Spełnij wymóg dotyczący docelowego poziomu interfejsu API w Google Play

Przesyłany plik APK musi spełniać wymagania Google Play dotyczące docelowego poziomu interfejsu API.

Od 31 sierpnia 2025 r.:

• Nowe aplikacje i aktualizacje aplikacji przesyłane do Google Play muszą być kierowane na Androida 15 (API na poziomie 35) lub nowszego. Nie dotyczy to aplikacji na Wear OS, na system operacyjny Android Automotive i na Androida TV, które muszą być kierowane na Androida 14 (API na poziomie 34) lub nowszego.
• Istniejące aplikacje muszą być kierowane na Androida 14 (API na poziomie 34) lub nowszego, aby pozostały dostępne dla nowych użytkowników na urządzeniach z systemem operacyjnym Android nowszym niż docelowy poziom API aplikacji. Aplikacje, które są kierowane na Androida 13 (API na poziomie 33) lub starszego, w tym Androida 12 (API na poziomie 31) lub starszego w przypadku Wear OS i Androida TV, będą dostępne tylko na urządzeniach z systemem operacyjnym Android z interfejsem API na docelowym poziomie takim samym jak dla danej aplikacji lub niższym.

Jeśli potrzebujesz więcej czasu na zaktualizowanie aplikacji, możesz poprosić o przedłużenie terminu do 1 listopada 2025 r. Formularze przedłużenia terminu dla Twojej aplikacji będą dostępne w Konsoli Play jeszcze w tym roku.

Przykładowe wyjątki od tych wymagań:

• Aplikacje zawsze prywatne, które są dostępne tylko dla użytkowników w konkretnej organizacji i przeznaczone wyłącznie do dystrybucji wewnętrznej.

Uwaga: nieaktualne aplikacje są niedostępne dla nowych użytkowników urządzeń z nowszymi wersjami Androida. Więcej informacji znajdziesz w sekcji „Wymagania dotyczące dostępności aplikacji” w artykule Wymagania dotyczące docelowego poziomu API w przypadku aplikacji w Google Play w Centrum pomocy Konsoli Play.

Dlaczego warto kierować reklamy na nowsze pakiety SDK?

Każda nowa wersja Androida wprowadza zmiany, które poprawiają bezpieczeństwo i wydajność, a także zwiększają wygodę korzystania z tego systemu. Niektóre z tych zmian dotyczą tylko aplikacji, które wyraźnie deklarują obsługę za pomocą atrybutu targetSdkVersion w pliku manifestu (nazywanego też docelowym poziomem interfejsu API).

Skonfigurowanie aplikacji pod kątem aktualnego poziomu interfejsu API zapewnia użytkownikom korzyści wynikające z tych ulepszeń, ale jednocześnie pozwala uruchamiać ją w starszych wersjach Androida. Kierowanie aplikacji na aktualny poziom interfejsu API umożliwia też korzystanie z najnowszych funkcji platformy, które mogą spodobać się użytkownikom. Ponadto od Androida 10 (API na poziomie 29) użytkownicy widzą ostrzeżenie, gdy po raz pierwszy uruchamiają aplikację, która jest kierowana na Androida 5.1 (API na poziomie 22) lub starszego.

W tym dokumencie znajdziesz najważniejsze informacje, które pomogą Ci zaktualizować docelowy poziom interfejsu API, aby spełnić wymagania Google Play. Instrukcje znajdziesz w sekcjach poniżej, w zależności od tego, do której wersji przeprowadzasz migrację.

Uwaga: jeśli plik Gradle zawiera wpisy manifestu, możesz potwierdzić lub zmienić bieżącą wartość targetSdkVersion w pliku Gradle aplikacji zgodnie z opisem w artykule Konfigurowanie kompilacji. Możesz też użyć atrybutu android:targetSdkVersion w pliku manifestu, jak opisano w dokumentacji elementu manifestu <uses-sdk>.

Przejście z Androida 12 i nowszych wersji (poziom API 31) na nowszą wersję

Aby zaktualizować aplikację i kierować ją na nowszą wersję Androida, zapoznaj się z odpowiednią listą zmian w zachowaniu:

• Zmiany w działaniu Androida 13
• Zmiany w działaniu Androida 14
• Zmiany w działaniu Androida 15
• Zmiany w działaniu Androida 16

Przejście z Androida 11 (poziom API 30) na Androida 12 (poziom API 31)

