Как узнать, что собирают ваши SDK

Любое требование магазинов о данных сводится к одному списку, и почти никто его не записывает. Ваша политика конфиденциальности, ваша форма Data safety и ваши ответы в App Privacy — это три представления одного и того же списка, поэтому составить его один раз и как следует — это и есть вся работа.

Оба магазина прямо говорят, что поведение SDK считается вашим. Google Play говорит, что сбор данных “includes data collected and handled through any third-party libraries or SDKs used in their apps” («включает данные, собираемые и обрабатываемые через любые сторонние библиотеки или SDK, используемые в приложениях»). Apple просит указать данные, которые “you or your third-party partners collect” («собираете вы или ваши сторонние партнёры»).

Шаг 1 — найдите каждый SDK

Читайте файлы, а не полагайтесь на память:

Платформа	Файлы
Android	build.gradle / build.gradle.kts, libs.versions.toml, AndroidManifest.xml (разрешения, meta-data)
iOS	Podfile, Package.swift, *.pbxproj, Info.plist (строки описания использования), *.entitlements
Flutter	pubspec.yaml
React Native / Expo	package.json, app.json

Учитывайте и транзитивные зависимости, которые вы не выбирали: SDK, подтягивающий рекламную библиотеку, собирает то, что собирает эта библиотека.

Шаг 2 — прочитайте собственное раскрытие каждого поставщика

Большинство серьёзных поставщиков публикуют страницу, где точно сказано, что отправляет их SDK, потому что их клиентам это нужно для тех же самых форм. Эта страница — не пост в блоге и не ответ на форуме — ваш источник.

Firebase — разобранный пример, потому что Google публикует разбивку по продуктам, сопоставленную с категориями App Privacy от Apple:

Продукт Firebase	Что собирает, согласно документации Google
Analytics	App instance ID, пользовательские свойства, события, IP-адрес
Crashlytics	Трассировки стека и состояние приложения в момент сбоя, сведения об устройстве и ОС, а также любые пользовательские ключи, логи и идентификаторы пользователей, которые прикрепляете вы
Cloud Messaging	Push-токен, связанный с идентификатором установки приложения; модель устройства, язык, часовой пояс, версия ОС, идентификатор и версия приложения
Authentication	Генерируемые им идентификаторы, а также адреса электронной почты, номера телефонов и отображаемые имена от включённых вами провайдеров входа
Performance Monitoring	Метрики производительности, такие как время запуска и сетевые задержки, сведения об устройстве и ОС, IP-адрес для географической сегментации
Remote Config	Код страны и языка, часовой пояс, версия ОС, идентификаторы приложения и bundle

Если вы используете Crashlytics, прочитайте эту таблицу дважды: последний столбец отчасти зависит от вас. Пользовательские ключи и идентификаторы пользователей, которые вы прикрепляете к отчётам о сбоях, — это данные, которые вы сами решили отправлять, и они должны быть в вашей политике, описанные вашими словами.

Другие поставщики с опубликованными раскрытиями, к которым стоит обращаться напрямую: рекламные сети (AdMob, AppLovin, Unity, ironSource), инструменты атрибуции (AppsFlyer, Adjust), отчёты об ошибках (Sentry, Bugsnag), покупки (RevenueCat, Adapty) и провайдеры аутентификации.

Шаг 3 — когда поставщик ничего не публикует

Такое бывает, особенно с небольшими библиотеками. Тогда:

• Посмотрите сетевой трафик. Пропустите приложение через прокси и посмотрите, что отправляет SDK. Это единственный метод, с которым не поспоришь, и он закрывает вопрос за полдня.
• Прочитайте исходный код, если он открыт.
• Спросите поставщика письменно и сохраните ответ.
• Подумайте об удалении. Зависимость, поведение которой в отношении данных никто не готов описать, — это риск, который вы несёте ради чужого удобства.

Шаг 4 — превратите список в три документа

Один список, три представления, в таком порядке:

1. Политика конфиденциальности — категории, цели, названные третьи стороны, срок хранения, контакты.
2. Форма Data safety в Play Console — те же факты в виде флажков.
3. App Privacy в App Store Connect — снова те же факты, в категориях Apple.

Заполняйте их по списку, а не друг по другу. Если два документа расходятся, магазин верит SDK: Google Play заявляет, что “when Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action” («когда Google узнаёт о расхождении между поведением вашего приложения и вашей декларацией, мы можем принять соответствующие меры, включая принудительные»).

Как поддерживать актуальность

Событие, которое делает недействительными все три документа, всегда одно и то же: изменилась зависимость. Добавьте одну строку в чек-лист релиза — изменилась ли в этом релизе какая-нибудь зависимость? если да, перепроверьте политику и обе формы, — потому что оба магазина требуют, чтобы эти документы оставались точными, а не просто были точными на момент запуска.

Что здесь делает AppFoyer

Этот метод и автоматизирует наш агент. Направьте ИИ-агента для программирования на репозиторий, и он прочитает эти файлы зависимостей, сопоставит найденное с картой известных SDK и составит черновик политики конфиденциальности с названиями найденных третьих сторон — указывая файл и строку, откуда взят каждый факт, чтобы вы могли проверить его, а не принимать на веру. Без агента те же вопросы задаёт короткая форма.

Результат — черновик, который вы проверяете. Агент не видит библиотеку, которую не распознаёт, и никогда ничего не публикует без вашего клика.

Официальные источники

• Конфиденциальность и безопасность в Firebase и Сбор данных для App Store — Google. Таблица выше взята с этих страниц; авторитетный источник — они, а не эта страница.
• Предоставление информации для раздела Data safety в Google Play — Google Play Console Help
• Сведения о конфиденциальности приложения в App Store — Apple