Свой TestFlight для Android

Для разработчиков

Этот раздел — для разработчиков. Владельцу читать его не обязательно: все выводы и решения изложены выше. Ссылки на AOSP ведут на зеркала LineageOS (lineage-24.0 — Android 17) и aosp-mirror, потому что android.googlesource.com во время исследования был недоступен.

Установка идёт только через сессии PackageInstaller, с запасным путём для MIUI

Основной путь — только сессии PackageInstaller: интенты ACTION_INSTALL_PACKAGE и ACTION_UNINSTALL_PACKAGE помечены устаревшими с Android 10 (Intent.java). Хаб объявляет REQUEST_INSTALL_PACKAGES. У этого разрешения уровень signature|appop, пользователь выдаёт его как «Установка неизвестных приложений». Хаб проверяет canRequestPackageInstalls(), а при false открывает Settings.ACTION_MANAGE_UNKNOWN_APP_SOURCES с данными package:<hub> (PackageManager.java; Settings.java). Результат перепроверяется в onResume, а не берётся из результата активности. Id ожидающей сборки сохраняется до перехода в настройки: на Android 11 выдача разрешения убивает процесс (ReVanced Manager #2138).

Параметры сессии — как у F-Droid и Accrescent: MODE_FULL_INSTALL, setAppPackageName, setSize, setInstallReason(INSTALL_REASON_USER). С API 31 добавляется setRequireUserAction(USER_ACTION_NOT_REQUIRED), с API 33 — setPackageSource(PACKAGE_SOURCE_STORE). Файл пишется через openWrite и fsync, все потоки закрываются до commit() (F-Droid SessionInstallManager.kt; PackageInstaller.java). IntentSender для commit() берётся из изменяемого явного PendingIntent (setPackage(packageName), FLAG_MUTABLE). При target 35+ неизменяемый PendingIntent роняет commit() с IllegalArgumentException. При target 34+ изменяемый неявный падает уже при создании. Приёмник регистрируется с RECEIVER_NOT_EXPORTED (PackageInstallerSession.java; Android 14 behavior changes). На STATUS_PENDING_USER_ACTION хаб сразу запускает Intent.EXTRA_INTENT, если он на экране. Иначе он публикует уведомление с PendingIntent.getActivity. Трамплины через сервис или приёмник запрещены с target 31, а при target 37 IntentSender.sendIntent() требует явного разрешения на запуск активности из фона (Android 12 behavior changes; Android 17 behavior changes).

У сессий есть известные грабли, и зрелые магазины обходят их одинаково.

Тихое обновление возможно, лишь когда хаб уже «хозяин» приложения

Окно подтверждения не появляется, только когда выполнены все условия сразу. Сессия создана с USER_ACTION_NOT_REQUIRED. Объявлено UPDATE_PACKAGES_WITHOUT_USER_ACTION (уровень normal). Хаб — installer of record (или update owner, если он назначен) либо обновляет сам себя. Разрешение «Установка неизвестных приложений» выдано. TargetSdk ставящегося APK не ниже порога. И тот же установщик не обновлял тихо тот же пакет в последние 30 секунд (PackageInstallerSession.java; SilentUpdatePolicy.java). Первая установка всегда требует пользователя: isInstallerOfRecord предполагает, что пакет уже стоит. Требования быть на переднем плане в коде нет, так что тихое обновление можно закоммитить из фоновой задачи. Installer of record переписывается при каждой установке через сессию (InstallPackageHelper.java). Поэтому первое обновление сборки, поставленной из Telegram, спросит подтверждение, а следующие — нет.

Для Android 16–17 источники по порогу расходятся (android16-release; lineage-24.0; SessionParams). Оба приложения собираются с targetSdk 35 и проходят при любом прочтении (build.gradle.kts «По любви»; build.gradle.kts «По душе»). Порог растёт каждый год. Поэтому targetSdk надо поднимать вовремя, а STATUS_PENDING_USER_ACTION обрабатывать всегда.

Режим «Автоматически, когда приложение закрыто» на API 34+ делается через commitSessionAfterInstallConstraintsAreMet(sessionId, receiver, InstallConstraints.GENTLE_UPDATE, timeout). Вызывать его может только installer of record. Таймаут — до недели, по истечении приходит STATUS_FAILURE_TIMEOUT (PackageInstaller.java). Update ownership (setRequestUpdateOwnership(true), API 34+) включается только при первой установке и требует ENFORCE_UPDATE_OWNERSHIP. Без этого разрешения сервис молча снимает флаг, хотя страница Android 14 называет INSTALL_PACKAGES (PackageInstallerService.java; Android 14 features). После этого установка из Telegram или браузера покажет напоминание, а согласие снимет владение. Включать ownership имеет смысл, когда файлы перестанут ходить по чатам. На уже стоящие приложения он не действует, пока их не переустановят через хаб.

Хаб обновляет сам себя по ветке isSelfUpdate — даже если его поставили из браузера или Telegram. Процесс при этом убивается. Поэтому итог сессии принимает приёмник из манифеста, а на ACTION_MY_PACKAGE_REPLACED хаб показывает «Хаб обновлён» (Intent.java). После любой фоновой установки хаб перечитывает lastUpdateTime и хеш и сообщает итог. Так Obtainium 1.6 закрыл свои «пропавшие» фоновые обновления (Obtainium v1.6.0). Как тихие обновления ведут себя на MIUI/HyperOS, One UI и в BlueStacks, на устройствах не проверено.

Проверки до скачивания предупреждают большинство ошибок установки

До скачивания хаб сверяет запись каталога с телефоном. Он проверяет имя пакета варианта и minSdk против Build.VERSION.SDK_INT (для «По душе» это 31, то есть Android 12). Проверяет, есть ли файл под первый подходящий ABI из Build.SUPPORTED_ABIS. Сравнивает SHA-256 сертификата из каталога с установленным через PackageManager.hasSigningCertificate(pkg, cert, CERT_INPUT_SHA256) и versionCode — с установленным. Свободного места должно быть не меньше 2–3 размеров файла, потому что файл и его копия в сессии живут одновременно (PackageManager.java). После скачивания хаб проверяет SHA-256 файла против каталога. Потом вызывает getPackageArchiveInfo(path, GET_SIGNING_CERTIFICATES); на API 28–29 нужен ещё GET_SIGNATURES, иначе signingInfo будет null (porter PR #112). Результат null значит, что файл битый. Затем снова сверяются имя пакета и сертификат. Файл с FLAG_TEST_ONLY отклоняется: такие APK делает кнопка Run в Android Studio, а assemble* из командной строки — нет (CommonsWare).

Правила понижения версии: меньший versionCode даёт INSTALL_FAILED_VERSION_DOWNGRADE. Равный versionCode допустим, если baseRevisionCode не ниже установленного (PackageManagerServiceUtils.java). setRequestDowngrade — SystemApi, а INSTALL_ALLOW_DOWNGRADE у обычного приложения снимается. Поэтому хаб откатывать не может. Разработчикам остаётся adb install -r -d, который код пропускает для debuggable-сборок. Данные, оставшиеся после удаления с DELETE_KEEP_DATA, тоже блокируют откат.

Публичных статусов установщика мало, и разные причины сливаются в один. Поэтому хаб разбирает токен INSTALL_FAILED_* из EXTRA_STATUS_MESSAGE (формат "<INSTALL_FAILED_…>: <message>") и читает EXTRA_OTHER_PACKAGE_NAME (PackageManager.java; PackageInstaller.java).

Какие статусы на самом деле приходят при блокировке Samsung, MIUI и Play Защитой, не документировано. Это надо снять на устройствах и логировать.

С Android 11 хаб видит установленные сборки только по явному разрешению

С Android 11 хаб не видит даже приложения, которые поставил сам. Автоматическая видимость односторонняя: установленное приложение видит свой установщик, но не наоборот (AppsFilterUtils.java; Package visibility). Хаб не публикуется в Google Play, поэтому проще объявить QUERY_ALL_PACKAGES. У этого разрешения уровень normal, его объявляют F-Droid, Droid-ify, Aurora и Obtainium (core AndroidManifest.xml). Альтернатива — <queries> со всеми вариантами. Это com.polyubvi.app с суффиксами .dusha, .dushalove, .dev и com.podushe.app с суффиксами .local, .dusha, .dushalove, .dev (build.gradle.kts «По любви»; build.gradle.kts «По душе»). С <queries> каждый новый вариант требует обновления хаба.

Из PackageInfo хаб берёт longVersionCode, versionName, firstInstallTime и lastUpdateTime. Из getInstallSourceInfo() (API 30) он узнаёт installer of record, с API 34 — ещё и update owner. Подпись сверяется через hasSigningCertificate. Идентификатор сборки хаб читает из <meta-data> (флаг GET_META_DATA), который Gradle вписывает через manifestPlaceholders (InstallSourceInfo.java).

Старые сборки с номером 1 уже стоят на телефонах, и по номеру их не различить. Их хаб опознаёт по содержимому. Файл base.apk из applicationInfo.sourceDir доступен на чтение всем (режим 0644) (PackageManagerService.java). Можно посчитать SHA-256 файла или, как Firebase App Distribution, SHA-256 от CRC32 всех записей ZIP (ReleaseIdentifier.java). Результат сверяется с полем legacyHash каталога; на HyperOS и One UI это не проверено. Изменения, сделанные мимо хаба, он ловит двумя способами: перечитывает пакеты в каждом onResume и слушает PACKAGE_ADDED/PACKAGE_REPLACED динамическим приёмником, как Obtainium (MainActivity.kt).

Запуск идёт через getLaunchIntentForPackage. Удаление — через PackageInstaller.uninstall() с REQUEST_DELETE_PACKAGES, и система всегда спрашивает подтверждение через STATUS_PENDING_USER_ACTION (PackageInstallerService.java). Стереть чужие данные нельзя. Вариант clearApplicationUserData с именем пакета скрыт и требует CLEAR_APP_USER_DATA (ActivityManager.java). Поэтому хаб только открывает ACTION_APPLICATION_DETAILS_SETTINGS с package:.

Загрузка и фоновые проверки подчиняются квотам энергосбережения

На API 34+ загрузку по нажатию кнопки лучше запускать как задачу пользовательской передачи данных (UIDT). Для неё нужны JobInfo.Builder.setUserInitiated(true) и разрешение RUN_USER_INITIATED_JOBS. Планировать задачу можно только пока хаб на экране. Ещё нужны setRequiredNetwork, setEstimatedNetworkBytes и setNotification(…, JOB_END_NOTIFICATION_POLICY_DETACH). Такие задачи не подпадают под квоты корзин энергосбережения (UIDT). Google Maps, перейдя на них, получил на 10% более надёжные загрузки (Android Developers Blog). Ниже API 34 подходит срочная задача WorkManager с setForeground(ForegroundInfo(…, FOREGROUND_SERVICE_TYPE_DATA_SYNC)) и разрешением FOREGROUND_SERVICE_DATA_SYNC, как у Aurora (DownloadWorker.kt). При target 35 фоновый dataSync ограничен 6 часами в сутки (FGS timeout). В Android 16 квоты времени распространяются и на задачи WorkManager и DownloadManager (Android 16). Системный DownloadManager не годится. Он пишет только во внешнюю память, не проверяет целостность и удаляет невидимые загрузки через 7 дней (DownloadManager.java).

Сама загрузка идёт через OkHttp в filesDir/apks/<sha256>.part. Докачка — через Range: bytes=N- с If-Range (ETag). Её можно принимать только при ответе 206. Иначе полный ответ допишется к куску и испортит файл — код Aurora прямо предупреждает об этом. Кусок сохраняется, если загрузку остановила система, и удаляется только при отмене пользователем. Затем хаб проверяет SHA-256, переименовывает и разбирает файл, копирует его в сессию с setSize, удаляет после STATUS_SUCCESS и периодически чистит остатки. На время установки нужно около двух размеров файла. Если хаб на target 37 будет качать из локальной сети, например с Mac mini, понадобится ACCESS_LOCAL_NETWORK (Android 17). Публичный HTTPS-хост этого не требует.

Каталог хаб запрашивает условным GET (If-None-Match) при каждом открытии. Кроме того, его запрашивает периодическая задача WorkManager с ограничением NetworkType.CONNECTED: минимум раз в 15 минут, разумно раз в 1–6 часов (WorkManager). Почти всегда ответ — 304 размером несколько сотен байт. Как часто фоновая работа идёт на самом деле, решают корзины App Standby:

В Restricted приложение попадает после 8 дней без взаимодействия на Android 13+ (на Android 12 — после 45 дней). Нажатие на уведомление возвращает его в Active (App Standby Buckets; Power management limits). Хаб, который открывают только по сигналу из чата, почти всё время будет в Rare или Restricted. Поэтому стоит предложить пользователю ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS — вне Google Play это не нарушает правил. FCM не используется: доставка в России в 2026 году ненадёжна, а у части Huawei нет сервисов Google, так что хаб не должен от них зависеть (Хабр). POST_NOTIFICATIONS (Android 13+) запрашивается после первой удачной установки. Перед отправкой уведомления проверяется areNotificationsEnabled() (Notification permission).

У хаба три канала уведомлений. «Новые сборки» — с обычной важностью. «Загрузка и установка» — с низкой, для текущего прогресса. «Ошибки установки» — с обычной. На каждое приложение одно уведомление, и оно обновляется на месте с тем же id. Когда уведомлений несколько, показывается сводка группы (Notification groups). Поля каталога mandatory, minSupportedBuild и withdrawn хаб проверяет на каждом опросе.

Номер, подпись и варианты настраиваются в Gradle один раз

Растущий номер уже есть в рабочих ветках «По душе», например в feature/ios-cmp. versionCode там равен числу минут от 2026-01-01T00:00:00Z до момента сборки. versionName строится как APP_VERSION-ГГММДД.ЧЧММ по московскому времени плюс хвост варианта. Управляют этим свойства -PBUILD_TIME (ISO-момент; тот же момент даёт тот же номер) и -PAPP_VERSION. Эту схему надо перенести в main и в android/ («По любви»), где сейчас versionCode = 1 и versionName = "1.0.0" (build.gradle.kts «По любви»).

Запас у схемы огромный. В конце сентября 2026 года номер около 386 000, а предел int — 2 147 483 647, потолок Google Play — 2 100 000 000 (Version your app). Схема yyMMddHHmm не годится: она переполнила int ещё в 2022 году. Число коммитов тоже не годится: сборки идут из разных веток, а на Mac mini нет .git. Две сборки в одну минуту получат равные номера, и это допустимо: сборка с равным номером ставится поверх. Часы машин сборки должны быть синхронизированы. Откат делается пересборкой старого коммита с новым BUILD_TIME; в каталоге такая сборка получает поле rebuildOf.

В BuildConfig полезно добавить BUILD_NUMBER, GIT_BRANCH и BUILD_TIME рядом с уже существующим GIT_SHA. Но только для сборок на раздачу: метка времени в каждой сборке ломает инкрементальную компиляцию. Идентификатор сборки стоит вписать в манифест: <meta-data android:name="…build_id" android:value="${buildId}"/>. Тогда хаб прочитает его, не запуская приложение. Оба приложения задают release = APPLICATION_ID@VERSION_NAME+VERSION_CODE и dist = GIT_SHA, поэтому в main все сборки попадают в GlitchTip одним релизом (Telemetry.kt «По душе»; Telemetry.kt «По любви»). После переноса номера релизы разделятся сами. Публикация будет создавать релиз GlitchTip с коммитом и писать строку sentryRelease в каталог (GlitchTip CLI).

Общим тестовым ключом становится ~/.android/debug.keystore с Mac mini. SHA-256 его сертификата начинается с A3:AA:35:8D, срок действия — до 2056 года. keytool -storepasswd и -keypasswd меняют только пароли, а не сертификат, так что уже стоящие сборки продолжат обновляться. В Gradle нужен отдельный signingConfigs.create("internal"). Он читает путь и пароли из ~/.gradle/gradle.properties или из переменных окружения каждой машины. В репозитории ключа быть не должно. Сам файл хранится в менеджере паролей или в зашифрованном виде (sops/age) (Sign your app). Сейчас «По душе» подписывает release всегда отладочным ключом. «По любви» подписывает его релизным, если задан RELEASE_STORE_FILE, иначе тоже отладочным. Ключи магазинных сборок com.podushe.app и com.polyubvi.app для Google Play и RuStore должны быть отдельными.

Сборки с ключом Windows можно было бы обновить без удаления через ротацию ключа по схеме v3 (apksigner rotate и --rotation-min-sdk-version 28). Но для горстки телефонов проще разовая переустановка (apksigner). SHA-256 сертификата каждого варианта закрепляется в каталоге и в хабе. У самого хаба — свой постоянный релизный ключ.

Варианты уже различаются applicationIdSuffix. Если два варианта объявят одинаковый authority у ContentProvider или одинаковое своё разрешение, установка второго упадёт с INSTALL_FAILED_CONFLICTING_PROVIDER или DUPLICATE_PERMISSION. Поэтому authority надо строить из ${applicationId} (PackageManager.java). Разные подписи вариантов на рабочем столе делаются через resValue("string", "app_name", …). Но это видимое изменение, и решает его владелец.

Каталог — подписанный JSON рядом с неизменяемыми файлами

Формат каталога объединяет модели F-Droid index-v2 и Zealot (PackageV2.kt; Zealot schema.rb).

Каталог подписывается отдельным файлом catalog.json.minisig (minisign, Ed25519). Открытый ключ зашит в хаб. В доверенный комментарий подписи пишется sequence, и хаб отвергает каталог, у которого sequence меньше последнего увиденного (minisign). Ed25519 в штатной криптографии Android есть только с API 33, а у «По любви» minSdk 28. Поэтому хабу нужен BouncyCastle или Tink (Tink; jsch PR #1160). HTTPS защищает канал, но не защищает от подмены файлов на самом сервере. От этого защищают подписанный каталог, SHA-256 файлов и закреплённый сертификат.

Файлы лежат по неизменяемым путям /<app>/<variant>/<buildId>/<app>-<variant>-<versionName>-<abi>.apk. Имя никогда не переиспользуется для других байтов. ETag и Range nginx отдаёт для статики по умолчанию. MIME-тип APK надо прописать: в стандартном mime.types его нет, а с application/octet-stream некоторые браузеры не предлагают установку (nginx; заметка команды). На дев-сервере /media/ отдаётся с max-age в 7 дней. Поэтому постоянное имя вроде «последняя сборка» там даст устаревший файл (заметка команды; MDN).

location /builds/ {
  types { application/vnd.android.package-archive apk; application/json json; }
  add_header Cache-Control "public, max-age=31536000, immutable";
  add_header Content-Disposition "attachment";
  sendfile on; tcp_nopush on;   # Range и ETag включены по умолчанию; gzip для apk не нужен
}
location = /builds/catalog.json { add_header Cache-Control "no-cache"; }

Хранятся последние 10–20 сборок на вариант, плюс все с флагом recommended и упомянутые в открытых задачах. Остальное удаляется через 60–90 дней. В каталоге при этом остаётся запись с withdrawn или expiresAt, чтобы хаб предупредил тех, у кого такая сборка стоит. При файлах по 30–80 МБ это несколько гигабайт на приложение.

Публикация — один скрипт на машине, которая управляет сборками. Например, tools/macbuild можно расширить до tools/publish-build <app> <variant>. Скрипт работает на управляющем сервере, где есть .git и выход в Telegram.

Размер уменьшают ABI-сплиты: splits { abi { isEnable = true; reset(); include("arm64-v8a", "x86_64"); isUniversalApk = true } }. При раздаче мимо магазина все файлы одной сборки могут иметь один versionCode (Build multiple APKs). Хаб берёт первый элемент Build.SUPPORTED_ABIS, для которого есть файл, а если такого нет — универсальный (NDK ABIs). armeabi-v7a нужен, только если у кого-то 32-битный телефон. Порядок ABI в BlueStacks неизвестен, это надо проверить; универсальный файл страхует. useLegacyPackaging = true сжимает .so и уменьшает загрузку, но увеличивает место после установки (16 KB page sizes). Дельта-обновления не окупают сложность при 50 МБ/с с российского сервера.

Ссылки открывают сборку в хабе, отзывы уходят в трекер

Для ссылок нужны App Links на собственном HTTPS-домене сервера сборок, с assetlinks.json и autoVerify. Пути такие: /app/<app>, /app/<app>/<env> и /b/<buildId>. С Android 12 неподтверждённая веб-ссылка открывается в браузере. Свои схемы вида hub:// мессенджеры часто не делают кликабельными, и у таких ссылок нет запасного веб-пути (App Links; Android 12). Страницы рендерятся сервером с тегами Open Graph. Тогда Telegram показывает превью: приложение, номер, сервер, «Что проверить». Для внешней ссылки Telegram ищет не-браузерное приложение через queryIntentActivities и открывает его, если находит (Browser.java). Увидит ли он хаб при правилах видимости Android 11+, зависит от манифеста Telegram; это надо проверить на устройстве. На запасной странице нужна заметная кнопка «Открыть в приложении для тестировщиков» — ссылка intent:// с запасным URL. Проверка App Links требует сервисов Google. Поэтому в BlueStacks без них ссылки могут не открываться в хабе.

Отзывы хаб отправляет POST-запросом (multipart) на небольшой эндпоинт на российском сервере. Эндпоинт создаёт задачу в трекере: проект по приложению, метка from-hub, buildId в описании, вложения через уже работающий REST, как в trk_attach.py. Короткое сообщение он дублирует в чат. В отзыв уходят текст по шаблону и скриншоты, выбранные через Photo Picker без разрешений (Photo picker). К ним добавляются данные сборки (пакет, versionName, versionCode, build_id, lastUpdateTime) и данные телефона (производитель, модель, версия Android, ABI, язык, свободное место, тип сети). Последними идут имя тестировщика, buildId и sentryRelease. Без сети отзывы ждут в очереди и отправляются повторно. Скриншот чужого приложения хаб сделать не может: колбэк обнаружения скриншота в Android 14 не отдаёт картинку (Screenshot detection).

Obtainium как временная мера. Для каждого варианта нужен постоянный адрес «последняя сборка»: редирект 302 или symlink на свежий файл, с no-cache. Obtainium отслеживает такой адрес как Direct APK Link по ETag или по хешу первых ~1 КБ файла (direct_apk_link.dart; apps_provider.dart). Настройку раздаёт одна ссылка obtainium://apps/<json> (Obtainium deep links).

Производители, BlueStacks и Google добавляют свои барьеры

Проверка разработчиков Google. С июня 2026 года на телефоны с Android 8+ через сервисы Google Play ставится компонент Android Developer Verifier. С 30.09.2026 правило действует в Бразилии, Индонезии, Сингапуре и Таиланде. С 2027 года оно станет глобальным для сертифицированных устройств с Android 7+ (developer verification; The Hacker News). В Android 16 QPR2 и 17 PackageInstaller сообщает причину отказа в EXTRA_DEVELOPER_VERIFICATION_FAILURE_REASON: 0 — неизвестно, 1 — нет сети, 2 — разработчик заблокирован. Установщики с target ≤ 36 сначала получают STATUS_PENDING_USER_ACTION. Установщики с target > 36 сразу получают STATUS_FAILURE_ABORTED, если пользователь не может обойти проверку (PackageInstaller.java).

Регистрация охватывает личность разработчика, имена пакетов и SHA-256 сертификатов. Полный аккаунт стоит $25 и требует документ и карту на имя разработчика; предоплаченные карты не принимаются. Аккаунт ограниченного распространения даёт до 20 устройств, которые подключаются через QR-код или ссылку (она живёт 7 дней). Он работает только с новыми именами пакетов и требует платёжный профиль Google (ADC Help; Limited distribution). Для тестовых вариантов это означало бы новые applicationId, например с суффиксом .test. Принимает ли Google отладочные сертификаты (CN=Android Debug), не документировано. Установка через ADB не проверяется. Registered App Stores в Android 17 рассчитаны на проверенные магазины и частному хабу не подходят (Android Authority).

До выпуска хаба на устройствах нужно проверить шесть вещей, которые источники не закрывают. Первая — какие статусы приходят, когда установку блокируют Samsung, MIUI и Play Защита. Вторая — работают ли тихие обновления и самообновление на HyperOS, One UI и в BlueStacks на Android 13. Третья — какой порядок SUPPORTED_ABIS в BlueStacks. Четвёртая — читается ли sourceDir чужого пакета на HyperOS и One UI. Пятая — открывает ли Telegram ссылки App Links в хабе. Шестая — доходит ли статус сессии до нового процесса после самообновления.