Подписание обновленной версии приложения AIR

Каждый раз при создании обновленной версии существующего приложения AIR следует подписывать обновленное приложение. При оптимальном раскладе для подписи обновленной версии используется тот же сертификат, что и для предыдущей версии. В этом случае процесс подписи в точности схож с первоначальной подписью приложения.

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

Прежде чем применить подпись переноса, обратите внимание на следующие моменты.

Чтобы применить подпись переноса, исходный сертификат должен быть действителен или быть просроченным не более чем на 365 дней. Этот период считается льготным, и его продолжительность может быть изменена в будущем.

После окончания 365-дневного льготного периода, который отсчитывается с момента истечения действия сертификата, подпись переноса не может быть применена. В этом случае пользователям потребуется перед установкой обновления удалить текущую версию приложения.

365-дневный льготный период применяется только к приложениям, для которых в пространстве имен дескриптора приложения указана версия AIR 1.5.3 или более поздняя версия.

Следующая таблица и рисунок иллюстрируют процесс обращения с подписями переноса:

Состояние оригинального сертификата

Приложение на основе среды выполнения Adobe AIR 1.5.3 или более новой версии

Опубликуйте последнюю версию приложения AIR

Действия не требуются

Приложение обновляется автоматически

Срок истек, но не более 365 дней назад

Подпишите приложение новым сертификатом. Примените подпись переноса с использованием устаревшего сертификата.

Действия не требуются

Приложение обновляется автоматически

Просрочен, льготный период закончился

Подпись переноса не может быть применена для обновления приложения AIR.

Вместо этого опубликуйте другую версию приложения AIR, используя новый сертификат. Пользователи могут установить новую версию приложения AIR после удаления существующей версии.

Удалите текущую версию приложения AIR и установите последнюю версию

Приложение на основе среды выполнения Adobe AIR 1.5.2 или более ранней версии

Идентификатор издателя в дескрипторе обновленного приложения совпадает с идентификатором предыдущей версии

Опубликуйте последнюю версию приложения AIR

Действия не требуются

Приложение обновляется автоматически

Просрочен, льготный период закончился

Подпись переноса не может быть применена для обновления приложения AIR.

Удалите текущую версию приложения AIR и установите последнюю версию

Приложение на основе среды выполнения Adobe AIR 1.5.2 или более ранней версии

Идентификатор издателя в дескрипторе обновленного приложения не совпадает с идентификатором предыдущей версии

Подпишите приложение AIR действующим сертификатом и опубликуйте его последнюю версию.

Удалите текущую версию приложения AIR и установите последнюю версию

Начало времен

Понять смысл и назначение защитных механизмов Android проще всего в ретроспективе. А именно — изучив, как была реализована защита (или ее отсутствие) в первых версиях ОС и как и зачем она менялась впоследствии.

Итак, Android 1.0 — платформа, выпущенная осенью 2008 года вместе со смартфоном HTC Dream (T-Mobile G1). Безопасность обеспечивается пятью ключевыми подсистемами.

1. PIN-код экрана блокировки для защиты от несанкционированного физического доступа.

2. Песочницы (изолированная среда исполнения) для приложений. Каждое приложение запускается от имени созданного специально для него пользователя Linux. Приложение имеет полный контроль над файлами своей песочницы ( /data/data/имя.пакета ), но не может получить доступ к системным файлам и файлам других приложений. Единственный способ покинуть песочницу — получить права root.

3. Каждое приложение обязано указывать список нужных для его работы полномочий в манифесте. Полномочия позволяют использовать те или иные системные API (доступ к камере, микрофону, сети и так далее). Хотя соблюдение полномочий контролируется на нескольких уровнях, включая ядро Linux, явно запрашивать их у пользователя не нужно; приложение автоматически получает все перечисленные в манифесте полномочия, и пользователю остается либо установить приложение, предоставив ему все полномочия, либо не устанавливать его вовсе.

Контроль доступа на основе полномочий не распространяется на карты памяти и USB-накопители. Они используют файловую систему FAT, которая не позволяет назначить права доступа к файлам. Любое приложение может читать содержимое всей карты памяти.

4. Приложения должны быть подписаны ключом разработчика. Во время установки новой версии приложения система сверяет цифровые подписи старой и новой версий приложения и не допускает установку, если они не совпадают. Такой подход позволяет защитить пользователя от фишинга и кражи данных, когда троян прикидывается легитимным приложением и после «обновления» получает доступ к файлам оригинального приложения.

5. Язык Java и виртуальная машина обеспечивают защиту от многих типов атак, перед которыми уязвимы приложения на небезопасных языках, таких как C и C++. Переполнение буфера или повторное использование освобожденной памяти в Java невозможны в принципе.