Zabezpieczenia i uprawnienia

• Bluetooth: musisz zastąpić deklaracje uprawnień BLUETOOTH i BLUETOOTH_ADMIN uprawnieniami BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE lub BLUETOOTH_CONNECT. Nie musisz już wysyłać LOCATION próśb o uprawnienia do wykonywania operacji Bluetooth w czasie działania aplikacji.
• Lokalizacja: użytkownicy mogą zażądać, aby aplikacje pobierały tylko informacje o przybliżonej lokalizacji. Za każdym razem, gdy wysyłasz prośbę o ACCESS_FINE_LOCATION, musisz też wysłać prośbę o uprawnienie ACCESS_COARSE_LOCATION.
  • Filtry intencji: jeśli Twoja aplikacja zawiera aktywności, usługi lub odbiorniki, które używają filtrów intencji, musisz jawnie zadeklarować atrybut android:exported dla tych komponentów.
• Hibernacja: aplikacje mogą zostać wprowadzone w stan hibernacji, jeśli nie są używane przez pewien czas. W trybie hibernacji uprawnienia w czasie działania i pamięć podręczna aplikacji są resetowane, a Ty nie możesz uruchamiać zadań ani alertów. Możesz sprawdzić stan hibernacji aplikacji.
• Zmienność intencji oczekującej: musisz określić zmienność każdego obiektu PendingIntent tworzonego przez aplikację.

Interfejs użytkownika

• Powiadomienia niestandardowe: powiadomienia z niestandardowymi widokami treści nie będą już zajmować całego obszaru powiadomień. Zamiast tego system zastosuje standardowy szablon. Ten szablon zapewnia, że niestandardowe powiadomienia mają taki sam wygląd jak inne powiadomienia we wszystkich stanach. Działanie to jest niemal identyczne z działaniem Notification.DecoratedCustomViewStyle.
• Zmiany w weryfikacji linków do aplikacji na Androida: jeśli używasz weryfikacji linków do aplikacji na Androida, upewnij się, że filtry intencji zawierają kategorię BROWSABLE i obsługują schemat HTTPS.

Wydajność

• Ograniczenia dotyczące uruchamiania usług na pierwszym planie: aby kierować aplikację na Androida 12 lub nowszego, nie możesz uruchamiać usług na pierwszym planie, gdy aplikacja działa w tle, z wyjątkiem kilku szczególnych przypadków. Jeśli aplikacja działająca w tle spróbuje uruchomić usługę działającą na pierwszym planie, wystąpi wyjątek (z wyjątkiem kilku szczególnych przypadków).

  Rozważ użycie biblioteki WorkManager do planowania i rozpoczynania przyspieszonej pracy, gdy aplikacja działa w tle. Aby wykonać działania wymagające natychmiastowej reakcji, o które prosi użytkownik, uruchamiaj usługi na pierwszym planie w ramach alarmu precyzyjnego.

• Ograniczenia dotyczące powiadomień: gdy użytkownicy klikają powiadomienia, niektóre aplikacje uruchamiają komponent, który rozpoczyna działanie, z którym użytkownik wchodzi w interakcję. Ten komponent aplikacji jest nazywany trampoliną powiadomień.

  Aplikacje nie mogą rozpoczynać działań z usług ani odbiorników transmisji, które są używane jako trampoliny powiadomień. Gdy użytkownik kliknie powiadomienie lub przycisk działania w powiadomieniu, aplikacja nie może wywoływać funkcji startActivity() w usłudze ani w odbiorniku transmisji.

Zobacz pełny zestaw zmian, które mają wpływ na aplikacje kierowane na Androida 12 (API na poziomie 31).

Przejście z wersji starszej niż Android 11 (poziom API 30)

Wybierz wersję Androida, z której chcesz przenieść dane:

Przejście na Androida 5 (poziom API 21)

Zapoznaj się ze stronami dotyczącymi zmian w działaniu w przypadku poszczególnych wersji, aby upewnić się, że Twoja aplikacja uwzględnia zmiany wprowadzone w tych wersjach:

• Android 5.0 (poziom API 21)
• Android 4.4 (poziom API 19).
• Android 4.1.x (poziom API 16)

Aby kontynuować, postępuj zgodnie z instrukcjami w następnej sekcji.

Migracja do Androida 6 (poziom interfejsu API 23)

