W systemie Android 11 wprowadzona zostanie opcja programisty „Zgodność aplikacji”, która pomoże testować zmiany platformy

Android 11 będzie wyposażony w nowe ustawienie „Zgodność aplikacji” w Opcjach programisty, które ułatwi twórcom aplikacji testowanie zmian w zachowaniu platformy.

Co roku podczas Google I/O Google prezentuje niektóre z najbardziej ekscytujących zmian, które pojawią się w kolejnej wersji Androida. Chociaż większość użytkowników ocenia wersje Androida na podstawie zmian wizualnych wpływających na ich wrażenia, każda aktualizacja Androida zawiera także mnóstwo nowych funkcji zmiany w API I zachowanie platformy. Twórcy aplikacji powinni wziąć pod uwagę te zmiany i przygotować się na nie, ponieważ mogą one zasadniczo zmienić sposób, w jaki ich aplikacje mogą być wykorzystywane przez użytkowników końcowych. W kolejnej wersji Androida 11 Google ułatwi programistom testowanie i przygotowywanie aplikacji na nadchodzące zmiany dzięki nowemu ustawieniu „Zgodność aplikacji” w Opcjach programisty.

Za każdym razem, gdy Google wypuszcza nową wersję Androida, twórcy aplikacji są zainteresowani aktywnym utrzymaniem ich wnioski muszą zapoznać się z nowymi zmianami i związaną z nimi dokumentacją zmiany. Mogą następnie podjąć decyzję o zaktualizowaniu swojej aplikacji w celu dodania nowych funkcji API, jeśli chcą przenieść lub przenieść korzystanie z istniejących interfejsów API do nowszych interfejsów API, przy czym ścieżka może być opcjonalna lub nie. Twórcy aplikacji nie muszą natychmiast aktualizować docelowego interfejsu API swoich aplikacji, ale w końcu muszą to zrobić, aby spełnić wymagania

zmiana docelowych wymagań API sklepu Google Play. Następnie programiści muszą także przetestować swoją aplikację w nowej wersji Androida, a można to zrobić na urządzeniu emulowanym, urządzeniu hostowanym w chmurze lub urządzeniu lokalnym. Testowanie jest częścią procedury programistycznej, ale staje się jeszcze ważniejsze, gdy w grę wchodzą poważne zmiany.

Co więcej, gdy Google chce wprowadzić istotne zmiany w zachowaniu platformy, nie wdraża ich od razu w nowej wersji Androida. Ma to na celu ochronę użytkowników przed awarią i utratą funkcjonalności wielu aplikacji, a także daje programistom więcej czasu na aktualizację aplikacji. Na przykład w Androidzie 7 Nougat Google zdecydował się na to ogranicz niektóre ukryte transmisje w celu oszczędzania baterii. Z Androidem 8 Oreo, Google całkowicie ograniczył aplikacjom możliwość rejestrowania ukrytych odbiorników transmisji. Jednak przed wypuszczeniem Androida 8 Oreo Google chciał, aby programiści przygotowali się na scenariusz, w którym ich aplikacje nie będą już mogły rejestrować ukrytych odbiorników transmisji. I do tego programiści mogliby użyj polecenia ADB w systemie Android 7 Nougat, aby zasymulować stan, w którym niejawne transmisje są niedostępne:

adb shell cmd appops set RUN_IN_BACKGROUND ignore

Polecenia ADB, takie jak powyższe, są przykładem tego, jak Google umożliwia twórcom aplikacji testowanie zachowania ich aplikacji w przypadku zmian w zachowaniu platformy Android.

Innym niedawnym przykładem jest to, jak w Androidzie Q Beta 2 Google poprosił programistów o przetestowanie pamięci o określonym zakresie w swoich aplikacjach, uruchamiając to polecenie ADB:

adb shell cmd appops set your-package-name android: legacy_storage default && \

Jako twórca aplikacji możesz założyć, że znasz się na poleceniach ADB i nie masz szczególnej ochoty używać ich do testowania zmian na platformie. Ale zawsze jest miejsce na ulepszenia, a Google ułatwia ten proces testowania, wprowadzając prosty interfejs użytkownika do kontrolowania tych zmian.

Z nowym Projekt PlatformCompatprogramiści nie muszą już uruchamiać poleceń ADB przy każdej nowej zmianie zachowania platformy. W Androidzie 11 Android będzie miał nowe podmenu w Opcjach programisty, umożliwiające szybkie przełączanie nowych zmian w zachowaniu platformy dla poszczególnych aplikacji, bez konieczności wysyłania jakichkolwiek poleceń powłoki ADB. Dla każdego docelowego poziomu interfejsu API będą dostępne różne sekcje — na przykład poziom interfejsu API > 29 będzie miał własny zestaw zmian zachowania, które można przełączać, podczas gdy poziom API > 30 będzie miał własny zestaw zmiany.

Na powyższym zrzucie ekranu przedstawiającym sekcję Zgodność aplikacji (ze źródłowego AOSP działającego na emulatorze) opcja „Domyślna Sekcja Włączone zmiany” zawiera zmiany interfejsu API systemu Android 11, które będą domyślnie włączone we wszystkich aplikacjach, niezależnie od ich celu SDK. Sekcja „włączona dla wersji docelowej SDK > 29” zawiera zmiany w interfejsie API systemu Android 11, które są włączone tylko w przypadku aplikacji przeznaczonych dla systemu Android 11/poziomu interfejsu API 30.

Chociaż ta konkretna zmiana nie wzbudzi bezpośrednio entuzjazmu użytkowników końcowych, ułatwia pracę twórcom aplikacji, a to zawsze dobrze.


Dzięki uznanemu programiście XDA Luca020400 za wskazówkę i za przesłanie załączonego zrzutu ekranu.

Dalsze informacje na temat Androida 11:

  • Android 11 może wreszcie usunąć limit rozmiaru plików dla nagrań wideo wynoszący 4 GB
  • Planowanie w trybie ciemnym może pojawić się w Androidzie 11
  • Tryb samolotowy może w końcu przestać wyłączać dźwięk Bluetooth, począwszy od Androida 11 R
  • Google wycofuje interfejs API AsyncTask Androida w Androidzie 11
  • Google poprosi programistów menedżerów plików o przesłanie formularza, aby uzyskać szeroki dostęp do przechowywania plików w Androidzie 11
  • Android 11 może w końcu przynieść odpowiednią, natywną implementację bezprzewodowego ADB