Definicja zgodności z Androidem 12

1. Wprowadzenie

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

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. 12. „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 12, 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 Projekt 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 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ą nazwę „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 powinna działać w bezpiecznym środowisku zgodnie z opisem, w sekcji 9 i innych miejscach niniejszego 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ę.
• mieć ekran o przekątnej fizycznym rozmiarze 3,3 cala (czyli 2,5 cala); cali w przypadku implementacji urządzeń, które zostały wysłane na poziomie API 29 lub wcześniejszym) do 2,4 cm.

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, który spełnia wszystkie wymagania opisane w tym dokumencie dokument.

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

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

• [7.1.1.1/H-1-1]* MUSI utworzyć ekran logiczny która jest dostępna dla aplikacji innych firm, musi znajdować się krótkie krawędzie i długie krawędzie. Urządzenia wysłane przy użyciu interfejsu Android API na poziomie 29 lub starszym mogą zostać zwolnione z obowiązku spełnienia wymogów tego wymogu.

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

• [7.1.1.1/H-2-1]* MUSI utworzyć ekran logiczny udostępnione dla aplikacji innych firm ma rozmiar co najmniej 2,7 cala krótsze krawędzie. Urządzenia wysyłane przy użyciu interfejsu Android API na poziomie 29 lub starszym mogą zostać zwolnione z obowiązku spełnienia wymogów tego wymogu.

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

• [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 metody wprowadzania (IME).
• [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.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.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] Są zalecane do obsługi czujnika pozycji za pomocą stopnie swobody.
• [7.4.3/H] POWINNA obejmować obsługę Bluetootha i Bluetooth LE.

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 wynosić od 50 do 95 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” dla 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 framebuffer 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 ma 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), komponentów takich jak radio czy wideo, które nie znajdują się 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 (zwane też partycją „/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.

jeśli urządzenia przenośne zawierają port USB obsługujący urządzenie peryferyjne, :

• [7.7.1/H-1-1] MUSI zaimplementować otwarty akcesorium Android (AOA) API.

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 rola isSink(), jeśli pole typu terminala 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 rola isSink(), jeśli pole typu terminala 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.

Jeśli implementacje urządzeń mobilnych zadeklarują android.hardware.audio.output i android.hardware.microphone, to:

• [5.6(#56_audio-latency)/H-1-1] MUSI mieć średni ciągły ruch w obie strony opóźnienie wynoszące 800 milisekund lub mniej w przypadku 5 pomiarów ze średnią Odchylenie bezwzględne mniejsze niż 100 ms, w przypadku co najmniej 1 obsługiwanej ścieżki.

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

• [7,10/H]* NIE NALEŻY używać nieśrodkowej masy obrotowej (ERM) czujnik haptyczny (wibrator).
• [7.10/H]* POWINNO umiejscowić urządzenie uruchamiające w pobliżu miejsca, w którym użytkownik zazwyczaj trzyma urządzenie lub dotyka go dłoniami.
• [7.10/H]* NALEŻY zastosować wszystkie stałe publiczne dla wyraźny czujnik haptyczny w android.view.HapticfeedbackConstants (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_launch, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_release, CONFIRM, REJECT, GESTURE_START i GESTURE_END).
• [7.10/H]* NALEŻY zastosować wszystkie stałe publiczne dla wyraźny czujnik haptyczny w narzędziu android.os.VibrationEffect mianowicie (EFFECT_TICK, osobiste_KLIKNIJ, 91.05.2014) i EFFECT_DOUBLE_CLICK) i wszystkie publiczne stałe dla czujników haptycznych. w funkcji android.os.VibrationEffect.Composition (PRIMITIVE_KLIKNIJ i PRIMITIVE_TICK).
• [7,10/H]* POWINNY jest użycie tych połączonych stałych haptycznych mapowania.
• [7.10/H]* POWINNO spełniać ocena jakości dla createOneShot() i createWaveform() interfejsy API.
• [7.10/H]* POWINNO sprawdzić możliwości amplitudy skalowalność przez uruchomienie android.os.Vibrator.hasAmplitudeControl().

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 zawierają co najmniej jeden liniowy rezonans użytkownika, to:

• [7.10/H]* POWINIEN przesunąć element uruchamiający haptyczny na osi X do orientacji pionowej.

Jeśli urządzenia mobilne mają czujnik haptyczny z osią X rezonansu rezonansowego (LRA), co:

• [7,10/H]* POWINNA mieć częstotliwość rezonansową na osi X Częstotliwość LRA musi być mniejsza niż 200 Hz.

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

• [7.10/H]* MUSISZ zweryfikować stan implementacji, przeprowadzając android.os.Vibrator.areAllEffectsSupported() i android.os.Vibrator.arePrimitvesSupported() interfejsy API.
• [7,10/H]* NALEŻY wykonać ocena jakości dla stałych haptycznych.
• [7.10/H]* POWINNA zapewniać pomoc zastępczą, aby zniwelować skutki ryzyko niepowodzenia, jak opisano tutaj.

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

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

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żety i funkcje 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ą 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 dodawać, edytować, wybierać i obsługiwać 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, a także wszelkie określone pola udostępniane przez Control. API.

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.

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-1 do wstępnego wczytywania 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.

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.

2.2.5. Model zabezpieczeń

Implementacje na urządzeniach mobilnych:

• [9.1/H-0-1] MUSI zezwalać aplikacjom innych firm na dostęp do statystyki użytkowania z użyciem uprawnień android.permission.PACKAGE_USAGE_STATS oraz udostępniać dostępny dla użytkownika mechanizm przyznawania lub cofania dostępu do takich aplikacji odpowiedź na android.settings.ACTION_USAGE_ACCESS_SETTINGS intencji.

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, SHA1 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.
• [9.11/H-0-5] MUSI obsługiwać atest klucza, w którym klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie to i bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby można było użyć kluczy jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie ten sam klucz atestu,chyba że zostało z całego świata. Jeśli wyprodukowana zostanie ponad 100 000 sztuk danego kodu SKU, klucz MOŻE zostać użyty na każde 100 000 jednostek.
• [9/H-0-1] MUSI zadeklarować „android.hardware.security.model.compatible” funkcji.

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

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

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ć do systemu lub usługi ContentCaptureService
• [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 przesyłanie na zewnątrz więcej niż 100 bajtów danych usługi wykrywania słów-kluczy dla każdego udanego wyniku dla słowa-klucza.
• [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-13] MUSISZ ponownie uruchomić proces hostujący usługę wykrywania słów-kluczy co najmniej raz na godzinę lub co 30 zdarzeń związanych z regułami sprzętowymi, zależnie od tego, jest na pierwszym miejscu.
• [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-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.

jeśli implementacje urządzeń obejmują aplikację, która korzysta z interfejsu System API. HotwordDetectionService lub podobny mechanizm wykrywania słowa-klucza 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

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

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

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

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

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

• Perfetto
  • [6.1/H-0-2]* MUSI zawierać /system/bin/perfetto do użytkownika powłoki, do której cmdline przestrzega dyrektywa cmdline. dokumentację perfetto.
  • [6.1/H-0-3]* Plik binarny perfetto MUSI akceptować jako wpisz konfigurację buforów protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/H-0-4]* Plik binarny perfetto MUSI zapisywać wyświetlać log logu czasu zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/H-0-5]* MUSI podać za pomocą perfetto binarnych, przynajmniej źródeł danych opisanych w dokumentacji perfetto.
  • [6.1/H-0-6]* Demon śledzący perfetto MUSI mieć domyślnie włączone (usługa systemowa persist.traced.enable).

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

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

2.2.7.1. Multimedia

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

• MUSI spełniać wymagania dotyczące multimediów wymienione w dyrektywie CDD dotyczącej Androida 11 sekcja 2.2.7.1

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

• [5.1/H-1-1] MUSI reklamować maksymalną liczbę 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().
• [5.1/H-1-2] MUSI obsługiwać 6 wystąpień sesji sprzętowego dekodera wideo (AVC, HEVC, VP9* lub nowsze) w dowolnej kombinacji kodeków równocześnie w rozdzielczości 720p przy 30 kl./s. *Jeśli wymagane są tylko 2 instancje Jest dostępny kodek VP9.
• [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().
• [5.1/H-1-4] MUSI obsługiwać 6 wystąpień sprzętowego kodera wideo (AVC, HEVC, VP9* lub nowsze) w dowolnej kombinacji kodeka i jednocześnie w rozdzielczości 720p przy 30 kl./s. *Wymagane są tylko 2 instancje jeśli jest dostępny kodek VP9.
• [5.1/H-1-5] MUSI reklamować maksymalną liczbę sprzętowych koderów wideo sesji dekodera, które mogą być uruchamiane jednocześnie w dowolnej kombinacji kodeków za pomocą CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] MUSI obsługiwać 6 instancji sprzętowych dekodera wideo i sprzętu sesji kodera wideo (AVC, HEVC, VP9* lub nowszego) w dowolnym kodeku działające równocześnie w rozdzielczości 720p przy 30 kl./s. *Jeśli dostępny jest kodek VP9, wymagane są tylko 2 instancje.
• [5.1/H-1-7] W przypadku formatu [5.1/H-1-7] opóźnienie inicjowania kodeka musi wynosić maksymalnie 50 ms Sesja kodowania 1080p lub mniejsza w przypadku wszystkich sprzętowych koderów wideo (innego niż kodek Dolby Vision). Wczytywanie tutaj jest zdefiniowane jako jednoczesna sesja transkodowania transmisji wideo od 1080p do 720p przy użyciu sprzętowego wideo kodeków oraz inicjowanie nagrywania audio-wideo w rozdzielczości 1080p.
• [5.1/H-1-8] W przypadku formatu [5.1/H-1-8] opóźnienie inicjowania kodeka musi wynosić maksymalnie 40 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.
• [5.3/H-1-1] NIE MOŻE upuścić więcej niż 2 klatek w ciągu 10 sekund (mniej niż 0,333% spadku liczby klatek) podczas sesji wideo w rozdzielczości 1080p przy 60 klatkach na sekundę. nie jest wczytywany. Wczytywanie definiuje się jako równoczesne odtwarzanie filmów w rozdzielczości 1080p–720p transkodowania za pomocą sprzętowych kodeków wideo oraz Odtwarzanie dźwięku w formacie AAC z szybkością 128 kb/s.
• [5.3/H-1-2] NIE MOŻE upuszczać w trakcie filmu więcej niż 2 klatek w ciągu 10 sekund zmiana rozdzielczości podczas wczytywania sesji wideo z prędkością 60 kl./s. Obciążenie jest zdefiniowane jako jednoczesna sesja transkodowania od 1080p do 720p, tylko przy użyciu sprzętu kodeki wideo oraz odtwarzanie dźwięku AAC 128 kb/s.
• [5.6/H-1-1] MUSI mieć opóźnienie trwające krócej niż 100 milisekund. korzystając z testu tonacji w systemie OboeTester lub testu tonacji z narzędzia CTS Verifier.

2.2.7.2. Aparat

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

• MUSI spełniać wymagania dotyczące aparatu wymienione w instrukcji CDD dotyczącej Androida 11 sekcja 2.2.7.2

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

• [7.5/H-1-1] MUSI mieć główny tylny aparat o rozdzielczości co najmniej 12 megapikseli obsługujących nagrywanie wideo z szybkością 4k przy 30 kl./s. Podstawowy tylny aparat to tylny aparat z najniższym identyfikatorem.
• [7.5/H-1-2] MUSI mieć główny przedni aparat o rozdzielczości co najmniej 5 megapikseli i umożliwia nagrywanie 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 wersji głównej i LIMITED lub lepszej dla głównego pokoju głównego aparat fotograficzny.
• [7.5/H-1-4] MUSI obsługiwać CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME – zarówno główne kamery.
• [7.5/H-1-5] MUSI mieć opóźnienie na zapis w formacie Camera2 JPEG < 1000 ms dla Rozdzielczość 1080p mierzona w ramach testu wydajności kamery CTS przeprowadzonego przez ITS warunków oświetleniowych (3000 K) obu aparatów głównych.
• [7.5/H-1-6] MUSI mieć opóźnienie na uruchomienie kamery2 (otwórz aparat, aby wyświetlić pierwszy podgląd ramka) < 600 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ć wartość CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW i android.graphics.ImageFormat.RAW_SENSOR za główny tylny aparat.

2.2.7.3 Sprzęt

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

• MUSI spełniać wymagania sprzętowe wymienione w zestawie danych CDD dotyczących Androida 11 sekcja 2.2.7.3

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

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

2.2.7.4. Wydajność

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

• MUSI spełniać wymagania dotyczące wydajności wymienione w zestawie danych o Androidzie 11. sekcja 2.2.7.4

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

• [8.2/H-2-1] MUSI zapewnić wydajność sekwencyjnego zapisu na poziomie co najmniej 125 MB/s.
• [8.2/H-2-2] MUSI zapewniać wydajność zapisu przy losowym połączeniu z szybkością co najmniej 10 MB/s.
• [8.2/H-2-3] MUSI zapewnić wydajność sekwencyjnego odczytu co najmniej 250 MB/s.
• [8.2/H-2-4] MUSI zapewnić prędkość odczytu z szybkością losowej co najmniej 40 MB/s.

2.3. Wymagania dotyczące telewizora

Urządzenie 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ą zaliczane do telewizorów, 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ć stronę główną i tylną 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 obejmować 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 na telewizorach 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

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

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, ze standardową liczbą 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-2-1] 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 zmniejszanie głośności cyfrowych 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 wybierz maksymalną rozdzielczość, która może być obsługiwana przy 50 Hz lub 60 Hz częstotliwość odświeżania danych.
• [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.

Implementacje na urządzeniach telewizyjnych:

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

2.3.4 Wydajność i moc

• [8.1/T-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie 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] POWINNA być przypisana 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.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, SHA1 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.
• [9.11/T-0-4] MUSI obsługiwać atest klucza, w którym klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie to i bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby można było użyć kluczy jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie ten sam klucz atestu,chyba że zostało z całego świata. Jeśli wyprodukowana zostanie ponad 100 000 sztuk danego kodu SKU, klucz MOŻE zostać użyty na każde 100 000 jednostek.
• [9/T-0-1] MUSI zadeklarować „android.hardware.security.model.compatible” funkcji.

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

Implementacje na urządzeniach telewizyjnych:

• Perfetto
  • [6.1/T-0-1] MUSI zawierać /system/bin/perfetto do użytkownika powłoki, do której cmdline przestrzega dyrektywa cmdline. dokumentację perfetto.
  • [6.1/T-0-2] Plik binarny perfetto MUSI akceptować jako wpisz konfigurację buforów protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/T-0-3] Plik binarny perfetto MUSI zapisywać wyświetlać log logu czasu zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/T-0-4] MUSI podać, za pomocą perfetto binarnych, przynajmniej źródeł danych opisanych w dokumentacji perfetto.

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

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.

