Poradniki Formularze sklepów i SDK
Jak sprawdzić, co zbierają Twoje SDK
Powtarzalna metoda, przykład na opublikowanych tabelach Firebase i gdzie szukać w przypadku dostawców, którzy takich tabel nie publikują.
Otwórz plik zależności, wypisz każdy zewnętrzny SDK, a potem przeczytaj stronę ujawnień danych każdego dostawcy — Firebase na przykład publikuje dokładnie, jakie dane zbiera każdy z jego produktów. Ta lista to treść Twojej polityki prywatności i źródło, z którego muszą pochodzić Twoje odpowiedzi w Data safety i App Privacy.
Zrób to zamiast tego w kilka minut
AppFoyer hostuje strony, o których jest ten poradnik — politykę prywatności, regulamin, wsparcie, usuwanie konta i app-ads.txt — na ich własnej subdomenie, bez Twojej własnej domeny i serwera. Jedna aplikacja jest za darmo, a nic, czego wymaga sklep, nigdy nie jest płatne.
Sprawdzono 19 września 2026. Zasady sklepów się zmieniają, czasem bez zapowiedzi. Wszystko poniżej linkuje do oficjalnej dokumentacji i to ona — nie ta strona — jest rozstrzygająca. Jeśli się różnią, rację ma sklep. Ten poradnik jest przetłumaczony z angielskiego; cytaty z dokumentacji sklepów pozostawiono w oryginalnym brzmieniu angielskim.
Każdy wymóg sklepów dotyczący danych sprowadza się do jednej listy, a prawie nikt jej nie spisuje. Twoja polityka prywatności, formularz Data safety i odpowiedzi w App Privacy to trzy wersje tej samej listy — więc porządne sporządzenie jej raz to cała robota.
Oba sklepy wprost mówią, że działanie SDK liczy się jako Twoje. Google Play mówi, że zbieranie danych „includes data collected and handled through any third-party libraries or SDKs used in their apps” (obejmuje dane zbierane i przetwarzane przez biblioteki lub SDK firm zewnętrznych używane w aplikacjach). Apple prosi o wskazanie danych, które „you or your third-party partners collect” (zbierasz Ty lub Twoi partnerzy zewnętrzni).
Krok 1 — znajdź każdy SDK
Czytaj pliki, nie polegaj na pamięci:
| Platforma | Pliki |
|---|---|
| Android | build.gradle / build.gradle.kts, libs.versions.toml, AndroidManifest.xml (uprawnienia, metadane) |
| iOS | Podfile, Package.swift, *.pbxproj, Info.plist (opisy użycia), *.entitlements |
| Flutter | pubspec.yaml |
| React Native / Expo | package.json, app.json |
Uwzględnij zależności przechodnie, których nie wybrałeś: SDK, który dociąga bibliotekę reklamową, zbiera to, co zbiera ta biblioteka.
Krok 2 — przeczytaj ujawnienie każdego dostawcy
Większość poważnych dostawców publikuje stronę, która mówi dokładnie, co wysyła ich SDK, bo ich klienci potrzebują tego do tych samych formularzy. Ta strona — nie wpis na blogu, nie odpowiedź na forum — jest Twoim źródłem.
Firebase to przykład, bo Google publikuje zestawienie dla każdego produktu, przypisane do kategorii App Privacy Apple:
| Produkt Firebase | Co zbiera według dokumentacji Google |
|---|---|
| Analytics | Identyfikator instancji aplikacji, właściwości użytkownika, zdarzenia, adres IP |
| Crashlytics | Stack trace’y i stan aplikacji w chwili awarii, informacje o urządzeniu i systemie, a także wszelkie własne klucze, logi i identyfikatory użytkowników, które dołączasz Ty |
| Cloud Messaging | Token push powiązany z identyfikatorem instalacji aplikacji; model urządzenia, język, strefę czasową, wersję systemu, identyfikator i wersję aplikacji |
| Authentication | Identyfikatory, które generuje, a także adresy e-mail, numery telefonów i nazwy wyświetlane od dostawców logowania, których włączysz |
| Performance Monitoring | Metryki wydajności, takie jak czas uruchamiania i opóźnienia sieci, informacje o urządzeniu i systemie, adres IP do segmentacji geograficznej |
| Remote Config | Kod kraju i języka, strefę czasową, wersję systemu, identyfikatory aplikacji i pakietu |
Jeśli używasz Crashlytics, przeczytaj tę tabelę dwa razy: ostatnia kolumna to częściowo Twoja sprawka. Własne klucze i identyfikatory użytkowników dołączane do raportów o awariach to dane, które sam zdecydowałeś się wysyłać, i należą do Twojej polityki, opisane Twoimi słowami.
Inni dostawcy z opublikowanymi ujawnieniami, do których warto zajrzeć bezpośrednio: sieci reklamowe (AdMob, AppLovin, Unity, ironSource), narzędzia atrybucji (AppsFlyer, Adjust), raportowanie błędów (Sentry, Bugsnag), zakupy (RevenueCat, Adapty) i dostawcy uwierzytelniania.
Krok 3 — gdy dostawca nic nie publikuje
Zdarza się, zwłaszcza w przypadku mniejszych bibliotek. Wtedy:
- Przeczytaj ruch sieciowy. Puść aplikację przez proxy i zobacz, co wysyła SDK. To jedyna metoda, z którą nie da się dyskutować, i rozstrzyga sprawę w jedno popołudnie.
- Przeczytaj kod źródłowy, jeśli jest otwarty.
- Zapytaj dostawcę na piśmie i zachowaj odpowiedź.
- Rozważ usunięcie go. Zależność, której zachowania wobec danych nikt nie chce określić, to ryzyko, które dźwigasz dla czyjejś wygody.
Krok 4 — zamień listę w trzy dokumenty
Jedna lista, trzy wersje, w tej kolejności:
- Polityka prywatności — kategorie, cele, wymienione z nazwy podmioty zewnętrzne, przechowywanie, kontakt.
- Formularz Data safety w Play Console — te same fakty w postaci pól wyboru.
- App Privacy w App Store Connect — znowu te same fakty, w kategoriach Apple.
Wypełniaj je na podstawie listy, nigdy jeden na podstawie drugiego. Gdy dwa się nie zgadzają, sklep wierzy SDK: Google Play stwierdza, że „when Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action” (gdy Google dowie się o rozbieżności między działaniem aplikacji a Twoją deklaracją, możemy podjąć odpowiednie działania, w tym działania egzekucyjne).
Utrzymanie aktualności
Zdarzenie, które unieważnia wszystkie trzy, jest zawsze to samo: zmieniła się zależność. Dopisz jedną linijkę do checklisty wydania — czy w tym wydaniu zmieniła się jakaś zależność? jeśli tak, sprawdź ponownie politykę i oba formularze — bo oba sklepy wymagają, żeby te dokumenty pozostawały dokładne, a nie tylko były dokładne w dniu premiery.
Co robi tutaj AppFoyer
Tę metodę automatyzuje nasz agent. Wskaż agentowi kodującemu repozytorium, a przeczyta te pliki zależności, porówna to, co znajdzie, z mapą znanych SDK i przygotuje politykę prywatności wymieniającą znalezione podmioty zewnętrzne — podając plik i linię, z których pochodzi każdy fakt, żebyś mógł to sprawdzić, zamiast ufać. Bez agenta te same pytania zadaje krótki formularz.
Wynikiem jest szkic, który przeglądasz. Agent nie widzi biblioteki, której nie rozpoznaje, i nigdy niczego nie publikuje bez Twojego kliknięcia.
Źródła oficjalne
- Prywatność i bezpieczeństwo w Firebase oraz Zbieranie danych na potrzeby App Store — Google. Powyższa tabela pochodzi z tych stron; to one są źródłem rozstrzygającym, nie ta.
- Podawanie informacji do sekcji Data safety w Google Play — Centrum pomocy Konsoli Google Play
- Szczegóły prywatności aplikacji w App Store — Apple