Definicja zgodności z Androidem 12

1. Wprowadzenie

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

Użycie słów „MUST” (musi), „MUST NOT” (nie musi), „REQUIRED” (wymagane), „SHALL” (musi), „SHALL NOT” (nie musi), „SHOULD” (zalecane), „MAY” (możliwe) i „OPTIONAL” (opcjonalne) jest zgodne ze standardem IETF zdefiniowanym w specyfikacji RFC2119.

W tym dokumencie „wdrożyciel urządzenia” lub „wdrożyciel” to osoba lub organizacja opracowująca rozwiązanie sprzętowe lub programowe z systemem Android 12. „Wdrażanie urządzenia” lub „wdrażanie” to opracowane rozwiązanie sprzętowo-programowe.

Aby uznać implementację urządzenia za zgodną z Androidem 12, należy spełnić 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, to implementator urządzenia jest odpowiedzialny za zapewnienie zgodności z dotychczasowymi implementacjami.

Z tego powodu projekt Android Open Source jest zarówno referencją, jak i preferowanym sposobem implementacji Androida. IMPLEMENTATOROM URZĄDZEŃ ZALECAMY, aby w jak największym stopniu opierali swoje implementacje na kodzie źródłowym „górnego poziomu” dostępnym w ramach projektu Android Open Source. Chociaż niektóre komponenty można teoretycznie zastąpić innymi implementacjami, ZDECYDOWANIE zaleca się, aby nie stosować tej praktyki, ponieważ przejście testów oprogramowania stanie się znacznie trudniejsze. Obowiązkiem implementatora jest zapewnienie pełnej zgodności z zachowaniem standardowej implementacji Androida, w tym w ramach pakietu Compatibility Test Suite i poza nim. Pamiętaj, że niektóre zamiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.

Wiele zasobów, do których prowadzą linki 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 ta definicja zgodności lub zestaw testów zgodności są niezgodne z dokumentacją pakietu SDK, za wiarygodną uznaje się dokumentację pakietu SDK. Wszelkie szczegóły techniczne podane w połączonych 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 sekcji 2 dotyczy konkretnego typu urządzenia.

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

1.1.2. Identyfikator 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 regule.

1.1.3. Identyfikator wymagań w sekcji 2

Identyfikatory wymagań w sekcji 2 składają się z 2 części. Pierwszy z nich odpowiada identyfikatorowi sekcji, jak opisano powyżej. Druga część identyfikuje format i odpowiadające mu wymagania.

identyfikator sekcji poprzedzony identyfikatorem wymagań opisanym powyżej.

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

2. Typy urządzeń

Projekt Android Open Source udostępnia zestaw oprogramowania, który można stosować na różnych typach i w różnych formatach urządzeń. Aby zapewnić bezpieczeństwo urządzeń, oczekuje się, że oprogramowanie, w tym system operacyjny zastępczy lub alternatywne jądro, będzie działać w bezpiecznym środowisku zgodnie z opisem w sekcji 9 i w innych miejscach w tym dokumencie. Istnieje kilka typów urządzeń, które mają stosunkowo lepiej rozwiniętą platformę dystrybucji aplikacji.

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

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

2.1 Konfiguracje urządzenia

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

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

Urządzenie przenośne z Androidem to urządzenie z Androidem, które jest zwykle używane w ręce, 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ć fizyczny rozmiar ekranu w zakresie od 3,3 cala (lub 2,5 cala w przypadku implementacji urządzeń z poziomem interfejsu API 29 lub niższym) do 8 cali;

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

2.2.1. Sprzęt

Implementacje na urządzeniach przenośnych:

• [7.1.1.1/H-0-1] MUSI zawierać co najmniej 1 ekran zgodny z Androidem, który spełnia wszystkie wymagania opisane w tym dokumencie.

• [7.1.1.3/H-SR-1] ZALECAMY, aby umożliwić użytkownikom zmianę rozmiaru wyświetlacza (gęstości ekranu).

• [7.1.1.1/H-0-2] MUSI obsługiwać tworzenie kompozycji za pomocą GPU buforów graficznych o rozmiary co najmniej tak duże jak najwyższa rozdzielczość dowolnego wbudowanego wyświetlacza.

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 2 cale(5,08 cm) na krawędziach krótkich i 2,7 cala(6,35 cm) na krawędziach długich. Wymagania te MOGĄ nie dotyczyć urządzeń z Androidem na poziomie interfejsu API 29 lub niższym.

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

• [7.1.1.1/H-2-1]* Ekran logiczny udostępniany aplikacjom innych firm MUSI mieć co najmniej 2,7 cala na krótszych krawędziach. Wymagania te MOGĄ nie dotyczyć urządzeń z Androidem na poziomie interfejsu API 29 lub starszym.

Jeśli implementacje urządzeń przenośnych obsługują wyświetlacze HDR za pomocą Configuration.isScreenHdr() :

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

Implementacje 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 etapów renderowania GPU określonych w dokumentacji Perffetto.
• [7.1.4.6/H-1-2] MUSI raportować wartości zgodne z wartościami zliczników GPU urządzenia zgodnie z protokołem gpu counter trace packet.
• [7.1.4.6/H-1-3] MUSI raportować wartości zgodne z GPU RenderStages zgodnie z protokołem render stage trace packet proto.
• [7.1.4.6/H-1-4] MUST report a GPU Frequency punkt trasowania 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 na platformie Android na licencji 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ć zachowania samego trybu zgodności.
• [7.2.1/H-0-1] MUSI zawierać obsługę aplikacji edytora metody wprowadzania (IME) innych firm.
• [7.2.3/H-0-3] MUSI zapewniać 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 udostępnić 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 MUSZĄ być wysyłane zdarzenia zarówno normalnego, jak i długiego naciśnięcia przycisku Wstecz (KEYCODE_BACK). System NIE MOŻE używać tych zdarzeń i MOŻE je wywoływać z zewnątrz urządzenia z Androidem (np. zewnętrzna klawiatura sprzętowa podłączona 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-1] MOCNO zalecane jest 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-1] MOCNO ZALECAMY 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 raportować 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, to:

• [7.3.3/H-2-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
• [7.3.3/H-2-2] MUST report GNSS pseudoranges and pseudorange rates, that, in conditions of 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ć w stanie zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
• [7.3.4/H-3-2] MUSI umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę.

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

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

Implementacje na urządzeniach przenośnych:

• [7.3.11/H-SR-1] 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 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) i musi wynosić od 50 do 95 stopni.

Implementacje na urządzeniach przenośnych:

• [7.6.1/H-0-1] Musisz mieć co najmniej 4 GB pamięci nieulotnej dostępnej dla danych prywatnych aplikacji (czyli partycji „/data”).
• [7.6.1/H-0-2] MUSI zwracać „true” dla ActivityManager.isLowRamDevice(), gdy do użycia przez jądro i przestrzeń użytkownika jest 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 pamięci podręcznej w rozdzielczości 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 framebuffera 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 framebuffera 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 bufora ramki 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 przestrzeni pamięci udostępnionej dodatkowo do 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.

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

• [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 (na przykład na partycji „/data”).

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

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

Jeśli implementacje urządzeń przenośnych mają co najmniej 2 GB i nie więcej niż 4 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, to:

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

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

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

Implementacje na urządzeniach przenośnych:

• [7.6.2/H-0-1] NIE MOŻESZ udostępnić aplikacji pamięci współdzielonej o pojemności mniejszej 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 peryferyjny, muszą:

• [7.7.1/H-1-1] MUSI implementować interfejs API akcesoriów otwartych Androida (AOA).

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ć za pomocą aplikacji VR za pomocą android.app.Activity#setVrModeEnabled.

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

• [7.8.2.2/H-1-1] MUST provide the following software mapping of HID codes:

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
			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 przypadkuandroid.speech.RecognizerIntent.ACTION_WEB_SEARCH
		Połączenie przychodzące	Dane wejściowe: krótkie naciśnięcie Dane wyjściowe: zaakceptuj połączenie
			Dane wejściowe: naciśnij i przytrzymaj  Dane wyjściowe: odrzuć połączenie
		Trwa rozmowa	Dane wejściowe: krótkie naciśnięcie Dane wyjściowe: zakończenie połączenia
			Wejście: 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] MUSI 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 zidentyfikowania 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 połączenia urządzenia peryferyjnego USB:

• [7.8.2.2/H-4-1] MUSI zawierać 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] MUST list a device of type AudioDeviceInfo.TYPE_USB_HEADSET and role isSink() if the USB audio terminal type field is 0x0402.

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

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

• [7.8.2.2/H-4-5] MUST list a device of type AudioDeviceInfo.TYPE_USB_DEVICE and role isSource() if the USB audio terminal type field is 0x604.

• [7.8.2.2/H-4-6] MUST list a device of type AudioDeviceInfo.TYPE_USB_DEVICE and role isSink() if the USB audio terminal type field is 0x400.

• [7.8.2.2/H-4-7] MUST list a device of type AudioDeviceInfo.TYPE_USB_DEVICE and role isSource() if the USB audio terminal type field is 0x400.

• [7.8.2.2/H-SR-1] W przypadku podłączenia urządzenia peryferyjnego do portu USB-C MOCNO zaleca się wykonanie enumeracji opisów USB, identyfikację typów terminali i wysłanie komunikatu o intencji ACTION_HEADSET_PLUG w mniej niż 1000 ms.

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

• [5.6(#56_audio-latency)/H-1-1] Średni czas oczekiwania w ciągłym ruchu w obie strony musi wynosić 800 ms lub mniej w przypadku 5 pomiary, a średnia odchylenie bezwzględne nie może przekraczać 100 ms na co najmniej jednej obsługiwanej ścieżce.

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

• [7.10/H]* NIE NALEŻY używać ekscentrycznej masy wirującej (ERM) aktywatora haptycznego (wibratora).
• [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]* NALEŻY zaimplementować wszystkie publiczne stałe dotyczące czystych wibracji w android.view.HapticFeedbackConstants, a mianowicie: CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START i GESTURE_END.
• [7.10/H]* NALEŻY zaimplementować wszystkie publiczne stałe dotyczące jasnych wibracji w android.os.VibrationEffect, a precyzyjniej (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK i EFFECT_DOUBLE_CLICK) oraz wszystkie publiczne stałe dotyczące bogatych wibracji w android.os.VibrationEffect.Composition, a precyzyjniej (PRIMITIVE_CLICK i PRIMITIVE_TICK).
• [7.10/H]* NALEŻY użyć tych połączonych stałych wartości haptycznych mapowań.
• [7.10/H]* NALEŻY stosować ocena jakości w przypadku createOneShot() i createWaveform() interfejsów API.
• [7.10/H]* NALEŻY sprawdzić możliwości skalowania amplitudy, uruchamiając 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 liniowy rezonansowy, 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 rezonansowym siłnikiem (LRA) na osi X, to:

• [7.10/H]* Częstotliwość rezonansowa osi X w LRA powinna wynosić poniżej 200 Hz.

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

• [7.10/H]* NALEŻY sprawdzić stan implementacji, uruchamiając interfejsy API android.os.Vibrator.areAllEffectsSupported() i android.os.Vibrator.arePrimitvesSupported().
• [7.10/H]* NALEŻY przeprowadzić ocenę jakości stałych haptycznych.
• [7.10/H]* NALEŻY zapewnić obsługę awaryjnego, aby zmniejszyć ryzyko awarii, jak opisano tutaj.

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 filmów i udostępniać je aplikacjom innych firm:

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

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

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

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 dokumentach 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]* Musisz wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji dla wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez te aplikacje z intencją wymienione tutaj.
• [3.2.3.1/H-SR-1] MOCNO POLECAMY wstępne załadowanie aplikacji poczty e-mail, która może obsługiwać intencje ACTION_SENDTO lub ACTION_SEND lub ACTION_SEND_MULTIPLE w celu wysłania e-maila.
• [3.4.1/H-0-1] Musisz zapewnić pełną implementację interfejsu android.webkit.Webview API.
• [3.4.2/H-0-1] Musisz udostępnić samodzielną aplikację przeglądarki do ogólnego przeglądania Internetu przez użytkowników.
• [3.8.1/H-SR-1] MOCNO POLECAMY wdrożenie domyślnej aplikacji, która obsługuje przypinanie skrótów, widżetów i widgetFeatures w aplikacji.
• [3.8.1/H-SR-2] MOCNO POLECAMY 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-3] MOCNO POLECAMY uwzględnienie domyślnej aplikacji uruchamiającej, która wyświetla plakietki dla ikon aplikacji.
• [3.8.2/H-SR-1] SĄ BARDZO ZALECANE do obsługi 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 multimedialne.
• [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 sterowanie powiadomieniami (np. odpowiadanie na nie, odkładanie na później, odrzucanie i blokowanie) za pomocą przycisków lub panelu sterowania zaimplementowanego w AOSP.
• [3.8.3/H-0-5] MUST display the choices provided through RemoteInput.Builder setChoices() in the notification shade.
• [3.8.3/H-SR-1] ZALECAMY wyświetlanie pierwszej opcji w RemoteInput.Builder setChoices() w pasku powiadomień bez dodatkowej interakcji użytkownika.
• [3.8.3/H-SR-2] 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-1] ZALECAMY wyświetlanie działań, dla których parametr Notification.Action.Builder.setContextual jest ustawiony jako true zgodnie z odpowiedziami wyświetlanymi przez Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR-1] MOCNO zaleca się wdrożenie na urządzeniu asystenta, który będzie obsługiwał działanie asystenta.

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

• [3.8.4/H-SR-2] Zdecydowanie zalecamy używanie długiego naciśnięcia przycisku HOME jako wyznaczonej interakcji w celu uruchomienia aplikacji Asystent 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.

Jeśli implementacje na urządzeniach przenośnych obsługują conversation notifications i umieszczają je w oddzielnej sekcji od powiadomień alarmowych i cichych powiadomień niebędących rozmowami, to:

• [3.8.4/H-1-1]* MUSI wyświetlać powiadomienia o rozmowie przed powiadomieniami o innych zdarzeniach, z wyjątkiem powiadomień o działaniach usług na pierwszym planie i powiadomień o istotności: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 z multimediów.

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.

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

• [3.8.16/H-1-1] NALEŻY zadeklarować flagę funkcji android.software.controls i ustawić ją na wartość true.
• [3.8.16/H-1-2] Musisz zapewnić użytkownikowi możliwość dodawania, edytowania, wybierania i sterowania ulubionymi elementami sterowania urządzeniami z użyciem interfejsów ControlsProviderService i interfejsów API Control zarejestrowanych przez aplikacje innych firm.
• [3.8.16/H-1-3] MUSI zapewnić użytkownikowi dostęp do tej opcji w ciągu 3 interakcji z domyślnym menu z aplikacjami.
• [3.8.16/H-1-4] W tym interfejsie użytkownika MUSISZ poprawnie wyświetlać nazwę i ikonę każdej aplikacji innej firmy, która udostępnia opcje sterowania za pomocą interfejsu ControlsProviderService API, a także wszystkie określone pola udostępniane 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-1] MOCNO POLECAMY-1 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.
• [3.11/H-0-1] MUSI obsługiwać instalację zewnętrznych silników TTS.
• [3.11/H-SR-1] MOCNO ZALECAMY uwzględnienie mechanizmu TTS obsługującego języki dostępne na urządzeniu.
• [3.13/H-SR-1] 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 urządzeń przenośnych zapewniają funkcję nawigacji jako gest wykonywany 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.

Jeśli implementacje urządzeń przenośnych obsługują bezpieczny ekran blokady i mają co najmniej 2 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, to:

• [3.9/H-1-2] MUST declare the support of managed profiles via the android.software.managed_users feature flag.

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

• [7.5.4/H-1-1] MUSI obsługiwać działanie android.media.action.STILL_IMAGE_CAMERA i android.media.action.STILL_IMAGE_CAMERA_SECUREintencji oraz uruchamiać aparat w trybie zdjęć zgodnie z opisem w pakiecie SDK.
• [7.5.4/H-1-2] MUSI obsługiwać android.media.action.VIDEO_CAMERAintencję uruchomienia aparatu w trybie wideo zgodnie z opisem w pakiecie SDK.

2.2.4. Wydajność i moc

• [8.1/H-0-1] Stała wartość opóźnienia ramki. Niespójny czas oczekiwania na renderowanie lub opóźnienie w renderowaniu klatek NIE POWINNY występować częściej niż 5 razy na sekundę, a ich liczba POWINNA być mniejsza niż 1 raz na sekundę.
• [8.1/H-0-2] Czas reakcji interfejsu użytkownika. Implementacje na urządzeniach MUSZĄ zapewniać użytkownikom niskie opóźnienia podczas przewijania listy zawierającej 10 tys. pozycji, zgodnie z definicją w pakiecie testów zgodności Androida (CTS) w mniej niż 36 sekund.
• [8.1/H-0-3] Przełączanie zadań. Po uruchomieniu wielu 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ść sekwencyjnego odczytu na poziomie co najmniej 15 MB/s.
• [8.2/H-0-4] MUSI zapewnić wydajność losowego odczytu na poziomie co najmniej 3,5 MB/s.

Jeśli implementacje urządzeń przenośnych zawierają funkcje poprawiające zarządzanie energią urządzenia, które są dostępne w AOSP, lub rozszerzają funkcje dostępne w AOSP, 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 poboru mocy dla każdego komponentu, 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/H-0-2] Musisz podać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
• [8.4/H-0-3] MUST report CPU power consumption per each process's UID. Projekt Android Open Source spełnia wymagania dzięki implementacji modułu jądra uid_cputime.
• [8.4/H-0-4] DEWELOPER MUSI udostępnić tę wartość za pomocą polecenia adb shell dumpsys batterystats w powłoce dla dewelopera aplikacji.
• [8.4/H] POWINIEN być przypisany 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_SUMMARYi 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 oraz udostępnić użytkownikom mechanizm przyznawania i odbierania dostępu do takich aplikacji w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Implementacje na urządzeniach przenośnych:

• [9.11/H-0-2] Musisz utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
• [9.11/H-0-3] MUSI zawierać 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 (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest też 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 dopiero po pomyślnym uwierzytelnieniu zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w otoczeniu odizolowanego wykonania. Projekt źródłowy Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymogu.
• [9.11/H-0-5] MUSI obsługiwać atestację klucza, w której klucz do podpisywania atesta jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania 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ŻE być używany inny klucz.
• [9/H-0-1] NALEŻY zadeklarować funkcję „android.hardware.security.model.compatible”.

Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi ona spełniać wymagań dotyczących posiadania magazynu kluczy obsługiwanego przez odizolowane środowisko wykonywania i obsługiwania uwierzytelniania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga magazynu 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 (czasu przejścia z niezablokowanego do zablokowanego 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 ten wymóg jako tryb blokady.

Jeśli implementacje na urządzeniach przenośnych obsługują 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 umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, z możliwością zarządzania bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

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

• [9.5/H-3-1] NIE MUSI obsługiwać profili ograniczonych, ale MUSI być zgodny z implementacją kontroli AOSP, aby zezwalać /odblokowywać dostęp do połączeń głosowych i SMS-ów dla innych użytkowników.

Android, za pomocą interfejsu System API VoiceInteractionService obsługuje mechanizm bezpiecznego wykrywania słów-kluczy w trybie ciągłym bez wskazania dostępu do mikrofonu.

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

• [9.8/H-1-1] NALEŻY zadbać o to, aby usługa wykrywania słów kluczowych mogła przesyłać dane tylko do System lub ContentCaptureService
• [9.8/H-1-2] NALEŻY się upewnić, że usługa wykrywania słów kluczowych może przesyłać do serwera systemu tylko dane audio z mikrofonu lub dane z nich wyprowadzone za pomocą interfejsu HotwordDetectionService API lub do ContentCaptureService za pomocą interfejsu ContentCaptureManager API.
• [9.8/H-1-3] Nie wolno przesyłać dźwięku z mikrofonu dłuższego niż 30 sekund w przypadku pojedynczego żądania wywołanego przez sprzęt do usługi wykrywania słów kluczowych.
• [9.8/H-1-4] W przypadku pojedynczego żądania do usługi wykrywania słów-kluczy nie wolno przesyłać do niej zasobów audio z mikrofonu z buforem starszych niż 8 sekund.
• [9.8/H-1-5] Do usługi interakcji głosowej lub podobnego podmiotu NIE MOŻNA przesyłać do bufora dźwięku z mikrofonu starszego niż 30 sekund.
• [9.8/H-1-6] NIE wolno przesyłać więcej niż 100 bajtów danych z usługi wykrywania słów-kluczy w przypadku każdego udanego wyniku wykrycia słowa-klucza.
• [9.8/H-1-7] NIE wolno zezwalać na przesyłanie więcej niż 5 bitów danych z usługi wykrywania słów kluczowych w przypadku każdego wyniku wykluczającego słowo kluczowe.
• [9.8/H-1-8] NALEŻY zezwalać na przesyłanie danych z usługi wykrywania słów kluczowych tylko w odpowiedzi na żądanie weryfikacji słowa kluczowego z serwera systemowego.
• [9.8/H-1-9] NIE wolno zezwalać aplikacji instalowanej przez użytkownika na świadczenie usługi wykrywania słów kluczowych.
• [9.8/H-1-10] W interfejsie nie mogą być widoczne dane ilościowe dotyczące używania mikrofonu przez usługę wykrywania słów kluczowych.
• [9.8/H-1-11] NALEŻY rejestrować liczbę bajtów zawartych w każdej transmisji z usługi wykrywania słów kluczowych, aby umożliwić badaczom bezpieczeństwa jej sprawdzenie.
• [9.8/H-1-12] MUSI obsługiwać tryb debugowania, który rejestruje surowe treści każdej transmisji z usługi wykrywania słów kluczowych, aby umożliwić badaczom bezpieczeństwa ich sprawdzenie.
• [9.8/H-1-13] NALEŻY zrestartować proces hostujący usługę wykrywania słów kluczowych co najmniej raz na godzinę lub co 30 wydarzeń wywołanych przez sprzęt, w zależności od tego, co nastąpi wcześniej.
• [9.8/H-1-14] MUSI wyświetlać wskaźnik mikrofonu zgodnie z opisem w sekcji 9.8.2, gdy wynik działania słówka aktywującego zostanie przekazany do usługi interakcji głosowej lub podobnego podmiotu.
• [9.8/H-SR-1] ZDECYTOWANIE zaleca się powiadomienie użytkowników przed ustawieniem aplikacji jako dostawcy usługi wykrywania słów kluczowych.
• [9.8/H-SR-2] ZDECYDOWANIE zalecamy zablokowanie przesyłania danych nieuporządkowanych z usługi wykrywania słów kluczowych.

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

• [9.8/H-2-1] MUST provide explicit notice to the user for each hotword phrase supported.
• [9.8/H-2-2] NIE NALEŻY zachowywać surowych danych audio ani danych z nich pochodzących w usłudze wykrywania słów kluczowych.
• [9.8/H-2-3] NIE wolno przesyłać z usługi wykrywania słów kluczowych danych audio, danych, które mogą posłużyć do odtworzenia (w całości lub częściowo) dźwięku, ani treści audio niezwiązanych ze słowem kluczowym, z wyjątkiem tych przesyłanych do ContentCaptureService.

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

• [9.8.2/H-4-1] MUSI wyświetlać wskaźnik mikrofonu, gdy aplikacja uzyskuje dostęp do danych audio z mikrofonu, ale nie wtedy, gdy mikrofon jest używany tylko przez HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje pełniące role wymienione w sekcji 9.1 z identyfikatorem CDD [C-4-X]. .
• [9.8.2/H-4-2] MUSI wyświetlać listę Ostatnie i Aktywne aplikacje korzystające z mikrofonu, zwracaną przez PermissionManager.getIndicatorAppOpUsageData(), wraz z wszelkimi komunikatami atrybutu powiązanymi z tymi aplikacjami.
• [9.8.2/H-4-3] Nie wolno ukrywać wskaźnika mikrofonu w przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.
• [9.8.2/H-4-4] MUSI wyświetlać listę ostatnich i aktywnych aplikacji korzystających z mikrofonu, jak zwraca PermissionManager.getIndicatorAppOpUsageData(), wraz z wszelkimi komunikatami dotyczącymi atrybucji.

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

• [9.8.2/H-5-1] Musi wyświetlać wskaźnik kamery, gdy aplikacja uzyskuje dostęp do danych z kamery na żywo, ale nie wtedy, gdy dostęp do kamery mają tylko aplikacje, które mają role wymienione w sekcji 9.1 z identyfikatorem CDD [C-4-X].
• [9.8.2/H-5-2] MUSI wyświetlać Ostatnie i Aktywne aplikacje korzystające z kamery zgodnie z informacjami z PermissionManager.getIndicatorAppOpUsageData(), wraz z wszelkimi komunikatami dotyczącymi atrybucji.
• [9.8.2/H-5-3] Nie wolno ukrywać wskaźnika kamery w przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.

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 w powłoce cmd testharness.

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

• Perfetto
  • [6.1/H-0-2]* Musi udostępniać użytkownikowi powłoki binarny plik /system/bin/perfetto, którego cmdline jest zgodny z dokumentacją perfetto.
  • [6.1/H-0-3]* Binarny pakiet 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 zapewnić 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 śledzenia perfetto MUSI być domyślnie włączony (właściwość systemowa persist.traced.enable).

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

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

• MUSI spełniać wymagania dotyczące multimediów wymienione w dokumentacji CDD dla Androida 11 w sekcji 2.2.7.1

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

• [5.1/H-1-1] NALEŻY podać maksymalną liczbę sesji dekodera wideo 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-2] MUSI obsługiwać 6 sesji sprzętowego dekodera wideo (AVC, HEVC, VP9* lub nowszy) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p przy 30 fps. *Jeśli jest obecny kodek VP9, wymagane są tylko 2 instancje.
• [5.1/H-1-3] MUST advertise the maximum number of hardware video encoder sessions that can be run concurrently in any codec combination via the CodecCapabilities.getMaxSupportedInstances() and VideoCapabilities.getSupportedPerformancePoints() methods.
• [5.1/H-1-4] MUSI obsługiwać 6 sesji sprzętowego kodera wideo (AVC, HEVC, VP9* lub nowsze) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p przy 30 fps. *Jeśli jest obecny kodek VP9, wymagane są tylko 2 instancje.
• [5.1/H-1-5] NALEŻY reklamować maksymalną liczbę sesji kodowania i dekodowania wideo za pomocą sprzętu, 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, HEVC, VP9* lub nowsze) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p przy 30 fps. *Jeśli jest obecny kodek VP9, wymagane są tylko 2 instancje.
• [5.1/H-1-7] W przypadku sesji kodowania wideo w rozdzielczości 1080p lub niższej we wszystkich sprzętowych kodekiach wideo (z wyjątkiem kodeka Dolby Vision) opóźnienie inicjalizacji kodeka MUSI wynosić 50 ms lub mniej. Obciążenie jest tu zdefiniowane jako jednoczesna sesja transkodowania tylko wideo z rozdzielczości 1080p na 720p przy użyciu kodeków wideo sprzętowych wraz z inicjalizacją nagrywania dźwięku i obrazu w rozdzielczości 1080p.
• [5.1/H-1-8] Czas opóźnienia inicjalizacji kodeka MUSI wynosić 40 ms lub mniej w przypadku sesji kodowania dźwięku o szybkości transmisji 128 kb/s lub niższej dla wszystkich koderów audio podczas obciążenia. Obciążenie jest tu zdefiniowane jako równoległa sesja transkodowania z 1080p na 720p tylko dla wideo, która wykorzystuje kodeki wideo sprzętowe, oraz inicjalizacja nagrywania dźwięku i obrazu w rozdzielczości 1080p.
• [5.3/H-1-1] W przypadku sesji wideo 1080p przy 60 fps nie może wystąpić więcej niż 2 utracone klatki w ciągu 10 sekund (czyli mniej niż 0,333 procent utraty klatek) podczas wczytywania. 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.3/H-1-2] Nie wolno pomijać więcej niż 2 klatek w ciągu 10 sekund podczas zmiany rozdzielczości w trakcie wczytywania sesji wideo z szybkością 60 fps. Obciążenie jest zdefiniowane jako jednoczesna sesja transkodowania wideo z 1080p na 720p przy użyciu kodeków wideo sprzętowych oraz odtwarzanie dźwięku AAC 128 kbps.
• [5.6/H-1-1] Czas opóźnienia od dotknięcia do wygenerowania tonu NIE MOŻE przekraczać 100 ms, gdy testuje się urządzenie za pomocą testu dotykowego OboeTester lub testu dotykowego 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.MEDIA_PERFORMANCE_CLASS, to:

• MUSI spełniać wymagania dotyczące aparatu wymienione w dokumentacji CDD Androida 11 w sekcji 2.2.7.2

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

• [7.5/H-1-1] Urządzenie MUSI mieć tylną kamerę o rozdzielczości co najmniej 12 Mpix, która umożliwia nagrywanie filmów w rozdzielczości 4K przy 30 fps. Główny tylny aparat to tylny aparat o najniższym identyfikatorze.
• [7.5/H-1-2] Musisz mieć główną przednią kamerę o rozdzielczości co najmniej 5 Mpix i obsługującą 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ści android.info.supportedHardwareLevel jako FULL lub wyższą w przypadku głównego tylnego aparatu oraz LIMITED lub wyższą w przypadku głównego przedniego aparatu.
• [7.5/H-1-4] Musi obsługiwać CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME w przypadku obu głównych kamer.
• [7.5/H-1-5] W przypadku aparatu 2 opóźnienie w przypadku formatu JPEG musi wynosić mniej niż 1000 ms w rozdzielczości 1080p, mierzone przez test wydajności aparatu CTS w warunkach oświetlenia ITS (3000 K) w przypadku obu aparatów głównych.
• [7.5/H-1-6] Czas oczekiwania na uruchomienie aplikacji camera2 (od otwarcia aparatu do pierwszego podglądu obrazu) musi być < 600 ms, jak zmierzono za pomocą testu wydajności aparatu CTS w warunkach oświetlenia ITS (3000 K) w przypadku obu głównych aparatów.
• [7.5/H-1-8] MUST support CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW and android.graphics.ImageFormat.RAW_SENSOR for the primary back camera.

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

• MUSI spełniać wymagania sprzętowe wymienione w dokumentacji CDD Androida 11 w sekcji 2.2.7.3

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

• [7.1.1/H-2-1] Rozdzielczość ekranu MUSI wynosić co najmniej 1080p.
• [7.1.1.3/H-2-1] gęstość pikseli na ekranie MUSI wynosić co najmniej 400 dpi.
• [7.6.1/H-2-1] Musisz 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.MEDIA_PERFORMANCE_CLASS, to:

• MUSI spełniać wymagania dotyczące wydajności wymienione w dokumentacji CDD Androida 11 w sekcji 2.2.7.4

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

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

2.3. Wymagania dotyczące telewizorów

Urządzenie Android TV to implementacja urządzenia z Androidem, która jest interfejsem rozrywkowym do oglądania mediów cyfrowych, filmów, gier, aplikacji lub telewizji na żywo przez użytkowników siedzących w odległości około 3 metrów (interfejs „lean back” lub „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;
• Urządzenie musi mieć wbudowany ekran o przekątnej większej niż 24 cale LUB musi mieć port wyjścia wideo, np. VGA, HDMI, DisplayPort lub port bezprzewodowy do wyświetlania.

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

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 Wstecz i Wstecz.
• [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 klawiszy 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] Musi być dostępne co najmniej 4 GB pamięci nieulotnej na potrzeby danych prywatnych aplikacji (czyli na partycji „/data”).

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

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

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

• [7.6.1/T-1-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI 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.

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do przestrzeni pamięci udostępnionej dodatkowo do 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-1] 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 telewizorów 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 z szybkością 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ą deinterlować 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 do:

• [5.3.4/T-1-1] HD 1080p przy 60 klatkach na sekundę 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 High Level 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 szybkościach klatek wideo i rozdzielczościach do:

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

Jeśli implementacje 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 przy 60 klatkach na sekundę 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 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 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 FPS z profilem 0 (głębia kolorów 8 bitów).
• [5.3.7/T-2-1] Zdecydowanie zalecamy obsługę profilu dekodowania UHD z szybkością 60 FPS z profilem 2 (głębia kolorów 10 bitów).

Implementacje na telewizorach:

• [5.5/T-0-1] MUSI obsługiwać system Master Volume 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 nie jest wykonywane dekodowanie dźwięku na urządzeniu).

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] W trybie wyjścia HDMI należy 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-1] MOCNO POLECAMY 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 zapewnić pełną implementację interfejsu API android.webkit.Webview.

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

• [3.8.10/T-1-1] Musi wyświetlać powiadomienia na ekranie blokady, w tym szablon powiadomienia z multimediów.

Implementacje na telewizorach:

