Eclipse to Android Studio Import

Question

I am moving all my source codes to AS as suggested by Android official website. However, the experience is not very good. It is very sluggish as described here. But this is not my ultimate problem for now.

I have resolved many problems such as updating the compileSdkVersion to 23 so that 99 errors of this kind:

Error:(13) Error retrieving parent for item: No resource found that matches the given name 'android:TextAppearance.Material.Inverse'.

could be rectified. But the problems keep on shooting up as I go. Now I have this 64k Dex issue.

Error:The number of method references in a .dex file cannot exceed 64K. Learn how to resolve this issue at https://developer.android.com/tools/building/multidex.html

I never had this Dex issue while using Eclipse. The source code I have in AS is exactly the same as when it was in Eclipse. The only differences are those gradle changes needed only to work on AS. Any idea why this sudden Dex issue? if I set multiDexEnabled to true, what are the implications?

Unfortunately (and I know this isn't really helpful) the migration process is convoluted thanks in part to gradle and the project structure changes. Gradle is likely introducing the new "issue". I would recommend taking a look here https://developer.android.com/studio/build/multidex.html — zgc7009, Sep 22 '16 at 14:40
Take a look at your dependencies. I had run into the 64k dex issue on a project years ago and found I was including dependencies that were very large and didn't need all of it. I was a bit turned off by gradle and AS studio when I first started using it, but now that the later versions have hot deploy, I can make a UI code change, click the debug button and have it running on an emulator in a few seconds. Something that could never happen in Eclipse. — Gary Bak, Sep 22 '16 at 15:18
You might find this [article](https://mutualmobile.com/posts/dex-64k-limit-not-problem-anymore-almost) helpful which I think previous suggestions are drawing from. If you need to audit your project they created a [dexinfo gradle plugin](https://mutualmobile.com/posts/introducing-our-dexinfo-gradle-plugin) to help with that process. — light, Sep 29 '16 at 13:45

score 2 · Answer 1 · edited May 23 '17 at 11:55

First of all, make sure you rebuild project, after importing (Build - Clean, Builde - Rebuild Probject). Fixing this issue with limitation methods reference:

android {

    defaultConfig {
        ...

        // Enabling multidex support.
        multiDexEnabled true
    }
    ...
    }

  dependencies {
      compile 'com.android.support:multidex:1.0.0'
}

And also update you Application.class in java to support MultiDex. See full information here!

UPDATE:

This options ignore on Eclipse, because methods references limit can be calculated from environment (like AS in our case). Why this options doesn't include in Gradle build - still question...

Android application (APK) files contain executable bytecode files in the form of Dalvik Executable (DEX) files, which contain the compiled code used to run your app. The Dalvik Executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536—including Android framework methods, library methods, and methods in your own code. In the context of computer science, the term Kilo, K, denotes 1024 (or 2^10). Because 65,536 is equal to 64 X 1024, this limit is referred to as the '64K reference limit'.

Source AS Doc

do you know why this sudden Dex issue in AS? – user1506104 Sep 26 '16 at 10:31 — user1506104, Sep 26 '16 at 10:31
@user1506104 Updated question. – GensaGames Sep 26 '16 at 11:15 — GensaGames, Sep 26 '16 at 11:15

score 1 · Answer 2 · edited May 23 '17 at 12:02

Multidex issue occurs when you use lots of libraries in your project. If your app's code have more than 64k methods then it happens.

When your application and the libraries it references reach a certain size, you encounter build errors that indicate your app has reached a limit of the Android app build architecture.

You can refer some links like :

How to enable multidexing with the new Android Multidex support library

http://www.rapidvaluesolutions.com/tech_blog/multidex-issue-or-building-application-over-65k-methods/

https://mutualmobile.com/posts/dex-64k-limit-not-problem-anymore-almost

PaulR · Accepted Answer · 2016-10-01T14:42:22.207

I suspect your dex error is a result of the growth of a library, but without more info, this is hard to debug. The newest version of Android Studio (2.2) provides an APK analyzer tool that makes the dex limit more transparent.

When using Google Play services APIs you should double check to make sure that you're only including the ones used with these directives compile 'com.google.android.gms:play-services-fitness:9.6.1' rather than including everything (full list).

If you need all the libraries you're already depending on then, this is typically resolved by enabling multidex in your development environment (requiring development using a device or emulator with L or greater), but then using minificationEnabled in your release builds such that multidex isn't required in your release APK. This results in a combination of fast debug builds and non-multidex your release builds to prevent slow startup times for your release build.

A bit more info: When you use native multidex in debug builds (requires minSdk set to L or greater) it results in faster incremental builds because modules and libraries deploy as separate dex files and less processing between deploys.

When you use minificationEnabled in your release build it often eliminates the need for the second dex file because methods from your dependendencies that you don't use are trimmed. This typically results in a single dex nullifying the negative effects of multidex (copying the N+1 dex files on app initialization for < version L devices).

the best answer so far. (unless a better answers crops up in 22 hours, this answer deserves the bounty.) thank you. ;) — user1506104, Oct 01 '16 at 07:05

Eclipse to Android Studio Import

3 Answers3