Android 🤖

Run

gradlew :android:installDebug

The AndroidLauncher (an AndroidApplication) creates the Main via getMain(canStart) → new Main(canStart, getCommandline()).

⚠️ Permission-delayed start

On Android, you usually do not bring the UI up immediately — you request permissions first. The pattern:

// in the launcher: canStart = false → the UI does NOT come up yet
initializeForView(getMain(false), config);
// … after the user grants the permissions (callback) …
main.startApp(true);   // now yes, bring up the UI (delayed = true)

This way, camera/GPS/Bluetooth are already authorized when the first screen appears (see Ch. 4 §4.2).

Manifest and permissions

Declare in the AndroidManifest.xml the permissions for the features you use (camera, location, Bluetooth) — and request them at runtime before startApp(true).

Status bar and density

The status bar is accounted for in the layout (DeviceConfig.statusbarHeight).
Density: Screen.scale reflects the DPI; since you use Relative/fractions, the UI adapts on its own.

Back button

The physical Back button is captured by the app (by default it calls hide() on the top window — see The window stack).

Packaging

The native .so libs (incl. crossfly-lib) are packaged per ABI. Signing/AAB and upload to the Play Store: Build and distribution.

Best practices

Request permissions before startApp(true) (delayed start) — avoids broken screens.
Test on varied densities/screens; rely on Relative to adapt.

Common mistakes

Bringing the UI up (canStart=true) and only then requesting permission (feature unavailable on the 1st screen).
Forgetting the permission in AndroidManifest.xml (the runtime request fails silently).