• [3.8.14/T-SR-1] ZALECAMY obsługę trybu obrazu w obrazie (PIP) w wielu oknach.
• [3.10/T-0-1] MUSI obsługiwać usługi dostępności innych firm.
• [3.10/T-SR-1] MOCNO POLECAMY 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 TalkBack Open Source.

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

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

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 POWINNY występować częściej niż 5 razy na sekundę, a ich liczba 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 na poziomie co najmniej 0,5 MB/s.
• [8.2/T-0-3] NALEŻY zapewnić wydajność sekwencyjnego odczytu na poziomie co najmniej 15 MB/s.
• [8.2/T-0-4] MUSI zapewnić wydajność losowego odczytu na poziomie 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] MUST provide user affordance to enable and disable the battery saver feature.

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 Obsługiwaniu 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] MUSISZ podać profil poboru mocy dla każdego komponentu, 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] Musisz podać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
• [8.4/T-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia wymagania 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] Musisz udostępnić ten pobór mocy za pomocą polecenia adb shell dumpsys batterystats w powłoce dla dewelopera aplikacji.

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] MUSI zawierać 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 (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest też 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 ekranu blokady w odizolowanym środowisku wykonywania i dopiero po pomyślnym uwierzytelnieniu zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w otoczeniu odizolowanego wykonania. Projekt źródłowy Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymogu.
• [9.11/T-0-4] MUSI obsługiwać atestację klucza, w której klucz do podpisywania atestacji jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania 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ŻE być używany inny klucz.
• [9/T-0-1] NALEŻY zadeklarować funkcję „android.hardware.security.model.compatible”.

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

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

• [9.11/T-1-1] NALEŻY umożliwić użytkownikowi wybranie czasu bezczynności przed przejściem z niezablokowanego stanu do zablokowanego, przy czym dopuszczalny czas bezczynności nie może być dłuższy niż 15 sekund.

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

• [9.5/T-2-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która pozwala właścicielom urządzeń zarządzać dodatkowymi użytkownikami i ich uprawnieniami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, z możliwością zarządzania 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 ograniczonych, ale MUSI być zgodny z implementacją kontroli AOSP, aby włączać i wyłączać dostęp innych użytkowników do połączeń głosowych i SMS-ów.

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

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

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

• [9.8.2/T-5-1] MUSI wyświetlać wskaźnik kamery, gdy aplikacja uzyskuje dostęp do danych z kamery na żywo, ale nie wtedy, gdy dostęp do kamery mają tylko aplikacje o rolach wymienionych w sekcji 9.1. Uprawnienia z identyfikatorem CDD [C-3-X].
• [9.8.2/T-5-2] Nie wolno ukrywać wskaźnika kamery w przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.

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 binarną /system/bin/perfetto, której cmdline jest zgodny z dokumentacją perfetto.
  • [6.1/T-0-2] Binarny plik perfetto MUSI akceptować 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 wykonywalnego 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 o długości od 1,1 do 2,5 cala;
• mieć mechanizm umożliwiający noszenie na ciele;

Dodatkowe wymagania w pozostałych częściach 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 w zakresie od 1,1 do 2,5 cala.

• [7.2.3/W-0-1] MUSI być dostępna funkcja „Strona główna” dla użytkownika oraz funkcja „Wstecz” z wyjątkiem sytuacji, gdy urządzenie jest 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-1] W przypadku urządzeń mobilnych MOCNO POLECAMY 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] 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/W-1-2] NALEŻY zgłaszać pseudozakresy i pseudozakresy GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, w stanie nieruchomym 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 oraz prędkości z dokładnością do 0,2 metra na sekundę w co najmniej 95% czasu.

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] Musisz mieć co najmniej 416 MB pamięci dostępnej dla jądra i przestrzeni użytkownika.

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

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

2.4.2. Multimedia

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] MUSI wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji dla wszystkich publicznych wzorów filtra intencji zdefiniowanych przez te aplikacje lub komponenty usługi, które mają znaczenie dla intencji wymienionych tutaj.

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

• [3.8.4/W-SR-1] WYMAGAMY wdrożenia na urządzeniu asystenta, który obsłuży działanie asystowania.

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-1] MOCNO POLECAMY wstępnie załadować na urządzeniu usługi 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-1] MOCNO zaleca się uwzględnienie mechanizmu 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-1] WYJŚCIE Z ZALECENIA z zastosowaniem opcji wyświetlania wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.
• [8.3/W-SR-2] MOCNO POLECAMY udostępnienie użytkownikowi możliwości włączania i wyłączania funkcji oszczędzania baterii.

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

• [8.4/W-0-1] MUSISZ podać profil poboru mocy dla każdego komponentu, 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] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia wymagania dzięki implementacji modułu jądra uid_cputime.
• [8.4/W-0-4] Musisz udostępnić ten pobór mocy za pomocą polecenia adb shell dumpsys batterystats w powłoce dla dewelopera aplikacji.
• [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ń

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

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

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

• [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 uprawnieniami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, z możliwością zarządzania 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 ograniczonych, ale MUSI być zgodny z implementacją kontroli AOSP, aby zezwalać /odrzucać dostęp innym użytkownikom do połączeń głosowych i SMS-ów.

2.5. Wymagania dotyczące pojazdów

Wdrożeniem Androida Automotive nazywamy radioodtwarzacz pojazdu, w którym Android jest systemem operacyjnym częściowo lub w pełni obsługującym system lub funkcje multimedialne.

Implementacje urządzeń z Androidem są klasyfikowane jako Automotive, jeśli deklarują tę 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 samochodowych z Androidem.

2.5.1. Sprzęt

Implementacje na urządzeniach samochodowych:

• [7.1.1.1/A-0-1] Ekran musi mieć co najmniej 6 cali przekątnej.

• [7.1.1.1/A-0-2] Rozmiar ekranu musi wynosić co najmniej 750 x 480 dp.

• [7.2.3/A-0-1] MUSI zawierać funkcję Wróć i 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 funkcji Wstecz (KEYCODE_BACK).

• [7.3/A-0-1] MUST implement and report GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED and PARKING_BRAKE_ON.

• [7.3/A-0-2] Wartość flagi NIGHT_MODE MUSI być zgodna z trybem dnia/nocy w panelu sterowania i POWINNA być oparta na danych z czujnika światła otoczenia. Używany czujnik światła otoczenia MOŻE być taki sam jak fotometry.

• [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ę na podstawie danych z GPS/GNSS i dodatkowych czujników. Jeśli lokalizacja jest określana na podstawie danych z GPS, MOCNO zalecamy zaimplementowanie i raportowanie odpowiednich typów czujników lub identyfikatorów właściwości pojazdu.

• [7.3/A-0-2] Lokalizacja wymagana przez LocationManager#requestLocationUpdates() NIE MOŻE być dopasowywana na mapie.

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

• [7.1.4.1/A-0-1] MUSI deklarować OpenGL ES 3.1 lub nowszą.
• [7.1.4.1/A-0-2] MUSI obsługiwać Vulkan 1.1.
• [7.1.4.1/A-0-3] MUSI zawierać ładowarkę Vulkana i eksportować wszystkie symbole.

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

• [7.3.1/A-1-1] MUSI być w stanie zgłaszać zdarzenia 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-3] MUSI umożliwiać pomiar zmian orientacji do 250 stopni na sekundę.
• [7.3.4/A-SR-1] ZALECAMY, aby zakres pomiarowy żyroskopu był ustawiony na +/- 250 dps, aby zmaksymalizować rozdzielczość

Jeśli implementacje urządzeń samochodowych obejmują odbiornik GPS/GNSS, ale nie obejmują łączności danych opartej na sieci komórkowej, muszą:

• [7.3.3/A-3-1] MUSI określić lokalizację za pierwszym razem, gdy odbiornik GPS/GNSS zostanie włączony, lub po 4 dniach (lub więcej) w ciągu 60 sekund.
• [7.3.3/A-3-2] MUSI spełniać kryteria czasu do pierwszego rozwiązania określone 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ą pierwszymi lub które nastąpiły po upływie ponad 4 dni). Wymaganie 7.3.3/C-1-2 jest zwykle spełnione w pojazdach bez łączności danych opartej na sieci komórkowej, za pomocą prognoz orbity GNSS obliczanej na odbiorniku lub za pomocą ostatniej znanej lokalizacji pojazdu wraz z możliwością nawigacji bez użycia przyrządów przez co najmniej 60 sekund z dokładnością do pozycji zgodną z 7.3.3/C-1-3 lub kombinacją 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-1] MOCNO POLECAMY obsługę profilu dostępu do wiadomości (MAP).

• [7.4.5/A] NALEŻY uwzględnić obsługę połączeń danych w sieci komórkowej.

• [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 obraz 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] Kamera zewnętrzna NIE MOŻE być dostępna za pomocą interfejsów API aparatu Androida, chyba że spełnia podstawowe wymagania dotyczące aparatu.
• [7.5/A-SR-1] MOCNO zalecamy, aby nie obracać ani nie odwracać poziomo podglądu kamery.
• [7.5.5/A-SR-1] MOCNO zaleca się, aby orientacja była taka, aby długi wymiar kamery był wyrównany z horyzontem.
• [7.5/A-SR-2] MOCNO zalecamy, 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ć wdrożony w sterowniku aparatu autofokus sprzętowy lub programowy.

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 zapewnić lepszą 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 pamięci wewnętrznej, która nie jest wymienna, muszą:

• [7.6.1/A-SR-1] ZALECAMY, aby zredukować obciążenie operacjami wejścia/wyjścia podczas operacji wykonywanych na zewnętrznym urządzeniu pamięci masowej, na przykład za pomocą funkcji 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.

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do przestrzeni pamięci udostępnionej dodatkowo do 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 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 mieć wyjście audio i deklarować 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 zalecamy obsługę tych formatów dekodowania wideo:

• [5.3/A-SR-1] 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 w ramach android.car.VehiclePropertyIds, to:

• [3/A-1-1] Nie wolno przypisywać specjalnych uprawnień do korzystania z tych usług przez aplikację systemową ani uniemożliwiać korzystania z nich aplikacjom innych firm.
• [3/A-1-2] NIE POWINNA 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 egzekwować wszystkie stałe uprawnienia zgodnie z dokumentacją na stronie referencyjnej dotyczącej uprawnień w przypadku pojazdów.

• [3.2.3.1/A-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/A-0-1] Musisz wdrożyć pełną implementację interfejsu API android.webkit.Webview.

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

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

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 „push-to-talk” jako wyznaczonej interakcji do uruchomienia aplikacji asystenta wybranej przez użytkownika, 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 Notifications on Automotive OS pakietu SDK.
• [3.8.3.1/A-0-2] MUSI wyświetlać opcje odtwarzania i wyciszenia dla działań powiadomienia zamiast tych udostępnianych przez Notification.Builder.addAction()
• [3.8.3.1/A] NALEŻY ograniczyć stosowanie zaawansowanych zadań administracyjnych, takich jak ustawienia powiadomień na kanałach. MOŻE używać interfejsu użytkownika w poszczególnych aplikacjach, aby ograniczyć liczbę elementów sterujących.

Jeśli implementacje urządzeń samochodowych obsługują właściwości HAL użytkownika, to:

• [3.9.3/A-1-1] IMPLEMENTUJ WSZYSTKIE właściwości cyklu życia użytkownika.
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

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 medió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 intencyjne CAR_INTENT_ACTION_MEDIA_TEMPLATE z dodatkowym parametrem CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] MUSISZ udostępnić możliwość przejścia do aktywności preferencji aplikacji multimedialnej, ale 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] Musisz obsługiwać wyszukiwanie w aplikacji w przypadku aplikacji, które obsługują wyszukiwanie.
• [3.14/A-0-7] MUSI przestrzegać definicji CONTENT_STYLE_BROWSABLE_HINT i CONTENT_STYLE_PLAYABLE_HINT podczas wyświetlania hierarchii MediaBrowser.

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ą CAR_INTENT_ACTION_MEDIA_TEMPLATEintencji.

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] PASEK STANÓW I PASEK NAWIGACYJNY MOGĄ BYĆ ZAWSZE WIDOCZNE.
• [3.8/A] MOŻE ograniczać prośby aplikacji o zmianę kolorów elementów interfejsu systemu, aby zapewnić, że elementy te będą zawsze wyraźnie widoczne.

2.5.4. Wydajność i moc

Implementacje na urządzeniach samochodowych:

• [8.2/A-0-1] NALEŻY zgłaszać liczbę bajtów odczytanych i zapisanych do pamięci nieulotnej dla każdego identyfikatora UID procesu, aby statystyki były dostępne dla deweloperów za pomocą interfejsu System APIandroid.car.storagemonitoring.CarStorageMonitoringManager. Projekt Android Open Source spełnia to wymaganie dzięki modułowi jądra uid_sys_stats.
• [8.3/A-1-3] MUSI obsługiwać tryb garażu.
• [8.3/A] Powinien znajdować się w trybie garażu przez 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 energetyczny dla każdego komponentu, 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/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 wymagania 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ć tę wartość za pomocą polecenia adb shell dumpsys batterystats w powłoce.

2.5.5. Model zabezpieczeń

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

• [9.5/A-1-1] NIE NALEŻY zezwalać użytkownikom na interakcję z użytkownikiem bezprzewodowego systemu ani na przełączanie się na niego, z wyjątkiem zarządzania urządzeniami.
• [9.5/A-1-2] NALEŻY przełączyć się na użytkownika dodatkowego przed BOOT_COMPLETED.
• [9.5/A-1-3] MUSI obsługiwać możliwość utworzenia użytkownika-gościa nawet wtedy, gdy osiągnięto maksymalną liczbę 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] 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 przez system Keystore Androida algorytmy 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 (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest też 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 logowania do ekranu blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w otoczeniu odizolowanego wykonania. Projekt źródłowy Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymogu.
• [9.11/A-0-4] MUSI obsługiwać atestację klucza, w której klucz podpisywania atestacji jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania 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ŻE być używany inny klucz.
• [9/A-0-1] NALEŻY zadeklarować funkcję „android.hardware.security.model.compatible”.

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

Implementacje na urządzeniach samochodowych:

• [9.14/A-0-1] MUST gatekeep messages from Android framework vehicle subsystems, e.g., allowlisting permitted message types and message sources.
• [9.14/A-0-2] MUSI chronić przed atakami typu DoS z ramy Androida lub aplikacji innych firm. Zapobiega to przeciążeniu sieci pojazdu przez złośliwe oprogramowanie, które może spowodować nieprawidłowe działanie 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 binarną /system/bin/perfetto, której cmdline jest zgodna z dokumentacją perfetto.
  • [6.1/A-0-2] Binarny plik perfetto MUSI akceptować 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 wykonywalnego perfetto co najmniej źródła danych opisane w dokumentacji perfetto.

2.6. Wymagania dotyczące tabletów

Tablet z Androidem to urządzenie z Androidem, które zazwyczaj 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ę.
• ma ekran o rozmiarze większym niż 7 cali i mniejszym niż 18 cali (zmierzone po przekątnej);

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

2.6.1. Sprzęt

Żyroskop

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

• [7.3.4/Tab-1-1] MUSI być w stanie mierzyć zmiany 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 (małe/normalne) 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 ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, z możliwością zarządzania bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

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

• [9.5/T-2-1] NIE MUSI obsługiwać profili ograniczonych, ale MUSI być zgodny z implementacją funkcji kontroli 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] Musisz wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji dla wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez te intencje aplikacji wymienione tutaj.

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 zbiór interfejsów platformy Androida udostępnionych aplikacjom działającym w środowisku zarządzanego środowiska wykonawczego.

Implementacje na urządzeniu:

• [C-0-1] Musisz udostępnić kompletne implementacje, w tym wszystkie opisane zachowania, dowolnego sdokumentowanego interfejsu API udostępnionego przez pakiet SDK Androida lub dowolnego interfejsu API o oznaczonym znacznikiem „@SystemApi” kodzie źródłowym Androida.

• [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 ani 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. Więcej informacji o wymaganiach w tym scenariuszu znajdziesz w sekcji 7.

• [C-0-5] NIE wolno zezwalać aplikacjom innych firm na korzystanie z 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 w AOSP i nie należące do publicznego pakietu SDK. Dotyczy to interfejsów API otagowanych adnotacją @hide, ale nie @SystemAPI, zgodnie z opisem w dokumentacji pakietu SDK oraz członków klas prywatnych i 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 API level branch in the AOSP.

• [C-0-7] MUSI obsługiwać sygnaturę konfiguracji, aby za pomocą mechanizmu aktualizacji dynamicznej usuwać interfejsy inne niż SDK z listy ograniczeń. W tym celu należy umieścić podpisaną konfigurację w dowolnym pliku APK, używając istniejących kluczy publicznych obecnych w AOSP.

  Jednak:

  • W MAJA, jeśli ukryty interfejs API jest nieobecny lub jest inaczej zaimplementowany na urządzeniu, przenieś ukryty interfejs API na listę zablokowanych lub pomiń go na wszystkich listach ograniczeń.
  • W MAJA, jeśli ukryty interfejs API nie istnieje już w AOSP, dodaj go do dowolnej z list ograniczonych.

3.1.1. Rozszerzenia Androida

Android obsługuje rozszerzanie interfejsu zarządzanego interfejsu API danego poziomu API przez aktualizowanie wersji rozszerzenia dla tego poziomu API. Interfejs API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) zwraca wersję rozszerzenia podana w parametrze apiLevel, jeśli są dostępne rozszerzenia dla tego poziomu interfejsu API.

Implementacje na urządzeniach z Androidem:

• [C-0-1] NALEŻY wstępnie załadować implementację AOSP zarówno biblioteki współdzielonej ExtShared, jak i usług ExtServices w wersjach nowszych lub równych minimalnym wersjom dozwolonym dla danego poziomu interfejsu API. Na przykład implementacje urządzeń z Androidem 7.0 z 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 na urządzeniach:

• [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 co najmniej 1 z tych warunków:
  • Kieruje na interfejs API na poziomie 28 lub niższym.
  • W 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 zarządzanych interfejsów API z sekcji 3.1 Android zawiera też „miękki” interfejs API działający tylko w czasie wykonywania. Dotyczy to takich elementów aplikacji na Androida jak intencje, uprawnienia i inne podobne aspekty, 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 dotyczące uprawnień zgodnie z dokumentacją na stronie referencyjnej poświęconej uprawnieniom. Pamiętaj, że sekcja 9 zawiera 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 na urządzeniach, w tabeli poniżej podano dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi implementacje na urządzeniach 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 zdefiniowanych w dozwolonych ciągach znaków wersji na potrzeby Androida 12.
WERSJ.SDK	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 12 to pole MUSI zawierać wartość całkowitą 12_INT.
VERSION.SDK_INT	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 12 to pole MUSI zawierać wartość całkowitą 12_INT.
VERSION.INCREMENTAL	Wartość wybrana przez implementatora urządzenia, która określa wersję systemu Androida w konkretnej implementacji w czytelnym dla człowieka formacie. Tej wartości NIE MOŻNA używać ponownie w przypadku różnych wersji udostępnionych użytkownikom. Typowe zastosowanie tego pola to 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ć kodowalna jako 7-bitowy kod ASCII i MUSI być zgodna z wyrażeniem regularnym „^[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ść natywnego interfejsu API.
SUPPORTED_32_BIT_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność natywnego interfejsu API.
SUPPORTED_64_BIT_ABIS	Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność natywnego interfejsu API.
CPU_ABI2	Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
URZĄDZENIE	Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową identyfikującą konfigurację funkcji sprzętowych i przeznaczenie przemysłowe 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 cyklu życia produktu.
FINGERPRINT	Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być w rozsądnym stopniu czytelny 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:12/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). Powinna być w rozsądnym stopniu czytelna dla człowieka. Wartość tego pola MUSI być kodowalna 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 wymagań dotyczących formatu tego pola, z tym wyjątkiem, że NIE może być ono puste ani nie może zawierać pustego ciągu znaków („”).
ID	Identyfikator wybrany przez implementatora urządzenia na potrzeby odniesienia do konkretnej wersji w czytelnym dla człowieka formacie. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINNA zawierać wartość na tyle zrozumiałą dla użytkowników, aby mogli oni odróżnić różne wersje oprogramowania. Wartość tego pola MUSI być możliwa do zakodowania w 7-bitowym formacie 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 (""). To pole NIE MOŻE się zmieniać w trakcie trwania produktu.
SOC_MANUFACTURER	Nazwa handlowa producenta głównego układu systemowego (SOC) używanego w produkcie. Urządzenia z tym samym producentem układu SOC powinny używać tej samej wartości stałej. Aby uzyskać prawidłową stałą, skontaktuj się z producentem SOC. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII, MUSI być zgodna z wyrażeniem regularnym „^([0-9A-Za-z ]+)”, NIE MOŻE się zaczynać ani kończyć białą przestrzenią i NIE MOŻE być równa „unknown”. To pole NIE MOŻE się zmieniać w trakcie całego okresu istnienia produktu.
SOC_MODEL	Nazwa modelu głównego układu systemowego (SOC) używanego w produkcie. Urządzenia z tym samym modelem SOC powinny używać tej samej stałej wartości. Aby uzyskać prawidłową stałą, skontaktuj się z producentem SOC. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^([0-9A-Za-z ._/+-]+)$”. Nie może się zaczynać ani kończyć białą przestrzenią i nie może być równa „unknown”. To pole NIE MOŻE się zmieniać w trakcie cyklu życia produktu.
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 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 (""). To pole NIE może się zmieniać w trakcie całego okresu istnienia produktu.
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ć zrozumiały dla człowieka, ale niekoniecznie musi być widoczny dla użytkowników. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i MUSI być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”. Nazwa produktu NIE MOŻE się zmieniać w trakcie jego cyklu życia.
ODM_SKU	Opcjonalna wartość wybrana przez implementatora urządzenia, która zawiera kod SKU (Stock Keeping Unit) używany do śledzenia określonych konfiguracji urządzenia, np. urządzeń peryferyjnych dołączonych do urządzenia w momencie sprzedaży. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym ^([0-9A-Za-z.,_-]+)$.
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ć kodowane jako 7-bitowy kod ASCII, MUSZĄ być zgodne z wyrażeniem regularnym „^[a-zA-Z0-9._-]+” i MUSZĄ zawierać 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 określająca 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ł kompilację. Nie ma 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 („"”).
SECURITY_PATCH	Wartość wskazująca poziom aktualizacji zabezpieczeń danej kompilacji. Musi ono oznaczać, że kompilacja nie jest w żaden sposób narażona na żadne z opisanych problemów w specjalnym Biuletynie bezpieczeństwa Androida. Musi mieć format [RRRR-MM-DD], który odpowiada zdefiniowanemu ciągowi znaków w publicznym biuletynie o zabezpieczeniach Androida lub w  powiadomieniu o zabezpieczeniach Androida, np. „2015-11-01”.
BASE_OS	Wartość reprezentująca parametr FINGERPRINT kompilacji, która jest identyczna z tą kompilacją, z wyjątkiem poprawek dostarczonych w powiadomieniu o bezpieczeństwie Androida. Musi on zwracać prawidłową wartość. Jeśli taka wersja nie istnieje, należy zwrócić pusty ciąg znaków („”).
BOOTLOADER	Wartość wybrana przez implementatora urządzenia, która identyfikuje wersję wewnętrznego bootloadera używaną na urządzeniu w czytelnym dla człowieka formacie. 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 identyfikującą konkretną wersję wewnętrznego radia/modemu używaną na urządzeniu w czytelnym dla człowieka formacie. Jeśli urządzenie nie ma żadnego radia/modemu wewnętrznego, musi zwrócić wartość NULL. Wartość tego pola MUSI być kodowalna 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 unikalny w przypadku urządzeń z tym samym MODELEM i PRODUCENTEM. Wartość w tym polu MUSI być możliwa do zakodowania w 7-bitowym formacie 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-1] MOCNO ZALECAMY wstępne załadowanie co najmniej 1 aplikacji lub komponentu usługi z obsługą intencji we wszystkich publicznych wzorach filtrów intencji zdefiniowanych przez te intencje aplikacji wymienione tutaj oraz zapewnienie realizacji, czyli spełnienie oczekiwań dewelopera w przypadku 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 Androida w górnym strumieniu 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 w szczególności 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ślnej aktywności dla intencji.

• Implementacje urządzeń MOGĄ jednak udostępniać domyślne czynności dla określonych wzorów URI (np. http://play.google.com), gdy domyślna czynność udostępnia bardziej szczegółowy atrybut 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 autorytatywnych domyślnych zachowań dotyczących łączenia aplikacji w przypadku niektórych typów intencji identyfikatora URI internetowego. Gdy takie deklaracje autoryzowane są zdefiniowane w wzorach filtrów intencji aplikacji, implementacje na urządzeniu:

• [C-0-4] NALEŻY spróbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji protokołu Digital Asset Links, jak to zostało zaimplementowane przez menedżera 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 URI jako domyślne moduły obsługi aplikacji dla ich identyfikatorów URI.
• MOŻE 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ępniać użytkownikowi odpowiednie zastąpienia w menu ustawień na podstawie wzorca URI.
• Musisz udostępnić użytkownikowi ustawienia 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 aplikacja działała w jednym z tych trybów: zawsze otwieraj, zawsze pytaj lub nigdy nie otwieraj, 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 URI.
  • Implementacja urządzenia MOŻE umożliwić użytkownikowi zastąpienie określonych docelowych filtrów 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 umożliwia weryfikację 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 intencje lub wzorce intencji przesyłania za pomocą działania, kategorii lub innego kluczowego ciągu 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łaszają wzorce intencji za pomocą ciągu znaków ACTION, CATEGORY lub innego ciągu klucza 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 korzystające z przestrzeni nazw wyraźnie powiązanych z daną organizacją. Ten zakaz jest analogiczny do tego, który dotyczy 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 powiadomić 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ętowej. Jeśli urządzenie obsługuje niezbędny sprzęt, intencje 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 odpowiednich przypadkach implementacje na urządzeniach MUSZĄ udostępniać podobny 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 okna sterującego 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łuje 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ć android.telecom.action.CHANGE_DEFAULT_DIALERintencję wyświetlenia okna dialogowego, aby umożliwić 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] W przypadku aplikacji, która ma rolę android.app.role.CALL_REDIRECTION, MUSISZ zezwolić na android.telecom.CallRedirectionService.

• [C-2-5] NALEŻY umożliwić użytkownikowi wybranie aplikacji, która ma android.app.role.CALL_REDIRECTIONrolę.

• [C-2-6] Musisz obsługiwać intencje android.intent.action.SENDTO i android.intent.action.VIEW oraz udostępniać aktywność do wysyłania i wyświetlania SMS-ów.

• [C-SR-1] BARDZO ZALECAMY uwzględnianie intencji android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW i android.intent.action.DIAL z wstępnie załadowaną aplikacją do wybierania numerów, 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] Musisz 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] Musi obsługiwać te intencje: android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, aby wyświetlić działanie, które spełnia oczekiwania dewelopera dotyczące tych intencji zgodnie z opisem w SDK.

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

• [C-5-1] Musisz 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 na urządzeniu, użytkownicy:

• [C-7-1] Musisz udostępnić użytkownikom mechanizm umożliwiający dodawanie i konfigurowanie metod wprowadzania danych 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ć android.settings.ACCESSIBILITY_SETTINGSintencję zapewnienia użytkownikowi mechanizmu umożliwiającego włączenie i wyłączenie usług ułatwień dostępu innych firm oraz 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ą ją 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] W ustawieniach musisz udostępnić interfejs użytkownika, który obsługuje działanie Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, umożliwiając użytkownikom dodawanie aplikacji do listy dozwolonych lub usuwanie ich z tej listy.

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 działanie Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻESZ zaimplementować je jako nieaktywne.

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

• [C-12-3] NALEŻY zezwolić tylko wstępnie zainstalowanym aplikacjom na Androida na obsługę tych 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, aby wywołać interfejs użytkownika w celu dodania administratora urządzenia do systemu (lub umożliwienia odrzucenia tej opcji).

• [C-13-2] MUSI obsługiwać intencje android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & 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świetlić 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 implementacja na urządzeniu obejmuje fabrycznie zainstalowaną aplikację lub jeśli chcesz zezwolić aplikacjom innych firm na dostęp do statystyk użytkowania, musisz:

• [C-SR-2] Zdecydowanie zalecamy udostępnienie użytkownikowi mechanizmu przyznawania lub odmowy przyznania dostępu do statystyk użytkowania w odpowiedzi na działanie android.settings.ACTION_USAGE_ACCESS_SETTINGS w przypadku aplikacji, które deklarują uprawnienie android.permission.PACKAGE_USAGE_STATS.

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

• [C-15-1] Musisz nadal mieć aktywność, która obsługuje wzór intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale musisz zaimplementować go jako no-op, czyli tak, aby miał on działanie równoważne z tym, gdy użytkownik odmówi dostępu.

Jeśli implementacje na urządzeniach wyświetlają linki do czynności określonych przez AutofillService_passwordsActivity w Ustawieniach lub linki do haseł użytkownika za pomocą podobnego mechanizmu, muszą:

• [C-16-1] Musi wyświetlać takie linki w przypadku wszystkich zainstalowanych usług autouzupełniania.

Jeśli implementacje na urządzeniu obsługują interfejs VoiceInteractionService i mają zainstalowaną więcej niż 1 aplikację korzystającą z tego interfejsu API, to:

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

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

• [C-SR-3] BARDZO ZALECAMY uwzględnienie intencji android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA i android.speech.tts.engine.GET_SAMPLE_TEXT, które mają działanie zapewniające realizację tych intencji zgodnie z opisem w SDK tutaj.

Android obsługuje interaktywne wygaszacze ekranu, które wcześniej nazywaliśmy „Dreams”. 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 ekranu i opcję ustawień, która umożliwia użytkownikom skonfigurowanie wygaszaczy ekranu 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 na Androidzie na więcej niż jednym wyświetlaczu, 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 wykonywanym na ekranie głównym.
• [C-1-3] Nowa aktywność MUSI uruchamiać się na tym samym wyświetlaczu, na którym została uruchomiona poprzednia aktywność, 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 wyświetlacz z flagą Display.FLAG_PRIVATE zostanie usunięty.
• [C-1-5] NALEŻY bezpiecznie ukryć treści na wszystkich ekranach, gdy urządzenie jest zablokowane za pomocą bezpiecznego ekranu blokady, chyba że aplikacja zdecyduje się wyświetlać na ekranie blokady za pomocą interfejsu API Activity#setShowWhenLocked().
• Powinien mieć android.content.res.Configuration, który odpowiada temu wyświetlaczowi, aby wyświetlać, działać prawidłowo i utrzymywać zgodność, jeśli aktywność jest uruchamiana na wyświetlaczu dodatkowym.

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych czynności na Androidzie 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ż wyświetlane, MUSI mieć możliwość uruchomienia wyświetlacza. Każdy może uruchomić wyświetlacz, który ma 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ń:

• [C-SR-1] MOCNO ZALECAMY korzystanie z implementacji bibliotek wymienionych poniżej z Android Open Source Project.

3.3.1. Interfejsy binarne aplikacji

Zarządzany kod bajtowy Dalvik może wywoływać kod natywny zawarty w pliku .apk aplikacji jako plik ELF .so skompilowany pod kątem odpowiedniej architektury sprzętowej urządzenia. Ponieważ kod natywny jest silnie zależny od 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 ze źródłem (czyli z nagłówkiem) i binarną biblioteką (w przypadku interfejsu ABI) z każdą wymaganą biblioteką na liście poniżej.
• [C-0-5] MUST accurately report the native Application Binary Interface (ABI) supported by the device, via the android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, and android.os.Build.SUPPORTED_64_BIT_ABIS parameters, each a comma separated list of ABIs ordered from the most to the least preferred one.

• [C-0-6] NALEŻY podać za pomocą powyższych parametrów podzbiór z poniższej listy ABI. NALEŻY NIE raportować żadnych ABI, które nie znajdują 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 następujące 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 MOŻESZ dodawać ani usuwać publicznych funkcji w bibliotekach natywnych wymienionych powyżej.

• [C-0-9] W /vendor/etc/public.libraries.txt NALEŻY podać listę dodatkowych bibliotek innych niż AOSP udostępnionych bezpośrednio aplikacjom innych firm.

• [C-0-10] Nie wolno udostępniać aplikacji innych firm na poziomie interfejsu API 24 lub wyższym żadnych innych bibliotek natywnych zaimplementowanych i dostarczonych w AOSP jako biblioteki systemowe, ponieważ są one 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 opisano szczegółowo wymagania dotyczące pełnej implementacji poszczególnych odpowiednich 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 więcej informacji o wymaganiach dotyczących pełnej implementacji poszczególnych funkcji.

• NALEŻY go skompilować, używając kodu źródłowego i plików nagłówkowych 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 przeznaczona tylko do zapewnienia zgodności wstecznej ze starszymi aplikacjami.

Jeśli implementacje na urządzeniu 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 (np. „8” w przypadku urządzeń ARMv8).

• [C-2-2] NALEŻY zawsze mieć dostępne te operacje, nawet w przypadku, gdy ABI jest implementowany na architekturze ARMv8, za pomocą natywnego wsparcia procesora lub emulacji oprogramowania:

  • Instrukcje dotyczące SWP i SWPB.
  • 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 wdrażania interfejsu API android.webkit.WebView MUSISZ użyć kompilacji projektu Chromium z upstreamowego projektu Android Open Source na gałęzi Androida 12.

• [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ć tę samą wartość co 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 górnym projekcie Android Open Source.
  • 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, a jeśli tak się dzieje, powinien być zgodny z specyfikacją HTML5.

• [C-1-4] 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ć pod oddzielnym identyfikatorem użytkownika, nie mieć dostępu do katalogu danych aplikacji, nie mieć bezpośredniego dostępu do sieci i mieć dostęp tylko do minimalnego zestawu 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 zwolnione z wymogów 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:
  • pamięć podręczna aplikacji/operacja offline
  • tag<video>
  • geolocation
• [C-1-2] MUSI obsługiwać interfejs webstorage API w HTML5/W3C oraz IndexedDB API w HTML5/W3C. Pamiętaj, że ponieważ instytucje opracowujące standardy dotyczące tworzenia stron internetowych przechodzą na IndexedDB zamiast webstorage, 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ść behawioralna 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 WOLNO stosować podejścia polegającego na użyciu listy dozwolonych, które zapewnia zgodność zachowania interfejsu API tylko w przypadku aplikacji wybranych przez implementatorów urządzeń.

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

• [C-0-1] Urządzenia NIE MOGĄ zmieniać działania ani semantyki standardowego zamiaru.
• [C-0-2] Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (np. usługi, aktywności, dostawcy treści itp.).
• [C-0-3] Urządzenia NIE MOGĄ zmieniać semantyki 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ę, aby otrzymywać dane wyjściowe z GnssMeasurement i GnssNavigationMessage.
  • [C-0-5] NALEŻY ograniczyć częstotliwość aktualizacji przesyłanych do 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 nowszy, NIE MOŻE ona zezwalać na rejestrowanie odbiorników transmisji dla niejawnych transmisji standardowych intencji Androida w pliku manifestu aplikacji, chyba że intencja transmisji wymaga uprawnienia "signature" lub "signatureOrSystem" protectionLevel lub znajduje się na liście wyjątków.
  • [C-0-7] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zatrzymać usługi działające w tle, tak jakby aplikacja wywołała metodę stopSelf() usługi, chyba że aplikacja została umieszczona na liście dozwolonych tymczasowo, aby obsłużyć zadanie widoczne 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-11] Urządzenia MUSZĄ zwracać te dostawcy zabezpieczeń jako pierwsze 7 wartości tablicy z metody Security.getProviders() w podanej kolejności i z podanymi nazwami (zwracanymi przez Provider.getName()) i klasy, chyba że aplikacja zmodyfikowała listę za pomocą 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 wszystkie. Implementator jest odpowiedzialny za zapewnienie zgodności z zachowaniem projektu Android Open Source. Dlatego implementatorzy urządzeń powinni w miarę możliwości korzystać z kodu źródłowego dostępnego w ramach Projektu Android Open Source, a nie ponownie implementować istotnych części systemu.

