java - Hide classes of library - Android -

i have 3 projects used libraries within 4th (main project).

the 3 projects complied within each other follows (build.gradle):

library project:

• project a

  compile project(":projecta") compile project(":projectb") 

• project b

  compile project(':projectc') 

main project:

compile(name: 'projecta', ext: 'aar') compile(name: 'projectb', ext: 'aar') compile(name: 'projectc', ext: 'aar') 

i "library project", within main project, if click on class within library project, should either not able see code, or should encrypted.

so example if there interfacea in projecta, , main activity of main project implements interface, if "ctrl-click" interface, result should similar specified above.

i understand proguard similar, if building release .apk, need same result compiled libraries.

many projects use proguard achieve protection.

• you can use gradle build library components android
• libraries, apps, can build in development or release build types
• proguard can configured run on component (app or library), in release build type. see here: https://sites.google.com/a/android.com/tools/tech-docs/new-build-system/user-guide#toc-running-proguard

• if component minified (highly advised), need tell progaurd "root" classes are, otherwise minify library literally nothing. can achieved adding rule configuration file:

  -keep class your.package.name {public *;} 

  a more extensive example here: http://proguard.sourceforge.net/manual/examples.html#library

however there limitations:

• proguard's main use is removing debug information, line numbers , names possible bytecode without changing bytecode does. replaces names of members , arguments, non-public classes meaningless ones, example vehiclelicenseplate might become _a. code maintainer relate, bad member , variable names make maintenance hard.
• proguard can (slightly) modify bytecode optimising as possible (computing constants defined expressions, playing around inlining, etc. optimisations listed here: http://proguard.sourceforge.net/faq.html#optimization)
• proguard not encrypt bytecode - jvm needs see actual bytecode otherwise not run program.

so, obfuscation makes harder reverse-engineer , understand library, cannot make task impossible.

one last pointer: proguard dumps file containing list of has changed, in particular line numbers. when stack traces customers (or through online tools crashlytics) can revert obfuscation can debug. in release-build process, need find way save file.

this file needed when make incremental releases of library obfuscation consistent released version. if don't, customer cannot drop-in replace library , have complete rebuild (and link) of app.

while proguard free-n-easy option works, there other free , paid-for obfuscators. offer few more features, fundamentally same, , compatibility of proguard ides, tools , services excellent.