Zmiany w działaniu: wszystkie aplikacje

Platforma Android 17 zawiera zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą wszystkich aplikacji działających na Androidzie 17, niezależnie od targetSdkVersion. Przetestuj aplikację i w razie potrzeby zmodyfikuj ją, aby w odpowiednich przypadkach obsługiwała te zmiany.

Zapoznaj się też z listą zmian w działaniu, które wpływają tylko na aplikacje kierowane na Androida 17.

Główna funkcja

Android 17 (poziom API 37) zawiera te zmiany, które modyfikują lub rozszerzają różne podstawowe funkcje systemu Android.

Limity pamięci aplikacji

Android 17 wprowadza limity pamięci aplikacji na podstawie łącznej ilości pamięci RAM urządzenia, aby zapewnić bardziej stabilne i deterministyczne środowisko dla aplikacji i użytkowników Androida. Te limity koncentrują się na wyciekach pamięci i innych wartościach odstających, zanim spowodują one niestabilność całego systemu, która może prowadzić do zacinania się interfejsu, większego zużycia baterii i zamykania aplikacji. Spodziewamy się, że wpływ na większość sesji aplikacji będzie minimalny, ale zalecamy stosowanie tych sprawdzonych metod dotyczących pamięci, w tym ustalenie punktu odniesienia dla pamięci.

Możesz sprawdzić, czy problem dotyczył sesji aplikacji, wywołując funkcję getDescription w ApplicationExitInfo. Jeśli tak, przyczyną wyjścia będzie REASON_OTHER, a opis będzie zawierać ciąg "MemoryLimiter:AnonSwap" oraz inne informacje. Możesz też użyć profilowania opartego na aktywatorach w TRIGGER_TYPE_ANOMALY, aby uzyskać zrzuty sterty zbierane po osiągnięciu limitu pamięci.

Dokumentacja Zarządzanie pamięcią aplikacji zawiera informacje, które pomogą Ci zdiagnozować problemy z pamięcią aplikacji i zoptymalizować zużycie zasobów.

Testowanie działania aplikacji w warunkach ograniczonej pamięci

Możesz użyć Android Debug Bridge (adb), aby dostosować lub wyłączyć limity pamięci na dowolnym urządzeniu, które je nakłada. Polecenie powłoki am udostępnia 3 polecenia podrzędne, które umożliwiają dostosowanie limitów pamięci. (Te polecenia nie mają wpływu na urządzenie, które nie nakłada limitów pamięci).

• am memory-limiter ignore <uid>|none|all
• am memory-limiter manual <pid> <limit>|max|none
• am memory-limiter status

ignore

Instruuje ogranicznik pamięci, aby ignorował niektóre lub wszystkie procesy. Przekazanie UID (identyfikatora użytkownika Androida) powoduje, że ogranicznik pamięci ignoruje egzekwowanie we wszystkich procesach powiązanych z tym identyfikatorem. Możesz też przekazać wartość all (ignoruj wszystkie aplikacje) lub none (nie ignoruj żadnych aplikacji). Przekazanie parametru none zastępuje wszystkie poprzednie wywołania funkcji am memory-limiter ignore.

Jeśli poinstruujesz ogranicznik pamięci, aby ignorował identyfikator UID, nadal możesz ręcznie zastosować limit pamięci do procesu w aplikacji, wywołując funkcję am memory-limiter manual.

manual

Instruuje system, aby nałożył ograniczenie pamięci na proces o określonym identyfikatorze PID (identyfikator procesu). Ograniczenie pamięci jest określane jako liczba całkowita MB. Na przykład przekazanie wartości 30 oznacza, że proces jest ograniczony do 30 MB pamięci. Przekazanie wartości max powoduje usunięcie wszystkich limitów pamięci dla tego procesu. Przekazanie wartości none powoduje usunięcie wszystkich ręcznych limitów ustawionych dla procesu i przywrócenie domyślnego limitu systemu (jeśli taki istnieje).

status

Zgłasza bieżący stan ogranicznika pamięci. Stan obejmuje limity pamięci nałożone na widoczne i niewidoczne procesy.

Prywatność

Android 17 zawiera te zmiany, które mają na celu zwiększenie prywatności użytkowników.