3.5.1. Ograniczenie aplikacji

Jeśli implementacje urządzeń implementują zastrzeżony mechanizm ograniczania dostępu do aplikacji i jego działanie jest bardziej restrykcyjne niż zastosowanie zasobnika aplikacji w stanie gotowości dla aplikacji z ograniczonym dostępem, to:

• [C-1-1] NALEŻY zapewnić użytkownikowi możliwość wyświetlenia listy aplikacji objętych ograniczeniami.
• [C-1-2] NALEŻY zapewnić użytkownikowi możliwość włączenia lub wyłączenia ograniczeń w każdej aplikacji.
• [C-1-3] Nie wolno automatycznie stosować ograniczeń bez dowodów na nieprawidłowe działanie systemu, ale można stosować ograniczenia w przypadku wykrycia nieprawidłowego działania systemu, np. zablokowanych blokad budzenia, długotrwałego działania usług i innych kryteriów. Kryteria mogą być określane przez implementatorów urządzenia, ale muszą być związane z wpływem aplikacji na stan systemu. Inne kryteria, które nie są ściśle związane ze stanem systemu, takie jak brak popularności aplikacji na rynku, NIE MOGĄ być używane jako kryteria.
• [C-1-4] NIE 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 poinformować 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 ograniczeniami musi on zwracać wartość true dla ActivityManager.isBackgroundRestricted().
• [C-1-7] NIE MOŻESZ ograniczać działania aplikacji na pierwszym planie, której użytkownik używa w danym momencie.
• [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 rozpocznie korzystanie z aplikacji, która była wcześniej ograniczona.
• [C-1-10] NIE wolno automatycznie umieszczać aplikacji w grupie ZAKRYTE w ciągu 2 godzin od ostatniego użycia przez użytkownika.

Jeśli implementacje na urządzeniach rozszerzają ograniczenia aplikacji zaimplementowane w AOSP, muszą:

• [C-2-1] NALEŻY przestrzegać implementacji opisanej w tym dokumencie.

3.5.2. Hibernacja aplikacji

Jeśli implementacje na urządzeniach obejmują funkcję hibernacji aplikacji, która jest zawarta w AOSP lub rozszerza funkcję zawartą w AOSP, to:

• [C-1-1] MUSI spełniać wszystkie wymagania podane w sekcji 3.5.1, z wyjątkiem [C-1-6] i [C-1-3].
• [C-1-2] NALEŻY zastosować ograniczenie dotyczące aplikacji tylko wtedy, gdy istnieją dowody, że użytkownik nie korzystał z niej przez pewien czas. MOCNO ZALECAMY, aby ten czas wynosił co najmniej miesiąc. Korzystanie MUSI być zdefiniowane przez wyraźną interakcję użytkownika za pomocą interfejsu API UsageStats#getLastTimeVisible() lub cokolwiek, co spowoduje, że aplikacja przejdzie ze stanu zatrzymania wymuszonego do stanu użycia, w tym wiązania usług, wiązania dostawców treści, wyraźne transmisje itp., które będą śledzone przez nowy interfejs API UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] NALEŻY stosować ograniczenia wpływające na wszystkich użytkowników urządzenia tylko wtedy, gdy istnieją dowody, że pakiet nie był używany przez ŻADNEGO użytkownika przez pewien czas. Zdecydowanie zalecamy, aby ten okres wynosił co najmniej miesiąc.
• [C-1-4] Aplikacja NIE MOŻE być niezdolna do reagowania na intencje aktywności, powiązania usług, żądania dostawcy treści lub transmisje bezpośrednie.

Tryb uśpienia aplikacji w AOSP spełnia powyższe wymagania.

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 Android poprzez zmianę sygnatur metod lub klas albo usuwanie klas lub pól klas.
• [C-0-2] NIE MOŻESZ dodawać żadnych publicznie dostępnych elementów (takich jak klasy, interfejsy, pola czy metody do istniejących klas lub interfejsów) ani interfejsów API Test czy System do interfejsów API w wymienionych powyżej przestrzeniach nazw. „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 interfejsów API udostępnionych publicznie.
• [C-0-4] NIE MOŻE być reklamowany ani w inny sposób udostępniany deweloperom.

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

• [C-0-5] NIE MOŻE znajdować się w przestrzeni nazw należącej do innej organizacji lub do niej odwołującej. 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 na nie wpływały.

Implementatorzy urządzeń MOGĄ dodawać niestandardowe interfejsy API w natywnym języku, poza interfejsami NDK, ale niestandardowe interfejsy API:

• [C-1-1] NIE MOŻE BYĆ w bibliotece NDK ani w bibliotece należącej do innej organizacji, jak opisano tutaj.

Jeśli implementator urządzenia zamierza ulepszyć jedną z wymienionych powyżej nazw przestrzeni pakietów (np. dodając nową przydatną funkcję do istniejącego interfejsu API lub dodając nowy interfejs 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 utrwalenie 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ę bajtkodów Dalvik.

• [C-0-2] NALEŻY skonfigurować środowisko uruchomieniowe Dalvik tak, aby przydzielać pamięć zgodnie z platformą Androida źródłowego i zgodnie z danymi podanymi 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 w górę 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ń MOGĄ 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
	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
	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)
	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)
	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) oraz obsługę aplikacji 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ą:

• [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 swojej ikony, a metody PackageManager są wywoływane w celu pobrania ikon.

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] NALEŻY wyświetlić użytkownikowi prośbę o dodanie skrótu żądanego przez aplikacje za pomocą metody ShortcutManager.requestPinShortcut() interfejsu API.
• [C-2-3] MUSI obsługiwać przypięte skróty oraz skróty dynamiczne i statyczne zgodnie z opisem na stronie Skróty do aplikacji.

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

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

Jeśli implementacje urządzeń korzystają z domyślnego menu uruchamiającego, które 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] Musisz 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, jeśli wartość wszystkich kanałów powiadomień aplikacji jest ustawiona na false.
• MOGĄ zastąpić plakietki ikon aplikacji za pomocą zastrzeżonego schematu plakietki, gdy aplikacje innych firm wskazują na obsługę zastrzeżonego schematu plakietki za pomocą zastrzeżonych interfejsów API, ale POWINNY używać zasobów i wartości udostępnianych przez interfejsy API plakietki powiadomień opisane w pakiecie SDK, takie jak Notification.Builder.setNumber() i 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 menu z aplikacjami.
• [C-1-3] Musi obsługiwać renderowanie widżetów o wymiarach 4 x 4 w standardowym rozmiarze siatki. 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] NALEŻY wyświetlić użytkownikowi prośbę o dodanie skrótu żądanego przez aplikacje za pomocą metody AppWidgetManager.requestPinAppWidget() interfejsu API.

3.8.3. Powiadomienia

Android zawiera interfejsy API 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) urządzenia.

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 opisem w dokumentacji pakietu SDK i w zakresie możliwym w ramach implementacji sprzętu urządzenia. Jeśli na przykład implementacja urządzenia zawiera wibrator, musi prawidłowo wdrażać 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] Musisz prawidłowo renderować wszystkie zasobów (ikony, pliki animacji itp.) udostępnione w interfejsach API lub w przewodniku po stylu ikon paska stanu/paska systemowego, chociaż mogą one zapewniać użytkownikom inne wrażenia w przypadku powiadomień niż w przypadku referencyjnej implementacji na Androidzie w wersji open source.
• [C-1-3] MUSISZ prawidłowo stosować zachowania opisane w przypadku interfejsów API na potrzeby aktualizowania, usuwania i grupowania powiadomień.
• [C-1-4] NALEŻY podać pełne informacje o zachowaniu interfejsu NotificationChannel API udokumentowanego w pakiecie SDK.
• [C-1-5] Musisz umożliwić użytkownikowi blokowanie i modyfikowanie powiadomień aplikacji innej firmy na poziomie każdego kanału i poziomu pakietu aplikacji.
• [C-1-6] Musisz też zapewnić użytkownikom możliwość wyświetlania kanałów powiadomień, które zostały usunięte.
• [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ą metody setGroupConversation MUSISZ wyświetlać wszystkie zasoby, w tym ikony, udostępnione przez android.app.Person.
• [C-SR-1] ZALECAMY, aby po wielokrotnym odrzuceniu powiadomienia przez użytkownika automatycznie wyświetlać użytkownikowi opcję zablokowania powiadomienia z określonej aplikacji innej firmy w ramach danego kanału i pakietu aplikacji.
• [C-SR-2] MOCNO zalecamy, aby umożliwić użytkownikom kontrolowanie powiadomień wyświetlanych w aplikacjach, które mają uprawnienia do odbierania powiadomień. Dokładność MUSI być taka, aby użytkownik mógł kontrolować, jakie typy powiadomień są przekazywane do tego odbiornika. Typy muszą obejmować powiadomienia „rozmowy”, „ostrzegające”, „ciche” i „ważne bieżące”.
• [C-SR-3] MOCNO POLECAMY, aby umożliwić użytkownikom określenie aplikacji, które nie będą otrzymywać powiadomień od konkretnego odbiornika powiadomień.
• 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ń.
• MOGĄ zarządzać widocznością i czasem, w którym aplikacje innych firm mogą powiadamiać użytkowników o istotnych zdarzeniach, aby ograniczać 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-4] ZALECAMY grupowanie i wyświetlanie conversation notifications powiadomień z wyjątkiem powiadomień z bieżącej usługi na pierwszym planie i powiadomień importance:high.

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

• [C-SR-5] MOCNO zalecamy wyświetlanie tej rozmowy jako dymka. 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 podanych w klasie interfejsu API Notification.Style i jej podklasach.
• 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 powiadomienia z poprzednim powiadomieniem i zasobów opisanych w klasie interfejsu API Notification.Builder, gdy wyświetlane są powiadomienia z poprzednim powiadomieniem.
• [C-3-2] NALEŻY wyświetlać działania udostępniane za pomocą 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łuchiwania, które są włączone przez użytkownika, w tym wszystkich metadanych dołączonych do obiektu powiadomienia.
• [C-0-2] MUSI obsługiwać wywołanie interfejsu API snoozeNotification(), zamykać powiadomienie i wywoływać ponownie po upływie czasu opóźnienia 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 wstrzymanego za pomocą standardowych interfejsów API, takich jak NotificationListenerService.getSnoozedNotifications().
• [C-1-2] Musisz udostępnić użytkownikom możliwość odłożenia powiadomień z każdej zainstalowanej aplikacji innej firmy, chyba że pochodzą one z trwałych usług działających 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ść zezwolenia lub odmowy zezwolenia aplikacjom innych firm na dostęp do konfiguracji zasad Nie przeszkadzać, wyświetlać automatyczne zasady Nie przeszkadzać utworzone przez aplikacje obok zdefiniowanych przez użytkownika i wstępnie zdefiniowanych zasad.
• [C-1-3] MUSI uwzględniać wartości suppressedVisualEffects przekazywane w NotificationManager.Policy, a 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ń Nie przeszkadzać.

3.8.4. Interfejsy Assist API

Android zawiera 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 końcowego, 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 powinien mieć możliwość wywołania asystenta w mniej niż 2 etapów od domyślnego menu ustawień komend głosowych i asystenta oraz udostępniania kontekstu tylko wtedy, gdy użytkownik wywoła 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ć użytkownikowi krótkie, niemodalne ciągi znaków, 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] Musisz 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] Musisz obsługiwać 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 umożliwiający aplikacjom stosowanie stylów w całym oknie 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 do motywu Holo zdefiniowanego 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ępnionych 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 wrażenia do motywu urządzenia określonego przez implementatora urządzenia.

• Implementacje na urządzeniu mogą modyfikować atrybuty motywu domyślnego 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 wrażenia dla deweloperów w ramach tej konfiguracji, ważne jest, aby styl ikony paska stanu był zachowany na różnych implementacjach urządzeń.

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

• [C-2-1] W przypadku ikon stanu systemu (np. siły sygnału i poziomu naładowania baterii) oraz powiadomień wysyłanych przez system należy używać koloru białego, chyba że ikona wskazuje na problem lub aplikacja prosi o jasny pasek stanu za pomocą flagi WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
• [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 tapety na żywo. 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ć animowane tapety zgodnie z opisem powyżej, POWINNY obsługiwać animowane tapety.

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 kod źródłowy Androida obejmuje ekran przeglądu, czyli interfejs użytkownika na poziomie systemu umożliwiający przełączanie zadań i wyświetlanie ostatnio używanych czynności i zadań za pomocą miniatury graficznego stanu aplikacji w momencie jej ostatniego zamknięcia przez użytkownika.

Implementacje na urządzeniu, w tym klawisz nawigacji funkcji ostatnich, zgodnie z opisem w sekcji 7.2.3, mogą zmieniać 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 po dwukrotnym naciśnięciu klawisza funkcyjnego „Ostatnie”.
• POWINIEN aktywować tryb wielookienkowy z podzielonym ekranem (jeśli jest obsługiwany), gdy przycisk funkcji ostatnich aplikacji jest długo naciśnięty.
• MOŻNA wyświetlać powiązane ostatnie elementy jako grupę, która porusza się razem.
• [SR-1] NAJTRWA w przypadku ekranu przeglądu zalecamy używanie górnego interfejsu użytkownika Androida (lub podobnego interfejsu opartego na miniaturach).

3.8.9. Zarządzanie wejściami

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

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

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

3.8.10. Sterowanie multimediami na ekranie blokady

Od wersji 5.0 Androida interfejs Remote Control Client API jest wycofany na rzecz Media Notification Template, 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 podać współrzędne lokalizacji,

• [C-1-2] Musisz wyświetlić aktualny 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 lekka, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light 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 łacińskiego rozszerzonego A, B, C i D oraz wszystkich znaków w bloku symboli walutowych w Unicode 7.0.
• [C-1-3] Nie wolno usuwać ani modyfikować pliku NotoColorEmoji.tff w pliku obrazu systemu. (dozwolone jest dodanie nowej czcionki emotikonów, aby zastąpić emotikony w pliku NotoColorEmoji.tff)
• POWINIEN obsługiwać odcienie skóry i emotikony przedstawiające różne rodziny, zgodnie z raportem technicznym 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 tego kraju 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] Domyślnie tekst MUSI być renderowany za pomocą czcionki zgodnej z Unicode. Czcionka niezgodna z Unicode NIE MOŻE być ustawiona jako domyślna, chyba że użytkownik wybierze ją w selektorze języka.
• [C-2-2] MUSI obsługiwać czcionkę zgodną z Unicode oraz czcionkę niezgodną z Unicode, jeśli taka czcionka jest obsługiwana na urządzeniu. Czcionka niezgodna z Unicode NIE MOŻE usuwać ani nadpisywać czcionki zgodnej z Unicode.
• [C-2-3] TRZEBA renderować tekst za pomocą czcionki niezgodnej z Unicode, JEDYNIE JEŚLI podano kod języka z kodem skryptu Qaag (np. my-Qaag). Do odwołania się do czcionki niezgodnej z Unicode w Mjanmie nie można używać żadnych innych kodów języków ani regionów ISO (zarówno przypisanych, nieprzypisanych, jak i zarezerwowanych). Deweloperzy aplikacji i twórcy stron internetowych mogą określić my-Qaag jako kod języka, tak jak w przypadku każdego innego języka.

3.8.14. Wiele okien

Jeśli implementacje urządzeń mają możliwość wyświetlania wielu działań w tym samym czasie, muszą:

• [C-1-1] NALEŻY zaimplementować tryb wielu okien zgodnie z zachowaniem aplikacji i interfejsami API opisanymi w dokumentacji obsługi trybu wielu okien pakietu SDK Androida oraz spełnić te wymagania:
• [C-1-2] MUSI honorować 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ść ekranu jest mniejsza niż 440 dp.
• [C-1-4] Rozmiar aktywności NIE MOŻE być mniejszy niż 220 dp w trybach wielookiennych innych niż obraz w obrazie.
• Implementacje urządzeń o rozmiarze ekranu xlarge POWINNY obsługiwać tryb swobodny.

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

• [C-2-2] Należy przyciąć dokowane okno na podzielonym ekranie, ale należy pokazać część jego zawartości, jeśli aplikacja Launcher jest oknem aktywnym.
• [C-2-3] MUSI uwzględniać zadeklarowane wartości AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight aplikacji uruchamiającej innej firmy oraz nie może ich zastępować podczas wyświetlania niektórych treści z 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 trybie obrazu w obrazie w trybie wielookiennym, gdy aplikacja:

  • kierować aplikację na interfejs API na poziomie 26 lub wyższym i deklarować to za pomocą elementu android:supportsPictureInPicture.
  • kierować aplikację na poziom interfejsu API 25 lub niższy i deklarować zarówno android:resizeableActivity, jak i android:supportsPictureInPicture;

• [C-3-2] Musisz udostępniać działania w SystemUI zgodnie z określeniami bieżącej aktywności PIP za pomocą interfejsu setActions()API.

• [C-3-3] Musi obsługiwać formaty obrazu o stosunku co najmniej 1:2,39 i maksymalnie 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 zaimplementowany, 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 PIP. Implementacja AOSP spełnia ten wymóg dzięki elementom sterującym w pasku powiadomień.

• [C-3-6] W przypadku okna PIP, gdy aplikacja nie deklaruje wartości dla AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight:

  • Urządzenia z wartością Configuration.uiMode inną niż UI_MODE_TYPE_TELEVISION MUSZĄ mieć minimalną szerokość i wysokość 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 ekranu, który może nie być dostępny dla aplikacji z powodu wycięcia na wyświetlaczu lub zakrzywionego ekranu na krawędziach.

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 WindowManager.LayoutParamsAPI zgodnie z opisem w pakiecie SDK.
• [C-1-4] MUSI podawać 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 działania.

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 dbającym o bezpieczeństwo 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ń obsługują 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:
  • Jeśli implementacja urządzenia nie ma jeszcze skonfigurowanych danych użytkownika, to:
    • [C-1-5] NALEŻY zarejestrować aplikację DPC jako aplikację 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.
    • [C-1-8] Musisz wysłać działanie ACTION_GET_PROVISIONING_MODE po wywołaniu obsługi Provisioning właściciela urządzenia, aby aplikacja DPC mogła wybrać, czy ma być właścicielem urządzenia, czy właścicielem profilu, chyba że z kontekstu wynika, że jest tylko jedna opcja (np. w przypadku obsługi Provisioning na podstawie NFC, gdzie obsługa właściciela profilu nie jest obsługiwana).
    • [C-1-9] DO aplikacji Właściciel urządzenia MUSI zostać wysłana intencja ACTION_ADMIN_POLICY_COMPLIANCE, jeśli podczas obsługi zostaje utworzony Właściciel urządzenia, niezależnie od użytej metody obsługi. Użytkownik nie może kontynuować kreatora konfiguracji, dopóki aplikacja Właściciel urządzenia nie zakończy działania.
  • Gdy implementacja urządzenia zawiera dane użytkownika, to:
    • [C-1-7] Nie można już rejestrować aplikacji DPC jako aplikacji właściciela urządzenia.
• [C-1-2] Koniecznie wymagaj podjęcia przez użytkownika jakiegoś działania przed rozpoczęciem lub w trakcie procesu udostępniania, aby wyraził on zgodę na ustawienie aplikacji jako właściciela urządzenia. Użytkownik może wyrazić zgodę na przetwarzanie danych w sposób manualny lub automatyczny, ale przed rozpoczęciem obsługi żądania przez właściciela urządzenia należy wyświetlić odpowiednie powiadomienie (opisane 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 aplikacji w wersji podstawowej w przypadku korzystania z niej poza firmą.
• [C-1-3] Nie wolno zakodować w twardym kodzie zgody ani uniemożliwiać korzystania z innych aplikacji właściciela urządzenia.

Jeśli implementacje na urządzeniu deklarują android.software.device_admin, ale zawierają również zastrzeżone rozwiązanie do zarządzania właścicielem urządzenia i mechanizm promowania aplikacji skonfigurowanej w ich rozwiązaniu jako „uprawnienia właściciela urządzenia” w ramach standardowego interfejsu API DevicePolicyManager na Androidzie, to:

• [C-2-1] Konieczne jest wdrożenie procesu weryfikacji, który ma na celu potwierdzenie, że promowana aplikacja należy do legalnego rozwiązania do zarządzania urządzeniami firmowymi i została już skonfigurowana w ramach rozwiązania firmowego w taki sposób, aby miała prawa równoważne z prawami „Właściciela urządzenia”.
• [C-2-2] NALEŻY wyświetlić te same informacje o zgodzie właściciela urządzenia w ramach procesu AOSP, który został zainicjowany przez android.app.action.PROVISION_MANAGED_DEVICE przed zarejestrowaniem aplikacji DPC jako „Właściciel urządzenia”.
• MOŻE mieć 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] NALEŻY zaimplementować 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 Provisioning w profilu zarządzanym (przepływ danych zainicjowany przez DPC za pomocą android.app.action.PROVISION_MANAGED_PROFILE lub przez platformę), ekran zgody i przebieg interakcji z użytkownikiem MUSZĄ być zgodne z implementacją AOSP.

• [C-1-3] W ustawieniach należy DOSTARCZAĆ użytkownikowi następujące możliwości, aby poinformować go, że dana funkcja systemu została wyłączona przez kontroler zasad urządzenia (DPC):

  • Ujednolicona ikona lub inna funkcja dla użytkownika (np. ikona informacji o AOSP w górę) wskazująca, ż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

• [C-1-4] W profilu służbowym MUSISZ uruchomić w ramach intencją ACTION_PROVISIONING_SUCCESSFUL, jeśli właściciel profilu został określony, gdy inicjowanie obsługi zostało zainicjowane przez intencję android.app.action.PROVISION_MANAGED_PROFILE, a DPC zaimplementował uchwyt.

• [C-1-5] NALEŻY wysłać transmisję ACTION_PROFILE_PROVISIONING_COMPLETE do DPC profilu służbowego, gdy inicjowanie obsługi jest wywoływane przez intencję android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-6] NALEŻY wysłać działanie ACTION_GET_PROVISIONING_MODE po wywołaniu obsługi inicjowania profilu, aby aplikacja DPC mogła wybrać, czy ma być właścicielem urządzenia czy właścicielem profilu, gdy inicjowanie zostanie wywołane przez działanie android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] NALEŻY wysłać intencję ACTION_ADMIN_POLICY_COMPLIANCE do profilu służbowego, gdy podczas obsługi zostaje utworzony właściciel profilu, niezależnie od tego, która metoda obsługi jest używana, z wyjątkiem sytuacji, gdy obsługa jest wywoływana przez intencję android.app.action.PROVISION_MANAGED_PROFILE. Użytkownik nie może kontynuować pracy z kreatorem konfiguracji, dopóki aplikacja Właściciel profilu nie zakończy działania.

• [C-1-8] NALEŻY wysłać ACTION_MANAGED_PROFILE_PROVISIONED broadcast do DPC profilu osobistego, gdy ustanowiono właściciela profilu, niezależnie od zastosowanej metody obsługi.

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] NALEŻY użyć plakietki ikony (podobnej do plakietki upstream AOSP) do reprezentowania zarządzanych aplikacji i widżetów oraz innych elementów interfejsu z plakietką, takich jak Ostatnie i Powiadomienia.
• [C-1-4] Musi wyświetlać ikonę powiadomienia (podobną do plakietki AOSP) wskazującą, że użytkownik jest w aplikacji na profilu zarządzanym.
• [C-1-6] Jeśli istnieje profil zarządzany, w oknie „Wybór intencji” MUSI być widoczna opcja pozwalająca użytkownikowi przekazać intencję 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, MUSI on udostępniać użytkownikowi te możliwości:
  • oddzielne rozliczanie baterii, lokalizacji, danych mobilnych i zajęcia miejsca na dysku w przypadku głównego użytkownika i profilu zarządzanego;
  • niezależne zarządzanie aplikacjami VPN zainstalowanymi na profilu głównego użytkownika lub profilu zarządzanym;
  • niezależne zarządzanie aplikacjami zainstalowanymi w ramach profilu głównego użytkownika lub profilu zarządzanego.
  • niezależne zarządzanie kontami w ramach profilu głównego użytkownika lub profilu zarządzanego.
• [C-1-8] NALEŻY zadbać o to, aby w preinstalowanych aplikacjach do wybierania numerów, kontaktów i wiadomości można było wyszukiwać i wyświetlać informacje o dzwoniącym z profilu zarządzanego (jeśli istnieje) obok informacji z profilu głównego, jeśli zezwala na to kontroler zasad urządzenia.
• [C-1-9] MUSI spełniać wszystkie wymagania dotyczące zabezpieczeń obowiązujące w przypadku urządzenia z włączoną obsługą wielu użytkowników (patrz sekcja 9.5), mimo że profil zarządzany nie jest 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, mogą:

• [C-2-1] MUSI obsługiwać możliwość określenia osobnego ekranu blokady spełniającego poniższe wymagania w celu przyznawania dostępu tylko aplikacjom działającym 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Ą używać tych samych mechanizmów przechowywania i zarządzania danymi logowania co profil nadrzędny, zgodnie z opisem na stronie projektu Android 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 zwróconej przez 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 z wielu użytkowników, gdy isLogoutEnabled powraca true. Element interfejsu MUSI być dostępny na ekranie blokady bez odblokowywania urządzenia.

Jeśli implementacje na urządzeniu deklarują android.software.device_admin i zapewniają użytkownikowi możliwość dodania dodatkowych użytkowników pomocniczych, to:

• [C-SR-1] ZALECAMY wyświetlanie tych samych informacji o zgodzie właściciela urządzenia AOSP, które zostały wyświetlone w ramach procesu inicjowanego przez android.app.action.PROVISION_MANAGED_DEVICE, przed zezwoleniem na dodawanie kont przez nowego użytkownika dodatkowego, aby użytkownicy wiedzieli, że urządzenie jest zarządzane.

3.10. Ułatwienia dostępu

Android udostępnia warstwę ułatwień dostępu, która ułatwia użytkownikom z niepełnosprawnościami poruszanie się po urządzeniach. Android udostępnia też interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu otrzymywanie wywołań zwrotnych dotyczących zdarzeń użytkownika i systemu oraz generowanie alternatywnych mechanizmów informacji zwrotnej, takich jak odczytywanie tekstu, informacje zwrotne haptyczne i sterowanie za pomocą kulki 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ć interfejs API ułatwień dostępu na Androida zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] Musi generować zdarzenia ułatwień dostępu i przekazywać odpowiednie dane AccessibilityEvent do wszystkich zarejestrowanych implementacji AccessibilityService, zgodnie z dokumentacją pakietu SDK.
• [C-1-4] NALEŻY zapewnić użytkownikowi możliwość sterowania usługami ułatwień dostępu, które deklarują flagę AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Pamiętaj, że w przypadku implementacji na urządzeniach z systemowym paskiem nawigacyjnym użytkownik powinien mieć opcję użycia przycisku na pasku nawigacyjnym systemu do sterowania tymi usługami.

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 plików (FBE).
• NALEŻY zapewnić w ramach procesu konfiguracji domyślnej 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, to:

• [C-1-1] MUSI obsługiwać interfejsy API ram worka TTS na Androida.

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

• [C-2-1] Musisz 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 z Androidem 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, tak aby aplikacja, która korzysta z tych interfejsów API i danych wejściowych innych firm na podstawie TIF, mogła być instalowana i używana 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 pilnych 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 nieaktywowane głosem (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ą getIconBitmap() lub getIconUri() oraz tytuły uzyskane za pomocą 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świetlać ikonę aplikacji innej firmy, 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 spełnić wymogi bezpieczeństwa (np. w przypadku rozpraszania uwagi kierowcy), ale NIE MOŻE faworyzować treści ani dostawcy treści.

• [C-1-5] NALEŻY wziąć pod uwagę dwukrotne kliknięcie KEYCODE_HEADSETHOOK lub KEYCODE_MEDIA_PLAY_PAUSE jako KEYCODE_MEDIA_NEXT w przypadku MediaSession.Callback#onMediaButtonEvent.

3.15. Aplikacje błyskawiczne

Jeśli implementacje urządzeń obsługują aplikacje błyskawiczne, muszą spełniać te wymagania:

• [C-1-1] Aplikacje błyskawiczne MOGĄ mieć tylko te uprawnienia, które mają wartość android:protectionLevel równą "instant".
• [C-1-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-1-3] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interaktywność z zainstalowanymi aplikacjami, chyba że komponent jest udostępniany za pomocą android:visibleToInstantApps.
• [C-1-4] Zainstalowane aplikacje NIE MOGĄ uzyskiwać szczegółowych informacji o aplikacji błyskawicznej na urządzeniu, chyba że aplikacja błyskawiczna wyraźnie połączy się z zainstalowaną aplikacją.

• Implementacje urządzeń MUSZĄ zapewniać użytkownikom te możliwości interakcji z aplikacją błyskawiczną: AOSP spełnia wymagania dzięki domyślnemu interfejsowi systemu, ustawieniom i wywoływaczemu. Implementacje na urządzeniu:

  • [C-1-5] Musisz umożliwić użytkownikowi wyświetlanie i usuwanie Aplikacji błyskawicznych zapisanych lokalnie w pamięci podręcznej w przypadku każdego pojedynczego pakietu aplikacji.
  • [C-1-6] Musisz wyświetlać użytkownikowi stałe powiadomienie, które można zwinąć, gdy aplikacja błyskawiczna działa na pierwszym planie. To powiadomienie MUSI zawierać informację, że aplikacje błyskawiczne nie wymagają instalacji, oraz opcję kierującą użytkownika do ekranu informacji o aplikacji w Ustawieniach. W przypadku aplikacji natychmiastowych uruchamianych za pomocą intencji internetowych, zdefiniowanych za pomocą intencji z działaniem ustawionym na Intent.ACTION_VIEW i schematem „http” lub „https”, dodatkowa interakcja użytkownika POWINNA umożliwiać użytkownikowi nie uruchamianie aplikacji natychmiastowej, a zamiast tego uruchomienie powiązanego linku w skonfigurowanej przeglądarce internetowej, jeśli przeglądarka jest dostępna na urządzeniu.
  • [C-1-7] 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-8] Musisz wstępnie wczytać co najmniej 1 aplikację lub komponent usługi z obsługą intencji wymienionych w pakiecie SDK tutaj 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 dostępne 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 musi być zainstalowana tylko jedna 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 aktywności w systemie zamiast naciśnięcia przycisku Wstecz, gdy w systemie nie ma już aktywnych aktywnoś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 WOLNO stosować innych zmian w zasadach, takich jak zmiana wydajności procesora lub zmiana priorytetów harmonogramu.

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

• [C-1-1] Musisz zignorować atrybut cantSaveState ustawiany przez aplikacje i nie możesz zmieniać 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.

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

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 służące do przechowywania nieprzetworzonych kontaktów tylko na urządzeniu, które nie są powiązane z kontem w usłudze AccountManager. Takie kontakty są tworzone z co najmniej jedną wartością inną niż null w kolumnach ACCOUNT_NAME i ACCOUNT_TYPE.

Implementacje na urządzeniu:

• [C-SR-1] Zdecydowanie zalecamy, aby nie tworzyć niestandardowych kont lokalnych.

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

• [C-1-1] Musisz zwrócić ACCOUNT_NAME na niestandardowym koncie lokalnym: ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] Wartość ACCOUNT_TYPE na niestandardowym koncie lokalnym MUSI zostać zwrócona przez ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] Nieprzetworzone kontakty wstawiane przez aplikacje innych firm za pomocą domyślnego konta lokalnego (czyli przez ustawienie wartości null dla pól ACCOUNT_NAME i ACCOUNT_TYPE) MUSZĄ być wstawiane na niestandardowe konto lokalne.
• [C-1-4] Niestandardowe kontakty 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 surowych 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] Musi być możliwe 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łową instalację 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ą pakietu 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 ze źródeł nieznanych, 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 ze źródeł nieznanych.

• NALEŻY umożliwić użytkownikowi przyznanie/wycofanie uprawnień do instalowania aplikacji z nieznanych źródeł, ale MOŻNA zaimplementować to jako funkcję nieaktywną 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 dostarczony przez interfejs API systemu PackageManager.setHarmfulAppWarning przed uruchomieniem czynności w aplikacji, która została oznaczona przez ten sam interfejs API systemu PackageManager.setHarmfulAppWarning jako potencjalnie szkodliwa.

• NALEŻY umożliwić użytkownikowi odinstalowanie lub uruchomienie aplikacji w oknie z ostrzeżeniem.

• [C-0-8] NALEŻY wdrożyć obsługę systemów 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.

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, a bufory wejściowe powinny być zwracane tylko po przetworzeniu.
  • Nie należy przechowywać odkodowanych buforów dłużej niż określa to standard (np. SPS).
  • Nie należy przechowywać zakodowanych buforów dłużej niż wymaga tego struktura GOP.

Wszystkie kodeki wymienione w sekcji poniżej są dostarczane jako implementacje oprogramowania w preferowanej implementacji Androida z projektu Android Open Source.

