FakeStore install sessions hang when PackageInstaller returns STATUS_PENDING_USER_ACTION on Android 14+

[abranson]

FakeStore can leave installs or updates stuck when PackageInstaller returns STATUS_PENDING_USER_ACTION.
FakeStore receives the confirmation intent from PackageInstaller.EXTRA_INTENT, but currently tries to start that activity directly from its session result receiver. On Android 14+ this can be blocked by background activity launch restrictions, so the required confirmation dialog is never shown and the install appears to hang.

To Reproduce
Steps to reproduce the behavior:

1. On Android 14+ or Android 15, install an older version of an app through Aurora Store using the session installer.
2. Switch the install/update source to microG FakeStore.
3. Try to update the same app through FakeStore.
4. Android requires user confirmation because the installer changed, the install may remain stuck instead of showing the confirmation dialog.

Alternative (my original problem):

1. Install a base app through Aurora Store that uses split install.
2. Use a feature in that app that triggers a Play Core dynamic feature/split install through FakeStore.
3. PackageInstaller requires confirmation, the split install may stay at 0% or "initializing"

Expected behaviour
When PackageInstaller returns STATUS_PENDING_USER_ACTION, FakeStore should show the required confirmation to the user, for example through a notification PendingIntent or "requires user confirmation" , instead of trying to launch the confirmation activity directly from the background.

Observed behaviour
Install seems to stall, split install sticks indefinitely at 0%

System
Android Version: 15 (but would happen on 14)
Custom ROM: Sailfish OS AppSupport 15

Additional context
I think this is related to #3541 and PR #3543: UPDATE_PACKAGES_WITHOUT_USER_ACTION / USER_ACTION_NOT_REQUIRED is still useful, but FakeStore still needs to handle STATUS_PENDING_USER_ACTION because Android can require confirmation for valid reasons, such as installer-of-record/update-owner mismatch or any other corner case. The extra component between the UI and the PackageInstaller seems to be the cause. Maybe in this case a fallback to a notification PendingIntent like I think you already do in the case of a locked-screen could catch everything potentially stuck here. For the split installs, then perhaps reporting the "requires user confirmation" session state back to the app, and it can handle asking for it?

[grenadin]

Additional context I think this is related to #3541 and PR #3543: UPDATE_PACKAGES_WITHOUT_USER_ACTION / USER_ACTION_NOT_REQUIRED is still useful, but FakeStore still needs to handle STATUS_PENDING_USER_ACTION because Android can require confirmation for valid reasons, such as installer-of-record/update-owner mismatch or any other corner case. The extra component between the UI and the PackageInstaller seems to be the cause. Maybe in this case a fallback to a notification PendingIntent like I think you already do in the case of a locked-screen could catch everything potentially stuck here. For the split installs, then perhaps reporting the "requires user confirmation" session state back to the app, and it can handle asking for it?

Thanks @abranson for the detailed report and for linking #3541 and #3543.

To clarify: USER_ACTION_NOT_REQUIRED is useful on all Android 12+ devices, it suppresses unnecessary confirmation dialogs for routine installs and DFM sessions. The EMUI behavior was just the most visible symptom. Since I only have Huawei devices to test on and am still relatively new to this codebase, I didn't observe the Android 14+ background launch restriction behavior you're describing.

You're right that it doesn't cover the case where Android legitimately requires confirmation (e.g. installer-of-record mismatch). In that case STATUS_PENDING_USER_ACTION still comes through, and looking at SessionResultReceiver, I can see it already has a notification fallback for the keyguard-locked case but the unlocked path still tries to launch the activity directly, which would be blocked on Android 14+ due to background activity launch restrictions.

So the two fixes would complement each other: PR #3543 reduces unnecessary prompts, while extending the existing notification fallback in SessionResultReceiver to also cover the Android 14+ case would handle confirmation when it's genuinely required. Agreed, this should probably be a separate PR since it's a different layer of the install flow. That said, I don't have a device running Android 14+ to verify, so I may be wrong on the details.