Definicja zgodności z Androidem 17

1. Wprowadzenie

W tym dokumencie wymieniono wymagania, które muszą być spełnione, aby urządzenia były zgodne z Androidem 17.

Użycie słów „MUSI”, „NIE MOŻE”, „WYMAGANE”, „POWINIEN”, „NIE POWINIEN”, „ZALECANE”, „MOŻE” i „OPCJONALNE” jest zgodne ze standardem IETF zdefiniowanym w dokumencie RFC2119.

W tym dokumencie „wdrażający urządzenie” lub „wdrażający” to osoba lub organizacja, która opracowuje rozwiązanie sprzętowe lub programowe działające na Androidzie 17. „Wdrożenie urządzenia” lub „wdrożenie” to opracowane rozwiązanie sprzętowe lub programowe.

Aby urządzenie było uznawane za zgodne z Androidem 17, jego implementacja MUSI spełniać wymagania przedstawione w niniejszej definicji zgodności, w tym wszelkie dokumenty włączone przez odniesienie.

Jeśli ta definicja lub testy oprogramowania opisane w sekcji 10 są niejasne, niejednoznaczne lub niepełne, za zapewnienie zgodności z istniejącymi implementacjami odpowiada podmiot wdrażający urządzenie.

Dlatego Projekt Android Open Source jest zarówno referencyjną, jak i preferowaną implementacją Androida. Zdecydowanie zaleca się, aby producenci urządzeń w jak największym stopniu opierali swoje implementacje na kodzie źródłowym „upstream” dostępnym w ramach projektu Android Open Source Project. Chociaż niektóre komponenty można teoretycznie zastąpić alternatywnymi implementacjami, ZDECYDOWANIE ZALECA SIĘ, aby tego nie robić, ponieważ znacznie utrudni to przejście testów oprogramowania. Obowiązkiem implementującego jest zapewnienie pełnej zgodności zachowania z standardową implementacją Androida, w tym zgodności z Compatibility Test Suite i poza nim. Pamiętaj, że niektóre zamiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.

Wiele zasobów, do których linki znajdziesz w tym dokumencie, pochodzi bezpośrednio lub pośrednio z pakietu Android SDK i jest funkcjonalnie identycznych z informacjami zawartymi w dokumentacji tego pakietu. W przypadku rozbieżności między tą definicją zgodności lub pakietem testów zgodności a dokumentacją pakietu SDK za wiążącą uznaje się dokumentację pakietu SDK. Wszelkie szczegóły techniczne podane w zasobach, do których odwołujemy się w tym dokumencie, są uważane za część tej definicji zgodności.

1.1 Struktura dokumentu

1.1.1. Wymagania według typu urządzenia

Sekcja 2 zawiera wszystkie wymagania, które dotyczą konkretnego typu urządzenia. Każda podsekcja sekcji 2 jest poświęcona konkretnemu typowi urządzenia.

Wszystkie pozostałe wymagania, które mają zastosowanie do wszystkich implementacji na urządzeniach z Androidem, są wymienione w sekcjach po sekcji 2. W tym dokumencie te wymagania są określane jako „Wymagania podstawowe”.

1.1.2. Identyfikator wymagania

Identyfikator wymagania jest przypisywany do wymagań MUST.

• Identyfikator jest przypisywany tylko w przypadku wymagań MUST.
• Wymagania ZDECYDOWANIE ZALECANE są oznaczone jako [SR], ale nie mają przypisanego identyfikatora.
• Identyfikator składa się z tych elementów : identyfikator typu urządzenia – identyfikator warunku – identyfikator wymagania (np. C-0-1).

Każdy identyfikator jest zdefiniowany w ten sposób:

• Identyfikator typu urządzenia (więcej informacji znajdziesz w sekcji 2. Typy urządzeń)
  • C: podstawowe (wymagania, które mają zastosowanie do wszystkich implementacji urządzeń z Androidem)
  • H: urządzenie przenośne z Androidem
  • T: urządzenie z Androidem TV
  • A: Implementacja Androida Automotive
  • W: Implementacja zegarka z Androidem
  • Karta: wdrożenie na tablecie z Androidem
• Identyfikator warunku
  • Gdy wymaganie jest bezwarunkowe, ten identyfikator ma wartość 0.
  • Gdy wymaganie jest warunkowe, pierwszemu warunkowi przypisywana jest wartość 1, a w ramach tej samej sekcji i tego samego typu urządzenia liczba zwiększa się o 1.
• Identyfikator wymagania
  • Identyfikator zaczyna się od 1 i zwiększa się o 1 w ramach tej samej sekcji i tego samego warunku.

1.1.3. Identyfikator wymagania w sekcji 2

Identyfikatory wymagań w sekcji 2 składają się z 2 części. Pierwsza z nich odpowiada identyfikatorowi sekcji, jak opisano powyżej. Druga część określa format i wymagania dotyczące tego formatu.

Identyfikator sekcji, po którym następuje identyfikator wymagania opisany powyżej.

• Identyfikator w sekcji 2 składa się z tych elementów: Identyfikator sekcji / identyfikator typu urządzenia – identyfikator warunku – identyfikator wymagania (np. 7.4.3/A-0-1).

2. Typy urządzeń

Projekt Android Open Source udostępnia zestaw oprogramowania, który można wykorzystywać na różnych typach urządzeń i w różnych formatach. Aby zapewnić bezpieczeństwo na urządzeniach, stos oprogramowania, w tym każdy zamienny system operacyjny lub alternatywna implementacja jądra, powinien działać w bezpiecznym środowisku, zgodnie z opisem w sekcji 9 i w innych miejscach tego dokumentu CDD. Istnieje kilka typów urządzeń, które mają stosunkowo lepiej rozwinięty ekosystem dystrybucji aplikacji.

W tej sekcji opisujemy te typy urządzeń oraz dodatkowe wymagania i zalecenia dotyczące każdego z nich.

Wszystkie implementacje urządzeń z Androidem, które nie pasują do żadnego z opisanych typów urządzeń, MUSZĄ spełniać wszystkie wymagania z innych sekcji niniejszej Definicji zgodności.

2.1 Konfiguracje urządzeń

Główne różnice w konfiguracji sprzętu w zależności od typu urządzenia znajdziesz w wymaganiach dotyczących poszczególnych urządzeń w tej sekcji.

2.2. Wymagania dotyczące urządzeń przenośnych

Urządzenie przenośne z Androidem to urządzenie z Androidem, które zwykle trzyma się w ręce, np. odtwarzacz MP3, telefon lub tablet.

Implementacje na urządzeniach z Androidem są klasyfikowane jako urządzenia przenośne, jeśli spełniają wszystkie te kryteria:

• mieć źródło zasilania, które zapewnia mobilność, np. baterię;
• ma fizyczną przekątną ekranu w zakresie od 4 do 8 cali;
• ma interfejs dotykowy,

Dodatkowe wymagania w pozostałej części tej sekcji dotyczą implementacji urządzeń przenośnych z Androidem.

2.2.1. Sprzęt

Implementacje urządzeń przenośnych:

• [7.1.1.1/H-0-1] MUSI mieć co najmniej 1 wyświetlacz zgodny z Androidem, który ma co najmniej 2,2 cala na krótszej krawędzi i 3,4 cala na dłuższej krawędzi.

• [7.1.1.3/H-SR-1] Zdecydowanie zaleca się, aby aplikacje umożliwiały użytkownikom zmianę rozmiaru wyświetlania (gęstości ekranu).

• [7.1.1.1/H-0-2] MUSI obsługiwać kompozycję GPU buforów graficznych o rozdzielczości co najmniej tak dużej jak najwyższa rozdzielczość dowolnego wbudowanego wyświetlacza.

• [7.1.1.1/H-0-3]^* MUSI mapować każdy wyświetlacz udostępniony aplikacjom innych firm na niezasłonięty obszar fizycznego wyświetlacza o wymiarach co najmniej 2,2 cala na krótszej krawędzi i 3,4 cala na dłuższej krawędzi.UI_MODE_NORMAL

• [7.1.1.3/H-0-1]^* MUSI mieć wartość 92% lub większą niż rzeczywista, fizyczna gęstość odpowiedniego wyświetlacza.DENSITY_DEVICE_STABLE

Jeśli urządzenia przenośne obsługują Vulkan, to:

• [7.1.4.2/H-1-1] MUSI spełniać wymagania określone w profilu Android Baseline 2021.

Jeśli urządzenia przenośne deklarują obsługę wyświetlaczy o szerokim zakresie dynamicznym za pomocą parametru Configuration.isScreenHdr():

• [7.1.4.5/H-1-1] MUSI reklamować obsługę rozszerzeń EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace i VK_EXT_hdr_metadata.

Implementacje urządzeń przenośnych:

• [7.1.4.6/H-0-1] MUSI zgłaszać, czy urządzenie obsługuje funkcję profilowania procesora graficznego, za pomocą właściwości systemugraphics.gpu.profiler.support.

Jeśli implementacje urządzeń przenośnych deklarują obsługę za pomocą właściwości systemowej graphics.gpu.profiler.support:

• [7.1.4.6/H-1-1] MUSI generować ślad w formacie protobuf zgodny ze schematem liczników GPU i etapów renderowania GPU zdefiniowanym w dokumentacji Perfetto.

• [7.1.4.6/H-1-2] MUSI raportować zgodne wartości liczników GPU urządzenia zgodnie z gpu counter trace protokołem pakietu.

• [7.1.4.6/H-1-3] MUSI raportować zgodne wartości dla etapów renderowania GPU urządzenia zgodnie z protokołem pakietu śledzenia etapu renderowania.

• [7.1.4.6/H-1-4] MUSI zgłaszać punkt śledzenia częstotliwości GPU w formacie:power/gpu_frequency.

Implementacje urządzeń przenośnych:

• [7.1.5/H-0-1] MUSI obsługiwać tryb zgodności ze starszymi aplikacjami zaimplementowany w źródłowym kodzie Androida. Oznacza to, że implementacje urządzeń NIE MOGĄ zmieniać wyzwalaczy ani progów, przy których aktywowany jest tryb zgodności, ani zmieniać działania samego trybu zgodności.

• [7.2.1/H-0-1] MUSI obsługiwać aplikacje edytora metody wprowadzania (IME) innych firm.

• [7.2.3/H-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno normalne, jak i długie naciśnięcie przycisku Wstecz (KEYCODE_BACK). System NIE MOŻE przetwarzać tych zdarzeń, a zdarzenia te MOGĄ być wywoływane poza urządzeniem z Androidem (np. przez zewnętrzną klawiaturę sprzętową podłączoną do urządzenia z Androidem).

• [7.2.3/H-0-3] MUSI udostępniać funkcję Strona główna na wszystkich wyświetlaczach zgodnych z Androidem, które wyświetlają ekran główny.

• [7.2.3/H-0-4] MUSI udostępniać funkcję Wstecz na wszystkich wyświetlaczach zgodnych z Androidem oraz funkcję Ostatnie na co najmniej jednym z wyświetlaczy zgodnych z Androidem.

• [7.2.4/H-0-1] MUSI obsługiwać wprowadzanie danych za pomocą ekranu dotykowego.

• [7.2.4/H-SR-1] Zdecydowanie zaleca się uruchamianie wybranej przez użytkownika aplikacji asystującej, czyli aplikacji, która implementuje VoiceInteractionService lub aktywność obsługującą ACTION_ASSIST po długim naciśnięciu KEYCODE_MEDIA_PLAY_PAUSE lub KEYCODE_HEADSETHOOK, jeśli aktywność na pierwszym planie nie obsługuje tych zdarzeń długiego naciśnięcia.

• [7.3.1/H-SR-1] Zdecydowanie zaleca się, aby zawierały 3-osiowy akcelerometr.

Jeśli implementacje urządzeń przenośnych obejmują 3-osiowy akcelerometr:

• [7.3.1/H-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 100 Hz.

Jeśli urządzenia przenośne mają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, to:

• [7.3.3/H-2-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.

• [7.3.3/H-2-2] MUSI zgłaszać pseudoodległości i szybkości pseudoodległości GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 0,2 m/s², wystarczają do obliczenia pozycji z dokładnością do 20 metrów i prędkości z dokładnością do 0,2 m/s co najmniej w 95% przypadków.

Jeśli implementacje urządzeń przenośnych obejmują 3-osiowy żyroskop:

• [7.3.4/H-3-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 100 Hz.

• [7.3.4/H-3-2] MUSI być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.

Implementacje urządzeń przenośnych, które mogą nawiązywać połączenia głosowe i wskazywać dowolną wartość inną niż PHONE_TYPE_NONE w getPhoneType:

• [7.3.8/H] POWINIEN zawierać czujnik zbliżeniowy.

Implementacje urządzeń przenośnych:

• [7.3.11/H-SR-1] Zdecydowanie zaleca się obsługę czujnika pozycji z 6 stopniami swobody.

Implementacje urządzeń przenośnych, które obsługują Bluetooth LE:

• [7.4.3/H-SR-1] Zdecydowanie zaleca się obsługę rozszerzenia długości pakietu danych Bluetooth LE.

Jeśli urządzenia obsługują standard 802.11 (Wi-Fi):

• [7.4.2.4/H-1-1] MUSI obsługiwać Wi-Fi Passpoint.

Jeśli urządzenia obsługują protokół Wi-Fi Neighbor Awareness Networking (NAN) przez zadeklarowanie PackageManager.FEATURE_WIFI_AWARE i Wi-Fi Location (Wi-Fi Round Trip Time – RTT) przez zadeklarowanie PackageManager.FEATURE_WIFI_RTT, to:

• [7.4.2.5/H-1-1] MUSI dokładnie podawać zakres z dokładnością do +/-1 metra przy paśmie 160 MHz na 68 percentylu (obliczanym za pomocą funkcji dystrybuanty), +/-2 metrów przy paśmie 80 MHz na 68 percentylu, +/-4 metrów przy paśmie 40 MHz na 68 percentylu i +/-8 metrów przy paśmie 20 MHz na 68 percentylu w odległościach 10 cm, 1 m, 3 m i 5 m, zgodnie z obserwacjami za pomocą interfejsu API Androida WifiRttManager#startRanging.

• [7.4.2.5/H-SR-1] Zdecydowanie zaleca się, aby urządzenia zgłaszały zakres z dokładnością do +/-1 metra przy paśmie 160 MHz na 90 percentylu (obliczanym za pomocą funkcji dystrybuanty), +/-2 metrów przy paśmie 80 MHz na 90 percentylu, +/-4 metrów przy paśmie 40 MHz na 90 percentylu i +/-8 metrów przy paśmie 20 MHz na 90 percentylu w odległościach 10 cm, zgodnie z obserwacjami za pomocą interfejsu API Androida WifiRttManager#startRanging.

Zdecydowanie ZALECA się wykonanie czynności konfiguracyjnych pomiaru podanych w sekcji Kalibracja obecności.

Jeśli implementacje urządzeń przenośnych deklarują FEATURE_BLUETOOTH_LE, to:

• [7.4.3/H-1-3] MUSI mierzyć i kompensować przesunięcie Rx, aby zapewnić, że mediana sygnału RSSI BLE wynosi -50 dBm +/-15 dB w odległości 1 m od urządzenia referencyjnego transmitującego na poziomie ADVERTISE_TX_POWER_HIGH.

• [7.4.3/H-1-4] MUSI mierzyć i kompensować przesunięcie Tx, aby zapewnić, że mediana RSSI BLE wynosi -50 dBm +/-15 dB podczas skanowania z urządzenia referencyjnego umieszczonego w odległości 1 m i nadającego sygnał z mocą ADVERTISE_TX_POWER_HIGH.

Jeśli implementacje urządzeń przenośnych obejmują logiczne urządzenie aparatu, które wyświetla możliwości za pomocą CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, to:

• [7.5.4/H-1-1] MUSI mieć domyślnie normalne pole widzenia (FOV) i MUSI mieścić się w zakresie od 50 do 75 stopni.

Implementacje urządzeń przenośnych:

• [7.6.1/H-0-1] MUSI mieć co najmniej 4 GB dostępnej pamięci trwałej na prywatne dane aplikacji (czyli partycję /data).

• [7.6.1/H-0-2] MUSI zwracać wartość „true”,ActivityManager.isLowRamDevice() gdy jądro i przestrzeń użytkownika mają do dyspozycji mniej niż 1 GB pamięci.

Jeśli implementacje urządzeń przenośnych deklarują obsługę tylko 32-bitowego interfejsu ABI:

• [7.6.1/H-1-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 416 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do qHD (np. FWVGA).

• [7.6.1/H-2-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 592 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do HD+ (np. HD, WSVGA).

• [7.6.1/H-3-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 896 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do FHD (np. WSXGA+).

• [7.6.1/H-4-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 1344 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do QHD (np. QWXGA).

Jeśli implementacje urządzeń przenośnych deklarują obsługę dowolnego 64-bitowego interfejsu ABI (z dowolnym 32-bitowym interfejsem ABI lub bez niego):

• [7.6.1/H-5-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 816 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do qHD (np. FWVGA).

• [7.6.1/H-6-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 944 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do HD+ (np. HD, WSVGA).

• [7.6.1/H-7-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 1280 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do FHD (np. WSXGA+).

• [7.6.1/H-8-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1824 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do QHD (np. QWXGA).

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do przestrzeni pamięci udostępnianej oprócz pamięci już przypisanej do komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro na urządzeniach.

Jeśli urządzenia przenośne mają nie więcej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

• [7.6.1/H-9-1] MUSI deklarować flagę funkcji android.hardware.ram.low.

• [7.6.1/H-9-2] MUSI mieć co najmniej 1,1 GB pamięci trwałej na prywatne dane aplikacji (czyli partycję „/data”).

Jeśli urządzenia przenośne mają więcej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

• [7.6.1/H-10-1] MUSI mieć co najmniej 4 GB pamięci trwałej dostępnej na prywatne dane aplikacji (czyli partycję „/data”).

• POWINIEN zadeklarować flagę funkcji android.hardware.ram.normal.

Jeśli urządzenia przenośne mają co najmniej 2 GB i mniej niż 4 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

• [7.6.1/H-SR-1] Zdecydowanie zaleca się obsługę tylko 32-bitowej przestrzeni użytkownika (zarówno aplikacji, jak i kodu systemowego).

Jeśli urządzenia przenośne mają mniej niż 2 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

• [7.6.1/H-1-1] MUSI obsługiwać tylko jeden interfejs ABI (tylko 64-bitowy lub tylko 32-bitowy).

Implementacje urządzeń przenośnych:

• [7.6.2/H-0-1] NIE MOŻE udostępniać aplikacji pamięci współdzielonej o rozmiarze mniejszym niż 1 GiB.

• [7.7.1/H] POWINIEN zawierać port USB obsługujący tryb urządzenia peryferyjnego.

Jeśli urządzenia przenośne mają port USB z kontrolerem działającym w trybie urządzenia peryferyjnego:

• [7.7.1/H-1-1] MUSI implementować interfejs Android Open Accessory (AOA).

Jeśli urządzenia przenośne mają port USB obsługujący tryb hosta:

• [7.7.2/H-1-1] MUSI implementować klasę audio USB zgodnie z dokumentacją pakietu Android SDK.

Implementacje urządzeń przenośnych:

• [7.8.1/H-0-1] MUSI zawierać mikrofon.

• [7.8.2/H-0-1] MUSI mieć wyjście audio i deklarowaćandroid.hardware.audio.output.

Jeśli urządzenia przenośne spełniają wszystkie wymagania dotyczące wydajności w trybie VR i obsługują ten tryb:

• [7.9.1/H-1-1] MUSI deklarować flagę funkcji.android.hardware.vr.high_performance

• [7.9.1/H-1-2] MUSI zawierać aplikację implementującą interfejs android.service.vr.VrListenerService, którą można włączyć w aplikacjach VR za pomocą interfejsu android.app.Activity#setVrModeEnabled.

Jeśli urządzenia przenośne mają co najmniej 1 port USB-C w trybie hosta i obsługują klasę audio USB, oprócz wymagań z sekcji 7.7.2 muszą:

• [7.8.2.2/H-1-1] MUSI udostępniać następujące mapowanie oprogramowania kodów HID:

Funkcja	Mapowania	Kontekst	Zachowanie
A	Strona użycia HID: 0x0C Użycie HID: 0x0CD Klucz jądra: KEY_PLAYPAUSE Klucz Androida: KEYCODE_MEDIA_PLAY_PAUSE	Odtwarzanie multimediów	Wejście: krótkie naciśnięcie Wyjście: odtwarzanie lub wstrzymywanie
			Wejście: długie naciśnięcie Wyjście: uruchomienie polecenia głosowego Wysyła: android.speech.action.VOICE_SEARCH_HANDS_FREE, jeśli urządzenie jest zablokowane lub jego ekran jest wyłączony. W innych przypadkach wysyłaandroid.speech.RecognizerIntent.ACTION_WEB_SEARCH.
		Połączenie przychodzące	Dane wejściowe: krótkie naciśnięcie Dane wyjściowe: odebranie połączenia
			Dane wejściowe: naciśnij i przytrzymaj Dane wyjściowe: odrzuć połączenie
		Trwa rozmowa	Dane wejściowe: krótkie naciśnięcie Dane wyjściowe: zakończenie połączenia
			Wejście: długie naciśnięcie Wyjście: wyciszenie lub wyłączenie wyciszenia mikrofonu
B	Strona użycia HID: 0x0C Użycie HID: 0x0E9 Klucz jądra: KEY_VOLUMEUP Klucz Androida: VOLUME_UP	Odtwarzanie multimediów, trwająca rozmowa	Wejście: krótkie lub długie naciśnięcie Wyjście: zwiększa głośność systemu lub słuchawek
C	Strona użycia HID: 0x0C Użycie HID: 0x0EA Klucz jądra: KEY_VOLUMEDOWN Klucz Androida: VOLUME_DOWN	Odtwarzanie multimediów, trwająca rozmowa	Wejście: krótkie lub długie naciśnięcie Wyjście: zmniejsza głośność systemu lub słuchawek
D	Strona użycia HID: 0x0C Użycie HID: 0x0CF Klucz jądra: KEY_VOICECOMMAND Klucz Androida: KEYCODE_VOICE_ASSIST	Wszystkie. Można je wywołać w dowolnej instancji.	Wejście: krótkie lub długie naciśnięcie Wyjście: uruchomienie polecenia głosowego

• [7.8.2.2/H-1-2] MUSI wywoływać zdarzenie ACTION_HEADSET_PLUG po włożeniu wtyczki, ale tylko po prawidłowym wyliczeniu interfejsów i punktów końcowych audio USB w celu określenia typu podłączonego terminala.

Gdy wykryte zostaną terminale audio USB typu 0x0302:

• [7.8.2.2/H-2-1] MUSI wysyłać intencję ACTION_HEADSET_PLUG z dodatkowym parametrem „microphone” ustawionym na 0.

Gdy wykryte zostaną terminale audio USB typu 0x0402,

• [7.8.2.2/H-3-1] MUSI wysyłać intencję ACTION_HEADSET_PLUG z dodatkowym parametrem „microphone” ustawionym na 1.

Gdy wywoływany jest interfejs API AudioManager.getDevices(), a urządzenie peryferyjne USB jest podłączone:

• [7.8.2.2/H-4-1] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i roli isSink(), jeśli pole typu terminala audio USB ma wartość 0x0302.

• [7.8.2.2/H-4-2] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i rolę isSink(), jeśli pole typu terminala audio USB ma wartość 0x0402.

• [7.8.2.2/H-4-3] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i rolę isSource(), jeśli pole typu terminala audio USB ma wartość 0x0402.

• [7.8.2.2/H-4-4] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i rolę isSink(), jeśli pole typu terminala audio USB ma wartość 0x603.

• [7.8.2.2/H-4-5] MUSI zawierać urządzenie typuAudioDeviceInfo.TYPE_USB_DEVICE i rolę isSource(), jeśli pole typu terminala audio USB ma wartość 0x604.

• [7.8.2.2/H-4-6] MUSI zawierać urządzenie typuAudioDeviceInfo.TYPE_USB_DEVICE i roli isSink(), jeśli pole typu terminala audio USB ma wartość 0x400.

• [7.8.2.2/H-4-7] MUSI zawierać urządzenie typuAudioDeviceInfo.TYPE_USB_DEVICE i rolę isSource(), jeśli pole typu terminala audio USB ma wartość 0x400.

• [7.8.2.2/H-SR-1] ZDECYDOWANIE ZALECA SIĘ, aby po podłączeniu urządzenia audio USB-C przeprowadzić wyliczanie deskryptorów USB, zidentyfikować typy terminali i rozgłosić intencję ACTION_HEADSET_PLUG w czasie krótszym niż 1000 milisekund.

W przypadku implementacji urządzeń przenośnych, które deklarują android.hardware.audio.output i android.hardware.microphone, wymagania dotyczące RTL i TTL znajdziesz w sekcji 5.6.

Liniowy siłownik rezonansowy (LRA) to system sprężynowy o jednej masie, który ma dominującą częstotliwość rezonansową, przy której masa przesuwa się w kierunku pożądanego ruchu.

Jeśli implementacje urządzeń przenośnych obejmują co najmniej 1 uniwersalny liniowy siłownik rezonansowy7.10, muszą:

• [7.10/H] AKTUATOR POWINIEN być umieszczony w pobliżu miejsca, w którym urządzenie jest zwykle trzymane lub dotykane rękami.

• [7.10/H] POWINIEN poruszać siłownikiem haptycznym w osi X (lewo-prawo) w naturalnej orientacji urządzenia.

Jeśli urządzenia przenośne mają siłownik haptyczny ogólnego przeznaczenia, który jest liniowym siłownikiem rezonansowym (LRA) osi X:

• [7.10/H] POWINIEN mieć częstotliwość rezonansową LRA osi X poniżej 200 Hz.

Jeśli implementacje urządzeń przenośnych są zgodne z mapowaniem stałych haptycznych:

• [7.10/H]^* POWINIEN sprawdzać stan implementacji, wywołując interfejsy API android.os.Vibrator.areAllEffectsSupported() i android.os.Vibrator.arePrimitivesSupported().

• [7.10/H]^* POWINIEN przeprowadzić ocenę jakości stałych haptycznych.

• [7.10/H]^* POWINIEN weryfikować i w razie potrzeby aktualizować konfigurację rezerwową dla nieobsługiwanych typów prostych zgodnie z wskazówkami dotyczącymi implementacji stałych.

2.2.2. Multimedia

Urządzenia przenośne MUSZĄ obsługiwać te formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] Profil MPEG-4 AAC (AAC LC)
• [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
• [5.1/H-0-5] AAC ELD (enhanced low delay AAC)

Urządzenia przenośne MUSZĄ obsługiwać te formaty kodowania wideo i udostępniać je aplikacjom innych firm:

• [5.2/H-0-1] H.264 AVC
• [5.2/H-0-2] VP8
• [5.2/H-0-3] AV1

Implementacje na urządzeniach przenośnych MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

• [5.3/H-0-1] H.264 AVC
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9
• [5.3/H-0-6] AV1

2.2.3. Oprogramowanie

Implementacje urządzeń przenośnych:

• [3.2.3.1/H-0-1] MUSI mieć aplikację, która obsługuje intencje ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE i ACTION_CREATE_DOCUMENT zgodnie z opisem w dokumentach pakietu SDK oraz zapewnia użytkownikowi możliwość dostępu do danych dostawcy dokumentów za pomocą interfejsu DocumentsProvider API.

[3.2.3.1/H-SR-1] ZDECYDOWANIE ZALECA się wstępne wczytywanie aplikacji do obsługi poczty e-mail, która może obsługiwać intencje ACTION_SENDTO lub ACTION_SEND lub ACTION_SEND_MULTIPLE wysyłania e-maili.

[3.4.1/H-0-1] MUSI udostępniać pełną implementację interfejsu android.webkit.Webview API.

[3.4.2/H-0-1] MUSI zawierać samodzielną aplikację przeglądarki do ogólnego przeglądania internetu przez użytkowników.

• [3.8.1/H-SR-1] Zdecydowanie zaleca się wdrożenie domyślnego programu uruchamiającego, który obsługuje przypinanie skrótów, widżetów i widgetFeatures w aplikacji.

• [3.8.1/H-SR-2] Zdecydowanie zaleca się wdrożenie domyślnego programu uruchamiającego, który zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu ShortcutManager.

• [3.8.1/H-SR-3] ZDECYDOWANIE ZALECA SIĘ dołączenie domyślnej aplikacji uruchamiającej, która wyświetla plakietki na ikonach aplikacji.

• [3.8.3/H-0-1] MUSI umożliwiać aplikacjom innych firm powiadamianie użytkowników o ważnych wydarzeniach za pomocą klas interfejsu API Notification i NotificationManager.

• [3.8.3/H-0-2] MUSI obsługiwać powiadomienia rozszerzone.

• [3.8.3/H-0-3] MUSI obsługiwać powiadomienia w formie wyskakujących okienek.

• [3.8.3/H-0-4] MUSI zawierać panel powiadomień, który umożliwia użytkownikowi bezpośrednie sterowanie powiadomieniami (np. odpowiadanie na nie, odkładanie ich, odrzucanie i blokowanie) za pomocą elementów interfejsu, takich jak przyciski działań lub panel sterowania zaimplementowany w AOSP.

• [3.8.3/H-0-5] MUSI wyświetlać opcje podane w RemoteInput.Builder setChoices() w obszarze powiadomień.

• [3.8.3/H-SR-1] Zdecydowanie zalecamy wyświetlanie pierwszego wyboru udostępnionego za pomocą RemoteInput.Builder setChoices() w obszarze powiadomień bez dodatkowej interakcji ze strony użytkownika.

• [3.8.3/H-SR-2] ZDECYDOWANIE ZALECA SIĘ wyświetlanie wszystkich opcji dostępnych w RemoteInput.Builder setChoices() w obszarze powiadomień, gdy użytkownik rozwinie wszystkie powiadomienia w tym obszarze.

• [3.8.3.1/H-SR-1] Zdecydowanie zalecamy wyświetlanie działań, dla których Notification.Action.Builder.setContextual jest ustawiony jako true w linii z odpowiedziami wyświetlanymi przez Notification.Remoteinput.Builder.setChoices.

• [3.8.4/H-SR-1] Zdecydowanie zalecamy wdrożenie na urządzeniu asystenta, który będzie obsługiwać działanie Assist.

Jeśli implementacje urządzeń przenośnych obsługują powiadomienia w stylu multimediów:

• [3.8.3.1/H-SR-2] ZDECYDOWANIE ZALECA się udostępnienie użytkownikom możliwości (np. przełącznika wyjścia) dostępnej w interfejsie systemu, która pozwala im przełączać się między odpowiednimi dostępnymi ścieżkami multimediów (np. urządzeniami Bluetooth i ścieżkami udostępnianymi MediaRouter2Manager), gdy aplikacja opublikuje powiadomienie MediaStyle z tokenem MediaSession.

Powiadomienie o aktualizacji na żywo aplikacji może być promowane, jeśli spełnia ona wszystkie wymagania dotyczące promocji. Takie powiadomienie jest w tym dokumencie określane jako powiadomienie o aktualizacji na żywo. Implementacje na urządzeniach przenośnych MUSZĄ w widocznym miejscu wyświetlać promowane powiadomienie o aktualizacji na żywo zgodnie z tymi wymaganiami:

Jeśli implementacje urządzeń przenośnych deklarują API na poziomie 36.1 lub wyższym:

• [3.8.3.1/H-0-1] MUSI wyświetlać powiadomienie o promowanej aktualizacji na żywo w widocznym miejscu na ekranie blokady.

• [3.8.3.1/H-0-12] MUSI być wyświetlane u góry stosu powiadomień powiadomienie wyskakujące i nad kolorowymi powiadomieniami (gdzie setColorized jest true), gdy wśród innych powiadomień wyświetlane jest promowane powiadomienie o aktualizacji na żywo.

  • MOŻE określać kolejność wyświetlania promowanych powiadomień o aktualizacjach na żywo w obszarze powiadomień i na ekranie blokady, gdy więcej niż jedna aplikacja kwalifikuje się do wyświetlania promowanych powiadomień o aktualizacjach na żywo.

• [3.8.3.1/H-0-2] MUSI wyświetlać powiadomienie o promowanej aktualizacji na żywo w stanie rozwiniętym.

• [3.8.3.1/H-0-3] NIE MOŻE udostępniać użytkownikowi możliwości zwinięcia rozwiniętego powiadomienia powyżej.

• [3.8.3.1/H-0-4] MUSI wyświetlać podstawowe style (pogrubienie, kursywa i podkreślenie) treści tekstowych w promowanym powiadomieniu o aktualizacji na żywo, zgodnie z informacjami podanymi przez StyleSpan lub UnderlineSpan.

• [3.8.3.1/H-0-5] W promowanym powiadomieniu o aktualizacji na żywo MUSZĄ być wyświetlane tylko standardowe obiekty działania (za pomocą Notification.Action), a niestandardowe obiekty działania, takie jak pola wpisywania, przyciski odpowiedzi i działania kontekstowe, MUSZĄ być ukryte (za pomocą addRemoteInput() i setContextual()), nawet jeśli powiadomienie je zawiera.

• [3.8.3.1/H-0-6] W dokumentacji pakietu SDK MUSI być wyświetlana kompaktowa reprezentacja, zwana też elementem stanu, w przypadku promowanego powiadomienia o aktualizacji na żywo, które MUSI zawierać Notification.getSmallIcon().

  • [3.8.3.1/H-0-7] W przypadku reprezentacji kompaktowej inne pola są opcjonalne, ale jeśli można ją rozwinąć, MUSI wyświetlać Notification.getShortCriticalText() jeśli jest obecne, lub Notification.when jeśli nie ma pola Notification.getShortCriticalText.

  • [3.8.3.1/H-0-8] Jeśli jest więcej niż jedno powiadomienie o promowanych aktualizacjach na żywo, urządzenie MUSI wyświetlać co najmniej jedno z nich na pasku stanu w formie skróconej.

  • [3.8.3.1/H-0-9] Musi wyświetlać powiązane powiadomienie (zalecane) lub otwierać powiązaną aplikację (za pomocą Notification.contentIntent), gdy użytkownik kliknie reprezentację kompaktową.

  • [3.8.3.1/H-0-13] MUSI wyświetlać w powiązanym powiadomieniu te same treści, które są dostępne w panelu powiadomień.

• [3.8.3.1/H-0-10] MUSI udostępniać użytkownikowi możliwość wyłączenia i włączenia promowanego wyświetlania powiadomień poszczególnych aplikacji.

• [3.8.3.1/H-0-11] MUSI prawidłowo renderować wszystkie powiadomienia o aktualizacjach na żywo, w tym m.in. niepromowane powiadomienia o aktualizacjach na żywo, które nie spełniają lub tylko częściowo spełniają cechy promocji. Takie niepromowane powiadomienia MUSZĄ być wyświetlane w stanie niepromowanym.

Jeśli implementacje urządzeń, w tym klawisz nawigacyjny funkcji ostatnich aplikacji, zgodnie z opisem w sekcji 7.2.3, zmieniają interfejs, to:

• [3.8.3/H-1-1] MUSI implementować zachowanie przypinania ekranu i udostępniać użytkownikowi menu ustawień, w którym można włączać i wyłączać tę funkcję.

Jeśli implementacje urządzeń przenośnych obsługują działanie Asystuj, to:

• [3.8.4/H-SR-2] ZDECYDOWANIE ZALECA się używanie przytrzymania klawisza HOME jako wyznaczonej interakcji do uruchamiania aplikacji asystującej zgodnie z sekcją 7.2.3. MUSI uruchomić wybraną przez użytkownika aplikację asystującą, czyli aplikację, która implementuje VoiceInteractionService lub aktywność obsługującą intencję ACTION_ASSIST.

Jeśli implementacje urządzeń przenośnych obsługują conversation notifications i grupują je w osobnej sekcji od powiadomień z alertami i cichych powiadomień niebędących rozmowami:

• [3.8.4/H-1-1]^* MUSI wyświetlać powiadomienia o rozmowach przed powiadomieniami o innych zdarzeniach, z wyjątkiem powiadomień o usługach na pierwszym planie i powiadomień o wysokim priorytecie.

Jeśli urządzenia przenośne z Androidem obsługują ekran blokady:

• [3.8.10/H-1-1] MUSI wyświetlać powiadomienia na ekranie blokady, w tym szablon powiadomienia o multimediach.

Jeśli urządzenia przenośne obsługują bezpieczny ekran blokady:

• [3.9/H-1-1] MUSI implementować pełny zakres zasad administrowania urządzeniem zdefiniowanych w dokumentacji pakietu Android SDK.

Jeśli implementacje urządzeń przenośnych obejmują obsługę interfejsów API ControlsProviderService i Control oraz umożliwiają aplikacjom innych firm publikowanie elementów sterujących urządzeniem, to:

• [3.8.16/H-1-1] MUSI zadeklarować flagę funkcji android.software.controls i ustawić ją na wartość true.

• [3.8.16/H-1-2] MUSI udostępniać użytkownikowi afordancję z możliwością dodawania, edytowania, wybierania i obsługiwania ulubionych elementów sterowania urządzeniami spośród elementów sterowania zarejestrowanych przez aplikacje innych firm za pomocą interfejsów API ControlsProviderService i Control.

• [3.8.16/H-1-3] MUSI zapewniać dostęp do tego elementu interfejsu użytkownika w ciągu 3 interakcji od domyślnego programu uruchamiającego.

• [3.8.16/H-1-4] MUSI dokładnie renderować w tym obszarze interfejsu użytkownika nazwę i ikonę każdej aplikacji innej firmy, która udostępnia elementy sterujące za pomocą interfejsu ControlsProviderService API, a także wszystkie określone pola udostępniane przez interfejsy Control API.

• [3.8.16/H-1-5] MUSI udostępniać użytkownikowi możliwość rezygnacji z elementów sterujących urządzeniami, które są oznaczone jako niewymagające uwierzytelniania, w przypadku elementów sterujących zarejestrowanych przez aplikacje innych firm za pomocą interfejsów ControlsProviderService i Control Control.isAuthRequired API.

• [3.8.16/H-1-6] Implementacje urządzeń MUSZĄ dokładnie renderować afordancję użytkownika w ten sposób:

  • Jeśli urządzenie ma ustawioną wartość config_supportsMultiWindow=true, a aplikacja deklaruje metadane META_DATA_PANEL_ACTIVITY w deklaracji ControlsProviderService, w tym ComponentName prawidłowego działania (zgodnie z definicją API), musi ona osadzić to działanie w tym elemencie interfejsu użytkownika.
  • Jeśli aplikacja nie deklaruje metadanych META_DATA_PANEL_ACTIVITY, musi renderować określone pola dostarczone przez interfejs ControlsProviderService API, a także wszystkie określone pola dostarczone przez interfejsy Control API.

• [3.8.16/H-1-7] Jeśli aplikacja deklaruje metadane META_DATA_PANEL_ACTIVITY, musi przekazać ustawienie zdefiniowane w [3.8.16/H-1-5] za pomocą EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS podczas uruchamiania wbudowanej aktywności.

Z kolei jeśli implementacje na urządzeniach przenośnych nie zawierają takich elementów sterujących:

• [3.8.16/H-2-1] MUSI raportować null w przypadku interfejsów API ControlsProviderService i Control.

• [3.8.16/H-2-2] MUSI zadeklarować flagę funkcji android.software.controls i ustawić ją na false.

Jeśli implementacje urządzeń przenośnych nie działają w trybie blokowania zadań, po skopiowaniu treści do schowka:

• [3.8.17/H-1-1] MUSI wyświetlać użytkownikowi potwierdzenie, że dane zostały skopiowane do schowka (np. miniaturę lub alert „Treść skopiowana”). Dodaj też informację, czy dane ze schowka będą synchronizowane na różnych urządzeniach.

Implementacje urządzeń przenośnych:

• [3.10/H-0-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.

• [3.10/H-SR-1] Zdecydowanie zaleca się wstępne wczytywanie na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z usługami Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) lub większej niż one, takich jak usługi ułatwień dostępu udostępniane w ramach projektu TalkBack Open Source.

• [3.11/H-0-1] MUSI obsługiwać instalację silników TTS innych firm.

• [3.11/H-SR-1] Zdecydowanie zaleca się, aby zawierały silnik TTS obsługujący języki dostępne na urządzeniu.

• [3.13/H-SR-1] Zdecydowanie zaleca się uwzględnienie komponentu interfejsu Szybkich ustawień.

Jeśli implementacje urządzeń przenośnych z Androidem deklarują obsługę FEATURE_BLUETOOTH lub FEATURE_WIFI:

• [3.16/H-1-1] MUSI obsługiwać funkcję parowania urządzenia towarzyszącego.

Jeśli funkcja nawigacji jest dostępna jako działanie na ekranie oparte na gestach:

• [7.2.3/H] Strefa rozpoznawania gestów dla funkcji Strona główna NIE POWINNA być wyższa niż 32 dp od dolnej krawędzi ekranu.

Jeśli implementacje urządzeń przenośnych zapewniają funkcję nawigacji w postaci gestu wykonywanego w dowolnym miejscu na lewej i prawej krawędzi ekranu:

• [7.2.3/H-0-1] Obszar gestów funkcji nawigacji MUSI mieć szerokość mniejszą niż 40 dp po każdej stronie. Obszar gestów POWINIEN mieć domyślnie szerokość 24 dp.

Jeśli urządzenia przenośne obsługują bezpieczny ekran blokady i mają co najmniej 2 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

• [3.9/H-1-2] MUSI deklarować obsługę profili zarządzanych za pomocą flagi funkcji android.software.managed_users.

Jeśli implementacje urządzeń przenośnych z Androidem deklarują obsługę aparatu za pomocą android.hardware.camera.any:

• [7.5.4/H-1-1] MUSI uwzględniać intencje android.media.action.STILL_IMAGE_CAMERA i android.media.action.STILL_IMAGE_CAMERA_SECURE oraz uruchamiać aparat w trybie zdjęć, zgodnie z opisem w pakiecie SDK.

• [7.5.4/H-1-2] MUSI uwzględniać android.media.action.VIDEO_CAMERA zamiar uruchomienia aparatu w trybie wideo zgodnie z opisem w pakiecie SDK.

Jeśli aplikacja ustawień na urządzeniu implementuje funkcję podziału za pomocą osadzania aktywności:

• [3.2.3.1/ H-1-1] MUSI mieć aktywność, która obsługuje intencję Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY gdy funkcja podziału jest włączona. Aktywność MUSI być chroniona przez android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK i MUSI uruchamiać aktywność intencji przeanalizowanej z Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

2.2.4. Wydajność i moc

• [8.1/H-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie klatek lub opóźnienie renderowania klatek NIE MOŻE występować częściej niż 5 klatek na sekundę i POWINNO być mniejsze niż 1 klatka na sekundę.

• [8.1/H-0-2] Opóźnienie interfejsu. Implementacje urządzeń MUSZĄ zapewniać użytkownikom małe opóźnienia,przewijając listę 10 000 pozycji zdefiniowaną w pakiecie testów zgodności z Androidem (CTS) w czasie krótszym niż 36 sekund.

• [8.1/H-0-3] Przełączanie zadań. Jeśli uruchomiono wiele aplikacji, ponowne uruchomienie już działającej aplikacji MUSI zająć mniej niż 1 sekundę.

Implementacje urządzeń przenośnych:

• [8.2/H-0-1] MUSI zapewniać sekwencyjną wydajność zapisu na poziomie co najmniej 5 MB/s.

• [8.2/H-0-2] MUSI zapewniać wydajność losowego zapisu na poziomie co najmniej 0,5 MB/s.

• [8.2/H-0-3] MUSI zapewniać wydajność odczytu sekwencyjnego na poziomie co najmniej 15 MB/s.

• [8.2/H-0-4] MUSI zapewniać wydajność odczytu losowego na poziomie co najmniej 3,5 MB/s.

Jeśli implementacje urządzeń przenośnych zawierają funkcje poprawiające zarządzanie energią urządzenia, które są uwzględnione w AOSP lub rozszerzają funkcje uwzględnione w AOSP:

• [8.3/H-1-1] MUSI udostępniać użytkownikowi afordancję umożliwiającą włączanie i wyłączanie funkcji Oszczędzanie baterii.

• [8.3/H-1-2] MUSI udostępniać użytkownikowi możliwość wyświetlania wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii „Wstrzymanie aplikacji” i „Drzemka”.

Implementacje urządzeń przenośnych:

• [8.4/H-0-1] MUSI udostępniać profil zasilania poszczególnych komponentów, który określa wartość zużycia prądu każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez te komponenty w czasie, zgodnie z dokumentacją na stronie Projektu Android Open Source.

• [8.4/H-0-2] MUSI zgłaszać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).

• [8.4/H-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.

• [8.4/H-0-4] MUSI udostępniać te informacje o zużyciu energii deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.

• [8.4/H] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji.

Jeśli urządzenia przenośne mają ekran lub wyjście wideo:

• [8.4/H-1-1] MUSI uwzględniać android.intent.action.POWER_USAGE_SUMMARY intencję użytkownika i wyświetlać menu ustawień, w którym widoczne jest zużycie energii.

Implementacje urządzeń przenośnych:

• [8.5/H-0-1] MUSI udostępniać użytkownikowi afordancję do wyświetlania wszystkich aplikacji z aktywnymi usługami (działającymi) na pierwszym planie lub zadaniami zainicjowanymi przez użytkownika, w tym czasu trwania każdej z tych usług od momentu jej rozpoczęcia, zgodnie z opisem w dokumencie pakietu SDK.

• [8.5/H-0-2]MUSI udostępniać użytkownikowi możliwość zatrzymania aplikacji, która uruchamia usługę na pierwszym planie lub zadanie zainicjowane przez użytkownika.

2.2.5. Model zabezpieczeń

Implementacje urządzeń przenośnych:

• [9/H-0-1] MUSI deklarować funkcję android.hardware.security.model.compatible.

• [9.1/H-0-1] MUSI zezwalać aplikacjom innych firm na dostęp do statystyk użytkowania za pomocą uprawnienia android.permission.PACKAGE_USAGE_STATS i udostępniać użytkownikowi mechanizm przyznawania lub cofania dostępu do takich aplikacji w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Jeśli implementacje urządzeń przenośnych obejmują domyślną aplikację obsługującą VoiceInteractionService:

• [9.1/H-0-2] NIE MOŻE przyznawać ACCESS_FINE_LOCATION jako domyślnego ustawienia tej aplikacji.

Implementacje urządzeń MUSZĄ deklarować obsługę android.software.credentials i:

• [9/H-0-2] MUSI uwzględniać android.settings.CREDENTIAL_PROVIDERintencję umożliwienia wyboru preferowanego dostawcy w Menedżerze danych logowania. Ten dostawca będzie włączony w przypadku autouzupełniania, a także będzie domyślną lokalizacją do zapisywania nowych danych logowania wprowadzanych w usłudze Credential Manager.

• [9/H-0-3] MUSI obsługiwać co najmniej 2 jednocześnie działających dostawców danych logowania i zapewniać użytkownikowi możliwość włączania i wyłączania dostawców w aplikacji Ustawienia.

• [9.5/H-1-1] Wymaganie usunięte w Androidzie 16.

Implementacje urządzeń przenośnych:

• [9.11/H-0-2] MUSI tworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.

• [9.11/H-0-3] MUSI mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji skracania MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać algorytmy obsługiwane przez system Android Keystore w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i wyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego środowiska izolowanego, w tym DMA. Projekt Android Open Source (AOSP) spełnia to wymaganie, korzystając z implementacji Trusty, ale alternatywnymi opcjami są inne rozwiązania oparte na ARM TrustZone lub zweryfikowane przez zewnętrzną firmę bezpieczne implementacje odpowiedniej izolacji opartej na hiperwizorze.

• [9.11/H-0-4] MUSI przeprowadzać uwierzytelnianie na ekranie blokady w izolowanym środowisku wykonawczym i tylko w przypadku powodzenia zezwalać na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób, który umożliwia uwierzytelnianie na ekranie blokady tylko w izolowanym środowisku wykonawczym. Projekt Android Open Source udostępnia warstwę abstrakcji sprzętowej (HAL) Gatekeeper i Trusty, które mogą być używane do spełnienia tego wymagania.

• [9.11/H-0-5] MUSI obsługiwać atestowanie kluczy, w przypadku którego klucz podpisu atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania zaświadczeń NIE MOGĄ być używane jako trwałe identyfikatory urządzenia.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na wcześniejszej wersji Androida, takie urządzenie jest zwolnione z wymogu posiadania magazynu kluczy opartego na izolowanym środowisku wykonawczym i obsługi atestowania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy opartego na izolowanym środowisku wykonawczym.

Jeśli urządzenia przenośne obsługują bezpieczny ekran blokady:

• [9.11/H-1-1] MUSI umożliwiać użytkownikowi ustawienie najkrótszego czasu bezczynności, czyli czasu przejścia ze stanu odblokowanego do zablokowanego, na 15 sekund lub mniej.

• [9.11/H-1-2] MUSI umożliwiać użytkownikowi ukrywanie powiadomień i wyłączanie wszystkich form uwierzytelniania z wyjątkiem uwierzytelniania podstawowego opisanego w sekcji 9.11.1 Bezpieczny ekran blokady. AOSP spełnia wymagania trybu blokady.

Jeśli implementacje na urządzeniach przenośnych obejmują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, to:

• [9.5/H-2-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska, w których będą pracować dodatkowi użytkownicy. Mają też możliwość zarządzania bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli implementacje urządzeń przenośnych obejmują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony, to:

• [9.5/H-3-1] NIE MOŻE obsługiwać profili z ograniczeniami, ale MUSI być zgodny z implementacją AOSP elementów sterujących, które umożliwiają włączanie i wyłączanie dostępu innych użytkowników do połączeń głosowych i SMS-ów.

• [9.5/H-4-1] Wymaganie usunięte w Androidzie 16.

• [9.5/H-4-2] Wymaganie usunięte w Androidzie 16.

Ustawienia z ograniczeniem

Ustawienia z ograniczeniami wyświetlają użytkownikowi widoczne ostrzeżenia i proszą go o potwierdzenie, aby przyznać uprawnienia każdej aplikacji, która:

• zainstalowana po pobraniu za pomocą aplikacji (np. aplikacji do obsługi wiadomości lub przeglądarki) innej niż aplikacja „sklepu z aplikacjami” oznaczona przez PackageManager jako PACKAGE_DOWNLOADED_FILE;

• zainstalowana z pliku lokalnego (np. aplikacja została wgrana z pominięciem sklepu) zidentyfikowana przez PackageManager jako PACKAGE_SOURCE_LOCAL_FILE.

W przypadku dowolnych Wymaganych uprawnień i powiązanych z nimi identyfikatorów wymienionych w sekcji [9.8/H-0-5] poniżej.

Wymagania wymienione w tej sekcji dotyczą „Aplikacji objętych ochroną”.

Implementacje urządzeń:

• [9.8/H-0-1] MUSI implementować ustawienia z ograniczeniem w sposób opisany powyżej w przypadku tych elementów:

  • Uprawnienia specjalne

    • Ułatwienia dostępu (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
    • Odbiornik powiadomień (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
    • Aplikacje administratora urządzenia (Manifest.permission.BIND_DEVICE_ADMIN)
    • Wyświetlanie nad innymi aplikacjami (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
    • Dostęp do danych o korzystaniu (AppOpsManager.OPSTR_GET_USAGE_STATS)

  • Role (aplikacje domyślne)

    • Dialer (RoleManager.ROLE_DIALER)
    • SMS (RoleManager.ROLE_SMS)

  • Uprawnienia czasu działania

    • Czas działania SMS-a (Manifest.permission_group.SMS)

• [9.8/H-0-2] MUSI włączyć ustawienia ograniczone jako domyślne i ZDECYDOWANIE ZALECA SIĘ, aby nie udostępniać użytkownikowi żadnych funkcji, które pozwalają mu wyłączyć ustawienia ograniczone dla wszystkich aplikacji.

• [9.8/H-0-3] MUSI zapewnić uzyskanie potwierdzenia użytkownika w przypadku każdej objętej aplikacji, zanim zostaną przyznane jakiekolwiek wymuszone uprawnienia.

• [9.8/H-0-4] MUSI zezwalać na uzyskanie potwierdzenia użytkownika w celu włączenia ustawień ograniczonych tylko na stronie AppInfo aplikacji objętej ochroną, za pomocą interfejsu EnhancedConfirmationManager API.

• [9.8/H-0-5] Zdecydowanie zalecamy integrację z usługą EnhancedConfirmationManager i wywoływanie jej w przypadku wszystkich uprawnień specjalnych, aby dynamicznie określać, czy są one ustawieniem ograniczonym.

  • Alarmy i przypomnienia: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • Dostęp do wszystkich plików: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
  • Wyświetlanie nad innymi aplikacjami: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
  • Instalowanie nieznanych aplikacji: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
  • Zarządzaj mediami: AppOpsManager.OPSTR_MANAGE_MEDIA
  • Modyfikowanie ustawień systemu: AppOpsManager.OPSTR_WRITE_SETTINGS
  • Obraz w obrazie: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
  • Włączanie ekranu: AppOpsManager.OPSTR_TURN_SCREEN_ON
  • Powiadomienia pełnoekranowe: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
  • Sterowanie Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
  • Ułatwienia dostępu: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
  • Odbiornik powiadomień: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
  • Dostęp do danych o korzystaniu: AppOpsManager.OPSTR_GET_USAGE_STATS
  • Administrator urządzenia: Manifest.permission.BIND_DEVICE_ADMIN
  • Nie przeszkadzać: Manifest.permission.MANAGE_NOTIFICATIONS

Android za pomocą interfejsu System API VoiceInteractionService obsługuje mechanizm bezpiecznego, ciągłego wykrywania słów kluczowych bez wskazywania dostępu do mikrofonu oraz ciągłego wykrywania zapytań bez wskazywania dostępu do mikrofonu lub aparatu.

Jeśli implementacje urządzeń przenośnych obsługują interfejs System API HotwordDetectionService lub inny mechanizm wykrywania słów kluczowych bez wskazywania dostępu do mikrofonu:

• [9.8/H-1-1] MUSI dopilnować, aby usługa wykrywania słowa aktywującego mogła przesyłać dane tylko do systemu ContentCaptureService lub usługi rozpoznawania mowy na urządzeniu utworzonej przez SpeechRecognizer#createOnDeviceSpeechRecognizer().

• [9.8/H-1-2] MUSI dopilnować, aby usługa wykrywania słowa aktywacyjnego mogła przesyłać dane audio z mikrofonu lub dane z nich pochodne do serwera systemu tylko za pomocą interfejsu HotwordDetectionService API lub do ContentCaptureService za pomocą interfejsu ContentCaptureManager API.

• [9.8/H-1-3] NIE WOLNO przesyłać dźwięku z mikrofonu dłuższego niż 30 sekund w przypadku pojedynczego żądania wywołanego sprzętowo do usługi wykrywania słów kluczowych.

• [9.8/H-1-4] NIE MOŻE dostarczać do usługi wykrywania słów kluczowych buforowanego dźwięku z mikrofonu starszego niż 8 sekund w przypadku pojedynczego żądania.

• [9.8/H-1-5] NIE WOLNO dostarczać do usługi interakcji głosowej ani podobnego podmiotu buforowanego dźwięku z mikrofonu starszego niż 30 sekund.

• [9.8/H-1-6] NIE MOŻE zezwalać na przesyłanie z usługi wykrywania słów kluczowych więcej niż 100 bajtów danych (z wyłączeniem strumieni audio) w przypadku każdego pomyślnego wyniku wykrycia słowa kluczowego.

• [9.8/H-1-7] NIE MOŻE zezwalać na przesyłanie z usługi wykrywania słów kluczowych więcej niż 5 bitów danych w przypadku każdego negatywnego wyniku wykrywania słowa kluczowego.

• [9.8/H-1-8] MUSI zezwalać na przesyłanie danych z usługi wykrywania słów kluczowych tylko w przypadku żądania weryfikacji słowa kluczowego z serwera systemowego.

• [9.8/H-1-9] NIE WOLNO zezwalać na udostępnianie usługi wykrywania słów aktywujących przez aplikację, którą można zainstalować.

• [9.8/H-1-10] NIE MOŻE wyświetlać w interfejsie danych ilościowych dotyczących używania mikrofonu przez usługę wykrywania słów aktywujących.

• [9.8/H-1-11] MUSI rejestrować liczbę bajtów zawartych w każdej transmisji z usługi wykrywania słów kluczowych, aby umożliwić badaczom ds. bezpieczeństwa sprawdzanie tych danych.

• [9.8/H-1-12] MUSI obsługiwać tryb debugowania, który rejestruje surowe treści każdej transmisji z usługi wykrywania słów kluczowych, aby umożliwić badaczom ds. bezpieczeństwa wgląd w te treści.

• [9.8/H-1-14] MUSI wyświetlać wskaźnik mikrofonu zgodnie z opisem w sekcji 9.8.2, gdy do usługi interakcji głosowej lub podobnego podmiotu zostanie przesłany prawidłowy wynik słowa aktywującego.

• [9.8/H-1-15] MUSI zapewnić, że strumienie audio dostarczane w przypadku udanego wykrycia słowa kluczowego są przesyłane w jednym kierunku z usługi wykrywania słów kluczowych do usługi interakcji głosowej.

• [9.8/H-SR-1] Zdecydowanie zalecamy powiadamianie użytkowników przed ustawieniem aplikacji jako dostawcy usługi wykrywania słów kluczowych.

• [9.8/H-SR-2] Zdecydowanie zaleca się zablokowanie przesyłania nieuporządkowanych danych z usługi wykrywania słów aktywujących.

• [9.8/H-SR-3] Zdecydowanie zaleca się ponowne uruchamianie procesu hostującego usługę wykrywania słowa aktywującego co najmniej raz na godzinę lub co 30 zdarzeń wywołanych sprzętowo, w zależności od tego, co nastąpi wcześniej.

Jeśli implementacje urządzeń obejmują aplikację, która korzysta z interfejsu System APIHotwordDetectionService lub podobnego mechanizmu wykrywania słów kluczowych bez wskazywania użycia mikrofonu, aplikacja:

• [9.8/H-2-1] MUSI wyświetlać użytkownikowi wyraźne powiadomienie o każdej obsługiwanej frazie aktywującej.

• [9.8/H-2-2] NIE WOLNO zachowywać nieprzetworzonych danych audio ani danych z nich pochodzących w ramach usługi wykrywania słowa aktywacyjnego.

• [9.8/H-2-3] NIE WOLNO przesyłać z usługi wykrywania słów aktywujących danych audio, danych, które mogą być użyte do odtworzenia (w całości lub częściowo) dźwięku, ani treści audio niezwiązanych z samym słowem aktywującym, z wyjątkiem ContentCaptureService lub usługi rozpoznawania mowy na urządzeniu.

Jeśli implementacje urządzeń przenośnych obsługują interfejs System APIVisualQueryDetectionService lub inny mechanizm wykrywania zapytań bez wskazywania dostępu do mikrofonu lub kamery:

• [9.8/H-3-1] MUSI zapewnić, że usługa wykrywania zapytań może przesyłać dane tylko do Systemu lub ContentCaptureService lub do usługi rozpoznawania mowy na urządzeniu (utworzonej przez SpeechRecognizer#createOnDeviceSpeechRecognizer()).

• [9.8/H-3-2] NIE MOŻE zezwalać na przesyłanie informacji audio lub wideo poza VisualQueryDetectionService, z wyjątkiem przesyłania do ContentCaptureService lub usługi rozpoznawania mowy na urządzeniu.

• [9.8/H-3-3] MUSI wyświetlać powiadomienie dla użytkownika w interfejsie systemu, gdy urządzenie wykryje zamiar użytkownika, aby skorzystać z aplikacji Asystenta cyfrowego (np.wykrywając obecność użytkownika za pomocą kamery).

• [9.8/H-3-4] MUSI wyświetlać wskaźnik mikrofonu i wykryte zapytanie użytkownika w interfejsie bezpośrednio po wykryciu zapytania.

• [9.8/H-3-5] NIE MOŻE zezwalać na udostępnianie usługi wykrywania zapytań wizualnych przez aplikację, którą można zainstalować.

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

• [9.8.2/H-4-1] MUSI wyświetlać wskaźnik mikrofonu, gdy aplikacja uzyskuje dostęp do danych audio z mikrofonu, ale nie wtedy, gdy mikrofon jest używany tylko przez HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje pełniące role wymienione w sekcji 9.1 z identyfikatorem CDD [C-4-X].

• [9.8.2/H-4-2] MUSI wyświetlać listę ostatnich i aktywnych aplikacji korzystających z mikrofonu zwróconą przez PermissionManager.getIndicatorAppOpUsageData() wraz z powiązanymi z nimi komunikatami o atrybucji.

• [9.8.2/H-4-3] NIE MOŻE ukrywać wskaźnika mikrofonu w przypadku aplikacji systemowych, które mają widoczny interfejs użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.

• [9.8.2/H-4-4] MUSI wyświetlać listę ostatnich i aktywnych aplikacji korzystających z mikrofonu, zwróconą przez PermissionManager.getIndicatorAppOpUsageData(), wraz z powiązanymi z nimi komunikatami o atrybucji.

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

• [9.8.2/H-5-1] MUSI wyświetlać wskaźnik aparatu, gdy aplikacja uzyskuje dostęp do danych z aparatu na żywo, ale nie wtedy, gdy aparat jest używany tylko przez aplikacje pełniące role wymienione w sekcji 9.1 z identyfikatorem CDD [C-4-X].

• [9.8.2/H-5-2] MUSZĄ wyświetlać ostatnio używane i aktywne aplikacje korzystające z aparatu, które zostały zwrócone przez PermissionManager.getIndicatorAppOpUsageData(), oraz powiązane z nimi komunikaty o atrybucji.

• [9.8.2/H-5-3] NIE MOŻE ukrywać wskaźnika aparatu w przypadku aplikacji systemowych, które mają widoczny interfejs użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.

Weryfikacja podczas uruchamiania to funkcja, która zapewnia integralność oprogramowania urządzenia. Jeśli implementacje urządzeń obsługują tę funkcję:

• [9.10/H-1-1] MUSI weryfikować wszystkie partycje tylko do odczytu zamontowane podczas sekwencji uruchamiania Androida, a wartość skrótu VBMeta MUSI uwzględniać w obliczeniach wszystkie te zweryfikowane partycje.

2.2.6. Zgodność narzędzi i opcji dla programistów

Implementacje urządzeń przenośnych (* nie dotyczy tabletów):

• [6.1/H-0-1]* MUSI obsługiwać polecenie powłoki cmd testharness.

Implementacje urządzeń przenośnych:

• Perfetto

  • [6.1/H-0-2] MUSI udostępniać użytkownikowi powłoki /system/bin/perfetto plik binarny, którego wiersz poleceń jest zgodny z dokumentacją narzędzia Perfetto.

  • [6.1/H-0-3] Plik binarny Perfetto MUSI akceptować jako dane wejściowe konfigurację bufora protokołu zgodną ze schematem zdefiniowanym w dokumentacji Perfetto.

  • [6.1/H-0-4] Plik binarny Perfetto MUSI zapisywać jako dane wyjściowe ślad bufora protokołu zgodny ze schematem zdefiniowanym w dokumentacji Perfetto.

  • [6.1/H-0-5] MUSI udostępniać za pomocą pliku binarnego perfetto co najmniej źródła danych opisane w dokumentacji perfetto.

  • [6.1/H-0-6] Śledzenie demona perfetto MUSI być domyślnie włączone (właściwość systemu persist.traced.enable).

2.2.7. Klasa wydajności urządzeń przenośnych

Definicję klasy skuteczności multimediów znajdziesz w sekcji 7.11, a definicję klasy skuteczności multimediów dla wszystkich pomiarów – w tym dokumencie.

2.2.7.1. Multimedia

Jeśli implementacje urządzeń przenośnych zwracają wartość inną niż zero w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• MUSI spełniać wszystkie wymagania dotyczące multimediów wymienione w sekcji 2.2.7.1 dokumentu CDD dla Androida 17, które odpowiadają zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

• [5.1/H-1-1] MUSI reklamować maksymalną liczbę sesji dekodera wideo sprzętowego, które mogą być uruchamiane jednocześnie w dowolnej kombinacji kodeków, za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints() odpowiadających zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-2] MUSI obsługiwać sesje sprzętowego dekodera wideo (AVC, HEVC, VP9, AV1 lub nowsze), równoczesne instancje i spadki liczby klatek odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-3] MUSI reklamować 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() odpowiadających zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-4] MUSI obsługiwać sesje sprzętowego kodera wideo (AVC, HEVC, VP9, AV1 lub nowsze), równoczesne instancje i utratę klatek odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-5] MUSI reklamować maksymalną liczbę równoczesnych sesji sprzętowego kodowania i dekodowania wideo w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints() odpowiadających zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-6] MUSI obsługiwać sesje sprzętowego dekodera i enkodera wideo (AVC, HEVC, VP9, AV1 lub nowsze), równoczesne instancje i utratę klatek odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-7] MUSI mieć opóźnienie inicjowania kodeka w przypadku sesji kodowania wideo w rozdzielczości 1080p lub mniejszej dla wszystkich sprzętowych koderów wideo przy obciążeniu odpowiadającym zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-8] MUSI mieć opóźnienie inicjowania kodeka w przypadku sesji kodowania dźwięku o szybkości transmisji 128 kb/s lub mniejszej dla wszystkich koderów audio pod obciążeniem odpowiadającym zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-9] MUSI obsługiwać 2 sesje bezpiecznego dekodera sprzętowego wideo (AVC, HEVC, VP9, AV1 lub nowsze) i pomijać klatki zgodnie z deklarowanym poziomem klasy wydajności multimediów urządzenia.

• [5.1/H-1-10] MUSI obsługiwać 3 sesje niezabezpieczonego sprzętowego dekodera wideo oraz 1 sesję zabezpieczonego sprzętowego dekodera wideo (łącznie 4 sesje) (AVC, HEVC, VP9, AV1 lub nowsze), rozdzielczości i spadki liczby klatek odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-11] MUSI obsługiwać bezpieczny dekoder dla każdego dekodera sprzętowego AVC, HEVC, VP9 lub AV1 odpowiadającego zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-12] MUSI mieć opóźnienie inicjowania kodeka w przypadku sesji dekodowania wideo w rozdzielczości 1080p lub niższej dla wszystkich dekoderów wideo sprzętowych przy obciążeniu odpowiadającym zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-13] MUSI mieć opóźnienie inicjowania kodeka w przypadku sesji dekodowania dźwięku o szybkości transmisji 128 kb/s lub mniejszej dla wszystkich dekoderów audio pod obciążeniem odpowiadającym zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-14] MUSI obsługiwać profil, funkcję i metodę wyświetlania dekodera sprzętowego AV1 odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-15] MUSI mieć co najmniej 1 dekoder wideo obsługujący 4K60, który odpowiada zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-16] MUSI mieć co najmniej 1 sprzętowy enkoder wideo obsługujący rozdzielczość 4K60, co odpowiada zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-17] MUSI mieć co najmniej 1 dekoder obrazów sprzętowych obsługujący profil podstawowy AVIF odpowiadający zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-18] MUSI obsługiwać koder AV1, który spełnia wymagania dotyczące szybkości transmisji, liczby klatek na sekundę i rozdzielczości odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-19] MUSI obsługiwać 3 sesje 10-bitowego (HDR) sprzętowego dekodera wideo i sprzętowego kodera wideo (AVC, HEVC, VP9, AV1 lub nowsze), rozdzielczość i spadki liczby klatek odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-20] MUSI obsługiwać funkcję Feature_HdrEditing w przypadku wszystkich sprzętowych koderów AV1 i HEVC na urządzeniu zgodnie z deklarowanym przez urządzenie poziomem klasy wydajności multimediów.

• [5.1/H-1-21] MUSI obsługiwać FEATURE_DynamicColorAspect w przypadku wszystkich dekoderów sprzętowych (AVC, HEVC, VP9, AV1 lub nowszych) odpowiadających zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

• [5.1/H-1-22] MUSI obsługiwać kodowanie, dekodowanie, edytowanie na GPU i wyświetlanie treści wideo w formacie pionowym odpowiadającym zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.2/H-2-1] Jeśli implementacja urządzenia obsługuje sprzętowe kodery AVC lub HEVC, MUSI spełniać minimalny cel jakości określony przez krzywe zniekształceń szybkości kodera wideo dla tych kodeków, odpowiadający zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

• [5.3/H-1-1] MUSI spełniać wymagania dotyczące wydajności sesji wideo i liczby utraconych klatek odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.3/H-1-2] MUSI spełniać wymagania dotyczące zmiany rozdzielczości wideo odpowiadające zadeklarowanej klasie wydajności multimediów urządzenia.

• [5.6/H-1-1] MUSI spełniać wymagania dotyczące opóźnienia od dotknięcia do dźwięku odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.6/H-1-2] MUSI spełniać wymagania dotyczące opóźnienia dźwięku w obie strony odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.6/H-1-3] MUSI spełniać wymagania dotyczące 24-bitowego dźwięku odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.6/H-1-4] MUSI obsługiwać urządzenia audio USB z co najmniej 4 kanałami, które odpowiadają zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.6/H-1-5] MUSI obsługiwać urządzenia MIDI zgodne z klasą i deklarować flagę funkcji MIDI odpowiadającą zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.6/H-1-9] MUSI obsługiwać mieszanie co najmniej 12 kanałów odpowiadające zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

• [5.6/H-SR-1] Zdecydowanie zaleca się obsługę miksowania kanałów audio odpowiadającego zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.7/H-1-2] MUSI obsługiwać MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL z możliwościami odszyfrowywania odpowiadającymi zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

• [5.12/H-1-2] MUSI spełniać wymagania dotyczące formatu kolorów w przypadku sprzętowych koderów AV1 i HEVC odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.12/H-1-3] MUSI reklamować obsługę rozszerzenia EXT_YUV_target odpowiadającego zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

• [7.1.4/H-1-1] MUSI spełniać wymagania dotyczące jednostki przetwarzania wyświetlania (DPU) odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

2.2.7.2. Aparat

Jeśli implementacje urządzeń przenośnych zwracają wartość inną niż zero w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• MUSI spełniać wymagania dotyczące aparatu wymienione w sekcji 2.2.7.2 dokumentu CDD dla Androida 17, które odpowiadają zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

Jeśli implementacje urządzeń przenośnych zwracają wartość inną niż zero w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• [7.5/H-1-1] MUSI spełniać wymagania dotyczące rozdzielczości głównego aparatu skierowanego do tyłu i nagrywania wideo odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-2] MUSI spełniać wymagania dotyczące rozdzielczości głównego aparatu przedniego i nagrywania wideo odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-3] MUSI obsługiwać android.info.supportedHardwareLevel wymagania dotyczące właściwości odpowiadające zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

• [7.5/H-1-4] MUSI obsługiwaćCameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME w przypadku obu głównych aparatów odpowiadających zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-5] MUSI spełniać wymagania dotyczące opóźnienia przechwytywania obrazu JPEG przez interfejs camera2 odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-6] MUSI spełniać wymagania dotyczące opóźnienia uruchamiania camera2 odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-8] MUSI spełniać wymagania dotyczące rejestrowania obrazu z kamery RAW odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-9] MUSI spełniać wymagania dotyczące nagrywania filmów w szybkim tempie przez tylny aparat główny, które odpowiadają zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-10] MUSI spełniać minimalne wymagania dotyczące współczynnika powiększenia odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-11] MUSI implementować jednoczesne przesyłanie strumieniowe z przedniego i tylnego aparatu głównego, które odpowiada zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-12] MUSI obsługiwać stabilizację obrazu w przypadku głównego tylnego aparatu odpowiadającego zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-13] MUSI obsługiwać LOGICAL_MULTI_CAMERAmożliwość w przypadku głównego aparatu z tyłu, odpowiadającą zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

• [7.5/H-1-14] MUSI obsługiwać funkcję STREAM_USE_CASE w przypadku głównego aparatu przedniego i głównego aparatu tylnego, zgodnie z deklarowanym poziomem klasy wydajności multimediów urządzenia.

• [7.5/H-1-15] MUSI obsługiwać rozszerzenia trybu nocnego za pomocą rozszerzeń CameraX i Camera2 w przypadku aparatów głównych odpowiadających zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-16] MUSI obsługiwać funkcję DYNAMIC_RANGE_TEN_BIT w przypadku głównych aparatów odpowiadających zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-17] MUSI obsługiwać funkcje wykrywania twarzy w przypadku kamer głównych odpowiadających zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-18] MUSI obsługiwać JPEG_R w przypadku głównego tylnego i głównego przedniego aparatu odpowiadającego zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.5/H-1-19] MUSI obsługiwać CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION w przypadku głównego tylnego aparatu odpowiadającego zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

• [7.5/H-1-20] MUSI domyślnie zwracać wartość JPEG_R dla głównego aparatu tylnego i głównego aparatu przedniego w natywnej aplikacji aparatu odpowiadającej zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

2.2.7.3. Sprzęt

Jeśli implementacje urządzeń przenośnych zwracają wartość inną niż zero w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• MUSI spełniać wymagania sprzętowe wymienione w sekcji 2.2.7.3, które odpowiadają zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

Jeśli implementacje urządzeń przenośnych zwracają wartość inną niż zero w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• [7.1.1.1/H-1-1] Ten element został celowo pominięty.

• [7.1.1.1/H-2-1] MUSI mieć rozdzielczość ekranu odpowiadającą zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.1.1.3/H-1-1] Ten element został celowo pominięty.

• [7.1.1.3/H-2-1] MUSI mieć gęstość ekranu odpowiadającą zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.1.1.3/H-3-1] MUSI obsługiwać wymagania dotyczące wyświetlacza HDR odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.6.1/H-1-1] Ten element został celowo pominięty.

• [7.6.1/H-2-1] MUSI spełniać wymagania dotyczące pamięci odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

2.2.7.4. Wydajność

Jeśli implementacje urządzeń przenośnych zwracają wartość inną niż zero w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• MUSI spełniać wymagania dotyczące wydajności wymienione w sekcji 2.2.7.4 dokumentu CDD dla Androida 17 odpowiadające zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

Jeśli implementacje urządzeń przenośnych zwracają wartość inną niż zero w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• [8.2/H-1-1] MUSI zapewniać wydajność zapisu sekwencyjnego odpowiadającą zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [8.2/H-1-2] MUSI zapewniać wydajność losowego zapisu odpowiadającą zadeklarowanemu poziomowi klasy wydajności nośnika urządzenia.

• [8.2/H-1-3] MUSI zapewniać wydajność odczytu sekwencyjnego odpowiadającą zadeklarowanej klasie wydajności nośnika urządzenia.

• [8.2/H-1-4] MUSI zapewniać wydajność odczytu losowego odpowiadającą zadeklarowanej klasie wydajności nośnika urządzenia.

• [8.2/H-1-5] MUSI zapewniać wydajność równoległego sekwencyjnego odczytu i zapisu odpowiadającą zadeklarowanemu poziomowi klasy wydajności nośnika urządzenia.

2.2.7.5. Grafika

Jeśli implementacje urządzeń przenośnych zwracają wartość inną niż zero w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS:

• [7.1.4.1/H-1-2] MUSI obsługiwać wymagane rozszerzenia EGL odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [7.1.4.1/H-1-3] MUSI obsługiwać wymagane funkcje interfejsu Vulkan odpowiadające zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

2.3. Wymagania dotyczące telewizora

Urządzenie Android TV to implementacja urządzenia z Androidem, która jest interfejsem rozrywkowym do korzystania z mediów cyfrowych, filmów, gier, aplikacji lub telewizji na żywo przez użytkowników siedzących w odległości około 3 metrów (interfejs „lean back” lub „interfejs użytkownika z odległości 3 metrów”).

Implementacje urządzeń z Androidem są klasyfikowane jako telewizory, jeśli spełniają wszystkie te kryteria:

• zapewnia mechanizm zdalnego sterowania renderowanym interfejsem użytkownika na wyświetlaczu, który może znajdować się w odległości 3 metrów od użytkownika;
• Musi mieć wbudowany wyświetlacz o przekątnej większej niż 24 cale LUB port wyjścia wideo, taki jak VGA, HDMI, DisplayPort lub port bezprzewodowy do wyświetlania.

Dodatkowe wymagania w pozostałej części tej sekcji dotyczą implementacji urządzeń z Androidem TV.

2.3.1. Sprzęt

Implementacje urządzeń telewizyjnych:

• [7.2.2/T-0-1] MUSI obsługiwać pad kierunkowy.
• [7.2.3/T-0-1] MUSI udostępniać funkcje Wstecz i Strona główna.
• [7.2.3/T-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno normalne, jak i długie naciśnięcie funkcji Wstecz (KEYCODE_BACK).
• [7.2.6.1/T-0-1] MUSI obsługiwać kontrolery do gier i deklarować flagę funkcji android.hardware.gamepad.
• [7.2.7/T] POWINIEN udostępniać pilota, za pomocą którego użytkownicy mogą korzystać z nawigacji bezdotykowej i podstawowych klawiszy nawigacyjnych.

Jeśli implementacje urządzeń telewizyjnych zawierają 3-osiowy żyroskop:

• [7.3.4/T-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 100 Hz.
• [7.3.4/T-1-2] MUSI być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.

Implementacje urządzeń telewizyjnych:

• [7.4.3/T-0-1] MUSI obsługiwać Bluetooth i Bluetooth LE.
• [7.6.1/T-0-1] MUSI mieć co najmniej 4 GB pamięci trwałej dostępnej na prywatne dane aplikacji (czyli partycję „/data”).

Jeśli urządzenia telewizyjne mają port USB obsługujący tryb hosta:

• [7.5.3/T-1-1] MUSI obsługiwać kamerę zewnętrzną, która łączy się przez ten port USB, ale nie musi być zawsze podłączona.

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

• [7.6.1/T-1-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 896 MB, jeśli używana jest którakolwiek z tych gęstości:

  • co najmniej 400 dpi na małych i normalnych ekranach,
  • xhdpi lub wyższa na dużych ekranach,
  • tvdpi lub wyższa na bardzo dużych ekranach,

Jeśli implementacje urządzeń z systemem TV są 64-bitowe:

• [7.6.1/T-2-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 1280 MB, jeśli używana jest którakolwiek z tych gęstości:

  • co najmniej 400 dpi na małych i normalnych ekranach,
  • xhdpi lub wyższa na dużych ekranach,
  • tvdpi lub wyższa na bardzo dużych ekranach,

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do przestrzeni pamięci udostępnianej oprócz pamięci już przypisanej do komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro na urządzeniach.

Implementacje urządzeń telewizyjnych:

• [7.8.1/T] POWINIEN zawierać mikrofon.
• [7.8.2/T-0-1] MUSI mieć wyjście audio i deklarować android.hardware.audio.output.

2.3.2. Multimedia

Implementacje urządzeń telewizyjnych MUSZĄ obsługiwać te formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:

• [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/T-0-3] AAC ELD (enhanced low delay AAC)

Urządzenia telewizyjne MUSZĄ obsługiwać te formaty kodowania wideo i udostępniać je aplikacjom innych firm:

• [5.2/T-0-1] H.264
• [5.2/T-0-2] VP8
• [5.2/T-0-3] AV1

Implementacje urządzeń telewizyjnych:

• [5.2.2/T-SR-1] ZDECYDOWANIE ZALECA SIĘ obsługę kodowania H.264 filmów o rozdzielczości 720p i 1080p przy 30 klatkach na sekundę.

Urządzenia telewizyjne MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2
• [5.3.2/T-0-7] AV1

Urządzenia telewizyjne MUSZĄ obsługiwać dekodowanie MPEG-2 zgodnie z opisem w sekcji 5.3.1 przy standardowych szybkościach klatek i rozdzielczościach wideo do:

• [5.3.1/T-1-1] HD 1080p przy 29,97 klatkach na sekundę z profilem głównym na wysokim poziomie.
• [5.3.1/T-1-2] HD 1080i przy 59,94 klatkach na sekundę z profilem głównym wysokiego poziomu. MUSI usuwać przeplot z przeplatanych filmów MPEG-2 i udostępniać je aplikacjom innych firm.

Urządzenia telewizyjne MUSZĄ obsługiwać dekodowanie H.264 zgodnie z opisem w sekcji 5.3.4 przy standardowych liczbach klatek i rozdzielczościach do:

• [5.3.4/T-1-1] HD 1080p przy 60 kl./s z profilem podstawowym
• [5.3.4/T-1-2] HD 1080p przy 60 kl./s z profilem głównym
• [5.3.4/T-1-3] HD 1080p przy 60 kl./s z profilem High Profile Level 4.2

Urządzenia telewizyjne z dekoderami sprzętowymi H.265 MUSZĄ obsługiwać dekodowanie H.265 zgodnie z opisem w sekcji 5.3.5 przy standardowych częstotliwościach klatek wideo i rozdzielczościach do:

• [5.3.5/T-1-1] HD 1080p przy 60 kl./s z profilem głównym poziomu 4.1

Jeśli implementacje urządzeń telewizyjnych z dekoderami sprzętowymi H.265 obsługują dekodowanie H.265 i profil dekodowania UHD, to:

• [5.3.5/T-2-1] MUSI obsługiwać profil dekodowania UHD przy 60 klatkach na sekundę z profilem Main10 Level 5 Main Tier.

Urządzenia telewizyjne MUSZĄ obsługiwać dekodowanie VP8 zgodnie z opisem w sekcji 5.3.6 przy standardowych liczbach klatek i rozdzielczościach do:

• [5.3.6/T-1-1] Profil dekodowania HD 1080p przy 60 kl./s

Implementacje urządzeń telewizyjnych z dekoderami sprzętowymi VP9 MUSZĄ obsługiwać dekodowanie VP9, zgodnie z opisem w sekcji 5.3.7, przy standardowych częstotliwościach klatek i rozdzielczościach wideo do:

• [5.3.7/T-1-1] HD 1080p przy 60 klatkach na sekundę z profilem 0 (8-bitowa głębia kolorów)

Jeśli implementacje urządzeń telewizyjnych z dekoderami sprzętowymi VP9 obsługują dekodowanie VP9 i profil dekodowania UHD, to:

• [5.3.7/T-2-1] MUSI obsługiwać profil dekodowania UHD przy 60 klatkach na sekundę z profilem 0 (8-bitowa głębia kolorów).
• [5.3.7/T-SR1] ZDECYDOWANIE ZALECA SIĘ obsługę profilu dekodowania UHD przy 60 klatkach na sekundę z profilem 2 (10-bitowa głębia kolorów).

Implementacje urządzeń telewizyjnych:

• [5.5/T-0-1] MUSI obsługiwać głośność główną systemu i tłumienie głośności cyfrowego wyjścia audio na obsługiwanych wyjściach, z wyjątkiem wyjścia przekazywania skompresowanego dźwięku (gdzie urządzenie nie dekoduje dźwięku).

Jeśli urządzenia telewizyjne nie mają wbudowanego wyświetlacza, ale obsługują wyświetlacz zewnętrzny podłączony przez HDMI:

• [5.8/T-0-1] MUSI ustawić tryb wyjścia HDMI na najwyższą rozdzielczość dla wybranego formatu pikseli, która działa z częstotliwością odświeżania 50 Hz lub 60 Hz w przypadku wyświetlacza zewnętrznego, w zależności od częstotliwości odświeżania wideo w regionie, w którym urządzenie jest sprzedawane.
• [5.8/T-SR-1] ZDECYDOWANIE ZALECA się udostępnienie użytkownikowi selektora częstotliwości odświeżania HDMI, który można skonfigurować.
• [5.8] POWINNO ustawić częstotliwość odświeżania trybu wyjścia HDMI na 50 Hz lub 60 Hz w zależności od częstotliwości odświeżania wideo w regionie, w którym urządzenie jest sprzedawane.

Jeśli urządzenia telewizyjne nie mają wbudowanego wyświetlacza, ale obsługują wyświetlacz zewnętrzny podłączony przez HDMI:

• [5.8/T-1-1] MUSI obsługiwać HDCP 2.2.

Jeśli implementacje urządzeń telewizyjnych nie obsługują dekodowania UHD, ale obsługują zewnętrzny wyświetlacz podłączony przez HDMI:

• [5.8/T-2-1] MUSI obsługiwać HDCP 1.4

2.3.3. Oprogramowanie

Implementacje urządzeń telewizyjnych:

• [3/T-0-1] MUSI deklarować funkcje android.software.leanback i android.hardware.type.television.
• [3.2.3.1/T-0-1] MUSI wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi z procedurą obsługi intencji dla wszystkich publicznych wzorców filtrów intencji zdefiniowanych przez intencje aplikacji wymienione tutaj.
• [3.4.1/T-0-1] MUSI udostępniać pełną implementację interfejsu API android.webkit.Webview.

Jeśli implementacje urządzeń z Androidem TV obsługują ekran blokady:

• [3.8.10/T-1-1] MUSI wyświetlać powiadomienia na ekranie blokady, w tym szablon powiadomienia o multimediach.

Implementacje urządzeń telewizyjnych:

• [3.8.14/T-SR-1] Zdecydowanie zalecane jest obsługiwanie trybu wielu okien w formacie obraz w obrazie.
• [3.10/T-0-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.
• [3.10/T-SR-1] Zdecydowanie zaleca się wstępne wczytywanie na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z usługami Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) lub większej niż te usługi, zgodnie z projektem TalkBack Open Source.

Jeśli implementacje urządzeń telewizyjnych zgłaszają tę funkcjęandroid.hardware.audio.output:

• [3.11/T-SR-1] Zdecydowanie zaleca się, aby zawierały silnik TTS obsługujący języki dostępne na urządzeniu.
• [3.11/T-1-1] MUSI obsługiwać instalację silników TTS innych firm.

Platforma wejścia Android Television (TIF) upraszcza dostarczanie treści na żywo na urządzenia z Androidem TV. TIF udostępnia standardowy interfejs API do tworzenia modułów wejściowych, które sterują urządzeniami z Androidem TV.

Implementacje urządzeń telewizyjnych:

• [3/T-0-2] MUSI deklarować funkcję platformy android.software.live_tv.
• [3/T-0-3] MUSI obsługiwać wszystkie interfejsy TIF API, aby aplikacja korzystająca z tych interfejsów i usługi wejściowe oparte na TIF innych firm mogła być zainstalowana i używana na urządzeniu.

Android Television Tuner Framework (TF) ujednolica obsługę treści na żywo z tunera z treściami przesyłanymi strumieniowo z IP na urządzeniach z Androidem TV. Platforma Tuner Framework udostępnia standardowy interfejs API do tworzenia usług wejściowych, które korzystają z tunera telewizyjnego Androida.

Jeśli implementacje urządzeń obsługują tuner:

• [3/T-1-1] MUSI obsługiwać wszystkie interfejsy Tuner Framework API, aby aplikacja, która ich używa, mogła być zainstalowana i używana na urządzeniu.

2.3.4. Wydajność i moc

• [8.1/T-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie klatek lub opóźnienie renderowania klatek NIE MOŻE występować częściej niż 5 klatek na sekundę i POWINNO być mniejsze niż 1 klatka na sekundę.
• [8.2/T-0-1] MUSI zapewniać wydajność zapisu sekwencyjnego na poziomie co najmniej 5 MB/s.
• [8.2/T-0-2] MUSI zapewniać wydajność losowego zapisu na poziomie co najmniej 0,5 MB/s.
• [8.2/T-0-3] MUSI zapewniać wydajność odczytu sekwencyjnego na poziomie co najmniej 15 MB/s.
• [8.2/T-0-4] MUSI zapewniać wydajność losowego odczytu na poziomie co najmniej 3,5 MB/s.

Jeśli implementacje urządzeń telewizyjnych zawierają funkcje poprawiające zarządzanie energią urządzenia, które są uwzględnione w AOSP lub rozszerzają funkcje uwzględnione w AOSP:

• [8.3/T-1-1] MUSI udostępniać użytkownikowi afordancję umożliwiającą włączanie i wyłączanie funkcji Oszczędzanie baterii.

Jeśli urządzenia telewizyjne nie mają baterii:

• [8.3/T-1-2] MUSI zarejestrować urządzenie jako urządzenie bez baterii zgodnie z opisem w sekcji Obsługa urządzeń bez baterii.

Jeśli urządzenia telewizyjne mają baterię:

• [8.3/T-1-3] MUSI udostępniać użytkownikowi możliwość wyświetlania wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii „Aplikacja w trybie gotowości” i „Drzemka”.

Implementacje urządzeń telewizyjnych:

• [8.4/T-0-1] MUSI udostępniać profil zasilania poszczególnych komponentów, który określa wartość zużycia prądu każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją na stronie Projektu Android Open Source.
• [8.4/T-0-2] MUSI podawać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
• [8.4/T-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/T] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji.
• [8.4/T-0-4] MUSI udostępniać te informacje o zużyciu energii za pomocą polecenia powłoki adb shell dumpsys batterystats deweloperowi aplikacji.

2.3.5. Model zabezpieczeń

Implementacje urządzeń telewizyjnych:

• [9/T-0-1] MUSI deklarować funkcję android.hardware.security.model.compatible.

Jeśli implementacje urządzeń telewizyjnych zawierają domyślną aplikację obsługującą VoiceInteractionService, to:

• [9.1/T-0-1] NIE MOŻE przyznawać ACCESS_FINE_LOCATION jako domyślnego uprawnienia w przypadku tej aplikacji.

Implementacje urządzeń telewizyjnych:

• [9.11/T-0-1] MUSI tworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/T-0-2] MUSI mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji skrótu MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać algorytmy obsługiwane przez system Android Keystore w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i wyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego środowiska izolowanego, w tym DMA. Wymaganie to jest spełniane w projekcie Android Open Source Project (AOSP) dzięki implementacji Trusty, ale alternatywnym rozwiązaniem może być inna implementacja oparta na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji opartej na hiperwizorze, która została zweryfikowana przez zewnętrzną firmę.
• [9.11/T-0-3] MUSI przeprowadzać uwierzytelnianie na ekranie blokady w izolowanym środowisku wykonawczym i tylko w przypadku powodzenia zezwalać na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób, który umożliwia uwierzytelnianie na ekranie blokady tylko w izolowanym środowisku wykonawczym. Projekt Android Open Source udostępnia warstwę abstrakcji sprzętowej (HAL) Gatekeeper i Trusty, które mogą być używane do spełnienia tego wymagania.

• [9.11/T-0-4] MUSI obsługiwać atestowanie kluczy, w przypadku którego klucz podpisu atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania zaświadczeń NIE MOGĄ być używane jako trwałe identyfikatory urządzenia.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na wcześniejszej wersji Androida, takie urządzenie jest zwolnione z wymogu posiadania magazynu kluczy opartego na izolowanym środowisku wykonawczym i obsługi atestowania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy opartego na izolowanym środowisku wykonawczym.

Jeśli urządzenia telewizyjne obsługują bezpieczny ekran blokady:

• [9.11/T-1-1] MUSI umożliwiać użytkownikowi wybór czasu oczekiwania na przejście w stan uśpienia z odblokowanego do zablokowanego, przy czym minimalny dopuszczalny czas oczekiwania wynosi maksymalnie 15 sekund.

Jeśli implementacje urządzeń telewizyjnych obsługują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, to:

• [9.5/T-2-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska, w których będą pracować dodatkowi użytkownicy. Mają też możliwość zarządzania bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli implementacje urządzeń telewizyjnych obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony, to:

• [9.5/T-3-1] NIE MOŻE obsługiwać profili z ograniczeniami, ale MUSI być zgodny z implementacją AOSP dotyczącą elementów sterujących, które umożliwiają włączanie i wyłączanie dostępu innych użytkowników do połączeń głosowych i SMS-ów.

Jeśli implementacje urządzeń telewizyjnych deklarują android.hardware.microphone, to:

• [9.8.2/T-4-1] MUSI wyświetlać wskaźnik mikrofonu, gdy aplikacja uzyskuje dostęp do danych audio z mikrofonu, ale nie wtedy, gdy mikrofon jest używany tylko przez HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje pełniące role wymienione w sekcji 9.1 Uprawnienia z identyfikatorem CDD C-3-X.
• [9.8.2/T-4-2] NIE MOŻE ukrywać wskaźnika mikrofonu w przypadku aplikacji systemowych, które mają widoczny interfejs użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.

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

• [9.8.2/T-5-1] MUSI wyświetlać wskaźnik aparatu, gdy aplikacja uzyskuje dostęp do danych z aparatu na żywo, ale nie wtedy, gdy aparat jest używany tylko przez aplikacje z rolami wymienionymi w sekcji 9.1 Uprawnienia z identyfikatorem CDD [C-3-X].
• [9.8.2/T-5-2] NIE MOŻE ukrywać wskaźnika aparatu w przypadku aplikacji systemowych, które mają widoczny interfejs użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.

2.3.6. Zgodność narzędzi i opcji dla programistów

Implementacje urządzeń telewizyjnych:

• Perfetto

  • [6.1/T-0-1] MUSI udostępniać użytkownikowi powłoki plik binarny, którego wiersz poleceń jest zgodny z /system/bin/perfetto dokumentacją narzędzia perfetto.
  • [6.1/T-0-2] Plik binarny narzędzia Perfetto MUSI akceptować jako dane wejściowe konfigurację bufora protokołu zgodną ze schematem zdefiniowanym w dokumentacji narzędzia Perfetto.
  • [6.1/T-0-3] Plik binarny Perfetto MUSI zapisywać jako dane wyjściowe ślad bufora protokołu zgodny ze schematem zdefiniowanym w dokumentacji Perfetto.
  • [6.1/T-0-4] MUSI udostępniać za pomocą pliku binarnego perfetto co najmniej źródła danych opisane w dokumentacji perfetto.
  • [6.1/T-0-5] Usługa śledzenia perfetto MUSI być domyślnie włączona (właściwość systemowa persist.traced.enable).

2.4. Wymagania dotyczące zegarka

Urządzenie z Androidem Watch to urządzenie z Androidem przeznaczone do noszenia na ciele, np. na nadgarstku.

Implementacje na urządzeniach z Androidem są klasyfikowane jako zegarki, jeśli spełniają wszystkie te kryteria:

• mieć ekran o przekątnej od 1,1 do 2,5 cala;
• musi mieć mechanizm umożliwiający noszenie na ciele;

Dodatkowe wymagania w pozostałej części tej sekcji dotyczą implementacji urządzeń z Androidem Watch.

2.4.1. Sprzęt

Implementacje urządzeń z systemem Wear OS:

• [7.1.1.1/W-0-1] MUSI mieć ekran o przekątnej fizycznej w zakresie od 1,1 do 2,5 cala.

• [7.2.3/W-0-1] MUSI udostępniać użytkownikowi funkcję Strona główna i funkcję Wstecz, z wyjątkiem sytuacji, gdy jest w stanie UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] MUSI obsługiwać wprowadzanie danych za pomocą ekranu dotykowego.

• [7.3.1/W-SR-1] Zdecydowanie zaleca się uwzględnienie 3-osiowego akcelerometru.

Jeśli implementacje urządzeń z Androidem Wear OS zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi android.hardware.location.gps, to:

• [7.3.3/W-1-1] MUSI raportować pomiary GNSS, gdy tylko zostaną wykryte, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
• [7.3.3/W-1-2] MUSI zgłaszać pseudoodległości i szybkości pseudoodległości GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 0,2 m/s², wystarczają do obliczenia pozycji z dokładnością do 20 metrów i prędkości z dokładnością do 0,2 m/s co najmniej w 95% przypadków.

Jeśli implementacje urządzeń z systemem Wear OS obejmują 3-osiowy żyroskop:

• [7.3.4/W-2-1] MUSI być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.

Implementacje urządzeń z systemem Wear OS:

• [7.4.3/W-0-1] MUSI obsługiwać Bluetooth.

• [7.6.1/W-0-1] MUSI mieć co najmniej 1 GB pamięci trwałej dostępnej na prywatne dane aplikacji (czyli partycję „/data”).

• [7.6.1/W-0-2] MUSI mieć co najmniej 416 MB pamięci dostępnej dla jądra i przestrzeni użytkownika.

• [7.8.1/W-0-1] MUSI zawierać mikrofon.

• [7.8.2/W] MOŻE mieć wyjście audio.

2.4.2. Multimedia

Brak dodatkowych wymagań.

2.4.3. Oprogramowanie

Implementacje urządzeń z systemem Wear OS:

• [3/W-0-1] MUSI deklarować funkcję android.hardware.type.watch.
• [3/W-0-2] MUSI obsługiwać uiMode = UI_MODE_TYPE_WATCH.
• [3.2.3.1/W-0-1] MUSI wstępnie wczytać co najmniej 1 aplikację lub komponent usługi z procedurą obsługi intencji dla wszystkich publicznych wzorców filtrów intencji zdefiniowanych przez intencje aplikacji wymienione tutaj.

Implementacje urządzeń z systemem Wear OS:

• [3.8.4/W-SR-1] Zdecydowanie zalecamy wdrożenie na urządzeniu asystenta, który będzie obsługiwać działanie Assist.

Obserwuj implementacje urządzeń, które deklarują android.hardware.audio.output flagę funkcji:

• [3.10/W-1-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.
• [3.10/W-SR-1] Zdecydowanie zaleca się wstępne wczytywanie usług ułatwień dostępu na urządzeniu o funkcjonalności porównywalnej z usługami Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany silnik przetwarzania tekstu na mowę) lub większej niż one, zgodnie z projektem open source TalkBack.

Jeśli implementacje urządzeń z zegarkiem zgłaszają funkcję android.hardware.audio.output, to:

• [3.11/W-SR-1] Zdecydowanie zaleca się, aby zawierały silnik TTS obsługujący języki dostępne na urządzeniu.

• [3.11/W-0-1] MUSI obsługiwać instalację silników TTS innych firm.

2.4.4. Wydajność i moc

Jeśli implementacje urządzeń z Wear OS zawierają funkcje poprawiające zarządzanie energią urządzenia, które są dostępne w AOSP lub rozszerzają funkcje dostępne w AOSP:

• [8.3/W-SR-1] Zdecydowanie zaleca się udostępnienie użytkownikowi możliwości wyświetlania wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii „Czuwanie aplikacji” i „Drzemka”.
• [8.3/W-SR-2] Zdecydowanie zalecamy udostępnienie użytkownikowi możliwości włączania i wyłączania funkcji oszczędzania baterii.

Implementacje urządzeń z systemem Wear OS:

• [8.4/W-0-1] MUSI udostępniać profil zasilania poszczególnych komponentów, który określa wartość zużycia prądu każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
• [8.4/W-0-2] MUSI zgłaszać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
• [8.4/W-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/W-0-4] MUSI udostępniać te dane o zużyciu energii deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.
• [8,4 W] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji.

2.4.5. Model zabezpieczeń

Implementacje urządzeń z systemem Wear OS:

• [9/W-0-1] MUSI zadeklarować funkcję android.hardware.security.model.compatible.

Jeśli implementacje urządzeń z Wear OS zawierają domyślną aplikację obsługującą VoiceInteractionService, to:

• [9.1/W-0-1] NIE MOŻE przyznawać ACCESS_FINE_LOCATION jako domyślnego uprawnienia w przypadku tej aplikacji.

Jeśli implementacje urządzeń z Wear OS obsługują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, to:

• [9.5/W-1-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska, w których będą pracować dodatkowi użytkownicy. Mają też możliwość zarządzania bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli implementacje urządzeń z Wear OS obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony:

• [9.5/W-2-1] NIE MOŻE obsługiwać profili z ograniczeniami, ale MUSI być zgodny z implementacją AOSP elementów sterujących, które umożliwiają włączanie i wyłączanie dostępu innych użytkowników do połączeń głosowych i SMS-ów.

Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jednego agenta zaufania, który implementuje interfejs TrustAgentService System API:

2.5. Wymagania dotyczące motoryzacji

Implementacja Androida Automotive odnosi się do jednostki głównej pojazdu działającej na Androidzie jako systemie operacyjnym części lub całości systemu i/lub funkcji informacyjno-rozrywkowych.

Implementacje urządzeń z Androidem są klasyfikowane jako Automotive, jeśli deklarują funkcję android.hardware.type.automotive lub spełniają wszystkie te kryteria:

• są wbudowane w pojazd lub można je do niego podłączyć.

• używasz ekranu w rzędzie fotela kierowcy jako głównego wyświetlacza;

Dodatkowe wymagania w pozostałej części tej sekcji dotyczą implementacji urządzeń z Androidem Automotive.

2.5.1. Sprzęt

Implementacje urządzeń z systemem Automotive:

• [7.1.1.1/A-0-1] MUSI mieć ekran o przekątnej co najmniej 6 cali.

• [7.1.1.1/A-0-2] MUSI mieć układ ekranu o rozmiarze co najmniej 750 dp x 480 dp.

• [7.1.1.1/A-0-3] MUSI obsługiwać kompozycję GPU buforów graficznych o rozmiarze co najmniej tak dużym jak najwyższa rozdzielczość dowolnego wbudowanego wyświetlacza.

Jeśli implementacje urządzeń z systemem Automotive obsługują jednoczesne korzystanie z wielu użytkowników (wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnym wyświetlaczem, gdy włączona jest funkcja config_multiuserVisibleBackgroundUsers):

• [7.1.1.1/A-1-1] MUSI mieć oddzielny ekran o przekątnej co najmniej 6 cali w każdej strefie pasażera na potrzeby głównego wyświetlacza. Każda strefa zajmowana przez pasażerów powinna być oznaczona tagiem CarOccupantZoneManager.DISPLAY_TYPE_MAIN.

• [7.1.1.1/A-1-2] MUSI mieć układ ekranu o rozmiarze co najmniej 750 dp x 480 dp na każdy główny wyświetlacz.

Jeśli implementacje urządzeń z systemem Automotive obsługują OpenGL ES 3.1:

• [7.1.4.1/A-0-1] MUSI deklarować OpenGL ES 3.1 lub nowszy.

• [7.1.4.1/A-0-2] MUSI obsługiwać Vulkan 1.1.

• [7.1.4.1/A-0-3] MUSI zawierać moduł wczytujący Vulkan i eksportować wszystkie symbole.

Jeśli implementacje urządzeń z systemem Automotive obsługują Vulkan, to:

• [7.1.4.2/A-1-1] MUSI spełniać wymagania określone w profilu Android Baseline 2021.

Jeśli implementacje urządzeń z systemem Automotive deklarują obsługę wyświetlaczy o szerokim zakresie dynamicznym za pomocą Configuration.isScreenHdr(),

• [7.1.4.5/A-1-1] MUSI reklamować obsługę rozszerzeń EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace i VK_EXT_hdr_metadata.

Implementacje urządzeń z systemem Automotive:

• [7.1.4.6/A-0-1] MUSI zgłaszać, czy urządzenie obsługuje funkcję profilowania GPU, za pomocą właściwości systemu graphics.gpu.profiler.support.

Jeśli implementacje urządzeń z systemem Automotive deklarują obsługę za pomocą właściwości systemugraphics.gpu.profiler.support, to:

• [7.1.4.6/A-1-1] MUSI generować jako dane wyjściowe ślad w formacie Protobuf zgodny ze schematem liczników GPU i etapów renderowania GPU zdefiniowanym w dokumentacji Perfetto.

• [7.1.4.6/A-1-2] MUSI raportować zgodne wartości liczników GPU urządzenia zgodnie z gpu counter trace protokołem pakietu.

• [7.1.4.6/A-1-3] MUSI raportować zgodne wartości dla etapów renderowania GPU urządzenia zgodnie z protokołem pakietu śledzenia etapów renderowania.

• [7.1.4.6/A-1-4] MUSI raportować punkt śledzenia Częstotliwość GPU w formacie:power/gpu_frequency.

Implementacje urządzeń z systemem Automotive:

• [7.1.5/A-0-1] MUSI obsługiwać tryb zgodności starszych aplikacji zaimplementowany w kodzie źródłowym Androida. Oznacza to, że implementacje urządzeń NIE MOGĄ zmieniać wyzwalaczy ani progów, przy których aktywowany jest tryb zgodności, ani NIE MOGĄ zmieniać działania samego trybu zgodności.

Implementacje urządzeń z systemem Automotive:

• [7.1.7/A-0-1] MUSI skonfigurować wyświetlacze dodatkowe w polu widzenia kierowcy jako FLAG_PRIVATE.

• [7.2.3/A-0-1] MUSI udostępniać funkcję Strona główna i MOŻE udostępniać funkcje Wstecz i Ostatnie.

• [7.2.3/A-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno zdarzenie normalnego, jak i długiego naciśnięcia funkcji Wstecz (KEYCODE_BACK).

• [7.3/A-0-1] MUSI wdrażać i zgłaszać GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED i PARKING_BRAKE_ON.

• [7.3/A-0-2] Wartość flagi NIGHT_MODE MUSI być zgodna z trybem dziennym/nocnym na panelu i POWINNA być oparta na danych wejściowych z czujnika jasności otoczenia. Czujnik jasności otoczenia MOŻE być taki sam jak fotometr.

• [7.3/A-0-3] MUSI zawierać pole dodatkowych informacji o czujniku TYPE_SENSOR_PLACEMENT w ramach elementu SensorAdditionalInfo dla każdego podanego czujnika.

• [7.3/A-SR1] MOŻE obliczać lokalizację na podstawie ostatniej znanej lokalizacji i kierunku ruchu, łącząc dane z GPS/GNSS z danymi z dodatkowych czujników. Jeśli Lokalizacja jest obliczana na podstawie ostatniej znanej lokalizacji i kierunku ruchu, ZDECYDOWANIE ZALECA się wdrożenie i raportowanie odpowiednich typów czujników lub używanych identyfikatorów właściwości pojazdu.

• [7.3/A-0-4] Lokalizacja żądana za pomocą LocationManager#requestLocationUpdates() NIE MOŻE być dopasowana do mapy.

• [7.3.1/A-0-4] MUSI być zgodny z układem współrzędnych czujników samochodowych w Androidzie.

• [7.3/A-SR-1] Zdecydowanie zaleca się, aby urządzenia zawierały 3-osiowy akcelerometr i 3-osiowy żyroskop.

• [7.3/A-SR-2] ZDECYDOWANIE ZALECA się implementowanie czujnika TYPE_HEADING i raportowanie danych z niego.

Jeśli implementacje urządzeń z systemem Automotive obsługują jednoczesne korzystanie z wielu użytkowników (wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnym wyświetlaczem, gdy włączona jest funkcja config_multiuserVisibleBackgroundUsers):

• [7.3/A-1-1] MUSI ustawiać wartość flagi NIGHT_MODE zgodnie z trybem dziennym/nocnym panelu na wszystkich wyświetlaczach, w tym na wyświetlaczach na tylnych siedzeniach.

Jeśli implementacje urządzeń z systemem Automotive zawierają akcelerometr:

• [7.3.1/A-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 100 Hz.

Jeśli implementacje urządzeń zawierają 3-osiowy akcelerometr:

• [7.3.1/A-SR-1] ZDECYDOWANIE ZALECA SIĘ implementowanie czujnika złożonego dla akcelerometru o ograniczonej liczbie osi.

Jeśli implementacje urządzeń z systemem Automotive zawierają akcelerometr z mniej niż 3 osiami:

• [7.3.1/A-1-3] MUSI implementować czujnik TYPE_ACCELEROMETER_LIMITED_AXES i raportować dane z niego.

• [7.3.1/A-1-4] MUSI implementować czujnik TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED i raportować dane z niego.

Jeśli implementacje urządzeń z systemem Automotive zawierają żyroskop:

• [7.3.4/A-2-1] MUSI mieć możliwość raportowania zdarzeń z 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-1] Zdecydowanie zaleca się skonfigurowanie zakresu pomiarowego żyroskopu na +/-250 dps, aby zmaksymalizować możliwą rozdzielczość.

Jeśli implementacje urządzeń z systemem Automotive zawierają 3-osiowy żyroskop:

• [7.3.4/A-SR-2] ZDECYDOWANIE ZALECA SIĘ implementowanie czujnika złożonego dla żyroskopu o ograniczonej liczbie osi.

Jeśli implementacje urządzeń z systemem Automotive zawierają żyroskop z mniej niż 3 osiami:

• [7.3.4/A-4-1] MUSI implementować czujnik TYPE_GYROSCOPE_LIMITED_AXES i raportować dane z niego.

• [7.3.4/A-4-2] MUSI implementować czujnik TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED i raportować dane z niego.

Jeśli implementacje urządzeń z systemem Automotive zawierają odbiornik GPS/GNSS, ale nie obejmują łączności opartej na sieci komórkowej:

• [7.3.3/A-3-1] MUSI określić lokalizację za pierwszym razem, gdy odbiornik GPS/GNSS zostanie włączony lub po 4 dniach w ciągu 60 sekund.

• [7.3.3/A-3-2] MUSI spełniać kryteria czasu do pierwszego ustalenia pozycji opisane w punktach 7.3.3/C-1-2 i 7.3.3/C-1-6 w przypadku wszystkich innych żądań lokalizacji (tj.żądań, które nie są pierwszymi w historii ani nie są wysyłane po ponad 4 dniach). Wymaganie 7.3.3/C-1-2 jest zwykle spełniane w pojazdach bez łączności opartej na komórkowej transmisji danych przez używanie prognoz orbit GNSS obliczanych na odbiorniku lub przez używanie ostatniej znanej lokalizacji pojazdu wraz z możliwością określania pozycji metodą martwego rachunku przez co najmniej 60 sekund z dokładnością pozycji spełniającą wymaganie 7.3.3/C-1-3 lub przez połączenie obu tych metod.

Jeśli implementacje urządzeń z systemem Automotive zawierają czujnik TYPE_HEADING:

• [7.3.4/A-4-3] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 1 Hz.

• [7.3.4/A-SR-3] ZDECYDOWANIE ZALECA się zgłaszanie zdarzeń z częstotliwością co najmniej 10 Hz.

• POWINNA odnosić się do północy geograficznej.

• POWINNA być dostępna nawet wtedy, gdy pojazd jest nieruchomy.

• POWINNA mieć rozdzielczość co najmniej 1 stopnia.

Implementacje urządzeń z systemem Automotive:

• [7.4.3/A-0-1] MUSI obsługiwać Bluetooth i POWINIEN obsługiwać Bluetooth LE.

• [7.4.3/A-0-2] Implementacje Androida Automotive MUSZĄ obsługiwać te profile Bluetooth:

  • Połączenia telefoniczne przez profil zestawu głośnomówiącego (HFP).
  • Odtwarzanie multimediów za pomocą profilu dystrybucji dźwięku (A2DP).
  • sterowanie odtwarzaniem multimediów za pomocą profilu zdalnego sterowania (AVRCP);
  • Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).

• [7.4.3/A-SR-1] Zdecydowanie zaleca się obsługę profilu dostępu do wiadomości (MAP), jeśli urządzenie znajduje się w strefie kierowcy.

Jeśli implementacje urządzeń z systemem Automotive obsługują jednoczesne korzystanie z wielu użytkowników (wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnym wyświetlaczem, gdy włączona jest funkcja config_multiuserVisibleBackgroundUsers):

• [7.4.3/A-1-1] MUSI być niezależne i NIE może zakłócać korzystania z Bluetootha przez innych użytkowników.

Implementacje urządzeń z systemem Automotive:

• [7.4.5/A] POWINNO obejmować obsługę łączności komórkowej opartej na sieci.

• [7.4.5/A] MOŻE używać stałej System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID w przypadku sieci, które powinny być dostępne dla aplikacji systemowych.

Jeśli implementacje urządzeń obejmują obsługę radia AM/FM i udostępniają tę funkcję dowolnej aplikacji:

• [7.4/A-1-1] MUSI deklarować obsługę FEATURE_BROADCAST_RADIO.

Tylny aparat to aparat skierowany na zewnątrz, który może być umieszczony w dowolnym miejscu pojazdu i skierowany na zewnątrz kabiny pojazdu; rejestruje on sceny po drugiej stronie nadwozia pojazdu, np. kamera cofania.

Przedni aparat to aparat skierowany na użytkownika, który może być umieszczony w dowolnym miejscu w pojeździe i skierowany do wnętrza kabiny. Służy on do rejestrowania obrazu użytkownika, np. podczas wideokonferencji i w podobnych zastosowaniach.

Implementacje urządzeń z systemem Automotive:

• [7.5/A-SR-1] Zdecydowanie zaleca się, aby zawierały co najmniej jedną kamerę skierowaną na zewnątrz.

• MOŻE zawierać co najmniej 1 aparat skierowany na użytkownika.

• [7.5/A-SR-2] ZDECYDOWANIE ZALECANE jest obsługiwanie jednoczesnego przesyłania strumieniowego z wielu kamer.

Jeśli urządzenia samochodowe zawierają co najmniej 1 kamerę skierowaną na zewnątrz, w przypadku takiej kamery:

• [7.5/A-1-1] MUSI być zorientowany w taki sposób, aby dłuższy wymiar kamery był zgodny z płaszczyzną XY osi czujników samochodowych Androida.

• [7.5/A-SR-3] Zdecydowanie zaleca się, aby urządzenia miały sprzęt z stałą ostrością lub EDOF (rozszerzoną głębią ostrości).

• [7.5/A-1-2] MUSI mieć główny aparat skierowany na zewnątrz jako aparat skierowany na zewnątrz o najniższym identyfikatorze.

Jeśli implementacje urządzeń z systemem Automotive zawierają co najmniej 1 kamerę skierowaną w stronę użytkownika, w przypadku takiej kamery:

• [7.5/A-2-1] Główny aparat skierowany na użytkownika MUSI być aparatem skierowanym na użytkownika o najniższym identyfikatorze.

• MOŻE być zorientowany tak, aby dłuższy wymiar kamery był zgodny z płaszczyzną X-Y osi czujników Androida Automotive.

Jeśli implementacje urządzeń samochodowych zawierają kamerę dostępną za pomocą interfejsu API android.hardware.Camera lub android.hardware.camera2, muszą:

• [7.5/A-3-1] MUSI spełniać podstawowe wymagania dotyczące aparatu określone w sekcji 7.5.

Jeśli implementacje urządzeń samochodowych obejmują co najmniej 1 kamerę dostępną za pomocą usługi Extended View System Service, w przypadku takiej kamery:

• [7.5/A-5-1] NIE WOLNO obracać ani odbijać poziomo podglądu z kamery.

• [7.5/A-SR-4] Zdecydowanie zaleca się, aby miały rozdzielczość co najmniej 1,3 megapiksela.

Jeśli implementacje urządzeń samochodowych obejmują co najmniej 1 kamerę, która jest dostępna zarówno za pomocą usługi Extended View System, jak i interfejsu API android.hardware.Camera lub android.hardware.Camera2, to w przypadku takiej kamery:

• [7.5/A-6-1] MUSI zgłaszać ten sam identyfikator kamery.

Jeśli implementacje urządzeń z systemem Automotive udostępniają zastrzeżony interfejs API aparatu:

• [7.5/A-7-1] MUSI implementować taki interfejs API aparatu za pomocą interfejsu API android.hardware.camera2 lub interfejsu API Extended View System.

Implementacje urządzeń z systemem Automotive:

• [7.6.1/A-0-1] MUSI mieć co najmniej 4 GB pamięci trwałej dostępnej na prywatne dane aplikacji (/data partycja).

• [7.6.1/A] POWINIEN sformatować partycję danych, aby zapewnić lepszą wydajność i dłuższą żywotność pamięci flash (np. używając systemu plików f2fs).

Jeśli urządzenia samochodowe udostępniają współdzielone miejsce zewnętrzne za pomocą części wewnętrznej, niewymiennej pamięci, to:

• [7.6.1/A-SR-1] ZDECYDOWANIE ZALECA się ograniczenie obciążenia wejścia/wyjścia podczas operacji wykonywanych na pamięci zewnętrznej, na przykład przez użycie SDCardFS.

Jeśli implementacje urządzeń z systemem Automotive obsługują jednoczesne korzystanie z wielu użytkowników (wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnym wyświetlaczem, gdy włączona jest funkcja config_multiuserVisibleBackgroundUsers):

• [7.6.1/A-1-1] MUSI mieć na pojedynczej instancji AAOS co najmniej 4 GB pamięci trwałej na każdego równoczesnego użytkownika Androida na potrzeby prywatnych danych aplikacji (partycja /data).

Jeśli implementacje urządzeń z systemem Automotive są 64-bitowe:

• [7.6.1/A-2-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 816 MB na główny wyświetlacz, jeśli używana jest którakolwiek z tych gęstości:

  • 280 dpi lub mniej na małych i normalnych ekranach
  • ldpi lub niższa na bardzo dużych ekranach;
  • mdpi lub niższa na dużych ekranach;

• [7.6.1/A-2-2] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 944 MB na główny wyświetlacz, jeśli używana jest którakolwiek z tych gęstości:

  • xhdpi lub wyższa na małych i normalnych ekranach,
  • hdpi lub wyższa na dużych ekranach,
  • mdpi lub wyższa na bardzo dużych ekranach,

• [7.6.1/A-2-3] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1280 MB na główny wyświetlacz, jeśli używana jest którakolwiek z tych gęstości:

  • 400 dpi lub więcej na małych i normalnych ekranach
  • xhdpi lub wyższa na dużych ekranach,
  • tvdpi lub wyższa na bardzo dużych ekranach,

• [7.6.1/A-2-4] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1824 MB na główny wyświetlacz, jeśli używana jest którakolwiek z tych gęstości:

  • 560 dpi lub więcej na małych i normalnych ekranach
  • 400 dpi lub więcej na dużych ekranach
  • xhdpi lub wyższa na bardzo dużych ekranach,

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do przestrzeni pamięci udostępnianej oprócz pamięci już przypisanej do komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro na urządzeniach.

Implementacje urządzeń z systemem Automotive:

• [7.7.1/A] POWINNO zawierać port USB obsługujący tryb peryferyjny.

Jeśli implementacje urządzeń z systemem Automotive zawierają port USB z kontrolerem działającym w trybie urządzenia peryferyjnego:

• [7.7.1/A-1-1] MUSI implementować interfejs Android Open Accessory (AOA).

Jeśli implementacje urządzeń z systemem Automotive zawierają port USB obsługujący tryb hosta:

• [7.7.2/A-1-1] MUSI implementować klasę audio USB zgodnie z dokumentacją pakietu Android SDK.

Implementacje urządzeń z systemem Automotive:

• [7.8.1/A-0-1] MUSI zawierać mikrofon.

Implementacje urządzeń z systemem Automotive:

• [7.8.2/A-0-1] MUSI mieć wyjście audio i deklarować android.hardware.audio.output.

Jeśli implementacje urządzeń z systemem Automotive obsługują jednoczesne korzystanie z wielu użytkowników (wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnym wyświetlaczem, gdy włączona jest funkcja config_multiuserVisibleBackgroundUsers):

• [7.8.2/A-1-1] W przypadku systemów dla wielu użytkowników MUSI być dostępne urządzenie wyjściowe audio dla każdego głównego wyświetlacza.

• [7.8.2/A-1-2] MUSI mieć strefę audio kierowcy obejmującą głośnik w kabinie. Strefa pasażera z przodu może współdzielić strefę audio kierowcy lub mieć własne wyjście audio.

Gdy wywoływany jest interfejs AudioManager.getDevices() API, a urządzenie peryferyjne USB jest podłączone:

• [7.8.2.2/A-1-1] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i roli isSink(), jeśli pole typu terminala audio USB ma wartość 0x0302.

• [7.8.2.2/A-1-2] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i rolę isSink(), jeśli pole typu terminala audio USB ma wartość 0x0402.

• [7.8.2.2/A-1-3] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i roli isSink(), jeśli pole typu terminala audio USB ma wartość 0x0603.

• [7.8.2.2/A-1-4] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i rolę isSink(), jeśli pole typu terminala audio USB ma wartość 0x0400.

2.5.2. Multimedia

Implementacje urządzeń z systemem Automotive MUSZĄ obsługiwać te formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:

• [5.1/A-0-1] Profil MPEG-4 AAC (AAC LC)

• [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)

• [5.1/A-0-3] AAC ELD (enhanced low delay AAC)

Implementacje urządzeń samochodowych MUSZĄ obsługiwać te formaty kodowania wideo i udostępniać je aplikacjom innych firm:

• [5.2/A-0-1] H.264 AVC

• [5.2/A-0-2] VP8

Urządzenia samochodowe MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

• [5.3/A-0-1] H.264 AVC

• [5.3/A-0-2] MPEG-4 SP

• [5.3/A-0-3] VP8

• [5.3/A-0-4] VP9

W przypadku implementacji urządzeń z systemem Automotive ZDECYDOWANIE ZALECA SIĘ obsługę dekodowania wideo w tych formatach:

• [5.3/A-SR-1] H.265 HEVC

Jeśli implementacje urządzeń z systemem Automotive obsługują jednoczesne korzystanie z wielu użytkowników (wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnym wyświetlaczem, gdy włączona jest funkcja config_multiuserVisibleBackgroundUsers):

• [5.5.3/A-1-1] MUSI definiować identyczne krzywe głośności dla wszystkich strumieni wyjściowych audio przypisanych do tej samej grupy głośności zdefiniowanej w pliku konfiguracyjnym audio w samochodzie.

2.5.3. Oprogramowanie

Implementacje urządzeń z systemem Automotive:

• [3/A-0-1] MUSI deklarować funkcję android.hardware.type.automotive.

• [3/A-0-2] MUSI obsługiwać uiMode = UI_MODE_TYPE_CAR.

• [3/A-0-3] MUSI obsługiwać wszystkie publiczne interfejsy API w przestrzeni nazw android.car.*.

Jeśli implementacje urządzeń z systemem Automotive udostępniają zastrzeżony interfejs API za pomocą android.car.CarPropertyManager z android.car.VehiclePropertyIds:

• [3/A-1-1] NIE WOLNO przyznawać specjalnych uprawnień do korzystania z tych właściwości aplikacjom systemowym ani uniemożliwiać korzystania z nich aplikacjom innych firm.

• [3/A-1-2] NIE MOŻE replikować właściwości pojazdu, która już istnieje w pakiecie SDK.

Implementacje urządzeń z systemem Automotive:

• [3.2.1/A-0-1] MUSI obsługiwać i egzekwować wszystkie stałe uprawnienia zgodnie z dokumentacją na stronie referencyjnej uprawnień w motoryzacji.

• [3.2.3.1/A-0-1] MUSI wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi z procedurą obsługi intencji dla wszystkich publicznych wzorców filtrów intencji zdefiniowanych przez intencje aplikacji wymienione tutaj.

• [3.2.3.1/A-0-2] MUSI mieć aplikację, która obsługuje intencje ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, i ACTION_CREATE_DOCUMENT zgodnie z opisem w dokumentach pakietu SDK oraz zapewnia użytkownikowi możliwość dostępu do danych dostawcy dokumentów za pomocą interfejsu API DocumentsProvider.

Jeśli aplikacja ustawień w implementacji urządzenia samochodowego implementuje podzieloną funkcjonalność za pomocą osadzania aktywności, to:

• [3.2.3.1/A-1-1] MUSI mieć aktywność, która obsługuje intencję Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY, gdy funkcja podziału jest włączona. Działanie MUSI być chronione przez android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK i MUSI rozpoczynać działanie intencji przeanalizowanej z Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

• [3.4.1/A-0-1] MUSI udostępniać pełną implementację interfejsu android.webkit.Webview API.

Jeśli implementacje urządzeń z systemem Automotive obsługują jednoczesne korzystanie z wielu użytkowników (wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnym wyświetlaczem, gdy włączona jest funkcja config_multiuserVisibleBackgroundUsers):

• [3.8/A-1-1] MUSI implementować tę predefiniowaną listę UserRestrictions dla wszystkich użytkowników pomocniczych, którzy nie są aktualnie użytkownikami pierwszoplanowymi, ale mają dostęp do interfejsu wyświetlacza przypisanego do nich. Lista UserRestrictions to:DISALLOW_CONFIG_LOCALE,DISALLOW_CONFIG_BLUETOOTH,DISALLOW_BLUETOOTH,DISALLOW_CAMERA_TOGGLE i DISALLOW_MICROPHONE_TOGGLE.

• [3.8/A-1-2] NIE WOLNO zezwalać pełnym użytkownikom dodatkowym, którzy nie są bieżącym użytkownikiem pierwszoplanowym, ale mają dostęp do interfejsu wyświetlacza przypisanego do nich, na zmianę trybu dziennego/nocnego, ustawień regionalnych, daty, godziny, strefy czasowej ani funkcji kolorów wyświetlacza (w tym jasności, trybu nocnego, skali szarości w ramach cyfrowego dobrostanu i ograniczania jasnych kolorów) w przypadku innych użytkowników za pomocą Ustawień lub interfejsu API.

Implementacje urządzeń z systemem Automotive:

• [3.8.3/A-0-1] MUSI wyświetlać powiadomienia, które korzystają z interfejsu Notification.CarExtender API, gdy jest to wymagane przez aplikacje innych firm.

• [3.8.4/A-SR-1] Zdecydowanie zalecamy wdrożenie na urządzeniu asystenta, który będzie obsługiwać działanie Assist.

Jeśli implementacje urządzeń z systemem Automotive zawierają przycisk naciśnij i mów, to:

• [3.8.4/A-1-1] MUSI używać krótkiego naciśnięcia przycisku „naciśnij i mów” jako wyznaczonego działania do uruchamiania wybranej przez użytkownika aplikacji asystującej, czyli aplikacji, która implementuje VoiceInteractionService.

Implementacje urządzeń z systemem Automotive:

• [3.8.3.1/A-0-1] MUSI prawidłowo renderować zasoby zgodnie z opisem w dokumentacji pakietu SDK Notifications on Automotive OS.

• [3.8.3.1/A-0-2] MUSI wyświetlać ODTWÓRZ i WYCISZ w przypadku działań związanych z powiadomieniami zamiast tych, które są udostępniane za pomocą Notification.Builder.addAction().

• [3.8.3.1/A] POWINNY ograniczać korzystanie z zaawansowanych funkcji zarządzania, takich jak sterowanie poszczególnymi kanałami powiadomień. MOŻE używać elementów interfejsu użytkownika w poszczególnych aplikacjach, aby ograniczyć liczbę elementów sterujących.

Jeśli implementacje urządzeń z systemem Automotive obsługują właściwości User HAL, to:

• [3.9.3/A-1-1] MUSI implementować wszystkie właściwości cyklu życia użytkownika: INITIAL_USER_INFO, SWITCH_USER, CREATE_USER i REMOVE_USER.

Implementacje urządzeń z systemem Automotive:

• [3.14/A-0-1] MUSI zawierać platformę interfejsu, która obsługuje aplikacje innych firm korzystające z interfejsów API multimediów zgodnie z opisem w sekcji 3.14.

• [3.14/A-0-2] MUSI umożliwiać użytkownikowi bezpieczne korzystanie z aplikacji multimedialnych podczas jazdy.

• [3.14/A-0-3] MUSI obsługiwać CAR_INTENT_ACTION_MEDIA_TEMPLATE niejawną intencję z działaniem intencji CAR_EXTRA_MEDIA_PACKAGE dodatkowym.

• [3.14/A-0-4] MUSI udostępniać możliwość przejścia do aktywności preferencji aplikacji multimedialnej, ale MUSI ją włączać tylko wtedy, gdy nie obowiązują ograniczenia dotyczące UX w samochodzie.

• [3.14/A-0-5] MUSI wyświetlać komunikaty o błędach ustawione przez aplikacje multimedialne i MUSI obsługiwać opcjonalne dodatki ERROR_RESOLUTION_ACTION_LABEL i ERROR_RESOLUTION_ACTION_INTENT.

• [3.14/A-0-6] MUSI obsługiwać funkcję wyszukiwania w aplikacji w przypadku aplikacji, które obsługują wyszukiwanie.

• [3.14/A-0-7] MUSI uwzględniać definicje CONTENT_STYLE_BROWSABLE_HINT i CONTENT_STYLE_PLAYABLE_HINT podczas wyświetlania hierarchii MediaBrowser.

Jeśli implementacje urządzeń z systemem Automotive zawierają domyślną aplikację programu uruchamiającego:

• [3.14/A-1-1] MUSI zawierać usługi multimedialne i otwierać je za pomocą intencji CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Implementacje urządzeń z systemem Automotive:

• [3.8/A] MOŻE ograniczyć żądania aplikacji dotyczące przejścia w tryb pełnoekranowy zgodnie z opisem w sekcji immersive documentation.

• [3.8/A] MOŻE utrzymywać pasek stanu i pasek nawigacyjny zawsze widoczne.

• [3.8/A] MOŻE ograniczyć żądania aplikacji dotyczące zmiany kolorów elementów interfejsu systemu, aby zapewnić ich dobrą widoczność w każdej sytuacji.

2.5.4. Wydajność i moc

• [8.1/A-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie klatek lub opóźnienie renderowania klatek NIE MOŻE występować częściej niż 5 klatek na sekundę i POWINNO być mniejsze niż 1 klatka na sekundę.

• [8.1/A-0-2] Opóźnienie interfejsu. Implementacje urządzeń MUSZĄ zapewniać użytkownikom małe opóźnienia,przewijając listę 10 000 pozycji zdefiniowaną w pakiecie testów zgodności Androida (CTS) w czasie krótszym niż 36 sekund.

• [8.1/A-0-3] Przełączanie zadań. Ponowne uruchomienie aplikacji, która jest już uruchomiona, musi zająć mniej niż 1 sekundę.

Implementacje urządzeń z systemem Automotive:

• [8.2/A-0-1] MUSI raportować liczbę bajtów odczytanych i zapisanych w pamięci trwałej dla każdego identyfikatora UID procesu, aby statystyki były dostępne dla deweloperów za pomocą interfejsu API systemuandroid.car.storagemonitoring.CarStorageMonitoringManager. Projekt Android Open Source spełnia to wymaganie dzięki uid_sys_statsmodułowi jądra.

• [8.2/A-0-2] MUSI zapewniać sekwencyjną wydajność zapisu na poziomie co najmniej 5 MB/s.

• [8.2/A-0-3] MUSI zapewniać wydajność losowego zapisu na poziomie co najmniej 0,5 MB/s.

• [8.2/A-0-4] MUSI zapewniać wydajność odczytu sekwencyjnego na poziomie co najmniej 15 MB/s.

• [8.2/A-0-5] MUSI zapewniać wydajność odczytu losowego na poziomie co najmniej 3,5 MB/s.

Jeśli implementacje urządzeń z systemem Automotive zwracają wartość android.os.Build.VERSION_CODES.U lub większą w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• [8.2/A-1-1] MUSI zapewniać sekwencyjną wydajność zapisu na poziomie co najmniej 150 MB/s.

• [8.2/A-1-2] MUSI zapewniać wydajność zapisu losowego na poziomie co najmniej 10 MB/s.

• [8.2/A-1-3] MUSI zapewniać sekwencyjną wydajność odczytu na poziomie co najmniej 250 MB/s.

• [8.2/A-1-4] MUSI zapewniać wydajność odczytu losowego na poziomie co najmniej 100 MB/s.

• [8.2/A-1-5] MUSI zapewniać równoległą wydajność odczytu i zapisu sekwencyjnego z 2-krotną wydajnością odczytu i 1-krotną wydajnością zapisu na poziomie co najmniej 50 MB/s.

• [8.3/A-1-3] MUSI obsługiwać tryb garażowy.

• [8.3/A] POWINNA być w trybie garażowym przez co najmniej 15 minut po każdej jeździe, chyba że:

  • Bateria jest rozładowana.
  • Nie ma zaplanowanych zadań bezczynnych.
  • Kierowca wyłącza tryb garażowy.

• [8.4/A-0-1] MUSI udostępniać profil zasilania poszczególnych komponentów, który określa wartość zużycia prądu każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.

• [8.4/A-0-2] MUSI zgłaszać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).

• [8.4/A-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.

• [8.4/A] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji.

• [8.4/A-0-4] MUSI udostępniać te dane o zużyciu energii deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.

2.5.5. Model zabezpieczeń

Jeśli implementacje urządzeń z systemem Automotive obsługują wielu użytkowników:

• [9.5/A-1-1] NIE MOŻE zezwalać użytkownikom na interakcję z użytkownikiem systemu bez interfejsu ani na przełączanie się na niego, z wyjątkiem udostępniania urządzenia.

• [9.5/A-1-2] MUSI przełączyć się na użytkownika dodatkowego przed BOOT_COMPLETED.

• [9.5/A-1-3] MUSI obsługiwać możliwość utworzenia użytkownika-gościa, nawet jeśli na urządzeniu osiągnięto maksymalną liczbę użytkowników.

Jeśli implementacje urządzeń z systemem Automotive obsługują interfejs System APIVisualQueryDetectionService lub inny mechanizm wykrywania zapytań bez wskazywania dostępu do mikrofonu lub kamery, to:

• [9.8/A-1-1] MUSI dopilnować, aby usługa wykrywania zapytań mogła przesyłać dane tylko do Systemu, ContentCaptureService lub usługi rozpoznawania mowy na urządzeniu (utworzonej przez SpeechRecognizer#createOnDeviceSpeechRecognizer()).

• [9.8/A-1-2] NIE MOŻE zezwalać na przesyłanie informacji audio lub wideo poza VisualQueryDetectionService, z wyjątkiem przesyłania do ContentCaptureService lub usługi rozpoznawania mowy na urządzeniu.

• [9.8/A-1-3] MUSI wyświetlać powiadomienie dla użytkownika w interfejsie systemu, gdy urządzenie wykryje intencję użytkownika, aby skorzystać z aplikacji Asystent cyfrowy (np. wykrywając obecność użytkownika za pomocą kamery).

• [9.8/A-1-4] MUSI wyświetlać wskaźnik mikrofonu i wykryte zapytanie użytkownika w interfejsie natychmiast po wykryciu zapytania.

• [9.8/A-1-5] NIE MOŻE zezwalać na udostępnianie usługi wykrywania zapytań wizualnych przez aplikację, którą użytkownik może zainstalować.

Jeśli implementacje urządzeń z systemem Automotive deklarują android.hardware.microphone, to:

• [9.8.2/A-1-1] MUSI wyświetlać wskaźnik mikrofonu, gdy aplikacja uzyskuje dostęp do danych audio z mikrofonu, ale nie wtedy, gdy mikrofon jest używany tylko przez HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje pełniące role wymienione w sekcji 9.1 z identyfikatorem CDD [C-4-X].

• [9.8.2/A-1-2] NIE MOŻE ukrywać wskaźnika mikrofonu w przypadku aplikacji systemowych, które mają widoczny interfejs użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.

• [9.8.2/A-1-3] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania mikrofonu w aplikacji Ustawienia.

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

• [9.8.2/A-2-1] MUSI wyświetlać wskaźnik aparatu, gdy aplikacja uzyskuje dostęp do danych z kamery na żywo, ale nie wtedy, gdy kamera jest używana tylko przez aplikacje pełniące role zdefiniowane w sekcji 9.1 Uprawnienia z identyfikatorem dokumentu CDD [C-4-X].

• [9.8.2/A-2-2] NIE MOŻE ukrywać wskaźnika aparatu w przypadku aplikacji systemowych, które mają widoczny interfejs użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.

• [9.8.2/A-2-3] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania aparatu w aplikacji Ustawienia.

• [9.8.2/A-2-4] MUSZĄ wyświetlać ostatnie i aktywne aplikacje korzystające z aparatu, zwrócone przez PermissionManager.getIndicatorAppOpUsageData(), oraz powiązane z nimi komunikaty o atrybucji.

Implementacje urządzeń z systemem Automotive:

• [9/A-0-1] MUSI deklarować funkcję android.hardware.security.model.compatible.

• [9.11/A-0-1] MUSI tworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.

• [9.11/A-0-2] MUSI mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji skrótu MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać algorytmy obsługiwane przez system Android Keystore w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i wyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego środowiska izolowanego, w tym DMA. Projekt Android Open Source (AOSP) spełnia to wymaganie, korzystając z implementacji Trusty, ale alternatywnymi opcjami są inne rozwiązania oparte na ARM TrustZone lub zweryfikowane przez zewnętrzną firmę bezpieczne implementacje odpowiedniej izolacji opartej na hiperwizorze.

• [9.11/A-0-3] MUSI przeprowadzać uwierzytelnianie na ekranie blokady w izolowanym środowisku wykonawczym i tylko w przypadku powodzenia zezwalać na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób, który umożliwia uwierzytelnianie na ekranie blokady tylko w izolowanym środowisku wykonawczym. Projekt Android Open Source udostępnia warstwę abstrakcji sprzętowej (HAL) Gatekeeper i Trusty, które mogą być używane do spełnienia tego wymagania.

• [9.11/A-0-4] MUSI obsługiwać atestację klucza, w której klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania zaświadczeń NIE MOGĄ być używane jako trwałe identyfikatory urządzenia.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na wcześniejszej wersji Androida, takie urządzenie jest zwolnione z wymogu posiadania magazynu kluczy opartego na izolowanym środowisku wykonawczym i obsługi atestowania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy opartego na izolowanym środowisku wykonawczym.

Implementacje urządzeń z systemem Automotive:

• [9.14/A-0-1] MUSI ograniczać dostęp do wiadomości z podsystemów pojazdu w ramach platformy Androida (np. zezwalać na określone typy i źródła wiadomości).

• [9.14/A-0-2] MUSI chronić przed atakami typu DoS ze strony platformy Android lub aplikacji innych firm. Zapobiega to zalewaniu sieci pojazdu przez złośliwe oprogramowanie, co może prowadzić do nieprawidłowego działania podsystemów pojazdu.

2.5.6. Zgodność narzędzi i opcji dla programistów

Implementacje urządzeń z systemem Automotive:

• Perfetto

  • [6.1/A-0-1] MUSI udostępniać użytkownikowi powłoki plik binarny, którego wiersz poleceń jest zgodny z /system/bin/perfetto dokumentacją narzędzia perfetto.

  • [6.1/A-0-2] Plik binarny narzędzia Perfetto MUSI akceptować jako dane wejściowe konfigurację bufora protokołu zgodną ze schematem zdefiniowanym w dokumentacji narzędzia Perfetto.

  • [6.1/A-0-3] Plik binarny Perfetto MUSI zapisywać jako dane wyjściowe ślad bufora protokołu zgodny ze schematem zdefiniowanym w dokumentacji Perfetto.

  • [6.1/A-0-4] MUSI udostępniać za pomocą pliku binarnego perfetto co najmniej źródła danych opisane w dokumentacji perfetto.

  • [6.1/A-0-5] Usługa śledzenia perfetto MUSI być domyślnie włączona (właściwość systemowa persist.traced.enable).

2.6. Wymagania dotyczące tabletów

Tablet z Androidem to urządzenie z Androidem, które zwykle spełnia wszystkie te kryteria:

• Używa się go, trzymając go obiema rękami.
• Nie ma konfiguracji typu clamshell ani convertible.
• Klawiatury fizyczne używane z urządzeniem łączą się za pomocą standardowego połączenia (np. USB, Bluetooth).
• ma źródło zasilania, które zapewnia mobilność, np. baterię;
• ma ekran o przekątnej większej niż 7 cali i mniejszej niż 18 cali;

Implementacje urządzeń typu tablet mają podobne wymagania do implementacji urządzeń przenośnych. Wyjątki są oznaczone w tej sekcji gwiazdką (*) i w celach informacyjnych wymienione w tej sekcji.

2.6.1. Sprzęt

Żyroskop

Jeśli implementacje urządzeń typu tablet zawierają 3-osiowy żyroskop:

• [7.3.4/Tab-1-1] MUSI być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.

Minimalna pamięć i miejsce na dane (sekcja 7.6.1)

Gęstości ekranu wymienione w przypadku małych i normalnych ekranów w wymaganiach dotyczących urządzeń przenośnych nie mają zastosowania do tabletów.

Tryb wirtualnej rzeczywistości (sekcja 7.9.1)

Wysoka wydajność w wirtualnej rzeczywistości (sekcja 7.9.2)

Wymagania dotyczące rzeczywistości wirtualnej nie mają zastosowania do tabletów.

2.6.2. Model zabezpieczeń

Klucze i dane uwierzytelniające (sekcja 9.11)

Patrz sekcja [9.11].

Jeśli implementacje na urządzeniach typu tablet obsługują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, to:

• [9.5/T-1-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska, w których będą pracować dodatkowi użytkownicy. Mają też możliwość zarządzania bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli implementacje urządzeń typu tablet obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony, to:

• [9.5/T-2-1] NIE MOŻE obsługiwać profili z ograniczeniami, ale MUSI być zgodny z implementacją AOSP elementów sterujących, które umożliwiają włączanie i wyłączanie dostępu innych użytkowników do połączeń głosowych i SMS-ów.

2.6.2. Oprogramowanie

• [3.2.3.1/Tab-0-1] MUSI wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi z procedurą obsługi intencji dla wszystkich publicznych wzorców filtrów intencji zdefiniowanych przez intencje aplikacji wymienione tutaj.

3. Oprogramowanie

3.1. Zgodność zarządzanego interfejsu API

Zarządzane środowisko wykonawcze kodu bajtowego Dalvik jest głównym narzędziem do uruchamiania aplikacji na Androida. Interfejs programowania aplikacji (API) Androida to zestaw interfejsów platformy Android udostępnianych aplikacjom działającym w zarządzanym środowisku wykonawczym.

Implementacje urządzeń:

• [C-0-1] MUSI udostępniać pełne implementacje, w tym wszystkie udokumentowane zachowania, każdego udokumentowanego interfejsu API udostępnianego przez pakiet Android SDK lub dowolny interfejs API oznaczony w źródłowym kodzie Androida tagiem „@SystemApi”.

• [C-0-2] MUSI obsługiwać/zachowywać wszystkie klasy, metody i powiązane elementy oznaczone adnotacją TestApi (@TestApi).

• [C-0-3] NIE WOLNO pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów ani sygnatur API, odbiegać od udokumentowanego zachowania ani uwzględniać operacji bez efektu, z wyjątkiem przypadków wyraźnie dozwolonych przez tę definicję zgodności.

• [C-0-4] MUSI nadal udostępniać interfejsy API i działać w rozsądny sposób, nawet jeśli niektóre funkcje sprzętowe, dla których Android udostępnia interfejsy API, są pominięte. Szczegółowe wymagania dotyczące tego scenariusza znajdziesz w sekcji 7.

• [C-0-5] NIE MOŻE zezwalać aplikacjom innych firm na używanie interfejsów spoza SDK, które są zdefiniowane jako metody i pola w pakietach języka Java znajdujących się w ścieżce klasy rozruchowej w AOSP i nie stanowią części publicznego pakietu SDK. Obejmuje to interfejsy API oznaczone adnotacją @hide, ale nie adnotacją @SystemAPI, zgodnie z opisem w dokumentach pakietu SDK, a także prywatne i dostępne tylko w pakiecie elementy klasy.

• [C-0-6] MUSI być dostarczany z każdym interfejsem innym niż SDK na tych samych listach z ograniczeniami, które są udostępniane za pomocą flag tymczasowych i listy zablokowanych w prebuilts/runtime/appcompat/hiddenapi-flags.csv ścieżce odpowiedniej gałęzi poziomu API w AOSP.

• [C-0-7] MUSI obsługiwać mechanizm dynamicznej aktualizacji podpisanego pliku konfiguracyjnego, aby usuwać interfejsy inne niż SDK z listy ograniczonej, osadzając podpisany plik konfiguracyjny w dowolnym pliku APK przy użyciu istniejących kluczy publicznych w AOSP.

  Jednak:

  • MAJ, jeśli ukryty interfejs API jest niedostępny lub zaimplementowany inaczej na urządzeniu, przenieść go na listę zablokowanych lub pominąć na wszystkich listach ograniczonych.
  • MAJ, jeśli ukryty interfejs API nie istnieje jeszcze w AOSP, dodaj go do dowolnej listy ograniczeń.

3.1.1. Rozszerzenia Androida

Android umożliwia rozszerzenie zarządzanej powierzchni interfejsu API na określonym poziomie interfejsu API przez zaktualizowanie wersji rozszerzenia dla tego poziomu interfejsu API. android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) Interfejs API zwraca wersję rozszerzenia podanego apiLevel, jeśli istnieją rozszerzenia dla tego poziomu interfejsu API.

Implementacje urządzeń z Androidem:

• [C-0-1] MUSI wstępnie wczytywać implementację AOSP zarówno biblioteki współdzielonejExtShared, jak i usługExtServices w wersjach większych lub równych minimalnym wersjom dozwolonym na każdym poziomie API. Na przykład implementacje urządzeń z Androidem 7.0, które korzystają z interfejsu API na poziomie 24, MUSZĄ zawierać co najmniej wersję 1.

• [C-0-2] MUSI zwracać tylko prawidłowy numer wersji rozszerzenia zdefiniowany przez AOSP.

• [C-0-3] MUSI obsługiwać wszystkie interfejsy API zdefiniowane przez wersje rozszerzeń zwracane przez android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) w taki sam sposób jak inne zarządzane interfejsy API, zgodnie z wymaganiami w sekcji 3.1.

3.1.2. Biblioteka Androida

Z powodu wycofania klienta HTTP Apache implementacje urządzeń:

• [C-0-1] NIE WOLNO umieszczać biblioteki org.apache.http.legacy w ścieżce rozruchowej.
• [C-0-2] Musisz dodać bibliotekę org.apache.http.legacy do ścieżki klas aplikacji tylko wtedy, gdy aplikacja spełnia jeden z tych warunków:
  • kierowana na interfejs API na poziomie 28 lub niższym.
  • W pliku manifestu deklaruje, że potrzebuje biblioteki, ustawiając atrybut android:name elementu <uses-library> na wartość org.apache.http.legacy.

Implementacja AOSP spełnia te wymagania.

3.2. Zgodność z interfejsem API

Oprócz interfejsów API zarządzanych, o których mowa w sekcji 3.1, Android zawiera też ważny interfejs API „programowy” działający tylko w czasie działania, w postaci takich elementów jak intencje, uprawnienia i podobne aspekty aplikacji na Androida, których nie można wymusić w czasie kompilacji aplikacji.

3.2.1. Uprawnienia

• [C-0-1] Producenci urządzeń MUSZĄ obsługiwać i egzekwować wszystkie stałe uprawnienia zgodnie z dokumentacją na stronie referencyjnej uprawnień. Pamiętaj, że w sekcji 9 wymieniono dodatkowe wymagania związane z modelem zabezpieczeń Androida.

3.2.2. Parametry kompilacji

Interfejsy API Androida zawierają wiele stałych w klasie android.os.Build, które opisują bieżące urządzenie.

3.2.3. Zgodność z intencją

3.2.3.1. Typowe intencje aplikacji

Intencje Androida umożliwiają komponentom aplikacji żądanie funkcji z innych komponentów Androida. Projekt Android upstream zawiera listę aplikacji, które implementują kilka wzorców intencji do wykonywania typowych działań.

Implementacje urządzeń:

• [C-SR-1] Zdecydowanie zaleca się wstępne wczytywanie co najmniej 1 aplikacji lub komponentu usługi z procedurą obsługi intencji dla wszystkich wzorców publicznych filtrów intencji zdefiniowanych przez intencje aplikacji wymienione tutaj oraz zapewnianie realizacji, czyli spełnianie oczekiwań dewelopera dotyczących tych typowych intencji aplikacji zgodnie z opisem w pakiecie SDK.

W sekcji 2 znajdziesz obowiązkowe intencje aplikacji dla każdego typu urządzenia.

3.2.3.2. Rozpoznawanie intencji

• [C-0-1] Android to platforma rozszerzalna, więc implementacje urządzeń MUSZĄ umożliwiać zastępowanie przez aplikacje innych firm każdego wzorca intencji wymienionego w sekcji 3.2.3.1, z wyjątkiem ustawień. W domyślnej implementacji open source Androida jest to możliwe.

• [C-0-2] Producenci urządzeń NIE MOGĄ przyznawać specjalnych uprawnień aplikacjom systemowym do korzystania z tych wzorców intencji ani uniemożliwiać aplikacjom innych firm wiązania się z tymi wzorcami i przejmowania nad nimi kontroli. Zakaz ten obejmuje w szczególności wyłączanie interfejsu użytkownika „Wybór”, który umożliwia użytkownikowi wybór spośród wielu aplikacji obsługujących ten sam wzorzec intencji.

• [C-0-3] Urządzenia MUSZĄ udostępniać interfejs użytkownika, który umożliwia modyfikowanie domyślnej aktywności w przypadku intencji.

• Jednak implementacje urządzeń MOGĄ udostępniać domyślne działania dla określonych wzorców URI (np. http://play.google.com), gdy domyślne działanie udostępnia bardziej szczegółowy atrybut dla identyfikatora URI danych. Na przykład wzorzec filtra intencji określający identyfikator URI danych „http://www.android.com” jest bardziej szczegółowy niż podstawowy wzorzec intencji przeglądarki dla „http://”.

Android zawiera też mechanizm, który umożliwia aplikacjom innych firm deklarowanie autorytatywnego domyślnego zachowania linków do aplikacji w przypadku niektórych typów intencji identyfikatorów URI sieci. Gdy takie deklaracje autorytatywne są zdefiniowane w wzorcach filtrów intencji aplikacji, implementacje urządzeń:

• [C-0-4] MUSI próbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji protokołu Digital Asset Links, które są zaimplementowane przez Menedżera pakietów w projekcie Android Open Source Project.
• [C-0-5] MUSI próbować zweryfikować filtry intencji podczas instalacji aplikacji i ustawić wszystkie pomyślnie zweryfikowane filtry intencji URI jako domyślne programy obsługi aplikacji dla ich identyfikatorów URI.
• MOGĄ ustawić konkretne filtry intencji URI jako domyślne programy obsługi identyfikatorów URI, jeśli zostaną one zweryfikowane, ale inne filtry URI nie przejdą weryfikacji. Jeśli urządzenie to robi, MUSI udostępniać w menu ustawień odpowiednie dla użytkownika zastąpienia wzorców dla poszczególnych identyfikatorów URI.
• MUSI udostępniać użytkownikowi w Ustawieniach elementy sterujące linkami do aplikacji dla poszczególnych aplikacji w sposób opisany poniżej:
  • [C-0-6] Użytkownik MUSI mieć możliwość globalnego zastąpienia domyślnego działania linków do aplikacji, aby aplikacja mogła: zawsze otwierać, zawsze pytać lub nigdy nie otwierać, co musi dotyczyć wszystkich kandydatów do filtrów intencji URI w równym stopniu.
  • [C-0-7] Użytkownik MUSI mieć możliwość wyświetlenia listy filtrów intencji kandydującego URI.
  • Implementacja urządzenia MOŻE umożliwiać użytkownikowi zastępowanie poszczególnych filtrów intencji URI kandydatów, które zostały pomyślnie zweryfikowane.
  • [C-0-8] Urządzenie MUSI umożliwiać użytkownikom wyświetlanie i zastępowanie konkretnych filtrów intencji URI kandydatów, jeśli implementacja urządzenia pozwala na pomyślne przejście weryfikacji przez niektóre filtry intencji URI kandydatów, a inne mogą nie przejść weryfikacji.

3.2.3.3. Przestrzenie nazw intencji

• [C-0-1] Implementacje urządzeń NIE MOGĄ zawierać żadnego komponentu Androida, który obsługuje nowe wzorce intencji lub intencji rozgłaszanych przy użyciu ACTION, CATEGORY lub innego kluczowego ciągu znaków w przestrzeni nazw android.* lub com.android.*.
• [C-0-2] Producenci urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub intencji rozgłaszania za pomocą ciągu ACTION, CATEGORY lub innego kluczowego ciągu w przestrzeni pakietu należącej do innej organizacji.
• [C-0-3] Twórcy urządzeń NIE MOGĄ zmieniać ani rozszerzać żadnych wzorców intencji wymienionych w sekcji 3.2.3.1.
• Implementacje urządzeń MOGĄ zawierać wzorce intencji korzystające z przestrzeni nazw wyraźnie i oczywiście powiązanych z ich własną organizacją. Ten zakaz jest analogiczny do zakazu określonego w artykule 3.6 w przypadku klas języka Java.

3.2.3.4. Intencje transmisji

Aplikacje innych firm korzystają z platformy, aby rozgłaszać określone intencje, które powiadamiają je o zmianach w środowisku sprzętowym lub programowym.

Implementacje urządzeń:

• [C-0-1] MUSI rozgłaszać publiczne intencje rozgłaszania wymienione tutaj w odpowiedzi na odpowiednie zdarzenia systemowe zgodnie z opisem w dokumentacji pakietu SDK. Pamiętaj, że to wymaganie nie jest sprzeczne z sekcją 3.5, ponieważ ograniczenia dotyczące aplikacji działających w tle są również opisane w dokumentacji pakietu SDK. Niektóre intencje transmisji zależą też od obsługi sprzętowej. Jeśli urządzenie obsługuje wymagany sprzęt, MUSI transmitować intencje i zapewniać działanie zgodne z dokumentacją pakietu SDK.

3.2.3.5. Intencje warunkowe aplikacji

Android ma ustawienia, które ułatwiają użytkownikom wybieranie domyślnych aplikacji, np. na ekranie głównym lub do SMS-ów.

W odpowiednich przypadkach implementacje urządzeń MUSZĄ udostępniać podobne menu ustawień i być zgodne z wzorcem filtra intencji oraz metodami interfejsu API opisanymi w dokumentacji pakietu SDK, jak poniżej.

Jeśli implementacje urządzeń zgłaszają android.software.home_screen, to:

• [C-1-1] MUSI uwzględniać android.settings.HOME_SETTINGS zamiar wyświetlenia domyślnego menu ustawień aplikacji na ekranie głównym.

Jeśli implementacje urządzeń zgłaszają android.hardware.telephony.calling, to:

• [C-2-1] MUSI udostępniać menu ustawień, które wywoła intencję android.provider.Telephony.ACTION_CHANGE_DEFAULT, aby wyświetlić okno umożliwiające zmianę domyślnej aplikacji do SMS-ów.

• [C-2-2] MUSI uwzględniać android.telecom.action.CHANGE_DEFAULT_DIALER zamiar wyświetlenia okna dialogowego, które umożliwi użytkownikowi zmianę domyślnej aplikacji Telefon.

  • MUSI używać interfejsu wybranej przez użytkownika domyślnej aplikacji Telefon do połączeń przychodzących i wychodzących, z wyjątkiem połączeń alarmowych, które będą korzystać z zainstalowanej fabrycznie aplikacji Telefon.

• [C-2-3] MUSI obsługiwać intencję android.telecom.action.CHANGE_PHONE_ACCOUNTS, aby umożliwić użytkownikowi skonfigurowanie ConnectionServices powiązanego z PhoneAccounts, a także domyślnego konta PhoneAccount, którego dostawca usług telekomunikacyjnych będzie używać do wykonywania połączeń wychodzących. Implementacja AOSP spełnia to wymaganie, ponieważ w menu ustawień „Połączenia” znajduje się menu „Konta połączeń”.

• [C-2-4] MUSI zezwalać na android.telecom.CallRedirectionService w przypadku aplikacji, która ma rolę android.app.role.CALL_REDIRECTION.

• [C-2-5] MUSI udostępniać użytkownikowi możliwość wyboru aplikacji, która pełni rolę android.app.role.CALL_REDIRECTION.

• [C-2-6] MUSI obsługiwać intencje android.intent.action.SENDTO i android.intent.action.VIEW oraz udostępniać aktywność do wysyłania i wyświetlania SMS-ów.

• [C-SR-1] Zdecydowanie zaleca się obsługę intencji android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW i android.intent.action.DIAL za pomocą wstępnie załadowanej aplikacji do wybierania numerów, która może obsługiwać te intencje i zapewniać realizację zgodnie z opisem w pakiecie SDK.

Jeśli implementacje urządzeń zgłaszają android.hardware.nfc.hce, to:

• [C-3-1] MUSI obsługiwać intencję android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlać menu ustawień domyślnej aplikacji do płatności zbliżeniowych.
• [C-3-2] MUSI obsługiwać intencję android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT w celu wyświetlenia aktywności, która otwiera okno z prośbą o zmianę domyślnej usługi emulacji karty w określonej kategorii zgodnie z opisem w pakiecie SDK.

Jeśli implementacje urządzeń zgłaszają android.hardware.nfc, to:

• [C-4-1] MUSI obsługiwać te intencje: android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED i android.nfc.action.TECH_DISCOVERED, aby wyświetlać działanie, które spełnia oczekiwania programistów dotyczące tych intencji, zgodnie z opisem w pakiecie SDK.

Jeśli implementacje urządzeń zgłaszają android.hardware.bluetooth, to:

• [C-5-1] MUSI obsługiwać intencję „android.bluetooth.adapter.action.REQUEST_ENABLE” i wyświetlać aktywność systemową, aby umożliwić użytkownikowi włączenie Bluetootha.
• [C-5-2] MUSI obsługiwać intencję 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' i wyświetlać działanie systemu, które żąda trybu wykrywalności.

Jeśli implementacje urządzeń obsługują funkcję Nie przeszkadzać:

• [C-6-1] MUSI implementować aktywność, która odpowiada na intencję ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, w przypadku implementacji z UI_MODE_TYPE_NORMAL MUSI to być aktywność, w której użytkownik może przyznać lub odmówić aplikacji dostępu do konfiguracji zasad „Nie przeszkadzać”.

Jeśli implementacje urządzeń umożliwiają użytkownikom korzystanie na urządzeniu z metod wprowadzania innych firm:

• [C-7-1] MUSI udostępniać mechanizm dostępny dla użytkownika, który umożliwia dodawanie i konfigurowanie metod wprowadzania innych firm w odpowiedzi na intencję android.settings.INPUT_METHOD_SETTINGS.

Jeśli implementacje urządzeń obsługują usługi ułatwień dostępu innych firm:

• [C-8-1] MUSI uwzględniać android.settings.ACCESSIBILITY_SETTINGS zamiar udostępnienia użytkownikowi mechanizmu umożliwiającego włączanie i wyłączanie usług ułatwień dostępu innych firm wraz z wstępnie załadowanymi usługami ułatwień dostępu.

Jeśli implementacje urządzeń obsługują Wi-Fi Easy Connect i udostępniają tę funkcję aplikacjom innych firm:

• [C-9-1] MUSI implementować interfejsy API intencji Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI zgodnie z opisem w dokumentacji pakietu SDK.

Jeśli implementacje urządzeń udostępniają tryb oszczędzania danych:

• [C-10-1] MUSI udostępniać w ustawieniach interfejs, który obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, umożliwiając użytkownikom dodawanie aplikacji do listy dozwolonych i usuwanie ich z niej.

Jeśli implementacje urządzeń nie udostępniają trybu oszczędzania danych:

• [C-11-1] MUSI mieć aktywność, która obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS , ale MOŻE ją zaimplementować jako operację bez efektu.

Jeśli implementacje urządzeń deklarują obsługę kamery za pomocą android.hardware.camera.any, to:

• [C-12-3] MUSI obsługiwać te intencje i MUSI zezwalać na ich obsługę tylko preinstalowanym aplikacjom na Androida: MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE i MediaStore.ACTION_VIDEO_CAPTURE zgodnie z opisem w dokumencie SDK.

Jeśli implementacje urządzeń zgłaszają android.software.device_admin, to:

• [C-13-1] MUSI uwzględniać intencję android.app.action.ADD_DEVICE_ADMIN wywołania interfejsu, aby umożliwić użytkownikowi dodanie administratora urządzenia do systemu (lub odrzucenie tej możliwości).

• [C-13-2] MUSI obsługiwać intencje android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD i android.app.action.START_ENCRYPTION oraz mieć aktywność, która realizuje te intencje zgodnie z opisem w pakiecie SDK tutaj.

Jeśli implementacje urządzeń deklarują flagę funkcji android.software.autofill, to:

• [C-14-1] MUSI w pełni implementować interfejsy API AutofillService i AutofillManager oraz obsługiwać intencję android.settings.REQUEST_SET_AUTOFILL_SERVICE, aby wyświetlać domyślne menu ustawień aplikacji umożliwiające włączanie i wyłączanie autouzupełniania oraz zmianę domyślnej usługi autouzupełniania dla użytkownika.

Jeśli implementacje urządzeń obejmują wstępnie zainstalowaną aplikację lub chcą zezwolić aplikacjom innych firm na dostęp do statystyk użytkowania:

• [C-SR-2] Zdecydowanie zalecamy, aby aplikacje deklarujące uprawnienie android.permission.PACKAGE_USAGE_STATS udostępniały użytkownikom mechanizm przyznawania lub odbierania dostępu do statystyk użytkowania w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Jeśli implementacje urządzeń mają uniemożliwiać dostęp do statystyk użycia dowolnym aplikacjom, w tym wstępnie zainstalowanym:

• [C-15-1] MUSI nadal mieć aktywność, która obsługuje wzorzec intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale MUSI implementować go jako operację bez efektu, czyli zachowywać się tak, jakby użytkownik odmówił dostępu.

Jeśli implementacje urządzeń udostępniają linki do aktywności określonych przez AutofillService_passwordsActivity w Ustawieniach lub linki do haseł użytkownika za pomocą podobnego mechanizmu:

• [C-16-1] MUSI wyświetlać takie linki w przypadku wszystkich zainstalowanych usług autouzupełniania.

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

• [C-18-1] MUSI uwzględniać intencję android.settings.ACTION_VOICE_INPUT_SETTINGS wyświetlania domyślnego menu ustawień aplikacji do głosowego wprowadzania tekstu i asystowania.

Jeśli implementacje urządzeń zgłaszają funkcję android.hardware.audio.output, to:

• [C-SR-3] Zdecydowanie zaleca się, aby intencje android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA i android.speech.tts.engine.GET_SAMPLE_TEXT miały aktywność, która zapewnia realizację tych intencji w sposób opisany w zestawie SDK tutaj.

Android obsługuje interaktywne wygaszacze ekranu, które wcześniej były nazywane snami. Wygaszacze ekranu umożliwiają użytkownikom interakcję z aplikacjami, gdy urządzenie podłączone do źródła zasilania jest bezczynne lub zadokowane na biurku. Implementacje urządzeń:

• POWINNO obejmować obsługę wygaszaczy ekranu i zapewniać opcję ustawień, która umożliwia użytkownikom konfigurowanie wygaszaczy ekranu w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

Jeśli implementacje urządzeń zgłaszają android.hardware.nfc.uicc lub android.hardware.nfc.ese, to:

• [C-19-1] MUSI implementować interfejs API intencji NfcAdapter.ACTION_TRANSACTION_DETECTED (zdefiniowany jako „EVT_TRANSACTION” w specyfikacji technicznej GSM Association TS.26 – wymagania dotyczące telefonów komórkowych z NFC).

3.2.4. Aktywności na dodatkowych/wielu wyświetlaczach

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych aktywności Androida na więcej niż jednym wyświetlaczu:

• [C-1-1] MUSI ustawić flagę funkcji android.software.activities_on_secondary_displays.
• [C-1-2] MUSI gwarantować zgodność interfejsu API podobną do zgodności działania uruchomionego na wyświetlaczu głównym.
• [C-1-3] MUSI wyświetlać nowe działanie na tym samym ekranie co działanie, które je uruchomiło, gdy nowe działanie jest uruchamiane bez określania ekranu docelowego za pomocą interfejsu ActivityOptions.setLaunchDisplayId().
• [C-1-4] MUSI usuwać wszystkie aktywności, gdy wyświetlacz z flagą Display.FLAG_PRIVATE zostanie usunięty.
• [C-1-5] MUSI bezpiecznie ukrywać treści na wszystkich ekranach, gdy urządzenie jest zablokowane za pomocą bezpiecznego ekranu blokady, chyba że aplikacja zdecyduje się na wyświetlanie na ekranie blokady za pomocą interfejsu Activity#setShowWhenLocked().
• POWINIEN mieć android.content.res.Configuration, który odpowiada temu wyświetlaczowi, aby można było go wyświetlać, prawidłowo obsługiwać i zachować zgodność, jeśli na wyświetlaczu dodatkowym zostanie uruchomiona aktywność.

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych aktywności Androida na dodatkowych wyświetlaczach, a dodatkowy wyświetlacz ma flagę android.view.Display.FLAG_PRIVATE:

• [C-3-1] Tylko właściciel wyświetlacza, systemu i aktywności, które są już na tym wyświetlaczu, MUSI mieć możliwość uruchomienia ich na tym wyświetlaczu. Każdy może uruchomić aplikację na ekranie z flagą android.view.Display.FLAG_PUBLIC.

3.3. Zgodność z natywnym interfejsem API

Zgodność kodu natywnego jest trudna. Z tego powodu producenci urządzeń:

• [C-SR-1] ZDECYDOWANIE ZALECA się korzystanie z implementacji bibliotek wymienionych poniżej z projektu Android Open Source Project.

3.3.1. Interfejsy binarne aplikacji

Zarządzany kod bajtowy Dalvik może wywoływać kod natywny dostarczony w pliku .apk aplikacji jako plik ELF .so skompilowany dla odpowiedniej architektury sprzętowej urządzenia. Kod natywny jest w dużym stopniu zależny od technologii procesora, dlatego w Android NDK zdefiniowano kilka interfejsów binarnych aplikacji (ABI).

Implementacje urządzeń:

• [C-0-1] MUSI być zgodna z co najmniej jednym zdefiniowanym interfejsem ABI Android NDK.
• [C-0-2] MUSI obsługiwać wywoływanie kodu natywnego przez kod działający w środowisku zarządzanym przy użyciu standardowej semantyki Java Native Interface (JNI).
• [C-0-3] MUSI być zgodna ze źródłem (tzn. zgodna z nagłówkiem) i binarnie (w przypadku interfejsu ABI) z każdą wymaganą biblioteką z poniższej listy.

• [C-0-5] MUSI dokładnie raportować natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pomocą parametrów android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS i android.os.Build.SUPPORTED_64_BIT_ABIS. Każdy z nich to rozdzielona przecinkami lista interfejsów ABI uporządkowana od najbardziej do najmniej preferowanego.

• [C-0-6] MUSI raportować za pomocą powyższych parametrów podzbiór poniższej listy interfejsów ABI i NIE MOŻE raportować żadnego interfejsu ABI, którego nie ma na liście.

  • armeabi (nie jest już obsługiwany jako cel przez NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64
  • riscv64

• [C-0-7] MUSI udostępniać aplikacjom zawierającym kod natywny wszystkie te biblioteki z natywnymi interfejsami API:

  • libaaudio.so (natywna obsługa dźwięku AAudio)
  • libamidi.so (natywna obsługa MIDI, jeśli funkcja android.software.midi jest zadeklarowana zgodnie z opisem w sekcji 5.9)
  • libandroid.so (obsługa natywnej aktywności Androida)
  • libc (biblioteka C)
  • libcamera2ndk.so
  • libdl (dynamic linker)
  • libEGL.so (natywne zarządzanie powierzchnią OpenGL)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (logowanie w Androidzie)
  • libmediandk.so (obsługa natywnych interfejsów API multimediów)
  • libm (biblioteka matematyczna)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (obsługa OpenMAX AL 1.0.1)
  • libOpenSLES.so (obsługa dźwięku OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (minimalna obsługa C++)
  • libvulkan.so (Vulkan)
  • libz (kompresja Zlib)
  • Interfejs JNI

• [C-0-8] NIE WOLNO dodawać ani usuwać funkcji publicznych w przypadku wymienionych powyżej bibliotek natywnych.

• [C-0-9] MUSI zawierać listę dodatkowych bibliotek innych niż AOSP udostępnianych bezpośrednio aplikacjom innych firm w /vendor/etc/public.libraries.txt.

• [C-0-10] NIE WOLNO udostępniać żadnych innych bibliotek natywnych zaimplementowanych i udostępnianych w AOSP jako biblioteki systemowe aplikacjom innych firm kierowanym na interfejs API na poziomie 24 lub wyższym, ponieważ są one zarezerwowane.

• [C-0-11] MUSI eksportować wszystkie symbole funkcji OpenGL ES 3.1 i Android Extension Pack, zdefiniowane w NDK, za pomocą biblioteki libGLESv3.so. Pamiętaj, że wszystkie symbole MUSZĄ być obecne, ale w sekcji 7.1.4.1 opisano bardziej szczegółowo wymagania dotyczące pełnego wdrożenia poszczególnych funkcji.

• [C-0-12] MUSI eksportować symbole funkcji dla podstawowych symboli funkcji Vulkan 1.1, a także rozszerzeń VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 i VK_KHR_get_physical_device_properties2 za pomocą biblioteki libvulkan.so. Pamiętaj, że wszystkie symbole MUSZĄ być obecne, a w sekcji 7.1.4.2 znajdziesz szczegółowe wymagania dotyczące tego, kiedy oczekiwane jest pełne wdrożenie poszczególnych funkcji.

• POWINIEN być zbudowany przy użyciu kodu źródłowego i plików nagłówkowych dostępnych w projekcie Android Open Source Project.

Pamiętaj, że w przyszłych wersjach Androida może zostać wprowadzona obsługa dodatkowych interfejsów ABI.

3.3.2. Zgodność z 32-bitowym kodem natywnym ARM

Jeśli implementacje urządzeń zgłaszają obsługę interfejsu armeabi ABI:

• [C-3-1] MUSI też obsługiwać armeabi-v7a i zgłaszać tę obsługę, ponieważ armeabi służy tylko do zapewnienia zgodności wstecznej ze starszymi aplikacjami.

Jeśli implementacje urządzeń zgłaszają obsługę interfejsu armeabi-v7a ABI, w przypadku aplikacji korzystających z tego interfejsu:

• [C-2-1] MUSI zawierać w /proc/cpuinfo te wiersze i NIE POWINIEN zmieniać wartości na tym samym urządzeniu, nawet jeśli są one odczytywane przez inne interfejsy ABI.

  • Features:, a następnie lista opcjonalnych funkcji procesora ARMv7 obsługiwanych przez urządzenie.
  • CPU architecture:, a następnie liczba całkowita opisująca najwyższą obsługiwaną architekturę ARM urządzenia (np. „8” w przypadku urządzeń z architekturą ARMv8).

• [C-2-2] MUSI zawsze udostępniać te operacje, nawet jeśli interfejs ABI jest zaimplementowany na architekturze ARMv8, za pomocą natywnej obsługi procesora lub emulacji oprogramowania:

  • Instrukcje dotyczące SWP i SWPB.
  • operacje barierowe CP15ISB, CP15DSB i CP15DMB;

• [C-2-3] MUSI obsługiwać rozszerzenie Advanced SIMD (znane też jako NEON).

3.4. Zgodność z internetem

3.4.1. Zgodność z WebView

Jeśli implementacje urządzeń zapewniają pełną implementację interfejsu APIandroid.webkit.Webview, to:

• [C-1-1] MUSI raportować android.software.webview.

• [C-1-2] MUSI używać kompilacji projektu Chromium z projektu Android Open Source Project w wersji Android 17 do implementacji interfejsu API android.webkit.WebView.

• [C-1-3] Ciąg klienta użytkownika zgłaszany przez WebView w przypadku aplikacji zgodnych z pakietem SDK na poziomie 36 lub niższym MUSI mieć ten format:

  Mozilla/5.0 (Linux; Android $(VERSION); \[$(MODEL)\] \[Build/$(BUILD)\]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • Wartość ciągu znaków $(VERSION) MUSI być taka sama jak wartość android.os.Build.VERSION.RELEASE.

  • Ciąg znaków $(MODEL) MOŻE być pusty, ale jeśli nie jest pusty, MUSI mieć taką samą wartość jak android.os.Build.MODEL.

  • „Build/$(BUILD)” MOŻE zostać pominięty, ale jeśli występuje, ciąg $(BUILD) MUSI być taki sam jak wartość android.os.Build.ID.

  • Ciąg znaków $(CHROMIUM_VER) MUSI być wersją Chromium w projekcie Android Open Source Project.

  • Implementacje urządzeń MOGĄ pominąć ciąg znaków klienta użytkownika w przypadku urządzeń mobilnych.

• Komponent WebView POWINIEN obsługiwać jak najwięcej funkcji HTML5, a jeśli obsługuje daną funkcję, POWINIEN być zgodny ze specyfikacją HTML5.

• [C-1-4] MUSI renderować dostarczone treści lub treści z odległego adresu URL w procesie, który jest odrębny od aplikacji, która tworzy instancję WebView. W szczególności oddzielny proces renderowania MUSI mieć niższe uprawnienia, działać z oddzielnym identyfikatorem użytkownika, nie mieć dostępu do katalogu danych aplikacji, nie mieć bezpośredniego dostępu do sieci i mieć dostęp tylko do minimalnie wymaganych usług systemowych za pomocą interfejsu Binder. Implementacja WebView w AOSP spełnia to wymaganie.

3.4.2. Zgodność z przeglądarką

Jeśli implementacje urządzeń obejmują samodzielną aplikację przeglądarki do ogólnego przeglądania internetu, muszą:

• [C-1-1] MUSI obsługiwać każdy z tych interfejsów API powiązanych z HTML5:

  • pamięć podręczna aplikacji/działanie w trybie offline
  • Tag <video>
  • geolocation

• [C-1-2] MUSI obsługiwać interfejs webstorage API HTML5/W3C i POWINIEN obsługiwać interfejs IndexedDB API HTML5/W3C. Pamiętaj, że organizacje zajmujące się standardami tworzenia stron internetowych przechodzą na IndexedDB zamiast webstorage, więc w przyszłej wersji Androida IndexedDB będzie prawdopodobnie wymaganym komponentem.

• MOŻE wysyłać niestandardowy ciąg znaków klienta użytkownika w samodzielnej aplikacji przeglądarki.

• POWINNA obsługiwać jak najwięcej funkcji HTML5 w samodzielnej aplikacji przeglądarki (niezależnie od tego, czy jest ona oparta na aplikacji przeglądarki WebKit, czy na zamienniku innej firmy).

Jeśli jednak implementacje urządzeń nie obejmują samodzielnej aplikacji przeglądarki, muszą:

• [C-2-1] MUSI nadal obsługiwać wzorce intencji publicznych zgodnie z opisem w sekcji 3.2.3.1.

3.5. Zgodność behawioralna interfejsu API

Implementacje urządzeń:

• [C-0-9] MUSI zapewnić, że zgodność behawioralna interfejsu API jest stosowana w przypadku wszystkich zainstalowanych aplikacji, chyba że są one ograniczone w sposób opisany w sekcji 3.5.1.
• [C-0-10] NIE WOLNO wdrażać podejścia opartego na liście dozwolonych, które zapewnia zgodność zachowania interfejsu API tylko w przypadku aplikacji wybranych przez producentów urządzeń.

Działanie każdego typu interfejsu API (zarządzanego, soft, natywnego i internetowego) musi być zgodne z preferowaną implementacją projektu Android Open Source Project. Oto niektóre obszary zgodności:

• [C-0-1] Urządzenia NIE MOGĄ zmieniać działania ani semantyki standardowego zamiaru.
• [C-0-2] Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (np. usługi, aktywności, dostawcy treści itp.).
• [C-0-3] Urządzenia NIE MOGĄ zmieniać semantyki standardowego uprawnienia.
• Urządzenia NIE MOGĄ zmieniać ograniczeń wymuszanych w przypadku aplikacji działających w tle. W przypadku aplikacji działających w tle:
  • [C-0-4] MUSZĄ przestać wykonywać wywołania zwrotne zarejestrowane przez aplikację w celu otrzymywania danych wyjściowych z GnssMeasurement i GnssNavigationMessage.
  • [C-0-5] MUSZĄ ograniczać częstotliwość aktualizacji przekazywanych do aplikacji za pomocą klasy interfejsu API LocationManager lub metody WifiManager.startScan().
  • [C-0-6] Jeśli aplikacja jest kierowana na interfejs API w wersji 25 lub nowszej, NIE MOŻE zezwalać na rejestrowanie odbiorników transmisji w przypadku niejawnych transmisji standardowych intencji Androida w pliku manifestu aplikacji, chyba że intencja transmisji wymaga uprawnienia "signature" lub "signatureOrSystem" protectionLevel lub znajduje się na liście wyłączeń.
  • [C-0-7] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zatrzymać usługi działające w tle, tak jakby wywołała metodę stopSelf() tych usług, chyba że aplikacja znajduje się na tymczasowej liście dozwolonych, aby wykonać zadanie widoczne dla użytkownika.
  • [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zwalniać blokady wybudzania, które utrzymuje.
• [C-0-11] Urządzenia MUSZĄ zwracać tych dostawców zabezpieczeń jako pierwsze 7 wartości tablicy z metody Security.getProviders() w podanej kolejności i z podanymi nazwami (zwracanymi przez Provider.getName()) i klasami, chyba że aplikacja zmodyfikowała listę za pomocą insertProviderAt() lub removeProvider(). Urządzenia MOGĄ zwracać dodatkowych dostawców po określonej liście dostawców poniżej.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

Powyższa lista nie jest wyczerpująca. Pakiet testów zgodności (CTS) sprawdza zgodność zachowania znacznej części platformy, ale nie całej. Obowiązkiem osoby wdrażającej jest zapewnienie zgodności zachowania z projektem Android Open Source. Z tego powodu producenci urządzeń POWINNI w miarę możliwości korzystać z kodu źródłowego dostępnego w ramach projektu Android Open Source Project, zamiast ponownie implementować znaczną część systemu.

3.5.1. Ograniczenie aplikacji

Jeśli implementacje urządzeń wdrażają mechanizm zastrzeżony, który ogranicza aplikacje (np. zmienia lub ogranicza zachowania interfejsu API opisane w pakiecie SDK), a ten mechanizm jest bardziej restrykcyjny niż ograniczony zasobnik czuwania aplikacji, to:

• [C-1-1] MUSI umożliwiać użytkownikowi wyświetlanie listy aplikacji z ograniczeniami.
• [C-1-2] MUSI umożliwiać użytkownikowi włączanie i wyłączanie wszystkich tych ograniczeń własności w przypadku każdej aplikacji.

• [C-1-3] NIE WOLNO automatycznie stosować tych zastrzeżonych ograniczeń bez dowodu na nieprawidłowe działanie systemu, ale MOŻNA stosować ograniczenia w przypadku aplikacji po wykryciu nieprawidłowego działania systemu, takiego jak zablokowane wybudzenia, długo działające usługi i inne kryteria. Kryteria MOGĄ być określane przez producentów urządzeń, ale MUSZĄ być związane z wpływem aplikacji na stan systemu. Inne kryteria, które nie są ściśle związane ze stanem systemu, takie jak brak popularności aplikacji na rynku, NIE MOGĄ być używane jako kryteria.

• [C-1-4] NIE MOŻE automatycznie stosować tych ograniczeń własności w przypadku aplikacji, gdy użytkownik ręcznie wyłączył ograniczenia aplikacji, i MOŻE sugerować użytkownikowi zastosowanie tych ograniczeń własności.

• [C-1-5] MUSI informować użytkowników, jeśli te zastrzeżone ograniczenia są automatycznie stosowane w przypadku aplikacji. Takie informacje MUSZĄ być podane w ciągu 24 godzin przed zastosowaniem tych zastrzeżonych ograniczeń.

• [C-1-6] MUSI zwracać wartość true w przypadku wywołań interfejsu API z aplikacji w metodzie ActivityManager.isBackgroundRestricted().

• [C-1-7] NIE MOŻE ograniczać działania aplikacji na pierwszym planie, która jest wyraźnie używana przez użytkownika.

• [C-1-8] MUSI zawiesić te zastrzeżone ograniczenia w aplikacji, gdy użytkownik zacznie z niej korzystać, co spowoduje, że stanie się ona aplikacją na pierwszym planie.

• [C-1-10] MUSI udostępniać publiczny i jasny dokument lub witrynę, w których opisano sposób stosowania ograniczeń wynikających z praw własności. Ten dokument lub strona internetowa MUSI zawierać linki do dokumentów pakietu Android SDK i MUSI zawierać:

  • Warunki wywołujące ograniczenia zastrzeżone.
  • Co i jak można ograniczyć w aplikacji.
  • Jak aplikacja może zostać zwolniona z takich ograniczeń.
  • Jak aplikacja może poprosić o wyjątek od zastrzeżonych ograniczeń, jeśli obsługuje taki wyjątek w przypadku aplikacji, które użytkownik może zainstalować.

Jeśli aplikacja jest fabrycznie zainstalowana na urządzeniu i nigdy nie była używana przez użytkownika przez ponad 30 dni, wyłączenia [C-1-3] [C-1-5] nie mają zastosowania.

Jeśli implementacje urządzeń rozszerzają ograniczenia aplikacji zaimplementowane w AOSP:

• [C-2-1]MUSI postępować zgodnie z implementacją opisaną w tym dokumencie.

3.5.2. Hibernacja aplikacji

Jeśli implementacje urządzeń obejmują hibernację aplikacji, która jest częścią AOSP lub rozszerza funkcję zawartą w AOSP, to:

• [C-1-1] MUSI spełniać wszystkie wymagania w sekcji 3.5.1 z wyjątkiem [C-1-6] i [C-1-3].
• [C-1-2] MUSI stosować ograniczenia w przypadku aplikacji użytkownika tylko wtedy, gdy istnieją dowody na to, że użytkownik nie korzystał z aplikacji przez pewien czas. Zdecydowanie zalecamy, aby ten okres trwał co najmniej miesiąc. Użycie MUSI być zdefiniowane przez wyraźną interakcję użytkownika za pomocą interfejsu API UsageStats#getLastTimeVisible() lub przez dowolne działanie, które spowoduje opuszczenie przez aplikację stanu wymuszonego zatrzymania, w tym powiązania usług, powiązania dostawców treści, wyraźne transmisje itp., które będą śledzone przez nowy interfejs API UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] MUSI stosować ograniczenia wpływające na wszystkich użytkowników urządzenia tylko wtedy, gdy istnieją dowody na to, że pakiet nie był używany przez ŻADNEGO użytkownika przez pewien okres. Zdecydowanie zalecamy, aby ten okres trwał co najmniej miesiąc.
• [C-1-4] NIE MOŻE powodować, że aplikacja nie będzie w stanie odpowiadać na intencje aktywności, powiązania usług, żądania dostawcy treści ani jawne transmisje.

Funkcja hibernacji aplikacji w AOSP spełnia powyższe wymagania.

3.6. Przestrzenie nazw interfejsów API

Android przestrzega konwencji przestrzeni nazw pakietów i klas zdefiniowanych przez język programowania Java. Aby zapewnić zgodność z aplikacjami innych firm, producenci urządzeń NIE MOGĄ wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w tych przestrzeniach nazw pakietów:

• java.*
• javax.*
• sun.*
• android.*
• androidx.*
• com.android.*

Oznacza to, że:

• [C-0-1] NIE WOLNO modyfikować publicznie udostępnianych interfejsów API na platformie Androida, zmieniając sygnatury metod lub klas ani usuwając klas lub pól klas.
• [C-0-2] NIE WOLNO dodawać żadnych publicznie dostępnych elementów (takich jak klasy lub interfejsy, pola lub metody do istniejących klas lub interfejsów) ani interfejsów API Test lub System do interfejsów API w przestrzeniach nazw wymienionych powyżej. „Publicznie udostępniony element” to dowolna konstrukcja, która nie jest oznaczona markerem „@hide” używanym w źródłowym kodzie Androida.

Producenci urządzeń MOGĄ modyfikować implementację interfejsów API, ale takie modyfikacje:

• [C-0-3] NIE MOŻE wpływać na deklarowane działanie ani sygnaturę w języku Java żadnych publicznie udostępnianych interfejsów API.
• [C-0-4] NIE MOŻE być reklamowany ani w inny sposób udostępniany deweloperom.

Producenci urządzeń MOGĄ jednak dodawać niestandardowe interfejsy API poza standardową przestrzenią nazw Androida, ale te interfejsy:

• [C-0-5] NIE MOŻE znajdować się w przestrzeni nazw należącej do innej organizacji lub do niej odsyłającej. Na przykład producenci urządzeń NIE MOGĄ dodawać interfejsów API do przestrzeni nazw com.google.* ani podobnych: może to robić tylko Google. Podobnie Google NIE MOŻE dodawać interfejsów API do przestrzeni nazw innych firm.
• [C-0-6] MUSI być spakowany w postaci biblioteki współdzielonej Androida, aby tylko aplikacje, które wyraźnie z niej korzystają (za pomocą mechanizmu <uses-library>), były narażone na zwiększone wykorzystanie pamięci przez takie interfejsy API.

Producenci urządzeń MOGĄ dodawać niestandardowe interfejsy API w językach natywnych, poza interfejsami API NDK, ale te niestandardowe interfejsy API:

• [C-1-1] NIE MOŻE znajdować się w bibliotece NDK ani w bibliotece należącej do innej organizacji, zgodnie z opisem tutaj.

Jeśli producent urządzenia zaproponuje ulepszenie jednej z powyższych przestrzeni nazw pakietów (np. przez dodanie przydatnej nowej funkcji do istniejącego interfejsu API lub dodanie nowego interfejsu API), powinien odwiedzić stronę source.android.com i rozpocząć proces wprowadzania zmian i kodu zgodnie z informacjami na tej stronie.

Pamiętaj, że powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java. Ta sekcja ma jedynie na celu utrwalenie tych konwencji i uczynienie ich wiążącymi poprzez włączenie ich do tej Definicji zgodności.

3.7. Zgodność środowiska wykonawczego

Implementacje urządzeń:

• [C-0-1] MUSI obsługiwać pełny format pliku wykonywalnego Dalvik (DEX) oraz specyfikację i semantykę kodu bajtowego Dalvik.

• [C-0-2] MUSI skonfigurować środowiska wykonawcze Dalvik tak, aby przydzielały pamięć zgodnie z platformą Android i zgodnie z tabelą poniżej. (Definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).

• POWINIEN używać środowiska wykonawczego Androida (ART), referencyjnej implementacji formatu wykonywalnego Dalvik i referencyjnego systemu zarządzania pakietami.

• POWINIEN przeprowadzać testy fuzzing w różnych trybach wykonywania i na różnych architekturach docelowych, aby zapewnić stabilność środowiska wykonawczego. Więcej informacji znajdziesz na stronach JFuzz i DexFuzz w witrynie Projekt Android Open Source.

Pamiętaj, że podane poniżej wartości pamięci są uważane za minimalne, a implementacje urządzeń MOGĄ przydzielać więcej pamięci na aplikację.

Układ ekranu	Gęstość ekranu	Minimalna ilość pamięci aplikacji
Android Watch	120 dpi (ldpi)	32 MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)
	200 dpi
	213 dpi (tvdpi)
	220 dpi (220 dpi)	36 MB
	240 dpi (hdpi)
	280 dpi (280 dpi)
	320 dpi (xhdpi)	48 MB
	360 dpi (360 dpi)
	400 dpi (400dpi)	56 MB
	420 dpi (420 dpi)	64 MB
	480 dpi (xxhdpi)	88 MB
	560 dpi (560dpi)	112 MB
	640 dpi (xxxhdpi)	154 MB
mały/normalny	120 dpi (ldpi)	32 MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48 MB
	200 dpi
	213 dpi (tvdpi)
	220 dpi (220 dpi)
	240 dpi (hdpi)
	280 dpi (280 dpi)
	320 dpi (xhdpi)	80 MB
	360 dpi (360 dpi)
	400 dpi (400dpi)	96 MB
	420 dpi (420 dpi)	112 MB
	480 dpi (xxhdpi)	128 MB
	560 dpi (560dpi)	192 MB
	640 dpi (xxxhdpi)	256 MB
duża	120 dpi (ldpi)	32 MB
	140 dpi (140dpi)	48 MB
	160 dpi (mdpi)
	180 dpi (180dpi)	80 MB
	200 dpi
	213 dpi (tvdpi)
	220 dpi (220 dpi)
	240 dpi (hdpi)
	280 dpi (280 dpi)	96 MB
	320 dpi (xhdpi)	128 MB
	360 dpi (360 dpi)	160 MB
	400 dpi (400dpi)	192 MB
	420 dpi (420 dpi)	228 MB
	480 dpi (xxhdpi)	256 MB
	560 dpi (560dpi)	384 MB
	640 dpi (xxxhdpi)	512 MB
bardzo duża	120 dpi (ldpi)	48 MB
	140 dpi (140dpi)	80 MB
	160 dpi (mdpi)
	180 dpi (180dpi)	96 MB
	200 dpi
	213 dpi (tvdpi)
	220 dpi (220 dpi)
	240 dpi (hdpi)
	280 dpi (280 dpi)	144 MB
	320 dpi (xhdpi)	192 MB
	360 dpi (360 dpi)	240 MB
	400 dpi (400dpi)	288 MB
	420 dpi (420 dpi)	336 MB
	480 dpi (xxhdpi)	384 MB
	560 dpi (560dpi)	576 MB
	640 dpi (xxxhdpi)	768 MB

3.8. Zgodność interfejsu

3.8.1. Menu z aplikacjami (ekran główny)

Android zawiera aplikację uruchamiającą (ekran główny) i obsługuje aplikacje innych firm, które mogą zastąpić aplikację uruchamiającą urządzenia (ekran główny).

Jeśli implementacje urządzeń umożliwiają aplikacjom innych firm zastąpienie ekranu głównego urządzenia:

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.home_screen.

• [C-1-2] MUSI zwracać obiekt AdaptiveIconDrawable, gdy aplikacja innej firmy używa tagu <adaptive-icon> do udostępniania ikony i wywoływane są metody PackageManager do pobierania ikon.

Jeśli implementacje urządzeń obejmują domyślny program uruchamiający, który obsługuje przypinanie skrótów w aplikacji:

• [C-2-1] MUSI raportować true w przypadku ShortcutManager.isRequestPinShortcutSupported().

• [C-2-2] MUSI zawierać element interfejsu użytkownika, który przed dodaniem skrótu zażądanego przez aplikacje za pomocą metody interfejsu API ShortcutManager.requestPinShortcut() prosi użytkownika o potwierdzenie.

• [C-2-3] MUSI obsługiwać przypięte skróty oraz skróty dynamiczne i statyczne zgodnie z dokumentacją na stronie skrótów do aplikacji.

Z kolei jeśli implementacje urządzeń nie obsługują przypinania skrótów w aplikacji:

• [C-3-1] MUSI raportować wartość false w przypadku parametru ShortcutManager.isRequestPinShortcutSupported().

Jeśli implementacje urządzeń zawierają domyślny program uruchamiający, który zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu ShortcutManager API, to:

• [C-4-1] MUSI obsługiwać wszystkie udokumentowane funkcje skrótów (np. skróty statyczne i dynamiczne, przypinanie skrótów) oraz w pełni implementować interfejsy API klasy ShortcutManager.

Jeśli implementacje urządzeń zawierają domyślną aplikację uruchamiającą, która wyświetla etykietki przy ikonach aplikacji:

• [C-5-1] MUSI respektować metodę interfejsu API NotificationChannel.setShowBadge(). Innymi słowy, wyświetlaj wizualną afordancję powiązaną z ikoną aplikacji, jeśli wartość jest ustawiona jako true, i nie wyświetlaj żadnego schematu oznaczeń ikony aplikacji, gdy wszystkie kanały powiadomień aplikacji mają ustawioną wartość false.

• MOŻE zastępować plakietki ikon aplikacji własnym schematem plakietek, gdy aplikacje innych firm wskazują, że obsługują ten schemat, korzystając z zastrzeżonych interfejsów API, ale POWINNY używać zasobów i wartości udostępnianych przez interfejsy API plakietek powiadomień opisane w pakiecie SDK, takie jak interfejsy API Notification.Builder.setNumber() i Notification.Builder.setBadgeIconType().

Jeśli urządzenia obsługują monochromatyczne ikony, te ikony:

• [C-6-1] MUSI być używany tylko wtedy, gdy użytkownik wyraźnie go włączy (np. w menu Ustawienia lub w selektorze tapet).

3.8.2. Widżety

Android obsługuje widżety aplikacji innych firm, definiując typ komponentu oraz odpowiedni interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi „widżetu aplikacji”.

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

• MOŻE obsługiwać widżety aplikacji na ekranie blokady.

Jeśli implementacje urządzeń obsługują widżety aplikacji innych firm i przypinanie skrótów w aplikacji:

• [C-2-1] MUSI raportować true w przypadku AppWidgetManager.html.isRequestPinAppWidgetSupported().

• [C-2-2] MUSI zawierać element interfejsu, który przed dodaniem skrótu zażądanego przez aplikacje za pomocą metody interfejsu API AppWidgetManager.requestPinAppWidget() prosi użytkownika o potwierdzenie.

3.8.3. Powiadomienia

Android zawiera interfejsy API Notification i NotificationManager, które umożliwiają deweloperom aplikacji innych firm powiadamianie użytkowników o ważnych zdarzeniach i przyciąganie ich uwagi za pomocą komponentów sprzętowych (np. dźwięku, wibracji i światła) oraz funkcji oprogramowania (np. panelu powiadomień, paska systemowego) urządzenia.

3.8.3.1. Wyświetlanie powiadomień

Jeśli implementacje urządzeń umożliwiają aplikacjom innych firm powiadamianie użytkowników o ważnych wydarzeniach:

• [C-1-1] MUSI obsługiwać powiadomienia korzystające z funkcji sprzętowych zgodnie z opisem w dokumentacji pakietu SDK i w zakresie możliwości sprzętu urządzenia. Jeśli na przykład implementacja urządzenia zawiera wibrator, MUSI prawidłowo implementować interfejsy API wibracji. Jeśli implementacja urządzenia nie ma odpowiedniego sprzętu, odpowiednie interfejsy API MUSZĄ być zaimplementowane jako operacje bez efektu. Więcej informacji o tym znajdziesz w sekcji 7.

• [C-1-2] MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki animacji itp.) udostępnione w interfejsach API lub w przewodniku po stylu ikon paska stanu/systemowego, ale MOŻE zapewniać alternatywne wrażenia użytkownika w przypadku powiadomień niż te, które są dostępne w referencyjnej implementacji Androida Open Source.

• [C-1-3] MUSI prawidłowo obsługiwać i wdrażać zachowania opisane w interfejsach API do aktualizowania, usuwania i grupowania powiadomień.

• [C-1-4] MUSI udostępniać pełne działanie interfejsu API NotificationChannel udokumentowane w pakiecie SDK.

• [C-1-5] MUSI udostępniać użytkownikowi możliwość blokowania i modyfikowania powiadomień określonej aplikacji innej firmy na poziomie każdego kanału i pakietu aplikacji.

• [C-1-6] MUSI też udostępniać użytkownikowi możliwość wyświetlania usuniętych kanałów powiadomień.

• [C-1-7] MUSI prawidłowo renderować wszystkie zasoby (obrazy, naklejki, ikony itp.) dostarczone za pomocą Notification.MessagingStyle wraz z tekstem powiadomienia bez dodatkowej interakcji użytkownika. Na przykład MUSI wyświetlać wszystkie zasoby, w tym ikony udostępnione przez android.app.Person w rozmowie grupowej ustawionej za pomocą setGroupConversation.

• [C-SR-1] Zdecydowanie zaleca się udostępnienie użytkownikowi możliwości kontrolowania powiadomień, które są udostępniane aplikacjom, którym przyznano uprawnienia do nasłuchiwania powiadomień. Granularność MUSI być taka, aby użytkownik mógł określić, jakie typy powiadomień są przekazywane do każdego z tych odbiorników powiadomień. Typy MUSZĄ obejmować powiadomienia „rozmowy”, „alerty”, „ciche” i „ważne bieżące”.

• [C-SR-2] Zdecydowanie zalecamy udostępnienie użytkownikom możliwości określania aplikacji, które mają być wykluczone z powiadamiania dowolnego konkretnego odbiorcy powiadomień.

• [C-SR-3] Zdecydowanie zaleca się automatyczne wyświetlanie użytkownikowi afordancji zablokowania powiadomień określonej aplikacji innej firmy na poziomie poszczególnych kanałów i pakietów aplikacji po tym, jak użytkownik wielokrotnie odrzuci to powiadomienie.

• POWINIEN obsługiwać powiadomienia z elementami rozszerzonymi.

• POWINIEN wyświetlać niektóre powiadomienia o wyższym priorytecie jako powiadomienia z ostrzeżeniem.

• POWINNA mieć możliwość wyciszania powiadomień.

• Mogą one zarządzać widocznością i czasem, w którym aplikacje innych firm mogą powiadamiać użytkowników o istotnych zdarzeniach, aby ograniczyć problemy związane z bezpieczeństwem, takie jak rozproszenie uwagi kierowcy.

Android 11 wprowadza obsługę powiadomień o rozmowach, które korzystają z MessagingStyle i udostępniają opublikowany identyfikator skrótu People.

Implementacje urządzeń:

• [C-SR-4] Zdecydowanie zaleca się grupowanie i wyświetlanieconversation notifications przed powiadomieniami nie dotyczącymi rozmowy, z wyjątkiem powiadomień o usługach na pierwszym planie i powiadomień importance:high.

Jeśli implementacje urządzeń obsługują conversation notifications, a aplikacja udostępnia wymagane dane na potrzeby bubbles, to:

• [C-SR-5] Zdecydowanie zaleca się wyświetlanie tej rozmowy w formie dymku. Implementacja AOSP spełnia te wymagania w przypadku domyślnego interfejsu systemu, Ustawień i Launchera.

Jeśli implementacje urządzeń obsługują powiadomienia z elementami multimedialnymi:

• [C-2-1] W przypadku prezentowanych elementów zasobów MUSI używać dokładnych zasobów udostępnianych przez klasę interfejsu API Notification.Style i jej podklasy.

• POWINIEN prezentować wszystkie elementy zasobu (np. ikonę, tytuł i tekst podsumowania) zdefiniowane w klasie interfejsu API Notification.Style i jej podklasach.

Powiadomienia typu Heads Up to powiadomienia, które są wyświetlane użytkownikowi w miarę ich przychodzenia, niezależnie od tego, na jakim urządzeniu się znajduje. Jeśli implementacje urządzeń obsługują powiadomienia typu heads-up, to:

• [C-3-1] MUSI używać widoku i zasobów powiadomień typu heads-up zgodnie z opisem w klasie interfejsu API Notification.Builder, gdy wyświetlane są powiadomienia typu heads-up.

• [C-3-2] MUSI wyświetlać działania udostępniane przez Notification.Builder.addAction() wraz z treścią powiadomienia bez dodatkowej interakcji użytkownika, zgodnie z opisem w pakiecie SDK.

3.8.3.2. Usługa odbiornika powiadomień

Android zawiera interfejsy APINotificationListenerService, które umożliwiają aplikacjom (po wyraźnym włączeniu przez użytkownika) otrzymywanie kopii wszystkich powiadomień w momencie ich opublikowania lub zaktualizowania.

Implementacje urządzeń:

• [C-0-1] MUSI prawidłowo i niezwłocznie aktualizować powiadomienia w całości we wszystkich zainstalowanych i włączonych przez użytkownika usługach odbiorczych, w tym wszystkie metadane dołączone do obiektu powiadomienia.

• [C-0-2] MUSI reagować na wywołanie interfejsu API snoozeNotification(), zamykać powiadomienie i wywoływać funkcję zwrotną po upływie czasu odroczenia ustawionego w wywołaniu interfejsu API.

Jeśli implementacje urządzeń mają funkcję wyciszania powiadomień, to:

• [C-1-1] MUSI prawidłowo odzwierciedlać stan odłożonego powiadomienia za pomocą standardowych interfejsów API, takich jak NotificationListenerService.getSnoozedNotifications().

• [C-1-2] MUSI udostępniać użytkownikowi możliwość odroczenia powiadomień z każdej zainstalowanej aplikacji innej firmy, chyba że pochodzą one z usług działających na pierwszym planie lub usług trwałych.

3.8.3.3. Nie przeszkadzać / Tryb priorytetowy

Jeśli implementacje urządzeń obsługują funkcję Nie przeszkadzać (zwaną też trybem priorytetowym):

• [C-1-1] MUSI wyświetlać automatyczne reguły trybu „Nie przeszkadzać” utworzone przez aplikacje obok reguł utworzonych przez użytkownika i reguł predefiniowanych, jeśli implementacja urządzenia udostępnia użytkownikowi możliwość przyznawania lub odmawiania aplikacjom innych firm dostępu do konfiguracji zasad trybu „Nie przeszkadzać”.

• [C-1-3] MUSI uwzględniać wartości przekazywane w parametrach suppressedVisualEffects i NotificationManager.Policy. Jeśli aplikacja ustawiła którykolwiek z parametrów SUPPRESSED_EFFECT_SCREEN_OFF lub SUPPRESSED_EFFECT_SCREEN_ON, POWINNA poinformować użytkownika, że efekty wizualne są wyłączone w menu ustawień trybu „Nie przeszkadzać”.

3.8.3.4. Ochrona powiadomień poufnych

Informacje poufne w powiadomieniach obejmują treści takie jak hasła jednorazowe, jednorazowe kody potwierdzające i podobne kody uwierzytelniające lub resetujące, które mogą pojawiać się w powiadomieniach wysyłanych do użytkowników.

Jeśli implementacje urządzeń umożliwiają aplikacjom innych firm powiadamianie użytkowników o ważnych wydarzeniach:

• [C-1-1] MUSI usuwać informacje poufne z powiadomień przekazywanych do odbiorców powiadomień, chyba że usługa odbiorcy jest jedną z tych usług:

  • Aplikacje podpisane przez system z wartością uid < 10000
  • interfejs systemu
  • Muszla
  • Wyznaczona aplikacja na urządzenie towarzyszące (zdefiniowana przez CompanionDeviceManager)
  • SYSTEM_AUTOMOTIVE_PROJECTION rola
  • SYSTEM_NOTIFICATION_INTELLIGENCE rola
  • Rola HOME

Implementacja AOSPNotificationAssistantServices spełnia te wymagania. Przykład znajdziesz w sekcji android.ext.services.notification.

3.8.4. Interfejsy API Assist

Android zawiera interfejsy Assist API, które umożliwiają aplikacjom określanie, ile informacji o bieżącym kontekście jest udostępnianych asystentowi na urządzeniu.

• [C-2-2] Wyznaczona interakcja służąca do uruchamiania aplikacji asystującej opisana w sekcji 7.2.3 MUSI uruchamiać wybraną przez użytkownika aplikację asystującą, czyli aplikację, która implementuje VoiceInteractionService, lub działanie obsługujące intencję ACTION_ASSIST.

3.8.5. Alerty i wyskakujące powiadomienia

Aplikacje mogą używać interfejsu Toast do wyświetlania użytkownikowi krótkich ciągów znaków, które nie są modalne i znikają po krótkim czasie, oraz interfejsu TYPE_APPLICATION_OVERLAY do wyświetlania okien alertów jako nakładki na inne aplikacje.

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

• [C-1-1] MUSI udostępniać użytkownikowi możliwość blokowania wyświetlania przez aplikację okien alertów, które korzystają z TYPE_APPLICATION_OVERLAY. Implementacja AOSP spełnia to wymaganie, ponieważ elementy sterujące znajdują się w obszarze powiadomień.

• [C-1-2] MUSI obsługiwać interfejs Toast API i wyświetlać powiadomienia z aplikacji użytkownikom w widocznym miejscu.

3.8.6. Motywy

Android udostępnia „motywy” jako mechanizm, który umożliwia aplikacjom stosowanie stylów w całej aktywności lub aplikacji.

Android zawiera rodzinę motywów „Holo” i „Material” jako zestaw zdefiniowanych stylów, z których mogą korzystać deweloperzy aplikacji, jeśli chcą dopasować wygląd i działanie motywu Holo zdefiniowane w pakiecie Android SDK.

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

• [C-1-1] NIE WOLNO zmieniać żadnych atrybutów motywu Holo udostępnianych aplikacjom.

• [C-1-2] MUSI obsługiwać rodzinę motywów „Material” i NIE MOŻE zmieniać żadnych atrybutów motywu Material ani zasobów udostępnianych aplikacjom.

• [C-1-3] MUSI ustawić rodzinę czcionek „sans-serif” na Roboto w wersji 2.x w przypadku języków, które obsługuje Roboto, lub umożliwić użytkownikowi zmianę czcionki używanej w rodzinie czcionek „sans-serif” na Roboto w wersji 2.x w przypadku języków, które obsługuje Roboto.

• [C-1-4] MUSI generować palety odcieni dynamicznych kolorów zgodnie z dokumentacją AOSP Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (patrz android.theme.customization.system_palette i android.theme.customization.theme_style).

• [C-1-5] MUSI generować dynamiczne palety tonalne kolorów przy użyciu stylów motywów kolorystycznych wymienionych w Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGESdokumentacji (patrz android.theme.customization.theme_styles), a mianowicie TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD i MONOCHROMATIC.

  „Kolor źródłowy” używany do generowania dynamicznych palet kolorów tonalnych, gdy jest wysyłany z parametrem android.theme.customization.system_palette (zgodnie z dokumentacją w Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

• [C-1-6] MUSI mieć wartość chromatyczności CAM16 równą co najmniej 5.

  • POWINIEN być wyodrębniony z tapety za pomocą interfejsu API com.android.systemui.monet.ColorScheme#getSeedColors, który udostępnia wiele prawidłowych kolorów źródłowych, z których można wybrać jeden.

  • POWINIEN używać wartości 0xFF1B6EF3, jeśli żaden z podanych kolorów nie spełnia powyższego wymagania dotyczącego koloru źródłowego.

Android zawiera też rodzinę motywów „Domyślny motyw urządzenia” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i działanie aplikacji do motywu urządzenia zdefiniowanego przez producenta urządzenia.

• Implementacje urządzeń MOGĄ modyfikować atrybuty domyślnego motywu urządzenia udostępniane aplikacjom.

Android obsługuje wariant motywu z półprzezroczystymi paskami systemu, co umożliwia deweloperom aplikacji wypełnianie obszaru za paskiem stanu i paskiem nawigacyjnym treścią aplikacji. Aby zapewnić spójne wrażenia programistom w tej konfiguracji, ważne jest, aby styl ikony paska stanu był zachowany w różnych implementacjach na urządzeniach.

Jeśli implementacje urządzeń zawierają pasek stanu systemu:

• [C-2-1] MUSI używać białego koloru w przypadku ikon stanu systemu (takich jak siła sygnału i poziom baterii) oraz powiadomień wydawanych przez system, chyba że ikona wskazuje problematyczny stan lub aplikacja zażąda jasnego paska stanu za pomocą flagi WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.

• [C-2-2] Implementacje urządzeń z Androidem MUSZĄ zmieniać kolor ikon stanu systemu na czarny (szczegółowe informacje znajdziesz w R.style), gdy aplikacja zażąda jasnego paska stanu.

3.8.7. Animowane tapety

Android definiuje typ komponentu oraz odpowiedni interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi co najmniej 1 „tapety na żywo”. Tapety na żywo to animacje, wzory lub podobne obrazy o ograniczonych możliwościach interakcji, które wyświetlają się jako tapeta, za innymi aplikacjami.

Sprzęt jest uznawany za zdolny do niezawodnego uruchamiania animowanych tapet, jeśli może uruchamiać wszystkie animowane tapety bez ograniczeń funkcjonalności, z rozsądną liczbą klatek na sekundę i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują awarie tapet lub aplikacji, ich nieprawidłowe działanie, nadmierne zużycie procesora lub baterii albo działanie z nieakceptowalnie niską liczbą klatek na sekundę, uznaje się, że sprzęt nie jest w stanie obsługiwać animowanych tapet. Na przykład niektóre tapety na żywo mogą używać kontekstu OpenGL 2.0 lub 3.x do renderowania treści. Animowana tapeta nie będzie działać prawidłowo na urządzeniach, które nie obsługują wielu kontekstów OpenGL, ponieważ używanie kontekstu OpenGL przez animowaną tapetę może powodować konflikty z innymi aplikacjami, które również korzystają z kontekstu OpenGL.

• Urządzenia, które mogą niezawodnie obsługiwać animowane tapety w sposób opisany powyżej, POWINNY je implementować.

Jeśli implementacje urządzeń obsługują animowane tapety:

• [C-1-1] MUSI raportować flagę funkcji platformy android.software.live_wallpaper.

3.8.8. Przełączanie aktywności

Kod źródłowy Androida obejmuje ekran przeglądu, interfejs użytkownika na poziomie systemu do przełączania zadań i wyświetlania ostatnio używanych działań i zadań za pomocą miniatury stanu graficznego aplikacji w momencie, gdy użytkownik ostatnio ją opuścił.

Implementacje urządzeń, w tym klawisz nawigacyjny funkcji ostatnich aplikacji, zgodnie z opisem w sekcji 7.2.3, MOGĄ zmieniać interfejs.

Jeśli implementacje urządzeń, w których klawisz nawigacyjny funkcji ostatnich aplikacji jest zgodny z opisem w sekcji 7.2.3, zmieniają interfejs, muszą:

• [C-1-1] MUSI obsługiwać co najmniej 7 wyświetlanych aktywności.

• POWINNA wyświetlać co najmniej tytuły 4 aktywności jednocześnie.

• POWINNA wyświetlać kolor wyróżnienia, ikonę i tytuł ekranu w sekcji Ostatnie.

• POWINIEN wyświetlać element zamykający („x”), ale MOŻE opóźnić to do momentu, gdy użytkownik wejdzie w interakcję z ekranami.

• POWINIEN zawierać skrót umożliwiający łatwe przełączenie się na poprzednią aktywność.

• POWINNO wywoływać szybkie przełączanie między 2 ostatnio używanymi aplikacjami, gdy dwukrotnie naciśniesz klawisz funkcji ostatnich aplikacji.

• POWINNO włączać tryb wielookienkowy na podzielonym ekranie, jeśli jest obsługiwany, gdy przycisk funkcji ostatnich aplikacji jest przytrzymywany.

• MOGĄ wyświetlać powiązane ostatnie wyszukiwania jako grupę, która przesuwa się razem.

• [C-SR-1] ZDECYDOWANIE ZALECA się używanie interfejsu użytkownika Androida (lub podobnego interfejsu opartego na miniaturach) na ekranie przeglądu.

3.8.9. Zarządzanie danymi wejściowymi

Android obsługuje zarządzanie danymi wejściowymi i edytory metod wprowadzania innych firm.

Jeśli implementacje urządzeń umożliwiają użytkownikom korzystanie na urządzeniu z metod wprowadzania innych firm:

• [C-1-1] MUSI deklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy API IME zgodnie z dokumentacją pakietu Android SDK.

3.8.10. Sterowanie multimediami z ekranu blokady

Interfejs Remote Control Client API został wycofany w Androidzie 5.0 na rzecz szablonu powiadomienia o multimediach, który umożliwia aplikacjom multimedialnym integrację z elementami sterującymi odtwarzaniem wyświetlanymi na ekranie blokady.

3.8.11. Wygaszacze ekranu (wcześniej Dreams)

Ustawienia wygaszaczy ekranu znajdziesz w sekcji 3.2.3.5.

3.8.12. Lokalizacja

Jeśli implementacje urządzeń zawierają czujnik sprzętowy (np. GPS), który może podawać współrzędne lokalizacji:

• [C-1-2] MUSI wyświetlać bieżący stan lokalizacji w menu Lokalizacja w Ustawieniach.

• [C-1-3] NIE MOŻE wyświetlać trybów lokalizacji w menu Lokalizacja w Ustawieniach.

3.8.13. Unicode i czcionka

Android obsługuje znaki emoji zdefiniowane w Unicode 10.0.

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

• [C-1-1] MUSI być w stanie renderować te emotikony w kolorze.

• [C-1-2] MUSI obsługiwać:

  • Czcionka Roboto 2 o różnej grubości – sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light – w językach dostępnych na urządzeniu.

  • Pełna obsługa standardu Unicode 7.0 w przypadku alfabetów łacińskiego, greckiego i cyrylicy, w tym zakresów Latin Extended A, B, C i D oraz wszystkich znaków w bloku symboli walut w standardzie Unicode 7.0.

• [C-1-3] NIE WOLNO usuwać ani modyfikować NotoColorEmoji.tff w obrazie systemu. (Możesz dodać nową czcionkę emotikonów, aby zastąpić emotikony w NotoColorEmoji.tff)

• POWINIEN obsługiwać emotikony przedstawiające różne odcienie skóry i różnorodne rodziny zgodnie z raportem technicznym Unicode nr 51.

Jeśli implementacje urządzeń obejmują IME:

• POWINIEN udostępniać użytkownikowi metodę wprowadzania tych emotikonów.

Android obsługuje renderowanie czcionek w języku birmańskim. W Birmie do renderowania języków birmańskich używa się kilku czcionek niezgodnych ze standardem Unicode, powszechnie znanych jako „Zawgyi”.

Jeśli implementacje urządzeń obejmują obsługę języka birmańskiego:

• [C-2-1] MUSI renderować tekst za pomocą czcionki zgodnej z Unicode jako domyślnej; czcionka niezgodna z Unicode NIE MOŻE być ustawiona jako domyślna, chyba że użytkownik wybierze ją w selektorze języka.

• [C-2-2] MUSI obsługiwać czcionkę Unicode i czcionkę niezgodną z Unicode, jeśli urządzenie obsługuje czcionkę niezgodną z Unicode. Czcionka niezgodna ze standardem Unicode NIE MOŻE usuwać ani zastępować czcionki Unicode.

• [C-2-3] MUSI renderować tekst za pomocą czcionki niezgodnej z Unicode TYLKO WTEDY, gdy określony jest kod języka z kodem skryptu Qaag (np. my-Qaag). Do odwoływania się do czcionki w Birmie niezgodnej ze standardem Unicode nie można używać żadnych innych kodów języka lub regionu ISO (przypisanych, nieprzypisanych ani zarezerwowanych). Twórcy aplikacji i autorzy stron internetowych mogą określić kod języka my-Qaag jako wyznaczony kod języka, tak jak w przypadku każdego innego języka.

3.8.14. Wiele okien

Jeśli implementacje urządzeń mają możliwość wyświetlania wielu aktywności jednocześnie:

• [C-1-1] MUSI implementować tryby wielu okien zgodnie z zachowaniami aplikacji i interfejsami API opisanymi w dokumentacji pakietu Android SDK dotyczącej obsługi trybu wielu okien oraz spełniać te wymagania:

• [C-1-2] Wymaganie usunięte w Androidzie 16.

• [C-1-3] NIE MOŻE oferować trybu podzielonego ekranu ani trybu dowolnego, jeśli wysokość ekranu jest mniejsza niż 440 dp, a szerokość ekranu jest mniejsza niż 440 dp.

• [C-1-4] Aktywność NIE MOŻE być zmieniana do rozmiaru mniejszego niż 220 dp w trybach wielu okien innych niż obraz w obrazie.

• Implementacje urządzeń o rozmiarze ekranu xlarge POWINNY obsługiwać tryb dowolny.

Jeśli implementacje urządzeń obsługują tryby wielu okien i tryb podzielonego ekranu:

• [C-2-2] MUSI przycinać zadokowaną aktywność w trybie podzielonego ekranu, ale POWINIEN wyświetlać część jej zawartości, jeśli aplikacja uruchamiająca jest oknem aktywnym.

• [C-2-3] MUSI uwzględniać zadeklarowane wartości AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight aplikacji uruchamiającej innej firmy i nie może ich zastępować podczas wyświetlania treści zadokowanej aktywności.

Jeśli implementacje urządzeń obsługują tryby wielu okien i tryb wielu okien obraz w obrazie:

• [C-3-1] MUSI uruchamiać aktywności w trybie wielu okien obrazu w obrazie, gdy aplikacja:

  • kierować aplikację co najmniej na poziom API 26 i deklarować android:supportsPictureInPicture.

  • kierować aplikację na interfejs API na poziomie 25 lub niższym i deklarować zarówno android:resizeableActivity, jak i android:supportsPictureInPicture.

• [C-3-2] MUSI udostępniać działania w interfejsie SystemUI zgodnie z bieżącą aktywnością w trybie obrazu w obrazie za pomocą interfejsu setActions().

• [C-3-3] MUSI obsługiwać proporcje obrazu większe lub równe 1:2,39 i mniejsze lub równe 2,39:1, zgodnie z aktywnością obrazu w obrazie określoną przez interfejs API setAspectRatio().

• [C-3-4] MUSI używać KeyEvent.KEYCODE_WINDOW do sterowania oknem obrazu w obrazie. Jeśli tryb obrazu w obrazie nie jest zaimplementowany, klawisz MUSI być dostępny dla aktywności na pierwszym planie.

• [C-3-5] MUSI udostępniać użytkownikowi możliwość zablokowania wyświetlania aplikacji w trybie obrazu w obrazie. Implementacja AOSP spełnia to wymaganie, ponieważ w panelu powiadomień znajdują się odpowiednie elementy sterujące.

• [C-3-6] MUSI przydzielić okienku PIP minimalną szerokość i wysokość, jeśli aplikacja nie zadeklaruje żadnej wartości dla AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight:

  • Urządzenia, w których wartość Configuration.uiMode jest inna niż UI_MODE_TYPE_TELEVISION, MUSZĄ przydzielać minimalną szerokość i wysokość wynoszącą 108 dp.

  • Urządzenia z parametrem Configuration.uiMode ustawionym na UI_MODE_TYPE_TELEVISION MUSZĄ przydzielać minimalną szerokość 240 dp i minimalną wysokość 135 dp.

Jeśli implementacje urządzeń obejmują więcej niż 1 obszar wyświetlania zgodny z Androidem i udostępniają takie obszary aplikacjom, to:

• [C-4-1] MUSI obsługiwać tryb wielu okien.

Jeśli implementacje urządzeń obsługują tryb wielu okien:

• [C-5-1] MUSI implementować prawidłową wersję rozszerzeń Menedżera okien na poziomie interfejsu API zgodnie z opisem w WindowManagerRozszerzeniach.

3.8.15. Wycięcie w ekranie

Android obsługuje wycięcie na wyświetlaczu zgodnie z opisem w dokumencie pakietu SDK. Interfejs DisplayCutout API określa obszar na krawędzi wyświetlacza, który może być niefunkcjonalny dla aplikacji ze względu na wycięcie w ekranie lub zakrzywiony wyświetlacz na krawędziach.

Jeśli implementacje urządzeń obejmują wycięcia w ekranie:

• [C-1-5] NIE MOŻE mieć wycięcia, jeśli format obrazu urządzenia wynosi 1,0 (1:1).

• [C-1-2] NIE MOŻE mieć więcej niż jednego wycięcia na krawędź.

• [C-1-3] MUSI uwzględniać flagi wycięcia w ekranie ustawione przez aplikację za pomocą interfejsu WindowManager.LayoutParams API zgodnie z opisem w pakiecie SDK.

• [C-1-4] MUSI raportować prawidłowe wartości wszystkich danych dotyczących wycięcia zdefiniowanych w interfejsie API DisplayCutout.

3.8.16. Sterowanie urządzeniami

Android zawiera interfejsy API ControlsProviderService i Control, które umożliwiają aplikacjom innych firm publikowanie elementów sterujących urządzeniami, aby użytkownicy mogli szybko sprawdzać ich stan i wykonywać działania.

Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2_2_3.

3.8.17. Schowek

Implementacje urządzeń:

• [C-0-1] NIE WOLNO wysyłać danych ze schowka do żadnego komponentu, aktywności, usługi ani przez żadne połączenie sieciowe bez wyraźnej zgody użytkownika (np. naciśnięcia przycisku w nakładce) lub wskazania, że treść jest wysyłana, z wyjątkiem usług wymienionych w sekcji 9.8.6 Przechwytywanie treści i wyszukiwanie w aplikacji.

Jeśli implementacje urządzeń generują widoczny dla użytkownika podgląd, gdy treść jest kopiowana do schowka w przypadku dowolnego elementu ClipData, w którym ClipData.getDescription().getExtras() zawiera android.content.extra.IS_SENSITIVE:

• [C-1-1] MUSI zredagować podgląd widoczny dla użytkownika

Implementacja referencyjna AOSP spełnia te wymagania dotyczące schowka.

3.8.18. Przycisk lokalizacji

3.9. Administracja urządzeniem

Android zawiera funkcje, które umożliwiają aplikacjom kontrolera zasad dotyczących urządzeń wykonywanie funkcji administracji urządzeniami na poziomie systemu, takich jak egzekwowanie zasad dotyczących haseł czy zdalne czyszczenie pamięci, za pomocą interfejsów Device Policy Manager API.

3.9.1. Obsługa administracyjna urządzenia

3.9.1.1. Obsługa administracyjna urządzenia należącego do firmy

Jeśli implementacje urządzeń deklarują android.software.device_admin, to:

• [C-1-1] MUSI obsługiwać rejestrację kontrolera zasad dotyczących urządzeń (DPC) jako aplikacji właściciela urządzenia w sposób opisany poniżej:

  • Jeśli na urządzeniu nie skonfigurowano użytkowników ani danych użytkownika:

    • [C-1-5] MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia LUB umożliwić aplikacji DPC wybór, czy ma stać się właścicielem urządzenia, czy właścicielem profilu, jeśli urządzenie deklaruje obsługę komunikacji NFC za pomocą flagi funkcji android.hardware.nfc i otrzymuje wiadomość NFC zawierającą rekord z typem MIME MIME_TYPE_PROVISIONING_NFC.

    • [C-1-8] MUSI wysłać intencję ACTION_GET_PROVISIONING_MODE po uruchomieniu procesu udostępniania właścicielowi urządzenia, aby aplikacja DPC mogła wybrać, czy ma zostać właścicielem urządzenia, czy właścicielem profilu, w zależności od wartości android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, chyba że z kontekstu wynika, że jest tylko jedna prawidłowa opcja.

    • [C-1-9] MUSI wysyłać intencję ACTION_ADMIN_POLICY_COMPLIANCE do aplikacji właściciela urządzenia, jeśli podczas aprowizacji zostanie ustanowiony właściciel urządzenia, niezależnie od użytej metody aprowizacji. Użytkownik nie może kontynuować pracy w Kreatorze konfiguracji, dopóki nie zakończy się działanie aplikacji właściciela urządzenia.

  • Jeśli implementacja na urządzeniu zawiera użytkowników lub dane użytkowników:

    • [C-1-7] NIE MOŻE rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia.

• [C-1-2] Wymaganie usunięte w Androidzie 15.

• [C-2-1] Wymaganie usunięte w Androidzie 15.

• [C-2-2] Wymaganie usunięte w Androidzie 15.

• [C-2-3] Wymaganie usunięte w Androidzie 15.

3.9.1.2. Obsługa administracyjna profilu zarządzanego

Jeśli implementacje urządzeń deklarują android.software.managed_users, to:

• [C-1-1] MUSI deklarować android.software.device_admin i wdrażać interfejsy API, które umożliwiają aplikacji kontrolera zasad dotyczących urządzeń (DPC) stanie się właścicielem nowego profilu zarządzanego.

• [C-1-2] Wymaganie usunięte w Androidzie 16.

• [C-1-3] MUSI udostępniać w Ustawieniach te możliwości, aby informować użytkownika, kiedy określona funkcja systemu została wyłączona przez kontroler zasad dotyczących urządzenia (DPC):

  • Spójna ikona lub inne ułatwienie dla użytkownika (np. ikona informacji AOSP) wskazujące, że dane ustawienie jest ograniczone przez administratora urządzenia.
  • Krótki komunikat z wyjaśnieniem podany przez administratora urządzenia za pomocą interfejsu setShortSupportMessage.
  • Ikona aplikacji DPC.

• [C-1-4] MUSI uruchomić moduł obsługi intencji ACTION_PROVISIONING_SUCCESSFUL w profilu służbowym, jeśli podczas inicjowania aprowizacji przez intencję android.app.action.PROVISION_MANAGED_PROFILE ustanowiono właściciela profilu, a DPC zaimplementował moduł obsługi.

• [C-1-5] MUSI wysyłać komunikat ACTION_PROFILE_PROVISIONING_COMPLETE do kontrolera zasad urządzenia profilu służbowego, gdy inicjowanie jest wywoływane przez intencję android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-6] MUSI wysyłać intencję ACTION_GET_PROVISIONING_MODE po uruchomieniu procesu udostępniania właściciela profilu, aby aplikacja DPC mogła wybrać, czy ma zostać właścicielem urządzenia, czy właścicielem profilu, z wyjątkiem sytuacji, gdy proces udostępniania jest uruchamiany przez intencję android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] MUSI wysyłać intencję ACTION_ADMIN_POLICY_COMPLIANCE do profilu służbowego, gdy podczas wdrażania zostanie utworzony właściciel profilu, niezależnie od użytej metody wdrażania, z wyjątkiem sytuacji, gdy wdrażanie jest wywoływane przez intencję android.app.action.PROVISION_MANAGED_PROFILE. Użytkownik nie może przejść dalej w Kreatorze konfiguracji, dopóki nie zakończy się działanie aplikacji Właściciel profilu.

• [C-1-8] MUSI wysyłać komunikat ACTION_MANAGED_PROFILE_PROVISIONED do profilu osobistego DPC, gdy zostanie utworzony właściciel profilu, niezależnie od użytej metody udostępniania.

3.9.2. Obsługa profili zarządzanych

Jeśli implementacje urządzeń deklarują android.software.managed_users, to:

• [C-1-1] MUSI obsługiwać profile zarządzane za pomocą interfejsów APIandroid.app.admin.DevicePolicyManager.

• [C-1-2] MUSI umożliwiać utworzenie tylko jednego profilu zarządzanego.

• [C-1-3] MUSI używać plakietki ikony (podobnej do plakietki służbowej AOSP) do reprezentowania zarządzanych aplikacji i widżetów oraz innych elementów interfejsu z plakietkami, takich jak „Ostatnie i powiadomienia”.

• [C-1-4] MUSI wyświetlać ikonę powiadomienia (podobną do plakietki w przypadku pracy w górę w AOSP), aby wskazywać, kiedy użytkownik korzysta z aplikacji w profilu zarządzanym.

• [C-1-5] MUSI wyświetlać komunikat informujący o tym, że użytkownik korzysta z zarządzanego profilu, gdy urządzenie zostanie wybudzone (ACTION_USER_PRESENT), a aplikacja na pierwszym planie będzie znajdować się w zarządzanym profilu.

• [C-1-6] Jeśli istnieje profil zarządzany, MUSI wyświetlać w „selektorze” intencji element wizualny, który umożliwia użytkownikowi przekazywanie intencji z profilu zarządzanego do użytkownika głównego lub odwrotnie, jeśli jest to włączone przez kontroler zasad urządzenia.

• [C-1-7] Jeśli istnieje profil zarządzany, MUSI udostępniać te funkcje użytkownika zarówno użytkownikowi podstawowemu, jak i profilowi zarządzanemu:

  • Oddzielne rozliczanie zużycia baterii, lokalizacji, mobilnej transmisji danych i wykorzystania miejsca na dane w przypadku głównego użytkownika i profilu zarządzanego.
  • Niezależne zarządzanie aplikacjami VPN zainstalowanymi w profilu głównym lub zarządzanym.
  • Niezależne zarządzanie aplikacjami zainstalowanymi w głównym profilu użytkownika lub profilu zarządzanym.
  • Niezależne zarządzanie kontami w głównym profilu użytkownika lub profilu zarządzanym.

• [C-1-8] MUSI zapewniać, że preinstalowane aplikacje do wybierania numerów, kontaktów i wiadomości mogą wyszukiwać i wyszukiwać informacje o dzwoniącym z profilu zarządzanego (jeśli taki istnieje) oraz z profilu głównego, jeśli kontroler zasad urządzenia na to zezwala.

• [C-1-9] MUSI spełniać wszystkie wymagania dotyczące bezpieczeństwa obowiązujące w przypadku urządzenia z włączoną obsługą wielu użytkowników (patrz sekcja 9.5), mimo że profil zarządzany nie jest traktowany jako dodatkowy użytkownik oprócz użytkownika głównego.

• [C-1-10] MUSI zapewnić, że dane zrzutu ekranu są zapisywane w pamięci profilu służbowego, gdy zrzut ekranu jest robiony w topActivity oknie, które ma fokus (czyli w oknie, z którym użytkownik ostatnio wchodził w interakcję spośród wszystkich działań) i należy do aplikacji profilu służbowego.

• [C-1-11] NIE MOŻE rejestrować żadnych innych treści ekranu (paska systemowego, powiadomień ani żadnych treści profilu osobistego) z wyjątkiem okna/okien aplikacji profilu służbowego podczas zapisywania zrzutu ekranu w profilu służbowym (aby mieć pewność, że dane profilu osobistego nie zostaną zapisane w profilu służbowym).

Jeśli implementacje urządzeń deklarują android.software.managed_users i android.software.secure_lock_screen, to:

• [C-2-1] MUSI obsługiwać możliwość określenia osobnego spotkania na ekranie blokady, które spełnia następujące wymagania, aby przyznawać dostęp tylko do aplikacji działających w profilu zarządzanym.

  • Implementacje urządzeń MUSZĄ uwzględniać intencję DevicePolicyManager.ACTION_SET_NEW_PASSWORD i wyświetlać interfejs do konfigurowania osobnych danych logowania na ekranie blokady dla profilu zarządzanego.

  • Dane logowania na ekranie blokady profilu zarządzanego MUSZĄ korzystać z tych samych mechanizmów przechowywania i zarządzania danymi logowania co profil nadrzędny, zgodnie z dokumentacją na stronie projektu Android Open Source.

  • Zasady dotyczące haseł DPC MUSZĄ być stosowane tylko do danych logowania na ekranie blokady profilu zarządzanego, chyba że zostanie wywołana instancja DevicePolicyManager zwrócona przez getParentProfileInstance.

• Gdy kontakty z profilu zarządzanego są wyświetlane w preinstalowanym dzienniku połączeń, interfejsie połączenia, powiadomieniach o trwających i nieodebranych połączeniach, aplikacjach do obsługi kontaktów i wiadomości, powinny być oznaczone tą samą plakietką, która jest używana do oznaczania aplikacji profilu zarządzanego.

3.9.3. Pomoc dla użytkowników zarządzanych

Jeśli implementacje urządzeń deklarują android.software.managed_users, to:

• [C-1-1] MUSI udostępniać użytkownikowi możliwość wylogowania się z bieżącego konta i powrotu do konta głównego w sesji wielu użytkowników, gdy isLogoutEnabled zwraca true. Element interfejsu użytkownika MUSI być dostępny na ekranie blokady bez odblokowywania urządzenia.

Jeśli implementacje urządzeń deklarują android.software.device_admin i zapewniają na urządzeniu możliwość dodawania dodatkowych użytkowników dodatkowych, muszą:

• [C-SR-1] Zdecydowanie zaleca się, aby w przypadku profilu służbowego na urządzeniu należącym do firmy wyświetlać te same informacje o zgodzie użytkownika na zarządzanie urządzeniem, które były wyświetlane w procesie inicjowanym przez działanie android.app.action.PROVISION_MANAGED_DEVICE, zanim będzie można dodać konta w nowym użytkowniku dodatkowym. Dzięki temu użytkownicy będą wiedzieć, że urządzenie jest zarządzane.

3.9.4. Wymagania dotyczące ról w zarządzaniu zasadami dotyczącymi urządzeń

Jeśli implementacje urządzeń deklarują android.software.device_admin, to:

• [C-1-1] MUSI obsługiwać rolę zarządzania zasadami dotyczącymi urządzeń zgodnie z definicją w sekcji 9.1. Aplikację, która pełni rolę zarządzania zasadami urządzenia, MOŻNA zdefiniować, ustawiając config_devicePolicyManagement na nazwę pakietu. Po nazwie pakietu MUSI znajdować się dwukropek (:) i certyfikat podpisu, chyba że aplikacja jest preinstalowana.

Jeśli nazwa pakietu nie jest zdefiniowana dla config_devicePolicyManagement w sposób opisany powyżej:

• [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać udostępnianie bez aplikacji posiadacza roli zarządzania zasadami urządzenia (AOSP udostępnia implementację referencyjną).

Jeśli nazwa pakietu jest zdefiniowana dla config_devicePolicyManagement w sposób opisany powyżej:

• [C-3-1] Aplikacja MUSI być zainstalowana we wszystkich profilach użytkownika.

• [C-3-2] Implementacje urządzeń MOGĄ definiować aplikację, która aktualizuje posiadacza roli zarządzania zasadami urządzenia przed udostępnieniem, ustawiając config_devicePolicyManagementUpdater.

Jeśli nazwa pakietu jest zdefiniowana dla config_devicePolicyManagementUpdater w sposób opisany powyżej:

• [C-4-1] Aplikacja MUSI być wstępnie zainstalowana na urządzeniu.

• [C-4-2] Aplikacja MUSI implementować filtr intencji, który rozwiązuje problem z android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

3.9.5. Platforma rozwiązywania problemów z zasadami dotyczącymi urządzeń

Jeśli implementacje urządzeń deklarują android.software.device_admin, to:

• [C-1-1] MUSI rozwiązywać konflikty zasad dotyczących urządzeń zgodnie z dokumentacją w ramach rozwiązywania konfliktów zasad dotyczących urządzeń.

3.10. Ułatwienia dostępu

Android udostępnia warstwę ułatwień dostępu, która pomaga osobom z niepełnosprawnościami łatwiej poruszać się po urządzeniach. Android udostępnia też interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu otrzymywanie wywołań zwrotnych dotyczących zdarzeń użytkownika i systemu oraz generowanie alternatywnych mechanizmów informacji zwrotnej, takich jak zamiana tekstu na mowę, reakcja haptyczna i nawigacja za pomocą trackballa lub pada kierunkowego.

Jeśli implementacje urządzeń obsługują usługi ułatwień dostępu innych firm:

• [C-1-1] MUSI udostępniać implementację platformy ułatwień dostępu na Androida zgodnie z opisem w dokumentacji pakietu SDK interfejsów Accessibility API.
• [C-1-2] MUSI generować zdarzenia związane z ułatwieniami dostępu i przekazywać odpowiednie informacjeAccessibilityEvent do wszystkich zarejestrowanychAccessibilityService implementacji zgodnie z dokumentacją pakietu SDK.
• [C-1-4] MUSI udostępniać użytkownikowi możliwość kontrolowania usług ułatwień dostępu, które deklarują AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. W przypadku urządzeń z systemowym paskiem nawigacyjnym powinny one umożliwiać użytkownikowi włączenie przycisku na tym pasku do sterowania tymi usługami.

Jeśli implementacje urządzeń obejmują wstępnie zainstalowane usługi ułatwień dostępu:

• [C-2-1] MUSI implementować te preinstalowane usługi ułatwień dostępu jako aplikacje obsługujące bezpośrednie uruchamianie, gdy pamięć jest szyfrowana za pomocą szyfrowania opartego na plikach (FBE).
• POWINIEN udostępniać w procesie konfiguracji po wyjęciu z pudełka mechanizm umożliwiający użytkownikom włączanie odpowiednich usług ułatwień dostępu, a także opcje dostosowywania rozmiaru czcionki, rozmiaru wyświetlacza i gestów powiększania.

3.11. Text-to-Speech

Android zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług zamiany tekstu na mowę (TTS), a dostawcom usług – udostępnianie implementacji usług TTS.

Jeśli implementacje urządzeń zgłaszają funkcję android.hardware.audio.output:

• [C-1-1] MUSI obsługiwać interfejsy API platformy Android TTS.

Jeśli implementacje urządzeń obsługują instalację silników TTS innych firm:

• [C-2-1] MUSI udostępniać użytkownikowi możliwość wyboru silnika TTS do użycia na poziomie systemu.

3.12. Nie dotyczy

3.13. Szybkie ustawienia

Android udostępnia komponent interfejsu Szybkie ustawienia, który umożliwia szybki dostęp do często używanych lub pilnie potrzebnych działań.

Jeśli implementacje urządzeń zawierają komponent interfejsu Szybkich ustawień i obsługują Szybkie ustawienia innych firm:

• [C-1-1] MUSI umożliwiać użytkownikowi dodawanie i usuwanie kafelków udostępnianych przez interfejsy API quicksettings w aplikacji innej firmy.
• [C-1-2] NIE MOŻE automatycznie dodawać kafelka z aplikacji innej firmy bezpośrednio do Szybkich ustawień.
• [C-1-3] MUSI wyświetlać wszystkie kafelki dodane przez użytkownika z aplikacji innych firm obok kafelków szybkich ustawień dostarczonych przez system.

3.14. Interfejs multimediów

Jeśli implementacje urządzeń obejmują aplikacje niewłączane głosem (Aplikacje), które wchodzą w interakcje z aplikacjami innych firm za pomocą MediaBrowser lub MediaSession, Aplikacje:

• [C-1-2] MUSI wyraźnie wyświetlać ikony uzyskane za pomocą interfejsu getIconBitmap() lub getIconUri() oraz tytuły uzyskane za pomocą interfejsu getTitle() zgodnie z opisem w sekcji MediaDescription. Może skrócić tytuły, aby zachować zgodność z przepisami dotyczącymi bezpieczeństwa (np. rozpraszania uwagi kierowcy).

• [C-1-3] MUSI wyświetlać ikonę aplikacji innej firmy za każdym razem, gdy wyświetla treści dostarczane przez tę aplikację.

• [C-1-4] MUSI umożliwiać użytkownikowi interakcję z całą hierarchią MediaBrowser. MOŻE ograniczyć dostęp do części hierarchii, aby zachować zgodność z przepisami dotyczącymi bezpieczeństwa (np. rozpraszanie uwagi kierowcy), ale NIE MOŻE przyznawać preferencyjnego traktowania na podstawie treści lub dostawcy treści.

• [C-1-5] MUSI traktować dwukrotne kliknięcie KEYCODE_HEADSETHOOK lub KEYCODE_MEDIA_PLAY_PAUSE jako KEYCODE_MEDIA_NEXT w przypadku MediaSession.Callback#onMediaButtonEvent.

3.15. Aplikacje błyskawiczne

Jeśli implementacje urządzeń obsługują aplikacje natychmiastowe, MUSZĄ spełniać te wymagania:

• [C-1-1] Aplikacje natychmiastowe MUSZĄ mieć przyznane tylko uprawnienia, które mają ustawioną wartość "instant" w przypadku parametru android:protectionLevel.
• [C-1-2] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami za pomocą niejawnych intencji, chyba że spełniony jest jeden z tych warunków:
  • Filtr wzorca intencji komponentu jest widoczny i ma wartość CATEGORY_BROWSABLE.
  • Działanie to ACTION_SEND, ACTION_SENDTO lub ACTION_SEND_MULTIPLE.
  • Element docelowy jest jawnie udostępniany za pomocą atrybutu android:visibleToInstantApps.
• [C-1-3] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami, chyba że komponent jest udostępniany za pomocą atrybutu android:visibleToInstantApps.
• [C-1-4] Zainstalowane aplikacje NIE MOGĄ widzieć szczegółów dotyczących aplikacji błyskawicznych na urządzeniu, chyba że aplikacja błyskawiczna wyraźnie połączy się z zainstalowaną aplikacją.

• Implementacje urządzeń MUSZĄ zapewniać użytkownikom te możliwości interakcji z aplikacjami błyskawicznymi: AOSP spełnia wymagania dzięki domyślnemu interfejsowi systemu, Ustawieniom i Launcherowi. Implementacje urządzeń:

  • [C-1-5] MUSI udostępniać użytkownikowi możliwość wyświetlania i usuwania aplikacji natychmiastowych pobranych lokalnie do pamięci podręcznej dla każdego pakietu aplikacji.
  • [C-1-6] MUSI wyświetlać stałe powiadomienie użytkownika, które można zwinąć, gdy aplikacja błyskawiczna działa na pierwszym planie. To powiadomienie MUSI zawierać informację, że aplikacje błyskawiczne nie wymagają instalacji, oraz element interfejsu, który kieruje użytkownika do ekranu informacji o aplikacji w Ustawieniach. W przypadku aplikacji natychmiastowych uruchamianych za pomocą intencji internetowych, zdefiniowanych przez użycie intencji z działaniem ustawionym na Intent.ACTION_VIEW i schematem „http” lub „https”, dodatkowa funkcja powinna umożliwiać użytkownikowi nieuruchamianie aplikacji natychmiastowej, a uruchamianie powiązanego linku w skonfigurowanej przeglądarce internetowej, jeśli jest ona dostępna na urządzeniu.
  • [C-1-7] MUSI umożliwiać dostęp do aplikacji natychmiastowych z funkcji Ostatnie, jeśli jest ona dostępna na urządzeniu.

• [C-1-8] MUSI wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi z procedurą obsługi intencji dla intencji wymienionych w pakiecie SDK tutaj i udostępniać te intencje aplikacjom natychmiastowym.

3.16. Parowanie urządzenia towarzyszącego

Android obsługuje parowanie urządzeń towarzyszących, co pozwala skuteczniej zarządzać powiązaniami z tymi urządzeniami. Udostępnia też interfejs API CompanionDeviceManager, który umożliwia aplikacjom korzystanie z tej funkcji.

Jeśli implementacje urządzeń obsługują funkcję parowania urządzeń towarzyszących:

• [C-1-1] MUSI zadeklarować flagę funkcji FEATURE_COMPANION_DEVICE_SETUP.

• [C-1-2] MUSI zapewnić pełne wdrożenie interfejsów API w pakiecie android.companion.

• [C-1-3] MUSI udostępniać użytkownikowi funkcje umożliwiające wybranie lub potwierdzenie, że urządzenie towarzyszące jest obecne i działa. MUSI używać tego samego komunikatu co w AOSP bez dodawania ani modyfikowania.

3.17. Aplikacje zużywające dużo zasobów

Jeśli implementacje urządzeń deklarują funkcję FEATURE_CANT_SAVE_STATE,

• [C-1-1] W systemie może być zainstalowana tylko jedna aplikacja instalowana, która określa cantSaveState. Jeśli użytkownik opuści taką aplikację bez jej wyraźnego zamknięcia (np. naciskając przycisk ekranu głównego podczas opuszczania aktywnego działania w systemie, zamiast naciskać przycisk Wstecz, gdy w systemie nie ma już żadnych aktywnych działań), implementacje urządzeń MUSZĄ traktować tę aplikację priorytetowo w pamięci RAM, tak jak w przypadku innych elementów, które powinny pozostać uruchomione, np. usług na pierwszym planie. Gdy taka aplikacja działa w tle, system może nadal stosować do niej funkcje zarządzania energią, takie jak ograniczenie dostępu do procesora i sieci.
• [C-1-2] MUSI udostępniać interfejs umożliwiający wybranie aplikacji, która nie będzie uczestniczyć w mechanizmie zapisywania i przywracania normalnego stanu, gdy użytkownik uruchomi drugą aplikację zadeklarowaną za pomocą atrybutu cantSaveState.
• [C-1-3] NIE WOLNO wprowadzać innych zmian w zasadach w przypadku aplikacji, które określają cantSaveState, np. zmieniać wydajności procesora lub priorytetu planowania.

Jeśli implementacje urządzeń nie deklarują funkcji FEATURE_CANT_SAVE_STATE, to:

• [C-1-1] MUSI ignorować atrybut cantSaveState ustawiony przez aplikacje i NIE MOŻE zmieniać zachowania aplikacji na podstawie tego atrybutu.

3.18. Kontakty

Android zawiera Contacts Provider interfejsy API, które umożliwiają aplikacjom zarządzanie informacjami o kontaktach przechowywanymi na urządzeniu. Dane kontaktowe wprowadzane bezpośrednio na urządzeniu są zwykle synchronizowane z usługą internetową, ale mogą też być przechowywane tylko lokalnie na urządzeniu. Kontakty, które są przechowywane tylko na urządzeniu, są nazywane kontaktami lokalnymi.

Obiekty RawContacts są „powiązane z” lub „przechowywane w” koncie, gdy kolumny ACCOUNT_NAME i ACCOUNT_TYPE w przypadku kontaktów surowych są zgodne z odpowiednimi polami Account.name i Account.type konta.

Domyślne konto lokalne: konto dla surowych kontaktów, które są przechowywane tylko na urządzeniu i nie są powiązane z kontem w AccountManager. Są one tworzone z wartościami null w kolumnach ACCOUNT_NAME i ACCOUNT_TYPE.

Niestandardowe konto lokalne: konto dla surowych kontaktów, które są przechowywane tylko na urządzeniu i nie są powiązane z kontem w AccountManager. Są one tworzone z wartościami niezerowymi w kolumnach ACCOUNT_NAME i ACCOUNT_TYPE.

Implementacje urządzeń:

• [C-SR-1] Zdecydowanie zalecamy, aby nie tworzyć niestandardowych kont lokalnych.

Jeśli implementacje urządzeń używają niestandardowego konta lokalnego:

• [C-1-1] Wartość ACCOUNT_NAME niestandardowego konta lokalnego MUSI być zwracana przez ContactsContract.RawContacts.getLocalAccountName.

• [C-1-2] Usługa ContactsContract.RawContacts.getLocalAccountType MUSI zwracać wartość ACCOUNT_TYPE niestandardowego konta lokalnego.

• [C-1-3] Surowe kontakty wstawiane przez aplikacje innych firm bez określania konta MUSZĄ być wstawiane na domyślne konto kontaktów na urządzeniu. Jeśli domyślne konto kontaktów to DEFAULT_ACCOUNT_STATE_LOCAL lub DEFAULT_ACCOUNT_STATE_NOT_SET, te nieprzetworzone kontakty MUSZĄ być przechowywane na niestandardowym koncie lokalnym.

• [C-1-4] Surowe kontakty wstawione na niestandardowe konto lokalne NIE MOGĄ być usuwane podczas dodawania lub usuwania kont.

• [C-1-5] Operacje usuwania wykonane na niestandardowym koncie lokalnym MUSZĄ powodować natychmiastowe usunięcie kontaktów w formacie surowym (tak jakby parametr CALLER_IS_SYNCADAPTER był ustawiony na wartość true), nawet jeśli parametr CALLER_IS_SYNCADAPTER był ustawiony na wartość false lub nie został określony.

3.18.2. Selektor kontaktów systemowych

3.19. Ustawienia języka

Implementacje urządzeń:

• [C-0-1] NIE WOLNO udostępniać użytkownikowi możliwości wyboru tłumaczeń uwzględniających płeć w przypadku języków, które nie obsługują takich tłumaczeń. Więcej informacji znajdziesz w materiałach dotyczących gramatyki.

3.20. Funkcje oparte na Asystencie

3.20.1. Wymagania dotyczące strumienia audio Asystenta

3.21. Obsługa funkcji synchronizacji urządzenia towarzyszącego

4. Zgodność pakowania aplikacji

Implementacje na urządzeniach:

• [C-0-1] MUSI umożliwiać instalowanie i uruchamianie plików „.apk” na Androida wygenerowanych za pomocą narzędzia „aapt” dołączonego do oficjalnego pakietu Android SDK.
  • Powyższe wymaganie może być trudne do spełnienia, dlatego zalecamy, aby implementacje urządzeń korzystały z systemu zarządzania pakietami w referencyjnej implementacji AOSP.

• [C-0-3] NIE MOŻE rozszerzać formatów .apk, manifestu Androida, kodu bajtowego Dalvik ani kodu bajtowego RenderScript w sposób, który uniemożliwiałby prawidłową instalację i działanie tych plików na innych zgodnych urządzeniach.

• [C-0-4] NIE MOŻE zezwalać aplikacjom innym niż bieżący „instalator” pakietu na ciche odinstalowywanie aplikacji bez potwierdzenia przez użytkownika, zgodnie z dokumentacją pakietu SDK dotyczącą uprawnienia DELETE_PACKAGE. Wyjątkiem jest tylko aplikacja weryfikująca pakiety systemowe, która obsługuje intencję PACKAGE_NEEDS_VERIFICATION, oraz aplikacja menedżera miejsca, która obsługuje intencję ACTION_MANAGE_STORAGE.

• [C-0-5] MUSI mieć aktywność, która obsługuje intencję android.settings.MANAGE_UNKNOWN_APP_SOURCES.

• [C-0-6] NIE MOŻE instalować pakietów aplikacji z nieznanych źródeł, chyba że aplikacja, która żąda instalacji, spełnia wszystkie te wymagania:

  • Musi deklarować uprawnienie REQUEST_INSTALL_PACKAGES lub mieć ustawioną wartość android:targetSdkVersion na 24 lub niższą.
  • Użytkownik MUSI przyznać mu uprawnienia do instalowania aplikacji z nieznanych źródeł.

• POWINIEN udostępniać użytkownikowi możliwość przyznawania i cofania uprawnień do instalowania aplikacji z nieznanych źródeł w przypadku poszczególnych aplikacji, ale MOŻE zaimplementować to jako operację bez efektu i zwracać RESULT_CANCELED w przypadku startActivityForResult(), jeśli implementacja urządzenia nie chce zezwalać użytkownikom na ten wybór. Jednak nawet w takich przypadkach POWINNI poinformować użytkownika, dlaczego nie ma takiej opcji.

• [C-0-7] MUSI wyświetlać okno dialogowe z ostrzeżeniem zawierającym ciąg tekstowy ostrzeżenia przekazywany przez interfejs API systemu PackageManager.setHarmfulAppWarning przed uruchomieniem aktywności w aplikacji, która została oznaczona przez ten sam interfejs API systemu PackageManager.setHarmfulAppWarning jako potencjalnie szkodliwa.

• POWINIEN udostępniać użytkownikowi możliwość odinstalowania lub uruchomienia aplikacji w oknie ostrzeżenia.

• [C-0-8] MUSI obsługiwać przyrostowy system plików zgodnie z dokumentacją tutaj.

• [C-0-9] MUSI obsługiwać weryfikację plików APK przy użyciu schematu podpisywania plików APK w wersji 4 i schematu podpisywania plików APK w wersji 4.1.

5. Zgodność z multimediami

Implementacje urządzeń:

• [C-0-1] MUSI obsługiwać formaty multimediów, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w sekcji 5.1 w przypadku każdego kodeka zadeklarowanego przez MediaCodecList.
• [C-0-2] MUSI deklarować i zgłaszać obsługę dostępnych koderów i dekoderów w aplikacjach innych firm za pomocą MediaCodecList.
• [C-0-3] MUSI być w stanie prawidłowo dekodować i udostępniać aplikacjom innych firm wszystkie formaty, które może kodować. Obejmuje to wszystkie strumienie bitów generowane przez jego kodery i profile zgłaszane w jego CamcorderProfile.

Implementacje urządzeń:

• POWINNY dążyć do minimalnego opóźnienia kodeka, czyli
  • NIE POWINNA zużywać ani przechowywać buforów wejściowych i zwracać ich dopiero po przetworzeniu.
  • NIE POWINNA przechowywać zdekodowanych buforów dłużej niż określono w standardzie (np. SPS).
  • NIE POWINNO przechowywać zakodowanych buforów dłużej niż jest to wymagane przez strukturę GOP.

Wszystkie kodeki wymienione w sekcji poniżej są udostępniane jako implementacje oprogramowania w preferowanej implementacji Androida z projektu Android Open Source.

Ani Google, ani Open Handset Alliance nie gwarantują, że te kodeki nie są objęte patentami osób trzecich. Osoby, które zamierzają używać tego kodu źródłowego w produktach sprzętowych lub programowych, powinny pamiętać, że wdrożenia tego kodu, w tym w oprogramowaniu open source lub shareware, mogą wymagać licencji patentowych od odpowiednich posiadaczy patentów.

5.1. Kodeki multimediów

5.1.1. Kodowanie dźwięku

Więcej informacji znajdziesz w sekcji 5.1.3. Szczegóły kodeków audio.

Jeśli implementacje urządzeń deklarują android.hardware.microphone, MUSZĄ obsługiwać kodowanie tych formatów audio i udostępniać je aplikacjom innych firm:

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

Wszystkie kodery audio MUSZĄ obsługiwać:

• [C-3-1] Ramki audio PCM 16-bitowe w natywnej kolejności bajtów za pomocą interfejsu android.media.MediaCodec API.

5.1.2. Dekodowanie dźwięku

Więcej informacji znajdziesz w sekcji 5.1.3. Szczegóły kodeków audio.

Jeśli implementacje urządzeń deklarują obsługę funkcji android.hardware.audio.output, muszą obsługiwać dekodowanie tych formatów audio:

• [C-1-1] MPEG-4 AAC Profile (AAC LC)
• [C-1-2] MPEG-4 HE AAC Profile (AAC+)
• [C-1-3] Profil MPEG-4 HE AACv2 (ulepszony AAC+)
• [C-1-4] AAC ELD (ulepszony kodek AAC o niskim opóźnieniu)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE, w tym formaty audio o wysokiej rozdzielczości do 24 bitów, częstotliwość próbkowania 192 kHz i 8 kanałów. Pamiętaj, że to wymaganie dotyczy tylko dekodowania, a urządzenie może zmniejszać częstotliwość próbkowania i liczbę kanałów podczas odtwarzania.
• [C-1-10] Opus
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, który obejmuje profil podstawowy USAC i ISO/IEC 23003-4 Dynamic Range Control Profile)

Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC strumieni wielokanałowych (czyli więcej niż 2 kanały) do PCM za pomocą domyślnego dekodera audio AAC w interfejsie android.media.MediaCodec API, MUSZĄ być obsługiwane te funkcje:

• [C-2-1] Dekodowanie MUSI odbywać się bez miksowania w dół (np. strumień AAC 5.0 musi być dekodowany do 5 kanałów PCM, a strumień AAC 5.1 musi być dekodowany do 6 kanałów PCM).

• [C-2-2] Metadane zakresu dynamicznego MUSZĄ być zgodne z definicją „Dynamic Range Control (DRC)” w normie ISO/IEC 14496-3, a klucze android.media.MediaFormat DRC MUSZĄ konfigurować zachowania dekodera audio związane z zakresem dynamicznym. Klucze AAC DRC zostały wprowadzone w interfejsie API 21 i są to: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_ENCODED_TARGET_LEVEL.

• [C-SR-1] ZDECYDOWANIE ZALECA SIĘ, aby wszystkie dekodery audio AAC spełniały wymagania C-2-1 i C-2-2 powyżej.

Podczas dekodowania dźwięku USAC, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] Metadane głośności i DRC MUSZĄ być interpretowane i stosowane zgodnie z profilem kontroli zakresu dynamicznego MPEG-D DRC na poziomie 1.

• [C-3-2] Dekoder MUSI działać zgodnie z konfiguracją ustawioną za pomocą tych kluczy: android.media.MediaFormat, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_DRC_EFFECT_TYPE.

Dekodery profili MPEG-4 AAC, HE AAC i HE AACv2:

• MOŻE obsługiwać sterowanie głośnością i zakresem dynamicznym za pomocą profilu sterowania zakresem dynamicznym ISO/IEC 23003-4.

Jeśli norma ISO/IEC 23003-4 jest obsługiwana i jeśli w dekodowanym strumieniu bitów znajdują się metadane ISO/IEC 23003-4 i ISO/IEC 14496-3, to:

• Metadane ISO/IEC 23003-4 mają pierwszeństwo.

Wszystkie dekodery audio MUSZĄ obsługiwać wyjście:

• [C-6-1] Ramki audio PCM 16-bitowe w natywnym porządku bajtów za pomocą interfejsu android.media.MediaCodec.

Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC strumieni wielokanałowych (czyli więcej niż 2 kanały) do PCM za pomocą domyślnego dekodera audio AAC w API android.media.MediaCodec, MUSZĄ być obsługiwane te funkcje:

• [C-7-1] Aplikacja MUSI mieć możliwość skonfigurowania dekodowania za pomocą klucza KEY_MAX_OUTPUT_CHANNEL_COUNT, aby określić, czy treść ma być miksowana w dół do stereo (przy użyciu wartości 2), czy ma być odtwarzana przy użyciu natywnej liczby kanałów (przy użyciu wartości równej tej liczbie lub większej od niej). Na przykład wartość 6 lub większa skonfiguruje dekoder tak, aby w przypadku treści 5.1 generował 6 kanałów.

• [C-7-2] Podczas dekodowania dekoder MUSI reklamować maskę kanału używaną w formacie wyjściowym za pomocą klucza KEY_CHANNEL_MASK, używając stałych android.media.AudioFormat (przykład: CHANNEL_OUT_5POINT1).

Jeśli implementacje urządzeń obsługują dekodery audio inne niż domyślny dekoder audio AAC i są w stanie odtwarzać dźwięk wielokanałowy (czyli więcej niż 2 kanały) po podaniu skompresowanych treści wielokanałowych:

• [C-SR-2] Zdecydowanie zaleca się, aby dekoder można było skonfigurować za pomocą aplikacji, która dekoduje dźwięk za pomocą klucza KEY_MAX_OUTPUT_CHANNEL_COUNT, aby określić, czy treść ma być miksowana w dół do stereo (gdy używana jest wartość 2), czy ma być odtwarzana przy użyciu natywnej liczby kanałów (gdy używana jest wartość równa tej liczbie lub większa od niej). Na przykład wartość 6 lub większa skonfiguruje dekoder tak, aby w przypadku treści 5.1 generował 6 kanałów.

• [C-SR-3] Podczas dekodowania DEKODER ZDECYDOWANIE ZALECA się, aby reklamował maskę kanału używaną w formacie wyjściowym za pomocą klucza KEY_CHANNEL_MASK, używając stałych android.media.AudioFormat (przykład: CHANNEL_OUT_5POINT1).

5.1.3. Szczegóły kodeków audio

5.1.4. Kodowanie obrazu

Więcej informacji znajdziesz w sekcji 5.1.6. Szczegóły dotyczące kodeków obrazu.

Implementacje urządzeń MUSZĄ obsługiwać kodowanie obrazu w tym formacie:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP
• [C-0-4] AVIF
  • Urządzenia muszą obsługiwać BITRATE_MODE_CQ i profil podstawowy.

Jeśli implementacje urządzeń obsługują kodowanie HEIC za pomocą android.media.MediaCodec w przypadku typu multimediów MIMETYPE_IMAGE_ANDROID_HEIC:

• [C-1-1] MUSI udostępniać kodek HEVC z akceleracją sprzętową, który obsługuje BITRATE_MODE_CQ tryb kontroli szybkości transmisji bitów, HEVCProfileMainStill profil i rozmiar klatki 512 × 512 pikseli.

5.1.5. Dekodowanie obrazu

Więcej informacji znajdziesz w sekcji 5.1.6. Szczegóły dotyczące kodeków obrazu.

Implementacje urządzeń MUSZĄ obsługiwać dekodowanie tego kodowania obrazu:

• [C-0-1] JPEG

• [C-0-2] GIF

• [C-0-3] PNG

• [C-0-4] BMP

• [C-0-5] WebP

• [C-0-6] Surowe

• [C-0-7] AVIF (profil podstawowy)

Jeśli implementacje urządzeń obsługują dekodowanie wideo HEVC:

• [C-1-1] MUSI obsługiwać dekodowanie obrazów HEIF (HEIC).

Dekodery obrazów obsługujące format o wysokiej głębi bitowej (co najmniej 9 bitów na kanał):

• [C-2-1] MUSI obsługiwać format wyjściowy w 8-bitowym odpowiedniku, jeśli zażąda tego aplikacja, np. za pomocą konfiguracji ARGB_8888 w android.graphics.Bitmap.

5.1.6. Szczegóły kodeków obrazu

Format/kodek	Szczegóły	Obsługiwane typy plików i formaty kontenerów
JPEG,	Podstawa + progresywna	JPEG (.jpg)
GIF		GIF (.gif),
PNG		PNG (.png)
BMP		BMP (.bmp),
WebP		WebP (.webp),
Nieprzetworzony		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Obraz, kolekcja obrazów, sekwencja obrazów	HEIF (.heif), HEIC (.heic)
AVIF (profil podstawowy)	Profil podstawowy obrazu, kolekcji obrazów i sekwencji obrazów	Kontener HEIF (.avif)

Enkodery i dekodery obrazów udostępniane przez interfejs MediaCodec API

• [C-1-1] MUSI obsługiwać elastyczny format kolorów YUV420 8:8:8 (COLOR_FormatYUV420Flexible) za pomocą CodecCapabilities.

• [C-SR-1] ZDECYDOWANIE ZALECANE jest obsługiwanie formatu kolorów RGB888 w trybie wejściowym Surface.

• [C-1-3] MUSI obsługiwać co najmniej 1 z tych formatów kolorów: płaski lub półpłaski YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (odpowiednik COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (odpowiednik COLOR_FormatYUV420SemiPlanar). ZDECYDOWANIE ZALECA SIĘ obsługę obu tych formatów.

5.1.7. Kodeki wideo

• Aby zapewnić akceptowalną jakość strumieniowania wideo w internecie i usług wideokonferencyjnych, urządzenia POWINNY używać sprzętowego kodeka VP8, który spełnia wymagania.

Jeśli implementacje urządzeń obejmują dekoder lub koder wideo:

• [C-1-1] Kodeki wideo MUSZĄ obsługiwać rozmiary wyjściowych i wejściowych buforów bajtowych, które mieszczą największą możliwą skompresowaną i nieskompresowaną klatkę zgodnie ze standardem i konfiguracją, ale nie mogą też przydzielać zbyt dużo pamięci.

• [C-1-2] Enkodery i dekodery wideo MUSZĄ obsługiwać elastyczne formaty kolorów YUV420 8:8:8 (COLOR_FormatYUV420Flexible) za pomocą CodecCapabilities.

• [C-1-3] Enkodery i dekodery wideo MUSZĄ obsługiwać co najmniej jeden z tych formatów kolorów: płaski lub półpłaski YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (odpowiednik COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (odpowiednik COLOR_FormatYUV420SemiPlanar). Zdecydowanie ZALECA SIĘ obsługę obu tych formatów.

• [C-SR-1] Enkodery i dekodery wideo ZDECYDOWANIE ZALECA się, aby obsługiwały co najmniej 1 z tych formatów: zoptymalizowany sprzętowo płaski lub półpłaski format koloru YUV420 8:8:8 (YV12, NV12, NV21 lub równoważny format zoptymalizowany przez dostawcę).

• [C-1-5] Dekodery wideo obsługujące format o wysokiej głębi bitowej (ponad 9 bitów na kanał) MUSZĄ obsługiwać format wyjściowy o równoważnej głębi 8-bitowej, jeśli zażąda tego aplikacja. Musi to być odzwierciedlone w obsłudze formatu kolorów YUV420 8:8:8 za pomocą android.media.MediaCodecInfo.

Jeśli implementacje urządzeń reklamują obsługę profilu HDR za pomocą elementu Display.HdrCapabilities, to:

• [C-2-1] MUSI obsługiwać analizowanie i przetwarzanie statycznych metadanych HDR.

Jeśli implementacje urządzeń reklamują obsługę odświeżania wewnątrzklatkowego za pomocą FEATURE_IntraRefresh w klasie MediaCodecInfo.CodecCapabilities:

• [C-3-1] MUSI obsługiwać okresy odświeżania w zakresie 10–60 klatek i dokładnie działać w zakresie 20% skonfigurowanego okresu odświeżania.

O ile aplikacja nie określi inaczej za pomocą klucza formatu KEY_COLOR_FORMAT, implementacje dekodera wideo:

• [C-4-1] MUSI domyślnie używać formatu kolorów zoptymalizowanego pod kątem wyświetlacza sprzętowego, jeśli jest skonfigurowany za pomocą wyjścia Surface.

• [C-4-2] MUSI domyślnie używać formatu kolorów YUV420 8:8:8 zoptymalizowanego pod kątem odczytu przez procesor, jeśli nie jest skonfigurowany do używania wyjścia Surface.

5.1.8. Lista kodeków wideo

Format/kodek	Szczegóły	Obsługiwane typy plików i formaty kontenerów
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)
H.264 AVC	Szczegółowe informacje znajdziesz w sekcjach 5.2 i 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, nie można przewijać) Matroska (.mkv, tylko dekodowanie)
H.265 HEVC	Szczegółowe informacje znajdziesz w sekcji 5.3.	MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)
MPEG-2	Profil główny	MPEG2-TS (.ts, nie można przewijać) MPEG-4 (.mp4, tylko dekodowanie) Matroska (.mkv, tylko dekodowanie)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)
VP8	Szczegółowe informacje znajdziesz w sekcjach 5.2 i 5.3.	WebM (.webm) Matroska (.mkv)
VP9	Szczegółowe informacje znajdziesz w sekcji 5.3.	WebM (.webm) Matroska (.mkv)
AV1	Szczegółowe informacje znajdziesz w sekcji 5.2 i sekcji 5.3.	MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)

5.1.9. Bezpieczeństwo kodeków multimediów

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń kodeków multimedialnych, jak opisano poniżej.

Android obsługuje OMX, interfejs API do akceleracji multimediów na wielu platformach, oraz Codec 2.0, interfejs API do akceleracji multimediów o niskim narzucie.

Jeśli urządzenia obsługują multimedia:

• [C-1-1] MUSI obsługiwać kodeki multimedialne za pomocą interfejsów API OMX lub Codec 2.0 (lub obu) zgodnie z Projektem Android Open Source i nie może wyłączać ani obchodzić zabezpieczeń. Nie oznacza to, że każdy kodek MUSI korzystać z interfejsu OMX lub Codec 2.0. Wymagane jest jedynie, aby obsługiwany był co najmniej jeden z tych interfejsów API, a obsługa dostępnych interfejsów API MUSI obejmować zabezpieczenia.

• [C-SR-1] Zdecydowanie zaleca się obsługę interfejsu Codec 2.0 API.

Jeśli implementacje urządzeń nie obsługują interfejsu Codec 2.0 API:

• [C-2-1] MUSI zawierać odpowiedni kodek oprogramowania OMX z projektu Android Open Source Project (jeśli jest dostępny) dla każdego formatu i typu multimediów (enkoder lub dekoder) obsługiwanego przez urządzenie.

• [C-2-2] Kodeki, których nazwy zaczynają się od „OMX.google”. MUSZĄ być oparte na kodzie źródłowym Projektu Android Open Source.

• [C-SR-2] ZDECYDOWANIE ZALECA się, aby kodeki programowe OMX działały w procesie kodeka, który nie ma dostępu do sterowników sprzętowych innych niż mapery pamięci.

Jeśli implementacje urządzeń obsługują interfejs Codec 2.0 API:

• [C-3-1] MUSI zawierać odpowiedni kodek oprogramowania Codec 2.0 z Projekt Android Open Source (jeśli jest dostępny) dla każdego formatu i typu multimediów (enkoder lub dekoder) obsługiwanego przez urządzenie.

• [C-3-2] MUSI zawierać kodeki oprogramowania Codec 2.0 w procesie kodeka oprogramowania udostępnionym w projekcie Android Open Source, aby umożliwić bardziej precyzyjne przyznawanie dostępu do kodeków oprogramowania.

• [C-3-3] Kodeki, których nazwy zaczynają się od „c2.android.” MUSZĄ być oparte na kodzie źródłowym Projektu Android Open Source.

5.1.10. Charakterystyka kodeka multimediów

Jeśli implementacje urządzeń obsługują kodeki multimediów:

• [C-1-1] MUSI zwracać prawidłowe wartości charakterystyki kodeka multimediów za pomocą interfejsu API MediaCodecInfo.

W szczególności:

• [C-1-2] Kodeki, których nazwy zaczynają się od „OMX”. MUSI korzystać z interfejsów API OMX i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa OMX IL.

• [C-1-3] Kodeki, których nazwy zaczynają się od „c2.”. MUSZĄ korzystać z interfejsu Codec 2.0 API i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa w Codec 2.0 na Androidzie.

• [C-1-4] Kodeki, których nazwy zaczynają się od „OMX.google.” lub „c2.android.”. NIE MOŻE być traktowany jako dostawca ani jako akcelerowany sprzętowo.

• [C-1-5] Kodeki działające w procesie kodeka (dostawcy lub systemu), które mają dostęp do sterowników sprzętu innych niż alokatory i mapery pamięci, NIE MOGĄ być uznawane za kodeki działające wyłącznie w oprogramowaniu.

• [C-1-6] Kodeki, których nie ma w projekcie Android Open Source Project lub które nie są oparte na kodzie źródłowym w tym projekcie, MUSZĄ być klasyfikowane jako kodeki dostawcy.

• [C-1-7] Kodeki, które korzystają z akceleracji sprzętowej, MUSZĄ być oznaczone jako akcelerowane sprzętowo.

• [C-1-8] Nazwy kodeków NIE MOGĄ wprowadzać w błąd. Na przykład kodeki o nazwie „dekodery” MUSZĄ obsługiwać dekodowanie, a kodeki o nazwie „enkodery” MUSZĄ obsługiwać kodowanie. Kodeki, których nazwy zawierają formaty multimediów, MUSZĄ obsługiwać te formaty.

Jeśli implementacje urządzeń obsługują kodeki wideo:

• [C-2-1] Wszystkie kodeki wideo MUSZĄ publikować dane o osiągalnej liczbie klatek na sekundę dla tych rozmiarów, jeśli są obsługiwane przez kodek:

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	176 x 144 piksele (H263, MPEG2, MPEG4) 352 x 288 pikseli (enkoder MPEG4, H263, MPEG2) 320 x 180 pikseli (VP8, VP8) 320 x 240 pikseli (inne)	704 x 576 pikseli (H263) 640 x 360 pikseli (VP8, VP9) 640 x 480 pikseli (koder MPEG4) 720 x 480 piks. (inne, AV1)	1408 x 1152 pikseli (H263) 1280 x 720 pikseli (inne, AV1)	1920 x 1080 pikseli (inne niż MPEG4, AV1)	3840 x 2160 pikseli (HEVC, VP9, AV1)

• [C-2-2] Kodeki wideo, które są określane jako akcelerowane sprzętowo, MUSZĄ publikować informacje o wydajności. Muszą one zawierać wszystkie obsługiwane standardowe punkty wydajności (wymienione w PerformancePoint interfejsie API), chyba że są one objęte innym obsługiwanym standardowym punktem wydajności.

• Dodatkowo powinni publikować rozszerzone punkty wydajności, jeśli obsługują utrzymywane wyniki filmu inne niż jedna ze standardowych wymienionych poniżej.

5.2. Kodowanie wideo

Jeśli implementacje urządzeń obsługują dowolny koder wideo i udostępniają go aplikacjom innych firm oraz ustawiają wartość
MediaFormat.KEY_BITRATE_MODE na BITRATE_MODE_VBR tak, aby koder działał w trybie zmiennej szybkości transmisji bitów, to o ile nie ma to wpływu na minimalną jakość, szybkość transmisji bitów po zakodowaniu :

• NIE POWINNA przekraczać w oknie przesuwnym o więcej niż 15% szybkości transmisji między interwałami klatek wewnątrzklatkowych (klatek I).
• NIE POWINNA przekraczać 100% przepływności w 1-sekundowym oknie przesuwnym.

Jeśli implementacje urządzeń obsługują dowolny koder wideo i udostępniają go aplikacjom innych firm oraz ustawiają wartość MediaFormat.KEY_BITRATE_MODE na BITRATE_MODE_CBR, aby koder działał w trybie stałej szybkości transmisji bitów, zakodowana szybkość transmisji bitów:

• [C-SR-2] ZDECYDOWANIE ZALECA SIĘ, aby nie przekraczać docelowej szybkości transmisji o więcej niż 15% w ruchomym oknie o długości 1 sekundy.

Jeśli implementacje urządzeń obejmują wbudowany ekran o przekątnej co najmniej 2,5 cala lub port wyjścia wideo albo deklarują obsługę aparatu za pomocą android.hardware.camera.anyflagi funkcji, to:

• [C-1-1] MUSI obsługiwać co najmniej jeden z enkoderów wideo VP8 lub H.264 i udostępniać go aplikacjom innych firm.
• POWINNO obsługiwać kodery wideo VP8 i H.264 oraz udostępniać je aplikacjom innych firm.

Jeśli implementacje urządzeń obsługują dowolny z enkoderów wideo H.264, VP8, VP9 lub HEVC i udostępniają go aplikacjom innych firm:

• [C-2-1] MUSI obsługiwać dynamicznie konfigurowane szybkości transmisji.
• POWINIEN obsługiwać zmienną liczbę klatek, w przypadku której koder wideo POWINIEN określać natychmiastowy czas trwania klatki na podstawie sygnatur czasowych buforów wejściowych i przydzielać zasoby bitowe na podstawie tego czasu trwania klatki.

Jeśli implementacje urządzeń obsługują koder wideo MPEG-4 SP i udostępniają go aplikacjom innych firm:

• POWINIEN obsługiwać dynamicznie konfigurowane szybkości transmisji bitów w przypadku obsługiwanego kodera.

Jeśli implementacje urządzeń udostępniają akcelerowane sprzętowo kodery wideo lub obrazów i obsługują co najmniej 1 podłączoną lub wtykową kamerę sprzętową udostępnianą za pomocą interfejsów API android.camera:

• [C-4-1] wszystkie akcelerowane sprzętowo kodery wideo i obrazów MUSZĄ obsługiwać kodowanie klatek z kamer sprzętowych.
• POWINIEN obsługiwać kodowanie klatek z kamer sprzętowych za pomocą wszystkich koderów wideo lub obrazów.

Jeśli implementacje urządzeń obsługują kodowanie HDR:

• [C-SR-1] Zdecydowanie zalecamy udostępnienie wtyczki do interfejsu API bezproblemowego transkodowania, która umożliwia konwersję z formatu HDR na SDR.

5.2.1. H.263

Jeśli implementacje urządzeń obsługują kodery H.263 i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI obsługiwać rozdzielczość QCIF (176 x 144) przy użyciu profilu podstawowego na poziomie 45. Rozdzielczość SQCIF jest opcjonalna.

5.2.2. H.264

Jeśli implementacje urządzeń obsługują kodek H.264:

• [C-1-1] MUSI obsługiwać profil podstawowy na poziomie 3. Obsługa funkcji ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) i RS (Redundant Slices) jest jednak OPCJONALNA. Ponadto w celu zachowania zgodności z innymi urządzeniami z Androidem ZALECAMY, aby koderzy nie używali funkcji ASO, FMO i RS w przypadku profilu podstawowego.
• [C-1-2] MUSI obsługiwać profile kodowania wideo w rozdzielczości SD (Standard Definition) podane w tej tabeli.
• POWINIEN obsługiwać profil główny na poziomie 4.
• POWINNO obsługiwać profile kodowania wideo HD (High Definition) zgodnie z tabelą poniżej.

Jeśli implementacje urządzeń zgłaszają obsługę kodowania H.264 w przypadku filmów w rozdzielczości 720p lub 1080p za pomocą interfejsów API multimediów:

• [C-2-1] MUSI obsługiwać profile kodowania w tabeli poniżej.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 240 pikseli	720 x 480 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli
Liczba klatek filmu	20 kl./s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	384 kb/s	2 Mb/s	4 Mb/s	10 Mb/s

5.2.3. VP8

Jeśli implementacje urządzeń obsługują kodek VP8:

• [C-1-1] MUSI obsługiwać profile kodowania wideo SD.
• POWINNY obsługiwać te profile kodowania wideo HD (High Definition):
• [C-1-2] MUSI obsługiwać zapisywanie plików Matroska WebM.
• POWINIEN udostępniać sprzętowy kodek VP8, który spełnia wymagania projektu WebM dotyczące sprzętowego kodowania RTC, aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo w internecie i usług wideokonferencyjnych.

Jeśli implementacje urządzeń zgłaszają obsługę kodowania VP8 w przypadku filmów o rozdzielczości 720p lub 1080p za pomocą interfejsów API multimediów, to:

• [C-2-1] MUSI obsługiwać profile kodowania w tabeli poniżej.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli
Liczba klatek filmu	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	4 Mb/s	10 Mb/s

5.2.4. VP9

Jeśli implementacje urządzeń obsługują kodek VP9:

• [C-1-2] MUSI obsługiwać profil 0 na poziomie 3.
• [C-1-1] MUSI obsługiwać zapisywanie plików Matroska WebM.
• [C-1-3] MUSI generować dane CodecPrivate.
• POWINIEN obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• [C-SR-1] ZDECYDOWANIE ZALECA się obsługę profili dekodowania HD zgodnie z tabelą poniżej, jeśli występuje koder sprzętowy.

	SD	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	720 x 480 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli	3840 x 2160 pikseli
Liczba klatek filmu	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

Jeśli implementacje urządzeń deklarują obsługę profilu 2 lub profilu 3 za pomocą interfejsów API multimediów:

• Obsługa formatu 12-bitowego jest OPCJONALNA.

5.2.5. H.265

Jeśli implementacje urządzeń obsługują kodek H.265:

• [C-1-1] MUSI obsługiwać profil główny na poziomie 3 w rozdzielczości do 512 x 512.
• [C-SR-1] Zdecydowanie zaleca się obsługę profilu SD 720 x 480 i profili kodowania HD zgodnie z tabelą poniżej, jeśli dostępny jest koder sprzętowy.

	SD	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	720 x 480 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli	3840 x 2160 pikseli
Liczba klatek filmu	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

5.2.6. AV1

Jeśli implementacje urządzeń obsługują kodek AV1, to:

• [C-1-1] MUSI obsługiwać profil główny, w tym treści 8-bitowe i 10-bitowe.

• [C-1-2] MUSI publikować dane o skuteczności, tzn. raportować dane o skuteczności za pomocą interfejsów API getSupportedFrameRatesFor() lub getSupportedPerformancePoints() w przypadku obsługiwanych rozdzielczości w tabeli poniżej.

• [C-1-3] MUSI akceptować metadane HDR i przesyłać je do strumienia bitów.

Jeśli koder AV1 jest akcelerowany sprzętowo, to:

• [C-2-1] MUSI obsługiwać profil kodowania do HD1080p włącznie z tabeli poniżej:

	SD	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	720 x 480 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli	3840 x 2160 pikseli
Liczba klatek filmu	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	5 Mb/s	8 Mb/s	16 Mb/s	50 Mb/s

5.3. Dekodowanie wideo

5.3.1. MPEG-2

Jeśli implementacje urządzeń obsługują dekodery MPEG-2:

• [C-1-1] MUSI obsługiwać profil główny na wysokim poziomie.

5.3.2. H.263

Jeśli implementacje urządzeń obsługują dekodery H.263, to:

• [C-1-1] MUSI obsługiwać profil podstawowy na poziomie 30 (rozdzielczości CIF, QCIF i SQCIF przy 30 kl./s i 384 kb/s) oraz na poziomie 45 (rozdzielczości QCIF i SQCIF przy 30 kl./s i 128 kb/s).

5.3.3. MPEG-4

Jeśli implementacje urządzeń z dekoderami MPEG-4:

• [C-1-1] MUSI obsługiwać Simple Profile Level 3.

5.3.4. H.264

Jeśli implementacje urządzeń obsługują dekodery H.264:

• [C-1-1] MUSI obsługiwać profil główny na poziomie 3.1 i profil podstawowy. Obsługa ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) i RS (Redundant Slices) jest OPCJONALNA.
• [C-1-2] MUSI być w stanie dekodować filmy w profilach SD (Standard Definition) wymienionych w tabeli poniżej i zakodowanych w profilu podstawowym i Main Level 3.1 (w tym 720p30).
• POWINNO umożliwiać dekodowanie filmów w profilach HD (High Definition) zgodnie z tabelą poniżej.

Jeśli wysokość zgłoszona przez metodę Display.getSupportedModes() jest równa rozdzielczości filmu lub od niej większa, implementacje urządzenia:

• [C-2-1] MUSI obsługiwać profile dekodowania wideo HD 720p w tabeli poniżej.
• [C-2-2] MUSI obsługiwać profile dekodowania wideo HD 1080p w tabeli poniżej.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 240 pikseli	720 x 480 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli
Liczba klatek filmu	30 klatek/s	30 klatek/s	60 kl./s	30 kl./s (60 kl./stelewizja)
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

5.3.5. H.265 (HEVC)

Jeśli implementacje urządzeń obsługują kodek H.265:

• [C-1-1] MUSI obsługiwać profil główny na poziomie 3 i profil dekodowania wideo SD zgodnie z tabelą poniżej.
• POWINIEN obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• [C-1-2] MUSI obsługiwać profile dekodowania HD wskazane w tabeli poniżej, jeśli jest dostępny dekoder sprzętowy.

Jeśli wysokość zgłoszona przez metodę Display.getSupportedModes() jest równa rozdzielczości wideo lub od niej większa:

• [C-2-1] Urządzenia MUSZĄ obsługiwać dekodowanie co najmniej jednego z formatów H.265 lub VP9 w profilach 720, 1080 i UHD.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	352 x 288 pikseli	720 x 480 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli	3840 x 2160 pikseli
Liczba klatek filmu	30 klatek/s	30 klatek/s	30 klatek/s	30/60 kl./s (60 kl./stelewizor z dekodowaniem sprzętowym H.265)	60 kl./s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

Jeśli implementacje urządzeń deklarują obsługę profilu HDR za pomocą interfejsów Media API:

• [C-3-1] Urządzenia MUSZĄ akceptować wymagane metadane HDR z aplikacji, a także obsługiwać wyodrębnianie i przesyłanie wymaganych metadanych HDR ze strumienia bitów lub kontenera.
• [C-3-2] Urządzenia MUSZĄ prawidłowo wyświetlać treści HDR na ekranie urządzenia lub na standardowym porcie wyjściowym wideo (np. HDMI).

5.3.6. VP8

Jeśli implementacje urządzeń obsługują kodek VP8:

• [C-1-1] MUSI obsługiwać profile dekodowania SD w tabeli poniżej.
• POWINIEN używać sprzętowego kodeka VP8, który spełnia wymagania.
• POWINNO obsługiwać profile dekodowania HD w tabeli poniżej.

Jeśli wysokość podana przez metodę Display.getSupportedModes() jest równa lub większa od rozdzielczości filmu:

• [C-2-1] Urządzenia MUSZĄ obsługiwać profile 720p w tabeli poniżej.
• [C-2-2] Urządzenia MUSZĄ obsługiwać profile 1080p w tabeli poniżej.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli
Liczba klatek filmu	30 klatek/s	30 klatek/s	30 kl./s (60 kl./stelewizja)	30 (60 kl./sTelewizor)
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

5.3.7. VP9

Jeśli implementacje urządzeń obsługują kodek VP9:

• [C-1-1] MUSI obsługiwać profile dekodowania wideo SD zgodnie z tabelą poniżej.
• POWINIEN obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.

Jeśli implementacje urządzeń obsługują kodek VP9 i dekoder sprzętowy:

• [C-2-1] MUSI obsługiwać profile dekodowania HD wskazane w tabeli poniżej.

Jeśli wysokość zgłoszona przez metodę Display.getSupportedModes() jest równa rozdzielczości wideo lub od niej większa:

• [C-3-1] Urządzenia MUSZĄ obsługiwać dekodowanie co najmniej jednego z formatów VP9 lub H.265 w przypadku profili 720, 1080 i UHD.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli	3840 x 2160 pikseli
Liczba klatek filmu	30 klatek/s	30 klatek/s	30 klatek/s	30 kl./s (60 kl./sTelewizor ze sprzętowym dekodowaniem VP9)	60 kl./s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

Jeśli implementacje urządzeń deklarują obsługę VP9Profile2 lub VP9Profile3 za pomocą interfejsów API multimediów 'CodecProfileLevel':

• Obsługa formatu 12-bitowego jest OPCJONALNA.

Jeśli implementacje urządzeń deklarują obsługę profilu HDR (VP9Profile2HDR,VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) za pomocą interfejsów API multimediów:

• [C-4-1] Implementacje urządzeń MUSZĄ akceptować wymagane metadane HDR (KEY_HDR_STATIC_INFO dla wszystkich profili HDR, a także „KEY_HDR10_PLUS_INFO” dla profili HDR10Plus) z aplikacji. Muszą też obsługiwać wyodrębnianie i przesyłanie wymaganych metadanych HDR ze strumienia bitów lub kontenera.
• [C-4-2] Urządzenia MUSZĄ prawidłowo wyświetlać treści HDR na ekranie urządzenia lub na standardowym porcie wyjściowym wideo (np. HDMI).

5.3.8. Dolby Vision

Jeśli implementacje urządzeń deklarują obsługę dekodera Dolby Vision za pomocą HDR_TYPE_DOLBY_VISION, to:

• [C-1-1] MUSI udostępniać ekstraktor obsługujący Dolby Vision.

• [C-1-2] MUSI prawidłowo wyświetlać treści w Dolby Vision na ekranie urządzenia lub na zewnętrznym wyświetlaczu podłączonym za pomocą standardowego portu wyjściowego wideo (np. HDMI).

• [C-1-3] MUSI ustawić identyfikator ścieżki wstecznie kompatybilnych warstw podstawowych (jeśli występują) na taki sam jak identyfikator ścieżki połączonej warstwy Dolby Vision.

5.3.9. AV1

Jeśli implementacje urządzeń obsługują kodek AV1 i udostępniają go aplikacjom innych firm:

• [C-1-1] MUSI obsługiwać profil główny, w tym treści 8-bitowe i 10-bitowe.

Jeśli implementacje urządzeń obsługują kodek AV1 z akcelerowanym sprzętowo dekoderem, to:

• [C-2-1] MUSI obsługiwać dekodowanie co najmniej profili dekodowania wideo HD 720p z tabeli poniżej, gdy wysokość zgłaszana przez metodę Display.getSupportedModes() jest równa lub większa niż 720p.
• [C-2-2] MUSI obsługiwać dekodowanie co najmniej profili dekodowania wideo HD 1080p z tabeli poniżej, gdy wysokość zgłoszona przez metodę Display.getSupportedModes() jest równa lub większa niż 1080p.

	SD	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	720 x 480 pikseli	1280 x 720 pikseli	1920 x 1080 pikseli	3840 x 2160 pikseli
Liczba klatek filmu	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	5 Mb/s	8 Mb/s	16 Mb/s	50 Mb/s

Jeśli implementacje urządzeń obsługują profil HDR za pomocą interfejsów Media API, to:

• [C-3-1] MUSI obsługiwać wyodrębnianie i przesyłanie metadanych HDR ze strumienia bitów lub kontenera.

• [C-3-2] MUSI prawidłowo wyświetlać treści HDR na ekranie urządzenia lub na standardowym porcie wyjściowym wideo (np. HDMI).

5.4. Nagrywanie dźwięku

Niektóre wymagania wymienione w tej sekcji są oznaczone jako SHOULD od Androida 4.3, ale w przypadku przyszłych wersji planujemy zmienić je na MUST w definicji zgodności. ZDECYDOWANIE ZALECA SIĘ, aby obecne i nowe urządzenia z Androidem spełniały te wymagania, które są oznaczone jako SHOULD. W przeciwnym razie po uaktualnieniu do przyszłej wersji nie będą one zgodne z Androidem.

5.4.1. Rejestrowanie surowego dźwięku i informacje o mikrofonie

Jeśli implementacje urządzeń deklarują android.hardware.microphone, to:

• [C-1-1] MUSI zezwalać na przechwytywanie surowych treści audio w przypadku każdego strumienia wejściowego AudioRecord lub AAudio, który został otwarty. Musi obsługiwać co najmniej te cechy:

  • Format: Linear PCM, 16-bit
  • Częstotliwości próbkowania: 8000, 11025, 16000, 44100, 48000 Hz
  • Kanały: mono
  • Źródła dźwięku: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED lub VOICE_PERFORMANCE. Dotyczy to również odpowiednich ustawień wstępnych danych wejściowych w AAudio, np. AAUDIO_INPUT_PRESET_CAMCORDER.

• POWINNO umożliwiać rejestrowanie surowych treści audio o tych cechach:

  • Format: Linear PCM, 16-bitowy i 24-bitowy
  • Częstotliwości próbkowania: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
  • Kanały: tyle kanałów, ile mikrofonów ma urządzenie.

• [C-1-2] MUSI rejestrować dźwięk z częstotliwością próbkowania powyżej podanej, bez upsamplingu.

• [C-1-3] MUSI zawierać odpowiedni filtr wygładzający, gdy powyższe częstotliwości próbkowania są rejestrowane z próbkowaniem w dół.

• POWINNO umożliwiać nagrywanie surowych treści audio w jakości radia AM i DVD, co oznacza, że:

  • Format: Linear PCM, 16-bit
  • Częstotliwości próbkowania: 22050, 48000 Hz
  • Kanały: stereo

• [C-1-4] MUSI obsługiwać interfejs MicrophoneInfo API i prawidłowo wypełniać informacje o dostępnych mikrofonach na urządzeniu dostępnych dla aplikacji innych firm za pomocą interfejsu AudioManager.getMicrophones() API dla aktywnego AudioRecord przy użyciu MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED lub VOICE_PERFORMANCE. Jeśli implementacje urządzeń umożliwiają odbiór radia AM i nagrywanie surowych treści audio w jakości DVD:

• [C-2-1] MUSI rejestrować bez zwiększania częstotliwości próbkowania przy żadnym współczynniku wyższym niż 16000:22050 lub 44100:48000.

• [C-2-2] MUSI zawierać odpowiedni filtr wygładzający w przypadku próbkowania w górę lub w dół.

5.4.2. Nagrywanie na potrzeby rozpoznawania głosu

Jeśli implementacje urządzeń deklarują android.hardware.microphone, to:

• [C-1-1] MUSI przechwytywaćandroid.media.MediaRecorder.AudioSource.VOICE_RECOGNITION źródło dźwięku z jedną z tych częstotliwości próbkowania: 44 100 i 48 000.
• [C-1-2] MUSI domyślnie wyłączać przetwarzanie dźwięku w celu redukcji szumów podczas nagrywania strumienia audio ze źródła dźwięku AudioSource.VOICE_RECOGNITION.

• [C-1-3] MUSI domyślnie wyłączać automatyczną regulację wzmocnienia podczas nagrywania strumienia audio ze źródła dźwięku AudioSource.VOICE_RECOGNITION.

• POWINIEN wykazywać w zakresie średnich częstotliwości w przybliżeniu płaską charakterystykę amplitudy w funkcji częstotliwości, a konkretnie ±3 dB w zakresie od 100 Hz do 4000 Hz w przypadku każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania mowy.

• [C-SR-1] Zdecydowanie zaleca się, aby mikrofony wykazywały poziomy amplitudy w zakresie niskich częstotliwości, a konkretnie od ±20 dB w zakresie od 30 Hz do 100 Hz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania głosu.

• [C-SR-2] ZDECYDOWANIE ZALECA SIĘ, aby wykazywały poziomy amplitudy w zakresie wysokich częstotliwości: w szczególności od ±30 dB w zakresie od 4000 Hz do 22 kHz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania głosu.

• POWINNO ustawić czułość wejścia audio tak, aby źródło dźwięku w postaci tonu sinusoidalnego o częstotliwości 1000 Hz odtwarzanego na poziomie ciśnienia akustycznego 90 dB (SPL) (mierzonym obok mikrofonu) dawało idealną odpowiedź RMS 2500 w zakresie od 1770 do 3530 dla 16-bitowych próbek (lub -22,35 dB ±3 dB w pełnej skali dla próbek zmiennoprzecinkowych lub podwójnej precyzji) dla każdego mikrofonu używanego do nagrywania źródła dźwięku rozpoznawania głosu.

• POWINNO nagrywać strumień audio rozpoznawania głosu w taki sposób, aby poziomy amplitudy PCM liniowo śledziły zmiany SPL wejściowego w zakresie co najmniej 30 dB od -18 dB do +12 dB w odniesieniu do 90 dB SPL przy mikrofonie.

• POWINNO nagrywać strumień audio rozpoznawania głosu z całkowitymi zniekształceniami harmonicznymi (THD) mniejszymi niż 1% przy częstotliwości 1 kHz i poziomie wejściowym 90 dB SPL przy mikrofonie.

Jeśli implementacje urządzeń deklarują android.hardware.microphone i technologie tłumienia (redukcji) szumów dostosowane do rozpoznawania mowy:

• [C-2-1] MUSI umożliwiać sterowanie tym efektem dźwiękowym za pomocą interfejsu API.android.media.audiofx.NoiseSuppressor
• [C-2-2] MUSI jednoznacznie identyfikować każdą implementację technologii eliminowania szumu za pomocą pola AudioEffect.Descriptor.uuid.

5.4.3. Przechwytywanie na potrzeby przekierowania odtwarzania

Klasa android.media.MediaRecorder.AudioSource obejmuje REMOTE_SUBMIXźródło dźwięku.

Jeśli implementacje urządzeń deklarują zarówno android.hardware.audio.output, jak i android.hardware.microphone, to:

• [C-1-1] MUSI prawidłowo zaimplementować REMOTE_SUBMIX źródło dźwięku, aby gdy aplikacja używa interfejsu android.media.AudioRecord API do nagrywania z tego źródła dźwięku, rejestrowała miks wszystkich strumieni audio z wyjątkiem:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. Usuwanie echa akustycznego

Jeśli implementacje urządzeń deklarują android.hardware.microphone, to:

• POWINIEN implementować technologię usuwania echa akustycznego (AEC) dostosowaną do komunikacji głosowej i stosowaną na ścieżce przechwytywania podczas przechwytywania za pomocą AudioSource.VOICE_COMMUNICATION.

5.4.5. Równoczesne przechwytywanie

Jeśli implementacje urządzeń deklarują android.hardware.microphone, MUSZĄ implementować równoczesne przechwytywanie zgodnie z opisem w tym dokumencie. Więcej szczegółów:

• [C-1-1] MUSI zezwalać na jednoczesny dostęp do mikrofonu przez usługę ułatwień dostępu rejestrującą dźwięk za pomocą AudioSource.VOICE_RECOGNITION i co najmniej 1 aplikację rejestrującą dźwięk za pomocą dowolnego AudioSource.
• [C-1-2] MUSI zezwalać na jednoczesny dostęp do mikrofonu preinstalowanej aplikacji, która pełni rolę Asystenta, oraz co najmniej 1 aplikacji rejestrującej dźwięk za pomocą dowolnego interfejsu API AudioSource z wyjątkiem interfejsów AudioSource.VOICE_COMMUNICATION i AudioSource.CAMCORDER.
• [C-1-3] MUSI wyciszać przechwytywanie dźwięku w przypadku wszystkich innych aplikacji z wyjątkiem usług ułatwień dostępu, gdy aplikacja przechwytuje dźwięk za pomocą interfejsu AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER. Jeśli jednak aplikacja rejestruje dźwięk za pomocą interfejsu AudioSource.VOICE_COMMUNICATION, inna aplikacja może rejestrować połączenie głosowe, jeśli jest aplikacją uprzywilejowaną (wstępnie zainstalowaną) z uprawnieniem CAPTURE_AUDIO_OUTPUT.

• [C-1-4] Jeśli 2 lub więcej aplikacji rejestruje dźwięk jednocześnie i żadna z nich nie ma interfejsu na wierzchu, dźwięk otrzymuje ta, która rozpoczęła rejestrowanie najpóźniej.

5.5. Odtwarzanie dźwięku

Android obsługuje odtwarzanie dźwięku przez aplikacje za pomocą urządzenia wyjściowego audio zgodnie z sekcją 7.8.2.

5.5.1. Odtwarzanie surowego dźwięku

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

• [C-1-1] MUSI umożliwiać odtwarzanie surowych treści audio o tych cechach:

  • Formaty źródłowe: Linear PCM, 16-bitowy, 8-bitowy, zmiennoprzecinkowy
  • Kanały: mono, stereo, prawidłowe konfiguracje wielokanałowe z maksymalnie 8 kanałami
  • Częstotliwości próbkowania (w Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 w przypadku konfiguracji kanałów wymienionych powyżej
    • 96 000 w mono i stereo

5.5.2. Efekty audio

Android udostępnia interfejs API efektów dźwiękowych dla implementacji na urządzeniach.

Jeśli implementacje urządzenia deklarują funkcję android.hardware.audio.output,

• [C-1-1] MUSI obsługiwać implementacje EFFECT_TYPE_EQUALIZER i EFFECT_TYPE_LOUDNESS_ENHANCER, którymi można sterować za pomocą podklas AudioEffect Equalizer i LoudnessEnhancer.

• [C-1-2] MUSI obsługiwać implementację interfejsu API wizualizatora, którą można sterować za pomocą klasy Visualizer.

• [C-1-3] MUSI obsługiwać implementację EFFECT_TYPE_DYNAMICS_PROCESSING, którą można kontrolować za pomocą podklasy AudioEffectDynamicsProcessing.

• [C-1-4] MUSI obsługiwać efekty dźwiękowe z wejściem i wyjściem zmiennoprzecinkowym, gdy wyniki efektu są zwracane do potoku audio platformy. Dotyczy to typowych efektów wstawianych lub pomocniczych, takich jak korektor. Rekomendowane jest równoważne działanie, gdy wyniki efektu nie są widoczne w potoku audio platformy, np. w przypadku efektów przetwarzania końcowego lub efektów przeniesionych.

• [C-1-5] MUSI zapewnić, że efekty audio obsługują wiele kanałów, aż do liczby kanałów miksera, zwanej też FCC_LIMIT, gdy wyniki efektu są zwracane do potoku audio platformy. Dotyczy to typowych efektów wstawianych lub pomocniczych, ale nie obejmuje efektów specjalnych, takich jak downmix, upmix czy efekty przestrzenne, które zmieniają liczbę kanałów. Zaleca się równoważne działanie, gdy efekty nie są widoczne w potoku audio platformy, np. w przypadku efektów przetwarzania końcowego lub efektów przeniesionych.

• POWINIEN obsługiwać implementacje EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB i EFFECT_TYPE_VIRTUALIZER, którymi można sterować za pomocą podklas AudioEffect: BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.

• [C-SR-1] ZDECYDOWANIE ZALECANE jest obsługiwanie efektów w przypadku reprezentacji zmiennoprzecinkowej i wielokanałowych.

5.5.3. Głośność wyjścia audio

Implementacje urządzeń z systemem Automotive:

• POWINNO umożliwiać dostosowywanie głośności dźwięku oddzielnie dla każdego strumienia audio na podstawie typu treści lub użycia zdefiniowanego przez AudioAttributes oraz użycia dźwięku w samochodzie zdefiniowanego publicznie w android.car.CarAudioManager.

5.5.4. Odciążanie dźwięku

Jeśli implementacje urządzeń obsługują odtwarzanie z odciążaniem audio:

• [C-SR-1] Zdecydowanie zaleca się przycinanie odtwarzanych bez przerw treści audio między 2 klipami w tym samym formacie zgodnie z informacjami podanymi w interfejsie AudioTrack gapless API i kontenerze multimedialnym dla odtwarzacza MediaPlayer.

• [C-SR-2] ZDECYDOWANIE ZALECA się wdrożenie odtwarzania z przeniesieniem obciążenia w przypadku formatów AAC, MP3, OPUS i PCM.

5.5.5. Parametry odtwarzania

5.6. Opóźnienie dźwięku

Opóźnienie dźwięku to czas, jaki upływa od momentu, w którym sygnał audio przechodzi przez system. Wiele klas aplikacji wymaga krótkich opóźnień, aby uzyskać efekty dźwiękowe w czasie rzeczywistym.

Na potrzeby tej sekcji używaj tych definicji:

• opóźnienie wyjściowe. Odstęp czasu między zapisaniem przez aplikację ramki danych zakodowanych w formacie PCM a odtworzeniem odpowiadającego jej dźwięku w otoczeniu za pomocą przetwornika na urządzeniu lub opuszczeniem urządzenia przez sygnał przez port, dzięki czemu można go zaobserwować z zewnątrz.

• opóźnienie wyjścia w trybie zimnym. Czas między rozpoczęciem strumienia wyjściowego a czasem prezentacji pierwszej klatki na podstawie sygnatur czasowych, gdy system wyjścia audio był bezczynny i wyłączony przed żądaniem.

• ciągły czas oczekiwania na wyjście. Opóźnienie wyjściowe w przypadku kolejnych klatek po rozpoczęciu odtwarzania dźwięku przez urządzenie.

• opóźnienie wejściowe. Odstęp czasu między momentem, w którym dźwięk jest odtwarzany przez środowisko na urządzeniu za pomocą przetwornika lub sygnał dociera do urządzenia przez port, a momentem, w którym aplikacja odczytuje odpowiednią ramkę danych zakodowanych w PCM.

• utracone dane wejściowe. Początkowa część sygnału wejściowego, która jest bezużyteczna lub niedostępna.

• opóźnienie przy zimnym starcie. Czas między rozpoczęciem przesyłania strumieniowego a otrzymaniem pierwszej prawidłowej klatki, gdy system wejścia audio był bezczynny i wyłączony przed żądaniem.

• ciągłe opóźnienie sygnału wejściowego. Opóźnienie wejściowe w przypadku kolejnych klatek podczas rejestrowania dźwięku przez urządzenie.

• ciągłe opóźnienie w obie strony. Suma opóźnienia ciągłego wejścia i opóźnienia ciągłego wyjścia oraz jednego okresu buforowania. Okres buforowania umożliwia aplikacji przetworzenie sygnału i zmniejszenie różnicy faz między strumieniami wejściowym i wyjściowym.

• Interfejs API kolejki buforów PCM OpenSL ES. Zestaw interfejsów API OpenSL ES związanych z PCM w ramach Android NDK.

• AAudio native audio API Zestaw interfejsów AAudio w ramach Android NDK.

• Sygnatura czasowa. Para składająca się z względnej pozycji klatki w strumieniu i szacowanego czasu, w którym ta klatka wchodzi do potoku przetwarzania dźwięku na powiązanym punkcie końcowym lub z niego wychodzi. Zobacz też AudioTimestamp.

• glitch. Chwilowe przerwanie lub nieprawidłowa wartość próbki w sygnałach audio, zwykle spowodowane niedoborem danych w buforze wyjściowym, nadmiarem danych w buforze wejściowym lub innym źródłem szumu cyfrowego lub analogowego.

• średnie odchylenie bezwzględne (MAD). Średnia wartość bezwzględna odchyleń od średniej dla zbioru wartości.

• Opóźnienie od dotknięcia do dźwięku (TTL), mierzone za pomocą CTS Verifier, to czas między dotknięciem ekranu a usłyszeniem w głośniku dźwięku wygenerowanego w wyniku tego dotknięcia. Jest to średnia z 5 pomiarów wykonanych za pomocą natywnego interfejsu AAudio API do obsługi dźwięku wyjściowego.

• Opóźnienie w obie strony (RTL), mierzone przez CTS Verifier, to średnie opóźnienie ciągłe w 5 pomiarach, mierzone na ścieżce sprzężenia zwrotnego, która przekazuje dane wyjściowe z powrotem do danych wejściowych, przy użyciu natywnego interfejsu AAudio API.

  Ścieżki sprzężenia zwrotnego to:

  • Głośnik/mikrofon: wbudowany głośnik do wbudowanego mikrofonu.
  • Analogowe: gniazdo analogowe 3,5 mm i adapter pętli zwrotnej.
  • USB: przejściówka USB na 3,5 mm i przejściówka sprzężenia zwrotnego lub interfejs audio USB i kable sprzężenia zwrotnego.

• FEATURE_AUDIO_LOW_LATENCY Zadeklarowano funkcję android.hardware.audio.low_latency.

• FEATURE_AUDIO_PRO. Zadeklarowano funkcję android.hardware.audio.pro.

• MPC Media Performance Class.

• opóźnienie śledzenia ruchu głowy. Czas, jaki upływa od wykrycia ruchu głowy przez moduł IMU do wykrycia przez przetworniki słuchawek zmiany dźwięku spowodowanej tym ruchem.

Jeśli implementacje urządzeń deklarują android.hardware.audio.output, MUSZĄ spełniać lub przekraczać te wymagania:

• [C-1-1] Wymaganie usunięte w Androidzie 15.

• [C-1-2] Opóźnienie wyjścia w przypadku zimnego startu nie przekracza 500 milisekund.

• [C-1-3] Otwieranie strumienia wyjściowego za pomocą funkcji AAudioStreamBuilder_openStream() MUSI trwać krócej niż 1000 milisekund.

• [C-1-4] Obliczone opóźnienia w obie strony na podstawie sygnatur czasowych wejścia i wyjścia zwracanych przez AAudioStream_getTimestamp MUSZĄ mieścić się w zakresie 200 ms od zmierzonego opóźnienia w obie strony dla AAUDIO_PERFORMANCE_MODE_NONE i AAUDIO_PERFORMANCE_MODE_LOW_LATENCY w przypadku głośników, słuchawek przewodowych i słuchawek bezprzewodowych.

• [C-SR-1] Wymaganie usunięte w Androidzie 15.

• [C-SR-2] Wymaganie usunięte w Androidzie 15.

• [C-SR-4] Wymaganie usunięte w Androidzie 15.

• [C-SR-5] Wymaganie usunięte w Androidzie 15.

• [C-SR-6] Wymaganie usunięte w Androidzie 15.

• [C-SR-7] Wymaganie usunięte w Androidzie 15.

• [C-2-1] Wymaganie usunięte w Androidzie 15.

Jeśli implementacje urządzeń obejmują android.hardware.microphone, MUSZĄ spełniać te wymagania dotyczące dźwięku wejściowego:

• [C-3-1] Wymaganie usunięte w Androidzie 15.

• [C-3-2] Opóźnienie danych wejściowych w przypadku uruchomienia „na zimno” nie przekracza 500 milisekund.

• [C-3-3] Otwieranie strumienia wejściowego za pomocą funkcji AAudioStreamBuilder_openStream() MUSI trwać krócej niż 1000 milisekund.

• [C-SR-8] Wymaganie usunięte w Androidzie 15.

• [C-SR-11] Wymaganie usunięte w Androidzie 15.

• [C-SR-12] Wymaganie usunięte w Androidzie 15.

W tabeli poniżej znajdziesz wymagania dotyczące RTL w przypadku implementacji na urządzeniach przenośnych zgodnie z sekcją 2.2.1, które deklarują android.hardware.audio.output i android.hardware.microphone.

W tabeli poniżej znajdziesz wymagania dotyczące parametru TTL w przypadku implementacji na urządzeniach przenośnych, zgodnie z definicją w punkcie 2.2.1, które deklarują android.hardware.audio.output i android.hardware.microphone.

Jeśli implementacje urządzeń obejmują obsługę spatial audio z śledzeniem ruchu głowy i deklarują flagę PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, to:

• [C-4-1] MUSI wykazywać maksymalne opóźnienie między śledzeniem ruchu głowy a aktualizacją dźwięku wynoszące 300 ms.

5.7. Protokoły sieciowe

Implementacje urządzeń MUSZĄ obsługiwać protokoły sieci multimedialnych do odtwarzania dźwięku i wideo zgodnie z dokumentacją pakietu Android SDK.

W przypadku każdego kodeka i formatu kontenera, które urządzenie musi obsługiwać:

• [C-1-1] MUSI obsługiwać ten kodek lub kontener w protokołach HTTP i HTTPS.

• [C-1-2] MUSI obsługiwać odpowiednie formaty segmentów multimedialnych zgodnie z tabelą formatów segmentów multimedialnych poniżej w ramach protokołu HTTP Live Streaming w wersji 7.

• [C-1-3] MUSI obsługiwać odpowiednie formaty ładunku RTSP, jak pokazano w tabeli RTSP poniżej. Wyjątki znajdziesz w przypisach do tabeli w sekcji 5.1.

Formaty segmentów multimedialnych

Formaty segmentów	Źródła	Wymagana obsługa kodeków
Zapis strumienia MPEG-2	ISO 13818	Kodeki wideo: H264 AVC MPEG-4 SP MPEG-2 Szczegółowe informacje o H264 AVC, MPEG2-4 SP i MPEG-2 znajdziesz w sekcji 5.1.8. Kodeki audio: AAC Szczegółowe informacje o AAC i jego odmianach znajdziesz w sekcji 5.1.3.
AAC z ramkami ADTS i tagami ID3	ISO 13818-7	Szczegółowe informacje o AAC i jego odmianach znajdziesz w sekcji 5.1.1 .
WebVTT	WebVTT

RTSP (RTP, SDP)

Nazwa profilu	Źródła	Wymagana obsługa kodeków
H264 AVC	RFC 6184	Szczegółowe informacje o H264 AVC znajdziesz w sekcji 5.1.8.
MP4A-LATM	RFC 6416	Szczegółowe informacje o AAC i jego odmianach znajdziesz w sekcji 5.1.3.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Szczegółowe informacje o H263 znajdziesz w sekcji 5.1.8.
H263-2000	RFC 4629	Szczegółowe informacje o H263 znajdziesz w sekcji 5.1.8.
AMR	RFC 4867	Szczegółowe informacje o AMR-NB znajdziesz w sekcji 5.1.3.
AMR-WB	RFC 4867	Szczegółowe informacje o AMR-WB znajdziesz w sekcji 5.1.3.
MP4V-ES	RFC 6416	Szczegółowe informacje o MPEG-4 SP znajdziesz w sekcji 5.1.8.
mpeg4-generic	RFC 3640	Szczegółowe informacje o AAC i jego odmianach znajdziesz w sekcji 5.1.3.
MP2T	RFC 2250	Szczegółowe informacje znajdziesz w sekcji Zapis strumienia MPEG-2 poniżej Transmisji na żywo przez HTTP.

5.8. Secure Media

Jeśli implementacje urządzeń obsługują bezpieczne wyjście wideo i bezpieczne powierzchnie, to:

• [C-1-1] MUSI deklarować obsługę Display.FLAG_SECURE.

Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE i obsługują protokół wyświetlania bezprzewodowego:

• [C-2-1] MUSI zabezpieczać połączenie za pomocą silnego mechanizmu kryptograficznego, takiego jak HDCP 2.x lub nowszy, w przypadku wyświetlaczy podłączonych za pomocą protokołów bezprzewodowych, takich jak Miracast.

Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE i obsługują przewodowy wyświetlacz zewnętrzny:

• [C-3-1] MUSI obsługiwać HDCP w wersji 1.2 lub nowszej w przypadku wszystkich wyświetlaczy zewnętrznych podłączonych przez dostępny dla użytkownika port przewodowy.

5.9. Cyfrowy interfejs do instrumentów muzycznych (MIDI)

Jeśli implementacje urządzeń zgłaszają obsługę funkcji android.software.midiza pomocą klasy android.content.pm.PackageManager, to:

• [C-1-1] MUSI obsługiwać MIDI we wszystkich transportach sprzętowych obsługujących MIDI, w przypadku których zapewnia ogólną łączność inną niż MIDI, jeśli takie transporty to:

  • Tryb hosta USB, sekcja 7.7
  • MIDI over Bluetooth LE w roli centralnej, sekcja 7.4.3

• [C-1-2] MUSI obsługiwać transport oprogramowania MIDI między aplikacjami (wirtualne urządzenia MIDI).

• [C-1-3] MUSI zawierać bibliotekę libamidi.so (natywna obsługa MIDI)

• POWINNO obsługiwać tryb urządzenia peryferyjnego MIDI przez USB, sekcja 7.7

5.10. Profesjonalny dźwięk

Jeśli implementacje urządzeń zgłaszają obsługę funkcjiandroid.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager, to:

• [C-1-1] MUSI zgłaszać obsługę funkcji android.hardware.audio.low_latency.

• [C-1-2] MUSI spełniać wymagania dotyczące opóźnienia w przypadku FEATURE_AUDIO_PRO określone w sekcji 5.6 Opóźnienie dźwięku .

• [C-1-3] MUSI zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.

• [C-1-4] MUSI zgłaszać obsługę funkcji android.software.midi.

• [C-1-5] MUSI spełniać wymagania dotyczące opóźnienia dźwięku USB przy użyciu interfejsu AAudio native audio i AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

• [C-1-6] MUSI mieć opóźnienie wyjścia w trybie zimnym wynoszące 200 milisekund lub mniej.

• [C-1-7] MUSI mieć opóźnienie wejścia w trybie zimnym wynoszące 200 milisekund lub mniej.

Jeśli urządzenia mają 4-żyłowe gniazdo słuchawek 3,5 mm, to:

• [C-2-2] MUSI być zgodny z sekcją Specyfikacje urządzeń mobilnych (gniazdo słuchawek) dokumentu Specyfikacja przewodowego zestawu słuchawkowego audio (v1.1).

Jeśli implementacje urządzeń nie zawierają 4-żyłowego gniazda słuchawek 3, 5 mm i mają porty USB obsługujące tryb hosta USB:

• [C-3-1] MUSI implementować klasę dźwięku USB.

5.11. Capture for Unprocessed

Android obsługuje nagrywanie nieprzetworzonego dźwięku za pomocą źródła dźwięku android.media.MediaRecorder.AudioSource.UNPROCESSED. W OpenSL ES można uzyskać do niego dostęp za pomocą ustawienia wstępnego nagrywania SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Jeśli implementacje urządzeń mają obsługiwać nieprzetworzone źródło dźwięku i udostępniać je aplikacjom innych firm:

• [C-1-1] MUSI zgłaszać obsługę za pomocą właściwości android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] MUSI wykazywać w zakresie średnich częstotliwości w przybliżeniu płaską charakterystykę amplitudy w funkcji częstotliwości: w szczególności ±10 dB w zakresie od 100 Hz do 7000 Hz w przypadku każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.

• [C-1-3] MUSI wykazywać poziomy amplitudy w zakresie niskich częstotliwości: w szczególności od ±20 dB w zakresie od 5 Hz do 100 Hz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.

• [C-1-4] MUSI wykazywać poziomy amplitudy w zakresie wysokich częstotliwości: w szczególności ±30 dB w zakresie od 7000 Hz do 22 kHz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.

• [C-1-5] MUSI ustawić czułość wejścia audio tak, aby źródło dźwięku w postaci fali sinusoidalnej o częstotliwości 1000 Hz odtwarzane na poziomie ciśnienia akustycznego 94 dB dawało odpowiedź o wartości RMS 520 dla 16-bitowych próbek (lub -36 dB w pełnej skali dla próbek zmiennoprzecinkowych/podwójnej precyzji) dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-6] MUSI mieć stosunek sygnału do szumu (SNR) na poziomie co najmniej 60 dB w przypadku każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku. (natomiast SNR jest mierzony jako różnica między 94 dB SPL a równoważnym SPL szumu własnego, ważonym A).

• [C-1-7] MUSI mieć całkowite zniekształcenia harmoniczne (THD) mniejsze niż 1% przy poziomie wejściowym 90 dB SPL przy 1 kHz w przypadku każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-8] NIE MOŻE mieć na ścieżce żadnego innego przetwarzania sygnału (np. automatycznej regulacji wzmocnienia, filtra górnoprzepustowego lub usuwania echa) poza mnożnikiem poziomu, który doprowadza poziom do żądanego zakresu. Krótko mówiąc:

  • [C-1-9] Jeśli w architekturze występuje przetwarzanie sygnału z jakiegokolwiek powodu, MUSI ono być wyłączone i nie może powodować opóźnienia ani dodatkowej latencji na ścieżce sygnału.
  • [C-1-10] Mnożnik poziomu może znajdować się na ścieżce, ale NIE MOŻE wprowadzać opóźnienia ani latencji na ścieżce sygnału.

Wszystkie pomiary SPL są wykonywane bezpośrednio obok testowanego mikrofonu. W przypadku konfiguracji z wieloma mikrofonami te wymagania dotyczą każdego z nich.

Jeśli implementacje urządzeń deklarują android.hardware.microphone, ale nie obsługują nieprzetworzonego źródła dźwięku:

• [C-2-1] MUSI zwracać wartość null w przypadku metody interfejsu API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), aby prawidłowo wskazywać brak obsługi.

• [C-SR-1] są nadal ZDECYDOWANIE ZALECANE, aby spełnić jak najwięcej wymagań dotyczących ścieżki sygnału dla nieprzetworzonego źródła nagrania.

5.12. Obsługa HDR

Android 13 obsługuje technologie HDR opisane w nadchodzącym dokumencie.

Format piksela

Jeśli dekoder wideo zgłasza obsługę COLOR_FormatYUVP010, to:

• [C-1-1] MUSI obsługiwać format P010 do odczytu przez procesor (ImageReader, MediaImage, ByteBuffer). W Androidzie 13 format P010 został zmodyfikowany, aby umożliwić dowolny krok dla płaszczyzn Y i UV.

• [C-1-2] Bufor wyjściowy P010 MUSI być próbkowany przez GPU (gdy jest przydzielony z użyciem GPU_SAMPLING). Umożliwia to aplikacjom kompozycję GPU i niestandardowe mapowanie odcieni.

Jeśli dekoder wideo deklaruje obsługę COLOR_Format32bitABGR2101010:

• [C-2-1] MUSI obsługiwać format RGBA_1010102 dla powierzchni wyjściowej i danych wyjściowych odczytywanych przez procesor (ByteBuffer).

Jeśli koder wideo deklaruje obsługę COLOR_FormatYUVP010:

• [C-3-1] MUSI obsługiwać format P010 w przypadku powierzchni wejściowej i wejścia z możliwością zapisu na procesorze (ImageWriter, MediaImage, ByteBuffer).

Jeśli koder wideo deklaruje obsługę COLOR_Format32bitABGR2101010:

• [C-4-1] MUSI obsługiwać format RGBA_1010102 w przypadku powierzchni wejściowej i wejścia zapisu na procesorze (ImageWriter, ByteBuffer). Uwaga: konwersja między różnymi krzywymi przenoszenia NIE jest wymagana w przypadku enkoderów.

Wymagania dotyczące nagrywania w HDR

W przypadku wszystkich koderów wideo obsługujących profile HDR implementacje urządzeń:

• [C-5-1] NIE WOLNO zakładać, że metadane HDR są precyzyjne. Na przykład zakodowana klatka może mieć piksele o jasności wykraczającej poza poziom jasności szczytowej lub histogram może nie być reprezentatywny dla klatki.

• POWINNY agregować dynamiczne metadane HDR, aby generować odpowiednie statyczne metadane HDR dla zakodowanych strumieni, i powinny je przesyłać na końcu każdej sesji kodowania.

Jeśli implementacje urządzeń obsługują rejestrowanie HDR za pomocą interfejsów API CamcorderProfile:

• [C-6-1] MUSI obsługiwać przechwytywanie HDR za pomocą interfejsów API Camera2.

• [C-6-2] MUSI obsługiwać co najmniej 1 akcelerowany sprzętowo koder wideo dla każdej obsługiwanej technologii HDR.

• [C-6-3] MUSI obsługiwać (co najmniej) nagrywanie w formacie HLG.

• [C-6-4] MUSI obsługiwać zapisywanie metadanych HDR (jeśli ma to zastosowanie do technologii HDR) w nagranym pliku wideo. W przypadku AV1, HEVC i DolbyVision oznacza to włączenie metadanych do zakodowanego strumienia bitów.

• [C-6-5] MUSI obsługiwać P010 i COLOR_FormatYUVP010.

• [C-6-6] MUSI obsługiwać mapowanie tonów HDR na SDR w domyślnym dekoderze akcelerowanym sprzętowo dla przechwyconego profilu. Innymi słowy, jeśli urządzenie może rejestrować obraz w formacie HDR10+ HEVC, domyślny dekoder HEVC MUSI być w stanie dekodować zarejestrowany strumień w SDR.

Wymagania dotyczące edycji HDR

Jeśli implementacje urządzeń obejmują kodery wideo obsługujące edycję HDR:

• POWINIEN generować metadane HDR z minimalnym opóźnieniem, gdy nie są one obecne, i POWINIEN prawidłowo obsługiwać sytuacje, w których metadane są obecne w niektórych klatkach, a w innych nie. Te metadane POWINNY być precyzyjne (np. przedstawiać rzeczywistą jasność szczytową i histogram klatki).

Jeśli implementacja urządzenia obejmuje kodeki obsługujące FEATURE_HdrEditing, to:

• [C-7-1] MUSI obsługiwać co najmniej 1 profil HDR.

• [C-7-2] MUSI obsługiwać FEATURE_HdrEditing w przypadku wszystkich profili HDR reklamowanych przez ten kodek. Innymi słowy, MUSI obsługiwać generowanie metadanych HDR, gdy nie są one obecne w przypadku wszystkich obsługiwanych profili HDR, które używają metadanych HDR.

• [C-7-3] MUSI obsługiwać te formaty wejściowe kodera wideo, które w pełni zachowują zdekodowany sygnał HDR:

  • RGBA_1010102 (już na docelowej krzywej przenoszenia) zarówno w przypadku powierzchni wejściowej, jak i obiektu ByteBuffer, i MUSI informować o obsłudze COLOR_Format32bitABGR2101010.

Jeśli implementacja urządzenia obejmuje kodeki obsługujące FEATURE_HdrEditing, to:

• [C-7-4] MUSI reklamować obsługę EXT_YUV_targetrozszerzenia OpenGL.

Wymagania dotyczące wyświetlacza HDR

Jeśli implementacje urządzeń otrzymują zawartość bufora zakodowaną za pomocą ADATASPACE_TRANSFER_HLG, a ta zawartość jest wysyłana na wyświetlacz za pomocą SurfaceControl.Transaction#setBuffer, to:

• [C-8-1] MUSI być zgodny z zaleceniami dotyczącymi bieli graficznej w BT.2408-7 i wyświetlać treści, które są co najwyżej 4,926 razy jaśniejsze niż treści SDR.

6. Zgodność narzędzi i opcji dla programistów

6.1. Narzędzia dla programistów

Implementacje urządzeń:

• [C-0-1] MUSI obsługiwać narzędzia dla programistów na Androida udostępniane w pakiecie Android SDK.

• Android Debug Bridge (adb)

• [C-0-2] MUSI obsługiwać adb zgodnie z dokumentacją pakietu Android SDK i poleceniami powłoki udostępnianymi w AOSP, z których mogą korzystać deweloperzy aplikacji, w tym dumpsys, cmd stats i  Simpleperf.

• [C-0-11] MUSI obsługiwać polecenie powłoki cmd testharness. Uaktualnianie implementacji urządzeń ze starszej wersji Androida bez trwałego bloku danych MOŻE być zwolnione z wymogu C-0-11.

• [C-0-3] NIE WOLNO zmieniać formatu ani zawartości zdarzeń systemowych urządzenia (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) rejestrowanych za pomocą polecenia dumpsys.

• [C-0-10] MUSI rejestrować bez pominięć i udostępniać te zdarzenia poleceniu powłoki cmd stats oraz klasie interfejsu API systemu StatsManager.

  • ActivityForegroundStateChanged
  • AnomalyDetected
  • AppBreadcrumbReported
  • AppCrashOccurred
  • AppStartOccurred
  • BatteryLevelChanged
  • BatterySaverModeStateChanged
  • BleScanResultReceived
  • BleScanStateChanged
  • ChargingStateChanged
  • DeviceIdleModeStateChanged
  • ForegroundServiceStateChanged
  • GpsScanStateChanged
  • InputDeviceUsageReported
  • JobStateChanged
  • KeyboardConfigured
  • KeyboardSystemsEventReported
  • PluggedStateChanged
  • PressureStallInformation
  • ScheduledJobStateChanged
  • ScreenStateChanged
  • SyncStateChanged
  • SystemElapsedRealtime
  • TouchpadUsage
  • UidProcessStateChanged
  • WakelockStateChanged
  • WakeupAlarmOccurred
  • WifiLockStateChanged
  • WifiMulticastLockStateChanged
  • WifiScanStateChanged

• [C-0-4] MUSI mieć domyślnie nieaktywny demon adb po stronie urządzenia i MUSI mieć dostępny dla użytkownika mechanizm włączania Android Debug Bridge.

• [C-0-5] MUSI obsługiwać bezpieczne adb. Android obsługuje bezpieczne adb. Bezpieczne adb umożliwia korzystanie z adb na znanych, uwierzytelnionych hostach.

• [C-0-6] MUSI udostępniać mechanizm umożliwiający połączenie adb z komputera hosta. Więcej szczegółów:

Jeśli urządzenia bez portu USB obsługują tryb urządzenia peryferyjnego:

• [C-3-1] MUSI implementować adb przez sieć lokalną (np. Ethernet lub Wi-Fi).

• [C-3-2] MUSI udostępniać sterowniki dla systemów Windows 7, 8 i 10, które umożliwiają deweloperom łączenie się z urządzeniem za pomocą protokołu ADB.

Jeśli implementacje urządzeń obsługują połączenia adb z maszyną hosta przez Wi-Fi lub Ethernet, to:

• [C-4-1] MUSI zwracać true w przypadku metody AdbManager#isAdbWifiSupported().

Jeśli implementacje urządzeń obsługują połączenia adb z maszyną hosta przez Wi-Fi lub Ethernet i zawierają co najmniej 1 kamerę:

• [C-5-1] MUSI zwracać true w przypadku metody AdbManager#isAdbWifiQrSupported().

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] MUSI obsługiwać wszystkie funkcje ddms zgodnie z dokumentacją pakietu Android SDK. Ponieważ ddms korzysta z adb, obsługa ddms POWINNA być domyślnie nieaktywna, ale MUSI być obsługiwana, gdy użytkownik aktywuje Android Debug Bridge, jak opisano powyżej.

• SysTrace

  • [C-0-9] MUSI obsługiwać narzędzie systrace zgodnie z dokumentacją pakietu Android SDK. Śledzenie systemowe musi być domyślnie nieaktywne. Musi też istnieć dostępny dla użytkownika mechanizm włączania śledzenia systemowego.

• Perfetto

  • [C-SR-1] Zdecydowanie zaleca się udostępnianie użytkownikowi powłoki /system/bin/perfettopliku binarnego, którego wiersz poleceń jest zgodny zdokumentacją Perfetto.

  • [C-SR-2] Zdecydowanie zalecamy, aby plik binarny perfetto akceptował jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.

  • [C-SR-3] Zdecydowanie zalecamy, aby dane wyjściowe były zapisywane w formacie binarnym perfetto, który jest zgodny ze schematem zdefiniowanym w dokumentacji perfetto.

  • [C-SR-4] Zdecydowanie zaleca się, aby za pomocą pliku binarnego perfetto udostępniać co najmniej źródła danych opisane w dokumentacji perfetto.

• Low Memory Killer

  • [C-0-12] MUSI zapisywać LMK_KILL_OCCURRED_FIELD_NUMBER Atom w dzienniku statsd, gdy aplikacja zostanie zamknięta przez Low Memory Killer.

• Tryb jarzma testowego

  Jeśli implementacje urządzeń obsługują polecenie powłoki cmd testharness i uruchamiają cmd testharness enable, to:

  • [C-2-1] MUSI zwrócić true za ActivityManager.isRunningInUserTestHarness()

  • [C-2-2] MUSI implementować tryb jarzma testowego zgodnie z opisem w dokumentacji trybu jarzma testowego.

• Informacje o pracy GPU

  Implementacje urządzeń:

  • [C-0-13] MUSI implementować polecenie powłoki dumpsys gpu --gpuwork, aby wyświetlać zagregowane dane o pracy procesora graficznego zwrócone przez punkt śledzenia jądra power/gpu_work_period lub nie wyświetlać żadnych danych, jeśli punkt śledzenia nie jest obsługiwany. Implementacja AOSP to frameworks/native/services/gpuservice/gpuwork/.

Jeśli implementacje urządzeń zgłaszają obsługę interfejsu Vulkan 1.0 lub nowszego za pomocą flag funkcjiandroid.hardware.vulkan.version, to:

• [C-1-1] MUSI umożliwiać deweloperowi aplikacji włączanie i wyłączanie warstw debugowania GPU.

• [C-1-2] MUSI, gdy włączone są warstwy debugowania GPU, wyliczać warstwy w bibliotekach dostarczanych przez narzędzia zewnętrzne (tj. niebędące częścią platformy ani pakietu aplikacji) znajdujące się w katalogu podstawowym aplikacji z możliwością debugowania, aby obsługiwać metody interfejsu API vkEnumerateInstanceLayerProperties() i vkCreateInstance().

6.2. Opcje programisty

Android umożliwia deweloperom konfigurowanie ustawień związanych z tworzeniem aplikacji.

Implementacje urządzeń MUSZĄ zapewniać spójne działanie opcji programisty. W tym celu:

• [C-0-1] MUSI obsługiwać intencję android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z tworzeniem aplikacji. W implementacji Androida wyższego poziomu menu Opcje dewelopera jest domyślnie ukryte, a użytkownicy mogą je uruchomić, klikając 7 razy kolejno Ustawienia > Informacje o urządzeniu > Numer kompilacji.
• [C-0-2] MUSI domyślnie ukrywać Opcje programisty.
• [C-0-3] MUSI udostępniać jasny mechanizm, który nie faworyzuje jednej aplikacji innej firmy w stosunku do innej, aby umożliwić włączenie opcji programisty. MUSI zawierać publicznie dostępny dokument lub stronę internetową z opisem sposobu włączania opcji programisty. Ten dokument lub ta witryna MUSI być połączona z dokumentami pakietu Android SDK.
• POWINNA stale wyświetlać użytkownikowi powiadomienie wizualne, gdy włączone są opcje programisty i istnieje obawa o bezpieczeństwo użytkownika.
• MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty, ukrywając je lub wyłączając, aby zapobiec rozproszeniu uwagi w sytuacjach, w których bezpieczeństwo użytkownika jest zagrożone.

7. Zgodność sprzętu

Jeśli urządzenie zawiera określony komponent sprzętowy, który ma odpowiedni interfejs API dla deweloperów zewnętrznych:

• [C-0-1] Implementacja urządzenia MUSI implementować ten interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK.

Jeśli interfejs API w pakiecie SDK wchodzi w interakcję z komponentem sprzętowym, który jest opcjonalny, a implementacja urządzenia nie zawiera tego komponentu:

• [C-0-2] Muszą być nadal prezentowane pełne definicje klas (zgodnie z dokumentacją pakietu SDK) interfejsów API komponentu.
• [C-0-3] Działanie interfejsu API MUSI być zaimplementowane w rozsądny sposób jako operacja bez efektu.
• [C-0-4] Metody interfejsu API MUSZĄ zwracać wartości null, jeśli zezwala na to dokumentacja pakietu SDK.
• [C-0-5] Metody interfejsu API MUSZĄ zwracać implementacje klas, które nie wykonują żadnych działań, jeśli dokumentacja pakietu SDK nie zezwala na wartości null.
• [C-0-6] Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, które nie są udokumentowane w dokumentacji pakietu SDK.
• [C-0-7] Implementacje urządzeń MUSZĄ konsekwentnie zgłaszać dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager dla tego samego odcisku palca kompilacji.

Typowym przykładem scenariusza, w którym obowiązują te wymagania, jest interfejs Telephony API: nawet na urządzeniach innych niż telefony te interfejsy API muszą być zaimplementowane jako rozsądne operacje bezczynne.

7.1. Wyświetlacz i grafika

Android zawiera funkcje, które automatycznie dostosowują zasoby aplikacji i układy interfejsu do urządzenia, aby zapewnić prawidłowe działanie aplikacji innych firm na różnych wyświetlaczach i konfiguracjach sprzętowych. Wyświetlacz zgodny z Androidem to ekran, który implementuje wszystkie zachowania i interfejsy API opisane w przeglądzie zgodności ekranu na stronie Android Developers, w tej sekcji (7.1) i jej podsekcjach, a także wszelkie dodatkowe zachowania specyficzne dla danego typu urządzenia udokumentowane w sekcji 2 tego dokumentu CDD.

Implementacje urządzeń:

• [C-0-1] MUSI domyślnie renderować aplikacje innych firm tylko na wyświetlaczach zgodnych z Androidem.

Jednostki, do których odwołują się wymagania w tej sekcji, są zdefiniowane w ten sposób:

• fizyczna przekątna. Odległość w calach między dwoma przeciwległymi rogami oświetlonej części wyświetlacza.

• density. Liczba pikseli obejmujących liniowy odcinek poziomy lub pionowy o długości 1 cala, wyrażona w pikselach na cal (ppi lub dpi). Jeśli podane są wartości ppi i dpi, zarówno pozioma, jak i pionowa wartość dpi musi mieścić się w podanym zakresie.

• format obrazu. Stosunek pikseli dłuższego boku do pikseli krótszego boku ekranu. Na przykład wyświetlacz o wymiarach 480 x 854 pikseli ma współczynnik proporcji 854 / 480 = 1, 779, czyli w przybliżeniu „16:9”.

• piksel niezależny od gęstości (dp). Wirtualna jednostka piksela znormalizowana do gęstości ekranu 160. W przypadku określonej gęstości d i liczby pikseli p liczba pikseli niezależnych od gęstości dp jest obliczana według wzoru: dp = (160 / d) * p.

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar i kształt ekranu

Platforma interfejsu Androida obsługuje różne rozmiary układu ekranu logicznego i umożliwia aplikacjom sprawdzanie rozmiaru układu ekranu bieżącej konfiguracji za pomocą Configuration.screenLayout z SCREENLAYOUT_SIZE_MASK i Configuration.smallestScreenWidthDp.

Implementacje urządzeń:

• [C-0-1] MUSI zgłaszać prawidłowy rozmiar układu elementu Configuration.screenLayout zgodnie z dokumentacją pakietu Android SDK. W szczególności implementacje urządzeń MUSZĄ zgłaszać prawidłowe logiczne wymiary ekranu w pikselach niezależnych od gęstości (dp) w sposób opisany poniżej:

  • Urządzenia, w których parametr Configuration.uiMode ma wartość inną niż UI_MODE_TYPE_WATCH, a rozmiar small parametru Configuration.screenLayout musi wynosić co najmniej 426 dp x 320 dp.

  • Urządzenia zgłaszające rozmiar normal dla Configuration.screenLayout muszą mieć co najmniej 480 dp x 320 dp.

  • Urządzenia zgłaszające rozmiar large dla Configuration.screenLayout muszą mieć co najmniej 640 dp x 480 dp.

  • Urządzenia zgłaszające rozmiar xlarge dla Configuration.screenLayout muszą mieć co najmniej 960 dp x 720 dp.

• [C-0-2] MUSI prawidłowo uwzględniać deklarowane przez aplikacje obsługiwane rozmiary ekranu za pomocą atrybutu <supports-screens> w AndroidManifest.xml, zgodnie z dokumentacją Android SDK.

• MOŻE mieć wyświetlacze zgodne z Androidem i zaokrąglonymi rogami.

Jeśli implementacje urządzeń obsługują ekrany o konfiguracji rozmiaru UI_MODE_TYPE_NORMAL i używają fizycznych wyświetlaczy z zaokrąglonymi rogami do renderowania tych ekranów:

• [C-1-1] MUSI zapewnić, że w przypadku każdego takiego wyświetlania spełnione jest co najmniej jedno z tych wymagań:

  • Promień zaokrąglonych rogów jest mniejszy lub równy 38 dp.

  • Gdy w każdym rogu wyświetlacza logicznego zakotwiczony jest kwadrat o wymiarach 18 dp × 18 dp, na ekranie widoczny jest co najmniej 1 piksel każdego kwadratu.

• POWINNA zawierać możliwość przełączenia się użytkownika na tryb wyświetlania z prostokątnymi rogami.

Jeśli implementacje urządzeń obsługują tylko konfigurację klawiatury NO_KEYS i chcą zgłaszać obsługę konfiguracji trybu interfejsu UI_MODE_TYPE_NORMAL:

• [C-4-1] MUSI mieć rozmiar układu, z wyłączeniem wycięć na wyświetlaczu, wynoszący co najmniej 596 dp x 384 dp.

Szczegółowe informacje o prawidłowym wdrażaniu interfejsów API komponentu pomocniczego lub rozszerzenia znajdziesz w publicznej dokumentacji Window Manager Jetpack.

• [C-4-1] Wymaganie usunięte w Androidzie 15.

7.1.1.2. Format ekranu

Ta sekcja została usunięta w Androidzie 14.

7.1.1.3. Gęstość ekranu

Platforma interfejsu Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić programistom aplikacji kierowanie zasobów aplikacji.

Implementacje urządzeń:

• [C-0-1] MUSI zgłaszać jedną z gęstości platformy Android wymienionych w DisplayMetrics za pomocą DENSITY_DEVICE_STABLE interfejsu API. Ta wartość musi być statyczna dla każdego wyświetlacza fizycznego. Urządzenie MOŻE jednak zgłaszać inną wartośćDisplayMetrics.density w zależności od zmian konfiguracji wyświetlacza wprowadzonych przez użytkownika (np. rozmiaru wyświetlacza) po początkowym uruchomieniu.

• POWINNA określać standardową gęstość platformy Android, która jest numerycznie najbliższa fizycznej gęstości ekranu, lub wartość, która odpowiadałaby tym samym pomiarom kątowego pola widzenia urządzenia przenośnego.

Jeśli implementacje urządzeń umożliwiają zmianę rozmiaru interfejsu urządzenia:

• [C-1-1] NIE WOLNO skalować wyświetlacza do rozmiaru większego niż 1,5-krotnyDENSITY_DEVICE_STABLE ani zmniejszać efektywnego minimalnego wymiaru ekranu poniżej 320 dp (co odpowiada kwalifikatorowi zasobu sw320dp), w zależności od tego, co nastąpi wcześniej.

• [C-1-2] NIE MOŻE zmniejszać wyświetlacza poniżej 0,85 raza DENSITY_DEVICE_STABLE.

• Aby zapewnić dobrą użyteczność i spójne rozmiary czcionek, ZALECA się stosowanie tego skalowania opcji wyświetlania reklam natywnych (z zachowaniem podanych powyżej limitów):

  • Mały: 0,85x
  • Domyślnie: 1x (natywna skala wyświetlania)
  • Duży: 1,15x
  • Większy: 1,3x
  • Największy 1,45x

7.1.2. Wyświetlanie danych

Jeśli implementacje urządzeń obejmują wyświetlacze zgodne z Androidem lub wyjście wideo na ekrany wyświetlaczy zgodnych z Androidem:

• [C-1-1] MUSI raportować prawidłowe wartości wszystkich wskaźników wyświetlania zgodnych z Androidem zdefiniowanych w interfejsie API android.util.DisplayMetrics.

Jeśli urządzenie nie ma wbudowanego ekranu ani wyjścia wideo:

• [C-2-1] MUSI zgłaszać prawidłowe wartości wyświetlacza zgodnego z Androidem zgodnie z definicją w android.util.DisplayMetrics interfejsie API dla emulowanego domyślnego view.Display.

7.1.3. Orientacja ekranu

Implementacje urządzeń:

• [C-0-1] MUSI zgłaszać obsługiwane orientacje ekranu (android.hardware.screen.portrait lub android.hardware.screen.landscape) i MUSI zgłaszać co najmniej 1 obsługiwaną orientację. Na przykład urządzenie z ekranem o stałej orientacji poziomej, takie jak telewizor lub laptop, POWINNO zgłaszać tylko wartość android.hardware.screen.landscape.

• [C-0-2] MUSI podawać prawidłową wartość bieżącej orientacji urządzenia, gdy jest o to pytany za pomocą interfejsów API android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innych.

Jeśli urządzenia obsługują obie orientacje ekranu:

• [C-1-1] Wymaganie usunięte w Androidzie 16.

• [C-1-2] NIE MOŻE zmieniać zgłoszonego rozmiaru ani gęstości ekranu podczas zmiany orientacji.

• MOŻE wybrać orientację pionową lub poziomą jako domyślną.

7.1.4. Akceleracja grafiki 2D i 3D

7.1.4.1. OpenGL ES

Implementacje urządzeń:

• [C-0-1] MUSI prawidłowo identyfikować obsługiwane wersje OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) za pomocą zarządzanych interfejsów API (np. za pomocą metody GLES10.getString()) i natywnych interfejsów API.

• [C-0-2] MUSI obejmować obsługę wszystkich odpowiednich zarządzanych interfejsów API i natywnych interfejsów API dla każdej wersji OpenGL ES, którą zidentyfikowano jako obsługiwaną.

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

• [C-1-1] MUSI obsługiwać OpenGL ES 1.1, 2.0, 3.0 i 3.1 zgodnie z opisem w dokumentacji pakietu Android SDK.

• [C-SR-1] Wymaganie usunięte w Androidzie 15.

• POWINNO obsługiwać OpenGL ES 3.2.

Testy dEQP OpenGL ES są podzielone na kilka list testów, z których każda ma powiązaną datę lub numer wersji. Znajdują się one w drzewie źródłowym Androida w lokalizacjiexternal/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Urządzenie, które obsługuje OpenGL ES na zadeklarowanym poziomie, może przejść testy dEQP ze wszystkich list testów z tego i wcześniejszych poziomów.

Jeśli implementacje urządzeń obsługują którąkolwiek z wersji OpenGL ES:

• [C-2-1] MUSI zgłaszać za pomocą interfejsów API OpenGL ES i natywnych interfejsów API wszystkie inne zaimplementowane rozszerzenia OpenGL ES, a z kolei NIE MOŻE zgłaszać ciągów rozszerzeń, których nie obsługuje.

• [C-2-2] MUSI obsługiwać rozszerzenia EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable i EGL_ANDROID_GLES_layers.

• [C-2-3] MUSI zgłaszać maksymalną wersję testów dEQP OpenGL ES obsługiwanych za pomocą flagi funkcji android.software.opengles.deqp.level.

• [C-2-4] MUSI obsługiwać co najmniej wersję 132383489 (z 1 marca 2020 r.) zgłoszoną w fladze funkcji android.software.opengles.deqp.level.

• [C-2-5] MUSI przejść wszystkie testy dEQP OpenGL ES z list testów między wersją 132383489 a wersją określoną w android.software.opengles.deqp.level fladze funkcji, dla każdej obsługiwanej wersji OpenGL ES.

• [C-SR-2] Zdecydowanie zaleca się obsługę rozszerzeń EGL_KHR_partial_update i OES_EGL_image_external.

• POWINNY dokładnie raportować za pomocą metody getString() wszelkie obsługiwane formaty kompresji tekstur, które są zwykle specyficzne dla danego dostawcy.

• POWINIEN obsługiwać rozszerzenia EGL_IMG_context_priority i EGL_EXT_protected_content.

Jeśli implementacje urządzeń deklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2:

• [C-3-1] MUSI eksportować odpowiednie symbole funkcji dla tych wersji oprócz symboli funkcji OpenGL ES 2.0 w libGLESv2.sobibliotece.

• [C-SR-3] ZDECYDOWANIE ZALECA się obsługę rozszerzenia OES_EGL_image_external_essl3.

Jeśli implementacje urządzeń obsługują OpenGL ES 3.2:

• [C-4-1] MUSI w pełni obsługiwać pakiet rozszerzeń OpenGL ES na Androida.

Jeśli implementacje urządzeń w całości obsługują pakiet rozszerzeń Androida OpenGL ES:

• [C-5-1] MUSI identyfikować obsługę za pomocą flagi funkcji android.hardware.opengles.aep.

Jeśli implementacje urządzeń udostępniają obsługę EGL_KHR_mutable_render_bufferrozszerzenia, to:

• [C-6-1] MUSI też obsługiwać rozszerzenie EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2. Vulkan

Android obsługuje Vulkana, interfejs API o niskim narzucie na wielu platformach do obsługi wydajnej grafiki 3D.

Jeśli implementacje urządzeń obsługują OpenGL ES 3.1:

• [C-SR-1] Zdecydowanie zaleca się obsługę interfejsu Vulkan 1.3.

• [C-4-1] NIE MOŻE obsługiwać wersji wariantu Vulkana (tzn. część wariantu wersji podstawowej Vulkana MUSI być zerowa).

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

• [C-SR-2] ZDECYDOWANIE ZALECA się obsługę interfejsu Vulkan 1.3.

Testy Vulkan dEQP są podzielone na kilka list testów, z których każda ma powiązaną datę lub wersję. Znajdują się one w drzewie źródłowym Androida w lokalizacjiexternal/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Urządzenie, które obsługuje Vulkan na zadeklarowanym poziomie, może przejść testy dEQP ze wszystkich list testów z tego i wcześniejszych poziomów.

Jeśli implementacje urządzeń obejmują obsługę interfejsu Vulkan:

• [C-1-1] MUSI zgłaszać prawidłową wartość całkowitą za pomocą flag funkcji android.hardware.vulkan.level i android.hardware.vulkan.version.

• [C-1-2] MUSI zawierać co najmniej 1 element VkPhysicalDevice w przypadku natywnego interfejsu API Vulkan vkEnumeratePhysicalDevices().

• [C-1-3] MUSI w pełni implementować interfejsy API Vulkan 1.1 dla każdego wymienionegoVkPhysicalDevice.

• [C-1-4] MUSI wyliczać warstwy zawarte w bibliotekach natywnych o nazwach libVkLayer*.so w katalogu bibliotek natywnych pakietu aplikacji za pomocą natywnych interfejsów API Vulkan vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties().

• [C-1-6] MUSI zgłaszać wszystkie obsługiwane ciągi rozszerzeń za pomocą natywnych interfejsów API Vulkan i odwrotnie: NIE MOŻE zgłaszać ciągów rozszerzeń , których nie obsługuje prawidłowo.

• [C-1-8] MUSI zgłaszać maksymalną wersję testów Vulkan dEQP obsługiwanych za pomocą flagi funkcji android.software.vulkan.deqp.level.

• [C-1-9] MUSI obsługiwać co najmniej wersję 132317953 (od 1 marca 2019 r.) zgodnie z informacjami w fladze funkcji android.software.vulkan.deqp.level.

• [C-1-10] MUSI przejść wszystkie testy Vulkan dEQP na listach testów między wersją 132317953 a wersją określoną w fladze funkcji android.software.vulkan.deqp.level.

• [C-1-11] NIE MOŻE wymieniać obsługi rozszerzeń VK_KHR_video_queue, VK_KHR_video_decode_queue ani VK_KHR_video_encode_queue.

• [C-1-12] NIE MOŻE wymieniać obsługi rozszerzenia VK_KHR_performance_query.

• [C-SR-4] SĄ ZDECYDOWANIE ZALECANE, aby spełniać wymagania określone w profilu Android Baseline 2022.

• [C-SR-5] ZDECYDOWANIE ZALECA się obsługę VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory i VK_EXT_global_priority.

• [C-SR-6] ZDECYDOWANIE ZALECA się używanie SkiaVk z HWUI.

Jeśli implementacje urządzeń obejmują obsługę interfejsu Vulkan:

• [C-SR-8] Zdecydowanie zaleca się, aby nie modyfikować modułu wczytującego Vulkan.

• [C-1-14] NIE MOŻE wymieniać rozszerzeń urządzenia Vulkan typu „KHR”, „GOOGLE” lub „ANDROID”, chyba że te rozszerzenia są uwzględnione w fladze funkcji android.software.vulkan.deqp.level.

Jeśli implementacje urządzeń nie obsługują interfejsu Vulkan 1.0:

• [C-2-1] NIE MOŻE deklarować żadnych flag funkcji interfejsu Vulkan (np. android.hardware.vulkan.level, android.hardware.vulkan.version).

• [C-2-2] NIE MOŻE wyliczać żadnych VkPhysicalDevice w przypadku natywnego interfejsu API VulkanvkEnumeratePhysicalDevices().

7.1.4.3. RenderScript

Implementacje urządzeń:

• [C-0-1] MUSI obsługiwać Android RenderScript zgodnie z dokumentacją pakietu Android SDK.

7.1.4.4. Akceleracja grafiki 2D

Android zawiera mechanizm, który umożliwia aplikacjom deklarowanie, że chcą włączyć akcelerację sprzętową grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku za pomocą tagu manifestu android:hardwareAccelerated lub bezpośrednich wywołań interfejsu API.

Implementacje urządzeń:

• [C-0-1] MUSI domyślnie włączać akcelerację sprzętową i MUSI wyłączać ją, jeśli deweloper o to poprosi, ustawiając android:hardwareAccelerated="false" lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów API widoku Androida.

• [C-0-2] MUSI działać zgodnie z dokumentacją pakietu Android SDK dotyczącą akceleracji sprzętowej.

Android zawiera obiekt TextureView, który umożliwia programistom bezpośrednie integrowanie tekstur OpenGL ES akcelerowanych sprzętowo jako miejsc docelowych renderowania w hierarchii interfejsu.

Implementacje urządzeń:

• [C-0-3] MUSI obsługiwać interfejs TextureView API i MUSI wykazywać spójne działanie z implementacją Androida wyższego poziomu.

7.1.4.5. Wyświetlacze o szerokiej gamie kolorów

Jeśli implementacje urządzeń deklarują obsługę wyświetlaczy o szerokiej gamie kolorów za pomocą Configuration.isScreenWideColorGamut():

• [C-1-1] MUSI mieć skalibrowany kolorystycznie wyświetlacz.

• [C-1-2] MUSI mieć wyświetlacz, którego gama kolorów w przestrzeni CIE 1931 xyY w całości obejmuje gamę kolorów sRGB.

• [C-1-3] MUSI mieć wyświetlacz, którego gamut obejmuje co najmniej 90% przestrzeni barw DCI-P3 w przestrzeni CIE 1931 xyY.

• [C-1-4] MUSI obsługiwać OpenGL ES 3.1 lub 3.2 i prawidłowo to zgłaszać.

• [C-1-5] MUSI reklamować obsługę rozszerzeń EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, i EGL_EXT_gl_colorspace_display_p3_passthrough.

• [C-SR-1] Zdecydowanie zalecamy obsługę GL_EXT_sRGB.

Z kolei jeśli urządzenia nie obsługują wyświetlaczy o szerokiej gamie kolorów:

• [C-2-1] POWINIEN pokrywać co najmniej 100% przestrzeni sRGB w przestrzeni CIE 1931 xyY, chociaż gamut kolorów ekranu jest niezdefiniowany.

7.1.5. Tryb zgodności ze starszymi aplikacjami

Android określa „tryb zgodności”, w którym platforma działa w trybie „normalnego” rozmiaru ekranu (320 dp szerokości) na potrzeby starszych aplikacji, które nie zostały opracowane dla starszych wersji Androida, w których nie było jeszcze niezależności od rozmiaru ekranu.

7.1.6. Technologia ekranu

Platforma Android zawiera interfejsy API, które umożliwiają aplikacjom renderowanie bogatej grafiki na wyświetlaczu zgodnym z Androidem. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zdefiniowane w pakiecie Android SDK, chyba że w tym dokumencie wyraźnie zezwala się na odstępstwo od tego wymagania.

Wszystkie ekrany zgodne z Androidem w implementacji urządzenia:

• [C-0-1] MUSI obsługiwać renderowanie grafiki w 16-bitowej palecie kolorów.

• POWINNY obsługiwać wyświetlacze obsługujące 24-bitową grafikę kolorową.

• [C-0-2] MUSI obsługiwać renderowanie animacji.

• [C-0-3] MUSI mieć współczynnik proporcji piksela (PAR) w zakresie od 0,9 do 1,15. Oznacza to, że współczynnik proporcji piksela MUSI być zbliżony do kwadratu (1,0) z tolerancją 10–15%.

7.1.7. Wyświetlacze dodatkowe

Android obsługuje dodatkowe wyświetlacze zgodne z Androidem, co umożliwia udostępnianie multimediów i korzystanie z interfejsów API dla programistów w celu uzyskiwania dostępu do wyświetlaczy zewnętrznych.

Jeśli urządzenia obsługują wyświetlacz zewnętrzny przez połączenie przewodowe, bezprzewodowe lub wbudowane dodatkowe połączenie wyświetlacza:

• [C-1-1] MUSI implementować usługę systemową i interfejs API DisplayManager zgodnie z opisem w dokumentacji pakietu Android SDK.

7.2. Urządzenia wejściowe

Implementacje urządzeń:

• [C-0-1] MUSI zawierać mechanizm wprowadzania danych, taki jak ekran dotykowy lub nawigacja bezdotykowa, umożliwiający poruszanie się między elementami interfejsu.

7.2.1. Klawiatura

Jeśli implementacje urządzeń obejmują obsługę aplikacji edytora metody wprowadzania (IME) innych firm:

• [C-1-1] MUSI zadeklarować flagę funkcji android.software.input_methods.
• [C-1-2] MUSI w pełni implementować Input Management Framework
• [C-1-3] MUSI mieć wstępnie zainstalowaną klawiaturę ekranową.

Implementacje urządzeń:

• [C-0-1] NIE MOŻE zawierać klawiatury sprzętowej, która nie jest zgodna z jednym z formatów określonych w android.content.res.Configuration.keyboard (QWERTY lub 12-klawiszowa).
• POWINNY zawierać dodatkowe implementacje klawiatury ekranowej.
• MOŻE zawierać klawiaturę sprzętową.

7.2.2. Nawigacja bezdotykowa

Android obsługuje pad kierunkowy, trackball i kółko jako mechanizmy nawigacji bezdotykowej.

Implementacje urządzeń:

• [C-0-1] MUSI zgłaszać prawidłową wartość parametru android.content.res.Configuration.navigation.

Jeśli implementacje urządzeń nie mają nawigacji bezdotykowej:

• [C-1-1] MUSI udostępniać rozsądny alternatywny mechanizm interfejsu użytkownika do wybierania i edytowania tekstu, zgodny z silnikami zarządzania wprowadzaniem. Implementacja open source Androida obejmuje mechanizm wyboru, który można stosować na urządzeniach bez wejść nawigacyjnych innych niż dotykowe.

7.2.3. Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz, które są zwykle dostępne po naciśnięciu specjalnego przycisku fizycznego lub określonej części ekranu dotykowego, są niezbędne w paradygmacie nawigacji w Androidzie, a tym samym w implementacjach urządzeń:

• [C-0-1] MUSI udostępniać użytkownikowi możliwość uruchamiania zainstalowanych aplikacji, które mają działanie z wartością <intent-filter> ustawioną na ACTION=MAIN i CATEGORY=LAUNCHER lub CATEGORY=LEANBACK_LAUNCHER w przypadku implementacji na urządzeniach telewizyjnych. Funkcja Home powinna być mechanizmem umożliwiającym użytkownikowi tę możliwość.
• POWINNY zawierać przyciski do funkcji Ostatnie i Wstecz.

Jeśli funkcje ekranu głównego, ostatnich aplikacji lub wstecz są dostępne, to:

• [C-1-1] MUSI być dostępny za pomocą jednego działania (np. kliknięcia, dwukrotnego kliknięcia lub gestu), gdy którykolwiek z nich jest dostępny.
• [C-1-2] MUSI wyraźnie wskazywać, które pojedyncze działanie wywoła każdą funkcję. Przykłady takich informacji to widoczna ikona na przycisku, ikona oprogramowania na pasku nawigacyjnym na ekranie lub przeprowadzenie użytkownika przez krok po kroku demonstracji podczas konfiguracji po wyjęciu z pudełka.

Implementacje urządzeń:

• [C-SR-1] Zdecydowanie zalecamy, aby nie udostępniać mechanizmu wprowadzania danych dla funkcji Menu, ponieważ od Androida 4.0 jest ona wycofana na rzecz paska działań.

• [C-SR-2] Zdecydowanie zaleca się, aby wszystkie funkcje nawigacyjne były anulowane. „Możliwość anulowania” oznacza, że użytkownik może zapobiec wykonaniu funkcji nawigacji (np. powrotu do domu, cofnięcia itp.), jeśli nie przesunie palcem poza określony próg.

Jeśli implementacje urządzeń udostępniają funkcję Menu:

• [C-2-1] MUSI wyświetlać przycisk menu działań dodatkowych, gdy wyskakujące menu działań dodatkowych nie jest puste i pasek działań jest widoczny.
• [C-2-2] NIE MOŻE modyfikować położenia wyskakującego okienka z dodatkowymi opcjami wyświetlanego po kliknięciu przycisku rozwijania menu na pasku działań, ale MOŻE renderować wyskakujące okienko z dodatkowymi opcjami w zmodyfikowanym położeniu na ekranie, gdy jest ono wyświetlane po kliknięciu funkcji Menu.

Jeśli implementacje urządzeń nie udostępniają funkcji Menu, w celu zapewnienia zgodności wstecznej:

• [C-3-1] MUSI udostępniać funkcję Menu aplikacjom, gdytargetSdkVersion jest mniejsza niż 10, za pomocą przycisku fizycznego, klawisza programowego lub gestów. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacyjnymi.

Jeśli implementacje urządzeń udostępniają funkcję pomocy:

• [C-4-1] MUSI udostępniać funkcję Asystenta za pomocą jednego działania (np. kliknięcia, dwukrotnego kliknięcia lub gestu), gdy dostępne są inne klawisze nawigacyjne.
• [C-SR-3] ZDECYDOWANIE ZALECANE jest używanie funkcji długiego naciśnięcia przycisku HOME, ponieważ jest to wyznaczona interakcja.

Jeśli implementacje urządzeń używają odrębnej części ekranu do wyświetlania klawiszy nawigacyjnych:

• [C-5-1] Klawisze nawigacyjne MUSZĄ zajmować odrębną część ekranu, niedostępną dla aplikacji, i NIE MOGĄ zasłaniać ani w inny sposób zakłócać działania części ekranu dostępnej dla aplikacji.
• [C-5-2] MUSI udostępniać część wyświetlacza aplikacjom, które spełniają wymagania określone w sekcji 7.1.1.
• [C-5-3] MUSI uwzględniać flagi ustawione przez aplikację za pomocą metody interfejsu API View.setSystemUiVisibility(), aby ta odrębna część ekranu (czyli pasek nawigacyjny) była prawidłowo ukryta zgodnie z dokumentacją pakietu SDK.

Jeśli funkcja nawigacji jest dostępna jako działanie na ekranie oparte na gestach:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() Musi być używany tylko do raportowania obszaru rozpoznawania gestu „Home”.
• [C-6-2] Gesty, które zaczynają się w obszarze wykluczenia podanym przez aplikację działającą na pierwszym planie za pomocą View#setSystemGestureExclusionRects(), ale poza WindowInsets#getMandatorySystemGestureInsets(), NIE MOGĄ być przechwytywane na potrzeby funkcji nawigacji, o ile obszar wykluczenia mieści się w maksymalnym limicie wykluczenia określonym w dokumentacji View#setSystemGestureExclusionRects().
• [C-6-3] MUSI wysłać do aplikacji na pierwszym planie zdarzenie MotionEvent.ACTION_CANCEL gdy tylko dotknięcia zaczną być przechwytywane na potrzeby gestu systemowego, jeśli wcześniej do aplikacji na pierwszym planie zostało wysłane zdarzenie MotionEvent.ACTION_DOWN.
• [C-6-4] MUSI udostępniać użytkownikowi możliwość przełączenia się na nawigację ekranową opartą na przyciskach (np. w Ustawieniach).
• POWINIEN zapewniać funkcję ekranu głównego w postaci przesunięcia palcem od dolnej krawędzi ekranu w górę w aktualnej orientacji ekranu.
• POWINIEN udostępniać funkcję Ostatnie jako przesunięcie w górę i przytrzymanie przed zwolnieniem w tym samym obszarze co gest Home.
• Gesty, które zaczynają się w obszarze WindowInsets#getMandatorySystemGestureInsets(), NIE POWINNY być objęte prostokątami wykluczenia podanymi przez aplikację na pierwszym planie za pomocą metody View#setSystemGestureExclusionRects().

Jeśli funkcja nawigacji jest dostępna w dowolnym miejscu na lewej i prawej krawędzi ekranu w bieżącej orientacji:

• [C-7-1] Funkcja nawigacji MUSI być funkcją Wstecz i MUSI być dostępna jako przesunięcie od lewej i prawej krawędzi ekranu w bieżącej orientacji.
• [C-7-2] Jeśli po lewej lub prawej stronie ekranu znajdują się niestandardowe panele systemowe, które można przesuwać, MUSZĄ one być umieszczone w górnej 1/3 ekranu i MUSZĄ mieć wyraźny, trwały wskaźnik wizualny, który informuje, że przeciągnięcie w ich kierunku spowoduje wyświetlenie wspomnianych paneli, a nie powrót. Panel systemowy MOŻE być skonfigurowany przez użytkownika tak, aby znajdował się poniżej górnej 1/3 krawędzi ekranu, ale NIE MOŻE zajmować więcej niż 1/3 krawędzi.
• [C-7-3] Gdy aplikacja na pierwszym planie ma ustawione flagi View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, przesuwanie od krawędzi MUSI działać tak, jak w AOSP, co jest opisane w pakiecie SDK.
• [C-7-4] Gdy aplikacja na pierwszym planie ma ustawione flagi View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, niestandardowe panele systemowe, które można przesuwać, MUSZĄ być ukryte, dopóki użytkownik nie wyświetli lub nie rozjaśni pasków systemowych (czyli paska nawigacyjnego i paska stanu) w sposób zaimplementowany w AOSP.

Jeśli funkcja przechodzenia wstecz jest dostępna, a użytkownik anuluje gest Wstecz:

• [C-8-1] Musi zostać wywołana funkcja OnBackInvokedCallback.onBackCancelled().
• [C-8-2] Nie WOLNO wywoływać funkcji OnBackInvokedCallback.onBackInvoked().
• [C-8-3] Zdarzenie KEYCODE_BACK NIE MOŻE być wysyłane.

Jeśli funkcja przechodzenia wstecz jest dostępna, ale aplikacja działająca na pierwszym planie NIE ma zarejestrowanego OnBackInvokedCallback, to:

• System POWINIEN wyświetlać animację aplikacji na pierwszym planie, która sugeruje, że użytkownik wraca do poprzedniego ekranu, tak jak w AOSP.

Jeśli implementacje urządzeń obsługują interfejs API systemu setNavBarMode, aby umożliwić każdej aplikacji systemowej z uprawnieniem android.permission.STATUS_BAR ustawienie trybu paska nawigacyjnego, to:

• [C-9-1] MUSI obsługiwać ikony przyjazne dla dzieci lub nawigację opartą na przyciskach, zgodnie z kodem AOSP.

7.2.4. Wprowadzanie danych za pomocą ekranu dotykowego

Android obsługuje różne systemy wprowadzania danych za pomocą wskaźnika, takie jak ekrany dotykowe, panele dotykowe i urządzenia do wprowadzania danych za pomocą symulacji dotyku. Urządzenia z ekranem dotykowym są powiązane z wyświetlaczem w taki sposób, że użytkownik ma wrażenie, że bezpośrednio manipuluje elementami na ekranie. Ponieważ użytkownik bezpośrednio dotyka ekranu, system nie wymaga żadnych dodatkowych elementów wskazujących obiekty, którymi manipuluje.

Implementacje urządzeń:

• POWINNO mieć jakiś system wprowadzania danych za pomocą wskaźnika (myszy lub dotyku).
• POWINNY obsługiwać wskaźniki śledzone w pełni niezależnie.

Jeśli implementacje urządzeń zawierają ekran dotykowy (obsługujący co najmniej 1 punkt dotyku) na głównym wyświetlaczu zgodnym z Androidem:

• [C-1-1] MUSI raportować wartość TOUCHSCREEN_FINGER w polu interfejsu API Configuration.touchscreen.
• [C-1-2] MUSI zgłaszać flagi funkcji android.hardware.touchscreen i android.hardware.faketouch.

Jeśli implementacje urządzeń obejmują ekran dotykowy, który może śledzić więcej niż 1 dotknięcie na głównym wyświetlaczu zgodnym z Androidem:

• [C-2-1] MUSI zgłaszać odpowiednie flagi funkcji android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand odpowiadające typowi konkretnego ekranu dotykowego na urządzeniu.

Jeśli implementacje urządzeń opierają się na zewnętrznym urządzeniu wejściowym, takim jak mysz lub trackball (tzn. nie dotykają bezpośrednio ekranu), w przypadku wprowadzania danych na głównym wyświetlaczu zgodnym z Androidem i spełniają wymagania dotyczące fałszywego dotyku określone w sekcji 7.2.5, to:

• [C-3-1] NIE MOŻE zgłaszać żadnej flagi funkcji zaczynającej się od android.hardware.touchscreen.
• [C-3-2] MUSI raportować tylko android.hardware.faketouch.
• [C-3-3] MUSI zgłaszać wartość TOUCHSCREEN_NOTOUCH w przypadku pola interfejsu API Configuration.touchscreen.

7.2.5. Symulowane dotykowe wprowadzanie danych

Symulowany interfejs dotykowy to system danych wejściowych użytkownika, który przybliża podzbiór funkcji ekranu dotykowego. Na przykład mysz lub pilot, które sterują kursorem na ekranie, są podobne do dotyku, ale wymagają od użytkownika najpierw wskazania lub ustawienia ostrości, a potem kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, żyroskopowa mysz powietrzna, żyroskopowy wskaźnik, joystick i trackpad wielodotykowy, może obsługiwać interakcje z fałszywym dotykiem. Android zawiera funkcję constant android.hardware.faketouch, która odpowiada urządzeniu wejściowemu o wysokiej wierności, które nie jest dotykowe (oparte na wskaźniku), np. myszy lub trackpadzie, które może odpowiednio emulować dane wejściowe oparte na dotyku (w tym podstawową obsługę gestów), i wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.

Jeśli implementacje urządzeń nie obejmują ekranu dotykowego, ale obejmują inny system wprowadzania za pomocą wskaźnika, który ma być dostępny, należy:

• POWINIEN deklarować obsługę flagi funkcji android.hardware.faketouch.

Jeśli implementacje urządzeń deklarują obsługę android.hardware.faketouch, to:

• [C-1-1] MUSI zgłaszać bezwzględne pozycje X i Y na ekranie wskazywanego miejsca i wyświetlać na ekranie wskaźnik.
• [C-1-2] MUSI zgłaszać zdarzenie dotyku z kodem działania, który określa zmianę stanu wskaźnika, gdy przesuwa się w dół lub w górę ekranu.
• [C-1-3] MUSI obsługiwać naciśnięcie i zwolnienie wskaźnika na obiekcie na ekranie, co umożliwia użytkownikom emulowanie kliknięcia obiektu na ekranie.
• [C-1-4] MUSI obsługiwać wskaźnik w dół, wskaźnik w górę, wskaźnik w dół, a następnie wskaźnik w górę w tym samym miejscu na obiekcie na ekranie w określonym czasie, co umożliwia użytkownikom emulowanie dwukrotnego kliknięcia obiektu na ekranie.
• [C-1-5] MUSI obsługiwać naciśnięcie wskaźnika w dowolnym punkcie ekranu, przesunięcie wskaźnika do dowolnego innego punktu ekranu, a następnie zwolnienie wskaźnika, co umożliwia użytkownikom emulowanie przeciągania dotykowego.
• [C-1-6] MUSI obsługiwać naciśnięcie wskaźnika, a następnie umożliwiać użytkownikom szybkie przeniesienie obiektu w inne miejsce na ekranie i zwolnienie wskaźnika na ekranie, co pozwala użytkownikom rzucać obiektem na ekranie.

Jeśli implementacje urządzeń deklarują obsługę android.hardware.faketouch.multitouch.distinct, to:

• [C-2-1] MUSI deklarować obsługę android.hardware.faketouch.
• [C-2-2] MUSI obsługiwać odrębne śledzenie co najmniej 2 niezależnych danych wejściowych wskaźnika.

Jeśli implementacje urządzeń deklarują obsługę android.hardware.faketouch.multitouch.jazzhand, to:

• [C-3-1] MUSI deklarować obsługę android.hardware.faketouch.
• [C-3-2] MUSI obsługiwać odrębne śledzenie co najmniej 5 wskaźników (śledzenie dłoni z palcami) w pełni niezależnie.

7.2.6. Obsługa kontrolera do gier

7.2.6.1. Mapowania przycisków

Implementacje urządzeń:

• [C-1-1] MUSI być w stanie mapować zdarzenia HID na odpowiednie stałe InputEvent wymienione w tabelach poniżej. Implementacja Androida upstream spełnia to wymaganie.

Jeśli urządzenia mają wbudowany kontroler lub są dostarczane z oddzielnym kontrolerem, który umożliwia wprowadzanie wszystkich zdarzeń wymienionych w tabelach poniżej:

• [C-2-1] MUSI zadeklarować flagę funkcji android.hardware.gamepad

Przycisk	HID Usage2	Przycisk Androida
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Pad kierunkowy – w górę1 Pad kierunkowy – w dół1	0x01 0x00393	AXIS_HAT_Y4
Przycisk w lewo na padzie kierunkowym1 Przycisk w prawo na padzie kierunkowym1	0x01 0x00393	AXIS_HAT_X4
Lewy przycisk na ramieniu1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Prawy przycisk na ramieniu1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Kliknięcie lewą gałką1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Kliknięcie prawą gałką1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Wstecz1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Powyższe zastosowania HID muszą być zadeklarowane w ramach urzędu certyfikacji Game pad (0x01 0x0005).

3 Wartość tego użycia musi mieć wartość Logical Minimum równą 0, Logical Maximum równą 7, Physical Minimum równą 0, Physical Maximum równą 315, Units w stopniach i Report Size równą 4. Wartość logiczna jest zdefiniowana jako obrót w kierunku zgodnym z ruchem wskazówek zegara od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i naciśnięcie przycisku w górę, a wartość logiczna 1 oznacza obrót o 45 stopni i naciśnięcie przycisków w górę i w lewo.

4 MotionEvent

Ustawienia analogowe1	Użycie HID	Przycisk Androida
Lewy spust	0x02 0x00C5	AXIS_LTRIGGER
Prawy spust	0x02 0x00C4	AXIS_RTRIGGER
Lewy joystick	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Prawy drążek	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Pilot

Wymagania dotyczące konkretnych urządzeń znajdziesz w sekcji 2.3.1.

7.3. Czujniki

Jeśli implementacje urządzeń zawierają określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, MUSZĄ one implementować ten interfejs API zgodnie z dokumentacją pakietu Android SDK i dokumentacją Android Open Source dotyczącą czujników.

Implementacje urządzeń:

• [C-0-1] MUSI dokładnie raportować obecność lub brak czujników zgodnie z klasą android.content.pm.PackageManager.

• [C-0-2] MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() i podobnych metod.

• [C-0-3] MUSI działać w rozsądny sposób w przypadku wszystkich innych interfejsów API czujników (np. zwracać wartość true lub false w odpowiednich przypadkach, gdy aplikacje próbują zarejestrować odbiorniki, nie wywoływać odbiorników czujników, gdy odpowiednie czujniki nie są obecne itp.).

Jeśli implementacje urządzeń zawierają określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych:

• [C-1-1] MUSI zgłaszać wszystkie pomiary czujników za pomocą odpowiednich wartości Międzynarodowego Układu Jednostek (metrycznych) dla każdego typu czujnika zgodnie z dokumentacją pakietu Android SDK.

• [C-1-2] MUSI raportować dane z czujnika z maksymalnym opóźnieniem 100 ms + 2 * sample_time w przypadku strumienia danych z czujnika z maksymalnym żądanym opóźnieniem 0 ms, gdy procesor aplikacji jest aktywny. To opóźnienie nie obejmuje opóźnień związanych z filtrowaniem.

• [C-1-3] MUSI raportować pierwszą próbkę z czujnika w ciągu 400 milisekund + 2 *  sample_time od aktywowania czujnika. Dopuszczalne jest, aby ta próbka miała dokładność 0.

• [C-1-4] W przypadku każdego interfejsu API, który zgodnie z dokumentacją pakietu Android SDK jest czujnikiem ciągłym, implementacje urządzeń MUSZĄ stale dostarczać okresowe próbki danych, które POWINNY mieć jitter poniżej 3%, gdzie jitter jest zdefiniowany jako odchylenie standardowe różnicy zgłaszanych wartości sygnatury czasowej między kolejnymi zdarzeniami.

• [C-1-5] MUSI zapewnić, że strumień zdarzeń z czujnika NIE MOŻE uniemożliwiać procesorowi urządzenia przejścia w stan zawieszenia ani wybudzenia z tego stanu.

• [C-1-6] MUSI zgłaszać czas zdarzenia w nanosekundach zgodnie z dokumentacją pakietu Android SDK, co oznacza czas wystąpienia zdarzenia zsynchronizowany z zegarem SystemClock.elapsedRealtimeNano().

• [C-SR-1] Zdecydowanie zaleca się, aby błąd synchronizacji sygnatury czasowej był mniejszy niż 100 milisekund, a powinien być mniejszy niż 1 milisekunda.

• Gdy kilka czujników jest aktywnych, zużycie energii NIE POWINNO przekraczać sumy zużycia energii poszczególnych czujników.

Powyższa lista nie jest wyczerpująca. Za wiarygodne należy uznać udokumentowane działanie pakietu Android SDK i dokumentację Android Open Source dotyczącą czujników.

Jeśli implementacje urządzeń zawierają określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych:

• [C-1-6] MUSI ustawić rozdzielczość różną od zera dla wszystkich czujników i raportować wartość za pomocą metody interfejsu API Sensor.getResolution().

Niektóre typy czujników są złożone, co oznacza, że można je uzyskać na podstawie danych dostarczanych przez co najmniej 1 inny czujnik. (Przykłady to czujnik orientacji i czujnik przyspieszenia liniowego).

Implementacje urządzeń:

• POWINNY implementować te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w sekcji Typy czujników.

Jeśli implementacje urządzeń obejmują czujnik złożony:

• [C-2-1] MUSI implementować czujnik zgodnie z opisem w dokumentacji Android Open Source na temat czujników złożonych.

Jeśli implementacje urządzeń zawierają określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, a czujnik raportuje tylko jedną wartość, implementacje urządzeń:

• [C-3-1] MUSI ustawić rozdzielczość czujnika na 1 i raportować wartość za pomocą metody interfejsu API Sensor.getResolution().

Jeśli implementacje urządzenia obejmują określony typ czujnika, który obsługuje SensorAdditionalInfo#TYPE_VEC3_CALIBRATION, a czujnik jest udostępniany deweloperom zewnętrznym:

• [C-4-1] W przekazywanych danych NIE WOLNO uwzględniać żadnych stałych, określonych fabrycznie parametrów kalibracji.

Jeśli implementacje urządzeń obejmują kombinację 3-osiowego akcelerometru, 3-osiowego żyroskopu lub magnetometru, są to:

• [C-SR-2] ZDECYDOWANIE ZALECANE, aby zapewnić stałe względne położenie akcelerometru, żyroskopu i magnetometru, tak aby w przypadku urządzenia transformowalnego (np. składanego) osie czujników pozostawały wyrównane i zgodne z układem współrzędnych czujnika we wszystkich możliwych stanach transformacji urządzenia.

7.3.1. Akcelerometr

Implementacje urządzeń:

• [C-SR-1] Zdecydowanie zaleca się, aby zawierały 3-osiowy akcelerometr.

Jeśli implementacje urządzeń zawierają akcelerometr:

• [C-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz.

• [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Androida, zgodnie z opisem w interfejsach API Androida.

• [C-1-4] MUSI być w stanie mierzyć od swobodnego spadania do czterokrotności gravity(4g) lub więcej na dowolnej osi.

• [C-1-5] MUSI mieć rozdzielczość co najmniej 12 bitów.

• [C-1-6] MUSI mieć odchylenie standardowe nie większe niż 0,05 m/s^, przy czym odchylenie standardowe należy obliczać dla każdej osi na podstawie próbek zebranych w okresie co najmniej 3 sekund przy największej częstotliwości próbkowania.

• POWINNY zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.

• POWINNA mieć rozdzielczość co najmniej 16 bitów.

• POWINIEN być kalibrowany podczas użytkowania, jeśli jego charakterystyka zmienia się w trakcie cyklu życia, a także kompensowany, a parametry kompensacji powinny być zachowywane między ponownymi uruchomieniami urządzenia.

• POWINNY mieć kompensację temperatury.

Jeśli implementacje urządzeń zawierają 3-osiowy akcelerometr:

• [C-2-1] MUSI implementować czujnik TYPE_ACCELEROMETER i raportować dane z niego.

• [C-SR-4] ZDECYDOWANIE ZALECA się implementowanie czujnika złożonego TYPE_SIGNIFICANT_MOTION.

• [C-SR-5] ZDECYDOWANIE ZALECA się implementowanie czujnika TYPE_ACCELEROMETER_UNCALIBRATED i raportowanie danych z niego. Zdecydowanie zalecamy, aby urządzenia z Androidem spełniały to wymaganie, ponieważ w przyszłości może ono stać się OBOWIĄZKOWE.

• POWINNY implementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR,TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER zgodnie z opisem w dokumencie pakietu Android SDK.

Jeśli implementacje urządzeń zawierają akcelerometr z mniej niż 3 osiami:

• [C-3-1] MUSI implementować czujnik TYPE_ACCELEROMETER_LIMITED_AXES i raportować dane z niego.

• [C-SR-6] ZDECYDOWANIE ZALECA się implementowanie czujnika TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED i raportowanie danych z niego.

Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr i dowolny z czujników złożonych TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER:

• [C-4-1] Suma ich zużycia energii MUSI być zawsze mniejsza niż 4 mW.

• POWINNY być poniżej 2 mW i 0,5 mW, gdy urządzenie jest w stanie dynamicznym lub statycznym.

Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr i 3-osiowy żyroskop:

• [C-5-1] MUSI implementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.

• [C-SR-7] ZDECYDOWANIE ZALECA się implementowanie czujnika złożonego TYPE_GAME_ROTATION_VECTOR.

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

• [C-6-1] MUSI implementować czujnik złożony TYPE_ROTATION_VECTOR.

7.3.2. Magnetometr

Implementacje urządzeń:

• [C-SR-1] ZDECYDOWANIE ZALECA się, aby zawierały 3-osiowy magnetometr (kompas).

Jeśli implementacje urządzeń zawierają 3-osiowy magnetometr:

• [C-1-1] MUSI implementować czujnik TYPE_MAGNETIC_FIELD.

• [C-1-2] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 10 Hz i POWINIEN raportować zdarzenia z częstotliwością co najmniej 50 Hz.

• [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Androida, zgodnie z opisem w interfejsach API Androida.

• [C-1-4] MUSI być w stanie mierzyć w zakresie od -900 µT do +900 µT na każdej osi, zanim osiągnie stan nasycenia.

• [C-1-5] MUSI mieć wartość przesunięcia twardego żelaza mniejszą niż 700 µT i POWINIEN mieć wartość poniżej 200 µT, co można osiągnąć, umieszczając magnetometr z dala od dynamicznych (indukowanych prądem) i statycznych (indukowanych magnesem) pól magnetycznych.

• [C-1-6] MUSI mieć rozdzielczość równą lub większą niż 0,6 µT.

• [C-1-7] MUSI obsługiwać kalibrację online i kompensację odchylenia spowodowanego przez twarde żelazo oraz zachowywać parametry kompensacji między ponownymi uruchomieniami urządzenia.

• [C-1-8] MUSI mieć zastosowaną kompensację miękkiego żelaza – kalibrację można przeprowadzić podczas użytkowania lub produkcji urządzenia.

• [C-1-9] MUSI mieć odchylenie standardowe obliczone dla każdej osi na podstawie próbek zebranych w okresie co najmniej 3 sekund przy największej częstotliwości próbkowania, nie większe niż 1,5 µT; POWINNO mieć odchylenie standardowe nie większe niż 0,5 µT.

• [C-1-10] MUSI implementować czujnik TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Jeśli implementacje urządzeń zawierają 3-osiowy magnetometr, akcelerometr i 3-osiowy żyroskop, to:

• [C-2-1] MUSI implementować czujnik złożony TYPE_ROTATION_VECTOR.

Jeśli implementacje urządzeń obejmują 3-osiowy magnetometr i akcelerometr:

• MOŻE implementować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Jeśli implementacje urządzeń zawierają 3-osiowy magnetometr, akcelerometr i czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR:

• [C-3-1] MUSI zużywać mniej niż 10 mW.

• POWINIEN zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie grupowania danych z częstotliwością 10 Hz.

7.3.3. GPS

Implementacje urządzeń:

• [C-SR-1] ZDECYDOWANIE ZALECA się, aby zawierały odbiornik GPS/GNSS.

Jeśli implementacje urządzeń zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, to:

• [C-1-1] MUSI obsługiwać dane wyjściowe lokalizacji z częstotliwością co najmniej 1 Hz, gdy są one wymagane przez LocationManager#requestLocationUpdate.

• [C-1-2] MUSI być w stanie określić lokalizację w warunkach otwartego nieba (silne sygnały, znikoma wielodrożność, HDOP < 2) w ciągu 10 sekund (szybki czas do pierwszego ustalenia pozycji), gdy jest połączony z internetem o szybkości transmisji danych co najmniej 0,5 Mb/s. Ten wymóg jest zwykle spełniany przez zastosowanie jakiejś formy wspomaganego lub przewidywanego GPS/GNSS, aby zminimalizować czas ustalania pozycji GPS/GNSS (dane wspomagające obejmują czas odniesienia, lokalizację odniesienia oraz efemerydy i zegary satelitarne).

  • [C-1-6] Po obliczeniu lokalizacji urządzenia MUSZĄ określić swoją lokalizację na otwartym niebie w ciągu 5 sekund od ponownego uruchomienia żądań lokalizacji, do godziny po początkowym obliczeniu lokalizacji, nawet jeśli kolejne żądanie zostanie wysłane bez połączenia transmisji danych lub po wyłączeniu i ponownym włączeniu zasilania.

• W otwartej przestrzeni po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 1 m/s²:

  • [C-1-3] MUSI być w stanie określić lokalizację z dokładnością do 20 metrów i prędkość z dokładnością do 0,5 metra na sekundę w co najmniej 95% przypadków.

  • [C-1-4] MUSI jednocześnie śledzić i zgłaszać za pomocą GnssStatus.Callback co najmniej 8 satelitów z jednej konstelacji.

  • POWINIEN być w stanie śledzić jednocześnie co najmniej 24 satelity z wielu konstelacji (np. GPS i co najmniej 1 z systemów GLONASS, BeiDou lub Galileo).

• [C-SR-2] ZDECYDOWANIE ZALECA się, aby podczas połączenia alarmowego nadal przekazywać normalne dane lokalizacji GPS/GNSS za pomocą interfejsów GNSS Location Provider API.

• [C-SR-3] Zdecydowanie ZALECA się zgłaszanie pomiarów GNSS ze wszystkich śledzonych konstelacji (zgłaszanych w wiadomościach GnssStatus), z wyjątkiem SBAS.

• [C-SR-4] Zdecydowanie zaleca się raportowanie AGC i częstotliwości pomiarów GNSS.

• [C-SR-5] Zdecydowanie ZALECA się zgłaszanie wszystkich szacunków dokładności (w tym kierunku, prędkości i położenia w pionie) w ramach każdej lokalizacji GPS/GNSS.

• [C-SR-6] ZDECYDOWANIE ZALECA się zgłaszanie pomiarów GNSS od razu po ich wykryciu, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.

• [C-SR-7] ZDECYDOWANIE ZALECA się zgłaszanie pseudoodległości i szybkości pseudoodległości GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 0,2 m/s², wystarczają do obliczenia pozycji z dokładnością do 20 metrów i prędkości z dokładnością do 0,2 m/s w co najmniej 95% przypadków.

7.3.4. Żyroskop

Implementacje urządzeń:

• [C-SR-1] ZDECYDOWANIE ZALECA się, aby zawierały czujnik żyroskopowy.

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

• [C-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz.

• [C-1-4] MUSI mieć rozdzielczość co najmniej 12 bitów.

• [C-1-5] MUSI mieć kompensację temperatury.

• [C-1-6] MUSI być kalibrowany i kompensowany podczas użytkowania oraz zachowywać parametry kompensacji między ponownymi uruchomieniami urządzenia.

• [C-1-7] MUSI mieć wariancję nie większą niż 1e-7 rad^2 / s^2 na Hz (wariancja na Hz lub rad^2 / s). Wariancja może się zmieniać wraz z częstotliwością próbkowania, ale MUSI być ograniczona przez tę wartość. Inaczej mówiąc, jeśli zmierzysz wariancję żyroskopu przy częstotliwości próbkowania 1 Hz, NIE POWINNA ona przekraczać 1e-7 rad^2/s^2.

• [C-SR-2] Błąd kalibracji ZDECYDOWANIE ZALECA się, aby był mniejszy niż 0,01 rad/s, gdy urządzenie jest nieruchome w temperaturze pokojowej.

• [C-SR-3] Zdecydowanie zaleca się, aby miały rozdzielczość co najmniej 16-bitową.

• POWINNY zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.

Jeśli implementacje urządzeń zawierają 3-osiowy żyroskop:

• [C-2-1] MUSI implementować czujnik TYPE_GYROSCOPE.

• [C-SR-4] Zdecydowanie zalecamy wdrożenie TYPE_GYROSCOPE_UNCALIBRATED czujnika.

Jeśli implementacje urządzeń zawierają żyroskop z mniej niż 3 osiami:

• [C-3-1] MUSI implementować czujnik TYPE_GYROSCOPE_LIMITED_AXES i raportować dane z niego.

• [C-SR-5] ZDECYDOWANIE ZALECA się implementowanie czujnika TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED i raportowanie danych z niego.

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

• [C-4-1] MUSI implementować czujnik złożony TYPE_ROTATION_VECTOR.

Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr i 3-osiowy żyroskop:

• [C-5-1] MUSI implementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.

• [C-SR-6] ZDECYDOWANIE ZALECA SIĘ implementowanie czujnika złożonego TYPE_GAME_ROTATION_VECTOR.

7.3.5. Barometr

Implementacje urządzeń:

• [C-SR-1] Zdecydowanie zaleca się, aby zawierały barometr (czujnik ciśnienia powietrza).

Jeśli implementacje urządzeń obejmują barometr:

• [C-1-1] MUSI implementować czujnik TYPE_PRESSURE i raportować dane z niego.

• [C-1-2] MUSI być w stanie dostarczać zdarzenia z częstotliwością co najmniej 5 Hz.

• [C-1-3] MUSI mieć kompensację temperatury.

• [C-SR-2] ZDECYDOWANIE ZALECANE jest, aby można było raportować pomiary ciśnienia w zakresie od 300 hPa do 1100 hPa.

• POWINNA mieć dokładność bezwzględną na poziomie 1 hPa.

• POWINIEN mieć dokładność względną 0,12 hPa w zakresie 20 hPa (co odpowiada dokładności ok. 1 m przy zmianie wysokości o ok. 200 m na poziomie morza).

Implementacje urządzeń, które deklarują właściwość systemu sensor.barometer.high_quality.implemented:

• [C-2-1] MUSI zgłaszać pomiary ciśnienia w zakresie od 300 hPa do 1100 hPa z dokładnością bezwzględną +/- 1 hPa.

• [C-2-2] MUSI mieć dokładność względną 0,15 hPa w zakresie 100 hPa, co odpowiada dokładności ~1 m przy zmianie ~1000 m na poziomie morza.

• [C-2-3] MUSI być stabilny w zakresie +/- 0,5 hPa, gdy użytkownik dotknie, naciśnie lub ściśnie urządzenie.

• [C-2-4] MUSI być stabilny w zakresie +/- 0,15 hPa, gdy użytkownik chodzi z urządzeniem w ręku lub w kieszeni.

• [C-2-5] NIE MOŻE być wygładzany ze stałą czasową większą niż 300 ms w przypadku aktywacji powyżej 5 Hz, a wygładzanie NIE MOŻE przenikać między aktywacjami czujników.

• [C-2-6] MUSI być stabilny w zakresie +/- 0,15 hPa w przypadku codziennego oświetlenia i częstotliwości radiowych pochodzących z powszechnych źródeł, takich jak Bluetooth, połączenie komórkowe lub Wi-Fi.

7.3.6. Termometr

Jeśli implementacje urządzeń zawierają termometr otoczenia (czujnik temperatury):

• [C-1-1] MUSI określaćSENSOR_TYPE_AMBIENT_TEMPERATURE w przypadku czujnika temperatury otoczenia, a czujnik MUSI mierzyć temperaturę otoczenia (pomieszczenia lub kabiny pojazdu) w miejscu, w którym użytkownik korzysta z urządzenia, w stopniach Celsjusza.

Jeśli implementacje urządzeń zawierają czujnik termometru, który mierzy temperaturę inną niż temperatura otoczenia, np. temperaturę procesora, muszą:

• [C-2-1] NIE MOŻE definiować SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury.

Jeśli implementacje urządzeń obejmują czujnik do monitorowania temperatury skóry:

• [C-SR-1] Zdecydowanie zaleca się obsługę interfejsu API PowerManager.getThermalHeadroom.

7.3.7. Fotometr

• Implementacje urządzeń MOGĄ zawierać fotometr (czujnik jasności otoczenia).

7.3.8. Czujnik zbliżeniowy

• Implementacje urządzeń MOGĄ zawierać czujnik zbliżeniowy.

Jeśli implementacje urządzeń obejmują czujnik zbliżeniowy i zgłaszają tylko odczyt binarny „blisko” lub „daleko”:

• [C-1-1] MUSI mierzyć odległość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI być zorientowany w taki sposób, aby wykrywać obiekty znajdujące się blisko ekranu, ponieważ jego głównym zadaniem jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacje urządzenia zawierają czujnik zbliżeniowy o dowolnej innej orientacji, NIE MOŻE on być dostępny za pomocą tego interfejsu API.

• [C-1-2] MUSI mieć dokładność co najmniej 1 bit.

• [C-1-3] MUSI używać 0 cm jako odczytu z bliska i 5 cm jako odczytu z daleka.

• [C-1-4] MUSI zgłaszać maksymalny zakres i rozdzielczość 5.

7.3.9. Czujniki o wysokiej wierności

Jeśli implementacje urządzeń obejmują zestaw czujników wyższej jakości zgodnie z definicją w tej sekcji i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI identyfikować funkcję za pomocą android.hardware.sensor.hifi_sensors flagi funkcji.

Jeśli implementacje urządzeń deklarują android.hardware.sensor.hifi_sensors, to:

• [C-2-1] MUSI mieć czujnik TYPE_ACCELEROMETER, który:

  • MUSI mieć zakres pomiarowy co najmniej od -8 g do +8 g, a ZDECYDOWANIE ZALECA SIĘ, aby zakres pomiarowy wynosił co najmniej od -16 g do +16 g.

  • MUSI mieć rozdzielczość pomiaru co najmniej 2048 LSB/g.

  • Musi mieć minimalną częstotliwość pomiaru wynoszącą 12,5 Hz lub mniej.

  • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz; POWINIEN obsługiwać SensorDirectChannel RATE_VERY_FAST.

  • MUSI mieć szum pomiarowy nie większy niż 400 μg/√Hz.

  • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z buforowaniem co najmniej 3000 zdarzeń.

  • MUSI mieć zużycie energii w trybie przetwarzania wsadowego nie większe niż 3 mW.

  • [C-SR-1] Zdecydowanie zaleca się, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a w tym paśmie znajdowało się widmo szumu białego.

  • POWINIEN mieć błąd losowy przyspieszenia mniejszy niż 30 μg √Hz testowany w temperaturze pokojowej.

  • POWINIEN mieć zmianę odchylenia w stosunku do temperatury ≤ +/- 1 mg/°C.

  • POWINIEN mieć nieliniowość linii dopasowania ≤ 0,5% i zmianę czułości w stosunku do temperatury ≤ 0,03%/°C.

  • POWINIEN mieć czułość w kierunku poprzecznym wynoszącą < 2,5 % i zmienność czułości w kierunku poprzecznym wynoszącą < 0,2% w zakresie temperatury pracy urządzenia.

• [C-2-2] MUSI mieć TYPE_ACCELEROMETER_UNCALIBRATED o takich samych wymaganiach jakościowych jak TYPE_ACCELEROMETER.

• [C-2-3] MUSI mieć czujnik TYPE_GYROSCOPE, który:

  • MUSI mieć zakres pomiarowy co najmniej od -1000 do +1000 dps.

  • MUSI mieć rozdzielczość pomiaru co najmniej 16 LSB/dps.

  • Musi mieć minimalną częstotliwość pomiaru wynoszącą 12,5 Hz lub mniej.

  • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz; POWINIEN obsługiwać SensorDirectChannel RATE_VERY_FAST.

  • MUSI mieć szum pomiarowy nie większy niż 0,014°/s/√Hz.

  • [C-SR-2] Zdecydowanie zaleca się, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a w tym paśmie znajdowało się widmo szumu białego.

  • POWINIEN mieć błąd losowy szybkości mniejszy niż 0,001°/s √Hz testowany w temperaturze pokojowej.

  • POWINIEN mieć zmianę odchylenia w stosunku do temperatury ≤ +/- 0,05°/ s / °C.

  • POWINIEN mieć zmianę czułości w stosunku do temperatury ≤ 0,02% / °C.

  • POWINNA mieć nieliniowość linii najlepszego dopasowania ≤ 0,2%.

  • POWINIEN mieć gęstość szumu ≤ 0,007°/s/√Hz.

  • W zakresie temperatur 10–40°C, gdy urządzenie jest nieruchome, błąd kalibracji powinien być mniejszy niż 0,002 rad/s.

  • POWINIEN mieć czułość na przyspieszenie grawitacyjne mniejszą niż 0,1°/s/g.

  • POWINIEN mieć czułość w kierunku poprzecznym < 4,0 % i zmienność czułości w kierunku poprzecznym < 0,3% w zakresie temperatur pracy urządzenia.

• [C-2-4] MUSI mieć TYPE_GYROSCOPE_UNCALIBRATED o takiej samej jakości jak TYPE_GYROSCOPE.

• [C-2-5] MUSI mieć czujnik TYPE_GEOMAGNETIC_FIELD, który:

  • MUSI mieć zakres pomiarowy co najmniej od -900 μT do +900 μT.

  • MUSI mieć rozdzielczość pomiaru co najmniej 5 LSB/uT.

  • MUSI mieć minimalną częstotliwość pomiaru wynoszącą 5 Hz lub mniej.

  • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 50 Hz.

  • MUSI mieć szum pomiarowy nieprzekraczający 0,5 uT.

• [C-2-6] MUSI mieć TYPE_MAGNETIC_FIELD_UNCALIBRATED o takiej samej jakości jak TYPE_GEOMAGNETIC_FIELD, a dodatkowo:

  • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z buforowaniem co najmniej 600 zdarzeń.

  • [C-SR-3] Zdecydowanie zaleca się, aby spektrum szumu białego wynosiło od 1 Hz do co najmniej 10 Hz, gdy częstotliwość raportowania wynosi 50 Hz lub więcej.

• [C-2-7] MUSI mieć czujnik TYPE_PRESSURE, który:

  • MUSI mieć zakres pomiarowy co najmniej od 300 hPa do 1100 hPa.

  • MUSI mieć rozdzielczość pomiaru co najmniej 80 LSB/hPa.

  • Musi mieć minimalną częstotliwość pomiaru wynoszącą 1 Hz lub mniej.

  • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 10 Hz.

  • MUSI mieć szum pomiarowy nie większy niż 2 Pa/√Hz.

  • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z buforowaniem co najmniej 300 zdarzeń.

  • Musi mieć zużycie energii w trybie wsadowym nie większe niż 2 mW.

• [C-2-8] MUSI mieć czujnik TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:

  • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest w spoczynku, i 1,5 mW, gdy urządzenie jest w ruchu.

• [C-2-10] MUSI mieć czujnik TYPE_STEP_DETECTOR, który:

  • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z buforowaniem co najmniej 100 zdarzeń czujnika.

  • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest w spoczynku, i 1,5 mW, gdy urządzenie jest w ruchu.

  • Musi mieć zużycie energii w trybie wsadowym nie większe niż 4 mW.

• [C-2-11] MUSI mieć czujnik TYPE_STEP_COUNTER, który:

  • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest w spoczynku, i 1,5 mW, gdy urządzenie jest w ruchu.

• [C-2-12] MUSI mieć czujnik TILT_DETECTOR, który:

  • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest w spoczynku, i 1,5 mW, gdy urządzenie jest w ruchu.

• [C-2-13] Sygnatury czasowe zdarzeń tego samego zdarzenia fizycznego zgłaszane przez akcelerometr, żyroskop i magnetometr MUSZĄ różnić się od siebie o nie więcej niż 2, 5 milisekundy. Sygnatury czasowe tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr i żyroskop powinny różnić się od siebie o nie więcej niż 0,25 milisekundy.

• [C-2-14] MUSI mieć sygnatury czasowe zdarzeń z żyroskopu na tej samej osi czasu co podsystem aparatu i z błędem nie większym niż 1 milisekunda.

• [C-2-15] MUSI dostarczać próbki do aplikacji w ciągu 5 milisekund od momentu, w którym dane są dostępne w dowolnym z wymienionych wyżej czujników fizycznych.

• [C-2-16] NIE MOŻE mieć poboru mocy większego niż 0,5 mW, gdy urządzenie jest nieruchome, i 2,0 mW, gdy urządzenie jest w ruchu, gdy włączona jest dowolna kombinacja tych czujników:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] MOŻE mieć czujnik TYPE_PROXIMITY, ale jeśli jest obecny, MUSI mieć minimalną pojemność bufora wynoszącą 100 zdarzeń z czujnika.

Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje ona moc pobieraną przez cały łańcuch czujników – czujnik, wszelkie obwody pomocnicze, dedykowany system przetwarzania danych z czujników itp.

Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników:

• [C-3-1] MUSI prawidłowo deklarować obsługę typów kanałów bezpośrednich i poziomów bezpośrednich stawek raportowania za pomocą interfejsów API isDirectChannelTypeSupported i getHighestDirectReportRateLevel.

• [C-3-2] MUSI obsługiwać co najmniej 1 z 2 typów bezpośrednich kanałów czujnika w przypadku wszystkich czujników, które deklarują obsługę bezpośredniego kanału czujnika.

  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE

• POWINIEN obsługiwać raportowanie zdarzeń za pomocą bezpośredniego kanału czujnika w przypadku głównego czujnika (wersja bez wybudzania) tych typów:

  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Czujniki biometryczne

Więcej informacji o pomiarze bezpieczeństwa odblokowywania biometrycznego znajdziesz w dokumentacji dotyczącej pomiaru bezpieczeństwa biometrycznego.

Jeśli implementacje urządzeń obejmują bezpieczny ekran blokady:

• POWINIEN zawierać czujnik biometryczny

Czujniki biometryczne mogą być klasyfikowane jako klasa 3 (wcześniej silne),

Klasa 2 (wcześniej Słaba) lub Klasa 1 (wcześniej Wygodna) w zależności od współczynnika akceptacji fałszywych tożsamości i podszywania się oraz bezpieczeństwa potoku biometrycznego. Ta klasyfikacja określa możliwości, jakie czujnik biometryczny ma w zakresie interakcji z platformą i aplikacjami innych firm. Aby czujniki mogły zostać zaklasyfikowane jako klasa 1, klasa 2 lub klasa 3, muszą spełniać dodatkowe wymagania opisane poniżej. Zarówno dane biometryczne klasy 2, jak i klasy 3 zyskują dodatkowe możliwości, o których piszemy poniżej.

Jeśli implementacje urządzeń udostępniają czujnik biometryczny aplikacjom innych firm za pomocą interfejsów android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt i android.provider.Settings.ACTION_BIOMETRIC_ENROLL:

• [C-4-1] MUSI spełniać wymagania dotyczące danych biometrycznych klasy 3 lub klasy 2 zgodnie z definicją w tym dokumencie.

• [C-4-2] MUSI rozpoznawać i honorować każdą nazwę parametru zdefiniowaną jako stała w klasie Authenticators oraz wszelkie jej kombinacje. Z kolei NIE WOLNO honorować ani rozpoznawać stałych liczb całkowitych przekazywanych do metod canAuthenticate(int) i setAllowedAuthenticators(int) innych niż te, które są udokumentowane jako stałe publiczne w Authenticators, ani żadnych ich kombinacji.

• [C-4-3] MUSI implementować działanie ACTION_BIOMETRIC_ENROLL na urządzeniach, które mają dane biometryczne klasy 3 lub klasy 2. Ta czynność MUSI wyświetlać tylko punkty wejścia rejestracji dla danych biometrycznych klasy 3 lub klasy 2.

• [C-4-4] MUSI umożliwiać aplikacjom dodawanie niestandardowych treści do BiometricPrompt za pomocą PromptContentView formatów wyświetlania treści. Formaty wyświetlania treści NIE MOGĄ być rozszerzane w sposób umożliwiający dodawanie obrazów, linków, treści interaktywnych ani innych form multimediów, które nie są jeszcze częścią interfejsu BiometricPromptAPI. Można wprowadzać korekty stylistyczne, które nie zmieniają, nie zasłaniają ani nie obcinają tych treści (np. zmieniać pozycję, dopełnienie, marginesy i typografię).

Jeśli implementacje urządzeń obsługują pasywną biometrię:

• [C-5-1] MUSI domyślnie wymagać dodatkowego potwierdzenia (np. naciśnięcia przycisku).

• [C-SR-1] Zdecydowanie zaleca się, aby aplikacja miała ustawienie umożliwiające użytkownikom zastąpienie preferencji aplikacji i zawsze wymagała dodatkowego potwierdzenia.

• [C-SR-2] Zdecydowanie zaleca się zabezpieczenie działania potwierdzającego w taki sposób, aby nie można było go sfałszować w wyniku naruszenia bezpieczeństwa systemu operacyjnego lub jądra. Oznacza to na przykład, że działanie potwierdzenia oparte na fizycznym przycisku jest kierowane przez ogólnego przeznaczenia pin wejścia/wyjścia (GPIO) tylko do wejścia elementu zabezpieczającego (SE), którego nie można uruchomić w żaden inny sposób niż przez naciśnięcie fizycznego przycisku.

• [C-5-2] MUSI dodatkowo implementować proces uwierzytelniania niejawnego (bez kroku potwierdzenia) odpowiadający funkcji setConfirmationRequired(boolean), z której aplikacje mogą korzystać w procesach logowania.

Jeśli implementacje urządzeń mają kilka czujników biometrycznych:

• [C-7-1] MUSI w przypadku zablokowania biometrii (tzn. wyłączenia biometrii do czasu odblokowania jej przez użytkownika za pomocą uwierzytelniania podstawowego) lub zablokowania czasowego (tzn. tymczasowego wyłączenia biometrii do czasu, aż użytkownik odczeka określony czas) z powodu zbyt wielu nieudanych prób zablokować również wszystkie inne biometrie niższej klasy. W przypadku blokady czasowej czas do ponowienia weryfikacji biometrycznej MUSI być maksymalnym czasem do ponowienia wszystkich danych biometrycznych w blokadzie czasowej.

• [C-SR-12] W przypadku zablokowania biometrii (tzn. wyłączenia biometrii do czasu odblokowania jej przez użytkownika za pomocą uwierzytelniania podstawowego) lub zablokowania czasowego (tzn. tymczasowego wyłączenia biometrii do czasu, aż użytkownik odczeka określony czas) z powodu zbyt wielu nieudanych prób ZDECYDOWANIE ZALECA SIĘ zablokowanie również wszystkich innych biometrii tej samej klasy. W przypadku blokady czasowej zaleca się, aby czas do ponowienia weryfikacji biometrycznej był maksymalnym czasem do ponowienia wszystkich danych biometrycznych w blokadzie czasowej.

• [C-7-2] MUSI poprosić użytkownika o podanie zalecanego podstawowego sposobu uwierzytelniania (np. kodu PIN, wzoru lub hasła), aby zresetować licznik blokady w przypadku zablokowania biometrii. Biometria klasy 3 MOŻE resetować licznik blokady zablokowanej biometrii tej samej lub niższej klasy. Biometria klasy 2 lub klasy 1 NIE MOŻE być używana do resetowania blokady w przypadku żadnej biometrii.

• [C-SR-3] Zdecydowanie zaleca się, aby podczas uwierzytelniania wymagane było potwierdzenie tylko jednego rodzaju danych biometrycznych (np. jeśli na urządzeniu dostępne są zarówno czytnik linii papilarnych, jak i czujnik rozpoznawania twarzy, funkcja onAuthenticationSucceeded powinna być wysyłana po potwierdzeniu dowolnego z nich).

Aby implementacje urządzeń zezwalały aplikacjom innych firm na dostęp do kluczy w magazynie kluczy:

• [C-6-1] MUSI spełniać wymagania dotyczące klasy 3 określone w sekcji poniżej.

• [C-6-2] MUSI przedstawiać tylko dane biometryczne klasy 3, gdy uwierzytelnianie wymaga BIOMETRIC_STRONG lub gdy uwierzytelnianie jest wywoływane za pomocą CryptoObject.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 1 (wcześniej wygodną), muszą:

• [C-1-1] MUSI mieć odsetek fałszywych akceptacji mniejszy niż 0,002%.

• [C-1-2] MUSI informować, że ten tryb może być mniej bezpieczny niż silny kod PIN, wzór lub hasło, i wyraźnie wymieniać zagrożenia związane z jego włączeniem, jeśli współczynniki akceptacji fałszywych danych i podszywania się są wyższe niż 7% zgodnie z protokołami testów biometrycznych na Androida.

• [C-1-9] MUSI poprosić użytkownika o podanie zalecanego podstawowego sposobu uwierzytelniania (np.kodu PIN, wzoru lub hasła) po nie więcej niż 20 nieudanych próbach i nie mniej niż 90-sekundowym czasie oczekiwania na weryfikację biometryczną. Nieudana próba to próba o odpowiedniej jakości przechwytywania (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.

• [C-SR-4] Zdecydowanie zaleca się obniżenie łącznej liczby fałszywych prób weryfikacji biometrycznej określonej w [C-1-9], jeśli wskaźniki akceptacji fałszywych i podszywających się osób są wyższe niż 7% zgodnie z protokołami testów biometrycznych na Androida.

• [C-1-3] MUSI ograniczać liczbę prób weryfikacji biometrycznej – gdzie nieudana próba to próba o odpowiedniej jakości rejestracji (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.

• [C-SR-5] Zdecydowanie zaleca się ograniczenie liczby prób weryfikacji biometrycznej do co najmniej 30 sekund po 5 nieudanych próbach, przy czym maksymalna liczba nieudanych prób na [C-1-9] – nieudana próba to próba o odpowiedniej jakości rejestracji (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.

• [C-SR-6] Zdecydowanie zaleca się, aby cała logika ograniczania liczby żądań znajdowała się w środowisku TEE.

• [C-1-10] MUSI wyłączyć biometrię po pierwszym wycofaniu uwierzytelniania podstawowego zgodnie z opisem w [C-0-2] w sekcji 9.11.

• [C-1-11] MUSI mieć współczynnik akceptacji fałszywych i podszywających się próbek nie wyższy niż 30%, przy czym (1) współczynnik akceptacji fałszywych i podszywających się próbek w przypadku instrumentów do ataków prezentacyjnych (PAI) poziomu A nie może być wyższy niż 30%, a (2) współczynnik akceptacji fałszywych i podszywających się próbek w przypadku instrumentów do ataków prezentacyjnych (PAI) poziomu B nie może być wyższy niż 40%, zgodnie z protokołami testów biometrycznych na Androidzie.

• [C-1-4] MUSI uniemożliwiać dodawanie nowych danych biometrycznych bez wcześniejszego utworzenia łańcucha zaufania przez potwierdzenie przez użytkownika istniejących lub dodanie nowych danych logowania na urządzeniu (PIN, wzór, hasło) zabezpieczonych przez TEE. Implementacja w projekcie Android Open Source zapewnia mechanizm w ramach, który to umożliwia.

• [C-1-5] MUSI całkowicie usuwać wszystkie dane biometryczne umożliwiające identyfikację użytkownika, gdy jego konto zostanie usunięte (w tym w wyniku przywrócenia ustawień fabrycznych) lub gdy zostanie usunięta zalecana podstawowa metoda uwierzytelniania (np. kod PIN, wzór lub hasło).

• [C-1-6] Musi uwzględniać poszczególne flagi dla danych biometrycznych (np. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE lub DevicePolicymanager.KEYGUARD_DISABLE_IRIS).

• [C-1-7] MUSI co 24 godziny lub rzadziej wymagać od użytkownika zalecanego podstawowego uwierzytelnienia (np. kodu PIN, wzoru lub hasła).

• [C-1-8] MUSI poprosić użytkownika o podanie zalecanego podstawowego sposobu uwierzytelniania (np. kodu PIN, wzoru lub hasła) lub biometrii klasy 3 (SILNEJ) po wystąpieniu dowolnego z tych zdarzeń:

  • 4-godzinny okres bezczynności.
  • 3 nieudane próby uwierzytelnienia biometrycznego.
  • Okres bezczynności i liczba nieudanych uwierzytelnień są resetowane po każdym pomyślnym potwierdzeniu danych logowania na urządzenie.

• [C-SR-7] ZDECYDOWANIE ZALECA się stosowanie logiki w ramach udostępnianych przez projekt Android Open Source do egzekwowania ograniczeń określonych w [C-1-7] i [C-1-8] w przypadku nowych urządzeń.

• [C-SR-8] Zdecydowanie zaleca się, aby wskaźnik fałszywych odrzuceń mierzony na urządzeniu był mniejszy niż 10%.

• [C-SR-9] Zdecydowanie zaleca się, aby czas oczekiwania był krótszy niż 1 sekunda, mierzony od momentu wykrycia danych biometrycznych do odblokowania ekranu, w przypadku każdego zarejestrowanego rodzaju danych biometrycznych.

• [C-1-12] MUSI mieć współczynnik akceptacji fałszywych i podszywających się próbek nie wyższy niż 40% w przypadku każdego rodzaju narzędzia do ataku przez prezentację, zgodnie z protokołami testów biometrycznych na Androidzie.

• [C-SR-13] Zdecydowanie zaleca się, aby wskaźnik akceptacji fałszywych i podrobionych tożsamości nie przekraczał 30% w przypadku każdego rodzaju instrumentu ataku prezentacyjnego (PAI), zgodnie z protokołami testów biometrycznych na Androida.

• [C-SR-8] Zdecydowanie zaleca się, aby wskaźnik fałszywych odrzuceń mierzony na urządzeniu był mniejszy niż 10%.

• [C-1-15] MUSI umożliwiać użytkownikom usuwanie pojedynczych lub wielu zarejestrowanych danych biometrycznych.

• [C-SR-14] Zdecydowanie zaleca się podanie klasy biometrycznej czujnika biometrycznego i odpowiednich zagrożeń związanych z jego włączeniem.

• [C-SR-17] ZDECYDOWANIE ZALECA się wdrożenie nowych interfejsów AIDL (takich jak IFace.aidl i IFingerprint.aidl).

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 2 (wcześniej słabą), muszą:

• [C-2-1] MUSI spełniać wszystkie wymagania dotyczące zajęć 1 wymienione powyżej.

• [C-2-2] MUSI mieć współczynnik akceptacji fałszywych tożsamości i podszywania się nie wyższy niż 20%, przy czym (1) współczynnik akceptacji fałszywych tożsamości i podszywania się w przypadku instrumentów do ataków prezentacyjnych (PAI) poziomu A nie może być wyższy niż 20%, a (2) współczynnik akceptacji fałszywych tożsamości i podszywania się w przypadku instrumentów PAI poziomu B nie może być wyższy niż 30%, zgodnie z protokołami testów biometrycznych na Androidzie.

• [C-SR-15] Zdecydowanie zaleca się, aby wskaźnik akceptacji fałszywych i podrobionych tożsamości nie przekraczał 20%w przypadku każdego rodzaju instrumentu ataku prezentacyjnego (PAI), zgodnie z protokołami testów biometrycznych na Androidzie.

• [C-2-3] MUSI przeprowadzać dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza przestrzenią użytkownika lub jądra Androida, takim jak zaufane środowisko wykonawcze (TEE), na układzie z bezpiecznym kanałem do odizolowanego środowiska wykonawczego lub na chronionej maszynie wirtualnej, która spełnia wymagania określone w sekcji 9.17.

• [C-2-4] MUSI mieć wszystkie dane umożliwiające identyfikację zaszyfrowane i uwierzytelnione kryptograficznie w taki sposób, aby nie można było ich uzyskać, odczytać ani zmienić poza odizolowanym środowiskiem wykonawczym lub układem z bezpiecznym kanałem do odizolowanego środowiska wykonawczego, zgodnie z dokumentacją w wytycznych dotyczących implementacji na stronie Android Open Source Project lub chronioną maszyną wirtualną kontrolowaną przez hiperwizor, która spełnia wymagania określone w sekcji 9.17.

• [C-2-5] W przypadku biometrii opartej na kamerze podczas uwierzytelniania lub rejestracji biometrycznej:

  • MUSI obsługiwać kamerę w trybie, który uniemożliwia odczytywanie lub modyfikowanie klatek kamery poza odizolowanym środowiskiem wykonawczym lub układem z bezpiecznym kanałem do odizolowanego środowiska wykonawczego albo chronioną maszyną wirtualną kontrolowaną przez hiperwizor, który spełnia wymagania określone w sekcji 9.17.

  • W przypadku rozwiązań z jednym aparatem RGB klatki z aparatu MOGĄ być odczytywane poza odizolowanym środowiskiem wykonawczym, aby obsługiwać operacje takie jak podgląd podczas rejestracji, ale NIE MOGĄ być zmieniane.

• [C-2-6] NIE MOŻE umożliwiać aplikacjom innych firm rozróżniania poszczególnych rejestracji danych biometrycznych.

• [C-2-7] NIE MOŻE zezwalać na niezaszyfrowany dostęp do danych biometrycznych umożliwiających identyfikację lub do danych z nich pochodzących (takich jak osadzenia) w procesorze aplikacji poza kontekstem TEE lub chronionej maszyny wirtualnej kontrolowanej przez hipernadzorcę, który spełnia wymagania określone w sekcji 9.17. Urządzenia, które zostały wprowadzone na rynek z Androidem w wersji 9 lub starszej, nie są zwolnione z wymogu [C-2-7].

• [C-2-8] MUSI mieć bezpieczny potok przetwarzania, tak aby naruszenie bezpieczeństwa systemu operacyjnego lub jądra nie umożliwiało bezpośredniego wstrzykiwania danych w celu fałszywego uwierzytelniania jako użytkownik.

• [C-SR-10] Zdecydowanie zaleca się uwzględnienie wykrywania żywotności w przypadku wszystkich metod biometrycznych oraz wykrywania uwagi w przypadku biometrii twarzy.

• [C-2-9] MUSI udostępniać czujnik biometryczny aplikacjom innych firm.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 3 (wcześniej silny):

• [C-3-1] MUSI spełniać wszystkie wymagania klasy 2 powyżej, z wyjątkiem [C-1-7] i [C-1-8].

• [C-3-2] MUSI mieć implementację magazynu kluczy wspieranego sprzętowo.

• [C-3-3] MUSI mieć współczynnik akceptacji fałszywych i podrobionych próbek nie wyższy niż 7%, przy czym (1) współczynnik akceptacji fałszywych i podrobionych próbek w przypadku instrumentów do ataków prezentacyjnych (PAI) poziomu A nie może być wyższy niż 7%, a (2) współczynnik akceptacji fałszywych i podrobionych próbek w przypadku instrumentów PAI poziomu B nie może być wyższy niż 20%, zgodnie z protokołami testów biometrycznych na Androidzie.

• [C-3-4] MUSI co 72 godziny lub rzadziej wymagać od użytkownika zalecanego podstawowego uwierzytelnienia (np. kodu PIN, wzoru lub hasła).

• [C-3-5] MUSI ponownie wygenerować identyfikator uwierzytelniania dla wszystkich danych biometrycznych klasy 3 obsługiwanych na urządzeniu, jeśli którekolwiek z nich zostaną ponownie zarejestrowane.

• [C-3-6] Musi umożliwiać aplikacjom innych firm korzystanie z kluczy w magazynie kluczy chronionym biometrycznie.

• [C-SR-16] Zdecydowanie zaleca się, aby wskaźnik akceptacji fałszywych i podrobionych próbek nie przekraczał 7% w przypadku każdego rodzaju narzędzia do ataku prezentacyjnego (PAI), zgodnie z protokołami testów biometrycznych na Androidzie.

Jeśli urządzenie ma czytnik linii papilarnych pod wyświetlaczem, musi:

• [C-SR-11] ZDECYDOWANIE ZALECA się, aby obszar dotykowy czytnika linii papilarnych pod wyświetlaczem nie zakłócał nawigacji przy użyciu 3 przycisków (która może być wymagana przez niektórych użytkowników ze względu na ułatwienia dostępu).

7.3.11. Czujnik pozycji

Implementacje urządzeń:

• MOŻE obsługiwać czujnik pozycji z 6 stopniami swobody.

Jeśli implementacje urządzeń obsługują czujnik pozycji z 6 stopniami swobody:

• [C-1-1] MUSI implementować czujnik TYPE_POSE_6DOF i raportować dane z niego.

• [C-1-2] MUSI być dokładniejszy niż sam wektor rotacji.

7.3.12. Czujnik kąta zawiasu

Jeśli implementacje urządzeń obsługują czujnik kąta zawiasu:

• [C-1-1] MUSI implementować i raportować TYPE_HINGE_ANGLE.

• [C-1-2] MUSI obsługiwać co najmniej 2 odczyty w zakresie od 0 do 360 stopni (włącznie z 0 i 360 stopniami).

• [C-1-3] MUSI zwracać czujnik wybudzania dla getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Jeśli implementacje urządzeń obsługują standard 802.1.15.4 i udostępniają funkcje aplikacji innej firmy:

• [C-1-2] MUSI zgłaszać flagę funkcji sprzętowej android.hardware.uwb.

• [C-1-3] MUSI obsługiwać wszystkie te zestawy konfiguracji (wstępnie zdefiniowane kombinacje parametrów FIRA UCI) zdefiniowane w implementacji AOSP.

  • CONFIG_ID_1: zdefiniowane przez FiRa wysyłanie sygnału typu unicast STATIC STS DS-TWR, tryb odroczony, interwał wysyłania sygnału 240 ms.

  • CONFIG_ID_2: określone przez FiRa pomiary odległości STATIC STS DS-TWR w trybie odroczonym, interwał pomiaru odległości 200 ms. Typowy przypadek użycia: smartfon wchodzi w interakcję z wieloma inteligentnymi urządzeniami.

  • CONFIG_ID_3: Tak samo jak CONFIG_ID_1, z tym że nie są raportowane dane dotyczące kąta nadejścia (AoA).

  • CONFIG_ID_4: Tak samo jak CONFIG_ID_1, z tą różnicą, że włączony jest tryb zabezpieczeń P-STS.

  • CONFIG_ID_5: Tak samo jak CONFIG_ID_2, z tą różnicą, że włączony jest tryb zabezpieczeń P-STS.

  • CONFIG_ID_6: Tak samo jak CONFIG_ID_3, z tą różnicą, że włączony jest tryb zabezpieczeń P-STS.

  • CONFIG_ID_7: tak samo jak CONFIG_ID_2, z tą różnicą, że włączony jest tryb klucza indywidualnego podmiotu kontrolowanego P-STS.

• [C-1-4] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania radia UWB.

• [C-1-5] MUSI egzekwować, aby aplikacje korzystające z radia UWB miały uprawnienie UWB_RANGING (w grupie uprawnień NEARBY_DEVICES).

Przejście odpowiednich testów zgodności i certyfikacji określonych przez organizacje normalizacyjne, w tym FIRA, CCC i CSA, pomaga zapewnić prawidłowe działanie standardu 802.1.15.4.

7.3.14. Czujniki niestandardowe

Aby zapewnić zróżnicowane działanie, implementacje urządzeń MOGĄ zawierać dodatkowe czujniki nieobjęte systemem Android ani Wear OS, do których mogą mieć dostęp wstępnie załadowane aplikacje.

W przypadku takich czujników identyfikator czujnika:

• [C-0-1] MUSI być większa niż 65536.

Jeśli czujnik niestandardowy jest przeznaczony do celów związanych ze zdrowiem lub aktywnością fizyczną:

• [C-0-2] MUSI być chroniony przez uprawnienia platformy lub uprawnienia systemowe.

7.4. Łączność danych

7.4.1. Połączenia telefoniczne

Termin „telefonia” używany w interfejsach API Androida i w tym dokumencie odnosi się konkretnie do sprzętu związanego z wykonywaniem połączeń głosowych i wysyłaniem SMS-ów lub z nawiązywaniem połączenia z mobilną transmisją danych za pomocą sieci komórkowej (np. GSM, CDMA, LTE, NR). Urządzenie obsługujące „Telefonię” może oferować niektóre lub wszystkie usługi połączeń, wiadomości i danych w zależności od produktu.

• Systemu Android MOŻNA używać na urządzeniach, które nie mają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami innymi niż telefony.

Jeśli implementacje urządzeń obejmują telefonię GSM lub CDMA:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.telephony i inne flagi podrzędnych funkcji zgodnie z technologią.

• [C-1-2] MUSI wdrożyć pełną obsługę interfejsu API dla tej technologii.

• POWINNY umożliwiać korzystanie z wszystkich dostępnych typów usług komórkowych (2G, 3G, 4G, 5G itp.) podczas połączeń alarmowych (niezależnie od typów sieci ustawionych przez SetAllowedNetworkTypeBitmap()).

Jeśli implementacje urządzeń nie obejmują sprzętu telefonicznego:

• [C-2-1] MUSI implementować pełne interfejsy API jako operacje bez efektu.

Jeśli implementacje urządzeń obsługują karty eUICC lub eSIM/wbudowane karty SIM i zawierają mechanizm zastrzeżony, który udostępnia funkcje eSIM deweloperom zewnętrznym:

• [C-3-1] MUSI zadeklarować flagę funkcji android.hardware.telephony.euicc.

Jeśli implementacje urządzeń nie ustawią właściwości systemowej ro.telephony.iwlan_operation_mode na legacy, to:

• [C-4-1] NIE MOŻE zgłaszać NETWORK_TYPE_IWLAN za pomocą NetworkRegistrationInfo#getAccessNetworkTechnology() gdy NetworkRegistrationInfo#getTransportType() jest zgłaszany jako TRANSPORT_TYPE_WWAN w przypadku tej samej instancji NetworkRegistrationInfo.

Jeśli implementacje urządzeń obsługują pojedynczą rejestrację w podsystemie multimedialnym IP (IMS) zarówno w przypadku funkcji multimedialnej usługi telefonicznej (MMTEL), jak i usługi Rich Communication Services (RCS) i mają spełniać wymagania operatorów komórkowych dotyczące używania pojedynczej rejestracji w IMS w przypadku całego ruchu sygnalizacyjnego IMS:

• [C-5-1] MUSI zadeklarować flagę funkcji android.hardware.telephony.ims i zapewnić pełną implementację interfejsu ImsService API dla MMTEL i RCS interfejsu User Capability Exchange API.

• [C-5-2] MUSI zadeklarować flagę funkcji android.hardware.telephony.ims.singlereg i zapewnić pełną implementację interfejsu SipTransport API, interfejsu GbaService API, dedykowanych wskaźników nośnika za pomocą IRadio 1.6 HAL oraz udostępniania za pomocą serwera automatycznej konfiguracji (ACS) lub innego zastrzeżonego mechanizmu udostępniania za pomocą interfejsu IMS Configuration API.

Jeśli implementacje urządzeń zgłaszają funkcję android.hardware.telephony:

• [C-6-1] Funkcje SmsManager#sendTextMessage i SmsManager#sendMultipartTextMessage MUSZĄ powodować odpowiednie wywołania funkcji CarrierMessagingService w celu zapewnienia możliwości wysyłania wiadomości tekstowych. SmsManager#sendMultimediaMessage i SmsManager#downloadMultimediaMessage MUSZĄ powodować odpowiednie wywołania funkcji CarrierMessagingService w celu zapewnienia funkcji przesyłania wiadomości multimedialnych.

• [C-6-2] Aplikacja wskazana przez android.provider.Telephony.Sms#getDefaultSmsPackage MUSI używać interfejsów API SmsManager podczas wysyłania i odbierania wiadomości SMS i MMS. Implementacja referencyjna AOSP w pakietach/aplikacjach/Messaging spełnia to wymaganie.

• [C-6-3] Aplikacja, która odpowiada na Intent#ACTION_DIAL, MUSI obsługiwać wprowadzanie dowolnych kodów dialera w formacie *#*#CODE#*#* i wywoływać odpowiednią transmisję TelephonyManager#ACTION_SECRET_CODE.

• [C-6-4] Aplikacja, która odpowiada na Intent#ACTION_DIAL MUSI używać VoicemailContract.Voicemails#TRANSCRIPTION do wyświetlania użytkownikom transkrypcji wizualnej poczty głosowej, jeśli obsługuje transkrypcje wizualnej poczty głosowej.

• [C-6-5] MUSI reprezentować wszystkie obiekty SubscriptionInfo z równoważnymi identyfikatorami UUID grupy jako jedną subskrypcję we wszystkich interfejsach widocznych dla użytkownika, które wyświetlają informacje o karcie SIM i umożliwiają ich kontrolowanie. Przykłady takich ułatwień to interfejsy ustawień, które pasują do Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS lub EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.

• [C-6-6] NIE MOŻE wyświetlać ani umożliwiać kontrolowania żadnych informacji SubscriptionInfo z niepustym identyfikatorem UUID grupy i bitem oportunistycznym w żadnych widocznych dla użytkownika elementach interfejsu, które umożliwiają konfigurowanie lub kontrolowanie ustawień karty SIM.

Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.telephony i zapewniają pasek stanu systemu:

• [C-7-1] MUSI wybrać reprezentatywną aktywną subskrypcję dla danego identyfikatora UUID grupy, aby wyświetlić ją użytkownikowi w dowolnych elementach interfejsu, które zawierają informacje o stanie karty SIM. Przykłady takich elementów to ikona sygnału komórkowego na pasku stanu lub kafelek Szybkich ustawień.

• [C-SR-1] Zdecydowanie zalecamy, aby subskrypcja reprezentatywna była aktywną subskrypcją danych, chyba że urządzenie jest w trakcie połączenia głosowego. W takim przypadku zdecydowanie zalecamy, aby subskrypcja reprezentatywna była aktywną subskrypcją głosową.

Jeśli implementacje urządzeń zgłaszają funkcję android.hardware.telephony:

• [C-6-7] MUSI być w stanie otworzyć i jednocześnie wykorzystywać maksymalną liczbę kanałów logicznych (łącznie 20) dla każdej karty UICC zgodnie z dokumentem ETSI TS 102 221.

• [C-6-8] NIE WOLNO stosować żadnego z tych zachowań w przypadku aktywnych aplikacji operatora (oznaczonych symbolem TelephonyManager#getCarrierServicePackageName) automatycznie lub bez wyraźnego potwierdzenia użytkownika:

  • Odbieranie lub ograniczanie dostępu do sieci
  • Cofanie uprawnień
  • Ograniczanie wykonywania aplikacji w tle lub na pierwszym planie poza istniejącymi funkcjami zarządzania energią w AOSP
  • Wyłączanie lub odinstalowywanie aplikacji

Jeśli implementacje urządzeń zgłaszają funkcję android.hardware.telephony i wszystkie aktywne subskrypcje nieopportunistyczne, które mają wspólny identyfikator UUID grupy, są wyłączone, fizycznie usunięte z urządzenia lub oznaczone jako opportunistyczne, urządzenie:

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

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

• [C-9-1] NIE MOŻE deklarować PackageManager#FEATURE_TELEPHONY_CDMA.

• [C-9-2] MUSI zgłaszać błąd IllegalArgumentException podczas prób ustawienia dowolnego typu sieci 3GPP2 w maskach bitowych preferowanego lub dozwolonego typu sieci.

• [C-9-3] MUSI zwracać pusty ciąg znaków z funkcji TelephonyManager#getMeid.

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

• [C-10-1] MUSI zadeklarować flagę funkcji android.hardware.telephony.euicc.mep.

7.4.1.1. Zgodność z blokowaniem numerów

Jeśli implementacje urządzeń zgłaszają funkcję android.hardware.telephony.calling, to:

• [C-1-1] MUSI obsługiwać blokowanie numerów

• [C-1-2] MUSI w pełni implementować BlockedNumberContract i odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu SDK.

• [C-1-3] MUSI blokować wszystkie połączenia i wiadomości z numeru telefonu w BlockedNumberProvider bez interakcji z aplikacjami. Jedynym wyjątkiem jest sytuacja, gdy blokowanie numerów zostanie tymczasowo zniesione, jak opisano w dokumentacji pakietu SDK.

• [C-1-4] MUSI zapisywać w usłudze rejestru połączeń platformy informacje o zablokowanym połączeniu i MUSI filtrować połączenia z BLOCKED_TYPE, aby nie były widoczne w domyślnym widoku rejestru połączeń w zainstalowanej fabrycznie aplikacji telefonu.

• [C-1-5] NIE MOŻE wysyłać do operatora telefonicznego informacji o zablokowanej wiadomości.

• [C-1-6] MUSI implementować interfejs zarządzania zablokowanymi numerami, który jest otwierany za pomocą intencji zwróconej przez metodę TelecomManager.createManageBlockedNumbersIntent().

• [C-1-7] NIE MOŻE zezwalać użytkownikom dodatkowym na wyświetlanie ani edytowanie zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że użytkownik podstawowy ma pełną kontrolę nad usługami telefonicznymi (jedną instancją) na urządzeniu. Wszystkie elementy interfejsu związane z blokowaniem MUSZĄ być ukryte dla użytkowników dodatkowych, a lista zablokowanych MUSI być nadal uwzględniana.

• POWINNO przenieść zablokowane numery do dostawcy, gdy urządzenie zostanie zaktualizowane do Androida 7.0.

• POWINNA udostępniać użytkownikowi możliwość wyświetlania zablokowanych połączeń w preinstalowanej aplikacji do wybierania numerów.

7.4.1.2. Telecom API

Jeśli implementacje urządzeń zgłaszają android.hardware.telephony.calling, to:

• [C-1-1] MUSI obsługiwać interfejsy API ConnectionService opisane w pakiecie SDK.

• [C-1-2] MUSI wyświetlać nowe połączenie przychodzące i umożliwiać użytkownikowi zaakceptowanie lub odrzucenie połączenia przychodzącego, gdy użytkownik prowadzi rozmowę za pomocą aplikacji innej firmy, która nie obsługuje funkcji wstrzymania określonej w CAPABILITY_SUPPORT_HOLD.

• [C-1-3] MUSI mieć aplikację, która implementuje InCallService.

• [C-SR-1] Zdecydowanie zaleca się powiadamianie użytkownika, że odebranie połączenia przychodzącego spowoduje przerwanie trwającego połączenia.

  Implementacja AOSP spełnia te wymagania dzięki powiadomieniu z ostrzeżeniem, które informuje użytkownika, że odebranie połączenia przychodzącego spowoduje rozłączenie innego połączenia.

• [C-SR-2] ZDECYDOWANIE ZALECA się wstępne wczytywanie domyślnej aplikacji do wybierania numerów, która w swoim dzienniku połączeń wyświetla wpis dziennika połączeń i nazwę aplikacji innej firmy, gdy ta aplikacja ustawia klucz dodatkowy EXTRA_LOG_SELF_MANAGED_CALLS w swoim elemencie PhoneAccount na wartość true.

• [C-SR-3] ZDECYDOWANIE ZALECANE jest obsługiwanie zdarzeń KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK słuchawek z mikrofonem w przypadku interfejsów API android.telecom w sposób opisany poniżej:

  • Wywołanie Connection.onDisconnect() gdy podczas trwającego połączenia zostanie wykryte krótkie naciśnięcie klawisza.

  • Wywołaj Connection.onAnswer(), gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie klawisza.

  • Wywołaj Connection.onReject(), gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie klawisza.

  • Przełącz stan wyciszenia CallAudioState.

7.4.1.3. Odciążanie utrzymywania aktywności NAT-T w sieci komórkowej

Implementacje urządzeń:

• POWINIEN obsługiwać odciążanie funkcji keepalive sieci komórkowej.

Jeśli implementacje urządzeń obsługują przeniesienie funkcji utrzymywania połączenia komórkowego i udostępniają tę funkcję aplikacjom innych firm, muszą:

• [C-1-1] MUSI obsługiwać interfejs SocketKeepAlive API.

• [C-1-2] MUSI obsługiwać co najmniej 1 równoczesne gniazdo keepalive w sieci komórkowej.

• [C-1-3] MUSI obsługiwać tyle równoczesnych gniazd podtrzymania połączenia komórkowego, ile jest obsługiwanych przez interfejs HAL radia komórkowego.

• [C-SR-1] Zdecydowanie zaleca się obsługę co najmniej 3 gniazd podtrzymujących połączenie komórkowe na instancję radiową.

Jeśli implementacje urządzeń nie obsługują przenoszenia funkcji keepalive sieci komórkowej,

• [C-2-1] MUSI zwrócić ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementacje urządzeń:

• POWINIEN obsługiwać co najmniej jeden standard 802.11.

Jeśli implementacje urządzeń obsługują standard 802.11 i udostępniają funkcje aplikacji innej firmy:

• [C-1-1] MUSI implementować odpowiedni interfejs API Androida.

• [C-1-2] MUSI zgłaszać flagę funkcji sprzętowej android.hardware.wifi.

• [C-1-3] MUSI zaimplementować interfejs API do transmisji grupowej zgodnie z opisem w dokumentacji pakietu SDK.

• [C-1-4] MUSI obsługiwać mDNS i NIE MOŻE filtrować pakietów mDNS (224.0.0.251 lub ff02::fb) w żadnym momencie działania, w tym gdy ekran nie jest aktywny, chyba że blokada multiemisji nie jest utrzymywana, a pakiety są filtrowane przez APF. Pakiety nie muszą spełniać żadnych operacji mDNS, o które aplikacje proszą obecnie za pomocą interfejsów API NsdManager. Urządzenie MOŻE jednak filtrować pakiety mDNS, jeśli jest to konieczne, aby utrzymać się w zakresach zużycia energii wymaganych przez przepisy obowiązujące na rynku docelowym.

• [C-1-5] NIE MOŻE traktować wywołania metody interfejsu API WifiManager.enableNetwork() jako wystarczającej wskazówki do przełączenia aktualnie aktywnego Network, który jest domyślnie używany w przypadku ruchu aplikacji i zwracany przez metody interfejsu API ConnectivityManager, takie jak getActiveNetwork i registerDefaultNetworkCallback. Innymi słowy, MOGĄ wyłączyć dostęp do internetu zapewniany przez innego dostawcę sieci (np. mobilną transmisję danych) TYLKO wtedy, gdy potwierdzą, że sieć Wi-Fi zapewnia dostęp do internetu.

• [C-1-6] ZDECYDOWANIE ZALECA się, aby po wywołaniu metody interfejsu API ConnectivityManager.reportNetworkConnectivity() ponownie ocenić dostęp do internetu na urządzeniu Network i gdy ocena wykaże, że bieżące urządzenie Network nie zapewnia już dostępu do internetu, przełączyć się na dowolną inną dostępną sieć (np. dane komórkowe), która zapewnia dostęp do internetu.

• [C-1-7] MUSI losowo wybierać źródłowy adres MAC i numer sekwencyjny ramek żądania sondy, raz na początku każdego skanowania, gdy STA jest odłączony.

• [C-1-8] MUSI używać jednego spójnego adresu MAC (NIE POWINIEN losować adresu MAC w połowie skanowania).

• [C-1-9] MUSI iterować numer sekwencji żądania sondy w normalny sposób (sekwencyjnie) między żądaniami sondy w skanowaniu.

• [C-1-10] MUSI losowo wybierać numer sekwencyjny żądania sondowania między ostatnim żądaniem sondowania w skanowaniu a pierwszym żądaniem sondowania w następnym skanowaniu.

• [C-SR-1] ZDECYDOWANIE ZALECA się randomizację źródłowego adresu MAC używanego do całej komunikacji STA z punktem dostępu podczas łączenia i połączenia.

  • Urządzenie MUSI używać innego randomizowanego adresu MAC dla każdego SSID (FQDN dla Passpoint), z którym się komunikuje.

  • Urządzenie MUSI udostępniać użytkownikowi opcję kontrolowania randomizacji dla każdego identyfikatora SSID (FQDN w przypadku Passpoint) z opcjami bez randomizacji i z randomizacją oraz MUSI ustawiać domyślny tryb dla nowych konfiguracji Wi-Fi na randomizację.

• [C-SR-2] ZDECYDOWANIE ZALECA się używanie losowego identyfikatora BSSID w przypadku każdego punktu dostępu, który tworzą.

  • Adres MAC MUSI być randomizowany i utrwalany dla każdego identyfikatora SSID używanego przez punkt dostępu.

  • URZĄDZENIE może udostępniać użytkownikowi opcję wyłączenia tej funkcji. Jeśli taka opcja jest dostępna, randomizacja MUSI być domyślnie włączona.

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

• POWINNO wyłączać tryb oszczędzania energii Wi-Fi, gdy aplikacja uzyskuje blokadę WIFI_MODE_FULL_HIGH_PERF lub blokadę WIFI_MODE_FULL_LOW_LATENCY za pomocą interfejsów API WifiManager.createWifiLock() i WifiManager.WifiLock.acquire(), a blokada jest aktywna.

• [C-3-2] Średni czas oczekiwania w ruchu w obie strony między urządzeniem a punktem dostępu, gdy urządzenie jest w trybie blokady niskiego opóźnienia Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY), MUSI być mniejszy niż czas oczekiwania w trybie blokady wysokiej wydajności Wi-Fi (WIFI_MODE_FULL_HIGH_PERF).

• [C-SR-3] są ZDECYDOWANIE ZALECANE, aby zminimalizować opóźnienie w obie strony w przypadku Wi-Fi, gdy tylko zostanie uzyskana blokada niskiego opóźnienia (WIFI_MODE_FULL_LOW_LATENCY) i zacznie obowiązywać.

Jeśli implementacje urządzeń obsługują Wi-Fi i używają tej sieci do skanowania lokalizacji:

• [C-2-1] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania odczytu wartości za pomocą metody interfejsu API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementacje urządzeń:

• POWINNY obsługiwać Wi-Fi Direct (Wi-Fi peer-to-peer).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Direct:

• [C-1-1] MUSI implementować odpowiedni interfejs API Androida zgodnie z opisem w dokumentacji pakietu SDK.

• [C-1-2] MUSI raportować funkcję sprzętową android.hardware.wifi.direct.

• [C-1-3] MUSI obsługiwać standardowe działanie Wi-Fi.

• [C-1-4] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Direct.

• [C-SR-1] ZDECYDOWANIE ZALECA się losowe generowanie źródłowego adresu MAC w przypadku wszystkich nowo utworzonych połączeń Wi-Fi Direct.

7.4.2.2. Konfiguracja tunelowanego bezpośredniego połączenia Wi-Fi

Implementacje urządzeń:

• POWINIEN obsługiwać konfigurację tunelowanego bezpośredniego połączenia Wi-Fi (TDLS) zgodnie z dokumentacją pakietu Android SDK.

Jeśli implementacje urządzeń obejmują obsługę TDLS, a TDLS jest włączony przez interfejs API WiFiManager:

• [C-1-1] MUSI deklarować obsługę TDLS za pomocą WifiManager.isTdlsSupported.

• TDLS należy używać tylko wtedy, gdy jest to możliwe I korzystne.

• POWINNO mieć pewne heurystyki i NIE używać TDLS, gdy jego wydajność może być gorsza niż w przypadku połączenia przez punkt dostępu Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementacje urządzeń:

• POWINIEN obsługiwać Wi-Fi Aware.

Jeśli implementacje urządzeń obsługują Wi-Fi Aware i udostępniają tę funkcję aplikacjom innych firm, muszą:

• [C-1-1] MUSI implementować interfejsy API WifiAwareManager zgodnie z opisem w dokumentacji pakietu SDK.

• [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.aware.

• [C-1-3] MUSI obsługiwać jednocześnie operacje Wi-Fi i Wi-Fi Aware.

• [C-1-4] MUSI losowo zmieniać adres interfejsu zarządzania Wi-Fi Aware w odstępach nie dłuższych niż 30 minut i za każdym razem, gdy Wi-Fi Aware jest włączone, chyba że trwa operacja pomiaru odległości Aware lub aktywna jest ścieżka danych Aware (losowa zmiana nie jest oczekiwana, dopóki ścieżka danych jest aktywna).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i lokalizacji Wi-Fi zgodnie z opisem w sekcji 7.4.2.5 i udostępniają te funkcje aplikacjom innych firm, muszą:

• [C-2-1] MUSI implementować interfejsy API wykrywania opartego na lokalizacji: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm i onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Jeśli urządzenia obsługują standard 802.11 (Wi-Fi):

• POWINIEN obsługiwać Wi-Fi Passpoint.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Passpoint:

• [C-1-2] MUSI implementować interfejsy API związane z Passpoint WifiManager zgodnie z opisem w dokumentacji pakietu SDK.

• [C-1-3] MUSI obsługiwać standard IEEE 802.11u, w szczególności w zakresie wykrywania i wyboru sieci, np. protokół GAS (Generic Advertisement Service) i ANQP (Access Network Query Protocol).

• [C-1-4] MUSI zadeklarować flagę funkcji android.hardware.wifi.passpoint.

• [C-1-5] MUSI postępować zgodnie z implementacją AOSP w zakresie wykrywania, dopasowywania i powiązywania sieci Passpoint.

• [C-1-6] MUSI obsługiwać co najmniej ten podzbiór protokołów obsługi administracyjnej urządzeń zdefiniowanych w specyfikacji Wi-Fi Alliance Passpoint R2: uwierzytelnianie EAP-TTLS i SOAP-XML.

• [C-1-7] MUSI przetwarzać certyfikat serwera AAA zgodnie z opisem w specyfikacji Hotspot 2.0 R3.

• [C-1-8] MUSI obsługiwać kontrolę użytkownika nad udostępnianiem za pomocą selektora Wi-Fi.

• [C-1-9] MUSI zachowywać konfiguracje Passpoint po ponownym uruchomieniu.

• [C-SR-1] ZDECYDOWANIE ZALECA SIĘ obsługę funkcji akceptacji warunków korzystania z usługi.

• [C-SR-2] ZDECYDOWANIE ZALECA się obsługę funkcji informacji o miejscu.

Jeśli dostępny jest globalny przełącznik wyłączania Passpointa przez użytkownika, implementacje:

• [C-3-1] MUSI domyślnie włączać Passpoint.

7.4.2.5. Lokalizacja Wi-Fi (czas błądzenia Wi-Fi – RTT)

Implementacje urządzeń:

• POWINIEN obsługiwać lokalizację Wi-Fi.

Jeśli implementacje urządzeń obsługują lokalizację Wi-Fi i udostępniają tę funkcję aplikacjom innych firm, muszą:

• [C-1-1] MUSI implementować interfejsy API WifiRttManager zgodnie z opisem w dokumentacji pakietu SDK.

• [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.rtt.

• [C-1-3] MUSI losowo generować źródłowy adres MAC dla każdego pakietu RTT wykonywanego, gdy interfejs Wi-Fi, na którym jest wykonywany RTT, nie jest połączony z punktem dostępu.

• [C-1-4] MUSI być dokładny w zakresie 2 metrów przy paśmie o szerokości 80 MHz w 68 percentylu (obliczanym za pomocą funkcji dystrybuanty).

• [C-SR-1] Zdecydowanie zaleca się podawanie dokładnych informacji z dokładnością do 1,5 m przy paśmie o szerokości 80 MHz na 68 percentylu (obliczanym za pomocą funkcji rozkładu skumulowanego).

7.4.2.6. Odciążanie utrzymywania aktywności Wi-Fi

Implementacje urządzeń:

• POWINIEN obsługiwać odciążanie funkcji utrzymywania połączenia Wi-Fi.

Jeśli implementacje urządzeń obsługują przenoszenie działania Wi-Fi keepalive na procesor pomocniczy i udostępniają tę funkcję aplikacjom innych firm:

• [C-1-1] MUSI obsługiwać interfejs SocketKeepAlive.

• [C-1-2] MUSI obsługiwać co najmniej 3 jednocześnie działające gniazda podtrzymujące połączenie przez Wi-Fi.

Jeśli implementacje urządzeń nie obsługują przenoszenia funkcji keepalive Wi-Fi na procesor Wi-Fi:

• [C-2-1] MUSI zwrócić ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protokół udostępniania urządzenia)

Implementacje urządzeń:

• POWINNO obejmować obsługę Wi-Fi Easy Connect (DPP).

Jeśli implementacje urządzeń obsługują Wi-Fi Easy Connect i udostępniają tę funkcję aplikacjom innych firm:

• [C-1-1] MUSI zwracać wartość true w przypadku metody WifiManager#isEasyConnectSupported().

7.4.2.8. Weryfikacja certyfikatu serwera Wi-Fi w firmie

Jeśli certyfikat serwera Wi-Fi nie zostanie zweryfikowany lub nazwa domeny serwera Wi-Fi nie zostanie ustawiona, implementacje urządzeń:

• [C-SR-1] Zdecydowanie zaleca się, aby nie udostępniać użytkownikowi opcji ręcznego dodawania sieci Wi-Fi dla firm w aplikacji Ustawienia.

7.4.2.9. Zaufaj przy pierwszym użyciu (TOFU)

Jeśli implementacje urządzeń obsługują zaufanie przy pierwszym użyciu (TOFU) i umożliwiają użytkownikowi definiowanie konfiguracji WPA/WPA2/WPA3-Enterprise:

• [C-4-1] MUSI udostępniać użytkownikowi opcję wyboru korzystania z TOFU.

7.4.2.10. Wykrywanie urządzeń w pobliżu za pomocą Wi-Fi (określanie odległości między urządzeniami)

7.4.3. Bluetooth

Jeśli implementacje urządzeń obsługują profil audio Bluetooth:

• POWINNY obsługiwać zaawansowane kodeki audio i kodeki dźwięku Bluetooth (np. LDAC).

Jeśli implementacje urządzeń obsługują profile HFP, A2DP i AVRCP:

• POWINNO obsługiwać co najmniej 5 połączonych urządzeń.

Jeśli implementacje urządzeń deklarują funkcję android.hardware.vr.high_performance, to:

• [C-1-1] MUSI obsługiwać Bluetooth 4.2 i rozszerzenie długości danych Bluetooth LE.

Android obsługuje Bluetooth i Bluetooth Low Energy.

Jeśli urządzenia obsługują Bluetooth i Bluetooth Low Energy:

• [C-2-1] MUSI zadeklarować odpowiednie funkcje platformy (android.hardware.bluetooth i android.hardware.bluetooth_le) oraz zaimplementować interfejsy API platformy.

• POWINNO implementować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX, HFP itp., w zależności od urządzenia.

Jeśli urządzenia obsługują Bluetooth Low Energy (BLE):

• [C-3-1] MUSI zadeklarować funkcję sprzętową android.hardware.bluetooth_le.

• [C-3-2] MUSI włączyć interfejsy API Bluetooth oparte na profilu GATT (generic attribute profile) zgodnie z opisem w dokumentacji pakietu SDK i android.bluetooth.

• [C-3-3] MUSI zgłaszać prawidłową wartość parametru BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy zaimplementowano logikę filtrowania klas interfejsu API ScanFilter.

• [C-3-4] MUSI zgłaszać prawidłową wartość atrybutu BluetoothAdapter.isMultipleAdvertisementSupported(), aby wskazać, czy obsługiwane są reklamy o niskim zużyciu energii.

• [C-3-5] MUSI implementować czas oczekiwania dla adresu prywatnego z możliwością rozwiązania (RPA) nie dłuższy niż 15 minut i obracać adres po upływie czasu oczekiwania, aby chronić prywatność użytkownika, gdy urządzenie aktywnie korzysta z BLE do skanowania lub rozgłaszania. Aby zapobiec atakom czasowym, przedziały czasu oczekiwania MUSZĄ być też losowe i mieścić się w zakresie od 5 do 15 minut.

• W przypadku implementacji interfejsu ScanFilter API urządzenie POWINNO obsługiwać przenoszenie logiki filtrowania do chipsetu Bluetooth.

• POWINIEN obsługiwać przenoszenie skanowania wsadowego do chipsetu Bluetooth.

• POWINIEN obsługiwać wiele reklam z co najmniej 4 slotami.

Jeśli implementacje urządzeń obsługują Bluetooth LE i używają go do skanowania lokalizacji:

• [C-4-1] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania odczytu wartości za pomocą interfejsu System API BluetoothAdapter.isBleScanAlwaysAvailable().

Jeśli implementacje urządzeń obejmują obsługę Bluetooth LE i profilu aparatów słuchowych, zgodnie z opisem w obsłudze dźwięku z aparatów słuchowych za pomocą Bluetooth LE, to:

• [C-5-1] MUSI zwracać true dla BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Jeśli implementacje urządzeń obejmują obsługę Bluetootha lub Bluetooth Low Energy:

• [C-6-1] MUSI ograniczać dostęp do wszelkich metadanych Bluetootha (takich jak wyniki skanowania), które mogą być używane do określania lokalizacji urządzenia, chyba że aplikacja wysyłająca żądanie pomyślnie przejdzie kontrolę uprawnień android.permission.ACCESS_FINE_LOCATION na podstawie bieżącego stanu (na pierwszym planie lub w tle).

Jeśli implementacje urządzeń obsługują Bluetooth lub Bluetooth Low Energy, a plik manifestu aplikacji nie zawiera deklaracji dewelopera, że nie uzyskuje on lokalizacji z Bluetootha:

• [C-6-2] Dostęp do Bluetootha MUSI być ograniczony przez android.permission.ACCESS_FINE_LOCATION.

Jeśli implementacje urządzeń zwracają true w przypadku interfejsu API BluetoothAdapter.isLeAudioSupported():

• [C-7-1] MUSI obsługiwać klienta unicast.

• [C-7-2] MUSI obsługiwać warstwę PHY 2M.

• [C-7-3] MUSI obsługiwać rozszerzone rozgłaszanie LE.

• [C-7-4] MUSI obsługiwać co najmniej 2 połączenia CIS w ramach CIG.

• [C-7-5] MUSI jednocześnie włączyć klienta emisji pojedynczej BAP, koordynatora zestawu CSIP, serwer MCP, kontroler VCP i serwer CCP.

• [C-SR-1] Zdecydowanie zalecamy włączenie klienta HAP unicast.

Jeśli implementacje urządzeń zwracają true w przypadku interfejsu API BluetoothAdapter.isLeAudioBroadcastSourceSupported():

• [C-8-1] MUSI obsługiwać co najmniej 2 połączenia BIS w BIG.

• [C-8-2] MUSI jednocześnie włączyć źródło transmisji BAP i asystenta transmisji BAP.

• [C-8-3] MUSI obsługiwać rozgłaszanie okresowe LE.

Jeśli implementacje urządzeń zwracają true w przypadku interfejsu API BluetoothAdapter.isLeAudioBroadcastAssistantSupported():

• [C-9-1] MUSI obsługiwać PAST (Periodic Advertising Sync Transfer).

• [C-9-2] MUSI obsługiwać rozgłaszanie okresowe LE.

Jeśli implementacje urządzeń deklarują FEATURE_BLUETOOTH_LE, to:

• [C-10-1] W 95% pomiarów w odległości 1 m od urządzenia referencyjnego transmitującego sygnał o mocy ADVERTISE_TX_POWER_HIGH w środowisku o bezpośredniej widoczności pomiary RSSI MUSZĄ mieścić się w zakresie +/-9 dB.

• [C-10-2] MUSI zawierać korekty Rx/Tx, aby zmniejszyć odchylenia w poszczególnych kanałach, tak aby pomiary na każdym z 3 kanałów na każdej z anten (jeśli używanych jest kilka) mieściły się w zakresie +/-3 dB w 95% pomiarów.

Jeśli implementacje urządzeń deklarują FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING, to:

• [C-11-1] MUSI raportować flagę funkcji sprzętowej android.hardware.bluetooth_le.channel_sounding.

• [C-11-2] MUSI zgłaszać zakres z dokładnością do +/- 0,5 m w 90 percentylu, obliczanym za pomocą funkcji dystrybuanty, w odległości 1 m.

Jeśli implementacje urządzeń deklarują FEATURE_BLUETOOTH_LE, to:

• [C-SR-2] Zdecydowanie zaleca się pomiar i kompensację przesunięcia Rx, aby zapewnić, że mediana RSSI BLE wynosi -60 dBm +/-10 dB w odległości 1 m od urządzenia referencyjnego transmitującego na poziomie ADVERTISE_TX_POWER_HIGH, przy czym urządzenia są zorientowane tak, aby znajdowały się na „równoległych płaszczyznach”, a ekrany były skierowane w tym samym kierunku.

• [C-SR-3] Zdecydowanie zaleca się pomiar i kompensację przesunięcia Tx, aby zapewnić, że mediana BLE RSSI wynosi -60 dBm +/-10 dB podczas skanowania z urządzenia referencyjnego umieszczonego w odległości 1 m i nadającego sygnał na poziomie ADVERTISE_TX_POWER_HIGH, przy czym urządzenia są ustawione tak, aby znajdowały się na „równoległych płaszczyznach”, a ekrany były skierowane w tym samym kierunku.

Zdecydowanie ZALECA się wykonanie czynności konfiguracyjnych pomiarów podanych w artykule Wymagania dotyczące kalibracji obecności.

7.4.4. Komunikacja bliskiego pola

Implementacje urządzeń:

• POWINIEN zawierać nadajnik-odbiornik i powiązany sprzęt do komunikacji Near Field Communication (NFC).

• [C-0-1] MUSI implementować interfejsy API android.nfc.NdefMessage i android.nfc.NdefRecord, nawet jeśli nie obsługują one NFC lub nie deklarują funkcji android.hardware.nfc, ponieważ klasy te reprezentują format danych niezależny od protokołu.

Jeśli implementacje urządzeń obejmują sprzęt NFC i mają być udostępniane aplikacjom innych firm:

• [C-1-1] MUSI raportować funkcję android.hardware.nfc z metody android.content.pm.PackageManager.hasSystemFeature().

• MUSI umożliwiać odczytywanie i zapisywanie wiadomości NDEF za pomocą poniższych standardów NFC:

• [C-1-2] MUSI mieć możliwość działania jako czytnik/zapisywarka NFC Forum (zgodnie ze specyfikacją techniczną NFC Forum NFCForum-TS-DigitalProtocol-1.0) w ramach tych standardów NFC:

  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NFC-F (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Typy tagów NFC Forum 2, 3, 4, 5 (zdefiniowane przez NFC Forum)

• [C-SR-1] ZDECYDOWANIE ZALECANE jest, aby urządzenie obsługiwało odczytywanie i zapisywanie wiadomości NDEF oraz surowych danych za pomocą tych standardów NFC: Pamiętaj, że chociaż standardy NFC są ZDECYDOWANIE ZALECANE, w przyszłej wersji definicji zgodności planujemy zmienić je na WYMAGANE. W tej wersji te standardy są opcjonalne, ale w przyszłych wersjach będą wymagane. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z tą wersją Androida spełniały te wymagania już teraz, aby można było je uaktualnić do przyszłych wersji platformy.

• [C-1-13] MUSI odpytywać wszystkie obsługiwane technologie w trybie wykrywania NFC.

• POWINNO być w trybie wykrywania NFC, gdy urządzenie jest włączone, ekran jest aktywny, a ekran blokady jest odblokowany.

• POWINNO być w stanie odczytać kod kreskowy i adres URL (jeśli jest zakodowany) produktów Thinfilm NFC Barcode.

Pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku wymienionych powyżej specyfikacji JIS, ISO i NFC Forum.

Android obsługuje tryb emulacji karty hosta (HCE) NFC.

Jeśli implementacje urządzeń obejmują chipset kontrolera NFC obsługujący HCE (w przypadku NfcA lub NfcB) i kierowanie na podstawie identyfikatora aplikacji (AID), to:

• [C-2-1] MUSI zgłaszać stałą funkcji android.hardware.nfc.hce.

• [C-2-2] MUSI obsługiwać interfejsy NFC HCE API zdefiniowane w pakiecie Android SDK.

Jeśli implementacje urządzeń zawierają chipset kontrolera NFC obsługujący HCE dla NfcF i implementują tę funkcję dla aplikacji innych firm:

• [C-3-1] MUSI zgłaszać stałą funkcji android.hardware.nfc.hcef.

• [C-3-2] MUSI implementować interfejsy API emulacji kart NFC-F zgodnie z definicją w pakiecie Android SDK.

Jeśli implementacje urządzeń obejmują ogólną obsługę NFC opisaną w tej sekcji i obsługują technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF na MIFARE Classic) w roli czytnika/zapisywarki:

• [C-4-1] MUSI implementować odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.

• [C-4-2] MUSI raportować funkcję com.nxp.mifare z metody android.content.pm.PackageManager.hasSystemFeature(). Pamiętaj, że nie jest to standardowa funkcja Androida, dlatego nie występuje jako stała w klasie android.content.pm.PackageManager.

7.4.5. Protokoły sieciowe i interfejsy API

7.4.5.1. Minimalna funkcjonalność sieci

Implementacje urządzeń:

• [C-0-1] MUSI obsługiwać co najmniej 1 formę sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o przepustowości co najmniej 200 kbit/s. Przykłady technologii spełniających to wymaganie to EDGE, HSPA, EV-DO, 802.11g, Ethernet i Bluetooth PAN.

• POWINNO też obejmować obsługę co najmniej jednego popularnego standardu bezprzewodowej transmisji danych, takiego jak 802.11 (Wi-Fi), gdy podstawowym połączeniem do transmisji danych jest fizyczny standard sieciowy (taki jak Ethernet).

• MOŻE obsługiwać więcej niż jeden rodzaj łączności danych.

7.4.5.2. IPv6

Implementacje urządzeń:

• [C-0-2] MUSI zawierać stos sieciowy IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection, a także natywnych interfejsów API, takich jak gniazda AF_INET6.

• [C-0-3] MUSI domyślnie włączać protokół IPv6.

• MUSI zapewnić, że komunikacja IPv6 jest tak samo niezawodna jak IPv4, np.:

• [C-0-4] MUSI utrzymywać łączność IPv6 w trybie uśpienia.

• [C-0-5] Ograniczanie szybkości NIE MOŻE powodować utraty łączności IPv6 przez urządzenie w żadnej sieci zgodnej z IPv6, która używa czasu życia RA wynoszącego co najmniej 180 sekund.

• [C-0-6] MUSI zapewniać aplikacjom innych firm bezpośrednie połączenie z siecią IPv6, gdy urządzenie jest połączone z siecią IPv6, bez żadnego tłumaczenia adresu lub portu na urządzeniu. Zarówno zarządzane interfejsy API, takie jak Socket#getLocalAddress lub Socket#getLocalPort, jak i interfejsy NDK API, takie jak getsockname() lub IPV6_PKTINFO, MUSZĄ zwracać adres IP i port, które są faktycznie używane do wysyłania i odbierania pakietów w sieci i są widoczne jako źródłowy adres IP i port dla serwerów internetowych.

Wymagany poziom obsługi protokołu IPv6 zależy od typu sieci, jak pokazują poniższe wymagania.

Jeśli urządzenia obsługują Wi-Fi:

• [C-1-1] MUSI obsługiwać podwójny stos i działanie tylko w IPv6 w przypadku Wi-Fi.

Jeśli urządzenia obsługują Ethernet:

• [C-2-1] MUSI obsługiwać podwójny stos i działanie tylko w IPv6 w sieci Ethernet.

Jeśli implementacje urządzeń obsługują komórkową transmisję danych:

• [C-3-1] MUSI obsługiwać działanie w sieci komórkowej w protokole IPv6 (tylko IPv6 i ewentualnie stos podwójny).

Jeśli implementacje urządzeń obsługują więcej niż 1 typ sieci (np. Wi-Fi i dane komórkowe):

• [C-4-1] MUSI jednocześnie spełniać powyższe wymagania w każdej sieci, gdy urządzenie jest jednocześnie połączone z więcej niż jednym typem sieci.

7.4.5.3. Portale przechwytujące

Portal przechwytujący to sieć, która wymaga zalogowania się, aby uzyskać dostęp do internetu.

Jeśli implementacje urządzeń zapewniają pełną implementację interfejsu android.webkit.Webview API, to:

• [C-1-1] MUSI udostępniać aplikację portalu przechwytującego do obsługi intencji ACTION_CAPTIVE_PORTAL_SIGN_IN i wyświetlania strony logowania w portalu przechwytującym przez wysyłanie tej intencji podczas wywołania interfejsu API systemu ConnectivityManager#startCaptivePortalApp(Network, Bundle).

• [C-1-2] MUSI wykrywać portale przechwytujące i umożliwiać logowanie za pomocą aplikacji portalu przechwytującego, gdy urządzenie jest połączone z dowolnym typem sieci, w tym z siecią komórkową, Wi-Fi, Ethernet lub Bluetooth.

• [C-1-3] MUSI obsługiwać logowanie się w portalach przechwytujących za pomocą DNS w postaci zwykłego tekstu, gdy urządzenie jest skonfigurowane do korzystania z prywatnego DNS w trybie ścisłym.

• [C-1-4] MUSI używać szyfrowanego DNS zgodnie z dokumentacją pakietu SDK dla android.net.LinkProperties.getPrivateDnsServerName i android.net.LinkProperties.isPrivateDnsActive w przypadku całego ruchu w sieci, który nie komunikuje się bezpośrednio z portalem uwierzytelniania.

• [C-1-5] MUSI zapewnić, że podczas logowania się użytkownika do portalu przechwytującego domyślna sieć używana przez aplikacje (zwracana przez ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback i domyślnie używana przez interfejsy API sieci Java, takie jak java.net.Socket, oraz interfejsy API natywne, takie jak connect()) jest inną dostępną siecią, która zapewnia dostęp do internetu, jeśli jest dostępna.

7.4.6. Ustawienia synchronizacji

Implementacje urządzeń:

• [C-0-1] MUSI mieć domyślnie włączone główne ustawienie automatycznej synchronizacji, aby metoda getMasterSyncAutomatically() zwracała wartość „true”.

7.4.7. Oszczędzanie danych

Jeśli implementacje urządzeń obejmują połączenie taryfowe, są to:

• [C-SR-1] Zdecydowanie zalecamy udostępnienie trybu oszczędzania danych.

Jeśli implementacje urządzeń udostępniają tryb oszczędzania danych:

• [C-1-1] MUSI obsługiwać wszystkie interfejsy API w klasie ConnectivityManager zgodnie z opisem w dokumentacji pakietu SDK.

Jeśli implementacje urządzeń nie udostępniają trybu oszczędzania danych:

• [C-2-1] MUSI zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED dla ConnectivityManager.getRestrictBackgroundStatus()

• [C-2-2] MUST NOT broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Zabezpieczenia

Jeśli implementacje urządzeń obsługują elementy bezpieczne zgodne z interfejsem Open Mobile API i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI wyliczać dostępne czytniki bezpiecznych elementów za pomocą interfejsu API android.se.omapi.SEService.getReaders().

• [C-1-2] MUSI deklarować prawidłowe flagi funkcji za pomocą android.hardware.se.omapi.uicc w przypadku urządzenia z elementami bezpiecznymi opartymi na karcie UICC, android.hardware.se.omapi.ese w przypadku urządzenia z elementami bezpiecznymi opartymi na eSE i android.hardware.se.omapi.sd w przypadku urządzenia z elementami bezpiecznymi opartymi na karcie SD.

7.4.9. UWB

Jeśli implementacje urządzeń obsługują standard 802.1.15.4 i udostępniają tę funkcję aplikacji innej firmy:

• [C-1-1] MUSI implementować odpowiedni interfejs API Androida w android.uwb.

• [C-1-2] MUSI zgłaszać flagę funkcji sprzętowej android.hardware.uwb.

• [C-1-3] MUSI obsługiwać wszystkie odpowiednie profile UWB zdefiniowane w implementacji Androida.

• [C-1-4] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania radia UWB.

• [C-1-5] MUSI egzekwować, aby aplikacje korzystające z radia UWB miały uprawnienie UWB_RANGING (w grupie uprawnień NEARBY_DEVICES).

• [C-SR-1] Zdecydowanie zaleca się, aby urządzenia te przechodziły odpowiednie testy zgodności i certyfikacji określone przez organizacje normalizacyjne, w tym FIRA, CCC i CSA.

• [C-1-6] MUSI zapewniać, że pomiary odległości w 95% przypadków w środowisku z bezpośrednią widocznością w odległości 1 m w komorze nieodbijającej światła mieszczą się w zakresie +/-15 cm.

• [C-1-7] MUSI zapewnić, że mediana pomiarów odległości w odległości 1 m od urządzenia referencyjnego mieści się w zakresie [0,75 m, 1,25 m], gdzie rzeczywista odległość jest mierzona od górnej krawędzi DUT.

• [C-SR-2] Zdecydowanie zaleca się wykonanie czynności związanych z konfiguracją pomiaru określonych w wymaganiach dotyczących kalibracji obecności.

7.5. Aparaty

Jeśli implementacje urządzeń obejmują co najmniej 1 aparat, to:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.camera.any.

• [C-1-2] Aplikacja MUSI mieć możliwość jednoczesnego przydzielenia 3 bitmap równych rozmiarowi obrazów generowanych przez czujnik aparatu o największej rozdzielczości na urządzeniu, gdy aparat jest otwarty w celu podstawowego podglądu i wykonywania zdjęć.RGBA_8888

• [C-1-3] MUSI zapewnić, że preinstalowana domyślna aplikacja aparatu obsługująca intencje MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE lub MediaStore.ACTION_VIDEO_CAPTURE jest odpowiedzialna za usuwanie lokalizacji użytkownika z metadanych obrazu przed wysłaniem go do aplikacji odbierającej, jeśli aplikacja odbierająca nie ma uprawnień ACCESS_FINE_LOCATION.

Jeśli urządzenia zawierają co najmniej 1 aparat, a wstępnie zainstalowana aplikacja aparatu obsługuje intencje MediaStore.ACTION_MOTION_PHOTO_CAPTURE lub MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, to:

• [C-1-4] MUSI zapewnić, że podczas obsługi tych intencji preinstalowana aplikacja aparatu usuwa lokalizację użytkownika z metadanych obrazu przed wysłaniem go do aplikacji odbierających, które nie mają ACCESS_FINE_LOCATION.

• [C-1-5] MUSI zapewnić, że zwrócone zdjęcie ruchome jest zgodne ze specyfikacją formatu zdjęcia ruchomego w wersji 1.0.

Jeśli implementacje urządzeń obsługują 10-bitowe dane wyjściowe HDR, to:

• [C-2-1] MUSI obsługiwać co najmniej profil HDR HLG w przypadku każdego urządzenia z kamerą, które obsługuje 10-bitowe wyjście.

• [C-2-2] MUSI obsługiwać 10-bitowe wyjście w przypadku głównego aparatu tylnego lub głównego aparatu przedniego.

• [C-SR-1] Zdecydowanie zaleca się obsługę 10-bitowego wyjścia w przypadku obu kamer głównych.

• [C-2-3] MUSI obsługiwać te same profile HDR dla wszystkich fizycznych podkamer logicznego aparatu obsługujących BACKWARD_COMPATIBLE oraz dla samego logicznego aparatu.

W przypadku urządzeń z aparatem logicznym, które obsługują 10-bitowy HDR i wdrażają interfejs API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO:

• [C-3-1] MUSI obsługiwać przełączanie między wszystkimi fizycznymi aparatami wstecznie zgodnymi za pomocą elementu sterującego CONTROL_ZOOM_RATIO na aparacie logicznym.

7.5.1. Tylny aparat

Tylny aparat to aparat skierowany na zewnątrz, który rejestruje sceny po drugiej stronie urządzenia, podobnie jak tradycyjny aparat. W przypadku urządzeń przenośnych jest to aparat znajdujący się po stronie urządzenia przeciwnej do wyświetlacza.

Implementacje urządzeń:

• POWINNO zawierać tylny aparat.

Jeśli urządzenie ma co najmniej 1 aparat skierowany do tyłu:

• [C-1-1] MUSI raportować flagę funkcji android.hardware.camera i android.hardware.camera.any.

• POWINIEN mieć zaimplementowany w sterowniku aparatu autofokus sprzętowy lub programowy (niewidoczny dla oprogramowania aplikacji).

• MOŻE mieć sprzęt z stałą ostrością lub EDOF (rozszerzoną głębią ostrości).

• MOŻE zawierać lampę błyskową.

Jeśli aparat ma lampę błyskową:

• [C-2-1] Lampa błyskowa NIE MOŻE być włączona, gdy na powierzchni podglądu aparatu zarejestrowano instancję, chyba że aplikacja wyraźnie włączyła lampę błyskową, włączając atrybuty FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters.android.hardware.Camera.PreviewCallback Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu systemowego na urządzeniu, ale tylko aplikacji innych firm korzystających z Camera.PreviewCallback.

7.5.2. Przedni aparat

Przedni aparat to aparat skierowany w stronę użytkownika, który jest zwykle używany do obrazowania użytkownika, np. podczas wideokonferencji i w podobnych aplikacjach. W przypadku urządzeń przenośnych jest to aparat znajdujący się po tej samej stronie urządzenia co wyświetlacz.

Implementacje urządzeń:

• MOŻE zawierać przedni aparat.

Jeśli urządzenie ma co najmniej 1 aparat przedni:

• [C-1-1] MUSI raportować flagę funkcji android.hardware.camera.any i android.hardware.camera.front.

• [C-1-2] MUSI mieć rozdzielczość co najmniej VGA (640 x 480 pikseli).

• [C-1-3] NIE MOŻE używać przedniego aparatu jako domyślnego w przypadku interfejsu Camera API i NIE MOŻE konfigurować interfejsu API tak, aby traktował przedni aparat jako domyślny tylny aparat, nawet jeśli jest to jedyny aparat na urządzeniu.

• [C-1-4] Podgląd z kamery MUSI być odwrócony w poziomie względem orientacji określonej przez aplikację, gdy bieżąca aplikacja wyraźnie zażądała obrócenia wyświetlacza kamery za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation(). Natomiast podgląd MUSI być odwrócony wzdłuż domyślnej osi poziomej urządzenia, jeśli bieżąca aplikacja nie zażąda wyraźnie obrócenia wyświetlacza aparatu przez wywołanie metody android.hardware.Camera.setDisplayOrientation().

• [C-1-5] NIE MOŻE odzwierciedlać końcowego zarejestrowanego obrazu nieruchomego ani strumieni wideo zwracanych do wywołań zwrotnych aplikacji lub zapisywanych w pamięci multimediów.

• [C-1-6] MUSI odzwierciedlać obraz wyświetlany przez podgląd w taki sam sposób jak strumień obrazu z podglądu z kamery.

• MOŻE zawierać funkcje (takie jak automatyczne ustawianie ostrości, lampa błyskowa itp.) dostępne w przypadku tylnych aparatów, zgodnie z opisem w sekcji 7.5.1.

Jeśli implementacje urządzenia mogą być obracane przez użytkownika (np. automatycznie za pomocą akcelerometru lub ręcznie za pomocą danych wejściowych użytkownika):

• [C-2-1] Podgląd z aparatu MUSI być odbity poziomo względem bieżącej orientacji urządzenia.

7.5.3. Aparat zewnętrzny

Kamera zewnętrzna to kamera, którą można w dowolnym momencie fizycznie podłączyć do urządzenia lub odłączyć od niego. Może być skierowana w dowolnym kierunku, np. kamery USB.

Implementacje urządzeń:

• MOŻE obejmować obsługę kamery zewnętrznej, która nie musi być zawsze podłączona.

Jeśli implementacje urządzeń obejmują obsługę kamery zewnętrznej:

• [C-1-1] MUSI zadeklarować flagę funkcji platformy android.hardware.camera.external i android.hardware camera.any.

• [C-1-2] MUSI obsługiwać klasę wideo USB (UVC 1.0 lub nowszą), jeśli zewnętrzna kamera łączy się przez port hosta USB.

• [C-1-3] MUSI przejść testy CTS kamery z podłączonym fizycznym urządzeniem zewnętrznym. Szczegóły testowania kamery w ramach CTS znajdziesz na stronie source.android.com.

• POWINNO obsługiwać kompresję wideo, np.MJPEG, aby umożliwić przesyłanie strumieni niekodowanych w wysokiej jakości (tj. strumieni obrazów surowych lub kompresowanych niezależnie).

• MOŻE obsługiwać wiele kamer.

• MOŻE obsługiwać kodowanie wideo oparte na kamerze.

Jeśli kodowanie wideo oparte na kamerze jest obsługiwane:

• [C-2-1] Urządzenie MUSI mieć dostęp do jednoczesnego strumienia nieskompresowanego lub MJPEG (rozdzielczość QVGA lub wyższa).

7.5.4. Działanie interfejsu Camera API

Android zawiera 2 pakiety interfejsu API do uzyskiwania dostępu do aparatu. Nowszy interfejs API android.hardware.camera2 udostępnia aplikacji kontrolę nad aparatem na niższym poziomie, w tym wydajne przepływy strumieniowe i seryjne bez kopiowania oraz sterowanie ekspozycją, wzmocnieniem, wzmocnieniem balansu bieli, konwersją kolorów, odszumianiem, wyostrzaniem i innymi parametrami w przypadku każdej klatki.

Starszy pakiet interfejsu API, android.hardware.Camera, jest oznaczony jako wycofany w Androidzie 5.0, ale powinien być nadal dostępny dla aplikacji. Implementacje na urządzeniach z Androidem MUSZĄ zapewniać dalszą obsługę interfejsu API zgodnie z opisem w tej sekcji i w pakiecie Android SDK.

Wszystkie funkcje wspólne dla wycofanej klasy android.hardware.Camera i nowszego pakietu android.hardware.camera2 MUSZĄ mieć w obu interfejsach API równoważną wydajność i jakość. Na przykład przy równoważnych ustawieniach szybkość i dokładność autofokusa muszą być identyczne, a jakość zarejestrowanych obrazów musi być taka sama. Funkcje, które zależą od różnej semantyki obu interfejsów API, nie muszą mieć takiej samej szybkości ani jakości, ale POWINNY być jak najbardziej zbliżone.

Urządzenia MUSZĄ implementować te zachowania w przypadku interfejsów API związanych z aparatem, dla wszystkich dostępnych aparatów. Implementacje urządzeń:

• [C-0-1] MUSI używać android.hardware.PixelFormat.YCbCr_420_SP w przypadku danych podglądu przekazywanych do wywołań zwrotnych aplikacji, gdy aplikacja nigdy nie wywołała android.hardware.Camera.Parameters.setPreviewFormat(int).

• [C-0-2] MUSI być w formacie kodowania NV21, gdy aplikacja rejestruje instancję android.hardware.Camera.PreviewCallback, a system wywołuje metodę onPreviewFrame(), a format podglądu to YCbCr_420_SP, dane w tablicy bajtów przekazywanej do onPreviewFrame(). Oznacza to, że format NV21 MUSI być domyślny.

• [C-0-3] MUSI obsługiwać format YV12 (oznaczony stałą android.graphics.ImageFormat.YV12) w przypadku podglądu z kamery przedniej i tylnej na urządzeniach android.hardware.Camera. (Koder wideo i aparat mogą używać dowolnego natywnego formatu pikseli, ale implementacja urządzenia MUSI obsługiwać konwersję do formatu YV12).

• [C-0-4] MUSI obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe za pomocą interfejsu API android.media.ImageReader na urządzeniach android.hardware.camera2, które reklamują funkcję REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE w android.request.availableCapabilities.

• [C-0-5] MUSI implementować pełny interfejs Camera API zawarty w dokumentacji pakietu Android SDK, niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład kamery, które nie mają autofokusa, MUSZĄ nadal wywoływać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback (nawet jeśli nie ma to związku z kamerą bez autofokusa). Pamiętaj, że dotyczy to przednich aparatów. Na przykład, mimo że większość przednich aparatów nie obsługuje autofokusa, wywołania zwrotne interfejsu API muszą być „symulowane” w opisany sposób.

• [C-0-6] MUSI rozpoznawać i uwzględniać każdą nazwę parametru zdefiniowaną jako stała w klasach android.hardware.Camera.Parameters i android.hardware.camera2.CaptureRequest. Z kolei implementacje urządzeń NIE MOGĄ honorować ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters() innych niż te, które są udokumentowane jako stałe w android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry aparatu, jeśli pozwala na to sprzęt, i NIE MOGĄ obsługiwać niestandardowych typów parametrów aparatu. Na przykład urządzenia obsługujące robienie zdjęć z wykorzystaniem technik obrazowania o szerokim zakresie dynamicznym (HDR) MUSZĄ obsługiwać parametr aparatu Camera.SCENE_MODE_HDR.

• [C-0-7] MUSI zgłaszać odpowiedni poziom obsługi za pomocą właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i zgłaszać odpowiednie flagi funkcji platformy.

• [C-0-8] MUSI też zadeklarować indywidualne możliwości kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i odpowiednich flag funkcji; MUSI zdefiniować flagę funkcji, jeśli którekolwiek z dołączonych urządzeń z kamerą obsługuje tę funkcję.

• [C-0-9] MUSI transmitować Camera.ACTION_NEW_PICTURE zamiar za każdym razem, gdy aparat zrobi nowe zdjęcie, a wpis dotyczący tego zdjęcia zostanie dodany do magazynu multimediów.

• [C-0-10] MUSI wysyłać intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy kamera nagra nowy film, a wpis dotyczący zdjęcia zostanie dodany do magazynu multimediów.

• [C-0-11] WSZYSTKIE kamery, do których można uzyskać dostęp za pomocą wycofanego interfejsu API android.hardware.Camera, MUSZĄ być też dostępne za pomocą interfejsu API android.hardware.camera2.

• [C-0-12] MUSI zapewnić, że wygląd twarzy NIE zostanie zmieniony, w tym m.in. geometria twarzy, odcień skóry twarzy lub wygładzenie skóry twarzy w przypadku interfejsu API android.hardware.camera2 lub android.hardware.Camera.

• [C-SR-1] W przypadku urządzeń z kilkoma kamerami RGB znajdującymi się blisko siebie i skierowanymi w tym samym kierunku ZDECYDOWANIE ZALECA SIĘ obsługę logicznego urządzenia z kamerą, które ma funkcję CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA i składa się ze wszystkich kamer RGB skierowanych w tym kierunku jako fizycznych urządzeń podrzędnych.

Jeśli implementacje urządzeń udostępniają zastrzeżony interfejs API aparatu aplikacjom innych firm:

• [C-1-1] MUSI implementować interfejs API aparatu za pomocą interfejsu android.hardware.camera2.

• MOŻE przekazywać tagi dostawcy lub rozszerzenia do interfejsu API.android.hardware.camera2

7.5.5. Orientacja aparatu

Jeśli urządzenie ma aparat przedni lub tylny, to:

• [C-1-1] MUSI być zorientowany tak, aby dłuższy bok kamery był równoległy do dłuższego boku ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, kamery MUSZĄ rejestrować obrazy w orientacji poziomej. Dotyczy to wszystkich urządzeń, niezależnie od ich naturalnej orientacji, czyli zarówno urządzeń z orientacją poziomą, jak i pionową.

  Wymaganie to nie dotyczy urządzeń, które spełniają dowolne z tych kryteriów:

  • Urządzenie ma ekrany o zmiennej geometrii, np. składane lub zawiasowe, ORAZ gdy zmienia się stan złożenia lub zawiasu urządzenia, przełącza się ono między orientacją pionową a poziomą (lub odwrotnie).

  • Implementacje urządzeń, których użytkownik nie może obracać, np. urządzenia samochodowe.

7.6. Pamięć i miejsce na dane

7.6.1. Minimalna ilość pamięci i miejsca na dane

Implementacje urządzeń:

• [C-0-1] MUSI zawierać menedżera pobierania, z którego aplikacje MOGĄ korzystać do pobierania plików danych, i MUSI umożliwiać pobieranie pojedynczych plików o rozmiarze co najmniej 100 MB do domyślnej lokalizacji „pamięci podręcznej”.

7.6.2. Pamięć współdzielona aplikacji

Implementacje urządzeń:

• [C-0-1] MUSI oferować miejsce na dane, które może być udostępniane aplikacjom. Jest ono często nazywane „udostępnionym miejscem zewnętrznym”, „miejscem na dane udostępnianym aplikacjom” lub ścieżką w systemie Linux „/sdcard”, pod którą jest montowane.
• [C-0-2] MUSI być skonfigurowane z zamontowaną domyślnie pamięcią współdzieloną, czyli „od razu po wyjęciu z pudełka”, niezależnie od tego, czy pamięć jest zaimplementowana w komponencie pamięci wewnętrznej, czy na wymiennym nośniku danych (np. gnieździe karty Secure Digital).
• [C-0-3] MUSI zamontować pamięć współdzieloną aplikacji bezpośrednio na ścieżce systemu Linuxsdcard lub zawierać symboliczny link systemu Linux z sdcard do rzeczywistego punktu montowania.
• [C-0-4] MUSI domyślnie włączać ograniczony dostęp do miejsca na dane w przypadku wszystkich aplikacji kierowanych na docelowy poziom interfejsu API 29 lub wyższy, z wyjątkiem tej sytuacji:
  • Gdy aplikacja zażąda android:requestLegacyExternalStorage="true" w pliku manifestu.
• [C-0-5] MUSI usuwać metadane lokalizacji, takie jak tagi EXIF GPS, przechowywane w plikach multimedialnych, gdy dostęp do tych plików jest uzyskiwany za pomocą interfejsu MediaStore, z wyjątkiem sytuacji, gdy aplikacja wywołująca ma uprawnienie ACCESS_MEDIA_LOCATION.

Urządzenia MOGĄ spełniać powyższe wymagania, korzystając z jednego z tych rozwiązań:

• Wymienna pamięć dostępna dla użytkownika, np. gniazdo karty SD.
• Część pamięci wewnętrznej (niewymiennej) w ramach Projektu Android Open Source (AOSP).

Jeśli implementacje urządzeń korzystają z pamięci wymiennej, aby spełnić powyższe wymagania:

• [C-1-1] MUSI implementować interfejs użytkownika w postaci wyskakującego okienka lub powiadomienia, które ostrzega użytkownika, gdy w gnieździe nie ma nośnika danych.
• [C-1-2] MUSI zawierać nośnik pamięci sformatowany w systemie FAT (np. kartę SD) lub zawierać informację na opakowaniu i w innych materiałach dostępnych w momencie zakupu, że nośnik pamięci należy kupić osobno.

Jeśli implementacje urządzeń wykorzystują część pamięci trwałej do spełnienia powyższych wymagań:

• POWINIEN korzystać z implementacji AOSP wewnętrznego udostępnionego miejsca na dane aplikacji.
• MOŻE udostępniać miejsce na dane prywatnym danym aplikacji.

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB:

• [C-3-1] MUSI udostępniać mechanizm dostępu do danych w pamięci współdzielonej aplikacji z komputera hosta.
• POWINNY udostępniać treści z obu ścieżek pamięci w sposób przejrzysty za pomocą usługi skanera multimediów Androida i android.provider.MediaStore.
• MOŻE korzystać z pamięci masowej USB, ale POWINIEN używać protokołu przesyłania multimediów, aby spełnić to wymaganie.

Jeśli urządzenie ma port USB z trybem urządzenia peryferyjnego USB i obsługuje protokół przesyłania multimediów, to:

• POWINIEN być zgodny z referencyjnym hostem MTP Androida, czyli aplikacją Android File Transfer.
• POWINIEN zgłaszać klasę urządzenia USB 0x00.
• POWINIEN zgłaszać nazwę interfejsu USB „MTP”.

7.6.3. Pamięć dostosowywana

Jeśli urządzenie ma być mobilne, a nie telewizorem, implementacje urządzenia to:

• [C-SR-1] Zdecydowanie zalecamy wdrożenie pamięci dostosowywanej w stabilnej lokalizacji długoterminowej, ponieważ przypadkowe odłączenie może spowodować utratę danych lub ich uszkodzenie.

Jeśli port urządzenia pamięci wymiennej znajduje się w stabilnym miejscu, np. w komorze baterii lub pod inną osłoną ochronną, urządzenie:

• [C-SR-2] Zdecydowanie zaleca się wdrożenie pamięci dostosowywanej.

7.7. USB

Jeśli urządzenie ma port USB:

• POWINNO obsługiwać tryb urządzenia USB.

• POWINNO obsługiwać tryb hosta USB.

• POWINNO obsługiwać wyłączanie sygnału danych przez USB.

7.7.1. Tryb urządzenia USB

Jeśli urządzenia mają port USB i implementują specyfikację AOA:

• [C-2-1] MUSI deklarować obsługę funkcji sprzętowej android.hardware.usb.accessory.
• [C-2-2] Klasa pamięci masowej USB MUSI zawierać ciąg znaków „android” na końcu ciągu znaków iInterface opisu interfejsu pamięci masowej USB.

7.7.2. Tryb hosta USB

Jeśli urządzenia mają port USB obsługujący tryb hosta:

• [C-1-1] MUSI implementować interfejs Android USB host API zgodnie z dokumentacją w pakiecie Android SDK i MUSI deklarować obsługę funkcji sprzętowej android.hardware.usb.host.
• [C-1-2] MUSI obsługiwać podłączanie standardowych urządzeń peryferyjnych USB. Musi mieć jedną z tych opcji:
  • Urządzenie musi mieć port USB typu C lub być dostarczane z kablami, które umożliwiają podłączenie portu zastrzeżonego na urządzeniu do standardowego portu USB typu C (urządzenie USB typu C).
  • Port USB typu A na urządzeniu lub kabel(-e) umożliwiający(-e) podłączenie portu zastrzeżonego na urządzeniu do standardowego portu USB typu A.
  • Port micro-AB USB na urządzeniu, który POWINIEN być dostarczany z kablem przejściowym na standardowy port USB typu A.
• [C-1-3] NIE MOŻE być dostarczany z adapterem konwertującym porty USB typu A lub micro-AB na port USB typu C (gniazdo).
• [C-SR-1] Zdecydowanie zaleca się wdrożenie klasy audio USB zgodnie z dokumentacją pakietu Android SDK.
• POWINNO obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta; reklamować prąd źródłowy o wartości co najmniej 1, 5 A zgodnie z sekcją Parametry zakończenia w specyfikacji kabli i złączy USB typu C w wersji 1.2 w przypadku złączy USB typu C lub korzystać z zakresu prądu wyjściowego portu ładowania (CDP) zgodnie ze specyfikacjami ładowania baterii przez USB w wersji 1.2 w przypadku złączy Micro-AB.
• POWINNY wdrażać i obsługiwać standardy USB typu C.

Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i klasę audio USB:

• [C-2-1] MUSI obsługiwać klasę USB HID.
• [C-2-2] MUSI obsługiwać wykrywanie i mapowanie tych pól danych HID określonych w tabelach użycia HID USB i żądaniu użycia polecenia głosowego na stałe wartości KeyEvent w sposób podany poniżej:
  • Strona użycia (0xC), identyfikator użycia (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Strona użycia (0xC), identyfikator użycia (0x0E9): KEYCODE_VOLUME_UP
  • Strona użycia (0xC), identyfikator użycia (0x0EA): KEYCODE_VOLUME_DOWN
  • Strona użycia (0xC), identyfikator użycia (0x0CF): KEYCODE_VOICE_ASSIST

Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i platformę Storage Access Framework (SAF):

• [C-3-1] MUSI rozpoznawać wszystkie urządzenia MTP (Media Transfer Protocol) połączone zdalnie i udostępniać ich zawartość za pomocą intencji ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT.

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i USB typu C:

• [C-4-1] MUSI obsługiwać funkcję zasilania dwukierunkowego (DRP) zgodnie ze specyfikacją USB Type-C (sekcja 4.5.1.3.3). W przypadku portów DRP na urządzeniach z gniazdem audio 3,5 mm wykrywanie odbiornika zasilania USB (tryb hosta) MOŻE być domyślnie wyłączone, ale użytkownik MUSI mieć możliwość jego włączenia.
• [C-SR-2] ZDECYDOWANIE ZALECA SIĘ obsługę DisplayPort.
  • POWINIEN obsługiwać szybkość transmisji danych SuperSpeed USB.
  • ZDECYDOWANIE ZALECANE do obsługi Power Delivery w przypadku zamiany ról danych i zasilania.
• [C-SR-3] ZDECYDOWANIE ZALECA SIĘ, aby nie obsługiwać trybu akcesorium przejściówki audio, zgodnie z opisem w dodatku A do specyfikacji kabla i wtyczki USB typu C w wersji 1.2.
• POWINIEN wdrażać model Try.*, który jest najbardziej odpowiedni dla formy urządzenia. Na przykład urządzenie przenośne POWINNO implementować model Try.SNK.

7.7.3. USB Power Delivery

7.8. Audio

7.8.1. Mikrofon

Jeśli urządzenie ma mikrofon:

• [C-1-1] MUSI zgłaszać stałą funkcji android.hardware.microphone.
• [C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku określone w sekcji 5.4.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku określone w sekcji 5.6.
• [C-SR-1] Zdecydowanie zaleca się obsługę nagrywania w zakresie bliskim ultradźwiękom zgodnie z opisem w sekcji 7.8.3.

Jeśli urządzenie nie ma mikrofonu:

• [C-2-1] NIE MOŻE zgłaszać stałej funkcji android.hardware.microphone.
• [C-2-2] MUSI zaimplementować interfejs API nagrywania dźwięku co najmniej jako operację bez efektu, zgodnie z sekcją 7.

7.8.2. Wyjście audio

Jeśli implementacje urządzeń obejmują głośnik lub port wyjścia audio/multimediów dla urządzenia peryferyjnego wyjścia audio, takiego jak 4-żyłowe gniazdo słuchawek 3,5 mm lub port trybu hosta USB korzystający z klasy audio USB, to:

• [C-1-1] MUSI zgłaszać stałą funkcji android.hardware.audio.output.
• [C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku określone w sekcji 5.5.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku określone w sekcji 5.6.
• [C-SR-1] ZDECYDOWANIE ZALECANE jest obsługiwanie odtwarzania w zakresie bliskim ultradźwiękom zgodnie z opisem w sekcji 7.8.3.

Jeśli urządzenie nie ma głośnika ani portu wyjścia audio:

• [C-2-1] NIE MOŻE zgłaszać funkcji android.hardware.audio.output.
• [C-2-2] MUSI implementować interfejsy API związane z wyjściem audio co najmniej jako operacje bez efektu.

Na potrzeby tej sekcji „port wyjściowy” to fizyczny interfejs, taki jak gniazdo audio 3, 5 mm, HDMI lub port hosta USB z klasą audio USB. Obsługa wyjścia audio za pomocą protokołów radiowych, takich jak Bluetooth, Wi-Fi lub sieć komórkowa, nie jest uznawana za „port wyjściowy”.

7.8.2.1. Analogowe porty audio

Aby zapewnić zgodność z zestawami słuchawkowymi i innymi akcesoriami audio korzystającymi z wtyczki audio 3,5 mm w ekosystemie Androida, jeśli implementacje urządzeń obejmują co najmniej 1 analogowy port audio, muszą:

• [C-SR-1] Zdecydowanie zaleca się, aby co najmniej jedno gniazdo audio było 4-żyłowym gniazdem słuchawkowym 3,5 mm.

Jeśli urządzenia mają 4-żyłowe gniazdo audio 3, 5 mm:

• [C-1-1] MUSI obsługiwać odtwarzanie dźwięku na słuchawkach stereo i zestawach słuchawkowych stereo z mikrofonem.
• [C-1-2] MUSI obsługiwać wtyczki audio TRRS z układem pinów CTIA.
• [C-1-3] MUSI obsługiwać wykrywanie i mapowanie na kody klawiszy w przypadku 3 zakresów równoważnej impedancji między mikrofonem a przewodnikami uziemiającymi na wtyczce audio:
  • 70 omów lub mniej: KEYCODE_HEADSETHOOK
  • 210–290 omów: KEYCODE_VOLUME_UP
  • 360–680 omów: KEYCODE_VOLUME_DOWN
• [C-1-4] MUSI wywoływać ACTION_HEADSET_PLUG po włożeniu wtyczki, ale tylko wtedy, gdy wszystkie styki wtyczki dotykają odpowiednich segmentów gniazda.
• [C-1-5] MUSI być w stanie zapewnić co najmniej 150 mV ± 10% napięcia wyjściowego przy impedancji głośnika 32 omy.
• [C-1-6] MUSI mieć napięcie polaryzacji mikrofonu w zakresie 1,8–2,9 V.
• [C-1-7] MUSI wykrywać i mapować na kod klucza następujący zakres równoważnej impedancji między mikrofonem a przewodami uziemiającymi na wtyczce audio:
  • 110–180 omów: KEYCODE_VOICE_ASSIST
• [C-SR-2] ZDECYDOWANIE ZALECA SIĘ obsługę wtyczek audio z układem pinów OMTP.
• [C-SR-3] Zdecydowanie zaleca się obsługę nagrywania dźwięku ze słuchawek stereo z mikrofonem.

Jeśli urządzenia mają 4-żyłowe gniazdo audio 3,5 mm i obsługują mikrofon, a także przesyłają wartość android.intent.action.HEADSET_PLUG z dodatkową wartością mikrofonu ustawioną na 1, to:

• [C-2-1] MUSI obsługiwać wykrywanie mikrofonu w podłączonym akcesorium audio.

7.8.2.2. Cyfrowe porty audio

Wymagania dotyczące konkretnych urządzeń znajdziesz w sekcji 2.2.1.

7.8.3. Dźwięki zbliżone do ultradźwięków

Dźwięk w zakresie bliskim ultradźwiękom to pasmo od 18,5 kHz do 20 kHz.

Implementacje urządzeń:

• MUSI prawidłowo zgłaszać obsługę dźwięku w zakresie bliskim ultradźwiękom za pomocą interfejsu AudioManager.getProperty API w ten sposób:

Jeśli wartość PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND to „true”, źródła dźwięku VOICE_RECOGNITION i UNPROCESSED MUSZĄ spełniać te wymagania:

• [C-1-1] Średnia charakterystyka mocy mikrofonu w zakresie od 18,5 kHz do 20 kHz MUSI być nie więcej niż o 15 dB niższa niż charakterystyka przy 2 kHz.
• [C-1-2] Nieważony stosunek sygnału do szumu mikrofonu w zakresie częstotliwości od 18,5 kHz do 20 kHz w przypadku tonu o częstotliwości 19 kHz przy poziomie -26 dBFS MUSI wynosić co najmniej 50 dB.

Jeśli PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „true”:

• [C-2-1] Średnia odpowiedź głośnika w zakresie 18,5–20 kHz MUSI być nie niższa niż 40 dB poniżej odpowiedzi przy 2 kHz.

7.8.4. Integralność sygnału

Implementacje urządzeń:

• POWINNY zapewniać ścieżkę sygnału audio bez zakłóceń zarówno w przypadku strumieni wejściowych, jak i wyjściowych na urządzeniach przenośnych, zgodnie z definicją braku zakłóceń zmierzonych podczas testu trwającego minutę na ścieżkę. Przeprowadź test za pomocą narzędzia OboeTester „Automated Glitch Test”.

Test wymaga użycia klucza sprzętowego do pętli audio, który jest podłączany bezpośrednio do gniazda 3,5 mm lub w połączeniu z przejściówką z USB-C na 3,5 mm. Należy przetestować wszystkie porty wyjścia audio.

OboeTester obsługuje obecnie ścieżki AAudio, więc w przypadku tych kombinacji NALEŻY przeprowadzić testy pod kątem usterek przy użyciu AAudio:

Tryb wydajności	Udostępnianie	Częstotliwość próbkowania danych wyjściowych	In Chans	Out Chans
LOW_LATENCY	ZAPROSZENIA NA	BRAK DANYCH	1	2
LOW_LATENCY	ZAPROSZENIA NA	BRAK DANYCH	2	1
LOW_LATENCY	UDOSTĘPNIONY	BRAK DANYCH	1	2
LOW_LATENCY	UDOSTĘPNIONY	BRAK DANYCH	2	1
BRAK	UDOSTĘPNIONY	48000	1	2
BRAK	UDOSTĘPNIONY	48000	2	1
BRAK	UDOSTĘPNIONY	44100	1	2
BRAK	UDOSTĘPNIONY	44100	2	1
BRAK	UDOSTĘPNIONY	16000	1	2
BRAK	UDOSTĘPNIONY	16000	2	1

Niezawodny strumień POWINIEN spełniać te kryteria dotyczące stosunku sygnału do szumu (SNR) i całkowitych zniekształceń harmonicznych (THD) dla sinusa o częstotliwości 2000 Hz.

Przetwornik	THD	SNR
główny głośnik wbudowany, mierzony za pomocą zewnętrznego mikrofonu referencyjnego;	< 3,0%	>= 50 dB
główny wbudowany mikrofon, mierzony za pomocą zewnętrznego głośnika referencyjnego;	< 3,0%	>= 50 dB
wbudowane analogowe gniazda 3,5 mm, testowane za pomocą adaptera pętli zwrotnej;	<1%	>= 60 dB
Adaptery USB dostarczone z telefonem, testowane za pomocą adaptera pętli zwrotnej	< 1,0%	>= 60 dB

7.9. Rzeczywistość wirtualna

Android zawiera interfejsy API i narzędzia do tworzenia aplikacji w technologii wirtualnej rzeczywistości (VR), w tym wysokiej jakości mobilnych aplikacji VR. Implementacje urządzeń MUSZĄ prawidłowo implementować te interfejsy API i zachowania, zgodnie z opisem w tej sekcji.

7.9.1. Tryb rzeczywistości wirtualnej

Android obsługuje tryb VR, który odpowiada za stereoskopowe renderowanie powiadomień i wyłącza monokularne komponenty interfejsu systemu, gdy użytkownik korzysta z aplikacji VR.

7.9.2. Tryb wirtualnej rzeczywistości – wysoka wydajność

Jeśli urządzenia obsługują tryb VR:

• [C-1-1] MUSI mieć co najmniej 2 rdzenie fizyczne.
• [C-1-2] MUSI zadeklarować funkcję android.hardware.vr.high_performance.
• [C-1-3] MUSI obsługiwać tryb wydajności.
• [C-1-4] MUSI obsługiwać OpenGL ES 3.2.
• [C-1-5] MUSI obsługiwać android.hardware.vulkan.level 0.
• POWINIEN obsługiwać android.hardware.vulkan.level w wersji 1 lub nowszej.
• [C-1-6] MUSI implementować EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace, i udostępniać rozszerzenia na liście dostępnych rozszerzeń EGL.
• [C-1-8] MUSI implementować GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, i udostępniać rozszerzenia na liście dostępnych rozszerzeń GL.
• [C-SR-1] Zdecydowanie zalecamy wdrożenie rozszerzeń GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture i udostępnienie ich na liście dostępnych rozszerzeń GL.
• [C-SR-2] Zdecydowanie zaleca się obsługę Vulkan 1.1.
• [C-SR-3] Zdecydowanie zaleca się wdrożenie rozszerzeńVK_ANDROID_external_memory_android_hardware_buffer,VK_GOOGLE_display_timing,VK_KHR_shared_presentable_image i udostępnienie ich na liście dostępnych rozszerzeń Vulkan.
• [C-SR-4] Zdecydowanie zaleca się udostępnianie co najmniej 1 rodziny kolejek Vulkan, w której flags zawiera zarówno VK_QUEUE_GRAPHICS_BIT, jak i VK_QUEUE_COMPUTE_BIT, a queueCount wynosi co najmniej 2.
• [C-1-7] Procesor graficzny i wyświetlacz MUSZĄ być w stanie zsynchronizować dostęp do wspólnego bufora przedniego, tak aby renderowanie treści VR z częstotliwością 60 klatek na sekundę w trybie naprzemiennym dla każdego oka przy użyciu 2 kontekstów renderowania było wyświetlane bez widocznych artefaktów rozrywania obrazu.
• [C-1-9] MUSI obsługiwać flagi AHardwareBuffer, AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT zgodnie z opisem w NDK.
• [C-1-10] MUSI obsługiwać AHardwareBufferz dowolną kombinacją flag użyciaAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT w przypadku co najmniej tych formatów: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] Zdecydowanie zaleca się obsługę przydzielania AHardwareBuffers z więcej niż jedną warstwą oraz flag i formatów określonych w C-1-10.
• [C-1-11] MUSI obsługiwać dekodowanie H.264 w rozdzielczości co najmniej 3840 x 2160 przy 30 kl./s, skompresowane do średniej wartości 40 Mb/s (co odpowiada 4 instancjom 1920 x 1080 przy 30 kl./s i 10 Mb/s lub 2 instancjom 1920 x 1080 przy 60 kl./s i 20 Mb/s).
• [C-1-12] MUSI obsługiwać HEVC i VP9, MUSI być w stanie dekodować co najmniej 1920 x 1080 przy 30 kl./s skompresowane do średniej wartości 10 Mb/s i POWINIEN być w stanie dekodować 3840 x 2160 przy 30 kl./s i 20 Mb/s (co odpowiada 4 instancjom 1920 x 1080 przy 30 kl./s i 5 Mb/s).
• [C-1-13] MUSI obsługiwać interfejs HardwarePropertiesManager.getDeviceTemperatures API i zwracać dokładne wartości temperatury skóry.
• [C-1-14] MUSI mieć wbudowany ekran, a jego rozdzielczość MUSI wynosić co najmniej 1920 x 1080.
• [C-SR-6] Zdecydowanie zaleca się, aby rozdzielczość wyświetlacza wynosiła co najmniej 2560 x 1440.
• [C-1-15] W trybie VR wyświetlacz MUSI odświeżać obraz z częstotliwością co najmniej 60 Hz.
• [C-1-17] Wyświetlacz MUSI obsługiwać tryb niskiej trwałości z trwałością ≤ 5 milisekund. Trwałość to czas, przez który piksel emituje światło.
• [C-1-18] MUSI obsługiwać Bluetooth 4.2 i rozszerzenie długości danych Bluetooth LE (sekcja 7.4.3).
• [C-1-19] MUSI obsługiwać i prawidłowo raportować typ kanału bezpośredniego w przypadku wszystkich tych domyślnych typów czujników:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] Zdecydowanie zaleca się obsługę typu kanału bezpośredniego TYPE_HARDWARE_BUFFER dla wszystkich typów kanałów bezpośrednich wymienionych powyżej.
• [C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru dla android.hardware.hifi_sensors, zgodnie z sekcją 7.3.9.
• [C-SR-8] ZDECYDOWANIE ZALECA SIĘ obsługę funkcji android.hardware.sensor.hifi_sensors.
• [C-1-22] MUSI mieć opóźnienie od ruchu do fotonu nie większe niż 28 milisekund.
• [C-SR-9] Zdecydowanie zaleca się, aby opóźnienie od ruchu do fotonu nie przekraczało 20 milisekund.
• [C-1-23] MUSI mieć współczynnik pierwszej klatki, czyli stosunek jasności pikseli w pierwszej klatce po przejściu z czerni do bieli do jasności białych pikseli w stanie ustalonym, wynoszący co najmniej 85%.
• [C-SR-10] ZDECYDOWANIE ZALECA SIĘ, aby współczynnik pierwszej klatki wynosił co najmniej 90%.
• MOŻE udostępniać wyłączny rdzeń aplikacji działającej na pierwszym planie i MOŻE obsługiwać interfejs Process.getExclusiveCores API, aby zwracać liczbę rdzeni procesora, które są wyłączne dla aplikacji działającej na pierwszym planie.

Jeśli dedykowany rdzeń jest obsługiwany, to:

• [C-2-1] NIE MOŻE zezwalać na uruchamianie na nim żadnych innych procesów przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.

7.10. Reakcja na dotyk

Urządzenia przeznaczone do trzymania w ręku lub noszenia mogą zawierać siłownik haptyczny ogólnego przeznaczenia, który jest dostępny dla aplikacji do różnych celów, w tym do zwracania uwagi za pomocą dzwonków, alarmów i powiadomień, a także do ogólnych informacji zwrotnych dotyczących dotyku.

Jeśli implementacje urządzeń NIE zawierają takiego siłownika haptycznego ogólnego przeznaczenia:

• [7.10/C] MUSI zwracać wartość false dla Vibrator.hasVibrator().

Jeśli implementacje urządzeń ZAWIERAJĄ co najmniej 1 taki siłownik haptyczny ogólnego przeznaczenia:

• [C-1-1] MUSI zwracać wartość „true” w przypadku Vibrator.hasVibrator().
• NIE POWINNO używać siłownika haptycznego z niewyważonym wirnikiem (wibratora).
• POWINIEN implementować wszystkie stałe publiczne dla wyraźnych haptycznych 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, REJECT, GESTURE_START i GESTURE_END).
• POWINIEN implementować wszystkie stałe publiczne dla wyraźnych haptycznych w android.os.VibrationEffect, a mianowicie (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK i EFFECT_DOUBLE_CLICK) oraz wszystkie możliwe stałe publiczne PRIMITIVE_* dla bogatych haptycznych w android.os.VibrationEffect.Composition, a mianowicie (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Niektóre z tych elementów pierwotnych, takie jak LOW_TICK i SPIN, mogą być możliwe tylko wtedy, gdy wibrator obsługuje stosunkowo niskie częstotliwości.
• POWINIEN postępować zgodnie ze wskazówkami dotyczącymi mapowania stałych publicznych w android.view.HapticFeedbackConstants na zalecane stałe android.os.VibrationEffect z odpowiednimi relacjami amplitud.
• POWINNY używać tych połączonych mapowań stałych wartości haptycznych.
• POWINNY być zgodne z oceną jakości interfejsów API createOneShot() i createWaveform().
• POWINIEN sprawdzić, czy wynik publicznego interfejsu android.os.Vibrator.hasAmplitudeControl() API prawidłowo odzwierciedla możliwości wibratora.
• POWINIEN weryfikować możliwości skalowania amplitudy, uruchamiając android.os.Vibrator.hasAmplitudeControl().

Jeśli implementacje urządzeń są zgodne z mapowaniem stałych haptycznych, to:

• POWINIEN sprawdzić stan implementacji, uruchamiając interfejsy API android.os.Vibrator.areAllEffectsSupported() i android.os.Vibrator.arePrimitivesSupported().
• POWINIEN przeprowadzić ocenę jakości stałych haptycznych.
• POWINIEN weryfikować i w razie potrzeby aktualizować konfigurację rezerwową dla nieobsługiwanych typów prostych zgodnie z wskazówkami dotyczącymi implementacji stałych.
• POWINIEN zapewniać obsługę rezerwową, aby zmniejszyć ryzyko niepowodzenia, jak opisano tutaj.

7.11. Klasa skuteczności mediów

Klasę wydajności multimediów implementacji urządzenia można uzyskać z interfejsu android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API. Wymagania dotyczące klasy wydajności multimediów są zdefiniowane dla każdej wersji Androida począwszy od wersji R (30). Wartość specjalna 0 oznacza, że urządzenie nie należy do klasy wydajności multimediów.

Jeśli implementacje urządzenia zwracają wartość inną niż zero w przypadku parametru android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• [C-1-1] MUSI zwracać co najmniej wartość android.os.Build.VERSION_CODES.R.

• [C-1-2] MUSI być implementacją na urządzeniu przenośnym.

• [C-1-3] MUSI spełniać wszystkie wymagania dotyczące „klasy wydajności multimediów” opisane w sekcji 2.2.7.

Innymi słowy, klasa wydajności multimediów w Androidzie T jest zdefiniowana tylko dla urządzeń przenośnych w wersji T, S lub R.

Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.2.7.

8. Wydajność i moc

Niektóre minimalne kryteria wydajności i mocy mają kluczowe znaczenie dla wrażeń użytkowników i wpływają na podstawowe założenia, jakie deweloperzy przyjmują podczas tworzenia aplikacji.

8.1. Spójność interfejsu użytkownika

Płynny interfejs użytkownika można zapewnić użytkownikowi końcowemu, jeśli spełnione są określone minimalne wymagania, które zapewniają stałą liczbę klatek na sekundę i czas reakcji aplikacji i gier. Wdrożenia urządzeń, w zależności od ich typu, MOGĄ mieć mierzalne wymagania dotyczące opóźnienia interfejsu użytkownika i przełączania zadań, jak opisano w sekcji 2.

8.2. Wydajność dostępu do plików wejścia/wyjścia

Zapewnienie wspólnego punktu odniesienia dla spójnej wydajności dostępu do plików w prywatnym obszarze pamięci aplikacji (partycja /data) umożliwia deweloperom aplikacji określenie odpowiednich oczekiwań, które pomogą im w projektowaniu oprogramowania. Wdrożenia urządzeń, w zależności od typu urządzenia, MOGĄ mieć określone wymagania opisane w sekcji 2 w przypadku tych operacji odczytu i zapisu:

• Wydajność zapisu sekwencyjnego Pomiar wykonany podczas zapisywania pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
• Wydajność zapisu losowego Pomiar wykonany podczas zapisywania pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.
• Szybkość odczytu sekwencyjnego Pomiar wykonany podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
• Wydajność odczytu losowego Pomiar wykonany podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.

8.3. Tryby oszczędzania energii

Jeśli implementacje urządzeń zawierają funkcje poprawiające zarządzanie energią urządzenia, które są dostępne w AOSP (np. zasobnik czuwania aplikacji, tryb uśpienia), lub rozszerzają te funkcje, aby stosować bardziej rygorystyczne ograniczenia niż zasobnik czuwania aplikacji RESTRICTED, to:

• [C-1-1] NIE MOŻE odbiegać od implementacji AOSP w zakresie wyzwalania, konserwacji, algorytmów wybudzania i korzystania z globalnych ustawień systemu lub DeviceConfig w trybach oszczędzania energii w przypadku czuwania aplikacji i uśpienia.
• [C-1-2] NIE MOŻE odbiegać od implementacji AOSP w zakresie korzystania z ustawień globalnych lub DeviceConfig do zarządzania ograniczaniem zadań, alarmów i sieci w przypadku aplikacji w każdym koszyku w trybie gotowości aplikacji.
• [C-1-3] NIE MOŻE odbiegać od implementacji AOSP w zakresie liczby zasobników czuwania aplikacji używanych w przypadku czuwania aplikacji.
• [C-1-4] MUSI implementować grupy czuwania aplikacji i tryb uśpienia zgodnie z opisem w sekcji Zarządzanie energią.
• [C-1-5] MUSI zwracać true dla PowerManager.isPowerSaveMode() gdy urządzenie jest w trybie oszczędzania energii.
• [C-1-6] MUSI udostępniać użytkownikowi możliwość wyświetlania wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii „Aplikacja w trybie gotowości” i „Drzemka” lub z optymalizacji baterii, i MUSI implementować intencję ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, aby poprosić użytkownika o zezwolenie aplikacji na ignorowanie optymalizacji baterii.
• [C-SR-1] Zdecydowanie zaleca się udostępnienie użytkownikowi możliwości włączania i wyłączania funkcji oszczędzania baterii.
• [C-SR-2] Zdecydowanie zaleca się udostępnienie użytkownikowi możliwości wyświetlania wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii: gotowości aplikacji i drzemki.

Jeśli implementacje urządzeń rozszerzają funkcje zarządzania energią, które są zawarte w AOSP, a to rozszerzenie nakłada bardziej rygorystyczne ograniczenia niż rzadka grupa czuwania aplikacji, zapoznaj się z sekcją 3.5.1.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ implementować dowolne lub wszystkie 4 stany uśpienia zdefiniowane przez interfejs ACPI (Advanced Configuration and Power Interface).

Jeśli implementacje urządzeń obsługują stany zasilania S4 zdefiniowane przez ACPI, to:

• [C-1-1] MUSI przejść w ten stan tylko wtedy, gdy użytkownik wykona wyraźną czynność, aby wprowadzić urządzenie w stan nieaktywności (np. zamknie pokrywę, która jest fizycznie częścią urządzenia, lub wyłączy pojazd lub telewizor), i zanim ponownie aktywuje urządzenie (np. otworzy pokrywę lub ponownie włączy pojazd lub telewizor).

Jeśli implementacje urządzeń obsługują stany zasilania S3 zdefiniowane przez ACPI, to:

• [C-2-1] MUSI spełniać wymagania C-1-1 powyżej LUB MUSI przechodzić w stan S3 tylko wtedy, gdy aplikacje innych firm nie potrzebują zasobów systemowych (np. ekranu, procesora).

  Z kolei MUSI wyjść ze stanu S3, gdy aplikacje innych firm potrzebują zasobów systemowych, zgodnie z opisem w tym pakiecie SDK.

  Na przykład, gdy aplikacje innych firm żądają utrzymania włączonego ekranu za pomocą interfejsu FLAG_KEEP_SCREEN_ON lub utrzymania działania procesora za pomocą interfejsu PARTIAL_WAKE_LOCK, urządzenie NIE MOŻE przejść w stan S3, chyba że użytkownik wykonał wyraźną czynność, aby wprowadzić urządzenie w stan nieaktywny, zgodnie z opisem w sekcji C-1-1. Z kolei w momencie, gdy zadanie zaimplementowane przez aplikacje innych firm za pomocą JobSchedulera zostanie wywołane lub gdy Komunikacja w chmurze Firebase zostanie dostarczona do aplikacji innych firm, urządzenie MUSI wyjść ze stanu S3, chyba że użytkownik wprowadził urządzenie w stan nieaktywności. Nie są to wyczerpujące przykłady, a AOSP implementuje wiele sygnałów wybudzania, które wywołują wybudzenie z tego stanu.

8.4. Rozliczanie zużycia energii

Dokładniejsze rozliczanie i raportowanie zużycia energii daje deweloperowi aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorca zużycia energii przez aplikację.

Implementacje urządzeń:

• [C-SR-1] Zdecydowanie zalecamy podanie profilu zasilania poszczególnych komponentów, który określa wartość zużycia prądu każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją na stronie Projektu Android Open Source.
• [C-SR-2] ZDECYDOWANIE ZALECANE jest podawanie wszystkich wartości zużycia energii w miliamperogodzinach (mAh).
• [C-SR-3] ZDECYDOWANIE ZALECANE jest raportowanie zużycia energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądrauid_cputime.
• [C-SR-4] ZDECYDOWANIE ZALECANE jest udostępnienie informacji o zużyciu energii deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.
• Jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji, NALEŻY przypisać je do samego komponentu sprzętowego.

8.5. Stała wydajność

W przypadku aplikacji o wysokiej wydajności działających przez długi czas wydajność może się znacznie zmieniać z powodu innych aplikacji działających w tle lub ograniczenia mocy procesora z powodu limitów temperatury. Android zawiera interfejsy programowe, dzięki którym, gdy urządzenie ma taką możliwość, aplikacja na pierwszym planie może poprosić system o zoptymalizowanie przydziału zasobów w celu uwzględnienia takich wahań.

Implementacje urządzeń:

• [C-0-1] MUSI dokładnie zgłaszać obsługę trybu stałej wydajności za pomocą metody interfejsu API PowerManager.isSustainedPerformanceModeSupported().

• POWINIEN obsługiwać tryb stałej wydajności.

Jeśli implementacje urządzeń zgłaszają obsługę trybu stałej wydajności:

• [C-1-1] MUSI zapewniać aplikacji na pierwszym planie stały poziom wydajności przez co najmniej 30 minut, gdy aplikacja tego wymaga.
• [C-1-2] MUSI obsługiwać interfejs API Window.setSustainedPerformanceMode() i inne powiązane interfejsy API.

Jeśli implementacje urządzeń obejmują co najmniej 2 rdzenie procesora:

• POWINIEN udostępniać co najmniej 1 wyłączny rdzeń, który może być zarezerwowany przez aplikację działającą na pierwszym planie.

Jeśli implementacje urządzeń obsługują rezerwowanie jednego rdzenia na wyłączność dla aplikacji działającej na pierwszym planie, to:

• [C-2-1] MUSI zgłaszać za pomocą metody interfejsu API Process.getExclusiveCores() identyfikatory rdzeni wyłącznych, które mogą być zarezerwowane przez aplikację na pierwszym planie.
• [C-2-2] NIE MOŻE zezwalać na uruchamianie na wyłącznych rdzeniach żadnych procesów przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację, ale MOŻE zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.

Jeśli implementacje urządzeń nie obsługują wyłącznego rdzenia, to:

• [C-3-1] MUSI zwracać pustą listę za pomocą metody interfejsu API Process.getExclusiveCores().

8.6. Limity pamięci aplikacji

9. Zgodność modelu zabezpieczeń

Implementacje urządzeń:

• [C-0-1] MUSI wdrażać model bezpieczeństwa zgodny z modelem bezpieczeństwa platformy Android zdefiniowanym w dokumencie referencyjnym dotyczącym bezpieczeństwa i uprawnień w interfejsach API w dokumentacji dla deweloperów Androida.

• [C-0-2] MUSI obsługiwać instalację aplikacji podpisanych samodzielnie bez konieczności uzyskiwania dodatkowych uprawnień lub certyfikatów od osób trzecich lub organów.

Jeśli implementacje urządzenia deklarują funkcję android.hardware.security.model.compatible

• [C-1-1] MUSI obsługiwać wymagania wymienione w tych podsekcjach.

9.1. Uprawnienia

Implementacje urządzeń:

• [C-0-1] MUSI obsługiwać model uprawnień Androida i model ról Androida zgodnie z dokumentacją dla deweloperów Androida. W szczególności MUSZĄ egzekwować każde uprawnienie i każdą rolę zdefiniowane w dokumentacji pakietu SDK. Nie można pomijać, zmieniać ani ignorować żadnych uprawnień ani ról.

• MOŻE dodawać dodatkowe uprawnienia, pod warunkiem że nowe ciągi identyfikatorów uprawnień nie znajdują się w przestrzeni nazw android.\*.

• [C-0-2] Uprawnienia oznaczone symbolem protectionLevelPROTECTION_FLAG_PRIVILEGED MUSZĄ być przyznawane tylko aplikacjom preinstalowanym w ścieżkach uprzywilejowanych obrazu systemu (a także plikom APEX) i muszą należeć do podzbioru uprawnień wyraźnie dozwolonych dla każdej aplikacji. Implementacja AOSP spełnia to wymaganie, odczytując i respektując uprawnienia dozwolone dla każdej aplikacji z plików w ścieżce etc/permissions/ i używając ścieżki system/priv-app jako ścieżki uprzywilejowanej.

• [C-SR-1] Uprawnienia z wartością protectionLevel PROTECTION_SIGNATURE ZDECYDOWANIE ZALECA SIĘ przyznawać tylko:

  • Aplikacje wstępnie zainstalowane w obrazie systemu (a także pliki APEX).

  • Aplikacje znajdujące się na liście dozwolonych z dozwolonymi uprawnieniami, jeśli nie są uwzględnione w obrazie systemu.

Uprawnienia o poziomie ochrony „niebezpieczne” to uprawnienia czasu działania. Aplikacje z wartością targetSdkVersion > 22 wysyłają prośby w czasie działania.

Implementacje urządzeń:

• [C-0-3] MUSI wyświetlać specjalny interfejs, w którym użytkownik może zdecydować, czy przyznać żądane uprawnienia w czasie działania, a także interfejs do zarządzania tymi uprawnieniami.

• [C-0-5] NIE WOLNO przyznawać aplikacjom żadnych uprawnień czasu działania, chyba że:

  • Są one instalowane w momencie wysyłki urządzenia, ORAZ
  • Zgodę użytkownika można uzyskać przed użyciem uprawnień przez aplikację.

  LUB

  • Uprawnienia w czasie działania są przyznawane przez domyślne zasady przyznawania uprawnień lub w ramach roli platformy.

• [C-0-6] MUSI przyznawać uprawnienie android.permission.RECOVER_KEYSTORE tylko aplikacjom systemowym, które rejestrują odpowiednio zabezpieczonego agenta odzyskiwania. Prawidłowo zabezpieczony agent odzyskiwania to agent oprogramowania na urządzeniu, który synchronizuje się ze zdalnym magazynem poza urządzeniem i jest wyposażony w bezpieczny sprzęt z ochroną równoważną lub silniejszą niż opisana w usłudze Google Cloud Key Vault, aby zapobiegać atakom siłowym na składnik wiedzy dotyczący ekranu blokady.

Implementacje urządzeń:

• [C-0-7] MUSI przestrzegać właściwości uprawnień do lokalizacji w Androidzie, gdy aplikacja żąda danych o lokalizacji lub aktywności fizycznej za pomocą standardowego interfejsu API Androida lub mechanizmu własnego. Dane te obejmują m.in.:

  • Lokalizacja urządzenia (np. szerokość i długość geograficzna) zgodnie z sekcją 9.8.8.

  • Informacje, których można użyć do określenia lub oszacowania lokalizacji urządzenia (np. identyfikator SSID, BSSID, identyfikator komórki lub lokalizacja sieci, z którą połączone jest urządzenie).

  • aktywność fizyczna użytkownika lub jej klasyfikacja;

W szczególności implementacje urządzeń:

• [C-0-8] MUSI uzyskać zgodę użytkownika na dostęp aplikacji do danych o lokalizacji lub aktywności fizycznej.

• [C-0-9] MUSI przyznawać uprawnienia w czasie działania TYLKO aplikacji, która ma wystarczające uprawnienia zgodnie z opisem w pakiecie SDK. Na przykład TelephonyManager#getServiceState wymaga android.permission.ACCESS_FINE_LOCATION.

Jedynym wyjątkiem od powyższych właściwości uprawnień do lokalizacji na Androidzie są aplikacje, które nie uzyskują dostępu do lokalizacji w celu określenia lub zidentyfikowania lokalizacji użytkownika. Dotyczy to w szczególności:

• Gdy aplikacje mają uprawnienia z grupy RADIO_SCAN_WITHOUT_LOCATION.

• W przypadku konfiguracji i ustawień urządzenia, gdy aplikacje systemowe mają uprawnienia NETWORK_SETTINGS lub NETWORK_SETUP_WIZARD.

Uprawnienia można oznaczyć jako ograniczone, co zmieni ich działanie.

• [C-0-10] Uprawnienia oznaczone flagą hardRestricted NIE MOGĄ być przyznawane aplikacji, chyba że:

  • Plik APK aplikacji znajduje się na partycji systemowej.

  • Użytkownik przypisuje do aplikacji rolę powiązaną z uprawnieniami hardRestricted.

  • Instalator przyznaje hardRestricted aplikacji.

  • Aplikacja otrzymuje uprawnienie hardRestricted we wcześniejszej wersji Androida.

• [C-0-11] Aplikacje z uprawnieniem softRestricted MUSZĄ mieć tylko ograniczony dostęp i NIE MOGĄ uzyskiwać pełnego dostępu, dopóki nie zostaną dodane do listy dozwolonych zgodnie z opisem w pakiecie SDK, w którym zdefiniowano pełny i ograniczony dostęp dla każdego uprawnienia softRestricted (np. READ_EXTERNAL_STORAGE).

• [C-0-12] NIE MOŻE udostępniać żadnych funkcji niestandardowych ani interfejsów API, które pozwalają obejść ograniczenia uprawnień zdefiniowane w interfejsach API setPermissionPolicy i setPermissionGrantState.

• [C-0-13] MUSI używać interfejsów AppOpsManager API do rejestrowania i śledzenia każdego programowego dostępu do danych chronionych przez uprawnienia niebezpieczne z poziomu działań i usług Androida.

• [C-0-14] MUSI przypisywać role tylko aplikacjom, których funkcje spełniają wymagania dotyczące roli.

• [C-0-15] NIE MOŻE definiować ról, które są duplikatami lub nadzbiorem funkcji ról zdefiniowanych przez platformę.

Jeśli urządzenia zawierają czujniki danych, które udostępniają dane biometryczne związane ze zdrowiem, takie jak tętno lub temperatura skóry, te dane biometryczne:

• [C-0-16] MUSI być chroniona przez uprawnienia platformy z android.permission-group.HEALTH, jeśli w HealthPermissions istnieje odpowiednie uprawnienie.

• [C-0-17] MUSI być chroniony przez niestandardowe uprawnienia systemowe, jeśli żadne uprawnienia platformy nie pasują do żądanego typu danych. (na przykład ELECTROCARDIOGRAM).

Jeśli urządzenia zgłaszają android.software.managed_users, oznacza to, że:

• [C-1-1] NIE MOŻE mieć tych uprawnień przyznanych przez administratora bez powiadomienia:

  • Lokalizacja (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Aparat (CAMERA)
  • Mikrofon (RECORD_AUDIO)
  • Czujnik na ciele (BODY_SENSORS)
  • Zdrowie (HealthPermissions)
  • Aktywność fizyczna (ACTIVITY_RECOGNITION)

Jeśli urządzenia zgłaszają android.software.managed_users, oznacza to, że:

• [C-1-1] NIE MOŻE mieć tych uprawnień przyznanych przez administratora bez powiadomienia:

  • Lokalizacja (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Aparat (CAMERA)
  • Mikrofon (RECORD_AUDIO)
  • Czujnik na ciele (BODY_SENSORS)
  • Aktywność fizyczna (ACTIVITY_RECOGNITION)

Jeśli implementacje urządzeń zapewniają użytkownikowi afordancję wyboru aplikacji, które mogą wyświetlać się na wierzchu innych aplikacji, za pomocą aktywności obsługującej intencję ACTION_MANAGE_OVERLAY_PERMISSION, to:

• [C-2-1] MUSI zapewnić, że wszystkie działania z filtrami intencji dla intencji ACTION_MANAGE_OVERLAY_PERMISSION mają ten sam ekran interfejsu, niezależnie od aplikacji inicjującej lub informacji, które ona przekazuje.

Jeśli implementacje urządzeń zgłaszają android.software.device_admin, to:

• [C-3-1] MUSI wyświetlać wyłączenie odpowiedzialności podczas konfigurowania w pełni zarządzanego urządzenia (konfiguracja właściciela urządzenia), w którym stwierdza się, że administrator IT będzie miał możliwość zezwalania aplikacjom na kontrolowanie ustawień telefonu, w tym mikrofonu, aparatu i lokalizacji, z opcjami umożliwiającymi użytkownikowi kontynuowanie lub zakończenie konfiguracji, CHYBA ŻE administrator zrezygnował z kontroli uprawnień na urządzeniu.

Jeśli implementacje urządzeń wstępnie instalują pakiety, które pełnią dowolną z tych ról: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence lub System Visual Intelligence, pakiety:

• [C-4-1] MUSI spełniać wszystkie wymagania dotyczące implementacji urządzeń opisane w sekcjach 9.8.6. dane na poziomie systemu operacyjnego i dane otoczenia oraz 9.8.15. implementacje interfejsu Sandboxed API.

9.2. Identyfikator UID i izolacja procesów

Implementacje urządzeń:

• [C-0-1] MUSI obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja jest uruchamiana jako unikalny identyfikator UID w stylu systemu Unix i w osobnym procesie.
• [C-0-2] MUSI obsługiwać uruchamianie wielu aplikacji z tym samym identyfikatorem użytkownika systemu Linux, pod warunkiem że aplikacje są prawidłowo podpisane i zbudowane zgodnie z definicją w dokumentacji dotyczącej bezpieczeństwa i uprawnień.

9.3. Uprawnienia do systemu plików

Implementacje urządzeń:

• [C-0-1] MUSI obsługiwać model uprawnień dostępu do plików na Androidzie zdefiniowany w dokumentacji dotyczącej bezpieczeństwa i uprawnień.

9.4. Alternatywne środowiska wykonawcze

Implementacje urządzeń MUSZĄ zachowywać spójność modelu zabezpieczeń i uprawnień Androida, nawet jeśli zawierają środowiska wykonawcze, które uruchamiają aplikacje przy użyciu innego oprogramowania lub technologii niż format wykonywalny Dalvik lub kod natywny. Krótko mówiąc:

• [C-0-1] Alternatywne środowiska wykonawcze MUSZĄ być aplikacjami na Androida i muszą być zgodne ze standardowym modelem zabezpieczeń Androida, zgodnie z opisem w sekcji 9.

• [C-0-2] Alternatywne środowiska wykonawcze NIE MOGĄ uzyskiwać dostępu do zasobów chronionych przez uprawnienia, o które nie poproszono w pliku AndroidManifest.xml środowiska wykonawczego za pomocą mechanizmu <uses-permission>.

• [C-0-3] Alternatywne środowiska wykonawcze NIE MOGĄ zezwalać aplikacjom na korzystanie z funkcji chronionych przez uprawnienia Androida, które są ograniczone do aplikacji systemowych.

• [C-0-4] Alternatywne środowiska wykonawcze MUSZĄ być zgodne z modelem piaskownicy Androida, a aplikacje zainstalowane przy użyciu alternatywnego środowiska wykonawczego NIE MOGĄ ponownie wykorzystywać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida, takich jak udostępniony identyfikator użytkownika i certyfikat podpisu.

• [C-0-5] Alternatywne środowiska wykonawcze NIE MOGĄ uruchamiać się z dostępem do piaskownic odpowiadających innym aplikacjom na Androida, przyznawać takiego dostępu ani go uzyskiwać.

• [C-0-6] Alternatywne środowiska wykonawcze NIE MOGĄ być uruchamiane z uprawnieniami superużytkownika (root) ani żadnego innego identyfikatora użytkownika, ani nie mogą przyznawać takich uprawnień innym aplikacjom.

• [C-0-7] Jeśli w obrazie systemu implementacji urządzenia znajdują się pliki .apk alternatywnych środowisk wykonawczych, muszą być one podpisane kluczem innym niż klucz używany do podpisywania innych aplikacji dołączonych do implementacji urządzenia.

• [C-0-8] Podczas instalowania aplikacji alternatywne środowiska wykonawcze MUSZĄ uzyskiwać zgodę użytkownika na uprawnienia Androida używane przez aplikację.

• [C-0-9] Gdy aplikacja musi użyć zasobu urządzenia, dla którego istnieje odpowiednie uprawnienie Androida (np. aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI poinformować użytkownika, że aplikacja będzie mogła uzyskać dostęp do tego zasobu.

• [C-0-10] Jeśli środowisko wykonawcze nie rejestruje możliwości aplikacji w ten sposób, MUSI ono podczas instalowania dowolnej aplikacji za pomocą tego środowiska wyświetlać listę wszystkich uprawnień, które posiada.

• Alternatywne środowiska wykonawcze POWINNY instalować aplikacje za pomocą PackageManager w osobnych piaskownicach Androida (identyfikatory użytkowników Linuksa itp.).

• Alternatywne środowiska wykonawcze MOGĄ udostępniać jedną piaskownicę Androida współdzieloną przez wszystkie aplikacje korzystające z tego środowiska.

9.5. Obsługa wielu użytkowników

Android obsługuje wielu użytkowników i zapewnia pełną izolację użytkowników oraz klonowanie profili użytkowników z częściową izolacją (czyli pojedynczy dodatkowy profil użytkownika typu android.os.usertype.profile.CLONE).

• Urządzenia MOGĄ, ale NIE POWINNY włączać obsługi wielu użytkowników, jeśli korzystają z nośników wymiennych jako głównej pamięci zewnętrznej.

Jeśli implementacje urządzeń obsługują wielu użytkowników:

• [C-1-2] MUSI w przypadku każdego użytkownika wdrażać model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android zdefiniowanym w dokumencie referencyjnym dotyczącym zabezpieczeń i uprawnień w interfejsach API.

• [C-1-3] MUSI mieć oddzielne i odizolowane katalogi współdzielonego miejsca na dane aplikacji (tzw. /sdcard) dla każdej instancji użytkownika.

• [C-1-4] MUSI zapewnić, że aplikacje należące do danego użytkownika i uruchamiane w jego imieniu nie mogą wyświetlać, odczytywać ani zapisywać plików należących do innego użytkownika, nawet jeśli dane obu użytkowników są przechowywane na tym samym woluminie lub w tym samym systemie plików.

• [C-1-5] MUSI szyfrować zawartość karty SD, gdy włączona jest funkcja wielu użytkowników, za pomocą klucza przechowywanego tylko na nośniku nieusuwalnym, do którego dostęp ma tylko system, jeśli implementacje urządzeń używają nośników wymiennych w przypadku interfejsów API pamięci zewnętrznej. Spowoduje to, że nośnik będzie nieczytelny dla komputera hosta, więc implementacje urządzeń będą musiały przełączyć się na MTP lub podobny system, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika.

Jeśli implementacje urządzenia obsługują wielu użytkowników, w przypadku wszystkich użytkowników z wyjątkiem tych, którzy zostali utworzeni specjalnie do uruchamiania dwóch instancji tej samej aplikacji:

• [C-2-1] MUSI mieć oddzielne i izolowane katalogi współdzielonego miejsca na dane aplikacji (czyli /sdcard) dla każdej instancji użytkownika.

• [C-2-2] MUSI zapewnić, że aplikacje należące do danego użytkownika i uruchamiane w jego imieniu nie mogą wyświetlać, odczytywać ani zapisywać plików należących do innego użytkownika, nawet jeśli dane obu użytkowników są przechowywane na tym samym woluminie lub w tym samym systemie plików.

Implementacje urządzeń MOGĄ tworzyć jeden dodatkowy profil użytkownika typuandroid.os.usertype.profile.CLONE dla użytkownika głównego (i tylko dla niego) w celu uruchamiania dwóch instancji tej samej aplikacji. Te dwie instancje mają częściowo odizolowane miejsce na dane, są prezentowane użytkownikowi w launcherze w tym samym czasie i wyświetlane w tym samym widoku ostatnich aplikacji. Może to na przykład umożliwić użytkownikowi zainstalowanie 2 osobnych instancji jednej aplikacji na urządzeniu z 2 kartami SIM.

Jeśli implementacje urządzeń tworzą dodatkowy profil użytkownika opisany powyżej:

• [C-3-1] MUSI zapewniać dostęp tylko do pamięci lub danych, które są już dostępne w profilu użytkownika nadrzędnego lub są bezpośrednio powiązane z tym dodatkowym profilem użytkownika.

• [C-3-2] NIE MOŻE mieć tego jako profilu służbowego.

• [C-3-3] MUSI mieć odizolowane katalogi danych aplikacji prywatnych od konta użytkownika nadrzędnego.

• [C-3-4] NIE MOŻE zezwalać na utworzenie dodatkowego profilu użytkownika, jeśli urządzenie jest skonfigurowane jako własność użytkownika (patrz sekcja 3.9.1), ani zezwalać na skonfigurowanie urządzenia jako własności użytkownika bez wcześniejszego usunięcia dodatkowego profilu użytkownika.

Jeśli implementacje urządzeń tworzą dodatkowy profil użytkownika opisany powyżej:

• [C-4-1] MUSI zezwalać na obsługę przez aplikacje głównego użytkownika na urządzeniu tych intencji pochodzących z dodatkowego profilu:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] MUSI dziedziczyć wszystkie ograniczenia użytkownika dotyczące zasad urządzenia i wybrane ograniczenia restrictions(list below) inne niż użytkownika zastosowane do głównego użytkownika urządzenia w tym dodatkowym profilu użytkownika.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] MUSI zezwalać na zapisywanie kontaktów z tego dodatkowego profilu tylko za pomocą tych intencji:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] NIE MOŻE synchronizować kontaktów w przypadku aplikacji działających w tym dodatkowym profilu użytkownika.

• [C-4-5] MUSI zezwalać tylko aplikacjom w profilu dodatkowym, które mają aktywność programu uruchamiającego, na dostęp do kontaktów, które są już dostępne w profilu użytkownika nadrzędnego.

Jeśli implementacje urządzeń tworzą dodatkowy profil użytkownika opisany powyżej, zawierają co najmniej 1 kamerę, a wstępnie zainstalowana aplikacja aparatu obsługuje intencje MediaStore.ACTION_MOTION_PHOTO_CAPTURE lub MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, to:

• [C-5-1] MUSI zezwalać aplikacjom użytkownika głównego na obsługę tych intencji pochodzących z dodatkowego profilu użytkownika.

9.6. Ostrzeżenie dotyczące SMS-ów specjalnych

Android obsługuje ostrzeganie użytkowników o każdej wychodzącej wiadomości SMS premium. SMS-y specjalne to wiadomości tekstowe wysyłane do usługi zarejestrowanej u operatora, za które użytkownik może ponosić opłaty.

Jeśli implementacje urządzeń deklarują obsługę android.hardware.telephony, to:

• [C-1-1] MUSI ostrzegać użytkowników przed wysłaniem wiadomości SMS na numery zidentyfikowane przez wyrażenia regularne zdefiniowane w /data/misc/sms/codes.xml na urządzeniu. Projekt Android Open Source udostępnia implementację, która spełnia to wymaganie.

9.7. Security Features

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń w jądrze i na platformie zgodnie z opisem poniżej.

Piaskownica Androida zawiera funkcje, które korzystają z systemu obowiązkowej kontroli dostępu (MAC) Security-Enhanced Linux (SELinux), piaskownicy seccomp i innych funkcji zabezpieczeń w jądrze systemu Linux. Implementacje urządzeń:

• [C-0-1] MUSI zachowywać zgodność z istniejącymi aplikacjami, nawet jeśli SELinux lub inne funkcje zabezpieczeń są zaimplementowane poniżej struktury Androida.

• [C-0-2] NIE MOŻE mieć widocznego interfejsu użytkownika, gdy funkcja zabezpieczeń zaimplementowana poniżej platformy Android wykryje i skutecznie zablokuje naruszenie bezpieczeństwa, ale MOŻE mieć widoczny interfejs użytkownika, gdy wystąpi niezablokowane naruszenie bezpieczeństwa, które doprowadzi do skutecznego wykorzystania luki w zabezpieczeniach.

• [C-0-3] NIE WOLNO udostępniać użytkownikowi ani deweloperowi aplikacji możliwości konfigurowania SELinux ani żadnych innych funkcji zabezpieczeń zaimplementowanych poniżej platformy Androida.

• [C-0-4] NIE WOLNO zezwalać aplikacji, która może wpływać na inną aplikację za pomocą interfejsu API (np. interfejsu Device Administration API), na konfigurowanie zasad, które powodują utratę zgodności.

• [C-0-5] MUSI podzielić platformę multimedialną na wiele procesów, aby można było bardziej precyzyjnie przyznawać dostęp do każdego z nich w sposób opisany na stronie projektu Android Open Source.

• [C-0-6] MUSI implementować mechanizm piaskownicy aplikacji w jądrze, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnych zasad z programów wielowątkowych. Projekt Android Open Source spełnia to wymaganie, umożliwiając seccomp-BPF z synchronizacją grupy wątków (TSYNC), zgodnie z opisem w sekcji Konfiguracja jądra na stronie source.android.com.

Integralność jądra i funkcje samoobrony są nieodłączną częścią zabezpieczeń Androida. Implementacje urządzeń:

• [C-0-7] MUSI implementować mechanizmy ochrony przed przepełnieniem bufora stosu jądra. Przykłady takich mechanizmów to CC_STACKPROTECTOR_REGULAR i CONFIG_CC_STACKPROTECTOR_STRONG.

• [C-0-8] MUSI wdrażać ścisłą ochronę pamięci jądra, w której kod wykonywalny jest tylko do odczytu, dane tylko do odczytu nie są wykonywalne ani zapisywalne, a dane zapisywalne nie są wykonywalne (np. włączone są zarówno rodata, jak i CONFIG_STRICT_KERNEL_RWX).

• [C-0-9] MUSI implementować statyczne i dynamiczne sprawdzanie rozmiaru obiektu kopii między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY) na urządzeniach, które pierwotnie były dostarczane z poziomem API 28 lub wyższym.

• [C-0-10] NIE MOŻE wykonywać pamięci przestrzeni użytkownika podczas działania w trybie jądra (np. sprzętowy PXN lub emulowany za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które pierwotnie były dostarczane z interfejsem API na poziomie 28 lub wyższym.

• [C-0-11] NIE WOLNO odczytywać ani zapisywać pamięci przestrzeni użytkownika w jądrze poza normalnymi interfejsami API dostępu usercopy (np. sprzętowy PAN lub emulowany za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które pierwotnie były dostarczane z interfejsem API na poziomie 28 lub wyższym.

• [C-0-12] MUSI implementować izolację tabeli stron jądra, jeśli sprzęt jest podatny na CVE-2017-5754 na wszystkich urządzeniach, które pierwotnie były dostarczane z interfejsem API na poziomie 28 lub wyższym (np. CONFIG_PAGE_TABLE_ISOLATION lub CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] MUSI implementować wzmocnienie przewidywania rozgałęzień, jeśli sprzęt jest podatny na CVE-2017-5715 na wszystkich urządzeniach, które pierwotnie były dostarczane z API na poziomie 28 lub wyższym (np. CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] ZDECYDOWANIE ZALECANE jest, aby po inicjowaniu oznaczać jako tylko do odczytu dane jądra, które są zapisywane tylko podczas inicjowania (np. __ro_after_init).

• [C-SR-2] Zdecydowanie zaleca się randomizację układu kodu jądra i pamięci oraz unikanie sytuacji, które mogłyby naruszyć randomizację (np. CONFIG_RANDOMIZE_BASE z użyciem entropii programu rozruchowego za pomocą /chosen/kaslr-seed Device Tree node lub EFI_RNG_PROTOCOL).

• [C-SR-3] ZDECYDOWANIE ZALECA się włączenie w jądrze ochrony integralności przepływu sterowania (CFI), aby zapewnić dodatkową ochronę przed atakami polegającymi na ponownym wykorzystaniu kodu (np. CONFIG_CFI_CLANG i CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] Zdecydowanie zaleca się, aby nie wyłączać funkcji Control-Flow Integrity (CFI), Shadow Call Stack (SCS) ani Integer Overflow Sanitization (IntSan) w komponentach, w których są one włączone.

• [C-SR-5] Zdecydowanie zalecamy włączenie CFI, SCS i IntSan w przypadku wszystkich dodatkowych komponentów przestrzeni użytkownika, które są wrażliwe na kwestie bezpieczeństwa, zgodnie z opisem w sekcjach CFI i IntSan.

• [C-SR-6] Zdecydowanie zaleca się włączenie inicjowania stosu w jądrze, aby zapobiec używaniu niezainicjowanych zmiennych lokalnych (CONFIG_INIT_STACK_ALL lub CONFIG_INIT_STACK_ALL_ZERO). Implementacje urządzeń NIE POWINNY też zakładać wartości używanej przez kompilator do inicjowania zmiennych lokalnych.

• [C-SR-7] Zdecydowanie zaleca się włączenie inicjowania sterty w jądrze, aby zapobiec używaniu nieinicjowanych przydziałów sterty (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), i NIE NALEŻY zakładać wartości używanej przez jądro do inicjowania tych przydziałów.

Jeśli implementacje urządzeń korzystają z jądra systemu Linux, które obsługuje SELinux, to:

• [C-1-1] MUSI implementować SELinux.

• [C-1-2] MUSI ustawić SELinux w trybie globalnego egzekwowania.

• [C-1-3] MUSI skonfigurować wszystkie domeny w trybie egzekwowania. Nie są dozwolone żadne domeny w trybie zezwalającym, w tym domeny specyficzne dla urządzenia lub dostawcy.

• [C-1-5] MUSI uruchamiać aplikacje innych firm przeznaczone na interfejs API na poziomie 28 lub wyższym w piaskownicach SELinux dla poszczególnych aplikacji z ograniczeniami SELinux dla poszczególnych aplikacji w katalogu danych prywatnych każdej aplikacji.

• POWINNI zachować domyślne zasady SELinux udostępnione w folderze system/sepolicy w projekcie Android Open Source Project i tylko dodawać do tych zasad własne konfiguracje specyficzne dla urządzenia.

Jeśli implementacje urządzeń korzystają z jądra innego niż Linux lub z systemu Linux bez SELinux:

• [C-2-1] MUSI używać systemu obowiązkowej kontroli dostępu, który jest odpowiednikiem SELinux.

Jeśli implementacje urządzeń korzystają z urządzeń wejścia/wyjścia obsługujących DMA:

• [C-SR-9] Zdecydowanie zaleca się odizolowanie każdego urządzenia wejścia/wyjścia obsługującego DMA za pomocą IOMMU (np. ARM SMMU).

Android zawiera wiele funkcji ochrony warstwowej, które są integralną częścią zabezpieczeń urządzenia. Android koncentruje się też na ograniczaniu kluczowych klas typowych błędów, które przyczyniają się do obniżenia jakości i bezpieczeństwa.

Aby ograniczyć błędy pamięci, implementacje urządzeń:

• [C-SR-10] Zdecydowanie zaleca się testowanie za pomocą narzędzi do wykrywania błędów pamięci w przestrzeni użytkownika, takich jak MTE w przypadku urządzeń z architekturą ARMv9, HWASan w przypadku urządzeń z architekturą ARMv8+ lub ASan w przypadku innych typów urządzeń.

• [C-SR-11] Zdecydowanie zaleca się testowanie za pomocą narzędzi do wykrywania błędów w pamięci jądra, takich jak KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS w przypadku urządzeń z ARMv9, CONFIG_KASAN_SW_TAGS w przypadku urządzeń z ARMv8 lub CONFIG_KASAN_GENERIC w przypadku innych typów urządzeń).

• [C-SR-12] Zdecydowanie zalecamy używanie w środowisku produkcyjnym narzędzi do wykrywania błędów pamięci, takich jak MTE, GWP-ASan i KFENCE.

Jeśli implementacje urządzeń korzystają z zaufanego środowiska wykonawczego TEE opartego na technologii Arm TrustZone:

• [C-SR-13] Zdecydowanie zaleca się stosowanie standardowego protokołu do udostępniania pamięci między Androidem a TEE, takiego jak Arm Firmware Framework for Armv8-A (FF-A).

• [C-SR-14] ZDECYDOWANIE ZALECA się ograniczenie dostępu zaufanych aplikacji tylko do pamięci, która została im wyraźnie udostępniona za pomocą powyższego protokołu. Jeśli urządzenie obsługuje poziom wyjątku Arm S-EL2, powinno to być egzekwowane przez menedżera bezpiecznej partycji. W przeciwnym razie powinno to być egzekwowane przez system operacyjny TEE.

Technologia bezpieczna pod względem zarządzania pamięcią to technologia, która z wysokim prawdopodobieństwem (> 90%) ogranicza co najmniej te klasy błędów w aplikacjach, które używają opcji manifestu android:memtagMode:

• przepełnienie bufora sterty,
• używać po okresie bezpłatnym,
• podwójny wolny
• wild free (zwolnienie pamięci, do której nie odnosi się wskaźnik malloc)

Implementacje urządzeń:

• [C-SR-15] Zdecydowanie zalecamy ustawienie ro.arm64.memtag.bootctl_supported.

Jeśli implementacje urządzenia ustawiają właściwość systemową ro.arm64.memtag.bootctl_supported na wartość true, to:

• [C-3-1] MUSI umożliwiać akceptowanie przez właściwość systemową arm64.memtag.bootctl listy rozdzielonych przecinkami wartości z poniższego zestawu, przy czym po kolejnym ponownym uruchomieniu systemu musi być stosowany oczekiwany efekt:

  • memtag: włączona jest technologia bezpieczeństwa pamięci zdefiniowana powyżej.

  • memtag-once: technologia Memory Safety w sposób tymczasowy jest włączona, a po następnym ponownym uruchomieniu automatycznie wyłączana.

  • memtag-off: technologia Memory Safety zdefiniowana powyżej jest wyłączona.

• [C-3-2] MUSI zezwalać użytkownikowi powłoki na ustawienie arm64.memtag.bootctl.

• [C-3-3] MUSI zezwalać każdemu procesowi na odczytywanie arm64.memtag.bootctl.

• [C-3-4] MUSI ustawić arm64.memtag.bootctl na aktualnie żądany stan po uruchomieniu. MUSI też zaktualizować właściwość, jeśli implementacja urządzenia umożliwia modyfikowanie stanu bez zmiany właściwości systemu.

• [C-SR-16] Zdecydowanie zaleca się wyświetlanie ustawienia programisty, które ustawia memtag-once i ponownie uruchamia urządzenie. W przypadku zgodnego programu rozruchowego projekt Android Open Source spełnia powyższe wymagania dzięki protokołowi programu rozruchowego MTE.

Jeśli urządzenie deklaruje android.hardware.telephony, obsługuje funkcję radiową CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK i zawiera modem komórkowy obsługujący połączenia 2G, implementacja urządzenia:

• [C-SR-17] Zdecydowanie zaleca się umożliwienie użytkownikowi wyłączania i włączania sieci 2G.

• [C-SR-18] ZDECYDOWANIE ZALECA SIĘ, aby nie zastępować możliwości użytkownika wyłączania i włączania 2G za pomocą żadnego innego elementu urządzenia, z wyjątkiem administratora urządzenia, który używa UserManager.DISALLOW_CELLULAR_2G.

• [C-SR-19] Zdecydowanie zalecamy wywołanie funkcji TelephonyManager.setAllowedNetworkTypesForReason z przyczyną ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G, aby spełnić to wymaganie.

• [C-SR-20] Zdecydowanie zalecamy sprawdzenie obsługi modemu komórkowego w przypadku sieci 2G przez wywołanie numeru TelephonyManager.getSupportedRadioAccessFamily. Więcej informacji znajdziesz w artykule Wyłączanie sieci 2G.

9.8. Prywatność

9.8.1. Historia wykorzystania

Android przechowuje historię wyborów użytkownika i zarządza nią za pomocą interfejsu UsageStatsManager.

Implementacje urządzeń:

• [C-0-1] MUSI zachować rozsądny okres przechowywania historii użytkownika.

• [C-SR-1] Zdecydowanie zaleca się zachowanie 14-dniowego okresu przechowywania skonfigurowanego domyślnie w implementacji AOSP.

Android przechowuje zdarzenia systemowe, używając StatsLog identyfikatorów, i zarządza taką historią za pomocą interfejsów API StatsManager i IncidentManager.

Implementacje urządzeń:

• [C-0-2] MUSI zawierać tylko pola oznaczone symbolem DEST_AUTOMATIC w raporcie o zdarzeniu utworzonym przez klasę interfejsu API systemu IncidentManager.

• [C-0-3] NIE WOLNO używać identyfikatorów zdarzeń systemowych do rejestrowania żadnych innych zdarzeń niż te, które są opisane w dokumentach pakietu SDK StatsLog. Jeśli rejestrowane są dodatkowe zdarzenia systemowe, MOGĄ one używać innego identyfikatora atomu z zakresu od 100 000 do 200 000.

9.8.2. Nagrywam

Implementacje urządzeń:

• [C-0-1] NIE WOLNO wstępnie ładować ani rozpowszechniać od razu po wyjęciu z pudełka komponentów oprogramowania, które wysyłają prywatne informacje użytkownika (np. naciśnięcia klawiszy, tekst wyświetlany na ekranie, raport o błędach) z urządzenia bez zgody użytkownika lub bez wyraźnych, ciągłych powiadomień.

• [C-0-2] MUSI wyświetlać ostrzeżenie dla użytkownika i uzyskiwać jego wyraźną zgodę na rejestrowanie wszelkich informacji poufnych wyświetlanych na ekranie użytkownika za każdym razem, gdy sesja przechwytywania transmisji ekranu lub nagrywania ekranu jest włączana za pomocą MediaProjection.createVirtualDisplay() lub interfejsów API własności.

• [C-0-3] MUSI wyświetlać użytkownikowi ciągłe powiadomienie, gdy włączone jest przesyłanie lub nagrywanie ekranu. AOSP spełnia ten wymóg, wyświetlając ikonę powiadomienia o trwającej aktywności na pasku stanu.

• [C-SR-1] ZDECYDOWANIE ZALECA się wyświetlanie ostrzeżenia dla użytkownika, które jest dokładnie takie samo jak komunikat zaimplementowany w AOSP, ale MOŻE być zmienione, o ile wyraźnie ostrzega użytkownika, że wszelkie informacje poufne na ekranie użytkownika są rejestrowane.

• [C-0-4] Wymaganie usunięte w Androidzie 16.

Implementacje urządzeń:

• [C-0-7] NIE WOLNO nagrywać, wyświetlać ani przesyłać informacji poufnych, takich jak:

  • Treść poufnego powiadomienia wymieniona w sekcji 3.8.3.4 Ochrona poufnych powiadomień
  • Okna aktywności aplikacji zawierające hasła jednorazowe
  • treści poufne, takie jak nazwa użytkownika, hasło i dane karty kredytowej;

Jeśli implementacje urządzeń zawierają funkcje systemowe, które rejestrują zawartość wyświetlaną na ekranie lub nagrywają strumień audio odtwarzany na urządzeniu w inny sposób niż za pomocą interfejsu System API ContentCaptureService lub w inny sposób opisany w sekcji 9.8.6 Dane na poziomie systemu operacyjnego i dane z otoczenia, to:

• [C-1-1] MUSI wyświetlać użytkownikowi powiadomienie o trwającej aktywności, gdy ta funkcja jest włączona i aktywna (rejestruje lub nagrywa).

Jeśli implementacje urządzeń zawierają komponent włączony od razu po wyjęciu z pudełka, który może nagrywać dźwięk otoczenia lub dźwięk odtwarzany na urządzeniu, aby wywnioskować przydatne informacje o kontekście użytkownika:

• [C-2-1] NIE WOLNO przechowywać w pamięci trwałej urządzenia ani przesyłać poza urządzenie nagranego surowego dźwięku ani żadnego formatu, który można przekonwertować z powrotem na oryginalny dźwięk lub jego niemal identyczną kopię, chyba że użytkownik wyrazi na to wyraźną zgodę.

„Wskaźnik mikrofonu” to widok na ekranie, który jest stale widoczny dla użytkownika i nie można go zasłonić. Użytkownicy rozumieją go jako informację o tym, że mikrofon jest w użyciu(dzięki unikalnemu tekstowi, kolorowi, ikonie lub ich kombinacji).

„Wskaźnik kamery” to widok na ekranie, który jest stale widoczny dla użytkownika i nie można go zasłonić. Użytkownicy rozumieją, że kamera jest w użyciu (dzięki unikalnemu tekstowi, kolorowi, ikonie lub ich kombinacji).

Po wyświetleniu przez pierwszą sekundę wskaźnik może ulec wizualnej zmianie, np. zmniejszyć się, i nie musi być wyświetlany w sposób pierwotny.

Wskaźnik mikrofonu może być połączony z aktywnie wyświetlanym wskaźnikiem kamery, pod warunkiem że tekst, ikony lub kolory informują użytkownika o rozpoczęciu korzystania z mikrofonu.

Wskaźnik aparatu może być połączony z aktywnie wyświetlanym wskaźnikiem mikrofonu, pod warunkiem że tekst, ikony lub kolory informują użytkownika o rozpoczęciu korzystania z aparatu.

Jeśli implementacje urządzeń deklarują android.hardware.microphone, to:

• [C-SR-1] Zdecydowanie zaleca się wyświetlanie wskaźnika mikrofonu, gdy aplikacja uzyskuje dostęp do danych audio z mikrofonu, ale nie wtedy, gdy mikrofon jest używany tylko przez HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje pełniące role wymienione w sekcji 9.1 Uprawnienia z identyfikatorem CDD [C-3-X].

• [C-SR-2] Zdecydowanie zaleca się wyświetlanie listy ostatnich i aktywnych aplikacji korzystających z mikrofonu, zwróconej przez PermissionManager.getIndicatorAppOpUsageData(), wraz z wszelkimi powiązanymi z nimi komunikatami o atrybucji.

• [C-SR-3] Zdecydowanie zalecamy, aby nie ukrywać wskaźnika mikrofonu w przypadku aplikacji systemowych, które mają widoczny interfejs użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.

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

• [C-SR-4] ZDECYDOWANIE ZALECA się wyświetlanie wskaźnika aparatu, gdy aplikacja uzyskuje dostęp do danych z aparatu na żywo, ale nie wtedy, gdy aparat jest używany tylko przez aplikacje pełniące role wymienione w sekcji 9.1 Uprawnienia z identyfikatorem dokumentu CDD [C-3-X].

• [C-SR-5] Zdecydowanie zaleca się wyświetlanie ostatnich i aktywnych aplikacji korzystających z kamery, które zostały zwrócone przez PermissionManager.getIndicatorAppOpUsageData(), oraz powiązanych z nimi komunikatów o atrybucji.

• [C-SR-6] Zdecydowanie zalecamy, aby w przypadku aplikacji systemowych z widocznym interfejsem użytkownika lub bezpośrednią interakcją z użytkownikiem nie ukrywać wskaźnika aparatu.

9.8.3. Łączność

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB:

• [C-1-1] MUSI wyświetlać interfejs użytkownika z prośbą o zgodę użytkownika przed zezwoleniem na dostęp do zawartości pamięci współdzielonej przez port USB.

9.8.4. Ruch sieciowy

Implementacje urządzeń:

• [C-0-1] MUSI wstępnie instalować te same certyfikaty główne w magazynie zaufanych przez system urzędów certyfikacji, które są dostarczane w projekcie Android Open Source Project.

• [C-0-2] MUSI być dostarczany z pustym magazynem głównego urzędu certyfikacji użytkownika.

• [C-0-3] MUSI wyświetlać użytkownikowi ostrzeżenie o tym, że po dodaniu głównego urzędu certyfikacji użytkownika ruch w sieci może być monitorowany.

Jeśli ruch na urządzeniu jest kierowany przez sieć VPN, implementacje na urządzeniu:

• [C-1-1] MUSI wyświetlać ostrzeżenie dla użytkownika wskazujące:
  • Ten ruch w sieci może być monitorowany.
  • Ten ruch w sieci jest kierowany przez konkretną aplikację VPN, która zapewnia VPN.

Jeśli implementacje urządzeń mają mechanizm, który jest domyślnie włączony i kieruje ruch danych sieciowych przez serwer proxy lub bramę VPN (np. wstępne wczytywanie usługi VPN z przyznanym uprawnieniem android.permission.CONTROL_VPN), to:

• [C-2-1] MUSI prosić użytkownika o zgodę przed włączeniem tego mechanizmu, chyba że sieć VPN jest włączana przez kontroler zasad dotyczących urządzenia za pomocą interfejsu DevicePolicyManager.setAlwaysOnVpnPackage(). W takim przypadku użytkownik nie musi wyrażać oddzielnej zgody, ale MUSI otrzymać powiadomienie.

Jeśli implementacje urządzeń udostępniają użytkownikowi możliwość włączania i wyłączania funkcji „stały VPN” aplikacji VPN innej firmy:

• [C-3-1] MUSI wyłączyć tę funkcję dla aplikacji, które nie obsługują usługi VPN działającej w trybie ciągłym, w pliku AndroidManifest.xml, ustawiając atrybut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

9.8.5. Identyfikatory urządzeń

Implementacje urządzeń:

• [C-0-1] MUSI uniemożliwiać dostęp do numeru seryjnego urządzenia oraz, w stosownych przypadkach, do numeru IMEI/MEID, numeru seryjnego karty SIM i identyfikatora IMSI (International Mobile Subscriber Identity) z poziomu aplikacji, chyba że spełnia ona jedno z tych wymagań:
  • jest podpisaną aplikacją operatora, która została zweryfikowana przez producentów urządzeń.
  • otrzymał(-a) uprawnienie READ_PRIVILEGED_PHONE_STATE.
  • ma uprawnienia operatora zdefiniowane w UICC Carrier Privileges.
  • jest właścicielem urządzenia lub profilu, któremu przyznano uprawnienie READ_PHONE_STATE.
  • (Dotyczy tylko numeru seryjnego karty SIM lub numeru ICCID) musi spełniać wymagania lokalnych przepisów, zgodnie z którymi aplikacja ma wykrywać zmiany tożsamości subskrybenta.

9.8.6. Ochrona danych na poziomie systemu operacyjnego i danych otoczenia

• [C-1-7] MUSI udostępniać użytkownikowi możliwość rezygnacji z wyświetlania na platformie Android (np. w launcherze) danych zebranych za pomocą wyszukiwarki aplikacji lub w inny sposób.

• [C-SR-1] ZDECYDOWANIE NIE ZALECA się żądania uprawnień INTERNET.

• [C-SR-2] Zdecydowanie zalecamy, aby dostęp do internetu był możliwy tylko za pomocą strukturalnych interfejsów API opartych na publicznie dostępnych implementacjach open source.

• [C-SR-4] ZDECYDOWANIE ZALECA się implementację za pomocą interfejsu API pakietu Android SDK lub podobnego repozytorium open source należącego do producenta OEM i / lub wykonanie w implementacji w piaskownicy (patrz punkt 9.8.15 Implementacje interfejsu API w piaskownicy).

• [C-SR-3] Zdecydowanie zaleca się, aby usługi były oddzielone od innych komponentów systemu (np. nie wiązać usługi ani nie udostępniać identyfikatorów procesów), z wyjątkiem tych przypadków:
  • Telefon, Kontakty, Interfejs systemu i Media

9.8.7. Dostęp do schowka

Implementacje urządzeń:

• [C-0-1] NIE MOŻE zwracać przyciętych danych ze schowka (np. za pomocą interfejsu API ClipboardManager), chyba że aplikacja innej firmy jest domyślnym edytorem IME lub aplikacją, która jest obecnie aktywna.

• [C-0-2] MUSI wyczyścić dane ze schowka najpóźniej 60 minut po tym, jak zostały ostatnio umieszczone w schowku lub odczytane ze schowka.

9.8.8. Lokalizacja

Lokalizacja obejmuje informacje z klasy lokalizacji Androida( np. szerokość, długość i wysokość geograficzną), a także identyfikatory, które można przekształcić w lokalizację. Lokalizacja może być tak dokładna jak DGPS (Differential Global Positioning System) lub tak ogólna jak lokalizacje na poziomie kraju (np. kod kraju – MCC – Mobile Country Code).

Poniżej znajdziesz listę typów lokalizacji, które bezpośrednio określają lokalizację użytkownika lub mogą zostać do niej przekształcone. Ta lista nie jest wyczerpująca, ale zawiera przykłady informacji, z których można bezpośrednio lub pośrednio wywnioskować lokalizację:

• GPS/GNSS/DGPS/PPP

  • Global Positioning Solution lub Global Navigation Satellite System lub Differential Global Positioning Solution
  • Obejmuje to też nieprzetworzone pomiary GNSS i stan GNSS.
    • Dokładną lokalizację można określić na podstawie nieprzetworzonych pomiarów GNSS.

• technologie bezprzewodowe z unikalnymi identyfikatorami, takie jak:

  • punkty dostępu Wi-Fi (MAC, BSSID, nazwa lub SSID);
  • Bluetooth/BLE (MAC, BSSID, nazwa lub SSID)
  • UWB (MAC, BSSID, nazwa lub SSID)
  • Identyfikator stacji bazowej (3G, 4G, 5G itp., w tym wszystkie przyszłe technologie modemów komórkowych, które mają unikalne identyfikatory)

Jako główne źródło informacji sprawdź interfejsy API Androida, które wymagają uprawnień ACCESS_FINE_Location lub ACCESS_COARSE_Location.

Implementacje urządzeń:

• [C-0-1] NIE WOLNO włączać ani wyłączać ustawień lokalizacji urządzenia oraz ustawień skanowania Wi-Fi lub Bluetooth bez wyraźnej zgody użytkownika lub bez jego inicjatywy.

• [C-0-2] MUSI udostępniać użytkownikowi możliwość dostępu do informacji związanych z lokalizacją, w tym ostatnich próśb o lokalizację, uprawnień na poziomie aplikacji i korzystania ze skanowania Wi-Fi/Bluetooth w celu określenia lokalizacji.

• [C-0-3] MUSI zapewnić, że aplikacja korzystająca z interfejsu Emergency Location Bypass API LocationRequest.setLocationSettingsIgnored() jest sesją alarmową zainicjowaną przez użytkownika (np. połączenie z numerem 911 lub wysłanie SMS-a pod ten numer). W przypadku motoryzacji pojazd MOŻE zainicjować sesję alarmową bez aktywnej interakcji użytkownika w przypadku wykrycia wypadku (np. w celu spełnienia wymagań eCall).

• [C-0-4] MUSI zachować możliwość pomijania ustawień lokalizacji urządzenia przez interfejsy API Emergency Location Bypass bez zmiany tych ustawień.

• [C-0-5] MUSI zaplanować powiadomienie, które przypomni użytkownikowi, że aplikacja działająca w tle uzyskała dostęp do jego lokalizacji za pomocą uprawnienia ACCESS_BACKGROUND_LOCATION.

9.8.9. Zainstalowane aplikacje

Aplikacje na Androida kierowane na poziom API 30 lub wyższy nie mogą domyślnie wyświetlać szczegółów o innych zainstalowanych aplikacjach (patrz sekcja Widoczność pakietów w dokumentacji pakietu SDK Androida).

Implementacje urządzeń:

• [C-0-1] NIE MOŻE udostępniać żadnej aplikacji kierowanej na docelowy poziom interfejsu API 30 lub wyższy szczegółów dotyczących innych aplikacji instalowanych, chyba że aplikacja może już wyświetlać szczegóły dotyczące innych aplikacji instalowanych za pomocą zarządzanych interfejsów API. Dotyczy to między innymi szczegółów udostępnianych przez niestandardowe interfejsy API dodane przez producenta urządzenia lub dostępne w systemie plików.

• [C-0-2] NIE WOLNO przyznawać żadnej aplikacji dostępu do odczytu ani zapisu plików w dedykowanym katalogu konkretnej aplikacji na pamięci zewnętrznej. Wyjątki:

  • Uprawnienia dostawcy miejsca na dane (np. aplikacji takich jak DocumentsUI).

  • Download Provider, który używa uprawnień dostawcy „downloads” do pobierania plików do pamięci aplikacji.

  • Aplikacje do przesyłania multimediów (MTP) podpisane przez platformę, które używają uprawnienia uprzywilejowanego ACCESS_MTP, aby umożliwić przesyłanie plików na inne urządzenie.

  • Aplikacje, które instalują inne aplikacje i mają uprawnienie INSTALL_PACKAGES, mogą uzyskiwać dostęp tylko do katalogów „obb” w celu zarządzania plikami rozszerzeń APK.

9.8.10. Raport o błędach związanych z łącznością

Jeśli implementacje urządzeń deklarują flagę funkcji android.hardware.telephony, to:

• [C-1-1] MUSI obsługiwać generowanie raportów o błędach związanych z łącznością za pomocą interfejsu BUGREPORT_MODE_TELEPHONY z klasą BugreportManager.

• [C-1-2] MUSI uzyskiwać zgodę użytkownika za każdym razem, gdy BUGREPORT_MODE_TELEPHONY jest używana do generowania raportu, i NIE MOŻE prosić użytkownika o wyrażenie zgody na wszystkie przyszłe żądania z aplikacji.

• [C-1-3] NIE MOŻE zwracać wygenerowanego raportu do aplikacji wysyłającej żądanie bez wyraźnej zgody użytkownika.

• [C-1-4] Raporty generowane za pomocą BUGREPORT_MODE_TELEPHONY MUSZĄ zawierać co najmniej te informacje:

  • TelephonyDebugService zrzut
  • TelephonyRegistry zrzut
  • WifiService zrzut
  • ConnectivityService zrzut
  • Zrzut instancji CarrierService pakietu wywołującego (jeśli jest powiązany).
  • Bufor dziennika radiowego
  • SubscriptionManagerService zrzut

• [C-1-5] W wygenerowanych raportach NIE MOŻE zawierać tych informacji:

  • Wszelkie informacje, które nie są bezpośrednio związane z debugowaniem łączności.

  • Wszelkie dzienniki ruchu aplikacji zainstalowanych przez użytkownika lub szczegółowe profile aplikacji/pakietów zainstalowanych przez użytkownika (identyfikatory UID są dopuszczalne, nazwy pakietów nie).

• MOŻE zawierać dodatkowe informacje, które nie są powiązane z tożsamością żadnego użytkownika. (np. logi dostawcy).

Jeśli implementacje urządzeń zawierają w raportach o błędach dodatkowe informacje (np. dane dostawcy), które mają wpływ na prywatność, bezpieczeństwo, baterię, pamięć masową lub pamięć, muszą:

• [C-SR-1] Zdecydowanie zaleca się, aby ustawienie programisty było domyślnie wyłączone. Referencyjna implementacja AOSP spełnia ten wymóg, udostępniając w ustawieniach programisty opcję Enable verbose vendor logging, która umożliwia uwzględnianie w raportach o błędach dodatkowych dzienników dostawcy dotyczących konkretnego urządzenia.

9.8.11. Udostępnianie obiektów danych

Android za pomocą BlobStoreManager umożliwia aplikacjom przesyłanie do systemu bloków danych, które mogą być udostępniane wybranemu zestawowi aplikacji.

Jeśli implementacje urządzeń obsługują udostępnione dane BLOB zgodnie z opisem w dokumentacji pakietu SDK:

• [C-1-1] NIE WOLNO udostępniać pakietów danych należących do aplikacji w zakresie wykraczającym poza ten, który użytkownik zamierzał zezwolić (tj. zakres domyślnego dostępu i inne tryby dostępu, które można określić za pomocą BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() lub BlobStoreManager.session#allowPublicAccess() NIE MOGĄ być modyfikowane). Implementacja referencyjna AOSP spełnia te wymagania.

• [C-1-2] NIE WOLNO wysyłać poza urządzenie ani udostępniać innym aplikacjom bezpiecznych skrótów bloków danych (które służą do kontrolowania dostępu).

9.8.12. Rozpoznawanie muzyki

Android za pomocą interfejsu System API MusicRecognitionManager obsługuje mechanizm, który umożliwia implementacjom urządzeń wysyłanie żądań rozpoznawania muzyki na podstawie nagrania audio i przekazywanie rozpoznawania muzyki do uprzywilejowanej aplikacji implementującej interfejs API MusicRecognitionService.

Jeśli implementacje urządzenia obejmują usługę, która implementuje interfejs System API MusicRecognitionManager lub dowolną usługę zastrzeżoną, która przesyła strumieniowo dane audio w sposób opisany powyżej:

• [C-1-1] MUSI sprawdzać, czy wywołujący MusicRecognitionManager ma uprawnienie MANAGE_MUSIC_RECOGNITION.

• [C-1-2] MUSI wymagać, aby jedna wstępnie zainstalowana aplikacja do rozpoznawania muzyki implementowała interfejs MusicRecognitionService.

• [C-1-3] NIE MOŻE zezwalać użytkownikom na zastępowanie usługi MusicRecognitionManagerService lub MusicRecognitionService aplikacją lub usługą, którą można zainstalować.

• [C-1-4] MUSI zapewnić, że gdy MusicRecognitionManagerService uzyskuje dostęp do nagrania audio i przekazuje je do aplikacji implementującej MusicRecognitionService, dostęp do dźwięku jest śledzony za pomocą wywołań AppOpsManager.noteOp / startOp.

Jeśli implementacje urządzeń MusicRecognitionManagerService lub MusicRecognitionService przechowują zarejestrowane dane audio:

• [C-2-1] NIE WOLNO przechowywać na dysku żadnych surowych danych audio ani odcisków audio, ani w pamięci przez okres dłuższy niż 14 dni.

• [C-2-2] NIE WOLNO udostępniać takich danych poza domeną MusicRecognitionService, chyba że użytkownik za każdym razem wyrazi na to wyraźną zgodę użytkownika.

9.8.13. SensorPrivacyManager

Jeśli implementacje urządzenia zapewniają użytkownikowi programową afordancję do wyłączenia wejścia z aparatu lub mikrofonu w ramach implementacji urządzenia:

• [C-1-1] MUSI zwracać wartość „true” w przypadku odpowiedniej metody interfejsu API supportsSensorToggle().

• [C-1-2] MUSI, gdy aplikacja próbuje uzyskać dostęp do zablokowanego mikrofonu lub aparatu, wyświetlać użytkownikowi nieusuwalny element interfejsu, który wyraźnie wskazuje, że czujnik jest zablokowany i wymaga podjęcia decyzji o dalszym blokowaniu lub odblokowaniu zgodnie z implementacją AOSP, która spełnia to wymaganie.

• [C-1-3] MUSI przekazywać do aplikacji tylko puste (lub fałszywe) dane z kamery i dźwięku oraz nie zgłaszać kodu błędu z powodu niewłączenia przez użytkownika kamery ani mikrofonu za pomocą elementu interfejsu użytkownika przedstawionego zgodnie z [C-1-2] powyżej.

9.8.14. Nie dotyczy

9.8.16. Ciągłe dane audio i z kamery

Jeśli implementacje urządzeń rejestrują jakiekolwiek dane w sposób opisany w sekcji 9.8.2 lub sekcji 9.8.6 i jeśli takie implementacje korzystają z danych audio uzyskanych w tle (w sposób ciągły) za pomocą interfejsów API AudioRecord, SoundTrigger lub innych interfejsów API audio LUB z danych z kamery uzyskanych w tle (w sposób ciągły) za pomocą interfejsu API CameraManager lub innych interfejsów API kamery, to:

• [C-0-1] MUSI wymuszać wyświetlanie odpowiedniego wskaźnika (aparatu lub mikrofonu zgodnie z sekcją 9.8.2 Nagrywanie), chyba że:

  • Dostęp ten jest realizowany w ramach implementacji w trybie piaskownicy (patrz sekcja 9.8.15 Implementacja interfejsu API w trybie piaskownicy) za pomocą pakietu pełniącego jedną lub więcej z tych ról: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence lub System Visual Intelligence.

  • Dostęp odbywa się w piaskownicy, która jest wdrażana i egzekwowana za pomocą mechanizmów w AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).

  • Dostęp do dźwięku jest uzyskiwany w celach pomocniczych przez aplikację Asystent cyfrowy, która jako źródło dźwięku podaje SOURCE_HOTWORD.

  • Dostęp jest realizowany przez system i wdrażany za pomocą kodu open source.

• [C-SR-1] Zdecydowanie zaleca się, aby w przypadku każdej funkcji wykorzystującej takie dane wymagać zgody użytkownika i aby była ona domyślnie wyłączona.

• [C-SR-2] Zdecydowanie zalecamy stosowanie tych samych zasad (tj. przestrzeganie ograniczeń opisanych w sekcjach 9.8.2 Nagrywanie, 9.8.6 Dane na poziomie systemu operacyjnego i dane otoczenia, 9.8.15 Implementacje interfejsu API w piaskownicy oraz 9.8.16 Ciągłe dane audio i z aparatu) w przypadku danych z aparatu pochodzących z zdalnego urządzenia do noszenia.

Jeśli implementacje urządzeń otrzymują dane z kamery lub mikrofonu z zdalnego urządzenia do noszenia, a dostęp do tych danych w niezaszyfrowanej formie jest możliwy poza systemem operacyjnym Android, implementacją w piaskownicy lub funkcją w piaskownicy utworzoną przez WearableSensingManager:

• [C-1-1] MUSI poinformować zdalne urządzenie do noszenia o wyświetleniu na nim dodatkowego wskaźnika.

Jeśli urządzenia umożliwiają korzystanie z aplikacji Asystenta cyfrowego bez przypisanego słowa kluczowego (np. obsługują ogólne zapytania użytkowników lub analizują obecność użytkownika za pomocą kamery):

• [C-2-1] MUSI zapewnić, że takie wdrożenie jest dostarczane przez pakiet pełniący rolę android.app.role.ASSISTANT.

• [C-2-2] MUSI dopilnować, aby implementacja korzystała z interfejsów API Androida HotwordDetectionServicelub VisualQueryDetectionService.

9.8.17. Dane telemetryczne

Android przechowuje logi systemowe i logi aplikacji przy użyciu interfejsów StatsLog API. Tymi logami zarządza się za pomocą interfejsów API StatsManager, z których mogą korzystać aplikacje systemowe z podwyższonymi uprawnieniami.

Usługa StatsManager umożliwia też zbieranie z urządzeń danych sklasyfikowanych jako wrażliwe pod względem prywatności za pomocą mechanizmu ochrony prywatności. W szczególności interfejs APIStatsManager::query umożliwia wysyłanie zapytań dotyczących kategorii ograniczonych danychzdefiniowanych w StatsLog.

Każda implementacja, która wysyła zapytania i zbiera ograniczone dane z interfejsu StatsManager:

• [C-0-1] MUSI być jedyną aplikacją/implementacją na urządzeniu i mieć uprawnienie READ_RESTRICTED_STATS.

• [C-0-2] MUSI wysyłać dane telemetryczne i dziennik urządzenia za pomocą mechanizmu chroniącego prywatność. Mechanizm chroniący prywatność jest zdefiniowany jako „mechanizm, który umożliwia tylko analizę zbiorczą i uniemożliwia dopasowywanie zarejestrowanych zdarzeń lub uzyskanych wyników do poszczególnych użytkowników”, aby zapobiec możliwości wglądu w dane poszczególnych użytkowników (np. zaimplementowany przy użyciu technologii prywatności różnicowej, takiej jak RAPPOR).

• [C-0-3] NIE WOLNO powiązywać takich danych z tożsamością użytkownika (np. z kontem) na urządzeniu.

• [C-0-4] NIE WOLNO udostępniać takich danych innym komponentom systemu operacyjnego, które nie spełniają wymagań określonych w bieżącej sekcji (9.8.17. Dane telemetryczne).

• [C-0-5] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania zbierania, wykorzystywania i udostępniania danych telemetrycznych z zachowaniem prywatności.

• [C-0-6] MUSI udostępniać użytkownikowi możliwość usunięcia danych zbieranych przez implementację, jeśli są one w jakiejkolwiek formie przechowywane na urządzeniu. Jeśli użytkownik zdecyduje się usunąć dane, MUSI usunąć wszystkie dane aktualnie przechowywane na urządzeniu.

• [C-0-7] MUSI ujawnić implementację protokołu chroniącego prywatność w repozytorium open source.

• [C-0-8] W tej sekcji MUSI egzekwować zasady dotyczące ruchu wychodzącego danych, aby ograniczać zbieranie danych w kategoriach danych objętych ograniczeniami zdefiniowanych w StatsLog.

9.8.18. Ochrona prywatności w przypadku funkcji agentowych

9.9. Szyfrowanie danych przechowywanych

Wszystkie urządzenia MUSZĄ spełniać wymagania sekcji 9.9.1. Urządzenia, które zostały wprowadzone na rynek z poziomem API wcześniejszym niż ten, który jest opisany w tym dokumencie, są zwolnione z wymagań sekcji 9.9.2 i 9.9.3. Zamiast tego MUSZĄ spełniać wymagania sekcji 9.9 dokumentu Android Compatibility Definition odpowiadające poziomowi API, z którym urządzenie zostało wprowadzone na rynek.

9.9.1. Bezpośredni rozruch

Implementacje urządzeń:

• [C-0-1] MUSZĄ implementować interfejsy API trybu bezpośredniego rozruchu, nawet jeśli nie obsługują szyfrowania pamięci.

• [C-0-2] Intencje ACTION_LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED MUSZĄ być nadal rozgłaszane, aby sygnalizować aplikacjom obsługującym bezpośrednie uruchamianie, że lokalizacje pamięci zaszyfrowanej na urządzeniu (DE) i zaszyfrowanej za pomocą danych logowania (CE) są dostępne dla użytkownika.

9.9.2. Wymagania dotyczące szyfrowania

Implementacje urządzeń:

• [C-0-1] MUSI szyfrować prywatne dane aplikacji (partycja /data), a także partycję pamięci współdzielonej aplikacji (partycja /sdcard), jeśli jest ona stałą, nieusuwalną częścią urządzenia.
• [C-0-2] MUSI domyślnie włączać szyfrowanie pamięci danych, gdy użytkownik zakończy wstępną konfigurację.

• [C-0-3] MUSI spełniać powyższe wymagania dotyczące szyfrowania danych przechowywanych przez wdrożenie jednej z tych 2 metod szyfrowania:

  • szyfrowanie oparte na plikach (FBE) i szyfrowanie metadanych zgodnie z opisem w sekcji 9.9.3.1.
  • Szyfrowanie na poziomie bloku dla poszczególnych użytkowników, jak opisano w sekcji 9.9.3.2.

9.9.3. Metody szyfrowania

Jeśli implementacje urządzeń są szyfrowane:

• [C-1-1] MUSI uruchamiać się bez proszenia użytkownika o podanie danych logowania i umożliwiać aplikacjom obsługującym bezpośrednie uruchamianie dostęp do pamięci zaszyfrowanej na urządzeniu (DE) po wyemitowaniu komunikatu ACTION_LOCKED_BOOT_COMPLETED.

• [C-1-2] NIE MOŻE zezwalać na dostęp do zaszyfrowanego miejsca na dane logowania (CE), dopóki nie zostaną spełnione oba te warunki:

  • Użytkownik odblokowuje urządzenie za pomocą podstawowej metody uwierzytelniania (np. hasła, wzoru lub kodu PIN).
  • Wiadomość ACTION_USER_UNLOCKED zostanie rozesłana.

• [C-1-13] NIE MOŻE oferować żadnej metody odblokowywania pamięci chronionej przez CE bez danych logowania podanych przez użytkownika, zarejestrowanego klucza depozytowego lub implementacji wznawiania po ponownym uruchomieniu spełniającej wymagania określone w sekcji 9.9.4.

• [C-1-4] MUSI korzystać z weryfikacji podczas uruchamiania.

9.9.3.1. Szyfrowanie oparte na plikach z szyfrowaniem metadanych

Jeśli implementacje urządzeń korzystają z szyfrowania opartego na plikach z szyfrowaniem metadanych:

• [C-1-5] MUSZĄ szyfrować zawartość plików i metadane systemu plików za pomocą algorytmu AES-256-XTS lub Adiantum. AES-256-XTS to standard Advanced Encryption Standard z 256-bitowym kluczem szyfrującym, działający w trybie XTS. Pełna długość klucza wynosi 512 bitów. Adiantum to Adiantum-XChaCha12-AES, zgodnie ze specyfikacją na stronie https://github.com/google/adiantum. Metadane systemu plików to dane takie jak rozmiary plików, własność, tryby i atrybuty rozszerzone (xattrs).
• [C-1-6] MUSI szyfrować nazwy plików za pomocą AES-256-CBC-CTS, AES-256-HCTR2 lub Adiantum.
• [C-1-12] Jeśli urządzenie ma instrukcje Advanced Encryption Standard (AES) (np. rozszerzenia kryptograficzne ARMv8 na urządzeniach z procesorem ARM lub AES-NI na urządzeniach z procesorem x86), należy używać opcji opartych na AES wymienionych powyżej w przypadku szyfrowania nazwy pliku, zawartości pliku i metadanych systemu plików, a nie Adiantum.
• [C-1-13] MUSI używać kryptograficznie silnej i nieodwracalnej funkcji derywacji klucza (np. HKDF-SHA512) do pozyskiwania wszelkich potrzebnych podkluczy (np. kluczy do poszczególnych plików) z kluczy CE i DE. „Kryptograficznie silna i nieodwracalna” oznacza, że funkcja derywacji klucza ma siłę zabezpieczeń co najmniej 256 bitów i działa jako rodzina funkcji pseudolosowych w odniesieniu do danych wejściowych.
• [C-1-14] NIE WOLNO używać tych samych kluczy ani podkluczy szyfrowania opartego na plikach (FBE) do różnych celów kryptograficznych (np. zarówno do szyfrowania, jak i do wyprowadzania kluczy, lub do dwóch różnych algorytmów szyfrowania).
• [C-1-15] MUSI zapewnić, że wszystkie nieusunięte bloki zaszyfrowanej zawartości pliku w pamięci trwałej zostały zaszyfrowane za pomocą kombinacji klucza szyfrowania i wektora inicjującego (IV), które zależą zarówno od pliku, jak i od przesunięcia w pliku. Dodatkowo wszystkie takie kombinacje MUSZĄ być różne, z wyjątkiem sytuacji, gdy szyfrowanie jest wykonywane przy użyciu sprzętu do szyfrowania wbudowanego, który obsługuje tylko długość wektora inicjującego wynoszącą 32 bity.
• [C-1-16] MUSI zapewnić, że wszystkie nieusunięte zaszyfrowane nazwy plików na trwałej pamięci masowej w różnych katalogach zostały zaszyfrowane przy użyciu różnych kombinacji klucza szyfrującego i wektora inicjującego (IV).

• [C-1-17] MUSI zapewnić, że wszystkie zaszyfrowane bloki metadanych systemu plików na pamięci trwałej zostały zaszyfrowane przy użyciu różnych kombinacji klucza szyfrowania i wektora inicjującego (IV).

• Klucze chroniące obszary pamięci CE i DE oraz metadane systemu plików:

  • [C-1-7] MUSI być kryptograficznie powiązany z magazynem kluczy wspieranym sprzętowo. Ten magazyn kluczy MUSI być powiązany z weryfikacją podczas uruchamiania i sprzętowym źródłem zaufania urządzenia.
  • [C-1-8] Klucze CE MUSZĄ być powiązane z danymi logowania do ekranu blokady użytkownika.
  • [C-1-9] Klucze CE MUSZĄ być powiązane z hasłem domyślnym, jeśli użytkownik nie określił danych logowania do ekranu blokady.
  • [C-1-10] MUSZĄ być unikalne i różne, czyli klucze CE lub DE żadnego użytkownika nie mogą być takie same jak klucze CE lub DE innego użytkownika.
  • [C-1-11] MUSI używać obowiązkowo obsługiwanych szyfrów, długości kluczy i trybów.
  • [C-1-12] MUSI zostać bezpiecznie usunięty podczas odblokowywania i blokowania programu rozruchowego, zgodnie z opisem tutaj.

• POWINNY być przystosowane do bezpośredniego uruchamiania wstępnie zainstalowane aplikacje podstawowe (np. Alarm, Telefon, Messenger).

Projekt Android Open Source udostępnia preferowaną implementację szyfrowania opartego na plikach, która korzysta z funkcji szyfrowania „fscrypt” jądra Linuksa, oraz implementację szyfrowania metadanych, która korzysta z funkcji „dm-default-key” jądra Linuksa.

9.9.3.2. Szyfrowanie na poziomie bloków dla poszczególnych użytkowników

Jeśli implementacje urządzeń korzystają z szyfrowania na poziomie bloku dla poszczególnych użytkowników:

• [C-1-1] MUSI obsługiwać wielu użytkowników zgodnie z opisem w sekcji 9.5.
• [C-1-2] MUSI udostępniać partycje dla poszczególnych użytkowników, korzystając z partycji surowych lub woluminów logicznych.
• [C-1-3] MUSI używać unikalnych i odrębnych kluczy szyfrowania dla każdego użytkownika do szyfrowania bazowych urządzeń blokowych.

• [C-1-4] MUSI używać AES-256-XTS do szyfrowania na poziomie bloku partycji użytkownika.

• Klucze chroniące zaszyfrowane na poziomie bloku urządzenia poszczególnych użytkowników:

  • [C-1-5] MUSI być kryptograficznie powiązany z magazynem kluczy wspieranym sprzętowo. Ten magazyn kluczy MUSI być powiązany z weryfikacją podczas uruchamiania i sprzętowym źródłem zaufania urządzenia.
  • [C-1-6] MUSI być powiązany z odpowiednimi danymi logowania użytkownika na ekranie blokady.

Szyfrowanie na poziomie bloku dla poszczególnych użytkowników można wdrożyć za pomocą funkcji „dm-crypt” jądra systemu Linux na partycjach poszczególnych użytkowników.

9.9.4. Wznów po ponownym uruchomieniu

Funkcja Wznów po ponownym uruchomieniu umożliwia odblokowanie pamięci CE wszystkich aplikacji, w tym tych, które nie obsługują jeszcze bezpośredniego uruchamiania, po ponownym uruchomieniu zainicjowanym przez aktualizację OTA. Ta funkcja umożliwia użytkownikom otrzymywanie powiadomień z zainstalowanych aplikacji po ponownym uruchomieniu urządzenia.

Implementacja funkcji wznawiania po ponownym uruchomieniu musi nadal zapewniać, że gdy urządzenie trafi w ręce osoby atakującej, odzyskanie przez nią zaszyfrowanych danych użytkownika będzie niezwykle trudne, nawet jeśli urządzenie jest włączone, pamięć CE jest odblokowana, a użytkownik odblokował urządzenie po otrzymaniu aktualizacji OTA. W przypadku odporności na ataki wewnętrzne zakładamy też, że atakujący uzyskuje dostęp do kluczy kryptograficznych do podpisywania transmisji.

Więcej szczegółów:

• [C-0-1] Pamięć CE NIE MOŻE być odczytywana nawet przez osobę przeprowadzającą atak, która ma fizyczny dostęp do urządzenia i ma te możliwości oraz ograniczenia:

  • Może używać klucza podpisywania dowolnego dostawcy lub firmy do podpisywania dowolnych wiadomości.
  • Może spowodować otrzymanie przez urządzenie aktualizacji OTA.
  • Może modyfikować działanie dowolnego sprzętu (AP, pamięci flash itp.) z wyjątkiem przypadków opisanych poniżej, ale taka modyfikacja wiąże się z co najmniej godzinnym opóźnieniem i cyklem zasilania, który niszczy zawartość pamięci RAM.
  • Nie można modyfikować działania sprzętu odpornego na manipulacje (np. Titan M).
  • Nie można odczytać pamięci RAM urządzenia na żywo.
  • Nie można uzyskać danych logowania użytkownika (kodu PIN, wzoru lub hasła) ani w inny sposób spowodować ich wpisania.

Na przykład implementacja urządzenia, która jest zgodna ze wszystkimi opisami znajdującymi się tutaj, będzie zgodna z [C-0-1].

9.10. Integralność urządzenia

Poniższe wymagania zapewniają przejrzystość stanu integralności urządzenia. Implementacje urządzeń:

• [C-0-1] MUSI prawidłowo raportować za pomocą metody interfejsu System API PersistentDataBlockManager.getFlashLockState(), czy stan programu rozruchowego umożliwia wgranie obrazu systemu.

• [C-0-2] MUSI obsługiwać weryfikację podczas uruchamiania w celu zapewnienia integralności urządzenia.

Jeśli urządzenia zostały już wprowadzone na rynek bez obsługi weryfikacji podczas uruchamiania w starszej wersji Androida i nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z tego wymagania.

Weryfikacja podczas uruchamiania to funkcja, która gwarantuje integralność oprogramowania urządzenia. Jeśli implementacje urządzeń obsługują tę funkcję:

• [C-1-1] MUSI zadeklarować flagę funkcji platformy android.software.verified_boot.
• [C-1-2] MUSI przeprowadzać weryfikację przy każdej sekwencji uruchamiania.
• [C-1-3] MUSI rozpocząć weryfikację od niezmiennego klucza sprzętowego, który jest źródłem zaufania, i przejść aż do partycji systemowej.
• [C-1-4] MUSI wdrażać każdy etap weryfikacji, aby sprawdzać integralność i autentyczność wszystkich bajtów na następnym etapie przed wykonaniem kodu na tym etapie.
• [C-1-5] MUSI używać algorytmów weryfikacji o sile co najmniej takiej, jak obecne zalecenia NIST dotyczące algorytmów szyfrowania (SHA-256) i rozmiarów kluczy publicznych (RSA-2048).
• [C-1-6] NIE MOŻE zezwalać na ukończenie rozruchu, gdy weryfikacja systemu zakończy się niepowodzeniem, chyba że użytkownik wyrazi zgodę na podjęcie próby rozruchu, w którym to przypadku dane z niezweryfikowanych bloków pamięci NIE MOGĄ być używane.
• [C-1-7] NIE MOŻE zezwalać na modyfikowanie zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokował program rozruchowy.
• [C-1-8] MUSI używać pamięci odpornej na manipulacje: do przechowywania informacji o tym, czy program rozruchowy jest odblokowany. Oznacza to, że program rozruchowy może wykryć, czy pamięć została naruszona z poziomu Androida.
• [C-1-9] MUSI wyświetlać użytkownikowi komunikat podczas korzystania z urządzenia i wymagać fizycznego potwierdzenia przed zezwoleniem na przejście z trybu blokady programu rozruchowego do trybu odblokowanego programu rozruchowego.
• [C-1-10] MUSI wdrażać ochronę przed wycofaniem zmian w przypadku partycji używanych przez Androida (np. partycji rozruchowych i systemowych) oraz używać pamięci odpornej na manipulacje do przechowywania metadanych używanych do określania minimalnej dopuszczalnej wersji systemu operacyjnego.

• [C-1-11] MUSI bezpiecznie usuwać wszystkie dane użytkownika podczas odblokowywania i blokowania programu rozruchowego zgodnie z sekcją 9.12. Usuwanie danych” (w tym partycji danych użytkownika i wszystkich obszarów pamięci NVRAM).

• [C-1-14] MUSI weryfikować podpis co najmniej raz podczas uruchamiania w przypadku pakietów z białej listy, które są wymienione jako require-strict-signature w konfiguracji systemu.

• [C-SR-2] Zdecydowanie zaleca się weryfikowanie wszystkich plików APK aplikacji z podwyższonymi uprawnieniami za pomocą łańcucha zaufania zakorzenionego w partycjach chronionych przez weryfikację podczas uruchamiania.

• [C-SR-3] Zdecydowanie zalecamy weryfikowanie wszystkich artefaktów wykonywalnych wczytywanych przez aplikację z uprawnieniami z zewnątrz pliku APK (np. dynamicznie wczytywanego lub skompilowanego kodu) przed ich uruchomieniem lub zdecydowanie zalecamy, aby w ogóle ich nie uruchamiać.

• POWINNO wdrażać ochronę przed wycofaniem zmian w przypadku każdego komponentu z trwałym oprogramowaniem sprzętowym (np. modemu, aparatu) i POWINNO używać pamięci odpornej na manipulacje do przechowywania metadanych używanych do określania minimalnej dopuszczalnej wersji.

Projekt Android Open Source Project udostępnia preferowaną implementację tej funkcji w repozytorium external/avb/, którą można zintegrować z programem rozruchowym używanym do wczytywania Androida.

Jeśli implementacje urządzeń mają możliwość weryfikowania zawartości pliku na poziomie poszczególnych stron, to:

• [C-2-1] obsługuje kryptograficzne weryfikowanie zawartości pliku bez odczytywania całego pliku.

• [C-2-2] NIE MOŻE zezwalać na żądania odczytu chronionego pliku, jeśli odczytana treść nie została zweryfikowana zgodnie z wymaganiem [C-2-1] powyżej.

• [C-2-4] MUSI zwracać sumę kontrolną pliku w czasie O(1) w przypadku włączonych plików.

Jeśli urządzenia zostały już wprowadzone na rynek bez możliwości weryfikacji zawartości pliku za pomocą zaufanego klucza w starszej wersji Androida i nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemu, MOGĄ zostać zwolnione z tego wymagania. Projekt Android Open Source udostępnia preferowaną implementację tej funkcji opartą na funkcji fs-verity jądra Linuksa.

9.11. Klucze i dane logowania

System Android Keystore umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i używanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub interfejsu Keystore API. Implementacje urządzeń:

• [C-0-1] MUSI umożliwiać importowanie lub generowanie co najmniej 8192 kluczy.

• [C-0-2] Uwierzytelnianie na ekranie blokady MUSI uwzględniać odstęp czasu między nieudanymi próbami. Jeśli n to liczba nieudanych prób, przedział czasu MUSI wynosić co najmniej 30 sekund w przypadku 9 < n < 30. W przypadku n > 29 wartość przedziału czasu MUSI wynosić co najmniej 30*2^floor((n-30)/10) sekund lub co najmniej 24 godziny, w zależności od tego, która z tych wartości jest mniejsza.

• NIE POWINNO ograniczać liczby kluczy, które można wygenerować.

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady:

• [C-1-1] MUSI tworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.

• [C-1-3] MUSI przeprowadzać uwierzytelnianie na ekranie blokady w izolowanym środowisku wykonawczym i tylko w przypadku powodzenia zezwalać na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób, który umożliwia uwierzytelnianie na ekranie blokady tylko w izolowanym środowisku wykonawczym. Projekt Android Open Source Project udostępnia warstwę abstrakcji sprzętowej (HAL) Gatekeeper i Trusty, które mogą być używane do spełnienia tego wymagania.

• [C-1-4] MUSI obsługiwać atestowanie klucza, w którym klucz podpisu atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania zaświadczeń NIE MOGĄ być używane jako trwałe identyfikatory urządzenia.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na wcześniejszej wersji Androida, takie urządzenie jest zwolnione z wymogu posiadania magazynu kluczy opartego na izolowanym środowisku wykonawczym i obsługi atestowania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy opartego na izolowanym środowisku wykonawczym.

• [C-1-5] MUSI umożliwiać użytkownikowi wybór czasu oczekiwania na przejście z odblokowanego do zablokowanego stanu, przy czym minimalny dopuszczalny czas oczekiwania wynosi 15 sekund. Urządzenia samochodowe, które blokują ekran po wyłączeniu jednostki głównej lub przełączeniu użytkownika, NIE MOGĄ mieć konfiguracji czasu uśpienia.

• [C-1-6] MUSI obsługiwać IKeymasterDevice w wersji 3.0 lub nowszej LUB IKeyMintDevice w wersji 1 lub nowszej.

9.11.1. Blokada zabezpieczająca ekranu, uwierzytelnianie i urządzenia wirtualne

Implementacja AOSP jest zgodna z wielopoziomowym modelem uwierzytelniania, w którym podstawowe uwierzytelnianie oparte na czynniku wiedzy może być wspierane przez drugorzędne silne dane biometryczne lub słabsze metody trzeciorzędne.

Implementacje urządzeń:

• [C-SR-1] Zdecydowanie zaleca się ustawienie tylko jednej z tych metod jako podstawowej metody uwierzytelniania:

  • numeryczny kod PIN,
  • hasło alfanumeryczne;
  • wzorzec przesunięcia na siatce składającej się z dokładnie 9 kropek (3 x 3).

  Pamiętaj, że powyższe metody uwierzytelniania są w tym dokumencie określane jako zalecane podstawowe metody uwierzytelniania.

• [C-0-1] MUSI ograniczać liczbę nieudanych prób uwierzytelniania podstawowego.

• [C-SR-5] Zdecydowanie zaleca się wdrożenie górnego limitu 20 nieudanych prób uwierzytelniania podstawowego. Jeśli użytkownicy wyrażą zgodę i włączą tę funkcję, po przekroczeniu limitu nieudanych prób uwierzytelniania podstawowego należy przeprowadzić „przywracanie danych fabrycznych”.

Jeśli implementacje urządzeń ustawiają numeryczny kod PIN jako zalecaną podstawową metodę uwierzytelniania:

• [C-SR-6] Zdecydowanie zalecamy, aby kod PIN miał co najmniej 6 cyfr lub 20-bitową entropię.

• [C-SR-7] Zdecydowanie NIE ZALECA SIĘ zezwalania na automatyczne wpisywanie kodu PIN o długości mniejszej niż 6 cyfr bez interakcji użytkownika, aby uniknąć ujawnienia długości kodu PIN.

Jeśli implementacje urządzeń dodają lub modyfikują zalecane podstawowe metody uwierzytelniania i używają nowej metody uwierzytelniania jako bezpiecznego sposobu blokowania ekranu, nowa metoda uwierzytelniania:

• [C-2-1] MUSI być metodą uwierzytelniania użytkownika opisaną w sekcji Wymaganie uwierzytelniania użytkownika w celu użycia klucza.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania w celu odblokowania ekranu blokady na podstawie znanego sekretu i używają nowej metody uwierzytelniania, która ma być traktowana jako bezpieczny sposób blokowania ekranu:

• [C-3-1] Entropia najkrótszej dozwolonej długości danych wejściowych MUSI być większa niż 10 bitów.

• [C-3-2] Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18 bitów.

• [C-3-3] Nowa metoda uwierzytelniania NIE MOŻE zastępować żadnej z zalecanych podstawowych metod uwierzytelniania (tj. kodu PIN, wzoru lub hasła) zaimplementowanych i udostępnianych w AOSP.

• [C-3-4] Nowa metoda uwierzytelniania MUSI zostać wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasady dotyczące wymagań hasła za pomocą metody DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjną stałą złożoności niż PASSWORD_COMPLEXITY_NONE lub za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą niż PASSWORD_QUALITY_BIOMETRIC_WEAK.

• [C-3-5] Nowe metody uwierzytelniania MUSZĄ co 72 godziny lub rzadziej wracać do zalecanych podstawowych metod uwierzytelniania (tj. PIN-u, wzoru lub hasła) LUB wyraźnie informować użytkownika, że niektóre dane nie będą objęte kopią zapasową, aby zachować prywatność danych użytkownika.

Jeśli implementacje urządzeń dodają lub modyfikują zalecane podstawowe metody uwierzytelniania, aby odblokować ekran blokady, i używają nowej metody uwierzytelniania opartej na biometrii, która ma być traktowana jako bezpieczny sposób blokowania ekranu, nowa metoda:

• [C-4-1] MUSI spełniać wszystkie wymagania opisane w sekcji 7.3.10 dotyczące klasy 1 (wcześniej wygoda).

• [C-4-2] MUSI mieć mechanizm rezerwowy, który umożliwia korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania opartych na znanym sekrecie.

• [C-4-3] MUSI być wyłączona i umożliwiać odblokowanie ekranu tylko za pomocą zalecanego podstawowego uwierzytelniania, gdy aplikacja kontrolera zasad urządzenia (DPC) ustawi zasady funkcji blokady ekranu, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures() z dowolną z powiązanych flag biometrycznych (np. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE lub KEYGUARD_DISABLE_IRIS).

Jeśli metody uwierzytelniania biometrycznego nie spełniają wymagań klasy 3 (wcześniej silne) opisanych w sekcji 7.3.10:

• [C-5-1] Metody MUSZĄ być wyłączone, jeśli kontroler zasad dotyczących urządzeń (DPC) ustawił zasady jakości dotyczące wymagań związanych z hasłem za pomocą metody DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjnym przedziałem złożoności niż PASSWORD_COMPLEXITY_LOW lub za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_BIOMETRIC_WEAK.

• [C-5-2] Użytkownik MUSI zostać poproszony o podanie zalecanego podstawowego sposobu uwierzytelniania (np. kodu PIN, wzoru lub hasła) zgodnie z wymaganiami [C-1-7] i [C-1-8] w sekcji 7.3.10.

• [C-5-3] Metody NIE MOGĄ być traktowane jako bezpieczny ekran blokady i MUSZĄ spełniać wymagania, które zaczynają się od C-8 w sekcji poniżej.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania w celu odblokowania ekranu blokady, a nowa metoda uwierzytelniania jest oparta na tokenie fizycznym lub lokalizacji:

• [C-6-1] Muszą mieć mechanizm rezerwowy, który umożliwia korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania opartych na znanym sekrecie i spełniających wymagania dotyczące bezpiecznego ekranu blokady.

• [C-6-2] Nowa metoda MUSI być wyłączona i musi zezwalać na odblokowanie ekranu tylko za pomocą jednej z zalecanych podstawowych metod uwierzytelniania, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasadę z jednym z tych warunków:

  • Metoda DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS).

  • Metoda DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_NONE.

  • Metoda DevicePolicyManager.setRequiredPasswordComplexity() o bardziej restrykcyjnym przedziale złożoności niż PASSWORD_COMPLEXITY_NONE.

• [C-6-3] Użytkownik MUSI być proszony o użycie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru lub hasła) co najmniej raz na 4 godziny lub rzadziej. Jeśli token fizyczny spełnia wymagania dotyczące implementacji TrustAgent w C-X, zamiast tego obowiązują ograniczenia czasu oczekiwania określone w [C-9-5].

• [C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI spełniać ograniczenia wymienione poniżej w punkcie C-8.

Jeśli implementacje urządzeń mają bezpieczną blokadę ekranu i zawierają co najmniej jednego agenta zaufania, który implementuje TrustAgentService System API, to:

• [C-7-1] W menu ustawień i na ekranie blokady MUSI być wyraźnie widoczna informacja o tym, że blokowanie urządzenia jest odroczone lub że urządzenie można odblokować za pomocą agentów zaufania. Na przykład AOSP spełnia to wymaganie, wyświetlając opis tekstowy ustawień „Automatyczne blokowanie” i „Przycisk zasilania natychmiast blokuje” w menu ustawień oraz rozpoznawalną ikonę na ekranie blokady.

• [C-7-2] MUSI respektować i w pełni implementować wszystkie interfejsy API agenta zaufania w klasie DevicePolicyManager, takie jak stała KEYGUARD_DISABLE_TRUST_AGENTS.

• [C-7-3] NIE WOLNO w pełni implementować funkcji TrustAgentService.addEscrowToken() na urządzeniu, które jest używane jako główne urządzenie osobiste (np. urządzenie przenośne), ale MOŻNA w pełni implementować tę funkcję na urządzeniach, które są zwykle współdzielone (np. telewizor z Androidem lub urządzenie samochodowe).

• [C-7-4] MUSI szyfrować wszystkie zapisane tokeny dodane przez TrustAgentService.addEscrowToken().

• [C-7-5] NIE WOLNO przechowywać klucza szyfrującego ani tokena depozytowego na tym samym urządzeniu, na którym jest używany klucz. Na przykład klucz przechowywany na telefonie może odblokować konto użytkownika na telewizorze. W przypadku urządzeń samochodowych nie można przechowywać tokena depozytowego w żadnej części pojazdu.

• [C-7-6] MUSI poinformować użytkownika o konsekwencjach związanych z bezpieczeństwem przed włączeniem tokena depozytowego do odszyfrowania pamięci danych.

• [C-7-7] MUSI mieć mechanizm rezerwowy, który umożliwia korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania.

• [C-7-9] Użytkownik MUSI zostać poproszony o użycie jednej z zalecanych podstawowych metod uwierzytelniania (np.kodu PIN, wzoru lub hasła) zgodnie z opisem w punktach [C-1-7] i [C-1-8] w sekcji 7.3.10, chyba że bezpieczeństwo użytkownika (np. rozproszenie uwagi kierowcy) jest zagrożone.

• [C-7-10] NIE MOŻE być traktowany jako bezpieczny ekran blokady i MUSI spełniać ograniczenia wymienione w sekcji C-8 poniżej.

• [C-7-11] NIE MOŻE zezwalać na odblokowywanie urządzenia przez TrustAgents na głównych urządzeniach osobistych (np.telefonach komórkowych) i może ich używać tylko do utrzymywania odblokowanego urządzenia w stanie odblokowanym przez maksymalnie 4 godziny. Domyślna implementacja usługi TrustManagerService w AOSP spełnia to wymaganie.

• [C-7-12] MUSI używać szyfrowanego kanału komunikacji (np.UKEY2) do przekazywania tokena depozytowego z urządzenia pamięci masowej na urządzenie docelowe.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania w celu odblokowania ekranu blokady, który nie jest bezpiecznym ekranem blokady opisanym powyżej, i używają nowej metody uwierzytelniania do odblokowania ekranu blokady:

• [C-8-1] Nowa metoda MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasady jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_NONE lub za pomocą metody DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjną stałą złożoności niż PASSWORD_COMPLEXITY_NONE.

• [C-8-2] NIE WOLNO resetować liczników czasu wygaśnięcia hasła ustawionych przez DevicePolicyManager.setPasswordExpirationTimeout().

• [C-8-3] NIE WOLNO udostępniać interfejsu API do użytku przez aplikacje innych firm w celu zmiany stanu blokady.

Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych wirtualnych wyświetlaczy i nie obsługują powiązanych zdarzeń wejściowych, np. za pomocą VirtualDeviceManager, to:

• [C-9-1] MUSI blokować te dodatkowe wirtualne wyświetlacze, gdy domyślny wyświetlacz urządzenia jest zablokowany, i odblokowywać je, gdy domyślny wyświetlacz urządzenia jest odblokowany.

Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych wirtualnych wyświetlaczy i obsługują powiązane zdarzenia wejściowe, np. za pomocą VirtualDeviceManager:

• [C-10-1] MUSI obsługiwać oddzielne stany blokady dla każdego urządzenia wirtualnego

• [C-10-2] Wymaganie usunięte w Androidzie 16.

• [C-10-3] Wymaganie usunięte w Androidzie 16.

• [C-10-4] MUSI blokować wszystkie wyświetlacze, gdy użytkownik rozpoczyna blokadę, w tym za pomocą elementu interfejsu użytkownika wymaganego w przypadku urządzeń przenośnych (patrz sekcja 2.2.5[9.11/H-1-2]).

• [C-10-5] MUSI mieć oddzielne instancje urządzenia wirtualnego dla każdego użytkownika

• [C-10-6] MUSI wyłączyć strumieniowanie aplikacji, co jest sygnalizowane przez DevicePolicyManager.setNearbyAppStreamingPolicy.

• [C-10-7] Wymaganie usunięte w Androidzie 16.

• [C-10-11] MUSI wyłączyć interfejs uwierzytelniania na urządzeniach wirtualnych, w tym wprowadzanie czynnika wiedzy i prośbę o uwierzytelnianie biometryczne.

• [C-10-12] Wymaganie usunięte w Androidzie 16.

• [C-10-13] NIE MOŻE używać stanu blokowania urządzenia wirtualnego jako autoryzacji uwierzytelniania użytkownika w systemie Android Keystore. Zobacz KeyGenParameterSpec.Builder.setUserAuthentication*.

• [C-10-14] MUSI udostępniać użytkownikowi możliwość włączenia udostępniania schowka między urządzeniami przed udostępnieniem danych schowka między urządzeniami fizycznymi i wirtualnymi, jeśli urządzenie implementuje udostępniony schowek.

• [C-10-15] MUSI wyświetlać powiadomienia o dostępie do danych ze schowka zarówno na urządzeniu, z którego uzyskano dostęp, jak i na urządzeniu, z którego pochodzi schowek.

Jeśli implementacje urządzenia umożliwiają użytkownikowi przeniesienie podstawowego czynnika wiedzy uwierzytelniającej z urządzenia źródłowego na urządzenie docelowe, np. podczas początkowej konfiguracji urządzenia docelowego:

• [C-11-1] MUSI szyfrować czynnik wiedzy z gwarancjami ochrony podobnymi do tych opisanych w dokumencie Google Cloud Key Vault Service dotyczącym bezpieczeństwa podczas przesyłania czynnika wiedzy z urządzenia źródłowego na urządzenie docelowe w taki sposób, aby czynnik wiedzy nie mógł być zdalnie odszyfrowany ani użyty do zdalnego odblokowania żadnego z tych urządzeń.

• [C-11-2] MUSI na urządzeniu źródłowym poprosić użytkownika o potwierdzenie czynnika wiedzy urządzenia źródłowego przed przeniesieniem go na urządzenie docelowe.

• [C-11-3] MUSI na urządzeniu docelowym, na którym nie ma ustawionego podstawowego czynnika uwierzytelniania opartego na wiedzy, poprosić użytkownika o potwierdzenie przeniesionego czynnika opartego na wiedzy na urządzeniu docelowym, zanim ustawi ten czynnik jako podstawowy czynnik uwierzytelniania oparty na wiedzy na urządzeniu docelowym i zanim udostępni jakiekolwiek dane przeniesione z urządzenia źródłowego.

Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jednego agenta zaufania, który wywołuje interfejs API systemu z flagą FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, to:TrustAgentService.grantTrust()

• [C-12-1] MUSI wywoływać funkcję grantTrust() z odpowiednią flagą tylko wtedy, gdy jest połączony z znajdującym się w pobliżu urządzeniem fizycznym z własnym ekranem blokady i gdy użytkownik uwierzytelni swoją tożsamość na tym ekranie blokady. Urządzenia w pobliżu mogą używać mechanizmów wykrywania na nadgarstku lub wykrywania kontaktu z ciałem po jednorazowym odblokowaniu przez użytkownika, aby spełnić wymagania dotyczące uwierzytelniania użytkownika.

• [C-12-2] MUSI wprowadzać urządzenie w stan TrustState.TRUSTABLE, gdy ekran jest wyłączony (np. po naciśnięciu przycisku lub upłynięciu czasu wyświetlania), a usługa TrustAgent nie cofnęła zaufania. AOSP spełnia to wymaganie.

• [C-12-3] MUSI przenosić urządzenie ze stanu TrustState.TRUSTABLE do stanu TrustState.TRUSTED tylko wtedy, gdy TrustAgent nadal przyznaje zaufanie na podstawie wymagań określonych w [C-12-1].

.

• [C-12-5] Implementacje, które polegają na bezpiecznym i dokładnym pomiarze odległości w celu spełnienia wymagań [C-12-4], MUSZĄ korzystać z jednego z tych rozwiązań:

  • Implementacje wykorzystujące UWB:

    • MUSI spełniać wymagania dotyczące zgodności, certyfikacji, dokładności i kalibracji dla UWB opisane w sekcji 7.4.9.

    • MUSI używać jednego z trybów bezpieczeństwa P-STS wymienionych w sekcji 7.4.9.

  • Implementacje korzystające z technologii Wi-Fi Neighborhood Awareness Networking (NAN):

    • MUSI spełniać wymagania dotyczące dokładności określone w sekcji 2.2.1 [7.4.2.5/H-SR-1], używać pasma 160 MHz (lub wyższego) i postępować zgodnie z instrukcjami konfiguracji pomiarów podanymi w sekcji Kalibracja obecności.

    • MUSI używać bezpiecznego LTF zgodnie z definicją w standardzie IEEE 802.11az.

Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych wirtualnych wyświetlaczy i obsługują powiązane zdarzenia wejściowe, np. za pomocą VirtualDeviceManager, a wyświetlacze nie są oznaczone flagą VIRTUAL_DISPLAY_FLAG_SECURE, to:

• [C-13-8] MUSI blokować aktywności z atrybutem android:canDisplayOnRemoteDevices lub metadanymi android.activity.can_display_on_remote_devices ustawionymi na wartość false, aby nie można było ich uruchamiać na urządzeniu wirtualnym.

• [C-13-9] MUSI blokować aktywności, które nie włączają wyraźnie przesyłania strumieniowego i wskazują, że wyświetlają treści o charakterze kontrowersyjnym, w tym za pomocą SurfaceView#setSecure i FLAG_SECURE, przed uruchomieniem na urządzeniu wirtualnym.

Jeśli implementacje urządzeń obsługują oddzielne stany zasilania wyświetlacza za pomocą interfejsu DeviceStateManager ORAZ oddzielne stany blokady wyświetlacza za pomocą interfejsu KeyguardDisplayManager, to:

• [C-SR-2] Zdecydowanie zaleca się korzystanie z danych logowania spełniających wymagania określone w sekcji 9.11.1 lub z danych biometrycznych spełniających co najmniej wymagania klasy 1 określone w sekcji 7.3.10, aby umożliwić niezależne odblokowywanie od domyślnego wyświetlacza urządzenia.

• [C-SR-3] Zdecydowanie zaleca się ograniczenie odblokowywania oddzielnego wyświetlacza za pomocą zdefiniowanego czasu oczekiwania wyświetlacza.

• [C-SR-4] Zdecydowanie zaleca się umożliwienie użytkownikowi globalnego blokowania wszystkich wyświetlaczy za pomocą blokady z głównego urządzenia przenośnego.

9.11.2. StrongBox

System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w dedykowanym bezpiecznym procesorze oraz w opisanym powyżej odizolowanym środowisku wykonawczym. Taki dedykowany bezpieczny procesor nazywa się „StrongBox”. Wymagania C-1-3 do C-1-11 poniżej określają wymagania, które musi spełniać urządzenie, aby kwalifikować się jako StrongBox.

Implementacje urządzeń z dedykowanym bezpiecznym procesorem:

• [C-SR-1] Zdecydowanie zalecamy obsługę StrongBox. W przyszłej wersji StrongBox prawdopodobnie stanie się wymaganiem.

Jeśli implementacje urządzeń obsługują StrongBox:

• [C-1-1] MUSI deklarować FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] MUSI udostępniać dedykowany bezpieczny sprzęt, który jest używany do obsługi magazynu kluczy i bezpiecznego uwierzytelniania użytkownika. Dedykowany bezpieczny sprzęt może być też używany do innych celów.

• [C-1-3] MUSI mieć osobny procesor, który nie współdzieli pamięci podręcznej, pamięci DRAM, koprocesorów ani innych zasobów rdzenia z procesorem aplikacji.

• [C-1-4] MUSI zapewnić, że żadne urządzenia peryferyjne udostępniane AP nie mogą w żaden sposób zmieniać przetwarzania w StrongBox ani uzyskiwać z niego żadnych informacji. Punkt dostępu MOŻE wyłączyć lub zablokować dostęp do StrongBox.

• [C-1-5] MUSI mieć wewnętrzny zegar o rozsądnej dokładności (±10%), który jest odporny na manipulacje ze strony punktu dostępu.

• [C-1-6] MUSI mieć generator prawdziwych liczb losowych, który generuje nieprzewidywalne dane wyjściowe o rozkładzie jednostajnym.

• [C-1-7] MUSI być odporny na manipulacje, w tym na fizyczne włamanie i zakłócenia.

• [C-1-8] MUSI być odporny na ataki z użyciem kanałów bocznych, w tym na wyciek informacji przez kanały boczne związane z zasilaniem, czasem, promieniowaniem elektromagnetycznym i promieniowaniem cieplnym.

• [C-1-9] MUSI mieć bezpieczną pamięć, która zapewnia poufność, integralność, autentyczność, spójność i aktualność treści. Pamięci NIE WOLNO odczytywać ani zmieniać, z wyjątkiem sytuacji dozwolonych przez interfejsy API StrongBox.

Aby sprawdzić zgodność z wymaganiami [C-1-3]–[C-1-9], implementacje urządzeń:

• [C-1-10] MUSI zawierać sprzęt certyfikowany zgodnie z profilem ochrony układu scalonego BSI-CC-PP-0084-2014 lub BSI-CC-PP-0117-2022 lub oceniany przez akredytowane na poziomie krajowym laboratorium testowe z uwzględnieniem oceny podatności na ataki o wysokim potencjale zgodnie z dokumentem Common Criteria Application of Attack Potential to Smartcards.

• [C-1-11] MUSI zawierać oprogramowanie sprzętowe, które jest oceniane przez akredytowane na poziomie krajowym laboratorium testowe z uwzględnieniem oceny podatności na ataki o wysokim potencjale zgodnie z dokumentem Common Criteria Application of Attack Potential to Smartcards.

• [C-SR-2] Zdecydowanie zaleca się uwzględnienie sprzętu, który jest oceniany przy użyciu profilu ochrony, poziomu oceny bezpieczeństwa (EAL) 5, rozszerzonego o AVA_VAN.5. Certyfikat EAL 5 prawdopodobnie stanie się wymagany w przyszłej wersji.

• [C-SR-3] Zdecydowanie zaleca się zapewnienie odporności na ataki wewnętrzne (IAR), co oznacza, że osoba z dostępem do kluczy podpisywania oprogramowania układowego nie może utworzyć oprogramowania układowego, które powoduje wyciek informacji tajnych z StrongBox, obejście wymagań dotyczących bezpieczeństwa funkcjonalnego ani w inny sposób umożliwić dostęp do poufnych danych użytkownika. Zalecanym sposobem wdrożenia IAR jest zezwalanie na aktualizacje oprogramowania tylko wtedy, gdy hasło głównego użytkownika jest podawane za pomocą interfejsu HAL IAuthSecret.

9.11.3. Identity Credential

System poświadczeń tożsamości jest zdefiniowany i osiągany przez wdrożenie wszystkich interfejsów API w pakiecie android.security.identity.*. Te interfejsy API umożliwiają deweloperom aplikacji przechowywanie i pobieranie dokumentów tożsamości użytkowników. Implementacje urządzeń:

• [C-SR-1] są ZDECYDOWANIE ZALECANE do wdrożenia systemu poświadczeń tożsamości.

Jeśli implementacje urządzeń implementują system danych uwierzytelniających tożsamość:

• [C-1-1] MUSI zwracać wartość inną niż null w przypadku metody IdentityCredentialStore#getInstance().

• [C-1-2] MUSI wdrażać system poświadczeń tożsamości (np. interfejsy API android.security.identity.*) za pomocą kodu komunikującego się z zaufaną aplikacją w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i powyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego środowiska izolowanego, w tym DMA.

• [C-1-3] Operacje kryptograficzne potrzebne do wdrożenia systemu Identity Credential System (np. interfejsy API android.security.identity.*) MUSZĄ być wykonywane w całości w zaufanej aplikacji, a materiały klucza prywatnego NIE MOGĄ nigdy opuszczać odizolowanego środowiska wykonawczego, chyba że jest to wyraźnie wymagane przez interfejsy API wyższego poziomu (np. metodę createEphemeralKeyPair()).

• [C-1-4] Zaufana aplikacja MUSI być zaimplementowana w taki sposób, aby jej właściwości związane z bezpieczeństwem nie były naruszane (np. dane logowania nie są udostępniane, chyba że zostaną spełnione warunki kontroli dostępu, a kody MAC nie mogą być generowane dla dowolnych danych), nawet jeśli Android działa nieprawidłowo lub został naruszony.

Projekt Android Open Source Project udostępnia referencyjną implementację zaufanej aplikacji (libeic), której można użyć do wdrożenia systemu danych uwierzytelniających tożsamość.

9.12. Usunięcie danych

Wszystkie implementacje urządzeń:

• [C-0-1] MUSI udostępniać użytkownikom mechanizm przywracania danych fabrycznych.
• [C-0-2] MUSI usuwać wszystkie dane z systemu plików danych użytkownika podczas wykonywania „przywracania danych fabrycznych”.
• [C-0-3] MUSI usuwać dane w sposób zgodny z odpowiednimi standardami branżowymi, takimi jak NIST SP800-88, podczas wykonywania „przywracania ustawień fabrycznych”.
• [C-0-4] MUSI wywoływać powyższy proces „przywracania danych fabrycznych”, gdy interfejs API DevicePolicyManager.wipeData() jest wywoływany przez aplikację Kontroler zasad na urządzeniu użytkownika podstawowego.
• MOŻE udostępniać opcję szybkiego usuwania danych, która przeprowadza tylko logiczne usuwanie danych.

9.13. Tryb bezpiecznego rozruchu

Android udostępnia tryb bezpiecznego rozruchu, który umożliwia użytkownikom uruchamianie urządzenia w trybie, w którym działają tylko wstępnie zainstalowane aplikacje systemowe, a wszystkie aplikacje innych firm są wyłączone. Ten tryb, zwany „trybem bezpiecznego rozruchu”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.

Implementacje urządzeń:

• [C-SR-1] Zdecydowanie zalecamy wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacje urządzeń obsługują tryb bezpiecznego uruchamiania:

• [C-1-1] MUSI udostępniać użytkownikowi opcję przejścia do trybu bezpiecznego rozruchu w sposób, który nie jest przerywany przez aplikacje innych firm zainstalowane na urządzeniu, z wyjątkiem sytuacji, gdy aplikacja innej firmy jest kontrolerem zasad dotyczących urządzenia i ustawiła flagę UserManager.DISALLOW_SAFE_BOOT na wartość „prawda”.

• [C-1-2] MUSI umożliwiać użytkownikowi odinstalowanie dowolnych aplikacji innych firm w trybie awaryjnym.

• POWINIEN udostępniać użytkownikowi opcję przejścia do trybu awaryjnego z menu rozruchu za pomocą przepływu pracy innego niż w przypadku normalnego rozruchu.

9.14. Odizolowanie systemu pojazdu samochodowego

Urządzenia z Androidem Automotive powinny wymieniać dane z kluczowymi podsystemami pojazdu za pomocą interfejsu HAL pojazdu, aby wysyłać i odbierać wiadomości w sieciach pojazdu, takich jak magistrala CAN.

Wymianę danych można zabezpieczyć, wdrażając funkcje bezpieczeństwa poniżej warstw platformy Android, aby zapobiec złośliwym lub niezamierzonym interakcjom z tymi podsystemami.

9.15. Abonamenty

„Plany subskrypcji” to szczegóły planu rozliczeniowego udostępniane przez operatora komórkowego za pomocą SubscriptionManager.setSubscriptionPlans().

Wszystkie implementacje urządzeń:

• [C-0-1] MUSI zwracać plany subskrypcji tylko do aplikacji operatora komórkowego, który pierwotnie je udostępnił.
• [C-0-2] NIE MOŻE zdalnie tworzyć kopii zapasowych ani przesyłać planów subskrypcji.
• [C-0-3] MUSI zezwalać tylko na zastąpienia, takie jak SubscriptionManager.setSubscriptionOverrideCongested(), z aplikacji operatora komórkowego, który obecnie oferuje ważne abonamenty.

9.16. Migracja danych aplikacji

Jeśli implementacje urządzeń obejmują możliwość przenoszenia danych z jednego urządzenia na inne i nie ograniczają kopiowanych danych aplikacji do tych, które zostały skonfigurowane przez programistę w pliku manifestu za pomocą atrybutu android:fullBackupContent, to:

• [C-1-1] NIE MOŻE inicjować przesyłania danych aplikacji z urządzeń, na których użytkownik nie ustawił podstawowego uwierzytelniania zgodnie z opisem w sekcji 9.11.1 Bezpieczny ekran blokady i uwierzytelnianie.
• [C-1-2] MUSI bezpiecznie potwierdzić główne uwierzytelnianie na urządzeniu źródłowym i potwierdzić intencję użytkownika skopiowania danych na urządzeniu źródłowym przed przeniesieniem jakichkolwiek danych.
• [C-1-3] MUSI używać atestacji kluczy bezpieczeństwa, aby mieć pewność, że zarówno urządzenie źródłowe, jak i urządzenie docelowe w procesie migracji między urządzeniami są legalnymi urządzeniami z Androidem i mają zablokowany program rozruchowy.
• [C-1-4] MUSI przenosić dane aplikacji tylko do tej samej aplikacji na urządzeniu docelowym, o tej samej nazwie pakietu I certyfikacie podpisywania.

• [C-1-5] MUSI wyświetlać w menu ustawień informację o tym, że dane z urządzenia źródłowego zostały przeniesione w ramach migracji danych z urządzenia na urządzenie. Użytkownik NIE POWINIEN mieć możliwości usunięcia tej informacji.

9.17. Platforma wirtualizacji Androida

Interfejsy API Platformy wirtualizacji Androida (AVF) (android.system.virtualmachine.*) umożliwiają aplikacjom tworzenie na urządzeniu maszyn wirtualnych (VM) – chronionych (pVM) i niechronionych (non-pVM) – które wczytują i uruchamiają natywne pliki binarne jako ładunki.

Jeśli implementacje urządzenia ustawiają wartość FEATURE_VIRTUALIZATION_FRAMEWORK na true,

• [C-1-1] MUSI zapewnić, że android.system.virtualmachine.VirtualMachineManager.getCapabilities() zwraca jedną z tych wartości:
  • CAPABILITY_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. Weryfikacja programisty

Implementacje urządzeń deklarujące API na poziomie 36.1 lub wyższym:

• MOŻE obejmować obsługę usługi weryfikacji dewelopera, która potwierdza, że aplikacje pochodzą od znanego dewelopera.

Urządzenia deklarujące poziom interfejsu API 36.1 lub wyższy i skonfiguruj weryfikator dewelopera, definiując config_developerVerificationServiceProviderPackageName w config.xml:

• [9.18/C-1-1] MUSI wywoływać skonfigurowaną usługę android.content.pm.verify.developer.DeveloperVerifierService w przypadku każdej instalacji pakietu aplikacji, w tym nowych instalacji i aktualizacji istniejących aplikacji.

Implementacje urządzeń deklarujące API na poziomie 36.1 lub wyższym:

• MAY może też skonfigurować delegata do ustawiania aktywnej zasady, definiując config_developerVerificationPolicyDelegatePackageName w config.xml.

Jeśli weryfikator dewelopera jest skonfigurowany, implementacje urządzeń:

• [9.18/C-2-1] MUSI zezwalać tylko weryfikatorowi dewelopera lub jego skonfigurowanemu delegatowi na ustawianie zasad instalacji zgodnie z definicją w android.content.pm.PackageInstaller.

Jeśli weryfikator jest wywoływany w ramach sesji instalacji pakietu, implementacje urządzenia:

• [9.18/C-3-1] MUSI uniemożliwiać instalację pakietu aplikacji, jeśli:

  • Instalacja nie przejdzie weryfikacji tożsamości dewelopera.

  • Zasady weryfikacji dewelopera dla sesji instalacji są ustawione na dowolną wartość inną niż DEVELOPER_VERIFICATION_POLICY_NONE.

  • Chyba że zastosowanie mają punkty 9.18/C-3-2 lub 9.18/C-3-3.

• [9.18/C-3-3] NIE MOŻE uniemożliwiać instalacji pakietu aplikacji, gdy spełnione są wszystkie te warunki:

  • Zasada ma wartość DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN lub DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.

  • Weryfikacja jest zgłaszana jako niekompletna.

  • Instalator wskazuje, że użytkownik wyraźnie poprosił o kontynuowanie instalacji, zgłaszając DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

10. Testowanie zgodności oprogramowania

Implementacje urządzeń MUSZĄ przejść wszystkie testy opisane w tej sekcji. Pamiętaj jednak, że żaden pakiet testów oprogramowania nie jest w pełni kompleksowy. Dlatego ZDECYDOWANIE ZALECA SIĘ, aby producenci urządzeń wprowadzali jak najmniej zmian w referencyjnej i preferowanej implementacji Androida dostępnej w ramach Projektu Android Open Source. Zminimalizuje to ryzyko wprowadzenia błędów, które powodują niezgodności wymagające ponownego opracowania i potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje urządzeń:

• [C-0-1] MUSI przejść pakiet testów zgodności z Androidem (CTS) dostępny w ramach Projektu Android Open Source, korzystając z ostatecznej wersji oprogramowania na urządzeniu.

• [C-0-2] MUSI zapewnić zgodność w przypadku niejednoznaczności w CTS i w przypadku wszelkich ponownych implementacji części referencyjnego kodu źródłowego.

Zestaw CTS jest przeznaczony do uruchamiania na rzeczywistym urządzeniu. Podobnie jak każde oprogramowanie, CTS może zawierać błędy. CTS będzie wersjonowany niezależnie od tej definicji zgodności, a w przypadku Androida 17 może zostać opublikowanych kilka wersji CTS.

Implementacje urządzeń:

• [C-0-3] MUSI przejść najnowszą wersję CTS dostępną w momencie ukończenia oprogramowania urządzenia.

• W miarę możliwości NALEŻY korzystać z implementacji referencyjnej w drzewie Android Open Source.

10.2. Weryfikator CTS

Weryfikator CTS jest częścią pakietu testów zgodności i jest przeznaczony do uruchamiania przez operatora, aby testować funkcje, których nie można przetestować za pomocą systemu automatycznego, takie jak prawidłowe działanie kamery i czujników.

Implementacje urządzeń:

• [C-0-1] MUSI prawidłowo wykonać wszystkie odpowiednie przypadki w weryfikatorze CTS.

Weryfikator CTS zawiera testy wielu rodzajów sprzętu, w tym niektórych opcjonalnych.

Implementacje urządzeń:

• [C-0-2] MUSI przejść wszystkie testy dotyczące posiadanego sprzętu, np. jeśli urządzenie ma akcelerometr, MUSI prawidłowo wykonać test akcelerometru w CTS Verifier.

Przypadki testowe funkcji oznaczonych w tym dokumencie definicji zgodności jako opcjonalne MOGĄ być pomijane.

• [C-0-2] Każde urządzenie i każda kompilacja MUSZĄ prawidłowo uruchamiać weryfikator CTS, jak wspomniano powyżej. Jednak wiele kompilacji jest bardzo podobnych, więc nie oczekuje się, że osoby wdrażające urządzenia będą wyraźnie uruchamiać weryfikator CTS w przypadku kompilacji, które różnią się tylko w niewielkim stopniu. W szczególności implementacje urządzeń, które różnią się od implementacji, która przeszła testy CTS Verifier, tylko zestawem uwzględnionych ustawień regionalnych, brandingiem itp., MOGĄ pominąć test CTS Verifier.

11. Oprogramowanie, które można aktualizować

• [C-0-1] Urządzenia MUSZĄ zawierać mechanizm zastępowania całego oprogramowania systemowego. Mechanizm nie musi przeprowadzać aktualizacji „na żywo”, czyli może być wymagane ponowne uruchomienie urządzenia. Możesz użyć dowolnej metody, o ile umożliwia ona zastąpienie całego oprogramowania wstępnie zainstalowanego na urządzeniu. Na przykład to wymaganie spełnia dowolne z tych podejść:

  • Pobieranie „bezprzewodowe” (OTA) z aktualizacją offline po ponownym uruchomieniu.
  • „Przywiązane” aktualizacje przez USB z komputera hosta.
  • Aktualizacje „offline” przez ponowne uruchomienie i aktualizację z pliku na nośniku wymiennym.

• [C-0-2] Używany mechanizm aktualizacji MUSI obsługiwać aktualizacje bez usuwania danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachować prywatne dane aplikacji i dane udostępnione aplikacji. Pamiętaj, że oprogramowanie Androida typu upstream zawiera mechanizm aktualizacji, który spełnia to wymaganie.

• [C-0-3] Cała aktualizacja MUSI być podpisana, a mechanizm aktualizacji na urządzeniu MUSI weryfikować aktualizację i podpis względem klucza publicznego przechowywanego na urządzeniu.

• [C-SR-1] Mechanizm podpisywania ZDECYDOWANIE ZALECA się, aby zaszyfrować aktualizację za pomocą SHA-256 i sprawdzić hash w porównaniu z kluczem publicznym za pomocą ECDSA NIST P-256.

Jeśli implementacja urządzenia obejmuje obsługę połączenia z nieograniczonym transferem danych, np. 802.11 lub profilu Bluetooth PAN (Personal Area Network), wówczas:

• [C-1-1] MUSI obsługiwać pobieranie aktualizacji OTA z aktualizacją offline po ponownym uruchomieniu.

Implementacje urządzeń POWINNY sprawdzać, czy obraz systemu jest binarnie identyczny z oczekiwanym wynikiem po aktualizacji OTA. Wymaganie to spełnia implementacja aktualizacji OTA opartej na blokach w projekcie Android Open Source Project, która została dodana w Androidzie 5.1.

Implementacje urządzeń POWINNY też obsługiwać aktualizacje systemu A/B. AOSP implementuje tę funkcję za pomocą interfejsu HAL sterowania rozruchem.

Jeśli po wprowadzeniu urządzenia na rynek, ale w rozsądnym okresie jego użytkowania (określonym w porozumieniu z zespołem ds. zgodności Androida) zostanie wykryty błąd w jego implementacji, który wpływa na zgodność aplikacji innych firm:

• [C-2-1] Producent urządzenia MUSI naprawić błąd za pomocą aktualizacji oprogramowania, którą można zastosować zgodnie z opisanym powyżej mechanizmem.

Android zawiera funkcje, które umożliwiają aplikacji Właściciel urządzenia (jeśli jest obecna) kontrolowanie instalacji aktualizacji systemu. Jeśli podsystem aktualizacji systemu na urządzeniach zgłasza android.software.device_admin, to:

• [C-3-1] MUSI implementować zachowanie opisane w klasie SystemUpdatePolicy.

12. Historia zmian dokumentu

Od Androida 16 nie ma oddzielnie prowadzonej listy zmian. Wszystkie zmiany w stosunku do poprzedniej wersji są w tym dokumencie wyróżnione.

13. Skontaktuj się z nami

Możesz dołączyć do forum zgodności z Androidem i poprosić o wyjaśnienia lub zgłosić problemy, które Twoim zdaniem nie zostały omówione w dokumencie.