Supporting dex.force.jumbo=true

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I have a large app (actually our customer's) with more than 65k methods and 
build with dex.force.jumbo=true
2. When I use apktool to unpack, instrument, and repack, we lose the 
dex.force.jumbo=true flag
3. Android doesn't load the new new apk because of that.

What is the expected output? What do you see instead?
Trying to find where I can add this flag either to the tool or in the apktool 
source and build it

What version of the product are you using? On what operating system?
Latest verionfrom your website

Please provide any additional information below.

Original issue reported on code.google.com by codehe...@gmail.com on 3 Mar 2015 at 7:10

[GoogleCodeExporter]

I'm confused on this. When you build an application using that flag. You are 
passing that onto dx. I don't know if thats the real parameter or if Android 
Studio wraps "dex.force.jumbo=true" to something else for dx.

Either way, this forces all const-string opcodes to const-string/jumbo opcodes. 
This means when baksmali disassembles this dex, it should find those jumbo 
opcodes and handle them as such. Then when smali repacks the dex file, it 
should take those opcodes in there jumbo form without a problem.

You are saying this isn't true. I'm not strong in the background of the smali 
project at all. I will ask around and see, but I don't have an application 
laying around with more than 65k methods so won't be able to test this easily.

Original comment by connor.tumbleson on 3 Mar 2015 at 8:35

• Changed state: Waiting_For_Issuer

[GoogleCodeExporter]

Unfortunately I can't share my clients app here.  But, that's exactly what's 
happening.

dx has this option - --force-jumbo.  Works in post ginger bread versions.

If anyone can point me where I can add dx options in the smali project, I would 
really appreciate it.

Original comment by codehe...@gmail.com on 3 Mar 2015 at 8:39

[GoogleCodeExporter]

dx no longer supports the jumbo stuff, afaik. Neither does Android. It was only 
available in the platform for a very brief period. 

Original comment by bgruv@google.com on 3 Mar 2015 at 8:44

[GoogleCodeExporter]

Thanks. My comment #1 was an incorrect assumption.

It appears there are other methods to have applications greater than 65k 
methods. See link below.

https://developer.android.com/tools/building/multidex.html

Original comment by connor.tumbleson on 3 Mar 2015 at 8:47

• Changed state: Invalid

[GoogleCodeExporter]

Also, smali/baksmali no longer supports this, although if you get an older 
version, it should be able to handle it. I would suggest trying v1.4.3.

It's also worth noting that apktool doesn't use dx while rebuilding an 
application. It uses smali to reassemble the disassembled smali flies.

Original comment by bgruv@google.com on 3 Mar 2015 at 8:49

[GoogleCodeExporter]

Can we keep the issue open since there are ways to support 65K + methods in 
android in the latest versions?

Original comment by codehe...@gmail.com on 3 Mar 2015 at 8:53

[GoogleCodeExporter]

Just because it can, doesn't validate a reason for Apktool to do anything (in 
my 2c).

There was a huge amount of problems in old versions of Apktool trying to 
constantly make old apks "buildable" in newer build tools (apktool uses the 
newest aapt binary during every AOSP release). This was a never ending problem 
that only became more difficult on every new AOSP release.

The problem at hand here is an APK that was built on old tools. Apktool should 
not be responsible for  detecting 65k methods or using multidex or 
classes[1...n] methods.

Apktool can correctly take a "multidex`d" apk and decode/rebuild it properly. 
That was a bug here a couple months ago.

I don't think Apktool should be responsible for "fixing apks to make them 
correctly buildable". This is why I closed the issue.

Original comment by connor.tumbleson on 3 Mar 2015 at 9:00