Comments 19
Обязательно стоит упомянуть, что такое поведение запрещено правилами Google Play Store.
Ниже перечислены запрещенные программы:
Приложения или пакеты разработчика, которые скачивают исполняемый код (например, файлы DEX или внутренний код), созданный сторонними разработчиками.
Созданный сторонними разработчиками
Интересно, что в данном случае подразумевается под "сторонними разработчиками"? Подходит ли под это определение код, созданный тем же разработчиком, который публикует APK на Google Play?
учитывая что в начале написано про "разработчика", то имеется в виду всё-таки сторонний, т.е. не тот же самый разработчик
Проверил английскую версию:
Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play.
на территории РФ же будет действовать русская версия соглашения. Или я не прав?
В корпоративном сегменте, класс лоадеры используются широко, дабы разгрузить тяжёлые приложения.
Но в Google Play за это забанят.
По реализации возникло пару вопросов
Данный dex файл сохраняется в папке с приложением и его уже больше не требуется грузить повторно?
Есть еще такая штука AAR, в ней можно хранить и ресурсы и разметку, что бы не грузить с сервера.
Вам не доводилось, подобным образом, динамически загружать такой тип ресурсов?
dex-файл загружается каждый раз при запуске.
Смысл как раз в том, что мы можем изменить на сервере dex-файл, не обновляя само приложение.
В принципе, при желании не сложно добавить проверку на время обновления dex на сервере, и загружать его по новой, только если он изменился.
По поводу AAR — как я понял из описания, он используется на этапе компиляции и сборки приложения.
Лично мне этим пользоваться не приходилось.
можно выдавать с сервера разные classes.dex в зависимости от типа аккаунта пользователя (платный/бесплатный)
Интересно виденье автора, как это реализовать, чтобы не было возможности перепаковать apk с обратной проверкой, или вообще включить платный classes.dex внутрь apk.
Я так полагаю, необходима комбинация нескольких разных подходов.
Вопрос интересный.
Мое мнение — стопроцентную защиту приложения от взлома сделать невозможно в принципе.
Но этот самый процент защиты всегда можно увеличить )
Я придумал только такое: в игрушках можно вынести автогенерируемые уровни, но смысла хранить уровни в classes.dex не придумал. Более-менее интересное решение пришло на ум такое: в клиентском apk есть интерфейс-протокол общения с _платным_ сервером, а в classes.dex нам сервер авторизации подсунет реализацию этого нитерфейса, которая будет динамически генерироваться.
Мне еще такой пример пришел на ум. Только не с платным, а с корпоративным сервером.
Не знаю, может ли такое реально быть кому-нибудь нужно, но можно сделать так, чтобы classes.dex загружался только из корпоративной сети, а при смене сети самоудалялся.
Уже даже реализовал, но подумал о том, что наверняка антивирусы Google Play заметят возможность рефлексии загружаемым кодом. А ведь я потенциально могу вписывать туда все что угодно. Хорошо что наткнулся на комментарии к этой статье, где опубликовали оригинальную трактовку правил, которые запрещают загружать любой код из внешних источников.
Android: динамически подгружаем фрагменты из сети