Pamiętaj, ż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 pamiętać, że implementacje tego kodu, w tym w oprogramowaniu open source lub shareware, mogą wymagać licencji patentowych 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.MediaCodecAPI.

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 (profil HE AAC rozszerzony ISO/IEC 23003-3, który obejmuje profil podstawowy USAC i profil sterowania zakresem dynamicznym ISO/IEC 23003-4)
• [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, a urządzenie może zmniejszać próbkowanie i poziom miksowania podczas odtwarzania.
• [C-1-10] Opus

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

• [C-2-1] Dekodowanie MUSI być przeprowadzone 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ć zachowania 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-1] ZDECYDOWANIE zalecamy, aby wszystkie dekodery audio AAC spełniały wymagania C-2-1 i C-2-2.

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 poziomem 1 profilu MPEG-D DRC.
• [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 Dynamic Range Control.

Jeśli obsługiwana jest norma ISO/IEC 23003-4 i w dekodowanym strumieniu bitów znajdują się metadane ISO/IEC 23003-4 oraz ISO/IEC 14496-3, wykonaj te czynności:

• 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 i 5.1 z 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 standardowymi częstotliwościami próbkowania od 16 do 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profile (enhanced AAC+)	Obsługa treści mono, stereo, 5.0 i 5.1 ze standardowymi częstotliwościami 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	W przypadku kodera i dekodera: MUSI być obsługiwany co najmniej tryb 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 w konfiguracji audio z użyciem liczb zmiennoprzecinkowych.	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 dzwonka 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] MUSI zawierać koder HEVC z akceleracją sprzętową, który obsługuje BITRATE_MODE_CQtryb kontroli szybkości transmisji bitów, profil HEVCProfileMainStilli 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, to:

• [C-1-1] MUSI obsługiwać dekodowanie obrazu HEIF (HEIC).

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 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-1] ZALECAMY obsługę formatu kolorów RGB888 w przypadku trybu wejściowego Surface.

• [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 zaleca się 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ć sprzętowego kodeka VP8, 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ą obsługę największych możliwych ramek skompresowanych i nieskompresowanych 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 semiplanarnych YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (równoważny COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (równoważny COLOR_FormatYUV420SemiPlanar). ZALECAMY obsługę obu formatów.

• [SR-1] Silnie zaleca się, aby kodery i dekodery wideo obsługiwały co najmniej jeden z formatów kolorów 8:8:8 YUV420 (YV12, NV12, NV21 lub równoważny format zoptymalizowany przez producenta).

• [C-1-5] Dekodery wideo obsługujące format o wysokiej głębi bitowej (9 i więcej bitów na kanał) MUSZĄ obsługiwać format 8-bitowy, jeśli zostanie to zażądane przez aplikację. 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 został skonfigurowany przy użyciu wyjścia Surface.
• [C-4-2] NALEŻY domyślnie ustawić 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 interfejs OMX, który jest wieloplatformowym interfejsem API przyspieszającym multimedia, a także interfejs Codec 2.0, który jest interfejsem API przyspieszającym multimedia o małym obciążeniu.

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

• [C-1-1] Musisz zapewnić obsługę kodeków multimedialnych za pomocą interfejsów OMX lub Codec 2.0 (lub obu), tak jak w projekcie Android Open Source Project, oraz nie wyłączać ani nie obchodzić zabezpieczeń. Nie oznacza to, że każdy kodek MUSI używać interfejsu OMX lub Codec 2.0 API, tylko że MUSI być dostępna obsługa co najmniej jednego z tych interfejsów API, a obsługa dostępnych interfejsów API MUSI obejmować zabezpieczenia.
• [C-SR-1] 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 należy DODAWAĆ 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-2] Zdecydowanie zalecamy, 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] MUSI zawierać odpowiedni kodek oprogramowania Codec 2.0 z Android Open Source Project (jeśli jest dostępny) dla każdego formatu i typu multimediów (kodowania lub dekodowania) obsługiwanego przez urządzenie.
• [C-3-2] Musisz umieścić kodeki programowe Codec 2.0 w procesie obsługi kodeków programowych zgodnie z informacjami podanymi w projekcie Android Open Source, aby umożliwić bardziej szczegółowe przyznawanie dostępu do kodeków programowych.
• [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 MediaCodecInfo API.

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 ze wskazówkami dotyczącymi nazewnictwa w Codec 2.0 na Androida.
• [C-1-4] Kodeki o nazwach zaczynających się od „OMX.google.” lub „c2.android.” NIE można ich opisywać jako produktów danego dostawcy ani przyspieszonych sprzętowo.
• [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] Kodeki, których nie ma w projekcie Android Open Source Project lub które nie są oparte na kodzie źródłowym w tym projekcie, MUSZĄ być opisane jako pochodzące od dostawcy.
• [C-1-7] Kodek, który wykorzystuje akcelerację sprzętową, MUSI być opisany jako akcelerowany sprzętowo.
• [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 przyspieszany 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 o wydajności.
• Dodatkowo powinni publikować rozszerzone punkty skuteczności, jeśli obsługują trwałą skuteczność filmu inną niż standardowa.

5.2. Kodowanie wideo

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

• W ciągu 2 przesuwających się okien nie powinna przekraczać o więcej niż 15% szybkości transmisji danych między interwałami klatek wewnątrzramkowych (I-frame).
• Nie powinna przekraczać 100% szybkości transmisji w przesuwalnym oknie liczonym w sekundach.

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

• [C-1-1] MUSI obsługiwać co najmniej 1 kodek wideo VP8 lub H.264 i udostępniać go 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 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.
• POWINIEN obsługiwać zmienne liczby klatek, przy czym koder wideo POWINIEN określać bieżący czas trwania klatki na podstawie sygnałów czasowych buforów wejściowych i przydzielać bity 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 przyspieszone sprzętowo i obsługują co najmniej 1 podłączoną lub wpinaną kamerę sprzętową udostępnioną przez interfejsy API android.camera:

• [C-4-1] Wszystkie enkodery wideo i obrazów przyspieszone sprzętowo 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 obrazów.

Jeśli implementacje na urządzeniach obsługują kodowanie HDR, to:

• [C-SR-1] BARDZO ZALECAMY udostępnienie wtyczki dla interfejsu API do płynnego transkodowania, aby przekonwertować format HDR na SDR.

5.2.1. H.263

Jeśli implementacje urządzeń obsługują kodery H.263 i udostępniają je aplikacjom innych firm, 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 (niepotrzebne segmenty) jest jednak OPCJONALNA. Ponadto w celu zachowania zgodności z innymi urządzeniami z Androidem zalecamy, aby kodery nie używały profili ASo, FMO i RS w przypadku profilu podstawowego.
• [C-1-2] MUSI obsługiwać profile kodowania wideo SD (standardowa rozdzielczość) wymienione w tabeli poniżej.
• Powinien obsługiwać poziom 4 profilu głównego.
• Powinien obsługiwać profile kodowania filmów w rozdzielczości HD (wysoka rozdzielczość) 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 projektu WebM dotyczące kodowania RTC na sprzęcie, aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo i usług wideokonferencji.

Jeśli implementacje urządzeń zgłaszają obsługę kodowania VP8 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 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.
• [C-SR-1] ZALECAMY, aby obsługiwać profile dekodowania HD zgodnie z tabelą 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 obsługują Profile 2 lub 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.
• NALEŻY obsługiwać profile kodowania HD zgodnie z tabelą poniżej.
• [C-SR-1] MOCNO zalecamy obsługę profili kodowania HD wskazanych w tabeli poniżej, jeśli istnieje sprzętowy koder.

	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 i liczby klatek na sekundę 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 (standardowa rozdzielczość) 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 na urządzeniu:

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

	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./stelewizor)
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 danymi w tabeli poniżej.
• NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• [C-1-2] MUSI obsługiwać profile dekodowania HD zgodnie z tabelą poniżej, jeśli jest dekoder sprzętowy.

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

• [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden z formatów H.265 lub VP9 do dekodowania profili 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 API Media:

• [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 lub większa niż rozdzielczość filmu:

• [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać profile 720p podane 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./stelewizor)	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 SD zgodnie z podanymi w tabeli 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 podanymi w tabeli poniżej.

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

• [C-3-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden z formatów VP9 lub H.265 do dekodowania 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ń zgłaszają obsługę profilu HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) za pomocą interfejsów API multimediów:

• [C-4-1] Implementacje urządzeń MUSZĄ akceptować wymagane metadane HDR (KEY_HDR_STATIC_INFO dla wszystkich profili HDR oraz 'KEY_HDR10_PLUS_INFO' dla 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ą interfejsu HDR_TYPE_DOLBY_VISION, to:

• [C-1-1] MUSISZ podać narzędzie do wyodrębniania obsługujące Dolby Vision.
• [C-1-2] MUSI 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 podstawowych zgodnych z wersjami wcześniejszymi (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ą oznaczone jako „NALEŻY”, od Androida 4.3 planujemy zmienić je na „NALEŻY”. W przypadku istniejących i nowych urządzeń z Androidem ZALECAMY spełnienie tych wymagań, które są oznaczone jako „NALEŻY”, ponieważ w przeciwnym razie nie będą one zgodne z Androidem po aktualizacji do przyszłej wersji.

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 z tymi cechami:

  • 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 użyciem próbkowania w dół.

• 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 oraz prawidłowo wypełniać informacje o dostępnych mikrofonach na urządzeniu dostępnych dla aplikacji innych firm za pomocą interfejsu API AudioManager.getMicrophones() oraz obecnie aktywnych mikrofonów 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ę przy dowolnym stosunku wyższym niż 16000:22050 lub 44100:48000.

• [C-2-2] NALEŻY uwzględnić odpowiedni filtr antyaliasingu w przypadku interpolacji i deinterpolacji.

5.4.2. Przechwytywanie danych do rozpoznawania głosu

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

• [C-1-1] MUST capture android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION audio source at one of the sampling rates, 44100 and 48000.
• [C-1-2] Domyślnie należy wyłączyć wszelkie przetwarzanie dźwięku w celu redukcji szumów podczas nagrywania strumienia audio z źródła AudioSource.VOICE_RECOGNITION.
• [C-1-3] Domyślnie należy wyłączyć automatyczne sterowanie wzmocnieniem podczas nagrywania strumienia audio z źródła audio AudioSource.VOICE_RECOGNITION.
• NALEŻY nagrywać strumień audio rozpoznawania głosu z w przybliżeniu płaską charakterystyką amplitudy w stosunku do częstotliwości: konkretnie ±3 dB od 100 Hz do 4000 Hz.
• NALEŻY nagrywać strumień audio do rozpoznawania mowy z ustawionymi czułościami wejścia, tak aby źródło o poziomie mocy dźwięku (SPL) 90 dB przy 1000 Hz dawało 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 do +12 dB w przypadku 90 dB SPL na 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 technologię tłumienia szumów (redukcji) dostosowane do rozpoznawania mowy, to:

• [C-2-1] NALEŻY zezwolić na sterowanie tym efektem dźwiękowym za pomocą interfejsu API android.media.audiofx.NoiseSuppressor.
• [C-2-2] Identyfikator musi jednoznacznie wskazywać 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 audio 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 zastosować technologię usuwania echa akustycznego (AEC) dostosowaną do komunikacji głosowej i zastosowanej do ścieżki przechwytywania podczas przechwytywania za pomocą AudioSource.VOICE_COMMUNICATION

Jeśli implementacje urządzeń zapewniają funkcję usuwania echa akustycznego, która jest wstawiana na ścieżce przechwytywania dźwięku po wybraniu opcji AudioSource.VOICE_COMMUNICATION, to:

• [C-SR-1] MOCNO_ZALECANE jest zadeklarowanie tego za pomocą metody AcousticEchoCanceler API AcousticEchoCanceler.isAvailable()
• [C-SR-2] ZALECAMY, aby ten efekt dźwiękowy był możliwy do kontrolowania za pomocą interfejsu API AcousticEchoCanceler.
• [C-SR-3] MOCNO_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] Musisz 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 aplikację, 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ę rejestrującą z dowolnym uprawnieniem 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 aplikacji ułatwień dostępu). Jeśli jednak aplikacja rejestruje dane za pomocą uprawnienia AudioSource.VOICE_COMMUNICATION, inna aplikacja może rejestrować połączenie głosowe, jeśli jest to aplikacja uprzywilejowana (wstępnie zainstalowana) 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, aplikacja, która rozpoczęła nagrywanie jako ostatnia, odbiera dźwięk.

5.4.6. Poziomy wzmocnienia mikrofonu

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

• W zakresie średnich częstotliwości powinny one mieć w przybliżeniu płaskie charakterystyki amplitudy w funkcji częstotliwości: konkretnie ±3 dB w zakresie 100–4000 Hz w przypadku 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 źródło tonów sinusoidalnych o częstotliwości 1000 Hz odtwarzane z poziomem ciśnienia akustycznego (SPL) 90 dB dawało odpowiedź z RMS 2500 dla próbek 16-bitowych (lub -22,35 dB w przypadku próbek z pełną precyzją zmiennoprzecinkową) dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania mowy.
• [C-SR-1] ZALECAMY, aby poziomy amplitudy w zakresie niskich częstotliwości wynosiły ±20 dB w zakresie 5–100 Hz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania głosu.
• [C-SR-2] ZALECAMY, aby poziomy amplitudy w zakresie wysokich częstotliwości (szczególnie ±30 dB w zakresie 4000–22 kHz) były porównywalne z poziomami średnich częstotliwości w przypadku każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania mowy.

5.5. Odtwarzanie dźwięku

Android obsługuje odtwarzanie dźwięku przez peryferyjne urządzenie wyjściowe zgodnie z definicją 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 surowego dźwięku 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, 24000, 32000, 44100, 48000 w przypadku konfiguracji kanałów wymienionych powyżej
    • 96000 w mono i stereo

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ądzeniu deklarują funkcję android.hardware.audio.output, to:

• [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 sterować za pomocą podklasy AudioEffect DynamicsProcessing.
• NALEŻY 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-1] Zdecydowanie zalecamy obsługę efektów w postaci liczb zmiennoprzecinkowych i wielokanałowy.

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 oddzielnie dla każdego strumienia audio, używając typu treści lub użycia zdefiniowanego za pomocą AudioAttributes oraz użycia dźwięku w samochodzie zdefiniowanego publicznie w android.car.CarAudioManager.

5.5.4. Przesyłanie dźwięku

Jeśli implementacje urządzeń obsługują odtwarzanie z przesłanymi plikami audio, to:

• [C-SR-1] MOCNO POLECAMY przycinanie odtwarzanych treści audio bez przerw, gdy jest to określone przez interfejs API AudioTrack gapless i kontener multimediów dla MediaPlayer.

5.6. Opóźnienie dźwięku

Opóźnienie dźwięku to czas opóźnienia sygnału dźwiękowego w systemie. Wiele klas 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 kodowanych w formacie PCM a momentem, w którym odpowiedni dźwięk jest prezentowany otoczeniu na przetworniku na urządzeniu lub gdy sygnał opuszcza urządzenie przez port i może być obserwowany zewnętrznie.
• opóźnienie zimnego wyjścia. Czas między rozpoczęciem strumienia wyjściowego a czasem wyświetlenia pierwszej ramki na podstawie sygnatur czasowych, 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. Czas między rozpoczęciem strumienia a otrzymaniem pierwszego prawidłowego kadru, gdy system wejścia dźwięku był nieaktywny i wyłączony przed wysłaniem żądania.
• 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ść poszczególnych pomiarów wartości opóźnienia wyjścia w przypadku zimnego rozruchu;
• Jitter na zimnym wejściu. zmienność między poszczególnymi pomiarami wartości opóźnienia na zimno sygnału wejściowego;
• 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 zapewnia 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 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 audio 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 wyjścia lub przepełnieniem bufora w przypadku wejścia albo jakimkolwiek innym źródłem szumu cyfrowego lub analogowego.
• średnie odchylenie bezwzględne. Średnia wartość bezwzględna odchyleń od średniej dla zbioru wartości.
• opóźnienie od dotknięcia do wygenerowania tonu. Czas od momentu dotknięcia ekranu do momentu, w którym głośnik odtwarza wygenerowany w efekcie dotknięcia dźwięk.

Jeśli implementacje urządzeń deklarują android.hardware.audio.output, MUSZĄ spełniać te wymagania:

• [C-1-1] Sygnatura czasowa danych wyjściowych zwrócona 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ądzeniu deklarują android.hardware.audio.output, to MOCNO ZALECAMY, aby spełniały te wymagania lub je przekraczały:

• [C-SR-1] Opóźnienie wyjścia po uruchomieniu nie większe niż 100 ms na ścieżce danych głośnika. Właścicielom istniejących i nowych urządzeń z tą wersją Androida BARDZO ZALECAMY spełnienie tych wymagań. W przyszłej wersji platformy wymagamy, aby opóźnienie na wyjściu w przypadku zimnego uruchomienia nie przekraczało 200 ms.
• [C-SR-2] Opóźnienie od dotknięcia do tonu nie większe niż 80 ms.
• [C-SR-3] Zminimalizuj jitter wyjścia „na zimno”.
• [C-SR-4] Sygnatura czasowa wyjściowa zwracana przez AudioTrack.getTimestamp i AAudioStream_getTimestamp jest z dokładnością do +/- 1 ms.

Jeśli implementacje urządzeń spełniają powyższe wymagania, po początkowej kalibracji przy użyciu natywnego interfejsu API AAudio opóźnienie ciągłego wyjścia i opóźnienie wyjścia po zimnym uruchomieniu na co najmniej 1 obsługiwanym urządzeniu wyjściowym audio wynosi:

• [C-SR-5] ZALECAMY zgłaszanie dźwięku o małej latencji przez zadeklarowanie flagi funkcji android.hardware.audio.low_latency.
• [C-SR-6] ZALECAMY, aby spełnić wymagania dotyczące dźwięku o niskim opóźnieniu za pomocą interfejsu AAudio API.
• [C-SR-7] MOCNO 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 usługi AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Jeśli implementacje na urządzeniach nie spełniają wymagań dotyczących dźwięku o małej latencji za pomocą natywnego interfejsu AAudio, nie spełniają następujących 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 dźwięku:

• [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, to BARDZO ZALECAMY, aby spełniały te wymagania dotyczące dźwięku wejściowego:

• [C-SR-8] Opóźnienie w przyjmowaniu danych na zimno nieprzekraczające 100 ms na ścieżce danych mikrofonu. Właścicielom istniejących i nowych urządzeń z tą wersją Androida bardzo zalecamy spełnienie tych wymagań. W przyszłej wersji platformy wymagamy, aby opóźnienie w przypadku zimnego wejścia nie przekraczało 200 ms.
• [C-SR-9] Ciągłe opóźnienie wejścia nie większe niż 30 ms.
• [C-SR-10] Zminimalizuj jitter w przypadku zimnego wejścia.
• [C-SR-11] Ogranicz błąd w danych wejściowych (zwracanych przez AudioRecord.getTimestamp lub AAudioStream_getTimestamp) do +/- 1 ms.

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

• [C-SR-12] MOCNO ZALECAMY, aby średnia ciągła wartość opóźnienia w obie strony nie przekraczała 50 ms w 5 przypadkach pomiaru, a średnia bezwzględna odchyleń nie przekraczała 10 ms na co najmniej 1 obsługiwanej ścieżce.

5.7. Protokoły sieciowe

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

W przypadku każdego kodeka i formatu kontenera, które musi obsługiwać implementacja urządzenia:

• [C-1-1] MUSI obsługiwać ten kodek lub kontener przez HTTP i HTTPS.

• [C-1-2] MUSI obsługiwać odpowiednie formaty segmentów multimediów zgodnie z tabelą formatów segmentów multimediów poniżej w protokole HTTP Live Streaming w wersji 7.

• [C-1-3] MUSI obsługiwać odpowiednie formaty danych RTSP, jak pokazano 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.8. Kodeki audio: AAC Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.3.
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

RTSP (RTP, SDP)

Nazwa profilu	Odsyłacze	Obsługa wymaganych kodeków
H264 AVC	RFC 6184	Szczegółowe informacje o H.264 AVC znajdziesz w sekcji 5.1.8.
MP4A-LATM	RFC 6416	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.3.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Szczegółowe informacje o H.263 znajdziesz w sekcji 5.1.8.
H263-2000	RFC 4629	Szczegółowe informacje o H.263 znajdziesz w sekcji 5.1.8.
AMR	RFC 4867	Szczegółowe informacje o AMR-NB znajdziesz w sekcji 5.1.3.
AMR-WB	RFC 4867	Szczegółowe informacje o AMR-WB znajdziesz w sekcji 5.1.3.
MP4V-ES	RFC 6416	Szczegółowe informacje o MPEG-4 SP znajdziesz w sekcji 5.1.8.
mpeg4-generic	RFC 3640	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.3.
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, to:

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

Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE i obsługują protokół wyświetlania bezprzewodowego, to:

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

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

• [C-3-1] MUSI obsługiwać HDCP 1.2 lub nowszą wersję w przypadku wszystkich zewnętrznych wyświetlaczy podłączonych przez port przewodowy dostępny dla użytkownika.

5.9. MusicaI Instrument Digital Interface (MIDI)

Jeśli implementacje urządzeń 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ądzeniach 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ć nie więcej niż 20 ms i POWINNA wynosić nie więcej niż 10 ms na co najmniej jednej obsługiwanej ścieżce.
• [C-1-3] MUSI zawierać port(y) 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] Musisz spełnić wymagania dotyczące opóźnień i dźwięku USB za pomocą interfejsu API AAudio.
• [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.
• [C-SR-1] ZALECAMY, aby opóźnienie było zgodne z definicją w sekcji 5.6 Opóźnienie sygnału audio, czyli wynosiło 20 ms lub mniej w przypadku 5 pomiarów z wartością średniej bezwzględnej odchylenia mniejszą niż 5 ms na ścieżce od głośnika do mikrofonu.
• [C-SR-2] MOCNO zalecamy spełnienie wymagań dotyczących opóźnienia dźwięku w obie strony, opóźnienia wejścia i wyjścia oraz wymagań dotyczących dźwięku przez USB w ramach interfejsu API AAudio natywnej ścieżki dźwięku za pomocą ścieżki MMAP.
• [C-SR-3] ZALECAMY zapewnienie stałego poziomu wydajności procesora, gdy dźwięk jest aktywny, a obciążenie procesora się zmienia. Należy to przetestować za pomocą aplikacji na Androida SynthMark. SynthMark używa syntezatora oprogramowania działającego na 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

Aby dowiedzieć się więcej o benchmarkach, zapoznaj się z dokumentacją 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 użyteczny odsetek pełnej przepustowości procesora w wywołaniu zwrotnym.
• 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ściową a stroną wyjściową odpowiednich punktów końcowych, gdy oba są aktywne. Przykładami takich 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ść do wywołania zwrotnego 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, wywołanie zwrotne wyjścia należy wpisać tuż po wywołaniu zwrotnym wejścia, aby aplikacja miała spójne ustawienia 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 powinno wynosić mniej niż 40 ms.

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

• [C-SR-4] MOCNO ZALECAMY zgłoszenie 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] Średnie opóźnienie w obie strony nie powinno przekraczać 20 ms, jak określono w sekcji 5.6 Opóźnienie w transmisji audio, na podstawie 5 pomiary z wartością średniej odchylenia bezwzględnego poniżej 5 ms na ścieżce audio z gniazdem słuchawek.
• [C-SR-5] ZALECAMY przestrzeganie sekcji Specyfikacja urządzeń mobilnych (gniazdo) Specyfikacji przewodowych słuchawek nausznych (wersja 1.1).

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

• [C-3-1] Musisz zaimplementować klasę audio USB.
• [C-3-2] Średnia opóźnienie audio w ciągłym cyklu przesyłania i odtwarzania musi wynosić 25 ms lub mniej w przypadku 5 pomiary z średnią odchyleniem bezwzględnym poniżej 5 ms w przypadku portu w trybie hosta USB przy użyciu klasy audio USB. (Możesz to sprawdzić, używając adaptera USB-3,5 mm i dongla Audio Loopback lub interfejsu audio USB z kablowymi złączami patchowymi łączącymi wejścia z wyjściami).
• [C-SR-6] MOCNO zaleca się obsługę do 8 kanałów wejść/wyjść w każdym kierunku, częstotliwość próbkowania 96 kHz oraz głębię 24-bitową lub 32-bitową, gdy urządzenie jest używane z peryferiami audio USB, które również spełniają te wymagania.
• [C-SR-7] MOCNO zalecamy spełnienie tej grupy wymagań za pomocą natywnego interfejsu API AAudio zamiast ścieżki MMAP.

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

• W przynajmniej jednej konfiguracji NALEŻY obsługiwać wyjście stereo i 8 kanałów z głębią bitową 20- lub 24-bitową oraz częstotliwością 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 udostępniać je aplikacjom innych firm, muszą:

• [C-1-1] NALEŻY zgłaszać obsługę za pomocą właściwości android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] MUSI wykazywać w przybliżeniu płaskie właściwości amplitudy w stosunku do częstotliwości w zakresie średnich częstotliwości: dokładnie ±10 dB od 100 Hz do 7000 Hz dla każdego mikrofonu użytego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-3] NALEŻY mieć poziomy amplitudy w zakresie niskich częstotliwości: dokładnie ±20 dB od 5 do 100 Hz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.

• [C-1-4] NALEŻY mieć poziomy amplitudy w zakresie wysokich częstotliwości: ±30 dB od 7000 Hz do 22 kHz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.

• [C-1-5] 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 pełnej skali dla próbek z dokładnością zmiennoprzecinkową/podwójną) dla każdego mikrofonu użytego do nagrania 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 występować stosunek sygnału do szumu (SNR) wynoszący co najmniej 60 dB. (gdzie SNR jest mierzony jako różnica między 94 dB SPL a ekwiwalent SPL własnego szumu, zważonego A).

• [C-1-7] Musisz mieć całkowite zniekształcenie harmoniczne (THD) mniejsze niż 1% dla 1 kHz przy poziomie wejściowym 90 dB SPL w każdym mikrofonie używanym do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-8] NIE wolno stosować żadnego innego przetwarzania sygnału (np. automatycznej regulacji wzmocnienia, filtra górnoprzepustowego czy eliminacji echa) na ścieżce, oprócz mnożnika poziomu, aby doprowadzić poziom do pożądanego zakresu. Krótko mówiąc:

  • [C-1-9] Jeśli architektura z jakiegokolwiek powodu zawiera przetwarzanie sygnału, musi ono być wyłączone i nie może wprowadzać opóźnienia ani dodatkowej zwłoki na ścieżce sygnału.
  • [C-1-10] Pomnażacz poziomu, który 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 mikrofonu te wymagania dotyczą każdego mikrofonu.

Jeśli implementacje na urządzeniu 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.
• [C-SR-1] 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 oraz poleceń powłoki udostępnionych 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. Aktualizacja implementacji urządzenia z wersji Androida bez trwałego blokowania danych MOŻE być zwolniona z obowiązku przestrzegania C-0-11.
  • [C-0-3] NIE MOŻESZ zmienić formatu ani zawartości zdarzeń systemu 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ń: cmd stats polecenie powłoki i klasa interfejsu API systemu StatsManager.
    • 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. Musi istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie mostu debugowania Androida.
  • [C-0-5] MUSI obsługiwać bezpieczny interfejs ADB. Android obsługuje bezpieczne połączenia przez adb. Bezpieczny adb włącza adb na znanych uwierzytelnionych hostach.
  • [C-0-6] NALEŻY udostępnić 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 implementować adb za pomocą sieci lokalnej (np. Ethernet lub Wi-Fi).
  • [C-3-2] Musisz dostarczyć sterowniki dla Windows 7, 8 i 10, które umożliwiają deweloperom połączenie 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] Musisz mieć metodę AdbManager#isAdbWifiSupported() zwracającą 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] Musisz mieć metodę AdbManager#isAdbWifiQrSupported(), która zwraca 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, jak opisano powyżej.

• Monkey

  • [C-0-8] Musisz uwzględnić platformę Monkey i uzyskać dostęp do niej 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-1] MOCNO POLECAMY udostępnienie użytkownikowi powłoki binarnego pliku /system/bin/perfetto, którego wiersz poleceń jest zgodny z dokumentacją perfetto.
  • [C-SR-2] Zalecamy, aby binarne pliki perfetto przyjmowały jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR-3] Zalecamy, aby binarne dane wyjściowe perfetto zapisywały ścieżkę protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR-4] MOCNO ZALECAMY podanie w pliku binarnym perfetto co najmniej źródeł danych opisanych w dokumentacji perfetto.

• Low Memory Killer

  • [C-0-10] MUST write a LMK_KILL_OCCURRED_FIELD_NUMBER Atom to the statsd log when an app is terminated by the Low Memory Killer.

• Tryb jarzma testowego Jeśli implementacje urządzeń obsługują polecenie powłoki cmd testharness i uruchomienie cmd testharness enable, to:

  • [C-2-1] NALEŻY zwrócić true w przypadku 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ę Vulkan 1.0 lub nowszej za pomocą flag funkcji android.hardware.vulkan.version, to:

• [C-1-1] Musisz umożliwić deweloperowi aplikacji włączanie i wyłączanie warstw debugowania GPU.
• [C-1-2] Gdy włączone są warstwy debugowania GPU, należy wyliczyć warstwy w bibliotekach udostępnianych przez zewnętrzne narzędzia (czyli niebędące częścią platformy ani pakietu aplikacji), które znajdują się w katalogu głównym aplikacji do debugowania, aby obsługiwać metody vkEnumerateInstanceLayerProperties() i vkCreateInstance() interfejsu API.

6.2. Opcje programisty

Android zapewnia deweloperom możliwość konfigurowania ustawień związanych z rozwojem aplikacji.

Implementacje na urządzeniach MUSZĄ zapewniać spójne działanie opcji dla deweloperów. Muszą one:

• [C-0-1] MUSI obsługiwać działanie intencji 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 uruchomić po kliknięciu 7 razy opcji 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 innej firmy w porównaniu z inną, aby umożliwić korzystanie z opcji dla deweloperów. Musisz przesłać publicznie dostępny dokument lub stronę internetową z instrukcjami włączania opcji dla deweloperów. Ten dokument lub witryna MUSI być powiązany(-a) z dokumentami pakietu Android SDK.
• APLIKACJA POWINNA wyświetlać użytkownikowi stałe wizualne powiadomienie, gdy opcje dla deweloperów 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ć to API zgodnie z opisem w dokumentacji pakietu 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] Musisz podać pełne definicje klas (opisane w pakiecie SDK) interfejsów API komponentu.
• [C-0-3] Zachowanie interfejsu API MUSI być zaimplementowane w taki sposób, aby nie wymagało żadnych działań.
• [C-0-4] Metody interfejsu 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 do obsługi rozmów telefonicznych: nawet na urządzeniach innych niż telefony te interfejsy API muszą być implementowane w sposób umożliwiający ich bezpieczne wyłączenie.

7.1. Wyświetlanie i grafika

Android zawiera funkcje, które automatycznie dostosowują zasoby aplikacji i rozkłady interfejsu do urządzenia, aby aplikacje innych firm działały prawidłowo w różnych konfiguracjach sprzętowych. Na wyświetlaczach zgodnych z Androidem, na których można uruchamiać wszystkie aplikacje innych firm zgodne z Androidem, implementacje na urządzeniach MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z opisem 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 przeciwległymi narożnikami podświetlonej części wyświetlacza.
• punkty na cal (dpi). Liczba pikseli zawartych w liniowym zakresie poziomym lub pionowym 1 cal. Jeśli podano 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 piksele będzie miał 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ładu ekranu i umożliwia aplikacjom wysyłanie zapytań o rozmiar układu ekranu bieżącej konfiguracji za pomocą Configuration.screenLayout z użyciem 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 Android SDK. 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 tymi wartościami:

  • Urządzenia, dla których atrybut Configuration.uiMode ma wartość inną niż UI_MODE_TYPE_WATCH, a które zgłaszają rozmiar small dla atrybutu Configuration.screenLayout, MUSZĄ mieć wymiary co najmniej 426 dp x 320 dp.
  • Urządzenia, które podają 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 opisem w dokumentacji 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 narożniku logicznego wyświetlacza zamocujesz pole o wymiarach 15 dp na 15 dp, na ekranie będzie widoczny co najmniej 1 piksel każdego pola.

• 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 są składane lub mają 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 biblioteka Jetpack Window Manager mogła z niego korzystać.

Jeśli implementacje urządzeń zawierają zgodne z Androidem wyświetlacze, które są składane, lub zawierają składany zawias między wieloma panelami wyświetlacza, a zawias lub składanie obejmuje okno aplikacji pełnoekranowej, muszą:

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

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

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, można obliczyć na podstawie wartości wysokości i szerokości z interfejsów API view.Display i Configuration. Należy spełnić te wymagania:

• [C-0-1] W przypadku implementacji urządzenia z wartością Configuration.uiMode równąUI_MODE_TYPE_NORMAL format obrazu musi mieć wartość mniejszą lub równą 1,86 (około 16:9), chyba że aplikacja spełnia jedną z tych 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 interfejs API na poziomie 24 lub wyższym i nie deklaruje android:maxAspectRatio, który ogranicza dozwolony format obrazu.

• [C-0-3] Wdrożenia urządzenia z ustawionymi wartościami Configuration.uiModeUI_MODE_TYPE_WATCH MUSZĄ mieć ustawioną wartość formatu obrazu 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 ramki Androida wymienionych na stronie DisplayMetrics za pomocą interfejsu API DENSITY_DEVICE_STABLE. Wartość ta NIE MOŻE się zmieniać w żaden sposób. 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 rozmiar ekranu (szerokość 320 dp), implementacje urządzeń powinny zgłaszać standardową gęstość ramki Androida o jednej wartości niższą.

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-krotność natywnej gęstości lub wygenerować skutecznej minimalnej wielkości ekranu mniejszej niż 320 dp (równa się kwalifikatorowi zasobów 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ć dobrą użyteczność i spójność rozmiarów czcionek, zalecamy zastosowanie tych opcji skalowania wyświetlania natywnych (z zachowaniem podanych powyżej limitów):
  • 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, muszą:

• [C-2-1] MUSI raportować 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 and/or android.hardware.screen.landscape) and MUST report at least one supported orientation. Na przykład urządzenie z ustawionym orientacją poziomą ekranu, takie jak telewizor czy laptop, POWINNA raportować tylko android.hardware.screen.landscape.
• [C-0-2] MUST report the correct value for the device’s orientation, whenever queried via the android.content.res.Configuration.orientation, android.view.Display.getOrientation(), or other APIs.

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 oraz 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ć interfejs OpenGL ES 1.1 i 2.0 zgodnie z opisem w dokumentacji pakietu SDK Androida.
• [C-SR-1] MOCNO ZALECAMY obsługę OpenGL ES 3.1.
• NALEŻY obsługiwać OpenGL ES 3.2.

