Настройка APK-файла
Прежде чем портировать Android-приложение, убедитесь, что оно корректно настроено:
- Придумайте идентификатор Android-приложения — package name — и укажите его в файле build.gradle в поле applicationId. Например, com.example.myapp. Package name привязывается к смартапу и должен быть уникальным в рамках всех проектов Studio. Все следующие APK-файлы для обновления фронтенда смартапа должны содержать один и тот же package name.
- Укажите package version APK-файла в поле versionCode. При каждом обновлении смартапа необходимо повышать версию в package version.
- Чтобы Native App отображался на устройствах, поддержите в проекте Android-атрибуты:
- android:banner — атрибут для загрузки иконки смартапа,
- Category_Leanback_Launcher — фильтр для установки специальной категории, которая отвечает за запуск смартапа.
- android.permission.RECORD_AUDIO — запрещено к использованию на SberBox и Salut TV. Разрешено для использования на SberPortal, SberBoxTop и SberBoxTime;
- android.permission.BIND_VOICE_INTERACTION — запрещено к использованию на всех устройствах;
- android.permission.WRITE_EXTERNAL_STORAGE — запрещено к использованию на всех устройствах.
В трей приложения попадает иконка, которая указана в Manifest.xml приложения. Для Android приложений, начиная с API Version 26 (Android 8.0), нужно дополнительно создать адаптивную иконку. Если у приложений с версией Android 8.0 и выше не указана адаптивная иконка, а только Legacy icon (устаревшая иконка), то у иконок добавляются отступы.
ПАО Сбербанк использует cookie для персонализации сервисов и удобства пользователей.
Вы можете запретить сохранение cookie в настройках своего браузера.Принципиальная разница между app-debug и app-release android?
У меня есть приложение на андроид. Я его тестировал на разных эмуляторах, и так повелось что я постоянно генерировал app-debug, или как такое приложение принято называть дебаг-версия. Эту версию приложения я с легкостью ставил на много реальных устройств, но потом два устройства повели себя не просто странно, а вообще непонятно. Что именно произошло — приложение не грузило ресурсы, вообще никакие — текст картинки,и может что еще, я не видел. Работать с этим приложением на проблемном, как я думал телефоне было невозможно так-как приложение слетало, и указывало что ошибка в строковом ресурсе, который на остальных устройствах был нормальным. Более подробно можете увидеть информацию по поводу этих проблем в моих вопросах: Объясните ошибку android. Дальше я сделал релизную версию приложения, и моя программа работала на всех устройствах. Дальше я начал искать информацию по этому поводу и нашел такой вопрос: Разница между .apk и signed .apk. Ответ на этот вопрос частично ответил на мои некоторые вопросы, но мне все равно не очень понятно что-же так сильно меняется в приложении после нормального подписания, ведь после подписания приложение нашло все ресурсы и работало отлично. Я буду очень благодарен если мне объяснят отличия, на моем примере с моим приложением.
Отслеживать
задан 9 авг 2018 в 14:53
17.9k 11 11 золотых знаков 25 25 серебряных знаков 57 57 бронзовых знаков1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Первый — отлаживаемый, а второй — нет. Это означает, что первый из них выведет все ваши Log.d , а релизная версия — нет. Кроме того, по умолчанию debug-версии компилируются без ProGuard , тогда как release-сборки скомпилированы с использованием ProGuard по умолчанию.
Отслеживать
ответ дан 10 авг 2018 в 4:40
1,859 3 3 золотых знака 15 15 серебряных знаков 24 24 бронзовых знака
а что такое ProGuard ?
10 авг 2018 в 5:53
10 авг 2018 в 6:04-
Важное на Мете
Связанные
Похожие
Подписаться на ленту
Лента вопроса
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
Дизайн сайта / логотип © 2024 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2024.1.3.2953
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Что внутри 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, которое позволит запрашивать у пользователя одобрение на установку приложений один раз и до тех пор пока разрешение не отзовует
Firebase App Distribution: рассылаем Flutter-сборки тестировщикам
CI/CD — это инструмент, позволяющий одной командой рассылать сборки вашего приложения тестировщикам, загружать их в App Store/Google Play, и не только. Ранее многие пользовались Fabric, но со временем были вынуждены мигрировать на Firebase App Distribution, предлагаемый Google. Хорошо это или плохо — время покажет. Мы же сегодня рассмотрим, как настроить эту технологию для рассылки сборок Flutter-приложения на macOS, используя Fastlane.
Когда мы только приступили к изучению данной технологии, то нашли эту статью. Она, бесспорно, полезная. Однако описывает только шаги для конфигурации Android-составляющей Flutter-приложения. Шаги для работы с iOS в ней опущены, а ведь там, как показала практика, есть, где споткнуться. Поэтому данная статья представляет собой перевод, расширенный и дополненный шагами, необходимыми для полноценной конфигурации рассылки как Android-, так и iOS-сборок Flutter-приложения. Итак, поехали.
Проверка подключения к Firebase
Предполагается, что к настоящему моменту ваш проект уже подключен к Firebase. Если вы еще этого не сделали, сейчас самое время. Воспользуйтесь сведениями из документации Firebase, описанными здесь. Обязательно перейдите на вкладку «App Distribution» и нажмите кнопку «Начать работу» — так вы подключите Firebase App Distribution к своему проекту. Позднее вам понадобится уникальный идентификатор вашего приложения в Firebase, который можно найти, перейдя по вкладкам: Настройки проекта → Общие настройки → Идентификатор приложения.
Учтите, что если у вас приложение для двух платформ: iOS и Android, то у каждой платформы будет свой идентификатор, и его нужно будет записать в соответствующей платформе Fastfile (конфигурационный файл для Fastlane). Но обо всем по порядку.
Подготовка командной строки macOS
Если вы не так давно обновились с Mojave (или другой, более старой версии macOS) до Catalina, то вы должны были заметить, что теперь macOS по умолчанию использует zsh вместо bash. В связи с этим вы должны переименовать свой $HOME/.bashrc в $HOME/.zshrc, а также выполнить команду:
chsh -s /bin/zshПосле выполнения этого шага в вашей командной строке вместо характерного для bash «‘$’» должен появиться «‘%’». Если этого не произошло (обычно такое случается, если у пользователя, под которым вы работаете, недостаточно прав), перейдите в Terminal → Preferences, выберите Command (complete path) и введите туда путь:
/bin/zsh
Следующий шаг — настройка Ruby. По умолчанию macOS поставляет свою версию Ruby, в которую вам нельзя ничего устанавливать. Предполагается, что она используется исключительно системой и полностью контролируется Apple. Поэтому вам нужно использовать другую версию Ruby, где никто не будет «бить по рукам» и у вас будет полная свобода в вопросах установки gems.
Для начала установим менеджер версий Ruby. Используем установку через Homebrew:
brew install rbenv ruby-buildДалее вам нужно дописать следующую строку в ваш $HOME/.bashrc или $HOME/.zshrc:
eval "$(rbenv init -)"Не забудьте перезагрузить терминал или выполнить команду:
source $HOME/.bashrcsource $HOME/.zshrc.Теперь установите нужную вам версию Ruby. Список всех версий можно получить командой:
rbenv install -lУстановка нужной версии выполняется следующей командой (предположим, что вы решили установить версию 2.6.5):
rbenv install 2.6.5После установки Ruby делаем ее глобально доступной для использования:
rbenv global 2.6.5Убедимся, что все сделано правильно. Введите команду:
rbenv versionsКоманда выдаст список всех версий Ruby, доступных на рабочей машине, и звездочкой выделит ту, которая в данный момент активна. Если все сделано правильно, то вывод должен выглядеть, например, так:
username-admin ~ % rbenv versions system * 2.6.5 (set by /Users/username/.rbenv/version)Вот теперь можно перейти к Firebase.
Установка Fastlane и Firebase CLI
Установим Fastlane, если у вас его еще нет. Выполним команду:
sudo gem install fastlane -NVУстановим утилиты командной строки Firebase CLI:
curl -sL firebase.tools | bashfirebase loginВ появившемся окне браузера выполните авторизацию через тот Google-аккаунт, в котором создавали проект в Firebase.
Подключение Firebase App Distribution
Теперь рассмотрим процесс подключения Firebase App Distribution к вашим iOS- и Android-проектам. Перейдите в соответствующую подпапку (iOS/Android) в корне вашего Flutter-проекта и выполните команду:
fastlane initНаходясь в той же папке, выполните команду:
fastlane add_plugin firebase_app_distributionТем самым вы подключили плагин Firebase к вашему проекту. Обратите внимание — выполнять эти две команды нужно дважды: отдельно для iOS-проекта, отдельно для Android.
Возможно, с первого раза этот шаг выполнить не удастся. Если у вас в консоли появилось такое сообщение об ошибке:
An error occurred while installing json (2.3.0), and Bundler cannot continue. Make sure that `gem install json -v '2.3.0' --source 'https://rubygems.org/'` succeeds before bundling.То принудительно установите gem необходимой версии:
sudo gem install json -v '2.3.0' --source 'https://rubygems.org/'А затем выполните неудавшуюся команду еще раз. После этого плагин должен благополучно подключиться к проекту.
Последний шаг — отредактировать наши Fastfile, которые находятся в подпапках проекта android/fastlane/ и ios/fastlane/. Вот как могут выглядеть файлы с простейшими lane для отправки сборок тестировщикам на Android:
default_platform(:android) platform :android do desc "Some Android test deployment" lane :distribute_internal_android do gradle(task: "clean assembleRelease") firebase_app_distribution( app: "ID вашего проекта в Firebase", testers: "account1@gmail.com, account2@gmail.com", release_notes: "New Android build", firebase_cli_path: "/usr/local/bin/firebase", apk_path: "../build/app/outputs/apk/release/app-release.apk" ) end endИ iOS, соответственно:
default_platform(:ios) platform :ios do desc "Some iOS test deployment" lane :distribute_internal_ios do build_ios_app( export_options: < method: "ad-hoc", provisioningProfiles: < "com.your.app.bundle.id": "Your sertificate ADHOC" >, signingStyle: "manual" > ) # build_ios_app is a built-in fastlane action. firebase_app_distribution( app: "ID вашего проекта в Firebase", testers: "account1@gmail.com, account2@gmail.com", release_notes: "New iOS build", firebase_cli_path: "/usr/local/bin/firebase" ) end endОбратите внимание — в случае с iOS в данном примере приводится конфигурация для ручного управления сертификатами (manual). Убедитесь, что у вас установлены все необходимые certificates и provisioning profiles (Ad Hoc, App Store, Development).
Рассылка приложения
Перед тем, как делать итоговую сборку, убедитесь, что ваши проекты собраны в релизной конфигурации. Если вы перед отправкой приложения запускали его под дебагом, чтобы убедиться, что все в порядке, то сборка тестировщикам также отправится в отладочной конфигурации. А это значит, что тестировщики ее увидят и даже установят, но при запуске приложение будет крашиться. Чтобы этого не произошло, предварительно соберите приложение в релизном режиме командами:
flutter build apkflutter build iosВпрочем, команду build необходимо выполнять в любом случае. Дело в том, что во время сборки Flutter собирает свои конфигурационные файлы и подтягивает их к платформенным проектам. В том числе, например, редактирует номер сборки/версии, взятый из pubspec.yaml. Без этих конфигурационных файлов вы просто не сможете собрать свои.apk-/.ipa-файлы.
Далее, в зависимости от того, в какой папке вы находитесь, выполните команду:
bundle exec fastlane distribute_internal_androidbundle exec fastlane distribute_internal_iosГотово! Ваши сборки уже собираются для отправки тестировщикам!
Иногда возникает странная ошибка — в консоли Firebase указано, что приглашения отправлены всем тестировщикам, однако некоторым на почту не приходит ничего. Делать сборку и отправлять ее повторно бесполезно. Чтобы это исправить, выберите нужных вам тестировщиков и нажмите «Resend invitation» / «Отправить приглашение еще раз».
После этого сборки начнут послушно прилетать на указанные email-адреса.