feature: offer the Android per-app language picker for localized apps

[SRWieZ]

The gap

Declare permission_localizations in config/nativephp.php and iOS registers the locales — per-locale InfoPlist.strings, knownRegions — so the app shows up in Settings → [App] → Preferred Language.

On Android, nothing happens. Android 13+ only lists an app in the per-app language picker when its manifest points at a locale-config resource, and the compiler never writes one. So a fully localized NativePHP app follows the system language but can never be switched per app:

Before	After
No Language entry in App info	Language entry appears

The fix

AndroidPluginCompiler now mirrors what the iOS compiler already does with the same declarations:

1. Collects every locale declared by the app's permission_localizations and by plugins' ios.info_plist_localizations.
2. Writes res/xml/locales_config.xml. A new documented default_locale config key (default 'en') leads the list, so users can always switch back to the app's base language explicitly.
3. Injects android:localeConfig="@xml/locales_config" into the <application> tag (once — idempotent across rebuilds).

It runs before the no-plugins early return, so an app with only its own permission_localizations gets the picker too (same app-config-only path the iOS side handles).

Apps that declare no localizations are completely untouched — no file, no manifest change.

Verified on an emulator (Android 16)

The picker lists exactly the declared locales, and selecting one changes what the app's PHP sees (Locale.getDefault() → Device::getInfo()['language']):

Picker	App in French

Tests

Three new cases in AndroidCompilerTest: writes the config + manifest attribute from app declarations, merges plugin locales and stays idempotent, and leaves apps without localizations untouched. Full suite passes (899).

[gwleuverink]

Awesome, thanks! Great PR 🚀

One design question first, more for @simonhamp (and my own understanding) than for this PR. The language list comes from permission_localizations keys, including plugin ones. A plugin translating its permission explainer into ten languages would make an English-only app offer ten languages in the picker. iOS already does the same through the lproj folders, so this is consistent, but maybe the supported languages want their own key that both platforms read? Not sure on this one but it sounds like a bug 🤔

Then a smaller one, about what happens when the localizations go away again by an update after the app is already installed:

1. Declare fr and nl under permission_localizations, run native:run android. locales_config.xml and the android:localeConfig attribute are written, the picker shows both languages.
2. Set permission_localizations => [] (or remove the only plugin that shipped them) and run native:run android again.
3. writeLocalesConfig returns early on the empty list, so the xml and the attribute stay exactly as they were.
4. The new APK still carries localeConfig with fr and nl, and the picker keeps offering them to an app that no longer declares any.
5. Only a fresh native:install clears the manifest, and since nativephp/ is gitignored a dev building releases from a long-lived scaffold can ship it that way.

Admittedly, this will likely not happen often in nativephp apps, but it might. It is cosmetic, but injectPluginProguardRules and injectGradlePlugins right above it do clear their block on an empty list. Was skipping that intentional, or would you be up for having this one strip the attribute and delete the file when the list is empty?

[SRWieZ]

I think this was originally based on iOS, if I recall correctly.

As a user, I’d personally prefer full control over which locales are suggested.

It really depends more on my Laravel app’s translation strings than on plugin permissions.

So maybe a new config ?

[gwleuverink]

Exactly. We cant have a random plugin contributing a bunch of extra language options the app doesnt even support.

Dedicated config makes sense to me. Good to be explicit. What do you think bossmen @simonhamp @shanerbaner82 ?