Как составить технический чек-лист для запуска мобильного приложения

Как составить технический чек-лист для запуска мобильного приложения? Подготовка технического чек-листа для релиза приложения требует проверки ассоциаций доменов для Universal Links и App Links, аудита файлов AASA и assetlinks.json, проверки инициализации SDK и тестирования параметрической маршрутизации на «чистых» устройствах до отправки сборки в стор.

Чек-лист запуска приложения — это комплексный протокол технического аудита перед публикацией, предназначенный для проверки критически важной мобильной инфраструктуры (включая домены deep linking, жизненный цикл SDK атрибуции и конвейеры восстановления параметров) до коммерческого релиза. Систематическое предпусковое тестирование помогает инженерным командам выявить риски навигации после релиза, дефекты интеграции атрибуции и проблемы готовности к выпуску до выхода на рынок.

Почему проверка Deep Link перед запуском защищает ROI вашего приложения

Коммерческие потери при сбоях в релизе: почему доработка после одобрения вредит росту

Публичный запуск приложения — это ответственный этап разработки. Как только бинарный файл проходит проверку App Store или автоматизированные проверки безопасности Google Play и попадает в продакшн, технические недочеты в инфраструктуре deep linking или атрибуции приводят к серьезным проблемам. Если маркетинговые кампании начинают распространять трекинговые ссылки, а базовая ассоциация доменов настроена неверно, пользователи попадают на стандартные экраны загрузки или ошибки 404 вместо целевых страниц.

Дефекты конфигурации (например, неверная запись Associated Domains или ошибка в идентификаторе пакета в скомпилированном файле) могут потребовать создания новой сборки, обновления версии и повторного прохождения модерации. Этот цикл часто занимает несколько рабочих дней, что приводит к простою маркетингового бюджета и снижению темпов привлечения пользователей в критический период запуска. В отличие от этого, ошибки ассоциации на стороне сервера (например, неверный отпечаток сертификата SHA-256 в файле assetlinks.json или неправильно настроенные пути AASA) часто можно исправить непосредственно на сервере без пересборки приложения, после чего требуется лишь повторная верификация домена.

Предпусковая архитектура: отделение подписи бинарного файла от верификации домена

Устойчивая стратегия предпусковой проверки разделяет компиляцию бинарного файла на стороне клиента и верификацию домена на стороне сервера. В то время как компиляция определяет логику навигации и SDK-хуки, операционные системы подтверждают авторизацию назначения путем получения внешних JSON-деклараций, размещенных на указанных HTTPS-доменах.

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

Установление порогов готовности для Soft Launch и производственных этапов

Фреймворки релиз-инжиниринга требуют наличия детерминированных критериев качества перед выпуском кода. Запуск приложений с поддержкой deep link зависит от верифицированных Universal Links и App Links, если предусмотрена контекстная веб-маршрутизация. Командам, выполняющим поэтапный запуск или географический софт-лонч, следует применять строгие критерии для тестовых сборок:

• Контроль проверки домена: Автоматизированная верификация конечных точек ассоциации доменов в продакшене и на стейджинге через запросы командной строки.
• Контроль восстановления после «холодного» запуска: Верификация восстановления параметров на чистых физических тестовых устройствах после симуляции перехода из стора.
• Контроль безопасности fallback-маршрутов: Подтверждение корректного перехода на главную страницу приложения или веб-лендинг при получении неверных, истекших или измененных строк маршрутизации.

Как провести аудит iOS Universal Links и размещения AASA перед отправкой приложения

Проверка формата JSON apple-app-site-association и HTTPS-заголовков

Universal Links для iOS требуют наличия файла apple-app-site-association (AASA) в формате JSON, надежно размещенного на целевом домене. Операционные системы запрашивают этот файл, чтобы определить, какие URL-пути должны запускать нативное приложение, а не сессию в браузере Safari.

