MuntashirAkon / MuntashirAkon/AppManager
Report install result via EXTRA_RETURN_RESULT (like the stock installer)
- Dominant language
- Java
- Stars
- 9k
- Forks
- 518
- PR merge metrics
- No merged PRs in 30d
Description
### Please check before submitting an issue
- [x] I am using the latest version of App Manager
- [x] I have searched the issues and haven't found anything relevant
- [x] I have read the docs
- [x] I know that generating a report, in whole part or in part, using AI/LLM is prohibited
### Describe the new feature
Right now, when another app (e.g. an app updater) hands App Manager an APK to install via ACTION_INSTALL_PACKAGE and asks for a result back (Intent.EXTRA_RETURN_RESULT = true), App Manager doesn't report anything — the caller just gets Android's default RESULT_CANCELED, identical to what it would get if the user had actually cancelled the install. There's no way for the calling app to tell "it succeeded" apart from "it was cancelled" or "App Manager doesn't support this at all."
This is a real gap in practice: I confirmed by testing directly that App Manager's PackageInstallerActivity completes installs successfully but never calls setResult() before finishing, so the caller has no reliable signal.
Both Android's own stock PackageInstaller and InstallerX-Revived already implement this correctly — see [InstallerX-Revived #672](https://github.com/wxxsfxyzm/InstallerX-Revived/issues/672), which was implemented in [PR #709](https://github.com/wxxsfxyzm/InstallerX-Revived/pull/709). The convention there:
If the launching intent has Intent.EXTRA_RETURN_RESULT = true, check the install outcome before finishing.
On success: `setResult(RESULT_OK, Intent().putExtra("android.intent.extra.INSTALL_RESULT", ))`
On failure: `setResult(RESULT_FIRST_USER, Intent().putExtra("android.intent.extra.INSTALL_RESULT", ))`
Otherwise (cancelled/unknown): leave the default RESULT_CANCELED.
Would it be possible to add the same handling to PackageInstallerActivity? This would let calling apps (app updaters, installer front-ends, etc.) get a direct, reliable answer instead of having to guess based on broadcasts, focus changes, or timeouts.
### Describe the solution you'd like
_No response_
### Describe alternatives you've considered
_No response_
### Additional context
_No response_
Contributor guide
Research direction
Start in PackageInstallerActivity and trace how install success, failure, and cancellation finish the activity. Check how the launching intent exposes EXTRA_RETURN_RESULT and compare the existing result handling with the behavior described for stock PackageInstaller and InstallerX-Revived. Done means callers can distinguish success and failure through the specified result codes while cancellation remains RESULT_CANCELED.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, java
- Domain
- mobile-dev
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100