W przypadku aplikacji kierowanych na Androida 6.0 i nowsze wersje platformy obowiązują te zasady:

• Uprawnienia czasu działania

  • Niebezpieczne uprawnienia są przyznawane tylko w momencie uruchomienia. Interfejsy przepływów muszą umożliwiać przyznawanie tych uprawnień.

  • W miarę możliwości zadbaj o to, aby aplikacja była przygotowana na odrzucenie próśb o przyznanie uprawnień. Jeśli na przykład użytkownik odrzuci prośbę o dostęp do GPS-u urządzenia, upewnij się, że aplikacja może kontynuować działanie w inny sposób.

Pełną listę zmian wprowadzonych w Androidzie 6.0 (poziom interfejsu API 23) znajdziesz na stronie Zmiany w działaniu w przypadku tej wersji platformy.

Aby kontynuować, postępuj zgodnie z instrukcjami w następnej sekcji.

Przejście na Androida 7 (poziom interfejsu API 24)

W przypadku aplikacji kierowanych na Androida 7.0 i nowsze wersje platformy obowiązują te kwestie:

• Uśpienie i czuwanie aplikacji

  Projektuj aplikacje pod kątem zachowań opisanych w artykule Optymalizacja pod kątem funkcji Uśpienie i Czuwanie aplikacji, który obejmuje stopniowe zmiany wprowadzane w kilku wersjach platformy.

  Gdy urządzenie jest w trybie uśpienia lub czuwania aplikacji, system działa w ten sposób:

  • Ogranicza dostęp do sieci
  • odkłada alarmy, synchronizacje i zadania;
  • Ogranicza skanowanie GPS i Wi-Fi
  • Ogranicza wiadomości o normalnym priorytecie w Komunikacji w chmurze Firebase.

• Zmiany uprawnień

  • System ogranicza dostęp do prywatnych katalogów aplikacji.
  • Udostępnienie file:// identyfikatora URI poza aplikacją powoduje wywołanie FileUriExposedException. Jeśli musisz udostępniać pliki poza aplikację, zaimplementujFileProvider

• System uniemożliwia łączenie z bibliotekami innymi niż NDK.

Pełną listę zmian wprowadzonych w Androidzie 7.0 (poziom API 24) znajdziesz na stronie Zmiany zachowania w przypadku tej wersji platformy.

Aby kontynuować, postępuj zgodnie z instrukcjami w następnej sekcji.

Migracja do Androida 8 (poziom 26 interfejsu API)

W przypadku aplikacji kierowanych na Androida 8.0 i nowsze wersje platformy obowiązują te kwestie:

• Limity wykonywania w tle
  • System ogranicza usługi dla aplikacji, które nie są uruchomione na pierwszym planie.
    • startService() zgłasza teraz wyjątek, gdy aplikacja próbuje go wywołać, a startService() jest zabronione.
    • Aby uruchomić usługi na pierwszym planie, aplikacja musi używać startForeground() i  startForegroundService().
    • Dokładnie zapoznaj się ze zmianami wprowadzonymi w interfejsie JobScheduler API, które zostały opisane na stronie dotyczącej zmian w zachowaniu w Androidzie 8.0 (poziom 26 interfejsu API).
    • Firebase Cloud Messaging wymaga pakietu SDK Usług Google Play w wersji 10.2.1 lub nowszej.
    • W przypadku korzystania z  Komunikacji w chmurze Firebase dostarczanie wiadomości podlega limitom wykonywania w tle. Jeśli po otrzymaniu wiadomości konieczne jest wykonanie pracy w tle, np. synchronizacja danych w tle, aplikacja powinna planować zadania za pomocą Firebase Job Dispatcher lub JobIntentService. Więcej informacji znajdziesz w  dokumentacji Firebase Cloud Messaging.
  • Komunikaty ogólne
    • Implicite transmisje są ograniczone. Informacje o obsłudze zdarzeń w tle znajdziesz w dokumentacji interfejsu JobScheduler API.
  • Ograniczenia dotyczące lokalizacji w tle
    • Aplikacje działające w tle mają ograniczony dostęp do danych o lokalizacji.
      • Na urządzeniach z usługami Google Play używaj zintegrowanego dostawcy lokalizacji, aby okresowo otrzymywać aktualizacje lokalizacji.