Файл AASA должен располагаться по адресу https://<domain>/.well-known/apple-app-site-association или https://<domain>/apple-app-site-association. Предпусковой аудит должен проверять как HTTP-заголовки ответа, так и корректность тела JSON:

curl -I https://app.example.com/.well-known/apple-app-site-association
curl -fsS https://app.example.com/.well-known/apple-app-site-association | jq .

Первая команда должна возвращать HTTP-статус 200 OK без перенаправлений (редиректы HTTP 301 или 302 приводят к сбою верификации ассоциации iOS). Сервер должен отдавать контент через защищенное HTTPS-соединение с заголовком Content-Type: application/json.

JSON-полезная нагрузка должна строго соответствовать современным спецификациям схемы Apple:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appIDs": [ "TEAMID1234.com.example.app" ],
        "components": [
          {
            "/": "/open/*",
            "?": { "promo": "?*" },
            "comment": "Соответствует маршрутам рекламных кампаний"
          },
          {
            "/": "/help",
            "exclude": true,
            "comment": "Сохраняет веб-маршрутизацию для документации"
          }
        ]
      }
    ]
  }
}

Обход задержек кэширования Apple CDN через права режима разработчика

На iOS 14 и более новых версиях Apple CDN получает и кэширует файл AASA. Apple не дает гарантий обновления в течение 48 часов, и прямого управления сбросом кэша CDN не существует. Устройства проверяют обновления периодически; согласно техническому руководству Apple, установленные приложения проверяют запись примерно раз в неделю, тогда как переустановка приложения может инициировать получение обновленных данных ассоциации.

Для целей разработки команды могут добавить ?mode=developer к своей настройке Associated Domains, включить «Режим разработчика» и «Разработку Associated Domains» в настройках устройства и запустить сборку, подписанную профилем разработчика:

<key>com.apple.developer.associated-domains</key>
<array>
    <string>applinks:app.example.com?mode=developer</string>
</array>

Поскольку этот альтернативный режим требует подписи разработчика, он служит инструментом диагностики, а не способом проверки для TestFlight или продакшена.

Аудит прав доступа бинарного файла с помощью инструментов командной строки macOS

Перед загрузкой архива в TestFlight или App Store Connect убедитесь, что Xcode корректно внедрил настройки Associated Domains во время компиляции:

codesign -d --entitlements :- /path/to/Payload/YourApp.app

Изучите вывод XML, чтобы подтвердить, что ключ com.apple.developer.associated-domains существует, не содержит ошибок форматирования или лишних пробелов и включает ожидаемые производственные домены.

Валидация распространения AASA через запросы к Apple CDN

Перед продвижением сборки в публичный продакшен опросите публичный edge-кэш Apple, чтобы убедиться, что CDN просканировал и подтвердил запись AASA на стороне сервера:

curl -v https://app-site-association.cdn-apple.com/a/v1/app.example.com

Соответствующий ответ CDN является полезным диагностическим сигналом, но его не следует рассматривать как гарантию поведения Universal Links на каждом устройстве. Проверяйте состояние ассоциации непосредственно на устройствах при диагностике готовности к релизу.

Как проверить Android App Links и ассоциации доменов через CLI

Структурирование assetlinks.json с отпечатками ключей релизного хранилища

Android App Links требуют наличия файла декларации Digital Asset Links, размещенного по адресу https://<domain>/.well-known/assetlinks.json. Эта декларация сообщает ОС Android, что указанный мобильный пакет имеет подтвержденное право открывать определенные веб-ссылки.

Файл assetlinks.json должен содержать точный отпечаток сертификата SHA-256 хранилища ключей (keystore), использованного для подписи целевого бинарного файла:

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.app",
      "sha256_cert_fingerprints": [
        "14:6D:E9:DE:0F:70:FF:E5:43:7E:0E:36:4F:18:28:4F:73:EC:82:E6:31:43:18:B3:3E:E6:2B:6A:BD:EF:94:3E"
      ]
    }
  }
]

