Building Java apps for Android
Important
Visual Studio App Center is scheduled for retirement on March 31, 2025. While you can continue to use Visual Studio App Center until it is fully retired, there are several recommended alternatives that you may consider migrating to.
To build your first Android app, follow these steps:
- Connect to your repository service account (GitHub, Bitbucket, VSTS, Azure DevOps).
- Select a repository and a branch where your app lives.
- Choose the Android project you want to build.
- Set up your first build.
Note
For the app to run on a real device, the build needs to be code signed with a valid certificate.
Note
The App Center tracks the project by searching the gradle (and gradlew) directory files of the Android project. Please do not include these files in the project .gitignore as App Center Build will not be able to find them.
Warning
Due to the recent shutdown of JCenter, certain apps may experience Gradle Task failures when building with App Center. Please view the migration guide provided by Gradle. As a workaround, all instances of jcenter()
can be removed from the build.gradle
file, and replaced with jcenter { url "http://jcenter.bintray.com/"}
. Read more about the JCenter Shutdown here.
You must connect to your repository service account if you haven't already. Once your account is connected, select the repository where your Android project is located. To set up a build for a repository, you need admin and pull permission for it.
After selecting a repository, select the branch you want to build. By default, all the active branches will be listed.
Before your first build, the Android project needs to be configured.
By default, a new build is triggered every time a developer pushes to a configured branch. This is referred to as "Continuous Integration". If you prefer to trigger a new build manually, you can change this setting in the configuration pane.
The available build variants will populate from the Build Types and Product Flavors specified in the build.gradle (app level) file. Select which build variant should be built.
Note
App Center Build supports finding build variants as the combination of a Build Type (debug, release or custom defined) and one of your gradle declared Product Flavors. Detection of Flavor Dimensions (combinations of multiple product flavors) isn't supported at this time.
The Android App Bundle is a distribution format that's uploaded to the Play Store and used to generate optimized APKs for specific devices. You can find out more about the Android App Bundle in the official Android documentation.
Toggle the option for Android App Bundle to produce an .aab
in addition to the .apk
. If the build.gradle
(app level) file contains the android.bundle
block, this option will already be on.
When enabled, the version code in the AndroidManifest.xml of your app automatically increments for each build. The change happens during the actual build and won't be committed to your repository.
A successful build will produce an .apk
file and an additional .aab
file if enabled. To release the build to the Play Store, it needs to be signed with a valid certificate stored in a keystore. To sign the builds produced from a branch, enable code signing in the configuration pane, upload your keystore to your repository, and provide the relevant credentials in the configuration pane. You can read more about code signing in App Center's Android code signing documentation. The .aab
will be signed using the same credentials as the .apk
.
Use your newly produced APK file to test if your app starts on a real device. This adds approximately 10 more minutes to the total build time. Read more about how to configure launch tests.
3.7. Configure from the build.gradle (app level) File
Specific information about your build will be collected from your Gradle file including dependencies, build tools version, build types, and product flavors.
You can configure each successful build from a branch to be distributed to a previously created distribution group or a store destination. You can add a new distribution group or configure a store connection from within the Distribute service. There's always a default distribution group called "Collaborators" that includes all the users who have access to the app.
Note
If distributing to the Google Play Store, an Android App Bundle (.aab
) is preferred and will be distributed if enabled. For App Center distribution groups and Intune store destinations, a regular .apk
will be used even if an .aab
is also generated.
After a build is triggered, it can be in these states:
- queued - the build is in a queue waiting for resources to be freed up.
- building - the app is building and running related tasks.
- succeeded - the build is completed successfully.
- failed - the build completed, but it failed. You can download and inspect the build log for troubleshooting.
- canceled - the build was canceled by user action, or it timed out.
For a completed build (succeeded or failed), download the logs to understand more about how the build went. App Center provides an archive with the following files:
|-- 1_build.txt (this is the general build log)
|-- build (this folder contains a separate log file for each build step)
|-- <build-step-1>
|-- <build-step-2>
|--
|-- <build-step-n> (e.g. n_Post Job Cleanup.txt)
The build step-specific logs (located in the build/ directory of the archive) are helpful for troubleshooting and understanding in what step and why the build failed.
The APK is a package that contains the Android app and assets. If the build is correctly signed, the APK can be installed on a real device and deployed to the Play Store. If the build hasn't been signed, the APK can be run on an emulator or used for other purposes.
If your app configuration builds multiple APKs, you need to build a universal APK too. Our build system works with one main APK file and will ignore all APKs specific to a certain CPU ABI or screen density. To learn more about APK splits and building a universal APK, read the ABI split guide.
The mapping.txt
file contains information on how to map obfuscated stack traces for the app back to the original class and method names.
- If you've previously integrated the App Center SDK in your app with the crash reporting module enabled and use either Proguard or R8 to minify and obfuscate the app binary, the crash reporting service requires this
mapping.txt
file for a build to display human readable (deobfuscated) crash reports. - If you've previously integrated another SDK for crash reporting purposes in your app (for example, HockeyApp SDK), the corresponding service requires the
mapping.txt
file to display readable crash reports.
The minimum version supported to build Android apps is 7.0 (API level 24). Android apps can have a lower minimum API level required to run, but must target at least API level 24.
Apps must build with Gradle and the Android Gradle plugin to be configured correctly. Your repository needs to include a Gradle wrapper.
See also: Cloud Build Machine information