Ochrona przy użyciu jednorazowego hasła SMS

Począwszy od Androida 17, rozszerzamy ochronę SMS-ów zawierających hasła jednorazowe.

W poprzednich wersjach Androida ta ochrona koncentrowała się głównie na formacie SMS Retriever. Dostarczanie wiadomości zawierających hasz SMS retriever było opóźnione o 3 godziny w przypadku większości aplikacji. Niektóre aplikacje (np. domyślny moduł obsługi SMS-ów) były jednak wyłączone z opóźnienia, podobnie jak aplikacja, która była właścicielem hasha.

Począwszy od Androida 17, ochrona jest stosowana również do wiadomości w formacie WebOTP. Jeśli aplikacja ma uprawnienia do odczytywania SMS-ów, ale nie jest zamierzonym odbiorcą wiadomości WebOTP (co jest określane na podstawie weryfikacji domeny), wiadomość nie będzie dla niej dostępna przez 3 godziny od jej otrzymania. Ta zmiana ma na celu zwiększenie bezpieczeństwa użytkowników przez zapewnienie, że tylko aplikacje powiązane z domeną wymienioną w wiadomości mogą automatycznie odczytywać kod weryfikacyjny.

W ciągu tych 3 godzin transmisja SMS_RECEIVED_ACTION jest wstrzymana, a zapytania do bazy danych dostawcy SMS-ów są filtrowane. Po upływie tego czasu SMS jest dostępny dla tych aplikacji. Ta zmiana dotyczy wszystkich aplikacji, niezależnie od docelowego poziomu interfejsu API.

Niektóre aplikacje, takie jak domyślna aplikacja asystująca do SMS-ów czy aplikacje towarzyszące na połączonych urządzeniach, są wyłączone z tego opóźnienia. Wszystkie aplikacje, które odczytują SMS-y w celu wyodrębnienia hasła jednorazowego, powinny przejść na interfejsy API SMS Retriever lub SMS User Consent, aby zapewnić ciągłość działania.

Bezpieczeństwo

Android 17 zawiera te ulepszenia zabezpieczeń urządzenia i aplikacji.

Harmonogram wycofywania atrybutu usesCleartextTraffic

W przyszłej wersji planujemy wycofać element usesCleartextTraffic. Aplikacje, które muszą nawiązywać nieszyfrowane połączenia (HTTP), powinny zostać przeniesione do pliku konfiguracji bezpieczeństwa sieci, który pozwala określić, z którymi domenami aplikacja musi nawiązywać połączenia w formie tekstu nieszyfrowanego.

Pamiętaj, że pliki konfiguracji zabezpieczeń sieci są obsługiwane tylko na poziomie interfejsu API 24 i wyższym. Jeśli minimalny poziom interfejsu API aplikacji jest niższy niż 24, musisz wykonać obie te czynności:

• Ustaw atrybut usesCleartextTraffic na true
• Używanie pliku konfiguracji sieci

Jeśli minimalny poziom interfejsu API aplikacji to 24 lub wyższy, możesz użyć pliku konfiguracji sieci i nie musisz ustawiać usesCleartextTraffic.

Ogranicz niejawne uprawnienia do identyfikatorów URI

Obecnie, jeśli aplikacja uruchamia intencję z identyfikatorem URI, który ma działanie ACTION_SEND, ACTION_SEND_MULTIPLE lub ACTION_IMAGE_CAPTURE, system automatycznie przyznaje aplikacji docelowej uprawnienia do odczytu i zapisu identyfikatora URI. Od Androida 18 system nie będzie już automatycznie przyznawać tych uprawnień. Z tego powodu zalecamy, aby aplikacje wyraźnie przyznawały odpowiednie uprawnienia do identyfikatorów URI, zamiast polegać na systemie.

Aby wykryć użycie tych intencji w aplikacji, użyj StrictMode z detectImplicitUriPermissionGrant(), aby wywołać naruszenie:

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

Możesz też monitorować zarejestrowane wyjątki zawierające komunikat Please set the grant explicitly in the app, który pojawia się, gdy system niejawnie ustawia uprawnienia. Możesz monitorować te logi za pomocą tego polecenia adb:

