When I add to my project the multidex:true, and make an Application class that extends from the MultiDexApplication, my project build time passed from 20 sec to around 90 sec.How to do some faster?
If you are like me who already tried Vic Vu's solution but still can't avoid enabling multiDex then you can try this (as long as your are using a device that has Android 5.0 and above).
Note This will only speed up your development build. Your production build will still be slow.
Basically you need to introduce 2 product flavors one for dev and one for prod.
Add multiDexEnabled true
android {
productFlavors {
// Define separate dev and prod product flavors.
dev {
// dev utilizes minSDKVersion = 21 to allow the Android gradle plugin
// to pre-dex each module and produce an APK that can be tested on
// Android Lollipop without time consuming dex merging processes.
minSdkVersion 21
}
prod {
// The actual minSdkVersion for the application.
minSdkVersion 14
}
}
...
buildTypes {
release {
runProguard true
proguardFiles getDefaultProguardFile('proguard-android.txt'),
'proguard-rules.pro'
}
defaultConfig {
applicationId "com.something.something"
targetSdkVersion 23
versionCode 1
versionName "1.0.0"
multiDexEnabled true
}
}
dependencies {
compile 'com.android.support:multidex:1.0.1'
}
And I have a class which extends Application so I had to override attachBaseContext()
#Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
If you are not extending Application simply use MultiDexApplication in your AndroidManifest.xml application tag.
Ensure that in your Android Studio Build Variants you are pointing to devDebug.
Read the complete instructions here https://developer.android.com/studio/build/multidex.html#dev-build
Supplying as an answer because this is better fit with the formatting.
To simply answer your question: No, there is no way. Multidex is a process meant to help lift the burden of the 65k method limit. This process is complicated and will simply make your build times longer.
The best you can can do is lower your method count.
In your build.gradle (supplied here) you're using:
`compile 'com.google.android.gms:play-services:8.3.0'`
But if you look at the most recent play services api you can pick and choose what services you actually need.
Look at Table 1 on this page.
Only use the ones you need. Google play services as a whole is somewhere around 30k methods.
That should help.
Multidexing uses more memory. As you get closer to your max heap size in Java you'll find Java spends more time doing GC than it does doing any real work, this can slow things down a lot.
I'd strongly recommend increasing the max heap size when using multidex. Add the following to the android closure in your build.gradle file to make the max heap size 4GB (Make it larger/smaller if you wish):
dexOptions {
javaMaxHeapSize "4g"
}
It depends.
You haven't specified it in your question, but if you just want to speed-up your development builds - then you can avoid the extra work. Official documentation includes a whole section about that.
Related
My Android app dumps files into Gdrive. It's using Oauth2.0 authentication and I've done the needful at console.developers.google.com. The problem I'm facing is that the app works fine on my Marshmallow phone but cannot get past the Google login on my JellyBean or lower. On these, the app gets stuck at the "Choose account for" window.
Studio's Android monitor returns the following:
GoogleApiClient connection failed: ConnectionResult{statusCode=SIGN_IN_REQUIRED, resolution=PendingIntent{419cbb80 ...
Keeping in mind that the app does work on the Marshmallow phone, my suspicion is that the issue is related to one of the "versions" in the app's build.grade file, an excerpt of which is below.
compileSdkVersion 23
buildToolsVersion "26.0.0"
defaultConfig {
applicationId "rudy.android.stgpro"
minSdkVersion 9
targetSdkVersion 18
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.rudykeystore
}
debug {
signingConfig signingConfigs.rudykeystore
}
}
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile 'com.android.support:appcompat-v7:23.0.1'
compile 'com.google.android.gms:play-services-drive:8.4.0'
}
Or, maybe, Oauth2.0 does not work with earlier Android versions.
I also notice that the size of the app loaded into Marshmallow is about 40% the size of that loaded into the other two phones.
Google's Drive app works fine on all phones.
I've googled around for hours now and am, pretty much, stuck. Any suggestions?
After much "blood, sweat and tears", I've discovered that the problem lay in a single line in the AndroidManifest.xml file ...
android:launchMode="singleInstance"
I have no clue why this line affects phones running JellyBean and lower but not Marshmallow (not sure about Kitkat & Lollipop). And, just to be clear, the line literally toggles the problem with its presence/absence (with zero other changes).
I zeroed in on the problem using Drives's Quickstart as a base (its connection worked with all my test phones), then gradually modifying its code by adding/removing from my app's code (took me a couple of days).
Anyway, thank goodness for these working samples.
Dears,
I read in many blog posts that multidex apps startup is slower than normal apps.
My app uses a lot of libraries that exceed 64k methods so I use multidex. But when I use proguard in release build, the final apk becomes less than 64k methods
So My question is: Can I enable multidex in Android debug build only so I don't have runtime error? and disable multi dex in release build as I don't need it?
If yes, how ?
If No, Is Android smart enough to speedup startup as it should recognize that app didn't exceed 64k even if it is multi dex app ?
Yes, you can. When you declare your buildTypes include multidex only for debug:
buildTypes {
release {
multiDexEnabled false
}
debug {
multiDexEnabled true
}
}
Instead of enabling multidex only for debug, you can change your min sdk version to 21 only for debug so gradle can speed up dexing with ART:
android {
productFlavors {
// Define separate dev and prod product flavors.
dev {
// dev utilizes minSDKVersion = 21 to allow the Android gradle plugin
// to pre-dex each module and produce an APK that can be tested on
// Android Lollipop without time consuming dex merging processes.
minSdkVersion 21
}
prod {
// The actual minSdkVersion for the application.
minSdkVersion 14
}
}
...
buildTypes {
release {
runProguard true
proguardFiles getDefaultProguardFile('proguard-android.txt'),
'proguard-rules.pro'
}
}
}
dependencies {
compile 'com.android.support:multidex:1.0.0'
}
http://developer.android.com/tools/building/multidex.html
suggested methods are not needed anymore as android studio became "smart enough".
In fact, it will now give you a warning when you use minSdkVersion 21 (the old way) to speed up build time with dex:
You no longer need a dev mode to enable multi-dexing during
development, and this can break API version checks less...
In the past, our documentation recommended creating a dev product
flavor with has a minSdkVersion of 21, in order to enable multidexing
to speed up builds significantly during development. That workaround
is no longer necessary, and it has some serious downsides, such as
breaking API access checking (since the true minSdkVersion is no
longer known.) In recent versions of the IDE and the Gradle plugin,
the IDE automatically passes the API level of the connected device
used for deployment, and if that device is at least API 21, then
multidexing is automatically turned on, meaning that you get the same
speed benefits as the dev product flavor but without the downsides.
Yes, it even works with the multidex support library for Android versions prior to Lollipop with a little trick.
First specify multiDexEnabled for the debug build in build.gradle:
buildTypes {
...
debug {
...
multiDexEnabled true
}
}
Then create an AndroidManifest.xml file under src/debug.
src/debug/AndroidManifest.xml:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<application
android:name="android.support.multidex.MultiDexApplication"
tools:replace="android:name"/>
</manifest>
That should do the trick. If your app uses a custom application class then you have to create a subclass of your application class and specify the name of that subclass in the manifest.
The application subclass should look like this:
public class MyDebugApplication extends MyApplication {
#Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
}
I have an app with a few libs, that reached the red-line of 65536 method count.
I achieved to setup the app as an multidex APK.
For size optimisation, I decided to use Proguard, because I just use a few feature of Guava and common.java.lang, and those libs bring their whole family with them.
After Proguard job, my app ref ~ 45 Kmethods
I often read that multidex app may crash time to time
And that because of second-dex runtime loading, this take time.
Does 4 and 5 are true ?
Then I just tried to not using mutidex, because my end methods count is < 56Kmethods with prodGuard, but it failed as if it has more !
To do so, I just put the gradle parameter multiDexEnabled to false
Is there something else to check/do ?
Here is a part of my Gradle :
android {
compileSdkVersion ANDROID_BUILD_SDK_VERSION
buildToolsVersion ANDROID_BUILD_TOOLS_VERSION
defaultConfig {
applicationId "XXXX"
targetSdkVersion ANDROID_BUILD_TARGET_SDK_VERSION
minSdkVersion ANDROID_BUILD_MIN_SDK_VERSION
versionCode ANDROID_BUILD_VERSION_CODE
versionName ANDROID_BUILD_APP_VERSION_NAME
// Enabling multidex support.
multiDexEnabled false
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
debuggable false
ext.enableCrashlytics = true
renderscriptOptimLevel 3
signingConfig android.signingConfigs.release
zipAlignEnabled true
minifyEnabled true
// shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro', 'proguard-rules-new.pro', 'proguard-rules-eventbus.pro', 'proguard-rules-firebase.pro', 'proguard-rules-fabric.pro', 'proguard-rules-leakcanary.pro'
}
debug {
debuggable true
renderscriptOptimLevel 3
applicationIdSuffix ".debug"
versionNameSuffix "debug"
}
}
I often read that multidex app may crash time to time
From the android developers documentation page (http://developer.android.com/tools/building/multidex.html#limitations):
Applications using a multidex configuration that make very large
memory allocation requests may crash during run time due to a Dalvik
linearAlloc limit (Issue 78035). The allocation limit was increased in
Android 4.0 (API level 14), but apps may still run into this limit on
Android versions prior to Android 5.0 (API level 21)
ART has built in support for multi-dex apks, so multi dexing should not cause any problems in lollipop and above. You may see issues on some devices running kitkat and below, although this should be rare unless you have a very high method count or memory requirements.
And that because of second-dex runtime loading, this take time.
Yes, multidex does slow down the very first start-up time of your app significantly. (upto 200% in case of yelp, when they went 20k methods above the limit) Even cold-start times increase.
Hence, if you can avoid multi-dexing, it is strongly recommended that you do so.
Even if you go above the limit, you should still try to minimize the method count as more and more methods slow down the app startup time on pre-lollipop devices.
In your case, if your build succeeded but if you're seeing run-time crashes (especially such as "No Class def. found") then it could be that you haven't configured proguard correctly, and it may be striping away some required components.
Timothy Meller from yelp has given a detailed talk on this issue, in which he also shares some multi-dex optimizations and the importance of proguard configurations:
https://www.youtube.com/watch?v=skmOBriQ28E
I'd recommend you watch this if you want a better understanding of multi-dexing on android
My project has 2 different groups of tests. One group runs only with the default AndroidJUnitRunner the other has to be run with a custom implementation TestRunner extends MonitoringInstrumentation.
Currently I switch the testInstrumentationRunner by editing the build.gradle each time I need to run the other group of tests:
android{
defaultConfig {
//testInstrumentationRunner "my.custom.TestRunner"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
}
I know that flavours can have their own testInstrumentationRunner but my current app already has 2 flavourDimensions. Using flavours is actually intended to have different versions of an app. I need 2 versions of the test application, both testing the same app with different testInstrumentationRunners.
I tried to change the testInstrumentationRunner by iterating over all test variants. There are actually multiple testInstrumentationRunner properties:
android.testVariants.all { TestVariant variant ->
//readonly
variant.variantData.variantConfiguration.instrumentationRunner
variant.variantData.variantConfiguration.defaultConfig.testInstrumentationRunner
}
But as soon as android.testVariants is called the build gets configured and all changes are not reflected in the build.
How can I change the testInstrumentationRunner (from a gradle plugin) dynamically?
I'd prefer to have 2 different gradle tasks, each using a different testInstrumentationRunner but testing the same variant. Because I intent to create a gradle plugin the solution should work as plugin too.
Have you considered using console parameter as a switch between two configurations? As simple as that:
android {
defaultConfig {
if (project.ext.has("customRunner")) {
testInstrumentationRunner "my.custom.TestRunner"
} else {
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
}
}
And then for example run gradlew aDeb -PcustomRunner if you want to test using custom runner or gradlew aDeb to use default.
I know it's not rocket science but simpler is better, right? You can use it in your plugin too, just obtain the Project object and do the similar thing.
Since the android gradle plugin 1.3 it is possible to create separate test modules. Each of those test modules can have its own testInstrumentationRunner.
For a detailed example see the AndroidTestingBlueprint example project on github.
The solution from #johan-stuyts that got bounty works fine (or at least it did with the android gradle plugin 1.2). But it uses private APIs and creating a separate module is easier and future proof.
I had a similar issue, I used gradle's taskGraph. Based on your statement "My project has 2 different groups of tests." I'm going to assume you have different tasks defined, I'll call them testGroupOne and testGroupTwo:
task testGroupOne{
}
task testGroupTwo{
}
gradle.taskGraph.whenReady {taskGraph ->
if(taskGraph.hasTask(testGroupOne)){
testInstrumentationRunner "my.custom.TestRunner"
} else if (taskGraph.hasTask(testGroupTwo)){
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
}
This enables you to set the value of testInstrumentationRunner after configuration but before execution.
This is a partial solution, but maybe this will make things a bit less cumbersome for you: It does not allow you to run the tests with both test runners in the same build. If you want that you would have to clone all task instances of DeviceProviderInstrumentTestTask, which, in my opinion, is too complex and fragile.
This works for me (Gradle 2.4 and Android build tools 1.2.3). It uses internal APIs, so it is possible that this no longer works with the next release of the Android build tools.
You should modify the tasks generated by the Android plug-in after the project has been evaluated. The changes will then be used by the test tasks. The property that actually changes the used test runner is task.testVariantData.variantConfiguration.testedConfig.mergedFlavor.testInstrumentationRunner. Instead of making these changes during the configuration phase (i.e. outside a task), the changes are applied using a task, so your test runner is only used when requested. By forcing the test tasks to run after useMyTestRunner (if the latter is part of the build), the class name of the test runner will have been changed when a test task starts:
project.afterEvaluate {
task useMyTestRunner << {
tasks.withType(com.android.build.gradle.internal.tasks.DeviceProviderInstrumentTestTask.class) { task ->
task.testVariantData.variantConfiguration.testedConfig.mergedFlavor.testInstrumentationRunner = 'com.mycompany.MyTestRunner'
}
}
tasks.withType(com.android.build.gradle.internal.tasks.DeviceProviderInstrumentTestTask.class) { task ->
task.mustRunAfter useMyTestRunner
}
}
You can now run the tests using the default test runner configured for the flavor(s) with:
gradle :myApp:connectedAndroidTest
When you want to run the tests with your test runner use:
gradle :myApp:connectedAndroidTest :myApp:useMyTestRunner
I did not add checks for null for any of the properties retrieved using task.testVariantData.variantConfiguration.testedConfig.mergedFlavor.testInstrumentationRunner. You should add them for robustness. I think at least testedConfig needs attention. See getInstrumentationRunner() at https://android.googlesource.com/platform/tools/build/+/master/builder/src/main/java/com/android/builder/VariantConfiguration.java
You can use an import for com.android.build.gradle.internal.tasks.DeviceProviderInstrumentTestTask at the top of your build file, so you only have to use the simple name of the class.
Say I have a production version com.android.xyz and this is production
then I am developing something and i want to load both this version and the production version on my phone so it's side by side. I know I can create a new package like com.android.abc and then I would have a second app which is basically a clone of com.android.xyz.
Thoughts?
Thanks in advance,
Reid
IF you are using Android Studio with Gradle, there is an easy way to do this. I still keep the the same packageName in AndroidManifest.xml (at least current gradle needs this duplicate definition)
AndroidManifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:installLocation="internalOnly"
package="com.android.xyz">
build.gradle
def devBuildName = "dev"
def testBuildName = "test"
android {
defaultConfig {
versionCode 70
versionName "2.2.3"
minSdkVersion 10
targetSdkVersion 19
packageName "com.android.xyz"
}
buildTypes {
debug {
packageNameSuffix "."+devBuildName
versionNameSuffix "-"+devBuildName.toUpperCase()
}
test.initWith(buildTypes.debug)
test {
packageNameSuffix "."+testBuildName
versionNameSuffix "-"+testBuildName.toUpperCase()
}
}
}
You can look at my full dev/release example at github.
You need to change the package name. IMO the easiest way to do this is by writing a perl/python script to iterate through the files and change the package name based on the build type. Or run a C style macro preprocessor over the files first.