Testy OpenGL ES dEQP są podzielone na kilka list testów, z których każda ma powiązaną datę lub numer wersji. Znajdziesz je w drzewie kodu źródłowego Androida na stronie external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Urządzenie, które obsługuje OpenGL ES na poziomie zgłoszonym przez producenta, oznacza, że może przejść testy dEQP na wszystkich listach testów od tego poziomu w górę.

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 przez siebie rozszerzenia OpenGL ES. NALEŻY NIE zgłaszać ciągów znaków rozszerzenia, których nie obsługują.
• [C-2-2] MUSI obsługiwać rozszerzenia EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable i EGL_ANDROID_GLES_layers.
• [C-2-3] MUST report the maximum version of the OpenGL ES dEQP tests supported via the android.software.opengles.deqp.level feature flag.
• [C-2-4] Musi obsługiwać co najmniej wersję 132383489 (od 1 marca 2020 r.), jak podano w flagach funkcji android.software.opengles.deqp.level.
• [C-2-5] Musisz przejść wszystkie testy dEQP OpenGL ES na listach testów od wersji 132383489 do wersji określonej w opcji funkcji android.software.opengles.deqp.level w przypadku każdej obsługiwanej wersji OpenGL ES.
• [C-SR-2] ZALECAMY stosowanie 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 zazwyczaj 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.
• [C-SR-3] 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 na urządzeniach obsługują pakiet rozszerzeń Androida OpenGL ES w całości, to:

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

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

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

• [C-SR-1] ZALECAMY, aby uwzględnić obsługę 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 Vulkan dEQP są podzielone na kilka list testów, z których każda ma powiązaną 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 Vulkana na poziomie zgłoszonym przez producenta, oznacza, że może przejść testy dEQP na wszystkich listach testów od tego poziomu i wcześniejszych.

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 natywnych Vulkan vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties().
• [C-1-5] NIE MOŻESZ 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 atrybuty android:debuggable ustawione jako true.
• [C-1-6] NALEŻY podać wszystkie ciągi znaków rozszerzeń, które są obsługiwane za pomocą interfejsów API natywnych Vulkan. NALEŻY TO ZROBIĆ, jeśli nie obsługuje się poprawnie ciągów znaków rozszerzeń.
• [C-1-7] MUSI obsługiwać rozszerzenia VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain oraz 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.), jak podano w flagach funkcji android.software.vulkan.deqp.level.
• [C-1-10] Musisz przejść wszystkie testy dEQP Vulkana na listach testów między wersją 132317953 a wersją określoną w flagach funkcji android.software.vulkan.deqp.level.
• [C-1-11] NIE MOŻESZ wymieniać obsługi rozszerzeń VK_KHR_video_queue, VK_KHR_video_decode_queue ani VK_KHR_video_encode_queue.
• [C-SR-2] 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 NIE MOŻNA wymieniać żadnych wartości VkPhysicalDevice.vkEnumeratePhysicalDevices()

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

• [C-3-1] MUSI obsługiwać semantyka zewnętrznego semafora SYNC_FD oraz typy i 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 zażąda tego, ustawiając android:hardwareAccelerated="false” lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów API Androida View.
• [C-0-2] Musi działać zgodnie z dokumentacją pakietu Android SDK dotyczącą przyspieszania sprzętowego.

Android zawiera obiekt TextureView, który pozwala deweloperom bezpośrednio integrować tekstury OpenGL ES przyspieszone sprzętowo jako docelowe elementy renderowania w hierarchii interfejsu użytkownika.

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

• [C-1-1] Musisz mieć wyświetlacz z kalibracją kolorów.
• [C-1-2] Musisz mieć wyświetlacz, którego gamut całkowicie pokrywa gamut sRGB w przestrzeni CIE 1931 xyY.
• [C-1-3] Musisz mieć wyświetlacz, którego gama kolorów 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-1] 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 reżimie „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 jest to wyraźnie dozwolone w tym dokumencie.

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] Format obrazu w pikselach (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 i użycie interfejsów API dla programistów do uzyskiwania dostępu do wyświetlaczy zewnętrznych.

Jeśli implementacje urządzeń obsługują wyświetlacz zewnętrzny przez połączenie przewodowe, bezprzewodowe lub za pomocą wbudowanego dodatkowego wyświetlacza, 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 nawigować między elementami interfejsu.

7.2.1. Klawiatura

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

• [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 odpowiada żadnemu 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 sterujący, gałkę i koło jako mechanizmy nawigacji bezdotykowej.

Implementacje na urządzeniu:

• [C-0-1] Musisz 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. Implementacja open source w górnym systemie Android zawiera mechanizm wyboru odpowiedni do stosowania na urządzeniach, które nie mają niedotykowych elementów sterujących.

7.2.3. Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz, które są zwykle dostępne po naciśnięciu specjalnego przycisku fizycznego lub określonej części ekranu dotykowego, są niezbędne w ramach paradygmatu nawigacji w Androidzie, a zatem w implementacjach urządzeń:

• [C-0-1] NALEŻY zapewnić użytkownikowi możliwość uruchomienia zainstalowanych aplikacji, które mają działanie z <intent-filter> ustawionym na ACTION=MAIN oraz 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ć dostępny za pomocą jednego działania (np. kliknięcia, podwójnego kliknięcia lub gestu), gdy którykolwiek z nich jest dostępny.
• [C-1-2] NALEŻY wyraźnie wskazać, które pojedyncze działanie uruchamia każdą funkcję. Przykładami takich wskazówek są widoczna ikona na przycisku, ikona oprogramowania na pasku nawigacyjnym lub przeprowadzanie użytkownika przez szczegółowy proces konfiguracji podczas konfiguracji w trybie automatycznym.

Implementacje na urządzeniu:

• [C-SR-1] Zdecydowanie 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 czynności, gdy menu czynności nie jest puste i widoczny jest pasek czynności.
• [C-2-2] NIE wolno modyfikować pozycji wyskakującego okienka akcji wyświetlanego po kliknięciu przycisku przepełnienia w pasku akcji, ale można wyświetlić to wyskakujące okienko w zmodyfikowanej pozycji na ekranie po kliknięciu funkcji menu.

Jeśli implementacje na urządzeniach nie zapewniają funkcji menu, ze względu na zgodność wsteczną:

• [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ń zapewniają funkcję pomocy:

• [C-4-1] Funkcja pomocy musi być dostępna po wykonaniu pojedynczego działania (np. kliknięcia, podwójnego kliknięcia lub gestu), gdy inne klawisze nawigacyjne są dostępne.
• [C-SR-2] ZALECAMY mocno używanie długiego naciśnięcia przycisku ekranu głównego jako tej wyznaczonej interakcji.

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 zakłócać części ekranu dostępnej dla aplikacji.
• [C-5-2] MUSI udostępniać część ekranu 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 mieści się w maks. limicie wykluczenia określonym w dokumentacji do interfejsu View#setSystemGestureExclusionRects().
• [C-6-3] NALEŻY wysłać do aplikacji na pierwszym planie zdarzenie MotionEvent.ACTION_CANCEL, gdy dotknięcia są przechwytywane w celu wykonania gestu systemowego, jeśli wcześniej zostało wysłane zdarzenie MotionEvent.ACTION_DOWN.
• [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 obecnej orientacji.
• 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 rozpoczynają się w ramach 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 ramach bieżącej orientacji ekranu:

• [C-7-1] Funkcja nawigacji MUSI umożliwiać cofnięcie się 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 są dostępne niestandardowe panele systemowe, które można przesunąć, muszą one znajdować się w górnej 1/3 ekranu. Muszą też mieć wyraźny, trwały wizualny wskaźnik, że przesunięcie 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 panel systemowy NIE MOŻE zajmować więcej niż 1/3 krawędzi.
• [C-7-3] Jeśli w aplikacji na pierwszym planie ustawione są flagi View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, przesuwanie palcem od krawędzi ekranu MUSI działać tak, jak zostało zaimplementowane w AOSP, co jest opisane w SDK.
• [C-7-4] Jeśli w aplikacji na pierwszym planie ustawione są flagi View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, niestandardowe panele systemowe, które można przesuwać, MUSZĄ być ukryte, dopóki użytkownik nie wprowadzi lub nie rozjaśni pasków systemowych (np. 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 z fałszywym wejściem dotykowym. 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 manipulowanie obiektami.

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ń zawierają 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 rejestrować 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 trackball (czyli nie dotykasz bezpośrednio ekranu), do wprowadzania danych na głównym wyświetlaczu 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ć żadnych flag funkcji zaczynających się od android.hardware.touchscreen.
• [C-3-2] MUST report only android.hardware.faketouch.
• [C-3-3] W polu API Configuration.touchscreen MUSISZ podać wartość TOUCHSCREEN_NOTOUCH.

7.2.5. Symulowane dotykowe wprowadzanie danych

Fałszywy interfejs dotykowy zapewnia system wprowadzania danych użytkownika, który w przybliżeniu odpowiada podzbiorowi funkcji ekranu dotykowego. Na przykład mysz lub pilot, które sterują kursorem ekranowym, naśladują dotyk, ale wymagają od użytkownika najpierw wskazania lub skoncentrowania się, a następnie kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, mysz powietrzna z użyciem żyroskopu, wskaźnik z użyciem żyroskopu, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe. Android zawiera stałą funkcję android.hardware.faketouch, która odpowiada urządzeniu do wprowadzania danych niebędącemu urządzeniem dotykowym (opartym na wskaźniku), takim jak mysz lub trackpad, które może odpowiednio emulować dane wprowadzane dotykiem (w tym obsługę podstawowych gestów) i wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.

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

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

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

• [C-1-1] NALEŻY podać bezwzględne pozycje X i Y na ekranie wskaźnika oraz wyświetlić na ekranie wizualny wskaźnik.
• [C-1-2] MUST report touch event with the action code that specifies the state change that occurs on the pointer going down or up on the screen.
• [C-1-3] MUSI obsługiwać kursor w dół i w górę na obiekcie na ekranie, co umożliwia użytkownikom emulowanie kliknięcia 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 na ekranie.
• [C-1-5] Musi obsługiwać kliknięcie w dowolnym miejscu na ekranie, przesunięcie kursora do dowolnego innego miejsca na ekranie, a następnie kliknięcie kursora w górę, 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 przeniesienie 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 danych wejściowych 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 5 (śledzenie dłoni 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 HID2	Przycisk na Androida
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Przycisk w górę na padzie kierunkowym1 Przycisk w dół na padzie kierunkowym1	0x01 0x00393	AXIS_HAT_Y4
Przycisk w lewo na padzie kierunkowym1 Przycisk w prawo na padzie kierunkowym1	0x01 0x00393	AXIS_HAT_X4
Przycisk lewego uchwytu1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Przycisk na prawym uchwycie1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Kliknięcie lewej gałki1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Kliknięcie prawego drążka1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Wstecz1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Powyższe zastosowania HID muszą być zadeklarowane w ramach Gamepad CA (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 kierunkiem 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 Controls1	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 implementacje na urządzeniu obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, implementacja na urządzeniu MUSI implementować ten interfejs API zgodnie z dokumentacją pakietu Android SDK i dokumentacją na temat źródeł otwartych Androida dotyczącą czujników.

Implementacje na urządzeniu:

• [C-0-1] Musisz dokładnie podać obecność lub brak czujników w klasie android.content.pm.PackageManager.
• [C-0-2] MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() lub podobnych.
• [C-0-3] W przypadku wszystkich innych interfejsów API czujników MUSI działać w racjonalny sposób (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 na urządzeniu obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, deweloperzy:

• [C-1-1] Zgłoszenie wszystkich pomiarów czujnika musi wykorzystywać odpowiednie wartości z Międzynarodowego Systemu Jednostek (metrycznych) dla każdego typu czujnika zgodnie z definicją w dokumentacji pakietu SDK Androida.
• [C-1-2] MUST report sensor data with a maximum latency of 100 milliseconds + 2 * sample_time for the case of a sensor stream with a maximum requested latency of 0 ms when the application processor is active. 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 każdego interfejsu API oznaczonego 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 wartości sygnału czasowego między kolejnymi zdarzeniami) powinien być mniejszy niż 3%.
• [C-1-5] MUSISZ zadbać o to, aby strumień zdarzeń czujnika MUSI NIE UTRZYMYWAĆ procesora urządzenia w stanie zawieszenia ani nie aktywować go z tego stanu.
• [C-1-6] Zdarzenie musi przekazywać czas w nanosekundach zgodnie z definicją w dokumentacji Android SDK, reprezentujący czas wystąpienia zdarzenia i zsynchronizowany z zegarem SystemClock.elapsedRealtimeNano().
• [C-SR-1] Zalecamy, 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 uznać za wiarygodne udokumentowane działanie pakietu Android SDK oraz dokumentacja Androida na temat czujników w języku C.

Jeśli implementacje na urządzeniu 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 można je uzyskać na podstawie danych pochodzących z co najmniej jednego innego czujnika. (np. czujnik orientacji i czujnik przyspieszenia liniowego).

Implementacje na urządzeniu:

• NALEŻY wdrożyć te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w typach 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 do Androida Open Source dotyczącej złożonych czujników.

Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma odpowiedni interfejs API dla zewnętrznych programistów, a czujnik raportuje tylko jedną wartość, implementacje urządzeń:

• [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ądzenia zawierają określony typ czujnika, który obsługuje SensorAdditionalInfo#TYPE_VEC3_CALIBRATION, a czujnik jest udostępniany deweloperom zewnętrznym, mogą oni:

• [C-4-1] W dostarczonych danych NIE MOŻE być żadnych 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-2] 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 czujników w wszystkich możliwych stanach transformacji urządzenia.

7.3.1. Akcelerometr

Implementacje na urządzeniu:

• [C-SR-1] 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, jak określono w interfejsach API Androida.
• [C-1-4] MUSI być w stanie mierzyć przyspieszenie od swobodnego spadania do 4-krotnego przyspieszenia ziemskiego(4g) lub więcej w dowolnej osi.
• [C-1-5] Rozdzielczość musi wynosić co najmniej 12 bitów.
• [C-1-6] Musi mieć odchylenie standardowe nie większe niż 0,05 m/s2, gdzie odchylenie standardowe należy obliczyć dla każdej osi na podstawie próbek zebranych w okresie co najmniej 3 sekund przy najszybszej częstotliwości próbkowania.
• [C-SR-2] MOCNO POLECAMY wdrożenie czujnika złożonego TYPE_SIGNIFICANT_MOTION.
• [C-SR-3] ZALECAMY wdrażanie 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 SDK dla Androida.
• 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 jeden 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 w przypadku, gdy urządzenie jest w stanie dynamicznym lub stałym.

Jeśli implementacje urządzeń zawierają 3-osiowy akcelerometr i 3-osiowy żyroskop, to:

• [C-3-1] OBOWIĄZKOWO wdrożyć czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR-4] MOCNO ZALECAMY wdrożenie czujnika złożonego TYPE_GAME_ROTATION_VECTOR.

Jeśli implementacje urządzeń zawierają 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-1] 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] Musisz mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 10 Hz i powinnaś raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-3] MUSI być zgodny z systemem współrzędnych czujnika Androida, jak określono w interfejsach API Androida.
• [C-1-4] MUSI umożliwiać pomiar w zakresie od -900 µT do +900 µT na każdej osi przed nasyceniem.
• [C-1-5] WARTOŚĆ offsetu pola magnetycznego stałego żelaza MUSI być mniejsza niż 700 µT, a WARTOŚĆ offsetu pola magnetycznego stałego MUSI być 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łędu zera w przypadku układów scalonych 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 podczas produkcji urządzenia.
• [C-1-9] Odchylenie standardowe obliczone dla każdej osi na podstawie próbek zebranych w ciągu co najmniej 3 sekund przy najszybszym tempie próbkowania nie może przekraczać 1, 5 µT; ODPOWIEDNIO powinno wynosić nie więcej niż 0, 5 µT.
• [C-1-10] OBOWIĄZKOWO wdrożyć czujnik TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Jeśli implementacje urządzenia zawierają 3-osiowy magnetometr, akcelerometr i 3-osiowy żyroskop, to:

• [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ądzeń zawierają 3-osiowy magnetometr, akcelerometr i czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR, muszą:

• [C-3-1] MUSI zużywać mniej niż 10 mW.
• Powinien zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie zbiorczym przy 10 Hz.

7.3.3. GPS

Implementacje na urządzeniu:

• [C-SR-1] Zdecydowanie zalecamy dołączenie 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 lokalizacji z częstotliwością co najmniej 1 Hz, gdy są one żądane za pomocą LocationManager#requestLocationUpdate.
• [C-1-2] Musi być możliwe określenie lokalizacji w warunkach otwartego nieba (silne sygnały, pomiar HDOP < 2) w ciągu 10 sekund (szybki czas pierwszego wyznaczenia), gdy urządzenie jest połączone z internetem o szybkości co najmniej 0,5 Mb/s. Wymaganie to jest zwykle realizowane przez zastosowanie jakiejś formy wspomaganego lub przewidywanego systemu GPS/GNSS w celu zminimalizowania czasu ustalania pozycji przez GPS/GNSS (dane wspomagania obejmują czas odniesienia, lokalizację odniesienia i ephemeridy satelity/zegar).
  • [C-1-6] Po obliczeniu lokalizacji implementacje na urządzeniu 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 zostało wysłane bez połączenia danych lub po wyłączeniu i ponownie włączeniu zasilania.

• W warunkach otwartego nieba po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 1 m/s²:

  • [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 prędkość z dokładnością do 0, 5 metra na sekundę.
  • [C-1-4] MUSI jednocześnie śledzić i zgłaszać co najmniej 8 satelitów z jednego konstelacji za pomocą GnssStatus.Callback.
  • POWINIEN być w stanie śledzić jednocześnie co najmniej 24 satelity z różnych konstelacji (np. GPS + co najmniej 1 z Glonas, BeiDou, Galileo).

• [C-SR-2] MOCNO ZALECAMY, aby podczas połączenia alarmowego nadal dostarczać normalne dane o lokalizacji GPS/GNSS za pomocą interfejsu API dostawcy danych o lokalizacji GNSS.

• [C-SR-3] MOCNO zalecamy raportowanie pomiarów GNSS ze wszystkich śledzonych konstelacji (jak podano w wiadomościach GnssStatus), z wyjątkiem SBAS.

• [C-SR-4] MOCNO zaleca się raportowanie AGC i częstości pomiarów GNSS.

• [C-SR-5] MOCNO zaleca się raportowanie wszystkich szacunków dokładności (w tym kierunku, prędkości i pionu) w ramach każdej lokalizacji GPS/GNSS.

• [C-SR-6] MOCNO zalecamy zgłaszanie pomiarów GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.

• [C-SR-7] MOCNO ZALECAMY raportowanie pseudozakresów i szybkości GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, w stanie spoczynku lub przy przyspieszeniu 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-1] 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] OBOWIĄZKOWO wdrożyć czujnik TYPE_GYROSCOPE.
• [C-1-4] Rozdzielczość musi wynosić co najmniej 12 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] Musisz mieć odchylenie standardowe nie większe niż 1e-7 rad^2 / s^2 na Hz (odchylenie standardowe na Hz lub rad^2 / s). Odchylenie może się zmieniać wraz z częstotliwością próbkowania, ale MUSI być ograniczone do tej wartości. Inaczej mówiąc, jeśli zmierzymy odchylenie od średniej żyroskopu przy częstotliwości próbkowania 1 Hz, nie powinno ono przekraczać 1e-7 rad^2/s^2.
• [C-SR-2] Błąd kalibracji powinien być mniejszy niż 0,01 rad/s, gdy urządzenie jest nieruchome w temperaturze pokojowej.
• [C-SR-3] Zdecydowanie zalecamy wdrożenie czujnika TYPE_GYROSCOPE_UNCALIBRATED.
• [C-SR-4] Zalecamy, aby rozdzielczość była co najmniej 16-bitowa.
• Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.

Jeśli implementacje urządzenia zawierają 3-osiowy żyroskop, akcelerometr i magnetometr, muszą:

• [C-2-1] MUSISZ zastosować czujnik złożony TYPE_ROTATION_VECTOR.

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

• [C-3-1] OBOWIĄZKO wdroż kompozytowe czujniki TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR-5] ZALECAMY stosowanie czujnika złożonego TYPE_GAME_ROTATION_VECTOR.

7.3.5. barometr;

Implementacje na urządzeniu:

• [C-SR-1] BARDZO ZALECAMY uwzględnienie barometru (czujnika ciśnienia atmosferycznego).

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.
• [C-SR-2] ZALECAMY, aby pomiary ciśnienia były raportowane 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 na poziomie morza).

7.3.6. Thermometer

Jeśli implementacje urządzeń zawierają termometr otoczenia (czujnik temperatury), to:

• [C-1-1] MUSI definiować SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury otoczenia, a czujnik MUSI mierzyć temperaturę otoczenia (temperaturę w pomieszczeniu lub kabinie pojazdu), 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.

Jeśli implementacje urządzeń zawierają czujnik do monitorowania temperatury skóry, urządzenia te:

• [C-SR-1] ZALECAMY obsługę interfejsu API PowerManager.getThermalHeadroom.

7.3.7. Fotometr

• Implementacje urządzeń MOGĄ zawierać fotometr (czujnik jasności otoczenia).

7.3.8. Czujnik zbliżeniowy

• Urządzenia mogą być wyposażone w czujnik zbliżeniowy.

Jeśli implementacje urządzeń zawierają czujnik zbliżeniowy i przekazują tylko binarne odczyty „blisko” lub „daleko”, to:

• [C-1-1] NALEŻY mierzyć odległość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżenia MUSI być skierowany na wykrywanie obiektów w pobliżu ekranu, ponieważ jego głównym celem jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy o dowolnej 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.
• [C-1-3] W przypadku odczytu z bliska należy użyć wartości 0 cm, a w przypadku odczytu z daleka – 5 cm.
• [C-1-4] NALEŻY podać maksymalny zakres i rozdzielczość 5.

7.3.9. Czujniki o wysokiej wierności

Jeśli implementacje urządzeń zawierają zestaw czujników o wyższej jakości, jak określono w tej sekcji, i są dostępne dla aplikacji innych firm, mogą:

• [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ę, aby obsługiwał interfejs SensorDirectChannel RATE_VERY_FAST.
  • Szum pomiarowy nie może przekraczać 400 μg/√Hz.
  • NALEŻY wdrożyć 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-1] ZALECAMY, aby pasmo pomiarowe 3 dB mieściło się w ramach co najmniej 80% częstotliwości Nyquista i były ograniczone do widma szumu białego.
  • Przyspieszenie powinno być mniejsze niż 30 μg/√Hz przy testach w temperaturze pokojowej.
  • Zmiana stycznej w zależności od temperatury powinna wynosić ≤ +/- 1 mg/°C.
  • Krzywa najlepszego dopasowania powinna mieć nieliniowości ≤ 0,5%, a zmianę czułości w zależności od temperatury ≤ 0,03%/°C.
  • POWINIEN mieć czułość na osi poprzecznej mniejszą niż 2,5 % i zmienność czułości na osi poprzecznej mniejszą niż 0,2% w zakresie temperatury pracy urządzenia.

• [C-2-2] MUSI zawierać TYPE_ACCELEROMETER_UNCALIBRATED z tymi samymi wymaganiami jakościowymi 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. Zaleca się, aby obsługiwał interfejs SensorDirectChannel RATE_VERY_FAST.
  • Szum pomiarowy nie może być większy niż 0,014°/s/√Hz.
  • [C-SR-2] MOCNO zaleca się, aby pasmo pomiarowe 3 dB mieściło się w ramach co najmniej 80% częstotliwości Nyquista i by zawierało widmo szumu białego.
  • 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 oś poprzeczną powinna wynosić < 4,0%, a różnica czułości na oś poprzeczną < 0,3%.

• [C-2-4] Musisz mieć TYPE_GYROSCOPE_UNCALIBRATED spełniający 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-3] MOCNO zalecamy, aby widmo szumu białego mieściło się 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.
  • NALEŻY wdrożyć wersję tego czujnika bez funkcji budzenia 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:

  • Zużycie energii MUSI wynosić 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 zaimplementować wersję tego czujnika bez funkcji budzenia z możliwością buforowania co najmniej 100 zdarzeń czujnika.
  • Zużycie energii MUSI wynosić 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:

  • Zużycie energii MUSI wynosić nie więcej niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.

• [C-2-12] MUSI zawierać czujnik TILT_DETECTOR, który:

  • Zużycie energii MUSI wynosić nie więcej 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 się mieścić w 2, 5 ms. Sygnatura czasowa zdarzenia fizycznego zarejestrowanego przez akcelerometr i żyroskop POWINNA różnić się od siebie o nie więcej niż 0,25 ms.

• [C-2-14] sygnatury czasowe zdarzeń czujnika żyroskopu MUSZĄ być podawane w tym samym systemie czasowym co sygnatury czasowe zdarzeń z podsystemu 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 w dowolnym z wymienionych powyżej czujników fizycznych, do aplikacji.

• [C-2-16] NIE MOŻE zużywać więcej niż 0,5 mW, gdy urządzenie jest nieruchome, i 2,0 mW, gdy urządzenie się porusza, gdy włączona jest dowolna kombinacja tych czujników:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] MOŻE mieć czujnik TYPE_PROXIMITY, ale jeśli jest obecny, MUSI mieć minimalną pojemność bufora wynoszącą 100 zdarzeń czujnika.

Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje ona zużycie energii przez cały łańcuch czujników, czyli 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] MUSISZ poprawnie zadeklarować obsługę typów kanałów bezpośrednich i poziom stawek raportowania bezpośredniego za pomocą interfejsu API isDirectChannelTypeSupported i getHighestDirectReportRateLevel.
• [C-3-2] Musi obsługiwać co najmniej 1 z 2 typów kanału bezpośredniego czujnika dla wszystkich czujników, które deklarują obsługę kanału bezpośredniego czujnika.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• Powinien obsługiwać raportowanie zdarzeń przez kanał bezpośredni czujnika w przypadku głównego czujnika (wersja bez funkcji budzenia) tych typów:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Czujniki biometryczne

Więcej informacji o pomiarach bezpieczeństwa odblokowywania biometrycznego znajdziesz w dokumentacji Pomiar bezpieczeństwa biometrycznego.

Jeśli implementacje urządzeń obejmują zabezpieczony ekran blokady, muszą:

• NALEŻY użyć czujnika biometrycznego

Sensory biometryczne można zaklasyfikować jako klasy 3 (dawniej silne), klasy 2 (dawniej słabe) lub klasy 1 (dawniej wygodne) na podstawie współczynników akceptacji fałszywych danych i podwójnych kont oraz bezpieczeństwa łańcucha przetwarzania danych biometrycznych. Ta klasyfikacja określa możliwości interfejsu czujnika biometrycznego w połączeniu z platformą i aplikacjami innych firm. Sensory są domyślnie klasyfikowane jako klasa 1 i muszą spełniać dodatkowe wymagania opisane poniżej, jeśli mają być klasyfikowane jako klasa 2 lub klasa 3. Zarówno klasa 2, jak i klasa 3 biometrii zyskują dodatkowe możliwości, opisane poniżej.

Jeśli implementacje urządzeń udostępniają czujnik biometryczny aplikacjom innych firm za pomocą 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 przestrzegać nazwy każdego parametru zdefiniowanego jako stała w klasie Authenticators oraz wszystkich jej kombinacji. Z drugiej strony NIE MOŻESZ uwzględniać 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 w dowolnych ich kombinacjach.
• [C-4-3] NA URZĄDZENIACH Z TECHNIKAMI IDENTYFIKACJI BIOEMETRYCZNEJ Klasa 3 LUB Klasa 2 NALEŻY WDROŻYĆ DZIAŁANIE ACTION_BIOMETRIC_ENROLL. To działanie MUSI zawierać tylko punkty rejestracji dla klasy 3 lub klasy 2 danych biometrycznych.

Jeśli implementacje urządzeń obsługują biometryczne dane biometryczne, muszą:

• [C-5-1] Domyślnie należy wymagać dodatkowego potwierdzenia (np. naciśnięcia przycisku).
• [C-SR-1] ZALECAMY, aby umożliwić użytkownikom zastąpienie ustawień aplikacji i wymaganie potwierdzenia.
• [C-SR-2] MOCNO POLECAMY zabezpieczenie działania potwierdzenia w taki sposób, aby nie można było go sfałszować w systemie operacyjnym lub jądrze. 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) 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 kroku potwierdzenia) odpowiadający parametrowi setConfirmationRequired(boolean), który aplikacje mogą wykorzystywać w procesach logowania.

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

• [C-SR-3] MOCNO zalecamy, 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 czujnik twarzy, wywołanie onAuthenticationSucceeded powinno być wysyłane po potwierdzeniu dowolnego z nich).

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 tym paragrafie 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] NALEŻY poinformować, że ten tryb może być mniej bezpieczny niż silny kod PIN, wzór lub hasło, oraz wyraźnie wymienić zagrożenia związane z jego włączeniem, jeśli wskaźniki akceptacji podszycia się pod inną osobę i podstępnej podmiany danych przekraczają 7% zgodnie z protokołami testów danych biometrycznych na Androidzie.
• [C-1-9] NALEŻY poprosić użytkownika o polecenie użycia zalecanej metody uwierzytelniania głównego (np.kodu PIN, wzoru lub hasła) po maksymalnie 20 nieudanych prób i nie mniej niż 90 sekundach od zakończenia weryfikacji biometrycznej. Nieudana próba to próba o odpowiedniej jakości (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.
• [C-SR-4] MOCNO POLECAMY zmniejszenie łącznej liczby prób fałszywych w przypadku weryfikacji biometrycznej określonej w [C-1-9], jeśli wskaźniki akceptacji próby oszustwa i podszycia się pod inną osobę są wyższe niż 7%, zgodnie z protokołami testów biometrycznych Androida.
• [C-1-3] NALEŻY ograniczyć liczbę prób weryfikacji biometrycznej – próba fałszywa to próba o odpowiedniej jakości obrazu (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.
• [C-SR-5] Zdecydowanie zalecamy ograniczenie liczby prób do 30 sekund po 5 nieudanych próbach weryfikacji biometrycznej (maksymalna liczba nieudanych prób zgodnie z [C-1-9]) – gdzie nieudana próba to próba z odpowiednim jakością uchwycenia (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.
• [C-SR-6] MOCNO zalecamy, aby cała logika ograniczania szybkości znajdowała się w TEE.
• [C-1-10] NALEŻY wyłączyć uwierzytelnianie biometryczne po tym, jak zostało uruchomione uwierzytelnianie zapasowe zgodnie z opisem w sekcji 9.11 w [C-0-2].
• [C-1-4] NALEŻY uniemożliwić dodawanie nowych danych biometrycznych bez uprzedniego ustanowienia łańcucha zaufania, prosząc użytkownika o potwierdzenie istniejącego lub dodanie nowego elementu danych (kod PIN, wzór lub hasło) zabezpieczonego przez TEE. W ramach implementacji projektu Android Open Source Project 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 przywracając ustawienia fabryczne).
• [C-1-6] MUSI obsługiwać indywidualną flagę dla danego elementu biometrycznego (np. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE lub DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] NALEŻY poprosić użytkownika o podanie danych do zalecanego głównego uwierzytelnienia (np. kodu PIN, wzoru lub hasła): a) raz na 24 godziny lub rzadziej w przypadku urządzeń z Androidem w wersji 9 lub nowszej albo b) raz na 72 godziny lub rzadziej w przypadku urządzeń z Androidem w wersji 8 lub starszej.

• [C-1-8] NALEŻY poprosić użytkownika o przeprowadzenie zalecanego procesu uwierzytelniania podstawowego (np. za pomocą kodu PIN, wzoru, hasła) lub uwierzytelniania biometrycznego klasy 3 (mocnego) po wykonaniu jednej z tych czynności:

  • 4-godzinny limit czasu nieaktywności LUB

  • 3 nieudane próby uwierzytelnienia biometrycznego.

• [C-SR-7] W przypadku nowych urządzeń MOCNO POLECAMY używanie logiki w ramach udostępnionych przez projekt Android Open Source, aby narzucić ograniczenia określone w [C-1-7] i [C-1-8].

• [C-SR-8] ZALECAMY, aby odsetek błędów odrzucenia na poziomie poniżej 10% był mierzony na urządzeniu.

• [C-SR-9] W przypadku każdej zarejestrowanej metody biometrycznej BARDZO ZALECAMY, aby opóźnienie było krótsze niż 1 sekunda, 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] Proporcja przypadków oszustwa i podszycia się pod kogoś nie może być wyższa niż 20%, mierzona zgodnie z protokołami testów biometrycznych na Androidzie.
• [C-2-3] MUSI wykonywać dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza przestrzenią użytkownika lub jądrem 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 wykonawczym. Dotyczy to również chipa z bezpiecznym kanałem do izolowanego środowiska wykonawczego zgodnie z opisem w wytycznych dotyczących implementacji na stronie projektu Android Open Source.
• [C-2-5] W przypadku uwierzytelniania lub rejestracji na podstawie danych biometrycznych z kamery:
  • Musisz obsługiwać kamerę w taki sposób, aby uniemożliwić odczyt lub zmianę jej klatek poza odizolowanym środowiskiem wykonywania lub za pomocą układu z bezpiecznym kanałem do odizolowanego środowiska wykonywania.
  • W przypadku rozwiązań z jedną kamerą RGB ramki obrazu mogą być odczytywalne poza izolowanym środowiskiem wykonania w celu obsługi operacji takich jak podgląd do 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. Urządzenia z Androidem w wersji 9 lub starszej nie są zwolnione z obowiązku przestrzegania zasad C-2-7.

• [C-2-8] Musisz mieć bezpieczny kanał przetwarzania, który uniemożliwia wstrzyknięcie danych bezpośrednio do systemu operacyjnego lub jądra w celu fałszywego uwierzytelnienia jako użytkownik.

