Restrict release ABIs to arm/arm64, limit locales to es/en

[mxrtins04]

closes #358

What changed

Restricted release APK to arm64-v8a and armeabi-v7a native libraries via ndk.abiFilters in buildTypes.release, leaving buildTypes.debug unfiltered so x86_64 emulators continue to install correctly. Restricted packaged locale resources to es and en via resConfigs in defaultConfig.

Files changed

micopay/frontend/android/app/build.gradle

Verification

• ./gradlew assembleRelease assembleDebug: both succeed
• unzip -l on release APK: only lib/arm64-v8a and lib/armeabi-v7a present, no lib/x86 or lib/x86_64
• unzip -l on debug APK: lib/x86_64 (and all other ABIs) still present, emulators unaffected
• Release APK size: 12,771,072 bytes (~12.2 MB), down from 25.2 MB baseline, under the 15 MB target
• Verified against app-release-unsigned.apk since no local signing keystore is configured in this environment
• QR scanner functional testing on real arm64/armeabi-v7a hardware is left to the integrator at merge time, per issue scope

Security / rollback notes

No security-sensitive code touched. Change is confined to app/build.gradle build configuration only — no changes to extractNativeLibs, minifyEnabled, shrinkResources, plugins, dependencies, or i18n files. Rollback is a single revert of this file.

Fill in yourself

• Issue number placeholder if the template requires one

[drips-wave]

@mxrtins04 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[mxrtins04]

@ericmt-98 please approve the workflow

[mxrtins04]

@ericmt-98 @waterWang please approve workflow. Do you have a tg channel i could join? Or could you give me your tg contact?

[ericmt-98]

Reproduced locally against this branch, with the release keystore present.
Everything you claimed holds, and the acceptance criteria are met.

	main	this PR
Release APK	25,405,597 B	12,971,206 B (12.37 MB)
ABIs in release	arm64-v8a, armeabi-v7a, x86, x86_64	arm64-v8a, armeabi-v7a only
Debug APK	31,233,962 B	31,233,962 B — byte-for-byte identical
lib/x86_64 in debug	present	present

• ./gradlew assembleRelease assembleDebug — BUILD SUCCESSFUL, exit 0, on
  AGP 8.13.0 / Gradle 8.14.3.
• Release drops 12,434,391 bytes, 48.9%, comfortably under the 15 MB target.
• The debug APK coming out identical to main is the strongest evidence that
  the filter is confined to release. No INSTALL_FAILED_NO_MATCHING_ABIS risk
  for anyone on an x86_64 emulator.
• resources.arsc is now 147,464 B, down from the ~390 KB the audit measured,
  so resConfigs did its part too.

One number to correct for the record: you reported 12,771,072 B, I measure
12,971,206 B. That's the signing block — you built app-release-unsigned.apk,
as you noted, and this machine has the keystore. Your figure was right for what
you could build; 12.37 MB is the real download size.

Approving. QR scanner verification on physical arm64 and armeabi-v7a hardware
stays with the integrator at merge time, per the issue scope.

Two follow-ups, neither blocking and neither yours to fix here:

1. ndk.abiFilters under release also applies to bundleRelease, so the Play
   AAB loses x86_64 as well. That matches the intent of #358, but it's a
   decision worth recording rather than discovering later — it drops Chromebooks
   and x86 Android devices from Play delivery.
2. resConfigs is deprecated in AGP 8.13 in favour of
   androidResources.localeFilters. It works today with a warning; worth a
   sweep when the project moves toward AGP 9.

Nice, tight change — four lines, correct scope, and the one subtle trap in the
issue avoided.

[ericmt-98]

Merged as 9dfb61f. Thank you — this is exactly the shape of contribution that's easy to say yes to.

You read the delicate part of the issue correctly and kept the filter out of debug, which is where this change most often goes wrong. You verified both variants instead of assuming, you said plainly which figure came from an unsigned build and why, and you drew the line at what you couldn't test rather than overstating it. Four lines, one file, no scope creep.

Everyone installing MicoPay by direct link now downloads half of what they did this morning. On entry-level phones over mobile data in Mexico, that is a real difference, not a rounding one.

Hope to see you on another issue.