Android: let frontends launch a pak through an intent extra

[MRinkl]

Pull Request

General Description

Lets a frontend start a game directly on Android. GameActivity now reads the string extra pak from its launching intent and passes that path to the native main() as argv[1], the same way the desktop ports take a pak on the command line. With the extra present and readable, the engine loads the pak and never shows the selection menu.

am start -n org.openbor.engine/.GameActivity -e pak /storage/emulated/0/Games/openbor/Game.pak

Without the extra, or when the file is missing, nothing changes: LauncherActivity and the menu work as before.

Why. Frontends such as Daijishō, Pegasus and ES-DE launch emulators with an am start line per platform and cannot drive the picker or the menu. Daijishō's maintainer asked for this to land upstream before they add an OpenBOR platform (TapiocaFox/Daijishou#917).

Storage. A pak outside the app's own folder needs a shared-storage permission. The manifest now declares MANAGE_EXTERNAL_STORAGE (Android 11+, "All files access") and READ_EXTERNAL_STORAGE up to API 32. When the pak cannot be read and the permission is missing, GameActivity shows a toast, asks for it (the permission dialog before Android 11, the "All files access" settings page from Android 11 on) and falls back to the menu. The next launch from the frontend then works. Nothing is asked of users who keep using the picker.

The permission check reads the manage_external_storage app op the way the platform does inside Environment.isExternalStorageManager(), because one vendor build (Anbernic's Android 12L) returns true from that method while the switch is off and every read fails.

Changes.

• GameActivity.java: EXTRA_PAK_PATH, an override of SDLActivity.getArguments(), and helpers that resolve the pak, check the permission and request it. Comments explain the flow and the am start line.
• AndroidManifest.xml: the two permissions with a comment on why they exist.

No C changes: main() already accepts a pak as its single argument on every platform.

Tested on an Anbernic RG405M (Android 12L, arm64) with this branch built through engine/android Gradle (NDK 25 locally). Paks on internal storage and on an exFAT SD card:

• With the extra and the permission: the engine log shows Game Selected: <intent path> and no menu.
• With the extra and no permission: toast, "All files access" page opens, switch on, relaunch loads the pak.
• Without the extra: LauncherActivity and the menu behave as before.

Current master exits on these particular paks a moment later because they use GIF assets, which the engine now refuses; the same Java on a v7533 engine runs them to the title screen from Daijishō's Play button.

🤖 Generated with Claude Code

[msmalik681]

@MRinkl have you tested this as storage permissions on game activity might be to late to access the file might need to move it to launcher activity.

[dbaldan]

As far as I know, there won't be a select pak menu anymore, in any port

[msmalik681]

Well this is a option to set a pak file via command line arguments so not a selection menu. At the moment i set the android port to have the user set a pak file from local safe directories but i will be adding back the option to have a pak file within the apk.

[DCurrent]

Well this is a option to set a pak file via command line arguments so not a selection menu. At the moment i set the android port to have the user set a pak file from local safe directories but i will be adding back the option to have a pak file within the apk.

Sorry, but no. We will not support a generic OpenBOR application that loads interchangeable game PAKs. That model has caused us severe support problems, and replacing a selection menu with a launch argument does not resolve the issue.

I already have a branch in progress that packages each game with its engine runtime as a signed, self-contained APK. That is OpenBOR’s required deployment model: one game, its bundled engine runtime, one independently installed application.

Bundling the game’s PAK inside the APK is not the objection. Retaining a generic loader alongside that option is. There will be no runtime selection of alternative game PAKs through a picker, command-line argument, Android intent, or other mechanism.

Game selection belongs in a separate launcher that starts the individually installed game applications - not a shared OpenBOR application that loads whichever PAK the launcher supplies.