Definicja zgodności z Androidem 17 [WERSJA TESTOWA]

1. Wprowadzenie

W tym dokumencie wymieniono wymagania, które muszą spełniać urządzenia, aby 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 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 producent urządzenia.

Dlatego Projekt Android Open Source jest zarówno referencyjną, jak i preferowaną implementacją Androida. Zdecydowanie zalecamy, 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 Compatibility Test Suite 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 mają zastosowanie do określonego 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: Core (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. Pierwszy z nich odpowiada identyfikatorowi sekcji zgodnie z opisem 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 innych częściach 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ętowej 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 umożliwić użytkownikom zmianę rozmiaru wyświetlanych elementów (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 UI_MODE_NORMAL wyświetlacz udostępniany 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.

• [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 GPU, za pomocą właściwości systemu graphics.gpu.profiler.support.

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

• [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ę uwzględnienie 3-osiowego akcelerometru.

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 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/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 implementacje urządzeń obejmują obsługę standardu 802.11 (Wi-Fi), to:

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

Jeśli urządzenia obsługują protokół Wi-Fi Neighbor Awareness Networking (NAN) przez deklarowanie PackageManager.FEATURE_WIFI_AWARE i lokalizację Wi-Fi (czas podróży w obie strony Wi-Fi – RTT) przez deklarowanie 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 w 68 percentylu (obliczanym za pomocą funkcji dystrybuanty), +/-2 metrów przy paśmie 80 MHz w 68 percentylu, +/-4 metrów przy paśmie 40 MHz w 68 percentylu i +/-8 metrów przy paśmie 20 MHz w 68 percentylu na odległościach 10 cm, 1 m, 3 m i 5 m, zgodnie z obserwacjami za pomocą interfejsu WifiRttManager#startRanging Android API.

• [7.4.2.5/H-SR-1] Zdecydowanie zaleca się, aby raportować 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, co można zaobserwować za pomocą interfejsu API Androida WifiRttManager#startRanging.

Zdecydowanie ZALECA się wykonanie czynności konfiguracyjnych pomiaru podanych w artykule 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 wartości 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ł na poziomie 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:

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

Implementacje urządzeń przenośnych:

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

• [7.6.1/H-0-2] MUSI zwracać wartość „true”, gdy ActivityManager.isLowRamDevice() dla jądra i przestrzeni użytkownika dostępna jest 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 mieć 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 (tzw. partycja „/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 mniejszej 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ą android.service.vr.VrListenerService, którą można włączyć w aplikacjach VR za pomocą 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ń podanych w sekcji 7.7.2:

• [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: przytrzymanie 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 ją 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, wykonują one te czynności:

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

Gdy wykryty zostanie typ złącza audio USB 0x0402, urządzenie:

• [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 rolę 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 roli 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 typu AudioDeviceInfo.TYPE_USB_DEVICE i rolę 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 urządzenia przenośne zawierają co najmniej 1 liniowy siłownik rezonansowy ogólnego przeznaczenia 7.10:

• [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, to:

• [7.10/H] POWINNA 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)

2.2.3. Oprogramowanie

Implementacje na urządzeniach przenośnych 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

Urządzenia przenośne 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 wczytanie aplikacji do obsługi poczty e-mail, która może obsługiwać intencje ACTION_SENDTO, 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ć obszar 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 ZALECA SIĘ wyświetlanie pierwszego wyboru podanego w ramach 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 podanych 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 publikuje powiadomienie MediaStyle z tokenem MediaSession.

Powiadomienie o aktualizacji na żywo aplikacji może być promowane, jeśli spełnia ona wszystkie cechy 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ć powiadomienie o promowanej 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 Heads Up 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ć pole Notification.getShortCriticalText() jeśli jest obecne, lub pole Notification.when jeśli pole Notification.getShortCriticalText nie jest obecne.

  • [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 (preferowane) 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 których klawisz nawigacyjny funkcji ostatnich aplikacji jest używany 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 Asystenta, to:

• [3.8.4/H-SR-2] ZDECYDOWANIE ZALECA SIĘ używanie przytrzymania klawisza HOME jako wyznaczonego działania do uruchamiania aplikacji asystującej zgodnie z opisem w sekcji 7.2.3. MUSI uruchomić wybraną przez użytkownika aplikację asystującą, czyli aplikację, która implementuje interfejs 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ń niezwiązanych z rozmową:

• [3.8.4/H-1-1]^* MUSI wyświetlać powiadomienia o rozmowach przed powiadomieniami o innych sprawach, 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 możliwość 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 dostarczone przez interfejsy Control API.

• [3.8.16/H-1-5] MUSI udostępniać użytkownikowi możliwość rezygnacji z kontroli nad 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 API ControlsProviderService i Control Control.isAuthRequired.

• [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łowej aktywności (zgodnie z definicją API), musi ona osadzić tę aktywność 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 zgłaszać 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”). Dodatkowo podaj 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 honorować 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 działającej już aplikacji musi zająć mniej niż 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ą dostępne w AOSP lub rozszerzają funkcje dostępne w AOSP:

• [8.3/H-1-1] MUSI zapewniać 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 „Czuwanie aplikacji” i „uśpienie”.

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 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ć intencję użytkownika android.intent.action.POWER_USAGE_SUMMARY 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ę (działającą) na pierwszym planie lub zadanie zainicjowane przez użytkownika.

2.2.5. Model zabezpieczeń

Implementacje urządzeń przenośnych:

• [9/H-0-1] MUSI zadeklarować 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 uprawnienia w przypadku 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żliwiającą wybór 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 przestrzeń 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ą spełniać to wymaganie.

• [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 urządzenie zostało już wprowadzone na rynek z wcześniejszą wersją Androida, nie musi mieć magazynu kluczy opartego na izolowanym środowisku wykonawczym ani obsługiwać 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 oczekiwania na uśpienie, 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 Blokada zabezpieczająca. AOSP spełnia wymagania trybu blokady.

Jeśli implementacje na urządzenia przenośne 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 na urządzeniach 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 zainstalowana z pominięciem sklepu) oznaczona przez PackageManager jako PACKAGE_SOURCE_LOCAL_FILE;

W przypadku dowolnych wymuszonych 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 wdrożyć ustawienia ograniczone 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 trwania 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 aktywujących 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łowa aktywującego.

• [9.8/H-1-4] NIE WOLNO przesyłać 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 MOŻE 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 MOŻE 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-kluczy, aby umożliwić badaczom ds. bezpieczeństwa sprawdzanie tych danych.

• [9.8/H-1-12] MUSI obsługiwać tryb debugowania, który rejestruje surową zawartość każdej transmisji z usługi wykrywania słów kluczowych, aby umożliwić badaczom ds. bezpieczeństwa sprawdzanie tych danych.

• [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 po udanym wykryciu słowa kluczowego są przesyłane jednokierunkowo z usługi wykrywania słów kluczowych do usługi interakcji głosowej.

• [9.8/H-SR-1] ZDECYDOWANIE ZALECA się powiadamianie użytkowników przed ustawieniem aplikacji jako dostawcy usługi wykrywania słów-kluczy.

• [9.8/H-SR-2] Zdecydowanie zalecamy, aby nie zezwalać na przesyłanie 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ń zawierają aplikację, która korzysta z interfejsu System API HotwordDetectionService 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łów aktywujących.

• [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, ContentCaptureService lub 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 wszelkimi powiązanymi z nimi komunikatami o atrybucji.

• [9.8.2/H-4-3] NIE MOŻE ukrywać wskaźnika mikrofonu w przypadku aplikacji systemowych z widocznym interfejsem użytkownika lub 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] MUSI 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] Śledzony demon Perfetto MUSI być domyślnie włączony (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 kodera i dekodera wideo w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints() odpowiadających zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

• [5.1/H-1-6] MUSI obsługiwać sesje sprzętowego dekodera i 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-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, gdy są one obciążone w stopniu 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 sprzętowego dekodera 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 sprzętowych wideo 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 rozdzielczość 4K60, co odpowiada zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [5.1/H-1-16] MUSI mieć co najmniej 1 enkoder wideo obsługujący rozdzielczość 4K60, który 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, które odpowiadają zadeklarowanemu poziomowi klasy wydajności multimediów urządzenia.

• [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 docelowy poziom jakości określony przez krzywe szybkości i zniekształceń 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 pominiętych klatek, które odpowiadają 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 zadeklarowanemu poziomowi klasy 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ć co najmniej 12-kanałowe miksowanie dźwięku 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 odpowiednio do zadeklarowanego poziomu 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ących 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świetlacza (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ą niezerową wartość parametru android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• 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ą niezerową wartość parametru android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• [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ć wymagania dotyczące właściwości odpowiadające zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.android.info.supportedHardwareLevel

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

• [7.5/H-1-5] MUSI spełniać wymagania dotyczące opóźnienia przechwytywania JPEG w 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 w formacie 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 przedniej i tylnej kamery głównej, które odpowiada zadeklarowanemu przez urządzenie poziomowi klasy wydajności multimediów.

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

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

• [7.5/H-1-14] MUSI obsługiwać 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 przez urządzenie poziomowi klasy wydajności multimediów.

• [7.5/H-1-17] MUSI obsługiwać funkcje wykrywania twarzy w przypadku aparatów 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 aparatu tylnego i głównego aparatu przedniego odpowiadających 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 generować JPEG_R w przypadku głównego tylnego i głównego przedniego aparatu 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 dokumentu CDD Androida 17 odpowiadające 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świetlania 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ą niezerową wartość parametru android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• 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ą niezerową wartość parametru android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• [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ć równoległą sekwencyjną wydajność 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 z Androidem TV to urządzenie z Androidem, które 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 na urządzeniach 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;
• mieć wbudowany wyświetlacz o przekątnej większej niż 24 cale LUB zawierać port wyjścia wideo, taki jak VGA, HDMI, DisplayPort lub port bezprzewodowy do wyświetlania obrazu;

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ą podłączaną do tego portu 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ń 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] Profil MPEG-4 AAC (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 kl./s.

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 częstotliwościach klatek i rozdzielczościach wideo do:

• [5.3.1/T-1-1] HD 1080p przy 29,97 kl./s 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 na wysokim poziomie. MUSZĄ usuwać przeplot z przeplatanego wideo 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 szybkościach 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 kl./s 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 na wyświetlaczu zewnętrznym, 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] POWINIEN 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 jedną 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 zaleca się obsługę trybu obrazu w obrazie w wielu oknach.
• [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 open source TalkBack.

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 danych wejściowych opartych na TIF pochodzących od 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 urządzenia obsługują tuner, to:

• [3/T-1-1] MUSI obsługiwać wszystkie interfejsy API platformy Tuner, aby aplikacja korzystająca z tych interfejsów API 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ść odczytu losowego 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ą dostępne w AOSP lub rozszerzają funkcje dostępne 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 „Czuwanie aplikacji” i „Uśpienie”.

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 te 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 deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.

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 ustawienia 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. Projekt Android Open Source (AOSP) spełnia to wymaganie, korzystając z implementacji Trusty, ale alternatywnymi opcjami są też inne rozwiązania oparte 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 klucza, 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 urządzenie zostało już wprowadzone na rynek z wcześniejszą wersją Androida, nie musi mieć magazynu kluczy opartego na izolowanym środowisku wykonawczym ani obsługiwać 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 tryb 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/perfettodokumentacją 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 narzędzia Perfetto MUSI zapisywać jako dane wyjściowe ślad bufora protokołu zgodny ze schematem zdefiniowanym w dokumentacji narzędzia 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 mieć dostępną dla użytkownika funkcję Strona główna i funkcję Wstecz, z wyjątkiem sytuacji, gdy jest w 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 funkcji 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 w co najmniej 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 zadeklarować 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 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.

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 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, zgodnie z projektem TalkBack o otwartym kodzie źródłowym.

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

• [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 Androidem Wear 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ą zwolnione 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ędzanie 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] MUSISZ zadeklarować funkcję android.hardware.security.model.compatible.

Jeśli implementacje urządzeń z zegarkiem 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 dla 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 urządzenie ma bezpieczny ekran blokady i zawiera co najmniej 1 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 siedzeń 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 rozdzielczości co najmniej tak dużej 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 przypadku każdej strefy 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 dla każdego głównego wyświetlacza.

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 profilowanie 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 protokołu 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 desce rozdzielczej 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ć na podstawie ostatniej znanej lokalizacji i kierunku ruchu lokalizację, łą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 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ń obejmują 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żny i NIE może zakłócać korzystania z BT 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 obraz scen po drugiej stronie nadwozia pojazdu, np. kamera cofania.

Aparat skierowany do przodu to aparat skierowany w stronę 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 implementacje urządzeń samochodowych obejmują 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 Androida Automotive.

• [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 MOŻE 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 Camera API:

• [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 zwiększyć wydajność i trwałość 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, np. 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 jednej 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 rolę 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 roli 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ń samochodowych 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 (ulepszony kodek AAC o niskim opóźnieniu)

Urządzenia samochodowe 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, które są mapowane na tę samą grupę głośności zdefiniowaną w pliku konfiguracji 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ć poniższą predefiniowaną listę UserRestrictions dla pełnych 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, podświetlenia nocnego, skali szarości w ramach Cyfrowej równowagi i ograniczenia 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 zażądają tego 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ć ODTWARZAJ 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] POWINNA 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ć działanie intencji niejawnej CAR_INTENT_ACTION_MEDIA_TEMPLATE z dodatkowym parametrem CAR_EXTRA_MEDIA_PACKAGE.

• [3.14/A-0-4] MUSI udostępniać afordancję do przejścia do aktywności związanej z ustawieniami aplikacji multimedialnej, ale MUSI ją włączać tylko wtedy, gdy nie obowiązują ograniczenia dotyczące interfejsu użytkownika 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ć w aplikacji funkcję wyszukiwania 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ę uruchamiającą:

• [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 do trybu pełnoekranowego zgodnie z opisem w sekcji immersive documentation.

• [3.8/A] MOŻE utrzymywać pasek stanu i pasek nawigacyjny widoczne przez cały czas.

• [3.8/A] MOŻE ograniczyć możliwość zmiany kolorów elementów interfejsu systemu przez aplikację, aby zapewnić ich stałą widoczność.

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 trwać krócej 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ść losowego zapisu 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ść losowego odczytu 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 o wartości co najmniej 50 MB/s.

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

• [8.3/A] POWINIEN 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 komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source Project.

• [8.4/A-0-2] MUSI podawać 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 obsługi administracyjnej 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ń samochodowych obsługują interfejs System API VisualQueryDetectionService lub inny mechanizm wykrywania zapytań bez wskazywania dostępu do mikrofonu lub kamery:

• [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 Asystenta cyfrowego (np. wykryje 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 WOLNO 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ć ostatnio używane i aktywne aplikacje korzystające z aparatu, zwrócone przez PermissionManager.getIndicatorAppOpUsageData(), wraz z powiązanymi z nimi komunikatami 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 przestrzeń 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ą spełniać to wymaganie.

• [9.11/A-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 urządzenie zostało już wprowadzone na rynek z wcześniejszą wersją Androida, nie musi mieć magazynu kluczy opartego na izolowanym środowisku wykonawczym ani obsługiwać 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 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 /system/bin/perfetto plik binarny, którego wiersz poleceń jest zgodny z dokumentacją Perfetto.

  • [6.1/A-0-2] Plik binarny perfetto MUSI akceptować jako dane wejściowe konfigurację bufora protokołu zgodną ze schematem zdefiniowanym w dokumentacji 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;

Wymagania dotyczące implementacji na tabletach są podobne do wymagań dotyczących implementacji na urządzeniach 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 tabletach 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 wykonywania kodu bajtowego Dalvik jest głównym narzędziem dla aplikacji na Androida. Interfejs programowania aplikacji (API) na 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 są 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 poprzez osadzanie podpisanego pliku konfiguracyjnego 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] MUSI 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. Miękka zgodność interfejsu 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] Twórcy urządzeń MUSZĄ obsługiwać i egzekwować wszystkie stałe uprawnień zgodnie z dokumentacją na stronie z informacjami o uprawnieniach. Pamiętaj, że w sekcji 9 znajdziesz 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 w zakresie 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 „Wybieranie”, 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), jeśli 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. Jeśli takie deklaracje są zdefiniowane w wzorcach filtrów intencji aplikacji, implementacje na urządzeniach:

• [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ć linki, zawsze pytać o otwarcie lub nigdy nie otwierać linków. Musi to dotyczyć wszystkich filtrów intencji URI.
  • [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, jeśli urządzenie umożliwia przejście weryfikacji przez niektóre filtry intencji URI, a inne nie.

3.2.3.3. Przestrzenie nazw zamiarów

• [C-0-1] Implementacje urządzeń NIE MOGĄ zawierać żadnego komponentu Androida, który obsługuje nowe wzorce intencji lub intencji rozgłoszeniowych przy użyciu ACTION, CATEGORY lub innego kluczowego ciągu znaków w przestrzeni nazw android.* lub com.android.*.
• [C-0-2] Twórcy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub intencji rozgłaszania za pomocą ACTION, CATEGORY lub innego kluczowego ciągu znaków 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 daną 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 wysyłać intencje transmisji publicznej 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 będzie wywoływać 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 konta 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 karty do emulacji 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ć 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ć działanie, które odpowiada na intencję ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, w przypadku implementacji z UI_MODE_TYPE_NORMAL MUSI to być działanie, w którym 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 z metod wprowadzania innych firm na urządzeniu:

• [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 włączania i wyłączania usług ułatwień dostępu innych firm oraz wstępnie załadowanych usług ułatwień dostępu.

Jeśli implementacje urządzeń obsługują Wi-Fi Easy Connect i udostępniają tę funkcję aplikacjom innych firm, muszą:

• [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 zaimplementować ją 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 wszystkim aplikacjom, w tym aplikacjom preinstalowanym:

• [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 mieć zachowanie równoważne z sytuacją, w której użytkownikowi odmówiono 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ą interfejs VoiceInteractionService i mają zainstalowanych więcej niż jedną 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:

• [C-SR-3] Zdecydowanie zaleca się, aby aplikacje obsługujące 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 realizuje te intencje 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ń:

• POWINNA obsługiwać wygaszacze ekranu i udostępniać 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ć nową aktywność na tym samym ekranie co aktywność, która ją uruchomiła, gdy nowa aktywność jest uruchamiana bez określania ekranu docelowego za pomocą interfejsu ActivityOptions.setLaunchDisplayId().
• [C-1-4] MUSI usuwać wszystkie działania, 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ą blokady zabezpieczającej, 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 ZALECANE jest używanie 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ć kod działający w środowisku zarządzanym, który wywołuje kod natywny 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ługiwana 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 sekcją 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, które są udostępniane 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 sekcja 7.1.4.2 zawiera szczegółowe wymagania dotyczące tego, kiedy oczekiwane jest pełne wdrożenie poszczególnych funkcji.

• POWINNY być tworzone 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 w 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 API android.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 w wersji Android 17 do implementacji interfejsu API android.webkit.WebView.

• [C-1-3] Ciąg tekstowy agenta użytkownika zgłaszany przez WebView w przypadku aplikacji kierowanych na pakiet SDK na poziomie 35 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 „Mobile”.

• 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.

Pamiętaj, że jeśli implementacje urządzeń są 32-bitowe lub deklarują flagę funkcji android.hardware.ram.low, są zwolnione z wymagania C-1-3.

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 w HTML5/W3C i POWINIEN obsługiwać interfejs IndexedDB API w 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, to:

• [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 konkretne 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 odbiorcó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(), chyba że została umieszczona 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ć następujących 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, 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ż zasobnik aplikacji w stanie ograniczonego czuwania, 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 zastrzeżonych ograniczeń 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ą bezpośrednio związane ze stanem systemu, takie jak brak popularności aplikacji na rynku, NIE MOGĄ być używane jako kryteria.

• [C-1-4] NIE WOLNO automatycznie stosować tych zastrzeżonych ograniczeń w przypadku aplikacji, gdy użytkownik ręcznie wyłączył ograniczenia aplikacji, i MOŻE sugerować użytkownikowi zastosowanie tych zastrzeżonych ograniczeń.

• [C-1-5] MUSI informować użytkowników, jeśli te zastrzeżone ograniczenia są automatycznie stosowane do 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 zawieszać te ograniczenia własnościowe w aplikacji, gdy użytkownik zaczyna z niej korzystać, co powoduje, że staje 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 witryna MUSI być dostępny za pomocą linku z dokumentów pakietu Android SDK i MUSI zawierać:

  • Warunki wywołujące ograniczenia zastrzeżone.
  • Jakie ograniczenia można nałożyć na aplikację i w jaki sposób.
  • 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 użytkownik nigdy nie korzystał z niej przez ponad 30 dni, obowiązują wyjątki od [C-1-3] i [C-1-5].

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 aplikacji w przypadku 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 czas. 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.

Implementatorzy urządzeń MOGĄ jednak dodawać niestandardowe interfejsy API poza standardową przestrzenią nazw Androida, ale te niestandardowe interfejsy API:

• [C-0-5] NIE MOŻE znajdować się w przestrzeni nazw należącej do innej organizacji lub odnoszącej się do niej. 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, jak opisano 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.

• POWINNY 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 (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 (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 (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 (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ń zawierają 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ć false w przypadku 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.

• MOGĄ zastępować plakietki ikon aplikacji własnym schematem plakietek, gdy aplikacje innych firm wskazują obsługę tego schematu za pomocą własnych 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 „AppWidget”.

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 użytkownika, 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. obszaru 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 implementacji 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 na pasku stanu/systemowym, 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 w celu 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 za pomocą 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 detektora powiadomień.

• [C-SR-3] Zdecydowanie zaleca się automatyczne wyświetlanie użytkownikowi afordancji zablokowania powiadomień określonej aplikacji innej firmy na poziomie każdego kanału i pakietu 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ść tymczasowego wyciszania powiadomień.

• MOŻE 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 innymi niż powiadomienia o rozmowach, 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] MUSI używać dokładnie tych samych zasobów, które są udostępniane przez klasę interfejsu API Notification.Style i jej podklasy w przypadku prezentowanych elementów zasobów.

• POWINNA 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 urządzenia, z którego korzysta. Jeśli implementacje urządzeń obsługują powiadomienia typu heads-up:

• [C-3-1] MUSI używać widoku i zasobów powiadomień z ostrzeżeniem zgodnie z opisem w klasie interfejsu API Notification.Builder, gdy wyświetlane są powiadomienia z ostrzeżeniem.

• [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 odroczonego 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 w sposób ciągły.

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 aplikacjom innych firm dostępu do konfiguracji zasad trybu „Nie przeszkadzać” lub odmawiania takiego dostępu.

• [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, kody potwierdzające jednorazowe 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:

  • 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 AOSP NotificationAssistantServices 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 krótkich ciągów znaków bez trybu, które 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, to:

• [C-1-1] MUSI udostępniać użytkownikowi możliwość zablokowania 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, to:

• [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 ich 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 odcieni kolorów przy użyciu stylów motywu kolorystycznego 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ższych wymagań dotyczących 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ójność środowiska programistycznego w tej konfiguracji, ważne jest, aby styl ikony paska stanu był zachowany w różnych implementacjach urządzenia.

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 żą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 działania animowanych tapet, jeśli może obsługiwać wszystkie animowane tapety bez ograniczeń funkcjonalności przy rozsądnej liczbie klatek na sekundę i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują awarie animowanych tapet lub aplikacji, ich nieprawidłowe działanie, nadmierne zużycie procesora lub baterii albo działanie z nieakceptowalnie niską liczbą klatek na sekundę, oznacza to, ż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 używany jako klawisz nawigacyjny, zgodnie 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 Ostatnie.

• 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 z metod wprowadzania innych firm na urządzeniu:

• [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 powiadomień multimedialnych, który umożliwia aplikacjom multimedialnym integrację z elementami sterującymi odtwarzaniem wyświetlanymi na ekranie blokady.

3.8.11. Wygaszacze ekranu (wcześniej Sny)

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, to:

• [C-1-1] MUSI być w stanie renderować te emotikony w postaci kolorowych glifów.

• [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 zakresie 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 odcienie skóry i różnorodne rodziny zgodnie z raportem technicznym Unicode nr 51.

Jeśli implementacje urządzeń obejmują IME, muszą:

• 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 z 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, która nie jest zgodna 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 urządzenia mogą wyświetlać kilka 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 na rozmiar mniejszy 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ć zadokowane działanie w trybie podzielonego ekranu, ale POWINIEN wyświetlać część jego zawartości, jeśli aplikacja uruchamiająca jest aktywnym oknem.

• [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 obrazu 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.

  • kierowana na interfejs API na poziomie 25 lub niższym i deklaruje 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ą PIP 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 setAspectRatio() API.

• [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 PIP. Wymaganie to jest spełnione w implementacji AOSP, która zawiera elementy sterujące w obszarze powiadomień.

• [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 z ustawieniem Configuration.uiMode innym niż UI_MODE_TYPE_TELEVISION MUSZĄ przydzielać minimalną szerokość i wysokość 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:

• [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 dokumentacji pakietu SDK. Interfejs DisplayCutout określa obszar na krawędzi wyświetlacza, który może nie działać w przypadku aplikacji z powodu wycięcia w ekranie lub zakrzywionego wyświetlacza 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ż 1 wycięcia na krawędź.

• [C-1-3] MUSI uwzględniać flagi wycięcia w ekranie ustawione przez aplikację za pomocą interfejsu API WindowManager.LayoutParams 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, to:

• [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ądzeniem 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, urządzenie:

    • [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 urządzenia właścicielowi, 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 wdrożenie na urządzeniu obejmuje użytkowników lub dane użytkowników:

    • [C-1-7] NIE MOŻE już 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 informacje dla użytkownika, aby wskazywać, 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ą funkcji 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 ustanowiony 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 kontynuować pracy 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 DPC profilu osobistego, 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 aplikacji 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 z wersji 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 dotyczących urządzeń 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 oknie topActivity, 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ć żadnej innej zawartości ekranu (paska systemowego, powiadomień ani żadnych treści z profilu osobistego) z wyjątkiem okna/okien aplikacji z profilu służbowego podczas zapisywania zrzutu ekranu w profilu służbowym (aby mieć pewność, że dane z 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 magazynowania 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 tym samym symbolem, który jest używany 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 użytkownika i powrotu do użytkownika głównego w sesji wielu użytkowników, gdy isLogoutEnabled zwraca true. Element interfejsu użytkownika MUSI być dostępny z ekranu 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, to:

• [C-SR-1] Zdecydowanie zalecamy, aby wyświetlały te same informacje o zgodzie właściciela urządzenia z AOSP, które były wyświetlane w procesie inicjowanym przez android.app.action.PROVISION_MANAGED_DEVICE, zanim zezwolą na dodanie kont 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 podpisywania, 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ść sterowania usługami ułatwień dostępu, które deklarują AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. W przypadku urządzeń z systemowym paskiem nawigacyjnym NALEŻY umożliwić użytkownikowi korzystanie z 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, 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ą funkcji getIconBitmap() lub getIconUri() oraz tytuły uzyskane za pomocą funkcji 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 polu 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 jawne 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 z domyślnym interfejsem systemu, Ustawieniami i Launcherem. Implementacje urządzeń:

  • [C-1-5] MUSI udostępniać użytkownikowi możliwość wyświetlania i usuwania aplikacji błyskawicznych przechowywanych lokalnie w pamięci podręcznej dla każdego indywidualnego 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 błyskawicznych uruchamianych za pomocą intencji internetowych, zdefiniowanych przez użycie intencji z działaniem ustawionym na Intent.ACTION_VIEW i schematem „http” lub „https”, dodatkowa afordancja powinna umożliwiać użytkownikowi nieuruchamianie aplikacji błyskawicznej, 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 uruchomionych aplikacji błyskawicznych 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 zestawie 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 umożliwia skuteczniejsze zarządzanie 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/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 wymagające dużych zasobów

Jeśli implementacje urządzenia deklarują funkcję FEATURE_CANT_SAVE_STATE, to:

• [C-1-1] MUSI mieć tylko 1 aplikację instalowaną, która określa cantSaveState działającą w systemie w danym momencie. 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 naciskania przycisku 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 inne elementy, które mają pozostać uruchomione, np. usługi 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 normalnym mechanizmie zapisywania i przywracania 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.

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] ACCOUNT_NAME niestandardowego konta lokalnego MUSI być zwracany 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 surowe 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 surowych kontaktów (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 języka uwzględniającego płeć w przypadku języków, które nie obsługują tłumaczeń uwzględniających płeć. 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

3.22. ComputerControls API

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 z 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 taki 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ące ciąg znaków ostrzegawczych przekazywany przez interfejs API systemu PackageManager.setHarmfulAppWarning, zanim uruchomi działanie 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 podpisu plików APK w wersji 4 i schematu podpisu plików APK w wersji 4.1.

5. Zgodność multimediów

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 dla 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.

Należy pamiętać, że 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 właścicieli 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 na urządzeniach 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] Profil MPEG-4 AAC (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 być przeprowadzane bez downmixingu (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 natywnej kolejności bajtów za pomocą interfejsu android.media.MediaCodec API.

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 (w przypadku użycia wartości 2), czy ma być odtwarzana przy użyciu natywnej liczby kanałów (w przypadku użycia wartości równej lub większej od tej liczby). 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 przesyłać dźwięk wielokanałowy (czyli więcej niż 2 kanały) po otrzymaniu skompresowanych treści wielokanałowych:

• [C-SR-2] ZDECYDOWANIE ZALECA SIĘ, aby dekoder można było skonfigurować przez aplikację za pomocą dekodowania z kluczem KEY_MAX_OUTPUT_CHANNEL_COUNT, aby określić, czy treść ma być miksowana w dół do stereo (w przypadku użycia wartości 2), czy ma być odtwarzana przy użyciu natywnej liczby kanałów (w przypadku użycia 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-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 x 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 + progresywny	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: obraz, kolekcja obrazów, sekwencja 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 jeden z tych formatów kolorów: planar YUV420 8:8:8 lub semiplanar 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ądzenia zawierają dekoder lub koder wideo:

• [C-1-1] Kodeki wideo MUSZĄ obsługiwać rozmiary wyjściowych i wejściowych buforów bajtowych, które umożliwiają obsługę największej możliwej skompresowanej i nieskompresowanej klatki zgodnie z normą i konfiguracją, ale nie mogą przydzielać zbyt dużej ilości 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ą 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 jest skonfigurowany tak, aby nie używać 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 przyspieszający działanie multimediów na wielu platformach, oraz Codec 2.0, interfejs API przyspieszający działanie multimediów o niskim obciążeniu.

Jeśli urządzenia obsługują multimedia:

• [C-1-1] MUSI obsługiwać kodeki multimedialne za pomocą interfejsów OMX lub Codec 2.0 (lub obu tych interfejsów) 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 oprogramowania OMX działały w procesie kodeka, który nie ma dostępu do sterowników sprzętu 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 zgodnie z projektem 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.”. MUSI korzystać z interfejsu Codec 2.0 API i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa Codec 2.0 na Androidzie.

• [C-1-4] Kodeki, których nazwy zaczynają się od „OMX.google.” lub „c2.android.”. NIE MOŻE być określana jako dostawca ani jako akcelerowana 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óre nie są obecne w projekcie Android Open Source Project lub 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 pikseli (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 POWINNO przekraczać 15% przepływności w oknie przesuwnym 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, to zakodowana szybkość transmisji bitów:

• [C-SR-2] ZDECYDOWANIE ZALECA się, aby nie przekraczać docelowej szybkości transmisji o więcej niż 15% w oknie przesuwnym 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.
• POWINIEN obsługiwać zarówno koder wideo VP8, jak 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 na sekundę, w przypadku której koder wideo POWINIEN określać chwilowy czas trwania klatki na podstawie sygnatur czasowych buforów wejściowych i przydzielać zasobnik bitów 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.
• POWINNO 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 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 zaleca się, aby koderzy nie używali funkcji ASO, FMO i RS w przypadku profilu podstawowego.
• [C-1-2] MUSI obsługiwać profile kodowania wideo SD (Standard Definition) z tabeli poniżej.
• 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, 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 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 w wysokiej rozdzielczości (HD):
• [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 poziom 3.
• [C-1-1] MUSI obsługiwać zapisywanie plików Matroska WebM.
• [C-1-3] MUSI generować dane CodecPrivate.
• POWINNO obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• [C-SR-1] ZDECYDOWANIE ZALECA się obsługę profili dekodowania HD wskazanych w tabeli 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 jest dostępny 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 przekazywać 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:

• [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 jakości SD (Standard Definition) wymienione w tabeli poniżej i zakodowane w profilu podstawowym i profilu Main na poziomie 3.1 (w tym 720p30).
• POWINNO być w stanie dekodować filmy w profilach HD (High Definition) zgodnie z tabelą poniżej.

Jeśli wysokość zgłoszona przez metodę Display.getSupportedModes() jest równa lub większa od rozdzielczości filmu, 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.
• POWINNO 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 lub większa od rozdzielczości filmu:

• [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.
• POWINIEN 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./stelewizja)
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.
• POWINNO 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 lub większa od rozdzielczości filmu:

• [C-3-1] Urządzenia MUSZĄ obsługiwać dekodowanie co najmniej jednego z formatów VP9 lub H.265 w profilach 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ścia 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 profili wideo o rozdzielczości co najmniej HD 720p z tabeli poniżej, gdy wysokość zgłoszona 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 przyszłych wersjach definicji zgodności planujemy zmienić je na MUST. W przypadku obecnych i nowych urządzeń z Androidem ZDECYDOWANIE ZALECA SIĘ spełnienie tych wymagań, 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. Przechwytywanie 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 antyaliasingowy, gdy podane powyżej 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, do których aplikacje innych firm mają dostęp za pomocą interfejsu AudioManager.getMicrophones() API, w przypadku aktywnego AudioRecord używającego 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 upsamplingu przy dowolnym 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 rejestrować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 przybliżeniu płaską charakterystykę amplitudy w funkcji częstotliwości w zakresie średnich częstotliwości: w szczególności ±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, a konkretnie – 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 o podwójnej precyzji) dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania mowy.

• 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 implementować REMOTE_SUBMIX źródło dźwięku, tak 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 tych:

  • 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:

• POWINNO 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 umożliwiać 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ą 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 przy konfiguracjach 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 do implementacji na urządzeniach.

Jeśli implementacje urządzenia deklarują funkcję android.hardware.audio.output, to:

• [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. Rekomendujemy, aby w przypadku efektów, których wyników nie widać w potoku audio platformy, takich jak przetwarzanie końcowe czy efekty przeniesione, zachowanie było podobne.

• [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. Podobne działanie jest zalecane, gdy efekty nie są widoczne w potoku audio platformy, np. w przypadku efektów przetwarzanych po fakcie lub 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 i 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 przeniesieniem przetwarzania dźwięku:

• [C-SR-1] ZDECYDOWANIE ZALECA się przycinanie odtwarzanych bez przerw treści audio między dwoma klipami w tym samym formacie zgodnie z ustawieniami interfejsu AudioTrack gapless API i kontenera multimedialnego dla 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 przez przetwornik 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 przypadku zimnego startu; 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łe opóźnienie wyjściowe. 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 formacie 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.

• OpenSL ES PCM API kolejki bufora Zestaw interfejsów API OpenSL ES związanych z PCM w ramach Android NDK.

• AAudio native audio API. Zestaw interfejsów API 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 zwrotne 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 zimnego 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 w przypadku 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ń zawierają 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] Otwarcie strumienia wejściowego za pomocą 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 zdefiniowano 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 śledzenia ruchu głowy w stosunku do aktualizacji 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 zgodnie z tabelą 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 ramkowaniem 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 protokołu wyświetlania bezprzewodowego, to:

• [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ę funkcji android.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 zgodnie z sekcją 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) Specyfikacji przewodowych zestawów słuchawkowych (wersja 1.1).

Jeśli urządzenia nie mają 4-żyłowego gniazda słuchawek 3,5 mm, ale 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 od ±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 pożą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 sygnału, 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ł rozszerzony, 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 przez procesor (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 koderó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 obrazu 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 danych wejściowych surface, jak i ByteBuffer, i MUSI reklamować obsługę COLOR_Format32bitABGR2101010.

Jeśli implementacja urządzenia obejmuje kodeki obsługujące FEATURE_HdrEditing, to urządzenie:

• [C-7-4] MUSI reklamować obsługę EXT_YUV_target rozszerzenia 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 podanymi 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. Aktualizacja implementacji urządzeń ze starszej wersji Androida bez trwałego bloku danych MOŻE być zwolniona 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ć następujące 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 implementacje urządzeń 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:

• [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 metodzie 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. Narzędzie Systrace musi być domyślnie nieaktywne. MUSI istnieć dostępny dla użytkownika mechanizm włączania narzędzia Systrace.

• Perfetto

  • [C-SR-1] Zdecydowanie zaleca się udostępnienie użytkownikowi powłoki pliku binarnego, którego wiersz poleceń jest zgodny z /system/bin/perfettodokumentacją 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 jako ślad protobuf 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 w wersji 1.0 lub nowszej 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 dostarczyć 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 ryzyko dla bezpieczeństwa 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 raportować dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager dla tego samego odcisku cyfrowego kompilacji.

Typowym przykładem scenariusza, w którym obowiązują te wymagania, jest interfejs API telefonii: 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 dla deweloperów aplikacji na Androida, 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:

• fizyczną przekątną. Odległość w calach między dwoma przeciwległymi rogami oświetlonej części wyświetlacza.

• density. Liczba pikseli na liniowym odcinku poziomym lub pionowym 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 ekranu 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 przypadku 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ą pakietu 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świetlenia 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 z tych kwadratów.

• 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ę NO_KEYS klawiatury i chcą zgłaszać obsługę konfiguracji UI_MODE_TYPE_NORMAL trybu interfejsu, muszą:

• [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 na 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ń zapewniają możliwość zmiany rozmiaru wyświetlanych elementów urządzenia, muszą:

• [C-1-1] NIE WOLNO skalować wyświetlacza do rozmiaru większego niż 1,5-krotnośćDENSITY_DEVICE_STABLE ani tworzyć efektywnego minimalnego wymiaru ekranu mniejszego niż 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-krotności DENSITY_DEVICE_STABLE.

• Aby zapewnić dobrą użyteczność i spójne rozmiary czcionek, ZALECA się udostępnienie tych opcji skalowania wyświetlania natywnego (zgodnie z limitami określonymi powyżej):

  • 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 implementacje urządzeń nie obejmują 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 interfejsie API android.util.DisplayMetrics dla emulowanego domyślnego view.Display.

7.1.3. Orientacja ekranu

Implementacje urządzeń:

• [C-0-1] MUSZĄ zgłaszać obsługiwane orientacje ekranu (android.hardware.screen.portrait lub android.hardware.screen.landscape) i MUSZĄ zgłaszać co najmniej jedną obsługiwaną orientację. Na przykład urządzenie z ekranem o stałej orientacji poziomej, takie jak telewizor lub laptop, POWINNO zgłaszać tylko android.hardware.screen.landscape.

• [C-0-2] MUSI zgłaszać 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óra jest obsługiwana.

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

• [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 OpenGL ES dEQP 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, oznacza, że 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 dla 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ę rozszerzenia EGL_KHR_mutable_render_buffer, 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, to:

• [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 dEQP Vulkan 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 Vulkana (np.android.hardware.vulkan.level, android.hardware.vulkan.version).

• [C-2-2] NIE MOŻE wyliczać żadnych VkPhysicalDevice dla 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 ją wyłączać, 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 zachowywać się 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 całości pokrywa gamę kolorów sRGB w przestrzeni CIE 1931 xyY.

• [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 zgodnie z definicją w pakiecie Android SDK, chyba że w tym dokumencie wyraźnie zezwala się na coś innego.

Wszystkie wyświetlacze zgodne z Androidem w ramach 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ć android.software.input_methods flagę funkcji.
• [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 formatami określonymi 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 obsługują nawigacji bezdotykowej:

• [C-1-1] MUSI udostępniać rozsądny alternatywny mechanizm interfejsu użytkownika do wybierania i edytowania tekstu, zgodny z mechanizmami zarządzania wprowadzaniem. Implementacja open source Androida obejmuje mechanizm wyboru odpowiedni do użycia na urządzeniach, które nie mają wejść nawigacyjnych innych niż dotykowe.

7.2.3. Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz, zwykle dostępne w wyniku interakcji z dedykowanym przyciskiem fizycznym lub odrębną 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 Strona główna, Ostatnie lub Wstecz są dostępne:

• [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ż została ona wycofana na rzecz paska działań w Androidzie 4.0.

• [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. przejścia na stronę główną lub powrotu), 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 rozwijania menu, gdy rozszerzone menu nie jest puste i pasek działań jest widoczny.
• [C-2-2] NIE MOŻE modyfikować położenia wyskakującego okienka przepełnienia działań wyświetlanego po wybraniu przycisku rozwijania menu na pasku działań, ale MOŻE renderować wyskakujące okienko przepełnienia działań w zmodyfikowanym położeniu na ekranie, gdy jest ono wyświetlane po wybraniu 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, gdy targetSdkVersion 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 „Strona główna”.
• [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 zacznie przechwytywać dotknięcia w przypadku gestu systemowego, jeśli wcześniej wysłała do aplikacji na pierwszym planie 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 niestandardowe panele systemowe, które można przesuwać, są dostępne na lewej lub prawej krawędzi, MUSZĄ być umieszczone w górnej 1/3 ekranu z wyraźnym, trwałym wizualnym wskazaniem, że przeciągnięcie spowoduje wywołanie 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 udokumentowane 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. Implementacje urządzeń z ekranem dotykowym są powiązane z wyświetlaczem w taki sposób, że użytkownik ma wrażenie bezpośredniego manipulowania elementami na ekranie. Ponieważ użytkownik dotyka bezpośrednio ekranu, system nie wymaga żadnych dodatkowych afordancji 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 urządzenie ma ekran dotykowy, który może śledzić więcej niż 1 dotyk 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ń korzystają z zewnętrznego urządzenia wejściowego, takiego jak mysz lub trackball (tzn. nie dotykają bezpośrednio ekranu), do 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 polu interfejsu API Configuration.touchscreen.

7.2.5. Fałszywe 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ć fałszywe interakcje dotykowe. Android zawiera funkcję stałą 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 urządzenie nie ma ekranu dotykowego, ale ma inny system wprowadzania danych 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 dotknięcia 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 przeciągnąć obiekt 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 mieć możliwość mapowania zdarzeń HID na odpowiednie stałe wartości InputEvent wymienione w tabelach poniżej. Implementacja Androida w wersji 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 Gamepad (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, implementacja urządzenia MUSI implementować ten interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK i dokumentacji Android Open Source dotyczącej 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 zachowywać się 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 (metrycznego) 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 żadnych 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ą Android SDK na Androida jest czujnikiem ciągłym, implementacje urządzeń MUSZĄ stale dostarczać okresowe próbki danych, które POWINNY mieć odchylenie poniżej 3%, gdzie odchylenie jest zdefiniowane jako odchylenie standardowe różnicy zgłoszonych 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, który reprezentuje 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ę Androida 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 mogą być tworzone 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 zgłasza 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] NIE MOŻE zawierać w przesyłanych danych żadnych stałych parametrów kalibracji określonych fabrycznie.

Jeśli implementacje urządzeń obejmują kombinację 3-osiowego akcelerometru, 3-osiowego żyroskopu lub magnetometru, są to:

• [C-SR-2] Zdecydowanie zaleca się zapewnienie stałego położenia względnego 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. Parametry kompensacji powinny być zachowywane między ponownymi uruchomieniami urządzenia.

• POWINNY mieć kompensację temperatury.

Jeśli implementacje urządzeń obejmują 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.

• POWINIEN implementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR,TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER zgodnie z opisem w dokumentacji 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ń obejmują 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 POWINNA mieć wartość poniżej 200 µT, co można osiągnąć, umieszczając magnetometr z dala od dynamicznych (indukowanych przez prąd) i statycznych (indukowanych przez magnes) 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 tych systemów: GLONASS, Beidou, 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 tą wartością. Inaczej mówiąc, jeśli zmierzysz wariancję żyroskopu przy częstotliwości próbkowania 1 Hz, NIE POWINNA ona być większa niż 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 bitów.

• 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] Zalecamy wdrożenieTYPE_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ę uwzględnienie barometru (czujnika 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 czujnika.

• [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ń obejmują termometr otoczenia (czujnik temperatury):

• [C-1-1] MUSI definiować SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury otoczenia, a czujnik MUSI mierzyć temperaturę otoczenia (pomieszczenia/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ń zawierają 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 miał zakres pomiarowy 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 przypadku 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ć losowy błąd 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 temperatury 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 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 przypadku przetwarzania wsadowego 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ń.

  • 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 powyż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 procesu biometrycznego. Ta klasyfikacja określa możliwości, jakie czujnik biometryczny ma w zakresie interakcji z platformą i aplikacjami innych firm. Czujniki muszą spełniać dodatkowe wymagania opisane poniżej, jeśli mają być klasyfikowane jako klasa 1, klasa 2 lub klasa 3. Zarówno dane biometryczne klasy 2, jak i dane biometryczne 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, to:

• [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 MOŻE 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 przypadku 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 bezpiecznego (SE), którego nie można sterować w żaden inny sposób niż przez naciśnięcie fizycznego przycisku.

• [C-5-2] MUSI dodatkowo implementować proces uwierzytelniania niejawnego (bez etapu potwierdzenia) odpowiadający funkcji setConfirmationRequired(boolean), którą aplikacje mogą ustawić do wykorzystania w procesach logowania.

Jeśli implementacje urządzeń mają kilka czujników biometrycznych:

• [C-7-1] MUSI w przypadku zablokowania danych biometrycznych (tzn. wyłączenia danych biometrycznych do czasu odblokowania przez użytkownika za pomocą uwierzytelniania podstawowego) lub zablokowania czasowego (tzn. tymczasowego wyłączenia danych biometrycznych do czasu, aż użytkownik odczeka określony czas) z powodu zbyt wielu nieudanych prób zablokować również wszystkie inne dane biometryczne niższej klasy. W przypadku blokady czasowej czas do ponowienia weryfikacji biometrycznej MUSI być maksymalnym czasem do ponowienia weryfikacji biometrycznej w ramach blokady 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 ZALECANE JEST również zablokowanie wszystkich innych biometrii tej samej klasy. W przypadku blokady czasowej zaleca się, aby czas do ponowienia weryfikacji biometrycznej był maksymalnym czasem do ponowienia wszystkich metod 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, po potwierdzeniu dowolnego z nich należy wysłać onAuthenticationSucceeded).

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 tej 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ą):

• [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 odsetek akceptacji fałszywych danych i podszywania się jest wyższy niż 7% zgodnie z protokołami testów biometrycznych na Androidzie.

• [C-1-9] MUSI poprosić użytkownika o podanie zalecanego podstawowego uwierzytelnienia (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 rejestracji (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 Androidzie.

• [C-1-3] MUSI ograniczać liczbę prób weryfikacji biometrycznej – gdzie fałszywa 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 przez co najmniej 30 sekund po 5 nieudanych próbach weryfikacji biometrycznej, aby ograniczyć maksymalną liczbę 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ć odsetek akceptacji fałszywych i podrobionych próbek nie wyższy niż 30%, przy czym (1) odsetek akceptacji fałszywych i podrobionych próbek w przypadku instrumentów do ataków prezentacyjnych (PAI) na poziomie A nie może być wyższy niż 30%, a (2) odsetek akceptacji fałszywych i podrobionych próbek w przypadku instrumentów do ataków prezentacyjnych (PAI) na poziomie 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 (kod PIN, wzór, hasło) zabezpieczonych przez TEE. Implementacja w ramach Projektu Android Open Source zapewnia mechanizm, 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ć indywidualną flagę dla danego rodzaju danych biometrycznych (np.DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT,DevicePolicymanager.KEYGUARD_DISABLE_FACE lubDevicePolicymanager.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 limitu czasu 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 instrumentu ataku prezentacyjnego (PAI), zgodnie z protokołami testów biometrycznych na Androidzie.

• [C-SR-13] Zdecydowanie zaleca się, aby wskaźnik akceptacji fałszywych i podrobionych próbek nie przekraczał 30% w przypadku każdego rodzaju instrumentu ataku prezentacyjnego, zgodnie z protokołami testów biometrycznych na Androidzie.

• [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 i podszywających się próbek nie wyższy niż 20%, 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ż 20%, a (2) współczynnik akceptacji fałszywych i podszywających się próbek w przypadku instrumentów PAI poziomu B nie może być wyższy niż 30%, zgodnie z protokołami testów biometrycznych na Androida.

• [C-SR-15] ZALECANE jest, aby odsetek akceptacji fałszywych i podrobionych próbek nie przekraczał 20% w przypadku każdego rodzaju instrumentu ataku prezentacyjnego (PAI), zgodnie z pomiarami wykonanymi na podstawie protokołów testów biometrycznych na Androidzie.

• [C-2-3] MUSI przeprowadzać dopasowywanie biometryczne w izolowanym środowisku wykonawczym poza przestrzenią użytkownika lub jądra Androida, takim jak zaufane środowisko wykonawcze (TEE), na układzie z bezpiecznym kanałem do izolowanego ś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 Projekt Android Open Source lub chronioną maszyną wirtualną kontrolowaną przez hiperwizor, który 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 hipernadzorcę, 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ę ani do żadnych danych z nich pochodzących (np. osadzeń) 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 tożsamości i podszywania się nie wyższy niż 7%, 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ż 7%, 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ż 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 implementacje urządzeń zawierają czytnik linii papilarnych pod wyświetlaczem,

• [C-SR-11] ZDECYDOWANIE ZALECANE, aby zapobiec kolizji obszaru dotykowego czytnika linii papilarnych pod wyświetlaczem z nawigacją 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ć czujnik TYPE_HINGE_ANGLE i raportować dane z niego.

• [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ń obejmują obsługę standardu 802.1.15.4 i udostępniają funkcje aplikacji innej firmy, muszą:

• [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łów do pojedynczego urządzenia STATIC STS DS-TWR, tryb odroczony, interwał wysyłania sygnałów 240 ms.

  • CONFIG_ID_2: pomiar odległości STATIC STS DS-TWR typu „jeden do wielu” zdefiniowany przez FiRa, tryb odroczony, 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 o kącie 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ść przełączania stanu włączenia/wyłączenia 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 kondycją:

• [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 nawiązywaniem połączeń głosowych i wysyłaniem SMS-ów lub z ustanawianiem mobilnej transmisji danych w 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ć android.hardware.telephony flagę funkcji i inne flagi podrzędnych funkcji zgodnie z technologią.

• [C-1-2] MUSI wdrożyć pełną obsługę interfejsu API dla tej technologii.

• POWINNO zezwalać na wszystkie dostępne typy 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 zawierają 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ą zastrzeżony mechanizm udostępniania funkcji eSIM deweloperom zewnętrznym:

• [C-3-1] MUSI zadeklarować android.hardware.telephony.euicc flagę funkcji.

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 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. Referencyjna implementacja 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 pojedynczą subskrypcję we wszystkich interfejsach widocznych dla użytkownika, które wyświetlają i kontrolują informacje o karcie SIM. 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 elementach interfejsu widocznych dla użytkownika, 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 interfejsach, które dostarczają informacji 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 otwierać i jednocześnie wykorzystywać maksymalną liczbę kanałów logicznych (20 łącznie) 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 ani 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 opportunistic, 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 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ć android.hardware.telephony.euicc.mep flagę funkcji.

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 zaimplementować 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 rejestrze połączeń platformy informacje o zablokowanym połączeniu i MUSI odfiltrowywać połączenia z BLOCKED_TYPE z domyślnego widoku rejestru połączeń w zainstalowanej fabrycznie aplikacji Telefon.

• [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 główny użytkownik 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 przenosić 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 Telefon.

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 za pomocą elementu 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 przerwanie innego połączenia.

• [C-SR-2] ZDECYDOWANIE ZALECA się wstępne wczytywanie domyślnej aplikacji do wybierania numerów, która wyświetla wpis w historii połączeń i nazwę aplikacji innej firmy w swojej historii połączeń, gdy aplikacja innej firmy ustawia klucz dodatkowy EXTRA_LOG_SELF_MANAGED_CALLS w swoim elemencie PhoneAccount na wartość true.

• [C-SR-3] ZDECYDOWANIE ZALECA się obsługę 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ącej rozmowy zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia.

  • Wywołaj Connection.onAnswer(), gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie klawisza.

  • Wywołanie 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ć przeniesienie 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 podtrzymania połączenia komórkowego na instancję radia.

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 multiemisji 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 są wymagane do obsługi ż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 sekwencyjny żądania sondy w normalny sposób (sekwencyjnie) między żądaniami sondy w skanowaniu.

• [C-1-10] MUSI losowo wybierać numer sekwencyjny żądania sondy między ostatnim żądaniem sondy w skanowaniu a pierwszym żądaniem sondy w następnym skanowaniu.

• [C-SR-1] ZDECYDOWANIE ZALECA SIĘ randomizację źródłowego adresu MAC używanego we wszelkiej komunikacji stacji z punktem dostępu podczas łączenia i połączenia.

  • Urządzenie MUSI używać innego randomizowanego adresu MAC dla każdego identyfikatora SSID (w przypadku Passpoint jest to w pełni kwalifikowana nazwa domeny), 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:

• POWINIEN 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 urządzenia obsługują Wi-Fi i używają tej technologii 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ń:

• POWINNO obejmować obsługę 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ą elementu WifiManager.isTdlsSupported.

• TDLS powinno być używane tylko wtedy, gdy jest to możliwe I korzystne.

• POWINIEN mieć pewną heurystykę 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ądzenia 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 implementacje urządzeń obejmują obsługę standardu 802.11 (Wi-Fi), to:

• 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ć android.hardware.wifi.passpoint flagę funkcji.

• [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ń, który jest zdefiniowany 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 powiązany 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ę dokładne raportowanie z dokładnością do 1,5 m przy paśmie 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 funkcji utrzymywania połączenia Wi-Fi na procesor 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 równoczesne gniazda keepalive przez Wi-Fi

Jeśli implementacje urządzeń nie obsługują przenoszenia na Wi-Fi funkcji keepalive,

• [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 obsługiwać 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 wywołania 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

7.4.3. Bluetooth

Jeśli implementacje urządzeń obsługują profil Bluetooth Audio:

• POWINNO 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, muszą:

• [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.

• POWINNY 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 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 jest reklamowanie 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 jej 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ę fizyczną 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 przypadku 95% pomiarów.

Jeśli implementacje urządzeń deklarują FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING, to:

• [C-11-1] MUSI zgłaszać 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, gdy urządzenia są ustawione w taki sposób, że znajdują się na „równoległych płaszczyznach”, a ekrany są 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ł o mocy 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 planują udostępnić go aplikacjom innych firm:

• [C-1-1] MUSI raportować funkcję android.hardware.nfc z android.content.pm.PackageManager.hasSystemFeature() metody.

• MUSI obsługiwać 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 z definicją w specyfikacji technicznej 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ć android.hardware.nfc.hcef stałą funkcji.

• [C-3-2] MUSI implementować interfejsy API emulacji karty 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 jeden standard danych o przepustowości 200 kbit/s lub większej. Przykłady technologii spełniających to wymaganie to EDGE, HSPA, EV-DO, 802.11g, Ethernet i Bluetooth PAN.

• POWINNY też obsługiwać co najmniej jeden popularny standard bezprzewodowej transmisji danych, np. 802.11 (Wi-Fi), gdy podstawowym połączeniem do transmisji danych jest fizyczny standard sieciowy (np. Ethernet).

• MOŻE obsługiwać więcej niż jeden rodzaj połączenia do transmisji 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, oraz 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 urządzenia 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 formie zwykłego tekstu, gdy urządzenie jest skonfigurowane do używania 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. Secure Elements

Jeśli implementacje urządzeń obsługują elementy bezpieczne z interfejsem Open Mobile API i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI wymieniać 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ść przełączania stanu włączenia/wyłączenia 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 zapewnić, ż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 konfiguracyjnych pomiaru podanych 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 bitmapRGBA_8888 o rozmiarze równym 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ęć.

• [C-1-3] MUSI zapewnić, że domyślna preinstalowana 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 dane wyjściowe 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 implementują 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 w 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 podobnych zastosowań. 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 WOLNO używać przedniego aparatu jako domyślnego w interfejsie Camera API i NIE WOLNO 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 autofokus, 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 kamery 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 urządzenie obsługuje kamerę zewnętrzną:

• [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 jest podłączona do portu hosta USB.

• [C-1-3] MUSI przejść testy CTS kamery z podłączonym fizycznym urządzeniem zewnętrznym. Szczegółowe informacje o testach CTS kamery 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 dla każdej klatki.

Starszy pakiet interfejsu API, android.hardware.Camera, jest oznaczony jako wycofany w Androidzie 5.0, ale powinien być nadal dostępny do użycia w aplikacjach. 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, które są 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 tych dwóch 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 nadal 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 klasie android.hardware.Camera.Parameters i klasie 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ż deklarować indywidualne możliwości kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i deklarować odpowiednie flagi 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 dostępne 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ą aplikacjom innych firm zastrzeżony interfejs API aparatu, to:

• [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ą.

  Urządzenia, które spełniają dowolne z tych kryteriów, są zwolnione z tego wymagania:

  • 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”, „udostępnionym miejscem na dane aplikacji” lub ścieżką w systemie Linux „/sdcard”, pod którą jest montowane.
• [C-0-2] MUSI być skonfigurowane z domyślnie zamontowaną 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 w ś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 interfejs API na poziomie 29 lub wyższym, z wyjątkiem następującej sytuacji:
  • Gdy aplikacja zażąda android:requestLegacyExternalStorage="true" w pliku manifestu.
• [C-0-5] MUSI usuwać metadane lokalizacji, takie jak tagi GPS Exif, 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) zaimplementowanej 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 prywatne 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 implementacje urządzeń mają port USB z trybem urządzenia peryferyjnego USB i obsługują 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.

• POWINIEN 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 implementacje urządzeń obejmują 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 wartości:
  • 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, to:

• [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 zastosowań USB HID i żądaniu zastosowania 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), to:

• [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.
  • SĄ ZDECYDOWANIE ZALECANE, aby obsługiwać Power Delivery w przypadku danych i zamiany ról zasilania.
• [C-SR-3] ZDECYDOWANIE ZALECA SIĘ, aby nie obsługiwać trybu akcesorium adaptera audio, zgodnie z opisem w dodatku A do specyfikacji kabla i złącza 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 dźwięków o częstotliwości zbliżonej do ultradźwięków 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ń zawierają co najmniej 1 analogowy port audio, muszą:

• [C-SR-1] Zdecydowanie zaleca się, aby co najmniej 1 port audio był 4-żyłowym gniazdem słuchawek 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ć zdarzenie 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 słuchawek 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:

• [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 i 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ń zmierzonego 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 w zakresie 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 aplikacji VR na urządzenia mobilne. Implementacje urządzeń MUSZĄ prawidłowo implementować te interfejsy API i zachowania, jak opisano 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ć rozszerzenia 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 EGL_KHR_mutable_render_buffer oraz udostępniać je 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 GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture i udostępnienie rozszerzeń 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 w trybie naprzemiennym dla każdego oka z częstotliwością 60 klatek na sekundę w 2 kontekstach 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, skompresowanej 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] Wyświetlacz MUSI odświeżać obraz z częstotliwością co najmniej 60 Hz w trybie VR.
• [C-1-17] Wyświetlacz MUSI obsługiwać tryb niskiej trwałości z trwałością ≤ 5 milisekund. Trwałość jest definiowana jako 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ą dostępne wyłącznie 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, dostępny dla aplikacji do celów takich jak zwracanie uwagi za pomocą dzwonków, alarmów i powiadomień, a także ogólne informacje zwrotne dotyczące dotyku.

Jeśli implementacje urządzenia NIE zawierają takiego siłownika haptycznego ogólnego przeznaczenia:

• [7.10/C] MUSI zwracać wartość false w przypadku Vibrator.hasVibrator().

Jeśli implementacje urządzeń ZAWIERAJĄ co najmniej 1 uniwersalny siłownik haptyczny:

• [C-1-1] MUSI zwracać wartość „true” w przypadku Vibrator.hasVibrator().
• NIE POWINIEN używać ekscentrycznego siłownika haptycznego z wirującą masą (ERM) (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 wibracji 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 wibracji 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.
• POWINNY 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ę awaryjną, 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ądzeń zwracają wartość inną niż zero w przypadku parametru android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• [C-1-1] MUSI zwracać wartość co najmniej 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 gwarantują stałą liczbę klatek na sekundę i czas reakcji w przypadku 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ń, zgodnie z opisem 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 magazynie danych aplikacji (partycja /data) umożliwia deweloperom aplikacji określenie odpowiednich oczekiwań, które pomogą im w projektowaniu oprogramowania. W zależności od typu urządzenia implementacje urządzeń 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 używania ustawień globalnych lub DeviceConfig do zarządzania ograniczaniem zadań, alarmów i sieci w przypadku aplikacji w każdym zasobniku 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 „Czuwanie aplikacji” i „uśpienie” 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ędzanie 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 „Czuwanie aplikacji” i „Uśpienie”.

Jeśli implementacje urządzeń rozszerzają funkcje zarządzania energią 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 te 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 zalecamy 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 tych 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ść

Wydajność aplikacji o wysokich wymaganiach i długim czasie działania może się znacznie wahać 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, muszą:

• 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ądzeń deklarują funkcję android.hardware.security.model.compatible, to:

• [C-1-1] MUSI obsługiwać wymagania wymienione w kolejnych 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ą one 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 MOŻE 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 na podstawie domyślnych zasad przyznawania uprawnień lub w ramach roli na platformie.

• [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 dostępu do lokalizacji w Androidzie, gdy aplikacja żąda danych o lokalizacji lub aktywności fizycznej za pomocą standardowego interfejsu API Androida lub mechanizmu zastrzeżonego. Dane te obejmują m.in.:

  • Lokalizacja urządzenia (np. szerokość i długość geograficzna) zgodnie z opisem w sekcji 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Ą uzyskać 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 API AppOpsManager do rejestrowania i śledzenia każdego programowego dostępu do danych chronionych przez niebezpieczne uprawnienia 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ć chroniony przez uprawnienia platformy z android.permission-group.HEALTH, jeśli w HealthPermissions istnieje odpowiednie uprawnienie.

• [C-0-17] MUSI, jeśli żadne uprawnienie platformy nie pasuje do żądanego typu danych, być chronione przez niestandardowe uprawnienie systemowe. (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ć treści 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 urządzenia w pełni zarządzanego (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ń fabrycznie 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Ą przestrzegać modelu 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Ą one być 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 korzystającej z 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 izolowane 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, dlatego 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 użytkownika głównego) 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świetlają się w tym samym widoku ostatnio używanych 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 dla 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) niezwiązane z użytkownikiem, które są stosowane w przypadku 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ć na dostęp do kontaktów, które są już dostępne w profilu użytkownika nadrzędnego, tylko aplikacjom w profilu dodatkowym, które mają aktywność programu uruchamiającego.

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 specjalny. 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ń zarówno w jądrze, jak 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 naruszenie bezpieczeństwa i skutecznie je zablokuje, 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 MOŻE 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 MOŻE 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, jak opisano 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), jak opisano 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 w przypadku kopii między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY) na urządzeniach, które pierwotnie były dostarczane z API na poziomie 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 systemu (operacyjnego) 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 systemu, 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ć wzmacnianie zabezpieczeń przewidywania rozgałęzień, jeśli sprzęt jest podatny na CVE-2017-5715 na wszystkich urządzeniach pierwotnie dostarczanych z poziomem [interfejsu] API 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 entropią 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 ZALECA się włączenie CFI, SCS i IntSan w przypadku wszystkich dodatkowych komponentów przestrzeni użytkownika wrażliwych na bezpieczeństwo, 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). Nie należy zakładać, że wartość używana przez jądro do inicjowania tych przydziałów jest znana.

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 wymuszania.

• [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.

• POWINIEN zachować domyślne zasady SELinux dostarczone w folderze system/sepolicy w projekcie Android Open Source Project i tylko rozszerzać te zasady o własną konfigurację specyficzną 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 kategorii typowych błędów, które obniżają jakość i bezpieczeństwo.

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 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 zaufanym aplikacjom dostępu 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 pamięci to technologia, która z wysokim prawdopodobieństwem (> 90%) ogranicza występowanie w aplikacjach co najmniej tych klas błędów, które korzystają z opcji manifestu android:memtagMode:

• przepełnienie bufora sterty,
• używać po okresie bezpłatnym,
• podwójny wolny
• wild free (zwolnienie wskaźnika, który nie został przydzielony za pomocą funkcji 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 zezwalać na to, aby właściwość systemowa arm64.memtag.bootctl akceptowała listę rozdzieloną przecinkami tych wartości, a po następnym ponownym uruchomieniu następowało zastosowanie odpowiedniego efektu:

  • memtag: włączona jest technologia bezpieczeństwa pamięci zdefiniowana powyżej.

  • memtag-once: technologia Memory Safety w opisanym powyżej znaczeniu jest tymczasowo włączona i automatycznie wyłączana przy następnym ponownym uruchomieniu.

  • memtag-off: technologia Memory Safety zdefiniowana powyżej jest wyłączona.

• [C-3-2] MUSI umożliwiać użytkownikowi powłoki 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 sieci 2G za pomocą żadnego innego elementu urządzenia niż administrator urządzenia za pomocą UserManager.DISALLOW_CELLULAR_2G.

• [C-SR-19] Zdecydowanie zaleca się wywołanie funkcji TelephonyManager.setAllowedNetworkTypesForReason z przyczyną ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G, aby spełnić to wymaganie.

• [C-SR-20] Zdecydowanie zaleca się 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, który jest domyślnie skonfigurowany w implementacji AOSP.

Android przechowuje zdarzenia systemowe, używając StatsLog identyfikatorów, i zarządza taką historią za pomocą interfejsów StatsManager i IncidentManager System API.

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 opisano 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ę użytkownika na rejestrowanie wszelkich informacji poufnych wyświetlanych na ekranie użytkownika za każdym razem, gdy sesja nagrywania ekranu lub przesyłania obrazu z ekranu jest włączana za pomocą MediaProjection.createVirtualDisplay() lub zastrzeżonych interfejsów API.

• [C-0-3] MUSI wyświetlać użytkownikowi powiadomienie o trwającej aktywności, 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 APIContentCaptureService lub w inny zastrzeżony 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 na urządzeniu 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 aparatu” to widok na ekranie, który jest stale widoczny dla użytkownika i nie można go zasłonić. Użytkownicy rozumieją, że aparat jest w użyciu (dzięki unikalnemu tekstowi, kolorowi, ikonie lub ich kombinacji).

Po wyświetleniu pierwszej sekundy wskaźnik może się wizualnie zmienić, np. zmniejszyć, i nie musi być wyświetlany w pierwotnej formie.

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 ostatnio używanych 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 nie 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.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łównych urzędów 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 jedną z tych możliwości:
  • 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 w sieci 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 poprosić użytkownika o zgodę przed włączeniem tego mechanizmu, chyba że sieć VPN jest włączana przez kontroler zasad dotyczących urządzeń 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 „zawsze włączona sieć 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

Android za pomocą interfejsów API systemu obsługuje mechanizm, który umożliwia implementacjom urządzeń rejestrowanie tych danych wrażliwych:

• dane multimedialne, takie jak dźwięk lub wideo, nagrywane lub odtwarzane przez urządzenie;

• zdarzenia wejściowe (np. klawisz, mysz, gest, głos, wideo i ułatwienia dostępu);

• Wszelkie dane ekranu lub inne dane wysyłane przez AugmentedAutofillService do systemu.

• Wszystkie ekrany i inne dane dostępne przez interfejsy APIContent Capture.

• Wszystkie dane aplikacji przekazywane do systemu za pomocą interfejsu AppSearchManager API i dostępne za pomocą AppSearchGlobalManager.query.

• Wszelkie teksty lub inne dane wysyłane za pomocą TextClassifier API do System TextClassifier, czyli do usługi systemowej, aby zrozumieć znaczenie tekstu, a także generować przewidywane kolejne działania na podstawie tekstu.

• Dane indeksowane przez implementację platformy AppSearch, w tym m.in. tekst, grafika, dane multimedialne i inne podobne dane.

• Dane audio uzyskane w wyniku korzystania z SpeechRecognizer#onDeviceSpeechRecognizer() przez implementację rozpoznawania mowy.

• Dane audio uzyskane w tle (w sposób ciągły) za pomocą interfejsów API AudioRecord,SoundTrigger lub innych interfejsów API audio, które nie powodują wyświetlania wskaźnika widocznego dla użytkownika.

• Dane z aparatu uzyskane w tle (w sposób ciągły) za pomocą interfejsu CameraManager lub innych interfejsów API aparatu, które nie powodują wyświetlania wskaźnika widocznego dla użytkownika.

• [C-1-7] MUSI udostępniać użytkownikowi możliwość rezygnacji z wyświetlania w platformie Androida (np. w launcherze) danych zebranych za pomocą wyszukiwarki aplikacji lub innych zastrzeżonych środków.

• [C-SR-1] ZDECYDOWANIE NIE ZALECA się żądania uprawnienia 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 w ramach implementacji w środowisku piaskownicy (patrz punkt 9.8.15 Implementacje interfejsu API w środowisku piaskownicy).

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 jest 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 Lokalizacja w Androidzie( 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)

Głównym punktem odniesienia są 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 112 lub wysłanie SMS-a na 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 innych zainstalowanych aplikacji (patrz 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 ujawnionych 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 korzystające z protokołu 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. Zgłoszenie błędu związanego 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żywane 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 elementów:

  • 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ęć lub miejsce na dane:

• [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 WOLNO modyfikować). 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 egzekwować, aby pojedyncza, 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 MOŻE w ogóle przechowywać na dysku 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 wyrazi na to wyraźną zgodę za każdym razem, gdy dane są udostępniane.

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 wyboru, czy ma pozostać zablokowany, czy odblokowany, 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.15. Implementacje Private Compute Core i aplikacji Gateway

9.8.16. Ciągłe dane audio i z kamery

Jeśli implementacje urządzeń rejestrują którekolwiek z danych opisanych w sekcji 9.8.2 lub sekcji 9.8.6 i 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 (kamery 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 zalecamy, aby każda funkcja wykorzystująca takie dane wymagała zgody użytkownika i była 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 kamery) w przypadku danych z kamery pochodzących z zdalnego urządzenia do noszenia.

Jeśli implementacje urządzeń otrzymują dane z kamery lub mikrofonu z zewnętrznego 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, to:

• [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 z rolą android.app.role.ASSISTANT.

• [C-2-2] MUSI dopilnować, aby implementacja korzystała z interfejsów API Androida HotwordDetectionService lub 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.

Menedżer statystyk umożliwia też zbieranie z urządzeń danych, które są uznawane za wrażliwe z punktu widzenia 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 do interfejsu StatsManager i zbiera z niego dane objęte ograniczeniami:

• [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 chroniących prywatność.

• [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 MUSZĄ być egzekwowane zasady dotyczące ruchu wychodzącego danych, aby ograniczać zbieranie danych w kategoriach danych objętych ograniczeniami zdefiniowanych w StatsLog.

9.8.18. Prywatność 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 masowej szyfrowanej na urządzeniu (DE) i szyfrowanej 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) oraz 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 przechowywania 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 zgodnie z opisem 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 żądania od użytkownika podania 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, 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] MUSI 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żyć powyższych opcji opartych na AES do 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 silny i nieodwracalny” 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 MOŻE 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 przy użyciu 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 za pomocą 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 w pamięci trwałej w różnych katalogach zostały zaszyfrowane przy użyciu różnych kombinacji klucza szyfrowania 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, co oznacza, że 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 rozruchu 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 szyfrowania metadanych, które 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 każdego użytkownika:

• [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 opartym na sprzęcie. 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 na ekranie blokady użytkownika.

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 Resume-on-Reboot musi nadal zapewniać, że gdy urządzenie trafi w ręce atakującego, odzyskanie przez niego 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 kryptograficznych kluczy 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ęć flash itp.) z wyjątkiem przypadków opisanych poniżej, ale taka modyfikacja wiąże się z opóźnieniem wynoszącym co najmniej godzinę 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 rozruchu.
• [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 haszowania (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 próbę 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 zaleca się weryfikowanie wszystkich artefaktów wykonywalnych wczytywanych przez aplikację z uprawnieniami z zewnątrz pliku APK (np. dynamicznie wczytywanego kodu lub skompilowanego kodu) przed ich wykonaniem lub zdecydowanie zaleca się, aby w ogóle ich nie wykonywać.

• POWINNO wdrażać ochronę przed przywróceniem w przypadku każdego komponentu z trwałym oprogramowaniem układowym (np. modemu, aparatu) i POWINNO używać pamięci masowej odpornej na manipulacje do przechowywania metadanych używanych do określania minimalnej dopuszczalnej wersji.

Projekt Android Open Source 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 odczytywanie 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, interwał czasowy 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 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 urządzenie zostało już wprowadzone na rynek z wcześniejszą wersją Androida, nie musi mieć magazynu kluczy opartego na izolowanym środowisku wykonawczym ani obsługiwać 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 limitu czasu uśpienia w przypadku przejścia ze stanu odblokowanego do zablokowanego, przy czym minimalny dopuszczalny limit czasu 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 9 punktów (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 przypadku używania 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, hasła) zaimplementowanych i udostępnianych w AOSP.

• [C-3-4] Nowa metoda uwierzytelniania MUSI być 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 jest 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 użycie 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 dotyczących urządzeń (DPC) ustawi zasadę 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 aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasady jakości wymagań dotyczących haseł 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 zaczynające się od C-8 w tej 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 umożliwiać 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 ustawień:

  • 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 sekcji C-8.

Jeśli implementacje urządzeń mają bezpieczny ekran blokady 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 można je 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 MOŻE przechowywać klucza szyfrowania 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 użycie 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 [C-1-7] i [C-1-8] w sekcji 7.3.10, chyba że bezpieczeństwo użytkownika (np. rozproszenie uwagi kierowcy) budzi obawy.

• [C-7-10] NIE MOŻE być traktowany jako bezpieczny ekran blokady i MUSI spełniać ograniczenia wymienione w punkcie 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ła 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ądzeń wirtualnych 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 blokady 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 w schowku na urządzeniu, na którym uzyskano do nich dostęp, oraz na urządzeniu, z którego pochodzą dane w schowku.

Jeśli implementacje urządzeń 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 na temat zabezpieczeń Google Cloud Key Vault Service 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 czynnika wiedzy 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 z użyciem UWB:

    • MUSI spełniać wymagania dotyczące zgodności, certyfikacji, dokładności i kalibracji technologii UWB opisane w sekcji 7.4.9.

    • MUSI korzystać z 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ą funkcji DeviceStateManager ORAZ oddzielne stany blokady wyświetlacza za pomocą funkcji 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 urządzenia z domyślnego wyświetlacza.

• [C-SR-3] Zdecydowanie zaleca się ograniczenie odblokowywania oddzielnego wyświetlacza za pomocą określonego 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 (AP).

• [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ć prawdziwy generator 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 w danym kraju 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 na poziomie 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 wtajemniczona 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] Zdecydowanie zaleca się wdrożenie 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 wdrożyć system poświadczeń tożsamości (np. interfejsy API android.security.identity.*) z kodem komunikującym 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 przestrzeń 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 tożsamości (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 kodów MAC nie można generować dla dowolnych danych), nawet jeśli Android działa nieprawidłowo lub został naruszony.

Projekt Android Open Source udostępnia referencyjną implementację zaufanej aplikacji (libeic), której można użyć do wdrożenia systemu danych tożsamości.

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 „przywracanie danych fabrycznych”, gdy interfejs API DevicePolicyManager.wipeData() jest wywoływany przez aplikację kontrolera zasad dotyczących urządzeń 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ądzeń i ustawiła flagę UserManager.DISALLOW_SAFE_BOOT na wartość „prawda”.

• [C-1-2] MUSI umożliwiać użytkownikowi odinstalowywanie 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. Izolacja 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 zabezpieczeń poniżej warstw platformy Android, aby zapobiec szkodliwym 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 WOLNO 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 klucza 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ą sekcje 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 wiele 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 w celu testowania funkcji, których nie można sprawdzić za pomocą automatycznego systemu, np. prawidłowego działania aparatu 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] MUSZĄ przejść wszystkie testy sprzętu, który posiadają. Na przykład, jeśli urządzenie ma akcelerometr, MUSI poprawnie wykonać test akcelerometru w CTS Verifier.

Przypadki testowe funkcji oznaczonych w tym dokumencie definicji zgodności jako opcjonalne MOGĄ zostać pominięte.

• [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 ponowne uruchomienie urządzenia MOŻE być wymagane. Możesz użyć dowolnej metody, o ile umożliwia ona zastąpienie całego oprogramowania wstępnie zainstalowanego na urządzeniu. Wymaganie to spełnia np. każda z tych metod:

  • 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ą algorytmu SHA-256 i sprawdzić skrót za pomocą klucza publicznego przy użyciu algorytmu ECDSA NIST P-256.

Jeśli implementacja urządzenia obejmuje obsługę połączenia z nieograniczonym transferem danych, takiego jak 802.11 lub profil Bluetooth PAN (Personal Area Network), wówczas:

• [C-1-1] MUSI obsługiwać pobieranie aktualizacji OTA z aktualizacją offline przez ponowne uruchomienie.

Implementacje urządzeń POWINNY sprawdzać, czy obraz systemu jest binarnie identyczny z oczekiwanym wynikiem po aktualizacji OTA. Implementacja aktualizacji OTA opartej na blokach w projekcie Android Open Source Project, dodana od Androida 5.1, spełnia to wymaganie.

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.