Интересно, что в данном случае подразумевается под "сторонними разработчиками"? Подходит ли под это определение код, созданный тем же разработчиком, который публикует APK на Google Play?
Не уверен. Каждый раз при публикации там нужно ставить галочку, что-то вроде "приложение не нарушает экспортное законодательство США" (точную формулировку не помню), так что полагаю, что английская версия в данном случае первична, а в русской просто неточности перевода.
что такое «внутренний код»? Если например, я использую свой простенький интерпретатор внутри приложения, а скрипты загружаю из интернетов, считается ли это кодом?
Это правило не распространяется на код, который запускается на виртуальной машине и имеет ограниченный доступ к API Android (например, код JavaScript в компоненте WebView или браузере).
По реализации возникло пару вопросов
Данный dex файл сохраняется в папке с приложением и его уже больше не требуется грузить повторно?
Есть еще такая штука AAR, в ней можно хранить и ресурсы и разметку, что бы не грузить с сервера.
Вам не доводилось, подобным образом, динамически загружать такой тип ресурсов?
dex-файл загружается каждый раз при запуске.
Смысл как раз в том, что мы можем изменить на сервере dex-файл, не обновляя само приложение.
В принципе, при желании не сложно добавить проверку на время обновления dex на сервере, и загружать его по новой, только если он изменился.
По поводу AAR — как я понял из описания, он используется на этапе компиляции и сборки приложения.
Лично мне этим пользоваться не приходилось.
можно выдавать с сервера разные classes.dex в зависимости от типа аккаунта пользователя (платный/бесплатный)
Интересно виденье автора, как это реализовать, чтобы не было возможности перепаковать apk с обратной проверкой, или вообще включить платный classes.dex внутрь apk.
Я так полагаю, необходима комбинация нескольких разных подходов.
Вопрос интересный.
Мое мнение — стопроцентную защиту приложения от взлома сделать невозможно в принципе.
Но этот самый процент защиты всегда можно увеличить )
И всё таки, можно какой-то абстрактный пример «на котиках», что можно вынести на сервер?
Я придумал только такое: в игрушках можно вынести автогенерируемые уровни, но смысла хранить уровни в classes.dex не придумал. Более-менее интересное решение пришло на ум такое: в клиентском apk есть интерфейс-протокол общения с _платным_ сервером, а в classes.dex нам сервер авторизации подсунет реализацию этого нитерфейса, которая будет динамически генерироваться.
Мне еще такой пример пришел на ум. Только не с платным, а с корпоративным сервером.
Не знаю, может ли такое реально быть кому-нибудь нужно, но можно сделать так, чтобы classes.dex загружался только из корпоративной сети, а при смене сети самоудалялся.
Если не ошибаюсь класс лоадер внешний dex файл грузит со стораджа, куда предварительно выкачивается и сохраняется. И даже видел реализации, которые таскают с собой дополнительный dex в зашифрованном виде, но при подгрузке и расшифровке все-равно кладут на сторадж. Было бы интереснее если научить класс лоадер загружать dex, который лежит только в памяти в хипе. Снятие дампа может кидс хакеров отсеить.
Тоже думал о том, как хранить его в памяти. Пока не придумал.
Еще такая идея была — dex загружается, и первым делом проверяет на устройстве root. И дальше работает, только если устройство не рутованное.
Хотел сделать для своего приложения баг-трекер с возможностью оперативного фикса бага — на сервер отправляется отчет об ошибке и если такая проблема была зарегистрирована, возвращает код для исправления ошибки.
Уже даже реализовал, но подумал о том, что наверняка антивирусы Google Play заметят возможность рефлексии загружаемым кодом. А ведь я потенциально могу вписывать туда все что угодно. Хорошо что наткнулся на комментарии к этой статье, где опубликовали оригинальную трактовку правил, которые запрещают загружать любой код из внешних источников.
Only those users with full accounts are able to leave comments.Log in, please.
Обязательно стоит упомянуть, что такое поведение запрещено правилами Google Play Store.
Интересно, что в данном случае подразумевается под "сторонними разработчиками"? Подходит ли под это определение код, созданный тем же разработчиком, который публикует APK на Google Play?
учитывая что в начале написано про "разработчика", то имеется в виду всё-таки сторонний, т.е. не тот же самый разработчик
Проверил английскую версию:
на территории РФ же будет действовать русская версия соглашения. Или я не прав?
Не уверен. Каждый раз при публикации там нужно ставить галочку, что-то вроде "приложение не нарушает экспортное законодательство США" (точную формулировку не помню), так что полагаю, что английская версия в данном случае первична, а в русской просто неточности перевода.
В корпоративном сегменте, класс лоадеры используются широко, дабы разгрузить тяжёлые приложения.
Но в Google Play за это забанят.
С той же страницы правил:
По реализации возникло пару вопросов
Данный dex файл сохраняется в папке с приложением и его уже больше не требуется грузить повторно?
Есть еще такая штука AAR, в ней можно хранить и ресурсы и разметку, что бы не грузить с сервера.
Вам не доводилось, подобным образом, динамически загружать такой тип ресурсов?
dex-файл загружается каждый раз при запуске.
Смысл как раз в том, что мы можем изменить на сервере dex-файл, не обновляя само приложение.
В принципе, при желании не сложно добавить проверку на время обновления dex на сервере, и загружать его по новой, только если он изменился.
По поводу AAR — как я понял из описания, он используется на этапе компиляции и сборки приложения.
Лично мне этим пользоваться не приходилось.
Интересно виденье автора, как это реализовать, чтобы не было возможности перепаковать apk с обратной проверкой, или вообще включить платный classes.dex внутрь apk.
Я так полагаю, необходима комбинация нескольких разных подходов.
Вопрос интересный.
Мое мнение — стопроцентную защиту приложения от взлома сделать невозможно в принципе.
Но этот самый процент защиты всегда можно увеличить )
Я придумал только такое: в игрушках можно вынести автогенерируемые уровни, но смысла хранить уровни в classes.dex не придумал. Более-менее интересное решение пришло на ум такое: в клиентском apk есть интерфейс-протокол общения с _платным_ сервером, а в classes.dex нам сервер авторизации подсунет реализацию этого нитерфейса, которая будет динамически генерироваться.
Мне еще такой пример пришел на ум. Только не с платным, а с корпоративным сервером.
Не знаю, может ли такое реально быть кому-нибудь нужно, но можно сделать так, чтобы classes.dex загружался только из корпоративной сети, а при смене сети самоудалялся.
Тоже думал о том, как хранить его в памяти. Пока не придумал.
Еще такая идея была — dex загружается, и первым делом проверяет на устройстве root. И дальше работает, только если устройство не рутованное.
Уже даже реализовал, но подумал о том, что наверняка антивирусы Google Play заметят возможность рефлексии загружаемым кодом. А ведь я потенциально могу вписывать туда все что угодно. Хорошо что наткнулся на комментарии к этой статье, где опубликовали оригинальную трактовку правил, которые запрещают загружать любой код из внешних источников.