Develop Reference

Proguard rule for Huawei push client

I have Unable to create application im.app.android.core.AppDemoApplication: e3.b: com.pushserver.android.huaweiPushClient cant cast com.myApp.android.push_lib.huawei.HcmPushClient to PushClient error
What proguard rule should I add? I have tried -keep class com.myApp.android.push_lib.** { *; } but after that I just see the blank screen - no crash, just stuck when trying to start.

Not really an answer, but too long for a comment. I'll update this answer in case we make progress.
1. What is the "normal bug"?
can't cast com.myApp.android.push_lib.huawei.HcmPushClient to PushClient
This means that somewhere in your code you are assigning/passing an instance of HcmPushClient to something that is expecting it to be a PushClient. I would assume that PushClient is some class that you defined in your project, but is does not extend from HcmPushClient. Try to find this piece of code and fix it or add it here to your question.
2. What does ProGuard have to do with this?
Actually, I think not much. If ProGuard would create this error, the message would look more like
can't cast com.myApp.android.push_lib.a.b to c
But since all class names in the error message are the original ones, it does not seem like ProGuard is making issues here. BUT: You can still decypher the message a little bit, because this part is obfuscated:
Unable to create application im.app.android.core.AppDemoApplication: e3.b:
e3.b refers to a class that was obfuscated by ProGuard. To find out what class it is, you can check the file /build/outputs/mapping/release/mapping.txt in your project folder. This is a simple text file that stores the information what class name was renamed to what obfuscated name. In this file search for -> e3 to find the class that was renamed to e3. Somewhere close to this line, you should also be able to find out what exactly e3.b is. Could be a method, could also be a member variable or an inner class.
I hope these two points will bring you closer to make the app run.

Kotlin: ProGuard erases properties attributes

TL;DR: with proguard enabled, when using reflection, my properties look private, non-nullable and without annotations, despite proguard config that should keep all these attributes.
I have some simple data classes with public properties to serve as data models in my Android app. Later, when doing generic [de]serialization of said classes, I filter the property list like this:
val properties = instance::class.memberProperties
.filter { it.visibility == KVisibility.PUBLIC } // && some other conditions, unrelated here
.filterIsInstance<KMutableProperty<*>>()
It works normally on my debug builds (I mean it selects the properties I want it to). But, when doing a release build, where proguard is active, the result is empty. To check why, I logged all the relevant stuff about the properties of one class -- turns out their visibility field reads PRIVATE (and all other attributes remain the same as on a debug build).
I already have a line in proguard config to keep all the models:
-keepclassmembers class * extends com.models.package.name.BaseModel { *; }
I tried this one before, with same result:
-keep class com.models.package.name.** { *; }
Why/how does proguard affect property visibility? Should I modify the config somehow? Or am I missing something else here?
UPDATE: It seems like visibility is not the only thing. prop.returnType.isMarkedNullable also doesn't work, it returns false for properties declared nullable. And annotations also seem to get lost, even though I asked proguard to keep them. Is there any way to work around this? It pretty much renders 2 weeks of my work useless...