adb logcat | grep "Please set the grant explicitly in the app"

Aby wyraźnie przyznać niezbędne uprawnienia, dodaj flagę FLAG_GRANT_READ_URI_PERMISSION do intencji ACTION_SEND i ACTION_SEND_MULTIPLE:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

W przypadku intencji ACTION_IMAGE_CAPTURE uwzględnij flagi FLAG_GRANT_READ_URI_PERMISSION i FLAG_GRANT_WRITE_URI_PERMISSION:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Limity magazynu kluczy na aplikację

Aplikacje nie powinny tworzyć nadmiernej liczby kluczy w magazynie kluczy Androida, ponieważ jest to zasób współdzielony przez wszystkie aplikacje na urządzeniu. Począwszy od Androida 17 system wymusza limit liczby kluczy, które może mieć aplikacja. Limit wynosi 50 000 kluczy w przypadku aplikacji niesystemowych kierowanych na Androida 17 (poziom interfejsu API 37) lub nowszego oraz 200 000 kluczy w przypadku wszystkich innych aplikacji. Aplikacje systemowe mają limit 200 000 kluczy,niezależnie od tego, na jaki poziom interfejsu API są kierowane.

Jeśli aplikacja spróbuje utworzyć klucze powyżej limitu, utworzenie zakończy się niepowodzeniem z błędem KeyStoreException. Ciąg komunikatu o wyjątku zawiera informacje o limicie kluczy. Jeśli aplikacja wywołuje getNumericErrorCode() w przypadku wyjątku, zwracana wartość zależy od poziomu interfejsu API, na który jest kierowana aplikacja:

• Aplikacje kierowane na Androida 17 (API na poziomie 37) lub nowszego: getNumericErrorCode() zwraca nową wartość ERROR_TOO_MANY_KEYS.
• Wszystkie inne aplikacje: getNumericErrorCode() zwraca ERROR_INCORRECT_USAGE.

Blokuj ruch pętli zwrotnej między profilami

Począwszy od Androida 17, ruch pętli zwrotnej między profilami nie jest już domyślnie dozwolony. Nie ma to wpływu na ruch w pętli zwrotnej w ramach tego samego profilu. Ta zmiana dotyczy wszystkich aplikacji na Androida 17 lub nowszego, niezależnie od docelowego poziomu interfejsu API.

Interfejs użytkownika i systemowy

Android 17 zawiera te zmiany, które mają na celu zapewnienie bardziej spójnego i intuicyjnego działania.

Przywracam domyślną widoczność IME po obróceniu

Począwszy od Androida 17, gdy konfiguracja urządzenia ulegnie zmianie (np. przez obrót), a nie jest to obsługiwane przez samą aplikację, poprzednia widoczność metody IME nie zostanie przywrócona.

Jeśli w aplikacji nastąpi zmiana konfiguracji, której nie obsługuje, a po zmianie klawiatura musi być widoczna, musisz wyraźnie o to poprosić. Możesz to zrobić na jeden z tych sposobów:

• Ustaw atrybut android:windowSoftInputMode na stateAlwaysVisible.
• Poproś o klawiaturę ekranową automatycznie w metodzie onCreate() aktywności lub dodaj metodę onConfigurationChanged().

Dane wejściowe od człowieka

Android 17 zawiera te zmiany, które wpływają na sposób interakcji aplikacji z urządzeniami wejściowymi, takimi jak klawiatury i touchpady.

Touchpady domyślnie dostarczają zdarzenia względne podczas przechwytywania wskaźnika

Począwszy od Androida 17, jeśli aplikacja żąda przechwytywania wskaźnika za pomocą metody View.requestPointerCapture(), a użytkownik korzysta z touchpada, system rozpoznaje ruch wskaźnika i gesty przewijania na podstawie dotknięć użytkownika i zgłasza je aplikacji w taki sam sposób jak ruchy wskaźnika i kółka przewijania z przechwyconej myszy. W większości przypadków eliminuje to konieczność dodawania specjalnej logiki obsługi touchpadów w aplikacjach, które obsługują przechwytywanie myszy. Więcej informacji znajdziesz w dokumentacji View.POINTER_CAPTURE_MODE_RELATIVE.

