I am successfully generating signed APKs in Android studio, splitting them by ABI and assigning a different versionCode for each, by adding the following code to my build.gradle file:
// Map for the version code that gives each ABI a value.
ext.abiCodes = ["armeabi-v7a":1, "arm64-v8a":2, "x86":3, "x86_64":4]
import com.android.build.OutputFile
// For each APK output variant, override versionCode with a combination of
// ext.abiCodes + variant.versionCode. In this example, variant.versionCode
// is equal to defaultConfig.versionCode. If you configure product flavors that
// define their own versionCode, variant.versionCode uses that value instead.
android.applicationVariants.all { variant ->
// Assigns a different version code for each output APK
// other than the universal APK.
variant.outputs.each { output ->
// Stores the value of ext.abiCodes that is associated with the ABI for this variant.
def baseAbiVersionCode =
// Determines the ABI for this variant and returns the mapped value.
project.ext.abiCodes.get(output.getFilter(OutputFile.ABI))
// Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes,
// the following code does not override the version code for universal APKs.
// However, because we want universal APKs to have the lowest version code,
// this outcome is desirable.
if (baseAbiVersionCode != null) {
// Assigns the new version code to versionCodeOverride, which changes the version code
// for only the output APK, not for the variant itself. Skipping this step simply
// causes Gradle to use the value of variant.versionCode for the APK.
output.versionCodeOverride =
baseAbiVersionCode + variant.versionCode
}
}
}
Now, I want to use ProGuard (minifyEnabled true) to obfuscate my code. As stated in the official android documentation, it is important to keep the mapping.txt files for each APK you release in order to decrypt a crash report's obfuscated stack trace received via the Google Play Developer Console. But when I generate the APKs split by ABI, I only find one mapping.txt file in the <module-name>/build/outputs/mapping/release/ directory.
My question: Could someone please confirm that this single mapping.txt file will allow me to decode obfuscated stack traces for the 4 APKs which were split by ABI? If not, how can I generate the 4 different mapping files?
I tried generating the different mapping files based on a snippet I found in this post, essentially trying to copy and rename the mapping.txt files as they are created during the multi APK generation process but I still only get one single mapping file:
applicationVariants.all { variant ->
if (variant.getBuildType().isMinifyEnabled()) {
variant.assemble.doLast {
copy {
from variant.mappingFile
into "${rootDir}/proguardTools"
rename { String fileName ->
"mapping-${variant.name}.txt"
}
}
}
}
}
I am very new to gradle and I find its syntax quite confusing. Any help would be very much appreciated.
I ended up testing the stack trace deobfuscation with Firebase Crash Reporting (i.e. without having to deploy a crash test version of my app to the google play store) and I can confirm that the one mapping.txt file created when generating the signed APKs in Android Studio does correctly deobfuscate stack traces for crashes occurring on APKs corresponding to different ABI types.
Related
I'm trying to bend firebase app distribution to work with apk splits.
I almost have it, however my issue is this
Could not find the APK. Make sure you build first by running ./gradlew assemble[Variant],
or set the apkPath parameter to point to your APK
My task
task firebaseAllEnvRelease() {
group = "publishing"
dependsOn ordered(
":printVersionCode",
":foo:app:assembleAllRelease"
":foo:app:firebasePublishAllEnvRelease")
}
For whatever reason, the firebase task runs the apk check (not upload) beforehand, before assemble, so obviously the apk is not there -- how can I force it to respect the order of tasks?
I know gradle creates the tasks graph hopwever it likes, but I do have a utility ordered for what, which chains them via mustRunAfter and it is for sure correct.
Plan b is to run the assemble ina separate gradlew command before that, that works but -- why :/
The problem is that the gradle plugin
doesn't declare dependency on assemble task (in general, regardless of apk splits, by gradle convention, you shouldn't just "expect" the apks to be there)
doesn't generate tasks per apk splits -- but you do for flavors
So here is the work around for it:
// Generate firebase app distribution task variants for all abis
applicationVariants.all { variant ->
variant.outputs.all { output ->
def abi = output.getFilter(com.android.build.OutputFile.ABI)
if (abi == null) return
def abiName = abi.replace("_", "").replace("-", "")
task("appDistributionUpload${abiName.capitalize()}${variant.name.capitalize()}", type: com.google.firebase.appdistribution.gradle.UploadDistributionTask_Decorated) {
appDistributionProperties = new com.google.firebase.appdistribution.gradle.AppDistributionProperties(
new com.google.firebase.appdistribution.gradle.AppDistributionExtension(),
project,
variant
)
appDistributionProperties.apkPath = output.outputFile.absolutePath
appDistributionProperties.serviceCredentialsFile = project.file("secrets/ci-firebase-account.json")
appDistributionProperties.releaseNotes = abi
appDistributionProperties.groups = "ra-testers"
// Add dependsOn respective assemble task, so it actually
// builds apk it wants to upload, not just expect it to be there
dependsOn "assemble${variant.name.capitalize()}"
}
}
}
In order to improve our QA workflow, we want to automatically build an APK file for each pull-request on Github so we can test it BEFORE the branch is merged. We already figured out how to build the file, but we are now wondering how to integrate this in our workflow.
It seems like most available Beta programs (e.g. Crashlytics Beta, Google Play) mostly focus on creating one beta version shortly before the release, but don't allow hosting multiple APKs in parallel.
Here's an example for our ideal workflow:
Developer finishes coding and creates a pull-request
Tests run
If tests are successful, an APK is built automatically and uploaded somewhere (that's the part we're trying to figure out)
QA takes a look at the pull-request and should be able to easily download the correct APK on their testing device
If there are no issues during QA, the pull-request is merged
The APK file is automatically deleted
We specifically don't want to test the APK after the pull-request has been merged, but instead test before so less bugs pop up in our develop branch.
Actually Crashlytics allow to have several versions of APK.
Ech version can have each own Version string and of course release notes, to help QA to find correct APK.
Point 3 from question can be described in that way:
CI configured to upload build to Crashlytics.
It can be achieved by gradle task:
gradle assembleRelease crashlyticsUploadDistributionRelease
It is really useful to have special build type (pullrequest) for this case. You can specify special distribution rules via distribution groups, notifications about builds and release notes.
build.gradle:
//example function for change log
def getLastGitCommitMessage() {
try {
"git log -1 --pretty=%B".execute().text.trim()
} catch (e) {
'Undefined message.'
}
}
android {
buildTypes {
...
pullrequest {
//invitation
ext.betaDistributionGroupAliases = "QA, devs"
// notification
ext.betaDistributionNotifications = true
// last commit message as release notes
ext.betaDistributionReleaseNotes = getLastGitCommitMessage()
}
}
}
In this case build and upload command will be like that:
gradle assemblePullrequest crashlyticsUploadDistributionPullrequest
There is a lot of ways to achieve it. But in my opinion the best way is to create next stage that will produce apk as artefact and later your QA team will be able to download apk on device and test it. As anaxad wrote you can also send apk file using mail and distribution list. But such solution will be more difficult, because you need to create task (e.g. using docker) that will send mail with apk.
Make your system the server.
After that at the time of generate APK, Give your server path.
If you do like this then every time your apk will update,
So you need to use one variable? Which will decide your apk deploy on your local server or not.
After finish your development, make it true and then your apk will copy on your local server. Then it is easily accessible to QA team.
Follow this question.
Some demo code.
debug {
applicationVariants.all { variant ->
variant.outputs.each { output ->
def apk = output.outputFile;
def newName;
newName = apk.name.replace("-" + variant.buildType.name, "")
.replace(project.name, name);
newName = newName.replace("-", "-" + version + "-" + milestone +
"-" + build + "-");
output.outputFile = new File(apk.parentFile, newName);
}
}
}
We included this AndroidPdfViewer library to support viewing of PDF reports in the app. It lead to massive increase in APK size from 4.7Mb to 20.1Mb .
Is there a way to reduce this size. Let me know where and what to tinker around to help or solve this.
I am familiar with proguard and have it configure for my app with reasonable success.
Why resulting apk is so big?
As stated in the documentation by barteksc/AndroidPdfViewer
Android PdfViewer depends on PdfiumAndroid, which is set of native
libraries (almost 16 MB) for many architectures. Apk must contain all
this libraries to run on every device available on market.
Fortunately, Google Play allows us to upload multiple apks, e.g. one
per every architecture. There is good article on automatically
splitting your application into multiple apks, available here.
Most important section is Improving multiple APKs creation and
versionCode handling with APK Splits, but whole article is worth
reading. You only need to do this in your application, no need for
forking PdfiumAndroid or so.
API: https://github.com/barteksc/AndroidPdfViewer
You have to generate Multiple APKs for different devices, by doing this you can reduce the size of apk up to 10 MB less than previous. Add below code to build.gradle (Module:App)
android{
.....
splits {
abi {
enable true
reset()
include 'x86_64', 'x86', 'armeabi', 'armeabi-v7a', 'arm64-v8a', 'mips'
universalApk false
}
}
.....
}
ext.versionCodes = ['armeabi': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3, mips: 4, 'x86': 5, 'x86_64': 6]
import com.android.build.OutputFile
// For each APK output variant, override versionCode with a combination of
// ABI APK value * 1000 + defaultConfig.versionCode
android.applicationVariants.all { variant ->
// assign different version code for each output
variant.outputs.each { output ->
output.versionCodeOverride =
project.ext.versionCodes.get(output.getFilter(OutputFile.ABI)) * 1000 + android.defaultConfig.versionCode
}
}
Whatch video here https://youtu.be/bP05Vpp49hs for detail explanation on how to do it.
If anyone is looking for a lightweight pdf viewer for your app, then try this one
Use this library
It helped me to reduce the app size from 27MB to 10MB because of the barteksc-androidpdfviewer requires more space
I also faced the same problem, but this is very easy as of now to reduce the apk sizes by using android app bundles.
Firstly in build.gradle(Module: app) add these lines inside android { } brackets.
bundle {
abi {
enableSplit = true
}
}
This will handle apk splits on the basis of architecture.
Now, also remember to add this line in proguard-rules.pro
-keep class com.shockwave.**
If you will not add this line in proguard-rules.pro then your app will crash in release version.
Now, after this go to Build and then select, Generate Signed Bundle/apk. From here, generate a signed bundle. Bundles are generated in very same way, as the apk's are generated.
Then, upload your bundle(.aab file) on Google Play Console and you will see that every device gets different apks depending upon their architecture.
This is the most easiest way to reduce the app size.Multiple apk concept is more complicated.
So,I suggest you to use this way.
I have been using gradle for creating different build variants for different companies for an Android app.
For example I have build flavors:
Company1
Company2
And then I have build types:
Production
Preview
Development
So this will create 6 build variants:
Company1Production
Company1Preview
Company1Development
Company2Production
Company2Preview
Company2Development
So the question is:
Actually I don't need the development build type for company 2, I only need it for company 1.
Is there a way I can specify only company 1 have the development build type?
I have a lot of companies in my projects, some of the build type just don't make sense for those companies, and it confuses people who want to build the app.
To answer my own question, I have found the documentation on the Gradle Plugin User Guide
Filtering Variants
When you add dimensions and flavors, you can end up with variants that don't make sense. For example you may define a flavor that uses your Web API and a flavor that uses hard-coded fake data, for faster testing. The second flavor is only useful for development, but not in release builds. You can remove this variant using the variantFilter closure, like this:
android {
productFlavors {
realData
fakeData
}
variantFilter { variant ->
def names = variant.flavors*.name
if (names.contains("fakeData") && variant.buildType.name == "release") {
variant.ignore = true
}
}
}
With the configuration above, your project will have only three variants:
realDataDebug
realDataRelease
fakeDataDebug
You can't stop the Android plugin from creating the matrix of all builds, but you can cause the build to fail if it's not valid. For example, if you don't want Flavor2 Debug builds to work, you can stop them like this:
afterEvaluate {
tasks['prepareFlavor2DebugDependencies'].doFirst {
throw new IllegalArgumentException("This project is not valid")
}
}
This is self-answered question to share my knowledge.
I have a project with multiple product flavors and I want to integrate Fabric using separate organizations for each product flavor.
I tried to integrate Fabric using Android Studio Fabric Plugin. It adds
<meta-data
android:name="io.fabric.ApiKey"
android:value="DEFAULT_ORGANIZATION_API_KEY" />
entry to AndroidManifest.xml of main source set.
I decided to rewrite this entry in application variant specific source sets:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<application>
<meta-data
android:name="io.fabric.ApiKey"
android:value="SECOND_ORGANIZATION_API_KEY"
tools:replace="android:value" />
</application>
</manifest>
Then I discovered that Fabric Gradle plugin generates crashlytics.properties file with fabric api secret (AKA build secret) during build and I should include this file to source control. But this file is overwritten each time I build specific application variant because api secret is unique for each application.
How can I integrate Fabric using separate organizations for each application variant?
During the build fabricGenerateResources task is called and it looks for a file named fabric.properties with following content:
apiSecret=YOUR_BUILD_SECRET
apiKey=YOUR_API_KEY
So all we need is to generate fabric.properties file before this.
I found this solution and slightly modified it to fully support application variants not only build types.
Add this code to android section of build.gradle:
File crashlyticsProperties = new File("${project.projectDir.absolutePath}/fabric.properties")
applicationVariants.all { variant ->
variant.productFlavors.each { flavor ->
def variantSuffix = variant.name.capitalize()
def generatePropertiesTask = task("fabricGenerateProperties${variantSuffix}") << {
Properties properties = new Properties()
properties.put("apiKey", flavor.fabricApiKey)
properties.put("apiSecret", flavor.fabricApiSecret)
properties.store(new FileWriter(crashlyticsProperties), "")
}
def generateResourcesTask = project.tasks.getByName("fabricGenerateResources${variantSuffix}")
generateResourcesTask.dependsOn generatePropertiesTask
generateResourcesTask.doLast {
println "Removing fabric.properties"
crashlyticsProperties.delete()
}
}
}
It iterates over application variants and for each application variant creates task that generates fabric.properties file and task that deletes this file after Fabric Gradle plugin generates application resources.
All you need now is to define product flavor or build type specific fabricApiKey and fabricApiSecret:
productFlavors {
flavor1 {
ext.fabricApiKey = "FLAVOR1_API_KEY"
ext.fabricApiSecret = "FLAVOR1_API_SECRET"
}
}
ext is an ExtraPropertiesExtention object provided by every ExtensionAware object. It allows new properties to be added to existing object. In my case flavor1 is ExtensionAware object and it can be extended with new properties by using ext.someProperty = "value" syntax and later these properties can be used as flavor.someProperty, flavor.fabricApiKey.
Also it's better to include fabric.properties to .gitignore.
And do not forget to remove ext.enableCrashlytics = false from debug build type if you used it to disable Crashlytics during debug. Instead of this you can disable it in Application.onCreate:
Fabric.with(this, new Crashlytics.Builder().core(
new CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build()).build());
If you're not opposed to using an application id suffix, you don't need separate organizations. The crashes and answers will be treated as separate apps.
For instance, let's say my application id is io.example
In your build.gradle:
buildTypes {
debug {
applicationIdSuffix ".debug"
}
release {
//options
}
}
After you deploy the debug version to a device or emulator, on the Fabric site you will see two apps:
io.example
io.example.debug
One thing that is nice about this approach is that you can also keep track of other build flavors seprately: io.exmaple.free, io.exmaple.paid, io.example.exterprise, and so on.
A simpler solution, which is also compatible with Gradle 5.x+ is to create separate fabric.properties files for each of the build variants that needs a unique Fabric API key and secret. Create the fabric.properties files as:
#Contains API Secret used to validate your application. Commit to internal source control; avoid making secret public.
apiSecret=YOUR_API_SECRET
apiKey=YOUR_API_KEY
replacing YOUR_API_SECRET with the build variant's API secret and YOUR_API_KEY with the build variant's API key.
Then place each variant's fabric.properties under the project src/variant folder, e.g. app/src/debug or app/src/release. See documentation on build variants for additional details.
At build time, the fabric.properties for the variant being built will be used.