Ta strona została przetłumaczona przez Cloud Translation API.

Definicja zgodności z Androidem 11

1. Wprowadzenie

Ten dokument zawiera listę wymagań, które muszą zostać spełnione, aby urządzenia były zgodne z Androidem 11.

Użycie słów „MUST”, „MUST NOT”, „REQUIRED”, „SHALL”, „SHALL NOT”, „SHOULD”, „SHOULD NOT”, „RECOMMENDED”, „MAY” i „OPTIONAL” jest zgodne ze standardem IETF zdefiniowanym w RFC2119.

W tym dokumencie „implementator urządzenia” to osoba lub organizacja opracowująca rozwiązanie sprzętowe lub programowe na Androida 11. „Wdrożenie urządzenia” lub „wdrożenie” to opracowane rozwiązanie sprzętowe lub programowe.

Aby uznać urządzenie za zgodne z Androidem 11, jego implementacja MUSI spełniać wymagania podane w tej definicji zgodności, w tym wszelkie dokumenty uwzględnione w dokumentach referencyjnych.

Jeśli definicja lub testy oprogramowania opisane w sekcji 10 są niejasne, niepełne lub nieprecyzyjne, implementator urządzenia musi zadbać o zgodność z dotychczasowymi implementacjami.

Z tego powodu Android Open Source Project jest zarówno referencyjnym, jak i preferowanym wdrożeniem Androida. Wdrożeniom urządzeń MOCNO zaleca się, aby w jak największym stopniu opierać swoje implementacje na „upstreamowym” kodzie źródłowym dostępnym w ramach Projektu Android Open Source. Chociaż niektóre komponenty można teoretycznie zastąpić alternatywnymi implementacjami, ZDECYDOWANIE zalecamy, aby nie stosować tej praktyki, ponieważ przejście testów oprogramowania będzie znacznie trudniejsze. Obowiązkiem implementatora jest zapewnienie pełnej zgodności z zachowaniem standardowej implementacji Androida, w tym w ramach pakietu testów zgodności i poza nim. Pamiętaj, że niektóre wymiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.

Wiele zasobów, do których linki znajdują się w tym dokumencie, pochodzi bezpośrednio lub pośrednio z pakietu SDK Androida i pod względem funkcjonalności jest identyczne z informacjami w dokumentacji tego pakietu. W każdym przypadku, gdy definicja zgodności lub zestaw testów zgodności są niezgodne z dokumentacją pakietu SDK, decydująca jest dokumentacja pakietu SDK. Wszelkie szczegóły techniczne podane w powiązanych zasobach w tym dokumencie są uznawane za część tej definicji zgodności.

1.1 Struktura dokumentu

1.1.1. Wymagania według typu urządzenia

Sekcja 2 zawiera wszystkie wymagania dotyczące konkretnego typu urządzenia. Każda sekcja w sekcji 2 dotyczy konkretnego typu urządzenia.

Pozostałe wymagania, które obowiązują w przypadku wszystkich implementacji urządzeń z Androidem, są wymienione w sekcjach po sekcji 2. W tym dokumencie te wymagania są określane jako „Wymagania podstawowe”.

1.1.2. Identyfikator wymagań

Identyfikator wymagania jest przypisany do wymagań MUST.

Identyfikator jest przypisany tylko do wymagań MUST.
Wymagania ZALECANE są oznaczone jako [SR], ale nie przypisano identyfikatora.
Identyfikator składa się z identyfikatora typu urządzenia, identyfikatora stanu i identyfikatora wymagań (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 stosowane do wszystkich implementacji na urządzeniach z Androidem)
- H: urządzenie przenośne z Androidem
- T: urządzenie z Androidem TV
- Odp.: wdrożenie Androida Automotive
- W: Implementacja na zegarku z Androidem
- Karta: implementacja na tabletach z Androidem
Identyfikator warunku
- Gdy wymaganie jest bezwarunkowe, ten identyfikator ma wartość 0.
- Jeśli wymagania są warunkowe, dla pierwszego warunku przypisuje się wartość 1, a w ramach tej samej sekcji i tego samego typu urządzenia liczba ta zwiększa się o 1.
Identyfikator wymagań:
- Ten identyfikator zaczyna się od 1 i zwiększa się o 1 w tej samej sekcji i przy tej samej wartości warunku.

1.1.3. Identyfikator wymagań w sekcji 2

Identyfikator wymagań w sekcji 2 zaczyna się od odpowiedniego identyfikatora sekcji, a za nim następuje identyfikator wymagań opisany powyżej.

Identyfikator w sekcji 2 składa się z identyfikatora sekcji / identyfikatora typu urządzenia – identyfikatora warunku – identyfikatora wymagań (np. 7.4.3/A-0-1).

2. Typy urządzeń

Chociaż projekt Android Open Source udostępnia pakiet oprogramowania, który można stosować na różnych typach i w różnych formach urządzeń, istnieje kilka typów urządzeń, które mają stosunkowo lepiej rozwiniętą platformę dystrybucji aplikacji.

W tej sekcji opisano 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 podane w innych sekcjach tej Definicji zgodności.

2.1 Konfiguracje urządzenia

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

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

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

Implementacje urządzeń 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ę;
mieć fizyczną przekątną ekranu w zakresie od 3,3 cala (lub 2,5 cala w przypadku urządzeń z poziomem interfejsu API wcześniejszego niż Android 11) do 8 cali;

Dodatkowe wymagania w pozostałej części tej sekcji dotyczą implementacji na urządzeniach z Androidem.

Uwaga: wymagania, które nie mają zastosowania do urządzeń z Androidem w formie tabletu, są oznaczone gwiazdką (*).

2.2.1. Sprzęt

Implementacje na urządzeniach przenośnych:

[7.1.1.1/H-0-1] MUSI zawierać co najmniej 1 wyświetlacz zgodny z Androidem, który spełnia wszystkie wymagania opisane w tym dokumencie.
[7.1.1.3/H-SR] ZALECAMY, aby umożliwić użytkownikom zmianę rozmiaru wyświetlacza (gęstości ekranu).

Jeśli implementacje urządzeń przenośnych obsługują obrócenie ekranu za pomocą oprogramowania, mogą:

[7.1.1.1/H-1-1]* Ekran logiczny udostępniany aplikacjom zewnętrznym MUSI mieć co najmniej 5,08 cm(2 cale) na krótszych krawędziach i 6,35 cm(2,5 cala) na dłuższych krawędziach. Wymagania te nie dotyczą urządzeń, które zostały uruchomione na poziomie interfejsu API wcześniejszym niż ten opisany w tym dokumencie.

Jeśli implementacje urządzeń przenośnych nie obsługują obrócenia ekranu za pomocą oprogramowania, nie mogą:

[7.1.1.1/H-2-1]* Należy zapewnić, aby ekran logiczny udostępniany aplikacjom innych firm miał co najmniej 2,7 cala po krótszym boku. Wymagania te nie dotyczą urządzeń, które zostały uruchomione na poziomie interfejsu API wcześniejszym niż ten opisany w tym dokumencie.

Jeśli implementacje urządzeń przenośnych obsługują wyświetlacze o wysokim zakresie dynamicznym za pomocą Configuration.isScreenHdr() , muszą:

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

[7.1.4.6/H-0-1] MUST report whether the device supports the GPU profiling capability via a system property graphics.gpu.profiler.support.

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

[7.1.4.6/H-1-1] Musisz podać jako dane wyjściowe ślad protobuf zgodny ze schematem dotyczącym liczników GPU i etapy renderowania GPU zdefiniowanym w dokumentacji Perffetto.
[7.1.4.6/H-1-2] MUSI raportować wartości zgodne z licznikami GPU urządzenia zgodnie z protokołem gpu counter trace packet proto.
[7.1.4.6/H-1-3] MUSI raportować wartości zgodne z GPU RenderStages urządzenia zgodnie z protokołem render stage trace.
[7.1.4.6/H-1-4] MUSI raportować punkt śledzenia częstotliwości GPU zgodnie z formatem: power/gpu_frequency.

Implementacje na urządzeniach przenośnych:

[7.1.5/H-0-1] MUSI zawierać obsługę starszego trybu zgodności aplikacji, który jest implementowany przez kod źródłowy Androida open source. Oznacza to, że implementacje na urządzeniach 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 zawierać obsługę aplikacji innych firm do edycji metody wprowadzania.
[7.2.3/H-0-3] Musisz 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] Musisz zapewnić funkcję Wstecz na wszystkich wyświetlaczach zgodnych z Androidem oraz funkcję Ostatnie na co najmniej jednym wyświetlaczu zgodnym z Androidem.
[7.2.3/H-0-2] DO aplikacji na pierwszym planie należy wysłać zdarzenie naciśnięcia i długiego naciśnięcia przycisku Wstecz (KEYCODE_BACK). Te zdarzenia NIE MOGĄ być wykorzystywane przez system i MOGĄ być wywoływane z zewnątrz urządzenia z Androidem (np. za pomocą zewnętrznej klawiatury sprzętowej podłączonej do urządzenia z Androidem).
[7.2.4/H-0-1] MUSI obsługiwać wprowadzanie danych za pomocą ekranu dotykowego.
[7.2.4/H-SR] ZALECAMY uruchamianie wybranej przez użytkownika aplikacji asystenta, czyli aplikacji, która implementuje VoiceInteractionService, lub aktywności obsługującej 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] MOCNO zaleca się uwzględnienie 3-osiowego akcelerometru.

Jeśli implementacja urządzenia przenośnego zawiera 3-osiowy akcelerometr, urządzenie:

[7.3.1/H-1-1] MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.

Jeśli implementacje urządzeń przenośnych zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, mogą:

[7.3.3/H-2-1] MUST report GNSS measurements, as soon as they are found, even if a location calculated from GPS/GNSS is not yet reported.
[7.3.3/H-2-2] MUST report GNSS pseudoranges and pseudorange rates, that, in conditions open-sky after determining the location, while stationary or moving with less than 0.2 meter per second squared of acceleration, are sufficient to calculate position within 20 meters, and speed within 0.2 meters per second, at least 95% of the time.

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

[7.3.4/H-3-1] Musi być możliwe zgłaszanie 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 pliku getPhoneType:

[7.3.8/H] NALEŻY uwzględnić czujnik zbliżeniowy.

Implementacje na urządzeniach przenośnych:

[7.3.11/H-SR] Zaleca się obsługę czujnika postawy z 6 stopniami swobody.
[7.4.3/H] NALEŻY uwzględnić obsługę Bluetooth i Bluetooth LE.

Jeśli implementacje urządzeń przenośnych obejmują połączenie z limitem danych, mogą:

[7.4.7/H-1-1] MUSI udostępniać tryb oszczędzania danych.

Jeśli implementacje urządzeń przenośnych zawierają logiczne urządzenie z kamerą, które wymienia funkcje za pomocą CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, to:

[7.5.4/H-1-1] Domyślnie musi mieć normalne pole widzenia (FOV) w zakresie 50–90 stopni.

Implementacje na urządzeniach przenośnych:

[7.6.1/H-0-1] Na potrzeby prywatnych danych aplikacji (czyli na partycji „/data”) musi być dostępne co najmniej 4 GB pamięci nieulotnej.
[7.6.1/H-0-2] MUSI zwracać „true” dla ActivityManager.isLowRamDevice(), gdy dla jądra i przestrzeni użytkownika jest dostępne mniej niż 1 GB pamięci.

Jeśli implementacje na urządzeniach przenośnych deklarują obsługę tylko 32-bitowego 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 używa rozdzielczości bufora ramki do qHD (np. FWVGA).
[7.6.1/H-2-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 592 MB, jeśli domyślny wyświetlacz używa rozdzielczości framebuffera do HD+ (np. HD, WSVGA).
[7.6.1/H-3-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 896 MB, jeśli domyślny wyświetlacz używa 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 wynosić co najmniej 1344 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora ramki do QHD (np. QWXGA).

Jeśli implementacje urządzeń przenośnych deklarują obsługę dowolnego 64-bitowego ABI (z dowolnym 32-bitowym 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 używa 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 używa rozdzielczości framebuffera do HD+ (np. HD, WSVGA).
[7.6.1/H-7-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1280 MB, jeśli domyślny wyświetlacz używa 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 używa rozdzielczości bufora ramki do QHD (np. QWXGA).

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do pamięci udostępnionej dodatkowo do pamięci już przeznaczonej na komponenty sprzętowe, takie jak radio, wideo itp., które nie są kontrolowane przez jądro w implementacjach urządzenia.

Jeśli implementacje urządzeń przenośnych mają mniej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, nie spełniają wymagań:

[7.6.1/H-9-1] NALEŻY zadeklarować flagę funkcji android.hardware.ram.low.
[7.6.1/H-9-2] Musisz mieć co najmniej 1,1 GB pamięci nieulotnej na dane prywatne aplikacji (czyli na partycję „/data”).

Jeśli implementacje urządzeń przenośnych zawierają więcej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, to:

[7.6.1/H-10-1] Dostępny musi być co najmniej 4 GB pamięci nieulotnej na potrzeby danych prywatnych aplikacji (czyli partycji „/data”).
NALEŻY zadeklarować flagę funkcji android.hardware.ram.normal.

Implementacje na urządzeniach przenośnych:

[7.6.2/H-0-1] NIE MOŻESZ udostępnić aplikacji miejsca na dane mniejszego niż 1 GiB.
[7.7.1/H] NALEŻY uwzględnić port USB obsługujący tryb peryferyjny.

Jeśli implementacje urządzeń przenośnych zawierają port USB obsługujący tryb urządzeń peryferyjnych, muszą:

[7.7.1/H-1-1] MUSI implementować interfejs API Open Accessory (AOA) na Androida.

Jeśli implementacje urządzeń przenośnych zawierają port USB obsługujący tryb hosta, muszą:

[7.7.2/H-1-1] NALEŻY zaimplementować klasę audio USB zgodnie z dokumentacją pakietu Android SDK.

Implementacje na urządzeniach przenośnych:

[7.8.1/H-0-1] MUSI zawierać mikrofon.
[7.8.2/H-0-1] MUSI mieć wyjście audio i być zadeklarowane jako android.hardware.audio.output.

Jeśli implementacje urządzeń przenośnych spełniają wszystkie wymagania dotyczące wydajności w trybie VR i obsługują ten tryb, muszą:

[7.9.1/H-1-1] NALEŻY zadeklarować flagę funkcji android.hardware.vr.high_performance.
[7.9.1/H-1-2] Musisz umieścić w aplikacji funkcję android.service.vr.VrListenerService, którą można włączyć w aplikacji VR za pomocą android.app.Activity#setVrModeEnabled.

Jeśli implementacja urządzenia przenośnego obejmuje co najmniej 1 port USB-C w trybie hosta i implementuje (klasa audio USB), oprócz wymagań podanych w sekcji 7.7.2:

[7.8.2.2/H-1-1] NALEŻY podać następujące mapowanie kodu HID w oprogramowaniu:

Funkcja	Mapowania	Kontekst	Działanie
A	Strona dotyczącej 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
		Odtwarzanie multimediów	Wejście: długie naciśnięcie Wyjście: polecenie głosowe Wyślij: `android.speech.action.VOICE_SEARCH_HANDS_FREE` jeśli urządzenie jest zablokowane lub ma wyłączony ekran. W innym przypadku `android.speech.RecognizerIntent.ACTION_WEB_SEARCH`
		Połączenie przychodzące	Dane wejściowe: krótkie naciśnięcie Dane wyjściowe: zaakceptuj połączenie
		Połączenie przychodzące	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
		Trwa rozmowa	Wejście: naciśnij i przytrzymaj Wyjście: wycisz lub wyłącz wyciszenie mikrofonu
B	Strona użycia HID: 0x0C Użycie HID: 0x0E9 Klucz jądra: `KEY_VOLUMEUP` Klucz Androida: `VOLUME_UP`	Odtwarzanie multimediów, Trwające połączenie	Wejście: krótkie lub długie naciśnięcie Wyjście: zwiększa głośność systemu lub zestawu słuchawkowego
C	Strona użycia HID: 0x0C Użycie HID: 0x0EA Klucz jądra: `KEY_VOLUMEDOWN` Klucz Androida: `VOLUME_DOWN`	Odtwarzanie multimediów, Trwające połączenie	Wejście: krótkie lub długie naciśnięcie Wyjście: zmniejsza głośność systemu lub zestawu słuchawkowego
D	Strona dotyczące użycia HID: 0x0C Użycie HID: 0x0CF Klucz jądra: `KEY_VOICECOMMAND` Klucz Androida: `KEYCODE_VOICE_ASSIST`	Wszystkie. Może być wywoływany w dowolnej instancji.	Wejście: krótkie lub długie naciśnięcie Wyjście: polecenie głosowe

[7.8.2.2/H-1-2] NALEŻY wywołać ACTION_HEADSET_PLUG po włożeniu wtyczki, ale dopiero po prawidłowym zliczeniu interfejsów audio USB i punktów końcowych w celu identyfikacji typu podłączonego terminala.

Po wykryciu terminala audio USB typu 0x0302:

[7.8.2.2/H-2-1] MUST broadcast Intent ACTION_HEADSET_PLUG with "microphone" extra set to 0.

Gdy wykryto typy terminali audio USB 0x0402,:

[7.8.2.2/H-3-1] MUST broadcast Intent ACTION_HEADSET_PLUG with "microphone" extra set to 1.

Gdy wywołysz interfejs API AudioManager.getDevices() podczas podłączania urządzenia peryferyjnego USB, wykonaj te czynności:

[7.8.2.2/H-4-1] NALEŻY podać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i role isSink(), jeśli pole typu terminala audio USB ma wartość 0x0302.
[7.8.2.2/H-4-2] NALEŻY podać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i role isSink(), jeśli pole typu terminala audio USB ma wartość 0x0402.
[7.8.2.2/H-4-3] MUST list a device of type AudioDeviceInfo.TYPE_USB_HEADSET and role isSource() if the USB audio terminal type field is 0x0402.
[7.8.2.2/H-4-4] Musisz podać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSink(), jeśli pole typu terminala audio USB ma wartość 0x603.
[7.8.2.2/H-4-5] Musisz podać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSource(), jeśli pole typu terminala audio USB ma wartość 0x604.
[7.8.2.2/H-4-6] NALEŻY podać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSink(), jeśli pole typu terminala audio USB ma wartość 0x400.
[7.8.2.2/H-4-7] W przypadku pola typu terminala audio USB o wartości 0x400 MUSI być podany typ urządzenia AudioDeviceInfo.TYPE_USB_DEVICE i rola isSource().
[7.8.2.2/H-SR] Zaleca się, aby po podłączeniu urządzenia peryferyjnego do portu audio USB-C wykonać enumerację identyfikatorów USB, zidentyfikować typy terminali i wykonać transmisję intencji ACTION_HEADSET_PLUG w mniej niż 1000 ms.

Jeśli implementacje urządzeń przenośnych zawierają co najmniej 1 aktywator haptyczny, muszą:

[7.10/H-SR]* Zdecydowanie zalecamy NIEużywanie wibratora z ekscentryczną masą wirnikową (ERM).
[7.10/H]* Należy umieścić siłownik w pobliżu miejsca, w którym urządzenie jest zwykle trzymane lub dotykane rękami.
[7.10/H-SR]* BARDZO ZALECAMY implementację wszystkich publicznych stałych wartości clear haptics w android.view.HapticFeedbackConstants, a precyzyjniej (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).
[7.10/H-SR]* BARDZO ZALECAMY zaimplementowanie wszystkich publicznych stałych dotyczących czystych wibracji haptycznych w android.os.VibrationEffect, a precyzyjniej (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK i EFFECT_DOUBLE_CLICK), oraz wszystkich publicznych stałych dotyczących bogatych wibracji haptycznych w android.os.VibrationEffect.Composition, a precyzyjniej (PRIMITIVE_CLICK i PRIMITIVE_TICK).
[7.10/H-SR]* Zdecydowanie zalecamy używanie tych połączonych mapowań stałych wibracji .
[7.10/H-SR]* MOCNO zalecamy stosowanie oceny jakości w przypadku interfejsów API createOneShot() i createWaveform().
[7.10/H-SR]* MOCNO POLECAMY sprawdzenie możliwości skalowania amplitudy przez uruchomienie android.os.Vibrator.hasAmplitudeControl().

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

Jeśli implementacje urządzeń przenośnych zawierają co najmniej 1 aktywator rezonansowy liniowy, muszą:

[7.10/H]* NALEŻY przesunąć siłownik haptyczny wzdłuż osi X w orientacji pionowej.

Jeśli implementacje urządzeń przenośnych mają siłownik haptyczny, który jest liniowym siłnikiem rezonansowym (LRA) na osi X, muszą:

[7.10/H-SR]* Zdecydowanie zalecamy, aby częstotliwość rezonansowa LRA osi X była niższa niż 200 Hz.

Jeśli implementacje na urządzeniach przenośnych przestrzegają mapowania stałych wartości haptycznych, muszą:

[7.10/H-SR]* MOCNO zalecamy przeprowadzenie oceny jakości dla stałych haptycznych.

2.2.2. Multimedia

Implementacje urządzeń przenośnych 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 (ulepszona jakość dźwięku AAC z małym opóźnieniem)

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

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

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

2.2.3. Oprogramowanie

Implementacje na urządzeniach przenośnych:

[3.2.3.1/H-0-1] Aplikacja MUSI obsługiwać intencje ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE i ACTION_CREATE_DOCUMENT zgodnie z opisem w dokumentacji pakietu SDK oraz udostępniać użytkownikowi możliwość uzyskania dostępu do danych dostawcy dokumentów za pomocą interfejsu API DocumentsProvider.
[3.2.3.1/H-0-2]* W przypadku wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez wymienione tutaj intencje aplikacji MUSISZ wstępnie wczytać co najmniej 1 aplikację lub komponent usługi z obsługą intencji.
[3.2.3.1/H-SR] Zdecydowanie zalecamy wstępne załadowanie aplikacji poczty e-mail, która może obsługiwać intencje ACTION_SENDTO, ACTION_SEND lub ACTION_SEND_MULTIPLE w celu wysłania e-maila.
[3.4.1/H-0-1] Musisz wdrożyć interfejs API android.webkit.Webview.
[3.4.2/H-0-1] Musisz udostępnić samodzielną aplikację przeglądarki do ogólnego przeglądania Internetu przez użytkownika.
[3.8.1/H-SR] MOCNO POLECAMY implementację domyślnej aplikacji, która obsługuje przypinanie skrótów, widżetów i widgetFeatures w aplikacji.
[3.8.1/H-SR] MOCNO zalecamy wdrożenie domyślnej aplikacji uruchamiającej, która zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu ShortcutManager API.
[3.8.1/H-SR] MOCNO zalecamy dodanie domyślnej aplikacji uruchamiającej, która wyświetla plakietki dla ikon aplikacji.
[3.8.2/H-SR] Zaleca się obsługę widżetów aplikacji innych firm.
[3.8.3/H-0-1] Musisz zezwolić aplikacjom innych firm na powiadamianie użytkowników o istotnych zdarzeniach za pomocą klas interfejsu API Notification i NotificationManager.
[3.8.3/H-0-2] Musi obsługiwać powiadomienia z elementami rozszerzonymi.
[3.8.3/H-0-3] MUSI obsługiwać powiadomienia typu heads-up.
[3.8.3/H-0-4] Musi zawierać panel powiadomień, który umożliwia użytkownikowi bezpośrednie zarządzanie powiadomieniami (np. odpowiadanie na nie, odkładanie, zamykanie i blokowanie) za pomocą przycisków akcji lub panelu sterowania zaimplementowanego w AOSP.
[3.8.3/H-0-5] W obszarze powiadomień MUSI wyświetlać opcje dostępne w RemoteInput.Builder setChoices().
[3.8.3/H-SR] MOCNO ZALECAMY wyświetlanie w pasku powiadomień pierwszej opcji dostępnej w RemoteInput.Builder setChoices() bez dodatkowej interakcji użytkownika.
[3.8.3/H-SR] ZALECAMY wyświetlanie wszystkich opcji udostępnionych w RemoteInput.Builder setChoices() w obszarze powiadomień, gdy użytkownik rozwinie wszystkie powiadomienia w obszarze powiadomień.
[3.8.3.1/H-SR] NALEŻY WYŚWIETLAC OPCJE, dla których Notification.Action.Builder.setContextual jest ustawiona jako true zgodnie z odpowiedziami wyświetlanymi przez Notification.Remoteinput.Builder.setChoices.
[3.8.4/H-SR] MOCNO POLECAMY wdrożenie na urządzeniu asystenta, aby obsłużyć działanie asystenta.

Jeśli implementacje na urządzeniach przenośnych obsługują działanie Asystenta, mogą:

[3.8.4/H-SR] MOCNO POLECAMY użycie długiego naciśnięcia przycisku HOME jako wyznaczonej interakcji w celu uruchomienia aplikacji asystenta zgodnie z opisem w sekcji 7.2.3. MUSI uruchamiać wybraną przez użytkownika aplikację asystenta, czyli aplikację, która implementuje VoiceInteractionService, lub aktywność obsługującą intencję ACTION_ASSIST.

Jeśli implementacje na urządzeniach przenośnych obsługują conversation notifications i umieszczają je w oddzielnej sekcji od powiadomień z dźwiękiem i bez dźwięku, które nie są powiązane z konwersacją, to:

[3.8.4/H-1-1]* NALEŻY wyświetlać powiadomienia o rozmowie przed powiadomieniami o innych zdarzeniach, z wyjątkiem powiadomień o bieżącej usłudze na pierwszym planie i powiadomień o istocie:wysoka.

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

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

Jeśli implementacje urządzeń przenośnych obsługują bezpieczny ekran blokady, muszą:

[3.9/H-1-1] NALEŻY wdrożyć pełny zakres zasad zarządzania urządzeniem zdefiniowanych w dokumentacji pakietu Android SDK.
[3.9/H-1-2] MUSI deklarować obsługę profili zarządzanych za pomocą flagi funkcji android.software.managed_users, z wyjątkiem sytuacji, gdy urządzenie jest skonfigurowane tak, aby zgłaszało się jako urządzenie z małą ilością pamięci RAM lub przydzielało pamięć wewnętrzną (niewymienną) jako pamięć współdzielona.

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

[3.8.16/H-1-1] NALEŻY zadeklarować flagę funkcji android.software.controls i ustawić ją na true.
[3.8.16/H-1-2] Musisz umożliwić użytkownikowi dodawanie, edytowanie, wybieranie i sterowanie ulubionymi elementami sterowania urządzeniami z użyciem elementów zarejestrowanych przez aplikacje innych firm za pomocą interfejsów ControlsProviderService i Control.
[3.8.16/H-1-3] MUSISZ zapewnić użytkownikowi dostęp do tej funkcji w ciągu 3 interakcji z domyślnym menu z aplikacjami.
[3.8.16/H-1-4] W tym interfejsie użytkownika MUSI być prawidłowo wyświetlana nazwa i ikona każdej aplikacji innej firmy, która udostępnia elementy sterujące za pomocą interfejsu ControlsProviderService API, a także wszystkie pola określone przez interfejsy Control API.

Jeśli implementacja na urządzeniach przenośnych nie zawiera takich elementów sterujących, to:

[3.8.16/H-2-1] MUST report null for the ControlsProviderService and the Control APIs.
[3.8.16/H-2-2] NALEŻY zadeklarować flagę funkcji android.software.controls i ustawić ją na false.

Implementacje na urządzeniach przenośnych:

[3.10/H-0-1] MUSI obsługiwać usługi dostępności innych firm.
[3.10/H-SR] Zdecydowanie zalecamy wstępne załadowanie na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z funkcjonalnością usług Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) w ramach projektu TalkBack open source.
[3.11/H-0-1] MUSI obsługiwać instalację zewnętrznych silników TTS.
[3.11/H-SR] MOCNO zaleca się uwzględnienie mechanizmu TTS obsługującego języki dostępne na urządzeniu.
[3.13/H-SR] ZALECAMY, aby uwzględnić komponent UI Szybkich ustawień.

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

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

Jeśli funkcja nawigacji jest obsługiwana jako działanie na ekranie oparte na gestach:

[7.2.3/H] Strefa rozpoznawania gestów w funkcji Home powinna mieć wysokość nie większą niż 32 dp od dołu ekranu.

Jeśli implementacje na urządzeniach przenośnych umożliwiają nawigację za pomocą gestów wykonywanych w dowolnym miejscu po lewej i prawej stronie ekranu:

[7.2.3/H-0-1] Szerokość obszaru gestów funkcji nawigacji MUSI być mniejsza niż 40 dp po każdej stronie. Domyślna szerokość obszaru gestów powinna wynosić 24 dp.

2.2.4. Wydajność i moc

[8.1/H-0-1] Stała wartość opóźnienia ramki. Niespójny czas oczekiwania na renderowanie klatek lub opóźnienie w renderowaniu klatek NIE MOŻE występować częściej niż 5 razy na sekundę, a jego wartość POWINNA być mniejsza niż 1 raz na sekundę.
[8.1/H-0-2] Czas reakcji interfejsu użytkownika. Implementacje urządzeń MUSZĄ zapewniać użytkownikom niskie opóźnienia, umożliwiając przewijanie listy 10 tys. pozycji w mniej niż 36 sekund, zgodnie z definicją w pakiecie testów zgodności Androida (CTS).
[8.1/H-0-3] Przełączanie zadań. Gdy uruchomionych jest kilka aplikacji, ponowne uruchomienie już uruchomionej aplikacji MUSI zająć mniej niż 1 sekundę.

Implementacje na urządzeniach przenośnych:

[8.2/H-0-1] MUSI zapewnić wydajność zapisu sekwencyjnego co najmniej 5 MB/s.
[8.2/H-0-2] MUSI zapewnić wydajność zapisu losowego co najmniej 0,5 MB/s.
[8.2/H-0-3] MUSI zapewnić wydajność odczytu sekwencyjnego co najmniej 15 MB/s.
[8.2/H-0-4] MUSI zapewnić wydajność losowego odczytu 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, muszą:

[8.3/H-1-1] MUSISZ umożliwić użytkownikowi włączenie i wyłączenie funkcji oszczędzania baterii.
[8.3/H-1-2] Musisz umożliwić użytkownikowi wyświetlanie wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.

Implementacje na urządzeniach przenośnych:

[8.4/H-0-1] MUSISZ podać profil zużycia energii dla poszczególnych komponentów, który definiuje wartość bieżącego zużycia energii dla każdego komponentu sprzętowego oraz przybliżony czas rozładowania baterii spowodowany przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
[8.4/H-0-2] Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
[8.4/H-0-3] MUST report CPU power consumption per each process's UID. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
[8.4/H-0-4] DEWELOPER APLIKACJI MUSI udostępnić ten pobór mocy za pomocą polecenia adb shell dumpsys batterystats w powłoce.
[8,4/h] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.

Jeśli implementacje urządzeń przenośnych obejmują ekran lub wyjście wideo, muszą spełniać te wymagania:

[8.4/H-1-1] MUSI obsługiwać intencję android.intent.action.POWER_USAGE_SUMMARY i wyświetlać menu ustawień, które pokazuje zużycie energii.

2.2.5. Model zabezpieczeń

Implementacje na urządzeniach przenośnych:

[9.1/H-0-1] Musisz zezwolić aplikacjom innych firm na dostęp do statystyk użycia za pomocą uprawnienia android.permission.PACKAGE_USAGE_STATS i zapewnić użytkownikom mechanizm umożliwiający przyznawanie i odbieranie dostępu do takich aplikacji w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Implementacje na urządzeniach przenośnych (* Nie dotyczy tabletów):

[9.11/H-0-2]* Musisz utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
[9.11/H-0-3]* Musisz mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać obsługiwane algorytmy systemu Keystore na Androidzie 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 kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source Project (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
[9.11/H-0-4]* NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonywania i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem tylko wtedy, gdy proces uwierzytelniania się powiedzie. Dane uwierzytelniające na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w odizolowanym środowisku wykonania. Projekt Android Open Source udostępnia interfejs HAL (Gatekeeper Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.
[9.11/H-0-5]* MUSI obsługiwać atestacjowanie klucza, w którym klucz podpisujący jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania certyfikatów MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻNA użyć innego klucza.

Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi spełniać wymagań dotyczących posiadania repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania ani obsługiwać uwierzytelniania klucza, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania.

Gdy implementacje urządzeń przenośnych obsługują bezpieczny ekran blokady, mogą:

[9.11/H-1-1] Musisz umożliwić użytkownikowi wybranie najkrótszego czasu bezczynności w trybie uśpienia, czyli czasu przejścia z otwartego do zamkniętego stanu, nie dłuższego niż 15 sekund.
[9.11/H-1-2] MUSISZ umożliwić użytkownikowi ukrywanie powiadomień i wyłączanie wszystkich form uwierzytelniania z wyjątkiem podstawowego uwierzytelniania opisanego w sekcji 9.11.1 Bezpieczny ekran blokady. AOSP spełnia wymagania dotyczące trybu blokady.

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

[9.5/H-2-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która pozwala właścicielom urządzeń zarządzać 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 dla dodatkowych użytkowników, a także zarządzać 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, muszą:

[9.5/H-3-1] NIE MUSI obsługiwać profili z ograniczonymi uprawnieniami, ale MUSI być zgodny z implementacją ustawień w AOSP, aby umożliwić /zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

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

Implementacje na urządzeniach przenośnych (* Nie dotyczy tabletów):

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

Implementacje na urządzeniach przenośnych (* Nie dotyczy tabletów):

Perfetto
- [6.1/H-0-2]* Musisz udostępnić użytkownikowi powłoki plik binarny /system/bin/perfetto, którego wiersz poleceń jest zgodny z dokumentacją perfetto.
- [6.1/H-0-3]* Plik binarne perfetto MUSI akceptować jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/H-0-4]* Binarny plik perfetto MUSI zapisywać jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/H-0-5]* Musisz udostępnić za pomocą binarnego pliku perfetto co najmniej te źródła danych, które są opisane w dokumentacji perfetto.
- [6.1/H-0-6]* Demon persist.traced.enable musi być włączony domyślnie (właściwość systemowa).

2.2.7 Klasa wydajności urządzeń mobilnych

Definicję klasy skuteczności mediów znajdziesz w sekcji 7.11.

2.2.7.1. Multimedia

Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.R dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

[5.1/H-1-1] MUST advertise the maximum number of hardware video decoder sessions that can be run concurrently in any codec combination via the CodecCapabilities.getMaxSupportedInstances() and VideoCapabilities.getSupportedPerformancePoints() methods.
[5.1/H-1-2] MUSI obsługiwać 6 sesji sprzętowego dekodera wideo (AVC lub HEVC) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p przy 30 fps.
[5.1/H-1-3] NALEŻY reklamować maksymalną liczbę sesji kodowania wideo za pomocą kodeka sprzętowego, które mogą być wykonywane jednocześnie w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-4] MUSI obsługiwać 6 sesji sprzętowego kodera wideo (AVC lub HEVC) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p z szybkością 30 fps.
[5.1/H-1-5] NALEŻY podać maksymalną liczbę sesji kodowania i dekodowania wideo za pomocą sprzętowego kodera, które mogą być wykonywane jednocześnie w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-6] MUSI obsługiwać 6 sesji sprzętowego dekodera wideo i sprzętowego kodera wideo (AVC lub HEVC) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p przy 30 fps.
[5.1/H-1-7] W przypadku sesji kodowania wideo w rozdzielczości 1080p lub niższej dla wszystkich kodeków wideo sprzętowych (z wyjątkiem kodeka Dolby Vision) czas opóźnienia inicjalizacji kodeka MUSI wynosić 65 ms lub mniej. Obciążenie jest tu zdefiniowane jako jednoczesna sesja transkodowania wideo z rozdzielczości 1080p na 720p przy użyciu kodeków wideo sprzętowych oraz inicjalizacja nagrywania dźwięku i obrazu w rozdzielczości 1080p.
[5.1/H-1-8] W przypadku sesji kodowania dźwięku o szybkości transmisji danych 128 kb/s lub niższej we wszystkich kodeki dźwięku opóźnienie inicjalizacji kodeka MUSI wynosić 50 ms lub mniej.Obciążenie zdefiniowano jako równoczesną sesję transkodowania obrazu w rozdzielczości 1080p lub 720p przy użyciu kodeków wideo sprzętowych wraz z inicjalizacją nagrywania dźwięku i obrazu w rozdzielczości 1080p.
[5.3/H-1-1] W przypadku sesji wideo 1080p z 30 klatkami na sekundę NIE MOŻE wystąpić więcej niż 1 utrata klatki w ciągu 10 sekund (czyli mniej niż 0,333 procent utraty klatek) podczas obciążenia. Obciążenie to jednoczesna sesja transkodowania wideo z 1080p na 720p z wykorzystaniem kodeków wideo sprzętowych oraz odtwarzanie dźwięku AAC 128 kbps.
[5.3/H-1-2] Nie wolno pominąć więcej niż 1 klatki w ciągu 10 sekund podczas zmiany rozdzielczości filmu w trakcie wczytywania obrazu z szybkością 30 FPS. Obciążenie jest zdefiniowane jako jednoczesna sesja transkodowania wideo z 1080p na 720p z wykorzystaniem kodeków wideo sprzętowych oraz odtwarzanie dźwięku AAC 128 kbps.
[5.6/H-1-1] Opóźnienie tap-to-tone musi być mniejsze niż 100 ms, gdy testuje się je za pomocą testu tap-to-tone OboeTester lub testu tap-to-tone CTS Verifier.

2.2.7.2. Aparat

Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.R dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

[7.5/H-1-1] Urządzenie MUSI mieć główną tylną kamerę o rozdzielczości co najmniej 12 Mpix, która umożliwia nagrywanie filmów w jakości 4K z częstotliwością 30 fps. Główny tylny aparat to tylny aparat o najniższym identyfikatorze.
[7.5/H-1-2] Musisz mieć główną kamerę przednią o rozdzielczości co najmniej 4 Mpix, która umożliwia nagrywanie filmów w rozdzielczości 1080p przy 30 fps. Główny aparat przedni to aparat przedni o najniższym identyfikatorze.
[7.5/H-1-3] MUSI obsługiwać właściwość android.info.supportedHardwareLevel jako FULL lub lepszą w przypadku głównego tylnego aparatu oraz LIMITED lub lepszą w przypadku głównego przedniego aparatu.
[7.5/H-1-4] MUSI obsługiwać CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME dla obu aparatów głównych.
[7.5/H-1-5] W przypadku rozdzielczości 1080p czas oczekiwania na JPEG z camera2 musi wynosić mniej niż 1000 ms, mierzony przez test PerformanceTest w ramach CTS w warunkach oświetlenia ITS (3000 K) dla obu głównych kamer.
[7.5/H-1-6] Czas oczekiwania na uruchomienie aplikacji camera2 (od otwarcia aplikacji do wyświetlenia pierwszego podglądu obrazu) musi być < 600 ms, mierzony za pomocą testu wydajności kamery CTS w warunkach oświetlenia ITS (3000 K) w przypadku obu głównych aparatów.

2.2.7.3. Sprzęt

Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.R dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

[7.1.1.1/H-1-1] Rozdzielczość ekranu MUSI wynosić co najmniej 1080p.
[7.1.1.3/H-1-1] gęstość pikseli na ekranie MUSI wynosić co najmniej 400 dpi.
[7.6.1/H-1-1] Musi mieć co najmniej 6 GB pamięci fizycznej.

2.2.7.4. Wydajność

Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.R dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

[8.2/H-1-1] MUSI zapewnić wydajność sekwencyjnego zapisu na poziomie co najmniej 100 MB/s.
[8.2/H-1-2] NALEŻY zapewnić wydajność zapisu losowego co najmniej 10 MB/s.
[8.2/H-1-3] MUSI zapewnić wydajność odczytu sekwencyjnego co najmniej 200 MB/s.
[8.2/H-1-4] MUSI zapewnić wydajność losowego odczytu na poziomie co najmniej 25 MB/s.

2.3. Wymagania dotyczące telewizorów

Urządzenie Android TV to urządzenie z Androidem, które jest interfejsem rozrywkowym do korzystania z multimediów, filmów, gier, aplikacji lub telewizji na żywo. Jest przeznaczone dla użytkowników, którzy siedzą w odległości około 3 metrów (interfejs „lean back” lub „10-foot user interface”).

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

udostępnić 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 ekran o przekątnej większej niż 24 cale LUB mieć port wyjścia wideo, np. VGA, HDMI, DisplayPort lub bezprzewodowy port wyświetlacza;

Pozostałe wymagania w tej sekcji dotyczą implementacji na urządzeniach z Androidem TV.

2.3.1. Sprzęt

Implementacje na telewizorach:

[7.2.2/T-0-1] MUSI obsługiwać D-pad.
[7.2.3/T-0-1] MUSI zawierać funkcje Wróć i Strona główna.
[7.2.3/T-0-2] DO aplikacji na pierwszym planie należy wysłać zdarzenie naciśnięcia i długiego naciśnięcia przycisku Wstecz (KEYCODE_BACK).
[7.2.6.1/T-0-1] MUSI zawierać obsługę kontrolerów gier i ogłosić flagę funkcji android.hardware.gamepad.
[7.2.7/T] NALEŻY zapewnić zdalne sterowanie, za pomocą którego użytkownicy mogą korzystać z nawigacji bezdotykowej i podstawowych przycisków nawigacyjnych.

Jeśli implementacje telewizorów zawierają 3-osiowy żyroskop, muszą:

[7.3.4/T-1-1] MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
[7.3.4/T-1-2] MUSI umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę.

Implementacje na telewizorach:

[7.4.3/T-0-1] MUSI obsługiwać Bluetooth i Bluetooth LE.
[7.6.1/T-0-1] Na potrzeby prywatnych danych aplikacji (czyli partycji „/data”) musi być dostępne co najmniej 4 GB pamięci nieulotnej.

Jeśli implementacje telewizorów zawierają port USB obsługujący tryb hosta, muszą:

[7.5.3/T-1-1] MUSI zawierać obsługę kamery zewnętrznej, która jest podłączona przez ten port USB, ale nie zawsze musi być 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 wynosić co najmniej 896 MB, jeśli używana jest dowolna z tych gęstości:
- 400 dpi lub więcej na małych/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 wynosić co najmniej 1280 MB, jeśli używana jest dowolna z tych gęstości:
- 400 dpi lub więcej na małych/normalnych ekranach
- xhdpi lub wyższa na dużych ekranach
- tvdpi lub wyższa na bardzo dużych ekranach.

Uwaga: „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do pamięci dostępnej oprócz pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro w implementacjach urządzenia.

Implementacje na telewizorach:

[7.8.1/T] NALEŻY uwzględnić 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 (ulepszona jakość dźwięku AAC z małym opóźnieniem)

Implementacje urządzeń telewizyjnych 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

Implementacje na telewizorach:

[5.2.2/T-SR] MOCNO POLECAMY obsługę kodowania H.264 filmów w rozdzielczości 720p i 1080p z szybkością 30 klatek na sekundę.

Implementacje urządzeń telewizyjnych 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

Implementacje urządzeń telewizyjnych MUSZĄ obsługiwać dekodowanie MPEG-2 zgodnie z opisem w sekcji 5.3.1 przy standardowych częstotliwościach klatek i rozdzielczościach do:

[5.3.1/T-1-1] HD 1080p przy 29,97 klatek na sekundę z profilem głównym High Level.
[5.3.1/T-1-2] HD 1080i przy 59,94 klatkach na sekundę z profilem głównym High Level. Muszą deinterlaceować przeplotowane wideo MPEG-2 i udostępnić je aplikacjom innych firm.

Implementacje telewizorów MUSZĄ obsługiwać dekodowanie H.264 zgodnie z opisem w sekcji 5.3.4 przy standardowych częstotliwościach klatek i rozdzielczościach wideo 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 klatkach na sekundę z profilem głównym
[5.3.4/T-1-3] HD 1080p przy 60 klatkach na sekundę z profilem wysokim poziomu 4.2

Implementacje telewizorów 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 i rozdzielczościach wideo do:

[5.3.5/T-1-1] HD 1080p przy 60 klatkach na sekundę z profilem głównym poziomu 4.1

Jeśli implementacje telewizorów 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 z szybkością 60 FPS z profilem Main10 Level 5 Main Tier

Implementacje telewizorów MUSZĄ obsługiwać dekodowanie VP8 zgodnie z opisem w sekcji 5.3.6 przy standardowych częstotliwościach klatek i rozdzielczościach wideo do:

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

Implementacje telewizorów z dekoderami sprzętowymi VP9 MUSZĄ obsługiwać dekodowanie formatu VP9 zgodnie z opisem w sekcji 5.3.7 przy standardowych częstotliwościach klatek i rozdzielczościach wideo do:

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

Jeśli implementacje telewizorów 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 z szybkością 60 klatek na sekundę w profilu 0 (głębia kolorów 8-bitowa).
[5.3.7/T-2-1] BARDZO ZALECAMY obsługę profilu dekodowania UHD z 60 klatkami na sekundę w profilu 2 (głębia kolorów 10 bitów).

Implementacje na telewizorach:

[5.5/T-0-1] MUSI obsługiwać systemowy głośność główną i obniżanie głośności wyjścia audio cyfrowego na obsługiwanych wyjściach, z wyjątkiem wyjścia z przepuszczaniem skompresowanego dźwięku (gdzie na urządzeniu nie jest przeprowadzane dekodowanie dźwięku).

Jeśli implementacje telewizorów nie mają wbudowanego wyświetlacza, ale obsługują wyświetlacz zewnętrzny podłączony przez HDMI, to:

[5.8/T-0-1] NALEŻY ustawić tryb wyjścia HDMI, aby wybrać maksymalną rozdzielczość, która może być obsługiwana przy częstotliwości odświeżania 50 Hz lub 60 Hz.
[5.8/T-SR] MOCNO ZALECAMY udostępnienie użytkownikowi opcji wyboru częstotliwości odświeżania HDMI.
[5.8] NALEŻY ustawić częstotliwość odświeżania w trybie 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 sprzedawane jest urządzenie.

Jeśli implementacje telewizorów nie mają wbudowanego wyświetlacza, ale obsługują wyświetlacz zewnętrzny podłączony przez HDMI, to:

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

Jeśli implementacje telewizorów nie obsługują dekodowania UHD, ale obsługują wyświetlacz zewnętrzny podłączony przez HDMI, to:

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

2.3.3. Oprogramowanie

Implementacje na telewizorach:

[3/T-0-1] NALEŻY zadeklarować funkcje android.software.leanback i android.hardware.type.television.
[3.2.3.1/T-0-1] W przypadku wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez te intencje aplikacji wymienione tutaj MUSISZ wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji.
[3.4.1/T-0-1] Musisz wdrożyć interfejs 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 multimedialnego.

Implementacje na telewizorach:

[3.8.14/T-SR] W przypadku trybu obrazu w obrazie (PIP) zaleca się obsługę trybu wielookiennego.
[3.10/T-0-1] MUSI obsługiwać zewnętrzne usługi ułatwień dostępu.
[3.10/T-SR] ZALECAMY WYMAGANIE wstępnego załadowania na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z funkcjonalnością usług Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) zgodnie z projektem TalkBack open source.

Jeśli implementacje telewizorów obsługują funkcję android.hardware.audio.output, to:

[3.11/T-SR] MOCNO zaleca się uwzględnienie silnika TTS obsługującego języki dostępne na urządzeniu.
[3.11/T-1-1] MUSI obsługiwać instalację silników TTS innych firm.

Implementacje na telewizorach:

[3.12/T-0-1] MUSI obsługiwać platformę TV Input Framework.

2.3.4. Wydajność i moc

[8.1/T-0-1] Stabilne opóźnienie klatek. Niespójny czas oczekiwania na renderowanie lub opóźnienie w renderowaniu klatek NIE MOŻE występować częściej niż 5 razy na sekundę, a jego wartość POWINNA być mniejsza niż 1 raz na sekundę.
[8.2/T-0-1] MUSI zapewnić wydajność sekwencyjnego zapisu co najmniej 5 MB/s.
[8.2/T-0-2] MUSI zapewnić wydajność zapisu losowego co najmniej 0,5 MB/s.
[8.2/T-0-3] NALEŻY zapewnić wydajność sekwencyjnego odczytu co najmniej 15 MB/s.
[8.2/T-0-4] NALEŻY zapewnić wydajność odczytu losowego co najmniej 3,5 MB/s.

Jeśli implementacje telewizorów zawierają funkcje poprawiające zarządzanie energią urządzenia, które są zawarte w AOSP, lub rozszerzają funkcje zawarte w AOSP, muszą:

[8.3/T-1-1] MUSISZ umożliwić użytkownikowi włączenie i wyłączenie funkcji oszczędzania baterii.

Jeśli implementacje telewizorów nie mają baterii:

[8.3/T-1-2] NALEŻY zarejestrować urządzenie jako urządzenie bez baterii zgodnie z opisem w artykule Obsługa urządzeń bez baterii.

Jeśli implementacje telewizorów mają baterię:

[8.3/T-1-3] Musisz umożliwić użytkownikowi wyświetlanie wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.

Implementacje na telewizorach:

[8.4/T-0-1] MUSI zawierać profil poboru mocy dla poszczególnych komponentów, który definiuje wartość bieżącego poboru energii dla każdego komponentu sprzętowego oraz przybliżony pobór energii z baterii spowodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
[8.4/T-0-2] Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
[8.4/T-0-3] MUST report CPU power consumption per each process's UID. 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 komponentu sprzętowego do aplikacji.
[8.4/T-0-4] DEWELOPER APLIKACJI MUSI udostępnić ten pobór mocy za pomocą polecenia adb shell dumpsys batterystats w powłoce.

2.3.5. Model zabezpieczeń

Implementacje na telewizorach:

[9.11/T-0-1] Musisz utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
[9.11/T-0-2] W ramach prawidłowego obsługiwania obsługiwanych algorytmów systemu Keystore na Androidzie w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze lub wyżej MUSZĄ być dostępne implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do wewnętrznego stanu odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source Project (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
[9.11/T-0-3] NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonania i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem tylko wtedy, gdy uwierzytelnianie się powiedzie. Dane uwierzytelniające na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w odizolowanym środowisku wykonania. Projekt Android Open Source udostępnia interfejs HAL (Gatekeeper Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.
[9.11/T-0-4] MUSI obsługiwać atestacjowanie klucza, w którym klucz do podpisywania jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane na bezpiecznym sprzęcie. Klucze podpisywania certyfikatów MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻNA użyć innego klucza.

Jeśli implementacje telewizorów obsługują bezpieczny ekran blokady, muszą:

[9.11/T-1-1] Musisz umożliwić użytkownikowi wybranie czasu przejścia w stan uśpienia z otwartego na zamknięty, z minimalnym dozwolonym czasem do 15 sekund.

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

[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 ograniczonymi uprawnieniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli implementacje telewizorów obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony, muszą:

[9.5/T-3-1] NIE MUSI obsługiwać profili z ograniczonymi uprawnieniami, ale MUSI być zgodna z implementacją ustawień w AOSP, aby umożliwić /zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

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

Implementacje na telewizorach:

Perfetto
- [6.1/T-0-1] NALEŻY udostępnić użytkownikowi powłoki binarny plik /system/bin/perfetto, którego wiersz poleceń jest zgodny z dokumentacją perfetto.
- [6.1/T-0-2] Binarny plik perfetto MUSI przyjmować jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/T-0-3] Binarny plik perfetto MUSI zapisywać jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/T-0-4] Musisz udostępnić za pomocą binarnego pliku perfetto co najmniej źródła danych opisane w dokumentacji perfetto.

2.4. Wymagania dotyczące zegarka

Urządzenie typu zegarek z Androidem to implementacja urządzenia z Androidem przeznaczona do noszenia na ciele, np. na nadgarstku.

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

mieć ekran o fizycznej przekątnej 1,1–2,5 cala;
mieć mechanizm umożliwiający noszenie na ciele;

Pozostałe wymagania w tej sekcji dotyczą implementacji na urządzeniach z Androidem Watch.

2.4.1. Sprzęt

Implementacje na urządzeniach z obsługą zegarka:

[7.1.1.1/W-0-1] Musi mieć ekran o fizycznej przekątnej o długości od 1,1 do 2,5 cala.
[7.2.3/W-0-1] Użytkownik MUSI mieć dostęp do funkcji Wróć do ekranu głównego oraz do funkcji Wróć, z wyjątkiem sytuacji, gdy jest ona w trybie UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] MUSI obsługiwać wprowadzanie danych za pomocą ekranu dotykowego.
[7.3.1/W-SR] MOCNO zaleca się uwzględnienie 3-osiowego akcelerometru.

Jeśli implementacje urządzeń Watch 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 zgłaszać pomiary GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
[7.3.3/W-1-2] MUST report GNSS pseudoranges and pseudorange rates, that, in conditions open-sky after determining the location, while stationary or moving with less than 0.2 meter per second squared of acceleration, are sufficient to calculate position within 20 meters, and speed within 0.2 meters per second, at least 95% of the time.

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

[7.3.4/W-2-1] MUSI umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę.

Implementacje na urządzeniach z obsługą zegarka:

[7.4.3/W-0-1] MUSI obsługiwać Bluetooth.
[7.6.1/W-0-1] Musi być dostępne co najmniej 1 GB pamięci nieulotnej na potrzeby danych prywatnych aplikacji (czyli na partycji „/data”).
[7.6.1/W-0-2] Musi być dostępne co najmniej 416 MB pamięci 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

Nie ma dodatkowych wymagań.

2.4.3. Oprogramowanie

Implementacje na urządzeniach z obsługą zegarka:

[3/W-0-1] NALEŻY 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] W przypadku wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez te intencje aplikacji wymienione tutaj NALEŻY wstępnie załadować co najmniej jedną aplikację lub komponent usługi z obsługą intencji.

Implementacje na urządzeniach z obsługą zegarka:

[3.8.4/W-SR] MOCNO ZALECAMY wdrożenie na urządzeniu asystenta, który obsłuży działanie asystenta.

Sprawdź implementacje na urządzeniach, które deklarują flagę funkcji android.hardware.audio.output:

[3.10/W-1-1] MUSI obsługiwać usługi dostępności innych firm.
[3.10/W-SR] Zdecydowanie zalecamy wstępne załadowanie na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z funkcjonalnością usług Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) zgodnie z projektem open source TalkBack.

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

[3.11/W-SR] MOCNO zaleca się uwzględnienie silnika TTS obsługującego języki dostępne na urządzeniu.
[3.11/W-0-1] MUSI obsługiwać instalację zewnętrznych silników TTS.

2.4.4. Wydajność i moc

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

[8.3/W-SR] W przypadku wszystkich aplikacji z wyłączonym trybem Standby i Doze MOCNO zalecamy wyświetlanie użytkownikowi informacji o tym, że aplikacja jest z niego wyłączona.
[8.3/W-SR] MOCNO ZALECAMY umożliwienie użytkownikowi włączenia i wyłączenia funkcji oszczędzania baterii.

Implementacje na urządzeniach z obsługą zegarka:

[8.4/W-0-1] MUSISZ podać profil poboru mocy dla poszczególnych komponentów, który definiuje wartość bieżącego poboru energii dla każdego komponentu sprzętowego oraz przybliżony pobór energii z baterii spowodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
[8.4/W-0-2] Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
[8.4/W-0-3] MUST report CPU power consumption per each process's UID. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
[8.4/W-0-4] DEWELOPER MUSI udostępnić ten pobór mocy 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 komponentu sprzętowego do aplikacji.

2.4.5. Model zabezpieczeń

Jeśli implementacje urządzeń Watch obejmują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, nie mogą:

[9.5/W-1-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która pozwala właścicielom urządzeń zarządzać 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 dla dodatkowych użytkowników, a także zarządzać bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

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

[9.5/W-2-1] NIE MUSI obsługiwać profili z ograniczonymi uprawnieniami, ale MUSI być zgodny z implementacją funkcji sterowania w AOSP, aby umożliwić /zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

2.5. Wymagania dotyczące pojazdów

Wdrożeniem Androida Automotive jest panel pojazdu z Androidem jako systemem operacyjnym dla części lub całości systemu lub funkcji multimedialnych.

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 samochód lub są w nim wpinane.
Używasz ekranu w rzędzie siedzeń kierowcy jako głównego wyświetlacza.

Dodatkowe wymagania w pozostałych częściach tej sekcji dotyczą implementacji na urządzeniach z Androidem Automotive.

2.5.1. Sprzęt

Implementacje na urządzeniach samochodowych:

[7.1.1.1/A-0-1] Ekran musi mieć przekątną o długości co najmniej 6 cali.
[7.1.1.1/A-0-2] Rozmiar ekranu musi wynosić co najmniej 750 dp x 480 dp.
[7.2.3/A-0-1] MUSI zawierać funkcję strony głównej oraz MOŻE zawierać funkcje Wstecz i Ostatnie.
[7.2.3/A-0-2] DO aplikacji na pierwszym planie należy wysłać zdarzenie naciśnięcia i długiego naciśnięcia przycisku Wstecz (KEYCODE_BACK).
[7.3/A-0-1] MUSISZ wdrożyć i zgłosić GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED oraz PARKING_BRAKE_ON.
[7.3/A-0-2] Wartość flagi NIGHT_MODE MUSI być zgodna z trybem dziennym/nocnym pulpitu i POWINNA być oparta na danych z czujnika światła otoczenia. Podrzędny czujnik jasności otoczenia MOŻE być taki sam jak fotometr.
[7.3/A-0-3] W przypadku każdego czujnika w polu SensorAdditionalInfo MUSISZ podać pole dodatkowych informacji o czujniku TYPE_SENSOR_PLACEMENT.
[7.3/A-0-1] MOŻE obliczać lokalizację metodą dead reckoningu, łącząc dane z GPS/GNSS z danymi z dodatkowych czujników. Jeśli lokalizacja jest określana na podstawie danych z czujników, MOCNO zalecamy implementację i raportowanie odpowiednich typów czujników lub identyfikatorów właściwości pojazdu.
[7.3/A-0-2] Lokalizacja żądana za pomocą metody LocationManager#requestLocationUpdates() NIE MOŻE być dopasowywana do mapy.

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

[7.3.1/A-1-1] Musi być możliwe zgłaszanie zdarzeń z częstotliwością co najmniej 100 Hz.
[7.3.1/A-1-2] MUSI być zgodny z systemem współrzędnych czujnika samochodowego Androida.

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

[7.3.4/A-2-1] MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
[7.3.4/A-2-2] NALEŻY również zaimplementować czujnik TYPE_GYROSCOPE_UNCALIBRATED.
[7.3.4/A-2-3] MUSI być w stanie mierzyć zmiany orientacji do 250 stopni na sekundę.
[7.3.4/A-SR] ZALECAMY, aby skonfigurować zakres pomiarowy żyroskopu na +/-250 dps, aby zmaksymalizować możliwą rozdzielczość.

Jeśli implementacje urządzeń samochodowych obejmują odbiornik GPS/GNSS, ale nie obejmują łączności z danymi przez sieć komórkową, to:

[7.3.3/A-3-1] MUSI określać lokalizację przy pierwszym włączeniu odbiornika GPS/GNSS lub po upływie 4 dni w ciągu 60 sekund.
[7.3.3/A-3-2] MUSI spełniać kryteria czasu do wprowadzenia poprawki opisane w 7.3.3/C-1-2 i 7.3.3/C-1-6 w przypadku wszystkich innych żądań lokalizacji (czyli żądań, które nie są pierwszym żądaniem lub które nie zostały wysłane po upływie 4 dni). Wymagania 7.3.3/C-1-2 są zwykle spełniane w pojazdach bez łączności z siecią komórkową na podstawie prognoz orbity GNSS obliczanej na odbiorniku lub ostatniej znanej lokalizacji pojazdu z możliwością określania pozycji metodą dead reckoning przez co najmniej 60 sekund z dokładnością spełniającą wymagania 7.3.3/C-1-3 lub kombinacji obu tych metod.

Implementacje na urządzeniach samochodowych:

[7.4.3/A-0-1] MUSI obsługiwać Bluetooth i POWINNA 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 audio (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] Zdecydowanie zaleca się obsługę profilu dostępu do wiadomości (MAP).
[7.4.5/A] NALEŻY uwzględnić obsługę transmisji danych przez sieć komórkową.
[7.4.5/A] Możesz używać interfejsu System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID w przypadku sieci, które powinny być dostępne dla aplikacji systemowych.

Kamera zewnętrzna to kamera, która rejestruje obrazy z zewnętrznej części urządzenia, np. kamera samochodowa.

Implementacje na urządzeniach samochodowych:

POWINNY zawierać co najmniej 1 kamerę zewnętrzną.

Jeśli implementacje urządzeń samochodowych obejmują kamerę widoku zewnętrznego, w przypadku takiej kamery:

[7.5/A-1-1] Nie wolno używać kamer zewnętrznych dostępnych za pomocą interfejsów API kamery Androida, chyba że spełniają podstawowe wymagania dotyczące kamer.
[7.5/A-SR] ZDECYTOWANIE POLECAMY nie obracać ani nie odwracać poziomo podglądu z kamery.
[7.5.5/A-SR] MOCNO zaleca się, aby orientacja była taka, aby dłuższy bok aparatu był wyrównany z horyzontem.
[7.5/A-SR] Zaleca się, aby rozdzielczość wynosiła co najmniej 1,3 Mpix.
NALEŻY użyć sprzętu z ostrzością stałą lub z rozszerzoną głębią ostrości (EDOF).
NALEŻY obsługiwać ramę synchronizacji Androida.
MOŻE mieć wbudowany mechanizm automatycznego ustawiania ostrości sprzętowej lub programowej w sterowniku kamery.

Implementacje na urządzeniach samochodowych:

[7.6.1/A-0-1] Musi być dostępne co najmniej 4 GB pamięci nieulotnej na potrzeby danych prywatnych aplikacji (czyli na partycji „/data”).
[7.6.1/A] NALEŻY sformatować partycję danych, aby zwiększyć wydajność i trwałość pamięci flash, na przykład za pomocą systemu plików f2fs.

Jeśli implementacje urządzeń samochodowych udostępniają zewnętrzne miejsce na dane za pomocą części wewnętrznej pamięci niewymiennej, muszą:

[7.6.1/A-SR] Zdecydowanie zalecamy zmniejszenie obciążenia operacjami wejścia/wyjścia w przypadku operacji wykonywanych na zewnętrznym urządzeniu pamięci masowej, na przykład za pomocą SDCardFS.

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

[7.6.1/A-1-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 512 MB, jeśli używana jest dowolna z tych gęstości:
- 280 dpi lub mniej na małych/normalnych ekranach
- ldpi lub niższą na ekranach bardzo dużych
- mdpi lub niższym na dużych ekranach.
[7.6.1/A-1-2] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 608 MB, jeśli używana jest dowolna z tych gęstości:
- xhdpi lub wyższa na małych/normalnych ekranach
- hdpi lub wyższa na dużych ekranach.
- mdpi lub wyższa na bardzo dużych ekranach.
[7.6.1/A-1-3] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 896 MB, jeśli używana jest dowolna z tych gęstości:
- 400 dpi lub więcej na małych/normalnych ekranach
- xhdpi lub wyższa na dużych ekranach
- tvdpi lub wyższa na bardzo dużych ekranach.
[7.6.1/A-1-4] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1344 MB, jeśli używana jest dowolna z tych gęstości:
- 560 dpi lub więcej na małych/normalnych ekranach
- 400 dpi lub więcej na dużych ekranach.
- xhdpi lub wyższa na bardzo dużych ekranach.

Jeśli implementacje urządzeń samochodowych 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, jeśli używana jest dowolna z tych gęstości:
- 280 dpi lub mniej na małych/normalnych ekranach
- ldpi lub niższą na ekranach bardzo dużych
- mdpi lub niższym 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, jeśli używana jest dowolna z tych gęstości:
- xhdpi lub wyższa na małych/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, jeśli używana jest dowolna z tych gęstości:
- 400 dpi lub więcej na małych/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, jeśli używana jest dowolna z tych gęstości:
- 560 dpi lub więcej na małych/normalnych ekranach
- 400 dpi lub więcej na dużych ekranach.
- xhdpi lub wyższa na bardzo dużych ekranach.

Uwaga: „Pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do pamięci udostępnionej dodatkowo do pamięci już przeznaczonej na komponenty sprzętowe, takie jak radio, wideo itp., które nie są kontrolowane przez jądro w implementacjach urządzenia.

Implementacje na urządzeniach samochodowych:

[7.7.1/A] NALEŻY uwzględnić port USB obsługujący tryb peryferyjny.

Implementacje na urządzeniach samochodowych:

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

Implementacje na urządzeniach samochodowych:

[7.8.2/A-0-1] Musi być dostępne wyjście audio i deklaracja android.hardware.audio.output.

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 (ulepszona jakość dźwięku AAC z minimalnym opóźnieniem)

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

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

Implementacje urządzeń samochodowych 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ń samochodowych MOCNO zaleca się obsługę tych algorytmów dekodowania wideo:

[5.3/A-SR] H.265 HEVC

2.5.3. Oprogramowanie

Implementacje na urządzeniach samochodowych:

[3/A-0-1] NALEŻY zadeklarować 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ń samochodowych udostępniają firmowe interfejsy API za pomocą interfejsu android.car.CarPropertyManager z android.car.VehiclePropertyIds, to:

[3/A-1-1] Nie wolno dołączać specjalnych uprawnień do korzystania z tych usług przez aplikację systemową ani uniemożliwiać aplikacjom innych firm korzystania z tych usług.
[3/A-1-2] NIE MOŻESZ powielać właściwości pojazdu, która istnieje już w pakiecie SDK.

Implementacje na urządzeniach samochodowych:

[3.2.1/A-0-1] MUSI obsługiwać i stosować wszystkie stałe uprawnienia zgodnie z dokumentacją na stronie referencyjnej dotyczącą uprawnień w automotive.
[3.2.3.1/A-0-1] W przypadku wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez wymienione tutaj intencje aplikacji MUSISZ wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji.
[3.4.1/A-0-1] Musisz wdrożyć interfejs API android.webkit.Webview.
[3.8.3/A-0-1] MUSI wyświetlać powiadomienia, które korzystają z interfejsu API Notification.CarExtender na żądanie aplikacji innych firm.
[3.8.4/A-SR] Stanowczo zaleca się wdrożenie asystenta na urządzeniu, aby obsłużyć działanie asystenta.

Jeśli wdrożenia urządzeń samochodowych obejmują przycisk „push-to-talk”, muszą:

[3.8.4/A-1-1] NALEŻY użyć krótkiego naciśnięcia przycisku „Naciśnij, aby mówić” jako wyznaczonej interakcji w celu uruchomienia wybranej przez użytkownika aplikacji asystenta, czyli aplikacji, która implementuje VoiceInteractionService.

Implementacje na urządzeniach samochodowych:

[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] W miejscu akcji podanych w Notification.Builder.addAction() MUSI wyświetlać opcje „ODTWÓRZ” i „WYCISZ”.
[3.8.3.1/A] NALEŻY ograniczyć korzystanie z zaawansowanych zadań związanych z zarządzaniem, takich jak ustawienia dotyczące kanałów powiadomień. MOŻE używać interfejsu użytkownika w poszczególnych aplikacjach, aby ograniczyć liczbę elementów sterujących.

Implementacje na urządzeniach samochodowych:

[3.14/A-0-1] MUSI zawierać interfejs użytkownika, który 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] Aplikacja MUSI umożliwiać użytkownikowi bezpieczne korzystanie z aplikacji multimedialnych podczas jazdy.
[3.14/A-0-3] Musi obsługiwać ukryte działanie CAR_INTENT_ACTION_MEDIA_TEMPLATE z dodatkiem CAR_EXTRA_MEDIA_PACKAGE.
[3.14/A-0-4] MUSISZ udostępnić możliwość przejścia do aktywności preferencyjnej aplikacji do multimediów, ale MUSISZ to umożliwić tylko wtedy, gdy nie obowiązują ograniczenia dotyczące UX w samochodzie.
[3.14/A-0-5] MUSI wyświetlać komunikaty o błędach ustawione przez aplikacje multimedialne i MUSI obsługiwać opcjonalne dodatki ERROR_RESOLUTION_ACTION_LABEL i ERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] W aplikacjach obsługujących wyszukiwanie MUSI być dostępna funkcja wyszukiwania w aplikacji.
[3.14/A-0-7] Podczas wyświetlania hierarchii MediaBrowser należy przestrzegać definicji CONTENT_STYLE_BROWSABLE_HINT i CONTENT_STYLE_PLAYABLE_HINT.

Jeśli implementacje urządzeń samochodowych zawierają domyślną aplikację uruchamiającą, muszą:

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

Implementacje na urządzeniach samochodowych:

[3.8/A] MOŻE ograniczyć żądania aplikacji dotyczące włączenia trybu pełnoekranowego zgodnie z opisem w immersive documentation.
[3.8/A] Możesz mieć zawsze widoczny pasek stanu i pasek nawigacyjny.
[3.8/A] MOŻE ograniczyć prośby aplikacji o zmianę kolorów elementów interfejsu systemu, aby zapewnić ich wyraźną widoczność przez cały czas.

2.5.4. Wydajność i moc

Implementacje na urządzeniach samochodowych:

[8.2/A-0-1] MUST report the number of bytes read and written to non-volatile storage per each process's UID so the stats are available to developers through System API android.car.storagemonitoring.CarStorageMonitoringManager. Projekt Android Open Source spełnia wymagania dzięki modułowi jądra uid_sys_stats.
[8.3/A-1-3] MUSI obsługiwać tryb garażu.
[8.3/A] NALEŻY ustawić tryb garażu na co najmniej 15 minut po każdej jeździe, chyba że:
- Bateria jest rozładowana.
- Nie zaplanowano żadnych zadań nieczynnych.
- Kierowca wyłącza tryb garażu.
[8.4/A-0-1] MUSISZ podać profil zużycia energii dla poszczególnych komponentów, który definiuje wartość bieżącego zużycia energii dla każdego komponentu sprzętowego oraz przybliżone zużycie energii przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
[8.4/A-0-2] Wszystkie wartości zużycia energii MUSZĄ być podawane 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 komponentu sprzętowego do aplikacji.
[8.4/A-0-4] DEWELOPER APLIKACJI MUSI udostępnić ten pobór mocy za pomocą polecenia powłoki adb shell dumpsys batterystats.

2.5.5. Model zabezpieczeń

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

[9.5/A-1-1] NIE MOŻESZ zezwolić użytkownikom na interakcję z Headless System User ani przełączanie się na niego, z wyjątkiem zarządzania urządzeniami.
[9.5/A-1-2] Przed BOOT_COMPLETED musisz przejść na konto użytkownika dodatkowego.
[9.5/A-1-3] MUSI obsługiwać możliwość utworzenia użytkownika-gościa, nawet jeśli została osiągnięta maksymalna liczba użytkowników na urządzeniu.

Implementacje na urządzeniach samochodowych:

[9.11/A-0-1] Musisz utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
[9.11/A-0-2] W ramach prawidłowego obsługiwania obsługiwanych algorytmów systemu Keystore na Androidzie w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze lub wyżej MUSISZ zaimplementować algorytmy szyfrowania RSA, AES, ECDSA i HMAC oraz funkcje haszowania z rodziny MD5, SHA-1 i SHA-2. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source Project (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
[9.11/A-0-3] NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonywania i dopiero po pomyślnym uwierzytelnieniu zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane uwierzytelniające na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w odizolowanym środowisku wykonania. Projekt Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.
[9.11/A-0-4] MUSI obsługiwać atestacjowanie klucza, w którym klucz podpisujący jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania certyfikatów MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻNA użyć innego klucza.

Implementacje na urządzeniach samochodowych:

[9.14/A-0-1] NALEŻY kontrolować wiadomości z podsystemów pojazdu w ramach Androida, np. dodając do listy dozwolonych typy i źródła wiadomości.
[9.14/A-0-2] Musi chronić przed atakami typu „odmowa usługi” z ramy Androida lub aplikacji innych firm. Zapobiega to zasypywaniu 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 dla programistów i opcji

Implementacje na urządzeniach samochodowych:

Perfetto
- [6.1/A-0-1] NALEŻY udostępnić użytkownikowi powłoki binarny plik /system/bin/perfetto, którego wiersz poleceń jest zgodny z dokumentacją perfetto.
- [6.1/A-0-2] Binarny plik perfetto MUSI przyjmować jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/A-0-3] Binarny plik perfetto MUSI zapisywać jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/A-0-4] Musisz udostępnić za pomocą binarnego pliku perfetto co najmniej źródła danych opisane w dokumentacji perfetto.

2.6. Wymagania dotyczące tabletów

Tablet z Androidem to implementacja urządzenia z Androidem, która zwykle spełnia wszystkie te kryteria:

Używany do trzymania w obu rękach.
Nie ma konfiguracji składanej ani składanej z klapką.
Implementacje klawiatury fizycznej 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ę.
Fizyczna przekątna ekranu ma rozmiar od 7 do 18 cali.

Implementacje na tabletach mają podobne wymagania jak implementacje na urządzeniach przenośnych. Wyjątki są oznaczone gwiazdką (*) w tej sekcji i wymienione w celu ułatwienia nawigacji.

2.6.1. Sprzęt

Rozmiar ekranu

[7.1.1.1/Tab-0-1] Wymiary ekranu: 7–18 cali.

Żyroskop

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

[7.3.4/Tab-1-1] MUSI umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę.

Minimalna ilość pamięci i miejsca na dane (sekcja 7.6.1)

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

Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)

Jeśli implementacje tabletów obejmują port USB obsługujący tryb peryferyjny, muszą:

[7.7.1/Tab] MOŻE implementować interfejs API AOA (Android Open Accessory).

Tryb rzeczywistości wirtualnej (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 urządzeń typu tablet obsługują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, nie mogą:

[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 ograniczonymi uprawnieniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać 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, mogą:

[9.5/T-2-1] NIE MUSI obsługiwać profili z ograniczonymi uprawnieniami, ale MUSI być zgodny z implementacją funkcji sterowania w AOSP, aby umożliwić /zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

2.6.2. Oprogramowanie

[3.2.3.1/Tab-0-1] W przypadku wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez wymienione tutaj intencje aplikacji MUSISZ wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji.

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

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

Implementacje na urządzeniu:

[C-0-1] Musisz zapewnić pełne implementacje, w tym wszystkie udokumentowane zachowania, dowolnego udokumentowanego interfejsu API udostępnionego przez pakiet SDK Androida lub dowolnego interfejsu API o oznaczonym w kodziku źródłowym Androida znacznikiem „@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 podpisów interfejsów API, odbiegać od udokumentowanego zachowania lub dołączać operacji pustych, z wyjątkiem przypadków, w których jest to wyraźnie dozwolone w tej definicji zgodności.
[C-0-4] Musisz zachować interfejsy API i działać w rozsądny sposób, nawet jeśli pominiesz niektóre funkcje sprzętowe, dla których Android zawiera interfejsy API. Szczegółowe wymagania dotyczące tego scenariusza znajdziesz w sekcji 7.
[C-0-5] NIE MOŻESZ zezwolić aplikacjom innych firm na używanie interfejsów spoza pakietu SDK, które są zdefiniowane jako metody i pola w pakietach języka Java, znajdujące się w ścieżce klas Boot Loadera w AOSP i niebędące częścią publicznego pakietu SDK. Dotyczy to interfejsów API otagowanych adnotacją @hide, ale nie @SystemAPI, zgodnie z opisem w dokumentacji pakietu SDK oraz elementów klas prywatnych i elementów klas prywatnych w ramach pakietu.
[C-0-6] MUST ship with each and every non-SDK interface on the same restricted lists as provided via the provisional and denylist flags in prebuilts/runtime/appcompat/hiddenapi-flags.csv path for the appropriate branch of API level in the AOSP.
[C-0-7] MUSI obsługiwać mechanizm aktualizacji dynamicznej zaszyfrowanej konfiguracji, aby usuwać interfejsy inne niż SDK z listy ograniczeń przez umieszczenie zaszyfrowanej konfiguracji w dowolnym pliku APK za pomocą istniejących kluczy publicznych obecnych w AOSP.

Jednak:
- MAY, jeśli ukryte API jest nieobecne lub zaimplementowane inaczej na urządzeniu, przenieś ukryte API na listę zablokowanych lub pomiń je na wszystkich listach ograniczonych (tj. jasnoszare, ciemnoszare, czarne).
- W MAJA, jeśli ukryty interfejs API nie istnieje już w AOSP, dodaj go do dowolnej z list ograniczonych (tj. jasnoszarej, ciemnoszarej lub czarnej).

3.1.1. Rozszerzenia Androida

Android umożliwia rozszerzenie interfejsu zarządzanego interfejsu API danego poziomu przez zaktualizowanie wersji rozszerzenia dla tego poziomu. Jeśli istnieją rozszerzenia dla danego poziomu interfejsu API, interfejs API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) zwraca wersję rozszerzenia podanego interfejsu apiLevel.

Implementacje na urządzeniach z Androidem:

[C-0-1] NALEŻY wstępnie załadować implementację AOSP zarówno współdzielonej biblioteki ExtShared, jak i usług ExtServices, w wersjach nowszych lub równych minimalnym wersjom dozwolonym dla danego poziomu interfejsu API. Na przykład implementacje na urządzeniach z Androidem 7.0 i poziomem interfejsu API 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 rozszerzenia zwracane przez android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) w taki sam sposób, w jaki obsługiwane są inne zarządzane interfejsy API, zgodnie z wymaganiami podanymi w sekcji 3.1.

3.1.2. Biblioteka Androida

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

[C-0-1] NIE WYMAGA umieszczania biblioteki org.apache.http.legacy w ścieżce ładowania.
[C-0-2] NALEŻY dodać bibliotekę org.apache.http.legacy do ścieżki klas aplikacji tylko wtedy, gdy aplikacja spełnia jedną z tych przesłanek:
- Kieruje na interfejs API na poziomie 28 lub niższym.
- w swoim pliku manifestu deklaruje, że potrzebuje biblioteki, ustawiając atrybut android:name w elementach <uses-library> na org.apache.http.legacy;

Implementacja AOSP spełnia te wymagania.

3.2. Zgodność z interfejsem API w wersji próbnej

Oprócz interfejsów API zarządzanych z sekcji 3.1 Android zawiera też „miękkie” interfejsy API, które są używane tylko w czasie działania. Są to na przykład intencje, uprawnienia i inne aspekty aplikacji na Androida, których nie można wymusić w czasie kompilacji aplikacji.

3.2.1. Uprawnienia

[C-0-1] Implementatorzy urządzeń MUSZĄ obsługiwać i stosować wszystkie stałe uprawnienia zgodnie z dokumentacją na stronie referencyjnej dotyczącej uprawnień. Pamiętaj, że w sekcji 9 znajdziesz dodatkowe wymagania dotyczące modelu zabezpieczeń Androida.

3.2.2. Parametry budowy

Interfejsy API Androida zawierają wiele stałych wartości w klasie android.os.Build, które służą do opisywania bieżącego urządzenia.

[C-0-1] Aby zapewnić spójne, sensowne wartości we wszystkich implementacjach urządzeń, w tabeli poniżej podano dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi implementacje urządzeń MUSZĄ być zgodne.

Parametr	Szczegóły
VERSION.RELEASE	Wersja aktualnie uruchomionego systemu Android w czytelnym dla człowieka formacie. To pole MUSI zawierać jeden z ciągów znaków zdefiniowanych w sekcji 11.
WERSJ.SDK	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 11 to pole MUSI zawierać wartość liczbową 11_INT.
VERSION.SDK_INT	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 11 to pole MUSI zawierać wartość liczbową 11_INT.
VERSION.INCREMENTAL	Wartość wybrana przez implementatora urządzenia, która w czytelnym dla człowieka formacie wskazuje konkretną wersję aktualnie uruchomionego systemu Android. Tej wartości NIE MOŻNA używać ponownie w przypadku różnych wersji udostępnionych użytkownikom. Typowym zastosowaniem tego pola jest wskazanie, który numer wersji lub identyfikator zmiany kontroli źródłowej posłużył do wygenerowania wersji. Wartość tego pola MUSI być możliwa do zakodowania jako drukowalny 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^[^ :\/~]+$”.
PLANSZOWE	Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretny sprzęt wewnętrzny używany przez urządzenie w czytelnym dla człowieka formacie. Możliwe zastosowanie tego pola to wskazanie konkretnej wersji płyty głównej zasilającej urządzenie. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
MARKA	Wartość odzwierciedlająca nazwę marki powiązaną z urządzeniem, jaką znają użytkownicy. MUSI być w formacie zrozumiałym dla człowieka i POWINIEN wskazywać producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_32_BIT_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywną wersją interfejsu API.
SUPPORTED_64_BIT_ABIS	Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywną wersją interfejsu API.
CPU_ABI	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI2	Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywną wersją interfejsu API.
URZĄDZENIE	Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową identyfikującą konfigurację funkcji sprzętowych i przemysłowy projekt urządzenia. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Nazwa urządzenia NIE MOŻE się zmieniać w trakcie trwania produktu.
FINGERPRINT	Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być zrozumiały dla człowieka. Musi on być zgodny z tym szablonem: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Przykład: acme/myproduct/ mydevice:11/LMYXX/3359:userdebug/test-keys Odcisk palca NIE MOŻE zawierać znaków odstępów. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII.
SPRZĘT	Nazwa sprzętu (z wiersza poleceń jądra lub katalogu /proc). Powinien być zrozumiały dla człowieka. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
HOST	Ciąg tekstowy jednoznacznie identyfikujący hosta, na którym została utworzona kompilacja, w zrozumiałym dla człowieka formacie. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („"").
ID	Identyfikator wybrany przez implementatora urządzenia, który odnosi się do konkretnej wersji w czytelnym dla człowieka formacie. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINIEN zawierać wartość na tyle znaczącą, aby użytkownicy mogli odróżnić różne wersje oprogramowania. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
PRODUCENT	Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE może być ono puste ani nie może zawierać pustego ciągu znaków (""). W trakcie trwania produktu pole to NIE może się zmieniać.
MODEL	Wartość wybrana przez implementatora urządzenia zawierająca nazwę urządzenia znaną użytkownikowi. Powinna to być ta sama nazwa, pod którą urządzenie jest sprzedawane i reklamowane użytkownikom końcowym. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE może być ono puste ani nie może zawierać pustego ciągu znaków („”). W trakcie trwania produktu pole to NIE może się zmieniać.
USŁUGA	Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową konkretnego produktu (SKU), która MUSI być unikalna w ramach tej samej marki. Musi być czytelny dla człowieka, ale niekoniecznie musi być widoczny dla użytkowników. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Nazwa produktu NIE MOŻE się zmieniać w trakcie jego cyklu życia.
SERIAL	Musi zwracać wartość „UNKNOWN” (nieznany).
TAGI	Lista tagów wybranych przez implementatora urządzenia, oddzielona przecinkami, która dodatkowo rozróżnia kompilację. Tagi MUSZĄ być kodowalne jako 7-bitowe kody ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-]+”. MUSZĄ też mieć jedną z wartości odpowiadających 3 typowym konfiguracjom podpisywania na platformie Android: release-keys, dev-keys i test-keys.
CZAS	Wartość reprezentująca sygnaturę czasową utworzenia kompilacji.
TYP	Wartość wybrana przez implementatora urządzenia, która określa konfigurację kompilacji w czasie wykonywania. To pole MUSI zawierać jedną z wartości odpowiadających 3 typowym konfiguracjom środowiska uruchomieniowego Androida: user, userdebug lub eng.
UŻYTKOWNIK	Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował wersję. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani zawierać pustego ciągu znaków („"").
VERSION.SECURITY_PATCH	Wartość wskazująca poziom aktualizacji zabezpieczeń danej kompilacji. Musi on oznaczać, że kompilacja nie jest w żaden sposób narażona na żadne z problemów opisanych w wybranym Biuletynie bezpieczeństwa Androida. Musi on mieć format [RRRR-MM-DD] i być zgodny z definiowanym ciągiem znaków udokumentowanym w publicznym biuletynie bezpieczeństwa Androida lub w powiadomieniu o zabezpieczeniach Androida, np. „2015-11-01”.
VERSION.BASE_OS	Wartość reprezentująca parametr FINGERPRINT kompilacji, która jest identyczna z tą kompilacją, z wyjątkiem poprawek podanych w publikacji Android Public Security Bulletin. Musi on zwracać prawidłową wartość. Jeśli taka wersja nie istnieje, musi zwracać pusty ciąg znaków („”).
BOOTLOADER	Wartość wybrana przez implementatora urządzenia, która w czytelnym dla człowieka formacie identyfikuje konkretną wersję wewnętrznego programu rozruchowego używanego na urządzeniu. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
getRadioVersion()	MUSI (być lub zwracać) wartość wybraną przez implementatora urządzenia, która identyfikuje specyficzną wewnętrzną wersję radia/modemu używaną na urządzeniu w czytelnym dla człowieka formacie. Jeśli urządzenie nie ma żadnego wewnętrznego radia/modemu, musi zwrócić wartość NULL. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-,]+$”.
getSerial()	Musisz podać numer seryjny sprzętu, który musi być dostępny i niepowtarzalny w przypadku urządzeń z tym samym MODELEM i PRODUCENTEM. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-,]+$”.

3.2.3. Zgodność z zamiarem

3.2.3.1. Typowe przypadki użycia aplikacji

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

Implementacje na urządzeniu:

[C-SR] ZALECAMY WYMAGANIE wstępnego wczytania co najmniej 1 aplikacji lub komponentu usługi z obsługą intencji w przypadku wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez te intencje aplikacji wymienione tutaj i zapewnić realizację, czyli spełnić oczekiwania dewelopera dotyczące tych typowych intencji aplikacji zgodnie z opisem w pakiecie SDK.

Informacje o obowiązkowych intencjach aplikacji dla poszczególnych typów urządzeń znajdziesz w sekcji 2.

3.2.3.2. Rozwiązywanie intencji

[C-0-1] Ponieważ Android jest platformą rozszerzalną, implementacje urządzeń MUSZĄ zezwalać na zastąpienie przez aplikacje innych firm każdego wzorca intencji wymienionego w sekcji 3.2.3.1, z wyjątkiem ustawień. Implementacja open source w górnym łańcuchu Androida umożliwia to domyślnie.
[C-0-2] Implementatorzy urządzeń NIE MOGĄ dołączać specjalnych uprawnień do korzystania z tych wzorów intencji przez aplikacje systemowe ani uniemożliwiać aplikacjom innych firm wiązania się z tymi wzorami i przejmowania nad nimi kontroli. Zakaz ten obejmuje m.in. wyłączenie interfejsu „Wybór”, który umożliwia użytkownikowi wybór spośród wielu aplikacji obsługujących ten sam wzór intencji.
[C-0-3] Implementacje na urządzeniach MUSZĄ zawierać interfejs użytkownika umożliwiający modyfikowanie domyślnego działania dla intencji.
Implementacje na urządzeniach MOGĄ jednak udostępniać domyślne działania w przypadku określonych wzorów URI (np. http://play.google.com), gdy domyślne działanie udostępnia bardziej szczegółowy atrybut dla URI danych. Na przykład wzór filtra intencji określający identyfikator URI danych „http://www.android.com” jest bardziej szczegółowy niż podstawowy wzór intencji przeglądarki „http://”.

Android zawiera też mechanizm, który umożliwia aplikacjom innych firm deklarowanie wiarygodnego domyślnego zachowania w przypadku łączenia aplikacji w przypadku niektórych typów intencji identyfikatora URI internetowego. Gdy w wzorach filtrów intencji aplikacji zdefiniowane są takie autorytatywne deklaracje, implementacje na urządzeniach:

[C-0-4] NALEŻY spróbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji Digital Asset Links, jak to robi menedżer pakietów w górnym projekcie Android Open Source.
[C-0-5] NALEŻY spróbować zweryfikować filtry intencji podczas instalacji aplikacji i ustawić wszystkie zweryfikowane filtry intencji identyfikatora URI jako domyślne moduły obsługi aplikacji dla ich identyfikatorów URI.
MOGĄ ustawić określone filtry intencji URI jako domyślne moduły obsługi aplikacji dla swoich identyfikatorów URI, jeśli zostaną one pomyślnie zweryfikowane, ale inne potencjalne filtry URI nie przejdą weryfikacji. Jeśli implementacja urządzenia wykonuje tę funkcję, MUSI udostępnić użytkownikowi odpowiednie zastąpienia wzorców dla poszczególnych adresów URI w menu ustawień.
MUSI udostępniać użytkownikom ustawienia dotyczące linków do aplikacji w ustawieniach aplikacji w ten sposób:
- [C-0-6] Użytkownik MUSI mieć możliwość globalnego zastąpienia domyślnego zachowania linków aplikacji, aby było ono takie: zawsze otwierać, zawsze pytać lub nigdy nie otwierać, co musi dotyczyć wszystkich docelowych filtrów identyfikatorów URI.
- [C-0-7] Użytkownik MUSI mieć możliwość wyświetlenia listy docelowych filtrów intencji URI.
- Implementacja urządzenia MOŻE umożliwić użytkownikowi zastąpienie konkretnych docelowych filtrów intencji URI, które zostały zweryfikowane, na podstawie każdego filtra intencji.
- [C-0-8] Implementacja na urządzeniu MUSI umożliwiać użytkownikom wyświetlanie i zastępowanie konkretnych docelowych filtrów identyfikatora URI, jeśli implementacja na urządzeniu pozwala na przeprowadzenie weryfikacji niektórych docelowych filtrów identyfikatora URI, podczas gdy inne mogą nie przejść weryfikacji.

3.2.3.3. Przestrzenie nazw intencji

[C-0-1] Implementacje urządzeń NIE MOGĄ zawierać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub rozgłaszania intencji za pomocą działania, kategorii lub innego kluczowego ciągu znaków w przestrzeni nazw android. lub com.android..
[C-0-2] Implementatorzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub rozgłaszania intencji za pomocą działania, kategorii lub innego ciągu kluczy w przestrzeni pakietu należącej do innej organizacji.
[C-0-3] Implementatorzy urządzeń NIE MOGĄ zmieniać ani rozszerzać żadnych wzorów intencji wymienionych w sekcji 3.2.3.1.
Implementacje na urządzeniach MOGĄ zawierać wzorce intencji, które używają przestrzeni nazw wyraźnie i wyraźnie powiązanych z własną organizacją. Ten zakaz jest analogiczny do zakazu dotyczącego zajęć z języka Java w sekcji 3.6.

3.2.3.4. Zamiary związane z transmisją

Aplikacje innych firm polegają na platformie, która wysyła określone intencje, aby powiadamiać je o zmianach w środowisku sprzętowym lub programowym.

Implementacje na urządzeniu:

[C-0-1] MUSI wysyłać publiczne intencje transmisji wymienione tutaj w odpowiedzi na odpowiednie zdarzenia systemowe zgodnie z dokumentacją 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. Ponadto niektóre intencje transmisji są zależne od obsługi sprzętu. Jeśli urządzenie obsługuje niezbędny sprzęt, intencje te MUSZĄ być transmitowane i działać zgodnie z dokumentacją pakietu SDK.

3.2.3.5. Warunkowe intencje aplikacji

Android zawiera ustawienia, które umożliwiają użytkownikom łatwe wybieranie domyślnych aplikacji, na przykład na ekranie głównym lub do wysyłania SMS-ów.

W przypadku urządzeń, w których ma to sens, implementacje MUSZĄ udostępniać podobne menu ustawień i być zgodne z wzorcem filtra intencji oraz metodami interfejsu API opisanymi w dokumentacji pakietu SDK, jak pokazano poniżej.

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

[C-1-1] MUSI obsługiwać działanie android.settings.HOME_SETTINGS, aby wyświetlić menu ustawień domyślnej aplikacji na ekranie głównym.

Jeśli wdrożenia urządzeń zgłaszają android.hardware.telephony, to:

[C-2-1] Musisz udostępnić menu ustawień, które wywoła działanie android.provider.Telephony.ACTION_CHANGE_DEFAULT, aby wyświetlić okno dialogowe umożliwiające zmianę domyślnej aplikacji do obsługi SMS-ów.
[C-2-2] MUSI honorować intencję android.telecom.action.CHANGE_DEFAULT_DIALER, aby wyświetlić okno dialogowe umożliwiające użytkownikowi zmianę domyślnej aplikacji Telefon.
- W przypadku połączeń przychodzących i wychodzących należy UŻYWAĆ interfejsu domyślnej aplikacji Telefon wybranej przez użytkownika, z wyjątkiem połączeń alarmowych, które będą korzystać z zainstalowanej fabrycznie aplikacji Telefon.
[C-2-3] MUSI obsługiwać działanie android.telecom.action.CHANGE_PHONE_ACCOUNTS, aby umożliwić użytkownikowi skonfigurowanie ConnectionServices powiązanego z PhoneAccounts, a także domyślnego konta PhoneAccount, którego dostawca usług telekomunikacyjnych będzie używać do wykonywania połączeń wychodzących. Implementacja AOSP spełnia ten wymóg, ponieważ zawiera menu „Opcja kont połączeń” w menu ustawień „Połączenia”.
[C-2-4] Musisz zezwolić na android.telecom.CallRedirectionService w przypadku aplikacji, która ma rolę android.app.role.CALL_REDIRECTION.
[C-2-5] NALEŻY umożliwić użytkownikowi wybranie aplikacji, która ma rolę android.app.role.CALL_REDIRECTION.
[C-2-6] Aplikacja 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] Zalecamy 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 Dialer, która może obsługiwać te intencje i zapewniać realizację zgodnie z opisem w pakiecie SDK.

Jeśli wdrożenia urządzeń zgłaszają android.hardware.nfc.hce, to:

[C-3-1] Musi obsługiwać działanie intencji android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlić menu ustawień domyślnej aplikacji do płatności zbliżeniowych.
[C-3-2] Musisz obsługiwać działanie android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT, aby wyświetlić aktywność, która otwiera okno dialogowe z prośbą o zmianę domyślnej usługi emulacji karty w przypadku określonej kategorii, zgodnie z opisem w pakiecie SDK.

Jeśli wdrożenia urządzeń zgłaszają android.hardware.nfc, to:

[C-4-1] Musisz obsługiwać te intencje: android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED i android.nfc.action.TECH_DISCOVERED, aby wyświetlić działanie, które spełnia oczekiwania dewelopera dotyczące tych intencji, jak opisano w SDK.

Jeśli implementacje na urządzeniu obsługują interfejs VoiceInteractionService i na urządzeniu jest zainstalowanych jednocześnie kilka aplikacji korzystających z tego interfejsu API, to:

[C-4-1] MUSI obsługiwać działanie android.settings.ACTION_VOICE_INPUT_SETTINGS polegające na wyświetlaniu menu ustawień domyślnej aplikacji do wprowadzania i obsługi głosowej.

Jeśli wdrożenia urządzeń zgłaszają android.hardware.bluetooth, to:

[C-5-1] MUSI obsługiwać działanie ‘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ć działanie ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ i wyświetlać aktywność systemową, która prosi o włączenie trybu wykrywalności.

Jeśli implementacje urządzeń obsługują funkcję DND, to:

[C-6-1] NALEŻY zaimplementować aktywność, która odpowiada na intencję ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. W przypadku implementacji z UI_MODE_TYPE_NORMAL musi to być aktywność, w której użytkownik może zezwolić lub odmówić aplikacji dostępu do konfiguracji zasad Nie przeszkadzać.

Jeśli implementacje urządzeń umożliwiają użytkownikom korzystanie z metod wprowadzania danych innych firm, użytkownicy mogą:

[C-7-1] Musisz udostępnić użytkownikowi mechanizm umożliwiający dodawanie i konfigurowanie metod wprowadzania danych pochodzących od 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, muszą:

[C-8-1] MUSI uwzględniać intencję android.settings.ACCESSIBILITY_SETTINGS polegającą na udostępnieniu użytkownikowi mechanizmu umożliwiającego włączenie i wyłączenie usług ułatwień dostępu innych firm obok wstępnie załadowanych usług ułatwień dostępu.

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

[C-9-1] NALEŻY zaimplementować interfejsy API poleceń Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI zgodnie z opisem w dokumentacji pakietu SDK.

Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych, muszą: * [C-10-1] MUSZĄ zawierać w ustawieniach interfejs użytkownika, który obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, umożliwiając użytkownikom dodawanie aplikacji do listy dozwolonych lub usuwanie ich z niej.

Jeśli implementacja na urządzeniu nie zapewnia trybu oszczędzania danych, nie spełnia ona tych wymagań:

[C-11-1] Musisz mieć aktywność, która obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻESZ ją zaimplementować jako no-op.

Jeśli implementacje urządzeń deklarują obsługę kamery za pomocą android.hardware.camera.any, to:

[C-12-1] MUSI obsługiwać działanie 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.
[C-12-2] MUSI obsługiwać działanie android.media.action.VIDEO_CAMERA polegające na uruchamianiu aparatu w trybie wideo zgodnie z opisem w pakiecie SDK.
[C-12-3] NALEŻY zezwolić tylko wstępnie zainstalowanym aplikacjom na Androida na obsługę poniższych intencji MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE i MediaStore.ACTION_VIDEO_CAPTURE zgodnie z opisem w dokumentacji pakietu SDK.

Jeśli wdrożenia urządzeń zgłaszają android.software.device_admin, to:

[C-13-1] MUSI uwzględniać intencję android.app.action.ADD_DEVICE_ADMIN polegającą na wywołaniu interfejsu użytkownika w celu dodania administratora urządzenia do systemu (lub umożliwienia użytkownikowi odrzucenia tej opcji).
[C-13-2] Musi obsługiwać intencje android.app.action.ADMIN_POLICY_COMPLIANCE, android.app.action.GET_PROVISIONING_MODE, android.app.action.PROVISIONING_SUCCESSFUL, android.app.action.PROVISION_MANAGED_DEVICE, android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION oraz mieć aktywność, która zapewnia realizację tych intencji zgodnie z opisem w SDK tutaj.

Jeśli implementacje urządzeń deklarują flagę funkcji android.software.autofill, muszą:

[C-14-1] Musisz w pełni zaimplementować interfejsy API AutofillService i AutofillManager oraz obsługiwać działanie intencji android.settings.REQUEST_SET_AUTOFILL_SERVICE, aby wyświetlać domyślne menu ustawień aplikacji umożliwiające włączenie i wyłączenie autouzupełniania oraz zmianę domyślnej usługi autouzupełniania dla użytkownika.

Jeśli implementacje urządzeń obejmują fabrycznie zainstalowaną aplikację lub jeśli chcesz zezwolić aplikacjom innych firm na dostęp do statystyk użytkowania, musisz:

[C-SR] W przypadku aplikacji, które deklarują uprawnienie android.permission.PACKAGE_USAGE_STATS, ZALECAMY udostępnienie użytkownikowi mechanizmu przyznawania lub odmowy przyznania dostępu do statystyk użytkowania w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Jeśli implementacje na urządzeniach mają uniemożliwiać dostęp do statystyk użytkowania wszystkim aplikacjom, w tym wstępnie zainstalowanym, muszą:

[C-15-1] Musisz nadal mieć aktywność, która obsługuje wzór intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale musisz zaimplementować ją jako no-op, czyli tak, aby miała działanie podobne do tego, gdy użytkownikowi odmówiono dostępu.

Jeśli implementacje na urządzeniach zgłaszają funkcję android.hardware.audio.output, to:

[C-SR] Stanowczo zalecamy, aby w ramach intencji android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA i android.speech.tts.engine.GET_SAMPLE_TEXT była dostępna aktywność, która zapewnia realizację tych intencji zgodnie z opisem w SDK tutaj.

Android obsługuje interaktywne wygaszacze ekranu, które wcześniej nazywano „marzeniami”. Wygaszacze ekranu umożliwiają użytkownikom interakcję z aplikacjami, gdy urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji dokującej. Implementacje na urządzeniu:

POWINIEN zawierać obsługę wygaszaczy i opcję ustawień, która umożliwia użytkownikom skonfigurowanie wygaszaczy w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

3.2.4. Aktywności na dodatkowym ekranie lub na wielu ekranach

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych czynności Androida na więcej niż 1 ekranie, muszą:

[C-1-1] NALEŻY ustawić flagę funkcji android.software.activities_on_secondary_displays.
[C-1-2] NALEŻY zagwarantować zgodność interfejsu API z działaniem na ekranie głównym.
[C-1-3] Nowa aktywność MUSI być wyświetlana na tym samym ekranie co aktywność, która ją uruchomiła, gdy nowa aktywność jest uruchamiana bez określenia wyświetlacza docelowego za pomocą interfejsu API ActivityOptions.setLaunchDisplayId().
[C-1-4] Należy usunąć wszystkie aktywności, gdy usunie się wyświetlacz z flagą Display.FLAG_PRIVATE.
[C-1-5] NALEŻY bezpiecznie ukryć zawartość na wszystkich ekranach, gdy urządzenie jest zablokowane za pomocą bezpiecznej blokady ekranu, chyba że aplikacja zdecyduje się wyświetlać na górze ekranu blokady za pomocą interfejsu API Activity#setShowWhenLocked().
android.content.res.Configuration powinien być zgodny z tym wyświetlaczem, aby można było go wyświetlić, aby działał prawidłowo i zachował zgodność, jeśli aktywność zostanie uruchomiona na wyświetlaczu dodatkowym.

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych czynnoś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 działalności, które są już na wyświetlaczu, MUSI mieć możliwość uruchomienia wyświetlacza. Każdy może uruchomić wyświetlacz z flagą android.view.Display.FLAG_PUBLIC.

3.3. Zgodność z natywnym interfejsem API

Zgodność kodu natywnego jest trudna do osiągnięcia. Dlatego implementatorzy urządzeń:

[SR] MOCNO ZALECAMY korzystanie z implementacji bibliotek wymienionych poniżej z wyższego projektu Android Open Source.

3.3.1. Interfejsy binarne aplikacji

Zarządzany kod bajtowy Dalvik może wywoływać kod natywny dostarczony w pliku aplikacji .apk jako plik ELF .so skompilowany pod kątem odpowiedniej architektury sprzętowej urządzenia. Ponieważ kod natywny jest w dużej mierze zależny od podstawowej technologii procesora, Android definiuje w NDK Androida kilka interfejsów binarnych aplikacji (ABI).

Implementacje na urządzeniu:

[C-0-1] MUSI być zgodny z co najmniej jednym zdefiniowanym Android NDK ABI.
[C-0-2] MUSI zawierać obsługę kodu działającego w środowisku zarządzanym, aby wywoływać kod natywny za pomocą standardowej semantyki interfejsu JNI (Java Native Interface).
[C-0-3] Musi być zgodny z źródłem (czyli z nagłówkiem) i binarną wersją (w przypadku interfejsu ABI) każdej wymaganej biblioteki na liście poniżej.
[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 lista rozdzielona przecinkami, zawierająca interfejsy ABI uporządkowane od najbardziej do najmniej preferowanego.
[C-0-6] NALEŻY podać za pomocą powyższych parametrów podzbiór z listy ABI, która znajduje się poniżej. NIE NALEŻY podać żadnego ABI, który nie znajduje się na liście.
- armeabi (NDK nie obsługuje już tego typu docelów)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
[C-0-7] Musisz udostępnić aplikacjom zawierającym kod natywny wszystkie te biblioteki, które udostępniają natywne interfejsy API:
- libaaudio.so (obsługa dźwięku AAudio)
- libamidi.so (wbudowane wsparcie MIDI, jeśli funkcja android.software.midi jest obsługiwana zgodnie z opisem w sekcji 5.9)
- libandroid.so (obsługa natywnej aktywności Androida)
- libc (biblioteka C)
- libcamera2ndk.so
- libdl (linker dynamiczny)
- libEGL.so (natywna obsługa 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 (rejestrowanie na Androidzie)
- libmediandk.so (obsługa natywnych interfejsów API multimediów)
- libm (biblioteka matematyczna)
- libneuralnetworks.so (interfejs 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ć publicznych funkcji w bibliotekach natywnych wymienionych powyżej.
[C-0-9] W /vendor/etc/public.libraries.txt MUSISZ podać listę dodatkowych bibliotek innych niż AOSP udostępnionych bezpośrednio aplikacjom innych firm.
[C-0-10] NIE wolno udostępniać aplikacji innych firm kierowanych na poziom interfejsu API 24 lub nowszy żadnych innych bibliotek natywnych, które są implementowane i udostępniane w AOSP jako biblioteki systemowe, ponieważ są zarezerwowane.
[C-0-11] NALEŻY wyeksportować wszystkie symbole funkcji OpenGL ES 3.1 i pakietu rozszerzeń Androida zdefiniowane w NDK za pomocą biblioteki libGLESv3.so. Pamiętaj, że chociaż wszystkie symbole MUSZĄ być obecne, w sekcji 7.1.4.1 podano bardziej szczegółowe wymagania dotyczące pełnej implementacji poszczególnych funkcji.
[C-0-12] NALEŻY wyeksportować symbole funkcji dla podstawowych symboli funkcji Vulkan 1.0, 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 chociaż wszystkie symbole MUSZĄ być obecne, w sekcji 7.1.4.2 podano bardziej szczegółowe wymagania dotyczące pełnej implementacji poszczególnych funkcji.
NALEŻY go skompilować, używając kodu źródłowego i plików nagłówków dostępnych w upstreamowym projekcie Android Open Source.

Pamiętaj, że w przyszłych wersjach Androida możemy dodać obsługę dodatkowych ABI.

3.3.2. Zgodność z 32-bitowym kodem natywnym ARM

Jeśli implementacje na urządzeniu zgłaszają obsługę ABI armeabi, to:

[C-3-1] Musisz też obsługiwać armeabi-v7a i zgłaszać tę obsługę, ponieważ armeabi jest przeznaczone tylko do zapewnienia zgodności wstecznej ze starszymi aplikacjami.

Jeśli implementacje urządzeń zgłaszają obsługę ABI armeabi-v7a, aplikacje korzystające z tego ABI:

[C-2-1] W pliku /proc/cpuinfo MUSISZ uwzględnić podane niżej wiersze i NIE wolno Ci zmieniać wartości na tym samym urządzeniu, nawet jeśli są one odczytywane przez inne ABI.
- Features:, a następnie listę opcjonalnych funkcji procesora ARMv7 obsługiwanych przez urządzenie.
- CPU architecture:, a następnie liczba całkowita określająca najwyższą obsługiwaną architekturę ARM urządzenia (np. „8” w przypadku urządzeń ARMv8).
[C-2-2] NALEŻY zawsze mieć dostępne te operacje, nawet jeśli ABI jest implementowany w architekturze ARMv8, czy to za pomocą natywnego wsparcia procesora, czy emulacji oprogramowania:
- Instrukcje dotyczące SWP i SWPB.
- Instrukcja SETEND.
- CP15ISB, CP15DSB i CP15DMB.
[C-2-3] Musi obsługiwać rozszerzenie Advanced SIMD (znane też jako NEON).

3.4. Zgodność z przeglądarką

3.4.1. Zgodność WebView

Jeśli implementacje na urządzeniu zapewniają pełną implementację interfejsu API android.webkit.Webview, to:

[C-1-1] MUST report android.software.webview.
[C-1-2] Do implementacji interfejsu API android.webkit.WebView należy użyć kompilacji projektu Chromium z upstreamowego projektu Android Open Source na gałęzi Androida 11.
[C-1-3] Ciąg tekstowy klienta użytkownika przesyłany przez WebView MUSI mieć 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 $(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 być pominięty, ale jeśli jest obecny, ciąg znaków $(BUILD) MUSI być taki sam jak wartość android.os.Build.ID.
- Wartość ciągu $(CHROMIUM_VER) MUSI być wersją Chromium w poprzednim projekcie open source Android.
- Implementacje urządzeń MOGĄ pomijać w ciągu danych klienta użytkownika ciąg znaków „Mobile”.
Komponent WebView powinien obsługiwać jak najwięcej funkcji HTML5. Jeśli obsługuje daną funkcję, powinien być zgodny ze specyfikacją HTML5.
[C-1-3] NALEŻY renderować dostarczone treści lub treści z odległego adresu URL w procesie, który jest odrębny od aplikacji, która instancjuje WebView. Proces oddzielnego renderera MUSI mieć mniejsze uprawnienia, działać jako oddzielny identyfikator użytkownika, nie mieć dostępu do katalogu danych aplikacji, nie mieć bezpośredniego dostępu do sieci i mieć dostęp tylko do minimalnych wymaganych usług systemowych za pomocą Bindera. Implementacja WebView w AOSP spełnia ten wymóg.

Pamiętaj, że jeśli implementacje urządzeń są 32-bitowe lub deklarują flagę funkcji android.hardware.ram.low, są one wyłączone z wymagań 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ć wszystkie te interfejsy API związane z HTML5:
[C-1-2] MUSI obsługiwać interfejs webstorage API w HTML5/W3C oraz IndexedDB API w HTML5/W3C. Pamiętaj, że organy standaryzacyjne zajmujące się tworzeniem stron internetowych przechodzą na IndexedDB zamiast Web Storage, dlatego IndexedDB ma stać się wymaganym komponentem w przyszłej wersji Androida.
W samodzielnej aplikacji przeglądarki MOŻNA przesyłać niestandardowy ciąg znaków klienta użytkownika.
NALEŻY wdrożyć obsługę jak największej części HTML5 w samodzielnej aplikacji przeglądarki (opracowanej na podstawie przeglądarki WebKit lub zastępczej przeglądarki innej firmy).

Jeśli jednak implementacje na urządzeniach nie obejmują samodzielnej aplikacji przeglądarki, nie mogą:

[C-2-1] MUSI nadal obsługiwać wzorce intencji publicznych opisane w sekcji 3.2.3.1.

3.5. Zgodność zachowania interfejsu API

Implementacje na urządzeniu:

[C-0-9] NALEŻY zadbać o to, aby zgodność z zachowaniem interfejsu API była stosowana we wszystkich zainstalowanych aplikacjach, chyba że są one ograniczone zgodnie z opisem w sekcji 3.5.1.
[C-0-10] NIE WDRAŻAJ metody stosowania listy dozwolonych, która zapewnia zgodność zachowania interfejsu API tylko w przypadku aplikacji wybranych przez implementatorów urządzenia.

Zachowanie każdego z typów interfejsu API (zarządzanego, miękkiego, natywnego i internetowego) musi być zgodne z preferowaną implementacją Android Open Source Project. Niektóre konkretne obszary zgodności to:

[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 standardowych uprawnień.
Urządzenia NIE MOGĄ zmieniać ograniczeń narzucanych na aplikacje działające w tle. W szczególności w przypadku aplikacji działających w tle:
- [C-0-4] NALEŻY zatrzymać wykonywanie wywołań zwrotnych zarejestrowanych przez aplikację w celu otrzymywania danych wyjściowych z GnssMeasurement i GnssNavigationMessage.
- [C-0-5] NALEŻY ograniczyć częstotliwość aktualizacji przekazywanych aplikacji za pomocą klasy interfejsu API LocationManager lub metody WifiManager.startScan().
- [C-0-6] Jeśli aplikacja jest kierowana na poziom interfejsu API 25 lub wyższy, NIE MOŻE ona zezwalać na rejestrowanie odbiorników transmisji w przypadku niejawnych transmisji standardowych intencji Androida w pliku manifestu aplikacji, chyba że intencja transmisji wymaga uprawnienia "signature" lub "signatureOrSystem" protectionLevel albo znajduje się na liście wyjątków.
- [C-0-7] Jeśli aplikacja jest kierowana na poziom interfejsu API 25 lub wyższy, MUSI zatrzymać usługi działające w tle, tak jakby aplikacja wywołała metodę stopSelf() usługi, chyba że aplikacja została umieszczona na liście dozwolonych tymczasowo w celu wykonania zadania widocznego dla użytkownika.
- [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zwolnić blokadę aktywacji, którą posiada.
[C-0-9] Urządzenia MUSZĄ zwracać wymienionych dostawców zabezpieczeń jako pierwsze 7 wartości tablicy z metody Security.getProviders(), w podanej kolejności i z podanymi nazwami (zwróconymi przez Provider.getName()) oraz klasami, chyba że aplikacja zmodyfikowała listę za pomocą metody insertProviderAt() lub removeProvider(). Urządzenia MOGĄ zwracać dodatkowych dostawców po wskazanej 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 Compatibility Test Suite (CTS) testuje znaczne części platformy pod kątem zgodności behawioralnej, ale nie wszystkich. Implementator jest odpowiedzialny za zapewnienie zgodności z zachowaniem w projekcie Android Open Source. Dlatego implementatorzy urządzeń powinni w miarę możliwości używać kodu źródłowego dostępnego w ramach Projektu Android Open Source, a nie ponownie wdrażać istotnych części systemu.

3.5.1. Ograniczenie aplikacji

Jeśli implementacje urządzeń implementują zastrzeżony mechanizm ograniczania aplikacji, a mechanizm ten jest bardziej restrykcyjny niż element rzadko używanej aplikacji w stanie gotowości, to:

[C-1-1] NALEŻY zapewnić użytkownikowi możliwość wyświetlenia listy aplikacji objętych ograniczeniami.
[C-1-2] NALEŻY umożliwić użytkownikowi włączenie lub wyłączenie ograniczeń w poszczególnych aplikacjach.
[C-1-3] Nie wolno automatycznie stosować ograniczeń bez dowodu na nieprawidłowe działanie systemu, ale można stosować ograniczenia w przypadku wykrycia nieprawidłowego działania systemu, takiego jak zablokowane blokady budzenia, długotrwałe uruchamianie usług i inne kryteria. Kryteria mogą być określane przez implementatorów urządzenia, ale MUSZĄ być związane z wpływem aplikacji na stan systemu. Nie należy używać innych kryteriów, które nie są ściśle związane ze stanem systemu, takich jak brak popularności aplikacji na rynku.
[C-1-4] NIE WOLNO automatycznie stosować ograniczeń aplikacji, gdy użytkownik ręcznie je wyłączył. MOŻNA zasugerować użytkownikowi zastosowanie ograniczeń aplikacji.
[C-1-5] NALEŻY informować użytkowników, jeśli ograniczenia są stosowane automatycznie. Informacje te MUSZĄ zostać podane w ciągu 24 godzin od zastosowania ograniczeń.
[C-1-6] W przypadku wywołania tego interfejsu API przez aplikację z ograniczonym dostępem musi on zwracać wartość true dla ActivityManager.isBackgroundRestricted().
[C-1-7] NIE MOŻESZ ograniczać działania głównej aplikacji na pierwszym planie, której użytkownik używa w pełni.
[C-1-8] NALEŻY zawiesić ograniczenia dotyczące aplikacji, która staje się główną aplikacją na pierwszym planie, gdy użytkownik wyraźnie zacznie z niej korzystać.

3.6. Nazwy katalogów interfejsu API

Android stosuje konwencje dotyczące przestrzeni nazw pakietów i klas zdefiniowane przez język programowania Java. Aby zapewnić zgodność z aplikacjami innych firm, implementatorzy urządzeń NIE MOGĄ wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w następujących przestrzeniach nazw pakietów:

java.*
javax.*
sun.*
android.*
androidx.*
com.android.*

Oznacza to, że:

[C-0-1] Nie wolno modyfikować publicznie udostępnionych interfejsów API na platformie Androida przez zmianę sygnatur metod lub klas albo usunięcie klas lub pól klas.
[C-0-2] DO interfejsów API w wymienionych powyżej przestrzeniach nazw NIE MOŻESZ dodawać żadnych publicznie dostępnych elementów (np. klas, interfejsów, pól lub metod do istniejących klas lub interfejsów) ani interfejsów API Test lub System. „Publicznie dostępny element” to dowolna konstrukcja, która nie jest ozdobiona znacznikiem „@hide” używanym w poprzednim kodzie źródłowym Androida.

Implementatorzy urządzeń MOGĄ modyfikować podstawową implementację interfejsów API, ale takie modyfikacje:

[C-0-3] NIE MOŻE wpływać na opisane zachowanie i sygnatura języka Java w żadnym z publicznie udostępnionych 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 ani nie może odnosić się do innej organizacji. Na przykład implementatorzy 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ć zapakowany w bibliotece współdzielonej Androida, aby tylko aplikacje, które z nich korzystają (za pomocą mechanizmu <uses-library>), były objęte zwiększonym zużyciem pamięci przez te interfejsy API.

Jeśli implementator urządzenia zamierza ulepszyć jedną z wymienionych powyżej nazw przestrzeni nazw pakietu (np. przez dodanie nowej przydatnej funkcji do istniejącego interfejsu API lub dodanie nowego interfejsu API), powinien odwiedzić stronę source.android.com i rozpocząć proces przesyłania 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. Celem tej sekcji jest po prostu wzmocnienie tych konwencji i ustanowienie ich jako wiążących poprzez uwzględnienie w tej definicji zgodności.

3.7. Zgodność w czasie działania

Implementacje na urządzeniu:

[C-0-1] MUSI obsługiwać pełny format Dalvik Executable (DEX) oraz specyfikację i semantykę kodu bajtowego Dalvik.
[C-0-2] NALEŻY skonfigurować środowisko uruchomieniowe Dalvik tak, aby przydzielać pamięć zgodnie z górną platformą Androida i jak to określono w tabeli poniżej. (Definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).
NALEŻY użyć Android RunTime (ART), referencyjnej implementacji upstream formatu wykonywalnego Dalvik oraz systemu zarządzania pakietami referencyjnej implementacji.
NALEŻY przeprowadzić testy fuzz w różnych trybach wykonywania i na różnych architekturach docelowych, aby zapewnić stabilność środowiska uruchomieniowego. Zapoznaj się z informacjami o JFuzz i DexFuzz na stronie Projektu Android Open Source.

Pamiętaj, że podane poniżej wartości pamięci są wartościami minimalnymi, a implementacje urządzeń MOŻE przydzielić więcej pamięci na aplikację.

Układ ekranu	Gęstość ekranu	Minimalna pamięć aplikacji
Android Watch	120 dpi (ldpi)	32 MB
	140 dpi
	160 dpi (mdpi)
	180 dpi (180 dpi)
	200 dpi
	213 dpi (tvdpi)
	220 dpi	36 MB
	240 dpi (hdpi)
	280 dpi
	320 dpi (xhdpi)	48 MB
	360 dpi	48 MB
	400 dpi (400 dpi)	56 MB
	420 dpi (420 dpi)	64 MB
	480 dpi (xxhdpi)	88 MB
	560 dpi (560 dpi)	112 MB
	640 dpi (xxxhdpi)	154 MB
małe/normalne	120 dpi (ldpi)	32 MB
	140 dpi
	160 dpi (mdpi)
	180 dpi (180 dpi)	48 MB
	200 dpi
	213 dpi (tvdpi)
	220 dpi
	240 dpi (hdpi)
	280 dpi
	320 dpi (xhdpi)	80 MB
	360 dpi	80 MB
	400 dpi (400 dpi)	96 MB
	420 dpi (420 dpi)	112 MB
	480 dpi (xxhdpi)	128 MB
	560 dpi (560 dpi)	192 MB
	640 dpi (xxxhdpi)	256 MB
duży	120 dpi (ldpi)	32 MB
	140 dpi	48 MB
	160 dpi (mdpi)	48 MB
	180 dpi (180 dpi)	80 MB
	200 dpi
	213 dpi (tvdpi)
	220 dpi
	240 dpi (hdpi)
	280 dpi	96 MB
	320 dpi (xhdpi)	128 MB
	360 dpi	160 MB
	400 dpi (400 dpi)	192 MB
	420 dpi (420 dpi)	228 MB
	480 dpi (xxhdpi)	256 MB
	560 dpi (560 dpi)	384 MB
	640 dpi (xxxhdpi)	512 MB
bardzo duża	120 dpi (ldpi)	48 MB
	140 dpi	80 MB
	160 dpi (mdpi)	80 MB
	180 dpi (180 dpi)	96 MB
	200 dpi
	213 dpi (tvdpi)
	220 dpi
	240 dpi (hdpi)
	280 dpi	144 MB
	320 dpi (xhdpi)	192 MB
	360 dpi	240 MB
	400 dpi (400 dpi)	288 MB
	420 dpi (420 dpi)	336 MB
	480 dpi (xxhdpi)	384 MB
	560 dpi (560 dpi)	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ądzenie (ekran główny).

Jeśli implementacje urządzeń umożliwiają zastąpienie ekranu głównego urządzenia aplikacjami innych firm, muszą one:

[C-1-1] NALEŻY zadeklarować funkcję platformy android.software.home_screen.
[C-1-2] NALEŻY zwrócić obiekt AdaptiveIconDrawable, gdy aplikacja innej firmy używa tagu <adaptive-icon> do wyświetlenia ikony i wywołuje metody PackageManager, aby pobrać ikony.

Jeśli implementacje urządzeń obejmują domyślny program uruchamiający, który obsługuje przypinanie skrótów w aplikacji, muszą one:

[C-2-1] MUST report true for ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] Przed dodaniem skrótu żądanego przez aplikacje za pomocą metody interfejsu API ShortcutManager.requestPinShortcut() należy poprosić użytkownika o pozwolenie.
[C-2-3] MUSI obsługiwać przypięte skróty oraz skróty dynamiczne i statyczne zgodnie z informacjami na stronie Skróty do aplikacji.

Jeśli implementacja urządzenia nie obsługuje przypinania skrótów w aplikacji, nie można:

[C-3-1] MUST report false for ShortcutManager.isRequestPinShortcutSupported().

Jeśli implementacje urządzeń korzystają z 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 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ń obejmują domyślną aplikację uruchamiającą, która wyświetla plakietki dla ikon aplikacji, muszą one:

[C-5-1] MUSI przestrzegać metody interfejsu API NotificationChannel.setShowBadge(). Innymi słowy, wyświetlaj wizualną ikonę powiązaną z ikoną aplikacji, jeśli wartość jest ustawiona na true, i nie wyświetlaj żadnego schematu plakietki ikony aplikacji, gdy wszystkie kanały powiadomień aplikacji mają ustawioną wartość false.
MOGĄ zastąpić plakietki ikon aplikacji zastrzeżonymi schematami plakietek, gdy aplikacje innych firm wskazują na obsługę zastrzeżonych schematów plakietek za pomocą zastrzeżonych interfejsów API, ale POWINNY używać zasobów i wartości udostępnianych przez interfejsy API plakietek powiadomień opisane w pakiecie SDK, takich jak Notification.Builder.setNumber() i interfejs API Notification.Builder.setBadgeIconType().

3.8.2. Widżety

Android obsługuje widżety aplikacji innych firm, definiując typ komponentu i odpowiednie interfejsy API oraz cykl życia, które umożliwiają aplikacjom udostępnianie „widżetu aplikacji” użytkownikowi końcowemu.

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

[C-1-1] NALEŻY zadeklarować obsługę funkcji platformy android.software.app_widgets.
[C-1-2] Musisz uwzględnić wbudowane funkcje obsługi widżetów aplikacji i zapewnić użytkownikom możliwość dodawania, konfigurowania, wyświetlania i usuwania widżetów bezpośrednio w wyskakującym okienku.
[C-1-3] Musi być możliwe renderowanie widżetów o standardowym rozmiarze siatki 4 x 4. Szczegółowe informacje znajdziesz w wytycznych dotyczących projektowania widżetów aplikacji w dokumentacji pakietu Android SDK.
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, muszą:

[C-2-1] MUST report true for AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] Przed dodaniem skrótu żądanego przez aplikacje za pomocą metody interfejsu API AppWidgetManager.requestPinAppWidget() należy poprosić użytkownika o pozwolenie.

3.8.3. Powiadomienia

Android zawiera interfejsy Notification i NotificationManager, które umożliwiają deweloperom aplikacji innych firm powiadamianie użytkowników o istotnych zdarzeniach i przyciąganie ich uwagi za pomocą komponentów sprzętowych (np. dźwięku, wibracji i światła) oraz funkcji oprogramowania (np. panelu powiadomień, paska systemowego).

3.8.3.1. Prezentacja powiadomień

Jeśli implementacje urządzeń zezwalają aplikacjom innych firm na powiadamianie użytkowników o istotnych zdarzeniach, mogą one:

[C-1-1] MUSI obsługiwać powiadomienia, które korzystają z funkcji sprzętowych zgodnie z dokumentacją pakietu SDK oraz w jak największym stopniu z urządzenia implementującego sprzęt. Jeśli na przykład implementacja urządzenia zawiera wibrator, musi prawidłowo implementować interfejsy API wibracji. Jeśli implementacja urządzenia nie zawiera sprzętu, odpowiednie interfejsy API MUSZĄ być zaimplementowane jako no-ops. Więcej informacji o tym znajdziesz w sekcji 7.
[C-1-2] Aplikacja MUSI prawidłowo wyświetlać wszystkie zasobów (ikony, pliki animacji itp.) udostępnione w interfejsach API lub w przewodniku po stylu ikon w pasku stanu/systemowym, ale MOŻE oferować alternatywne wrażenia użytkownika dotyczące powiadomień niż te dostępne w implementacji referencyjnej na Androidzie Open Source.
[C-1-3] MUSISZ prawidłowo stosować zachowania opisane w interfejsach API dotyczące aktualizowania, usuwania i grupowania powiadomień.
[C-1-4] NALEŻY podać pełne informacje o zachowaniu interfejsu NotificationChannel w dokumentacji pakietu SDK.
[C-1-5] Musisz umożliwić użytkownikowi zablokowanie i zmodyfikowanie powiadomienia określonej aplikacji innej firmy na każdym poziomie kanału i poziomu pakietu aplikacji.
[C-1-6] NALEŻY również zapewnić użytkownikowi możliwość wyświetlenia usuniętych kanałów powiadomień.
[C-1-7] NALEŻY prawidłowo renderować wszystkie zasoby (obrazy, naklejki, ikony itp.) udostępnione za pomocą Notification.MessagingStyle wraz z tekstem powiadomienia bez dodatkowej interakcji użytkownika. Na przykład w rozmowie grupowej ustawionej za pomocą setGroupConversation MUSI wyświetlać się wszystkie zasoby, w tym ikony udostępnione przez android.app.Person.
[C-SR] MOCNO ZALECAMY automatyczne wyświetlanie użytkownikowi opcji blokowania powiadomień z określonej aplikacji innej firmy na poziomie każdego kanału i pakietu aplikacji po tym, jak użytkownik wielokrotnie zamknie powiadomienie.
Powinien obsługiwać powiadomienia z elementami rozszerzonymi.
Niektóre powiadomienia o wyższym priorytecie powinny być wyświetlane jako powiadomienia z ostrzeżeniem.
NALEŻY umożliwić użytkownikowi wyciszenie 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 rozmowie, czyli powiadomień, które korzystają z MessagingStyle i zawierają opublikowany identyfikator skrótu Osoby.

Implementacje na urządzeniu:

[C-SR] MOCNO POLECAMY grupowanie i wyświetlanie powiadomień conversation notifications przed powiadomieniami niebędącymi rozmową, z wyjątkiem powiadomień o bieżącej usłudze na pierwszym planie oraz powiadomień importance:high.

Jeśli implementacje urządzeń obsługują conversation notifications, a aplikacja udostępnia wymagane dane do bubbles, to:

[C-SR] MOCNO ZALECAMY wyświetlanie tej rozmowy jako dymek. Implementacja AOSP spełnia te wymagania dzięki domyślnemu interfejsowi System UI, ustawieniom i wywoływaczemu.

Jeśli implementacje urządzeń obsługują powiadomienia z zawartością multimedialną, mogą:

[C-2-1] W przypadku prezentowanych elementów zasobów NALEŻY używać zasobów dokładnie takich, jakie są udostępniane przez klasę interfejsu API Notification.Style i jej podklasy.
NALEŻY przedstawić wszystkie elementy zasobu (np. ikonę, tytuł i tekst podsumowania) zdefiniowane w klasie interfejsu API Notification.Style i jej podklasach.

Jeśli implementacje urządzeń obsługują powiadomienia o zbliżającym się terminie:

[C-3-1] NALEŻY używać widoku powiadomień w ramce oraz zasobów opisanych w klasie interfejsu API Notification.Builder, gdy wyświetlane są powiadomienia w ramce.
[C-3-2] NALEŻY 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 API NotificationListenerService, które umożliwiają aplikacjom (po wyraźnym włączeniu przez użytkownika) otrzymywanie kopii wszystkich powiadomień w miarę ich publikowania lub aktualizowania.

Implementacje na urządzeniu:

[C-0-1] NALEŻY prawidłowo i na bieżąco aktualizować powiadomienia w całości w przypadku wszystkich zainstalowanych usług odsłuchujących, w tym wszystkich metadanych dołączonych do obiektu powiadomienia.
[C-0-2] MUSI obsługiwać wywołanie interfejsu API snoozeNotification(), zamknąć powiadomienie i wykonać wywołanie zwrotne po upływie czasu wyciszenia ustawionego w wywołaniu interfejsu API.

Jeśli implementacje urządzeń umożliwiają użytkownikom wyciszanie powiadomień, muszą one:

[C-1-1] MUSI prawidłowo odzwierciedlać stan powiadomienia wyciszonego za pomocą standardowych interfejsów API, takich jak NotificationListenerService.getSnoozedNotifications().
[C-1-2] Musisz umożliwić użytkownikom odkładanie powiadomień z każdej zainstalowanej aplikacji innej firmy, chyba że pochodzą one z usług działających w tle lub na pierwszym planie.

3.8.3.3. Nie przeszkadzać

Jeśli implementacje urządzeń obsługują funkcję DND, to:

[C-1-1] NALEŻY, gdy implementacja urządzenia zapewnia użytkownikowi możliwość przyznania lub odmowy przyznania dostępu aplikacjom innych firm do konfiguracji DND, wyświetlać automatyczne reguły DND utworzone przez aplikacje obok zdefiniowanych przez użytkownika i zdefiniowanych wstępnie reguł.
[C-1-3] MUSI obsługiwać wartości suppressedVisualEffects przekazywane w ramach NotificationManager.Policy. Jeśli aplikacja ma ustawione flagi SUPPRESSED_EFFECT_SCREEN_OFF lub SUPPRESSED_EFFECT_SCREEN_ON, POWINNA poinformować użytkownika, że efekty wizualne są tłumione w menu ustawień DND.

3.8.4. Szukaj

Android zawiera interfejsy API, które umożliwiają deweloperom włączanie wyszukiwania w aplikacjach i udostępnianie danych aplikacji w globalnym wyszukiwaniu systemowym. Ogólnie rzecz biorąc, ta funkcja składa się z jednego interfejsu użytkownika obejmującego cały system, który umożliwia wpisywanie zapytań, wyświetlanie sugestii podczas wpisywania tekstu oraz wyświetlanie wyników. Interfejsy API Androida umożliwiają deweloperom ponowne używanie tego interfejsu do udostępniania wyszukiwania w ich własnych aplikacjach oraz dostarczania wyników do wspólnego globalnego interfejsu wyszukiwania.

Implementacje na urządzeniach z Androidem powinny obejmować wyszukiwanie globalne, czyli jeden wspólny interfejs wyszukiwania w całym systemie, który może wyświetlać w czasie rzeczywistym sugestie w odpowiedzi na dane wejściowe użytkownika.

Jeśli implementacje na urządzeniach korzystają z globalnego interfejsu wyszukiwania, muszą:

[C-1-1] NALEŻY wdrożyć interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii do pola wyszukiwania, gdy jest ono używane w trybie wyszukiwania globalnego.

Jeśli nie masz zainstalowanych aplikacji innych firm, które korzystają z wyszukiwania globalnego:

Domyślne zachowanie to wyświetlanie sugestii i wyników wyszukiwarki internetowej.

Android zawiera też interfejsy API Asystenta, które umożliwiają aplikacjom określenie, ile informacji o bieżącym kontekście ma być udostępniane Asystentowi na urządzeniu.

Jeśli implementacje urządzeń obsługują działanie Asystent:

[C-2-1] NALEŻY wyraźnie poinformować użytkownika, kiedy kontekst jest udostępniany, w ten sposób:
- Za każdym razem, gdy aplikacja asystująca uzyskuje dostęp do kontekstu, wyświetla białe światło na krawędziach ekranu, które odpowiada lub przekracza czas trwania i jasność implementacji projektu Android Open Source.
- W przypadku wstępnie zainstalowanej aplikacji asystenta użytkownik musi mieć możliwość wykonania nie więcej niż 2 operacji nawigacyjnych od domyślnego menu ustawień głosowego wprowadzania danych i aplikacji asystenta oraz udostępniać kontekst tylko wtedy, gdy użytkownik wywoła aplikację asystenta za pomocą słowa kluczowego lub przycisku nawigacyjnego asystenta.
[C-2-2] Wyznaczona interakcja, która uruchamia aplikację wspomagającą zgodnie z opisem w sekcji 7.2.3, MUSI uruchamiać wybraną przez użytkownika aplikację wspomagającą, czyli aplikację, która implementuje VoiceInteractionService, lub aktywność obsługującą intencję ACTION_ASSIST.

3.8.5. Alerty i powiadomienia wyświetlane na ekranie

Aplikacje mogą używać interfejsu API Toast, aby wyświetlać krótkie niemodalne ciągi tekstowe, które znikają po krótkim czasie, oraz interfejsu API typu okna TYPE_APPLICATION_OVERLAY, aby wyświetlać okna alertów jako nakładki na inne aplikacje.

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

[C-1-1] NALEŻY umożliwić użytkownikowi zablokowanie wyświetlania przez aplikację okien alertów, które używają TYPE_APPLICATION_OVERLAY . Implementacja AOSP spełnia ten wymóg, ponieważ zawiera elementy sterujące w pasku powiadomień.
[C-1-2] NALEŻY stosować interfejs Toast API i wyświetlać komunikaty Toast użytkownikom w wyraźnie widoczny sposób.

3.8.6. Motywy

Android udostępnia „motywy” jako mechanizm, który pozwala aplikacjom stosować style w całej aktywności lub aplikacji.

Android zawiera rodzinę motywów „Holo” i „Material” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i wykonanie motywu Holo zgodnie z definicją w pakiecie Android SDK.

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

[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 Design ani zasobów udostępnianych aplikacjom.
[C-1-3] NALEŻY ustawić rodzinę czcionek „sans-serif” na Roboto w wersji 2.x w przypadku języków obsługiwanych przez Roboto lub umożliwić użytkownikowi zmianę czcionki używanej w przypadku rodziny czcionek „sans-serif” na Roboto w wersji 2.x w przypadku języków obsługiwanych przez Roboto.

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 sposób obsługi motywu urządzenia zgodnie z definicją implementatora urządzenia.

Implementacje na urządzeniach mogą modyfikować atrybuty domyślnego motywu urządzenia udostępniane aplikacjom.

Android obsługuje wariant motywu z przezroczystymi paskami systemu, co pozwala deweloperom aplikacji wypełnić obszar za paskiem stanu i paskiem nawigacji treściami aplikacji. Aby zapewnić spójne środowisko deweloperów w ramach tej konfiguracji, ważne jest, aby styl ikony paska stanu był zachowany na różnych urządzeniach.

Jeśli implementacje urządzeń zawierają pasek stanu systemu, muszą:

[C-2-1] Należy używać koloru białego do ikon stanu systemu (takich jak siła sygnału i poziom naładowania baterii) i powiadomień wysyłanych przez system, chyba że ikona wskazuje stan problemowy lub aplikacja prosi o jasny pasek stanu za pomocą flagi SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
[C-2-2] Implementacje urządzeń z Androidem MUSZĄ zmienić kolor ikon stanu systemu na czarny (szczegóły znajdziesz w R.style), gdy aplikacja poprosi o jasny pasek 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 „animowanej tapety”. Animowane tapety to animacje, wzory lub podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które wyświetlają się jako tapeta za innymi aplikacjami.

Urządzenie jest uznawane za zdolne do niezawodnego wyświetlania tapet na żywo, jeśli może wyświetlać wszystkie tapety na żywo bez ograniczeń funkcjonalności, przy rozsądznej częstotliwości klatek i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują, że tapety lub aplikacje ulegają awarii, nie działają prawidłowo, zużywają zbyt dużo energii procesora lub baterii albo działają z niedopuszczalnie niską liczbą klatek na sekundę, sprzęt jest uznawany za niezdolny do obsługi tapety na żywo. Na przykład niektóre tapety na żywo mogą używać kontekstu OpenGL 2.0 lub 3.x do renderowania treści. Tapeta na żywo nie będzie działać prawidłowo na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ używanie przez nią tego kontekstu może powodować konflikty z innymi aplikacjami, które również go używają.

Urządzenia, które mogą niezawodnie wyświetlać tapety na żywo w sposób opisany powyżej, POWINNY obsługiwać tapety na żywo.

Jeśli implementacje urządzeń obsługują animowane tapety, mogą:

[C-1-1] MUSI raportować flagę funkcji platformy android.software.live_wallpaper.

3.8.8. Przełączanie aktywności

Dostarczony przez Ciebie kod źródłowy Androida zawiera ekran przeglądu, czyli interfejs użytkownika na poziomie systemu, który umożliwia przełączanie zadań i wyświetlanie ostatnio używanych czynności i zadań za pomocą miniatury graficznego stanu aplikacji w momencie, gdy użytkownik ostatnio ją zamknął.

Implementacje urządzeń, w tym klucz nawigacji funkcji ostatnich, zgodnie z opisem w sekcji 7.2.3, MOGĄ zmienić interfejs.

Jeśli implementacje urządzeń, w tym klucz nawigacyjny funkcji Ostatnie, zgodnie z opisem w sekcji 7.2.3 zmieniają interfejs, muszą:

[C-1-1] Musi obsługiwać co najmniej 7 wyświetlanych aktywności.
POWINIEN wyświetlać tytuły co najmniej 4 aktywności naraz.
[C-1-2] NALEŻY wdrożyć zachowanie przypinania ekranu i udostępnić użytkownikowi menu ustawień, aby włączyć tę funkcję.
NALEŻY wyświetlić kolor wyróżnienia, ikonę i tytuł ekranu w sekcji Ostatnie.
NALEŻY wyświetlić opcję zamknięcia („x”), ale MOŻNA opóźnić to, dopóki użytkownik nie wejdzie w interakcję z ekranami.
NALEŻY wdrożyć skrót umożliwiający łatwe przełączanie się na poprzednią aktywność.
POWINIEN wywoływać szybkie przełączanie między 2 ostatnio używanymi aplikacjami, gdy użytkownik dwukrotnie kliknie przycisk funkcji Ostatnio używane.
POWINIEN aktywować tryb wielookienkowy (jeśli jest obsługiwany) po długim naciśnięciu klawisza funkcji Ostatnie.
MOŻNA wyświetlać powiązane ostatnie elementy jako grupę, która porusza się razem.
[SR] NAJLEPSZEJ jest użycie na ekranie przeglądu interfejsu Androida (lub podobnego interfejsu opartego na miniaturach).

3.8.9. Zarządzanie wejściami

Android obsługuje zarządzanie wprowadzaniem oraz edytory metod wprowadzania innych firm.

Jeśli implementacje urządzeń umożliwiają użytkownikom korzystanie z metod wprowadzania danych innych firm, użytkownicy mogą:

[C-1-1] NALEŻY zadeklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy API IME zgodnie z dokumentacją pakietu Android SDK.

3.8.10. Sterowanie multimediami na ekranie blokady

W Androidzie 5.0 interfejs Remote Control Client API został wycofany na rzecz szablonu powiadomienia multimedialnego, który umożliwia aplikacjom multimedialnym integrację z elementami sterowania odtwarzaniem wyświetlanymi na ekranie blokady.

3.8.11. Wygaszacze ekranu (wcześniej Dreams)

Aby dowiedzieć się, jak skonfigurować wygaszacze ekranu, zapoznaj się z sekcją 3.2.3.5.

3.8.12. Lokalizacja

Jeśli implementacje urządzeń zawierają czujnik sprzętowy (np. GPS), który może dostarczyć współrzędnych lokalizacji,

[C-1-2] Musisz wyświetlić bieżący stan lokalizacji w menu Lokalizacja w Ustawieniach.
[C-1-3] NIE MOŻNA 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, muszą:

[C-1-1] Musi być możliwe renderowanie tych emotikonów w kolorze.
[C-1-2] MUSI obsługiwać:
- czcionka Roboto 2 w różnych grubościach: bezszeryfowa cienka, bezszeryfowa zwykła, bezszeryfowa pogrubiała, bezszeryfowa czarna, bezszeryfowa wąska, bezszeryfowa wąska zwykła w przypadku języków dostępnych na urządzeniu.
- Pełne pokrycie Unicode 7.0 dla alfabetów łacińskiego, greckiego i cyrylickiego, w tym zakresów Latin Extended A, B, C i D oraz wszystkich znaków w bloku symboli walut w Unicode 7.0.
POWINIEN obsługiwać odcienie skóry i emotikony przedstawiające różne rodziny, zgodnie z raportami technicznymi Unicode nr 51.

Jeśli implementacje na urządzeniach obejmują IME, muszą:

NALEŻY podać użytkownikowi metodę wprowadzania tych emotikonów.

Android obsługuje renderowanie czcionek birmańskich. W Mjanmie do wyświetlania języków mjanma używa się kilku czcionek niezgodnych z Unicode, powszechnie znanych jako „Zawgyi”.

Jeśli implementacja urządzenia obejmuje obsługę języka birmańskiego, urządzenie:

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. Wiele okien

Jeśli implementacje urządzeń mają możliwość wyświetlania wielu aktywności jednocześnie, muszą:

[C-1-1] NALEŻY wdrożyć takie tryby wielookienności zgodnie z zachowaniem aplikacji i interfejsami API opisanymi w dokumentacji obsługi trybu wielookienności pakietu Android SDK oraz spełnić te wymagania:
[C-1-2] Musi obsługiwać wartość android:resizeableActivity ustawioną przez aplikację w pliku AndroidManifest.xml zgodnie z opisem w tym pakiecie SDK.
[C-1-3] Nie wolno oferować trybu podzielonego ekranu ani trybu swobodnego, jeśli wysokość ekranu jest mniejsza niż 440 dp, a szerokość mniejsza niż 440 dp.
[C-1-4] W trybach wielookiennych innych niż tryb obraz w obrazie rozmiar aktywności NIE MOŻE być mniejszy niż 220 dp.
Implementacje urządzeń o rozmiarach ekranu xlarge POWINNY obsługiwać tryb swobodny.

Jeśli implementacje urządzeń obsługują tryb wielu okien i tryb podzielonego ekranu, muszą:

[C-2-1] NALEŻY wstępnie wczytać jako domyślny moduł uruchamiający aplikację, który można zmienić rozmiar.
[C-2-2] Należy przyciąć dokowane okno w ramach podzielonego ekranu, ale NALEŻY pokazać część jego zawartości, jeśli aplikacja Launcher jest oknem aktywnym.
[C-2-3] MUSI honorować zadeklarowane wartości AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight aplikacji uruchamiającej innej firmy oraz nie może zastępować tych wartości podczas wyświetlania niektórych treści w ramach zadokowanej aktywności.

Jeśli implementacje urządzeń obsługują tryb wielu okien i tryb obrazu w obrazie, muszą:

[C-3-1] Musisz uruchamiać czynności w wielozadaniowym trybie obrazu w obrazie, gdy aplikacja: * jest kierowana na interfejs API na poziomie 26 lub nowszym i deklaruje android:supportsPictureInPicture * jest 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 SystemUI zgodnie z bieżącą aktywnością PIP za pomocą interfejsu API setActions().
[C-3-3] Musi obsługiwać formaty obrazu o proporcjach większych lub równych 1:2,39 i mniejszych lub równych 2,39:1, jak określono w działalności PIP za pomocą interfejsu API setAspectRatio().
[C-3-4] DO sterowania oknem PIP należy UŻYWAĆ KeyEvent.KEYCODE_WINDOW; jeśli tryb PIP nie jest obsługiwany, klucz MUSI być dostępny dla aktywności na pierwszym planie.
[C-3-5] Musisz umożliwić użytkownikowi zablokowanie wyświetlania aplikacji w trybie obrazu w obrazie. Implementacja AOSP spełnia ten wymóg dzięki elementom sterującym w pasku powiadomień.
[C-3-6] W przypadku aplikacji, które nie deklarują wartości dla atrybutów AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight, należy przypisać minimalną szerokość i wysokość okna PIP:
- Urządzenia z wartością Configuration.uiMode inną niż UI_MODE_TYPE_TELEVISION MUSZĄ mieć minimalną szerokość i wysokość wynoszącą 108 dp.
- Urządzenia z wartością UI_MODE_TYPE_TELEVISION w ustawieniu Configuration.uiMode MUSZĄ mieć minimalną szerokość 240 dp i minimalną wysokość 135 dp.

3.8.15. Wycięcie w ekranie

Android obsługuje wycięcie wyświetlacza zgodnie z opisem w dokumentacji pakietu SDK. Interfejs API DisplayCutout definiuje obszar na krawędzi wyświetlacza, który może nie być funkcjonalny dla aplikacji z powodu wycięcia lub zakrzywionego wyświetlacza na krawędzi.

Jeśli implementacje urządzeń zawierają wycięcia w ekranie, muszą spełniać te wymagania:

[C-1-5] Nie wolno stosować wycięć, jeśli format obrazu urządzenia wynosi 1,0 (1:1).
[C-1-2] Nie może być więcej niż 1 wycięcia na krawędź.
[C-1-3] MUSI obsługiwać flagi wycięcia wyświetlacza ustawione przez aplikację za pomocą interfejsu API WindowManager.LayoutParams zgodnie z opisem w pakiecie SDK.
[C-1-4] Musisz podać prawidłowe wartości wszystkich danych typu cutout 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ądzeniem, aby użytkownicy mogli szybko sprawdzić jego stan i wykonać określone działanie.

Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2_2_3.

3.9. Administracja urządzeniem

Android zawiera funkcje, które umożliwiają aplikacjom z zabezpieczeniami wykonywanie funkcji administracyjnych na poziomie systemu, takich jak egzekwowanie zasad dotyczących haseł czy zdalne wymazywanie danych, za pomocą interfejsu Android Device Administration API.

Jeśli implementacje urządzeń implementują pełny zakres zasad zarządzania urządzeniami zdefiniowanych w dokumentacji pakietu SDK Androida, to:

[C-1-1] MUST declare android.software.device_admin.
[C-1-2] MUSI obsługiwać konfigurowanie właściciela urządzenia zgodnie z opisem w sekcji 3.9.1 i sekcji 3.9.1.1.

3.9.1 Obsługa administracyjna urządzenia

3.9.1.1 Obsługa administracyjna właściciela urządzenia

Jeśli implementacje na urządzeniu deklarują android.software.device_admin, to:

[C-1-1] MUSI obsługiwać rejestrowanie klienta Device Policy (DPC) jako aplikacji właściciela urządzenia w sposób opisany poniżej:
- Gdy implementacja na urządzeniu nie ma jeszcze danych użytkownika, to:
  - [C-1-3] MUST report true for DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  - [C-1-4] W odpowiedzi na działanie intencyjne android.app.action.PROVISION_MANAGED_DEVICE aplikacja DPC MUSI zostać zarejestrowana jako aplikacja właściciela urządzenia.
  - [C-1-5] Aplikacja DPC MUSI być zarejestrowana jako aplikacja właściciela urządzenia, jeśli urządzenie deklaruje obsługę komunikacji Near Field Communication (NFC) za pomocą flagi funkcji android.hardware.nfc i odbiera wiadomość NFC zawierającą rekord z typem MIME MIME_TYPE_PROVISIONING_NFC.
- Gdy implementacja urządzenia zawiera dane użytkownika, to:
  - [C-1-6] MUST report false for the DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
  - [C-1-7] Nie wolno już rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia.
[C-1-2] Koniecznie wymagaj podjęcia działania przed rozpoczęciem lub w trakcie procesu konfiguracji, aby uzyskać zgodę na ustawienie aplikacji jako właściciela urządzenia. Użytkownik może wyrazić zgodę na przetwarzanie danych w sposób manualny lub programowy, ale przed rozpoczęciem obsługi administracyjnej właściciela urządzenia MUSI zostać wyświetlony odpowiedni komunikat o zbieraniu danych (opisywany w AOSP). Ponadto automatyczny mechanizm uzyskiwania zgody właściciela urządzenia używany (przez firmy) do obsługi właściciela urządzenia NIE MOŻE zakłócać działania funkcji „Out-Of-Box” w przypadku korzystania z urządzenia poza firmą.
[C-1-3] Nie wolno zakodować w twardym kodzie zgody na przetwarzanie danych ani uniemożliwiać korzystania z innych aplikacji właściciela urządzenia.

Jeśli implementacje urządzeń deklarują android.software.device_admin, ale zawierają też zastrzeżone rozwiązanie do zarządzania właścicielem urządzenia i mechanizm promowania aplikacji skonfigurowanej w ich rozwiązaniu jako „odpowiednik właściciela urządzenia” dla standardowego „właściciela urządzenia” rozpoznawanego przez standardowe interfejsy API DevicePolicyManager w Androidzie, to:

[C-2-1] Musisz mieć proces weryfikacji, który potwierdza, że konkretna reklamowana aplikacja należy do legalnego rozwiązania do zarządzania urządzeniami w firmie i że została już skonfigurowana w rozwiązaniu firmowym, aby mieć prawa równoważne z uprawnieniami „Właściciel urządzenia”.
[C-2-2] NALEŻY wyświetlić tę samą informację o zgodzie właściciela urządzenia w ramach AOSP, co w przypadku procesu inicjowanego przez android.app.action.PROVISION_MANAGED_DEVICE przed zarejestrowaniem aplikacji DPC jako „Właściciel urządzenia”.
MOŻE zawierać dane użytkownika na urządzeniu przed zarejestrowaniem aplikacji DPC jako „Właściciel urządzenia”.

3.9.1.2 Zarządzanie profilem zarządzanym

Jeśli implementacje na urządzeniu deklarują android.software.managed_users, to:

[C-1-1] IMPLEMENTOWAĆ interfejsy API, które umożliwiają aplikacji kontrolera zasad dotyczących urządzeń (DPC) stać się właścicielem nowego profilu zarządzanego.
[C-1-2] Proces obsługi inicjowany przez użytkowników w ramach zarządzanego profilu (android.app.action.PROVISION_MANAGED_PROFILE) MUSI być zgodny z implementacją AOSP.
[C-1-3] W ustawieniach należy DOSTARCZYĆ użytkownikowi następujące możliwości, aby poinformować go, że dana funkcja systemu została wyłączona przez kontroler zasad dotyczących urządzeń (DPC):
- Ujednoliconą ikonę lub inny element interfejsu użytkownika (np. ikonę informacji o AOSP) wskazujący, że określone ustawienie jest ograniczone przez administratora urządzenia.
- Krótki komunikat wyjaśniający, który administrator urządzenia udostępnia za pomocą setShortSupportMessage.
- Ikona aplikacji DPC

3.9.2 Obsługa profilu zarządzanego

Jeśli implementacje na urządzeniu deklarują android.software.managed_users, to:

[C-1-1] Musi obsługiwać profile zarządzane za pomocą interfejsów API android.app.admin.DevicePolicyManager.
[C-1-2] NALEŻY zezwolić na utworzenie tylko 1 profila zarządzanego.
[C-1-3] DO ZASŁANIA: ikona musi zawierać plakietkę (podobną do plakietki AOSP upstream) reprezentującą zarządzane aplikacje i widżety oraz inne elementy interfejsu z plakietką, takie jak Ostatnie i Powiadomienia.
[C-1-4] Musi wyświetlać ikonę powiadomienia (podobną do plakietki AOSP upstream) wskazującą, że użytkownik jest w aplikacji na profilu zarządzanym.
[C-1-5] NALEŻY wyświetlić komunikat podpowiadający, że użytkownik jest w profilu zarządzanym, gdy urządzenie się obudzi (ACTION_USER_PRESENT) i aplikacja na pierwszym planie znajduje się w profilu zarządzanym.
[C-1-6] Jeśli istnieje profil zarządzany, w oknie „Wybieranie” musi być widoczna opcja umożliwiająca użytkownikowi przekierowanie intencji z profilu zarządzanego do głównego użytkownika lub odwrotnie, jeśli jest to możliwe w ramach kontrolera zasad urządzenia.
[C-1-7] Jeśli istnieje profil zarządzany, NALEŻY udostępnić użytkownikowi podstawowemu i profilowi zarządzanemu te funkcje:
- oddzielne rozliczanie baterii, lokalizacji, danych mobilnych i zajęcia miejsca na dane w przypadku głównego użytkownika i profilu zarządzanego;
- niezależne zarządzanie aplikacjami VPN zainstalowanymi w profilu głównego użytkownika lub zarządzanym.
- niezależne zarządzanie aplikacjami zainstalowanymi na profilu głównego użytkownika lub profilu zarządzanym;
- niezależne zarządzanie kontami w ramach profilu głównego lub profilu zarządzanego,
[C-1-8] NALEŻY zadbać o to, aby wbudowane aplikacje do wybierania numerów, kontaktów i wiadomości mogły wyszukiwać i wyświetlać informacje o dzwoniącym z profilu zarządzanego (jeśli istnieje) obok informacji z profilu głównego, jeśli kontroler zasad urządzenia na to zezwala.
[C-1-9] MUSI spełniać wszystkie wymagania dotyczące zabezpieczeń obowiązujące w przypadku urządzeń z włączoną funkcją wielu użytkowników (patrz sekcja 9.5), nawet jeśli profil zarządzany nie jest liczony jako dodatkowy użytkownik oprócz głównego użytkownika.

Jeśli implementacje na urządzeniu deklarują android.software.managed_users i android.software.secure_lock_screen, mają:

[C-2-1] Musisz obsługiwać możliwość określenia osobnego ekranu blokady, który spełnia poniższe wymagania, aby zezwolić na dostęp do aplikacji działających tylko w profilu zarządzanym.
- Implementacje urządzeń MUSZĄ obsługiwać 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 w profilu zarządzanym MUSZĄ korzystać z tych samych mechanizmów przechowywania i zarządzania danymi logowania co profil nadrzędny, zgodnie z dokumentacją na stronie projektu Androida Open Source.
- Zasady dotyczące haseł w DPC MUSZĄ dotyczyć tylko danych logowania na ekranie blokady w profilu zarządzanym, chyba że są wywoływane w przypadku instancji DevicePolicyManager zwracanej przez funkcję getParentProfileInstance.
Gdy kontakty z profilu zarządzanego są wyświetlane w preinstalowanym dzienniku połączeń, interfejsie podczas połączenia, powiadomieniach o rozmowie w toku i nieodebranych połączeniach, kontaktach i aplikacjach do obsługi wiadomości, powinny być oznaczone tym samym znacznikiem, który jest używany do oznaczania aplikacji na profilu zarządzanym.

3.9.3 Pomoc dla zarządzanych użytkowników

Jeśli implementacje na urządzeniu deklarują android.software.managed_users, to:

[C-1-1] NALEŻY zapewnić użytkownikowi możliwość wylogowania się z bieżącego konta i powrotu do konta głównego w sesji dla wielu użytkowników, gdy isLogoutEnabled wróci do true. Element interfejsu użytkownika MUSI być dostępny na ekranie blokady bez odblokowywania urządzenia.

3.10. Ułatwienia dostępu

Android udostępnia warstwę ułatwień dostępu, która ułatwia osobom niepełnosprawnym poruszanie się po urządzeniach. Ponadto Android udostępnia interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu odbieranie wywołań zwrotnych dotyczących zdarzeń związanych z użytkownikiem i systemem oraz generowanie alternatywnych mechanizmów sprzężenia zwrotnego, takich jak odczytywanie tekstu na głos, sprzężenie zwrotne haptyczne i sterowanie za pomocą kulki sterującej lub panelu dotykowego.

Jeśli implementacje urządzeń obsługują usługi ułatwień dostępu innych firm, muszą:

[C-1-1] NALEŻY zaimplementować platformę dostępności Androida zgodnie z opisem w dokumentacji pakietu SDK interfejsów API dostępności.
[C-1-2] Musi generować zdarzenia ułatwień dostępu i przekazywać odpowiednie AccessibilityEvent do wszystkich zarejestrowanych implementacji AccessibilityService zgodnie z dokumentacją pakietu SDK.
[C-1-4] NALEŻY dodać przycisk na pasku nawigacyjnym systemu, który pozwoli użytkownikowi kontrolować usługę ułatwień dostępu, gdy włączone usługi ułatwień dostępu deklarują AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Pamiętaj, że w przypadku implementacji urządzenia bez paska nawigacji systemu to wymaganie nie ma zastosowania, ale implementacje urządzenia POWINNY umożliwiać użytkownikowi kontrolowanie tych usług ułatwień dostępu.

Jeśli implementacje na urządzeniach obejmują wstępnie zainstalowane usługi ułatwień dostępu, muszą:

[C-2-1] NALEŻY wdrożyć te wstępnie zainstalowane usługi ułatwień dostępu jako aplikacje Direct Boot Aware, gdy pamięć danych jest szyfrowana za pomocą szyfrowania na poziomie plików (FBE).
NALEŻY zapewnić w ramach procesu konfiguracji 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 gestyk powiększania.

3.11. Zamiana tekstu na mowę

Android zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług konwersji tekstu na mowę (TTS), a także umożliwia dostawcom usług implementowanie usług TTS.

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

[C-1-1] Musi obsługiwać interfejsy API Android TTS framework.

Jeśli implementacje urządzeń obsługują instalację zewnętrznych mechanizmów TTS, muszą:

[C-2-1] NALEŻY umożliwić użytkownikowi wybranie silnika TTS do użycia na poziomie systemu.

3.12. Framework wejścia TV

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

Jeśli implementacje urządzeń obsługują format TIF, to:

[C-1-1] NALEŻY zadeklarować funkcję platformy android.software.live_tv.
[C-1-2] MUSI obsługiwać wszystkie interfejsy TIF API, aby można było zainstalować aplikację, która korzysta z tych interfejsów, oraz korzystać z usługi zewnętrznych danych wejściowych na podstawie TIF na urządzeniu.

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ą element interfejsu użytkownika Szybkich ustawień i obsługują Szybkie ustawienia innych firm, muszą:

[C-1-1] Musisz zezwolić użytkownikowi na dodawanie i usuwanie kafelków udostępnianych przez interfejsy API quicksettings aplikacji innej firmy.
[C-1-2] Nie wolno automatycznie dodawać kafelka z aplikacji innej firmy bezpośrednio do Szybkich ustawień.
[C-1-3] NALEŻY 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 nieaktywne głosowo (Aplikacje), które współpracują z aplikacjami innych firm za pomocą MediaBrowser lub MediaSession, Aplikacje:

[C-1-2] MUSI wyraźnie wyświetlać ikony uzyskane za pomocą metody getIconBitmap() lub getIconUri() oraz tytuły uzyskane za pomocą metody getTitle() zgodnie z opisem w MediaDescription. Możesz skrócić tytuły, aby zachować zgodność z przepisami dotyczącymi bezpieczeństwa (np. w przypadku rozpraszania uwagi kierowcy).
[C-1-3] NALEŻY wyświetlić ikonę aplikacji zewnętrznej, gdy wyświetlane są treści dostarczane przez tę aplikację.
[C-1-4] Musisz umożliwić użytkownikowi interakcję z całą hierarchią MediaBrowser. MOŻE ograniczyć dostęp do części hierarchii, aby przestrzegać przepisów bezpieczeństwa (np. w przypadku rozpraszania uwagi kierowcy), ale NIE MOŻE faworyzować treści ani dostawcy treści.
[C-1-5] NALEŻY uznać dwukrotne kliknięcie KEYCODE_HEADSETHOOK lub KEYCODE_MEDIA_PLAY_PAUSE za KEYCODE_MEDIA_NEXT w przypadku MediaSession.Callback#onMediaButtonEvent.

3.15. Aplikacje błyskawiczne

Implementacje urządzeń MUSZĄ spełniać te wymagania:

[C-0-1] Aplikacje błyskawiczne MOGĄ mieć tylko te uprawnienia, dla których android:protectionLevel jest ustawione jako "instant".
[C-0-2] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami za pomocą domyślnych intencji, chyba że występuje jedna z tych sytuacji:
- Filtr wzoru intencji komponentu jest dostępny i ma wartość CATEGORY_BROWSABLE.
- Działanie to jedno z tych: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE.
- element docelowy jest jawnie udostępniany za pomocą atrybutu android:visibleToInstantApps,
[C-0-3] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami, chyba że komponent jest widoczny dla aplikacji błyskawicznych za pomocą android:visibleToInstantApps.
[C-0-4] Zainstalowane aplikacje NIE MOGĄ widzieć szczegółów aplikacji błyskawicznych na urządzeniu, chyba że aplikacja błyskawiczna wyraźnie połączy się z zainstalowaną aplikacją.

Jeśli implementacje urządzeń obsługują aplikacje błyskawiczne, to:

[C-1-1] Musisz udostępnić użytkownikom te możliwości interakcji z aplikacją błyskawiczną: AOSP spełnia wymagania dzięki domyślnemu interfejsowi systemu, ustawieniom i wywoływaczowi.
[C-1-2] NALEŻY zapewnić użytkownikowi możliwość wyświetlania i usuwania aplikacji błyskawicznych zapisanych lokalnie w pamięci podręcznej w przypadku każdego pojedynczego pakietu aplikacji.
[C-1-3] Musisz wyświetlać użytkownikowi stałe powiadomienie, które można zwinąć, gdy aplikacja błyskawiczna działa na pierwszym planie. Powiadomienie musi zawierać informację, że aplikacje błyskawiczne nie wymagają instalacji, oraz opcję przekierowania użytkownika do ekranu z informacjami o aplikacji w Ustawieniach. W przypadku aplikacji natychmiastowych uruchamianych za pomocą intencji internetowych, zdefiniowanych przez użycie intencji z działaniem ustawionym na Intent.ACTION_VIEW i schematem „http” lub „https”, dodatkowe opcje interfejsu użytkownika POWINNY umożliwiać użytkownikowi nie tylko uruchomienie aplikacji natychmiastowej, ale też uruchomienie powiązanego linku w skonfigurowanej przeglądarce internetowej, jeśli jest ona dostępna na urządzeniu.
[C-1-4] NALEŻY zezwolić na dostęp do uruchomionych aplikacji błyskawicznych z funkcji Ostatnie, jeśli jest ona dostępna na urządzeniu.
[C-1-5] NALEŻY wstępnie załadować co najmniej 1 aplikację lub co najmniej 1 element usługi z obsługą intencji wymienionych w pakiecie SDK i uczynić te intencje widoczne dla aplikacji błyskawicznych.

3.16. Parowanie urządzenia towarzyszącego

Android obsługuje parowanie urządzeń towarzyszących, aby umożliwić skuteczniejsze zarządzanie powiązaniem z urządzeniami towarzyszącymi. Udostępnia też interfejs API CompanionDeviceManager, który pozwala aplikacjom korzystać z tej funkcji.

Jeśli implementacje urządzeń obsługują funkcję parowania urządzenia towarzyszącego:

[C-1-1] NALEŻY zadeklarować flagę funkcji FEATURE_COMPANION_DEVICE_SETUP .
[C-1-2] Musisz mieć pewność, że interfejsy API w pakiecie android.companion są w pełni zaimplementowane.
[C-1-3] NALEŻY zapewnić użytkownikowi możliwość wybrania/potwierdzenia, że urządzenie towarzyszące jest obecne i działa.

3.17. Aplikacje o dużej pojemności

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

[C-1-1] W systemie może być uruchomiona tylko 1 aplikacja, która określa cantSaveState. Jeśli użytkownik opuści taką aplikację bez jej zamykania (np. przez naciśnięcie przycisku Home podczas korzystania z aktywnej czynności w systemie zamiast naciśnięcia przycisku Wstecz, gdy w systemie nie ma żadnych pozostałych aktywnych czynności), implementacje urządzeń MUSZĄ nadać priorytet tej aplikacji w pamięci RAM, tak jak w przypadku innych elementów, które mają pozostać uruchomione, takich jak usługi na pierwszym planie. Gdy taka aplikacja działa w tle, system może nadal stosować w niej funkcje zarządzania energią, takie jak ograniczanie dostępu do procesora i do sieci.
[C-1-2] Musisz zapewnić w interfejsie możliwość wybrania aplikacji, która nie będzie korzystać z normalnego mechanizmu zapisywania/przywracania stanu, gdy użytkownik uruchomi drugą aplikację zadeklarowaną za pomocą atrybutu cantSaveState.
[C-1-3] DO aplikacji, które określają cantSaveState, NIE MOŻNA stosować innych zmian w zasadach, takich jak zmiana wydajności procesora lub zmiana priorytetów harmonogramu.

Jeśli implementacje na urządzeniu nie deklarują funkcji FEATURE_CANT_SAVE_STATE, to:

[C-1-1] Musisz zignorować atrybut cantSaveState ustawiony przez aplikacje i nie możesz zmienić zachowania aplikacji na podstawie tego atrybutu.

3.18. kontakty,

Android zawiera interfejsy API Contacts Provider, które umożliwiają aplikacjom zarządzanie informacjami o kontaktach zapisanymi na urządzeniu. Dane kontaktów wprowadzane bezpośrednio na urządzeniu są zwykle synchronizowane z usługą internetową, ale mogą też znajdować się tylko lokalnie na urządzeniu. Kontakty, które są przechowywane tylko na urządzeniu, są nazywane kontaktami lokalnymi.

Kontakty nieprzetworzone są „powiązane z” lub „zmagazynowane na” koncie, gdy kolumny ACCOUNT_NAME i ACCOUNT_TYPE kontaktów nieprzetworzonych pasują do odpowiednich pól Account.name i Account.type na koncie.

Domyślne konto lokalne: konto dla nieprzetworzonych kontaktów, które są przechowywane tylko na urządzeniu i nie są powiązane z kontem w AccountManager. Kontakty te są tworzone z wartościami null w kolumnach ACCOUNT_NAME i ACCOUNT_TYPE.

Niestandardowe konto lokalne: konto zawierające nieprzetworzone kontakty, które są przechowywane tylko na urządzeniu i nie są powiązane z kontem w usługach menedżera. Są one tworzone z co najmniej jedną wartością inną niż null w kolumnach ACCOUNT_NAME i ACCOUNT_TYPE.

Implementacje na urządzeniu:

[C-SR] MOCNO ZALECAMY, aby nie tworzyć niestandardowych kont lokalnych.

Jeśli implementacje urządzeń korzystają z niestandardowego konta lokalnego:

[C-1-1] Zmienna ACCOUNT_NAME na koncie lokalnym niestandardowym MUSI być zwrócona przez ContactsContract.RawContacts.getLocalAccountName
[C-1-2] Wartość ACCOUNT_TYPE na niestandardowym koncie lokalnym MUSI zostać zwrócona w ramach ContactsContract.RawContacts.getLocalAccountType
[C-1-3] Dane kontaktów wstawiane przez aplikacje innych firm z domyślnym kontem lokalnym (czyli z wartościami pustymi dla pól ACCOUNT_NAME i ACCOUNT_TYPE) MUSZĄ być wstawiane na koncie lokalnym użytkownika.
[C-1-4] Kontakty w postaci danych wejściowych wstawiane na niestandardowym koncie lokalnym NIE MOGĄ zostać usunięte podczas dodawania lub usuwania kont.
[C-1-5] Operacje usuwania wykonywane na niestandardowym koncie lokalnym MUSZĄ powodować natychmiastowe usunięcie nieprzetworzonych kontaktów (tak jakby parametr CALLER_IS_SYNCADAPTER był ustawiony na wartość true), nawet jeśli parametr CALLER\_IS\_SYNCADAPTER został ustawiony na wartość false lub nie został określony.

4. Zgodność z pakietem aplikacji

Implementacje na urządzeniach:

[C-0-1] Aplikacja MUSI umożliwiać instalowanie i uruchamianie plików „.apk” na Androida wygenerowanych przez narzędzie „aapt” zawarte w oficjalnym pakiecie Android SDK.
Powyższe wymaganie może być trudne do spełnienia, dlatego zalecamy używanie systemu zarządzania pakietami w implementacji referencyjnej AOSP.

Implementacje na urządzeniu:

[C-0-2] MUSI obsługiwać weryfikację plików „.apk” przy użyciu schematu podpisywania plików APK w wersji 3 , schematu podpisywania plików APK w wersji 2 i podpisywania plików JAR.
[C-0-3] NIE MOŻESZ rozszerzać formatów .apk, Android Manifest, Dalvik bytecode ani RenderScript bytecode w sposób uniemożliwiający ich prawidłowe instalowanie i uruchamianie na innych zgodnych urządzeniach.
[C-0-4] NIE wolno zezwalać aplikacjom innym niż bieżący „instalator” pakietu na automatyczne odinstalowanie aplikacji bez potwierdzenia przez użytkownika, zgodnie z dokumentacją SDK dla uprawnienia DELETE_PACKAGE. Jedynymi wyjątkami są aplikacja weryfikująca pakiet systemowy, która obsługuje intencję PACKAGE_NEEDS_VERIFICATION, oraz aplikacja menedżera pamięci, która obsługuje intencję ACTION_MANAGE_STORAGE.
[C-0-5] Musisz mieć aktywność, która obsługuje intencję android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] NIE WOLNO instalować pakietów aplikacji z nieznanych źródeł, chyba że aplikacja, która prosi o instalację, spełnia wszystkie te wymagania:
- Musisz zadeklarować uprawnienie REQUEST_INSTALL_PACKAGES lub ustawić wartość android:targetSdkVersion na 24 lub niższą.
- Użytkownik musi zezwolić na instalowanie aplikacji z nieznanych źródeł.
NALEŻY umożliwić użytkownikowi udzielenie/wycofanie uprawnienia do instalowania aplikacji z nieznanych źródeł w przypadku każdej aplikacji, ale MOŻNA zaimplementować to jako no-op i zwrócić RESULT_CANCELED dla startActivityForResult(), jeśli implementacja urządzenia nie chce udostępniać użytkownikom tej opcji. Nawet w takich przypadkach należy jednak poinformować użytkownika, dlaczego nie ma takiej opcji.
[C-0-7] MUSI wyświetlać użytkownikowi okno z ostrzeżeniem zawierającym ciąg znaków ostrzeżenia udostępniany przez interfejs API systemu PackageManager.setHarmfulAppWarning przed uruchomieniem w aplikacji aktywności oznaczonej przez ten sam interfejs API PackageManager.setHarmfulAppWarning jako potencjalnie szkodliwej.
NALEŻY umożliwić użytkownikowi odinstalowanie lub uruchomienie aplikacji w oknie z ostrzeżeniem.
[C-0-8] NALEŻY wdrożyć obsługę systemu plików Incremental File System zgodnie z opisem tutaj.
[C-0-9] MUSI obsługiwać weryfikację plików .apk przy użyciu schematu podpisu plików APK w wersji 4.
Jeśli implementacje urządzeń zostały już uruchomione w starszej wersji Androida i nie spełniają wymagań [C-0-8] i [C-0-9] w ramach aktualizacji oprogramowania systemowego, MOGĄ być zwolnione z tych wymagań.

5. Zgodność multimedialna

Implementacje na urządzeniu:

[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 z kodeków zadeklarowanych przez MediaCodecList.
[C-0-2] NALEŻY zadeklarować i zgłosić obsługę koderów i dekoderów dostępnych dla aplikacji 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 bitowe generowane przez jego kodery oraz profile raportowane w CamcorderProfile.

Implementacje na urządzeniu:

NALEŻY dążyć do minimalnego opóźnienia kodeka, innymi słowy:
- NIE POWINNA zużywać ani przechowywać buforów wejściowych i zwracać buforów wejściowych tylko po przetworzeniu.
- NIE NALEŻY przechowywać odkodowanych buforów dłużej niż określono w standardzie (np. SPS).
- NIE POWINIEN przechowywać zakodowanych buforów dłużej niż wymaga tego struktura GOP.

Wszystkie kodeki wymienione w sekcji poniżej są dostępne 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 są wolne od patentów innych firm. Osoby, które chcą używać tego kodu źródłowego w urządzeniach lub produktach programowych, powinny wiedzieć, że implementacje tego kodu, w tym w oprogramowaniu open source lub shareware, mogą wymagać licencji na patenty od odpowiednich właścicieli patentów.

5.1. Kodeki multimedialne

5.1.1. Kodowanie dźwięku

Więcej informacji znajdziesz w sekcji 5.1.3. Szczegóły kodeków audio.

Jeśli implementacje urządzeń deklarują android.hardware.microphone, MUSZĄ obsługiwać kodowanie tych formatów audio i udostępniać je aplikacjom innych firm:

[C-1-1] PCM/WAVE
[C-1-2] FLAC
[C-1-3] Opus

Wszystkie kodery audio MUSZĄ obsługiwać:

[C-3-1] Ramki audio w formacie PCM 16-bitowym 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 na urządzeniach 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] MPEG-4 HE AACv2 Profile (ulepszona wersja AAC+)
[C-1-4] AAC ELD (ulepszona jakość dźwięku AAC z małym opóźnieniem)
[C-1-11] xHE-AAC (rozszerzony profil HE AAC ISO/IEC 23003-3, który obejmuje podstawowy profil USAC i profil ISO/IEC 23003-4 z kontrolą zakresu dynamiki)
[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 ten wymóg dotyczy tylko dekodowania. Podczas odtwarzania urządzenie może zmniejszyć próbkowanie i poziom dźwięku.
[C-1-10] Opus

Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC strumieni wielokanałowych (czyli więcej niż 2 kanałów) na PCM za pomocą domyślnego dekodera audio AAC w interfejsie API android.media.MediaCodec, MUSI być obsługiwane:

[C-2-1] Dekodowanie MUSI być wykonane bez downmixowania (np. strumień AAC 5.0 musi zostać zdekodowany do 5 kanałów PCM, a strumień AAC 5.1 musi zostać zdekodowany do 6 kanałów PCM).
[C-2-2] Metadane zakresu dynamicznego MUSZĄ być zdefiniowane zgodnie z „Dynamic Range Control (DRC)” w normie ISO/IEC 14496-3 oraz kluczami DRC android.media.MediaFormat, aby skonfigurować zachowanie dekodera audio związane z zakresem dynamicznym. Klucze AAC DRC zostały wprowadzone w interfejsie API 21. 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.
[SR] Zdecydowanie zalecamy, aby wszystkie dekodery audio AAC spełniały wymagania C-2-1 i C-2-2 opisane powyżej.

Podczas dekodowania dźwięku USAC w MPEG-D (ISO/IEC 23003-4):

[C-3-1] Metadane dotyczące głośności i DRC muszą być interpretowane i stosowane zgodnie z profilem MPEG-D DRC (Dynamic Range Control) poziomu 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 MPEG-4 AAC, HE AAC i HE AACv2:

MOŻE obsługiwać głośność i kontrolę zakresu dynamicznego za pomocą profilu ISO/IEC 23003-4.

Jeśli obsługiwana jest norma ISO/IEC 23003-4 i w dekodowanym strumieniu bitów są obecne metadane ISO/IEC 23003-4 oraz ISO/IEC 14496-3, to:

W przypadku kolizji mają pierwszeństwo metadane ISO/IEC 23003-4.

Wszystkie dekodery audio MUSZĄ obsługiwać te formaty wyjściowe:

[C-6-1] Ramki audio w formacie PCM 16-bitowym w natywnej kolejności bajtów za pomocą interfejsu API android.media.MediaCodec.

5.1.3. Szczegóły kodeków audio

Format/kodek	Szczegóły	Typy plików/formaty kontenerów, które mają być obsługiwane
MPEG-4 AAC Profile (AAC LC)	Obsługa treści mono/stereo/5.0/5.1 ze standardową częstotliwością próbkowania od 8 do 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, ADIF nieobsługiwany) MPEG-TS (.ts, bez możliwości przeskakiwania, tylko dekodowanie) Matroska (.mkv, tylko dekodowanie)
MPEG-4 HE AAC Profile (AAC+)	Obsługa treści mono, stereo, 5.0 i 5.1 ze standardową częstotliwością próbkowania od 16 do 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profil (ulepszona wersja AAC+)	Obsługa treści mono, stereo, 5.0 i 5.1 ze standardową częstotliwością próbkowania od 16 do 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (ulepszona wersja AAC o niskim opóźnieniu)	Obsługa treści mono lub stereo ze standardową częstotliwością próbkowania od 16 do 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Obsługa treści mono lub stereo ze standardową częstotliwością próbkowania od 7,35 do 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz	3GPP (.3gp)
AMR-WB	9 szybkości od 6,60 kbit/s do 23,85 kbit/s z próbkowaniem 16 kHz, zgodnie z definicją w AMR-WB, Adaptive Multi-Rate – kodek mowy szerokopasmowej	3GPP (.3gp)
FLAC	Zarówno w przypadku kodera, jak i dekodera: MUSZĄ być obsługiwane co najmniej tryby Mono i Stereo. NALEŻY obsługiwać częstotliwości próbkowania do 192 kHz; NALEŻY obsługiwać rozdzielczość 16- i 24-bitową. Obsługa danych audio FLAC 24-bitowych MUSI być dostępna z konfiguracją audio o zmiennoprzecinkowej dokładności.	FLAC (.flac) MPEG-4 (.mp4, .m4a, tylko dekodowanie) Matroska (.mkv, tylko dekodowanie)
MP3	Mono/stereo 8–320 kb/s stała (CBR) lub zmienna szybkość transmisji (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, tylko dekodowanie) Matroska (.mkv, tylko dekodowanie)
MIDI	Typ MIDI 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody	Typ 0 i 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis		Ogg (.ogg) MPEG-4 (.mp4, .m4a, tylko dekodowanie) Matroska (.mkv) WebM (.webm)
PCM/WAVE	Kodek PCM MUSI obsługiwać 16-bitowy linearny PCM i 16-bitowy format zmiennoprzecinkowy. Wyodrębniacz WAVE musi obsługiwać 16-bitowy, 24-bitowy, 32-bitowy liniowy PCM i 32-bitowy zmiennoprzecinkowy (szybkość do limitu sprzętowego). Częstotliwości próbkowania MUSZĄ być obsługiwane w zakresie od 8 kHz do 192 kHz.	WAVE (.wav)
Opus	Dekodowanie: obsługa treści mono, stereo, 5.0 i 5.1 z częstotliwością próbkowania 8000, 12000, 16000, 24000 i 48000 Hz. Kodowanie: obsługa treści mono i stereo z częstotliwością próbkowania 8000, 12000, 16000, 24000 i 48000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, tylko dekodowanie) Matroska (.mkv) WebM (.webm)

5.1.4. Kodowanie obrazu

Więcej informacji znajdziesz w sekcji 5.1.6. Szczegóły kodeków obrazu.

Implementacje urządzeń MUSZĄ obsługiwać kodowanie tych typów obrazów:

[C-0-1] JPEG
[C-0-2] PNG
[C-0-3] WebP

Jeśli implementacje urządzeń obsługują kodowanie HEIC za pomocą android.media.MediaCodec dla typu multimediów MIMETYPE_IMAGE_ANDROID_HEIC, to:

[C-1-1] NALEŻY dostarczyć koder HEVC z akceleracją sprzętową, który obsługuje tryb kontroli szybkości transmisji bitów BITRATE_MODE_CQ, profil HEVCProfileMainStill i rozmiar ramki 512 × 512 pikseli.

5.1.5. Dekodowanie obrazu

Więcej informacji znajdziesz w sekcji 5.1.6. Szczegóły kodeków obrazu.

Implementacje urządzeń MUSZĄ obsługiwać dekodowanie tych formatów kodowania obrazów:

[C-0-1] JPEG
[C-0-2] GIF
[C-0-3] PNG
[C-0-4] BMP
[C-0-5] WebP
[C-0-6] Nieprzetworzone

Jeśli implementacje urządzeń obsługują dekodowanie wideo HEVC, muszą: * [C-1-1] MUSI obsługiwać dekodowanie obrazu HEIF (HEVC).

Dekodery obrazu obsługujące format o wysokiej głębi bitów (co najmniej 9 bitów na kanał):

[C-2-1] MUSI obsługiwać format wyjściowy 8-bitowy, jeśli aplikacja tego zażąda, na przykład za pomocą konfiguracji ARGB_8888 w android.graphics.Bitmap.

5.1.6. Szczegóły kodeków obrazów

Format/kodek	Szczegóły	Obsługiwane typy plików i formaty kontenerów
JPEG	Podstawowe + progresywne	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)

kodery i dekodery obrazów udostępnione za pomocą interfejsu MediaCodec API;

[C-1-1] Musi obsługiwać elastyczny format kolorów YUV420 8:8:8 (COLOR_FormatYUV420Flexible) za pomocą CodecCapabilities.
[SR] ZALECAMY obsługę formatu kolorów RGB888 w trybie powierzchni.
[C-1-3] Musi obsługiwać co najmniej jeden z formatów planarnych lub półpłaskich YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (równoważny COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (równoważny COLOR_FormatYUV420SemiPlanar). Zdecydowanie zalecamy obsługę obu formatów.

5.1.7. Kodeki wideo

Aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo i usług wideokonferencji, implementacje urządzeń POWINNY używać kodeka VP8 na poziomie sprzętowym, który spełnia wymagania.

Jeśli implementacje na urządzeniu obejmują dekoder lub koder wideo:

[C-1-1] Kodeki wideo MUSZĄ obsługiwać rozmiary buforów bajtów wejścia i wyjścia, które umożliwiają wyświetlanie największej możliwej ramki skompresowanej i nieskompresowanej zgodnie ze standardem i konfiguracją, ale też nie mogą przydzielać zbyt dużo zasobów.
[C-1-2] Kodery i dekodery wideo MUSZĄ obsługiwać elastyczne formaty kolorów YUV420 8:8:8 (COLOR_FormatYUV420Flexible) za pomocą CodecCapabilities.
[C-1-3] Kodery i dekodery wideo MUSZĄ obsługiwać co najmniej jeden z formatów kolorów planarnych lub półpłaskich YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (równoważny COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (równoważny COLOR_FormatYUV420SemiPlanar). Zdecydowanie zalecamy obsługę obu formatów.
[SR] Silnie zaleca się, aby kodery i dekodery wideo obsługiwały co najmniej jeden z formatów kolorów płaskich lub półpłaskich YUV420 8:8:8 zoptymalizowanych sprzętowo (YV12, NV12, NV21 lub równoważny format zoptymalizowany przez producenta).
[C-1-5] Dekodery wideo obsługujące format o dużej głębi bitów (co najmniej 9 bitów na kanał) MUSZĄ obsługiwać format 8-bitowy, jeśli aplikacja tego zażąda. Musi to być odzwierciedlone przez obsługę 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, muszą:

[C-2-1] MUSI obsługiwać analizowanie i przetwarzanie statycznych metadanych HDR.

Jeśli implementacje urządzeń reklamują obsługę odświeżania w ramach FEATURE_IntraRefresh w klasie MediaCodecInfo.CodecCapabilities, to:

[C-3-1] MUSI obsługiwać okresy odświeżania w zakresie 10–60 ramek i działać prawidłowo w granicach 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] NALEŻY ustawić domyślnie format kolorów zoptymalizowany pod kątem wyświetlacza sprzętowego, jeśli jest on skonfigurowany za pomocą wyjścia Surface.
[C-4-2] NALEŻY ustawić domyślnie format kolorów YUV420 8:8:8 zoptymalizowany pod kątem odczytu przez procesor, jeśli nie ma być używane wyjście Surface.

5.1.8. Lista kodeków wideo

Format/kodek	Szczegóły	Typy plików/formaty kontenerów, które mają być obsługiwane
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)
H.264 AVC	Więcej informacji znajdziesz w sekcji 5.2 i 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, bez możliwości przesuwania) Matroska (.mkv, tylko dekodowanie)
H.265 HEVC	Więcej informacji znajdziesz w sekcji 5.3.	MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)
MPEG-2	Profil główny	MPEG2-TS (.ts, nie można przesuwać do żądanego miejsca) MPEG-4 (.mp4, tylko dekodowanie) Matroska (.mkv, tylko dekodowanie)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)
VP8	Więcej informacji znajdziesz w sekcji 5.2 i 5.3.	WebM (.webm) Matroska (.mkv)
VP9	Więcej informacji znajdziesz w sekcji 5.3.	WebM (.webm) Matroska (.mkv)

5.1.9. Zabezpieczenia kodeka multimediów

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń kodeków multimedialnych opisanymi poniżej.

Android obsługuje OMX, interfejs API do akceleracji multimediów na różnych platformach, a także Codec 2.0, interfejs API do akceleracji multimediów o małym obciążeniu.

Jeśli implementacje urządzeń obsługują multimedia, mogą:

[C-1-1] MUSI obsługiwać kodeki multimedialne za pomocą interfejsów OMX lub Codec 2.0 (lub obu), tak jak w projekcie Android Open Source, oraz nie może wyłączać ani obchodzić zabezpieczeń. Nie oznacza to, że każdy kodek MUSI używać interfejsu OMX lub Codec 2.0, tylko że MUSI być dostępna obsługa co najmniej jednego z tych interfejsów API, a ta obsługa MUSI obejmować zabezpieczenia.
[C-SR] MOCNO ZALECAMY uwzględnienie obsługi interfejsu Codec 2.0 API.

Jeśli implementacje urządzeń nie obsługują interfejsu Codec 2.0 API:

[C-2-1] W przypadku każdego formatu i typu multimediów (kodowania lub dekodowania) obsługiwanego przez urządzenie MUSISZ uwzględnić odpowiedni kodek oprogramowania OMX z projektu Android Open Source (jeśli jest dostępny).
[C-2-2] Kodeki, których nazwy zaczynają się od „OMX.google.” MUSI być oparty na kodzie źródłowym Projektu Android Open Source.
[C-SR] Zalecamy MOCNO, aby kodeki oprogramowania OMX działały w procesie kodeka, który nie ma dostępu do sterowników sprzętowych innych niż mapery pamięci.

Jeśli implementacje na urządzeniu obsługują interfejs Codec 2.0 API, to:

[C-3-1] W przypadku każdego formatu i typu multimediów (koderek lub dekoder) obsługiwanego przez urządzenie należy DODAWAĆ odpowiedni kodek oprogramowania Codec 2.0 z projektu Android Open Source (jeśli jest dostępny).
[C-3-2] MUST house the Codec 2.0 software codecs in the software codec process as provided in the Android Open Source Project to make it possible to more narrowly grant access to software codecs.
[C-3-3] Kodeki, których nazwy zaczynają się od „c2.android. MUSI być oparty na kodzie źródłowym Projektu Android Open Source.

5.1.10. Charakterystyka kodeka multimediów

Jeśli implementacje urządzeń obsługują kodeki multimedialne, to:

[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 o nazwach zaczynających się od „OMX”. MUSI używać interfejsów API OMX i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa OMX IL.
[C-1-3] Kodeki o nazwach zaczynających się od „c2”. MUSI używać interfejsu Codec 2.0 API i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa w przypadku Codec 2.0 na Androida.
[C-1-4] Kodeki o nazwach zaczynających się od „OMX.google.” lub „c2.android.” NIE MOŻE być opisany jako pochodzący od konkretnego dostawcy lub przyspieszony przez sprzęt.
[C-1-5] Kodeki, które działają w procesie kodeka (dostawcy lub systemu) i mają dostęp do sterowników sprzętowych innych niż przydzielacze i mapery pamięci, NIE MOGĄ być opisane jako oprogramowanie.
[C-1-6] Kodek, który nie jest dostępny w projekcie Android Open Source lub nie jest oparty na kodzie źródłowym w tym projekcie, MUSI być określony jako pochodzący od dostawcy.
[C-1-7] Kodeki, które korzystają z akceleracji sprzętowej, MUSZĄ być opisane jako korzystające z akceleracji sprzętowej.
[C-1-8] Nazwy kodeków NIE MOGĄ wprowadzać w błąd. Na przykład kodeki o nazwie „decoders” MUSZĄ obsługiwać dekodowanie, a kodeki o nazwie „encoders” MUSZĄ obsługiwać kodowanie. Kodeki o nazwach zawierających formaty multimediów MUSZĄ obsługiwać te formaty.

Jeśli implementacje na urządzeniu obsługują kodeki wideo:

[C-2-1] Wszystkie kodeki wideo MUSZĄ publikować dane dotyczące osiągalnej liczby klatek na sekundę w przypadku tych rozmiarów, jeśli są obsługiwane przez dany 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 (koder 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 pikseli (inne)	1408 x 1152 pikseli (H263) 1280 x 720 pikseli (inne)	1920 x 1080 pikseli (inne niż MPEG4)	3840 x 2160 pikseli (HEVC, VP9)

[C-2-2] Kodek wideo, który jest przyspieszony sprzętowo, MUSI publikować informacje o punktach wydajności. Muszą one zawierać wszystkie obsługiwane standardowe punkty danych o wydajności (wymienione w interfejsie API PerformancePoint), chyba że są one objęte innym obsługiwanym standardowym punktem danych.
Dodatkowo powinni opublikować rozszerzone punkty dotyczące skuteczności, jeśli obsługują trwałą skuteczność filmu inną niż standardowa wymieniona powyżej.

5.2. Kodowanie wideo

Jeśli implementacje urządzeń obsługują dowolny koder wideo i udostępniają go aplikacjom innych firm, muszą:

W 2 przesuwających się oknach nie powinien przekraczać o więcej niż 15% przepływności danych między interwałami klatek wewnątrzramkowych (I-frame).
NIE POWINNA przekraczać 100% szybkości transmisji danych w przesuwalnym oknie 1 sekundy.

Jeśli implementacje urządzeń zawierają wbudowany wyświetlacz o przekątnej co najmniej 6,35 cm lub mają port wyjścia wideo albo deklarują obsługę aparatu za pomocą flagi funkcji android.hardware.camera.any, muszą:

[C-1-1] Musisz uwzględnić obsługę co najmniej jednego z enkoderów wideo VP8 lub H.264 i udostępnić ją aplikacjom innych firm.
NALEŻY obsługiwać kodery wideo VP8 i H.264 oraz udostępniać je aplikacjom innych firm.

Jeśli implementacje urządzeń obsługują dowolny z enkoderów wideo H.264, VP8, VP9 lub HEVC i udostępniają je aplikacjom innych firm, muszą:

[C-2-1] Musi obsługiwać dynamicznie konfigurowalne szybkości transmisji danych.
NALEŻY obsługiwać zmienne liczby klatek, przy czym koder wideo NALEŻY określać chwilowy czas trwania klatki na podstawie sygnałów czasowych buforów wejściowych i przydzielać mu zasobnik bitów na podstawie tego czasu trwania.

Jeśli implementacje urządzeń obsługują koder wideo MPEG-4 SP i udostępniają go aplikacjom innych firm, mogą:

Powinien obsługiwać dynamicznie konfigurowalne bitrate’y dla obsługiwanego kodera.

Jeśli implementacje urządzeń zapewniają kodery wideo lub obrazów z przyspieszeniem sprzętowym i obsługują co najmniej 1 dołączoną lub podłączaną kamerę sprzętową udostępnioną przez interfejsy API android.camera:

[C-4-1] Wszystkie kodery wideo i obrazu z przyspieszeniem sprzętowym MUSZĄ obsługiwać kodowanie klatek z kamery sprzętowej.
NALEŻY obsługiwać kodowanie klatek z kamer sprzętowych za pomocą wszystkich koderów wideo lub obrazu.

5.2.1. H.263

Jeśli implementacje urządzeń obsługują kodery H.263 i udostępniają je aplikacjom innych firm, mogą:

[C-1-1] Musi obsługiwać profil podstawowy na poziomie 45.
Powinien obsługiwać dynamicznie konfigurowalne bitrate’y dla obsługiwanego kodera.

5.2.2. H.264

Jeśli implementacje urządzeń obsługują kodek H.264, to:

[C-1-1] Musi obsługiwać profil podstawowy poziomu 3. Obsługa ASO (dowolne sortowanie segmentów), FMO (elastyczne sortowanie makrobloków) i RS (nadmiarowe segmenty) jest jednak opcjonalna. Ponadto w celu zachowania zgodności z innymi urządzeniami z Androidem zalecamy, aby kodery nie używały funkcji ASO, FMO ani RS w przypadku profilu podstawowego.
[C-1-2] MUSI obsługiwać profile kodowania wideo SD (standardowa rozdzielczość) podane w tabeli poniżej.
Powinien obsługiwać poziom 4 profilu głównego.
Powinien obsługiwać profile kodowania filmów HD (High Definition) zgodnie z tabelą poniżej.

Jeśli implementacje urządzeń zgłaszają obsługę kodowania H.264 dla filmów w rozdzielczości 720p lub 1080p za pomocą interfejsów API multimediów, to:

[C-2-1] MUSI obsługiwać profile kodowania podane w tabeli poniżej.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 240 pikseli	720 x 480 piks.	1280 x 720 pikseli	1920 x 1080 piks.
liczba klatek na sekundę,	20 kl./s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	384 kbps	2 Mb/s	4 Mb/s	10 Mb/s

5.2.3. VP8

Jeśli implementacje urządzeń obsługują kodek VP8, to:

[C-1-1] MUSI obsługiwać profile kodowania SD.
NALEŻY obsługiwać te profile kodowania filmów w wysokiej rozdzielczości (HD).
[C-1-2] MUSI obsługiwać zapisywanie plików Matroska WebM.
NALEŻY zapewnić sprzętowy kodek VP8, który spełnia wymagania dotyczące kodowania sprzętowego RTC projektu WebM, aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo i usług wideokonferencji.

Jeśli implementacje urządzeń zgłaszają obsługę kodowania VP8 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 podane 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 piks.
liczba klatek na sekundę,	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, to:

[C-1-2] Musi obsługiwać profil 0 na poziomie 3.
[C-1-1] MUSI obsługiwać zapisywanie plików WebM w formacie Matroska.
[C-1-3] MUSI generować dane CodecPrivate.
NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
[SR] MOCNO ZALECAMY obsługę profili dekodowania HD, jak wskazano w tabeli poniżej, jeśli istnieje koder sprzętowy.

	SD	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	720 x 480 piks.	1280 x 720 pikseli	1920 x 1080 piks.	3840 x 2160 pikseli
liczba klatek na sekundę,	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 na urządzeniu twierdzą, że obsługują profil 2 lub profil 3 za pomocą interfejsów Media API:

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.
POWINNY obsługiwać profile kodowania HD zgodnie z tabelą poniżej.
[SR] MOCNO zalecamy obsługę profili kodowania HD, jak wskazano w tabeli poniżej, jeśli istnieje koder sprzętowy.

	SD	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	720 x 480 piks.	1280 x 720 pikseli	1920 x 1080 piks.	3840 x 2160 pikseli
liczba klatek na sekundę,	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.3. Dekodowanie wideo

Jeśli implementacje urządzeń obsługują kodeki VP8, VP9, H.264 lub H.265, to:

[C-1-1] MUSI obsługiwać dynamiczne przełączanie rozdzielczości wideo i szybkości klatek za pomocą standardowych interfejsów API Androida w ramach tego samego strumienia dla wszystkich kodeków VP8, VP9, H.264 i H.265 w czasie rzeczywistym oraz do maksymalnej rozdzielczości obsługiwanej przez każdy z kodeków na urządzeniu.

5.3.1. MPEG-2

Jeśli implementacje urządzeń obsługują dekodery MPEG-2, to:

[C-1-1] Musi obsługiwać profil główny na wysokim poziomie.

5.3.2. H.263

Jeśli implementacje urządzeń obsługują dekodery H.263, to:

[C-1-1] Musi obsługiwać poziom profilu podstawowego 30 i 45.

5.3.3. MPEG-4

W przypadku implementacji dekoderów MPEG-4 na urządzeniach:

[C-1-1] Musi obsługiwać profil prosty poziomu 3.

5.3.4. H.264

Jeśli implementacje urządzeń obsługują dekodery H.264, mogą:

[C-1-1] Musi obsługiwać profil główny na poziomie 3.1 i profil podstawowy. Obsługa ASO (dowolne sortowanie segmentów), FMO (elastyczne sortowanie makrobloków) i RS (niepotrzebne segmenty) jest OPCJONALNA.
[C-1-2] MUSI być w stanie dekodować filmy z profilami SD (standardowej rozdzielczości) wymienionymi w poniższej tabeli i zakodowanymi za pomocą profilu podstawowego i profilu głównego poziomu 3.1 (w tym 720p30).
POWINIEN być w stanie dekodować filmy z profilami HD (High Definition) zgodnie z tabelą poniżej.

Jeśli wysokość zwracana przez metodę Display.getSupportedModes() jest równa lub większa niż rozdzielczość filmu, implementacje urządzeń:

[C-2-1] Musi obsługiwać profile dekodowania wideo HD 720p podane w tabeli poniżej.
[C-2-2] MUSI obsługiwać profile dekodowania wideo HD 1080p podane w tabeli poniżej.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 240 pikseli	720 x 480 piks.	1280 x 720 pikseli	1920 x 1080 piks.
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	60 kl./s	30 kl./s (60 kl./s^telewizor)
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ć poziom główny profilu głównego na poziomie 3 oraz profile dekodowania wideo SD zgodnie z tabelą poniżej.
NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
[C-1-2] W przypadku dekodera sprzętowego MUSI obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.

Jeśli wysokość zwrócona przez metodę Display.getSupportedModes() jest równa lub większa niż rozdzielczość filmu, wtedy:

[C-2-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 z 2 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 piks.	1280 x 720 pikseli	1920 x 1080 piks.	3840 x 2160 pikseli
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 klatek/s	30/60 fps (60 fps ^{telewizor 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ń twierdzą, że obsługują profil HDR za pomocą interfejsów Media API:

[C-3-1] Implementacje urządzeń MUSZĄ akceptować wymagane metadane HDR z aplikacji, a także obsługiwać wyodrębnianie i wyprowadzanie wymaganych metadanych HDR z bitowego strumienia danych lub kontenera.
[C-3-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).

5.3.6. VP8

Jeśli implementacje urządzeń obsługują kodek VP8, to:

[C-1-1] MUSI obsługiwać profile dekodowania SD podane w tabeli poniżej.
NALEŻY użyć sprzętowego kodeka VP8, który spełnia wymagania.
NALEŻY obsługiwać profile dekodowania HD podane w tabeli poniżej.

Jeśli wysokość podana przez metodę Display.getSupportedModes() jest równa rozdzielczości filmu lub większa:

[C-2-1] Implementacje urządzeń MUSZĄ obsługiwać profile 720p wymienione w tabeli poniżej.
[C-2-2] Implementacje urządzeń MUSZĄ obsługiwać profile 1080p wymienione w poniższej tabeli.

	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 piks.
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 kl./s (60 kl./s^telewizor)	30 (60 fps, ^telewizor)
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, to:

[C-1-1] MUSI obsługiwać profile dekodowania filmów SD zgodnie z tabelą poniżej.
NALEŻY 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 zgodnie z tabelą poniżej.

Jeśli wysokość zwrócona przez metodę Display.getSupportedModes() jest równa lub większa niż rozdzielczość filmu, wtedy:

[C-3-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 z 2 formatów: VP9 lub H.265 w przypadku profili 720, 1080 i UHD.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 piks.	3840 x 2160 pikseli
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 klatek/s	30 kl./s (60 kl./s ^{telewizor z dekodowaniem sprzętowym 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ń twierdzą, że obsługują VP9Profile2 lub VP9Profile3 za pomocą interfejsów API mediów CodecProfileLevel:

Obsługa formatu 12-bitowego jest OPCJONALNA.

Jeśli implementacje urządzeń twierdzą, że obsługują profil 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 w przypadku wszystkich profili HDR oraz 'KEY_HDR10_PLUS_INFO' w przypadku profili HDR10Plus) z aplikacji. Muszą też obsługiwać wyodrębnianie i wyprowadzanie wymaganych metadanych HDR z bitowego strumienia danych lub kontenera.
[C-4-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR na ekranie urządzenia lub na standardowym wyjściu 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] MUSISZ podać narzędzie do wyodrębniania obsługujące Dolby Vision.
[C-1-2] NALEŻY prawidłowo wyświetlać treści Dolby Vision na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).
[C-1-3] NALEŻY ustawić indeks ścieżki warstw zgodnych z wersjami starszymi (jeśli występują) tak, aby był taki sam jak indeks ścieżki połączonej warstwy Dolby Vision.

5.3.9. AV1

Jeśli implementacje urządzeń obsługują kodek AV1, to:

[C-1-1] MUSI obsługiwać profil 0, w tym treści 10-bitowe.

5.4. Nagrywanie dźwięku

Chociaż niektóre wymagania opisane w tej sekcji są od wersji Androida 4.3 oznaczone jako „NALEŻY”, w definicji zgodności w przyszłych wersjach zostaną one zmienione na „NALEŻY”. Aby zapewnić zgodność z Androidem w przyszłej wersji, MOCNO zalecamy spełnienie tych wymagań, które są oznaczone jako „NALEŻY”. W przeciwnym razie urządzenie nie będzie zgodne z Androidem.

5.4.1. Przechwytywanie nieprzetworzonego dźwięku i informacje o mikrofonie

Jeśli implementacje na urządzeniu deklarują android.hardware.microphone, to:

[C-1-1] MUSI umożliwiać rejestrowanie surowego dźwięku o tych właściwościach:
- Format: Linear PCM, 16-bitowy
- Częstotliwości próbkowania: 8000, 11025, 16000, 44100, 48000 Hz
- Kanały: mono
NALEŻY zezwolić na rejestrowanie surowych treści audio o tych cechach:
- Format: PCM liniowy, 16- 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 jest na urządzeniu.
[C-1-2] NALEŻY nagrywać z wykorzystaniem współczynników próbkowania wyższych niż 48 kHz bez interpolacji.
[C-1-3] NALEŻY użyć odpowiedniego filtra antyaliasingu, gdy wymienione powyżej częstotliwości próbkowania są rejestrowane z obniżeniem próbkowania.
POWINNA umożliwiać rejestrowanie surowych treści audio w jakości radia AM i DVD, co oznacza te cechy:
- Format: Linear PCM, 16-bitowy
- Częstotliwości próbkowania: 22050, 48000 Hz
- Kanały: stereo
- [C-1-4] MUSI obsługiwać interfejs API MicrophoneInfo i odpowiednio wypełniać informacje o dostępnych mikrofonach na urządzeniu dostępnych dla aplikacji innych firm za pomocą interfejsu API AudioManager.getMicrophones() oraz o obecnie aktywnych mikrofonach dostępnych dla aplikacji innych firm za pomocą interfejsów API AudioRecord.getActiveMicrophones() i MediaRecorder.getActiveMicrophones(). Jeśli implementacje urządzeń umożliwiają przechwytywanie nieprzetworzonych treści audio w jakości radia AM i DVD, mogą:
[C-2-1] NALEŻY nagrywać bez próbkowania w górę w dowolnym formacie wyższym niż 16000:22050 lub 44100:48000.
[C-2-2] MUSI zawierać odpowiedni filtr antyaliasingu w przypadku próbkowania w górę lub w dół.

5.4.2. Przechwytywanie danych do rozpoznawania głosu

Jeśli implementacje na urządzeniu deklarują android.hardware.microphone, to:

[C-1-1] NALEŻY zarejestrować źródło dźwięku android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION z częstotliwością próbkowania 44 100 lub 48 000.
[C-1-2] Domyślnie musisz wyłączyć wszelkie przetwarzanie dźwięku w celu redukcji szumów podczas nagrywania strumienia audio ze źródła audio AudioSource.VOICE_RECOGNITION.
[C-1-3] Domyślnie należy wyłączyć automatyczne sterowanie wzmocnieniem podczas nagrywania strumienia audio ze źródła audio AudioSource.VOICE_RECOGNITION.
NALEŻY nagrywać strumień audio do rozpoznawania głosu z około płaską charakterystyką amplitudy w zależności od częstotliwości: konkretnie ±3 dB w zakresie 100–4000 Hz.
NALEŻY nagrywać strumień audio do rozpoznawania głosu z ustawionymi czułościami wejściowymi, tak aby źródło o poziomie mocy dźwięku (SPL) 90 dB przy 1000 Hz dawało wartość RMS 2500 dla próbek 16-bitowych.
NALEŻY nagrywać strumień audio do rozpoznawania mowy w taki sposób, aby poziomy amplitudy PCM śledziły liniowo zmiany SPL wejścia w zakresie co najmniej 30 dB od -18 dB do +12 dB w skali SPL 90 dB przy mikrofonie.
NALEŻY nagrywać strumień audio do rozpoznawania głosu z całkowitym zniekształceniem harmonicznym (THD) mniejszym niż 1% dla 1 kHz przy poziomie wejściowym 90 dB SPL na mikrofonie.

Jeśli implementacje na urządzeniach deklarują android.hardware.microphone i technologie redukcji szumów dostosowane do rozpoznawania mowy, to:

[C-2-1] NALEŻY umożliwić sterowanie tym efektem dźwiękowym za pomocą interfejsu API android.media.audiofx.NoiseSuppressor.
[C-2-2] Identyfikuj jednoznacznie każdą implementację technologii redukcji szumów za pomocą pola AudioEffect.Descriptor.uuid.

5.4.3. Przechwytywanie w celu przekierowania odtwarzania

Klasa android.media.MediaRecorder.AudioSource zawiera źródło dźwięku REMOTE_SUBMIX.

Jeśli implementacje urządzeń deklarują zarówno android.hardware.audio.output, jak i android.hardware.microphone, to:

[C-1-1] NALEŻY prawidłowo zaimplementować źródło dźwięku REMOTE_SUBMIX, aby aplikacja korzystająca z interfejsu API android.media.AudioRecord 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 na urządzeniu deklarują android.hardware.microphone, to:

NALEŻY wdrożyć technologię usuwania echa akustycznego (AEC) dostosowaną do komunikacji głosowej i zastosowaną do ścieżki przechwytywania podczas przechwytywania za pomocą AudioSource.VOICE_COMMUNICATION

Jeśli implementacje na urządzeniach zapewniają funkcję usuwania echa, która jest wstawiana na ścieżce przechwytywania dźwięku, gdy wybrana jest opcja AudioSource.VOICE_COMMUNICATION, to:

[C-SR] Zdecydowanie zalecamy oświadczenie za pomocą metody interfejsu API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
[C-SR] MOCNO_ZALECANA możliwość sterowania tym efektem dźwiękowym za pomocą interfejsu API AcousticEchoCanceler.
[C-SR] ZALECAMY jednoznaczne identyfikowanie każdej implementacji technologii AEC za pomocą pola AudioEffect.Descriptor.uuid.

5.4.5. Jednoczesne nagrywanie

Jeśli implementacje urządzeń deklarują android.hardware.microphone,MUSZĄ zaimplementować jednoczesne przechwytywanie zgodnie z opisem w tym dokumencie. Więcej szczegółów:

[C-1-1] NALEŻY zezwolić na jednoczesny dostęp do mikrofonu przez usługę ułatwień dostępu, która rejestruje dane za pomocą AudioSource.VOICE_RECOGNITION, oraz co najmniej 1 aplikacji, która rejestruje dane za pomocą dowolnego AudioSource.
[C-1-2] MUSI zezwalać na jednoczesny dostęp do mikrofonu przez wstępnie zainstalowaną aplikację, która pełni rolę Asystenta, oraz co najmniej jedną aplikację, która rejestruje dźwięk za pomocą dowolnego AudioSource, z wyjątkiem AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER.
[C-1-3] Podczas nagrywania dźwięku za pomocą funkcji AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER aplikacja MUSI wyciszyć dźwięk z innych aplikacji (z wyjątkiem usług ułatwień dostępu). Jeśli jednak aplikacja rejestruje dane za pomocą AudioSource.VOICE_COMMUNICATION, inna aplikacja może rejestrować rozmowę głosową, jeśli jest to uprzywilejowana (zainstalowana fabrycznie) aplikacja z uprawnieniem CAPTURE_AUDIO_OUTPUT.
[C-1-4] Jeśli 2 lub więcej aplikacji nagrywa jednocześnie i żadna z nich nie ma interfejsu na górze, dźwięk jest przesyłany z aplikacji, która rozpoczęła nagrywanie jako ostatnia.

5.4.6. Poziomy wzmocnienia mikrofonu

Jeśli implementacje na urządzeniu deklarują android.hardware.microphone, to:

POWINNY wykazywać w zakresie średnich częstotliwości w przybliżeniu płaskie charakterystyki amplitudy w funkcji częstotliwości: konkretnie ±3 dB w zakresie 100–4000 Hz dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania głosu.
NALEŻY ustawić czułość wejścia audio tak, aby sygnał sinusoidalny o częstotliwości 1000 Hz odtwarzany z poziomem ciśnienia akustycznego (SPL) 90 dB dawał odpowiedź z wartością RMS wynoszącą 2500 dla próbek 16-bitowych (lub -22,35 dB w zakresie pełnym dla próbek z pływającą kropką/podwójną precyzją) dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania mowy.
[C-SR] BARDZO ZALECAMY, aby poziomy amplitudy w zakresie niskich częstotliwości (od ±20 dB w zakresie 5–100 Hz) były porównywalne z poziomami w zakresie średnich częstotliwości w przypadku każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania głosu.
[C-SR] ZALECAMY, aby poziomy amplitudy w zakresie wysokich częstotliwości wynosiły ±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.

5.5. Odtwarzanie dźwięku

Android obsługuje odtwarzanie dźwięku przez peryferyjne wyjście audio zgodnie z opisem w sekcji 7.8.2.

5.5.1. Odtwarzanie dźwięku w postaci surowych danych

Jeśli implementacje na urządzeniu deklarują android.hardware.audio.output, to:

[C-1-1] MUSI umożliwiać odtwarzanie surowych treści audio o tych cechach:
- Formaty źródłowe: PCM liniowy, 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, 32000, 44100, 48000 przy konfiguracjach kanału wymienionych powyżej
  - 96000 w mono i stereo
NALEŻY zezwolić na odtwarzanie surowych treści audio o tych cechach:
- Częstotliwości próbkowania: 24 000, 48 000

5.5.2. Efekty dźwiękowe

Android udostępnia interfejs API do efektów dźwiękowych na potrzeby implementacji na urządzeniach.

Jeśli implementacje na urządzeniach deklarują funkcję android.hardware.audio.output, muszą:

[C-1-1] MUSI obsługiwać implementacje EFFECT_TYPE_EQUALIZER i EFFECT_TYPE_LOUDNESS_ENHANCER, które można kontrolować za pomocą podklas AudioEffect Equalizer i LoudnessEnhancer.
[C-1-2] MUSI obsługiwać implementację interfejsu API wizualizacji, którą można kontrolować za pomocą klasy Visualizer.
[C-1-3] Musi obsługiwać implementację EFFECT_TYPE_DYNAMICS_PROCESSING, którą można kontrolować za pomocą podklasy AudioEffect DynamicsProcessing.
Powinien obsługiwać implementacje EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB i EFFECT_TYPE_VIRTUALIZER, które można kontrolować za pomocą podklas AudioEffect BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.
[C-SR] ZALECAMY obsługę efektów w postaci liczb zmiennoprzecinkowych i wielokanałowych.

5.5.3. Głośność wyjścia audio

Implementacje na urządzeniach samochodowych:

NALEŻY umożliwić dostosowywanie głośności dźwięku osobno dla każdego strumienia audio, używając typu treści lub użycia zdefiniowanego przez AudioAttributes oraz użycia dźwięku w samochodzie zdefiniowanego publicznie w android.car.CarAudioManager.

5.6. Opóźnienie dźwięku

Opóźnienie dźwięku to czas opóźnienia sygnału dźwiękowego w systemie. Wiele rodzajów aplikacji wymaga niskich opóźnień, aby uzyskać efekty dźwiękowe w czasie rzeczywistym.

W rozumieniu tego punktu stosuje się następujące definicje:

opóźnienie wyjścia. Interval między zapisaniem przez aplikację ramki danych zakodowanych w formacie PCM a momentem, w którym odpowiedni dźwięk jest prezentowany otoczeniu przez przetwornik na urządzeniu lub sygnał opuszcza urządzenie przez port i może być obserwowany z zewnątrz.
opóźnienie zimnego wyjścia. Opóźnienie wyjścia dla pierwszego obrazu, gdy system wyjścia audio był nieaktywny i wyłączony przed żądaniem.
ciągły czas oczekiwania na wyjście. Opóźnienie wyjściowe kolejnych klatek po rozpoczęciu odtwarzania dźwięku przez urządzenie.
opóźnienie reakcji. Interval between when a sound is presented by environment to device at an on-device transducer or signal enters the device via a port and when an application reads the corresponding frame of PCM-coded data.
utracił(a) dane wejściowe. Początkowa część sygnału wejściowego, która jest nieprzydatna lub niedostępna.
Opóźnienie w przypadku zimnego wejścia. Suma czasu utraconego na wprowadzenie danych i opóźnienia wprowadzania danych dla pierwszej klatki, gdy system wprowadzania danych audio był nieaktywny i wyłączony przed żądaniem.
ciągłe opóźnienie wejścia. Opóźnienie wejścia w przypadku kolejnych klatek podczas rejestrowania dźwięku przez urządzenie.
tylko w przypadku jittera na wyjściu. zmienność między poszczególnymi pomiarami wartości opóźnienia wyjścia bez uczenia
Jitter na zimnym wejściu. zmienność między poszczególnymi pomiarami wartości opóźnienia zimnego wejścia;
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 jeden okres buforowania. Okres buforowania daje aplikacji czas na przetworzenie sygnału i zmniejszenie różnicy fazy między strumieniami wejściowym i wyjściowym.
OpenSL ES PCM buffer queue API. Zestaw interfejsów API OpenSL ES związanych z PCM w Android NDK.
AAudio – natywny interfejs API do obsługi dźwięku. Zestaw interfejsów AAudio w ramach Android NDK.
Sygnatura czasowa. Para składająca się z względnej pozycji klatki w strumieniach i szacowanego czasu, w którym dana klatka wchodzi do potoku przetwarzania dźwięku lub z niego wychodzi na powiązanym urządzeniu końcowym. Zobacz też AudioTimestamp.
glitch. Tymczasowe przerwanie lub nieprawidłowa wartość próbki w sygnale audio, zwykle spowodowane niedostatecznym wypełnieniem bufora w przypadku danych wyjściowych, przepełnieniem bufora w przypadku danych wejściowych lub jakimkolwiek innym źródłem szumu cyfrowego lub analogowego.

Jeśli implementacje na urządzeniu deklarują android.hardware.audio.output, muszą spełniać te wymagania:

[C-1-1] Sygnatura czasowa zwracana przez AudioTrack.getTimestamp i AAudioStream_getTimestamp jest dokładna do +/- 2 ms.
[C-1-2] Opóźnienie wyjściowe na zimno nie większe niż 500 ms.

Jeśli implementacje na urządzeniach deklarują android.hardware.audio.output, to ZALECAMY, aby spełniały te wymagania lub je przekraczały:

[C-SR] Opóźnienie wyjściowe na zimno nie większe niż 100 ms. BARDZO ZALECAMY, aby istniejące i nowe urządzenia z tą wersją Androida spełniały te wymagania. W przyszłej wersji platformy w 2021 r. wymagamy, aby opóźnienie wyjściowe w przypadku zimnego uruchomienia nie przekraczało 200 ms.
[C-SR] Ciągłe opóźnienie wyjściowe nieprzekraczające 45 ms.
[C-SR] Zminimalizuj jitter wyjściowy na zimno.
[C-SR] Sygnatura czasowa wyjściowa zwracana przez AudioTrack.getTimestamp i AAudioStream_getTimestamp jest dokładna do +/- 1 ms.

Jeśli implementacje urządzeń spełniają powyższe wymagania, po początkowej kalibracji, przy użyciu kolejki buforów OpenSL ES PCM i natywnych interfejsów API AAudio, opóźnienie ciągłego wyjścia i opóźnienie zimnego wyjścia na co najmniej 1 obsługiwanym urządzeniu wyjściowym audio wynosi:

[C-SR] ZALECAMY zgłaszanie dźwięku o małym opóźnieniu przez zadeklarowanie flagi funkcji android.hardware.audio.low_latency.
[C-SR] ZALECAMY, aby spełniać wymagania dotyczące dźwięku o niskim opóźnieniu za pomocą interfejsu AAudio API.
[C-SR] ZALECAMY, aby w przypadku strumieni zwracających wartość AAUDIO_PERFORMANCE_MODE_LOW_LATENCY z AAudioStream_getPerformanceMode() wartość zwracana przez AAudioStream_getFramesPerBurst() była mniejsza lub równa wartości zwracanej przez android.media.AudioManager.getProperty(String) dla klucza właściwości AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Jeśli implementacje na urządzeniach nie spełniają wymagań dotyczących niskiej latencji dźwięku za pomocą kolejki buforów OpenSL ES PCM i natywnego interfejsu API AAudio, nie spełniają też tych wymagań:

[C-2-1] NIE zgłaszaj obsługi dźwięku o małej latencji.

Jeśli implementacje urządzeń obejmują android.hardware.microphone, muszą spełniać te wymagania dotyczące wejściowego sygnału audio:

[C-3-1] Ogranicz błąd w sygnaturach czasowych wejścia zwracanych przez funkcję AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/- 2 ms. „Błąd” oznacza tu odchylenie od prawidłowej wartości.
[C-3-2] Opóźnienie w przypadku zimnego uruchomienia nie dłuższe niż 500 ms.

Jeśli implementacje urządzeń obejmują android.hardware.microphone, MOCNO ZALECAMY, aby spełniały te wymagania dotyczące dźwięku wejściowego:

[C-SR] Opóźnienie wejścia „na zimno” nie większe niż 100 ms. BARDZO ZALECAMY, aby istniejące i nowe urządzenia z tą wersją Androida spełniały te wymagania. W przyszłej wersji platformy w 2021 r. wymagamy, aby opóźnienie w przypadku zimnego wejścia nie przekraczało 200 ms.
[C-SR] Ciągłe opóźnienie wejścia nieprzekraczające 30 ms.
[C-SR] Ciągłe opóźnienie w obie strony nieprzekraczające 50 ms.
[C-SR] Zminimalizuj jitter w przypadku zimnego wejścia.
[C-SR] Ogranicz błąd w danych sygnatury czasowej wejścia zwracanych przez AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/- 1 ms.

5.7. Protokoły sieciowe

Implementacje na urządzeniach MUSZĄ obsługiwać protokoły sieci multimedialnej do odtwarzania dźwięku i obrazu zgodnie z dokumentacją pakietu SDK Androida.

Jeśli implementacje na urządzeniu obejmują dekoder audio lub wideo, muszą:

[C-1-1] MUSI obsługiwać wszystkie wymagane kodeki i formaty kontenerów wymienione w sekcji 5.1 w protokole HTTP(S).
[C-1-2] MUSI obsługiwać formaty segmentów multimediów podane w tabeli Formaty segmentów multimediów poniżej w ramach protokołu HTTP Live Streaming w wersji 7.
[C-1-3] MUSI obsługiwać profil audio i wideo RTP oraz powiązane z nim kodeki w tabeli RTSP poniżej. Wyjątki znajdziesz w przypisach do tabeli w sekcji 5.1.

Formaty segmentów multimediów

Formaty segmentów	Odsyłacze	Obsługa wymaganych kodeków
MPEG-2 Transport Stream	ISO 13818	Kodek 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.3. Kodeki audio: AAC Więcej informacji o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
AAC z ramowaniem ADTS i tagami ID3	ISO 13818-7	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
WebVTT	WebVTT

Formaty segmentów

Odsyłacze

Obsługa wymaganych kodeków

MPEG-2 Transport Stream

ISO 13818

Kodek 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.3.

Kodeki audio:

Więcej informacji o AAC i jego wariantach znajdziesz w sekcji 5.1.1.

AAC z ramowaniem ADTS i tagami ID3

ISO 13818-7

Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1.

WebVTT

RTSP (RTP, SDP)

Nazwa profilu	Odsyłacze	Obsługa wymaganych kodeków
H264 AVC	RFC 6184	Szczegółowe informacje na temat H264 AVC znajdziesz w sekcji 5.1.3.
MP4A-LATM	RFC 6416	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Szczegółowe informacje o H.263 znajdziesz w sekcji 5.1.3.
H263-2000	RFC 4629	Szczegółowe informacje o H.263 znajdziesz w sekcji 5.1.3.
AMR	RFC 4867	Szczegółowe informacje o AMR-NB znajdziesz w sekcji 5.1.1.
AMR-WB	RFC 4867	Szczegółowe informacje o AMR-WB znajdziesz w sekcji 5.1.1.
MP4V-ES	RFC 6416	Szczegółowe informacje o MPEG-4 SP znajdziesz w sekcji 5.1.3.
mpeg4-generic	RFC 3640	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
MP2T	RFC 2250	Szczegółowe informacje znajdziesz w sekcji MPEG-2 Transport Stream w sekcji Transmisja na żywo przez HTTP.

5.8. Secure Media

Jeśli implementacje urządzeń obsługują bezpieczne wyjście wideo i mogą obsługiwać bezpieczne powierzchnie, mogą:

[C-1-1] MUSISZ zadeklarować obsługę Display.FLAG_SECURE.

Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE i protokołu wyświetlania bezprzewodowego, muszą:

[C-2-1] W przypadku wyświetlaczy podłączonych za pomocą protokołów bezprzewodowych, takich jak Miracast, należy zabezpieczyć połączenie za pomocą silnego mechanizmu szyfrowania, takiego jak HDCP 2.x lub nowszy.

Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE i obsługują przewodowy wyświetlacz zewnętrzny, muszą:

[C-3-1] W przypadku wszystkich zewnętrznych wyświetlaczy podłączonych przez port przewodowy dostępny dla użytkownika MUSI być obsługiwana funkcja HDCP 1.2 lub nowsza.

5.9. MusicaI Instrument Digital Interface (MIDI)

Jeśli implementacje na urządzeniach zgłaszają obsługę funkcji android.software.midi za pomocą klasy android.content.pm.PackageManager, to:

[C-1-1] MUSI obsługiwać MIDI przez wszystkie urządzenia transportowe z obsługą MIDI, dla których zapewniają one ogólne połączenia nie-MIDI. Takie urządzenia transportowe:
- Tryb hosta USB, sekcja 7.7
- MIDI przez Bluetooth LE w roli centralnej, sekcja 7.4.3
[C-1-2] MUSI obsługiwać przesyłanie danych MIDI między aplikacjami (wirtualne urządzenia MIDI)
[C-1-3] MUSI zawierać libamidi.so (obsługa MIDI natywnych)
POWINIEN obsługiwać MIDI przez USB w trybie peryferyjnym (sekcja 7.7).

5.10. Profesjonalny dźwięk

Jeśli implementacje na urządzeniu zgłaszają obsługę funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager, to:

[C-1-1] MUST report support for feature android.hardware.audio.low_latency.
[C-1-2] Ciągłe opóźnienie w obie strony w przypadku dźwięku, zgodnie z definicją w sekcji 5.6 Opóźnienie w przypadku dźwięku, MUSI wynosić 20 ms lub mniej i POWINNA wynosić 10 ms lub mniej w przypadku co najmniej jednej obsługiwanej ścieżki.
[C-1-3] Musi zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
[C-1-4] MUST report support for feature android.software.midi.
[C-1-5] Musi spełniać wymagania dotyczące opóźnień i dźwięku USB, korzystając z interfejsu API kolejki bufora OpenSL ES PCM oraz co najmniej 1 ścieżki interfejsu API dźwięku natywnego AAudio.
[SR] ZALECAMY stosowanie interfejsu API AAudio native audio, aby spełnić wymagania dotyczące opóźnień i dźwięku USB, zamiast korzystania z ścieżki MMAP.
[C-1-6] Czas opóźnienia wyjściowego w przypadku zimnego uruchomienia musi wynosić 200 ms lub mniej.
[C-1-7] Czas reakcji na zimny start musi wynosić 200 ms lub mniej.
[SR] MOCNO ZALECANA jest zapewnienie stałego poziomu wydajności procesora, gdy dźwięk jest aktywny, a obciążenie procesora się zmienia. Należy to przetestować, używając wersji aplikacji na Androida z identyfikatorem zatwierdzenia SynthMark 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark używa syntezatora programowego działającego w symulowanym środowisku audio, które mierzy wydajność systemu. Aplikację SynthMark należy uruchomić, korzystając z opcji „Automatyczny test”, i uzyskać następujące wyniki:
- voicemark.90 > 32 głosów
- latencymark.fixed.little <= 15 ms
- latencymark.dynamic.little <= 50 ms

Więcej informacji o benchmarkach znajdziesz w dokumentacji SynthMark.

NALEŻY zminimalizować niedokładność zegara audio i jego odchylenia względem czasu standardowego.
NALEŻY zminimalizować przesunięcie zegara dźwięku w stosunku do procesora CLOCK_MONOTONIC, gdy oba są aktywne.
NALEŻY zminimalizować opóźnienie dźwięku na przetwornikach na urządzeniu.
NALEŻY zminimalizować opóźnienie dźwięku w przypadku dźwięku cyfrowego przez USB.
NALEŻY udokumentować pomiary opóźnienia dźwięku na wszystkich ścieżkach.
NALEŻY zminimalizować jitter w czasie wywołania zwrotnego zakończenia bufora audio, ponieważ wpływa to na procentowy udział w pełnej przepustowości procesora przez wywołanie zwrotne.
W przypadku normalnego użytkowania przy zgłoszonym opóźnieniu nie powinno być żadnych zakłóceń dźwięku.
NALEŻY zapewnić zerową różnicę opóźnień między kanałami.
NALEŻY zminimalizować średni czas oczekiwania MIDI w przypadku wszystkich transportów.
NALEŻY zminimalizować zmienność opóźnienia MIDI pod obciążeniem (jitter) we wszystkich transporcie.
NALEŻY podać dokładne sygnatury czasowe MIDI w przypadku wszystkich transportów.
NALEŻY zminimalizować szum sygnału audio na przetwornikach na urządzeniu, w tym w okresie bezpośrednio po uruchomieniu „na zimno”.
NALEŻY zapewnić zerową różnicę zegara audio między stroną wejścia i wyjścia odpowiednich punktów końcowych, gdy oba są aktywne. Przykładami odpowiednich punktów końcowych są mikrofon i głośnik na urządzeniu lub wejście i wyjście gniazda audio.
NALEŻY obsłużyć wywołania zwrotne zakończenia buforowania dźwięku po stronie wejścia i wyjścia odpowiednich punktów końcowych w tym samym wątku, gdy oba są aktywne, oraz wejść w wywołanie zwrotne wyjścia bezpośrednio po powrocie z wywołania zwrotnego wejścia. Jeśli nie można obsłużyć wywołań zwrotnych w tym samym wątku, wpisz wywołanie zwrotne wyjścia tuż po wywołaniu zwrotnym wejścia, aby umożliwić aplikacji spójne ustalanie czasu po stronie wejścia i wyjścia.
NALEŻY zminimalizować różnicę fazową między buforowaniem dźwięku HAL po stronie wejścia i wyjścia odpowiednich punktów końcowych.
NALEŻY zminimalizować opóźnienie dotykowe.
NALEŻY zminimalizować zmienność opóźnienia dotyku pod obciążeniem (jitter).
Opóźnienie od dotyku do wyjścia audio nie powinno przekraczać 40 ms.

Jeśli implementacje urządzeń spełniają wszystkie powyższe wymagania, mogą:

[SR] ZALECAMY zgłaszanie obsługi funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager.

Jeśli implementacje urządzeń zawierają 4-żyłowe gniazdo słuchawek 3,5 mm, muszą:

[C-2-1] Opóźnienie dźwięku w obie strony nie może przekraczać 20 ms na ścieżce audio przez złącze audio.
[SR] ZALECAMY stosowanie się do sekcji Specyfikacja urządzenia mobilnego (gniazdo) w specyfikacji przewodowych słuchawek nausznych (w wersji 1.1).
Ciągłe opóźnienie sygnału audio w obie strony nie powinno przekraczać 10 ms na wyjściu audio.

Jeśli implementacje urządzeń nie mają 4-żyłowego gniazda słuchawek 3,5 mm, ale mają porty USB obsługujące tryb hosta USB, to:

[C-3-1] Musisz zaimplementować klasę audio USB.
[C-3-2] Urządzenie MUSI mieć ciągłe opóźnienie dźwięku w obie strony nieprzekraczające 20 ms w trybie hosta USB przy użyciu klasy audio USB.
Ciągłe opóźnienie w obie strony nie powinno przekraczać 10 ms w przypadku portu w trybie hosta USB przy użyciu klasy audio USB.
[C-SR] Zaleca się, aby podczas korzystania z urządzeń peryferyjnych USB obsługujących te wymagania urządzenie obsługiwało jednocześnie do 8 kanałów wejściowych i wyjściowych, częstotliwość próbkowania 96 kHz oraz głębię 24- lub 32-bitową.

Jeśli implementacje urządzeń zawierają port HDMI, muszą:

W co najmniej jednej konfiguracji NALEŻY obsługiwać wyjście stereo i 8 kanałów z głębią bitową 20- lub 24-bitową i częstotliwością próbkowania 192 kHz bez utraty głębi bitowej ani próbkowania.

5.11. Rejestrowanie nieprzetworzonych

Android obsługuje nagrywanie nieprzetworzonego dźwięku za pomocą źródła audio android.media.MediaRecorder.AudioSource.UNPROCESSED. W OpenSL ES można uzyskać do niego dostęp za pomocą wstępnie ustawionego rekordu SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Jeśli implementacje urządzeń mają obsługiwać nieprzetworzone źródło dźwięku i udzielać do niego dostępu aplikacjom innych firm, muszą:

[C-1-1] Musisz zgłosić obsługę w ramach właściwości android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] W zakresie średnich częstotliwości muszą występować w przybliżeniu płaskie charakterystyki amplitudy w funkcji częstotliwości: dokładnie ±10 dB od 100 Hz do 7000 Hz w przypadku każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.
[C-1-3] NALEŻY wykazać poziomy amplitudy w zakresie niskich częstotliwości: dokładnie od ±20 dB od 5 Hz do 100 Hz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu użytego do nagrywania nieprzetworzonego źródła dźwięku.
[C-1-4] NALEŻY wykazać poziomy amplitudy w zakresie wysokich częstotliwości: w szczególności od ±30 dB od 7000 Hz do 22 kHz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu użytego do nagrywania nieprzetworzonego źródła dźwięku.
[C-1-5] NALEŻY ustawić czułość wejścia audio tak, aby sygnał sinusoidalny o częstotliwości 1000 Hz odtwarzany z poziomem ciśnienia akustycznego (SPL) wynoszącym 94 dB dawał odpowiedź z wartością RMS wynoszącą 520 dB dla próbek 16-bitowych (lub -36 dB w skali pełnej dla próbek z dokładnością zmiennoprzecinkową/podwójną) dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.
[C-1-6] W przypadku każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku MUSI być zachowany stosunek sygnału do szumu (SNR) na poziomie 60 dB lub wyższym. (gdzie SNR jest mierzony jako różnica między 94 dB SPL a ekwiwalent SPL własnego szumu, z wagami A).
[C-1-7] Łączne zniekształcenie harmoniczne (THD) musi być mniejsze niż 1% przy 1 kHz przy poziomie wejściowym 90 dB SPL w przypadku każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.
Nie może zawierać żadnego innego przetwarzania sygnału (np. automatycznej regulacji wzmocnienia, filtra górnoprzepustowego czy eliminacji echa) na ścieżce, oprócz mnożnika poziomu, który ma doprowadzić poziom do pożądanego zakresu. Krótko mówiąc:
[C-1-8] Jeśli w ramach architektury z jakiegokolwiek powodu występuje przetwarzanie sygnału, należy je wyłączyć i wprowadzić zerowe opóźnienie lub dodatkowe opóźnienie na ścieżce sygnału.
[C-1-9] Pomnóżnik poziomu, mimo że może się znajdować na ścieżce, NIE MOŻE powodować opóźnień na ścieżce sygnału.

Wszystkie pomiary SPL są wykonywane bezpośrednio przy mikrofonie, który jest testowany. W przypadku wielu konfiguracji mikrofonów te wymagania mają zastosowanie do każdego mikrofonu.

Jeśli implementacje urządzeń deklarują android.hardware.microphone, ale nie obsługują nieprzetworzonego źródła dźwięku, to:

[C-2-1] W przypadku metody interfejsu API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) musisz zwrócić wartość null, aby prawidłowo wskazać brak obsługi.
[SR] nadal MOCNO zaleca się, aby spełniać jak najwięcej wymagań dotyczących ścieżki sygnału dla nieprzetworzonego źródła nagrania.

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

6.1. Narzędzia dla programistów

Implementacje na urządzeniu:

[C-0-1] Musi obsługiwać narzędzia dla deweloperów Androida udostępniane w pakiecie Android SDK.
Android Debug Bridge (adb)
- [C-0-2] MUSI obsługiwać adb zgodnie z dokumentacją do pakietu Android SDK i komendy powłoki dostępne w AOSP, których mogą używać deweloperzy aplikacji, w tym dumpsys cmd stats
- [C-0-11] Musi obsługiwać polecenie powłoki cmd testharness. Z wyjątkiem wytycznych C-0-11 z możliwością ominięcia wytycznych C-0-11 mogą być zwolnione z wymagań wytycznych C-0-11: uaktualnienia implementacji urządzenia z wersji Androida bez trwałego blokowania danych.
- [C-0-3] Nie wolno zmieniać formatu ani zawartości zdarzeń systemowych urządzenia (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) zarejestrowanych za pomocą polecenia dumpsys.
- [C-0-10] NALEŻY rejestrować bez pomijania i uzyskiwać dostęp do tych zdarzeń, aby były dostępne dla polecenia cmd stats w powłoce i klasy interfejsu StatsManager System API.
  - ActivityForegroundStateChanged
  - AnomalyDetected
  - AppBreadcrumbReported
  - AppCrashOccurred
  - AppStartOccurred
  - BatteryLevelChanged
  - BatterySaverModeStateChanged
  - BleScanResultReceived
  - BleScanStateChanged
  - ChargingStateChanged
  - DeviceIdleModeStateChanged
  - ForegroundServiceStateChanged
  - GpsScanStateChanged
  - JobStateChanged
  - PluggedStateChanged
  - ScheduledJobStateChanged
  - ScreenStateChanged
  - SyncStateChanged
  - SystemElapsedRealtime
  - UidProcessStateChanged
  - WakelockStateChanged
  - WakeupAlarmOccurred
  - WifiLockStateChanged
  - WifiMulticastLockStateChanged
  - WifiScanStateChanged
- [C-0-4] Domyślnie demon adb na urządzeniu MUSI być nieaktywny i MUSI istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie Android Debug Bridge.
- [C-0-5] MUSI obsługiwać bezpieczny interfejs ADB. Android obsługuje bezpieczne połączenia ADB. Bezpieczny adb włącza adb na znanych uwierzytelnionych hostach.
- [C-0-6] MUSI zawierać 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 peryferyjny:
- [C-3-1] NALEŻY stosować adb przez sieć lokalną (np. Ethernet lub Wi-Fi).
- [C-3-2] Musisz udostępnić sterowniki dla systemów Windows 7, 8 i 10, które umożliwiają deweloperom nawiązywanie połączenia z urządzeniem za pomocą protokołu adb.
Jeśli implementacje urządzeń obsługują połączenia adb z hostem przez Wi-Fi, to:
- [C-4-1] Metoda AdbManager#isAdbWifiSupported() MUSI zwracać wartość true.
Jeśli implementacje urządzeń obsługują połączenia adb z hostem przez Wi-Fi i zawierają co najmniej 1 kamerę, to:
- [C-5-1] Metoda AdbManager#isAdbWifiQrSupported() MUSI zwracać wartość true.
Dalvik Debug Monitor Service (ddms)
- [C-0-7] Musi obsługiwać wszystkie funkcje DMS zgodnie z dokumentacją pakietu SDK Androida. Ponieważ ddms używa adb, obsługa ddms powinna być domyślnie nieaktywna, ale MUSI być obsługiwana, gdy użytkownik aktywuje Android Debug Bridge (ADB), jak opisano powyżej.
Monkey
- [C-0-8] Musisz uwzględnić platformę Monkey i uzyskać do niej dostęp w aplikacji.
SysTrace
- [C-0-9] Musi obsługiwać narzędzie systrace zgodnie z dokumentacją pakietu SDK Androida. Systrace musi być domyślnie nieaktywny i musi istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie Systrace.
Perfetto
- [C-SR] Zdecydowanie zalecamy udostępnienie użytkownikowi powłoki binarnego pliku /system/bin/perfetto, którego wiersz poleceń jest zgodny z dokumentacją perfetto.
- [C-SR] Zalecamy, aby binarny plik perfetto przyjmował jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
- [C-SR] Zalecamy, aby binarny plik perfetto zapisywał jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
- [C-SR] MOCNO zalecamy podanie w pliku binarnym perfetto co najmniej źródeł danych opisanych w dokumentacji perfetto.
Low Memory Killer
- [C-0-10] NALEŻY zapisać atom LMK_KILL_OCCURRED_FIELD_NUMBER do dziennika 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] MUST return true for ActivityManager.isRunningInUserTestHarness()
- [C-2-2] MUSISZ zaimplementować tryb jarzma testowego zgodnie z opisem w dokumentacji trybu jarzma testowego.

Jeśli implementacje urządzeń zgłaszają obsługę interfejsu Vulkan 1.0 lub nowszego za pomocą flag funkcji android.hardware.vulkan.version, to:

[C-1-1] NALEŻY zapewnić deweloperowi aplikacji możliwość włączania i wyłączania warstw debugowania GPU.
[C-1-2] Gdy włączone są warstwy debugowania GPU, MUSISZ wyliczać warstwy w bibliotekach udostępnianych przez narzędzia zewnętrzne (czyli niebędące częścią platformy ani pakietu aplikacji) znajdujące się w katalogu głównym aplikacji, aby obsługiwać metody interfejsu API vkEnumerateInstanceLayerProperties() i vkCreateInstance().

6.2. Opcje programisty

Android zawiera funkcje umożliwiające deweloperom konfigurowanie ustawień związanych z tworzeniem aplikacji.

Implementacje na urządzeniach MUSZĄ zapewniać spójne opcje dla deweloperów. Muszą one:

[C-0-1] Musisz obsługiwać działanie okna dialogowego android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z rozwojem aplikacji. W dolnej implementacji Androida menu Opcje dewelopera jest domyślnie ukryte, a użytkownicy mogą je otworzyć, gdy 7 razy klikną element menu Ustawienia > Informacje o urządzeniu > Numer kompilacji.
[C-0-2] Domyślnie należy ukryć Opcje programisty.
[C-0-3] Musisz udostępnić przejrzysty mechanizm, który nie faworyzuje jednej aplikacji zewnętrznej w stosunku do innej, aby umożliwić korzystanie z opcji dla deweloperów. MUSISZ podać publicznie dostępny dokument lub stronę internetową, w których opisano, jak włączyć opcje dewelopera. Dokument lub witryna muszą być dostępne z dokumentów pakietu Android SDK.
POWINIEN wyświetlać użytkownikowi stałe wizualne powiadomienie, gdy opcje programisty są włączone, a bezpieczeństwo użytkownika jest zagrożone.
MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty, ukrywając je wizualnie lub wyłączając, aby zapobiec rozproszeniu w sytuacjach, w których bezpieczeństwo użytkownika jest zagrożone.

7. Zgodność sprzętowa

Jeśli urządzenie zawiera określony komponent sprzętowy z odpowiednim interfejsem API dla deweloperów zewnętrznych:

[C-0-1] Implementacja na urządzeniu MUSI implementować interfejs API zgodnie z opisem w dokumentacji Android SDK.

Jeśli interfejs API w pakiecie SDK współdziała ze sprzętowym komponentem, który jest oznaczony jako opcjonalny, a urządzenie nie ma tego komponentu:

[C-0-2] W przypadku interfejsów API komponentów nadal MUSISZ podać pełne definicje klas (opisane w pakiecie SDK).
[C-0-3] Zachowanie interfejsu API MUSI być zaimplementowane w taki sposób, aby nie wymagało żadnych działań.
[C-0-4] Metody API MUSZĄ zwracać wartości null, gdy jest to dozwolone przez dokumentację pakietu SDK.
[C-0-5] Metody interfejsu API MUSZĄ zwracać implementacje klas bez operacji, gdy wartości null nie są dozwolone w dokumentacji pakietu SDK.
[C-0-6] Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, które nie są opisane w dokumentacji pakietu SDK.
[C-0-7] Implementacje urządzeń MUSZĄ konsekwentnie przekazywać dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager dla tego samego odcisku palca kompilacji.

Typowym przykładem scenariusza, w którym obowiązują te wymagania, jest interfejs API telefonii: nawet na urządzeniach innych niż telefony te interfejsy API muszą być implementowane jako rozsądne no-ops.

7.1. Wyświetlanie i grafika

Android zawiera funkcje, które automatycznie dostosowują zasoby aplikacji i układy interfejsu do urządzenia, aby aplikacje innych firm działały prawidłowo w różnych konfiguracjach sprzętowych. W przypadku wyświetlaczy zgodnych z Androidem, na których można uruchamiać wszystkie aplikacje innych firm zgodne z Androidem, implementacje na urządzeniu MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z informacjami podanymi w tej sekcji.

Jednostki, do których odwołują się wymagania w tej sekcji, są zdefiniowane w następujący sposób:

fizyczna przekątna. Odległość w calach między dwoma przeciwległymi rogami podświetlonej części wyświetlacza.
punkty na cal (dpi). Liczba pikseli zawartych w liniowym zakresie poziomym lub pionowym 1”. W przypadku podanych wartości dpi zarówno poziomy, jak i pionowy dpi muszą mieścić się w zakresie.
format. Stosunek pikseli dłuższego wymiaru do krótszego wymiaru ekranu. Na przykład wyświetlacz o wymiarach 480 x 854 pikseli miałby współczynnik 854/480 = 1, 779, czyli mniej więcej „16:9”.
piksel niezależny od gęstości (dp). Wirtualna jednostka piksela znormalizowana do ekranu o rozdzielczości 160 dpi, obliczona jako: piksele = dpi * (gęstość/160).

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar i kształt ekranu

Interfejs użytkownika Androida obsługuje różne rozmiary układów ekranu i pozwala aplikacjom wysyłać zapytanie o rozmiar układu ekranu w bieżącej konfiguracji za pomocą interfejsu Configuration.screenLayout z użyciem metod SCREENLAYOUT_SIZE_MASK i Configuration.smallestScreenWidthDp.

Implementacje na urządzeniu:

[C-0-1] Musisz podać prawidłowy rozmiar układu dla Configuration.screenLayout zgodnie z definicją w dokumentacji pakietu SDK Androida. W szczególności implementacje urządzeń MUSZĄ zgłaszać prawidłowe wymiary ekranu w pikselach niezależnych od gęstości (dp) zgodnie z poniższymi wartościami:
- Urządzenia z wartością Configuration.uiMode inną niż UI_MODE_TYPE_WATCH, które podają rozmiar Configuration.screenLayout, MUSZĄ mieć co najmniej 426 x 320 dp.small
- Urządzenia zgłaszające rozmiar normal dla Configuration.screenLayout MUSZĄ mieć co najmniej 480 dp x 320 dp.
- Urządzenia, które podają rozmiar large dla Configuration.screenLayout, MUSZĄ mieć wymiary co najmniej 640 x 480 dp.
- Urządzenia zgłaszające rozmiar xlarge w przypadku Configuration.screenLayout MUSZĄ mieć co najmniej 960 dp x 720 dp.
[C-0-2] MUSI prawidłowo obsługiwać deklarowane przez aplikację rozmiary ekranów za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml zgodnie z dokumentacją pakietu SDK Androida.
MOŻE mieć wyświetlacze zgodne z Androidem z zaokrąglonymi rogami.

Jeśli implementacje urządzeń obsługują UI_MODE_TYPE_NORMAL i obejmują wyświetlacze zgodne z Androidem z zaokrąglonymi rogami, to:

[C-1-1] NALEŻY zadbać o to, aby spełniony był co najmniej 1 z tych wymagań:
Promień zaokrąglonych rogów jest mniejszy lub równy 38 dp.
Gdy w każdym rogu logicznego wyświetlacza jest zakotwiczona ramka o wymiarach 15 x 15 dp, na ekranie jest widoczny co najmniej 1 piksel każdej ramki.
NALEŻY uwzględnić możliwość przełączenia się do trybu wyświetlania za pomocą prostokątnych rogów.

Jeśli implementacje urządzeń zawierają zgodne z Androidem wyświetlacze, które można złożyć, lub zawierają składany zawias między wieloma panelami wyświetlacza i umożliwiają renderowanie aplikacji innych firm, muszą:

[C-2-1] NALEŻY zaimplementować najnowszą dostępną stabilną wersję interfejsu extensions API lub stabilną wersję interfejsu sidecar API, aby można było go używać w bibliotece Jetpack Window Manager.

Jeśli implementacje urządzeń zawierają zgodne z Androidem wyświetlacze, które można złożyć, lub mają składane zawiasy między wieloma panelami wyświetlacza, a zawieszka lub składanie obejmuje okno aplikacji na pełnym ekranie, muszą:

[C-3-1] NALEŻY zgłaszać pozycję, granice i stan zawiasów lub składania za pomocą rozszerzeń lub interfejsów API.

Szczegółowe informacje o prawidłowym wdrażaniu interfejsów API sidecar lub rozszerzeń znajdziesz w publicznej dokumentacji Window Manager Jetpack.

7.1.1.2. Format obrazu

Chociaż nie ma ograniczeń dotyczących proporcji fizycznych ekranów zgodnych z Androidem, proporcje ekranu logicznego, na którym renderowane są aplikacje innych firm, muszą być zgodne z tymi wymaganiami:view.Display

[C-0-1] Wdrożenia na urządzeniach z wartością Configuration.uiMode równą UI_MODE_TYPE_NORMAL MUSZĄ mieć współczynnik kształtu obrazu mniejszy niż 1,86 (około 16:9), chyba że aplikacja spełnia jedną z tych 2 warunków:
- Aplikacja zadeklarowała, że obsługuje większy format obrazu za pomocą wartości metadanych android.max_aspect.
- Aplikacja deklaruje, że można zmienić jej rozmiar, za pomocą atrybutu android:resizeableActivity.
- Aplikacja jest kierowana na poziom interfejsu API 24 lub wyższy i nie deklaruje android:maxAspectRatio, który ogranicza dozwolony współczynnik proporcji.
[C-0-2] Wdrożenia na urządzeniach z wartością Configuration.uiMode równą UI_MODE_TYPE_NORMAL MUSZĄ mieć współczynnik proporcji równy lub większy niż 1,3333 (4:3), chyba że aplikacja może zostać rozciągnięta w szerzy, gdy spełniony jest jeden z tych warunków:
- Aplikacja deklaruje, że można zmienić jej rozmiar, za pomocą atrybutu android:resizeableActivity.
- Aplikacja deklaruje uprawnienie android:minAspectRatio, które ogranicza dozwolony format obrazu.
[C-0-3] Wdrożenia urządzenia z wartością Configuration.uiMode ustawioną jako UI_MODE_TYPE_WATCH MUSZĄ mieć wartość formatu obrazu ustawioną jako 1,0 (1:1).

7.1.1.3. Gęstość ekranu

Interfejs użytkownika Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić deweloperom aplikacji kierowanie zasobów aplikacji.

[C-0-1] Domyślnie implementacje urządzeń MUSZĄ zgłaszać tylko jedną z gęstości Androida, które są wymienione w DisplayMetrics za pomocą interfejsu API DENSITY_DEVICE_STABLE, a ta wartość NIE MOŻE się zmieniać. Urządzenie MOŻE jednak zgłaszać inną dowolną gęstość w zależności od zmian w konfiguracji wyświetlacza wprowadzonych przez użytkownika (np. rozmiar wyświetlacza) po pierwszym uruchomieniu.
Implementacje urządzeń powinny zdefiniować standardową gęstość w ramach Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, chyba że ta gęstość logiczna spowoduje, że zgłaszany rozmiar ekranu będzie niższy niż minimalny obsługiwany rozmiar. Jeśli standardowa gęstość ramki Androida, która pod względem liczbowym jest najbliższa fizycznej gęstości, powoduje, że rozmiar ekranu jest mniejszy niż najmniejszy obsługiwany zgodny rozmiar ekranu (szerokość 320 dp), implementacje urządzeń POWINNY zgłaszać następną niższą standardową gęstość ramki Androida.

Jeśli istnieje możliwość zmiany rozmiaru wyświetlacza urządzenia:

[C-1-1] Rozmiar wyświetlacza NIE MOŻE być powiększony ponad 1,5-krotną wartość gęstości natywnej ani nie może powodować, że minimalny wymiar ekranu będzie mniejszy niż 320 dp (co odpowiada kwalifikatorowi zasobu sw320dp), w zależności od tego, co nastąpi pierwsze.
[C-1-2] Rozmiar wyświetlacza NIE MOŻE być przeskalowany do wartości mniejszej niż 0,85 krotna gęstości natywnej.
Aby zapewnić wygodę użytkowania i spójność rozmiarów czcionek, zalecamy zastosowanie tych opcji skalowania wyświetlania natywnych (z zachowaniem limitów określonych powyżej).
Małe: 0,85 x
Domyślnie: 1x (rodzinna skala wyświetlacza)
Duża: 1,15 x
Większy: 1,3 x
Największy 1,45 x

7.1.2. Dane wyświetleń

Jeśli implementacje urządzeń obejmują wyświetlacze zgodne z Androidem lub wyjście wideo na ekrany zgodne z Androidem, muszą:

[C-1-1] MUSI raportować prawidłowe wartości wszystkich danych wyświetlania zgodnych z Androidem zdefiniowanych w interfejsie API android.util.DisplayMetrics.

Jeśli implementacje urządzeń nie zawierają wbudowanego ekranu ani wyjścia wideo, nie spełniają następujących wymagań:

[C-2-1] MUSI przekazywać 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 na urządzeniu:

[C-0-1] MUST report which screen orientations they support (android.hardware.screen.portrait or android.hardware.screen.landscape) and MUST report at least one supported orientation. Na przykład urządzenie z utrwaloną orientacją poziomą ekranu, takie jak telewizor czy laptop, POWINNA zgłaszać tylko android.hardware.screen.landscape.
[C-0-2] MUSI zwracać prawidłową wartość bieżącej orientacji urządzenia, gdy zostanie zapytany za pomocą interfejsów API android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innych.

Jeśli implementacje urządzeń obsługują obie orientacje ekranu, muszą:

[C-1-1] Aplikacje MUSZĄ obsługiwać dynamiczną orientację ekranu w orientacji poziomej lub pionowej. Oznacza to, że urządzenie musi uwzględnić prośbę aplikacji o określoną orientację ekranu.
[C-1-2] Nie wolno zmieniać zgłaszanego rozmiaru ekranu ani gęstości 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 na urządzeniu:

[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 zawierać obsługę wszystkich odpowiednich zarządzanych interfejsów API i natywnych interfejsów API we wszystkich wersjach OpenGL ES, które zostały wskazane jako obsługiwane.

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

[C-1-1] Musi obsługiwać OpenGL ES 1.1 i 2.0 zgodnie z opisem w dokumentacji pakietu SDK Androida.
[C-SR] MOCNO zalecamy obsługę OpenGL ES 3.1.
NALEŻY obsługiwać OpenGL ES 3.2.

Jeśli implementacje urządzeń obsługują dowolną wersję OpenGL ES, muszą:

[C-2-1] NALEŻY zgłaszać za pomocą interfejsów API zarządzanych OpenGL ES i natywnych interfejsów API wszystkie zaimplementowane rozszerzenia OpenGL ES. Z drugiej strony, NALEŻY NIE zgłaszać ciągów znaków rozszerzenia, 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-SR] MOCNO zalecamy obsługę rozszerzeń EGL_KHR_partial_update i OES_EGL_image_external.
NALEŻY dokładnie podać za pomocą metody getString() dowolny obsługiwany format kompresji tekstur, który jest zwykle specyficzny dla dostawcy.

Jeśli implementacje na urządzeniu deklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2, muszą:

[C-3-1] NALEŻY wyeksportować odpowiadające symbole funkcji dla tych wersji, oprócz symboli funkcji OpenGL ES 2.0 w bibliotece libGLESv2.so.
[SR] MOCNO zalecamy obsługę rozszerzenia OES_EGL_image_external_essl3.

Jeśli implementacje urządzeń obsługują OpenGL ES 3.2, to:

[C-4-1] Aplikacja MUSI obsługiwać cały pakiet rozszerzeń OpenGL ES na Androida.

Jeśli implementacje urządzeń obsługują w pełni pakiet rozszerzeń OpenGL ES na Androida, to:

[C-5-1] MUSISZ wskazać obsługę za pomocą flagi funkcji android.hardware.opengles.aep.

Jeśli implementacje urządzeń obsługują rozszerzenie EGL_KHR_mutable_render_buffer, muszą:

[C-6-1] Musi obsługiwać rozszerzenie EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

Android obsługuje interfejs Vulkan , czyli wieloplatformowy interfejs API o niskim obciążeniu, który umożliwia tworzenie wydajnej grafiki 3D.

Jeśli implementacje na urządzeniu obsługują OpenGL ES 3.1, to:

[SR] ZDECYDOWANIE zaleca się uwzględnienie obsługi Vulkan 1.1.

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

NALEŻY uwzględnić obsługę Vulkan 1.1.

Testy dEQP Vulkan są podzielone na kilka list testów, z których każda ma przypisaną datę lub wersję. Znajdziesz je w drzewie kodu źródłowego Androida na stronie external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Urządzenie, które obsługuje Vulkan na zgłoszonym poziomie, wskazuje, że może przejść testy dEQP na wszystkich listach testów od tego poziomu i starszych.

Jeśli implementacje urządzeń obsługują Vulkan 1.0 lub nowszą wersję, to:

[C-1-1] Musisz podać prawidłową wartość całkowitą z flagami funkcji android.hardware.vulkan.level i android.hardware.vulkan.version.
[C-1-2] MUST enumerate, at least one VkPhysicalDevice for the Vulkan native API vkEnumeratePhysicalDevices() .
[C-1-3] NALEŻY w pełni zaimplementować interfejsy API Vulkan 1.0 dla każdego z wymienionych VkPhysicalDevice.
[C-1-4] NALEŻY wyliczać warstwy zawarte w bibliotekach natywnych o nazwie libVkLayer*.so w katalogu bibliotek natywnych pakietu aplikacji za pomocą interfejsów API Vulkan vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties() .
[C-1-5] NIE wolno wymieniać warstw udostępnianych przez biblioteki spoza pakietu aplikacji ani udostępniać innych sposobów śledzenia lub przechwytywania interfejsu Vulkan API, chyba że aplikacja ma atrybut android:debuggable ustawiony jako true.
[C-1-6] NALEŻY podać wszystkie ciągi znaków rozszerzeń, które są obsługiwane za pomocą natywnych interfejsów API Vulkan, i odwrotnie – NALEŻY NIE podać ciągów znaków rozszerzeń, które nie są obsługiwane prawidłowo.
[C-1-7] Musi obsługiwać rozszerzenia VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain i VK_KHR_incremental_present.
[C-1-8] MUST report the maximum version of the Vulkan dEQP Tests supported via the android.software.vulkan.deqp.level feature flag.
[C-1-9] Musi obsługiwać co najmniej wersję 132317953 (od 1 marca 2019 r.), zgodnie z flagą funkcji android.software.vulkan.deqp.level.
[C-1-10] Musisz przejść wszystkie testy dEQP Vulkana na listach testów w wersjach od 132317953 do wersji określonej w flagach funkcji android.software.vulkan.deqp.level.
[C-SR] MOCNO ZALECAMY obsługę rozszerzeń VK_KHR_driver_properties i VK_GOOGLE_display_timing.

Jeśli implementacje urządzeń nie obsługują Vulkan 1.0, nie:

[C-2-1] NIE NALEŻY deklarować żadnych flag funkcji Vulkana (np. android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] W przypadku interfejsu API natywnego Vulkan vkEnumeratePhysicalDevices() NIE MOŻNA wymieniać żadnych VkPhysicalDevice.

Jeśli implementacje na urządzeniu obejmują obsługę Vulkan 1.1 i deklarują co najmniej 1 flagę funkcji Vulkan, muszą:

[C-3-1] MUSI obsługiwać typy zewnętrznych semantów i uchwytów SYNC_FD oraz rozszerzenie VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

[C-0-1] Implementacje na urządzeniach MUSZĄ obsługiwać Android RenderScript, zgodnie z opisem w dokumentacji pakietu Android SDK.

7.1.4.4 Akceleracja grafiki 2D

Android zawiera mechanizm, który umożliwia aplikacjom oświadczenie o chęci włączenia akceleracji sprzętowej grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku za pomocą tagu manifestu android:hardwareAccelerated lub bezpośrednich wywołań interfejsu API.

Implementacje na urządzeniu:

[C-0-1] NALEŻY włączyć akcelerację sprzętową domyślnie i NALEŻY ją wyłączyć, jeśli deweloper tak zażąda, ustawiając android:hardwareAccelerated="false” lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów Android View API.
[C-0-2] Musi działać zgodnie z dokumentacją pakietu SDK Androida dotyczącą przyspieszania sprzętowego.

Android zawiera obiekt TextureView, który umożliwia deweloperom bezpośrednią integrację tekstur OpenGL ES przyspieszanych sprzętowo jako celów renderowania w hierarchii interfejsu.

Implementacje na urządzeniu:

[C-0-3] MUSI obsługiwać interfejs TextureView API i MUSI zachowywać się zgodnie z implementacją na Androidzie.

7.1.4.5 Wyświetlacze o szerokim zakresie dynamiki

Jeśli implementacje urządzeń obsługują wyświetlacze o szerokim zakresie tonalnym za pomocą Configuration.isScreenWideColorGamut() , muszą:

[C-1-1] Musisz mieć wyświetlacz z kalibracją kolorów.
[C-1-2] Wyświetlacz musi mieć gamę, która całkowicie pokrywa gamę kolorów sRGB w przestrzeni CIE 1931 xyY.
[C-1-3] Musisz mieć wyświetlacz, którego paleta ma obszar co najmniej 90% DCI-P3 w przestrzeni CIE 1931 xyY.
[C-1-4] Musi obsługiwać OpenGL ES 3.1 lub 3.2 i odpowiednio to zgłaszać.
[C-1-5] MUSISZ 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] Zdecydowanie zalecamy obsługę GL_EXT_sRGB.

Jeśli implementacje urządzeń nie obsługują wyświetlaczy o szerokim zakresie, nie mogą:

[C-2-1] POWINIEN obejmować co najmniej 100% przestrzeni sRGB w przestrzeni CIE 1931 xyY, chociaż gama kolorów ekranu jest niezdefiniowana.

7.1.5. Tryb zgodności ze starszymi wersjami aplikacji

Android określa „tryb zgodności”, w którym framework działa w trybie „normalnego” rozmiaru ekranu (szerokość 320 dp) na potrzeby starszych aplikacji, które nie zostały opracowane na potrzeby starszych wersji Androida, które nie obsługują niezależności od rozmiaru ekranu.

7.1.6. Technologia ekranu

Platforma Android zawiera interfejsy API, które umożliwiają aplikacjom renderowanie bogatych grafik na wyświetlaczu zgodnym z Androidem. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zgodnie z definicją w pakiecie SDK Androida, chyba że w tym dokumencie jest to wyraźnie dozwolone.

Wszystkie wyświetlacze zgodne z Androidem w ramach implementacji urządzenia:

[C-0-1] Musi być możliwe renderowanie grafiki w kolorze 16-bitowym.
NALEŻY obsługiwać wyświetlacze obsługujące 24-bitową grafikę kolorową.
[C-0-2] Musi być możliwe renderowanie animacji.
[C-0-3] Współczynnik proporcji pikseli (PAR) MUSI mieścić się 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, aby umożliwić udostępnianie multimediów, oraz interfejsy API dla programistów, które umożliwiają dostęp do wyświetlaczy zewnętrznych.

Jeśli implementacje urządzeń obsługują wyświetlacz zewnętrzny przez połączenie przewodowe, bezprzewodowe lub wbudowane dodatkowe wyświetlacze, muszą:

[C-1-1] NALEŻY zaimplementować usługę systemową DisplayManager i interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK.

7.2. Urządzenia wejściowe

Implementacje na urządzeniu:

[C-0-1] Musisz uwzględnić mechanizm wprowadzania danych, np. ekran dotykowy lub nawigację bezdotykowej, aby poruszać się między elementami interfejsu.

7.2.1. Klawiatura

Jeśli implementacje urządzeń obejmują obsługę zewnętrznych edytorów metody wprowadzania, muszą:

[C-1-1] NALEŻY zadeklarować flagę funkcji android.software.input_methods.
[C-1-2] NALEŻY w pełni wdrożyć Input Management Framework
[C-1-3] Musi być wstępnie zainstalowana klawiatura programowa.

Implementacje na urządzeniu: * [C-0-1] NIE MOŻE zawierać klawiatury sprzętowej, która nie pasuje do jednego z formatów określonych w android.content.res.Configuration.keyboard (QWERTY lub 12 klawiszy). * NALEŻY uwzględnić dodatkowe implementacje klawiatury ekranowej. * MOŻE zawierać klawiaturę sprzętową.

7.2.2. Nawigacja bezdotykowa

Android obsługuje panel kierunkowy, kulkę kierunkową i koło jako mechanizmy nawigacji bezdotykowej.

Implementacje na urządzeniu:

[C-0-1] NALEŻY podać prawidłową wartość dla android.content.res.Configuration.navigation.

Jeśli implementacje na urządzeniach nie obsługują nawigacji bezdotykowej, mogą:

[C-1-1] Musisz zapewnić rozsądny alternatywny mechanizm interfejsu użytkownika do zaznaczania i edytowania tekstu, który jest zgodny z silnikami zarządzania danymi wejściowymi. W upstreamowej implementacji oprogramowania open source na Androida dostępny jest mechanizm wyboru odpowiedni do stosowania na urządzeniach, które nie mają elementów sterujących dotykowych.

7.2.3. Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz są zwykle dostępne po naciśnięciu odpowiedniego przycisku fizycznego lub innej części ekranu dotykowego. Są one niezbędne w ramach paradygmatu nawigacji w Androidzie, a dlatego są też implementowane na urządzeniach:

[C-0-1] Musisz umożliwić użytkownikowi uruchamianie zainstalowanych aplikacji, które mają działanie z wartością <intent-filter> z wartościami ACTION=MAIN i CATEGORY=LAUNCHER lub CATEGORY=LEANBACK_LAUNCHER w przypadku implementacji na telewizorach. Funkcja Home powinna być mechanizmem umożliwiającym użytkownikom korzystanie z tej funkcji.
NALEŻY zapewnić przyciski Ostatnie i Wstecz.

Jeśli dostępne są funkcje ekranu głównego, Ostatnie lub Wstecz, muszą one:

[C-1-1] Musi być możliwe do wykonania jednym działaniem (np. dotknięciem, dwukrotnym kliknięciem lub gestem), gdy którekolwiek z nich jest dostępne.
[C-1-2] Musisz wyraźnie wskazać, które pojedyncze działanie uruchamia każdą funkcję. Przykłady takich wskazówek to widoczna ikona na przycisku, ikona oprogramowania na pasku nawigacyjnym lub szczegółowe instrukcje dla użytkownika podczas konfiguracji.

Implementacje na urządzeniu:

[SR] ZALECAMY, aby nie udostępniać mechanizmu wprowadzania danych w funkcji menu, ponieważ od wersji 4.0 Androida jest on wycofany na rzecz paska czynności.

Jeśli implementacje urządzeń udostępniają funkcję menu, muszą:

[C-2-1] NALEŻY wyświetlić przycisk menu akcji, gdy menu akcji nie jest puste i widoczny jest pasek akcji.
[C-2-2] NIE wolno modyfikować pozycji wyskakującego okienka akcji wyświetlanego po kliknięciu przycisku przepełnienia na pasku akcji, ale można wyświetlić to wyskakujące okienko w zmienionej pozycji na ekranie po kliknięciu funkcji menu.

Jeśli implementacje na urządzeniu nie zapewniają funkcji menu, na potrzeby zgodności wstecznej:

[C-3-1] Funkcja menu MUSI być dostępna w aplikacjach, gdy targetSdkVersion jest mniejsza niż 10, za pomocą przycisku fizycznego, klawisza oprogramowania lub gestów. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacji.

Jeśli implementacje urządzeń obsługują funkcję pomocy:

[C-4-1] Funkcja pomocy musi być dostępna za pomocą pojedynczego działania (np. kliknięcia, podwójnego kliknięcia lub gestu), gdy inne klawisze nawigacyjne są dostępne.
[SR] MOCNO ZALECANA długotrwała aktywacja funkcji ekranu głównego.

Jeśli implementacje urządzeń używają osobnej części ekranu do wyświetlania klawiszy nawigacyjnych, muszą:

[C-5-1] Klawisze nawigacyjne MUSZĄ zajmować osobną część ekranu, niedostępną dla aplikacji, i NIE MOGĄ zasłaniać ani w inny sposób przeszkadzać w obsłudze 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 odpowiednio ukryta zgodnie z dokumentacją pakietu SDK.

Jeśli funkcja nawigacji jest obsługiwana jako działanie na ekranie oparte na gestach:

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() należy używać tylko do raportowania obszaru rozpoznawania gestu Home.
[C-6-2] Gesty, które rozpoczynają się w prostokącie wykluczenia udostępnionym przez aplikację na pierwszym planie za pomocą interfejsu View#setSystemGestureExclusionRects(), ale poza obszarem WindowInsets#getMandatorySystemGestureInsets(), NIE POWINNY być przechwytywane przez funkcję nawigacji, o ile prostokąt wykluczenia jest dozwolony w ramach maksymalnego limitu wykluczenia określonego w dokumentacji do interfejsu View#setSystemGestureExclusionRects().
[C-6-3] Gdy aplikacja na pierwszym planie otrzyma zdarzenie MotionEvent.ACTION_CANCEL, musi wysłać zdarzenie MotionEvent.ACTION_DOWN, gdy wykryje dotknięcia przechwycone przez gest systemowy.
[C-6-4] NALEŻY zapewnić użytkownikowi możliwość przełączenia się na ekranową nawigację opartą na przyciskach (np. w Ustawieniach).
NALEŻY zapewnić funkcję ekranu głównego jako przesunięcie palcem od dołu ekranu w bieżącym ułożeniu.
NALEŻY udostępnić funkcję Ostatnie jako gest przesunięcia w górę i przytrzymania przed zwalnieniem, z tego samego obszaru co gest powrotu do ekranu głównego.
Gesty, które zaczynają się w aplikacji WindowInsets#getMandatorySystemGestureInsets(), NIE powinny być blokowane przez prostokąty wykluczenia udostępniane przez aplikację na pierwszym planie za pomocą View#setSystemGestureExclusionRects().

Jeśli funkcja nawigacji jest dostępna w dowolnym miejscu po lewej i po prawej stronie w zależności od bieżącej orientacji ekranu:

[C-7-1] Funkcja nawigacji MUSI być funkcją Wstecz i musi być dostępna przez przesunięcie palcem od lewej i prawej krawędzi ekranu w zależności od bieżącej orientacji ekranu.
[C-7-2] Jeśli po lewej lub prawej stronie ekranu dostępne są niestandardowe panele systemowe, które można przesuwać, muszą one znajdować się w górnej 1/3 ekranu. Muszą też być wyraźnie oznaczone wizualnie, aby użytkownik wiedział, że przesunięcie palcem spowoduje wyświetlenie wspomnianych paneli, a nie przycisku Wstecz. Panel systemowy MOŻE zostać 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 lub View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, przesuwanie palcem od krawędzi MUSI działać tak, jak w AOSP, zgodnie z dokumentacją pakietu SDK.
[C-7-4] Jeśli aplikacja na pierwszym planie ma ustawione flagi View.SYSTEM_UI_FLAG_IMMERSIVE lub View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, niestandardowe panele systemowe, które można przesuwać, MUSZĄ być ukryte, dopóki użytkownik nie wyświetli pasków systemowych (czyli paska nawigacyjnego i paska stanu) zgodnie z implementacją w AOSP.

7.2.4. Dotykowe wprowadzanie danych

Android obsługuje różne systemy wskaźników, takie jak ekrany dotykowe, panele dotykowe i urządzenia dotykowe z fałszywym dotykiem. Implementacje urządzeń z ekranem dotykowym są powiązane z ekranem w taki sposób, aby użytkownik miał wrażenie bezpośredniej manipulacji elementami na ekranie. Ponieważ użytkownik dotyka ekranu bezpośrednio, system nie wymaga żadnych dodatkowych elementów, które wskazywałyby na obiekty, którymi można manipulować.

Implementacje na urządzeniu:

POWINIEN zawierać system sterowania za pomocą wskaźnika (podobny do myszy lub dotykowy).
NALEŻY obsługiwać wskaźniki śledzone niezależnie.

Jeśli implementacje urządzeń obejmują ekran dotykowy (jednodotykowy lub lepszy) na głównym ekranie zgodnym z Androidem, muszą:

[C-1-1] W polu interfejsu API Configuration.touchscreen musisz podać wartość TOUCHSCREEN_FINGER.
[C-1-2] MUST report the android.hardware.touchscreen and android.hardware.faketouch feature flags.

Jeśli implementacje urządzeń obejmują ekran dotykowy, który może śledzić więcej niż jedno dotknięcie na głównym ekranie zgodnym z Androidem, muszą:

[C-2-1] NALEŻY podać 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 kulka optyczna (czyli nie dotykasz bezpośrednio ekranu), do wprowadzania danych na głównym ekranie zgodnym z Androidem i spełniają wymagania dotyczące fałszywych dotknięć podane w sekcji 7.2.5, to:

[C-3-1] NIE MOŻESZ zgłaszać żadnej flagi funkcji, która zaczyna się od android.hardware.touchscreen.
[C-3-2] MUST report only android.hardware.faketouch.
[C-3-3] W polu interfejsu API Configuration.touchscreen MUSISZ podać wartość TOUCHSCREEN_NOTOUCH.

7.2.5. Symulowane dotykowe wprowadzanie danych

Symulowany interfejs dotykowy udostępnia system wprowadzania danych użytkownika, który w przybliżeniu odwzorowuje możliwości ekranu dotykowego. Na przykład mysz lub pilot, który steruje kursorem na ekranie, naśladuje dotyk, ale wymaga od użytkownika najpierw wskazania lub skupienia się na obiekcie, a potem kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, mysz powietrzna z żyroskopem, wskaźnik z żyroskopem, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe. Android zawiera stałą android.hardware.faketouch, która odpowiada urządzeniu do wprowadzania danych niebędącemu urządzeniem dotykowym (z wskaźnikiem), np. myszce lub trackpadowi, które może emulować wprowadzanie danych za pomocą ekranu dotykowego (w tym podstawowe gesty) i wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.

Jeśli implementacje urządzeń nie obejmują ekranu dotykowego, ale zawierają inny system wskaźnika, który chcą udostępnić, muszą:

NALEŻY zadeklarować obsługę flagi funkcji android.hardware.faketouch.

Jeśli implementacje na urządzeniach deklarują obsługę android.hardware.faketouch, muszą:

[C-1-1] MUSI raportować absolutne pozycje X i Y na ekranie wskaźnika oraz wyświetlać na ekranie wizualny wskaźnik.
[C-1-2] NALEŻY zgłaszać zdarzenie dotyku z kodem działania, który określa stan zmiany, jaka zachodzi w wskaźniku przemieszczającym się w dół lub w górę po ekranie.
[C-1-3] Musi obsługiwać kursor w dół i w górę na obiekcie na ekranie, co pozwala użytkownikom emulować kliknięcie obiektu na ekranie.
[C-1-4] MUSI obsługiwać ruchy kursora w dół, w górę, w dół i znów w górę w tym samym miejscu na ekranie w ramach określonego progu czasowego, co pozwala użytkownikom emulować dwukrotne kliknięcie obiektu na ekranie.
[C-1-5] MUSI obsługiwać wciśnięcie wskaźnika w dowolnym miejscu na ekranie, przesuwanie wskaźnika do dowolnego innego miejsca na ekranie, a następnie zwolnienie wskaźnika, co pozwala użytkownikom emulować przeciąganie palcem.
[C-1-6] MUSI obsługiwać wskaźnik w dół, a następnie musi umożliwiać użytkownikom szybkie przenoszenie obiektu w inne miejsce na ekranie, a następnie wskaźnik w górę na ekranie, co pozwala użytkownikom rzucać obiektem na ekranie.

Jeśli implementacje na urządzeniach deklarują obsługę android.hardware.faketouch.multitouch.distinct, muszą:

[C-2-1] MUST declare support for android.hardware.faketouch.
[C-2-2] MUSI obsługiwać oddzielne śledzenie co najmniej 2 niezależnych wejść wskaźnika.

Jeśli implementacje na urządzeniach deklarują obsługę android.hardware.faketouch.multitouch.jazzhand, muszą:

[C-3-1] MUSISZ zadeklarować obsługę android.hardware.faketouch.
[C-3-2] Musi obsługiwać oddzielne śledzenie co najmniej 5 (śledzenie ręki z palcami) lub więcej urządzeń wskazujących w pełni niezależnie.

7.2.6. Obsługa kontrolera gier

7.2.6.1. Mapowania przycisków

Implementacje na urządzeniu:

[C-1-1] MUSI być możliwe mapowanie zdarzeń HID na odpowiadające im stałe InputEvent wymienione w tabelach poniżej. Wyższa implementacja Androida spełnia to wymaganie.

Jeśli implementacje urządzeń zawierają kontroler lub są dostarczane z oddzielnym kontrolerem, który umożliwia wprowadzanie wszystkich zdarzeń wymienionych w tabeli poniżej, muszą:

[C-2-1] NALEŻY zadeklarować flagę funkcji android.hardware.gamepad

Przycisk	Użycie HID²	Przycisk na Androida
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Przycisk w górę na padzie kierunkowym¹ Przycisk w dół na padzie kierunkowym¹	0x01 0x0039³	AXIS_HAT_Y⁴
Przycisk w lewo na padzie kierunkowym1 Przycisk w prawo na padzie kierunkowym¹	0x01 0x0039³	AXIS_HAT_X⁴
Przycisk lewego uchwytu¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Przycisk na prawym uchwycie¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Kliknięcie lewej gałki¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Kliknięcie prawego drążka¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Strona główna¹	0x0c 0x0223	KEYCODE_HOME (3)
Wstecz¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Powyższe zastosowania HID muszą być zadeklarowane w ramach CA kontrolera do gier (0x01 0x0005).

3 Ta wartość musi mieć minimalną wartość logiczną 0, maksymalną wartość logiczną 7, minimalną wartość fizyczną 0, maksymalną wartość fizyczną 315, jednostki w stopniach oraz rozmiar raportu 4. Wartość logiczna jest zdefiniowana jako obrót zgodnie z ruchem wskazówek zegara od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i wciśnięcie przycisku w górę, a wartość logiczna 1 oznacza obrót o 45° i wciśnięcie przycisków w górę i w lewo.

4. MotionEvent

Analog Controls¹	Użycie HID	Przycisk na Androida
Lepiej:	0x02 0x00C5	AXIS_LTRIGGER
Prawy spust	0x02 0x00C4	AXIS_RTRIGGER
Lewy joystick	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Prawy joystick	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Pilot

Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.3.1.

7.3. Czujniki

Jeśli implementacja urządzenia zawiera określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów innych firm, implementacja urządzenia MUSI implementować ten interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK i dokumentacji Androida Open Source dotyczącej czujników.

Implementacje na urządzeniu:

[C-0-1] Musisz dokładnie podać 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ą metod SensorManager.getSensorList() i podobnych.
[C-0-3] Musi działać prawidłowo w przypadku wszystkich innych interfejsów API czujników (np. zwracać true lub false w odpowiednich przypadkach, gdy aplikacje próbują zarejestrować słuchaczy, nie wywoływać słuchaczy czujników, gdy odpowiednie czujniki są nieobecne itp.).

Jeśli implementacje urządzeń obejmują określony typ czujnika z odpowiednim interfejsem API dla deweloperów zewnętrznych, mogą one:

[C-1-1] Zgłoszenia wszystkich pomiarów czujników muszą być dokonywane z użyciem odpowiednich wartości z Międzynarodowego Systemu Jednostek (metrycznych) dla każdego typu czujnika zgodnie z definicją w dokumentacji Android SDK.
[C-1-2] W przypadku strumienia danych z czujnika z maksymalnie żądaną latencją 0 ms, gdy aktywny jest procesor aplikacji, MUSI raportować dane z czujnika z maksymalnie 100 ms opóźnienia + 2 * sample_time. To opóźnienie nie obejmuje opóźnień związanych z filtrowaniem.
[C-1-3] NALEŻY zgłaszać pierwszą próbkę czujnika w ciągu 400 milisekund + 2 * sample_time od momentu aktywacji czujnika. W przypadku tej próbki dopuszczalna jest dokładność 0.
[C-1-4] W przypadku interfejsów API oznaczonych w dokumentacji pakietu SDK Androida jako ciągły czujnik implementacje na urządzeniu MUSZĄ stale dostarczać okresowych próbek danych, których jitter (zdefiniowany jako odchylenie standardowe różnicy wartości raportowanych sygnałów czasowych między kolejnymi zdarzeniami) powinien być mniejszy niż 3%.
[C-1-5] NALEŻY zadbać o to, aby strumień zdarzeń z czujników NIE PRZESZKADZAŁ procesorowi w wejściu w stan zawieszenia ani w wybudzeniu z tego stanu.
[C-1-6] Zdarzenie musi podawać czas w nanosekundach zgodnie z definicją w dokumentacji pakietu SDK Androida. Czas ten musi odpowiadać czasowi zdarzeniu i być zsynchronizowany z zegarami SystemClock.elapsedRealtimeNano().
[C-SR] Zaleca się, aby błąd synchronizacji sygnatury czasowej był mniejszy niż 100 milisekund, a błąd synchronizacji sygnatury czasowej powinien być mniejszy niż 1 milisekunda.
Gdy aktywowanych jest kilka czujników, zużycie energii NIE POWINNA przekraczać sumy zużycia energii poszczególnych czujników.

Powyższa lista nie jest wyczerpująca. Należy wziąć pod uwagę udokumentowane działanie pakietu Android SDK i dokumentację na temat czujników w dokumentacji do Androida w wersji open source.

Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, deweloperzy:

[C-1-6] NALEŻY ustawić niezerową rozdzielczość dla wszystkich czujników i przekazać wartość za pomocą metody interfejsu API Sensor.getResolution().

Niektóre typy czujników są złożone, co oznacza, że mogą być wyprowadzone z danych pochodzących z co najmniej jednego innego czujnika. (np. czujnik orientacji i czujnik przyspieszenia liniowego).

Implementacje na urządzeniu:

NALEŻY zaimplementować te typy czujników, jeśli zawierają one wymagane czujniki fizyczne opisane w sekcji Typy czujników.

Jeśli implementacje urządzeń obejmują czujnik złożony, muszą:

[C-2-1] NALEŻY zaimplementować czujnik zgodnie z opisem w dokumentacji dotyczącej złożonych czujników w systemie Android Open Source.

Jeśli implementacje na urządzeniu obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, a czujnik raportuje tylko jedną wartość, implementacje na urządzeniu:

[C-3-1] NALEŻY ustawić rozdzielczość na 1 dla czujnika i przekazać wartość za pomocą metody interfejsu API Sensor.getResolution().

Jeśli implementacje urządzeń zawierają określony typ czujnika, który obsługuje SensorAdditionalInfo#TYPE_VEC3_CALIBRATION, a czujnik jest udostępniony deweloperom zewnętrznym, mogą oni:

[C-4-1] W dostarczonych danych NIE MOŻE być stałych, fabrycznie określonych parametrów kalibracji.

Jeśli implementacje urządzeń zawierają kombinację 3-osiowego akcelerometru, 3-osiowego czujnika żyroskopowego lub czujnika magnetycznego, są:

[C-SR] ZALECAMY, aby akcelerometr, żyroskop i magnetometr miały stałą pozycję względną, tak aby w przypadku urządzenia z możliwością zmiany kształtu (np. składanego) osie czujników były wyrównane i zgodne z systemem współrzędnych czujnika we wszystkich możliwych stanach transformacji urządzenia.

7.3.1. Akcelerometr

Implementacje na urządzeniu:

[C-SR] Zdecydowanie zalecamy dodanie 3-osiowego akcelerometru.

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

[C-1-1] Musi być możliwe raportowanie zdarzeń z częstotliwością co najmniej 50 Hz.
[C-1-2] MUSISZ wdrożyć i zgłosić czujnik TYPE_ACCELEROMETER.
[C-1-3] MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida.
[C-1-4] MUSI być w stanie mierzyć od swobodnego spadania do 4 razy większej siły grawitacji(4 g) lub więcej na dowolnej osi.
[C-1-5] Rozdzielczość musi wynosić co najmniej 12 bitów.
[C-1-6] Musisz mieć odchylenie standardowe nie większe niż 0,05 m/s2, gdzie odchylenie standardowe powinno być obliczone dla każdej osi na podstawie próbek zebranych w ciągu co najmniej 3 sekund z najwyższą częstotliwością próbkowania.
[SR] MOCNO POLECAMY implementację złożonego czujnika TYPE_SIGNIFICANT_MOTION.
[SR] ZALECAMY Z MOCĄ zaimplementowanie i raportowanie czujnika TYPE_ACCELEROMETER_UNCALIBRATED. Zalecamy, aby urządzenia z Androidem spełniały to wymaganie, ponieważ w przyszłości może ono stać się wymagane.
NALEŻY zaimplementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER zgodnie z opisem w dokumentacji pakietu Android SDK.
Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.
Rozdzielczość powinna wynosić co najmniej 16 bitów.
NALEŻY je kalibrować podczas użytkowania, jeśli ich właściwości zmieniają się w trakcie cyklu życia, oraz zachować parametry kompensacji między ponownymi uruchamianiami urządzenia.
POWINIEN być kompensowany temperaturowo.

Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr i dowolny z sensorów złożonych TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER:

[C-2-1] Łączna wartość zużycia energii MUSI być zawsze mniejsza niż 4 mW.
Wartości te powinny być niższe niż 2 mW i 0,5 mW, gdy urządzenie jest w stanie dynamicznym lub stałym.

Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr i 3-osiowy żyroskop, muszą:

[C-3-1] OBOWIĄZKOWO wdrożyć czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
[C-SR] Zdecydowanie zalecamy wdrożenie złożonego czujnika TYPE_GAME_ROTATION_VECTOR.

Jeśli implementacje urządzenia obejmują 3-osiowy akcelerometr, 3-osiowy czujnik żyroskopowy i czujnik magnetyczny, muszą:

[C-4-1] MUSISZ zastosować czujnik złożony TYPE_ROTATION_VECTOR.

7.3.2. Magnetometr

Implementacje na urządzeniu:

[C-SR] Zdecydowanie zalecamy uwzględnienie 3-osiowego magnetometru (kompasu).

Jeśli implementacje urządzeń obejmują 3-osiowy magnetometr, muszą:

[C-1-1] MUSISZ zaimplementować czujnik TYPE_MAGNETIC_FIELD.
[C-1-2] Musi być możliwe raportowanie zdarzeń z częstotliwością co najmniej 10 Hz i należy raportować zdarzenia z częstotliwością co najmniej 50 Hz.
[C-1-3] MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida.
[C-1-4] MUSI być w stanie mierzyć wartości od -900 µT do +900 µT na każdej osi przed nasyceniem.
[C-1-5] Wartość przesunięcia pola magnetycznego stałego żelaza MUSI być mniejsza niż 700 µT, a WARTO, aby była mniejsza niż 200 µT. Aby to osiągnąć, należy umieścić magnetometr z dala od pól magnetycznych dynamicznych (wywołanych przez prąd) i statycznych (wywołanych przez magnes).
[C-1-6] Rozdzielczość musi być równa lub większa niż 0,6 µT.
[C-1-7] MUSI obsługiwać kalibrację online i kompensację błędów na poziomie sprzętowym oraz zachowywać parametry kompensacji po ponownym uruchomieniu urządzenia.
[C-1-8] NALEŻY zastosować 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 ciągu co najmniej 3 sekund z najwyższą częstotliwością próbkowania nie większą niż 1, 5 µT; powinno mieć odchylenie standardowe nie większe niż 0, 5 µT.
[C-SR] Zdecydowanie zalecamy wdrożenie czujnika TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Jeśli implementacje urządzeń zawierają 3-osiowy magnetometr, akcelerometr i 3-osiowy żyroskop, muszą:

[C-2-1] MUSISZ zastosować czujnik złożony TYPE_ROTATION_VECTOR.

Jeśli implementacje urządzeń obejmują 3-osiowy magnetometr i akcelerometr, muszą:

MOŻE implementować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Jeśli implementacje urządzenia zawierają 3-osiowy magnetometr, akcelerometr i czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR, to:

[C-3-1] MUSI zużywać mniej niż 10 mW.
Powinien zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie zbiorczym z częstotliwością 10 Hz.

7.3.3. GPS

Implementacje na urządzeniu:

[C-SR] Zdecydowanie zalecamy dodanie odbiornika 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 położenia z częstotliwością co najmniej 1 Hz, gdy zostanie o to poproszono za pomocą LocationManager#requestLocationUpdate.
[C-1-2] Musi być w stanie określić lokalizację w warunkach otwartego nieba (silne sygnały, pomiar multipath nieistotny, HDOP < 2) w ciągu 10 sekund (szybki czas do pierwszego wyznaczenia pozycji) po połączeniu z internetem o szybkości co najmniej 0,5 Mb/s. Wymaganie to jest zwykle spełnione przez użycie jakiejś formy wspomaganego lub przewidywanego GPS-a/GNSS w celu zminimalizowania czasu ustalania pozycji przez GPS-a/GNSS (dane wspomagania obejmują czas odniesienia, lokalizację odniesienia i ephemeridy satelity/zegar).
- [C-1-6] Po obliczeniu lokalizacji implementacje urządzeń MUSZĄ określić lokalizację na otwartym niebie w ciągu 5 sekund od ponownego uruchomienia żądań lokalizacji, maksymalnie do godziny od początkowego obliczenia lokalizacji, nawet jeśli kolejne żądanie zostanie wysłane bez połączenia danych lub po wyłączeniu i ponownie włączeniu urządzenia.
W warunkach otwartego nieba po określeniu lokalizacji, podczas postoju lub poruszania się z przyspieszeniem poniżej 1 metra na sekundę kwadratową:
- [C-1-3] W co najmniej 95% czasu urządzenie MUSI być w stanie określić lokalizację z dokładnością do 20 metrów, a szybkość z dokładnością do 0, 5 metra na sekundę.
- [C-1-4] MUSI jednocześnie śledzić i przekazywać informacje za pomocą GnssStatus.Callback co najmniej 8 satelitów z jednej konstelacji.
- POWINNA być w stanie śledzić jednocześnie co najmniej 24 satelity z różnych konstelacji (np. GPS + co najmniej jeden z Glonas, Beidou, Galileo).
- [C-SR] MOCNO ZALECAMY, aby podczas połączenia alarmowego nadal dostarczać normalne dane wyjściowe lokalizacji GPS/GNSS za pomocą interfejsu API dostawcy lokalizacji GNSS.
- [C-SR] MOCNO zalecamy raportowanie pomiarów GNSS ze wszystkich śledzonych konstelacji (jak podano w wiadomościach GnssStatus), z wyjątkiem SBAS.
- [C-SR] MOCNO zalecamy raportowanie AGC i częstości pomiaru GNSS.
- [C-SR] MOCNO POLECAMY raportowanie wszystkich szacunków dokładności (w tym kierunku, prędkości i pionowości) w ramach każdej lokalizacji GPS/GNSS.
- [C-SR] MOCNO zalecamy zgłaszanie pomiarów GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie danych z GPS/GNSS nie została jeszcze zgłoszona.
- [C-SR] MOCNO zaleca się zgłaszanie pseudozakresów i pseudozakresów GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, w stanie spoczynku lub w ruchu z przyspieszeniem poniżej 0,2 metra na sekundę kwadratową, wystarczają do obliczenia pozycji z dokładnością do 20 metrów i prędkości z dokładnością do 0,2 metra na sekundę w co najmniej 95% czasu.

7.3.4. Żyroskop

Implementacje na urządzeniu:

[C-SR] Zdecydowanie zalecamy dodanie czujnika żyroskopu.

Jeśli implementacja urządzenia obejmuje 3-osiowy żyroskop:

[C-1-1] Musi być możliwe raportowanie zdarzeń z częstotliwością co najmniej 50 Hz.
[C-1-2] NALEŻY zaimplementować czujnik TYPE_GYROSCOPE. BARDZO ZALECAMY też wdrożenie czujnika TYPE_GYROSCOPE_UNCALIBRATED.
[C-1-4] Rozdzielczość musi wynosić co najmniej 12 bitów, a najlepiej 16 bitów.
[C-1-5] MUSI być z kompensacją temperatury.
[C-1-6] MUSI być skalibrowany i skompensowany podczas użytkowania oraz zachowywać parametry kompensacji po ponownym uruchomieniu urządzenia.
[C-1-7] Wariancja musi być mniejsza niż 1e-7 rad^2 / s^2 na Hz (wartość na Hz lub rad^2 / s). Wartość odchylenia może się zmieniać wraz z częstotliwością próbkowania, ale MUSI być ograniczona do tej wartości. Inaczej mówiąc, jeśli zmierzymy odchylenie standardowe żyroskopu przy częstotliwości próbkowania 1 Hz, nie powinno ono przekraczać 1e-7 rad^2/s^2.
[SR] Błąd kalibracji powinien być mniejszy niż 0,01 rad/s, gdy urządzenie jest nieruchome w temperaturze pokojowej.
Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.

Jeśli implementacje urządzenia obejmują 3-osiowy żyroskop, akcelerometr i magnetometr, muszą:

[C-2-1] MUSISZ zastosować czujnik złożony TYPE_ROTATION_VECTOR.

Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr i 3-osiowy żyroskop, muszą:

[C-3-1] OBOWIĄZKOWO wdrożyć czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
[C-SR] Zdecydowanie zalecamy wdrożenie czujnika złożonego TYPE_GAME_ROTATION_VECTOR.

7.3.5. barometr;

Implementacje na urządzeniu:

[C-SR] MOCNO zalecamy uwzględnienie barometru (czujnika ciśnienia otoczenia).

Jeśli implementacja urządzenia zawiera barometr, musi:

[C-1-1] MUSISZ wdrożyć i zgłosić czujnik TYPE_PRESSURE.
[C-1-2] MUSI być w stanie przesyłać zdarzenia z częstotliwością co najmniej 5 Hz.
[C-1-3] MUSI być z kompensacją temperatury.
[SR] ZALECAMY, aby urządzenie mogło raportować pomiary ciśnienia w zakresie 300–1100 hPa.
Powinien mieć bezwzględną dokładność 1 hPa.
POWINIEN mieć dokładność względną 0,12 hPa w zakresie 20 hPa (co odpowiada dokładności około 1 m przy zmianie wysokości około 200 m nad poziomem morza).

7.3.6. Thermometer

Jeśli implementacje urządzeń zawierają termometr otoczenia (czujnik temperatury), muszą:

[C-1-1] MUSI definiować SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury otoczenia, a czujnik MUSI mierzyć temperaturę otoczenia (w pomieszczeniu lub kabinie pojazdu) z miejsca, w którym użytkownik wchodzi w interakcję z urządzeniem, w stopniach Celsjusza.

Jeśli implementacje urządzeń zawierają czujnik temperatury, który mierzy temperaturę inną niż temperatura otoczenia, np. temperaturę procesora, muszą:

[C-2-1] NIE NALEŻY definiować SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury.

7.3.7. Fotometr

Implementacje urządzeń MOGĄ zawierać fotometr (czujnik jasności otoczenia).

7.3.8. Czujnik zbliżeniowy

Urządzenia mogą być wyposażone w czujnik zbliżeniowy.

Jeśli implementacja urządzenia obejmuje czujnik zbliżeniowy, urządzenie:

[C-1-1] NALEŻY mierzyć odległość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI być zorientowany tak, aby wykrywać obiekty w pobliżu ekranu, ponieważ głównym celem tego typu czujnika jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy w dowolnej innej orientacji, nie może być on dostępny za pomocą tego interfejsu API.
[C-1-2] Musi mieć co najmniej 1 bita dokładności.

7.3.9. Czujniki o wysokiej wierności

Jeśli implementacje urządzeń zawierają zestaw czujników o wyższej jakości, zgodnie z definicją w tej sekcji, i są dostępne dla aplikacji innych firm, muszą:

[C-1-1] Identyfikator musi być podany za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

Jeśli implementacje na urządzeniu deklarują android.hardware.sensor.hifi_sensors, to:

[C-2-1] Musi zawierać czujnik TYPE_ACCELEROMETER, który:
- Zakres pomiarowy musi wynosić co najmniej -8 g do +8 g. BARDZO ZALECAMY, aby zakres pomiarowy wynosił co najmniej -16 g do +16 g.
- Rozdzielczość pomiaru MUSI wynosić co najmniej 2048 LSB/g.
- Częstotliwość pomiaru musi wynosić co najmniej 12,5 Hz.
- Musi mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz. Zaleca się obsługę interfejsu SensorDirectChannel RATE_VERY_FAST.
- Szum pomiarowy nie może przekraczać 400 μg/√Hz.
- MUSI implementować niebudzącą formę tego czujnika z możliwością buforowania co najmniej 3000 zdarzeń czujnika.
- Musisz mieć ustawienie poboru mocy w ramach przetwarzania w partiach nie większe niż 3 mW.
- [C-SR] MOCNO zaleca się, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a spektr szumu białego mieścił się w tym paśmie.
- Przyspieszenie powinno być mniejsze niż 30 μg √Hz przy temperaturze pokojowej.
- Zmiana stycznej w zależności od temperatury powinna wynosić ≤ +/- 1 mg/°C.
- USTAWIĆ nieliniowości linii dopasowania najlepszego do danych na poziomie ≤ 0,5% oraz zmianę czułości w zależności od temperatury na poziomie ≤ 0,03%/°C.
- W zakresie temperatury pracy urządzenia czułość na osi poprzecznej powinna wynosić mniej niż 2,5%, a jej zmienność – mniej niż 0,2%.
[C-2-2] Musisz mieć TYPE_ACCELEROMETER_UNCALIBRATED, który spełnia te same wymagania dotyczące jakości co TYPE_ACCELEROMETER.
[C-2-3] MUSI zawierać czujnik TYPE_GYROSCOPE, który:
- Zakres pomiarowy musi wynosić co najmniej -1000 do +1000 dps.
- Rozdzielczość pomiaru MUSI wynosić co najmniej 16 LSB/dps.
- Częstotliwość pomiaru musi wynosić co najmniej 12,5 Hz.
- Musi mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz. NALEŻY obsługiwać interfejs SensorDirectChannel RATE_VERY_FAST.
- Szum pomiarowy nie może być większy niż 0,014°/s/√Hz.
- [C-SR] MOCNO ZALECAMY, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a spektr szumu białego mieścił się w tym paśmie.
- W temperaturze pokojowej szybkość losowego spaceru powinna wynosić mniej niż 0,001 °/s √Hz.
- Zmiana przesunięcia względem temperatury powinna wynosić ≤ +/- 0,05°/ s / °C.
- Zmiana czułości w zależności od temperatury powinna wynosić ≤ 0,02% / °C.
- Współczynnik nieliniowości linii najlepszego dopasowania powinien wynosić ≤ 0,2%.
- gęstość szumów powinna wynosić ≤ 0,007 °/s/√Hz;
- Błąd kalibracji powinien być mniejszy niż 0,002 rad/s w zakresie temperatury 10–40 °C, gdy urządzenie jest nieruchome.
- Czułość na przyspieszenie powinna być mniejsza niż 0,1°/s/g.
- W zakresie temperatury pracy urządzenia czułość na osi poprzecznej powinna wynosić < 4,0%, a jej zmienność < 0,3%.
[C-2-4] Musisz mieć TYPE_GYROSCOPE_UNCALIBRATED, który spełnia te same wymagania dotyczące jakości co TYPE_GYROSCOPE.
[C-2-5] MUSI zawierać czujnik TYPE_GEOMAGNETIC_FIELD, który:
- Zakres pomiarowy musi wynosić co najmniej -900 do +900 μT.
- Rozdzielczość pomiaru musi wynosić co najmniej 5 LSB/uT.
- Częstotliwość pomiaru MUSI wynosić co najmniej 5 Hz.
- Maksymalna częstotliwość pomiaru musi wynosić co najmniej 50 Hz.
- Szum pomiarowy nie może być większy niż 0,5 uT.
[C-2-6] Musisz mieć TYPE_MAGNETIC_FIELD_UNCALIBRATED, który spełnia te same wymagania dotyczące jakości co TYPE_GEOMAGNETIC_FIELD, a dodatkowo:
- NALEŻY wdrożyć niebudzącą formę tego czujnika z możliwością buforowania co najmniej 600 zdarzeń czujnika.
- [C-SR] MOCNO ZALECAMY stosowanie widma szumu białego w zakresie 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:
- Zakres pomiarowy musi wynosić co najmniej 300–1100 hPa.
- Musi mieć rozdzielczość pomiaru co najmniej 80 LSB/hPa.
- Częstotliwość pomiaru MUSI wynosić co najmniej 1 Hz.
- Maksymalna częstotliwość pomiaru musi wynosić co najmniej 10 Hz.
- Szum pomiarowy nie może przekraczać 2 Pa/√Hz.
- MUSI implementować niebudzącą formę tego czujnika z możliwością buforowania co najmniej 300 zdarzeń czujnika.
- Musisz mieć ustawienie poboru mocy w trybie zbiorczym nieprzekraczające 2 mW.
[C-2-8] MUSI mieć czujnik TYPE_GAME_ROTATION_VECTOR.
[C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:
- Musi zużywać nie więcej niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
[C-2-10] MUSI mieć czujnik TYPE_STEP_DETECTOR, który:
- NALEŻY wdrożyć niebudzącą formę tego czujnika z możliwością buforowania co najmniej 100 zdarzeń czujnika.
- Musi zużywać nie więcej niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
- Musi zużywać nie więcej niż 4 mW energii podczas przetwarzania w grupach.
[C-2-11] MUSI mieć czujnik TYPE_STEP_COUNTER, który:
- Musi zużywać nie więcej niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
[C-2-12] MUSI mieć czujnik TILT_DETECTOR, który:
- Musisz mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
[C-2-13] Czas stempla zdarzeń tego samego zdarzenia fizycznego zarejestrowanego przez akcelerometr, żyroskop i magnetometr MUSI mieścić się w zakresie 2, 5 ms. Sygnatura czasowa zdarzenia zarejestrowanego przez akcelerometr i żyroskop w ramach tego samego zdarzenia fizycznego POWINNA mieścić się w zakresie 0,25 ms.
[C-2-14] Musisz mieć sygnatury czasowe zdarzeń czujnika żyroskopu oparte na tej samej podstawie czasowej co podsystem kamery i z dokładnością do 1 milisekundy.
[C-2-15] NALEŻY przesyłać próbki do aplikacji w ciągu 5 milisekund od momentu, gdy dane są dostępne na dowolnym z wymienionych powyżej czujników fizycznych.
[C-2-16] Podczas korzystania z dowolnej kombinacji tych czujników: zużycie energii nie może być większe niż 0,5 mW w stanie spoczynku i 2,0 mW w ruchu:
- 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ć co najmniej 100 miejsc na dane w buforze.

Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje to moc pobieraną przez cały łańcuch czujników: czujnik, wszelkie układy pomocnicze, dedykowany system przetwarzania czujników itp.

Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników, urządzenia te:

[C-3-1] NALEŻY prawidłowo zadeklarować obsługę typów kanałów bezpośrednich i poziomu stawek raportowania bezpośredniego za pomocą interfejsu API isDirectChannelTypeSupported i getHighestDirectReportRateLevel.
[C-3-2] Musi obsługiwać co najmniej 1 z 2 typów bezpośredniego kanału czujnika we wszystkich czujnikach, które deklarują obsługę bezpośredniego kanału czujnika.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
Powinien obsługiwać raportowanie zdarzeń za pomocą kanału bezpośredniego czujnika w przypadku głównego czujnika (wersja nieobsługująca funkcji budzenia) o tych typach:
- 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 pomiarach bezpieczeństwa odblokowywania biometrycznego znajdziesz w dokumentacji pomiaru bezpieczeństwa zabezpieczeń biometrycznych.

Jeśli implementacje urządzeń obejmują zabezpieczony ekran blokady, muszą:

NALEŻY użyć czujnika biometrycznego

Czujniki biometryczne można zaklasyfikować jako klasę 3 (dawniej silną), klasę 2 (dawniej słabą) lub klasę 1 (dawniej wygodną) na podstawie ich współczynników akceptacji podróbek i podwójnych kont oraz bezpieczeństwa systemu biometrycznego. Ta klasyfikacja określa możliwości interfejsu czujnika biometrycznego w połączeniu z platformą i aplikacjami firm zewnętrznych. Sensory są domyślnie klasyfikowane jako klasa 1 i muszą spełniać dodatkowe wymagania opisane poniżej, aby można je było zaklasyfikować jako klasa 2 lub klasa 3. Zarówno klasa 2, jak i klasa 3 danych biometrycznych zyskują dodatkowe możliwości, opisane 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 drugiej strony nie wolno honorować ani rozpoznawać stałych liczb całkowitych przekazywanych do metod canAuthenticate(int) i setAllowedAuthenticators(int) innych niż te, które są udokumentowane jako stałe publiczne w Authenticators i ich kombinacje.
[C-4-3] NALEŻY zaimplementować działanie ACTION_BIOMETRIC_ENROLL na urządzeniach z usługą Class 3 lub Class 2. To działanie MUSI zawierać tylko punkty rejestracji dla klasy 3 lub klasy 2.

Jeśli implementacje urządzeń obsługują biometryczne dane biometryczne, muszą:

[C-5-1] Domyślnie musi być wymagany dodatkowy krok potwierdzenia (np. naciśnięcie przycisku).
[C-SR] MOCNO ZALECAMY, aby ustawić opcję umożliwiającą użytkownikom zastąpienie ustawień aplikacji i zawsze wymagaj potwierdzenia.
[C-SR] MOCNO POLECAMY zabezpieczenie działania potwierdzenia w taki sposób, aby nie można było go sfałszować przez naruszenie zabezpieczeń systemu operacyjnego lub jądra. Oznacza to na przykład, że działanie potwierdzenia oparte na przycisku fizycznym jest kierowane przez pin wejścia/wyjścia ogólnego przeznaczenia (GPIO) tylko do odczytu elementu bezpiecznego (SE), który nie może być sterowany w żaden inny sposób niż przez naciśnięcie przycisku fizycznego.
[C-5-2] NALEŻY dodatkowo wdrożyć proces domyślnego uwierzytelniania (bez etapu potwierdzenia) odpowiadający metodzie setConfirmationRequired(boolean), którą aplikacje mogą wykorzystywać w procesach logowania.

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

[C-SR] MOCNO POLECAMY, aby wymagać potwierdzenia tylko jednego elementu danych biometrycznych na jedno uwierzytelnienie (np. jeśli na urządzeniu dostępne są zarówno czytnik linii papilarnych, jak i czytnik twarzy, po potwierdzeniu dowolnego z nich należy wysłać zdarzenie onAuthenticationSucceeded).

Aby implementacje urządzeń zezwalały aplikacjom innych firm na dostęp do kluczy w magazynie kluczy, muszą:

[C-6-1] MUSI spełniać wymagania dotyczące klasy 3 określone w tej sekcji poniżej.
[C-6-2] MUST present only Class 3 biometrics when the authentication requires BIOMETRIC_STRONG, or the authentication is invoked with a CryptoObject.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 1 (dawniej wygoda), muszą:

[C-1-1] Wskaźnik fałszywych akceptacji musi być mniejszy niż 0,002%.
[C-1-2] MUST disclose that this mode may be less secure than a strong PIN, pattern or password and clearly enumerate the risks of enabling it, if the spoof and imposter acceptance rates are higher than 7% as measured by the Android Biometrics Test Protocols.
[C-1-3] W przypadku weryfikacji biometrycznej po 5 nieudanych próbach należy ograniczyć liczbę prób do minimum 30 sekund – próba jest nieudana, gdy jakość uchwycenia jest wystarczająca (BIOMETRIC_ACQUIRED_GOOD), ale nie pasuje do zarejestrowanych danych biometrycznych.
[C-1-4] NALEŻY uniemożliwić dodawanie nowych danych biometrycznych bez uprzedniego ustanowienia łańcucha zaufania, prosząc użytkownika o potwierdzenie istniejących lub dodanie nowych danych logowania na urządzeniu (kod PIN, wzór lub hasło) chronionych przez TEE. W ramach implementacji projektu Android Open Source udostępniono mechanizm umożliwiający wykonanie tej czynności.
[C-1-5] NALEŻY całkowicie usunąć wszystkie dane biometryczne umożliwiające identyfikację użytkownika, gdy jego konto zostanie usunięte (w tym przywracanie do ustawień fabrycznych).
[C-1-6] MUSI obsługiwać flagę dla danego typu danych biometrycznych (np. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE lub DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] W przypadku nowych urządzeń z Androidem w wersji 10 lub nowszej należy prosić użytkownika o polecane uwierzytelnienie podstawowe (np. kod PIN, wzór lub hasło) co 24 godziny lub rzadziej, a w przypadku urządzeń z uaktualnioną wcześniejszą wersją Androida – co 72 godziny lub rzadziej.
[C-1-8] NALEŻY poprosić użytkownika o podanie danych uwierzytelniania podstawowego (np. kodu PIN, wzoru lub hasła) po wykonaniu jednej z tych czynności:
- 4-godzinny limit czasu nieaktywności LUB
- 3 nieudane próby uwierzytelnienia biometrycznego.
- Po potwierdzeniu danych logowania na urządzeniu okres bezczynności i licznik nieudanych prób uwierzytelniania są resetowane.
Wymagania C-1-8 nie dotyczą urządzeń z Androidem w wersji wcześniejszej niż ta, na której odbywa się aktualizacja. * [C-SR] MOCNO POLECAMY stosowanie logiki w ramach udostępnionych przez projekt Android Open Source w celu egzekwowania ograniczeń określonych w [C-1-7] i [C-1-8] w przypadku nowych urządzeń. * [C-SR] MOCNO zaleca się, aby odsetek błędów odrzucenia był mniejszy niż 10%, mierzonego na urządzeniu. * [C-SR] W przypadku każdej zarejestrowanej metody biometrycznej ZALECAMY, aby opóźnienie było krótsze niż 1 s, liczone od momentu wykrycia danych biometrycznych do odblokowania ekranu.

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 klasy 1 wymienione powyżej.
[C-2-2] Współczynnik akceptacji podszycia się pod kogoś innego i podstępnego oszustwa nie może być wyższy niż 20%, zgodnie z protokołami testów biometrycznych na Androidzie.
[C-2-3] NALEŻY przeprowadzać dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza przestrzenią użytkownika lub jądra Androida, takim jak zaufane środowisko wykonawcze (TEE), lub na chipie z bezpiecznym kanałem do odizolowanego środowiska wykonawczego.
[C-2-4] WSZYSTKIE dane identyfikacyjne MUSZĄ być zaszyfrowane i uwierzytelnione kryptograficznie, tak aby nie mogły być pobierane, odczytywane ani zmieniane poza izolowanym środowiskiem wykonania lub za pomocą chipa z bezpiecznym kanałem do izolowanego środowiska wykonania zgodnie z dokumentacją w wytycznych dotyczących implementacji na stronie projektu Android Open Source.
[C-2-5] W przypadku uwierzytelniania lub rejestrowania na podstawie danych biometrycznych z kamery:
- Musi obsługiwać kamerę w taki sposób, aby uniemożliwić odczytywanie lub zmienianie ramek poza izolowanym środowiskiem wykonywania. Może to być też chip z bezpiecznym kanałem do izolowanego środowiska wykonywania.
- W przypadku rozwiązań z pojedynczą kamerą RGB ramki kamery MOGĄ być odczytywane poza izolowanym środowiskiem wykonania, aby obsługiwać operacje takie jak podgląd w celu rejestracji, ale NIE MOGĄ być zmieniane.
[C-2-6] NIE WOLNO zezwalać aplikacjom innych firm na rozróżnianie poszczególnych rejestracji biometrycznych.
[C-2-7] NIE MOŻESZ zezwolić na dostęp do niezaszyfrowanych danych biometrycznych umożliwiających identyfikację lub danych z nich pochodzących (takich jak elementy wbudowane) procesorowi aplikacji poza kontekstem TEE.
[C-2-8] Musisz mieć bezpieczny kanał przetwarzania, który uniemożliwia wstrzyknięcie danych bezpośrednio w system operacyjny lub jądro, aby nie można było sfałszować uwierzytelnienia.

Jeśli implementacje urządzeń zostały już uruchomione w starszej wersji Androida i nie można ich dostosować do wymogu C-2-8 przez aktualizację oprogramowania systemowego, MOŻNA zwolnić je z wymogu.
[C-SR] MOCNO zalecamy uwzględnienie wykrywania żywości w przypadku wszystkich metod biometrycznych oraz wykrywania uwagi w przypadku biometryki twarzy.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 3 (wcześniej silne), muszą:

[C-3-1] MUSI spełniać wszystkie wymagania dotyczące klasy 2 wymienione powyżej, z wyjątkiem [C-1-7] i [C-1-8]. Urządzenia z Androidem w wersji starszej niż 2.7 nie są zwolnione z wymagań C-2-7.
[C-3-2] Musisz zaimplementować magazyn kluczy wspierany sprzętowo.
[C-3-3] Współczynnik akceptacji oszustwa i podszycia się pod kogoś nie może być wyższy niż 7%, zgodnie z protokołami testów biometrycznych Androida.
[C-3-4] NALEŻY wymagać od użytkownika podania danych uwierzytelniających (np. kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny.

7.3.12. Czujnik postawy

Implementacje na urządzeniu:

MOŻE obsługiwać czujnik postawy z 6 stopniami swobody.

Jeśli implementacje urządzeń obsługują czujnik postawy z 6 stopniami swobody, muszą:

[C-1-1] MUSISZ wdrożyć i zgłosić czujnik TYPE_POSE_6DOF.
[C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.

7.3.13. Czujnik kąta zawiasu

Jeśli implementacje urządzeń obsługują czujnik kąta zawiasów, mogą:

[C-1-1] NALEŻY wdrożyć i zgłosić TYPE_HINGLE_ANGLE.
[C-1-2] MUSI obsługiwać co najmniej 2 wartości z zakresu 0–360 stopni (włącznie z 0 i 360 stopniami).
[C-1-3] Musisz zwrócić czujnik pobudki dla getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4. Łączność z danymi

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 za pomocą sieci GSM lub CDMA. Na potrzeby Androida te połączenia głosowe mogą być przełączane pakietowo lub nie, ale są one niezależne od połączeń danych, które mogą być realizowane w ramach tej samej sieci. Innymi słowy, funkcje i interfejsy API „telefonii” w Androidzie odnoszą się wyłącznie do połączeń głosowych i SMS-ów. Na przykład implementacje urządzeń, które nie mogą nawiązywać połączeń ani wysyłać/odbierać SMS-ów, nie są uważane za urządzenia telefoniczne, niezależnie od tego, czy do łączności danych używają sieci komórkowej.

Android MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami, które nie są telefonami.

Jeśli implementacje urządzeń obejmują telefonię GSM lub CDMA, muszą:

[C-1-1] NALEŻY zadeklarować flagę funkcji android.hardware.telephony i inne flagi podfunkcji zgodnie z technologią.
[C-1-2] Należy w pełni obsługiwać interfejs API dla danej technologii.

Jeśli implementacje urządzeń nie obejmują sprzętu telefonicznego, nie mogą:

[C-2-1] NALEŻY wdrożyć pełne interfejsy API jako no-ops.

Jeśli implementacje urządzeń obsługują karty eUICC lub eSIM/wbudowane karty SIM i zawierają zastrzeżoną technologię, która umożliwia udostępnienie funkcji eSIM zewnętrznym deweloperom, muszą:

[C-3-1] Musisz wdrożyć EuiccManager API.

7.4.1.1. Zgodność z blokowaniem numeru

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

[C-1-1] MUST include number blocking support
[C-1-2] NALEŻY w pełni zaimplementować BlockedNumberContract i odpowiednie 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 tymczasowe odblokowanie blokady numeru zgodnie z opisem w dokumentacji pakietu SDK.
[C-1-4] W przypadku zablokowanego połączenia NIE MOŻESZ zapisywać danych w rejestrach połączeń platformy.
[C-1-5] NIE NALEŻY pisać do dostawcy usług telefonicznych w przypadku zablokowanej wiadomości.
[C-1-6] NALEŻY wdrożyć interfejs zarządzania zablokowanymi numerami, który otwiera się za pomocą intencji zwracanej przez metodę TelecomManager.createManageBlockedNumbersIntent().
[C-1-7] Nie należy zezwalać użytkownikom dodatkowym na wyświetlanie ani edytowanie zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że użytkownik główny ma pełną kontrolę nad usługami telefonicznymi, w jednym wystąpieniu na urządzeniu. Wszystkie elementy interfejsu związane z blokowaniem MUSZĄ być ukryte dla użytkowników dodatkowych, a lista zablokowanych użytkowników MUSI być nadal uwzględniana.
Blokowane numery NALEŻY przenieść do dostawcy, gdy urządzenie zostanie zaktualizowane do Androida 7.0.

7.4.1.2. Interfejs Telecom API

Jeśli wdrożenia urządzeń zgłaszają android.hardware.telephony, to:

[C-1-1] Musi obsługiwać interfejsy API ConnectionService opisane w pakiecie SDK.
[C-1-2] NALEŻY wyświetlić nowe połączenie przychodzące i umożliwić użytkownikowi zaakceptowanie lub odrzucenie połączenia przychodzącego, gdy użytkownik jest w trakcie rozmowy z inną osobą w aplikacji innej firmy, która nie obsługuje funkcji wstrzymania określonej w CAPABILITY_SUPPORT_HOLD.
[C-1-3] Aplikacja MUSI implementować interfejs InCallService.
[C-SR] MOCNO ZALECAMY powiadomienie użytkownika, że odebranie połączenia spowoduje przerwanie trwającego połączenia.

Implementacja AOSP spełnia te wymagania dzięki powiadomieniu, które informuje użytkownika, że odebranie połączenia przychodzącego spowoduje przerwanie innego połączenia.
[C-SR] Zdecydowanie zalecamy wstępne załadowanie domyślnej aplikacji do wybierania numerów, która wyświetla w dzienniku połączeń wpis i nazwę aplikacji innej firmy, gdy aplikacja innej firmy ustawia klucz dodatkowych informacji EXTRA_LOG_SELF_MANAGED_CALLS na PhoneAccount o wartości true.
[C-SR] ZALECAMY obsługę zdarzeń KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK dotyczących słuchawek na podczerwień w przypadku interfejsów android.telecom w następujący sposób:
- Po krótkim naciśnięciu klawisza podczas trwającego połączenia wywołaj funkcję Connection.onDisconnect().
- Wywołanie Connection.onAnswer() po wykryciu krótkiego naciśnięcia klawisza podczas połączenia przychodzącego.
- Wywołanie Connection.onReject(), gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia.
- Przełącz stan wyciszenia CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementacje na urządzeniu:

POWINNA obejmować obsługę co najmniej jednej formy 802.11.

Jeśli implementacje urządzeń obejmują obsługę 802.11 i udostępniają tę funkcję aplikacji innych firm, muszą:

[C-1-1] Musisz zaimplementować odpowiedni interfejs API Androida.
[C-1-2] MUST report the hardware feature flag android.hardware.wifi.
[C-1-3] MUSISZ zaimplementować interfejs API multicast zgodnie z opisem w dokumentacji pakietu SDK.
[C-1-4] MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) w żadnym momencie działania, w tym:
- nawet wtedy, gdy ekran nie jest aktywny.
- W przypadku implementacji urządzeń z Androidem TV nawet w stanie gotowości.
[C-1-5] Nie należy traktować wywołania metody interfejsu API WifiManager.enableNetwork() jako wystarczającej wskazówki do przełączenia obecnie aktywnego Network, który jest używany domyślnie do ruchu aplikacji i zwracany przez metody interfejsu API ConnectivityManager, takie jak getActiveNetwork i registerDefaultNetworkCallback. Innymi słowy, mogą wyłączyć dostęp do internetu przez dowolnego innego dostawcę sieci (np. dane komórkowe), jeśli potwierdzą, że sieć Wi-Fi zapewnia dostęp do internetu.
[C-1-6] MOCNO zalecamy, aby po wywołaniu metody interfejsu API ConnectivityManager.reportNetworkConnectivity() ponownie sprawdzić dostęp do internetu na urządzeniu Network.Gdy po tej ocenie okaże się, że bieżąca sieć Network nie zapewnia już dostępu do internetu, należy przejść na dowolną inną dostępną sieć (np. mobilną) zapewniającą dostęp do internetu.
[C-SR] MOCNO ZALECAMY losowanie adresu MAC źródła i numeru sekwencji ramek żądań sondowania raz na początku każdego skanowania, gdy STA jest odłączony.
- Każda grupa ramek żądania sondowania, która obejmuje jedno skanowanie, powinna używać jednego stałego adresu MAC (NIE NALEŻY losować adresu MAC w połowie skanowania).
- Numer sekwencyjny żądania sondowania powinien być zwykłą iteracją (kolejność) między żądaniami sondowania w skanowaniu.
- Numer sekwencyjny żądania sondowania powinien być losowy między ostatnim żądaniem sondowania w ramach jednego skanowania a pierwszym żądaniem sondowania w ramach następnego skanowania.
[C-SR] MOCNO ZALECANA, gdy STA jest odłączony, aby zezwolić tylko na te elementy w ramkach żądania sondy:
- Zestaw parametrów SSID (0)
- Zestaw parametrów DS (3)

Jeśli implementacje urządzeń obejmują obsługę trybu oszczędzania energii Wi-Fi zgodnie ze standardem IEEE 802.11, urządzenia te:

[C-3-1] Należy wyłączyć tryb oszczędzania energii Wi-Fi, gdy aplikacja uzyska blokadę WIFI_MODE_FULL_HIGH_PERF lub 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 obie strony między urządzeniem a punktem dostępu w trybie Wi-Fi Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) MUSI być krótszy niż czas oczekiwania w trybie Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
[C-SR] ZALECAMY zminimalizowanie opóźnień w transmisji Wi-Fi, gdy zostanie uzyskany i zacznie obowiązywać blokada niskiego opóźnienia (WIFI_MODE_FULL_LOW_LATENCY).

Jeśli implementacje urządzeń obsługują Wi-Fi i korzystają z niego do skanowania lokalizacji, muszą:

[C-2-1] NALEŻY zapewnić użytkownikowi możliwość włączenia lub wyłączenia wartości odczytanej za pomocą metody interfejsu API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementacje na urządzeniu:

NALEŻY uwzględnić obsługę Wi-Fi Direct (Wi-Fi peer-to-peer).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Direct, urządzenia te:

[C-1-1] NALEŻY zaimplementować odpowiednie interfejsy API Androida zgodnie z opisem w dokumentacji pakietu SDK.
[C-1-2] MUST report the hardware feature android.hardware.wifi.direct.
[C-1-3] MUSI obsługiwać zwykłe działanie Wi-Fi.
[C-1-4] MUSI obsługiwać operacje Wi-Fi i Wi-Fi Direct jednocześnie.

7.4.2.2. Konfiguracja połączenia bezpośredniego z tunelowaniem Wi-Fi

Implementacje na urządzeniu:

POWINIEN zawierać obsługę konfiguracji tunelu bezpośredniego Wi-Fi (TDLS) zgodnie z opisem w dokumentacji pakietu SDK Androida.

Jeśli implementacje urządzeń obsługują TDLS, a TDLS jest włączone przez interfejs API WiFiManager, urządzenia te:

[C-1-1] MUSI deklarować obsługę TDLS za pomocą WifiManager.isTdlsSupported.
NALEŻY używać TDLS tylko wtedy, gdy jest to możliwe i korzystne.
Powinien zawierać heurystyki i NIE używać TDLS, gdy jego wydajność może być gorsza niż w przypadku korzystania z punktu dostępu Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementacje na urządzeniu:

POWINIEN zawierać obsługę Wi-Fi Aware.

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

[C-1-1] NALEŻY zaimplementować interfejsy API WifiAwareManager zgodnie z opisem w dokumentacji pakietu SDK.
[C-1-2] NALEŻY zadeklarować flagę funkcji android.hardware.wifi.aware.
[C-1-3] MUSI obsługiwać operacje Wi-Fi i Wi-Fi Aware jednocześnie.
[C-1-4] NALEŻY losowo generować adres interfejsu zarządzania Wi-Fi Aware co 30 minut i za każdym razem, gdy włączona jest funkcja Wi-Fi Aware, chyba że trwa operacja pomiaru odległości Aware lub aktywna jest ścieżka danych Aware (losowanie nie jest wymagane, dopóki ścieżka danych jest aktywna).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i lokalizacji Wi-Fi zgodnie z opisem w sekcji 7.4.2.5 i udostępniają te funkcje aplikacjom innych firm, muszą:

[C-2-1] NALEŻY zaimplementować interfejsy API wykrywania z uwzględnieniem lokalizacji: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm i onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Jeśli implementacje urządzeń obejmują obsługę 802.11 (Wi-Fi), urządzenia te:

POWINIEN zawierać obsługę Wi-Fi Passpoint.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Passpoint, urządzenia te:

[C-1-2] NALEŻY zaimplementować interfejsy API WifiManager związane z Passpoint 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 wybierania sieci, np. Generic Advertisement Service (GAS) i Access Network Query Protocol (ANQP).

Jeśli implementacja urządzenia nie obsługuje Wi-Fi Passpoint:

[C-2-1] Implementacja interfejsów API WifiManager związanych z Passpoint MUSI zgłaszać błąd UnsupportedOperationException.

7.4.2.5. Lokalizacja Wi-Fi (czas błądzenia Wi-Fi – RTT)

Implementacje na urządzeniu:

POWINIEN zawierać obsługę lokalizacji Wi-Fi.

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

[C-1-1] NALEŻY zaimplementować interfejsy API WifiRttManager zgodnie z opisem w dokumentacji pakietu SDK.
[C-1-2] NALEŻY zadeklarować flagę funkcji android.hardware.wifi.rtt.
[C-1-3] NALEŻY losowo zmienić źródłowy adres MAC w przypadku każdego wysyłania RTT, które jest wykonywane, gdy interfejs Wi-Fi, na którym jest wykonywane RTT, nie jest powiązany z punktem dostępu.

7.4.2.6. Odciążenie utrzymywania aktywności Wi-Fi

Implementacje na urządzeniu:

NALEŻY uwzględnić obsługę przenoszenia danych w ramach funkcji keepalive Wi-Fi.

Jeśli implementacje urządzeń obsługują funkcję przenoszenia obsługi Wi-Fi keepalive i udostępniają ją aplikacjom innych firm, muszą:

[C-1-1] Musi obsługiwać interfejs API SocketKeepAlive.
[C-1-2] MUSI obsługiwać co najmniej 3 jednoczesne gniazda utrzymywania połączenia przez Wi-Fi i co najmniej 1 gniazdo utrzymywania połączenia przez sieć komórkową.

Jeśli implementacje urządzeń nie obsługują przenoszenia funkcji utrzymywania połączenia Wi-Fi, nie:

[C-2-1] Musi zwracać ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protokół Device Provisioning Protocol)

Implementacje na urządzeniu:

NALEŻY uwzględnić obsługę Wi-Fi Easy Connect (DPP).

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

[C-1-1] Metoda WifiManager#isEasyConnectSupported() MUSI zwracać wartość true.

7.4.3. Bluetooth

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

POWINNY obsługiwać zaawansowane kodeki audio i kodeki dźwięku Bluetooth (np. LDAC).

Jeśli implementacje urządzeń obsługują protokoły HFP, A2DP i AVRCP, muszą:

NALEŻY obsługiwać co najmniej 5 połączonych urządzeń.

Jeśli implementacje na urządzeniach deklarują funkcję android.hardware.vr.high_performance, muszą:

[C-1-1] MUSI obsługiwać Bluetooth 4.2 i Bluetooth LE Data Length Extension.

Android obsługuje Bluetooth i Bluetooth Low Energy.

Jeśli implementacje urządzeń obejmują obsługę Bluetooth i Bluetooth Low Energy, mogą:

[C-2-1] NALEŻY zadeklarować odpowiednie funkcje platformy (odpowiednio android.hardware.bluetooth i android.hardware.bluetooth_le) oraz zaimplementować interfejsy API platformy.
NALEŻY wdrożyć odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX, HFP itp., w sposób odpowiedni dla urządzenia.

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

[C-3-1] NALEŻY zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
[C-3-2] NALEŻY włączyć interfejsy API Bluetooth oparte na GATT (ogólnym profilu atrybutów) zgodnie z dokumentacją pakietu SDK i android.bluetooth.
[C-3-3] NALEŻY podać prawidłową wartość w polu BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy logika filtrowania dla klas interfejsu API ScanFilter została zaimplementowana.
[C-3-4] Musisz podać prawidłową wartość atrybutu BluetoothAdapter.isMultipleAdvertisementSupported(), aby wskazać, czy reklamy o niskiej energochłonności są obsługiwane.
[C-3-5] NALEŻY wdrożyć limit czasu dla rozwiązywalnych adresów prywatnych (RPA) nie dłuższy niż 15 minut i zmienić adres w momencie osiągnięcia limitu, aby chronić prywatność użytkownika, gdy urządzenie aktywnie korzysta z BLE do skanowania lub wyświetlania reklam. Aby zapobiec atakom czasowym, czasy oczekiwania MUSZĄ być losowo generowane w zakresie od 5 do 15 minut.
NALEŻY obsługiwać przenoszenie logiki filtrowania na układ Bluetooth podczas implementowania interfejsu ScanFilter API.
NALEŻY obsługiwać przenoszenie skanowania zbiorczego na układ Bluetooth.
NALEŻY obsługiwać wiele reklam z co najmniej 4 miejscami.

Jeśli implementacje urządzeń obsługują Bluetooth LE i korzystają z Bluetooth LE do skanowania lokalizacji, to:

[C-4-1] NALEŻY zapewnić użytkownikowi możliwość włączenia lub wyłączenia wartości odczytanej 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 artykule Obsługa aparatów słuchowych za pomocą Bluetooth LE, urządzenia te:

[C-5-1] W funkcji BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) musi zostać zwrócona wartość true.

7.4.4. Komunikacja Near Field Communication

Implementacje na urządzeniu:

POWINIEN zawierać transceiver 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ą NFC ani nie deklarują funkcji android.hardware.nfc, ponieważ klasy reprezentują format reprezentacji danych niezależny od protokołu.

Jeśli implementacje urządzeń obejmują sprzęt NFC i planują udostępnić go aplikacjom innych firm, muszą:

[C-1-1] MUST report the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method.
MUSI być w stanie odczytywać i zapisywać komunikaty NDEF za pomocą tych standardów NFC:
[C-1-2] MUSI być w stanie działać jako czytnik/nagrywarka NFC Forum (zgodnie ze specyfikacją techniczną NFC Forum NFCForum-TS-DigitalProtocol-1.0) za pomocą tych standardów NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Typy tagów NFC Forum 1, 2, 3, 4, 5 (zdefiniowane przez NFC Forum)
[SR] MOCNO ZALECANA możliwość odczytywania i zapisywania komunikatów NDEF oraz danych nieprzetworzonych za pomocą tych standardów NFC. Pamiętaj, że chociaż standardy NFC są opisane jako „MOCNO ZALECANE”, w przyszłej wersji definicji zgodności planujemy zmienić je na „WYMAGANE”. Te standardy są opcjonalne w tej wersji, ale będą wymagane w przyszłych wersjach. Zachęcamy, aby i dotychczasowe, i nowe urządzenia z tą wersją Androida spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
[C-1-13] W trybie wykrywania NFC musi sprawdzać wszystkie obsługiwane technologie.
NALEŻY ustawić tryb wykrywania NFC, gdy urządzenie jest aktywne, ekran jest włączony, a ekran blokady odblokowany.
POWINIEN odczytywać kody kreskowe i adresy URL (jeśli są zakodowane) produktów z kodami kreskowymi Thinfilm NFC.

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 hosta karty NFC (HCE).

Jeśli implementacje urządzeń zawierają chipset kontrolera NFC obsługujący HCE (dla NfcA lub NfcB) i obsługują routing identyfikatora aplikacji (AID), to:

[C-2-1] MUST report the android.hardware.nfc.hce feature constant.
[C-2-2] MUSI obsługiwać interfejsy API NFC HCE zdefiniowane w pakiecie Android SDK.

Jeśli implementacje urządzeń zawierają chipset kontrolera NFC obsługujący HCE dla NfcF i implementują tę funkcję w przypadku aplikacji innych firm, muszą:

[C-3-1] MUST report the android.hardware.nfc.hcef feature constant.
[C-3-2] MUSISZ zaimplementować interfejsy API do emulacji karty NfcF zgodnie z definicją w pakiecie SDK Androida.

Jeśli implementacje urządzeń obejmują ogólną obsługę NFC zgodnie z opisem w tej sekcji i obsługują technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF na MIFARE Classic) w roli czytnika/nagrywarki, muszą:

[C-4-1] NALEŻY zaimplementować odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
[C-4-2] MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() method. Pamiętaj, że nie jest to standardowa funkcja Androida i nie jest wyświetlana 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 na urządzeniu:

[C-0-1] MUSI obsługiwać co najmniej jedną formę sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o przepustowości co najmniej 200 kbps. Przykłady technologii spełniających ten wymóg to EDGE, HSPA, EV-DO, 802.11g, Ethernet i PAN Bluetooth.
NALEŻY również uwzględnić obsługę co najmniej jednego popularnego standardu bezprzewodowego przesyłania danych, takiego jak 802.11 (Wi-Fi), gdy podstawowym połączeniem danych jest standard sieci fizycznej (taki jak Ethernet).
MOŻNA stosować więcej niż jedną formę łączności danych.

7.4.5.2. IPv6

Implementacje na urządzeniu:

[C-0-2] MUSI zawierać stos sieciowy IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection, a także natywnych interfejsów API, takich jak gniazda AF_INET6.
[C-0-3] Protokół IPv6 MUSI być domyślnie włączony.
MUSISZ zadbać o to, aby komunikacja IPv6 była tak samo niezawodna jak IPv4, na przykład:
- [C-0-4] W trybie Doze musi być zachowana łączność IPv6.
- [C-0-5] Ograniczenie szybkości NIE MOŻE spowodować utraty łączności IPv6 w żadnej sieci zgodnej z IPv6, która używa okresów ważności RA wynoszący co najmniej 180 sekund.
[C-0-6] Musisz zapewnić aplikacjom innych firm bezpośrednią łączność IPv6 z siecią, gdy urządzenie jest połączone z siecią IPv6, bez żadnej formy tłumaczenia adresu lub portu na poziomie lokalnym. Zarówno zarządzane interfejsy API, takie jak Socket#getLocalAddress lub Socket#getLocalPort, jak i interfejsy NDK, 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, oraz być widoczne jako adres IP źródłowy i port serwerów internetowych (WWW).

Wymagany poziom obsługi IPv6 zależy od typu sieci, jak pokazano w tych wymaganiach.

Jeśli implementacje urządzeń obsługują Wi-Fi, to:

[C-1-1] MUSI obsługiwać stos podwójny i IPv6 w sieci Wi-Fi.

Jeśli implementacje urządzeń obsługują Ethernet, to:

[C-2-1] Musi obsługiwać stos podwójny i IPv6 w sieci Ethernet.

Jeśli implementacje urządzeń obsługują dane komórkowe, to:

[C-3-1] MUSI obsługiwać działanie IPv6 (tylko IPv6 i ewentualnie stos podwójny) w sieci komórkowej.

Jeśli implementacje urządzeń obsługują więcej niż jeden typ sieci (np. Wi-Fi i komórkową), mogą:

[C-4-1] MUSI jednocześnie spełniać powyższe wymagania w przypadku 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 na urządzeniach zapewniają pełną implementację android.webkit.Webview API, to:

[C-1-1] Musisz udostępnić aplikację portalu uwierzytelniającego, która będzie obsługiwać intencję ACTION_CAPTIVE_PORTAL_SIGN_IN i wyświetlać stronę logowania portalu uwierzytelniającego, wysyłając tę intencję w wywołaniu do interfejsu System API ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] MUSI wykrywać portale przechwytujące i obsługiwać logowanie przez aplikację portalu przechwytującego, gdy urządzenie jest połączone z dowolnym typem sieci, w tym siecią komórkową/komórkową, Wi-Fi, Ethernet lub Bluetooth.
[C-1-3] MUSI obsługiwać logowanie na portalach ograniczonych za pomocą DNS w postaci zwykłego tekstu, gdy urządzenie jest skonfigurowane do używania prywatnego DNS w trybie ścisłym.
[C-1-4] NALEŻY używać szyfrowanego DNS zgodnie z dokumentacją pakietu SDK w przypadku android.net.LinkProperties.getPrivateDnsServerName i android.net.LinkProperties.isPrivateDnsActive w przypadku całego ruchu sieciowego, który nie komunikuje się bezpośrednio z portalem ograniczonym.
[C-1-5] NALEŻY zadbać o to, aby podczas logowania się użytkownika na portalu uwięzionym domyślna sieć używana przez aplikacje (zwracana przez ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback i używana domyślnie przez interfejsy API sieci Java, takie jak java.net.Socket, oraz natywne interfejsy API, takie jak connect()) była dowolną inną dostępną siecią, która zapewnia dostęp do Internetu (jeśli jest dostępna).

7.4.6. Ustawienia synchronizacji

Implementacje na urządzeniu:

[C-0-1] Ustawienie głównej automatycznej synchronizacji MUSI być domyślnie włączone, aby metoda getMasterSyncAutomatically() zwracała „true”.

7.4.7. Oszczędzanie danych

Jeśli implementacje urządzeń obejmują połączenie z licznikiem, są:

[SR] MOCNO ZALECANA funkcja trybu oszczędzania danych.

Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych, muszą:

[C-1-1] Musi obsługiwać wszystkie interfejsy API z klasy ConnectivityManager zgodnie z opisem w dokumentacji pakietu SDK

Jeśli implementacja na urządzeniu nie zapewnia trybu oszczędzania danych, nie spełnia ona tych wymagań:

[C-2-1] W przypadku argumentu ConnectivityManager.getRestrictBackgroundStatus() musi zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED
[C-2-2] NIE MOŻNA nadawać ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Bezpieczne elementy

Jeśli implementacje urządzeń obsługują elementy zabezpieczone zgodne z interfejsem Open Mobile API i są dostępne dla aplikacji innych firm, to:

[C-1-1] NALEŻY wyliczyć dostępne czytniki elementów zabezpieczeń za pomocą interfejsu API android.se.omapi.SEService.getReaders().
[C-1-2] NALEŻY zadeklarować prawidłowe flagi funkcji za pomocą android.hardware.se.omapi.uicc w przypadku urządzenia z elementami bezpieczeństwa opartymi na kartach UICC, android.hardware.se.omapi.ese w przypadku urządzenia z elementami bezpieczeństwa opartymi na kartach eSE oraz android.hardware.se.omapi.sd w przypadku urządzenia z elementami bezpieczeństwa opartymi na kartach SD.

7.5. Aparaty

Jeśli implementacje urządzeń zawierają co najmniej 1 kamerę, muszą:

[C-1-1] NALEŻY zadeklarować flagę funkcji android.hardware.camera.any.
[C-1-2] Aplikacja MUSI mieć możliwość jednoczesnego przydzielenia 3 bitmap RGBA_8888 o rozmiarze równym rozmiarowi obrazów generowanych przez czujnik aparatu o najwyższej rozdzielczości na urządzeniu, gdy kamera jest otwarta w celu wyświetlenia podglądu i zapisu zdjęć.
[C-1-3] Musisz mieć pewność, że wstępnie zainstalowana domyślna aplikacja do obsługi aparatu, która obsługuje intencje MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE lub MediaStore.ACTION_VIDEO_CAPTURE, jest odpowiedzialna za usunięcie lokalizacji użytkownika w metadanych obrazu przed wysłaniem go do aplikacji odbiorczej, gdy ta nie ma dostępu ACCESS_FINE_LOCATION.

7.5.1. Tylny aparat

Tylny aparat znajduje się po przeciwnej stronie urządzenia niż wyświetlacz. Oznacza to, że rejestruje obrazy po przeciwnej stronie urządzenia, tak jak tradycyjny aparat.

Implementacje na urządzeniu:

NALEŻY umieścić tylny aparat.

Jeśli implementacje urządzeń zawierają co najmniej 1 aparat skierowany do tyłu, muszą:

[C-1-1] MUST report the feature flag android.hardware.camera and android.hardware.camera.any.
[C-1-2] Rozdzielczość musi wynosić co najmniej 2 Mpix.
W sterowniku aparatu powinien być ZREALIZOWANY autofokus sprzętowy lub automatyczny autofokus oprogramowania (niewidoczny dla oprogramowania aplikacji).
MOŻE mieć sprzęt z ostrzością stałą lub EDOF (rozszerzoną głębią ostrości).
MOŻE zawierać błysk.

Jeśli aparat ma lampę błyskową:

[C-2-1] lampa błyskowa NIE MOŻE być włączona, gdy instancja android.hardware.Camera.PreviewCallback została zarejestrowana na powierzchni podglądu aparatu, 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. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu, ale tylko aplikacji innych firm korzystających z funkcji Camera.PreviewCallback.

7.5.2. Przedni aparat

Przedni aparat to aparat znajdujący się po tej samej stronie urządzenia co wyświetlacz, czyli aparat zwykle używany do robienia zdjęć użytkownikowi, na przykład w przypadku konferencji wideo i podobnych aplikacji.

Implementacje na urządzeniu:

MOŻE zawierać przedni aparat.

Jeśli implementacje urządzeń zawierają co najmniej 1 przedni aparat:

[C-1-1] MUST report the feature flag android.hardware.camera.any and android.hardware.camera.front.
[C-1-2] Rozdzielczość musi wynosić co najmniej VGA (640 x 480 pikseli).
[C-1-3] Nie wolno używać przedniego aparatu jako domyślnego interfejsu Camera API. Nie wolno też skonfigurować interfejsu 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 kamery MUSI być odbiciem lustrzanym w orientacji poziomej względem orientacji określonej przez aplikację, gdy bieżąca aplikacja wyraźnie poprosiła o obrócenie wyświetlacza aparatu za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation(). Z drugiej strony, podgląd MUSI być odzwierciedlony wzdłuż domyślnej osi poziomej urządzenia, gdy bieżąca aplikacja nie prosi wyraźnie o obrócenie wyświetlacza aparatu za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation().
[C-1-5] NIE MOŻESZ odbić lustrzanego obrazu z ostatecznego uchwytu ani strumienia wideo z powrotem do aplikacji lub do magazynu multimediów.
[C-1-6] Obraz wyświetlany przez postview MUSI być odbiciem lustrzanym w taki sam sposób jak strumień obrazu z podglądu kamery.
MOŻE zawierać funkcje (takie jak autofokus czy lampa błyskowa) dostępne dla tylnych kamer zgodnie z opisem w sekcji 7.5.1.

Jeśli implementacje na urządzeniach 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 w kamerze MUSI być odbitykiem poziomym bieżącej orientacji urządzenia.

7.5.3. Kamera zewnętrzna

Implementacje na urządzeniu:

MOŻE obejmować obsługę zewnętrznej kamery, która nie zawsze musi być podłączona.

Jeśli implementacje urządzeń obejmują obsługę kamery zewnętrznej, muszą:

[C-1-1] NALEŻY zadeklarować flagę funkcji platformy android.hardware.camera.external i android.hardware camera.any.
[C-1-2] Musi obsługiwać USB Video Class (UVC 1.0 lub nowszy), jeśli kamera zewnętrzna łączy się przez port hosta USB.
[C-1-3] Musi przejść testy CTS aparatu z podłączonym fizycznym zewnętrznym urządzeniem z kamerą. Szczegółowe informacje o testach CTS aparatu są dostępne na stronie source.android.com.
POWINIEN obsługiwać kompresję wideo, np. MJPEG, aby umożliwić przesyłanie nieskompresowanych strumieni o wysokiej jakości (czyli strumieni nieprzetworzonych lub niezależnie skompresowanych).
MOŻE obsługiwać wiele kamer.
MOŻE obsługiwać kodowanie wideo na podstawie kamery.

Jeśli kodowanie wideo na podstawie kamery jest obsługiwane:

[C-2-1] Jednoczesny strumień nieskompresowany / MJPEG (w rozdzielczości QVGA lub wyższej) MUSI być dostępny dla implementacji urządzenia.

7.5.4. Zachowanie interfejsu Camera API

Android zawiera 2 pakiety interfejsu API umożliwiające dostęp do aparatu. Nowszy interfejs API android.hardware.camera2 udostępnia aplikacji niższy poziom kontroli nad aparatem, w tym wydajne przepływy zdjęć seryjnych/strumieniowych bez kopiowania i kontroli na poziomie poszczególnych klatek dotyczące ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, redukcji szumów, wyostrzania itp.

Starszy pakiet interfejsu API (android.hardware.Camera) jest oznaczony jako przestarzały w Androidzie 5.0, ale powinien być nadal dostępny dla aplikacji. Implementacje na urządzeniach z Androidem MUSZĄ zapewniać ciągłą obsługę interfejsu API zgodnie z opisem w tej sekcji i w pakiecie SDK Androida.

Wszystkie funkcje wspólne dla przestarzałej klasy android.hardware.Camera i nowszego pakietu android.hardware.camera2 MUSZĄ mieć porównywalne osiągi i jakość w obu interfejsach API. Na przykład przy takich samych ustawieniach szybkość i dokładność autofokusa muszą być identyczne, a jakość zarejestrowanych obrazów musi być taka sama. Funkcje, które zależą od odmiennej semantyki obu interfejsów API, nie muszą mieć takiej samej szybkości ani jakości, ale powinny być jak najbardziej zbliżone.

Implementacje urządzeń MUSZĄ implementować poniższe zachowania w przypadku interfejsów API związanych z aparatami w przypadku wszystkich dostępnych aparatów. Implementacje na urządzeniu:

[C-0-1] DO użycia w przypadku danych podglądu przekazywanych do aplikacji w wywołaniach zwrotnych, gdy aplikacja nigdy nie wywołała funkcji android.hardware.Camera.Parameters.setPreviewFormat(int), należy użyć android.hardware.PixelFormat.YCbCr_420_SP.
[C-0-2] Musi być w dalszym ciągu w formacie kodowania NV21, gdy aplikacja rejestruje wystąpienie android.hardware.Camera.PreviewCallback, system wywołuje metodę onPreviewFrame(), a format podglądu to YCbCr_420_SP, a dane w byte[] przekazane do onPreviewFrame(). Oznacza to, że NV21 MUSI być ustawiony jako domyślny.
[C-0-3] Musi obsługiwać format YV12 (oznaczony za pomocą stałej android.graphics.ImageFormat.YV12) w przypadku podglądów z aparatów przednich i tylnych w urządzeniu android.hardware.Camera. (Sprzętowy koder wideo i kamera mogą używać dowolnego natywnego formatu pikseli, ale implementacja urządzenia MUSI obsługiwać konwersję do YV12).
[C-0-4] MUSI obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe w interfejsie API android.media.ImageReader na urządzeniach android.hardware.camera2, które reklamują obsługę funkcji REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE w android.request.availableCapabilities.
[C-0-5] NALEŻY w dalszym ciągu wdrożyć pełne Camera API zawarte w dokumentacji pakietu SDK Androida, niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład aparaty bez autofokusa MUSZĄ wywoływać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback (nawet jeśli nie mają one zastosowania do aparatu bez autofokusa). Pamiętaj, że dotyczy to również przednich aparatów. Na przykład mimo że większość przednich aparatów nie obsługuje autofokusa, wywołania interfejsu API muszą być „fałszowane” w sposób opisany powyżej.
[C-0-6] MUSI rozpoznawać i szanować nazwy parametrów zdefiniowane jako stałe w klasie android.hardware.Camera.Parameters i klasie android.hardware.camera2.CaptureRequest. Z drugiej strony implementacje urządzeń NIE MOGĄ obsługiwać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters() innych niż te, które są dokumentowane jako stałe w android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry aparatu, jeśli sprzęt na to pozwala, i NIE MOGĄ obsługiwać niestandardowych typów parametrów aparatu. Na przykład implementacje urządzeń, które obsługują techniki rejestrowania obrazu z wysokim zakresem dynamiki (HDR), MUSZĄ obsługiwać parametr aparatu Camera.SCENE_MODE_HDR.
[C-0-7] Musisz podać odpowiedni poziom obsługi za pomocą właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie SDK Androida. Musisz też podać odpowiednie flagi funkcji frameworka.
[C-0-8] MUSI również zadeklarować indywidualne możliwości kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i zadeklarować odpowiednie flagi funkcji; MUSI zdefiniować flagę funkcji, jeśli którekolwiek z podłączonych urządzeń z kamerą obsługują tę funkcję.
[C-0-9] MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.
[C-0-10] NALEŻY przesyłać intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy aparat nagrywa nowy film, a zdjęcie jest dodawane do magazynu multimediów.
[C-0-11] Wszystkie kamery dostępne za pomocą przestarzałego interfejsu API android.hardware.Camera muszą być też dostępne za pomocą interfejsu API android.hardware.camera2.
[C-0-12] Należy zadbać o to, aby wygląd twarzy NIE był zmieniany, w tym geometria twarzy, odcień skóry twarzy ani gładkość skóry twarzy w przypadku interfejsu API android.hardware.camera2 lub android.hardware.Camera.
[C-SR] W przypadku urządzeń z większą liczbą kamer RGB skierowanych w ten sam kierunek MOCNO zalecamy obsługę logicznego urządzenia z kamerą, które zawiera wszystkie kamery RGB skierowane w ten sam kierunek jako fizyczne podurządzenia.CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA

Jeśli implementacje na urządzeniach udostępniają firmom zewnętrznym firmowe interfejsy API aparatu, mogą:

[C-1-1] NALEŻY zaimplementować interfejs API aparatu za pomocą interfejsu android.hardware.camera2 API.
MOŻE udostępniać tagi dostawcy lub rozszerzenia do interfejsu android.hardware.camera2 API.

7.5.5. Orientacja aparatu

Jeśli implementacje urządzeń mają przednie lub tylne kamery:

[C-1-1] Musi być ustawiona tak, aby dłuższy wymiar kamery był wyrównany z dłuższym wymiarem ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparaty MUSZĄ robić zdjęcia w orientacji poziomej. Dotyczy to niezależnie od naturalnej orientacji urządzenia, czyli zarówno urządzeń z główną orientacją poziomą, jak i z główną orientacją pionową.

7.6. Pamięć i miejsce na dane

7.6.1. Minimalna ilość pamięci i miejsca na dane

Implementacje na urządzeniu:

[C-0-1] Musi zawierać menedżera pobierania, którego aplikacje MOGĄ używać do pobierania plików danych. Musi być w stanie pobierać pojedyncze pliki o rozmiarze co najmniej 100 MB do domyślnej lokalizacji „bufora”.

7.6.2. Pamięć współdzielona aplikacji

Implementacje na urządzeniu:

[C-0-1] Musi oferować miejsce na dane, które może być udostępniane przez aplikacje. Jest ono często nazywane „wspólnym miejscem na dane zewnętrzne”, „wspólnym miejscem na dane aplikacji” lub ścieżką Linuxa „/sdcard”, na której jest zamontowane.
[C-0-2] Musi być skonfigurowany z udziałem pamięci współdzielonej zamontowanej domyślnie, czyli „od razu po wyjęciu z pudła”, niezależnie od tego, czy pamięć jest implementowana na wewnętrznym komponencie pamięci czy na wymiennym nośniku pamięci (np. gniazdo karty Secure Digital).
[C-0-3] NALEŻY zamontować udostępnioną pamięć aplikacji bezpośrednio na ścieżce Linuxa sdcard lub umieścić link symboliczny Linuxa z sdcard do rzeczywistego punktu montowania.
[C-0-4] W przypadku wszystkich aplikacji kierowanych na interfejs API na poziomie 29 lub wyższym MUSISZ domyślnie włączyć storage ujęty w zakresie, z wyjątkiem następującej sytuacji:
- gdy aplikacja poprosi o android:requestLegacyExternalStorage="true" w pliku manifestu.
[C-0-5] NALEŻY usunąć metadane dotyczące lokalizacji, takie jak tagi GPS Exif, przechowywane w plikach multimedialnych, gdy te pliki są dostępne przez MediaStore, z wyjątkiem sytuacji, gdy wywołująca aplikacja ma uprawnienia ACCESS_MEDIA_LOCATION.

Implementacje urządzeń MOGĄ spełniać powyższe wymagania, korzystając z jednego z tych rozwiązań:

wymienna pamięć dostępna dla użytkownika, np. gniazdo karty Secure Digital (SD);
Część pamięci wewnętrznej (nieusuwalna) w ramach Projektu Android Open Source (AOSP).

Jeśli implementacje urządzeń korzystają z wymiennej pamięci, aby spełniać powyższe wymagania, muszą:

[C-1-1] W interfejsie należy DODAWAĆ toast lub wyskakujące okienko z ostrzeżeniem dla użytkownika, gdy w gniazdo nie jest włożone żadne medium.
[C-1-2] MUSI zawierać nośnik danych w formacie FAT (np. kartę SD) lub na pudełku i w innych materiałach dostępnych w momencie zakupu musi być informacja, że nośnik danych należy kupić osobno.

Jeśli implementacje urządzeń używają części niewymiennej pamięci masowej, aby spełnić powyższe wymagania, muszą:

NALEŻY użyć implementacji AOSP dotyczącej wewnętrznego udostępnionego miejsca na dane aplikacji.
MOŻE udostępniać miejsce na dane aplikacji z danymi prywatnymi.

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB, muszą:

[C-3-1] Musisz udostępnić mechanizm dostępu do danych na współdzielonym magazynie aplikacji z komputera hosta.
NALEŻY udostępniać treści z obu ścieżek pamięci w przejrzysty sposób za pomocą usługi skanowania multimediów w Androidzie i android.provider.MediaStore.
Możesz użyć pamięci masowej USB, ale musisz użyć protokołu Media Transfer Protocol, aby spełnić ten wymóg.

Jeśli implementacje urządzeń mają port USB z trybem urządzenia peryferyjnego USB i obsługują protokół Media Transfer Protocol, to:

Powinien być zgodny z hostem MTP na Androidzie, czyli aplikacją Android File Transfer.
NALEŻY podać klasę urządzenia USB 0x00.
Powinien zwracać nazwę interfejsu USB „MTP”.

7.6.3. Pamięć dostosowywana

Jeśli urządzenie ma być mobilne (w przeciwieństwie do telewizora), implementacje urządzenia muszą:

[SR] MOCNO ZALECAMY stosowanie przenośnego miejsca na dane w stabilnej lokalizacji, ponieważ przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

Jeśli port wymiennego urządzenia pamięci masowej znajduje się w stabilnym miejscu, np. w komorze baterii lub innej osłonie ochronnej, implementacje urządzenia muszą:

[SR] ZDECYDOWANIE POLECAMY wdrożenie pamięci dostosowywanej.

7.7. USB

Jeśli implementacje urządzeń mają port USB, muszą:

POWINIEN obsługiwać tryb urządzenia peryferyjnego USB i tryb hosta USB.

7.7.1. Tryb urządzenia peryferyjnego USB

Jeśli implementacje urządzenia obejmują port USB obsługujący tryb peryferyjny:

[C-1-1] Port MUSI umożliwiać połączenie z hostem USB, który ma standardowy port USB typu A lub C.
[C-1-2] W standardowym opisie urządzenia USB (android.os.Build.SERIAL) MUSI być podana prawidłowa wartość iSerialNumber.
[C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem rezystancyjnego ładowania typu C oraz MUSI wykrywać zmiany w reklamie, jeśli obsługuje USB typu C.
[SR] Port powinien używać formatu USB micro-B, micro-AB lub Type-C. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
[SR] Port powinien znajdować się na dole urządzenia (zgodnie z naturalną orientacją) lub umożliwiać obrócenie ekranu w ramach oprogramowania we wszystkich aplikacjach (w tym na ekranie głównym), aby wyświetlacz był prawidłowo wyświetlany, gdy port znajduje się na dole. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, aby można było uaktualnić je do przyszłych wersji platformy.
[SR] NALEŻY wdrożyć obsługę poboru prądu 1, 5 A podczas szumowania i przesyłania danych w trybie HS zgodnie ze specyfikacją USB Battery Charging 1.2. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
[SR] MOCNO ZALECANA obsługa metod ładowania, które modyfikują napięcie Vbus poza poziomem domyślnym lub zmieniają role odbiornika/źródła, ponieważ może to spowodować problemy z kompatybilnością z ładowarkami lub urządzeniami, które obsługują standardowe metody przesyłania mocy przez USB. Chociaż jest to „ZALECANA” opcja, w przyszłych wersjach Androida możemy wymagać, aby wszystkie urządzenia z typem C obsługiwały pełną interoperacyjność ze standardowymi ładowarkami typu C.
[SR] MOCNO POLECANE jest, aby obsługiwać Power Delivery do przesyłania danych i wymiany ról zasilania, gdy urządzenia obsługują USB typu C i tryb hosta USB.
POWINIEN obsługiwać Power Delivery do ładowania wysokiego napięcia i obsługiwać tryby alternatywne, takie jak wyświetlacz zewnętrzny.
NALEŻY zaimplementować interfejs API i specyfikację Android Open Accessory (AOA) zgodnie z dokumentacją pakietu Android SDK.

Jeśli implementacje urządzeń zawierają port USB i spełniają wymagania specyfikacji AOA, muszą:

[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ń zawierają port USB obsługujący tryb hosta, muszą:

[C-1-1] MUSI implementować interfejs API hosta USB Androida 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ć standardowe urządzenia peryferyjne USB, czyli MUSI:
- Urządzenie musi mieć port typu C lub być dostarczane z kablami umożliwiającymi dostosowanie portu własnego urządzenia do standardowego portu USB typu C (urządzenie z USB typu C).
- Urządzenie musi mieć port typu A lub być dostarczane z kablami umożliwiającymi dostosowanie portu własnego urządzenia do standardowego portu USB typu A.
- Urządzenie musi mieć port micro-AB, do którego DOSTARCZA się kabel dopasowujący do standardowego portu typu A.
[C-1-3] Nie wolno dostarczać adaptera do konwersji portów USB typu A lub mikro-AB na porty typu C (gniazdo).
[C-SR] MOCNO ZALECAMY implementację klasy audio USB zgodnie z dokumentacją pakietu SDK Androida.
POWINNY obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta; podawać prąd źródła co najmniej 1, 5 A zgodnie z sekcją Parametry zakończenia w specyfikacji kabla i złącza USB typu C w wersji 1.2 w przypadku złączy USB typu C lub używać portu podrzędnego ładowania(CDP) w zakresie prądu wyjściowego zgodnie z specyfikacją ładowania baterii USB w wersji 1.2 w przypadku złączy Micro-AB.
NALEŻY wdrożyć i obsługiwać standardy USB typu C.

Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i klasę audio USB, muszą:

[C-2-1] MUSI obsługiwać klasę USB HID.
[C-2-2] MUSI obsługiwać wykrywanie i mapowanie tych pól danych HID określonych w tabelach użycia USB HID i zapytaniu o użycie polecenia głosowego na stałe KeyEvent w ten sposób:
- Strona użycia (0xC) Identyfikator użycia (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- Strona z informacjami o użytkowaniu (0xC) Identyfikator użycia (0x0E9): KEYCODE_VOLUME_UP
- Strona Użycie (0xC) Identyfikator użycia (0x0EA): KEYCODE_VOLUME_DOWN
- Strona z informacjami o użytkowaniu (0xC) Identyfikator informacji o użytkowaniu (0x0CF): KEYCODE_VOICE_ASSIST

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i ramę Storage Access Framework (SAF), muszą:

[C-3-1] MUSI rozpoznawać wszystkie urządzenia połączone zdalnie przez protokół MTP (Media Transfer Protocol) i uzyskiwać dostęp do ich zawartości za pomocą intencji ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT. .

Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i USB typu C, muszą:

[C-4-1] MUSI implementować funkcję portu podwójnego zastosowania zgodnie ze specyfikacją USB Type-C (sekcja 4.5.1.3.3).
[SR] ZALECAMY obsługę interfejsu DisplayPort, obsługę interfejsu USB SuperSpeed oraz obsługę funkcji Power Delivery na potrzeby wymiany danych i mocy.
[SR] BARDZO ZALECAMY, aby nie obsługiwać trybu akcesoriów adaptera audio opisanego w Załączniku A w specyfikacji kabla i złącza USB typu C w wersji 1.2.
NALEŻY zastosować model Try.*, który najlepiej pasuje do formatu urządzenia. Na przykład urządzenie ręczne POWINNA stosować model Try.SNK.

7.8. Audio

7.8.1. mikrofon

Jeśli implementacje urządzeń zawierają mikrofon, muszą:

[C-1-1] NALEŻY podać stałą android.hardware.microphone.
[C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku podane w sekcji 5.4.
[C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku podane w sekcji 5.6.
[SR] ZALECAMY, aby obsługiwać nagrywanie w zakresie ultradźwięków zgodnie z opisem w sekcji 7.8.3.

Jeśli implementacje na urządzeniu pomijają mikrofon, mogą:

[C-2-1] NIE należy raportować stałej funkcji android.hardware.microphone.
[C-2-2] NALEŻY zaimplementować interfejs API do nagrywania dźwięku zgodnie z sekcją 7.

7.8.2. Wyjście audio

Jeśli implementacje urządzeń zawierają głośnik lub port wyjściowy audio/multimedia dla urządzeń peryferyjnych, takich jak 4-żyłowe gniazdo słuchawek 3,5 mm lub port w trybie hosta USB za pomocą klasy audio USB, muszą:

[C-1-1] NALEŻY podać stałą android.hardware.audio.output.
[C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku podane w sekcji 5.5.
[C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku podane w sekcji 5.6.
[SR] ZALECAMY, aby obsługiwać odtwarzanie zbliżone do ultradźwiękowego zgodnie z opisem w sekcji 7.8.3.

Jeśli implementacje urządzeń nie zawierają głośnika ani portu wyjściowego audio, nie mogą:

[C-2-1] NIE należy zgłaszać funkcji android.hardware.audio.output.
[C-2-2] NALEŻY zaimplementować interfejsy API związane z wyjściami audio jako co najmniej operacje niewymagające działania.

W celu tej sekcji „port wyjściowy” to interfejs fizyczny, taki jak gniazdo słuchawek 3, 5 mm, port HDMI lub port w trybie 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 kwalifikuje się jako „port wyjściowy”.

7.8.2.1. Gniazda analogowe

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 port analogowy do przesyłania dźwięku, muszą:

[C-SR] MOCNO ZALECAMY, aby co najmniej 1 port audio był 4-żyłowym gniazdem słuchawek 3,5 mm.

Jeśli implementacje urządzeń mają 4-żyłowe złącze jack 3,5 mm, muszą:

[C-1-1] Musi obsługiwać odtwarzanie dźwięku w słuchawkach stereo i zestawach słuchawkowych stereo z mikrofonem.
[C-1-2] MUSI obsługiwać wtyczki audio TRRS z kolejnością styków zgodną ze standardem CTIA.
[C-1-3] MUSI obsługiwać wykrywanie i mapowanie na kody klawiszy dla tych 3 zakresów impedancji równoważnej między mikrofonem a przewodami masy na złączu audio:
- 70 Ohm lub mniej: KEYCODE_HEADSETHOOK
- 210–290 Ω: KEYCODE_VOLUME_UP
- 360–680 ohm: KEYCODE_VOLUME_DOWN
[C-1-4] MUSI aktywować ACTION_HEADSET_PLUG po włożeniu wtyczki, ale dopiero wtedy, gdy wszystkie styki wtyczki dotykają odpowiednich segmentów w gnieździe.
[C-1-5] MUSI być w stanie wygenerować co najmniej 150 mV ± 10% napięcia wyjściowego przy impedancji głośnika 32 Ohm.
[C-1-6] Napięcie polaryzacji mikrofonu MUSI mieścić się w zakresie 1,8–2,9 V.
[C-1-7] MUSI wykrywać i mapować kody kluczy dla następującego zakresu impedancji pozornej między mikrofonem a przewodami masy na wtyczce audio:
- 110–180 om: KEYCODE_VOICE_ASSIST
[C-SR] ZALECAMY obsługę wtyczek audio z kolejnością styków OMTP.
[C-SR] MOCNO POLECAMY obsługę nagrywania dźwięku z zestawów słuchawkowych stereo z mikrofonem.

Jeśli implementacje urządzeń mają 4-żyłowe gniazdo słuchawek 3,5 mm i obsługują mikrofon, a także nadają android.intent.action.HEADSET_PLUG z dodatkową wartością mikrofonu ustawioną jako 1, to:

[C-2-1] MUSI obsługiwać wykrywanie mikrofonu w podłączonym urządzeniu audio.

7.8.2.2. Porty dźwięku cyfrowego

Zgodność ze słuchawkami i innymi urządzeniami audio korzystającymi z złączy USB-C i implementującymi (klasa audio USB) w ekosystemie Androida zgodnie ze specyfikacją zestawów słuchawkowych USB na Androida.

Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.2.1.

7.8.3. Zbliżenie ultradźwiękowe

Dźwięk w zakresie ultradźwięku to pasmo od 18,5 kHz do 20 kHz.

Implementacje na urządzeniu:

MUSI prawidłowo zgłaszać obsługę funkcji dźwięku w zakresie ultradźwięków za pomocą interfejsu AudioManager.getProperty API w ten sposób:

Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND ma wartość „true”, źródła dźwięku VOICE_RECOGNITION i UNPROCESSED MUSZĄ spełniać te wymagania:

[C-1-1] Średnia moc wyjściowa mikrofonu w zakresie 18,5–20 kHz MUSI być niższa o nie więcej niż 15 dB od wartości w zakresie 2 kHz.
[C-1-2] Współczynnik sygnału do szumu mikrofonu bez ważenia w zakresie 18,5–20 kHz dla tonu 19 kHz przy -26 dBFS MUSI wynosić co najmniej 50 dB.

Jeśli PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „prawda”:

[C-2-1] Średnia wartość głośnika w zakresie 18,5–20 kHz MUSI być wyższa o co najmniej 40 dB od wartości w zakresie 2 kHz.

7.8.4. Integralność sygnału

Implementacje na urządzeniach: * NALEŻY zapewnić ścieżkę sygnału audio bez zakłóceń zarówno dla strumieni wejściowych, jak i wyjściowych na urządzeniach przenośnych, co oznacza brak zakłóceń zmierzonych podczas testu trwającego minutę na ścieżce. Przeprowadź test za pomocą [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) „Automated Glitch Test”.

Test wymaga przejściówki audio, która jest używana bezpośrednio w gniazdku słuchawek 3,5 mm lub w połączeniu z przejściówką USB-C na 3,5 mm. NALEŻY przetestować wszystkie porty wyjściowe audio.

OboeTester obsługuje obecnie ścieżki AAudio, więc należy przetestować te kombinacje, aby wykryć błędy w AAudio:

Tryb wydajności	Udostępnianie	Częstotliwość próbkowania wyjściowego	W chansach	Out Chans
LOW_LATENCY	EKSKLUZYWNE	BRAK DANYCH	1	2
LOW_LATENCY	EKSKLUZYWNE	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 przypadku stosunku sygnału do szumu (SNR) i całkowitego zniekształcenia harmonicznego (THD) dla częstotliwości 2000 Hz.

Przetwornik	THD	SNR
główny wbudowany głośnik, zmierzony za pomocą zewnętrznego mikrofonu referencyjnego	< 3,0%	>= 50 dB
główny wbudowany mikrofon, zmierzony za pomocą zewnętrznego głośnika referencyjnego;	< 3,0%	>= 50 dB
wbudowane analogowe gniazda 3,5 mm, testowane przy użyciu adaptera pętli;	<1%	>= 60 dB
Adaptery USB dostarczane z telefonem, testowane przy użyciu adaptera pętli zwrotnej	< 1,0%	>= 60 dB

7.9. Rzeczywistość wirtualna

Android zawiera interfejsy API i funkcje do tworzenia aplikacji do rzeczywistości wirtualnej (VR), w tym aplikacji do mobilnej rzeczywistości wirtualnej o wysokiej jakości. Implementacje na urządzeniach MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z opisem w tej sekcji.

7.9.1. Tryb rzeczywistości wirtualnej

Android obsługuje tryb VR, który umożliwia renderowanie powiadomień w stereoskopowym obrazie i wyłącza monokularne komponenty interfejsu systemu, gdy aplikacja VR ma na siebie nałożony fokus użytkownika.

7.9.2. Tryb rzeczywistości wirtualnej – wysoka wydajność

Jeśli implementacje urządzeń obsługują tryb VR, to:

[C-1-1] Musisz mieć co najmniej 2 rdzenie fizyczne.
[C-1-2] NALEŻY zadeklarować funkcję android.hardware.vr.high_performance.
[C-1-3] MUSI obsługiwać tryb ciągłej wydajności.
[C-1-4] MOCNO ZALECAMY obsługę OpenGL ES 3.2.
[C-1-5] MUST support android.hardware.vulkan.level 0.
NALEŻY obsługiwać android.hardware.vulkan.level 1 lub nowszą.
[C-1-6] NALEŻY wdrożyć 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 i EGL_EXT_image_gl_colorspace oraz udostępnić je na liście dostępnych rozszerzeń EGL.
[C-1-8] NALEŻY zaimplementować GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures i ujawnić te rozszerzenia na liście dostępnych rozszerzeń GL.
[C-SR] ZALECAMY wdrażanie rozszerzeń GL_EXT_external_buffer, GL_EXT_EGL_image_array i GL_OVR_multiview_multisampled_render_to_texture oraz dodawanie ich do listy dostępnych rozszerzeń GL.
[C-SR] Zdecydowanie zalecamy obsługę Vulkan 1.1.
[C-SR] BARDZO ZALECAMY wdrożenie VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing i VK_KHR_shared_presentable_image oraz dodanie go do listy dostępnych rozszerzeń Vulkan.
[C-SR] MOCNO zalecamy udostępnienie co najmniej 1 rodziny kolejek Vulkan, w której flags zawiera zarówno VK_QUEUE_GRAPHICS_BIT, jak i VK_QUEUE_COMPUTE_BIT, a wartość queueCount wynosi co najmniej 2.
[C-1-7] GPU i wyświetlacz MUSZĄ być w stanie zsynchronizować dostęp do wspólnego bufora przedniego w taki sposób, aby renderowanie treści VR z wymiennym renderowaniem oczu z prędkością 60 FPS z dwoma kontekstami renderowania było wyświetlane bez widocznych artefaktów rozrywania obrazu.
[C-1-9] NALEŻY wdrożyć obsługę flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT zgodnie z opisem w NDK.
[C-1-10] NALEŻY wdrożyć obsługę AHardwareBuffer z dowolną kombinacją flag użycia AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT co najmniej w tych formatach: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR] ZALECAMY uwzględnienie w przydziale AHardwareBuffer więcej niż 1 warstwy 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 fps, skompresowane do średnio 40 Mb/s (co odpowiada 4 przypadkom 1920 x 1080 przy 30 fps i 10 Mb/s lub 2 przypadkom 1920 x 1080 przy 60 fps 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 fps skompresowanych do średnio 10 Mb/s i POWINNA być w stanie dekodować 3840 x 2160 przy 30 fps i 20 Mb/s (co odpowiada 4 przypadkom 1920 x 1080 przy 30 fps i 5 Mb/s).
[C-1-13] MUSI obsługiwać interfejs API HardwarePropertiesManager.getDeviceTemperatures i zwracać dokładne wartości temperatury skóry.
[C-1-14] Musi mieć wbudowany ekran o rozdzielczości co najmniej 1920 x 1080.
[C-SR] MOCNO ZALECAMY, aby rozdzielczość wyświetlacza wynosiła co najmniej 2560 x 1440.
[C-1-15] Wyświetlacz MUSI odświeżać obraz co najmniej z częstotliwością 60 Hz w trybie VR.
[C-1-17] Wyświetlacz MUSI obsługiwać tryb niskiej trwałości z trwałością do 5 ms, przy czym trwałość jest definiowana jako czas, przez który piksel emituje światło.
[C-1-18] MUSI obsługiwać rozszerzenie długości danych Bluetooth 4.2 i Bluetooth LE sekcja 7.4.3.
[C-1-19] MUSI obsługiwać i odpowiednio 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] MOCNO zalecamy obsługę typu kanału bezpośredniego TYPE_HARDWARE_BUFFER we wszystkich wymienionych powyżej typach kanałów bezpośrednich.
[C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru dla android.hardware.hifi_sensors, jak określono w sekcji 7.3.9.
[C-SR] MOCNO POLECAMY obsługę funkcji android.hardware.sensor.hifi_sensors.
[C-1-22] Musisz mieć opóźnienie od ruchu do fotonu nie większe niż 28 milisekund.
[C-SR] MOCNO ZALECAMY, aby opóźnienie od początku do końca procesu generowania ruchu do fotonu nie przekraczało 20 ms.
[C-1-23] Pierwszy obraz musi mieć współczynnik pierwszego obrazu, który jest stosunkiem jasności pikseli na pierwszym obrazie po przejściu od czerni do bieli i jasności białych pikseli w stanie ustalonym, wynoszącym co najmniej 85%.
[C-SR] ZALECAMY, aby współczynnik pierwszego kadru wynosił co najmniej 90%.
MOŻE udostępniać procesor wyłącznie aplikacji na pierwszym planie i MOŻE obsługiwać interfejs API Process.getExclusiveCores, aby zwracać liczby rdzeni procesora, które są dostępne wyłącznie dla aplikacji na pierwszym planie.

Jeśli obsługiwany jest rdzeń wyłączny, to:

[C-2-1] NIE MOŻE uruchamiać żadnych innych procesów 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

Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.2.1.

7.11. Klasa Media Performance

Klasę wydajności multimediów w implementacji urządzenia można uzyskać z interfejsu API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Wymagania dotyczące klasy skuteczności multimediów są zdefiniowane dla każdej wersji Androida, począwszy od R (wersja 30). Wartość specjalna 0 oznacza, że urządzenie nie należy do klasy wydajności multimediów.

Jeśli implementacje urządzeń zwracają wartość niezerową dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

[C-1-1] Musi zwracać co najmniej wartość android.os.Build.VERSION_CODES.R.
[C-1-2] Musi być implementacją na urządzeniu przenośnym.
[C-1-3] NALEŻY spełnić wszystkie wymagania dotyczące „Klasy skuteczności multimediów” opisane w sekcji 2.2.7.

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 są kluczowe dla wrażeń użytkownika i mają wpływ na założenia wyjściowe, które deweloperzy powinni uwzględnić podczas tworzenia aplikacji.

8.1. Spójność wrażeń użytkownika

Aby zapewnić płynne działanie interfejsu użytkownika, należy spełnić określone wymagania minimalne, które zagwarantują stałą liczbę klatek na sekundę i czas reakcji w przypadku aplikacji i gier. Wdrożenia na urządzeniach, w zależności od typu urządzenia, MOGĄ mieć mierzalne wymagania dotyczące opóźnień w interfejsie użytkownika i przełączania zadań, jak opisano w sekcji 2.

8.2. Wydajność dostępu do plików I/O

Udostępnienie wspólnej wartości granicznej dla spójnej wydajności dostępu do plików w ramach prywatnego miejsca na dane aplikacji (partycji /data) pozwala deweloperom aplikacji określić odpowiednie oczekiwania, które pomogą im w projektowaniu oprogramowania. W zależności od typu urządzenia implementacje MOŻE wymagać spełnienia określonych w sekcji 2 wymagań dotyczących tych operacji odczytu i zapisu:

Wydajność sekwencyjnego zapisu. Zmierzono podczas zapisywania pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
Skuteczność zapisu losowego. Zmierzono podczas zapisywania pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.
Wydajność sekwencyjnego odczytu. Zmierzono podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
Wydajność losowego odczytu. Zmierzono 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. grupa w stanie gotowości aplikacji, Doze), lub rozszerzają funkcje, które nie nakładają bardziej restrykcyjnych ograniczeń niż grupa w stanie gotowości rzadko używanych aplikacji, muszą:

[C-1-1] NIE MOŻE odbiegać od implementacji AOSP w przypadku algorytmów uruchamiania, konserwacji i budzenia oraz globalnych ustawień systemu w trybach oszczędzania energii App Standby i Doze.
[C-1-2] NIE MOŻE odbiegać od implementacji AOSP w zakresie korzystania z ustawień globalnych do zarządzania ograniczeniem szybkości wykonywania zadań, alarmów i sieci w przypadku aplikacji w każdej grupie w trybie czuwania aplikacji.
[C-1-3] Liczba poziomów aplikacji w stanie gotowości używanych w przypadku aplikacji w stanie gotowości MUSI ZGADAJAĆ SIĘ z implementacją AOSP.
[C-1-4] NALEŻY wdrożyć grupy aplikacji w stanie gotowości i tryb Doze zgodnie z opisem w Zarządzanie energią.
[C-1-5] W trybie oszczędzania energii urządzenie true musi PowerManager.isPowerSaveMode() zwracać true.
[C-SR] MOCNO ZALECAMY, aby umożliwić użytkownikom włączanie i wyłączanie funkcji oszczędzania baterii.
[C-SR] ZDECYDOWANIE zalecamy, aby umożliwić użytkownikom wyświetlanie wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.

Jeśli implementacje na urządzeniach rozszerzają funkcje zarządzania energią zawarte w AOSP, a rozszerzenie stosuje bardziej rygorystyczne ograniczenia niż kategoria aplikacji rzadko używanych, zapoznaj się z sekcją 3.5.1.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ wykorzystywać 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 zgodnie z definicją ACPI, muszą:

[C-1-1] MUST enter this state only after the user has taken an explicit action to put the device in an inactive state (e.g. by closing a lid that is physically part of the device or turning off a vehicle or television) and before the user re-activates the device (e.g. by opening the lid or turning the vehicle or television back on).

Jeśli implementacje urządzeń implementują stany zasilania S3 zgodnie z definicją ACPI, muszą:

[C-2-1] MUSI spełniać wymagania podane w sekcji C-1-1 lub MUSI wejść w stan S3 tylko wtedy, gdy aplikacje innych firm nie potrzebują zasobów systemowych (np. ekranu czy procesora).

Z drugiej strony, gdy aplikacje innych firm potrzebują zasobów systemowych, muszą opuścić stan S3, zgodnie z opisem w tym pakiecie SDK.

Podczas gdy aplikacje innych firm proszą o utrzymanie ekranu w stanie włączonym (FLAG_KEEP_SCREEN_ON) lub uruchomionego procesora (PARTIAL_WAKE_LOCK), urządzenie NIE MOŻE przejść w stan S3, chyba że użytkownik wykona wyraźne działanie, aby umieścić urządzenie w stanie nieaktywnym, jak opisano w sekcji C-1-1. Z drugiej strony, gdy uruchamiane jest zadanie implementowane przez aplikacje innych firm za pomocą JobSchedulera lub gdy aplikacje innych firm otrzymują wiadomości z Komunikacji w chmurze Firebase, urządzenie MUSI opuścić stan S3, chyba że użytkownik przełączy je w stan nieaktywny. To nie są wyczerpujące przykłady, ponieważ AOSP implementuje rozbudowane sygnały budzenia, które powodują wybudzanie z tego stanu.

8.4. Rachunkowość zużycia energii

Dokładniejsze rozliczanie i raportowanie zużycia energii daje deweloperowi aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorców zużycia energii przez aplikację.

Implementacje na urządzeniu:

[SR] BARDZO ZALECAMY podanie profilu zużycia energii dla poszczególnych komponentów, który definiuje bieżącą wartość zużycia energii dla każdego komponentu sprzętowego oraz przybliżony pobór energii z baterii spowodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
[SR] ZDECYDOWANIE POLECAMY podawanie wszystkich wartości zużycia energii w miliamperogodzinach (mAh).
[SR] ZDECYDOWANIE POLECAMY raportowanie zużycia energii procesora dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
[SR] ZDECYDOWANIE POLECANE: udostępnij ten tryb zużycia energii za pomocą polecenia adb shell dumpsys batterystats w powłoce dla dewelopera aplikacji.
POWINIEN być przypisany do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.

8.5. Spójna wydajność

Wydajność może się znacznie wahać w przypadku aplikacji o wysokiej wydajności i długim czasie działania z powodu innych aplikacji działających w tle lub ograniczania procesora z powodu limitów temperatury. Android zawiera interfejsy programowe, dzięki którym aplikacja na pierwszym planie może poprosić system o zoptymalizowanie przydziału zasobów w celu łagodzenia takich wahań.

Implementacje na urządzeniu:

[C-0-1] NALEŻY prawidłowo zgłaszać obsługę trybu Sustained Performance za pomocą metody interfejsu API PowerManager.isSustainedPerformanceModeSupported().
Powinien obsługiwać tryb ciągłej wydajności.

Jeśli implementacje urządzeń zgłaszają obsługę trybu ciągłej wydajności, to:

[C-1-1] Musisz zapewnić najwyższej aplikacji na pierwszym planie spójny poziom wydajności przez co najmniej 30 minut, gdy aplikacja tego zażąda.
[C-1-2] MUSI obsługiwać interfejs API Window.setSustainedPerformanceMode() i inne powiązane interfejsy API.

Jeśli implementacje urządzeń zawierają co najmniej 2 rdzenie procesora, muszą:

NALEŻY zapewnić co najmniej 1 rdzeń, który może być zarezerwowany przez aplikację na pierwszym planie.

Jeśli implementacje urządzeń obsługują rezerwowanie 1 rdzenia wyłącznie dla głównej aplikacji na pierwszym planie, to:

[C-2-1] Musisz przekazać za pomocą metody interfejsu API Process.getExclusiveCores() numery identyfikatorów zasobów, które mogą być zarezerwowane przez aplikację na pierwszym planie.
[C-2-2] Nie wolno zezwalać na uruchamianie na rdzeniach wyłącznych żadnych procesów w przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację, ale można zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.

Jeśli implementacje urządzeń nie obsługują rdzenia wyłącznego, nie:

[C-3-1] Musi zwracać pustą listę za pomocą metody interfejsu API Process.getExclusiveCores().

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniu:

[C-0-1] NALEŻY wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji interfejsów API w dokumentacji dla deweloperów Androida.
[C-0-2] MUSI obsługiwać instalowanie samodzielnie podpisanych aplikacji bez konieczności uzyskiwania dodatkowych uprawnień lub certyfikatów od stron trzecich/autorytetów. W szczególności kompatybilne urządzenia MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w następnych podrozdziałach.

9.1. Uprawnienia

Implementacje na urządzeniu:

[C-0-1] Musi obsługiwać model uprawnień Androida zgodnie z definicją w dokumentacji dla deweloperów Androida. W szczególności muszą one egzekwować wszystkie uprawnienia zdefiniowane w dokumentacji pakietu SDK. Żadnych uprawnień nie można pominąć, zmienić ani zignorować.
MOŻESZ dodać dodatkowe uprawnienia, o ile nowe ciągi identyfikatorów uprawnień nie znajdują się w przestrzeni nazw android.\*.
[C-0-2] Uprawnienia z protectionLevel PROTECTION_FLAG_PRIVILEGED MUSZĄ być przyznawane tylko aplikacjom wstępnie zainstalowanym na ścieżkach uprzywilejowanych obrazu systemu i w ramach podzbioru uprawnień dozwolonych w przypadku każdej aplikacji. Implementacja AOSP spełnia ten wymóg, odczytując i przestrzegając uprawnień dozwolonych dla każdej aplikacji z plików na ścieżce etc/permissions/ i korzystając ze ścieżki system/priv-app jako ścieżki uprzywilejowanej.

Uprawnienia z poziomem ochrony niebezpieczny to uprawnienia czasu działania. Aplikacje z targetSdkVersion > 22 żądają ich w czasie wykonywania.

Implementacje na urządzeniu:

[C-0-3] Musisz wyświetlić użytkownikowi specjalny interfejs, aby umożliwić mu podjęcie decyzji, czy przyznać żądane uprawnienia w czasie działania, a także udostępnić interfejs do zarządzania uprawnieniami w czasie działania.
[C-0-4] Musisz mieć jedną i tylko jedną implementację obu interfejsów użytkownika.
[C-0-5] NIE NALEŻY przyznawać żadnych uprawnień w czasie działania w przypadku wstępnie zainstalowanych aplikacji, chyba że:
- Zgoda użytkownika może zostać uzyskana przed użyciem danych przez aplikację.
- Uprawnienia w czasie działania są powiązane z wzorcem intencji, dla którego domyślnym modułem obsługi jest wstępnie zainstalowana aplikacja.
[C-0-6] NALEŻY przyznać uprawnienie android.permission.RECOVER_KEYSTORE tylko aplikacjom systemowym, które rejestrują odpowiednio zabezpieczonego agenta odzyskiwania danych. Prawidłowo zabezpieczony agent odzyskiwania to oprogramowanie na urządzeniu, które synchronizuje się z zdalnymi miejscami na dane poza urządzeniem. Takie miejsce na dane jest wyposażone w sprzęt z ochroną na poziomie równoważnym lub wyższym niż w usłudze Google Cloud Key Vault, aby zapobiec atakom z wykorzystaniem metody brute force na czynniku wiedzy na ekranie blokady.

Implementacje na urządzeniu:

[C-0-7] Aplikacja MUSI przestrzegać właściwości uprawnień dotyczących lokalizacji na Androidzie, gdy prosi o dane o lokalizacji lub aktywności fizycznej za pomocą standardowego interfejsu API Androida lub zastrzeżonego mechanizmu. Dane te obejmują:
- lokalizacja urządzenia (np. szerokość i długość geograficzna).
- Informacje, które mogą służyć do określenia lub oszacowania lokalizacji urządzenia (np. SSID, BSSID, identyfikator komórki lub lokalizacja sieci, z którą jest połączone urządzenie).
- Aktywność fizyczna użytkownika lub klasyfikacja tej aktywności.

W szczególności dotyczy to implementacji na urządzeniach:

[C-0-8] Musisz uzyskać zgodę użytkownika na dostęp aplikacji do danych o lokalizacji lub aktywności fizycznej.
[C-0-9] MUST grant a runtime permission ONLY to the app that holds sufficient permission as described on SDK. Na przykład: TelephonyManager#getServiceState wymaga android.permission.ACCESS_FINE_LOCATION.

Uprawnienia mogą być oznaczone jako ograniczone, co zmienia ich działanie.

[C-0-10] Uprawnienia oznaczone flagą hardRestricted NIE MOGĄ zostać przyznane aplikacji, chyba że:
- Plik APK aplikacji znajduje się na partycji systemowej.
- Użytkownik przypisuje do aplikacji rolę powiązaną z uprawnieniami hardRestricted.
- Instalator przyznaje aplikacji uprawnienia hardRestricted.
- Aplikacja ma przyznane uprawnienie hardRestricted w poprzedniej 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 w sposób opisany w pakiecie SDK, w którym zdefiniowano pełny i ograniczony dostęp dla każdego uprawnienia softRestricted (np. READ_EXTERNAL_STORAGE).

Jeśli implementacje na urządzeniu umożliwiają użytkownikowi wybranie aplikacji, które mogą rysować na innych aplikacjach za pomocą aktywności obsługującej intencję ACTION_MANAGE_OVERLAY_PERMISSION, to:

[C-2-1] Należy zadbać o to, aby wszystkie czynności z filtrami intencji dla intencji ACTION_MANAGE_OVERLAY_PERMISSION miały ten sam ekran interfejsu niezależnie od aplikacji inicjującej lub informacji, które ona udostępnia.

9.2. UID i izolacja procesów

Implementacje na urządzeniu:

[C-0-1] Musi obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja działa jako unikalny identyfikator UID w stylu Unixa i w oddzielnym procesie.
[C-0-2] MUSI obsługiwać uruchamianie wielu aplikacji z użyciem tego samego identyfikatora użytkownika Linuxa, o ile aplikacje są prawidłowo podpisane i skonstruowane zgodnie z definicją w dokumentacji dotyczącej zabezpieczeń i uprawnień.

9.3. Uprawnienia do systemu plików

Implementacje na urządzeniu:

[C-0-1] MUSI obsługiwać model uprawnień dostępu do plików w Androidzie zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień.

9.4. Alternatywne środowiska wykonawcze

Implementacje urządzeń MUSZĄ zachować spójność modelu zabezpieczeń i uprawnień Androida, nawet jeśli zawierają środowiska uruchomieniowe, które wykonują aplikacje za pomocą innego oprogramowania lub technologii niż format wykonywalny Dalvik czy kod natywny. Krótko mówiąc:

[C-0-1] Alternatywny czas wykonywania MUSI być aplikacją na Androida i stosować standardowy model zabezpieczeń Androida, jak opisano w sekcji 9.
[C-0-2] Alternatywnym środowiskom uruchomieniowym NIE MOŻNA przyznawać dostępu do zasobów chronionych przez uprawnienia, których nie żądano w pliku AndroidManifest.xml środowiska uruchomieniowego za pomocą mechanizmu <uses-permission>.
[C-0-3] Alternatywny czas wykonywania NIE MOŻE zezwalać aplikacjom na korzystanie z funkcji chronionych przez uprawnienia Androida, które są ograniczone do aplikacji systemowych.
[C-0-4] Alternatywne środowisko uruchomieniowe MUSI być zgodne z modelem piaskownicy Androida, a zainstalowane aplikacje korzystające z alternatywnego środowiska uruchomieniowego NIE MOGĄ ponownie używać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida dotyczących udostępnionego identyfikatora użytkownika i certyfikatu podpisywania.
[C-0-5] Alternatywny środowisko uruchomieniowe NIE MOŻE uruchamiać, przyznawać ani uzyskiwać dostępu do piaskownicy odpowiadającej innym aplikacjom na Androida.
[C-0-6] Alternatywny czas wykonywania NIE MOŻE być uruchamiany z uprawnieniami superużytkownika (root) ani nie może przyznawać takich uprawnień innym aplikacjom. Nie może też przyznawać uprawnień innym aplikacjom.
[C-0-7] Jeśli pliki .apk alternatywnych środowisk wykonawczych są zawarte w pliku obrazu systemu implementacji urządzenia, muszą być podpisane za pomocą klucza innego niż klucz używany do podpisywania innych aplikacji zawartych w implementacjach urządzenia.
[C-0-8] Podczas instalowania aplikacji alternatywne środowisko uruchomieniowe MUSI uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację.
[C-0-9] Gdy aplikacja potrzebuje zasobu urządzenia, dla którego istnieje odpowiednie uprawnienie Androida (np. aparat, GPS itp.), alternatywny czas wykonywania MUSI poinformować użytkownika, że aplikacja będzie mieć dostęp do tego zasobu.
[C-0-10] Jeśli środowisko uruchomieniowe nie rejestruje w taki sposób możliwości aplikacji, MUSI ono podać wszystkie uprawnienia posiadane przez środowisko uruchomieniowe podczas instalowania dowolnej aplikacji korzystającej z tego środowiska.
Alternatywny czas wykonywania POWINIEN instalować aplikacje za pomocą PackageManager w oddzielnych piaskownicach Androida (identyfikatory użytkowników systemu Linux itp.).
Alternatywny czas wykonywania MOŻE udostępniać jedną piaskownicę Androida, która jest wspólna dla wszystkich aplikacji korzystających z alternatywnego czasu wykonywania.

9,5. Pomoc dla wielu użytkowników

Android obsługuje wielu użytkowników i pozwala na pełną izolację użytkowników.

Implementacje urządzeń MOGĄ, ale NIE POWINNY umożliwiać korzystania z wielu użytkowników, jeśli używają wymiennych nośników danych jako głównej pamięci zewnętrznej.

Jeśli implementacje urządzeń obejmują wielu użytkowników, muszą one:

[C-1-1] MUSI spełniać te wymagania dotyczące obsługi wielu użytkowników.
[C-1-2] W przypadku każdego użytkownika należy wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji referencyjnej Zasady zabezpieczeń i uprawnień dotyczącej interfejsów API.
[C-1-3] W przypadku każdego wystąpienia użytkownika MUSISZ mieć osobne, odizolowane katalogi współdzielonego miejsca na dane aplikacji (czyli /sdcard).
[C-1-4] NALEŻY zadbać o to, aby aplikacje należące do danego użytkownika i uruchamiane w jego imieniu nie mogły wyświetlać, odczytywać ani zapisywać plików należących do innego użytkownika, nawet jeśli dane obu użytkowników są przechowywane w tym samym woluminie lub systemie plików.
[C-1-5] NALEŻY szyfrować zawartość karty SD, gdy włączona jest obsługa wielu użytkowników, za pomocą klucza przechowywanego tylko na niewymiennym nośniku, dostępnego tylko dla systemu, jeśli implementacje urządzeń używają wymiennych nośników dla interfejsów API zewnętrznego miejsca na dane. Ponieważ w takim przypadku media nie będą czytelne dla komputera hosta, implementacje urządzeń będą musiały przejść na MTP lub podobny system, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika.

9,6. Ostrzeżenie dotyczące SMS-ów specjalnych

Android obsługuje ostrzeżenia użytkowników o wysyłanych SMS-ach premium. SMS-y premium to wiadomości tekstowe wysyłane do usługi zarejestrowanej u operatora, za którą użytkownik może zostać obciążony opłatą.

Jeśli implementacje na urządzeniach deklarują obsługę android.hardware.telephony, muszą:

[C-1-1] NALEŻY ostrzegać użytkowników przed wysłaniem SMS-a do numerów zdefiniowanych za pomocą wyrażeń regularnych w pliku /data/misc/sms/codes.xml na urządzeniu. Dostępny w górę projektu Android Open Source Project zapewnia implementację, która spełnia ten wymóg.

9,7. Funkcje zabezpieczeń

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń w jądrze i na platformie, jak opisano poniżej.

Piaskownica Androida zawiera funkcje korzystające z systemu kontroli dostępu (MAC) Security-Enhanced Linux (SELinux), piaskownicy seccomp i innych funkcji zabezpieczeń w jądrze systemu Linux. Implementacje na urządzeniu:

[C-0-1] Musi być zgodny z dotychczasowymi aplikacjami, nawet jeśli SELinux lub inne funkcje zabezpieczeń są implementowane poniżej platformy Android.
[C-0-2] Nie wolno stosować widocznego interfejsu użytkownika, gdy naruszenie bezpieczeństwa zostanie wykryte i skutecznie zablokowane przez funkcję zabezpieczeń zaimplementowaną poniżej platformy Android, ale można użyć widocznego interfejsu użytkownika, gdy nie zablokowane naruszenie bezpieczeństwa spowoduje skuteczne wykorzystanie luki.
[C-0-3] Nie wolno zezwalać użytkownikowi ani deweloperowi aplikacji na konfigurowanie SELinux ani innych funkcji zabezpieczeń implementowanych poniżej platformy Android.
[C-0-4] Nie wolno zezwalać aplikacji, która może wpływać na inną aplikację za pomocą interfejsu API (np. interfejsu Device Administration API), na konfigurowanie zasad, które naruszają zgodność.
[C-0-5] NALEŻY podzielić framework multimediów na kilka procesów, aby umożliwić bardziej precyzyjne przyznawanie dostępu do poszczególnych procesów, zgodnie z opisem na stronie projektu Android Open Source.
[C-0-6] NALEŻY zaimplementować mechanizm piaskownicy aplikacji jądra, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnych zasad z programów wielowątkowych. Projekt Android Open Source na upstreamie spełnia ten wymóg dzięki włączeniu seccomp-BPF z synchronizacją wątków grup (TSYNC), jak opisano w sekcji Konfiguracja jądra na stronie source.android.com.

Funkcje integralności i samoochrony jądra są integralną częścią zabezpieczeń Androida. Implementacje na urządzeniu:

[C-0-7] NALEŻY wdrożyć mechanizmy ochrony przed przepełnieniem bufora stosu jądra. Przykładami takich mechanizmów są CC_STACKPROTECTOR_REGULAR i CONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] NALEŻY wdrożyć ścisłe zabezpieczenia pamięci jądra, w których kod wykonywalny jest tylko do odczytu, dane tylko do odczytu są tylko do odczytu i nie do zapisu, a dane tylko do zapisu są tylko do zapisu (np. CONFIG_DEBUG_RODATA lub CONFIG_STRICT_KERNEL_RWX).
[C-0-9] NALEŻY zaimplementować sprawdzanie granic rozmiaru statycznych i dynamicznych obiektów w kopiach między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY) na urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym.
[C-0-10] NIE WOLNO wykonywać kodu w pamięci na poziomie użytkownika podczas działania w trybie jądra (np. sprzętowego PXN lub emulowanego za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym.
[C-0-11] NIE MOŻESZ odczytywać ani zapisywać danych w pamięci użytkownika w rdzeniu poza normalnymi interfejsami API dostępu do danych użytkownika (np. interfejs API sterowania sprzętem lub emulowany za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach pierwotnie dostarczanych z interfejsem API na poziomie 28 lub wyższym.
[C-0-12] NALEŻY zaimplementować izolację tabeli stron jądra, jeśli sprzęt jest podatny na atak CVE-2017-5754 na wszystkich urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym (np. CONFIG_PAGE_TABLE_ISOLATION lub CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] NALEŻY wdrożyć wzmocnienie przewidywania rozgałęzi, jeśli sprzęt jest podatny na atak CVE-2017-5715 na wszystkich urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym (np. CONFIG_HARDEN_BRANCH_PREDICTOR).
[SR] MOCNO ZALECANA jest zmiana po inicjalizacji danych jądra, które są zapisywane tylko podczas inicjalizacji, na dane tylko do odczytu (np. __ro_after_init).
[C-SR] Zdecydowanie zalecamy losowanie rozkładu kodu jądra i pamięci oraz unikanie sytuacji, które mogłyby zagrozić losowości (np. CONFIG_RANDOMIZE_BASE z entropią programu rozruchowego za pomocą /chosen/kaslr-seed Device Tree node lub EFI_RNG_PROTOCOL).
[C-SR] ZALECAMY WŁĄCZENIE integralności przepływu sterowania (CFI) w jądrze, aby zapewnić dodatkową ochronę przed atakami polegającymi na ponownym użyciu kodu (np. CONFIG_CFI_CLANG i CONFIG_SHADOW_CALL_STACK).
[C-SR] W przypadku komponentów, w których są włączone mechanizmy CFI, SCS lub IntSan, MOCNO zalecamy, aby ich nie wyłączać.
[C-SR] WYJĄTKOWO zalecamy włączenie CFI, SCS i IntSan w przypadku wszystkich dodatkowych komponentów przestrzeni użytkownika, które są wrażliwe na zagrożenia związane z bezpieczeństwem, zgodnie z opisem w artykułach CFI i IntSan.
[C-SR] W przypadku urządzeń z systemem Linux MOCNO zalecamy włączenie inicjalizacji stosu w rdzeniu, aby zapobiec używaniu niezinicjowanych zmiennych lokalnych (CONFIG_INIT_STACK_ALL lub CONFIG_INIT_STACK_ALL_ZERO). Implementacje na urządzeniach NIE powinny też zakładać wartości używanej przez kompilator do inicjalizacji zmiennych lokalnych.
[C-SR] ZALECAMY WYMAGANIE inicjalizacji stosu w jądrze, aby zapobiec używaniu nieinicjalizowanych alokacji stosu (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). Nie należy zakładać wartości używanej przez jądro do inicjalizacji tych alokacji.

Jeśli implementacje urządzeń korzystają z jądra Linuksa, muszą:

[C-1-1] NALEŻY wdrożyć SELinux.
[C-1-2] NALEŻY ustawić SELinux na tryb globalny.
[C-1-3] NALEŻY skonfigurować wszystkie domeny w trybie wymuszania. Niedozwolone są domeny w trybie dozwolonym, w tym domeny związane z urządzeniem lub dostawcą.
[C-1-4] Nie wolno modyfikować, pomijać ani zastępować reguł neverallow znajdujących się w folderze system/sepolicy udostępnianym w ramach projektu upstream Android Open Source (AOSP). Polityka MUSI być zgodna ze wszystkimi regułami neverallow, zarówno w przypadku domen AOSP SELinux, jak i w przypadku domen konkretnych urządzeń lub dostawców.
[C-1-5] NALEŻY uruchamiać aplikacje innych firm przeznaczone dla interfejsu API w wersji 28 lub nowszej w oddzielnych piaskownicach SELinux dla każdej aplikacji z ograniczeniami SELinux dla każdej aplikacji w przypadku katalogu danych prywatnych każdej aplikacji.
NALEŻY zachować domyślną zasadę SELinux udostępnioną w folderze system/sepolicy w ramach projektu źródłowego Androida Open Source i tylko dodać do tej zasady własną konfigurację urządzenia.

Jeśli implementacje urządzeń zostały już uruchomione w poprzedniej wersji Androida i nie spełniają wymagań [C-1-1] i [C-1-5] w ramach aktualizacji oprogramowania systemowego, MOGĄ być zwolnione z tych wymagań.

Jeśli implementacje urządzeń używają jądra innego niż Linux:

[C-2-1] NALEŻY używać systemu obowiązkowej kontroli dostępu, który jest odpowiednikiem SELinux.

Android zawiera wiele funkcji zabezpieczeń, które są integralną częścią zabezpieczeń urządzenia.

9,8. Prywatność

9.8.1. Historia użycia

Android przechowuje historię wyborów użytkownika i zarządza nią za pomocą UsageStatsManager.

Implementacje na urządzeniu:

[C-0-1] NALEŻY zachować rozsądny okres przechowywania takiej historii użytkownika.
[SR] MOCNO ZALECAMY zachowanie okresu przechowywania wynoszącego 14 dni, który jest skonfigurowany domyślnie w implementacji AOSP.

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

Implementacje na urządzeniu:

[C-0-2] W raporcie o incydencie utworzonym przez klasę interfejsu System API IncidentManager MUSISZ uwzględnić tylko pola oznaczone jako DEST_AUTOMATIC.
[C-0-3] NIE WOLNO używać identyfikatorów zdarzeń systemowych do rejestrowania innych zdarzeń niż te opisane w dokumentach pakietu SDK StatsLog. Jeśli są rejestrowane dodatkowe zdarzenia systemowe, mogą one używać innego identyfikatora atomu w zakresie od 100 000 do 200 000.

9.8.2. Nagrywam

Implementacje na urządzeniu:

[C-0-1] NIE WOLNO wstępnie wczytywać ani rozpowszechniać 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 jego zgody lub bez wyraźnego powiadomienia.
[C-0-2] NALEŻY wyświetlić i uzyskać wyraźną zgodę użytkownika na rejestrowanie wszelkich poufnych informacji wyświetlanych na ekranie użytkownika, gdy włączone jest przesyłanie lub nagrywanie ekranu za pomocą interfejsów API MediaProjection lub zastrzeżonych interfejsów API. NIE MOŻESZ udostępnić użytkownikom opcji umożliwiającej wyłączenie wyświetlania prośby o zgodę.
[C-0-3] Podczas udostępniania ekranu lub nagrywania ekranu MUSI być wyświetlane ciągłe powiadomienie dla użytkownika. AOSP spełnia ten wymóg, wyświetlając ikonę powiadomienia na pasku stanu.

Jeśli implementacje urządzeń zawierają funkcje systemu, które umożliwiają rejestrowanie treści wyświetlanych na ekranie lub strumienia audio odtwarzanego na urządzeniu w inny sposób niż za pomocą interfejsu API systemu ContentCaptureService lub innych zastrzeżonych metod opisanych w sekcji 9.8.6 „Zapisywanie treści”, muszą:

[C-1-1] NALEŻY wyświetlać użytkownikowi ciągłe powiadomienie, gdy ta funkcja jest włączona i aktywnie rejestruje/nagrywa.

Jeśli implementacje urządzeń zawierają komponent, który jest domyślnie włączony i umożliwia nagrywanie dźwięku z otoczenia lub dźwięku odtwarzanego na urządzeniu w celu wywnioskowania przydatnych informacji o kontekście użytkownika, to:

[C-2-1] Nie wolno przechowywać w pamięci trwałej na urządzeniu ani przesyłać z urządzenia nagranego dźwięku w postaci surowych danych lub w dowolnym formacie, który można przekonwertować z powrotem na oryginalny dźwięk lub jego zbliżone kopie, z wyjątkiem sytuacji, gdy użytkownik wyrazi wyraźną zgodę.

9.8.3. Łączność

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB, muszą:

[C-1-1] NALEŻY wyświetlić interfejs z prośbą o zgodę użytkownika przed przyznaniem dostępu do zawartości wspólnego miejsca na dane przez port USB.

9.8.4. Ruch w sieci

Implementacje na urządzeniu:

[C-0-1] NALEŻY wstępnie zainstalować te same certyfikaty główne dla zaufanych urzędów certyfikacji (CA) w systemie, które zostały dostarczone w ramach projektu Android Open Source.
[C-0-2] Musi być dostarczany z pusta pamięcią głównego urzędu certyfikacji użytkownika.
[C-0-3] NALEŻY wyświetlić użytkownikowi ostrzeżenie, że ruch w sieci może być monitorowany, gdy dodawane jest główne zaufane urzędu certyfikacji użytkownika.

Jeśli ruch na urządzeniu jest kierowany przez VPN, implementacje urządzenia:

[C-1-1] MUSI wyświetlać użytkownikowi ostrzeżenie zawierające:
- Ruch w sieci może być monitorowany.
- Ruch sieciowy jest przekierowywany przez konkretną aplikację VPN, która zapewnia VPN.

Jeśli implementacje urządzeń mają mechanizm, który jest domyślnie włączony i przekierowuje ruch danych sieciowych przez serwer proxy lub bramę VPN (np. w ramach wstępnego wczytania usługi VPN z przyznanym uprawnieniem android.permission.CONTROL_VPN), to:

[C-2-1] NALEŻY poprosić o zgodę użytkownika przed włączeniem tego mechanizmu, chyba że VPN jest włączony przez kontroler zasad urządzenia za pomocą DevicePolicyManager.setAlwaysOnVpnPackage(). W tym przypadku użytkownik nie musi wyrażać osobnej zgody, ale NALEŻY go o to powiadomić.

Jeśli implementacje urządzeń umożliwiają użytkownikowi przełączanie funkcji „stały VPN” w aplikacji VPN innej firmy, muszą:

[C-3-1] W pliku AndroidManifest.xml należy DISABLE (WYŁĄCZ) tę funkcję dla aplikacji, które nie obsługują stałej usługi VPN. W tym celu należy ustawić atrybut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

9.8.5. Identyfikatory urządzeń

Implementacje na urządzeniu:

[C-0-1] Aplikacja NIE MOŻE umożliwiać dostępu do numeru seryjnego urządzenia ani, w stosownych przypadkach, numeru IMEI/MEID, numeru seryjnego karty SIM i identyfikatora IMSI, chyba że spełnia on co najmniej jeden z tych wymagań:
- jest podpisaną aplikacją operatora, która została zweryfikowana przez producentów urządzeń.
- otrzymało uprawnienie READ_PRIVILEGED_PHONE_STATE.
- ma uprawnienia operatora zdefiniowane w Uprawnieniach operatora UICC.
- jest właścicielem urządzenia lub właścicielem profilu, któremu przyznano uprawnienia READ_PHONE_STATE.
- (Tylko w przypadku numeru seryjnego karty SIM lub identyfikatora ICCID) zgodnie z lokalnymi przepisami aplikacja musi wykrywać zmiany tożsamości subskrybenta.

9.8.6. Rejestrowanie treści

Android, za pomocą interfejsu System API ContentCaptureService lub innych zastrzeżonych metod, obsługuje mechanizm umożliwiający implementacje urządzeń do rejestrowania interakcji między aplikacjami a użytkownikiem.

Tekst i grafika renderowane na ekranie, w tym między innymi powiadomienia i dane asystenta za pomocą interfejsu API AssistStructure.
dane multimedialne, takie jak dźwięk lub film, nagrane lub odtworzone przez urządzenie;
zdarzenia związane z wprowadzaniem danych (np. klawiatura, mysz, gesty, głos, wideo i dostępność);
wszelkie inne zdarzenia, które aplikacja przekazuje systemowi za pomocą interfejsu Content Capture API lub podobnego zastrzeżonego interfejsu API;
dowolny tekst lub inne dane wysyłane przez TextClassifier API do System TextClassifier, czyli do usługi systemowej, aby zrozumieć znaczenie tekstu, a także generować przewidywane następne działania na podstawie tekstu;

Jeśli implementacje urządzeń rejestrują powyższe dane, mogą:

[C-1-1] NALEŻY szyfrować wszystkie takie dane, gdy są przechowywane na urządzeniu. Szyfrowanie MOŻE być wykonywane za pomocą szyfrowania opartego na plikach w Androidzie lub dowolnego szyfru wymienionego jako wersja interfejsu API 26 lub nowsza w pakiecie Cipher SDK.
[C-1-2] NIE wolno tworzyć kopii zapasowych danych w postaci nieprzetworzonej lub zaszyfrowanej za pomocą metod tworzenia kopii zapasowej na Androidzie ani żadnych innych metod.
[C-1-3] NALEŻY wysyłać wszystkie takie dane i dziennik urządzenia tylko przy użyciu mechanizmu ochrony prywatności. Mechanizm ochrony prywatności to „takie mechanizmy, które umożliwiają analizę tylko w ujęciu zbiorczym i uniemożliwiają dopasowywanie zarejestrowanych zdarzeń lub wyników pochodnych do poszczególnych użytkowników”. Ma to na celu zapobieganie możliwości wglądu w jakiekolwiek dane dotyczące poszczególnych użytkowników (np. za pomocą technologii prywatności różnicowej, takiej jak RAPPOR).
[C-1-4] NIE wolno wiązać tych danych z żadną tożsamością użytkownika (np. Account) na urządzeniu, chyba że użytkownik wyrazi na to wyraźną zgodę przy każdym użyciu danych.
[C-1-5] NIE MOŻESZ udostępniać takich danych innym aplikacjom, chyba że użytkownik wyrazi na to zgodę za każdym razem.
[C-1-6] NALEŻY umożliwić użytkownikowi usunięcie danych, które ContentCaptureService lub zastrzeżone metody gromadzą, jeśli dane są przechowywane w dowolnej formie na urządzeniu.

Jeśli implementacje na urządzeniu obejmują usługę, która implementuje interfejs System API ContentCaptureService, lub dowolną zastrzeżoną usługę, która rejestruje dane w sposób opisany powyżej, to:

[C-2-1] NIE wolno zezwalać użytkownikom na zastąpienie usługi przechwytywania treści aplikacją lub usługą instalowaną przez użytkownika. NALEŻY zezwolić na przechwytywanie takich danych tylko w ramach wstępnie zainstalowanej usługi.
[C-2-2] NIE wolno zezwalać żadnym aplikacjom innym niż wstępnie zainstalowany mechanizm usługi przechwytywania treści na możliwość przechwytywania takich danych.
[C-2-3] MUSISZ umożliwić użytkownikowi wyłączenie usługi przechwytywania treści.
[C-2-4] NIE MOŻNA pominąć możliwości zarządzania uprawnieniami Androida, które są wymagane przez usługę rejestrowania treści, oraz stosować modelu uprawnień Androida zgodnie z opisem w sekcji 9.1. Uprawnienia.
[C-SR] MOCNO zalecamy oddzielne przechowywanie komponentów usługi rejestrującej treści, np. niewiązanie usługi ani udostępnianie identyfikatorów procesów z innymi komponentami systemu, z wyjątkiem tych:
- Telefonia, Kontakty, UI systemu i multimedia

9.8.7. Dostęp do schowka

Implementacje na urządzeniu:

[C-0-1] NIE MOŻE zwracać danych skopiowanych do schowka (np. za pomocą interfejsu API ClipboardManager), chyba że aplikacja jest domyślną metodą wprowadzania lub jest aplikacją, która ma obecnie fokus.

9.8.8. Lokalizacja

Implementacje na urządzeniu:

[C-0-1] NIE WOLNO włączać ani wyłączać ustawień lokalizacji urządzenia oraz ustawień skanowania Wi-Fi/Bluetooth bez wyraźnej zgody użytkownika lub jego inicjatywy.
[C-0-2] Musisz umożliwić użytkownikowi dostęp do informacji związanych z lokalizacją, w tym ostatnich próśb o lokalizację, uprawnień na poziomie aplikacji i skanowania Wi-Fi/Bluetooth w celu określenia lokalizacji.
[C-0-3] Aplikacja korzystająca z interfejsu API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] MUSI być aplikacją, która została uruchomiona przez użytkownika w ramach sesji alarmowej (np. po wywołaniu numeru 112 lub wysłaniu SMS-a na numer 112). W przypadku pojazdów samochodowych pojazd może jednak zainicjować sesję awaryjną bez aktywnego udziału użytkownika, jeśli wykryje wypadek (np. aby spełnić wymagania dotyczące eCall).
[C-0-4] NALEŻY zachować możliwość pominięcia ustawień lokalizacji urządzenia przez interfejs API Emergency Location Bypass bez zmiany tych ustawień.
[C-0-5] NALEŻY zaplanować wysłanie powiadomienia, które przypomina użytkownikowi, że aplikacja 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 interfejs API na poziomie 30 lub wyższym nie mogą domyślnie wyświetlać szczegółów innych zainstalowanych aplikacji (patrz Widoczność pakietu w dokumentacji pakietu Android SDK).

Implementacje na urządzeniu:

[C-0-1] Aplikacja kierowana na interfejs API na poziomie 30 lub wyższym NIE MOŻE udostępniać szczegółów dotyczących innej zainstalowanej aplikacji, chyba że ta aplikacja może już zobaczyć szczegóły dotyczące innej zainstalowanej aplikacji za pomocą zarządzanych interfejsów API. Dotyczy to między innymi szczegółów udostępnianych przez niestandardowe interfejsy API dodane przez implementatora urządzenia lub dostępnych za pomocą systemu plików.

9.8.10. Raport o błędzie związanym z łącznością

Jeśli implementacje na urządzeniach generują raporty o błędach za pomocą interfejsu System API BUGREPORT_MODE_TELEPHONY za pomocą klasy BugreportManager, to:

[C-1-1] Należy uzyskać zgodę użytkownika za każdym razem, gdy interfejs System API BUGREPORT_MODE_TELEPHONY jest wywoływany w celu wygenerowania raportu. Nie należy prosić użytkownika o zgodę na wszystkie przyszłe żądania aplikacji.
[C-1-2] NALEŻY wyświetlić wyraźną prośbę o zgodę użytkownika i uzyskać jego zgodę na tworzenie raportów. NALEŻY UWZGLĘDNIĆ wygenerowany raport w aplikacji proszącej o dane bez uzyskania wyraźnej zgody użytkownika.
[C-1-3] MUSI generować żądane raporty zawierające co najmniej te informacje:
- Zrzut danych TelephonyDebugService
- Zrzut danych TelephonyRegistry
- Zrzut danych usługi WifiService
- Zrzut danych ConnectivityService
- zrzut ekranu instancji usługi CarrierService (jeśli jest powiązana);
- Bufor dziennika radiowego
[C-1-4] W generowanych raportach NIE WOLNO uwzględniać tych informacji:
- wszelkiego rodzaju informacje niezwiązane z debugowaniem połączeń;
- wszelkie dzienniki ruchu z aplikacji zainstalowanych przez użytkownika lub szczegółowe profile aplikacji/pakietów zainstalowanych przez użytkownika (identyfikatory UID są dozwolone, nazwy pakietów nie).
MOŻE zawierać dodatkowe informacje, które nie są powiązane z żadną tożsamością użytkownika. (np. logi dostawcy).

Jeśli implementacje urządzeń zawierają w raporcie o błędzie dodatkowe informacje (np.dzienniki dostawcy), które mają wpływ na prywatność, bezpieczeństwo, baterię, pamięć lub pamięć masową, to:

[C-SR] ZDECYDOWANIE POLECAMY, aby ustawienie dla programistów było domyślnie wyłączone. AOSP spełnia te wymagania, udostępniając w opcjach dla programistów opcję Enable verbose vendor logging, która umożliwia dołączanie do raportów o błędach dodatkowych danych dostawcy dotyczących konkretnego urządzenia.

9.8.11. Udostępnianie zbiorów danych

Android za pomocą BlobStoreManager umożliwia aplikacjom przesyłanie fragmentów danych do systemu w celu udostępnienia ich wybranym aplikacjom.

Jeśli implementacje urządzeń obsługują udostępniane dane blob zgodnie z opisem w dokumentacji pakietu SDK, to:

[C-1-1] NIE MOŻESZ udostępniać blobów danych należących do aplikacji poza zakresem dozwolonym przez nie (tzn. zakres dostępu domyślnego i inne tryby dostępu, które można określić za pomocą metod BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() lub BlobStoreManager.session#allowPublicAccess(), NIE MOŻNA modyfikować). Implementacja referencyjna AOSP spełnia te wymagania.
[C-1-2] NIE MOŻESZ wysyłać z urządzenia ani udostępniać innym aplikacjom zaszyfrowanych haszy danych blob (które służą do kontrolowania dostępu).

9.9. Szyfrowanie danych przechowywanych

Wszystkie urządzenia muszą spełniać wymagania podane w sekcji 9.9.1. Urządzenia, które zostały uruchomione na poziomie interfejsu API wcześniejszym niż w tym dokumencie, są zwolnione z wymagań zawartych w sekcjach 9.9.2 i 9.9.3. Zamiast tego muszą spełniać wymagania podane w sekcji 9.9 dokumentu Definicja zgodności z Androidem odpowiadające poziomowi interfejsu API, na którym urządzenie zostało uruchomione.

9.9.1. Bezpośredni rozruch

Implementacje na urządzeniu:

[C-0-1] NALEŻY zaimplementować interfejsy API Tryb bezpośredniego uruchamiania, nawet jeśli nie obsługują one szyfrowania pamięci masowej.
[C-0-2] Intencje ACTION_LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED MUSZĄ być nadal nadawane, aby sygnalizować aplikacjom obsługującym bezpośrednie uruchamianie, że dostępne są dla użytkownika szyfrowane miejsca na dane na urządzeniu (DE) i szyfrowane miejsca na dane z danymi logowania (CE).

9.9.2. Wymagania dotyczące szyfrowania

Implementacje na urządzeniu:

[C-0-1] Musisz zaszyfrować prywatne dane aplikacji (partycja /data) oraz partycję współdzielonego miejsca na dane aplikacji (partycja /sdcard), jeśli jest to stała, nieusuwalna część urządzenia.
[C-0-2] Domyślnie musisz włączyć szyfrowanie danych w momencie, gdy użytkownik zakończy proces konfiguracji.
[C-0-3] NALEŻY spełnić powyższy wymóg szyfrowania danych, wdrażając jedną z tych 2 metod szyfrowania:
- Szyfrowanie oparte na plikach (FBE) i szyfrowanie metadanych zgodnie z opisem w sekcji 9.9.3.1.
- szyfrowanie na poziomie bloku dla poszczególnych użytkowników, jak opisano w sekcji 9.9.3.2;

9.9.3. Metody szyfrowania

Jeśli implementacje urządzeń są zaszyfrowane, to:

[C-1-1] Musi uruchamiać się bez żądania od użytkownika danych uwierzytelniających i umożliwiać aplikacjom obsługującym bezpośrednie uruchamianie dostęp do zaszyfrowanej pamięci urządzenia (DE) po przesłaniu komunikatu ACTION_LOCKED_BOOT_COMPLETED.
[C-1-2] NALEŻY zezwalać na dostęp do zaszyfrowanej pamięci tylko wtedy, gdy użytkownik odblokuje urządzenie, podając swoje dane logowania (np. kod dostępu, kod PIN, wzór lub odcisk palca) i wyświetli się komunikat ACTION_USER_UNLOCKED.
[C-1-13] NIE wolno oferować żadnej metody odblokowania chronionego magazynu CE bez podania przez użytkownika danych logowania, zarejestrowanego klucza powiernikowego lub wznowienia po restarcie zgodnie z wymaganiami podanymi w sekcji 9.9.4.
[C-1-4] NALEŻY używać 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, muszą:

[C-1-5] NALEŻY szyfrować zawartość plików i metadane systemu plików za pomocą AES-256-XTS lub Adiantum. AES-256-XTS to standard Advanced Encryption Standard z 256-bitowym kluczem szyfrującym, który działa w trybie XTS. Pełna długość klucza to 512 bitów. Adiantum to Adiantum-XChaCha12-AES, jak określono na stronie https://github.com/google/adiantum. Metadane systemu plików to dane takie jak rozmiary plików, własność, tryby i rozszerzone atrybuty (xattr).
[C-1-6] NALEŻY szyfrować nazwy plików za pomocą AES-256-CBC-CTS lub Adiantum.
[C-1-12] Jeśli urządzenie obsługuje instrukcje Advanced Encryption Standard (AES) (np. rozszerzenia kryptograficzne ARMv8 na urządzeniach z procesorami ARMv8 lub AES-NI na urządzeniach z procesorami x86), NALEŻY użyć opcji szyfrowania nazwy pliku, zawartości pliku i metadanych systemu plików opartych na AES, a nie Adiantum.
[C-1-13] NALEŻY użyć silnej pod względem kryptograficznym i nieodwracalnej funkcji derywacji klucza (np. HKDF-SHA512) do wyprowadzenia dowolnych kluczy podrzędnych (np. kluczy na poziomie pliku) z kluczy CE i DE. „Silne pod względem kryptograficznym i nieodwracalne” oznacza, że funkcja derywacji klucza ma moc bezpieczeństwa co najmniej 256 bitów i działa jak rodzina funkcji pseudolosowych na swoich danych wejściowych.
[C-1-14] Nie wolno używać tych samych kluczy szyfrowania opartego na plikach (FBE) ani podkluczy do różnych celów kryptograficznych (np. do szyfrowania i wyprowadzania kluczy lub do dwóch różnych algorytmów szyfrowania).
Klucze chroniące obszary pamięci CE i DE oraz metadane systemu plików:
[C-1-7] MUSI być powiązany z kluczem sprzętowym za pomocą mechanizmu szyfrowania. Ten magazyn kluczy MUSI być powiązany z weryfikacją podczas uruchamiania i sprawdzonym korzeniami zaufania sprzętowym urządzenia.
[C-1-8] Klucze CE MUSZĄ być powiązane z danymi uwierzytelniania na ekranie blokady użytkownika.
[C-1-9] Klucze CE muszą być powiązane z domyślnym kodem dostępu, gdy użytkownik nie podał danych logowania na ekranie blokady.
[C-1-10] Musi być unikalny i niepowtarzalny, co oznacza, że klucz CE lub DE żadnego użytkownika nie może być taki sam jak klucz CE lub DE innego użytkownika.
[C-1-11] NALEŻY używać szyfrów, długości kluczy i trybów obsługiwanych obligatoryjnie.
NALEŻY umożliwić bezpośrednie uruchamianie w trybie Direct Boot w przypadku wstępnie zainstalowanych niezbędnych aplikacji (np. Alarm, Telefon, Messenger).

Górny projekt Android Open Source udostępnia preferowaną implementację szyfrowania opartego na plikach na podstawie funkcji szyfrowania „fscrypt” jądra Linuksa oraz szyfrowania metadanych na podstawie funkcji „dm-default-key” jądra Linuksa.

9.9.3.2. Szyfrowanie na poziomie bloku dla poszczególnych użytkowników

Jeśli implementacje urządzeń korzystają z szyfrowania na poziomie bloku dla poszczególnych użytkowników, to:

[C-1-1] NALEŻY włączyć obsługę wielu użytkowników zgodnie z opisem w sekcji 9.5.
[C-1-2] MUST MUST provide per-user partitions, either using raw partitions or logical volumes.
[C-1-3] DO szyfrowania urządzeń blokowych musisz używać unikalnych i różnych kluczy szyfrowania na użytkownika.
[C-1-4] NALEŻY użyć AES-256-XTS do szyfrowania partycji użytkownika na poziomie bloku.
Klucze chroniące urządzenia szyfrowane na poziomie bloku dla poszczególnych użytkowników:
[C-1-5] MUSI być powiązany z kluczem sprzętowym. Ten magazyn kluczy MUSI być powiązany z weryfikacją podczas uruchamiania i sprawdzonym korzeniami zaufania sprzętowym urządzenia.
[C-1-6] MUSI być powiązany z danymi logowania na ekranie blokady odpowiedniego użytkownika.

Szyfrowanie na poziomie bloku dla poszczególnych użytkowników można zaimplementować za pomocą funkcji jądra Linuksa „dm-crypt” w przypadku partycji dla poszczególnych użytkowników.

9.9.4. Wznów po ponownym uruchomieniu

Funkcja wznawiania po restarcie umożliwia odblokowanie pamięci CE wszystkich aplikacji, w tym tych, które nie obsługują jeszcze bezpośredniego uruchamiania, po restarcie zainicjowanym przez OTA. Dzięki tej funkcji użytkownicy mogą otrzymywać powiadomienia z zainstalowanych aplikacji po ponownym uruchomieniu urządzenia.

Wdrożenie funkcji wznawiania po ponownym uruchomieniu musi nadal zapewniać, że gdy urządzenie wpadnie w ręce atakującego, będzie on miał ogromne trudności z odzyskaniem zaszyfrowanych danych użytkownika, 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 z udziałem osób z wewnątrz firmy zakładamy też, że atakujący uzyska dostęp do kluczy kryptograficznych do podpisywania transmisji.

Więcej szczegółów:

[C-0-1] Pamięć CE NIE MOŻE być czytelna nawet dla osoby przeprowadzającej 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ć, że urządzenie otrzyma aktualizację OTA.
- Może modyfikować działanie dowolnego sprzętu (AP, flash itp.), z wyjątkiem opisanych poniżej przypadków, ale taka modyfikacja wymaga opóźnienia o co najmniej godzinę i cyklu zasilania, który powoduje utratę zawartości pamięci RAM.
- Nie można modyfikować działania sprzętu chronionego przed ingerencją (np. Titan M).
- Nie można odczytać pamięci RAM urządzenia na żywo.
- Nie może 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 realizuje wszystkie opisy tutaj, będzie zgodna z [C-0-1].

9.10. Integralność urządzenia

Wymagania te zapewniają przejrzystość stanu integralności urządzenia. Implementacje na urządzeniu:

[C-0-1] MUSI prawidłowo zgłaszać za pomocą metody interfejsu System API PersistentDataBlockManager.getFlashLockState(), czy stan bootloadera zezwala na flashowanie obrazu systemu. Stan FLASH_LOCK_UNKNOWN jest zarezerwowany dla implementacji urządzeń, które są aktualizowane z wcześniejszej wersji Androida, w której nie istniała ta nowa metoda interfejsu API.
[C-0-2] Musi obsługiwać Verified Boot w celu zapewnienia integralności urządzenia.

Jeśli implementacje urządzeń zostały już uruchomione bez obsługi Verified Boot w wersji Androida wcześniejszej niż 9.0 i nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, mogą być zwolnione z tego wymogu.

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

[C-1-1] NALEŻY zadeklarować flagę funkcji platformy android.software.verified_boot.
[C-1-2] NALEŻY przeprowadzić weryfikację w ramach każdej sekwencji uruchamiania.
[C-1-3] NALEŻY rozpocząć weryfikację od niezmiennego klucza sprzętowego, który jest zaufanym źródłem, i przeprowadzić ją aż do partycji systemowej.
[C-1-4] NALEŻY wdrożyć każdy etap weryfikacji, aby sprawdzić integralność i autentyczność wszystkich bajtów na następnym etapie przed wykonaniem kodu na tym etapie.
[C-1-5] NALEŻY używać algorytmów weryfikacji o tak silnej sile jak w przypadku algorytmów szyfrowania (SHA-256) i kluczy publicznych (RSA-2048) zgodnie z aktualnymi zaleceniami NIST.
[C-1-6] NIE wolno dopuścić do uruchomienia, gdy weryfikacja systemu się nie powiedzie, chyba że użytkownik wyrazi zgodę na próbę uruchomienia, w którym to przypadku nie wolno używać danych z niezweryfikowanych bloków pamięci.
[C-1-7] NIE wolno zezwalać na modyfikowanie zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokował bootloader.
[C-SR] Jeśli na urządzeniu jest kilka oddzielnych układów (np. radio, wyspecjalizowany procesor obrazu), MOCNO zalecamy, aby podczas rozruchu zweryfikować każdy etap uruchamiania każdego z tych układów.
[C-1-8] MUST use tamper-evident storage: for storing whether the bootloader is unlocked. Pamięć z funkcją wykrywania manipulacji oznacza, że bootloader może wykryć, czy pamięć została naruszona z poziomu Androida.
[C-1-9] NALEŻY wyświetlić użytkownikowi odpowiedni komunikat podczas korzystania z urządzenia i wymagać fizycznego potwierdzenia przed przejściem z trybu zablokowanego programu rozruchowego do trybu odblokowanego programu rozruchowego.
[C-1-10] NALEŻY wdrożyć ochronę przed cofnięciem zmian na partycjach używanych przez Androida (np. partycjach rozruchu i systemowych) oraz używać pamięci z funkcją wykrywania manipulacji do przechowywania metadanych służących do określania minimalnej dozwolonej wersji systemu operacyjnego.
[C-SR] MOCNO ZALECAMY weryfikowanie wszystkich plików APK aplikacji uprzywilejowanej za pomocą łańcucha zaufania z korzeniami w partycjach chronionych przez weryfikowany rozruch.
[C-SR] MOCNO ZALECAMY weryfikowanie wszystkich artefaktów wykonywalnych załadowanych przez aplikację uprzywilejowaną spoza pliku APK (np. kodu skompilowanego lub kodu ładowanego dynamicznie) przed ich wykonaniem. MOCNO ZALECAMY, aby w ogóle ich nie wykonywać.
NALEŻY wdrożyć ochronę przed przywracaniem w przypadku każdego komponentu z trwałym oprogramowaniem sprzętowym (np. modemu lub kamery) i NALEŻY użyć magazynu z funkcją wykrywania manipulacji do przechowywania metadanych służących do określania minimalnej dozwolonej wersji.

Jeśli implementacje urządzeń zostały już wdrożone bez obsługi wymagań C-1-8 do C-1-10 w starszej wersji Androida i nie można dodać obsługi tych wymagań za pomocą aktualizacji oprogramowania systemowego, mogą być zwolnione z tych wymagań.

Projekt Android Open Source udostępnia preferowaną implementację tej funkcji w repozytorium external/avb/, która może być zintegrowana z bootloaderem używanym do ładowania Androida.

Implementacje na urządzeniu:

[C-0-3] MUSI obsługiwać weryfikację treści pliku za pomocą szyfrowania przy użyciu zaufanych kluczy bez odczytywania całego pliku.
[C-0-4] NIE wolno zezwalać na odczytywanie żądań dotyczących chronionego pliku, gdy odczytywane treści nie są weryfikowane za pomocą zaufanego klucza.

Jeśli implementacje urządzeń zostały już uruchomione bez możliwości weryfikacji treści pliku za pomocą zaufanych kluczy w starszej wersji Androida i nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, mogą być zwolnione z tego wymogu. Wspólny projekt Android Open Source udostępnia preferowaną implementację tej funkcji na podstawie funkcji fs-verity jądra Linuksa.

Implementacje na urządzeniu:

[C-R] Zaleca się obsługę interfejsu Android Protected Confirmation API.

Jeśli implementacje urządzeń obsługują interfejs Protected Confirmation API, to:

[C-3-1] W przypadku interfejsu API ConfirmationPrompt.isSupported() należy zgłaszać dane true.
[C-3-2] NALEŻY zadbać o to, aby kod działający w systemie operacyjnym Android, w tym jego jądro, złośliwy lub inny, nie mógł wygenerować pozytywnej odpowiedzi bez interakcji użytkownika.
[C-3-3] NALEŻY zadbać o to, aby użytkownik mógł przejrzeć i zatwierdzić wyświetlaną wiadomość nawet wtedy, gdy system operacyjny Android (w tym jego jądro) został naruszony.

9.11. Klucze i dane logowania

System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i używanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub Keystore API. Implementacje na urządzeniu:

[C-0-1] MUSI umożliwiać zaimportowanie lub wygenerowanie co najmniej 8192 kluczy.
[C-0-2] Uwierzytelnianie na ekranie blokady MUSI stosować limitowanie prób i MUSI zawierać algorytm wygaszania. Po 150 nieudanych próbach opóźnienie MUSI wynosić co najmniej 24 godziny na próbę.
NIE należy ograniczać liczby kluczy, które mogą być generowane

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady, urządzenie:

[C-1-1] NALEŻY utworzyć kopię zapasową implementacji magazynu kluczy w odizolowanym środowisku wykonawczym.
[C-1-2] Musisz mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać obsługiwane algorytmy systemu Keystore na Androidzie 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 kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source Project (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
[C-1-3] NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonywania i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem tylko wtedy, gdy proces uwierzytelniania zakończy się pomyślnie. Dane uwierzytelniające na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w odizolowanym środowisku wykonania. Projekt Android Open Source udostępnia interfejs HAL (Gatekeeper Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.
[C-1-4] MUSI obsługiwać atesta klucza, w którym klucz podpisujący jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania certyfikatów MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻNA użyć innego klucza.

Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi spełniać wymagań dotyczących posiadania repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania i obsługiwania uwierzytelniania klucza, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania.

[C-1-5] NALEŻY umożliwić użytkownikowi wybranie czasu bezczynności w trybie uśpienia, który pozwala na przejście z otwartego do zamkniętego stanu, z minimalnym dozwolonym czasem bezczynności do 15 sekund. Urządzenia samochodowe, które blokują ekran po wyłączeniu urządzenia głównego lub po zmianie użytkownika, MOGĄ NIE mieć konfiguracji uśpienia.

9.11.1. Bezpieczna blokada ekranu i uwierzytelnianie

Implementacja AOSP opiera się na modelach uwierzytelniania wielopoziomowego, w których uwierzytelnianie podstawowe oparte na fabryce wiedzy może być wspierane przez drugorzędne silne metody biometryczne lub słabsze metody potrójnego uwierzytelniania.

Implementacje na urządzeniu:

[C-SR] MOCNO POLECAMY ustawienie jako podstawowej metody uwierzytelniania tylko jednej z tych opcji:
- numeryczny kod PIN;
- hasło alfanumeryczne
- Wzór przesunięcia na siatce dokładnie 3 x 3 kropek

Pamiętaj, że w tym dokumencie powyższe metody uwierzytelniania są określane jako zalecane podstawowe metody uwierzytelniania.

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 to być metoda uwierzytelniania użytkownika opisana w sekcji Wymaganie uwierzytelniania użytkownika w przypadku korzystania z klucza.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, jeśli są oparte na znanym kluczu tajnym i korzystają z nowej metody uwierzytelniania, która ma być traktowana jako bezpieczny sposób blokowania ekranu:

[C-3-1] Entropia najkrótszych dozwolonych 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ąpić żadnej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) zaimplementowanych i dostępnych w AOSP.
[C-3-4] Nowa metoda uwierzytelniania MUSI być wyłączona, gdy aplikacja Device Policy Controller (DPC) ustawia zasady dotyczące jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_SOMETHING.
[C-3-5] Nowe metody uwierzytelniania MUSZĄ co najpóźniej co 72 godziny stosować zalecane podstawowe metody uwierzytelniania (np. kod PIN, wzór, hasło) LUB wyraźnie informować użytkownika, że niektóre dane nie będą szyfrowane, aby zachować prywatność jego danych.

Jeśli implementacje urządzeń dodają lub modyfikują zalecane podstawowe metody uwierzytelniania, aby odblokować ekran blokady i używać nowej metody uwierzytelniania opartej na danych biometrycznych, która ma być traktowana jako bezpieczny sposób blokowania ekranu, nowa metoda:

[C-4-1] MUSI spełniać wszystkie wymagania opisane w sekcji 7.3.10 dotyczące klasy 1 (dawniej wygoda).
[C-4-2] MUSI zawierać mechanizm zapasowy umożliwiający korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania, która opiera się na znanym kluczu.
[C-4-3] NALEŻY wyłączyć i zezwolić tylko na zalecane uwierzytelnianie podstawowe na potrzeby odblokowywania ekranu , gdy aplikacja Device Policy Controller (DPC) ustawiła zasady funkcji klucza blokady, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures() z dowolnym 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 (dawniej silne), zgodnie z opisem w sekcji 7.3.10:

[C-5-1] Metody MUSZĄ być wyłączone, jeśli aplikacja kontrolera zasad dotyczących urządzeń (DPC) skonfigurowała zasady jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] Należy poprosić użytkownika o zalecane uwierzytelnienie podstawowe (np. PIN, wzór, hasło) zgodnie z opisem w punktach [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 opisane w tej sekcji od C-8.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, a nowa metoda uwierzytelniania opiera się na fizycznym tokenie lub lokalizacji:

[C-6-1] Muszą one zawierać mechanizm zapasowy, który umożliwia korzystanie z jednej z zalecanych metod uwierzytelniania podstawowego opartej na znanym kluczu tajnym i spełniającej wymagania dotyczące traktowania jako bezpieczny ekran blokady.
[C-6-2] Nowa metoda MUSI być wyłączona i zezwalać tylko na jedną z zalecanych podstawowych metod uwierzytelniania, aby odblokować ekran, gdy aplikacja Device Policy Controller (DPC) skonfigurowała zasady za pomocą metody DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) lub metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_UNSPECIFIED.
[C-6-3] Użytkownik MUSI zostać poproszony o wykonanie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru lub hasła) co najmniej raz na 4 godziny.
[C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI być zgodna z ograniczeniami wymienionymi w sekcji C-8.

Jeśli implementacje urządzeń mają zabezpieczony ekran blokady i zawierają co najmniej 1 usługę zaufania, która implementuje interfejs API systemu TrustAgentService, to:

[C-7-1] W menu ustawień i na ekranie blokady musi być wyraźnie wskazane, kiedy blokada urządzenia jest odroczona lub może zostać odblokowana przez zaufanego agenta. Na przykład AOSP spełnia ten wymóg, wyświetlając w menu ustawień opis tekstowy „Automatyczne blokowanie” i „Przycisk zasilania natychmiast blokuje”, a na ekranie blokady – różniącą się ikonę.
[C-7-2] MUSISZ przestrzegać i w pełni wdrażać wszystkie interfejsy API zaufanego agenta w klasie DevicePolicyManager, np. stałą KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] NIE WOLNO w pełni wdrażać funkcji TrustAgentService.addEscrowToken() na urządzeniu używanym jako podstawowe urządzenie osobiste (np. urządzenie przenośne), ale MOŻNA w pełni wdrażać tę funkcję na urządzeniach, które są zwykle współużytkowane (np. Android TV lub urządzenie samochodowe).
[C-7-4] NALEŻY zaszyfrować wszystkie zapisane tokeny dodane przez TrustAgentService.addEscrowToken().
[C-7-5] Nie przechowuj klucza szyfrowania ani tokena powiernikowego na tym samym urządzeniu, na którym używany jest klucz. Na przykład klucz przechowywany na telefonie może odblokować konto użytkownika na telewizorze. W przypadku urządzeń Automotive token escrow nie może być przechowywany w żadnej części pojazdu.
[C-7-6] NALEŻY poinformować użytkownika o konsekwencjach bezpieczeństwa przed włączeniem tokena powiernikowego w celu odszyfrowania danych.
[C-7-7] MUSI zawierać mechanizm zapasowy umożliwiający korzystanie z jednej z zalecanych metod uwierzytelniania podstawowego.
[C-7-8] Użytkownik MUSI zostać poproszony o podanie danych uwierzytelniających za pomocą jednej z zalecanych metod uwierzytelniania podstawowego (np.kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny, chyba że chodzi o bezpieczeństwo użytkownika (np. rozproszenie kierowcy).
[C-7-9] Użytkownik MUSI zostać poproszony o podanie danych uwierzytelniających za pomocą jednej z zalecanych metod uwierzytelniania podstawowego (np.kodu PIN, wzoru lub hasła), jak opisano w [C-1-7] i [C-1-8] w sekcji 7.3.10, chyba że chodzi o bezpieczeństwo użytkownika (np. rozproszenie kierowcy).
[C-7-10] NIE MOŻE być traktowany jako bezpieczny ekran blokady i musi spełniać ograniczenia wymienione w sekcji C-8 poniżej.
[C-7-11] NIE MOŻESZ zezwalać zaufanym agentom na odblokowywanie urządzeń osobistych (np. urządzeń przenośnych). Możesz używać tych urządzeń tylko do utrzymywania już 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] NALEŻY używać szyfrowanego kanału komunikacji (np.UKEY2) do przekazywania tokena powiernikowego z urządzenia magazynującego na urządzenie docelowe.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, który nie jest zabezpieczony zgodnie z opisem powyżej, i używają nowej metody uwierzytelniania do odblokowania ekranu blokady:

[C-8-1] Nowa metoda MUSI zostać wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) skonfigurowała zasady dotyczące jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_UNSPECIFIED.
[C-8-2] Nie wolno resetować ustawień czasu ważności hasła przez DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] Nie wolno im udostępniać interfejsu API do użytku przez aplikacje innych firm w celu zmiany stanu blokady.

9.11.2. StrongBox

System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych na dedykowanym bezpiecznym procesorze, a także w opisanym powyżej odizolowanym środowisku wykonywania. 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 mogło być uznane za StrongBox.

Implementacje urządzeń z dedykowanym bezpiecznym procesorem:

[C-SR] Zdecydowanie zalecamy obsługę StrongBox. W kolejnych wersjach będzie to wymagane.

Jeśli implementacje urządzeń obsługują StrongBox, to:

[C-1-1] NALEŻY zadeklarować FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] NALEŻY zapewnić specjalny sprzęt zabezpieczający, który służy do tworzenia kopii zapasowych magazynu kluczy i zabezpieczenia uwierzytelniania użytkownika. Specjalne bezpieczne urządzenia mogą być używane również do innych celów.
[C-1-3] Musi zawierać procesor, który nie udostępnia procesorowi aplikacji (AP) pamięci podręcznej, pamięci DRAM, procesorów pomocniczych ani innych zasobów rdzenia.
[C-1-4] NALEŻY zadbać o to, aby żadne urządzenia peryferyjne udostępnione AP nie mogły w żaden sposób zmienić przetwarzania StrongBox ani uzyskać żadnych informacji z tego urządzenia. AP 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 AP.
[C-1-6] MUSI zawierać prawdziwy generator liczb losowych, który generuje wyjście o jednolitej dystrybucji i nieprzewidywalnym wyniku.
[C-1-7] Musi być odporny na próby manipulacji, w tym na próby fizycznego wtargnięcia i uszkodzenia.
[C-1-8] MUSI zapewniać odporność na kanały boczne, w tym na wyciek informacji przez kanały boczne związane z zasilaniem, czasem, promieniowaniem elektromagnetycznym i promieniowaniem cieplnym.
[C-1-9] MUSI być zapewnione bezpieczne miejsce przechowywania, które zapewnia poufność, integralność, autentyczność, spójność i świeżość treści. Nie można odczytywać ani zmieniać danych w magazynie, z wyjątkiem sytuacji dozwolonych przez interfejsy StrongBox API.
Aby sprawdzić zgodność z [C-1-3] do [C-1-9], implementacje na urządzeniach:
- [C-1-10] MUSI zawierać sprzęt z certyfikatem zgodności z profilem ochrony kart inteligentnych BSI-CC-PP-0084-2014 lub oceniony przez akredytowane na poziomie krajowym laboratorium testowe, które uwzględniło ocenę podatności na ataki o wysokim potencjale zgodnie z kryteriami Common Criteria dla kart inteligentnych.
- [C-1-11] MUSI zawierać oprogramowanie sprzętowe, które zostało ocenione przez akredytowane w danym kraju laboratorium testowe, uwzględniające ocenę podatności na ataki o wysokim potencjale zgodnie z kryteriami Common Criteria dla kart inteligentnych.
- [C-SR] MOCNO zalecamy uwzględnienie sprzętu, który został oceniony przy użyciu Security Target, Evaluation Assurance Level (EAL) 5, uzupełnionego o AVA_VAN.5. Certyfikat EAL 5 będzie wymagany w kolejnych wersjach.
[C-SR] MOCNO POLECAMY, aby zapewnić odporność na ataki z wewnętrznego źródła, co oznacza, że osoba z dostępem do kluczy do podpisywania oprogramowania układowego nie może wyprodukować oprogramowania układowego, które powoduje wyciek tajemnic z StrongBoxa, obejście wymagań bezpieczeństwa funkcjonalnego lub w inny sposób umożliwi dostęp do poufnych danych użytkownika. Zalecane jest, aby zezwolenie na aktualizacje oprogramowania sprzętowego było możliwe tylko wtedy, gdy hasło głównego użytkownika zostanie podane za pomocą interfejsu IAuthSecret HAL.

9.11.3. Identity Credential

System tożsamości jest definiowany i uzyskiwany przez implementację 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 na urządzeniu:

[C-SR] MOCNO ZALECAMY zaimplementowanie systemu tożsamości.

Jeśli implementacje urządzeń korzystają z systemu danych uwierzytelniających tożsamości, muszą:

[C-0-1] W przypadku metody IdentityCredentialStore#getInstance() musi zwracać wartość inną niż null.
[C-0-2] NALEŻY zaimplementować system tożsamości (np. interfejsy API android.security.identity.*) za pomocą kodu, który komunikuje 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 kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA.
[C-0-3] Operacje kryptograficzne potrzebne do wdrożenia systemu tożsamości (np. interfejsy API android.security.identity.*) MUSZĄ być wykonywane wyłącznie w zaufanej aplikacji, a materiał klucza prywatnego NIGDY nie może opuszczać odizolowanego środowiska wykonania, chyba że jest to wyraźnie wymagane przez interfejsy API wyższego poziomu (np. metoda createEphemeralKeyPair()).
[C-0-4] Zaufana aplikacja MUSI być wdrożona w taki sposób, aby nie wpływało to na jej właściwości związane z bezpieczeństwem (np. dane uwierzytelniające nie są udostępniane, chyba że są spełnione warunki kontroli dostępu, a MAC-y nie mogą być generowane dla dowolnych danych), nawet jeśli Android działa nieprawidłowo lub został naruszony.

9.12. Usuwanie danych

Wszystkie implementacje urządzeń:

[C-0-1] Musisz udostępniać użytkownikom mechanizm umożliwiający przywrócenie ustawień fabrycznych.
[C-0-2] NALEŻY usunąć wszystkie dane z systemu plików userdata.
[C-0-3] NALEŻY usunąć dane w sposób zgodny z odpowiednimi standardami branżowymi, takimi jak NIST SP800-88.
[C-0-4] NALEŻY wywołać powyższy proces „Resetowania danych do ustawień fabrycznych”, gdy interfejs API DevicePolicyManager.wipeData() zostanie wywołany przez aplikację Kontroler zasad urządzenia należącą do głównego użytkownika.
MOŻE udostępnić opcję szybkiego wymazywania danych, która polega tylko na logicznym usunięciu 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 mogą działać tylko wstępnie zainstalowane aplikacje systemowe, a aplikacje innych firm są wyłączone. Ten tryb, znany jako „Tryb bezpiecznego uruchamiania”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.

Implementacje na urządzeniach:

[SR] ZDECYDOWANIE ZALECAMY wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacja urządzenia obejmuje tryb bezpiecznego uruchamiania, to:

[C-1-1] Musisz zapewnić użytkownikowi możliwość przejścia do trybu bezpiecznego rozruchu w sposób, który nie może zostać przerwany przez aplikacje innych firm zainstalowane na urządzeniu, z wyjątkiem sytuacji, gdy aplikacja innej firmy jest kontrolerem zasad urządzenia i ma ustawioną flagę UserManager.DISALLOW_SAFE_BOOT jako prawda.
[C-1-2] Musisz umożliwić użytkownikowi odinstalowanie dowolnej aplikacji innej firmy w trybie bezpiecznym.
NALEŻY umożliwić użytkownikowi uruchomienie trybu bezpiecznego uruchamiania z menu uruchamiania za pomocą procesu różniącego się od normalnego uruchamiania.

9.14. Izolacja systemów pojazdów samochodowych

Urządzenia z Androidem Automotive mają wymieniać dane z krytycznymi podsystemami pojazdu, korzystając z interfejsu HAL pojazdu do wysyłania i odbierania wiadomości przez sieci pojazdu, takie jak magistrala CAN.

Wymiana danych może być zabezpieczona przez wdrożenie funkcji bezpieczeństwa poniżej warstw Androida, aby zapobiec złośliwej lub niezamierzonej interakcji z tymi podsystemami.

9.15. Plany abonamentowe

„Plany subskrypcji” to szczegóły planu rozliczeniowego udostępniane przez operatora komórkowego za pomocą SubscriptionManager.setSubscriptionPlans().

Wszystkie implementacje urządzeń:

[C-0-1] MUST return subscription plans only to the mobile carrier app that has originally provided them.
[C-0-2] Nie wolno tworzyć kopii zapasowych ani przesyłać planów subskrypcji zdalnie.
[C-0-3] DOZWOLONE są tylko zastąpienia, takie jak SubscriptionManager.setSubscriptionOverrideCongested(), z aplikacji operatora komórkowego, która obecnie udostępnia ważne plany subskrypcji.

9.16. Migracja danych aplikacji

Jeśli implementacje na urządzeniu obejmują możliwość migracji danych z jednego urządzenia na inne i nie ograniczają danych aplikacji do tych skonfigurowanych przez dewelopera aplikacji 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 skonfigurował uwierzytelniania podstawowego zgodnie z opisem w sekcji 9.11.1 Bezpieczeństwo ekranu blokady i uwierzytelnianie.
[C-1-2] NALEŻY bezpiecznie potwierdzić uwierzytelnianie podstawowe na urządzeniu źródłowym i uzyskać potwierdzenie od użytkownika, że chce on skopiować dane na urządzeniu źródłowym, zanim zostaną one przeniesione.
[C-1-3] NALEŻY użyć uwierzytelnienia klucza bezpieczeństwa, aby mieć pewność, że zarówno urządzenie źródłowe, jak i docelowe w ramach migracji są prawidłowymi urządzeniami z Androidem i mają zablokowany program rozruchowy.
[C-1-4] NALEŻY przenieść dane aplikacji tylko do tej samej aplikacji na urządzeniu docelowym z tą samą nazwą pakietu i tym samym certyfikatem podpisywania.
[C-1-5] W menu ustawień MUSI być widoczne wskazanie, że na urządzeniu źródłowym dane zostały przeniesione z urządzenia na urządzenie. Użytkownik NIE powinien mieć możliwości usunięcia tego wskazania.

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 ZALECAMY deweloperom implementacji urządzeń wprowadzanie jak najmniejszej liczby zmian w implementacji referencyjnej i preferowanej implementacji Androida dostępnej w ramach Projektu Android Open Source. Pozwoli to zminimalizować ryzyko wprowadzenia błędów, które powodują niezgodności wymagające ponownego wykonania pracy i ewentualnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje na urządzeniu:

[C-0-1] Musi przejść testy zgodności Android Compatibility Test Suite (CTS) dostępne w ramach projektu Android Open Source, używając oprogramowania do ostatecznej wersji urządzenia.
[C-0-2] NALEŻY zapewnić zgodność w przypadku niejednoznaczności w CTS oraz w przypadku każdej ponownej implementacji części kodu źródłowego referencyjnego.

Test CTS jest przeznaczony do uruchamiania na rzeczywistym urządzeniu. Podobnie jak inne oprogramowanie, CTS może zawierać błędy. Wersje CTS będą niezależne od tej definicji zgodności, a na potrzeby Androida 11 może być udostępnionych wiele wersji CTS.

Implementacje na urządzeniu:

[C-0-3] Musi przejść najnowszą wersję CTS dostępną w momencie ukończenia oprogramowania urządzenia.
NALEŻY w jak największym stopniu korzystać z implementacji referencyjnej w drzewie Android Open Source.

10.2. Weryfikator CTS

Narzędzie CTS Verifier jest zawarte w pakiecie Compatibility Test Suite i ma być uruchamiane przez operatora w celu testowania funkcji, których nie można przetestować za pomocą automatycznego systemu, np. prawidłowego działania kamery i czujników.

Implementacje na urządzeniu:

[C-0-1] MUSI prawidłowo wykonać wszystkie odpowiednie przypadki w weryfikatorze CTS.

Narzędzie CTS Verifier zawiera testy wielu rodzajów sprzętu, w tym niektórych opcjonalnych.

Implementacje na urządzeniu:

[C-0-2] Musi przejść wszystkie testy sprzętowe, które posiada. Jeśli na przykład urządzenie ma akcelerometr, MUSI poprawnie wykonać test akcelerometru w CTS Verifier.

Przypadki testowe dotyczące 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 działać z narzędziem CTS Verifier, jak opisano powyżej. Ponieważ jednak wiele wersji jest bardzo podobnych, implementatorzy urządzeń nie muszą uruchamiać narzędzia CTS Verifier w przypadku wersji, które różnią się tylko nieznacznie. W szczególności implementacje urządzeń, które różnią się od implementacji, która przeszła weryfikację CTS Verifier, tylko zestawem obsługiwanych języków, marki itp., MOGĄ pominąć test CTS Verifier.

11. Oprogramowanie z możliwością aktualizacji

[C-0-1] Implementacje urządzeń MUSZĄ zawierać mechanizm zastępujący cały system operacyjny. Mechanizm nie musi wykonywać aktualizacji „na żywo”, czyli może być wymagane ponowne uruchomienie urządzenia. Można użyć dowolnej metody, o ile pozwala ona na zastąpienie całego fabrycznie zainstalowanego oprogramowania. Na przykład dowolne z tych rozwiązań spełni to wymaganie:
- bezprzewodowe (OTA) pobieranie z aktualizacją offline po ponownym uruchomieniu urządzenia;
- „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 kasowania danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachowywać prywatne i udostępnione dane aplikacji. Pamiętaj, że oprogramowanie Androida, z którego korzystasz, zawiera mechanizm aktualizacji, który spełnia ten wymóg.
[C-0-3] Cała aktualizacja MUSI być podpisana, a mechanizm aktualizacji na urządzeniu MUSI weryfikować aktualizację i podpis za pomocą klucza publicznego przechowywanego na urządzeniu.
[C-SR] Zalecamy, aby mechanizm podpisywania szyfrował aktualizację za pomocą algorytmu SHA-256 i sprawdzał skrót za pomocą klucza publicznego za pomocą algorytmu ECDSA NIST P-256.

Jeśli implementacje urządzeń obejmują obsługę nielimitowanego połączenia danych, takiego jak 802.11 lub profil Bluetooth PAN (Personal Area Network), muszą:

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

W przypadku implementacji urządzeń z Androidem 6.0 lub nowszym mechanizm aktualizacji POWINIEN obsługiwać weryfikację, czy obraz systemu jest identyczny z oczekiwanym wynikiem po aktualizacji OTA. Implementacja OTA na podstawie bloków w ramach projektu źródłowego Android Open Source, dodanego od Androida 5.1, spełnia ten wymóg.

Implementacje urządzeń powinny też obsługiwać aktualizacje systemu A/B. AOSP wdraża tę funkcję za pomocą interfejsu HAL sterowania uruchamianiem.

Jeśli po wydaniu urządzenia, ale w ramach rozsądkowego okresu jego użytkowania, który został określony wspólnie z zespołem ds. zgodności Androida, zostanie znaleziony błąd wpływający na zgodność aplikacji innych firm, należy:

[C-2-1] Implementator urządzenia MUSI poprawić błąd za pomocą aktualizacji oprogramowania, którą można zastosować zgodnie z opisanym mechanizmem.

Android zawiera funkcje, które umożliwiają aplikacji Właściciel urządzenia (jeśli jest dostępna) kontrolowanie instalacji aktualizacji systemu. Jeśli podsystem aktualizacji systemu dla urządzeń raportuje android.software.device_admin, to:

[C-3-1] NALEŻY zaimplementować zachowanie opisane w klasie SystemUpdatePolicy.

12. Historia zmian dokumentu

Oto podsumowanie zmian w definicji zgodności w tej wersji:

Zmiany w dokumentacji

Podsumowanie zmian w poszczególnych sekcjach:

12.1. Wskazówki dotyczące wyświetlania historii zmian

Zmiany są oznaczone w ten sposób:

CDD
Znaczne zmiany wymagań dotyczących zgodności.
Dokumenty
Zmiany kosmetyczne lub związane z kompilacją.

Aby zapewnić najlepszą widoczność, dodaj parametry adresu URL pretty=full i no-merges do adresów URL strony z informacjami o zmianach.

13. Skontaktuj się z nami

Możesz dołączyć do forum dotyczącego zgodności z Androidem i poprosić o wyjaśnienia lub zgłosić problemy, które Twoim zdaniem nie zostały opisane w dokumencie.