Thanks to the suggestion from #yole in question comments, I've been able to make this work. Even though my classes were configured to be kept by ProGuard, it stripped the kotlin.Metadata annotations from them. These annotatons are where Kotlin stores all the attributes I was missing. The solution is to prevent ProGuard from deleting them, adding to configuration:
-keep class kotlin.Metadata { *; }
(on a side note: it's weird that it's not included in the default config, at least if you're using the kotlin.reflect.full package. Or at least it should be mentioned clearly somewhere in the docs...)

Why Proguard keeps Activity class in Android?

I have applied ProGuard to my Android application.
I'm using
android-studio/sdk/tools/proguard/proguard-android.txt
as a configuration file, changing nothing.
In this file I can see the only statement regarding Activity:
We want to keep methods in Activity that could be used in the XML attribute onClick
-keepclassmembers class * extends android.app.Activity {
public void *(android.view.View);
}
It follows from that the Activities class names are obfusctated by ProGuard while some methods are preserved as they are. This is understandable.
However, in my application I then create an Activity Class from a string using
Class.forName("my.app.MyActivity")
then I start this Activity and it starts fine.
But that means Activity-derived classes are not obfuscated??. It should have failed because ProGuard does not have -keep class directive for Activity, it only has -keepclassmembers.
Can someone, please, explain, if I can rely on the behaviour I observe? Or do I misunderstand the -keepclassmembers directive?

Because the activities are listed in the manifest and classes referenced there are automagically kept. This is needed because the Android framework accesses these app entry points via reflection.
From here:
The build process runs the tool aapt to automatically create the configuration file bin/proguard.txt, based on AndroidManifest.xml and other xml files. The build process then passes the configuration file to ProGuard. So ProGuard itself indeed doesn't consider AndroidManifest.xml, but aapt+ProGuard do.

From the ProGuard FAQ:
Does ProGuard handle Class.forName calls?
Yes. ProGuard automatically handles constructs like Class.forName("SomeClass") and SomeClass.class. The referenced classes are preserved in the shrinking phase, and the string arguments are properly replaced in the obfuscation phase.
With variable string arguments, it's generally not possible to determine their possible values. They might be read from a configuration file, for instance. However, ProGuard will note a number of constructs like "(SomeClass)Class.forName(variable).newInstance()". These might be an indication that the class or interface SomeClass and/or its implementations may need to be preserved. The developer can adapt his configuration accordingly.
So, ProGuard's being cleverer than you expected: it will automatically detect and handle simple cases of the use for forName(). Even if the class isn't referenced in the Android manifest file, ProGuard will obfuscate the class name in both the class and in your call to forName().
For Activities, it wouldn't surprise me if you're doubly-covered by both this behaviour and by the Android-specific input to ProGuard that's part of the build process, as #laalto mentions in his answer.

Proguard NoSuchMethodError ITelephony

My code works fine but after applying proguard i am getting the following exception
05-04 16:12:00.803: E/AndroidRuntime(22257):
java.lang.NoSuchMethodError:
com.android.internal.telephony.ITelephony.a
I ma having Itelephony.aidl but still getting the error. Can anyone tell me if there is a way to around this ?
On google, i couldn't get more information on examples of how to keep interfaces, interface members and inner classes along with inner class members.
Actually i want to keep everything in my app but just obsfucate and optimize it. Is there a way to achieve it ?

You need to exclude the ITelephony class from proguard, i.e. add this ...
-keep class com.android.internal.telephony.ITelephony { *; }
... entry to your proguard.cfg file. You'll find it in your project root folder.
Proguard is a tool that obfuscates your code, i.e. makes it more compact and less readable for others by applying various optimization (e.g. renaming classes). So in some cases this might have a negative impact on the functionality, e.g. if you consider dynamic reflection calls.
Cheers!

Android: Proguard NoSuchMethodError

I recently activated ProGuard for my Eclipse Android project. After adding external libs and dynamically referenced classes to the proguard.cfg, I don't get any errors when building the apk. I get however a NoSuchMethodError when I try to start the installed app.
I narrowed it down to a specific method called in the onCreate method of the main activity. To simplify things, here's what the class and method look like (I left out a lot of code, but I think this should illustrate it):
public class TestMain extends TabActivity implements OnSharedPreferenceChangeListener{
...
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
...
testMethod();
}
}
testMethod() is defined as follows:
private void testMethod() {
int charsLeft = maxPostMessageLength - someEditText.length();
...
}
When I remove the "someEditText.length()" part, the app starts. So, the way I see it, the method that can't be found is the EditText.length() method. Strangely, though, the app also starts when I remove "someEditText.length()" from the testMethod and put it directly into the onCreate method:
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
test = someEditText.length();
testMethod();
}
Does anyone know how I can get rid of this error and why I can call someEditText.length() directly in the onCreate method but not in a method called by the onCreate method?
Without using Proguard the app works fine, of course.
Edit:
I tried the -dontshrink, -dontobfuscate and the -dontoptimzie options in the proguard.cfg. With -dontoptimize the app starts without errors.
Still, it would be interesting what exactly causes this specific error.

The Proguard documentation proudly states: "The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes".
Well, I gave up with the 'shrinking' part of it after getting runtime errors like you describe. I added the line
-dontshrink
to the proguard.cfg
You can see which routines have been removed from your code by inspecting the file usage.txt.
I'm happy to say that in my projects it's always missing, meaning that the code is obfuscated but nothing has been removed. I don't get any runtime errors now.

I accidentally stumbled upon a possible solution. Well, it totally works in my case, so this IS a solution to the original problem:
Today, I implemented some code with #Override annotations, which didn't work, at first. Luckily, someone else already had the same problem and an easy Eclipse-related solution:
'Must Override a Superclass Method' Errors after importing a project into Eclipse
Now, I thought, well, if I was always using Java level 1.5 before, why not try ProGuard again, without the -dontoptimize option, now that I set it to 1.6. Can't hurt...
And what can I say, now the app starts and I don't get the strange error when EditText.length() is called in a method.

The optimizer may remove the method invocation and the method if it comes to the conclusion that the method doesn't have any side-effects. It should never create inconsistent code though, and I'm not aware of a problem like this. You should check if it persists with the latest version of ProGuard. Otherwise, you should file a bug report on the ProGuard site, preferably with a small example that illustrates the problem.

I had a similar problem to the OP and it ended up being a proguard config option I set -allowaccessmodification, removing this solved the issue.