• Kanały powiadomień
  • Właściwości przerywania powiadomień należy definiować dla każdego kanału osobno.
  • Aby powiadomienia się wyświetlały, musisz przypisać je do kanału.
  • Ta wersja platformy obsługuje NotificationCompat.Builder.
• Prywatność
  • ANDROID_ID jest ograniczony do klucza podpisywania aplikacji.

Pełną listę zmian wprowadzonych w Androidzie 8.0 (poziom interfejsu API 26) znajdziesz na stronie Zmiany zachowania w przypadku tej wersji platformy.

Migracja z Androida 8 (API 26) na Androida 9 (API 28)

• Zarządzanie zasilaniem
  • Zasobniki stanu gotowości aplikacji wprowadzają nowe ograniczenia działania w tle na podstawie zaangażowania w aplikację, takie jak odroczone zadania, alarmy i limity wiadomości o wysokim priorytecie.
  • Ulepszenia oszczędzania baterii zwiększają ograniczenia dotyczące aplikacji w trybie gotowości.
• Uprawnienia usługi działającej na pierwszym planie
  • Musisz poprosić o zwykłe uprawnienia FOREGROUND_SERVICE (nie o uprawnienia w czasie działania).
• Zmiany w zakresie prywatności
  • Ograniczony dostęp do czujników w tle
  • Ograniczony dostęp do rejestru połączeń, obecnie w grupie uprawnień CALL_LOG
  • Ograniczony dostęp do numerów telefonów, wymagający uprawnień READ_CALL_LOG
  • Ograniczony dostęp do informacji o Wi-Fi

Pełną listę zmian wprowadzonych w Androidzie 9.0 (poziom interfejsu API 28) znajdziesz w sekcji Zmiany zachowania.

Przejście z Androida 9 (poziom 28 interfejsu API) na Androida 10 (poziom 29 interfejsu API)

• Powiadomienia z intencją pełnoekranową
  • Musisz poprosić o zwykłe uprawnienia USE_FULL_SCREEN_INTENT (a nie o uprawnienia w czasie działania).
• Obsługa urządzeń składanych i urządzeń z dużym ekranem
  • Wiele aktywności może być jednocześnie w stanie „wznowiono”, ale tylko jedna z nich jest aktywna.
    • Ta zmiana wpłynie na działanie onResume() i onPause().
    • Nowa koncepcja cyklu życia „najwyżej wznawiany”, którą można wykryć, subskrybując onTopResumedActivityChanged().
      • Tylko jedna aktywność może być „najwyższą wznowioną”.
  • Gdy wartość parametru resizeableActivity jest ustawiona na false, aplikacje mogą dodatkowo określać parametr minAspectRatio , który automatycznie dodaje do aplikacji paski po bokach w przypadku węższych proporcji obrazu.
• Zmiany w zakresie prywatności
  • Zakres przechowywania
    • Dostęp do pamięci zewnętrznej jest ograniczony tylko do katalogu aplikacji i określonych typów multimediów utworzonych przez aplikację.
  • Ograniczony dostęp do lokalizacji, gdy aplikacja działa w tle, co wymaga zgody ACCESS_BACKGROUND_LOCATION.
  • Ograniczony dostęp do identyfikatorów, których nie można zresetować, takich jak IMEI i numer seryjny.
  • Ograniczony dostęp do informacji o aktywności fizycznej, takich jak liczba kroków użytkownika, wymagający uprawnień ACTIVITY_RECOGNITION.
  • Ograniczony dostęp do niektórych interfejsów API telefonii, Bluetootha i Wi-Fi, wymagający ACCESS_FINE_LOCATION zezwolenia.
  • Ograniczony dostęp do ustawień Wi-Fi
    • Aplikacje nie mogą już bezpośrednio włączać ani wyłączać Wi-Fi. Muszą to robić za pomocą paneli ustawień.
    • Ograniczenia dotyczące inicjowania połączenia z siecią Wi-Fi, wymagające użycia WifiNetworkSpecifier lub WifiNetworkSuggestion.

Przejście z Androida 10 (poziom 29 interfejsu API) na Androida 11 (poziom 30 interfejsu API)

