Develop Reference

Proguard rules for Jetpack GameActivity

I'm trying to use Jetpack GameActivity in my project, but I encounter a strange issue with Proguard. My project has 2 modules, app and my-lib:
my-lib module has MyActivity which extends GameActivity:
api 'androidx.games:games-activity:1.2.1'
app module has MainActivity which extends MyActivity from my-lib module
implementation project(":my-lib")
When I built my project in Release build and had Proguard enabled, I got a native crash:
Abort message: 'Unable to find method setWindowFlags'
=> I tried inspecting GameActivity class from my APK, setWindowFlags method didn't exist at all, which means Proguard has removed it, that's why the native part of the GameActivity library couldn't find the method and it threw an error.
Then, I tried to fix it, by adding Proguard rule like this:
-keep, includedescriptorclasses class com.google.androidgamesdk.GameActivity { *; }
But unfortunately, I got another native crash:
Abort message: 'Unable to find field left'
=> Why does this happen? I tried inspecting the APK again, but have no idea why
Anyway, how can I deal with this situation? Does Jetpack GameActivty need to add Proguard rules to keep methods that will be used by the native part?

There is a know issue in version 1.2.1 and before: the java functions called by native code only were stripped out by proguard for the release build. Version 1.2.2-alpha01 has fixed that and a few other important potential issues, including the static library release in the AAR. To use the 1.2.2-alpha01+:
Add the latest version to the dependency: 1.2.2-alpha01+
Use C/C++ static lib release in the AAR.
add the following or something similar to your project's existing CMakeLists.txt
find_package(game-activity REQUIRED CONFIG)
add_library(${PROJECT_NAME} SHARED sth.cpp) #<=== this is your own.
target_link_libraries(${PROJECT_NAME} game-activity::game-activity_static
# optional: does not hurt to add it; refer to the official doc for update.
set(CMAKE_SHARED_LINKER_FLAGS
"${CMAKE_SHARED_LINKER_FLAGS} -u \
Java_com_google_androidgamesdk_GameActivity_initializeNativeCode")
If want to use the source code directly(not recommended), do something similar to this:
# Find GameActivity sources to build.
find_package(game-activity REQUIRED CONFIG)
get_target_property(GAME_ACTIVITY_INCLUDE_PATH
game-activity::game-activity
INTERFACE_INCLUDE_DIRECTORIES)
string(REPLACE "include" "" GAME_ACTIVITY_SRCS ${GAME_ACTIVITY_INCLUDE_PATH})
file(GLOB_RECURSE GAME_ACTIVITY_SRCS
${GAME_ACTIVITY_INCLUDE_PATH}/*.c*)
add_library(${PROJECT_NAME} SHARED
sth.cpp. #<== this is your own file
${GAME_ACTIVITY_SRCS})
target_link_libraries(${PROJECT_NAME} PUBLIC
android log
game-activity::game-activity
# other libs
)
Note: it is still just 3 source files now, and you can unzip the latest AAR and list them explicitly like:
add_library(${PROJECT_NAME} SHARED
sth.cpp. #<== this is your own file
${GAME_ACTIVITY_INCLUDE_PATH}/game-activity/GameActivity.cpp
${GAME_ACTIVITY_INCLUDE_PATH}/game-activity/native_app_glue/android_native_app_glue.c
${GAME_ACTIVITY_INCLUDE_PATH}/game-text-input/gametextinput.cpp)
The glob way might be better for future compatibility reasons; but it is not cmake recommended way to do things.
Handle the the "back" button press to exit app either from Kotlin/Java side(handle KEYCODE_BACK in onKeyDown()) or native code (AKEYCODE_BACK in input key event processing).
Referring to the documentation page and probably the list above, you should be able to get your project going. The simple fact is this: all of the C/C++ things are inside AAR, under the prefab sub-directory, you even can copy it out and directly put into your own source tree. This Pull Request might help (but not totally sure).
If you see something or like some new things, please create a bug.

I had the same issues as you and I solved this by adding the following line to my proguard-rules.pro file:
-keep class com.google.androidgamesdk.** { *; }
Of course then I had other proguard related errors so I had to add these
additional lines:
-keep class androidx.core.graphics.Insets { *; }
-keep class androidx.core.view.** { *; }
-keep class org.fmod.** { *; }
Of course you will have different errors in your build, but hopefully this will help you.

Proguard (R8) obfuscate custom view names

I am using R8 in my app and have several custom views (which are referenced in xml layouts) tho their names are not obfuscated at all. Is there any way to achieve this? I am using the standard Gradle rules:
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
And also tried with android.enableR8.fullMode=true but it's the same.

I am using R8 in my app and have several custom views (which are referenced in xml layouts) tho their names are not obfuscated at all.
This is because the proguard-android-optimize.txt has the following rule:
# keep setters in Views so that animations can still work.
-keepclassmembers public class * extends android.view.View {
void set*(***);
*** get*();
}
So your custom views, or any views, will not have their names obfuscated by default.
Now the question is can you still have R8 rename the custom views in your app? And the answer is not really.
You could add an -applymapping myCustomMapping.txt by copying the contents of
<root_dir>/app/build/outputs/mapping/<build_variant>/mapping.txt and replacing all references to your custom views that are NOT obfuscated with obfuscated names.
Like this:
Copy contents of <root_dir>/app/build/outputs/mapping/<build_variant>/mapping.txt into a new file <root_dir>/app/myCustomMapping.txt
Before changing anything, it will look like this:
my.app.package.CustomView -> my.app.package.CustomView :
13:34:void <init>(android.content.Context,android.util.AttributeSet,int) -> <init>
15:16:void <init>(android.content.Context,android.util.AttributeSet,int,int,kotlin.jvm.internal.DefaultConstructorMarker) -> <init>
43:46:void customMethod() -> c
You need to change only this line, that has the top level class mapping. Notice that it is unchanged because of the android proguard rules. Change it to whatever obfuscated name you want, like this:
my.app.package.CustomView -> my.app.package.youcantseemeatall :
13:34:void <init>(android.content.Context,android.util.AttributeSet,int) -> <init>
15:16:void <init>(android.content.Context,android.util.AttributeSet,int,int,kotlin.jvm.internal.DefaultConstructorMarker) -> <init>
43:46:void customMethod() -> c
Finally, add these lines to your proguard-rules.pro file
-applymapping myCustomMapping.txt
-printmapping mapping.txt
Those above steps will change your .class files to obfuscate CustomView to youcantseemeatall, BUT your resource files will still reference the original CustomView name and your app will crash at runtime.
Conclusion:
Unfortunately there really isn't a way to do what your asking with proguard or any tooling that comes with Android Studio. There may be a custom Gradle Plugin that changes all custom view names before the app is assembled, but I couldn't find one just googling it now.

How can I obfuscate my sdk coded with kotlin (and get rid of Metadata)

I'm developing a SDK (Android library), and I have to obfuscate a large part of my code so the customer may not try and play with internal code.
My lib is coded in kotlin, and I used proguard to obfuscate the code. Problem is that there are still #kotlin.Metadata (runtime) annotations inside the code after compile and obfuscation. With those annotations, it's really easy to retrieve the java code that originated this "(not-so-)obfuscated" bytecode.
I first thought it was my fault, and my project had too many entropy sources that might have induced this behaviour, so I made a sample project to prove that the problem does not come from my sdk implementation.
I created a new project with AS, then a lib module with 2 files:
facade.kt is my facade class, the one that I do not wish to obfuscate, so the customer may use it:
package com.example.mylibrary
class MyFacade(val internalClass:InternalClass) {
fun doSomething() {
internalClass.doSomething(
firstArgument=1,
secondArgument=2
)
}
}
and in this sample, internal.kt holds the classes that I want to obfuscate:
package com.example.mylibrary
class InternalClass {
fun doSomething(firstArgument: Int, secondArgument: Int) {
System.out.println("Arguments are : $firstArgument, $secondArgument")
}
}
The proguard rules are injected into gradle project with this release closure:
buildTypes {
release {
minifyEnabled true
proguardFiles 'proguard-rules.pro'
}
}
And here is proguard-rules.pro (only one line, nothing more) :
-keep class com.example.mylibrary.MyFacade {*;}
The result: when I ./gradlew clean myLib:assembleRelease, I do obtain an aar in which my facade is kept, and my internal class has been renamed in 'a', with one method 'a', except that the class is still annotated with kotlin #Metadata, which holds every information that helps the decompiler retrieve the original class name, the method, attribute and argument names, etc...
So my code is not so obfuscated at all...
#Metadata(
mv = {1, 1, 7},
bv = {1, 0, 2},
k = 1,
d1 = {"\u0000\u001a\n\u0002\u0018\u0002\n\u0002\u0010\u0000\n\u0002\b\u0002\n\u0002\u0010\u0002\n\u0000\n\u0002\u0010\b\n\u0002\b\u0002\u0018\u00002\u00020\u0001B\u0005¢\u0006\u0002\u0010\u0002J\u0016\u0010\u0003\u001a\u00020\u00042\u0006\u0010\u0005\u001a\u00020\u00062\u0006\u0010\u0007\u001a\u00020\u0006¨\u0006\b"},
d2 = {"Lcom/example/mylibrary/InternalClass;", "", "()V", "doSomething", "", "firstArgument", "", "secondArgument", "mylibrary_release"}
)
public final class a {
...
}
So my question: is it possible to get rid of those annotations, am I the only one facing this problem, or have I missed something?

Finally, I found a way to delete Kotlin metadata annotations.
In order to hide Kotlin metadata annotations, you need to enable R8 full mode.
Here is the information about my environment.
Environment
OS: macOS 10.15.1
Android Studio: 3.5.1
Gradle: 5.4.1
Android Gradle Tool: 3.5.2
What you have to do is just add properties to gradle.properties like below
gradle.properties
android.enableR8.fullMode=true
And here is my Proguard Rules
proguard-rules.pro
-dontwarn kotlin.**
-assumenosideeffects class kotlin.jvm.internal.Intrinsics {
static void checkParameterIsNotNull(java.lang.Object, java.lang.String);
}
FYI, R8 full mode is still testing now, so sometimes it doesn't work well. However, for me, it works perfectly for now.

There is some plugin dedicated for this kind of this request : https://github.com/oliver-jonas/unmeta
This plugin allows removing all Kotlin #Metadata / #DebugMetadata annotations from generated class files. This is safe to do as long as:
you do not intend to use the resulting binaries as a Kotlin library (#Metadata annotations are used to determine Kotlin function definitions),
you are not using Kotlin Reflection (certain reflection functionality depends on the presence of the #Metadata annotations).
Must be careful because when removing the metadata kotlin may your application or your library will not work.

Android ProGuard how to hide/obfuscate source code of exported library

I'm developing Android library and I want to hide/obfuscate the source code implementation of the library.
The way the user project app will use the library is:
startActivity( new Intent(context, LibraryActivityName.class) );
So I need to keep just the name of entry point Activity inside the library project, That's all.
When I used the default ProGuard settings:
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
as well as the suggested example for library - Nothing happened, and by clicking on the Activity name inside the user app (when he imports it) - One can see the source code.
Thanks,

As you do not have a typical library, you should not include the typical library example.
First of all, you need to enable Proguard execution, change this line:
minifyEnabled true
Second, you do not want to keep all public classes, but only the activity:
-keep class LibraryActivityName { public protected <methods>; }
The remaining classes can be fully obfuscated if I understand your question correctly, so there should be no need for further configuration, unless you use reflection somewhere.
It would also be good if you repackage the obfuscated classes into an internal package or something using
-repackageclasses my.library.package.internal
which might also required
-allowaccessmodification
btw. ProGuard will not obfuscate the code itself, only the class / method names.

Android Proguard does not inline

I am using the latest Android SDK (4.1) and I tried exporting a signed jar with Proguard enabled. However, after decompiling the optimized APK, I noticed that methods that I would have expected to be inlined were not.
I know that Proguard ran because the code was correctly obfuscated. So to confirm this, I added this method to my Activity:
private void testInlining()
{
mConfig = null;
}
This private method is called only once in my activity, and because it is private, it should be very obvious to the optimizer that it is called only once and that it should be inlined.
The documentation says that all optimizations are enabled by default, and that Proguard "Inline methods that are short or only called once".
Is there a specific flag I should give to Proguard to enable inlining?
EDIT
My proguard configuration file contains
-optimizationpasses 5
-allowaccessmodification
-overloadaggressively
-repackageclasses ''
-dontskipnonpubliclibraryclasses
EDIT
After using
-whyareyoukeeping class com.templatecompany.templateappname.EntryPointActivity {*;}
I get the reason why the method is not inlined:
[proguard] com.templatecompany.templateappname.EntryPointActivity: void testInlining() (20:21)
[proguard] is invoked by com.templatecompany.templateappname.EntryPointActivity: com.td.media.ivConnection.IvConfig getIvConfig() (14:15)
[proguard] implements com.td.widget.MainActivity: com.td.media.ivConnection.IvConfig getIvConfig()
[proguard] is invoked by com.td.widget.MainActivity: void onCreate(android.os.Bundle) (140:175)
[proguard] implements android.app.Activity: void onCreate(android.os.Bundle)
[proguard] is a library method.
But I am not sure to see how the fact that the method testInlining is used in the method getIvConfig which is in turn used by another method prevents the inlining on testInlining in getIvConfig.

This recent Android SDK disables all optimizations by default, see ${sdk.dir}/tools/proguard/proguard-android.txt:
-dontoptimize
The alternative optimizing configuration only disables a few optimizations, see ${sdk.dir}/tools/proguard/proguard-android-optimize.txt:
-optimizations !code/simplification/arithmetic,!code/simplification/cast,!field/*,!class/merging/*
You can specify your preferred configuration file in project.properties.
You can verify which complete configuration ProGuard is using by adding the option -printconfiguration.
Some optimizations have been disabled in order to avoid bugs in older versions of the Dalvik VM (!code/simplification/arithmetic,!code/simplification/cast), and some optimizations may have been disabled to avoid bugs in older versions of ProGuard (!field/*,!class/merging/*).
Note that -whyareyoukeeping refers to the shrinking step, which removes unnecessary classes/fields/methods as a whole. Methods that are not removed may be inlined in the optimization step (unless explicitly specified otherwise with -keep).

In your module's build.gradle file, you should look at:
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), file('proguard-project.txt')
signingConfig signingConfigs.release
}
}
and replace proguard-android.txt with proguard-android-optimize.txt, which doesn't include the -dontoptimize line while keeping the dalvik problems away (see Eric Lafortune's answer).