fix(calendar): don't register calendar observer before permission granted
All checks were successful
CI / ci (push) Successful in 4m15s
All checks were successful
CI / ci (push) Successful in 4m15s
The repository registers a ContentObserver on the calendar provider eagerly in its init block, and an activity-scoped SettingsViewModel (which drives the theme) injects that repository — so the @Singleton is constructed at launch, above RootScreen's permission gate. On newer Android, registering an observer on a provider you lack permission for throws SecurityException instead of silently no-op'ing, so the app crashed instantly on every launch whenever calendar access wasn't granted (fresh install or revoked permission), before the permission screen could ever appear. Guard the registration behind a calendar-permission check and re-attach the observer lazily on the first calendars()/instances() read, which runs once the gate opens and screens subscribe. Access to the observer collections is now synchronized since registration can happen on the main thread (repo init) or the IO dispatcher (query re-attach). Verified on-device: permission-denied launch shows the permission screen instead of crashing; granting it proceeds to the calendar with live updates. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -28,8 +28,8 @@ android {
|
||||
// the tag, with versionCode = MAJOR*10000 + MINOR*100 + PATCH
|
||||
// (e.g. v2.0.0 -> 20000). These committed values are the dev/local
|
||||
// default; keep them matching the latest released tag. See docs/RELEASING.md.
|
||||
versionCode = 20700
|
||||
versionName = "2.7.0"
|
||||
versionCode = 20701
|
||||
versionName = "2.7.1"
|
||||
|
||||
testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user