Чтобы извлечь производственный отпечаток из существующего релизного хранилища, используйте утилиту Java keytool:

keytool -list -v -keystore /path/to/release.keystore -alias release_key

При развертывании через Google Play App Signing убедитесь, что отпечаток, указанный в assetlinks.json, соответствует сертификату ключа подписи приложения (App Signing Key Certificate), указанному в Google Play Console, а не локальному ключу загрузки.

Настройка Intent Filters: изоляция подтвержденных HTTPS App Links от пользовательских схем

В соответствии с руководством Android для разработчиков по добавлению Intent Filters для App Links, файлы манифеста должны изолировать верифицированные фильтры App Link от кастомных схем. Смешивание объявлений пользовательских схем внутри блока фильтра с autoVerify="true" может привести к нарушению верификации хоста в разных версиях Android.

<!-- AndroidManifest.xml: Верифицированный Intent Filter для App Link -->
<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="http" />
    <data android:scheme="https" />
    <data android:host="app.example.com" />
</intent-filter>

<!-- Отдельный Intent Filter для пользовательской схемы -->
<intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="yourapp" />
</intent-filter>

Автоматизация диагностики верификации доменов через Android Debug Bridge (ADB)

После локальной установки кандидата в релиз запустите ручную верификацию домена через Android Debug Bridge (ADB):

adb shell pm set-app-links --package com.example.app 0 all
adb shell pm verify-app-links --re-verify com.example.app

Дайте системе верификации время для завершения сетевых запросов, затем запросите состояние подсистемы верификации для подтверждения одобрения домена:

adb shell pm get-app-links com.example.app

Терминал должен показать статус «verified»:

com.example.app:
    ID: 01234567-89ab-cdef-0123-456789abcdef
    Signatures: [14:6D:E9:DE:0F:70:FF:E5:43:7E:0E:36...]
    Domain verification state:
      app.example.com: verified

Работа с обновленными состояниями верификации доменов в Android 12 и выше

В Android 12 и выше объявленные хосты оцениваются независимо. Если один домен успешно прошел верификацию, приложение может выступать обработчиком по умолчанию для ссылок с этого хоста, даже если другой хост не прошел проверку. В отличие от этого, на Android 11 и ниже верификация доменов работает по принципу «все или ничего»: если любой хост не проходит проверку, автоматическая верификация ссылок может завершиться неудачей для всех хостов в блоке фильтра. Консультация с руководством Android по устранению неполадок App Links поможет выявить несоответствия подписей, бесконечные циклы перенаправлений или сетевые барьеры.

Протоколы сквозного тестирования передачи параметров и восстановления состояния

Критическая разница между «горячим» запуском и восстановлением параметров при отложенном переходе

Предпусковая проверка должна различать два основных состояния жизненного цикла deep link:

• Прямой запуск (Warm Launch): Приложение уже установлено на тестовом устройстве. Переход по Universal Link или App Link напрямую открывает или возобновляет работу приложения, передавая параметры запроса через нативный Intent или делегаты активности пользователя.
• Отложенное восстановление параметров (Cold Launch Post-Install): Приложение не установлено на тестовом устройстве. Переход по ссылке открывает веб-страницу маршрутизации, сохраняет контекст, перенаправляет пользователя в магазин и восстанавливает динамические параметры при первом запуске приложения.

Проверка ранней инициализации SDK без блокировки основного потока

SDK атрибуции и deep linking должны инициализироваться на ранних этапах жизненного цикла приложения для регистрации входящих Intent-хуков. В архитектуре Android инициализация должна происходить в обратном вызове Application.onCreate(), с защитой от повторной инициализации в мультипроцессных средах. В среде iOS конфигурация выполняется в методе application(_:didFinishLaunchingWithOptions:).

Хотя регистрационные хуки выполняются при запуске, тяжелые вычисления и блокирующие операции сетевого ввода-вывода должны оставаться вне основного потока UI Android, чтобы предотвратить предупреждения ANR (Application Not Responding).

