В чем разница между Bundle и Intent?
Bundle – это класс, реализующий ассоциативный массив, т.е. хранящий пары ключ-значение. Имеет get() и put() методы для примитивов, строк и объектов, которые реализуют интерфейсы Parcelable и Serializable.
Bundle используется для передачи данных между базовыми компонентами.
Также рекомендуется использовать Bundle для передачи данных между процессами, потому что Bundle оптимизирован под маршалинг/демаршалинг.
Intent описывает операцию к исполнению. Интенты используются при старте базовых компонент, например startActivity(intent: Intent) и startService(intent: Intent) .
Intent так же как и Bundle имеет get() и put() методы и используется для передачи данных. Но Intent не реализует ассоциативный массив, а лишь предоставляет интерфейс. Intent имеет внутри объект Bundle, куда делегируются переданные пары и уже Bundle используется для хранения и передачи данных.
Класс Bundle зачем он?
Класс Bundle (с английского — сверток) по сути представляет собой враппер (оболочку) над коллекцией ArrayMap для создания более комфортного в работе контейнера для элементов разных типов, в котором можно разместить любые Parcelabe-объекты и примитивные типы. Класс является потокобезопасным и может использоваться для передачи значений между разными потоками. Доступ к элементам этой коллекции осуществляется, как и в ArrayMap , по парам ключ-значение. Дополнительно класс предоставляет методы по размещению и извлечению типизированных данных и некоторые другие возможности.
Класс широко используется для группировки в одну сущность разнотиповых данных (как например строки, простые числа, булевы значения и др.) для последующей передачи как между отдельными методами одного объекта, так и разными объектами и даже разными компонентами одного приложения в основном в случаях, когда типы передаваемых данных заранее не известны — то есть мы можем передат строку, а можем и число или чт то другое в каждом отдельном случае (в остальных случаях удобнее использовать передачу через конструктор или отдельные аргументы метода).
Так же такой контейнер удобно использовать для передачи результата работы метода, когда нужно вернуть несколько значений разного типа, а создавать POJO-модель нет особого смысла.
Класс широко используется системой, в том числе и для хранения значений при смене состояния, но сам класс не предоставляет функционал такого сохранения, он лишь оболчка для группировки данных в работе других механизмов.
Что внутри APK. App Bundle. Google Play Dynamic Feature
APK — это формат, в котором распространяются и устанавливаются Android приложения. Задумывались что у них внутри? Почему мы уже давно в Google Play загружаем AAB файлы, а не APK? Эта статья является расшифровкой видео, в котором я рассказал что находится внутри APK, что такое App Bundle и зачем поменяли формат распространения приложений в Google Play.
Если вам интересно следить за самыми последними новостями Android разработки и получать подборку интересных статей по этой тематике, тогда вам стоит подписаться на Телеграм-канал Android Broadcast и мой YouTube канал «Android Broadcast»
Структура APK
APK файл — это обычный ZIP архив и любой инструмент, который умеет работать с этим форматом, сможет распаковать содержимое APK. Лучше всего его смотреть через Android Studio. Для этого там есть инструмент, который покажет, что находится внутри, а также размер каждого файла.
Первое что вы заметите внутри APK — это множество файлов classes.dex с номерам. dex файлы — это скомпилированный Java код, который позже трансформируется в специальный Android формат байт кода. Весь Java код из проекта и подключенных библиотек попадает сюда.
Файл AndroidManifest.xml — вся информация о вашем приложении: компоненты, разрешения, требования к устройству и другая информация для системы. Хоть библиотеки и модули в проекте могут содержать свои файлы манифеста, но в итоге он один и объединяется с помощью утилиты Manifest Merger. На канале есть отдельное видео про неё.
Android ресурсы представлены в нескольких местах: папка res, куда попадают файлы: картинки, ресурсы шрифтов, layout‑ы, сырые ресурсы (да‑да, в Android ресурсы можно положить любой файл), а также файл resources.arsc, который содержит ссылки на ресурсы, value ресурсы (строки, размеры и пр.)
В папке libs кладут скомпилированные нативные библиотеки под различные архитектуры процессоров, обычно это ARM V7 и V8, а также x86 и x86–64. Этой папки может не быть, если вы сами или какая‑то из библиотек не содержит нативных библиотек т. е. попросту класть нечего
Папка assets — еще одно место, куда можно положить любые файлы, которые просто будут добавлены в финальное APK. Например, до появления ресурсов шрифтов разработчики складывали их именно туда! Зачем несколько мест? assets позволяют организовать любую структуру папок внутри директории, не накладывает никаких ограничений на имена файлов, а также позволяет работать внутри как с деревом файлов. В свою очередь raw ресурсы подчиняются всем ограничениям ресурсов
Папка META-INF содержит несколько важных файлов, которые содержат информацию и подписи файла, а также проверки, что это именно оригинальный файл от разработчика. За это отвечают 3 файла: CERT.RSA , CERT.SF и MANIFEST.MF
Вы можете увидеть и другие файлы в APK, а также странные файлы в папках, про которые рассказывал ранее. Дело в том, что всё содержимое подключаемых библиотек попадает и в финальный файл приложения. Многие Java библиотеки содержат кучу всего лишнего. Например, я встречал исходный код библиотеки на Java, а другая библиотека добавила README файл из GitHub репозитория.
Universal APK
Теперь давайте разберемся, как сборки доставляются пользователям и какие форматы есть для этого. Первое и самое универсальное решение — одна сборка под все поддерживаемые устройства. Такая сборка называется Universal APK. Её плюс очевиден — пользователю не надо ничего знать про его устройство, чтобы выбрать правильную APK, она всего одна. Минусы сборки — большой размер и хранение на устройстве множества неиспользуемых файлов. Например, нативные библиотеки под неподдерживаемую устройством архитектуру процессора.
Universal APK используют в процессе разработки, но я рекомендую вам уменьшать размер в процессе, чтобы быстрее доставлять сборку на устройство. Также Universal APK публикуют компании на сайте компании, которые не могут размещаться в Google Play, например, альтернативные магазины приложений или те кто попал под санкции.
Multi APK
Подход уже считается устаревшим и приводится лишь как шаг в эволюции распространения Android приложений.
Идея делать сборки меньшего размера, чтобы доставлять их быстрее и занимать на устройстве меньше места, возникла сразу после успеха Android устройств. В Google сразу начали анализировать, что можно убрать из APK. Если рассмотреть отдельное Android устройство, то мы четко знаем его размер экрана, плотность пикселей на экране, поддерживаемую архитектуру процессора (например, ARM‑v8a или x86 инструкции). Фактически, если оставить только нативные библиотеки под архитектуру процессора и графику только для необходимой плотности экрана, то мы уменьшим размер APK, но никак не повлияем на работу приложения.
Вот только остается вопрос: «Как доставлять APK под каждое устройство?». Собрать новую APK из Universal APK не представляется возможным т.к. нужно заново подписывать сборку, а механизм для этого у Google Play на заре Android не было.
В Google выбрали самое простое решение — делегировать разработчикам сборку и подпись нескольких APK. Механизм назвали Split APK. В Gradle вы указываете по каким критериям разбивать сборку и плагин соберет вам несколько APK
android < . splits < density < isEnable = true exclude("ldpi", "mhdpi") compatibleScreens("normal", "large") >abi < isEnable = true isUniversalApk = false include("armeabi-v7a", "arm64-v8a") >>Проблема в одном — чтобы залить их в Google Play у каждой из них должен быть уникальный version code. Вот тут уже разработчикам приходилось все это делать ручками, Google давала рекомендации, но порой все уходили во что горазды.
// Пример расчета versionCode для нескольких сборок в рамках Split APKs android < val abiCodes = mapOf("armeabi-v7a" to 1, "arm64-v8a" to 2) androidComponents < onVariants < variant ->variant.outputs.forEach < output ->val name = output.filters.find < it.filterType == ABI >?.identifier val baseAbiCode = abiCodes.getValue(name) if (baseAbiCode != null) < output.versionCode.set(baseAbiCode * 1000 + output.versionCode.get()) >> > >App Bundle
Новой итерацией создания оптимизированных сборок для Android устройств стал формат App Bundle, который представили в 2018 году. App Bundle представляет из себя архив с кубиками для построения APK. Теперь разработчикам нужно было просто собрать AAB файл вместо APK и загрузить в магазин приложений. Также стало проще и с версионированием — у всех APK из одного App Bundle она теперь одна и та же.
Помимо всего того, что уже было в Multi APK нововведением App Bundle стала возможность скачивать ресурсы только для отдельных локалей на устройстве. Ведь они тоже все не нужны, зачастую мы используем только один язык, разве что с приходом Android 13 появилась возможность менять язык приложений независимо от системы. Эта возможность опциональна и если вы поддерживаете переключение локалей внутри своего приложения независимо от системы, то вам стоит отключить эту опцию:
bundle < language < enableSplit = false >density < enableSplit = true >abi < enableSplit = true >texture < enableSplit = false >>App Bundle не установить на устройство, потому что единственным форматом распространения приложений остается все также APK. Чтобы из AAB файла получить APK надо воспользоваться утилитой bundletoole от Google. На вход ей необходимо передать конфигурацию устройства. В результате вы получите несколько APK файлов. Почему так? Отдельная APK представляет базовую APK, где содержится вся основа приложения, отдельное APK для нативных библиотек под архитектуру процессора, APK с графическими ресурсами и строками и другие APK с различными компонентами. После этого все они устанавливаются на устройство. Подписывать полученные APK вам уже придется самостоятельно.
Установка нескольких APK проходит с помощью специального API PackageInstaller, которое представили в API Level 21. И это важный аспект — ощутить преимущества App Bundle не смогу устройства на Android 4.4 и ниже.
App Bundle — свободный формат с открытым исходным кодом. Любой из магазинов приложений может взять его себе на вооружение, но конечно полноценно сделали это только в Google Play. Поддержка также есть в Huawei App Gallery. Начиная с августа 2021 он является обязательным для всех новых приложение в Google Play и рекомендуй для остальных.
На основе App Bundle реализуется множество возможностей: расширенная проверка и верификация приложений, анализ зависимостей, доставка ассетов для игр и другие.
Google Play App Signing
Чтобы весь механизм заработал прозрачно через магазин приложений, нужно было решить вопрос с подписью приложений. Для этого появился механизм Google Play App Signing. Его суть заключается в том, что ключ для подписи вашего приложения, его называют Signing Key , хранится на защищенном сервере Google, чтобы магазин мог подписать приложение в любой момент. Для новых приложений ключ за вас сам сгенерирует магазин, а для существующих есть процесс передачи ключа и данных для доступа к нему.
Помимо этого вам надо сгенерировать еще один ключ для подписи — Upload Key . Он используется при передачи сборки от разработчика в магазин приложений, чтобы убедиться в том, что именно разработчик приложения загружает его в консоль. Если вы потеряете Upload Key или его украдут, то можно обратиться в Google Play и заменить его на новый.
С одной стороны, звучит все хорошо — Google упростила работу с получением APK из App Bundle. Но это не совсем так, фактически магазин может собрать и изменить финальные APK как ему угодно, добавив или убрав оттуда файлы. Официально заявляют, что они делают оптимизации на стороне Google Play. Так поступают для добавления метаинформации о том, чтобы убедится в подлинности сборке магазином приложений. Но что они могут добавлять еще известно только Google…
Google Play Feature Delivery
Представьте, что у вас есть приложение карт. Вы в него вставили функцию AR навигации, но использует её лишь 5% аудитории. Почему так? Банально в устройстве может не быть камеры, либо не хватает мощности, а может фича и вовсе доступна только по подписке. Библиотеки, связанные с AR весят немало, и получается, что мы имеем функционал, который редко используется, но который качают все пользователи.
Почему бы не сделать так, чтобы мы могли какие‑то части приложения скачивать по запросу? Для этого сделали Google Play Feature Delivery. Вы можете доставлять части своего приложения по запросу либо при выполнение условий на устройстве. Сложность подхода заключается в том, что разработчикам нужно правильно организовать модули и связи их с основным API приложения.
apply plugin: 'com.android.application' // В application модуле указываем все подключаемые dynamic feature приложе android
// Пример dynamic feature модул apply plugin: 'com.android.dynamic-feature' dependencies < // Указываем application модуль в который будет подключаться модуль implementation project(':app') >Dynamic Feature модули могут доставляться несколькими способами:
- Установка вместе с приложением
- Загрузка модуля по запросу
- Установка по условию которыми могут быть требования к железу устройства, версия OpenGL ES, стране, версии Android
- Instant Apps т.е. возможность запуска без установки приложения
Все подробности работы с Dynamic Feature и организации их архитектуры тянет на отдельное видео: архитектура, API, UI/UX. На самом деле я уверен, что такой функционал к себе интегрируют очень редко, но если в вашем приложение он есть, а может вы сами его реализовывали — оставьте комментарий!
Механизм доставки приложений в Google Play прошел огромный путь и продолжает развиваться, сократив размеры приложения и скорость их доставки. На момент написания статья ограничение на размер приложения, загружаемого в Google Play — 150 Мб. Для большинства контента в магазине этого объема хватает с головой, разве что супераппы выходят за его лимиты.
Проблема в текущих реалиях заключается в том, как прозрачно может работать этот механизм с альтернативными магазинами приложений, особенно те, что не имею системных прав. Сейчас пользователю нужно подтверждать установку и обновление каждого приложения вне Google Play, а в случае с App Bundle — это будет несколько отдельных APK. Также встает вопрос как динамически устанавливать модули. В общем, пока без дополнительных полномочий для магазинов приложений в Android, кроме Google Play никому не получится нормально работать с динамической доставкой сборок.
В Android 14 Dev Preview 2 представили новое API в Package Manager, которое позволит запрашивать у пользователя одобрение на установку приложений один раз и до тех пор пока разрешение не отзовует
Поддержка формата публикации мобильных приложений Android App Bundle (AAB)
Внимание! С августа 2021 года публиковать новые приложения в Google Play можно будет только в виде Android App Bundle (AAB).
- Перевод существующей публикации на сборку Android App Bundle
- Публикация нового приложения
Android App Bundle (AAB) — это новый официальный формат публикации Android, который предлагает более эффективный способ создания и выпуска вашего приложения.
Android App Bundle включает в себя весь скомпилированный код и ресурсы вашего приложения, а также перекладывает создание APK и подписки на Google Play. Конечные APK-файлы под конкретные устройства и архитектуры процессоров в этом случае магазин собирает сам. В случае необходимости их можно будет получить потом из консоли разработчика. Пакет Android App Bundle позволяет упростить работу по сборке приложения меньшего размера, что может повысить успешность установки и сократить количество удалений. Пакет имеет расширение файла «.aab».
Магазин уже больше года принимает приложения для загрузки в формате AAB и теперь начинается постепенный отказ от публикации приложений в формате APK, который используется для установки приложений на устройство.
Переходить на новую мобильную платформу 8.3.19 сейчас нет никакой срочности, если вы не планируете выпускать новое приложение в магазине. Обновлять в формате APК существующие приложения можно будет в течение нескольких месяцев и после августа 2021.
Следите за сообщениями от Google.
Сборщик мобильных приложений подготовлен для сборки нового формата. В новой версии разработчику необходимо создать ключ загрузки в настройках поставщика и собрать приложение в новом формате на мобильной платформе версии 8.3.19.52 и выше.
Также исправлен и описан процесс автоматической загрузки результатов сборки приложения как в формате APK, так и в формате AAB.
В документации по сборщику мобильных приложений можно найти новую информацию по ключам подписи и загрузки в настройках поставщика, о сборке приложения в новом формате и об автоматической загрузке приложения в магазин Google Play:
Справка Google по публикации приложений в магазине:
Переход на сборку Android App Bundle в сборщике мобильных приложений и публикацию в магазине Google Play
Прежде всего, обновите сборщик мобильных приложений на версию из последних дистрибутивов мобильной платформы 8.3.19.
После этого загрузите в него непосредственно дистрибутив мобильной платформы 8.3.19. Именно в такой последовательности.
В противном случае старый сборщик может неправильно загрузить в базу новый дистрибутив, что потенциально приведет к ошибкам сборки.
Перевод существующей публикации на сборку Android App Bundle
Шаг 1. Зарегистрируйтесь в сервисе подписания приложений Google Play
1. Откройте Play Console.
2. Выберите приложение.
3. В меню слева нажмите «Выпуск» — «Настройка» — «Целостность приложения«.
После этого будет открыта «Программа подписания приложений».
Шаг 2. Отправьте оригинальный ключ подписи приложения в Google
1. В «Программе подписания приложений» выберите «Экспортировать и загрузить ключ из Java Keystore«.
2. Оригинальный ключ подписи приложения следует выгрузить в сборщике мобильных приложений:
В меню «Сервис» — «Настройка параметров поставщика» откройте вкладку «Параметры для ОС Android» и в группе «Ключ подписи приложений» нажмите ссылку «Экспорт закрытого ключа«.
3. Полученный файл с расширением «.pepk» загрузите на странице «Программа подписания приложений» в Play Console.
Внимание! Не рекомендуется создавать ключ подписи в магазине Google Play, поскольку его нельзя получить из магазина и использовать в сборщике мобильных приложений.
Внимание! Включение автоматической подписки приложения распространяется на весь срок действия вашего приложения.
В целях обеспечения безопасности после регистрации в программе подписания вы не сможете получить копию ключа подписи вашего приложения и не сможете удалить его с серверов Google, не удалив само приложение.
Шаг 3. Создайте ключ загрузки
1. Создайте ключ загрузки:
1) В сборщике мобильных приложений в меню «Сервис» выберите команду «Настройка параметров поставщика«.
2) Откройте вкладку «Параметры для ОС Android» и в группе «Ключ загрузки приложения» нажмите ссылку «Экспорт сертификата ключа«.
2. Полученный файл с расширением «.pem» загрузите в Play Console в «Программе подписания приложений«, там же, где загружали ключ подписи.
В качестве ключа загрузки можно также использовать ключ подписи приложения, но этот способ не рекомендуется, т.к. является менее безопасным.
Внимание! Если вы потеряете свой ключ загрузки или если он будет скомпрометирован, то чтобы отозвать свой старый ключ загрузки и сгенерировать новый, следует связаться с техподдержкой Google.
Поскольку ключ подписи вашего приложения защищен Google, вы можете продолжать загружать новые версии своего приложения в качестве обновлений исходного приложения, даже если вы измените ключи загрузки.
Шаг 4. Завершите регистрацию в сервисе подписания приложений Google Play
1. В программе подписания в магазине нажмите кнопку «Сохранить«.
2. Далее следует принять «Условия использования«.
После этого обновления приложения можно загружать в магазин Google Play только в формате AAB (Android App Bundle).
Шаг 5. Соберите мобильное приложение и отправьте его в Google Play с помощью ключа загрузки
1. В новом сборщике мобильных приложений, в карточке приложения на закладке «Для ОС Android» для отправки приложения в магазин Google Play следует выбрать результат сборки приложения (APK, AAB или собирать все).
Выберите «Все варианты результирующих файлов» или «Только aab-файл (пакет для магазина)«.
2. Сборщик соберет пакет для магазина и подпишет его ключом загрузки.
3. Собранный AAB-файла опубликуйте в магазине.
4. Подготовьте и разверните выпуск вашего приложения в магазине.
Создание публикации нового приложения
Шаг 1. Создайте ключ загрузки и соберите приложение
1. Если еще не создали, то создайте ключ загрузки в настройках поставщика на закладке «Параметры для ОС Android» в сборщике мобильных приложений.
2. Соберите приложение в формате AAB.
Шаг 2. Подготовьте выпуск
1. Подготовьте и внедрите выпуск приложения в магазине Google Play, следуя инструкциям магазина.
2. Выбрав тип версии (закрытая, альфа, бета и т.д.), настройте параметры подписания приложений в разделе «Разрешите Google защищать ключ подписи приложения и управлять им«.
3. Выберите «Экспортировать и загрузить ключ из Java Keystore«.
4. Найдите оригинальный ключ подписи приложения. Его можно выгрузить из настроек поставщика на закладке «Параметры для ОС Android» в сборщике мобильных приложений с помощью команды «Экспорт закрытого ключа«.
5. Полученный файл с расширением «.pepk» загрузите в магазин.
6. Найдите оригинальный ключ загрузки. Его можно выгрузить из настроек поставщика на закладке «Параметры для ОС Android» в сборщике мобильных приложений с помощью команды «Экспорт сертификата«.
7. Полученный файл с расширением «.pem» загрузите в магазин в «Программу подписания приложений» там же, где загружали ключ подписи.
8. Выберите «Обновить».
9. Чтобы продолжить, нужно принять Условия использования и зарегистрироваться в сервисе подписания приложений.
10. Собранный AAB-файл выгрузите из сборщика и опубликуйте в магазине, в созданном выпуске.