MuntashirAkon / MuntashirAkon/AppManager

Report install result via EXTRA_RETURN_RESULT (like the stock installer)

Open
#2,003 2 comments 0 reactions 0 assignees View on GitHub
Feature Feature: 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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.