I am trying to make Dexguard not stripping out logging functions when it is shrinking and obfuscating my code. I have therefore commented the following instruction in Dexguard configuration file:
-assumenosideeffects class android.util.Log {...}
Once this instruction is commented, build fails with the following error message :
Execution failed for task ':app:dexguardRelease'.
> Instruction has invalid constant index size ([699742] ldc_w #65536)
I have first thought that the problem was related to Android 64K limits but the build successes when dexguard is disabled or when it is enabled and set to strip out the logging functions.
Is it possible that dexguard has troubles obfuscating functions like Log.d() that can contain long strings as input arguments?
Thanks
You probably have lots of debug strings in this class in combination with an -encryptstrings ** directive.
This will lead to a large number of encrypted strings in a single class leading to errors as described in your post.
I would suggest that you revisit your -encryptstrings rules, and only encrypt the ones that are really sensitive.
Related
After adding a jar file containing some functionality that I need to my application, my proguard build hasn't been working. the error message I get after running my proguard build is:
Warning: Exception while processing task java.io.IOException: java.lang.RuntimeException: Unexpected error while writing class [proguard/optimize/gson/_OptimizedTypeAdapterFactory] (Overflow of unsigned short value [93362])
Thread(Tasks limiter_1): destruction
Is there any way to exclude that jar file from being checked by ProGuard? I'm using ProGuard v6.2.2. I suspected the issue would be GSON since i had issues with it before this error.
I've also checked and researched answers here such as Proguard [ java.lang.IllegalArgumentException: Overflow of unsigned short value ]
Android crash while using GSON Library and ProGuard
#732 Exception while handling very long string argument
Any help would be appreciated.
You can read more about ProGuard configuration and optimizations here:
https://www.guardsquare.com/en/products/proguard/manual/usage/optimizations
but in your case you can exclude the gson library that is throwing the exception like this:
-optimizations !library/gson
That's a known bug. Until this had been rectified, you can only disable the code optimization:
-optimizations !code/simplification/string
Or disable optimization altogether with -dontoptimize. Or just use R8 instead ...
That one linked answer which suggests a version-downgrade might also work.
After adding a library to project that contains native code (embedded as .so), my app build started to crash when running the dexguard<Flavor><BuildType> task.
The error says:
Caused by: java.io.IOException: Can't read [/home/user/project/app/build/intermediates/transforms/mergeJniLibs/flavor/buildType/folders/2000/1f/main(;;;;;;lib/*/*.so,lib/*/gdb*)] (Can't write resource [lib/x86/filecointainedonlibrary.so] (New string section exceeds the length of the original: 243 > 242))
That might happen when DexGuard obfuscates your native methods.
The latest version 7.1.29 should fix this issue, please give it a try.
Edit: The troubleshooting section of the DexGuard manual describes work-arounds when this happens. They basically keep names of native methods.
I hit this error and found no hits for the error message, so I thought I'd share the solution I came up with to save anyone else facing the problem repeating my work.
When writing a new Android library (apklib) for use in a (large) application, I'm getting the following error during dexing when I add my new project as a dependency:
trouble writing output: Too many field references: 70185; max is 65536.
You may try using --multi-dex option.
References by package:
<...long list of packages with field counts elided...>
The particular build step it fails on is:
java -jar $ANDROID_SDK/build-tools/19.0.3/lib/dx.jar --dex \
--output=$PROJECT_HOME/target/classes.dex \
<... long list of apklib and jar dependencies elided ...>
Using --multi-dex as recommended by the error message might be a solution, but I'm not the owner of the application project and it already has a large complex build process that I would hesitate to change regardless.
I can reproduce this problem with a no-op test library project that has literally no fields, but in the error output it's listed as having 6000+ fields. Of the packages listed in the error output, there are a handful with similar 6k+ field counts, but then the vast majority have more plausible <1k field counts.
This problem is similar to the "Too many methods" problem that Facebook famously hacked their way around. The FB solution seems insane, and the only other solutions I've found (e.g., this Android bug ticket, or this one, this SO answer, this other SO answer) all involve changing the main app's code which is well beyond the scope of what I want to do.
Is there any other solution?
The solution was to change the package in the AndroidManifest to match the main application's package.
A manifest like this:
<manifest package="com.example.testlibrary" ...
resulted in 6k+ fields and build failure. Changing it to match the main application's package
<manifest package="com.example.mainapplication" ...
resulted in the project building successfully.
Note that only the package in the manifest is changing, I did not make any changes to the library's Java source or its layout (the Java package was still com.example.testlibrary with directory structure to match).
I hypothesize that the different package name is causing all the Android fields to be included again under that package. All the packages in the error listing with 6k+ fields had a different package name than the main application.
I also (later, grr), found this blog post which details the same problem and the eventual same solution.
I'm currently building an android application using ANT on a Jenkins server.
DexGuard is set to run on release in the custom_rules.xml.
Currently there is an issue when DexGuard tries to convert a method:
[dexguard] Unexpected error while converting:
[dexguard] Class = [o/?]
[dexguard] Method = [?(Ljava/lang/String;)Lo/?;]
[dexguard] Exception = [java.lang.IllegalStateException] (Variable v17 too large for instruction [neg-int v17, v17])
[dexguard] java.lang.IllegalStateException: Variable v17 too large for instruction [neg-int v17, v17]
...
Stack trace
...
[dexguard] Not converting this method
My question is, is there a way to get DexGuard to exit with an error status so that either ANT or Jenkins can mark the build as failed?
At the moment it simply prints the stack trace and continues.
I am currently using the Text-finder plugin for Jenkins as a post build step to match a DexGuard exception. If found it downgrades the build to failed.
DexGuard currently ignores methods that it can't convert from Java bytecode to Dalvik bytecode, for any reason -- notably corrupt input code. In this case, it looks more like a bug in DexGuard itself. We'll fix it as soon as possible, and we'll consider adding a flag to stop with an error status.
(I am the lead developer of ProGuard and DexGuard)
I have an important problem while compiling Android Application.
Using Windev Mobile, it generates java code, compile and create apk, however, when the apk creation, an error happens:
command line: "myjavapath\java.exe" -Xmx1024m -Djava.ext.dirs=.\platform-tools\lib -jar .\platform-tools\lib\dx.jar --dex --output "path\classes.dex" "path\classes" "path\libs"
returned error:
Trouble writing output: No expanded opcode for 0004368d R.java:11#0001: invoke-direct v0:NffffLmynamespace/R$attr;, java.lang.Object.<init>:()v
Furthermore, R$attr in R.java contains nothing:
public static final class attr {
}
I assume there is a hard limit of 64k. But:
The R.java file contains only 364 lines, if these lines are
fields/methods references, I'm very far away from 64k hard limit.
This error happened when I add a specific window, in my Windev Mobile project. Window that I'm using in another project without error.
So, what do you think it comes from?
If you need any information, or document, no problem.
Thanks in advance.
PS: Maybe my english isn't perfect, I sorry for that.
There are various limits in the dex file format. It looks like the one you are encountering is that there can't be more than 64k method references. This limit is for all classes in your dex file, not for just a single class.
The fact that the error is occurring on that class has nothing to do with the class itself, that's just that where it happened to hit the limit.
The only solution currently, is to reduce the size of your code, or to split some classes out into a separate dex file that you load dynamically.