В то же время значительная часть операционной системы, включая системные сервисы, виртуальную машину, мультимедийные библиотеки, систему рендеринга графики, а также все сетевые подсистемы, написана на тех самых небезопасных C и C++ и работает с правами root. Уязвимость в одном из этих компонентов может быть использована для получения полного контроля над ОС или выполнения DoS-атаки. HTC Dream был «взломан» благодаря тому, что сервис Telnet, предустановленный на смартфон, работал с правами root. Все, что нужно было сделать, — это найти способ его запустить, а затем к смартфону можно было подключиться по сети и получить шелл-доступ с правами суперпользователя.

Читать еще: Пропали приложения на андроиде как вернуть

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

Строго говоря, все эти API не были уязвимостями в прямом смысле слова. Наоборот, они открывали широкие возможности для программистов и, как следствие, пользователей. Но если в 2008-м эти возможности не создавали особых проблем, поскольку рынок смартфонов был ориентирован на энтузиастов и бизнесменов, то уже через несколько лет, когда смартфоны получили распространение среди всех групп населения, стало понятно, что приложения необходимо ограничивать в возможностях.

Перенос приложения AIR с собственным файлом установки на новый сертификат

Приложение AIR, опубликованное как собственный файл установки для конкретной платформы (например, приложение, использующее собственный API платформы), не может быть подписано командой ADT -migrate , поскольку не является файлом air. Для переноса приложения AIR, опубликованного в качестве собственного расширения платформы, на новый сертификат предусмотрена другая процедура:

Создайте обновление приложения.

Убедитесь, что в файле-дескрипторе приложения (app.xml) тег содержит как профиль настольной системы (desktop), так и расширенный профиль настольной системы (extendedDesktop); либо совсем удалите тег из дескриптора приложения.

Упакуйте и подпишите обновленное приложение как файл air при помощи команды ADT -package с новым сертификатом.

Примените сертификат переноса к файлу .air, используя команду ADT -migrate с оригинальным сертификатом (как описано ранее в разделе «Перенос приложения AIR для использования нового сертификата»).

Упакуйте файл .air в виде собственного установочного файла платформы при помощи команды ADT -package с флагом -target native . Поскольку приложение уже подписано, на этом шаге нет необходимости указывать сертификат подписи.

В следующем примере показаны этапы 3–5 этой процедуры. Код вызывает программу ADT с командой -package , затем — с командой -migrate , затем снова с командой -package для упаковки обновленной версии приложения AIR в виде собственного файла установки данной платформы:

Нестандартная установка Google Play

Если после Hard Reset Плей Маркет так и не установился на смартфон, можно попробовать произвести загрузку нестандартным путем. Дело в том, что на китайских аппаратах может быть не предусмотрен сервис GApps. В этом случае обычная инсталляция не приведет к желаемому результату.

В качестве установщика будем использовать менеджер файлов Mobile Go. Порядок действий будет следующим:

Загружаем программу на ПК.
Ищем и скачиваем из сети такие файлы: GoogleServiceFramework.apk, GoogleLoginService.apk и Google Play.apk.
На мобильном устройстве активируем отладку по USB.
Подключаем к компьютеру проблемный гаджет и при необходимости ставим к нему драйвера.
Включаем Mobile Go. Переходим во вкладку My Device и активируем права суперпользователя.
В левом столбце переходим в раздел File, после чего открываем внутреннюю память телефона и ищем там каталог system.
Заходим в папку app и копируем туда ранее скачанные файлы APK, кликнув в верхней панели по кнопке Add. Пока Google Play устанавливается, телефон от ПК отключать категорически запрещается, так как это может повлиять на его дальнейшую работу.
Отсоединяем аппарат от компьютера и перезапускаем его.

После выполнения описанных действий Плей Маркет на Андроиде должен заработать.

Полномочия

Есть два способа ограничить приложения в правах и не дать им влиять на систему и пользовательские данные:

Урезать возможности всех приложений до минимума, как это было сделано в J2ME.
Позволить пользователю контролировать доступные приложению возможности (путь iOS).

Android, несмотря на мощную систему разделения полномочий внутри ОС, не позволял ни того, ни другого. Первые намеки на систему гранулярного контроля полномочий появились только в Android 4.3 вместе со скрытым разделом настроек App Ops.

Скрытое меню App Ops в Android 4.3

С помощью этих настроек пользователь мог отозвать у приложения любые доступные ему полномочия по отдельности. Однако назвать эту систему удобной и дружелюбной пользователю нельзя: управление разрешениями было чересчур гранулярным, приходилось ориентироваться среди десятков разрешений, смысл которых часто оставался непонятен. При этом отзыв любого разрешения мог привести (и часто приводил) к падению приложения, так как в Android просто не было API, который бы позволил программисту понять, имеет его приложение разрешение на выполнение того или иного действия или нет. В итоге систему App Ops удалили из Android уже в версии 4.4.2, и только в Android 6 ей на смену пришла существующая до сих пор система полномочий.

Читать еще: В приложении email произошла ошибка андроид

В этот раз инженеры Google пошли другим путем и объединили смежные полномочия, получив в итоге семь метаполномочий, которые могут быть запрошены прямо во время работы приложения. В основе системы лежал новый API, позволивший программистам проверять доступные приложению полномочия и запрашивать их, когда нужно.