• [C-SR-10] MOCNO zalecamy uwzględnienie wykrywania żywotności we wszystkich trybach biometrycznych oraz wykrywania uwagi w przypadku biometryki twarzy.

• [C-2-9] NALEŻY udostępnić czujnik biometryczny aplikacjom innych firm.

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 opisane powyżej, z wyjątkiem wymagań [C-1-7] i [C-1-8].
• [C-3-2] Musisz zaimplementować magazyn kluczy wspierany sprzętowo.
• [C-3-3] Wskaźnik akceptacji podszycia się pod kogoś innego i podstępnego oszustwa NIE MOŻE przekraczać 7%, mierzony zgodnie z protokołami testów biometrycznych Androida.
• [C-3-4] NALEŻY wymagać od użytkownika podania rekomendowanego głównego uwierzytelnienia (np. kodu PIN, wzoru lub hasła) co 72 godziny lub krócej.
• [C-3-5] NALEŻY ponownie wygenerować identyfikator uwierzytelniania dla wszystkich funkcji biometrycznych klasy 3 obsługiwanych na urządzeniu, jeśli którakolwiek z nich zostanie ponownie zarejestrowana.
• [C-3-6] Klucze w sklepie kluczy muszą być obsługiwane przez aplikacje za pomocą danych biometrycznych.

Jeśli implementacje urządzeń zawierają czytnik linii papilarnych pod wyświetlaczem (UDFPS), powinny:

• [C-SR-11] ZDECYDOWANIE zalecamy, aby obszar dotykowy UDFPS nie kolidował z sterowaniem za pomocą 3 przycisków (którego niektórzy użytkownicy mogą wymagać ze względu na ułatwienia dostępu).

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° (włącznie, tzn. w tym 0 i 360°).
• [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” w rozumieniu interfejsów API Androida i tego dokumentu odnosi się konkretnie do sprzętu związanego z nawiązywaniem połączeń głosowych i wysyłaniem SMS-ów przez sieć GSM lub CDMA. Podczas gdy te połączenia głosowe mogą być przełączane pakietowo, w przypadku Androida są one traktowane niezależnie od wszelkich połączeń danych, które mogą być wdrażane za pomocą tej samej sieci. Innymi słowy, funkcje i interfejsy API dotyczące „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 przesyłania 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.
• POWINNA zezwalać na wszystkie dostępne typy usług komórkowych (2G, 3G, 4G, 5G itd.) podczas połączeń alarmowych (niezależnie od typów sieci ustawionych przez SetAllowedNetworkTypeBitmap()).

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żony mechanizm udostępniający funkcje eSIM deweloperom zewnętrznym, to:

• [C-3-1] Musisz wdrożyć EuiccManager API.

Jeśli implementacje urządzeń nie ustawiają właściwości systemowej ro.telephony.iwlan\_operation\_mode na „legacy”, to:

• [C-4-1] NIE MOŻESZ zwracać wartości „NETWORK_TYPE_IWLAN” za pomocą metody NetworkRegistrationInfo#getAccessNetworkTechnology(), gdy NetworkRegistrationInfo#getTransportType() zwraca wartość „TRANSPORT_TYPE_WWAN” dla tej samej instancji NetworkRegistrationInfo.

Jeśli implementacje urządzeń obsługują rejestrację w ramach pojedynczego IP Multimedia Subsystem (IMS) dla funkcji multimedialnej usługi telefonicznej (MMTEL) i usług RCS oraz muszą spełniać wymagania operatora komórkowego dotyczące używania pojedynczej rejestracji IMS dla całego ruchu sygnalizacyjnego IMS, to:

• [C-5-1] NALEŻY zadeklarować flagę funkcji android.hardware.telephony.ims i zapewnić pełną implementację interfejsu ImsService API zarówno w przypadku MMTEL, jak i interfejsu User Capability Exchange API.
• [C-5-2] NALEŻY zadeklarować flagę funkcji android.hardware.telephony.ims.singlereg i zapewnić pełną implementację interfejsu SipTransport API, interfejsu GbaService API, dedykowanych wskazań biernego za pomocą interfejsu IRadio 1.6 HAL oraz obsługi Provisioning za pomocą serwera Auto Configuration Server (ACS) lub innego zastrzeżonego mechanizmu obsługi Provisioning za pomocą interfejsu IMS Configuration 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 interfejsie „BlockedNumberProvider” bez interakcji z aplikacją. Jedynym wyjątkiem jest tymczasowe odblokowanie numeru zgodnie z opisem w dokumentacji interfejsu SDK.
• [C-1-4] W przypadku zablokowanego połączenia NIE MOŻESZ zapisywać danych w rejestrach połączeń na platformie.
• [C-1-5] NIE NALEŻY wysyłać wiadomości do dostawcy usług telefonicznych, jeśli została ona zablokowana.
• [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 wolno 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, które są pojedynczą instancją 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 respektowana.
• 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 zapewnić użytkownikowi możliwość zaakceptowania lub odrzucenia 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 za pomocą CAPABILITY_SUPPORT_HOLD.
• [C-1-3] Aplikacja MUSI implementować interfejs InCallService.

• [C-SR-1] MOCNO zaleca się powiadomienie użytkownika, że odebranie przychodzącego połączenia spowoduje przerwanie bieżą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-1] 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 PhoneAccount na true.EXTRA_LOG_SELF_MANAGED_CALLS

• [C-SR-2] ZALECAMY, aby obsłużyć zdarzenia KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK interfejsu API android.telecom w przypadku słuchawek na tle:

  • Rozpocznij połączenie Connection.onDisconnect(), gdy podczas trwającego połączenia zostanie wykryte krótkie naciśnięcie klawisza.
  • Wywołanie Connection.onAnswer(), gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia.
  • 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ą te funkcje aplikacji innej firmy, 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 getActiveNetwork i registerDefaultNetworkCallback. Innymi słowy, mogą wyłączyć dostęp do internetu, który jest zapewniany przez innego dostawcę sieci (np. dane mobilne), tylko wtedy, gdy potwierdzą, że sieć Wi-Fi zapewnia dostęp do internetu.
• [C-1-6] W przypadku wywołania metody interfejsu API ConnectivityManager.reportNetworkConnectivity() ZALECAMY ponowną ocenę dostępu do Internetu na urządzeniu Network.Jeśli okaże się, że obecne Network nie zapewnia już dostępu do Internetu, należy przejść na inną dostępną sieć (np. dane mobilne), która zapewnia dostęp do Internetu.
• [C-1-7] NALEŻY losowo zmienić źródłowy adres MAC i numer sekwencji ramek żądań sondy, raz na początku każdego skanowania, gdy STA jest rozłączony.
• [C-1-8] NALEŻY używać jednego stałego adresu MAC (NIE NALEŻY losować adresu MAC w połowie skanowania).
• [C-1-9] NALEŻY iterować numer sekwencji żądania sondowania w normalny sposób (sekwencyjnie) między żądaniami sondowania w skanowaniu.
• [C-1-10] MUSI losowo generować numer porządkowy żądania sondowania między ostatnim żądaniem sondowania w ramach skanowania a pierwszym żądaniem sondowania w ramach kolejnego skanowania.
• [C-SR-1] MOCNO zaleca się losowanie źródłowego adresu MAC używanego do komunikacji STA z punktem dostępu (AP) podczas tworzenia i powiązania.
  • Urządzenie MUSI używać innego losowego adresu MAC dla każdego SSID (FQDN dla Passpoint), z którym się komunikuje.
  • Urządzenie MUSI oferować użytkownikowi opcję kontrolowania losowania na podstawie identyfikatora SSID (FQDN dla Passpoint) z opcjami losowania i nielosowania oraz MUSI ustawić domyślny tryb dla nowych konfiguracji Wi-Fi, aby losowanie było możliwe.
• [C-SR-2] Zdecydowanie zalecamy używanie losowego identyfikatora BSSID dla dowolnego punktu dostępu utworzonego przez użytkownika.
  • Adres MAC MUSI być zrandomizowany i zachowywany w przypadku każdego SSID używanego przez AP.
  • URZĄDZENIE MOŻE umożliwiać użytkownikowi wyłączenie tej funkcji. Jeśli taka opcja jest dostępna, losowanie MUSI być domyślnie włączone.

Jeśli implementacje urządzeń obejmują obsługę trybu oszczędzania energii Wi-Fi zgodnie ze standardem IEEE 802.11, urządzenia te:

• 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().
• [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-3] ZALECAMY zminimalizowanie opóźnień w transmisji Wi-Fi za każdym razem, gdy zostanie uzyskany i zacznie obowiązywać blokada opóźnienia niskiego poziomu (WIFI_MODE_FULL_LOW_LATENCY).

Jeśli implementacje urządzeń obsługują Wi-Fi i korzystają z niego do skanowania lokalizacji, to:

• [C-2-1] NALEŻY zapewnić użytkownikowi możliwość włączenia lub wyłączenia odczytu wartości 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.
• [C-SR-1] MOCNO zaleca się losowanie adresu MAC źródła w przypadku wszystkich nowo utworzonych połączeń Wi-Fi Direct.

7.4.2.2. Konfiguracja połączenia bezpośredniego z tunelowaniem Wi-Fi

Implementacje na urządzeniu:

• POWINIEN zawierać obsługę konfiguracji tunelowanej bezpośredniej łączności Wi-Fi (TDLS) zgodnie z dokumentacją pakietu Android SDK.

Jeśli implementacje urządzeń obejmują obsługę 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 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 oraz udostępniają te funkcje aplikacjom innych firm, muszą:

• [C-2-1] NALEŻY zaimplementować interfejsy API wykrywania z uwzględnieniem lokalizacji: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm oraz 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).
• [C-1-4] Należy zadeklarować flagę funkcji android.hardware.wifi.passpoint.
• [C-1-5] W celu wykrywania, dopasowywania i kojarzenia z sieciami Passpoint należy stosować implementację AOSP.
• [C-1-6] MUSI obsługiwać co najmniej ten podzbiór protokołów wdrożeniowych urządzeń zdefiniowanych w specyfikacji Wi-Fi Alliance Passpoint R2: uwierzytelnianie EAP-TTLS i SOAP-XML.
• [C-1-7] NALEŻY przetwarzać certyfikat serwera AAA zgodnie ze specyfikacją Hotspot 2.0 R3.
• [C-1-8] MUSI obsługiwać kontrolę użytkownika nad wdrożeniem za pomocą selektora Wi-Fi.
• [C-1-9] Konfiguracje Passpoint MUSZĄ być trwałe po ponownym uruchomieniu.
• [C-SR-1] MOCNO zalecamy dodanie funkcji akceptowania warunków.
• [C-SR-2] MOCNO POLECAMY obsługę funkcji informacji o miejscu.

Jeśli implementacje urządzeń nie obsługują Wi-Fi Passpoint:

• [C-2-1] Implementacja interfejsów API WifiManager związanych z Passpoint MUSI zgłaszać błąd UnsupportedOperationException.

Jeśli udostępniono globalny przełącznik kontroli użytkownika do wyłączania Passpoint, implementacje:

• [C-3-1] Domyślnie musi być włączony Passpoint.

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 punktami dostępu.
• [C-1-4] MUSI być dokładny w zakresie 2 metrów przy szerokości pasma 80 MHz w 68. procentylu (obliczonym za pomocą funkcji rozkładu kumulatywnego).

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ą przenoszenie funkcji 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 sloty utrzymywania połączenia przez Wi-Fi oraz co najmniej 1 slot utrzymywania połączenia przez sieć komórkową.

Jeśli implementacje urządzeń nie obsługują przenoszenia funkcji utrzymania połączenia Wi-Fi, urządzenia te:

• [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ą ją aplikacjom innych firm, muszą:

• [C-1-1] Metoda WifiManager#isEasyConnectSupported() MUSI zwracać wartość true.

7.4.2.8. Weryfikacja certyfikatu serwera sieci Wi-Fi w firmie

Jeśli certyfikat serwera Wi-Fi nie został zweryfikowany lub nazwa domeny serwera Wi-Fi nie została ustawiona, implementacje urządzenia:

• [C-SR-1] ZALECAMY, aby nie udostępniać użytkownikowi opcji ręcznego dodawania sieci Wi-Fi dla firm w aplikacji Ustawienia.

7.4.3. Bluetooth

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

• NALEŻY 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, to:

• [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 zależności od 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 (profil ogólny atrybutów) zgodnie z dokumentacją pakietu SDK i android.bluetooth.
• [C-3-3] NALEŻY podać prawidłową wartość parametru BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy zaimplementowano logikę filtrowania dla klas interfejsu API ScanFilter.
• [C-3-4] MUST report the correct value for BluetoothAdapter.isMultipleAdvertisementSupported() to indicate whether Low Energy Advertising is supported.
• [C-3-5] NALEŻY wdrożyć limit czasu adresu prywatnego do rozwiązywania (RPA) nieprzekraczający 15 minut i zmieniać adres po upływie tego czasu, aby chronić prywatność użytkownika, gdy urządzenie aktywnie korzysta z BLE do skanowania lub reklamowania. Aby zapobiec atakom czasowym, interwały limitu czasu muszą być losowe i mieć od 5 do 15 minut.
• NALEŻY obsługiwać przenoszenie logiki filtrowania na układ Bluetooth, gdy wdrażasz interfejs 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 odczytywanej za pomocą interfejsu System API BluetoothAdapter.isBleScanAlwaysAvailable().

Jeśli implementacje urządzeń obejmują obsługę Bluetooth LE i profilu aparatów słuchowych, jak opisano w artykule Obsługa aparatów słuchowych za pomocą Bluetooth LE, to:

• [C-5-1] W funkcji BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) musi zostać zwrócona wartość true.

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

• [C-6-1] NALEŻY ograniczyć dostęp do metadanych Bluetooth (takich jak wyniki skanowania), które mogą posłużyć do określenia lokalizacji urządzenia, chyba że aplikacja przesyłająca żądanie przeszła pomyślnie weryfikację uprawnień android.permission.ACCESS_FINE_LOCATION na podstawie bieżącego stanu (pierwszego lub tła).

Jeśli implementacje na urządzeniu obejmują obsługę Bluetootha lub Bluetootha Low Energy, a w pliku manifestu aplikacji nie ma deklaracji dewelopera, która potwierdza, że nie uzyskuje on lokalizacji z Bluetootha:

• [C-6-2] NALEŻY zablokować dostęp do Bluetootha za pomocą android.permission.ACCESS_FINE_LOCATION.

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] NALEŻY zaimplementować interfejsy API android.nfc.NdefMessage i android.nfc.NdefRecord, nawet jeśli nie obsługują one 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)

• [C-SR-1] MOCNO ZALECANA obsługa odczytu i zapisu komunikatów NDEF, a także 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 być w stanie odczytać kod kreskowy i adres URL (jeśli jest zakodowany) 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ń obejmują 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 w przypadku 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ólne obsługiwanie NFC zgodnie z opisem w tej sekcji i obsługują technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF na MIFARE Classic) w roli czytnika/nagrywarki, to:

• [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 widoczna 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 kbit/s. 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 standardu bezprzewodowej transmisji danych, takiego jak 802.11 (Wi-Fi), gdy podstawowym połączeniem danych jest standard fizyczny sieci (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 AF_INET6sockets.
• [C-0-3] Protokół IPv6 MUSI być domyślnie włączony.
  • NALEŻY 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średnie połączenie IPv6 z siecią, gdy urządzenie jest połączone z siecią IPv6, bez żadnej formy tłumaczenia adresów lub portów 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óry jest faktycznie używany do wysyłania i odbierania pakietów w sieci, oraz być widoczne jako adres IP źródłowy i port serwerów internetowych.

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 w sieci komórkowej w protokole IPv6 (tylko IPv6 lub ewentualnie w stosie podwójnym).

Jeśli implementacje urządzeń obsługują więcej niż jeden typ sieci (np. Wi-Fi i komórkowej transmisji danych), 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ększą liczbą typów sieci.

7.4.5.3. Portale przechwytujące

Portal przechwytujący to sieć, która wymaga zalogowania się w celu uzyskania dostępu do internetu.

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

• [C-1-1] Musisz udostępnić aplikację portalu ograniczonego, która będzie obsługiwać intencję ACTION_CAPTIVE_PORTAL_SIGN_IN i wyświetlać stronę logowania portalu ograniczonego, wysyłając tę intencję w ramach wywołania interfejsu System API ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] Musi wykrywać portale przechwytujące i obsługiwać logowanie za pomocą aplikacji portalu przechwytującego, gdy urządzenie jest połączone z dowolnym typem sieci, w tym siecią komórkową, Wi-Fi, Ethernet lub Bluetooth.
• [C-1-3] MUSI obsługiwać logowanie na portalach uwięzionych przy użyciu DNS w formie zwykłego tekstu, gdy urządzenie jest skonfigurowane do używania prywatnego DNS w trybie ścisłym.
• [C-1-4] W przypadku android.net.LinkProperties.getPrivateDnsServerName i android.net.LinkProperties.isPrivateDnsActive należy używać szyfrowanego DNS zgodnie z dokumentacją pakietu SDK. Dotyczy to całego ruchu w sieci, który nie komunikuje się bezpośrednio z portalem ograniczonym.
• [C-1-5] NALEŻY zadbać o to, aby podczas logowania się użytkownika w 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 autosynchronizacji MUSI być domyślnie włączone, aby metoda getMasterSyncAutomatically() zwracała wartość „true”.

7.4.7. Oszczędzanie danych

Jeśli implementacje urządzeń obejmują połączenie z licznikiem, są:

• [C-SR-1] ZALECAMY zaimplementowanie trybu oszczędzania danych.

Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych, muszą:

• [C-1-1] Musi obsługiwać wszystkie interfejsy API w klasie 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] Musi zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED dla ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NIE MOŻNA nadawać ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Bezpieczne elementy

Jeśli implementacje urządzeń obsługują interfejs Open Mobile API i zabezpieczone elementy, udostępniając je aplikacjom innych firm, mogą:

• [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ć poprawne flagi funkcji za pomocą android.hardware.se.omapi.uicc w przypadku urządzenia z elementami zabezpieczeń opartymi na UICC, android.hardware.se.omapi.ese w przypadku urządzenia z elementami zabezpieczeń opartymi na eSE i android.hardware.se.omapi.sd w przypadku urządzenia z elementami zabezpieczeń opartymi na 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 na potrzeby podstawowego podglądu i robienia zdjęć.
• [C-1-3] NALEŻY zadbać o to, aby wstępnie zainstalowana domyślna aplikacja do obsługi aparatu (z intencją MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE lub MediaStore.ACTION_VIDEO_CAPTURE) odpowiadała za usunięcie lokalizacji użytkownika z metadanych obrazu przed wysłaniem go do aplikacji odbiorczej, jeśli ta nie ma uprawnień 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] MUSISZ zgłosić flagę funkcji android.hardware.camera i android.hardware.camera.any.
• [C-1-2] Rozdzielczość musi wynosić co najmniej 2 Mpix.
• W sterowniku aparatu (niewidocznym dla oprogramowania aplikacji) powinien być zaimplementowany automatyczny autofokus sprzętowy lub automatyczny autofokus oprogramowania.
• 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 w urządzeniu, ale tylko aplikacji innych firm korzystających z Camera.PreviewCallback.

7.5.2. Przedni aparat

Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz. Jest to kamera zwykle używana 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] MUSISZ zgłosić flagę funkcji android.hardware.camera.any i 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 aparatu w interfejsie 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 aparatu MUSI być odbiciem lustrzanym w orientacji określonej przez aplikację, gdy aplikacja wyraźnie poprosiła o obrócenie wyświetlacza aparatu za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation(). Odwrotnie, 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 lustrować końcowego obrazu nieruchomego ani strumieni wideo z powrotem do aplikacji lub do pamięci masowej.
• [C-1-6] Obraz wyświetlany przez postview MUSI być odbiciem lustrzanym strumienia obrazu z podglądu kamery.
• MOŻE zawierać funkcje (takie jak autofokus, lampa błyskowa itp.) dostępne dla tylnych kamer zgodnie z opisem w sekcji 7.5.1.

Jeśli implementacje urządzeń 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 aparacie MUSI być odbiciem poziomym względem bieżącego ustawienia urządzenia.

7.5.3. Kamera zewnętrzna

Implementacje na urządzeniu:

• MOŻE obsługiwać kamerę zewnętrzną, która nie musi być stale 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 zewnętrzna kamera łączy się przez port hosta USB.
• [C-1-3] Należy przejść testy CTS aparatu z podłączonym zewnętrznym aparatem. Szczegółowe informacje o testach CTS aparatu są dostępne na stronie source.android.com.
• POWINNA 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ń niekodowany / 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ącej ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, redukcji szumów, wyostrzania itp.

Starszy pakiet interfejsu API (android.hardware.Camera) został oznaczony jako przestarzały w Androidzie 5.0, ale nadal powinien być 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 kamerą we wszystkich dostępnych kamerach. Implementacje na urządzeniu:

• [C-0-1] DO stosowania w przypadku danych podglądu przekazywanych do wywołań zwrotnych aplikacji, gdy aplikacja nigdy nie wywołała funkcji android.hardware.Camera.Parameters.setPreviewFormat(int).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 obu kamer (przedniej i tylnej) 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 android.media.ImageReader API na urządzeniach android.hardware.camera2, które reklamują REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLEw android.request.availableCapabilities.
• [C-0-5] NALEŻY nadal wdrożyć pełne Camera API zawarte w dokumentacji pakietu Android SDK, niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład aparaty, które nie mają autofokusa, MUSZĄ wywoływać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback (nawet jeśli nie mają 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(), które nie są opisane jako stałe w interfejsie android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry kamery, jeśli sprzęt na to pozwala, i NIE MOGĄ obsługiwać niestandardowych typów parametrów kamery. Na przykład implementacje urządzeń, które obsługują rejestrowanie obrazu za pomocą technik obrazowania o wysokim zakresie dynamicznym (HDR), MUSZĄ obsługiwać parametr kamery Camera.SCENE_MODE_HDR.
• [C-0-7] NALEŻY podać odpowiedni poziom obsługi za pomocą właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i podać odpowiednie flagi funkcji frameworka.
• [C-0-8] NALEŻY również zadeklarować poszczególne funkcje kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities oraz zadeklarować odpowiednie flagi funkcji. NALEŻY zdefiniować flagę funkcji, jeśli którekolwiek z podłączonych kamer obsługuje tę funkcję.
• [C-0-9] MUSI przesyłać intencję Camera.ACTION_NEW_PICTUREza każdym razem, gdy aparat zrobi nowe zdjęcie i jego wpis zostanie dodany do magazynu multimediów.
• [C-0-10] NALEŻY przesyłać Camera.ACTION_NEW_VIDEO intencję za każdym razem, gdy kamera nagra nowy film, a zdjęcie zostanie dodane do magazynu multimediów.
• [C-0-11] Wszystkie kamery muszą być dostępne za pomocą przestarzałego interfejsu API android.hardware.Camera oraz interfejsu API android.hardware.camera2.
• [C-0-12] NALEŻY zadbać o to, aby wygląd twarzy NIE był zmieniany, w tym nie ograniczając się do zmiany geometrii twarzy, odcienia skóry twarzy lub wygładzania skóry twarzy w żadnym interfejsie android.hardware.camera2 lub android.hardware.Camera.
• [C-SR-1] W przypadku urządzeń z większą liczbą kamer RGB skierowanych w ten sam kierunek MOCNO zalecamy obsługę urządzenia logicznego z kamerą, które zawiera informacje o możliwościachCameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, w którym wszystkie kamery RGB są skierowane w ten sam kierunek jako fizyczne podurządzenia.

Jeśli implementacje na urządzeniach udostępniają firmom zewnętrznym zastrzeżony interfejs API aparatu, to:

• [C-1-1] NALEŻY zaimplementować taki interfejs API aparatu za pomocą interfejsu API android.hardware.camera2.
• MOŻE udostępniać tagi dostawcy lub rozszerzenia do interfejsu android.hardware.camera2API.

7.5.5. Orientacja aparatu

Jeśli implementacje urządzeń mają przednie lub tylne kamery:

• [C-1-1] Musi być ustawiony 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 wszystkich urządzeń niezależnie od ich naturalnej orientacji, czyli zarówno urządzeń z główną orientacją poziomą, jak i urządzeń z główną orientacją pionową.

Powyższe wymagania nie dotyczą urządzeń, które spełniają wszystkie te kryteria:

• Urządzenie ma ekrany o zmiennej geometrii, takie jak składane lub składane na zawiasach.
• Gdy zmienia się stan zawiasów lub składania urządzenia, zmienia się orientacja urządzenia z głównej orientacji poziomej na główną orientację pionową (lub odwrotnie).

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 on umożliwiać pobieranie poszczególnych plików 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 mogą być udostępniane przez aplikacje. Jest to często nazywane „wspólne miejsce na dane zewnętrzne”, „wspólne miejsce na dane aplikacji” lub ścieżką Linuxa „/sdcard”, na której jest zamontowane.
• [C-0-2] MUSI być skonfigurowany z pamięcią współdzieloną zamontowaną domyślnie, innymi słowy „out of the box”, niezależnie od tego, czy pamięć jest implementowana na komponencie pamięci wewnętrznej czy wymiennym nośniku pamięci (np. gniazdo kart Secure Digital).
• [C-0-3] NALEŻY zamontować udostępnione miejsce na dane aplikacji bezpośrednio na ścieżce Linuxa sdcard lub umieścić link symboliczny Linuxa z sdcard do rzeczywistego punktu zamontowania.
• [C-0-4] MUSISZ włączyć storage skoncentrowane domyślnie we wszystkich aplikacjach kierowanych na interfejs API na poziomie 29 lub wyższym, z wyjątkiem tej sytuacji:
  • Gdy aplikacja poprosi o android:requestLegacyExternalStorage="true" w pliku manifestu.
• [C-0-5] NALEŻY usunąć metadane dotyczące lokalizacji, takie jak tagi EXIF GPS, 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 za pomocą jednej z tych metod:

• 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 masowej, aby spełnić powyższe wymagania, muszą:

• [C-1-1] W interfejsie należy wyświetlić komunikat w oknie wyskakującym lub w powiadomieniu, gdy w gniazdo nie jest włożone żadne medium.
• [C-1-2] MUSI zawierać nośnik pamięci w formacie FAT (np. kartę SD) lub na opakowaniu i innych materiałach dostępnych w momencie zakupu musi być informacja, że nośnik pamięci musi być kupiony osobno.

Jeśli implementacje urządzeń używają części niewymiennej pamięci masowej, aby spełnić powyższe wymagania, muszą:

• NALEŻY używać implementacji AOSP wewnętrznego współdzielonego magazynu 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, to:

• [C-3-1] Musisz udostępnić mechanizm dostępu do danych w pamięci współdzielonej 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ć to wymaganie.

Jeśli implementacje urządzeń mają port USB z obsługą trybu peryferyjnego USB i protokołu Media Transfer Protocol, muszą:

• POWINIEN być zgodny z hostem MTP na Androidzie, 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ą:

• [C-SR-1] ZDECYDOWANIE POLECAMY stosowanie elastycznej pamięci w stabilnej lokalizacji na dłuższy czas, ponieważ jej przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

Jeśli port wymiennego urządzenia do przechowywania danych znajduje się w stabilnym miejscu, na przykład w komorze baterii lub innej osłonie ochronnej, implementacje urządzenia:

• [C-SR-2] 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.
• NALEŻY obsługiwać wyłączanie sygnalizacji danych przez 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ć podłączenie do hosta USB z standardowym portem USB typu A lub C.
• [C-1-2] MUST report the correct value of iSerialNumber in USB standard device descriptor through android.os.Build.SERIAL.
• [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem rezystora typu C oraz MUSI wykrywać zmiany w reklamie, jeśli obsługuje USB typu C.
• [C-SR-1] Port powinien być w formacie micro-B, micro-AB lub USB typu 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.
• [C-SR-2] Port powinien znajdować się na dole urządzenia (zgodnie z naturalną orientacją) lub umożliwiać obrócenie ekranu w oprogramowaniu 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 stare, i nowe urządzenia z Androidem spełniały te wymagania, aby można było na nich zainstalować przyszłe wersje platformy.
• [C-SR-3] NALEŻY wdrożyć obsługę poboru prądu 1,5 A podczas przesyłania dźwięku w trybie HS oraz ruchu zgodnie ze specyfikacją USB Battery Charging specification, revision 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.
• [C-SR-4] ZDECYDOWANIE POLECANE: nie należy obsługiwać zastrzeżonych metod ładowania, które modyfikują napięcie Vbus poza domyślnymi poziomami lub zmieniają role odbiornika/źródła, ponieważ może to spowodować problemy ze zgodnością z ładowarkami lub urządzeniami, które obsługują standardowe metody przesyłania mocy przez USB. Chociaż jest to „MOCNO ZALECANE”, w przyszłych wersjach Androida możemy wymagać, aby wszystkie urządzenia z gniazdem typu C obsługiwały pełną interoperacyjność ze standardowymi ładowarkami typu C.
• [C-SR-5] ZALECAMY obsługę funkcji Power Delivery do przesyłania danych i przełączania 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 oraz 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ą specyfikację 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 w opisie 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] NALEŻY zaimplementować interfejs API hosta USB Androida zgodnie z dokumentacją w pakiecie Android SDK i NALEŻY zadeklarować 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 DOSTARCZAJĄCY CABLE ADAPTING TO STANDARD PORT TYPE-A.
• [C-1-3] Nie wolno dostarczać urządzenia z adapterem umożliwiającym konwersję portów USB typu A lub mikro-AB na porty typu C (gniazdo).
• [C-SR-1] MOCNO zalecamy implementację klasy audio USB zgodnie z dokumentacją pakietu SDK Androida.
• POWINNA obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta; reklamować prąd źródła co najmniej 1, 5 A zgodnie z sekcją „Termination Parameters” (Parametry zakończenia) w specyfikacji kabla i złącza USB typu C (wersja 1.2) w przypadku złączy USB typu C lub używać portu ładowania w dół (CDP) z zakresem prądu wyjściowego zgodnie z specyfikacją ładowania baterii USB (wersja 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 żądaniu użycia polecenia głosowego do KeyEventkonstant 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ń zawierają 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).
• [C-SR-2] ZALECAMY obsługę interfejsu DisplayPort, ZALECAMY obsługę szybkości transmisji danych SuperSpeed USB oraz ZALECAMY obsługę Power Delivery do przełączania ról danych i mocy.
• [C-SR-3] BARDZO ZALECAMY, aby nie obsługiwać trybu akcesoriów adaptera audio opisanego w Załączniku A w specyfikacji kabla i złącza USB Type-C w wersji 1.2.
• NALEŻY zaimplementować model Try.*, który jest najbardziej odpowiedni dla danego formatu urządzenia. Na przykład urządzenie przenośne POWINNA implementować 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.
• [C-SR-1] 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 z wyjściami audio, takie jak 4-żyłowe gniazdo słuchawkowe 3,5 mm lub port w trybie hosta USB z klasą 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.
• [C-SR-1] ZALECAMY, aby obsługiwać odtwarzanie z częstotliwością zbliżoną do ultradźwięków 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, 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 gniazda 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-1] MOCNO ZALECAMY, aby co najmniej 1 gniazdo audio było 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 na 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 3 zakresów równoważnej impedancji między mikrofonem a uziemieniem 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 tylko wtedy, gdy wszystkie styki wtyczki dotykają odpowiednich segmentów wtyczki.
• [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 klucza dla następującego zakresu impedancji równoważnej między przewodami mikrofonu i uziemienia na wtyczce audio:
  • 110–180 om: KEYCODE_VOICE_ASSIST
• [C-SR-2] ZALECAMY obsługę wtyczek audio z kolejnością styków OMTP.
• [C-SR-3] MOCNO zalecamy obsługę nagrywania dźwięku ze słuchawek 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 transmitują android.intent.action.HEADSET_PLUG z dodatkową wartością mikrofonu ustawioną na 1, to:

• [C-2-1] MUSI obsługiwać wykrywanie mikrofonu w podłączonym akcesorium audio.

7.8.2.2. Porty dźwięku cyfrowego

Zgodność z zestawami słuchawkowymi i innymi urządzeniami audio korzystającymi z złączy USB-C i implementacją (klasa audio USB) w ekosystemie Androida zgodnie ze specyfikacją zestawu słuchawkowego USB 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 audio zbliżonego do ultradźwięków za pomocą interfejsu API AudioManager.getProperty w ten sposób:

Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND jest ustawiona na „true”, źródła audio 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ądzeniu:

• 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. Testowanie za pomocą OboeTester „Automated Glitch Test”.

Do testu potrzebny jest dongiel do pętli audio, który jest używany 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 za pomocą 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 sygnału sinusoidalnego 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 VR mobilnego o wysokiej jakości. Implementacje na urządzeniu 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 3D i wyłącza jednooczne wyświetlanie elementów 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] MUSI obsługiwać 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ć rozszerzenia GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2 i GL_EXT_protected_textures oraz udostępnić je na liście dostępnych rozszerzeń GL.
• [C-SR-1] ZALECAMY WDRAŻENIE ROZWIĄZANIA GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, a także udostępnienie rozszerzeń na liście dostępnych rozszerzeń GL.
• [C-SR-2] Zdecydowanie zalecamy obsługę Vulkan 1.1.
• [C-SR-3] ZALECAMY wdrażanie interfejsów VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing i VK_KHR_shared_presentable_image oraz wyświetlanie ich na liście dostępnych rozszerzeń Vulkan.
• [C-SR-4] 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Ą umożliwiać synchronizowanie dostępu do wspólnego bufora przedniego w taki sposób, aby renderowanie treści VR z wyświetlaniem naprzemiennym oczu z częstotliwoś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 dokumentacją 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 w przynajmniej tych formatach: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] ZALECAMY, aby obsługiwać alokację AHardwareBufferz więcej niż 1 warstwą oraz flagami i formatami określonymi 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-6] MOCNO ZALECAMY, aby rozdzielczość wyświetlacza wynosiła co najmniej 2560 × 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 o niskiej trwałości z trwałością do 5 ms, gdzie trwałość jest zdefiniowana 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-7] ZALECAMY obsługę kanału bezpośredniego TYPE_HARDWARE_BUFFER dla wszystkich typów kanałów bezpośrednich wymienionych powyżej.
• [C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru w urządzeniu android.hardware.hifi_sensors, jak określono w sekcji 7.3.9.
• [C-SR-8] MOCNO zalecamy obsługę funkcji android.hardware.sensor.hifi_sensors.
• [C-1-22] Musisz mieć opóźnienie od ruchu do fotonu nie większe niż 28 ms.
• [C-SR-9] MOCNO ZALECAMY, aby opóźnienie od ruchu do fotonu nie przekraczało 20 ms.
• [C-1-23] Współczynnik pierwszego kadru (first-frame ratio) musi wynosić co najmniej 85%, gdzie jest to stosunek jasności pikseli w pierwszym kadrze po przejściu od czerni do bieli do jasności białych pikseli w stanie ustalonym.
• [C-SR-10] 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ć liczbę 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] Aplikacja NIE MOŻE zezwalać na uruchamianie w sobie żadnych innych procesów przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.

