Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to configure Android ABIs #808

Open
mhsmith opened this issue Aug 3, 2022 · 5 comments
Open

Add option to configure Android ABIs #808

mhsmith opened this issue Aug 3, 2022 · 5 comments
Labels
android The issue relates to Android mobile support. enhancement New features, or improvements to existing features. good first issue Is this your first time contributing? This could be a good place to start!

Comments

@mhsmith
Copy link
Member

mhsmith commented Aug 3, 2022

Generated APKs and AABs currently include the following ABIs:

  • armeabi-v7a
  • arm64-v8a
  • x86_64

We can't drop armeabi-v7a yet, because there are still too many 32-bit devices in use (see chaquo/chaquopy#709). However, we were OK to drop 32-bit x86 because we set our minimum API level to 26 (beeware/briefcase-android-gradle-template#49), and 64-bit emulator images have been available since level 21. Since BeeWare developers will need to use a 64-bit emulator image anyway to test on the current version of Android, requiring them to do the same on the other versions is no great inconvenience. And omitting x86 reduces the APK size and makes it faster to build and install.

Anyway, there are legitimate reasons for developers to want to change the set of available ABIs, so we should make this configurable in pyproject.toml. See beeware/briefcase-android-gradle-template#52 (comment) for discussion of possible approaches.

@mhsmith mhsmith added the enhancement New features, or improvements to existing features. label Aug 3, 2022
@mhsmith
Copy link
Member Author

mhsmith commented Aug 3, 2022

Other open issues that may involve updating the Android template:

@freakboy3742 freakboy3742 added up-for-grabs android The issue relates to Android mobile support. good first issue Is this your first time contributing? This could be a good place to start! labels Aug 4, 2022
@freakboy3742
Copy link
Member

freakboy3742 commented Aug 4, 2022

+1.

Flagging this as "first timers" because the actual change isn't especially complex:

  • Modify the Android Gradle template to explicitly specify the supported platforms. See this documentation for the configuration change that is required. This should be controlled by the template, with the NDK configuration block only being included if the template context provides a value.
  • Modify the Android Gradle backend to include the list of supported platforms in the template context. This should be extracted from the the app configuration using a new android_abis setting; it will fall back to "None" if not specified.
  • Document for the new (optional) android_abis Android configuration setting.

For example, a project configuration of:

[tool.briefcase.app.myapp.android]
android_abis = ['arm64-v8a', 'x86_64']

would result in a build.gradle file that contains:

...
    defaultConfig {
        applicationId "com.example.helloworld"
...
        ndk {
            abiFilters 'arm64-v8a', 'x86_64'
        }

However, if the user doesn't specify android_abis, the ndk block would not be included.

@mhsmith
Copy link
Member Author

mhsmith commented Aug 4, 2022

The above comment is valid for the current Rubicon template. After we switch to Chaquopy, the abiFilters setting will be compulsory, because the Chaquopy plugin requires it. I did this because defaulting to all 4 ABIs could make the APK too large, so I thought it was better to force the user to be explicit about what they wanted.

@mhsmith
Copy link
Member Author

mhsmith commented Jan 31, 2023

This can now be done using the build_gradle_extra_content setting. For example, to include the 64-bit ABIs only:

build_gradle_extra_content = "android.defaultConfig.ndk.abiFilters = ['arm64-v8a', 'x86_64']"

@mhsmith mhsmith closed this as completed Jan 31, 2023
@freakboy3742
Copy link
Member

@mhsmith I'm not sure we can close this. Selecting target platforms isn't an especially common use case, but it's high on the list of "optional things people are may want to do to their project". An explicit setting for this means we're protected from any format changes that Gradle introduces into the configuration file format, as we're capturing a "first order" user configuration.

At the very least, it's worth capturing as documentation (possibly as a section in the docs on briefcase_gradle_extra_content capturing "common use cases" (along with the extract_packages use case).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
android The issue relates to Android mobile support. enhancement New features, or improvements to existing features. good first issue Is this your first time contributing? This could be a good place to start!
Projects
None yet
Development

No branches or pull requests

2 participants