Ниже представлена техническая реализация логики предпусковой валидации для архитектур Android (Kotlin) и iOS (Swift). Разработчики могут ознакомиться с документацией по интеграции SDK для получения спецификаций жизненного цикла.

// Android: MainActivity.kt - Логирование Intent и диагностика маршрутизации
package com.example.app

import android.content.Intent
import android.net.Uri
import android.os.Bundle
import android.util.Log
import androidx.appcompat.app.AppCompatActivity
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.listener.AppWakeUpAdapter
import com.opoinstall.api.model.AppData
import org.json.JSONObject

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        auditLaunchIntent(intent, "onCreate")
        processDeepLink(intent)
    }

    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        setIntent(intent)

        auditLaunchIntent(intent, "onNewIntent")
        processDeepLink(intent)
    }

    private fun processDeepLink(intent: Intent?) {
        if (intent == null) return

        OpoInstall.getInstance().getWakeUp(intent, object : AppWakeUpAdapter() {
            override fun onWakeUp(appData: AppData?) {
                if (appData == null) {
                    Log.d(TAG, "Параметры deep link не получены.")
                    return
                }

                val channel = appData.channelCode ?: "organic"
                val customData = appData.data ?: "{}"

                Log.i(TAG, "Маршрут верифицирован - Канал: $channel, Данные: $customData")

                val validatedRoute = validateRoutePayload(customData)
                if (validatedRoute != null) {
                    authorizeRoute(validatedRoute) { isAuthorized ->
                        runOnUiThread {
                            if (isAuthorized) {
                                executeTargetNavigation(validatedRoute)
                            } else {
                                executeLobbyFallback("Маршрут не авторизован или недоступен.")
                            }
                        }
                    }
                } else {
                    runOnUiThread {
                        executeLobbyFallback("Некорректная нагрузка маршрута.")
                    }
                }
            }
        })
    }

    private fun validateRoutePayload(rawJson: String): ValidatedRoute? {
        return try {
            val json = JSONObject(rawJson)
            val scene = json.optString("scene", "")
            val targetId = json.optString("target_id", "")

            val allowedScenes = setOf("event_hub", "promo_detail", "guild_hall")
            if (!allowedScenes.contains(scene)) {
                return null
            }

            if (targetId.isBlank() || targetId.length > 128 || !targetId.matches(Regex("^[A-Za-z0-9_-]+$"))) {
                return null
            }

            ValidatedRoute(scene, targetId)
        } catch (e: Exception) {
            Log.e(TAG, "Ошибка валидации JSON", e)
            null
        }
    }

    private fun authorizeRoute(route: ValidatedRoute, callback: (Boolean) -> Unit) {
        BackendRouteAuthorizer.verifyRouteAuthorization(route.scene, route.targetId) { result ->
            callback(result.isAuthorized && result.isResourceAvailable)
        }
    }

    private fun executeTargetNavigation(route: ValidatedRoute) {
        Log.i(TAG, "Навигация к сцене: ${route.scene}, ID: ${route.targetId}")
    }

    private fun executeLobbyFallback(reason: String) {
        Log.w(TAG, "Переход в лобби: $reason")
    }

    private fun auditLaunchIntent(intent: Intent?, lifecycleStage: String) {
        val action = intent?.action
        val data: Uri? = intent?.data
        Log.d(TAG, "[$lifecycleStage] Action: $action, URI: $data")
    }

    data class ValidatedRoute(val scene: String, val targetId: String)

    companion object {
        private const val TAG = "PreFlightAudit"
    }
}