7.10. Reakcja na dotyk

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

7.11. Klasa Media Performance

Klasę wydajności multimediów implementacji urządzenia można uzyskać z android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS. Wymagania dotyczące klasy wydajności multimediów są zdefiniowane dla każdej wersji Androida, począwszy od wersji R (30). Specjalna wartość 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.MEDIA_PERFORMANCE_CLASS, to:

• [C-1-1] Musi zwracać co najmniej wartość android.os.Build.VERSION_CODES.R.

• [C-1-2] Musi być implementacją na urządzeniu przenośnym.

• [C-1-3] MUSI spełniać wszystkie wymagania dotyczące „Klasy skuteczności reklamy” 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żytkowników 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 gwarantują spójną liczbę klatek na sekundę i czas reakcji w przypadku aplikacji i gier. W zależności od typu urządzenia implementacje MOŻE wymagać mierzalnych wartości opóźnień interfejsu użytkownika i przełączania zadań, zgodnie z opisem w sekcji 2.

8.2. Wydajność dostępu do plików I/O

Udostępnianie wspólnej wartości referencyjnej dla spójnej wydajności dostępu do plików w pamięci na dane prywatne aplikacji (partycji /data) pozwala deweloperom aplikacji na sformułowanie odpowiednich oczekiwań, które pomogą im w projektowaniu oprogramowania. W zależności od typu urządzenia implementacje MOŻE wymagać spełnienia pewnych wymagań opisanych w sekcji 2 w przypadku 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. Pomiar wykonano podczas zapisywania pliku o rozmiarze 256 MB za pomocą 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ą zawarte w AOSP (np. grupa w trybie gotowości aplikacji, Doze) lub rozszerzają funkcje, aby zastosować bardziej restrykcyjne ograniczenia niż grupa w trybie gotowości aplikacji ZRANIONY, muszą:

• [C-1-1] NIE MOŻE odbiegać od implementacji AOSP w zakresie uruchamiania, konserwacji, algorytmów wybudzania i używania globalnych ustawień systemu lub DeviceConfig w przypadku trybów oszczędzania energii App Standby i Doze.
• [C-1-2] NIE MOŻE odbiegać od implementacji AOSP w zakresie korzystania z ustawień globalnych lub DeviceConfig do zarządzania ograniczaniem szybkości wykonywania zadań, alarmów i sieci w przypadku aplikacji w każdej grupie w ramach funkcji App Standby.
• [C-1-3] W przypadku liczby poziomów w trybie czuwania aplikacji używanych w trybie czuwania aplikacji NIE MOŻNA odbiegać od implementacji AOSP.
• [C-1-4] NALEŻY wdrożyć grupy czuwania aplikacji i funkcję Uśpienie zgodnie z opisem w Zarządzanie zasilaniem.
• [C-1-5] NALEŻY zwrócić true dla PowerManager.isPowerSaveMode(), gdy urządzenie jest w trybie oszczędzania energii.
• [C-1-6] MUSISZ umożliwić użytkownikowi wyświetlanie wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze lub z optymalizacji baterii, a także MUSISZ zaimplementować działanie ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, aby poprosić użytkownika o zezwolenie na ignorowanie optymalizacji baterii przez aplikację.
• [C-SR-1] MOCNO ZALECAMY, aby umożliwić użytkownikom włączenie i wyłączenie funkcji oszczędzania baterii.
• [C-SR-2] 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 to stosuje bardziej rygorystyczne ograniczenia niż kategoria rzadko używanych aplikacji w stanie gotowości, 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 określone przez interfejs ACPI (Advanced Configuration and Power Interface).

Jeśli implementacje urządzeń obsługują stany zasilania S4 zgodnie z definicją ACPI, to:

• [C-1-1] Musisz przejść do tego stanu tylko po tym, jak użytkownik wykonał wyraźne działanie, aby umieścić urządzenie w stanie nieaktywnym (np. przez zamknięcie pokrywy, która jest fizyczną częścią urządzenia, lub wyłączenie pojazdu lub telewizora) i zanim użytkownik ponownie aktywuje urządzenie (np. przez otwarcie pokrywy lub ponowne włączenie pojazdu lub telewizora).

Jeśli implementacje urządzeń implementują stany zasilania S3 zgodnie z definicją ACPI, to:

• [C-2-1] MUSI spełniać wymagania podane w sekcji C-1-1 lub MUSI przejść w stan S3 tylko wtedy, gdy aplikacje innych firm nie potrzebują zasobów systemowych (np. ekranu czy procesora).

  W przeciwnym razie MUSISZ wyjść ze stanu S3, gdy aplikacje innych firm potrzebują zasobów systemowych, zgodnie z opisem w tym pakiecie SDK.

  Podczas gdy aplikacje innych firm proszą o utrzymanie ekranu włączonego za pomocą funkcji FLAG_KEEP_SCREEN_ON lub o utrzymanie procesora w stanie aktywnym za pomocą funkcji PARTIAL_WAKE_LOCK, urządzenie NIE MOŻE wejść 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 zostanie wywołane zadanie implementowane przez aplikacje innych firm za pomocą JobSchedulera lub gdy Komunikacja w chmurze Firebase zostanie dostarczona do aplikacji innych firm, 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 aktywacji, które powodują przebudzenie z tego stanu.

8.4. Rachunkowość zużycia energii

Dokładniejsze rejestrowanie i raportowanie zużycia energii daje deweloperowi aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorców zużycia energii aplikacji.

Implementacje na urządzeniu:

• [C-SR-1] BARDZO ZALECANA: podaj 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 pobór energii przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
• [C-SR-2] ZALECAMY, aby wszystkie wartości zużycia energii były podawane w miliamperogodzinach (mAh).
• [C-SR-3] MOCNO ZALECANA rejestracja zużycia energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [C-SR-4] ZDECYDOWANIE ZALECAMY udostępnienie tego użycia energii za pomocą polecenia adb shell dumpsys batterystats w powłoce dla dewelopera aplikacji.
• NALEŻY przypisać 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, które działają przez dłuższy czas. Może to być spowodowane innymi aplikacjami działającymi w tle lub ograniczeniem procesora z powodu limitów temperatury. Android zawiera interfejsy programowe, dzięki którym aplikacja na pierwszym planie może poprosić system o zoptymalizowanie alokacji zasobów, aby zniwelować takie wahania.

Implementacje na urządzeniu:

• [C-0-1] NALEŻY prawidłowo zgłaszać obsługę trybu ciągłej wydajności 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] NALEŻY zapewnić 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 aplikacji na pierwszym planie, to:

• [C-2-1] Musisz przekazać przez metodę interfejsu API Process.getExclusiveCores() numery identyfikatorów zasobów jądrowych, które mogą być zarezerwowane przez główną aplikację na pierwszym planie.
• [C-2-2] Nie wolno zezwalać na uruchamianie w rdzeniu aplikacji żadnych procesów w przestrzeni użytkownika z wyjątkiem sterowników urządzeń, ale można zezwolić 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 zaimplementować 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 zezwoleń lub certyfikatów od stron trzecich lub organów.

Jeśli implementacje na urządzeniach deklarują funkcję android.hardware.security.model.compatible:

• [C-1-1] MUSI obsługiwać wymagania wymienione w następujących podrozdziałach.

9.1. Uprawnienia

Implementacje na urządzeniu:

• [C-0-1] Aplikacja MUSI obsługiwać model uprawnień Androida i model ról Androida zdefiniowane w dokumentacji dla deweloperów Androida. W szczególności muszą one egzekwować wszystkie uprawnienia i role zdefiniowane w dokumentacji SDK. Żadnych uprawnień ani ról nie można pominąć, zmienić ani zignorować.

• MOŻESZ dodać dodatkowe uprawnienia, o ile nowe ciągi znaków identyfikatora uprawnień nie znajdują się w przestrzeni nazw android.\*.

• [C-0-2] Uprawnienia z protectionLevel PROTECTION_FLAG_PRIVILEGEDMUSZĄ być przyznawane tylko aplikacjom wstępnie zainstalowanym na ścieżkach uprzywilejowanych w obrazie systemu i w ramach podzbioru uprawnień dozwolonych w przypadku każdej aplikacji. Implementacja AOSP spełnia ten wymóg, odczytując i szanując uprawnienia dozwolone 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] MUSI wyświetlać specjalny interfejs, aby użytkownik mógł zdecydować, czy przyznać żądane uprawnienia w czasie działania, a także udostępnić interfejs, za pomocą którego użytkownik może zarządzać uprawnieniami w czasie działania.
• [C-0-4] Musi istnieć tylko jedna implementacja 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ć uprawnienia android.permission.RECOVER_KEYSTORE tylko aplikacjom systemowym, które rejestrują odpowiednio zabezpieczonego agenta odzyskiwania. prawidłowo zabezpieczony agent odzyskiwania to oprogramowanie na urządzeniu, które synchronizuje się z zdalnymi miejscami na dane poza urządzeniem. Oprogramowanie to jest wyposażone w zabezpieczenia sprzętowe o odpowiedniej lub większej skuteczności niż te opisane w usłudze Google Cloud Key Vault, aby zapobiec atakom typu brute-force na element wiedzy związany z ekranem 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 za pomocą zastrzeżonego mechanizmu. Dane te obejmują:

  • Lokalizacja urządzenia (np. szerokość i długość geograficzna) zgodnie z opisem w sekcji 9.8.8.
  • 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.

Jedynymi wyjątkami od powyższych właściwości uprawnień do lokalizacji na Androidzie są aplikacje, które nie uzyskują dostępu do lokalizacji w celu określenia lub identyfikacji lokalizacji użytkownika. Dotyczy to w szczególności:

• Gdy aplikacje mają uprawnienia RADIO_SCAN_WITHOUT_LOCATION.
• w celu konfiguracji urządzenia, gdy aplikacje systemowe mają uprawnienia NETWORK_SETTINGS lub NETWORK_SETUP_WIZARD;

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 uprawnieniami softRestricted MUSZĄ mieć tylko ograniczony dostęp i NIE mogą uzyskać pełny dostęp, dopóki nie zostaną dodane do listy dozwolonych w pakiecie SDK, gdzie dla każdego uprawnienia softRestricted zdefiniowano pełny i ograniczony dostęp (np. READ_EXTERNAL_STORAGE).

• [C-0-12] NIE MOŻESZ udostępniać żadnych funkcji ani interfejsów API, które umożliwiają obejście ograniczeń dostępu zdefiniowanych w interfejsach API setPermissionPolicy i setPermissionGrantState.

• [C-0-13] DO nagrywania i śledzenia każdego dostępu do danych chronionych przez niebezpieczne uprawnienia z działalności i usług Androida należy używać interfejsów AppOpsManager API.

• [C-0-14] NALEŻY przypisywać role tylko do aplikacji z funkcjami spełniającymi wymagania dotyczące ról.

• [C-0-15] Nie wolno definiować ról, które są duplikatami lub superzbiorem funkcji ról zdefiniowanych przez platformę.

Jeśli urządzenia zgłaszają android.software.managed_users, to:

• [C-1-1] Nie może mieć następujących uprawnień przyznanych przez administratora:
  • Lokalizacja (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Aparat (CAMERA)
  • Mikrofon (RECORD_AUDIO)
  • Czujnik na ciele (BODY_SENSORS)
  • Aktywność fizyczna (ACTIVITY_RECOGNITION)

Jeśli implementacje urządzeń umożliwiają użytkownikowi wybór 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 działania z filtrami intencji dla intencji ACTION_MANAGE_OVERLAY_PERMISSION miały ten sam ekran interfejsu niezależnie od aplikacji inicjującej i informacje, które ona udostępnia.

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

• [C-3-1] MUST show a disclaimer during fully managed device setup (device owner setup) stating that the IT admin will have the ability to allow apps to control settings on the phone including microphone, camera and location, with options for user to continue setup or exit setup UNLESS the admin has opted out of control of permissions on the device.

Jeśli implementacje urządzeń wstępnie instalują pakiety zawierające dowolną z ról System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence lub System Visual Intelligence, pakiety:

• [C-4-1] MUSI spełniać wszystkie wymagania dotyczące implementacji urządzeń opisane w sekcji „9.8.6 Przechwytywanie treści”.
• [C-4-2] Aplikacja NIE MOŻE mieć uprawnienia android.permission.INTERNET. Jest to bardziej restrykcyjne niż zalecenie o wysokim priorytecie wymienione w sekcji 9.8.6.
• [C-4-3] NIE MOŻE wiązać się z innymi aplikacjami, z wyjątkiem tych aplikacji systemowych: Bluetooth, Kontakty, Media, Telefonia, SystemUI oraz komponentów udostępniających interfejsy internetowe.Jest to bardziej restrykcyjne niż zalecenie w sekcji 9.8.6.

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 pod tym samym identyfikatorem użytkownika systemu Linux, pod warunkiem, że aplikacje są prawidłowo podpisane i skonstruowane zgodnie z definicją w dokumentacji Bezpieczeństwo i uprawnienia.

9.3. Uprawnienia do systemu plików

Implementacje na urządzeniu:

• [C-0-1] MUSI obsługiwać model uprawnień dostępu do plików Androida zgodnie z definicją w dokumentacji dotyczącej zabezpieczeń i uprawnień.

9.4. Alternatywne środowiska wykonawcze

Implementacje na urządzeniach MUSZĄ zachowywać spójność modelu zabezpieczeń i uprawnień Androida, nawet jeśli obejmują środowiska uruchomieniowe, które wykonują aplikacje za pomocą innego oprogramowania lub technologii niż kod wykonywalny Dalvik lub kod natywny. Krótko mówiąc:

• [C-0-1] Alternatywny środowisko uruchomieniowe MUSI być aplikacją na Androida i stosować się do standardowego modelu zabezpieczeń Androida, zgodnie z opisem w sekcji 9.

• [C-0-2] Alternatywnym środowiskom uruchomieniowym NIE NALEŻY przyznawać dostępu do zasobów chronionych uprawnieniami, 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] Alternatywny czas wykonywania MUSI być zgodny z modelem piaskownicy Androida, a zainstalowane aplikacje korzystające z alternatywnego czasu wykonywania 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 czas wykonywania 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 ani innym identyfikatorom użytkownika.

• [C-0-7] Jeśli pliki .apk alternatywnych środowisk wykonawczych są uwzględnione w pliku obrazu systemu implementacji urządzenia, muszą być podpisane za pomocą klucza innego niż klucz użyty do podpisania 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 użyć zasobu urządzenia, do którego dostęp jest możliwy na podstawie odpowiedniego uprawnienia Androida (np. aparatu lub GPS-a), środowisko uruchomieniowe MUSI poinformować użytkownika, że aplikacja będzie mogła uzyskać 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, które posiada samo ś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 Linuksa itp.).

• Alternatywny czas wykonywania MOŻE udostępniać jedną piaskownicę Androida, z której korzystają wszystkie aplikacje korzystające z tego alternatywnego środowiska uruchomieniowego.

9,5. Pomoc dla wielu użytkowników

Android obsługuje wielu użytkowników oraz zapewnia pełną izolację użytkowników i klonowanie profili użytkowników z częściową izolacją(np. pojedynczy dodatkowy profil użytkownika typu android.os.usertype.profile.CLONE).

• 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ń obsługują wielu użytkowników, muszą:

• [C-1-2] W przypadku każdego użytkownika MUSISZ wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji referencyjnej Bezpieczeństwo i uprawnienia dotyczącej interfejsów API.
• [C-1-3] Musisz mieć oddzielne i odizolowane katalogi współdzielonego miejsca na dane aplikacji (zwanego też /sdcard) dla każdej instancji użytkownika.
• [C-1-4] NALEŻY zadbać o to, aby aplikacje należące do danego użytkownika i działające 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łączono obsługę wielu użytkowników, używając klucza przechowywanego tylko na niewymiennym nośniku, dostępnego tylko dla systemu, jeśli implementacje urządzenia korzystają z interfejsów API zewnętrznej pamięci masowej na nośnikach wymiennych. 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.

Jeśli implementacje urządzeń obsługują wielu użytkowników, to w przypadku wszystkich użytkowników (z wyjątkiem użytkowników utworzonych specjalnie do uruchamiania dwóch instancji tej samej aplikacji) obowiązują następujące zasady:

• [C-2-1] Musisz mieć oddzielne i odizolowane katalogi wspólnej pamięci aplikacji (np. /sdcard) dla każdej instancji użytkownika.
• [C-2-2] 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 na tym samym woluminie lub w tym samym systemie plików.

Implementacje urządzeń mogą tworzyć dodatkowy profil użytkownika typu android.os.usertype.profile.CLONE dla głównego użytkownika (i tylko dla głównego użytkownika) w celu uruchamiania dwóch instancji tej samej aplikacji. Te dwie instancje współdzielą częściowo odizolowane miejsce na dane, są prezentowane użytkownikowi w tym samym czasie w menu i wyświetlane w tym samym widoku Ostatnie. Można go na przykład użyć, aby umożliwić użytkownikowi zainstalowanie 2 oddzielnych instancji jednej aplikacji na urządzeniu z 2 kartami SIM.

Jeśli implementacje urządzeń tworzą dodatkowy profil użytkownika, o którym mowa powyżej, to:

• [C-3-1] MUSI zapewniać dostęp tylko do pamięci lub danych, które są już dostępne dla nadrzędnego profilu użytkownika lub są bezpośrednio własnością tego dodatkowego profilu użytkownika.
• [C-3-2] NIE MOŻE być to profil służbowy.
• [C-3-3] Musisz mieć odizolowane katalogi danych aplikacji od nadrzędnego konta użytkownika.
• [C-3-4] NIE wolno zezwalać na utworzenie dodatkowego profilu użytkownika, jeśli istnieje właściciel urządzenia (patrz sekcja 3.9.1) lub zezwalać na skonfigurowanie właściciela urządzenia bez wcześniejszego usunięcia dodatkowego profilu użytkownika.

9,6. Ostrzeżenie dotyczące SMS-ów specjalnych

Android obsługuje ostrzeżenia użytkowników przed wysyłaniem specjalnych SMS-ów. SMS-y specjalne 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ądzeniu deklarują obsługę android.hardware.telephony, to:

• [C-1-1] NALEŻY ostrzegać użytkowników przed wysyłaniem SMS-ów na numery zidentyfikowane za pomocą wyrażeń regularnych zdefiniowanych w pliku /data/misc/sms/codes.xml na urządzeniu. Dostępny w górę projekt Android Open Source udostępnia 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 rdzeniu systemu Linux. Implementacje na urządzeniu:

