Comments 12
Как я понимаю, seed'ы в Android — это потомки Application, Activity и BroadcastReceiver. Их имена классов не будут обфусцированы. Есть ли какая-то настройка для их принудительной обфускации?
```
protected void onCreate(Bundle bundle) {
super.onCreate(bundle);
setContentView(R.layout.activity_login);
m18099a((C1594i) new C1594i(null, this));
((C3371b) mo2290t()).m15997c();
}
```
Если все-таки и правда хочется все сломать, то можно:
— НЕ добавлять дефолтный конфиг андроида `getDefaultProguardFile('proguard-android.txt')`
— каким-то образом не добавлять конфиги, сгенерированные aapt, библиотеками и сторонними плагинами — думаю этого можно добиться модификацией gradle-тасок, которые создаются `gradle-android` плагином, но я не пробовал
Идея то интересная, но прогурд же не умеет за нас редактировать манифест, чтобы после обфускации переименовать и в манифесте Application, Activity и BroadcastReceiver?
Хочешь спрятать дерево — спрячь его в лесу. Вот и тут возможны ситуации, когда мы захотим спрятать, например, AdvertActivity в гуще других таких же Activity. То есть прямая задача обфускации — потратить время реверс инженера, в данном случае выполнима.
«Advert» это же реклама?
А раз так, то оно будет использовать стандартное API одного из распространённых сервисов. По его использованию и найдут. Поиск использования классов в Android Studio работает на отлично. Не знаю, правда, зачем кому-либо нужно искать рекламное activity. Тем более настоящему инженеру.
Напоследок, Proguard может превратить весь ваш код в нечитабельное месиво переименовав все классы, методы и поля в наборы случайных (на самом деле не совсем случайных) букв. Это очень полезная опция, так как декомпилировать ваш apk-файл может любой желающий, а разбираться в обфусцированном коде хватит терпения не у каждого.
Главное не питать иллюзий и осознавать, что это защита уровня «если крепко зажмурить глаза, то при игре в прятки меня никто не найдёт». Переименованные идентификаторы могут испугать разве что совсем неопытных.
Сам всегда стараюсь пользоваться Proguard'ом, до тех пор пока в проекте не появляются Google Play Services, тогда уже приходится сдаться и включить Mulditex.
Если вы используете Google Play Services, то плагин com.google.gms.google-services подберет нужный вам конфиг самостоятельно.
Можно об этом поподробнее? Это плагин для Android Studio или то что загружает SDK Manager?
до тех пор пока в проекте не появляются Google Play Services
убедитесь, что вы используете конкретную часть сервисов, а не весь фрэймворк целиком (https://developers.google.com/android/guides/setup)
Можно об этом поподробнее? Это плагин для Android Studio или то что загружает SDK Manager?
Это тот плагин, который вы подключаете последней строчкой в build.gradle:
apply plugin: 'com.google.gms.google-services'
Раньше этот плагин добавлял конфиг, прада сейчас, судя по всему, они просто распространяют свои библиотеки сразу со вшитыми конфигами, так что плагин почти ни при чем. Сейчас плагин просто проверяет корректность настройки, версии библиотеки и наличие google-services.json
Я все больше убеждаюсь, что с прогурадом можно влезть в пресловутые 65к практически с любыми зависимостями. Например, у меня есть проект в котором: google-play-services(локация, реклама, in-app покупки, аналитика), пуши от одно знаменитого сервиса (работает поверх firebase), rxjava, kotlin, okhttp, retrofit, picasso, commons-io, exoplayer и еще горстка третесторонних sdk и мы все еще держимся на уровне ~55k. Просто нужно очень тщательно и аккуратно проинспектировать keep-правила :)
Как перестать бояться Proguard и начать жить