Lista zmian dokumentu definicji zgodności z systemem Android

Androida 13

26 czerwca 2023 r

2. Typy urządzeń

  • 2.2.1. Sprzęt komputerowy

    • Usunięto wymagania 7.2.3/H-0-5, 7.2.3/H-0-6, 7.2.3/H-0-7

    • Inne aktualizacje:

      Zobacz wersję

      ZDECYDOWANIE ZALECA się wykonanie kroków konfiguracji pomiaru określonych w Kalibracji obecności Wymagania .

  • 2.5.1. Sprzęt komputerowy

    Zobacz wersję

    Jeśli implementacje urządzeń Automotive są 32-bitowe:

    • [7.6.1/A-1-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 512 MB, jeśli używana jest dowolna z poniższych gęstości:

      • 280 dpi lub mniej na małych/normalnych ekranach
      • ldpi lub niższy na bardzo dużych ekranach
      • mdpi lub niższe na dużych ekranach

    • [7.6.1/A-1-2] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 608 MB, jeśli używana jest dowolna z poniższych gęstości:

      • xhdpi lub nowszy na małych/normalnych ekranach
      • hdpi lub wyższy na dużych ekranach
      • mdpi lub wyższy na bardzo dużych ekranach

    • [7.6.1/A-1-3] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 896 MB, jeśli używana jest dowolna z poniższych gęstości:

      • 400 dpi lub więcej na małych/normalnych ekranach
      • xhdpi lub wyższej na dużych ekranach
      • tvdpi lub wyższy na bardzo dużych ekranach

    • [7.6.1/A-1-4] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1344 MB, jeśli używana jest dowolna z poniższych gęstości:

      • 560 dpi lub więcej na małych/normalnych ekranach
      • 400 dpi lub więcej na dużych ekranach
      • xhdpi lub wyższej na bardzo dużych ekranach

3. Oprogramowanie

7. Kompatybilność sprzętowa

9. Kompatybilność modeli zabezpieczeń

  • 9.1 Uprawnienia

    Zobacz wersję

    Implementacje urządzeń:

    • [C-0-5] NIE WOLNO przyznawać żadnych uprawnień w czasie wykonywania preinstalowany aplikacje, chyba że:

      • Są one instalowane w momencie wysyłki urządzenia ORAZ
      • Zgodę użytkownika można uzyskać przed użyciem aplikacji To pozwolenie ,

      LUB

      • Uprawnienia środowiska wykonawczego są przyznawane przez domyślną politykę przyznawania uprawnień lub w celu pełnienia roli platformy . powiązany z wzorcem intencji, dla którego preinstalowana aplikacja jest ustawiona jako domyślna procedura obsługi .

  • 9.11. Klucze i poświadczenia

    • Usunięto wymagania [C-13-10] i 9.11.4.

20 marca 2023 r

2. Typy urządzeń

3. Oprogramowanie

  • 3.18. Łączność

    Zobacz wersję

    Rozpocznij nowe wymagania

    Domyślne konto dla nowych kontaktów: Dostawca kontaktów udostępnia interfejsy API do zarządzania ustawieniami konta domyślnego podczas tworzenia nowego kontaktu.

    Jeśli implementacje urządzeń wstępnie ładują aplikację kontaktów, to wstępnie załadowana aplikacja kontaktów:

    • [C-2-1] MUSI obsłużyć zamiar ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT , aby uruchomić interfejs użytkownika do wyboru konta i zapisać ustawienie u dostawcy kontaktów po wybraniu konta.

    • [C-2-2] MUSI przestrzegać domyślnego ustawienia konta podczas obsługi Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT dla ContactsContracts.Contacts.CONTENT_TYPE i ContactsContract.RawContacts.CONTENT_TYPE przez początkowe wybranie konta.

  • 3.2.3.5. Warunkowe intencje aplikacji

    Zobacz wersję

    [Przeniesiono do wersji 2.2.3]

    Rozpocznij nowe wymagania

    Jeśli aplikacja Ustawienia implementacji urządzenia zaimplementuje podzieloną funkcjonalność , używając osadzania aktywności, wówczas:

6. Kompatybilność narzędzi programistycznych i opcji

7. Kompatybilność sprzętowa

  • 7.3.13. IEEE 802.1.15.4 (UWB)

    Zobacz wersję

    [Przeniesiono do 7.4.9]

    Rozpocznij nowe wymagania

    Jeśli implementacje urządzeń obejmują obsługę standardu 802.1.15.4 i udostępniają tę funkcjonalność aplikacji innej firmy, to:

    • [C-1-1] MUSI zaimplementować odpowiedni interfejs API systemu Android w pliku android.uwb.
    • [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.uwb.
    • [C-1-3] MUSI obsługiwać wszystkie odpowiednie profile UWB zdefiniowane w implementacji systemu Android.
    • [C-1-4] MUSI zapewnić afordancję użytkownika, aby umożliwić użytkownikowi przełączanie stanu włączenia/wyłączenia radia UWB.
    • [C-1-5] MUSI wymusić, aby aplikacje korzystające z radia UWB miały uprawnienia UWB_RANGING (w grupie uprawnień NEARBY_DEVICES).
    • [C-1-6] ZDECYDOWANIE ZALECA SIĘ przejście odpowiednich testów zgodności i certyfikacji określonych przez organizacje normalizacyjne, w tym FIRA , CCC i CSA .

  • 7.4.1. Telefonia

    Zobacz wersję

    Jeśli implementacje urządzeń obejmują telefonię GSM lub CDMA zgłoś funkcję android.hardware.telephony , a następnie:

    Jeśli implementacje urządzeń obejmują telefonię GSM lub CDMA zgłoś funkcję android.hardware.telephony i podaj pasek stanu systemu, a następnie:

    • [C- 6 -7 -1 ] MUSI wybrać reprezentatywną aktywną subskrypcję dla danego identyfikatora UUID grupy , który ma być wyświetlany użytkownikowi w dowolnych afordancjach, które dostarczają informacji o stanie karty SIM. Przykładami takich afordancji są ikona sygnału komórkowego na pasku stanu lub kafelek szybkich ustawień.
    • [C-SR-1] Stanowczo ZALECA się, aby subskrypcja reprezentatywna była aktywną subskrypcją transmisji danych , chyba że urządzenie jest w trakcie połączenia głosowego, podczas którego ZDECYDOWANIE ZALECA się, aby subskrypcja reprezentatywna była aktywną subskrypcją głosową.

    Jeśli implementacje urządzeń obejmują telefonię GSM lub CDMA zgłoś funkcję android.hardware.telephony , a następnie:

    • [C-6- 8 7 ] MUSI mieć możliwość otwarcia i jednoczesnego wykorzystania maksymalnej liczby kanałów logicznych (w sumie 20) dla każdego UICC zgodnie z ETSI TS 102 221.
    • [C-6- 10 8 ] NIE WOLNO stosować żadnego z poniższych zachowań do aplikacji aktywnego operatora (określonych przez TelephonyManager#getCarrierServicePackageName ) automatycznie lub bez wyraźnego potwierdzenia użytkownika:
      • Odwołaj lub ogranicz dostęp do sieci
      • Odwołaj uprawnienia
      • Ogranicz wykonywanie aplikacji w tle lub na pierwszym planie poza istniejącymi funkcjami zarządzania energią zawartymi w AOSP
      • Wyłącz lub odinstaluj aplikację

    Jeśli implementacje urządzeń obejmują telefonię GSM lub CDMA zgłoś funkcję android.hardware.telephony i wszystkie aktywne, nieoportunistyczne subskrypcje , które mają wspólny identyfikator UUID grupy, są wyłączone, vfizycznie usunięte z urządzenia lub oznaczone jako oportunistyczne, wtedy urządzenie:

    • [C- 7 8 -1] MUSI automatycznie wyłączyć wszystkie pozostałe aktywne subskrypcje oportunistyczne w tej samej grupie.

    Jeśli implementacje urządzeń obejmują telefonię GSM, ale nie telefonię CDMA, to:

    • [C- 8 9 -1] NIE WOLNO deklarować PackageManager#FEATURE_TELEPHONY_CDMA .
    • [C- 8 9 -2] MUSI zgłaszać wyjątek IllegalArgumentException przy próbach ustawienia dowolnych typów sieci 3GPP2 w preferowanych lub dozwolonych maskach bitowych typu sieci.
    • [C- 8 9 -3] MUSI zwrócić pusty ciąg z TelephonyManager#getMeid .

    Jeśli implementacje urządzeń obsługują eUICC z wieloma portami i profilami, to:

  • 7.4.9. UWB

    Zobacz wersję

    Jeśli implementacje urządzeń zgłaszają obsługę funkcji android.hardware.uwb za pośrednictwem klasy android.content.pm.PackageManager , Jeśli implementacje urządzeń obejmują obsługę standardu 802.1.15.4 i udostępniają tę funkcjonalność aplikacji innej firmy, wówczas:

    Rozpocznij nowe wymagania

    • [C-1-1] MUSI zaimplementować odpowiedni interfejs API systemu Android w pliku android.uwb.
    • [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.uwb.
    • [C-1-3] MUSI obsługiwać wszystkie odpowiednie profile UWB zdefiniowane w implementacji systemu Android.
    • [C-1-4] MUSI zapewnić afordancję użytkownika, aby umożliwić użytkownikowi przełączanie stanu włączenia/wyłączenia radia UWB.
    • [C-1-5] MUSI wymusić, aby aplikacje korzystające z radia UWB miały uprawnienia UWB_RANGING (w grupie uprawnień NEARBY_DEVICES).
    • [C-SR-1] ZDECYDOWANIE ZALECA SIĘ przejście odpowiednich testów zgodności i certyfikacji określonych przez organizacje normalizacyjne, w tym FIRA , CCC i CSA .
    • [C-1- 1 6 ] MUSI upewnić się, że pomiary odległości mieszczą się w zakresie +/-15 cm dla 95% pomiarów w środowisku linii wzroku z odległości 1 m w komorze bezodblaskowej.
    • [C-1- 2 7 ] MUSI się upewnić, że mediana pomiarów odległości w odległości 1 m od urządzenia referencyjnego mieści się w granicach [0,75 m, 1,25 m], gdzie rzeczywista odległość do uziemienia jest mierzona od górnej krawędzi badanego urządzenia trzymanego ekranem do góry i przechylonego pod kątem 45 stopni.
    • [C-SR-2] ZDECYDOWANIE ZALECA się wykonanie kroków konfiguracji pomiaru określonych w Wymaganiach dotyczących kalibracji obecności .

    ZDECYDOWANIE ZALECA się przestrzeganie kroków konfiguracji pomiaru określonych w Wymaganiach dotyczących kalibracji obecności .

  • 7.8.2.2. Cyfrowe porty audio

    Zobacz wersję

    Aby zapewnić kompatybilność z zestawami słuchawkowymi i innymi akcesoriami audio korzystającymi ze złączy USB-C i wdrażającymi (klasa audio USB) w całym ekosystemie Android, zgodnie ze specyfikacją zestawu słuchawkowego Android USB .

19 października 2022 r

2. Typy urządzeń

  • 2.2.3 Oprogramowanie

    Zobacz wersję

    Jeśli implementacje urządzeń przenośnych nie działają w trybie zadania blokady , podczas kopiowania treści do schowka:

    • [3.8.17/H-1-1] MUSI przedstawiać użytkownikowi potwierdzenie, że dane zostały skopiowane do schowka (np. miniatura lub ostrzeżenie „Treść skopiowana”). Dodatkowo umieść tutaj informację, czy dane ze schowka będą synchronizowane między urządzeniami.

3. Oprogramowanie

  • 3.2.3.5. Warunkowe intencje aplikacji

    Zobacz wersję

    Jeśli aplikacja Ustawienia implementacji urządzenia zaimplementuje podzieloną funkcjonalność , używając osadzania aktywności, wówczas:

    Jeśli implementacje urządzeń obsługują VoiceInteractionService i mają jednocześnie zainstalowaną więcej niż jedną aplikację korzystającą z tego interfejsu API, to:

  • 3.4.1 Zgodność z przeglądarką internetową

    Zobacz wersję

    • [C-1-4] MUSI renderować „dostarczoną” treść lub zawartość zdalnego adresu URL w procesie innym niż aplikacja, która tworzy instancję WebView. W szczególności oddzielny proces renderowania MUSI mieć niższe uprawnienia, działać jako oddzielny identyfikator użytkownika, nie mieć dostępu do katalogu danych aplikacji, nie mieć bezpośredniego dostępu do sieci i mieć dostęp tylko do minimalnych wymaganych usług systemowych przez Binder. Implementacja AOSP WebView spełnia ten wymóg.

7. Kompatybilność sprzętowa

  • 7.4.2 IEEE 802.11 (Wi-Fi)

    Zobacz wersję

    Jeśli implementacje urządzeń obejmują obsługę trybu oszczędzania energii Wi-Fi zgodnie z definicją w standardzie IEEE 802.11, to:

  • 7.4.3 Bluetooth

    Zobacz wersję

    Jeśli implementacje urządzeń obejmują obsługę Bluetooth Low Energy (BLE), to:

    • [C-3-5] MUSI wdrożyć limit czasu rozpoznawalnego adresu prywatnego (RPA) nie dłuższy niż 15 minut i obracać adres po przekroczeniu limitu czasu, aby chronić prywatność użytkownika , gdy urządzenie aktywnie korzysta z BLE do skanowania lub reklam. Aby zapobiec atakom czasowym, odstępy czasu MUSZĄ być losowe w przedziale od 5 do 15 minut.

  • 7.5.5 Orientacja kamery

    Zobacz wersję

    Jeśli implementacje urządzenia mają przednią lub tylną kamerę, takie kamery:

    • [C-1-1] MUSI być ustawiony tak, aby dłuższy wymiar kamery pokrywał się z dłuższym wymiarem ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparaty MUSZĄ rejestrować obrazy w orientacji poziomej. Ma to zastosowanie niezależnie od naturalnej orientacji urządzenia; to znaczy dotyczy to urządzeń podstawowych w orientacji poziomej, jak również urządzeń podstawowych w orientacji pionowej.

    Urządzenia, które spełniają wszystkie poniższe kryteria, są zwolnione z powyższego wymogu:

    • Urządzenie implementuje ekrany o zmiennej geometrii, takie jak wyświetlacze składane lub uchylne.
    • Gdy zmienia się stan złożenia lub zawiasu urządzenia, urządzenie przełącza się między orientacją pionową podstawową a poziomą podstawową (lub odwrotnie).

9. Kompatybilność modeli zabezpieczeń

  • 9.11 Klucze i dane uwierzytelniające

    Zobacz wersję

    Gdy implementacja urządzenia obsługuje bezpieczny ekran blokady, to:

    • [C-1-6] MUSI obsługiwać IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice wersja 1 lub IKeyMintDevice wersja 2.

  • 9.17 Struktura wirtualizacji Androida

    Zobacz wersję

    Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework ( android.system.virtualmachine.* ), host systemu Android:

    • [C-1-3] NIE WOLNO modyfikować, pomijać ani zastępować reguł nigdy niedozwolonych obecnych w systemie/zasadach dostarczonych w nadrzędnym projekcie Android Open Source Project (AOSP), a zasady MUSZĄ zostać skompilowane ze wszystkimi obecnymi regułami nigdy niedozwolonymi.

    Jeśli urządzenie zaimplementowało obsługę interfejsów API platformy Android Virtualization Framework ( android.system.virtualmachine.* ), to dowolna instancja chronionej maszyny wirtualnej:

    • [C-2-4] NIE WOLNO modyfikować, pomijać ani zastępować reguł nigdy nie zezwalających obecnych w systemie/sepolicy/mikroroidzie dostarczonym w nadrzędnym projekcie Android Open Source Project (AOSP).

    Jeśli urządzenie obsługuje interfejsy API Android Virtualization Framework, to w przypadku zarządzania kluczami:

    • [C-6-2] MUSI prawidłowo wykonać KOSTKI, tj. podać prawidłowe wartości. Ale może nie musieć schodzić na taki poziom szczegółowości.

15 sierpnia 2022 r

2. Typy urządzeń

  • 2.2.1 Sprzęt : Zmiany w wymaganiach sprzętowych w następujący sposób.

    • Urządzenia wejściowe:

      Zobacz wersję

      Implementacje urządzeń przenośnych:

      • [ 7.2 .3/H-0-5] MUSI wywoływać OnBackInvokedCallback.onBackStarted() w aktualnie aktywnym oknie, gdy rozpoczyna się gest wstecz lub przycisk wstecz ( KEYCODE_BACK ) jest wciśnięty w dół.
      • [ 7.2 .3/H-0-6] MUSI wywołać OnBackInvokedCallback.onBackInvoked() po zatwierdzeniu gestu cofania lub zwolnieniu przycisku Wstecz (GÓRA).
      • [ 7.2 .3/H-0-7] MUSI wywoływać OnBackInvokedCallback.onBackCancelled() , gdy gest cofania nie jest zatwierdzony lub zdarzenie KEYCODE_BACK jest anulowane.

      Jeśli urządzenia obsługują protokół WiFi Neighbor Awareness Networking (NAN) przez deklarację PackageManager.FEATURE_WIFI_AWARE i Wi-Fi Location (Wi-Fi Round Trip Time — RTT) przez deklarację PackageManager.FEATURE_WIFI_RTT , wówczas:

      • [ 7.4 .2.5/H-1-1] MUSI podawać zasięg z dokładnością do +/-1 metra przy szerokości pasma 160 MHz na 68. percentylu (zgodnie z obliczeniem funkcji skumulowanego rozkładu), +/-2 metrów przy szerokości pasma 80 MHz na 68. percentylu, +/-4 metry przy szerokości pasma 40 MHz na 68. percentylu i +/-8 metrów przy szerokości pasma 20 MHz na 68. percentylu w odległościach 10 cm, 1 m, 3 m i 5 m, jak obserwowane przez API WifiRttManager#startRanging dla Androida .

      • [ 7.4 .2.5/H-SR] ZDECYDOWANIE ZALECA się, aby podawać zasięg z dokładnością do +/-1 metra przy szerokości pasma 160 MHz na 90. percentylu (zgodnie z obliczeniem za pomocą funkcji dystrybucji skumulowanej), +/-2 metrów przy 80 MHz przepustowość na 90. percentylu, +/-4 metry przy przepustowości 40 MHz na 90. percentylu i +/-8 metrów przy przepustowości 20 MHz na 90. percentylu przy odległości 10 cm, jak zaobserwowano za pomocą API WifiRttManager#startRanging Android .

      ZDECYDOWANIE ZALECA się przestrzeganie kroków konfiguracji pomiaru określonych w Wymaganiach dotyczących kalibracji obecności .

    • Opóźnienie dźwięku:

      Zobacz wersję

      Jeśli implementacje urządzeń przenośnych deklarują android.hardware.audio.output i android.hardware.microphone , to:

      • [ 5.6 /H-1-1] MUSI mieć średnie ciągłe opóźnienie w obie strony równe 500 800 milisekund lub mniej w ciągu 5 pomiarów, ze średnim bezwzględnym odchyleniem mniejszym niż 50 100 ms, przez następujące ścieżki danych: „głośnik do mikrofonu”, adapter sprzężenia zwrotnego 3,5 mm (jeśli jest obsługiwany), sprzężenie zwrotne USB (jeśli jest obsługiwane). co najmniej jedną obsługiwaną ścieżkę.

      • [ 5.6 /H-1-1] MUSI mieć średnie opóźnienie Tap-to-tone wynoszące 500 milisekund lub mniej w ciągu co najmniej 5 pomiarów na ścieżce danych głośnik-mikrofon.

    • Wejścia dotykowe:

      Zobacz wersję

      Jeśli implementacje urządzeń przenośnych obejmują co najmniej jeden siłownik dotykowy, to:

      • [ 7.10 /H]* NIE WOLNO używać siłownika dotykowego (wibratora) z mimośrodową masą wirującą (ERM).
      • [ 7.10 /H]* NALEŻY umieścić siłownik w pobliżu miejsca, w którym urządzenie jest zwykle trzymane lub dotykane rękami.
      • [ 7.10 /H]* POWINNO zaimplementować wszystkie stałe publiczne dla wyraźnych wrażeń dotykowych w android.view.HapticFeedbackConstants , a mianowicie (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJ EW, GESTURE_START i GESTURE_END).
      • [ 7.10 /H]* POWINNO zaimplementować wszystkie stałe publiczne dla wyraźnych wrażeń dotykowych w android.os.VibrationEffect , mianowicie (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK i EFFECT_DOUBLE_CLICK) oraz wszystkie możliwe stałe publiczne PRIMITIVE_* dla bogatych wrażeń dotykowych w android.os.VibrationEffect.Composition , mianowicie (PRIMITIVE_CLICK i PRIMITIVE_TICK) (KLIKNIJ, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Niektóre z tych prymitywów, takie jak LOW_TICK i SPIN, mogą być wykonalne tylko wtedy, gdy wibrator może obsługiwać stosunkowo niskie częstotliwości.

      • [ 7.10 /H]* POWINNO używać tych połączonych mapowań stałych dotykowych .

      Jeśli implementacje urządzeń przenośnych obejmują co najmniej jeden liniowy siłownik rezonansowy, to:

      • [ 7.10 /H]* POWINIEN przesunąć siłownik dotykowy w osi X (lewo-prawo) w orientacji pionowej.

      • [ 7.10 /H]* POWINIEN zweryfikować iw razie potrzeby zaktualizować konfigurację awaryjną dla nieobsługiwanych prymitywów, jak opisano we wskazówkach dotyczących implementacji stałych.

      • [7.10/H]* POWINIEN zapewniać wsparcie awaryjne w celu ograniczenia ryzyka niepowodzenia zgodnie z opisem tutaj .

  • 2.2.3 Oprogramowanie :

    • Uwierzytelnianie Trivial Device Controls:

      Zobacz wersję

      • [ 3.8 .16/H-1-5] MUSI zapewnić użytkownikowi możliwość rezygnacji z wyznaczonych przez aplikację, uwierzytelnionych i trywialnych kontroli urządzenia z kontroli zarejestrowanych przez aplikacje innych firm za pośrednictwem ControlsProviderService i Control Control.isAuthRequired API.

    • Powiadomienia MediaStyle:

      Zobacz wersję

      Jeśli implementacje urządzeń przenośnych obsługują powiadomienia MediaStyle :

      • [3.8.3.1/H-1-SR] ZDECYDOWANIE ZALECA SIĘ, aby zapewnić dostęp dla użytkownika (np. „przełącznik wyjścia”) z interfejsu użytkownika systemu, który umożliwia użytkownikom przełączanie się między odpowiednimi dostępnymi trasami mediów (np. urządzeniami Bluetooth i trasami dostarczonymi do MediaRouter2Manager ) gdy aplikacja publikuje powiadomienie MediaStyle z tokenem MediaSession .

  • 2.2.4 Wydajność i moc : nowe wymagania dotyczące aplikacji obsługujących usługi pierwszego planu.

    Zobacz wersję

    Implementacje urządzeń przenośnych:

    • [ 8.5 /H-0-1] MUSI zapewnić użytkownikowi w menu Ustawienia możliwość zatrzymania aplikacji, która działa na pierwszym planie, i wyświetlić wszystkie aplikacje, które mają aktywne usługi na pierwszym planie, oraz czas trwania każdej z tych usług od rozpoczęto zgodnie z opisem w dokumencie SDK .
      • Niektóre aplikacje MOGĄ być zwolnione z zatrzymywania lub umieszczania na liście użytkowników zgodnie z opisem w dokumencie SDK .

  • 2.2.7.1 Nośniki : Aktualizacje sekcji Nośniki przenośne z wymaganiami w następujący sposób:

    Zobacz wersję

    Jeśli implementacje urządzeń przenośnych zwracają android.os.Build.VERSION_CODES.T dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , wtedy:

    • [5.1/H-1-1] MUSI ogłosić maksymalną liczbę sesji sprzętowego dekodera wideo, które mogą być uruchomione jednocześnie w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints() .
    • [5.1/H-1-2] MUSI obsługiwać 6 sesji sprzętowego dekodera wideo (AVC, HEVC, VP9, ​​AV1 lub nowszy) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 1080p przy 30 fps.
    • [5.1/H-1-3] MUSI ogłaszać maksymalną liczbę sesji sprzętowego kodera wideo, które mogą być uruchamiane jednocześnie w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints() .
    • [5.1/H-1-4] MUSI obsługiwać 6 wystąpień sesji sprzętowego kodera wideo (AVC, HEVC, VP9, ​​AV1 lub nowszy) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 1080p przy 30 klatkach na sekundę.
    • [5.1/H-1-5] MUSI ogłaszać maksymalną liczbę sprzętowych sesji kodera i dekodera wideo, które mogą być uruchamiane jednocześnie w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints() .
    • [5.1/H-1-6] MUSI obsługiwać 6 instancji sprzętowego dekodera wideo i sesji sprzętowego kodera wideo (AVC, HEVC, VP9, ​​AV1 lub nowszy) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 1080p przy 30 klatkach na sekundę.
    • [5.1/H-1-7] MUSI mieć opóźnienie inicjalizacji kodeka 40 ms lub mniej dla sesji kodowania wideo 1080p lub mniejszej dla wszystkich sprzętowych koderów wideo pod obciążeniem. W tym przypadku ładowanie jest definiowane jako jednoczesna sesja transkodowania samego wideo 1080p do 720p przy użyciu sprzętowych kodeków wideo wraz z inicjalizacją nagrywania audio-wideo 1080p.
    • [5.1/H-1-8] MUSI mieć opóźnienie inicjalizacji kodeka 30 ms lub mniej dla sesji kodowania dźwięku o przepływności 128 kb/s lub niższej dla wszystkich koderów audio pod obciążeniem. W tym przypadku ładowanie jest definiowane jako jednoczesna sesja transkodowania samego wideo 1080p do 720p przy użyciu sprzętowych kodeków wideo wraz z inicjalizacją nagrywania audio-wideo 1080p.
    • [5.1/H-1-9] MUSI obsługiwać 2 instancje sesji bezpiecznego sprzętowego dekodera wideo (AVC, HEVC, VP9, ​​AV1 lub nowszy) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 1080p przy 30 fps.
    • [5.1/H-1-10] MUSI obsługiwać 3 instancje sesji niezabezpieczonego sprzętowego dekodera wideo wraz z 1 instancją sesji bezpiecznego sprzętowego dekodera wideo (łącznie 4 instancje) (AVC, HEVC, VP9, ​​AV1 lub nowszy) w dowolnym kodeku kombinacja działająca jednocześnie w rozdzielczości 1080p przy 30 klatkach na sekundę.
    • [5.1/ H-1-11] MUSI obsługiwać bezpieczny dekoder dla każdego sprzętowego dekodera AVC, HEVC, VP9 lub AV1 na urządzeniu.
    • [5.1/H-1-12] MUSI mieć opóźnienie inicjalizacji dekodera wideo wynoszące 40 ms lub mniej.
    • [5.1/H-1-13] MUSI mieć opóźnienie inicjalizacji dekodera audio wynoszące 30 ms lub mniej.
    • [5.1/H-1-14] MUSI obsługiwać dekoder sprzętowy AV1 Main 10, Level 4.1.
    • [5.1/H-SR] są zdecydowanie zalecane do obsługi Film Grain dla dekodera sprzętowego AV1.
    • [5.1/H-1-15] MUSI mieć co najmniej 1 sprzętowy dekoder wideo obsługujący 4K60.
    • [5.1/H-1-16] MUSI mieć co najmniej 1 sprzętowy koder wideo obsługujący 4K60.
    • [5.3/H-1-1] NIE WOLNO tracić więcej niż 1 klatki w ciągu 10 sekund (tj. mniej niż 0,167 procent spadku liczby klatek) w przypadku sesji wideo 1080p 60 kl./s pod obciążeniem. Obciążenie jest definiowane jako jednoczesna sesja transkodowania wideo 1080p do 720p przy użyciu sprzętowych kodeków wideo, a także odtwarzanie dźwięku AAC z szybkością 128 kb/s.
    • [5.3/H-1-2] NIE MOŻE spaść o więcej niż 1 klatkę w ciągu 10 sekund podczas zmiany rozdzielczości wideo w sesji wideo 60 kl./s pod obciążeniem. Obciążenie jest definiowane jako jednoczesna sesja transkodowania wideo 1080p do 720p przy użyciu sprzętowych kodeków wideo, a także odtwarzanie dźwięku AAC z szybkością 128 kb/s.
    • [5.6/H-1-1] MUSI mieć opóźnienie stuknij w ton 80 milisekund lub mniej przy użyciu testu stuknij w ton OboeTester lub testu stuknij w ton weryfikatora CTS.
    • [5.6/H-1-2] MUSI mieć opóźnienie dźwięku w obie strony wynoszące 80 milisekund lub mniej na co najmniej jednej obsługiwanej ścieżce danych.
    • [5.6/H-1-3] MUSI obsługiwać dźwięk >=24-bitowy dla wyjścia stereo przez gniazda audio 3,5 mm, jeśli jest obecne, i przez dźwięk USB, jeśli jest obsługiwany przez całą ścieżkę danych w przypadku konfiguracji z niskimi opóźnieniami i przesyłania strumieniowego. W przypadku konfiguracji z małym opóźnieniem AAudio powinno być używane przez aplikację w trybie wywołania zwrotnego o małym opóźnieniu. W przypadku konfiguracji przesyłania strumieniowego aplikacja powinna używać Java AudioTrack. Zarówno w konfiguracji z niskim opóźnieniem, jak i w konfiguracji przesyłania strumieniowego, wyjściowy ujście HAL powinien akceptować AUDIO_FORMAT_PCM_24_BIT , AUDIO_FORMAT_PCM_24_BIT_PACKED , AUDIO_FORMAT_PCM_32_BIT lub AUDIO_FORMAT_PCM_FLOAT jako docelowy format wyjściowy.
    • [5.6/H-1-4] MUSI obsługiwać >=4-kanałowe urządzenia audio USB (jest to używane przez kontrolery DJ do podglądu utworów).
    • [5.6/H-1-5] MUSI obsługiwać urządzenia MIDI zgodne z klasą i deklarować flagę funkcji MIDI.
    • [5.7/H-1-2] MUSI obsługiwać MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL z poniższymi możliwościami deszyfrowania treści.
    Minimalna wielkość próbki 4 MiB
    Minimalna liczba podpróbek — H264 lub HEVC 32
    Minimalna liczba podpróbek - VP9 9
    Minimalna liczba podpróbek - AV1 288
    Minimalny rozmiar bufora podpróbki 1 MiB
    Minimalny rozmiar ogólnego bufora kryptograficznego 500 KiB
    Minimalna liczba jednoczesnych sesji 30
    Minimalna liczba kluczy na sesję 20
    Minimalna łączna liczba kluczy (wszystkie sesje) 80
    Minimalna łączna liczba kluczy DRM (wszystkie sesje) 6
    Rozmiar wiadomości 16 KiB
    Odszyfrowane klatki na sekundę 60 kl./s

  • 2.2.7.2 Aparat : Aktualizacje wymagań dotyczących aparatu klasy wydajności mediów.

    Zobacz wersję

    Jeśli implementacje urządzeń przenośnych zwracają android.os.Build.VERSION_CODES.T dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , wtedy:

    • [7.5/H-1-1] MUSI mieć główną kamerę skierowaną do tyłu o rozdzielczości co najmniej 12 megapikseli, obsługującą nagrywanie wideo z szybkością 4k przy 30 klatkach na sekundę. Podstawowym aparatem skierowanym do tyłu jest aparat skierowany do tyłu z najniższym identyfikatorem kamery.
    • [7.5/H-1-2] MUSI mieć główną przednią kamerę o rozdzielczości co najmniej 5 megapikseli i obsługiwać przechwytywanie wideo w rozdzielczości 1080p przy 30 klatkach na sekundę. Podstawowym aparatem przednim jest aparat przedni z najniższym identyfikatorem kamery.
    • [7.5/H-1-3] MUSI obsługiwać właściwość android.info.supportedHardwareLevel jako FULL lub lepszą dla obu głównych kamer.
    • [7.5/H-1-4] MUSI obsługiwać CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME dla obu głównych kamer.
    • [7.5/H-1-5] MUSI mieć opóźnienie przechwytywania JPEG kamery 2 < 1000 ms dla rozdzielczości 1080p, jak zmierzono w teście wydajności kamery CTS w warunkach oświetleniowych ITS (3000 K) dla obu głównych kamer.
    • [7.5/H-1-6] MUSI mieć opóźnienie uruchamiania kamery 2 (otwarcie kamery do pierwszej klatki podglądu) < 500 ms, zgodnie z pomiarem w teście wydajności kamery CTS w warunkach oświetleniowych ITS (3000 K) dla obu głównych kamer.
    • [7.5/H-1-8] MUSI obsługiwać CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW i android.graphics.ImageFormat.RAW_SENSOR dla głównego tylnego aparatu.
    • [7.5/H-1-9] MUSI mieć tylną kamerę główną obsługującą rozdzielczość 720p lub 1080p przy 240 kl./s.
    • [7.5/H-1-10] MUSI mieć min. ZOOM_RATIO < 1,0 dla głównych kamer, jeśli kamera ultraszerokokątna RGB jest skierowana w tym samym kierunku.
    • [7.5/H-1-11] MUSI zaimplementować jednoczesne przesyłanie strumieniowe przód-tył w głównych kamerach.
    • [7.5/H-1-12] MUSI obsługiwać CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION zarówno dla głównego przedniego, jak i głównego tylnego aparatu.
    • [7.5/H-1-13] MUSI obsługiwać funkcję LOGICAL_MULTI_CAMERA dla głównych kamer, jeśli jest więcej niż 1 kamera RGB skierowana w tym samym kierunku.
    • [7.5/H-1-14] MUSI obsługiwać funkcję STREAM_USE_CASE zarówno dla głównego przedniego, jak i głównego tylnego aparatu.

  • 2.2.7.3 Sprzęt : Aktualizacje wymagań dotyczących klasy wydajności nośnika dla sprzętu.

    Zobacz wersję

    Jeśli implementacje urządzeń przenośnych zwracają android.os.Build.VERSION_CODES.T dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , wtedy:

    • [7.1.1.1/H-2-1] MUSI mieć rozdzielczość ekranu co najmniej 1080p.
    • [7.1.1.3/H-2-1] MUSI mieć gęstość ekranu co najmniej 400 dpi.
    • [7.6.1/H-2-1] MUSI mieć co najmniej 8 GB pamięci fizycznej.

  • 2.2.7.4 Wydajność : Aktualizacje klasy wydajności nośnika dla wydajności.

    Zobacz wersję

    Jeśli implementacje urządzeń przenośnych zwracają android.os.Build.VERSION_CODES.T dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , wtedy:

    • [8.2/H-1-1] MUSI zapewniać wydajność zapisu sekwencyjnego na poziomie co najmniej 125 MB/s.
    • [8.2/H-1-2] MUSI zapewniać wydajność zapisu losowego na poziomie co najmniej 10 MB/s.
    • [8.2/H-1-3] MUSI zapewniać wydajność odczytu sekwencyjnego na poziomie co najmniej 250 MB/s.
    • [8.2/H-1-4] MUSI zapewniać wydajność losowego odczytu na poziomie co najmniej 40 MB/s.

  • 2.5.1 Sprzęt : Aktualizacje wymagań dotyczących 3-osiowego akcelerometru i 3-osiowego żyroskopu, a także wymagań dotyczących kamery zewnętrznej.

    Zobacz wersję

    Implementacje urządzeń motoryzacyjnych:

    Jeśli implementacje urządzeń motoryzacyjnych zawierają akcelerometr, to:

    • [ 7.3 .1/A-1-1] MUSI być w stanie zgłaszać zdarzenia do częstotliwości co najmniej 100 Hz.

    Jeśli implementacje urządzeń obejmują akcelerometr 3-osiowy, to:

    • [ 7.3 .1/A-SR] ZDECYDOWANIE ZALECA SIĘ wdrożenie czujnika kompozytowego dla przyspieszeniomierza o ograniczonej osi.

    Jeśli implementacje urządzeń motoryzacyjnych obejmują akcelerometr z mniej niż 3 osiami, to:

    • [ 7.3 .1/A-1-3] MUSI wdrożyć i zgłosić czujnik TYPE_ACCELEROMETER_LIMITED_AXES .
    • [ 7.3 .1/A-1-4] MUSI wdrożyć i zgłosić czujnik TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED .

    Jeśli implementacje urządzeń motoryzacyjnych obejmują żyroskop, to:

    • [ 7.3 .4/A-2-1] MUSI być w stanie zgłaszać zdarzenia do częstotliwości co najmniej 100 Hz.
    • [ 7.3 .4/A-2-3] MUSI być w stanie mierzyć zmiany orientacji do 250 stopni na sekundę.
    • [ 7.3 .4/A-SR] ZDECYDOWANIE ZALECA SIĘ skonfigurowanie zakresu pomiarowego żyroskopu na +/-250 dps w celu maksymalizacji możliwej rozdzielczości.

    Jeśli implementacje urządzeń motoryzacyjnych obejmują 3-osiowy żyroskop, to:

    • [ 7.3 .4/A-SR] ZDECYDOWANIE ZALECA SIĘ wdrożenie czujnika kompozytowego dla żyroskopu o ograniczonej osi.

    Jeśli implementacje urządzeń motoryzacyjnych obejmują żyroskop z mniej niż 3 osiami, to:

    • [ 7.3 .4/A-4-1] MUSI wdrożyć i zgłosić czujnik TYPE_GYROSCOPE_LIMITED_AXES .
    • [ 7.3 .4/A-4-2] MUSI wdrożyć i zgłosić czujnik TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED .

    Jeśli implementacje urządzeń samochodowych zawierają czujnik TYPE_HEADING , to:

    • [ 7.3 .4/A-4-3] MUSI być w stanie zgłaszać zdarzenia do częstotliwości co najmniej 1 Hz.
    • [ 7.3 .4/A-SR] STRONGLY_RECOMMENDED zgłaszanie zdarzeń o częstotliwości do co najmniej 10 Hz.
    • POWINNA odnosić się do prawdziwej północy.
    • MUSI być dostępny nawet wtedy, gdy pojazd jest nieruchomy.
    • MUSI mieć rozdzielczość co najmniej 1 stopień.

    Kamera zewnętrzna to kamera, która rejestruje sceny poza implementacją urządzenia, na przykład kamera tylna kamera samochodowa .

    Jeśli implementacje urządzeń motoryzacyjnych obejmują zewnętrzną kamerę, w przypadku takiej kamery:

    • [ 7.5 .5/A-SR] ZDECYDOWANIE ZALECA się ustawienie kamery w taki sposób, aby dłuższy wymiar kamery był wyrównany z horyzontem.

    • POWINIEN obsługiwać ramy synchronizacji Androida .

    • MOŻE mieć sprzętowy lub programowy autofokus zaimplementowany w sterowniku aparatu.

    Jeśli implementacje urządzeń samochodowych obejmują jedną lub więcej kamer zewnętrznych i ładują usługę Exterior View System (EVS), to dla takiej kamery:

    • [ 7.5 /A-2-1] NIE WOLNO obracać ani tworzyć lustrzanego odbicia w poziomie podglądu z kamery.

    Implementacje urządzeń motoryzacyjnych:

    • MOŻE zawierać jedną lub więcej kamer, które są dostępne dla aplikacji innych firm.

    Jeśli implementacje urządzeń motoryzacyjnych zawierają co najmniej jedną kamerę i udostępniają ją aplikacjom stron trzecich, to:

    • [ 7.5 /A-3-1] MUSI zgłaszać flagę funkcji android.hardware.camera.any .
    • [ 7.5 /A-3-2] NIE WOLNO deklarować kamery jako kamery systemowej .
    • MOŻE obsługiwać kamery zewnętrzne opisane w punkcie 7.5.3 .
    • MOŻE zawierać funkcje (takie jak automatyczne ustawianie ostrości itp.) dostępne dla kamer skierowanych tyłem do kierunku jazdy, zgodnie z opisem w sekcji 7.5.1 .

  • 2.5.5 Model bezpieczeństwa : Nowe wymagania dotyczące uprawnień do kamer dla urządzeń samochodowych.

    Zobacz wersję

    Jeśli implementacje urządzeń motoryzacyjnych deklarują android.hardware.camera.any , to:

    • [ 9.8.2 /A-2-1] MUSI wyświetlać wskaźnik kamery, gdy aplikacja uzyskuje dostęp do danych z kamery na żywo, ale nie wtedy, gdy dostęp do kamery mają tylko aplikacje posiadające role określone w sekcji 9.1 Uprawnienia z CDD identyfikator [C-3-X].

    • [ 9.8.2 /A-2-2] NIE WOLNO ukrywać wskaźnika aparatu dla aplikacji systemowych, które mają widoczne interfejsy użytkownika lub bezpośrednią interakcję użytkownika.

  • 2.6.1 Wymagania dotyczące tabletu — Sprzęt : aktualizacja wymagań dotyczących rozmiaru ekranu tabletu.

    Zobacz wersję

    Tablet z systemem Android odnosi się do implementacji urządzenia z systemem Android, która zazwyczaj spełnia wszystkie następujące kryteria:

    • Ma ekran o przekątnej większej niż 7 cali i mniejszej niż 18 cali, mierzonej po przekątnej.

    Rozmiar ekranu

    • [ 7.1 .1.1/Tab-0-1] MUSI mieć ekran o przekątnej od 7 do 18 cali.

3. Oprogramowanie

  • 3.2.2 Parametry kompilacji : Zaktualizowano znaki ASCII w getSerial() .

    Zobacz wersję

    • [C-0-1] Aby zapewnić spójne, znaczące wartości we wszystkich implementacjach urządzeń, poniższa tabela zawiera dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi implementacje urządzeń MUSZĄ być zgodne.
    Parametr Detale
    getSerial() MUSI (być lub zwrócić) numer seryjny sprzętu, który MUSI być dostępny i niepowtarzalny dla urządzeń tego samego MODELU i PRODUCENTA. Wartość tego pola MUSI być zakodowana jako 7-bitowy ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9]+$” .

  • 3.2.3.5 Warunkowe intencje aplikacji : Aktualizacja wymagań dla warunkowych intencji aplikacji.

    Zobacz wersję

    Jeśli implementacje urządzeń obejmują duży wyświetlacz (zwykle o szerokości i wysokości wyświetlacza powyżej 600dp) i obsługują funkcję dzielenia , wówczas:

  • 3.5.1 Ograniczenia aplikacji : Aktualizacje ograniczeń aplikacji.

    Zobacz wersję

    Jeśli implementacje urządzeń implementują zastrzeżony mechanizm ograniczania aplikacji (np. zmiany lub ograniczania zachowań interfejsu API opisanych w pakiecie SDK) i ten mechanizm jest bardziej restrykcyjny niż zasobnik wstrzymania aplikacji z ograniczeniami , to:

    • [C-1-1] MUSI umożliwiać użytkownikowi przeglądanie listy aplikacji z ograniczeniami.
    • [C-1-2] MUSI zapewnić użytkownikom możliwość włączania/wyłączania wszystkich tych zastrzeżonych ograniczeń w każdej aplikacji.
    • [C-1-3] NIE MOŻE automatycznie stosować tych zastrzeżonych ograniczeń bez dowodów na złe działanie systemu, ale MOŻE stosować ograniczenia na aplikacje po wykryciu złego działania systemu, takiego jak zablokowane wakelocki, długo działające usługi i inne kryteria. Kryteria MOGĄ być określane przez osoby wdrażające urządzenia, ale MUSZĄ być powiązane z wpływem aplikacji na kondycję systemu. Inne kryteria, które nie są wyłącznie związane ze stanem systemu, takie jak brak popularności aplikacji na rynku, NIE MOGĄ być używane jako kryteria.
    • [C-1-4] NIE WOLNO automatycznie stosować tych zastrzeżonych ograniczeń do aplikacji, gdy użytkownik ręcznie wyłączył ograniczenia aplikacji, i MOŻE sugerować użytkownikowi zastosowanie tych zastrzeżonych ograniczeń.

    • [C-1-5] MUSI informować użytkowników, czy te zastrzeżone ograniczenia są stosowane do aplikacji automatycznie. Takie informacje MUSZĄ zostać dostarczone w ciągu 24 godzin poprzedzających zastosowanie tych ograniczeń własnościowych.

    • [C-1-6] MUSI zwracać wartość true dla metody ActivityManager.isBackgroundRestricted() dla wszystkich wywołań API z aplikacji.

    • [C-1-7] NIE WOLNO ograniczać aplikacji na pierwszym planie, która jest jawnie używana przez użytkownika.

    • [C-1-8] MUSI zawiesić te zastrzeżone ograniczenia aplikacji za każdym razem, gdy użytkownik zaczyna jawnie korzystać z aplikacji, czyniąc ją pierwszą aplikacją pierwszoplanową.

    • [C-1-9] MUSI zgłaszać wszystkie zdarzenia związane z ograniczeniami własności za pośrednictwem UsageStats.

    • [C-1-10] MUSI udostępnić publiczny i jasny dokument lub stronę internetową, które opisują, w jaki sposób stosowane są ograniczenia własności. Ten dokument lub witryna MUSI umożliwiać połączenie z dokumentami Android SDK i MUSI zawierać:

      • Warunki uruchomienia ograniczeń własnościowych.
      • Co i jak aplikacja może zostać ograniczona.
      • Jak aplikacja może zostać zwolniona z takich ograniczeń.
      • W jaki sposób aplikacja może zażądać zwolnienia z ograniczeń własnościowych, jeśli obsługują takie zwolnienie dla aplikacji, które użytkownik może zainstalować.

    Jeśli aplikacja jest wstępnie zainstalowana na urządzeniu i nigdy nie była jawnie używana przez użytkownika przez ponad 30 dni, [C-1-3] [C-1-5] są zwolnione.

  • 3.8.1 Program uruchamiający (ekran główny) : Aktualizacje obsługujące monochrome/adaptive-icon .

    Zobacz wersję

    Jeśli implementacje urządzeń obsługują ikony monochromatyczne , te ikony:

    • [C-6-1] MUSI być używane tylko wtedy, gdy użytkownik wyraźnie je włączy (np. poprzez Ustawienia lub menu wyboru tapety).

  • 3.8.2 Widżety : aktualizacja obecności widżetów aplikacji innych firm w programie uruchamiającym.

    Zobacz wersję

    Jeśli implementacje urządzeń obsługują widżety aplikacji innych firm:

    • [C-1-2] MUSI zawierać wbudowaną obsługę AppWidgets i ujawniać możliwości interfejsu użytkownika w celu dodawania, konfigurowania, przeglądania i usuwania AppWidgets bezpośrednio w programie uruchamiającym.

  • 3.8.3.1 Prezentacja powiadomień : Wyjaśnienie definicji powiadomień heads-up.

    Zobacz wersję

    Powiadomienia head-up to powiadomienia, które są wyświetlane użytkownikowi w miarę ich nadejścia, niezależnie od powierzchni, na której się znajduje.

  • 3.8.3.3 DND (nie przeszkadzać) / tryb priorytetowy : Aktualizacja obejmuje tryb priorytetowy w wymaganiach DND (nie przeszkadzać).

    Zobacz wersję

    3.8.3.3. DND (nie przeszkadzać) / tryb priorytetowy

    Jeśli implementacje urządzeń obsługują funkcję DND (zwaną także trybem priorytetowym), to:

  • 3.8.6 Tematy : Nowe wymagania dotyczące dynamicznych palet tonalnych kolorów.

    Zobacz wersję

    Jeśli implementacje urządzeń obejmują ekran lub wyjście wideo, to:

    • [C-1-4] MUST generate dynamic color tonal palettes as specified in the AOSP documentation of Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (see android.theme.customization.system_palette and android.theme.customization.theme_style ).

    • [C-1-5] MUST generate dynamic color tonal palettes using color theme styles enumerated in the Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES documentation (see android.theme.customization.theme_styles ), namely TONAL_SPOT , VIBRANT , EXPRESSIVE , SPRITZ , RAINBOW , FRUIT_SALAD .

      "Source color" used to generate dynamic color tonal palettes when sent with android.theme.customization.system_palette (as documented in Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES ).

    • [C-1-6] MUST have a CAM16 chroma value of 5 or larger.

      • SHOULD be derived from the wallpaper via com.android.systemui.monet.ColorScheme#getSeedColors , which provides multiple valid source colors to pick one from.

      • SHOULD use the value 0xFF1B6EF3 , if none of the provided colors meet the above source color requirement.

  • 3.8.17 Clipboard : Added new requirements section for content on the clipboard.

    See revision

    3.8.17. Clipboard

    Device implementations:

    • [C-0-1] MUST NOT send clipboard data to any component, activity, service, or across any network connection, without explicit user action (eg, pressing a button on the overlay), except for services mentioned in 9.8.6 Content Capture and App Search .

    If device implementations generate a user-visible preview when content is copied to the clipboard for any ClipData item where ClipData.getDescription().getExtras() contains android.content.extra.IS_SENSITIVE , they:

    • [C-1-1] MUST redact the user visible preview

    The AOSP reference implementation satisfies these clipboard requirements.

  • 3.9.1.1 Device Owner Provisioning : Updates to device owner provisioning requirements.

    See revision

    If device implementations declare android.software.device_admin , they:

    • [C-1-1] MUST support enrolling a Device Policy Client (DPC) as a Device Owner app as described below:
      • When the device implementation has neither users nor user data configured, it:
        • [C-1-5] MUST enroll the DPC application as the Device Owner app or enable the DPC app to choose whether to become a Device Owner or a Profile Owner, if the device declares Near-Field Communications (NFC) support via the feature flag android.hardware.nfc and receives an NFC message containing a record with MIME type MIME_TYPE_PROVISIONING_NFC .
        • [C-1-8] MUST send the ACTION_GET_PROVISIONING_MODE intent after device owner provisioning is triggered so that the DPC app can choose whether to become a Device Owner or a Profile Owner, depending on the values of android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES , unless it can be determined from context that there is only one valid option. (such as for NFC based provisioning where Profile Owner provisioning is not supported).
        • [C-1-9] MUST send the ACTION_ADMIN_POLICY_COMPLIANCE intent to the Device Owner app if a Device Owner is established during provisioning regardless of the provisioning method used. The user must not be able to proceed in the Setup Wizard until the Device Owner app finishes.
      • When the device implementation has users or user data, it:
        • [C-1-7] MUST not enroll any DPC application as the Device Owner App any more.
    • [C-1-2] MUST show an appropriate disclosure notice (such as referenced in AOSP ) and obtain affirmative consent from the end user prior to an app being set as Device Owner, unless the device is programmatically configured for retail demo mode prior to on-screen, end-user interaction. require some affirmative action before or during the provisioning process to consent to an app being set as Device Owner. Consent can be via user action or by some programmatic means but appropriate disclosure notice (as referenced in AOSP) MUST be shown before device owner provisioning is initiated. Also, the programmatic device owner consent mechanism used (by enterprises) for device owner provisioning MUST NOT interfere with the Out-Of-Box Experience for non-enterprise use.
    • [C-1-3] MUST NOT hard code the consent or prevent the use of other device owner apps.

    If device implementations declare android.software.device_admin , but also include a proprietary Device Owner device management solution and provide a mechanism to promote an application configured in their solution as a "Device Owner equivalent" to the standard "Device Owner" as recognized by the standard Android DevicePolicyManager APIs, they:

    • [C-2-1] MUST have a process in place to verify that the specific app being promoted belongs to a legitimate enterprise device management solution and has been configured in the proprietary solution to have the rights equivalent as a "Device Owner".
    • [C-2-2] MUST show the same AOSP Device Owner consent disclosure as the flow initiated by android.app.action.PROVISION_MANAGED_DEVICE prior to enrolling the DPC application as "Device Owner".
    • [C-2-3] MUST NOT hard code the consent or prevent the use of other device owner apps.
    • MAY have user data on the device prior to enrolling the DPC application as "Device Owner".

  • 3.9.4 Device Management Role Requirements : Added a section for Device Management Role Requirements.

    See revision

    3.9.4 Device Policy Management Role Requirements

    If device implementations report android.software.device_admin or android.software.managed_users , then they:

    • [C-1-1] MUST support the device policy management role as defined in section 9.1 . The application that holds the device policy management role MAY be defined by setting config_devicePolicyManagement to the package name. The package name MUST be followed by : and the signing certificate unless the application is preloaded.

    If a package name is not defined for config_devicePolicyManagement as described above:

    If a package name is defined for config_devicePolicyManagement as described above:

    • [C-3-1] The application MUST be installed on all profiles for a user .
    • [C-3-2] Device implementations MAY define an application that updates the device policy management role holder before provisioning by setting config_devicePolicyManagementUpdater .

    If a package name is defined for config_devicePolicyManagementUpdater as described above:

    • [C-4-1] The application MUST be preinstalled on the device.
    • [C-4-2] The application MUST implement an intent filter which resolves android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER .

  • 3.18 Contacts : Adding information for new contacts.

    See revision

    Default account for new contacts: Contacts Provider provides APIs to manage the setting of the default account when creating a new contact.

    If device implementations preload a contacts app, then the pre-loaded contacts app:

    • [C-2-1] MUST handle the intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT to launch a UI for account selection and save the setting to Contacts Provider when an account is selected.

    • [C-2-2] MUST honor the default account setting when handling Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT for the ContactsContracts.Contacts.CONTENT_TYPE and ContactsContract.RawContacts.CONTENT_TYPE by initially selecting the account.

4. Application Packaging Compatibility

5. Multimedia Compatibility

  • 5.1.2 Audio Decoding : Added new requirements for decoders capable of outputting mutli-channel audio.

    See revision

    If device implementations support the decoding of AAC input buffers of multichannel streams (ie more than two channels) to PCM through the default AAC audio decoder in the android.media.MediaCodec API, then the following MUST be supported:

    • [C-7-1] MUST be able to be configured by the application using the decoding with the key KEY_MAX_OUTPUT_CHANNEL_COUNT to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content.
    • [C-7-2] When decoding, the decoder MUST advertise the channel mask being used on the output format with the KEY_CHANNEL_MASK key, using the android.media.AudioFormat constants (example: CHANNEL_OUT_5POINT1 ).

    If device implementations support audio decoders other than the default AAC audio decoder and are capable of outputting multi-channel audio (ie more than 2 channels) when fed compressed multi-channel content, then:

    • [C-SR] The decoder is STRONGLY RECOMMENDED to be able to be configured by the application using the decoding with the key KEY_MAX_OUTPUT_CHANNEL_COUNT to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content.
    • [C-SR] When decoding, the decoder is STRONGLY RECOMMENDED to advertise the channel mask being used on the output format with the KEY_CHANNEL_MASK key, using the android.media.AudioFormat constants (example: CHANNEL_OUT_5POINT1 ).

  • 5.4.1 Raw Audio Capture and Microphone Information : Updates to supported audio sources for audio input streams.

    See revision

    If device implementations declare android.hardware.microphone , they:

  • 5.4.2 Capture for Voice Recognition : Updated requirements for voice recognition audio stream and added requirements for microphone gain levels.

    See revision

    If device implementations declare android.hardware.microphone , they:

    • SHOULD record the voice recognition audio stream with approximately flat amplitude versus frequency characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
    • SHOULD record the voice recognition audio stream with input sensitivity set such that a 90 dB sound power level (SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.

    • SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 30 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) (measured next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

  • 5.4.6 Microphone Gain Levels : Moved requirements for Microphone Gain Levels to section 5.4.2.

    See revision

    5.4.6. Microphone Gain Levels [Moved to 5.4.2]

    If device implementations declare android.hardware.microphone , they:

    • SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 5 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
    • SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) yields a response with RMS of 2500 for 16 bit-samples (or -22.35 dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

  • 5.5.4 Audio Offload : Updates to the audio offload playback requirements.

    See revision

    If device implementations support audio offload playback , they:

    • [C-SR] Are STRONGLY RECOMMENDED to trim the played gapless audio content between two clips with the same format when specified by the AudioTrack gapless API and the media container for MediaPlayer.

  • 5.6 Audio Latency : Updates to the audio latency requirements.

    See revision

    For the purposes of this section, use the following definitions:

    • cold output jitter . The variability among separate measurements of cold output latency values.
    • cold input jitter . The variability among separate measurements of cold input latency values.

    If device implementations declare android.hardware.audio.output , they MUST meet or exceed the following requirements:

    • [C-1-2] Cold output latency of 500 milliseconds or less.
    • [C-1-3] Opening an output stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

    If device implementations declare android.hardware.audio.output they are STRONGLY RECOMMENDED to meet or exceed the following requirements:

    • [C-SR] Cold output latency of 100 milliseconds or less over the speaker data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release, we will require Cold output latency of 200 ms or less as a MUST.
    • [C-SR] Minimize the cold output jitter.

    If device implementations include android.hardware.microphone , they MUST meet these input audio requirements:

    • [C-3-2] Cold input latency of 500 milliseconds or less.
    • [C-3-3] Opening an input stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

    If device implementations include android.hardware.microphone , they are STRONGLY RECOMMENDED to meet these input audio requirements:

    • [C-SR] Cold input latency of 100 milliseconds or less over the microphone data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release we will require Cold input latency of 200 ms or less as a MUST.

    • [C-SR] Continuous input latency of 30 milliseconds or less.
    • [C-SR] Minimize the cold input jitter.

  • 5.10 Professional Audio : Updates to audio latency requirements for professional audio support.

    See revision

    If device implementations report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager class, they:

    • [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less and SHOULD be 10 milliseconds or less over at least one supported path.
    • [C-1-5] MUST meet latencies and USB audio requirements using the AAudio native audio API and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY .
    • [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
    • [C-SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark . SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the “Automated Test” option and achieve the following results: * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
    • SHOULD have a latency from touch input to audio output of less than or equal to 40 ms.

    If device implementations include a 4 conductor 3.5mm audio jack, they:

    • [C-2-1] MUST have a mean Continuous Round-trip Audio Latency, as defined in section 5.6 Audio Latency , of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the audio jack path using an audio loopback dongle .

  • 5.12 HDR Video : Added a new section for HDR Video requirements.

6. Developer Tools and Options Compatibility

  • 6.1 Developer Tools : Updates to connectivity and GPU Kernel requirements.

    See revision

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , they:

    • [C-4-1] MUST have the AdbManager#isAdbWifiSupported() method return true .

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , and includes at least one camera, they:

    • [C-5-1] MUST have the AdbManager#isAdbWifiQrSupported() method return true .

    • GPU work information

      Device implementations:

      • [C-6-1] MUST implement the shell command dumpsys gpu --gpuwork to display the aggregated GPU work data returned by the power/gpu_work_period kernel tracepoint, or display no data if the tracepoint is not supported. The AOSP implementation is frameworks/native/services/gpuservice/gpuwork/ .

7. Hardware Compatibility

  • 7.1.4.1 OpenGL ES : Update to recommended extensions.

    See revision

    If device implementations support any of the OpenGL ES versions, they:

    • SHOULD support the EGL_IMG_context_priority and EGL_EXT_protected_content extensions.

  • 7.1.4.2 Vulkan : Updates to version supported for Vulkan.

    See revision

    If device implementations support OpenGL ES 3.1, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1
    • MUST NOT support a Vulkan Variant version (ie the variant part of the Vulkan core version MUST be zero).

    If device implementations include a screen or video output, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1

    If device implementations include support for Vulkan 1.0 or higher, they:

    • SHOULD support VkPhysicalDeviceProtectedMemoryFeatures and VK_EXT_global_priority .
    • [C-1-12] MUST NOT enumerate support for the VK_KHR_performance_query extension.
    • [C-SR] Are STRONGLY RECOMMENDED to satisfy the requirements specified by the Android Baseline 2021 profile.

  • 7.2.3 Navigation Keys :

    See revision

    Device implementations:

    • [C-SR] Are STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 'Cancellable' is defined as the user's ability to prevent the navigation function from executing (eg going home, going back, etc.) if the swipe is not released past a certain threshold.

    If the back navigation function is provided and the user cancels the Back gesture, then:

    • [C-8-1] OnBackInvokedCallback.onBackCancelled() MUST be called.
    • [C-8-2] OnBackInvokedCallback.onBackInvoked() MUST NOT be called.
    • [C-8-3] KEYCODE_BACK event MUST NOT be dispatched.

    If the back navigation function is provided but the foreground application does NOT have an OnBackInvokedCallback registered, then:

    • The system SHOULD provide an animation for the foreground application that suggests that the user is going back, as provided in AOSP.

    If device implementations provide support for the system API setNavBarMode to allow any system app with android.permission.STATUS_BAR permission to set the navigation bar mode, then they:

    • [C-9-1] MUST provide support for kid-friendly icons or button-based navigation as provided in the AOSP code.

  • 7.3.1 Accelerometer : Updates to sensor requirements for accelerometers.

    See revision

    If device implementations include an accelerometer, a 3-axis accelerometer, they:

    • [C-1-2] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [SR] are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [SR] are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

    If device implementations include a 3-axis accelerometer, they:

    • [C-2-1] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

    If device implementations include an accelerometer with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_ACCELEROMETER_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis accelerometer and any of the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors are implemented:

    • [C-4-1] The sum of their power consumption MUST always be less than 4 mW.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

    If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:

    • [C-6-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

  • 7.3.4 Gyroscopes : Updates to sensor requirements for gyroscopes.

    See revision

    If device implementations include a gyroscope, they:

    • [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
    • [C-1-4] MUST have a resolution of 12-bits or more.
    • [C-1-5] MUST be temperature compensated.
    • [C-1-6] MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
    • [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater than 1e-7 rad^2/s^2.
    • [C-SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
    • [C-SR] Are STRONGLY RECOMMENDED to have a resolution of 16-bits or more.
    • SHOULD report events up to at least 200 Hz.

    If device implementations include a 3-axis gyroscope, they:

    • [C-2-1] MUST implement the TYPE_GYROSCOPE sensor.

    If device implementations include a gyroscope with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_GYROSCOPE_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:

    • [C-4-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

  • 7.3.10 Biometric Sensors : Updates to sensor requirements for biometric sensors.

    See revision

    Biometric sensors can be classified as Class 3 (formerly Strong ), Class 2 (formerly Weak ), or Class 1 (formerly Convenience ) based on their spoof and imposter acceptance rates, and on the security of the biometric pipeline. This classification determines the capabilities the biometric sensor has to interface with the platform and with third-party applications. Sensors need to meet additional requirements as detailed below if they wish to be classified as either Class 1 , Class 2 or Class 3 . Sensors are classified as Class 1 by default, and need to meet additional requirements as detailed below if they wish to be classified as either Class 2 or Class 3 . Both Class 2 and Class 3 biometrics get additional capabilities as detailed below.

    If device implementations wish to treat a biometric sensor as Class 1 (formerly Convenience ), they:

    • [C-1-11] MUST have a spoof and imposter acceptance rate not higher than 30%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 30%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 40%, as measured by the Android Biometrics Test Protocols.

    If device implementations wish to treat a biometric sensor as Class 2 (formerly Weak ), they:

    • [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 20%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 30%, as measured by the Android Biometrics Test Protocols .

    If device implementations wish to treat a biometric sensor as Class 3 (formerly Strong ), they:

    • [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 7%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 20%, as measured by the Android Biometrics Test Protocols .

  • 7.3.13 IEEE 802.1.15.4 (UWB) : Added a new requirements section for UWB.

    See revision

    7.3.13. IEEE 802.1.15.4 (UWB)

    If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:

    • [C-1-1] MUST implement the corresponding Android API in android.uwb.
    • [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
    • [C-1-3] MUST support all the relevant UWB profiles defined in Android implementation.
    • [C-1-4] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
    • [C-1-5] MUST enforce that apps using UWB radio hold UWB_RANGING permission (under NEARBY_DEVICES permission group).
    • [C-1-6] Are STRONGLY RECOMMENDED to pass the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA .

  • 7.4.1 Telephony : Updates to telephony requirements for GSM and CDMA telephony, and cellular usage settings.

    See revision

    If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:

    If device implementations include GSM or CDMA telephony, then:

    If the device device implementations include GSM or CDMA telephony and provide a system status bar, then:

    • [C-6-7] MUST select a representative active subscription for a given group UUID to display to the user in any affordances that provide SIM status information. Examples of such affordances include the status bar cellular signal icon or quick settings tile.
    • [C-SR] It is STRONGLY RECOMMENDED that the representative subscription is chosen to be the active data subscription unless the device is in a voice call, during which it is STRONGLY RECOMMENDED that the representative subscription is the active voice subscription.

    If device implementations include GSM or CDMA telephony, then:

    • [C-6-8] MUST be capable of opening and concurrently utilizing the maximum number of logical channels (20 in total) for each UICC per ETSI TS 102 221.
    • [C-6-10] MUST NOT apply any of the following behaviors to active carrier apps (as designated by TelephonyManager#getCarrierServicePackageName ) automatically or without explicit user confirmation:
      • Revoke or limit network access
      • Revoke permissions
      • Restrict background or foreground app execution beyond the existing power management features included in AOSP
      • Disable or uninstall the app

    If device device implementations include GSM or CDMA telephony and all active, non-opportunistic subscriptions that share a group UUID are disabled, physically removed from the device, or marked opportunistic, then the device:

    • [C-7-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.

    If device implementations include GSM telephony but not CDMA telephony, they:

    If the device implementations support eUICCs with multiple ports and profiles, they:

  • 7.4.1.1 Number Blocking Compatibility : Updates to the number blocking requirements.

    See revision

    If device implementations report the android.hardware.telephony feature , they:

    • [C-1-4] MUST write to the platform call log provider for a blocked call and MUST filter calls with BLOCKED_TYPE out of the default call log view in the pre-installed dialer app.
    • SHOULD provide a user affordance to show blocked calls in the pre-installed dialer app.

  • 7.4.1.3 Cellular NAT-T Keepalive Offload : New section for Cellular NAT-T Keepalive Offload.

    See revision

    7.4.1.3. Cellular NAT-T Keepalive Offload

    Device implementations:

    • SHOULD include support for Cellular keepalive offload.

    If device implementations include support for Cellular keepalive offload and exposes the functionality to third-party apps, they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least one concurrent keepalive slot over cellular.
    • [C-1-3] MUST support as many concurrent cellular keepalive slots as are supported by the Cellular Radio HAL.
    • [C-SR] Are STRONGLY RECOMMENDED to support at least three cellular keepalive slots per radio instance.

    If device implementations do not include support for cellular keepalive offload, they:

    • [C-2-1] MUST return ERROR_UNSUPPORTED.

  • 7.4.2.5 Wi-Fi Location (Wi-Fi Round Trip Time - RTT) : Updates to Wi-Fi location accuracy.

    See revision

    If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:

    • [C-1-4] MUST be accurate to within 2 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
    • [C-SR] Are STRONGLY RECOMMENDED to report it accurately to within 1.5 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).

  • 7.4.2.6 Wi-Fi Keepalive Offload : Updated to add cellular keepalive offload requirements.

    See revision

    Device implementations:

    • SHOULD include support for Wi-Fi keepalive offload.

    If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi
      and at least one keepalive slot over cellular.

    If device implementations do not include support for Wi-Fi keepalive offload, they:

  • 7.4.2.9 Trust On First Use (TOFU) : Added Trust on First Use requirements section.

    See revision

    7.4.2.9 Trust On First Use (TOFU)

    If device implementations support Trust on first usage (TOFU) and allow the user to define WPA/WPA2/WPA3-Enterprise configurations, then they:

    • [C-4-1] MUST provide the user an option to select to use TOFU.

  • 7.4.3 Bluetooth : Update to Bluetooth requirements.

    See revision

    If device implementations support Bluetooth Audio profile, they:

    • SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (eg LDAC) with A2DP.

    If device implementations return true for the BluetoothAdapter.isLeAudioSupported() API, then they:

    • [C-7-1] MUST support unicast client.
    • [C-7-2] MUST support 2M PHY.
    • [C-7-3] MUST support LE Extended advertising.
    • [C-7-4] MUST support at least 2 CIS connections in a CIG.
    • [C-7-5] MUST enable BAP unicast client, CSIP set coordinator, MCP server, VCP controller, CCP server simultaneously.
    • [C-SR] Are STRONGLY RECOMMENDED to enable HAP unicast client.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, then they:

    • [C-8-1] MUST support at least 2 BIS links in a BIG.
    • [C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
    • [C-8-3] MUST support LE Periodic advertising.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, then they:

    • [C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
    • [C-9-2] MUST support LE Periodic advertising.

    If device implementations declare FEATURE_BLUETOOTH_LE , they:

    • [C-10-1] MUST have RSSI measurements be within +/-9dB for 95% of the measurements at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH in line of sight environment.
    • [C-10-2] MUST include Rx/Tx corrections to reduce per-channel deviations so that the measurements on each of the 3 channels, on each of the antennas (if multiple are used), are within +/-3dB of one another for 95% of the measurements.
    • [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH , where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
    • [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at ADVERTISE_TX_POWER_HIGH , where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.

    ZDECYDOWANIE ZALECA się przestrzeganie kroków konfiguracji pomiaru określonych w Wymaganiach dotyczących kalibracji obecności .

    If device implementations support Bluetooth version 5.0, then they:

    • [C-SR] Are STRONGLY RECOMMENDED to provide support for:
      • LE 2M PHY
      • LE Codec PHY
      • LE Advertising Extension
      • Periodic advertising
      • At least 10 advertisement sets
      • At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
      • LE Link Layer Privacy
      • A "resolving list" size of at least 8 entries

  • 7.4.9 UWB : Added a requirements section for UWB hardware.

    See revision

    7.4.9. UWB

    If device implementations report support for feature android.hardware.uwb via the android.content.pm.PackageManager class, then they:

    • [C-1-1] MUST ensure the distance measurements are within +/-15 cm for 95% of the measurements in the line of sight environment at 1m distance in a non-reflective chamber.
    • [C-1-2] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT held face up and tilted 45 degrees.

    ZDECYDOWANIE ZALECA się przestrzeganie kroków konfiguracji pomiaru określonych w Wymaganiach dotyczących kalibracji obecności .

  • 7.5 Cameras : Updates to the requirements for HDR 10-bit output capability.

    See revision

    If device implementations support HDR 10-bit output capability, then they:

    • [C-2-1] MUST support at least the HLG HDR profile for every camera device that supports 10-bit output.
    • [C-2-2] MUST support 10-bit output for either the primary rear-facing or the primary front-facing camera.
    • [C-SR] Are STRONGLY RECOMMENDED to support 10-bit output for both primary cameras.
    • [C-2-3] MUST support the same HDR profiles for all BACKWARD_COMPATIBLE-capable physical sub-cameras of a logical camera, and the logical camera itself.

    For Logical camera devices which support 10-bit HDR that implement the android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, they:

    • [C-3-1] MUST support switching between all the backwards-compatible physical cameras via the CONTROL_ZOOM_RATIO control on the logical camera.

  • 7.7.2 USB Host Mode : Revisions for dual role ports.

    See revision

    If device implementations include a USB port supporting host mode and USB Type-C, they:

    • [C-4-1] MUST implement Dual Role Port functionality as defined by the USB Type-C specification (section 4.5.1.3.3). For Dual Role Ports, On devices that include a 3.5mm audio jack, the USB sink detection (host mode) MAY be off by default but it MUST be possible for the user to enable it.

  • 7.11 Media Performance Class : Updated to include Android T.

    See revision

    If device implementations return non-zero value for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , they:

    • [C-1-3] MUST meet all requirements for "Media Performance Class" described in section 2.2.7 .

    In other words, media performance class in Android T is only defined for handheld devices at version T, S or R.

    See section 2.2.7 for device-specific requirements.

9. Security Model Compatibility

  • 9.1 Permissions : Extend accepted paths for permissions allowlists for preinstalled apps to APEX files.

    See revision

    • [C-0-2] Permissions with a protectionLevel of PROTECTION_FLAG_PRIVILEGED MUST only be granted to apps preinstalled in the privileged path(s) of the system image (as well as APEX files ) and be within the subset of the explicitly allowlisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the allowlisted permissions for each app from the files in the etc/permissions/ path and using the system/priv-app path as the privileged path.

  • 9.7 Security Features : Updates to initialization requirements to maintain kernel integrity.

    See revision

    Kernel integrity and self-protection features are integral to Android security. Device implementations:

    • [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables ( CONFIG_INIT_STACK_ALL or CONFIG_INIT_STACK_ALL_ZERO ). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.

  • 9.8.7 Privacy — Clipboard Access : Automatically clear clipboard data after 60 minutes following a cut/copy/paste activity to protect user privacy.

    See revision

    Device implementations:

    • [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the ClipboardManager API) unless the 3rd-party app is the default IME or is the app that currently has focus.
    • [C-0-2] MUST clear clipboard data at most 60 minutes after it has last been placed in a clipboard or read from a clipboard.

  • 9.11 Keys and Credentials : Updates to the secure lock screen requirements, including the addition of ECDH and 3DES to crypto algorithms.

    See revision

    When the device implementation supports a secure lock screen, it:

    • [C-1-2] MUST have implementations of RSA, AES, ECDSA, ECDH (if IKeyMintDevice is supported), 3DES, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub przestrzeni użytkownika mógłby uzyskać dostęp do stanu wewnętrznego izolowanego środowiska, w tym DMA. Nadrzędny projekt Android Open Source Project (AOSP) spełnia to wymaganie za pomocą implementacji Trusty , ale inne rozwiązanie oparte na ARM TrustZone lub zweryfikowana przez firmę zewnętrzną bezpieczna implementacja odpowiedniej izolacji opartej na hiperwizorze to alternatywne opcje.

  • 9.11.1 Secure Lock Screen, Authentication, and Virtual Devices : Added requirements section for virtual devices and authentication transfers.

    See revision

    If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:

    • [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less. When a physical token meets the requirements for TrustAgent implementations in CX, timeout restrictions defined in C-9-5 apply instead.

    If device implementations allow applications to create secondary virtual displays and do not support associated input events, such as via VirtualDeviceManager , they:

    • [C-9-1] MUST lock these secondary virtual display(s) when the device's default display is locked, and unlock these secondary virtual display(s) when the device's default display is unlocked.

    If device implementations allow applications to create secondary virtual displays and support associated input events, such as via VirtualDeviceManager , they:

    • [C-10-1] MUST support separate lock states per virtual device
    • [C-10-2] MUST disconnect all virtual devices upon idle timeout
    • [C-10-3] MUST have an idle timeout
    • [C-10-4] MUST lock all displays when the user initiates a lockdown , including via the lockdown user affordance required for handheld devices (see Section 2.2.5[9.11/H-1-2] )
    • [C-10-5] MUST have separate virtual device instances per user
    • [C-10-6] MUST disable the creation of associated input events via VirtualDeviceManager when indicated by DevicePolicyManager.setNearbyAppStreamingPolicy
    • [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)
    • [C-10-11] MUST disable authentication UI on virtual devices, including knowledge factor entry and biometric prompt
    • [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device
    • [C-10-13] MUST not use a virtual device lock state as user authentication authorization with the Android Keystore System. See KeyGenParameterSpec.Builder.setUserAuthentication* .

    When device implementations allow the user to transfer the primary authentication knowledge-factor from a source device to a target device, such as for initial setup of the target device, they:

    • [C-11-1] MUST encrypt the knowledge-factor with protection guarantees similar to those described in the Google Cloud Key Vault Service security whitepaper when transferring the knowledge-factor from the source device to the target device such that the knowledge-factor cannot be remotely decrypted or used to remotely unlock either device.
    • [C-11-2] MUST, on the source device , ask the user to confirm the knowledge-factor of the source device before transferring the knowledge-factor to the target device.
    • [C-11-3] MUST, on a target device lacking any set primary authentication knowledge-factor, ask the user to confirm a transferred knowledge-factor on the target device before setting that knowledge-factor as the primary authentication knowledge-factor for the target device and before making available any data transferred from a source device.

    If device implementations have a secure lock screen and include one or more trust agents, which call the TrustAgentService.grantTrust() System API with the FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE flag they:

    • [C-12-1] MUST only call grantTrust() with the flag when connected to a proximate physical device with a lockscreen of its own, and when the user has authenticated their identity against that lockscreen. Proximate devices can use on-wrist or on-body detection mechanisms after a one-time user unlock to satisfy the user authentication requirement.
    • [C-12-2] MUST put the device implementation into the TrustState.TRUSTABLE state when the screen is turned off (such as via a button press or display time out) and the TrustAgent has not revoked trust. The AOSP satisfies this requirement.
    • [C-12-3] MUST only move the device from TrustState.TRUSTABLE to the TrustState.TRUSTED state if the TrustAgent is still granting trust based on the requirements in C-12-1.
    • [C-12-4] MUST call TrustManagerService.revokeTrust() after a maximum of 24 hours from granting trust, an 8 hour idle window, or when the underlying connection to the proximate physical device is lost.

    If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:

    • [C-13-8] MUST block activities with the attribute android:canDisplayOnRemoteDevices or the meta-data android.activity.can_display_on_remote_devices set to false from being started on the virtualdevice.
    • [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.
    • [C-13-10] MUST disable installation of apps initiated from virtual devices.

  • 9.11.2 Strongbox : Making insider attack resistance (IAR) a necessary requirement.

    See revision

    To validate compliance with [C-1-3] through [C-1-9], device implementations:

    • [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will become a MUST requirement in Android 14 (AOSP experimental).

  • 9.11.3 Identity Credential : Added information about the Identity Credential system reference implementation.

    See revision

    The Identity Credential System is defined and achieved by implementing all APIs in the android.security.identity.* package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:

    The upstream Android Open Source Project provides a reference implementation of a trusted application ( libeic ) that can be used to implement the Identity Credential system.

  • 9.11.4 ID Attestation : Added a section for ID attestation requirement.

    See revision

    9.11.4. ID Attestation

    Device implementations MUST support ID attestation .

  • 9.17 Android Virtualization Framework : Added a requirements section for Android Virtualization Framework.

    See revision

    9.17. Android Virtualization Framework

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), the Android host:

    • [C-1-1] MUST support all the APIs defined by the android.system.virtualmachine.* package.
    • [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines.
    • [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
    • [C-1-4] MUST NOT allow untrusted code (eg 3p apps) to create and run a Protected Virtual Machine. Note: This might change in future Android releases.
    • [C-1-5] MUST NOT allow a Protected Virtual Machine to execute code that is not part of the factory image or their updates. Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), then any Protected Virtual Machine instance:

    • [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine.
    • [C-2-2] MUST NOT allow a Protected Virtual Machine to run an operating system that is not signed by the device implementor or OS vendor.
    • [C-2-3] MUST NOT allow a Protected Virtual Machine to execute data as code (eg SELinux neverallow execmem).
    • [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
    • [C-2-5] MUST implement Protected Virtual Machine defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems.
    • [C-2-6] MUST ensure that the pVM firmware refuses to boot if it cannot verify the initial image.
    • [C-2-7] MUST ensure that the pVM firmware refuses to boot if the integrity of the instance.img is compromised.

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), then the hypervisor:

    • [C-3-1] MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses.
    • [C-3-2] MUST wipe a page after it is used by a VM and before it is returned to the host (eg the pVM is destroyed).
    • [C-3-3] MUST ensure that the pVM firmware is loaded and executed prior to any code in a pVM.
    • [C-3-4] MUST ensure that BCC and CDIs provided to a pVM instance can only be derived by that particular instance.

    If the device implements support for the Android Virtualization Framework APIs, then across all areas:

    • [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.

    If the device implements support for the Android Virtualization Framework APIs, then:

    • [C-5-1] MUST support Isolated Compilation of an ART runtime update.

    If the device implements support for the Android Virtualization Framework APIs, then for Key Management:

    • [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
    • [C-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.

Back to top