• Prywatność
  • Wymuszanie dostępu do pamięci w określonym zakresie : aplikacje powinny korzystać z modelu dostępu do pamięci w określonym zakresie, w którym pliki specyficzne dla aplikacji, multimedia i inne typy plików są zapisywane i dostępne w wyznaczonych lokalizacjach.
  • Automatyczne resetowanie uprawnień: jeśli użytkownicy nie korzystają z aplikacji przez kilka miesięcy, system automatycznie resetuje jej uprawnienia dostępu do danych wrażliwych. Nie powinno to mieć wpływu na większość aplikacji. Jeśli Twoja aplikacja działa głównie w tle bez interakcji z użytkownikiem, możesz poprosić użytkowników o wyłączenie automatycznego resetowania.
  • Dostęp do lokalizacji w tle: aplikacje muszą oddzielnie prosić o dostęp do lokalizacji na pierwszym planie i w tle. Zezwolenie na dostęp do lokalizacji w tle można przyznać tylko w ustawieniach aplikacji, a nie w oknach z prośbą o dostęp do lokalizacji w czasie działania.
  • Widoczność pakietu: gdy aplikacja wysyła zapytanie o listę zainstalowanych aplikacji i usług na urządzeniu, zwracana lista jest filtrowana.
    • Jeśli korzystasz z usług zamiany tekstu na mowę lub rozpoznawania mowy, musisz dodać do pliku manifestu elementy zapytań dotyczące tych usług.
• Bezpieczeństwo
  • Skompresowane pliki `resource.arsc` nie są już obsługiwane
  • Schemat podpisywania plików APK w wersji 2 jest teraz wymagany. Ze względu na zgodność wsteczną deweloperzy powinni nadal podpisywać aplikacje według schematu podpisu plików APK w wersji 1.
  • Ograniczenie dotyczące interfejsu innego niż SDK. Używanie interfejsów innych niż SDK nie jest zalecane w przypadku aplikacji kierowanych na poziom API 30, ponieważ niektóre z tych interfejsów są teraz blokowane. Pełną listę zablokowanych interfejsów innych niż SDK znajdziesz w artykule Interfejsy inne niż SDK, które są teraz blokowane w Androidzie 11.

Pełną listę zmian wprowadzonych w Androidzie 11 (poziom API 30) znajdziesz na stronie Zmiany w działaniu.

Kontynuuj aktualizację do interfejsu API 31, postępując zgodnie z instrukcjami w poprzedniej sekcji.

Modernizowanie aplikacji

Podczas aktualizowania docelowego poziomu interfejsu API aplikacji rozważ wprowadzenie najnowszych funkcji platformy, aby zmodernizować aplikacje i zadowolić użytkowników.

• Aby w pełni wykorzystać możliwości aparatu, możesz użyć biblioteki CameraX, która jest w wersji beta.
• Używaj komponentów Jetpack, aby stosować sprawdzone metody, nie musieć pisać powtarzalnego kodu i upraszczać złożone zadania, dzięki czemu możesz skupić się na kodzie, który jest dla Ciebie ważny.
• Używaj Kotlina, aby pisać lepsze aplikacje szybciej i z mniejszą ilością kodu.
• Przestrzegaj wymagań i sprawdzonych metod dotyczących prywatności.
• Dodaj do aplikacji obsługę ciemnego motywu.
• Dodaj do aplikacji obsługę nawigacji przy użyciu gestów.
• Przenieś aplikację z Google Cloud Messaging (GCM) do najnowszej wersji Komunikacji w chmurze Firebase.
• korzystać z zaawansowanego zarządzania oknami,
  • obsługiwać większe formaty obrazu (ponad 16:9), aby wykorzystać najnowsze osiągnięcia w zakresie sprzętu; Sprawdź, czy aplikacja zmienia rozmiar, aby wypełnić dostępną przestrzeń ekranu. Deklaruj maksymalny współczynnik proporcji tylko w ostateczności. Więcej informacji o maksymalnych współczynnikach proporcji znajdziesz w sekcji Deklarowanie obsługi ekranów o ograniczonej wielkości.
  • Dodaj obsługę wielu okien, aby zwiększyć produktywność aplikacji i zarządzać wieloma wyświetlaczami.
  • Jeśli zminimalizowana aplikacja poprawi komfort użytkowników, dodaj obsługę obrazu w obrazie.
    • Optymalizacja pod kątem urządzeń z wycięciem na wyświetlaczu.
    • Nie zakładaj wysokości paska stanu. Zamiast tego użyj interfejsów WindowInsets i View.OnApplyWindowInsetsListener. Więcej informacji znajdziesz w filmie z konferencji droidcon NYC 2017.
    • Nie zakładaj, że aplikacja zajmuje całe okno. Zamiast tego potwierdź lokalizację za pomocą View.getLocationInWindow(), a nie View.getLocationOnScreen(). * Podczas obsługi MotionEvent używaj MotionEvent.getX() i MotionEvent.getY(), a nie MotionEvent.getRawX() ani MotionEvent.getRawY().