• [7.2.3/A-0-1] MUSI udostępniać funkcję Home, a MAJ udostępniać funkcje Wstecz i Ostatnie.

• [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-0-1] MAJ nierozliczone 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-2] Lokalizacja żądane za pomocą funkcji LocationManager#requestLocationUpdates() NIE MOŻE być dopasowana do mapy.

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ń motoryzacyjnych zawierają 3-osiowy akcelerometr:

• [7.3.1/A-1-1] MUSI być w stanie zgłaszać zdarzenia do co najmniej 100 Hz.
• [7.3.1/A-1-2] MUSI być zgodna z układ współrzędnych czujnika samochodowego.

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

• [7.3.4/A-2-1] MUSI być w stanie zgłaszać zdarzenia do 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. możliwe

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.

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

• [7.4.3/A-SR-1] Zdecydowanie ZALECANE jest wsparcie Profil dostępu do wiadomości (MAP).

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

Kamera z zewnątrz to aparat, który obrazuje sceny z zewnątrz urządzenia np. jak w przypadku kamery samochodowej.

Implementacje na urządzeniach motoryzacyjnych:

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

Jeśli implementacje urządzeń w samochodach obejmują kamerę w widoku zewnętrznym, na przykład dzięki kamerze, mogą:

• [7.5/A-1-1] NIE MOŻE mieć dostępu do zewnętrznych kamer obrazu za pomocą interfejsów API aparatu Android, o ile nie są one zgodne z zasadami z podstawowymi wymaganiami dotyczącymi aparatu.
• [7.5/A-SR-1] Zdecydowanie ZALECANE jest nierotowanie lub utworzyć odbicie lustrzane podglądu z aparatu w poziomie.
• [7.5.5/A-SR-1] Zdecydowanie ZALECANE jest kierowanie się w taki sposób, a jego dłuższy wymiar wyrówna się do horyzontu.
• [7.5/A-SR-2] Zdecydowanie ZALECANE jest rozwiązanie problemu. co najmniej 1,3 megapiksela.
• POWINNY być sprzęt o stałej ostrości lub EDOF (rozszerzona głębia ostrości).
• MUSI obsługiwać platformę synchronizacji Androida.
• MOGĄ mieć zaimplementowany sprzętowy autofokus lub programowy autofokus sterownika aparatu.

Implementacje na urządzeniach motoryzacyjnych:

• [7.6.1/A-0-1] MUSI mieć co najmniej 4 GB pamięci pamięć nieulotna dostępna na prywatne dane aplikacji (zwane też partycją „/data”).

• [7.6.1/A] POWINNO Sformatować partycję danych aby zwiększyć wydajność i wydłużyć czas pracy pamięci flash. 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.

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

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

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

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

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

• [7.6.1/A-1-3] Pamięć dostępna dla jądra 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

• [7.6.1/A-1-4] Pamięć dostępna dla jądra a przestrzeń użytkowników MUSI mieć co najmniej 1344 MB, jeśli wykorzystane:

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

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

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

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

• [7.6.1/A-2-2] Pamięć dostępna dla jądra a przestrzeń użytkowników MUSI mieć co najmniej 944 MB, jeśli używana jest dowolna z tych gęstości:

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

• [7.6.1/A-2-3] Pamięć dostępna dla jądra a przestrzeń użytkowników MUSI mieć co najmniej 1280 MB, jeśli używana jest dowolna z tych gęstości:

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

• [7.6.1/A-2-4] Pamięć dostępna dla jądra a przestrzeń użytkowników MUSI mieć co najmniej 1824 MB, jeśli używana jest dowolna z następujących gęstości:

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

Pamiętaj, że „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), komponentów takich jak radio czy wideo, które nie znajdują się i większą kontrolę nad implementacją urządzeń.

Implementacje na urządzeniach motoryzacyjnych:

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

Implementacje na urządzeniach motoryzacyjnych:

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

Implementacje na urządzeniach motoryzacyjnych:

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

2.5.2 Multimedia

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

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.

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

Implementacje na urządzeniach motoryzacyjnych:

• [9.11/A-0-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/A-0-2] MUSI zawierać implementacje RSA, AES, algorytmy kryptograficzne ECDSA i HMAC oraz rodzina MD5, SHA1 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.
• [9.11/A-0-4] MUSI obsługiwać atest klucza, w którym klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie to i bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby można było użyć kluczy jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie ten sam klucz atestu,chyba że zostało z całego świata. Jeśli wyprodukowana zostanie ponad 100 000 sztuk danego kodu SKU, klucz MOŻE zostać użyty na każde 100 000 jednostek.
• [9/A-0-1] MUSI zadeklarować „android.hardware.security.model.compatible” funkcji.

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

Implementacje na urządzeniach motoryzacyjnych:

• Perfetto
  • [6.1/A-0-1] MUSI zawierać /system/bin/perfetto do użytkownika powłoki, do której cmdline przestrzega dyrektywa cmdline. dokumentację perfetto.
  • [6.1/A-0-2] Plik binarny perfetto MUSI akceptować jako wpisz konfigurację buforów protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/A-0-3] Plik binarny perfetto MUSI zapisywać wyświetlać log logu czasu zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/A-0-4] MUSI podać, za pomocą perfetto binarnych, przynajmniej źródeł danych opisanych w dokumentacji perfetto.

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ę.
• ma wyświetlacz o przekątnej ekranu większej niż 7 cali i mniejszej niż 18 cali (mierzona na ukos.

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.

Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)

jeśli tablety wyposażone są w port USB obsługujący urządzenie peryferyjne, :

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

Tryb rzeczywistości wirtualnej (art. 7.9.1)

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

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

2.6.2 Model zabezpieczeń

Klucze i dane logowania (art. 9.11)

Patrz [9.11].

Jeśli 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 do Androida. lub dowolny interfejs API oznaczony znacznikiem „@SystemApi” w nadchodzącym środowisku 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.

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 udostępnia również ważny „łagodny” interfejs API tylko w czasie działania, w postaci takich 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 Dozwolone ciągi znaków wersji dozwolone dla Androida 12.
WERSJA.SDK	Wersja obecnie uruchomionego systemu Android w formacie kod aplikacji innej firmy. W przypadku Androida 12: to pole MUSI zawierać liczbę całkowitą 12_INT.
VERSION.SDK_INT	Wersja obecnie uruchomionego systemu Android w formacie kod aplikacji innej firmy. W przypadku Androida 12: to pole MUSI zawierać liczbę całkowitą 12_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ŁUGI_MOŻLIWOŚCI	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) dla natywnego w kodzie. Zobacz sekcję 3.3. Natywny interfejs API Zgodność.
OBSŁUGI_32_BIT_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) dla natywnego w kodzie. Zobacz sekcję 3.3. Natywny interfejs API Zgodność.
OBSŁUGI_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:12/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.
PRODUKCJA_SOC	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ę spacją, 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 MUST 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 („”).
PAKIET_BEZPIECZEŃSTWA	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 Biuletyn o bezpieczeństwie w Androidzie lub w Usługa Android Security Advisory, na przykład „2015-11-01”.
PODSTAWY_systemu operacyjnego	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Ą zezwól na każdy wzorzec intencji, o którym mowa w sekcji 3.2.3.1. , z wyjątkiem Ustawienia, aby zostały 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 obejmuje m.in. wyłączenie użytkownika „Wybór” 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 Identyfikator URI danych „http://www.android.com” jest bardziej szczegółowy niż podstawowy wzorzec 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 w nadrzędnym środowisku 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:

