Develop Reference

Google Play services and WebView strange interaction

I have an app which uses Vision API from Google, and has a WebView which shows some internet content.
When the build.gradle file contains this line:
compile 'com.google.android.gms:play-services:8+'
everything compiles and work ok.
I want to use the latest version, so I change it to:
compile 'com.google.android.gms:play-services:9.6.1'
Then I hit the limit of 64K method references in a .dex file
Using multidex library and changing my manifest file, doesn't solve it.
So I tried the granular approach, and changed the line to:
compile 'com.google.android.gms:play-services-vision:9.6.1'
Then it compiles ok, but when running, every attempt to load a url in WebView,
fails and onReceivedError is called with errorCode -1.
I don't know if it is important, but the actual use of WebView, is done from a library which has nothing to do with Play Services.
Can somebody propose something?
Thank you

Then I hit the limit of 64K method references in a .dex file
Because it contains more than 56k methods.
com.google.android.gms:play-services-vision:9.6.1 is for Mobile Vision.
I can help you with getting over the 64 method limit though, do the steps below
But first make sure you have permission
<uses-permission android:name="android.permission.INTERNET" />
and active internet connection.
First put this in your buidl.gradle
dependencies {
compile 'com.android.support:multidex:1.0.1'
}
then put multiDexEnabled true
android {
compileSdkVersion 24
buildToolsVersion "24.0.1"
defaultConfig {
...
minSdkVersion 14
targetSdkVersion 24
...
// Enabling multidex support.
multiDexEnabled true
}
}
Then go to your menifest and in your application tag
<application
android:name="android.support.multidex.MultiDexApplication">
I hope it will resolve your problem.

Can I enable multidex in Android debug build only?

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);
}
}

May Proguard save going to multidex app ?

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

gradle - Android Studio build too slow multidex application

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.

Unable to open debugger port : java.net.SocketException “Socket closed”

I'm using Android Studio, with multiple flavors using Gradle, each with a Debug and Release type, organized as described here, on the bottom half.When I try to start the debugger, I get this error:
Error running androidRecover [installAppDebug]: Unable to open debugger port : java.net.SocketException "Socket closed
I'm also unable to attach the debugger to my device once it's running (it only displays the name of my phone, not the app).
All 3 flavors install on my phone just fine. I just can't get it to let me debug them. I also tested attaching the debugger on a Nexus tablet, and I got the same result.
It's not Gradle specifically as a whole because I can run other Gradle-based apps and attach the debugger just fine so I wonder if it's something with how I've setup my Gradle project and settings.
Here's my build.gradle:
apply plugin: 'android'
apply from: 'signing.gradle'
android {
compileSdkVersion 19
buildToolsVersion '19.0.3'
defaultConfig {
minSdkVersion 8
targetSdkVersion 19
}
buildTypes {
release {
runProguard false
proguardFiles getDefaultProguardFile
('proguard-android.txt'), 'proguard-rules.txt'
}
}
productFlavors {
flav1 {
packageName "com.ex.flav1"
versionCode 32
versionName "1.0.5"
signingConfig signingConfigs.flav1
}
flav2 {
packageName "com.ex.flav2"
versionCode 33
versionName "1.0.6"
signingConfig signingConfigs.flav2
}
flav3 {
packageName "com.ex.flav3"
versionCode 27
versionName "1.0.0"
signingConfig signingConfigs.flav3
}
}
}
dependencies {
compile 'com.android.support:appcompat-v7:19.+'
compile fileTree(dir: 'libs', include: ['*.jar'])
compile files('libs/httpmime-4.2.5.jar')
}
I really have no idea what else to try. Android Studio is completely up-to-date. I've restarted Android Studio, my phone, and my computer.
Also, last week I was having this problem, but it was a specific socket that was blocked, from trying to run the emulator and my phone at the same time. I also noticed I had multiple Gradle processes running, because it wasn't killing them on its own, which I often had to kill Android Studio to kill them. Once that was fixed, it was working off and on.
Let me know if you need any other info.
Thanks,
Devin
Edit I finally know why #hasanaydogar's answer works and why it probably would have solved my problem if we had known it then. See my 2nd comment on it to know why, but in short, you have to select in that dropdown the name that matches your app's root directory.

Just Click the button (left side the RUN button).
Select Android. Then Run.
It will connect to your device.
And dont forget to change build variant

I finally understand why I was getting that error so I'm going to explain how I Debug now. Note that I use Gradle (build multiple apk's using the same code), which might influence some how you use the third part of this answer.
For these to work, in the dropdown next to the debug (icon in #1) and run buttons in the top toolbar, you have to have the one selected with the following icon next to it because that's the name of the root directory of your app where all your code lives:
To start debugging from the beginning, I run the app in Debug mode from the start, using this button in your toolbar:
To attach the debugger to the app when it's already running as #scottyab mentioned, I click the Attach Debugger button in your toolbar:
To run the release version of my app in debug mode, I've started changing my strings in the Debug version of strings.xml in the file path myApp/src/appNameDebug(verses appNameRelease)/res/values/strings.xml, more easily seen here, on the bottom half. When I say change, I really mean that I have two versions of all the strings (3 in my case) necessary to change from using the debug server to using the release server. It might not be completely kosher, but it takes about 5 seconds to go the file, and hold down Cmd+/ and uncomment and comment all of the appropriate lines.
My Release version is just there for when I'm ready to build an apk for release.
Doing things in this way has eliminated that error popping up anymore. I think the Release version is just not made for debugging, and I haven't found an easy way to turn the debug flags on when in Release mode.

I managed to get this working by attaching the debugger after a build see Unable to open debugger port : java.net.SocketException "Socket closed"

I managed to get rid of this problem by killing & restart the adb process,hope this would help :]

I have solved this question with reference to the following SO Answer
The "Select Run/Debug Configuration" button in android studio 2.3.2
Change the Debug type to Native