I need to make sure the method
java.lang.String -> isEmpty()
Is present in the compiled code.
Will Proguard keep this method if it is referenced somewhere in my code? Or is it better to include
-keep class java.lang.String { *; }
Into Proguard configuration file?
I'm asking because to fix java.lang.ClassNotFoundException this code is used:
try {
Class.forName("android.os.AsyncTask");
}
catch(Throwable ignore) {}
Instead of adding this to Proguard:
-keep class android.os.AsyncTask { *; }
If you're referencing that method in your code, it should be kept by Proguard. From the documentation:
The ProGuard tool shrinks, optimizes, and obfuscates your code by
removing unused code and renaming classes, fields, and methods with
semantically obscure names
So if the code is being used, there's no reason why Proguard would remove it.
Related
In order to configure proguard to keep all classes from a single package, say org.myorg.special, the following notation works:
-keep class !org.myorg.special { *; }
I would like to configure proguard to keep all classes except when they are from either of two packages, say org.myorg.special and org.myorg.another.
I have tried for instance
-keep class !(org.myorg.special,org.myorg.another) { *; }
but the above syntax is not supported by proguard.
What is the correct syntax?
-keep class ![org.myorg.special,org.myorg.another],org.** { *; }
I'm trying to keep proguard from renaming/optimizing classes which have a certain annotaion. There are quite a few examples out there and it should be straight forward but proguard isn't behaving as I would expect it to be.
Issue
Proguard v6.2.2 obfuscates classes annotated with #KeepClass although -whyareyoukeeping shows test.KeepMe is kept by a directive in the configuration.
I can reproduce the issue with a simple 3 file project.
Proguard config:
-optimizations !code/simplification/cast,!field/*,!class/merging/*
-optimizationpasses 3
-allowaccessmodification
-adaptresourcefilecontents **.properties,META-INF/MANIFEST.MF
-dontusemixedcaseclassnames
-dontskipnonpubliclibraryclasses
-verbose
-keep public class test.Entry {
public static void main(java.lang.String[]);
}
-keep #proguard.annotation.KeepClass public class * {
*;
}
-whyareyoukeeping class test.KeepMe
Class which should be kept:
import proguard.annotation.KeepClass;
#KeepClass
public class KeepMe
{
}
Proguard log:
Explaining why classes and class members are being kept...
Printing usage to [D:\Development\Projects\ProguardTest\build\usage.txt]...
test.KeepMe
is kept by a directive in the configuration.
Removing unused program classes and class elements...
Original number of program classes: 3
Final number of program classes: 2
And finally the files in the processed jar file:
- test
|- Entry.class
|- a.class (Obfuscated KeepMe class)
If however I explicitly list the class in the proguard configuration using
-keep class test.KeepMe{*;}
proguard reports the same log output but the class is untouched (as expected)
Am I missing something or is this a bug in proguard?
As it turns out the issue was actually related to a bug in proguard. After trying the latest beta it's working as expected.
I'm running into an issue at runtime when using Proguard with Kotlin reflection. Basically, when I am calling KClass.declaredMemberProperties, I get:
Incomplete hierarchy for class FieldBoundObject, unresolved classes [com.example.test.classes.DisposableObject]
kotlin.reflect.jvm.internal.components.RuntimeErrorReporter.reportIncompleteHierarchy
Here is the relevant stacktrace:
Caused by java.lang.IllegalStateException: Incomplete hierarchy for class FieldBoundObject, unresolved classes [com.example.test.classes.DisposableObject]
at kotlin.reflect.jvm.internal.components.RuntimeErrorReporter.reportIncompleteHierarchy(RuntimeErrorReporter.kt:26)
at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedClassDescriptor$DeserializedClassTypeConstructor.computeSupertypes(DeserializedClassDescriptor.kt:181)
at kotlin.reflect.jvm.internal.impl.types.AbstractTypeConstructor$supertypes$1.invoke(AbstractTypeConstructor.kt:34)
at kotlin.reflect.jvm.internal.impl.types.AbstractTypeConstructor$supertypes$1.invoke(AbstractTypeConstructor.kt:22)
at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:354)
at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:410)
at kotlin.reflect.jvm.internal.impl.types.AbstractTypeConstructor.getSupertypes(AbstractTypeConstructor.kt:23)
at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedClassDescriptor$DeserializedClassMemberScope.getNonDeclaredFunctionNames(DeserializedClassDescriptor.kt:278)
at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope$functionNamesLazy$2.invoke(DeserializedMemberScope.kt:73)
at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope$functionNamesLazy$2.invoke(DeserializedMemberScope.kt:40)
at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:354)
at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:410)
at kotlin.reflect.jvm.internal.impl.storage.StorageKt.getValue(storage.kt:42)
at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope.getFunctionNamesLazy(DeserializedMemberScope.kt)
at kotlin.reflect.jvm.internal.impl.serialization.deserialization.descriptors.DeserializedMemberScope.getFunctionNames(DeserializedMemberScope.kt:84)
at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaClassMemberScope.computeFunctionNames(LazyJavaClassMemberScope.kt:75)
at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaClassMemberScope.computeFunctionNames(LazyJavaClassMemberScope.kt:65)
at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.computeNonDeclaredFunctions(LazyJavaScope.kt:342)
at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope$allDescriptors$1.invoke(LazyJavaScope.kt:61)
at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope$allDescriptors$1.invoke(LazyJavaScope.kt:55)
at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:354)
at kotlin.reflect.jvm.internal.impl.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:410)
at kotlin.reflect.jvm.internal.impl.load.java.lazy.descriptors.LazyJavaScope.getContributedDescriptors(LazyJavaScope.kt:323)
at kotlin.reflect.jvm.internal.impl.resolve.scopes.ResolutionScope$DefaultImpls.getContributedDescriptors$default(ResolutionScope.kt:52)
at kotlin.reflect.jvm.internal.KDeclarationContainerImpl.getProperties(KDeclarationContainerImpl.kt:64)
at kotlin.reflect.jvm.internal.KClassImpl$Data$declaredNonStaticMembers$2.invoke(KClassImpl.kt:151)
at kotlin.reflect.jvm.internal.KClassImpl$Data$declaredNonStaticMembers$2.invoke(KClassImpl.kt:44)
at kotlin.reflect.jvm.internal.ReflectProperties$LazySoftVal.invoke(ReflectProperties.java:92)
at kotlin.reflect.jvm.internal.ReflectProperties$Val.getValue(ReflectProperties.java:31)
at kotlin.reflect.jvm.internal.KClassImpl$Data.getDeclaredNonStaticMembers(KClassImpl.kt)
at kotlin.reflect.full.KClasses.getDeclaredMemberProperties(KClasses.kt:163)
at com.example.test.classes.FieldBinder.bindFields(FieldBinder.kt:51)
at com.example.test.classes.FieldBinder.(FieldBinder.kt:28)
at com.example.test.classes.FieldBoundObject.(FieldBoundObject.kt:15)
at com.example.test.models.TestClass.(TestClass.java:52)
at com.example.test.models.TestClass.(TestClass.java:58)
at com.example.test.ReactLandingActivity.startClass(ReactLandingActivity.java:93)
Here is the relevant call in Fieldbinder.kt:
class FieldBinder(receiver: Any) {
private fun bindFields(receiver: Any, classToCheck: Class<*>) {
for (property in classToCheck.kotlin.declaredMemberProperties) {
//...
}
}
// ...
}
Here is the signature for the "missing" class DisposableObject
package com.example.test.classes
open class DisposableObject : ScopeProvider, Dispose {
//...
}
I think it has something to do with name obfuscation. I've tried using #Keep on the actual class itself, as well as using -keep class on the class itself in my Proguard file. However, what DOES solve the problem is keeping names in Proguard:
-dontobfuscate
or
-keepnames class com.example.test.classes.DisposableObject
Is there an issue with name obfuscation and Kotlin reflection? I'm not having the same issues with Java reflection. Or is there a better way to solve this problem? Thanks!
I'm using the #VisibleForTesting annotation located in the Android Support Annotations library, and it looks like this:
#Retention(SOURCE)
public #interface VisibleForTesting {
}
As I understand it, ProGuard operates on the .class files and since this annotation isn't available at compile time due to its retention policy, all the annotated methods are stripped away. I'd like to run automated tests on my app and use the methods exposed for testing to verify that the ProGuard configuration doesn't break any use cases.
Is it possible to configure ProGuard to keep these elements somehow? So far I've tried:
-keep #android.support.annotation.VisibleForTesting class *
-keep class android.support.annotation.** {
#**.VisibleForTesting *;
}
-keep interface android.support.annotation.** {
#**.VisibleForTesting *;
}
And:
-keep interface android.support.annotation.VisibleForTesting
-keepclasseswithmembers class * {
#android.support.annotation.VisibleForTesting *;
}
-keepclassmembers class ** {
#android.support.annotation.VisibleForTesting *;
}
These two configurations do not work. If I annotate the methods with #Keep as well, and configure ProGuard to keep those methods, the methods are kept and the tests pass. However, by doing that I have to annotate all methods with two annotations.
Is it possible to hook into the annotation processor and override the retention policy for #VisibleForTesting? Or is that already too late in the build process?
Guava's #VisibleForTesting uses RetentionPolicy.CLASS, while Android Support Annotations Library uses RetentionPolicy.SOURCE. I'm considering posting a request to change the policy, but I suppose it's set to SOURCE for a reason, possibly due to performance and a very slightly increased file size?
Are there any options other than using two annotations (#VisibleForTesting and #Keep)?
Annotations with a RetentionPolicy == SOURCE are not present in .class files on which ProGuard is operating. Thus there is no way to use them in rules as they will never match.
Annotations with RetentionPolicy == CLASS should work fine. If needed, they can even be removed in release builds using ProGuard.
In other words: what -keep commands should I use to tell Proguard to avoid obfuscating my classes that represent native libraries? (since JNA requires that the names match the equivalent native function, struct, etc.)
This is the rule I'm using for now:
-keepclassmembers class * extends com.sun.jna.** {
<fields>;
<methods>;
}
I still think there might be a better way to do it though.
For me worked as well
-keep class com.sun.jna.** { *; }
-keep class * implements com.sun.jna.** { *; }
I think I solved it using these rules instead, because it seems they need everything of the package to be de-obfuscated:
-keep class com.sun.jna.** { *; }
-keep class * implements com.sun.jna.** { *; }
JNA by default uses Library interface method names to look up native function names. Anything other than those should be able to withstand obfuscation.
If your tests include coverage of all JNA calls then you should be able to test this almost as fast as asking the question here.
EDIT
Consider this a comment, since I'm not prepared to offer "-keep" commands :)
You certainly must avoid elimination or reordering of any Structure fields.