Crash with proguard

Crash with proguard

Hi there,

I don't know if this problem is in MOE or libGDX, so I'm posting it here, too:

I'm using the default proguard.cfg from MOE. This cfg already contains
-keepattributes InnerClasses
-keep class com.badlogic.** { *; }
-keep enum com.badlogic.** { *; }

But these entries only make sense if the obfuscater is used (at least I think so), so I was surprised that the default configuration has the option "-dontobfuscate". However, when I enable the obfuscater (comment out the "-dontobfuscate"), I get the following error when the app starts:

art E 310 22229 /teamcity/workdir/moe_repo_build/moe_repo/art/runtime/java_vm_ext.cc:255] No implementation found for com.badlogic.gdx.backends.iosmoe.objectal.OALSimpleAudio com.badlogic.gdx.backends.iosmoe.objectal.OALSimpleAudio.sharedInstance() (tried Java_com_badlogic_gdx_backends_iosmoe_objectal_OALSimpleAudio_sharedInstance and Java_com_badlogic_gdx_backends_iosmoe_objectal_OALSimpleAudio_sharedInstance__)
java.lang.UnsatisfiedLinkError: No implementation found for com.badlogic.gdx.backends.iosmoe.objectal.OALSimpleAudio com.badlogic.gdx.backends.iosmoe.objectal.OALSimpleAudio.sharedInstance() (tried Java_com_badlogic_gdx_backends_iosmoe_objectal_OALSimpleAudio_sharedInstance and Java_com_badlogic_gdx_backends_iosmoe_objectal_OALSimpleAudio_sharedInstance__)
at com.badlogic.gdx.backends.iosmoe.objectal.OALSimpleAudio.sharedInstance(Native Method)
at com.badlogic.gdx.backends.iosmoe.IOSAudio.<init>(Unknown Source)
at com.badlogic.gdx.backends.iosmoe.IOSApplication.didFinishLaunching(Unknown Source)
at com.badlogic.gdx.backends.iosmoe.IOSApplication$Delegate.applicationDidFinishLaunchingWithOptions(Unknown Source)
at ios.uikit.c.UIKit.UIApplicationMain(Native Method)

I don't understand why I'm getting this error.
Is there any proguard setting I've missed?

Thanks in advance.

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I've found the solution:

The default MOE cfg had:
-keepattributes InnerClasses

but this needs to be extended to (e.g. in proguard.append.cfg):
-keepattributes InnerClasses,*Annotation*

now the error is gone.

Hmm, this raises a problem:

Because "-dontobfuscate" is the default in MOE's proguard.cfg, I have no option to re-enable the obfuscater in proguard.append.cfg.

Currently the only option is to comment out "-dontobfuscate", but with the drawback that this will get overwritten when MOE is updated.

This should be fixed.

(by the way, I think "-dontoptimize" has the same problem)

Dear Tobias,

That is good news, but FYI:
-keep, -keepclassmembers and -keepclasseswithmembers disable shrinking and obfuscation on the specified members.
-keepnames, -keepclassmembernames and -keepclasseswithmembernames disable obfuscation but allows shrinking on the specified members.

To have a fully custom proguard.cfg, duplicate the original cfg from /Applications/Intel/multi_os_engine/tools/proguard.cfg into your module (next to the proguard.append.cfg, without changing the file name).

Best Regards,
Kristóf

Ah, I understand, I forgot the shrinking ... so "-keep class com.badlogic.**" was still needed for the shrinking and not needless in the default config.

But maybe the default proguard.cfg should at least contain "keepattributes InnerClasses,*Annotation*" in the next MOE release. This will save some users from a headache, when they try to enable the obfuscater in a libGDX app ;-)

 

 

Quote:

Kristof Liliom - Migeran Ltd wrote:

To have a fully custom proguard.cfg, duplicate the original cfg from /Applications/Intel/multi_os_engine/tools/proguard.cfg into your module (next to the proguard.append.cfg, without changing the file name).

Oh, I didn't know that. Yes, I can confirm that when I copy the MOE proguard.cfg into my moe-module and removing the "-dontobfuscate" there, it is working and therefore it cannot be overwritten by a MOE update.

By the way: Is there a way to use the obfuscater in a release build only? Currently the obfuscater is also used in every debug build and this is really unconvenient when I output a stacktrace.

 

Leave a Comment

Please sign in to add a comment. Not a member? Join today