PackageManager cache invalidation after component enable/disable on Android 34
0 reputation · 10 Feb 2022, 03:35 UTC
Goal
Determine how and when the internal cache used by PackageManager.queryIntentActivities() is refreshed after a component’s enabled state is toggled via PackageManager.setComponentEnabledSetting() on Android 34.
Constraints
There is no public API to force a cache flush, and the documented AOSP source indicates the cache lives until the package‑manager service restarts or a binder timeout occurs. OEM implementations vary, and the new package‑visibility rules on Android 11+ may delay the appearance of newly visible components.
Uncertainty
It is unclear whether the ACTION_PACKAGE_CHANGED broadcast is emitted before or after the cache is refreshed, creating a potential race window. The duration of stale data also appears to differ across API levels and device manufacturers.
Questions
- What specific internal event in
PackageManagerServicetriggers a cache flush after a component’s enabled state changes? - How long can stale results persist on Android 34, and does this duration depend on the device’s OEM skin or API level?
- Is there a reliable, documented method to force the PackageManager to re‑query intent filters without restarting the service or the entire system?
android