fix: app icon picker and banner hide on reload

[deadlyjack]

No description provided.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; no actionable new defect remains in the changes since the previous review.

Summary

• Adds selectable adaptive and legacy Android launcher icons.
• Integrates icon selection with settings, purchase eligibility, rewarded ads, and persistence.
• Updates dialog and loader lifecycle behavior used by the picker.
• Adds unit coverage for icon metadata, selection flow, UI behavior, and Android resource preparation.
• Fixes banner visibility restoration across reloads.

Diagram

sequenceDiagram
    participant User
    participant Picker as App Icon Picker
    participant Selection as Icon Selection Flow
    participant Android as System Plugin
    participant PM as PackageManager
    User->>Picker: Select icon
    Picker->>Selection: selectAppIcon(iconId)
    Selection->>User: Confirm app exit
    opt Reward or Pro required
        Selection->>Selection: Validate entitlement / show reward
    end
    Selection->>Android: setAppIcon(iconId)
    Android->>PM: Enable target alias
    Android->>PM: Disable other aliases
    Android-->>Selection: Success
    Selection->>Selection: Persist selected icon

Loading

_{Reviews (4) · Last reviewed commit: "fix: bug"}

[github-actions]

Preview Release for this, has been built.

Click here to view that github actions build

[deadlyjack]

@greptile review

[RohitKushvaha01]

@greptile

[RohitKushvaha01]

@greptile elaborate on the p1 finding

[greptile-apps]

The P1 is about the ordering of the Android launcher-alias changes, not the picker UI itself.

src/lib/appIconSelection.js calls system.setAppIcon(iconId) after the confirmation/ad flow. The native implementation then changes the enabled state of the launcher aliases declared in config.xml (MainActivityIconPrism, MainActivityIconPorcelain, etc.). Each alias targets MainActivity, so the enabled alias is also the launcher entry point for the app.

The risk is that the alias loop can disable the currently active alias before enabling the replacement. That creates a transient state in which Android has no enabled MAIN/LAUNCHER component for Acode. Depending on Android/OEM launcher behavior, this can:

• make the app disappear from the launcher;
• cause the current task/activity to be recreated or exited while the picker is open; or
• leave the app without a usable launcher entry if the operation is interrupted or fails part-way through.

It will not necessarily reproduce on every device, and disabling an alias does not guarantee that Android kills the process. The concern is the unsupported intermediate component state and the device-dependent lifecycle/launcher reaction. The fact that appSettings.update() runs only after setAppIcon completes does not prevent this native transition; it only keeps the JS setting consistent after a successful operation.

The required invariant should be: there must always be at least one enabled launcher alias. The safest fix is to enable the replacement alias first, then disable the previous aliases (or retain a stable forwarding launcher activity that is never disabled). The regression test should switch icons repeatedly from an already-running app and verify that the app remains open/recoverable and that exactly one launcher alias is enabled afterward.

[RohitKushvaha01]

@greptile