v1.6.2

Changelog 1.6.2

Patch 2 - Crash Reports & Stability

What's New

Crash Handling & Safe Mode

• Added a global crash handler: uncaught exceptions are written to a durable crash report with app version, flavor, device, thread, exception, stack trace, and the last 400 app-log lines, then a dedicated crash screen opens instead of the app closing silently
• The crash screen can Retry, enter Safe Mode, export a diagnostic ZIP, share or copy the crash log, expand technical details, and exit; nothing is uploaded automatically
• The screen is self-contained and uses default Material colors, so it can still render when the app theme, preferences, or database are broken
• Crash loop protection: after 3 crashes within 60 seconds the screen is not relaunched again; a high-priority "Zenith stopped unexpectedly" notification remains as the way back to the report, including when the app crashes in the background
• A 1.2-second backup alarm reopens the crash screen if an OEM drops the activity launch during process death
• Safe Mode boots Zenith without loading your data: preferences use throwaway files, the database is in-memory, and the monitoring service, workers, and heartbeat handling stay off, so a bad setting or database can be bypassed without touching saved data
• An "App crashed - view report" pill stays above the bottom bar until the report is viewed, and a SAFE MODE banner offers a one-tap restart back to normal mode
• The last 10 crash reports are kept on disk; diagnostic ZIP exports include the latest crash plus up to 5 recent reports
• Developer settings has a new Crash & Safety section with main-thread, background, delayed background, and composition crash tests, an open-last-report action, and restart-in-Safe-Mode

Grace Period

• Added an opt-in Weekly Edit Lock (off by default): when enabled, changing the window or days shows a confirmation and then locks all Grace Period settings for 7 days
• Turning Weekly Edit Lock off requires the 10-lever confirmation
• Replaced the red "Editing locked" banner with a neutral card that explains only Grace Period settings are paused; app blocking outside the window keeps running as configured
• Reworded the info card, info-sheet entry, Features summary, and snackbar errors so the 2-hour limit and weekly cooldown are easier to understand #90

Bug Fixes

Foreground Service & Stability

• Fixed the ForegroundServiceDidNotStartInTimeException crash when the app launches while the main thread is busy: the visible activity now starts the monitor with startService(), which has no foreground-service start deadline #91 #88
• Heartbeat and midnight-reset starts now reuse a running monitor via startService() and only fall back to startForegroundService() for a cold start, with a further fallback when background restrictions reject the call
• The monitor service now tracks its own running state so restart requests choose the safe path

Schedules & Goals

• Goal-linked schedules now stay blocking after their window ends until the linked goal is completed, so an incomplete goal can no longer be bypassed once the schedule window closes #89
• Goal completion is detected from live usage and the latest "Goal Achieved" state instead of a usage cache that could stay stale for up to ~15 minutes, so completed goals stop blocking immediately
• The schedule overlay shows "Goal Lock Active" when blocking is extended past the window
• Schedule cards now dim when inactive or completed and show Active / Goal Lock / Completed / Inactive, while goal-locked cards stay highlighted

Other Improvements

Diagnostics

• Crash reports now keep 400 log lines instead of 200, and the in-app log buffer capacity increased from 500 to 2,000 entries

Build

• Bumped version to 1.6.2 (versionCode 15)
• Added unit tests for crash-loop detection and goal-linked schedule window behavior
• Removed inline code comments across the codebase (no behavior change)

Full Changelog: v1.6.1...v1.6.2