Google is committed to advancing racial equity for Black communities. See how.
After you build your Android App Bundle, you should test how Google Playuses it to generate APKs and how those APKs behave when deployed to a device.There are two ways you should consider testing your app bundle: locally using the
bundletool
command line tool and through Google Play byuploading your bundle to the Play Consoleand using a test track. This page explains how to use bundletool
to test yourapp bundle locally.The application plugin can generate Unix (suitable for Linux, macOS etc.) and Windows start scripts out of the box. The start scripts launch a JVM with the specified settings defined as part of the original build and runtime environment (e.g. JAVAOPTS env var). A Gradle Plugin to create a Mac OSX.app application and dmg based on the project. Note I am no longer able to actively develop this project. I will consider pull requests, but I believe that the Java world has changed significantly over the past several years, and this plugin may no longer be the recommended way to package a Java app for OSX. Setting up Gradle variables# Place the my-upload-key.keystore file under the android/app directory in your project folder. Edit the file /.gradle/gradle.properties or android/gradle.properties, and add the following (replace. with the correct keystore password, alias and key password).
![Gradle Gradle](https://blogs.unity3d.com/wp-content/uploads/2018/10/Build-App-Bundle-640x360.png)
bundletool
is the underlying tool that Gradle, Android Studio, and GooglePlay use to build an Android App Bundle or convert an app bundle into thevarious APKs that are deployed to devices. bundletool
is also available toyou as a command line tool, so you can recreate, inspect, and verify GooglePlay’s server-side build of your app’s APKs.You should use Android Studio and the Android plugin for Gradle tobuild and sign an Android App Bundle.However, if using the IDE is not an option (for example, because you’re using a continuousbuild server), you can alsobuild your app bundle from the command lineand sign it using
Note: You can not use jarsigner
.apksigner
to sign your app bundle.By default, the IDE does not use app bundles to deploy your app to a localdevice for testing. However, you canmodify your run/debug configurationand select the option to deploy APK from app bundle to see how it affectsyour app's execution.
Download bundletool
Sirius xm app mac. If you haven't already done so, download
bundletool
from theGitHub repository.Generate a set of APKs from your app bundle
When
bundletool
generates APKs from your app bundle, it includes them in acontainer called an APK set archive, which uses the .apks
fileextension. To generate an APK set for all device configurations your appsupports from your app bundle, use the bundletool build-apks
command, asshown below.If you want to deploy the APKs to a device, you need to also include your app’ssigning information, as shown in the command below. If you do not specifysigning information,
bundletool
attempts to sign your APKs with a debug keyfor you.The table below describes the various flags and options you can set when usingthe
bundletool build-apks
command in greater detail. Only--bundle
and --output
are required—all other flags are optional.Flag | Description |
---|---|
--bundle=path | (Required) Specifies the path to the app bundle you built using Android Studio. To learn more, read Build your project. |
--output=path | (Required) Specifies the name of the output `.apks` file, which contains all the APK artifacts for your app. To test the artifacts in this file on a device, go to the section about how to deploy APKs to a connected device. |
--overwrite | Include this flag if you want to overwrite any existing output file with the same path you specify using the --output option. If you don't include this flag and the output file already exists, you get a build error. |
--aapt2=path | Specifies a custom path to AAPT2. By default, bundletool includes its own version of AAPT2. |
--ks=path | Specifies the path to the deployment keystore used to sign the APKs. This flag is optional. If you don't include it, bundletool attempts to sign your APKs with a debug signing key. |
--ks-pass=pass:password or --ks-pass=file:/path/to/file | Specifies your keystore’s password. If you’re specifying a password in plain text, qualify it with pass: . If you’re passing the path to a file that contains the password, qualify it with file: . If you specify a keystore using the --ks flag without specifying --ks-pass , bundletool prompts you for a password from the command line. |
--ks-key-alias=alias | Specifies the alias of the signing key you want to use. |
--key-pass=pass:password or --key-pass=file:/path/to/file | Specifies the password for the signing key. If you’re specifying a password in plain text, qualify it with pass: . If you’re passing the path to a file that contains the password, qualify it with file: . If this password is identical to the one for the keystore itself, you can omit this flag. |
--connected-device | Instructs bundletool to build APKs that target the configuration of a connected device. If you don’t include this flag, bundletool generates APKs for all device configurations your app supports. |
--device-id=serial-number | If you have more than one connected device, use this flag to specify the serial ID of the device to which you want to deploy your app. |
--device-spec=spec_json | Use this flag to provide a path to a .json file that specifies the device configuration you want to target. To learn more, go to the section about how to Create and use device specification JSON files. |
--mode=universal | Set the mode to universal if you want bundletool to build only a single APK that includes all of your app's code and resources such that the APK is compatible with all device configurations your app supports. Note: bundletool includes only feature modules that specify <dist:fusing dist:include='true'/> in their manifest in a universal APK. To learn more, read about the feature module manifest. Keep in mind, these APKs are larger than those optimized for a particular device configuration. However, they’re easier to share with internal testers who, for example, want to test your app on multiple device configurations. |
--local-testing | Use this flag to enable your app bundle for local testing. Local testing allows for quick, iterative testing cycles without the need to upload to Google Play servers. For an example of how to test module installation using the --local-testing flag, see Locally test module installs. |
Mac Gradle Path
Deploy APKs to a connected device
Mac Gradle Home
After you generate a set of APKs,
bundletool
can deploy the rightcombination of APKs from that set to a connected device.For example, if you have a connected device running Android 5.0 (API level 21)or higher,
bundletool
pushes the base APK, feature module APKs, andconfiguration APKs required to run your app on that device. Alternatively, ifyour connected device is running Android 4.4 (API level 20) or lower,bundletool
looks for a compatible multi-APK and deploys it to your device.To deploy your app from an APK set, use the
Note: If you're using the install-apks
command and specifythe path of the APK set using the--apks=/path/to/apks
flag, asshown below. (If you have multiple devices connected, specify a target deviceby adding the --device-id=serial-id
flag.)--local-testing
flag with the build-apks
command,for local testing to work correctly, you need to use install-apks
to installyour APKs.Generate a device-specific set of APKs
If you’d rather not build a set of APKs for all device configurations your appsupports, you can build APKs that target only the configuration of a connecteddevice using the
--connected-device
option, as shown below. (If you havemultiple devices connected, specify a target device by including the--device-id=serial-id
flag.)Generate and use device specification JSON files
bundletool
is capable of generating an APK set that targets a deviceconfiguration specified by a JSON file. To first generate a JSON file for aconnected device, run the following command:bundletool
creates a JSON file for your device in the directory the tool islocated. You can then pass it to bundletool
to generate a set of APKs thattarget only the configuration described in that JSON file as follows:Manually create a device specification JSON
If you don’t have access to the device for which you want to build a targetedAPK set (for example, a friend wants to try your app with a device you don’thave on-hand), you can manually create a JSON file using the following format: Download line app for mac.
You can then pass this JSON to the
bundle extract-apks
command, as describedin the previous section.Extract device-specific APKs from an existing APK set
![Gradle Mac App Bundle Gradle Mac App Bundle](/uploads/1/3/4/1/134147142/987581429.png)
If you have an existing APK set and you want to extract from it a subset of APKsthat target a specific device configuration, you can use the
extract-apks
command and specify a device specification JSON, as follows:Measure the estimated download sizes of APKs in an APK set
To measure the estimated download sizes of APKs in an APK set as they wouldbe served compressed over-the-wire, use the
get-size total
command:You can modify the behavior of the
get-size total
command using thefollowing flags:Flag | Description |
---|---|
--apks=path | (Required) Specifies the path to the existing APK set file whose download size is measured. |
--device-spec=path | Specifies the path to the device spec file (from get-device-spec or constructed manually) to use for matching. You can specify a partial path to evaluate a set of configurations. |
--dimensions=dimensions | Specifies the dimensions used when computing the size estimates. Accepts a comma-separated list of: SDK , ABI , SCREEN_DENSITY , and LANGUAGE . To measure across all dimensions, specify ALL . |
--instant | Measures the download size of the instant-enabled APKs instead of the installable APKs. By default, bundletool measures the installable APK download sizes. |
--modules=modules | Specifies a comma-separated list of modules in the APK set to consider in the measurement. The bundletool command automatically includes any dependent modules for the specified set. By default, the command measures the download size of all modules installed during the first download. |
Additional resources
To learn more about using
bundletool
, try the following resource.Gradle Mac App Bundle Android
Codelabs
- Your First Android App Bundle,a codelab that explores the basic principles of Android App Bundles and showsyou how to quickly get started with building your own using Android Studio.This codelab also explores how to test your app bundlesusing
bundletool
.
Gradle Mac App Bundle App
We are happy to announce that we have just released
Cordova Android 9.0.0
! This is one of Cordova's supported platforms for building Android mobile applications.To upgrade:
Release Highlights
- Added Kotlin SupportKotlin is one of the newest statically typed languages for developing Android apps. It is designed to work fully with the existing language, Java.By default, Cordova has Kotlin disabled but it can be enabled with the
GradlePluginKotlinEnabled
preference inconfig.xml
.Additionally, Kotlin’s coding style and version are configurable. By default, Cordova sets the coding style asofficial
and uses version1.3.50
.Below is an exampleconfig.xml
for enabling and configuring Kotlin.For plugin developers, it is recommended to ensure that the Kotlin files are placed into the platformssrc/main/kotlin
directory. - Added AndroidX SupportAndroidX is the new and improved namespace for the Android Support Libraries. The original support libraries are no longer maintained.It is recommended to use AndroidX so that your app is running the latest support libraries but, by default, Cordova has AndroidX support disabled for compatibility with existing plugins.A lot of the Android supported plugins are still using the old support libraries which can not build when using the AndroidX support libraries. It is recommended to research each plugin to see if they support AndroidX before enabling this feature.It is recommended for plugin developers to start migrating to support AndroidX. App developers could also use Jetifier to automatically migrates their existing third-party libraries to use AndroidX.You can enable this feature by setting the
AndroidXEnabled
preference totrue
inconfig.xml
.If you were previously using the cordova-plugin-androidx plugin to enable AndroidX support, this plugin is no longer needed with this preference flag.The cordova-plugin-androidx-adapter plugin can be used to migrate the legacy references to the new AndroidX references. - Added Google Services SupportTo use Google APIs or Firebase services, the Gradle plugin Google Services is required to be enabled when building your Android application.For plugin developers, this can be enabled by setting to the app's
config.xml
theGradlePluginGoogleServicesEnabled
preference
flag. From theplugin.xml
file, you can do this by adding the following lines: - Android Version Support Update
- The default target SDK version is set to 29.
- The minimum SDK version is set to 22.
- The minimum supported Android version is 5.1.
NOTE: because Cordova has increased the minimum SDK version to 22, we no longer support or test with Android 5.0 or lower. - Gradle and Gradle Plugin Version Support Update
- Cordova has increased the default Gradle version to 6.5.
- Cordova has increased the Gradle Plugin to version 4.0.0
Please report any issues you find at issues.cordova.io!
Full Changelog
- GH-1005 chore: set AndroidX off by default
- GH-971 fix: Accept multiple mime types on file input
- GH-1001 fix: support both adaptive and standard icons at the same time
- GH-985 fix: Plugin install fails when preview sdk is installed
- GH-994 chore: cleanup yaml files
- GH-999 chore: remove trailing spaces from Java sources
- GH-992 chore: update some dependencies
- GH-998 chore: remove trailing spaces from framework build files
- GH-997 chore: remove trailing spaces from project template
- GH-996 chore: remove trailing spaces from bat files
- GH-995 remove trailing spaces from markdown files
- GH-993 chore: update
devDependencies
- GH-987 breaking: reduce combined response cutoff to 16 MB
- GH-988 major: Gradle 6.5 & Android Gradle plugin 4.0.0 updates
- GH-990 chore: remove trailing spaces from
app/build.gradle
- GH-989 breaking: remove
legacy/build.gradle
from template - GH-978 fix:
wait_for_boot
waiting forever - GH-965 fix: Increased
detectArchitecture()
timeout - GH-962 breaking: Bump Android gradle plugin to 3.6.0
- GH-948 feature: JVM Args flag
- GH-951 fix:
ANDROID_SDK_ROOT
variable - GH-959 test: synced AndroidX gradle versions to the same version as the Android test
- GH-960 feat:
com.android.tools.build:gradle:3.5.3
- GH-956 chore(npm): add
package-lock.json
- GH-958 chore(npm): add ignore list
- GH-957 chore: various cleanup
- GH-955 chore(eslint): bump package & apply eslint fix
- GH-954 breaking(npm): bump packages
- GH-953 chore(npm): use short notation in
package.json
- GH-823 fix: prevent exit fullscreen mode from closing application
- GH-950 fix: removed redundent logcat print
- GH-915 breaking: bump minSdkVersion to 22 and drop pre-Lollipop specific code
- GH-941 fix: GH-873 App bundle builds to obey command-line arguments
- GH-940 ci: drop travis & move codecov to gh-actions
- GH-929 chore: updated
README
to reflect what Android requires more accurately, which is Java 8, not anything less, not anything greater. Java 1.8.x is required. - GH-937 fix: GH-935 replaced
compare-func
with native sort method - GH-939 fix: test failure with shebang interpreter in
rewired
files - GH-911 refactor: use es6 class
- GH-910 refactor (eslint): use
cordova-eslint
- GH-909 chore: remove appveyor residual
- GH-895 feat: add github actions
- GH-842 refactor: remove
shelljs
dependency - GH-896 feat: add Kotlin support
- GH-901 feat: add AndroidX support
- GH-849 fix: cordova requirements consider the
android-targetSdkVersion
- GH-904 fix (adb): shell to return expected stdout
- GH-792 feat: upgrade
gradle
to 6.1 & gradle build tools to 3.5.3 - GH-902 chore: remove
.project
file & add.settings
togitignore
- GH-900 refactor: simplify
doFindLatestInstalledBuildTools
- GH-751 feat: use Java package name for loading
BuildConfig
- GH-898 chore: rename gradle plugin google services
preference
options - GH-893 feat: add Google Services support
- GH-709 feat: add
version-compare
library to comparebuild-tools
versions properly. - GH-831 chore: ignore auto-generated eclipse buildship files
- GH-848 breaking: increased default target sdk to 29
- GH-859 breaking: removed unnecessary project name restriction
- GH-833 chore: drop
q
module - GH-862 chore: replace
superspawn
&child_process
withexeca
- GH-860 feat: don't filter gradle's stderr anymore
- GH-832 chore: drop node 6 and 8 support
- GH-890 chore: bump version to 9.0.0-dev
- GH-697 chore: optimization code
- GH-863 chore: removed comment that serves no purpose
- GH-861 chore: update
jasmine
to 3.5.0 - GH-858 chore: modernize our one E2E test
- GH-854 chore: ensure to lint as many files as possible