Definicja zgodności z Androidem 15

1. Wprowadzenie

W tym dokumencie opisujemy wymagania, które muszą zostać spełnione, aby urządzenie aby była zgodna z Androidem 15.

określenia „MUSI”, „NIE MOŻE”, „WYMAGANE”, „WYMAGANE”, „WOLNE”, „NIE POWINNY”, „POWINNO”, „NIE POWINNO”, „ZALECANE”, „MOŻE” i „OPCJONALNE” jest zgodny ze standardem IETF zdefiniowane w dokumencie RFC2119.

Używana w tym dokumencie „narzędzie do implementacji urządzeń” lub „implementer” jest osobą albo organizacji opracowującej rozwiązanie sprzętowo-oprogramowania z Androidem. 15. „Implementacja na urządzeniu” lub „implementacja” to tak opracowanego rozwiązania sprzętowego i programowego.

Aby urządzenie zostało uznane za zgodne z Androidem 15, implementacje MUSZĄ spełniać wymagania przedstawione w tej specyfikacji definicji, w tym wszystkich dokumentów dołączonych przez odniesienie;

Gdzie ta definicja lub testy oprogramowania opisane w sekcja 10 jest cicha, niejednoznaczna lub niekompletna, to osoba implementująca urządzenie odpowiada za dopilnowanie, zgodność z istniejącymi implementacjami.

Z tego powodu projekt Android Open Source jest zarówno referencją, jak i preferowaną implementacją Androida. Urządzenie Zdecydowanie zaleca się, aby wdrażali wyłącznie w największym możliwym stopniu na „dodatku” z kodu źródłowego dostępnego w Android Open Source. Chociaż niektóre komponenty mogą być hipotetycznie zastąpione alternatywnymi implementacjami, ZDECYDOWANIE NIE zaleca się stosuj się do tej metody, ponieważ zaliczanie testów oprogramowania co jest utrudnione. Obowiązkiem wdrażającego jest dopilnowanie, zgodność behawioralną ze standardową implementacją Androida, w tym i poza platformą Compatibility Test Suite. Niektóre elementy podstawienia i modyfikacji jest wyraźnie zabronione w tym dokumencie.

Wiele zasobów, do których prowadzą linki w tym dokumencie, pochodzi bezpośrednio lub pośrednio z pakietu SDK Androida i będzie działać tak samo jak znajdziesz w dokumentacji tego pakietu SDK. W każdym przypadku, gdy taka zgodność Definicja lub zestaw testów zgodności nie zgadza się z pakietem SDK dokumentacja pakietu SDK jest uznawana za miarodajną. Wszystkie techniczne informacje podane w zasobach wskazanych w tym dokumencie są które są uwzględnione w 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 sekcji 2 jest przeznaczonego na konkretne typy urządzeń.

wszystkie inne wymagania, które obowiązują uniwersalnie na każdym urządzeniu z Androidem; implementacji są wymienione w sekcjach po Sekcji 2. Wymagania te noszą się jako „Podstawowe wymagania”. w tym dokumencie.

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, za 1 miejsce zostanie przypisana wartość 1 , a liczba zwiększa się o 1 w tej samej sekcji i urządzenia tego samego typu.
• Identyfikator wymagania
  • Ten identyfikator rozpoczyna się od 1 i zwiększa o 1 w tej samej sekcji oraz taki sam warunek.

1.1.3 Identyfikator wymagania w sekcji 2

Identyfikatory wymagań w sekcji 2 składają się z 2 części. Pierwszy odpowiada identyfikatorowi sekcji opisanym powyżej. Druga część określa format i wymagania dotyczące konkretnego formatu.

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

• Identyfikator podany 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 stos oprogramowania, którego można używać do różnych typów urządzeń i formatów. Aby zapewnić bezpieczeństwo urządzeń, stosu oprogramowania, w tym nowego systemu operacyjnego lub alternatywnego jądra systemu ma działać w bezpiecznym środowisku zgodnie z opisem, w sekcji 9. i innych miejscach niniejszej CDD. Istnieje kilka typów urządzeń które mają względnie lepiej ugruntowany ekosystem dystrybucji aplikacji.

W tej sekcji opisano te typy urządzeń i dodatkowe wymagania oraz zalecenia dla każdego typu urządzenia.

Wszystkie implementacje urządzeń z Androidem, które nie pasują do żadnej z opisanych typy urządzeń MUSZĄ spełniać wszystkie wymagania wymienione w pozostałych sekcjach tego Definicja zgodności.

2.1 Konfiguracje urządzeń

Główne różnice w konfiguracji sprzętu w zależności od urządzenia należy zapoznać się z wymaganiami dotyczącymi konkretnego urządzenia przedstawionymi w tej sekcji.

2.2. Wymagania dotyczące urządzenia mobilnego

Urządzenie mobilne z Androidem to implementacja urządzenia z Androidem, która jest zazwyczaj używa się go w dłoni, np. odtwarzacza mp3, telefonu lub tablecie.

Implementacje na urządzeniach z Androidem są zaliczane do urządzeń mobilnych, jeśli spełniają wszystkie następujące kryteria:

• mieć źródło zasilania, które pozwala na mobilność, np. baterię.
• Mają ekran o przekątnej fizycznym w zakresie od od 4 do 8 cali.
• muszą mieć interfejs wprowadzania na ekranie dotykowym,

Dodatkowe wymagania opisane w pozostałej części tej sekcji dotyczą Androida Implementacje na urządzeniach mobilnych.

2.2.1. Sprzęt

Implementacje na urządzeniach mobilnych:

• [7.1.1.1/H-0-1] MUSI zawierać co najmniej jeden Wyświetlacz zgodny z Androidem o przekątnej co najmniej 2,2 cala na krótszej krawędzi i 3,4 cala wzdłuż dłuższej krawędzi.

• [7.1.1.3/H-SR-1] Zdecydowanie ZALECANE są umożliwiają użytkownikom zmianę rozmiaru wyświetlacza (gęstości ekranu).

• [7.1.1.1/H-0-2] MUSI obsługiwać kompozycję GPU bufory graficzne o wielkości co najmniej najwyższej rozdzielczości wyświetlacz.

• [7.1.1.1/H-0-3]* MUSI zmapować UI_MODE_NORMAL na nieprzesłonięty ekran dostępny dla aplikacji innych firm fizyczny obszar wyświetlania o przekątnej co najmniej 2,2 cala na krótszej krawędzi i 3,4 cala na dłuższej krawędzi.

• [7.1.1.3/H-0-1]* MUSI ustawiać wartość DENSITY_DEVICE_STABLE musi być o 92% lub więcej od rzeczywistej gęstości fizycznej odpowiedniego wyświetlacza.

Jeśli implementacje urządzeń mobilnych obsługują język Vulkan:

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

Jeśli implementacji na urządzeniach mobilnych zgłaszają obsługę szerokiego zakresu dynamiki, wyświetla się do Configuration.isScreenHdr() one:

• [7.1.4.5/H-1-1] MUSI reklamować wsparcie EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace i Rozszerzenia: VK_EXT_hdr_metadata.

Implementacje na urządzeniach mobilnych:

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

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

• [7.1.4.6/H-1-1] MUSI zgłaszać jako dane wyjściowe ślad protokołu Protobuf zgodny ze schematem liczników GPU i GPU Renderstagi zdefiniowane w dokumentacji Perfetto.
• [7.1.4.6/H-1-2] MUSI zgłaszać zgodne wartości dla liczników GPU urządzenia po Pakiet śledzenia licznika GPU (proto).
• [7.1.4.6/H-1-3] MUSI zgłaszać zgodne wartości dla procesów renderowania GPU urządzenia po pakiet śledzenia etapu renderowania (proto).
• [7.1.4.6/H-1-4] MUSI podawać częstotliwość GPU log śledzenia zgodnie z formatem power/gpu_frequency.

Implementacje na urządzeniach mobilnych:

• [7.1.5/H-0-1] MUSI obejmować obsługę starszych wersji tryb zgodności aplikacji wdrożony przez nadrzędną wersję systemu Android kodu źródłowego. Oznacza to, że implementacje urządzenia NIE MOGĄ zmieniać wyzwalaczy ani progi, przy których aktywowany jest tryb zgodności, i NIE MOŻE zmieniać wartości samego trybu zgodności.
• [7.2.1/H-0-1] MUSI obejmować obsługę rozwiązań innych firm aplikacje edytora metod wprowadzania (IME).
• [7.2.3/H-0-2] MUSI wysłać zarówno normalne, jak i długie naciśnięcie zdarzenie funkcji Wstecz (KEYCODE_BACK) do aplikacji na pierwszym planie. System NIE POWINNY być wykorzystywać tych zdarzeń i CAN mogą być wywoływane przez inne urządzenia z Androidem (np. sprzęt zewnętrzny klawiatura podłączona do urządzenia z Androidem).
• [7.2.3/H-0-3] Funkcja MUSI zapewniać funkcję ekranu głównego na na wszystkich wyświetlaczach zgodnych z Androidem, które mają ekran główny.
• [7.2.3/H-0-4] MUSI zapewniać funkcję Back (Wstecz) na wszystkich wyświetlaczach zgodnych z Androidem oraz funkcji Ostatnie na co najmniej jednym na wyświetlaczach zgodnych 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 wybraną przez użytkownika aplikację asystującą, czyli aplikację, która stosuje VoiceInteractionService lub działanie obsługujące 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 użycie modelu 3-osiowego. przy użyciu 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 urządzenia mobilne obejmują odbiornik GPS/GNSS i możliwość przejścia na aplikacje za pomocą funkcji android.hardware.location.gps oznacza to, że:

• [7.3.3/H-2-1] MUSI podawać wyniki pomiarów GNSS, gdy tylko nawet jeśli lokalizacja określona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
• [7.3.3/H-2-2] MUSI zgłaszać pseudozakresy i pseudozakresy GNSS w warunkach na świeżym powietrzu po określeniu lokalizacji oraz nieruchome lub poruszające się z szybkością mniejszą niż 0,2 metra na sekundę do kwadratu przyspieszenie, wystarczają do obliczenia pozycji z odległości do 20 metrów, a prędkość z dokładnością do 0,2 metra na sekundę, przez co najmniej 95% czasu.

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. do 1000 stopni na sekundę.

Implementacje urządzeń mobilnych, które umożliwiają nawiązywanie połączeń głosowych i wskazywanie, 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] Zdecydowanie ZALECANE jest obsługa czujnika pozycji. i sześć stopni swobody.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli urządzenia obsługują protokół NAN (Wi-Fi Neighbor Awareness Networking) przez deklaruję: PackageManager.FEATURE_WIFI_AWARE i lokalizację Wi-Fi (okrągły Wi-Fi Czas podróży – RTT) przez zadeklarowanie wartości PackageManager.FEATURE_WIFI_RTT, a potem:

• [7.4.2.5/H-1-1] MUSI podawać dokładne dane do w zakresie +/-1 metra przy przepustowości 160 MHz przy 68 centylu (zgodnie z obliczeniami) przy użyciu funkcji rozkładu skumulowanego) +/-2 metry przy przepustowości 80 MHz przy 68 centyl, +/-4 metry przy przepustowości 40 MHz przy 68 centylu, i +/-8 metrów przy przepustowości 20 MHz przy 68 centylu w odległości 10 MHz cm, 1 m, 3 m i 5 m, jak przedstawiono za pomocą WifiRttManager#startRanging Android API.

• [7.4.2.5/H-SR-1] Zdecydowanie ZALECANE jest zgłoszenie z dokładnością do +/-1 metra przy przepustowości 160 MHz przy 90. MHz percentyl (obliczany za pomocą funkcji rozkładu skumulowanego), +/-2 metry przy przepustowości 80 MHz przy 90 centylu, +/-4 metry przy 40 MHz przy 90. percentylu i +/-8 metrów przy przepustowości 20 MHz 90. percentyl w odległości 10 cm, jak można zaobserwować w WifiRttManager#startRanging Android API.

Zdecydowanie ZALECANE jest wykonanie kroków konfiguracji pomiaru podanych w artykule Kalibracja obecności.

Jeśli implementacje urządzeń mobilnych zadeklarują FEATURE_BLUETOOTH_LE:

• [7.4.3/H-1-3] MUSI mierzyć i kompensować Rx odsunięcie, by mediana BLE RSSI wynosiła -50 dBm +/-15 dB w odległości 1 m od wysyłającego dane w źródle ADVERTISE_TX_POWER_HIGH.
• [7.4.3/H-1-4] MUSI przeprowadzać pomiary i zrekompensować potencjalne przychody w celu zapewnienia, że mediana BLE RSSI wynosi -50 dBm +/-15 dB podczas skanowania urządzenia referencyjnego umieszczonego w odległości 1 m i nadającego sygnał na ADVERTISE_TX_POWER_HIGH

Jeśli implementacje urządzeń mobilnych obejmują aparat logiczny z listą za pomocą funkcji CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA one:

• [7.5,4/H-1-1] Domyślnie MUSI mieć normalne pole widzenia. i MUSI mieścić się w przedziale od 50 do stopni.

Implementacje na urządzeniach mobilnych:

• [7.6.1/H-0-1] MUSI zawierać co najmniej 4 GB pamięć nieulotna dostępna na prywatne dane aplikacji (zwane też partycją „/data”).
• [7.6.1/H-0-2] MUSI zwracać wartość „true” w przypadku ActivityManager.isLowRamDevice(), gdy ilość pamięci jest mniejsza niż 1 GB dla jądra i przestrzeni użytkownika.

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 , a przestrzeń użytkownika MUSI mieć co najmniej 416 MB, jeśli domyślny wyświetlacz korzysta z bufora ramki maksymalnie qHD (np. FWVGA).

• [7.6.1/H-2-1] Pamięć dostępna dla jądra a przestrzeń użytkownika MUSI mieć co najmniej 592 MB, jeśli domyślny wyświetlacz korzysta z framebuffer maksymalnie HD+ (np. HD, WSVGA).

• [7.6.1/H-3-1] Pamięć dostępna dla jądra a przestrzeń użytkownika MUSI mieć co najmniej 896 MB, jeśli domyślny wyświetlacz korzysta z framebuffer maksymalnie FHD (np. WSXGA+).

• [7.6.1/H-4-1] Pamięć dostępna dla jądra a przestrzeń użytkownika MUSI mieć co najmniej 1344 MB, jeśli domyślny wyświetlacz 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] Pamięć dostępna dla jądra a przestrzeń użytkownika MUSI musi wynosić co najmniej 816 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora ramki do na qHD (np. FWVGA).

• [7.6.1/H-6-1] Pamięć dostępna dla jądra a przestrzeń użytkowników MUSI mieć co najmniej 944 MB, jeśli domyślny wyświetlacz korzysta z buforowania klatek o rozdzielczości do HD+ (np. HD, WSVGA).

• [7.6.1/H-7-1] Pamięć dostępna dla jądra a przestrzeń użytkowników MUSI mieć co najmniej 1280 MB, jeśli domyślny wyświetlacz obsługuje rozdzielczość bufora klatek do FHD. (np. WSXGA+).

• [7.6.1/H-8-1] Pamięć dostępna dla jądra a przestrzeń użytkowników MUSI mieć co najmniej 1824 MB, jeśli wyświetlacz domyślny korzysta z bufora klatek o rozdzielczości do QHD. (np. QWXGA).

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do dostępna pamięć (oprócz pamięci już przeznaczonej dla sprzętu), komponenty takie jak radio czy wideo, które nie są i większą kontrolę nad implementacją urządzeń.

jeśli wdrożenia na urządzeniach mobilnych obejmują mniej niż 1 GB pamięci; dla jądra i przestrzeni użytkownika:

• [7.6.1/H-9-1] MUSI zadeklarować flagę funkcji android.hardware.ram.low.
• [7.6.1/H-9-2] MUSI zawierać co najmniej 1,1 GB pamięć nieulotna na potrzeby aplikacji prywatne dane (zwane też partycją „/data”).

jeśli wdrożenia na urządzeniach mobilnych obejmują więcej niż 1 GB dostępnej pamięci; w jądrze i przestrzeni użytkownika:

• [7.6.1/H-10-1] MUSI zawierać co najmniej 4 GB pamięć nieulotna dostępna dla prywatne dane aplikacji (inaczej partycja „/data”).
• NALEŻY zadeklarować flagę funkcji android.hardware.ram.normal.

Jeśli implementacje na urządzeniach mobilnych obejmują co najmniej 2 GB i mniej niż 4 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

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

Jeśli urządzenia mobilne zawierają mniej niż 2 GB pamięci dostępnej dla jądro i przestrzeń użytkownika:

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

Implementacje na urządzeniach mobilnych:

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

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli urządzenia mobilne są wyposażone w port USB obsługujący tryb hosta, one:

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

Czy implementacje urządzeń mobilnych są w stanie spełnić wszystkie wymagania wymagania dotyczące trybu VR i obejmują obsługę tego trybu:

• [7.9.1/H-1-1] MUSI zadeklarować android.hardware.vr.high_performance flaga funkcji.
• [7.9.1/H-1-2] MUSI zawierać aplikację implementuję tagi android.service.vr.VrListenerService, które można włączyć przez VR aplikacji za pośrednictwem android.app.Activity#setVrModeEnabled.

Jeśli implementacje urządzeń mobilnych obejmują co najmniej jeden port USB-C na hoście i wdrożenia (klasa audio USB), a także wymagania art. 7.7.2:

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

Funkcja	Odwzorowania	Kontekst	Działanie
A	Strona o wykorzystaniu HID: 0x0C Użycie HID: 0x0CD Klucz jądra: KEY_PLAYPAUSE Klucz Androida: KEYCODE_MEDIA_PLAY_PAUSE	Odtwarzanie multimediów	Wejście: krótkie naciśnięcie Dane wyjściowe: odtwarzanie lub wstrzymywanie.
			Wejście: przytrzymaj Wyniki: Uruchom polecenie głosowe Wysłane: android.speech.action.VOICE_SEARCH_HANDS_FREE, jeśli urządzenie jest zablokowany lub wyłączony jest jego ekran. Wysłane W innym przypadku: android.speech.RecognizerIntent.ACTION_WEB_SEARCH
		Połączenie przychodzące	Wejście: krótkie naciśnięcie Dane wyjściowe: Odbierz połączenie.
			Wejście: przytrzymaj Wyniki: Odrzuć połączenie
		Trwa rozmowa	Wejście: krótkie naciśnięcie Wyniki: Zakończ połączenie
			Wejście: przytrzymaj Wyjście: wycisz lub wyłącz wyciszenie mikrofonu.
B	Strona o wykorzystaniu HID: 0x0C Wykorzystanie HID: 0x0E9 Klucz jądra: KEY_VOLUMEUP Klucz 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 systemu.
C	Strona o wykorzystaniu HID: 0x0C Wykorzystanie HID: 0x0EA Klucz jądra: KEY_VOLUMEDOWN Klucz Androida: VOLUME_DOWN	Odtwarzanie multimediów, rozmowa trwa	Wejście: krótkie lub długie naciśnięcie Wyjście: zmniejsza głośność systemu lub zestawu słuchawkowego.
D	Strona o wykorzystaniu HID: 0x0C Wykorzystanie HID: 0x0CF Klucz jądra: KEY_VOICECOMMAND Klucz Androida: KEYCODE_VOICE_ASSIST	Wszystkie. Może zostać aktywowany w każdej instancji.	Wejście: krótkie lub długie naciśnięcie Wyniki: Uruchom polecenie głosowe.

• [7.8.2.2/H-1-2] MUSI wywołać funkcję ACTION_HEADSET_PLUG tylko po podłączeniu wtyczki, ale dopiero po połączeniu interfejsów audio USB i punktów końcowych zostały prawidłowo wyliczone, by zidentyfikować typ podłączonego terminala.

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

• [7.8.2.2/H-2-1] MUSI przekazywać intencję ACTION_HEADSET_PLUG za pomocą „mikrofon” dodatkowe ustawienie na 0.

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

• [7.8.2.2/H-3-1] MUSI przekazywać intencję ACTION_HEADSET_PLUG za pomocą „mikrofon” dodatkowe ustawienie ma wartość 1.

Gdy wywoływana jest funkcja API AudioManager.getDevices(), gdy urządzenie peryferyjne USB jest Połączono:

• [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 audio USB to 0x0302.

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

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

• [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 audio USB to 0x603.

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

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

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

• [7.8.2.2/H-SR-1] Zdecydowanie ZALECANE w przypadku połączenia Urządzenie peryferyjne USB-C audio, służące do wyliczania deskryptorów USB, typów terminali i intencji transmisji ACTION_HEADSET_PLUG w czasie krótszym niż 1000 milisekund.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Liniowy mechanizm rezonansowy (LRA) to jednomasowy system sprężyn częstotliwość rezonansowa dominującej, przy której masa przekłada się w kierunku pożądany ruch.

Jeśli implementacje urządzeń mobilnych obejmują co najmniej jeden typ ogólnego przeznaczenia 7.10 rezonansu rezonansowego.

• [7.10/H] NALEŻY umieścić urządzenie wykonawcze w pobliżu w miejscu, w którym urządzenie jest zazwyczaj trzymane lub dotykane dłońmi.

• [7,10/godz.] MUSISZ przesunąć element uruchamiający haptyczny na osi X (od lewej do prawej) w naturalnej orientacji urządzenia.

Jeśli implementacje urządzeń mobilnych mają ogólny cel jest to urządzenie uruchamiające rezonans haptyczny z osią X. Umożliwia ono:

• [7,10/godz.] Częstotliwość rezonansowa jednostki LRA na osi X powinna być mniejsza niż 200 Hz.

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

• [7.10/H]* MUSI zweryfikować stan implementacji, uruchamiając android.os.Vibrator.areAllEffectsSupported() i android.os.Vibrator.arePrimitivesSupported() API.

• [7,10/H]* NALEŻY wykonać ocena jakości dla stałych haptycznych.

• [7.10/H]* MUSI zweryfikować i w razie potrzeby zaktualizować wartość zastępczą dla nieobsługiwanych elementów podstawowych, jak opisano w wskazówkami dotyczącymi implementacji dla stałych.

2.2.2. Multimedia

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać poniższe kodowanie dźwięku i formatów do dekodowania i udostępniania 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ć to kodowanie wideo formatów i udostępniać je aplikacjom innych firm:

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

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

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

2.2.3. Oprogramowanie

Implementacje na urządzeniach mobilnych:

• [3.2.3.1/H-0-1] MUSI mieć która obsługuje języki ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE i ACTION_CREATE_DOCUMENT zgodnie z intencjami opisanymi w dokumentach pakietu SDK, i zapewnić użytkownikom do danych dostawcy dokumentów za pomocą interfejsu API DocumentsProvider.
• [3.2.3.1/H-0-2]* MUSI załadować wstępnie aplikacji czy komponentów usługi z modułem obsługi intencji, np. wszystkie wzorce filtra intencji publicznych zdefiniowane przez tę aplikację intencji wymienionych tutaj.
• [3.2.3.1/H-SR-1] Są ZDECYDOWANIE ZALECANE jest wstępne wczytanie aplikacji poczty e-mail, która obsługuje działanie ACTION_SENDTO. lub ACTION_SEND lub ACTION_SEND_MULTIPLE z zamiarem wysłania e-maila.
• [3.4.1/H-0-1] MUSI zawierać pełny implementacji interfejsu android.webkit.Webview API.
• [3.4.2/H-0-1] MUSI zawierać samodzielną przeglądarkę do przeglądania internetu.
• [3.8.1/H-SR-1] Zdecydowanie ZALECANE aby zaimplementować domyślny program uruchamiający, który obsługuje przypinanie skrótów w aplikacji, widżetów i funkcji widżetów.
• [3.8.1/H-SR-2] Zdecydowanie ZALECANE aby zaimplementować domyślny program uruchamiający, który zapewnia szybki dostęp do dodatkowych, skróty dostępne w aplikacjach innych firm za pomocą menedżera ShortcutManager API.
• [3.8.1/H-SR-3] Zdecydowanie ZALECANE , aby uwzględnić domyślną aplikację uruchamiającą, która wyświetla plakietki przy ikonach aplikacji.
• [3.8.2/H-SR-1] Zdecydowanie ZALECANE z widżetami aplikacji innych firm.
• [3.8.3/H-0-1] MUSI zezwalać na aplikacje innych firm do powiadamiania użytkowników o ważnych wydarzeniach za pomocą Notification oraz NotificationManager. klas interfejsu API.
• [3.8.3/H-0-2] MUSI obsługiwać reklamy multimedialne powiadomienia.
• [3.8.3/H-0-3] MUSI obsługiwać funkcję HUD powiadomienia.
• [3.8.3/H-0-4] MUSI zawierać parametr obszar powiadomień, który daje użytkownikowi możliwość bezpośredniego kontrolowania (np. odpowiadanie na powiadomienia, odkładanie na później, odrzucanie, blokowanie) z pomocą użytkowników, takich jak przycisków poleceń lub panelu sterowania w taki sposób, w jaki został zaimplementowany w AOSP.
• [3.8.3/H-0-5] MUSI wyświetlać opcje udostępnione przez: RemoteInput.Builder setChoices() w obszarze powiadomień.
• [3.8.3/H-SR-1] Zdecydowanie ZALECANE aby wyświetlić pierwszą opcję podaną w RemoteInput.Builder setChoices() w obszarze powiadomień bez dodatkowej interakcji ze strony użytkownika.
• [3.8.3/H-SR-2] Zdecydowanie ZALECANE aby wyświetlić wszystkie opcje dostępne w RemoteInput.Builder setChoices() w obszarze powiadomień, gdy użytkownik rozwinie wszystkie powiadomienia w tej sekcji. w obszarze powiadomień.
• [3.8.3.1/H-SR-1] Zdecydowanie ZALECANE aby wyświetlić działania, dla których Notification.Action.Builder.setContextual jest ustawiony jako true (wraz z odpowiedziami wyświetlanymi przez) Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR-1] Zdecydowanie ZALECANE aby wdrożyć na urządzeniu asystenta do działania wspomagającego.

Jeśli implementacje urządzeń mobilnych obsługują powiadomienia MediaStyle one:

• [3.8.3.1/H-SR-2] Zdecydowanie ZALECANE dla użytkowników (np. do przełącznika wyjścia), do którego dostęp interfejs systemu, który pozwala użytkownikom przełączać się między odpowiednimi dostępnymi trasy (na przykład urządzenia Bluetooth i trasy udostępniane do usługi, MediaRouter2Manager) gdy aplikacja publikuje powiadomienie MediaStyle z tokenem MediaSession.

Jeśli implementacje urządzeń obejmujące klawisz nawigacyjny funkcji Ostatnie jako opisane w sekcji 7.2.3 dotyczące zmian interfejsu:

• [3.8.3/H-1-1] MUSI umieścić ekran przypinania i udostępniać użytkownikowi menu ustawień funkcji.

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

• [3.8.4/H-SR-2] Zdecydowanie ZALECANE aby użyć i przytrzymać klawisz HOME jako wyznaczoną interakcję do uruchomienia aplikacji asystującej zgodnie z opisem w sekcji 7.2.3. MUSI uruchomić wybraną przez użytkownika aplikację asystującą, czyli aplikację, która stosuje VoiceInteractionService lub aktywność obsługującą intencję ACTION_ASSIST.

Jeśli implementacje na urządzeniach mobilnych obsługują conversation notifications i zgrupować je w osobnej sekcji, oddzielnie od alertów i cichej nierozmowy, powiadomienia,

• [3.8.4/H-1-1]* MUSI wyświetlać powiadomienia o rozmowach przed powiadomieniami o innych rozmowach z z wyjątkiem ciągłych powiadomień usługi na pierwszym planie oraz znaczenie:wysoka powiadomienia.

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

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

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

• [3.9/H-1-1] MUSI obsługiwać pełny zakres administrowanie urządzeniami zasady określone w dokumentacji pakietu Android SDK.

Jeśli implementacje urządzeń mobilnych obejmują obsługę ControlsProviderService i Control interfejsy API i zezwalają aplikacjom innych firm na publikowanie ustawień urządzeń, a następnie:

• [3.8.16/H-1-1] MUSI zadeklarować funkcję flaga android.software.controls i ustaw ją na true.
• [3.8.16/H-1-2] MUSI zawierać użytkownika dodawanie, edytowanie, wybieranie i obsługę sterowanie ulubionymi urządzeniami za pomocą elementów sterujących zarejestrowanych przez inną firmę; aplikacji w ControlsProviderService oraz Control API.
• [3.8.16/H-1-3] MUSI zapewniać dostęp do dla tych użytkowników w ramach 3 interakcji z domyślnego Menu z aplikacjami.

• [3.8.16/H-1-4] MUSI być renderowana prawidłowo nazwę i ikonę każdej aplikacji innej firmy, zapewnia elementy sterujące za pomocą ControlsProviderService API oraz innych określonych polach dostarczonych przez Control. API.

• [3.8.16/H-1-5] MUSI zawierać użytkownika rezygnacja z korzystania z prostych mechanizmów uwierzytelniania elementów sterujących zarejestrowanych przez aplikacje innych firm za pomocą ControlsProviderService. oraz Control Interfejs API Control.isAuthRequired.

• [3.8.16/H-1-6] Implementacje na urządzeniach MUSI dokładnie renderować zarobki użytkownika w następujący sposób:

  • Jeśli urządzenie ustawiło config_supportsMultiWindow=true, a aplikacja deklaruje metadane META_DATA_PANEL_ACTIVITY. w ControlsProviderService z uwzględnieniem parametru KomponentName prawidłową aktywność (zgodnie z definicją interfejsu API), to aplikacja MUSI umieścić na stronie dla tych użytkowników.
  • Jeśli aplikacja nie zadeklaruje metadanych META_DATA_PANEL_ACTIVITY, MUSI renderować określone pola zgodnie z ControlsProviderService API oraz innych określonych polach dostarczonych przez Kontrolowane interfejsy API.

• [3.8.16/H-1-7] Jeśli aplikacja deklaruje metadane META_DATA_PANEL_ACTIVITY, MUSI przekazywać wartość ustawienia zdefiniowanego w [3.8.16/H-1-5] za pomocą EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS. podczas uruchamiania umieszczonej aktywności.

Jeśli natomiast wdrożenia na urządzeniach mobilnych nie mają takich mechanizmów kontroli, one:

• [3.8.16/H-2-1] MUSI zgłosić null za ControlsProviderService oraz Control API.
• [3.8.16/H-2-2] MUSI zadeklarować funkcję flaga android.software.controls i ustaw ją na false.

Jeśli implementacje na urządzeniach mobilnych nie działają w trybie blokady zadań, po skopiowaniu treści do schowka:

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

Implementacje na urządzeniach mobilnych:

• [3.10/H-0-1] MUSI obsługiwać ułatwienia dostępu innych firm usług Google.
• [3.10/H-SR-1] Zdecydowanie ZALECANE jest wstępne wczytywanie usługi ułatwień dostępu na urządzeniu są porównywalne lub przewyższające funkcjonalność funkcji Switch Access i TalkBack (dla języków obsługiwanych przez usługi ułatwień dostępu służące do zamiany tekstu na mowę) zgodnie z otwartym komunikatem TalkBack. projekt źródłowy.
• [3.11/H-0-1] MUSI obsługiwać instalację za pomocą funkcji zamiany tekstu na mowę innych firm.
• [3.11/H-SR-1] Zdecydowanie ZALECANE jest dodanie Mechanizm zamiany tekstu na mowę obsługuje języki dostępne na urządzeniu.
• [3.13/H-SR-1] Zdecydowanie ZALECANE jest dodanie Komponent UI Szybkich ustawień.

Jeśli implementacje urządzeń mobilnych z Androidem zadeklarują FEATURE_BLUETOOTH lub Zespół pomocy FEATURE_WIFI:

• [3.16/H-1-1] MUSI obsługiwać parowanie urządzenia towarzyszącego funkcji.

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

• [7.2.3/H] Strefa rozpoznawania gestów na urządzeniu Home Funkcja POWINNA mieć wysokość nie większą niż 32 dp od dolnej krawędzi ekranu.

jeśli w urządzeniach mobilnych jest dostępna funkcja nawigacji w postaci gestu. z dowolnego miejsca przy lewej i prawej krawędzi ekranu:

• [7.2.3/H-0-1] Obszar gestów funkcji nawigacji Szerokość musi mieć mniej niż 40 dp po każdej stronie. Obszar gestów POWINNY być: Domyślnie szerokość 24 dp.

Jeśli Chromebooki obsługują bezpieczny ekran blokady i mają większą 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 w Flaga funkcji android.software.managed_users.

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

• [7.5.4/H-1-1] MUSI uwzględniać android.media.action.STILL_IMAGE_CAMERA i android.media.action.STILL_IMAGE_CAMERA_SECURE i uruchomić aparat w trybie zdjęć, tak jak to opisano w pakiecie SDK.
• [7.5.4/H-1-2] MUSI uwzględniać android.media.action.VIDEO_CAMERA zamierza uruchomić kamerę w trybie wideo, zgodnie z opisem w pakiecie SDK.

Jeśli aplikacja ustawień implementacji urządzenia implementuje dzielonej funkcji, za pomocą umieszczania aktywności, to:

• [3.2.3.1/ H-1-1] MUSI mieć działanie, które obsługuje intencja Settings#ACTION_SETTINGS_COMMENTER_DEEP_LINK_ACTIVITY, gdy funkcja podziału jest włączona. Aktywność MUSI być chroniona przez android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK i MUSI rozpocznij aktywność intencji analizowanej z Ustawienia#EXTRA_SETTINGS_COMMENTERDED_DEEP_LINK_INTENT_URI.

Jeśli implementacje urządzeń umożliwiają użytkownikom nawiązywanie jakichkolwiek połączeń,

• [7.4.1.2/H-0-1] MUSI zadeklarować flagę funkcji android.software.telecom.
• [7.4.1.2/H-0-2] MUSI wdrożyć platformę telekomunikacyjną.

2.2.4 Wydajność i moc

• [8.1/H-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie klatek lub opóźnienie renderowania klatek NIE MOŻE powtarzać się często niż 5 klatek na sekundę, a POWINNA być poniżej 1 klatki na sekundę.
• [8.1/H-0-2] Opóźnienie interfejsu użytkownika. Implementacje urządzeń MUSZĄ zapewniać użytkownikom niewielkie opóźnienia, przewijając lista 10 tys. pozycji zgodnie z definicją zawartą w narzędziu Android Compatibility Test Suite. (CTS) w niecałe 36 sekund.
• [8.1/H-0-3] Przełączanie zadań. Kiedy uruchomiono wiele aplikacji, co powoduje ponowne uruchomienie jednej z już uruchomionych aplikacji. od uruchomienia aplikacji MUSI trwać mniej niż 1 sekundę.

Implementacje na urządzeniach mobilnych:

• [8.2/H-0-1] MUSI zapewniać ciągłość działania z wydajnością zapisu co najmniej 5 MB/s.
• [8.2/H-0-2] MUSI zapewniać losowy zapis z wydajnością co najmniej 0,5 MB/s.
• [8.2/H-0-3] MUSI zapewniać sekwencyjny odczyt z wydajnością co najmniej 15 MB/s.
• [8.2/H-0-4] MUSI zapewniać losowy odczyt z wydajnością co najmniej 3,5 MB/s.

jeśli implementacje urządzeń mobilnych obejmują funkcje zwiększające wydajność urządzenia; funkcji zarządzania uwzględnionymi w AOSP lub rozszerzających dostępne funkcje. w AOSP:

• [8.3/H-1-1] MUSI zapewniać wygodę użytkowników, aby umożliwić i wyłączyć funkcję oszczędzania baterii.
• [8.3/H-1-2] MUSI zapewniać wygodę wyświetlania użytkownikom wszystkich aplikacji, które są wyłączone z trybów czuwania aplikacji i uśpienia.

Implementacje na urządzeniach mobilnych:

• [8.4/H-0-1] MUSI zawierać parametr profil zasilania na komponent, który określa bieżącą wartość zużycia dla każdego elementu sprzętowego i przybliżone zużycie baterii przez zgodnie z opisem w witrynie Android Open Source Project.
• [8.4/H-0-2] MUSI zgłaszać całą zasilanie wartości wykorzystania w miliiamperach godzin (mAh).
• [8.4/H-0-3] MUSI raportować moc procesora na wykorzystanie identyfikatora UID każdego procesu. W projekcie Android Open Source Project za pomocą modułu jądra uid_cputime.
• [8.4/H-0-4] MUSI zapewniać to zużycie energii dostępne w adb shell dumpsys batterystats należy użyć polecenia powłoki do dewelopera aplikacji.
• [8.4/H] POWINNY być przypisane do sam komponent sprzętowy, jeśli nie można przypisać wykorzystania energii przez komponent sprzętowy. do aplikacji.

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

• [8.4/H-1-1] MUSI uwzględniać android.intent.action.POWER_USAGE_SUMMARY. i wyświetli menu ustawień, które pokazuje to zużycie energii.

Implementacje na urządzeniach mobilnych:

• [8.5/H-0-1] MUSI zawierać możliwość wyświetlania wszystkich aplikacji z aktywnymi usługami na pierwszym planie lub zadań inicjowanych przez użytkownika, w tym czas trwania każdej z tych usług od momentu rozpoczęcia zgodnie z opisem w dokumentacji pakietu SDK.

• [8.5/H-0-2]MUSI zapewniać zaoferowanie użytkownikowi Zatrzymać aplikację uruchomioną na pierwszym planie lub w zadaniu inicjowanym przez użytkownika.

2.2.5. Model zabezpieczeń

Implementacje na urządzeniach mobilnych:

• [9/H-0-1] MUSI zadeklarować android.hardware.security.model.compatible funkcji.
• [9.1/H-0-1] MUSI zezwalać aplikacjom innych firm na dostęp do statystyki użytkowania z użyciem uprawnienia android.permission.PACKAGE_USAGE_STATS i udostępniać dostępny dla użytkownika mechanizm przyznawania lub unieważnić dostęp do takich aplikacji w odpowiedzi na android.settings.ACTION_USAGE_ACCESS_SETTINGS intencji.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli implementacje urządzeń zadeklarują obsługę android.hardware.telephony, one:

• [9.5/H-1-1] NIE MOŻE ustawiać UserManager.isHeadlessSystemUserMode do true.

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 RSA, AES, algorytmy kryptograficzne ECDSA i HMAC oraz rodziny MD5, SHA-1 i SHA-2 funkcji skrótu do prawidłowej obsługi które są bezpiecznie odizolowane od kodu działającego na na jądrze i w nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy za pomocą którego jądro lub kod przestrzeni użytkownika może uzyskać dostęp do wewnętrznego stanu w odizolowanym środowisku, w tym DMA. Starsze oprogramowanie typu open source na Androida Projekt (AOSP) spełnia to wymaganie dzięki wdrożeniu Trusty. Rozwiązanie oparte na technologii ARM TrustZone lub zewnętrzne sprawdzone wdrożenie prawidłowej izolacji opartej na hipernadzorcy to alternatywne rozwiązanie .
• [9.11/H-0-4] MUSI włączać ekran blokady w izolowanym środowisku wykonawczym i tylko wtedy, gdy pomyślne, zezwól na używanie kluczy powiązanych z uwierzytelnianiem. Ekran blokady dane logowania MUSZĄ być przechowywane w sposób umożliwiający wyłącznie izolowane uruchomienie aby przeprowadzić uwierzytelnianie przy zablokowanym ekranie. Nadrzędny Android Projekt open source zapewnia Warstwa abstrakcji sprzętowej bramy (HAL) i Trusty. Można je wykorzystać, aby spełnić to wymaganie.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Pamiętaj, że jeśli implementacja na urządzeniach została już wprowadzona na starszym Androidzie przez co urządzenie jest zwolnione z obowiązku posiadania magazynu kluczy są oparte na izolowanym środowisku wykonawczym i obsługują atest klucza; chyba że deklaruje on funkcję android.hardware.fingerprint, która wymaga żądania magazyn kluczy obsługiwany przez izolowane środowisko wykonawcze.

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

• [9.11/H-1-1] MUSI umożliwiać użytkownikowi wybranie najkrótszej czas uśpienia, czyli czas przejścia z odblokowanego do zablokowanego może wynosić maksymalnie 15 sekund.
• [9.11/H-1-2] MUSI udostępniać użytkownikom zgodę na ukrycie powiadomień i wyłączyć wszystkie formy uwierzytelniania z wyjątkiem podstawowe uwierzytelnianie opisane w 9.11.1 Bezpieczny ekran blokady. AOSP spełnia jako trybu blokady.

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

• [9.11.1/H-1-1] MUSI prosić użytkownika o zastosowanie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) częściej niż raz na 72 godziny.

Jeśli wdrożenia na urządzeniach mobilnych obejmują wielu użytkowników nie deklarują flagi funkcji android.hardware.telephony, oznacza to, że:

• [9.5/H-2-1] MUSI obsługiwać profile z ograniczonym dostępem, funkcję umożliwiającą właścicielom urządzeń zarządzanie dodatkowymi użytkownikami dostępnych na urządzeniu. Dzięki profilom ograniczonym właściciele urządzeń mogą szybko skonfigurować osobne środowiska do pracy dodatkowych użytkowników, oraz zarządzanie bardziej precyzyjnymi ograniczeniami w aplikacjach, które są dostępne w tych środowiskach.

Jeśli wdrożenia na urządzeniach mobilnych obejmują wielu użytkowników zadeklarować flagę funkcji android.hardware.telephony, oznacza to, że:

• [9.5/H-3-1] NIE MOŻE obsługiwać reklam z ograniczeniami profili, ale MUSZĄ być zgodne z implementacją AOSP. , aby włączyć lub wyłączyć innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

Jeśli ustawiono wartość UserManager.isHeadlessSystemUserMode w implementacjach na urządzeniach mobilnych do: true,

• [9.5/H-4-1] NIE MOŻE obsługiwać obsługi eUICC, ani w przypadku kart eSIM z możliwością połączeń.
• [9.5/H-4-2] NIE MOŻE deklarować obsługi android.hardware.telephony

Na Androidzie za pośrednictwem interfejsu System API VoiceInteractionService obsługuje mechanizm bezpieczne, zawsze włączone wykrywanie słów-kluczy bez wskaźnika dostępu do mikrofonu i zawsze włączone wykrywanie zapytań, bez mikrofonu i kamery wskaźnik dostępu.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli implementacje urządzeń mobilnych obsługują interfejs System API HotwordDetectionService lub inny mechanizm wykrywania słowa-klucza bez dostęp do mikrofonu:

• [9.8/H-1-1] MUSI się upewnić, że usługa wykrywania słów-kluczy może przesyłać dane do systemu, ContentCaptureService, lub usługi rozpoznawania mowy na urządzeniu utworzonej przez SpeechRecognizer#createOnDeviceSpeechRecognizer()
• [9.8/H-1-2] MUSI się upewnić, że usługa wykrywania słów-kluczy może przesyłać z mikrofonu lub danych pozyskanych z tego mikrofonu na serwer systemowy HotwordDetectionService API lub ContentCaptureService do Interfejs API ContentCaptureManager.
• [9.8/H-1-3] NIE MOŻE dostarczać dźwięku z mikrofonu dłuższego niż 30 sekund przez żądań wyzwalanych przez sprzęt 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 przez do usługi wykrywania słów-kluczy.
• [9.8/H-1-5] NIE MOŻE przekazywać do usługi interakcji głosowej lub podobnego podmiotu.
• [9.8/H-1-6] NIE MOŻE zezwalać na więcej niż 100 bajtów danych (z wyłączeniem strumieni audio) są wysyłane poza usługę wykrywania słów-kluczy po każdym udanym działaniu ze słowem-kluczem.
• [9.8/H-1-7] NIE MOŻE zezwalać na przesyłanie więcej niż 5 bitów danych na zewnątrz usługi wykrywania słów-kluczy dla każdego z negatywnych słów-kluczy.
• [9.8/H-1-8] MUSI umożliwiać przesyłanie danych tylko poza słowo-klucz wykrywania w przypadku żądania weryfikacji słowa-klucza otrzymanego od serwera systemu.
• [9.8/H-1-9] NIE MOŻE zezwalać aplikacji instalowanej przez użytkownika na dostarczanie usługi wykrywania słów-kluczy.
• [9.8/H-1-10] NIE MOŻESZ wyświetlać w interfejsie użytkownika danych ilościowych o korzystaniu z mikrofonu przez dzięki usłudze 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, która umożliwia sprawdzenie pod kątem bezpieczeństwa i badań.
• [9.8/H-1-12] MUSI obsługiwać tryb debugowania, który rejestruje nieprzetworzoną zawartość każdego przesyłania z usługi wykrywania słów-kluczy, co pozwala na sprawdzenie i badaczy bezpieczeństwa.

• [9.8/H-1-14] NALEŻY wyświetlać wskaźnik mikrofonu, zgodnie z opisem w sekcji 9.8.2, jeśli udany wynik słowa-klucza zostanie przesłany do głosu usługi interakcji lub podobnego podmiotu.

• [9.8/H-1-15] MUSI mieć pewność, że strumienie audio zostaną dostarczone po słowie-kluczu są przesyłane w jedną stronę z usługi wykrywania słów-kluczy do usługi interakcji głosowej.

• [9.8/H-SR-1] Zdecydowanie ZALECANE jest powiadomienie użytkowników przed ustawieniem jako dostawcę usługi wykrywania słów-kluczy.

• [9.8/H-SR-2] Zdecydowanie ZALECANE jest zablokowanie transmisji nieuporządkowanych danych poza usługą wykrywania słów-kluczy.

• [9.8/H-SR-3] Zdecydowanie ZALECANE jest ponowne uruchomienie procesu hostowania wykrywanie słów-kluczy co najmniej raz na godzinę lub co 30 zdarzenia aktywującego sprzęt (w zależności od tego, co nastąpi wcześniej).

jeśli implementacje urządzeń obejmują aplikację, która korzysta z interfejsu System API. HotwordDetectionService lub podobny mechanizm wykrywania słów-kluczy bez wskazaniem użycia mikrofonu, aplikacja:

• [9.8/H-2-1] MUSI zawierać wyraźne powiadomienie o każdym słowie-kluczu obsługiwane.
• [9.8/H-2-2] NIE MOŻE zachowywać nieprzetworzonych danych dźwiękowych ani danych uzyskanych z nich. w usłudze wykrywania słów-kluczy.
• [9.8/H-2-3] NIE MOŻE przesyłać z usługi wykrywania słów-kluczy ani dźwięku dane, które można wykorzystać do zrekonstruowania (całkowitej lub części) dźwięku, lub treści audio niezwiązane z samym słowem-kluczem, z wyjątkiem ContentCaptureService lub mowa na urządzeniu i rozpoznawania twarzy.

Jeśli implementacje urządzeń mobilnych obsługują interfejs System API VisualQueryDetectionService lub inny mechanizm wykrywania zapytań bez wskazania dostępu do mikrofonu lub aparatu:

• [9.8/H-3-1] MUSI mieć pewność, że usługa wykrywania zapytań może przesyłać tylko dane do systemu, ContentCaptureService lub mowę na urządzeniu usługa rozpoznawania (utworzona przez SpeechRecognizer#createOnDeviceSpeechRecognizer()).
• [9.8/H-3-2] NIE MOŻE umożliwiać przesyłania żadnych informacji dźwiękowych ani wideo z VisualQueryDetectionService oprócz ContentCaptureService lub usługi rozpoznawania mowy na urządzeniu.
• [9.8/H-3-3] MUSI wyświetlać w interfejsie systemu powiadomienie użytkownika, gdy urządzenie wykryje użytkownika mają zamiary korzystać z aplikacji Asystent cyfrowy (np.przez przez kamerę).
• [9.8/H-3-4] MUSI wyświetlać wskaźnik mikrofonu i pokazywać wykryte bezpośrednio po wykryciu zapytania użytkownika.
• [9.8/H-3-5] NIE MOŻE zezwalać aplikacji instalowanej przez użytkownika na dostarczanie usługi wizualnego wykrywania zapytań.

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 dostęp do mikrofonu ma tylko HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService lub aplikacje pełniące role nazywane w sekcji 9.1 o identyfikatorze CDD [C-4-X].
• [9.8.2/H-4-2] MUSI wyświetlać listę najnowszych i aktywnych aplikacje używające mikrofonu w odpowiedzi PermissionManager.getIndicatorAppOpUsageData() wraz z wszelką atrybucją wiadomości, które są z nimi powiązane.
• [9.8.2/H-4-3] NIE MOŻE ukrywać wskaźnika mikrofonu w aplikacje systemowe z widocznymi interfejsami lub bezpośrednią interakcją użytkownika.
• [9.8.2/H-4-4] MUSI wyświetlać listę najnowszych i aktywnych aplikacje używające mikrofonu (dane z aplikacji PermissionManager.getIndicatorAppOpUsageData()), wraz z powiązanymi z nimi wiadomościami 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 ma dostęp do danych kamery, ale nie wtedy, gdy kamera jest mają dostęp do aplikacji pełniących role nazywane w art. 9.1 z identyfikatorem CDD [C-4-X].
• [9.8.2/H-5-2] MUSI wyświetlać Ostatnie i aktywne aplikacje za pomocą aparat zwrócony z urządzenia PermissionManager.getIndicatorAppOpUsageData(), wraz z powiązanymi z nimi wiadomościami o atrybucji.
• [9.8.2/H-5-3] NIE MOŻE ukrywać wskaźnika aparatu dla aplikacje systemowe z widocznymi interfejsami lub bezpośrednią interakcją użytkownika.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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

Definicję znajdziesz w artykule 7.11 klasa skuteczności multimediów.

2.2.7.1. Multimedia

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

• MUSI spełniać wymagania dotyczące multimediów wymienione w sekcji CDD na temat systemu Android 14 (sekcja 2.2.7.1).

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [5.1/H-1-1] MUSI reklamować maksymalną liczbę sprzętowych dekoderów wideo które mogą być uruchamiane jednocześnie przy użyciu dowolnej kombinacji kodeka za pośrednictwem CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints() metody.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [5.1/H-1-3] NALEŻY reklamować maksymalną liczbę sprzętowych koderów wideo. które mogą być uruchamiane jednocześnie przy użyciu dowolnej kombinacji kodeka za pośrednictwem CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints() metody.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [5.1/H-1-5] MUSI reklamować maksymalną liczbę sprzętowych koderów wideo sesji dekodera, które mogą być uruchamiane równocześnie z użyciem dowolnej kombinacji kodeków za pośrednictwem CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints() metody.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [5.1/H-1-7] W przypadku formatu [5.1/H-1-7] opóźnienie inicjowania kodeka musi wynosić maksymalnie 40 ms Sesja kodowania 1080p lub mniejsza w przypadku wszystkich sprzętowych koderów wideo, gdy nie jest wczytywany. Wczytywanie tutaj jest zdefiniowane jako jednoczesny tryb odtwarzania filmów od 1080p do 720p i sesji transkodowania za pomocą sprzętowych kodeków wideo oraz funkcji 1080p. inicjowania nagrywania audio-wideo. W przypadku kodeka Dolby Vision opóźnienie inicjowania MUSI wynosić 50 ms lub mniej.
• [5.1/H-1-8] W przypadku formatu [5.1/H-1-8] opóźnienie inicjowania kodeka musi wynosić maksymalnie 30 ms Sesja kodowania dźwięku 128 kb/s lub niższa w przypadku wszystkich koderów audio, gdy nie jest wczytywany. Wczytywanie tutaj jest zdefiniowane jako jednoczesny tryb odtwarzania filmów od 1080p do 720p i sesji transkodowania za pomocą sprzętowych kodeków wideo oraz funkcji 1080p. inicjowania nagrywania audio-wideo.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [5.1/H-1-11] MUSI obsługiwać bezpieczny dekoder dla każdego sprzętowego AVC, HEVC VP9 lub AV1 na urządzeniu.
• [5.1/H-1-12] W przypadku formatu [5.1/H-1-12] opóźnienie inicjowania kodeka musi wynosić maksymalnie 40 ms Sesja dekodowania wideo 1080p lub mniejsza w przypadku wszystkich sprzętowych dekoderów wideo a w trakcie wczytywania. Wczytywanie w tym miejscu jest zdefiniowane jako jednoczesna rozdzielczość od 1080p do 720p w trybie transkodowania tylko wideo za pomocą sprzętowych kodeków wideo Inicjowanie odtwarzania dźwięku i wideo w rozdzielczości 1080p. W przypadku kodeka Dolby Vision opóźnienie inicjowania MUSI wynosić 50 ms lub mniej.
• [5.1/H-1-13] W przypadku formatu [5.1/H-1-13] opóźnienie inicjowania kodeka musi wynosić maksymalnie 30 ms Sesja dekodowania dźwięku 128 kb/s lub niższa we wszystkich dekoderach audio, gdy: nie jest wczytywany. Wczytywanie tutaj jest zdefiniowane jako jednoczesny tryb odtwarzania filmów od 1080p do 720p i sesji transkodowania za pomocą sprzętowych kodeków wideo oraz funkcji 1080p. zainicjowanie odtwarzania dźwięku i filmu.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [5.1/H-1-15] MUSI mieć co najmniej jeden sprzętowy dekoder wideo obsługujący rozdzielczość 4K60.
• [5.1/H-1-16] MUSI mieć co najmniej jeden koder sprzętowy obsługujący rozdzielczość 4K60.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [5.3/H-1-1] NIE MOŻE upuścić więcej niż 1 klatki w ciągu 10 sekund (tj. krócej niż 0,167% utraty klatki) podczas wczytywania sesji wideo 4K 60 kl./s.
• [5.3/H-1-2] W trakcie filmu NIE MOŻE upuścić więcej niż 1 klatki na 10 sekund zmiana rozdzielczości podczas wczytywania sesji wideo z prędkością 60 kl./s w przypadku sesji 4K.
• [5.6/H-1-1] Czas oczekiwania na tonację musi wynosić maksymalnie 80 milisekund. który jest dostępny w narzędziu CTS Verifier.
• [5.6/H-1-2] MUSI mieć opóźnienie w obie strony wynoszące 80 milisekund lub w przypadku co najmniej 1 obsługiwanej ścieżki danych.
• [5.6/H-1-3] MUSI obsługiwać >= 24-bitowy dźwięk w przypadku wyjścia stereo z dźwiękiem 3,5 mm gniazda słuchawek (jeśli są dostępne) i przez USB audio, jeśli są obsługiwane w całej transmisji danych. dla konfiguracji z krótkim czasem oczekiwania i strumieniem strumieniowania. Krótki czas oczekiwania AAudio ma być używany przez aplikację w wywołaniu zwrotnym z krótkim czasem oczekiwania i trybu uzyskiwania zgody. Do konfiguracji strumieniowego przesyłania danych należy użyć funkcji Java AudioTrack aplikację. Zarówno w konfiguracji z krótkim czasem oczekiwania, jak i w konfiguracji strumieniowania HAL ujście wyjściowe powinno akceptować AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT lub AUDIO_FORMAT_PCM_FLOAT dla docelowego formatu wyjściowego.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [5.6/H-1-5] MUSI obsługiwać urządzenia MIDI zgodne ze standardem klasy i zadeklarować Flaga funkcji MIDI.
• [5.6/H-1-9] MUSI obsługiwać co najmniej 12-kanałowy miksowanie. Oznacza to, że aby uruchomić ścieżkę audio z maską 7.1.4 kanału przestrzennego lub typu Downmix wszystkich kanałów do stereo.
• [5.6/H-SR] Zdecydowanie ZALECANE jest obsługa 24-kanałowego miksowania za pomocą co najmniej obsługują maski kanału 9.1.6 i 22.2.
• [5.7/H-1-2] MUSI obsługiwać tag MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL z poniżej funkcji odszyfrowywania treści.

Minimalny rozmiar próbki	4 MiB
Minimalna liczba próbek podrzędnych – H264 lub HEVC	32
Minimalna liczba próbek podrzędnych – VP9	9
Minimalna liczba próbek podrzędnych – AV1	288
Minimalny rozmiar bufora próbki podrzędnego	1 MiB
Minimalny rozmiar ogólnego bufora kryptograficznego	500 KiB
Minimalna liczba równoczesnych sesji	30
Minimalna liczba kluczy na sesję	20
Minimalna łączna liczba kluczy (wszystkie sesje)	80
Minimalna łączna liczba kluczy DRM (wszystkie sesji)	6
Rozmiar wiadomości	16 KiB
Odszyfrowane klatki na sekundę	60 kl./s

• [5.1/H-1-17] MUSI mieć co najmniej jeden sprzętowy dekoder obrazu obsługujący format AVIF Profil podstawowy.
• [5.1/H-1-18] MUSI obsługiwać koder AV1, który potrafi kodować do 480p. 30 kl./s i 1 Mb/s.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [5.12/H-SR] Zdecydowanie zalecamy wsparcie Feature_HdrEditing dla wszystkich sprzętowych koderów AV1 i HEVC dostępnych na urządzeniu.
• [5.12/H-1-2] MUSI obsługiwać format kolorów RGBA_1010102 dla całego sprzętu AV1 i Urządzenie zawiera kodery HEVC.
• [5.12/H-1-3] MUSISZ reklamować obsługę rozszerzenia EXT_YUV_target w próbkę z tekstur YUV w 8 i 10-bitach.
• [7.1.4/H-1-1] W przetwarzaniu wyświetlacza MUSI mieć co najmniej 6 nakładek sprzętowych (DPU), przy czym co najmniej 2 z nich mogą wyświetlać 10-bitową treść wideo.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [5.2/H-2-1] MUSI osiągnąć minimalną docelową jakość określoną w filmie. krzywe zniekształcenia szybkości kodera dla sprzętowych kodeków AVC i HEVC, zgodnie z definicją Przeprowadź testy jakości kodowania wideo (VEQ) w klasie wydajności 14 (PC14).

2.2.7.2. Aparat

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

• MUSI spełniać wymagania dotyczące multimediów wymienione w sekcji CDD na temat Androida 14 (sekcja 2.2.7.2).

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [7.5/H-1-2] MUSI mieć główny przedni aparat o rozdzielczości co najmniej 6 megapikseli i umożliwia nagrywanie filmów w rozdzielczości 1080p przy 30 kl./s. Podstawowy przedni aparat to przedni aparat z najniższym identyfikatorem.
• [7.5/H-1-3] MUSI obsługiwać właściwość android.info.supportedHardwareLevel jako FULL lub więcej dla tylnej głównej i LIMITED lub lepszej dla głównej części głównej aparat fotograficzny.
• [7.5/H-1-4] MUSI obsługiwać CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME dla obu domen kamery.
• [7.5/H-1-5] MUSI mieć opóźnienie na zapis w formacie JPEG w aparacie2 < 1000 ms dla rozdzielczości 1080p mierzonej w teście wydajności kamery CTS w Warunki oświetleniowe ITS (3000 K) dla obu głównych kamer.
• [7.5/H-1-6] MUSI mieć opóźnienie na uruchomienie kamery2 (otwórz aparat, aby wyświetlić pierwszy podgląd ramka) < 500 ms na podstawie wyników testu wydajności kamery CTS przeprowadzonego przez ITS warunków oświetleniowych (3000 K) obu aparatów głównych.
• [7.5/H-1-8] MUSI obsługiwać CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW i android.graphics.ImageFormat.RAW_SENSOR za główny tylny aparat.
• [7.5/H-1-9] MUSI mieć tylny aparat główny obsługujący rozdzielczość 720p lub 1080p. 240 kl./s
• [7,5/H-1-10] MUSI mieć min.ZOOM_RATIO < 1.0 dla aparatów głównych, jeśli są dostępne jest ultraszerokokątny aparat RGB skierowany w tę samą stronę.
• [7.5/H-1-11] MUSI zaimplementować równoczesne przesyłanie strumieniowe z przodu na stronie głównej kamery.
• [7.5/H-1-12] MUSI obsługiwać CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION dla obu domen przedni i główny tylny aparat.
• [7.5/H-1-13] MUSI obsługiwać funkcję LOGICAL_MULTI_CAMERA dla głównego tylnego aparatu, jeśli masz więcej niż 1 tylny aparat RGB kamery.
• [7.5/H-1-14] MUSI obsługiwać STREAM_USE_CASE w przypadku przedni i główny tylny aparat.
• [7.5/H-1-15] MUSI obsługiwać Rozszerzenia trybu nocnego dla rozszerzeń podstawowych z AparatuX i Aparatu2 kamery.
• [7.5/H-1-16] MUSI obsługiwać funkcję DYNAMIC_RANGE_TEN_BIT w kamery.
• [7.5/H-1-17] MUSI obsługiwać tryb control_SCENE_MODE_FACE_PRIORITY i wykrywanie twarzy (STATISTICS_FACE_DETECT_MODE_SIMPLE lub STATISTICS_FACE_DETECT_MODE_FULL) dla aparatów głównych.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

2.2.7.3 Sprzęt

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

• MUSI spełniać wymagania dotyczące multimediów wymienione w sekcji CDD na temat systemu Android 14 (sekcja 2.2.7.3).

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [7.1.1.1/H-2-1] MUSI mieć rozdzielczość co najmniej 1080p.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [7.1.1.3/H-3-1] MUSI mieć wyświetlacz HDR obsługujący co najmniej 1000 nitów średnią.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

2.2.7.4. Wydajność

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

• MUSI spełniać wymagania dotyczące wydajności wymienione w sekcji CDD na temat Androida 14 (sekcja 2.2.7.4).

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [8.2/H-1-1] MUSI zapewnić wydajność sekwencyjnego zapisu na poziomie co najmniej 150 MB/s.
• [8.2/H-1-2] MUSI zapewniać wydajność zapisu przy losowym połączeniu z szybkością co najmniej 10 MB/s.
• [8.2/H-1-3] MUSI zapewniać wydajność sekwencyjnego odczytu co najmniej 250 MB/s.
• [8.2/H-1-4] MUSI zapewnić prędkość odczytu z szybkością losowej co najmniej 100 MB/s.
• [8.2/H-1-5] MUSI zapewniać równoległą wydajność sekwencyjnego odczytu i zapisu przy wydajności dwukrotnej odczytu i 1-krotnego zapisu z szybkością co najmniej 50 MB/s.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

2.2.7.5. Grafika

2.3. Wymagania dotyczące telewizora

Urządzenie Android TV odnosi się do implementacji urządzeń z Androidem, które to interfejs rozrywkowy do korzystania z mediów cyfrowych, filmów, gier, aplikacji lub telewizję na żywo dla użytkowników siedzących w odległości około 3 metrów od siebie interfejsu”).

Implementacje na urządzeniach z Androidem są klasyfikowane jako telewizory, jeśli spełniają wszystkie następujące kryteria:

• udostępniają mechanizm zdalnego sterowania renderowanym interfejsem użytkownika na który może znajdować się ok. 3,5 metra od użytkownika.
• mieć wbudowany wyświetlacz o przekątnej większej niż 24 lata. LUB zawierać port wyjściowy wideo, np. VGA, HDMI, DisplayPort lub i bezprzewodowego portu do wyświetlania.

Dodatkowe wymagania opisane w pozostałej części tej sekcji dotyczą Androida Implementacje na urządzeniach telewizyjnych.

2.3.1 Sprzęt

Implementacje na urządzeniach telewizyjnych:

• [7.2.2/T-0-1] MUSI obsługiwać pada kierunkowego.
• [7.2.3/T-0-1] MUSI zawierać adres strony głównej i Wstecz funkcji.
• [7.2.3/T-0-2] MUSI wysłać zarówno normalne, jak i długie naciśnięcie zdarzenie funkcji Wstecz (KEYCODE_BACK) do aplikacji na pierwszym planie.
• [7.2.6.1/T-0-1] MUSI zawierać obsługę gry kontrolerów i zadeklarować flagę funkcji android.hardware.gamepad.
• [7.2.7/T] POWINNY jest dostarczyć pilota, którego użytkownicy mogą korzystać z nawigacji bezdotykowej oraz główne klawisze nawigacyjne.

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

• [7.3.4/T-1-1] MUSI być w stanie zgłaszać zdarzenia do co najmniej 100 Hz.
• [7.3.4/T-1-2] MUSI być w stanie mierzyć zmiany orientacji ekranu. 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 zawierać co najmniej 4 GB pamięci pamięć nieulotna dostępna na prywatne dane aplikacji (zwane też partycją „/data”).

Jeśli telewizory są wyposażone w port USB obsługujący tryb hosta, one:

• [7.5.3/T-1-1] MUSI zawierać obsługę kamery zewnętrznej który łączy się przez ten port USB, ale nie zawsze jest podłączony.

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

• [7.6.1/T-1-1] Pamięć dostępna dla jądra a przestrzeń użytkowników 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 a przestrzeń użytkowników MUSI mieć co najmniej 1280 MB, jeśli wykorzystane:

  • 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

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do dostępne miejsce w pamięci dodane do pamięci, która jest już przeznaczone do części sprzętowych (np. radia czy wideo), które nie są które są pod kontrolą jądra systemu operacyjnego.

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 telewizorach MUSZĄ obsługiwać to kodowanie dźwięku formatów i dekodowania, a także udostępnić 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 telewizorach MUSZĄ obsługiwać to kodowanie wideo formatów i udostępniać je aplikacjom innych firm:

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

Implementacje na urządzeniach telewizyjnych:

• [5.2.2/T-SR-1] Zdecydowanie ZALECANE jest wsparcie Kodowanie filmów w jakości H.264 w rozdzielczości 720p i 1080p przy 30 klatkach na sekundę.

Implementacje na telewizory MUSZĄ obsługiwać następujące dekodowanie wideo formatów i udostępniać je aplikacjom innych firm:

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

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać dekodowanie MPEG-2, zgodnie z opisem w sekcji Sekcja 5.3.1, ze standardową liczbą klatek i rozdzielczością do w tym:

• [5.3.1/T-1-1] HD 1080p przy 29,97 klatce na sekundę z wysokim poziomem profilu głównego.
• [5.3.1/T-1-2] HD 1080i przy 59,94 klatce na sekundę z wysokim poziomem profilu głównego. Trzeba usunąć przeplot w filmie MPEG-2 i udostępniać je aplikacjom innych firm.

Implementacje na telewizorach MUSZĄ obsługiwać dekodowanie H.264, jak opisano w Sekcja 5.3.4, przy standardowej liczbie klatek i rozdzielczości do w tym:

• [5.3.4/T-1-1] 1080p HD przy 60 klatkach na sekundę przy Profil podstawowy
• [5.3.4/T-1-2] HD 1080p przy 60 klatkach na sekundę przy Profil główny
• [5.3.4/T-1-3] 1080p HD przy 60 klatkach na sekundę przy Wysoki poziom 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, ze standardowymi liczbami klatek filmu i rozdzielczości aż do:

• [5.3.5/T-1-1] 1080p HD przy 60 klatkach na sekundę przy Poziom 4.1 profilu głównego

Jeśli implementacje urządzeń telewizyjnych z dekoderami sprzętowymi H.265 obsługują Dzięki dekodowaniu H.265 i profilowi dekodowania UHD:

• [5.3.5/T-2-1] MUSI obsługiwać profil dekodowania UHD 60 klatek na sekundę w profilu głównego poziomu 5 Main10

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać dekodowanie VP8, jak opisano w Sekcja 5.3.6, ze standardową liczbą klatek i rozdzielczością do w tym:

• [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ć ten standard (zgodnie z opisem w sekcji 5.3.7) przy standardowych liczbach klatek na sekundę oraz maksymalnie:

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

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

• [5.3.7/T-2-1] MUSI obsługiwać profil dekodowania UHD 60 klatek na sekundę przy profilu 0 (8-bitowa głębia kolorów).
• [5.3.7/T-SR1] Zdecydowanie ZALECANE jest działanie Profil dekodowania UHD przy 60 klatkach na sekundę z profilem 2 (10-bitowa głębia kolorów).

Implementacje na urządzeniach telewizyjnych:

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

Jeśli telewizory nie mają wbudowanego wyświetlacza, Zamiast tego obsługują zewnętrzny wyświetlacz podłączony przez HDMI, ale:

• [5.8/T-0-1] MUSI ustawić tryb wyjścia HDMI na najwyższa rozdzielczość dla wybranego formatu piksela, który obsługuje 50 Hz lub 60 Hz częstotliwość odświeżania zewnętrznego wyświetlacza (w zależności od częstotliwości odświeżania wideo regionu, w którym jest sprzedawane urządzenie.
• [5.8/T-SR-1] Zdecydowanie ZALECANE jest podanie użytkownikowi informacji konfigurowalny selektor częstotliwości odświeżania HDMI.
• [5.8] NALEŻY ustawiać częstotliwość odświeżania w trybie wyjścia HDMI na 50 Hz lub 60 Hz, zależnie od częstotliwości odświeżania wideo w regionie, w których sprzedawano swoje urządzenie.

Jeśli telewizory nie mają wbudowanego wyświetlacza, Zamiast tego obsługują zewnętrzny wyświetlacz podłączony przez HDMI, ale:

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

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

• [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] MUSI załadować jeden lub aplikacji czy komponentów usługi z modułem obsługi intencji, dla wszystkich wzorce filtra intencji publicznych zdefiniowane przez te intencje aplikacji wymienione tutaj.
• [3.4.1/T-0-1] MUSI zawierać pełny implementacji interfejsu android.webkit.Webview API.

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

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

Implementacje na urządzeniach telewizyjnych:

• [3.8.14/T-SR-1] Zdecydowanie ZALECANE aby obsługiwać wiele okien w trybie obrazu w obrazie (PIP).
• [3.10/T-0-1] MUSI obsługiwać ułatwienia dostępu innych firm usług Google.
• [3.10/T-SR-1] Zdecydowanie ZALECANE są wstępne załadowanie usług ułatwień dostępu na urządzeniu porównywalnym do lub przekraczającym funkcji Switch Access i TalkBack (w językach obsługiwanych przez fabrycznie zainstalowanego mechanizmu przetwarzania tekstu na mowę), zgodnie z opisem projektu open source TalkBack.

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

• [3.11/T-SR-1] Zdecydowanie ZALECANE jest dodanie Mechanizm zamiany tekstu na mowę obsługuje języki dostępne na urządzeniu.
• [3.11/T-1-1] MUSI obsługiwać instalację za pomocą funkcji zamiany tekstu na mowę innych firm.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

2.3.4 Wydajność i moc

• [8.1/T-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie klatek lub opóźnienie renderowania klatek NIE MOŻE powtarzać się często niż 5 klatek na sekundę, a POWINNA być poniżej 1 klatki na sekundę.
• [8.2/T-0-1] MUSI zapewniać ciągłość działania z wydajnością zapisu co najmniej 5 MB/s.
• [8.2/T-0-2] MUSI zapewniać losowy zapis z wydajnością co najmniej 0,5 MB/s.
• [8.2/T-0-3] MUSI zapewniać ciągłość działania odczyt z szybkością co najmniej 15 MB/s.
• [8.2/T-0-4] MUSI zapewniać losowy odczyt z wydajnością co najmniej 3,5 MB/s.

jeśli implementacje urządzeń telewizyjnych obejmują funkcje zwiększające wydajność urządzenia, funkcji zarządzania uwzględnionymi w AOSP lub rozszerzających dostępne funkcje. w AOSP:

• [8.3/T-1-1] MUSI zapewniać wygodę użytkowników, aby umożliwić i wyłączyć funkcję oszczędzania baterii.

Jeśli telewizory nie mają baterii:

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

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

• [8.3/T-1-3] MUSI zapewniać wygodę wyświetlania użytkownikom 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 na komponent, który określa bieżącą wartość zużycia dla każdego elementu sprzętowego i przybliżone zużycie baterii przez zgodnie z opisem w witrynie Android Open Source Project.
• [8.4/T-0-2] MUSI zgłaszać całą zasilanie wartości wykorzystania w miliiamperach godzin (mAh).
• [8.4/T-0-3] MUSI raportować moc procesora na wykorzystanie identyfikatora UID każdego procesu. W projekcie Android Open Source Project za pomocą modułu jądra uid_cputime.
• [8.4/T] POWINNO być przypisane do sam komponent sprzętowy, jeśli nie można przypisać wykorzystania energii przez komponent sprzętowy. do aplikacji.
• [8.4/T-0-4] MUSI zapewniać to zużycie energii dostępne w adb shell dumpsys batterystats należy użyć polecenia powłoki do dewelopera aplikacji.

2.3.5 Model zabezpieczeń

Implementacje na urządzeniach telewizyjnych:

• [9/T-0-1] MUSI zadeklarować android.hardware.security.model.compatible funkcji.
• [9.11/T-0-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/T-0-2] MUSI zawierać implementacje RSA, AES, algorytmy kryptograficzne ECDSA i HMAC oraz rodzina MD5, SHA-1 i SHA-2 funkcji skrótu do prawidłowej obsługi które są bezpiecznie odizolowane od kodu działającego na na jądrze i w nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy za pomocą którego jądro lub kod przestrzeni użytkownika może uzyskać dostęp do wewnętrznego stanu w odizolowanym środowisku, w tym DMA. Starsze oprogramowanie typu open source na Androida Projekt (AOSP) spełnia to wymaganie dzięki wdrożeniu Trusty. Rozwiązanie oparte na technologii ARM TrustZone lub zewnętrzne sprawdzone wdrożenie prawidłowej izolacji opartej na hipernadzorcy to alternatywne rozwiązanie .
• [9.11/T-0-3] MUSI obsługiwać ekran blokady w izolowanym środowisku wykonawczym i tylko wtedy, gdy pomyślne, zezwól na używanie kluczy powiązanych z uwierzytelnianiem. Ekran blokady dane logowania MUSZĄ być przechowywane w sposób umożliwiający wyłącznie izolowane uruchomienie aby przeprowadzić uwierzytelnianie przy zablokowanym ekranie. Nadrzędny Android Projekt open source zapewnia Warstwa abstrakcji sprzętowej bramy (HAL) i Trusty. Można je wykorzystać, aby spełnić to wymaganie.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Pamiętaj, że jeśli implementacja na urządzeniach została już wprowadzona na starszym Androidzie przez co urządzenie jest zwolnione z obowiązku posiadania magazynu kluczy są oparte na izolowanym środowisku wykonawczym i obsługują atest klucza; chyba że deklaruje on funkcję android.hardware.fingerprint, która wymaga żądania magazyn kluczy obsługiwany przez izolowane środowisko wykonawcze.

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

• [9.11/T-1-1] MUSI umożliwiać użytkownikowi wybór snu limit czasu oczekiwania na przejście z trybu odblokowanego do zablokowanego, ze znakiem minimalny dozwolony limit czasu to maksymalnie 15 sekund.

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

• [9.5/T-2-1] MUSI obsługiwać profile z ograniczonym dostępem, funkcję umożliwiającą właścicielom urządzeń zarządzanie dodatkowymi użytkownikami dostępnych na urządzeniu. Dzięki profilom ograniczonym właściciele urządzeń mogą szybko skonfigurować osobne środowiska do pracy dodatkowych użytkowników, oraz zarządzanie bardziej precyzyjnymi ograniczeniami w aplikacjach, które są dostępne w tych środowiskach.

Jeśli implementacje urządzeń telewizyjnych obejmują wielu użytkowników zadeklarować flagę funkcji android.hardware.telephony, oznacza to, że:

• [9.5/T-3-1] NIE MOŻE obsługiwać reklam z ograniczeniami profili, ale MUSZĄ być zgodne z implementacją AOSP. , aby włączyć lub wyłączyć innym użytkownikom dostęp 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 jest możliwy tylko przez usługę HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje pełniące role, o których mowa 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 aplikacje systemowe z widocznymi interfejsami lub bezpośrednią interakcją użytkownika.

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

• [9.8.2/T-5-1] MUSI wyświetlać wskaźnik aparatu, gdy ma dostęp do danych kamery, ale nie wtedy, gdy kamera jest uzyskują dostęp 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 dla aplikacje systemowe z widocznymi interfejsami lub bezpośrednią interakcją użytkownika.

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

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

2.4. Wymagania dotyczące zegarka

Zegarek Android Watch odnosi się do implementacji urządzenia z Androidem, której celem jest noszone na ciele, na przykład na nadgarstku.

Implementacje na urządzeniach z Androidem są zaliczane do zegarka, jeśli spełniają wszystkie następujące kryteria:

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

Dodatkowe wymagania opisane w pozostałej części tej sekcji dotyczą Androida Implementacje na zegarkach.

2.4.1. Sprzęt

Implementacje na zegarkach:

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

• [7.2.3/W-0-1] MUSI być dostępna funkcja Home i Wstecz, chyba że jest ustawiona wartość 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 użycie modelu 3-osiowego. przy użyciu akcelerometru.

Jeśli implementacje na zegarkach obsługują interfejs Vulkan:

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

Jeśli modele zegarka obejmują odbiornik GPS/GNSS, możliwość przejścia na aplikacje za pomocą funkcji android.hardware.location.gps oznacza to, że:

• [7.3.3/W-1-1] MUSI podawać wyniki pomiarów GNSS, gdy tylko zostaną nawet jeśli lokalizacja określona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
• [7.3.3/W-1-2] MUSI zgłaszać pseudozakresy i pseudozakresy GNSS w warunkach na świeżym powietrzu po określeniu lokalizacji oraz nieruchome lub poruszające się z szybkością mniejszą niż 0,2 metra na sekundę do kwadratu przyspieszenie, wystarczają do obliczenia pozycji z odległości do 20 metrów, a prędkość z dokładnością do 0,2 metra na sekundę, przez co najmniej 95% czasu.

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

• [7.3.4/W-2-1] MUSI być w stanie mierzyć zmiany orientacji ekranu. 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 zawierać co najmniej 1 GB nieulotna pamięć masowa dostępna na prywatne dane aplikacji (inaczej partycja „/data”).

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

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

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

2.4.2 Multimedia

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ć tryb uiMode = UI_MODE_TYPE_WATCH.
• [3.2.3.1/W-0-1] MUSI załadować wstępnie aplikacji czy komponentów usługi z modułem obsługi intencji, np. wszystkie wzorce filtra intencji publicznych zdefiniowane przez tę aplikację intencji wymienionych tutaj.

Implementacje na zegarkach:

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

Implementacje na zegarek, które deklarują android.hardware.audio.output flaga funkcji:

• [3.10/W-1-1] MUSI obsługiwać ułatwień dostępu innych firm usług Google.
• [3.10/W-SR-1] Zdecydowanie ZALECANE jest wstępne wczytywanie usługi ułatwień dostępu na urządzeniu są porównywalne lub przewyższające funkcjonalność funkcji Switch Access i TalkBack (dla języków obsługiwanych przez usługi ułatwień dostępu oparte na zamianie tekstu na mowę) Projekt open source TalkBack.

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

• [3.11/W-SR-1] Zdecydowanie ZALECANE jest dodanie Mechanizm zamiany tekstu na mowę obsługuje języki dostępne na urządzeniu.

• [3.11/W-0-1] MUSI obsługiwać instalację za pomocą funkcji zamiany tekstu na mowę innych firm.

2.4.4 Wydajność i moc

jeśli implementacje zegarka obejmują funkcje zwiększające wydajność urządzenia, funkcji zarządzania uwzględnionymi w AOSP lub rozszerzających dostępne funkcje. w AOSP:

• [8.3/W-SR-1] Zdecydowanie ZALECANE jest podanie dla użytkowników na wyświetlanie wszystkich aplikacji zwolnionych z trybu czuwania Uśpienie trybów oszczędzania energii.
• [8.3/W-SR-2] Zdecydowanie ZALECANE jest podanie aby włączyć lub wyłączyć funkcję oszczędzania baterii.

Implementacje na zegarkach:

• [8.4/W-0-1] MUSI zawierać profil zasilania na komponent, który określa bieżącą wartość zużycia dla każdego elementu sprzętowego i przybliżone zużycie baterii przez zgodnie z opisem w witrynie Android Open Source Project.
• [8.4/W-0-2] MUSI zgłaszać całą zasilanie wartości wykorzystania w miliiamperach godzin (mAh).
• [8.4/W-0-3] MUSI raportować moc procesora na wykorzystanie identyfikatora UID każdego procesu. W projekcie Android Open Source Project za pomocą modułu jądra uid_cputime.
• [8.4/W-0-4] MUSI zapewniać to zużycie energii dostępne w adb shell dumpsys batterystats należy użyć polecenia powłoki do dewelopera aplikacji.
• [8.4/W] POWINNO być przypisane do sam komponent sprzętowy, jeśli nie można przypisać wykorzystania energii przez komponent sprzętowy. do aplikacji.

2.4.5 Model zabezpieczeń

Implementacje na zegarkach:

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

Jeśli implementacje na zegarkach obejmują wielu użytkowników nie deklarują flagi funkcji android.hardware.telephony, oznacza to, że:

• [9.5/W-1-1] MUSI obsługiwać profile z ograniczonym dostępem, funkcję umożliwiającą właścicielom urządzeń zarządzanie dodatkowymi użytkownikami dostępnych na urządzeniu. Dzięki profilom ograniczonym właściciele urządzeń mogą szybko skonfigurować osobne środowiska do pracy dodatkowych użytkowników, oraz zarządzanie bardziej precyzyjnymi ograniczeniami w aplikacjach, które są dostępne w tych środowiskach.

Jeśli implementacje na zegarkach obejmują wielu użytkowników zadeklarować flagę funkcji android.hardware.telephony, oznacza to, że:

• [9.5/W-2-1] NIE MOŻE obsługiwać reklam z ograniczeniami profili, ale MUSZĄ być zgodne z implementacją AOSP. , aby włączyć lub wyłączyć innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

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

• [9.11.1/W-1-1] MUSI prosić użytkownika o zastosowanie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) częściej niż raz na 72 godziny.

2.5. Wymagania dotyczące motoryzacji

Implementacja na Androida Automotive dotyczy systemu centrali pojazdu. Android jako system operacyjny wybrany w ramach całości lub części systemu lub funkcje informacyjno-rozrywkowe.

Implementacje na urządzeniach z Androidem są klasyfikowane jako urządzenia motoryzacyjne, jeśli deklaracja jest funkcję android.hardware.type.automotive lub spełnić poniższe warunki 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 opisane w pozostałej części tej sekcji dotyczą Androida Implementacje na urządzeniach motoryzacyjnych.

2.5.1 Sprzęt

Implementacje na urządzeniach motoryzacyjnych:

• [7.1.1.1/A-0-1] MUSI mieć co najmniej 6 ekranów cali po przekątnej.
• [7.1.1.1/A-0-2] MUSI mieć układ rozmiaru ekranu o wymiarach co najmniej 750 dp x 480 dp.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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

• [7.1.4.1/A-0-1] MUSI zadeklarować OpenGL ES 3.1 lub nowszy.
• [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ń z Androidem obsługują język Vulkan:

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

Implementacje na urządzeniach motoryzacyjnych:

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [7.2.3/A-0-2] MUSI wysłać zarówno normalne, jak i długie naciśnięcie zdarzenie funkcji Wstecz (KEYCODE_BACK) do aplikacji na pierwszym planie.
• [7.3/A-0-1] MUSI wdrożyć i raportować GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED oraz PARKING_BRAKE_ON.
• [7.3/A-0-2] Wartość parametru NIGHT_MODE. flaga MUSI być zgodna z trybem dziennym/nocnym pulpitu i POWINNA być dane wejściowe czujnika jasności otoczenia. Czujnik jasności otoczenia MOŻE być taki sam jako Fotometr.
• [7.3/A-0-3] MUSI zawierać dodatkowe pole informacyjne czujnika TYPE_SENSOR_PLACEMENT. w ramach SensorAdditionalInfo dla każdego dostarczonego czujnika.
• [7.3/A-SR1] MAJ wieczorek nie ma już pewności Lokalizacja dzięki połączeniu GPS/GNSS z dodatkowymi czujnikami. Jeśli Lokalizacja Obecnie Zdecydowanie ZALECANE jest wdrożenie i zgłaszanie odpowiedni Sensor typy lub identyfikatory nieruchomości pojazdów .

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

• [7.3.1/A-0-4] MUSI być zgodna z układ współrzędnych czujnika samochodowego.

• [7.3/A-SR-1] Są STRONGLY_RECOMMENDENDED 3-osiowy akcelerometr i 3-osiowy żyroskop.

• [7.3/A-SR-2] Ssilnie_ZALECANE jest wdrożenie i raportowanie Czujnik TYPE_HEADING.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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

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

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

• [7.3.1/A-SR-1] Zdecydowanie ZALECANE jest wdrożenie akcelerometru kompozytowego dla akcelerometru o ograniczonych osiach.

Jeśli implementacje urządzeń motoryzacyjnych obejmują akcelerometr z wartością mniejszą niż 3 osie:

• [7.3.1/A-1-3] MUSI wdrożyć i raportować Czujnik TYPE_ACCELEROMETER_LIMITED_AXES.
• [7.3.1/A-1-4] MUSI wdrożyć i raportować Czujnik TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Jeśli żyroskop obejmuje urządzenia motoryzacyjne:

• [7.3.4/A-2-1] MUSI zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
• [7.3.4/A-2-3] MUSI być w stanie mierzyć zmiany orientacji ekranu. do 250 stopni na sekundę.
• [7.3.4/A-SR-1] Zdecydowanie ZALECANE jest skonfigurowanie żyroskopu w zakresie pomiarowym do +/-250 dps w celu maksymalizacji rozdzielczości. jak to tylko możliwe.

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

• [7.3.4/A-SR-2] Zdecydowanie ZALECANE jest wdrożenie żyroskop z komponentem dla żyroskopu z ograniczonymi osiami.

Jeśli implementacje urządzeń w branży motoryzacyjnej obejmują żyroskop z mniej niż 3 osiami:

• [7.3.4/A-4-1] MUSI wdrożyć i raportować Czujnik TYPE_GYROSCOPE_LIMITED_AXES.
• [7.3.4/A-4-2] MUSI wdrożyć i raportować Czujnik TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

jeśli implementacje urządzeń samochodowych obejmują odbiornik GPS/GNSS, obejmują komórkową transmisję danych za pomocą sieci komórkowej, to:

• [7.3.3/A-3-1] MUSI określić lokalizację za pierwszym razem. odbiornik GPS/GNSS zostanie włączony lub upłynie ponad 4 dni w ciągu 60 sekund.
• [7.3.3/A-3-2] MUSI spełniać kryteria dotyczące czasu do pierwszej poprawki zgodnie 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ą wysyłane po raz pierwszy) w dowolnym momencie lub po upływie 4+ dni). Wymaganie 7.3.3/C-1-2 to spotykane zwykle w pojazdach bez łączności komórkowej używanej do transmisji danych. wykorzystując prognozy orbity GNSS obliczone na odbiorniku lub ostatnią znaną lokalizację pojazdu wraz z możliwością realizacji transakcji co najmniej 60 sekund z satysfakcjonującą dokładnością pozycji 7.3.3/C-1-3 lub ich połączenie.

Jeśli implementacje urządzeń samochodowych obejmują czujnik TYPE_HEADING:

• [7.3.4/A-4-3] MUSI zgłaszać zdarzenia z częstotliwością co najmniej 1 Hz.
• [7.3.4/A-SR-3] STRONGLY_RECOMMENDED raportowania zdarzeń do co najmniej 10 Hz.
• POWINNA odnosić się do rzeczywistej północy.
• POWINNA być dostępna, nawet gdy pojazd jest nieruchomy.
• Wymagana jest rozdzielczość co najmniej 1 stopnia.

Implementacje na urządzeniach motoryzacyjnych:

• [7.4.3/A-0-1] MUSI obsługiwać Bluetooth i POWINNO obsługują Bluetooth LE.
• [7.4.3/A-0-2] Implementacje w Androidzie Automotive MUSI 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).

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Implementacje na urządzeniach motoryzacyjnych:

• [7.4.5/A] POWINNA obsługiwać technologię komórkową dzięki sieciowej łączności do transmisji danych.
• [7.4.5/A] MOŻE korzystać z interfejsu System API Stała NetworkCapabilities#NET_CAPABILITY_OEM_PAID dla i sieci, które powinny być dostępne dla aplikacji systemowych.

czy urządzenia obsługują odbiornik radiowy AM/FM i funkcje w dowolnej aplikacji:

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

Tylny aparat oznacza kamerę „w kierunku świata”, którą można umieścić w dowolnym znajduje się na pojeździe i jest zwrócony na zewnątrz kabiny pojazdu; czyli np. obrazu z kamery tylnej.

Przedni aparat oznacza kamerę dla użytkownika, która znajduje się w każdym znajduje się na pojeździe i jest zwrócony do wnętrza kabiny pojazdu; to wszystko obrazów użytkownika, np. do wideokonferencji i podobnych aplikacji.

Implementacje na urządzeniach motoryzacyjnych:

• [7.5/A-SR-1] Zdecydowanie ZALECANE jest dodanie przynajmniej jednego widoku skierowanego do świata kamery.
• MOŻE zawierać co najmniej 1 kamerę skierowanym do użytkownika.
• [7.5/A-SR-2] Zdecydowanie ZALECANE jest umożliwienie jednoczesnej transmisji dla wielu kamer.

Jeśli implementacje urządzeń mobilnych obejmują co najmniej jeden aparat, w kierunku całego świata, w przypadku takiego aparatu:

• [7.5/A-1-1] MUSI być zorientowana tak, by długi wymiar kamery był taki sam. z płaszczyzną X-Y osi czujnika samochodowego w Androidzie.
• [7.5/A-SR-3] Zdecydowanie ZALECANE jest użycie stałej ostrości lub EDOF. (rozszerzona głębia ostrości).
• [7.5/A-1-2] MUSI mieć główny aparat skierowany na świat z najniższym identyfikatorem.

Jeśli implementacje urządzeń mobilnych obejmują co najmniej jeden aparat, dla użytkownika, w przypadku takiego aparatu:

• [7.5/A-2-1] Główny aparat skierowany do użytkownika MUSI być aparatem skierowanym do użytkownika z najniższym identyfikatorem kamery.
• MOŻE być zorientowane w taki sposób, aby długi wymiar kamery był zgodny z wymiarami X i Y. płaszczyzny czujników w samochodach z Androidem.

jeśli wdrożenia urządzeń w branży motoryzacyjnej obejmują aparat dostępny android.hardware.Camera lub android.hardware.camera2 API, wówczas:

• [7.5/A-3-1] MUSI być zgodny z podstawowymi wymaganiami dotyczącymi aparatu podanymi w sekcji 7.5.

jeśli implementacje urządzeń samochodowych zawierają niedostępną kamerę, za pomocą interfejsu API android.hardware.Camera lub android.hardware.camera2, a następnie one:

• [7.5/A-4-1] MUSI być dostępny w usłudze Extended View System.

jeśli implementacje urządzeń w branży motoryzacyjnej obejmują co najmniej jedną kamerę dostępną przez Usługa systemu Extended View (Rozszerzony widok) w przypadku takiego aparatu:

• [7.5/A-5-1] NIE MOŻE obracać obrazu z kamery ani wyświetlać jego odbicia lustrzanego w poziomie.
• [7.5/A-SR-4] Zdecydowanie ZALECANE jest ustawienie rozdzielczości co najmniej 1,3. megapiksela.

Jeśli implementacje urządzeń samochodowych zawierają co najmniej jedną kamerę, dostępne zarówno przez usługę Extended View System, jak i android.hardware.Camera lub interfejsu API android.hardware.Camera2, a następnie w przypadku takiej kamery:

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

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

• [7.5/A-7-1] NALEŻY zaimplementować taki interfejs API aparatu za pomocą android.hardware.camera2 API lub interfejs Extended View System API.

Implementacje na urządzeniach motoryzacyjnych:

• [7.6.1/A-0-1] MUSI zawierać co najmniej 4 GB pamięć nieulotna dostępna na prywatne dane aplikacji (/data partycja).

• [7.6.1/A] POWINNO Sformatować partycję danych aby zwiększyć wydajność i trwałość pamięci flash (np. przy użyciu systemu plików f2fs).

Jeśli implementacje urządzeń w samochodach zapewniają współdzieloną pamięć zewnętrzną za pomocą pamięci wewnętrznej, która nie jest wymienna, spowoduje to:

• [7.6.1/A-SR-1] Zdecydowanie ZALECANE jest zmniejszenie narzuty I/O na operacje wykonywane w pamięci zewnętrznej, np. za pomocą funkcji SDCardFS.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

2.5.2 Multimedia

Implementacje na urządzeniach motoryzacyjnych MUSZĄ obsługiwać to kodowanie dźwięku formatów i dekodowania, a także udostępnić 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ć to kodowanie wideo formatów 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ć to dekodowanie wideo formatów 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ą wdrożenia na urządzeniach motoryzacyjnych, aby to dekodowanie wideo:

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

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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 android.car.*. przestrzeni nazw.

Jeśli implementacje urządzeń z branży motoryzacyjnej udostępniają zastrzeżony interfejs API, który korzysta z parametru android.car.CarPropertyManager z android.car.VehiclePropertyIds, one:

• [3/A-1-1] NIE MOŻE przypisywać specjalnych uprawnień do systemu używanie tych właściwości przez aplikację lub 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ż jest dostępny w pakiecie SDK.

Implementacje na urządzeniach motoryzacyjnych:

• [3.2.1/A-0-1] MUSI obsługiwać i egzekwować wszystkie stałych uprawnień, jak opisano na stronie z informacjami o uprawnieniach dotyczących motoryzacji.

• [3.2.3.1/A-0-1] MUSI załadować jeden lub aplikacji czy komponentów usługi z modułem obsługi intencji, dla wszystkich wzorce filtra intencji publicznych zdefiniowane przez te intencje aplikacji wymienione tutaj.

• [3.4.1/A-0-1] MUSI zawierać pełny implementacji interfejsu android.webkit.Webview API.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Implementacje na urządzeniach motoryzacyjnych:

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

• [3.8.4/A-SR-1] Zdecydowanie zalecane aby wdrożyć na urządzeniu asystenta do działania wspomagającego.

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

• [3.8.4/A-1-1] MUSI użyć krótkiego przycisku przycisk „Naciśnij, aby rozmawiać” jako czynność wyznaczoną do uruchomienia wybraną przez użytkownika aplikację asystującą, czyli aplikację, która stosuje VoiceInteractionService.

Implementacje na urządzeniach motoryzacyjnych:

• [3.8.3.1/A-0-1] MUSI prawidłowo renderowanie zasobów zgodnie z opisem w Notifications on Automotive OS Dokumentacja pakietu SDK.
• [3.8.3.1/A-0-2] MUSI wyświetlać ODTWÓRZ i Wycisz w przypadku działań związanych z powiadomieniami zamiast działań podanych przez Notification.Builder.addAction().
• [3.8.3.1/A] POWINNA ograniczać korzystanie z zaawansowanych funkcji zarządzania, takich jak kontrola 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 stosować 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, aplikacji innych firm korzystających z interfejsów API multimediów, jak opisano w sekcji 3.14.
• [3.14/A-0-2] MUSI umożliwiać użytkownikom bezpieczną interakcję za pomocą aplikacji multimedialnych podczas jazdy.
• [3.14/A-0-3] MUSI obsługiwać CAR_INTENT_ACTION_MEDIA_TEMPLATE. domyślnie określone działanie intencji CAR_EXTRA_MEDIA_PACKAGE. dodatkowe.
• [3.14/A-0-4] MUSI zawierać afordancję umożliwiającą przejście do aplikacji multimedialnej ustawienie aktywność, ale MUSI ją włączać tylko wtedy, gdy nie obowiązują ograniczenia dotyczące wygody użytkowników samochodu.
• [3.14/A-0-5] MUSI wyświetlać komunikaty o błędach ustawiony 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 aplikacji dla aplikacji z funkcją wyszukiwania.
• [3.14/A-0-7] MUSI szanować CONTENT_STYLE_BROWSABLE_HINT. i CONTENT_STYLE_PLAYABLE_HINT definicje podczas wyświetlania Media Browser w hierarchii.

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

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

Implementacje na urządzeniach motoryzacyjnych:

• [3.8/A] MOŻE ograniczyć możliwość aplikacji prosi o przejście w tryb pełnoekranowy, jak opisano w sekcji immersive documentation.
• [3.8/A] MOŻE utrzymać pasek stanu widoczny przez cały czas pasek nawigacyjny.
• [3.8/A] MOŻE ograniczyć możliwość aplikacji żądania zmiany kolorów za elementy interfejsu systemu, aby zapewnić są one 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, dzięki czemu statystyki są dostępne dla programistów przez interfejs System API android.car.storagemonitoring.CarStorageMonitoringManager Android Open Projekt źródłowy spełnia wymagania dzięki modułowi jądra uid_sys_stats.
• [8.3/A-1-3] MUSI obsługiwać tryb garażu.
• [8.3/A] POWINNY być w trybie garażowym przez 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 na komponent, który określa bieżącą wartość zużycia dla każdego elementu sprzętowego i przybliżone zużycie baterii przez zgodnie z opisem w witrynie Android Open Source Project.
• [8.4/A-0-2] MUSI zgłaszać całą zasilanie wartości wykorzystania w miliiamperach godzin (mAh).
• [8.4/A-0-3] MUSI raportować moc procesora na wykorzystanie identyfikatora UID każdego procesu. W projekcie Android Open Source Project za pomocą modułu jądra uid_cputime.
• [8.4/A] POWINNO być przypisane do sam komponent sprzętowy, jeśli nie można przypisać wykorzystania energii przez komponent sprzętowy. do aplikacji.
• [8.4/A-0-4] MUSI zapewniać to zużycie energii dostępne w adb shell dumpsys batterystats należy użyć polecenia powłoki do dewelopera 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 ani przełączać się na użytkownika systemowego bez interfejsu graficznego, oprócz obsługi administracyjnej urządzeń.
• [9.5/A-1-2] MUSI przejść na użytkownika dodatkowego przed BOOT_COMPLETED.
• [9.5/A-1-3] MUSI obsługiwać możliwość tworzenia gość nawet po osiągnięciu maksymalnej liczby użytkowników na urządzeniu.

Jeśli implementacje na urządzeniach motoryzacyjnych zadeklarują android.hardware.microphone, one:

• [9.8.2/A-1-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 mają tylko HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje pełniące role nazywane w artykuł 9.1 z identyfikatorem CDD [C-4-X].
• [9.8.2/A-1-2] NIE MOŻE ukrywać wskaźnika mikrofonu w aplikacje systemowe z widocznymi interfejsami lub bezpośrednią interakcją użytkownika.
• [9.8.2/A-1-3] MUSI umożliwiać użytkownikom przełączanie mikrofon w aplikacji Ustawienia.

Jeśli implementacje na urządzeniach motoryzacyjnych zadeklarują android.hardware.camera.any, wtedy one:

• [9.8.2/A-2-1] MUSI wyświetlać wskaźnik aparatu, gdy ma dostęp do danych kamery, ale nie wtedy, gdy kamera jest mają dostęp do aplikacji pełniących role określone w Sekcja 9.1 Uprawnienia o identyfikatorze CDD [C-4-X].
• [9.8.2/A-2-2] NIE MOŻE ukrywać wskaźnika aparatu dla aplikacje systemowe z widocznymi interfejsami lub bezpośrednią interakcją użytkownika.
• [9.8.2/A-2-3] MUSI zapewniać użytkownikowi możliwość przełączania aparatu w aplikacji Ustawienia.
• [9.8.2/A-2-4] MUSI wyświetlać ostatnie i aktywne aplikacje z aparatem w takiej postaci, w jakiej został zwrócony od PermissionManager.getIndicatorAppOpUsageData() oraz wszystkie wiadomości o atrybucji.

Implementacje na urządzeniach motoryzacyjnych:

• [9/A-0-1] MUSI zadeklarować android.hardware.security.model.compatible funkcji.
• [9.11/A-0-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/A-0-2] MUSI zawierać implementacje RSA, AES, algorytmy kryptograficzne ECDSA i HMAC oraz rodzina MD5, SHA-1 i SHA-2 funkcji skrótu do prawidłowej obsługi które są bezpiecznie odizolowane od kodu działającego na na jądrze i w nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy za pomocą którego jądro lub kod przestrzeni użytkownika może uzyskać dostęp do wewnętrznego stanu w odizolowanym środowisku, w tym DMA. Starsze oprogramowanie typu open source na Androida Projekt (AOSP) spełnia to wymaganie dzięki wdrożeniu Trusty. Rozwiązanie oparte na technologii ARM TrustZone lub zewnętrzne sprawdzone wdrożenie prawidłowej izolacji opartej na hipernadzorcy to alternatywne rozwiązanie .
• [9.11/A-0-3] MUSI włączać ekran blokady w izolowanym środowisku wykonawczym i tylko wtedy, gdy pomyślne, zezwól na używanie kluczy powiązanych z uwierzytelnianiem. Ekran blokady dane logowania MUSZĄ być przechowywane w sposób umożliwiający wyłącznie izolowane uruchomienie aby przeprowadzić uwierzytelnianie przy zablokowanym ekranie. Nadrzędny Android Projekt open source zapewnia Warstwa abstrakcji sprzętowej bramy (HAL) i Trusty. Można je wykorzystać, aby spełnić to wymaganie.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Pamiętaj, że jeśli implementacja na urządzeniach została już wprowadzona na starszym Androidzie przez co urządzenie jest zwolnione z obowiązku posiadania magazynu kluczy są oparte na izolowanym środowisku wykonawczym i obsługują atest klucza; chyba że deklaruje on funkcję android.hardware.fingerprint, która wymaga żądania magazyn kluczy obsługiwany przez izolowane środowisko wykonawcze.

Implementacje na urządzeniach motoryzacyjnych:

• [9.14/A-0-1] MUSI mieć dostęp do wiadomości od bramki z podsystemów pojazdu Android Framework, np. z dozwolenia wiadomości na listę dozwolonych typów wiadomości i źródeł wiadomości.
• [9.14/A-0-2] MUSI watchdog przeciwko ataki typu DoS za pomocą platformy Androida lub aplikacji innych firm. Ten chronią przed złośliwym oprogramowaniem zapełniającym sieć pojazdu kołem co może prowadzić do awarii podsystemów pojazdu.

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

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

2.6. Wymagania dotyczące tabletu

Tablet z Androidem odnosi się do implementacji urządzenia z Androidem, która zwykle spełnia wszystkie następujące 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 podczas łączenia urządzenia przez standardowego połączenia (np. USB lub Bluetooth).

• Ma źródło zasilania, które umożliwia mobilność, np. baterię.

• urządzenie ma wyświetlacz o przekątnej większej niż 7 cali i mniejszej niż 18 cali, mierzona z przekątną;

Implementacje na tabletach mają podobne wymagania co urządzenia mobilne implementacji. Wyjątki są w tej sekcji oznaczone symbolem * oraz warte uwagi w tej sekcji.

2.6.1 Sprzęt

Żyroskop

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

• [7.3.4/Tab-1-1] MUSI mieć możliwość pomiaru orientacji zmienia się do 1000 stopni na sekundę.

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

Gęstości ekranu wymienione dla małych/normalnych ekranów w urządzeniu mobilnym nie mają zastosowania do tabletów.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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 wdrożenia na tabletach obejmują wielu użytkowników nie deklarują flagi funkcji android.hardware.telephony, oznacza to, że:

• [9.5/T-1-1] MUSI obsługiwać profile z ograniczonym dostępem, funkcję umożliwiającą właścicielom urządzeń zarządzanie dodatkowymi użytkownikami dostępnych na urządzeniu. Dzięki profilom ograniczonym właściciele urządzeń mogą szybko skonfigurować osobne środowiska do pracy dodatkowych użytkowników, oraz zarządzanie bardziej precyzyjnymi ograniczeniami w aplikacjach, które są dostępne w tych środowiskach.

Jeśli wdrożenia na tabletach obejmują wielu użytkowników zadeklarować flagę funkcji android.hardware.telephony, oznacza to, że:

• [9.5/T-2-1] NIE MOŻE obsługiwać ograniczeń profili, ale MUSZĄ być zgodne z implementacją AOSP. , aby włączyć lub wyłączyć innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

2.6.2 Oprogramowanie

• [3.2.3.1/Tab-0-1] MUSI załadować wstępnie jedną aplikacji czy komponentów usługi z modułem obsługi intencji, dla wszystkich wzorce filtra intencji publicznych zdefiniowane przez te intencje aplikacji wymienione tutaj.

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

Zarządzanym środowiskiem wykonywania kodów bajtowych Dalvik jest Aplikacje na Androida. Interfejs programowania aplikacji (API) Androida to zestaw interfejsów platformy Androida dostępnych dla aplikacji działających w w zarządzanym środowisku wykonawczym.

Implementacje na urządzeniach:

• [C-0-1] MUSI dostarczyć kompletne implementacje, w tym wszystkie wszystkich udokumentowanych interfejsów API udostępnianych przez Pakiet SDK na Androida lub dowolny interfejs API ozdobiony znakiem „@SystemApi” znacznik w nadrzędnym systemie Android kodu źródłowego.

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

• [C-0-3] NIE MOŻE pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów API ani ich podpisów. odbiegać od udokumentowanego zachowania lub dodawać elementy bezobsługowe, z wyjątkiem dopuszczonych przez tę definicję zgodności.

• [C-0-4] MUSI utrzymywać dostępność i działanie interfejsów API nawet jeśli niektóre funkcje sprzętowe, na które Android zawiera interfejsy API, zostaną pominięte. Zobacz sekcję 7 pod kątem konkretnych wymagań dotyczących tego scenariusza.

• [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 Javy, które są w ścieżce rozruchu w AOSP i nie należą do publicznego SDK. Obejmuje to interfejsy API oznaczone adnotacją @hide, ale bez adnotacji @SystemAPI, zgodnie z opisem w dokumentach pakietu SDK. oraz prywatnych i prywatnych w postaci uczestników zajęć.

• [C-0-6] MUSI być dostarczany z każdym interfejsem innym niż SDK w ramach tych samych ograniczeń jak określono za pomocą flag tymczasowych i odrzuconych prebuilts/runtime/appcompat/hiddenapi-flags.csv dla odpowiedniej gałęzi interfejsu API w AOSP.

• [C-0-7] MUSI obsługiwać podpisaną konfigurację mechanizm aktualizacji dynamicznej do usuwania interfejsów spoza pakietu SDK z listy objętej ograniczeniami przez umieszczenie podpisanej konfiguracji w dowolnym pliku APK przy użyciu istniejących kluczy publicznych dostępnych w AOSP.

  Pamiętaj jednak, że:

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

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

3.1.1. Rozszerzenia na Androida

Android umożliwia rozszerzanie zarządzanej platformy interfejsu API na określonym poziomie interfejsu API przez zaktualizowanie wersji rozszerzenia dla tego poziomu interfejsu API. android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API zwraca błąd wersji rozszerzenia apiLevel, o ile istnieją rozszerzenia do tego elementu poziom interfejsu API.

Implementacje na urządzeniach z Androidem:

• [C-0-1] MUSI wstępnie wczytywać implementację AOSP zarówno w zasobach wspólnych, ExtShared i usługi ExtServices w wersji co najmniej minimalną liczbę wersji dozwolonych na każdym poziomie interfejsu API. Na przykład Android 7.0 na poszczególnych urządzeniach, uruchomiony interfejs API na poziomie 24 MUSI zawierać co najmniej wersji 1.

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

• [C-0-3] MUSI obsługiwać wszystkie interfejsy API zdefiniowane przez wersje rozszerzenia zwrócone przez: android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) w taki sam sposób, w jaki są obsługiwane inne zarządzane interfejsy API, zgodnie z wymagania opisane w sekcji 3.1.

3.1.2. Biblioteka Androida

W związku z wycofaniem klienta Apache HTTP implementacji na urządzeniach:

• [C-0-1] NIE NALEŻY umieszczać biblioteki org.apache.http.legacy w ścieżka startowa.
• [C-0-2] MUSI dodać do aplikacji bibliotekę org.apache.http.legacy classpath tylko wtedy, gdy aplikacja spełnia jeden z tych warunków:
  • Kierowanie na interfejs API na poziomie 28 lub niższym.
  • W pliku manifestu deklaruje, że potrzebuje biblioteki, ustawiając atrybut Atrybut android:name o wartości od <uses-library> do 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 zawiera też znaczną „łatwą” wersję, która jest dostępna tylko w czasie działania API w formie takiej np. intencje, uprawnienia i podobne aspekty aplikacji na Androida, nie może być wymuszana podczas kompilowania aplikacji.

3.2.1. Uprawnienia

• [C-0-1] Implementacje urządzenia MUSZĄ obsługiwać i wymuszać wszystkie uprawnienia stałe, jak opisano na stronie z informacjami o uprawnieniach. Uwaga: w sekcji 9 znajdują się związane z modelem zabezpieczeń Androida.

3.2.2. Parametry kompilacji

Interfejsy API Androida zawierają szereg stałych klasa android.os.Build które mają opisać obecne urządzenie.

• [C-0-1] Zapewnienie spójnych, wartościowych wartości na różnych urządzeniach implementacji, w tabeli poniżej znajdziesz dodatkowe ograniczenia dotyczące formatów wartości, z którymi MUSZĄ być zgodne implementacje urządzeń.

Parametr	Szczegóły
WERSJA.PREMIERA	Czytelna dla człowieka wersja obecnie uruchomionego systemu Android. . To pole MUSI mieć jedną z wartości ciągu zdefiniowanych w Ciągi znaków wersji dozwolone dla Androida 15.
WERSJA.SDK	Wersja obecnie uruchomionego systemu Android w formacie kod aplikacji innej firmy. W przypadku Androida 15: to pole MUSI zawierać liczbę całkowitą 15_INT.
VERSION.SDK_INT	Wersja obecnie uruchomionego systemu Android w formacie kod aplikacji innej firmy. W przypadku Androida 15: to pole MUSI mieć wartość całkowitą 15_INT.
WERSJA.INCREMENTALNA	Wartość wybrana przez osobę implementującą urządzenie wskazującą konkretną kompilację działającego obecnie systemu Android, w formacie zrozumiałym dla człowieka. Ten Wartość nie może być wykorzystywana ponownie w różnych wersjach udostępnianych użytkownikom. O typowym zastosowaniem tego pola jest wskazanie numeru kompilacji lub Do wygenerowania kompilacji został użyty identyfikator zmiany kontroli źródła. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII do wydrukowania i pasować do wyrażenie regularne ^[^ :\/~]+$.
PLANSZOWE	Wartość wybrana przez mechanizm implementujący urządzenie, identyfikujący konkretny Wewnętrzny sprzęt używany przez urządzenie w formacie zrozumiałym dla człowieka. Możliwe tego pola służy do wskazania konkretnej wersji płytki urządzenia. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII pasują do wyrażenia regularnego ^[a-zA-Z0-9_-]+$.
MARKI	Wartość odzwierciedlająca nazwę marki powiązaną z urządzeniem, o której mowa z myślą o użytkownikach. MUSI być w formacie zrozumiałym dla człowieka i POWINNA reprezentować producent urządzenia lub marka firmy, do której należy urządzenie. i promowaniu. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i dopasowanie wyrażenie regularne ^[a-zA-Z0-9_-]+$.
Obsługiwany_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) dla natywnego w kodzie. Zobacz sekcję 3.3. Natywny interfejs API Zgodność.
SUPPORTED_32_BIT_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) dla natywnego w kodzie. Zobacz sekcję 3.3. Natywny interfejs API Zgodność.
SUPPORTED_64_BIT_ABIS	Nazwa drugiego zbioru instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Reklama natywna Zgodność z interfejsami API.
CPU_ABI	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) dla natywnego w kodzie. Zobacz sekcję 3.3. Natywny interfejs API Zgodność.
CPU_ABI2	Nazwa drugiego zbioru instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Reklama natywna Zgodność z interfejsami API.
URZĄDZENIE	Wartość wybrana przez narzędzie implementujące urządzenie, która zawiera nazwę wersji deweloperskiej lub nazwa kodowa identyfikująca konfigurację funkcji sprzętowych to przemysłowa konstrukcja urządzenia. Wartość w tym polu MUSI być zakodowana jako 7-bitowy kod ASCII, dopasowany do wyrażenia regularnego ^[a-zA-Z0-9_-]+$ Tej nazwy urządzenia NIE MOŻNA zmieniać w okres użytkowania produktu.
DŹWIĘK	Ciąg jednoznacznie identyfikujący tę kompilację. Powinna ona być rozsądnie zrozumiałe dla człowieka. MUSI być zgodna z tym szablonem: $(BRAND)/$(PRODUKT)/ $(DEVICE):$(VERSION.release)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Na przykład: acme/mojprodukt/ mydevice:15/LMYXX/3359:userdebug/test-keys Odcisk palca NIE MOŻE zawierać odstępów. Wartość to pole MUSI być zakodowane jako 7-bitowy kod ASCII.
SPRZĘT	Nazwa sprzętu (z wiersza poleceń jądra lub /proc). it MUSZĄ być w granicach rozsądnie zrozumiałe dla człowieka. Wartość w tym polu MUSI być możliwe do zakodowania jako 7-bitowego kodu ASCII i pasujące do wyrażenia regularnego ^[a-zA-Z0-9_-]+$
GOSPODARZE	Ciąg jednoznacznie identyfikujący hosta, na którym została zbudowana kompilacja, zrozumiałego dla człowieka. Nie ma wymagań dotyczących konkretnego formatu w tym polu, oprócz tego, że NIE MOŻE mieć wartości null ani pustego ciągu („”).
ID	Identyfikator wybrany przez mechanizm implementujący urządzenie, aby odwołać się do konkretnego elementu w formacie zrozumiałym dla człowieka. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINNA mieć wystarczającą wartość co pomaga użytkownikom rozróżnić kompilacje oprogramowania. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasować do zwykłego wyrażenie ^[a-zA-Z0-9._-]+$.
PRODUCENT	Nazwa handlowa producenta oryginalnego sprzętu (OEM) usługi. Nie ma wymagań dotyczących konkretnego formatu tego pola. z tą różnicą, że NIE MOŻE mieć wartości null ani pustego ciągu („”). To pole NIE MOGĄ zmieniać się przez cały okres użytkowania produktu.
SOC_MANUFACTURER	Nazwa handlowa producenta systemu podstawowego na układu SOC, który jest używany w usłudze. Urządzenia z tym samym producentem SOC powinny mieć tę samą stałą wartość. Zapytaj producenta SOC o i wybiera odpowiednią stałą. Wartość w tym polu MUSI być zakodowana jako 7-bitowy kod ASCII, MUSI pasować do wyrażenia regularnego ^([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 ulec zmianie w trakcie okres użytkowania produktu.
SOC_MODEL	Nazwa modelu systemu podstawowego w układzie SOC używany w poszczególnych usług. Urządzenia o tym samym modelu SOC powinny używać tej samej 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 i pasować do wyrażenie regularne ^([0-9A-Za-z ._/+-]+)$, NIE MOŻE rozpoczynać się lub kończy się spacją i NIE MOŻE równać się „nieznane”. To pole NIE MOGĄ zmieniać się przez cały okres użytkowania produktu.
MODEL	Wartość wybrana przez narzędzie implementujące urządzenie, która zawiera nazwę elementu urządzenie znane użytkownikowi. POWINNA to być ta sama nazwa, pod którą urządzenie jest reklamowane i sprzedawane użytkownikom. Nie ma wymagań, konkretnego formatu tego pola, z tym wyjątkiem, że NIE MOŻE ono mieć wartości null ani pusty ciąg znaków („”). To pole NIE MOŻE ulec zmianie w trakcie okres użytkowania produktu.
USŁUGA	Wartość wybrana przez narzędzie implementujące urządzenie, która zawiera nazwę wersji deweloperskiej lub nazwę kodową konkretnego produktu (SKU). MUSI być niepowtarzalna w obrębie tej samej marki. MUSI być możliwa do odczytania przez człowieka, ale niekoniecznie do odczytu przez użytkowników. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII pasują do wyrażenia regularnego ^[a-zA-Z0-9_-]+$. Ten produkt Nazwa NIE MOŻE zmieniać się przez cały okres użytkowania produktu.
ODM_SKU	Opcjonalna wartość wybrana przez narzędzie do implementacji urządzenia, która zawiera: SKU (jednostka magazynowa) służąca do śledzenia określonych konfiguracji urządzenia, na przykład wszystkich urządzeń peryferyjnych dołączonej do niego, gdy są sprzedawane. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasować do wyrażenie regularne ^([0-9A-Za-z.,_-]+)$.
SERYJNY	MUSI zwracać wartość „UNKNOWN”.
TAGI	Rozdzielona przecinkami lista tagów wybranych przez narzędzie implementujące na urządzeniu, które jeszcze bardziej odróżnia kompilację. Tagi MUSZĄ być kodowane jako 7-bitowy kod ASCII. i pasują do wyrażenia regularnego ^[a-zA-Z0-9._-]+ oraz MUSI mają jedną z wartości odpowiadających 3 typowym platformom Androida konfiguracje podpisywania: wersja-klucze, klucze deweloperskie i klucze testowe.
CZAS	Wartość reprezentująca sygnaturę czasową wystąpienia kompilacji.
TYP	Wartość wybrana przez mechanizm implementujący urządzenie, określający środowisko wykonawcze konfiguracji kompilacji. To pole MUSI mieć jedną z wartości odpowiadający 3 typowym konfiguracjom środowiska wykonawczego Androida: użytkownik, userdebug lub ing.
UŻYTKOWNIK	Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował tworzyć. Nie ma wymagań dotyczących konkretnego formatu tego pola. z tą różnicą, że NIE MOŻE mieć wartości null ani pustego ciągu („”).
BEZPIECZEŃSTWO_PATCH	Wartość wskazująca poziom poprawki zabezpieczeń kompilacji. MUSI oznaczać że kompilacja nie jest w żaden sposób podatna na żadne z opisanych problemów. można znaleźć w wyznaczonym biuletynie na temat bezpieczeństwa publicznego w Androidzie. MUSI być w format [RRRR-MM-DD], który pasuje do zdefiniowanego ciągu opisanego w Bezpieczeństwo publiczne Androida Newsletter lub Usługa Android Security Advisory, na przykład „2015-11-01”.
PODSTAWA_OS	Wartość reprezentująca parametr FINGERINSERT w kompilacji, która jest są identyczne z tą kompilacją, z wyjątkiem poprawek dostarczonych w Biuletyn o bezpieczeństwie w Androidzie. MUSI podawać prawidłową wartość i 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 konkretny wewnętrznej wersji programu rozruchowego używanej w urządzeniu w formacie zrozumiałym dla człowieka. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasować do wyrażenie regularne ^[a-zA-Z0-9._-]+$.
getRadioVersion()	MUSI (być lub zwracać) wartość wybraną przez mechanizm implementujący urządzenie określającą wewnętrzną wersję radia/modema używaną w urządzeniu, w formacie zrozumiałym dla człowieka. Jeśli urządzenie nie ma żadnych wewnętrznych radio/modem MUSI zwracać wartość NULL. Wartość w tym polu MUSI być możliwe do zakodowania jako 7-bitowego kodu ASCII i pasujące do wyrażenia regularnego ^[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 MANUFACTURER. Wartość to pole MUSI być zakodowane jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego ^[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 z innymi komponentami Androida. Projekt nadrzędny na Androida zawiera listę które implementują kilka wzorców intencji w celu wykonywania typowych działań.

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest wstępne wczytanie jednej lub większej liczby aplikacji lub komponenty usługi z modułem obsługi intencji dla wszystkich filtrów intencji publicznych zdefiniowane przez te intencje aplikacji wymienione tutaj i dostarczanie realizacji, tj. spełnianie wymagań programisty w zakresie dla intencji aplikacji, zgodnie z opisem w pakiecie SDK.

Obowiązkowe intencje aplikacji znajdziesz w Sekcji 2. 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 każdy wzorzec intencji, o którym mowa w sekcji 3.2.3.1, z wyjątkiem Ustawienia, które mają zostać zastąpione przez aplikacje innych firm. pozwala na to domyślnie implementacja open source Androida.

• [C-0-2] Moduły implementujące urządzenie NIE MOGĄ przypisywać specjalnych uprawnień do systemu aplikacji wykorzystywania tych wzorców intencji lub uniemożliwiać korzystanie z aplikacji innych firm. od wiązania do nich i przejmowania nad nimi kontroli. Ten zakaz w szczególności dotyczy to m.in. wyłączenia funkcji wyboru użytkownik który pozwala użytkownikowi wybierać spośród wielu aplikacji, obsługują ten sam wzorzec intencji.

• [C-0-3] Implementacje urządzeń MUSZĄ zapewniać użytkownikom interfejs zmienić domyślną aktywność na potrzeby intencji.

• Jednak implementacje na urządzeniach MOGĄ wyświetlić domyślne działania dla określonych URI (np. http://play.google.com), jeśli aktywność domyślna to bardziej szczegółowego atrybutu identyfikatora URI danych. Na przykład wzorzec filtra intencji podając identyfikator URI danych „http://www.android.com” jest bardziej szczegółowe niż podstawowego wzorca intencji przeglądarki dla „http://”.

Android zawiera również mechanizm deklarowania przez aplikacje innych firm domyślne linki do aplikacji dla określonych typów intencji identyfikatora URI. Gdy takie wiarygodne deklaracje są zdefiniowane we wzorach filtra intencji aplikacji, implementacje urządzeń:

• [C-0-4] MUSI próbować zweryfikować filtry intencji, wykonując metodę kroki weryfikacji opisane w specyfikacji linków do zasobów cyfrowych. zgodnie z implementacją za pomocą menedżera pakietów na nadrzędnym kanale open source Androida. Projekt.
• [C-0-5] MUSI próbować zweryfikować filtry intencji podczas instalacji aplikacji oraz ustaw wszystkie poprawnie zweryfikowane filtry intencji URI na domyślnych modułów obsługi aplikacji dla ich identyfikatorów URI.
• MOŻE ustawić konkretne filtry intencji URI jako domyślne moduły obsługi aplikacji dla ich identyfikatorów URI po pomyślnej weryfikacji, ale niepowodzenie innych filtrów URI kandydatów weryfikacji. Jeśli tak jest, MUSI zawierać parametr odpowiednich dla użytkownika w menu ustawień.
• MUSI udostępniać w Ustawieniach opcje linków dla poszczególnych aplikacji jako następujące:
  • [C-0-6] Użytkownik MUSI mieć możliwość całościowego zastąpienia domyślnej aplikacji zachowanie linków w aplikacji: zawsze otwieraj, zawsze pytaj lub nigdy nie otwieraj, który musi mieć zastosowanie do wszystkich kandydujących filtrów intencji URI.
  • [C-0-7] Użytkownik MUSI zobaczyć listę intencji URI kandydata filtry.
  • Implementacja na urządzeniu MOŻE dawać użytkownikowi możliwość zastąp wybrane filtry intencji URI, które udało się zweryfikowanych za pomocą filtrów według intencji.
  • [C-0-8] Wdrożenie na urządzeniu MUSI dawać użytkownikom możliwość wyświetlanie i zastępowanie określonych filtrów intencji URI kandydatów, jeśli urządzenie umożliwia zastosowanie niektórych filtrów intencji URI kandydatów weryfikacji, podczas gdy inne mogą się nie powieść.

3.2.3.3 Przestrzenie nazw intencji

• [C-0-1] Implementacje na urządzeniu NIE MOGĄ zawierać żadnych komponentów Androida, które uwzględnia nowe intencje lub wzorce zamiarów transmisji za pomocą atrybutów ACTION, CATEGORY lub 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ędnianie nowych intencji lub wzorców zamiarów transmisji za pomocą atrybutów ACTION, CATEGORY lub inny ciąg klucza w obszarze pakietu należącym do innej organizacji.
• [C-0-3] Osoby wdrażające urządzenie NIE MOGĄ zmieniać ani rozszerzać żadnego z intencji wymienionych w sekcji 3.2.3.1.
• Implementacje na urządzeniach MOGĄ wyraźnie zawierać wzorce intencji wykorzystujących przestrzenie nazw i wyraźnie powiązanych z własną organizacją. Ten zakaz jest analogicznie do klasy określonej 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 powiadamiać użytkownika o zmianach w środowisku sprzętowym lub oprogramowania.

Implementacje na urządzeniach:

• [C-0-1] MUSI transmitować publiczne komunikaty o transmisjach wymienione tutaj w reakcji na odpowiednie zdarzenia systemowe zgodnie z opisem w dokumentacji pakietu SDK. Ten wymóg nie jest sprzeczny z sekcją 3.5, ponieważ ograniczenia aplikacji działających w tle zostały również opisane w pakiecie SDK dokumentacji. Ponadto niektóre intencje transmisji zależą od sprzętu. obsługi klienta. Jeśli urządzenie obsługuje niezbędny sprzęt, MUSI transmitować intencjami i zapewnić działanie zgodnie z dokumentacją pakietu SDK.

3.2.3.5. Warunkowe intencje aplikacji

Android zawiera ustawienia, które ułatwiają użytkownikom domyślnych aplikacji, takich jak ekran główny czy SMS-y.

W stosownych przypadkach implementacje na urządzeniach MUSZĄ oferować podobne ustawienia oraz być zgodne ze wzorcem filtra intencji i opisanymi metodami interfejsu API. znajdziesz w dokumentacji pakietu SDK jak poniżej.

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

• [C-1-1] MUSI spełniać warunki standardu android.settings.HOME_SETTINGS Nie chcesz już wyświetlać domyślnego menu ustawień na ekranie głównym.

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

• [C-2-1] MUSI zawierać menu ustawień, które wywoła funkcję android.provider.Telephony.ACTION_CHANGE_DEFAULT wyświetlić okno zmiany domyślnej aplikacji SMS.

• [C-2-2] MUSI spełniać warunki standardu android.telecom.action.CHANGE_DEFAULT_DIALER Wyświetlenie okna umożliwiającego zmianę domyślnego telefonu aplikacji.

  • MUSI używać wybranego przez użytkownika domyślnego interfejsu aplikacji Telefon do połączeń przychodzących i połączeń wychodzących, z wyjątkiem połączeń alarmowych, w przypadku których używany jest zainstalowana fabrycznie aplikacja Telefon.

• [C-2-3] MUSI spełniać warunki android.telecom.action.CHANGE_PHONE_ACCOUNTS. intencja użytkownika, aby skonfigurować ConnectionServices powiązane z PhoneAccounts, jak oraz domyślne konto telefoniczne, które dostawca usług telekomunikacyjnych służy do nawiązywania połączeń wychodzących. Implementacja AOSP spełnia to wymaganie przez: w tym opcję „Konta telefoniczne”, w menu „Połączenia”. menu ustawień.

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

• [C-2-5] MUSI zapewniać użytkownikom wybór aplikacji, która obsługuje android.app.role.CALL_REDIRECTION rolę użytkownika.

• [C-2-6] MUSI spełniać warunki android.intent.action.SENDTO i android.intent.action.VIEW i wysyłać/wyświetlać wiadomości SMS.

• [C-SR-1] Zdecydowanie ZALECANE jest wykorzystanie odpowiedzi na pytanie android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_Button, android.intent.action.VIEW i android.intent.action.DIAL z załadowaną aplikacją telefonu, która radzi sobie z tymi intencjami, zapewnić realizację zgodnie z opisem w pakiecie SDK.

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

• [C-3-1] MUSI spełniać warunki android.settings.NFC_PAYMENT_SETTINGS wyświetlić domyślne menu ustawień aplikacji dla płatności zbliżeniowych.
• [C-3-2] MUSI spełniać warunki android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT ma zamiar pokazać czynność, która otwiera okno z prośbą o zmianę domyślna usługa emulacji kart w 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 pokazać aktywność, która spełnia oczekiwania deweloperów w odniesieniu do tych intencji, opisane w pakiecie SDK.

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

• [C-5-1] MUSI spełniać warunki 'android.bluetooth.adapter.action.REQUEST_ENABLE' oraz wyświetlić aktywność systemu, aby umożliwić użytkownikowi włączenie Bluetootha.
• [C-5-2] MUSI spełniać warunki „android.bluetooth.adapter.action.REQUEST_DISCOVERABLE” i pokażą aktywność systemu, która żąda trybu wykrywalnego.

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

• [C-6-1] MUSI wdrożyć działanie, które zareaguje na intencję ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS dla których w implementacjach z interfejsem UI_MODE_TYPE_NORMAL MUSI być to działanie, w którym użytkownik może przyznać lub odmówić aplikacji dostęp do konfiguracji zasad Nie przeszkadzać.

Jeśli implementacje urządzeń pozwalają użytkownikom na korzystanie z metod wprowadzania danych innych firm urządzenia, to:

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

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

• [C-8-1] MUSI spełniać warunki standardu android.settings.ACCESSIBILITY_SETTINGS udostępniającym dostępny dla użytkowników mechanizm włączania i wyłączania usługi ułatwień dostępu innych firm oprócz wstępnie wczytanych ułatwień dostępu usług Google.

Jeśli urządzenia obsługują Wi-Fi Easy Connect i udostępnić funkcji aplikacji innych firm:

• [C-9-1] MUSI zaimplementować Ustawienia#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Interfejsy API intencji zgodnie z opisem 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 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS Intencje, które pozwalają użytkownikom dodawać aplikacje do listę dozwolonych.

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

• [C-11-1] MUSI mieć aktywność, która obsługuje Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS ale MOGĄ wdrożyć tę metodę jako no op.

Jeśli implementacje urządzenia zadeklarują obsługę kamery przez android.hardware.camera.any, to:

• [C-12-3] MUSI obsługiwać i MUSI zezwalać tylko na zainstalowane fabrycznie aplikacje na Androida do obsługi następujących 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 aby wywołać interfejs użytkownika przez dodanie administratora urządzenia system (lub umożliwienie mu jego odrzucenia).

• [C-13-2] MUSI przestrzegać intencji android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD i android.app.action.START_ENCRYPTION i mają działanie zapewniające realizację tych intencji, zgodnie z opisem w pakiecie SDK znajdziesz tutaj.

Jeśli implementacje urządzenia zadeklarują parametr android.software.autofill flagę cechy, oznacza to, że:

• [C-14-1] MUSI w pełni wdrożyć AutofillService i AutofillManager interfejsów API oraz zasady android.settings.REQUEST_SET_AUTOFILL_SERVICE. z intencją wyświetlenia domyślnego menu ustawień aplikacji, które pozwala włączyć i wyłączyć autouzupełnianie zmienić domyślną usługę autouzupełniania dla użytkownika.

Jeśli implementacje urządzeń obejmują wstępnie zainstalowaną aplikację lub chcesz zezwolić na aplikacji innych firm, aby uzyskać dostęp do statystyk użytkowania,:

• [C-SR-2] Zdecydowanie ZALECANE jest udostępnienie dla użytkownika mechanizmu przyznawania lub unieważnić dostęp do statystyk użytkowania w odpowiedzi na android.settings.ACTION_USAGE_ACCESS_SETTINGS dla aplikacji, które deklarują intencję android.permission.PACKAGE_USAGE_STATS uprawnienia.

Jeśli implementacje urządzenia mają na celu zablokowanie dostępu do aplikacji, w tym zainstalowanych fabrycznie dostępu do statystyk użytkowania aplikacji:

• [C-15-1] MUSI mieć aktywność, która obsługuje android.settings.ACTION_USAGE_ACCESS_SETTINGS ale MUSI wdrożyć go w trybie no-op, aby mieć odpowiednik w takiej sytuacji, jak w przypadku odmowy dostępu.

Jeśli implementacje urządzeń wyświetlają linki do działań określonych przez AutofillService_passwordsActivity Ustawienia lub linki do haseł użytkowników przy użyciu podobnego mechanizmu:

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

Jeśli implementacje urządzeń obsługują VoiceInteractionService i mają więcej więcej niż jednej aplikacji korzystającej z tego interfejsu API, użytkownik:

• [C-18-1] MUSI spełniać warunki standardu android.settings.ACTION_VOICE_INPUT_SETTINGS z zamiarem wyświetlenia domyślnego menu ustawień aplikacji z funkcją głosowego wprowadzania tekstu i Asystenta.

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

• [C-SR-3] Zdecydowanie ZALECANE jest działanie funkcji android.intent.action.TTS_SERVICE. android.speech.tts.engine.INSTALL_TTS_DATA & Intencje android.speech.tts.engine.GET_SAMPLE_TEXT mają działanie, które zapewnia działanie dla tych intencji, jak opisano w tym artykule w pakiecie SDK.

Android zapewnia obsługę interaktywnych wygaszaczy ekranu. jak Marzy. Wygaszacze ekranu pozwalają użytkownikom na interakcję z aplikacjami, gdy urządzenie urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji biurkowej. Implementacje na urządzeniach:

• MUSI obsługiwać wygaszacze ekranu i opcję ustawień dla konfigurowania wygaszaczy ekranu w odpowiedzi na Intencja android.settings.DREAM_SETTINGS.

Jeśli implementacje na urządzeniach zgłaszają android.hardware.nfc.uicc lub android.hardware.nfc.ese, one:

• [C-19-1] MUSI zaimplementować parametr NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API (jako „EVT_TRANSACTION” zgodnie z definicją podaną w specyfikacji technicznej Stowarzyszenia GSM TS.26 – Wymagania dotyczące telefonu NFC).

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 ponad jeden wyświetlacz, to:

• [C-1-1] MUSI ustawić android.software.activities_on_secondary_displays flagę funkcji.
• [C-1-2] MUSI gwarantować zgodność z interfejsem API podobną do aktywności uruchomionej na głównego wyświetlacza.
• [C-1-3] MUSI wyświetlić nową aktywność na tym samym ekranie co aktywność, po uruchomieniu nowej aktywności bez określania celu, wyświetlać za pomocą ActivityOptions.setLaunchDisplayId() API.
• [C-1-4] MUSI zniszczyć wszystkie działania, gdy zostanie wyświetlony Display.FLAG_PRIVATE flaga została usunięta.
• [C-1-5] MUSI bezpiecznie ukrywać treści na wszystkich ekranach, gdy urządzenie jest zablokowane korzysta z bezpiecznego ekranu blokady, chyba że aplikacja ma włączone wyświetlanie na nim blokady za pomocą Activity#setShowWhenLocked() API.
• POWINNA PRZEDSTAWIĆ android.content.res.Configuration który odpowiada temu ekranowi, aby były wyświetlane, oraz zachowuj zgodność, jeśli aktywność jest uruchamiana na dodatkowy wyświetlacz.

Jeśli implementacje urządzeń pozwalają na uruchamianie zwykłych aktywności na Androidzie na dodatkowych a drugi wyświetlacz ma android.view.Display.FLAG_PRIVATE flaga:

• [C-3-1] Wyłącznie właściciel wyświetlacza, systemu i działań, które są na tym wyświetlaczu MUSISZ mieć możliwość uruchomienia na nim. Każdy może uruchomić ekran z elementem android.view.Display.FLAG_PUBLIC, flaga.

3.3. Zgodność z natywnym interfejsem API

Zgodność kodu natywnego stanowi wyzwanie. Z tego powodu implementujące urządzenia:

• [C-SR-1] Zdecydowanie ZALECANA do korzystania z wdrożeń bibliotek wymienionych poniżej z nadrzędnego projektu Android Open Source.

3.3.1 Interfejsy binarne aplikacji

Zarządzany kod bajtowy Dalvik może wywoływać kod natywny podany w aplikacji .apk w postaci pliku ELF .so skompilowanego dla odpowiedniego sprzętu. i architekturą. Kod natywny w dużym stopniu zależy od procesora Android definiuje kilka interfejsów binarnych aplikacji 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 do kodu natywnego przy użyciu standardowego interfejsu natywnego Java (JNI) semantyka.
• [C-0-3] MUSI być zgodny ze źródłem (tzn. z nagłówkiem) i zgodne z kodem binarnym (dla ABI) z każdą wymaganą biblioteką na liście poniżej.
• [C-0-5] MUSI dokładnie zgłaszać natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pomocą interfejsu android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS i Parametry android.os.Build.SUPPORTED_64_BIT_ABIS, rozdzielone przecinkami lista interfejsów ABI uporządkowana od najbardziej do najmniej preferowanego.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-0-7] MUSI utworzyć wszystkie poniższe biblioteki, udostępniając natywne interfejsy API dostępne dla aplikacji zawierających kod natywny:

  • libaaudio.so (natywna obsługa dźwięku AAudio).
  • libamidi.so (wbudowana obsługa MIDI, jeśli funkcja android.software.midi zostało zgłoszone zgodnie z opisem w sekcji 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 bibliotek natywnych wymienionych powyżej.

• [C-0-9] MUSI zawierać dodatkowe biblioteki inne niż AOSP dostępne bezpośrednio aplikacje innych firm w usłudze /vendor/etc/public.libraries.txt.

• [C-0-10] NIE MOŻE udostępniać żadnych innych bibliotek natywnych, wdrożonych udostępniane w AOSP jako biblioteki systemowe do aplikacji innych firm kierujących reklamy na interfejs API na poziomie 24 lub wyższym, ponieważ są one zarezerwowane.

• [C-0-11] MUSI wyeksportować wszystkie pakiety rozszerzeń OpenGL ES 3.1 i Android Extension Pack symboli funkcji zgodnie z definicją w NDK za pomocą biblioteki libGLESv3.so. Pamiętaj, że o ile MUSZĄ być obecne wszystkie symbole, zgodnie z sekcją 7.1.4.1 o tym, jakie wymagania należy spełnić w przypadku pełnego wdrożenia każdego oczekiwanych funkcji są odpowiednie funkcje.

• [C-0-12] MUSI wyeksportować symbole funkcji podstawowej Funkcja Vulkan 1.1 a także VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 i VK_KHR_get_physical_device_properties2 rozszerzeń przez libvulkan.so. Pamiętaj, że wszystkie symbole MUSZĄ być obecne, art. 7.1.4.2 bardziej szczegółowo opisuje wymagania dotyczące sytuacji, niektórych z tych funkcji.

• POWINNA budować za pomocą kodu źródłowego i plików nagłówka dostępnych projektu open source Androida.

Kolejne wersje Androida mogą wprowadzać obsługę interfejsy ABI.

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ć usługę armeabi-v7a i zgłaszać jej wsparcie zgodnie z Element armeabi zapewnia tylko zgodność wsteczną ze starszymi aplikacjami.

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

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

  • Features:, a następnie lista wszystkich opcjonalnych funkcji procesora ARMv7 obsługiwane przez urządzenie.
  • CPU architecture:, a po nim liczba całkowita opisująca najwyżej obsługiwana architektura ARM (np. „8” na urządzeniach z architekturą ARMv8).

• [C-2-2] Trzeba zawsze przechowywać następujące operacje, nawet w w którym interfejs ABI jest wdrożony w architekturze ARMv8, za pomocą natywną obsługę procesora lub przez emulację oprogramowania:

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

• [C-2-3] MUSI obsługiwać zaawansowaną kartę SIMD (inaczej NEON).

3.4 Zgodność z internetem

3.4.1 Zgodność z WebView

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

• [C-1-1] MUSI zgłosić użytkownika android.software.webview.
• [C-1-2] MUSI używać kompilacji z projektu Chromium z projektu Android Open Source na Androida 15 która zajmuje się wdrażaniem android.webkit.WebView. API.

• [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ść android.os.Build.VERSION.release.
  • Ciąg znaków $(MODEL) MOŻE być pusty, ale jeśli nie jest pusty, MUSI mieć tę samą wartość co android.os.Build.MODEL.
  • „Kompilacja/$(BUILD)” MOŻE zostać pominięte, ale jeśli zawiera parametr $(BUILD) ciąg znaków MUSI być taki sam jak wartość w polu android.os.Build.ID.
  • Wartość ciągu $(CHROMIUM_VER) MUSI być wersją Chromium w nadrzędnym projekcie Android Open Source.
  • Implementacje na urządzeniach MOGĄ pominąć element „mobilny” w ciągu znaków klienta użytkownika.

• Komponent WebView POWINIEN obsługiwać tyle funkcji HTML5, ile to możliwe, a jeśli obsługuje funkcję, MUSI być zgodna z Specyfikacja HTML5.

• [C-1-4] MUSI renderować podaną treść lub zdalny adres URL w ramach procesu różnią się od aplikacji, która tworzy wystąpienie komponentu WebView. Więcej szczegółów osobny proces renderowania MUSI mieć niższe uprawnienia, uruchom polecenie jako osobnego identyfikatora użytkownika, nie mają dostępu do katalogu danych aplikacji, nie mają bezpośredniego dostępu do sieci i mają dostęp tylko do minimalnych wymaganych usług systemowych w ramach usługi Binder. Implementacja AOSP komponentu WebView spełnia tego wymogu.

Pamiętaj, że jeśli implementacje urządzeń są 32-bitowe lub zadeklaruj flagę funkcji android.hardware.ram.low, są zwolnione z obowiązku spełniania wymogów tych zasad C-1–3.

3.4.2. Zgodność z przeglądarką

Jeśli implementacje urządzeń obejmują samodzielną aplikację przeglądarki dla ogółu użytkowników podczas 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
  • <film>
  • geolokalizacja
• [C-1-2] MUSI obsługiwać format HTML5/W3C webstorage API i POWINNO obsługiwać HTML5/W3C Interfejs API IndexedDB. Pamiętaj, że jako witryna organy zajmujące się standardami programowania wolą korzystać z IndexedDB webstorage, IndexedDB ma stać się wymaganym komponentem wersji Androida.
• MOŻE przesłać niestandardowy ciąg znaków klienta użytkownika do samodzielnej aplikacji przeglądarki.
• POTRZEBUJESZ wsparcia dla tak dużej HTML5, jak to tylko możliwe w samodzielnej wersji aplikacja przeglądarki (w oparciu o nadrzędną przeglądarkę WebKit, aplikacji lub zastępczym narzędziu innej firmy).

Jeśli jednak implementacje urządzeń nie zawierają samodzielnej przeglądarki aplikacji, to znaczy, że:

• [C-2-1] MUSI nadal wspierać publiczne wzorce intencji, jak opisano w art. 3.2.3.1.

3.5. Zgodność behawioralna interfejsu API

Implementacje na urządzeniach:

• [C-0-9] MUSI mieć pewność, że do wszystkich elementów zainstalowanych aplikacji, chyba że dostęp do nich jest ograniczony zgodnie z opisem w Artykuł 3.5.1.
• [C-0-10] NIE MOŻE wdrażać metody dodawania do listy dozwolonych, która zapewnia interfejs API zgodność behawioralna tylko w przypadku aplikacji wybranych przez urządzenie implementacji.

Działanie każdego z typów interfejsów API (zarządzane, łagodne, natywne i internetowe) musi być zgodne z preferowaną implementacją kodu nadrzędnego Projekt Android Open Source. Niektóre konkretne obszary są takie:

• [C-0-1] Urządzeń NIE MOŻNA zmieniać działania ani semantyki o standardowej intencji.
• [C-0-2] Urządzenia NIE MOGĄ zmieniać semantyki cyklu życia ani semantyki określonego typu komponentu systemu (np. Service, Activity, ContentProvider itp.).
• [C-0-3] Urządzenia NIE MOGĄ zmieniać semantyki uprawnień standardowych.
• Urządzenia NIE MOGĄ zmieniać ograniczeń nałożonych na aplikacje w tle. Bardziej szczegółowo:
  • [C-0-4] MUSI zaprzestać wykonywania wywołań zwrotnych zarejestrowanych przez do odbierania danych wyjściowych z GnssMeasurement i GnssNavigationMessage.
  • [C-0-5] MUSZĄ ograniczać częstotliwość aktualizacji udostępnianej aplikacji za pomocą LocationManager klasa interfejsu API lub parametr WifiManager.startScan() .
  • [C-0-6] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, NIE MOŻE pozwalają rejestrować odbiorniki na potrzeby niejawnych transmisji standardowych intencji Androida w pliku manifestu aplikacji, chyba że intencja wymaga "signature" lub "signatureOrSystem" protectionLevel. lub znajdują się listę wykluczeń.
  • [C-0-7] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zostać zatrzymana usług w tle, tak jakby aplikacja wywoływała usług stopSelf() chyba że aplikacja została umieszczona na tymczasowej liście dozwolonych w celu obsługi widoczne dla użytkownika.
  • [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI JEST Puść blokady uśpienia ustawione przez aplikację.
• [C-0-11] Urządzenia MUSZĄ zwrócić w pierwszym kroku listę dostawców zabezpieczeń wymienionych poniżej siedem wartości tablicowych z argumentu Security.getProviders() w podanej kolejności i z podanymi nazwami (z podanymi przez Provider.getName()) i klas, chyba że aplikacja zmodyfikowała listę za pomocą insertProviderAt() lub removeProvider(). Urządzenia MOŻE zwrócić dodatkowych dostawców po określonej liście dostawców poniżej.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. 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. testy CTS (Compatibility Test Suite). ale nie wszystkie z nich. Odpowiedzialność za zapewnienie zgodności pod kątem działania spoczywa na Tobie. w ramach Android Open Source Project. Z tego powodu TREŚCI POWINNY jest używać kodu źródłowego dostępnego w ramach projektu Android Open Source, jest to możliwe, bez konieczności wprowadzania zmian na nowo.

3.5.1 Ograniczenie aplikacji

jeśli implementacje urządzeń implementują zastrzeżony mechanizm ograniczania dostępu aplikacji; (np. przez zmianę lub ograniczenie działań API, które opisane w pakiecie SDK) oraz ten mechanizm jest bardziej ograniczony niż zasobnik gotowości aplikacji z ograniczonym dostępem, tzn.:

• [C-1-1] MUSI umożliwiać użytkownikowi wyświetlenie listy aplikacji objętych ograniczeniami.
• [C-1-2] MUSZĄ zapewnić użytkownikom wsparcie w zakresie włączenia / wyłączenia wszystkich tych funkcji i ograniczeniach zastrzeżonych w każdej aplikacji.

• [C-1-3] NIE MOŻE automatycznie stosować tych ograniczeń zastrzeżonych bez wskazuje na słabe działanie systemu, ale MOŻE nałożyć ograniczenia na aplikacje po wykryciu nieprawidłowego działania systemu, takiego jak ciągłe blokady uśpienia, usług i innych kryteriów. Kryteria MOGĄ być określone przez urządzenie implementacji, ale MUSZĄ być związana z wpływem aplikacji na stan systemu. Inny powód kryteria, które nie są bezpośrednio związane ze stanem systemu, takie jak braku popularności na rynku, NIE POWOLNO być wykorzystywane jako kryterium.

• [C-1-4] NIE MOŻE automatycznie stosować tych zastrzeżonych ograniczeń do aplikacji gdy użytkownik ręcznie wyłączył ograniczenia aplikacji i MOŻE zasugerować mu tych ograniczeń zastrzeżonych.

• [C-1-5] MUSI informować użytkowników, jeśli te ograniczenia zastrzeżone są stosowane do automatycznie uruchamiać aplikację. Takie informacje MUSZĄ zostać dostarczone w ciągu 24 godzin przed zastosowaniem tych ograniczeń zastrzeżonych.

• [C-1-6] MUSI zwracać wartość „prawda” w przypadku funkcji ActivityManager.isBackgroundRestricted() dla dowolnych wywołań interfejsu API z aplikacji.

• [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ć te zastrzeżone ograniczenia w aplikacji za każdym razem, użytkownik zaczyna bezpośrednio korzystać z aplikacji, czyniąc ją pierwszym pierwszym planem. aplikacji.

• [C-1-10] MUSI dostarczyć publiczny i jasny dokument lub witrynę opisującą stosowania ograniczeń zastrzeżonych. Ten dokument lub witryna MUSI być w dokumentacji pakietu Android SDK i MUSI zawierać:

  • Wyzwalanie warunków ograniczeń zastrzeżonych.
  • Jakie i w jaki sposób aplikacje mogą podlegać ograniczeniom.
  • Jak aplikacja może zostać zwolniona z tych ograniczeń.
  • Jak aplikacja może poprosić o zwolnienie z ograniczeń zastrzeżonych, jeśli: obsługiwać takie wyjątek w przypadku aplikacji, które użytkownik może instalować.

jeśli aplikacja jest wstępnie zainstalowana na urządzeniu i nigdy nie była jawnie używana przez ponad 30 dni, [C-1-3] [C-1-5] nie zostaną zwolnieni.

Jeśli implementacje na urządzeniach rozszerzają wprowadzone ograniczenia aplikacji 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 dostępną w AOSP lub rozszerza funkcje uwzględnione w AOSP, to:

• [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 obowiązuje w aplikacji w przypadku użytkownika tylko wtedy, gdy dowody na to, że użytkownik nie używał aplikacji od jakiegoś czasu. Ten ZALECANY jest czas trwania co najmniej 1 miesiąca. Wykorzystanie MUSI być jest definiowana przez bezpośrednią interakcję użytkownika UsageStats#getLastTimeVisible() interfejsu API lub innych elementów, które powodują wyjście aplikacji ze stanu wymuszonego zatrzymania. w tym powiązania usług, dostawców treści, transmisji dla pełnoletnich itp. , która będzie śledzona przez nowy interfejs API UsageStats#getLastTimeAny składUsed().
• [C-1-3] MUSI stosować ograniczenia dotyczące wszystkich użytkowników urządzeń to dowód na to, że pakiet nie był używany przez ŻADNY użytkownik od pewnego okresu obecnie się znajdujesz. 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 wiadomości 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 w Javie język programowania. Aby zapewnić zgodność z aplikacjami innych firm, Programy implementujące urządzenia NIE MOGĄ wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w celu te przestrzenie nazw pakietów:

• 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ę podpisu metod lub klas bądź przez usunięcie zajęć lub klas. .
• [C-0-2] NIE MOŻE dodawać żadnych elementów widocznych publicznie (takich jak klasy lub interfejsów lub pól albo metod istniejących klas lub interfejsów) bądź lub systemowych interfejsów API do interfejsów API w powyższych przestrzeniach nazw. Ujawniony publicznie pierwiastek" to dowolny obiekt, który nie jest oznaczony tagiem „@hide” znacznik jako używany w nadrzędnym kodzie źródłowym Androida.

Mechanizmy implementujące urządzenia MOGĄ zmodyfikować podstawową implementację interfejsów API, ale takie modyfikacje:

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

Jednak twórcy implementacji na urządzeniach MOGĄ dodać niestandardowe interfejsy API poza standardowym Androidem , ale niestandardowe interfejsy API:

• [C-0-5] NIE MOŻE znajdować się w przestrzeni nazw należącej do innej firmy lub do niej odwołującej się Twojej organizacji. Na przykład narzędzia implementujące urządzenia NIE MOGĄ dodawać interfejsów API do com.google.* lub podobna przestrzeń nazw: tylko Google może to robić. Podobnie Google NIE MOŻE dodawać interfejsów API do innych firm przestrzeni nazw.
• [C-0-6] MUSI być spakowana w udostępnianych zasobach Androida, tak by tylko aplikacje które wyraźnie z nich korzystają (za pomocą mechanizmu <uses-library>), są na zwiększone wykorzystanie pamięci przez te interfejsy API.

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

• [C-1-1] NIE MOŻE znajdować się w bibliotece NDK ani w bibliotece należącej do innej osoby organizacji zgodnie z opisem tutaj.

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

Powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsy API w języku programowania Java; ta sekcja ma tylko umocnić i uczynić je wiążącymi przez włączenie do tej Zgodność Definicja.

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ą Android oraz zgodnie z zasadami tabeli poniżej. (Patrz sekcja 7.1.1 na rozmiaru i gęstości ekranu).

• POWINNY jest używać środowiska wykonawczego Android (ART), czyli referencyjnego obiektu nadrzędnego implementacji formatu wykonywalnego Dalvik, a odniesienie do wdrożenia systemu zarządzania pakietami.

• TRZEBA przeprowadzać testy rozmycia w różnych trybach wykonywania i docelowych architektur, aby zapewnić stabilność środowiska wykonawczego. Więcej informacji: JFuzz, i DexFuzz na stronie projektu Android Open Source.

Podane poniżej wartości pamięci są uważane za minimalne na urządzeniach 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ługuje aplikacje innych firm zastępujące program uruchamiający (ekran główny).

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

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.home_screen.
• [C-1-2] MUSI zwrócić AdaptiveIconDrawable gdy aplikacja innej firmy używa tagu <adaptive-icon> do udostępniania oraz ikonę PackageManager metod pobierania ikon.

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

• [C-2-1] MUSI zgłosić użytkownika true za ShortcutManager.isRequestPinShortcutSupported()
• [C-2-2] MUSI poprosić użytkownika o zgodę na dodanie skrótu przez aplikacje z ShortcutManager.requestPinShortcut() API.
• [C-2-3] MUSI obsługiwać przypięte skróty oraz dynamiczne i statyczne skrótów, jak opisano na stronie Skróty aplikacji.

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

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

Jeśli na urządzeniach jest wdrożony domyślny program uruchamiający, który zapewnia szybkie dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą ShortcutManager (Menedżer skrótów) API:

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

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

• [C-5-1] MUSI respektować: NotificationChannel.setShowBadge() API. Inaczej mówiąc, zadbaj o wizualną wygodę związaną z ikoną aplikacji, jeśli jest ustawiona na true i nie pokazuj żadnych schematów plakietek aplikacji, gdy wszystkie kanałów powiadomień aplikacji ustawiło wartość na false.
• MOŻE zastępować plakietki ikony aplikacji własnym schematem plakietek, jeśli aplikacje innych firm wskazują na obsługę zastrzeżonego schematu plakietek. dzięki wykorzystaniu zastrzeżonych interfejsów API, ale MUSI korzystać z zasobów i wartości udostępniane za pomocą interfejsów API z plakietkami powiadomień opisanych w pakiecie SDK, Na przykład Notification.Builder.setNumber() oraz Notification.Builder.setBadgeIconType() API.

Jeśli implementacje urządzenia obsługują monochromatyczny ikony, te ikony:

• [C-6-1] Trzeba go używać tylko wtedy, gdy użytkownik na to zezwoli (np. w Ustawienia lub menu selektora tapet).

3.8.2 Widżety

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

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ę AppWidgets i udostępniać funkcje interfejsu użytkownika umożliwiające dodawanie, konfigurowanie, wyświetlanie i usuwanie widżetów AppWidgets
• [C-1-3] MUSI wyświetlać widżety o wymiarach 4 x 4 w standardowym rozmiarze siatki. Przeczytaj wytyczne dotyczące projektowania widżetów aplikacji. w dokumentacji pakietu Android SDK.
• MOŻE obsługiwać widżety aplikacji na ekranie blokady.

jeśli implementacje urządzeń obsługują widżety i elementy w aplikacji innych firm; przypięcia skrótów:

• [C-2-1] MUSI zgłosić użytkownika true za AppWidgetManager.html.isRequestPinAppWidgetSupported()
• [C-2-2] MUSI poprosić użytkownika o zgodę na dodanie skrótu przez aplikacje z AppWidgetManager.requestPinAppWidget() API.

3.8.3 Powiadomienia

Android obejmuje Notification oraz NotificationManager interfejsy API, które umożliwiają deweloperom aplikacji innych firm powiadamianie użytkowników o ważnych wydarzeniach oraz przyciągnąć użytkowników uwagi za pomocą komponentów sprzętowych (np. dźwięków, wibracji, i światła) oraz funkcje oprogramowania (np. obszar powiadomień, 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 oraz w zakresie, w jakim jest to możliwe dzięki wdrożeniu na urządzeniu sprzęt. Jeśli na przykład urządzenie jest wyposażone w wibracje, MUSI mieć poprawnie zaimplementować interfejsy API wibracji. Jeśli na urządzeniu brakuje implementacji sprzęt, odpowiednie interfejsy API MUSZĄ być zaimplementowane w trybie bezobsługowym. Działanie to szerzej znajdziesz w sekcji 7.
• [C-1-2] MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki animacji itp.) udostępniane w interfejsach API lub Przewodnik po stylu ikon na pasku stanu/systemu, chociaż MOGĄ one zapewnić użytkownikom alternatywny sposób obsługi powiadomień niż pozwala na to referencyjna implementacja Android Open Source.
• [C-1-3] MUSI przestrzegać i właściwie wdrażać zachowania opisane interfejsy API , aby aktualizować, usuwać i grupować powiadomienia.
• [C-1-4] MUSI zawierać pełne informacje o działaniu notificationChannel. Interfejs API jest udokumentowany w pakiecie SDK.
• [C-1-5] MUSI zapewniać użytkownikowi możliwość blokowania i modyfikowania określonych powiadomienia wysyłane przez aplikację innej firmy na każdy poziom kanału i pakietu aplikacji.
• [C-1-6] MUSI też udostępniać zgodę użytkownika na wyświetlanie usuniętych powiadomień kanałów.

• [C-1-7] MUSI prawidłowo renderować wszystkie zasoby (obrazy, naklejki, ikony itp.) przekazywane przez Powiadomienie.MessagingStyle obok tekstu powiadomienia bez dodatkowej interakcji ze strony użytkownika. Dla: przykład MUSI pokazywać wszystkie zasoby, w tym ikony dostarczane przez android.app.Person, w rozmowie grupowej, która jest setGroupConversation.

• [C-SR-1] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości zakupu kontrolować powiadomienia dla aplikacji, którym przyznano uprawnienia Uprawnienia detektora powiadomień. Szczegółowość MUSI być precyzyjna, tak aby użytkownik mógł określ typy powiadomień dla każdego detektora powiadomień połączone z tym słuchaczem. Typy MUSZĄ obejmować „wątki”, „alerty”, „ciche” i „ważne ciągłe” powiadomienia.

• [C-SR-2] Zdecydowanie ZALECANE jest podanie przez użytkowników liczby dostępnych wartości wykluczyć aplikacje z powiadomienia konkretnego detektora powiadomień.

• [C-SR-3] Zdecydowanie ZALECANE są automatyczne wyświetlanie aprobaty dla użytkowników. blokować powiadomienia z określonej aplikacji innej firmy w przypadku każdego kanału i aplikacji poziomu pakietu po wielokrotnym zamknięciu tego powiadomienia przez użytkownika.

• 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ą wysyłać powiadomienia użytkowników biorących udział w ważnych wydarzeniach w celu ograniczenia problemów związanych z bezpieczeństwem, takich jak rozpraszanie uwagi kierowcy.

Android 11 wprowadza obsługę powiadomień o rozmowach, które są powiadomienia korzystające z interfejsu MessagingStyle. i udostępnia opublikowany identyfikator skrótu People.

Implementacje na urządzeniach:

• [C-SR-4] Zdecydowanie ZALECANE są grupowania i wyświetlania conversation notifications przed powiadomieniami niedotyczącymi rozmowy, z wyjątkiem bieżące powiadomienia usługi na pierwszym planie oraz importance:high powiadomienia.

Jeśli implementacje na urządzeniach obsługują conversation notifications Dostarczy ona danych wymaganych do bubbles:

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

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

• [C-2-1] MUSI korzystać z dokładnie takich zasobów, jak zapewniana przez Notification.Style Klasa interfejsu API i jej podklasy dla prezentowanych elementów zasobów.
• POWINIEN zaprezentować każdy element zasobu (np. ikony, tytułu i tekstu podsumowania) zdefiniowanego w narzędziu Notification.Style Klasa interfejsu API i jej podklasy.

Powiadomienia z ostrzeżeniem to powiadomienia, które są prezentowane użytkownikowi w miarę, jak wchodzą w niego niezależnie od powierzchni, z której włącz. Jeśli implementacje urządzenia obsługują funkcję Uważaj na przejściu powiadomienia, a następnie:

• [C-3-1] MUSI korzystać z widoku powiadomień i zasobów zgodnie z opisem na stronie Notification.Builder Klasa interfejsu API, gdy wyświetlane są powiadomienia z ostrzeżeniem.
• [C-3-2] MUSI wyświetlać działania wykonane przez Notification.Builder.addAction() razem z treścią powiadomień bez dodatkowej interakcji ze strony użytkownika zgodnie z opisem w pakiecie SDK.

3.8.3.2 Usługa powiadamiania słuchaczy

Android obejmuje NotificationListenerService Interfejsy API, które umożliwiają aplikacjom (raz jawnie włączone przez użytkownika) otrzymywanie kopii wszystkie powiadomienia w miarę ich publikowania lub aktualizowania.

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo i szybko aktualizować powiadomienia wszystkich zainstalowanych i włączanych przez użytkownika usług detektorów, w tym wszystkie metadane dołączone do obiektu Notification (Powiadomienie).
• [C-0-2] MUSI respektować: snoozeNotification() wywołanie interfejsu API i zamknięcie powiadomienia oraz wywołanie zwrotne po uśpieniu. 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 uśpionych powiadomień przy użyciu standardowych interfejsów API, takich jak NotificationListenerService.getSnoozedNotifications()
• [C-1-2] MUSISZ udostępnić temu użytkownikowi zgodę na usypianie powiadomień z każdej zainstalowanej aplikacji innej firmy, chyba że pochodzą usług trwałych/działających na pierwszym planie.

3.8.3.3 Tryb Nie przeszkadzać / Priorytet

Jeśli implementacje urządzeń obsługują funkcję Nie przeszkadzać (nazywany też trybem priorytetowym), to:

• [C-1-1] MUSI, jeśli implementacja urządzenia zapewnia użytkownikowi środki aby przyznać aplikacjom innych firm dostęp do konfiguracji zasad Nie przeszkadzać lub go zablokować, Wyświetl Automatyczne reguły Nie przeszkadzać tworzonych przez aplikacje w połączeniu z regułami utworzonymi przez użytkowników i wstępnie zdefiniowanymi.
• [C-1-3] MUSI spełniać warunki standardu suppressedVisualEffects wartości przekazywane przez NotificationManager.Policy i jeśli aplikacja ustawił którekolwiek z SUPPRESSED_EFFECT_SCREEN_OFF lub SUPPRESSED_FE_SCREEN_ON, MUSI wskazywać użytkownikowi, że efekty wizualne są pomijane w menu ustawień Nie przeszkadzać.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

3.8.3.4 Ochrona powiadomień poufnych

3.8.4 Interfejsy API wspomagające

Android udostępnia interfejsy API wspomagające aby umożliwić aplikacjom wybór ilości informacji w bieżącym kontekście udostępnione 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 kontekst jest udostępniany, przez albo:
  • Za każdym razem, gdy aplikacja asystująca uzyskuje dostęp do kontekstu, wyświetlany jest biały wokół krawędzi ekranu, w takim przypadku, jak jego czas trwania i jasność implementacji projektu Android Open Source.
  • Wstępnie zainstalowana aplikacja asystująca – mniej pieniędzy dla użytkownika o więcej niż dwie opcje nawigacji od domyślne menu ustawień rozpoznawania mowy i aplikacji Asystent, i udostępniać kontekst tylko wtedy, gdy aplikacja asystująca zostanie jawnie wywołana przez użytkownika za pomocą słowa-klucza lub klawisza nawigacyjnego.
• [C-2-2] Wyznaczona interakcja służąca do uruchomienia aplikacji asystującej, zgodnie z opisem w sekcji 7.2.3 MUSI uruchamiać aplikacja wspomagająca, czyli aplikacja, która obsługuje VoiceInteractionService, lub aktywność obsługującą intencję ACTION_ASSIST.

3.8.5 Alerty i powiadomienia

Aplikacje mogą używać interfejsu Toast interfejsu API do wyświetlania użytkownikowi krótkich, niemodalnych ciągów znaków, które znikają po przez krótki czas i użyj TYPE_APPLICATION_OVERLAY interfejsu API typu okna do wyświetlania okien 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 wsparcie w celu zablokowania aplikacji możliwości wyświetlania alertów w oknach korzystających z interfejsu TYPE_APPLICATION_OVERLAY. Implementacja AOSP spełnia to wymaganie, ponieważ zawiera opcje w obszarze powiadomień.

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

3.8.6 Motywy

Android dostarcza „motywy” jako mechanizm stosowania stylów przez aplikacje całą aktywność lub aplikację.

Android zawiera „Holo” i „Materiał” rodzina motywów jako zestaw zdefiniowanych stylów dla programistów aplikacji, dzięki którym mogą Wygląd i sposób działania motywu Holo zgodnie z definicją podaną w pakiecie SDK na Androida.

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

• [C-1-1] NIE MOŻE zmieniać żadnych atrybutów motywu z motywem Holo narażonych na aplikacji.
• [C-1-2] MUSI obsługiwać „materiał” rodziny motywów i NIE MOŻE zmieniać żadnych z atrybuty motywu Material Design. lub jego zasobów udostępnianych aplikacjom.

• [C-1-3] MUSI albo ustawić „sans-serif” rodzina czcionek na Roboto w wersji 2.x dla języków obsługiwane przez Roboto, lub zapewnienie użytkownikowi możliwości zmiany używanej czcionki dla „sans-szeryfów” rodzina czcionek na Roboto w wersji 2.x w językach obsługiwanych przez Roboto.

• [C-1-4] MUSI generować dynamiczne palety kolorów zgodnie z wymaganiami AOSP. dokumentacja Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (zobacz android.theme.customization.system_palette i android.theme.customization.theme_style).

• [C-1-5] MUSI generować dynamiczne palety kolorów przy użyciu stylów motywów kolorystycznych. wymienione w Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES dokumentacja (patrz android.theme.customization.theme_styles), czyli TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD iMONOCHROMATIC.

  „Kolor źródła” służy do generowania dynamicznych palet kolorów przy wysyłaniu z android.theme.customization.system_palette (jak opisano w Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

• [C-1–6] MUSI mieć wartość barwy CAM16 równą 5 lub większą.

  • POWINNA POWIĄZAĆ na podstawie tapety przez com.android.systemui.monet.ColorScheme#getSeedColors, która zapewnia możesz wybrać jeden z wielu prawidłowych kolorów źródłowych.

  • Jeśli żaden z podanych kolorów nie jest zgodny, należy użyć wartości 0xFF1B6EF3 powyższego wymagania dotyczącego koloru źródła.

Android obejmuje też „Ustawienie domyślne urządzenia” rodzina motywów jako zestaw zdefiniowanych stylów dla programistów aplikacji, którzy chcą dostosować do wyglądu i sposobu działania motyw urządzenia określony przez narzędzie do implementacji.

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

Android obsługuje wariant motywu z półprzezroczystymi paskami systemowymi, co umożliwia programistów aplikacji, aby wypełnić obszar za paskiem stanu i nawigacji z treściami w aplikacjach. Aby zapewnić spójne środowisko deweloperskie w tym Trzeba zachować styl ikony paska stanu na różnych urządzeniach.

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

• [C-2-1] TRZEBA użyć białego koloru do oznaczania ikon stanu systemu (takich jak siła sygnału czy poziom naładowania baterii) oraz powiadomienia z systemu, chyba że ikona wskazujący stan problemu lub aplikacja prosi o świecący pasek stanu, kontrolkę WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS flaga.
• [C-2-2] Implementacje na urządzeniach z Androidem MUSZĄ zmienić kolor systemu ikony stanu są czarne (więcej informacji znajdziesz w sekcji R.style), gdy aplikacja prosi o świecący pasek stanu.

3.8.7 Animowane tapety

Android definiuje typ komponentu, odpowiedni interfejs API oraz cykl życia, które pozwalają aby udostępnić co najmniej jeden „Animowane tapety” użytkownikowi. Animowane tapety to animacje, wzory lub podobne obrazy. z ograniczonymi możliwościami wprowadzania danych, które wyświetlają się jako tapeta, za innymi aplikacji.

Uznaje się, że urządzenie może niezawodnie wyświetlać animowane tapety, jeśli może działać. wszystkie animowane tapety bez ograniczeń funkcji, w rozsądnym kadrze. bez negatywnego wpływu na inne zastosowania. Jeśli ograniczenia w sprzęt powoduje awarię tapet lub aplikacji, zbyt duża moc procesora lub baterii albo nieakceptowalna liczba klatek na sekundę uznaje się, że sprzęt nie może wyświetlać animowanych tapet. Na przykład niektóre animowane tapety mogą wykorzystywać kontekst OpenGL 2.0 lub 3.x do renderowania treści. Animowana tapeta nie będzie działać prawidłowo na sprzęcie, który nie obsługuje wielu Konteksty OpenGL, ponieważ użycie animowanej tapety z kontekstu OpenGL może kolidować z innymi aplikacjami, które również korzystają z kontekstu OpenGL.

• Implementacje urządzeń, które pozwalają na niezawodne wyświetlanie animowanych tapet zgodnie z opisem. powyżej WARTO stosować animowane tapety.

Jeśli na urządzeniu są włączone animowane tapety:

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

3.8.8 Przełączanie aktywności

Fragment kodu źródłowego Androida zawiera funkcje ekran Przegląd, interfejs użytkownika na poziomie systemu do przełączania zadań i wyświetlania ostatnio używanych za pomocą miniatury graficznej aplikacji w chwili ostatniego opuszczenia aplikacji przez użytkownika.

Implementacje na urządzeniach w tym klawisz nawigacyjny funkcji ostatnich, zgodnie z opisem w sekcja 7.2.3 MOŻE zmienić interfejs.

Jeśli implementacje urządzeń obejmujące klawisz nawigacyjny funkcji ostatnich, zgodnie z opisem w punktu 7.2.3 modyfikują interfejs, dlatego:

• [C-1-1] MUSI obsługiwać do 7 wyświetlonych działań.
• NALEŻY wyświetlać przynajmniej tytuł 4 aktywności jednocześnie.
• 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.
• POWINNY jest uruchamiać działanie szybkiej zmiany między dwoma ostatnio używanymi gdy klawisz funkcji ostatnich kliknięć trzeba nacisnąć dwukrotnie.
• POWINNY być aktywowanie trybu wielu okien podzielonego ekranu, jeśli jest obsługiwany, gdy klawisz funkcji ostatnich jest wciśnięty i przytrzymaj.
• MOŻE wyświetlać ostatnie powiązane zdjęcia jako grupę poruszającą się razem.
• [C-SR-1] Zdecydowanie ZALECANE jest użycie użytkownika nadrzędnego Androida. interfejsu (lub podobnego interfejsu opartego na miniaturach) do wyświetlenia na ekranie Przegląd.

3.8.9 Zarządzanie danymi wejściowymi

Android zapewnia obsługę Zarządzanie danymi wejściowymi oraz obsługę zewnętrznych edytorów metody wprowadzania.

Jeśli implementacje urządzeń pozwalają użytkownikom na korzystanie z metod wprowadzania danych innych firm urządzenia, to:

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.input_methods i obsługują interfejsy IME API zgodnie z definicją podaną 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 Szablon powiadomienia o multimediach który pozwala aplikacjom do multimediów integrować się z elementami sterującymi odtwarzaniem, wyświetlanych na ekranie blokady.

3.8.11 Wygaszacze ekranu (wcześniej Sny)

Ustawienia znajdziesz w sekcji 3.2.3.5 aby skonfigurować wygaszacze ekranu.

3.8.12. Lokalizacja

Jeśli urządzenia są wyposażone w czujnik sprzętowy (np. GPS), który umożliwia podawania współrzędnych 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 emoji 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-jasna bezszeryfowa-średnia, czarna bezszeryfowa, bezszeryfowa-kondensowana, bezszeryfowa-kondensowana-świetlna dla języków dostępnych na urządzeniu.
  • Pełne zapisy Unicode 7.0 w alfabecie łacińskim, greckim i cyrylicy, w tym Rozszerzone zakresy A, B, C i D w alfabecie łacińskim oraz wszystkie glify w walucie blok symboli Unicode 7.0.
• [C-1-3] NIE MOŻE usuwać ani modyfikować pliku NotoColorEmoji.tff z obrazu systemu. (Można dodać nową czcionkę emotikonów, aby zastąpić emotikon NotoColorEmoji.tff).
• POWINNA spełniać odcień skóry i różnorodne emotikony rodzinne, zgodnie z opisem w Raport techniczny 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 niezgodnych z Unicode, czyli potocznie zwanych „Zawgyi”, do renderowania Myanmar języki.

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 Unicode NIE MOŻE być ustawiona jako domyślna, chyba że użytkownik wybierze go w selektorze języka.
• [C-2-2] MUSI obsługiwać czcionkę Unicode i czcionkę niezgodną z tym standardem, jeśli czcionka niezgodna z Unicode jest obsługiwana przez urządzenie. Niezgodne z Unicode czcionka zgodna z wymaganiami NIE MOŻE usuwać ani zastępować czcionki Unicode.
• [C-2-3] MUSI renderować tekst z użyciem czcionki niezgodnej z Unicode TYLKO JEŚLI kod języka z kod skryptu Qaag (np. my-Qaag). Brak innych kodów języków lub regionów w standardzie ISO (niezależnie od tego, przypisane, nieprzypisane lub zarezerwowane) mogą być używane w odniesieniu do znaków innych niż Unicode. czcionka zgodna z wymaganiami Mjanmy. Programiści aplikacji i autorzy stron internetowych mogą określ my-Qaag jako kod języka, tak jak w przypadku każdego innego innego języka.

3.8.14. Wiele okien

Jeśli implementacje urządzeń mają możliwość wyświetlania wielu działań Jednocześnie:

• [C-1-1] MUSI wdrożyć taki tryb wielu okien zgodnie z zachowania aplikacji i interfejsy API opisane w Android SDK dokumentacji obsługi trybu wielu okien oraz następujące wymagania:
• [C-1-2] MUSI uwzględniać: android:resizeableActivity jest ustawiona przez aplikację w pliku AndroidManifest.xml, jak opisano w tego pakietu SDK.
• [C-1-3] NIE MOŻE wyświetlać trybu podzielonego ani dowolnego, jeśli wysokość ekranu jest mniejsza niż 440 dp, a szerokość ekranu mniejsza niż 440 dp. dp.
• [C-1-4] Nie wolno zmieniać rozmiaru aktywności poniżej 220 dp w trybach wielu okien innych niż obraz w obrazie.
• Implementacje na urządzeniach o rozmiarze ekranu xlarge POWINNY obsługiwać dowolny obszar i trybu uzyskiwania zgody.

czy implementacje urządzeń obsługują tryby wielu okien i podzielony ekran, :

• [C-2-2] MUSI przyciąć aktywność zadokowaną w przypadku podzielonego ekranu dla wielu okien, ale POWINNY jest wyświetlać jego część, jeśli aplikacja Launcher jest aktywnym oknem.
• [C-2-3] MUSI spełniać warunki określonej wartości AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight wartości aplikacji uruchamiającej innej firmy i nie zastępują one tych wartości. podczas wyświetlania pewnych treści.

czy implementacje urządzeń obsługują tryby wielu okien i obraz w obrazie. trybu wielu okien:

• [C-3-1] MUSI uruchamiać działania w trybie wielu okien obrazu 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 android:resizeableActivity oraz android:supportsPictureInPicture.
• [C-3-2] MUSI udostępniać działania w interfejsie SystemUI jako określonych przez bieżącą aktywność PIP w setActions() API.
• [C-3-3] MUSI obsługiwać formaty obrazu większe lub równe 1:2,39 i mniejszym lub równym 2,39:1, zgodnie z aktywnością PIP w setAspectRatio() API.
• [C-3-4] MUSI używać KeyEvent.KEYCODE_WINDOW sterowanie oknem PIP; jeśli tryb PIP nie jest zaimplementowany, klucz MUSI być dostępnych dla aktywności na pierwszym planie.
• [C-3-5] MUSI zapewniać zgodę użytkownika na zablokowanie wyświetlania aplikacji tryb PIP; wdrożenie AOSP spełnia to wymaganie dzięki w obszarze powiadomień.

• [C-3-6] MUSI przydzielić tę minimalną szerokość i wysokość do okna PIP okno, w którym aplikacja nie zadeklaruje żadnej wartości dla AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight:

  • Urządzenia ze skonfigurowanym trybem Configuration.uiMode innym niż UI_MODE_TYPE_TELEVISION Minimalna szerokość i wysokość to 108 dp.
  • Urządzenia z ustawieniem Configuration.uiMode ustawionym na UI_MODE_TYPE_TELEVISION Minimalna szerokość to 240 dp, a minimalna wysokość 135 dp.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

3.8.15. Wycięcie w sieci reklamowej

Android obsługuje wycięcie w ekranie zgodnie z opisem w dokumencie SDK. Interfejs DisplayCutout API określa, obszar przy krawędzi wyświetlacza, który może nie działać w żadnej aplikacji z powodu wycięcia w ekranie lub zakrzywionego ekranu 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ę WindowManager.LayoutParams API zgodnie z opisem w pakiecie SDK.
• [C-1-4] MUSI podawać prawidłowe wartości dla wszystkich danych wycięcia zdefiniowanych w DisplayCutout API.

3.8.16. Sterowanie urządzeniami

Android obejmuje ControlsProviderService i Control Interfejsy API umożliwiające aplikacjom innych firm publikowanie ustawień urządzeń stan i działanie użytkowników.

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

3.8.17. Schowek

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE wysyłać danych ze schowka do żadnego komponentu, aktywności, usługi ani niezależnie od połączenia sieciowego, bez wyraźnej czynności ze strony użytkownika (np. naciśnięcia klawisza w nakładce), z wyjątkiem usług wymienionych w 9.8.6 Rejestrowanie treści i wyszukiwanie aplikacji.

czy implementacje urządzeń generują podgląd widoczny dla użytkowników podczas kopiowania treści, do schowka dla dowolnego elementu ClipData, gdzie ClipData.getDescription().getExtras() zawiera android.content.extra.IS_SENSITIVE, to oni:

• [C-1-1] MUSI usunąć widoczny podgląd

Implementacja referencyjna AOSP spełnia te wymagania dotyczące schowka.

3.9. Administracja urządzeniem

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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 Aplikacja Właściciel urządzenia jak opisano poniżej:
  • Gdy implementacja urządzenia ani użytkownicy, ani skonfigurowanych danych użytkownika, oznacza to, że:
    • [C-1-5] MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia lub włącz aplikację DPC, aby określić, czy zostanie właścicielem urządzenia lub właścicielem profilu; jeśli urządzenie deklaruje obsługę komunikacji Near-Field Communications (NFC) za pośrednictwem flaga funkcji android.hardware.nfc i otrzymuje wiadomość NFC zawierający rekord z typem MIME MIME_TYPE_PROVISIONING_NFC
    • [C-1-8] MUSI wysłać tryb ACTION_GET_PROVISIONING_MODE po uruchomieniu obsługi administracyjnej właściciela urządzenia, dzięki czemu Aplikacja DPC może zdecydować, czy chcesz zostać właścicielem urządzenia czy profilem Właściciel w zależności od wartości android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, chyba że można je ustalić na podstawie że istnieje tylko jedna prawidłowa opcja.
    • [C-1-9] MUSI wysłać ACTION_ADMIN_POLICY_COMPLIANCE dla aplikacji Właściciel urządzenia, jeśli został ustanowiony właściciel urządzenia podczas obsługi administracyjnej niezależnie od używanej metody obsługi administracyjnej. użytkownik nie może mieć możliwości kontynuowania kreatora konfiguracji do czasu Aplikacja Właściciel urządzenia kończy działanie.
  • Gdy implementacja urządzenia użytkowników lub danych użytkownika, oznacza to, że:
    • [C-1-7] NIE MOŻE rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia więcej informacji.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

3.9.1.2. Udostępnianie profili zarządzanych

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

• [C-1-1] MUSI obsługiwać interfejsy API dzięki której aplikacja kontrolera zasad urządzeń (DPC) może stać się właścicielem nowego profilu zarządzanego.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-1-3] MUSI podać w Ustawieniach następujące opcje użytkownika sygnalizują użytkownikowi, że określona funkcja systemu została wyłączona przez za pomocą kontrolera zasad dotyczących urządzeń:

  • Spójna ikona lub inne korzyści dla użytkownika (np. ikona informacji AOSP) oznaczająca, że określone ustawienie jest ograniczone przez administratora urządzenia.
  • Krótki komunikat z wyjaśnieniem dostarczony przez administratora urządzenia w setShortSupportMessage
  • Ikona aplikacji DPC.

• [C-1-4] MUSI uruchomić moduł obsługi dla funkcji ACTION_PROVISIONING_successFUL w profilu służbowym, jeśli został ustanowiony właściciel profilu podczas obsługa administracyjna jest inicjowana przez profil android.app.action.PROVISION_MANAGED_PROFILE. a DPC zaimplementował moduł obsługi.

• [C-1-5] MUSI wysłać ACTION_PROFILE_PROVISIONING_COMPLETE są wysyłane do DPC profilu służbowego po zainicjowaniu obsługi administracyjnej android.app.action.PROVISION_MANAGED_PROFILE intencji.

• [C-1-6] MUSI wysłać tryb ACTION_GET_PROVISIONING_MODE po uruchomieniu obsługi administracyjnej właściciela profilu, tak aby aplikacja DPC mogą zdecydować, czy zostać właścicielem urządzenia czy właścicielem profilu, chyba że obsługa administracyjna jest uruchamiana przez intencję android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] MUSI wysłać ACTION_ADMIN_POLICY_COMPLIANCE do profilu służbowego, gdy zostanie utworzony właściciel profilu obsługi administracyjnej niezależnie od używanej metody obsługi administracyjnej z wyjątkiem gdy obsługa administracyjna jest uruchamiana przez intencję android.app.action.PROVISION_MANAGED_PROFILE. Użytkownik nie może mieć możliwości kontynuowania w kreatorze konfiguracji, dopóki profil nie zostanie Aplikacja właściciela kończy działanie.

• [C-1-8] MUSI wysłać ACTION_MANAGED_PROFILE_PROVISIONED do profilu osobistego DPC po utworzeniu właściciela profilu. 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ą android.app.admin.DevicePolicyManager API.
• [C-1-2] MUSI zezwalać na utworzenie tylko jednego profilu zarządzanego.
• [C-1-3] MUSI używać plakietki ikony (podobnej do plakietki pracy nadającej AOSP) do reprezentują zarządzane aplikacje i widżety oraz inne elementy interfejsu z plakietką np. Ostatnie i Powiadomienia.
• [C-1-4] MUSI wyświetlać ikonę powiadomienia (podobna do działania na wyższym poziomie AOSP ) wskazującą, kiedy użytkownik korzysta z aplikacji profilu zarządzanego.
• [C-1-5] MUSI wyświetlać toast informujący o tym, że użytkownik korzysta z zarządzanej usługi profilu po wybudzeniu urządzenia (ACTION_USER_PRESENT). aplikacja na pierwszym planie znajduje się w profilu zarządzanym.
• [C-1-6] Jeśli istnieje profil zarządzany, MUSI wykazywać afordancję w sekcji Intencja „Chooser” aby umożliwić użytkownikowi przekazanie intencji z zarządzanego głównemu użytkownikowi lub odwrotnie, po włączeniu Zasad dotyczących urządzeń kontroler.
• [C-1-7] Jeśli istnieje profil zarządzany, MUSI udostępniać następujące konto użytkownika zarówno dla użytkownika głównego, jak i profilu zarządzanego:
  • Oddzielne zliczanie baterii, lokalizacji, mobilnej transmisji danych i wykorzystania miejsca na dane dla głównego użytkownika i profilu zarządzanego.
  • Niezależne zarządzanie aplikacjami VPN zainstalowanymi w głównym użytkownika lub profilu zarządzanego.
  • Niezależne zarządzanie aplikacjami zainstalowanymi u głównego użytkownika lub profilu zarządzanego.
  • Niezależne zarządzanie kontami głównego użytkownika lub zarządzanych kont profil.
• [C-1-8] MUSI mieć zainstalowaną fabrycznie zainstalowaną aplikację telefonu, kontakty i wiadomości aplikacje mogą wyszukiwać i wyszukiwać informacje o rozmówcy w zarządzanych profilu (jeśli istnieje) i profilu głównego, jeśli Kontroler zasad dotyczących urządzeń na to zezwala.
• [C-1-9] MUSI mieć pewność, że spełnia wszystkie wymagania dotyczące bezpieczeństwa dotyczy urządzenia z włączonymi wieloma użytkownikami (patrz sekcja 9.5), nawet jeśli profil zarządzany nie jest liczony jako inny użytkownik oprócz użytkownika głównego.
• [C-1-10] MUSI mieć pewność, że dane zrzutu ekranu są zapisane w profilu służbowym w pamięci podręcznej. topActivity okno z ostrością (tę, z którą użytkownik wchodził w interakcję jako ostatnia spośród wszystkich aktywności) i należy do aplikację profilu służbowego.
• [C-1-11] NIE MOŻE przechwytywać żadnej innej zawartości ekranu (paska systemowego, powiadomień i treści z profilu osobistego) z wyjątkiem profilu służbowego okno/okna aplikacji przy zapisywaniu zrzutu ekranu w profilu służbowym (aby mieć pewność, nie są zapisywane w profilu służbowym).

Jeśli implementacje urządzeń zadeklarują android.software.managed_users i android.software.secure_lock_screen, to:

• [C-2-1] MUSI obsługiwać możliwość określania osobnego spotkania na ekranie blokady poniższe wymagania dotyczące przyznawania dostępu do aplikacji działających w środowisku zarządzanym tylko do profilu.
  • Implementacje na urządzeniach MUSZĄ spełniać DevicePolicyManager.ACTION_SET_NEW_PASSWORD intencji i pokazanie interfejsu w celu skonfigurowania osobnego ekranu blokady dane logowania dla profilu zarządzanego.
  • Dane logowania na ekran blokady profilu zarządzanego MUSZĄ być takie same magazynowania danych logowania i mechanizmów zarządzania nimi jako profilu nadrzędnego, zgodnie z dokumentacją Witryna projektu Android Open Source
  • Zasady dotyczące haseł DPC MUSI mieć zastosowanie tylko do danych logowania na ekranie blokady profilu zarządzanego, chyba że wywołano wystąpienie DevicePolicyManager zwrócone przez getParentProfileInstance
• Gdy wyświetlane są kontakty z profilu zarządzanego we wstępnie zainstalowanym rejestrze połączeń, interfejsie w trakcie rozmowy, w toku i nieodebranych połączeniach powiadomienia, kontakty i aplikacje do obsługi wiadomości, które POWINNY być oznaczone etykietą ta sama plakietka używana do wskazywania aplikacji profilu zarządzanego.

3.9.3 Obsługa zarządzanych 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 bieżącego przełącz się z powrotem na użytkownika głównego w sesji wielu użytkowników, isLogoutEnabled zwraca true. Karta użytkownika MUSI być dostępna na ekranie blokady bez odblokowywania urządzenia.

Jeśli implementacje urządzeń zadeklarują android.software.device_admin i przekażą więcej użytkowników pomocniczych na urządzeniu.

• [C-SR-1] Zdecydowanie ZALECANE jest posiadanie takiej samej zgody właściciela urządzenia AOSP oświadczenia wyświetlane w ramach procesu zainicjowanego przez android.app.action.PROVISION_MANAGED_DEVICE, przed zezwoleniem na dodawanie kont nowego użytkownika dodatkowego, aby użytkownicy wiedzieli, że urządzenie jest zarządzane.

3.9.4 Wymagania dotyczące roli zarządzania zasadami dotyczącymi urządzeń

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

• [C-1-1] MUSI obsługiwać rolę zarządzania zasadami dotyczącymi urządzeń, zgodnie z definicją w art. 9.1. aplikację, która pełni rolę zarządzania zasadami dotyczącymi urządzeń; MOŻNA ją zdefiniować, ustawiając config_devicePolicyManagement na nazwę pakietu. Po nazwie pakietu MUSI występować ciąg : i certyfikat podpisywania, chyba że aplikacja jest wstępnie wczytana.

Jeśli nazwa pakietu nie jest zdefiniowana dla config_devicePolicyManagement jako opisane powyżej:

• [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać obsługę administracyjną bez urządzenia wniosek o rolę podmiotu zarządzającego polityką (AOSP udostępnia implementację referencyjną).

Jeśli nazwa pakietu jest zdefiniowana dla config_devicePolicyManagement zgodnie z opisem powyżej:

• [C-3-1] Aplikacja MUSI być zainstalowana na wszystkich profile dla użytkownika.
• [C-3-2] Implementacje na urządzeniach MOGĄ definiować aplikację, która aktualizuje właściciel roli zarządzania zasadami dotyczącymi urządzeń przed obsługą administracyjną według ustawienia config_devicePolicyManagementUpdater

Jeśli nazwa pakietu jest zdefiniowana dla config_devicePolicyManagementUpdater jako opisane powyżej:

• [C-4-1] Aplikacja MUSI być wstępnie zainstalowana na urządzeniu.
• [C-4-2] Aplikacja MUSI zaimplementować filtr intencji, który rozwiązuje android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER

3.9.5. Zasady rozwiązywania problemów z urządzeniami

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

• [C-1-1] MUSI rozwiązywać konflikty zasad dotyczących urządzeń zgodnie z opisem w Zasady dotyczące urządzeń z Androidem.

3.10. Ułatwienia dostępu

Android zapewnia dostęp do funkcji, które pomagają osobom z niepełnosprawnościami łatwiej poruszać się między urządzeniami. Ponadto Android zapewnia interfejsy API platformy, które umożliwiają implementom usług ułatwień dostępu otrzymywanie wywołań zwrotnych dla użytkowników i zdarzeniach systemowych, a także generować alternatywne mechanizmy opinii, takie jak zamiana tekstu na mowę, reakcji haptycznych i nawigacji za pomocą kulki/pada kierunkowego.

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

• [C-1-1] MUSI zawierać implementację ułatwień dostępu na Androidzie zgodnie z opisem w interfejsy API ułatwień dostępu Dokumentacja pakietu SDK.
• [C-1-2] MUSI generować zdarzenia ułatwień dostępu i dostarczać odpowiednie AccessibilityEvent dla wszystkich zarejestrowanych AccessibilityService. implementacji zgodnie z dokumentacją w pakiecie SDK.
• [C-1-4] MUSI zapewniać użytkownikowi możliwości kontroli ułatwień dostępu usługi deklarujące AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_Button, Pamiętaj, że w urządzeniach z systemowym paskiem nawigacyjnym Trzeba zezwolić użytkownikowi na oferowanie przycisku w pasek nawigacyjny pozwala sterować tymi usługami.

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, Bezpośrednie uruchamianie zależne od uruchamiania aplikacji, gdy przechowywanie danych jest szyfrowane przy użyciu algorytmu szyfrowania opartego na plikach (FBE).
• W gotowym procesie konfiguracji MUSI udostępnić mechanizm, który umożliwia użytkownikom włączenie odpowiednie usługi ułatwień dostępu, a także opcje zmiany rozmiaru czcionki, rozmiaru wyświetlacza i gestów powiększenia.

3.11. Przekształcanie tekstu na mowę

Android obejmuje interfejsy API, które pozwalają aplikacjom na zamianę tekstu na mowę. usług (TTS) i umożliwia dostawcom usług ich wdrożenie usług Google.

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

• [C-1-1] MUSI obsługiwać Platforma TTS Androida API.

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

• [C-2-1] MUSI zapewniać korzyści dla użytkownika, aby mógł on wybrać zamianę tekstu na mowę do użytku na poziomie systemu.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

3.12. Platforma wejścia TV

3.13. Szybkie ustawienia

Android zapewnia komponent interfejsu Szybkich ustawień, który zapewnia szybki dostęp do często używane lub pilnie potrzebne działania.

jeśli implementacje urządzeń zawierają komponent interfejsu Szybkich ustawień i obsługują aplikacje innych firm, Szybkie ustawienia:

• [C-1-1] MUSI umożliwiać użytkownikowi dodawanie lub usuwanie kafelków udostępnionych przez quicksettings Interfejsy API z aplikacji innej firmy.
• [C-1-2] NIE MOŻE automatycznie dodawać kafelka bezpośrednio z aplikacji innej firmy otwórz Szybkie ustawienia.
• [C-1-3] MUSI wyświetlać wszystkie kafelki dodane przez użytkowników z aplikacji innych firm obok dostępnych przez system kafelków szybkich ustawień.

3.14. Interfejs multimediów

Jeśli implementacje urządzeń obejmują aplikacje nieaktywowane głosem (aplikacje), które współdziałają aplikacji innych firm w ramach usługi MediaBrowser lub MediaSession, Aplikacje:

• [C-1-2] MUSZĄ wyraźnie wyświetlać ikony uzyskane za pomocą getIconBitmap() lub getIconUri() oraz tytuły uzyskane za pośrednictwem getTitle(), jak opisano w 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 przy treściach dostarczanych przez tej aplikacji zewnętrznej.

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

• [C-1-5] MUSI rozważyć dwukrotne dotknięcie KEYCODE_HEADSETHOOK lub KEYCODE_MEDIA_PLAY_PAUSE jako KEYCODE_MEDIA_NEXT dla MediaSession.Callback#onMediaButtonEvent.

3.15. Aplikacje błyskawiczne

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

• [C-1-1] Aplikacje błyskawiczne MUSZĄ mieć uprawnienia tylko z android:protectionLevel ustawiono na "instant".
• [C-1-2] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje 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 bezpośrednio, chyba że komponent jest udostępniany przez android:visibleTo InstantApps.
• [C-1-4] Zainstalowane aplikacje NIE MOGĄ mieć dostępu do szczegółów dotyczących aplikacji błyskawicznych na chyba że aplikacja błyskawiczna łączy się zainstalowanej aplikacji.

• Implementacje urządzeń MUSZĄ oferować następujące parametry użytkownika podczas interakcji z aplikacjami błyskawicznymi. AOSP spełnia wymagania domyślny interfejs systemu, Ustawienia i Menu z aplikacjami. Implementacje na urządzeniach:

  • [C-1-5] MUSI zapewnić użytkownikowi możliwość przeglądania i usuwania aplikacji błyskawicznych lokalnie w pamięci podręcznej dla każdego pakietu aplikacji.
  • [C-1-6] MUSI zawierać trwałe powiadomienie użytkownika, które może zostać zwinięte, gdy aplikacja błyskawiczna działa na pierwszym planie. Ten użytkownik powiadomienie MUSI zawierać informację, że Aplikacje błyskawiczne nie wymagają instalacji i zapewniać klientom korzyści, które kierują ich do aplikacji ekran informacyjny w Ustawieniach. W przypadku aplikacji błyskawicznych uruchamianych za pomocą intencji internetowej zdefiniowane przez użycie intencji z działaniem ustawionym na Intent.ACTION_VIEW oraz ze schematem „http” lub „https”, czyli zwiększenie liczby użytkowników MUSI zezwalać użytkownikowi na nieuruchamianie aplikacji błyskawicznej oraz uruchomić powiązany link za pomocą skonfigurowanej przeglądarki, jeśli jest dostępna na urządzeniu.
  • [C-1-7] MUSI zezwalać na dostęp do uruchomionych aplikacji błyskawicznych w sekcji Ostatnie jeśli na urządzeniu jest dostępna funkcja Ostatnie.

• [C-1-8] MUSI wstępnie wczytywać co najmniej jedną aplikację lub składnik usługi z modułem obsługi intencji dla intencji wymienionych w pakiecie SDK tutaj i uwzględnij intencje w aplikacjach błyskawicznych.

3.16. Parowanie urządzenia towarzyszącego

Android zapewnia obsługę parowania urządzeń towarzyszących, co pozwala na skuteczniejsze zarządzanie z urządzeniami towarzyszącymi i zapewnia CompanionDeviceManager Interfejs API dla aplikacji umożliwiający 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 zadbać o to, aby interfejsy API w android.companion pakiet został w pełni wdrożony.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

3.17. Aplikacje do wagi

Jeśli implementacje urządzeń zadeklarują funkcję FEATURE_CANT_SAVE_STATE, to:

• [C-1-1] MUSI mieć zainstalowaną tylko jedną aplikację, która określa cantSaveState działające w systemie w tym samym czasie. Jeśli użytkownik opuszcza aplikację bez jej zamykania (np. naciskając w domu i zostawić aktywną aktywność, zamiast naciskać przycisk „Wstecz” bez aktywnych działań w systemie), a następnie wdrożenia na urządzeniu MUSZĄ priorytetowo traktować tę aplikację w pamięci RAM tak jak w przypadku innych rzeczy, które powinny pozostać uruchomione, na przykład usługi na pierwszym planie. Gdy taka aplikacja działa w tle, system może nadal zasilać urządzenie. funkcji zarządzania, np. ograniczania dostępu do procesora i sieci.
• [C-1-2] MUSI udostępniać zasoby UI, by wybrać aplikację, która nie chce korzystają z mechanizmu zapisywania/przywracania stanu normalnego, gdy użytkownik uruchamia drugą aplikację zadeklarowaną przy użyciu cantSaveState .
• [C-1-3] NIE MOŻE stosować innych zmian zasad do aplikacji, które określają cantSaveState na przykład zmień wydajność procesora lub priorytety planowania.

Jeśli implementacje urządzeń nie zadeklarują funkcji FEATURE_CANT_SAVE_STATE to:

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

3.18. Kontakty

Android obejmuje Contacts Provider Interfejsy API umożliwiające 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 dane MOGĄ też być przechowywane tylko lokalnie na urządzeniu. Kontakty przechowywane tylko na urządzeniu są określane jako lokalne kontaktów.

Nieprzetworzone kontakty są „powiązane z” lub „zapisane w” Konto gdy ACCOUNT_NAME, oraz ACCOUNT_TYPE kolumny nieprzetworzonych kontaktów pasują do odpowiednich Nazwa.konta oraz Typ konta pola na koncie.

Domyślne konto lokalne: konto dla nieprzetworzonych kontaktów, które są przechowywane tylko urządzenie i nie jest powiązane z kontem w AccountManager utworzone z wartościami null dla ACCOUNT_NAME, oraz ACCOUNT_TYPE kolumny.

Niestandardowe konto lokalne: konto dla nieprzetworzonych kontaktów, które są przechowywane tylko na i nie są powiązane z kontem w usłudze AccountManager, które są utworzony z co najmniej 1 wartością niepustą dla argumentu ACCOUNT_NAME, oraz ACCOUNT_TYPE kolumny.

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] ACCOUNT_NAME z niestandardowego konta lokalnego MUSZĄ zostać zwrócone do ContactsContract.RawContacts.getLocalAccountName.
• [C-1-2] ACCOUNT_TYPE z niestandardowego konta lokalnego MUSZĄ zostać zwrócone do ContactsContract.RawContacts.getLocalAccountType.
• [C-1-3] Nieprzetworzone kontakty wstawiane przez aplikacje innych firm za pomocą domyślnego konta lokalnego (tzn. przez ustawienie wartości null dla ACCOUNT_NAME i ACCOUNT_TYPE) MUSZĄ zostać wstawione do niestandardowego kodu lokalnego .
• [C-1-4] Nieprzetworzone kontakty wstawione do niestandardowego konta lokalnego NIE MOGĄ być są usuwane podczas dodawania lub usuwania kont.
• [C-1-5] Usuwanie operacji wykonanych na niestandardowym koncie lokalnym MUSI spowodować natychmiastowe trwałe usunięcie nieprzetworzonych kontaktów (tak jak w przypadku CALLER_IS_SYNCADAPTER. Parametr ma wartość prawda), nawet jeśli skonfigurowano parametr CALLER\_IS\_SYNCADAPTER na fałsz lub nie określono.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

3.19. Ustawienia języka

4. Zgodność pakietów aplikacji

Implementacje urządzeń:

• [C-0-1] MUSI mieć możliwość instalowania i uruchamiania pliku „.apk” systemu Android pliki jako generowanych przez „aapt” narzędzia zawartego w oficjalnym pakiecie SDK na Androida.

  • Powyższe wymaganie może być wyzwaniem, dlatego implementacje na urządzeniach ZALECANE jest korzystanie z zarządzania pakietami implementacji referencyjnej AOSP systemu.

• [C-0-2] MUSI obsługiwać weryfikację pliku „.apk” za pomocą Schemat podpisu APK w wersji 3.1, Schemat podpisu pliku APK w wersji 3, Schemat podpisu pliku APK w wersji 2 i podpisywanie plików JAR.

• [C-0-3] NIE MOŻE wydłużać pliki .apk, Plik manifestu Androida kod bajtowy Dalvik lub z kodami bajtowymi RenderScript tak, aby uniemożliwiały one instaluje się i działa prawidłowo na innych zgodnych urządzeniach.

• [C-0-4] NIE MOŻE zezwalać na aplikacje inne niż „zarejestrowany użytkownik” aby pakiet mógł odinstalować aplikację bez żadnych potwierdzania przez użytkownika, zgodnie z dokumentacją pakietu SDK DELETE_PACKAGE uprawnienia. Jedynym wyjątkiem jest obsługa aplikacji weryfikatora pakietów systemu PACKAGE_NEEDS_VERIFICATION intencję i obsługę aplikacji przez menedżera miejsca ACTION_MANAGE_STORAGE intencji.

• [C-0-5] MUSI mieć aktywność, która obsługuje android.settings.MANAGE_UNKNOWN_APP_SOURCES intencji.

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

  • MUSI zadeklarować REQUEST_INSTALL_PACKAGES uprawnienia albo ustaw android:targetSdkVersion na 24 lub mniej.
  • Użytkownik MUSI przyznać uprawnienia do instalowania aplikacji z nieznanych źródeł.

• MUSI zapewnić użytkownikowi zgodę na przyznanie lub unieważnienie uprawnień instalowanie aplikacji z nieznanych źródeł dla poszczególnych aplikacji, ale MOŻE zdecydować się na ich wdrożenie to no-op i zwróć RESULT_CANCELED dla startActivityForResult(), , jeśli implementacja urządzenia nie pozwala użytkownikom na wybór. Jednak nawet w takich przypadkach należy poinformować użytkownika, dlaczego nie ma takiego wyboru.

• [C-0-7] MUSI wyświetlić okno dialogowe ostrzeżenia z ciągiem ostrzegawczym udostępnione przez systemowy interfejs API PackageManager.setHarmfulAppWarning użytkownikowi przed uruchomieniem działania w aplikacji, która została oznaczona przez ten sam systemowy interfejs API PackageManager.setHarmfulAppWarning jako potencjalnie szkodliwe.

• MUSISZ dać użytkownikowi możliwość odinstalowania lub uruchomienia aplikacji w oknie ostrzeżenia.

• [C-0-8] MUSI wdrożyć obsługę przyrostowego systemu plików zgodnie z opisem tutaj.

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

.

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ć i zgłosić obsługę dostępnych koderów i dekoderów do aplikacji innych firm za pośrednictwem MediaCodecList
• [C-0-3] MUSI być w stanie poprawnie dekodować i udostępniać we wszystkich formatach, które potrafi zakodować. Obejmuje to wszystkie strumienie bitowe, których generowane przez kodery oraz profile zgłaszane 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 zwracanych buforów wejściowych po przetworzeniu danych.
  • NIE NALEŻY przechowywać zdekodowanych buforów przez czas dłuższy niż określony w (np. SPS).
  • NIE NALEŻY przechowywać kodowanych buforów dłużej niż wymaga tego GOP. do jego struktury.

Wszystkie kodeki wymienione w sekcji poniżej są udostępniane jako oprogramowanie w preferowanej implementacji na Androidzie z programu Android Open, Projekt źródłowy.

Pamiętaj, że ani Google, ani Open Handset Alliance nie nakładają żadnych oświadczenie, że kodeki nie są objęte patentami innych firm. Te wartości zamierzających używać tego kodu źródłowego w sprzęcie lub oprogramowaniu, zalecamy które implementacje tego kodu, w tym również w oprogramowaniu open source, oprogramowanie współdzielone może wymagać licencji patentowych od odpowiednich właścicieli patentów.

5.1. Kodeki multimediów

5.1.1 Kodowanie dźwięku

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

Jeśli implementacje urządzeń zadeklarują android.hardware.microphone, MUSZĄ obsługiwać kodowanie poniższych formatów audio i udostępnić je do aplikacji 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 PCM przez interfejs android.media.MediaCodec API.

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ń zadeklarują obsługę android.hardware.audio.output, musi obsługiwać dekodowanie następujące formaty dźwięku:

• [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 (ISO/IEC 23003-3 Extended HE AAC Profile, który obejmuje: profil Baseline USAC i zakres dynamiczny ISO/IEC 23003-4 profil kontrolny)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE z dźwiękiem w wysokiej rozdzielczości maksymalnie 24 bity, częstotliwość próbkowania 192 kHz i 8 kanałów. Pamiętaj, że wymaga to jedynie dekodowania, a urządzenie można redukować i miksować w fazie odtwarzania.
• [C-1-10] Opus

Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC strumienie wielokanałowe (tj. więcej niż 2 kanały) do PCM domyślnie w dekoderze dźwięku AAC w interfejsie API android.media.MediaCodec, MUSISZ obsługiwane:

• [C-2-1] Dekodowanie MUSI być wykonywane bez miksowania (np. AAC 5.0) strumień musi być zdekodowany na 5 kanałów PCM, strumień AAC 5.1 musi być zdekodowany do 6 kanałów PCM).
• [C-2-2] Metadane zakresu dynamicznego MUSZĄ być zgodne z definicją w sekcji „Kontrola zakresu dynamicznego (DRK)” w normie ISO/IEC 14496-3 i klucze DRC android.media.MediaFormat do skonfigurować zachowania dekodera dźwięku związane z zakresem dynamicznym. Klucze AAC DRC zostały wprowadzone w interfejsie API 21. Są to: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_ENCODED_TARGET_LEVEL.
• [C-SR-1] Zdecydowanie ZALECANE jest, aby powyższe wymagania C-2-1 i C-2-2 były dla wszystkich dekoderów dźwięku AAC.

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

• [C-3-1] Trzeba interpretować i stosować metadane dotyczące głośności i metadanych DRRC zgodnie z poziomem 1 profilu kontroli zakresu dynamiki MPEG-D DRC.
• [C-3-2] Dekoder MUSI działać zgodnie z konfiguracją ustawiono 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ć kontrolę głośności i zakresu dynamicznego według normy ISO/IEC 23003-4 Profil dynamicznej kontroli zakresu.

Jeśli obsługiwany jest standard ISO/IEC 23003-4 oraz zarówno ISO/IEC 23003-4, Metadane ISO/IEC 14496-3 są zawarte w zdekodowanym strumieniu bitowym, a potem:

• 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 PCM przez interfejs android.media.MediaCodec API.

Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC strumienie wielokanałowe (tj. więcej niż 2 kanały) do PCM domyślnie w dekoderze dźwięku AAC w interfejsie API android.media.MediaCodec, to MUSISZ wykonać poniższy kod być obsługiwane:

• [C-7-1] MUSI być skonfigurowany przez aplikację za pomocą dekodowania z kluczem KEY_MAX_OUTPUT_CHANNEL_COUNT aby kontrolować, czy treść ma być mieszana do dźwięku stereo (przy użyciu wartości 2) lub jest zwracany z użyciem natywnej liczby kanałów (w przypadku użycia wartości równej lub większa od tej liczby). Na przykład wartość 6 lub większa zostanie skonfigurowana dekoder do przesyłania treści 5.1 na 6 kanałów.
• [C-7-2] Podczas dekodowania dekoder MUSI reklamować używaną maskę kanału na formacie wyjściowym z atrybutem KEY_CHANNEL_MASK ze stałymi android.media.AudioFormat (przykład: CHANNEL_OUT_5POINT1).

Jeśli implementacje urządzeń obsługują dekodery audio inne niż domyślny kod AAC za pomocą dekodera dźwięku i który jest w stanie wysyłać dźwięk wielokanałowy (tj. więcej niż 2 kanałów) podczas przesyłania skompresowanych treści wielokanałowych, a potem:

• [C-SR-2] Zdecydowanie ZALECANE jest możliwość skonfigurowania dekodera przez za pomocą dekodowania za pomocą klucza KEY_MAX_OUTPUT_CHANNEL_COUNT aby kontrolować, czy treści mają być miksowane do stereo (przy użyciu wartości 2) lub jest zwracany z użyciem natywnej liczby kanałów (w przypadku użycia wartości równej lub większa od tej liczby). Na przykład wartość 6 lub większa zostanie skonfigurowana dekoder do przesyłania treści 5.1 na 6 kanałów.
• [C-SR-3] Zdecydowanie ZALECANE jest użycie dekodera do reklamowania w formacie wyjściowym z atrybutem KEY_CHANNEL_MASK ze stałymi android.media.AudioFormat (przykład: CHANNEL_OUT_5POINT1).

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 w standardzie częstotliwości 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 w standardzie częstotliwości 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 w standardzie częstotliwości 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 16 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 częstotliwości od 6,60 kb/s do 23,85 kb/s, próbkowanie przy 16 kHz, zgodnie z definicją AMR-WB, adaptacyjna obsługa wielu prędkości – szerokopasmowy kodek mowy	3GPP (.3GPP)
FLAC	Zarówno w przypadku kodera, jak i dekodera: przynajmniej tryb mono i stereo MUSZĄ być obsługiwane. MUSI być obsługiwana częstotliwość próbkowania do 192 kHz. 16- i 24-bitowe MUSI być obsługiwana. Obsługiwanie 24-bitowych danych audio w technologii FLAC MUSI być dostępna ze zmiennoprzecinkową konfiguracją dźwięku.	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. Pomoc: formaty dzwonków RTTTL/RTX, OTA oraz iMelody	Wpisz 0 i 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Dekodowanie: obsługa treści mono, stereo, 5.0 i 5.1 z próbkowaniem 8000, 12 000, 16 000, 24 000 i 48 000 Hz. Kodowanie: obsługa treści mono i stereo z częstotliwością próbkowania 8000, 12000, 16 000, 24 000 i 48 000 Hz.	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ą. fala Moduł wyodrębniania musi obsługiwać 16-, 24- i 32-bitowy linearny PCM oraz 32-bitowy plik zmiennoprzecinkowy. (otrzymuje wartość do limitu sprzętowego). Częstotliwość próbkowania MUSI być obsługiwana od 8–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, 16 000, 24 000 i 48 000 Hz. Kodowanie: obsługa treści mono i stereo. z częstotliwością próbkowania 8000, 12 000, 16 000, 24 000 i 48 000 Hz.	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
• [C-0-4] AVIF
  • Urządzenia muszą obsługiwać profil BITRATE_MODE_CQ i profil podstawowy.

Jeśli implementacje urządzeń obsługują kodowanie HEIC przez android.media.MediaCodec dla typu mediów MIMETYPE_IMAGE_ANDROID_HEIC, one:

• [C-1-1] MUSI udostępniać kodek HEVC z akceleracją sprzętową, obsługuje BITRATE_MODE_CQ tryb sterowania szybkością transmisji bitów. HEVCProfileMainStill profilu i rozmiaru ramki 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
• [C-0-7] AVIF (profil podstawowy)

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 zostanie zażądany przez aplikacji, na przykład za pomocą narzędzia ARGB_8888 konfiguracji 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)
AVIF (profil podstawowy)	Obraz, kolekcja obrazów, profil odniesienia sekwencji obrazów	Kontener HEIF (.avif)

Koder obrazu i dekodery dostępne przez interfejs API MediaCodec

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

• [C-SR-1] Zdecydowanie zalecana obsługa formatu kolorów RGB888 dla interfejsu wejściowego Surface i trybu uzyskiwania zgody.

• [C-1-3] MUSI obsługiwać co najmniej jeden planarny lub półpłaszczyzny Format koloru YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (odpowiednik COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (odpowiednik do COLOR_FormatYUV420SemiPlanar). Zdecydowanie zalecamy ich wsparcie, i jednym, i drugim.

5.1.7 Kodeki wideo

• Dopuszczalna jakość strumieniowego przesyłania filmów i rozmów wideo w internecie usług, implementacje urządzeń POWINIEN używać 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 i wejściowego bufora bajtowego, z największą możliwą dopuszczalną skompresowaną i nieskompresowaną klatką zgodnie z wymaganiami według standardu i konfiguracji, ale nie w ogóle.

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

• [C-1-3] Kodery i dekodery wideo MUSZĄ obsługiwać co najmniej jeden planar lub półpłaszczyzny YUV420 w formacie kolorów 8:8:8: COLOR_FormatYUV420PackedPlanar (odpowiednik COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (odpowiednik COLOR_FormatYUV420SemiPlanar). Zdecydowanie zalecamy stosowanie tych rozwiązań w obu tych przypadkach.

• [C-SR-1] Zdecydowanie ZALECANE jest obsługa przy użyciu koderów i dekoderów wideo co najmniej jeden kolor planarny lub półpłaszczyzny YUV420 zoptymalizowany pod kątem sprzętu; kolor: 8:8:8 (YV12, NV12, NV21 lub równoważny format zoptymalizowany przez dostawcę).

• [C-1-5] Dekodery wideo, które obsługują format z dużą głębią bitów (Ponad 9 bitów na kanał) MUSI obsługiwać wyświetlanie równoważnego formatu 8-bitowego, jeśli żądane przez aplikację. MUSI to zostać uwzględnione przez wsparcie Format kolorów YUV420 8:8:8 za pomocą android.media.MediaCodecInfo.

Jeśli implementacje urządzenia reklamują obsługę profilu HDR przez Display.HdrCapabilities one:

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

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

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

O ile aplikacja nie określi inaczej za pomocą parametru KEY_COLOR_FORMAT klucz formatu, implementacje dekodera wideo:

• [C-4-1] MUSI mieć domyślny format kolorów zoptymalizowany pod kątem wyświetlacza sprzętowego jeśli skonfigurowano za pomocą danych wyjściowych Surface.
• [C-4-2] MUSI domyślnie mieć format kolorów YUV420 8:8:8 zoptymalizowany pod kątem procesora odczytuje, jeśli skonfigurowano nieużywanie danych wyjściowych z Surface.

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	Zapoznaj się z sekcją 5.2 i 5.3 Więcej informacji	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	Zapoznaj się z sekcją 5.2 i 5.3 Więcej informacji	WebM, (.webm) matroska (.mkv)
VP9	Więcej informacji znajdziesz w sekcji 5.3.	WebM, (.webm) matroska (.mkv)
AV1	Szczegółowe informacje znajdziesz w sekcjach 5.2 i 5.3.	MPEG-4 (MP4) matroska (.mkv, tylko dekodowanie)

5.1.9. Zabezpieczenia kodeka multimediów

Implementacje urządzenia MUSZĄ zapewnić zgodność z funkcjami zabezpieczeń kodeka multimediów jak opisano poniżej.

Android zapewnia obsługę OMX, wieloplatformowego interfejsu Media acceleration API, a także Codec 2.0 – niskobudżetowy interfejs API przyspieszenia multimedialnego.

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

• [C-1-1] MUSI obsługiwać kodeki multimedialne przez OMX lub kodek 2.0 interfejsów API (lub obu tych elementów) jak w projekcie Android Open Source, bez wyłączania lub omijać zabezpieczenia. Nie oznacza to w szczególności, że każda kodek MUSI korzystać z interfejsu API OMX lub Codec 2.0, tylko obsługa co najmniej jeden z tych interfejsów API MUSI być dostępny, a obsługa dostępnych interfejsów API MUSI być dostępna między innymi z dostępnych 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 systemu Android Projekt open source (jeśli jest dostępny) dla każdego formatu i typu multimediów (kodera lub dekodera) obsługiwanego przez urządzenie.
• [C-2-2] Kodeki, których nazwy zaczynają się od „OMX.google”. MUSI być oparta na w kodzie źródłowym projektu Android Open Source Project.
• [C-SR-2] Zdecydowanie ZALECANE jest używanie programowych kodeków OMX korzystające z kodeka. nie ma dostępu do sterowników sprzętowych innych niż programy do mapowania 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 Android Open Source Project (jeśli jest dostępny) dla wszystkich formatów i typów multimediów (kodera lub dekodera) obsługiwanego przez urządzenie.
• [C-3-2] MUSI zawierać kodeki Codec 2.0 w kodeku. jak to jest możliwe w projekcie Android Open Source, do ściślejszego przyznawania dostępu do kodeków.
• [C-3-3] Kodeki, których nazwy zaczynają się od „c2.android”. MUSI być oparta na w kodzie źródłowym projektu Android Open Source Project.

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 charakteryzacji kodeka multimediów przez MediaCodecInfo API.

W szczególności:

• [C-1-2] Kodeki o nazwach zaczynających się od „OMX”. MUSI używać interfejsów OMX API i mają 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 oraz mieć nazwy zgodne z wytycznymi dotyczącymi nazw dla systemu Android zgodnie z Kodekem 2.0.
• [C-1-4] Kodeki o nazwach zaczynających się od „OMX.google”. lub „c2.android”. MUSI NIE mogą być określane jako dostawca ani umożliwiać akceleracji sprzętowej.
• [C-1-5] Kodeki, które działają w procesie kodeka (od dostawcy lub systemu), dostępu do sterowników sprzętowych innych niż przydzielające pamięć i programy do map charakteryzuje się wyłącznie oprogramowaniem.
• [C-1-6] Kodeki, których nie ma w projekcie Android Open Source lub nie w kodzie źródłowym w tym projekcie MUSI być określony jako dostawca.
• [C-1-7] Kodeki korzystające z akceleracji sprzętowej MUSZĄ mieć opis. z akceleracją sprzętową.
• [C-1-8] Nazwy kodeków NIE MOGĄ wprowadzać w błąd. Na przykład kodeki o nazwie „dekodery” MUSI obsługiwać dekodowanie oraz elementy o nazwie „kodery”. MUSI obsługiwać kodowanie. Kodeki o nazwach zawierających formaty multimediów MUSZĄ je obsługiwać formatów reklam.

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

• [C-2-1] Wszystkie kodeki wideo MUSZĄ publikować dane o możliwej liczbie klatek w tych rozmiarów, jeśli obsługiwany przez kodek:

	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, AV1)	1408 x 1152 piks. (H263) 1280 x 720 piks. (inne, AV1)	1920 x 1080 piks. (inne niż MPEG4 i AV1)	3840 x 2160 piks. (HEVC, VP9, AV1)

• [C-2-2] Kodeki wideo z akceleracją sprzętową MUSZĄ publikowanie informacji o punktach wydajności. Każda lista MUSI być obsługiwana standardowe punkty skuteczności (wymienione w sekcji PerformancePoint) API), chyba że są one objęte innym obsługiwanym wskaźnikiem wydajności.
• Dodatkowo POWINNY jest opublikować rozszerzone punkty wydajności, jeśli: pomagają utrzymać długotrwałe wyniki filmu inne niż wymienione powyżej.

5.2. Kodowanie wideo

Jeśli implementacje urządzeń obsługują koder wideo i udostępniają go aplikacji innych firm i ustaw
MediaFormat.KEY_BITRATE_MODE na BITRATE_MODE_VBR aby koder działał w trybie zmiennej szybkości transmisji bitów, a następnie o ile nie ma to wpływu na minimalną jakość, zakodowana szybkość transmisji bitów :

• NIE POWINNO mieć więcej niż jednego okno przesuwane o ponad 15% powyżej szybkości transmisji bitów między ramkami (I-frame). interwały.
• NIE POWINNO mieć więcej niż 100% powyżej szybkości transmisji bitów w oknie przesuwanym o długości 1 sekundy.

Jeśli implementacje urządzeń obsługują koder wideo i udostępniają go aplikacji innych firm i ustawiać MediaFormat.KEY_BITRATE_MODE do BITRATE_MODE_CBR więc koder działa ze stałą szybkością transmisji bitów, wówczas

• [C-SR-2] Zdecydowanie ZALECANY NIE może przekraczać docelowej szybkości transmisji bitów o więcej niż 15% w oknie przesuwanym o długości 1 sekundy.

Jeśli implementacje urządzeń obejmują osadzony wyświetlacz z funkcją musi mieć przekątną co najmniej 2,5 cala lub być wyposażony w port wyjściowy wideo; deklaruj obsługę kamery w interfejsie android.hardware.camera.any flagę cechy, oznacza to, że:

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

Jeśli implementacje urządzeń obsługują formaty wideo H.264, VP8, VP9 lub HEVC koderów i udostępniać je aplikacjom innych firm,

• [C-2-1] MUSI obsługiwać dynamicznie konfigurowane szybkości transmisji bitów.
• POWINNA obsługiwać zmienną liczbę klatek, przy czym koder wideo POWINNY określić tymczasowy czas trwania klatki na podstawie sygnatur czasowych buforów wejściowych oraz przydziela jego zasobnik bitów na podstawie czasu trwania klatki.

Jeśli implementacje urządzeń obsługują koder wideo MPEG-4 SP, dostępnych dla aplikacji innych firm:

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

Jeśli urządzenia zapewniają akcelerację sprzętową koderów wideo lub obrazów, i obsługuje co najmniej jedną podłączoną lub podłączaną kamerę sprzętową interfejsy API android.camera:

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

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

• [C-SR-1] Zdecydowanie ZALECANE jest udostępnienie wtyczki dla do płynnego transkodowania interfejsu API do konwersji z formatu HDR na SDR.

5.2.1 H.263

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

• [C-1-1] MUSI obsługiwać rozdzielczość QCIF (176 x 144) używając profilu bazowego poziomu 45. Rozdzielczość SQCIF jest opcjonalna.

5.2.2 H.264

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

• [C-1-1] MUSI obsługiwać profil podstawowy poziomu 3. Jednak obsługa ASO (Arbitrary Slice Ordering) – FMO (elastyczne) Sortowanie makr) i RS (nadmiarowe wycinki) są OPCJONALNE. Ponadto, aby zachowania zgodności z innymi urządzeniami z Androidem, ZALECANE jest Kodery ASO, FMO i RS nie są używane w profilu podstawowym.
• [C-1-2] MUSI obsługiwać profile kodowania wideo w rozdzielczości SD (standardowej rozdzielczości). w poniższej tabeli.
• POTRZEBNA jest obsługa profilu głównego na poziomie 4.
• POWINNA obsługiwać profile kodowania wideo HD (High Definition) jako podane w poniższej tabeli.

Jeśli implementacje urządzeń zgłaszają obsługę kodowania H.264 w przypadku rozdzielczości 720p lub 1080p do rozdzielczości wideo 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.
• POTRZEBUJESZ sprzętowy kodek VP8, który spełnia Wymagania w zakresie kodowania RTC w projektach WebM, akceptowalna jakość strumieniowych transmisji wideo w internecie i usług rozmów wideo.

Jeśli implementacje urządzeń zgłaszają obsługę kodowania VP8 w przypadku rozdzielczości 720p lub 1080p do rozdzielczości wideo 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.
• Zdecydowanie ZALECANE jest włączenie obsługi profili dekodowania HD jako podane w poniższej tabeli, jeśli dostępny jest koder sprzętowy.

	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ń twierdzą, że obsługują Profil 2 lub Profil 3 w Interfejsy API multimediów:

• Obsługa formatu 12-bitowego jest OPCJONALNA.

5.2.5 H.265

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

• [C-1-1] MUSI obsługiwać profil główny na poziomie 3 do Rozdzielczość 512 x 512.
• Zdecydowanie ZALECANE jest użycie funkcji [C-SR-1] do wspierania Profil SD 720 x 480 Profile kodujące HD opisane w tej tabeli, jeśli koder sprzętowy.

	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.2.6 AV1

Jeśli implementacje urządzeń obsługują kodek AV1, wówczas:

• [C-1-1] MUSI obsługiwać profil główny, w tym treści 8- i 10-bitowe.

• [C-1-2] MUSI publikować dane o skuteczności, tj. raportować dane o skuteczności w getSupportedFrameRatesFor() lub getSupportedPerformancePoints() Interfejsy API obsługujące obsługiwane rozwiązania znajdziesz w tabeli poniżej.

• [C-1-3] MUSI akceptować metadane HDR i przesyłać je do strumienia bitowego

Jeśli koder AV1 ma przyspieszanie sprzętowe, to:

• [C-2-1] MUSI obsługiwać maksymalnie profil kodowania HD1080p z 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	5 Mb/s	8 Mb/s	16 Mb/s	50 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 dla wszystkich kodeków VP8, VP9, Kodeki H.264 i H.265 w czasie rzeczywistym i z maksymalną obsługiwaną rozdzielczością przy użyciu każdego kodeka urządzenia.

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 poziomu 30 (rozdzielczości CIF, QCIF i SQCIF przy 30 kl./s przy 384 kb/s) oraz poziom 45 (QCIF i w rozdzielczości SQCIF przy 30 kl./s i 128 kb/s).

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. Pomoc dla ASO (Arbitrary Slice Ordering), FMO (elastyczne porządkowanie makr) i RS (Nadmiarowe wycinki) jest OPCJONALNE.
• [C-1-2] MUSI dekodować filmy w jakości SD (standardowa rozdzielczość). profile wymienione w poniższej tabeli i zakodowane przy użyciu profilu podstawowego i profilu głównego na poziomie 3.1 (w tym 720p30).
• POWINNY być w stanie dekodować filmy za pomocą profili HD (High Definition). jak podano w poniższej tabeli.

Jeśli wysokość raportowana przez metodę Display.getSupportedModes() to co najmniej rozdzielczość wideo, implementacje urządzeń:

• [C-2-1] MUSI obsługiwać profile dekodowania wideo HD 720p w następujących tabeli.
• [C-2-2] MUSI obsługiwać profile dekodowania wideo HD 1080p w tych 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ć poziom główny profilu głównego na poziomie 3 i film w jakości SD profilów zgodnie z poniższą tabelą.
• KONIECZNIE jest obsługa profili dekodowania HD zgodnie z informacjami w poniższej tabeli.
• [C-1-2] MUSI obsługiwać profile dekodowania HD zgodnie z poniższymi o dekoder sprzętowy.

Jeśli wysokość raportowana przez metodę Display.getSupportedModes() to co najmniej równą rozdzielczości wideo, a następnie:

• [C-2-1] Implementacje na urządzeniu MUSZĄ obsługiwać co najmniej jeden format H.265 lub VP9 dekodowanie profili 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 implementacja urządzenia twierdzi, że obsługuje profil HDR w mediach Interfejsy API:

• [C-3-1] Implementacje urządzeń MUSZĄ akceptować wymagane metadane HDR aplikacji oraz obsługuje wyodrębnianie i wygenerowanie wymaganego formatu HDR metadanych z strumienia bitowego lub kontenera.
• [C-3-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR do ekranu urządzenia lub do standardowego portu wyjściowego 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.
• NALEŻY użyć sprzętowego kodeka VP8 zgodnego wymagania.
• MUSI obsługiwać profile dekodowania HD z poniższej tabeli.

Jeśli wysokość raportowana przez metodę Display.getSupportedModes() jest równa lub od rozdzielczości wideo, a potem:

• [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać profile 720p tabeli.
• [C-2-2] Implementacje urządzeń MUSZĄ obsługiwać profile 1080p 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 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ższymi tabeli.

Jeśli wysokość raportowana przez metodę Display.getSupportedModes() to co najmniej równą rozdzielczości wideo, a następnie:

• [C-3-1] Implementacje na urządzeniu MUSZĄ obsługiwać co najmniej jeden kod VP9 lub H.265 z dekodowaniem profili 720, 1080 i 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 na urządzeniach twierdzą, że obsługują VP9Profile2 lub VP9Profile3 za pomocą parametru 'CodecProfileLevel' Interfejsy API multimediów:

• Obsługa formatu 12-bitowego jest OPCJONALNA.

Jeśli implementacje urządzenia twierdzą, że obsługują profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) przez Interfejsy API multimediów:

• [C-4-1] Implementacje urządzeń MUSZĄ akceptować wymagane metadane HDR (KEY_HDR_STATIC_INFO) dla wszystkich profili HDR oraz KEY_HDR10_PLUS_INFO' dla profili HDR10Plus) z aplikacji. MUSZĄ również obsługiwać wyodrębnianie i wyeksportowanie wymagane metadane HDR ze strumienia bitowego lub kontenera.
• [C-4-2] Implementacje urządzenia MUSZĄ prawidłowo wyświetlać treści HDR do ekranu urządzenia lub do standardowego portu wyjściowego 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 one:

• [C-1-1] MUSI zawierać moduł wyodrębniający z obsługą Dolby Vision.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-1-3] MUSI ustawiać identyfikator ścieżki kompatybilnych wstecznie warstw bazowych (jeśli występują) tak, aby były takie same połączony identyfikator ścieżki warstwy Dolby Vision.

5.3.9 AV1

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

• [C-1-1] MUSI obsługiwać profil główny, w tym treści 8- i 10-bitowe.

Jeśli implementacje urządzeń zapewniają obsługę kodeka AV1 za pomocą sprzętu z przyspieszonym dekoderem:

• [C-2-1] MUSI dekodować profile dekodowania wideo o rozdzielczości co najmniej HD 720p z w tabeli poniżej, gdy wysokość podawana przez Display.getSupportedModes() jest równa lub większa niż 720p.
• [C-2-2] MUSI dekodować profile dekodowania wideo w rozdzielczości co najmniej 1080p. z poniższej tabeli, gdy wysokość podawana przez Display.getSupportedModes() ma wartość równą lub większą niż 1080p.

	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	5 Mb/s	8 Mb/s	16 Mb/s	50 Mb/s

Jeśli implementacje urządzeń obsługują profil HDR za pomocą interfejsów Media API, one:

• [C-3-1] MUSI obsługiwać wyodrębnianie i wyświetlanie metadanych HDR z lub w kontenerze.
• [C-3-2] MUSI prawidłowo wyświetlać treści HDR na ekranie urządzenia lub standardowym portem wyjściowym wideo (np. HDMI).

5.4. Nagrywanie dźwięku

Chociaż niektóre z wymagań opisanych w tej sekcji są wymienione jako: od Androida 4.3 planowane jest wprowadzenie definicji zgodności dla przyszłych wersji. aby zmienić je na MUST. Dotychczasowe i nowe urządzenia z Androidem ZALECANE, jeśli spełniasz te wymagania, lub są nie będą w stanie osiągnąć zgodności z Androidem po uaktualnieniu 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 nieprzetworzonej treści audio dowolny otwarty strumień INPUT AudioRecord lub AAudio . Muszą być spełnione przynajmniej te warunki:

  • Format: linearny PCM, 16-bitowy
  • Częstotliwość próbkowania: 8000, 11025, 16 000, 44 100, 48 000 Hz
  • Kanały: mono
  • Źródła dźwięku: DEFAULT, MIC, CAMCORDER VOICE_RECOGNITION VOICE_COMMUNICATION UNPROCESSED lub VOICE_PERFORMANCE. Dotyczy to również równoważnych gotowych ustawień wejściowych w trybie AAudio: na przykład AAUDIO_INPUT_PRESET_CAMCORDER.

• POWINNY jest zezwalać na przechwytywanie nieprzetworzonej treści audio za pomocą: cechy:

  • Format: liniowy PCM, 16- i 24-bitowy
  • Częstotliwość próbkowania: 8000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100, 48000 Hz
  • Kanały: tyle kanałów, ile wynosi liczba mikrofonów na ekranie urządzenie

• [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, gdy podane powyżej współczynniki próbkowania są ujęte w próbkowaniu w dół.

• NALEŻY zezwolić na przechwytywanie nieprzetworzonych treści audio w jakości radia AM i DVD, 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ć warunki interfejsu API MicrophoneInfo i uzupełnij informacje o mikrofony dostępne na urządzeniu. mogą być również dostępne dla aplikacji innych firm za pomocą AudioManager.getMicrophones() API na potrzeby aktywnego rekordu AudioRecord przy użyciu MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED lub VOICE_PERFORMANCE. czy implementacje urządzeń zezwalają na przechwytywanie surowego dźwięku w jakości radia AM i DVD. treści, to:

• [C-2-1] MUSI przechwytywać bez próbkowania w górę przy współczynniku wyższego niż 16000:22050 lub 44100:48000.

• [C-2-2] W celu zwiększenia próbkowania MUSI dodać odpowiedni filtr antyaliasingowy. lub zmniejszanie.

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ć android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION źródło dźwięku: jedną z częstotliwości próbkowania – 44100 lub 48 000.
• [C-1-2] Domyślnie MUSI wyłączyć przetwarzanie dźwięku z redukcją szumów, gdy nagrywam strumień audio z dźwięku AudioSource.VOICE_RECOGNITION źródła.

• [C-1-3] Domyślnie MUSI wyłączyć automatyczną kontrolę wzmocnienia podczas nagrywania. strumień audio ze źródła dźwięku AudioSource.VOICE_RECOGNITION.

• POWINNA wykazywać w przybliżeniu płaską amplitudę w porównaniu do częstotliwości. w średnim zakresie częstotliwości: ±3 dB od 100 Hz do 4000 Hz dla każdego a każdy mikrofon użyty do nagrywania źródła dźwięku rozpoznawania głosu.

• Zdecydowanie ZALECANE jest działanie amplitudy na poziomie niskiego tętna [C-SR-1] zakres częstotliwości: zwłaszcza od ±20 dB od 30 Hz do 100 Hz w porównaniu średniej częstotliwości dla każdego mikrofonu użytego do nagrywania głosu rozpoznawania dźwięku.

• Zdecydowanie ZALECANE jest działanie na poziomie amplitudy wysokich zakres częstotliwości: zwłaszcza od ±30 dB od 4000 Hz do 22 kHz w porównaniu z średni zakres częstotliwości dla każdego mikrofonu użytego do nagrania głosu, rozpoznawania dźwięku.

• NALEŻY ustawić czułość wejścia dźwięku w taki sposób, aby źródło sygnału sinusoidalnego 1000 Hz było odtwarzane przy poziomie ciśnienia akustycznego 90 dB (SPL) (mierzonego obok mikrofonu) daje idealną odpowiedź RMS 2500 w zakresie od 1770 do 3530 dla 16 próbek bitów (lub -22,35 dB ±3 dB pełnej skali dla zmiennoprzecinkowego/podwójnej precyzji próbek) dla każdego mikrofonu używanego do nagrywania rozpoznawania głosu źródła dźwięku.

• MUSI nagrać strumień audio rozpoznawania głosu tak, aby amplituda PCM poziomy liniowo śledzą zmiany poziomu SPL wejściowego w zakresie co najmniej 30 dB od -18 Od dB do +12 dB re 90 dB SPL do mikrofonu.

• NAGRYWAJ strumień audio rozpoznawania głosu z całkowitą harmonią zniekształcenia (THD) poniżej 1% dla 1 kHz przy 90 dB SPL na poziomie sygnału wejściowego mikrofon.

Jeśli implementacje urządzeń zadeklarują android.hardware.microphone i szum technologii ukrywania (redukcji) dostosowanych pod kątem rozpoznawania mowy:

• [C-2-1] MUSI umożliwiać sterowanie tym efektem dźwiękowym za pomocą Interfejs API android.media.audiofx.NoiseSuppressor.
• [C-2-2] MUSI jednoznacznie identyfikować każdą technologię 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 REMOTE_SUBMIX źródła dźwięku.

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

• [C-1-1] MUSI prawidłowo zaimplementować źródło dźwięku REMOTE_SUBMIX, tak by gdy aplikacja używa interfejsu API android.media.AudioRecord, aby nagrywać za pomocą tego źródła dźwięku, rejestruje miks wszystkich strumieni audio z wyjątkiem 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:

• NALEŻY zastosować akustyczny reduktor echa Technologia (AEC) dostrojona pod kątem komunikacji głosowej i zastosowana do ścieżki nagrywania podczas przechwytywania za pomocą AudioSource.VOICE_COMMUNICATION.

Jeśli urządzenia zawierają akustyczną redukcję echa, wstawiono do ścieżki audio przechwytywania, gdy AudioSource.VOICE_COMMUNICATION zostaną zaznaczone:

• [C-SR-1] jest STRONGLY_RECOMMENDED do zadeklarowania tego za pomocą funkcji AcousticEchoCanceler Metoda interfejsu API AcousticEchoCanceler.isAvailable()
• [C-SR-2] jest STRONGLY_RECOMMENDED] umożliwiająca użycie tego efektu audio którą można sterować za pomocą funkcji AcousticEchoCanceler API.
• [C-SR-3] jest STRONGLY_RECOMMENDED jednoznacznie identyfikowana na potrzeby każdej technologii AEC implementacji za pomocą polecenia AudioEffect.Descriptor.uuid .

5.4.5 Jednoczesne przechwytywanie

Jeśli implementacje urządzenia deklarują android.hardware.microphone,MUSZĄ zaimplementuj przechwytywanie równoległe, jak opisano w tym dokumencie. Więcej szczegółów:

• [C-1-1] MUSI zezwalać na równoczesny dostęp do mikrofonu na podstawie ułatwień dostępu usługa przechwytująca za pomocą AudioSource.VOICE_RECOGNITION i co najmniej 1 przechwytywanie aplikacji za pomocą dowolnego AudioSource.
• [C-1-2] MUSI zezwalać na równoczesny dostęp do mikrofonu aplikacja, która ma przypisaną rolę Asystenta i co najmniej 1 aplikację. przechwytywanie z użyciem dowolnej wartości 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, a aplikacja przechwytuje AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER. Jednak gdy aplikacja przechwytuje za pomocą pola AudioSource.VOICE_COMMUNICATION, a następnie innej aplikacji może zarejestrować połączenie głosowe, jeśli jest to uprzywilejowana (wstępnie zainstalowana) aplikacja z uprawnienie CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Jeśli co najmniej 2 aplikacje przechwytują jednocześnie Żadna z nich nie ma u góry interfejsu użytkownika, który rozpoczął przechwytywanie odbiera dźwięk.

5.5. Odtwarzanie dźwięku

Android zapewnia obsługę zezwalającą aplikacjom na odtwarzanie dźwięku urządzenia peryferyjnego wyjściowego zgodnie z definicją w artykule 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 zezwalać na odtwarzanie nieprzetworzonych treści audio z następującymi cechy:

  • Formaty źródłowe: linearny PCM, 16-bitowy, 8-bitowy, liczba zmiennoprzecinkowa
  • Kanały: mono, stereo, prawidłowe konfiguracje wielokanałowe nawet 8 kanałów,
  • Częstotliwość próbkowania (w Hz):
    • 8000, 11025, 16 000, 22050, 24 000, 32 000, 44100, 48 000 w kanale konfiguracje wymienione powyżej
    • 96 000 w mono i stereo

5.5.2 Efekty audio

Android udostępnia interfejs API efektów dźwiękowych. na poszczególne urządzenia.

Jeśli implementacje urządzeń zadeklarują funkcję android.hardware.audio.output, one:

• [C-1-1] MUSI obsługiwać atrybuty EFFECT_TYPE_EQUALIZER i implementacji 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ą zajęcia Visualizer.
• [C-1-3] MUSI obsługiwać implementację EFFECT_TYPE_DYNAMICS_PROCESSING można sterować za pomocą podklasy AudioEffect DynamicsProcessing.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• POWINNA obsługiwać: EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, Implementacje za pomocą narzędzi EFFECT_TYPE_PRESET_REVERB i EFFECT_TYPE_VIRTUALIZER można kontrolować za pomocą podklas AudioEffect BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.
• [C-SR-1] Zdecydowanie ZALECANE jest obsługa efektów w postaci zmiennoprzecinkowej i wielokanałowa.

5.5.3 Wyjściowa głośność dźwięku

Implementacje na urządzeniach motoryzacyjnych:

• POWINNA regulować głośność dźwięku osobno na każdy strumień audio, używając określonego typu lub wykorzystania według: AudioAttributes i użytkowania w samochodzie, jak określono w 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 są przycinanie odtwarzanych treści audio bez przerw między 2 klipami o tym samym formacie gdy zostanie określone przez Interfejs API AudioTrack bez przerw i kontenera multimediów.

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ń, co pozwala uzyskać efekty dźwiękowe.

Na potrzeby tej sekcji należy stosować następujące definicje:

• opóźnienia wyjścia. Odstęp czasu, jaki upływa od momentu, gdy aplikacja zapisuje ramkę danych kodowanych w PCM i gdy odpowiedni dźwięk jest prezentowany w przetworniku urządzenia lub sygnał opuszcza urządzenie i można go obserwować zewnętrznie.
• opóźnienia „na zimno”. Czas między uruchomieniem strumienia wyjściowego a rozpoczęciem czas prezentacji pierwszej klatki na podstawie sygnatur czasowych, gdy wyjście audio system został bezczynny i wyłączony przed wykonaniem żądania.
• ciągły czas oczekiwania na sygnał wyjściowy. opóźnienie wyjściowe kolejnych klatek, gdy urządzenie zacznie odtwarzać dźwięk.
• opóźnienia sygnału wejściowego. Odstęp czasu pomiędzy momentem wyświetlenia dźwięku przez z urządzenia na przetworniku urządzenia lub sygnał trafia do urządzenia przez przez port i gdy aplikacja odczytuje odpowiednią ramkę danych zakodowanych w PCM.
• utraconych danych wejściowych. Początkowa część sygnału wejściowego, który jest bezużyteczny lub niedostępna.
• opóźnienia „zimnego sygnału wejściowego”. Czas między rozpoczęciem transmisji odebranie pierwszej prawidłowej klatki, gdy system wejścia audio był bezczynny, wyłączono przed wysłaniem żądania.
• 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.
• ciągłe opóźnienie w obie strony. Suma ciągłych opóźnień sygnału wejściowego plus ciągły czas oczekiwania na dane wyjściowe plus jeden okres buforowania. Okres buforowania umożliwia czas na przetworzenie sygnału i czas na złagodzenie fazy przez aplikację. między strumieniami wejściowymi a wyjściowymi.
• Interfejs API kolejki buforowej OpenSL ES PCM. Zbiór raportów powiązanych z PCM OpenSL ES Interfejsy API w Androidzie NDK.
• Natywny interfejs API audio audio Zestaw Interfejsy API AAudio w ramach Androida NDK.
• Sygnatura czasowa. Para złożona z względnego położenia klatki w elemencie oraz szacowany czas pojawienia się tej klatki lub jej opuszczania potoku przetwarzania dźwięku w powiązanym punkcie końcowym. Zobacz też AudioTimestamp.
• glitch. Tymczasowa przerwa w działaniu lub nieprawidłowa wartość próbki w sygnale audio; zwykle powodowane przez buforowanie poniżej limitu dla danych wyjściowych, przepełnienia bufora w przypadku wejścia lub jakiegokolwiek innego źródła szumu cyfrowego lub analogowego.
• średnie odchylenie bezwzględne (MAD). Średnia wartości bezwzględnej parametru odchyleń od średniej dla zbioru wartości.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli implementacje urządzeń zadeklarują android.hardware.audio.output, MUSI spełniać lub przewyższać następujące wymagania:

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-1-2] Opóźnienie wyjściowe „na zimno”: 500 milisekund .

• [C-1-3] Otwieranie strumienia wyjściowego za pomocą dodatku AAudioStreamBuilder_openStream() MUSI trwa mniej niż 1000 milisekund.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli implementacje na urządzeniach obejmują android.hardware.microphone, MUSI spełniać te wymagania dotyczące wejściowego dźwięku:

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-3-2] Opóźnienie danych wejściowych „na zimno”: 500 milisekund .
• [C-3-3] Otwieranie strumienia wejściowego za pomocą funkcji AAudioStreamBuilder_openStream() MUSI trwa mniej niż 1000 milisekund.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

5.7. Protokoły sieciowe

Implementacje na urządzeniach MUSZĄ obsługiwać protokoły sieci medialnych do odtwarzania dźwięku i wideo, jak określono w dokumentacji pakietu Android SDK.

Dla każdego kodeka i formatu kontenera, do którego wymagana jest implementacja na urządzeniu na temat implementacji na różnych urządzeniach:

• [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 Protokół HTTP Transmisja na żywo w wersji roboczej, wersja 7.

• [C-1-3] MUSI obsługiwać odpowiednie formaty ładunków protokołu RTSP zgodne z w tabeli RTSP poniżej. Wyjątki znajdziesz w przypisach w tabeli w art. 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 na temat H264 AVC i MPEG2-4 SP znajdziesz w sekcji 5.1.8. i MPEG-2. 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	Zobacz sekcję 5.1.1 .
WebVTT	WebVTT

RTSP (RTP, SDP)

Nazwa profilu	Pliki referencyjne	Wymagana obsługa kodeka
H264 AVC	RFC 6184	Zobacz sekcję 5.1.8 szczegółowe informacje o AVC H264
MP4A-LATM	RFC 6416	Zobacz sekcję 5.1.3. .
H263–1998	RFC 3551 RFC 4629 RFC 2190	Zobacz sekcję 5.1.8 .
H263–2000	RFC 4629	Zobacz sekcję 5.1.8 .
AMR	RFC 4867	Zobacz sekcję 5.1.3. , aby dowiedzieć się więcej o AMR-NB
AMR-WB	RFC 4867	Zobacz sekcję 5.1.3. , aby uzyskać szczegółowe informacje o AMR-WB
MP4V-ES	RFC 6416	Zobacz sekcję 5.1.8 szczegółowe informacje o MPEG-4 SP
mpeg4-generic,	RFC 3640	Zobacz sekcję 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 umożliwiają obsługujących bezpieczne platformy:

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

Jeśli implementacje urządzenia zadeklarują obsługę Display.FLAG_SECURE i obsługi to:

• [C-2-1] MUSI zabezpieczyć link silnym kryptograficznie mechanizmem, takim jak jako HDCP 2.x lub nowszego w przypadku wyświetlaczy połączonych przez protokoły bezprzewodowe takich jak Miracast.

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

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

5.9. Interfejs MIDI (Musical Instrument Digital Interface)

Jeśli implementacje urządzeń zgłaszają obsługę funkcji android.software.midi przez android.content.pm.PackageManager. klasa, to:

• [C-1-1] MUSI obsługiwać MIDI we wszystkich transportach sprzętowych obsługujących MIDI które zapewniają ogólne połączenia inne niż MIDI, gdzie takie środki transportu:

  • 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 przez android.content.pm.PackageManager, klasa, to:

• [C-1-1] MUSI zgłaszać pomoc dotyczącą funkcji android.hardware.audio.low_latency

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-1-3] MUSI zawierać porty USB obsługujące tryb hosta USB i port USB trybu urządzenia peryferyjnego.
• [C-1-4] MUSI zgłosić wsparcie funkcji android.software.midi.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3, 5 mm:

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli w implementacjach urządzenia pomijane są 4-kanałowe gniazdo słuchawek 3,5 mm musi mieć port lub porty USB obsługujące tryb hosta USB, więc:

• [C-3-1] MUSI zaimplementować klasę audio USB.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

5.11. Zrób zdjęcie, aby nie zostały przetworzone

Android zapewnia obsługę nagrywania nieprzetworzonego dźwięku za pomocą Źródło dźwięku: android.media.MediaRecorder.AudioSource.UNPROCESSED. W OpenSL ES, dostęp do niego można uzyskać za pomocą gotowego ustawienia rekordu SL_ANDROID_RECORDING_PRESET_UNPROCESSED

Jeśli implementacja urządzenia ma obsługiwać nieprzetworzone źródło dźwięku i sprawia, aplikacji innych firm, mogą:

• [C-1-1] MUSI zgłosić pomoc na stronie android.media.AudioManager właściwość PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] MUSI wykazywać w przybliżeniu płaską amplitudę w porównaniu do częstotliwości. charakterystyki średniej częstotliwości: ±10 dB od 100 Hz–7000 Hz dla każdego mikrofonu użytego do nagrywania nieprzetworzonej źródła dźwięku.

• [C-1-3] MUSI wykazywać poziomy amplitudy przy niskiej częstotliwości zakres: konkretnie od ±20 dB od 5 z do 100 Hz w porównaniu średniego zakresu częstotliwości dla każdego mikrofonu użytego do nagrywania nieprzetworzone źródło dźwięku.

• [C-1-4] MUSI mieć poziom amplitudy w wysokiej częstotliwości zakres: konkretnie od ±30 dB od 7000 Hz do 22 kHz w porównaniu średniego zakresu częstotliwości dla każdego mikrofonu użytego do nagrywania nieprzetworzone źródło dźwięku.

• [C-1-5] MUSI ustawić czułość wejścia audio na sinusoidalną 1000 Hz źródło tonu odtwarzanego przy poziomie ciśnienia akustycznego 94 dB (SPL) zwraca odpowiedź z Wartość RMS 520 dla próbek 16-bitowych (lub -36 dB w pełnej skali dla zmiennoprzecinkowego/podwójnej wartości próbek precyzji) dla każdego mikrofonu użytego do rejestracji nieprzetworzonej źródła dźwięku.

• [C-1-6] MUSI mieć współczynnik sygnału do szumu (SNR) na poziomie 60 dB lub wyższym każdego mikrofonu użytego do nagrywania nieprzetworzonego źródła dźwięku. (nacisk SNR jest mierzony jako różnica między 94 dB SPL i równoważnym poziomem SPL dla szumu własnego, ważona A).

• [C-1-7] Wartość całkowitego zniekształcenia harmonicznych (THD) musi być mniejsza niż 1% dla 1 kHz przy poziomie sygnału wejściowego SPL 90 dB na każdym mikrofonie używanym do nagrać nieprzetworzone źródło dźwięku.

• [C-1-8] NIE MOŻE obsługiwać żadnych innych procesów przetwarzania sygnału (np.automatycznego wzmocnienia). kontrola, filtr górnoprzepustowy lub anulowanie echa) w ścieżce innej niż w celu dostosowania poziomu do pożądanego zakresu. Krótko mówiąc:

  • [C-1-9] Jeśli w architekturze musi zostać wyłączony i w efekcie nie spowoduje opóźnienia lub i zwiększają opóźnienia w ścieżce sygnału.
  • [C-1-10] Mnożnik poziomu, który może znajdować się na ścieżce, NIE MOŻE wprowadzić 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 mikrofonu.

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

• [C-2-1] MUSI zwrócić null za AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API, aby odpowiednio wskazywać brak wsparcia.
• [C-SR-1] są nadal Zdecydowanie ZALECANE, jeśli chodzi o spełnienie jak największej liczby wymagań. dla ścieżki sygnału nieprzetworzonego źródła nagrania.

5.12. Film HDR

Android 13 obsługuje technologie HDR zgodnie z opisem w kolejnym dokumencie.

Format piksela

Jeśli dekoder wideo reklamuje obsługę formatu color_FormatYUVP010, to:

• [C-1-1] MUSI obsługiwać format P010 w przypadku odczytu z procesora (ImageReader, MediaImage, ByteBuffer). W Androidzie 13 sygnał P010 jest zrelaksowany, aby umożliwić dowolny krok dla osi Y i płaszczyzn UV.

• [C-1-2] Bufor wyjściowy P010 MUSI być dostępny do próbkowania przez GPU (gdy przydzielone z wykorzystaniem GPU_SAMPLING). Umożliwia to komponowanie za pomocą GPU oraz mapowania tonalnego w aplikacjach.

Jeśli dekoder wideo reklamuje obsługę formatu color_Format32bitABGR2101010, oznacza to, że:

• [C-2-1] MUSI obsługiwać format RGBA_1010102 w przypadku powierzchni wyjściowej i Czytelny dla procesora (dane wyjściowe ByteBuffer).

Jeśli koder wideo reklamuje obsługę formatu color_FormatYUVP010, to:

• [C-3-1] MUSI obsługiwać format P010 w przypadku platformy wejściowej i procesora z możliwością zapisu (ImageWriter, MediaImage, ByteBuffer).

.

Jeśli koder wideo reklamuje obsługę formatu color_Format32bitABGR2101010, oznacza to, że:

• [C-4-1] MUSI obsługiwać format RGBA_1010102 w przypadku powierzchni wejściowej i procesora z możliwością zapisu (ImageWriter, ByteBuffer). Uwaga: konwertowanie między różnymi opcjami przenoszenia krzywe NIE są wymagane dla koderów.

Wymagania dotyczące robienia zdjęć HDR

W przypadku wszystkich koderów wideo, które obsługują profile HDR, implementacje urządzeń:

• [C-5-1] NIE MOŻE zakładać, że metadane HDR są dokładne. Na przykład parametr zakodowana klatka może zawierać piksele powyżej szczytowego poziomu luminancji lub histogram może nie być reprezentatywny dla klatki.

• NALEŻY agregować dynamiczne metadane HDR, aby wygenerować odpowiedni statyczny obraz HDR dla zakodowanych strumieni i powinny przesyłać je na końcu każdego i sesji kodowania.

Jeśli implementacje urządzeń obsługują robienie zdjęć HDR przy użyciu interfejsów API CamcorderProfile to:

• [C-6-1] MUSI też obsługiwać robienie zdjęć HDR za pomocą interfejsów API Camera2.

• [C-6-2] MUSI obsługiwać co najmniej jeden koder wideo z akceleracją sprzętową do w każdej obsługiwanej technologii HDR.

• [C-6-3] MUSI obsługiwać (co najmniej) przechwytywanie HLG.

• [C-6-4] MUSI obsługiwać zapisywanie metadanych HDR (jeśli są dostępne w przypadku technologii) do przechwyconego pliku wideo. Formaty AV1, HEVC i DolbyVision oznacza to dołączenie metadanych do zakodowanego strumienia bitowego.

• [C-6-5] MUSI obsługiwać parametry P010 i color_FormatYUVP010.

• [C-6-6] MUSI domyślnie obsługiwać mapowanie tonów z HDR na SDR wspomagany sprzętowo dekoder dla przechwyconego profilu. Innymi słowy, Jeśli urządzenie może rejestrować technologię HDR10+ HEVC, domyślny dekoder HEVC MUSI mieć taką możliwość który pozwala zdekodować przechwycony strumień w SDR.

Wymagania dotyczące edycji HDR

Jeśli implementacje urządzeń obejmują kodery wideo obsługujące edycję HDR, one:

• Generowanie metadanych HDR powinno być minimalne, gdy jej brak, w sposób sprawny radzić sobie z sytuacjami, w których metadane niektórych i nie u innych. Metadane te POWINNY być dokładne (np. reprezentują rzeczywistą szczytową luminancję i histogram klatki).

Jeśli implementacja na urządzeniu obejmuje kodeki obsługujące FEATURE_HdrEditing, tych kodeków:

• [C-7-1] MUSI obsługiwać co najmniej 1 profil HDR.

• [C-7-2] MUSI obsługiwać format FEATURE_HdrEditing w przypadku wszystkich profili HDR reklamowanych przez tego kodeka. Innymi słowy, MUSZĄ one obsługiwać generowanie metadanych HDR, gdy: nie występuje w przypadku wszystkich obsługiwanych profili HDR, które korzystają z metadanych HDR.

• [C-7-3] MUSI obsługiwać poniższe formaty wejściowe kodera wideo, które w pełni zachowaj sygnał zdekodowany HDR:

  • RGBA_1010102 (już na docelowej krzywej transferu) dla obu danych wejściowych i ByteBuffer oraz MUSI reklamować wsparcie color_Format32bitABGR2101010.

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

• [C-7-4] MUSI reklamować obsługę rozszerzenia OpenGL EXT_YUV_target.

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 SDK.
• Android Debug Bridge (adb)

• 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 aktywował Android Debug Bridge. jak powyżej.

• SysTrace,

  • [C-0-9] MUSI obsługiwać narzędzie systrace zgodnie z opisem w pakiecie SDK na Androida. Struktura musi być domyślnie nieaktywna i musi być dostępny dla użytkownika uruchamiający Systrace.

• Perfetto

  • [C-SR-1] Zdecydowanie ZALECANE jest udostępnienie obiektu /system/bin/perfetto do użytkownika powłoki, do której cmdline przestrzega dyrektywa cmdline. dokumentację perfetto.
  • [C-SR-2] Zdecydowanie ZALECANE jest użycie pliku binarnego perfetto jako danych wejściowych konfigurację protokołu Protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR-3] Zdecydowanie ZALECANE jest użycie zapisu binarnego perfetto jako danych wyjściowych ślad protokołu Protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR-4] Zdecydowanie ZALECANE jest podanie za pomocą pliku binarnego perfetto przynajmniej źródeł danych opisanych w dokumentacji perfetto.

• Narzędzie do ograniczania braku pamięci

  • [C-0-12] MUSI napisać LMK_KILL_OCCURRED_FIELD_NUMBER Atom w log statystyczny po zamknięciu aplikacji przez mechanizm zarządzania pamięcią masową.

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

  • [C-2-1] MUSI zwrócić true za ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] MUSI wdrożyć tryb jarzma testowego zgodnie z opisem w Dokumentacja trybu jarzma testowego.

• Informacje o pracy GPU

  Implementacje na urządzeniach:

  • [C-0-13] Aby wyświetlić, TRZEBA zaimplementować polecenie powłoki dumpsys gpu --gpuwork zagregowane dane robocze GPU zwracane przez jądro power/gpu_work_period śledzenia lub nie wyświetlaj żadnych danych, jeśli ten punkt nie jest obsługiwany. AOSP implementacja jest frameworks/native/services/gpuservice/gpuwork/.

Jeśli implementacje urządzeń zgłaszają obsługę Vulkan 1.0 lub nowszej wersji android.hardware.vulkan.version flag funkcji. Są to:

• [C-1-1] MUSI udostępniać deweloper aplikacji w celu włączenia/wyłączenia Warstwy debugowania GPU.
• [C-1-2] Gdy włączone są warstwy debugowania GPU, należy wyliczyć warstwy w biblioteki udostępnione przez narzędzia zewnętrzne (tj. nienależące do platformy lub pakietu aplikacji) w aplikacjach z możliwością debugowania do katalogu podstawowego obsługa metody vkEnumerateInstanceLayerWłaściwości() i vkCreateInstance() Metody API.

6.2. Opcje programisty

Android zapewnia deweloperom możliwość konfigurowania aplikacji związanych z programowaniem.

Implementacje na urządzeniach MUSZĄ zapewniać spójne wrażenia Opcje programisty:

• [C-0-1] MUSI spełniać warunki android.settings.APPLICATION_DEVELOPMENT_SETTINGS aby pokazać ustawienia związane z tworzeniem aplikacji. Nadrzędny Android domyślnie ukrywa menu Opcje programisty i umożliwia użytkownikom uruchom Opcje programisty po naciśnięciu 7 (7) razy w sekcji Ustawienia > Informacje o urządzeniu > Pozycja menu Numer kompilacji.
• [C-0-2] Domyślnie MUSI ukryć Opcje programisty.
• [C-0-3] MUSI zawierać jasny mechanizm, który nie daje preferencji traktowanie jednej aplikacji innej firmy, a nie drugiej, aby umożliwić Deweloperowi Opcje. MUSI zawierać publicznie widoczny dokument lub witrynę z opisem, jak włącz Opcje programisty. Ten dokument lub witryna MUSI zawierać link z pakietu Android SDK.
• MUSI wyświetlać użytkownikowi bieżące powiadomienie wizualne, gdy Deweloper Opcje są włączone, a bezpieczeństwo użytkownika jest zagrożone.
• MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty wizualnie ukrywanie lub wyłączanie menu w celu uniknięcia rozproszenia uwagi w sytuacjach, w których bezpieczeństwo użytkowników.

7. Zgodność sprzętu

Jeśli urządzenie jest wyposażone w konkretny komponent sprzętowy, który ma Interfejs API dla zewnętrznych deweloperów:

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

Jeśli interfejs API w pakiecie SDK wchodzi w interakcję z komponentem sprzętowym, który jest określony jako opcjonalny, a tag implementacja na urządzeniu nie zawiera tego komponentu:

• [C-0-2] Pełne definicje klas (zgodnie z dokumentacją w pakiecie SDK) dla komponentu Interfejsy API MUSZĄ nadal być prezentowane.
• [C-0-3] Działanie interfejsu API MUSI być wdrożone jako brak działań w w świecie mody.
• [C-0-4] Metody interfejsu API MUSZĄ zwracać wartości null tam, gdzie jest to dozwolone przez SDK dokumentacji.
• [C-0-5] Metody interfejsu API MUSZĄ zwracać implementacje klas bezobsługowych, w których wartości null nie są dozwolone w dokumentacji pakietu SDK.
• [C-0-6] Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, których nie opisano w pakiecie SDK dokumentacji.
• [C-0-7] Implementacje urządzeń MUSZĄ konsekwentnie zgłaszać dokładne informacje dotyczące sprzętu informacji o konfiguracji w interfejsach getSystemAvailableFeatures() oraz hasSystemFeature(String) metody na android.content.pm.PackageManager dla tego samego odcisku cyfrowego kompilacji.

Typowym przykładem sytuacji, w której obowiązują te wymagania, jest połączenie telefoniczne API: te interfejsy API należy wdrożyć w rozsądny sposób nawet na urządzeniach innych niż telefony nie działa.

7.1. Wyświetlacz i grafika

Android obejmuje elementy, które automatycznie dostosowują komponenty i interfejs aplikacji układy graficzne treści w taki sposób, aby aplikacje innych firm będą działać na różnych wyświetlaczach i konfiguracjach sprzętowych. An Wyświetlacz zgodny z Androidem to ekran, który obsługuje wszystkie zachowania i interfejsy API opisane w artykule Android Developers – Zgodność ekranu omówienie, to (7.1) i jego podpunktów, a także wszelkie dodatkowe typy urządzeń określonych zachowań opisanych w sekcji 2 dokumentu. CDD.

Implementacje na urządzeniach:

• [C-0-1] Domyślnie MUSI renderować aplikacje innych firm tylko na Wyświetlacze zgodne z Androidem.

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

• fizyczny rozmiar przekątnej. Odległość między dwoma przeciwległymi obiektami w calach w rogach podświetlonej części wyświetlacza.
• gęstość. Liczba pikseli ujętych przez obiekt liniowy rozpiętość pozioma lub pionowa 1", wyrażona w pikselach na cal (ppi lub dpi). Jeśli podane są wartości ppi i dpi, Wartość dpi zarówno w poziomie, jak i w pionie musi mieścić się w wymienionym zakresie.
• format obrazu. Stosunek liczby pikseli dłuższego wymiaru do wartości krótszy wymiar ekranu. Na przykład przy wyświetlaczu o wymiarach 480 x 854 piksele to 854/480 = 1, 779 lub w przybliżeniu „16:9”.
• piksel niezależny od gęstości (dp). Jednostka wirtualnego piksela znormalizowana do gęstości ekranu do 160. Przy niektórych gęstości d a liczba pikseli p, czyli liczba pikseli niezależnych od gęstości dp, to obliczany w ten sposób: dp = (160 / d) * p.

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar i kształt ekranu

Platforma interfejsu Androida obsługuje różne logiczne układy ekranu rozmiarów i pozwala aplikacjom na wysyłanie zapytań dotyczących ekranu bieżącej konfiguracji. rozmiar układu przez Configuration.screenLayout z SCREENLAYOUT_SIZE_MASK i Configuration.smallestScreenWidthDp.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłosić prawidłowy rozmiar układu dla Configuration.screenLayout zgodnie z definicją podaną w dokumentacji pakietu Android SDK. Przede wszystkim implementacje urządzeń MUSZĄ zgłaszać prawidłowe niezależne od gęstości pikseli (dp) wymiary ekranu jak poniżej:

  • Urządzenia, dla których parametr Configuration.uiMode jest ustawiony jako dowolna wartość inna niż UI_MODE_TYPE_WATCH i zgłasza rozmiar small dla Configuration.screenLayout, MUSI mieć co najmniej 426 dp x 320 dp.
  • Urządzenia zgłaszające rozmiar: normal dla: Configuration.screenLayout. MUSI mieć co najmniej 480 dp x 320 dp.
  • Urządzenia zgłaszające rozmiar: large dla: Configuration.screenLayout. MUSI mieć co najmniej 640 dp x 480 dp.
  • Urządzenia zgłaszające rozmiar: xlarge dla: Configuration.screenLayout. MUSI mieć co najmniej 960 dp x 720 dp.

• [C-0-2] MUSI prawidłowo akceptować zgłoszenia stwierdził obsługę rozmiarów ekranu w parametrach <supports-screens> w pliku AndroidManifest.xml, zgodnie z opisem. znajdziesz w dokumentacji pakietu Android SDK.

• MOŻE mieć wyświetlacze zgodne z Androidem z zaokrąglonymi rogami.

Jeśli implementacje urządzeń obsługują ekrany obsługujące Konfiguracja rozmiaru UI_MODE_TYPE_NORMAL i używają ekranów fizycznych z zaokrąglonymi rogami do renderowania. one:

• [C-1-1] MUSI spełniać co najmniej jedno z następujących wymagań dla każdego takiego wyświetlenia:

  • Promień zaokrąglonych rogów nie przekracza 38 dp.
  • Gdy pole o wymiarach 18 dp na 18 dp jest zakotwiczone w każdym rogu wartości logicznej, musi być widoczny co najmniej jeden piksel w każdej ramce.

• POWINNASZ uwzględniać końcową dostępność użytkownika dotyczącą przełączania na tryb wyświetlania za pomocą prostokątnych rogów.

Jeśli implementacje urządzenia mogą skonfigurować tylko klawiaturę NO_KEYS, i zamierzam zgłosić pomoc w trybie interfejsu użytkownika UI_MODE_TYPE_NORMAL , to znaczy, że:

• [C-4-1] MUSI mieć rozmiar co najmniej (z wyłączeniem wycięć w wyświetlaczu) 596 dp x 384 dp lub więcej.

Szczegółowe informacje na temat prawidłowego wdrażania interfejsów API pomocniczych lub rozszerzeń znajdziesz w dokumentacji do publicznej dokumentacji Window Manager Jetpack.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

7.1.1.2. Współczynnik proporcji ekranu

Ta sekcja została usunięta na Androidzie 14.

7.1.1.3 Gęstość ekranu

Platforma UI Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić którzy chcą wykorzystywać zasoby aplikacji.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłosić jedną z wymienionych gęstości interfejsu na Androida na stronie DisplayMetrics za pomocą interfejsu API DENSITY_DEVICE_STABLE i musi być wartością statyczną każdego wyświetlacza. Jednak urządzenie MOŻE zgłoś inny element DisplayMetrics.density zgodnie ze zmianami w konfiguracji wyświetlacza wprowadzonymi przez użytkownika (na np. rozmiar wyświetlacza) ustawiony po pierwszym uruchomieniu.

• MUSI zdefiniować standardową gęstość platformy Androida, która jest liczbowa która jest najbliższa fizycznej gęstości ekranu lub wartości, która zostałaby zmapowana takich samych pomiarów pola widzenia jak w przypadku urządzenia mobilnego.

Jeśli implementacje urządzeń zapewniają zmiana rozmiaru wyświetlacza urządzenia:

• [C-1-1] NIE MOŻE skalować wyświetlacza większego niż 1,5 raza DENSITY_DEVICE_STABLE lub ustaw minimalny rozmiar ekranu mniejszy niż 320 dp (odpowiednik do kwalifikatora zasobów sw320dp) w zależności od tego, co nastąpi wcześniej.
• [C-1-2] NIE MOŻE skalować wyświetlacza mniejszy niż 0,85 raza więcej niż DENSITY_DEVICE_STABLE.
• Aby zapewnić wygodę użytkowania i spójne rozmiary czcionek, ZALECANE jest dodanie podane niżej opcje skalowania opcji natywnych reklam displayowych (przy zachowaniu zgodności z limitami: określone 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 wideo na ekrany displayowe zgodne z Androidem:

• [C-1-1] MUSI podawać prawidłowe wartości w przypadku wszystkich wyświetlaczy zgodnych z Androidem zdefiniowanych w android.util.DisplayMetrics API.

Jeśli implementacje urządzeń nie zawierają osadzonego ekranu lub wyjścia wideo, one:

• [C-2-1] MUSI podawać prawidłowe wartości wyświetlacza zgodnego z Androidem zgodnie z definicją podaną w interfejsie API android.util.DisplayMetrics. dla emulowanej wartości domyślnej 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łosić co najmniej jedną obsługiwaną orientacji ekranu. Na przykład urządzenie ze stałą orientacją poziomą. np. telewizora czy laptopa, POWINNY BYĆ raport android.hardware.screen.landscape.
• [C-0-2] MUSI zgłosić prawidłową wartość obecnego urządzenia przy wysyłaniu zapytań za pomocą metody 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. orientacji ekranu. Oznacza to, że urządzenie musi respektować żądanie aplikacji dotyczące określonego ekranu. 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 obejmować obsługę wszystkich odpowiednich zarządzanych interfejsów API natywne interfejsy API dla każdej wersji OpenGL ES, którą zidentyfikowano do obsługi.

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

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• MUSI obsługiwać standard OpenGL ES 3.2.

Testy OpenGL ES dEQP są podzielone na różne listy testowe, z których każda zawiera z powiązaną datą lub numerem wersji. Znajdziesz je w drzewie źródłowym Androida na stronie 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 przekazywać dEQP testów na wszystkich listach testowych na tym poziomie i starszych.

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

• [C-2-1] MUSI generować raporty za pomocą zarządzanych interfejsów API OpenGL ES i natywnych interfejsów API innych zaimplementowanych przez nich rozszerzeń OpenGL ES i odwrotnie MUSI NIE zgłaszaj ciągów rozszerzeń, które nie są obsługiwane.
• [C-2-2] MUSI obsługiwać atrybuty: 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 rozszerzenia.
• [C-2-3] MUSI zgłaszać maksymalną wersję testów dEQP OpenGL ES obsługiwane przez flagę funkcji android.software.opengles.deqp.level.
• [C-2-4] MUSI obsługiwać co najmniej wersję 132383489 (od 1 marca 2020 r.) jako zgłoszone we fladze android.software.opengles.deqp.level.
• [C-2-5] MUSI przejść wszystkie testy OpenGL ES dEQP na listach testowych pomiędzy wersjami 132383489 a wersja określona w Flaga funkcji android.software.opengles.deqp.level, dla każdej obsługiwanej funkcji Wersja OpenGL ES.
• [C-SR-2] Zdecydowanie ZALECANE jest działanie funkcji EGL_KHR_partial_update i OES_EGL_image_external rozszerzenia.

• WYMAGANE jest precyzyjne raportowanie za pomocą metody getString(), dowolna tekstura obsługiwanego przez nich formatu kompresji, który jest zwykle zależny od dostawcy.

• POWINNA obsługiwać EGL_IMG_context_priority i EGL_EXT_protected_content rozszerzenia.

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 w z symbolami funkcji OpenGL ES 2.0 w bibliotece libGLESv2.so.
• [C-SR-3] Zdecydowanie ZALECANE jest działanie funkcji 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ń obsługują pakiet rozszerzeń OpenGL ES całość, to znaczy, że:

• [C-5-1] MUSI określić pomoc na android.hardware.opengles.aep flagę funkcji.

Jeśli implementacje urządzeń zapewniają obsługę EGL_KHR_mutable_render_buffer Google:

• [C-6-1] MUSI też obsługiwać EGL_ANDROID_front_buffer_auto_refresh .

7.1.4.2. Wulkan

Android obsługuje języki Vulkan, niewymagający dużych nakładów pracy, wieloplatformowy interfejs API do obsługi wysokiej wydajności grafiki 3D.

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

• [C-SR-1] Zdecydowanie ZALECANE jest dodanie obsługi: Vulkan 1.3
• [C-4-1] NIE MOŻE obsługiwać wersji interfejsu Vulkan (tj. wariantu) części podstawowej interfejsu Vulkan MUSI mieć wartość zero).

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

• [C-SR-2] Zdecydowanie ZALECANE jest dodanie obsługi Vulkan 1.3

Testy Vulkan dEQP są podzielone na kilka list testowych, z których każda zawiera parametr powiązanej daty/wersji. Znajdziesz je w drzewie źródłowym Androida na stronie external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt Urządzenie, które obsługuje Vulkan na poziomie zgłoszonym przez siebie, wskazuje, że może przejść dEQP testów na wszystkich listach testowych na tym poziomie i starszych.

Jeśli implementacje urządzeń obejmują obsługę interfejsu Vulkan:

• [C-1-1] MUSI zgłaszać prawidłową liczbę całkowitą z android.hardware.vulkan.level i android.hardware.vulkan.version flag funkcji.
• [C-1-2] MUSI wyliczyć co najmniej jeden element VkPhysicalDevice dla interfejsu Vulkan natywnego interfejsu API vkEnumeratePhysicalDevices().
• [C-1-3] MUSI w pełni wdrożyć interfejsy Vulkan 1.1 API w przypadku każdego wymienionego VkPhysicalDevice
• [C-1-4] MUSI wyliczać warstwy zawarte w bibliotekach natywnych o nazwach libVkLayer*.so w natywnym katalogu biblioteki pakietu aplikacji, za pomocą natywnych interfejsów API Vulkan vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties().
• [C-1-5] NIE MOŻE wyliczać warstw udostępnianych przez biblioteki spoza aplikacji ani zapewniać innych sposobów śledzenia lub przechwytywania Interfejs Vulkan API, chyba że aplikacja ma atrybut android:debuggable ustawiono jako true lub metadane com.android.graphics.injectLayers.enable ustawiono na true.
• [C-1-6] MUSI podawać w parametrze Natywne interfejsy API Vulkan i odwrotnie NIE MOGĄ raportować ciągów rozszerzeń które są nieprawidłowo obsługiwane.
• [C-1-7] MUSI obsługiwać platformy 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ługiwane przez flagę funkcji android.software.vulkan.deqp.level.
• [C-1-9] MUSI obsługiwać co najmniej wersję 132317953 (od 1 marca 2019 r.) jako zgłoszone we fladze funkcji android.software.vulkan.deqp.level.
• [C-1-10] MUSI przejść wszystkie testy Vulkan dEQP na listach testowych od w wersji 132317953 oraz wersji określonej w parametrze flaga funkcji android.software.vulkan.deqp.level.
• [C-1-11] NIE MOŻE liczyć wsparcia dla VK_KHR_video_queue, VK_KHR_video_decode_queue lub VK_KHR_video_encode_queue.
• [C-SR-3] Zdecydowanie ZALECANE jest działanie funkcji VK_KHR_driver_properties i VK_GOOGLE_display_timing rozszerzenia.
• [C-1-12] NIE MOŻE wyszczególniać obsługi rozszerzenia VK_KHR_performance_query.
• [C-SR-4] Zdecydowanie ZALECANE jest spełnić wymagania określone przez profilu Android Baseline 2022,
• [C-SR-5] Zdecydowanie ZALECANE jest działanie funkcji VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory i VK_EXT_global_priority.
• [C-SR-6] Zdecydowanie ZALECANE jest użycie narzędzia SkiaVk z HWUI.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

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ń obejmują obsługę interfejsu Vulkan 1.1 i zadeklarują Państwo flagi funkcji interfejsu Vulkan opisane tutaj; one:

• [C-3-1] MUSI udostępniać obsługę zewnętrznego semfora i uchwytu SYNC_FD i rozszerzenie VK_ANDROID_external_memory_android_hardware_buffer.

• [C-SR-7] Zdecydowanie ZALECANE jest wykonanie VK_KHR_external_fence_fd rozszerzenie dostępne dla aplikacji innych firm i włączenie aplikacji do eksportowania ładunku ogrodzenia do i importowania ładunku ogrodzenia z pliku POSIX deskryptory zgodnie z opisem tutaj.

7.1.4.3 RenderScript

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać język Android RenderScript, jak opisano w dokumentacji pakietu Android SDK.

7.1.4.4 Przyspieszenie działania grafiki 2D

Android obejmuje mechanizm deklarowania przez aplikacje, że włącz akcelerację sprzętową grafiki 2D w polach Aplikacje, Aktywność, Poziom okna lub widoku za pomocą tagu manifestu android:hardwareAccelerated, lub bezpośrednich wywołaniach API.

Implementacje na urządzeniach:

• [C-0-1] MUSI domyślnie włączać akcelerację sprzętową i MUSI wyłącz akcelerację sprzętową, jeśli deweloper prosi o to przez ustawienie android:hardwareAccelerated="false" (w języku angielskim) lub wyłączenie akceleracji sprzętowej bezpośrednio w interfejsach API Android View.
• [C-0-2] MUSI wykazywać zachowanie zgodne z Dokumentacja pakietu Android SDK na temat akceleracji sprzętowej.

Android zawiera obiekt TextureView, który umożliwia programistom bezpośrednią integrację wspierane sprzętowo tekstury OpenGL ES jako cele renderowania w hierarchii UI.

Implementacje na urządzeniach:

• [C-0-3] MUSI obsługiwać interfejs TextureView API i MUSI wyświetlać zachowanie spójne z wcześniejszą implementacją Androida.

7.1.4.5. Wyświetlacze o szerokiej gamie

Jeśli implementacje urządzenia zgłaszają obsługę wyświetlaczy o szerokim zakresie Configuration.isScreenWideColorGamut():

• [C-1-1] MUSI mieć wyświetlacz z kalibracją kolorów.
• [C-1-2] MUSI mieć wyświetlacz z paletą kolorów sRGB. w całości w przestrzeni CIE 1931 xyY.
• [C-1-3] MUSI mieć wyświetlacz, którego gama obejmuje co najmniej 90% DCI-P3 w CI 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ć wsparcie: 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 rozszerzeń.
• [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 pokryć co najmniej 100% pamięci sRGB w przestrzeni CIE 1931 xyY, chociaż 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 „normalny” tryb równoważny rozmiarem ekranu (szerokości 320 dp) aplikacje nieopracowane na starsze wersje Androida starsze niż niezależnie od rozmiaru ekranu.

7.1.6 Technologia ekranu

Platforma Androida zawiera interfejsy API, które umożliwiają aplikacjom renderowanie na wyświetlacz zgodny z Androidem. Urządzenia MUSZĄ obsługiwać wszystkie te funkcje Interfejsy API zdefiniowane w pakiecie Android SDK, chyba że 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) pomiędzy 0,9 a 1,15. Oznacza to, że proporcje piksela MUSZĄ być zbliżone do kwadratu (1,0) z tolerancją wynoszącą 10 ~ 15%.

7.1.7 Wyświetlacze dodatkowe

Android zapewnia obsługę dodatkowych wyświetlaczy zgodnych z tym systemem, funkcje udostępniania multimediów i interfejsy API dla programistów umożliwiające dostęp do wyświetlaczy zewnętrznych.

Jeśli urządzenia obsługują zewnętrzny wyświetlacz za pomocą przewodowego, bezprzewodowe lub połączenie z dodatkowym ekranem:

• [C-1-1] MUSI zaimplementować DisplayManager i usług systemowych oraz interfejsu API zgodnie z opisem w dokumentacji pakietu Android SDK.

7.2. Urządzenia wejściowe

Implementacje na urządzeniach:

• [C-0-1] MUSI zawierać mechanizm wprowadzania danych, taki jak ekran dotykowy lub nawigacja bezdotykowa, do poruszania się między elementami interfejsu.

7.2.1. Klawiatura

Jeśli implementacje urządzeń obejmują obsługę rozwiązań innych firm aplikacje edytora metod wprowadzania (IME);

• [C-1-1] MUSI zadeklarować parametr android.software.input_methods flagę funkcji.
• [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, która nie pasuje do formatów określonych w argumencie android.content.res.Configuration.keyboard, (QWERTY lub 12-klawiszowy).
• POWINNY BYĆ dodatkowe implementacje klawiatury programowej.
• MOŻE zawierać klawiaturę sprzętową.

7.2.2 Nawigacja bezdotykowa

Android zapewnia obsługę pada kierunkowego, trackballa i kółka bezdotykowa nawigacja.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłaszać prawidłową wartość dla android.content.res.Configuration.navigation

Jeśli w urządzeniach nie ma nawigacji niedotykowej:

• [C-1-1] MUSI zapewniać uzasadniony alternatywny mechanizm interfejsu użytkownika zaznaczania i edytowania tekstu, kompatybilna z mechanizmami zarządzania danymi wejściowymi. implementacja open source Androida obejmuje mechanizm wyboru. odpowiedni do użytku z urządzeniami, które nie mają dotykowego, bezdotykowego wejścia do nawigacji.

7.2.3 Klawisze nawigacyjne

Strona główna, Ostatnie, i Wstecz funkcje obsługiwane zwykle przez interakcję z dedykowanym przyciskiem fizycznym lub odrębnej części ekranu dotykowego są niezbędne paradygmat nawigacji, a tym samym wdrożenia urządzeń:

• [C-0-1] MUSI zapewniać użytkownikowi możliwości uruchamiania zainstalowanych aplikacji ma aktywność z elementem <intent-filter> ustawionym z parametrami ACTION=MAIN i CATEGORY=LAUNCHER lub CATEGORY=LEANBACK_LAUNCHER w przypadku telewizora implementacji. 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 ramach jednej czynności (np. kliknięcia, dwukrotnego kliknięcia lub gestu palca), gdy którekolwiek z nich jest dostępne.
• [C-1-2] MUSI wyraźnie wskazywać, które działanie może wywołać działanie. dla każdej funkcji. z nadrukowaną ikoną na przycisku oraz informacją o oprogramowaniu; znajdującą się na pasku nawigacyjnym albo prowadząc użytkownika przez szczegółowe instrukcje konfigurowania podczas konfiguracji na przykłady tego typu wskazania.

Implementacje na urządzeniach:

• Zdecydowanie ZALECANE jest nieudostępnianie mechanizmu wprowadzania danych dla funkcji Funkcja menu ponieważ w Androidzie 4.0 został wycofany pasek działań.

• [C-SR-2] Zdecydowanie zaleca się zapewnić wszystkie funkcje nawigacyjne nie można anulować. „Można anulować” jest zdolność użytkownika do zapobiegania nie zostanie wykonana funkcja nawigacji (np. powrót do domu, powrót do domu itp.), jeśli funkcja nie udaje się przekroczyć określonego progu.

Jeśli implementacje urządzeń zapewniają funkcję menu, są to:

• [C-2-1] MUSI wyświetlać dodatkowy przycisk działania, gdy działanie nie jest puste, a pasek działań jest widoczny.
• [C-2-2] NIE MOŻE zmieniać pozycji wyskakującego okienka rozszerzonego działania wyświetlane po kliknięciu przycisku rozszerzonego na pasku działań, ale MOGĄ wyskakujące okienko działania w zmodyfikowanym położeniu na ekranie, gdy jest można wyświetlić po wybraniu funkcji menu.

Jeśli implementacje urządzeń nie udostępniają funkcji menu, w przypadku instrukcji wstecznych zgodność ze standardami:

• [C-3-1] MUSI udostępnić funkcję Menu aplikacjom, gdy Wartość targetSdkVersion jest mniejsza niż 10 (przy użyciu fizycznego przycisku, klucza oprogramowania) lub gestami. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z z innych funkcji nawigacji.

Jeśli implementacje na urządzeniach udostępniają funkcję wspomagania, one:

• [C-4-1] MUSI udostępnić funkcję wspomagania jednym działaniem. (np. klikając, dwukrotnie lub przy użyciu gestów), gdy dostępne są inne klawisze nawigacyjne.
• [C-SR-3] Zdecydowanie zalecamy przytrzymanie funkcji ekranu głównego, ponieważ wyznaczonej interakcji.

Jeśli implementacje urządzeń wykorzystują osobną część ekranu do wyświetlania klawisze nawigacyjne:

• [C-5-1] Klawisze nawigacyjne MUSZĄ zajmować osobną część ekranu, nie i NIE MOŻE zasłaniać ani w inny sposób zakłócać fragmentu ekranu dostępnego dla aplikacji.
• [C-5-2] MUSI udostępniać część wyświetlacza aplikacjom, spełnia wymagania określone w sekcji 7.1.1.
• [C-5-3] MUSI uwzględniać flagi ustawione przez aplikację w View.setSystemUiVisibility(). API, aby ta charakterystyczna część ekranu (inaczej pasek nawigacyjny) jest poprawnie ukryty, jak opisano w pakietu SDK.

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

• [K-6–1] WindowInsets#getMandatorySystemGestureInsets() MOŻNA używać tylko do zgłaszania obszaru rozpoznawania gestów na ekranie głównym.
• [C-6-2] Gesty rozpoczynające się w polu prostokątnym zdefiniowanym w parametrze aplikacji działających na pierwszym planie za pośrednictwem View#setSystemGestureExclusionRects() ale poza WindowInsets#getMandatorySystemGestureInsets(), NIE MOŻE być przechwytywane dla funkcji nawigacji, jeśli wykluczenie jest dozwolony w ramach maksymalnego limitu wykluczeń określonego w dokumentacja dla View#setSystemGestureExclusionRects()
• [C-6-3] MUSI wysłać do aplikacji na pierwszym planie MotionEvent.ACTION_CANCEL gdy dotknięcie jest przechwytywane przez gest systemowy, jeśli do aplikacji na pierwszym planie została wcześniej wysłana MotionEvent.ACTION_DOWN .
• [C-6-4] MUSI zapewniać użytkownikom dostęp do funkcji na ekranie, nawigacja przy użyciu przycisków (np. w Ustawieniach).
• Trzeba udostępnić funkcję ekranu głównego, przesuwając palcem z dołu ekranu w górę. bieżącej orientacji ekranu.
• Trzeba udostępnić funkcję Ostatnie – przesuń palcem w górę i przytrzymaj przed zwolnieniem w tym samym obszarze co gest ekranu głównego.
• Gesty rozpoczynające się w obrębie WindowInsets#getMandatorySystemGestureInsets() NIE NALEŻY oddziaływać na żądania wykluczania podawane na pierwszym planie. aplikacji przez View#setSystemGestureExclusionRects()

Jeśli funkcja nawigacji jest dostępna z dowolnego miejsca na lewej i prawej krawędzi bieżącej orientacji ekranu:

• [C-7-1] Funkcja nawigacji MUSI być „Wstecz” i być przesuń palcem od lewej i prawej krawędzi bieżącej orientacji ekranu.
• [C-7-2] Jeśli po lewej stronie lub krawędzie, należy je umieścić w górnej 1/3 wyraźny, stały sygnał wizualny, że przeciągnięcie reklamy wywoła wspomnianych paneli, a więc nie Wstecz. Panel systemowy MOŻE być skonfigurowane przez użytkownika w taki sposób, że znajdują się poniżej 1/3 górnej części ekranu krawędzie, ale panel systemowy NIE MOŻE być dłuższy niż 1/3.
• [C-7-3] Gdy aplikacja na pierwszym planie ma albo View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub Ustawiono flagi WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SSTORAGE, przesunięcie od krawędzi MUSI działać tak samo jak w AOSP, o treściach udokumentowanych w pakiecie SDK.
• [C-7-4] Gdy aplikacja na pierwszym planie ma parametr View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub Ustawiono flagi WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SSTORAGE, niestandardowe przesuwane panele systemowe MUSZĄ być ukryte do czasu, aż użytkownik wejdzie Usuwa przyciemnienie pasków systemowych (tzw. nawigacji i paska stanu) po zaimplementowaniu w AOSP.

Jeśli dostępna jest funkcja przechodzenia wstecz, a użytkownik anuluje gestu, a następnie:

• [C-8-1] Trzeba zadzwonić do użytkownika OnBackInvokedCallback.onBackCancelled().
• [C-8-2] NIE NALEŻY wywoływać funkcji OnBackInvokedCallback.onBackInvoked().
• [C-8-3] Zdarzenie KEYCODE_BACK NIE MOŻE być wysyłane.

Jeśli podana jest funkcja przechodzenia wstecz, ale aplikacja na pierwszym planie ją NIE masz zarejestrowanego konta OnBackInvokedCallback, to wtedy:

• System powinien udostępnić animację na pierwszym planie, która sugeruje, że użytkownik wraca, zgodnie z AOSP.

Jeśli implementacje urządzeń zapewniają obsługę systemowego interfejsu API setNavBarMode do zezwól dowolnej aplikacji systemowej z uprawnieniami android.permission.STATUS_BAR na ustawianie trybu paska nawigacyjnego, a następnie:

• [C-9-1] MUSI obsługiwać ikony przyjazne dzieciom lub wykorzystujące przyciski nawigacji zgodnie z kodem AOSP.

7.2.4 Wprowadzanie tekstu z ekranu dotykowego

Android zapewnia obsługę różnych systemów wprowadzania danych wskaźnikach, takich jak ekrany dotykowe, pady dotykowe i imitacje dotykowych urządzeń wejściowych. Implementacje na urządzeniach z ekranem dotykowym są powiązane z reklamą displayową, tak aby użytkownik miał wrażenie, do manipulowania elementami na ekranie. Użytkownik dotyka bezpośrednio ekranu, system nie wymaga żadnych dodatkowych afordancji wskazujących obiekty być manipulowany.

Implementacje na urządzeniach:

• POWINNY jest mieć jakiś system wprowadzania danych z użyciem wskaźników (jak mysz lub dotyk).
• POWINNA obsługiwać w pełni niezależnie śledzone wskaźniki.

Jeśli urządzenia są wyposażone w ekran dotykowy (pojedynczy dotyk lub lepszy) głównych wyświetlaczy zgodnych z Androidem:

• [C-1-1] MUSI zgłosić TOUCHSCREEN_FINGER za Configuration.touchscreen API.
• [C-1-2] MUSI zgłosić android.hardware.touchscreen i android.hardware.faketouch flag funkcji.

Jeśli urządzenia są wyposażone w ekran dotykowy, który może śledzić więcej niż za pomocą jednego kliknięcia 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ący typowi ekranu dotykowego urządzenia.

korzystanie z zewnętrznego urządzenia wejściowego, takiego jak mysz czy kulka (tj. nie dotykając ekranu bezpośrednio) w celu wprowadzania na Wyświetlacz zgodny z Androidem i spełnianie wymagań dotyczących fałszywego dotyku art. 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ć użytkownika TOUCHSCREEN_NOTOUCH za Configuration.touchscreen. API.

7.2.5 Wprowadzanie tekstu fałszywego dotykiem

Interfejs fałszywego dotykowego udostępnia system wprowadzania danych użytkownika, który w przybliżeniu przedstawia podzbiór funkcje ekranu dotykowego. Na przykład mysz lub pilot, którego można używać kursor na ekranie przybliża go do kliknięcia, ale wymaga od użytkownika pierwszego wpisania zaznacz i kliknij. Liczne urządzenia wejściowe, takie jak mysz, trackpad czy żyroskop mysz powietrzna, żyroskop, joystick i trackpad z obsługą wielodotykową obsługują fałszywe dotykiem. Android udostępnia stałą funkcję android.hardware.faketouch, który odpowiada wysokiej jakości bezdotykowemu procesorowi. urządzenie wejściowe (oparte na wskaźniku), np. mysz lub trackpad, emuluje wprowadzanie danych dotykiem (w tym podstawową obsługę gestów) i wskazuje, że Urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.

Jeśli urządzenia nie zawierają ekranu dotykowego, tylko systemu wprowadzania wskaźników, który chce udostępnić, to:

• Trzeba zadeklarować obsługę flagi funkcji android.hardware.faketouch.

Jeśli implementacje urządzeń zadeklarują obsługę android.hardware.faketouch, one:

• [C-1-1] MUSI podawać bezwzględne położenie ekranu X i Y. lokalizacji wskaźnika i wyświetlić wskaźnik wizualny na ekranie.
• [C-1-2] MUSI zgłaszać zdarzenie dotknięcia za pomocą kodu działania, który określa zmiana stanu występująca we wskaźniku w górę lub w dół ekranu.
• [C-1-3] MUSI obsługiwać wskaźnik w dół i w górę na obiekcie na ekranie, co pozwala emulować kliknięcie obiektu na ekranie.
• [C-1-4] MUSI obsługiwać wskaźnik w dół, wskaźnik w górę, wskaźnik w dół, a następnie w górę. w tym samym miejscu na obiekcie na ekranie w czasie, który umożliwia użytkownikom emulację dwukrotnego dotknięcia. na obiekcie na ekranie.
• [C-1-5] MUSI obsługiwać kursor w dowolnym punkcie na ekranie. przesuń wskaźnik do dowolnego innego punktu na ekranie, a po nim wskaźnik w górę, co umożliwia emulację przeciągnięcia dotykiem.
• [C-1-6] MUSI zapewniać wsparcie w dół, a następnie umożliwiać użytkownikom szybkie ustaw obiekt w innym miejscu na ekranie, a następnie wskaż kursorem w górę, które umożliwia użytkownikom przesuwanie obiektu na ekranie.

Jeśli implementacje urządzeń zadeklarują obsługę android.hardware.faketouch.multitouch.distinct, to:

• [C-2-1] MUSI zadeklarować obsługę interfejsu android.hardware.faketouch.
• [C-2-2] MUSI obsługiwać odrębne śledzenie co najmniej dwóch niezależnych wskaźników danych wejściowych.

Jeśli implementacje urządzeń zadeklarują obsługę android.hardware.faketouch.multitouch.jazzhand, to:

• [C-3-1] MUSI zadeklarować obsługę interfejsu android.hardware.faketouch.
• [C-3-2] MUSI obsługiwać odrębne śledzenie 5 (śledzenie dłoni) całkowicie niezależnie.

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)
Górny pad kierunkowy1 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 grze pad CA (0x01 0x0005).

3 To użycie musi mieć wartość logiczną minimum 0, Logiczne maksimum: 7, fizyczne minimum: 0, fizyczne maksimum: 315, jednostki w stopniach i 4. Wartość logiczna jest zdefiniowana jako obracanie 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 klawisze w górę i w lewo są naciśnięto.

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 API dla programistów zewnętrznych, implementacja urządzeń MUSI zaimplementować ten interfejs API w sposób opisany w dokumentacji pakietu Android SDK i znajdziesz w dokumentacji Androida open source poświęconej czujnikom.

Implementacje na urządzeniach:

• [C-0-1] MUSI dokładnie zgłaszać obecność lub brak czujników zgodnie z android.content.pm.PackageManager zajęcia.
• [C-0-2] MUSI zwracać dokładną listę obsługiwanych czujników przez SensorManager.getSensorList() i podobne metody.
• [C-0-3] MUSI działać w rozsądny sposób w przypadku wszystkich innych interfejsów API czujników (na przykład zwracanie odpowiednio true lub false, gdy aplikacje próbują zarejestrować detektorów i nie wywoływać odbiorników, gdy odpowiadające im czujniki obecny; itp.).

Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma API dla zewnętrznych deweloperów:

• [C-1-1] MUSI raportować wszystkie pomiary z czujnika używając odpowiednich wartości Międzynarodowego Systemu Jednostek (danych) dla każdego z nich. Typ czujnika zgodny z definicją podaną w dokumentacji pakietu Android SDK.
• [C-1-2] MUSI raportować dane z czujnika z maksymalnym opóźnieniem 100 milisekund + 2 * sample_time w przypadku strumienia czujnika z maksymalny żądany czas oczekiwania wynoszący 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 * sample_time czujnika podczas aktywacji. Próbka może mieć mają dokładność 0.
• [C-1-4] W przypadku każdego interfejsu API wskazanego w dokumentacji pakietu Android SDK jako czujnika ciągłego, na różnych urządzeniach MUSI zapewniać okresowych próbek danych, w przypadku których zakłócenia powinny być mniejsze niż 3%, gdzie zakłócenia są zdefiniowane jako odchylenie standardowe różnicy raportowania wartości sygnatur czasowych między kolejnymi zdarzeniami.
• [C-1-5] MUSI upewnić się, że strumień zdarzeń z czujnika NIE MOŻE uniemożliwiać przejścia w stan zawieszenia lub wybudzenia procesora urządzenia ze stanu zawieszenia.
• [C-1-6] MUSI zgłaszać godzinę wydarzenia w nanosekundach zgodnie z definicją zawartą w dokumentacji pakietu Android SDK, która reprezentuje i czasu wystąpienia zdarzenia oraz zsynchronizowanego z Zegar SystemClock.elapsedRealtimeNano().
• [C-SR-1] Zdecydowanie ZALECANE jest wystąpienie błędu synchronizacji sygnatury czasowej. poniżej 100 milisekund, a błąd synchronizacji sygnatury czasowej powinien być mniejszy niż 1 milisekundę.
• Gdy jest aktywnych kilka czujników, zużycie energii NIE POWINNO przekraczać suma zużycia energii przez dany czujnik.

Powyższa lista nie jest wyczerpująca. udokumentowane działanie pakietu Android SDK oraz dokumentację Android Open Source czujniki, wiarygodny.

Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma API dla zewnętrznych deweloperów:

• [C-1-6] MUSI ustawić rozdzielczość inną niż 0 dla wszystkich czujników i zgłosić wartość przez: Sensor.getResolution() API.

Niektóre typy czujników są złożone, co oznacza, że mogą pochodzić z dostarczonych danych przez co najmniej jeden inny czujnik. (Na przykład czujnik orientacji oraz czujnik przyspieszenia liniowego).

Implementacje na urządzeniach:

• Należy wdrożyć te typy czujników, jeśli muszą skonfigurować wstępne czujniki fizyczne zgodnie z opisem w typach czujników.

Jeśli implementacje urządzeń zawierają czujnik kompozytowy,:

• [C-2-1] NALEŻY zaimplementować czujnik w sposób opisany w witrynie Android Open Source. dokumentacji na temat czujników kompozytowych.

Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma odpowiadający interfejsowi API dla zewnętrznych programistów, a czujnik zgłasza tylko jeden wartości oraz implementacje urządzeń:

• [C-3-1] MUSI ustawiać rozdzielczość czujnika na 1 i zgłaszać wartość przez: Sensor.getResolution() API.

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który obsługuje Dodatkowe informacje: #TYPE_VEC3_CALIBRATION a czujnik jest narażony na działanie innych deweloperów, dlatego:

• [C-4-1] NIE MOŻE zawierać żadnej stałej kalibracji określonej przez fabrykę w podanych danych.

Jeśli w implementacji urządzenia zastosowano kombinację 3-osiowego akcelerometru, 3-osiowy żyroskop lub czujnik magnetometru. Są to:

• [C-SR-2] Zdecydowanie ZALECANY, aby zapewnić działanie akcelerometru, żyroskopu magnetometr ma stałe położenie względne, na przykład gdy urządzenie przekształcalność (np.składana), osie czujnika pozostają wyrównane i spójne. z układem współrzędnych czujnika we wszystkich możliwych urządzeniach, i stanów przekształcenia.

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ą akcelerometr:

• [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-3] MUSI być zgodny z Układ współrzędnych czujnika Androida jak opisano w interfejsach API Androida.
• [C-1-4] MUSI być w stanie mierzyć od swobodnego spadania do czterech razy większej gravity(4g) lub więcej 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^, gdzie odchylenie standardowe powinno zostać obliczone na podstawie poszczególnych osi dla próbek zebrane w okresie co najmniej 3 sekund z najszybszą częstotliwością próbkowania.
• POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.
• Rozdzielczość powinna wynosić co najmniej 16 bitów.
• NALEŻY kalibrować podczas używania, jeśli parametry zmienią się cykl życia i kompensacji oraz zachowanie parametrów wynagrodzenia między restartami urządzeń.
• POWINNA być kompensowana temperatura.

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

• [C-2-1] MUSI zaimplementować i zgłosić czujnik TYPE_ACCELEROMETER.
• [C-SR-4] Zdecydowanie ZALECANE jest wdrożenie TYPE_SIGNIFICANT_MOTION czujnika kompozytu.
• [C-SR-5] Zdecydowanie ZALECANE są wdrożenie i raportowanie Czujnik TYPE_ACCELEROMETER_UNCALIBRATED. Urządzenia z Androidem są ZDECYDOWANIE ZALECANE, aby spełnić to wymaganie i zyskać możliwość przejścia na w przyszłej wersji platformy, w której może to stać się WYMAGANE.
• NALEŻY zaimplementować TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR (TYPE_STEP_COUNTER) czujniki złożone zgodnie z opisem w dokumentacji pakietu Android SDK.

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

• [C-3-1] MUSI zaimplementować i zgłosić czujnik TYPE_ACCELEROMETER_LIMITED_AXES.
• [C-SR-6] Są STRONGLY_ZALECANE do wdrożenia i raportowania Czujnik TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Jeśli w urządzeniach jest 3-osiowy akcelerometr i dowolny TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR Zaimplementowane czujniki złożone (TYPE_STEP_COUNTER):

• [C-4-1] Suma ich wartości zużycie energii MUSI zawsze wynosić mniej niż 4 mW.
• Gdy urządzenie znajduje się w trybie dynamicznym lub statycznego warunku.

Jeśli urządzenia są wyposażone w 3-osiowy akcelerometr i 3-osiowy żyroskop, one:

• [C-5-1] MUSI wdrożyć zasady TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION i komponentów.
• [C-SR-7] Zdecydowanie ZALECANE jest wdrożenie Czujnik kompozytowy TYPE_GAME_ROTATION_VECTOR.

Jeśli w urządzeniach jest 3-osiowy akcelerometr, 3-osiowy żyroskop i czujnik magnetometru:

• [C-6-1] NALEŻY zastosować 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 raportować zdarzenia z częstotliwością co najmniej 10 Hz i 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 Android. jak podano w Interfejsy API dla Androida.
• [C-1-4] MUSI mierzyć od -900 μT do +900 μT w każdym przed nasyceniem.
• [C-1-5] MUSI mieć wartość przesunięcia twardego żelaza mniejszą niż 700 μT i POWINNA poniżej 200 μT, umieszczając magnetometr w odległości dynamicznych (wywołanych 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 zachować parametry kompensacji między restartami urządzeń.
• [C-1-8] MUSI zastosować kompensację miękkiego żelaza – kalibrację można zarówno podczas użytkowania, jak i produkcji urządzenia.
• [C-1-9] MUSI mieć odchylenie standardowe obliczone na podstawie jednej osi próbki zebrane w okresie co najmniej 3 sekund z najszybszym próbkowaniem współczynnik klikalności, nie większy niż 1,5 μT; Odchylenie standardowe musi mieć wartość nie większą niż 0,5 μT.
• [C-1-10] MUSI zaimplementować 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.
• POWINNO zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie wsadowym 10 Hz.

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 poinformują o możliwości do aplikacji za pomocą flagi funkcji android.hardware.location.gps, spowoduje to:

• [C-1-1] MUSI obsługiwać dane wyjściowe z lokalizacją z częstotliwością co najmniej 1 Hz, gdy wysłano prośbę za pośrednictwem: LocationManager#requestLocationUpdate.
• [C-1-2] MUSI określić lokalizację na otwartym niebie (silne sygnały, pomijane ścieżki wielościeżkowe, HDOP < 2) w ciągu 10 sekund (szybkie) czas do pierwszej naprawy), przy połączeniu z szybkością co najmniej 0,5 Mb/s. i połączenia z internetem. Ten wymóg jest zwykle spełniany przez zastosowanie forma metody wspomaganego lub przewidywanego GPS/GNSS. do zminimalizowania czasu blokady GPS/GNSS (dane pomocy obejmują czas odniesienia, Lokalizacja odniesienia i satelitarny efemeris/zegar).
  • [C-1-6] Po wyliczeniu lokalizacji implementacje MUSZĄ określić swoją lokalizację, na otwartym niebie, w po 5 sekundach, jeśli żądania lokalizacji są ponownie uruchamiane, maksymalnie do godziny po tym czasie. początkowe obliczenie lokalizacji, nawet jeśli kolejne żądanie wykonane bez połączenia do transmisji danych lub po wyłączeniu i włączeniu zasilania.

• Na otwartym niebie po określeniu lokalizacji, na siedzącym lub poruszając się z przyspieszeniem poniżej 1 metra na sekundę do kwadratu:

  • [C-1-3] MUSI określić lokalizację w promieniu 20 metrów i prędkość z dokładnością do 0,5 metra na sekundę, przez co najmniej 95% czasu.
  • [C-1-4] MUSI jednocześnie śledzić i raportować przez GnssStatus.Callback co najmniej 8 satelitów z 1 konstelacji.
  • POWINNA być w stanie jednocześnie śledzić co najmniej 24 satelity, wiele konstelacji (np. GPS + przynajmniej jeden z Glonass, Beidou, Galileusza).

• [C-SR-2] Zdecydowanie ZALECANE jest dalsze działanie normalnego systemu GPS/GNSS. dane o lokalizacji przesyłane przez interfejsy API dostawcy lokalizacji GNSS w czasie połączenia alarmowego .

• [C-SR-3] Zdecydowanie ZALECANE są raportowanie pomiarów GNSS we wszystkich śledzone konstelacje (zgodnie z raportem w komunikatach GnssStatus), z wyjątkiem przedsiębiorcy SBAS.

• [C-SR-4] Zdecydowanie ZALECANE jest raportowanie AGC oraz częstotliwość GNSS pomiar skuteczności.

• [C-SR-5] Zdecydowanie ZALECANE jest raportowanie wszystkich szacunków dokładności (w tym Orientacja, Prędkość i Orientacja pionowa) jako część każdej lokalizacji GPS/GNSS.

• [C-SR-6] Zdecydowanie ZALECANE jest zgłaszanie pomiarów GNSS, gdy tylko nawet jeśli lokalizacja określona na podstawie GPS/GNSS nie została jeszcze zostało zgłoszone.

• [C-SR-7] Zdecydowanie ZALECANE są zgłaszanie pseudozakresów GNSS i współczynniki pseudozakresów, które w warunkach na niebie po określeniu lokalizacji nieruchome lub poruszające się z szybkością mniejszą niż 0,2 metra na sekundę do kwadratu przyspieszenie, wystarczają do obliczenia pozycji z odległości do 20 metrów, a prędkość z dokładnością do 0,2 metra na sekundę, przez co najmniej 95% czasu.

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 żyroskop:

• [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• 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. 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, czyli rad^2 / s). Warianty mogą się różnić w zależności od ale MUSI być ograniczana przez tę wartość. Innymi słowy, zmierz wariancję żyroskopu przy częstotliwości próbkowania 1 Hz niż 1e-7 rad^2/s^2.
• [C-SR-2] ZALECANY jest błąd kalibracji mniejszy niż 0,01 rad/s gdy urządzenie pozostaje w temperaturze pokojowej.
• [C-SR-3] 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:

• [C-2-1] MUSI zamocować czujnik TYPE_GYROSCOPE.
• [C-SR-4] Zdecydowanie zalecamy wdrożenie TYPE_GYROSCOPE_UNCALIBRATED .

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

• [C-3-1] MUSI zaimplementować i zgłosić czujnik TYPE_GYROSCOPE_LIMITED_AXES.
• [C-SR-5] Są STRONGLY_ZALECANE do wdrożenia i raportowania Czujnik TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Jeśli urządzenia są wyposażone w 3-osiowy żyroskop, i czujnik magnetometru:

• [C-4-1] NALEŻY zastosować czujnik kompozytowy TYPE_ROTATION_VECTOR.

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

• [C-5-1] MUSI wdrożyć zasady TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION i komponentów.
• [C-SR-6] Zdecydowanie ZALECANE jest wdrożenie TYPE_GAME_ROTATION_VECTOR czujnika kompozytu.

7.3.5 barometr;

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest dodanie barometru (ciśnienia powietrza otoczenia) ).

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 pomiarów ciśnienia w zakres od 300 hPa do 1100 hPa.
• Całkowita dokładność 1hPa.
• POWINNA mieć względną dokładność 0,12 hPa w zakresie 20 hPa. (odpowiednik dokładności ok. 1 m na ok. 200 m zmiany na poziomie morza).

7.3.6 Thermometer

Jeśli urządzenia obejmują termometr otoczenia (czujnik temperatury): one:

• [C-1-1] MUSI definiować SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury otoczenia, a czujnik MUSI mierzyć temperaturę otoczenia (w pomieszczeniu/kabinie pojazdu), od której użytkownik wchodzi w interakcję z urządzenia w stopniach Celsjusza.

Jeśli urządzenia są wyposażone w czujnik termometru, który mierzy temperatura inna niż temperatura otoczenia (np. temperatura procesora) powoduje, że:

• [C-2-1] NIE MOŻE definiować SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury.

Jeśli urządzenia są wyposażone w czujnik do monitorowania temperatury skóry, to:

• [C-SR-1] Zdecydowanie ZALECANE są działania PowerManager.getThermalHeadroom API.

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 urządzenia są wyposażone w czujnik zbliżeniowy, który zgłasza tylko binarny „blisko” lub „dalej” Google:

• [C-1-1] MUSI mierzyć bliskość obiektu w tym samym kierunku co ekranu. Oznacza to, że czujnik zbliżeniowy MUSI być zorientowany, by wykrywać obiekty. blisko ekranu, ponieważ czujniki tego typu wykorzystują przede wszystkim wykrywanie telefonu używanego przez użytkownika. Jeśli implementacje urządzeń obejmują parametr czujnik zbliżeniowy w 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 podać 0 cm jako odczyt, a 5 cm jako czytanie długofalowe.
• [C-1-4] MUSI zgłosić maksymalny zakres i rozdzielczość 5.

7.3.9. Czujniki wysokiej jakości

Jeśli implementacje urządzeń obejmują zbiór czujników o wyższej jakości, zgodnie z definicją w tej sekcji i udostępnić je aplikacjom innych firm:

• [C-1-1] MUSI określić umiejętność w Flaga funkcji android.hardware.sensor.hifi_sensors.

Jeśli implementacje urządzeń zadeklarują android.hardware.sensor.hifi_sensors, one:

• [C-2-1] MUSI mieć czujnik TYPE_ACCELEROMETER, który:

  • MUSI mieć zakres pomiaru od -8 g do +8 g i jest Zdecydowanie ZALECAMY zakres pomiaru na poziomie co najmniej -16 g i +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ługuje SensorDirectChannel RATE_VERY_FAST.
  • Poziom szumu pomiarowego MUSZĄ być większy niż 400 μg/√Hz.
  • MUSI zastosować czujnik nie wybudzany z buforowaniem z możliwością co najmniej 3000 zdarzeń z czujnika.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 3 mW.
  • [C-SR-1] Zdecydowanie ZALECANE jest ustawienie przepustowości pomiaru na poziomie 3 dB na poziomie co najmniej 80% częstotliwości Nyquist i widmo białego szumu połączenia internetowego.
  • W przypadku przyspieszenia testowane losowe spacery powinny mieć wartość mniejszą niż 30 μg √Hz temperatury w pomieszczeniu.
  • MUSISZ mieć zmianę odchylenia w porównaniu z temperaturą na poziomie ≤ +/- 1 mg/°C.
  • Optymalna nieliniowość w zakresie ≤ 0,5% oraz zmiana czułości względem temperatury na poziomie ≤ 0,03%/C°.
  • Czułość krzyżowa powinna wynosić < 2,5 % i zmienność czułość obrazu na osi < 0,2% w zakresie temperatur działania urządzenia.

• [C-2-2] MUSI mieć TYPE_ACCELEROMETER_UNCALIBRATED o takim samym identyfikatorze wymagania dotyczące jakości na poziomie 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ługuje SensorDirectChannel RATE_VERY_FAST.
  • Poziom szumu pomiarowego MUSZĄ być większy niż 0,014°/s/√Hz.
  • [C-SR-2] Zdecydowanie ZALECANE jest ustawienie przepustowości pomiaru na poziomie 3 dB na poziomie co najmniej 80% częstotliwości Nyquist i widmo białego szumu połączenia internetowego.
  • Częstotliwość losowego spaceru POWINNA być testowana w pomieszczeniu poniżej 0,001°/s √ Hz temperatury ciała.
  • 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 zakres temperatur 10 ~ 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 % i czułość między osią odmiana < 0,3% w zakresie temperatur działania urządzenia.

• [C-2-4] MUSI mieć TYPE_GYROSCOPE_UNCALIBRATED tej samej jakości wymagania zgodne ze standardem 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 tej samej jakości wymagania określone w TYPE_GEOMAGNETIC_FIELD, a dodatkowo:

  • MUSI zastosować czujnik nie wybudzany z buforowaniem z możliwością co najmniej 600 zdarzeń z czujnika.
  • [C-SR-3] Zdecydowanie ZALECANE jest użycie widma białego szumu od 1 Hz do co najmniej 10 Hz, jeśli 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 nie wybudzany z buforowaniem z możliwością co najmniej 300 zdarzeń z czujnika.
  • 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 wynosić nie mniej niż 0,5 mW, gdy urządzenie jest Statyczny i 1,5 mW, gdy urządzenie jest w ruchu.

• [C-2-10] MUSI mieć czujnik TYPE_STEP_DETECTOR, który:

  • MUSI zastosować czujnik nie wybudzany z buforowaniem z możliwością co najmniej 100 zdarzeń z czujnika.
  • Zużycie energii musi wynosić nie mniej niż 0,5 mW, gdy urządzenie jest Statyczny i 1,5 mW, gdy urządzenie 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 wynosić nie mniej niż 0,5 mW, gdy urządzenie jest Statyczny i 1,5 mW, gdy urządzenie jest w ruchu.

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

  • Zużycie energii musi wynosić nie mniej niż 0,5 mW, gdy urządzenie jest Statyczny i 1,5 mW, gdy urządzenie jest w ruchu.

• [C-2-13] Sygnatura czasowa tego samego zdarzenia fizycznego zgłoszonego przez Akcelerometr, żyroskop i magnetometr MUSZĄ być maksymalnie 2, 5 milisekundy do siebie nawzajem. Sygnatura czasowa tego samego zdarzenia fizycznego zgłoszonego przez odczyt akcelerometru i żyroskopu POWINIEN być oddalony w odległości maksymalnie 0,25 milisekundy. inne.

• [C-2-14] MUSI mieć w tym samym czasie sygnatury czasowe zdarzeń z czujnika żyroskopu jako podsystemu kamery i w ciągu 1 milisekundy od błędu.

• [C-2-15] MUSI dostarczyć próbki do aplikacji w ciągu 5 milisekund od czas, gdy dane są dostępne przez dowolny z powyższych czujników fizycznych do aplikacji.

• [C-2-16] NIE MOŻE zużywać energii większej niż 0,5 mW gdy urządzenie jest statyczne i 2,0 mW, gdy urządzenie jest w ruchu gdy włączona jest dowolna kombinacja następujących 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, a jeśli jest zainstalowany, MUSI mieć bufor dla co najmniej 100 zdarzeń z czujnika.

Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycie energii przez procesor aplikacji. Obejmuje on rysowany przez cały łańcuch czujników – czujnik, dowolny obwód pomocniczy, dowolny dedykowanego systemu przetwarzania czujnika itp.

Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników:

• [C-3-1] MUSI poprawnie zadeklarować obsługę typów kanałów bezpośrednich i bezpośrednich poziomem częstotliwości raportowania za pomocą raportu isDirectChannelTypeSupported i getHighestDirectReportRateLevel API.
• [C-3-2] MUSI obsługiwać co najmniej 1 z 2 typów kanałów bezpośrednich z czujnikiem dla wszystkich czujników, które deklarują obsługę kanału bezpośredniego.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• POWINNA obsługiwać raportowanie zdarzeń przez kanał bezpośredni czujnika dla głównego czujnik (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 na temat mierzenia zabezpieczeń odblokowywania biometrycznego: Dokumentacja zabezpieczeń biometrycznych

Jeśli implementacje urządzeń obejmują bezpieczny ekran blokady:

• POWINNA zawierać czujnik biometryczny

Czujniki biometryczne mogą należeć do klasy 3 (wcześniej Silne), Klasa 2 (wcześniej Słaba) lub Klasa 1 (wcześniej Wygodna) na podstawie wskaźników akceptacji za podszywanie się pod inne osoby oraz bezpieczeństwa biometrycznego potoku. Ta klasyfikacja określa możliwości czujnik biometryczny musi łączyć się z platformą oraz z zewnętrznym aplikacji. Czujniki muszą spełniać dodatkowe wymagania opisane poniżej, jeśli chce zostać sklasyfikowany jako klasa 1, klasa 2 lub klasa 3. Zarówno biometria klasy 2, jak i klasy 3 zyskują dodatkowe możliwości: podane niżej.

Jeśli implementacje urządzeń udostępniają czujnik biometryczny innym firmom aplikacji za pomocą android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, i android.provider.Settings.ACTION_BIOMETRIC_ENROLL, one:

• [C-4-1] MUSI spełniać wymagania dotyczące danych biometrycznych klasy 3 lub klasy 2 zgodnie z definicją podaną w tym dokumencie.
• [C-4-2] MUSI rozpoznawać i uwzględniać każdą nazwę parametru zdefiniowaną jako stałą na stronie Authenticators, i ich kombinacji. I na odwrót NIE MOŻE spełniać ani rozpoznawać stałych liczb całkowitych przekazywanych do funkcji canAuthenticate(int), i setAllowedAuthenticators(int) metod innych niż te opisane jako stałe publiczne Uwierzytelnianie oraz ich kombinacji.
• [C-4-3] MUSI obsługiwać funkcję ACTION_BIOMETRIC_ENROLL na urządzeniach z biometrią klasy 3 lub klasy 2. To działanie MUSI przedstawiać tylko punkty wejścia do rejestracji dla klasy 3. lub danych biometrycznych klasy 2.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli implementacje urządzeń obsługują pasywną biometrię:

• [C-5-1] Domyślnie MUSI wymagać dodatkowego potwierdzenia (np. naciśnięcie przycisku).
• [C-SR-1] Zdecydowanie ZALECANE jest wprowadzenie ustawienia umożliwiającego użytkownikom zastępują preferencje aplikacji i zawsze wymagają towarzyszącego kroku potwierdzenia.
• [C-SR-2] Zdecydowanie ZALECANE jest zabezpieczenie działania związanego z potwierdzeniem. w taki sposób, że nie będzie można podszywać się pod niego przez system operacyjny lub jądro. Na przykład oznacza to, że potwierdzenie za pomocą fizycznego przycisku jest kierowana tylko przez wejście/wyjście ogólnego przeznaczenia (GPIO) bezpiecznego elementu (SE), który nie może być wywoływany w żaden inny sposób niż naciśnięcie fizycznego przycisku.
• [C-5-2] MUSI dodatkowo zaimplementować pośrednie uwierzytelnianie (bez kroku potwierdzenia) odpowiadający setConfirmationRequired(boolean), których aplikacje mogą używać do logowania się.

Jeśli urządzenia są wyposażone w kilka czujników biometrycznych:

• [C-7-1] MUSI być wyłączony, gdy biometria jest zablokowana (tj. dane biometryczne są wyłączone do momentu odblokowania urządzenia za pomocą uwierzytelniania podstawowego) lub tymczasowej blokady (np. dane biometryczne są tymczasowo wyłączone, dopóki użytkownik nie poczeka przez jakiś czas (interwał) z powodu zbyt wielu nieudanych prób, zablokuj też wszystkie pozostałe dane biometryczne z niższej klasy. W przypadku blokady ograniczonej czasowo czas do ponowienia w przypadku weryfikacji biometrycznej MUSI być maksymalnym czasem ponowienia wszystkich danych biometrycznych z blokadą z ograniczeniem czasowym.

• [C-SR-12] Są Zdecydowanie ZALECANE, gdy dane biometryczne są zablokowane (np. dane biometryczne są wyłączone, dopóki użytkownik nie odblokuje się za pomocą podstawowego uwierzytelniania) lub blokada ograniczona czasowo (tzn. biometria jest tymczasowo wyłączona do (oczekuje określony przedział czasu) z powodu zbyt wielu nieudanych prób, aby zablokować wszystkie pozostałe funkcje biometryczne z tej samej klasy. W przypadku blokada ograniczona czasowo, czas do ponowienia w przypadku weryfikacji biometrycznej BARDZO ZALECANY jest maksymalnym czasem do ponowienia w przypadku wszystkich danych biometrycznych w określonym czasie. blokady.

• [C-7-2] MUSI wymagać od użytkownika skonfigurowania zalecanego podstawowego uwierzytelniania (np. kod PIN, wzór, hasło) do zresetowania licznika blokady uwierzytelniania biometrycznego dostęp do informacji. Urządzenie biometryczne klasy 3 MOŻE zresetuje blokadę dla zablokowanej metody biometrycznej tej samej lub niższej klasy. Klasa 2 lub Urządzenia biometryczne klasy 1 NIE MOGĄ mieć możliwości dokończenia blokady resetowania w przypadku dowolnej biometrii.

• [C-SR-3] Zdecydowanie ZALECANE jest wymaganie potwierdzenia tylko 1 danych biometrycznych na uwierzytelnianie (np. gdy dostępny jest zarówno odcisk palca, jak i czujniki twarzy) na urządzeniu, onAuthenticationSucceeded należy wysłać po potwierdzeniu dowolnego z nich).

Aby implementacje urządzeń umożliwiały dostęp do kluczy magazynu kluczy aplikacji innych firm, mogą one:

• [C-6-1] MUSI spełniać wymagania dotyczące klasy 3 zdefiniowane w sekcji poniżej.
• [C-6-2] Podczas uwierzytelniania MUSI podawać tylko dane biometryczne klasy 3 wymaga parametru BIOMETRIC_STRONG, uwierzytelnianie jest wywoływane za pomocą obiektu CryptoObject.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 1. (dawniej Wygoda), to:

• [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. lub hasła, a także jednoznacznie wyliczać ryzyko ich włączenia, jeśli Współczynnik akceptacji imitacji jest wyższy niż 7%, Protokoły testów biometrycznych Androida.
• [C-1-9] MUSI wymagać od użytkownika skonfigurowania zalecanego podstawowego uwierzytelniania (np. kod PIN, wzór, hasło) po najwyżej 20 fałszywych próbach i nie krótszy niż 90 sekund dla weryfikacji biometrycznej, gdzie Fałszywy test to wynik o dostatecznej jakości zapisu (BIOMETRIC_ACQUIRED_GOOD), który nie jest zgodny z zarejestrowanym danymi biometrycznym.
• [C-SR-4] Zdecydowanie ZALECANE jest ograniczenie łącznej liczby fałszywych prób. do weryfikacji biometrycznej określonej w normie [C-1-9], jeśli podszywanie się pod inne osoby współczynnik akceptacji przekracza 7% – jak wynika z danych biometrycznych Androida. Protokoły testowe.
• [C-1-3] MUSI mieć limit prób weryfikacji biometrycznej, gdzie Fałszywy test to wynik o dostatecznej jakości zapisu (BIOMETRIC_ACQUIRED_GOOD) niepasujące do zarejestrowanych danych biometrycznych.
• [C-SR-5] Zdecydowanie ZALECANE są próby ograniczenia liczby żądań przez co najmniej 30 sekund po 5 fałszywych próbach weryfikacji biometrycznej maksymalna liczba fałszywych prób na [C-1-9], gdzie fałszywa próba to jedna z o odpowiedniej jakości przechwytywania (BIOMETRIC_ACQUIRED_GOOD), która nie odpowiada zarejestrowanej biometrii.
• [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 powrocie do poprzedniego uwierzytelnienia. które zostały po raz pierwszy uruchomione zgodnie z opisem w sekcji [C-0-2] sekcji 9.11.
• [C-1-11] MUSI mieć współczynnik akceptacji fałszywych informacji niż 30%. z (1) współczynnikiem akceptacji podszywania się pod inne osoby w prezentacji poziomu A gatunki instrumentów atakowych (PAI) nie większe niż 30%; oraz (2) imitacja współczynnik akceptacji oszustów na poziomie B PAI nie wyższy niż 40%, zmierzoną za pomocą protokołów testów biometrycznych Androida.
• [C-1-4] MUSI uniemożliwiać dodawanie nowych danych biometrycznych bez uprzedniego ustanowienia łańcuch zaufania – użytkownik może potwierdzić istniejące urządzenie lub dodać nowe. dane logowania (kod PIN/wzór/hasło) zabezpieczone przez TEE; Android Open Wdrożenie projektu źródłowego zapewnia mechanizm działania tak.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-1-6] MUSI uwzględniać flagę poszczególnych danych biometrycznych (tzn. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT DevicePolicymanager.KEYGUARD_DISABLE_FACE, lub DevicePolicymanager.KEYGUARD_DISABLE_IRIS).

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-SR-7] Zdecydowanie ZALECANE jest użycie logiki w podanej strukturze. przez Android Open Source Project, aby egzekwować ograniczenia określone w [C-1-7] i [C-1-8] w przypadku nowych urządzeń.
• [C-SR-8] Zdecydowanie ZALECANE jest zwiększenie odsetka fałszywych odrzuceń poniżej 10%, co jest mierzone na urządzeniu.
• [C-SR-9] Zdecydowanie ZALECANE jest opóźnienie poniżej 1 sekundy, mierzone od momentu wykrycia danych biometrycznych do odblokowania ekranu zarejestrowanej biometrii.
• [C-1-12] MUSI mieć współczynnik akceptacji fałszywych informacji niż 40% gatunków przyrządów atakujących (PAI) – zgodnie z pomiarami Protokoły testów biometrycznych Androida.
• [C-SR-13] Zdecydowanie ZALECANE jest użycie podszywania się pod inne osoby współczynnik akceptacji oszustów nie wyższy niż 30% gatunków przyrządów atakujących (PAI) – zgodnie z pomiarami Protokoły testów biometrycznych Androida.
• [C-SR-8] Zdecydowanie ZALECANE jest zwiększenie odsetka fałszywych odrzuceń poniżej 10%, co jest mierzone na urządzeniu.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-SR-14] Zdecydowanie ZALECANE jest podanie klasy biometrycznej czujnika biometrycznego i powiązane z nim ryzyko jego włączenia.

• [C-SR-17] Zdecydowanie ZALECANE jest wdrożenie nowych interfejsów AIDL. (na przykład IFace.aidl i IFingerprint.aidl).

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 2. (dawniej Słabe), to:

• [C-2-1] MUSI spełniać wszystkie wymagania dotyczące klasy 1 powyżej.
• [C-2-2] MUSI mieć współczynnik akceptacji imitacji nie wyższy niż 20%, z (1) współczynnikiem akceptacji fałszywych informacji dla Gatunek instrumentu atakowego poziomu A (PAI) nie więcej niż 20%, oraz (2) współczynnik akceptacji i oszustw w przypadku gatunku PAI poziomu B, które nie są zgodne z zasadami. powyżej 30%, co mierze Protokoły testów biometrycznych Androida.
• [C-SR-15] Zdecydowanie ZALECANE jest podszywanie się pod inne osoby wskaźnik akceptacji nie wyższy niż 20% gatunków przyrządów atakujących (PAI) – zgodnie z pomiarami Protokoły testów biometrycznych Androida.
• [C-2-3] MUSI wykonać dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza Androidem użytkownika lub przestrzeni jądra systemu, takiego jak Trusted Execution Environment (TEE), na układzie z bezpiecznym kanałem i izolowanym środowiskiem wykonawczym lub na chronionej maszynie wirtualnej spełniającej wymagania artykułu 9.17.
• [C-2-4] MUSI mieć zaszyfrowane i kryptograficzne dane umożliwiające identyfikację uwierzytelnionych w taki sposób, że nie można ich pozyskać, odczytać ani zmienić poza izolowane środowisko wykonawcze lub układ z bezpiecznym kanałem izolowane środowisko wykonawcze, zgodnie z opisem w implementacji wytycznych na stronie projektu Android Open Source lub w Protected Virtual Machine pod kontrolą hipernadzorcy spełniającego wymagania artykułu 9.17.
• [C-2-5] Uwierzytelnianie biometryczne z użyciem aparatu i uwierzytelnianie biometryczne lub rejestracja ma miejsce:
  • MUSI obsługiwać aparat w trybie, który uniemożliwia być odczytywana lub zmieniana poza izolowanym środowiskiem wykonawczym lub elementem z bezpiecznym kanałem i izolowanym środowiskiem wykonawczym lub środowiskiem chronionym Maszyna wirtualna kontrolowana przez hipernadzorcę, która spełnia wymagania w sekcji 9.17.
  • W przypadku rozwiązań RGB z jedną kamerą ramki aparatu mogą być czytelna poza izolowanym środowiskiem wykonawczym na potrzeby operacji np. podglądu rejestracji, ale NIE WOLNO zmieniać.
• [C-2-6] NIE MOŻE umożliwiać aplikacjom innych firm odróżniania rejestracje biometryczne.
• [C-2-7] NIE MOŻE umożliwiać niezaszyfrowanego dostępu do danych biometrycznych możliwych do zidentyfikowania ani wszelkich danych uzyskanych z niej (takich jak wektory dystrybucyjne) do Podmiotu przetwarzającego aplikację poza kontekstem TEE lub chronionej maszyny wirtualnej kontrolowanej przez hipernadzorcę spełniającego wymagania artykułu 9.17. Uaktualnienie urządzeń z Androidem w wersji 9 lub starszej nie jest wyjątkiem od kierownictwa C-2-7.

• [C-2-8] MUSI mieć bezpieczny potok przetwarzania, tak aby w wyniku naruszenia zabezpieczeń systemu lub jądra nie można zezwolić na bezpośrednie wstrzykiwanie danych nie uwierzytelniają się jako użytkownik. Uwaga: jeśli implementacje na urządzeniach zostały już wdrożone na urządzeniach z Androidem w wersji 9 lub wcześniej i nie może spełnić wymagań C-2-8 za pomocą oprogramowania systemowego aktualizacja, MOŻE być zwolniona z obowiązku spełnienia tego wymogu.

• [C-SR-10] Zdecydowanie ZALECANE jest włączenie wykrywania żywotności w przypadku wszystkich modalności biometrycznej i wykrywania uwagi na potrzeby biometrii twarzy.

• [C-2-9] MUSI udostępnić czujnik biometryczny innej firmy aplikacji.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 3. (dawniej Silne):

• [C-3-1] MUSI spełniać wszystkie wymagania klasy 2 powyżej oprócz [C-1-7] i [C-1-8].
• [C-3-2] MUSI mieć implementację magazynów kluczy wspieranych sprzętowo.
• [C-3-3] MUSI mieć współczynnik akceptacji imitacji nie wyższy niż 7%. z (1) współczynnikiem akceptacji fałszywych informacji dla gatunków instrumentów atakowych poziomu A (PAI) – nie więcej niż 7% gatunków; (2) współczynnik akceptacji imitacji przez oszustów lub innych gatunków pochodzących z PAI na poziomie B nie jest wyższy niż 20%, co mierzy Protokoły testów biometrycznych Androida.
• [C-3-4] MUSI wymagać od użytkownika pytania o zalecaną trasę podstawową uwierzytelnianie (np. kod PIN, wzór, hasło) raz na 72 godziny .
• [C-3-5] MUSI ponownie wygenerować identyfikator modułu uwierzytelniającego wszystkich biometrii klasy 3 obsługiwanych przez urządzenie, jeśli któraś z nich jest została zarejestrowana ponownie.
• [C-3-6] Musisz włączyć biometryczne klucze magazynu kluczy dla zewnętrznych aplikacji.

• [C-SR-16] Zdecydowanie ZALECANE jest podszywanie się pod inne osoby wskaźnik akceptacji nie wyższy niż 7% gatunków instrumentów atakujących, zgodnie z pomiarami Protokoły testów biometrycznych Androida. Jeśli urządzenia mają czytnik linii papilarnych pod wyświetlaczem: one:

• [C-SR-11] Zdecydowanie ZALECANE jest niedostosowanie do dotykowego obszaru UDFPS. zakłócające nawigację przy użyciu 3 przycisków( co niektórzy użytkownicy mogą wymagać związane z ułatwieniami dostępu).

7.3.11. 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 wdrożyć i zgłosić stronę TYPE_POSE_6DOF .
• [C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.

7.3.12. 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 dwa odczyty od 0 do 360 stopni (włącznie, tzn. w tym od 0 do 360 stopni).
• [C-1-3] MUSI zwrócić wybudzenie czujnik dla: getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Jeśli implementacje urządzeń obsługują standard 802.1.15.4 i udostępniają aplikacji innej firmy:

• [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.uwb.
• [C-1-3] MUSI obsługiwać wszystkie następujące zestawy konfiguracji (wstępnie zdefiniowane kombinacji parametrów FIRA UCI) zdefiniowane w implementacji AOSP.
  • CONFIG_ID_1: zdefiniowany przez FiRa zakres typu unicast STATIC STS DS-TWR, tryb odroczenia z odstępem 240 ms.
  • CONFIG_ID_2: zdefiniowany przez FiR zakres STATIC STS DS-TWR w zakresie jeden do wielu, tryb odroczenia z zakresu 200 ms. Typowe zastosowanie: smartfon współdziała z wieloma urządzeniami.
  • CONFIG_ID_3: taka sama jak CONFIG_ID_1, oprócz kąta przyjazdu (AoA) nie są uwzględniane w raportach.
  • CONFIG_ID_4: taki sam jak w przypadku CONFIG_ID_1, z wyjątkiem trybu zabezpieczeń P-STS: .
  • CONFIG_ID_5: taki sam jak w przypadku CONFIG_ID_2, z wyjątkiem trybu zabezpieczeń P-STS: .
  • CONFIG_ID_6: taki sam jak w przypadku CONFIG_ID_3, z wyjątkiem trybu zabezpieczeń P-STS: .
  • CONFIG_ID_7: taki sam jak CONFIG_ID_2, oprócz indywidualnego kontrolera P-STS włączony jest tryb klawisza.
• [C-1-4] MUSI udostępniać informacje o produkcie, aby użytkownik mógł przełączyć UWB stanu włączenia/wyłączenia radia.
• [C-1-5] MUSI wymuszać, aby aplikacje korzystające z radia UWB zawierały UWB_RANGING (w grupie uprawnień NEARBY_DEVICES).

zaliczenie odpowiednich testów zgodności i certyfikatów określonych w standardzie. organizacji, w tym FIRA, CC oraz CSA zapewnia prawidłowe działanie standardu 802.1.15.4.

7.4 Połączenie transmisji danych

7.4.1 Telefonia

„Połączenia telefoniczne” jako stosowane w interfejsach API Androida. W tym dokumencie sprzętu związanego z nawiązywaniem połączeń głosowych i wysyłaniem SMS-ów; Nawiązywanie komórkowej transmisji danych przez sieć komórkową (np. GSM, CDMA, LTE, NR) GSM lub CDMA Urządzenie obsługujące „telefonię” mogą zdecydować się na oferowanie części lub całości połączeń, wiadomości i danych.

• Android MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Ten oznacza, ż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 flag funkcji podrzędnych.
• [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 uwzględniają zastrzeżony mechanizm udostępniania funkcji eSIM firmom zewnętrznym programistów:

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

Jeśli implementacje urządzeń nie ustawią stanu usługi systemowej ro.telephony.iwlan\_operation\_mode na „legacy”, oznacza to, że:

• [C-4-1] NIE MOŻE zgłaszać treści „NETWORK_TYPE_IWLAN” za pomocą NetworkRegistrationInfo#getAccessNetworkTechnology() gdy NetworkRegistrationInfo#getTransportType() jest raportowany jako „TRANSPORT_TYPE_WWAN” dla tej samej instancji NetworkRegistrationInfo.

Jeśli implementacje urządzeń obsługują pojedynczy podsystem multimedialny IP (IMS) rejestracji w usługach telefonii multimedialnej (MMTEL), funkcje protokołu Rich Communication Services (RCS) i muszą być zgodne z wymaganiami, jakie muszą spełniać operator sieci komórkowej, Rejestracja w IMS w przypadku całego ruchu sygnalizującego ruch IMS:

• [C-5-1] MUSI zadeklarować parametr android.hardware.telephony.ims flagę funkcji i zapewnić pełną implementację Interfejs ImsService API dla MMTEL i RCS User Capability Exchange API.
• [C-5-2] MUSI zadeklarować android.hardware.telephony.ims.singlereg flagę funkcji i zapewnić pełną implementację interfejsu SipTransport API. interfejs API GbaService, dedykowanych użytkowników za pomocą HAL IRadio 1.6 oraz udostępnianie przy użyciu serwera automatycznej konfiguracji (ACS) lub innej zastrzeżonej obsługi administracyjnej za pomocą interfejsu IMS Configuration API.

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

• [C-6-1] SmsManager#sendTextMessage i SmsManager#sendMultipartTextMessage MUSI prowadzić do odpowiednich wywołań CarrierMessagingService na potrzeby obsługi wiadomości tekstowych. SmsManager#sendMultimediaMessage oraz SmsManager#downloadMultimediaMessage MUSI prowadzić do odpowiednich wywołań CarrierMessagingService udostępniania funkcji wiadomości multimedialnych.
• [C-6-2] Wniosek wskazany przez android.provider.Telephony.Sms#getDefaultSmsPackage MUSI używać SmsManager Interfejsy API do wysyłania i odbierania SMS-ów i MMS-ów. Dokumentacja AOSP wdrożenia w pakietach/aplikacjach/wiadomościach spełniają to wymaganie.
• [C-6-3] Aplikacja, która odpowiada na Intent#ACTION_DIAL MUSI obsługiwać wpisywanie dowolnych kodów telefonu w formacie *#*#CODE#*#* i aktywuje odpowiedni TelephonyManager#ACTION_SECRET_CODE transmisję.
• [C-6-4] Aplikacja odpowiadająca na Intent#ACTION_DIAL MUSI używać VoicemailContract.Voicemails#TRANSCRIPTION wyświetlanie użytkownikom transkrypcji wizualnej poczty głosowej, jeśli obsługuje ona zapisy tekstowe poczty głosowej.
• [C-6-5] MUSI zawierać wszystkie elementy SubscriptionInfo wraz z ich odpowiednikiem identyfikatory UUID grup jako pojedynczą subskrypcję we wszystkich widocznych dla użytkowników aprobatach, które wyświetlają kontrolować informacje na karcie SIM. Przykłady takich afordancji to m.in. ustawienia które pasują do siebie Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS lub EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
• [C-6-6] NIE MOŻE wyświetlać informacji o subskrypcjach ani umożliwiać kontroli nad nimi za pomocą niepusty identyfikator UUID grupy i oportunistycznym widoczne dla użytkownika, umożliwiać konfigurowanie i kontrolowanie ustawień karty SIM.

Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.telephony i wyświetl systemowy pasek stanu, a potem:

• [C-7-1] MUSI wybrać reprezentatywną aktywną subskrypcję dla danego identyfikator UUID grupy do wyświetlania użytkownikowi w dowolnej wersji, która zapewnia stan karty SIM i informacjami o nich. Przykładami takich afordancji jest pasek stanu komórkowy ikony sygnału lub kafelka szybkich ustawień.
• [C-SR-1] Zdecydowanie ZALECANE jest, aby reprezentatywna subskrypcja został wybrany na aktywna subskrypcja danych chyba że urządzenie ma włączony głos podczas której Zdecydowanie ZALECANE jest, aby przedstawiciel subskrypcja to subskrypcja aktywnej usługi Voice.

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

• [C-6-7] MUSI być w stanie otwierać się w tym samym czasie liczba kanałów logicznych (łącznie 20) dla każdego interfejsu UICC według wytycznych ETSI TS 102 221.
• [C-6-8] NIE MOŻE wykonywać żadnych z poniższych działań w przypadku aktywnych aplikacji operatora (zgodnie z wytycznymi podanymi przez: TelephonyManager#getCarrierServicePackageName) automatycznie lub bez wyraźnego potwierdzenia użytkownika:
  • Anuluj lub ogranicz dostęp do sieci
  • Cofnij uprawnienia
  • Ogranicz uruchamianie aplikacji w tle lub na pierwszym planie poza dotychczasowe funkcje zarządzania energią dostępne w AOSP
  • Wyłączanie i odinstalowywanie aplikacji

Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.telephony i wszystkie aktywne, subskrypcje nieoportunistyczne które mają ten sam identyfikator UUID grupy, fizycznie usunięte z urządzenia lub oznaczone jako oportunistyczne, wówczas urządzenie:

• [C-8-1] MUSI automatycznie wyłączyć wszystkie pozostałe elementy aktywne oportunistyczne subskrypcji w tej samej grupie.

Jeśli implementacje urządzeń obejmują usługę telefonii GSM, ale nie CDMA:

• [C-9-1] NIE MOŻE deklarować sekcji PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] MUSI rzucić IllegalArgumentException przy próbie ustawienia Typy sieci 3GPP2 w preferowanych lub dozwolonych maskach bitowych typu sieci.
• [C-9-3] MUSI zwracać pusty ciąg z TelephonyManager#getMeid

Jeśli implementacje urządzeń obsługują eUICC z wieloma portami i profilami, to:

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

7.4.1.1 Zgodność z blokadami numerów

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

• [C-1-1] MUSI obsługiwać blokowanie numerów
• [C-1-2] MUSI w pełni zaimplementować BlockedNumberContract i odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu SDK.

• [C-1-3] MUSI blokować wszystkie połączenia i wiadomości z numeru telefonu w „BlockNumberProvider” bez interakcji z aplikacjami. Jedyny wyjątek gdy blokowanie numerów jest tymczasowo zniesione zgodnie z opisem w pakiecie SDK. dokumentacji.

• [C-1-4] MUSI zapisywać dane do dostawcy rejestru połączeń platformy dla zablokowanego połączenia i MUSI filtrować połączenia z BLOCKED_TYPE w domyślny widok rejestru połączeń we wstępnie zainstalowanej aplikacji telefonu.

• [C-1-5] NIE MOŻE pisać do dostawcy usług telefonicznych w przypadku zablokowanej wiadomości.

• [C-1-6] MUSI wdrożyć interfejs do zarządzania zablokowanymi numerami, który jest otwarty z intencją zwrócona przez funkcję TelecomManager.createManageBlockedNumbersIntent() .

• [C-1-7] NIE MOŻE zezwalać użytkownikom pomocniczym na wyświetlanie ani edytowanie zablokowanych numerów na danym urządzeniu, ponieważ platforma Android zakłada, że główny użytkownik ma nad usługami telefonicznymi na urządzeniu. Wszystkie UI powiązany z blokowaniem MUSI być ukryty dla użytkowników pomocniczych, a lista zablokowanych MUSI być ukryta które nadal będą szanowane.

• PO KAŻDEJ aktualizacji urządzenia NALEŻY przenieść zablokowane numery do dostawcy usług. na Androida 7.0.

• TRZEBA zapewnić użytkownikom możliwości wyświetlania zablokowanych połączeń Telefon.

7.4.1.2. Telecom API

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

• [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 poinformować użytkownika zaakceptować lub odrzucić połączenie przychodzące, gdy użytkownik jest w trakcie trwającego połączenia; utworzone przez aplikację innej firmy, która nie obsługuje funkcji blokady; określona przez CAPABILITY_SUPPORT_HOLD
• [C-1-3] MUSI zawierać aplikację, która stosuje InCallService.

• [C-SR-1] Zdecydowanie ZALECANE jest powiadomienie użytkownika o tym, że odpowiedź na połączenie przychodzące spowoduje zakończenie trwającego połączenia.

  Implementacja AOSP spełnia te wymagania dzięki powiadomieniu z ostrzeżeniem który informuje, że odebranie połączenia przychodzącego spowoduje inne połączenie do usunięcia.

• [C-SR-2] Zdecydowanie ZALECANE jest wstępne ładowanie domyślnej aplikacji telefonu, która pokazuje wpis w rejestrze połączeń i nazwę aplikacji innej firmy w rejestrze połączeń gdy aplikacja innej firmy ustawia EXTRA_LOG_SELF_MANAGED_CALLS klucz dodatków na jego kluczu od PhoneAccount do true.

• [C-SR-3] Zdecydowanie ZALECANE jest obsługa Zdarzenia KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK dla miesiąca android.telecom. Interfejsy API jak poniżej:

  • Zadzwoń pod numer Connection.onDisconnect() gdy zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia w trakcie trwającej rozmowy.
  • Zadzwoń pod numer Connection.onAnswer() gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia.
  • Zadzwoń pod numer Connection.onReject() gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia.
  • Przełącz stan wyciszenia elementu CallAudioState.

7.4.1.3 Odciążanie sieci komórkowej NAT-T

Implementacje na urządzeniach:

• POWINNO obsługiwać funkcję utrzymywania aktywności sieci komórkowej.

Jeśli implementacje urządzeń obejmują obsługę funkcji utrzymywania aktywności sieci komórkowej ujawnia tę funkcję aplikacjom innych firm,

• [C-1-1] MUSI obsługiwać interfejs SocketKeepAlive API.
• [C-1-2] MUSI obsługiwać co najmniej 1 przedział utrzymywania aktywności równoczesnej przez sieć komórkową.
• [C-1-3] MUSI obsługiwać tyle równoczesnych przedziałów czasu utrzymywania aktywności sieci komórkowej obsługiwane przez Cellular Radio HAL.
• [C-SR-1] Zdecydowanie ZALECANE są obsługa co najmniej 3 komórek utrzymywania aktywności na instancję radiową.

Jeśli implementacje urządzeń nie obsługują funkcji utrzymywania aktywności sieci komórkowej, one:

• [C-2-1] MUSI zwrócić błąd ERROR_UNSUPPORTED.

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ń obsługują standard 802.11 i udostępniają 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 zgodnie z opisem w dokumentacji pakietu SDK.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-1-5] NIE MOŻE traktować funkcji WifiManager.enableNetwork() wywołanie metody API jako wystarczające wskazanie do przełączania obecnie aktywnej metody Network, który jest domyślnie używany do obsługi ruchu w aplikacji i jest zwracany autor: ConnectivityManager Metody API, takie jak getActiveNetwork oraz registerDefaultNetworkCallback. Innymi słowy, MOGĄ one wyłączyć dostęp do internetu wyłącznie innego operatora (np.mobilnej transmisji danych), jeśli weryfikacja przebiegła pomyślnie. czy sieć Wi-Fi zapewnia dostęp do internetu.
• [C-1-6] Są Zdecydowanie ZALECANE, gdy ConnectivityManager.reportNetworkConnectivity() gdy zostanie wywołana metoda interfejsu API, ponownie oceń dostęp do internetu na urządzeniu Network, gdy ocena wskazuje, że bieżący Network nie udostępnia już dostęp do internetu i łączenie się z inną dostępną siecią (np.komórkową). ), który umożliwia dostęp do internetu.
• [C-1-7] MUSI randomizować źródłowy adres MAC i numer sekwencyjny sondy żądań (1 raz na początku każdego skanowania, a STA to – rozłączono.
• [C-1-8] MUSI używać jednego spójnego adresu MAC (NIE POWINNY być randomizowane adresy MAC) w trakcie skanowania).
• [C-1-9] MUSI powtarzać numer sekwencyjny żądania sondowania w zwykły sposób (po kolei) między żądaniami sondowania.
• [C-1-10] MUSI randomizować numer sekwencyjny żądania sondowania między ostatnią sondą żądania skanowania i pierwszego żądania sondowania w kolejnym skanowaniu.
• [C-SR-1] Zdecydowanie ZALECANE jest użycie losowego adresu MAC używanego do wszelką komunikację STA z punktem dostępu (AP) podczas wiązania powiązane treści.
  • Urządzenie MUSI używać innego randomizowanego adresu MAC dla każdego identyfikatora SSID (FQDN w przypadku Passpoint), z którym się komunikuje.
  • Urządzenie MUSI umożliwiać użytkownikowi sterowanie randomizacja według identyfikatora SSID (FQDN w przypadku Passpoint) losowe opcje i MUSI ustawiać tryb domyślny dla nowej sieci Wi-Fi; losowe konfiguracje.
• [C-SR-2] Zdecydowanie ZALECANE jest użycie losowego identyfikatora BSSID dla każdego punktu dostępu tworzyć.
  • Adres MAC MUSI być losowy i trwały zgodnie z identyfikatorem SSID używanym przez AP.
  • 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ądzenia obsługują tryb oszczędzania energii Wi-Fi zgodnie z definicją zgodnie ze standardem IEEE 802.11:

• Tryb oszczędzania energii przez Wi-Fi należy wyłączać za każdym razem, gdy aplikacja uzyska WIFI_MODE_FULL_HIGH_PERF zamek lub WIFI_MODE_FULL_LOW_LATENCY zamek przez: WifiManager.createWifiLock() iWifiManager.WifiLock.acquire() Interfejsy API i blokada są aktywne.
• [C-3-2] Średnie opóźnienie w obie strony między urządzeniem i punktu dostępu, gdy na urządzeniu jest włączona blokada Wi-Fi z opóźnieniem Tryb (WIFI_MODE_FULL_LOW_LATENCY) MUSI być mniejszy niż opóźnienia w trybie blokady Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] Zdecydowanie ZALECANE jest ograniczenie opóźnień przesyłania danych przez Wi-Fi w obie strony. za każdym razem, gdy uzyskano blokadę o krótkim czasie oczekiwania (WIFI_MODE_FULL_LOW_LATENCY) i zaczyna obowiązywać.

Jeśli urządzenia obsługują Wi-Fi i używają Wi-Fi do skanowania lokalizacji, one:

• [C-2-1] MUSI udostępniać środki użytkownika, aby włączyć/wyłączyć odczytywaną wartość przez WifiManager.isScanAlwaysAvailable API.

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 losowe wybór źródłowego adresu MAC dla wszystkich nowo utworzonych połączeń Wi-Fi Direct.

7.4.2.2. Konfiguracja bezpośredniego linku Wi-Fi

Implementacje na urządzeniach:

• POWINNA OBSŁUGIWAĆ pomoc dotyczącą Konfiguracja bezpośredniego połączenia przez tunel Wi-Fi (TDLS) zgodnie z opisem w dokumentacji pakietu Android SDK.

Jeśli implementacje urządzeń obejmują obsługę TDLS, a tag TDLS jest włączony w Wi-FiManager 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ć jest 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ą funkcji aplikacji innych firm, to:

• [C-1-1] MUSI wdrożyć interfejsy API WifiAwareManager w sposób opisany w Dokumentacja 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 w odstępach losowych udostępniać adres interfejsu zarządzania Wi-Fi Aware nie może być dłuższy niż 30 minut i gdy jest włączona usługa Wi-Fi Aware, trwa operacja określania zakresu lub aktywna jest ścieżka danych Aware (randomizacja nie jest oczekiwana, dopóki ścieżka danych jest aktywna).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware oraz Lokalizacja Wi-Fi zgodnie z opisem w sekcji 7.4.2.5 i ujawnia te funkcje aplikacjom innych firm, to:

• [C-2-1] MUSI wdrożyć interfejsy API wykrywania lokalizacji: setRangingEnabled, setMinOdległośćMm, setMaxOdległośćMm, oraz 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 wdrożyć interfejsy API WifiManager związane z Passpoint jako opisane w dokumentacji pakietu SDK.
• [C-1-3] MUSI obsługiwać standard IEEE 802.11u, w szczególności w zakresie wykrywania i wybierania sieci, np. reklam ogólnikowych. Service (GAS) i Access Network Query Protocol (ANQP).
• [C-1-4] MUSI zadeklarować flagę funkcji android.hardware.wifi.passpoint.
• [C-1-5] MUSI używać implementacji AOSP, aby wykrywać, dopasowywać i powiązywać elementy w sieciach Passpoint.
• [C-1-6] MUSI obsługiwać co najmniej ten podzbiór obsługi administracyjnej urządzeń protokoły zgodnie z definicją w Wi-Fi Alliance Passpoint R2: EAP-TTLS uwierzytelnianie i uwierzytelnianie SOAP-XML.
• [C-1-7] MUSI przetworzyć certyfikat serwera AAA w sposób opisany w Specyfikacja 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 ZALECANE jest uzupełnienie warunków korzystania z usługi .
• [C-SR-2] Zdecydowanie ZALECANE jest obsługa funkcji informacji o obiekcie.

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ą funkcji aplikacji innych firm, to:

• [C-1-1] MUSI wdrożyć interfejsy API WifiRttManager w sposób opisany w Dokumentacja 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óry jest wykonywany podczas korzystania z interfejsu Wi-Fi używanego przez RTT nie jest powiązany z punktem dostępu.
• [C-1-4] MUSI być dokładność z dokładnością do 2 metrów przy przepustowości 80 MHz przy 68 MHz percentyl (obliczany za pomocą funkcji rozkładu skumulowanego).
• [C-SR-1] Zdecydowanie ZALECANE jest raportowanie go z dokładnością do 1,5 metra. przy przepustowości 80 MHz w 68 centylu (zgodnie z obliczeniem funkcja rozkładu skumulowanego).

7.4.2.6 Odciążanie Wi-Fi

Implementacje na urządzeniach:

• POWINNO_obsługiwać odciążanie Wi-Fi.

jeśli implementacje urządzeń obsługują odciążanie Wi-Fi, i udostępniać tę funkcję aplikacjom innych firm:

• [C-1-1] MUSI obsługiwać interfejs API SocketKeepAlive.
• [C-1-2] MUSI obsługiwać co najmniej trzy równoległe przedziały utrzymywania aktywności przez Wi-Fi

Jeśli implementacje urządzeń nie obsługują odciążania Wi-Fi, one:

• [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 urządzenia obsługują Wi-Fi Easy Connect i udostępnić funkcji aplikacji innych firm:

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

7.4.2.8 Weryfikacja certyfikatu serwera Wi-Fi dla firm

Jeśli certyfikat serwera Wi-Fi nie został zweryfikowany lub serwer Wi-Fi nie został zweryfikowany nie ustawiono nazwy domeny, implementacje urządzeń:

• [C-SR-1] Zdecydowanie ZALECANE jest nieudostępnianie użytkownikowi opcji ręcznie dodaj firmową sieć Wi-Fi, w aplikacji Ustawienia.

7.4.2.9. Zaufanie przy pierwszym użyciu (TOFU)

Jeśli implementacje urządzenia obsługują funkcję „Zaufanie przy pierwszym użyciu” (TOFU), pozwalają użytkownikowi na definiowanie konfiguracji WPA/WPA2/WPA3-Enterprise; to:

• [C-4-1] MUSI umożliwiać użytkownikowi użycie usługi TOFU.

7.4.3 Bluetooth

Jeśli implementacje urządzenia obsługują profil audio Bluetooth:

• POWINNA 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ą android.hardware.vr.high_performance to:

• [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 Bluetootha Niski poziom energii:

• [C-2-1] MUSI zadeklarować odpowiednie funkcje platformy (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. odpowiednio do 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łączyć Bluetooth oparty na GATT (ogólnym profilu) interfejsów API opisanych w dokumentacji pakietu SDK oraz android.Bluetooth
• [C-3-3] MUSI zgłaszać prawidłową wartość dla BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy logika filtrowania w funkcji ScanFilter Wdrożono klasy interfejsu API.
• [C-3-4] MUSI zgłaszać prawidłową wartość dla BluetoothAdapter.isMultipleAdvertisementSupported(), aby wskazać czy reklamy Low Energy Advertising są obsługiwane.

• [C-3-5] TRZEBA wdrożyć limit czasu oczekiwania na odpowiedź RPA ponad 15 minut i zmieniać adres po upłynięciu czasu oczekiwania, aby chronić prywatność użytkowników gdy urządzenie aktywnie używa BLE do skanowania lub wyświetlania reklam. Aby zapobiec atakom czasowym, przedziały czasu oczekiwania MUSZĄ też być losowe od 5 do 15 minut.

• POWINNA obsługiwać przenoszenie logiki filtrowania do chipsetu Bluetooth podczas implementacji interfejsu API ScanFilter.

• 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 Bluetooth LE do skanowania lokalizacji,

• [C-4-1] MUSI udostępniać środki użytkownika, aby włączyć/wyłączyć odczytywaną wartość za pomocą interfejsu System API BluetoothAdapter.isBleScanAlwaysAvailable().

Jeśli implementacje urządzeń obejmują obsługę Bluetooth LE i aparatów słuchowych Profil, zgodnie z opisem w sekcji Obsługa dźwięku w aparacie słuchowym przy użyciu Bluetooth LE umożliwia:

• [C-5-1] MUSI zwrócić true za BluetoothAdapter.getProfileProxy(context, detektor, BluetoothProfile.HEARING_AID).

Jeśli implementacje urządzenia obejmują obsługę Bluetootha lub Bluetooth Low Energy, one:

• [C-6-1] MUSI ograniczać dostęp do metadanych Bluetooth (takich jak skanowanie które mogą zostać użyte do określenia lokalizacji urządzenia, chyba że aplikacja wysyłająca prośbę przekazuje android.permission.ACCESS_FINE_LOCATION sprawdzania uprawnień na podstawie jej bieżącego stanu na pierwszym planie/w tle.

Jeśli implementacje urządzenia obejmują obsługę Bluetootha lub Bluetooth Low Energy a manifest aplikacji nie zawiera deklaracji dewelopera, że nie korzystają z Bluetootha, to:

• [C-6-2] MUSI blokować dostęp do Bluetootha za urządzeniem android.permission.ACCESS_FINE_LOCATION.

Jeśli implementacje urządzeń zwracają wartość true w przypadku parametru BluetoothAdapter.isLeAudioSupported() API, wówczas:

• [C-7-1] MUSI obsługiwać klienta unicast.
• [C-7-2] MUSI obsługiwać 2 mln PHY.
• [C-7-3] MUSI obsługiwać reklamy rozszerzone LE.
• [C-7-4] MUSI obsługiwać co najmniej 2 połączenia CIS w CIG.
• [C-7-5] MUSI włączyć klienta unicast BAP, koordynatora zestawu CSIP, serwer MCP kontroler VCP i serwer CCP jednocześnie.
• [C-SR-1] Zdecydowanie ZALECANE jest włączenie klienta HAP unicast.

Jeśli implementacje urządzeń zwracają wartość true w przypadku parametru BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, wówczas:

• [C-8-1] MUSI obsługiwać co najmniej 2 linki BIS w dużych liczbach.
• [C-8-2] MUSI włączyć źródło transmisji BAP, asystenta transmisji BAP jednocześnie.
• [C-8-3] MUSI obsługiwać reklamy okresowe LE.

Jeśli implementacje urządzeń zwracają wartość true w przypadku parametru BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, wówczas:

• [C-9-1] MUSI obsługiwać okresowe przesyłanie synchronizacji reklam.
• [C-9-2] MUSI obsługiwać reklamy okresowe LE.

Jeśli implementacje urządzenia zadeklarują FEATURE_BLUETOOTH_LE:

• [C-10-1] Pomiar RSSI MUSI mieścić się w zakresie +/-9 dB w przypadku 95% w odległości 1 m od urządzenia referencyjnego transmitującego w odległości 1 m ADVERTISE_TX_POWER_HIGH w miejscu, w którym nic nie widać.
• [C-10-2] MUSI zawierać korekty Rx/Tx, aby zmniejszyć odchylenia dla poszczególnych kanałów. aby pomiary na każdym z 3 kanałów, na każdej z anten (jeśli zastosowanych jest kilka) znajdują się w zakresie +/-3 dB od siebie w 95% pomiarów.
• [C-SR-2] Zdecydowanie ZALECANE jest mierzenie i kompensowanie przesunięcia Rx do upewnij się, że mediana BLE RSSI wynosi -60 dBm +/-10 dB w odległości 1 m od urządzenia referencyjnego nadającego w źródle ADVERTISE_TX_POWER_HIGH, gdzie urządzenia są zorientowane tak, że znajdują się na „równoległych płaszczyznach” z ekranami skierowanymi do siebie kierunek.
• [C-SR-3] Zdecydowanie ZALECANE jest mierzenie i kompensowanie przesunięcia transakcji o upewnij się, że mediana BLE RSSI wynosi -60 dBm +/-10 dB podczas skanowania z poziomu odniesienia znajduje się w odległości 1 m i przesyła z częstotliwości ADVERTISE_TX_POWER_HIGH, gdzie urządzenia są ustawione tak, że są włączone „samoloty równoległe” których ekrany są skierowane w tym samym kierunku.

Zdecydowanie ZALECANE jest wykonanie kroków konfiguracji pomiaru podanych w artykule Wymagania dotyczące kalibracji obecności

7.4.4 Komunikacja Near Field Communication

Implementacje na urządzeniach:

• POWINIEN zawierać odbiornik i powiązany sprzęt do obsługi Near-Field Komunikacja (NFC).
• [C-0-1] MUSI zaimplementować zasady android.nfc.NdefMessage i interfejsów API usługi android.nfc.NdefRecord, nawet jeśli nie obsługują one NFC lub zadeklaruj funkcję android.hardware.nfc, ponieważ klasy reprezentują format reprezentacji danych niezależny od protokołu.

Jeśli urządzenia są wyposażone w moduł NFC i planujemy udostępnić tę funkcję innych firm:

• [C-1-1] MUSI zgłosić funkcję android.hardware.nfc w Metoda android.content.pm.PackageManager.hasSystemFeature().
• MUSI być w stanie odczytywać i zapisywać wiadomości NDEF za pomocą następującej komunikacji NFC standardów opisanych poniżej:
• [C-1-2] MUSI działać jako czytnik/zapisujący forum NFC (zgodnie ze specyfikacją techniczną Forum NFC NFCForum-TS-DigitalProtocol-1.0) za pomocą następujących standardów 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 do czytania i zapisu NDEF wiadomości, a także nieprzetworzone dane z wykorzystaniem poniższych standardów NFC. Pamiętaj, że podczas gdy standardy NFC są określane jako Zdecydowanie ZALECANE, Planujemy zmienić definicję zgodności w przyszłej wersji, MUSZĄ. Standardy te są opcjonalne w tej wersji, ale będą wymagane w przyszłych wersjach. Istniejące i nowe urządzenia, na których działa ta wersja aplikacji Zdecydowanie zalecamy spełnienie tych wymagań już teraz, możliwość przejścia na kolejne wersje platformy.

• [C-1-13] W trakcie wykrywania NFC MUSI przeprowadzać sondowanie w poszukiwaniu wszystkich obsługiwanych technologii i trybu uzyskiwania zgody.

• POWINNY być w trybie wykrywania NFC, gdy urządzenie jest wybudzone i ekran aktywny, a ekran blokady odblokowany.

• MUSI być w stanie odczytać kod kreskowy i URL (jeśli został zakodowany) Kod kreskowy NFC usług.

Pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku standardów JIS, ISO i NFC Specyfikacje forum wymienione powyżej.

Android obsługuje tryb HCE (NFC).

Jeśli używane urządzenia są wyposażone w chipset kontrolera NFC obsługujący HCE (na NfcA lub NfcB) oraz obsługują routing na podstawie identyfikatora aplikacji (AID). Dzięki temu:

• [C-2-1] MUSI zgłaszać stałą funkcję android.hardware.nfc.hce.
• [C-2-2] MUSI obsługiwać interfejsy NFC HCE API jako zdefiniowane w pakiecie SDK Androida.

jeśli implementacje urządzeń obejmują chipset kontrolera NFC obsługujący HCE; dla NfcF i wdrożyć 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 zgodnie z definicją w pakiecie Android SDK.

Jeśli implementacje urządzeń obejmują ogólną obsługę NFC, jak opisano w i obsługują technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF w MIFARE Classic), czytelnik/scenarzysta:

• [C-4-1] MUSI wdrożyć odpowiednie interfejsy API Androida zgodnie z pakiet SDK do Androida.
• [C-4-2] MUSI zgłosić funkcję com.nxp.mifare w android.content.pm.PackageManager.hasSystemFeature() . Nie jest to standardowa funkcja Androida, dlatego nie są wyświetlane 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 zawierać wsparcie dla co najmniej jednej formy i sieci danych. Implementacje na urządzeniach MUSZĄ obejmować obsługę co najmniej jeden standard danych o szybkości co najmniej 200 kb/s. Przykłady Technologie, które spełniają to wymaganie, to m.in. EDGE, HSPA, EV-DO, 802.11g, Ethernet i Bluetooth PAN.
• POWINIEN również obsługiwać co najmniej jedną wspólną transmisję danych bezprzewodowych np. 802.11 (Wi-Fi), w przypadku użycia sieci fizycznej (np. Ethernet) jest podstawowym połączeniem transmisji danych.
• 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ć IPv6 komunikacji przy użyciu zarządzanych interfejsów API, takich jak java.net.Socket, java.net.URLConnection oraz natywne interfejsy API, takie jak AF_INET6 i gniazdek.
• [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 adresu IPv6 przez urządzenie w dowolnej sieci zgodnej z protokołem IPv6, która korzysta z czasów istnienia RA: co najmniej 180 sekund.
• [C-0-6] MUSI zapewniać aplikacjom innych firm bezpośrednie połączenia IPv6 do sieci po podłączeniu do sieci IPv6, bez żadnych adresów ani translacji portów odbywającej się lokalnie na urządzeniu. Oba zarządzane interfejsy API, takie jak Socket#getLocalAddress lub Socket#getLocalPort) i interfejsy API NDK, takie jak getsockname() czy IPV6_PKTINFO, MUSZĄ zwracać adres IP adres i port, które są używane do wysyłania i odbierania pakietów sieci i jest widoczny jako źródłowy adres IP oraz port serwerów internetowych (internetowych).

Wymagany poziom obsługi IPv6 zależy od typu sieci, jak pokazano w poniższe wymagania.

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ć operację na stosie podwójnym i tylko IPv6 na Ethernet.

Jeśli implementacje urządzeń obsługują komórkową transmisję danych:

• [C-3-1] MUSI obsługiwać operację IPv6 (tylko IPv6 i być może podwójny stos) na sieć komórkową.

Jeśli implementacje urządzeń obsługują więcej niż 1 typ sieci (np. Wi-Fi, i mobilnej transmisji danych),

• [C-4-1] MUSI równocześnie spełniać powyższe wymagania w każdej sieci gdy urządzenie jest jednocześnie podłączone do więcej niż jednego typu sieci.

7.4.5.3 Portale przechwytujące

Portal dostępowy to sieć, która wymaga zalogowania się uzyskać dostęp do internetu.

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

• [C-1-1] MUSI zawierać aplikację portalu przechwytującego do obsługi intencji ACTION_CAPTIVE_PORTAL_SIGN_IN i wyświetlić stronę logowania do portalu przechwytującego, wysyłając tę intencję wywołanie interfejsu System API ConnectivityManager#startCaptivePortalApp(Network, Bundle)
• [C-1-2] MUSI wykrywać portale przechwytujące i logować się do pomocy za pomocą aplikacji portalu przechwytującego, gdy urządzenie jest podłączone do dowolnego typu sieci, w tym do sieci komórkowej/komórkowej, Wi-Fi i Ethernetu lub Bluetooth.
• [C-1-3] MUSI obsługiwać logowanie do portali przechwytujących z użyciem protokołu DNS z użyciem tekstu nieszyfrowanego gdy urządzenie jest skonfigurowane do korzystania z prywatnego trybu ograniczonego dostępu DNS.
• [C-1-4] MUSI używać zaszyfrowanego DNS zgodnie z dokumentacją SDK dla android.net.LinkProperties.getPrivateDnsServerName i android.net.LinkProperties.isPrivateDnsActive dla całego ruchu w sieci, który nie komunikuje się bezpośrednio z portalu przechwytującego.
• [C-1-5] MUSI upewnić się, że podczas logowania użytkownika do punktu dostępowego domyślnej sieci używanej przez aplikacje (podanej przez funkcję ConnectivityManager.getActiveNetwork ConnectivityManager.registerDefaultNetworkCallback, i domyślnie używane przez interfejsy sieciowe Java API, takie jak java.net.Socket, i natywne interfejsy API, takie jak connect()) to dowolna inna dostępna sieć który zapewnia dostęp do internetu (jeśli jest dostępny).

7.4.6 Ustawienia synchronizacji

Implementacje na urządzeniach:

• [C-0-1] MUSI mieć domyślnie włączone ustawienie autosynchronizacji głównej, aby metoda getMasterSyncAutomatically() zwraca wartość „true” (prawda).

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 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ą Open Mobile API zabezpieczeń i udostępniania ich aplikacjom innych firm:

• [C-1-1] MUSI wyliczać dostępne elementy zabezpieczone za pomocą android.se.omapi.SEService.getReaders() API.

• [C-1-2] MUSI zadeklarować prawidłowe flagi funkcji w android.hardware.se.omapi.uicc dla urządzeń z elementami bezpiecznymi opartymi na UICC, android.hardware.se.omapi.ese dla urządzeń z elementami zabezpieczonymi opartymi na eSE, android.hardware.se.omapi.sd dla urządzenia z zabezpieczonymi elementami opartymi na SD.

7.4.9. UWB

Jeśli implementacje urządzeń obejmują obsługę w wersji 802.1.15.4 i udostępnić ją aplikacji innej firmy, to:

• [C-1-1] MUSI zaimplementować odpowiedni interfejs API Androida w pliku android.uwb.
• [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.uwb.
• [C-1-3] MUSI obsługiwać wszystkie odpowiednie profile UWB zdefiniowane w Androidzie implementacji.
• [C-1-4] MUSI udostępniać informacje o produkcie, aby użytkownik mógł przełączyć UWB stanu włączenia/wyłączenia radia.
• [C-1-5] MUSI wymuszać, aby aplikacje korzystające z radia UWB miały uprawnienie UWB_RANGING (w grupie uprawnień NEARBY_devices).
• [C-SR-1] Zdecydowanie ZALECANE jest przejście odpowiedniej zgodności i testów certyfikacyjnych zdefiniowanych przez standardowe organizacje, w tym FIRA, CCC i CSA.
• [C-1-6] MUSI mieć pewność, że pomiar odległości wynosi +/-15 cm w przypadku 95%. w miejscu widoczności z odległości 1 m w komorze nieodbiciowej.
• [C-1-7] MUSI zapewnić medianę odległości 1 m z urządzenia referencyjnego znajduje się w promieniu [0,75 m; 1,25 m], gdzie dane podstawowe odległość jest mierzona od górnej krawędzi urządzenia.
• [C-SR-2] Zdecydowanie ZALECANE jest wykonanie czynności wymaganych do konfiguracji pomiaru. określona w Wymagania dotyczące kalibracji obecności

7.5 Aparaty

Jeśli implementacje urządzeń obejmują co najmniej jedną kamerę:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.camera.any.
• [C-1-2] MUSI być dostępna, aby aplikacja mogła jednocześnie przydzielać 3 mapy bitowe RGBA_8888 równe rozmiarowi obrazów wygenerowanych przez czujnika aparatu o największej rozdzielczości na urządzeniu, a aparat jest otwarty na potrzeby podstawowej wersji przedpremierowej.
• [C-1-3] MUSI mieć pewność, że zainstalowana jest domyślna aplikacja aparatu. intencji obsługi MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, lub MediaStore.ACTION_VIDEO_CAPTURE, odpowiada za usunięcie lokalizacji użytkownika z metadanych obrazu przed wysyłanie do aplikacji odbierającej, gdy aplikacja odbierająca nie mają ACCESS_FINE_LOCATION.

Jeśli implementacje urządzeń obsługują 10-bitowy HDR, to:

• [C-2-1] MUSI obsługiwać co najmniej profil HLG HDR w przypadku każdego aparatu. który obsługuje 10-bitowe pliki wyjściowe.
• [C-2-2] MUSI obsługiwać 10-bitowe wyjście dla głównego tylnego urządzenia lub głównego przedniego aparatu.
• [C-SR-1] Zdecydowanie ZALECANE jest obsługa 10-bitowych danych wyjściowych zarówno kamery.
• [C-2-3] MUSI obsługiwać te same profile HDR na wszystkich urządzeniach fizyczne podrzędne kamery kamery logicznej z obsługą funkcji BACKWARD_COMPATIBLE; przez aparat logiczny.

W przypadku aparatów logicznych, które obsługują 10-bitowy HDR, android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO. Są to:

• [C-3-1] MUSI obsługiwać przełączanie między wszystkimi urządzeniami fizycznymi zgodnymi wstecznie za pomocą elementu sterującego CONTROL_ZOOM_RATIO na kamerze logicznej.

7.5.1 Kamera tylna

Tylny aparat to aparat skierowany w stronę świata, który rejestruje sceny z daleka jak w przypadku tradycyjnego aparatu fotograficznego, na urządzeniach mobilnych, czyli aparatach, który znajduje się z boku urządzenia, naprzeciwko wyświetlacza.

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.
• MUSISZ mieć wdrożony sprzętowy autofokus lub automatyczny autofokus programowy w sterowniku aparatu (przezroczyste dla oprogramowania aplikacji).
• 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 być włączona, gdy Zarejestrowano android.hardware.Camera.PreviewCallback instancję na platformie podglądu aparatu, chyba że aplikacja została wyraźnie włączona Flash, włączając atrybuty FLASH_MODE_AUTO lub FLASH_MODE_ON Camera.Parameters obiektu. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu systemowego, ale tylko aplikacji za pomocą interfejsu Camera.PreviewCallback.

7.5.2 Przedni aparat

Przedni aparat to aparat skierowany do użytkownika, zwykle używany do robienia zdjęć. użytkownika, np. do obsługi rozmów wideo i podobnych aplikacji; na urządzeniu przenośnym czyli kamerę znajdującą się po tej samej stronie co wyświetlacz.

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 Camera API i NIE MOŻE konfigurować interfejsu API w taki sposób, aby traktował przedni aparat jako domyślny tylny aparat, nawet jeśli jest to jedyny aparat w urządzeniu.
• [C-1-4] Podgląd z aparatu MUSI być odbicie lustrzane w poziomie orientacja określona przez aplikację, gdy bieżąca aplikacja ma wyraźnie zażądał, aby kamera można obrócić za pomocą wywołania funkcji android.hardware.Camera.setDisplayOrientation() . I odwrotnie, podgląd MUSI być taki sam jak domyślny na urządzeniu. oś pozioma, gdy bieżąca aplikacja nie żąda wyraźnie obrót wyświetlacza kamery przez wywołanie funkcji android.hardware.Camera.setDisplayOrientation() .
• [C-1-5] NIE MOŻE odzwierciedlać ostatecznej wersji zdjęć ani strumieni wideo w odpowiedzi na wywołania zwrotne aplikacji lub zadeklarowano do przechowywania multimediów.
• [C-1-6] MUSI w ten sam sposób odbić obraz wyświetlany po wyświetleniu jako strumień obrazów z podglądu z aparatu.
• MOŻE zawierać funkcje (takie jak autofokus, lampa błyskowa itp.) dostępne dla: tylnych aparatów zgodnie z opisem w sekcji 7.5.1.

Jeśli implementacje urządzeń mogą być objęte rotacji przez użytkownika (np. automatycznie za pomocą akcelerometru lub ręcznie na podstawie danych wejściowych użytkownika):

• [C-2-1] Podgląd z aparatu MUSI być odbicie lustrzane w poziomie bieżącej orientacji urządzenia.

7.5.3 Kamera zewnętrzna

Kamera zewnętrzna to kamera, którą można fizycznie zamocować lub odłączyć. implementacji urządzenia w dowolnym momencie i mogą wystąpić w dowolnym kierunku; Na przykład USB kamery.

Implementacje na urządzeniach:

• MOŻNA obsługiwać kamerę zewnętrzną, ale nie jest to konieczne zawsze połączony.

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 Aparat łączy się przez port hosta USB.
• [C-1-3] MUSI przejść testy CTS kamery za pomocą fizycznego zewnętrznego aparatu. – podłączono 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 wysokiej jakości niezakodowane strumienie (tj. nieprzetworzone lub niezależnie skompresowane obrazy strumienie).
• 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] Równoczesna strumień niezakodowany / MJPEG (rozdzielczość QVGA lub większa) MUSI być dostępna dla na urządzeniach mobilnych.

7.5.4 Działanie interfejsu Camera API

Android oferuje dostęp do aparatu za pomocą dwóch pakietów API. Nowszy jest interfejs API android.hardware.camera2 zapewnia aplikacji możliwość sterowania kamerą niższego poziomu, w tym wydajne przepływy zdjęć typu burst/strumieniowanie bez żadnej kopii i ustawienia dla poszczególnych klatek ekspozycja, wzmocnienie, wzmocnienia balansu bieli, konwersja kolorów, odszumienie, wyostrzenie, i inne.

Starszy pakiet interfejsu API (android.hardware.Camera) jest oznaczony jako wycofany w Androida 5.0, ale nadal powinien być dostępny dla aplikacji. urządzenie z Androidem Implementacje MUSZĄ zapewnić ciągłość obsługi interfejsu API zgodnie z opisem w w tej sekcji oraz w pakiecie Android SDK.

Wszystkie funkcje wspólne w wycofanej klasie android.hardware.Camera Nowy pakiet android.hardware.camera2 MUSI mieć podobną wydajność i jakość w obu interfejsach API. Na przykład przy równoważnych ustawieniach szybkość i dokładność autofokusa muszą być identyczne, a jakość robionych zdjęć musi być taka sama. musi być taka sama. Funkcje, które zależą od semantyki 2 interfejsów API nie muszą mieć zgodnej szybkości ani jakości, ale POWINNY być ściśle dopasowane jak to tylko możliwe.

Implementacje na urządzeniach MUSZĄ działać w następujący sposób w przypadku interfejsów API związanych z aparatami dla wszystkich dostępnych kamer. Implementacje na urządzeniach:

• [C-0-1] W podglądzie MUSISZ używać komponentu android.hardware.PixelFormat.YCbCr_420_SP dane przekazywane do wywołań zwrotnych aplikacji, gdy aplikacja nigdy nie została wywołana android.hardware.Camera.Parameters.setPreviewFormat(int)
• [C-0-2] MUSI mieć dodatkowo format kodowania NV21, gdy aplikacja rejestruje android.hardware.Camera.PreviewCallback instancję, a system wywołuje metodę onPreviewFrame() oraz podgląd format to YCbCr_420_SP, 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 tagiem stałą android.graphics.ImageFormat.YV12) dla podglądów z kamery w obu modelach. na przednim i tylnym aparacie android.hardware.Camera. (Sprzęt koder wideo i kamera mogą wykorzystywać dowolny natywny format piksela, ale urządzenie implementacja MUSI obsługiwać konwersję na YV12).
• [C-0-4] MUSI obsługiwać atrybuty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako danych wyjściowych przez Interfejs API android.media.ImageReader dla android.hardware.camera2 urządzeń, które Reklamuj REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE w android.request.availableCapabilities.
• [C-0-5] MUSI nadal zaimplementować pełny interfejs Camera API zawarte w dokumentacji pakietu Android SDK niezależnie od tego, czy urządzenie obejmuje sprzętowy autofokus i inne funkcje. Na przykład kamery, które brak autofokusa MUSI nadal wywoływać dowolne zarejestrowane android.hardware.Camera.AutoFocusCallback instancji (mimo że w tym przypadku nie ma trafność w przypadku aparatu bez autofokusa). Pamiętaj, że dotyczy to przedniego aparatu kamery; na przykład mimo że większość przednich aparatów nie obsługuje autofokus, wywołania zwrotne interfejsu API nadal muszą być „sfakowane” zgodnie z opisem.
• [C-0-6] MUSI rozpoznawać i uwzględniać każdą nazwę parametru jest określona jako stała w argumencie android.hardware.Camera.Parameters i android.hardware.camera2.CaptureRequest. I odwrotnie, implementacje urządzeń NIE MOGĄ uwzględniać ani rozpoznawać stałych ciągów znaków przekazywane do metody android.hardware.Camera.setParameters() innej niż te są udokumentowane jako stałe na android.hardware.Camera.Parameters. To znaczy, implementacje urządzenia MUSZĄ obsługiwać wszystkie standardowe parametry aparatu, jeśli sprzęt zezwala i NIE MOŻE obsługiwać niestandardowych typów parametrów aparatu. Na przykład implementacji urządzeń, które obsługują przechwytywanie obrazów przy użyciu technik obrazowania High Dynamic Range (HDR) MUSI obsługiwać parametry kamery. Camera.SCENE_MODE_HDR
• [C-0-7] MUSI zgłosić odpowiedni poziom pomocy android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i zgłoś odpowiednią flagi funkcji platformy.
• [C-0-8] MUSI też zadeklarować możliwości poszczególnych kamer android.hardware.camera2 przez Usługa android.request.availableCapabilities i zadeklarować odpowiednie flagi funkcji; MUSI zdefiniować flagę funkcji, jeśli dowolne z podłączonych do niej kamer obsługuje tę funkcję.
• [C-0-9] MUSI transmitować Camera.ACTION_NEW_PICTURE za każdym razem, gdy aparat zapisuje nowe zdjęcie. Zdjęcie zostało dodane do magazynu multimediów.
• [C-0-10] MUSI transmitować Camera.ACTION_NEW_VIDEO za każdym razem, gdy kamera zarejestruje nowy film, Zdjęcie zostało dodane do magazynu multimediów.
• [C-0-11] MUSI mieć dostęp do wszystkich kamer za pomocą android.hardware.Camera Interfejs API jest też dostępny w interfejsie android.hardware.camera2 API.
• [C-0-12] MUSI dopilnować, aby NIE zmienił się wygląd twarzy, w tym między innymi zmiany geometrii, odcienia skóry lub samej twarzy wygładzenie skóry dla każdego typu android.hardware.camera2 lub android.hardware.Camera API.
• [C-SR-1] Urządzenia z wieloma kamerami RGB są blisko siebie i skierowane w tym samym kierunku, Zdecydowanie zaleca się korzystanie z aparatu logicznego, który wyświetla listę zdolność CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA obejmujący wszystkie kamery RGB skierowane w tym kierunku jako fizyczne urządzenia podrzędne.

Jeśli implementacje urządzeń udostępniają aplikacjom innych firm zastrzeżony interfejs API aparatu, one:

• [C-1-1] MUSI wdrożyć taki interfejs API aparatu za pomocą android.hardware.camera2 API.
• MOŻE udostępniać tagi lub rozszerzenia dostawców do android.hardware.camera2 API.

7.5.5 Orientacja aparatu

Jeśli urządzenia mają aparat przedni lub tylny:

• [C-1-1] MUSI być zorientowana tak, by długi wymiar kamery był równy do długości ekranu. Oznacza to, że gdy urządzenie jest trzymane poziomo. aparaty MUSZĄ robić zdjęcia w orientacji poziomej. Ten obowiązuje niezależnie od naturalnej orientacji urządzenia; czyli dotyczy z urządzeniami głównymi w orientacji poziomej i pionowej.

Urządzenia, które spełniają wszystkie poniższe kryteria, są zwolnione z tego wymogu:

• Urządzenie ma ekrany o zmiennej geometrii, np. składane lub zawiasowe. i wyświetlacze.
• Gdy zmieni się stan złożenia lub zawiasu, urządzenie przełącza się od orientacji pionowej do podstawowej i poziomej.
• Implementacje urządzeń, które nie mogą być rotowane przez użytkownika, takie jak jak urządzenia motoryzacyjne.

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żer pobierania których aplikacje MOGĄ używać do pobierania plików danych, przy czym MUSZĄ one być w stanie domyślne pobieranie pojedynczych plików o rozmiarze co najmniej 100 MB „pamięć podręczna” lokalizacji.

7.6.2 Pamięć współdzielona aplikacji

Implementacje na urządzeniach:

• [C-0-1] MUSI oferować miejsce na dane, które może być współużytkowane przez aplikacje (często również nazywane) jako „współdzielona pamięć zewnętrzna”, „pamięć współdzielona aplikacji” ani przez Linuksa, ścieżka „/sdcard” na których są zamontowane.
• [C-0-2] MUSI być skonfigurowana z domyślnie podłączoną pamięcią współdzieloną w innych „Gotowe”, niezależnie od tego, czy pamięć masowa została zaimplementowana Element pamięci wewnętrznej lub nośnik wymienny (np. bezpieczny) gniazdo na kartę cyfrową).
• [C-0-3] MUSI podłączać pamięć współdzieloną aplikacji bezpośrednio w ścieżce Linuksa sdcard lub dołącz łącze symboliczne Linuksa z sdcard do rzeczywistego punktu montowania .
• [C-0-4] MUSI włączyć ograniczone miejsce na dane domyślnie dla wszystkich aplikacje kierowane na interfejs API na poziomie 29 lub wyższym, z wyjątkiem tych sytuacji:
  • Gdy aplikacja zażąda android:requestLegacyExternalStorage="true" w pliku manifestu.
• [C-0-5] MUSI usuwać metadane lokalizacji, takie jak tagi Exif GPS, plików multimedialnych, gdy dostęp do nich jest uzyskiwany w aplikacji MediaStore, chyba że aplikacja do rozmów ma uprawnienie ACCESS_MEDIA_LOCATION.

Implementacje na urządzeniach MOGĄ spełniać powyższe wymagania, jeśli korzystasz z :

• Pamięć wymienna dostępna dla użytkowników, np. gniazdo kart Secure Digital (SD).
• Część pamięci wewnętrznej (niewymiennej) wdrożona w Android Open Source Project (AOSP).

Jeśli implementacje urządzeń korzystają z pamięci wymiennej, aby spełnić wymagania opisane powyżej spełniają poniższe wymagania:

• [C-1-1] MUSI zaimplementować toast lub wyskakujące okienko z ostrzeżeniem dla użytkownika gdy w gniazdku nie ma nośnika pamięci.
• [C-1-2] MUSI zawierać nośnik pamięci w formacie FAT (np.kartę SD) lub program. na pudełku i innych materiałach dostępnych w momencie zakupu, Medium trzeba kupić osobno.

jeśli implementacje urządzeń wykorzystują część niewymiennej pamięci masowej, aby powyższe wymagania:

• Trzeba użyć implementacji AOSP udostępnionej aplikacji wewnętrznej pamięci masowej.
• 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, one:

• [C-3-1] MUSI zapewniać mechanizm dostępu do danych w aplikacji pamięci współdzielonej z komputera hosta.
• Treści z obu ścieżek pamięci NALEŻY w przejrzysty sposób udostępniać Skaner multimediów na Androidzie i android.provider.MediaStore.
• MOŻNA korzystać z pamięci masowej USB, ale POWINNY jest korzystać z protokołu Media Transfer Protocol. tego wymogu.

Urządzenia wyposażone w port USB z trybem peryferyjnym USB i obsługą Media Transfer Protocol:

• POWINNA być zgodna z referencyjnym hostem MTP Androida, 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 urządzenie ma być mobilne, implementacji na różnych urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest wdrożenie pamięci dostosowywanej w w stabilnej lokalizacji długoterminowej, ponieważ przypadkowe rozłączenie może spowodować mogą spowodować utratę lub uszkodzenie danych.

Jeśli port wymiennego urządzenia pamięci masowej znajduje się w stabilnej lokalizacji długoterminowej, np. w komorze na baterię lub w innej osłonie ochronnej, implementacji na różnych urządzeniach:

• [C-SR-2] Zdecydowanie ZALECANE jest wdrożenie pamięci uniwersalnej.

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 zgodnego ze standardem port USB typu A lub typu C.
• [C-1-2] MUSI zgłosić prawidłową wartość parametru iSerialNumber w standardzie USB deskryptor urządzenia za pomocą: android.os.Build.SERIAL.
• [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A na opornik typu C standardowe i MUSI wykrywać zmiany w reklamie, jeśli obsługują USB typu C.
• [C-SR-1] Port POWINIEN używać formatu micro-B, micro-AB lub USB typu C. Zdecydowanie ZALECANE są stosowane już i nowe urządzenia z Androidem, aby spełniać te wymagania: , aby umożliwić przejście na kolejne wersje platformy.
• [C-SR-2] Port powinien znajdować się na spodzie urządzenia (zgodnie z naturalną orientacją) lub włącz programowy obrót ekranu dla wszystkich aplikacji (w tym ekranu głównego), aby ekran wyświetlał się prawidłowo urządzenie jest kierowane na port u dołu. Istniejący i nowy Android urządzenia są Zdecydowanie ZALECANE, jeśli chodzi o spełnienie tych wymagań, dzięki czemu będą możliwość uaktualnienia do przyszłych wersji platformy.
• [C-SR-3] NALEŻY zaimplementować wsparcie umożliwiające pobieranie prądu o napięciu 1,5 A przy sygnale HS i ruchu zgodnie ze specyfikacją ładowania baterii USB w wersji 1.2. Zdecydowanie ZALECANE są stosowane już i nowe urządzenia z Androidem, aby spełniać te wymagania: , aby umożliwić przejście na kolejne wersje platformy.
• [C-SR-4] Zdecydowanie ZALECANE nie obsługuje zastrzeżonych metod ładowania, które modyfikują napięcie Vbus do wartości domyślnych lub zmieniają role ujścia/źródłowe mogą powodować problemy ze współdziałaniem z ładowarki lub urządzenia, które obsługują standardowe metody przesyłania energii przez USB. Choć tzw. „Zdecydowanie ZALECANE”, w kolejnych wersjach Androida może WYMAGAĆ obsługi wszystkich urządzeń typu C w celu zapewnienia pełnej interoperacyjności ze standardowymi ładowarki typu C.
• [C-SR-5] ZDECYDOWANIE ZALECANE do obsługi funkcji Power Delivery dla danych i zmianę roli zasilania, jeśli urządzenie obsługuje tryb hosta USB typu C i USB.
• POWINNA obsługiwać technologię Power Delivery w przypadku ładowania wysokiego napięcia oraz Alternatywne tryby, np. wyświetlanie na zewnątrz.
• NALEŻY zaimplementować interfejs API i specyfikację Android Open Accessory (AOA) jako omówiono w dokumentacji pakietu Android SDK.

Jeśli urządzenia są wyposażone w port USB i wdrożono interfejs AOA specyfikacja, oznacza to, że:

• [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” w koniec ciągu opisu interfejsu iInterface pamięci masowej USB

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, jak opisano w SDK na Androida i MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.host
• [C-1-2] MUSISZ wdrożyć obsługę podłączania standardowych urządzeń peryferyjnych USB. Innymi słowy, MUSZĄ:
  • urządzenie musi mieć port USB typu C lub musi być wyposażony w kable umożliwiające podłączenie urządzenia. zastrzeżony port do standardowego portu USB typu C (urządzenie z USB typu C).
  • urządzenie musi być wyposażone w urządzenie typu A lub użyć kabli dołączonych do urządzenia. do standardowego portu USB typu A.
  • urządzenie musi mieć port micro-AB na urządzeniu, który POWINNY być w dostarczeniu z przejściowym kablem; do standardowego portu typu A.
• [C-1-3] NIE MOŻE być wysyłane z przejściówką przekonwertowaną z USB typu A ani porty micro-AB do portu typu C (pojemnika).
• [C-SR-1] Zdecydowanie ZALECANE jest wdrożenie Zajęcia audio USB zgodnie z dokumentacją pakietu Android SDK.
• POWINNO obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB podczas hosta tryb; reklamujesz źródło prądu o wartości co najmniej 1,5 A, jak określono w Sekcja Parametry zakończenia Wersja 1.2 ze specyfikacją kabla USB typu C dla USB typu C lub korzystanie z zakresu prądu wyjściowego CDP (CDP) jako określona w tagu Specyfikacja ładowania baterii przez USB, wersja 1.2 dla złączy Micro-AB.
• 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 i port USB, podczas lekcji audio:

• [C-2-1] MUSI obsługiwać klasę USB HID.
• [C-2-2] MUSI obsługiwać wykrywanie i mapowanie tych danych HID określone w tabelach użytkowania USB HID. oraz Voice Command Usage Request do KeyEvent takie 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 urządzenia są wyposażone w port USB obsługujący tryb hosta oraz platformę Storage Access Framework (SAF), mogą:

• [C-3-1] MUSI rozpoznawać zdalnie połączony MTP (Media Transfer Protocol) urządzeń i udostępniaj ich treści w ACTION_GET_CONTENT, Intencje ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT. .

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i USB Typ C, to:

• [C-4-1] MUSI zaimplementować funkcję podwójnego portu USB zgodnie z definicją podaną przez USB Specyfikacja typu C (art. 4.5.1.3.3). Dual Porty ról: na urządzeniach wyposażonych w gniazdo słuchawek 3,5 mm zlew USB wykrywanie (tryb hosta) MOŻE być domyślnie wyłączone, ale MUSI być dostępne w użytkownik, który ją włączy.
• [C-SR-2] Zdecydowanie zalecana do obsługi DisplayPort, POWINNA obsługiwać USB SuperSzybkość danych i Zdecydowanie ZALECANA do obsługi Power Delivery w celu zmiany ról związanych z danymi i zasilaniem.
• [C-SR-3] Zdecydowanie NIE zaleca się obsługi trybu akcesorium adaptera audio jako opisane w Załączniku A do Wersja 1.2 specyfikacji kabla USB typu C i złącza
• Trzeba wdrożyć model Try.*, który najlepiej pasuje do format urządzenia. Na przykład na urządzeniu przenośnym WARTO zaimplementować Model 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 w art. 5.4.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnień dźwięku określone w artykuł 5.6.
• [C-SR-1] Zdecydowanie ZALECANE są w sposób opisany powyżej nagrywanie dźwięku bliskiego ultradźwięku. 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 trybie braku działań zgodnie z sekcja 7.

7.8.2 Wyjście audio

jeśli implementacje urządzeń obejmują głośnik lub wyjście audio/multimedialne, do urządzenia peryferyjnego wyjścia audio, takiego jak 4-kanałowe gniazdo słuchawek 3,5 mm lub Port w trybie hosta USB i z użyciem klasy audio USB:

• [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 w sekcja 5.5.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnień dźwięku określone w artykuł 5.6.
• [C-SR-1] Zdecydowanie zalecana do odtwarzania dźwięku 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” jest interfejs fizyczny np.gniazdo słuchawek 3, 5 mm, HDMI lub port w trybie hosta USB z klasą audio USB. Obsługa wyjścia audio przez protokoły radiowe, takie jak Bluetooth, Wi-Fi lub sieć komórkowa nie obejmuje „portu wyjściowego”.

7.8.2.1 Analogowe porty audio

Aby zapewnić zgodność z słuchawki i inne akcesoria audio z wtyczki audio 3,5 mm w całym ekosystemie Androida, jeśli urządzenie Możliwe zastosowania obejmują co najmniej jeden analogowy port audio. Są to:

• [C-SR-1] Zdecydowanie ZALECANE jest dodanie co najmniej jednej porty audio jako 4-kanałowe gniazdo 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 słuchawkowych stereo za pomocą mikrofonu.
• [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 poniżej 3 zakresów równoważnych impedancji między mikrofonem a podłożem przewodniki na 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 włożeniu wtyczki, ale dopiero wtedy, gdy wszystkie kontakty podłączone do wtyczki dotykają odpowiednich segmentów na gnieździe.
• [C-1-5] MUSI być zdolna do napięcia na poziomie co najmniej 150 mV ± 10% napięcia wyjściowego na dla głośnika 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 zakres równoważnej impedancji między mikrofonem a przewodnikami po powierzchni ziemi na wtyczce audio:
  • 110–180 omów: KEYCODE_VOICE_ASSIST
• [C-SR-2] Zdecydowanie ZALECANE są współdziałanie wtyczek audio z OMTP w kolejności odpinania.
• [C-SR-3] Zdecydowanie ZALECANE są obsługa nagrywania dźwięku ze źródeł stereo. zestawy słuchawkowe z mikrofonem.

Jeśli urządzenia są wyposażone w 4-żyłowe gniazdo słuchawek 3,5 mm i obsługują i prześlij komunikat „android.intent.action.HEADSET_PLUG” wraz z mikrofon o dodatkowej wartości ustawiony na 1:

• [C-2-1] MUSI obsługiwać wykrywanie mikrofonu we podłączonym dźwięku akcesorium.

7.8.2.2. Cyfrowe porty audio

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ć zespół pomocy dźwięku bliskiego ultradźwięku za pośrednictwem AudioManager.getWłaściwość API w następujący sposób:

Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND ma wartość „true”, następujące wymagania MUSZĄ spełniać warunki Źródła dźwięku VOICE_RECOGNITION i UNPROCESSED:

• [C-1-1] Średnia moc mikrofonu mikrofonu w paśmie 18,5–20 kHz Wartość MUSI nie przekraczać 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 jest „true” (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:

• NALEŻY zapewnić bezproblemową ścieżkę sygnału audio dla obu źródeł sygnału strumienie wyjściowe i urządzenia mobilne zgodnie z definicją braku błędów zmierzoną w teście trwającym 1 minutę na ścieżkę. Przetestuj za pomocą OboeTester „Automatyczny test błędu”.

Test wymaga klucza sprzętowego do odtwarzania dźwięku w pętli audio, bezpośrednio do gniazda słuchawek 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, więc tag następujące kombinacje POWINNY być przetestowane pod kątem błędów przy użyciu AAudio:

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ć następujące kryteria sygnałów do szumu Współczynnik (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. Rzeczywistość wirtualna

Android udostępnia interfejsy API i obiekty do tworzenia „rzeczywistości wirtualnej” (VR) w tym wysokiej jakości rzeczywistość wirtualną na urządzeniach mobilnych. Urządzenie Implementacje MUSZĄ poprawnie wdrożyć te interfejsy API i zachowania, jak opisano w tej sekcji.

7.9.1. Tryb rzeczywistości wirtualnej

Android zapewnia obsługę Tryb VR, funkcję, która obsługuje stereoskopowe renderowanie powiadomień i wyłącza je monokularnych komponentów interfejsu systemu, 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ępniać rozszerzenia na liście dostępnych rozszerzeń EGL.
• [C-1-8] MUSI zaimplementować GL_EXT_multisampled_render_to_texture2 GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures i udostępniać rozszerzenia na liście dostępnych rozszerzeń GL.
• [C-SR-1] Zdecydowanie ZALECANE jest wdrożenie GL_EXT_external_buffer GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, i udostępniać rozszerzenia 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 VK_ANDROID_external_memory_android_hardware_buffer VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, i udostępnić go na liście dostępnych rozszerzeń Vulkan.
• [C-SR-4] Zdecydowanie ZALECANE jest udostępnienie co najmniej 1 rodziny kolejek Vulkan, w których flags zawierają zarówno VK_QUEUE_GRAPHICS_BIT, jak i VK_QUEUE_COMPUTE_BIT, i queueCount to co najmniej 2.
• [C-1-7] GPU i wyświetlacz MUSZĄ synchronizować dostęp do współdzielonych bufor z przodu, czyli naprzemienne renderowanie treści VR z prędkością 60 kl./s konteksty renderowania będą wyświetlane bez widocznych artefaktów rozdarcia.
• [C-1-9] MUSI wdrożyć obsługę AHardwareBuffer flagi AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT zgodnie z wytycznymi NDK.
• [C-1-10] MUSISZ zaimplementować obsługę komponentów AHardwareBuffer z dowolnymi kombinacja 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ą oraz flagami i formatami określonymi w standardzie C-1-10.
• [C-1-11] MUSI obsługiwać dekodowanie H.264 w rozdzielczości co najmniej 3840 x 2160 przy 30 kl./s, skompresowane do średnio 40 Mb/s (odpowiednik 4 instancji 1920 x 1080 przy 30 kl./s do 10 Mb/s lub 2 instancje 1920 x 1080 przy 60–20 Mb/s).
• [C-1-12] MUSI obsługiwać kodowanie HEVC i VP9 i MUSI umożliwiać dekodowanie 1920 x 1080 przy 30 kl./s skompresowana do średniej wartości 10 Mb/s. POWINNA dekodowanie rozdzielczości 3840 x 2160 przy 30–20 Mb/s (odpowiednik 4 instancje 1920 x 1080 przy 30 kl./s do 5 Mb/s).
• [C-1-13] MUSI obsługiwać interfejs HardwarePropertiesManager.getDeviceTemperatures API i zwracają dokładne wartości temperatury skóry.
• [C-1-14] MUSI mieć wbudowany ekran, a jego rozdzielczość MUSI mieć co najmniej 1920 × 1080.
• [C-SR-6] Zdecydowanie ZALECANE są rozdzielczość ekranu na poziomie co najmniej 2560 x 1440.
• [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 niskiej żywotności przez ≤ 5 milisekund trwałość, trwałość jest definiowana jako czas który wysyła światło.
• [C-1-18] MUSI obsługiwać rozszerzenie Bluetooth 4.2 i Bluetooth LE art. 7.4.3.
• [C-1-19] MUSI obsługiwać i prawidłowo zgłaszać Typ kanału bezpośredniego dla 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 są wsparcie TYPE_HARDWARE_BUFFER bezpośredni typ kanału dla wszystkich typów kanałów bezpośrednich wymienionych powyżej.
• [C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru wymagania dla usługi android.hardware.hifi_sensors określone w art. 7.3.9.
• [C-SR-8] Zdecydowanie ZALECANE są działania android.hardware.sensor.hifi_sensors funkcja.
• [C-1-22] MUSI mieć opóźnienie w stopniu pełnym animacji do fotonów, nie większe niż 28 milisekund.
• [C-SR-9] Zdecydowanie ZALECANE jest dla nich maksymalne opóźnienie w stosunku do fotonów. nie dłuższy niż 20 milisekund.
• [C-1-23] MUSI mieć współczynnik pierwszej klatki, czyli stosunek między jasność pikseli na pierwszej klatce po przejściu z czarnego do czarnego biały i jasność 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łączny rdzeń na pierwszym planie aplikacji i MOŻE obsługiwać interfejs API Process.getExclusiveCores w celu zwrócenia liczba rdzeni procesora dostępnych wyłącznie na górnym pierwszym planie aplikacji.

Jeśli obsługiwana jest funkcja podstawowa, która obejmuje:

• [C-2-1] NIE MOŻE zezwalać na uruchamianie żadnych innych procesów przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE zezwolić na używanie niektórych jąder które przebiegają zgodnie z potrzebami.

7.10. Reakcja na dotyk

Urządzenia przeznaczone do noszenia w ręce lub noszenia mogą obsługiwać reakcję haptyczną o ogólnym zastosowaniu. aktywator, dostępny dla aplikacji m.in. w celu zwrócenia uwagi dzwonki, alarmy, powiadomienia, a także ogólne sygnały dotykowe.

Jeśli implementacje urządzeń NIE zawierają tego ogólnego przeznaczenia czujnika haptycznego, one:

• [7.10/C] MUSI zwracać wartość fałsz dla funkcji Vibrator.hasVibrator().

Jeśli implementacje urządzenia OBEJMUJĄ co najmniej jeden taki ogólny czujnik haptyczny użytkownika, to:

• [C-1-1] MUSI zwracać wartość „prawda” dla funkcji Vibrator.hasVibrator().
• NIE NALEŻY używać ekscentrycznego mechanizmu haptycznego (wibratora) z niecentryczną obrotową masą (ERM).
• NALEŻY zastosować wszystkie publiczne stałe, aby uzyskać wyraźne czujniki haptyczne. w android.view.HapticFeedbackConstants (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START i GESTURE_END).
• NALEŻY zastosować wszystkie publiczne stałe, aby uzyskać wyraźne czujniki haptyczne. w android.os.VibrationEffect (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK i EFFECT_DOUBLE_CLICK) i wszystkie możliwe publiczne stałe PRIMITIVE_* dla reakcja haptyczna za android.os.VibrationEffect.Composition CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Niektóre z tych elementów podstawowych, na przykład LOW_TICK a SPIN może być możliwe tylko wtedy, gdy wibracje obsługują stosunkowo słabą jakość częstotliwości.
• MUSISZ przestrzegać wytycznych dotyczących mapowania stałych publicznych w android.view.HapticFeedbackConstants na zalecaną wartość android.os.VibrationEffect stałe o odpowiednich zależnościach amplitudy.
• NALEŻY użyć tych połączonych stałych wartości haptycznych (mapowania).
• MUSI spełniać ocenę jakości. dla createOneShot() i createWaveform() API.
• MUSI sprawdzić, czy wynik publiczny android.os.Vibrator.hasAmplitudeControl() Interfejs API poprawnie odzwierciedla możliwości wibracji.
• NALEŻY sprawdzić możliwości skalowalności amplitudy, uruchamiając polecenie android.os.Vibrator.hasAmplitudeControl().

Jeśli implementacje urządzeń postępują zgodnie z mapowaniem stałych haptycznych:

• NALEŻY sprawdzić stan implementacji, uruchamiając polecenie android.os.Vibrator.areAllEffectsSupported() i android.os.Vibrator.arePrimitivesSupported() API.
• MUSISZ przeprowadzić ocenę jakości dla stałych haptycznych.
• TRZEBA zweryfikować i w razie potrzeby zaktualizować konfigurację zastępczą dla nieobsługiwane elementy podstawowe opisane we wskazówkach dotyczących implementacji. dla stałych.
• MUSI zapewnić pomoc zastępczą, aby zmniejszyć ryzyko awarii zgodnie z opisem tutaj.

7.11. Zajęcia dotyczące skuteczności mediów

O klasie wydajności mediów w przypadku implementacji urządzenia można uzyskać z interfejs API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Wymagania klasy wydajności multimediów są zdefiniowane dla każdej wersji Androida, zaczynając od R (wersja 30). Wartość specjalna 0 oznacza, że urządzenie nie jest klasa skuteczności multimediów.

Jeśli implementacje urządzeń zwracają wartość inną niż zero dla argumentu android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

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

• [C-1-2] MUSI być implementacją na urządzeniach mobilnych.

• [C-1-3] MUSI spełniać wszystkie wymagania dotyczące klasy „Media Performance Class” opisana w sekcji 2.2.7.

Inaczej mówiąc, klasa wydajności multimediów w Androidzie T jest zdefiniowana tylko dla: urządzeń mobilnych w wersji T, S lub R.

Szczegółowe informacje znajdziesz w sekcji 2.2.7. .

8. Wydajność i moc

Niektóre kryteria minimalnej wydajności i mocy mają kluczowe znaczenie dla wygody użytkowników. i wpłynąć na podstawowe założenia, jakich przyjmują deweloperzy przy opracowywaniu .

8.1. Spójność wrażeń użytkownika

Użytkownikom można zapewnić płynny interfejs, jeśli minimalne wymagania dla zapewnienia stałej liczby klatek i czasu reakcji aplikacji i gier. Implementacje urządzeń w zależności od ich typu MOŻE mieć mierzalne wymagania dotyczące czasu oczekiwania i zadania w interfejsie zgodnie z opisem w sekcji 2.

8.2. Skuteczność dostępu do plików

Wskazanie punktu odniesienia dla stałej wydajności dostępu do plików w prywatne miejsce na dane aplikacji (partycja /data) umożliwia deweloperom aplikacji aby uzyskać odpowiednie oczekiwania, które ułatwią projektowanie oprogramowania. Urządzenie implementacje MOGĄ mieć określone wymagania w zależności od typu urządzenia opisanych w sekcji 2. i operacji zapisu:

• Wydajność sekwencyjnego zapisu. Pomiar ten polega na zapisaniu pliku 256 MB za pomocą Bufor zapisu 10 MB.
• Losowa wydajność zapisu. Zmierzony przez zapisanie pliku 256 MB o rozmiarze 4 kB bufor zapisu.
• Wydajność sekwencyjnego odczytu. Pomiar dokonywany jest na podstawie odczytu pliku 256 MB za pomocą Bufor zapisu 10 MB.
• Losowa wydajność odczytu. Pomiar został zmierzony przy odczycie pliku 256 MB przy użyciu 4 KB bufor zapisu.

8.3. Tryby oszczędzania energii

jeśli implementacje urządzeń obejmują funkcje usprawniające zarządzanie energią urządzenia; uwzględnione w AOSP (np. zasobnik gotowości aplikacji, uśpienie) lub rozszerzenie funkcji w celu zastosowania silniejszych ograniczeń niż zasobnik gotowości aplikacji OGRANICZONE:

• [C-1-1] NIE MOŻE odbiegać od implementacji AOSP dla reguły, konserwację, algorytmy wybudzania i korzystanie z globalnych ustawień systemu lub DeviceConfig trybów Czuwanie aplikacji i Uśpienie.
• [C-1-2] NIE MOŻE odbiegać od implementacji AOSP w przypadku użycia globalnego lub DeviceConfig do zarządzania ograniczaniem liczby zadań, dla aplikacji w każdym zasobniku na potrzeby gotowości aplikacji.
• [C-1-3] NIE MOŻE odbiegać od implementacji AOSP dla liczby Zasobniki gotowości aplikacji używany w trybie gotowości aplikacji.
• [C-1-4] MUSI wdrożyć zasobniki gotowości aplikacji i Uśpienie zgodnie z opisem w sekcji Zarządzanie zasilaniem.
• [C-1-5] MUSI zwrócić true za PowerManager.isPowerSaveMode(). gdy urządzenie działa w trybie oszczędzania energii.
• [C-1-6] MUSI udostępniać dostęp do wszystkich aplikacji, które są zwolnione z obowiązku posiadania licencji z trybów Czuwanie aplikacji i Uśpienia, a także optymalizacji baterii. i MUSI zaimplementować ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. prosić użytkownika o zgodę na ignorowanie baterii przez aplikację i optymalizacji.
• [C-SR-1] Zdecydowanie ZALECANE są zapewnić zasoby dla użytkowników umożliwiające wyłączyć funkcję oszczędzania baterii.
• [C-SR-2] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości wyświetlania wszystkich aplikacje wyłączone z trybów czuwania aplikacji i uśpienia.

Jeśli implementacje urządzeń rozszerzają dostępne funkcje zarządzania energią 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 wdrożenia na urządzeniach z Androidem MAJ zastosuj dowolny lub wszystkie 4 stany uśpienia, określone w Zaawansowanych Configuration and Power Interface (ACPI).

Jeśli implementacje urządzeń stosują stany zasilania S4 określone w ACPI:

• [C-1-1] MUSI wejść w ten stan tylko po wykonaniu wyraźnego działania przez użytkownika przełączyć urządzenie w stan nieaktywny (np. przez zamknięcie pokrywy, która fizycznie części urządzenia lub wyłączenia pojazdu lub telewizora) i przed użytkownik ponownie aktywuje urządzenie (np.otwierając pokrywę lub obracając pojazd). lub telewizor).

Jeśli implementacje urządzeń stosują stany zasilania S3 zdefiniowane w ACPI:

• [C-2-1] MUSI spełniać powyższe wymagania C-1-1 lub MUSI wprowadzać stan S3 tylko w przypadku aplikacje nie potrzebują zasobów systemowych (np. ekranu czy procesora).

  I na odwrót: MUSI wyjść ze stanu S3, gdy aplikacje innych firm wymagają wywołania zasobów systemowych, jak opisano w tym pakiecie SDK.

  Gdy na przykład aplikacje innych firm proszą o zachowanie ekranu włącz do FLAG_KEEP_SCREEN_ON lub nie wyłączaj procesora PARTIAL_WAKE_LOCK, urządzenie NIE MOŻE przejść w stan S3, chyba że zgodnie z opisem w C-1-1 użytkownik podjął wyraźne działanie, aby umieścić urządzenie nieaktywny. I na odwrót – w czasie, gdy zadanie, które aplikacje innych firm aktywowana jest implementacja za pomocą harmonogramu JobScheduler lub zostaje uruchomiona usługa Komunikacja w chmurze Firebase (FCM) dostarczone do aplikacji innych firm, urządzenie MUSI wyjść ze stanu S3, chyba że użytkownik ustawił urządzenie w stanie nieaktywnym. Te informacje nie są wyczerpujące przykłady, a AOSP wdraża szeroko zakrojone sygnały wybudzenia, z tego stanu.

8.4. Rachunkowanie zużycia energii

Dokładniejsze liczenie i raportowanie zużycia energii pozwala dla deweloperów aplikacji, zarówno zachęty, jak i narzędzia do optymalizacji zużycia energii dla każdej aplikacji.

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANY jest profil zasilania dla każdego komponentu. określa bieżącą wartość wykorzystania dla każdego elementu sprzętowego i przybliżone zużycie baterii przez zgodnie z opisem w witrynie Android Open Source Project.
• [C-SR-2] Zdecydowanie ZALECANE jest raportowanie wszystkich wartości poboru energii w miliiamperach godz. (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 za pośrednictwem Implementacja modułu jądra uid_cputime.
• [C-SR-4] Zdecydowanie ZALECANE jest udostępnienie tego zużycia energii przez adb shell dumpsys batterystats należy użyć polecenia powłoki do dewelopera aplikacji.
• MUSI być przypisana do komponentu sprzętowego, jeśli nie jest w stanie tego zrobić. przypisywanie aplikacji zużycie energii przez komponenty sprzętowe.

8.5. Stała skuteczność

W przypadku zaawansowanych aplikacji o długiej wydajności wydajność może z powodu innych aplikacji działających w tle lub spowalniania procesora z powodu limitów temperatury. Android ma interfejsy programistyczne, dzięki którym jeśli urządzenie ma odpowiednie funkcje, aplikacja główna na pierwszym planie może zażądać, by optymalizuje alokację zasobów, aby dostosować się do takich wahań.

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo przekazywać informacje o obsłudze trybu trwałej wydajności przez PowerManager.isSustainedPerformanceModeSupported() API.

• 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ć aplikacji najwyższego poziomu na pierwszym planie spójny poziom wydajności przez co najmniej 30 minut, jeśli aplikacja o to poprosi.
• [C-1-2] MUSI spełniać warunki Window.setSustainedPerformanceMode() API i innych powiązanych interfejsów API.

Jeśli implementacje urządzeń obejmują co najmniej 2 rdzenie procesora, są to:

• POWINIEN podać co najmniej 1 rdzeń wyłączny, który można zarezerwować dla platformy najwyższego poziomu aplikacji działających na pierwszym planie.

Jeśli implementacje urządzeń obsługują zarezerwowanie jednego wyłącznego rdzenia dla aplikacji działających na pierwszym planie, to:

• [C-2-1] MUSI zgłosić się za pomocą Process.getExclusiveCores() Metoda interfejsu API określa numery identyfikacyjne wyłącznych rdzeni, które można zarezerwować przez aplikację na pierwszym planie.
• [C-2-2] NIE MOŻE zezwalać na żadne procesy w przestrzeni użytkownika z wyjątkiem sterowników urządzenia używanych przez aplikację do działania na wyłącznych rdzeniach, ale MOGĄ umożliwić korzystanie jądra systemu, aby działać zgodnie z potrzebami.

Jeśli implementacje urządzeń nie obsługują rdzeni na wyłączność, są to:

• [C-3-1] MUSI zwracać pustą listę przez funkcję Process.getExclusiveCores() API.

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniach:

• [C-0-1] MUSISZ wdrożyć model zabezpieczeń, który będzie spójny z modelem zabezpieczeń platformy Androida zdefiniowanym w Dokument referencyjny dotyczący zabezpieczeń i uprawnień znajdziesz w sekcji dotyczącej interfejsów API w dokumentacji dla programistów aplikacji na Androida.

• [C-0-2] MUSI obsługiwać instalację samodzielnie podpisanego dokumentu bez konieczności uzyskania dodatkowych pozwoleń/certyfikatów ze strony osób trzecich/organów.

Jeśli implementacje urządzeń zadeklarują android.hardware.security.model.compatible to:

• [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 modelu ról Androida zgodnie z definicją podaną w dokumentacji dla deweloperów aplikacji na Androida. Mówiąc konkretnie, MUSI wymuszać wszystkie uprawnienia i role zdefiniowane w sposób dokumentacja pakietu SDK; żadne uprawnienia ani role nie mogą zostać pominięte, zmienione lub zignorowano.

• MOŻE dodać więcej uprawnień, pod warunkiem że nowe ciągi identyfikatorów uprawnień nie znajdują się w przestrzeni nazw android.\*.

• [C-0-2] Uprawnienia z wartością protectionLevel o wartości PROTECTION_FLAG_PRIVILEGED MOŻE być przyznawana tylko aplikacjom wstępnie zainstalowanym w ścieżkach z podwyższonymi uprawnieniami obrazu systemu (oraz APEX) i należących do podzbioru uprawnień poszczególnych aplikacji umieszczonych na liście dozwolonych. Implementacja AOSP spełnia to wymaganie, czytając i przestrzegając dostęp do wszystkich aplikacji z listy dozwolonych, etc/permissions/ i użycie ścieżki system/priv-app jako parametru ścieżki z podwyższonymi uprawnieniami.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Uprawnienia z poziomem ochrony „Niebezpieczne” to uprawnienia w czasie działania. Aplikacje z: targetSdkVersion > 22 wysyłanie o niej prośby w czasie działania.

Implementacje na urządzeniach:

• [C-0-3] MUSI wyświetlić specjalny interfejs, aby użytkownik mógł zdecydować czy przyznać żądane uprawnienia w czasie działania, a także interfejs użytkownika do zarządzania uprawnieniami czasu działania.

• [C-0-5] NIE MOŻE przyznawać aplikacjom żadnych uprawnień w czasie działania, chyba że:

  • są instalowane w momencie wysyłki urządzenia ORAZ

  • Zgodę użytkownika można uzyskać przed złożeniem wniosku korzysta z tych uprawnień,

    LUB

  • Przyznano uprawnienia w czasie działania aplikacji przez domyślną zasadę przyznawania uprawnień lub pełnienia roli na platformie.

• [C-0-6] MUSI przyznać uprawnienie android.permission.RECOVER_KEYSTORE tylko w przypadku aplikacji systemowych rejestrujących prawidłowo zabezpieczonego agenta odzyskiwania. O poprawnie zabezpieczony agent odzyskiwania jest zdefiniowany jako agent oprogramowania na urządzeniu; która synchronizuje się ze zdalnej pamięci masowej poza urządzeniem, która zawiera bezpieczny sprzęt z odpowiednią ochroną lub silniejszym opisane w Usługa Google Cloud Key Vault Service aby zapobiec atakom 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 wysyła żądanie danych o lokalizacji lub 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 art. 9.8.8.
  • Informacje, które mogą służyć do określenia lub oszacowania lokalizacja (np. identyfikator SSID, BSSID, identyfikator komórkowy lub lokalizacja sieci, urządzenie, z którym jest połączone urządzenie).
  • 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 na dostęp do dane o lokalizacji czy aktywności fizycznej.
• [C-0-9] MUSI przyznawać uprawnienia w czasie działania TYLKO aplikacji, która zawiera wystarczających uprawnień zgodnie z opisem w pakiecie SDK. Przykład: Menedżer połączeń#getServiceState wymaga android.permission.ACCESS_FINE_LOCATION).

Jedynym wyjątkiem od powyższych właściwości dotyczących dostępu do lokalizacji na Androidzie są te, aplikacje nie mające dostępu do Lokalizacji w celu określenia lub ustalania lokalizacji użytkownika; a konkretnie:

• Gdy aplikacje mają uprawnienie RADIO_SCAN_WITHOUT_LOCATION.
• W celach związanych z konfiguracją urządzenia, gdzie aplikacje systemowe przechowują Uprawnienie 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ć przyznanych aplikacji, chyba że:

  • Plik APK aplikacji znajduje się na partycji systemowej.
  • Użytkownik przypisuje rolę powiązaną z zasobem hardRestricted uprawnienia aplikacji.
  • Instalator przydziela aplikacji hardRestricted.
  • Aplikacja otrzymuje uprawnienia hardRestricted w wcześniejszej wersji Androida.

• [C-0-11] Aplikacje z uprawnieniem softRestricted MUSZĄ mieć tylko ograniczone dostępu i NIE MOŻE mieć pełnego dostępu, dopóki nie zostanie dodana do listy dozwolonych zgodnie z opisem w pakiet SDK, w przypadku którego dla każdej usługi softRestricted definiowany jest pełny i ograniczony dostęp; (np. READ_EXTERNAL_STORAGE).

• [C-0-12] NIE MOŻE udostępniać żadnych niestandardowych funkcji ani interfejsów API do omijania ograniczenia uprawnień określone w setPermissionPolicy i setPermissionGrantState API.

• [C-0-13] MUSI używać interfejsów API AppOpsManager do rejestrowania i śledzenia każdy programowy dostęp do danych chronionych niebezpiecznymi uprawnieniami Aktywność i usługi Androida.

• [C-0-14] MUSI przypisywać role tylko tym aplikacjom, których funkcje spełniać wymagania roli.

• [C-0-15] NIE MOŻE definiować ról, które są duplikatami lub funkcjami nadzorowania ról zdefiniowanych przez platformę.

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

• [C-1-1] NIE MOŻE mieć następujących uprawnień przyznanych dyskretnie przez administrator:
  • 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ń pozwalają użytkownikom na wybór aplikacji, nad innymi aplikacjami, które obsługują ACTION_MANAGE_OVERLAY_PERMISSION to:

• [C-2-1] MUSI mieć pewność, że wszystkie działania z filtrami intencji dla argumentu ACTION_MANAGE_OVERLAY_PERMISSION mają ten sam ekran interfejsu niezależnie od tego, aplikacja inicjująca zawarte w nim informacje.

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

• [C-3-1] MUSI wyświetlać wyłączenie odpowiedzialności podczas konfiguracji w pełni zarządzanego urządzenia (konfiguracji właściciela urządzenia), z którego wynika, że administrator IT ma możliwość Zezwalaj aplikacjom na kontrolowanie ustawień telefonu, w tym mikrofonu, aparatu i oraz opcje kontynuowania lub zakończenia konfiguracji, WYŁĄCZNIE 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 urządzeń sekcji „9.8.6 Dane na poziomie systemu operacyjnego i otoczenia oraz 9.8.15 Implementacje interfejsu API w trybie piaskownicy”.

Jeśli implementacje urządzeń obejmują domyślną aplikację do obsługi VoiceInteractionService to:

• [C-5-1] NIE MOŻE przyznawać opcji ACCESS_FINE_LOCATION jako domyślnej w tym przypadku aplikacji.

9.2. UID i izolacja procesów

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać aplikację na Androida model piaskownicy, w którym każda aplikacja działa jako unikalny identyfikator UID w stylu Unixstyle, i w ramach osobnego procesu.
• [C-0-2] MUSI obsługiwać wiele aplikacji co ten sam identyfikator użytkownika Linuksa, o ile aplikacje są prawidłowo podpisane i skonstruowane zgodnie z definicją Informacje o zabezpieczeniach i uprawnieniach

9.3. Uprawnienia systemu plików

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać dostęp do plików na Androidzie model uprawnień określony w Informacje o zabezpieczeniach i uprawnieniach

9.4. Alternatywne środowiska wykonawcze

Implementacje na urządzeniach MUSZĄ zachowywać spójność zabezpieczeń Androida modelu uprawnień, nawet jeśli obejmuje on środowiska wykonawcze, które uruchamiają się aplikacje korzystające z innego oprogramowania lub technologii niż plik wykonywalny Dalvik Format lub kod natywny. Krótko mówiąc:

• [C-0-1] Alternatywne środowiska wykonawcze MUSZĄ być aplikacjami na Androida i zachować zgodność ze standardowym modelem zabezpieczeń Androida, jak opisano w innym miejscu. w sekcji 9.

• [C-0-2] Alternatywne środowiska wykonawcze NIE MOGĄ mieć dostępu do zasobów chronione przez uprawnienia, które nie są wymagane w środowisku AndroidManifest.xml środowiska wykonawczego za pośrednictwem modułu <uses-permission> .

• [C-0-3] Alternatywne środowiska wykonawcze NIE MOGĄ zezwalać aplikacjom na korzystanie z funkcje chronione uprawnieniami Androida ograniczonymi do aplikacji systemowych.

• [C-0-4] Alternatywne środowiska wykonawcze MUSZĄ być zgodne z modelem piaskownicy Androida i zainstalowanych aplikacji korzystających z alternatywnego środowiska wykonawczego NIE MOŻE ponownego wykorzystywania piaskownicy dowolnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida korzystających ze wspólnego identyfikatora użytkownika i certyfikatu podpisywania.

• [C-0-5] Alternatywne środowiska wykonawcze NIE MOGĄ uruchamiać się z zastosowaniem, uwierzytelniać ani przyznawać im dostępu dostęp do piaskownicy odpowiadającej innym aplikacjom na Androida.

• [C-0-6] Alternatywne środowiska wykonawcze NIE MOGĄ być uruchamiane za pomocą, przyznane ani przyznane innym aplikacjom jakichkolwiek uprawnień superużytkownika (roota) identyfikatora użytkownika.

• [C-0-7] Jeśli pliki .apk alternatywnych środowisk wykonawczych są dołączone do pliku obraz systemu przedstawiający implementacje urządzenia, MUSI być podpisany znakiem odrębnego za pomocą klucza używanego do podpisywania innych aplikacji dołączonych do urządzenia implementacji.

• [C-0-8] Podczas instalowania aplikacji alternatywne środowiska wykonawcze MUSZĄ uzyskać zgody użytkownika na uprawnienia Androida używane przez aplikację.

• [C-0-9] Gdy aplikacja musi użyć zasobu urządzenia do które są dostępne w Androidzie (takie jak Aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI informować użytkownika, że aplikacja będzie mogła dostępu do tego zasobu.

• [C-0-10] Gdy środowisko wykonawcze nie rejestruje aplikacji funkcji w ten sposób, środowisko wykonawcze MUSI zawierać listę wszystkich uprawnień jest wspierane przez środowisko wykonawcze podczas instalowania dowolnej aplikacji, która z niego korzysta.

• Alternatywne środowiska wykonawcze POWINNO instalować aplikacje za pomocą interfejsu PackageManager w osobnych piaskownicy Androida (identyfikatory użytkowników Linuksa itp.).

• Alternatywne środowiska wykonawcze MOGĄ udostępniać jedną piaskownicę Androida wspólną dla wszystkich korzystających z alternatywnego środowiska wykonawczego.

9.5. Obsługa wielu użytkowników

Android zapewnia obsługę wielu użytkowników i zapewnia pełną izolację użytkowników oraz klonowanie profili użytkowników za pomocą częściowa izolacja(tj. pojedynczy dodatkowy profil użytkownika typu android.os.usertype.profile.CLONE).

• Implementacje na urządzeniach MOGĄ BYĆ, ale NIE NALEŻY włączać obsługi wielu użytkowników, jeśli korzystają nośnik wymienny jako podstawowej pamięci zewnętrznej.

Jeśli implementacje urządzeń obejmują obsługę wielu użytkowników:

• [C-1-2] MUSI zastosować zabezpieczenia dla każdego użytkownika zgodny z modelem zabezpieczeń platformy Androida zdefiniowanym w Dokument referencyjny dotyczący zabezpieczeń i uprawnień w interfejsach API.
• [C-1-3] MUSI mieć oddzielną, wydzieloną pamięć współdzieloną aplikacji /sdcard) dla każdej instancji użytkownika.
• [C-1-4] MUSI zapewnić, że aplikacje należące do i uruchomione w imieniu dany użytkownik nie może wyświetlać, odczytywać ani zapisywać plików należących do innych użytkowników, nawet jeśli dane obu użytkowników są przechowywane w tym samym woluminie lub systemie plików.
• [C-1-5] MUSI szyfrować zawartość karty SD, gdy jest włączona obsługa 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ń korzystają z nośników wymiennych do obsługi interfejsów API pamięci zewnętrznej. Implementacje urządzeń mobilnych uniemożliwiają czytelność multimediów na komputerze będzie musiał przejść na MTP lub podobny system, dostęp do danych bieżącego użytkownika.

Jeśli implementacje urządzeń obejmują obsługę wielu użytkowników, wszyscy użytkownicy oprócz użytkowników utworzonych specjalnie do uruchamiania instancji podwójnych do tej samej aplikacji:

• [C-2-1] MUSI mieć oddzielną, wydzieloną pamięć współdzieloną aplikacji (inaczej /sdcard) dla każdej instancji użytkownika.
• [C-2-2] MUSI zapewnić, że aplikacje należące do i uruchomione na w imieniu danego użytkownika nie może wyświetlać, odczytywać ani zapisywać plików należących do użytkownika przez jakiegokolwiek innego użytkownika, nawet jeśli dane obu użytkowników są przechowywane w tym samym woluminu ani systemu plików.

Implementacje na urządzeniach MOGĄ utworzyć pojedynczy dodatkowy profil użytkownika typu android.os.usertype.profile.CLONE względem głównego użytkownika (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ą przedstawiane w tym samym czasie w programie uruchamiającym i wyświetlają się w tym samym widoku ostatnich danych. Można to na przykład wykorzystać, aby użytkownik mógł zainstalować 2 osobne instancji jednej aplikacji na urządzeniu z 2 kartami SIM.

Jeśli po wdrożeniu na urządzeniach zostanie utworzony dodatkowy profil użytkownika omówiony powyżej, to:

• [C-3-1] MUSI zapewniać dostęp tylko do pamięci lub danych, które już są dostępne dla nadrzędnego profilu użytkownika lub należy do niego dodatkowy profil użytkownika.
• [C-3-2] NIE MOŻE mieć tego profilu służbowego.
• [C-3-3] MUSI mieć wyizolowane prywatne katalogi danych aplikacji od katalogu nadrzędnego konto użytkownika.
• [C-3-4] NIE MOŻE zezwalać na utworzenie dodatkowego profilu użytkownika, jeśli jest urządzeniem obsługiwanym przez właściciela (patrz sekcja 3.9.1) lub zezwalającym właścicielowi urządzenia obsługi administracyjnej bez usuwania dodatkowego profilu użytkownika.

Jeśli po wdrożeniu na urządzeniach zostanie utworzony dodatkowy profil użytkownika omówiony powyżej, to:

• [C-4-1] MUSI zezwalać na poniższe intencje pochodzące z dodatkowych który ma być obsługiwany przez aplikacje głównego użytkownika na urządzeniu:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] MUSI dziedziczyć wszystkie ograniczenia zasad dotyczących urządzeń i wybrane użytkownik niebędący użytkownikiem restrictions(list below) został zastosowany do głównego użytkownika urządzenia do tego dodatkowego profilu użytkownika.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] MUSI zezwalać tylko na zapisywanie kontaktów z tego dodatkowego profilu przez z następującymi intencjami:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] NIE MOŻE uruchamiać synchronizacji kontaktów dla aplikacji działających w ten dodatkowy profil użytkownika.

• [C-4-5] MUSI zezwalać tylko na aplikacje w dodatkowym profilu, które mają działania programu uruchamiającego w celu uzyskania dostępu do kontaktów, które są już dostępne dla nadrzędnym profilu użytkownika.

9.6 Ostrzeżenie SMS-a specjalnego

Android obsługuje ostrzeganie użytkowników przed SMS-em premium. SMS-y specjalne to SMS-y wysyłane do usługi zarejestrowanej u operatora, obciążanie użytkownika.

Jeśli implementacje urządzeń zadeklarują obsługę android.hardware.telephony, one:

• [C-1-1] MUSI ostrzegać użytkowników przed wysłaniem SMS-a na numery identyfikowane przez wyrażenia regularne zdefiniowane w /data/misc/sms/codes.xml zapisany na urządzeniu. Dotychczasowy projekt Android Open Source zapewnia implementacji, która spełnia to wymaganie.

9.7. Funkcje zabezpieczeń

Implementacje urządzeń MUSZĄ zapewnić zgodność z funkcjami zabezpieczeń ją jądra i platformę, jak opisano poniżej.

Piaskownica Androida obejmuje funkcje korzystające z ulepszonych zabezpieczeń Linuksa (SELinux) obowiązkowej kontroli dostępu (MAC), piaskownica seccomp i inne zabezpieczeń dostępnych w jądrze Linuksa. Implementacje na urządzeniach:

• [C-0-1] MUSI zachować zgodność z istniejącymi aplikacjami, nawet jeśli SELinux i wszelkie inne funkcje zabezpieczeń są w niektórych wersjach Androida. platformy.
• [C-0-2] NIE MOŻE mieć widocznego interfejsu użytkownika, jeśli funkcja zabezpieczeń została wykryta i zablokowana wdrożony poniżej platformy Android, ale MOŻE mieć widoczny interfejs użytkownika gdy niezablokowane naruszenie zabezpieczeń skutkuje udanym wykorzystaniem ataku.
• [C-0-3] NIE MOŻE wymuszać stosowania funkcji SELinux ani żadnych innych funkcji zabezpieczeń poniżej platformy Androida konfigurowanej dla użytkownika lub dewelopera aplikacji.
• [C-0-4] NIE MOŻE zezwalać na aplikację, która może mieć wpływ na inną aplikację interfejs API (taki jak interfejs Device Administration API) do konfigurowania zasad co narusza zgodność.
• [C-0-5] MUSI podzielić platformę multimediów na wiele procesów, każdemu procesowi można ściślej przyznać dostęp opisany na stronie projektu Android Open Source.
• [C-0-6] MUSI wdrożyć mechanizm piaskownicy aplikacji w jądrze który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnej zasady lub wielowątkowości. Ten projekt spełnia te warunki: wymaga włączenia seccomp-BPF z grupą wątków synchronizacji (TSYNC) zgodnie z opisem. w sekcji Konfiguracja jądra witryny source.android.com.

Integralność jądra i funkcje samoochrony są integralną częścią Androida. zabezpieczeń. Implementacje na urządzeniach:

• [C-0-7] MUSI wdrożyć mechanizmy ochrony przed przepełnieniem bufora stosu jądra. Przykłady takich mechanizmów: CC_STACKPROTECTOR_REGULAR i CONFIG_CC_STACKPROTECTOR_STRONG
• [C-0-8] MUSI wdrożyć rygorystyczne zabezpieczenia pamięci jądra tam, gdzie plik wykonywalny kod jest tylko do odczytu, dane tylko do odczytu – nie wykonywalny i niemożliwy do zapisu; dane, które można zapisać, nie są wykonalne (np. CONFIG_DEBUG_RODATA lub CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] MUSI implementować statyczny i dynamiczny rozmiar obiektu – granice sprawdzania kopii między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY) w przypadku urządzeń, które oryginalnie zostały wysłane na poziomie interfejsu API 28 lub więcej.
• [C-0-10] Podczas wykonywania NIE MOŻE wykonywać pamięci w przestrzeni użytkownika w trybie jądra (np. sprzętowy PXN lub emulowany przez CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach oryginalnie produkt był wysyłany przy użyciu interfejsu API na poziomie 28 lub wyższym.
• [C-0-11] NIE MOŻE odczytywać ani zapisywać pamięci przestrzeni użytkownika w jądro systemu poza normalnymi interfejsami API z dostępem do kopii zapasowej (np. sprzętowym numerem PAN lub emulacja przez CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które zostały pierwotnie wysłane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-12] MUSI wdrożyć izolację tabel stron jądra, jeśli sprzęt podatna na atak CVE-2017-5754 na wszystkich urządzeniach pierwotnie wysyłanych z poziomem API 28 lub więcej (np. CONFIG_PAGE_TABLE_ISOLATION lub CONFIG_UNMAP_KERNEL_AT_EL0).

• [C-0-13] NALEŻY wdrożyć wzmacnianie prognozowania gałęzi, jeśli sprzęt jest podatna na atak CVE-2017-5715 na wszystkich urządzeniach pierwotnie wysyłanych z poziomem API 28 lub więcej (np. CONFIG_HARDEN_BRANCH_PREDICTOR).

• [C-SR-1] Zdecydowanie ZALECANE jest zachowanie danych jądra który jest zapisywany tylko podczas inicjowania oznaczony jako tylko do odczytu po zainicjowanie (np. __ro_after_init).

• [C-SR-2] Zdecydowanie ZALECANE jest zastosowanie losowego układu kodu jądra oraz pamięci i unikać ekspozycji, które mogłyby zaszkodzić randomizacji (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 integracji procesu sterowania (CFI) w jądro 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 niewyłączanie integracji z aplikacją Control-Flow Integrity (CFI), Stos wywołań cieni (SCS) lub sanitarizacja przekroju liczby całkowitej (IntSan) są włączone komponenty, w których ta funkcja jest włączona.

• [C-SR-5] Zdecydowanie ZALECANE jest włączenie CFI, SCS i IntSan w każdym dodatkowe, związane z bezpieczeństwem komponenty przestrzeni użytkownika opisane w CFI oraz IntSan

• [C-SR-6] Zdecydowanie ZALECANE jest włączenie inicjowania stosu w jądrze. aby zapobiec użyciu niezainicjowanych zmiennych lokalnych (CONFIG_INIT_STACK_ALL lub CONFIG_INIT_STACK_ALL_ZERO). Ponadto implementacje urządzeń NIE POWINNY zakładać wartości używanej przez kompilatora do zainicjować zasoby lokalne.

• [C-SR-7] Zdecydowanie ZALECANE jest włączenie inicjowania stosu w jądrze. aby zapobiec używaniu niezainicjowanych alokacji sterty (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), a NIE POWINNO przyjmować wartości używanej przez jądro zainicjuje te przydziały.

Jeśli implementacji na urządzeniach korzysta z jądra Linuksa, który obsługuje 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. Brak trybu mniej rygorystycznego domeny, w tym domeny charakterystyczne dla danego urządzenia lub dostawcy.
• [C-1-4] NIE MOŻE modyfikować, pomijać ani zastępować obecnych reguł zezwalających w folderze system/sepolicy udostępnionym na nadrzędnym kanale open source Androida Projekt (AOSP) i zasada MUSZĄ skompilować wszystkie obecne reguły typu „Nigdy nie zezwalaj”, zarówno w domenach AOSP SELinux, jak i tych specyficznych dla urządzeń/dostawców.
• [C-1-5] MUSI uruchamiać aplikacje innych firm kierowane na interfejs API na poziomie 28 lub wyższym w piaskownicy SELinux z ograniczeniami SELinux dla poszczególnych aplikacji w katalogu prywatnych aplikacji.
• POWINNY jest zachować domyślną zasadę SELinux obowiązującą w systemie/zasadzie sekwencji. folderu nadrzędnego projektu Android Open Source, a do tego dla ich własnej konfiguracji.

Jeśli implementacje urządzeń wykorzystują jądro innego niż Linux lub Linux bez SELinux, one:

• [C-2-1] MUSI używać obowiązkowego systemu kontroli dostępu, który odpowiednika SELinux.

Jeśli implementacje urządzeń korzystają z urządzeń I/O obsługujących DMA:

• [C-SR-9] Zdecydowanie ZALECANE jest izolowanie każdego urządzenia wejścia-wyjścia obsługującego DMA, przy użyciu IOMMU (np. ARM SMMU).

Android zawiera wiele zaawansowanych funkcji obrony, które są wbudowane w urządzenie zabezpieczeń. Oprócz tego Android skupia się na redukcji kluczowych klas typowych błędów. które wpływają na niską jakość i bezpieczeństwo.

Aby ograniczyć błędy w pamięci, implementacje urządzeń:

• [C-SR-10] Zdecydowanie ZALECANE jest przetestowanie ich z wykorzystaniem błędu pamięci przestrzeni użytkownika. narzędzi do wykrywania takich jak MTE dla urządzeń z architekturą ARMv9, HWASan dla urządzeń ARMv8+ i ASan w przypadku innych typów urządzeń.
• [C-SR-11] Zdecydowanie ZALECANE jest przetestowanie z wykorzystaniem błędu pamięci jądra systemu takich jak KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS), Urządzenia ARMv9, CONFIG_KASAN_SW_TAGS dla urządzeń ARMv8 lub CONFIG_KASAN_GENERIC w przypadku innych typów urządzeń).
• [C-SR-12] Zdecydowanie ZALECANE jest korzystanie z narzędzi do wykrywania błędów pamięci w takich jak MTE, GWP-ASan i KFENCE.

Jeśli implementacje urządzeń korzystają z TEE opartego na Arm TrustZone:

• [C-SR-13] Zdecydowanie ZALECANE jest używanie standardowego protokołu pamięci udostępniania danych między Androidem a TEE, jak np. platforma Armware Framework Armv8-A (FF-A).
• [C-SR-14] Zdecydowanie ZALECANE jest ograniczenie dostępu zaufanych aplikacji tylko do użytkowników, dostęp do pamięci, która została mu udostępniona za pomocą powyższego protokołu. Jeśli urządzenie obsługuje poziom wyjątku Arm S-EL2, powinno być egzekwowane przez menedżera bezpiecznego partycji. W przeciwnym razie wymuszane przez system TEE OS.

Technologia bezpieczeństwa pamięci to technologia, która łagodzi co najmniej: klasy błędów z wysokim prawdopodobieństwem (> 90%) w aplikacjach, które korzystają z funkcji android:memtagMode Opcja pliku manifestu:

• przepełnienie bufora sterty
• użyj po bezpłatnym
• podwójne wolne
• wolny (wild wolne) (bez wskaźnika niemalloc)

Implementacje na urządzeniach:

• [C-SR-15] Zdecydowanie ZALECANE jest ustawienie ro.arm64.memtag.bootctl_supported

Jeśli implementacje urządzeń ustawiają właściwość systemową ro.arm64.memtag.bootctl_supported ma wartość prawda, to:

• [C-3-1] MUSI zezwalać właściwości systemowej arm64.memtag.bootctl na zaakceptowanie rozdzielana przecinkami lista poniższych wartości z pożądanym efektem zostanie zastosowany przy następnym ponownym uruchomieniu:

  • memtag: włączono technologię bezpieczeństwa pamięci zdefiniowaną powyżej
  • memtag-once: technologia zabezpieczeń pamięci (zgodnie z definicją powyżej) to jest tymczasowo włączony i jest automatycznie wyłączany, gdy, następnym razem Uruchom ponownie
  • memtag-off: technologia Bezpieczeństwo pamięci zgodnie z definicją powyżej jest wyłączona

• [C-3-2] MUSI umożliwiać użytkownikowi powłoki ustawienie arm64.memtag.bootctl.

• [C-3-3] MUSI zezwalać dowolny proces na odczyt arm64.memtag.bootctl.

• [C-3-4] MUSI ustawić arm64.memtag.bootctl na obecny stan podczas uruchamiania MUSI też aktualizować właściwość, jeśli implementacja urządzenia umożliwia zmianę stanu bez zmiany właściwości systemowej.

• [C-SR-16] Zdecydowanie ZALECANE jest włączenie ustawienia dla programistów pozwalającego memtag-on. W przypadku zgodnego programu rozruchowego Android Open Source Project spełnia powyższe wymagania dzięki Protokół programu rozruchowego MTE.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

9.8. Prywatność

9.8.1. Historia wykorzystania

Android przechowuje historię wyborów użytkownika i zarządza nią przez 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 14-dniowego okresu przechowywania jako skonfigurowany domyślnie w implementacji AOSP.

Android przechowuje zdarzenia systemowe za pomocą tagów StatsLog i zarządza taką historią za pomocą StatsManager oraz Systemowy interfejs API IncidentManager.

Implementacje na urządzeniach:

• [C-0-2] MUSI zawierać tylko pola oznaczone symbolem DEST_AUTOMATIC w raport o zdarzeniu utworzony przez klasę System API IncidentManager.
• [C-0-3] NIE MOŻE używać identyfikatorów zdarzeń systemowych do rejestrowania innych zdarzeń niż jest to opisane w StatsLog Dokumenty pakietu SDK. Jeśli zostaną zarejestrowane dodatkowe zdarzenia systemowe, MOGĄ one używać parametru różnych atomów z zakresu od 100 000 do 200 000.

9.8.2. Nagrywam

Implementacje na urządzeniach:

• [C-0-1] NIE WOLNO ładować wstępnie ani rozprowadzać komponentów oprogramowania, które są wysyłać informacje prywatne użytkownika (np. o naciśnięciach klawiszy czy tekście wyświetlanym na ekranu lub zgłaszania błędów) z urządzenia bez zgody użytkownika lub o trwających powiadomieniach.

• [C-0-2] MUSI wyświetlać ostrzeżenie użytkownika i uzyskać jego wyraźną zgodę dzięki której wszelkie poufne informacje wyświetlane na ekranie użytkownika być rejestrowane za każdym razem podczas sesji, ekran jest uruchamiany przez MediaProjection.createVirtualDisplay() VirtualDeviceManager.createVirtualDisplay(), lub zastrzeżone interfejsy API.

• [C-0-3] MUSI mieć trwające powiadomienie do użytkownika podczas przesyłania ekranu lub nagrywanie ekranu jest włączone. AOSP spełnia to wymaganie, wyświetlając ikonę powiadomienia o trwającej aktywności na pasku stanu.

• [C-SR-1] Zdecydowanie ZALECANE jest wyświetlanie ostrzeżenia użytkownika, które dokładnie opisuje ten sam komunikat co w AOSP, ale MOŻNA zmienić, jeśli ostrzega użytkownika, że wszelkie poufne informacje zostanie przechwycony.

• [C-0-4] NIE MOŻE zapewniać użytkownikom możliwości wyłączenia w przyszłości użytkownik wyraża zgodę na zrzut ekranu, chyba że sesja zostanie uruchomiona przez aplikacja systemowa, na którą użytkownik zezwolił associate() z android.app.role.COMPANION_DEVICE_APP_STREAMING lub android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING profil urządzenia.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli implementacje urządzeń obejmują funkcje systemu, które: rejestruje treści wyświetlane na ekranie i/lub nagrywa strumień audio odtwarzane na urządzeniu innym niż za pomocą interfejsu System API ContentCaptureService lub innych zastrzeżonych środków opisanych w Artykuł 9.8.6 Dane na poziomie systemu operacyjnego i dane otoczenia:

• [C-1-1] MUSI mieć aktywne powiadomienie o tym, że jest włączona i aktywnie przechwytuje/rejestruje.

Jeśli implementacje urządzeń zawierają włączony od razu komponent, który może 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 pamięci trwałej na urządzeniu ani przesyłać poza Dotyczy to nagranych nieprzetworzonych plików dźwiękowych lub dowolnego formatu, który można przekonwertować z powrotem na oryginalnej ścieżki dźwiękowej lub zbliżonym faksem, chyba że użytkownik wyraził na to wyraźną zgodę.

„Wskaźnik mikrofonu” oznacza wyświetlenie na ekranie, które jest stale widoczne nie może być zasłonięta. Użytkownicy rozumieją, że mikrofon jest włączony. (przez niepowtarzalny tekst, kolor, ikonę lub dowolną kombinację).

„Wskaźnik aparatu” czyli wyświetlenia na ekranie, które są stale widoczne dla użytkownika i nie może być zasłonięta (dla użytkowników jest zrozumiała, że kamera jest w użyciu). (za pomocą niepowtarzalnego tekstu, koloru, ikony lub innej kombinacji).

Po wyświetleniu pierwszej sekundy wskaźnik może się zmienić, np.: zmniejsza się i nie musi być wyświetlana w pierwotnej formie zrozumiano.

Wskaźnik mikrofonu może zostać połączony z aktywnie wyświetlaną kamerą. pod warunkiem, że tekst, ikony lub kolory wskazują użytkownikowi, zaczęło się korzystanie z mikrofonu.

Wskaźnik aparatu może zostać połączony z aktywnie wyświetlanym mikrofonem pod warunkiem, że tekst, ikony lub kolory wskazują użytkownikowi, zaczęło się korzystanie z aparatu.

Jeśli implementacje urządzenia zadeklarują android.hardware.microphone:

• [C-SR-1] Zdecydowanie ZALECANE jest wyświetlanie wskaźnika mikrofonu, gdy aplikacja ma dostęp do danych dźwiękowych z mikrofonu, ale nie, gdy jest dostęp tylko dla: HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje pełniące role wymienione w sekcji 9.1 Uprawnienia z identyfikatorem CDD [C-3-X]. .
• [C-SR-2] Zdecydowanie ZALECANE jest wyświetlanie listy Najnowsze i Aktywne. aplikacje używające mikrofonu w odpowiedzi PermissionManager.getIndicatorAppOpUsageData() i wszelkie informacje o atrybucji wiadomości, które są z nimi powiązane.
• [C-SR-3] Zdecydowanie ZALECANE jest, aby nie ukrywać wskaźnika mikrofonu w aplikacje systemowe z widocznymi interfejsami lub bezpośrednią interakcją użytkownika.

Jeśli implementacje urządzenia zadeklarują android.hardware.camera.any:

• [C-SR-4] Zdecydowanie ZALECANE jest wyświetlanie wskaźnika aparatu, gdy aplikacja jest dostęp do danych kamery na żywo, ale nie wtedy, gdy dostęp do kamery jest uzyskiwany tylko wtedy, gdy jest używany przez aplikacje pełniące role wymienione w artykule 9.1 Uprawnienia dotyczące CDD [C-3-X].
• [C-SR-5] Zdecydowanie ZALECANE jest wyświetlanie ostatnich i aktywnych aplikacji przy użyciu aparat zwrócony z urządzenia PermissionManager.getIndicatorAppOpUsageData(), wraz z powiązanymi z nimi wiadomościami o atrybucji.
• [C-SR-6] Zdecydowanie ZALECANE jest, aby nie ukrywać wskaźnika aparatu systemu. z widocznymi interfejsami lub bezpośrednią interakcją z użytkownikiem.

9.8.3 Łączność

Jeśli urządzenia są wyposażone w port USB z obsługą trybu urządzenia peryferyjnego USB, one:

• [C-1-1] MUSI wyświetlić interfejs użytkownika z prośbą o zgodę przed z możliwością uzyskiwania dostępu 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ć te same certyfikaty główne dla zaufanych Magazyn urzędu certyfikacji (CA) zgodnie z podanym 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 o ruchu w sieci może być monitorowana 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.
  • że ruch w sieci jest kierowany przez określoną sieć VPN, aplikacji udostępniającej sieć VPN.

Jeśli implementacje urządzeń mają wbudowany mechanizm, kieruje ruch związany z danymi sieciowymi przez serwer proxy lub bramę VPN (na przykład wstępnie wczytują usługę VPN z przyznanym uprawnieniem android.permission.CONTROL_VPN):

• [C-2-1] MUSI prosić użytkownika o zgodę przed włączeniem tego mechanizmu. chyba że usługa VPN została włączona przez kontroler zasad urządzeń w DevicePolicyManager.setAlwaysOnVpnPackage() w którym to przypadku użytkownik nie musi wyrażać osobnej zgody, ale TRZEBA otrzymać tylko powiadomienie.

Jeśli implementacje urządzeń wykorzystują finansowanie przez użytkownika, aby włączyć „stały VPN” aplikacji VPN innej firmy:

• [C-3-1] MUSI wyłączyć tę funkcję użytkownika w przypadku aplikacji, które nie obsługują zawsze włączona usługa VPN w pliku AndroidManifest.xml przez ustawienie SERVICE_META_DATA_SUPPORTS_ALWAYS_ON. wartość atrybutu false.

9.8.5 Identyfikatory urządzeń

Implementacje na urządzeniach:

• [C-0-1] MUSI uniemożliwiać dostęp do numeru seryjnego urządzenia oraz, gdzie numer IMEI/MEID, numer seryjny karty SIM oraz International Mobile. Tożsamość subskrybenta (IMSI) z aplikacji, chyba że spełnia ona jeden z tych warunków wymagania:
  • 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.
  • jest właścicielem urządzenia lub właścicielem profilu, który otrzymał Uprawnienie READ_PHONE_STATE.
  • (tylko w przypadku numeru seryjnego karty SIM/identyfikatora ICCID) zgodności z lokalnymi przepisami że aplikacja wykrywa zmiany w tożsamości subskrybenta.

9.8.6 Dane na poziomie systemu operacyjnego i dane otoczenia

Android, za pośrednictwem systemowych interfejsów API, obsługuje mechanizm dla urządzenia implementacji umożliwiających rejestrowanie tych danych wrażliwych:

• tekst i grafika renderowane na ekranie, w tym między innymi: powiadomień i danych wspomaganych za pomocą AssistStructure API.
• 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 ekrany i inne dane wysyłane przez AugmentedAutofillService do systemu.

• dowolnego ekranu lub innych danych dostępnych przez Content Capture API.

• Wszystkie dane aplikacji przekazywane do systemu przez interfejs API AppSearchManager i dostępne w usłudze AppSearchGlobalManager.query.

• wiadomości tekstowe i inne dane wysyłane przez TextClassifier API, do System TextClassifier, tj. do usługi systemowej, aby zrozumieć, znaczenia tekstu, a także generować przewidywanie dalszych działań na podstawie tekst.

• Dane zindeksowane przez implementację AppSearch na platformie, w tym między innymi ograniczone do tekstu, grafiki, danych multimedialnych lub innych podobnych danych.

• Dane audio uzyskane w wyniku użycia funkcji SpeechRecognizer#onDeviceSpeechRecognizer() dzięki rozpoznawaniu mowy Wdrożenie.

• Dane dźwiękowe uzyskane w tle (ciągle) przez aplikację AudioRecord, SoundTrigger lub inny interfejs API audio i nie powoduje, że plik cookie jest widoczny dla użytkownika. wskaźnik

• Dane z kamery uzyskane w tle (ciągle) za pomocą usługi CameraManager lub innych interfejsów API aparatu i nie spowoduje wyświetlania wskaźnika widocznego dla użytkownika.

Jeśli implementacje urządzeń rejestrują któreś z powyższych danych, to:

• [C-1-1] MUSI szyfrować wszystkie takie dane, gdy są przechowywane na urządzeniu. Ten szyfrowanie MOŻE zostać wykonane za pomocą szyfrowania opartego na plikach na Androidzie, mechanizmów szyfrowania wymienionych jako interfejs API w wersji 26 lub nowszej opisanych w artykule Cipher SDK.
• [C-1-2] NIE MOŻE tworzyć kopii zapasowych nieprzetworzonych ani zaszyfrowanych danych za pomocą Tworzenie kopii zapasowej danych z Androida lub inne sposoby za pomocą metody „up” (górnej).
• [C-1-3] W takiej sytuacji MUSISZ wysyłać wszystkie takie dane poza korzystających z mechanizmu chroniącego prywatność, z wyjątkiem za każdym razem, gdy dane są Udostępnione. Mechanizm ochrony prywatności są definiowane jako „te, które umożliwiają tylko zbiorczą analizę i zapobiegają dopasowania zarejestrowanych zdarzeń lub wyników pochodnych do poszczególnych użytkowników”, zapobiegać spojrzeniu na dane poszczególnych użytkowników (np. implementowane za pomocą technologii prywatności różnicowej, np. RAPPOR).
• [C-1-4] NIE MOŻE wiązać takich danych z żadną tożsamością użytkownika (np. jako Account) na urządzeniu, chyba że za każdym razem, gdy użytkownik wyrazi na to zgodę, powiązane treści.
• [C-1-5] NIE MOŻE udostępniać takich danych innym komponentom systemu operacyjnego, które nie należy spełnić wymagania opisane w bieżącej sekcji (9.8.6 Dane na poziomie systemu operacyjnego i dane otoczenia), chyba że za wyraźną zgodą użytkownika przy jego udostępnianiu. O ile taka funkcja nie jest utworzono jako interfejs API Android SDK (AmbientContext, HotwordDetectionService).
• [C-1-6] MUSI dostarczyć informacje na temat możliwości usunięcia danych, które lub zastrzeżone środki gromadzą, gdy są przechowywane na urządzeniu w dowolnej formie. Jeśli deweloper zdecyduje się usunąć dane, MUSI usunąć wszystkie zebrane i skalowalnych danych.

• [C-1-7] MUSI zapewniać użytkownikowi zgodę na rezygnację z zbierania danych za pośrednictwem AppSearch lub zastrzeżonych środków na platformie Androida. (np. program uruchamiający).

• [C-SR-1] Zdecydowanie ZALECANE jest NIE prosić o uprawnienia INTERNET.

• [C-SR-2] Zdecydowanie ZALECANY jest dostęp do internetu tylko za pomocą uporządkowane interfejsy API korzystające z publicznie dostępnych implementacji typu open source.

• [C-SR-4] Zdecydowanie ZALECANE są wdrożenie za pomocą interfejsu Android SDK API lub podobne repozytorium open source należące do OEM; i / lub być wykonywane Implementacja w trybie piaskownicy (patrz: 9.8.15 Implementacje interfejsu API w trybie piaskownicy).

Jeśli implementacje urządzeń obejmują usługę, która implementuje interfejs System API ContentCaptureService, AppSearchManager.index lub dowolna zastrzeżona usługa który przechwytuje dane w sposób opisany powyżej, oznacza to, że:

• [C-2-1] NIE MOŻE zezwalać użytkownikom na zastępowanie usług aplikacji lub usługi instalowanej przez użytkownika i MUSI zezwalać na używanie jedynie wstępnie zainstalowane usługi, aby rejestrować takie dane.
• [C-2-2] NIE MOŻE zezwalać na aplikacje inne niż wstępnie zainstalowane usługi mechanizmu zbierania takich danych.
• [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 do zarządzania uprawnieniami Androida, które są objęte usługami i stosują się do uprawnień Androida zgodnie z opisem w artykule 9.1. Uprawnienia.

• [C-SR-3] Zdecydowanie ZALECANE jest oddzielenie usług od innych. komponenty systemu (np.brak powiązania usługi lub identyfikatorów procesów udostępniania). oprócz tych:

  • Telefonia, kontakty, interfejs systemu i multimedia

9.8.7 Dostęp do schowka

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE zwrócić obciętych danych ze schowka (np. ClipboardManager API), chyba że inna firma jest domyślnym edytorem IME lub jest aktualnie zaznaczony.

• [C-0-2] MUSI wyczyścić dane ze schowka po upływie maksymalnie 60 minut od ich ostatniego umieszczone w schowku lub odczytywane ze schowka.

9.8.8 Lokalizacja

Lokalizacja obejmuje informacje z klasy lokalizacji systemu Android( takie jak Współrzędne, długość i wysokość), a także identyfikatory, które można przekonwertować na lokalizację. Lokalizacja może być tak dokładna jak DGPS (różnicowy globalny system pozycjonowania) lub przybliżone jako lokalizacje na poziomie kraju (np. lokalizacja według kodu kraju – MCK – Komórki kod kraju).

Poniżej znajduje się lista typów lokalizacji, które bezpośrednio stanowią dla użytkownika do lokalizacji lub mogą zostać przekształcone na lokalizację użytkownika. Nie jest to wyczerpująca lista ale należy go używać jako przykładu do bezpośredniego lub pośrednio pochodzą z:

• GPS/GNSS/DGPS/PPP
  • rozwiązanie do globalnego pozycjonowania, globalny system satelitarny lub Rozwiązanie do różnicowego pozycjonowania globalnego
  • Obejmuje to również nieprzetworzone pomiary GNSS i stan 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)
  • Identyfikator stacji bazowej (3G, 4G, 5G... oraz wszystkich przyszłych modemów komórkowych) technologie korzystające z unikalnych identyfikatorów)

Na początek zapoznaj się z interfejsami API Androida, które wymagają Uprawnienia 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 Wi-Fi/Bluetooth ustawień skanowania bez wyraźnej zgody użytkownika ani bez jego zgody.
• [C-0-2] MUSI zapewniać użytkownikowi dostęp do informacji o lokalizacji informacje, w tym ostatnie prośby o lokalizację, uprawnienia na poziomie aplikacji i użytkowanie skanowania Wi-Fi/Bluetooth, by określić lokalizację.
• [C-0-3] MUSI upewnić się, że aplikacja korzystająca z interfejsu Emergency Location Bypass API [LocationRequest.setLocationSettingsIdentifid()] to zdarzenie alarmowe zainicjowane przez użytkownika (np. wybierz numer 112 lub wyślij SMS-a pod numer 112). w przypadku branży motoryzacyjnej: pojazd MAJA zainicjować sesję alarmową bez aktywnej interakcji użytkownika w danym przypadku. wykryto wypadek lub wypadek (np. w celu spełnienia wymagań dotyczących połączeń e-mail).
• [C-0-4] MUSI zachować możliwość ominięcia lokalizacji dla połączeń alarmowych w ramach ominąć ustawienia lokalizacji urządzenia bez ich zmiany.
• [C-0-5] MUSISZ zaplanować powiadomienie przypominające użytkownikowi o aplikacji w dostęp do lokalizacji użytkownika w tle przy użyciu [ACCESS_BACKGROUND_LOCATION].

9.8.9. Zainstalowane aplikacje

Aplikacje na Androida kierowane na interfejs API na poziomie 30 lub wyższym nie mają dostępu do szczegółowych informacji o innych domyślnie zainstalowanych aplikacji (zobacz Widoczność pakietów na urządzeniu z Androidem SDK).

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE udostępniać żadnych informacji dotyczących aplikacji kierowanej na interfejs API na poziomie 30 lub wyższym o innej zainstalowanej aplikacji, chyba że aplikacja ma już dostęp do szczegółowych informacji o innej zainstalowanej aplikacji przy użyciu zarządzanych interfejsów API. Obejmuje to między innymi: nie tylko do szczegółów udostępnianych przez niestandardowe interfejsy API dodane przez urządzenie; implementatora lub można uzyskać do niego dostęp w systemie plików.
• [C-0-2] NIE MOŻE przyznawać żadnych aplikacji uprawnień do odczytu ani zapisu w żadnych innych aplikacjach. w katalogu dla określonej aplikacji, w pamięci zewnętrznej. Jedyne wyjątki są następujące:
  • Urząd zewnętrznego dostawcy pamięci masowej (np. aplikacji takich jak DocumentsUI).
  • Dostawca pobierania, który korzysta z metody „do pobrania” urząd dostawcy dla pobierania plików do pamięci aplikacji.
  • aplikacje korzystające z protokołu MTP podpisanego przez platformę Media Transfer Protocol (MTP), z podwyższonymi uprawnieniami ACCESS_MTP, aby umożliwić przesyłanie plików do przez inne urządzenie.
  • Aplikacje, które instalują inne aplikacje i mają uprawnienia INSTALL_PACKAGES ma dostęp tylko do pliku „obb” w katalogach do zarządzania Pliki rozszerzeń APK.

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

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

• [C-1-1] MUSI obsługiwać generowanie raportów o błędach połączeń przez BUGREPORT_MODE_TELEPHONY w narzędziu BugreportManager.
• [C-1-2] MUSI uzyskiwać zgodę użytkownika za każdym razem, gdy BUGREPORT_MODE_TELEPHONY używane do generowania raportu i NIE MOGĄ prosić użytkownika o zgodę na wszystkie kolejnych żądań z aplikacji.
• [C-1-3] NIE MOŻE zwracać wygenerowanego raportu do aplikacji, która wysłała prośbę, bez wyraźnej zgody użytkownika.
• [C-1-4] Raporty wygenerowane za pomocą usługi BUGREPORT_MODE_TELEPHONY MUSZĄ zawierać przynajmniej następujące informacje:
  • Zrzut TelephonyDebugService
  • Zrzut TelephonyRegistry
  • Zrzut WifiService
  • Zrzut ConnectivityService
  • Zrzut instancji CarrierService pakietu wywołującego (jeśli jest powiązany)
  • Bufor dziennika radiowego
  • Zrzut SubscriptionManagerService
• [C-1-5] W wygenerowanych raportach NIE MOŻE zawierać tych danych:
  • Wszelkie informacje, które nie są bezpośrednio związane z łącznością i debugowaniu.
  • jakiekolwiek dzienniki ruchu z aplikacji zainstalowanych przez użytkowników lub szczegółowe profile; aplikacji lub pakietów zainstalowanych przez użytkownika (identyfikatory UID są dozwolone, nazwy pakietów nie).
• MOŻE zawierać dodatkowe informacje, które nie są powiązane z żadnym użytkownikiem tożsamości. (np. dzienniki dostawcy).

Jeśli implementacje urządzeń zawierają dodatkowe informacje (np. dzienniki dostawcy) w raporty o błędach i że te informacje zawierają prywatność/bezpieczeństwo/baterię/pamięć/pamięć mają większy wpływ na kształt:

• [C-SR-1] Zdecydowanie ZALECANE jest włączenie domyślnego ustawienia dla programistów na wyłączono. Implementacja referencyjna AOSP spełnia to wymaganie, udostępniając atrybut Enable verbose vendor logging opcja dołączania w ustawieniach dewelopera dodatkowych dzienników dostawcy związanych z konkretnym urządzeniem. w raportach o błędach.

9.8.11. Udostępnianie blobów danych

Android w aplikacji BlobStoreManager umożliwia aplikacjom dodawanie blobów danych do systemu, które są udostępniane wybranym i aplikacjami.

Jeśli implementacje urządzeń obsługują udostępniane bloby danych zgodnie z Dokumentacja pakietu SDK one:

• [C-1-1] NIE MOŻE udostępniać obiektów blob danych należących do aplikacji poza tymi, do których są które chcesz zezwolić (tj. zakres domyślnego dostępu oraz pozostałe opcje dostępu tryby, które można określić za pomocą BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess(), lub BlobStoreManager.session#allowPublicAccess() NIE NALEŻY modyfikować). Implementacja referencyjna AOSP spełnia te warunki .
• [C-1-2] NIE MOŻE wysyłać bezpiecznych haszów na urządzeniu ani udostępniać innym aplikacjom. blobów danych (które służą do kontroli dostępu).

9.8.12. Rozpoznawanie muzyki

Android, za pomocą interfejsu System API MusicRecognitionManager, obsługuje mechanizm implementacje urządzeń, które wysyłają żądania rozpoznawania muzyki z uwzględnieniem nagrania dźwiękowego; delegować rozpoznawanie muzyki do uprzywilejowanych aplikacji implementujących Interfejs API MusicRecognitionService.

Jeśli implementacje urządzeń obejmują usługę, która implementuje interfejs System API MusicRecognitionManager lub dowolną zastrzeżoną usługę, która transmituje dane audio jako opisane powyżej:

• [C-1-1] MUSI wymuszać, aby element wywołujący MusicRecognitionManager przybierał MANAGE_MUSIC_RECOGNITION uprawnienie
• [C-1-2] MUSI wymuszać stosowanie jednego, zainstalowanego fabrycznie systemu rozpoznawania muzyki implementuje MusicRecognitionService.
• [C-1-3] NIE MOŻE umożliwiać użytkownikom zastępowania obiektu MusicRecognitionManagerService lub MusicRecognitionService za pomocą aplikacji lub usługi, którą użytkownik może zainstalować.
• [C-1-4] MUSI mieć pewność, że gdy MusicRecognitionManagerService uzyska dostęp do nagrasz dźwięk i przekaże go do aplikacji implementującej MusicRecognitionService, dostęp do dźwięku jest śledzony przez wywołania AppOpsManager.noteOp / startOp.

Jeśli implementacje usługi MusicRecognitionManagerService na urządzeniach lub MusicRecognitionService przechowuje wszystkie zarejestrowane dane dźwiękowe:

• [C-2-1] NIE MOŻE przechowywać na dysku odcisków palców ani nieprzetworzonego dźwięku. lub zapisane w pamięci przez dłużej niż 14 dni.
• [C-2-2] NIE MOŻE udostępniać takich danych poza MusicRecognitionService z wyjątkiem za każdym razem, gdy jest udostępniany z 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 oprogramowania, wejścia kamery lub mikrofonu na potrzeby urządzenia:

• [C-1-1] MUSI zwracać wartość „true” (prawda) dla odpowiednich obsługujeSensorToggle() API.
• [C-1-2] MUSI, gdy aplikacja próbuje uzyskać dostęp do zablokowanego mikrofonu lub aparatu, zaoferują użytkownikowi nieodrzuconą ofertę, która będzie jasno wskazywać wskazuje, że czujnik jest zablokowany i wymaga wyboru, aby kontynuować blokowanie lub odblokowywanie zgodnie z implementacją AOSP zgodną z tym .
• [C-1-3] MUSI przekazywać do aplikacji tylko pusty (lub fałszywy) aparat i dane audio i nie zgłaszają kodu błędu, ponieważ użytkownik nie włącza kamery ani mikrofonu za pomocą aprobaty użytkownika przedstawionej w punkcie [C-1-2] powyżej.

9.8.14. Nie dotyczy

9.8.15. Implementacje interfejsu API w trybie piaskownicy

Android za pomocą zestawu delegowanych interfejsów API zapewnia mechanizm przetwarzania bezpiecznych Dane na poziomie systemu operacyjnego i dane otoczenia. Takie przetwarzanie można przekazać do wstępnie zainstalowanego plik APK z uprzywilejowanym dostępem i ograniczonymi możliwościami komunikacji, znany jako Implementacja interfejsu API w trybie piaskownicy.

Dowolne wdrożenie interfejsu API w trybie piaskownicy:

• [C-0-1] NIE MOŻE prosić o uprawnienia INTERNET.
• [C-0-2] MUSI mieć dostęp do internetu tylko za pomocą uporządkowanych interfejsów API opartych na publicznie dostępnych implementacji open source z zachowaniem ochrony prywatności, za pomocą interfejsów API pakietu Android SDK. W przypadku tagu chroniącego prywatność są definiowane jako „te, które umożliwiają tylko analizę zagregowaną zapobiegać dopasowywaniu zarejestrowanych zdarzeń lub wyników pochodnych do poszczególnych użytkowników.", aby zapobiec spojrzeniu na dane poszczególnych użytkowników (np. implementowane za pomocą technologię prywatności różnicowej, taką jak RAPPOR).
• [C-0-3] Usługi MUSZĄ oddzielać usługi od innych komponentów systemu (np. nie wiążą identyfikatorów usługi ani procesów udostępniania) z wyjątkiem :
  • Telefonia, kontakty, interfejs systemu i multimedia
• [C-0-4] NIE MOŻE zezwalać użytkownikom na zastępowanie usług aplikacja lub usługa instalowana przez użytkownika
• [C-0-5] MUSI zezwalać na zbieranie takich danych tylko wstępnie zainstalowanym usługom. Chyba że funkcja wymiany jest wbudowana w AOSP (np. w przypadku aplikacji cyfrowych, Aplikacje Asystenta).
• [C-0-6] NIE MOŻE zezwalać na aplikacje inne niż wstępnie zainstalowane usługi mechanizmu zbierania takich danych. Chyba że taka możliwość zapisu danych jest implementowana za pomocą interfejsu API pakietu Android SDK.
• [C-0-7] MUSI zapewniać koszty użytkownika w celu wyłączenia usług.
• [C-0-8] NIE MOŻE pomijać zgody użytkownika do zarządzania uprawnieniami Androida, które są przechowywane przez usługi i zgodnie z modelem uprawnień Androida, opisane w Artykuł 9.1. Uprawnienia.

9.8.16. Ciągły dźwięk i dane z aparatu

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-0-1] MUSI wymuszać stosowanie odpowiedniego wskaźnika (aparat i/lub mikrofon jako zgodnie z sekcją 9.8.2 Nagrywanie, chyba że:
  • Ten dostęp jest wykonywany w ramach implementacji w trybie piaskownicy (zobacz 9.8.15 implementacji interfejsu API w trybie piaskownicy) za pomocą pakietu zawierającego jeden lub inne role: System UI Intelligence, System Ambient Audio Intelligence System Audio Intelligence System Notification Intelligence, System Text Intelligence lub Systemowa inteligencja wizualna.
  • Dostęp jest przeprowadzany w piaskownicy, zaimplementowany i egzekwowane za pomocą mechanizmów AOSP (HotwordDetectionService, WearableSensingService i VisualQueryDetector).
  • Dostęp do dźwięku jest przeprowadzany w celach wspomagających przez Aplikacja Asystent, przesyłając SOURCE_HOTWORD jako źródło dźwięku.
  • Dostęp jest wykonywany przez system i implementowany za pomocą kodu open source.
• [C-SR-1] Zdecydowanie ZALECANE jest wymaganie zgody użytkownika za każdym razem, korzystające z takich danych i domyślnie wyłączone.
• [C-SR-2] Zdecydowanie ZALECANE jest zastosowanie tej samej metody leczenia (tj. ograniczeń opisanych w sekcjach 9.8.2 Nagrywanie, 9.8.6 dane na poziomie systemu operacyjnego i dane otoczenia 9.8.15 Implementacje interfejsów API w trybie piaskownicy oraz 9.8.16 Tryb ciągłego dźwięku i kamery danych) do danych kamery z zdalnego urządzenia do noszenia.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-1-1] MUSI wskazywać na zdalne urządzenie do noszenia, wyświetli się tam dodatkowy wskaźnik.

Jeśli urządzenia umożliwiają interakcję z aplikacją Asystenta cyfrowego bez przypisanego słowa kluczowego (obsługa ogólnych zapytań użytkownika, przez kamerę), to:

• [C-2-1] MUSI zapewnić taką implementację przez pakiet zawierający Rola użytkownika android.app.role.ASSISTANT.
• [C-2-2] MUSI mieć pewność, że w takiej implementacji wykorzystywana jest właściwość HotwordDetectionService lub VisualQueryDetectionService interfejsów API Androida.

9.8.17. Telemetry

Android przechowuje dzienniki systemowe i dzienniki aplikacji za pomocą interfejsów StatsLog API. Tymi logami są zarządzane za pośrednictwem interfejsów API StatsManager, których mogą używać aplikacje systemowe z podwyższonymi uprawnieniami.

StatsManager umożliwia też zbieranie danych sklasyfikowanych jako dotyczące prywatności wrażliwych od urządzeń z mechanizmem chroniącym prywatność. W szczególności Interfejs API StatsManager::query umożliwia wysyłanie zapytań dotyczących danych objętych ograniczeniami Zdefiniowano kategorie w Statystykach Google.

Każda implementacja, która wysyła zapytania i zbiera dane objęte ograniczeniami Menedżer statystyk:

• [C-0-1] MUSI być jedyną aplikacją lub implementacją na urządzeniu i blokować uprawnienia READ_RESTRICTED_STATS.
• [C-0-2] MOŻE wysyłać dane telemetryczne i dziennik urządzenia tylko za pomocą mechanizm ochrony prywatności. Mechanizm ochrony prywatności został zdefiniowany które umożliwiają tylko zbiorczą analizę i uniemożliwiają dopasowywanie zdarzeń rejestrowanych przez użytkownika ani wyników pochodnych dla poszczególnych użytkowników”, dane poszczególnych użytkowników, które można spostrzegać (np. zaimplementowane za pomocą metody różnicowej technologię ochrony prywatności, taką jak RAPPOR).
• [C-0-3] NIE MOŻE wiązać takich danych z żadną tożsamością użytkownika (np. Konto) na urządzeniu.
• [C-0-4] NIE MOŻE udostępniać takich danych innym komponentom systemu operacyjnego, które nie są zgodne wymagania opisane w obecnej sekcji (9.8.17 Polityka prywatności Dane telemetryczne).
• [C-0-5] MUSI udostępniać dodatkowe korzyści, aby włączyć/wyłączyć ochronę prywatności zbieranie, wykorzystywanie i udostępnianie danych telemetrycznych.
• [C-0-6] MUSI dostarczyć informacje na temat możliwości usunięcia danych, które zostały jeśli dane są przechowywane na urządzeniu w jakiejkolwiek formie. Jeśli użytkownik zdecydował się usunąć dane, MUSISZ usunąć wszystkie dane przechowywane obecnie na urządzenia.
• [C-0-7] MUSI ujawniać podstawowe wdrożenie protokołu chroniącego prywatność w repozytorium open source.
• [C-0-8 ]MUSI egzekwować zasady ruchu wychodzącego danych w tej sekcji, aby zablokować zbieranie danych danych z kategorii wskaźników podlegających ograniczeniom zdefiniowanych w StatsLog.

9.9. Szyfrowanie magazynu danych

Wszystkie urządzenia MUSZĄ spełniać wymagania opisane w sekcji 9.9.1. Urządzenia, które zostały uruchomione na poziomie interfejsu API wcześniej niż w przypadku tego dokumentu, to zwolniona z wymagań podanych w artykułach 9.9.2 i 9.9.3; zamiast tego MUSI spełniać wymagania podane w sekcji 9.9 dotyczącej zgodności z systemem Android Dokument z definicją odpowiadający 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 masowej.

• [C-0-2] ACTION_LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED Intencje MUSZĄ nadal być transmitowane, aby sygnalizować aplikacje obsługujące funkcję bezpośredniego rozruchu, Lokalizacje pamięci masowej zaszyfrowane na urządzeniu (DE) i z danymi uwierzytelniającymi (CE) to dostępnych dla użytkownika.

9.9.2. Wymagania dotyczące szyfrowania

Implementacje na urządzeniach:

• [C-0-1] MUSI szyfrować prywatną aplikację danych (partycja /data) i partycji pamięci współdzielonej aplikacji (partycji /sdcard), jeśli jest to trwała, niemożliwa część urządzenia.
• [C-0-2] MUSI domyślnie włączyć szyfrowanie przechowywania danych użytkownik przeprowadził już gotową konfigurację.

• [C-0-3] MUSI spełniać powyższe wymagania dotyczące szyfrowania miejsca na dane stosując jedną z dwóch poniższych metod szyfrowania:

  • Szyfrowanie oparte na plikach (FBE) oraz Szyfrowanie metadanych zgodnie z artykułem 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 pytania użytkownika o dane logowania zezwalaj aplikacjom wykrywającym bezpośrednie uruchamianie aplikacji 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 z szyfrowaniem danych uwierzytelniających (CE) tylko po użytkownik odblokował urządzenie, podając swoje dane logowania. (np. kod dostępu, kod PIN, wzór lub odcisk palca) i ACTION_USER_UNLOCKED Wysyłana wiadomość.
• [C-1-13] NIE MOŻE oferować żadnej metody odblokowywania pamięci chronionej przez CE bez użycia danych logowania podanych przez użytkownika, zarejestrowanego klucza depozytowego ani wznów wdrożenie po ponownym uruchomieniu, spełniając wymagania art. 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, one:

• [C-1-5] MUSI szyfrować zawartość pliku i metadane systemu plików za pomocą AES-256-XTS lub Adiantum. AES-256-XTS odnosi się do standardu Advanced Encryption Standard 256-bitowym kluczem szyfrowania, który działa w trybie XTS; pełnej długości ma 512 bitów.Adiantum odnosi się do Adiantum-XChaCha12-AES, zgodnie z opisem na stronie https://github.com/google/adiantum Metadane systemu plików to dane takie jak plik rozmiary, własność, tryby i atrybuty rozszerzone (xattrs).
• [C-1-6] MUSI szyfrować nazwy plików za pomocą AES-256-CBC-CTS, AES-256-HCTR2, czy Adiantum.
• [C-1-12] Jeśli urządzenie obsługuje standard AES (Advanced Encryption Standard) (np. ARMv8 Cryptography Extensions na urządzeniach z procesorami ARM lub AES-NI na urządzeniach x86), a następnie oparte na AES opcje nazwy pliku, zawartość pliku oraz szyfrowanie metadanych systemu plików MUSI być używane, a nie Adiantum.
• [C-1-13] MUSI używać silnego kryptograficznego i nieodwracalnego klucza funkcji derywacji (np. HKDF-SHA512), aby uzyskać potrzebne klucze podrzędne (np. kluczy dla poszczególnych plików) z kluczy CE i DE. „Sprawne kryptograficznie nieodwracalne oznacza, że funkcja derywacji klucza ma poziom zabezpieczeń co najmniej 256 bitów i działa jako funkcja pseudonimowa grupa rodzinna nad danymi wejściowymi.
• [C-1-14] NIE MOŻE używać tych samych kluczy ani podkluczy szyfrowania opartych na plikach (FBE) do różnych celów kryptograficznych (np. zarówno do szyfrowania, jak i do obsługi kluczy lub dwa różne algorytmy szyfrowania).
• [C-1-15] MUSI mieć pewność, że wszystkie nieusunięte bloki zaszyfrowanej treści pliku pamięci trwałej zostały zaszyfrowane za pomocą kombinacji klucza szyfrowania wektora inicjującego (IV), który zależy od pliku i przesunięcia plik. Ponadto wszystkie takie kombinacje MUSZĄ być różne, z wyjątkiem sytuacji, szyfrowanie jest wykonywane za pomocą wbudowanego sprzętu do szyfrowania, który obsługuje tylko IV o długości 32 bitów.
• [C-1-16] MUSI mieć pewność, że wszystkie nieusunięte zaszyfrowane nazwy plików w trwałych miejsce na dane w różnych katalogach zostało zaszyfrowane przy użyciu różnych kombinacji klucz szyfrowania i wektor inicjujący (IV).

• [C-1-17] MUSI mieć pewność, że wszystkie zaszyfrowane metadane systemu plików pamięć trwała była szyfrowana przy użyciu różnych kombinacji klucza szyfrowania i wektor inicjujący (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 ze sprzętem urządzenia. źródła zaufania.
  • [C-1-8] Klucze CE MUSZĄ być powiązane z danymi logowania na ekranie blokady użytkownika.
  • [C-1-9] Klucze CE MUSZĄ być powiązane z domyślnym hasłem, jeśli użytkownik nie określono danych logowania ekranu blokady.
  • [C-1-10] MUSI być niepowtarzalna i charakterystyczna, czyli nie może mieć oznaczenia CE ani DE użytkownika. klucz pasuje do dowolnego klucza CE lub DE innego użytkownika.
  • [C-1-11] MUSI używać domyślnie obsługiwanych mechanizmów szyfrowania, długości kluczy i trybów wyświetlania.
  • [C-1-12] MUSI zostać bezpiecznie wykasowana podczas odblokowywania i blokowania programu rozruchowego jak opisano tutaj.

• POTRZEBUJESZ wstępnie zainstalowane niezbędne aplikacje (np. Alarm, Telefon, Messenger) Bezpośrednie uruchamianie.

Nadrzędny projekt Android Open Source zapewnia preferowaną implementację Szyfrowanie oparte na plikach oparte na jądrze Linuksa „fscrypt” funkcję szyfrowania, oraz szyfrowania metadanych na podstawie jądra systemu Linux „dm-default-key”. funkcji.

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 za pomocą partycji nieprzetworzonych lub woluminy logiczne.
• [C-1-3] MUSI używać unikalnych, odrębnych kluczy szyfrowania dla każdego użytkownika szyfrowania powiązanych urządzeń blokujących.

• [C-1-4] MUSI używać AES-256-XTS do szyfrowania użytkownika na poziomie bloku partycji.

• 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 ze sprzętem urządzenia. źródła zaufania.
  • [C-1-6] MUSI być powiązany z ekranem blokady odpowiedniego użytkownika dane logowania.

Szyfrowanie na poziomie bloku dla poszczególnych użytkowników można wdrożyć za pomocą jądra systemu Linux. „dm-crypt” w podziale na partycje na użytkownika.

9.9.4. Wznów po ponownym uruchomieniu

Opcja „Wznów przy ponownym uruchomieniu” umożliwia odblokowanie pamięci CE wszystkich aplikacji, w tym które nie obsługują jeszcze bezpośredniego rozruchu po ponownym uruchomieniu zainicjowanym przez OTA. Ten pozwala użytkownikom otrzymywać powiadomienia z zainstalowanych aplikacji po i uruchomić go ponownie.

Implementacja funkcji Wznów po ponownym uruchomieniu musi nadal gwarantować, że po uruchomieniu urządzenie wpadnie w ręce atakującego, bardzo trudno jest osoby przeprowadzającej atak w celu odzyskania danych użytkownika zaszyfrowanych przy użyciu znaku CE, nawet jeśli urządzenie jest zasilane. włączona, pamięć CE jest odblokowana, a użytkownik odblokował urządzenie po otrzymaniu OTA. Ze względu na odporność na atak osób wtajemniczonych zakładamy także, że osoba przeprowadzająca atak uzyska dostęp do przesyłania 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 z urządzeniami oraz mają te możliwości i ograniczenia:

  • Możliwość podpisania dowolnego dostawcy lub firmy za pomocą klucza podpisywania dowolnego dostawcy lub firmy wiadomości.
  • Może powodować odbieranie aktualizacji OTA przez urządzenie.
  • Może modyfikować działanie dowolnego sprzętu (AP, Flash itp.) z wyjątkiem opisane poniżej, ale taka modyfikacja wiąże się z opóźnieniem o co najmniej i cykl zasilania, który 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 powoduje jego wprowadzenie.

Przykładem może być implementacja urządzenia, w której zaimplementowane są wszystkie opisów, które można znaleźć tutaj jest 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 raportować za pomocą metody System API PersistentDataBlockManager.getFlashLockState(), czy program rozruchowy pozwala na miganie obrazu systemu.

• [C-0-2] MUSI obsługiwać weryfikację podczas uruchamiania, aby zapewnić integralność urządzenia.

Jeśli implementacje urządzeń zostały już uruchomione bez obsługi weryfikacji podczas uruchamiania na wcześniejszej wersji Androida i nie można dodać obsługi tej wraz z aktualizacją oprogramowania systemowego, mogą zostać zwolnieni z .

Weryfikacja podczas uruchamiania to funkcja, która gwarantuje integralność urządzenia i oprogramowaniu. 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 i uzyskać dostęp do partycji systemowej.
• [C-1-4] MUSI przeprowadzić każdy etap weryfikacji, aby sprawdzić integralność i autentyczności wszystkich bajtów na następnym etapie, zanim wykonasz kod do kolejnego etapu.
• [C-1-5] MUSI używać algorytmów weryfikacji tak silnych, jak obecne zalecenia NIST dotyczące algorytmów haszujących (SHA-256) i klucza publicznego. (RSA-2048).
• [C-1-6] NIE MOŻE umożliwiać ukończenia rozruchu w przypadku niepowodzenia weryfikacji systemu. chyba że użytkownik mimo to wyrazi zgodę na próbę uruchomienia. W takim przypadku dane z NIE NALEŻY używać żadnych 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 odblokował program rozruchowy.
• [C-1-8] MUSZĄ korzystać z pamięci, w której nie wykryto manipulacji: do przechowywania, czy Program rozruchowy jest odblokowany. Wykrywanie ingerencji w pamięć masową oznacza, że program rozruchowy może wykryć, czy nie ktoś manipulował w pamięci urządzenia z Androidem.
• [C-1-9] MUSI prosić użytkownika podczas korzystania z urządzenia i wymaga fizycznego potwierdzenia przed zezwoleniem na przejście z programu rozruchowego; z trybu blokady do trybu odblokowanego programu rozruchowego.
• [C-1-10] MUSI wdrożyć ochronę przed wycofywaniem zmian na partycjach używanych przez Androida (np. podczas uruchamiania czy na partycjach systemu) i przechowywać w pamięci masowej metadane używane do określenia minimalnej dopuszczalnej wersji systemu operacyjnego.
• [C-1-11] MUSI bezpiecznie wymazywać wszystkie dane użytkownika podczas odblokowywania programu rozruchowego i zgodnie ze standardem 9.12. „Usunięcie danych” (w tym partycji danych użytkownika spacji NVRAM).

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-SR-2] Zdecydowanie ZALECANE jest sprawdzanie wszystkich plików APK aplikacji z podwyższonymi uprawnieniami za pomocą łańcuch zaufania zakorzenionego w partycjach chronionych przez weryfikację podczas uruchamiania.
• [C-SR-3] Zdecydowanie ZALECANE jest sprawdzanie wszystkich artefaktów wykonywalnych ładowanych przez aplikacji z podwyższonymi uprawnieniami spoza pliku APK (np. dynamicznie ładowanego kodu lub skompilowanego kodu) przed ich wykonaniem lub Zdecydowanie ZALECAMY nie uruchamiać ich .
• NALEŻY zaimplementować ochronę przywracania przed wycofywaniem komponentów ze wszystkimi komponentami z trwałymi oprogramowania sprzętowego (np. modemu czy aparatu) i POWINNY być używane do tego celu w którym są przechowywane metadane służące do określania minimalnej dopuszczalnej wersji.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nadrzędny projekt Android Open Source zapewnia preferowaną implementację tę funkcję w external/avb/ które można zintegrować z programem rozruchowym używanym do wczytywania na urządzeniu z Androidem.

Jeśli implementacje na urządzeniach umożliwiają weryfikację pliku treści na stronie, to:

• [C-2-1] obsługuje kryptograficzną weryfikację zawartości pliku bez odczytywania cały plik.

• [C-2-2] NIE MOŻE DOpuszczać żądania odczytu danych do chronionego pliku, aby odnieść sukces, gdy odczytywana treść nie jest weryfikowane zgodnie z podaną wyżej [C-2-1].

• [C-2-4] W przypadku włączonych plików MUSI zwracać sumę kontrolną pliku w O(1).

jeśli implementacje urządzeń zostały już uruchomione bez możliwości weryfikacji, zawartości pliku z zaufanym kluczem we wcześniejszej wersji Androida i nie można dodać na obsługę tej funkcji po aktualizacji oprogramowania systemowego, urządzenia te MOGĄ zostać zwolnione od wymogu. Nadrzędny projekt Android Open Source udostępnia preferowana implementacja tej funkcji w oparciu o funkcję fs-verity jądra systemu Linux.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

9.11. Klucze i dane uwierzytelniające

system magazynu kluczy Androida, umożliwia programistom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i używanie ich operacji kryptograficznych za pomocą KeyChain API. lub 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 stosować przedział czasu między nieudanych próbami. Jeśli liczba nieudanych prób to n, przedział czasu MUSI wynosić co najmniej 30 sekund dla 9 < n < 30) Dla n > 29, wartość przedziału czasu MUSI wynosić co najmniej 30*2^floor((n-30)/10)) s lub co najmniej 24 godziny, zależnie od tego, co jest krótsze.
• 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 środowiska wykonawczego.
• [C-1-2] MUSI zawierać implementacje RSA, AES, ECDSA, ECDH (jeśli obsługiwany jest system IKeyMintDevice), 3DES, i algorytmy kryptograficzne HMAC oraz hasz rodziny MD5, SHA-1 i SHA-2 zapewnia prawidłową obsługę które są bezpiecznie odizolowane od kodu działającego na na jądrze i w nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy za pomocą którego jądro lub kod przestrzeni użytkownika może uzyskać dostęp do wewnętrznego stanu w odizolowanym środowisku, w tym DMA. Starsze oprogramowanie typu open source na Androida Projekt (AOSP) spełnia to wymaganie, wykorzystując Zaufane, ale inne rozwiązanie oparte na technologii ARM TrustZone lub zewnętrzne sprawdzone wdrożenie prawidłowej izolacji opartej na hipernadzorcy to alternatywne rozwiązanie .
• [C-1-3] MUSI przeprowadzić uwierzytelnianie ekranu blokady w i tylko wtedy, gdy wszystko się uda, zezwól na dostępnych kluczy. Dane logowania na ekran blokady MUSZĄ być przechowywane który umożliwia korzystanie z ekranu blokady wyłącznie izolowanemu środowisku wykonawczemu uwierzytelnianie. Główny projekt Android Open Source udostępnia Warstwa abstrakcji sprzętowej bramy (HAL) i Trusty. Można je wykorzystać, aby spełnić to wymaganie.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Pamiętaj, że jeśli implementacja na urządzeniach została już wprowadzona na starszym Androidzie przez co urządzenie jest zwolnione z obowiązku posiadania magazynu kluczy są oparte na izolowanym środowisku wykonawczym i obsługują atest klucza; chyba że deklaruje on funkcję android.hardware.fingerprint, która wymaga żądania magazyn kluczy obsługiwany przez izolowane środowisko wykonawcze.

• [C-1-5] MUSI umożliwiać użytkownikowi wybranie limitu czasu uśpienia dla przejścia z odblokowano do stanu blokady z minimalnym dozwolonym czasem oczekiwania do 15 sekund. urządzenia motoryzacyjne, które blokują ekran zawsze, gdy znajduje się w urządzeniu centralnym. jest wyłączona lub użytkownik jest przełączony, NIE MOŻE mieć limitu czasu uśpienia konfiguracji.
• [C-1-6] MUSI obsługiwać jeden z tych formatów:
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1,
  • IKeyMintDevice w wersji 1 lub
  • IKeyMintDevice w wersji 2.
• [C-SR-1] Zdecydowanie ZALECANY jest obsługa IKeyMintDevice w wersji 1.

9.11.1. Bezpieczny ekran blokady, uwierzytelnianie i urządzenia wirtualne

Implementacja AOSP korzysta z wielopoziomowego modelu uwierzytelniania, w którym Uwierzytelnianie podstawowe oparte na wiedzy może być poparte wtórną silny biometryczną lub słabszymi modalnościami trzeciorzędnymi.

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest ustawienie tylko jednej z tych opcji jako podstawowego uwierzytelniania :

  • Numeryczny kod PIN
  • Hasło alfanumeryczne

  • Wzór przesuwania na siatce zawierającej dokładnie 3 x 3 kropki

    Powyższe metody uwierzytelniania są nazywane podstawowych metod uwierzytelniania w tym dokumencie.

• [C-0-1] MUSI ograniczać liczbę nieudanych prób uwierzytelnienia podstawowego.

• [C-SR-5] Zdecydowanie ZALECANE jest wdrożenie górnej granicy wynoszącej 20 niepowodzeń. głównych prób uwierzytelniania, a jeśli użytkownik wyrazi zgodę i zezwoli na korzystanie z tej funkcji, „Przywracanie danych fabrycznych” po przekroczeniu limitu niezrealizowanej głównej wartości prób uwierzytelnienia.

Jeśli implementacje urządzeń ustawiają numeryczny kod PIN jako zalecany podstawowy kod PIN metody uwierzytelniania, a następnie:

• [C-SR-6] Zdecydowanie ZALECANY jest kod PIN składający się z co najmniej 6 cyfr lub jest odpowiednikiem 20-bitowej entropii.
• [C-SR-7] Zdecydowanie ZALECANE jest podanie kodu PIN o długości mniejszej niż 6 cyfr umożliwia automatyczne wprowadzanie kodu bez interakcji użytkownika, co pozwala uniknąć ujawniania kodu PIN. długości.

Jeśli implementacje urządzeń dodają lub zmieniają zalecane uwierzytelnianie podstawowe nowych metod uwierzytelniania jako bezpiecznych metod blokowania ekranu, nową metodę uwierzytelniania:

• [C-2-1] MUSI być metodą uwierzytelniania użytkownika opisaną w Wymaganie uwierzytelniania użytkowników przy użyciu klucza.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania na potrzeby odblokowywania ekranu blokady, jeśli jest on oparty na znanym obiekcie tajnym, i użyje nowego uwierzytelniania. , która jest traktowana jako bezpieczny sposób blokowania ekranu:

• [C-3-1] Entropia najkrótszej dozwolonej długości danych wejściowych MUSI być więcej niż 10 bitów.
• [C-3-2] Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18-bitowa.
• [C-3-3] Nowa metoda uwierzytelniania NIE MOŻE zastępować żadnych zalecane główne metody uwierzytelniania (np. kod PIN, wzór, hasło) zostały wdrożone i udostępnione w AOSP.
• [C-3-4] Nowa metoda uwierzytelniania MUSI być wyłączona, gdy Aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła hasło wymagania dotyczące DevicePolicyManager.setRequiredPasswordComplexity() o bardziej restrykcyjnej stałej złożoności niż PASSWORD_COMPLExitY_NONE lub za pomocą funkcji DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] Nowe metody uwierzytelniania MUSZĄ wrócić do zalecane główne metody uwierzytelniania (np. kod PIN, wzór, hasła) raz na 72 godziny LUB wyraźnie ujawnić że niektóre dane nie będą tworzone w celu zachowania kopii zapasowej ochrony prywatności ich danych.

Jeśli implementacje urządzeń dodają lub zmieniają zalecane uwierzytelnianie podstawowe do odblokowywania ekranu blokady i używania nowej metody uwierzytelniania, oparte na biometrii jako bezpiecznego sposobu blokowania ekranu, :

• [C-4-1] MUSI spełniać wszystkie wymagania opisane w sekcji 7.3.10 dla klasy 1 (wcześniej: Wygoda).
• [C-4-2] MUSI mieć mechanizm awaryjny, aby użyć jednego z zalecanych podstawowych metod uwierzytelniania opartych na znanym obiekcie tajnym.
• [C-4-3] MUSI być wyłączona i zezwalać tylko na zalecane główne uwierzytelnianie, aby odblokować ekran, gdy kontroler zasad dotyczących urządzeń (DPC) aplikacja ustawiła zasadę funkcji blokady klawiszy, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures() z powiązanymi flagami biometrycznymi KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE lub KEYGUARD_DISABLE_IRIS).

Jeśli metody uwierzytelniania biometrycznego nie spełniają wymagań dla klasy 3 (dawniej Silne) zgodnie z opisem w sekcja 7.3.10:

• [C-5-1] Metody MUSZĄ być wyłączone, jeśli kontroler zasad dotyczących urządzeń (DPC) aplikacja ustawiła politykę jakości wymagań dotyczących haseł za pośrednictwem: funkcja DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjnym zasobnikiem złożoności niż PASSWORD_COMPLEXITY_LOW lub za pomocą funkcji DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Użytkownik MUSI otrzymać prośbę o podanie zalecanej metody głównej uwierzytelniania (np. kodu PIN, wzoru, hasła) zgodnie z opisem w sekcjach [C-1-7] oraz [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 rozpoczynające się od C-8 w tej sekcji poniżej.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania na potrzeby odblokowywania ekran blokady, a nowa metoda uwierzytelniania jest oparta na tokenie fizycznym lub lokalizacja:

• [C-6-1] MUSZĄ mieć mechanizm awaryjny, aby użyć jednego z zalecanych podstawowych metod uwierzytelniania, które są oparte na znanym obiekcie tajnym i są wymagania dotyczące korzystania z bezpiecznego ekranu blokady.
• [C-6-2] Nowa metoda MUSI być wyłączona i zezwalać tylko na jeden zalecane główne metody uwierzytelniania do odblokowywania ekranu, Aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasadę:
  • DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) metoda
  • DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_NONE
  • DevicePolicyManager.setRequiredPasswordComplexity() o bardziej restrykcyjnym zasobniku złożoności niż PASSWORD_COMPLEXITY_NONE
• [C-6-3] Użytkownik MUSI otrzymać wyzwanie dotyczące jednego z zalecanych głównych metody uwierzytelniania (np. kod PIN, wzór, hasło) co najmniej raz Nie dłużej niż 4 godziny. Gdy token fizyczny spełnia wymagania wymagania dotyczące implementacji TrustAgent w C-X, ograniczenia czasu oczekiwania zdefiniowane w artykule 9-5.
• [C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI pamiętaj o ograniczeniach wymienionych w punkcie C-8 poniżej.

Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jeden który implementuje systemowy interfejs API TrustAgentService:

• [C-7-1] MUSI mieć wyraźne oznaczenie w menu ustawień i na zamku ekranu, gdy blokada urządzenia zostanie odroczona lub może zostać odblokowana przez agenta zaufania. Na przykład AOSP spełnia to wymaganie, wyświetlając opis tekstowy dla: ustawienie „Automatycznie blokuj” i „Błyskawiczne blokowanie przycisku zasilania” w menu ustawień i wyróżniającą się ikonę na ekranie blokady.
• [C-7-2] MUSI respektować i w pełni wdrażać wszystkie interfejsy API agenta zaufania DevicePolicyManager, takie jak KEYGUARD_DISABLE_TRUST_AGENTS. jest stała.
• [C-7-3] NIE MOŻE w pełni implementować funkcji TrustAgentService.addEscrowToken() na urządzeniu używanym jako główne urządzenie osobiste (np. w telefonie), ale MOŻE w pełni wdrożyć funkcję na urządzeniu typowe implementacje (np. Android TV czy urządzenie motoryzacyjne).
• [C-7-4] MUSI szyfrować wszystkie przechowywane tokeny dodane przez TrustAgentService.addEscrowToken()
• [C-7-5] NIE MOŻE przechowywać klucza szyfrowania ani tokena depozytowego w na tym samym urządzeniu, na którym jest używany kluczyk. Na przykład dozwolony jest dla: klucza zapisanego na telefonie, który pozwala odblokować konto użytkownika na telewizorze. W przypadku urządzeń motoryzacyjnych nie można przechowywać tokena depozytowego w dowolnej części pojazdu.
• [C-7-6] MUSI poinformować użytkownika o wpływie na bezpieczeństwo przed przez umożliwienie tokena depozytowego odszyfrowania magazynu danych.
• [C-7-7] MUSI mieć mechanizm awaryjny, aby użyć jednego z zalecanych podstawowych metod uwierzytelniania.
• [C-7-9] Użytkownik MUSI otrzymać wyzwanie dotyczące jednego z zalecanych głównych uwierzytelniania (np. za pomocą kodu PIN, wzoru, hasła) zgodnie z opisem w [C-1-7] i [C-1-8] w sekcji 7.3.10, o ile jest istotne dla bezpieczeństwa użytkownika (np. aby rozpraszać uwagę kierowcy).
• [C-7-10] NIE MOŻE być traktowane jako bezpieczny ekran blokady i MUSI spełniać wymagania wymienionych w C-8 poniżej.
• [C-7-11] NIE MOŻE zezwalać agentom zaufania na podstawowych urządzeniach osobistych (np. trzymanego w ręku) do odblokowywania urządzenia. Można go używać tylko do: utrzymuj urządzenie, które jest już odblokowane, w stanie odblokowanym przez maksymalnie maksymalnie 4 godziny. Domyślna implementacja Usługa TrustManagerService w AOSP spełnia to wymaganie.
• [C-7-12] MUSI używać bezpiecznego kryptograficznie (np.UKEY2) kanału komunikacji, aby przekazać token depozytowy z pamięci masowej z urządzeniem docelowym.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania na potrzeby odblokowywania ekranu blokady, który nie jest bezpiecznym ekranem blokady w sposób opisany powyżej, oraz nową metodę uwierzytelniania do odblokowania blokady:

• [C-8-1] Nowa metoda MUSI być wyłączona, gdy kontroler zasad dotyczących urządzeń Aplikacja (DPC) ustawiła zasady dotyczące jakości haseł w DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_NONE lub przez 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 DevicePolicyManager.setPasswordExpirationTimeout()
• [C-8-3] NIE MOGĄ udostępniać interfejsu API do użytku przez aplikacje innych firm zmienić stan blokady.

Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych elementów wyświetlacze wirtualne i nie obsługują powiązanych zdarzeń wejściowych, np. przez VirtualDeviceManager, one:

• [C-9-1] MUSI zablokować te dodatkowe ekrany wirtualne, gdy domyślny wyświetlacz jest zablokowany i odblokuj dodatkowe wyświetlacze wirtualne, gdy: domyślny wyświetlacz urządzenia jest odblokowany.

Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych wyświetlaczy wirtualnych i obsługę powiązanych danych wejściowych zdarzeń, np. za pomocą narzędzia VirtualDeviceManager, mogą one:

• [C-10-1] MUSI obsługiwać osobne stany blokady na urządzeniu wirtualnym
• [C-10-2] MUSI odłączać wszystkie urządzenia wirtualne po przekroczeniu limitu czasu bezczynności
• [C-10-3] MUSI mieć limit czasu bezczynności
• [C-10-4] MUSI zablokować wszystkie ekrany po uruchomieniu blokadę ekranu, w tym dzięki subskrypcji, która jest wymagana w przypadku urządzeń mobilnych (patrz sekcja Sekcja 2.2.5[9.11/H-1-2])
• [C-10-5] MUSI mieć oddzielne instancje urządzeń wirtualnych na użytkownika

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-10-11] NALEŻY wyłączyć interfejs uwierzytelniania na urządzeniach wirtualnych, w tym wprowadzanie do czynnika wiedzy i prompt biometryczny

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

• [C-10-13] W ramach uwierzytelniania użytkownika nie wolno używać stanu blokady urządzenia wirtualnego w systemie Android Keystore. Zobacz KeyGenParameterSpec.Builder.setUserAuthentication*

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Gdy implementacje urządzeń pozwalają użytkownikowi przenieść główną współczynnik wiedzy o uwierzytelnianiu z urządzenia źródłowego na urządzenie docelowe np. podczas wstępnej konfiguracji urządzenia docelowego:

• [C-11-1] MUSI szyfrować współczynnik wiedzy z gwarancjami podobnymi do: tych opisanych w Usługa Google Cloud Key Vault Service na temat zabezpieczeń podczas z urządzenia źródłowego do urządzenia docelowego, tak aby współczynnika wiedzy nie można odszyfrować zdalnie ani wykorzystać do zdalnego odblokowania na każdym z tych urządzeń.
• [C-11-2] MUSI poprosić użytkownika na urządzeniu źródłowym o potwierdzenie współczynnik wiedzy o urządzeniu źródłowym przed przeniesieniem współczynnika wiedzy na urządzenie docelowe.
• [C-11-3] MUSI NA urządzeniu docelowym bez ustawionego podstawowego uwierzytelniania należy poprosić użytkownika o potwierdzenie przekazanego czynnika wiedzy na temat na urządzeniu docelowym przed ustawieniem tego współczynnika wiedzy jako głównego współczynnika wiedzy na temat uwierzytelniania na urządzeniu docelowym oraz przed wszystkie dane przesłane z urządzenia źródłowego.

Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jeden agentów zaufania, które wywołują interfejs TrustAgentService.grantTrust() System API z flagę FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE:

• [C-12-1] MOŻE wywoływać funkcję grantTrust() tylko z flagą po połączeniu z w pobliżu urządzenia fizycznego z własnym ekranem blokady, a użytkownik musi uwierzytelnili swoją tożsamość na tym ekranie blokady. Urządzenia zbliżeniowe mogą używać mechanizmów wykrywania na nadgarstku lub kontaktu z ciałem po jednorazowym odblokowaniu urządzenia spełniają wymóg uwierzytelniania użytkownika.
• [C-12-2] MUSI umieścić implementację urządzenia w sekcji TrustState.TRUSTABLE stanu, gdy ekran jest wyłączony (np. przez naciśnięcie przycisku lub wyświetlacza) przekroczono limit czasu), a agent TrustAgent nie unieważnił zaufania. AOSP jest zadowolony(-a) tego wymogu.
• [C-12-3] MUSI przenosić urządzenie tylko z urządzenia TrustState.TRUSTABLE do TrustState.TRUSTED, jeśli agent TrustAgent nadal przyznaje zaufanie na podstawie wymagania określone w kategorii C-12-1.
• [C-12-4] MUSI zadzwonić do: TrustManagerService.revokeTrust()
  • po maksymalnie 24 godzinach od przyznania zaufania,
  • po 8-godzinnym okresie bezczynności lub
  • Jeśli implementacje nie korzystają z kryptograficznie bezpiecznych dokładnego zakresu zgodnie z definicją w dokumencie [C-12-5], gdy podstawowe połączenie z zbliżonego urządzenia fizycznego.
• [C-12-5] Implementacje polegają na bezpiecznym i dokładnym określaniu zakresu, aby wymagania standardu [C-12-4] MUSZĄ skorzystać z jednego z tych rozwiązań:
  • Implementacje korzystające z UWB:
    • MUSI spełniać wymagania dotyczące zgodności, certyfikacji, dokładności i wymagania dotyczące kalibracji dla UWB opisanego w 7.4.9.
    • MUSI używać jednego z trybów zabezpieczeń P-STS wymienionych w 7.4.9.
  • Implementacje z wykorzystaniem sieci wykrywania okolic Wi-Fi (NAN):
    • MUSI spełniać wymagania dotyczące dokładności w 2.2.1 [7.4.2.5/H-SR-1], użyj przepustowości 160 MHz (lub i postępuj zgodnie z instrukcjami konfiguracji pomiaru podanymi w Kalibracja obecności
    • MUSI używać bezpiecznego LTF zgodnie z definicją w IEEE 802.11az

Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych wyświetlaczy wirtualnych i obsługę powiązanych danych wejściowych zdarzeń, np. za pomocą VirtualDeviceManager a wyświetlacze nie są oznaczone symbolem VIRTUAL_DISPLAY_FLAG_SECURE, ponieważ:

• [C-13-8] MUSI blokować activities z atrybutem android:canDisplayOnRemoteDevices lub metadanymi android.activity.can_display_on_remote_devices ustawionymi na false, aby nie uruchamiały się na urządzeniu wirtualnym urządzenia.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

Jeśli implementacje urządzeń obsługują osobne stany zasilania wyświetlacza przez DeviceStateManager ORAZ obsługuje oddzielne stany blokady ekranu KeyguardDisplayManager, to:

• [C-SR-2] Zdecydowanie ZALECANE jest skorzystanie ze spotkania dotyczącego danych logowania wymagania określone w artykule 9.11.1 lub wymagania dotyczące danych biometrycznych specyfikacji klasy 1 zdefiniowane w artykule 7.3.10, aby umożliwić niezależne odblokowywanie z domyślnego wyświetlacza urządzenia.
• [C-SR-3] Zdecydowanie ZALECANE jest ograniczenie odblokowywania osobnego wyświetlacza. przez określony czas oczekiwania na wyświetlacz.
• [C-SR-4] Zdecydowanie ZALECANE jest umożliwienie użytkownikom globalnego zablokowania wszystkich wyświetlaczy. przez blokadę na głównym urządzeniu przenośnym.

9.11.2. StrongBox,

System Android Keystore przechowywania kluczy kryptograficznych w dedykowanym bezpiecznym procesorze, a także w osobnym środowisku wykonawczym opisanym powyżej. Taki dedykowany bezpieczny procesor jest nazywany „StrongBox”. Wymagania C-1–3 do kategorii C-1-11 poniżej określają wymagania, które urządzenie musi spełniać, są uznawane za StrongBox.

Implementacje urządzeń, które mają dedykowany bezpieczny procesor:

• [C-SR-1] Zdecydowanie ZALECANE są wsparcie dla StrongBox. StrongBox będzie mogą stać się obowiązkowym elementem w przyszłej 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 tworzenia kopii zapasowych magazyn kluczy i bezpieczne uwierzytelnianie użytkowników. Dedykowane zabezpieczenia sprzęt również może być używany do innych celów.

• [C-1-3] MUSI mieć oddzielny procesor, który nie ma pamięci podręcznej, pamięci DRAM ani współprocesorów lub inne kluczowe zasoby w połączeniu z procesorem aplikacji.

• [C-1-4] MUSI mieć pewność, że żadne urządzenia peryferyjne współdzielone przez punkt dostępu nie mogą zmieniać przetwarzania StrongBox w jakikolwiek sposób ani uzyskiwania 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%) odpornego na manipulacje ze strony AP.

• [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 fizycznej penetracji i błędów.

• [C-1-8] MUSI mieć opór boczny, w tym wytrzymałość na wyciek informacji przez zasilanie, czas, promieniowanie elektromagnetyczne boczne kanały radiowe.

• [C-1-9] MUSZĄ mieć bezpieczne przechowywanie, które zapewnia poufność, uczciwości, autentyczności, spójności i aktualności treści. Pamięć NIE MOŻE być odczytywana ani modyfikowana, z wyjątkiem zgodnie z wymaganiami interfejsów API StrongBox.

• Aby zweryfikować zgodność z zakresami od [C-1-3] do [C-1-9], urządzenie implementacji:

• [C-1-11] MUSI zawierać oprogramowanie oceniane przez akredytowane w całym kraju laboratorium wykonujące testy na wysokim poziomie potencjalnych luk w zabezpieczeniach według Stosowanie potencjału ataku w przypadku kart inteligentnych (Common Criteria).
• [C-SR-2] Zdecydowanie ZALECANE jest dodanie sprzętu, który oceniane za pomocą celu zabezpieczeń, poziomu zapewniania oceny (EAL) 5, rozszerzony przez AVA_VAN.5. Certyfikat EAL 5 stanie się wymogiem w przyszłej wersji usługi.
• [C-SR-3] Zdecydowanie ZALECANE są zapewnić odporność na atak osób wtajemniczonych (IAR), co oznacza, że osoba wtajemniczona mająca dostęp do podpisywania oprogramowania Klucze nie mogą tworzyć oprogramowania, które powoduje wyciek StrongBox w celu obejścia zabezpieczeń lub w inny sposób umożliwiają dostęp do poufnych danych użytkownika. Zalecany sposób implementacji IAR zezwala na aktualizacje oprogramowania tylko wtedy, gdy główne hasło użytkownika jest udostępniany przez IAuthSecret HAL.

9.11.3 Dane logowania

System danych logowania tożsamości został zdefiniowany i osiągnięty przez wdrożenie wszystkich Interfejsy API w android.security.identity.* pakietu SDK. Te interfejsy API pozwalają deweloperom aplikacji na przechowywanie i pobieranie tożsamości użytkowników dokumenty. Implementacje na urządzeniach:

• Zdecydowanie ZALECANE jest wdrożenie Dokumentu tożsamości [C-SR-1]. System.

Jeśli implementacje urządzeń implementują system danych logowania tożsamości:

• [C-1-1] MUSI zwracać wartość inną niż zero w przypadku IdentityCredentialStore#getInstance() .

• [C-1-2] MUSI wdrożyć system danych logowania tożsamości (np. android.security.identity.*) za pomocą kodu komunikującego się z zaufanym aplikacji w obszarze, który jest bezpiecznie odizolowany od uruchomionego kodu na jądrze i w nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy za pomocą którego jądro lub kod przestrzeni użytkownika może uzyskać dostęp do wewnętrznego stanu w odizolowanym środowisku, w tym DMA.

• [C-1-3] Operacje kryptograficzne niezbędne do wdrożenia tożsamości System danych logowania (np. interfejsy API android.security.identity.*) MUSI być wyłącznie w zaufanej aplikacji, a materiał klucza prywatnego MUSI nigdy nie opuszczają izolowanego środowiska wykonawczego, chyba że jest to wymagane przez interfejsy API wyższego poziomu (np. createEphemeralKeyPair() ).

• [C-1-4] Zaufana aplikacja MUSI być zaimplementowana w taki sposób, nie ma wpływu na właściwości zabezpieczeń (np. dane logowania nie są udostępniane jeśli warunki kontroli dostępu nie są spełnione, nie można tworzyć adresów MAC dla dowolne dane), nawet jeśli Android działa w sposób niewłaściwy lub przejęty.

Dodatkowy projekt Android Open Source udostępnia wdrożenie zaufanej aplikacji (libeic), której można użyć do wdrożenia systemu danych logowania tożsamości.

9.12. Usuwanie danych

Wszystkie implementacje na urządzeniach:

• [C-0-1] MUSI udostępniać użytkownikom mechanizm przywracania danych fabrycznych.
• [C-0-2] MUSI usunąć wszystkie dane z systemu plików danych użytkownika podczas wykonywania „Przywracanie danych fabrycznych”.
• [C-0-3] MUSI usuwać dane w taki sposób, by zapewnić standardów branżowych, takich jak NIST SP800-88, Resetuj”.
• [C-0-4] MUSI wywołać powyższy „Przywracanie danych fabrycznych” gdy DevicePolicyManager.wipeData() Interfejs API jest wywoływany przez aplikację kontrolera zasad 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 uruchamianie urządzeń w tym trybie. gdzie mogą działać tylko wstępnie zainstalowane aplikacje systemowe, a wszystkie aplikacje innych firm Aplikacje są wyłączone. Ten tryb, nazywany „trybem bezpiecznego rozruchu”, umożliwia możliwość odinstalowywania 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 dawać użytkownikowi możliwość włączać bezpiecznego rozruchu w taki sposób, że nie można go przerwać zainstalowane na urządzeniu, chyba że aplikacja innej firmy jest kontroler zasad dotyczących urządzeń i skonfigurował UserManager.DISALLOW_SAFE_BOOT flagę jako true (prawda).

• [C-1-2] MUSI umożliwiać użytkownikowi odinstaluj wszystkie aplikacje innych firm w trybie awaryjnym.

• MUSI umożliwiać użytkownikowi włączenie trybu bezpiecznego rozruchu z przy użyciu przepływu pracy innego niż podczas normalnego uruchamiania.

9.14. Izolacja systemu samochodowego

Oczekuje się, że urządzenia z Androidem Automotive będą wymieniać dane z pojazdami o znaczeniu krytycznym podsystemów z wykorzystaniem kodu HAL pojazdu. do wysyłania i odbierania wiadomości w sieciach w pojeździe, takich jak magistrala CAN.

Wymianę danych można zabezpieczyć, implementując funkcje zabezpieczeń poniżej warstwy struktury Androida w celu zapobiegania złośliwej lub niezamierzonej interakcji z aplikacjami, dla tych podsystemów.

9.15. Abonamenty

„Abonamenty” zapoznaj się z podanymi szczegółami abonamentu relacji rozliczeniowych przez operatora sieci komórkowej za pośrednictwem SubscriptionManager.setSubscriptionPlans()

Wszystkie implementacje na urządzeniach:

• [C-0-1] MUSI zwracać abonamenty tylko aplikacji operatora komórkowego, która .
• [C-0-2] NIE MOŻESZ zdalnie przesyłać ani tworzyć kopii zapasowych abonamentów.
• [C-0-3] MUSI zezwalać tylko na zastąpienia, takie jak SubscriptionManager.setSubscriptionOverrideCongested() w aplikacji operatora komórkowego, który jest obecnie objęty aktualnym abonamentem.

9.16. Migracja danych aplikacji

Jeśli implementacje urządzeń obejmują możliwość migracji danych z urządzenia do z innego urządzenia i nie ograniczaj danych aplikacji do skonfigurowana przez dewelopera aplikacji w pliku manifestu za pomocą android:fullBackupContent, to:

• [C-1-1] NIE MOŻE inicjować przenoszenia danych aplikacji z urządzeń, na których użytkownik nie ustawił podstawowego uwierzytelniania jako opisane w 9.11.1 Bezpieczny ekran blokady i uwierzytelnianie.
• [C-1-2] MUSI bezpiecznie potwierdzić podstawowe uwierzytelnianie u źródła na urządzeniu i potwierdzić zamiar skopiowania danych u użytkownika. urządzenia, zanim jakiekolwiek dane zostaną przesłane.
• [C-1-3] MUSI korzystać z atestu klucza bezpieczeństwa, by zagwarantować, że zarówno źródło, i urządzenie docelowe w migracji między urządzeniami prawidłowe urządzenia z Androidem i zablokowany program rozruchowy.
• [C-1-4] MUSI migrować dane aplikacji tylko do tej samej aplikacji urządzenie docelowe o tej samej nazwie pakietu ORAZ certyfikacie podpisywania.
• [C-1-5] MUSI pokazywać, że na urządzeniu źródłowym znajdują się dane przeniesione przez migrację danych między urządzeniami w menu ustawień. Użytkownik NIE można usunąć tego oznaczenia.

Nowe wymagania dotyczące pakietu 15 (AOSP Experiment)

9.17. Platforma wirtualizacji Androida

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. Dlatego Zdecydowanie ZALECANE są narzędzia do wdrażania rozwiązań w przypadku urządzeń, jak najmniejszej liczby zmian w pliku referencyjnym i preferencjach implementacji Androida dostępnej w projekcie Android Open Source. Pozwoli to zminimalizować ryzyko wprowadzenia błędów, które powodują niezgodności wymagają przerobienia i potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje na urządzeniach:

• [C-0-1] MUSI przejść test Android Compatibility Test Suite (CTS). dostępne w projekcie Android Open Source, z użyciem ostatecznej wersji oprogramowanie zainstalowane na urządzeniu.

• [C-0-2] MUSI zapewniać zgodność w przypadku niejasności w CTS oraz lub częściach kodu źródłowego.

Narzędzie CTS zostało zaprojektowane tak, aby działać na prawdziwym urządzeniu. Podobnie jak w przypadku każdego oprogramowania, wskaźnik CTS może zawierać robaki. Pakiet CTS będzie wersjonowany niezależnie od tego może zostać opublikowana definicja zgodności i wiele wersji CTS; Android 15.

Implementacje na urządzeniach:

• [C-0-3] MUSI przejść najnowszą wersję CTS dostępną w momencie urządzenia gdy oprogramowanie jest gotowe.

• Trzeba użyć implementacji referencyjnej w drzewie open source Androida jak najczęściej.

10.2. Weryfikator CTS

weryfikator CTS wchodzi w skład zestawu Compatibility Test Suite. jest uruchamiana przez człowieka w celu testowania funkcji, których nie można przetestowane przez zautomatyzowany system, np. na poprawne 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 przeprowadza testy różnego rodzaju sprzętu, w tym części sprzętu. (opcjonalnie).

Implementacje na urządzeniach:

• [C-0-2] MUSI przejść wszystkie testy posiadanego sprzętu. np. jeśli urządzenie jest wyposażone w akcelerometr, MUSI prawidłowo wykonywać Przypadek testowy akcelerometru w narzędziu CTS Verifier.

Przypadki testowe dla 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ć prawidłowo weryfikator CTS. jak zaznaczono powyżej. Ponieważ jednak wiele kompilacji jest bardzo podobnych, Implementatory nie powinny jawnie uruchamiać weryfikatora CTS w kompilacji które różnią się tylko banalnie. Dotyczy to zwłaszcza implementacji na urządzeniach, różnią się od implementacji, która została sprawdzona przez weryfikatora CTS tylko przez zestaw uwzględnionych regionów, elementów marki itp. MOŻE pominąć test weryfikatora CTS.

11. Oprogramowanie do aktualizacji

• [C-0-1] Implementacje urządzeń MUSZĄ zawierać mechanizm zastępujący całe oprogramowanie systemowe. Mechanizm nie musi działać w trybie „aktywnym” uaktualnienia – oznacza to, że MOŻE być wymagane ponowne uruchomienie urządzenia. Można użyć dowolnej metody, pod warunkiem że może ona zastąpić całą jest fabrycznie zainstalowany na urządzeniu. Na przykład każdy z tych elementów spełni to wymaganie:

  • „Bezprzewodowe (OTA)” pobieranie z aktualizacją offline przez restartowanie.
  • „Połączono” aktualizacji przez USB z komputera hosta.
  • „Offline” aktualizacje są aktualizowane przez restartowanie i aktualizowane z pliku w pamięci wymiennej.

• [C-0-2] Użyty mechanizm aktualizacji MUSI obsługiwać aktualizacje bez czyszczenia pamięci użytkownika i skalowalnych danych. Oznacza to, że mechanizm aktualizacji MUSI zachować prywatne dane aplikacji oraz dane udostępnione przez aplikację. Pamiętaj, że starsze oprogramowanie Android zawiera który spełnia to wymaganie.

• [C-0-3] Cała aktualizacja MUSI być podpisana, a mechanizm aktualizacji na urządzeniu MUSI sprawdzić aktualizację i podpis w stosunku do klucza publicznego zapisanego na urządzeniu.

• [C-SR-1] Zdecydowanie ZALECANE jest użycie mechanizmu podpisywania do haszowania aktualizacji z SHA-256 i zweryfikować hasz pod kątem klucza publicznego za pomocą ECDSA NIST. P-256).

czy implementacje urządzenia obsługują dane bez pomiaru. takie jak profil 802.11 lub profil Bluetooth PAN (Personal Area Network), to:

• [C-1-1] MUSI obsługiwać pobieranie OTA z aktualizacją offline po ponownym uruchomieniu.

Implementacje urządzenia NALEŻY sprawdzić, czy obraz systemu jest identyczny z plikiem binarnym zgodnie z oczekiwaniami. Aktualizacje OTA oparte na blokach w nadrzędnym projekcie Android Open Source, dodanego od czasu uruchomienia tego rozwiązania. 5.1, spełnia to wymaganie.

Implementacje na urządzeniach MUSZĄ też obsługiwać aktualizacje systemu A/B. AOSP implementuje tę funkcję przy użyciu interfejsu HAL kontroli rozruchu.

Błąd w implementacji urządzenia po jego opublikowaniu, ale w rozsądnym okresie użytkowania produktu, który jest ustalany po zespołu ds. zgodności z Androidem, które wpływają na zgodność aplikacji, a następnie:

• [C-2-1] Narzędzie do implementacji urządzenia MUSI poprawić błąd za pomocą oprogramowania dostępnej aktualizacji, którą można zastosować zgodnie z opisanym powyżej mechanizmem.

Android zawiera funkcje, które umożliwiają aplikacji Właściciel urządzenia (jeśli jest dostępna) kontrolować instalowanie aktualizacji systemu. Jeśli podsystem aktualizacji systemu w przypadku urządzeń zgłasza android.software.device_admin, a następnie:

• [C-3-1] MUSI wdrożyć działanie opisane w SystemUpdatePolicy zajęcia.

12. Historia zmian dokumentu

Podsumowanie zmian w definicji zgodności w tej wersji:

• Historia zmian dokumentu

13. Skontaktuj się z nami

Możesz dołączyć do forum na temat zgodności z Androidem i proś o wyjaśnienia lub poruszanie kwestii, które Twoim zdaniem nie stanowią okładki.