Kunzisoft / Kunzisoft/KeePassDX

Timer Autosave

Open
#2,497 1 comment 0 reactions 0 assignees View on GitHub
feature
Dominant language
Kotlin
Stars
7.3k
Forks
401
Avg merge
2d 10h
Merged PRs (30d)
1

Description

### Checks

- [x] I have read the Wiki, searched the open issues, and still think this is a new feature.

### Explain the problem clearly and succinctly:

I had a recent scenario with KeePassDX 4.2.4 with Autosave off & with a Timeout (Save & Lock) of 15 minutes, whereby an entry was finalized, and I switched to another app. Android system decided to rug-pull the RAM from KeePassDX a little while after, thus destroying the existence of the new entry. Resuming-to KeePassDX to Save was therefore impossible

Autosave is off is to prevent thrashing the MicroSD card: theyre fragile and require paced management. The Timeout feature assumes an ideal state: that RAM is plentiful and there is no outer governance of resources, and therefore the Timeout can be achieved as set

### Describe the solution you'd like:

I don't know the Android internal mechanism for memory management, but the behavior hints that Android system doesnt throw a warning, nor does KeePassDX have any mechanism to know when its RAM allocation is about to expire, nullifying its Timeout. Considering that, a middleground balance can be optioned: a timered Autosave of 1 or 2 minutes since last activity. Keeping the database open, securing the entry to avert events of the system executive. It can be the one that toggles-on when event Autosave is toggled-off, and it too can be toggled-off, further for the manual Save

### Describe alternatives you've considered:

A shorter Timeout

### Additional context:

_No response_

Contributor guide

Open the contributing guide

Research direction

No files or tests are named. Start by locating the existing Autosave and Save & Lock timeout settings and their Android lifecycle handling, then determine how a timered save would interact with manual saving and both toggles. Done means the proposed interval behavior preserves edits after the app is reclaimed while leaving users able to disable it and avoid unwanted frequent writes.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, kotlin
Domain
mobile
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.