Скрыть классы библиотеки - Android

У меня есть 3 проекта, которые используются в качестве библиотек в 4-м (основной проект).

3 проекта выполняются друг с другом следующим образом (build.gradle):

Проект библиотеки:

  • Проект A

    compile project(":projectA")
compile project(":projectB")

  • Проект B

    compile project(':projectC')

Основной проект:

compile(name: 'projectA', ext: 'aar')
compile(name: 'projectB', ext: 'aar')
compile(name: 'projectC', ext: 'aar')

Я хотел бы сделать что-то в "Библиотечном проекте", так что изнутри основного проекта, если я нажму на любой класс из проекта библиотеки, я должен либо не увидеть код, либо он должен быть зашифрованным.

Так, например, если в ProjectA есть InterfaceA, и основное действие Main Project реализует этот интерфейс, если я "Ctrl-Click" в интерфейсе, результат должен быть похож на то, что я указал выше.

Я понимаю, что Proguard делает что-то подобное, но это только если вы создаете выпуск .apk, мне нужен тот же результат для скомпилированных библиотек.

Ответы

Ответ 1

Многие проекты используют ProGuard для достижения этой защиты.

  • Вы можете использовать Gradle для сборки компонентов библиотеки для Android
  • Библиотеки, так же как и приложения, могут быть созданы в разработке или выпусках типов сборки.
  • Proguard может быть настроен для работы на компоненте (приложении или библиотеке), но только в типе выпуска. См. Здесь: https://sites.google.com/a/android.com/tools/tech-docs/new-build-system/user-guide#TOC-Running-ProGuard

  • Если компонент минимизирован (настоятельно рекомендуется), то вам нужно сообщить Progaurd, что такое "корневые" классы, иначе он будет нивелировать библиотеку дословно. Этого можно добиться, добавив правило в файл конфигурации:

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

    Более обширный пример: http://proguard.sourceforge.net/manual/examples.html#library

Однако существуют некоторые ограничения:

  • Основное использование ProGuard - удаление как можно большего количества отладочной информации, номеров строк и имен из байт-кода без изменения того, что фактически делает байт-код. Он заменяет имена членов и аргументов, непубличные классы бессмысленными, например vehicleLicensePlate может стать _a. Поскольку любой поддерживающий код будет относиться, неправильные имена членов и переменных значительно упрощают техническое обслуживание.
  • ProGuard может (слегка) модифицировать байт-код, оптимизируя как можно больше (вычислительные константы, определяемые как выражения, играющие с инкрустацией и т.д. Оптимизации перечислены здесь: http://proguard.sourceforge.net/FAQ.html#optimization)
  • ProGuard не шифрует байт-код - JVM должен видеть фактический байт-код, иначе он не смог запустить программу.

Таким образом, обфускация только усложняет обратную инженерию и понимает библиотеку, она не может сделать эту задачу невозможной.

Один последний указатель: ProGuard выгружает файл, содержащий список изменений, в частности номеров строк. Когда вы получаете трассировки стека от своих клиентов (или с помощью онлайн-инструментов, таких как Crashlytics), вы можете вернуть обфускацию, чтобы вы могли отлаживать. В любом процессе сборки релиза вам нужно найти способ сохранить этот файл.

Этот файл также необходим, если вы делаете инкрементные выпуски своей библиотеки, чтобы обфускация соответствовала ранее выпущенной версии. Если вы этого не сделаете, клиент не сможет вставить замену вашей библиотеки и должен будет выполнить полную перестройку (и ссылку) своего приложения.

Хотя ProGuard - это бесплатный вариант, который просто работает, есть и другие бесплатные и платные обфускаторы. Некоторые предлагают еще несколько функций, но они принципиально одинаковы, и совместимость ProGuard с IDE, инструментами и сервисами превосходна.

Ответ 2

Вы можете установить для всех методов, которые не должны быть общедоступными, по умолчанию, поэтому они не могут использоваться вне исходного проекта. А также вы должны отделить библиотеки от проекта приложения, скомпилировать их и использовать в качестве внешних зависимостей. Если вы не хотите, чтобы исходный код библиотеки был опубликован, просто не добавляйте его в параметры компиляции. Если кто-то другой, кроме вас, должен использовать вашу библиотеку, опубликуйте ее с помощью bintray или просто добавьте скомпилированные файлы aar/jar в проект приложения.

Вот руководство для всего процесса: https://inthecheesefactory.com/blog/how-to-upload-library-to-jcenter-maven-central-as-dependency/en

В качестве альтернативы вы можете создавать проекты библиотек с использованием maven (я нахожу это намного проще, чем использование gradle), посмотрите здесь на пример: https://github.com/simpligility/android-maven-plugin/tree/master/src/test/projects/libraryprojects

и конкретный проект: https://github.com/fcopardo/BaseViews-Android

Ответ 3

2 шага:

  • добавьте свои библиотеки в локальное хранилище maven

  • использовать зависимости maven вместо зависимостей проекта.

Ответ 4

Вы не можете этого сделать. Скомпилированная библиотека имеет файлы .class(байт-код), которые можно декомпилировать и просмотреть с помощью различных компиляторов, таких как JD-GUI и т.д. Android Studio имеет встроенный декомпилятор, который упрощает для кого-то просто ctrl -click и просмотреть файл .class. Лучший вариант, который у вас есть, - обфускать ваш код. Здесь - некоторые обфускаторы, которые вы можете использовать. Но всегда имейте в виду, что никогда не невозможно перепроектировать что-то. Все взломанно.