• [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 obsługi połączeń przychodzących i z wyjątkiem połączeń alarmowych, w których użyto 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 &amp; 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 &amp; 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 funkcji „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 wykrywalności.

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ę aparatu android.hardware.camera.any to:

• [C-12-3] MUSI zezwalać na obsługę tylko wstępnie zainstalowanych aplikacji na Androida te intencje: 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 &amp; 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.

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.

• [C-0-6] MUSI raportować za pomocą powyższych parametrów podzbiór następujących danych listę interfejsów ABI i NIE MOŻE zgłaszać żadnych interfejsów ABI, których nie ma na liście.

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

• [C-0-7] MUSI 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 eksportować symbole funkcji dla podstawowej funkcji Vulkan 1.0 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, w sekcji 7.1.4.2 bardziej szczegółowo opisano wymagania dotyczące sytuacji, niektórych z tych funkcji.

• POWINNA budować za pomocą kodu źródłowego i plików nagłówka dostępnych nadrzędny projekt Android Open Source

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 12 która odpowiada za implementację 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 przekazywanej aplikacji przez LocationManager Klasa interfejsu API lub 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 uprawnień lub znajdują się na liście 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ługstopSelf() 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 MUSI 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 7 wartości tablic z 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 urządzenia implementują zastrzeżony mechanizm ograniczania dostępu do aplikacji lub ten mechanizm jest bardziej ograniczony niż zasobnik gotowości aplikacji z ograniczonym dostępem, tzn.:

• [C-1-1] MUSI udostępniać informacje na temat możliwości zakupu dla użytkownika, w którym może on zobaczyć listę aplikacji z ograniczonym dostępem.
• [C-1-2] MUSI zapewniać użytkownikom dostęp do funkcji włączania / wyłączania ograniczeń w każdej aplikacji.
• [C-1-3] NIE MOŻE automatycznie stosować ograniczeń, jeśli nie wskazują na niską jakość prawidłowe działanie systemu, ale MOŻE zastosować ograniczenia do aplikacji po ich wykryciu złej kondycji systemu, takich jak ciągłe blokady uśpienia czy długo działające usługi; z innymi kryteriami. Kryteria MOGĄ być określone przez osoby zajmujące się implementacją urządzenia, ale MUSZĄ być powiązane z wpływem aplikacji na stan systemu. Inne kryteria, które nie są czy są powiązane wyłącznie ze stanem systemu, np. z brakiem popularności aplikacji NIE NALEŻY używać jako kryteriów.
• [C-1-4] NIE MOŻE automatycznie stosować ograniczeń aplikacji, gdy użytkownik ręcznie wyłączył ograniczenia aplikacji i MOŻE zasugerować użytkownikowi stosowanie ograniczenia aplikacji.
• [C-1-5] MUSI informować użytkowników, jeśli do aplikacji są stosowane ograniczenia automatycznie. Takie informacje MUSZĄ zostać dostarczone w ciągu 24 godzin od ich ograniczenia.
• [C-1-6] MUSI zwrócić true za ActivityManager.isBackgroundRestricted() gdy aplikacja z ograniczeniami wywołuje ten interfejs API.
• [C-1-7] NIE MOŻE ograniczać aplikacji znajdującej się na pierwszym planie, która jest bezpośrednio używana przez użytkownika.
• [C-1-8] MUSI zawiesić ograniczenia w aplikacji, która staje się głównym pierwszym planem aplikacji, gdy użytkownik wyraźnie zaczyna używać aplikacji, która wcześniej była ograniczony.
• [C-1-10] NIE MOŻE zezwalać na automatyczne umieszczanie aplikacji w sekcji OGRANICZONE zasobnika w ciągu 2 godzin od ostatniego użycia usługi przez użytkownika.

Jeśli implementacje urządzenia 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ć zdefiniowane przez jawną interakcję użytkownika za pomocą metody 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.

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 do użytkownika.

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 bezpośrednio w Menu z aplikacjami.
• [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 skonfigurowanej za pomocą metody setGroupConversation.
• [C-SR-1] 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.
• [C-SR-2] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości zakupu kontrolować powiadomienia wyświetlane aplikacjom z przyznanym dostępem uprawnienia Odbiornika powiadomień. Szczegółowość MUSI być taka, aby użytkownik może określić dla każdego detektora powiadomień, które powiadomienia typy elementów są połączone z tym detektorem. Typy MUSZĄ zawierać „wątki”, „alerty”, „ciche” i „ważne ważne” powiadomienia.
• [C-SR-3] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości zakupu określać aplikacje, które nie powinny być powiadamiane o wybranym detektorze powiadomień.
• OBSŁUGA powiadomień rozszerzonych.
• TRZEBA pokazywać powiadomienia o wyższym priorytecie jako powiadomienia typu HUD.
• MUSISZ mieć możliwość uśpienia powiadomień.
• MOŻE zarządzać tylko widocznością i czasem, w którym aplikacje innych firm mogą 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.

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

• [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 Nie przeszkadzać

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

• [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 wraz z regułami tworzonymi 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ć.

3.8.4 Interfejs Assist API

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 oknach korzystających z technologii 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 zapewnia „motywy” jako mechanizm, który pozwala aplikacjom stosować style całą aktywność lub aplikację.

Android obejmuje przyciski „Holo” i „Material”. 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ć rodzinę motywów „Material” i NIE MOŻE zmieniać żadnych 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.

Android zawiera też rodzinę motywów „Ustawienie domyślne urządzenia” 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” do użytkownika. 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ą wdrożone 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.
• [C-1-2] MUSI obsługiwać przypinanie ekranu. i udostępnić użytkownikowi menu ustawień, w którym może włączyć tę funkcję.
• 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ć wyzwalanie 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.
• [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 czcionki niezgodne ze standardem Unicode, potocznie nazywane „Zawgyi”, używane do renderowania birmańskiego 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 i 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, których tryb konfiguracji ma wartość „Configuration.uiMode” UI_MODE_TYPE_TELEVISION Minimalna szerokość to 240 dp, a minimalna wysokość 135 dp.

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.9. Administracja urządzeniem

Android zawiera funkcje, które umożliwiają aplikacjom wykrywającym zabezpieczenia funkcje administracyjne urządzenia na poziomie systemu, takie jak wymuszanie stosowania hasła; lub zdalnego czyszczenia pamięci, Android Device Administration API.

Jeśli implementacje urządzeń obejmują pełny zakres administracji urządzeniami zasady określone w dokumentacji pakietu Android SDK:

• [C-1-1] MUSI zadeklarować: android.software.device_admin.
• [C-1-2] MUSI obsługiwać obsługę administracyjną właściciela urządzenia zgodnie z opisem w art. 3.9.1 i art. 3.9.1.1.

3.9.1 Obsługa administracyjna urządzeń

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

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

• [C-1-1] MUSI obsługiwać rejestrację klienta Device Policy (DPC) jako Aplikacja Właściciel urządzenia jak opisano poniżej:
  • Jeśli w implementacji urządzenia nie skonfigurowano jeszcze danych użytkownika, oznacza to, że:
    • [C-1-5] MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia, jeśli urządzenie deklaruje obsługę komunikacji Near-Field Communications (NFC) za pośrednictwem tej funkcji, flaga android.hardware.nfc i otrzyma wiadomość NFC zawierającą 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 o ile nie można ustalić na podstawie kontekstu, że istnieją tylko jedną prawidłową opcję (np. w przypadku obsługi administracyjnej opartej na NFC, Obsługa administracyjna właścicieli nie jest obsługiwana).
    • [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 ma dane użytkownika:
    • [C-1-7] NIE MOŻE rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia więcej informacji.
• [C-1-2] MUSI wymagać wyrażenia zgody przed rozpoczęciem lub w trakcie jest proces obsługi administracyjnej, aby wyrazić zgodę na ustawienie aplikacji jako właściciela urządzenia. Zgodę można wyrazić poprzez działanie użytkownika lub za pomocą narzędzi automatycznych, ale odpowiednich powiadomienie (opisane w AOSP) MUSI być wyświetlane przed właścicielem urządzenia zostanie zainicjowana obsługa administracyjna użytkowników. Oprócz tego właściciel urządzenia zautomatyzowanego mechanizm używany (przez firmy) do obsługi administracyjnej właściciela urządzenia NIE MOŻE zakłócać działanie gotowego urządzenia w przypadku użytkowników niebiznesowych.
• [C-1-3] NIE MOŻE kodować zgody na stałe ani uniemożliwiać korzystania z innego urządzenia i aplikacjami właściciela.

Jeśli implementacje urządzeń zadeklarują android.software.device_admin, ale również zawierają zastrzeżone rozwiązanie do zarządzania właścicielem urządzenia i udostępniają mechanizm aby promować aplikację skonfigurowaną w swoim rozwiązaniu jako „Właściciel urządzenia” „równoważny” na standardową opcję „Właściciel urządzenia”, standardu Android DevicePolicyManager API:

• [C-2-1] MUSI mieć wdrożony proces sprawdzania, czy określona aplikacja należy do legalnego zarządzania urządzeniami firmy i zostało już skonfigurowane w ramach zastrzeżonego rozwiązania, aby mieć odpowiednie uprawnienia jako „Właściciel urządzenia”.
• [C-2-2] MUSI zawierać te same informacje o zgodzie właściciela urządzenia AOSP co proces zainicjowany przez: android.app.action.PROVISION_MANAGED_DEVICE przed zarejestrowaniem aplikacji DPC jako „właściciela urządzenia”.
• MOGĄ mieć na urządzeniu dane użytkownika sprzed rejestracji aplikacji DPC jako „Właściciel urządzenia”.

3.9.1.2 Obsługa administracyjna 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.

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

• [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 może zdecydować, czy zostanie właścicielem urządzenia czy właścicielem profilu, 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-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.

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ślenia 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 Zarządzana pomoc dla użytkowników

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

• [C-1-1] MUSI zapewnić użytkownikowi możliwość wylogowania się z 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.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ść 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 gotowej konfiguracji powinien być dostępny 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.

3.12. Platforma wejścia TV

Android Television Interface Framework (TIF) ułatwia transmitowanie na żywo na urządzenia Android TV. TIF udostępnia standardowy interfejs API do tworzenia moduły wejściowe do sterowania urządzeniami Android TV.

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

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.live_tv.
• [C-1-2] MUSI obsługiwać wszystkie interfejsy API TIF, tak aby aplikacja, która używa oraz wejściowe dane wejściowe innych firm oparte na TIF usługa może być zainstalowana i używana na urządzeniu.

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 ograniczać 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ądzenia 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 za pomocą 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.
• [C-1-3] MUSI podać liczbę użytkowników, aby mógł wybrać/potwierdzić reklamę towarzyszącą jest dostępne i działa.

3.17. Aplikacje do wagi

Jeśli implementacje urządzenia 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ądzenia i nie jest powiązane z żadnym kontem w usłudze AccountManager, które są utworzony 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.

4. Zgodność pakietów aplikacji

Implementacje urządzeń:

• [C-0-1] MUSI mieć możliwość instalowania i uruchamiania plików „.apk” Androida jako plików generowane przez narzędzie „aapt” uwzględnione 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.

Implementacje na urządzeniach:

• [C-0-2] MUSI obsługiwać weryfikację plików „.apk” za pomocą 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 potwierdzenia przez użytkownika, zgodnie z dokumentacją w pakiecie SDK dla DELETE_PACKAGE. uprawnienia. Jedynym wyjątkiem jest obsługa aplikacji weryfikatora pakietów systemu PACKAGE_NEEDS_VERIFICATION intencja i aplikacja menedżera miejsca obsługująca: 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 działanie jako no-op i zwrócić 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ępniane 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 za pomocą Schemat podpisu pliku APK w wersji 4.

5. Zgodność multimediów

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać formaty multimedialne, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w sekcji 5.1. dla każdego kodeka zadeklarowanego przez MediaCodecList.
• [C-0-2] MUSI zadeklarować 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 pięć 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.
• [SR-1] Zdecydowanie ZALECANE jest, aby powyższe wymagania w zakresie C-2-1 i C-2-2 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.

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

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

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)

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.

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

• [SR-1] Zdecydowanie ZALECANE są kodery i dekodery wideo do obsługi 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)

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

• [C-2-2] Kodeki wideo z akceleracją sprzętową MUSZĄ 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

czy implementacje urządzeń obsługują koder wideo i udostępniając go. aplikacji innych firm:

• Ponad 2 okna przesuwne NIE POWINNY o przekraczać 15% szybkości transmisji bitów między odstępami między ramkami (I-frame).
• Szybkość transmisji bitów NIE POWINNO przekraczać 100% szybkości transmisji w oknie przesuwnym wynoszący 1 sekundę.

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ć profil podstawowy poziomu 45.
• POWINNA obsługiwać dynamicznie konfigurowane szybkości transmisji bitów dla obsługiwanego kodera.

5.2.2 H.264

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

• [C-1-1] MUSI obsługiwać profil podstawowy poziomu 3. Jednak obsługa ASO (Arbitrary Slice Ordering) – FMO (elastyczne) 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.
• POWINNA obsługiwać profile kodowania HD zgodnie z informacjami w tej tabeli.
• Zdecydowanie ZALECANE jest korzystanie z profili kodujących HD jako podane w poniższej tabeli, jeśli jest dostępny 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.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 na poziomie 30 i 45.

5.3.3 MPEG-4

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

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

5.3.4 H.264

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

• [C-1-1] MUSI obsługiwać profil główny na poziomie 3.1 i profil podstawowy. 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 , to:

• [C-1-1] MUSI zawierać moduł wyodrębniający z obsługą Dolby Vision.
• [C-1-2] MUSI prawidłowo wyświetlać treści Dolby Vision na ekranie urządzenia lub do standardowego portu wyjściowego wideo (np. HDMI).
• [C-1-3] MUSI ustawiać indeks ścieżki zgodnych wstecznie warstw podstawowych (jeśli obecny), tak aby był taki sam jak indeks ścieżki połączonej warstwy Dolby Vision.

5.3.9 AV1

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

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

5.4. Nagrywanie dźwięku

Chociaż niektóre z wymagań opisanych w tej sekcji są wymienione jako: 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 za pomocą cechy:

  • Format: linearny PCM, 16-bitowy
  • Częstotliwość próbkowania: 8000, 11025, 16 000, 44 100, 48 000 Hz
  • Kanały: mono

• 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() oraz aktualnie aktywne mikrofony, które są dostępne dla aplikacji innych firm przez AudioRecord.getActiveMicrophones() oraz MediaRecorder.getActiveMicrophones() API. 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 wyższych współczynnikach niż 16000:22050 czy 44100:48000.

• [C-2-2] MUSI zawierać odpowiedni filtr antyaliasingowy w górę lub w dół.

5.4.2 Zrób zdjęcie, by włączyć rozpoznawanie głosu

Jeśli implementacje urządzenia zadeklarują android.hardware.microphone:

• [C-1-1] MUSI przechwytywać 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.
• Strumień audio rozpoznawania głosu powinien nagrywać około płasko amplituda względem charakterystyki częstotliwości: ±3 dB, od 100 Hz do 4000 Hz.
• MUSI nagrywać strumień audio rozpoznawania głosu z ustawioną czułością sygnału wejściowego dzięki czemu źródło mocy akustycznej na poziomie 90 dB (SPL) przy 1000 Hz daje RMS 2500 w przypadku próbek 16-bitowych.
• 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.4.6 Poziomy wzmocnienia mikrofonu

Jeśli implementacje urządzenia zadeklarują android.hardware.microphone:

• MUSI wykazywać w przybliżeniu płaską amplitudę w porównaniu z częstotliwością charakterystyka w średnim zakresie częstotliwości: ±3 dB od 100 Hz do 4000 Hz dla każdego mikrofonu użytego do nagrywania głosu; rozpoznawania dźwięku.
• NALEŻY ustawić czułość wejścia audio na sinusoidalną 1000 Hz źródło dźwięku odtwarzane przy poziomie ciśnienia akustycznego 90 dB (SPL) zapewnia odpowiedź z RMS 2500 dla 16-bitowych próbek (lub -22,35 dB w przypadku pełnej skali dla pływania próbek z podwójną precyzją) dla każdego mikrofonu użytego do nagrać źródło dźwięku rozpoznawania głosu.
• Zdecydowanie ZALECANE jest działanie amplitudy na poziomie niskiego tętna [C-SR-1] zakres częstotliwości: konkretnie od ±20 dB od 5 Hz do 100 Hz w porównaniu do średniego zakresu częstotliwości dla każdego mikrofonu użytego do nagrywania źródła dźwięku rozpoznawania głosu.
• Zdecydowanie ZALECANE jest działanie na poziomie amplitudy zakres wysokich częstotliwości: konkretnie od ±30 dB od 4000 Hz do 22 kHz w porównaniu ze średnim zakresem częstotliwości dla każdego używanego mikrofonu aby nagrać źródło dźwięku rozpoznawania głosu.

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.
• POTRZEBA 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 gdy jest określona przez interfejs AudioTrack gapless API. 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 otoczeniu na przetworniku lub sygnał opuszcza urządzenie przez port i może zostać zaobserwowano na zewnątrz.
• 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 i kiedy 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.
• zakłócenia przy zimnie. Zmienność pomiędzy różnymi pomiarami zimna czasu oczekiwania na dane wyjściowe.
• zakłócenia przy zimnie. Zmienność pomiędzy różnymi pomiarami zimna wartości opóźnienia wejściowego.
• 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. Średnia wartości bezwzględnej parametru odchyleń od średniej dla zbioru wartości.
• czas oczekiwania przy dotknięciu tonu. Czas między kliknięciem ekranu a chwilą Z głośnika usłyszysz sygnał dźwiękowy, gdy dotkniesz urządzenia.

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

• [C-1-1] Sygnatura czasowa wyjścia zwracana przez AudioTrack.getTimestamp a AAudioStream_getTimestamp z dokładnością do +/-2 ms.
• [C-1-2] Opóźnienie reakcji „na zimno” wynoszące maksymalnie 500 milisekund.

Jeśli implementacje urządzeń deklarują android.hardware.audio.output, że są Zdecydowanie ZALECANE jest spełnienie lub przekroczenie następujących wymagań:

• [C-SR-1] Opóźnienie reakcji „na zimno” (maksymalnie 100 milisekund) w przypadku danych z głośnika ścieżki konwersji. Dotychczasowe i nowe urządzenia z tą wersją Androida są BARDZO Zdecydowanie zalecamy, aby już teraz spełnić te wymagania. W przyszłej platformie należy użyć opóźnienia na wyjściu „na zimno” nie więcej niż 200 ms.
• [C-SR-2] Opóźnienie reakcji na dotknięcie: maksymalnie 80 milisekund.
• [C-SR-3] Zminimalizuj zakłócenia na zimno.
• [C-SR-4] Sygnatura czasowa wyjścia zwracana przez AudioTrack.getTimestamp a AAudioStream_getTimestamp z dokładnością do +/-1 ms.

Jeśli implementacje na urządzeniach spełniają powyższe wymagania, po początkowym kalibracji w przypadku korzystania z natywnego interfejsu API AAudio w celu zapewnienia ciągłego odtwarzania. opóźnienie i opóźnienie „na zimno” w co najmniej 1 obsługiwanym dźwięku urządzenia wyjściowego, są to:

• [C-SR-5] Zdecydowanie ZALECANE jest zgłaszanie dźwięku o małym opóźnieniu za pomocą deklaracji Flaga funkcji android.hardware.audio.low_latency.
• [C-SR-6] Zdecydowanie ZALECANY, aby spełnić wymagania małego opóźnienia za pomocą interfejsu AAudio API.
• [C-SR-7] Zdecydowanie zalecamy, aby zapewnić, że w przypadku transmisji powracających AAUDIO_PERFORMANCE_MODE_LOW_LATENCY od AAudioStream_getPerformanceMode(), wartość zwrócona przez AAudioStream_getFramesPerBurst() jest mniejsza od wartości zwróconej przez android.media.AudioManager.getProperty(String) lub jej równa dla klucza właściwości AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Jeśli implementacje urządzeń nie spełniają wymagań dotyczących dźwięku z małym opóźnieniem za pomocą natywnego interfejsu API audio AAudio:

• [C-2-1] NIE MOŻE zgłaszać obsługi dźwięku z małym opóźnieniem.

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

• [C-3-1] Ogranicz błąd w wejściowych sygnaturach czasowych zwracanych przez AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/-2 ms. „Błąd” oznacza odchylenie od prawidłowej wartości.
• [C-3-2] Opóźnienie reakcji „na zimno” wynoszące maksymalnie 500 milisekund.

Jeśli implementacje na urządzeniach obejmują android.hardware.microphone, wartości Zdecydowanie ZALECANE jest spełnienie tych wymagań dotyczących wejściowego dźwięku:

• [C-SR-8] Opóźnienie podczas wczytywania „na zimno” (maksymalnie 100 milisekund) przez mikrofon ścieżki danych. Istniejące i nowe urządzenia z tą wersją Androida są Zdecydowanie ZALECANE jest teraz spełnienie tych wymagań. W przyszłości będziemy wymagać opóźnienia sygnału wejściowego „zimnego” wynoszącego 200 ms lub mniej. To obowiązkowe.
• [C-SR-9] Ciągłe opóźnienie sygnału wejściowego: maksymalnie 30 milisekund.
• [C-SR-10] Zminimalizuj zakłócenia sygnału wejściowego „na zimno”.
• [C-SR-11] Ogranicz błąd w wejściowych sygnaturach czasowych zwracanych przez AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/-1 ms.

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

• [C-SR-12] Zdecydowanie ZALECANY jest średni czas oczekiwania na ruch w obie strony 50 milisekund lub mniej w przypadku 5 pomiarów ze średnim odchyleniem bezwzględnym mniej niż 10 ms, w co najmniej 1 obsługiwanej ścieżce.

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
• [C-1-2] MUSI mieć ciągłe opóźnienie dźwięku w obie strony, zgodnie z definicją w (sekcja 5.6 Opóźnienie dźwięku) – musi wynosić maksymalnie 20 milisekund i musi wynosić 10 milisekund w przypadku co najmniej 1 obsługiwanej ścieżki.
• [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.
• [C-1-5] MUSI spełniać wymagania dotyczące opóźnień i dźwięku przez USB, Natywne reklamy audio AAudio API.
• [C-1-6] Opóźnienie urządzenia „na zimno” musi wynosić maksymalnie 200 milisekund.
• [C-1-7] Opóźnienie reakcji „na zimno” nie może przekraczać 200 milisekund.
• [C-SR-1] Zdecydowanie ZALECANE jest ograniczenie czasu oczekiwania zgodnie z definicją w sekcji 5.6 Opóźnienie dźwięku: 20 milisekund lub mniej, powyżej 5 pomiarów ze średnim odchyleniem bezwzględnym mniejszym niż 5 milisekundy ponad ścieżkę między głośnikiem a mikrofonem.
• [C-SR-2] ZDECYDOWANIE ZALECANE jest w celu spełnienia wymagań dotyczących audio w wersji Pro: ciągłe opóźnienie dźwięku w obie strony, opóźnienie sygnału wejściowego „na zimno” i „na zimno” wymagania dotyczące czasu oczekiwania i dźwięku USB korzystające z interfejsu API AAudio natywnego audio; na ścieżce MMAP.
• [C-SR-3] Zdecydowanie ZALECANE są zapewnić stały poziom procesora wydajność urządzenia przy włączonym dźwięku i obciążenie procesora. Należy to przetestować używając aplikacji SynthMark na Androida. SynthMark wykorzystuje syntezator programowy na symulowanej platformie audio. który mierzy wydajność systemu. Aplikację SynthMark należy uruchomić za pomocą atrybutu „Test automatyczny” i osiągnij te wyniki:
  • voicemark.90 >= 32 głosy
  • czas oczekiwania.fixed.little <= 15 ms
  • opóźnieniemark.dynamic.little <= 50 ms

Zobacz dokumentację SynthMark , gdzie znajdziesz wyjaśnienie wyników testów porównawczych.

• POWINNO zminimalizować niedokładność zegara audio i dryf w stosunku do czasu standardowego.
• POWINNO Zminimalizować dryf zegara audio w stosunku do CPU CLOCK_MONOTONIC gdy obie są aktywne.
• POWINNO Zminimalizować opóźnienie dźwięku przez przetworniki na urządzeniu.
• POWINNO zminimalizować opóźnienie dźwięku podczas korzystania z dźwięku cyfrowego przez USB.
• POWINIEN udokumentować pomiary opóźnienia dźwięku na wszystkich ścieżkach.
• POWINNY być zminimalizowanie zakłóceń podczas wywołań zwrotnych pełnego bufora audio, ponieważ wpływa na użyteczny procent pełnej przepustowości procesora przez wywołanie zwrotne.
• Przy normalnym użytkowaniu z określonym opóźnieniem nie powinno być żadnych zakłóceń w dźwięku.
• POWINNA SIĘ znajdować zerową różnicę czasu oczekiwania między kanałami.
• POWINNA Zminimalizować średni czas oczekiwania MIDI podczas wszystkich transmisji.
• POWINNO zminimalizować zmienność opóźnienia MIDI podczas obciążenia (zakłócenia) podczas wszystkich transmisji.
• NALEŻY podawać dokładne sygnatury czasowe MIDI we wszystkich transmisjach.
• POWINNO zminimalizować szum w sygnałach audio przez przetworniki urządzenia, w tym bezpośrednio po uruchomieniu „na zimno”.
• POWINNO CI zadbać o zerową różnicę zegara audio między wejściem a wyjściem odpowiednich punktów końcowych, gdy oba są aktywne. Przykłady powiązanych takie punkty końcowe obejmują mikrofon i głośnik urządzenia lub wejście audio. i dane wyjściowe.
• POWINNA obsługiwać wywołania zwrotne uzupełniania bufora audio po stronach wejściowych i wyjściowych odpowiednich punktów końcowych w tym samym wątku, gdy oba są aktywne, a następnie wpisz wyjściowe wywołanie zwrotne natychmiast po zwrocie z wywołania zwrotnego. lub jeśli nie możesz obsłużyć wywołań zwrotnych w tym samym wątku, wpisz wkrótce po wprowadzeniu wejściowego wywołania zwrotnego, aby umożliwić aplikacji do utrzymywania stałego czasu wczytywania danych wejściowych i wyjściowych.
• NALEŻY zminimalizować różnicę fazową między buforowaniem dźwięku HAL dla wejścia i stronach wyjściowych odpowiednich punktów końcowych.
• POWINNO zminimalizować opóźnienie dotyku.
• POWINNO zminimalizować zmienność czasu oczekiwania na dotknięcie przy obciążeniu (zakłócenia).
• Czas oczekiwania między sygnałem dotykowym a wyjściem audio musi być mniejszy niż lub równy 40 ms.

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

• [C-SR-4] Zdecydowanie ZALECANE jest zgłoszenie pomocy dotyczącej funkcji android.hardware.audio.pro przez: android.content.pm.PackageManager zajęcia.

Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3, 5 mm:

• [C-2-1] MUSI mieć średni czas oczekiwania na dźwięk w obie strony, zgodnie z definicją w sekcji 5.6 Opóźnienie dźwięku, nieprzekraczające 20 milisekund, na 5 pomiarach ze średnim odchyleniem bezwzględnym mniejszym niż 5 milisekund ścieżkę audio.
• [C-SR-5] Zdecydowanie ZALECANE jest przestrzeganie sekcję Specyfikacja urządzenia mobilnego (gniazda słuchawek). specyfikacji przewodowego zestawu słuchawkowego do dźwięku (wersja 1.1).

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.
• [C-3-2] Ciągłe opóźnienie dźwięku w obie strony musi wynosić Nie więcej niż 25 milisekund, powyżej 5 pomiarów ze średnim odchyleniem bezwzględnym mniej niż 5 milisekund nad portem w trybie hosta USB za pomocą klasy audio USB. (Można to zmierzyć za pomocą przejściówki USB-3,5 mm i sprzężenia zwrotnego audio Użyj klucza sprzętowego lub interfejsu audio USB z kablem krosowym podłączającym dane wejściowe do danych wyjściowych).
• [C-SR-6] Zdecydowanie ZALECANE są jednoczesne korzystanie z maksymalnie 8 kanałów we/wy. w każdym kierunku, częstotliwość próbkowania 96 kHz i głębia 24- lub 32-bitowa (jeśli jest używana) z urządzeniami peryferyjnymi audio USB, które również spełniają te wymagania.
• [C-SR-7] Zdecydowanie ZALECANE jest spełnienia tej grupy wymagań przez zastosowanie natywnego interfejsu API audio AAudio w ramach ścieżki MMAP.

Jeśli urządzenia są wyposażone w port HDMI:

• POWINNA obsługiwać wyjście stereo i 8 kanałów 20-bitowych lub 24-bitowa głębia i 192 kHz bez utraty głębi bitowej ani ponownego próbkowania, w co najmniej 1 konfiguracji.

5.11. Zrób zdjęcie, aby nie zostały przetworzone

Android zapewnia obsługę nagrywania nieprzetworzonego dźwięku za pomocą android.media.MediaRecorder.AudioSource.UNPROCESSED źródło dźwięku. 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.

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)

  • [C-0-2] MUSI obsługiwać narzędzie adb zgodnie z opisem w pakiecie Android SDK i powłoce dostępnych w AOSP, których mogą używać deweloperzy aplikacji, w tym dumpsys cmd stats
  • [C-0-11] MUSI obsługiwać polecenie powłoki cmd testharness. Uaktualniam na urządzeniach ze starszą wersją Androida bez stały blok danych MOŻE być zwolniony z zasady C-0-11.
  • [C-0-3] NIE MOŻE zmieniać formatu ani zawartości systemu urządzenia zdarzenia (batterystats , statystki dysku, odciski cyfrowe, statystyki graficzne, netstats, powiadomienia, procstats) rejestrowanego za pomocą polecenia dumpsys.
  • [C-0-10] MUSI nagrywać bez pominięcia, i wykonywać następujące zdarzenia dostępne dla polecenia powłoki cmd stats oraz StatsManager klasa Systemowego interfejsu API.
    • Zmieniono stan działania pierwszego planu
    • Wykryto anomalię
    • Zgłoszono menu nawigacyjne aplikacji
    • Wystąpiła awaria
    • Uruchomienie aplikacji
    • Poziom baterii został zmieniony
    • Zmieniono stan trybu oszczędzania baterii
    • Odebrano BleScanResult
    • Stan BleScanState zmieniony
    • Zmieniono stan ładowania
    • Zmieniono stan bezczynności urządzenia
    • Zmieniono stan usługi na pierwszym planie
    • Zmieniono stan skanowania GPS
    • Stan zadania zmieniony
    • Stan wtyczki zmieniony
    • Zmieniono stan zaplanowanego zadania
    • Zmieniono stan ekranu
    • SyncState (Zmiana stanu)
    • Czas rzeczywisty po upłynięciu systemu
    • Zmieniono stan procesu UidProcess
    • Stan uśpienia został zmieniony
    • Pojawił się Budzik
    • Zmiana stanu blokady Wi-Fi
    • Zmiana stanu blokady Wi-FiMulticastLock
    • Zmiana stanu skanowania Wi-Fi
  • [C-0-4] demon adb po stronie urządzenia MUSI być domyślnie nieaktywny i włączenie debugowania Androida MUSI dostępny dla użytkownika mechanizm. Most.
  • [C-0-5] MUSI obsługiwać bezpieczne narzędzie adb. Android zapewnia obsługę adb. Bezpieczny adb włącza narzędzie adb na znanych uwierzytelnionych hostach.
  • [C-0-6] MUSI zawierać mechanizm umożliwiający połączenie adb z na komputerze. Więcej szczegółów:

  Jeśli implementacje urządzeń bez portu USB obsługują tryb peryferyjny:

  • [C-3-1] MUSI zaimplementować adb przez sieć lokalną (np. Ethernet lub Wi-Fi).
  • [C-3-2] MUSI dostarczyć sterowniki dla Windows 7, 8 i 10, co pozwala na łączenie się z urządzeniem przez protokół adb.

  Jeśli implementacje urządzeń obsługują połączenia adb z hostem przez Wi-Fi:

  • [C-4-1] MUSI zawierać metodę AdbManager#isAdbWifiSupported() zwróć true.

  Jeśli implementacje urządzeń obsługują połączenia adb z hostem przez Wi-Fi i co najmniej 1 kamera:

  • [C-5-1] MUSI zawierać metodę AdbManager#isAdbWifiQrSupported() zwróć true.

• Usługa monitorowania debugowania Dalvik (ddms)

  • [C-0-7] MUSI obsługiwać wszystkie funkcje ddms zgodnie z dokumentacją pakietu Android SDK. Ponieważ pakiet ddms używa narzędzia adb, obsługa ddms powinna być domyślnie nieaktywna, ale MUSI być obsługiwana za każdym razem, gdy użytkownik aktywował Android Debug Bridge. jak powyżej.

• Małpa

  • [C-0-8] MUSI zawierać platformę Monkey i udostępnić ją i aplikacjach.

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

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ład odpowiedni dla urządzenia, tak aby aplikacje innych firm działać na różnych konfiguracjach sprzętowych. Na wyświetlaczach zgodnych z Androidem, na których wszystkie urządzenia innych firm aplikacje MUSZĄ właściwie implementować te interfejsy API. i zachowań, jak opisano w tej sekcji.

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

• fizyczny rozmiar przekątnej. Odległość między dwoma przeciwległymi obiektami w calach w rogach podświetlonej części wyświetlacza.
• punktów na cal (dpi). Liczba pikseli ujętych przez obiekt liniowy na poziomie lub w pionie wynoszącym 1, Podaje wartości dpi (zarówno w poziomie, jak i w poziomie) i dpi w pionie muszą mieścić się w danym 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 Ekran o rozdzielczości 160 dpi, obliczany w ten sposób: piks. = dps * (gęstość/160).

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar i kształt ekranu

Platforma interfejsu Androida obsługuje różne logiczne 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 na urządzeniach obsługują UI_MODE_TYPE_NORMAL i zawierają parametr Wyświetlacze zgodne z Androidem z zaokrąglonymi rogami:

• [C-1-1] MUSI spełniać co najmniej jedno z następujących wymagań jest spełniony:

  • Promień zaokrąglonych rogów nie przekracza 38 dp.
  • Gdy pole o wymiarach 15 dp na 15 dp jest zakotwiczone w każdym rogu pola logicznego, 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ądzeń obejmują wyświetlacze zgodne z Androidem, które: składa się lub jest wyposażony w zawias pomiędzy kilkoma panelami takie wyświetlacze dostępne do renderowania aplikacji innych firm:

• [C-2-1] MUSI wdrożyć najnowszą dostępną stabilną wersję interfejs API rozszerzeń lub stabilna wersja sidecar API do wykorzystania przez bibliotekę Window Manager Jetpack.

Jeśli implementacje urządzeń obejmują wyświetlacze zgodne z Androidem, które: składa się lub jest wyposażony w zawias pomiędzy kilkoma panelami zawias lub zawias przecina pełnoekranowe okno aplikacji, dlatego:

• [C-3-1] MUSI zgłosić położenie, granice i stan zawiasu lub zawinięcia lub pomocnicze interfejsy API do aplikacji.

Szczegółowe informacje na temat prawidłowego wdrażania interfejsów API pomocniczych lub rozszerzeń znajdziesz w dokumentacji do publicznej dokumentacji Window Manager Jetpack.

7.1.1.2. Współczynnik proporcji ekranu

Nie ma żadnych ograniczeń dotyczących formatu obrazu fizycznego wyświetlacza wyświetlaczy zgodnych z systemem Android, format obrazu miejsce, w którym są renderowane aplikacje innych firm. Dane te można określić na podstawie wysokości wartości szerokości zgłaszanych w funkcji view.Display Interfejsy API i konfiguracja Interfejsy API MUSZĄ spełniać następujące wymagania:

• [C-0-1] Implementacje na urządzeniach z wartością Configuration.uiMode ustawioną na Współczynnik proporcji UI_MODE_TYPE_NORMAL MUSI mieć format obrazu mniejszy lub równy do 1,86 (około 16:9), chyba że aplikacja spełnia jeden z tych warunków warunki:

  • Aplikacja zadeklarowała, że obsługuje większy format ekranu przez android.max_aspect wartości metadanych.
  • Aplikacja deklaruje, że można zmienić jej rozmiar w elemencie android:resizeableActivity. .
  • Aplikacja jest kierowana na interfejs API na poziomie 24 lub wyższym i nie deklaruje android:maxAspectRatio które ograniczałyby dozwolony format obrazu.

• [C-0-3] Implementacje na urządzeniach z wartością Configuration.uiMode ustawioną jako UI_MODE_TYPE_WATCH MUSI mieć współczynnik proporcji ustawiony na 1,0 (1:1).

7.1.1.3 Gęstość ekranu

Platforma UI Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić którzy chcą wykorzystywać zasoby aplikacji.

• [C-0-1] Domyślnie implementacje urządzeń MUSZĄ zgłaszać tylko jeden Gęstości platformy Androida wymienione na DisplayMetrics za pomocą interfejsu API DENSITY_DEVICE_STABLE a ta wartość NIE MOŻE W żadnym momencie zmieniać; jednak urządzenie MOŻE zgłosić różne gęstości w zależności od konfiguracji wyświetlacza. zmiany wprowadzone przez użytkownika (np. rozmiar wyświetlacza) ustawione po początkowym uruchamianie.

• Implementacje na urządzeniach NALEŻY określić standardową gęstość platformy Androida która jest zbliżona do fizycznej gęstości ekranu, chyba że gęstość logiczna powoduje, że raportowany rozmiar ekranu jest poniżej obsługiwanego rozmiaru minimalnego. Jeśli standardowa gęstość platformy Androida, która jest najbliższa liczbowo gęstość fizyczna powoduje, że rozmiar ekranu jest mniejszy niż najmniejszy obsługiwane zgodne rozmiary ekranu (szerokości 320 dp), implementacje urządzeń POWINIENIE w raportach o kolejnej najmniejszej standardowej gęstości platformy Androida.

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

• [C-1-1] Rozmiar wyświetlacza NIE MOŻE być skalowany w większym stopniu niż 1,5 raza gęstości natywnej ani generują efektywny minimalny wymiar 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] Rozmiar wyświetlacza NIE MOŻE być skalowany w sposób mniejszy niż 0,85 raza gęstości natywnej.
• 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 uwzględniać żą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:

• [C-1-1] MUSI obsługiwać zarówno platformę OpenGL ES 1.1, jak i 2.0, zarówno w wersji [C-1-1], jak i dokładniejszej. w dokumentacji pakietu SDK na Androida.
• [C-SR-1] Zdecydowanie ZALECANE są obsługa OpenGL ES 3.1.
• MUSI obsługiwać standard OpenGL ES 3.2.

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

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 interfejs Vulkan

Android zapewnia obsługę 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 włączenie obsługi Vulkan 1.1.

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

• POWINNO obsługiwać platformę Vulkan 1.1.

Testy Vulkan dEQP są podzielone na 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łoszonego przez siebie, wskazuje, że może przejść dEQP testów na wszystkich listach testowych na tym poziomie i starszych.

Jeśli implementacje urządzeń obsługują standard Vulkan 1.0 lub nowszy:

• [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 natywny interfejs API vkEnumeratePhysicalDevices() ,
• [C-1-3] MUSI w pełni wdrożyć interfejsy Vulkan 1.0 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 ustaw jako 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-2] Zdecydowanie ZALECANE jest wsparcie dla VK_KHR_driver_properties i VK_GOOGLE_display_timeming.

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

• [C-3-1] MUSI udostępniać obsługę zewnętrznego semfora i uchwytu SYNC_FD i rozszerzenie VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Implementacje na urządzeniach MUSZĄ obsługiwać Android RenderScript (zgodnie ze szczegółowym opisem). znajdziesz w dokumentacji pakietu Android SDK.

Przyspieszenie grafiki 2D 7.1.4.4

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

• [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 wdrożyć komponent 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 formaty określone w zasadzie 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. dotknięcia, dwukrotnego kliknięcia lub gestu palca), gdy któreś 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ń.

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-2] 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ć udostępniana jako przesunięcie od lewą i prawą krawędź 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.

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 zmiany stanu zachodzące na wskaźniku przesuwającym się w dół lub w górę na 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 sposób rozsądny 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ć sumę zużycia energii przez poszczególne czujniki.

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ą 3-osiowy akcelerometr:

• [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-2] MUSI wdrożyć i zgłosić stronę TYPE_ACCELEROMETER .
• [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Android. jak opisano w interfejsach API Androida.
• [C-1-4] MUSI być w stanie mierzyć od swobodnego spadania do czterech razy większej grawitacja(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.
• [C-SR-2] Zdecydowanie ZALECANE jest wdrożenie TYPE_SIGNIFICANT_MOTION czujnika kompozytu.
• [C-SR-3] Zdecydowanie ZALECANE jest wdrożenie i raportowanie TYPE_ACCELEROMETER_UNCALIBRATED. . Urządzenia z Androidem są Zdecydowanie ZALECANE, aby spełnić to wymaganie, dlatego więc będzie można uaktualnić ją do przyszłej wersji platformy, stanie się WYMAGANE.
• NALEŻY zaimplementować TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER czujników kompozytowych zgodnie z opisem w dokumentacji pakietu Android SDK.
• POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.
• Rozdzielczość powinna wynosić co najmniej 16 bitów.
• NALEŻY kalibrować podczas używania, jeśli parametry zmienią się cykl życia i wynagrodzenie oraz zachowanie parametrów wynagrodzenia między restartami urządzeń.
• POWINNA być kompensowana temperatura.

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-2-1] Suma ich zużycia 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-3-1] MUSI wdrożyć zasady TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION i komponentów.
• [C-SR-4] Zdecydowanie ZALECANE jest wdrożenie TYPE_GAME_ROTATION_VECTOR czujnika kompozytu.

Jeśli w urządzeniach jest 3-osiowy akcelerometr, 3-osiowy żyroskop i czujnik magnetometru:

• [C-4-1] MUSI zaimplementować czujnik kompozytowy TYPE_ROTATION_VECTOR.

7.3.2 Magnetometr

Implementacje na urządzeniach:

• [C-SR-1] Zdecydowanie ZALECANE jest użycie 3-osiowego magnetometru (kompasu).

Jeśli urządzenia są wyposażone w 3-osiowy magnetometr:

• [C-1-1] MUSI zamocować czujnik TYPE_MAGNETIC_FIELD.
• [C-1-2] MUSI 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 za pomocą interfejsu GNSS Location Provider API 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 3-osiowy żyroskop:

• [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-2] MUSI zamocować czujnik TYPE_GYROSCOPE.
• Rozdzielczość [C-1-4] MUSI mieć co najmniej 12 bitów.
• [C-1-5] MUSI mieć kompensację temperatury.
• [C-1-6] MUSI być skalibrowany i skompensowany podczas używania. 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 jest wdrożenie TYPE_GYROSCOPE_UNCALIBRATED .
• [C-SR-4] Zdecydowanie ZALECANE są rozdzielczość 16-bitowa lub większa.
• POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.

Jeśli urządzenia są wyposażone w 3-osiowy żyroskop, i czujnik magnetometru:

• [C-2-1] MUSI zaimplementować czujnik kompozytowy TYPE_ROTATION_VECTOR.

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

• [C-3-1] MUSI wdrożyć zasady TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION czujników kompozytowych.
• [C-SR-5] 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 odczyt binarny „w pobliżu” lub „daleko”, oznacza to, że:

• [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, 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 są domyślnie klasyfikowane jako klasa 1 i muszą spełnić dodatkowe wymagania opisane poniżej, jeśli firma chce zostać sklasyfikowana jako Klasa 2 lub Class 3. Klasa 2 i klasa 3 biometria uzyskuje dodatkowe możliwości, które opisaliśmy poniż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.

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-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 maksymalnie 20 fałszywych próbach 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-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.
• [C-1-5] MUSI całkowicie usunąć wszystkie dane biometryczne umożliwiające identyfikację użytkownika po usunięciu konta użytkownika (także przez przywrócenie go do ustawień fabrycznych).
• [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 ).
• [C-1-7] MUSI wymagać uwierzytelniania użytkownika za pomocą zalecanego podstawowego uwierzytelniania (np.kod PIN, wzór, hasło): a) co 24 godziny lub częściej w przypadku urządzeń. uruchamianie aplikacji na urządzeniach z Androidem w wersji 9 lub nowszej albo b) co 72 godziny lub rzadziej, na urządzeniach z Androidem 8 lub starszym.

• [C-1-8] MUSI wymagać uwierzytelniania użytkownika za pomocą zalecanego podstawowego uwierzytelniania (np. kod PIN, wzór, hasło) lub biometrię klasy 3 (STRONG) po jednym ze :

  • 4-godzinny limit czasu bezczynności LUB

  • 3 nieudane próby uwierzytelnienia biometrycznego.

• [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, aby wskaźnik fałszywych odrzuceń wynosił mniej niż 10%, zgodnie z pomiarem na urządzeniu.

• [C-SR-9] Zdecydowanie ZALECANE jest opóźnienie poniżej 1 sekundy, mierzone od momentu wykrycia danych biometrycznych do odblokowania ekranu zarejestrowanej biometrii.

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% zgodnie z danymi protokołów testów biometrycznych Androida.
• [C-2-3] MUSI wykonać dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza Androidem użytkownika lub przestrzeni jądra systemu, takich jak Trusted Execution Environment (TEE) lub na układzie z bezpiecznym kanałem i izolowanym środowiskiem wykonawczym.
• [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 w witrynie Android Open Source Project.
• [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 w bezpiecznym kanale do izolowanego środowiska wykonawczego.
  • 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 indywidualne rejestracje biometryczne.
• [C-2-7] NIE MOŻE zezwalać na nieszyfrowany dostęp do elementów umożliwiających identyfikację danych biometrycznych lub jakichkolwiek danych pochodzących z nich (takich jak wektory dystrybucyjne) podmiotu przetwarzającego aplikację poza kontekstem TEE. Uaktualnianie urządzeń wprowadzone na urządzeniach z Androidem w wersji 9 lub starszej nie są zwolnione z obowiązku spełnienia wymogów 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 fałszywie uwierzytelniać się jako użytkownik.

• [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 określone w powyższej klasie 2 z wyjątkiem [C-1-7] i [C-1-8].
• [C-3-2] MUSI mieć implementację magazynów kluczy wspieranych sprzętowo.
• [C-3-3] MUSI mieć współczynnik akceptacji imitacji fałszywych niż 7% zgodnie z danymi protokołów 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) co 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.

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.12. Czujnik pozycji

Implementacje na urządzeniach:

• MOŻE obsługiwać czujnik pozycji z 6 stopniami swobody.

Jeśli implementacje urządzeń obsługują czujnik pozycji z sześcioma stopniami swobody:

• [C-1-1] MUSI wdrożyć i zgłosić stronę TYPE_POSE_6DOF .
• [C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.

7.3.13. Czujnik kąta nachylenia

Jeśli urządzenia obsługują czujnik kąta zawiasu:

• [C-1-1] MUSI wdrożyć i zgłosić stronę TYPE_HINGLE_ANGLE.
• [C-1-2] MUSI obsługiwać co najmniej 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.4 Połączenie transmisji danych

7.4.1 Telefonia

Termin „telefonia” jest używany w interfejsach API Androida, a w tym dokumencie ze sprzętem do nawiązywania połączeń głosowych i wysyłania SMS-ów w ramach GSM. lub sieci CDMA. Mimo że w tych połączeniach głosowych przełączanie pakietów nie jest możliwe, są wykorzystywane do celów związanych z Androidem uważanych za niezależne od jakichkolwiek danych. które można wdrożyć w tej samej sieci. Innymi słowy, funkcje „telefonii” na Androidzie i interfejsy API odnoszą się w szczególności do Voice, połączenia i SMS-y. Dotyczy to na przykład implementacji urządzeń, które nie umożliwiają nawiązywania połączeń wysyłanie/odbieranie wiadomości SMS nie jest uważane za urządzenie telefoniczne, czy używają sieci komórkowej do przesyłania 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 zawierać pełną implementację EuiccManager API.

Jeśli implementacje urządzeń nie ustawią w usłudze systemowej ro.telephony.iwlan\_operation\_mode ustawienia „Legacy” (starsza wersja), wykonaj te czynności:

• [C-4-1] NIE MOŻE zgłaszać treści „NETWORK_TYPE_IWLAN” za pomocą NetworkRegistrationInfo#getAccessNetworkTechnology() gdy NetworkRegistrationInfo#getTransportType() jest zgłaszany jako „TRANSPORT_TYPE_WWAN” w przypadku tej samej instancji NetworkRegistrationInfo.

Jeśli implementacje urządzeń obsługują 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ć 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ć parametr android.hardware.telephony.ims.singlereg flagę funkcji i zapewnić pełną implementację interfejsu SipTransport API. interfejs API GbaService, dedykowanych użytkowników za pomocą interfejsu 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.

7.4.1.1 Zgodność z blokadami numerów

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

• [C-1-1] MUSI obsługiwać blokowanie numerów
• [C-1-2] MUSI w pełni 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] NIE MOŻE zapisywać do dostawcy rejestru połączeń platformy w przypadku zablokowanego połączenia.
• [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.

7.4.1.2. Telecom API

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

• [C-1-1] MUSI obsługiwać interfejsy API ConnectionService opisane w pakiecie SDK.
• [C-1-2] MUSI wyświetlić nowe połączenie przychodzące i 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-1] 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 na kluczu dodatków od PhoneAccount do true.

• [C-SR-2] 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.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.
• [C-1-4] MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) w dowolnej chwili działania, w tym:
  • Nawet wtedy, gdy ekran nie jest aktywny.
  • Urządzenia z Android TV, nawet w trybie gotowości stanów zasilania.
• [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 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() i WifiManager.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 i onServiceDiscoveredWithinRange.

7.4.2.4. Punkt dostępu Wi-Fi

Jeśli implementacje urządzeń obsługują standard 802.11 (Wi-Fi):

• [C-1-1] MUSI obsługiwać punkt dostępu Wi-Fi.
• [C-1-2] MUSI 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 implementacje urządzeń nie obsługują Wi-Fi, Hasło:

• [C-2-1] Wdrożenie interfejsu WifiManager związanego z Passpoint Interfejsy API MUSZĄ zgłosić UnsupportedOperationException.

Jeśli podany jest globalny przełącznik kontroli użytkownika w trybie Passpoint, implementacje:

• [C-3-1] Domyślnie MUSI włączać Passpoint.

7.4.2.5. Lokalizacja Wi-Fi (czas w obie strony przez Wi-Fi – RTT)

Implementacje na urządzeniach:

• POWINNO_obsługiwać lokalizację przez Wi-Fi.

Jeśli implementacje urządzeń obejmują obsługę lokalizacji Wi-Fi i udostępniają 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 na 68. centylu (zgodnie z wynikami obliczeń skumulowanych funkcji dystrybucji).

7.4.2.6 Odciążanie Wi-Fi

Implementacje na urządzeniach:

• POWINNO_obsługiwać odciążanie Wi-Fi.

Jeśli implementacje urządzeń obejmują obsługę odciążania Wi-Fi i ujawniają te funkcje aplikacjom innych firm,

• [C-1-1] MUSI obsługiwać Interfejs API SocketKeepAlive.

• [C-1-2] MUSI obsługiwać co najmniej 3 przedziały utrzymywania aktywności równoczesnej przez Wi-Fi i co najmniej 1 przedział utrzymywania aktywności przez sieć komórkową.

Jeśli implementacje urządzeń nie obsługują odciążania Wi-Fi, 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, aby ręcznie dodać korporacyjną sieć Wi-Fi, w aplikacji Ustawienia.

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.

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 takiego jak 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 sieci dowolnego typu, w tym sieci komórkowej/komórkowej, Wi-Fi, Ethernet 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 przez 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.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.

7.5.1 Kamera tylna

Tylny aparat to kamera znajdująca się z boku po przeciwnej stronie ekranu. czyli obrazowanie scen z daleka jak w przypadku tradycyjnego aparatu fotograficznego.

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 kamera znajdująca się po tej samej stronie urządzenia jako wyświetlacz, czyli aparat zwykle używany do robienia zdjęć użytkownika, , jak w przypadku wideokonferencji i podobnych aplikacji.

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 za pomocą 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

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ć „sfałszowane” 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Ą uznawać 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] W przypadku urządzeń z wieloma kamerami RGB skierowanymi w tę samą stronę są Zdecydowanie ZALECANE do obsługi aparatów logicznych, które zawierają 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.

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 wysłała żądanie android:requestLegacyExternalStorage="true" w pliku manifestu.
• [C-0-5] MUSI usuwać metadane lokalizacji, takie jak tagi Exif GPS, plików multimedialnych, gdy są one otwierane przez aplikację 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 klasy 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 używanie zakresu prądu wyjściowego CDP(CDP) jako wymienione w specyfikacjach ładowania baterii 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).
• [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 czy sieć komórkowa nie obsługują „portu wyjściowego”.

7.8.2.1 Analogowe porty audio

Aby były zgodne z zestawami słuchawkowymi i innymi akcesoriami 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

Aby były zgodne z zestawami słuchawkowymi i innymi akcesoriami audio, Złącza USB-C i wdrażanie (klasa audio USB) w ekosystemie Androida jak opisano w specyfikacji zestawu słuchawkowego USB na Androida.

Wymagania związane z poszczególnymi urządzeniami znajdziesz w artykule 2.2.1.

7.8.3 Prawie ultradźwiękowy

Dźwięk Near ultradźwiękowy to pasmo 18,5–20 kHz.

Implementacje na urządzeniach:

• MUSI prawidłowo zgłaszać zespół pomocy możliwość korzystania z dźwięku bliskiego ultradźwięku w interfejsie AudioManager.getproperty interfejsu 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	&lt; 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] MUSISZ zaimplementować obsługę klienta 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 umożliwia 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 ZALECANY jest czas oczekiwania na efekt przejścia między ruchem a fotonem. 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 podstawowa wersja podstawowa:

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

Wymagania związane z poszczególnymi urządzeniami znajdziesz w artykule 2.2.1.

7.11. Zajęcia dotyczące skuteczności mediów

O klasie wydajności mediów w przypadku implementacji urządzenia można uzyskać z android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS. Wymagania Dla każdej wersji Androida określa się klasę wydajności multimediów, 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.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.

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żywane na potrzeby aplikacji Tryb gotowości.
• [C-1-4] MUSI zaimplementować Zasobniki gotowości aplikacji i Uśpienie jako opisane w artykule Zarządzanie zasilaniem.
• [C-1-5] MUSI zwrócić produkt 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ż zasobnika rzadkich aplikacji w trybie gotowości, sekcji 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 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: PROTECTION_FLAG_PRIVILEGED MOŻNA przyznawać tylko aplikacjom wstępnie zainstalowanym w ramach ścieżek z podwyższonymi uprawnieniami w systemie obrazu oraz w podzbiorze uprawnień znajdujących się na liście dozwolonych dla każdego z nich . Implementacja AOSP spełnia to wymaganie, ponieważ odczytuje lista dozwolonych uprawnień dla poszczególnych aplikacji, które znajdują się w etc/permissions/, a ścieżka system/priv-app jako ścieżki z podwyższonymi uprawnieniami.

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-4] MUSI zawierać jedną i tylko jedną implementację obu tagów i interfejsów.
• [C-0-5] NIE MOŻE przyznawać żadnych uprawnień czasu działania aplikacji instalowanej fabrycznie chyba że:
  • Zgodę użytkownika można uzyskać przed złożeniem wniosku z niego korzysta.
  • Uprawnienia w czasie działania są powiązane z wzorcem intencji dla których wstępnie zainstalowana aplikacja jest ustawiona jako domyślny moduł obsługi.
• [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 na urządzeniach opisane w sekcji „9.8.6 Rejestrowanie treści”.
• [C-4-2] NIE MOŻE mieć uprawnienia android.permission.INTERNET. Jest to bardziej rygorystyczne niż Zdecydowanie ZALECANE Treści wymienione w artykule 9.8.6.
• [C-4-3] NIE MOŻE tworzyć powiązań z innymi aplikacjami, z wyjątkiem tych aplikacji systemowych: Bluetooth, Kontakty, Media, Telefonia, SystemUI oraz komponenty udostępniające internetowe interfejsy API.Jest to bardziej rygorystyczne niż Zdecydowanie ZALECANE w sekcji 9.8.6.

9.2. UID i izolacja procesów

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać 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ępu 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 lub 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.

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-8] 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-9] 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-10] 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-11] 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-12] Zdecydowanie ZALECANE jest używanie standardowego protokołu pamięci w systemie Android i TEE, jak np. platforma Armware Framework Armv8-A (FF-A).
• [C-SR-13] 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.

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ć i uzyskiwać wyraźną zgodę użytkownika na wykorzystanie danych wrażliwych informacje wyświetlane na ekranie użytkownika, przechwycone za każdym razem, przesyłanie ekranu lub nagrywanie ekranu jest włączone w MediaProjection lub zastrzeżone interfejsy API. NIE MOŻE zapewniać użytkownikom możliwości wyłączenia w przyszłości wyświetlania zgody użytkownika.
• [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.

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 Zbieranie treści zgodnie z artykułem 9.8.6:

• [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 widok na ekranie, który jest stale widoczny. 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 kamery” oznacza widok na ekranie, który jest stale widoczny 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 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 Rejestrowanie treści i wyszukiwanie aplikacji

na Androidzie za pomocą interfejsu System API ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query lub inny zastrzeżonych środków, obsługuje mechanizm implementacji urządzenia do przechwytywania następujące interakcje danych aplikacji między aplikacjami użytkownik:

• 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 inne zdarzenia przekazywane przez aplikację do systemu za pomocą Content Capture API lub AppSearchManager API o podobnej możliwości w wersji na Androida lub zastrzeżonego interfejsu API.
• 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.

Jeśli implementacje urządzeń rejestrują powyższe dane:

• [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] Wszystkie takie dane oraz dziennik urządzenia MUSI wysyłać tylko za pomocą mechanizm ochrony prywatności. 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, takiej jak 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 Rejestrowanie treści), chyba że każdorazowo za wyraźną zgodą użytkownika jest udostępniany.
• [C-1-6] MUSI dostarczyć informacje na temat możliwości usunięcia danych, które ContentCaptureService lub zastrzeżone środki zbierają, jeśli są przechowywane na urządzeniu w dowolnej formie.
• [C-1-7] MUSI zapewniać użytkownikowi zgodę na rezygnację z zbierania danych za pośrednictwem AppSearch lub zastrzeżonych środków na platformie Android. np. Menu z aplikacjami.
• [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.

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 wiązania usługi lub identyfikatorów procesów udostępniania) oprócz tych:

  • Telefonia, kontakty, interfejs systemu i multimedia

Android w wersji SpeechRecognizer#onDeviceSpeechRecognizer() umożliwia rozpoznawania mowy na urządzeniu bez korzystania z sieci. Każda implementacja Speech korekty na urządzeniu MUSI być zgodna z zasadami. opisane w tej sekcji.

9.8.7 Dostęp do schowka

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE zwracać zapisanych w schowku skróconych danych (np. ClipboardManager API), chyba że jest to domyślny edytor IME lub ostrość.

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 sieci komórkowej (3G, 4G, 5G... łącznie z modemem komórkowym w przyszłości) 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 interfejsu Emergency Location Bypass API 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; lub narzędzie do implementacji za pomocą systemu 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).
  • Pobierz dostawcę, który korzysta z urzędu dostawcy „pobierania” 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 katalogów „obb” w celu 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
