Repository navigation
Sprout 0.2.1 · Backups and recovery
Pre-releaseSprout 0.2.1 focuses on keeping your time safe. Backups read one current database snapshot, and restores recheck the database when they commit so a stale preview cannot overwrite newer edits.
- Verified portable backups: schema 2 adds a SHA-256 checksum, complete record validation, original device attribution, historical activity names, preferences and Windows app rules. Saved documents are read back before success is reported. Sprout still reads 0.2.0 backups.
- Automatic recovery copies: retain one snapshot from each of seven saved days and eight copies from before imports, restores and deletions. An unwritable safety copy cancels the change without touching existing records.
- Careful restores: add missing history in one transaction, keep current edits and timers, and respect known intentional deletions. Recovering deletions and restoring preferences/rules are explicit options. Added Windows rules start disabled for review.
- Database recovery: existing databases are checked through a non-destructive read-only open first. If recovery is needed, Sprout builds and integrity-checks a replacement before preserving the original database and WAL/SHM companions together in a recovery archive.
- Clearer backup controls: previews show saved dates, totals, additions and conflicts. Cancellation is distinct from success; Android provider I/O and read-back verification run off the UI thread.
See backup and recovery instructions and the review.
Validation
- 58 local tests pass, including the owner's private CSV check. All 712 entries and 2,868,154 seconds survive backup/restore with every session field retained; re-restoring adds zero entries. A separate empty replica receives the CSV history through the Drive protocol simulator. The CSV remains private.
- 57 public tests pass; formatting and Flutter analysis are clean.
- 27 backup/recovery tests pass on Windows, covering the actual SQLite/filesystem code. The extracted portable ZIP also passes native startup, persistence and database-integrity checks.
- Android ARM64 and x86_64 release builds pass. The APKs retain the stable 0.2.0 signing certificate and package, enabling upgrades from that release.
- On an API 35 emulator, the release APK imports two synthetic entries totalling 7,200 seconds, exports verified JSON through the real picker, and restores every field into fresh app storage. Cancelling export leaves the saved-snapshot status untouched; damaged JSON is rejected without changing current records. A running timer is frozen in the exported file while the real timer continues and remains controllable.
- A deliberately corrupted Android database is preserved byte-for-byte on the recovery screen. Recovery restores both saved entries, passes SQLite integrity and archives the damaged original exactly. Device screenshots use synthetic history.
- Published APK/ZIP files are CRC-checked and accompanied by SHA-256 checksums. The source ZIP contains no private CSV, database or signing key.
Source: 179a1adfab5c7a0819a96ef64683dde337a55cce.
All three hosted jobs passed, including Windows backup and portable startup checks.
Downloads
Use the ARM64 APK for most Android phones; x86_64 is for compatible devices/emulators. Extract the Windows ZIP and keep its files together, then run sprout.exe. Google Drive still needs your own OAuth configuration.
Local recovery copies are removed with app data. Keep an exported portable backup on another device or in your own cloud storage. Backup JSON is readable; its checksum detects damage and is not encryption or an author signature. Drive sync propagates edits/deletions and does not replace versioned backups.
This remains a preview. Live Google sign-in/Drive access was not available for testing. Windows file-picker interaction, focus/idle/lock/sleep tracking, tray behavior and startup at login still need checking on the owner's PC; physical-phone launcher/battery behavior also remains device-dependent.