I'm refactoring my current build.gradle to support both amazon and googleplay apks.
For that I've created 2 productFlavors (amazon and googleplay), so I can set some different dependancies and manifest.xml for each flavor.
During this refactor I came to an understanding that my current gradle didn't work well.
My goal is to get 4 build variants: debug/release-amazon/googlplay.apk.
When I build a debug I want only the current active ABI to be built, but if it's a release build , build all ABIs APKs.
I succeeded to get those variants. But build only current active ABI on debug only, doesn't work for me, because I couldn't get the value of active ABI from gradle.
I couldn't find this information on "Active ABI" on the internet, so this is why I'm asking here.
Related
I am using the following splits code in my gradle to reduce APK size:
splits {
abi {
// Enable ABI split
enable true
// Clear list of ABIs
reset()
// Specify each architecture currently supported by the Video SDK
include "armeabi-v7a", "arm64-v8a", "x86", "x86_64"
// Specify that we do not want an additional universal SDK
universalApk false
}
}
When I run the app, the APK is generated fine, with reduced size and runs on Emulator.
But when I try to build APK file from Build > Build bundles/apks like
I get this error:
Execution failed for task ':app:packageAbcDebug'.
> A failure occurred while executing com.android.build.gradle.tasks.PackageAndroidArtifact$IncrementalSplitterRunnable
> Could not find EOCD in '....apk'
Possible solution:
- Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html
I only wanted to exclude "x86" architectures, to reduce the APK size and need to send the APK to my client. How do I fix this?
I was running into a similar issue during my build process, though I wasn't enabling split. Take it for what you will.
After digging through the source kit for PackageAndroidArtifact and other sources in Android, I discovered "EOCD" means "End Of Central Directory". That is, it's related to the end marker of the zip file that gets built when building your output. (The link to the comments in Android's source kit.)
In my own case, I discovered that even though I'm asking Android Studio to do a complete clean of my build directory, it's leaving the app-debug.apk build artifact file. (For reasons, I'm trying to package the debug version of our APK for internal testing.) And somehow that file got corrupted, which completely confuses the build process.
The resolution was to manually delete the apk file prior to running the build process. (In my case, it was found in my build's app/debug directory, next to the app/build directory.)
G'figure...
May be its late but here is the solution with reason for it to work.
Since we are using splits to create apks for each architecture build system needs a different name for each apk being generated.
Best solution is to provide a dynamic way of generating apk names.
Just go to app level build.gradle file
Add rules for release/debug build variants in buildTypes block inside android block like this
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
applicationVariants.all { variant ->
variant.outputs.all { output ->
project.ext { appName = 'YourApkName' }
outputFileName = "${appName}-${output.getFilter(OutputFile.ABI)}-${variant.name}-${variant.versionName}.apk"
}
}
}
}
Explaination :
Here the apk name is appended by the ABI name that helps build system identify the apks for each architectures.
You can also use Android Size Analyze to identify sizes and reduces the apk size.
In order to understand which files are actually taking up more space in the application, use the Android Size Analyzer plugin inside Android Studio. For installing the plugin
Select File > Settings (or on Mac, Android Studio > Preferences.)
Select the Plugins section in the left panel.
Click the Marketplace tab.
Search for the “Android Size Analyzer” plugin.
Click the Install button for the analyzer plugin.
Restart the IDE after installing the plugin. Now, to analyze the application, go to Analyze > Analyze App Size from the menu bar.
I have a project A which has 3 B,C and D lib module.
Project A has 4 builtTypes Debug, Staging, Beta and Release but library modules has only debug and release. Now if I want one of my lib module consider C to have 3 buildTypes Debug, Staging and release. How can achieve this?
Go View > Tool Windows > Build Variants.
You can see all of modules with BuildVariants that are combination of BuildTypes and ProductFlavors, and select which type you want use for any module.
for example I define 2 flavors {production,staging} anly for app and remote modules and by default every module have 2 buildType named {debug,release}
and then you run app or install or build apk with selected configs
I use gradle splits to generate different apks for different architectures. However, based on the running "assemble(ABI)" I'd like to disable building some native libraries.
My question is, if I run:
gradle assembleMipsDebug
how can I get "assembleMipsDebug" or preferably "mips" from build.gradle script?
Even if you have splits enabled, there is no separate gradle task for each ABI. Still, you can provide different options for different splits.
You can choose the list of built libraries in your Android.mk or CMakeLists.txt script, or you can list the explicit targets in the externalNativeBuild block.
I have a project with three different build types: debug, beta, and release. My test package is always created for debug builds, but QA uses the beta build and we want QA to run these tests on their vast array of devices.
I'm trying to create a testing apk for QA that is signed by the same key as the beta build. Looking through the Android-Gradle documentation, I don't see anything telling me that I can't do this, but I don't see anyway to configure this. Is there anyway I can configure which keystore is used when assembling a test apk? Or is there a way to create an unsigned test apk?
You can now point this to a different target, I don't know when this happened, but from the docs:
Currently only one Build Type is tested. By default it is the debug
Build Type, but this can be reconfigured with:
android {
...
testBuildType "staging"
}
This is an incomplete answer to your question in that it documents what you can't do, but the connectedAndroidTest task, which is what runs the androidTest tests in your project, is hardcoded to run against the debug build type, and I don't see a way to point it at a different build type.
Taking the advice from Is there a way to list task dependencies in Gradle? and examining the task dependency tree, if you run:
./gradlew tasks --all
you get this in your output:
Verification tasks
------------------
app:check - Runs all checks. [app:lint]
app:connectedAndroidTest - Installs and runs the tests for Build 'debug' on connected devices. [app:assembleDebug, app:assembleDebugTest]
app:connectedCheck - Runs all device checks on currently connected devices. [app:connectedAndroidTest]
app:deviceCheck - Runs all device checks using Device Providers and Test Servers.
The documentation for the connectedAndroidTest task claims it runs tests against debug, and the task dependencies (which you see with the -all flag) confirm that the task depends on assembleDebug.
Adding additional build types and flavors doesn't seem to affect the dependency on the built-in debug type.
It's possible that with greater Gradle-fu than mine, you could rewire the tasks to make the tests depend on a different build type, but doing this is likely to be fragile since it's bound to depend on things that aren't supported API in the Android Gradle plugin.
To answer your question most directly, though, if all you want is to run tests against a build with a different certificate, you could change the signing config on your debug build to use the beta certificate:
android {
signingConfigs {
beta {
keyAlias 'key'
keyPassword 'password'
storeFile file('/path/to/beta_keystore.jks')
storePassword 'password'
}
}
buildTypes {
debug {
signingConfig signingConfigs.beta
}
beta {
signingConfig signingConfigs.beta
}
}
}
I tested it and I am able to run androidTest targets against debug builds that use a custom keystore in this way. However, I doubt this solves your problem, because I suspect you want to run your tests against the beta build, not a debug build with the beta certificate.
To add a testing source set for your build variant, follow these steps:
In the Project window on the left, click the drop-down menu and
select the Project view.
Within the appropriate module folder,
right-click the src folder and click New > Directory.
For the directory name, enter "androidTestVariantName." For example,
if you have a build variant called "MyFlavor" then the directory name
shoulbe "androidTestMyFlavor." Then click OK.
Right-click on the new directory and click New > Directory. Enter
"java" as the directory name, and then click OK.
Now you can add tests to this new source set by following the steps above to add a new test. When you reach the Choose Destination Directory dialog, select the new variant test source set.
The instrumented tests in src/androidTest/ source set are shared by all build variants. When building a test APK for the "MyFlavor" variant of your app, Gradle combines both the src/androidTest/ and src/androidTestMyFlavor/ source sets.
Another way is to put following line your in default config.
Currently only one Build Type is tested. By default it is the debug Build Type, but this can be reconfigured with:
android {
...
testBuildType "staging"
}
In my Android Studio project I have 2 flavours both having separate corresponding dependencies.
dependencies {
libflavour1Compile project(':TestLib1')
libflavour2Compile project(':TestLib2')
}
Building both of these flavours in debug works great, pulling in their respectful resources.
However, for both flavours debug and release urls are needed. To 'TestLib1' I added strings.xml to the release/res/values folder. Now the build is always inserting this release string to the debug build.
In Android Studio, selecting all build variants to be Debug still results in the release string being used even though the folder is not highlighted.
Creating a Debug build on the command line also has the same result.
./gradlew installLibflavour1Debug
Is there something I'm doing wrong here or do libraries always default to the Release build type?