Definicja zgodności z Androidem 12

1. Wprowadzenie

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

Odpowiedzi „MUST”, „MUST” (MUSZĄ), „WYMAGANE”, „WYMAGANE”, „SHALL” (NIE BĘDĄ), „POWINNO”, „NIE POWINNY”, „ZALECANE”, „MOŻE” oraz „OPCJONALNIE” są zgodne ze standardem IETF zdefiniowanym w RFC2119.

W tym dokumencie „implementator urządzeń” to osoba lub organizacja opracowująca sprzętowo/oprogramowanie na Androida 12. „Implementacja na urządzeniu” to tak opracowane rozwiązanie sprzętowe i oprogramowania.

Aby zostały uznane za zgodne z Androidem 12, wdrożenia na urządzeniu MUSZĄ spełniać wymagania przedstawione w tej definicji zgodności, w tym wszystkie dokumenty dołączone przez odniesienie.

Jeśli ta definicja lub testy oprogramowania opisane w sekcji 10 są dyskretne, niejednoznaczne lub niepełne, to osoba implementująca urządzenie odpowiada za zgodność z dotychczasowymi implementacjami.

Dlatego Android Open Source Project jest zarówno referencją, jak i preferowaną implementacją Androida. Zdecydowanie ZALECANE jest oprzeć swoje wdrożenia na kodach źródłowych projektu, które są częścią projektu Android Open Source. Chociaż niektóre komponenty można hipotetycznie zastąpić alternatywnymi implementacjami, Zdecydowanie zaleca się nie stosować tej praktyki, ponieważ zaliczenie testów oprogramowania będzie znacznie trudniejsze. Odpowiada on za zapewnienie pełnej zgodności ze standardową implementacją Androida, w tym z pakietem Compatibility Test Suite i nie tylko. Niektóre podstawienia 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 Android SDK i będzie działać tak samo jak informacje podane w dokumentacji pakietu SDK. W każdym przypadku, gdy ta definicja zgodności lub pakiet Compatibility Test Suite nie zgadza się z dokumentacją pakietu SDK, uznaje się, że dokumentacja pakietu SDK jest miarodajna. Wszelkie szczegóły techniczne wymienione w zasobach połączonych 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 podsekcja w sekcji 2 jest poświęcona konkretnemu typowi urządzenia.

Wszystkie pozostałe wymagania, które obowiązują we wszystkich implementacjach urządzeń z Androidem, zostały wymienione w sekcjach po Sekcji 2. Wymagania te są nazywane w tym dokumencie „wymaganiami podstawowymi”.

1.1.2 Identyfikator wymagania

W przypadku wymagań MUSZĄ przypisano identyfikator wymagania.

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

Każdy identyfikator jest zdefiniowany poniżej:

• Identyfikator typu urządzenia (więcej informacji znajdziesz w sekcji 2. typy urządzeń)
  • C: podstawowy (wymagania dotyczące wszystkich implementacji na urządzeniach z Androidem)
  • H: przenośne urządzenie z Androidem
  • T: urządzenie z Androidem TV
  • O: Wdrożenie Androida Automotive
  • W: Implementacja na zegarku Android Watch
  • Karta: Implementacja na tabletach z Androidem
• Identyfikator warunku
  • Gdy wymaganie jest bezwarunkowe, ten identyfikator ma wartość 0.
  • Gdy wymaganie jest warunkowe, do pierwszego warunku zostaje przypisana wartość 1, a liczba zwiększa się o 1 w tej samej sekcji i na tym samym typie urządzenia.
• Identyfikator wymagania
  • Ten identyfikator rozpoczyna się od 1 i zwiększa o 1 w tej samej sekcji i w tym samym warunku.

1.1.3 Identyfikator wymagania w sekcji 2

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

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

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

2. Typy urządzeń

Android Open Source Project zapewnia pakiet oprogramowania, z którego można korzystać na różnych typach urządzeń i formatach. Z myślą o zapewnieniu bezpieczeństwa urządzeń system oprogramowania, w tym każdy zastępczy system operacyjny lub alternatywna implementacja jądra systemu, powinien uruchamiać się w bezpiecznym środowisku zgodnie z opisem w sekcji 9 i innych częściach tego CDD. Istnieje kilka typów urządzeń, które mają względnie lepiej ugruntowany ekosystem dystrybucji aplikacji.

W tej sekcji znajdziesz opis tych typów 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 wymienione w pozostałych sekcjach tej definicji zgodności.

2.1 Konfiguracje urządzeń

Informacje o głównych różnicach w konfiguracji sprzętu w zależności od typu urządzenia znajdziesz w podanych niżej wymaganiach dotyczących poszczególnych urządzeń.

2.2. Wymagania dotyczące urządzenia mobilnego

Przenośne urządzenie z Androidem to implementacja urządzenia z Androidem, w którym zazwyczaj trzymasz urządzenie w dłoni, np. odtwarzacz mp3, telefon czy tablet.

Implementacje na urządzeniach z Androidem zaliczamy do urządzeń mobilnych, jeśli spełniają wszystkie te kryteria:

• mieć źródło zasilania, które pozwala na mobilność, np. baterię.
• mieć ekran o przekątnej fizycznej w zakresie od 3,3 cala (lub 2,5 cala w przypadku implementacji na poziomie interfejsu API 29 lub starszym) do 8 cali.

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

2.2.1. Urządzenie

Implementacje na urządzeniach mobilnych:

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

• [7.1.1.3/H-SR-1] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości zmiany rozmiaru wyświetlacza (gęstości ekranu).

• [7.1.1.1/H-0-2] MUSI obsługiwać kompozycję GPU w buforach graficznych o rozmiarze co najmniej odpowiadającym najwyższej rozdzielczości wbudowanym wyświetlaczowi.

Jeśli implementacje urządzeń mobilnych obsługują obracanie ekranu za pomocą oprogramowania, umożliwiają one:

• [7.1.1.1/H-1-1]* Ekran logiczny udostępniany aplikacjom innych firm MUSI mieć co najmniej 2 cale od krótszej krawędzi i 2,7 cala od dłuższej. Urządzenia wysłane z wykorzystaniem interfejsu Android API na poziomie 29 lub starszym mogą zostać zwolnione z tego wymogu.

Jeśli implementacje urządzeń mobilnych nie obsługują programowego obracania ekranu:

• [7.1.1.1/H-2-1]* Ekran logiczny udostępniany aplikacjom innych firm MUSI mieć co najmniej 2,7 cala od krótszej krawędzi. Urządzenia wysłane z wykorzystaniem interfejsu Android API na poziomie 29 lub starszym mogą zostać zwolnione z tego wymogu.

Jeśli implementacje na urządzeniach mobilnych twierdzą, że obsługują wyświetlacz o wysokim zakresie dynamiki (Configuration.isScreenHdr() ), oznacza to, że:

• [7.1.4.5/H-1-1] MUSI reklamować wsparcie 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 mobilnych:

• [7.1.4.6/H-0-1] MUSI podawać za pomocą właściwości systemowej graphics.gpu.profiler.support informację, czy urządzenie obsługuje możliwość profilowania GPU.

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

• [7.1.4.6/H-1-1] MUSI generować raport jako ślad protokołu zgodny ze schematem liczników GPU i procesów renderowania GPU zdefiniowanych w dokumentacji Perfetto.
• [7.1.4.6/H-1-2] MUSI zgłaszać zgodne wartości dla liczników GPU urządzenia po protoku pakietu śledzenia licznika GPU.
• [7.1.4.6/H-1-3] MUSI zgłaszać zgodne wartości dotyczące procesu renderowania GPU urządzenia po protokole śledzenia pakietu śledzenia etapu renderowania.
• [7.1.4.6/H-1-4] MUSI zgłaszać punkt śledzenia częstotliwości GPU w formacie power/gpu_frequency.

Implementacje na urządzeniach mobilnych:

• [7.1.5/H-0-1] MUSI obsługiwać starszy tryb zgodności aplikacji w obecnej wersji kodu open source Androida. Oznacza to, że implementacje urządzenia NIE MOGĄ zmieniać wyzwalaczy ani progów, przy których włączony jest tryb zgodności. NIE MOGĄ też zmieniać działania samego trybu zgodności.
• [7.2.1/H-0-1] MUSI obsługiwać zewnętrzne aplikacje edytora metody wprowadzania (IME).
• [7.2.3/H-0-3] MUSI zapewniać funkcję ekranu głównego na wszystkich wyświetlaczach zgodnych z Androidem, które obsługują ekran główny.
• [7.2.3/H-0-4] MUSI zapewniać funkcję Wstecz na wszystkich wyświetlaczach zgodnych z Androidem, a funkcję Ostatnie na co najmniej jednym z wyświetlaczy zgodnych z Androidem.
• [7.2.3/H-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno normalne, jak i przytrzymane naciśnięcie funkcji Wstecz (KEYCODE_BACK). System nie może wykorzystywać tych zdarzeń i MOGĄ być wywoływane przez inne urządzenia (np. zewnętrzną klawiaturę sprzętową podłączoną do urządzenia z Androidem).
• [7.2.4/H-0-1] MUSI obsługiwać wprowadzanie na ekranie dotykowym.
• [7.2.4/H-SR-1] Zdecydowanie ZALECANE jest uruchomienie aplikacji asystującej wybranej przez użytkownika, czyli aplikacji obsługującej VoiceInteractionService lub działania obsługującego funkcję ACTION_ASSIST po przytrzymaniu przycisku KEYCODE_MEDIA_PLAY_PAUSE lub KEYCODE_HEADSETHOOK, jeśli aktywność na pierwszym planie nie obsługuje zdarzeń przytrzymania.
• [7.3.1/H-SR-1] Zdecydowanie ZALECANE jest dodanie 3-osiowego akcelerometru.

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

• [7.3.1/H-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 100 Hz.

Jeśli implementacje urządzeń mobilnych obejmują odbiornik GPS/GNSS i zgłaszają możliwość korzystania z aplikacji za pomocą flagi funkcji android.hardware.location.gps, to:

• [7.3.3/H-2-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną wykryte, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie jest jeszcze raportowana.
• [7.3.3/H-2-2] MUSI zgłaszać pseudozakresy i częstotliwości pseudozakresowe GNSS, że w warunkach na otwartym niebie po określeniu lokalizacji, gdy ruch jest stały lub porusza się z przyspieszeniem poniżej 0,2 metra na sekundę do kwadratu, wystarczy do obliczenia pozycji z dokładnością do 20 metrów z dokładnością do 5% z dokładnością do 5% w czasie.

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

• [7.3.4/H-3-1] MUSI raportować zdarzenia z częstotliwością co najmniej 100 Hz.
• [7.3.4/H-3-2] MUSI być w stanie mierzyć zmiany orientacji ekranu z dokładnością do 1000 stopni na sekundę.

Implementacje urządzeń mobilnych, które umożliwiają wykonywanie połączeń głosowych i wskazują dowolną wartość inną niż PHONE_TYPE_NONE w getPhoneType:

• [7.3,8/H] POWINNY jest zawierać czujnik zbliżeniowy.

Implementacje na urządzeniach mobilnych:

• [7.3.11/H-SR-1] Są zalecane do obsługi czujnika pozycji z 6 stopniami swobody.
• [7.4.3/H] POWINNO obsługiwać Bluetooth i Bluetooth LE.

Jeśli implementacje urządzeń mobilnych obejmują logiczny aparat z listą możliwości za pomocą CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA:

• [7.5,4/H-1-1] domyślnie MUSI mieć normalne pole widzenia, a muszą mieścić się w zakresie od 50 do 95 stopni.

Implementacje na urządzeniach mobilnych:

• [7.6.1/H-0-1] MUSI mieć co najmniej 4 GB nieulotnego miejsca na dane do przechowywania prywatnych danych aplikacji (inaczej partycja „/data”).
• [7.6.1/H-0-2] MUSI zwracać wartość „true” (prawda) w przypadku ActivityManager.isLowRamDevice(), gdy dla jądra i przestrzeni użytkownika dostępnych jest mniej niż 1 GB pamięci.

Jeśli implementacje na urządzeniach mobilnych deklarują obsługę tylko 32-bitowego interfejsu ABI:

• [7.6.1/H-1-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSZĄ mieć co najmniej 416 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora klatek do wartości qHD (np. FWVGA).

• [7.6.1/H-2-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSZĄ mieć co najmniej 592 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora klatek do HD+ (np. HD, WSVGA).

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

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

Jeśli implementacje na urządzeniach mobilnych deklarują obsługę dowolnego 64-bitowego interfejsu ABI (z 32-bitowym ABI lub bez):

• [7.6.1/H-5-1] Jeśli domyślny wyświetlacz używa rozdzielczości bufora klatek do rozdzielczości qHD (np. FWVGA), pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 816 MB.

• [7.6.1/H-6-1] Jeśli domyślny wyświetlacz używa rozdzielczości bufora ramki do HD+ (np. HD, WSVGA), pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 944 MB.

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

• [7.6.1/H-8-1] Jeśli domyślny wyświetlacz używa rozdzielczości bufora klatek do QHD (np. QWXGA), pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 1824 MB.

Pamiętaj, że pojęcie „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do przestrzeni pamięci dostępnej jako uzupełnienie pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio czy wideo itp., które nie są pod kontrolą jądra systemu na potrzeby implementacji na urządzeniach.

Jeśli implementacje urządzeń mobilnych obejmują mniej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, muszą one:

• [7.6.1/H-9-1] MUSI zadeklarować flagę funkcji android.hardware.ram.low.
• [7.6.1/H-9-2] MUSI mieć co najmniej 1,1 GB nieulotnego miejsca na prywatne dane aplikacji (partycja „/data”).

Jeśli implementacje urządzeń mobilnych obejmują więcej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

• [7.6.1/H-10-1] MUSI mieć co najmniej 4 GB nieulotnego miejsca na prywatne dane aplikacji (partycja „/data”).
• NALEŻY zadeklarować flagę funkcji android.hardware.ram.normal.

Jeśli implementacje urządzeń mobilnych obejmują więcej niż 2 GB i mniej niż 4 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

• [7.6.1/H-SR-1] Zdecydowanie ZALECANE jest obsługa tylko 32-bitowej przestrzeni użytkownika (zarówno w aplikacjach, jak i w kodzie systemu).

Jeśli implementacje urządzeń mobilnych obejmują mniej niż 2 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

• [7.6.1/H-1-1] MUSI obsługiwać tylko 32-bitowe interfejsy ABI.

Implementacje na urządzeniach mobilnych:

• [7.6.2/H-0-1] NIE MOŻE udostępniać pamięci współdzielonej aplikacji mniejszej niż 1 GiB.
• [7.7.1/H] POWINNY jest mieć port USB obsługujący tryb peryferyjny.

Jeśli urządzenia mobilne mają port USB obsługujący tryb peryferyjny, te funkcje:

• [7.7.1/H-1-1] MUSI wdrożyć interfejs API Android Open Accessory (AOA).

Jeśli implementacje urządzeń mobilnych obejmują port USB obsługujący tryb hosta:

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

Implementacje na urządzeniach mobilnych:

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

Jeśli implementacje urządzeń mobilnych mogą spełnić wszystkie wymagania dotyczące wydajności niezbędne do obsługi trybu VR i obsługują ten tryb, to:

• [7.9.1/H-1-1] MUSI zadeklarować flagę funkcji android.hardware.vr.high_performance.
• [7.9.1/H-1-2] MUSI zawierać aplikację implementującą android.service.vr.VrListenerService, która może zostać włączona przez aplikacje VR za pomocą android.app.Activity#setVrModeEnabled.

Jeśli implementacje urządzeń mobilnych obejmują co najmniej 1 port USB-C w trybie hosta i zaimplementują (klasę audio USB), oprócz wymagań opisanych w sekcji 7.7.2:

• [7.8.2.2/H-1-1] MUSI zawierać następujące oprogramowanie mapowania kodów HID:

Funkcja	Odwzorowania	Kontekst	Działanie
O	Strona użycia HID: 0x0C Użycie HID: 0x0CD Klucz jądra: KEY_PLAYPAUSE Klucz dla Androida: KEYCODE_MEDIA_PLAY_PAUSE	Odtwarzanie multimediów	Wejście: krótkie naciśnięcie Urządzenie wyjściowe: odtwarzanie lub wstrzymywanie.
			Wejście: przytrzymaj: naciśnij i przytrzymaj. Wyjście: uruchom polecenie głosowe. Wysłane: android.speech.action.VOICE_SEARCH_HANDS_FREE, gdy urządzenie jest zablokowane lub jego ekran jest wyłączony. W przeciwnym razie zostanie wysłana android.speech.RecognizerIntent.ACTION_WEB_SEARCH.
		Połączenie przychodzące	Wejście: krótkie naciśnięcie Wyjście: odbierz połączenie
			Dane wejściowe: przytrzymaj dłużej Dane wyjściowe: Odrzuć połączenie
		Trwa rozmowa	Wejście: krótkie naciśnięcie Wyniki: kończenie połączenia
			Wejście: przytrzymaj i przytrzymaj Wyjście: wycisz lub wyłącz wyciszenie mikrofonu.
mld	Strona użycia HID: 0x0C Użycie HID: 0x0E9 Klucz jądra: KEY_VOLUMEUP Klucz dla Androida: VOLUME_UP	Odtwarzanie multimediów, rozmowa trwa	Wejście: krótkie lub długie naciśnięcie Wyjście: zwiększa głośność zestawu słuchawkowego lub zestawu słuchawkowego.
C	Strona użycia HID: 0x0C Użycie HID: 0x0EA Klucz jądra: KEY_VOLUMEDOWN Klucz dla Androida: VOLUME_DOWN	Odtwarzanie multimediów, rozmowa trwa	Wejście: krótkie lub długie naciśnięcie Wyjście: zmniejsza głośność zestawu słuchawkowego lub zestawu słuchawkowego.
D	Strona użycia HID: 0x0C Użycie HID: 0x0CF Klucz jądra: KEY_VOICECOMMAND Klucz dla Androida: KEYCODE_VOICE_ASSIST	Wszystkie. Może zostać aktywowany w każdej instancji.	Wejście: krótkie lub długie naciśnięcie Wyjście: uruchomienie polecenia głosowego

• [7.8.2.2/H-1-2] MUSI uruchamiać ACTION_HEADSET_PLUG pod wtyczką, ale dopiero po prawidłowym wyliczeniu interfejsów audio i punktów końcowych USB, aby można było zidentyfikować typ podłączonego złącza.

Po wykryciu złącza audio USB typu 0x0302:

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

Po wykryciu złącza audio USB typu 0x0402:

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

Gdy następuje wywołanie interfejsu API AudioManager.getDevices() przy podłączeniu urządzenia peryferyjnego USB, funkcja ta:

• [7.8.2.2/H-4-1] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i rolę isSink(), jeśli pole typu złącza USB audio to 0x0302.

• [7.8.2.2/H-4-2] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i role isSink(), jeśli pole typu złącza USB audio to 0x0402.

• [7.8.2.2/H-4-3] Jeśli pole typu złącza USB audio to 0x0402, MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i role isSource().

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

• [7.8.2.2/H-4-5] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSource(), jeśli pole typu złącza USB audio to 0x604.

• [7.8.2.2/H-4-6] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i rolę isSink(), jeśli pole typu złącza USB audio to 0x400.

• [7.8.2.2/H-4-7] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSource(), jeśli pole typu złącza USB audio to 0x400.

• [7.8.2.2/H-SR-1] Zdecydowanie ZALECANE jest użycie urządzenia peryferyjnego audio USB-C w celu wyliczania deskryptorów USB, identyfikowania typów terminali i intencji transmisji ACTION_HEADSET_PLUG w czasie krótszym niż 1000 milisekund.

Jeśli implementacje na urządzeniach mobilnych zadeklarują android.hardware.audio.output i android.hardware.microphone:

• [5.6(#56_audio-latency)/H-1-1] Średni czas oczekiwania w obrębie jednej ścieżki w obie strony wynosi 800 milisekund lub mniej w przypadku 5 pomiarów, przy średnim odchyleniu bezwzględnym mniejszym niż 100 ms na co najmniej 1 obsługiwanej ścieżce.

Jeśli implementacje urządzeń mobilnych zawierają co najmniej jeden czujnik haptyczny:

• [7.10/H]* NIE POWINNO używać nieśrodkowego mechanizmu haptycznego (wibratora) z nieśrodkową obrotową masą (ERM).
• [7.10/H]* NALEŻY umieścić urządzenie wykonawcze w miejscu, w którym zazwyczaj jest trzymany lub dotykany dłońmi.
• [7.10/H]* POWINNY być wdrożenie wszystkich stałych publicznych dla wyraźnych reakcji haptycznych w android.view.HapticfeedbackConstants (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_launch, KEYBOARD_TAP, LONG_PREVILE_PRESS, TEXT_PRESS, TEXT_PRESS).
• [7.10/H]* Należy wdrożyć wszystkie publiczne stałe dla wyraźnych reakcji haptycznych w android.os.VibrationEffect, czyli (SKU_TICK, skutalizuje, efekt
• [7.10/H]* POWINNY jest korzystać z tych połączonych stałych haptycznych map.
• [7.10/H]* WYMAGAJĄ ocenę jakości interfejsów API createOneShot() i createWaveform().
• [7.10/H]* NALEŻY sprawdzić możliwości skalowalności amplitudy, uruchamiając polecenie android.os.Vibrator.hasAmplitudeControl().

Liniowy rezonator rezonansowy (LRA) to jednomasowy system sprężyn, w którym dominuje częstotliwość rezonansowa, przy której masa przewija się w kierunku pożądanego ruchu.

Jeśli implementacje urządzeń mobilnych zawierają co najmniej jeden liniowy czynnik rezonansowy:

• [7.10/H]* POWINIEN przesunąć element wywołujący reakcję haptyczną na osi X w orientacji pionowej.

Jeśli urządzenia mobilne są wyposażone w mechanizm haptyczny, który jest wyposażony w aktor rezonansu haptycznego z osią X (LRA), działają one:

• [7,10/H]* Częstotliwość rezonansowa na osi X powinna wynosić mniej niż 200 Hz.

Jeśli implementacje urządzeń mobilnych bazują na mapowaniu stałych haptycznych:

• [7.10/H]* MUSI zweryfikować stan implementacji za pomocą interfejsów 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]* POWINNA zapewniać pomoc zastępczą, aby zmniejszyć ryzyko awarii, co opisano tutaj.

2.2.2. Multimedia

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać poniższe formaty kodowania i dekodowania dźwięku i 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 AAC MPEG-4 (AAC LC)
• [5.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
• [5.1/H-0-5] AAC ELD (rozszerzony AAC z niskim opóźnieniem)

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać poniższe formaty kodowania wideo i udostępniać je aplikacjom innych firm:

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

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać poniższe 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 mobilnych:

• [3.2.3.1/H-0-1] MUSI mieć aplikację, która obsługuje intencje ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE i ACTION_CREATE_DOCUMENT zgodnie z opisem w dokumentach pakietu SDK, oraz umożliwiać użytkownikom dostęp do danych dostawcy dokumentów za pomocą interfejsu DocumentsProvider.
• [3.2.3.1/H-0-2]* MUSI wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji dla wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj przez poniższe intencje aplikacji.
• [3.2.3.1/H-SR-1] Zdecydowanie ZALECANE jest wstępne wczytanie aplikacji e-mailowej, która może obsłużyć zamiar wysłania e-maila przez funkcję ACTION_SENDTO, ACTION_SEND lub ACTION_SEND_MULTIPLE.
• [3.4.1/H-0-1] MUSI zawierać pełną implementację interfejsu API android.webkit.Webview.
• [3.4.2/H-0-1] MUSI zawierać samodzielną aplikację przeglądarki do przeglądania stron internetowych przez zwykłych użytkowników.
• [3.8.1/H-SR-1] Zdecydowanie ZALECANE jest wdrożenie domyślnego programu uruchamiającego, który obsługuje przypinanie w aplikacji skrótów, widżetów i WidgetFeatures.
• [3.8.1/H-SR-2] Zdecydowanie ZALECANE jest wdrożenie domyślnego programu uruchamiającego, które zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu API ShortcutManager.
• [3.8.1/H-SR-3] Zdecydowanie ZALECANE jest dodanie domyślnego programu uruchamiającego, który pokazuje plakietki przy ikonach aplikacji.
• [3.8.2/H-SR-1] Zdecydowanie ZALECANE są obsługa widżetów aplikacji innych firm.
• [3.8.3/H-0-1] MUSI zezwalać aplikacjom innych firm na powiadamianie użytkowników o ważnych wydarzeniach za pomocą klas interfejsu Notification i NotificationManager.
• [3.8.3/H-0-2] MUSI obsługiwać powiadomienia rozszerzone.
• [3.8.3/H-0-3] MUSI obsługiwać powiadomienia HUD.
• [3.8.3/H-0-4] MUSI zawierać cień powiadomień zapewniający użytkownikowi możliwość bezpośredniego sterowania powiadomieniami (np. odpowiadaniem, drzemką, odrzucaniem, blokowaniem) przy użyciu funkcji interfejsu użytkownika, takich jak przyciski poleceń lub panel sterowania zaimplementowanymi w AOSP.
• [3.8.3/H-0-5] MUSI wyświetlać opcje dostępne w RemoteInput.Builder setChoices() w obszarze powiadomień.
• [3.8.3/H-SR-1] Zdecydowanie ZALECANE jest wyświetlanie pierwszej opcji dostępnej w RemoteInput.Builder setChoices() w obszarze powiadomień bez dodatkowej interakcji ze strony użytkownika.
• [3.8.3/H-SR-2] Zdecydowanie ZALECANE jest wyświetlanie wszystkich opcji dostępnych w RemoteInput.Builder setChoices() w obszarze powiadomień, gdy użytkownik rozwinie wszystkie powiadomienia w tym obszarze.
• [3.8.3.1/H-SR-1] Zdecydowanie ZALECANE jest wyświetlanie działań, dla których parametr Notification.Action.Builder.setContextual jest ustawiony jako true obok odpowiedzi wyświetlanych przez Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR-1] Zdecydowanie ZALECANE jest wdrożenie na urządzeniu asystenta do działania wspomagającego.

Jeśli implementacje urządzeń mobilnych obsługują działanie wspomagające, mogą one:

• [3.8.4/H-SR-2] Zdecydowanie ZALECANE jest używanie klawisza HOME do uruchomienia aplikacji asystującej zgodnie z opisem w sekcji 7.2.3. MUSI uruchomić wybraną przez użytkownika aplikację asystującą, czyli aplikację implementującą VoiceInteractionService lub działanie obsługujące intencję ACTION_ASSIST.

Jeśli implementacje urządzeń mobilnych obsługują conversation notifications i grupują je w osobnej sekcji niż alerty i ciche powiadomienia o nierozmowie, funkcje te:

• [3.8.4/H-1-1]* MUSI wyświetlać przed powiadomieniami inne niż rozmowy powiadomienia o rozmowie, z wyjątkiem bieżących powiadomień usługi na pierwszym planie i powiadomień Znaczenie:high.

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

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

Jeśli implementacje urządzeń mobilnych obsługują bezpieczny ekran blokady:

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

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

• [3.8.16/H-1-1] MUSI zadeklarować flagę funkcji android.software.controls i ustawić ją na true.
• [3.8.16/H-1-2] MUSI zapewniać użytkownikowi możliwość dodawania, edytowania, wybierania i obsługiwania ustawień ulubionych urządzeń za pomocą opcji zarejestrowanych przez aplikacje innych firm za pomocą interfejsów API ControlsProviderService i Control.
• [3.8.16/H-1-3] MUSI zapewniać dostęp do tej funkcji użytkownika w ciągu 3 interakcji z domyślnego Menu z aplikacjami.
• [3.8.16/H-1-4] MUSI dokładnie renderować na tym urządzeniu użytkownika nazwę i ikonę każdej aplikacji innej firmy, która udostępnia elementy sterujące przez interfejs API ControlsProviderService, a także wszelkie określone pola dostarczane przez interfejsy API Control.

Jeśli natomiast implementacje urządzeń mobilnych nie mają takich ustawień,:

• [3.8.16/H-2-1] MUSI zgłosić null dotyczący interfejsów API ControlsProviderService i Control.
• [3.8.16/H-2-2] MUSI zadeklarować flagę funkcji android.software.controls i ustawić ją na false.

Implementacje na urządzeniach mobilnych:

• [3.10/H-0-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.
• [3.10/H-SR-1] Zdecydowanie ZALECANE-1] w celu wstępnego wczytywania na urządzeniu usług ułatwień dostępu porównywalnych z funkcjami ułatwień dostępu Switch Access i TalkBack (dla języków obsługiwanych przez wstępnie zainstalowany mechanizm zamiany tekstu na mowę) dostępnych w projekcie open source TalkBack.
• [3.11/H-0-1] MUSI obsługiwać instalację mechanizmu zamiany tekstu na mowę innej firmy.
• [3.11/H-SR-1] Zdecydowanie ZALECANE jest dodanie silnika TTS obsługującego języki dostępne na urządzeniu.
• [3.13/H-SR-1] Zdecydowanie ZALECANE jest dodanie komponentu Szybkich ustawień.

Jeśli implementacje urządzeń mobilnych z Androidem zadeklarują obsługę FEATURE_BLUETOOTH lub FEATURE_WIFI, będą one:

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

Jeśli funkcja nawigacji jest udostępniana na ekranie za pomocą gestów:

• [7.2.3/H] Strefa rozpoznawania gestów w przypadku funkcji Home POWINNA znajdować się nie więcej niż 32 dp od dołu ekranu.

Jeśli implementacje urządzeń mobilnych oferują funkcję nawigacji w postaci gestu z dowolnego miejsca przy lewej i prawej krawędzi ekranu:

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

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

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

Jeśli implementacje urządzeń mobilnych z Androidem zadeklarują obsługę aparatu w android.hardware.camera.any, wykonaj te czynności:

• [7.5.4/H-1-1] MUSI uwzględniać zamiary android.media.action.STILL_IMAGE_CAMERA i android.media.action.STILL_IMAGE_CAMERA_SECURE oraz uruchamiać aparat w trybie nieruchomym zgodnie z opisem w pakiecie SDK.
• [7.5.4/H-1-2] MUSI uwzględniać zamiar android.media.action.VIDEO_CAMERA uruchomienia kamery w trybie wideo zgodnie z opisem w pakiecie SDK.

2.2.4 Wydajność i moc

• [8.1/H-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie renderowania klatki lub opóźnienie renderowania klatek NIE MOŻE mieć miejsca częściej niż 5 klatek na sekundę i NIE POWINNO być poniżej 1 klatek na sekundę.
• [8.1/H-0-2] Opóźnienie interfejsu użytkownika. Implementacje na urządzeniach MUSZĄ zapewniać użytkownikom krótki czas oczekiwania przez przewinięcie listy 10 tys. pozycji na liście zgodnie z definicją zawartą w narzędziu Android Compatibility Test Suite (CTS) w czasie krótszym niż 36 sekund.
• [8.1/H-0-3] Przełączanie zadań. W przypadku uruchomienia wielu aplikacji ponowne uruchomienie aplikacji już uruchomionej po uruchomieniu MUSI potrwać mniej niż sekundę.

Implementacje na urządzeniach mobilnych:

• [8.2/H-0-1] MUSI zapewniać wydajność sekwencyjnego zapisu na poziomie co najmniej 5 MB/s.
• [8.2/H-0-2] MUSI zapewniać wydajność zapisu losowego na poziomie co najmniej 0,5 MB/s.
• [8,2/H-0-3] MUSI zapewniać wydajność sekwencyjnego odczytu co najmniej 15 MB/s.
• [8,2/H-0-4] MUSI zagwarantować losową szybkość odczytu co najmniej 3,5 MB/s.

Jeśli implementacje urządzeń mobilnych obejmują funkcje usprawniające zarządzanie energią urządzenia uwzględnione w AOSP lub rozszerzające funkcje dostępne w AOSP:

• [8.3/H-1-1] MUSI umożliwiać użytkownikom włączanie i wyłączanie funkcji oszczędzania baterii.
• [8.3/H-1-2] MUSI umożliwiać użytkownikom wyświetlanie wszystkich aplikacji wyłączonych z trybów czuwania aplikacji i uśpienia.

Implementacje na urządzeniach mobilnych:

• [8.4/H-0-1] MUSI zawierać profil zasilania dla każdego komponentu, który określa wartość bieżącego zużycia energii przez każdy komponent sprzętowy oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z opisem na stronie Android Open Source Project.
• [8,4/H-0-2] MUSI podawać wszystkie wartości zużycia energii w miliiamperach godzin (mAh).
• [8.4/H-0-3] MUSI raportować wykorzystanie mocy procesora przez każdy identyfikator UID każdego procesu. Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/H-0-4] MUSI udostępnić informacje o zużywaniu energii za pomocą polecenia powłoki adb shell dumpsys batterystats deweloperowi aplikacji.
• [8.4/H] POWINNA być przypisana do samego komponentu sprzętowego, jeśli nie można przypisać do aplikacji zużycia energii przez komponent sprzętowy.

Jeśli implementacje urządzeń mobilnych obejmują wyjście ekranu lub wideo:

• [8.4/H-1-1] MUSI spełniać zamiar android.intent.action.POWER_USAGE_SUMMARY i wyświetlać menu ustawień pokazujące to zużycie energii.

2.2.5. Model zabezpieczeń

Implementacje na urządzeniach mobilnych:

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

Implementacje na urządzeniach mobilnych:

• [9.11/H-0-2] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/H-0-3] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1 i SHA-2, aby zapewnić prawidłową obsługę obsługiwanych algorytmów systemu magazynu kluczy Android w obszarze odizolowanym od kodu uruchomionego w jądrze lub nowszym. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, dzięki którym jądro lub kod przestrzeni użytkownika mogą uzyskiwać dostęp do wewnętrznego stanu izolowanego środowiska, w tym do DMA. Nadrzędny projekt Android Open Source Project (AOSP) spełnia to wymaganie dzięki implementacji Trusty. Alternatywnym rozwiązaniem jest skorzystanie z rozwiązania opartego na ARM TrustZone lub sprawdzonej przez firmę zewnętrzną, bezpiecznej izolacji opartej na hipernadzorcy.
• [9.11/H-0-4] MUSI przeprowadzić uwierzytelnianie ekranu blokady w izolowanym środowisku wykonawczym. Gdy wszystko się uda, musi zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający uwierzytelnianie przy zablokowanym ekranie tylko w przypadku izolowanego środowiska wykonawczego. Nadrzędny projekt Android Open Source udostępnia platformę Gatekeeper Hardware Abstraction Layer (HAL) i Trusty, które można wykorzystać w celu spełnienia tego wymogu.
• [9.11/H-0-5] MUSI obsługiwać atest klucza, jeśli klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane z użyciem bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane przez wystarczającą liczbę urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie tego samego klucza atestu,chyba że zostanie utworzone co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowanych zostanie więcej niż 100 tys. jednostek SKU, dla każdej z nich może zostać użyty inny klucz.
• [9/H-0-1] MUSI zadeklarować funkcję „android.hardware.security.model.compatible”.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona we wcześniejszej wersji Androida, urządzenie zostanie zwolnione z konieczności posiadania magazynu kluczy w odizolowanym środowisku wykonawczym oraz obsługi atestu klucza, chyba że zadeklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy działającej w odizolowanym środowisku wykonawczym.

Gdy implementacje urządzeń mobilnych obsługują bezpieczny ekran blokady:

• [9.11/H-1-1] MUSI umożliwiać użytkownikowi wybranie najkrótszego czasu uśpienia, czyli czasu przejścia z odblokowania do stanu blokady, wynoszącego maksymalnie 15 sekund.
• [9.11/H-1-2] MUSI zapewniać użytkownikom zgodę na ukrywanie powiadomień i wyłączanie wszystkich form uwierzytelniania oprócz uwierzytelniania podstawowego opisanego w artykule 9.11.1 Bezpieczny ekran blokady. AOSP spełnia wymóg w postaci trybu blokady.

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

• [9.5/H-2-1] MUSI obsługiwać profile z ograniczonym dostępem, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich funkcjami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko skonfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej precyzyjnymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

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

• [9.5/H-3-1] NIE MOŻE obsługiwać profili z ograniczonym dostępem, ale MUSI być zgodny z mechanizmami kontroli opartymi na AOSP, które włączają lub wyłączają innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

w Androidzie za pomocą interfejsu System API VoiceInteractionService obsługuje mechanizm bezpiecznego i zawsze aktywnego wykrywania słów-kluczy bez informacji o dostępie do mikrofonu.

Jeśli implementacje urządzeń mobilnych obsługują interfejs System API HotwordDetectionService lub inny mechanizm wykrywania słów-kluczy bez informacji o dostępie do mikrofonu:

• [9.8/H-1-1] MUSI mieć pewność, że usługa wykrywania słów-kluczy może przesyłać dane tylko do systemu lub usługi ContentCaptureService
• [9.8/H-1-2] Usługa wykrywania słów-kluczy MUSI mieć pewność, że usługa wykrywania słów-kluczy może przesyłać na serwer systemowy tylko dane dźwiękowe lub dane pochodzące z tych danych na serwer systemowy przez interfejs API HotwordDetectionService lub interfejs API ContentCaptureService przez ContentCaptureManager.
• [9.8/H-1-3] NIE MOŻE przekazywać dźwięku z mikrofonu dłuższego niż 30 sekund w przypadku pojedynczego żądania wyzwalanego sprzętowo do usługi wykrywania słów-kluczy.
• [9.8/H-1-4] NIE MOŻE dostarczać buforowanego dźwięku z mikrofonu starszego niż 8 sekund w przypadku pojedynczego żądania wysyłanego do usługi wykrywania słów-kluczy.
• [9.8/H-1-5] NIE MOŻE dostarczać buforowanego dźwięku z mikrofonu starszego niż 30 sekund do usługi interakcji głosowej lub podobnego urządzenia.
• [9.8/H-1-6] W przypadku każdego udanego wyniku dla słowa-klucza NIE MOŻESZ dopuścić przesyłania więcej niż 100 bajtów danych poza usługę wykrywania słów-kluczy.
• [9.8/H-1-7] W przypadku każdego negatywnego słowa-klucza NIE MOŻESZ zezwalać na przesyłanie więcej niż 5 bitów danych poza usługę wykrywania słów-kluczy.
• [9.8/H-1-8] MUSI zezwalać na przesyłanie danych poza usługę wykrywania słów-kluczy tylko w przypadku żądania weryfikacji słowa-klucza wysłanego z serwera systemowego.
• [9.8/H-1-9] NIE MOŻE umożliwiać funkcji wykrywania słów-kluczy aplikacji instalowanej przez użytkownika.
• [9.8/H-1-10] NIE MOŻESZ wyświetlać w interfejsie użytkownika danych ilościowych o korzystaniu z mikrofonu przez usługę wykrywania słów-kluczy.
• [9.8/H-1-11] MUSI rejestrować liczbę bajtów uwzględnionych w każdej transmisji z usługi wykrywania słów-kluczy, aby umożliwić kontrolę nad bezpieczeństwem.
• [9.8/H-1-12] MUSI obsługiwać tryb debugowania, który rejestruje nieprzetworzoną treść każdej transmisji z usługi wykrywania słów-kluczy, co umożliwia przeanalizowanie ich przez badaczy zabezpieczeń.
• [9.8/H-1-13] MUSI ponownie uruchamiać proces hostowania usługi wykrywania słów-kluczy co najmniej raz na godzinę lub co 30 zdarzeń związanych ze sprzętem, w zależności od tego, co nastąpi wcześniej.
• [9.8/H-1-14] Jeśli pomyślne słowo-klucz zostanie przesłane do usługi interakcji głosowej lub podobnego urządzenia, MUSI wyświetlać wskaźnik mikrofonu, zgodnie z opisem w sekcji 9.8.2.
• [9.8/H-SR-1] Zdecydowanie ZALECANE jest powiadamianie użytkowników przed wybraniem aplikacji jako dostawcy usługi wykrywania słów-kluczy.
• [9.8/H-SR-2] Zdecydowanie ZALECANE jest uniemożliwić przesyłanie nieuporządkowanych danych poza usługę wykrywania słów-kluczy.

Jeśli implementacje urządzeń obejmują aplikację, która korzysta z interfejsu System API HotwordDetectionService lub podobnego mechanizmu do wykrywania słów-kluczy bez wskazania użycia mikrofonu, aplikacja:

• [9.8/H-2-1] MUSI wyraźnie informować użytkownika o każdym obsługiwanym wyrażeniu-słowo-klucz.
• [9.8/H-2-2] NIE MOŻE zachowywać nieprzetworzonych danych dźwiękowych ani danych uzyskanych z nich za pomocą usługi wykrywania słów-kluczy.
• [9.8/H-2-3] NIE MOŻE przesyłać z usługi wykrywania słów-kluczy danych dźwiękowych, danych, które mogą zostać użyte do zrekonstruowania (całkowicie lub części) dźwięku ani treści audio niezwiązanych z samym słowem-kluczem, z wyjątkiem ContentCaptureService.

Jeśli implementacje urządzeń mobilnych zadeklarują android.hardware.microphone:

• [9.8.2/H-4-1] MUSI wyświetlać wskaźnik mikrofonu, gdy aplikacja uzyskuje dostęp do danych dźwiękowych z mikrofonu, ale nie wtedy, gdy do mikrofonu uzyskują dostęp tylko funkcje HotwordDetectionService, SOURCE_HOTWORD lub ContentCaptureService lub aplikacje pełniące role wymienione w sekcji 9.1 z identyfikatorem CDD [C-4-X]. .
• [9.8.2/H-4-2] MUSI wyświetlać listę ostatnich i aktywnych aplikacji korzystających z mikrofonu pochodzącą z PermissionManager.getIndicatorAppOpUsageData() wraz z powiązanymi z nimi komunikatami o atrybucji.
• [9.8.2/H-4-3] NIE MOŻE ukrywać wskaźnika mikrofonu w aplikacjach systemowych, które mają widoczne interfejsy użytkownika lub mają bezpośrednią interakcję z użytkownikiem.
• [9.8.2/H-4-4] MUSI wyświetlać listę ostatnich i aktywnych aplikacji, które korzystają z mikrofonu, uzyskaną z PermissionManager.getIndicatorAppOpUsageData(), a także wszystkie powiązane z nimi wiadomości o atrybucji.

Jeśli implementacje urządzeń mobilnych zadeklarują android.hardware.camera.any:

• [9.8.2/H-5-1] MUSI wyświetlać wskaźnik aparatu, gdy aplikacja uzyskuje dostęp do danych kamery, ale nie wtedy, gdy dostęp do kamery uzyskuje tylko aplikacje pełniące role określone w sekcji 9.1 o identyfikatorze CDD [C-4-X].
• [9.8.2/H-5-2] MUSI wyświetlać ostatnie i aktywne aplikacje używające kamery w takiej postaci, w jakiej pochodzą z aparatu PermissionManager.getIndicatorAppOpUsageData(), oraz wszystkie powiązane z nimi komunikaty o atrybucji.
• [9.8.2/H-5-3] NIE MOŻE ukrywać wskaźnika aparatu w przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub mają bezpośrednią interakcję użytkownika.

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

Implementacje na urządzeniach mobilnych (* nie dotyczy tabletów):

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

Implementacje na urządzeniach mobilnych (* nie dotyczy tabletów):

• Perfetto
  • [6.1/H-0-2]* MUSI udostępniać użytkownikowi powłoki plik binarny /system/bin/perfetto, który jest zgodny z dokumentacją perfetto.
  • [6.1/H-0-3]* Plik binarny perfetto MUSI akceptować jako dane wejściowe konfigurację protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/H-0-4]* Plik binarny perfetto MUSI zapisywać ślad protokołu protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/H-0-5]* MUSI podać, za pomocą pliku binarnego perfetto, przynajmniej źródła danych opisane w dokumentacji perfetto.
  • [6.1/H-0-6]* Demon śledzenia perfetto MUSI być domyślnie włączony (usługa systemowa persist.traced.enable).

2.2.7. Zajęcia z wydajności urządzeń mobilnych

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

2.2.7.1. Multimedia

Jeśli implementacje urządzeń mobilnych 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 sekcji 2.2.7.1 CDD na temat Androida 11

Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.S dla android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, to:

• [5.1/H-1-1] MUSI reklamować maksymalną liczbę sesji sprzętowego dekodera wideo, które można uruchomić jednocześnie w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] MUSI obsługiwać 6 wystąpień sesji sprzętowego dekodera wideo (AVC, HEVC, VP9* lub nowszego) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p przy 30 klatkach na sekundę. *Jeśli dostępny jest kodek VP9, wymagane są tylko 2 instancje.
• [5.1/H-1-3] MUSI reklamować maksymalną liczbę sesji kodera wideo na sprzęcie, które można uruchomić jednocześnie przy użyciu dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] MUSI obsługiwać 6 instancji sprzętowych sesji kodera wideo (AVC, HEVC, VP9* lub nowszego) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p przy 30 kl./s. *Jeśli dostępny jest kodek VP9, wymagane są tylko 2 instancje.
• [5.1/H-1-5] MUSI reklamować maksymalną liczbę sesji kodera i dekodera wideo, które można uruchomić jednocześnie w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] MUSI obsługiwać 6 wystąpień sprzętowego dekodera wideo i sesji kodera wideo (AVC, HEVC, VP9* lub nowszego) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p przy 30 kl./s. *Jeśli dostępny jest kodek VP9, wymagane są tylko 2 instancje.
• [5.1/H-1-7] W przypadku sesji kodowania 1080p lub mniejszej w przypadku sesji kodowania 1080p (innych niż Dolby vision) opóźnienie inicjowania kodeka musi wynosić maksymalnie 50 ms. Wczytywanie w tym miejscu jest definiowane jako równoczesna sesja transkodowania w rozdzielczości 1080p do 720p z użyciem sprzętowych kodeków wideo wraz z inicjowaniem nagrywania audio-wideo 1080p.
• [5.1/H-1-8] Opóźnienie inicjowania kodeka musi wynosić 40 ms lub mniej w przypadku sesji kodowania audio 128 kb/s lub mniejszej w przypadku wszystkich koderów audio, gdy są wczytane. Wczytywanie w tym miejscu jest definiowane jako równoczesna sesja transkodowania w rozdzielczości 1080p do 720p przy użyciu sprzętowych kodeków wideo i inicjowanie nagrywania audio-wideo w jakości 1080p.
• W trakcie wczytywania sesji wideo 1080p z 60 klatkami na sekundę w ciągu 10 sekund NIE MOŻE upuścić więcej niż 2 klatek na sekundę (czyli mniej niż 0,333 procent spadku). Wczytywanie definiuje się jako równoczesną sesję transkodowania w rozdzielczości od 1080p do 720p przy użyciu sprzętowych kodeków wideo oraz odtwarzanie dźwięku AAC 128 kb/s.
• [5.3/H-1-2] W ciągu 10 sekund NIE POWINNY jest upuszczać więcej niż 2 klatek na sekundę przy zmianie rozdzielczości filmu podczas wczytywania podczas wczytywania sesji wideo 60 kl./s. Wczytywanie definiuje się jako równoczesną sesję transkodowania w rozdzielczości 1080p do 720p przy użyciu sprzętowych kodeków wideo oraz odtwarzanie dźwięku AAC 128 kb/s.
• [5.6/H-1-1] muszą mieć czas oczekiwania na tonie krótszy niż 100 milisekund.

2.2.7.2. Aparat

Jeśli implementacje urządzeń mobilnych 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 dyrektywie CDD dotyczącej Androida 11 w sekcji 2.2.7.2

Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.S dla android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, to:

• [7.5/H-1-1] MUSI mieć główny tylny aparat o rozdzielczości co najmniej 12 megapikseli, który umożliwia nagrywanie filmów z szybkością 4k przy 30 kl./s. Główny tylny aparat to tylny aparat z najniższym identyfikatorem.
• [7.5/H-1-2] MUSI mieć główny przedni aparat o rozdzielczości co najmniej 5 megapikseli i umożliwiać nagrywanie w rozdzielczości 1080p przy 30 kl./s. Główny aparat przedni to ten z najniższym identyfikatorem.
• [7.5/H-1-3] MUSI obsługiwać właściwość android.info.supportedHardwareLevel jako FULL lub lepszą w przypadku tylnej głównej kamery oraz LIMITED lub lepszej dla przedniej kamery głównej.
• [7.5/H-1-4] MUSI obsługiwać CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME w obu aparatach głównych.
• [7.5/H-1-5] Opóźnienie podczas przechwytywania obrazu JPEG < 1000 ms dla rozdzielczości 1080p mierzone w teście wydajności kamery CTS w warunkach oświetleniowych ITS (3000 K) dla obu aparatów głównych.
• [7.5/H-1-6] Opóźnienie uruchamiania kamery 2 (otwarta kamera do pierwszej klatki podglądu) musi wynosić mniej niż 600 ms, zgodnie z pomiarem wydajności kamery CTS w warunkach oświetleniowych ITS (3000 K) w przypadku obu głównych kamer.
• [7.5/H-1-8] MUSI obsługiwać aparaty CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW i android.graphics.ImageFormat.RAW_SENSOR w przypadku głównego tylnego aparatu.

2.2.7.3 Urządzenie

Jeśli implementacje urządzeń mobilnych 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 instrukcji CDD dotyczącej Androida 11 w sekcji 2.2.7.3

Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.S dla android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, to:

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

2.2.7.4. Wydajność

Jeśli implementacje urządzeń mobilnych 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 sekcji 2.2.7.4 CDD na potrzeby Androida 11

Jeśli implementacje urządzeń mobilnych 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 na poziomie co najmniej 125 MB/s.
• [8.2/H-2-2] MUSI zapewniać wydajność zapisu przy losowym połączeniu z szybkością co najmniej 10 MB/s.
• [8.2/H-2-3] MUSI zapewnić wydajność sekwencyjnego odczytu co najmniej 250 MB/s.
• [8.2/H-2-4] MUSI zapewnić prędkość odczytu z szybkością losowej co najmniej 40 MB/s.

2.3. Wymagania dotyczące telewizora

Urządzenie z Androidem TV odnosi się do implementacji urządzenia z Androidem, która jest interfejsem rozrywkowym służącym do korzystania z multimediów cyfrowych, filmów, gier, aplikacji lub telewizji na żywo dla użytkowników, którzy siedzą w odległości około 3 metrów od siebie (w odległości 2,5 metra).

Implementacje na urządzeniach z Androidem są zaliczane do telewizorów, jeśli spełniają wszystkie poniższe kryteria:

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

Dodatkowe wymagania podane w pozostałej części tej sekcji dotyczą implementacji telewizorów z Androidem.

2.3.1 Urządzenie

Implementacje na urządzeniach telewizyjnych:

• [7.2.2/T-0-1] MUSI obsługiwać pada kierunkowego.
• [7.2.3/T-0-1] MUSI zawierać funkcje ekranu głównego i Wstecz.
• [7.2.3/T-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno zdarzenie normalnego, jak i przytrzymania funkcji Wstecz (KEYCODE_BACK).
• [7.2.6.1/T-0-1] MUSI zawierać obsługę kontrolerów gier i zadeklarować flagę funkcji android.hardware.gamepad.
• [7.2.7/T] POWINNY jest mieć pilota, za pomocą którego użytkownicy mogą uzyskiwać dostęp do wprowadzania danych bezdotykowych i głównych klawiszy nawigacyjnych.

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

• [7.3.4/T-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 100 Hz.
• [7.3.4/T-1-2] MUSI być w stanie mierzyć zmiany orientacji ekranu z dokładnością do 1000 stopni na sekundę.

Implementacje na urządzeniach telewizyjnych:

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

Jeśli implementacje telewizorów są wyposażone w port USB obsługujący tryb hosta:

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

Jeśli implementacje na telewizorach są 32-bitowe:

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

  • Rozdzielczość 400 dpi lub większa na małych lub normalnych ekranach
  • xhdpi lub więcej na dużych ekranach
  • tvdpi lub więcej na bardzo dużych ekranach

Jeśli implementacje telewizorów są 64-bitowe:

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

  • Rozdzielczość 400 dpi lub większa na małych lub normalnych ekranach
  • xhdpi lub więcej na dużych ekranach
  • tvdpi lub więcej na bardzo dużych ekranach

Uwaga: powyższa „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do dostępnego powyżej miejsca oprócz pamięci już przeznaczonej na komponenty sprzętowe, takie jak radio czy wideo, które nie są pod kontrolą jądra podczas implementacji na urządzeniach.

Implementacje na urządzeniach telewizyjnych:

• [7.8.1/T] POWINNY być mikrofon.
• [7.8.2/T-0-1] MUSI mieć wyjście audio i zadeklarować android.hardware.audio.output.

2.3.2. Multimedia

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać następujące formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:

• [5.1/T-0-1] Profil AAC MPEG-4 (AAC LC)
• [5.1/T-0-2] Profil MPEG-4 HE AAC (AAC+)
• [5.1/T-0-3] AAC ELD (rozszerzony AAC z niskim opóźnieniem)

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać następujące 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 urządzeniach telewizyjnych:

• [5.2.2/T-SR-1] Zdecydowanie zalecamy obsługę kodowania H.264 w rozdzielczościach 720p i 1080p przy 30 klatkach na sekundę.

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać następujące 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 na urządzeniach telewizyjnych MUSZĄ obsługiwać dekodowanie w formacie MPEG-2, zgodnie z sekcją 5.3.1, przy standardowych liczbach klatek i rozdzielczości do:

• [5.3.1/T-1-1] HD 1080p przy 29,97 klatce na sekundę przy wysokim poziomie profilu głównego.
• [5.3.1/T-1-2] HD 1080i przy 59,94 klatce na sekundę z poziomem profilu głównego. W tym celu należy usunąć przeplot wideo z przeplotem i udostępnić go aplikacjom innych firm.

Implementacje na telewizorach MUSZĄ obsługiwać dekodowanie H.264 (zgodnie z opisem w sekcji 5.3.4) dla standardowej liczby klatek i rozdzielczości wideo w następujących formatach:

• [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 wysokim poziomem profilu 4.2

Implementacje urządzeń telewizyjnych z dekoderami sprzętowymi H.265 MUSZĄ obsługiwać dekodowanie H.265, zgodnie z opisem w sekcji 5.3.5, przy standardowych liczbach klatek i rozdzielczości do:

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

Jeśli implementacje telewizorów z dekoderami sprzętowymi H.265 obsługują dekodowanie H.265 i profil dekodowania UHD:

• [5.3.5/T-2-1] MUSI obsługiwać profil dekodowania UHD z prędkością 60 klatek na sekundę w głównym profilu w standardzie Main10 Level 5.

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać dekodowanie VP8, zgodnie z sekcją 5.3.6, przy standardowych liczbach klatek i rozdzielczości do:

• [5.3.6/T-1-1] 1080p HD przy 60 klatkach na sekundę (profil dekodowania)

Implementacje urządzeń telewizyjnych z dekoderami sprzętowymi VP9 MUSZĄ obsługiwać dekodowanie VP9 (zgodnie z opisem w sekcji 5.3.7) przy standardowych liczbach klatek na sekundę i rozdzielczościach obejmujących:

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

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

• [5.3.7/T-2-1] MUSI obsługiwać profil dekodowania UHD z prędkością 60 klatek na sekundę z profilem 0 (8-bitowa głębia kolorów).
• [5.3.7/T-2-1] Zdecydowanie ZALECANE jest obsługa profilu dekodowania UHD z prędkością 60 klatek na sekundę oraz profilu 2 (10-bitowa głębia kolorów).

Implementacje na urządzeniach telewizyjnych:

• [5.5/T-0-1] MUSI obsługiwać system wyciszania głównego i cyfrowego wyjścia audio na obsługiwanych wyjściach, z wyjątkiem skompresowanego wyjścia audio (na urządzeniu, na którym nie jest wykonywane dekodowanie dźwięku).

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

• [5.8/T-0-1] MUSI ustawić tryb wyjścia HDMI, aby wybrać maksymalną rozdzielczość, jaką można obsługiwać przy częstotliwości odświeżania 50 Hz lub 60 Hz.
• [5.8/T-SR-1] Zdecydowanie ZALECANE jest udostępnienie konfigurowanego przez użytkownika selektora częstotliwości odświeżania HDMI.
• [5.8] NALEŻY ustawić częstotliwość odświeżania w trybie wyjścia HDMI na 50 lub 60 Hz w zależności od częstotliwości odświeżania wideo w regionie, w którym urządzenie jest sprzedawane.

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

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

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

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

2.3.3 Oprogramowanie

Implementacje na urządzeniach telewizyjnych:

• [3/T-0-1] MUSI zadeklarować funkcje android.software.leanback i android.hardware.type.television.
• [3.2.3.1/T-0-1] W przypadku wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj MUSISZ wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji.
• [3.4.1/T-0-1] MUSI zawierać pełną implementację interfejsu API android.webkit.Webview.

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

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

Implementacje na urządzeniach telewizyjnych:

• [3.8.14/T-SR-1] Zdecydowanie ZALECANE jest obsługa wielu okien w trybie obraz w obrazie (PIP).
• [3.10/T-0-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.
• [3.10/T-SR-1] Zdecydowanie ZALECANE jest wstępne wczytywanie usług ułatwień dostępu na urządzeniu do funkcji ułatwień dostępu Switch Access i TalkBack (dla języków obsługiwanych przez wstępnie zainstalowany mechanizm zamiany tekstu na mowę) zgodnie z projektem open source TalkBack.

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

• [3.11/T-SR-1] Zdecydowanie ZALECANE jest dodanie silnika TTS obsługującego języki dostępne na urządzeniu.
• [3.11/T-1-1] MUSI obsługiwać instalację mechanizmu zamiany tekstu na mowę innej firmy.

Implementacje na urządzeniach telewizyjnych:

• [3.12/T-0-1] MUSI obsługiwać platformę wejścia TV.

2.3.4 Wydajność i moc

• [8.1/T-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie renderowania klatki lub opóźnienie renderowania klatek NIE MOŻE mieć miejsca częściej niż 5 klatek na sekundę i NIE POWINNO być poniżej 1 klatek na sekundę.
• [8.2/T-0-1] MUSI zapewnić prędkość zapisu sekwencyjnego z szybkością co najmniej 5 MB/s.
• [8.2/T-0-2] MUSI zapewniać wydajność zapisu losowego na poziomie co najmniej 0,5 MB/s.
• [8.2/T-0-3] MUSI zapewniać wydajność sekwencyjnego odczytu co najmniej 15 MB/s.
• [8.2/T-0-4] MUSI zagwarantować losową szybkość odczytu co najmniej 3,5 MB/s.

Jeśli implementacje urządzeń telewizyjnych obejmują funkcje usprawniające zarządzanie energią urządzenia uwzględnione w AOSP lub rozszerzające funkcje uwzględnione w AOSP:

• [8.3/T-1-1] MUSI umożliwiać użytkownikom włączanie i wyłączanie funkcji oszczędzania baterii.

Jeśli telewizory nie mają baterii:

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

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

• [8.3/T-1-3] MUSI zapewniać użytkownikom dostęp do wszystkich aplikacji, które są wyłączone z trybów czuwania aplikacji i uśpienia.

Implementacje na urządzeniach telewizyjnych:

• [8.4/T-0-1] MUSI zawierać profil zasilania dla każdego komponentu, który określa aktualne zużycie przez poszczególne komponenty sprzętowe oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją projektu Android Open Source.
• [8.4/T-0-2] MUSI podawać wszystkie wartości zużycia energii w miliiamperach godzin (mAh).
• [8.4/T-0-3] MUSI raportować wykorzystanie mocy procesora przez każdy identyfikator UID każdego procesu. Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/T] POWINNA być przypisana do samego komponentu sprzętowego, jeśli nie można przypisać do aplikacji zużycia energii przez komponent sprzętowy.
• [8.4/T-0-4] MUSI udostępnić informacje o zużywaniu energii za pomocą polecenia powłoki adb shell dumpsys batterystats deweloperowi aplikacji.

2.3.5 Model zabezpieczeń

Implementacje na urządzeniach telewizyjnych:

• [9.11/T-0-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/T-0-2] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1 i SHA-2, aby zapewnić prawidłową obsługę obsługiwanych algorytmów systemu magazynu kluczy Android w obszarze odizolowanym od kodu działającego w jądrze lub nowszym. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, dzięki którym jądro lub kod przestrzeni użytkownika mogą uzyskiwać dostęp do wewnętrznego stanu izolowanego środowiska, w tym do DMA. Nadrzędny projekt Android Open Source Project (AOSP) spełnia to wymaganie dzięki implementacji Trusty. Alternatywnym rozwiązaniem jest skorzystanie z rozwiązania opartego na ARM TrustZone lub sprawdzonej przez firmę zewnętrzną, bezpiecznej izolacji opartej na hipernadzorcy.
• [9.11/T-0-3] MUSI przeprowadzić uwierzytelnianie ekranu blokady w izolowanym środowisku wykonawczym. Gdy wszystko będzie się udać, zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający uwierzytelnianie przy zablokowanym ekranie tylko w przypadku izolowanego środowiska wykonawczego. Nadrzędny projekt Android Open Source udostępnia platformę Gatekeeper Hardware Abstraction Layer (HAL) i Trusty, które można wykorzystać w celu spełnienia tego wymogu.
• [9.11/T-0-4] MUSI obsługiwać atest klucza, jeśli klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane z użyciem bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane przez wystarczającą liczbę urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie tego samego klucza atestu,chyba że zostanie utworzone co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowanych zostanie więcej niż 100 tys. jednostek SKU, dla każdej z nich może zostać użyty inny klucz.
• [9/T-0-1] MUSI zadeklarować funkcję „android.hardware.security.model.compatible”.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona we wcześniejszej wersji Androida, urządzenie zostanie zwolnione z konieczności posiadania magazynu kluczy w odizolowanym środowisku wykonawczym oraz obsługi atestu klucza, chyba że zadeklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy działającej w odizolowanym środowisku wykonawczym.

Jeśli implementacje urządzeń telewizyjnych obsługują bezpieczny ekran blokady:

• [9.11/T-1-1] MUSI umożliwiać użytkownikowi wybranie limitu czasu uśpienia, po którym następuje przejście z odblokowanej w zablokowaną. Minimalny dozwolony czas oczekiwania to 15 sekund lub mniej.

Jeśli implementacje urządzeń telewizyjnych uwzględniają wielu użytkowników i nie mają zadeklarowanej flagi funkcji android.hardware.telephony:

• [9.5/T-2-1] MUSI obsługiwać profile z ograniczonym dostępem, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich funkcjami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko skonfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej precyzyjnymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

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

• [9.5/T-3-1] NIE MOŻE obsługiwać profili z ograniczonym dostępem, ale MUSI być zgodny z mechanizmami kontroli AOSP umożliwiającymi /wyłączanie dostępu innych użytkowników do połączeń głosowych i SMS-ów.

Jeśli implementacje urządzeń telewizyjnych zadeklarują android.hardware.microphone:

• [9.8.2/T-4-1] MUSI wyświetlać wskaźnik mikrofonu, gdy aplikacja uzyskuje dostęp do danych dźwiękowych z mikrofonu, ale nie wtedy, gdy dostęp do mikrofonu uzyskuje się tylko przez HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje pełniące role określone w artykule 9.1 Uprawnienia z identyfikatorem CDD C-3-X].
• [9.8.2/T-4-2] NIE MOŻE ukrywać wskaźnika mikrofonu w aplikacjach systemowych, które mają widoczne interfejsy użytkownika lub mają bezpośrednią interakcję z użytkownikiem.

Jeśli implementacje urządzeń telewizyjnych zadeklarują android.hardware.camera.any:

• [9.8.2/T-5-1] MUSI wyświetlać wskaźnik aparatu, gdy aplikacja uzyskuje dostęp do danych kamery, ale nie wtedy, gdy dostęp do kamery uzyskuje tylko aplikacje pełniące role wymienione w artykule 9.1. Uprawnienia z identyfikatorem CDD [C-3-X].
• [9.8.2/T-5-2] NIE MOŻE ukrywać wskaźnika aparatu w przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub mają bezpośrednią interakcję użytkownika.

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

Implementacje na urządzeniach telewizyjnych:

• Perfetto
  • [6.1/T-0-1] MUSI udostępniać użytkownikowi powłoki plik binarny /system/bin/perfetto, który jest zgodny z dokumentacją perfetto.
  • [6.1/T-0-2] Plik binarny perfetto MUSI akceptować jako dane wejściowe konfigurację protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/T-0-3] Plik binarny perfetto MUSI zapisywać ślad protokołu Protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/T-0-4] MUSI podać, za pomocą pliku binarnego perfetto, przynajmniej źródła danych opisane w dokumentacji perfetto.

2.4. Wymagania dotyczące zegarka

Zegarek z Androidem odnosi się do implementacji urządzenia z Androidem przeznaczonej do noszenia na ciele, na przykład na nadgarstku.

Implementacje na urządzeniach z Androidem są zaliczane do zegarków, jeśli spełniają wszystkie te kryteria:

• Ekran musi mieć przekątną fizyczną z zakresu od 1,1 do 2,5 cala.
• Mają mechanizm przeznaczony do noszenia przy ciele.

Dodatkowe wymagania podane w pozostałej części tej sekcji dotyczą tylko implementacji na zegarkach z Androidem.

2.4.1. Urządzenie

Implementacje na zegarkach:

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

• [7.2.3/W-0-1] MUSI mieć dostęp do funkcji Home i Wstecz, chyba że jest ustawiona na UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] MUSI obsługiwać wprowadzanie na ekranie dotykowym.

• [7.3.1/W-SR-1] Zdecydowanie ZALECANE jest dodanie 3-osiowego akcelerometru.

Jeśli implementacje na urządzeniach Pixel Watch obejmują odbiornik GPS/GNSS i zgłaszają możliwość korzystania z aplikacji za pomocą flagi funkcji android.hardware.location.gps, to:

• [7.3.3/W-1-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną wykryte, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie jest jeszcze raportowana.
• [7.3.3/W-1-2] MUSI zgłaszać pseudozakresy i częstotliwości pseudozakresowe GNSS, że w warunkach na otwartym niebie po określeniu lokalizacji, gdy ruch jest stały lub porusza się z przyspieszeniem poniżej 0,2 metra na sekundę do kwadratu, wystarczy do obliczenia pozycji z dokładnością do 20 metrów z dokładnością do 5% z dokładnością do 5% w czasie.

Jeśli zegarki są wyposażone w 3-osiowy żyroskop:

• [7.3.4/W-2-1] MUSI być w stanie mierzyć zmiany orientacji ekranu z dokładnością do 1000 stopni na sekundę.

Implementacje na zegarkach:

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

• [7.6.1/W-0-1] MUSI mieć co najmniej 1 GB nieulotnego miejsca na prywatne dane aplikacji (partycja „/data”).

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

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

• [7.8,2/W] MOŻE mieć wyjście audio.

2.4.2 Multimedia

Brak dodatkowych wymagań.

2.4.3 Oprogramowanie

Implementacje na zegarkach:

• [3/W-0-1] MUSI zadeklarować funkcję android.hardware.type.watch.
• [3/W-0-2] MUSI obsługiwać parametr uiMode = UI_MODE_TYPE_WATCH.
• [3.2.3.1/W-0-1] W przypadku wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj MUSISZ wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji.

Implementacje na zegarkach:

• [3.8.4/W-SR-1] Zdecydowanie ZALECANE jest wdrożenie na urządzeniu asystenta do działania wspomagającego.

Implementacje na zegarkach deklarujące flagę funkcji android.hardware.audio.output:

• [3.10/W-1-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.
• [3.10/W-SR-1] Zdecydowanie ZALECANE jest wstępne ładowanie na urządzeniu usług ułatwień dostępu porównywalnych lub przekraczających możliwości funkcji ułatwień dostępu Switch Access i TalkBack (dla języków obsługiwanych przez wstępnie zainstalowany mechanizm zamiany tekstu na mowę) zgodnie z projektem open source TalkBack.

Jeśli implementacje na zegarku zgłaszają funkcję android.hardware.audio.output:

• [3.11/W-SR-1] Zdecydowanie ZALECANE jest dodanie silnika TTS obsługującego języki dostępne na urządzeniu.

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

2.4.4 Wydajność i moc

Jeśli implementacje urządzeń zegarka obejmują funkcje usprawniające zarządzanie zasilaniem urządzenia uwzględnione w AOSP lub rozszerzające funkcje dostępne w AOSP:

• [8.3/W-SR-1] Zdecydowanie zalecamy, aby użytkownicy mogli w łatwy sposób wyświetlać wszystkie aplikacje wyłączone z trybów czuwania aplikacji i oszczędzania energii.
• [8.3/W-SR-2] Zdecydowanie ZALECANE jest udostępnienie i wyłączenie funkcji oszczędzania baterii przez użytkownika.

Implementacje na zegarkach:

• [8.4/W-0-1] MUSI zawierać profil zasilania dla każdego komponentu, który określa wartość bieżącego zużycia energii przez każdy komponent sprzętowy oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z opisem na stronie Android Open Source Project.
• [8,4/W-0-2] MUSI podawać wszystkie wartości zużycia energii w miliiamperach godzin (mAh).
• [8.4/W-0-3] MUSI raportować wykorzystanie mocy procesora przez każdy identyfikator UID każdego procesu. Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/W-0-4] MUSI udostępnić informacje o zużywaniu energii za pomocą polecenia powłoki adb shell dumpsys batterystats deweloperowi aplikacji.
• [8.4/W] Jeśli nie można przypisać do aplikacji zużycia energii przez komponent sprzętowy, JEST wymagany.

2.4.5 Model zabezpieczeń

Implementacje na zegarkach:

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

Jeśli w implementacjach na zegarkach uwzględniono wielu użytkowników i nie zadeklarowano flagi funkcji android.hardware.telephony, oznacza to, że:

• [9.5/W-1-1] MUSI obsługiwać profile z ograniczonym dostępem, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich funkcjami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko skonfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej precyzyjnymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli implementacje na zegarkach obejmują wielu użytkowników i zadeklarują one flagę funkcji android.hardware.telephony:

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

2.5. Wymagania dotyczące motoryzacji

Implementacja na Androida Automotive oznacza radio w pojeździe z Androidem jako systemem operacyjnym z częścią lub całością obsługi systemu lub funkcji informacyjno-rozrywkowych.

Implementacje na urządzeniach z Androidem są zaliczane do samochodów, jeśli zawierają zadeklarowaną funkcję android.hardware.type.automotive lub spełniają wszystkie poniższe kryteria.

• są umieszczone w pojeździe samochodowym lub mogą być do niego podłączone.
• korzystają z ekranu w rzędzie kierowcy jako głównego wyświetlacza.

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

2.5.1 Urządzenie

Implementacje na urządzeniach motoryzacyjnych:

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

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

• [7.2.3/A-0-1] MUSI zawierać funkcję ekranu głównego, a MOŻE zawierać funkcje Wstecz i Ostatnie.

• [7.2.3/A-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno zdarzenie normalnego, jak i przytrzymania funkcji Back (KEYCODE_BACK).

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

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

• [7.3/A-0-3] MUSI zawierać dodatkowe pole informacyjne czujnika TYPE_SENSOR_PLACEMENT w ramach parametru SensorAdditionalInfo dla każdego dostarczonego czujnika.

• [7.3/A-0-1] MAJJONALNIE identyfikuje lokalizację przez połączenie GPS/GNSS z dodatkowymi czujnikami. Jeśli dane w kolumnie Lokalizacja są niewidoczne, Zdecydowanie ZALECANE jest wdrożenie i raportowanie odpowiednich typów czujników lub identyfikatorów właściwości pojazdu.

• [7.3/A-0-2] Żądanie dotyczące lokalizacji żądanej przez LocationManager#requestLocationUpdates() NIE MOŻE być dopasowane do mapy.

Jeśli implementacje urządzeń motoryzacyjnych obsługują standard OpenGL ES 3.1:

• [7.1.4.1/A-0-1] MUSI zadeklarować standard OpenGL ES 3.1 lub nowszym.
• [7.1.4.1/A-0-2] MUSI obsługiwać wersję Vulkan 1.1.
• [7.1.4.1/A-0-3] MUSI zawierać ładowarkę Vulkan i wyeksportować wszystkie symbole.

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

• [7.3.1/A-1-1] MUSI raportować 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:

• [7.3.4/A-2-1] MUSI raportować zdarzenia z częstotliwością co najmniej 100 Hz.
• [7.3.4/A-2-3] MUSI być w stanie mierzyć zmiany orientacji ekranu z dokładnością do 250 stopni na sekundę.
• [7.3.4/A-SR-1] Zdecydowanie ZALECANE jest skonfigurowanie zakresu pomiaru żyroskopu na +/-250 dps, co pozwoli zmaksymalizować możliwą rozdzielczość.

Jeśli implementacje urządzeń motoryzacyjnych obejmują odbiornik GPS/GNSS, ale nie uwzględniają komórkowej transmisji danych za pomocą sieci komórkowej, to:

• [7.3.3/A-3-1] MUSI określić lokalizację po pierwszym włączeniu odbiornika GPS/GNSS lub po upływie ponad 4 dni w ciągu 60 sekund.
• [7.3.3/A-3-2] MUSI spełniać kryteria dotyczące czasu do pierwszej korekty opisane w artykułach 7.3.3/C-1-2 i 7.3.3/C-1-6 w przypadku wszystkich pozostałych próśb o lokalizację (tj.próśb, które nie są pierwszymi prośbami ani co najmniej 4 dni). Wymaganie 7.3.3/C-1-2 jest zazwyczaj spełnione w pojazdach, które nie korzystają z komórkowej łączności danych przez sieć komórkową przy użyciu prognoz orbity GNSS obliczonych na odbiorniku lub korzystania z ostatniej znanej lokalizacji pojazdu wraz z możliwością nieobsłużenia potwierdzenia przez co najmniej 60 sekund z dokładnością na poziomie zgodnym z 7.3.3/C-1-3 lub połączeniem obu tych metod.

Implementacje na urządzeniach motoryzacyjnych:

• [7.4.3/A-0-1] MUSI obsługiwać Bluetooth i POWINIEN obsługiwać Bluetooth LE.
• [7.4.3/A-0-2] Implementacje na Androida Automotive MUSZĄ obsługiwać te profile Bluetooth:
  • Nawiązywanie połączeń telefonicznych przez profil HFP.
  • Odtwarzanie multimediów przez profil dystrybucji dźwięku (A2DP).
  • Sterowanie odtwarzaniem multimediów w profilu pilota (AVRCP).
  • Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).

• [7.4.3/A-SR-1] Zdecydowanie ZALECANE jest obsługa profilu dostępu do wiadomości (MAP).

• [7.4.5/A] POWINNA obsługiwać komórkową transmisję danych za pomocą sieci.

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

Kamera z zewnątrz to aparat, który obrazuje sceny poza wdrożeniem urządzenia, np. jako kamera samochodowa.

Implementacje na urządzeniach motoryzacyjnych:

• POWINIEN zawierać co najmniej jedną kamerę zewnętrzną.

Jeśli implementacje urządzeń w samochodach obejmują kamerę w widoku zewnętrznym, w przypadku takiego aparatu:

• [7.5/A-1-1] NIE MOŻE mieć kamer do widoków z zewnątrz dostępnych za pomocą interfejsów API aparatu z Androidem, chyba że są one zgodne z wymaganiami dotyczącymi podstawowych urządzeń.
• [7.5/A-SR-1] Zdecydowanie ZALECANE jest, aby nie obracać obrazu z kamery ani tworzyć odbicia lustrzanego w poziomie.
• [7.5.5/A-SR-1] Zdecydowanie ZALECANE jest taka orientację, by długi wymiar aparatu był zgodny z horyzontem.
• [7.5/A-SR-2] Zdecydowanie ZALECANE jest rozdzielczość co najmniej 1,3 megapiksela.
• POWINNY być sprzęt o stałej ostrości lub EDOF (rozszerzona głębia ostrości).
• MUSI obsługiwać platformę synchronizacji Androida.
• W sterowniku aparatu MOŻE być zaimplementowany sprzętowy autofokus lub programowy autofokus.

Implementacje na urządzeniach motoryzacyjnych:

• [7.6.1/A-0-1] MUSI mieć co najmniej 4 GB nieulotnego miejsca na prywatne dane aplikacji (partycji „/data”).

• [7.6.1/A] NALEŻY sformatować partycję danych w taki sposób, aby zwiększyć wydajność i trwałość pamięci flash, na przykład przy użyciu systemu plików f2fs.

Jeśli implementacje urządzeń z Androidem korzystają ze współdzielonej pamięci zewnętrznej przez część pamięci wewnętrznej, niewymiennej,:

• [7.6.1/A-SR-1] Zdecydowanie ZALECANE jest ograniczenie operacji wejścia-wyjścia podczas operacji wykonywanych w pamięci zewnętrznej, np. przy użyciu SDCardFS.

Jeśli implementacje urządzeń z branży motoryzacyjnej są 32-bitowe:

• [7.6.1/A-1-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 512 MB, jeśli używana jest jedna z tych gęstości:

  • Rozdzielczość 280 dpi lub niższa na małych bądź normalnych ekranach
  • ldpi lub niższy na bardzo dużych ekranach
  • mdpi lub niższy na dużych ekranach

• [7.6.1/A-1-2] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 608 MB, jeśli używana jest jedna z tych gęstości:

  • xhdpi lub wyższa na małych/normalnych ekranach
  • rozdzielczość hdpi lub wyższa na dużych ekranach;
  • mdpi lub więcej na bardzo dużych ekranach

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

  • Rozdzielczość 400 dpi lub większa na małych lub normalnych ekranach
  • xhdpi lub więcej na dużych ekranach
  • tvdpi lub więcej na bardzo dużych ekranach

• [7.6.1/A-1-4] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSZĄ mieć co najmniej 1344 MB, jeśli używana jest dowolna z tych gęstości:

  • Rozdzielczość 560 dpi lub większa na małym lub normalnym ekranie
  • rozdzielczość 400 dpi lub wyższa na dużych ekranach;
  • xhdpi lub więcej na bardzo dużych ekranach

Jeśli implementacje urządzeń z branży motoryzacyjnej są 64-bitowe:

• [7.6.1/A-2-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 816 MB, jeśli używana jest jedna z tych gęstości:

  • Rozdzielczość 280 dpi lub niższa na małych bądź normalnych ekranach
  • ldpi lub niższy na bardzo dużych ekranach
  • mdpi lub niższy na dużych ekranach

• [7.6.1/A-2-2] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSZĄ mieć co najmniej 944 MB, jeśli używana jest jedna z tych gęstości:

  • xhdpi lub wyższa na małych/normalnych ekranach
  • rozdzielczość hdpi lub wyższa na dużych ekranach;
  • mdpi lub więcej na bardzo dużych ekranach

• [7.6.1/A-2-3] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSZĄ mieć co najmniej 1280 MB, jeśli używana jest jedna z tych gęstości:

  • Rozdzielczość 400 dpi lub większa na małych lub normalnych ekranach
  • xhdpi lub więcej na dużych ekranach
  • tvdpi lub więcej na bardzo dużych ekranach

• [7.6.1/A-2-4] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 1824 MB, jeśli używana jest jedna z tych gęstości:

  • Rozdzielczość 560 dpi lub większa na małym lub normalnym ekranie
  • rozdzielczość 400 dpi lub wyższa na dużych ekranach;
  • xhdpi lub więcej na bardzo dużych ekranach

Pamiętaj, że pojęcie „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do przestrzeni pamięci dostępnej jako uzupełnienie pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio czy wideo itp., które nie są pod kontrolą jądra systemu na potrzeby implementacji na urządzeniach.

Implementacje na urządzeniach motoryzacyjnych:

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

Implementacje na urządzeniach motoryzacyjnych:

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

Implementacje na urządzeniach motoryzacyjnych:

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

2.5.2 Multimedia

Implementacje na urządzeniach motoryzacyjnych MUSZĄ obsługiwać poniższe formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:

• [5.1/A-0-1] Profil AAC MPEG-4 (AAC LC)
• [5.1/A-0-2] Profil MPEG-4 HE AAC (AAC+)
• [5.1/A-0-3] AAC ELD (rozszerzony AAC z niskim opóźnieniem)

Implementacje na urządzeniach motoryzacyjnych MUSZĄ obsługiwać poniższe 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 na urządzeniach motoryzacyjnych MUSZĄ obsługiwać poniższe 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

Zdecydowanie ZALECANE są implementacje urządzeń motoryzacyjnych do obsługi następujących dekodowania wideo:

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

2.5.3 Oprogramowanie

Implementacje na urządzeniach motoryzacyjnych:

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

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

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

Jeśli implementacje na urządzeniach z branży motoryzacyjnej udostępniają zastrzeżony interfejs API korzystający z interfejsu android.car.CarPropertyManager z android.car.VehiclePropertyIds:

• [3/A-1-1] NIE MOŻE dołączać specjalnych uprawnień do korzystania z tych właściwości przez aplikacje systemowe ani uniemożliwiać aplikacjom innych firm korzystania z tych właściwości.
• [3/A-1-2] NIE MOŻE powielać właściwości pojazdu, które już istnieje w pakiecie SDK.

Implementacje na urządzeniach motoryzacyjnych:

• [3.2.1/A-0-1] MUSI obsługiwać i egzekwować wszystkie stałe uprawnienia, zgodnie z dokumentacją na stronie z informacjami o uprawnieniach dot. motoryzacji.

• [3.2.3.1/A-0-1] W przypadku wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj MUSISZ wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji.

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

• [3.8.3/A-0-1] MUSI wyświetlać powiadomienia korzystające z interfejsu API Notification.CarExtender na żądanie aplikacji innych firm.

• [3.8.4/A-SR-1] Zdecydowanie ZALECANE jest wdrożenie na urządzeniu asystenta do działania wspomagającego.

Jeśli implementacje urządzeń motoryzacyjnych zawierają przycisk „Naciśnij, aby rozmawiać”,:

• [3.8.VoiceInteractionService

Implementacje na urządzeniach motoryzacyjnych:

• [3.8.3.1/A-0-1] MUSI prawidłowo renderować zasoby zgodnie z opisem w dokumentacji pakietu SDK Notifications on Automotive OS.
• [3.8.3.1/A-0-2] MUSI wyświetlać odtwarzanie i wyciszanie w przypadku działań związanych z powiadomieniami zamiast działań podanych w Notification.Builder.addAction()
• [3.8.3.1/A] POWINNO ograniczać korzystanie z zaawansowanych zadań zarządzania, takich jak opcje dla poszczególnych kanałów powiadomień. W celu ograniczenia liczby elementów sterujących MOŻNA użyć kupna interfejsu dla poszczególnych aplikacji.

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

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

Implementacje na urządzeniach motoryzacyjnych:

• [3.14/A-0-1] MUSI zawierać platformę interfejsu do obsługi aplikacji innych firm korzystających z interfejsów API multimediów zgodnie z opisem w sekcji 3.14.
• [3.14/A-0-2] MUSI umożliwiać użytkownikowi bezpieczne korzystanie z aplikacji multimedialnych podczas prowadzenia pojazdu.
• [3.14/A-0-3] MUSI obsługiwać działanie niejawne CAR_INTENT_ACTION_MEDIA_TEMPLATE z dodatkowym CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] MUSI umożliwiać przejście do aktywności Aplikacji multimedialnej, ale MUSI włączać ją tylko wtedy, gdy nie obowiązują Ograniczenia dotyczące wygody użytkowania samochodu.
• [3.14/A-0-5] MUSI wyświetlać komunikaty o błędach ustawione przez aplikacje multimedialne i MUSI obsługiwać opcjonalne dodatki ERROR_RESOLUTION_ACTION_LABEL i ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] MUSI obsługiwać wyszukiwanie w aplikacjach, które obsługują wyszukiwanie.
• [3.14/A-0-7] Podczas wyświetlania hierarchii Media Browser MUSI szanować definicje CONTENT_STYLE_BROWSABLE_HINT i CONTENT_STYLE_PLAYABLE_HINT.

Jeśli implementacje urządzeń z Androidem mają domyślną aplikację uruchamiającą, te funkcje:

• [3.14/A-1-1] MUSI zawierać usługi multimedialne i otwierać je zgodnie z zamiarem CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Implementacje na urządzeniach motoryzacyjnych:

• [3.8/A] MOŻE ograniczyć żądania aplikacji przejście do trybu pełnoekranowego zgodnie z opisem w immersive documentation.
• [3.8/A] Pasek stanu i pasek nawigacyjny MOGĄ BYĆ widoczne przez cały czas.
• [3.8/A] MOŻE ograniczyć żądania aplikacji dotyczące zmiany kolorów elementów interfejsu systemu, aby elementy te były zawsze widoczne.

2.5.4 Wydajność i moc

Implementacje na urządzeniach motoryzacyjnych:

• [8.2/A-0-1] MUSI podawać liczbę bajtów odczytanych i zapisanych w pamięci nieulotnej dla każdego identyfikatora UID każdego procesu, aby statystyki były dostępne dla programistów przez interfejs System API android.car.storagemonitoring.CarStorageMonitoringManager. Projekt Android Open Source Project 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] POWINNY być w trybie garażowym co najmniej 15 minut po każdym przejazdie, chyba że:
  • Bateria jest rozładowana.
  • Nie zaplanowano żadnych nieaktywnych zadań.
  • Kierowca wyłącza tryb garażowy.
• [8.4/A-0-1] MUSI zawierać profil zasilania dla każdego komponentu, który określa wartość bieżącego zużycia energii dla każdego komponentu oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją projektu Android Open Source.
• [8.4/A-0-2] MUSI podawać wszystkie wartości zużycia energii w miliiamperach godzin (mAh).
• [8.4/A-0-3] MUSI raportować wykorzystanie mocy procesora przez każdy identyfikator UID każdego procesu. Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/A] MUSI być przypisana do samego komponentu sprzętowego, jeśli nie można przypisać do aplikacji zużycia energii przez komponent sprzętowy.
• [8.4/A-0-4] MUSI udostępnić informacje o zużywaniu energii za pomocą polecenia powłoki adb shell dumpsys batterystats deweloperowi aplikacji.

2.5.5 Model zabezpieczeń

Jeśli implementacje urządzeń z branży motoryzacyjnej obsługują wielu użytkowników:

• [9.5/A-1-1] NIE MOŻE umożliwiać użytkownikom interakcji z użytkownikiem systemowym bez interfejsu graficznego ani przełączania się na niego, z wyjątkiem obsługi administracyjnej urządzeń.
• Przed BOOT_COMPLETED [9.5/A-1-2] MUSI przełączyć się na użytkownika dodatkowego.
• [9.5/A-1-3] MUSI obsługiwać gościa nawet po osiągnięciu maksymalnej liczby użytkowników na urządzeniu.

Implementacje na urządzeniach motoryzacyjnych:

• [9.11/A-0-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/A-0-2] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1 i SHA-2, aby zapewnić prawidłową obsługę obsługiwanych algorytmów systemu magazynu kluczy Android w obszarze odizolowanym od kodu działającego w jądrze lub nowszym. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, dzięki którym jądro lub kod przestrzeni użytkownika mogą uzyskiwać dostęp do wewnętrznego stanu izolowanego środowiska, w tym do DMA. Nadrzędny projekt Android Open Source Project (AOSP) spełnia to wymaganie dzięki implementacji Trusty. Alternatywnym rozwiązaniem jest skorzystanie z rozwiązania opartego na ARM TrustZone lub sprawdzonej przez firmę zewnętrzną, bezpiecznej izolacji opartej na hipernadzorcy.
• [9.11/A-0-3] MUSI przeprowadzić uwierzytelnianie ekranu blokady w izolowanym środowisku wykonawczym. Gdy wszystko będzie się udać, zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający uwierzytelnianie przy zablokowanym ekranie tylko w przypadku izolowanego środowiska wykonawczego. Nadrzędny projekt Android Open Source udostępnia platformę Gatekeeper Hardware Abstraction Layer (HAL) i Trusty, które można wykorzystać w celu spełnienia tego wymogu.
• [9.11/A-0-4] MUSI obsługiwać atest klucza, jeśli klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane z użyciem bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane przez wystarczającą liczbę urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie tego samego klucza atestu,chyba że zostanie utworzone co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowanych zostanie więcej niż 100 tys. jednostek SKU, dla każdej z nich może zostać użyty inny klucz.
• [9/A-0-1] MUSI zadeklarować funkcję „android.hardware.security.model.compatible”.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona we wcześniejszej wersji Androida, urządzenie zostanie zwolnione z konieczności posiadania magazynu kluczy w odizolowanym środowisku wykonawczym oraz obsługi atestu klucza, chyba że zadeklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy działającej w odizolowanym środowisku wykonawczym.

Implementacje na urządzeniach motoryzacyjnych:

• [9.14/A-0-1] MUSI blokować wiadomości z podsystemów pojazdów Android Framework, na przykład umieszczać dozwolone typy wiadomości i źródła wiadomości na liście dozwolonych.
• [9.14/A-0-2] MUSI pilnować ataków typu Dog of Service z wykorzystaniem platformy Androida lub aplikacji innych firm. Zapewnia to ochronę przed złośliwym oprogramowaniem zapełniającym sieć pojazdu ruchami, które może prowadzić do awarii podsystemów pojazdu.

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

Implementacje na urządzeniach motoryzacyjnych:

• Perfetto
  • [6.1/A-0-1] MUSI udostępniać użytkownikowi powłoki plik binarny /system/bin/perfetto, który jest zgodny z dokumentacją perfetto.
  • [6.1/A-0-2] Plik binarny perfetto MUSI akceptować jako dane wejściowe konfigurację protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/A-0-3] Plik binarny perfetto MUSI zapisywać ślad protokołu Protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/A-0-4] MUSI podać, za pomocą pliku binarnego perfetto, przynajmniej źródła danych opisane w dokumentacji perfetto.

2.6. Wymagania dotyczące tabletu

Tablet z Androidem oznacza wdrożenie urządzenia z Androidem, które zwykle spełnia wszystkie te kryteria:

• Aby go użyć, przytrzymaj go w obu rękach.
• Nie ma konfiguracji w tradycyjnej obudowie ani urządzenia konwertowalnego.
• Implementacje klawiatury fizycznej używane z urządzeniem łączą się przez standardowe połączenie (np. USB, Bluetooth).
• Ma źródło zasilania, które umożliwia mobilność, np. baterię.
• Ma wyświetlacz o przekątnej większej niż 7 cali i mniejszych niż 18 cali (mierzona pod kątem przekątnej).

Implementacje na tabletach mają podobne wymagania jak w przypadku urządzeń mobilnych. Wyjątki są w tej sekcji oznaczone symbolem *, a w tej sekcji mowa o wyjątkach.

2.6.1 Urządzenie

Żyroskop

Jeśli implementacje tabletów obejmują 3-osiowy żyroskop:

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

Minimalna pamięć i miejsce na dane (artykuł 7.6.1)

Gęstości ekranu podane dla małych/normalnych ekranów zgodnie z wymaganiami urządzeń mobilnych nie mają zastosowania do tabletów.

Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)

Jeśli tablety wyposażone są w port USB obsługujący tryb peryferyjny, te funkcje:

• [7.7.1/Tab] MOŻE Wdrożyć interfejs Android Open Accessory API (AOA).

Tryb rzeczywistości wirtualnej (art. 7.9.1)

Wysoka wydajność rzeczywistości wirtualnej (art. 7.9.2)

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

2.6.2 Model zabezpieczeń

Klucze i dane logowania (art. 9.11)

Patrz [9.11].

Jeśli implementacje tabletów obejmują wielu użytkowników i nie mają zadeklarowanej flagi funkcji android.hardware.telephony, oznacza to, że:

• [9.5/T-1-1] MUSI obsługiwać profile z ograniczonym dostępem, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich funkcjami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko skonfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej precyzyjnymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli implementacje tabletów obejmują wielu użytkowników i zadeklarują flagę funkcji android.hardware.telephony:

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

2.6.2 Oprogramowanie

• [3.2.3.1/Tab-0-1] TRZEBA wstępnie wczytać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji dla wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj przez poniższe intencje aplikacji.

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

Podstawowym narzędziem dla aplikacji na Androida jest zarządzane środowisko wykonywania kodu bajtowego Dalvik. Interfejs programowania aplikacji na Androida (API) to zestaw interfejsów platformy Androida dostępnych dla aplikacji działających w zarządzanym środowisku wykonawczym.

Implementacje na urządzeniach:

• [C-0-1] MUSI zawierać pełne implementacje, w tym wszystkie udokumentowane działania, dowolnego udokumentowanego interfejsu API udostępnianego przez pakiet SDK do Androida lub dowolny interfejs API oznaczony znacznikiem „@SystemApi” w nadrzędnym kodzie źródłowym Androida.

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

• [C-0-3] NIE MOŻE pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów ani podpisów interfejsów API, odbiegać od udokumentowanego zachowania ani zawierać elementów bez działań, chyba że jest to wyraźnie dozwolone przez tę definicję zgodności.

• [C-0-4] MUSI utrzymywać interfejsy API i działać w sposób rozsądny, nawet jeśli niektóre funkcje sprzętowe, w przypadku których Android obejmuje interfejsy API, zostały pominięte. Szczegółowe wymagania w tym scenariuszu znajdziesz w sekcji 7.

• [C-0-5] NIE MOŻE zezwalać aplikacjom innych firm na korzystanie z interfejsów innych niż SDK, które są zdefiniowane jako metody i pola w pakietach językowych Java, które znajdują się w ścieżce rozruchu w AOSP i nie należą do publicznego pakietu SDK. Dotyczy to interfejsów API oznaczonych adnotacją @hide, ale bez @SystemAPI, zgodnie z opisem w dokumentach pakietu SDK oraz uczestnikach zajęć prywatnych i prywatnych w pakiecie.

• [C-0-6] MUSI być dostarczany z każdym interfejsem spoza pakietu SDK na tych samych listach ograniczonych co za pomocą flag listy tymczasowej i listy odrzuconych w ścieżce prebuilts/runtime/appcompat/hiddenapi-flags.csv dla odpowiedniej gałęzi interfejsu API w AOSP.

• [C-0-7] MUSI obsługiwać mechanizm aktualizacji dynamicznej podpisanej konfiguracji, aby usuwać interfejsy inne niż SDK z listy ograniczonej przez umieszczenie podpisanej konfiguracji w dowolnym pliku APK przy użyciu istniejących kluczy publicznych dostępnych w AOSP.

  Pamiętaj jednak, że:

  • Jeśli nie ma ukrytego interfejsu API lub został on inaczej zaimplementowany w implementacji urządzenia, przenieś go na listę odrzuconych lub pomiń go na wszystkich listach objętych ograniczeniami.
  • MOŻE: jeśli w usłudze AOSP nie ma jeszcze ukrytego interfejsu API, dodaj go do dowolnej z list objętych ograniczeniami.

3.1.1. Rozszerzenia na Androida

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

Implementacje na urządzeniach z Androidem:

• [C-0-1] MUSI wstępnie wczytywać implementację AOSP zarówno biblioteki współdzielonej ExtShared, jak i usług ExtServices, w wersji co najmniej takiej jak minimalna dozwolona liczba na każdym poziomie interfejsu API. Na przykład w przypadku implementacji na urządzeniach z Androidem 7.0 uruchomiony interfejs API na poziomie 24 MUSI zawierać co najmniej wersję 1.

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

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

3.1.2. Biblioteka Androida

Ze względu na wycofanie klienta Apache HTTP implementacje urządzeń:

• [C-0-1] NIE MOŻE umieszczać biblioteki org.apache.http.legacy w bootclasspath.
• [C-0-2] MUSI dodać bibliotekę org.apache.http.legacy do ścieżki klasy aplikacji tylko wtedy, gdy aplikacja spełnia jeden z tych warunków:
  • Kierowanie na interfejs API na poziomie 28 lub niższym.
  • Deklaruje w pliku manifestu, że potrzebuje biblioteki, ustawiając atrybut android:name <uses-library> na org.apache.http.legacy.

Implementacja AOSP spełnia te wymagania.

3.2. Zgodność Soft API

Oprócz zarządzanych interfejsów API opisanych w sekcji 3.1 Android zapewnia też ważny „elastyczny” interfejs API tylko w czasie działania. Są to np. intencje, uprawnienia i podobne aspekty aplikacji na Androida, których nie można wymuszać podczas kompilowania aplikacji.

3.2.1. Uprawnienia

• [C-0-1] Implementacje urządzeń MUSZĄ obsługiwać i egzekwować wszystkie stałe uprawnień zgodnie z opisem na stronie z informacjami o uprawnieniach. Pamiętaj, że sekcja 9 zawiera dodatkowe wymagania związane z modelem zabezpieczeń Androida.

3.2.2. Parametry kompilacji

Interfejsy API Androida zawierają szereg stałych w klasie android.os.Build, które służą do opisania bieżącego urządzenia.

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

Parametr	Szczegóły
WERSJA.PREMIERA	Wersja obecnie uruchomionego systemu Android w formacie zrozumiałym dla człowieka. To pole MUSI zawierać jedną z wartości ciągu znaków zdefiniowanych w sekcji Ciągi znaków dozwolone w przypadku Androida 12.
WERSJA.SDK	Wersja obecnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 12 to pole MUSI zawierać wartość całkowitą 12_INT.
VERSION.SDK_INT	Wersja obecnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 12 to pole MUSI zawierać wartość całkowitą 12_INT.
WERSJA.INCREMENTALNA	Wartość wybrana przez osobę implementującą urządzenie, wskazującą konkretną kompilację obecnie uruchomionego systemu Android, w formacie zrozumiałym dla człowieka. Tej wartości NIE WOLNO używać ponownie w różnych kompilacjach udostępnianych użytkownikom. Typowym zastosowaniem tego pola jest wskazywanie numeru kompilacji lub identyfikatora zmiany źródła, które zostały użyte do wygenerowania kompilacji. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII do wydrukowania i pasować do wyrażenia regularnego „^[^ :\/~]+$”.
PLANSZOWE	Wartość wybrana przez mechanizm implementujący urządzenie, określający konkretny wewnętrzny sprzęt używany przez urządzenie, w formacie zrozumiałym dla człowieka. To pole może być używane do wskazania konkretnej wersji płyty zasilającej urządzenie. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”.
MARKI	Wartość odzwierciedlająca markę przypisaną do urządzenia, znaną użytkownikom. MUSI mieć format zrozumiały dla człowieka i MUSI reprezentować producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”.
OBSŁUGI_MOŻLIWOŚCI	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
OBSŁUGI_32_BIT_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
OBSŁUGI_64_BIT_ABIS	Nazwa drugiego zbioru 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ść z natywnym interfejsem API.
CPU_ABI2	Nazwa drugiego zbioru instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
URZĄDZENIE	Wartość wybrana przez narzędzie do implementacji, zawierająca nazwę programistyczną lub nazwę kodową identyfikującą konfigurację funkcji sprzętowych i konstrukcję przemysłową urządzenia. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”. Ta nazwa urządzenia NIE MOŻE zmieniać się przez cały okres użytkowania usługi.
DŹWIĘK	Ciąg jednoznacznie identyfikujący tę kompilację. Treść MUSI być wystarczająco czytelna dla człowieka. MUSI być zgodna z tym szablonem: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.Release)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Na przykład: acme/myproduct/ mydevice:12/LMYXX/3359:userdebug/test-keys Odcisk cyfrowy NIE MOŻE zawierać odstępów. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII.
SPRZĘT	Nazwa sprzętu (z wiersza poleceń jądra lub /proc). Treść MUSI być wystarczająco czytelna dla człowieka. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
GOSPODARZE	Ciąg jednoznacznie identyfikujący hosta, na którym została utworzona kompilacja, w formacie zrozumiałym dla człowieka. Nie ma wymagań dotyczących konkretnego formatu tego pola. Pole NIE MOŻE mieć wartości null ani pustego ciągu („”).
ID	Identyfikator wybrany przez mechanizm implementujący urządzenie w celu odwołania się do konkretnej wersji w formacie zrozumiałym dla człowieka. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale MUSI zawierać wartość na tyle zrozumiałą dla użytkowników, by umożliwić im odróżnianie kompilacji oprogramowania. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9._-]+$”.
PRODUCENT	Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola. NIE MOŻE ono mieć wartości null ani pustego ciągu („”). To pole NIE MOŻE się zmieniać przez cały okres użytkowania produktu.
PRODUKCJA_SOC	Nazwa handlowa producenta głównego układu SOC (SOC) używanego w produkcie. Urządzenia z tym samym producentem SOC powinny używać tej samej wartości stałej. Poproś producenta SOC o prawidłową stałą, której należy użyć. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII, MUSI być zgodna z wyrażeniem regularnym „^([0-9A-Za-z ]+)”, NIE MOŻE zaczynać ani kończyć się odstępem i NIE MOŻE mieć wartości „nieznana”. To pole NIE MOŻE zmieniać się w okresie użytkowania produktu.
SOC_MODEL	Nazwa modelu systemu podstawowego w układzie (SOC) używanym w usłudze. Urządzenia o tym samym modelu SOC powinny używać tej samej wartości stałej. Zapytaj producenta SOC o prawidłową stałą, której należy użyć. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi odpowiadać wyrażeniu regularnemu „^([0-9A-Za-z ._/+-]+)$”, NIE MOŻE zaczynać ani kończyć się odstępem i NIE MOŻE mieć wartości „nieznane”. To pole NIE MOŻE zmieniać się w okresie użytkowania produktu.
MODEL	Wartość wybrana przez mechanizm implementujący urządzenie, zawierająca nazwę urządzenia znaną użytkownikowi. Powinna to być ta sama nazwa, pod którą urządzenie jest sprzedawane i sprzedawane użytkownikom. Nie ma wymagań dotyczących konkretnego formatu tego pola. NIE MOŻE to być puste ani mieć wartości null („”). To pole NIE MOŻE się zmieniać przez cały okres użytkowania produktu.
USŁUGA	Wartość wybrana przez program implementujący urządzenie, zawierająca nazwę programistyczną lub nazwę kodową konkretnego produktu (SKU), która MUSI być niepowtarzalna w obrębie tej samej marki. MUSI być zrozumiała dla człowieka, ale niekoniecznie przeznaczona dla użytkowników. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”. Ta nazwa produktu NIE MOŻE zmieniać się przez cały okres użytkowania produktu.
ODM_SKU	Opcjonalna wartość wybrana przez narzędzie implementujące urządzenie, która zawiera kod SKU (ang. Stocking Unit) używaną do śledzenia określonych konfiguracji urządzenia, na przykład wszystkich sprzedawanych urządzeń peryferyjnych. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „[0-9A-Za-z.,_-])”.
SERYJNY	MUSI zwracać wartość „UNKNOWN”.
TAGI	Rozdzielona przecinkami lista tagów wybranych przez mechanizm implementujący urządzenie, który dokładniej rozróżnia kompilację. Tagi MUSZĄ być kodowane jako 7-bitowe znaki ASCII, pasujące do wyrażenia regularnego „^[a-zA-Z0-9._-]+” i MUSZĄ mieć jedną z wartości odpowiadających 3 typowym konfiguracjom podpisywania platformy Androida: wersja-klucze, klucze deweloperskie i klucze testowe.
CZAS	Wartość reprezentująca sygnaturę czasową wystąpienia kompilacji.
TYP	Wartość wybrana przez narzędzie implementujące urządzenie, określająca konfigurację środowiska wykonawczego kompilacji. To pole MUSI mieć jedną z wartości odpowiadających 3 typowym konfiguracjom środowiska wykonawczego Androida: user (użytkownik), userdebug lub eng.
UŻYTKOWNIK	Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował kompilację. Nie ma wymagań dotyczących konkretnego formatu tego pola. NIE MOŻE ono mieć wartości null ani pustego ciągu („”).
PAKIET_BEZPIECZEŃSTWA	Wartość wskazująca poziom poprawki zabezpieczeń kompilacji. MUSI wskazywać, że kompilacja nie jest w żaden sposób podatna na ataki opisane w wyznaczonym biuletynie dotyczącym bezpieczeństwa publicznego w Androidzie. MUSI mieć format [RRRR-MM-DD] i odpowiadać zdefiniowanym ciągiem znaków udokumentowanym w biuletynie o bezpieczeństwie w Androidzie lub w dokumencie Android Security Advisory, na przykład „2015-11-01”.
PODSTAWY_systemu operacyjnego	Wartość reprezentująca parametr FINGERDR kompilacji, która jest identyczna z tą kompilacją pod innymi względami, z wyjątkiem poprawek dostarczonych w biuletynie dotyczącym bezpieczeństwa publicznego w Androidzie. MUSI zgłosić prawidłową wartość. Jeśli taka kompilacja nie istnieje, zgłoś pusty ciąg znaków („”).
WŁAŚCICIEL MOTYWACYJNY	Wartość wybrana przez mechanizm implementujący urządzenie identyfikujący konkretną wersję wewnętrznego programu rozruchowego używaną na urządzeniu w formacie zrozumiałym dla człowieka. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9._-]+$”.
getRadioVersion()	MUSI (być lub zwracać) wartość wybraną przez implementator urządzenia identyfikującą konkretną wewnętrzną wersję radia/modema używanej w urządzeniu w formacie zrozumiałym dla człowieka. Jeśli urządzenie nie ma wewnętrznego radia/modem, MUSI zwracać wartość NULL. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi ona być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9._-,]+$”.
getSerial(),	MUSI (być lub zwracać) numer seryjny sprzętu, który MUSI być dostępny i unikalny na wszystkich urządzeniach z tym samym modelem MODEL i PRODUCENT. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi ona być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9._-,]+$”.

3.2.3 Zgodność intencji

3.2.3.1. Częste intencje Application Intents

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

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest wstępne wczytywanie co najmniej 1 aplikacji lub komponentu usługi do modułu obsługi intencji dla wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj i realizacji celów, czyli spełniania oczekiwań programistów w przypadku tych typowych intencji aplikacji, zgodnie z opisem w pakiecie SDK.

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

3.2.3.2. Rozwiązanie intencji

• [C-0-1] Android jest rozszerzoną platformą, dlatego implementacje urządzeń MUSZĄ zezwalać na zastępowanie przez aplikacje innych firm wszystkich wzorców intencji wymienionych w sekcji 3.2.3.1, z wyjątkiem ustawień. Implementacja open source Androida na to pozwala domyślnie.

• [C-0-2] Mechanizmy implementujące urządzenia NIE MOGĄ przypisywać specjalnych uprawnień do korzystania z tych wzorców intencji przez aplikacje systemowe ani uniemożliwiać aplikacjom innych firm wiązania z tymi wzorcami i przejmowania nad nimi kontroli. Zakaz ten obejmuje m.in. wyłączenie interfejsu „Wybór”, który pozwala użytkownikowi wybierać pomiędzy wieloma aplikacjami obsługującymi ten sam wzorzec intencji.

• [C-0-3] Implementacje urządzeń MUSZĄ zapewniać użytkownikom interfejs umożliwiający zmianę domyślnego działania pod kątem intencji.

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

Android udostępnia też mechanizm, który umożliwia aplikacjom innych firm deklarowanie wiarygodnego domyślnego działania związanego z łączeniem aplikacji w przypadku określonych typów intencji URI internetowego. Gdy takie wiarygodne deklaracje są zdefiniowane we wzorcach filtra intencji aplikacji, implementacje urządzeń:

• [C-0-4] MUSI spróbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji linków do zasobów cyfrowych, implementowane przez menedżera pakietów w nadchodzącym projekcie Android Open Source.
• [C-0-5] MUSI próbować zweryfikować filtry intencji podczas instalacji aplikacji i ustawić wszystkie zweryfikowane filtry intencji URI jako domyślne moduły obsługi ich identyfikatorów URI.
• MOGĄ ustawić filtry intencji URI jako domyślne moduły obsługi ich identyfikatorów URI, jeśli zostaną one zweryfikowane, ale inne filtry identyfikatorów URI nie przejdą weryfikacji. Jeśli tak działa implementacja na urządzeniu, MUSI udostępniać w menu ustawień odpowiednie zastąpienia wzorca identyfikatora URI.
• MUSI udostępniać użytkownikowi w Ustawieniach linki do poszczególnych aplikacji w ten sposób:
  • [C-0-6] Użytkownik MUSI mieć możliwość całościowego zastępowania domyślnego działania linków do aplikacji, tak aby aplikacja działała zawsze: „zawsze otwieraj”, „zawsze pytaj” lub „nigdy nie otwieraj” – co musi mieć zastosowanie do wszystkich filtrów intencji URI kandydatów.
  • [C-0-7] Użytkownik MUSI zobaczyć listę kandydujących filtrów intencji URI.
  • Implementacja na urządzeniu MOŻE zapewnić użytkownikowi możliwość zastąpienia wybranych filtrów intencji URI, które zostały zweryfikowane, na podstawie poszczególnych intencji.
  • [C-0-8] Implementacja na urządzeniu MUSI zapewniać użytkownikom możliwość wyświetlenia i zastąpienia konkretnych filtrów intencji URI kandydatów, jeśli implementacja urządzenia umożliwia pomyślne przejście weryfikacji niektórych filtrów intencji URI, a inne – niepowodzenie.

3.2.3.3 Przestrzenie nazw intencji

• [C-0-1] Implementacje na urządzeniach NIE MOGĄ zawierać żadnych komponentów Androida, które uwzględniają nowe intencje lub wzorce intencji transmisji, używając ciągu ACTION, CATEGORY lub innego klucza w przestrzeni nazw android.* lub com.android.*.
• [C-0-2] Moduły implementujące urządzenia NIE MOGĄ zawierać żadnych komponentów Androida, które uwzględniają nowe intencje lub wzorce intencji rozpowszechniania używających ACTION, CATEGORY lub innego ciągu kluczowego w przestrzeni pakietu należącej do innej organizacji.
• [C-0-3] Mechanizmy implementujące urządzenia NIE MOGĄ zmieniać ani rozszerzać żadnych wzorców intencji wymienionych w sekcji 3.2.3.1.
• Implementacje na urządzeniach MOGĄ uwzględniać wzorce intencji korzystające z przestrzeni nazw wyraźnie i wyraźnie powiązanych z ich własną organizacją. Zakaz ten jest podobny do zakazu określonego dla klas języka Java w sekcji 3.6.

3.2.3.4. Intencje związane z transmisją

Aplikacje innych firm korzystają z platformy, aby przesyłać określone intencje w celu powiadomienia ich o zmianach w środowisku sprzętowym lub oprogramowania.

Implementacje na urządzeniach:

• [C-0-1] MUSI transmitować publiczne intencje transmisji wymienione tutaj w odpowiedzi na odpowiednie zdarzenia systemowe zgodnie z opisem w dokumentacji pakietu SDK. Pamiętaj, że to wymaganie nie jest sprzeczne z artykułem 3.5, ponieważ ograniczenie dotyczące aplikacji działających w tle zostało również opisane w dokumentacji pakietu SDK. Niektóre intencje transmisji zależą też od obsługi sprzętu. Jeśli urządzenie obsługuje niezbędny sprzęt, MUSI transmitować intencje i działać zgodnie z dokumentacją pakietu SDK.

3.2.3.5. Warunkowe intencje aplikacji

Android zawiera ustawienia, które pozwalają użytkownikom w łatwy sposób wybierać domyślne aplikacje, takie jak ekran główny czy SMS-y.

W stosownych przypadkach implementacje urządzeń MUSZĄ zawierać podobne menu ustawień i być zgodne ze wzorcem filtra intencji i metodami interfejsu API opisanymi w dokumentacji pakietu SDK jak poniżej.

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

• [C-1-1] MUSI uwzględniać intencję android.settings.HOME_SETTINGS, aby wyświetlać domyślne menu ustawień aplikacji na ekranie głównym.

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

• [C-2-1] MUSI zawierać menu ustawień, które wywołuje android.provider.Telephony.ACTION_CHANGE_DEFAULT, by wyświetlić okno umożliwiające zmianę domyślnej aplikacji SMS.

• [C-2-2] MUSI uwzględniać zamiar android.telecom.action.CHANGE_DEFAULT_DIALER, aby wyświetlić okno umożliwiające użytkownikowi zmianę domyślnej aplikacji Telefon.

  • Do połączeń przychodzących i wychodzących MUSI używać wybranego przez użytkownika domyślnego interfejsu aplikacji Telefon, z wyjątkiem połączeń alarmowych, które korzystają ze wstępnie zainstalowanej aplikacji Telefon.

• [C-2-3] MUSI spełniać prośbę android.telecom.action.CHANGE_PHONE_ACCOUNTS, aby zapewnić użytkownikowi możliwość skonfigurowania ConnectionServices powiązanego z PhoneAccounts, a także domyślnego konta PhoneAccount, którego dostawca usług telekomunikacyjnych będzie używać do nawiązywania połączeń wychodzących. Implementacja AOSP spełnia to wymaganie, dodając w menu ustawień „Połączenia” menu „Konta telefoniczne”.

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

• [C-2-5] MUSI udostępniać użytkownikom funkcje umożliwiające wybór aplikacji, która ma rolę android.app.role.CALL_REDIRECTION.

• [C-2-6] MUSI uwzględniać intencje android.intent.action.SENDTO i android.intent.action.VIEW oraz umożliwiać wysyłanie i wyświetlanie SMS-ów.

• [C-SR-1] Zdecydowanie ZALECANE jest uszanowanie intencji android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_Button, android.intent.action.VIEW i android.intent.action.DIAL z intencją wczytywaną jako intensywną aplikacją telefoniczną, która może obsługiwać te intencje opisane jako intensywnie opisane przez telefon, które obsługują takie intencje.

Jeśli implementacje urządzeń zgłaszają android.hardware.nfc.hce:

• [C-3-1] MUSI uwzględniać intencję android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlać domyślne menu ustawień aplikacji w przypadku płatności zbliżeniowych.
• [C-3-2] MUSI uwzględniać intencję android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT, aby wyświetlić działanie, które otwiera okno z prośbą o zmianę domyślnej usługi emulacji karty dla określonej kategorii zgodnie z opisem w pakiecie SDK.

Jeśli implementacje urządzeń zgłaszają android.hardware.nfc:

• [C-4-1] MUSI uwzględniać te intencje android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED i android.nfc.action.TECH_DISCOVERED, aby pokazywać działanie, które spełnia oczekiwania programistów dotyczące tych intencji, zgodnie z opisem w pakiecie SDK.

Jeśli implementacje urządzeń zgłaszają android.hardware.bluetooth:

• [C-5-1] MUSI uwzględniać intencję „android.bluetooth.adapter.action.REQUEST_ENABLE” i pokazywać aktywność systemu, która pozwala użytkownikowi włączyć Bluetooth.
• [C-5-2] MUSI uwzględniać intencję „android.bluetooth.adapter.action.REQUEST_DISCOVERABLE” i pokazywać działanie systemu, które wymaga trybu wykrywalności.

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

• [C-6-1] MUSI zaimplementować działanie, które zareaguje na intencję ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, które w implementacjach z funkcją UI_MODE_TYPE_NORMAL MUSI być działaniem, w którym użytkownik może przyznawać i odbierać dostęp aplikacji do konfiguracji zasad Nie przeszkadzać.

Jeśli implementacje urządzeń pozwalają użytkownikom na korzystanie z zewnętrznych metod wprowadzania na urządzeniu:

• [C-7-1] MUSI udostępniać dostępny dla użytkownika mechanizm umożliwiający dodawanie i konfigurowanie zewnętrznych metod wprowadzania w odpowiedzi na intencję android.settings.INPUT_METHOD_SETTINGS.

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

• [C-8-1] MUSI spełniać cel android.settings.ACCESSIBILITY_SETTINGS, aby udostępnić użytkownikom dostępny dla użytkowników mechanizm włączania i wyłączania usług ułatwień dostępu innych firm wraz z wstępnie załadowanymi usługami ułatwień dostępu.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Easy Connect i udostępnienie tej funkcji aplikacjom innych firm:

• [C-9-1] MUSI zaimplementować interfejsy API intencji Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI w sposób opisany w dokumentacji pakietu SDK.

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

• [C-10-1] MUSI zawierać w ustawieniach interfejs użytkownika, który obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, umożliwiając użytkownikom dodawanie aplikacji do listy dozwolonych lub usuwanie ich z niej.

Jeśli implementacje urządzeń nie obsługują trybu oszczędzania danych:

• [C-11-1] MUSI mieć działanie obsługujące intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻE wdrożyć je jako no-op.

Jeśli implementacje urządzenia zadeklarują obsługę aparatu za pomocą android.hardware.camera.any:

• [C-12-3] MUSI zezwalać 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 implementacje urządzeń zgłaszają android.software.device_admin:

• [C-13-1] MUSI uwzględniać intencję android.app.action.ADD_DEVICE_ADMIN wywoływania interfejsu, który umożliwia użytkownikowi dodanie do systemu administratora urządzenia (lub umożliwienie mu jego odrzucenia).

• [C-13-2] MUSI uwzględniać 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, i zawierać działania opisane w tym artykule dotyczące realizacji tych intencji.

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

• [C-14-1] MUSI w pełni wdrożyć interfejsy API AutofillService i AutofillManager oraz przestrzegać zamiaru android.settings.REQUEST_SET_AUTOFILL_SERVICE, aby wyświetlać domyślne menu ustawień aplikacji umożliwiające włączenie i wyłączenie autouzupełniania oraz zmianę domyślnej usługi autouzupełniania dla użytkownika.

Jeśli implementacje na urządzeniu obejmują wstępnie zainstalowaną aplikację lub chcesz umożliwić aplikacjom innych firm dostęp do statystyk użytkowania:

• Zdecydowanie zalecamy, aby [C-SR-2] udostępniał dostępny dla użytkownika mechanizm przyznawania lub anulowania dostępu do statystyk użytkowania w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS w przypadku aplikacji, które zadeklarują uprawnienie android.permission.PACKAGE_USAGE_STATS.

Jeśli implementacje urządzeń uniemożliwią dostęp do statystyk użytkowania aplikacjom, w tym aplikacjom instalowanym fabrycznie:

• [C-15-1] MUSI nadal mieć działanie obsługujące wzór zamiaru android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale MUSI działać w trybie no-op, tak by działał w taki sam sposób jak w przypadku odmowy dostępu użytkownika.

Jeśli implementacje urządzeń wyświetlają linki do działań określonych przez parametr AutofillService_passwordsActivity w Ustawieniach lub linki do haseł użytkowników wykorzystujące podobny mechanizm:

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

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

• [C-18-1] MUSI uwzględniać zamiar android.settings.ACTION_VOICE_INPUT_SETTINGS, aby wyświetlać domyślne menu ustawień aplikacji dla rozpoznawania i Asystenta głosowego.

Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.audio.output:

• [C-SR-3] Zdecydowanie ZALECANE jest działanie android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA i android.speech.tts.engine.GET_SAMPLE_TEXT za pomocą działania, które umożliwia realizację tych intencji, zgodnie z opisem w pakiecie SDK tutaj.

Android obsługuje interaktywne wygaszacze ekranu, znane wcześniej jako Dreams. Wygaszacze ekranu pozwalają użytkownikom korzystać z aplikacji, gdy urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji dokującej. Implementacje na urządzeniach:

• POWINNO obsługiwać wygaszacze ekranu i udostępnić opcję ustawień, która umożliwia użytkownikom konfigurowanie wygaszaczy ekranu w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

3.2.4 Działania na dodatkowych/wielu wyświetlaczach

Jeśli implementacje urządzeń pozwalają na uruchamianie zwykłych aktywności na Androidzie na więcej niż jednym wyświetlaczu:

• [C-1-1] MUSI ustawiać flagę funkcji android.software.activities_on_secondary_displays.
• [C-1-2] MUSI gwarantować zgodność z interfejsem API podobną do działania wykonywanego na ekranie głównym.
• [C-1-3] Nowa aktywność MUSI trafiać na ten sam ekran co aktywność, która uruchomiła je po uruchomieniu, bez określania docelowego wyświetlacza przez interfejs API ActivityOptions.setLaunchDisplayId().
• [C-1-4] MUSI zniszczyć wszystkie działania, gdy zostanie usunięte wyświetlanie z flagą Display.FLAG_PRIVATE.
• [C-1-5] MUSI bezpiecznie ukrywać treści na wszystkich ekranach, gdy urządzenie jest zablokowane, używając bezpiecznego ekranu blokady, chyba że aplikacja włączy opcję wyświetlania na górze ekranu blokady za pomocą interfejsu API Activity#setShowWhenLocked().
• POWINNA zawierać parametr android.content.res.Configuration odpowiadający temu wyświetlaczowi, aby mógł być wyświetlany, działać prawidłowo i zachować zgodność w przypadku uruchomienia działania na wyświetlaczu dodatkowym.

Jeśli implementacje urządzeń pozwalają na uruchamianie normalnych aktywności na Androidzie na wyświetlaczach dodatkowych, a wyświetlacz dodatkowy ma flagę android.view.Display.FLAG_PRIVATE:

• [C-3-1] Tylko właściciel wyświetlacza i systemu oraz działania, które są na nim dostępne, MUSZĄ go uruchomić. Każdy może włączyć ekran z flagą android.view.Display.FLAG_PUBLIC.

3.3. Zgodność z natywnym interfejsem API

Zgodność kodu natywnego stanowi wyzwanie. Z tego powodu implementacje urządzeń:

• [C-SR-1] Zdecydowanie ZALECAMY użycie wymienionych poniżej bibliotek z wcześniejszego projektu Android Open Source.

3.3.1 Interfejsy binarne aplikacji

Zarządzany kod bajtowy Dalvik może wywoływać kod natywny podany w pliku .apk aplikacji w postaci pliku ELF .so skompilowanego z myślą o odpowiedniej architekturze sprzętowej urządzenia. Ponieważ kod natywny w dużym stopniu zależy od bazowej technologii procesorów, Android definiuje kilka interfejsów Application Binary Interfaces (ABI) w pakiecie Android NDK.

Implementacje na urządzeniach:

• [C-0-1] MUSI być zgodny z co najmniej jednym zdefiniowanym interfejsem ABI Androida NDK.
• [C-0-2] MUSI obejmować obsługę kodu działającego w środowisku zarządzanym w celu wywoływania kodu natywnego z użyciem standardowej semantyki JNI (Java Native Interface).
• [C-0-3] MUSI być zgodna ze źródłem (tzn. z nagłówkiem) i z kodem binarnym (w przypadku interfejsu ABI) z każdą wymaganą biblioteką z poniższej listy.
• [C-0-5] MUSI dokładnie raportować natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie, za pomocą parametrów android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS i android.os.Build.SUPPORTED_64_BIT_ABIS. Każdy z nich musi zawierać listę rozdzielonych przecinkami interfejsów ABI uporządkowanych od najniższego do najmniej preferowanego.

• Za pomocą powyższych parametrów MUSI zgłaszać podzbiór interfejsów ABI z poniższej listy. NIE MOŻE zgłaszać żadnych interfejsów ABI, których nie ma na liście.

  • armeabi (nie jest już obsługiwany przez NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

• [C-0-7] MUSI udostępnić wszystkie poniższe biblioteki udostępniające natywne interfejsy API, aby udostępniać je aplikacjom zawierającym kod natywny:

  • libaaudio.so (natywna obsługa dźwięku AAudio).
  • libamidi.so (natywna obsługa MIDI, jeśli została zgłoszona funkcja android.software.midi zgodnie z opisem w artykule 5.9)
  • libandroid.so (natywna obsługa aktywności na Androidzie)
  • libc (biblioteka C)
  • libcamera2ndk.so
  • libdl (dynamiczny tag łączący)
  • libEGL.so (natywne zarządzanie powierzchnią OpenGL)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (logowanie w systemie Android)
  • libmediandk.so (obsługa natywnych interfejsów API multimediów)
  • libm (biblioteka matematyczna)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (obsługa OpenMAX AL 1.0.1)
  • libOpenSLES.so (obsługa dźwięku OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (minimalna obsługa języka C++)
  • libvulkan.so (Vulkan)
  • libz (kompresja Zlib)
  • Interfejs JNI

• [C-0-8] NIE MOŻE dodawać ani usuwać funkcji publicznych dla wymienionych powyżej bibliotek natywnych.

• [C-0-9] MUSI zawierać dodatkowe biblioteki spoza AOSP dostępne bezpośrednio dla aplikacji innych firm w /vendor/etc/public.libraries.txt.

• [C-0-10] NIE MOŻE udostępniać żadnych innych bibliotek natywnych zaimplementowanych i udostępnionych w AOSP jako bibliotek systemowych aplikacjom innych firm kierowanych na interfejs API na poziomie 24 lub wyższym, ponieważ są one zarezerwowane.

• [C-0-11] MUSI wyeksportować wszystkie symbole funkcji OpenGL ES 3.1 i Android Extension Pack zgodnie z definicją w pakiecie NDK za pomocą biblioteki libGLESv3.so. Pamiętaj, że choć MUSZĄ być obecne wszystkie symbole, w sekcji 7.1.4.1 bardziej szczegółowo opisano wymagania dotyczące momentu pełnej implementacji poszczególnych funkcji.

• [C-0-12] MUSI eksportować symbole funkcji podstawowych symboli funkcji Vulkan 1.0, a także rozszerzenia 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ż MUSZĄ być obecne wszystkie symbole, w sekcji 7.1.4.2 bardziej szczegółowo opisano wymagania dotyczące czasu pełnego wdrożenia poszczególnych funkcji.

• POWINNA budować z użyciem kodu źródłowego i plików nagłówka dostępnych w nadchodzącym projekcie Android Open Source,

Pamiętaj, że w kolejnych wersjach Androida może pojawić się obsługa dodatkowych funkcji AI.

3.3.2 Zgodność z 32-bitowym kodem natywnym ARM

Jeśli implementacje urządzeń zgłaszają obsługę interfejsu ABI armeabi:

• [C-3-1] MUSI też obsługiwać narzędzie armeabi-v7a i zgłaszać dotyczące go wsparcie, ponieważ armeabi służy tylko do zapewnienia zgodności wstecznej ze starszymi aplikacjami.

Jeśli implementacje urządzeń zgłaszają obsługę interfejsu ABI armeabi-v7a, w przypadku aplikacji korzystających z tego interfejsu ABI:

• [C-2-1] MUSI zawierać poniższe wiersze w języku /proc/cpuinfo i NIE POWINNO zmieniać wartości na tym samym urządzeniu, nawet jeśli są one odczytywane przez inne interfejsy ABI.

  • Features:, a następnie lista wszystkich opcjonalnych funkcji procesora ARMv7 obsługiwanych przez urządzenie.
  • CPU architecture:, po której następuje liczba całkowita opisująca najwyżej obsługiwaną architekturę ARM urządzenia (np. „8” w przypadku urządzeń z architekturą ARMv8).

• [C-2-2] MUSI zawsze udostępniać te operacje, nawet w przypadku, gdy interfejs ABI jest zaimplementowany w architekturze ARMv8, przez natywnego wsparcia procesora lub przez emulację oprogramowania:

  • Instrukcje dotyczące SWP i SWPB.
  • Operacje na barierach CP15ISB, CP15DSB i CP15DMB.

• [C-2-3] MUSI obsługiwać rozszerzenie Advanced SIMD (NEON).

3.4 Zgodność z internetem

3.4.1 Zgodność z WebView

Jeśli implementacje urządzeń zapewniają pełną implementację interfejsu API android.webkit.Webview:

• [C-1-1] MUSI zgłosić użytkownika android.software.webview.
• [C-1-2] Aby wdrożyć interfejs API android.webkit.WebView, [C-1-2] MUSI użyć kompilacji Chromium z nadrzędnego projektu Android Open Source w gałęzi Androida 12.

• [C-1-3] Ciąg znaków klienta użytkownika zgłoszony przez WebView MUSI mieć ten format:

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • Wartość ciągu $(VERSION) MUSI być taka sama jak wartość w polu android.os.Build.VERSION.Release.
  • Ciąg $(MODEL) MOŻE być pusty, ale jeśli nie jest pusty, MUSI mieć taką samą wartość jak android.os.Build.MODEL.
  • Pole „Build/$(BUILD)” MOŻE zostać pominięte, ale jeśli jest podany, ciąg znaków $(BUILD) MUSI być taki sam jak wartość android.os.Build.ID.
  • Wartość ciągu $(CHROMIUM_VER) MUSI być wersją przeglądarki Chromium z nadrzędnego projektu Android Open Source.
  • Implementacje na urządzeniach MOGĄ pominąć element „mobilny” w ciągu znaków klienta użytkownika.

• Komponent WebView POWINIEN obsługiwać jak najwięcej funkcji HTML5, a jeśli go obsługuje, POWINIEN być zgodny ze specyfikacją HTML5.

• [C-1-4] MUSI renderować podaną treść lub zawartość zdalnego adresu URL w ramach procesu innego niż aplikacja, która tworzy wystąpienie komponentu WebView. W szczególności oddzielny proces renderowania MUSI mieć niższe uprawnienia, działać jako osobny identyfikator użytkownika, nie może mieć dostępu do katalogu danych aplikacji, nie może mieć bezpośredniego dostępu do sieci i mieć dostęp przez usługę Binder tylko do minimalnej wymaganej liczby usług systemowych. Implementacja AOSP komponentu WebView spełnia to wymaganie.

Pamiętaj, że jeśli implementacje urządzeń są 32-bitowe lub mają zadeklarowaną flagę funkcji android.hardware.ram.low, są one zwolnione z obowiązku spełnienia 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:

• [C-1-1] MUSI obsługiwać każdy z tych interfejsów API powiązanych z HTML5:
  • pamięć podręczna aplikacji/operacja offline
  • Tag<video>
  • geolokalizacja
• [C-1-2] MUSI obsługiwać interfejs webstorage API HTML5/W3C oraz interfejs API IndexedDB HTML5/W3C. Pamiętaj, że ponieważ treści standardów tworzenia stron internetowych wolą korzystać z IndexedDB zamiast do pamięci masowej, IndexedDB może stać się wymaganym komponentem w przyszłej wersji Androida.
• MOŻE przesłać niestandardowy ciąg znaków klienta użytkownika do samodzielnej aplikacji przeglądarki.
• POTRZEBUJESZ obsługę jak największej liczby zasobów HTML5 w samodzielnej aplikacji przeglądarki (niezależnie od tego, czy jest oparta na nadrzędnej aplikacji przeglądarki WebKit czy w zastępstwie innej firmy).

Jeśli jednak implementacje urządzeń nie zawierają samodzielnej aplikacji przeglądarki:

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

3.5. Zgodność behawioralna interfejsu API

Implementacje na urządzeniach:

• [C-0-9] MUSI zadbać o zgodność behawioralną interfejsów API w przypadku wszystkich zainstalowanych aplikacji, chyba że są one objęte ograniczeniami opisanymi w artykule 3.5.1.
• [C-0-10] NIE MOŻE wdrażać metody dodawania do listy dozwolonych, która zapewnia zgodność interfejsu API tylko w przypadku aplikacji wybranych przez osoby wdrażające na urządzeniach.

Działanie każdego z typów interfejsów API (zarządzane, elastyczne, natywne i internetowe) musi być spójne z preferowaną implementacją nadrzędnego projektu Android Open Source. Oto niektóre obszary zgodności:

• [C-0-1] Urządzenia NIE MOGĄ zmieniać działania ani semantyki intencji standardowej.
• [C-0-2] Urządzenia NIE MOGĄ zmieniać semantyki cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (np. Service, Activity czy ContentProvider).
• [C-0-3] Urządzenia NIE MOGĄ zmieniać semantyki uprawnień standardowych.
• Urządzenia NIE MOGĄ zmieniać ograniczeń nałożonych na aplikacje w tle. W przypadku aplikacji działających w tle:
  • [C-0-4] Aby otrzymywać dane wyjściowe z GnssMeasurement i GnssNavigationMessage, MUSISZ zatrzymać wykonywanie wywołań zwrotnych zarejestrowanych przez aplikację.
  • [C-0-5] MUSI ograniczać częstotliwość aktualizacji dostarczanych do aplikacji za pomocą klasy interfejsu API LocationManager lub metody WifiManager.startScan().
  • [C-0-6] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, NIE MOŻE umożliwiać rejestrowania odbiorników na potrzeby niejawnych komunikatów Androida w pliku manifestu, chyba że intencja transmisji wymaga uprawnienia "signature" lub "signatureOrSystem" protectionLevel lub znajduje się na liście wykluczeń.
  • [C-0-7] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zatrzymać usługi w tle, tak jakby aplikacja wywołała metodę stopSelf(), chyba że aplikacja znajduje się na tymczasowej liście dozwolonych, aby umożliwić wykonywanie zadania widocznego dla użytkownika.
  • [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI uruchamiać blokady uśpienia ustawione przez aplikację.
• [C-0-11] Urządzenia MUSZĄ zwracać tych dostawców zabezpieczeń jako pierwsze 7 wartości tablicy z metody Security.getProviders() w podanej kolejności oraz z podanymi nazwami (takimi jak Provider.getName()) i klasami, chyba że aplikacja zmodyfikowała listę za pomocą funkcji insertProviderAt() lub removeProvider(). Urządzenia MOGĄ zwrócić dodatkowych dostawców po podanej poniżej liście.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCObejście – 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. Compatibility Test Suite (CTS) testuje znaczną część platformy pod kątem zgodności behawioralnej, ale nie wszystkie. Odpowiada on za zapewnienie zgodności z projektem Android Open Source. Z tego względu tam, gdzie to możliwe, osoby wdrażające na urządzeniach POWINNY są używać kodu źródłowego dostępnego w ramach Android Open Source Project, zamiast ponownie wdrażać istotne części systemu.

3.5.1 Ograniczenie aplikacji

Jeśli implementacje urządzeń implementują zastrzeżony mechanizm ograniczania dostępu aplikacji, który jest bardziej restrykcyjny niż zasobnik gotowości aplikacji z ograniczeniami:

• [C-1-1] MUSI udostępniać listę aplikacji objętych ograniczeniami.
• [C-1-2] MUSI zapewniać użytkownikom dostęp do funkcji włączania i wyłączania ograniczeń w każdej aplikacji.
• [C-1-3] NIE MOŻE automatycznie stosować ograniczeń bez dowodów na słabe działanie systemu, MOŻE jednak zastosować ograniczenia do aplikacji w przypadku wykrycia nieprawidłowego działania systemu, takich jak ciągłe blokady uśpienia, długo działające usługi i inne kryteria. Kryteria MOGĄ być określone przez osoby zajmujące się implementacją urządzenia, ale MUSZĄ być związane z wpływem aplikacji na stan systemu. Inne kryteria, które nie są bezpośrednio związane ze stanem systemu, takie jak brak popularności aplikacji na rynku, NIE mogą być brane pod uwagę.
• [C-1-4] NIE MOŻE automatycznie stosować ograniczeń do aplikacji, gdy użytkownik ręcznie je wyłączył, i MOŻE zasugerować mu zastosowanie ograniczeń
• [C-1-5] MUSI informować użytkowników, jeśli ograniczenia aplikacji są stosowane do aplikacji automatycznie. Takie informacje MUSZĄ zostać udostępnione w ciągu 24 godzin od zastosowania ograniczeń.
• [C-1-6] MUSI zwracać wartość true w przypadku ActivityManager.isBackgroundRestricted(), gdy aplikacja z ograniczeniami wywołuje ten interfejs API.
• [C-1-7] NIE MOŻE ograniczać aplikacji znajdującej się na pierwszym planie, która jest jawnie używana przez użytkownika.
• [C-1-8] MUSI zawiesić ograniczenia w aplikacji, która stanie się aplikacją na pierwszym planie, gdy użytkownik wyraźnie zacznie używać aplikacji, która wcześniej była objęta ograniczeniami.
• [C-1-10] NIE MOŻE zezwalać na automatyczne umieszczanie aplikacji w zasobniku RESTRICTED w ciągu 2 godzin od ostatniego użycia aplikacji przez użytkownika.

Jeśli implementacje urządzeń rozszerzają ograniczenia aplikacji stosowane w AOSP:

• [C-2-1] MUSI postępować zgodnie z implementacją opisaną w tym dokumencie.

3.5.2 Hibernacja aplikacji

Jeśli implementacje urządzeń obejmują hibernację aplikacji, która jest uwzględniona w AOSP lub rozszerza funkcję dostępną w AOSP, wtedy:

• [C-1-1] MUSI spełniać wszystkie wymagania określone w artykule 3.5.1 z wyjątkiem [C-1-6] i [C-1-3].
• [C-1-2] Ograniczenie MUSI nakładać ograniczenie na użytkownika tylko wtedy, gdy istnieją dowody na to, że użytkownik nie używał aplikacji od jakiegoś czasu. Zdecydowanie ZALECANY jest czas trwania co najmniej 1 miesiąca. Użycie MUSI być określone przez jawną interakcję użytkownika za pomocą interfejsu API UsageStats#getLastTimeVisible() lub cokolwiek, co mogłoby spowodować zamknięcie stanu przez aplikację, w tym powiązania usługi, powiązania dostawcy treści, jawne komunikaty itp., które będą śledzone przez nowy interfejs API UsageStats#getLastTimeAny składUsed().
• [C-1-3] MUSI stosować ograniczenia dotyczące wszystkich użytkowników urządzeń tylko wtedy, gdy istnieją dowody na to, że pakiet nie był przez jakiś czas używany przez ŻADNEGO użytkownika. ZALECANE jest, aby długość tego okresu była co najmniej 1 miesiąc.
• [C-1-4] NIE MOŻE renderować aplikacji, która jest w stanie odpowiedzieć na intencje związane z aktywnością, powiązania usług, żądania dostawcy treści lub komunikaty dla pełnoletnich.

Hibernacja aplikacji w AOSP spełnia powyższe wymagania.

3.6. Przestrzenie nazw interfejsów API

Android przestrzega konwencji przestrzeni nazw pakietów i klas zdefiniowanych przez język programowania Java. Aby zapewnić zgodność z aplikacjami innych firm, implementujące urządzenia NIE MOGĄ wprowadzać żadnych zabronionych zmian w tych przestrzeniach nazw pakietów (patrz poniżej):

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

Oznacza to, że:

• [C-0-1] NIE MOŻE modyfikować publicznie dostępnych interfejsów API na platformie Androida przez zmianę podpisów metod lub klas ani przez usunięcie klas czy pól klas.
• [C-0-2] NIE MOŻE dodawać do interfejsów API w powyższych przestrzeniach nazw żadnych publicznie dostępnych elementów (takich jak klasy lub interfejsy, pola czy metody do istniejących klas lub interfejsów) ani testowych interfejsów API czy systemowych interfejsów. „Element widoczny publicznie” to każdy obiekt, który nie jest oznaczony znacznikiem „@hide” używany w nadrzędnym kodzie źródłowym Androida.

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

• [C-0-3] NIE MOŻE mieć wpływu na określone zachowanie ani podpis w języku Java jakichkolwiek publicznie udostępnionych interfejsów API.
• [C-0-4] NIE POWINNY być reklamowane ani w żaden inny sposób prezentowane deweloperom.

Twórcy implementacji urządzeń MOGĄ jednak dodawać niestandardowe interfejsy API poza standardową przestrzenią nazw Androida, ale niestandardowe interfejsy API:

• [C-0-5] NIE MOŻE znajdować się w przestrzeni nazw należącej do innej organizacji lub do innej organizacji. Na przykład implementatory urządzeń NIE MOGĄ dodawać interfejsów API do przestrzeni nazw com.google.* ani do podobnej przestrzeni nazw – może to robić tylko Google. Analogicznie Google NIE MOŻE dodawać interfejsów API do przestrzeni nazw innych firm.
• [C-0-6] MUSI być spakowana w bibliotece współdzielonej Androida, aby większe wykorzystanie pamięci przez takie interfejsy API miało wpływ tylko na aplikacje, które z nich korzystają (za pomocą mechanizmu <uses-library>).

Implementacje urządzeń MOGĄ dodawać niestandardowe interfejsy API w językach ojczystych poza interfejsami NDK API, ale niestandardowe interfejsy API:

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

Jeśli implementujący urządzenie proponuje ulepszenie jednej z przestrzeni nazw pakietów powyżej (np. przez dodanie nowej przydatnej funkcji do istniejącego interfejsu API lub dodanie nowego interfejsu API), implementator POWINIEN otworzyć stronę source.android.com i rozpocząć proces przesyłania zmian i kodu zgodnie z informacjami na tej stronie.

Powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java. Ta sekcja ma tylko utrwalić te konwencje i uczynić je wiążącymi przez uwzględnienie w tej definicji zgodności.

3.7. Zgodność środowiska wykonawczego

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać pełny format DEX (Dalvik Executable) oraz specyfikację i semantykę kodu bajtowego Dalvik.

• [C-0-2] MUSI skonfigurować środowiska wykonawcze Dalvik, aby przydzielać pamięć zgodnie z nadrzędną platformą Androida oraz w tabeli poniżej. (definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).

• POWINIEN użyć środowiska wykonawczego Android (ART), referencyjnej nadrzędnej implementacji formatu wykonywalnego Dalvik i systemu zarządzania pakietami implementacji referencyjnej.

• Aby zapewnić stabilność środowiska wykonawczego, NALEŻY przeprowadzać testy rozmycia w różnych trybach wykonywania i na różnych architekturach. 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ą uważane za wartości minimalne, a implementacje urządzeń MOGĄ przeznaczyć więcej pamięci na aplikację.

Układ ekranu	Gęstość ekranu	Minimalna pamięć aplikacji
Zegarek z Androidem	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)	36MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (Xhdpi)	48MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
mały/normalny	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (Xhdpi)	80MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
duży	120 dpi (ldpi)	32MB
	140 dpi (140dpi)	48MB
	160 dpi (mdpi)
	180 dpi (180dpi)	80MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi (Xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
bardzo duża	120 dpi (ldpi)	48MB
	140 dpi (140dpi)	80MB
	160 dpi (mdpi)
	180 dpi (180dpi)	96MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (Xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8. Zgodność interfejsu użytkownika

3.8.1 Menu z aplikacjami (ekran główny)

Android zawiera aplikację uruchamiającą (ekran główny) i obsługę aplikacji innych firm, które zastępują program uruchamiający (ekran główny).

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

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.home_screen.
• [C-1-2] MUSI zwracać obiekt AdaptiveIconDrawable, gdy aplikacja innej firmy prześle ikonę za pomocą tagu <adaptive-icon>, a wywoływane są metody pobierania ikon PackageManager.

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

• [C-2-1] MUSI zgłosić true za ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] MUSI prosić użytkownika o zgodę przed dodaniem skrótu na żądanie za pomocą metody API ShortcutManager.requestPinShortcut().
• [C-2-3] MUSI obsługiwać przypięte skróty oraz skróty dynamiczne i statyczne zgodnie z opisem na stronie Skróty aplikacji.

Jeśli natomiast implementacje urządzeń nie obsługują przypinania skrótów w aplikacji:

• [C-3-1] MUSI zgłosić false za ShortcutManager.isRequestPinShortcutSupported().

Jeśli implementacje urządzeń implementują domyślny program uruchamiający, który zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu API ShortcutManager, spowoduje to:

• [C-4-1] MUSI obsługiwać wszystkie udokumentowane funkcje skrótów (np. statyczne i dynamiczne skróty, przypinanie skrótów) oraz w pełni implementować interfejsy API klasy API ShortcutManager.

Jeśli implementacje urządzeń zawierają domyślną aplikację uruchamiającą, która wyświetla plakietki przy ikonach aplikacji:

• [C-5-1] MUSI respektować metodę interfejsu API NotificationChannel.setShowBadge(). Inaczej mówiąc, jeśli wartość jest ustawiona jako true, pokazuj wizualizację powiązaną z ikoną aplikacji i nie pokazuj żadnych schematów plakietek ikony aplikacji, jeśli wszystkie kanały powiadomień aplikacji mają ustawioną wartość false.
• MOŻE zastępować plakietki ikony aplikacji ich zastrzeżonym schematem plakietek, gdy aplikacje innych firm wskazują na obsługę zastrzeżonego schematu plakietek za pomocą zastrzeżonych interfejsów API, lecz POWINNY jest korzystać z zasobów i wartości dostarczonych przez interfejsy API z plakietkami powiadomień opisane w pakiecie SDK, takie jak Notification.Builder.setNumber() i interfejs API Notification.Builder.setBadgeIconType().

3.8.2 Widżety

Android obsługuje widżety aplikacji innych firm, definiując typ komponentu i odpowiadający mu interfejs API oraz cykl życia, które pozwalają aplikacjom na udostępnianie użytkownikowi widżetu AppWidget.

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

• [C-1-1] MUSI zadeklarować obsługę funkcji platformy android.software.app_widgets.
• [C-1-2] MUSI zawierać wbudowaną obsługę widżetów AppWidgets i udostępniać funkcje interfejsu użytkownika w celu dodawania, konfigurowania, wyświetlania i usuwania AppWidgets bezpośrednio w Menu z aplikacjami.
• [C-1-3] MUSI wyświetlać widżety o wymiarach 4 x 4 w standardowym rozmiarze siatki. Szczegółowe informacje znajdziesz w dokumencie App Widget DesignGuidelines 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:

• [C-2-1] MUSI zgłosić true za AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] MUSI prosić użytkownika o zgodę przed dodaniem skrótu na żądanie za pomocą metody API AppWidgetManager.requestPinAppWidget().

3.8.3 Powiadomienia

Android obejmuje interfejsy API Notification i NotificationManager, które pozwalają zewnętrznym deweloperom aplikacji na powiadamianie użytkowników o ważnych wydarzeniach i przyciąganie uwagi użytkowników za pomocą komponentów sprzętowych (np. dźwięku, wibracji i światła) oraz funkcji oprogramowania (takich jak obszar powiadomień czy pasek systemu) urządzenia.

3.8.3.1 Prezentacja powiadomień

Jeśli implementacje urządzeń umożliwiają aplikacjom innych firm powiadamianie użytkowników o ważnych wydarzeniach:

• [C-1-1] MUSI obsługiwać powiadomienia korzystające z funkcji sprzętowych zgodnie z opisem w dokumentacji pakietu SDK i w zakresie, w jakim jest to możliwe przy korzystaniu ze sprzętu do implementacji na urządzeniu. Jeśli na przykład urządzenie jest wyposażone w wibrator, MUSI prawidłowo zaimplementować interfejsy API wibracji. Jeśli urządzenie nie ma w nim sprzętu, odpowiednie interfejsy API MUSZĄ być wdrożone w trybie bezobsługowym. Szczegółowe informacje na ten temat znajdziesz w sekcji 7.
• [C-1-2] MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki animacji itp.) przewidziane w interfejsach API lub w przewodniku po stylu ikon paska stanu/paska systemu, choć MOGĄ one zapewniać użytkownikom lepsze wrażenia niż w przypadku referencyjnej implementacji Androida Open Source.
• [C-1-3] MUSI spełniać i wdrażać odpowiednie działania opisane w przypadku interfejsów API w zakresie aktualizowania, usuwania i grupowania powiadomień.
• [C-1-4] MUSI zapewniać pełne działanie notificationChannel w interfejsie API opisanego w pakiecie SDK.
• [C-1-5] MUSI zapewniać użytkownikowi zgodę na blokowanie i modyfikowanie powiadomień z aplikacji innych firm na każdym poziomie kanału i pakietu aplikacji.
• [C-1-6] MUSI też zapewnić użytkownikom możliwość wyświetlania usuniętych kanałów powiadomień.
• [C-1-7] MUSI prawidłowo wyświetlać wraz z tekstem powiadomienia wszystkie zasoby (obrazy, naklejki, ikony itp.) dostarczane przez notification.MessagingStyle. Nie wymaga to dodatkowej interakcji ze strony użytkownika. Na przykład: MUSI pokazywać wszystkie zasoby, w tym ikony udostępnione przez android.app.Person, w rozmowie grupowej ustawionej za pomocą metody setGroupConversation.
• [C-SR-1] Zdecydowanie ZALECANE jest automatyczne wyświetlanie finansów użytkownika w celu blokowania powiadomień z określonej aplikacji innej firmy na każdym kanale i poziomie pakietu aplikacji po tym, jak użytkownik wielokrotnie odrzuci to powiadomienie.
• Zdecydowanie ZALECANE jest umożliwienie użytkownikowi kontrolowania powiadomień wyświetlanych aplikacjom z uprawnieniami Odbiornika powiadomień. Szczegółowość MUSI być taka, aby użytkownik mógł określić dla każdego takiego detektora, jakie typy powiadomień są z nim powiązane. Typy MUSZĄ obejmować „rozmowy”, „alerty”, „wyciszone” i „ważne, aby aktywne” powiadomienia.
• Zdecydowanie ZALECANE jest umożliwienie użytkownikom wskazywania aplikacji, które mają wykluczyć z powiadomienia konkretnego detektora powiadomień.
• OBSŁUGA powiadomień rozszerzonych.
• TRZEBA pokazywać powiadomienia o wyższym priorytecie jako powiadomienia typu HUD.
• MUSISZ mieć możliwość uśpienia powiadomień.
• MOŻE zarządzać tylko widocznością i czasem, w którym aplikacje innych firm mogą powiadamiać użytkowników o ważnych wydarzeniach, aby zniwelować zagrożenia, takie jak rozpraszanie uwagi kierowcy.

Android 11 wprowadza obsługę powiadomień o rozmowach, czyli powiadomień korzystających z funkcji MessagingStyle, które udostępniają opublikowany identyfikator skrótu People.

Implementacje na urządzeniach:

• [C-SR-4] Zdecydowanie ZALECANA jest do grupowania i wyświetlania conversation notifications przed powiadomieniami niezwiązanych z wątkami, z wyjątkiem bieżących powiadomień usługi na pierwszym planie i powiadomień importance:high.

Jeśli implementacje na urządzeniach obsługują conversation notifications, a aplikacja dostarczy wymagane dane na potrzeby bubbles:

• [C-SR-5] Zdecydowanie ZALECANE jest wyświetlanie tej rozmowy w dymku. Implementacja AOSP spełnia te wymagania w domyślnym interfejsie systemu, ustawieniach i Menu z aplikacjami.

Jeśli implementacje urządzeń obsługują powiadomienia rozszerzone, zostaną w nich wprowadzone zmiany:

• [C-2-1] MUSI używać dokładnie takich samych zasobów jak w klasie interfejsu API Notification.Style oraz jej podklasach na potrzeby prezentowanych elementów zasobów.
• POWINNY jest przedstawiać każdy element zasobu (np. ikonę, tytuł i tekst podsumowania) zdefiniowany w klasie interfejsu API Notification.Style i jej podklasach.

Jeśli implementacje urządzenia obsługują powiadomienia HUD:

• [C-3-1] Przy prezentowaniu powiadomień z ostrzeżeniem MUSI używać widoku powiadomień HUD i zasobów zgodnie z opisem w klasie interfejsu API Notification.Builder.
• [C-3-2] MUSI wyświetlać działania wykonane w Notification.Builder.addAction() razem z treścią powiadomienia bez dodatkowej interakcji z użytkownikiem, zgodnie z opisem w pakiecie SDK.

3.8.3.2 Usługa powiadamiania słuchaczy

Android obejmuje interfejsy API NotificationListenerService, które umożliwiają aplikacjom (raz jawnie włączone przez użytkownika) otrzymywanie kopii wszystkich powiadomień w miarę ich publikowania lub aktualizacji.

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo i niezwłocznie aktualizować powiadomienia we wszystkich zainstalowanych i włączonych przez użytkownika usługach detektorów, w tym wszystkie metadane dołączone do obiektu Notification.
• [C-0-2] MUSI respektować wywołanie interfejsu API snoozeNotification() i odrzucać powiadomienie i wywołać wywołanie zwrotne po czasie drzemki ustawionym w wywołaniu interfejsu API.

Jeśli implementacje urządzeń pozwalają użytkownikom na uśpienie powiadomień:

• [C-1-1] MUSI prawidłowo odzwierciedlać stan odłożonych powiadomień za pomocą standardowych interfejsów API, takich jak NotificationListenerService.getSnoozedNotifications().
• [C-1-2] MUSI umożliwić użytkownikom uśpienie powiadomień z każdej zainstalowanej aplikacji innej firmy, chyba że pochodzą one z usług trwałych/działających na pierwszym planie.

3.8.3.3 Nie przeszkadzać

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

• [C-1-1] Jeśli implementacja urządzenia zapewni użytkownikowi możliwość przyznania aplikacjom innych firm dostępu do konfiguracji zasad Nie przeszkadzać, MUSISZ wyświetlać automatyczne reguły Nie przeszkadzać utworzone przez aplikacje wraz z regułami utworzonymi przez użytkownika i wstępnie zdefiniowanymi.
• [C-1-3] MUSI uwzględniać wartości suppressedVisualEffects przekazywane w elemencie NotificationManager.Policy, a jeśli aplikacja ma ustawioną którąkolwiek z flag SUPPRESSED_EFFECT_SCREEN_OFF lub SUPPRESSED_EFFECT_SCREEN_ON, MUSI poinformować użytkownika, że efekty wizualne są wyłączone w menu ustawień Nie przeszkadzać.

3.8.4 Interfejs Assist API

Android obejmuje interfejsy API Asystenta, które pozwalają aplikacjom decydować, ile informacji w bieżącym kontekście ma być udostępniane asystentowi na urządzeniu.

Jeśli implementacje urządzeń obsługują działanie wspomagające, mogą one:

• [C-2-1] MUSI jasno wskazywać użytkownikowi, kiedy jest udostępniany kontekst, na jeden z tych sposobów:
  • Za każdym razem, gdy aplikacja asystująca uzyskuje dostęp do kontekstu i wokół krawędzi ekranu pada białe światło, które wynosi lub przekracza czas trwania i jasność określony w projekcie Android Open Source Project.
  • w przypadku wstępnie zainstalowanej aplikacji asystującej: zapewnienie użytkownikowi możliwości korzystania z domyślnego menu ustawień głosowego wprowadzania tekstu i Asystenta w odległości mniejszej niż 2 nawigacji i udostępnianie kontekstu tylko wtedy, gdy aplikacja asystująca zostanie jawnie wywołana przez użytkownika za pomocą słowa-klucza lub klawisza nawigacji wspomagającej.
• [C-2-2] Wyznaczona interakcja służąca do uruchamiania aplikacji asystującej zgodnie z opisem w sekcji 7.2.3 MUSI uruchomić wybraną przez użytkownika aplikację asystującą, czyli aplikację z funkcją VoiceInteractionService lub działanie obsługujące intencję ACTION_ASSIST.

3.8.5 Alerty i powiadomienia

Aplikacje mogą używać interfejsu API Toast do wyświetlania użytkownikowi krótkich, niemodalnych ciągó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ą wyjście ekranu lub wideo:

• [C-1-1] MUSI zapewniać użytkownikowi dostęp do funkcji TYPE_APPLICATION_OVERLAY, która uniemożliwia aplikacji wyświetlanie okien alertów. Implementacja AOSP spełnia to wymaganie, ponieważ zawiera opcje w obszarze powiadomień.

• [C-1-2] MUSI honorować interfejs Toast API i wyświetlać użytkownikom wygłaszane powiadomienia z aplikacji w jak najbardziej widoczny sposób.

3.8.6 Motywy graficzne

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

Android zawiera rodzinę motywów „Holo” i „Materiał” jako zestaw stylów zdefiniowanych przez deweloperów aplikacji, które mogą wykorzystać, aby dopasować wygląd i sposób działania motywu Holo określone w pakiecie SDK Androida.

Jeśli implementacje urządzeń obejmują wyjście ekranu lub wideo:

• [C-1-1] NIE MOŻE zmieniać żadnych atrybutów motywu Holo widocznych dla aplikacji.
• [C-1-2] MUSI zawierać motywy „Materiał” i NIE MOŻE zmieniać żadnych atrybutów motywu Material Design, ani zasobów prezentowanych w aplikacjach.
• [C-1-3] TRZEBA ustawić rodzinę czcionek „sans-serif” na Roboto w wersji 2.x dla języków obsługiwanych przez Roboto albo podać opcję użytkownika, aby zmienić czcionkę rodziny czcionek „sans-serif” na Roboto w wersji 2.x dla języków obsługiwanych przez Roboto.

Android zawiera także rodzinę motywów „Ustawienie domyślne urządzenia” jako zestaw zdefiniowanych stylów, które programiści aplikacji mogą wykorzystać, aby dopasować wygląd i sposób działania motywu urządzenia określonego przez programistę.

• Implementacje na urządzeniach MOGĄ zmodyfikować atrybuty domyślnego motywu urządzenia widoczne dla aplikacji.

Android obsługuje wariant z przezroczystymi paskami systemowymi, dzięki czemu deweloperzy aplikacji mogą wypełniać obszar za paskiem stanu i paskiem nawigacyjnym treścią aplikacji. Aby programiści mogli w sposób spójny korzystać z tej konfiguracji, styl ikon paska stanu powinien występować na różnych urządzeniach.

Jeśli implementacje urządzeń mają systemowy pasek stanu:

• [C-2-1] MUSI używać białego koloru przy ikonach stanu systemu (takich jak siła sygnału czy poziom baterii) oraz powiadomień wysyłanych przez system, chyba że ikona wskazuje na problematyczny stan lub aplikacja prosi o podświetlenie paska stanu za pomocą flagi WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
• [C-2-2] Gdy aplikacja żąda wyświetlania paska stanu podświetlenia, implementacja na urządzeniach z Androidem MUSI zmienić kolor ikon stanu systemu na czarny (szczegóły znajdziesz w sekcji R.style).

3.8.7 Animowane tapety

Android określa typ komponentu, odpowiedni interfejs API oraz cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi co najmniej jednej „animowanej tapety”. Animowane tapety to animacje, wzory lub podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które wyświetlają się jako tapeta za innymi aplikacjami.

Uznaje się, że urządzenie może niezawodnie wyświetlać animowane tapety, jeśli jest w stanie wyświetlać wszystkie animowane tapety bez ograniczeń w funkcjonalności i z rozsądną liczbą klatek na sekundę bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętu powodują awarie tapet lub aplikacji, nadmiernie obciążają procesor lub baterię albo działają z nieakceptowalnie niską liczbą klatek, uznajemy, że urządzenie nie umożliwia wyświetlania animowanych tapet. Przykład: niektóre tapety animowane mogą wykorzystywać do renderowania treści kontekst OpenGL 2.0 lub 3.x. Animowana tapeta nie będzie działać prawidłowo na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ użycie animowanej tapety w kontekście OpenGL może powodować konflikt z innymi aplikacjami, które korzystają też z kontekstu OpenGL.

• Implementacje animowanych tapet, które umożliwiają sprawne wyświetlanie animowanych tapet, powinny być implementowane powyżej.

Jeśli na urządzeniu są wdrożone animowane tapety:

• [C-1-1] MUSI zgłosić flagę funkcji platformy android.software.live_wallpaper.

3.8.8 Przełączanie aktywności

Nadrzędny kod źródłowy Androida zawiera ekran przeglądu, interfejs na poziomie systemu służący do przełączania zadań oraz wyświetlanie ostatnio używanych czynności i zadań w postaci obrazu miniatury przedstawiającego graficzny stan aplikacji w momencie, gdy użytkownik ostatnio ją opuścił.

Implementacje urządzeń, w tym klawisz nawigacyjny funkcji najnowszych wiadomości, zgodnie z opisem w sekcji 7.2.3, MOGĄ zmienić interfejs.

Jeśli implementacje urządzeń obejmujące klawisz nawigacyjny funkcji ostatnich zgodnie z opisem w sekcji 7.2.3 zmieniają interfejs:

• [C-1-1] MUSI obsługiwać do 7 wyświetlonych działań.
• NALEŻY wyświetlać przynajmniej tytuł 4 aktywności jednocześnie.
• [C-1-2] MUSI włączyć przypinanie ekranu i umożliwiać użytkownikowi włączenie funkcji w menu ustawień.
• W ostatnich przypadkach MUSI wyświetlać kolor zaznaczenia, ikonę i tytuł ekranu.
• POWINIEN wyświetlać afordancję zamykającą („x”), ale MOŻE opóźnić ją do czasu interakcji użytkownika z ekranami.
• NALEŻY zaimplementować skrót, który umożliwi łatwe przechodzenie do poprzedniej aktywności.
• TRZEBA wywołać działanie szybkiego przełączania między 2 ostatnio używanymi aplikacjami, gdy dwukrotnie naciśniesz klawisz funkcji Ostatnie.
• POWINNY jest wyzwalać tryb wielu okien podzielonego ekranu, jeśli jest obsługiwany, po przytrzymaniu klawisza funkcji najnowszych okien.
• MOŻE wyświetlać ostatnie powiązane zdjęcia jako grupę poruszającą się razem.
• [SR-1] Zdecydowanie ZALECANE jest użycie na ekranie przeglądowym interfejsu użytkownika Androida (lub podobnego interfejsu opartego na miniaturach).

3.8.9 Zarządzanie danymi wejściowymi

Android zapewnia obsługę zarządzania danymi wejściowymi oraz zewnętrznych edytorów metod wprowadzania tekstu.

Jeśli implementacje urządzeń pozwalają użytkownikom na korzystanie z zewnętrznych metod wprowadzania na urządzeniu:

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy API IME zgodnie z definicją w dokumentacji pakietu Android SDK.

3.8.10. Sterowanie multimediami na ekranie blokady

Interfejs Remote Control Client API został wycofany z Androida 5.0 i zastąpiony szablonem powiadomienia o multimediach, który umożliwia aplikacjom do multimediów integrowanie się z elementami sterującymi odtwarzaniem wyświetlanymi na ekranie blokady.

3.8.11 Wygaszacze ekranu (wcześniej Sny)

Informacje o ustawieniach związanych z konfigurowaniem wygaszaczy ekranu znajdziesz w sekcji 3.2.3.5.

3.8.12. Lokalizacja

Jeśli urządzenia są wyposażone w czujnik sprzętowy (np. GPS), który może przekazywać współrzędne lokalizacji,

• [C-1-2] MUSI wyświetlać aktualny stan lokalizacji w menu Lokalizacja w Ustawieniach.
• [C-1-3] NIE MOŻE wyświetlać trybów lokalizacji w menu Lokalizacja w Ustawieniach.

3.8.13. Unicode i czcionka

Android obsługuje znaki emotikonów zdefiniowane w Unicode 10.0.

Jeśli implementacje urządzeń obejmują wyjście ekranu lub wideo:

• [C-1-1] MUSI być w stanie renderować znaki z emotikonów w kolorze glifu.
• [C-1-2] MUSI zawierać informacje dotyczące:
  • Czcionka Roboto 2 o różnych wagach: sans-szeryfowa-cienka, bezszeryfowa-lekka, sans-szeryfowa-średnia, bezszeryfowa-czarna, bezszeryfowa-kondensowana, sans-serif-condensed-light dla języków dostępnych na urządzeniu.
  • Pełne pokrycie Unicode 7.0 w alfabecie łacińskim, greckim i cyrylicy, w tym rozszerzone zakresy A, B, C i D alfabetu łacińskiego, a także wszystkie glify w bloku symboli walutowych Unicode 7.0.
• [C-1-3] NIE MOŻE usuwać ani modyfikować pliku NotoColorEmoji.tff z obrazu systemu. (Możesz dodać nową czcionkę, aby zastąpić emotikon w NotoColorEmoji.tff)
• POWINNA obsługiwać odcień skóry i różnorodne emotikony rodzinne zgodnie z raportem technicznym Unicode nr 51.

Jeśli implementacje urządzeń obejmują edytor IME:

• TRZEBA określić metodę wprowadzania znaków w przypadku tych emotikonów.

Android zapewnia obsługę renderowania czcionek birmańskich. Mjanma ma kilka czcionek, które nie są zgodne z ustawą Unicode, potocznie zwanych „Zawgyi”, przeznaczonych do renderowania w językach birmańskich.

Jeśli implementacje urządzeń obejmują obsługę języka birmańskiego:

• [C-2-1] Domyślnie MUSI renderować tekst z użyciem czcionki zgodnej z Unicode. Czcionka niezgodna z tym standardem NIE MOŻE być ustawiona jako domyślna, chyba że użytkownik wybierze ją w selektorze języka.
• [C-2-2] Jeśli urządzenie obsługuje czcionkę inną niż Unicode, musi obsługiwać czcionkę Unicode oraz inną niż Unicode. Czcionka niezgodna z Unicode NIE MOŻE usuwać ani zastępować czcionki Unicode.
• [C-2-3] MUSI renderować tekst z czcionką niezgodną z Unicode TYLKO JEŚLI został określony kod języka z kodem skryptu Qaag (np. my-Qaag). Do odwoływania się do czcionki niezgodnej z Unicode dla Mjanmy nie można używać żadnych innych kodów języków ani regionów ISO (przypisanych, nieprzypisanych lub zarezerwowanych). Deweloperzy aplikacji i autorzy stron internetowych mogą określić my-Qaag jako kod języka tak samo jak w przypadku każdego innego języka.

3.8.14. Wiele okien

Jeśli implementacje urządzeń mogą wyświetlać wiele aktywności jednocześnie, mogą:

• [C-1-1] MUSI wdrożyć takie tryby wielu okien zgodnie z działaniami aplikacji i interfejsami API opisanymi w dokumentacji dotyczącej obsługi trybu wielu okien w pakiecie Android SDK oraz spełnić te wymagania:
• [C-1-2] MUSI uwzględniać parametr android:resizeableActivity ustawiony przez aplikację w pliku AndroidManifest.xml w sposób opisany w tym pakiecie SDK.
• [C-1-3] NIE MOŻE wyświetlać trybu podzielonego ani dowolnego ekranu, jeśli wysokość ekranu jest mniejsza niż 440 dp, a szerokość ekranu jest mniejsza niż 440 dp.
• [C-1-4] NIE MOŻNA zmienić rozmiaru aktywności do rozmiaru mniejszego niż 220 dp w trybach wielu okien innych niż obraz w obrazie.
• Implementacje na urządzeniach o rozmiarze ekranu xlarge POWINNY obsługiwać tryb swobodny.

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

• [C-2-2] MUSI przyciąć aktywność zadokowaną w trybie wielu okien na podzielonym ekranie, ale POWINNA pokazywać część jego zawartości, jeśli aplikacja Menu z aplikacjami jest zaznaczonym oknem.
• [C-2-3] MUSI uwzględniać zadeklarowane wartości AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight zewnętrznego programu uruchamiającego i nie mogą zastępować tych wartości podczas wyświetlania niektórych treści zadokowanej aktywności.

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

• [C-3-1] MUSI uruchamiać działania w trybie wielu okien w trybie obraz w obrazie, gdy aplikacja:

  • Kierowanie na interfejs API na poziomie 26 lub wyższym i deklaracje android:supportsPictureInPicture
  • Kierowanie na interfejs API na poziomie 25 lub niższym i deklaruje zarówno android:resizeableActivity, jak i android:supportsPictureInPicture.

• [C-3-2] MUSI udostępniać działania w interfejsie SystemUI zgodnie z bieżącym działaniem PIP za pomocą interfejsu API setActions().

• [C-3-3] MUSI obsługiwać współczynniki proporcji większe lub równe 1:2,39 i mniejsze lub równe 2,39:1, zgodnie z aktywnością PIP podaną w interfejsie API setAspectRatio().

• [C-3-4] MUSI używać KeyEvent.KEYCODE_WINDOW do sterowania oknem PIP. Jeśli tryb PIP nie jest włączony, klucz MUSI być dostępny dla działania na pierwszym planie.

• [C-3-5] MUSI zapewniać użytkownikowi dostęp do funkcji blokowania wyświetlania aplikacji w trybie PIP. Implementacja AOSP spełnia to wymaganie, ponieważ elementy sterujące znajdują się w obszarze powiadomień.

• [C-3-6] Gdy aplikacja nie zadeklaruje żadnej wartości dla AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight, MUSI przydzielić następujące minimalną szerokość i wysokość do okna PIP:

  • Urządzenia z funkcją Configuration.uiMode ustawioną na inną niż UI_MODE_TYPE_TELEVISION MUSZĄ przydzielać minimalną szerokość i wysokość 108 dp.
  • Urządzenia z funkcją Configuration.uiMode ustawioną na UI_MODE_TYPE_TELEVISION MUSZĄ przydzielać minimalną szerokość 240 dp i minimalną wysokość 135 dp.

3.8.15. Wycięcie w sieci reklamowej

Android obsługuje wycięcie w sieci reklamowej zgodnie z opisem w dokumencie SDK. Interfejs DisplayCutout API definiuje obszar na krawędzi wyświetlacza, który może nie działać w aplikacji ze względu na wycięcie w ekranie lub zakrzywiony wyświetlacz na krawędziach.

Jeśli implementacje urządzeń zawierają wycięcia w ekranie:

• [C-1-5] NIE MOŻE mieć wycięć, jeśli format obrazu wynosi 1,0 (1:1).
• [C-1-2] NIE MOŻE mieć więcej niż jednego wycięcia na krawędź.
• [C-1-3] MUSI uwzględniać flagi wycięcia w ekranie ustawione przez aplikację za pomocą interfejsu API WindowManager.LayoutParams zgodnie z opisem w pakiecie SDK.
• [C-1-4] MUSI podawać prawidłowe wartości dla wszystkich wskaźników wycięcia zdefiniowanych w interfejsie API DisplayCutout.

3.8.16. Sterowanie urządzeniami

Android obejmuje interfejsy API ControlsProviderService i Control, które umożliwiają aplikacjom innych firm publikowanie ustawień urządzenia, co zapewnia użytkownikom szybki stan i wykonanie określonych działań.

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

3.9. Administracja urządzeniem

Android zawiera funkcje, które umożliwiają aplikacjom wykrywającym zabezpieczenia wykonywanie funkcji administracyjnych na poziomie systemu, takich jak wymuszanie stosowania zasad dotyczących haseł lub zdalne czyszczenie pamięci przy użyciu interfejsu Android Device Administration API.

Jeśli implementacje urządzeń obejmują pełny zakres zasad administrowania urządzeniami zdefiniowanych w dokumentacji pakietu Android SDK, pamiętaj o tych kwestiach:

• [C-1-1] MUSI zadeklarować: android.software.device_admin.
• [C-1-2] MUSI obsługiwać obsługę administracyjną 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ądzeń

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

Jeśli implementacje urządzenia zadeklarują android.software.device_admin:

• [C-1-1] MUSI obsługiwać rejestrację klienta Device Policy (DPC) jako aplikacji właściciela urządzenia w sposób opisany poniżej:
  • Jeśli w implementacji urządzenia nie skonfigurowano jeszcze danych użytkownika:
    • [C-1-5] MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia, jeśli urządzenie zadeklaruje obsługę komunikacji Near-Field Communications (NFC) za pomocą flagi funkcji android.hardware.nfc i otrzyma wiadomość NFC zawierającą rekord z typem MIME MIME_TYPE_PROVISIONING_NFC.
    • [C-1-8] MUSI wysłać intencję ACTION_GET_PROVISIONING_MODE po aktywowaniu obsługi administracyjnej właściciela urządzenia, aby aplikacja DPC mogła wybrać, czy ma zostać właścicielem urządzenia czy właścicielem profilu, chyba że z kontekstu wynika, że jest tylko jedna prawidłowa opcja (np. w przypadku obsługi administracyjnej opartej na NFC, gdy obsługa właściciela profilu nie jest obsługiwana).
    • [C-1-9] MUSI wysłać intencję ACTION_ADMIN_POLICY_COMPLIANCE do aplikacji Właściciel urządzenia, jeśli podczas obsługi administracyjnej został zdefiniowany go, niezależnie od użytej metody obsługi administracyjnej. Użytkownik nie może kontynuować pracy z kreatorem konfiguracji, dopóki aplikacja Właściciel urządzenia nie zakończy działania.
  • Gdy implementacja urządzenia zawiera dane użytkownika:
    • [C-1-7] NIE MOŻE rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia.
• [C-1-2] MUSI wymagać wyrażenia zgody przed rozpoczęciem procesu obsługi administracyjnej lub w jego trakcie, aby uzyskać zgodę na ustawienie aplikacji jako właściciela urządzenia. Zgodę można wyrazić w wyniku działania użytkownika lub w inny sposób zautomatyzowany, ale przed rozpoczęciem obsługi administracyjnej właściciela urządzenia MUSI wyświetlić się odpowiednie powiadomienie o ujawnieniu informacji (zgodnie z postanowieniami AOSP). Poza tym mechanizm uzyskiwania zgody właściciela zautomatyzowanego urządzenia używany (przez firmy) do obsługi administracyjnej właściciela urządzenia NIE MOŻE zakłócać działania gotowego urządzenia w przypadku użytkowników innych niż firmy.
• [C-1-3] NIE MOŻE kodować zgody na stałe ani uniemożliwiać korzystania z innych aplikacji właściciela urządzenia.

Jeśli implementacje urządzeń deklarują android.software.device_admin, ale zawierają też zastrzeżone rozwiązanie do zarządzania właścicielem urządzenia i udostępniają mechanizm promowania aplikacji skonfigurowanej w danym rozwiązaniu jako „odpowiednik właściciela urządzenia” znanego przez standardowe interfejsy API Androida DevicePolicyManager:

• [C-2-1] MUSI mieć wdrożony proces pozwalający na sprawdzenie, czy promowana aplikacja należy do legalnego rozwiązania do zarządzania urządzeniami w firmie i została już skonfigurowana w zastrzeżonym rozwiązaniu tak, aby miała odpowiednie uprawnienia jako „Właściciel urządzenia”.
• [C-2-2] MUSI wyświetlać te same informacje o zgodzie właściciela urządzenia AOSP co proces zainicjowany przez android.app.action.PROVISION_MANAGED_DEVICE przed zarejestrowaniem aplikacji DPC jako „właściciela urządzenia”.
• Przed zarejestrowaniem aplikacji DPC jako „właściciela urządzenia” MOŻE mieć na urządzeniu dane użytkownika.

3.9.1.2 Obsługa administracyjna profili zarządzanych

Jeśli implementacje urządzenia zadeklarują android.software.managed_users:

• [C-1-1] MUSI wdrożyć interfejsy API, dzięki czemu aplikacja kontrolera zasad dotyczących urządzeń (DPC) staje się właścicielem nowego profilu zarządzanego.

• [C-1-2] Proces obsługi administracyjnej profilu zarządzanego (proces zainicjowany przez DPC przy użyciu profilu android.app.action.PROVISION_MANAGED_PROFILE) lub przez platformę), ekran zgody i wygoda użytkownika MUSZĄ być zgodne z implementacją AOSP.

• [C-1-3] MUSI udostępniać w Ustawieniach następujące informacje o użytkowniku, aby wskazać użytkownikowi, że dana funkcja systemu została wyłączona przez kontroler zasad dotyczących urządzeń (DPC):

  • Spójna ikona lub inna informacja użytkownika (np. ikona informacji o AOSP) wskazująca, że konkretne ustawienie zostało ograniczone przez administratora urządzenia.
  • Krótki komunikat z wyjaśnieniem dostarczony przez administratora urządzenia na stronie setShortSupportMessage.
  • Ikona aplikacji DPC.

• [C-1-4] MUSI uruchomić moduł obsługi intencji ACTION_PROVISIONING_successFUL w profilu służbowym, jeśli podczas inicjowania obsługi administracyjnej intencja android.app.action.PROVISION_MANAGED_PROFILE został ustanowiony przez DPC moduł obsługi.

• [C-1-5] MUSI wysłać transmisję ACTION_PROFILE_PROVISIONING_COMPLETE do DPC w profilu służbowym po zainicjowaniu obsługi administracyjnej przez intencję android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-6] MUSI wysłać intencję ACTION_GET_PROVISIONING_MODE po aktywowaniu obsługi administracyjnej właściciela profilu, aby aplikacja DPC mogła wybrać, czy zostanie wywołany przez intencję android.app.action.PROVISION_MANAGED_PROFILE, czy zostanie właścicielem urządzenia czy właścicielem profilu.

• [C-1-7] MUSI wysłać intencję ACTION_ADMIN_POLICY_COMPLIANCE do profilu służbowego, gdy podczas obsługi administracyjnej został ustanowiony właściciel profilu, niezależnie od używanej metody obsługi administracyjnej, chyba że jest ona uruchamiana przez intencję android.app.action.PROVISION_MANAGED_PROFILE. Użytkownik nie może mieć możliwości kontynuowania w kreatorze konfiguracji, dopóki aplikacja Właściciel profilu nie zakończy działania.

• [C-1-8] Po ustanowieniu właściciela profilu MUSI wysyłać transmisję ACTION_MANAGED_PROFILE_PROVISIONED do profilu osobistego DPC, niezależnie od użytej metody obsługi administracyjnej.

3.9.2 Obsługa profilu zarządzanego

Jeśli implementacje urządzenia zadeklarują android.software.managed_users:

• [C-1-1] MUSI obsługiwać profile zarządzane za pomocą interfejsów API android.app.admin.DevicePolicyManager.
• [C-1-2] MUSI zezwalać na utworzenie tylko jednego profilu zarządzanego.
• [C-1-3] MUSI mieć plakietkę ikony (podobną do odznaki AOSP nadrzędnego działania) 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ę powiadomień (podobną do plakietki służbowej AOSP na poziomie nadrzędnym), która wskazuje, że użytkownik korzysta z aplikacji profilu zarządzanego.
• [C-1-6] Jeśli istnieje profil zarządzany, MUSI wykazywać wizualną uniwersalność w polu wyboru intencji, aby umożliwić użytkownikowi przekazywanie intencji z profilu zarządzanego głównemu użytkownikowi lub odwrotnie, jeśli włączono go przez kontroler zasad dotyczących urządzeń.
• [C-1-7] Jeśli istnieje profil zarządzany, MUSI udostępniać następujące współczynniki użytkowników zarówno dla użytkownika głównego, jak i profilu zarządzanego:
  • Oddzielne rozliczenia dla baterii, lokalizacji, mobilnej transmisji danych i miejsca na dane dla użytkownika głównego i profilu zarządzanego.
  • Niezależne zarządzanie aplikacjami VPN zainstalowanymi w obrębie głównego użytkownika lub profilu zarządzanego.
  • Niezależne zarządzanie aplikacjami zainstalowanymi w ramach głównego użytkownika lub profilu zarządzanego.
  • Niezależne zarządzanie kontami w ramach głównego użytkownika lub profilu zarządzanego.
• [C-1-8] Zainstalowane aplikacje do telefonu, kontaktów i wiadomości mogą wyszukiwać i wyszukiwać informacje o rozmówcy z profilu zarządzanego (jeśli taki istnieje) wraz z profilami głównymi (jeśli pozwala na to kontroler zasad dotyczących urządzeń).
• [C-1-9] MUSI spełniać wszystkie wymagania bezpieczeństwa obowiązujące na urządzeniu z włączoną obsługą wielu użytkowników (patrz sekcja 9.5), mimo że profil zarządzany nie jest liczony jako inny użytkownik oprócz głównego użytkownika.

Jeśli implementacje urządzenia zadeklarują android.software.managed_users i android.software.secure_lock_screen:

• [C-2-1] MUSI obsługiwać możliwość określania osobnego ekranu blokady spełniającego poniższe wymagania w celu przyznania dostępu tylko do aplikacji działających w profilu zarządzanym.
  • Implementacje na urządzeniu MUSZĄ spełniać intencję DevicePolicyManager.ACTION_SET_NEW_PASSWORD i zawierać interfejs umożliwiający skonfigurowanie osobnych danych logowania na ekranie blokady dla profilu zarządzanego.
  • Dane logowania na ekran blokady profilu zarządzanego MUSZĄ korzystać z tego samego magazynu danych logowania i mechanizmów zarządzania co profil nadrzędny, co zostało opisane na stronie projektu Android Open Source.
  • Zasady dotyczące haseł DPC MUSZĄ mieć zastosowanie tylko do danych logowania na ekranie blokady profilu zarządzanego, chyba że zostaną wywołane przez instancję DevicePolicyManager zwróconej przez getParentProfileInstance.
• Gdy kontakty z profilu zarządzanego są wyświetlane we wstępnie zainstalowanym rejestrze połączeń, interfejsie połączenia, powiadomieniach w toku i nieodebranych połączeniach, kontaktach i aplikacjach do obsługi wiadomości, POWINNY być opatrzone plakietką informującą o aplikacjach profilu zarządzanego.

3.9.3 Zarządzana pomoc dla użytkowników

Jeśli implementacje urządzenia zadeklarują android.software.managed_users:

• [C-1-1] MUSI zapewnić użytkownikowi możliwość wylogowania się z konta bieżącego i przełączenia się z powrotem na użytkownika głównego w sesji wielu użytkowników, gdy isLogoutEnabled zwróci wartość true. Informacje o użytkowniku MUSZĄ być dostępne na ekranie blokady bez odblokowywania urządzenia.

Jeśli implementacje urządzeń zawierają zadeklarowanie android.software.device_admin i zapewniają użytkownikom na urządzeniu dodatkowe możliwości dodawania dodatkowych użytkowników:

• [C-SR-1] Zdecydowanie zalecamy wyświetlanie tych samych informacji o zgodzie właściciela urządzenia AOSP, które były widoczne w procesie zainicjowanym przez android.app.action.PROVISION_MANAGED_DEVICE, przed zezwoleniem na dodawanie kont nowemu użytkownikowi dodatkowemu. Dzięki temu użytkownicy będą wiedzieć, że urządzenie jest zarządzane.

3.10. Ułatwienia dostępu

Android zapewnia warstwę ułatwień dostępu, która ułatwia użytkownikom z niepełnosprawnościami korzystanie z urządzeń. Dodatkowo Android udostępnia interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu otrzymywanie wywołań zwrotnych dla zdarzeń użytkownika i systemów oraz generują alternatywne mechanizmy informacji zwrotnych, takie jak zamiana tekstu na mowę, reakcje haptyczne czy nawigacja za pomocą trackballa/pada kierunkowego.

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

• [C-1-1] MUSI zawierać wdrożenie platformy ułatwień dostępu w Androidzie opisane w dokumentacji interfejsów API ułatwień dostępu pakietu SDK.
• [C-1-2] MUSI generować zdarzenia ułatwień dostępu i dostarczać odpowiednie AccessibilityEvent do wszystkich zarejestrowanych implementacji AccessibilityService zgodnie z opisem w pakiecie SDK.
• [C-1-4] MUSI zapewniać użytkownikowi możliwość kontrolowania usług ułatwień dostępu zadeklarowany przy użyciu przycisku AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_Button. Pamiętaj, że w przypadku implementacji na urządzeniach z paskiem nawigacyjnym systemu użytkownik powinien mieć możliwość sterowania tymi usługami za pomocą przycisku na pasku nawigacyjnym.

Jeśli implementacje urządzeń obejmują wstępnie zainstalowane usługi ułatwień dostępu, te funkcje:

• [C-2-1] MUSI wdrożyć te wstępnie zainstalowane usługi ułatwień dostępu jako aplikacje bezpośredniego rozruchu, gdy dane przechowywane są szyfrowane przy użyciu szyfrowania opartego na plikach (FBE).
• W standardowym procesie konfiguracji należy włączyć mechanizm umożliwiający użytkownikom włączenie odpowiednich usług ułatwień dostępu, a także opcje umożliwiające dostosowanie rozmiaru czcionki i rozmiaru wyświetlacza oraz gestów powiększenia.

3.11. Przekształcanie tekstu na mowę

Android zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług zamiany tekstu na mowę i pozwalają dostawcom usług wdrażać te usługi.

Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.audio.output:

• [C-1-1] MUSI obsługiwać interfejsy API Android TTS Framework.

Jeśli implementacje na urządzeniach obsługują instalację mechanizmu zamiany tekstu na mowę firmy zewnętrznej, funkcje te:

• [C-2-1] MUSI zapewnić wygodę użytkownika, aby mógł on wybrać mechanizm zamiany tekstu na mowę do użycia na poziomie systemu.

3.12. Platforma wejścia TV

Android Television Interface Framework (TIF) ułatwia przesyłanie treści na żywo na urządzenia Android TV. TIF udostępnia standardowy interfejs API do tworzenia modułów wejściowych do sterowania urządzeniami Android TV.

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

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.live_tv.
• [C-1-2] MUSI obsługiwać wszystkie interfejsy API TIF, aby na urządzeniu mogły być instalowane i używane aplikacje korzystające z tych interfejsów oraz zewnętrznej usługi wejściowej opartej na TIF.

3.13. Szybkie ustawienia

Android ma komponent interfejsu Szybkich ustawień, który zapewnia szybki dostęp do często używanych lub pilnych działań.

Jeśli implementacje urządzeń zawierają komponent Szybkie ustawienia i obsługują Szybkie ustawienia innych firm, te funkcje:

• [C-1-1] MUSI umożliwiać użytkownikowi dodawanie kafelków udostępnionych przez interfejsy API quicksettings w aplikacji innej firmy lub ich usuwanie.
• [C-1-2] NIE MOŻE automatycznie dodawać kafelka z aplikacji innej firmy bezpośrednio do Szybkich ustawień.
• [C-1-3] MUSI wyświetlać wszystkie dodane przez użytkowników kafelki z aplikacji innych firm razem z udostępnionymi przez system kafelkami szybkich ustawień.

3.14. Interfejs multimediów

Jeśli implementacje urządzeń obejmują aplikacje nieaktywowane głosem (aplikacje), które współdziałają z aplikacjami innych firm za pomocą MediaBrowser lub MediaSession, aplikacje:

• [C-1-2] MUSZĄ wyraźnie wyświetlać ikony uzyskane za pomocą getIconBitmap() lub getIconUri() oraz tytuły uzyskane za pomocą getTitle(), jak opisano w sekcji MediaDescription. Mogą zostać skrócone, aby zapewnić zgodność z przepisami dotyczącymi bezpieczeństwa (np. aby rozpraszać uwagę kierowcy).

• [C-1-3] MUSI pokazywać ikonę aplikacji innej firmy podczas wyświetlania treści dostarczanych przez tę aplikację.

• [C-1-4] MUSI umożliwiać użytkownikowi interakcję z całą hierarchią MediaBrowser. MOŻE ograniczać dostęp do części hierarchii w celu zachowania zgodności z przepisami dotyczącymi bezpieczeństwa (np. aby rozpraszać uwagę kierowcy), ale NIE MOŻE traktować priorytetowo na podstawie treści lub dostawcy treści.

• [C-1-5] W przypadku MediaSession.Callback#onMediaButtonEvent MUSISZ kliknąć dwukrotnie element KEYCODE_HEADSETHOOK lub KEYCODE_MEDIA_PLAY_PAUSE jako KEYCODE_MEDIA_NEXT.

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 MUSZĄ mieć tylko uprawnienia z atrybutem android:protectionLevel o wartości "instant".
• [C-1-2] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcję z zainstalowanymi aplikacjami za pomocą intencji niejawnych, chyba że spełniony jest jeden z tych warunków:
  • Filtr wzorca intencji komponentu jest widoczny i ma wartość CATEGORY_BROWSABLE
  • Czynność: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
  • Miejsce docelowe jest bezpośrednio widoczne w tagu android:visibleTo InstantApps.
• [C-1-3] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami, chyba że komponent jest udostępniany przez android:visibleTo InstantApps.
• [C-1-4] Zainstalowane aplikacje NIE MOGĄ mieć dostępu do szczegółowych informacji o aplikacjach błyskawicznych na urządzeniu, chyba że zostaną z nimi jednoznacznie połączone.

• Aby możliwa była interakcja z aplikacjami błyskawicznymi, implementacje urządzeń MUSZĄ zapewniać wymienione niżej funkcje. AOSP spełnia wymagania dotyczące domyślnego interfejsu systemu, ustawień i Menu z aplikacjami. Implementacje na urządzeniach:

  • [C-1-5] MUSI zapewnić użytkownikowi możliwość przeglądania i usuwania aplikacji błyskawicznych przechowywanych w lokalnej pamięci podręcznej dla każdego pakietu aplikacji.
  • [C-1-6] MUSI zawierać trwałe powiadomienie użytkownika, które można zwinąć, gdy aplikacja błyskawiczna działa na pierwszym planie. To powiadomienie dla użytkownika MUSI zawierać informację, że Aplikacje błyskawiczne nie wymagają instalacji, a także musi zawierać informacje o ofercie użytkownika, która przekieruje go do ekranu z informacjami o aplikacji w Ustawieniach. W przypadku aplikacji błyskawicznych uruchamianych za pomocą intencji internetowej, zgodnie z definicją za pomocą intencji z działaniem ustawionym na Intent.ACTION_VIEW i schematu „http” lub „https”, dodatkowa obsługa klienta powinna umożliwiać użytkownikowi nieuruchamianie aplikacji błyskawicznej i uruchamianie powiązanego linku przy użyciu skonfigurowanej przeglądarki, o ile na urządzeniu jest dostępna taka przeglądarka.
  • [C-1-7] MUSI umożliwiać uruchamianie aplikacji błyskawicznych z poziomu funkcji Ostatnie, jeśli na urządzeniu jest dostępna ta funkcja.

• [C-1-8] MUSI wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji dla intencji wymienionych w pakiecie SDK tutaj i udostępnić intencje w przypadku aplikacji błyskawicznych.

3.16. Parowanie urządzenia towarzyszącego

Android zapewnia obsługę parowania urządzeń towarzyszących w celu efektywniejszego zarządzania powiązaniami z urządzeniami towarzyszącymi. Udostępnia też interfejs API CompanionDeviceManager , umożliwiający aplikacjom dostęp do tej funkcji.

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

• [C-1-1] MUSI zadeklarować flagę funkcji FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] MUSI upewnić się, że interfejsy API w pakiecie android.companion zostały w pełni zaimplementowane.
• [C-1-3] MUSI zawierać opcje pozwalające na wybór i potwierdzenie, że urządzenie towarzyszące jest dostępne i działa.

3.17. Aplikacje do wagi

Jeśli implementacje na urządzeniach zadeklarują funkcję FEATURE_CANT_SAVE_STATE, to:

• [C-1-1] MUSI mieć zainstalowaną tylko jedną aplikację, która określa działanie cantSaveState w systemie jednocześnie. Jeśli użytkownik opuści taką aplikację bez jej jednoznacznego zamknięcia (np. po wyjściu z systemu przytrzyma przycisk ekranu głównego zamiast cofać się i nie cofnie się, gdy w systemie nie będzie żadnych aktywnych działań), implementacje urządzenia MUSZĄ traktować tę aplikację priorytetowo w ramach pamięci RAM, tak samo jak w przypadku innych funkcji, które powinny 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 sieci.
• [C-1-2] MUSI mieć dostęp do interfejsu użytkownika, aby wybrać aplikację, która nie będzie korzystać z mechanizmu zapisywania/przywracania w normalnym stanie, gdy użytkownik uruchomi drugą aplikację zadeklarowaną z użyciem atrybutu cantSaveState.
• [C-1-3] NIE MOŻE wprowadzać innych zmian w zasadach do aplikacji, które określają cantSaveState, takich jak zmiana wydajności procesora czy priorytety harmonogramu.

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

• [C-1-1] MUSI ignorować atrybut cantSaveState ustawiony przez aplikacje i NIE MOŻE zmieniać działania aplikacji na podstawie tego atrybutu.

3.18. Kontakty

Android obejmuje interfejsy API Contacts Provider, które umożliwiają aplikacjom zarządzanie informacjami kontaktowymi przechowywanymi na urządzeniu. Dane kontaktowe wprowadzane bezpośrednio na urządzeniu są zwykle synchronizowane z usługą internetową, ale MOGĄ też znajdować się tylko lokalnie na urządzeniu. Kontakty przechowywane tylko na urządzeniu są nazywane kontaktami lokalnymi.

Nieprzetworzone kontakty są „powiązane” lub „przechowywane na” koncie, gdy kolumny ACCOUNT_NAME i ACCOUNT_TYPE nieprzetworzonych kontaktów pasują do odpowiednich pól Account.name i Account.type na tym koncie.

Domyślne konto lokalne: konto do nieprzetworzonych kontaktów, które są przechowywane tylko na urządzeniu i nie są powiązane z kontem w usłudze AccountManager, które są utworzone z wartościami null w kolumnach ACCOUNT_NAME i ACCOUNT_TYPE.

Niestandardowe konto lokalne: konto do nieprzetworzonych kontaktów, które są przechowywane tylko na urządzeniu i nie są powiązane z kontem w usłudze AccountManager, utworzone z co najmniej jedną niepustą wartością w kolumnach ACCOUNT_NAME i ACCOUNT_TYPE.

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest nietworzenie niestandardowych kont lokalnych.

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

• [C-1-1] Dane ACCOUNT_NAME niestandardowego konta lokalnego MUSZĄ zostać zwrócone do ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] Dane ACCOUNT_TYPE niestandardowego konta lokalnego MUSZĄ zostać zwrócone do ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] Nieprzetworzone kontakty wstawione przez aplikacje innych firm na domyślnym koncie lokalnym (np. przez ustawienie wartości null dla ACCOUNT_NAME i ACCOUNT_TYPE) MUSZĄ zostać wstawione do niestandardowego konta lokalnego.
• [C-1-4] Nieprzetworzone kontakty wstawione do niestandardowego konta lokalnego NIE NALEŻY usuwać podczas dodawania lub usuwania kont.
• [C-1-5] Operacje usuwania wykonane na niestandardowym koncie lokalnym MUSZĄ natychmiast spowodować trwałe usunięcie nieprzetworzonych kontaktów (jak gdyby parametr CALLER_IS_SYNCADAPTER miał wartość Prawda), nawet jeśli parametr CALLER\_IS\_SYNCADAPTER ma wartość Fałsz lub nie został określony.

4. Zgodność pakietów aplikacji

Implementacje urządzeń:

• [C-0-1] MUSI mieć możliwość instalowania i uruchamiania plików „.apk” Androida generowanych za pomocą narzędzia „aapt” zawartego w oficjalnym pakiecie Android SDK.
  • Powyższe wymaganie może być trudne, dlatego ZALECANE jest użycie systemu zarządzania pakietami implementacji referencyjnej AOSP na urządzeniach.

Implementacje na urządzeniach:

• [C-0-2] MUSI obsługiwać weryfikację plików „.apk” przy użyciu schematu podpisu APK w wersji 3, schematu podpisu APK w wersji 2 i podpisywania plików JAR.
• [C-0-3] NIE MOŻE rozszerzać formatów plików .apk, pliku manifestu Androida, kodu bajtowego Dalvik ani kodu bajtowego RenderScriptu w taki sposób, że uniemożliwiałoby to prawidłowe instalowanie i działanie tych plików na innych zgodnych urządzeniach.

• [C-0-4] NIE MOŻE zezwalać aplikacjom innym niż obecny „zarejestrowany instalator” pakietu na dyskretne odinstalowanie aplikacji bez potwierdzenia ze strony użytkownika, zgodnie z dokumentacją pakietu SDK dotyczącą uprawnień DELETE_PACKAGE. Jedynymi wyjątkami są intencja obsługi aplikacji weryfikatora pakietów systemowych PACKAGE_NEEDS_VERIFICATION i intencja aplikacji menedżera miejsca obsługującego ACTION_MANAGE_STORAGE.

• [C-0-5] MUSI mieć działanie, które obsługuje intencję android.settings.MANAGE_UNKNOWN_APP_SOURCES.

• [C-0-6] NIE MOŻE instalować pakietów aplikacji z nieznanych źródeł, chyba że aplikacja, która żąda instalacji, spełnia wszystkie poniższe wymagania:

  • MUSI zadeklarować uprawnienie REQUEST_INSTALL_PACKAGES lub mieć android:targetSdkVersion ustawiony na wartość 24 lub niższą.
  • MUSI on mieć uprawnienia do instalowania aplikacji z nieznanych źródeł.

• MUSI zapewnić użytkownikowi zgodę na przyznanie lub unieważnienie uprawnień do instalowania aplikacji z nieznanych źródeł w poszczególnych aplikacjach. MOŻE jednak zastosować to rozwiązanie jako brak działania i zwrócić RESULT_CANCELED w przypadku domeny startActivityForResult(), jeśli implementacja urządzenia nie chce, aby użytkownicy mieli taki wybór. Jednak nawet w takich przypadkach należy poinformować użytkownika, dlaczego nie ma takiego wyboru.

• [C-0-7] MUSI wyświetlać okno z ostrzeżeniem z ciągiem ostrzeżenia dostarczonym przez systemowy interfejs API PackageManager.setHarmfulAppWarning przed uruchomieniem działania w aplikacji, która została oznaczona przez ten sam systemowy interfejs API PackageManager.setHarmfulAppWarning jako potencjalnie szkodliwą.

• MUSI udostępniać użytkownikowi możliwość odinstalowania lub uruchomienia aplikacji w oknie ostrzeżenia.

• [C-0-8] MUSI wdrożyć obsługę przyrostowego systemu plików, jak opisano tutaj.

• [C-0-9] MUSI obsługiwać weryfikację plików .apk przy użyciu schematu podpisu pliku APK w wersji 4.

5. Zgodność multimediów

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać formaty multimedialne, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w sekcji 5.1 dla każdego kodeka zadeklarowanego przez MediaCodecList.
• [C-0-2] MUSI zadeklarować obsługę koderów i dekoderów dostępnych dla aplikacji innych firm za pomocą MediaCodecList.
• [C-0-3] MUSI prawidłowo dekodować i udostępniać aplikacjom innych firm wszystkie formaty, które potrafi kodować. Dotyczy to wszystkich strumieni bitowych generowanych przez jego kodery oraz profili raportowanych w CamcorderProfile.

Implementacje na urządzeniach:

• NALEŻY dążyć do minimalnego opóźnienia kodeka. Inaczej mówiąc,
  • NIE POWINNY jest wykorzystywać ani przechowywać buforów wejściowych ani zwrotnych buforów wejściowych tylko po przetworzeniu.
  • NIE NALEŻY przechowywać zdekodowanych buforów przez czas dłuższy niż określony w standardzie (np. SPS).
  • NIE NALEŻY przechowywać kodowanych buforów dłużej niż wymaga tego struktura GOP.

Wszystkie kodeki wymienione w poniższej sekcji zostały udostępnione jako implementacje programowe w preferowanej implementacji na Androida w ramach projektu Android Open Source Project.

Google ani stowarzyszenie Open Handset Alliance nie twierdzą, że kodeki są wolne od patentów innych firm. Wszystkim, którzy mają wykorzystywać ten kod źródłowy w sprzęcie lub oprogramowaniu, zalecamy, aby jego implementacja, w tym w oprogramowaniu typu open source, jak i shareware, wymagała licencji opatentowanych przez posiadaczy odpowiednich patentów.

5.1. Kodeki multimediów

5.1.1 Kodowanie dźwięku

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

Jeśli implementacje urządzeń z zadeklarowaniem 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] 16-bitowa natywna kolejność bajtów audio w formacie PCM za pomocą interfejsu API android.media.MediaCodec.

5.1.2 Dekodowanie dźwięku

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

Jeśli implementacje urządzeń deklarują obsługę funkcji android.hardware.audio.output, muszą obsługiwać dekodowanie tych formatów audio:

• [C-1-1] Profil AAC MPEG-4 (AAC LC)
• [C-1-2] Profil AAC MPEG-4 HE (AAC+)
• [C-1-3] Profil MPEG-4 HE AACv2 (ulepszony AAC+)
• [C-1-4] AAC ELD (rozszerzony format AAC z niskim opóźnieniem)
• [C-1-11] xHE-AAC (Rozszerzony profil AAC w normie ISO/IEC 23003-3, który obejmuje profil bazowy USAC oraz profil kontroli zakresu dynamiki 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 to wymaganie dotyczy wyłącznie dekodowania, a urządzenie może zmniejszać i miksować w fazie odtwarzania.
• [C-1-10] Opus

Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC strumieni wielokanałowych (tj. więcej niż 2 kanałów) do PCM za pomocą domyślnego dekodera dźwięku AAC w interfejsie API android.media.MediaCodec, MUSZĄ być obsługiwane te elementy:

• [C-2-1] Dekodowanie MUSI być wykonywane bez redmiksowania (np. strumień AAC 5.0 należy zdekodować na 5 kanałów PCM, a strumień AAC 5.1 na 6 kanałów PCM).
• [C-2-2] Metadane zakresu dynamicznego MUSZĄ być zgodne z definicją w dokumencie „Dynamic Range Control (DRC)” w standardzie ISO/IEC 14496-3 oraz kluczami DRC android.media.MediaFormat w celu skonfigurowania działania dekodera dźwięku w zakresie dynamiki. 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 ZALECANE jest, aby wszystkie dekodery audio AAC spełniały wymagania opisane powyżej.

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

• [C-3-1] Natężenie dźwięku i metadane DRC MUSZĄ być interpretowane i stosowane zgodnie z regulacją zakresu dynamiki MPEG-D DRC na poziomie 1.
• [C-3-2] Dekoder MUSI działać zgodnie z konfiguracją ustawioną za pomocą tych kluczy android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_DRC_EFFECT_TYPE.

Dekodery profilu MPEG-4 AAC, HE AAC i HE AACv2:

• MOŻE obsługiwać sterowanie głośnością i zakresem dynamicznym zgodnie z normą ISO/IEC 23003-4.

Jeśli obsługiwany jest standard ISO/IEC 23003-4, a metadane ISO/IEC 23003-4 i ISO/IEC 14496-3 znajdują się w zdekodowanym strumieniu bitowym, to:

• Metadane ISO/IEC 23003-4 MUSZĄ mieć pierwszeństwo.

Wszystkie dekodery audio MUSZĄ obsługiwać:

• [C-6-1] 16-bitowa natywna kolejność bajtów audio w formacie PCM za pomocą interfejsu API android.media.MediaCodec.

5.1.3 Szczegóły kodeków audio

Format/kodek	Szczegóły	Obsługiwane typy plików i kontenerów
Profil AAC MPEG-4 (AAC LC)	Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 8 do 48 kHz.	3GPP (.3GPP) MPEG-4 (.mp4, .m4a) Nieprzetworzony kod AAC ADTS (AAC, ADIF nie jest obsługiwany) MPEG-TS (.ts, bez możliwości przewijania, tylko dekodowanie) matroska (.mkv, tylko dekodowanie)
Profil MPEG-4 HE AAC (AAC+)	Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.	3GPP (.3GPP) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profil (rozszerzony AAC+)	Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.	3GPP (.3GPP) MPEG-4 (.mp4, .m4a)
AAC ELD (rozszerzone AAC z niskim opóźnieniem)	Obsługa treści mono/stereo ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.	3GPP (.3GPP) MPEG-4 (.mp4, .m4a)
USAC	Obsługa treści mono/stereo ze standardowymi częstotliwościami próbkowania od 7,35 do 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75–12,2 kb/s, próbkowanie przy 8 kHz	3GPP (.3GPP)
AMR-WB	9 o częstotliwości od 6,60 kb/s do 23,85 kb/s, próbkowanie przy 16 kHz, zgodnie z definicją na stronie AMR-WB, adaptacyjna wiele prędkości – szerokopasmowy kodek mowy	3GPP (.3GPP)
FLAC	Zarówno w przypadku kodera, jak i dekodera: MUSISZ obsługiwać co najmniej tryby mono i stereo. Częstotliwość próbkowania do 192 kHz MUSI być obsługiwana; MUSI być obsługiwana rozdzielczość 16- i 24-bitowa. 24-bitowa obsługa danych audio FLAC MUSI być dostępna w konfiguracji dźwięku zmiennoprzecinkowego.	FLAC (.flac) MPEG-4 (.mp4, .m4a, tylko dekodowanie) matroska (.mkv, tylko dekodowanie)
MP3	Stała szybkość transmisji bitów mono/Stereo 8–320 kb/s (CBR) lub zmienna szybkość transmisji bitów (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, tylko dekodowanie) matroska (.mkv, tylko dekodowanie)
MIDI	MIDI typu 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody	Wpisz 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-bitową liczbę zmiennoprzecinkową. Ekstraktor WAVE musi obsługiwać 16-, 24-bitowy i 32-bitowy linearny PCM, oraz 32-bitową transmisję zmiennoprzecinkową (o wartości do najniższego limitu sprzętowego). Częstotliwość próbkowania MUSI być obsługiwana w przedziale od 8 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, 12 000, 16000, 24 000 i 48 000 Hz Kodowanie: obsługa treści mono i stereo z częstotliwością próbkowania 8000, 12 000, 0, 0, 16000, 1	Ogg (.ogg) MPEG-4 (.mp4, .m4a, tylko dekodowanie) matroska (.mkv) Webm (.webm)

5.1.4 Kodowanie obrazu

Więcej informacji znajdziesz w artykule 5.1.6. Szczegóły kodeków graficznych.

Implementacje na urządzeniu MUSZĄ obsługiwać kodowanie 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 w przypadku multimediów MIMETYPE_IMAGE_ANDROID_HEIC:

• [C-1-1] MUSI udostępniać kodek HEVC z akceleracją sprzętową, który obsługuje tryb kontroli szybkości transmisji bitów BITRATE_MODE_CQ, profil HEVCProfileMainStill i rozmiar klatki 512 x 512 pikseli.

5.1.5 Dekodowanie obrazu

Więcej informacji znajdziesz w artykule 5.1.6. Szczegóły kodeków graficznych.

Implementacje na urządzeniu MUSZĄ obsługiwać dekodowanie tego kodowania obrazu:

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

Jeśli implementacje urządzeń obsługują dekodowanie wideo HEVC:

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

Dekodery obrazów, które obsługują format o dużej głębi bitowej (co najmniej 9 bitów na kanał):

• [C-2-1] MUSI obsługiwać wyświetlanie równoważnego formatu 8-bitowego, jeśli zażąda tego aplikacja, na przykład za pomocą konfiguracji ARGB_8888 android.graphics.Bitmap.

5.1.6 Szczegóły kodeków obrazu

Format/kodek	Szczegóły	Obsługiwane typy plików/formaty kontenerów
JPEG	Podstawowy+progresywny	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png),
BMP		BMP (.bmp),
WebP		WebP (.webp)
Nieprzetworzony		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Obraz, kolekcja obrazów, sekwencja obrazów	HEIF (.heif), HEIC (.heic)

Koder obrazu i dekodery dostępne przez interfejs API MediaCodec

• [C-1-1] MUSI obsługiwać elastyczny format kolorów YUV420 w formacie 8:8:8 (COLOR_FormatYUV420Flexible) do CodecCapabilities.

• [SR-1] Zdecydowanie zalecana jest obsługa formatu kolorów RGB888 w trybie powierzchni wejściowej.

• [C-1-3] MUSI obsługiwać co najmniej jeden format koloru YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (odpowiednik COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (odpowiednik COLOR_FormatYUV420SemiPlanar). Zdecydowanie zalecamy stosowanie tych formatów.

5.1.7 Kodeki wideo

• Aby zapewnić akceptowalną jakość strumieniowego przesyłania filmów i usług do wideokonferencji, w implementacjach urządzeń WYMAGANE jest użycie sprzętowego kodeka VP8 spełniającego wymagania.

Jeśli implementacje urządzeń obejmują dekoder lub koder wideo:

• [C-1-1] Kodeki wideo MUSZĄ obsługiwać rozmiary wyjściowego bufora bajtowego i wejściowego, które odpowiadają największej możliwej do możliwości skompresowanej i nieskompresowanej klatki zgodnie ze standardem i konfiguracją, ale nie w ogólnym formacie.

• [C-1-2] Kodery i dekodery wideo MUSZĄ obsługiwać elastyczne formaty kolorów YUV420 8:8:8 (COLOR_FormatYUV420Flexible) do CodecCapabilities.

• [C-1-3] Kodery i dekodery wideo MUSZĄ obsługiwać co najmniej jeden planarny lub półplanarny format kolorów YUV420 o proporcjach 8:8:8: COLOR_FormatYUV420PackedPlanar (odpowiednik COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (odpowiednik COLOR_FormatYUV420SemiPlanar). Zdecydowanie ZALECANE są w przypadku obu formatów.

• [SR-1] Zdecydowanie ZALECANE są kodery i dekodery wideo, które obsługują co najmniej jeden zoptymalizowany sprzętowo planarny lub półpłaszczyzny YUV420 w formacie kolorów 8:8:8 (YV12, NV12, NV21 lub równoważny format zoptymalizowany przez dostawcę).

• [C-1-5] Dekodery wideo, które obsługują format o wysokiej głębi bitowej (co najmniej 9 bitów na kanał), MUSZĄ obsługiwać wyświetlanie równoważnego formatu 8-bitowego, jeśli wymaga tego aplikacja. MUSI być uwzględniana przez obsługę formatu kolorów YUV420 o współczynniku proporcji 8:8:8 za pomocą android.media.MediaCodecInfo.

Jeśli implementacje urządzeń reklamują obsługę profilu HDR w Display.HdrCapabilities:

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

Jeśli implementacje urządzeń sygnalizują obsługę wewnątrzodświeżania w ramach funkcji FEATURE_IntraRefresh w klasie MediaCodecInfo.CodecCapabilities:

• [C-3-1] MUSI obsługiwać okresy odświeżania w zakresie 10–60 klatek i musi działać prawidłowo z zakresu 20% skonfigurowanego okresu odświeżania.

Jeśli w aplikacji nie określono inaczej przy użyciu klucza formatu KEY_COLOR_FORMAT, implementacje dekodera wideo:

• [C-4-1] MUSI domyślnie korzystać z formatu koloru zoptymalizowanego pod kątem sprzętowego wyświetlacza, jeśli został skonfigurowany z wykorzystaniem wyjścia Surface.
• [C-4-2] MUSI mieć domyślnie ustawiony format kolorów YUV420 o współczynniku proporcji 8:8:8 zoptymalizowany pod kątem odczytu przez procesor, jeśli skonfigurowano nieużywanie danych wyjściowych z powierzchni

5.1.8 Lista kodeków wideo

Format/kodek	Szczegóły	Obsługiwane typy plików i kontenerów
H.263		3GPP (.3GPP) MPEG-4 (MP4) matroska (.mkv, tylko dekodowanie)
H.264 AVC	Szczegółowe informacje znajdziesz w sekcji 5.2 i 5.3	3GPP (.3GPP) MPEG-4 (MP4) MPEG-2 TS (.ts, brak możliwości przewijania) 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, bez możliwości przewijania) MPEG-4 (.mp4, tylko dekodowanie) matroska (.mkv, tylko dekodowanie)
MPEG-4 SP		3GPP (.3GPP) MPEG-4 (MP4) matroska (.mkv, tylko dekodowanie)
VP8	Szczegółowe informacje znajdziesz w sekcjach 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

Implementacja na urządzeniu MUSI zapewniać zgodność z opisanymi poniżej funkcjami zabezpieczeń kodeków multimediów.

Android obsługuje OMX, wieloplatformowy interfejs multimedialny acceleration API, a także Codec 2.0, czyli niskobudżetowy interfejs multimedialny acceleration API.

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

• [C-1-1] MUSI zapewniać obsługę kodeków multimedialnych za pomocą interfejsów API OMX lub Codec 2.0 (albo obu tych interfejsów), tak jak w projekcie Android Open Source Project, i nie może wyłączać ani omijać zabezpieczeń. Nie oznacza to, że każdy kodek MUSI korzystać z interfejsu API OMX lub Codec 2.0, tylko obsługa co najmniej jednego z tych interfejsów API MUSI być dostępna, a obsługa dostępnych interfejsów API MUSI obejmować używane funkcje zabezpieczeń.
• [C-SR-1] Zdecydowanie ZALECANE jest włączenie obsługi interfejsu API Codec 2.0.

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

• [C-2-1] MUSI zawierać odpowiedni kodek OMX z Android Open Source Project (jeśli jest dostępny) dla każdego formatu multimediów i typu (kodera lub dekodera) obsługiwanego przez urządzenie.
• [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 ZALECANE jest używanie kodeków OMX w procesie kodeka, który nie ma dostępu do sterowników sprzętowych innych niż mapy pamięci.

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

• [C-3-1] MUSI zawierać odpowiedni kodek oprogramowania Codec 2.0 z projektu Android Open Source (jeśli jest dostępny) dla każdego formatu multimediów i typu (kodera lub dekodera) obsługiwanego przez urządzenie.
• [C-3-2] MUSI włączać kodeki Codec 2.0 w procesie kodeka, zgodnie z projektem Android Open Source, aby umożliwić węższe przyznawanie dostępu do kodeków.
• [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:

• [C-1-1] MUSI zwracać prawidłowe wartości charakteru kodeka multimediów przez interfejs API MediaCodecInfo.

W szczególności:

• [C-1-2] Kodeki o nazwach zaczynających się od „OMX”. MUSI używać interfejsów OMX API i mieć nazwy zgodne z wytycznymi dotyczącymi nazw OMX IL.
• [C-1-3] Kodeki o nazwach zaczynających się od „c2”. MUSI używać interfejsu API Codec 2.0 i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa w usłudze Codec 2.0 dla Androida.
• [C-1-4] Kodeki o nazwach zaczynających się od „OMX.google.” lub „c2.android”. NIE MOŻNA określać jako dostawcy ani stosować akceleracji sprzętowej.
• [C-1-5] Kodeki działające w ramach procesu kodeka (od dostawcy lub systemu) z dostępem do sterowników sprzętowych innych niż przydzielające pamięć i programy do mapowania NIE mogą być określane jako „tylko oprogramowanie”.
• [C-1-6] Kodeki, których nie ma w projekcie Android Open Source lub nieoparte na kodzie źródłowym w tym projekcie, MUSZĄ być określone jako dostawca.
• [C-1-7] Kodeki, które korzystają z akceleracji sprzętowej, MUSZĄ być opisane jako z akceleracją sprzętową.
• [C-1-8] Nazwy kodeków NIE MOGĄ wprowadzać w błąd. Na przykład kodeki o nazwie „dekodery” MUSZĄ obsługiwać dekodowanie, a te o nazwie „enkodery” MUSZĄ obsługiwać kodowanie. Kodeki o nazwach zawierających formaty multimediów MUSZĄ obsługiwać te formaty.

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

• [C-2-1] Wszystkie kodeki wideo MUSZĄ publikować dane o możliwej do osiągnięcia liczbie klatek w następujących rozmiarach, jeśli dany kodek jest obsługiwany:

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	176 x 144 piks. (H263, MPEG2, MPEG4) 352 x 288 pikseli (koder MPEG4, H263, MPEG2) 320 x 180 piks. (VP8, VP8) 320 x 240 piks. (inne)	704 x 576 piks. (H263) 640 x 360 piks. (VP8, VP9) 640 x 480 piks. (koder MPEG4) 720 x 480 piks. (inne)	1408 x 1152 piks. (H263) 1280 x 720 piks. (inne)	1920 x 1080 piks. (inne niż MPEG4)	3840 x 2160 piks. (HEVC, VP9)

• [C-2-2] Kodeki wideo z akceleracją sprzętową MUSZĄ publikować informacje o punktach wydajności. Każda z nich MUSI zawierać listę wszystkich obsługiwanych standardowych punktów wydajności (wymienionych w interfejsie API PerformancePoint), chyba że są one objęte innym obsługiwanym standardowym punktem wydajności.
• Dodatkowo POWINNY jest publikować rozszerzone punkty skuteczności, jeśli wymagają one utrzymywania stałej skuteczności filmu innej niż jeden z wymienionych wyżej standardowych punktów.

5.2. Kodowanie wideo

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

• W dwóch oknach przesuwanych NIE POWINNO być o ponad 15% wyższe niż szybkość transmisji bitów między interwałami wewnątrzklatki (I-frame).
• Szybkość transmisji bitów NIE POWINNO przekraczać 100% w przesuwanym oknie o długości 1 sekundy.

Jeśli implementacje urządzeń obejmują osadzony wyświetlacz o przekątnej co najmniej 2,5 cala, port wyjściowy wideo lub zadeklarowanie obsługi kamery za pomocą flagi funkcji android.hardware.camera.any:

• [C-1-1] MUSI obsługiwać co najmniej jeden z koderów wideo VP8 lub H.264 i udostępniać go aplikacjom innych firm.
• POWINNA obsługiwać kodery wideo VP8 i H.264 oraz udostępniać je aplikacjom innych firm.

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

• [C-2-1] MUSI obsługiwać dynamicznie konfigurowane szybkości transmisji bitów.
• POWINNY być obsługiwane zmienne liczby klatek, gdzie koder wideo POWINNY określać ciągły czas trwania klatek na podstawie sygnatur czasowych buforów wejściowych i przydzielać zasobnik bity na podstawie tej długości.

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

• POWINNA obsługiwać dynamicznie konfigurowane szybkości transmisji bitów dla obsługiwanego kodera.

Jeśli implementacje urządzeń udostępniają kodery wideo lub graficzne z akceleracją sprzętową i obsługują co najmniej 1 podłączoną lub podłączaną kamerę sprzętową dostępną za pomocą interfejsów API android.camera:

• [C-4-1] Wszystkie kodery wideo i obrazów z akceleracją sprzętową MUSZĄ obsługiwać kodowanie klatek z kamer sprzętowych.
• POWINNA obsługiwać kodowanie klatek z kamer sprzętowych we wszystkich koderach wideo i koderów graficznych.

Jeśli urządzenia obsługują kodowanie HDR:

• Zdecydowanie zaleca się udostępnić wtyczkę [C-SR-1] do interfejsu API płynnego transkodowania, która umożliwia konwersję z formatu HDR na format SDR.

5.2.1 H.263

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

• [C-1-1] MUSI obsługiwać profil podstawowy poziomu 45.
• POWINNA obsługiwać dynamicznie konfigurowane szybkości transmisji bitów dla obsługiwanego kodera.

5.2.2 H.264

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

• [C-1-1] MUSI obsługiwać profil podstawowy poziomu 3. Jednak obsługa ASO (Arbitrary Slice Ordering), FMO (elastyczne porządkowanie makr) i RS (nadmiarowe wycinki) jest OPCJONALNA. Co więcej, ze względu na zachowanie zgodności z innymi urządzeniami z Androidem ZALECAMY, by kodery ASO, FMO i RS nie używały koderów do profilu podstawowego.
• [C-1-2] MUSI obsługiwać profile kodowania wideo w jakości SD (standardowej rozdzielczości) z poniższej tabeli.
• POWINNY jest obsługiwać profil główny na poziomie 4.
• POWINNA obsługiwać profile kodowania wideo HD (High Definition) zgodnie z informacjami w poniższej tabeli.

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

• [C-2-1] MUSI obsługiwać profile kodujące z poniższej tabeli.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 240 piks.	720 x 480 piks.	1280 x 720 piks.	1920 x 1080 piks.
Liczba klatek w filmie	20 kl./s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	384 Kb/s	2 Mb/s	4 Mb/s	10 Mb/s

5.2.3 VP8

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

• [C-1-1] MUSI obsługiwać profile kodowania wideo SD.
• POWINNA obsługiwać poniższe profile kodowania wideo HD (High Definition).
• [C-1-2] MUSI obsługiwać zapisywanie plików Matroska WebM.
• MUSI dostarczyć sprzętowy kodek VP8, który spełnia wymagania dotyczące sprzętowego kodowania RTC w projekcie WebM, aby zapewnić akceptowalną jakość strumieniowego przesyłania filmów i usług do prowadzenia rozmów wideo.

Jeśli implementacje urządzeń zgłaszają obsługę kodowania VP8 w przypadku filmów w rozdzielczości 720p lub 1080p za pomocą interfejsów API multimediów:

• [C-2-1] MUSI obsługiwać profile kodujące z poniższej tabeli.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 180 piks.	640 x 360 piks.	1280 x 720 piks.	1920 x 1080 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	4 Mb/s	10 Mb/s

5.2.4 VP9

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

• [C-1-2] MUSI obsługiwać profil 0 na poziomie 3.
• [C-1-1] MUSI obsługiwać zapisywanie plików Matroska WebM.
• [C-1-3] MUSI generować dane CodecPrivate.
• KONIECZNIE jest obsługa profili dekodowania HD zgodnie z informacjami w poniższej tabeli.
• Jeśli używasz kodera sprzętowego, Zdecydowanie zaleca się korzystanie z profili dekodowania HD zgodnie z informacjami w tabeli poniżej.

	SD	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	720 x 480 piks.	1280 x 720 piks.	1920 x 1080 piks.	3840 x 2160 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

Jeśli implementacje urządzeń deklarują, że obsługują Profil 2 lub Profil 3 za pomocą interfejsów Media API:

• Obsługa formatu 12-bitowego jest OPCJONALNA.

5.2.5 H.265

Jeśli implementacje urządzeń obsługują kodek H.265:

• [C-1-1] MUSI obsługiwać profil główny na poziomie 3.
• POWINNA obsługiwać profile kodowania HD zgodnie z informacjami w tej tabeli.
• Jeśli używasz kodera sprzętowego, Zdecydowanie zaleca się korzystanie z profili kodowania HD zgodnie z informacjami w tabeli poniżej.

	SD	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	720 x 480 piks.	1280 x 720 piks.	1920 x 1080 piks.	3840 x 2160 piks.
Liczba klatek w filmie	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:

• [C-1-1] MUSI obsługiwać dynamiczną rozdzielczość obrazu i przełączanie liczby klatek za pomocą standardowych interfejsów API Androida w tym samym strumieniu w przypadku wszystkich kodeków VP8, VP9, H.264 i H.265 w czasie rzeczywistym z maksymalną rozdzielczością obsługiwaną przez każdy kodek na urządzeniu.

5.3.1 MPEG-2

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

• [C-1-1] MUSI obsługiwać wysoki poziom profilu głównego.

5.3.2 H.263

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

• [C-1-1] MUSI obsługiwać profil podstawowy na poziomie 30 i 45.

5.3.3 MPEG-4

Urządzenia obsługujące dekodery MPEG-4:

• [C-1-1] MUSI obsługiwać prosty profil na poziomie 3.

5.3.4 H.264

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

• [C-1-1] MUSI obsługiwać profil główny na poziomie 3.1 i profil podstawowy. Obsługa ASO (Arbitrary Slice Ordering), FMO (elastyczne porządkowanie makr) i RS (nadmiarowe wycinki) jest OPCJONALNA.
• [C-1-2] MUSI dekodować filmy za pomocą profili SD (standardowej rozdzielczości) wymienionych w tabeli poniżej i zakodować przy użyciu profilu podstawowego i profilu głównego na poziomie 3.1 (w tym 720p30).
• MUSI dekodować filmy w profilach HD (High Definition) zgodnie z informacjami w poniższej tabeli.

Jeśli wysokość zgłoszona przez metodę Display.getSupportedModes() jest równa lub większa od rozdzielczości wideo, sposoby implementacji na urządzeniach:

• [C-2-1] MUSI obsługiwać profile dekodowania wideo HD 720p z poniższej tabeli.
• [C-2-2] MUSI obsługiwać profile dekodowania wideo HD 1080p z poniższej tabeli.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 240 piks.	720 x 480 piks.	1280 x 720 piks.	1920 x 1080 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	60 kl./s	30 kl./s (60 kl./s, telewizja)
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

5.3.5 H.265 (HEVC)

Jeśli implementacje urządzeń obsługują kodek H.265:

• [C-1-1] MUSI obsługiwać profil główny poziomu 3 i profile dekodowania wideo SD zgodnie z poniższą tabelą.
• KONIECZNIE jest obsługa profili dekodowania HD zgodnie z informacjami w poniższej tabeli.
• Jeśli jest dekoder sprzętowy, [C-1-2] MUSI obsługiwać profile dekodowania HD zgodnie z informacjami w poniższej tabeli.

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

• [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden dekodowanie H.265 lub VP9 w profilach 720, 1080 i UHD.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	352 x 288 piks.	720 x 480 piks.	1280 x 720 piks.	1920 x 1080 piks.	3840 x 2160 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 klatek/s	30/60 kl./s (60 kl./s, telewizja 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ądzenia twierdzą, że obsługują profil HDR za pomocą interfejsów Media API:

• [C-3-1] Implementacje urządzeń MUSZĄ akceptować wymagane metadane HDR z aplikacji oraz obsługiwać wyodrębnianie i wyświetlanie wymaganych metadanych HDR ze strumienia bitowego lub kontenera.
• [C-3-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR na ekranie urządzenia lub w standardowym porcie wyjściowym wideo (np. HDMI).

5.3.6 VP8

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

• [C-1-1] MUSI obsługiwać profile dekodowania SD z poniższej tabeli.
• POWINNY jest używać sprzętowego kodeka VP8, który spełnia wymagania.
• MUSI obsługiwać profile dekodowania HD z poniższej tabeli.

Jeśli wysokość zgłoszona przez metodę Display.getSupportedModes() jest równa lub większa od rozdzielczości wideo, to:

• [C-2-1] Implementacje na urządzeniach MUSZĄ obsługiwać profile 720p z poniższej tabeli.
• [C-2-2] Implementacje na urządzeniach MUSZĄ obsługiwać profile 1080p z poniższej tabeli.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 180 piks.	640 x 360 piks.	1280 x 720 piks.	1920 x 1080 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 kl./s (60 kl./s, telewizja)	30 (60 kl./s, telewizja)
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

5.3.7 VP9

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

• [C-1-1] MUSI obsługiwać profile dekodowania wideo SD zgodnie z informacjami w poniższej tabeli.
• KONIECZNIE jest obsługa profili dekodowania HD zgodnie z informacjami w poniższej tabeli.

Jeśli implementacje urządzeń obsługują kodek VP9 i dekoder sprzętowy:

• [C-2-1] MUSI obsługiwać profile dekodowania HD zgodnie z poniższą tabelą.

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

• [C-3-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden dekodowanie formatów VP9 lub H.265 z profilu 720, 1080 lub UHD.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	320 x 180 piks.	640 x 360 piks.	1280 x 720 piks.	1920 x 1080 piks.	3840 x 2160 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 klatek/s	30 kl./s (60 kl./s, telewizja z sprzętowym dekodowaniem VP9)	60 kl./s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

Jeśli implementacje urządzeń deklarują, że obsługują VP9Profile2 lub VP9Profile3 za pomocą interfejsów API multimediów 'CodecProfileLevel':

• Obsługa formatu 12-bitowego jest OPCJONALNA.

Jeśli implementacje urządzenia twierdzą, że obsługują profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) za pomocą interfejsów API multimediów:

• [C-4-1] Implementacje na urządzeniu MUSZĄ akceptować wymagane metadane HDR (KEY_HDR_STATIC_INFO w przypadku wszystkich profili HDR oraz KEY_HDR10_PLUS_INFO' dla profili HDR10Plus) z aplikacji. Muszą też obsługiwać wyodrębnianie i eksportowanie wymaganych metadanych HDR z strumienia bitowego lub kontenera.
• [C-4-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR na ekranie urządzenia lub w standardowym porcie wyjściowym wideo (np. HDMI).

5.3.8 Dolby Vision

Jeśli implementacje urządzeń zadeklarują obsługę dekodera Dolby Vision za pomocą HDR_TYPE_DOLBY_VISION:

• [C-1-1] MUSI zawierać moduł wyodrębniający z obsługą Dolby Vision.
• [C-1-2] MUSI prawidłowo wyświetlać treści Dolby Vision na ekranie urządzenia lub w standardowym porcie wyjściowym wideo (np. HDMI).
• [C-1-3] MUSI ustawić indeks ścieżki zgodnych wstecznie warstw podstawowych (jeśli występują) na taki sam jak indeks ścieżki połączonej warstwy Dolby Vision.

5.3.9 AV1

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

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

5.4. Nagrywanie dźwięku

Chociaż niektóre z wymagań opisanych w tej sekcji są wymienione jako „POWINNY” od Androida 4.3, w przyszłości planujemy zmienić definicję zgodności w przyszłości na MUSZĄ. Zdecydowanie ZALECANE są zarówno istniejące, jak i nowe urządzenia z Androidem spełniające wymienione poniżej wymagania. W przeciwnym razie nie będą w stanie osiągnąć zgodności z Androidem po uaktualnieniu do nowej wersji.

5.4.1 Przechwycony dźwięk i informacje z mikrofonu

Jeśli implementacje urządzenia zadeklarują android.hardware.microphone:

• [C-1-1] MUSI umożliwiać przechwytywanie nieprzetworzonych treści audio o tych cechach:

  • Format: linearny PCM, 16-bitowy
  • Częstotliwość próbkowania: 8000, 11025, 16 000, 44 100, 48 000 Hz
  • Kanały: mono

• POWINNA zezwalać na przechwytywanie nieprzetworzonych treści audio o tych cechach:

  • Format: liniowy PCM, 16- i 24-bitowy
  • Częstotliwość próbkowania: 8000, 11025, 16 000, 22 050, 24 000, 32 000, 44 100, 48 000 Hz
  • Kanały: tyle kanałów, ile wynosi liczba mikrofonów urządzenia.

• [C-1-2] MUSI przechwytywać z większą częstotliwością próbkowania bez próbkowania w górę.

• [C-1-3] MUSI zawierać odpowiedni filtr antyaliasing, jeśli podane powyżej częstotliwości próbkowania są odczytywane przy użyciu próbkowania w dół.

• NALEŻY zezwolić na przechwytywanie nieprzetworzonych treści audio w jakości radia AM i DVD, co oznacza następujące cechy:

  • Format: linearny PCM, 16-bitowy
  • Częstotliwość próbkowania: 22 050, 48 000 Hz
  • Kanały: stereo

• [C-1-4] MUSI spełniać wymagania interfejsu API MicrophoneInfo i odpowiednio podawać informacje o mikrofonach dostępnych na urządzeniu dostępnych dla aplikacji innych firm przez interfejs API AudioManager.getMicrophones() oraz o obecnie aktywnych mikrofonach, które są dostępne 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:

• [C-2-1] MUSI przechwytywać bez próbkowania w górę przy współczynniku wyższego niż 16 000:22050 lub 44100:48000.

• [C-2-2] MUSI zawierać odpowiedni filtr antyaliasingowy w przypadku próbkowania w górę lub w dół.

5.4.2 Zrób zdjęcie, by włączyć rozpoznawanie głosu

Jeśli implementacje urządzenia zadeklarują android.hardware.microphone:

• [C-1-1] MUSI przechwytywać źródło dźwięku android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION z jedną z częstotliwości próbkowania – 44 100 lub 48 000.
• [C-1-2] Podczas nagrywania strumienia audio ze źródła AudioSource.VOICE_RECOGNITION MUSISZ domyślnie wyłączyć przetwarzanie dźwięku z redukcją szumów.
• [C-1-3] Domyślnie MUSI wyłączyć automatyczną kontrolę wzmocnienia podczas nagrywania strumienia audio ze źródła dźwięku AudioSource.VOICE_RECOGNITION.
• NAGRYWAJ strumień audio rozpoznawania głosu o względnie płaskiej amplitudzie względem charakterystyki częstotliwości: ±3 dB, od 100 Hz do 4000 Hz.
• Strumień audio rozpoznawania głosu należy nagrywać z czułością sygnału wejściowego. Źródło mocy akustycznej o wartości 90 dB (SPL) przy 1000 Hz daje RMS 2500 dla próbek 16-bitowych.
• MUSI nagrywać strumień audio rozpoznawania głosu, tak aby amplituda PCM liniowo śledziła poziom SPL wejściowej na poziomie co najmniej 30 dB od -18 dB do +12 dB do 90 dB poziomu SPL mikrofonu.
• NAGRYWANIE strumienia audio rozpoznawania głosu z całkowitym zniekształceniem harmonicznym (THD) poniżej 1% dla częstotliwości 1 kHz przy 90 dB na poziomie sygnału SPL na mikrofonie.

Jeśli implementacje urządzeń zadeklarują android.hardware.microphone i technologie eliminowania szumów (redukcji szumów) dostosowanych do rozpoznawania mowy, te funkcje:

• [C-2-1] MUSI umożliwiać sterowanie tym efektem dźwiękowym za pomocą interfejsu API android.media.audiofx.NoiseSuppressor.
• [C-2-2] MUSI jednoznacznie identyfikować każdą implementację technologii eliminowania szumów za pomocą pola AudioEffect.Descriptor.uuid.

5.4.3 Zrób zdjęcie, aby zmienić trasę odtwarzania

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

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

• [C-1-1] MUSI prawidłowo zaimplementować źródło dźwięku REMOTE_SUBMIX, aby aplikacja, która nagrywa za pomocą interfejsu API android.media.AudioRecord, przechwytywała kombinację wszystkich strumieni audio oprócz tych:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4 Reduktor echa akustycznego

Jeśli implementacje urządzenia zadeklarują android.hardware.microphone:

• Trzeba wdrożyć technologię akustycznego redukcji echa (AEC) dostosowaną do komunikacji głosowej i stosować ją do ścieżki przechwytywania podczas nagrywania z użyciem AudioSource.VOICE_COMMUNICATION

Jeśli implementacje urządzeń udostępniają akustyczną redukcję echa, która jest wstawiana w ścieżce przechwytywania dźwięku po wybraniu opcji AudioSource.VOICE_COMMUNICATION:

• [C-SR-1] jest STRONGLY_RECOMMENDED do zadeklarowania tego za pomocą AcousticEchoCanceler metody API AcousticEchoCanceler.isAvailable()
• [C-SR-2] są STRONGLY_RECOMMENDED wymagane, aby można było sterować tym efektem dźwiękowym za pomocą interfejsu API AcousticEchoCanceler.
• [C-SR-3] są STRONGLY_RECOMMENDED niezbędne do jednoznacznego identyfikowania każdej implementacji technologii AEC za pomocą pola AudioEffect.Descriptor.uuid.

5.4.5 Jednoczesne przechwytywanie

Jeśli implementacje urządzeń z zadeklarowaną wartością android.hardware.microphone MUSZĄ włączyć przechwytywanie równoległe,zgodnie z opisem w tym dokumencie. Więcej szczegółów:

• [C-1-1] MUSI zezwalać na równoczesny dostęp do mikrofonu usłudze ułatwień dostępu, która przechwytuje za pomocą AudioSource.VOICE_RECOGNITION i co najmniej 1 aplikacji przechwytującej za pomocą dowolnego AudioSource.
• [C-1-2] MUSI zezwalać na równoczesny dostęp do mikrofonu wstępnie zainstalowanej aplikacji, która ma przypisaną rolę Asystenta, oraz co najmniej jednej aplikacji przechwytującej dane przy użyciu dowolnej z funkcji AudioSource oprócz AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER.
• [C-1-3] MUSI wyciszać przechwytywanie dźwięku w innych aplikacjach (z wyjątkiem usługi ułatwień dostępu), gdy aplikacja przechwytuje za pomocą AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER. Jeśli jednak aplikacja rejestruje rozmowę za pomocą AudioSource.VOICE_COMMUNICATION, inna aplikacja może zarejestrować połączenie głosowe, o ile jest to aplikacja uprzywilejowana (wstępnie zainstalowana) z uprawnieniami CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Jeśli co najmniej 2 aplikacje przechwytują jednocześnie i żadna z nich nie ma interfejsu użytkownika, to ta, która zaczęła rejestrować dźwięk jako ostatnia, odbiera dźwięk.

5.4.6 Poziomy wzmocnienia mikrofonu

Jeśli implementacje urządzenia zadeklarują android.hardware.microphone:

• POWINNA wzmacniać w przybliżeniu płaską amplitudę w porównaniu z częstotliwością w średnim zakresie częstotliwości: ±3 dB od 100 Hz do 4000 Hz dla każdego mikrofonu użytego do nagrywania źródła dźwięku rozpoznawania głosu.
• NALEŻY ustawić czułość sygnału wejściowego dźwięku w taki sposób, aby sinusoidalne źródło o częstotliwości 1000 Hz odtwarzane przy poziomie ciśnienia akustycznego 90 dB (SPL) generowało odpowiedź z wartością RMS 2500 dla 16-bitowych próbek (lub -22,35 dB w pełnej skali -22,35 dB w przypadku każdego dźwięku zmiennoprzecinkowego lub podwójnej precyzji do nagrywania każdego źródła dźwięku z mikrofonem).
• [C-SR-1] Zdecydowanie ZALECANE jest działanie amplitudy w niskim zakresie częstotliwości: od ±20 dB od 5 Hz do 100 Hz w porównaniu do średniego zakresu częstotliwości dla każdego mikrofonu użytego do nagrywania dźwięku z rozpoznawania głosu.
• Zdecydowanie zalecamy, aby [C-SR-2] posiadała amplitudę w zakresie wysokich częstotliwości: od ±30 dB od 4000 Hz do 22 kHz w porównaniu ze średnią częstotliwością dla każdego mikrofonu użytego do nagrywania źródła dźwięku.

5.5. Odtwarzanie dźwięku

Android umożliwia zezwolenie aplikacjom na odtwarzanie dźwięku przez wyjście audio peryferyjnego zgodnie z definicją w sekcji 7.8.2.

5.5.1 Odtwarzanie surowego dźwięku

Jeśli implementacje urządzenia zadeklarują android.hardware.audio.output:

• [C-1-1] MUSI umożliwiać odtwarzanie nieprzetworzonych treści audio o tych cechach:

  • Formaty źródłowe: linearny PCM, 16-bitowy, 8-bitowy, liczba zmiennoprzecinkowa
  • Kanały: mono, stereo, prawidłowe konfiguracje wielokanałowe, maksymalnie 8 kanałów
  • Częstotliwość próbkowania (w Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 w konfiguracjach kanałów wymienionych powyżej
    • 96 000 w mono i stereo

5.5.2 Efekty audio

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

Jeśli implementacje urządzenia zadeklarują funkcję android.hardware.audio.output:

• [C-1-1] MUSI obsługiwać implementacje EFFECT_TYPE_EQUALIZER i EFFECT_TYPE_LOUDNESS_ENHANCER, które można kontrolować za pomocą podklasy 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 sterowaną za pomocą podklasy AudioEffect DynamicsProcessing.
• POWINNA 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 BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.AudioEffect
• [C-SR-1] Zdecydowanie ZALECANE jest obsługa efektów w formatach zmiennoprzecinkowych i wielokanałowych.

5.5.3 Wyjściowa głośność dźwięku

Implementacje na urządzeniach motoryzacyjnych:

• POWINNY jest zezwalać na dostosowywanie głośności dźwięku oddzielnie dla każdego strumienia audio z użyciem typu lub użycia treści zdefiniowanego w parametrach AudioAttributes oraz wykorzystania audio w samochodzie zgodnie z publicznie zdefiniowanym w zasadzie android.car.CarAudioManager.

5.5.4 Odciążanie dźwięku

Jeśli implementacje urządzeń obsługują odciążanie odtwarzania dźwięku:

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

5.6. Opóźnienie dźwięku

Opóźnienie dźwięku to czas, w którym sygnał audio przechodzi przez system. Wiele klas aplikacji korzysta z krótkich opóźnień w celu uzyskania efektów dźwiękowych w czasie rzeczywistym.

Na potrzeby tej sekcji należy stosować następujące definicje:

• opóźnienia wyjścia. Odstęp czasu między momentem, w którym aplikacja zapisuje ramkę danych kodowanych w PCM, a odebraniem odpowiedniego dźwięku przez przetwornik lub sygnał na urządzeniu.
• opóźnienia „na zimno”. Czas od rozpoczęcia strumienia wyjściowego do wyświetlenia pierwszej klatki określony na podstawie sygnatur czasowych, kiedy system wyjścia audio był bezczynny i wyłączony przed żądaniem.
• ciągły czas oczekiwania na sygnał wyjściowy. Opóźnienie na wyjściu dla kolejnych klatek, gdy urządzenie zacznie odtwarzać dźwięk.
• opóźnienia sygnału wejściowego. Odstęp czasu, jaki upływa od momentu, gdy środowisko dociera do urządzenia za pomocą przetwornika lub sygnału urządzenia na urządzeniu, a odstępem między momentem, w którym aplikacja odczytuje odpowiednią ramkę danych kodowanych w PCM.
• utraconych danych wejściowych. Początkowa część sygnału wejściowego, który jest bezużyteczny lub niedostępny.
• opóźnienia „zimnego sygnału wejściowego”. Czas między rozpoczęciem strumienia a odebraniem pierwszej prawidłowej klatki, gdy system wejścia audio był nieaktywny i wyłączony przed żądaniem.
• ciągłe opóźnienie sygnału wejściowego. opóźnienie sygnału wejściowego dla kolejnych klatek, gdy urządzenie rejestruje dźwięk.
• zakłócenia przy zimnie. Zmienność pomiędzy osobnymi pomiarami wartości czasu oczekiwania na „zimne” dane wyjściowe.
• zakłócenia przy zimnie. zmienność między osobnymi pomiarami wartości opóźnienia danych wejściowych „na zimno”.
• ciągłe opóźnienie w obie strony. Suma ciągłego opóźnienia sygnału wejściowego i ciągłego opóźnienia na wyjściu oraz 1 okresu buforowania. Okres buforowania to czas na przetworzenie przez aplikację sygnału i czas na złagodzenie różnic fazowych między strumieniami wejściowymi i wyjściowymi.
• Interfejs API kolejki buforowej OpenSL ES PCM. Zbiór interfejsów API OpenSL ES związanych z PCM w ramach Android NDK.
• Natywny interfejs API audio audio Zestaw interfejsów API AAudio w systemie Android NDK.
• Sygnatura czasowa. Para składająca się z względnego położenia klatki w strumieniu i szacowanego czasu wejścia tej klatki do potoku przetwarzania audio w powiązanym punkcie końcowym lub go opuszczania. Patrz też AudioTimestamp.
• glitch. Tymczasowa przerwa w działaniu lub nieprawidłowa wartość próbki w sygnale audio, zwykle spowodowana zaniżeniem bufora wyjściowego, przepełnieniem bufora dla wejścia lub jakimkolwiek innym źródłem szumu cyfrowego bądź analogowego.
• średnie odchylenie bezwzględne. Średnia z wartości bezwzględnych odchyleń od średniej dla zbioru wartości.
• czas oczekiwania przy dotknięciu tonu. Czas między kliknięciem ekranu a dźwiękiem wygenerowanym przez kliknięcie w głośniku.

Jeśli implementacje urządzeń zawierają deklarację android.hardware.audio.output, MUSZĄ one spełniać lub przewyższać te wymagania:

• [C-1-1] Sygnatura czasowa wyjścia zwracana przez funkcję AudioTrack.getTimestamp i AAudioStream_getTimestamp ma dokładność +/- 2 ms.
• [C-1-2] Opóźnienie podczas wczytywania „na zimno” (maks. 500 milisekund).

Jeśli implementacje urządzeń deklarują użycie funkcji android.hardware.audio.output, Zdecydowanie ZALECANE jest spełnienie lub przekroczenie tych wymagań:

• [C-SR-1] Opóźnienie reakcji „na zimno” wynoszące maksymalnie 100 milisekund w ścieżce danych głośnika. Dotychczasowe i nowe urządzenia, które działają w tej wersji Androida, Zdecydowanie Zdecydowanie Zdecydowanie Zdecydowanie zalecamy, aby już teraz spełnić te wymagania. W przyszłej wersji platformy opóźnienie sygnału wyjściowego „na zimno” nie może przekraczać 200 ms.
• [C-SR-2] Opóźnienie reakcji na dotknięcie: maksymalnie 80 milisekund.
• [C-SR-3] Zminimalizuj zakłócenia na zimno.
• [C-SR-4] Sygnatura czasowa wyjścia zwracana przez funkcje AudioTrack.getTimestamp i AAudioStream_getTimestamp ma dokładność z dokładnością do +/- 1 ms.

Jeśli implementacje urządzeń spełniają powyższe wymagania, po początkowej kalibracji przy korzystaniu z natywnego interfejsu audio AAudio, w celu zapewnienia ciągłego opóźnienia i opóźnienia „na zimno” na co najmniej 1 obsługiwanym urządzeniu wyjściowym audio:

• [C-SR-5] Zdecydowanie zaleca się przesyłać dźwięk z małym opóźnieniem przez zadeklarowanie flagi funkcji android.hardware.audio.low_latency.
• [C-SR-6] Zdecydowanie zalecana jest spełnienie wymagań dotyczących dźwięku z małym opóźnieniem przez interfejs AAudio API.
• [C-SR-7] Zdecydowanie zalecamy, aby w przypadku strumieni, które zwracają wartość AAUDIO_PERFORMANCE_MODE_LOW_LATENCY z AAudioStream_getPerformanceMode(), wartość zwracana przez AAudioStream_getFramesPerBurst() jest mniejsza niż wartość zwracana przez android.media.AudioManager.getProperty(String) dla klucza właściwości AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Jeśli implementacje urządzeń nie spełniają wymagań dotyczących dźwięku z małym opóźnieniem generowanym przez interfejs AAudio natywnego interfejsu API audio:

• [C-2-1] NIE MOŻE zgłaszać obsługi dźwięku z małym opóźnieniem.

Jeśli implementacje urządzeń obejmują android.hardware.microphone, MUSZĄ one spełniać te wymagania dotyczące wejściowego dźwięku:

• [C-3-1] Ogranicz błąd w wejściowych sygnaturach czasowych zwracanych przez funkcję AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/- 2 ms. „Błąd” oznacza tutaj odchylenie od prawidłowej wartości.
• [C-3-2] Opóźnienie reakcji „na zimno” wynoszące maksymalnie 500 milisekund.

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

• [C-SR-8] Opóźnienie podczas działania „na zimno” na ścieżce danych mikrofonu wynoszące maksymalnie 100 milisekund. Zdecydowanie Zdecydowanie Zdecydowanie Zdecydowanie zalecamy już teraz spełnienie tych wymagań zarówno w przypadku dotychczasowych, jak i nowych urządzeń, na których działa ta wersja Androida. W przyszłej wersji platformy opóźnienie sygnału wejściowego „na zimno” nie może przekraczać 200 ms.
• [C-SR-9] Ciągłe opóźnienie sygnału wejściowego: maksymalnie 30 milisekund.
• [C-SR-10] Zminimalizuj zakłócenia sygnału wejściowego „na zimno”.
• [C-SR-11] Ogranicz błąd w wejściowych sygnaturach czasowych zwracanych przez funkcję AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/- 1 ms.

Jeśli implementacje urządzenia zadeklarują android.hardware.audio.output i android.hardware.microphone:

• [C-SR-12] Zdecydowanie ZALECANY jest średni czas oczekiwania w obie strony na poziomie 50 milisekund lub mniej w przypadku 5 pomiarów przy średnim odchyleniu bezwzględnym mniejszym niż 10 ms na co najmniej 1 obsługiwanej ścieżce.

5.7. Protokoły sieciowe

Implementacje urządzeń MUSZĄ obsługiwać protokoły sieci multimedialnej do odtwarzania dźwięku i obrazu zgodnie z opisem w dokumentacji pakietu Android SDK.

W przypadku każdego kodeka i formatu kontenera wymaganej przez implementację urządzenia:

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

• [C-1-2] MUSI obsługiwać odpowiednie formaty segmentów multimediów, tak jak pokazano w tabeli formatów segmentów multimedialnych poniżej. Wymagana jest obsługa wersji roboczej protokołu transmisji na żywo przez HTTP w wersji 7.

• [C-1-3] MUSI obsługiwać odpowiednie formaty ładunków protokołu RTSP, jak pokazano w tabeli poniżej. Informacje o wyjątkach znajdziesz w przypisach w sekcji 5.1.

Formaty segmentów multimediów

Formaty segmentów	Pliki referencyjne	Wymagana obsługa kodeka
Zapis strumienia MPEG-2	ISO 13818	Kodeki wideo: H264 AVC MPEG-4 SP MPEG-2 Szczegółowe informacje o kodach 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 kadrowaniem 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	Pliki referencyjne	Wymagana obsługa kodeka
H264 AVC	RFC 6184	Szczegółowe informacje o H264 AVC znajdziesz w sekcji 5.1.8
MP4A-LATM	RFC 6416	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.3
H263–1998	RFC 3551 RFC 4629 RFC 2190	Szczegółowe informacje o H263 znajdziesz w sekcji 5.1.8
H263–2000	RFC 4629	Szczegółowe informacje o H263 znajdziesz w sekcji 5.1.8
AMR	RFC 4867	Szczegółowe informacje o AMR-NB znajdziesz w sekcji 5.1.3
AMR-WB	RFC 4867	Szczegółowe informacje o AMR-WB znajdziesz w sekcji 5.1.3
MP4V-ES	RFC 6416	Szczegółowe informacje o MPEG-4 SP znajdziesz w sekcji 5.1.8
mpeg4-generic,	RFC 3640	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.3
Plik MP2T	RFC 2250	Więcej informacji znajdziesz w sekcji Strumień transportu MPEG-2 pod nagłówkiem Transmisja na żywo przez HTTP

5.8. Bezpieczne nośniki

Jeśli implementacje urządzeń obsługują bezpieczne wyjście wideo i bezpieczne platformy, to:

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

Jeśli implementacje urządzeń zadeklarują, że obsługują Display.FLAG_SECURE i protokół wyświetlania bezprzewodowego,:

• [C-2-1] W przypadku ekranów połączonych protokołami bezprzewodowymi, np. Miracast, połączenie MUSI zabezpieczyć link silnym kryptograficznie mechanizmem, np. HDCP 2.x lub nowszym.

Jeśli implementacje urządzeń deklarują obsługę interfejsu Display.FLAG_SECURE i przewodowego wyświetlacza zewnętrznego,:

• [C-3-1] MUSI obsługiwać standard HDCP 1.2 lub nowszy w przypadku wszystkich wyświetlaczy zewnętrznych podłączonych do dostępnego dla użytkownika portu przewodowego.

5.9. Interfejs MIDI (Musical Instrument Digital Interface)

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

• [C-1-1] MUSI obsługiwać MIDI w przypadku wszystkich transportów sprzętowych obsługujących MIDI, dla których zapewniają one ogólne połączenia inne niż MIDI, w których:

  • Tryb hosta USB, sekcja 7.7
  • MIDI przez Bluetooth LE w głównej roli, sekcja 7.4.3

• [C-1-2] MUSI obsługiwać transport oprogramowania MIDI między aplikacjami (wirtualne urządzenia MIDI)

• [C-1-3] MUSI zawierać libamidi.so (natywna obsługa MIDI).

• POWINNA OBSŁUGA MIDI przez tryb urządzenia peryferyjnego USB (sekcja 7.7)

5.10. Profesjonalne treści audio

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

• [C-1-1] MUSI zgłosić pomoc dotyczącą funkcji android.hardware.audio.low_latency.
• [C-1-2] MUSI mieć ciągłe opóźnienie dźwięku w obie strony (opisane w sekcji 5.6 Czas oczekiwania na dźwięk), MUSI wynosić nie więcej niż 20 milisekund i 10 milisekund w przypadku co najmniej jednej obsługiwanej ścieżki.
• [C-1-3] MUSI zawierać porty USB obsługujące tryb hosta USB i tryb peryferyjny USB.
• [C-1-4] MUSI zgłosić wsparcie funkcji android.software.midi.
• [C-1-5] MUSI spełniać wymagania dotyczące opóźnień i dźwięku USB przy użyciu interfejsu API natywnego dźwięku AAudio.
• [C-1-6] Opóźnienie urządzenia „na zimno” musi wynosić maksymalnie 200 milisekund.
• [C-1-7] Opóźnienie reakcji „na zimno” nie może przekraczać 200 milisekund.
• [C-SR-1] Zdecydowanie ZALECANE są opóźnienia zgodnie z definicją w sekcji 5.6 Opóźnienia dźwięku (20 milisekund lub mniej) przy 5 pomiarach ze średnim odchyleniem bezwzględnym mniejszym niż 5 milisekund od ścieżki głośnika do mikrofonu.
• [C-SR-2] Zdecydowanie ZALECANE jest spełnienie wymagań Pro Audio w zakresie ciągłego opóźnienia dźwięku w obie strony, opóźnienia wejścia „na zimno” i „zimnego sygnału wyjściowego” oraz wymagań dotyczących dźwięku USB za pomocą interfejsu API AAudio natywnego audio w ramach ścieżki MMAP.
• [C-SR-3] Zdecydowanie ZALECANE są zapewnić stały poziom wydajności procesora przy włączonym dźwięku, a obciążenie procesora się zmienia. Należy to zrobić za pomocą aplikacji na Androida SynthMark. SynthMark korzysta z syntezatora programowego działającego na symulowanej platformie audio, który mierzy wydajność systemu. Aplikację SynthMark należy uruchomić przy użyciu opcji „Automatyczny test” i uzyskać następujące wyniki:
  • voicemark.90 >= 32 głosy
  • czas oczekiwania.fixed.little <= 15 ms
  • opóźnieniemark.dynamic.little <= 50 ms

Objaśnienie wyników porównań znajdziesz w dokumentacji SynthMark.

• POWINNO zminimalizować niedokładność zegara audio i dryf w stosunku do czasu standardowego.
• POWINNO zminimalizować dryf zegara audio w stosunku do CPU CLOCK_MONOTONIC, gdy obie te wartości są aktywne.
• POWINNO Zminimalizować opóźnienie dźwięku przez przetworniki na urządzeniu.
• POWINNO zminimalizować opóźnienie dźwięku podczas korzystania z dźwięku cyfrowego przez USB.
• POWINIEN udokumentować pomiary opóźnienia dźwięku na wszystkich ścieżkach.
• POWINNY być zminimalizowanie zakłóceń podczas wywołań zwrotnych pełnego bufora audio, ponieważ ma to wpływ na procent wykorzystania pełnej przepustowości procesora przez wywołanie zwrotne.
• Przy normalnym użytkowaniu z określonym opóźnieniem nie powinno być żadnych zakłóceń w dźwięku.
• POWINNA SIĘ znajdować zerową różnicę czasu oczekiwania między kanałami.
• POWINNA Zminimalizować średni czas oczekiwania MIDI podczas wszystkich transmisji.
• POWINNO zminimalizować zmienność opóźnienia MIDI podczas obciążenia (zakłócenia) podczas wszystkich transmisji.
• NALEŻY podawać dokładne sygnatury czasowe MIDI we wszystkich transmisjach.
• POWINNO zminimalizować szum sygnału audio przez przetworniki urządzenia, w tym także okres bezpośrednio po uruchomieniu „na zimno”.
• TRZEBA zadbać o zerową różnicę zegara audio między stroną wejściową a wyjściową odpowiednich punktów końcowych, gdy oba te punkty są aktywne. Przykładami odpowiednich punktów końcowych są mikrofon i głośnik urządzenia oraz wejście i wyjście słuchawek audio.
• POWINNA obsługiwać wywołania zwrotne uzupełniania bufora audio po stronach wejściowych i wyjściowych odpowiednich punktów końcowych w tym samym wątku, gdy oba są aktywne, i wprowadzać wyjściowe wywołanie zwrotne natychmiast po zwrocie z wejściowego wywołania zwrotnego. A jeśli nie możesz obsłużyć wywołań zwrotnych w tym samym wątku, wpisz wyjściowe wywołanie zwrotne krótko po wprowadzeniu wywołania zwrotnego, aby aplikacja miała spójne czasy wejściowe i wyjściowe.
• 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.
• POWINNO zminimalizować opóźnienie dotyku.
• POWINNO zminimalizować zmienność czasu oczekiwania na dotknięcie przy obciążeniu (zakłócenia).
• Opóźnienie pomiędzy sygnałem dotykowym a wyjściem audio powinno wynosić mniej niż 40 ms.

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

• [C-SR-4] Zdecydowanie ZALECANE jest zgłoszenie pomocy dotyczącej funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager.

Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3, 5 mm:

• [C-2-1] MUSI mieć średni czas oczekiwania na dźwięk w obie strony (opisany w sekcji Opóźnienie dźwięku w obie strony) wynoszący 20 milisekund lub mniej, na więcej niż 5 pomiarów przy średnim odchyleniu bezwzględnym mniejszym niż 5 ms długości ścieżki audio.
• [C-SR-5] Zdecydowanie ZALECANE jest zachowanie zgodności z sekcją Specyfikacja urządzenia mobilnego (gniazdko) w specyfikacji przewodowego zestawu słuchawkowego do dźwięku (wersja 1.1).

Jeśli implementacje urządzeń pomijają 4-kanałowe gniazdo słuchawek 3, 5 mm i są wyposażone w porty USB obsługujące tryb hosta USB:

• [C-3-1] MUSI zaimplementować klasę audio USB.
• [C-3-2] Ciągłe opóźnienie dźwięku w obie strony musi wynosić 25 milisekund lub mniej, przy co najmniej 5 pomiarach ze średnim odchyleniem bezwzględnym mniejszym niż 5 ms przez port trybu hosta USB z zastosowaniem klasy audio USB. Można to zrobić z użyciem przejściówki USB-3, 5 mm i klucza audio Loopback lub użycia interfejsu audio USB z kablem krosowym podłączającym wejścia do wyjścia.
• [C-SR-6] Zdecydowanie ZALECANE są jednoczesne korzystanie z maksymalnie 8 kanałów w każdym kierunku, częstotliwości próbkowania 96 kHz i głębi 24-bitowej lub 32-bitowej, gdy są używane z urządzeniami peryferyjnymi USB audio, które również spełniają te wymagania.
• [C-SR-7] Zdecydowanie ZALECANE jest spełnienie tej grupy wymagań przy korzystaniu z interfejsu AAudio natywnego interfejsu API audio zamiast ścieżki MMAP.

Jeśli urządzenia są wyposażone w port HDMI:

• POWINNA obsługiwać wyjście stereo i 8 kanałów przy głębi 20- lub 24-bitowej i 192 kHz bez utraty głębi bitowej lub ponownego próbkowania, w co najmniej 1 konfiguracji.

5.11. Zrób zdjęcie, aby nie zostały przetworzone

Android umożliwia nagrywanie nieprzetworzonego dźwięku przez źródło dźwięku android.media.MediaRecorder.AudioSource.UNPROCESSED. W OpenSL ES można uzyskać dostęp za pomocą gotowego ustawienia rekordów SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Jeśli implementacja urządzenia ma obsługiwać nieprzetworzone źródło dźwięku i udostępniać je aplikacjom innych firm:

• [C-1-1] MUSI zgłosić pomoc za pomocą usługi android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] MUSI przedstawiać mniej więcej płaską amplitudę od częstotliwości w średnim zakresie częstotliwości: konkretnie ±10 dB od 100 Hz do 7000 Hz dla każdego mikrofonu używanego do rejestrowania nieprzetworzonego źródła dźwięku.

• [C-1-3] MUSI mieć poziom amplitudy w niskim zakresie: od ±20 dB od 5 Hz do 100 Hz w porównaniu ze średnią częstotliwością dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-4] MUSI mieć poziom amplitudy w zakresie wysokich częstotliwości: od ±30 dB od 7000 Hz do 22 kHz w porównaniu ze średnią częstotliwością dla każdego mikrofonu użytego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-5] MUSI ustawić czułość sygnału wejściowego dźwięku tak, by sinusoidalne źródło o częstotliwości 1000 Hz odtwarzane przy ciśnieniu akustycznym 94 dB (SPL) dawało odpowiedź z prawdopodobieństwem 520 dla 16-bitowych próbek (lub -36 dB pełnej skali dla każdego źródła zmiennoprzecinkowego i podwójnej precyzji mikrofonu użytego do nagrywania każdego źródła zmiennoprzecinkowego i podwójnej precyzji dźwięku).

• [C-1-6] MUSI mieć współczynnik sygnału do szumu (SNR) wynoszący 60 dB lub więcej dla każdego i każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku. (SNR jest mierzony jako różnica między 94 dB SPL a równoważnym SPL własnym szumem ważonym A).

• Całkowite zniekształcenie harmoniczne (THD) urządzenia [C-1-7] musi być mniejsze niż 1% dla 1 kHz przy poziomie sygnału wejściowego SPL 90 dB na każdym mikrofonie używanym do rejestrowania nieprzetworzonego źródła dźwięku.

• [C-1-8] NIE MOŻE mieć żadnego innego przetwarzania sygnału (np. automatycznej kontroli wzmocnienia, filtra górnoprzepustowego czy usuwania echa) na ścieżce innej niż mnożnik poziomu, który zapewni odpowiedni poziom. Krótko mówiąc:

  • [C-1-9] Jeśli z jakiegokolwiek powodu w architekturze obecne jest przetwarzanie sygnałów, MUSI być ono wyłączone i w efekcie powodować zerowe lub dodatkowe opóźnienie na ścieżce sygnału.
  • [C-1-10] Mnożnik poziomu, który może znajdować się na ścieżce, NIE MOŻE powodować opóźnienia na ścieżce sygnału.

Wszystkie pomiary SPL są wykonywane bezpośrednio obok testowanego mikrofonu. W przypadku różnych konfiguracji mikrofonów te wymagania dotyczą każdego z nich.

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

• [C-2-1] W przypadku metody AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) MUSI zwracać wartość null, aby prawidłowo wskazać brak obsługi.
• [C-SR-1] nadal Zdecydowanie zalecamy, by spełnić jak najwięcej wymagań dotyczących ścieżki sygnału dla nieprzetworzonego źródła nagrania.

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

6.1. Narzędzia dla programistów

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać narzędzia dla programistów aplikacji na Androida dostępne w pakiecie Android SDK.

• Android Debug Bridge (adb)

  • [C-0-2] MUSI obsługiwać narzędzie adb w sposób opisany w pakiecie SDK do Androida i za pomocą poleceń powłoki dostępnych 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. Uaktualnienie implementacji urządzeń z wcześniejszej wersji Androida bez trwałego blokowania danych może zostać wyłączone z zastosowania C-0-11.
  • [C-0-3] NIE MOŻE zmieniać formatu ani zawartości zdarzeń systemowych urządzenia (batterystats , disstats, odcisków cyfrowych, graficznych, netstats, powiadomień, procstats) zarejestrowanych za pomocą polecenia dumpsys.
  • [C-0-10] MUSI rejestrować bez pomijania te zdarzenia oraz udostępniać poniższe zdarzenia poleceniem powłoki cmd stats i klasom Systemowego interfejsu API StatsManager.
    • Zmieniono stan działania pierwszego planu
    • Wykryto anomalię
    • Zgłoszono menu nawigacyjne aplikacji
    • Wystąpiła awaria
    • Uruchomienie aplikacji
    • Poziom baterii został zmieniony
    • Zmieniono stan trybu oszczędzania baterii
    • Odebrano BleScanResult
    • Stan BleScanState zmieniony
    • Zmieniono stan ładowania
    • Zmieniono stan bezczynności urządzenia
    • Zmieniono stan usługi na pierwszym planie
    • Zmieniono stan skanowania GPS
    • Stan zadania zmieniony
    • Stan wtyczki zmieniony
    • Zmieniono stan zaplanowanego zadania
    • Zmieniono stan ekranu
    • SyncState (Zmiana stanu)
    • Czas rzeczywisty po upłynięciu systemu
    • Zmieniono stan procesu UidProcess
    • Stan uśpienia został zmieniony
    • Pojawił się Budzik
    • Zmiana stanu blokady Wi-Fi
    • Zmiana stanu blokady Wi-FiMulticastLock
    • Zmiana stanu skanowania Wi-Fi
  • [C-0-4] demon adb po stronie urządzenia MUSI być domyślnie nieaktywny, a most debugowania Androida MUSI mieć łatwo dostępny dla użytkownika mechanizm.
  • [C-0-5] MUSI obsługiwać bezpieczne narzędzie adb. Android zapewnia obsługę bezpiecznych plików adb. Bezpieczny adb włącza narzędzie adb na znanych uwierzytelnionych hostach.
  • [C-0-6] MUSI zapewniać mechanizm umożliwiający połączenie narzędzia adb z komputera hosta. Więcej szczegółów:

  Jeśli implementacje urządzeń bez portu USB obsługują tryb peryferyjny:

  • [C-3-1] MUSI zaimplementować adb przez sieć lokalną (np. Ethernet lub Wi-Fi).
  • [C-3-2] MUSI zawierać sterowniki dla Windows 7, 8 i 10, które pozwalają programistom połączyć się 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] MUSI zwracać metodę AdbManager#isAdbWifiSupported() true.

  Jeśli implementacje urządzeń obsługują połączenia adb z hostem przez Wi-Fi i zawierają co najmniej 1 kamerę:

  • [C-5-1] MUSI zwracać metodę AdbManager#isAdbWifiQrSupported() true.

• Usługa monitorowania debugowania Dalvik (ddms)

  • [C-0-7] MUSI obsługiwać wszystkie funkcje ddms zgodnie z dokumentacją pakietu Android SDK. Ponieważ pakiet ddms używa narzędzia adb, obsługa ddms powinna być domyślnie nieaktywna, ale MUSI być obsługiwana za każdym razem, gdy użytkownik aktywuje Android Debug Bridge (jak powyżej).

• Małpa

  • [C-0-8] MUSI zawierać platformę Monkey i udostępniać ją aplikacjom.

• SysTrace,

  • [C-0-9] MUSI obsługiwać narzędzie systrace zgodnie z opisem w pakiecie SDK na Androida. System musi być domyślnie nieaktywny, a jego włączenie MUSI mieć dostępny dla użytkowników mechanizm.

• Perfetto

  • [C-SR-1] Zdecydowanie ZALECANE jest udostępnienie użytkownikowi powłoki pliku binarnego /system/bin/perfetto. cmdline jest zgodny z dokumentacją perfetto.
  • [C-SR-2] Zdecydowanie zalecamy użycie pliku binarnego perfetto, aby jako dane wejściowe akceptować konfigurację protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR-3] Zdecydowanie zaleca się zapisać plik binarny perfetto jako dane wyjściowe w postaci logu czasu protokołu zgodnego ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR-4] Zdecydowanie zalecamy podanie, za pomocą pliku binarnego perfetto, przynajmniej źródeł danych opisanych w dokumentacji perfetto.

• Narzędzie do niszczenia pamięci

  • [C-0-10] MUSI zapisywać Atom LMK_KILL_OCCURRED_FIELD_NUMBER w logu statystyk, gdy aplikacja jest zamykana przez mechanizm zarządzania funkcją Low Memory Killer.

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

  • [C-2-1] MUSI zwrócić true za ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] MUSI wdrożyć tryb jarzma testowego zgodnie z opisem w dokumentacji trybu jarzma testowego.

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

• [C-1-1] MUSI udostępniać deweloperowi aplikacji możliwość włączenia/wyłączenia warstw debugowania GPU.
• [C-1-2] Gdy włączone są warstwy debugowania GPU, należy wyliczać warstwy w bibliotekach udostępnianych przez narzędzia zewnętrzne (tj. niebędące częścią platformy ani pakietu aplikacji) znajdujące się w katalogu podstawowym aplikacji z możliwością debugowania, aby obsługiwać metody interfejsu API vkEnumerateInstanceLayerWłaściwości() i vkCreateInstance().

6.2. Opcje programisty

Android umożliwia programistom konfigurowanie ustawień związanych z programowaniem aplikacji.

Implementacje na urządzeniach MUSZĄ zapewniać spójne funkcje Opcji programisty, ponieważ:

• [C-0-1] MUSI uwzględniać zamiar android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlić ustawienia związane z programowaniem aplikacji. Poprzednia implementacja Androida ukrywa menu Opcje programisty domyślnie i umożliwia użytkownikom uruchomienie Opcji programisty po naciśnięciu 7 (7) razy w menu Ustawienia > Informacje o urządzeniu > Numer kompilacji.
• [C-0-2] Domyślnie MUSI ukryć Opcje programisty.
• [C-0-3] MUSI zawierać jasny mechanizm, który nie traktuje aplikacji innej firmy na priorytetowo w stosunku do innych, umożliwiając im korzystanie z opcji programisty. MUSI udostępnić publicznie widoczny dokument lub witrynę z opisem, jak włączyć Opcje programisty. Dokument lub witryna MUSI zawierać link w dokumentach pakietu Android SDK.
• POWINNY być stale widoczne dla użytkownika powiadomienie wizualne, gdy opcje programisty są włączone i użytkownik obawia się o bezpieczeństwo.
• MOGĄ tymczasowo ograniczyć dostęp do menu Opcje programisty, ukrywając je lub wyłączając je, aby nie rozpraszać uwagi w sytuacjach, gdy bezpieczeństwo użytkownika jest niepokojące.

7. Zgodność sprzętu

Jeśli urządzenie jest wyposażone w konkretny komponent sprzętowy, który ma odpowiedni interfejs API dla zewnętrznych deweloperów:

• [C-0-1] Implementacja na urządzeniu MUSI implementować ten interfejs API w sposób opisany w dokumentacji pakietu Android SDK.

Jeśli interfejs API w pakiecie SDK wchodzi w interakcję z komponentem sprzętowym, który jest określony jako opcjonalny, a implementacja urządzenia nie zawiera tego komponentu:

• [C-0-2] Pełne definicje klas (zgodnie z dokumentacją w pakiecie SDK) dla komponentu MUSZĄ nadal być przedstawiane.
• [C-0-3] Działanie interfejsu API MUSI być w jakiś rozsądny sposób implementowane jako brak działań.
• [C-0-4] Metody interfejsu API MUSZĄ zwracać wartości null tam, gdzie jest to dozwolone w dokumentacji pakietu SDK.
• [C-0-5] Metody interfejsu API MUSZĄ zwracać implementacje klas bezobsługowych, w których wartości null są niedozwolone w dokumentacji pakietu SDK.
• [C-0-6] Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, których nie opisano w dokumentacji pakietu SDK.
• [C-0-7] Implementacje urządzeń MUSZĄ spójnie zgłaszać dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager dla tego samego odcisku cyfrowego kompilacji.

Typowym przykładem sytuacji, w której obowiązują te wymagania, jest interfejs API telefonii. Te interfejsy API trzeba wdrożyć w rozsądnych sytuacjach nawet na urządzeniach innych niż telefony.

7.1. Wyświetlacz i grafika

Android zawiera urządzenia, które automatycznie dostosowują zasoby aplikacji i układy UI odpowiednio do urządzenia, aby aplikacje innych firm działały prawidłowo na różnych konfiguracjach sprzętowych. Na wyświetlaczach zgodnych z Androidem, na których mogą działać wszystkie aplikacje innych firm z Androidem, implementacje urządzeń MUSZĄ prawidłowo implementować te interfejsy API i działania zgodnie z opisem w tej sekcji.

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

• fizyczny rozmiar przekątnej. Wyrażona w calach odległość między dwoma przeciwległymi rogami oświetlonej części wyświetlacza.
• punktów na cal (dpi). Liczba pikseli w obrębie liniowej, poziomej lub pionowej rozpiętości wynoszącej 1. Przy podanych wartościach dpi zarówno dpi w poziomie, jak i w pionie muszą mieścić się w zakresie.
• format obrazu. Stosunek liczby pikseli dłuższego wymiaru do krótszego wymiaru ekranu. Na przykład przy rozmiarze 480 x 854 piksele będzie to 854/480 = 1, 779, czyli w przybliżeniu „16:9”.
• piksel niezależny od gęstości (dp). Jednostka wirtualnego piksela znormalizowana do ekranu o rozdzielczości 160 dpi. Wartość jest obliczana według wzoru: piksele = dps * (gęstość/160).

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar i kształt ekranu

Platforma interfejsu Androida obsługuje różne logiczne rozmiary układu ekranu i umożliwia aplikacjom wysyłanie zapytań o rozmiar ekranu w bieżącej konfiguracji za pomocą funkcji Configuration.screenLayout za pomocą metod SCREENLAYOUT_SIZE_MASK i Configuration.smallestScreenWidthDp.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłosić prawidłowy rozmiar układu elementu Configuration.screenLayout zgodnie z definicją w dokumentacji pakietu Android SDK. Implementacje urządzeń MUSZĄ zgłaszać prawidłowe wymiary ekranu niezależne od gęstości logicznej (dp) jak poniżej:

  • Urządzenia, które mają ustawioną wartość Configuration.uiMode jako dowolną inną niż UI_MODE_TYPE_WATCH i przesyłający zgłoszenie o rozmiarze small dla elementu Configuration.screenLayout MUSZĄ mieć co najmniej 426 dp x 320 dp.
  • Urządzenia zgłaszające rozmiar normal w polu Configuration.screenLayout MUSZĄ mieć co najmniej 480 dp x 320 dp.
  • Urządzenia zgłaszające rozmiar large w polu Configuration.screenLayout MUSZĄ mieć co najmniej 640 dp x 480 dp.
  • Urządzenia zgłaszające rozmiar xlarge w polu Configuration.screenLayout MUSZĄ mieć co najmniej 960 dp x 720 dp.

• [C-0-2] MUSI spełniać określone przez aplikacje obsługę rozmiarów ekranu za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml, zgodnie z dokumentacją pakietu Android SDK.

• MOŻE mieć wyświetlacze zgodne z Androidem z zaokrąglonymi rogami.

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

• [C-1-1] MUSI zadbać o spełnienie co najmniej jednego z tych warunków:

  • Promień zaokrąglonych rogów nie przekracza 38 dp.
  • Jeśli w każdym rogu logicznego wyświetlacza zakotwiczone jest pole o wymiarach 15 x 15 dp, na ekranie widoczny jest co najmniej 1 piksel.

• POWINIEN uwzględnić opcję przejścia użytkownika na tryb wyświetlania z prostokątnymi narożnikami.

Jeśli implementacje urządzeń obejmują składane wyświetlacze zgodne z Androidem lub zawiasy umieszczone między wieloma panelami i udostępniają takie wyświetlacze do renderowania aplikacji innych firm:

• [C-2-1] Aby używać biblioteki Window Manager Jetpack, MUSI wdrożyć najnowszą dostępną stabilną wersję interfejsu API rozszerzeń lub stabilną wersję interfejsu pomocniczego.

Jeśli urządzenia są wyposażone w składany wyświetlacz zgodny z Androidem lub składany zawias między kilkoma panelami, a zawias lub zawias przecina pełnoekranowe okno aplikacji:

• [C-3-1] MUSI zgłaszać do aplikacji pozycję, granice i stan zawiasu lub zawinięcia za pomocą rozszerzeń lub interfejsów API pomocniczych.

Szczegółowe informacje na temat prawidłowego wdrażania interfejsów API pomocniczych lub rozszerzeń znajdziesz w publicznej dokumentacji Window Manager Jetpack.

7.1.1.2. Współczynnik proporcji ekranu

Chociaż nie ma ograniczeń co do formatu obrazu fizycznego wyświetlacza zgodnego z Androidem, format obrazu logicznego, na którym są renderowane aplikacje innych firm, który można określić na podstawie wartości wysokości i szerokość zgłaszanych za pomocą interfejsów API view.Display oraz konfiguracji, MUSI spełniać te wymagania:

• [C-0-1] Implementacje na urządzeniach, w których Configuration.uiMode ma wartość UI_MODE_TYPE_NORMAL, MUSZĄ mieć współczynnik proporcji mniejszy lub równy 1,86 (około 16:9), chyba że aplikacja spełnia jeden z tych warunków:

  • Aplikacja zadeklarowała, że obsługuje większy format ekranu za pomocą wartości metadanych android.max_aspect.
  • Aplikacja deklaruje, że rozmiar można zmienić za pomocą atrybutu android:resizeableActivity.
  • Aplikacja jest kierowana na interfejs API na poziomie 24 lub wyższym i nie deklaruje obiektu android:maxAspectRatio, który ograniczałby dozwolony format obrazu.

• [C-0-3] Implementacje na urządzeniach z atrybutem Configuration.uiMode ustawionym jako UI_MODE_TYPE_WATCH MUSZĄ mieć format obrazu ustawiony na 1,0 (1:1).

7.1.1.3 Gęstość ekranu

Platforma UI Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić programistom kierowanie zasobów aplikacji.

• [C-0-1] Domyślnie implementacje urządzeń MUSZĄ zgłaszać tylko jedną z gęstości platformy Androida wymienionych na stronie DisplayMetrics przez interfejs API DENSITY_DEVICE_STABLE. Ta wartość NIE MOŻE się zmienić w żadnym momencie. Urządzenie MOŻE jednak zgłosić inną gęstość w zależności od zmian w konfiguracji wyświetlacza wprowadzonych przez użytkownika (np. rozmiaru wyświetlacza) ustawionych po pierwszym uruchomieniu.

• Implementacje na urządzeniach MUSZĄ definiować standardową gęstość platformy Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, chyba że taka gęstość logiczna powoduje, że raportowany rozmiar ekranu jest poniżej obsługiwanego rozmiaru minimalnego. Jeśli standardowa gęstość platformy Androida, która jest najbliższa liczbowo gęstości fizycznej, powoduje, że rozmiar ekranu jest mniejszy niż najmniej obsługiwany obsługiwany rozmiar ekranu (320 dp), implementacje urządzeń POWINNY zgłaszać kolejną najniższą gęstość standardowej gęstości platformy Androida.

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

• [C-1-1] Rozmiar wyświetlacza NIE MOŻE być większy niż 1,5 raza gęstości natywnej ani nie powoduje, że minimalny rozmiar ekranu jest mniejszy niż 320 dp (odpowiednik kwalifikatora zasobów sw320dp) – w zależności od tego, co nastąpi wcześniej.
• [C-1-2] Rozmiar wyświetlacza NIE MOŻE być skalowany w sposób mniejszy niż 0,85 raza gęstości natywnej.
• Aby zapewnić wygodę obsługi i spójne rozmiary czcionek, ZALECANE jest użycie takiego skalowania opcji natywnych reklam displayowych (przy zachowaniu zgodności z limitami określonymi powyżej):
  • Małe: 0,85x
  • Domyślnie: 1x (natywna skala wyświetlania)
  • Duży: 1,15x
  • Większe: 1,3x
  • Największy 1,45x

7.1.2. Wyświetl dane

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

• [C-1-1] MUSI podawać prawidłowe wartości w przypadku wszystkich danych o wyświetlaczach zgodnych z Androidem zdefiniowanych w interfejsie API android.util.DisplayMetrics.

Jeśli implementacje urządzeń nie zawierają osadzonego ekranu lub wyjścia wideo, umożliwiają one:

• [C-2-1] MUSI zgłaszać prawidłowe wartości wyświetlacza zgodnego z Androidem zgodnie z definicją w interfejsie API android.util.DisplayMetrics dla emulowanej domyślnej wartości view.Display.

7.1.3 Orientacja ekranu

Implementacje na urządzeniach:

• [C-0-1] MUSI podawać obsługiwane orientacje ekranu (android.hardware.screen.portrait lub android.hardware.screen.landscape) i MUSI zgłaszać co najmniej 1 obsługiwaną orientację. Na przykład urządzenie ze stałą orientacją poziomą, takie jak telewizor czy laptop, POWINNO zgłaszać tylko wartość android.hardware.screen.landscape.
• [C-0-2] MUSI zgłaszać prawidłową wartość w bieżącej orientacji urządzenia w przypadku żądania za pomocą android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innych interfejsów API.

Jeśli implementacje urządzeń obsługują obie orientacje ekranu, umożliwiają one:

• [C-1-1] MUSI obsługiwać orientację dynamiczną w aplikacjach w orientacji pionowej lub poziomej. Oznacza to, że urządzenie musi reagować na żądanie aplikacji dotyczące określonej orientacji ekranu.
• [C-1-2] NIE MOŻE zmieniać zgłoszonego rozmiaru ani gęstości ekranu podczas zmiany orientacji.
• MOGĄ wybrać orientację pionową lub poziomą jako domyślną.

7.1.4. Przyspieszenie działania grafiki 2D i 3D

7.1.4.1 OpenGL ES

Implementacje na urządzeniach:

• [C-0-1] MUSI poprawnie identyfikować obsługiwane wersje OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) za pomocą zarządzanych interfejsów API (np. GLES10.getString()) i natywnych interfejsów API.
• [C-0-2] MUSI obsługiwać wszystkie odpowiednie zarządzane interfejsy API i natywne interfejsy API dla każdej wersji OpenGL ES, którą są obsługiwane.

Jeśli implementacje urządzeń obejmują wyjście ekranu lub wideo:

• [C-1-1] MUSI obsługiwać zarówno platformę OpenGL ES 1.1, jak i 2.0, zgodnie z opisem w dokumentacji pakietu SDK na Androida.
• [C-SR-1] Zdecydowanie ZALECANE są obsługa OpenGL ES 3.1.
• MUSI obsługiwać standard OpenGL ES 3.2.

Testy dEQP OpenGL ES są podzielone na wiele list testowych, z których każda ma przypisaną datę i numer wersji. Znajdziesz je w drzewie źródłowym Androida w external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Urządzenie, które obsługuje OpenGL ES na zgłoszonym poziomie, wskazuje, że może przejść testy dEQP na wszystkich listach testowych na tym poziomie i wcześniejszych.

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

• [C-2-1] MUSI zgłaszać za pomocą zarządzanych interfejsów API OpenGL ES i natywnych interfejsów API wszystkie inne zaimplementowane rozszerzenia OpenGL ES i odwrotnie NIE MOŻE zgłaszać ciągów rozszerzeń, które 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] MUSI zgłaszać maksymalną wersję testów dEQP OpenGL ES obsługiwaną za pomocą flagi funkcji android.software.opengles.deqp.level.
• [C-2-4] MUSI obsługiwać co najmniej wersję 132383489 (od 1 marca 2020 r.) zgodnie z informacją we fladze funkcji android.software.opengles.deqp.level.
• [C-2-5] W przypadku każdej obsługiwanej wersji OpenGL ES MUSI przejść wszystkie testy OpenGL ES dEQP na listach testowych między wersją 132383489 a wersją określoną we fladze funkcji android.software.opengles.deqp.level.
• [C-SR-2] Zdecydowanie ZALECANE jest obsługa rozszerzeń EGL_KHR_partial_update i OES_EGL_image_external.
• MUSI generować dokładne raporty za pomocą metody getString(), czyli dowolnego obsługiwanego formatu kompresji tekstur, który jest zwykle zależny od dostawcy.

Jeśli implementacje urządzeń zadeklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2:

• [C-3-1] MUSI wyeksportować odpowiednie symbole funkcji dla tych wersji jako uzupełnienie symboli funkcji OpenGL ES 2.0 z biblioteki libGLESv2.so.
• [C-SR-3] Zdecydowanie ZALECANE jest obsługa rozszerzenia OES_EGL_image_external_essl3.

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

• [C-4-1] MUSI obsługiwać w całości pakiet rozszerzeń OpenGL ES na Androida.

Jeśli implementacje urządzeń w całości obsługują pakiet rozszerzeń Android OpenGL ES:

• [C-5-1] MUSI identyfikować wsparcie za pomocą flagi funkcji android.hardware.opengles.aep.

Jeśli implementacje urządzenia zapewniają obsługę rozszerzenia EGL_KHR_mutable_render_buffer:

• [C-6-1] MUSI też obsługiwać rozszerzenie EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 interfejs Vulkan

Android obsługuje Vulkan – niskobudżetowy, wieloplatformowy interfejs API do wysokiej wydajności grafiki 3D.

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

• [C-SR-1] Zdecydowanie ZALECANE jest włączenie obsługi Vulkan 1.1.

Jeśli implementacje urządzeń obejmują wyjście ekranu lub wideo:

• POWINNO obsługiwać platformę Vulkan 1.1.

Testy Vulkan dEQP są podzielone na różne listy testowe, z których każda ma ustaloną datę i wersję. Znajdziesz je w drzewie źródłowym Androida w external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Urządzenie, które obsługuje Vulkana na zgłoszonym poziomie, wskazuje, że może przejść testy dEQP na wszystkich listach testowych na tym poziomie i wcześniejszych.

Jeśli implementacje urządzeń obsługują standard Vulkan 1.0 lub nowszy:

• [C-1-1] MUSI podawać prawidłową liczbę całkowitą z flagami funkcji android.hardware.vulkan.level i android.hardware.vulkan.version.
• [C-1-2] MUSI wyliczać co najmniej 1 VkPhysicalDevice dla natywnego interfejsu Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] MUSI w pełni wdrożyć interfejsy Vulkan 1.0 API w przypadku każdego wskazanego parametru VkPhysicalDevice.
• [C-1-4] MUSI wyliczać warstwy zawarte w bibliotekach natywnych o nazwie libVkLayer*.so w katalogu biblioteki natywnej pakietu aplikacji przy użyciu natywnych interfejsów API Vulkan vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties().
• [C-1-5] NIE MOŻE wyliczać warstw dostarczanych przez biblioteki poza pakietem aplikacji ani udostępniać innych sposobów śledzenia lub przechwytywania interfejsu Vulkan API, chyba że aplikacja ma atrybut android:debuggable ustawiony jako true.
• [C-1-6] MUSI zgłaszać wszystkie ciągi rozszerzeń, które obsługują przez natywne interfejsy API Vulkan, i NIE MOGĄ raportować ciągów rozszerzeń, które nie są prawidłowo obsługiwane.
• [C-1-7] MUSI obsługiwać rozszerzenia VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain i VK_KHR_incremental_present.
• [C-1-8] MUSI zgłaszać maksymalną wersję testów Vulkan dEQP obsługiwanych za pomocą flagi funkcji android.software.vulkan.deqp.level.
• [C-1-9] MUSI obsługiwać co najmniej wersję 132317953 (od 1 marca 2019 r.) zgodnie z flagą funkcji android.software.vulkan.deqp.level.
• [C-1-10] MUSI przejść wszystkie testy Vulkan dEQP na listach testowych w wersji 132317953 a wersją określoną we fladze funkcji android.software.vulkan.deqp.level.
• [C-1-11] NIE MOŻE liczyć wsparcia dla rozszerzeń VK_KHR_video_queue, VK_KHR_video_decode_queue ani VK_KHR_video_encode_queue.
• [C-SR-2] Zdecydowanie zalecana jest obsługa rozszerzeń VK_KHR_driver_properties i VK_GOOGLE_display_timing.

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

• [C-2-1] NIE MOŻE deklarować żadnych flag funkcji interfejsu Vulkan (np. android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] NIE MOŻE wyliczać żadnych elementów VkPhysicalDevice dla natywnego interfejsu API Vulkan vkEnumeratePhysicalDevices().

Jeśli implementacje urządzeń obsługują wersję Vulkan 1.1 i zadeklarowane są dowolne flagi funkcji Vulkan, oznacza to, że:

• [C-3-1] MUSI udostępniać obsługę typów zewnętrznych semaforów i uchwytów SYNC_FD oraz rozszerzenia VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

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

Przyspieszenie grafiki 2D 7.1.4.4

Android zawiera mechanizm deklarowania przez aplikacje, że chcą włączyć akcelerację sprzętową grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku, korzystając z tagu manifestu android:hardwareAccelerated lub bezpośrednich wywołań interfejsu API.

Implementacje na urządzeniach:

• [C-0-1] MUSI domyślnie włączać akcelerację sprzętową i MUSI wyłączyć akcelerację sprzętową, jeśli deweloper o to poprosi, ustawiając parametr android:hardwareAccelerated="false" lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów Android View API.
• [C-0-2] MUSI działać zgodne z dokumentacją pakietu Android SDK na temat akceleracji sprzętowej.

Android zawiera obiekt TextureView, który pozwala programistom bezpośrednio integrować tekstury OpenGL ES z akceleracją sprzętową jako cele renderowania w hierarchii UI.

Implementacje na urządzeniach:

• [C-0-3] MUSI obsługiwać interfejs TextureView API i MUSI działać w spójny sposób z wcześniejszą implementacją Androida.

7.1.4.5 Wyświetlacze o szerokiej gamie

Jeśli implementacji na urządzeniu informują o obsłudze ekranów o szerokiej gamie za pomocą Configuration.isScreenWideColorGamut() , oznacza to, że:

• [C-1-1] MUSI mieć wyświetlacz z kalibracją kolorów.
• [C-1-2] MUSI mieć wyświetlacz, który w całości pokrywa gamę kolorów sRGB w przestrzeni CIE 1931 xyY.
• [C-1-3] MUSI mieć wyświetlacz o gatunku równym co najmniej 90% obszaru DCI-P3 w przestrzeni CIE 1931 xyY.
• [C-1-4] MUSI obsługiwać standard OpenGL ES 3.1 lub 3.2 i prawidłowo go zgłaszać.
• [C-1-5] MUSI reklamować obsługę rozszerzeń EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear i EGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR-1] Zdecydowanie ZALECANE jest działanie funkcji GL_EXT_sRGB.

Jeśli natomiast implementacje urządzeń nie obsługują wyświetlaczy o szerokim zakresie kolorów:

• [C-2-1] POWINNA obejmować co najmniej 100% przestrzeni sRGB w przestrzeni CIE 1931 xyY, ale gama kolorów ekranu jest nieokreślona.

7.1.5 Tryb zgodności starszych aplikacji

Android określa „tryb zgodności”, w którym platforma działa w trybie „normalnego” rozmiaru ekranu (szerokości 320 dp), co umożliwia korzystanie ze starszych aplikacji nieopracowanych na potrzeby starszych wersji Androida, które wcześniej nie były niezależne od rozmiaru ekranu.

7.1.6 Technologia ekranu

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

Wszystkie ekrany w implementacji na urządzeniach zgodnych z Androidem:

• [C-0-1] MUSI obsługiwać 16-bitową grafikę w kolorach.
• NALEŻY obsługiwać wyświetlacze z 24-bitową grafiką w 24-bitowych kolorach.
• [C-0-2] MUSI wyświetlać animacje.
• [C-0-3] MUSI mieć współczynnik proporcji piksela (PAR) w zakresie 0,9–1,15. Oznacza to, że format piksela MUSI być niemal kwadratowy (1,0) i z tolerancją 10–15%.

7.1.7 Wyświetlacze dodatkowe

Android obsługuje dodatkowe wyświetlacze zgodne z Androidem, które umożliwiają udostępnianie multimediów, oraz interfejsy API dla programistów umożliwiające dostęp do wyświetlaczy zewnętrznych.

Jeśli implementacje urządzeń obsługują wyświetlacz zewnętrzny za pomocą połączenia przewodowego, bezprzewodowego lub wbudowanego wyświetlacza dodatkowego,:

• [C-1-1] MUSI wdrożyć usługę systemową i interfejs API DisplayManager w sposób opisany w dokumentacji pakietu Android SDK.

7.2. Urządzenia wejściowe

Implementacje na urządzeniach:

• [C-0-1] Do poruszania się między elementami interfejsu MUSI zawierać mechanizm wprowadzania danych, np. ekran dotykowy lub nawigację bezdotykową.

7.2.1. Klawiatura

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

• [C-1-1] MUSI zadeklarować flagę funkcji android.software.input_methods.
• [C-1-2] MUSI obsługiwać w całości Input Management Framework
• [C-1-3] MUSI mieć wstępnie zainstalowaną klawiaturę programową.

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE zawierać klawiatury sprzętowej w jednym z formatów określonych w ustawieniu android.content.res.Configuration.keyboard (QWERTY lub 12-key).
• POWINNY BYĆ dodatkowe implementacje klawiatury programowej.
• MOŻE zawierać klawiaturę sprzętową.

7.2.2 Nawigacja bezdotykowa

Android zapewnia obsługę pada kierunkowego, kulki i kółka jako mechanizmów do nawigacji bezdotykowej.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłosić prawidłową wartość parametru android.content.res.Configuration.navigation.

Jeśli w urządzeniach nie ma nawigacji niedotykowej:

• [C-1-1] MUSI zapewniać rozsądny alternatywny interfejs użytkownika do wyboru i edytowania tekstu, zgodny z mechanizmami zarządzania danymi wejściowymi. Dodatkowa implementacja open source Androida obejmuje mechanizm wyboru odpowiedni do użycia z urządzeniami, które nie zawierają nawigacji bezdotykowej.

7.2.3 Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz są zwykle dostępne w wyniku interakcji z osobnym przyciskiem fizycznym lub wybraną częścią ekranu dotykowego są niezbędne dla paradygmatu nawigacji po Androidzie, a tym samym we implementacjach urządzeń:

• [C-0-1] MUSI zapewniać użytkownikowi możliwość uruchamiania zainstalowanych aplikacji, które mają działanie związane z funkcją <intent-filter> ustawioną na potrzeby implementacji na urządzeniach telewizyjnych wartości ACTION=MAIN i CATEGORY=LAUNCHER lub CATEGORY=LEANBACK_LAUNCHER. Funkcja Home POWINNA być mechanizmem dla tej afordancji użytkownika.
• POWINNY jest dostęp do przycisków funkcji Ostatnie i Wstecz.

Jeśli dostępne są funkcje Ekran główny, Ostatnie i Wstecz, umożliwiają one:

• [C-1-1] MUSI być dostępne w wyniku 1 działania (np. kliknięcia lub dwukrotnego kliknięcia), jeśli którekolwiek z nich jest dostępne.
• [C-1-2] MUSI wyraźnie wskazywać, które działanie może wywoływać poszczególne funkcje. Przykładem może być wyświetlenie na przycisku widocznej ikony, ikona oprogramowania na pasku nawigacyjnym na ekranie lub przejście użytkownika przez szczegółową prezentację na temat gotowej konfiguracji.

Implementacje na urządzeniach:

• Zdecydowanie ZALECAM, aby w modelu [C-SR-1] nie używać mechanizmu wprowadzania danych w funkcji menu, ponieważ od Androida 4.0 wycofano tę funkcję i zastąpiła nią pasek działań.

Jeśli implementacje urządzeń zapewniają funkcję menu, są to:

• [C-2-1] MUSI wyświetlać przycisk przepełnienia działania, gdy rozszerzone menu czynności nie jest puste i widoczny jest pasek działań.
• [C-2-2] NIE MOŻE zmieniać pozycji wyświetlanego wyskakującego okienka działań, które pojawia się po kliknięciu przycisku rozszerzonego na pasku działań, ale MOŻE renderować wyskakujące okienko działania w zmodyfikowanym położeniu, gdy jest wyświetlane po wybraniu funkcji menu.

Jeśli implementacje urządzeń nie obsługują funkcji menu, w celu zapewnienia zgodności wstecznej:

• [C-3-1] MUSI udostępnić funkcję Menu aplikacjom, gdy wartość targetSdkVersion jest mniejsza niż 10 za pomocą fizycznego przycisku, klawisza oprogramowania lub gestów. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacyjnymi.

Jeśli implementacje na urządzeniach udostępniają funkcję wspomagania:

• [C-4-1] MUSI umożliwiać korzystanie z funkcji Asystenta jednym działaniem (np. kliknięciem, dwukrotnym kliknięciem lub gestem), gdy dostępne są inne klawisze nawigacyjne.
• [C-SR-2] Zdecydowanie zalecamy przytrzymanie funkcji ekranu głównego, ponieważ jest to wskazane działanie.

Jeśli implementacje urządzeń wykorzystują osobną część ekranu do wyświetlania klawiszy nawigacyjnych:

• [C-5-1] Klawisze nawigacyjne MUSZĄ zajmować wyraźną część ekranu, nie są dostępne dla aplikacji i NIE MOGĄ zasłaniać tej części ekranu dostępnej dla aplikacji ani w inny sposób zakłócać jej działania.
• [C-5-2] MUSI udostępnić część wyświetlacza aplikacjom, które spełniają wymagania określone w sekcji 7.1.1.
• [C-5-3] MUSI uwzględniać flagi ustawione przez aplikację za pomocą metody interfejsu API View.setSystemUiVisibility(), aby ta odrębna część ekranu (czyli pasek nawigacyjny) była prawidłowo ukryta w sposób opisany w pakiecie SDK.

Jeśli funkcja nawigacji jest udostępniana na ekranie za pomocą gestów:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() MUSI być używana tylko do zgłaszania obszaru rozpoznawania gestów w domu.
• [C-6-2] Gesty rozpoczynające się w polu wykluczenia podanym w aplikacji na pierwszym planie za pomocą funkcji View#setSystemGestureExclusionRects(), ale poza WindowInsets#getMandatorySystemGestureInsets() NIE MOGĄ być przechwytywane przez funkcję nawigacji, jeśli jest dozwolony w ramach maksymalnego ograniczenia wykluczeń określonego w dokumentacji dotyczącej View#setSystemGestureExclusionRects().
• [C-6-3] MUSI wysłać do aplikacji na pierwszym planie zdarzenie MotionEvent.ACTION_CANCEL, gdy dotknięcia zaczną być przechwytywane dla gestu systemowego, jeśli aplikacja na pierwszym planie została wcześniej wysłana zdarzenie MotionEvent.ACTION_DOWN.
• [C-6-4] MUSI zapewniać użytkownikowi możliwość przełączenia się na nawigację ekranową za pomocą przycisków (np. w Ustawieniach).
• Trzeba udostępnić funkcję ekranu głównego, czyli przesunąć palcem w górę od dolnej krawędzi bieżącej orientacji ekranu.
• POWINIEN udostępnić funkcję Ostatnie – przesuń palcem w górę i przytrzymaj przed zwolnieniem, z tego samego obszaru co gest ekranu głównego.
• Na gesty rozpoczynające się w obrębie WindowInsets#getMandatorySystemGestureInsets() NIE POWINNYJĄ mieć wpływu podpowiedzi wykluczania podane przez aplikację na pierwszym planie w View#setSystemGestureExclusionRects().

Jeśli funkcja nawigacji jest dostępna z dowolnego miejsca przy lewej i prawej krawędzi bieżącej orientacji ekranu:

• [C-7-1] Funkcja nawigacji MUSI być cofnięta i dostępna jako przesunięcie od lewej i prawej krawędzi bieżącej orientacji ekranu.
• [C-7-2] Jeśli niestandardowe przesuwane panele systemowe znajdują się przy lewej lub prawej krawędzi, MUSZĄ być umieszczone w górnej 1/3 ekranu i mieć wyraźne, trwałe oznaczenie wizualne, które informuje, że przeciąganie spowoduje wyświetlenie wspomnianych paneli, a nie Wstecz. Użytkownik MOŻE skonfigurować panel systemu w taki sposób, aby znajdował się poniżej górnej 1/3 krawędzi ekranu, ale NIE MOŻE sięgać dalej niż 1/3 krawędzi.
• [C-7-3] Gdy aplikacja na pierwszym planie ma zaimplementowany pakiet SDK View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub
• [C-7-4] Gdy w aplikacji na pierwszym planie występuje pasek nawigacyjny View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_.

7.2.4 Wprowadzanie tekstu z ekranu dotykowego

Android obsługuje różne systemy wprowadzania danych wskaźnikami, takie jak ekrany dotykowe, pady dotykowe i fałszywe urządzenia dotykowe. Implementacje na urządzeniach z ekranem dotykowym są powiązane z wyświetlaczem w taki sposób, że użytkownik ma wrażenie bezpośredniego manipulowania elementami na ekranie. Użytkownik dotyka bezpośrednio ekranu, więc system nie wymaga żadnych dodatkowych afordancji wskazujących manipulowane obiekty.

Implementacje na urządzeniach:

• POTRZEBNY jest jakikolwiek system wprowadzania danych za pomocą wskaźnika (na przykład myszy lub dotyku).
• POWINNA obsługiwać w pełni niezależnie śledzone wskaźniki.

Jeśli urządzenia są wyposażone w ekran dotykowy (dotykowo lub lepszy) na głównym wyświetlaczu zgodnym z Androidem:

• [C-1-1] MUSI zgłosić TOUCHSCREEN_FINGER w polu interfejsu API Configuration.touchscreen.
• [C-1-2] MUSI zgłosić flagi funkcji android.hardware.touchscreen i android.hardware.faketouch.

Jeśli implementacje urządzeń obejmują ekran dotykowy, który może śledzić więcej niż jeden dotyk na głównym wyświetlaczu zgodnym z Androidem,:

• [C-2-1] MUSI zgłosić odpowiednie flagi funkcji android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand odpowiadające typowi ekranu dotykowego urządzenia.

Jeśli implementacje urządzeń wymagają zewnętrznego urządzenia wejściowego, takiego jak mysz lub kulka (czyli kulka nie dotykając ekranu bezpośrednio), do wprowadzania danych na głównym wyświetlaczu zgodnym z Androidem i spełniają wymagania dotyczące fałszywego dotyku opisane w sekcji 7.2.5:

• [C-3-1] NIE MOŻE zgłaszać żadnych flag funkcji rozpoczynających się od android.hardware.touchscreen.
• [C-3-2] MUSI zgłosić tylko android.hardware.faketouch.
• [C-3-3] MUSI zgłosić TOUCHSCREEN_NOTOUCH w polu interfejsu API Configuration.touchscreen.

7.2.5 Wprowadzanie tekstu fałszywego dotykiem

Fałszywy interfejs dotykowy udostępnia system wprowadzania danych, który w przybliżeniu przedstawia podzbiór możliwości ekranu dotykowego. Na przykład mysz lub pilot, który steruje kursorem na ekranie, przybliża je do kliknięcia, ale wymaga od użytkownika najpierw wyśledzenia lub kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, mysz powietrzna z żyroskopem, żyroskop, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe. Android ma stałą funkcję android.hardware.faketouch, która odpowiada wysokiej jakości bezdotykowemu urządzeniu wejściowemu (opartemu na wskaźniku), takim jak mysz lub trackpad, które może odpowiednio emulować obsługę dotykową (w tym podstawową obsługę gestów). Wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.

Jeśli implementacje urządzeń nie zawierają ekranu dotykowego, ale są wyposażone w inny system wprowadzania danych z wskaźnikiem, który chce udostępnić:

• Trzeba zadeklarować obsługę flagi funkcji android.hardware.faketouch.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.faketouch, będą to:

• [C-1-1] MUSI podawać bezwzględne położenie ekranu na osi X i Y oraz wyświetlać wskaźnik wizualny na ekranie.
• [C-1-2] MUSI zgłaszać zdarzenie dotknięcia za pomocą kodu działania, który określa zmianę stanu, gdy wskaźnik przesuwa się w dół lub w górę na ekranie.
• [C-1-3] MUSI obsługiwać kursor w dół i w górę na obiekcie na ekranie, co umożliwia emulację dotknięcia obiektu na ekranie.
• [C-1-4] MUSI obsługiwać wskaźnik w dół, w górę i w dół, a następnie wskazuje w górę w to samo miejsce na obiekcie na ekranie w określonym przedziale czasu. Pozwala to użytkownikom emulować dwukrotne kliknięcie obiektu na ekranie.
• [C-1-5] MUSI obsługiwać kursor w dół w dowolnym punkcie na ekranie. Wskaźnik przesuwa się do dowolnego innego punktu na ekranie, a za nim wskaźnik w górę, co pozwala emulować przeciąganie dotykiem.
• [C-1-6] MUSI utrzymywać wskaźnik w dół, a następnie umożliwiać użytkownikom szybkie przeniesienie obiektu w inne miejsce na ekranie i przesunięcie go w górę, co umożliwia przesuwanie obiektu na ekranie.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.faketouch.multitouch.distinct:

• [C-2-1] MUSI zadeklarować obsługę interfejsu android.hardware.faketouch.
• [C-2-2] MUSI obsługiwać odrębne śledzenie co najmniej 2 niezależnych danych wejściowych wskaźnika.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.faketouch.multitouch.jazzhand:

• [C-3-1] MUSI zadeklarować obsługę interfejsu android.hardware.faketouch.
• [C-3-2] MUSI obsługiwać odrębne śledzenie 5 (śledzenie dłoni) lub więcej parametrów wejściowych wskaźnika.

7.2.6 Obsługa kontrolera gier

7.2.6.1 Mapowania przycisków

Implementacje na urządzeniach:

• [C-1-1] MUSI być w stanie mapować zdarzenia HID na odpowiednie stałe InputEvent, jak podano w tabelach poniżej. Implementacja Androida spełnia to wymaganie.

Jeśli urządzenia są wyposażone w kontroler lub są dostarczane z osobnym kontrolerem, który umożliwiałby wprowadzanie wszystkich zdarzeń wymienionych w tabelach poniżej:

• [C-2-1] MUSI zadeklarować flagę funkcji android.hardware.gamepad

Przycisk	Wykorzystanie HID2	Przycisk Androida
A1	0x09 0x0001	KEYCODE_PRZYCISK_A (96)
B1	0x09 0x0002	KEYCODE_PRZYCISK_B (97)
X1	0x09 0x0004	KEYCODE_PRZYCISK_X (99)
T1	0x09 0x0005	KEYCODE_PRZYCISK_Y (100)
Pad kierunkowy w górę1 Pad kierunkowy w dół1	0x01 0x00393	AXIS_HAT_Y4
Pad kierunkowy w lewo1 Pad kierunkowy w prawo1	0x01 0x00393	AXIS_HAT_X4
Przycisk na lewym ramieniu1	0x09 0x0007	KEYCODE_Button_L1 (102)
Przycisk na prawym ramieniu1	0x09 0x0008	KEYCODE_PRZYCISK_R1 (103)
Kliknięcie lewym drążkiem1	0x09 0x000E	KEYCODE_button_THUMBL (106)
Kliknięcie prawym przyciskiem myszy1	0x09 0x000F	KEYCODE_button_THUMBR (107)
Wstecz1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Powyższe przypadki użycia HID muszą być zadeklarowane w urzędzie certyfikacji pada do gier (0x01 0x0005).

3 Minimalne wartości logiczne muszą wynosić 0, maksimum logiczne 7, fizyczne minimum to 0, fizyczne maksimum 315, jednostki w stopniach i 4 rozmiar raportu. Wartość logiczna oznacza obrót w prawo od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i naciśnięty przycisk w górę, a wartość logiczna 1 oznacza obrót o 45 stopni oraz naciskanie jednocześnie klawiszy strzałek w górę i w lewo.

4 MotionEvent

Elementy sterujące analogowe1	Wykorzystanie HID	Przycisk Androida
Lewy spust	0x02 0x00C5	AXIS_LTRIGGER
Prawy aktywator	0x02 0x00C4	AXIS_RTRIGGER
Lewy joystick	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Prawy joystick	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_Z

1 MotionEvent

7.2.7 Pilot

Wymagania związane z poszczególnymi urządzeniami znajdziesz w artykule 2.3.1.

7.3. Czujniki

Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma odpowiedni interfejs API dla zewnętrznych programistów, implementacja urządzenia MUSI ją zaimplementować w sposób opisany w dokumentacji pakietu Android SDK i w dokumentacji Androida Open Source w zakresie czujników.

Implementacje na urządzeniach:

• [C-0-1] MUSI dokładnie zgłaszać 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() i podobnych.
• [C-0-3] MUSI działać w rozsądny sposób w przypadku wszystkich innych interfejsów API czujników (na przykład przez zwracanie odpowiednio parametru true lub false, gdy aplikacje próbują rejestrować detektory, a nie wywoływanie detektorów, gdy odpowiednie czujniki nie są dostępne itp.).

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który ma odpowiedni interfejs API dla programistów zewnętrznych,:

• [C-1-1] MUSI raportować wszystkie pomiary z czujników z użyciem odpowiednich wartości Międzynarodowego Systemu Jednostki (danych) dla każdego typu czujnika zgodnie z definicją w dokumentacji pakietu Android SDK.
• [C-1-2] MUSI zgłaszać dane z czujnika z maksymalnym opóźnieniem 100 milisekund + 2 * czas parametru sample_time w przypadku strumienia z czujnika z maksymalnym żądanym czasem oczekiwania wynoszącym 0 ms, gdy procesor aplikacji jest aktywny. Opóźnienie to nie uwzględnia opóźnień w filtrowaniu.
• [C-1-3] MUSI zgłosić pierwszy próbkę czujnika w ciągu 400 milisekund + 2 * czas_próbki (sample_time) czujnika. W przypadku tej próbki dokładność może wynosić 0.
• [C-1-4] W przypadku każdego interfejsu API wskazanego w dokumentacji pakietu Android SDK jako czujnika ciągłego implementacje urządzeń MUSZĄ w sposób ciągły dostarczać okresowe próbki danych, w których zakłócenia są zdefiniowane jako standardowe odchylenie różnicy zgłaszanych wartości sygnatur czasowych między kolejnymi zdarzeniami.
• [C-1-5] MUSI mieć pewność, że strumień zdarzeń z czujnika NIE MOŻE zapobiegać przechodzeniu procesora w stan zawieszenia ani wybudzeniem procesora ze stanu zawieszenia.
• [C-1-6] MUSI raportować czas zdarzenia w nanosekundach, zgodnie z definicją w dokumentacji pakietu Android SDK, wskazując czas wystąpienia zdarzenia i zsynchronizowany z zegarem SystemClock.elapsedRealtimeNano().
• [C-SR-1] ZALECANE jest, aby błąd synchronizacji sygnatury czasowej był krótszy niż 100 milisekund, a błąd synchronizacji sygnatury czasowej był niższy niż 1 milisekunda.
• Gdy aktywowanych jest kilka czujników, zużycie energii NIE POWINNO przekraczać sumy zużycia energii przez poszczególne czujniki.

Powyższa lista nie jest wyczerpująca. Udokumentowane zachowanie pakietu Android SDK i dokumentacji Androida Open Source dotyczące czujników należy uznać za wiarygodne.

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który ma odpowiedni interfejs API dla programistów zewnętrznych,:

• [C-1-6] MUSI ustawić rozdzielczość inną niż 0 dla wszystkich czujników i zgłosić wartość za pomocą metody interfejsu API Sensor.getResolution().

Niektóre typy czujników są złożone, co oznacza, że mogą pochodzić z danych dostarczonych przez co najmniej jeden inny czujnik. (np. czujnik orientacji i czujnika przyspieszenia liniowego).

Implementacje na urządzeniach:

• POWINNA SIĘ stosować te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w sekcji Typy czujników.

Jeśli implementacje urządzeń zawierają czujnik kompozytowy,:

• [C-2-1] MUSI zaimplementować czujnik w sposób opisany w dokumentacji Androida open source dotyczącej czujników złożonych.

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który ma odpowiedni interfejs API dla zewnętrznych programistów, a czujnik zgłasza tylko 1 wartość, to implementacje urządzenia:

• [C-3-1] MUSI ustawić rozdzielczość czujnika na 1 i przesłać wartość za pomocą metody interfejsu API Sensor.getResolution().

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który obsługuje funkcję SensorAdditionalInfo#TYPE_VEC3_CALIBRATION, a czujnik jest widoczny dla programistów zewnętrznych,:

• [C-4-1] NIE MOŻE zawierać w dostarczanych danych żadnych stałych, określonych przez fabrykę parametrów kalibracji.

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

• [C-SR-2] Zdecydowanie zalecana jest sytuacja, w której akcelerometr, żyroskop i magnetometr mają stałe położenie względne, dzięki czemu, jeśli urządzenie można przekształcać (np. składa się), osie czujnika pozostają wyrównane i spójne z układem współrzędnych czujnika we wszystkich możliwych stanach przekształcenia urządzenia.

7.3.1 Akcelerometr

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest użycie 3-osiowego akcelerometru.

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

• [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-2] MUSI zaimplementować i zgłosić czujnik TYPE_ACCELEROMETER.
• [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Androida, jak opisano w interfejsach API Androida.
• [C-1-4] MUSI być w stanie mierzyć od swobodnego spadania do 4-krotności grawitacji(4g) lub większej na dowolnej osi.
• Rozdzielczość [C-1-5] MUSI mieć co najmniej 12 bitów.
• [C-1-6] MUSI mieć odchylenie standardowe nie większe niż 0,05 m/s^, przy czym odchylenie standardowe powinno być obliczane na podstawie poszczególnych osi dla próbek zebranych w okresie co najmniej 3 sekund z największą częstotliwością próbkowania.
• Zdecydowanie ZALECANE jest wdrożenie czujnika kompozytowego TYPE_SIGNIFICANT_MOTION.
• [C-SR-3] Zdecydowanie ZALECANE jest wdrożenie i zgłaszanie czujnika TYPE_ACCELEROMETER_UNCALIBRATED. Zdecydowanie ZALECANE są urządzenia z Androidem, które spełniają to wymaganie, dzięki czemu będą mogły przejść na nową wersję platformy, w której będzie to wymagane.
• NALEŻY zaimplementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR i TYPE_STEP_COUNTER zgodnie z opisem w dokumentacji pakietu Android SDK.
• POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.
• Rozdzielczość powinna wynosić co najmniej 16 bitów.
• POWINNY być kalibrowane podczas używania, jeśli charakterystyka zmieni się w ciągu cyklu życia i zostaną skompensowane, oraz zachowaj parametry kompensacji między restartami urządzenia.
• POWINNA być kompensowana temperatura.

Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr i dowolny z czujników kompozytowych TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR lub TYPE_STEP_COUNTER:

• [C-2-1] Suma ich zużycia energii MUSI zawsze wynosić mniej niż 4 mW.
• Gdy urządzenie jest w stanie dynamicznym lub statycznym, NIE powinna przekraczać 2 mW i 0,5 mW.

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

• [C-3-1] MUSI zaimplementować czujniki kompozytowe TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR-4] Zdecydowanie ZALECANE jest wdrożenie czujnika kompozytowego TYPE_GAME_ROTATION_VECTOR.

Jeśli urządzenia są wyposażone w 3-osiowy akcelerometr, 3-osiowy żyroskop i czujnik magnetometrowy:

• [C-4-1] MUSI zaimplementować czujnik kompozytowy TYPE_ROTATION_VECTOR.

7.3.2 Magnetometr

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest użycie 3-osiowego magnetometru (kompasu).

Jeśli urządzenia są wyposażone w 3-osiowy magnetometr:

• [C-1-1] MUSI zamocować czujnik TYPE_MAGNETIC_FIELD.
• [C-1-2] MUSI zgłaszać zdarzenia z częstotliwością co najmniej 10 Hz, a powinna zgłaszać zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Androida, jak opisano w interfejsach API Androida.
• [C-1-4] MUSI być w stanie zmierzyć wartość od -900 μT do +900 μT na każdej osi bez nasycenia.
• [C-1-5] MUSI mieć wartość przesunięcia twardego żelaza na poziomie mniejszą niż 700 μT, a wartość PRZEWODNIK MUSI mieć wartość mniejszą niż 200 μT, ponieważ magnetometr należy umieszczać z dala od dynamicznych (wywoływanych prądem) i statycznych (wywoływanych magnesem) pól magnetycznych.
• [C-1-6] MUSI mieć rozdzielczość równą lub większą niż 0,6 μT.
• [C-1-7] MUSI obsługiwać kalibrację online i kompensację twardego żelaza i zachowywać parametry kompensacji między restartami urządzenia.
• [C-1-8] MUSI zastosować kompensację miękkiego żelaza – kalibrację można przeprowadzić podczas używania lub produkcji urządzenia.
• [C-1-9] MUSI mieć odchylenie standardowe obliczone na podstawie poszczególnych osi dla próbek zebranych w okresie co najmniej 3 sekund z największą częstotliwością próbkowania, nie większe niż 1,5 μT; odchylenie standardowe nie może przekraczać 0,5 μT.
• [C-1-10] MUSI zamontować czujnik TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Jeśli urządzenia są wyposażone w 3-osiowy magnetometr, akcelerometr i 3-osiowy żyroskop:

• [C-2-1] MUSI zaimplementować czujnik kompozytowy TYPE_ROTATION_VECTOR.

Jeśli urządzenia są wyposażone w 3-osiowy magnetometr (akcelerometr):

• MOŻESZ zastosować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Jeśli urządzenia są wyposażone w 3-osiowy magnetometr, akcelerometr i czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR:

• [C-3-1] MUSI zużywać mniej niż 10 mW.
• Gdy czujnik jest zarejestrowany w trybie wsadowym z częstotliwością 10 Hz, NALEŻY zużywać mniej niż 3 mW.

7.3.3 GPS

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest użycie odbiornika GPS/GNSS.

Jeśli implementacje urządzeń obejmują odbiornik GPS/GNSS i zgłaszają możliwość aplikacji za pomocą flagi funkcji android.hardware.location.gps, to:

• [C-1-1] MUSI obsługiwać dane wyjściowe z lokalizacją z częstotliwością co najmniej 1 Hz, gdy jest to wymagane przez LocationManager#requestLocationUpdate.
• [C-1-2] MUSI określić lokalizację na otwartym niebie (silne sygnały, niedostateczna ścieżka wielościeżkowa, HDOP < 2) w ciągu 10 sekund (szybko do pierwszej naprawy) przy połączeniu z internetem o szybkości 0,5 Mb/s lub szybszej. Wymóg ten jest zazwyczaj spełniony przy użyciu pewnej formy metody wspomagania lub przewidywanego GPS/GNSS w celu zminimalizowania czasu blokady GPS/GNSS (dane pomocnicze obejmują czas odniesienia, lokalizację referencyjną i satelitarne dane efemeryczne/zegar).
  • [C-1-6] Po obliczeniu lokalizacji urządzenia implementacje MUSZĄ określić jego lokalizację na otwartym niebie w ciągu 5 sekund, gdy żądania lokalizacji są ponownie uruchamiane, w ciągu maksymalnie godziny od początkowego obliczenia lokalizacji, nawet jeśli kolejne żądanie jest wysyłane bez połączenia do transmisji danych lub po wyłączeniu urządzenia.

• Na otwartym niebie po określeniu lokalizacji, gdy jesteś w miejscu lub poruszasz się z przyspieszeniem poniżej 1 metra na sekundę do kwadratu:

  • [C-1-3] MUSI określić lokalizację z dokładnością do 20 metrów i z prędkością do 0, 5 metra na sekundę, w co najmniej 95% przypadków.
  • [C-1-4] MUSI jednocześnie śledzić i raportować za pomocą GnssStatus.Callback co najmniej 8 satelitów z 1 konstelacji.
  • POWINNA być w stanie jednocześnie śledzić co najmniej 24 satelity pochodzące z wielu konstelacji (np. GPS + przynajmniej jeden Glonass, Beidou, Galileo).

• [C-SR-2] Zdecydowanie ZALECANE jest dalsze działanie zwykłych danych o lokalizacji GPS/GNSS przy użyciu interfejsu API GNSS Location Provider API podczas alarmowego połączenia telefonicznego.

• [C-SR-3] Zdecydowanie ZALECANE są raportowanie pomiarów GNSS ze wszystkich śledzonych konstelacji (jak podawana w komunikatach GnssStatus), z wyjątkiem SBAS.

• [C-SR-4] Zdecydowanie ZALECANE są raporty AGC i częstotliwość pomiarów GNSS.

• [C-SR-5] Zdecydowanie ZALECANE jest raportowanie wszystkich szacunków dokładności (w tym położenia, prędkości i pionu) w ramach każdej lokalizacji GPS/GNSS.

• [C-SR-6] Zdecydowanie ZALECANE jest zgłaszanie pomiarów GNSS, gdy tylko zostaną wykryte, nawet jeśli lokalizacja określona na podstawie GPS/GNSS nie jest jeszcze raportowana.

• [C-SR-7] Zdecydowanie ZALECANE są raportowanie pseudozakresów i wskaźników pseudozakresowych GNSS, że w warunkach na otwartym niebie po określeniu lokalizacji, gdy nieruchomo lub w ruchu z przyspieszeniem poniżej 0,2 metra na sekundę do kwadratu, wystarczają do obliczenia pozycji z dokładnością do 20 metrów, z prędkością do co najmniej 0, 2 metra na sekundę.

7.3.4 Żyroskop

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest użycie czujnika żyroskopu.

Jeśli urządzenia są wyposażone w 3-osiowy żyroskop:

• [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-2] MUSI zamocować czujnik TYPE_GYROSCOPE.
• Rozdzielczość [C-1-4] MUSI mieć co najmniej 12 bitów.
• [C-1-5] MUSI mieć kompensację temperatury.
• [C-1-6] MUSI być skalibrowany i skompensowany podczas używania. Zachowaj parametry kompensacji między restartami urządzenia.
• [C-1-7] MUSI mieć wariancję nie większą niż 1e–7 rad^2 / s^2 na Hz (wariancja na Hz lub rad^2 / s). Wariancja może się zmieniać zależnie od częstotliwości próbkowania, ale MUSI być ograniczana przez tę wartość. Inaczej mówiąc, jeśli mierzysz wariancję żyroskopu przy częstotliwości próbkowania 1 Hz, NIE POWINNA być ona większa niż 1e–7 rad^2/s^2.
• [C-SR-2] ZAWSZE ZALECANE jest, aby błąd kalibracji wynosił mniej niż 0,01 rad/s, gdy urządzenie pozostaje w temperaturze pokojowej.
• [C-SR-3] Zdecydowanie ZALECANE jest wdrożenie czujnika TYPE_GYROSCOPE_UNCALIBRATED.
• [C-SR-4] Zdecydowanie ZALECANE są rozdzielczość 16-bitowa lub większa.
• POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.

Jeśli urządzenia są wyposażone w 3-osiowy żyroskop, akcelerometr i czujnik magnetometru:

• [C-2-1] MUSI zaimplementować czujnik kompozytowy TYPE_ROTATION_VECTOR.

Jeśli urządzenia są wyposażone w 3-osiowy akcelerometr i 3-osiowy żyroskop:

• [C-3-1] MUSI zaimplementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR-5] Zdecydowanie ZALECANE jest wdrożenie czujnika kompozytowego TYPE_GAME_ROTATION_VECTOR.

7.3.5 Barometr

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest dodanie barometru (czujnika ciśnienia powietrza).

Jeśli implementacje urządzeń obejmują barometr:

• [C-1-1] MUSI zaimplementować i zgłosić czujnik TYPE_PRESSURE.
• [C-1-2] MUSI być w stanie przesyłać zdarzenia z częstotliwością 5 Hz lub większą.
• [C-1-3] MUSI mieć kompensację temperatury.
• [C-SR-2] Zdecydowanie zalecana jest możliwość raportowania ciśnienia w zakresie od 300 hPa do 1100 hPa.
• Całkowita dokładność 1hPa.
• MUSI mieć względną dokładność 0,12 hPa w zakresie 20 hPa (odpowiednik dokładności ok. 1 m przy ok. 200 m na poziomie morza).

7.3.6 Thermometer

Jeśli implementacje urządzeń obejmują termometr otoczenia (czujnik temperatury):

• [C-1-1] MUSI zdefiniować parametr SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury otoczenia, a czujnik MUSI mierzyć temperaturę otoczenia (w pomieszczeniu lub kabinie pojazdu) z miejsca, w którym użytkownik wchodzi w interakcję z urządzeniem, wyrażoną w stopniach Celsjusza.

Jeśli implementacje urządzeń obejmują czujnik termometr, który mierzy temperaturę inną niż temperatura otoczenia (np. temperaturę procesora), spełniają one te warunki:

• [C-2-1] NIE MOŻE definiować właściwości SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury.

Jeśli urządzenia mają czujnik do monitorowania temperatury skóry, :

• [C-SR-1] Zdecydowanie ZALECANE jest obsługa interfejsu API PowerManager.getThermalHeadroom.

7.3.7 Fotometr

• Urządzenia MOGĄ zawierać fotometr (czujnik jasności otoczenia).

7.3.8 Czujnik zbliżeniowy

• Urządzenia MOGĄ zawierać czujnik zbliżeniowy.

Jeśli implementacje urządzeń zawierają czujnik zbliżeniowy, który zgłasza tylko odczyt binarny „w pobliżu” lub „daleko”, oznacza to, że:

• [C-1-1] MUSI mierzyć odległość od obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI wykrywać obiekty znajdujące się blisko ekranu, ponieważ jego głównym celem jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacje urządzeń obejmują czujnik zbliżeniowy o jakiejkolwiek innej orientacji, NIE MOŻE być dostępny za pomocą tego interfejsu API.
• [C-1-2] MUSI mieć co najmniej 1 bit z dokładnością.
• [C-1-3] MUSI używać 0 centymetrów jako odczytu bliskiego, a 5 centymetrów w przypadku dalekiego.
• [C-1-4] MUSI zgłosić maksymalny zakres i rozdzielczość 5.

7.3.9. Czujniki wysokiej jakości

Jeśli implementacje urządzeń obejmują zestaw czujników o wyższej jakości (zgodnie z definicją w tej sekcji) i udostępniają je aplikacjom innych firm,:

• [C-1-1] MUSI identyfikować możliwość za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

Jeśli implementacje urządzenia zadeklarują android.hardware.sensor.hifi_sensors:

• [C-2-1] MUSI mieć czujnik TYPE_ACCELEROMETER, który:

  • MUSI mieć zakres pomiarów od -8 g do +8 g, a Zdecydowanie ZALECANE jest zakres pomiarów od -16 g do +16 g.
  • Rozdzielczość pomiaru MUSI mieć wartość co najmniej 2048 LSB/g.
  • Minimalna częstotliwość pomiaru musi wynosić 12,5 Hz lub mniejszą.
  • MUSI mieć maksymalną częstotliwość pomiaru 400 Hz lub większą. POWINNO obsługiwać kanał SensorDirectChannel RATE_VERY_FAST.
  • Poziom szumu pomiarowego MUSZĄ być większy niż 400 μg/√Hz.
  • MUSI zastosować czujnik bez wybudzania, z możliwością buforowania wynoszącą co najmniej 3000 zdarzeń.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 3 mW.
  • [C-SR-1] Zdecydowanie ZALECANE jest użycie przepustowości pomiaru na poziomie 3 dB na poziomie co najmniej 80% częstotliwości Nyquist oraz spektrum szumu białego w ramach tej przepustowości.
  • TREŚCI POWINNY być testowane przy przyspieszeniu losowy spacer o wartości poniżej 30 μg √Hz w temperaturze pokojowej.
  • MUSISZ mieć zmianę odchylenia w porównaniu z temperaturą na poziomie ≤ +/- 1 mg/°C.
  • Najbardziej optymalna nieliniowalność linii powinna wynosić ≤ 0,5%, a zmiana czułości w porównaniu do temperatury na poziomie ≤ 0,03%/C°.
  • Czułość przekrojowa musi wynosić < 2,5%, a jej różnica w zakresie temperatur działania urządzenia wynosi < 0,2%.

• [C-2-2] MUSI mieć TYPE_ACCELEROMETER_UNCALIBRATED z takimi samymi wymaganiami dotyczącymi jakości jak TYPE_ACCELEROMETER.

• [C-2-3] MUSI mieć czujnik TYPE_GYROSCOPE, który:

  • MUSI mieć zakres pomiaru od -1000 do +1000 dps.
  • Rozdzielczość pomiaru MUSI mieć co najmniej 16 LSB/dps.
  • Minimalna częstotliwość pomiaru musi wynosić 12,5 Hz lub mniejszą.
  • MUSI mieć maksymalną częstotliwość pomiaru 400 Hz lub większą. POWINNO obsługiwać kanał SensorDirectChannel RATE_VERY_FAST.
  • Poziom szumu pomiarowego MUSZĄ być większy niż 0,014°/s/√Hz.
  • [C-SR-2] Zdecydowanie ZALECANE jest użycie przepustowości pomiaru na poziomie 3 dB na poziomie co najmniej 80% częstotliwości Nyquist oraz spektrum szumu białego w ramach tej przepustowości.
  • Częstotliwość losowych spacerów MUSI być testowana w temperaturze pokojowej na poziomie niższym niż 0,001°/s √Hz.
  • MUSI mieć zmianę odchylenia w porównaniu z temperaturą na poziomie ≤ +/- 0,05°/ s / °C.
  • TRZEBA zmienić czułość w porównaniu z temperaturą na poziomie ≤ 0,02% / °C.
  • Optymalny rozmiar nieliniowości musi wynosić ≤ 0,2%.
  • Gęstość szumu powinna wynosić ≤ 0,007°/s/√ Hz.
  • Błąd kalibracji powinien wynosić mniej niż 0,002 rad/s w zakresie temperatur od 10 do 40°C, gdy urządzenie jest nieruchome.
  • Czułość g powinna być mniejsza niż 0,1°/s/g.
  • Czułość krzyżowa powinna wynosić < 4,0%, a zmienność czułości na osi krzyżowej powinna wynosić < 0,3% w zakresie temperatur działania urządzenia.

• [C-2-4] MUSI mieć TYPE_GYROSCOPE_UNCALIBRATED o takich samych wymaganiach dotyczących jakości co TYPE_GYROSCOPE.

• [C-2-5] MUSI mieć czujnik TYPE_GEOMAGNETIC_FIELD, który:

  • MUSI mieć zakres pomiaru od -900 do +900 μT.
  • MUSI mieć rozdzielczość pomiaru wynoszącą co najmniej 5 LSB/uT.
  • MUSI mieć minimalną częstotliwość pomiaru 5 Hz lub mniejszą.
  • Maksymalna częstotliwość pomiaru MUSI 50 Hz lub większa.
  • MUSI zawierać szum pomiarowy nie większy niż 0,5 uT.

• [C-2-6] MUSI mieć TYPE_MAGNETIC_FIELD_UNCALIBRATED z tymi samymi wymaganiami dotyczącymi jakości co TYPE_GEOMAGNETIC_FIELD, a także:

  • MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 600 zdarzeń.
  • [C-SR-3] Zdecydowanie ZALECANE jest użycie widma szumu białego w zakresie od 1 Hz do co najmniej 10 Hz, gdy częstotliwość raportowania wynosi 50 Hz lub więcej.

• [C-2-7] MUSI mieć czujnik TYPE_PRESSURE, który:

  • MUSI mieć zakres pomiaru od 300 do 1100 hPa.
  • Rozdzielczość pomiaru MUSI mieć co najmniej 80 LSB/hPa.
  • Minimalna częstotliwość pomiaru musi wynosić 1 Hz lub mniejszą.
  • Maksymalna częstotliwość pomiaru MUSI wynosić 10 Hz lub więcej.
  • Poziom szumu pomiarowego MUSI być większy niż 2 Pa/√ Hz.
  • MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 300 zdarzeń.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 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 nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy jest w ruchu.

• [C-2-10] MUSI mieć czujnik TYPE_STEP_DETECTOR, który:

  • MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 100 zdarzeń.
  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy jest w ruchu.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 4 mW.

• [C-2-11] MUSI mieć czujnik TYPE_STEP_COUNTER, który:

  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy jest w ruchu.

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

  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy jest w ruchu.

• [C-2-13] Sygnatura czasowa tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr, żyroskop i magnetometr MUSI zawierać się w odległości maksymalnie 2, 5 milisekundy. Sygnatura czasowa tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr i żyroskop POWINIEN być oddalona od siebie w odległości maksymalnie 0,25 milisekundy.

• [C-2-14] MUSI mieć sygnatury czasowe zdarzeń z czujnika żyroskopu w tym samym czasie co podsystem kamery i z dokładnością do 1 milisekundy od błędu.

• [C-2-15] MUSI dostarczyć próbki do aplikacji w ciągu 5 milisekund od momentu, gdy dane są dostępne w dowolnym z powyższych czujników fizycznych do aplikacji.

• [C-2-16] NIE MOŻE generować mocy o mocy większej niż 0,5 mW, gdy urządzenie jest statyczne, i 2,0 mW, gdy jest w ruchu, gdy włączona jest dowolna kombinacja tych czujników:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] MOŻE mieć czujnik TYPE_PROXIMITY, ale jeśli jest zainstalowany, MUSI mieć minimalny bufor o zmienności 100 zdarzeń.

Wszystkie wymagania dotyczące zużycia energii opisane w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje on moc pobieraną przez cały łańcuch czujników – czujnik, dowolny obwód pomocniczy, dedykowany system przetwarzania czujników itp.

Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników:

• [C-3-1] MUSI prawidłowo zadeklarować obsługę typów kanałów bezpośrednich i poziomu stawek za zgłaszanie bezpośrednie w interfejsach API isDirectChannelTypeSupported i getHighestDirectReportRateLevel.
• [C-3-2] MUSI obsługiwać co najmniej 1 z 2 typów kanałów bezpośredniego czujnika w przypadku wszystkich czujników, które deklarują obsługę kanału bezpośredniego.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• POWINNA obsługiwać raportowanie zdarzeń za pomocą kanału bezpośredniego czujnika w przypadku głównego czujnika (wariant wybudzenia) 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 dotyczącej pomiaru zabezpieczeń biometrycznych.

Jeśli implementacje urządzeń obejmują bezpieczny ekran blokady:

• POWINNA zawierać czujnik biometryczny

Czujniki biometryczne mogą być klasyfikowane jako klasa 3 (wcześniej Silne), klasa 2 (wcześniej słaba) lub klasa 1 (wcześniej Wygoda) na podstawie współczynnika akceptowania fałszywych i fałszywych danych oraz bezpieczeństwa potoku biometrycznego. Klasyfikacja ta określa możliwości, jakie czujnik biometryczny ma w interfejsie z platformą i aplikacjami innych firm. Czujniki są domyślnie klasyfikowane jako klasa 1. Jeśli mają zostać sklasyfikowane jako klasa 2 lub klasa 3, muszą spełniać dodatkowe wymagania opisane poniżej. Zarówno biometria klasy 2, jak i klasy 3 mają dodatkowe możliwości, które opisaliśmy poniżej.

Jeśli implementacje urządzeń udostępniają czujnik biometryczny aplikacjom innych firm za pomocą interfejsów android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt i android.provider.Settings.ACTION_BIOMETRIC_ENROLL, funkcje te:

• [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 uwzględniać każdą nazwę parametru zdefiniowaną jako stałą w klasie Authenticators oraz wszelkie ich kombinacje. I odwrotnie, NIE MOŻE spełniać ani rozpoznawać stałych liczb całkowitych przekazywanych do metod canAuthenticate(int) i setAllowedAuthenticators(int), które nie jest zgodne ze stałymi publicznymi w narzędziu Authenticator, a także ich kombinacjami.
• [C-4-3] MUSI zaimplementować działanie ACTION_BIOMETRIC_ENROLL na urządzeniach korzystających z biometrii klasy 3 lub klasy 2. To działanie MUSI przedstawiać tylko punkty wejścia do rejestracji w przypadku danych biometrycznych klasy 3 lub klasy 2.

Jeśli implementacje urządzeń obsługują pasywną biometrię:

• [C-5-1] Domyślnie MUSI wymagać dodatkowego potwierdzenia (np. naciśnięcia przycisku).
• [C-SR-1] Zdecydowanie ZALECANE jest ustawienie ustawienia, które umożliwia użytkownikom zastąpienie preferencji aplikacji i zawsze wymaga towarzyszącego kroku potwierdzenia.
• [C-SR-2] Zdecydowanie ZALECANE jest zabezpieczanie działania potwierdzonego, tak aby system operacyjny lub przejęcie jądra nie umożliwiały podszywania się pod inne osoby. Na przykład oznacza to, że działanie potwierdzenia na podstawie fizycznego przycisku jest kierowane przez styk wejściowe/wyjściowe ogólnego przeznaczenia (GPIO) bezpiecznego elementu (SE), którego nie da się wywołać w żaden inny sposób niż przez fizyczne naciśnięcie przycisku.
• [C-5-2] MUSI dodatkowo zaimplementować proces niejawnego uwierzytelniania (bez kroku potwierdzania) odpowiadający funkcji setConfirmationRequired(boolean), której aplikacje mogą używać w procesach logowania.

Jeśli urządzenia są wyposażone w kilka czujników biometrycznych:

• [C-SR-3] Zdecydowanie ZALECANE jest wymaganie tylko jednego uwierzytelniania biometrycznego (np. jeśli na urządzeniu dostępne są zarówno odciski palców, jak i czujniki twarzy, po potwierdzeniu dowolnego z nich należy wysłać onAuthenticationSucceeded).

Aby implementacje urządzeń umożliwiały dostęp aplikacji innych firm do kluczy magazynu kluczy:

• [C-6-1] MUSI spełniać wymagania dotyczące klasy 3 zdefiniowane w tej sekcji poniżej.
• [C-6-2] MUSI przedstawiać dane biometryczne klasy 3, gdy uwierzytelnianie wymaga BIOMETRIC_STRONG, lub gdy uwierzytelnianie jest wywoływane za pomocą CryptoObject.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 1 (dawniej Wygoda), muszą:

• [C-1-1] MUSI mieć współczynnik fałszywych akceptacji niższy niż 0,002%.
• [C-1-2] MUSI ujawniać, że ten tryb może być mniej bezpieczny niż silny kod PIN, wzór lub hasło i wyraźnie informować o ryzyku jego włączenia, jeśli odsetek fałszywych użytkowników jest wyższy niż 7%, zgodnie z pomiarami protokołów testów biometrycznych Androida.
• [C-1-9] MUSI wymagać uwierzytelniania użytkownika za pomocą zalecanego podstawowego uwierzytelniania (np.kodu PIN, wzoru, hasła) po maksymalnie 20 fałszywych próbach i nie krótszym niż 90 sekund w przypadku weryfikacji biometrycznej. Fałszywy test oznacza taką, w której jakość zapisu (BIOMETRIC_ACQUIRED_GOOD) nie odpowiada zarejestrowanych danych biometrycznych.
• [C-SR-4] Zdecydowanie ZALECANE jest zmniejszenie łącznej liczby fałszywych prób weryfikacji biometrycznej określonej w kodzie [C-1-9], jeśli odsetek fałszywych informacji w ramach testów biometrycznych Androida wynosi ponad 7%.
• [C-1-3] MUSI mieć limit prób weryfikacji biometrycznej – jeśli fałszywa próba ma odpowiednią jakość zapisu (BIOMETRIC_ACQUIRED_GOOD), która nie odpowiada zarejestrowanej biometrii.
• [C-SR-5] Zdecydowanie ZALECANE jest ograniczenie liczby prób weryfikacji biometrycznej przez co najmniej 30 sekund po 5 fałszywych próbach w przypadku maksymalnej liczby fałszywych prób na [C-1-9]. Fałszywa próba to taka, w której jakość zapisu (BIOMETRIC_ACQUIRED_GOOD) nie odpowiada zarejestrowanych danych biometrycznych.
• [C-SR-6] Zdecydowanie ZALECANE jest użycie w TEE wszystkich procesów ograniczających liczbę żądań.
• [C-1-10] MUSI wyłączyć biometrię po pierwszym uruchomieniu podstawowego uwierzytelniania, jak opisano w artykule 9.11 w części [C-0-2].
• [C-1-4] MUSI powstrzymywać dodawanie nowych danych biometrycznych bez wcześniejszego budowania łańcucha zaufania przez potwierdzenie istniejących danych uwierzytelniających urządzenia lub dodanie nowych danych uwierzytelniających urządzenia (kodu PIN, wzoru/hasła) zabezpieczonego przez TEE. Wdrożenie projektu Android Open Source Project zapewnia w ramach ten mechanizm.
• [C-1-5] MUSI całkowicie usunąć wszystkie dane biometryczne umożliwiające identyfikację użytkownika wraz z usunięciem jego konta (w tym po przywróceniu ustawień fabrycznych).
• [C-1-6] MUSI uwzględniać poszczególne oznaczenia biometryczne (tj. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE lub DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
• [C-1-7] MUSI wymagać od użytkownika zalecanego uwierzytelnienia podstawowego (np. kodu PIN, wzoru, hasła): a) co 24 godziny lub częściej w przypadku urządzeń z Androidem w wersji 9 lub nowszej albo b) co 72 godziny lub rzadziej w przypadku urządzeń z Androidem 8 lub starszym.

• [C-1-8] MUSI wymagać uwierzytelniania użytkownika za pomocą zalecanego podstawowego uwierzytelniania (np. kodu PIN, wzoru, hasła) lub użycia danych biometrycznych klasy 3 (STRONG) po wykonaniu jednego z tych działań:

  • 4-godzinny limit czasu bezczynności LUB

  • 3 nieudane próby uwierzytelnienia biometrycznego.

• [C-SR-7] Zdecydowanie ZALECANE jest użycie logiki w ramach platformy Android Open Source Project do egzekwowania w przypadku nowych urządzeń ograniczeń określonych w artykułach [C-1-7] i [C-1-8].

• [C-SR-8] Zdecydowanie ZALECANE jest, aby wskaźnik fałszywych odrzuceń wynosił mniej niż 10%, zgodnie z pomiarem na urządzeniu.

• [C-SR-9] Zdecydowanie ZALECANE jest opóźnienie poniżej 1 sekundy, mierzone od momentu wykrycia biometrii do momentu odblokowania ekranu w przypadku każdego zarejestrowanego urządzenia biometrycznego.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 2 (wcześniej słabe), muszą one:

• [C-2-1] MUSI spełniać wszystkie wymagania dotyczące klasy 1 powyżej.
• [C-2-2] MUSI mieć współczynnik akceptacji fałszywych użytkowników nie wyższy niż 20%, zgodnie z pomiarami protokołów testów biometrycznych Androida.
• [C-2-3] MUSI przeprowadzić dopasowywanie biometryczne w wyizolowanym środowisku wykonawczym poza środowiskiem wykonawczym Androida, takim jak Trusted Execution Environment (TEE), lub na układzie z bezpiecznym kanałem i w odizolowanym środowisku wykonawczym.
• [C-2-4] MUSI mieć zaszyfrowane i uwierzytelnione kryptograficznie wszystkie dane umożliwiające identyfikację, tak aby nie można było ich pozyskać, odczytać ani zmienić poza wyodrębnionym środowiskiem wykonawczym lub elementem z bezpiecznym kanałem prowadzącym do izolowanego środowiska wykonawczego, jak opisano w wytycznych dotyczących implementacji na stronie projektu Android Open Source Project.
• [C-2-5] W przypadku urządzeń biometrycznych z użyciem aparatu i uwierzytelniania biometrycznego lub rejestracji:
  • MUSI obsługiwać kamerę w trybie, który uniemożliwia odczyt i zmienianie klatek kamery poza osobnym środowiskiem wykonawczym lub układowi z bezpiecznym kanałem prowadzącym do wyodrębnionego środowiska wykonawczego.
  • W przypadku rozwiązań RGB z jedną kamerą ramki kamery MOGĄ być odczytywane poza izolowanym środowiskiem wykonawczym na potrzeby operacji takich jak podgląd w celu rejestracji, ale NIE WOLNO ich zmieniać.
• [C-2-6] NIE MOŻE umożliwiać aplikacjom innych firm rozróżniania poszczególnych rejestracji biometrycznych.
• [C-2-7] NIE MOŻE umożliwiać niezaszyfrowanego dostępu do danych biometrycznych możliwych do zidentyfikowania ani żadnych danych pochodzących z nich (takich jak wektory dystrybucyjne) do podmiotu przetwarzającego aplikację poza kontekstem TEE. Aktualizacje urządzeń z Androidem w wersji 9 lub starszej nie są zwolnione z obowiązku spełnienia wymogów zasad C-2-7.

• [C-2-8] MUSI mieć bezpieczny potok przetwarzania, dzięki któremu system operacyjny lub przejęcie jądra nie pozwalają na bezpośrednie wstrzykiwanie danych w celu fałszywego uwierzytelnienia użytkownika.

• [C-SR-10] Zdecydowanie ZALECANE jest włączenie wykrywania życia za pomocą wszystkich modalności biometrycznych i wykrywania uwagi na potrzeby biometrii twarzy.

• [C-2-9] MUSI 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 klasy 2 powyżej z wyjątkiem [C-1-7] i [C-1-8].
• [C-3-2] MUSI mieć implementację magazynów kluczy wspieranych sprzętowo.
• [C-3-3] MUSI mieć wskaźnik akceptacji i podszywać się pod użytkowników, który nie przekracza 7%, zgodnie z pomiarami protokołów testów biometrycznych Androida.
• [C-3-4] MUSI wymagać od użytkownika przeprowadzenia zalecanego podstawowego uwierzytelniania (np. kodu PIN, wzoru, hasła) co 72 godziny lub częściej.
• [C-3-5] MUSI ponownie wygenerować identyfikator uwierzytelniania dla wszystkich biometrii klasy 3 obsługiwanych na urządzeniu, jeśli któraś z nich zostanie ponownie zarejestrowana.
• [C-3-6] Trzeba włączyć obsługiwane biometrycznie klucze magazynu kluczy dla aplikacji innych firm.

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

• [C-SR-11] Zdecydowanie ZALECANE jest zapobieganie zakłócaniu nawigacji przy użyciu 3 przycisków przez dotykowy obszar UDFPS( co niektórzy użytkownicy mogą wymagać ze względu na ułatwienia dostępu).

7.3.12. Czujnik pozycji

Implementacje na urządzeniach:

• MOŻE obsługiwać czujnik pozycji z 6 stopniami swobody.

Jeśli implementacje urządzeń obsługują czujnik pozycji z sześcioma stopniami swobody:

• [C-1-1] MUSI zaimplementować i zgłosić czujnik TYPE_POSE_6DOF.
• [C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.

7.3.13. Czujnik kąta nachylenia

Jeśli urządzenia obsługują czujnik kąta zawiasu:

• [C-1-1] MUSI wdrożyć i zgłosić stronę TYPE_HINGLE_ANGLE.
• [C-1-2] MUSI obsługiwać co najmniej 2 odczyty od 0 do 360 stopni (włącznie, tzn. w tym od 0 do 360 stopni).
• [C-1-3] MUSI zwrócić czujnik wybudzenia dla urządzenia getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4 Połączenie transmisji danych

7.4.1 Telefonia

Termin „telefonia” jest używany w interfejsach API Androida, a ten dokument odnosi się w szczególności do sprzętu do nawiązywania połączeń głosowych i wysyłania SMS-ów przez sieć GSM lub CDMA. Te połączenia głosowe mogą, ale nie muszą, być przełączane pakietami, ale do celów Androida są one uważane za niezależne od łącza transmisji danych, które mogą być realizowane w tej samej sieci. Innymi słowy, funkcje „telefonii” i interfejsy API w Androidzie odnoszą się w szczególności do połączeń głosowych i SMS-ów. Na przykład urządzenia, które nie mogą nawiązywać połączeń ani wysyłać/odbierać SMS-ów, nie są uznawane za urządzenia telefoniczne, niezależnie od tego, czy korzystają z sieci komórkowej do przesyłania danych.

• 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ą usługę telefonii GSM lub CDMA:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.telephony i inne flagi funkcji podrzędnych zgodnie z technologią.
• [C-1-2] MUSI wdrożyć pełną obsługę interfejsu API dla danej technologii.
• POWINNA zezwalać na wszystkie dostępne typy usług komórkowych (2G, 3G, 4G, 5G itp.) podczas połączeń alarmowych (niezależnie od typów sieci ustawionych przez SetAllowedNetworkTypeBitmap()).

Jeśli implementacje urządzenia nie obejmują sprzętu telefonicznego:

• [C-2-1] MUSI wdrożyć pełne interfejsy API w trybie bezobsługowym.

Jeśli implementacje urządzeń obsługują karty eUICC lub eSIM/wbudowane karty SIM i zawierają zastrzeżony mechanizm udostępniania funkcji eSIM deweloperom zewnętrznym:

• [C-3-1] MUSI zawierać pełną implementację EuiccManager API.

Jeśli implementacje urządzeń nie ustawią w usłudze systemowej ro.telephony.iwlan\_operation\_mode ustawienia „Legacy” (starsza wersja), wykonaj te czynności:

• [C-4-1] NIE MOŻE zgłaszać „NETWORK_TYPE_IWLAN” za pomocą NetworkRegistrationInfo#getAccessNetworkTechnology(), gdy NetworkRegistrationInfo#getTransportType() zostanie zgłoszone jako „TRANSPORT_TYPE_WWAN” dla tej samej instancji NetworkRegistrationInfo.

Jeśli implementacje urządzeń obsługują jedną rejestrację podsystemu multimedialnego IP (IMS) zarówno na potrzeby funkcji MMTEL, jak i multimedialnych usług komunikacyjnych (RCS), oraz powinny spełniać wymagania operatora sieci komórkowej dotyczące używania pojedynczej rejestracji IMS dla całego ruchu sygnalizacyjnego IMS:

• [C-5-1] MUSI zadeklarować flagę funkcji android.hardware.telephony.ims i zapewnić pełną implementację interfejsu ImsService API zarówno w przypadku MMTEL, jak i RCS User Capability Exchange API.
• [C-5-2] MUSI zadeklarować flagę funkcji android.hardware.telephony.ims.singlereg i zapewnić pełną implementację interfejsu SipTransport API, interfejsu GbaService API, dedykowane wskazówki dotyczące okaziciela korzystające z interfejsu HAL IRadio 1.6 oraz obsługę administracyjną za pomocą serwera automatycznej konfiguracji (ACS) lub innego zastrzeżonego mechanizmu obsługi administracyjnej za pomocą interfejsu IMS Configuration API.

7.4.1.1 Zgodność z blokadami numerów

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

• [C-1-1] MUSI obsługiwać blokowanie numerów
• [C-1-2] MUSI w pełni wdrożyć BlockedNumberContract i odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-3] MUSI blokować wszystkie połączenia i wiadomości z numeru telefonu w elemencie „BlockNumberProvider” bez interakcji z aplikacjami. Jedynym wyjątkiem jest sytuacja, w której blokowanie numerów jest tymczasowo znoszone w sposób opisany w dokumentacji pakietu SDK.
• [C-1-4] W przypadku zablokowanego wywołania NIE MOŻE zapisywać danych do dostawcy rejestru połączeń platformy.
• [C-1-5] NIE MOŻE pisać do dostawcy usług telefonicznych w przypadku zablokowanej wiadomości.
• [C-1-6] MUSI wdrożyć interfejs zarządzania zablokowanymi liczbami, który jest otwierany z intencją zwracaną przez metodę TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NIE MOŻE umożliwiać użytkownikom pomocniczym wyświetlania ani edytowania zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że główny użytkownik ma pełną kontrolę nad poszczególnymi instancjami usług telefonicznych na urządzeniu. Interfejs powiązany z blokowaniem MUSI być ukryty dla użytkowników pomocniczych, a lista zablokowanych MUSI być respektowana.
• po zaktualizowaniu Androida do wersji 7.0 NALEŻY przenieść zablokowane numery do dostawcy usług.

7.4.1.2. Telecom API

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

• [C-1-1] MUSI obsługiwać interfejsy API ConnectionService opisane w pakiecie SDK.
• [C-1-2] MUSI wyświetlić nowe połączenie przychodzące i zapewnić użytkownikowi zgodę na zaakceptowanie lub odrzucenie połączenia przychodzącego, gdy użytkownik jest w trakcie trwającego połączenia, które zostało wykonane przez aplikację innej firmy, która nie obsługuje funkcji blokady określonej w CAPABILITY_SUPPORT_HOLD.
• [C-1-3] MUSI mieć aplikację, która implementuje InCallService.

• [C-SR-1] Zdecydowanie ZALECANE jest powiadamianie użytkownika, że odebranie połączenia przychodzącego spowoduje przerwanie trwającego połączenia.

  Implementacja AOSP spełnia te wymagania dzięki wyświetlaniu powiadomienia z ostrzeżeniem, które informuje użytkownika, że odebranie połączenia przychodzącego spowoduje odrzucenie drugiego połączenia.

• [C-SR-1] Zdecydowanie ZALECANE jest wstępne wczytywanie domyślnej aplikacji telefonu, która wyświetla wpis rejestru połączeń i nazwę aplikacji innej firmy w dzienniku połączeń, gdy aplikacja innej firmy ustawia klucz EXTRA_LOG_SELF_MANAGED_CALLS na PhoneAccount na true.

• [C-SR-2] Zdecydowanie ZALECANE jest obsługa zdarzeń KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK zestawu słuchawkowego audio w interfejsach API android.telecom w następujący sposób:

  • Wywołaj Connection.onDisconnect(), gdy zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia podczas trwającej rozmowy.
  • Wywołaj Connection.onAnswer() po wykryciu krótkiego naciśnięcia kluczowego zdarzenia podczas połączenia przychodzącego.
  • Wywołaj Connection.onReject() po wykryciu długiego naciśnięcia kluczowego zdarzenia podczas połączenia przychodzącego.
  • Przełącz stan wyciszenia elementu CallAudioState.

7.4.2 IEEE 802.11 (Wi-Fi)

Implementacje na urządzeniach:

• POWINNO obsługiwać co najmniej jedną formę standardu 802.11.

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

• [C-1-1] MUSI wdrożyć odpowiedni interfejs API Androida.
• [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.wifi.
• [C-1-3] MUSI wdrożyć interfejs API multicast w sposób opisany 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 dowolnym momencie działania, w tym:
  • Nawet wtedy, gdy ekran nie jest aktywny.
  • Dotyczy implementacji urządzeń Android TV, nawet w trybie gotowości.
• [C-1-5] NIE MOŻE traktować wywołania metody interfejsu API WifiManager.enableNetwork() jako wystarczającego wskaźnika do zmiany obecnie aktywnej usługi Network, która jest używana domyślnie do obsługi ruchu w aplikacji i jest zwracana przez metody ConnectivityManager, takie jak getActiveNetwork i registerDefaultNetworkCallback. Oznacza to, że MOGĄ wyłączyć dostęp do internetu zapewniany przez innego dostawcę (np. sieć komórkową) tylko wtedy, gdy ustalą, że sieć Wi-Fi zapewnia dostęp do internetu.
• [C-1-6] SĄ ZALECANE, gdy po wywołaniu metody interfejsu API ConnectivityManager.reportNetworkConnectivity() należy ponownie ocenić dostęp do internetu w Network, a po upewnieniu się, że bieżący Network nie zapewnia już dostępu do internetu, przełącz się na inną dostępną sieć (np. mobilną transmisję danych), która zapewnia dostęp do internetu.
• [C-1-7] MUSI randomizować źródłowy adres MAC i numer sekwencyjny ramek żądań sond, jeden raz na początku każdego skanowania, gdy STA jest odłączony.
• [C-1-8] MUSI używać 1 spójnego adresu MAC (NIE POWINNO wybierać losowego adresu MAC w trakcie skanowania).
• [C-1-9] MUSI powtarzać numer sekwencyjny żądania sondowania w zwykły sposób (sekwencyjnie) między żądaniami sondowania podczas skanowania.
• [C-1-10] MUSI randomizować numer sekwencyjny żądania sondowania między ostatnim żądaniem sondowania w ramach skanowania a pierwszym żądaniem sondowania w kolejnym skanowaniu.
• [C-SR-1] Zdecydowanie ZALECANE jest użycie losowego adresu MAC używanego na potrzeby całej komunikacji STA z punktem dostępu (AP) w trakcie wiązania i powiązywania danych.
  • Urządzenie MUSI używać innego randomizowanego adresu MAC w przypadku każdego identyfikatora SSID (FQDN w przypadku protokołu Passpoint), z którym się komunikuje.
  • Urządzenie MUSI udostępniać użytkownikowi opcję sterowania randomizacją według identyfikatora SSID (FQDN w przypadku Passpoint) przy użyciu opcji nielosowych i losowych oraz MUSI ustawić tryb domyślny dla nowych konfiguracji Wi-Fi.
• [C-SR-2] Zdecydowanie ZALECANE jest użycie losowego identyfikatora BSSID dla każdego tworzonego przez nich punktu dostępu.
  • Adres MAC MUSI być randomizowany i utrwalany zgodnie z identyfikatorem SSID używanym przez punkt dostępu.
  • URZĄDZENIE MOŻE dać użytkownikowi możliwość wyłączenia tej funkcji. Jeśli taka opcja jest dostępna, randomizacja MUSI być domyślnie włączona.

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

• Tryb oszczędzania energii Wi-Fi należy wyłączać za każdym razem, 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(), gdy blokada jest aktywna.
• [C-3-2] Średni czas oczekiwania w obie strony między urządzeniem a punktem dostępu, gdy urządzenie jest w trybie blokady Wi-Fi (WIFI_MODE_FULL_LOW_LATENCY) MUSI być mniejsze niż opóźnienie w trybie blokady Wi-Fi o wysokiej wydajności (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] Zdecydowanie ZALECANE jest ograniczenie czasu oczekiwania w obie strony w pobliżu sieci Wi-Fi po wykryciu i zastosowaniu blokad o krótkim czasie oczekiwania (WIFI_MODE_FULL_LOW_LATENCY).

Jeśli urządzenia obsługują Wi-Fi i używają Wi-Fi do skanowania lokalizacji, :

• [C-2-1] MUSI udostępniać liczbę użytkowników, aby włączyć lub wyłączyć wartość odczytywaną za pomocą metody interfejsu API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementacje na urządzeniach:

• POWINNA obsługiwać technologię Wi-Fi Direct (typu Wi-Fi peer-to-peer).

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

• [C-1-1] MUSI wdrożyć odpowiedni interfejs API Androida zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] MUSI zgłosić funkcję sprzętową android.hardware.wifi.direct.
• [C-1-3] MUSI obsługiwać normalne działanie Wi-Fi.
• [C-1-4] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Direct.
• [C-SR-1] Zdecydowanie ZALECANE jest użycie losowego adresu MAC w przypadku wszystkich nowo utworzonych połączeń Wi-Fi Direct.

7.4.2.2. Konfiguracja bezpośredniego linku Wi-Fi

Implementacje na urządzeniach:

• POWINNO_obsługiwać obsługę konfiguracji bezpośredniego linku Wi-Fi (TDLS) zgodnie z opisem w dokumentacji pakietu Android SDK.

Jeśli implementacje urządzeń obejmują obsługę TDLS i TDLS włączone przez interfejs WiFiManager API:

• [C-1-1] MUSI zadeklarować obsługę TDLS do WifiManager.isTdlsSupported.
• Narzędzia TDLS należy używać tylko wtedy, gdy jest to możliwe i korzystne.
• POWINNY jest działać mechanizm heurystyczny i NIE używać TDLS, gdy jego wydajność może być gorsza niż przez punkt dostępu Wi-Fi.

7.4.2.3 Rozpoznawalność Wi-Fi

Implementacje na urządzeniach:

• POWINNO_obsługiwać funkcję Wi-Fi Aware.

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

• [C-1-1] MUSI zaimplementować interfejsy API WifiAwareManager w sposób opisany w dokumentacji pakietu SDK.
• [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.aware.
• [C-1-3] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Aware.
• [C-1-4] MUSI randomizować adres interfejsu zarządzania Wi-Fi Aware w odstępach nie dłuższych niż 30 minut i zawsze wtedy, gdy jest włączona usługa Wi-Fi Aware, chyba że trwa operacja Aware Aware lub ścieżka danych Aware jest aktywna (randomizacja nie jest możliwa, 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 artykule 7.4.2.5 oraz są one dostępne dla aplikacji innych firm, wtedy:

• [C-2-1] MUSI wdrożyć interfejsy API do wykrywania z uwzględnieniem lokalizacji: setRangingEnabled, setMinOdległośćMm, setMaxOdległośćMm i onServiceDiscoveredWithinRange.

7.4.2.4. Punkt dostępu Wi-Fi

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

• [C-1-1] MUSI obsługiwać punkt dostępu Wi-Fi.
• [C-1-2] MUSI zaimplementować interfejsy API WifiManager związane z Passpoint w sposób opisany w dokumentacji pakietu SDK.
• [C-1-3] MUSI obsługiwać standard IEEE 802.11u, zwłaszcza związany z wykrywaniem i wyborem sieci, takim jak usługi GAS i Access Network Query Protocol (ANQP).
• [C-1-4] MUSI zadeklarować flagę funkcji android.hardware.wifi.passpoint.
• [C-1-5] MUSI korzystać z implementacji AOSP, aby wykrywać sieci Passpoint, dopasowywać je i powiązywać z nimi.
• [C-1-6] MUSI obsługiwać co najmniej ten podzbiór protokołów obsługi administracyjnej urządzeń określony w specyfikacji Wi-Fi Alliance Passpoint R2: uwierzytelnianie EAP-TTLS i SOAP-XML.
• [C-1-7] MUSI przetworzyć certyfikat serwera AAA zgodnie ze specyfikacją Hotspot 2.0 R3.
• [C-1-8] MUSI zapewniać użytkownikowi kontrolę nad obsługą administracyjną za pomocą selektora Wi-Fi.
• [C-1-9] MUSI utrzymywać konfiguracje Passpoint przez cały czas po ponownym uruchomieniu.
• [C-SR-1] Zdecydowanie zalecamy obsługę funkcji akceptacji Warunków korzystania z usługi.
• [C-SR-2] Zdecydowanie ZALECANE jest obsługa funkcji informacji o obiekcie.

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

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

Jeśli podany jest globalny przełącznik kontroli użytkownika w trybie Passpoint, implementacje:

• [C-3-1] Domyślnie MUSI włączać Passpoint.

7.4.2.5. Lokalizacja Wi-Fi (czas w obie strony przez Wi-Fi – RTT)

Implementacje na urządzeniach:

• POWINNO_obsługiwać lokalizację przez Wi-Fi.

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

• [C-1-1] MUSI zaimplementować interfejsy API WifiRttManager w sposób opisany w dokumentacji pakietu SDK.
• [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.rtt.
• [C-1-3] MUSI randomizować źródłowy adres MAC w przypadku każdej serii RTT, która jest wykonywana, podczas gdy interfejs Wi-Fi, za pomocą którego jest wykonywany RTT, nie jest powiązany z punktem dostępu.
• [C-1-4] MUSI mieć dokładność z dokładnością do 2 metrów przy przepustowości 80 MHz w 68 centylu (zgodnie z funkcją dystrybucji skumulowanej).

7.4.2.6 Odciążanie Wi-Fi

Implementacje na urządzeniach:

• POWINNO_obsługiwać odciążanie Wi-Fi.

Jeśli implementacje urządzeń obejmują obsługę odciążania Wi-Fi i udostępniają tę funkcję aplikacjom innych firm:

• [C-1-1] MUSI obsługiwać interfejs SocketKeepAlive API.

• [C-1-2] MUSI obsługiwać co najmniej 3 przedziały utrzymywania aktywności przez Wi-Fi i co najmniej 1 przedział utrzymywania aktywności przez sieć komórkową.

Jeśli implementacje urządzeń nie obsługują odciążania Wi-Fi, wykonaj te czynności:

• [C-2-1] MUSI zwrócić ERROR_UNSUPPORTED.

7.4.2.7. Łatwe połączenie Wi-Fi (protokół obsługi administracyjnej urządzeń)

Implementacje na urządzeniach:

• POWINNO_obsługiwać Wi-Fi Easy Connect (DPP).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Easy Connect i udostępnienie tej funkcji aplikacjom innych firm:

• [C-1-1] MUSI zwracać metodę WifiManager#isEasyConnectSupported(). true

7.4.2.8 Weryfikacja certyfikatu serwera Wi-Fi dla firm

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

• [C-SR-1] Zdecydowanie ZALECANE jest nieudostępnianie użytkownikowi opcji ręcznego dodawania firmowej sieci Wi-Fi w aplikacji Ustawienia.

7.4.3 Bluetooth

Jeśli implementacje urządzenia obsługują profil audio Bluetooth:

• MUSI obsługiwać zaawansowane kodeki audio i kodeki audio Bluetooth (np. LDAC).

Jeśli implementacje urządzeń obsługują HFP, A2DP i AVRCP:

• POWINNA OBSŁUGIWAĆ co najmniej 5 połączonych urządzeń.

Jeśli implementacje urządzenia zadeklarują funkcję android.hardware.vr.high_performance:

• [C-1-1] MUSI obsługiwać rozszerzenie Bluetooth 4.2 i Bluetooth LE.

Android obsługuje Bluetooth i Bluetooth Low Energy.

Jeśli implementacje urządzeń obejmują obsługę Bluetootha i Bluetooth Low Energy, funkcje te:

• [C-2-1] MUSI zadeklarować odpowiednie funkcje platformy (odpowiednio android.hardware.bluetooth i android.hardware.bluetooth_le) i wdrożyć interfejsy API platformy.
• NALEŻY zaimplementować 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), te funkcje:

• [C-3-1] MUSI zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
• [C-3-2] MUSI włączać oparte na interfejsie API Bluetooth GATT (ogólny profil atrybutów) w sposób opisany w dokumentacji pakietu SDK i w android.bluetooth.
• [C-3-3] MUSI zgłosić prawidłową wartość parametru BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy logika filtrowania klas interfejsu ScanFilter została zaimplementowana.
• [C-3-4] MUSI podawać prawidłową wartość BluetoothAdapter.isMultipleAdvertisementSupported(), aby wskazać, czy reklamy Low Energy Advertising są obsługiwane.
• [C-3-5] MUSI wdrożyć czas oczekiwania na rozpoznawany adres prywatny (RPA) nie dłuższy niż 15 minut i przeprowadzać rotację adresu po przekroczeniu limitu czasu, aby chronić prywatność użytkownika, gdy urządzenie aktywnie używa BLE do skanowania lub wyświetlania reklam. Aby zapobiec atakom czasowym, odstępy czasu oczekiwania MUSZĄ też być losowe z zakresu 5–15 minut.
• POWINNO obsługiwać przenoszenie logiki filtrowania na chipset Bluetooth podczas wdrażania interfejsu ScanFilter API.
• POWINNO obsługiwać pobieranie skanowania zbiorczego do chipsetu Bluetooth.
• POWINNA obsługiwać wiele reklam z co najmniej 4 boksami.

Jeśli implementacje urządzeń obsługują Bluetooth LE i używają Bluetooth LE do skanowania lokalizacji, to:

• [C-4-1] MUSI udostępniać liczbę użytkowników, aby włączyć lub wyłączyć wartość odczytywaną przez interfejs API systemu BluetoothAdapter.isBleScanAlwaysAvailable().

Jeśli implementacje urządzeń obejmują obsługę Bluetooth LE i profilu aparatów słuchowych, zgodnie z opisem w sekcji Obsługa dźwięku w aparacie słuchowym przez Bluetooth LE:

• [C-5-1] MUSI zwracać wartość true w przypadku parametru BluetoothAdapter.getProfileProxy(context, detektor, BluetoothProfile.HEARING_AID).

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

• [C-6-1] MUSI ograniczać dostęp do metadanych Bluetooth (takich jak wyniki skanowania), które mogą zostać użyte do określenia lokalizacji urządzenia, chyba że aplikacja żądająca przejścia przejdzie kontrolę uprawnień android.permission.ACCESS_FINE_LOCATION na podstawie jej bieżącego stanu na pierwszym planie/w tle.

Jeśli implementacje urządzeń obejmują obsługę Bluetootha lub Bluetooth Low Energy, a manifest aplikacji nie zawiera deklaracji dewelopera stwierdzającej, że urządzenia nie korzystają z Bluetootha, wtedy:

• [C-6-2] MUSI blokować dostęp do Bluetootha za urządzeniem android.permission.ACCESS_FINE_LOCATION.

7.4.4 Komunikacja Near Field Communication

Implementacje na urządzeniach:

• POWINIEN zawierać odbiornik oraz odpowiedni sprzęt do komunikacji Near-Field Communication (NFC).
• [C-0-1] MUSI zaimplementować interfejsy API android.nfc.NdefMessage i android.nfc.NdefRecord, nawet jeśli nie obsługują NFC lub zadeklaruje funkcję android.hardware.nfc, ponieważ klasy przedstawiają format danych niezależny od protokołu.

Jeśli implementacje urządzeń obejmują sprzęt do NFC i planują udostępnić tę funkcję aplikacjom innych firm:

• [C-1-1] MUSI zgłosić funkcję android.hardware.nfc za pomocą metody android.content.pm.PackageManager.hasSystemFeature().
• MUSI być w stanie odczytywać i zapisywać wiadomości NDEF z użyciem następujących standardów NFC, jak poniżej:
• [C-1-2] MUSI działać jako czytnik/zapisujący forum NFC (zgodnie z definicją w specyfikacji technicznej NFC Forum NFCForum-TS-DigitalProtocol-1.0) zgodnie z następującymi standardami NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Typy tagów forum NFC 1, 2, 3, 4, 5 (zdefiniowane przez Forum NFC)

• [C-SR-1] Zdecydowanie zalecana jest możliwość odczytywania i zapisywania wiadomości NDEF, a także nieprzetworzonych danych przy użyciu poniższych standardów NFC. Chociaż standardy NFC są określone jako Zdecydowanie ZALECANE, w przyszłości planujemy zmienić definicję zgodności w przyszłości na TRZEBA. Standardy te są w tej wersji opcjonalne, ale będą wymagane w kolejnych. Zdecydowanie zalecamy spełnianie tych wymagań już teraz i na nowych urządzeniach, na których działa ta wersja Androida, aby umożliwić ich uaktualnienie do przyszłych wersji platformy.

• [C-1-13] W trybie wykrywania NFC MUSI przeprowadzać ankiety w poszukiwaniu wszystkich obsługiwanych technologii.

• POWINNY być w trybie wykrywania NFC, gdy urządzenie jest wybudzone, a ekran jest aktywny, a ekran blokady jest odblokowany.

• MUSI być w stanie odczytać kod kreskowy i adres URL (jeśli jest zakodowany) kodu kreskowego Thinfilm NFC.

Pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku wymienionych powyżej specyfikacji JIS, ISO i NFC.

Android obsługuje tryb HCE (NFC).

Jeśli implementacje urządzeń obejmują chipset kontrolera NFC obsługujący HCE (NfcA lub NfcB) i obsługują routing na podstawie identyfikatora aplikacji (AID), spełniają one te wymagania:

• [C-2-1] MUSI zgłaszać stałą funkcję android.hardware.nfc.hce.
• [C-2-2] MUSI obsługiwać interfejsy NFC HCE API zgodnie z definicją w pakiecie Android SDK.

Jeśli używane urządzenia korzystają z chipsetu kontrolera NFC obsługującego HCE for NfcF i wdrożą tę funkcję na potrzeby aplikacji innych firm:

• [C-3-1] MUSI zgłaszać stałą funkcję android.hardware.nfc.hcef.
• [C-3-2] MUSI wdrożyć interfejsy API karty NfcF Card Emulation zdefiniowane w pakiecie Android SDK.

Jeśli implementacje urządzeń obejmują ogólną obsługę NFC, jak opisano w tej sekcji, oraz technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF w MIFARE Classic) w roli odczytującego/zapisującego, użytkownicy:

• [C-4-1] MUSI wdrożyć odpowiednie interfejsy API Androida w sposób opisany w pakiecie SDK do Androida.
• [C-4-2] MUSI zgłosić funkcję com.nxp.mifare za pomocą metody android.content.pm.PackageManager.hasSystemFeature(). Pamiętaj, że nie jest to standardowa funkcja Androida, dlatego nie jest wyświetlana jako stała w klasie android.content.pm.PackageManager.

7.4.5 Protokoły sieciowe i interfejsy API

7.4.5.1 Minimalne możliwości sieci

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać co najmniej jedną formę sieci danych. Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden standard danych o szybkości co najmniej 200 kb/s. Przykłady technologii, które spełniają to wymaganie, to EDGE, HSPA, EV-DO, 802.11g, Ethernet i Bluetooth PAN.
• POWINNA też obsługiwać co najmniej jeden popularny standard bezprzewodowych danych, taki jak 802.11 (Wi-Fi), gdy podstawowym połączeniem transmisji danych jest fizyczny standard sieci (np. Ethernet).
• MOŻESZ wdrożyć więcej niż jedną formę połączeń danych.

7.4.5.2 IPv6

Implementacje na urządzeniach:

• [C-0-2] MUSI zawierać stos sieci 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_INET6gniazda.
• [C-0-3] MUSI domyślnie włączać IPv6.
  • MUSI mieć pewność, że komunikacja IPv6 będzie równie niezawodna jak IPv4. Na przykład:
    • [C-0-4] MUSI utrzymywać połączenia IPv6 w trybie uśpienia.
    • [C-0-5] Ograniczenie szybkości NIE MOŻE spowodować utraty połączenia IPv6 w żadnej sieci zgodnej z IPv6, w której czas trwania RA wynosi co najmniej 180 sekund.
• [C-0-6] MUSI zapewniać zewnętrzne aplikacje korzystające z bezpośredniego połączenia IPv6 z siecią przy połączeniu z siecią IPv6, bez żadnej translacji adresów lub portów odbywającej się lokalnie na urządzeniu. Zarówno zarządzane interfejsy API, takie jak Socket#getLocalAddress lub Socket#getLocalPort), jak i interfejsy API NDK, takie jak getsockname() lub IPV6_PKTINFO, MUSZĄ zwracać adres IP i port, które są rzeczywiście używane do wysyłania i odbierania pakietów w sieci i są widoczne jako źródłowy adres IP oraz port do serwerów internetowych (internetowych).

Wymagany poziom obsługi IPv6 zależy od typu sieci, jak pokazano w poniższych wymaganiach.

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

• [C-1-1] MUSI obsługiwać operacje na stosie podwójnym i tylko IPv6 w Wi-Fi.

Jeśli implementacje urządzeń obsługują protokół Ethernet:

• [C-2-1] MUSI obsługiwać operacje na stosie podwójnym i tylko IPv6 w sieci Ethernet.

Jeśli implementacje urządzeń obsługują komórkową transmisję danych:

• [C-3-1] MUSI obsługiwać operację IPv6 (tylko w przypadku protokołu IPv6 i ewentualnie stos podwójny) w sieci komórkowej.

Jeśli implementacje urządzeń obsługują więcej niż 1 typ sieci (np. Wi-Fi i komórkowa transmisja danych):

• [C-4-1] MUSI jednocześnie spełniać powyższe wymagania w każdej sieci, gdy urządzenie jest jednocześnie połączone z więcej niż jednym typem sieci.

7.4.5.3 Portale przechwytujące

Portal dostępowy to sieć, która wymaga zalogowania się, by uzyskać dostęp do internetu.

Jeśli implementacje na urządzeniach zapewniają pełną implementację android.webkit.Webview API:

• [C-1-1] MUSI udostępnić aplikację portalu przechwytującego do obsługi intencji ACTION_CAPTIVE_PORTAL_SIGN_IN i wyświetlania strony logowania do portalu przechwytującego, wysyłając tę intencję do interfejsu System API ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] MUSI wykrywać portale przechwytujące i umożliwiać logowanie się przez aplikację portalu przechwytującego, gdy urządzenie jest podłączone do sieci dowolnego typu, w tym sieci komórkowej/komórkowej, Wi-Fi, Ethernetu lub Bluetooth.
• [C-1-3] MUSI obsługiwać logowanie się do portali przechwytujących z użyciem jawnego tekstu DNS, gdy urządzenie jest skonfigurowane do korzystania z prywatnego trybu ścisłego DNS.
• [C-1-4] MUSI używać zaszyfrowanego DNS zgodnie z dokumentacją pakietu SDK dotyczącą android.net.LinkProperties.getPrivateDnsServerName i android.net.LinkProperties.isPrivateDnsActive w przypadku całego ruchu w sieci, który nie komunikuje się bezpośrednio z portalem przechwytującym.
• [C-1-5] MUSI mieć pewność, że podczas logowania się użytkownika w portalu przechwytującym domyślna sieć używana przez aplikacje (wyświetlana przez ConnectivityManager.getActiveNetwork i ConnectivityManager.registerDefaultNetworkCallback i używana domyślnie przez interfejsy sieciowe Java, np. java.net.Socket) oraz natywne interfejsy API, np. Connect()), która zapewnia dostęp do internetu, jeśli jest dostępna.

7.4.6 Ustawienia synchronizacji

Implementacje na urządzeniach:

• [C-0-1] MUSI mieć domyślnie włączone ustawienie automatycznej synchronizacji głównej, aby metoda getMasterSyncAutomatically() zwracała wartość „true”.

7.4.7 Oszczędzanie danych

Jeśli implementacje urządzeń obejmują połączenie z pomiarem, będą to:

• [C-SR-1] Zdecydowanie ZALECANE jest włączenie trybu oszczędzania danych.

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

• [C-1-1] MUSI obsługiwać wszystkie interfejsy API w klasie ConnectivityManager zgodnie z opisem w dokumentacji pakietu SDK

Jeśli implementacje urządzeń nie obsługują trybu oszczędzania danych:

• [C-2-1] MUSI zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED dla ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NIE MOŻE rozgłaszać ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8 Zabezpieczone elementy

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

• [C-1-1] MUSI wyliczać dostępne czytniki elementów zabezpieczonych za pomocą interfejsu API android.se.omapi.SEService.getReaders().

• [C-1-2] MUSI zadeklarować prawidłowe flagi funkcji za pomocą android.hardware.se.omapi.uicc w przypadku urządzenia z elementami zabezpieczonymi opartymi na UICC, android.hardware.se.omapi.ese w przypadku urządzenia z elementami zabezpieczonymi opartymi na eSE i android.hardware.se.omapi.sd dla urządzenia z elementami zabezpieczonymi opartymi na SD.

7.5 kamery,

Jeśli implementacje urządzeń obejmują co najmniej jedną kamerę:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.camera.any.
• [C-1-2] Aplikacja musi mieć możliwość jednoczesnego przydzielania 3 map bitowych RGBA_8888 odpowiadających rozmiarowi obrazu generowanego przez czujnik aparatu o największej rozdzielczości w urządzeniu, a aparat jest otwarty na potrzeby podstawowego podglądu i rejestrowania.
• [C-1-3] MUSI upewnić się, że domyślnie zainstalowana domyślna aplikacja aparatu obsługująca intencje MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE lub MediaStore.ACTION_VIDEO_CAPTURE jest odpowiedzialna za usunięcie lokalizacji użytkownika z metadanych obrazu przed wysłaniem go do aplikacji odbierającej, gdy aplikacja odbierająca nie ma ACCESS_FINE_LOCATION.

7.5.1 Kamera tylna

Tylny aparat to kamera znajdująca się z boku urządzenia naprzeciw wyświetlacza. Oznacza to, że obrazuje sceny z daleka, tak jak tradycyjny aparat.

Implementacje na urządzeniach:

• POWINIEN zawierać tylny aparat.

Jeśli urządzenia mają co najmniej 1 tylny aparat:

• [C-1-1] MUSI zgłosić flagę funkcji android.hardware.camera i android.hardware.camera.any.
• [C-1-2] MUSI mieć rozdzielczość co najmniej 2 megapiksele.
• W sterowniku aparatu musi być zaimplementowany sprzętowy autofokus lub programowy autofokus (przezroczysty dla oprogramowania).
• MOŻE mieć sprzęt o stałej ostrości lub EDOF (rozszerzona głębia ostrości).
• MOŻE zawierać obiekty flash.

Jeśli aparat ma lampę błyskową:

• [C-2-1] Lampa błyskowa NIE MOŻE się świecić, gdy na platformie podglądu aparatu zostało zarejestrowane wystąpienie android.hardware.Camera.PreviewCallback, chyba że aplikacja wyraźnie włączyła lampę błyskową przez włączenie atrybutów FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu na urządzeniu, a jedynie aplikacji innych firm korzystających z funkcji Camera.PreviewCallback.

7.5.2 Przedni aparat

Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz. To kamera zwykle używana do nagrywania obrazu użytkownika, na przykład do rozmów wideo i w podobnych aplikacjach.

Implementacje na urządzeniach:

• MOŻE zawierać przedni aparat.

Jeśli implementacje urządzeń obejmują co najmniej jeden przedni aparat:

• [C-1-1] MUSI zgłosić flagę funkcji android.hardware.camera.any i android.hardware.camera.front.
• [C-1-2] MUSI mieć rozdzielczość co najmniej VGA (640 x 480 pikseli).
• [C-1-3] NIE MOŻE używać przedniego aparatu jako domyślnego dla interfejsu Camera API i NIE MOŻE konfigurować interfejsu API w taki sposób, aby traktował przedni aparat jako domyślny, nawet jeśli jest to jedyna kamera w urządzeniu.
• [C-1-4] Podgląd z kamery MUSI być odbicie lustrzane w poziomie względem orientacji określonej przez aplikację, gdy bieżąca aplikacja wyraźnie zażąda obracania wyświetlacza kamery przez wywołanie metody android.hardware.Camera.setDisplayOrientation(). I odwrotnie, gdy bieżąca aplikacja nie zażąda w sposób wyraźny obrócenia ekranu kamery przez wywołanie metody android.hardware.Camera.setDisplayOrientation(), podgląd MUSI być zduplikowany wzdłuż domyślnej osi poziomej urządzenia.
• [C-1-5] NIE MOŻE odzwierciedlić ostatecznej wersji zarejestrowanych obrazów ani strumieni wideo zwracanych do wywołań zwrotnych aplikacji lub zadeklarowanych do przechowywania multimediów.
• [C-1-6] MUSI odbić obraz wyświetlany po wyświetleniu w taki sam sposób, jak w strumieniu obrazu z aparatu.
• MOŻE obejmować funkcje (takie jak autofokus, lampa błyskowa itp.) dostępne w przypadku tylnych aparatów zgodnie z opisem w sekcji 7.5.1.

Jeśli implementacje urzą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 z aparatu MUSI być odbicie lustrzane w poziomie względem bieżącej orientacji urządzenia.

7.5.3 Kamera zewnętrzna

Implementacje na urządzeniach:

• MOŻESZ obsługiwać kamerę zewnętrzną, która nie musi być zawsze podłączona.

Jeśli implementacje urządzeń obejmują obsługę aparatu zewnętrznego:

• [C-1-1] MUSI zadeklarować flagę funkcji platformy android.hardware.camera.external i android.hardware camera.any.
• [C-1-2] MUSI obsługiwać standard wideo USB (UVC 1.0 lub nowszy), jeśli zewnętrzny aparat jest podłączony przez port hosta USB.
• [C-1-3] MUSI przejść testy CTS kamery z podłączonym fizycznym aparatem zewnętrznym. Szczegółowe informacje o testowaniu CTS aparatu znajdziesz na stronie source.android.com.
• POWINNA obsługiwać kompresję wideo, taką jak MJPEG, by umożliwić przesyłanie niezakodowanych strumieni w wysokiej jakości (tj. nieprzetworzonych lub niezależnie skompresowanych strumieni obrazu).
• MOŻE obsługiwać wiele aparatów.
• MOŻE obsługiwać kodowanie wideo z użyciem kamery.

Jeśli obsługiwane jest kodowanie przy użyciu kamery:

• [C-2-1] Jednoczesny niezakodowany strumień / MJPEG (o rozdzielczości QVGA lub wyższej) MUSI być dostępny dla implementacji urządzenia.

7.5.4 Działanie interfejsu Camera API

Android zawiera 2 pakiety interfejsów API dostępu do aparatu. Nowszy interfejs android.hardware.camera2 API zapewnia aplikacji niższy poziom kontroli nad kamerą, w tym wydajne serie bez żadnej kopii i strumieniowanie w przypadku poszczególnych klatek oraz ustawienia ekspozycji, wzmocnienia, wzmocnienia bieli, konwersji kolorów, odszumiania, wyostrzania i nie tylko.

Starszy pakiet interfejsów API (android.hardware.Camera) jest oznaczony jako wycofany w Androidzie 5.0, ale nadal powinien być dostępny dla aplikacji. Implementacje na urządzeniach z Androidem MUSZĄ zapewnić nieprzerwaną obsługę interfejsu API w sposób opisany w tej sekcji oraz w pakiecie SDK Androida.

Wszystkie funkcje typowe dla wycofanej klasy android.hardware.Camera i nowszym pakietem android.hardware.camera2 MUSZĄ mieć taką samą wydajność i jakość w obu interfejsach API. Na przykład przy równoważnych ustawieniach szybkość i dokładność autofokusa muszą być takie same, a jakość zrobionych zdjęć musi być taka sama. Funkcje, które zależą od semantyki obu interfejsów API, nie muszą do siebie pasować pod względem 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 aparatem w przypadku wszystkich dostępnych kamer. Implementacje na urządzeniach:

• [C-0-1] MUSI używać android.hardware.PixelFormat.YCbCr_420_SP do obsługi danych podglądu przekazywanych do wywołań zwrotnych aplikacji, gdy aplikacja nigdy nie wywołała android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] MUSI dodatkowo mieć format kodowania NV21, gdy aplikacja rejestruje wystąpienie android.hardware.Camera.PreviewCallback, a system wywołuje metodę onPreviewFrame(), a format podglądu to YCbCr_420_SP, czyli dane w bajcie[] przekazywane do onPreviewFrame(). Oznacza to, że NV21 MUSI być wartością domyślną.
• [C-0-3] MUSI obsługiwać format YV12 (oznaczony stałą wartością android.graphics.ImageFormat.YV12) dla podglądów zarówno przednich, jak i tylnych aparatów android.hardware.Camera. (Sprzętowy koder wideo i kamera mogą używać dowolnego formatu piksela, ale implementacja urządzenia MUSI obsługiwać konwersję na format YV12).
• [C-0-4] MUSI obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe przez interfejs API android.media.ImageReader w przypadku urządzeń android.hardware.camera2, które reklamują funkcję REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE w android.request.availableCapabilities.
• [C-0-5] W dalszym ciągu MUSI wdrożyć pełny interfejs Camera API podany w dokumentacji pakietu Android SDK, niezależnie od tego, czy urządzenie jest wyposażone w sprzętowy autofokus czy inne funkcje. Na przykład kamery bez autofokusa MUSZĄ wywoływać dowolne zarejestrowane wystąpienia android.hardware.Camera.AutoFocusCallback (mimo że nie ma to znaczenia dla aparatu bez autofokusa). Pamiętaj, że dotyczy to przednich aparatów. Na przykład większość z nich nie obsługuje autofokusa, ale wywołania zwrotne interfejsu API muszą być „sfałszowane” zgodnie z opisem.
• [C-0-6] MUSI rozpoznawać i uwzględniać wszystkie nazwy parametrów zdefiniowane jako stałe w klasie android.hardware.Camera.Parameters i android.hardware.camera2.CaptureRequest. I odwrotnie, implementacje urządzeń NIE MOGĄ uznawać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters() innych niż te podane jako stałe w zasadzie 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 MOŻE obsługiwać niestandardowych typów parametrów aparatu. Na przykład urządzenia, które obsługują robienie zdjęć z użyciem technik obrazowania High Dynamic Range (HDR), MUSZĄ obsługiwać parametr aparatu Camera.SCENE_MODE_HDR.
• [C-0-7] MUSI zgłosić odpowiedni poziom pomocy za pomocą właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i zgłaszać odpowiednie flagi funkcji platformy.
• [C-0-8] MUSI też zadeklarować funkcje kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i zadeklarować odpowiednie flagi funkcji. Jeśli któreś z podłączonych do niej kamer ją obsługuje.
• [C-0-9] MUSI przesyłać zamiar Camera.ACTION_NEW_PICTURE za każdym razem, gdy aparat zrobi nowe zdjęcie i zostanie dodany do magazynu multimediów.
• [C-0-10] MUSI transmitować intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy kamera zarejestruje nowy film, a obraz został dodany do magazynu multimediów.
• [C-0-11] MUSI mieć wszystkie kamery dostępne za pomocą wycofanego interfejsu API android.hardware.Camera również z poziomu interfejsu API android.hardware.camera2.
• [C-0-12] MUSI dopilnować, aby NIE zmieniał wyglądu twarzy, w tym między innymi geometrii, odcienia skóry ani wygładzania skóry w przypadku dowolnego interfejsu API android.hardware.camera2 lub android.hardware.Camera.
• [C-SR-1] W przypadku urządzeń z wieloma kamerami RGB skierowanymi w tym samym kierunku Zdecydowanie ZALECANE jest korzystanie z aparatu logicznego, który zawiera listę możliwości CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, czyli wszystkie kamery RGB skierowane w tę samą stronę co fizyczne urządzenia podrzędne.

Jeśli implementacje urządzeń udostępniają zastrzeżony interfejs API aparatu aplikacjom innych firm, :

• [C-1-1] MUSI wdrożyć taki interfejs API aparatu za pomocą interfejsu API android.hardware.camera2.
• MOŻE udostępniać tagi lub rozszerzenia dostawcy do interfejsu API android.hardware.camera2.

7.5.5 Orientacja aparatu

Jeśli urządzenia mają aparat przedni lub tylny:

• [C-1-1] musi być zorientowany tak, by długi wymiar kamery był zgodny z długością ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparaty MUSZĄ robić zdjęcia w orientacji poziomej. Ma zastosowanie niezależnie od naturalnej orientacji urządzenia, tzn. zarówno w przypadku urządzeń poziomych, jak i pionowych.

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

• Urządzenie ma ekrany o zmiennej geometrii, np. ekrany składane lub zawiasowe.
• Gdy zmieni się stan złożenia lub zawiasu, urządzenie przełączy się między orientacją pionową, a poziomą i poziomą.

7.6 Pamięć i miejsce na dane

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

Implementacje na urządzeniach:

• [C-0-1] MUSI zawierać menedżera pobierania, za pomocą którego aplikacje MOGĄ pobierać pliki danych. Muszą mieć możliwość pobierania pojedynczych plików o rozmiarze co najmniej 100 MB do domyślnej lokalizacji w „pamięci podręcznej”.

7.6.2 Pamięć współdzielona aplikacji

Implementacje na urządzeniach:

• [C-0-1] MUSI udostępniać miejsce na dane, które może być współużytkowane przez aplikacje. Często nazywane jest też „wspólną pamięcią zewnętrzną”, „pamięcią współdzieloną aplikacji” lub ścieżką systemu Linux „/sdcard”, w której jest podłączona.
• [C-0-2] MUSI być skonfigurowana z domyślnie instalowaną pamięcią współdzieloną (np. „już po wyjęciu z pudełka”), niezależnie od tego, czy pamięć masowa znajduje się w pamięci wewnętrznej, czy na wymiennym nośniku pamięci (np. w pamięci cyfrowej).
• [C-0-3] MUSI podłączyć pamięć współdzieloną aplikacji bezpośrednio w ścieżce Linuksa sdcard lub dołączyć łącze symboliczne Linuksa z sdcard do rzeczywistego punktu podłączania.
• [C-0-4] MUSI domyślnie włączać zakres miejsca na dane we wszystkich aplikacjach kierowanych na interfejs API na poziomie 29 lub wyższym, z wyjątkiem tych sytuacji:
  • Gdy aplikacja zażądał elementu android:requestLegacyExternalStorage="true" w pliku manifestu.
• [C-0-5] MUSI usuwać metadane lokalizacji, takie jak tagi GPS Exif, przechowywane w plikach multimedialnych, gdy uzyskuje się do nich dostęp przez MediaStore, chyba że aplikacja wywołująca ma uprawnienie ACCESS_MEDIA_LOCATION.

Implementacje na urządzeniach MOGĄ spełniać powyższe wymagania, jeśli:

• Pamięć wymienna dostępna dla użytkowników, np. gniazdo kart Secure Digital (SD).
• Część pamięci wewnętrznej (niewymiennej) wdrożona w ramach projektu Android Open Source Project (AOSP).

Jeśli implementacje urządzeń korzystają z pamięci wymiennej, aby spełnić powyższe wymagania:

• [C-1-1] MUSI zaimplementować tost lub wyskakujące okienko z ostrzeżeniem dla użytkownika, gdy w gnieździe nie ma nośnika pamięci.
• [C-1-2] MUSI zawierać nośnik pamięci w formacie FAT (np. kartę SD) lub informacje na pudełku i inne materiały dostępne w momencie zakupu, że należy je zakupić oddzielnie.

Jeśli implementacje urządzeń wykorzystują część pamięci niewymiennej w celu spełnienia powyższych wymagań:

• NALEŻY użyć implementacji AOSP współdzielonej pamięci wewnętrznej aplikacji.
• MOGĄ dzielić dostępne miejsce z prywatnymi danymi aplikacji.

Jeśli urządzenia są wyposażone w port USB z obsługą trybu urządzenia peryferyjnego USB, umożliwiają one:

• [C-3-1] MUSI zapewniać mechanizm dostępu do danych w pamięci współdzielonej z komputera hosta.
• Treści z obu ścieżek pamięci NALEŻY w przejrzysty sposób udostępniać za pomocą usługi skanera multimediów na Androidzie i android.provider.MediaStore.
• MOŻE korzystać z pamięci masowej USB, ale aby spełnić to wymaganie, WARTO używać protokołu Media Transfer Protocol.

Jeśli implementacje urządzeń mają port USB z trybem peryferyjnym USB i obsługują protokół Media Transfer Protocol, funkcje te:

• MUSI być zgodny z referencyjnym hostem MTP Androida i Android File Transfer.
• MUSISZ zgłosić klasę urządzenia USB 0x00.
• POWINIEN zgłosić nazwę interfejsu USB „MTP”.

7.6.3 Pamięć elastyczna

Jeśli z założenia mają być urządzenia mobilne (inaczej niż w przypadku telewizji), implementacje urządzeń są następujące:

• [C-SR-1] Zdecydowanie zaleca się wdrożenie pamięci adaptacyjnej w stabilnej lokalizacji długoterminowej, ponieważ przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

Jeśli port wymiennego urządzenia pamięci masowej znajduje się w stabilnej lokalizacji długoterminowej, na przykład w komorze na baterię lub w innej osłonie ochronnej, sposób implementacji urządzenia:

• [C-SR-2] Zdecydowanie zalecamy wdrożenie pamięci dostosowywanej.

7.7. USB

Jeśli urządzenia są wyposażone w port USB:

• POWINNA obsługiwać tryb urządzenia peryferyjnego USB i POWINNO obsługiwać tryb hosta USB.
• POWINIEN obsługiwać wyłączanie sygnałów danych przez USB.

7.7.1. Tryb urządzenia peryferyjnego USB

Jeśli używane urządzenia są wyposażone w port USB obsługujący tryb peryferyjny:

• [C-1-1] Port MUSI być podłączony do hosta USB ze standardowym portem USB typu A lub C.
• [C-1-2] MUSI zgłaszać prawidłową wartość iSerialNumber w deskryptorze urządzenia ze standardowym USB do android.os.Build.SERIAL.
• [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem oporu typu C i MUSZĄ wykrywać zmiany w reklamach, jeśli obsługują USB typu C.
• [C-SR-1] Port POWINIEN używać formatu micro-B, micro-AB lub USB typu C. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
• [C-SR-2] Port powinien znajdować się na spodzie urządzenia (zgodnie z naturalną orientacją) lub umożliwiać programowe obracanie ekranu we wszystkich aplikacjach (w tym na ekranie głównym), by ekran wyświetlał się poprawnie, gdy urządzenie jest zorientowane na port u dołu. ZALECANE JEST spełnienie tych wymagań w przypadku dotychczasowych i nowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
• [C-SR-3] POWINNO obsługiwać pobieranie prądu na poziomie 1,5 A podczas sygnalizowania HS i ruchu, zgodnie ze specyfikacją ładowania baterii USB w wersji 1.2. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
• [C-SR-4] Zdecydowanie zaleca się, aby nie obsługiwać zastrzeżonych metod ładowania, które modyfikują napięcie Vbus do wartości domyślnych lub zmieniają role ujścia/źródła w takiej sytuacji, co może powodować problemy ze współdziałaniem z ładowarkami lub urządzeniami, które obsługują standardowe metody przesyłania przez USB Power Delivery. Choć nazywa się to „ZDECYDOWANIE ZALECANE”, w przyszłych wersjach Androida możemy WYMAGAĆ wszystkie urządzenia typu C, które będą w pełni działać ze standardowymi ładowarkami typu C.
• [C-SR-5] Zdecydowanie zalecana jest obsługa Power Delivery w zakresie wymiany danych i zasilania, jeśli obsługuje ona tryby hosta USB typu C i USB typu C.
• POWINNA obsługiwać technologię Power Delivery w przypadku ładowania wysokiego napięcia oraz obsługa trybów alternatywnych, takich jak wyświetlacz na zewnątrz.
• NALEŻY zaimplementować interfejs API i specyfikację Android Open Accessory (AOA) w sposób opisany w dokumentacji pakietu Android SDK.

Jeśli urządzenia są wyposażone w port USB i zawierają specyfikację AOA:

• [C-2-1] MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.accessory.
• [C-2-2] Klasa pamięci masowej USB MUSI zawierać ciąg „android” na końcu opisu interfejsu iInterface pamięci masowej USB
• NIE NALEŻY implementować dźwięku AOAv2 udokumentowanego w dokumentacji protokołu Android Open Accessory Protocol 2.0. Audio AOAv2 zostało wycofane na Androidzie w wersji 8.0 (poziom interfejsu API 26).

7.7.2 Tryb hosta USB

Jeśli implementacje urządzeń są wyposażone w port USB obsługujący tryb hosta:

• [C-1-1] MUSI zaimplementować interfejs Android USB Host API w sposób opisany w pakiecie SDK na Androida i MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.host.
• [C-1-2] MUSI obsługiwać podłączenie standardowych urządzeń peryferyjnych USB. Oznacza to, że MUSI:
  • urządzenie musi mieć port USB typu C lub musi być wyposażony w kable umożliwiające podłączenie zastrzeżonego portu urządzenia do standardowego portu USB typu C (urządzenie USB typu C).
  • urządzenie musi mieć urządzenie typu A lub wyposażone w kable umożliwiające podłączenie odpowiedniego portu urządzenia do standardowego portu USB typu A;
  • Musisz mieć na urządzeniu port micro-AB, który POWINNY być w dostarczeniu z kablem pasującym do standardowego portu typu A.
• [C-1-3] NIE MOŻE być dostarczany z przejściówką konwertowaną z portów USB typu A lub micro-AB na porty typu C (gniazdo).
• [C-SR-1] Zdecydowanie ZALECANE jest wdrożenie klasy audio USB zgodnie z dokumentacją pakietu Android SDK.
• POWINNY jest obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta; reklamowanie prądu źródłowego o wartości co najmniej 1, 5 A zgodnie z opisem w sekcji Parametry zakończenia w wersji 1.2 specyfikacji kabla USB typu C i złącza w przypadku złączy USB typu C lub używanie złączy USB typu C lub używanie złącza ładowania USB typu C w specyfikacjach prądu wyjściowego micro(CDP); zakres prądu wyjściowego dla ładowarki micro USB.
• KONIECZNIE jest wdrożenie i obsługa standardów USB typu C.

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta oraz klasę audio USB, te funkcje:

• [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 wykorzystania USB HID i żądaniu użycia poleceń głosowych na stałe KeyEvent jak poniżej:
  • Identyfikator wykorzystania strony użycia (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Identyfikator wykorzystania strony wykorzystania (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • Identyfikator wykorzystania strony wykorzystania (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • Identyfikator wykorzystania strony użycia (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i platformę Storage Access Framework (SAF), takie funkcje:

• [C-3-1] MUSI rozpoznawać zdalnie połączone urządzenia MTP (Media Transfer Protocol) i udostępniać ich treści w intencjach ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT. .

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i USB typu C:

• [C-4-1] MUSI zaimplementować funkcję Dual Role Port zgodnie z definicją w specyfikacji USB typu C (sekcja 4.5.1.3.3).
• [C-SR-2] Zdecydowanie ZALECANY jest obsługa DisplayPort, obsługa USB SuperSzybkość danych i Zdecydowanie ZALECANA do obsługi funkcji Power Delivery w zakresie zamiany ról danych i zasilania.
• [C-SR-3] Zdecydowanie ZALECANY, aby NIE obsługiwać trybu akcesorium adaptera audio zgodnie z opisem w Załączniku A do wersji 1.2 dotyczącymi kabla USB typu C i złącza.
• NALEŻY zastosować model Try.*, który najlepiej pasuje do formatu urządzenia. Na przykład na urządzeniu przenośnym POWINNY jest zaimplementowanie modelu Try.SNK.

7.8 Dźwięk

7.8.1 Mikrofon

Jeśli implementacje urządzeń zawierają mikrofon:

• [C-1-1] MUSI zgłaszać stałą funkcję android.hardware.microphone.
• [C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku opisane w sekcji 5.4.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku opisane w sekcji 5.6.
• [C-SR-1] Zdecydowanie ZALECANE jest umożliwienie nagrywania w trybie zbliżonym do ultradźwięków zgodnie z opisem w sekcji 7.8.3.

Jeśli implementacje urządzenia pomijają mikrofon:

• [C-2-1] NIE MOŻE zgłaszać stałej funkcji android.hardware.microphone.
• [C-2-2] MUSI wdrożyć interfejs API do nagrywania dźwięku co najmniej w sposób niewymagający żadnych działań (zgodnie z sekcją 7).

7.8.2 Wyjście audio

Jeśli implementacje urządzeń obejmują głośnik lub port wyjściowy audio/multimedialny dla urządzenia peryferyjnego audio, takiego jak 4-kanałowe gniazdo słuchawek 3,5 mm lub port w trybie hosta USB obsługującym klasę audio USB, to umożliwiają:

• [C-1-1] MUSI zgłaszać stałą funkcję android.hardware.audio.output.
• [C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku opisane w sekcji 5.5.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku opisane w sekcji 5.6.
• [C-SR-1] Zdecydowanie zalecana jest obsługa odtwarzania w trybie zbliżonym do ultradźwięków, zgodnie z opisem w sekcji 7.8.3.

Jeśli urządzenia nie mają gniazda głośnika ani wyjścia audio:

• [C-2-1] NIE MOŻE zgłaszać funkcji android.hardware.audio.output.
• [C-2-2] MUSI wdrożyć interfejsy API związane z wyjściem audio przynajmniej w trybie bezobsługowym.

Na potrzeby tej sekcji „port wyjściowy” to fizyczny interfejs, taki jak gniazdo słuchawek 3, 5 mm, port HDMI lub port trybu hosta USB z klasą audio USB. Obsługa wyjścia audio przez protokoły radiowe, takie jak Bluetooth, Wi-Fi czy sieć komórkowa, nie obejmuje „portu wyjściowego”.

7.8.2.1 Analogowe porty audio

Aby były zgodne z zestawami słuchawkowymi i innymi akcesoriami audio przez wykorzystanie wtyczki audio 3,5 mm w całym ekosystemie Androida, jeśli implementacje urządzeń obejmują co najmniej 1 analogowy port audio, te urządzenia:

• [C-SR-1] Zdecydowanie ZALECANE jest użycie co najmniej jednego portu audio jako 4-kanałowego gniazda słuchawek 3,5 mm.

Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3, 5 mm:

• [C-1-1] MUSI obsługiwać odtwarzanie dźwięku w słuchawkach stereo i zestawach stereo z mikrofonem.
• [C-1-2] MUSI obsługiwać wtyczki audio TRRS w kolejności styków CTIA.
• [C-1-3] MUSI obsługiwać wykrywanie i mapowanie kodów klawiszy w następujących 3 zakresach równoważnej impedancji między mikrofonem a przewodnikami uziemiającymi we wtyczce audio:
  • Maks. 70 omów: KEYCODE_HEADSETHOOK
  • 210–290 omów: KEYCODE_VOLUME_UP
  • 360–680 omów: KEYCODE_VOLUME_DOWN
• [C-1-4] MUSI uruchamiać ACTION_HEADSET_PLUG po podłączeniu wtyczki, ale dopiero wtedy, gdy wszystkie kontakty podłączone do wtyczki dotykają odpowiednich segmentów gniazda.
• [C-1-5] MUSZĄ napędzać co najmniej 150 mV ± 10% napięcia wyjściowego na głośniku 32 om o impedancji 32 om.
• [C-1-6] MUSI mieć napięcie odchylenia mikrofonu w zakresie 1,8 V ~ 2,9 V.
• [C-1-7] MUSI wykryć i zmapować kod klucza dla poniższego zakresu równoważnej impedancji między mikrofonem a przewodami uziemiającymi na wtyczce audio:
  • 110–180 omów: KEYCODE_VOICE_ASSIST
• [C-SR-2] Zdecydowanie ZALECANE jest obsługa wtyczek audio w kolejności, w jakiej należy podłączyć wtyczkę OMTP.
• [C-SR-3] Zdecydowanie ZALECANY jest on do obsługi nagrywania dźwięku z zestawów słuchawkowych stereo z mikrofonem.

Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3,5 mm i obsługują mikrofon oraz transmitują android.intent.action.HEADSET_PLUG z mikrofonem o dodatkowej wartości ustawionej na 1:

• [C-2-1] MUSI obsługiwać wykrywanie mikrofonu na podłączonych akcesoriach audio.

7.8.2.2. Cyfrowe porty audio

Aby zachować zgodność z zestawami słuchawkowymi i innymi akcesoriami audio przez złącze USB-C i zaimplementować (klasę audio USB) w ekosystemie Androida, zgodnie ze specyfikacją zestawu słuchawkowego USB na Androida.

Wymagania związane z poszczególnymi urządzeniami znajdziesz w artykule 2.2.1.

7.8.3 Prawie ultradźwiękowy

Dźwięk Near ultradźwiękowy to pasmo 18,5–20 kHz.

Implementacje na urządzeniach:

• MUSI prawidłowo zgłaszać obsługę funkcji dźwięku bliskiego ultradźwięku za pomocą interfejsu API AudioManager.getproperty w ten sposób:

Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND ma wartość „prawda”, źródła dźwięku VOICE_RECOGNITION i UNPROCESSED MUSZĄ spełniać te wymagania:

• [C-1-1] Średnia moc mikrofonu mikrofonu w paśmie 18,5–20 kHz MUSI być niższa niż 15 dB poniżej odpowiedzi przy 2 kHz.
• [C-1-2] Stosunek nieważonego sygnału do szumu mikrofonu powyżej 18,5–20 kHz dla tonu 19 kHz przy -26 dBFS MUSI być nie mniejszy niż 50 dB.

Jeśli PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „prawda”:

• [C-2-1] Średnia odpowiedź głośnika w zakresie 18,5 kHz – 20 kHz MUSI być niższa niż 40 dB poniżej odpowiedzi przy 2 kHz.

7.8.4 Integralność sygnałów

Implementacje na urządzeniach:

• POWINIEN zapewnić bezproblemową ścieżkę sygnału audio dla strumieni wejściowych i wyjściowych w urządzeniach mobilnych, zgodnie z definicją „zero błędów” mierzoną podczas testu trwającego 1 minutę na ścieżkę. Przetestuj za pomocą „Automatyczny test błędu” OboeTester.

Do testu potrzebny jest klucz sprzętowy audio typu loopback, używany bezpośrednio z wtykiem 3,5 mm lub w połączeniu z przejściówką z USB-C na 3,5 mm. Wszystkie porty wyjściowe audio MUSZĄ zostać przetestowane.

OboeTester obsługuje obecnie ścieżki AAudio, dlatego musisz przetestować te kombinacje pod kątem błędów:

Tryb Perf	Udostępnianie	Częstotliwość próbkowania wyjściowego	Chans	Piosenki zewnętrzne
LOW_LATENCY	WYJĄTKOWA OFERTA	NIEOKREŚLONY	1	2
LOW_LATENCY	WYJĄTKOWA OFERTA	NIEOKREŚLONY	2	1
LOW_LATENCY	UDOSTĘPNIONY	NIEOKREŚLONY	1	2
LOW_LATENCY	UDOSTĘPNIONY	NIEOKREŚLONY	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ń MUSI spełniać kryteria współczynnika sygnału do szumu (SNR) i całkowite zniekształcenie harmoniczne (THD) dla sinusa 2000 Hz.

Przetwornik	THD	numer SNR
główny wbudowany głośnik, mierzony za pomocą zewnętrznego mikrofonu referencyjnego	< 3,0%	>= 50 dB
główny wbudowany mikrofon, mierzony za pomocą zewnętrznego głośnika referencyjnego	< 3,0%	>= 50 dB
wbudowane analogowe gniazda słuchawek 3,5 mm, przetestowane z użyciem przejściówki typu loopback	<1%	>= 60 dB
Ładowarki USB dostarczone z telefonem, przetestowane z użyciem przejściówki typu loopback	< 1%	>= 60 dB

7.9. Wirtualna rzeczywistość

Android zapewnia interfejsy API i infrastrukturę do tworzenia aplikacji do rzeczywistości wirtualnej, w tym wysokiej jakości rozwiązań do rzeczywistości wirtualnej. Implementacje na urządzeniach MUSZĄ poprawnie 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 obsługuje stereoskopowe renderowanie powiadomień i wyłącza komponenty interfejsu systemu lunetowego, gdy aplikacja VR skupia się na użytkowniku.

7.9.2. Tryb rzeczywistości wirtualnej – wysoka wydajność

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

• [C-1-1] MUSI mieć co najmniej 2 rdzenie fizyczne.
• [C-1-2] MUSI zadeklarować funkcję android.hardware.vr.high_performance.
• [C-1-3] MUSI obsługiwać tryb utrzymującej wydajność.
• [C-1-4] MUSI obsługiwać standard OpenGL ES 3.2.
• [C-1-5] MUSI obsługiwać wartość android.hardware.vulkan.level 0.
• MUSI obsługiwać system android.hardware.vulkan.level w wersji 1 lub nowszej.
• [C-1-6] MUSI zaimplementować EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace, i udostępnić rozszerzenia na liście.
• [C-1-8] MUSI zaimplementować GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures i udostępnić rozszerzenia na liście dostępnych rozszerzeń GL.
• [C-SR-1] Zdecydowanie ZALECANE jest wdrożenie GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture i udostępnienie rozszerzeń na liście dostępnych rozszerzeń GL.
• [C-SR-2] Zdecydowanie ZALECANE są obsługa Vulkana 1.1.
• [C-SR-3] Zdecydowanie ZALECANE jest wdrożenie rozwiązań VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image i umieszczenie ich na liście dostępnych rozszerzeń Vulkan.
• [C-SR-4] Zdecydowanie ZALECANE jest udostępnienie co najmniej 1 rodziny kolejek Vulkan, w której flags zawierają zarówno VK_QUEUE_GRAPHICS_BIT, jak i VK_QUEUE_COMPUTE_BIT, a queueCount to co najmniej 2.
• [C-1-7] GPU i wyświetlacz MUSZĄ synchronizować dostęp do wspólnego bufora przedniego, tak aby treści VR z prędkością 60 kl./s były wyświetlane z użyciem naprzemiennego renderowania treści VR z 2 kontekstami renderowania bez widocznych zakłóceń.
• [C-1-9] MUSI wdrożyć obsługę flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT zgodnie z opisem w NDK.
• [C-1-10] MUSI zaimplementować obsługę AHardwareBuffer z dowolną kombinacją flag wykorzystania AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT dla co najmniej tych formatów: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] Zdecydowanie ZALECANE jest obsługa alokacji zasobów typu AHardwareBuffer z więcej niż jedną warstwą i flagami i formatami określonymi w C-1-10.
• [C-1-11] MUSI obsługiwać dekodowanie H.264 z szybkością co najmniej 3840 x 2160 przy 30 kl./s, skompresowaną do średniej szybkości 40 Mb/s (odpowiednik 4 instancji 1920 x 1080 przy 30 kl./s do 10 Mb/s lub 2 instancje x 1920 Mb/s).
• [C-1-12] MUSI obsługiwać HEVC i VP9; MUSI umożliwiać dekodowanie przy szybkości co najmniej 1920 x 1080 przy 30 kl./s po skompresowaniu do średnio 10 Mb/s i powinny mieć możliwość dekodowania szybkości 3840 x 2160 przy szybkości 30–2160 Mb/s przy 30–21 Mb/s (przy prędkości 30–20 Mb/s).
• [C-1-13] MUSI obsługiwać interfejs HardwarePropertiesManager.getDeviceTemperatures API i zwracać dokładne wartości temperatury skóry.
• [C-1-14] MUSI mieć wbudowany ekran, a jego rozdzielczość MUSI wynosić co najmniej 1920 x 1080 pikseli.
• [C-SR-6] Zdecydowanie zalecana jest rozdzielczość co najmniej 2560 x 1440 pikseli.
• [C-1-15] Wyświetlacz MUSI aktualizować się z częstotliwością co najmniej 60 Hz w trybie VR.
• [C-1-17] Wyświetlacz MUSI obsługiwać tryb o niskiej trwałości, który wynosi ≤ 5 milisekund, przy czym trwałość jest definiowana jako czas, przez jaki piksel emituje światło.
• [C-1-18] MUSI obsługiwać Bluetooth 4.2 oraz rozszerzenie Bluetooth LE Data Extension Sekcja 7.4.3.
• [C-1-19] MUSI obsługiwać i prawidłowo zgłaszać typ kanału bezpośredniego w przypadku wszystkich tych domyślnych typów czujników:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] Zdecydowanie ZALECANE jest obsługa typu kanału bezpośredniego TYPE_HARDWARE_BUFFER we wszystkich wymienionych powyżej typach kanałów bezpośrednich.
• [C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru w przypadku urządzenia android.hardware.hifi_sensors, określone w sekcji 7.3.9.
• [C-SR-8] Zdecydowanie ZALECANE jest obsługa funkcji android.hardware.sensor.hifi_sensors.
• [C-1-22] Trzeba mieć opóźnienie w pełnym zakresie do 28 milisekund.
• [C-SR-9] Zdecydowanie ZALECANE jest opóźnienie całkowite dla fotonów nie większe niż 20 milisekund.
• [C-1-23] MUSI mieć współczynnik pierwszej klatki, czyli stosunek jasności pikseli na pierwszej klatce po przejściu z czarnego do bieli i jasności białych pikseli w stanie nieruchomym na poziomie co najmniej 85%.
• [C-SR-10] Zdecydowanie ZALECANE jest, aby współczynnik pierwszej klatki wynosił co najmniej 90%.
• MOŻE zapewnić wyłączne rdzeń aplikacji na pierwszym planie i obsługiwać interfejs Process.getExclusiveCores API w celu zwracania liczby rdzeni procesora używanych wyłącznie dla aplikacji na pierwszym planie.

Jeśli obsługiwana jest podstawowa wersja podstawowa:

• [C-2-1] NIE MOŻE zezwalać na uruchamianie w niej żadnych innych procesów w przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE umożliwiać uruchomienie niektórych procesów jądra w razie potrzeby.

7.10. Reakcja na dotyk

Wymagania związane z poszczególnymi urządzeniami znajdziesz w artykule 2.2.1.

7.11. Zajęcia dotyczące skuteczności mediów

O klasę wydajności multimediów w przypadku implementacji urządzenia można uzyskać z android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS. Wymagania dotyczące klasy wydajności mediów są określone dla każdej wersji Androida od R (wersja 30). Wartość specjalna wynosząca 0 oznacza, że urządzenie nie należy do klasy wydajności mediów.

Jeśli implementacje urządzeń zwracają wartość inną niż 0 dla parametru android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS:

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

• [C-1-2] MUSI być implementacją na urządzeniach mobilnych.

• [C-1-3] MUSI spełniać wszystkie wymagania dotyczące klasy „Media Performance Class” opisane w sekcji 2.2.7.

Wymagania związane z konkretnymi urządzeniami znajdziesz w sekcji 2.2.7.

8. Wydajność i moc

Niektóre kryteria dotyczące minimalnej wydajności i mocy mają kluczowe znaczenie dla wygody użytkowników i wpływają na podstawowe założenia, jakie deweloperzy powinni mieć przy tworzeniu aplikacji.

8.1. Spójność wrażeń użytkownika

Użytkownikowi można zapewnić płynny interfejs, jeśli istnieją pewne minimalne wymagania, które zapewniają stałą liczbę klatek i czas odpowiedzi w aplikacjach i grach. Implementacje urządzeń, w zależności od ich typu, MOGĄ wiązać się z wymiernymi wymaganiami dotyczącymi czasu oczekiwania w interfejsie i przełączania zadań, zgodnie z opisem w sekcji 2.

8.2. Skuteczność dostępu do plików

Wspólna baza dla stałej wydajności dostępu do plików w prywatnym miejscu na dane aplikacji (partycja /data) umożliwia deweloperom aplikacji wprowadzenie odpowiednich oczekiwań, które ułatwią projektowanie oprogramowania. Implementacje urządzeń (w zależności od ich typu) MOGĄ BYĆ określone wymagania opisane w sekcji 2 dotyczące tych operacji odczytu i zapisu:

• Wydajność sekwencyjnego zapisu. Pomiar ten polega na zapisaniu pliku o rozmiarze 256 MB w buforze zapisu 10 MB.
• Losowa wydajność zapisu. Pomiar ten polega na zapisaniu pliku o wielkości 256 MB z użyciem bufora zapisu o rozmiarze 4 KB.
• Wydajność sekwencyjnego odczytu. Pomiar ten polega na odczytaniu pliku o wielkości 256 MB z użyciem 10 MB bufora zapisu.
• Losowa wydajność odczytu. Pomiar ten polega na odczytaniu pliku o wielkości 256 MB z użyciem bufora zapisu o wielkości 4 KB.

8.3. Tryby oszczędzania energii

Jeśli implementacje urządzeń obejmują funkcje usprawniające zarządzanie energią, które są uwzględnione w AOSP (np. zasobnik gotowości aplikacji, uśpienie) lub rozszerzenie funkcji pozwalających na stosowanie silniejszych ograniczeń niż zasobnik gotowości aplikacji z ograniczonym dostępem, to:

• [C-1-1] NIE MOŻE odbiegać od implementacji AOSP w przypadku algorytmów wyzwalania, konserwacji, wybudzania ani używania globalnych ustawień systemu ani DeviceConfig w trybach czuwania i oszczędzania energii w aplikacji.
• [C-1-2] NIE MOŻE odchodzić od implementacji AOSP w celu użycia ustawień globalnych lub DeviceConfig do zarządzania ograniczaniem zadań, alarmów i sieci dla aplikacji w każdym zasobniku w trybie gotowości aplikacji.
• [C-1-3] NIE MOŻE różnić się od implementacji AOSP w zakresie liczby zasobników gotowości aplikacji używanych do gotowości aplikacji.
• [C-1-4] MUSI zaimplementować zasobniki gotowości aplikacji i uśpienie zgodnie z opisem w artykule Zarządzanie zasilaniem.
• [C-1-5] MUSI zwracać kod true za PowerManager.isPowerSaveMode(), gdy urządzenie jest w trybie oszczędzania energii.
• [C-1-6] MUSI zapewniać użytkownikom dostęp do wszystkich aplikacji, które są zwolnione z trybów C-1-6, które są wykluczone z trybów czuwania i oszczędzania energii, a także wszelkich optymalizacji baterii. MUSZĄ też zaimplementować ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, aby użytkownik zezwolił aplikacji na zignorowanie optymalizacji baterii.
• [C-SR-1] Zdecydowanie zalecamy, aby użytkownicy mogli włączać i wyłączać funkcję oszczędzania baterii.
• [C-SR-2] Zdecydowanie zalecamy, aby użytkownicy mogli w łatwy sposób wyświetlać wszystkie aplikacje wyłączone z trybów czuwania aplikacji i uśpienia.

Jeśli implementacje urządzeń rozszerzają funkcje zarządzania energią dostępne w AOSP i to rozszerzenie stosuje bardziej rygorystyczne ograniczenia niż zasobnik gotowości do rzadkich aplikacji, zapoznaj się z sekcją 3.5.1.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ wdrożyć dowolny lub wszystkie 4 stany uśpienia zgodnie z definicją w zaawansowanym interfejsie konfiguracji i zasilania (ACPI).

Jeśli implementacje urządzeń implementują stany zasilania S4 określone w ACPI:

• [C-1-1] MUSI przejść w ten stan tylko wtedy, gdy użytkownik wykona wyraźne działanie mające na celu przełączenie urządzenia w stan nieaktywny (np. przez zamknięcie pokrywy, która jest fizycznie częścią urządzenia, lub wyłączenie pojazdu bądź telewizora), a także przed ponownym jego aktywacją (np. przez otwarcie pokrywy lub ponowne włączenie pojazdu lub telewizora).

Jeśli implementacje urządzeń implementują stany zasilania S3 zdefiniowane w ACPI:

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

  I na odwrót, MUSI wyjść ze stanu S3, gdy aplikacje zewnętrzne potrzebują zasobów systemowych, zgodnie z opisem w tym pakiecie SDK.

  Na przykład, gdy aplikacje innych firm żądają, aby ekran był włączony przez FLAG_KEEP_SCREEN_ON lub nieprzerwany przepływ pracy procesora przez PARTIAL_WAKE_LOCK, urządzenie NIE MOŻE przejść w stan S3, chyba że użytkownik zgodnie z opisem w punkcie C-1-1 podejmie wyraźne działanie w celu ustawienia go w stanie nieaktywności. I na odwrót, w przypadku uruchomienia zadania zaimplementowanych przez aplikacje innych firm za pomocą JobScheduler lub dostarczenia Komunikacji w chmurze Firebase do takich aplikacji urządzenie MUSI wyjść ze stanu S3, chyba że użytkownik przełączy je w stan nieaktywny. Nie są to wyczerpujące przykłady, a AOSP wykorzystuje silne sygnały wybudzenia, które wybudzają z tego stanu.

8.4. Rachunkowanie zużycia energii

Dokładniejsze liczenie i raportowanie zużycia energii zapewnia deweloperowi aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorca wykorzystania energii przez aplikację.

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie zalecamy podanie profilu zasilania dla poszczególnych komponentów, który określa wartość bieżącego zużycia energii dla każdego komponentu oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją projektu Android Open Source.
• [C-SR-2] Zdecydowanie ZALECANE jest raportowanie wszystkich wartości zużycia energii w miliiamperach godzin (mAh).
• [C-SR-3] Zdecydowanie ZALECANE jest raportowanie zużycia energii przez procesor według identyfikatora UID każdego procesu. Projekt Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [C-SR-4] Zdecydowanie ZALECANE jest udostępnienie tej informacji deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.
• MUSI być przypisana do samego komponentu sprzętowego, jeśli nie może przypisać do aplikacji zużycia energii przez komponent sprzętowy.

8.5. Stała skuteczność

W przypadku długotrwałych aplikacji o wysokiej wydajności wydajność może się znacznie wahać ze względu na inne aplikacje działające w tle lub ograniczanie procesora przez limity temperatury. Android ma interfejsy automatyczne, dzięki czemu, gdy urządzenie ma odpowiednie możliwości, główna aplikacja na pierwszym planie może zażądać, by system zoptymalizował alokację zasobów, żeby uwzględnić takie wahania.

Implementacje na urządzeniach:

• [C-0-1] MUSI dokładnie zgłaszać obsługę trybu zrównoważonej wydajności za pomocą metody interfejsu API PowerManager.isSustainedPerformanceModeSupported().

• POWINNA obsługiwać tryb stałej wydajności.

Jeśli implementacje urządzeń zgłaszają obsługę trybu trwałej wydajności:

• [C-1-1] MUSI zapewniać głównej aplikacji na pierwszym planie stały poziom wydajności przez co najmniej 30 minut, gdy aplikacja tego zażąda.
• [C-1-2] MUSI uwzględniać interfejs API Window.setSustainedPerformanceMode() i inne powiązane interfejsy API.

Jeśli implementacje urządzeń obejmują co najmniej 2 rdzenie procesora, są to:

• POWINIEN udostępnić co najmniej 1 rdzeń wyłączny, który można zarezerwować dla aplikacji najwyższego poziomu.

Jeśli implementacje urządzeń obsługują rezerwację 1 wyłącznego rdzenia dla aplikacji najwyższego poziomu:

• [C-2-1] MUSI raportować za pomocą metody API Process.getExclusiveCores() numery identyfikacyjne wyłącznych rdzeni, które mogą zostać zarezerwowane przez aplikację na pierwszym planie.
• [C-2-2] NIE MOŻE zezwalać na uruchamianie żadnych procesów w przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację na uruchamianie wyłącznych rdzeni, ale MOŻE zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.

Jeśli implementacje urządzeń nie obsługują rdzeni na wyłączność, są to:

• [C-3-1] MUSI zwracać pustą listę za pomocą metody interfejsu API Process.getExclusiveCores().

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniach:

• [C-0-1] MUSI wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, zgodnie z definicją podaną w dokumentacji dotyczącej zabezpieczeń i uprawnień w interfejsach API w dokumentacji dla programistów aplikacji na Androida.

• [C-0-2] MUSI obsługiwać samodzielnie podpisane aplikacje bez konieczności uzyskania dodatkowych pozwoleń/certyfikatów od osób trzecich/urzędów.

Jeśli implementacje urządzenia zadeklarują funkcję android.hardware.security.model.compatible:

• [C-1-1] MUSI spełniać wymagania wymienione w poniższych podpunktach.

9.1. Uprawnienia

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać model uprawnień Androida i model ról Androida zgodnie z definicją w dokumentacji dla deweloperów aplikacji na Androida. W szczególności MUSI egzekwować wszystkie uprawnienia i role zdefiniowane w sposób opisany w dokumentacji pakietu SDK. Żadne uprawnienia ani role nie mogą być pomijane, zmieniane ani ignorowane.

• MOŻE dodać dodatkowe uprawnienia, o ile ciągi identyfikatorów nowych uprawnień nie znajdują się w przestrzeni nazw android.\*.

• [C-0-2] Uprawnienia z protectionLevel PROTECTION_FLAG_PRIVILEGED MUSZĄ być przyznawane tylko aplikacjom wstępnie zainstalowanym w ramach uprzywilejowanych ścieżek obrazu systemu i w podzbiorze uprawnień bezpośrednio dozwolonych dla poszczególnych aplikacji. Implementacja AOSP spełnia to wymaganie, odczytując i przestrzegając uprawnień dozwolonych poszczególnych aplikacji z plików na ścieżce etc/permissions/ i używając ścieżki system/priv-app jako ścieżki z podwyższonymi uprawnieniami.

Uprawnienia z poziomem ochrony „Niebezpieczne” to uprawnienia w czasie działania. Aplikacje, które mają targetSdkVersion > 22, wysyłają żądania w czasie działania.

Implementacje na urządzeniach:

• [C-0-3] MUSI wyświetlać specjalny interfejs, w którym użytkownik może zdecydować, czy przyznać wymagane uprawnienia w czasie działania, oraz udostępnić interfejs do zarządzania uprawnieniami w czasie działania.
• [C-0-4] MUSI mieć tylko jedną implementację obu interfejsów.
• [C-0-5] NIE MOŻE przyznawać żadnych uprawnień w czasie działania zainstalowanym wstępnie aplikacjom, chyba że:
  • Zgodę użytkownika można uzyskać, zanim aplikacja jej użyje.
  • Uprawnienia w czasie działania są powiązane ze wzorcem intencji, dla którego ustawiona jest wstępnie zainstalowana aplikacja jako domyślny moduł obsługi.
• [C-0-6] MUSI przyznawać uprawnienie android.permission.RECOVER_KEYSTORE tylko aplikacjom systemowym, które rejestrują prawidłowo zabezpieczonego agenta odzyskiwania. Prawidłowo zabezpieczony agent przywracania to działający na urządzeniu agent oprogramowania, który synchronizuje się ze zdalną pamięcią urządzenia, która jest wyposażona w bezpieczny sprzęt zapewniający ochronę równoważną lub silniejszą niż jest to opisane w usłudze Google Cloud Key Vault, co pozwala zapobiegać atakom typu brute-force na podstawie wiedzy na ekranie blokady.

Implementacje na urządzeniach:

• [C-0-7] MUSI przestrzegać właściwości dostępu do lokalizacji na Androidzie, gdy aplikacja prosi o dostęp do lokalizacji lub danych o aktywności fizycznej za pomocą standardowego interfejsu API Androida lub zastrzeżonego mechanizmu. Dane te obejmują między innymi:

  • 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. identyfikator SSID, BSSID, identyfikator sieci komórkowej lub lokalizacja sieci, z którą urządzenie jest połączone).
  • Aktywność fizyczna lub klasyfikacja aktywności użytkownika.

Mówiąc bardziej szczegółowo o implementacjach na urządzeniach:

• [C-0-8] MUSI uzyskać zgodę użytkownika, by zezwolić aplikacji na dostęp do danych o lokalizacji lub aktywności fizycznej.
• [C-0-9] MUSI przyznawać uprawnienia w czasie działania TYLKO tej aplikacji, która posiada odpowiednie uprawnienia zgodnie z opisem w pakiecie SDK. Na przykład TelephonyManager#getServiceState wymaga uprawnienia android.permission.ACCESS_FINE_LOCATION.

Jedynym wyjątkiem od powyższych właściwości dostępu do lokalizacji na Androidzie są aplikacje, które nie mają dostępu do lokalizacji w celu określenia ani ustalania lokalizacji użytkownika. W szczególności:

• Gdy aplikacje mają uprawnienie RADIO_SCAN_WITHOUT_LOCATION.
• na potrzeby konfigurowania urządzenia, gdy aplikacje systemowe mają uprawnienia NETWORK_SETTINGS lub NETWORK_SETUP_WIZARD.

Uprawnienia można oznaczyć jako objęte ograniczeniami – wpływa to na ich działanie.

• [C-0-10] Uprawnienia oznaczone flagą hardRestricted NIE MOGĄ być przyznawane aplikacji, chyba że:

  • Plik APK aplikacji znajduje się na partycji systemowej.
  • Użytkownik przypisuje do aplikacji rolę powiązaną z uprawnieniami hardRestricted.
  • Instalator przydziela aplikacji hardRestricted.
  • Aplikacja otrzymuje uprawnienia hardRestricted w wcześniejszej wersji Androida.

• [C-0-11] Aplikacje z uprawnieniem softRestricted MUSZĄ mieć tylko ograniczony dostęp i NIE MOGĄ mieć pełnego dostępu, dopóki nie znajdą się na liście dozwolonych zgodnie z opisem w pakiecie SDK, gdzie pełny i ograniczony dostęp jest zdefiniowany dla każdego uprawnienia softRestricted (np. READ_EXTERNAL_STORAGE).

• [C-0-12] NIE MOŻE udostępniać żadnych niestandardowych funkcji ani interfejsów API umożliwiających ominięcie ograniczeń uprawnień zdefiniowanych w interfejsach API setPermissionPolicy i setPermissionGrantState.

• [C-0-13] MUSI używać interfejsów AppOpsManager API do rejestrowania i śledzenia każdego zautomatyzowanego dostępu do danych chronionych przez niebezpieczne uprawnienia w działaniach i usługach na Androidzie.

• [C-0-14] MUSI przypisywać role tylko do aplikacji z funkcjami, które spełniają wymagania tej roli.

• [C-0-15] NIE MOŻE definiować ról, które są duplikatami ani nadzbiorem funkcji ról zdefiniowanych przez platformę.

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

• [C-1-1] NIE MOŻE mieć tych uprawnień przyznawanych dyskretnie przez administratora:
  • Lokalizacja (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Aparat (APARAT)
  • 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ą wyświetlać się nad innymi aplikacjami z działaniem realizującym zamiar ACTION_MANAGE_OVERLAY_PERMISSION:

• [C-2-1] MUSI mieć pewność, że wszystkie działania z filtrami intencji dla intencji ACTION_MANAGE_OVERLAY_PERMISSION mają ten sam ekran interfejsu niezależnie od tego, jaka aplikacja inicjuje aplikację czy podawane przez nią informacje.

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

• [C-3-1] Podczas konfiguracji w pełni zarządzanego urządzenia (konfiguracja właściciela urządzenia) MUSI wyświetlać wyłączenie odpowiedzialności z informacją, że administrator IT będzie mógł zezwolić aplikacjom na kontrolowanie ustawień telefonu, w tym mikrofonu, aparatu i lokalizacji, oraz do opcji kontynuowania lub zakończenia konfiguracji, JEŻELI administrator zrezygnował z kontroli uprawnień na urządzeniu.

Jeśli implementacje urządzenia wstępnie instalują pakiety z rolą 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 na urządzeniach opisane w sekcji „9.8.6 Rejestrowanie treści”.
• [C-4-2] NIE MOŻE mieć uprawnienia android.permission.INTERNET. Jest to bardziej rygorystyczne niż Zdecydowanie ZALECANE Treści wymienione w artykule 9.8.6.
• [C-4-3] NIE MOŻE tworzyć powiązań z innymi aplikacjami, z wyjątkiem tych aplikacji systemowych: Bluetooth, Kontakty, Media, Telefonia, SystemUI oraz komponenty udostępniające internetowe interfejsy API.Jest to bardziej rygorystyczne niż Zdecydowanie ZALECANE w sekcji 9.8.6.

9.2. UID i izolacja procesów

Implementacje na urządzeniach:

• [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 Unixstyle i w osobnym procesie.
• [C-0-2] MUSI obsługiwać wiele aplikacji z tym samym identyfikatorem użytkownika Linuksa, o ile są one prawidłowo podpisane i skonstruowane, zgodnie z opisem w dokumentacji zabezpieczeń i uprawnień.

9.3. Uprawnienia systemu plików

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać model uprawnień dostępu do plików na Androidzie zgodnie z opisem 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 wykonawcze, w których są wykonywane aplikacje korzystające z innego oprogramowania lub technologii niż format wykonywalny Dalvik lub kod natywny. Krótko mówiąc:

• [C-0-1] Alternatywne środowiska wykonawcze MUSZĄ być aplikacjami na Androida i być zgodne ze standardowym modelem zabezpieczeń Androida opisanym w sekcji sekcja 9.

• [C-0-2] Alternatywne środowiska wykonawcze NIE MOGĄ mieć dostępu do zasobów chronionych za pomocą uprawnień, które nie są wymagane w pliku AndroidManifest.xml środowiska wykonawczego za pomocą mechanizmu <uses-permission>.

• [C-0-3] Alternatywne środowiska wykonawcze NIE MOGĄ zezwalać aplikacjom na korzystanie z funkcji chronionych uprawnieniami Androida ograniczonych do aplikacji systemowych.

• [C-0-4] Alternatywne środowiska wykonawcze MUSZĄ być zgodne z modelem piaskownicy Androida, a zainstalowane aplikacje korzystające z alternatywnego środowiska NIE MOGĄ ponownie używać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida związanych z udostępnianym identyfikatorem użytkownika i certyfikatem podpisywania.

• [C-0-5] Alternatywne środowiska wykonawcze NIE MOGĄ uruchamiać się w środowiskach piaskownicy odpowiadających innym aplikacjom na Androida, przyznawać do nich dostępu ani im do nich przyznawać.

• [C-0-6] Alternatywnego środowiska wykonawczego NIE MOŻNA uruchamiać razem z innymi aplikacjami ani przyznawać im żadnych uprawnień superużytkownika (roota) ani żadnego innego identyfikatora użytkownika.

• [C-0-7] Jeśli plik .apk alternatywnych środowisk wykonawczych znajduje się w obrazie systemowym implementacji urządzenia, MUSI być podpisany kluczem innym niż klucz używany do podpisywania innych aplikacji uwzględnionych w implementacjach na urządzeniu.

• [C-0-8] Podczas instalowania aplikacji alternatywne środowiska wykonawcze MUSZĄ uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację.

• [C-0-9] Gdy aplikacja musi skorzystać z zasobu urządzenia, które ma odpowiednie uprawnienie Androida (takiego jak Aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI informować użytkownika, że aplikacja będzie miała dostęp do tego zasobu.

• [C-0-10] Jeśli środowisko wykonawcze nie rejestruje funkcji aplikacji w ten sposób, podczas instalowania aplikacji korzystających z tego środowiska wykonawczego MUSI ono zawierać wszystkie uprawnienia samego środowiska wykonawczego.

• Alternatywne środowiska wykonawcze MUSZĄ instalować aplikacje za pomocą interfejsu PackageManager w osobnych piaskownicy Androida (identyfikatory użytkowników systemu Linux itp.).

• Alternatywne środowiska wykonawcze MOGĄ udostępniać jedną piaskownicę Androida udostępnianą wszystkim aplikacjom używającym tego środowiska.

9.5. Obsługa wielu użytkowników

Android zapewnia obsługę wielu użytkowników oraz umożliwia pełną izolację użytkowników oraz 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Ą BYĆ, ale NIE NALEŻY włączać obsługi wielu użytkowników, jeśli korzystają z nośników wymiennych jako podstawowej pamięci zewnętrznej.

Jeśli implementacje urządzeń obejmują obsługę wielu użytkowników:

• [C-1-2] MUSZĄ dla każdego użytkownika wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień w interfejsach API.
• [C-1-3] MUSI mieć oddzielne, odizolowane katalogi współdzielonej pamięci aplikacji (/sdcard) dla każdej instancji użytkownika.
• [C-1-4] MUSI mieć pewność, że aplikacje należące do danego użytkownika i uruchamiane w jego imieniu nie mogą wyświetlać plików należących do innego użytkownika, odczytywać ich ani zapisywać w nich danych, nawet jeśli dane obu użytkowników są przechowywane w tym samym woluminie lub w tym samym systemie plików.
• [C-1-5] MUSI szyfrować zawartość karty SD, gdy jest włączony wielu użytkowników, przy użyciu klucza zapisanego wyłącznie na nośniku niewymiennym dostępnym tylko dla systemu, jeśli implementacje urządzeń używają nośników wymiennych do obsługi interfejsów API pamięci zewnętrznej. Utrudnia to odczytywanie multimediów na hoście, dlatego implementacje urządzeń będą musiały przejść na MTP lub podobny system, by zapewnić komputerom hosta dostęp do danych bieżącego użytkownika.

Jeśli implementacje urządzeń obejmują obsługę wielu użytkowników, to w przypadku wszystkich użytkowników (oprócz tych utworzonych specjalnie na potrzeby uruchamiania 2 instancji tej samej aplikacji):

• [C-2-1] MUSI mieć oddzielne, odizolowane współdzielone katalogi pamięci masowej aplikacji (znane jako /sdcard) dla każdej instancji użytkownika.
• [C-2-2] MUSI mieć pewność, że aplikacje należące do danego użytkownika i uruchomione w jego imieniu nie mogą wyświetlać plików należących do innego użytkownika, odczytywać ich ani zapisywać w nich danych, nawet jeśli dane obu użytkowników są przechowywane w tym samym woluminie lub w tym samym systemie plików.

Implementacje na urządzeniach MOGĄ utworzyć jeden dodatkowy profil użytkownika typu android.os.usertype.profile.CLONE względem użytkownika głównego (i tylko wobec głównego użytkownika) na potrzeby uruchomienia 2 instancji tej samej aplikacji. Te podwójne instancje współdzielą częściowo izolowaną pamięć masową, są wyświetlane w programie uruchamiającym w tym samym czasie i w tym samym widoku najnowszych instancji. Dzięki temu użytkownik może na przykład zainstalować 2 osobne instancje tej samej aplikacji na urządzeniu z 2 kartami SIM.

Jeśli po implementacji na urządzeniach dodatkowy profil użytkownika omówiony powyżej:

• [C-3-1] MUSI zapewniać dostęp wyłącznie do miejsca na dane lub danych, które są już dostępne dla nadrzędnego profilu użytkownika lub należą bezpośrednio do tego dodatkowego profilu użytkownika.
• [C-3-2] NIE MOŻE mieć tego profilu służbowego.
• [C-3-3] MUSI mieć wyizolowane katalogi danych aplikacji od nadrzędnego konta użytkownika.
• [C-3-4] NIE MOŻE zezwalać na utworzenie dodatkowego profilu użytkownika, jeśli właściciel urządzenia jest zarejestrowany (patrz sekcja 3.9.1), ani umożliwiać obsługi administracyjnej właścicielowi urządzenia bez wcześniejszego usuwania dodatkowego profilu użytkownika.

9.6 Ostrzeżenie SMS-a specjalnego

Android umożliwia ostrzeganie użytkowników o wychodzących SMS-ach premium. SMS-y specjalne to SMS-y wysyłane do usługi zarejestrowanej u operatora, za którą użytkownik może być obciążony.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.telephony, będą to:

• [C-1-1] MUSI ostrzegać użytkowników przed wysłaniem SMS-a pod numery identyfikowane przez wyrażenia regularne zdefiniowane w pliku /data/misc/sms/codes.xml na urządzeniu. Rozwiązania Android Open Source Project, które można stosować, spełniają to wymaganie.

9.7. Funkcje zabezpieczeń

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń zarówno w jądrze, jak i na platformie, jak opisano poniżej.

Piaskownica Androida obejmuje funkcje korzystające z systemu Security-Extended Linux (SELinux), obowiązkowej kontroli dostępu (MAC), piaskownica seccomp i inne funkcje zabezpieczeń jądra systemu Linux. Implementacje na urządzeniach:

• [C-0-1] MUSI zachować zgodność z istniejącymi aplikacjami, nawet jeśli funkcja SELinux lub inne funkcje zabezpieczeń są wdrożone poniżej platformy Android.
• [C-0-2] NIE MOŻE mieć widocznego interfejsu użytkownika po wykryciu naruszenia bezpieczeństwa i zablokowaniu go przez funkcję zabezpieczeń wdrożoną poniżej platformy Androida, ale MOŻE mieć widoczny interfejs w przypadku wystąpienia niezablokowanego naruszenia zabezpieczeń skutkujące udanym wykorzystaniem ataku.
• [C-0-3] NIE MOŻE umożliwiać użytkownikowi ani deweloperowi aplikacji konfiguracji SELinux ani żadnych innych funkcji zabezpieczeń w środowisku Androida.
• [C-0-4] NIE MOŻE dopuścić do konfigurowania zasady naruszającej zgodność aplikacji, która może mieć wpływ na inną aplikację za pomocą interfejsu API (takiego jak interfejs Device Administration API).
• [C-0-5] MUSI podzielić platformę multimediów na wiele procesów, aby możliwe było bardziej precyzyjne przyznawanie dostępu do każdego z nich zgodnie z opisem na stronie projektu Android Open Source.
• [C-0-6] MUSI wdrożyć mechanizm piaskownicy aplikacji jądra, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnej zasady z programów wielowątkowych. Nadrzędny projekt Android Open Source Project spełnia to wymaganie przez włączenie seccomp-BPF z synchronizacją grup wątków (TSYNC) zgodnie z opisem w sekcji Konfiguracja jądra na stronie source.android.com.

Integralność jądra i funkcje samoochrony stanowią integralne elementy zabezpieczeń Androida. Implementacje na urządzeniach:

• [C-0-7] MUSI wdrożyć mechanizmy ochrony przed przepełnieniem bufora stosu jądra. Przykłady takich mechanizmów to CC_STACKPROTECTOR_REGULAR i CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] MUSI wdrożyć rygorystyczną ochronę pamięci jądra.Kod wykonywalny jest tylko do odczytu, dane tylko do odczytu są niemożliwe do wykonania i nie można zapisywać danych, a dane, których nie można zapisać, nie są możliwe do wykonania (np. CONFIG_DEBUG_RODATA lub CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] MUSI wdrożyć statyczne i dynamiczne ograniczenia rozmiaru obiektu oraz sprawdzanie kopii między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY) na urządzeniach, które pierwotnie były wysyłane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-10] NIE MOŻE uruchamiać pamięci w przestrzeni użytkownika podczas wykonywania w trybie jądra (np. sprzętowego PXN albo emulowanego przez CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które pierwotnie były wysyłane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-11] NIE MOŻE odczytywać ani zapisywać pamięci przestrzeni użytkownika w jądrze poza zwykłymi interfejsami API umożliwiającymi korzystanie z kopii przez użytkownika (np. sprzętowym numerem PAN lub emulowanym przez CONFIG_CPU_SW_DOMAIN_PAN bądź CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które pierwotnie były wysyłane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-12] MUSI wdrożyć izolację tabeli stron jądra, jeśli sprzęt jest podatny na ataki CVE-2017-5754 na wszystkich urządzeniach oryginalnie wysłanych z interfejsem API na poziomie 28 lub wyższym (np. CONFIG_PAGE_TABLE_ISOLATION lub CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] MUSI wdrożyć hartowanie prognozowania gałęzi, jeśli sprzęt jest podatny na ataki CVE-2017-5715 na wszystkich urządzeniach oryginalnie wysłanych z interfejsem API na poziomie 28 lub wyższym (np. CONFIG_HARDEN_BRANCH_PREDICTOR).
• [C-SR-1] Zdecydowanie ZALECANE jest zachowanie danych jądra, które po zainicjowaniu są zapisywane jako tylko do odczytu (np. __ro_after_init).

• [C-SR-2] Zdecydowanie ZALECANE jest użycie losowego układu kodu jądra i pamięci oraz unikanie ekspozycji, które mogłyby negatywnie wpłynąć na randomizację (np. CONFIG_RANDOMIZE_BASE z entropią programu rozruchowego przez /chosen/kaslr-seed Device Tree node lub EFI_RNG_PROTOCOL).

• [C-SR-3] Zdecydowanie ZALECANE jest włączenie integralności przepływu sterowania (CFI) w jądrze, co zapewnia dodatkową ochronę przed atakami polegającymi na ponownym użyciu kodu (np. CONFIG_CFI_CLANG i CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] Zdecydowanie ZALECANE jest, aby nie wyłączać funkcji Control-Flow Integrity (CFI), stosów wywołań cieni (SCS) ani Integer Overflow Sanitization (IntSan) w komponentach, które mają tę funkcję włączoną.

• [C-SR-5] Zdecydowanie ZALECANE jest włączenie CFI, SCS i IntSan w przypadku wszelkich dodatkowych komponentów w przestrzeni użytkownika zapewniających bezpieczeństwo, jak opisano w CFI i IntSan.

• [C-SR-6] Zdecydowanie ZALECANE jest włączenie inicjowania stosu w jądrze, co uniemożliwia użycie niezainicjowanych zmiennych lokalnych (CONFIG_INIT_STACK_ALL lub CONFIG_INIT_STACK_ALL_ZERO). Poza tym w implementacjach na urządzeniach NIE POWINNY jest przyjmowanie wartości używanej przez kompilatora do inicjowania zasobów lokalnych.

• [C-SR-7] Zdecydowanie ZALECANE jest włączenie inicjowania stosu w jądrze w celu uniemożliwienia korzystania z niezainicjowanych alokacji stosu (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). NIE POWINNY jest też zakładać wartości używanej przez jądro do inicjowania tych alokacji.

Jeśli implementacje urządzeń korzystają z jądra systemu Linux, które może obsługiwać SELinux:

• [C-1-1] MUSI zaimplementować SELinux.
• [C-1-2] MUSI ustawić SELinux w tryb globalnego egzekwowania.
• [C-1-3] MUSI skonfigurować wszystkie domeny w trybie wymuszania. Nie są dozwolone żadne domeny w trybie mniej rygorystycznym, w tym domeny charakterystyczne dla urządzenia/dostawcy.
• [C-1-4] NIE MOŻE modyfikować, pomijać ani zastępować reguł nigdy, które znajdują się w folderze systemowym/sepolicy dostępnym w nadrzędnym projekcie Android Open Source Project (AOSP), a zasady MUSZĄ skompilować z wszystkimi regułami „Nigdy nie zezwalaj” zarówno w domenach AOSP SELinux, jak i w domenach konkretnych urządzeń/dostawców.
• [C-1-5] MUSI uruchamiać zewnętrzne aplikacje kierowane na interfejs API na poziomie 28 lub wyższym w piaskownicy SELinux dla poszczególnych aplikacji z ograniczeniami SELinux dla poszczególnych aplikacji w katalogach prywatnych danych.
• POWINIEN zachować domyślną zasadę SELinux w folderze systemowym/sekwencyjnym nadrzędnego projektu Android Open Source i dodać ją do tej zasady wyłącznie na potrzeby własnej konfiguracji na danym urządzeniu.

Jeśli implementacje urządzeń korzystają z jądra innego niż Linux lub Linux bez SELinux:

• [C-2-1] MUSI używać obowiązkowego systemu kontroli dostępu, odpowiadającego SELinux.

Jeśli implementacje urządzeń korzystają z urządzeń I/O obsługujących DMA:

• [C-SR-8] Zdecydowanie ZALECANE jest izolowanie każdego urządzenia wejścia-wyjścia zdolne do DMA przy użyciu IOMMU (np. ARM SMMU).

Android zawiera wiele zaawansowanych funkcji ochrony, które są zintegrowane z zabezpieczeniami urządzenia. Dodatkowo Android skupia się na ograniczaniu kluczowych klas typowych błędów, które powodują obniżenie jakości i bezpieczeństwa.

Aby ograniczyć błędy w pamięci, implementacje urządzeń:

• [C-SR-9] Zdecydowanie ZALECANE jest użycie narzędzi do wykrywania błędów pamięci przestrzeni użytkownika, takich jak MTE w przypadku urządzeń ARMv9, HWASan dla urządzeń z architekturą ARMv8+ i ASan w przypadku innych typów urządzeń.
• [C-SR-10] Zdecydowanie ZALECANE jest przetestowanie ich 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ń z ARMv8 i CONFIG_KASAN_GENERIC w przypadku urządzeń innych typów).
• [C-SR-11] Zdecydowanie ZALECANE jest korzystanie w środowisku produkcyjnym z narzędzi do wykrywania błędów pamięci, takich jak MTE, GWP-ASan i KFENCE.

Jeśli implementacje urządzeń korzystają z TEE opartego na Arm TrustZone:

• [C-SR-12] Zdecydowanie ZALECANE jest używanie standardowego protokołu do udostępniania pamięci między Androidem a TEE, takim jak Arm Firmware Framework dla Armv8-A (FF-A).
• [C-SR-13] Zdecydowanie ZALECANE jest ograniczenie dostępu zaufanych aplikacji tylko do pamięci, która została im udostępniona za pomocą powyższego protokołu. Jeśli urządzenie obsługuje poziom wyjątku Arm S-EL2, powinno to być egzekwowane przez bezpiecznego menedżera partycji. W przeciwnym razie ten wymóg powinno być wymuszany przez TEE OS.

9.8. Prywatność

9.8.1. Historia wykorzystania

Android przechowuje historię wyborów użytkownika i zarządza nią w usłudze UsageStatsManager.

Implementacje na urządzeniach:

• [C-0-1] MUSI przechowywać taką historię użytkownika w rozsądnym czasie.
• [C-SR-1] Zdecydowanie ZALECANE jest zachowanie domyślnie skonfigurowanego 14-dniowego okresu przechowywania w implementacji AOSP.

Android przechowuje zdarzenia systemowe za pomocą identyfikatorów StatsLog i zarządza taką historią za pomocą StatsManager oraz interfejsu System API IncidentManager.

Implementacje na urządzeniach:

• [C-0-2] W raporcie o incydentach utworzonym przez klasę Systemowego interfejsu API IncidentManager MUSI uwzględniać tylko pola oznaczone symbolem DEST_AUTOMATIC.
• [C-0-3] NIE MOŻE używać identyfikatorów zdarzeń systemowych do rejestrowania innych zdarzeń niż opisane w dokumentach pakietu SDK StatsLog. W przypadku rejestrowania dodatkowych zdarzeń systemowych mogą one używać innego identyfikatora atomu z zakresu od 100 000 do 200 000.

9.8.2. Nagrywam

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE wstępnie wczytywać ani rozpowszechniać komponentów oprogramowania, które wysyłają z urządzenia prywatne informacje (np. naciśnięcia klawiszy, tekst wyświetlany na ekranie czy raport o błędach) z urządzenia bez jego zgody lub wyraźnych ciągłych powiadomień.
• [C-0-2] MUSI wyświetlać i uzyskiwać wyraźną zgodę użytkownika na przechwytywanie wszelkich informacji poufnych wyświetlanych na ekranie za każdym razem, gdy za pomocą MediaProjection lub zastrzeżonych interfejsów API jest włączone przesyłanie ekranu lub nagrywanie ekranu. NIE MOŻE udostępniać użytkownikom możliwości wyłączenia wyświetlania zgody użytkownika w przyszłości.
• [C-0-3] MUSI mieć aktywne powiadomienie o tym, że włączone jest przesyłanie ekranu lub nagrywanie ekranu. AOSP spełnia to wymaganie, wyświetlając ikonę ciągłego powiadomienia na pasku stanu.

Jeśli implementacje urządzeń obejmują funkcje systemu, które umożliwiają przechwytywanie treści wyświetlanych na ekranie lub nagrywanie strumienia audio odtwarzanego na urządzeniu w inny sposób niż za pomocą interfejsu ContentCaptureService System API albo za pomocą innych zastrzeżonych środków opisanych w artykule 9.8.6 Rejestrowanie treści:

• [C-1-1] MUSI mieć stałe powiadomienie o tym, że ta funkcja jest włączona i aktywnie przechwytuje lub nagrywa.

Jeśli implementacje urządzeń zawierają włączony od razu komponent, który umożliwia nagrywanie dźwięku otoczenia lub nagrywanie dźwięku odtwarzanego na urządzeniu w celu uzyskania przydatnych informacji o kontekście użytkownika:

• [C-2-1] NIE MOŻE przechowywać w trwałym miejscu na urządzeniu ani przesyłać poza urządzenie nagranych, nieprzetworzonych plików audio ani żadnych formatów, które można przekonwertować z powrotem na oryginalny dźwięk lub faks, chyba że za wyraźną zgodą użytkownika.

„Wskaźnik mikrofonu” oznacza widok na ekranie, który jest stale widoczny dla użytkownika i nie może być zasłonięty(przez unikalny tekst, kolor, ikonę lub inną kombinację).

„Wskaźnik kamery” odnosi się do widoku na ekranie, który jest stale widoczny dla użytkownika i nie może być zasłonięty (przez unikalny tekst, kolor, ikonę lub inną kombinację).

Po wyświetleniu pierwszej sekundy wskaźnik może się zmienić wizualnie, np. staje się mniejszy. Nie musi też pokazywać się w oryginalnym i zrozumiałym dla niego formacie.

Wskaźnik mikrofonu może zostać połączony z widocznym wskaźnikiem aparatu, pod warunkiem że tekst, ikony lub kolory będą wskazywać użytkownikowi, że właśnie rozpoczęło się korzystanie z mikrofonu.

Wskaźnik aparatu może zostać połączony z widocznym wskaźnikiem mikrofonu, pod warunkiem że tekst, ikony lub kolory będą wskazywać użytkownikowi, że właśnie rozpoczęło się korzystanie z kamery.

Jeśli implementacje urządzenia zadeklarują android.hardware.microphone:

• [C-SR-1] Zdecydowanie ZALECANE jest wyświetlanie wskaźnika mikrofonu, gdy aplikacja uzyskuje dostęp do danych dźwiękowych z mikrofonu, ale nie wtedy, gdy do mikrofonu uzyskują dostęp tylko aplikacje HotwordDetectionService, SOURCE_HOTWORD lub ContentCaptureService albo aplikacje pełniące role wymienione w artykule 9.1 Uprawnienia z identyfikatorem CDD [C-3-X]. .
• [C-SR-2] Zdecydowanie ZALECANE jest wyświetlanie listy ostatnich i aktywnych aplikacji korzystających z mikrofonu zwróconej przez PermissionManager.getIndicatorAppOpUsageData() wraz z powiązanymi komunikatami o atrybucji.
• [C-SR-3] Zdecydowanie ZALECANE jest, by nie ukrywać wskaźnika mikrofonu w aplikacjach systemowych, które mają widoczne interfejsy użytkownika lub mają bezpośrednią interakcję z użytkownikiem.

Jeśli implementacje urządzenia zadeklarują android.hardware.camera.any:

• [C-SR-4] Zdecydowanie ZALECANE jest wyświetlanie wskaźnika aparatu, gdy aplikacja uzyskuje dostęp do danych kamery, ale nie wtedy, gdy dostęp do kamery uzyskuje tylko aplikacje pełniące role wymienione w artykule 9.1 Uprawnienia z identyfikatorem CDD [C-3-X].
• [C-SR-5] Zdecydowanie ZALECANE jest wyświetlanie ostatnich i aktywnych aplikacji przy użyciu aparatu zwróconych z aplikacji PermissionManager.getIndicatorAppOpUsageData() oraz wszystkich powiązanych z nimi komunikatów o atrybucji.
• [C-SR-6] Zdecydowanie ZALECANE jest, aby nie ukrywać wskaźnika aparatu w aplikacjach systemowych, które mają widoczny interfejs lub bezpośrednią interakcję użytkownika.

9.8.3 Połączenia

Jeśli urządzenia są wyposażone w port USB z obsługą trybu urządzenia peryferyjnego USB, umożliwiają one:

• [C-1-1] MUSI wyświetlić interfejs użytkownika z prośbą o zgodę, zanim uzyska dostęp do zawartości pamięci współdzielonej przez port USB.

9.8.4 Ruch w sieci

Implementacje na urządzeniach:

• [C-0-1] MUSI zainstalować wstępnie te same certyfikaty główne dla zaufanego systemu urzędu certyfikacji (CA), które zostały udostępnione w nadrzędnym projekcie Android Open Source.
• [C-0-2] MUSI być wysyłany z pustym magazynem głównego urzędu certyfikacji użytkownika.
• [C-0-3] MUSI wyświetlać użytkownikowi ostrzeżenie informujące, że ruch sieciowy może być monitorowany po dodaniu głównego urzędu certyfikacji użytkownika.

Jeśli ruch z urządzenia jest kierowany przez VPN, takie implementacje urządzeń:

• [C-1-1] MUSI wyświetlać użytkownikowi ostrzeżenie:
  • Ruch w tej sieci może być monitorowany.
  • Ruch ten jest kierowany przez konkretną aplikację VPN, która udostępnia tę sieć.

Jeśli implementacje urządzeń mają wbudowany mechanizm, który jest domyślnie włączony, aby kierować ruch danych sieci przez serwer proxy lub bramę VPN (np. wstępne wczytywanie usługi VPN z przyznanym ustawieniem android.permission.CONTROL_VPN):

• [C-2-1] MUSI prosić użytkownika o zgodę przed włączeniem tego mechanizmu, chyba że usługa VPN jest włączona przez kontroler zasad dotyczących urządzeń w narzędziu DevicePolicyManager.setAlwaysOnVpnPackage(). W takim przypadku użytkownik nie musi wyrażać osobnej zgody, a jedynie otrzymać powiadomienie.

Jeśli implementacje urządzeń implementują funkcję kupna klienta, aby włączyć funkcję „stały VPN” w aplikacji VPN innej firmy:

• [C-3-1] MUSI wyłączyć tę funkcję użytkownika dla aplikacji, które nie obsługują stałej sieci VPN w pliku AndroidManifest.xml przez ustawienie atrybutu SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

9.8.5 Identyfikatory urządzeń

Implementacje na urządzeniach:

• [C-0-1] MUSI uniemożliwiać dostęp do numeru seryjnego urządzenia, a w stosownych przypadkach także numeru IMEI/MEID, numeru seryjnego karty SIM oraz identyfikatora IMSI (International Mobile Subscriber Identity) z aplikacji, chyba że aplikacja spełnia dowolne z tych wymagań:
  • to podpisana aplikacja operatora zweryfikowana przez producentów urządzeń.
  • Użytkownik otrzymał uprawnienie READ_PRIVILEGED_PHONE_STATE.
  • ma uprawnienia operatora określone w uprawnieniach operatora UICC.
  • to właściciel urządzenia lub właściciel profilu, który otrzymał uprawnienie READ_PHONE_STATE.
  • (Tylko w przypadku numeru seryjnego karty SIM/identyfikatora ICCID) wymaga zgodności z lokalnymi przepisami dotyczącymi wykrywania zmian tożsamości subskrybenta przez aplikację.

9.8.6 Rejestrowanie treści i wyszukiwanie aplikacji

Android za pomocą interfejsu System API ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query lub innych zastrzeżonych środków obsługuje mechanizm implementacji urządzeń, który rejestruje następujące interakcje danych aplikacji między aplikacjami a użytkownikiem:

• Tekst i grafiki renderowane na ekranie, w tym między innymi powiadomienia i dane wspomagające przez interfejs API AssistStructure.
• Dane multimedialne, takie jak dźwięk i film, nagrane lub odtwarzane przez urządzenie.
• Zdarzenia dotyczące wprowadzania danych (np. klawisz, mysz, gest, głos, film i ułatwienia dostępu).
• Wszelkie inne zdarzenia przekazywane przez aplikację do systemu za pomocą interfejsu API Content Capture lub AppSearchManager API o podobnej funkcjonalności Androida i zastrzeżonego interfejsu API.
• Dowolne teksty i inne dane wysyłane przez TextClassifier API do System TextClassifier, tj. do usługi systemowej w celu zrozumienia znaczenia tekstu, a także wygenerowania przewidywalnych dalszych działań na podstawie tekstu.
• Dane zindeksowane przez wdrożenie AppSearch na platformie, w tym m.in. dane tekstowe, graficzne i multimedialne.

Jeśli implementacje urządzeń rejestrują powyższe dane:

• [C-1-1] MUSI szyfrować wszystkie takie dane, gdy są przechowywane na urządzeniu. To szyfrowanie MOŻE zostać zrealizowane za pomocą szyfrowania na Androidzie lub dowolnego z mechanizmów szyfrowania wymienionych w interfejsie API w wersji 26 lub nowszej, zgodnie z opisem w pakiecie SDK Cipher.
• [C-1-2] NIE MOŻE tworzyć kopii zapasowych nieprzetworzonych ani zaszyfrowanych danych przy użyciu metod tworzenia kopii zapasowych na Androidzie ani żadnych innych metod tworzenia kopii zapasowej.
• [C-1-3] MUSI wysyłać wszystkie takie dane oraz dziennik urządzenia tylko przy użyciu mechanizmu ochrony prywatności. Mechanizm chroniący prywatność to „te, które umożliwiają tylko analizę zbiorczą i uniemożliwiają dopasowywanie zalogowanych zdarzeń lub wyników uzyskanych do poszczególnych użytkowników”, zapobiegając spojrzeniu na dane poszczególnych użytkowników (np. implementowane przy użyciu technologii prywatności różnicowej, takiej jak RAPPOR).
• [C-1-4] NIE MOŻE wiązać takich danych z jakąkolwiek tożsamością użytkownika (taką jak Account) na urządzeniu, chyba że za każdym razem uzyskasz wyraźną zgodę użytkownika.
• [C-1-5] NIE MOŻE udostępniać takich danych innym komponentom systemu operacyjnego, które nie spełniają wymagań opisanych w bieżącej sekcji (9.8.6 Rejestrowanie treści), chyba że za każdym razem wyrazisz na to wyraźną zgodę użytkownika.
• [C-1-6] MUSI zapewnić użytkownikowi możliwość usunięcia takich danych, które zbiera ContentCaptureService lub zastrzeżone środki, jeśli dane są przechowywane na urządzeniu w dowolnej formie.
• [C-1-7] MUSI zapewniać użytkownikowi możliwość rezygnacji z danych zebranych za pomocą AppSearch lub zastrzeżonych środków na platformie Androida, np. w programie uruchamiającym.
• [C-SR-1] Zdecydowanie ZALECANE jest NIE prosić o uprawnienia INTERNET.
• [C-SR-2] Zdecydowanie ZALECANE jest uzyskiwanie dostępu do internetu wyłącznie za pomocą uporządkowanych interfejsów API opartych na publicznie dostępnych implementacjach open source.

Jeśli implementacje urządzeń obejmują usługę, która implementuje interfejs API systemu ContentCaptureService, AppSearchManager.index lub dowolną zastrzeżoną usługę, która rejestruje dane w sposób opisany powyżej:

• [C-2-1] NIE MOŻE zezwalać użytkownikom na zastępowanie usług aplikacjami lub usługami możliwymi do zainstalowania przez użytkownika i MUSI zezwalać na przechwytywanie takich danych wyłącznie przez zainstalowane usługi.
• [C-2-2] NIE MOŻE zezwalać na przechwytywanie takich danych aplikacjom innym niż zainstalowany fabrycznie mechanizm usług.
• [C-2-3] MUSI zapewnić użytkownikom korzyści w celu wyłączenia usług.
• [C-2-4] NIE MOŻE pomijać zgody użytkownika na zarządzanie uprawnieniami Androida przyznanymi przez usługi i zgodnie z modelem uprawnień Androida opisanym w artykule 9.1. Uprawnienia.

• [C-SR-3] Zdecydowanie ZALECANE jest oddzielenie usług od innych komponentów systemu(np. brak wiązania identyfikatorów usług i procesów udostępniania) z wyjątkiem tych przypadków:

  • Telefonia, kontakty, interfejs systemu i multimedia

Android w SpeechRecognizer#onDeviceSpeechRecognizer() umożliwia rozpoznawanie mowy na urządzeniu bez konieczności korzystania z sieci. Implementacja narzędzia SpeechSpeechr na urządzeniu MUSI być zgodna z zasadami opisanymi w tej sekcji.

9.8.7 Dostęp do schowka

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE zwracać do schowka przyciętych danych (np. za pomocą interfejsu API ClipboardManager), chyba że aplikacja jest domyślnym edytorem IME lub jest aktualnie fokusem.

9.8.8 Lokalizacja

Lokalizacja obejmuje informacje z klasy lokalizacji Androida( takie jak szerokość geograficzna, długość geograficzna czy wysokość), a także identyfikatory, które można przekonwertować na lokalizację. Lokalizacja może być bardzo dokładna, np. DGPS (różnicowy globalny system pozycjonowania) lub przybliżona, jak lokalizacja na poziomie kraju (np. lokalizacja według kraju – MCK – kod kraju mobilnego).

Poniżej znajdziesz listę typów lokalizacji, które bezpośrednio określają lokalizację użytkownika lub które mogą zostać przekonwertowane na lokalizację. Ta lista nie jest wyczerpująca, ale powinna służyć jako przykład tego, z czego może bezpośrednio lub pośrednio pochodzić usługa Lokalizacja:

• GPS/GNSS/DGPS/PPP
  • rozwiązanie do globalnego pozycjonowania, globalny system nawigacji satelitarnej czy rozwiązanie do różnicowego globalnego pozycjonowania
  • Dotyczy to również nieprzetworzonych pomiarów GNSS i stanu GNSS
    • Dokładną lokalizację można określić na podstawie nieprzetworzonych pomiarów GNSS
• Technologie bezprzewodowe o unikalnych identyfikatorach, takich jak:
  • Punkty dostępu Wi-Fi (MAC, BSSID, nazwa lub SSID)
  • Bluetooth/BLE (MAC, BSSID, nazwa lub SSID)
  • UWB (MAC, BSSID, nazwa lub SSID)
  • identyfikatora stacji bazowej sieci komórkowej (3G, 4G, 5G..., łącznie ze wszystkimi przyszłymi modemami komórkowymi, które będą miały unikalne identyfikatory)

Jako punkt odniesienia zapoznaj się z interfejsami API Androida, które wymagają uprawnień ACCESS_FINE_Location lub ACCESS_COARSE_Location.

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE włączać/wyłączać ustawień lokalizacji urządzenia ani skanowania Wi-Fi/Bluetooth bez wyraźnej zgody użytkownika lub jego zainicjowania.
• [C-0-2] W celu określenia lokalizacji użytkownik musi mieć dostęp do informacji związanych z lokalizacją, w tym do ostatnich próśb o lokalizację, uprawnień na poziomie aplikacji oraz korzystania ze skanowania Wi-Fi i Bluetooth.
• [C-0-3] MUSI upewnić się, że aplikacja korzystająca z interfejsu Emergency Location Bypass API [LocationRequest.setLocationSettingsignored()] jest sesją alarmową inicjowaną przez użytkownika (np. wybranie numeru 911 lub SMS-a pod 112). W przypadku motoryzacji pojazd MOŻE zainicjować sesję alarmową bez aktywnej interakcji użytkownika w przypadku wykrycia wypadku/wypadku (np. w celu spełnienia wymagań dotyczących eCall).
• [C-0-4] MUSI zachować możliwość ominięcia ustawień lokalizacji urządzenia przez interfejs Emergency Location Bypass API bez ich zmiany.
• [C-0-5] MUSI zaplanować powiadomienie przypominające użytkownikowi, gdy aplikacja w tle uzyska dostęp do jego lokalizacji przy użyciu uprawnienia [ACCESS_BACKGROUND_LOCATION].

9.8.9. Zainstalowane aplikacje

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

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE udostępniać żadnych informacji dotyczących innych zainstalowanych aplikacji kierowanych na interfejs API na poziomie 30 lub wyższym, chyba że aplikacja ma już dostęp do informacji o innej zainstalowanej aplikacji za pomocą zarządzanych interfejsów API. Obejmuje to między innymi szczegóły udostępniane przez niestandardowe interfejsy API dodane przez implementujący urządzenie lub dostępne z poziomu systemu plików.
• [C-0-2] NIE MOŻE przyznawać żadnych aplikacji uprawnień do odczytu ani zapisu plików w specjalnym katalogu aplikacji innej aplikacji w pamięci zewnętrznej. Jedyne wyjątki to:
  • Urząd zewnętrznego dostawcy pamięci masowej (np. aplikacji takich jak DocumentsUI).
  • Pobierz dostawcę, który korzysta z uprawnień dostawcy „pobierania” w przypadku pobierania plików do pamięci aplikacji.
  • Aplikacje korzystające z protokołu przesyłania multimediów podpisanego przez platformę (MTP), które korzystają z uprzywilejowanych uprawnień ACCESS_MTP, umożliwiają przesyłanie plików na inne urządzenie.
  • Aplikacje, które instalują inne aplikacje i mają uprawnienie INSTALL_PACKAGES, mają dostęp tylko do katalogów „obb” na potrzeby zarządzania plikami rozszerzeń APK.

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

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

• [C-1-1] MUSI obsługiwać generowanie raportów o błędach połączeń za pomocą BUGREPORT_MODE_TELEPHONY za pomocą BugreportManager.
• [C-1-2] MUSI uzyskiwać zgodę użytkownika za każdym razem, gdy usługa BUGREPORT_MODE_TELEPHONY jest używana do wygenerowania raportu. NIE MOŻE prosić użytkownika o zgodę na wszystkie przyszłe żądania aplikacji.
• [C-1-3] NIE MOŻE zwracać wygenerowanego raportu aplikacji, która wysłała prośbę, bez wyraźnej zgody użytkownika.
• [C-1-4] Raporty wygenerowane za pomocą narzędzia BUGREPORT_MODE_TELEPHONY MUSZĄ zawierać co najmniej te informacje:
  • Zrzut TelephonyDebugService
  • Zrzut TelephonyRegistry
  • Zrzut WifiService
  • Zrzut ConnectivityService
  • Zrzut instancji CarrierService pakietu wywołującego (jeśli jest powiązany)
  • Bufor dziennika radiowego
• [C-1-5] NIE MOŻE zawierać w wygenerowanych raportach tych informacji:
  • Wszelkie informacje, które nie są bezpośrednio związane z debugowaniem połączeń.
  • Wszelkie logi ruchu z aplikacji zainstalowanych przez użytkowników lub szczegółowe profile aplikacji lub pakietów zainstalowanych przez użytkowników (identyfikatory UID są dopuszczalne, nazwy pakietów nie są dozwolone).
• MOŻE zawierać dodatkowe informacje, które nie są powiązane z żadną tożsamością użytkownika. (np. dzienniki dostawcy).

Jeśli implementacje urządzeń zawierają dodatkowe informacje (np. dzienniki dostawcy) w raportach o błędach i mogą one mieć wpływ na ochronę prywatności, bezpieczeństwo, baterię, pamięć masową lub pamięć,:

• [C-SR-1] Zdecydowanie ZALECANE jest włączenie ustawienia programistycznego na domyślnie wyłączone. Implementacja referencyjna AOSP spełnia to wymaganie, udostępniając w ustawieniach dewelopera opcję Enable verbose vendor logging, która pozwala uwzględniać w raportach o błędach dodatkowe logi dostawcy dotyczące konkretnego urządzenia.

9.8.11. Udostępnianie blobów danych

Android, za pomocą BlobStoreManager, umożliwia aplikacjom przesyłanie blobów danych do systemu, aby były udostępniane wybranemu zestawowi aplikacji.

Jeśli implementacje urządzeń obsługują udostępniane bloby danych zgodnie z opisem w dokumentacji pakietu SDK, umożliwiają one:

• [C-1-1] NIE MOŻE udostępniać blobów danych należących do aplikacji poza ich przeznaczeniem (tj. zakresu dostępu domyślnego i innych trybów dostępu, które można określić za pomocą BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() lub BlobStoreAccessManager.session#allow Implementacja referencyjna AOSP spełnia te wymagania.
• [C-1-2] NIE MOŻE wysyłać bezpiecznych haszów blobów danych (służących do kontroli dostępu) ani udostępniać innym aplikacjom.

9.8.12. Rozpoznawanie muzyki

Android, w ramach interfejsu System API MusicRecognitionManager, obsługuje mechanizm implementacji żądań rozpoznawania muzyki na urządzeniach, rejestrując dźwięk i przekazuje rozpoznanie muzyki do aplikacji z podwyższonymi uprawnieniami, implementującej interfejs MusicRecognitionService API.

Jeśli implementacje urządzeń obejmują usługę, która implementuje system MusicRecognitionManager lub dowolną zastrzeżoną usługę, która strumieniuje dane audio zgodnie z opisem powyżej:

• [C-1-1] MUSI wymuszać, aby element wywołujący MusicRecognitionManager miał uprawnienie MANAGE_MUSIC_RECOGNITION
• [C-1-2] MUSI wymuszać stosowanie usługi MusicRecognitionService w przypadku pojedynczej, wstępnie zainstalowanej aplikacji do rozpoznawania muzyki.
• [C-1-3] NIE MOŻE umożliwiać użytkownikom zastępowania obiektów MusicRecognitionManagerService ani MusicRecognitionService aplikacjami lub usługami, które użytkownik może zainstalować.
• [C-1-4] MUSI mieć pewność, że gdy MusicRecognitionManagerService uzyska dostęp do rekordu audio i przekaże go do aplikacji implementującej usługę MusicRecognitionService, dostęp audio będzie śledzony za pomocą wywołań AppOpsManager.noteOp / startOp.

Jeśli implementacje MusicRecognitionManagerService lub MusicRecognitionService na urządzeniu zapisują zarejestrowane dane audio:

• [C-2-1] NIE MOŻE w ogóle przechowywać na dysku ani w pamięci żadnych odcisków cyfrowych nieprzetworzonych plików audio ani dźwiękowych przez okres dłuższy niż 14 dni.
• [C-2-2] NIE MOŻE udostępniać takich danych poza MusicRecognitionService, chyba że za każdym razem wyrazisz na to wyraźną zgodę użytkownika.

9.8.13. Menedżer prywatności czujnika

Jeśli implementacje urządzeń zapewniają użytkownikowi możliwość wyłączenia wejścia kamery lub mikrofonu na potrzeby urządzenia:

• [C-1-1] MUSI zwracać wartość „true” (prawda) w przypadku odpowiedniej metody interfejsu API supportsSensorToggle().
• [C-1-2] Gdy aplikacja próbuje uzyskać dostęp do zablokowanego mikrofonu lub aparatu, musi przedstawić użytkownikowi niemożliwą do odrzucenia informację o tym, że czujnik jest zablokowany i że wymaga wyboru kontynuowania jego blokowania lub odblokowywania zgodnie z implementacją AOSP spełniającą to wymaganie.
• [C-1-3] MUSI przekazywać do aplikacji tylko pusty (lub fałszywy) aparat i dane dźwiękowe. Użytkownik nie może zgłaszać kodu błędu, jeśli użytkownik nie włączy kamery i mikrofonu zgodnie z opisem w punkcie [C-1-2] powyżej.

9.9. Szyfrowanie magazynu danych

Wszystkie urządzenia MUSZĄ spełniać wymagania opisane w sekcji 9.9.1. Urządzenia, które zostały wprowadzone na poziomie interfejsu API wcześniej niż ten dokument, są zwolnione z wymagań sekcji 9.9.2 i 9.9.3. Zamiast tego MUSZĄ spełniać wymagania z artykułu 9.9 dokumentu definicji zgodności z Androidem odpowiadające poziomowi interfejsu API, na którym uruchomiono urządzenie.

9.9.1. Bezpośredni rozruch

Implementacje na urządzeniach:

• [C-0-1] MUSI wdrożyć interfejsy API trybu bezpośredniego rozruchu, nawet jeśli nie obsługują szyfrowania pamięci.

• [C-0-2] ACTION_LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED intencje MUSZĄ nadal być transmitowane, aby zasygnalizować aplikacjom, że dane są dostępne w lokalizacji pamięci zaszyfrowanej na urządzeniu (DE) lub CE.

9.9.2. Wymagania dotyczące szyfrowania

Implementacje na urządzeniach:

• [C-0-1] MUSI szyfrować prywatne dane aplikacji (partycja /data) oraz partycję pamięci współdzielonej aplikacji (partycja /sdcard), jeśli jest to trwała, niemożliwa do usunięcia część urządzenia.
• [C-0-2] MUSI domyślnie włączać szyfrowanie danych, gdy użytkownik zakończy rozruchową konfigurację.

• [C-0-3] MUSI spełniać powyższe wymagania dotyczące szyfrowania miejsca na dane przez wdrożenie jednej z tych 2 metod szyfrowania:

  • Szyfrowanie oparte na plikach (FBE) i szyfrowanie metadanych zgodnie z opisem w sekcji 9.9.3.1.
  • Szyfrowanie na poziomie blokowania poszczególnych użytkowników opisane w sekcji 9.9.3.2.

9.9.3 Metody szyfrowania

Jeśli implementacje urządzeń są zaszyfrowane:

• [C-1-1] MUSI uruchomić się bez żądania podania danych logowania przez użytkownika i zezwolić aplikacjom wykrywającym bezpośrednie rozruchy na dostęp do pamięci zaszyfrowanej na urządzeniu (DE) po wysłaniu komunikatu ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] MUSI zezwalać na dostęp do pamięci CE (Credential Encrypted) dopiero po odblokowaniu urządzenia przez użytkownika, podając swoje dane logowania (np. hasło, kod PIN, wzór lub odcisk palca) i wysłany komunikat ACTION_USER_UNLOCKED.
• [C-1-13] NIE MOŻE oferować żadnej metody odblokowywania pamięci chronionej CE bez danych logowania podanych przez użytkownika, zarejestrowanego klucza depozytowego ani wznowienia po ponownym uruchomieniu spełniającego wymagania opisane w sekcji 9.9.4.
• [C-1-4] MUSI 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:

• [C-1-5] MUSI szyfrować zawartość pliku i metadane systemu plików przy użyciu protokołu 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 odnosi się do Adiantum-XChaCha12-AES, jak podano na stronie https://github.com/google/adiantum. Metadane systemu plików to dane takie jak rozmiary plików, własność, tryby i atrybuty rozszerzone (xattrs).
• [C-1-6] MUSI szyfrować nazwy plików za pomocą AES-256-CBC-CTS lub Adiantum.
• [C-1-12] Jeśli urządzenie obsługuje instrukcje AES (Advanced Encryption Standard, np. ARMv8 Cryptography Extensions na urządzeniach z procesorami ARM lub AES-NI na urządzeniach z procesorami x86), należy używać powyższych opcji opartych na AES w zakresie nazwy pliku, zawartości pliku i szyfrowania metadanych systemu plików, a nie Adiantum.
• [C-1-13] MUSI używać silnej kryptograficznie i nieodwracalnej funkcji derywacji kluczy (np. HKDF-SHA512), aby uzyskać potrzebne podklucze (np. klucze poszczególnych plików) z kluczy CE i DE. „Syptograficzna i nieodwracalna” oznacza, że funkcja derywacji klucza ma poziom zabezpieczeń co najmniej 256 bitów i działa jak rodzina funkcji pseudonimizowanych nad jej danymi wejściowymi.
• [C-1-14] NIE MOŻE używać tych samych kluczy ani podkluczy szyfrowania FBE do różnych celów kryptograficznych (np. zarówno do szyfrowania, jak i wygenerowania kluczy lub do dwóch różnych algorytmów szyfrowania).
• [C-1-15] MUSI zapewnić szyfrowanie wszystkich nieusuniętych bloków zaszyfrowanej treści plików w trwałych pamięciach przy użyciu kombinacji klucza szyfrowania i wektora inicjującego (IV), które zależą zarówno od pliku, jak i odsunięcia w pliku. Poza tym wszystkie takie kombinacje MUSZĄ być różne, chyba że szyfrowanie jest realizowane z wykorzystaniem wbudowanego sprzętu do szyfrowania, który obsługuje tylko 32-bitowe szyfrowanie IV.
• [C-1-16] MUSI zadbać o to, aby wszystkie nieusunięte zaszyfrowane nazwy plików w trwałych katalogach w różnych katalogach były szyfrowane przy użyciu różnych kombinacji klucza szyfrowania i wektora inicjującego (IV).

• [C-1-17] MUSI mieć pewność, że wszystkie zaszyfrowane bloki metadanych systemu plików w pamięci trwałej są szyfrowane przy użyciu różnych kombinacji klucza szyfrowania i wektora inicjującego (IV).

• Klucze chroniące obszary pamięci CE i DE oraz metadane systemu plików:

  • [C-1-7] MUSI być kryptograficznie powiązany ze sprzętowym magazynem kluczy. Ten magazyn kluczy MUSI być powiązany z weryfikacją podczas uruchamiania i z urządzeniem głównym zaufania urządzenia.
  • [C-1-8] Klucze CE MUSZĄ być powiązane z danymi logowania na ekranie blokady użytkownika.
  • [C-1-9] Jeśli użytkownik nie określił danych logowania na ekranie blokady, klucze CE MUSZĄ być powiązane z domyślnym kodem dostępu.
  • [C-1-10] MUSI być niepowtarzalny. Oznacza to, że żaden klucz CE ani DE użytkownika nie pasuje do żadnego klucza CE lub DE innego użytkownika.
  • [C-1-11] MUSI używać obsługiwanych szyfrów, długości kluczy i trybów.
  • [C-1-12] MUSI zostać bezpiecznie wykasowana podczas odblokowywania i blokowania programu rozruchowego, jak opisano tutaj.

• TRZEBA utworzyć wstępnie zainstalowane niezbędne aplikacje (np. Alarm, telefon, Messenger) Bezpośrednie uruchamianie.

Nadrzędny projekt Android Open Source zapewnia preferowaną implementację szyfrowania opartego na plikach w oparciu o funkcję szyfrowania „fscrypt” jądra systemu Linux oraz szyfrowanie metadanych oparte na funkcji „dm-default-key” jądra systemu Linux.

9.9.3.2. Szyfrowanie na poziomie blokowania poszczególnych użytkowników

Jeśli implementacje urządzeń korzystają z szyfrowania na poziomie bloku dla poszczególnych użytkowników:

• [C-1-1] MUSI włączyć obsługę wielu użytkowników zgodnie z opisem w sekcji 9.5.
• [C-1-2] MUSI udostępniać partycje dla poszczególnych użytkowników przy użyciu partycji nieprzetworzonych lub woluminów logicznych.
• [C-1-3] MUSI używać unikalnych, unikalnych kluczy szyfrowania dla każdego użytkownika do szyfrowania bazowych urządzeń blokujących.

• [C-1-4] MUSI używać AES-256-XTS do szyfrowania partycji użytkownika na poziomie bloku.

• Klucze chroniące urządzenia zaszyfrowane na poziomie bloku dla poszczególnych użytkowników:

  • [C-1-5] MUSI być kryptograficznie powiązany ze sprzętowym magazynem kluczy. Ten magazyn kluczy MUSI być powiązany z weryfikacją podczas uruchamiania i z urządzeniem głównym 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 wdrożyć za pomocą funkcji „dm-crypt” jądra systemu Linux zamiast partycji poszczególnych użytkowników.

9.9.4. Wznów po ponownym uruchomieniu

Funkcja Wznowienie przy ponownym uruchomieniu umożliwia odblokowanie pamięci CE wszystkich aplikacji, w tym tych, które jeszcze nie obsługują bezpośredniego rozruchu, po ponownym uruchomieniu zainicjowanym przez OTA. Ta funkcja umożliwia użytkownikom otrzymywanie powiadomień z zainstalowanych aplikacji po ponownym uruchomieniu.

Wdrożenie funkcji wznawiania po ponownym uruchomieniu musi zapewniać, że gdy urządzenie wpadnie w ręce atakującego, bardzo będzie bardzo trudno odzyskać zaszyfrowane dane CE użytkownika, nawet jeśli urządzenie jest włączone, pamięć CE jest odblokowana, a użytkownik odblokował urządzenie po otrzymaniu OTA. Z myślą o odporności na atak osób wtajemniczonych zakładamy też, że osoba przeprowadzająca atak uzyskuje dostęp do przesyłanych kryptograficznych kluczy podpisywania.

Więcej szczegółów:

• [C-0-1] Pamięć CE NIE MOŻE być czytelna dla osoby przeprowadzającej atak, który fizycznie ma urządzenie z następującymi możliwościami i ograniczeniami:

  • Umożliwia podpisywanie dowolnych wiadomości kluczem podpisywania dowolnego dostawcy lub firmy.
  • Może powodować odbieranie aktualizacji OTA przez urządzenie.
  • Mogą modyfikować działanie dowolnego sprzętu (AP, Flash itp.), z wyjątkiem przypadków opisanych poniżej, ale wymagają co najmniej godzinnego opóźnienia i cyklu zasilania, które niszczy zawartość pamięci RAM.
  • Nie można zmienić działania sprzętu odpornego na manipulacje (np. Titan M).
  • Nie można odczytać pamięci RAM aktywnego urządzenia.
  • Nie można uzyskać danych logowania użytkownika (kodu PIN, wzoru, hasła) lub w inny sposób spowodować ich podanie.

Na przykład implementacja urządzeń, w której zastosowano wszystkie funkcje wymienione tutaj i z nimi zgodna, będzie zgodna z normą [C-0-1].

9.10. Integralność urządzenia

Te wymagania zapewniają przejrzystość stanu integralności urządzenia. Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo zgłaszać za pomocą metody System API PersistentDataBlockManager.getFlashLockState(), czy stan programu rozruchowego zezwala na flashowanie obrazu systemu.

• [C-0-2] MUSI obsługiwać weryfikację podczas uruchamiania, aby zapewnić integralność urządzenia.

Jeśli implementacje urządzeń zostały już wdrożone bez obsługi weryfikacji podczas uruchamiania we wcześniejszej wersji Androida i nie mogą dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, MOGĄ one zostać zwolnione z tego wymogu.

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

• [C-1-1] MUSI zadeklarować flagę funkcji platformy android.software.verified_boot.
• [C-1-2] MUSI przeprowadzić weryfikację przy każdej sekwencji uruchamiania.
• [C-1-3] MUSI rozpocząć weryfikację od stałego klucza sprzętowego, który jest podstawą zaufania, aż do poziomu partycji systemowej.
• [C-1-4] MUSI wdrożyć każdy etap weryfikacji, aby na następnym etapie sprawdzić integralność i autentyczność wszystkich bajtów, zanim wykonasz kod na kolejnym etapie.
• [C-1-5] MUSI korzystać z algorytmów weryfikacji o takim samym stopniu jak obecne zalecenia NIST w zakresie algorytmów haszujących (SHA-256) i rozmiarów kluczy publicznych (RSA-2048).
• [C-1-6] NIE MOŻE umożliwiać uruchomienia urządzenia w przypadku niepowodzenia weryfikacji systemu, chyba że użytkownik mimo to wyrazi zgodę na uruchomienie urządzenia. W takim przypadku nie wolno używać danych z niezweryfikowanych bloków pamięci masowej.
• [C-1-7] NIE MOŻE zezwalać na modyfikowanie zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokuje program rozruchowy.
• [C-SR-1] Jeśli urządzenie ma wiele dyskretnych układów scalonych (np. radio, specjalistyczny procesor obrazu), Zdecydowanie ZALECANY jest proces uruchamiania każdego z tych układów, aby można było sprawdzić każdy etap podczas uruchamiania.
• [C-1-8] MUSI korzystać z pamięci, w której nie wykryto manipulacji: do przechowywania, czy program rozruchowy jest odblokowany. Dzięki temu program rozruchowy może wykryć, czy w pamięci urządzenia z Androidem ktoś manipulował.
• [C-1-9] MUSI poprosić użytkownika podczas korzystania z urządzenia i wymagać fizycznego potwierdzenia przed zezwoleniem na przejście z trybu blokady programu rozruchowego na tryb odblokowany przez program rozruchowy.
• [C-1-10] MUSI wdrożyć ochronę przed wycofywaniem partycji używanych przez Androida (np. podczas uruchamiania, partycje systemowe) i przechowywać metadane użyte do określenia minimalnej dopuszczalnej wersji systemu operacyjnego w pamięci, w trakcie której doszło do modyfikacji.
• [C-1-11] MUSI bezpiecznie usuwać wszystkie dane użytkownika podczas odblokowywania i blokowania programu rozruchowego, zgodnie z normą 9.12. Usunięcie danych” (w tym partycja danych użytkownika i wszelkie obszary NVRAM).
• [C-SR-2] Zdecydowanie ZALECANE jest sprawdzanie wszystkich plików APK aplikacji z podwyższonymi uprawnieniami, które zawierają łańcuch zaufania zakorzenionego w partycjach chronionych przez funkcję weryfikacji podczas uruchamiania.
• [C-SR-3] Zdecydowanie ZALECANE jest sprawdzanie wszystkich artefaktów wykonywalnych wczytywanych przez aplikację z podwyższonymi uprawnieniami spoza pliku APK (takiego jak kod ładowany dynamicznie lub skompilowany) przed ich wykonaniem lub Zdecydowanie ZALECANE jest ich niewykonanie.
• NALEŻY wdrożyć ochronę przed wycofywaniem dowolnego komponentu z trwałym oprogramowaniem układowym (np.modemem, aparatem) i używać pamięci masowej na potrzeby weryfikacji do momentu manipulacji. Dane te są używane do określania minimalnej dopuszczalnej wersji.

Jeśli implementacje urządzeń zostały już wdrożone bez obsługi języków od C-1-8 do C-1-11 we wcześniejszej wersji Androida i nie mogą dodać świadczenia tych wymagań w ramach aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z tych wymagań.

Nadrzędny projekt Android Open Source zapewnia preferowaną implementację tej funkcji w repozytorium external/avb/, które można zintegrować z programem rozruchowym służącym do wczytywania Androida.

Implementacje na urządzeniach:

• [C-0-3] MUSI obsługiwać weryfikację kryptograficzną zawartości pliku w zaufanym kluczu bez odczytywania całego pliku.
• [C-0-4] NIE MOŻE zezwalać na realizację żądań odczytu chronionego pliku, gdy odczytywana treść nie jest weryfikowana za pomocą zaufanego klucza.

Jeśli implementacje urządzeń zostały już uruchomione bez możliwości weryfikacji zawartości pliku pod kątem zaufanego klucza we wcześniejszej wersji Androida i nie mogą dodać obsługi tej funkcji w ramach aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z tego wymogu. Nadrzędny projekt Android Open Source zapewnia preferowaną implementację tej funkcji opartą na funkcji fs-verity jądra systemu Linux.

Implementacje na urządzeniach:

• [C-SR-4] Zdecydowanie ZALECANE jest obsługa interfejsu Android Protected Confirmation API.

Jeśli implementacje urządzeń obsługują interfejs Android Protected Confirmation API:

• [C-3-1] MUSI zgłosić true w przypadku interfejsu API ConfirmationPrompt.isSupported().

• [C-3-2] MUSI mieć pewność, że kod uruchomiony w systemie operacyjnym Android, w tym jej jądro, złośliwy lub inny, nie może wygenerować pozytywnej odpowiedzi bez interakcji użytkownika.

• [C-3-3] MUSI upewnić się, że użytkownik jest w stanie sprawdzić i zatwierdzić wyświetlony komunikat, nawet jeśli system operacyjny Android i jego jądro zostaną przejęte.

9.11. Klucze i dane uwierzytelniające

System magazynu kluczy Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i wykorzystywanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub interfejsu Keystore API. Implementacje na urządzeniach:

• [C-0-1] MUSI umożliwiać zaimportowanie lub wygenerowanie co najmniej 8192 kluczy.
• [C-0-2] Uwierzytelnianie ekranu blokady MUSI wdrożyć odstęp czasu między nieudanymi próbami. Gdy liczba nieudanych prób wynosi n, przedział czasu MUSI wynosić co najmniej 30 sekund w przypadku wartości 9 < n < 30. W przypadku n > 29 wartość przedziału czasu MUSI wynosić co najmniej 30*2^floor(n-30)/10)) s lub co najmniej 24 godziny, w zależności od tego, która wartość jest mniejsza.
• NIE POWINNO ograniczać liczby kluczy, które można wygenerować

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady,:

• [C-1-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [C-1-2] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1 i SHA-2, aby zapewnić prawidłową obsługę algorytmów obsługiwanych przez system magazynu kluczy Androida w obszarze, który jest bezpiecznie odizolowany od kodu działającego w jądrze lub nowszych. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, które umożliwiają jądrom lub kodom przestrzeni użytkownika dostęp do wewnętrznego stanu odizolowanego środowiska, w tym do DMA. Wycofany projekt Android Open Source Project (AOSP) spełnia to wymaganie dzięki implementacji Trusty, ale alternatywnym rozwiązaniem jest rozwiązanie oparte na technologii ARM TrustZone lub sprawdzone i sprawdzone przez firmę zewnętrzną wdrożenie izolacji opartej na hipernadzorcy.
• [C-1-3] MUSI przeprowadzić uwierzytelnianie blokady ekranu w odizolowanym środowisku wykonawczym i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem dopiero po pomyślnym uwierzytelnieniu. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób, który umożliwia uwierzytelnianie przy zablokowanym ekranie tylko w przypadku izolowanego środowiska wykonawczego. Nadrzędny projekt Android Open Source udostępnia platformę Gatekeeper Hardware Abstraction Layer (HAL) i Trusty, które można wykorzystać w celu spełnienia tego wymogu.
• [C-1-4] MUSI obsługiwać atest klucza, gdy klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane z użyciem bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane przez wystarczającą liczbę urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest korzystanie z tego samego klucza atestu,chyba że zostanie utworzone co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowany zostanie więcej niż 100 tys. jednostek SKU, dla każdej z nich może zostać użyty inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona we wcześniejszej wersji Androida, urządzenie zostanie zwolnione z konieczności posiadania magazynu kluczy w odizolowanym środowisku wykonawczym oraz obsługi atestu klucza, chyba że zadeklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy działającej w odizolowanym środowisku wykonawczym.

• [C-1-5] MUSI umożliwiać użytkownikowi wybranie limitu czasu uśpienia, po którym następuje przejście ze stanu odblokowanego w zablokowany, przy minimalnym dozwolonym czasie oczekiwania do 15 sekund. W przypadku urządzeń motoryzacyjnych, które blokują ekran po wyłączeniu jednostki głównej lub przełączeniu użytkownika, MOGĄ NIE mieć konfiguracji czasu uśpienia.
• [C-1-6] MUSI obsługiwać IKeymasterDevice 4.0, IKeymasterDevice 4.1 lub IKeyMintDevice w wersji 1.
• [C-SR-1] Zdecydowanie ZALECANY jest obsługa IKeyMintDevice w wersji 1.

9.11.1. Bezpieczny ekran blokady i uwierzytelnianie

Implementacja AOSP jest oparta na wielopoziomowym modelu uwierzytelniania, w którym podstawowe uwierzytelnianie oparte na fabryce wiedzy może być poparte albo dodatkowymi, silnymi danymi biometrycznymi, albo słabszymi modalnościami trzeciorzędnymi.

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest ustawienie tylko jednej z tych metod jako podstawowej metody uwierzytelniania:
  • Numeryczny kod PIN
  • Hasło alfanumeryczne
  • Wzór przesuwania na siatce zawierającej dokładnie 3 x 3 kropki

Pamiętaj, że w tym dokumencie powyższe metody uwierzytelniania są określane jako zalecane główne metody uwierzytelniania.

Jeśli implementacje urządzeń dodają lub zmieniają zalecane główne metody uwierzytelniania i używają nowej metody uwierzytelniania jako bezpiecznej metody blokowania ekranu, nowa metoda uwierzytelniania:

• [C-2-1] MUSI być metodą uwierzytelniania użytkownika opisaną w artykule Wymaganie uwierzytelniania użytkowników przed użyciem klucza.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania w celu odblokowywania ekranu blokady na podstawie znanego obiektu tajnego i używają nowej metody uwierzytelniania, która umożliwia blokowanie ekranu:

• [C-3-1] Entropia najkrótszej dozwolonej długości danych wejściowych MUSI być większa niż 10 bitów.
• [C-3-2] Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18 bitów.
• [C-3-3] Nowa metoda uwierzytelniania NIE MOŻE zastępować żadnej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) wdrożonej i podanej w AOSP.
• [C-3-4] Nowa metoda uwierzytelniania MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła wymagania dotyczące haseł za pomocą metody DevicePolicyManager.setRequiredPasswordComplexity() o bardziej restrykcyjnej stałej złożoności niż PASSWORD_COMPL zeExitY_NONE lub metodą DevicePolicyManager.setPasswordQuality(), która jest bardziej restrykcyjna niż metoda stała.
• [C-3-5] Nowe metody uwierzytelniania MUSZĄ korzystać z zalecanych podstawowych metod uwierzytelniania (np. kodem PIN, wzorem, hasłem) co 72 godziny lub rzadziej LUB wyraźnie informować użytkownika, że w celu ochrony prywatności jego danych nie zostanie utworzona kopia zapasowa niektórych danych.

Jeśli implementacje urządzeń dodają lub zmieniają zalecane główne metody uwierzytelniania w celu odblokowywania ekranu blokady i korzystają z 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 (wcześniej Wygoda).
• [C-4-2] MUSI mieć mechanizm awaryjny, aby użyć jednej z zalecanych podstawowych metod uwierzytelniania, która opiera się na znanym obiekcie tajnym.
• [C-4-3] MUSI być wyłączona i zezwolić na zalecane uwierzytelnianie podstawowe w celu odblokowania ekranu tylko wtedy, gdy aplikacja kontrolera zasad urządzeń (DPC) ustawi zasadę funkcji blokady klawiszy, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures()) z dowolnymi powiązanymi flagami biometrycznymi (np. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE lub KEYGUARD_DISABLE_IRIS).

Jeśli metody uwierzytelniania biometrycznego nie spełniają wymagań klasy 3 (wcześniej Strong) opisanych w sekcji 7.3.10:

• [C-5-1] Metody MUSZĄ być wyłączone, jeśli aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasadę jakości wymagań dotyczących haseł za pomocą funkcji DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjnym zasobnikiem złożoności niż PASSWORD_COMPLEXITY_LOW lub metodą DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Użytkownik MUSI otrzymać prośbę o wykonanie zalecanego podstawowego uwierzytelniania (np. kod PIN, wzór, hasło) zgodnie z zasadami [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 poniżej, zaczynające się od litery C-8.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania na potrzeby odblokowywania ekranu blokady, a nowa metoda uwierzytelniania jest oparta na tokenie fizycznym lub lokalizacji:

• [C-6-1] MUSZĄ one mieć mechanizm awaryjny, aby używać jednej z zalecanych podstawowych metod uwierzytelniania, która opiera się na znanym obiekcie tajnym, i spełniać wymagania traktowania jako bezpiecznego ekranu blokady.
• [C-6-2] Nowa metoda MUSI być wyłączona i umożliwiać odblokowywanie ekranu jednej z zalecanych podstawowych metod uwierzytelniania tylko wtedy, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasadę:
  • Metoda DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
  • Metoda DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakością niż PASSWORD_QUALITY_NONE.
  • Metoda DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjnym zasobnikiem złożoności niż PASSWORD_COMPLEXITY_NONE.
• [C-6-3] Użytkownik MUSI otrzymywać potwierdzenia użycia jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) co najmniej raz na 4 godziny.
• [C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI być zgodna z ograniczeniami wymienionymi w punkcie C-8 poniżej.

Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej 1 agenta zaufania, który wdraża systemowy interfejs API TrustAgentService:

• [C-7-1] MUSI być wyraźnie oznaczony w menu ustawień i na ekranie blokady, gdy blokada urządzenia jest odroczona lub może zostać odblokowana przez agenta zaufania. Na przykład AOSP spełnia to wymaganie, wyświetlając opis tekstowy ustawień „Automatycznie zablokuj” i „Błyskawiczne zablokowanie przycisku zasilania” w menu ustawień oraz wyraźną ikonę na ekranie blokady.
• [C-7-2] MUSI respektować i w pełni implementować wszystkie interfejsy API agenta zaufania w klasie DevicePolicyManager, takie jak stała KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NIE MOŻE w pełni wdrażać funkcji TrustAgentService.addEscrowToken() na urządzeniu używanym jako główne urządzenie osobiste (np. przenośne), ale MOŻE w pełni wdrożyć tę funkcję na urządzeniach, które są zwykle używane (np. na urządzeniach z Androidem Television lub Automotive).
• [C-7-4] MUSI szyfrować wszystkie przechowywane tokeny dodane przez TrustAgentService.addEscrowToken().
• [C-7-5] NIE MOŻE przechowywać klucza szyfrowania ani tokena depozytowego na tym samym urządzeniu, na którym jest używany klucz. Przykładowo klucz zapisany na telefonie może służyć do odblokowywania konta użytkownika na telewizorze. W przypadku urządzeń motoryzacyjnych token depozytowy nie może być przechowywany w żadnej części pojazdu.
• [C-7-6] MUSI poinformować użytkownika o wpływie na bezpieczeństwo przed włączeniem tokena depozytowego na potrzeby odszyfrowywania magazynu danych.
• [C-7-7] MUSI mieć mechanizm awaryjny, aby użyć jednej z zalecanych podstawowych metod uwierzytelniania.
• [C-7-8] Użytkownik MUSI otrzymywać potwierdzenia użycia jednej z zalecanych podstawowych metod uwierzytelniania (np.kodu PIN, wzoru, hasła) co najmniej raz na 72 godziny lub częściej, chyba że zagraża to bezpieczeństwu użytkownika (np. może rozpraszać uwagę kierowcy).
• [C-7-9] Użytkownik MUSI uzyskać dostęp do jednej z zalecanych podstawowych metod uwierzytelniania (np.kodu PIN, wzoru, hasła) opisanej w sekcjach [C-1-7] i [C-1-8] w sekcji 7.3.10, chyba że obawiasz się o bezpieczeństwo użytkownika (np. rozpraszanie uwagi kierowcy).
• [C-7-10] NIE MOŻE być traktowane jako bezpieczny ekran blokady i MUSI spełniać wymagania opisane poniżej w punkcie C-8.
• [C-7-11] NIE MOŻE zezwalać agentom zaufania na podstawowych urządzeniach osobistych (np. urządzeniach przenośnych) na odblokowywanie urządzenia. Za pomocą tych urządzeń nie wolno za ich pomocą utrzymywać odblokowanego urządzenia w stanie odblokowanym przez maksymalnie 4 godziny. Domyślna implementacja TrustManagerService w AOSP spełnia to wymaganie.
• [C-7-12] MUSI używać bezpiecznego kryptograficznego kanału komunikacyjnego (np.UKEY2), aby przekazać token depozytowy z urządzenia pamięci masowej do urządzenia docelowego.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania, aby odblokować ekran blokady, który nie jest bezpiecznym ekranem blokady, zgodnie z opisem powyżej, i korzystanie z nowej metody uwierzytelniania do odblokowywania ekranu blokady:

• [C-8-1] Nowa metoda MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_NONE lub za pomocą metody DevicePolicyManager.setRequiredPasswordComplexity() o bardziej restrykcyjnej stałej złożoności niż „PASSWORD_COMPLExitY_NONE”.
• [C-8-2] NIE MOŻE resetować liczników czasu wygaśnięcia haseł ustawionych przez usługę DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] NIE MOGĄ udostępniać interfejsu API do określania stanu blokady aplikacji innych firm.

Jeśli implementacje urządzeń obsługują osobne stany zasilania wyświetlacza za pomocą funkcji DeviceStateManager ORAZ umożliwiają obsługę oddzielnych stanów blokady ekranu przez KeyguardDisplayManager, zapewnia to te możliwości:

• [C-SR-2] Zdecydowanie ZALECANE jest użycie urządzenia spełniającego wymagania dotyczące danych logowania określonych w artykule 9.11.1 lub urządzenia biometrycznego spełniającego wymagania klasy 1 co najmniej klasy 1 zdefiniowane w artykule 7.3.10 w celu umożliwienia niezależnego odblokowywania go od domyślnego wyświetlacza urządzenia.
• [C-SR-3] Zdecydowanie ZALECANE jest ograniczenie odblokowywania osobnego wyświetlacza przez określony czas oczekiwania.
• [C-SR-4] Zdecydowanie ZALECANE są umożliwienie użytkownikom globalnego blokowania wszystkich wyświetlaczy przez blokadę ekranu głównego urządzenia przenośnego.

9.11.2. StrongBox,

System magazynu kluczy Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w dedykowanym bezpiecznym procesorze oraz w izolowanym środowisku wykonawczym opisanym powyżej. Taki bezpieczny procesor nazywa się „StrongBox”. Poniższe wymagania określają wymagania, jakie urządzenie musi spełniać, aby zostało sklasyfikowane jako StrongBox.

Implementacje urządzeń, które mają dedykowany bezpieczny procesor:

• [C-SR-1] Zdecydowanie ZALECANE są wsparcie dla StrongBox. StrongBox prawdopodobnie stanie się wymagany w kolejnej wersji.

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

• [C-1-1] MUSI zadeklarować FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] MUSI zapewniać specjalny bezpieczny sprzęt, który służy do przechowywania kluczy i zabezpieczania uwierzytelniania użytkowników. Dedykowany bezpieczny sprzęt może być też używany do innych celów.

• [C-1-3] MUSI mieć dyskretny procesor, który nie współdzieli pamięci podręcznej, pamięci DRAM, współprocesorów ani innych podstawowych zasobów z procesorem aplikacji.

• [C-1-4] MUSI upewnić się, że żadne urządzenia peryferyjne udostępniane punktowi dostępu nie mogą w żaden sposób zmieniać przetwarzania StrongBox ani uzyskiwać z niego żadnych informacji. AP MOŻE wyłączyć lub zablokować dostęp do StrongBox.

• [C-1-5] MUSI mieć wewnętrzny zegar z odpowiednią dokładnością (+-10%), odporny na manipulacje ze strony punktu dostępu.

• [C-1-6] MUSI mieć prawdziwy generator liczb losowych, który generuje równomiernie rozłożone i nieprzewidywalne dane wyjściowe.

• [C-1-7] MUSI być odporny na manipulacje, w tym na przenikanie fizyczne i zakłócenia.

• [C-1-8] MUSI mieć opór w obrębie kanału, w tym na wyciek informacji przez zasilanie, czas, promieniowanie elektromagnetyczne i boczne kanały promieniowania cieplnego.

• [C-1-9] MUSI mieć bezpieczne miejsce na dane, które zapewnia poufność, integralność, autentyczność, spójność i aktualność treści. Pamięć NIE MOŻE być odczytywana ani zmieniana, chyba że jest to dozwolone przez interfejsy API StrongBox.

• Aby sprawdzić zgodność z zasadami od [C-1-3] do [C-1-9], wdrożenia na urządzeniach:

  • [C-1-10] MUSI zawierać sprzęt certyfikowany pod kątem zgodności z profilem bezpiecznego IC (BSI-CC-PP-0084-2014) lub oceniony przez akredytowane w całym kraju laboratorium badawcze, które przeprowadza ocenę luk w zabezpieczeniach o wysokim potencjale ataku zgodnie z wytycznymi Common Criteria obejmuje zastosowanie Potencjału ataku na karty Smartcard.
  • [C-1-11] MUSI zawierać oprogramowanie oceniane przez akredytowane w kraju laboratorium badawcze, które uwzględnia ocenę luk w zabezpieczeniach o wysokim potencjale ataku zgodnie z zasadą Common Criteria obejmuje zastosowanie potencjału ataku z kart Smartcard (Common Criteria).
  • [C-SR-2] Zdecydowanie ZALECANE jest dodanie sprzętu ocenianego za pomocą celu zabezpieczeń, Evaluation Assurance Level 5 (EAL) 5 wzbogaconego przez AVA_VAN.5. Certyfikat EAL 5 prawdopodobnie będzie wymagany w kolejnej wersji.

• [C-SR-3] Zdecydowanie ZALECANE jest zapewnienie odporności na atak osób wtajemniczonych (IAR), co oznacza, że osoba wtajemniczona z dostępem do kluczy podpisywania oprogramowania nie może tworzyć oprogramowania, które powoduje wyciek obiektów tajnych przez StrongBox, ominięcie funkcjonalnych wymagań bezpieczeństwa lub w inny sposób umożliwia dostęp do poufnych danych użytkownika. Zalecanym sposobem implementacji IAR jest zezwolenie na aktualizacje oprogramowania tylko wtedy, gdy główne hasło użytkownika jest podane za pomocą interfejsu IAuthSecret HAL.

9.11.3 Dane logowania

System tożsamości tożsamości jest zdefiniowany i osiągany przez wdrożenie wszystkich interfejsów API w pakiecie android.security.identity.*. Te interfejsy API pozwalają deweloperom aplikacji na przechowywanie i pobieranie dokumentów tożsamości użytkowników. Implementacje na urządzeniach:

• Zdecydowanie ZALECANE jest wdrożenie systemu danych uwierzytelniających tożsamość [C-SR-1].

Jeśli implementacje urządzeń implementują system danych logowania tożsamości:

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

• [C-1-2] MUSI wdrożyć system danych logowania tożsamości (np. interfejsy API android.security.identity.*) za pomocą kodu komunikującego się z zaufaną aplikacją w obszarze, który jest bezpiecznie odizolowany od kodu działającego w jądrze i nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, dzięki którym jądro lub kod przestrzeni użytkownika mogą uzyskiwać dostęp do wewnętrznego stanu izolowanego środowiska, w tym do DMA.

• [C-1-3] Operacje kryptograficzne niezbędne do wdrożenia systemu danych uwierzytelniających tożsamości (np. interfejsów API android.security.identity.*) MUSZĄ być wykonywane w całości w zaufanej aplikacji, a materiał klucza prywatnego MUSI nigdy nie opuszczać osobnego środowiska wykonawczego, 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, by nie wpływało to na jej właściwości zabezpieczeń (np. dane logowania nie są udostępniane, jeśli nie są spełnione warunki kontroli dostępu, nie można tworzyć adresów MAC dla dowolnych danych), nawet jeśli Android działa wadliwie lub przejmie zabezpieczenia.

9.12. Usuwanie danych

Wszystkie implementacje na urządzeniach:

• [C-0-1] MUSI udostępniać użytkownikom mechanizm przywracania danych fabrycznych.
• [C-0-2] Podczas przywracania danych fabrycznych MUSI usunąć wszystkie dane z systemu plików danych użytkownika.
• [C-0-3] MUSI usuwać dane w sposób zgodny z odpowiednimi standardami branżowymi, takimi jak NIST SP800-88 podczas przywracania danych fabrycznych.
• [C-0-4] MUSI aktywować powyższy proces „przywracania danych fabrycznych” po wywołaniu interfejsu API DevicePolicyManager.wipeData() przez aplikację kontrolera zasad dotyczących urządzeń głównego użytkownika.
• MOŻE udostępnić opcję szybkiego czyszczenia danych, która przeprowadza tylko logiczne usuwanie danych.

9.13. Tryb bezpiecznego rozruchu

Android zapewnia tryb bezpiecznego rozruchu, który umożliwia użytkownikom uruchomienie w trybie, w którym mogą działać tylko wstępnie zainstalowane aplikacje systemowe, a wszystkie aplikacje innych firm są wyłączone. Ten tryb, nazywany „trybem bezpiecznego rozruchu”, umożliwia użytkownikowi odinstalowywanie potencjalnie szkodliwych aplikacji innych firm.

Implementacje urządzeń:

• [C-SR-1] Zdecydowanie ZALECANE jest wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacje urządzeń mają włączony tryb bezpiecznego rozruchu:

• [C-1-1] MUSI umożliwiać użytkownikowi przejście w tryb bezpiecznego rozruchu w taki sposób, aby aplikacje innych firm zainstalowane na urządzeniu nie zakłócały jego działania, z wyjątkiem sytuacji, gdy aplikacja innej firmy jest kontrolerem zasad dotyczących urządzeń i ma ustawioną flagę UserManager.DISALLOW_SAFE_BOOT na wartość true (prawda).

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

• Trzeba udostępnić użytkownikowi opcję włączenia trybu bezpiecznego rozruchu z menu rozruchu przy użyciu przepływu pracy innego niż zwykły rozruch.

9.14. Izolacja systemu samochodowego

Oczekuje się, że urządzenia z Androidem Automotive będą wymieniać dane z najważniejszymi podsystemami pojazdów, wykorzystując interfejs HAL pojazdu do wysyłania i odbierania wiadomości w sieciach pojazdu, takich jak magistrala CAN.

Wymianę danych można zabezpieczyć, wdrażając funkcje zabezpieczeń poniżej warstw platformy Androida, aby zapobiegać złośliwej lub niezamierzonej interakcji z tymi podsystemami.

9.15. Abonamenty

„Abonamenty” to szczegóły abonamentu oferowanego przez operatora komórkowego na stronie SubscriptionManager.setSubscriptionPlans().

Wszystkie implementacje na urządzeniach:

• [C-0-1] TRZEBA zwracać abonamentów tylko do aplikacji operatora komórkowego, która je udostępniła.
• [C-0-2] NIE MOŻESZ zdalnie przesyłać ani tworzyć kopii zapasowych abonamentów.
• [C-0-3] MUSI zezwalać na zastąpienia takie jak SubscriptionManager.setSubscriptionOverrideCongested() tylko w aplikacji operatora komórkowego, która obecnie dostarcza ważne abonamenty.

9.16. Migracja danych aplikacji

Jeśli implementacje urządzeń umożliwiają migrację danych z jednego urządzenia na inne i nie ograniczają kopiowanych danych aplikacji do danych skonfigurowanych przez dewelopera aplikacji w pliku manifestu za pomocą atrybutu android:fullBackupContent, oznacza to, że:

• [C-1-1] NIE MOŻE inicjować przesyłania danych aplikacji z urządzeń, na których użytkownik nie ustawił podstawowego uwierzytelniania, jak opisano w artykule 9.11.1 Bezpieczny ekran blokady i uwierzytelnianie.
• [C-1-2] MUSI bezpiecznie potwierdzić podstawowe uwierzytelnianie na urządzeniu źródłowym i potwierdzić zamiar skopiowania danych z urządzenia źródłowego przed ich przesłaniem.
• [C-1-3] MUSI używać atestu klucza bezpieczeństwa, aby mieć pewność, że zarówno urządzenie źródłowe, jak i urządzenie docelowe w ramach migracji między urządzeniami są prawidłowe i mają zablokowany program rozruchowy.
• [C-1-4] MUSI migrować dane aplikacji tylko do tej samej aplikacji na urządzeniu docelowym, o tej samej nazwie pakietu ORAZ certyfikacie podpisywania.
• [C-1-5] MUSI zawierać w menu ustawień informację o tym, że dane z urządzenia źródłowego zostały przeniesione przez migrację danych z urządzenia na urządzenie. Użytkownik NIE POWINNO mieć możliwości usunięcia tego oznaczenia.

10. Testowanie zgodności oprogramowania

Implementacje na urządzeniach MUSZĄ przejść wszystkie testy opisane w tej sekcji. Należy jednak pamiętać, że żaden pakiet testów oprogramowania nie jest w pełni wszechstronny. Z tego powodu Zdecydowanie ZALECANE jest wprowadzenie minimalnej liczby zmian w plikach referencyjnych i implementacji Androida w ramach projektu Android Open Source Project. Zminimalizujesz w ten sposób ryzyko wprowadzenia błędów, które powodują niezgodności, które wymagają przepracowywania i potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje na urządzeniach:

• [C-0-1] MUSI przejść pakiet Android Compatibility Test Suite (CTS) dostępny w projekcie Android Open Source Project, korzystając z oprogramowania dostawy zainstalowanego na urządzeniu.

• [C-0-2] MUSI zapewniać zgodność w przypadku niejasności w klasyfikacji CTS i w przypadku ponownych implementacji części referencyjnego kodu źródłowego.

Narzędzie CTS zostało zaprojektowane tak, aby działać na prawdziwym urządzeniu. Tak jak w przypadku każdego oprogramowania, narzędzie CTS może zawierać błędy. Pakiet CTS będzie prowadzony niezależnie od tej definicji zgodności, a dla Androida 12 może zostać wydanych kilka wersji.

Implementacje na urządzeniach:

• [C-0-3] MUSI przejść najnowszą wersję CTS dostępną w chwili zakończenia oprogramowania urządzenia.

• W miarę możliwości należy korzystać z implementacji referencyjnej w drzewie Android Open Source.

10.2. Weryfikator CTS

CTS Verifier wchodzi w skład pakietu Compatibility Test Suite i może być uruchamiany przez człowieka w celu testowania funkcji, których automatyczny system nie może przetestować, takich jak prawidłowe działanie kamery i czujników.

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo wykonać wszystkie odpowiednie zgłoszenia weryfikatora CTS.

Weryfikator CTS wykonuje testy obejmujące różne rodzaje sprzętu, w tym sprzęt opcjonalny.

Implementacje na urządzeniach:

• [C-0-2] MUSI przejść wszystkie testy posiadanego sprzętu. Na przykład: jeśli urządzenie ma akcelerometr, MUSI prawidłowo przeprowadzić test akcelerometru w weryfikatorze CTS.

Przypadki testowe funkcji oznaczonych w tej definicji zgodności jako opcjonalne Dokument MOŻE zostać pominięty.

• [C-0-2] Na każdym urządzeniu i każdej kompilacji MUSI działać weryfikator CTS zgodnie z opisem powyżej. Ponieważ jednak wiele kompilacji jest bardzo podobnych, osoby implementujące urządzenia nie powinny uruchamiać weryfikatora CTS w przypadku kompilacji, które różnią się tylko w prosty sposób. W szczególności dotyczy to implementacji na urządzeniach, które różnią się od tych, które przeszły weryfikację przez weryfikatora CTS tylko przy użyciu zestawu uwzględnionych języków, oznaczenia marki itp. MOGĄ pominąć test weryfikatora CTS.

11. Oprogramowanie do aktualizacji

• [C-0-1] Implementacje na urządzeniu MUSZĄ zawierać mechanizm zastępujący całe oprogramowanie systemowe. Mechanizm nie musi przeprowadzać uaktualnień w czasie rzeczywistym, czyli MOŻE być wymagane ponowne uruchomienie urządzenia. Można stosować dowolną metodę, pod warunkiem że może ona zastąpić całe oprogramowanie zainstalowane fabrycznie na urządzeniu. To wymaganie spełni na przykład każdy z poniższych sposobów:

  • „Bezprzewodowe pobieranie (OTA)” z aktualizacją offline po ponownym uruchomieniu.
  • Opcja „w tetheringu” jest aktualizowana przez USB z komputera hosta.
  • „Tryb offline” jest aktualizowany przez restartowanie i aktualizację z pliku w pamięci wymiennej.

• [C-0-2] Użyty mechanizm aktualizacji MUSI obsługiwać aktualizacje bez czyszczenia danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachować prywatne dane aplikacji i dane udostępnione przez aplikację. Pamiętaj, że starsze oprogramowanie Android ma mechanizm aktualizacji, który spełnia to wymaganie.

• [C-0-3] Cała aktualizacja MUSI być podpisana, a mechanizm aktualizacji na urządzeniu MUSI zweryfikować aktualizację i podpis pod kątem klucza publicznego zapisanego na urządzeniu.

• [C-SR-1] Zdecydowanie ZALECANE jest zaszyfrowanie aktualizacji za pomocą algorytmu SHA-256 i zweryfikowanie skrótu z kluczem publicznym za pomocą ECDSA NIST P-256.

Jeśli implementacje urządzeń obsługują połączenie danych bez pomiaru użycia danych, np. profil 802.11 lub profil Bluetooth z numerem PAN (sieć osobista), to:

• [C-1-1] MUSI obsługiwać pobieranie OTA z aktualizacją offline po ponownym uruchomieniu.

Implementacje urządzeń NALEŻY sprawdzić, czy obraz systemu jest binarnie identyczny z oczekiwanym wynikiem po aktualizacji OTA. Ten wymóg spełnia oparta na blokowych implementacja OTA w starszym projekcie Android Open Source, dodana od Androida 5.1.

Implementacje na urządzeniach MUSZĄ też obsługiwać aktualizacje systemu A/B. AOSP implementuje tę funkcję przy użyciu interfejsu HAL kontroli rozruchu.

Jeśli w implementacji urządzenia po jej wprowadzeniu na rynek zostanie wykryty błąd, ale w rozsądnym okresie przydatności usługi, co zostanie określone po konsultacji z zespołem ds. zgodności na Androidzie w celu ustalenia zgodności aplikacji innych firm:

• [C-2-1] Implementator urządzenia MUSI poprawić błąd przy użyciu 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 zainstalowana) na kontrolowanie instalowania aktualizacji systemu. Jeśli podsystem aktualizacji systemu dla urządzeń zgłasza android.software.device_admin, to:

• [C-3-1] MUSI wdrożyć działanie opisane w klasie SystemUpdatePolicy.

12. Historia zmian dokumentu

Podsumowanie zmian w definicji zgodności w tej wersji:

• Historia zmian dokumentu

Aby zobaczyć podsumowanie zmian w sekcjach dotyczących poszczególnych osób:

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

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

Zmiany są oznaczane w ten sposób:

• CDD
  Istotne zmiany w wymaganiach dotyczących zgodności.

• Dokumenty
  Zmiany kosmetyczne lub związane z wprowadzeniem.

Aby to zrobić, dołącz do adresów URL dziennika zmian parametry URL pretty=full i no-merges.

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órych Twoim zdaniem nie obejmuje dokument.