Sprawdzanie i aktualizowanie pakietów SDK i bibliotek

Sprawdź, czy zależności pakietu SDK innej firmy obsługują interfejs API 31: niektórzy dostawcy pakietów SDK publikują tę informację w swoim pliku manifestu, a w innych przypadkach konieczne będzie dodatkowe sprawdzenie. Jeśli używasz pakietu SDK, który nie obsługuje interfejsu API 31, priorytetowo potraktuj współpracę z dostawcą pakietu SDK w celu rozwiązania problemu.

Pamiętaj też, że targetSdkVersion Twoja aplikacja lub gra może ograniczać dostęp do prywatnych bibliotek platformy Android. Więcej informacji znajdziesz w artykule NDK Apps Linking to Platform Libraries (Aplikacje NDK łączące się z bibliotekami platformy).

Sprawdź też wszelkie ograniczenia, które mogą występować w używanej wersji biblioteki pomocy Androida. Jak zawsze musisz zadbać o zgodność głównej wersji Biblioteki pomocy Androida z compileSdkVersion Twojej aplikacji.

Zalecamy wybranie wersji targetSdkVersion mniejszej lub równej głównej wersji biblioteki pomocy. Zachęcamy do zaktualizowania biblioteki pomocy do najnowszej, zgodnej wersji, aby korzystać z najnowszych funkcji związanych ze zgodnością i poprawek błędów.

Testowanie aplikacji

Po zaktualizowaniu poziomu interfejsu API i funkcji aplikacji należy przetestować niektóre podstawowe przypadki użycia. Poniższe sugestie nie są wyczerpujące, ale mają na celu ułatwienie Ci procesu testowania. Sugerujemy przetestowanie:

• Aplikacja kompiluje się do interfejsu API 29 bez błędów i ostrzeżeń.

• Aplikacja ma strategię na wypadek, gdy użytkownik odrzuci prośby o uprawnienia, i wyświetla prośby o uprawnienia. Aby to zrobić:

  • Otwórz ekran Informacje o aplikacji i wyłącz wszystkie uprawnienia.
  • Otwórz aplikację i upewnij się, że nie ulega awarii.
    • Przeprowadź testy podstawowych przypadków użycia i sprawdź, czy wymagane uprawnienia są ponownie wyświetlane.

• Obsługuje tryb Doze z oczekiwanymi wynikami i bez błędów.

  • Za pomocą adb wprowadź urządzenie testowe w tryb uśpienia, gdy aplikacja jest uruchomiona.
    • Przetestuj wszystkie przypadki użycia, które wywołują wiadomości Komunikacji w chmurze Firebase.
    • Przetestuj wszystkie przypadki użycia, które korzystają z alarmów lub zadań.
    • Wyeliminuj zależności od usług działających w tle.
  • Ustawianie aplikacji w trybie gotowości
    • Przetestuj wszystkie przypadki użycia, które wywołują wiadomości Komunikacji w chmurze Firebase.
    • Testuj wszystkie przypadki użycia, w których wykorzystywane są alarmy.

• Obsługuje robienie nowych zdjęć i nagrywanie filmów

  • Sprawdź, czy aplikacja obsługuje ograniczone ACTION_NEW_PICTURE i ACTION_NEW_VIDEO transmisje (czyli przeniesione do zadań JobScheduler) prawidłowo.
  • Upewnij się, że wszystkie kluczowe przypadki użycia, które zależą od tych zdarzeń, nadal działają.

• Obsługuje udostępnianie plików innym aplikacjom. Testuj dowolny przypadek użycia, w którym dane plików są udostępniane innej aplikacji (nawet innej aplikacji tego samego dewelopera).

  • Sprawdź, czy treść jest widoczna w innej aplikacji i nie powoduje awarii.

Dodatkowe informacje

Zezwól na otrzymywanie e-maili w Konsoli Google Play, abyśmy mogli wysyłać Ci ważne aktualizacje i ogłoszenia dotyczące Androida i Google Play, w tym nasz miesięczny newsletter dla partnerów.