• [C-0-1] Musi być zgodny z dotychczasowymi aplikacjami, nawet jeśli SELinux lub inne funkcje zabezpieczeń są wdrażane poniżej platformy Android.
• [C-0-2] Nie wolno stosować widocznego interfejsu użytkownika, gdy wykryto naruszenie zabezpieczeń i udało się je zablokować za pomocą funkcji bezpieczeństwa zaimplementowanej poniżej platformy Android, ale można użyć widocznego interfejsu użytkownika, gdy dochodzi do niezablokowanego naruszenia zabezpieczeń, które umożliwia skuteczne wykorzystanie luki.
• [C-0-3] Nie wolno udostępniać użytkownikowi ani deweloperowi aplikacji możliwości konfigurowania SELinux ani innych funkcji zabezpieczeń zaimplementowanych 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 można było przyznawać dostęp do poszczególnych procesów w sposób bardziej szczegółowy, zgodnie z opisem na stronie projektu Android Open Source.
• [C-0-6] NALEŻY wdrożyć 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 to wymaganie dzięki włączeniu seccomp-BPF z synchronizacją wątków (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 rozmiaru statycznych i dynamicznych obiektów oraz ich granic na kopiach między przestrzenią użytkownika a jądrem (np. CONFIG_HARDENED_USERCOPY) na urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym.
• [C-0-10] NIE WYKONUJ kodu w pamięci przeznaczonej dla użytkownika podczas wykonywania kodu w trybie jądra (np. w ramach sprzętowego PXN lub emulacji 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 jądrze poza normalnymi interfejsami API dostępu do danych użytkownika (np. interfejs API PAN dla sprzętu lub emulowany za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub wyższym.
• [C-0-12] NALEŻY wdrożyć 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 CVE-2017-5715 na wszystkich urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym (np. CONFIG_HARDEN_BRANCH_PREDICTOR).
• [C-SR-1] ZALECAMY, aby dane jądra, które są zapisywane tylko podczas inicjowania, były po inicjowaniu oznaczone jako tylko do odczytu (np. __ro_after_init).

• [C-SR-2] Zdecydowanie zalecamy losowanie ukł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-3] ZALECAMY stosowanie 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-4] ZALECAMY NIE stosowanie wyłączania integralności kontroli przepływu (CFI), ścieżki wywołań cienia (SCS) ani sterowania przepełnieniem liczb całkowitych (IntSan) w komponentach, w których są one włączone.

• [C-SR-5] Zdecydowanie zalecamy włączenie CFI, SCS i IntSan w przypadku wszystkich dodatkowych komponentów przestrzeni użytkownika, które są istotne z punktu widzenia bezpieczeństwa, zgodnie z opisem w dokumentach CFI i IntSan.

• [C-SR-6] Zdecydowanie zalecamy włączenie inicjalizacji stosu w rdzeniu, aby zapobiec używaniu niezinicjowanych zmiennych lokalnych (CONFIG_INIT_STACK_ALL lub CONFIG_INIT_STACK_ALL_ZERO). Ponadto implementacje na urządzeniach NIE powinny przyjmować wartości używanej przez kompilator do inicjalizacji zmiennych lokalnych.

• [C-SR-7] ZALECAMY WYMAGANIE włączenia inicjalizacji stosu w jądrze, aby zapobiec używaniu nieinicjalizowanych alokacji stosu (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). Nie należy też zakładać wartości używanej przez jądro do inicjalizacji tych alokacji.

Jeśli implementacje urządzeń korzystają z jądra Linuksa, które obsługuje SELinux, to:

• [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. Nie są dozwolone domeny w trybie permisywnym, w tym domeny związane z urządzeniem lub dostawcą.
• [C-1-4] Nie wolno modyfikować, pomijać ani zastępować zasad neverallow w folderze system/sepolicy udostępnianym w ramach projektu upstream Android Open Source (AOSP). Zasady muszą być zgodne ze wszystkimi zasadami 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 z ograniczeniami SELinux dla każdej aplikacji w przypadku katalogu prywatnych danych 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 dodatkowe informacje dotyczące konfiguracji konkretnego urządzenia.

Jeśli implementacje urządzeń używają jądra innego niż Linux lub Linux bez SELinux, to:

• [C-2-1] NALEŻY używać systemu obowiązkowej kontroli dostępu, który jest równoważny z SELinux.

Jeśli implementacje urządzeń używają urządzeń wejścia/wyjścia obsługujących DMA, to:

• [C-SR-8] ZALECAMY, aby każde urządzenie wejścia/wyjścia obsługujące DMA było izolowane za pomocą IOMMU (np. ARM SMMU).

Android zawiera wiele funkcji zabezpieczeń, które są integralną częścią zabezpieczeń urządzenia. Poza tym Android koncentruje się na ograniczaniu występowania kluczowych typów częstych błędów, które wpływają na niską jakość i bezpieczeństwo.

Aby ograniczyć błędy związane z pamięcią, implementacje na urządzeniach:

• [C-SR-9] Zaleca się przetestowanie ich za pomocą narzędzi do wykrywania błędów pamięci w przestrzeni użytkownika, takich jak MTE w przypadku urządzeń ARMv9, HWASan w przypadku urządzeń ARMv8+ lub ASan w przypadku innych typów urządzeń.
• [C-SR-10] MOCNO POLECANE jest przetestowanie za pomocą narzędzi do wykrywania błędów pamięci jądra, takich jak KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS dla urządzeń ARMv9, CONFIG_KASAN_SW_TAGS dla urządzeń ARMv8 lub CONFIG_KASAN_GENERIC dla innych typów urządzeń).
• [C-SR-11] MOCNO zalecamy używanie w wersji produkcyjnej narzędzi do wykrywania błędów pamięci, takich jak MTE, GWP-ASan i KFENCE.

Jeśli implementacje urządzeń korzystają z zaufanego środowiska wykonawczego TEE opartego na Arm TrustZone, to:

• [C-SR-12] MOCNO zaleca się używanie standardowego protokołu do udostępniania pamięci między Androidem a procesorem TEE, np. Arm Firmware Framework dla Armv8-A (FF-A).
• [C-SR-13] Zdecydowanie zalecamy ograniczenie zaufanych aplikacji do dostępu tylko do pamięci, do której zostały one wyraźnie udostępnione za pomocą wymienionego powyżej protokołu. Jeśli urządzenie obsługuje poziom wyjątków Arm S-EL2, menedżer partycji zabezpieczonej powinien go wymuszać. W przeciwnym razie powinno to być wymuszane przez system operacyjny TEE.

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.
• [C-SR-1] MOCNO zalecamy zachowanie okresu przechowywania wynoszącego 14 dni, który jest domyślnie skonfigurowany 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ę System API IncidentManager MUSZ podać 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 dotyczących StatsLog pakietu SDK. 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źnych powiadomień.
• [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 ekranu lub nagrywanie ekranu za pomocą interfejsu MediaProjection lub zastrzeżonego interfejsu API. NIE MOŻESZ udostępnić użytkownikom opcji wyłączenia wyświetlania prośby o zgodę.
• [C-0-3] Należy wyświetlać użytkownikowi ciągłe powiadomienie, gdy włączone jest przesyłanie obrazu lub nagrywanie ekranu. AOSP spełnia ten wymóg, wyświetlając na pasku stanu ikonę trwającego powiadomienia.

Jeśli implementacje na urządzeniu obejmują funkcje systemu, które przechwytują treści wyświetlane na ekranie lub nagrywają strumień audio odtwarzany 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 „Zachwytywanie 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 obraz.

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 kopie, chyba że użytkownik wyrazi na to zgodę.

„Wskaźnik mikrofonu” to widok na ekranie, który jest stale widoczny dla użytkownika i nie może być zasłonięty. Użytkownicy powinni rozumieć, że mikrofon jest używany(za pomocą unikalnego tekstu, koloru, ikony lub ich kombinacji).

„Wskaźnik kamery” to widok na ekranie, który jest stale widoczny dla użytkownika i nie może być zasłonięty, co pozwala użytkownikom zrozumieć, że kamera jest używana (za pomocą unikalnego tekstu, koloru, ikony lub ich kombinacji).

Po upływie pierwszej sekundy wyświetlania wskaźnik może się wizualnie zmienić, np. stać się mniejszy, i nie musi być wyświetlany w taki sposób, w jaki został pierwotnie przedstawiony i zrozumiany.

Wskaźnik mikrofonu może być połączony z wyświetlanym aktywnie wskaźnikiem kamery, o ile tekst, ikony lub kolory wskazują użytkownikowi, że mikrofon jest włączony.

Wskaźnik aparatu może być połączony z wskaźnikiem mikrofonu, o ile tekst, ikony lub kolory wskazują użytkownikowi, że aparat jest w użyciu.

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

• [C-SR-1] Zdecydowanie zalecamy wyświetlanie wskaźnika mikrofonu, gdy aplikacja uzyskuje dostęp do danych audio z mikrofonu, ale nie wtedy, gdy dostęp do mikrofonu mają tylko HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje, które mają role wymienione w sekcji 9.1 Uprawnienia z identyfikatorem CDD [C-3-X]. .
• [C-SR-2] MOCNO ZALECAMY wyświetlanie listy ostatnich i aktywnych aplikacji korzystających z mikrofonu, z którą zwraca PermissionManager.getIndicatorAppOpUsageData(), wraz z wszelkimi powiązanymi z nimi komunikatami dotyczącymi atrybucji.
• [C-SR-3] MOCNO ZALECAMY, aby nie ukrywać wskaźnika mikrofonu w przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub bezpośrednią interakcję z użytkownikiem.

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

• [C-SR-4] Zdecydowanie zalecamy wyświetlanie wskaźnika kamery, gdy aplikacja uzyskuje dostęp do danych z kamery na żywo, ale nie wtedy, gdy dostęp do kamery mają tylko aplikacje o rolach wymienionych w sekcji 9.1 Uprawnienia z identyfikatorem CDD [C-3-X].
• [C-SR-5] MOCNO POLECAMY wyświetlanie ostatnich i aktywnych aplikacji za pomocą kamery z użyciem danych z funkcji PermissionManager.getIndicatorAppOpUsageData(), wraz z wszelkimi powiązanymi z nimi komunikatami.
• [C-SR-6] W przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub bezpośrednią interakcję z użytkownikiem, MOCNO POLECAMY, aby nie ukrywać wskaźnika użycia aparatu.

9.8.3. Łączność

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB, to:

• [C-1-1] NALEŻY wyświetlić interfejs z prośbą o zgodę użytkownika przed udzieleniem 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 urzędu certyfikacji (CA) zaufane przez system, które zostały dostarczone w poprzedniej wersji Android Open Source Project.
• [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 dodano główny urząd 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, które zawiera:
  • Ruch w sieci może być monitorowany.
  • Ruch sieciowy jest kierowany przez konkretną aplikację VPN, która zapewnia VPN.

Jeśli implementacje urządzeń mają mechanizm, który jest domyślnie włączony, przekierowuje ruch danych sieciowych przez serwer proxy lub bramę VPN (na przykład w ramach wstępnego wczytania usługi VPN z 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ą interfejsu DevicePolicyManager.setAlwaysOnVpnPackage(), w którym to 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 wyłączyć tę funkcję dla aplikacji, które nie obsługują stałej usługi VPN, ustawiając atrybut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

9.8.5. Identyfikatory urządzeń

Implementacje na urządzeniu:

• [C-0-1] Aplikacja MUSI uniemożliwić dostęp do numeru seryjnego urządzenia oraz, 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 abonenta.

9.8.6. Rejestrowanie treści i wyszukiwanie aplikacji

Android za pomocą interfejsu System API ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query lub innych zastrzeżonych metod obsługuje mechanizm implementacji urządzeń umożliwiający rejestrowanie tych interakcji z danymi aplikacji między aplikacjami a użytkownikiem:

• Tekst i grafika renderowane na ekranie, w tym między innymi powiadomienia i dane pomocnicze 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 dostarczane przez aplikację do systemu za pomocą interfejsu Content Capture API lub interfejsu AppSearchManager API, który ma podobne możliwości i jest zastrzeżonym interfejsem API na Androida.
• 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;
• Dane zindeksowane przez implementację platformy AppSearch, w tym m.in. tekst, grafika, dane multimedialne i inne podobne dane.

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 zostać wykonane za pomocą szyfrowania opartego na plikach Androida 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 tworzenia kopii zapasowych.
• [C-1-3] NALEŻY wysyłać wszystkie takie dane i dziennik urządzenia tylko za pomocą mechanizmu zapewniającego ochronę prywatności. Mechanizm ochrony prywatności definiuje się jako „taki, który umożliwia analizę tylko w ujęciu zbiorczym i uniemożliwia dopasowywanie zarejestrowanych zdarzeń lub wyników pochodnych do poszczególnych użytkowników”, aby zapobiec możliwości analizowania danych dotyczących 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ę za każdym razem, gdy dane zostaną powiązane.
• [C-1-5] NIE MOŻESZ udostępniać takich danych innym komponentom systemu operacyjnego, które nie spełniają wymagań opisanych w tej sekcji (9.8.6 Zbieranie treści), chyba że użytkownik wyrazi zgodę na ich udostępnienie 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.
• [C-1-7] Musisz umożliwić użytkownikowi rezygnację z wyświetlania danych zebranych przez AppSearch lub za pomocą zastrzeżonych metod na platformie Android (np. w wyszukiwarce).
• [C-SR-1] Zdecydowanie zalecamy, aby nie prosić o uprawnienia INTERNET.
• [C-SR-2] MOCNO POLECAMY korzystanie z internetu tylko za pomocą ustrukturyzowanych interfejsów API opartych na publicznie dostępnych implementacjach typu open source.

Jeśli implementacje na urządzeniu obejmują usługę, która implementuje interfejs System APIContentCaptureService, AppSearchManager.index lub dowolną własną usługę, która rejestruje dane w sposób opisany powyżej, to:

• [C-2-1] NIE wolno zezwalać użytkownikom na zastępowanie usług aplikacją lub usługą instalowaną przez użytkownika. NALEŻY zezwolić na rejestrowanie takich danych tylko w preinstalowanych usługach.
• [C-2-2] NIE NALEŻY zezwalać żadnym aplikacjom innym niż wstępnie zainstalowane usługi na rejestrowanie takich danych.
• [C-2-3] NALEŻY umożliwić użytkownikowi wyłączenie usług.
• [C-2-4] NIE MOŻNA pominąć możliwości zarządzania uprawnieniami Androida, które są wymagane przez usługi i które są zgodne z modelem uprawnień Androida opisanym w sekcji 9.1. Uprawnienia.

• [C-SR-3] ZALECAMY, aby usługi były oddzielone od innych komponentów systemu(np. nie wiązać usługi ani nie udostępniać identyfikatorów procesów), z wyjątkiem:

  • Telefonia, Kontakty, UI systemu i multimedia

Android za pomocą SpeechRecognizer#onDeviceSpeechRecognizer() umożliwia rozpoznawanie mowy na urządzeniu bez udziału sieci. Wdrożenie usługi SpeechRecognizer na urządzeniu MUSI być zgodne z zasadami opisanymi w tej sekcji.

9.8.7. Dostęp do schowka

Implementacje na urządzeniu:

• [C-0-1] NIE MOŻE zwracać danych z wykroju w schowku (np. za pomocą interfejsu API ClipboardManager), chyba że aplikacja jest domyślną metodą wprowadzania lub jest aplikacją, która jest obecnie aktywna.

9.8.8. Lokalizacja

Lokalizacja obejmuje informacje z klasy Lokalizacja Androida( np. szerokość, długość geograficzna, wysokość), a także identyfikatory, które można przekształcić w lokalizację. Lokalizacja może być tak dokładna jak DGPS (Differential Global Positioning System) lub tak ogólna jak lokalizacja na poziomie kraju (np. kod kraju – MCC – Mobile Country Code).

Poniżej znajdziesz listę typów lokalizacji, które są bezpośrednio powiązane z lokalizacją użytkownika lub mogą zostać w nią przekształcone. Ta lista nie jest wyczerpująca, ale powinna służyć jako przykład tego, co może być bezpośrednio lub pośrednio powiązane z lokalizacją:

• GPS/GNSS/DGPS/PPP
  • Globalne rozwiązanie do pozycjonowania lub globalny system nawigacji satelitarnej lub różnicowe globalne rozwiązanie do pozycjonowania
  • Obejmuje to również surowe pomiary GNSS i stan GNSS.
    • Dokładną lokalizację można uzyskać na podstawie surowych pomiarów GNSS
• Technologie bezprzewodowe z unikalnymi identyfikatorami, takie jak:
  • Punkty dostępu Wi-Fi (MAC, BSSID, nazwa lub SSID)
  • Bluetooth/BLE (MAC, BSSID, nazwa lub SSID)
  • UWB (MAC, BSSID, nazwa lub SSID)
  • Identyfikator wieży komórkowej (3G, 4G, 5G… w tym wszystkie przyszłe technologie modemu komórkowego, które mają unikalne identyfikatory)

Jako główne źródło informacji sprawdź interfejsy API Androida, które wymagają uprawnień ACCESS_FINE_LOCATION lub ACCESS_COARSE_Location.

Implementacje 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 awaryjnej (np. wybieranie numeru 112 lub wysyłanie SMS-a na numer 112). W przypadku pojazdów jednak pojazd MOŻE zainicjować sesję awaryjną bez aktywnej interakcji użytkownika w przypadku wykrycia wypadku (np. w celu spełnienia wymagań 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 działająca w tle uzyskała dostęp do jego lokalizacji za pomocą uprawnienia [ACCESS_BACKGROUND_LOCATION].

9.8.9. Zainstalowane aplikacje

Aplikacje na Androida kierowane na interfejs API na poziomie 30 lub wyższym nie mogą domyślnie wyświetlać szczegółów o innych zainstalowanych aplikacjach (patrz Widoczność pakietu w dokumentacji pakietu SDK Androida).

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 żadnej innej zainstalowanej aplikacji, chyba że aplikacja może już zobaczyć szczegóły dotyczące tej innej zainstalowanej aplikacji za pomocą interfejsów API zarządzanych. 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.
• [C-0-2] NIE NALEŻY zezwalać żadnej aplikacji na odczyt ani zapisywanie plików w żadnym innym katalogu aplikacji w pamięci zewnętrznej. Jedynymi wyjątkami są:
  • Dostawca autoryzacji pamięci zewnętrznej (np. aplikacje takie jak DocumentsUI).
  • Dostawca pobierania, który używa uprawnień dostawcy „pobierania” do pobierania plików do pamięci aplikacji.
  • Aplikacje korzystające z protokołu przesyłania multimediów (MTP) podpisane przez platformę, które używają uprzywilejowanego uprawnienia ACCESS_MTP do przesyłania plików na inne urządzenie.
  • Aplikacje, które instalują inne aplikacje i mają uprawnienie INSTALL_PACKAGES, mogą uzyskiwać dostęp tylko do katalogów „obb” w celu zarządzania plikami rozszerzenia APK.

9.8.10. Raport o błędzie związanym z łącznością

Jeśli implementacje urządzeń deklarują flagę funkcji android.hardware.telephony, to:

• [C-1-1] Musi obsługiwać generowanie raportów o błędach dotyczących łączności za pomocą funkcji BUGREPORT_MODE_TELEPHONY w klasie BugreportManager.
• [C-1-2] NALEŻY uzyskać zgodę użytkownika za każdym razem, gdy funkcja BUGREPORT_MODE_TELEPHONY jest używana do wygenerowania raportu. Nie należy prosić użytkownika o zgodę na wszystkie przyszłe żądania aplikacji.
• [C-1-3] NIE MOŻESZ zwrócić wygenerowanego raportu do aplikacji przesyłającej żądanie bez wyraźnej zgody użytkownika.
• [C-1-4] Raporty wygenerowane za pomocą BUGREPORT_MODE_TELEPHONY MUSZĄ zawierać co najmniej te informacje:
  • TelephonyDebugService zrzut
  • TelephonyRegistry zrzut
  • WifiService zrzut
  • ConnectivityService zrzut
  • Dump instancji CarrierService pakietu wywołującego (jeśli jest powiązany)
  • Bufor dziennika radiowego
• [C-1-5] W wygenerowanych raportach NIE MOŻNA uwzględniać tych informacji:
  • wszelkie informacje, które nie są bezpośrednio związane z debugowaniem połączeń;
  • dowolne dzienniki ruchu 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 tożsamością użytkownika. (np. logi dostawcy).

Jeśli implementacje urządzeń zawierają dodatkowe informacje (np. dzienniki dostawcy) w raportach o błędach, a informacje te mają wpływ na prywatność, bezpieczeństwo, baterię, pamięć lub pamięć masową, należy:

• [C-SR-1] ZALECAMY, aby ustawienie programisty było domyślnie wyłączone. Implementacja referencyjna AOSP spełnia to wymaganie, ponieważ udostępnia Enable verbose vendor loggingopcję w ustawieniach dewelopera, 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ą interfejsu BlobStoreManager umożliwia aplikacjom udostępnianie blobów danych systemowi, aby udostępnić je wybranym aplikacjom.

Jeśli implementacje urządzeń obsługują wspólne bloki danych zgodnie z opisem w dokumentacji pakietu SDK, to:

• [C-1-1] NIE wolno udostępniać blobów danych należących do aplikacji poza zakresem dozwolonym (czyli zakres dostępu domyślnego i innych trybów dostępu, które można określić za pomocą metod BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() lub BlobStoreManager.session#allowPublicAccess(). Nie wolno ich modyfikować). Implementacja referencyjna AOSP spełnia te wymagania.
• [C-1-2] NIE MOŻESZ wysyłać z urządzenia ani udostępniać innym aplikacjom bezpiecznych haszy blobów danych (które są używane do kontrolowania dostępu).

9.8.12. Rozpoznawanie muzyki

Android, za pomocą interfejsu System API MusicRecognitionManager, obsługuje mechanizm umożliwiający implementacje urządzeń do żądania rozpoznawania muzyki na podstawie nagrania audio i przekazywania rozpoznawania muzyki do aplikacji uprzywilejowanej, która implementuje interfejs MusicRecognitionService API.

Jeśli implementacje na urządzeniu obejmują usługę, która implementuje interfejs API systemu MusicRecognitionManager, lub dowolną zastrzeżoną usługę przesyłającą strumieniowo dane audio zgodnie z opisem powyżej, to:

• [C-1-1] Należy wymusić, aby wywołujący MusicRecognitionManager miał uprawnienia MANAGE_MUSIC_RECOGNITION
• [C-1-2] NALEŻY wymagać, aby jedna wstępnie zainstalowana aplikacja do rozpoznawania muzyki implementowała interfejs MusicRecognitionService.
• [C-1-3] Nie wolno zezwalać użytkownikom na zastępowanie usługi MusicRecognitionManagerService lub MusicRecognitionService aplikacją lub usługą instalowaną przez użytkownika.
• [C-1-4] NALEŻY zadbać o to, aby gdy MusicRecognitionManagerService uzyskuje dostęp do nagrania audio i przesyła je do aplikacji implementującej MusicRecognitionService, dostęp do dźwięku był śledzony za pomocą wywołań AppOpsManager.noteOp / startOp.

Jeśli implementacje MusicRecognitionManagerService lub MusicRecognitionService na urządzeniu przechowują jakiekolwiek dane audio, to:

• [C-2-1] Nie wolno przechowywać na dysku żadnych nieprzetworzonych plików audio ani odcisków audio ani w pamięci przez dłużej niż 14 dni.
• [C-2-2] NIE MOŻESZ udostępniać takich danych poza MusicRecognitionService, chyba że użytkownik wyrazi na to wyraźną zgodę za każdym razem.

9.8.13. SensorPrivacyManager

Jeśli implementacja urządzenia umożliwia użytkownikowi wyłączenie wejścia z kamery lub mikrofonu, to:

• [C-1-1] W przypadku odpowiedniej metody interfejsu API supportsSensorToggle() MUSI zwracać wartość „prawda”.
• [C-1-2] Gdy aplikacja próbuje uzyskać dostęp do zablokowanego mikrofonu lub aparatu, MUSI wyświetlić użytkownikowi nieusuwalny element interfejsu, który wyraźnie wskazuje, że czujnik jest zablokowany, oraz wymaga podjęcia decyzji o dalszym blokowaniu lub odblokowaniu zgodnie z implementacją AOSP, która spełnia ten wymóg.
• [C-1-3] Do aplikacji muszą być przekazywane tylko puste (lub fałszywe) dane z kamery i dźwięku. Nie wolno zgłaszać kodu błędu z powodu braku włączenia przez użytkownika kamery ani mikrofonu za pomocą interfejsu użytkownika przedstawionego w sekcji [C-1-2] powyżej.

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 zawarte w sekcji 9.9 dokumentu Definicja zgodności Androida odpowiadającej 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ą 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ą szyfrowane miejsca na dane urządzenia (DE) i szyfrowane miejsca na dane poświadczeń (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 konfigurację urządzenia.

• [C-0-3] NALEŻY spełniać powyższy wymóg szyfrowania danych, stosują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 pytania użytkownika o dane logowania i umożliwiać aplikacjom obsługującym bezpośrednie uruchamianie dostęp do zaszyfrowanej pamięci urządzenia (DE) po przesłaniu wiadomości 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 gdy zostanie wysłane powiadomienie ACTION_USER_UNLOCKED.
• [C-1-13] NIE MOŻESZ oferować żadnej metody odblokowania chronionego magazynu CE bez podania danych logowania użytkownika, zarejestrowanego klucza powiernikowego lub wznowienia po restarcie, które spełnia wymagania podane 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, to:

• [C-1-5] NALEŻY zaszyfrować zawartość pliku i metadane systemu plików za pomocą AES-256-XTS lub Adiantum. AES-256-XTS odnosi się do standardu Advanced Encryption Standard z 256-bitowym kluczem szyfrowania, który działa w trybie XTS; pełna długość klucza to 512 bitów. Adiantum oznacza 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 szyfrowania 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 kryptograficznie i nieodwracalnej funkcji derywacji klucza (np. HKDF-SHA512), aby wyprowadzić dowolne klucze podrzędne (np. klucze na poziomie pliku) z kluczy CE i DE. „Silnie szyfrowane i nieodwracalne” oznacza, że funkcja derywacji klucza ma moc szyfrowania co najmniej 256 bitów i działa jako rodzina funkcji pseudolosowych na swoich danych wejściowych.
• [C-1-14] NIE wolno używać tych samych kluczy szyfrowania opartego na plikach (FBE) lub podkluczy do różnych celów kryptograficznych (np. do szyfrowania i wyprowadzania kluczy lub do dwóch różnych algorytmów szyfrowania).
• [C-1-15] NALEŻY zadbać o to, aby wszystkie nieusunięte bloki zaszyfrowanej zawartości pliku w trwałym miejscu przechowywania były zaszyfrowane za pomocą kombinacji klucza szyfrowania i wektora inicjalizacji (IV), które zależą zarówno od pliku, jak i od przesunięcia w pliku. Ponadto wszystkie takie kombinacje MUSZĄ być różne, z wyjątkiem sytuacji, gdy szyfrowanie jest wykonywane za pomocą sprzętowego szyfrowania w internecie, które obsługuje tylko długość IV wynoszącą 32 bity.
• [C-1-16] NALEŻY zadbać o to, aby wszystkie nieusunięte zaszyfrowane nazwy plików w trwałym magazynie w różnych katalogach zostały zaszyfrowane przy użyciu różnych kombinacji klucza szyfrującego i wektora inicjującego (IV).

• [C-1-17] NALEŻY zadbać o to, aby wszystkie zaszyfrowane bloki metadanych systemu plików w trwałym magazynie były szyfrowane za pomocą różnych kombinacji klucza szyfrowania i wektora inicjalizacji (IV).

• 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 sprzętowym katalogiem zaufania 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 ma nieokreślone dane logowania do ekranu blokady.
  • [C-1-10] MUSI być unikalny i różnić się od kluczy CE lub DE innych użytkowników.
  • [C-1-11] NALEŻY używać szyfrów, długości kluczy i trybów obsługiwanych obligatoryjnie.
  • [C-1-12] NALEŻY je bezpiecznie usunąć podczas odblokowywania i blokowania programu rozruchowego w sposób opisany tutaj.

• NALEŻY zadbać o to, aby wbudowane niezbędne aplikacje (np. Alarm, Telefon, Messenger) były świadome bezpośredniego uruchamiania.

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] MUSI zawierać partycje dla poszczególnych użytkowników, używając partycji nieprzetworzonych lub woluminów logicznych.
• [C-1-3] NALEŻY używać unikalnych i różnych kluczy szyfrowania na potrzeby szyfrowania poszczególnych użytkowników na urządzeniach blokowych.

• [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 sprzętowym katalogiem zaufania 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 Linux „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. Ta funkcja umożliwia użytkownikom otrzymywanie powiadomień 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 wewnętrznych zagrożeń zakładamy też, że atakujący uzyska dostęp do kluczy 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. W efekcie ma ona te możliwości i 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żna uzyskać danych logowania użytkownika (kodu PIN, wzoru lub hasła) ani w inny sposób spowodować ich wpisania.

Na przykład implementacja urządzenia, która implementuje i przestrzega wszystkich opisów podanych 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] MUST correctly report through the System API method PersistentDataBlockManager.getFlashLockState() whether their bootloader state permits flashing of the system image.

• [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ż ta wymagana 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 silnym poziomie bezpieczeństwa, jak to wynika z aktualnych zaleceń NIST dotyczących algorytmów szyfrowania (SHA-256) i rozmiarów kluczy publicznych (RSA-2048).
• [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 przypadku NIE wolno używać danych z niezatwierdzonych 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-1] Jeśli na urządzeniu jest kilka oddzielnych układów (np. radio, wyspecjalizowany procesor obrazu), MOCNO POLECAMY sprawdzenie każdego etapu podczas uruchamiania.
• [C-1-8] NALEŻY używać pamięci z funkcją wykrywania manipulacji: do przechowywania informacji o tym, czy bootloader jest odblokowany. 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 w przypadku partycji używanych przez Androida (np. partycji rozruchu, partycji systemowych) oraz używać magazynu z funkcją wykrywania próby manipulacji do przechowywania metadanych służących do określania minimalnej dozwolonej wersji systemu operacyjnego.
• [C-1-11] NALEŻY bezpiecznie usunąć wszystkie dane użytkownika podczas odblokowywania i blokowania programu rozruchowego zgodnie z sekcją 9.12. „Usuwanie danych” (w tym partycji userdata i dowolnych obszarach NVRAM).
• [C-SR-2] MOCNO ZALECAMY weryfikowanie wszystkich plików APK aplikacji z dostępem uprzywilejowanym za pomocą łańcucha zaufania z korzeniami w partycjach chronionych przez weryfikowany rozruch.
• [C-SR-3] MOCNO ZALECAMY weryfikowanie wszystkich artefaktów wykonywalnych wczytywanych przez aplikację uprzywilejowaną spoza pliku APK (np. kodu wczytywanego dynamicznie lub skompilowanego kodu) przed ich wykonaniem lub 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 układowym (np. modemu lub kamery) oraz NALEŻY użyć pamięci z funkcją ochrony przed nieuprawnionym dostępem do przechowywania metadanych używanych do określania minimalnej dozwolonej wersji.

Jeśli implementacje urządzeń zostały już uruchomione bez obsługi wymagań C-1-8 do C-1-11 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 za pomocą zaufanych kluczy bez odczytywania całego pliku.
• [C-0-4] NIE NALEŻY 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ż wdrożone 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 preferowane wdrożenie tej funkcji na podstawie funkcji fs-verity jądra Linuksa.

Implementacje na urządzeniu:

• [C-SR-4] MOCNO zalecamy obsługę interfejsu Android Protected Confirmation API.

Jeśli implementacje na urządzeniach obsługują interfejs API Protected Confirmation na Androida, to:

• [C-3-1] MUST report true for the ConfirmationPrompt.isSupported() API.

• [C-3-2] NALEŻY zadbać o to, aby kod działający w systemie operacyjnym Android, w tym jego jądro, złośliwe lub inne, 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 jeśli 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 implementować interwał czasowy między nieudanymi próbami. Jeśli n to liczba nieudanych prób, to w przypadku 9 < n < 30 interwał czasowy MUSI wynosić co najmniej 30 sekund. W przypadku wartości n > 29 wartość przedziału czasowego MUSI wynosić co najmniej 30*2^floor((n-30)/10)) sekund lub co najmniej 24 godziny, zależnie od tego, która z tych wartości jest mniejsza.
• 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] MUSI zawierać 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 jądro lub kod w przestrzeni użytkownika mogą uzyskać dostęp do wewnętrznego stanu odizolowanego środowiska, w tym DMA. Projekt Android Open Source (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest też 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 po pomyślnym uwierzytelnieniu. Dane logowania 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.
• [C-1-4] MUSI obsługiwać atestakcję klucza, w której klucz do podpisywania 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 zapobiec ich wykorzystaniu 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, na każde 100 tys. jednostek MOŻE być używany inny klucz.

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

• [C-1-5] NALEŻY umożliwić użytkownikowi wybranie czasu bezczynności w trybie uśpienia podczas przechodzenia z otwartego stanu na zamknięty, z minimalnym dozwolonym czasem do 15 sekund. Urządzenia samochodowe, które blokują ekran, gdy wyłącza się jednostka główna lub gdy użytkownik zmieni się, MOGĄ NIE mieć konfiguracji uśpienia.
• [C-1-6] Musi obsługiwać jedną z tych opcji:
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1 lub
  • IKeyMintDevice w wersji 1.
• [C-SR-1] ZDECYDOWANIE POLECAMY obsługę urządzenia IKeyMint w wersji 1.

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 trzeciorzędowe.

Implementacje na urządzeniu:

• [C-SR-1] MOCNO ZALECAMY skonfigurowanie 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 na urządzeniach dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, oparte na znanym kluczu tajnym i używają nowej metody uwierzytelniania, która ma być traktowana jako bezpieczny sposób blokowania ekranu:

• [C-3-1] Entropia najkrótszych dozwolonych długości danych wejściowych MUSI być większa niż 10 bitów.
• [C-3-2] Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18 bitów.
• [C-3-3] Nowa metoda uwierzytelniania NIE MOŻE zastąpić żadnej z zalecanych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) zaimplementowanych i dostępnych w AOSP.
• [C-3-4] Nowa metoda uwierzytelniania MUSI zostać wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawia zasady dotyczące haseł za pomocą metody DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjną stałą złożoności niż PASSWORD_COMPLEXITY_NONE lub za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] Nowe metody uwierzytelniania MUSZĄ co 72 godziny lub rzadziej stosować zalecane podstawowe metody uwierzytelniania (np. kod PIN, wzór lub 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 metody uwierzytelniania, aby odblokować ekran blokady i użyć 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ącej klasy 1 (dawniej wygoda).
• [C-4-2] MUSI zawierać mechanizm zapasowy umożliwiający korzystanie z jednej z zalecanych metod uwierzytelniania podstawowego opartego na znanym kluczu tajnym.
• [C-4-3] MUSI być wyłączona i zezwalać tylko na zalecaną metodę uwierzytelniania pierwotnego do odblokowania ekranu, gdy aplikacja Device Policy Controller (DPC) ustawiła zasady funkcji zabezpieczenia ekranu głównego, 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 silnego), o których mowa w sekcji 7.3.10:

• [C-5-1] Metody MUSZĄ być wyłączone, jeśli aplikacja kontrolera zasad urządzenia (DPC) ma ustawioną politykę jakości haseł za pomocą metody DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjnym zasobnikiem złożoności niż PASSWORD_COMPLEXITY_LOW lub za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Należy poprosić użytkownika o podanie danych do logowania (np. kodu PIN, wzoru lub hasła) w ramach zalecanego głównego uwierzytelniania, jak opisano w [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] Musisz mieć 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 ekranu blokady.
• [C-6-2] Nowa metoda MUSI być wyłączona i zezwalać tylko na jedną z zalecanych metod uwierzytelniania, aby odblokować ekran, gdy aplikacja Device Policy Controller (DPC) skonfigurowała zasadę za pomocą:
  • Metoda DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
  • Metoda DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_NONE.
  • Metoda DevicePolicyManager.setRequiredPasswordComplexity(), która ma bardziej restrykcyjny zakres złożoności niż PASSWORD_COMPLEXITY_NONE.
• [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 spełniać ograniczenia wymienione w sekcji C-8 poniżej.

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 opóźniona lub może zostać odblokowana przez zaufanego agenta. Na przykład AOSP spełnia ten wymóg, wyświetlając w menu ustawień opis opcji „Automatyczne blokowanie” i „Przycisk zasilania natychmiast blokuje” oraz wyróżniającą się ikonę na ekranie blokady.
• [C-7-2] MUSISZ przestrzegać i w pełni wdrażać wszystkie interfejsy API zaufanego agenta w klasie DevicePolicyManager, takie jak stała KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NIE NALEŻY w pełni wdrażać funkcji TrustAgentService.addEscrowToken() na urządzeniu używanym jako podstawowe urządzenie osobiste (np. 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 służyć do odblokowania konta użytkownika na telewizorze. W przypadku urządzeń Automotive nie można przechowywać tokena powiernikowego w żadnej części pojazdu.
• [C-7-6] NALEŻY poinformować użytkownika o konsekwencjach włączenia tokena powiernikowego do odszyfrowywania 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 przy użyciu jednej z zalecanych metod uwierzytelniania (np.kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny, chyba że chodzi o bezpieczeństwo użytkownika (np. rozproszenie uwagi kierowcy).
• [C-7-9] Użytkownik MUSI zostać poproszony o podanie danych uwierzytelniających za pomocą jednej z zalecanych metod uwierzytelniania (np.kodu PIN, wzoru lub hasła) opisanych w punktach [C-1-7] i [C-1-8] w sekcji 7.3.10, chyba że chodzi o bezpieczeństwo użytkownika (np. rozproszenie uwagi 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 NALEŻY zezwalać zaufanym agentom na głównych urządzeniach osobistych (np. urządzeniach przenośnych) na odblokowywanie urządzenia. Można ich używać 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 do przechowywania na urządzenie docelowe.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, który nie jest ekranem blokady zabezpieczonej zgodnie z opisem powyżej, i używają nowej metody uwierzytelniania do odblokowania ekranu blokady klawiatury:

• [C-8-1] Nowa metoda MUSI być wyłączona, gdy aplikacja Device Policy Controller (DPC) ustawiła zasady jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_NONE lub za pomocą metody DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjną stałą złożoności niż „PASSWORD_COMPLEXITY_NONE”.
• [C-8-2] Nie wolno resetować liczników czasu ważności hasła ustawionych przez DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] Nie wolno udostępniać interfejsu API aplikacjom innych firm do zmiany stanu blokady.

Jeśli implementacje urządzeń obsługują oddzielne stany zasilania ekranu za pomocą DeviceStateManager I obsługują oddzielne stany blokowania ekranu za pomocą KeyguardDisplayManager, to:

• [C-SR-2] ZALECAMY stosowanie danych logowania spełniających wymagania określone w sekcji 9.11.1 lub danych biometrycznych spełniających co najmniej wymagania klasy 1 określone w sekcji 7.3.10, aby umożliwić niezależne odblokowywanie z poziomu domyślnego ekranu urządzenia.
• [C-SR-3] ZALECAMY ograniczenie możliwości odblokowania wyświetlacza za pomocą osobnego przycisku za pomocą zdefiniowanego czasu oczekiwania wyświetlacza.
• [C-SR-4] ZALECAMY, aby umożliwić użytkownikowi globalne blokowanie wszystkich wyświetlaczy za pomocą blokady na głównym urządzeniu przenośnym.

9.11.2. StrongBox

System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych na dedykowanym bezpiecznym procesorze, a także w odizolowanym środowisku wykonywania opisanym powyżej. Taki dedykowany bezpieczny procesor nazywa się „StrongBox”. Wymagania C-1–3 do C-1–11 określają wymagania, które musi spełniać urządzenie, aby kwalifikować się jako StrongBox.

Implementacje urządzeń z dedykowanym bezpiecznym procesorem:

• [C-SR-1] Zdecydowanie zalecamy obsługę StrongBox. W przyszłej wersji StrongBox prawdopodobnie stanie się wymagany.

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

• [C-1-1] NALEŻY zadeklarować FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] MUSI zawierać specjalny sprzęt zabezpieczający, który służy do tworzenia kopii zapasowych magazynu kluczy i zabezpieczonego uwierzytelniania użytkownika. Specjalny bezpieczny sprzęt może być używany również do innych celów.

• [C-1-3] Musi zawierać procesor, który nie udostępnia pamięci podręcznej, DRAM, procesorów pomocniczych ani innych podstawowych zasobów procesorowi aplikacji (AP).

• [C-1-4] NALEŻY zadbać o to, aby żadne urządzenia peryferyjne udostępnione AP nie mogły w żaden sposób zmieniać przetwarzania StrongBox ani uzyskiwać ż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] Musisz mieć prawdziwy generator liczb losowych, który generuje dane o jednolitej dystrybucji i nieprzewidywalne wyniki.

• [C-1-7] MUSI być odporny na próby manipulacji, w tym na włamanie się do niego fizycznie i na zakłócanie.

• [C-1-8] MUSI zapewniać odporność na kanały boczne, w tym na wyciek informacji przez kanały zasilania, czasu, promieniowania elektromagnetycznego i cieplnego.

• [C-1-9] Musisz mieć bezpieczne miejsce przechowywania, które zapewnia poufność, integralność, autentyczność, spójność i aktualność 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], wdrożenia na urządzeniu:

  • [C-1-10] MUSI zawierać sprzęt z certyfikatem zgodnym z profilem ochrony IC BSI-CC-PP-0084-2014 lub oceniony przez akredytowane na poziomie krajowym laboratorium testowe, uwzględniając ocenę podatności na ataki o wysokim potencjale zgodnie z kryteriami Common Criteria dotyczącymi potencjalnego ataku na karty inteligentne.
  • [C-1-11] Musi zawierać oprogramowanie sprzętowe, które zostało ocenione przez akredytowane na poziomie krajowym laboratorium testowe, uwzględniające ocenę podatności na ataki o wysokim potencjale zgodnie z Common Criteria Application of Attack Potential to Smartcards.
  • [C-SR-2] MOCNO zalecamy uwzględnienie sprzętu, który został oceniony za pomocą Security Target, Evaluation Assurance Level (EAL) 5, uzupełnionego o AVA_VAN.5. Certyfikat EAL 5 prawdopodobnie stanie się wymagany w kolejnych wersjach.

• [C-SR-3] MOCNO POLECAMY, aby zapewnić odporność na ataki z wewnątrz (IAR). Oznacza to, że osoba z dostępem do kluczy podpisywania oprogramowania układowego nie może wygenerować oprogramowania układowego, które powoduje wyciek tajemnic w StrongBox, umożliwia obejście wymagań bezpieczeństwa funkcjonalnego lub w inny sposób umożliwia dostęp do poufnych danych użytkownika. Zalecaną metodą implementacji IAR jest zezwalanie na aktualizacje oprogramowania 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 zdefiniowany i osiągnięty 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żytkownika. Implementacje na urządzeniu:

• [C-SR-1] MOCNO ZALECAMY zaimplementowanie systemu tożsamości.

Jeśli implementacje urządzeń korzystają z systemu danych uwierzytelniających tożsamości, muszą:

• [C-1-1] W przypadku metody IdentityCredentialStore#getInstance() musi zwracać wartość inną niż null.

• [C-1-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-1-3] Operacje kryptograficzne potrzebne do wdrożenia systemu tożsamości i poświadczeń (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 wymagane przez interfejsy API wyższego poziomu (np. metoda createEphemeralKeyPair()).

• [C-1-4] Zaufana aplikacja MUSI być zaimplementowana w taki sposób, aby nie wpływało to na jej właściwości zabezpieczeń (np. dane uwierzytelniające nie są ujawniane, 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] Podczas wykonywania „przywracania danych do ustawień fabrycznych” 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, podczas wykonywania „resetu danych fabrycznych”.
• [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, zwany „trybem bezpiecznego uruchamiania”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.

Implementacje na urządzeniach:

• [C-SR-1] ZDECYDOWANIE POLECAMY wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacja urządzenia obejmuje tryb bezpiecznego uruchamiania, to:

• [C-1-1] NALEŻY zapewnić użytkownikowi opcję uruchomienia 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 na wartość prawda.

• [C-1-2] Musisz umożliwić użytkownikowi odinstalowanie aplikacji innych firm w trybie awaryjnym.

• 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 powinny wymieniać dane z podsystemami pojazdu za pomocą interfejsu HAL pojazdu do wysyłania i odbierania wiadomości w sieciach pojazdu, takich jak magistrala CAN.

Wymiana danych może być zabezpieczona przez wdrożenie funkcji bezpieczeństwa poniżej warstw platformy Android, aby zapobiec złośliwej lub niezamierzonej interakcji z tymi podsystemami.

9.15. Plany abonamentowe

„Abonamenty” to szczegóły planu rozliczeniowego udostępnione 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ą kopiowanych 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 Zabezpieczenia 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ą autentycznymi 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ń wprowadzenie jak najmniejszej liczby zmian w dostępnej w ramach Projektu Android Open Source referencyjnej i preferowanej implementacji Androida. Pozwoli to zminimalizować ryzyko wprowadzenia błędów, które powodują niezgodności i wymagają ponownego wykonania pracy oraz potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje na urządzeniu:

• [C-0-1] Musisz przejść testy zgodności Androida (Compatibility Test Suite, CTS) dostępne w ramach projektu Android Open Source, używając oprogramowania na urządzeniu w wersji przeznaczonej do wysyłki.

• [C-0-2] Musisz 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ą wydawane niezależnie od tej definicji zgodności, a w przypadku Androida 12 może być udostępnionych kilka 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 częścią pakietu Compatibility Test Suite i ma być uruchamiane przez operatora w celu testowania funkcji, których nie można przetestować za pomocą automatycznego systemu, takich jak prawidłowe działanie 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 funkcji oznaczonych w tym dokumencie z definicją 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 test CTS Verifier, tylko pod względem zestawu 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 umożliwiający zastąpienie całego oprogramowania systemowego. Mechanizm nie musi wykonywać aktualizacji „na żywo”, czyli może być konieczne ponowne uruchomienie urządzenia. Można użyć dowolnej metody, o ile pozwala ona na zastąpienie całego wstępnie zainstalowanego oprogramowania na urządzeniu. Na przykład każde z tych rozwiązań spełnia to wymaganie:

  • „Over-the-air (OTA)” – pobieranie z aktualizacją offline po ponownym uruchomieniu.
  • „Przywiązane” aktualizacje przez USB z komputera hosta.
  • „Offline” aktualizacje przez ponowne uruchomienie i aktualizację z pliku na pamięci wymiennej.

• [C-0-2] Używany mechanizm aktualizacji MUSI obsługiwać aktualizacje bez kasowania danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachować dane prywatne aplikacji i dane udostępnione przez aplikację. Pamiętaj, że oprogramowanie Androida na poziomie upstream 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-1] W ramach mechanizmu podpisywania BARDZO ZALECAMY stosowanie szyfrowania SHA-256 i weryfikowania skrótu za pomocą klucza publicznego przy użyciu 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), to:

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

Implementacje urządzeń powinny weryfikować, czy obraz systemu jest identyczny z oczekiwanym wynikiem po aktualizacji OTA. Ten wymóg spełnia implementacja OTA na podstawie bloków w upstreamowym projekcie Android Open Source, dodana od wersji Android 5.1.

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 zostanie w nim znaleziony błąd, który wpływa na zgodność aplikacji innych firm, ale w rozsądnym okresie użytkowania urządzenia (określonym w konsultacji z zespołem ds. zgodności Androida), należy:

• [C-2-1] Implementator urządzenia MUSI poprawić błąd za pomocą dostępnej 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ń zgłasza android.software.device_admin, to:

• [C-3-1] NALEŻY zaimplementować działanie 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:

1. Wprowadzenie
2. Typy urządzeń
3. Oprogramowanie
4. Opakowanie aplikacji
5. Multimedia
6. Narzędzia i opcje dla programistów
7. Zgodność sprzętowa
8. Wydajność i moc
9. Model zabezpieczeń
10. Testowanie zgodności oprogramowania
11. Oprogramowanie z możliwością aktualizacji
12. Historia zmian dokumentu
13. Skontaktuj się z nami

12.1. Wskazówki dotyczące wyświetlania historii zmian

Zmiany są oznaczone w ten sposób:

• CDD
  Zmiany w wymaganiach 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 zmian.

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 nie zostały opisane w dokumencie.