• [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ęć masową i 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.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 jest klucz 512-bitowy. Adiantum odnosi się do Adiantum-XChaCha12-AES, jak określono 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 przy użyciu AES-256-CBC-CTS 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 w przypadku urządzeń opartych na 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 technologii 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 starszej wersji Androida i nie można dodać tej obsługi 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-SR-1] Jeśli w urządzeniu jest kilka osobnych układów scalonych (np. radio, wyspecjalizowanego procesora obrazów), proces uruchamiania każdego z tych układów Zdecydowanie ZALECANE jest sprawdzenie każdego etapu po uruchomieniu.
• [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ęć 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).
• [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.

Jeśli implementacje na urządzeniach zostały już wdrożone bez obsługi procesów od C-1-8 do C-1-11 na starszej wersji Androida i nie można dodać obsługi tych wymagań wraz z aktualizacją oprogramowania systemowego mogą zostać zwolnione z .

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.

Implementacje na urządzeniach:

• [C-0-3] MUSI obsługiwać kryptograficzną weryfikację treści pliku w zaufanym kluczem bez odczytu całego pliku.
• [C-0-4] NIE MOŻE zezwalać na realizację żądań odczytu chronionego pliku , gdy odczytywana treść nie jest weryfikowana za pomocą zaufanego klucza.

jeśli implementacje urządzeń zostały już uruchomione bez możliwości weryfikacji, zawartości pliku 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.

Implementacje na urządzeniach:

• [C-SR-4] Zdecydowanie ZALECANE jest obsługa interfejsu Android Protected Confirmation API.

Jeśli implementacje urządzeń obsługują Bezpieczne potwierdzenie w Androidzie API:

• [C-3-1] MUSI zgłosić true za ConfirmationPrompt.isSupported() API.

• [C-3-2] MUSI zadbać o to, aby kod działający w systemie operacyjnym Android jądro (złośliwego oprogramowania) ani w inny sposób nie może wygenerować pozytywnej odpowiedzi bez interakcji użytkownika.

• [C-3-3] MUSI upewnić się, że użytkownik był w stanie przejrzeć i zatwierdzić wyświetlany komunikat nawet w przypadku, gdy system operacyjny Android, w tym jego jądro, jest przejęte.

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. Przy liczbie nieudanych prób podany jest n, czas interwał 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, w zależności od tego, która z tych wartości jest krótsza.
• 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 kryptograficzne RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1 i SHA-2, aby zapewnić prawidłową obsługę obsługiwane przez system Android Keystore na obszarze bezpieczniejszym izolowane od kodu działającego w jądrze i nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, które mogłyby umożliwić dostęp jądra systemu lub przestrzeni użytkownika wewnętrzny stan odizolowanego środowiska, w tym DMA. Nadrzędna Android Open Source Project (AOSP) spełnia to wymaganie dzięki wykorzystaniu 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ązania.
• [C-1-3] MUSI przeprowadzić uwierzytelnianie ekranu blokady w i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem dopiero po pomyślnym uwierzytelnieniu. 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.
• [C-1-4] MUSI obsługiwać atest klucza, gdy klucz podpisywania atestu to zabezpieczane przez bezpieczny sprzęt, a podpisywanie jest realizowane na bezpiecznym sprzęcie. Klucze podpisywania atestu MUSZĄ być udostępniane przez wystarczającą liczbę urządzeń, aby uniemożliwia używanie kluczy jako identyfikatorów urządzeń. Aby to osiągnąć, wymagamy, aby używali tego samego klucza atestu, chyba że liczba jednostek wynosi co najmniej 100 tys. dla danego kodu SKU. Jeśli wyprodukowana zostanie ponad 100 tys. sztuk produktu, dla każdej 100 000 jednostek MOŻE być używany inny klucz.

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 lub
  • IKeyMintDevice w wersji 1.
• [C-SR-1] Zdecydowanie ZALECANY jest obsługa IKeyMintDevice w wersji 1.

9.11.1. Bezpieczny ekran blokady i uwierzytelnianie

Implementacja AOSP 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.

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 awaryjności, 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 wszelkimi powiązanymi flagami biometrycznymi (np. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE lub KEYGUARD_DISABLE_IRIS).

Jeśli metody uwierzytelniania biometrycznego nie spełniają wymagań 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 na 4 godz. lub mniej.
• [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-8] Użytkownik MUSI otrzymać wyzwanie dotyczące jednego z zalecanych głównych uwierzytelniania (np. za pomocą kodu PIN, wzoru, hasła) co najmniej raz na 72 godz., chyba że ze względu na bezpieczeństwo użytkownika (np. rozpraszanie uwagi kierowcy) jest problemem.
• [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 interfejsie 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ń 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-10] MUSI zawierać sprzęt zgodny z Bezpieczny profil ochrony IC BSI-CC-PP-0084-2014 lub oceniane przez akredytowane w całym kraju laboratorium, w którym wykorzystano Ocena podatnego na atak luk w zabezpieczeniach według Stosowanie potencjału ataku na kartach inteligentnych (Common Criteria).
  • [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 jest zwiększenie odporności na atak osób wtajemniczonych (IAR), co oznacza, że osoba wtajemniczona mająca dostęp do kluczy podpisywania oprogramowania nie może wygenerować które powoduje ujawnianie obiektów tajnych przez StrongBox w celu ominięcia funkcjonalnego oprogramowania układowego wymagania zabezpieczeń lub w inny sposób umożliwiać dostęp do poufnych danych użytkownika. zalecanym sposobem implementacji IAR jest zezwalanie na aktualizacje oprogramowania tylko wtedy, gdy główne hasło użytkownika jest dostarczane 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 bez są spełnione warunki kontroli, MAC nie może być tworzony dla dowolnego ), nawet jeśli Android działa w sposób niewłaściwy lub przejęty.

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.

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

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

Aby zobaczyć podsumowanie zmian w sekcjach dotyczących poszczególnych osób:

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

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

Zmiany są oznaczane w ten sposób:

• CDD
  Istotne zmiany w wymaganiach dotyczących zgodności.

• Dokumenty
  Zmiany kosmetyczne lub związane z wprowadzeniem.

Aby uzyskać najlepsze wyniki, dołącz parametry adresu URL pretty=full i no-merges do tagu przy użyciu URL-i dziennika zmian.

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.