// iOS: AppDelegate.swift - Аудит Universal Link
import UIKit
import libOpoInstallSDK

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        if userActivity.activityType == NSUserActivityTypeBrowsingWeb, let webpageURL = userActivity.webpageURL {
            NSLog("[PreFlightAudit] URL: %@", webpageURL.absoluteString)
        }

        OpoInstallSDK.continue(userActivity)
        return true
    }

    func getWakeUpParams(_ appData: OpoInstallData?) {
        guard let data = appData else {
            NSLog("[PreFlightAudit] Нет параметров.")
            return
        }

        let channel = data.channelCode ?? "organic"
        let payload = data.data ?? "{}"

        NSLog("[PreFlightAudit] Канал: %@, Данные: %@", channel, payload)

        if let validatedRoute = validateRoutePayload(payload) {
            authorizeRoute(route: validatedRoute) { isAuthorized in
                DispatchQueue.main.async {
                    if isAuthorized {
                        self.navigateToScene(route: validatedRoute)
                    } else {
                        self.navigateToLobbyFallback(reason: "Не авторизовано")
                    }
                }
            }
        } else {
            DispatchQueue.main.async {
                self.navigateToLobbyFallback(reason: "Ошибка валидации")
            }
        }
    }

    private func validateRoutePayload(_ rawJson: String) -> (scene: String, targetId: String)? {
        guard let data = rawJson.data(using: .utf8) else { return nil }

        do {
            if let json = try JSONSerialization.jsonObject(with: data, options: []) as? [String: Any] {
                let scene = json["scene"] as? String ?? ""
                let targetId = json["target_id"] as? String ?? ""

                let allowedScenes = ["event_hub", "promo_detail", "guild_hall"]
                guard allowedScenes.contains(scene) else { return nil }

                let validCharacters = CharacterSet(charactersIn: "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_")
                guard !targetId.isEmpty,
                      targetId.count <= 128,
                      targetId.rangeOfCharacter(from: validCharacters.inverted) == nil else {
                    return nil
                }

                return (scene: scene, targetId: targetId)
            }
        } catch {
            NSLog("[PreFlightAudit] Ошибка десериализации: %@", error.localizedDescription)
        }
        return nil
    }

    private func authorizeRoute(route: (scene: String, targetId: String), completion: @escaping (Bool) -> Void) {
        BackendRouteAuthorizer.shared.verifyRouteAuthorization(scene: route.scene, targetId: route.targetId) { result in
            completion(result.isAuthorized && result.isResourceAvailable)
        }
    }

    private func navigateToScene(route: (scene: String, targetId: String)) {
        NSLog("[PreFlightAudit] Переход к сцене: %@", route.scene)
    }

    private func navigateToLobbyFallback(reason: String) {
        NSLog("[PreFlightAudit] Лобби: %@", reason)
    }
}

Валидация очистки данных и Fallback для некорректных параметров

Поскольку строки URL-запросов и данные deep link поступают из внешней веб-среды, приложения должны рассматривать входящие параметры как недоверенные. Комплексы верификации должны подтверждать, что:

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

Автоматизация проверок перед релизом на «чистых» физических устройствах

Почему эмуляторы должны дополняться валидацией на физических устройствах

Тестирование deep linking и восстановления параметров исключительно на эмуляторах сопряжено со значительными рисками ложноположительных результатов. Эмуляторы используют буфер обмена хост-системы, не имитируют специфические для оператора ограничения сети и не могут воспроизвести специфические для вендоров службы оптимизации аккумулятора, которые могут задерживать фоновые задачи SDK.

Предпусковая проверка должна выполняться на физическом оборудовании с различными версиями ОС и конфигурациями от разных OEM-производителей.

Тестирование сценариев установки: использование параметризованных QR-кодов для внутреннего аудита

Чтобы подтвердить работу отложенного deep linking, команды релиза развертывают двухэтапный фреймворк верификации, проверяющий как локальную механику, так и путь установки из стора:

1. Симуляция локальной установки: Sideload (загрузка) подписанной тестовой или ad-hoc сборки напрямую на чистое физическое устройство для проверки SDK-коллбэков, условий отложенного сопоставления и восстановления параметров без нагрузки стора.
2. Валидация через дистрибуцию стора: Загрузка кандидата в релиз в официальные каналы пре-релиза (TestFlight для iOS и внутренние/закрытые треки Google Play для Android). Сканируйте тестовый QR-код (https://app.example.com/join?channelCode=QA_PreRelease&inviteCode=TEST_USER_99), пройдите путь установки из стора и убедитесь, что установленное приложение корректно получает параметры при первом запуске.

Симуляция «холодного» запуска, перезапуска процессов и возобновления из фона

Полная проверка требует валидации восстановления состояния при различных условиях процесса:

• Холодный старт: Запуск приложения через Universal Link или App Link, когда процесс был полностью выгружен из памяти устройства.
• Возобновление из фона (Warm Resume): Запуск приложения через ссылку, когда процесс приостановлен в фоне, с подтверждением того, что onNewIntent или continueUserActivity перехватывают событие.
• Принудительная выгрузка из памяти: Приостановка приложения, симуляция нехватки памяти через опции разработчика, завершение фонового процесса и проверка того, что состояние deep link восстанавливается предсказуемо при повторном запуске.

[Сборка к релизу готова]
              │
              ▼
[Аудит ассоциации платформ]
   ┌──────────┴──────────┐
   ▼                     ▼
[iOS AASA Check]   [Android DAL Check]
   │                     │
   ▼                     ▼
[Apple CDN Query]  [ADB App-Link Check]
   │                     │
   └──────────┬──────────┘
              ▼
[Установка в песочницу устройства]
              │
              ▼
[Сканирование параметрической ссылки]
              │
              ▼
[Извлечение и валидация параметров SDK]
   ┌──────────┴──────────┐
   ▼                     ▼
[Загрузка целевой сцены] [Fallback-сценарий]
              │
              ▼
[Релиз одобрен]

Матрица технической верификации и смягчения рисков перед запуском

Комплексный чек-лист технического аудита перед полетом

Нижеприведенная матрица суммирует основные контрольные точки валидации инфраструктуры, диагностические команды CLI и протоколы устранения ошибок:

Итоги и фреймворк принятия решений

Успешный запуск мобильного приложения зависит от структурированного выполнения предпусковых проверок. Игнорирование настроек верификации доменов или рабочих процессов восстановления параметров создает риск срыва маркетинговых кампаний и ухудшения процесса онбординга новых пользователей.

Систематически выполняя диагностику командной строки, проводя аудит распространения через Apple CDN и проверяя потоки параметров на физическом оборудовании, инженерные команды минимизируют «слепые зоны» в день релиза. Интеграция проверенных инструментов помогает подтвердить предсказуемость работы deep linking и атрибуции перед публичным выпуском.

Чтобы узнать, как настроить и верифицировать предпусковые рабочие процессы deep linking, изучите документацию по интеграции SDK, ознакомьтесь с центром загрузки SDK OpoInstall, изучите примеры с открытым кодом на GitHub или настройте тестовое приложение в консоли разработчика OpoInstall.

Сопутствующие материалы

• Концепции: Чек-лист запуска приложения, Предпусковая верификация, Восстановление сцены, Инвалидация Apple CDN, Digital Asset Links

• Технологии: Universal Links, Android App Links, Deferred Deep Linking, Associated Domains

• Стандарты: IETF RFC 3986 (URI), Спецификация прав Associated Domains Apple, Протокол Digital Asset Links для Android, Руководство по тестированию безопасности мобильных приложений OWASP (MASTG)

• API: API инициализации SDK OpoInstall, API верификации Intent Filter для Android, Интерфейс маршрутизации iOS NSUserActivity

• Официальная документация и ссылки:

  • Документация Apple: Поддержка Associated Domains

  • Техническая заметка Apple TN3155: Отладка Universal Links

  • Руководство Android: Верификация App Links

  • Руководство Android: Устранение неполадок App Links

  • Руководство OWASP MASTG: Небезопасные Deep Links

  • Примеры интеграции OpoInstall на GitHub