Wcześniej system nie próbował rozpoznawać gestów na touchpadzie, lecz przekazywał aplikacji nieprzetworzone, bezwzględne położenie palców w formacie podobnym do dotknięć ekranu dotykowego. Jeśli aplikacja nadal wymaga tych danych bezwzględnych, powinna wywołać nową metodę View.requestPointerCapture(int) z View.POINTER_CAPTURE_MODE_ABSOLUTE.

Multimedia

Android 17 wprowadza te zmiany w działaniu multimediów.

Ulepszenie dźwięku w tle

Począwszy od Androida 17, platforma audio wymusza ograniczenia dotyczące interakcji z dźwiękiem w tle, w tym odtwarzania dźwięku, żądań fokusu audio i interfejsów API zmiany głośności, aby mieć pewność, że te zmiany są wprowadzane celowo przez użytkownika.

Jeśli aplikacja próbuje wywołać interfejsy API audio, gdy nie jest w prawidłowym cyklu życia, interfejsy API odtwarzania dźwięku i zmiany głośności nie działają, ale nie zgłaszają wyjątku ani nie wyświetlają komunikatu o błędzie. Interfejs API fokusu audio nie działa i zwraca kod wyniku AUDIOFOCUS_REQUEST_FAILED.

Więcej informacji, w tym strategie ograniczania ryzyka, znajdziesz w artykule Wzmacnianie zabezpieczeń dźwięku w tle.

Połączenia

Android 17 zawiera te zmiany, które ulepszają łączność urządzenia.

Autonomiczne ponowne parowanie w przypadku utraty połączenia Bluetooth

Android 17 wprowadza autonomiczne ponowne parowanie, czyli ulepszenie na poziomie systemu, które automatycznie rozwiązuje problem utraty połączenia Bluetooth.

Wcześniej, jeśli połączenie zostało utracone, użytkownicy musieli ręcznie przejść do Ustawień, aby rozparować, a następnie ponownie sparować urządzenie peryferyjne. Ta funkcja opiera się na ulepszeniach zabezpieczeń Androida 16, umożliwiając systemowi ponowne nawiązywanie połączeń w tle bez konieczności ręcznego przechodzenia do ustawień w celu rozparowania i ponownego sparowania urządzeń peryferyjnych.

Większość aplikacji nie będzie wymagać zmian w kodzie, ale deweloperzy powinni pamiętać o tych zmianach w zachowaniu stosu Bluetooth:

• Nowy kontekst parowania: ACTION_PAIRING_REQUEST zawiera teraz dodatkowy element EXTRA_PAIRING_CONTEXT, który umożliwia aplikacjom odróżnienie standardowej prośby o sparowanie od autonomicznej próby ponownego sparowania zainicjowanej przez system.
• Warunkowe aktualizacje kluczy: istniejące klucze bezpieczeństwa zostaną zastąpione tylko wtedy, gdy ponowne parowanie się powiedzie, a nowe połączenie będzie miało co najmniej taki sam poziom bezpieczeństwa jak poprzednie.
• Zmodyfikowany czas intencji: intencja ACTION_KEY_MISSING jest teraz transmitowana tylko wtedy, gdy próba autonomicznego ponownego parowania się nie powiedzie. Zmniejsza to niepotrzebną obsługę błędów w aplikacji, jeśli system pomyślnie przywróci powiązanie w tle.
• Powiadomienie użytkownika: system zarządza ponownym parowaniem za pomocą nowych powiadomień i okien dialogowych w interfejsie. Użytkownicy zostaną poproszeni o potwierdzenie próby ponownego sparowania, aby upewnić się, że są świadomi ponownego połączenia.

Producenci urządzeń peryferyjnych i deweloperzy aplikacji towarzyszących powinni sprawdzić, czy sprzęt i aplikacja prawidłowo obsługują przejścia między powiązaniami. Aby przetestować to zachowanie, zasymuluj utratę połączenia zdalnego za pomocą jednej z tych metod:

• Ręczne usuwanie informacji o powiązaniu z urządzenia peryferyjnego
• Ręcznie rozparuj urządzenie w sekcji Ustawienia > Połączone urządzenia.