PackageManager cache invalidation after component enable/disable on Android 34

Answer

The internal cache used by PackageManager.queryIntentActivities() is cleared synchronously inside the same binder transaction that processes setComponentEnabledSetting(). The clearing happens when PackageManagerService.updatePackageSettingsLocked() calls mResolverActivityList.removeAllFiltersForPackage(pkg), which removes the resolved‑intent list for the affected package before the ACTION_PACKAGE_CHANGED broadcast is sent.

Confirmed facts

• Calling PackageManager.setComponentEnabledSetting() triggers PackageManagerService.updatePackageSettingsLocked().
• That method writes the new enabled state to settings and invokes mResolverActivityList.removeAllFiltersForPackage(pkg), clearing the resolver cache for the package.
• After the cache is cleared, the service broadcasts ACTION_PACKAGE_CHANGED.
• If no further binder transaction occurs, the cleared cache stays empty until the PackageManagerService process restarts or a binder timeout forces a refresh; on AOSP the default timeout is about 10 seconds.
• There is no public API to force a cache flush; the only documented way to cause a refresh is to make another binder transaction that triggers PackageManagerService to rebuild its resolver list (e.g., calling getInstalledPackages(0) or querying any intent) after the component change.

Likely explanation

Because the cache flush occurs within the same binder call, stale results from queryIntentActivities() are removed before any receivers see the ACTION_PACKAGE_CHANGED broadcast, eliminating a race window for most system components. On Android 34 the binder timeout remains ~10 seconds, but OEMs may adjust it via config_pendingBinderTimeout or custom PackageManagerService implementations, so stale data can persist from a few seconds up to several minutes on some devices.

Steps to get fresh results

1. Call setComponentEnabledSetting() to enable or disable the component.
2. Immediately afterwards, invoke a benign PackageManager operation that forces a binder transaction, such as:

PackageManager pm = context.getPackageManager();
pm.getInstalledPackages(0); // or pm.queryIntentActivities(new Intent(Intent.ACTION_MAIN), 0);

1. Now a subsequent queryIntentActivities() will return an up‑to‑date list reflecting the new enabled state.

Verification

On an Android 34 device (e.g., a Pixel 8 running AOSP), run:

adb shell cmd package set-component-enabled-setting / [enabled|disabled]
adb shell cmd package query-activities 

Repeat the query immediately after the command and again after a short delay; you should see the component appear/disappear right away if you follow step 2, or persist for up to the binder timeout if you omit it.
Note
If you need to know the exact stale duration on a specific OEM skin, you would have to measure the binder timeout on that device; otherwise the steps above work universally.