Побочным эффектом такого подхода стала. бесполезность новой системы. Дело в том, что она работала исключительно для приложений, собранных под Android 6.0 и выше. Разработчик приложения мог указать в правилах сборки директиву targetSdkVersion 22 (то есть Android 5.1), и его приложение продолжило бы получать все полномочия в автоматическом режиме.

Google была вынуждена реализовать систему именно таким образом, чтобы сохранить совместимость со старым софтом. По-настоящему система начала действовать только спустя два года, когда Google ввела требование минимального SDK в Google Play, то есть просто запретила публиковать приложения, собранные для устаревших версий ОС. Окончательно решили вопрос только в Android 10: стало возможно отзывать полномочия у софта, собранного для Android 5.1 и ниже.

В Android 11 система полномочий была расширена и теперь позволяет предоставлять разрешение на ту или иную операцию только на один раз. Как только приложение будет свернуто, оно потеряет разрешение, и его придется запрашивать снова.

Одноразовые разрешения в Android 11

Проблема в обновлении приложения лежащего в GP и написанного на Java, на новое приложение AIR. Google play ругается на неправильное название пакета. Но как я понял не устраивает его не просто название apk файла, а идентификатора приложения, так как названия файлов — старого и нового совпадают. Идентификатор указывается в дескрипторе, однако в предыдущем id — есть нижнее подчеркивание, а сборщик AIR на нижнее подчеркивание ругается, и говорит что идентификатор должен состоять только из букв, цифр и точек. Есть ли способ переписать идентификатор после сборки APK.

Также скорее всего имеет место префикс air. Его получают все air приложения, однако скорее всего после установки, ибо при разборке APK в дескрипторе ID указан все еще без air. Простая замена ID в дескрипторе в собранном приложении не помогает, приложение перестает устанавливаться. Магазин говорит что приложение не оптимизировано, после оптимизации — что не подписано, ну а после подписи снова не оптимизировано и т.д.

Вот как решил, может кому пригодится. Все же изменил идентификатор после сборки. Для начала префикс AIR убрал переменной окружения Windows, теперь все приложения мои по умолчанию собираются без него. Но возникла проблема в следующем — у заказчика название приложения в идентификаторе разделялось нижним подчеркиванием, что опять же не допустимый символ для сборщика Air. В общем плюнул на это, собрал APK слитно без нижнего подчеркивания (apkname). Потом декомпилировал его apktool’ом. Вставил нижнее подчеркивание в индентификатор в дескрипторе, там кажется 2 строчки, переименовал папки, которые лежат одна в другой соответсвуя вашему дескриптору — например com/companyname/app_name, и из головной папки, текстовым редактором прошелся поиском по файлам с заменой совпадений appname -> app_name. Потом все тем же Apktool’ом собрал, оптимизировал zipalign’ом, подписал jarsigner’ом и снова оптимизировал. И гугл плей принял )

В связи с этим вопрос, нельзя ли как-то разрешить испозльование нижнего подчеркивания сборщиком? Танцев с бубном можно было бы избежать.

Перенос приложения AIR с собственным файлом установки на новый сертификат

Создайте обновление приложения.

Упакуйте и подпишите обновленное приложение как файл air при помощи команды ADT -package с новым сертификатом.

Начало времен

Читать еще: Установка приложений windows 10 без магазина

1. PIN-код экрана блокировки для защиты от несанкционированного физического доступа.

Перенос на новый сертификат приложения AIR, использующего собственное расширение платформы

Приложение AIR, использующее собственное расширение платформы, не может быть подписано при помощи команды ADT -migrate . Его перенос также не может быть выполнен по процедуре переноса приложения AIR с собственным файлом установки, поскольку оно не может быть опубликовано как промежуточный файл .air. Для переноса приложения AIR, использующего собственное расширение платформы, на новый сертификат предусмотрена другая процедура:

Создайте обновление приложения

Упакуйте и подпишите обновленный собственный файл установки при помощи команды ADT -package . Упакуйте приложение с указанием нового сертификата и включите в команду флаг -migrate с указанием оригинального сертификата.

Для вызова команды ADT -package с флагом -migrate используется следующий синтаксис:

AIR_SIGNING_OPTIONS. Параметры подписи определяют закрытый ключ и сертификат подписи файла AIR. Эти параметры определяют новый сертификат подписи (их описание приводится в разделе «Параметры подписания кода ADT»).

MIGRATION_SIGNING_OPTIONS. Параметры подписи определяют закрытый ключ и сертификат подписи файла AIR. Эти параметры определяют оригинальный сертификат подписи (их описание приводится в разделе «Параметры подписания кода ADT»).

Прочие параметры те же, что применяются при упаковке приложения AIR с собственным файлом установки; они описаны в разделе «Команда ADT package».

В следующем примере иллюстрируется вызов программы ADT с командой -package и флагом -migrate для упаковки обновленной версии приложения AIR, использующего собственное расширение платформы, и для применения к нему подписи переноса:

голоса

Рейтинг статьи