1. Wprowadzenie
Ten dokument zawiera listę wymagań, które muszą zostać spełnione, aby urządzenie aby była zgodna z Androidem 13.
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 sprzęt i oprogramowanie z Androidem, 13. „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 13, 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ą się jako „Podstawowe wymagania”. w tym dokumencie.
1.1.2 Identyfikator wymagania
W przypadku wymagań MUSZĄ przypisano identyfikator wymagania.
- Identyfikator jest przypisywany tylko w przypadku wymagań MUST.
- Zdecydowanie ZALECANE wymagania są oznaczone jako [SR], ale identyfikator nie jest przypisany.
- Identyfikator składa się z tych elementów : identyfikator typu urządzenia – identyfikator warunku – identyfikator wymagania (np. C-0-1).
Każdy identyfikator jest zdefiniowany poniżej:
- Identyfikator typu urządzenia (więcej informacji znajdziesz w sekcji 2. typy urządzeń)
- C: podstawowy (wymagania dotyczące wszystkich implementacji na urządzeniach z Androidem)
- H: przenośne urządzenie z Androidem
- T: urządzenie z Androidem TV
- O: Wdrożenie Androida Automotive
- W: Implementacja na zegarku Android Watch
- Karta: Implementacja na tabletach z Androidem
- Identyfikator warunku
- Gdy wymaganie jest bezwarunkowe, ten identyfikator ma wartość 0.
- Gdy wymaganie jest warunkowe, za 1 miejsce zostanie przypisana wartość 1 , a liczba zwiększa się o 1 w tej samej sekcji i urządzenia tego samego typu.
- Identyfikator wymagania
- Ten identyfikator rozpoczyna się od 1 i zwiększa o 1 w tej samej sekcji oraz taki sam warunek.
1.1.3 Identyfikator wymagania w sekcji 2
Identyfikatory wymagań w sekcji 2 składają się z 2 części. Pierwszy odpowiada identyfikatorowi sekcji opisanym powyżej. Druga część określa format i wymagania dotyczące konkretnego formatu.
identyfikator sekcji, po którym następuje identyfikator wymagania opisany powyżej.
- Identyfikator podany w sekcji 2 składa się z tych elementów : Identyfikator sekcji / Identyfikator typu urządzenia – Identyfikator warunku – Identyfikator wymagania (np. 7.4.3/A-0-1).
2. Typy urządzeń
Android Open Source Project zapewnia stos oprogramowania, którego można używać do różnych typów urządzeń i formatów. Aby zapewnić bezpieczeństwo urządzeń, stosu oprogramowania, w tym zapasowego systemu operacyjnego i alternatywnego jądra; ma działać w bezpiecznym środowisku zgodnie z opisem, w sekcji 9. i innych miejscach niniejszej CDD. Istnieje kilka typów urządzeń które mają względnie lepiej ugruntowany ekosystem dystrybucji aplikacji.
W tej sekcji opisano te typy urządzeń i dodatkowe wymagania oraz zalecenia dla każdego typu urządzenia.
Wszystkie implementacje urządzeń z Androidem, które nie pasują do żadnej z opisanych typy urządzeń MUSZĄ spełniać wszystkie wymagania wymienione w pozostałych sekcjach tego Definicja zgodności.
2.1 Konfiguracje urządzeń
Główne różnice w konfiguracji sprzętu w zależności od urządzenia należy zapoznać się z wymaganiami dotyczącymi konkretnego urządzenia przedstawionymi w tej sekcji.
2.2. Wymagania dotyczące urządzenia mobilnego
Urządzenie mobilne z Androidem to implementacja urządzenia z Androidem, która jest zazwyczaj używa się go w dłoni, np. odtwarzacza mp3, telefonu lub tablecie.
Implementacje na urządzeniach z Androidem są zaliczane do urządzeń mobilnych, jeśli spełniają wszystkie następujące kryteria:
- mieć źródło zasilania, które pozwala na mobilność, np. baterię.
- mieć fizyczny ekran o przekątnej 3,3 cala (lub 2,5 cala w przypadku implementacji urządzeń, które zostały wysłane na poziomie API 29 lub wcześniej) do 8 cali.
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 z interfejsem API Androida na poziomie 29 lub starszym MOGĄ jest zwolnione z 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 wysłane z interfejsem API Androida na poziomie 29 lub starszym MOGĄ jest zwolnione z 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 metod wprowadzania (IME).
- [7.2.3/H-0-2] MUSI wysłać zarówno normalne, jak i długie naciśnięcie
zdarzenie funkcji Wstecz (
KEYCODE_BACK
) do aplikacji na pierwszym planie. System NIE POWINNY być wykorzystywać tych zdarzeń i CAN mogą być wywoływane przez inne urządzenia z Androidem (np. sprzęt zewnętrzny klawiatura podłączona do urządzenia z Androidem). - [7.2.3/H-0-3] Funkcja MUSI zapewniać funkcję ekranu głównego na na wszystkich wyświetlaczach zgodnych z Androidem, które mają ekran główny.
- [7.2.3/H-0-4] MUSI zapewniać funkcję Back (Wstecz) na wszystkich wyświetlaczach zgodnych z Androidem oraz funkcji Ostatnie na co najmniej jednym na wyświetlaczach zgodnych z Androidem.
- [7.2.4/H-0-1] MUSI obsługiwać wprowadzanie na ekranie dotykowym.
- [7.2.4/H-SR-1] Zdecydowanie ZALECANE jest uruchomienie
wybraną przez użytkownika aplikację asystującą, czyli aplikację, która stosuje
VoiceInteractionService lub działanie obsługujące
ACTION_ASSIST
po przytrzymaniu przyciskuKEYCODE_MEDIA_PLAY_PAUSE
lubKEYCODE_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ą Zdecydowanie ZALECANE do obsługi czujnika pozycji i sześć stopni swobody.
- [7.4.3/H] POWINNA obejmować obsługę Bluetootha i Bluetooth LE.
Jeśli urządzenia obsługują protokół NAN (Wi-Fi Neighbor Awareness Networking) przez
deklaruję: PackageManager.FEATURE_WIFI_AWARE
i lokalizację Wi-Fi (okrągły Wi-Fi
Czas podróży – RTT) przez zadeklarowanie wartości PackageManager.FEATURE_WIFI_RTT
, a potem:
[7.4.2.5/H-1-1] MUSI podawać dokładne dane do w zakresie +/-1 metra przy przepustowości 160 MHz przy 68 centylu (zgodnie z obliczeniami) przy użyciu funkcji rozkładu skumulowanego) +/-2 metry przy przepustowości 80 MHz przy 68 centyl, +/-4 metry przy przepustowości 40 MHz przy 68 centylu, i +/-8 metrów przy przepustowości 20 MHz przy 68 centylu w odległości 10 MHz cm, 1 m, 3 m i 5 m, jak przedstawiono za pomocą WifiRttManager#startRanging Android API.
[7.4.2.5/H-SR-1] Zdecydowanie ZALECANE jest zgłoszenie z dokładnością do +/-1 metra przy przepustowości 160 MHz przy 90. MHz percentyl (obliczany za pomocą funkcji rozkładu skumulowanego), +/-2 metry przy przepustowości 80 MHz przy 90 centylu, +/-4 metry przy 40 MHz przy 90. percentylu i +/-8 metrów przy przepustowości 20 MHz 90. percentyl w odległości 10 cm, jak można zaobserwować w WifiRttManager#startRanging Android API.
Zdecydowanie ZALECANE jest wykonanie kroków konfiguracji pomiaru podanych w artykule Kalibracja obecności.
Jeśli implementacje urządzeń mobilnych 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 obsługuje rozdzielczość bufora klatek do FHD. (np. WSXGA+).
[7.6.1/H-8-1] Pamięć dostępna dla jądra a przestrzeń użytkowników MUSI mieć co najmniej 1824 MB, jeśli wyświetlacz domyślny korzysta z bufora klatek o rozdzielczości do QHD. (np. QWXGA).
Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do dostępna pamięć (oprócz pamięci już przeznaczonej dla sprzętu), 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 (inaczej partycja „/data”).
- NALEŻY zadeklarować flagę funkcji
android.hardware.ram.normal
.
Jeśli implementacje na urządzeniach mobilnych obejmują co najmniej 2 GB i mniej niż 4 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:
- [7.6.1/H-SR-1] Zdecydowanie ZALECANE jest obsługa tylko 32-bitowej przestrzeni użytkownika. (zarówno aplikacje, jak i kod systemu)
Jeśli urządzenia mobilne zawierają mniej niż 2 GB pamięci dostępnej dla jądro i przestrzeń użytkownika:
- [7.6.1/H-1-1] MUSI obsługiwać tylko jeden interfejs ABI (tylko 64-bitowy lub 32-bitowy). ).
Implementacje na urządzeniach mobilnych:
- [7.6.2/H-0-1] NIE MOŻE zawierać aplikacji pamięci współdzielonej mniejszej niż 1 GiB.
- [7.7.1/H] POWINNY jest mieć port USB obsługujący tryb peryferyjny.
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średnictwemandroid.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 jest po podłączeniu 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/H-1-1] MUSI mieć średnią prędkość ciągłego obiegu w obie strony opóźnienie wynoszące 500 milisekund lub mniej niż 5 pomiarów, ze średnim odchyleniem bezwzględnym mniejszym niż 50 ms, na tych ścieżkach danych: „głośnik do mikrofonu”, Przejściówka z zapętlaniem 3,5 mm (jeśli jest obsługiwana) i USB loopback (jeśli jest obsługiwana).
[5,6/H-1-2] MUSI mieć średni czas oczekiwania w przypadku funkcji „Dotknij, by” 500 milisekund lub mniej, z co najmniej 5 pomiarów z głośnika do ścieżki danych mikrofonu.
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 tagu 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ły
PRIMITIVE_*
dla Inteligentny czujnik haptyczny w android.os.VibrationEffect.Composition (KLIKNIJ, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Niektóre z tych elementów podstawowych, na przykład LOW_TICK i SPIN mogą być możliwe tylko wtedy, gdy wibracje obsługują przy stosunkowo niskiej częstotliwości. [7.10/H]* POWINNO trzymać się wytycznych dotyczących mapowania stałych publicznych w zasadzie android.view.HapticFeedbackConstants. na zalecane stałe android.os.VibrationEffect, z odpowiednimi zależnościami amplitudy.
[7.10/H]* POWINNO spełniać ocena jakości dla funkcji createOneShot() i createWaveform() API.
[7.10/H]* POWINNY być sprawdzenie, czy wynik publicznej funkcji android.os.Vibrator.hasAmplitudeControl() Interfejs API poprawnie odzwierciedla możliwości wibracji.
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]* POWINNO przesunąć element haptyczny na osi X (od lewej do prawej) 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]* MUSI zweryfikować stan implementacji, uruchamiając android.os.Vibrator.areAllEffectsSupported() i android.os.Vibrator.arePrimitivesSupported() interfejsy API.
[7,10/H]* NALEŻY wykonać ocena jakości dla stałych haptycznych.
[7.10/H]* MUSI zweryfikować i w razie potrzeby zaktualizować wartość zastępczą dla nieobsługiwanych elementów podstawowych, jak opisano w wskazówkami dotyczącymi implementacji dla stałych.
2.2.2. Multimedia
Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać poniższe kodowanie dźwięku i formatów do dekodowania i udostępniania aplikacjom innych firm:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] Profil AAC MPEG-4 (AAC LC)
- [5.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
- [5.1/H-0-5] AAC ELD (rozszerzony AAC z niskim opóźnieniem)
Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać to kodowanie wideo formatów i udostępniać je aplikacjom innych firm:
Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać poniższe dekodowanie wideo formatów i udostępniać je aplikacjom innych firm:
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
, iACTION_CREATE_DOCUMENT
zgodnie z intencjami opisanymi w dokumentach pakietu SDK, i zapewnić użytkownikom do danych dostawcy dokumentów za pomocą interfejsu APIDocumentsProvider
. - [3.2.3.1/H-0-2]* MUSI załadować wstępnie aplikacji czy komponentów usługi z modułem obsługi intencji, np. wszystkie wzorce filtra intencji publicznych zdefiniowane przez tę aplikację intencji wymienionych tutaj.
- [3.2.3.1/H-SR-1] Są ZDECYDOWANIE ZALECANE jest wstępne wczytanie aplikacji poczty e-mail, która obsługuje działanie ACTION_SENDTO. lub ACTION_SEND lub ACTION_SEND_MULTIPLE z zamiarem wysłania e-maila.
- [3.4.1/H-0-1] MUSI zawierać pełny
implementacji interfejsu
android.webkit.Webview
API. - [3.4.2/H-0-1] MUSI zawierać samodzielną przeglądarkę do przeglądania internetu.
- [3.8.1/H-SR-1] Zdecydowanie ZALECANE aby zaimplementować domyślny program uruchamiający, który obsługuje przypinanie skrótów w aplikacji, widżetów i funkcji widżetów.
- [3.8.1/H-SR-2] Zdecydowanie ZALECANE aby zaimplementować domyślny program uruchamiający, który zapewnia szybki dostęp do dodatkowych, skróty dostępne w aplikacjach innych firm za pomocą menedżera ShortcutManager API.
- [3.8.1/H-SR-3] Zdecydowanie ZALECANE , aby uwzględnić domyślną aplikację uruchamiającą, która wyświetla plakietki przy ikonach aplikacji.
- [3.8.2/H-SR-1] Zdecydowanie ZALECANE z widżetami aplikacji innych firm.
- [3.8.3/H-0-1] MUSI zezwalać na aplikacje innych firm
do powiadamiania użytkowników o ważnych wydarzeniach za pomocą
Notification
orazNotificationManager
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 jakotrue
(wraz z odpowiedziami wyświetlanymi przez)Notification.Remoteinput.Builder.setChoices
. - [3.8.4/H-SR-1] Zdecydowanie ZALECANE aby wdrożyć na urządzeniu asystenta do działania wspomagającego.
Jeśli implementacje urządzeń mobilnych obsługują powiadomienia MediaStyle one:
- [3.8.3.1/H-SR-2] Zdecydowanie ZALECANE
dla użytkowników (np. do przełącznika wyjścia), do którego dostęp
interfejs systemu, który pozwala użytkownikom przełączać się między odpowiednimi dostępnymi
trasy (na przykład urządzenia Bluetooth i trasy udostępniane do usługi,
MediaRouter2Manager
) gdy aplikacja publikuje powiadomienieMediaStyle
z tokenemMediaSession
.
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 stosujeVoiceInteractionService
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ą natrue
. - [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
orazControl
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 przezControl
. API.[3.8.16/H-1-5] MUSI zawierać użytkownika rezygnacja z korzystania z prostych mechanizmów uwierzytelniania elementów sterujących zarejestrowanych przez aplikacje innych firm za pomocą
ControlsProviderService
orazControl
Interfejs APIControl.isAuthRequired
.
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
zaControlsProviderService
orazControl
API. - [3.8.16/H-2-2] MUSI zadeklarować funkcję
flaga
android.software.controls
i ustaw ją nafalse
.
Jeśli implementacje na urządzeniach mobilnych nie działają w trybie blokady zadań, po skopiowaniu treści do schowka:
- [3.8.17/H-1-1] MUSI przedstawić użytkownikowi potwierdzenie, że dane zostały skopiowany do schowka (np. miniatura lub alert „Treść została skopiowana”). Dołącz też informację, czy dane ze schowka będą synchronizowane na różnych urządzeniach.
Implementacje na urządzeniach mobilnych:
- [3.10/H-0-1] MUSI obsługiwać ułatwienia dostępu innych firm usług Google.
- [3.10/H-SR-1] Zdecydowanie ZALECANE jest wstępne wczytywanie usługi ułatwień dostępu na urządzeniu są porównywalne lub przewyższające funkcjonalność funkcji Switch Access i TalkBack (dla języków obsługiwanych przez usługi ułatwień dostępu służące do zamiany tekstu na mowę) zgodnie z otwartym komunikatem TalkBack. projekt źródłowy.
- [3.11/H-0-1] MUSI obsługiwać instalację za pomocą funkcji zamiany tekstu na mowę innych firm.
- [3.11/H-SR-1] Zdecydowanie ZALECANE jest dodanie Mechanizm zamiany tekstu na mowę obsługuje języki dostępne na urządzeniu.
- [3.13/H-SR-1] Zdecydowanie ZALECANE jest dodanie Komponent UI Szybkich ustawień.
Jeśli implementacje urządzeń mobilnych z Androidem zadeklarują FEATURE_BLUETOOTH
lub
Zespół pomocy FEATURE_WIFI
:
- [3.16/H-1-1] MUSI obsługiwać parowanie urządzenia towarzyszącego funkcji.
Jeśli funkcja nawigacji jest udostępniana na ekranie za pomocą gestów:
- [7.2.3/H] Strefa rozpoznawania gestów na urządzeniu Home Funkcja POWINNA mieć wysokość nie większą niż 32 dp od dolnej krawędzi ekranu.
jeśli w urządzeniach mobilnych jest dostępna funkcja nawigacji w postaci gestu. z dowolnego miejsca przy lewej i prawej krawędzi ekranu:
- [7.2.3/H-0-1] Obszar gestów funkcji nawigacji Szerokość musi mieć mniej niż 40 dp po każdej stronie. Obszar gestów POWINNY być: Domyślnie szerokość 24 dp.
Jeśli Chromebooki obsługują bezpieczny ekran blokady i mają większą co najmniej 2 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:
- [3.9/H-1-2] MUSI zadeklarować obsługę profili zarządzanych w
Flaga funkcji
android.software.managed_users
.
Jeśli implementacje urządzeń mobilnych z Androidem zadeklarują obsługę aparatu,
android.hardware.camera.any
to:
- [7.5.4/H-1-1] MUSI uwzględniać
android.media.action.STILL_IMAGE_CAMERA
iandroid.media.action.STILL_IMAGE_CAMERA_SECURE
i uruchomić aparat w trybie zdjęć, tak jak to opisano w pakiecie SDK. - [7.5.4/H-1-2] MUSI uwzględniać
android.media.action.VIDEO_CAMERA
zamierza uruchomić kamerę w trybie wideo, zgodnie z opisem w pakiecie SDK.
Jeśli aplikacja ustawień implementacji urządzenia mobilnego implementuje dzielonej funkcji, za pomocą umieszczania aktywności, to:
- [3.2.3.1/ H-1-1]
MUSI mieć aktywność, która obsługuje
intencja Settings#ACTION_SETTINGS_COMMENTER_DEEP_LINK_ACTIVITY, gdy funkcja podziału jest włączona. Aktywność MUSI być chroniona przez usługę
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
i MUSI rozpocznij aktywność intencji analizowanej z Ustawienia#EXTRA_SETTINGS_COMMENTERDED_DEEP_LINK_INTENT_URI.
2.2.4 Wydajność i moc
- [8.1/H-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie klatek lub opóźnienie renderowania klatek NIE MOŻE powtarzać się często niż 5 klatek na sekundę, a POWINNA być poniżej 1 klatki na sekundę.
- [8.1/H-0-2] Opóźnienie interfejsu użytkownika. Implementacje urządzeń MUSZĄ zapewniać użytkownikom niewielkie opóźnienia, przewijając lista 10 tys. pozycji zgodnie z definicją zawartą w narzędziu Android Compatibility Test Suite. (CTS) w niecałe 36 sekund.
- [8.1/H-0-3] Przełączanie zadań. Kiedy uruchomiono wiele aplikacji, co powoduje ponowne uruchomienie jednej z już uruchomionych aplikacji. od uruchomienia aplikacji MUSI trwać mniej niż 1 sekundę.
Implementacje na urządzeniach mobilnych:
- [8.2/H-0-1] MUSI zapewniać ciągłość działania z wydajnością zapisu co najmniej 5 MB/s.
- [8.2/H-0-2] MUSI zapewniać losowy zapis z wydajnością co najmniej 0,5 MB/s.
- [8.2/H-0-3] MUSI zapewniać sekwencyjny odczyt z wydajnością co najmniej 15 MB/s.
- [8.2/H-0-4] MUSI zapewniać losowy odczyt z wydajnością co najmniej 3,5 MB/s.
jeśli implementacje urządzeń mobilnych obejmują funkcje zwiększające wydajność urządzenia; funkcji zarządzania uwzględnionymi w AOSP lub rozszerzających dostępne funkcje. w AOSP:
- [8.3/H-1-1] MUSI zapewniać wygodę użytkowników, aby umożliwić i wyłączyć funkcję oszczędzania baterii.
- [8.3/H-1-2] MUSI zapewniać wygodę wyświetlania użytkownikom wszystkich aplikacji, które są wyłączone z trybów czuwania aplikacji i uśpienia.
Implementacje na urządzeniach mobilnych:
- [8.4/H-0-1] MUSI zawierać parametr profil zasilania na komponent, który określa bieżącą wartość zużycia dla każdego elementu sprzętowego i przybliżone zużycie baterii przez zgodnie z opisem w witrynie Android Open Source Project.
- [8.4/H-0-2] MUSI zgłaszać całą zasilanie wartości wykorzystania w miliiamperach godzin (mAh).
- [8.4/H-0-3] MUSI raportować moc procesora
na wykorzystanie identyfikatora UID każdego procesu. W projekcie Android Open Source Project
za pomocą modułu jądra
uid_cputime
. - [8.4/H-0-4] MUSI zapewniać to zużycie energii
dostępne w
adb shell dumpsys batterystats
należy użyć polecenia powłoki do dewelopera aplikacji. - [8.4/H] POWINNY być przypisane do sam komponent sprzętowy, jeśli nie można przypisać wykorzystania energii przez komponent sprzętowy. do aplikacji.
Jeśli implementacje urządzeń mobilnych obejmują wyjście ekranu lub wideo:
- [8.4/H-1-1] MUSI uwzględniać
android.intent.action.POWER_USAGE_SUMMARY
i wyświetli menu ustawień, które pokazuje to zużycie energii.
Implementacje na urządzeniach mobilnych:
- [8.5/H-0-1] MUSI udostępniać zaoferowaną użytkownikom
menu Ustawienia z możliwością zatrzymania aplikacji działającej na pierwszym planie
i wyświetlają wszystkie aplikacje, które mają aktywne usługi na pierwszym planie, oraz
czasu trwania każdej z tych usług od momentu uruchomienia, zgodnie z opisem w pakiecie SDK
dokumentu.
- Niektóre aplikacje MOGĄ zostać zwolnione z zatrzymania lub umieszczenia w takim aprobatę dla użytkowników zgodnie z opisem w dokumentacji pakietu SDK.
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ź naandroid.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 lubContentCaptureService
do Interfejs APIContentCaptureManager
. - [9.8/H-1-3] NIE MOŻE dostarczać dźwięku z mikrofonu dłuższego niż 30 sekund żą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 dopuszczać więcej niż 100 bajtów danych innych niż audio przesyłane z usługi wykrywania słów-kluczy dla każdego udanego słowa-klucza wynik.
- [9.8/H-1-7] NIE MOŻE zezwalać na przesyłanie więcej niż 5 bitów danych na zewnątrz usługi wykrywania słów-kluczy dla każdego z negatywnych słów-kluczy.
- [9.8/H-1-8] MUSI umożliwiać przesyłanie danych tylko poza słowo-klucz wykrywania w przypadku żądania weryfikacji słowa-klucza otrzymanego od serwera systemu.
- [9.8/H-1-9] NIE MOŻE zezwalać aplikacji instalowanej przez użytkownika na dostarczanie usługi wykrywania słów-kluczy.
- [9.8/H-1-10] NIE MOŻESZ wyświetlać w interfejsie użytkownika danych ilościowych o korzystaniu z mikrofonu przez dzięki usłudze wykrywania słów-kluczy.
- [9.8/H-1-11] MUSI rejestrować liczbę bajtów uwzględnionych w każdej transmisji z usługi wykrywania słów-kluczy, która umożliwia sprawdzenie pod kątem bezpieczeństwa i badań.
- [9.8/H-1-12] MUSI obsługiwać tryb debugowania, który rejestruje nieprzetworzoną zawartość każdego przesyłania z usługi wykrywania słów-kluczy, co pozwala na sprawdzenie i badaczy bezpieczeństwa.
- [9.8/H-1-14] NALEŻY wyświetlać wskaźnik mikrofonu, zgodnie z opisem w sekcji 9.8.2, jeśli udany wynik słowa-klucza jest przesył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.
- [9.8/H-SR-3] Zdecydowanie ZALECANE jest ponowne uruchomienie procesu hostowania wykrywanie słów-kluczy co najmniej raz na godzinę lub co 30 zdarzenia aktywującego sprzęt (w zależności od tego, co nastąpi wcześniej).
jeśli implementacje urządzeń obejmują aplikację, która korzysta z interfejsu System API.
HotwordDetectionService
lub podobny mechanizm wykrywania słów-kluczy bez
wskazaniem użycia mikrofonu, aplikacja:
- [9.8/H-2-1] MUSI zawierać wyraźne powiadomienie o każdym słowie-kluczu obsługiwane.
- [9.8/H-2-2] NIE MOŻE zachowywać nieprzetworzonych danych dźwiękowych ani danych uzyskanych z nich. w usłudze wykrywania słów-kluczy.
- [9.8/H-2-3] NIE MOŻE przesyłać z usługi wykrywania słów-kluczy ani dźwięku
dane, które można wykorzystać do zrekonstruowania (całkowitej lub części) dźwięku,
lub treści audio niezwiązane z samym słowem-kluczem, z wyjątkiem
ContentCaptureService
Jeśli implementacje urządzeń mobilnych zadeklarują android.hardware.microphone
:
- [9.8.2/H-4-1] MUSI wyświetlać wskaźnik mikrofonu, gdy
aplikacja uzyskuje dostęp do danych dźwiękowych z mikrofonu, ale nie wtedy, gdy
dostęp do mikrofonu ma tylko
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
lub aplikacje pełniące role nazywane w sekcji 9.1 o identyfikatorze CDD [C-4-X]. - [9.8.2/H-4-2] MUSI wyświetlać listę najnowszych i aktywnych
aplikacje używające mikrofonu w odpowiedzi
PermissionManager.getIndicatorAppOpUsageData()
wraz z wszelką atrybucją wiadomości, które są z nimi powiązane.
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.
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
).
- [6.1/H-0-2]* MUSI zawierać
2.2.7. Zajęcia z wydajności urządzeń mobilnych
Definicję znajdziesz w artykule 7.11 klasa skuteczności multimediów.
2.2.7.1. Multimedia
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.S
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania dotyczące multimediów wymienione w zestawie danych CDD na temat Androida 12 art.2.2.7.1
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.T
dla android.os.Build.VERSION_CODES.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()
iVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] MUSI obsługiwać 6 wystąpień sesji sprzętowego dekodera wideo (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków równocześnie w rozdzielczości 1080p przy 30 kl./s.
- [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()
iVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] MUSI obsługiwać 6 wystąpień sprzętowego kodera wideo (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków równocześnie w rozdzielczości 1080p przy 30 kl./s.
- [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()
iVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] MUSI obsługiwać 6 instancji sprzętowych dekodera wideo i sprzętu sesji kodera wideo (AVC, HEVC, VP9, AV1 lub nowszego) w dowolnym kodeku działająca jednocześnie w rozdzielczości 1080p przy 30 kl./s.
- [5.1/H-1-7] W przypadku formatu [5.1/H-1-7] opóźnienie inicjowania kodeka musi wynosić maksymalnie 40 ms Sesja kodowania 1080p lub mniejsza w przypadku wszystkich sprzętowych koderów wideo a w trakcie wczytywania. Wczytywanie w tym miejscu jest zdefiniowane jako jednoczesna rozdzielczość od 1080p do 720p w trybie transkodowania tylko wideo za pomocą sprzętowych kodeków wideo Inicjowanie nagrywania dźwięku i obrazu w jakości 1080p. W przypadku kodeka Dolby Vision Opóźnienie inicjowania kodeka MUSI wynosić maksymalnie 50 ms.
- [5.1/H-1-8] W przypadku formatu [5.1/H-1-8] opóźnienie inicjowania kodeka musi wynosić maksymalnie 30 ms Sesja kodowania dźwięku 128 kb/s lub niższa w przypadku wszystkich koderów audio, gdy nie jest wczytywany. Wczytywanie tutaj jest zdefiniowane jako jednoczesny tryb odtwarzania filmów od 1080p do 720p i sesji transkodowania za pomocą sprzętowych kodeków wideo oraz funkcji 1080p. inicjowania nagrywania audio-wideo.
- [5.1/H-1-9] MUSI obsługiwać 2 instancje bezpiecznego sprzętowego dekodera wideo (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków równocześnie w rozdzielczości 1080p przy 30 kl./s.
- [5.1/H-1-10] MUSI obsługiwać 3 wystąpienia niezabezpieczonego sprzętowego dekodera wideo sesja wraz z 1 instancją bezpiecznego sprzętowego dekodera wideo (łącznie 4 instancje) (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków działające równocześnie w rozdzielczości 1080p przy 30 kl./s.
- [5.1/ H-1-11] MUSI obsługiwać bezpieczny dekoder dla każdego sprzętowego AVC, HEVC dekodera VP9 lub AV1 na urządzeniu.
- [5.1/H-1-12] W przypadku formatu [5.1/H-1-12] opóźnienie inicjowania kodeka musi wynosić maksymalnie 40 ms Sesja dekodowania wideo 1080p lub mniejsza w przypadku wszystkich sprzętowych dekoderów wideo a w trakcie wczytywania. Wczytywanie w tym miejscu jest zdefiniowane jako jednoczesna rozdzielczość od 1080p do 720p w trybie transkodowania tylko wideo za pomocą sprzętowych kodeków wideo Inicjowanie odtwarzania dźwięku i wideo w rozdzielczości 1080p. W przypadku kodeka Dolby Vision opóźnienie inicjowania MUSI wynosić 50 ms lub mniej.
- [5.1/H-1-13] W przypadku formatu [5.1/H-1-13] opóźnienie inicjowania kodeka musi wynosić maksymalnie 30 ms Sesja dekodowania dźwięku 128 kb/s lub niższa we wszystkich dekoderach audio, gdy: nie jest wczytywany. Wczytywanie tutaj jest zdefiniowane jako jednoczesny tryb odtwarzania filmów od 1080p do 720p i sesji transkodowania za pomocą sprzętowych kodeków wideo oraz funkcji 1080p. zainicjowanie odtwarzania dźwięku i filmu.
- [5.1/H-1-14] MUSI obsługiwać dekoder sprzętowy AV1 Main 10, poziom 4.1.
- [5.1/H-SR-1] Zdecydowanie ZALECANE jest obsługa ziarna kliszy w sprzęcie AV1. za pomocą dekodera.
- [5.1/H-1-15] MUSI mieć co najmniej jeden sprzętowy dekoder wideo obsługujący rozdzielczość 4K60.
- [5.1/H-1-16] MUSI mieć co najmniej jeden koder sprzętowy obsługujący rozdzielczość 4K60.
- [5.3/H-1-1] NIE MOŻE upuścić więcej niż 1 klatki w ciągu 10 sekund (mniej niż 0,167% 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 od 1080p do 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] W trakcie filmu NIE MOŻE upuścić więcej niż 1 klatki na 10 sekund zmiana rozdzielczości podczas wczytywania sesji wideo z prędkością 60 kl./s. 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] Czas oczekiwania na tonację musi wynosić maksymalnie 80 milisekund korzystając z testu tonacji w systemie OboeTester lub testu tonacji z narzędzia CTS Verifier.
- [5.6/H-1-2] Opóźnienie dźwięku w obie strony musi wynosić maksymalnie 80 milisekund w przypadku co najmniej 1 obsługiwanej ścieżki danych.
- [5.6/H-1-3] W przypadku wyjścia stereo 3,5 mm MUSI obsługiwać >=24-bitowy dźwięk.
gniazda słuchawek (jeśli są dostępne) i audio USB, jeśli są obsługiwane przez
całą ścieżkę danych dla konfiguracji
z małym czasem oczekiwania i funkcją strumieniowania. Niski poziom
konfiguracji czasu oczekiwania, aplikacja AAudio powinna używać jej w krótkim czasie.
w trybie wywołania zwrotnego. Gdy oglądasz transmisję
aplikacja powinna użyć ścieżki audio Java. Zarówno niskie,
konfiguracji czasu oczekiwania i strumieniowania, ujście wyjściowe HAL powinno akceptować
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
lubAUDIO_FORMAT_PCM_FLOAT
dla docelowych danych wyjściowych . - [5.6/H-1-4] MUSI obsługiwać więcej niż 4-kanałowe urządzenia audio USB (używane przez DJ-ów). kontrolery do odtwarzania utworów).
- [5.6/H-1-5] MUSI obsługiwać urządzenia MIDI zgodne z klasą i zadeklarować MIDI flagę funkcji.
- [5.7/H-1-2] MUSI obsługiwać wartość
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
z poniższe funkcje odszyfrowywania treści.
Minimalny rozmiar próbki | 4 MiB |
Minimalna liczba próbek podrzędnych – H264 lub HEVC | 32 |
Minimalna liczba próbek podrzędnych – VP9 | 9 |
Minimalna liczba próbek podrzędnych – AV1 | 288 |
Minimalny rozmiar bufora próbki podrzędnego | 1 MiB |
Minimalny rozmiar ogólnego bufora kryptograficznego | 500 KiB |
Minimalna liczba równoczesnych sesji | 30 |
Minimalna liczba kluczy na sesję | 20 |
Minimalna łączna liczba kluczy (wszystkie sesje) | 80 |
Minimalna łączna liczba kluczy DRM (wszystkie sesji) | 6 |
Rozmiar wiadomości | 16 KiB |
Odszyfrowane klatki na sekundę | 60 kl./s |
2.2.7.2. Aparat
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.S
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania dotyczące aparatu wymienione w systemie CDD na temat Androida 12 art. 2.2.7.2.
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.T
dla android.os.Build.VERSION_CODES.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
jakoFULL
lub więcej dla tylnej wersji głównej iLIMITED
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) < 500 ms na podstawie wyników testu wydajności kamery CTS przeprowadzonego przez ITS warunków oświetleniowych (3000 K) obu aparatów głównych.
- [7.5/H-1-8] MUSI obsługiwać wartość
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
iandroid.graphics.ImageFormat.RAW_SENSOR
za główny tylny aparat. - [7.5/H-1-9] MUSI mieć tylny aparat główny obsługujący rozdzielczość 720p lub 1080p. 240 kl./s
- [7,5/H-1-10] MUSI mieć min.ZOOM_RATIO < 1.0 dla aparatów głównych, jeśli są dostępne jest ultraszerokokątny aparat RGB skierowany w tę samą stronę.
- [7.5/H-1-11] NALEŻY zaimplementować równoczesne przesyłanie strumieniowe z przodu na stronie głównej kamery.
- [7.5/H-1-12] MUSI obsługiwać wartość
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
dla głównego tylnego aparatu. - [7.5/H-1-13] MUSI obsługiwać funkcję
LOGICAL_MULTI_CAMERA
w tylny aparat, jeśli jest więcej niż 1 tylny aparat RGB. - [7.5/H-1-14] MUSI obsługiwać funkcję
STREAM_USE_CASE
zarówno w przypadku głównych, przedni i główny tylny aparat.
2.2.7.3 Sprzęt
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.S
dla
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania sprzętowe wymienione w zestawie danych CDD na temat Androida 12 art.2.2.7.3
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.T
dla
android.os.Build.VERSION_CODES.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 8 GB pamięci fizycznej.
2.2.7.4. Wydajność
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.S
dla
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania dotyczące wydajności wymienione w zestawie danych o Androidzie 12. art. 2.2.7.4.
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.T
dla
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- [8.2/H-1-1] MUSI zapewniać wydajność sekwencyjnego zapisu na poziomie co najmniej 125 MB/s.
- [8.2/H-1-2] MUSI zapewniać wydajność zapisu przy losowym połączeniu z szybkością co najmniej 10 MB/s.
- [8.2/H-1-3] MUSI zapewniać wydajność sekwencyjnego odczytu co najmniej 250 MB/s.
- [8.2/H-1-4] MUSI zapewnić prędkość odczytu z szybkością losowej co najmniej 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 zawierać obsługę gry
kontrolerów i zadeklarować flagę funkcji
android.hardware.gamepad
. - [7.2.7/T] POWINNY jest dostarczyć pilota, którego użytkownicy mogą korzystać z nawigacji bezdotykowej oraz główne klawisze nawigacyjne.
Jeśli implementacje urządzeń telewizyjnych obejmują 3-osiowy żyroskop:
- [7.3.4/T-1-1] MUSI być w stanie zgłaszać zdarzenia do co najmniej 100 Hz.
- [7.3.4/T-1-2] MUSI być w stanie mierzyć zmiany orientacji ekranu. do 1000 stopni na sekundę.
Implementacje na urządzeniach telewizyjnych:
- [7.4.3/T-0-1] MUSI obsługiwać Bluetooth i Bluetooth LE.
- [7.6.1/T-0-1] MUSI zawierać co najmniej 4 GB pamięci pamięć nieulotna dostępna na prywatne dane aplikacji (zwane też partycją „/data”).
Jeśli telewizory są wyposażone w port USB obsługujący tryb hosta, one:
- [7.5.3/T-1-1] MUSI zawierać obsługę kamery zewnętrznej który łączy się przez ten port USB, ale nie zawsze jest podłączony.
Jeśli implementacje na telewizorach są 32-bitowe:
[7.6.1/T-1-1] Pamięć dostępna dla jądra a przestrzeń użytkowników MUSI mieć co najmniej 896 MB, jeśli używana jest dowolna z tych gęstości:
- Rozdzielczość 400 dpi lub większa na małych lub normalnych ekranach
- xhdpi lub więcej na dużych ekranach
- tvdpi lub więcej na bardzo dużych ekranach
Jeśli implementacje telewizorów są 64-bitowe:
[7.6.1/T-2-1] Pamięć dostępna dla jądra a przestrzeń użytkowników MUSI mieć co najmniej 1280 MB, jeśli wykorzystane:
- Rozdzielczość 400 dpi lub większa na małych lub normalnych ekranach
- xhdpi lub więcej na dużych ekranach
- tvdpi lub więcej na bardzo dużych ekranach
Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do dostępne miejsce w pamięci dodane do pamięci, która jest już przeznaczone do części sprzętowych (np. radia czy wideo), które nie są które są pod kontrolą jądra systemu operacyjnego.
Implementacje na urządzeniach telewizyjnych:
- [7.8.1/T] POWINNY być mikrofon.
- [7.8.2/T-0-1] MUSI mieć wyjście audio i zadeklarować
android.hardware.audio.output
2.3.2 Multimedia
Implementacje na telewizorach MUSZĄ obsługiwać to kodowanie dźwięku formatów i dekodowania, a także udostępnić je aplikacjom innych firm:
- [5.1/T-0-1] Profil AAC MPEG-4 (AAC LC)
- [5.1/T-0-2] Profil MPEG-4 HE AAC (AAC+)
- [5.1/T-0-3] AAC ELD (rozszerzony AAC z niskim opóźnieniem)
Implementacje na telewizorach MUSZĄ obsługiwać to kodowanie wideo formatów i udostępniać je aplikacjom innych firm:
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, przy standardowej liczbie klatek i rozdzielczości do w tym:
- [5.3.4/T-1-1] 1080p HD przy 60 klatkach na sekundę przy Profil podstawowy
- [5.3.4/T-1-2] HD 1080p przy 60 klatkach na sekundę przy Profil główny
- [5.3.4/T-1-3] 1080p HD przy 60 klatkach na sekundę przy Wysoki poziom profilu 4.2
Implementacje urządzeń telewizyjnych z dekoderami sprzętowymi H.265 MUSZĄ obsługiwać Dekodowanie H.265, zgodnie z opisem w sekcji 5.3.5, ze standardowymi liczbami klatek filmu i rozdzielczości aż do:
- [5.3.5/T-1-1] 1080p HD przy 60 klatkach na sekundę przy Poziom 4.1 profilu głównego
Jeśli implementacje urządzeń telewizyjnych z dekoderami sprzętowymi H.265 obsługują Dzięki dekodowaniu H.265 i profilowi dekodowania UHD:
- [5.3.5/T-2-1] MUSI obsługiwać profil dekodowania UHD 60 klatek na sekundę w profilu głównego poziomu 5 Main10
Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać dekodowanie VP8, jak opisano w Sekcja 5.3.6, ze standardową liczbą klatek i rozdzielczością do w tym:
- [5.3.6/T-1-1] 1080p HD przy 60 klatkach na sekundę (profil dekodowania)
Implementacje urządzeń telewizyjnych z dekoderami sprzętowymi VP9 MUSZĄ obsługiwać ten standard (zgodnie z opisem w sekcji 5.3.7) przy standardowych liczbach klatek na sekundę oraz maksymalnie:
- [5.3.7/T-1-1] HD 1080p przy 60 klatkach na sekundę przy profil 0 (8-bitowa głębia kolorów)
Jeśli implementacje urządzeń telewizyjnych z dekoderami sprzętowymi VP9 obsługują ten format i profil dekodowania UHD:
- [5.3.7/T-2-1] MUSI obsługiwać profil dekodowania UHD 60 klatek na sekundę przy profilu 0 (8-bitowa głębia kolorów).
- [5.3.7/T-SR1] Zdecydowanie ZALECANE jest działanie Profil dekodowania UHD przy 60 klatkach na sekundę z profilem 2 (10-bitowa głębia kolorów).
Implementacje na urządzeniach telewizyjnych:
- [5.5/T-0-1] MUSI obsługiwać system Master wyciszanie głośności i wyciszanie cyfrowego wyjścia audio na obsługiwanych wyjściach, z wyjątkiem skompresowanego przekazującego wyjścia audio (na którym nie jest wykonywane dekodowanie dźwięku na urządzeniu).
Jeśli telewizory nie mają wbudowanego wyświetlacza, Zamiast tego obsługują zewnętrzny wyświetlacz podłączony przez HDMI, ale:
- [5.8/T-0-1] MUSI ustawić tryb wyjścia HDMI na 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
iandroid.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] POWINNO być przypisane do sam komponent sprzętowy, jeśli nie można przypisać wykorzystania energii przez komponent sprzętowy. do aplikacji.
- [8.4/T-0-4] MUSI zapewniać to zużycie energii
dostępne w
adb shell dumpsys batterystats
należy użyć polecenia powłoki do dewelopera aplikacji.
2.3.5 Model zabezpieczeń
Implementacje na urządzeniach telewizyjnych:
- [9.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 lub jądra systemu operacyjnego. 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.
- [6.1/T-0-1] MUSI zawierać
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
orazPARKING_BRAKE_ON
.[7.3/A-0-2] Wartość parametru
NIGHT_MODE
flaga MUSI być zgodna z trybem dziennym/nocnym pulpitu i POWINNA być dane wejściowe czujnika jasności otoczenia. Czujnik jasności otoczenia MOŻE być taki sam jako Fotometr.[7.3/A-0-3] MUSI zawierać dodatkowe pole informacyjne czujnika
TYPE_SENSOR_PLACEMENT
w ramach SensorAdditionalInfo dla każdego dostarczonego czujnika.[7.3/A-SR1] MAJ wieczorek nie ma już pewności Lokalizacja dzięki połączeniu GPS/GNSS z dodatkowymi czujnikami. Jeśli Lokalizacja Obecnie Zdecydowanie ZALECANE jest wdrożenie i zgłaszanie odpowiedni Czujnik typy lub identyfikatory nieruchomości pojazdów .
[7.3/A-0-4] Lokalizacja żądane za pomocą funkcji LocationManager#requestLocationUpdates() NIE MOŻE być dopasowana do mapy.
[7.3.1/A-0-4] MUSI być zgodna z układ współrzędnych czujnika samochodowego.
[7.3/A-SR-1] Są STRONGLY_RECOMMENDENDED 3-osiowy akcelerometr i 3-osiowy żyroskop.
[7.3/A-SR-2] Ssilnie_ZALECANE jest wdrożenie i raportowanie Czujnik
TYPE_HEADING
.
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ą akcelerometr:
- [7.3.1/A-1-1] MUSI zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr:
- [7.3.1/A-SR-1] Zdecydowanie ZALECANE jest wdrożenie akcelerometru kompozytowego dla akcelerometru o ograniczonych osiach.
Jeśli implementacje urządzeń motoryzacyjnych obejmują akcelerometr z wartością mniejszą niż 3 osie:
- [7.3.1/A-1-3] MUSI wdrożyć i raportować
Czujnik
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] MUSI wdrożyć i raportować
Czujnik
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Jeśli żyroskop obejmuje urządzenia motoryzacyjne:
- [7.3.4/A-2-1] MUSI zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
- [7.3.4/A-2-3] MUSI być w stanie mierzyć zmiany orientacji ekranu. do 250 stopni na sekundę.
- [7.3.4/A-SR-1] Zdecydowanie ZALECANE jest skonfigurowanie żyroskopu w zakresie pomiarowym do +/-250 dps w celu maksymalizacji rozdzielczości. jak to tylko możliwe.
Jeśli implementacje urządzeń samochodowych obejmują 3-osiowy żyroskop:
- [7.3.4/A-SR-2] Zdecydowanie ZALECANE jest wdrożenie żyroskop z komponentem dla żyroskopu z ograniczonymi osiami.
Jeśli implementacje urządzeń w branży motoryzacyjnej obejmują żyroskop z mniej niż 3 osiami:
- [7.3.4/A-4-1] MUSI wdrożyć i raportować
Czujnik
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] MUSI wdrożyć i raportować
Czujnik
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
jeśli implementacje urządzeń samochodowych obejmują odbiornik GPS/GNSS, obejmują komórkową transmisję danych za pomocą sieci komórkowej, to:
- [7.3.3/A-3-1] MUSI określić lokalizację za pierwszym razem. odbiornik GPS/GNSS zostanie włączony lub upłynie ponad 4 dni w ciągu 60 sekund.
- [7.3.3/A-3-2] MUSI spełniać kryteria dotyczące czasu do pierwszej poprawki zgodnie opisane w artykułach 7.3.3/C-1-2 i 7.3.3/C-1-6 w przypadku wszystkich pozostałych próśb o lokalizację (tj.próśb, które nie są wysyłane po raz pierwszy) w dowolnym momencie lub po upływie 4+ dni). Wymaganie 7.3.3/C-1-2 to spotykane zwykle w pojazdach bez komórkowej transmisji danych za pomocą sieci komórkowej, wykorzystując prognozy orbity GNSS obliczone na odbiorniku lub ostatnią znaną lokalizację pojazdu wraz z możliwością realizacji transakcji co najmniej 60 sekund z satysfakcjonującą dokładnością pozycji 7.3.3/C-1-3 lub ich połączenie.
Jeśli implementacje urządzeń samochodowych obejmują czujnik TYPE_HEADING
:
- [7.3.4/A-4-3] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 1 Hz.
- [7.3.4/A-SR-3] STRONGLY_RECOMMENDED raportowania zdarzeń do co najmniej 10 Hz.
- POWINNA odnosić się do rzeczywistej północy.
- POWINNA być dostępna, nawet gdy pojazd jest nieruchomy.
- Wymagana jest rozdzielczość co najmniej 1 stopnia.
Implementacje na urządzeniach motoryzacyjnych:
- [7.4.3/A-0-1] MUSI obsługiwać Bluetooth i POWINNO obsługują Bluetooth LE.
- [7.4.3/A-0-2] Implementacje w Androidzie Automotive
MUSI obsługiwać te profile Bluetooth:
- Nawiązywanie połączeń telefonicznych przez profil HFP.
- Odtwarzanie multimediów przez profil dystrybucji dźwięku (A2DP).
- Sterowanie odtwarzaniem multimediów w profilu pilota (AVRCP).
- Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).
[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 takich jak tylny aparat.
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/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).
MOGĄ mieć zaimplementowany sprzętowy autofokus lub programowy autofokus sterownika aparatu.
Jeśli implementacje urządzeń samochodowych obejmują co najmniej jedną kamerę i wczytywać usługę systemu widoku zewnętrznego (EVS), a następnie w przypadku takiego aparatu:
- [7.5/A-2-1] NIE MOŻE obracać ani odbijać w poziomie podgląd z aparatu.
Implementacje na urządzeniach motoryzacyjnych:
- MOŻE zawierać co najmniej jedną kamerę dostępną dla innych firm aplikacji.
Jeśli w implementacjach w urządzeniu samochodowym znajduje się co najmniej jedna kamera dostęp do aplikacji innych firm, wówczas:
- [7.5/A-3-1] MUSI zgłosić flagę funkcji
android.hardware.camera.any
- [7.5/A-3-2] NIE MOŻE deklarować kamery jako aparat systemowy.
- MOŻE obsługiwać zewnętrzne kamery opisane w sekcji 7.5.3.
- MOŻE zawierać funkcje (takie jak autofokus itp.) dostępne dla tylnych zdjęć aparatów zgodnie z opisem w sekcji 7.5.1.
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ą 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:
Implementacje na urządzeniach motoryzacyjnych MUSZĄ obsługiwać to dekodowanie wideo formatów i udostępniać je aplikacjom innych firm:
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 intencjiCAR_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
iERROR_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
iCONTENT_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ądrauid_sys_stats
. - [8.3/A-1-3] MUSI obsługiwać tryb garażu.
- [8.3/A] POWINNY być w trybie garażowym przez co najmniej
15 minut po każdym przejazdie, chyba że:
- Bateria jest rozładowana.
- Nie zaplanowano żadnych nieaktywnych zadań.
- Kierowca wyłącza tryb garażowy.
- [8.4/A-0-1] MUSI zawierać profil zasilania na komponent, który określa bieżącą wartość zużycia dla każdego elementu sprzętowego i przybliżone zużycie baterii przez zgodnie z opisem w witrynie Android Open Source Project.
- [8.4/A-0-2] MUSI zgłaszać całą zasilanie wartości wykorzystania w miliiamperach godzin (mAh).
- [8.4/A-0-3] MUSI raportować moc procesora
na wykorzystanie identyfikatora UID każdego procesu. W projekcie Android Open Source Project
za pomocą modułu jądra
uid_cputime
. - [8.4/A] POWINNO być przypisane do sam komponent sprzętowy, jeśli nie można przypisać wykorzystania energii przez komponent sprzętowy. do aplikacji.
- [8.4/A-0-4] MUSI zapewniać to zużycie energii
dostępne w
adb shell dumpsys batterystats
należy użyć polecenia powłoki do dewelopera aplikacji.
2.5.5 Model zabezpieczeń
Jeśli implementacje urządzeń z branży motoryzacyjnej obsługują wielu użytkowników:
- [9.5/A-1-1] NIE MOŻE umożliwiać użytkownikom interakcji z ani przełączać się na użytkownika systemowego bez interfejsu graficznego, oprócz obsługi administracyjnej urządzeń.
- [9.5/A-1-2] MUSI przejść na użytkownika dodatkowego
przed
BOOT_COMPLETED
. - [9.5/A-1-3] MUSI obsługiwać możliwość tworzenia gość nawet po osiągnięciu maksymalnej liczby użytkowników na urządzeniu.
Jeśli implementacje na urządzeniach motoryzacyjnych zadeklarują android.hardware.camera.any
, wtedy
one:
- [9.8.2/A-2-1] MUSI wyświetlać wskaźnik aparatu, gdy ma dostęp do danych kamery, ale nie wtedy, gdy kamera jest mają dostęp do aplikacji pełniących role nazywane w Sekcja 9.1 Uprawnienia o identyfikatorze CDD [C-3-X].
- [9.8.2/A-2-2] NIE MOŻE ukrywać wskaźnika aparatu dla aplikacje systemowe z widocznymi interfejsami lub bezpośrednią interakcją użytkownika.
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.
- [6.1/A-0-1] MUSI zawierać
2.6. Wymagania dotyczące tabletu
Tablet z Androidem odnosi się do implementacji urządzenia z Androidem, która zwykle spełnia wszystkie następujące kryteria:
- Aby go użyć, przytrzymaj go w obu rękach.
- Nie ma konfiguracji w tradycyjnej obudowie ani urządzenia konwertowalnego.
- Implementacje klawiatury fizycznej używane podczas łączenia urządzenia przez standardowego połączenia (np. USB lub Bluetooth).
- Ma źródło zasilania, które umożliwia mobilność, np. baterię.
- urządzenie ma wyświetlacz o przekątnej większej niż 7 cali i mniejszej niż 18 cali, mierzona z przekątną;
Implementacje na tabletach mają podobne wymagania co urządzenia mobilne implementacji. Wyjątki są w tej sekcji oznaczone symbolem * oraz warte uwagi w tej sekcji.
2.6.1 Sprzęt
Żyroskop
Jeśli implementacje tabletów obejmują 3-osiowy żyroskop:
- [7.3.4/Tab-1-1] MUSI mieć możliwość pomiaru orientacji zmienia się do 1000 stopni na sekundę.
Minimalna pamięć i miejsce na dane (artykuł 7.6.1)
Gęstości ekranu wymienione dla małych/normalnych ekranów w urządzeniu mobilnym nie mają zastosowania do tabletów.
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ługiExtServices
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>
doorg.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 dozwolonej w przypadku Androida 13 |
WERSJA.SDK | Wersja obecnie uruchomionego systemu Android w formacie kod aplikacji innej firmy. W przypadku Androida 13: to pole MUSI zawierać liczbę całkowitą 13_INT. |
VERSION.SDK_INT | Wersja obecnie uruchomionego systemu Android w formacie kod aplikacji innej firmy. W przypadku Androida 13: to pole MUSI zawierać liczbę całkowitą 13_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)/ Na przykład: acme/mojprodukt/ 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ądzenia zgłaszają „android.hardware.telephony.calling”, oznacza to, że:
[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 zPhoneAccounts
, 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 zawieraandroid.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 & 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 & 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 wykrywalnego.
Jeśli implementacje urządzeń obsługują tę funkcję:
- [C-6-1] MUSI wdrożyć działanie, które zareaguje na intencję
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
dla których w implementacjach z interfejsem UI_MODE_TYPE_NORMAL MUSI być to działanie, w którym użytkownik może przyznać lub odmówić aplikacji dostęp do konfiguracji zasad Nie przeszkadzać.
Jeśli implementacje urządzeń pozwalają użytkownikom na korzystanie z metod wprowadzania danych innych firm urządzenia, to:
- [C-7-1] MUSI zawierać dostępny dla użytkownika mechanizm umożliwiający dodawanie i konfigurowanie
zewnętrznych metod wprowadzania w odpowiedzi na
android.settings.INPUT_METHOD_SETTINGS
intencji.
Jeśli implementacje urządzenia obsługują usługi ułatwień dostępu innych firm:
- [C-8-1] MUSI spełniać warunki standardu
android.settings.ACCESSIBILITY_SETTINGS
udostępniającym dostępny dla użytkowników mechanizm włączania i wyłączania usługi ułatwień dostępu innych firm oprócz wstępnie wczytanych ułatwień dostępu usług Google.
Jeśli urządzenia obsługują Wi-Fi Easy Connect i udostępnić funkcji aplikacji innych firm:
- [C-9-1] MUSI zaimplementować Ustawienia#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Interfejsy API intencji zgodnie z opisem w dokumentacji pakietu SDK.
Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych:
- [C-10-1] MUSI zawierać w ustawieniach interfejs użytkownika, który obsługuje
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
Intencje, które pozwalają użytkownikom dodawać aplikacje do listę dozwolonych.
Jeśli implementacje urządzeń nie obsługują trybu oszczędzania danych:
- [C-11-1] MUSI mieć aktywność, która obsługuje
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
ale MOGĄ wdrożyć tę metodę jako no op.
Jeśli implementacje urządzenia zadeklarują obsługę kamery przez
android.hardware.camera.any
, to:
- [C-12-3] MUSI obsługiwać i MUSI zezwalać tylko na zainstalowane fabrycznie aplikacje na Androida
do obsługi następujących intencji
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, iMediaStore.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 & 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
iAutofillManager
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 w Ustawieniach lub w linkach 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.
[C-17-1] [Przeniesione do wersji 2.2.3]
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 Parametryandroid.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
iVK_KHR_get_physical_device_properties2
rozszerzeń przezlibvulkan.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 Elementarmeabi
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 udostępniać 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
13 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:
- [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
iGnssNavigationMessage
. - [C-0-5] MUSZĄ ograniczać częstotliwość aktualizacji
przekazywanej aplikacji przez
LocationManager
Klasa interfejsu API lubWifiManager.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ług
stopSelf()
chyba że aplikacja została umieszczona na tymczasowej liście dozwolonych w celu obsługi widoczne dla użytkownika. - [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI MUSI Puść blokady uśpienia ustawione przez aplikację.
- [C-0-4] MUSI zaprzestać wykonywania wywołań zwrotnych zarejestrowanych przez
do odbierania danych wyjściowych z
- [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 przezProvider.getName()
) i klas, chyba że aplikacja zmodyfikowała listę za pomocąinsertProviderAt()
lubremoveProvider()
. Urządzenia MOŻE zwrócić dodatkowych dostawców po określonej liście dostawców poniżej.- AndroidNSSP –
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL –
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider –
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCObejście –
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC –
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE –
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore –
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP –
Powyższa lista nie jest wyczerpująca. testy CTS (Compatibility Test Suite). ale nie wszystkie z nich. Odpowiedzialność za zapewnienie zgodności pod kątem działania spoczywa na Tobie. w ramach Android Open Source Project. Z tego powodu TREŚCI POWINNY jest używać kodu źródłowego dostępnego w ramach projektu Android Open Source, jest to możliwe, bez konieczności wprowadzania zmian na nowo.
3.5.1 Ograniczenie aplikacji
jeśli implementacje urządzeń implementują zastrzeżony mechanizm ograniczania dostępu aplikacji; (np. przez zmianę lub ograniczenie działań API, które opisane w pakiecie SDK) oraz ten mechanizm jest bardziej ograniczony niż zasobnik gotowości aplikacji z ograniczonym dostępem, tzn.:
- [C-1-1] MUSI umożliwiać użytkownikowi wyświetlenie listy aplikacji objętych ograniczeniami.
- [C-1-2] MUSZĄ zapewnić użytkownikom wsparcie w zakresie włączenia / wyłączenia wszystkich tych funkcji i ograniczeniach zastrzeżonych w każdej aplikacji.
[C-1-3] NIE MOŻE automatycznie stosować tych ograniczeń zastrzeżonych bez wskazuje na słabe działanie systemu, ale MOŻE nałożyć ograniczenia na aplikacje po wykryciu nieprawidłowego działania systemu, takiego jak ciągłe blokady uśpienia, usług i innych kryteriów. Kryteria MOGĄ być określone przez urządzenie implementacji, ale MUSZĄ być związana z wpływem aplikacji na stan systemu. Inny powód kryteria, które nie są bezpośrednio związane ze stanem systemu, takie jak braku popularności na rynku, NIE POWOLNO być wykorzystywane jako kryterium.
[C-1-4] NIE MOŻE automatycznie stosować tych zastrzeżonych ograniczeń do aplikacji gdy użytkownik ręcznie wyłączył ograniczenia aplikacji i MOŻE zasugerować mu tych ograniczeń zastrzeżonych.
[C-1-5] MUSI informować użytkowników, jeśli te ograniczenia zastrzeżone są stosowane do automatycznie uruchamiać aplikację. Takie informacje MUSZĄ zostać dostarczone w ciągu 24 godzin przed zastosowaniem tych ograniczeń zastrzeżonych.
[C-1-6] MUSI zwracać wartość „prawda” w przypadku funkcji ActivityManager.isBackgroundRestricted() dla dowolnych wywołań interfejsu API z aplikacji.
[C-1-7] NIE MOŻE ograniczać aplikacji znajdującej się na pierwszym planie, która jest jawnie używana przez użytkownika.
[C-1-8] MUSI zawiesić te zastrzeżone ograniczenia w aplikacji za każdym razem, użytkownik zaczyna bezpośrednio korzystać z aplikacji, czyniąc ją pierwszym pierwszym planem. aplikacji.
[C-1-10] MUSI dostarczyć publiczny i jasny dokument lub witrynę opisującą stosowania ograniczeń zastrzeżonych. Ten dokument lub witryna MUSI być w dokumentacji pakietu Android SDK i MUSI zawierać:
- Wyzwalanie warunków ograniczeń zastrzeżonych.
- Jakie i w jaki sposób aplikacje mogą podlegać ograniczeniom.
- Jak aplikacja może zostać zwolniona z tych ograniczeń.
- Jak aplikacja może poprosić o zwolnienie z ograniczeń zastrzeżonych, jeśli: obsługiwać takie wyjątek w przypadku aplikacji, które użytkownik może instalować.
jeśli aplikacja jest wstępnie zainstalowana na urządzeniu i nigdy nie była jawnie używana przez ponad 30 dni, [C-1-3] [C-1-5] nie zostaną zwolnieni.
Jeśli implementacje 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 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 zrobić. 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).
POTRZEBUJESZ: należy użyć ś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
zaShortcutManager.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
zaShortcutManager.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 natrue
i nie pokazuj żadnych schematów plakietek aplikacji, gdy wszystkie kanałów powiadomień aplikacji ustawiło wartość nafalse
. - 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()
orazNotification.Builder.setBadgeIconType()
API.
Jeśli implementacje urządzenia obsługują monochromatyczny ikony, te ikony:
- [C-6-1] Trzeba go używać tylko wtedy, gdy użytkownik na to zezwoli (np. w Ustawienia lub menu selektora tapet).
3.8.2 Widżety
Android obsługuje widżety aplikacji innych firm, definiując typ komponentu i odpowiedni interfejs API i cykl życia, które pozwalają aplikacjom na udostępnianie AppWidget 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 do dodawania, konfigurowania, wyświetlania i usuwania elementów AppWidgets.
- [C-1-3] MUSI wyświetlać widżety o wymiarach 4 x 4 w standardowym rozmiarze siatki. Przeczytaj wytyczne dotyczące projektowania widżetów aplikacji. w dokumentacji pakietu Android SDK.
- MOŻE obsługiwać widżety aplikacji na ekranie blokady.
jeśli implementacje urządzeń obsługują widżety i elementy w aplikacji innych firm; przypięcia skrótów:
- [C-2-1] MUSI zgłosić użytkownika
true
zaAppWidgetManager.html.isRequestPinAppWidgetSupported()
- [C-2-2] MUSI poprosić użytkownika o zgodę na dodanie skrótu
przez aplikacje z
AppWidgetManager.requestPinAppWidget()
API.
3.8.3 Powiadomienia
Android obejmuje Notification
oraz
NotificationManager
interfejsy API, które umożliwiają deweloperom aplikacji innych firm powiadamianie użytkowników o ważnych wydarzeniach oraz
przyciągnąć użytkowników uwagi za pomocą komponentów sprzętowych (np. dźwięków, wibracji,
i światła) oraz funkcje oprogramowania (np. obszar powiadomień, pasek systemu)
urządzenia.
3.8.3.1 Prezentacja powiadomień
Jeśli implementacje urządzeń umożliwiają aplikacjom innych firm powiadamianie użytkowników o ważnych wydarzeniach:
- [C-1-1] MUSI obsługiwać powiadomienia korzystające z funkcji sprzętowych zgodnie z opisem w dokumentacji pakietu SDK oraz w zakresie, w jakim jest to możliwe dzięki wdrożeniu na urządzeniu sprzęt. Jeśli na przykład urządzenie jest wyposażone w wibracje, MUSI mieć poprawnie zaimplementować interfejsy API wibracji. Jeśli na urządzeniu brakuje implementacji sprzęt, odpowiednie interfejsy API MUSZĄ być zaimplementowane w trybie bezobsługowym. Działanie to szerzej znajdziesz w sekcji 7.
- [C-1-2] MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki animacji itp.) udostępniane w interfejsach API lub Przewodnik po stylu ikon na pasku stanu/systemu, chociaż MOGĄ one zapewnić użytkownikom alternatywny sposób obsługi powiadomień niż pozwala na to referencyjna implementacja Android Open Source.
- [C-1-3] MUSI przestrzegać i właściwie wdrażać zachowania opisane interfejsy API , aby aktualizować, usuwać i grupować powiadomienia.
- [C-1-4] MUSI zawierać pełne informacje o działaniu notificationChannel. Interfejs API jest udokumentowany w pakiecie SDK.
- [C-1-5] MUSI zapewniać użytkownikowi możliwość blokowania i modyfikowania określonych powiadomienia wysyłane przez aplikację innej firmy na każdy poziom kanału i pakietu aplikacji.
- [C-1-6] MUSI też udostępniać zgodę użytkownika na wyświetlanie usuniętych powiadomień kanałów.
- [C-1-7] MUSI prawidłowo renderować wszystkie zasoby (obrazy, naklejki, ikony itp.) przekazywane przez Powiadomienie.MessagingStyle obok tekstu powiadomienia bez dodatkowej interakcji ze strony użytkownika. Dla: przykład MUSI pokazywać wszystkie zasoby, w tym ikony dostarczane przez android.app.Person, w rozmowie grupowej, która jest setGroupConversation.
- [C-SR-1] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości zakupu kontrolować powiadomienia dla aplikacji, którym przyznano uprawnienia Uprawnienia detektora powiadomień. Szczegółowość MUSI być precyzyjna, tak aby użytkownik mógł określ typy powiadomień dla każdego detektora powiadomień połączone z tym słuchaczem. Typy MUSZĄ obejmować „wątki”, „alerty”, „ciche” i „ważne ciągłe” powiadomienia.
- [C-SR-2] Zdecydowanie ZALECANE jest podanie przez użytkowników liczby dostępnych wartości wykluczyć aplikacje z powiadomienia konkretnego detektora powiadomień.
- [C-SR-3] Zdecydowanie ZALECANE są automatyczne wyświetlanie aprobaty dla użytkowników. blokować powiadomienia z określonej aplikacji innej firmy w przypadku każdego kanału i aplikacji poziomu pakietu po wielokrotnym zamknięciu tego powiadomienia przez użytkownika.
- OBSŁUGA powiadomień rozszerzonych.
- TRZEBA pokazywać powiadomienia o wyższym priorytecie jako powiadomienia typu HUD.
- MUSISZ mieć możliwość uśpienia powiadomień.
- MOŻE zarządzać tylko widocznością i czasem, w którym aplikacje innych firm mogą wysyłać powiadomienia użytkowników biorących udział w ważnych wydarzeniach w celu ograniczenia problemów związanych z bezpieczeństwem, takich jak rozpraszanie uwagi kierowcy.
Android 11 wprowadza obsługę powiadomień o rozmowach, które są powiadomienia korzystające z interfejsu MessagingStyle. i udostępnia opublikowany identyfikator skrótu People.
Implementacje na urządzeniach:
- [C-SR-4] Zdecydowanie ZALECANE są grupowania i wyświetlania
conversation notifications
przed powiadomieniami niedotyczącymi rozmowy, z wyjątkiem bieżące powiadomienia usługi na pierwszym planie orazimportance:high
powiadomienia.
Jeśli implementacje na urządzeniach obsługują conversation notifications
Dostarczy ona danych wymaganych do
bubbles
:
- [C-SR-5] Zdecydowanie ZALECANE jest wyświetlanie tej rozmowy w dymku. Implementacja AOSP spełnia te wymagania w domyślnym interfejsie systemu, Ustawienia i Menu z aplikacjami.
Jeśli implementacje urządzeń obsługują powiadomienia rozszerzone, zostaną w nich wprowadzone zmiany:
- [C-2-1] MUSI korzystać z dokładnie takich zasobów, jak
zapewniana przez
Notification.Style
Klasa interfejsu API i jej podklasy dla prezentowanych elementów zasobów. - POWINIEN zaprezentować każdy element zasobu (np.
ikony, tytułu i tekstu podsumowania) zdefiniowanego w narzędziu
Notification.Style
Klasa interfejsu API i jej podklasy.
Powiadomienia z ostrzeżeniem to powiadomienia, które są prezentowane użytkownikowi w miarę, jak wchodzą w niego niezależnie od powierzchni, z której włącz. Jeśli implementacje urządzenia obsługują funkcję Uważaj na przejściu powiadomienia, a następnie:
- [C-3-1] MUSI korzystać z widoku powiadomień i zasobów
zgodnie z opisem na stronie
Notification.Builder
Klasa interfejsu API, gdy wyświetlane są powiadomienia z ostrzeżeniem. - [C-3-2] MUSI wyświetlać działania wykonane przez
Notification.Builder.addAction()
razem z treścią powiadomień bez dodatkowej interakcji ze strony użytkownika zgodnie z opisem w pakiecie SDK.
3.8.3.2 Usługa powiadamiania słuchaczy
Android obejmuje NotificationListenerService
Interfejsy API, które umożliwiają aplikacjom (raz jawnie włączone przez użytkownika) otrzymywanie kopii
wszystkie powiadomienia
w miarę ich publikowania lub aktualizowania.
Implementacje na urządzeniach:
- [C-0-1] MUSI prawidłowo i szybko aktualizować powiadomienia wszystkich zainstalowanych i włączanych przez użytkownika usług detektorów, w tym wszystkie metadane dołączone do obiektu Notification (Powiadomienie).
- [C-0-2] MUSI respektować:
snoozeNotification()
wywołanie interfejsu API i zamknięcie powiadomienia oraz wywołanie zwrotne po uśpieniu. ustawionym w wywołaniu interfejsu API.
Jeśli implementacje urządzeń pozwalają użytkownikom na uśpienie powiadomień:
- [C-1-1] MUSI prawidłowo odzwierciedlać stan uśpionych powiadomień
przy użyciu standardowych interfejsów API, takich jak
NotificationListenerService.getSnoozedNotifications()
- [C-1-2] MUSISZ udostępnić temu użytkownikowi zgodę na usypianie powiadomień z każdej zainstalowanej aplikacji innej firmy, chyba że pochodzą usług trwałych/działających na pierwszym planie.
3.8.3.3 Tryb Nie przeszkadzać / Priorytet
Jeśli implementacje urządzeń obsługują funkcję Nie przeszkadzać (nazywany też trybem priorytetowym), to:
- [C-1-1] MUSI, jeśli implementacja urządzenia zapewnia użytkownikowi środki aby przyznać aplikacjom innych firm dostęp do konfiguracji zasad Nie przeszkadzać lub go zablokować, Wyświetl Automatyczne reguły Nie przeszkadzać tworzonych przez aplikacje 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 przezNotificationManager.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.
[C-1-4] MUSI generować dynamiczne palety kolorów zgodnie z wymaganiami AOSP. dokumentacja
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(zobaczandroid.theme.customization.system_palette
iandroid.theme.customization.theme_style
).[C-1-5] MUSI generować dynamiczne palety kolorów przy użyciu stylów motywów kolorystycznych. wymienione w
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
dokumentacja (patrzandroid.theme.customization.theme_styles
), czyliTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
.„Kolor źródła” służy do generowania dynamicznych palet kolorów przy wysyłaniu z
android.theme.customization.system_palette
(jak opisano wSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1–6] MUSI mieć wartość barwy
CAM16
równą 5 lub większą.POWINNA POWIĄZAĆ na podstawie tapety przez
com.android.systemui.monet.ColorScheme#getSeedColors
, która zapewnia możesz wybrać jeden z wielu prawidłowych kolorów źródłowych.Jeśli żaden z podanych kolorów nie jest zgodny, należy użyć wartości
0xFF1B6EF3
powyższego wymagania dotyczącego koloru źródła.
Android 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 , ważne jest, aby styl ikony na pasku stanu został zachowany na różnych urządzeniach.
Jeśli implementacje urządzeń mają systemowy pasek stanu:
- [C-2-1] TREŚCI MUSZĄ być białe na białych ikonach 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, kontrolka 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ą włączone animowane tapety:
- [C-1-1] MUSI zgłosić flagę funkcji platformy android.software.live_wallpaper.
3.8.8 Przełączanie aktywności
Fragment kodu źródłowego Androida zawiera funkcje ekran Przegląd, interfejs użytkownika na poziomie systemu do przełączania zadań i wyświetlania ostatnio używanych za pomocą miniatury graficznej aplikacji w chwili ostatniego opuszczenia aplikacji przez użytkownika.
Implementacje na urządzeniach w tym klawisz nawigacyjny funkcji ostatnich, zgodnie z opisem w sekcja 7.2.3 MOŻE zmienić interfejs.
Jeśli implementacje urządzeń obejmujące klawisz nawigacyjny funkcji ostatnich, zgodnie z opisem w punktu 7.2.3 modyfikują interfejs, dlatego:
- [C-1-1] MUSI obsługiwać do 7 wyświetlonych działań.
- NALEŻY wyświetlać przynajmniej tytuł 4 aktywności jednocześnie.
- [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ć aktywowanie trybu wielu okien podzielonego ekranu, jeśli jest obsługiwany, gdy klawisz funkcji ostatnich jest wciśnięty i przytrzymaj.
- MOŻE wyświetlać ostatnie powiązane zdjęcia jako grupę poruszającą się razem.
- [C-SR-1] Zdecydowanie ZALECANE jest użycie użytkownika nadrzędnego Androida. interfejsu (lub podobnego interfejsu opartego na miniaturach) do wyświetlenia na ekranie Przegląd.
3.8.9 Zarządzanie danymi wejściowymi
Android zapewnia obsługę Zarządzanie danymi wejściowymi oraz obsługę zewnętrznych edytorów metody wprowadzania.
Jeśli implementacje urządzeń pozwalają użytkownikom na korzystanie z metod wprowadzania danych innych firm urządzenia, to:
- [C-1-1] MUSI zadeklarować funkcję platformy android.software.input_methods i obsługują interfejsy IME API zgodnie z definicją podaną w dokumentacji pakietu Android SDK.
3.8.10. Sterowanie multimediami na ekranie blokady
Interfejs Remote Control Client API został wycofany z Androida 5.0 i zastąpiony Szablon powiadomienia o multimediach który pozwala aplikacjom do multimediów integrować się z elementami sterującymi odtwarzaniem, wyświetlanych na ekranie blokady.
3.8.11 Wygaszacze ekranu (wcześniej Sny)
Ustawienia znajdziesz w sekcji 3.2.3.5 aby skonfigurować wygaszacze ekranu.
3.8.12. Lokalizacja
Jeśli urządzenia są wyposażone w czujnik sprzętowy (np. GPS), który umożliwia podawania współrzędnych lokalizacji,
- [C-1-2] MUSI wyświetlać aktualny stan lokalizacji w menu Lokalizacja w Ustawieniach.
- [C-1-3] NIE MOŻE wyświetlać trybów lokalizacji w menu Lokalizacja w Ustawieniach.
3.8.13. Unicode i czcionka
Android obsługuje znaki emoji zdefiniowane w Unicode 10.0.
Jeśli implementacje urządzeń obejmują wyjście ekranu lub wideo:
- [C-1-1] MUSI być w stanie renderować znaki z emotikonów w kolorze glifu.
- [C-1-2] MUSI zawierać informacje dotyczące:
- Czcionka Roboto 2 o różnych wagach: sans-szeryfowa-cienka, bezszeryfowa-jasna bezszeryfowa-średnia, czarna bezszeryfowa, bezszeryfowa-kondensowana, bezszeryfowa-kondensowana-świetlna dla języków dostępnych na urządzeniu.
- Pełne zapisy Unicode 7.0 w alfabecie łacińskim, greckim i cyrylicy, w tym Rozszerzone zakresy A, B, C i D w alfabecie łacińskim oraz wszystkie glify w walucie blok symboli Unicode 7.0.
- [C-1-3] NIE MOŻE usuwać ani modyfikować pliku NotoColorEmoji.tff z obrazu systemu. (Można dodać nową czcionkę emotikonów, aby zastąpić emotikon NotoColorEmoji.tff).
- POWINNA spełniać odcień skóry i różnorodne emotikony rodzinne, zgodnie z opisem w Raport techniczny Unicode nr 51.
Jeśli implementacje urządzeń obejmują edytor IME:
- TRZEBA określić metodę wprowadzania znaków w przypadku tych emotikonów.
Android zapewnia obsługę renderowania czcionek birmańskich. Mjanma ma kilka czcionki niezgodne ze standardem Unicode, powszechnie znane jako „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 dotyczącymi 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 plikuAndroidManifest.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
iAndroidManifestLayout_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 deklarujeandroid:resizeableActivity
orazandroid: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
iAndroidManifestLayout_minHeight
:- Urządzenia ze skonfigurowanym trybem Configuration.uiMode innym niż
UI_MODE_TYPE_TELEVISION
Minimalna szerokość i wysokość to 108 dp. - Urządzenia z ustawieniem Configuration.uiMode ustawionym na
UI_MODE_TYPE_TELEVISION
Minimalna szerokość to 240 dp, a minimalna wysokość 135 dp.
- Urządzenia ze skonfigurowanym trybem Configuration.uiMode innym niż
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 związane z poszczególnymi urządzeniami znajdziesz w sekcji 2_2_3.
3.8.17. Schowek
Implementacje na urządzeniach:
- [C-0-1] NIE MOŻE wysyłać danych ze schowka do żadnego komponentu, aktywności, usługi ani niezależnie od połączenia sieciowego, bez wyraźnej czynności ze strony użytkownika (np. naciśnięcia klawisza w nakładce), z wyjątkiem usług wymienionych w 9.8.6 Rejestrowanie treści i wyszukiwanie aplikacji.
czy implementacje urządzeń generują podgląd widoczny dla użytkowników podczas kopiowania treści,
do schowka dla dowolnego elementu ClipData
, gdzie
ClipData.getDescription().getExtras()
zawiera
android.content.extra.IS_SENSITIVE
, to oni:
- [C-1-1] MUSI usunąć widoczny podgląd
Implementacja referencyjna AOSP spełnia te wymagania dotyczące schowka.
3.9. Administracja urządzeniem
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:
- Gdy implementacja urządzenia
ani użytkownicy, ani
skonfigurowanych danych użytkownika, oznacza to, że:
- [C-1-5] MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia
lub włącz aplikację DPC,
zostanie właścicielem urządzenia lub właścicielem profilu;
jeśli urządzenie deklaruje obsługę komunikacji Near-Field Communications (NFC) za pośrednictwem
flaga funkcji
android.hardware.nfc
i otrzymuje wiadomość NFC zawierający rekord z typem MIMEMIME_TYPE_PROVISIONING_NFC
- [C-1-8] MUSI wysłać tryb ACTION_GET_PROVISIONING_MODE
po uruchomieniu obsługi administracyjnej właściciela urządzenia, dzięki czemu
Aplikacja DPC może zdecydować, czy chcesz zostać właścicielem urządzenia czy profilem
Właściciel w zależności od wartości
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, chyba że można je ustalić na podstawie że istnieje tylko jedna prawidłowa opcja. - [C-1-9] MUSI wysłać ACTION_ADMIN_POLICY_COMPLIANCE dla aplikacji Właściciel urządzenia, jeśli został ustanowiony właściciel urządzenia podczas obsługi administracyjnej niezależnie od używanej metody obsługi administracyjnej. użytkownik nie może mieć możliwości kontynuowania kreatora konfiguracji do czasu Aplikacja Właściciel urządzenia kończy działanie.
- [C-1-5] MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia
lub włącz aplikację DPC,
zostanie właścicielem urządzenia lub właścicielem profilu;
jeśli urządzenie deklaruje obsługę komunikacji Near-Field Communications (NFC) za pośrednictwem
flaga funkcji
- Gdy implementacja urządzenia
użytkowników lub
danych użytkownika, oznacza to, że:
- [C-1-7] NIE MOŻE rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia więcej informacji.
- Gdy implementacja urządzenia
ani użytkownicy, ani
skonfigurowanych danych użytkownika, oznacza to, że:
- [C-1-2] MUSI zawierać odpowiednie powiadomienie o zbieraniu danych (jak wspomniano w artykule AOSP) i uzyskać zgodę użytkownika przed rozpoczęciem korzystania z aplikacji ustawione jako właściciel urządzenia, chyba że urządzenie zostało skonfigurowane automatycznie. dla trybu demonstracyjnego dla sprzedawców przed interakcją użytkownika z reklamą.
Jeśli implementacje urządzeń zadeklarują android.software.device_admin
, ale również
zawierają zastrzeżone rozwiązanie do zarządzania urządzeniami 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 skonfigurowane w naszym zastrzeżonym rozwiązaniu, 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”. - [C-2-3] NIE MOŻE kodować zgody na stałe ani zapobiegać korzystanie z innych aplikacji właściciela 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 działania ACTION_PROVISIONING_successFUL w profilu służbowym, jeśli został ustanowiony właściciel profilu podczas obsługa administracyjna jest inicjowana przez profil android.app.action.PROVISION_MANAGED_PROFILE. a DPC zaimplementował moduł obsługi.
[C-1-5] MUSI wysłać ACTION_PROFILE_PROVISIONING_COMPLETE są wysyłane do DPC profilu służbowego po zainicjowaniu obsługi administracyjnej android.app.action.PROVISION_MANAGED_PROFILE intencji.
[C-1-6] MUSI wysłać tryb ACTION_GET_PROVISIONING_MODE po uruchomieniu obsługi administracyjnej właściciela profilu, tak aby aplikacja DPC mogą zdecydować, czy zostać właścicielem urządzenia czy właścicielem profilu, chyba że obsługa administracyjna jest uruchamiana przez intencję android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] MUSI wysłać ACTION_ADMIN_POLICY_COMPLIANCE do profilu służbowego, gdy zostanie utworzony właściciel profilu obsługi administracyjnej niezależnie od używanej metody obsługi administracyjnej z wyjątkiem: gdy obsługa administracyjna jest uruchamiana przez intencję android.app.action.PROVISION_MANAGED_PROFILE. Użytkownik nie może mieć możliwości kontynuowania w kreatorze konfiguracji, dopóki profil nie zostanie Aplikacja właściciela kończy działanie.
[C-1-8] MUSI wysłać ACTION_MANAGED_PROFILE_PROVISIONED do profilu osobistego DPC po utworzeniu właściciela profilu. niezależnie od użytej metody obsługi administracyjnej.
3.9.2 Obsługa profilu zarządzanego
Jeśli implementacje urządzenia zadeklarują android.software.managed_users
:
- [C-1-1] MUSI obsługiwać profile zarządzane za pomocą
android.app.admin.DevicePolicyManager
API. - [C-1-2] MUSI zezwalać na utworzenie tylko jednego profilu zarządzanego.
- [C-1-3] MUSI używać plakietki ikony (podobnej do plakietki pracy nadającej AOSP) do reprezentują zarządzane aplikacje i widżety oraz inne elementy interfejsu z plakietką np. Ostatnie i Powiadomienia.
- [C-1-4] MUSI wyświetlać ikonę powiadomienia (podobna do działania na wyższym poziomie AOSP ) wskazującą, kiedy użytkownik korzysta z aplikacji profilu zarządzanego.
- [C-1-5] MUSI wyświetlać toast informujący o tym, że użytkownik korzysta z zarządzanej usługi profilu po wybudzeniu urządzenia (ACTION_USER_PRESENT). aplikacja na pierwszym planie znajduje się w profilu zarządzanym.
- [C-1-6] Jeśli istnieje profil zarządzany, MUSI wykazywać afordancję w sekcji Intencja „Chooser” aby umożliwić użytkownikowi przekazanie intencji z zarządzanego głównemu użytkownikowi lub odwrotnie, po włączeniu Zasad dotyczących urządzeń kontroler.
- [C-1-7] Jeśli istnieje profil zarządzany, MUSI udostępniać następujące konto użytkownika
zarówno dla użytkownika głównego, jak i profilu zarządzanego:
- Oddzielne zliczanie baterii, lokalizacji, mobilnej transmisji danych i wykorzystania miejsca na dane dla głównego użytkownika i profilu zarządzanego.
- Niezależne zarządzanie aplikacjami VPN zainstalowanymi w głównym użytkownika lub profilu zarządzanego.
- Niezależne zarządzanie aplikacjami zainstalowanymi u głównego użytkownika lub profilu zarządzanego.
- Niezależne zarządzanie kontami głównego użytkownika lub zarządzanych kont profil.
- [C-1-8] MUSI mieć zainstalowaną fabrycznie zainstalowaną aplikację telefonu, kontakty i wiadomości aplikacje mogą wyszukiwać i wyszukiwać informacje o rozmówcy w zarządzanych profilu (jeśli istnieje) i profilu głównego, jeśli Kontroler zasad dotyczących urządzeń na to zezwala.
- [C-1-9] MUSI mieć pewność, że spełnia wszystkie wymagania dotyczące bezpieczeństwa dotyczy urządzenia z włączonymi wieloma użytkownikami (patrz sekcja 9.5), nawet jeśli profil zarządzany nie jest liczony jako inny użytkownik oprócz użytkownika głównego.
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.
- Implementacje na urządzeniach MUSZĄ spełniać
- 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
zwracatrue
. Karta użytkownika MUSI być dostępna na ekranie blokady bez odblokowywania urządzenia.
Jeśli implementacje urządzeń zadeklarują android.software.device_admin
i przekażą
więcej użytkowników pomocniczych na urządzeniu.
- [C-SR-1] Zdecydowanie ZALECANE jest posiadanie takiej samej zgody właściciela urządzenia AOSP oświadczenia wyświetlane w ramach procesu zainicjowanego przez android.app.action.PROVISION_MANAGED_DEVICE, przed zezwoleniem na dodawanie kont nowego użytkownika dodatkowego, aby użytkownicy wiedzieli, że urządzenie jest zarządzane.
3.9.4 Wymagania roli zarządzania zasadami dotyczącymi urządzeń
Jeśli implementacje urządzeń zgłaszają android.software.device_admin
lub
android.software.managed_users
, to:
- [C-1-1] MUSI obsługiwać rolę zarządzania zasadami dotyczącymi urządzeń, zgodnie z definicją w
art. 9.1. aplikację, która pełni rolę zarządzania zasadami dotyczącymi urządzeń;
MOŻNA ją zdefiniować, ustawiając
config_devicePolicyManagement
na nazwę pakietu. Po nazwie pakietu MUSI występować ciąg:
i certyfikat podpisywania, chyba że aplikacja jest wstępnie wczytana.
Jeśli nazwa pakietu nie jest zdefiniowana dla config_devicePolicyManagement
jako
opisane powyżej:
- [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać obsługę administracyjną bez urządzenia wniosek o rolę podmiotu zarządzającego polityką (AOSP udostępnia implementację referencyjną).
Jeśli nazwa pakietu jest zdefiniowana dla config_devicePolicyManagement
zgodnie z opisem
powyżej:
- [C-3-1] Aplikacja MUSI być zainstalowana na wszystkich profile dla użytkownika.
- [C-3-2] Implementacje na urządzeniach MOGĄ definiować aplikację, która aktualizuje
właściciel roli zarządzania zasadami dotyczącymi urządzeń przed obsługą administracyjną według ustawienia
config_devicePolicyManagementUpdater
Jeśli nazwa pakietu jest zdefiniowana dla config_devicePolicyManagementUpdater
jako
opisane powyżej:
- [C-4-1] Aplikacja MUSI być wstępnie zainstalowana na urządzeniu.
- [C-4-2] Aplikacja MUSI zaimplementować filtr intencji, który rozwiązuje
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
3.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 zarejestrowanychAccessibilityService
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 zewnętrzne dane wejściowe 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()
lubgetIconUri()
oraz tytuły uzyskane za pośrednictwemgetTitle()
, jak opisano wMediaDescription
. 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
lubKEYCODE_MEDIA_PLAY_PAUSE
jakoKEYCODE_MEDIA_NEXT
dlaMediaSession.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ądzeń zadeklarują funkcję FEATURE_CANT_SAVE_STATE
,
to:
- [C-1-1] MUSI mieć zainstalowaną tylko jedną aplikację, która określa
cantSaveState
działających 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 kontaktów 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 doContactsContract.RawContacts.getLocalAccountName
- [C-1-2]
ACCOUNT_TYPE
z niestandardowego konta lokalnego MUSZĄ zostać zwrócone doContactsContract.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
iACCOUNT_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 parametrCALLER\_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.
[C-0-2] MUSI obsługiwać weryfikację plików „.apk” za pomocą Schemat podpisu APK w wersji 3.1, Schemat podpisu pliku APK w wersji 3, Schemat podpisu pliku APK w wersji 2 i podpisywanie plików JAR.
[C-0-3] NIE MOŻE wydłużać Pliki APK, Plik manifestu Androida kod bajtowy Dalvik lub z kodami bajtowymi RenderScript w taki sposób, że uniemożliwia to 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 ustawandroid:targetSdkVersion
na 24 lub mniej. - Użytkownik MUSI przyznać uprawnienia do instalowania aplikacji z nieznanych źródeł.
- MUSI zadeklarować
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
dlastartActivityForResult()
, , 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 APIPackageManager.setHarmfulAppWarning
jako potencjalnie szkodliwe.MUSISZ dać użytkownikowi możliwość odinstalowania lub uruchomienia aplikacji w oknie ostrzeżenia.
[C-0-8] MUSI wdrożyć obsługę przyrostowego systemu plików zgodnie z opisem tutaj.
[C-0-9] MUSI obsługiwać weryfikację plików .apk przy użyciu schematu podpisu pliku APK w wersji 4 i Schemat podpisu APK w wersji 4.1.
5. Zgodność multimediów
Implementacje na urządzeniach:
- [C-0-1] MUSI obsługiwać formaty multimedialne, kodery, dekodery, typy plików
i formaty kontenerów zdefiniowane w sekcji 5.1.
dla każdego kodeka zadeklarowanego przez
MediaCodecList
. - [C-0-2] MUSI zadeklarować i zgłosić obsługę dostępnych koderów i dekoderów
do aplikacji innych firm za pośrednictwem
MediaCodecList
- [C-0-3] MUSI być w stanie poprawnie dekodować i udostępniać
we wszystkich formatach, które potrafi zakodować. Obejmuje to wszystkie strumienie bitowe, których
generowane przez kodery oraz profile zgłaszane w
CamcorderProfile
Implementacje na urządzeniach:
- NALEŻY dążyć do minimalnego opóźnienia kodeka. Inaczej mówiąc,
- NIE POWINNY jest wykorzystywać ani przechowywać buforów wejściowych ani zwracanych buforów wejściowych po przetworzeniu danych.
- NIE NALEŻY przechowywać zdekodowanych buforów przez czas dłuższy niż określony w (np. SPS).
- NIE NALEŻY przechowywać kodowanych buforów dłużej niż wymaga tego GOP. do jego struktury.
Wszystkie kodeki wymienione w sekcji poniżej są udostępniane jako oprogramowanie w preferowanej implementacji na Androidzie z programu Android Open, Projekt źródłowy.
Pamiętaj, że ani Google, ani Open Handset Alliance nie nakładają żadnych oświadczenie, że kodeki nie są objęte patentami innych firm. Te wartości zamierzających używać tego kodu źródłowego w sprzęcie lub oprogramowaniu, zalecamy które implementacje tego kodu, w tym również w oprogramowaniu open source, oprogramowanie współdzielone może wymagać licencji patentowych od odpowiednich właścicieli patentów.
5.1. Kodeki multimediów
5.1.1 Kodowanie dźwięku
Więcej informacji znajdziesz w artykule 5.1.3. Szczegóły kodeków audio.
Jeśli implementacje urządzeń zadeklarują android.hardware.microphone
,
MUSZĄ obsługiwać kodowanie poniższych formatów audio i udostępnić je
do aplikacji innych firm:
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
Wszystkie kodery audio MUSZĄ obsługiwać:
- [C-3-1] 16-bitowa natywna kolejność bajtów audio PCM przez interfejs
android.media.MediaCodec
API.
5.1.2 Dekodowanie dźwięku
Więcej informacji znajdziesz w artykule 5.1.3. Szczegóły kodeków audio.
Jeśli implementacje urządzeń zadeklarują obsługę
android.hardware.audio.output
, musi obsługiwać dekodowanie
następujące formaty dźwięku:
- [C-1-1] Profil AAC MPEG-4 (AAC LC)
- [C-1-2] Profil AAC MPEG-4 HE (AAC+)
- [C-1-3] Profil MPEG-4 HE AACv2 (ulepszony AAC+)
- [C-1-4] AAC ELD (rozszerzony format AAC z niskim opóźnieniem)
- [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, który obejmuje: profil Baseline USAC i zakres dynamiczny ISO/IEC 23003-4 profil kontrolny)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE z dźwiękiem w wysokiej rozdzielczości maksymalnie 24 bity, częstotliwość próbkowania 192 kHz i 8 kanałów. Pamiętaj, że wymaga to jedynie dekodowania, a urządzenie można redukować i miksować w fazie odtwarzania.
- [C-1-10] Opus
Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC
strumienie wielokanałowe (tj. więcej niż 2 kanały) do PCM domyślnie
w dekoderze dźwięku AAC w interfejsie API android.media.MediaCodec
, MUSISZ
obsługiwane:
- [C-2-1] Dekodowanie MUSI być wykonywane bez miksowania (np. AAC 5.0) strumień musi być zdekodowany na 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
iKEY_AAC_ENCODED_TARGET_LEVEL
. - [C-SR-1] Zdecydowanie ZALECANE jest, aby powyższe wymagania C-2-1 i C-2-2 były dla wszystkich dekoderów dźwięku AAC.
Podczas dekodowania dźwięku USAC MPEG-D (ISO/IEC 23003-4):
- [C-3-1] Trzeba interpretować i stosować metadane dotyczące głośności i metadanych DRRC zgodnie z poziomem 1 profilu kontroli zakresu dynamiki MPEG-D DRC.
- [C-3-2] Dekoder MUSI działać zgodnie z konfiguracją
ustawiono za pomocą tych kluczy (
android.media.MediaFormat
):KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
iKEY_AAC_DRC_EFFECT_TYPE
.
Dekodery profilu MPEG-4 AAC, HE AAC i HE AACv2:
- MOŻE obsługiwać kontrolę głośności i zakresu dynamicznego według normy ISO/IEC 23003-4 Profil dynamicznej kontroli zakresu.
Jeśli obsługiwany jest standard ISO/IEC 23003-4 oraz zarówno ISO/IEC 23003-4, Metadane ISO/IEC 14496-3 są zawarte w zdekodowanym strumieniu bitowym, a potem:
- Metadane ISO/IEC 23003-4 MUSZĄ mieć pierwszeństwo.
Wszystkie dekodery audio MUSZĄ obsługiwać:
- [C-6-1] 16-bitowa natywna kolejność bajtów audio PCM przez interfejs
android.media.MediaCodec
API.
Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC
strumienie wielokanałowe (tj. więcej niż 2 kanały) do PCM domyślnie
w dekoderze dźwięku AAC w interfejsie API android.media.MediaCodec
, to MUSISZ wykonać poniższy kod
być obsługiwane:
- [C-7-1] MUSI być skonfigurowany przez aplikację za pomocą dekodowania
z kluczem
KEY_MAX_OUTPUT_CHANNEL_COUNT
aby kontrolować, czy treści mają być miksowane do stereo (przy użyciu wartości 2) lub jest zwracany z użyciem natywnej liczby kanałów (w przypadku użycia wartości równej lub większa od tej liczby). Na przykład wartość 6 lub większa zostanie skonfigurowana dekoder do przesyłania treści 5.1 na 6 kanałów. - [C-7-2] Podczas dekodowania dekoder MUSI reklamować używaną maskę kanału
na formacie wyjściowym z atrybutem
KEY_CHANNEL_MASK
ze stałymiandroid.media.AudioFormat
(przykład:CHANNEL_OUT_5POINT1
).
Jeśli implementacje urządzeń obsługują dekodery audio inne niż domyślny kod AAC za pomocą dekodera dźwięku i który jest w stanie wysyłać dźwięk wielokanałowy (tj. więcej niż 2 kanałów) podczas przesyłania skompresowanych treści wielokanałowych, a potem:
- [C-SR-2] Zdecydowanie ZALECANE jest możliwość skonfigurowania dekodera przez
za pomocą dekodowania za pomocą klucza
KEY_MAX_OUTPUT_CHANNEL_COUNT
aby kontrolować, czy treści mają być miksowane do stereo (przy użyciu wartości 2) lub jest zwracany z użyciem natywnej liczby kanałów (w przypadku użycia wartości równej lub większa od tej liczby). Na przykład wartość 6 lub większa zostanie skonfigurowana dekoder do przesyłania treści 5.1 na 6 kanałów. - [C-SR-3] Zdecydowanie ZALECANE jest użycie dekodera do reklamowania
w formacie wyjściowym z atrybutem
KEY_CHANNEL_MASK
ze stałymi android.media.AudioFormat (przykład:CHANNEL_OUT_5POINT1
).
5.1.3 Szczegóły kodeków audio
Format/kodek | Szczegóły | Obsługiwane typy plików i kontenerów |
---|---|---|
Profil AAC MPEG-4 (AAC LC) |
Obsługa treści mono/stereo/5.0/5.1 w standardzie częstotliwości próbkowania od 8 do 48 kHz. |
|
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. |
|
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. |
|
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. |
|
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. |
|
MP3 | Stała szybkość transmisji bitów mono/Stereo 8–320 kb/s (CBR) lub zmienna szybkość transmisji bitów (VBR) |
|
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 |
|
Vorbis | Dekodowanie: obsługa treści mono, stereo, 5.0 i 5.1 z próbkowaniem
8000, 12 000, 16 000, 24 000 i 48 000 Hz. Kodowanie: obsługa treści mono i stereo z częstotliwością próbkowania 8000, 12000, 16 000, 24 000 i 48 000 Hz. |
|
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. |
|
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
konfiguracjiandroid.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
) doCodecCapabilities
.[C-SR-1] Zdecydowanie zalecana obsługa formatu kolorów RGB888 dla interfejsu wejściowego Surface i trybu uzyskiwania zgody.
[C-1-3] MUSI obsługiwać co najmniej jeden planarny lub półpłaszczyzny Format koloru YUV420 8:8:8:
COLOR_FormatYUV420PackedPlanar
(odpowiednikCOLOR_FormatYUV420Planar
) lubCOLOR_FormatYUV420PackedSemiPlanar
(odpowiednik doCOLOR_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
) doCodecCapabilities
.[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
(odpowiednikCOLOR_FormatYUV420Planar
) lubCOLOR_FormatYUV420PackedSemiPlanar
(odpowiednikCOLOR_FormatYUV420SemiPlanar
). Zdecydowanie zalecamy stosowanie tych rozwiązań w obu tych przypadkach.[C-SR-1] Zdecydowanie ZALECANE jest obsługa przy użyciu koderów i dekoderów wideo co najmniej jeden kolor planarny lub półpłaszczyzny YUV420 zoptymalizowany pod kątem sprzętu; kolor: 8:8:8 (YV12, NV12, NV21 lub równoważny format zoptymalizowany przez dostawcę).
[C-1-5] Dekodery wideo, które obsługują format z dużą głębią bitów (Ponad 9 bitów na kanał) MUSI obsługiwać wyświetlanie równoważnego formatu 8-bitowego, jeśli żądane przez aplikację. MUSI to zostać uwzględnione przez wsparcie Format kolorów YUV420 8:8:8 za pomocą
android.media.MediaCodecInfo
.
Jeśli implementacje urządzenia reklamują obsługę profilu HDR przez
Display.HdrCapabilities
one:
- [C-2-1] MUSI obsługiwać analizowanie i obsługę statycznych metadanych HDR.
Jeśli implementacje urządzeń reklamują obsługę wewnętrznego odświeżania
FEATURE_IntraRefresh
w: MediaCodecInfo.CodecCapabilities
klasa, to:
- [C-3-1] MUSI obsługiwać okresy odświeżania w zakresie 10-60 klatek i poprawnie działać w zakresie 20% skonfigurowanego okresu odświeżania.
O ile aplikacja nie określi inaczej za pomocą parametru KEY_COLOR_FORMAT
klucz formatu, implementacje dekodera wideo:
- [C-4-1] MUSI mieć domyślny format kolorów zoptymalizowany pod kątem wyświetlacza sprzętowego jeśli skonfigurowano za pomocą danych wyjściowych Surface.
- [C-4-2] MUSI domyślnie mieć format kolorów YUV420 8:8:8 zoptymalizowany pod kątem procesora odczytuje, jeśli skonfigurowano nieużywanie danych wyjściowych z Surface.
5.1.8 Lista kodeków wideo
Format/kodek | Szczegóły | Obsługiwane typy plików i kontenerów |
---|---|---|
H.263 |
|
|
H.264 AVC | Zapoznaj się z sekcją 5.2 i 5.3 Więcej informacji |
|
H.265 HEVC | Więcej informacji znajdziesz w sekcji 5.3. |
|
MPEG-2 | Profil główny |
|
MPEG-4 SP |
|
|
VP8 | Zapoznaj się z sekcją 5.2 i 5.3 Więcej informacji |
|
VP9 | Więcej informacji znajdziesz w sekcji 5.3. |
|
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 |
|
|
|
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.
czy implementacje urządzeń obsługują którekolwiek z formatów 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.
- POWINNY jest obsługiwać profil główny 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 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 |
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. Wsparcie 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ć identyfikator ścieżki kompatybilnych wstecznie warstw bazowych (jeśli występują) tak, aby były takie same połączony identyfikator ścieżki warstwy Dolby Vision.
5.3.9 AV1
Jeśli implementacje urządzeń obsługują kodek AV1:
- [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 dowolny otwarty strumień INPUT
AudioRecord
lubAAudio
. Muszą być spełnione przynajmniej te warunki:- Format: linearny PCM, 16-bitowy
- Częstotliwość próbkowania: 8000, 11025, 16 000, 44 100, 48 000 Hz
- Kanały: mono
- Źródła dźwięku:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
VOICE_COMMUNICATION
UNPROCESSED
lubVOICE_PERFORMANCE
. Dotyczy to również równoważnych gotowych ustawień wejściowych w trybieAAudio
: na przykładAAUDIO_INPUT_PRESET_CAMCORDER
.
POWINNY jest zezwalać na przechwytywanie nieprzetworzonej treści audio za pomocą: cechy:
- Format: liniowy PCM, 16- i 24-bitowy
- Częstotliwość próbkowania: 8000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100, 48000 Hz
- Kanały: tyle kanałów, ile wynosi liczba mikrofonów na ekranie urządzenie
[C-1-2] MUSI przechwytywać z większą częstotliwością próbkowania bez próbkowania w górę.
[C-1-3] MUSI zawierać odpowiedni filtr antyaliasing, gdy podane powyżej współczynniki próbkowania są ujęte w próbkowaniu w dół.
NALEŻY zezwolić na przechwytywanie nieprzetworzonych treści audio w jakości radia AM i DVD, oznacza następujące cechy:
- Format: linearny PCM, 16-bitowy
- Częstotliwość próbkowania: 22 050, 48 000 Hz
- Kanały: stereo
[C-1-4] MUSI spełniać warunki interfejsu API
MicrophoneInfo
i uzupełnij informacje o mikrofony dostępne na urządzeniu. mogą być również dostępne dla aplikacji innych firm za pomocąAudioManager.getMicrophones()
API na potrzeby aktywnego rekordu AudioRecord przy użyciuMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
lubVOICE_PERFORMANCE
.
czy implementacje urządzeń zezwalają na przechwytywanie surowego dźwięku w jakości radia AM i DVD. treści, to:
- [C-2-1] MUSI przechwytywać bez próbkowania w górę przy współczynniku wyższego niż 16000:22050 lub 44100:48000.
- [C-2-2] W celu zwiększenia próbkowania MUSI dodać odpowiedni filtr antyaliasingowy. lub zmniejszanie.
5.4.2 Zrób zdjęcie, by włączyć rozpoznawanie głosu
Jeśli implementacje urządzenia zadeklarują android.hardware.microphone
:
- [C-1-1] MUSI przechwytywać
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
źródło dźwięku: jedną z częstotliwości próbkowania – 44100 lub 48 000. - [C-1-2] Domyślnie MUSI wyłączyć przetwarzanie dźwięku z redukcją szumów, gdy
nagrywam strumień audio z dźwięku
AudioSource.VOICE_RECOGNITION
źródła. [C-1-3] Domyślnie MUSI wyłączyć automatyczną kontrolę wzmocnienia podczas nagrywania. strumień audio ze źródła dźwięku
AudioSource.VOICE_RECOGNITION
.POWINNA wykazywać w przybliżeniu płaską amplitudę w porównaniu do częstotliwości. w średnim zakresie częstotliwości: ±3 dB od 100 Hz do 4000 Hz dla każdego a każdy mikrofon użyty do nagrywania źródła dźwięku rozpoznawania głosu.
Zdecydowanie ZALECANE jest działanie amplitudy na poziomie niskiego tętna [C-SR-1] zakres częstotliwości: zwłaszcza od ±20 dB od 30 Hz do 100 Hz w porównaniu średni zakres częstotliwości dla każdego mikrofonu użytego do nagrywania głosu rozpoznawania dźwięku.
Zdecydowanie ZALECANE jest działanie na poziomie amplitudy wysokich zakres częstotliwości: zwłaszcza od ±30 dB od 4000 Hz do 22 kHz w porównaniu z średni zakres częstotliwości dla każdego mikrofonu użytego do nagrania głosu, rozpoznawania dźwięku.
NALEŻY ustawić czułość wejścia dźwięku w taki sposób, aby źródło sygnału sinusoidalnego 1000 Hz było odtwarzane przy poziomie ciśnienia akustycznego 90 dB (SPL) (mierzonego obok mikrofonu) daje idealną odpowiedź RMS 2500 w zakresie od 1770 do 3530 dla 16 próbek bitów (lub -22,35 dB ±3 dB pełnej skali dla zmiennoprzecinkowego/podwójnej precyzji próbek) dla każdego mikrofonu używanego do nagrywania rozpoznawania głosu źródła dźwięku.
MUSI nagrać strumień audio rozpoznawania głosu tak, aby amplituda PCM poziomy liniowo śledzą zmiany poziomu SPL wejściowego w zakresie co najmniej 30 dB od -18 Od dB do +12 dB re 90 dB SPL do mikrofonu.
NAGRYWAJ strumień audio rozpoznawania głosu z całkowitą harmonią zniekształcenia (THD) poniżej 1% dla 1 kHz przy 90 dB SPL na poziomie sygnału wejściowego mikrofon.
Jeśli implementacje urządzeń zadeklarują android.hardware.microphone
i szum
technologii ukrywania (redukcji) dostosowanych pod kątem rozpoznawania mowy:
- [C-2-1] MUSI umożliwiać sterowanie tym efektem dźwiękowym za pomocą
Interfejs API
android.media.audiofx.NoiseSuppressor
. - [C-2-2] MUSI jednoznacznie identyfikować każdą technologię eliminowania szumów
za pomocą pola
AudioEffect.Descriptor.uuid
.
5.4.3 Zrób zdjęcie, aby zmienić trasę odtwarzania
Klasa android.media.MediaRecorder.AudioSource
zawiera REMOTE_SUBMIX
źródła dźwięku.
Jeśli implementacje urządzeń zadeklarują zarówno android.hardware.audio.output
, jak i
android.hardware.microphone
, to:
[C-1-1] MUSI prawidłowo zaimplementować źródło dźwięku
REMOTE_SUBMIX
, tak by gdy aplikacja używa interfejsu APIandroid.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ą dowolnegoAudioSource
. - [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óczAudioSource.VOICE_COMMUNICATION
lubAudioSource.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
lubAudioSource.CAMCORDER
. Jednak gdy aplikacja przechwytuje za pomocą polaAudioSource.VOICE_COMMUNICATION
, a następnie innej aplikacji może zarejestrować połączenie głosowe, jeśli jest to uprzywilejowana (wstępnie zainstalowana) aplikacja z uprawnienieCAPTURE_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 [przeniesione do wersji 5.4.2]
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 implementacjiEFFECT_TYPE_LOUDNESS_ENHANCER
, które można kontrolować za pomocą Podklasy AudioEffectEqualizer
iLoudnessEnhancer
. - [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 AudioEffectDynamicsProcessing
. - POTRZEBA obsługiwać:
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
, Implementacje za pomocą narzędziEFFECT_TYPE_PRESET_REVERB
iEFFECT_TYPE_VIRTUALIZER
można kontrolować za pomocą podklasAudioEffect
BassBoost
,EnvironmentalReverb
,PresetReverb
iVirtualizer
. - [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
autor:
AudioAttributes
i użytkowania w samochodzie zgodnie z definicją publiczną w artykuleandroid.car.CarAudioManager
.
5.5.4 Odciążanie dźwięku
Jeśli implementacje urządzeń obsługują odciążanie odtwarzania dźwięku:
- [C-SR-1] Zdecydowanie ZALECANE są przycinanie odtwarzanych treści audio bez przerw między dwoma klipami o tym samym formacie, gdy tag Interfejs API AudioTrack bez przerw i kontenera multimediów.
5.6. Opóźnienie dźwięku
Opóźnienie dźwięku to czas, w którym sygnał audio przechodzi przez system. Wiele klas aplikacji korzysta z krótkich opóźnień, co pozwala uzyskać efekty dźwiękowe.
Na potrzeby tej sekcji należy stosować następujące definicje:
- opóźnienia wyjścia. Odstęp czasu, jaki upływa od momentu, gdy aplikacja zapisuje ramkę danych kodowanych w PCM i gdy odpowiedni dźwięk jest prezentowany w przetworniku urządzenia lub sygnał opuszcza urządzenie i można go obserwować zewnętrznie.
- opóźnienia „na zimno”. Czas między uruchomieniem strumienia wyjściowego a rozpoczęciem czas prezentacji pierwszej klatki na podstawie sygnatur czasowych, gdy wyjście audio system został bezczynny i wyłączony przed wykonaniem żądania.
- ciągły czas oczekiwania na sygnał wyjściowy. opóźnienie wyjściowe kolejnych klatek, gdy urządzenie zacznie odtwarzać dźwięk.
- opóźnienia sygnału wejściowego. Odstęp czasu pomiędzy momentem wyświetlenia dźwięku przez z urządzenia na przetworniku urządzenia lub sygnał trafia do urządzenia przez 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.
- 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 wyjściowe „na zimno”: 500 milisekund .
[C-1-3] Otwieranie strumienia wyjściowego za pomocą dodatku
AAudioStreamBuilder_openStream()
MUSI trwa mniej niż 1000 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.
[C-SR-2] Opóźnienie reakcji na dotknięcie: maksymalnie 80 milisekund.
[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
odAAudioStream_getPerformanceMode()
, wartość zwrócona przezAAudioStream_getFramesPerBurst()
jest mniejsza od wartości zwróconej przezandroid.media.AudioManager.getProperty(String)
lub jej równa dla klucza właściwościAudioManager.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 danych wejściowych „na zimno”: 500 milisekund .
[C-3-3] Otwieranie strumienia wejściowego za pomocą funkcji
AAudioStreamBuilder_openStream()
MUSI trwa mniej niż 1000 milisekund.
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.
[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:
i MPEG-2. Kodeki audio:
|
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 sekcji 5.6 Opóźnienie dźwięku 25 milisekund lub mniej niż co najmniej 1 obsługiwaną ścieżkę.
- [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 oraz
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [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-1-8] MUSI mieć średni czas oczekiwania przy dotknięciu tonem wynoszący 80 milisekund lub mniej. z co najmniej 5 pomiarów w ramach ścieżki danych między głośnikiem a mikrofonem.
- [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ć w aplikacji SynthMark na Androida. SynthMark wykorzystuje syntezator programowy na symulowanej platformie audio. który mierzy wydajność systemu. Zobacz DokumentacjaSynthMark , gdzie znajdziesz wyjaśnienie wyników testów porównawczych. The SynthMark aplikacja musi być uruchamiana za pomocą „Test automatyczny” i osiągnij te wyniki:
- voicemark.90 >= 32 głosy
- czas oczekiwania.fixed.little <= 15 ms
- opóźnieniemark.dynamic.little <= 50 ms
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).
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 za pomocą klucza sprzętowego do odtwarzania dźwięku w pętli.
- [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ą
Źródło dźwięku: android.media.MediaRecorder.AudioSource.UNPROCESSED
. W
OpenSL ES, dostęp do niego można uzyskać za pomocą gotowego ustawienia rekordu
SL_ANDROID_RECORDING_PRESET_UNPROCESSED
Jeśli implementacja urządzenia ma obsługiwać nieprzetworzone źródło dźwięku i sprawia, aplikacji innych firm, mogą:
[C-1-1] MUSI zgłosić pomoc na stronie
android.media.AudioManager
właściwość PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.[C-1-2] MUSI wykazywać w przybliżeniu płaską amplitudę w porównaniu do częstotliwości. charakterystyki średniej częstotliwości: ±10 dB od 100 Hz–7000 Hz dla każdego mikrofonu użytego do nagrywania nieprzetworzonej źródła dźwięku.
[C-1-3] MUSI wykazywać poziomy amplitudy przy niskiej częstotliwości zakres: konkretnie od ±20 dB od 5 z do 100 Hz w porównaniu średniego zakresu częstotliwości dla każdego mikrofonu użytego do nagrywania nieprzetworzone źródło dźwięku.
[C-1-4] MUSI mieć poziom amplitudy w wysokiej częstotliwości zakres: konkretnie od ±30 dB od 7000 Hz do 22 kHz w porównaniu średniego zakresu częstotliwości dla każdego mikrofonu użytego do nagrywania nieprzetworzone źródło dźwięku.
[C-1-5] MUSI ustawić czułość wejścia audio na sinusoidalną 1000 Hz źródło tonu odtwarzanego przy poziomie ciśnienia akustycznego 94 dB (SPL) zwraca odpowiedź z Wartość RMS 520 dla próbek 16-bitowych (lub -36 dB w pełnej skali dla zmiennoprzecinkowego/podwójnej wartości próbek precyzji) dla każdego mikrofonu użytego do rejestracji nieprzetworzonej źródła dźwięku.
[C-1-6] MUSI mieć współczynnik sygnału do szumu (SNR) na poziomie 60 dB lub wyższym każdego mikrofonu użytego do nagrywania nieprzetworzonego źródła dźwięku. (na przykład 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 poziomu 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
zaAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
API, aby odpowiednio wskazywać brak wsparcia. - [C-SR-1] są nadal Zdecydowanie ZALECANE, jeśli chodzi o spełnienie jak największej liczby wymagań. dla ścieżki sygnału nieprzetworzonego źródła nagrania.
5.12. Film HDR
Android 13 obsługuje technologie HDR zgodnie z opisem w kolejnym dokumencie.
Format piksela
Jeśli dekoder wideo reklamuje obsługę formatu color_FormatYUVP010, to:
[C-1-1] MUSI obsługiwać format P010 w przypadku odczytu z procesora (ImageReader, MediaImage, ByteBuffer). W Androidzie 13 sygnał P010 jest zrelaksowany, aby umożliwić dowolny krok dla osi Y i płaszczyzn UV.
[C-1-2] Bufor wyjściowy P010 MUSI być dostępny do próbkowania przez GPU (gdy przydzielone z wykorzystaniem GPU_SAMPLING). Umożliwia to komponowanie za pomocą GPU oraz mapowania tonalnego w aplikacjach.
Jeśli dekoder wideo reklamuje obsługę formatu color_Format32bitABGR2101010, oznacza to, że:
- [C-2-1] MUSI obsługiwać format RGBA_1010102 w przypadku powierzchni wyjściowej i Czytelny dla procesora (dane wyjściowe ByteBuffer).
Jeśli koder wideo reklamuje obsługę formatu color_FormatYUVP010, to:
- [C-3-1] MUSI obsługiwać format P010 w przypadku platformy wejściowej i procesora z możliwością zapisu (ImageWriter, MediaImage, ByteBuffer).
Jeśli koder wideo reklamuje obsługę formatu color_Format32bitABGR2101010, oznacza to, że:
- [C-4-1] MUSI obsługiwać format RGBA_1010102 w przypadku powierzchni wejściowej i procesora z możliwością zapisu (ImageWriter, ByteBuffer). Uwaga: konwertowanie między różnymi opcjami przenoszenia krzywe NIE są wymagane dla koderów.
Wymagania dotyczące robienia zdjęć HDR
W przypadku wszystkich koderów wideo, które obsługują profile HDR, implementacje urządzeń:
[C-5-1] NIE MOŻE zakładać, że metadane HDR są dokładne. Na przykład parametr zakodowana klatka może zawierać piksele powyżej szczytowego poziomu luminancji lub histogram może nie być reprezentatywny dla klatki.
NALEŻY agregować dynamiczne metadane HDR, aby wygenerować odpowiedni statyczny obraz HDR dla zakodowanych strumieni i powinny przesyłać je na końcu każdego i sesji kodowania.
Jeśli implementacje urządzeń obsługują robienie zdjęć HDR przy użyciu interfejsów API CamcorderProfile to:
[C-6-1] MUSI też obsługiwać robienie zdjęć HDR za pomocą interfejsów API Camera2.
[C-6-2] MUSI obsługiwać co najmniej jeden koder wideo z akceleracją sprzętową do w każdej obsługiwanej technologii HDR.
[C-6-3] MUSI obsługiwać (co najmniej) przechwytywanie HLG.
[C-6-4] MUSI obsługiwać zapisywanie metadanych HDR (jeśli są dostępne w przypadku technologii) do przechwyconego pliku wideo. Formaty AV1, HEVC i DolbyVision oznacza to dołączenie metadanych do zakodowanego strumienia bitowego.
[C-6-5] MUSI obsługiwać parametry P010 i color_FormatYUVP010.
[C-6-6] MUSI domyślnie obsługiwać mapowanie tonów z HDR na SDR wspomagany sprzętowo dekoder dla przechwyconego profilu. Innymi słowy, Jeśli urządzenie może rejestrować technologię HDR10+ HEVC, domyślny dekoder HEVC MUSI mieć taką możliwość który pozwala zdekodować przechwycony strumień w SDR.
Wymagania dotyczące edycji HDR
Jeśli implementacje urządzeń obejmują kodery wideo obsługujące edycję HDR, one:
- Generowanie metadanych HDR powinno być minimalne, gdy jej brak, w sposób sprawny radzić sobie z sytuacjami, w których metadane niektórych i nie u innych. Metadane te POWINNY być dokładne (np. reprezentują rzeczywistą szczytową luminancję i histogram klatki).
Jeśli implementacja urządzenia obejmuje kodeki obsługujące FEATURE_HdrEditing, tych kodeków:
[C-7-1] MUSI obsługiwać co najmniej 1 profil HDR.
[C-7-2] MUSI obsługiwać edycję FEATURE_HdrEditing we wszystkich profilach HDR reklamowanych przez tego kodeka. Innymi słowy, MUSZĄ one obsługiwać generowanie metadanych HDR, gdy: nie występuje w przypadku wszystkich obsługiwanych profili HDR, które korzystają z metadanych HDR.
[C-7-3] MUSI obsługiwać poniższe formaty wejściowe kodera wideo, które w pełni zachowaj sygnał zdekodowany HDR:
- RGBA_1010102 (już na docelowej krzywej transferu) dla obu danych wejściowych i ByteBuffer oraz MUSI reklamować wsparcie color_Format32bitABGR2101010.
Jeśli implementacja urządzenia obejmuje kodeki obsługujące FEATURE_HdrEditing, urządzenie:
- [C-7-4] MUSI reklamować obsługę rozszerzenia OpenGL EXT_YUV_target.
6. Zgodność narzędzi i opcji dla programistów
6.1. Narzędzia dla programistów
Implementacje na urządzeniach:
- [C-0-1] MUSI obsługiwać narzędzia dla programistów aplikacji na Androida SDK.
-
- [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
orazStatsManager
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
- Zmieniono stan zadania
- 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 lub Ethernet:
- [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 lub Ethernet zawiera co najmniej 1 kamerę:
- [C-5-1] MUSI zawierać metodę
AdbManager#isAdbWifiQrSupported()
zwróćtrue
.
- [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
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.
-
- [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.
-
- [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.
- [C-SR-1] Zdecydowanie ZALECANE jest udostępnienie obiektu
Narzędzie do ograniczania braku pamięci
- [C-0-12] MUSI napisać
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom w log statystyczny po zamknięciu aplikacji przez mechanizm zarządzania pamięcią masową.
- [C-0-12] MUSI napisać
Tryb jarzma testowego Jeśli implementacje urządzeń obsługują polecenie powłoki
cmd testharness
i uruchomionocmd testharness enable
,- [C-2-1] MUSI zwrócić
true
zaActivityManager.isRunningInUserTestHarness()
- [C-2-2] MUSI wdrożyć tryb jarzma testowego zgodnie z opisem w Dokumentacja trybu jarzma testowego.
- [C-2-1] MUSI zwrócić
Informacje o pracy GPU
Implementacje na urządzeniach:
- [C-0-13] Aby wyświetlić, TRZEBA zaimplementować polecenie powłoki
dumpsys gpu --gpuwork
zagregowane dane robocze GPU zwracane przez jądropower/gpu_work_period
śledzenia lub nie wyświetlaj żadnych danych, jeśli ten punkt nie jest obsługiwany. AOSP implementacja jestframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] Aby wyświetlić, TRZEBA zaimplementować polecenie powłoki
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.
- MOGĄ 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()
orazhasSystemFeature(String)
metody na android.content.pm.PackageManager dla tego samego odcisku cyfrowego kompilacji.
Typowym przykładem sytuacji, w której obowiązują te wymagania, jest połączenie telefoniczne API: te interfejsy API należy wdrożyć w rozsądny sposób nawet na urządzeniach innych niż telefony nie działa.
7.1. Wyświetlacz i grafika
Android obejmuje elementy, które automatycznie dostosowują komponenty i interfejs aplikacji układy graficzne treści w taki sposób, aby aplikacje innych firm 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 rozmiarsmall
dlaConfiguration.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.
- Urządzenia, dla których parametr
[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 proporcjiUI_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.
- Aplikacja zadeklarowała, że obsługuje większy format ekranu
przez
[C-0-3] Implementacje na urządzeniach z wartością
Configuration.uiMode
ustawioną jakoUI_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 APIDENSITY_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ślnejview.Display
.
7.1.3 Orientacja ekranu
Implementacje na urządzeniach:
- [C-0-1] MUSI podawać obsługiwane orientacje ekranu
(
android.hardware.screen.portrait
lubandroid.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Ć raportandroid.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-main-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
iEGL_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
iOES_EGL_image_external
rozszerzenia. - WYMAGANE jest precyzyjne raportowanie za pomocą metody
getString()
, dowolna tekstura obsługiwanego przez nich formatu kompresji, który jest zwykle zależny od dostawcy. - POWINNA obsługiwać
EGL_IMG_context_priority
iEGL_EXT_protected_content
rozszerzenia.
Jeśli implementacje urządzeń zadeklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2:
- [C-3-1] MUSI wyeksportować odpowiednie symbole funkcji dla tych wersji w z symbolami funkcji OpenGL ES 2.0 w bibliotece libGLESv2.so.
- [C-SR-3] Zdecydowanie ZALECANE jest działanie funkcji
OES_EGL_image_external_essl3
.
Jeśli implementacje urządzeń obsługują OpenGL ES 3.2:
- [C-4-1] MUSI obsługiwać w całości pakiet rozszerzeń OpenGL ES na Androida.
Jeśli implementacje urządzeń obsługują pakiet rozszerzeń OpenGL ES całość, to znaczy, że:
- [C-5-1] MUSI określić pomoc na
android.hardware.opengles.aep
flagę funkcji.
Jeśli implementacje urządzeń zapewniają obsługę EGL_KHR_mutable_render_buffer
to:
- [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.3.
- [C-4-1] NIE MOŻE obsługiwać wersji interfejsu Vulkan (tj. wariantu) części podstawowej interfejsu Vulkan MUSI mieć wartość zero).
Jeśli implementacje urządzeń obejmują wyjście ekranu lub wideo:
- [C-SR-2] Zdecydowanie ZALECANE jest włączenie obsługi Vulkan 1.3.
Testy Vulkan dEQP są podzielone na kilka list testowych, z których każda zawiera parametr
powiązanej daty/wersji. Znajdziesz je w drzewie źródłowym Androida na stronie
external/deqp/android/cts/main/vk-main-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
iandroid.hardware.vulkan.version
flag funkcji. - [C-1-2] MUSI wyliczyć co najmniej jeden element
VkPhysicalDevice
dla interfejsu Vulkan natywny interfejs APIvkEnumeratePhysicalDevices()
, - [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 VulkanvkEnumerateInstanceLayerProperties()
ivkEnumerateDeviceLayerProperties()
, - [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 jakotrue
. - [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 funkcjiandroid.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 funkcjiandroid.software.vulkan.deqp.level
. - [C-1-11] NIE MOŻE liczyć wsparcia dla VK_KHR_video_queue, VK_KHR_video_decode_queue lub VK_KHR_video_encode_queue.
- [C-SR-3] Zdecydowanie ZALECANE jest działanie funkcji
VK_KHR_driver_properties
iVK_GOOGLE_display_timing
rozszerzenia. - POWINNO obsługiwać atrybuty
VkPhysicalDeviceProtectedMemoryFeatures
iVK_EXT_global_priority
- [C-1-12] NIE MOŻE wyszczególniać obsługi rozszerzenia VK_KHR_performance_query.
- [C-SR-4] Zdecydowanie ZALECANE jest spełnić wymagania określone przez profilowi Androida Baseline 2021.
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 VulkanvkEnumeratePhysicalDevices()
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 rozszerzenieVK_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
, iEGL_EXT_gl_colorspace_display_p3_passthrough
rozszerzeń. - [C-SR-1] Zdecydowanie ZALECANE jest działanie funkcji
GL_EXT_sRGB
.
Jeśli 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. odpowiednia 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 parametramiACTION=MAIN
iCATEGORY=LAUNCHER
lubCATEGORY=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órekolwiek z nich jest dostępne.
- [C-1-2] MUSI wyraźnie wskazywać, które działanie może wywołać działanie. dla każdej funkcji. z nadrukowaną ikoną na przycisku oraz informacją o oprogramowaniu; znajdującą się na pasku nawigacyjnym albo prowadząc użytkownika przez szczegółowe instrukcje konfigurowania podczas konfiguracji na przykłady tego typu wskazania.
Implementacje na urządzeniach:
Zdecydowanie ZALECANE jest nieudostępnianie mechanizmu wprowadzania danych dla funkcji Funkcja menu ponieważ w Androidzie 4.0 został wycofany pasek działań.
[C-SR-2] Zdecydowanie zaleca się zapewnić wszystkie funkcje nawigacyjne nie można anulować. „Można anulować” jest zdolność użytkownika do zapobiegania nie zostanie wykonana funkcja nawigacji (np. powrót do domu, powrót do domu itp.), jeśli funkcja nie udaje się przekroczyć określonego progu.
Jeśli implementacje urządzeń zapewniają funkcję menu, są to:
- [C-2-1] MUSI wyświetlać dodatkowy przycisk działania, gdy działanie nie jest puste, a pasek działań jest widoczny.
- [C-2-2] NIE MOŻE zmieniać pozycji wyskakującego okienka rozszerzonego działania wyświetlane po kliknięciu przycisku rozszerzonego na pasku działań, ale MOGĄ wyskakujące okienko działania w zmodyfikowanym położeniu na ekranie, gdy jest można wyświetlić po wybraniu funkcji menu.
Jeśli implementacje urządzeń nie udostępniają funkcji menu, w przypadku instrukcji wstecznych
zgodność ze standardami:
* [C-3-1] MUSI udostępnić funkcję Menu aplikacjom, gdy
Wartość targetSdkVersion
jest mniejsza niż 10 (przy użyciu fizycznego przycisku, klucza oprogramowania)
lub gestami. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z
z innych funkcji nawigacji.
Jeśli implementacje na urządzeniach udostępniają funkcję wspomagania, one:
- [C-4-1] MUSI udostępnić funkcję wspomagania jednym działaniem. (np. klikając, dwukrotnie lub przy użyciu gestów), gdy dostępne są inne klawisze nawigacyjne.
- [C-SR-3] Zdecydowanie zalecamy przytrzymanie funkcji ekranu głównego, ponieważ wyznaczonej interakcji.
Jeśli implementacje urządzeń wykorzystują osobną część ekranu do wyświetlania klawisze nawigacyjne:
- [C-5-1] Klawisze nawigacyjne MUSZĄ zajmować osobną część ekranu, nie i NIE MOŻE zasłaniać ani w inny sposób zakłócać fragmentu ekranu dostępnego dla aplikacji.
- [C-5-2] MUSI udostępniać część wyświetlacza aplikacjom, spełnia wymagania określone w sekcji 7.1.1.
- [C-5-3] MUSI uwzględniać flagi ustawione przez aplikację w
View.setSystemUiVisibility()
. API, aby ta charakterystyczna część ekranu (inaczej pasek nawigacyjny) jest poprawnie ukryty, jak opisano w pakietu SDK.
Jeśli funkcja nawigacji jest udostępniana na ekranie za pomocą gestów:
- [K-6–1]
WindowInsets#getMandatorySystemGestureInsets()
MOŻNA używać tylko do zgłaszania obszaru rozpoznawania gestów na ekranie głównym. - [C-6-2] Gesty zaczynające się w polu prostokątnym wskazywanym przez
aplikacji działających na pierwszym planie za pośrednictwem
View#setSystemGestureExclusionRects()
ale pozaWindowInsets#getMandatorySystemGestureInsets()
, NIE MOŻE być przechwytywane dla funkcji nawigacji, jeśli wykluczenie jest dozwolony w ramach maksymalnego limitu wykluczeń określonego w dokumentacja dlaView#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łanaMotionEvent.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 przezView#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 View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub Ustawiono flagi WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SSTORAGE, przesunięcie od krawędzi MUSI działać tak samo jak w AOSP, o treściach udokumentowanych w pakiecie SDK.
- [C-7-4] Gdy aplikacja na pierwszym planie ma parametr View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub Ustawiono flagi WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SSTORAGE, niestandardowe, przesuwane panele systemowe MUSZĄ być ukryte do czasu, aż użytkownik wejdzie Usuwa przyciemnienie pasków systemowych (tzw. nawigacji i paska stanu) po zaimplementowaniu w AOSP.
Jeśli dostępna jest funkcja przechodzenia wstecz, a użytkownik anuluje gestu, a następnie:
- [C-8-1] Trzeba zadzwonić do użytkownika
OnBackInvokedCallback.onBackCancelled()
. - [C-8-2] NIE NALEŻY wywoływać funkcji
OnBackInvokedCallback.onBackInvoked()
. - [C-8-3] Zdarzenie KEYCODE_BACK NIE MOŻE być wysyłane.
Jeśli podana jest funkcja przechodzenia wstecz, ale aplikacja na pierwszym planie ją
NIE masz zarejestrowanego konta OnBackInvokedCallback
, to wtedy:
- System powinien udostępnić animację na pierwszym planie, która sugeruje, że użytkownik wraca, zgodnie z AOSP.
Jeśli implementacje urządzeń zapewniają obsługę systemowego interfejsu API setNavBarMode
do
zezwól dowolnej aplikacji systemowej z uprawnieniami android.permission.STATUS_BAR
na ustawianie
trybu paska nawigacyjnego, a następnie:
- [C-9-1] MUSI obsługiwać ikony przyjazne dzieciom lub wykorzystujące przyciski nawigacji zgodnie z kodem AOSP.
7.2.4 Wprowadzanie tekstu z ekranu dotykowego
Android zapewnia obsługę różnych systemów wprowadzania danych wskaźnikach, takich jak ekrany dotykowe, pady dotykowe i imitacje dotykowych urządzeń wejściowych. Implementacje na urządzeniach z ekranem dotykowym są powiązane z reklamą displayową, tak aby użytkownik miał wrażenie, do manipulowania elementami na ekranie. Użytkownik dotyka bezpośrednio ekranu, system nie wymaga żadnych dodatkowych afordancji wskazujących obiekty być manipulowany.
Implementacje na urządzeniach:
- POWINNY jest mieć jakiś system wprowadzania danych z użyciem wskaźników (jak mysz lub dotyk).
- POWINNA obsługiwać w pełni niezależnie śledzone wskaźniki.
Jeśli urządzenia są wyposażone w ekran dotykowy (pojedynczy dotyk lub lepszy) głównych wyświetlaczy zgodnych z Androidem:
- [C-1-1] MUSI zgłosić
TOUCHSCREEN_FINGER
zaConfiguration.touchscreen
API. - [C-1-2] MUSI zgłosić
android.hardware.touchscreen
iandroid.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 dotknię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
zaConfiguration.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.
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 |
7.2.7 Pilot
Wymagania związane z poszczególnymi urządzeniami znajdziesz w artykule 2.3.1.
7.3. Czujniki
Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma API dla programistów zewnętrznych, implementacja urządzeń MUSI zaimplementować ten interfejs API w sposób opisany w dokumentacji pakietu Android SDK i znajdziesz w dokumentacji Androida open source poświęconej czujnikom.
Implementacje na urządzeniach:
- [C-0-1] MUSI dokładnie zgłaszać obecność lub brak czujników zgodnie z
android.content.pm.PackageManager
zajęcia. - [C-0-2] MUSI zwracać dokładną listę obsługiwanych czujników przez
SensorManager.getSensorList()
i podobne metody. - [C-0-3] MUSI działać w rozsądny sposób w przypadku wszystkich innych interfejsów API czujników (na przykład
zwracanie odpowiednio
true
lubfalse
, 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ą akcelerometr:
- [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
- [C-1-3] MUSI być zgodny z Układ współrzędnych czujnika Androida jak opisano w interfejsach API Androida.
- [C-1-4] MUSI być w stanie mierzyć od swobodnego spadania do czterech razy większej 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.
- 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 implementacje urządzeń obejmują 3-osiowy akcelerometr:
- [C-2-1] MUSI zaimplementować i zgłosić czujnik
TYPE_ACCELEROMETER
. - [C-SR-4] Zdecydowanie ZALECANE jest wdrożenie
TYPE_SIGNIFICANT_MOTION
czujnika kompozytu. - [C-SR-5] Zdecydowanie ZALECANE są wdrożenie i raportowanie
Czujnik
TYPE_ACCELEROMETER_UNCALIBRATED
. Urządzenia z Androidem są ZDECYDOWANIE ZALECANE, aby spełnić to wymaganie i zyskać możliwość przejścia na w przyszłej wersji platformy, w której może to stać się WYMAGANE. - NALEŻY zaimplementować
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
TYPE_STEP_COUNTER
czujniki złożone zgodnie z opisem w dokumentacji pakietu Android SDK.
Jeśli implementacje urządzeń obejmują akcelerometr z mniej niż 3 osiami:
- [C-3-1] MUSI zaimplementować i zgłosić czujnik
TYPE_ACCELEROMETER_LIMITED_AXES
. - [C-SR-6] Są STRONGLY_ZALECANE do wdrożenia i raportowania
Czujnik
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Jeśli w urządzeniach jest 3-osiowy akcelerometr i dowolny
TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
Zaimplementowane czujniki złożone (TYPE_STEP_COUNTER
):
- [C-4-1] Suma ich 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-5-1] MUSI zaimplementować
czujniki złożone
TYPE_GRAVITY
iTYPE_LINEAR_ACCELERATION
. - [C-SR-7] 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-6-1] NALEŻY zastosować czujnik kompozytowy
TYPE_ROTATION_VECTOR
.
7.3.2 Magnetometr
Implementacje na urządzeniach:
- [C-SR-1] Zdecydowanie ZALECANE jest użycie 3-osiowego magnetometru (kompasu).
Jeśli urządzenia są wyposażone w 3-osiowy magnetometr:
- [C-1-1] MUSI zamocować czujnik
TYPE_MAGNETIC_FIELD
. - [C-1-2] MUSI raportować zdarzenia z częstotliwością co najmniej 10 Hz i POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 50 Hz.
- [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Android. jak podano w Interfejsy API dla Androida.
- [C-1-4] MUSI mierzyć od -900 μT do +900 μT w każdym przed nasyceniem.
- [C-1-5] MUSI mieć wartość przesunięcia twardego żelaza mniejszą niż 700 μT i POWINNA poniżej 200 μT, umieszczając magnetometr w odległości dynamicznych (wywołanych prądem) i statycznych (wywoływanych magnesem) pól magnetycznych.
- [C-1-6] MUSI mieć rozdzielczość równą lub większą niż 0,6 μT.
- [C-1-7] MUSI obsługiwać kalibrację online i kompensację twardego żelaza i zachować parametry kompensacji między restartami urządzeń.
- [C-1-8] MUSI zastosować kompensację miękkiego żelaza – kalibrację można zarówno podczas użytkowania, jak i produkcji urządzenia.
- [C-1-9] MUSI mieć odchylenie standardowe obliczone na podstawie jednej osi próbki zebrane w okresie co najmniej 3 sekund z najszybszym próbkowaniem współczynnik klikalności, nie większy niż 1,5 μT; Odchylenie standardowe musi mieć wartość nie większą niż 0,5 μT.
- [C-1-10] MUSI zaimplementować
TYPE_MAGNETIC_FIELD_UNCALIBRATED
.
Jeśli urządzenia są wyposażone w 3-osiowy magnetometr, akcelerometr i 3-osiowy żyroskop:
- [C-2-1] MUSI zaimplementować czujnik kompozytowy
TYPE_ROTATION_VECTOR
.
Jeśli urządzenia są wyposażone w 3-osiowy magnetometr (akcelerometr):
- MOŻESZ zastosować czujnik
TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
Jeśli urządzenia są wyposażone w 3-osiowy magnetometr, akcelerometr i
Czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
- [C-3-1] MUSI zużywać mniej niż 10 mW.
- POWINNO zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie wsadowym 10 Hz.
7.3.3 GPS
Implementacje na urządzeniach:
- [C-SR-1] Zdecydowanie ZALECANE jest użycie odbiornika GPS/GNSS.
Jeśli implementacje urządzeń obejmują odbiornik GPS/GNSS i poinformują o możliwości
do aplikacji za pomocą flagi funkcji android.hardware.location.gps
, spowoduje to:
- [C-1-1] MUSI obsługiwać dane wyjściowe z lokalizacją z częstotliwością co najmniej 1 Hz, gdy
wysłano prośbę za pośrednictwem:
LocationManager#requestLocationUpdate
. - [C-1-2] MUSI określić lokalizację na otwartym niebie
(silne sygnały, pomijane ścieżki wielościeżkowe, HDOP < 2) w ciągu 10 sekund (szybkie)
czas do pierwszej naprawy), przy połączeniu z szybkością co najmniej 0,5 Mb/s.
i połączenia z internetem. Ten wymóg jest zwykle spełniany przez zastosowanie
forma metody wspomaganego lub przewidywanego GPS/GNSS.
do zminimalizowania czasu blokady GPS/GNSS (dane pomocy obejmują czas odniesienia,
Lokalizacja odniesienia i satelitarny efemeris/zegar).
- [C-1-6] Po wyliczeniu lokalizacji implementacje MUSZĄ określić swoją lokalizację, na otwartym niebie, w po 5 sekundach, jeśli żądania lokalizacji są ponownie uruchamiane, maksymalnie do godziny po tym czasie. początkowe obliczenie lokalizacji, nawet jeśli kolejne żądanie wykonane bez połączenia do transmisji danych lub po wyłączeniu i włączeniu zasilania.
Na otwartym niebie po określeniu lokalizacji, na siedzącym lub poruszając się z przyspieszeniem poniżej 1 metra na sekundę do kwadratu:
- [C-1-3] MUSI określić lokalizację w promieniu 20 metrów i prędkość z dokładnością do 0,5 metra na sekundę, przez co najmniej 95% czasu.
- [C-1-4] MUSI jednocześnie śledzić i raportować przez
GnssStatus.Callback
co najmniej 8 satelitów z 1 konstelacji. - Funkcja MUSI być w stanie jednocześnie śledzić co najmniej 24 satelity, od wiele konstelacji (np. GPS + przynajmniej jeden z Glonass, Beidou, Galileusza).
[C-SR-2] Zdecydowanie ZALECANE jest dalsze działanie systemu GPS/GNSS. dane o lokalizacji przesyłane za pomocą interfejsu API GNSS Location Provider API podczas połączenia alarmowego .
[C-SR-3] Zdecydowanie ZALECANE są raportowanie pomiarów GNSS we wszystkich śledzone konstelacje (zgodnie z raportem w komunikatach GnssStatus), z wyjątkiem przedsiębiorcy SBAS.
[C-SR-4] Zdecydowanie ZALECANE jest raportowanie AGC oraz częstotliwość GNSS pomiar skuteczności.
[C-SR-5] Zdecydowanie ZALECANE jest raportowanie wszystkich szacunków dokładności (w tym Orientacja, Prędkość i Orientacja pionowa) jako część każdej lokalizacji GPS/GNSS.
[C-SR-6] Zdecydowanie ZALECANE jest zgłaszanie pomiarów GNSS, gdy tylko nawet jeśli lokalizacja określona na podstawie GPS/GNSS nie została jeszcze zostało zgłoszone.
[C-SR-7] Zdecydowanie ZALECANE są zgłaszanie pseudozakresów GNSS i współczynniki pseudozakresów, które w warunkach na niebie po określeniu lokalizacji nieruchome lub poruszające się z szybkością mniejszą niż 0,2 metra na sekundę do kwadratu przyspieszenie, wystarczają do obliczenia pozycji z odległości do 20 metrów, a prędkość z dokładnością do 0,2 metra na sekundę, przez co najmniej 95% czasu.
7.3.4 Żyroskop
Implementacje na urządzeniach:
- [C-SR-1] Zdecydowanie ZALECANE jest użycie czujnika żyroskopu.
Jeśli urządzenia są wyposażone w żyroskop:
- [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
- Rozdzielczość [C-1-4] MUSI mieć co najmniej 12 bitów.
- [C-1-5] MUSI mieć kompensację temperatury.
- [C-1-6] MUSI być skalibrowany i skompensowany podczas używania. parametry kompensacji między restartami urządzenia.
- [C-1-7] MUSI mieć wariancję nie większą niż 1e-7 rad^2 / s^2 na Hz (wariancja na Hz, czyli rad^2 / s). Warianty mogą się różnić w zależności od ale MUSI być ograniczana przez tę wartość. Innymi słowy, zmierz wariancję żyroskopu przy częstotliwości próbkowania 1 Hz niż 1e-7 rad^2/s^2.
- [C-SR-2] ZALECANY jest błąd kalibracji mniejszy niż 0,01 rad/s gdy urządzenie pozostaje w temperaturze pokojowej.
- [C-SR-3] Zdecydowanie ZALECANE są rozdzielczość 16-bitowa lub większa.
- POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.
Jeśli urządzenia są wyposażone w 3-osiowy żyroskop:
- [C-2-1] MUSI zamocować czujnik
TYPE_GYROSCOPE
. - [C-SR-4] Zdecydowanie zalecamy wdrożenie
TYPE_GYROSCOPE_UNCALIBRATED
.
Jeśli implementacje urządzeń obejmują żyroskop z mniej niż 3 osiami:
- [C-3-1] MUSI zaimplementować i zgłosić czujnik
TYPE_GYROSCOPE_LIMITED_AXES
. - [C-SR-5] Są STRONGLY_ZALECANE do wdrożenia i raportowania
Czujnik
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Jeśli urządzenia są wyposażone w 3-osiowy żyroskop, i czujnik magnetometru:
- [C-4-1] MUSI zaimplementować czujnik kompozytowy
TYPE_ROTATION_VECTOR
.
Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr i 3-osiowy żyroskop, czujnika:
- [C-5-1] MUSI wdrożyć zasady
TYPE_GRAVITY
iTYPE_LINEAR_ACCELERATION
i komponentów. - [C-SR-6] Zdecydowanie ZALECANE jest wdrożenie
TYPE_GAME_ROTATION_VECTOR
czujnika kompozytu.
7.3.5 barometr;
Implementacje na urządzeniach:
- [C-SR-1] Zdecydowanie ZALECANE jest dodanie barometru (ciśnienia powietrza otoczenia) ).
Jeśli implementacje urządzeń obejmują barometr:
- [C-1-1] MUSI zaimplementować i zgłosić czujnik
TYPE_PRESSURE
. - [C-1-2] MUSI być w stanie przesyłać zdarzenia z częstotliwością 5 Hz lub większą.
- [C-1-3] MUSI mieć kompensację temperatury.
- [C-SR-2] Zdecydowanie zalecana jest możliwość raportowania pomiarów ciśnienia w zakres od 300 hPa do 1100 hPa.
- Całkowita dokładność 1hPa.
- POWINNA mieć względną dokładność 0,12 hPa w zakresie 20 hPa. (odpowiednik dokładności ok. 1 m na ok. 200 m zmiany na poziomie morza).
7.3.6 Thermometer
Jeśli urządzenia obejmują termometr otoczenia (czujnik temperatury): one:
- [C-1-1] MUSI definiować
SENSOR_TYPE_AMBIENT_TEMPERATURE
dla czujnika temperatury otoczenia, a czujnik MUSI mierzyć temperaturę otoczenia (w pomieszczeniu/kabinie pojazdu), od której użytkownik wchodzi w interakcję z urządzenia w stopniach Celsjusza.
Jeśli urządzenia są wyposażone w czujnik termometru, który mierzy temperatura inna niż temperatura otoczenia (np. temperatura procesora) powoduje, że:
- [C-2-1] NIE MOŻE definiować
SENSOR_TYPE_AMBIENT_TEMPERATURE
dla czujnika temperatury.
Jeśli urządzenia są wyposażone w czujnik do monitorowania temperatury skóry, to:
- [C-SR-1] Zdecydowanie ZALECANE są działania PowerManager.getThermalHeadroom API.
7.3.7 Fotometr
- Urządzenia MOGĄ zawierać fotometr (czujnik jasności otoczenia).
7.3.8 Czujnik zbliżeniowy
- Urządzenia MOGĄ zawierać czujnik zbliżeniowy.
Jeśli urządzenia są wyposażone w czujnik zbliżeniowy, który zgłasza tylko 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 ZALECANY, aby zakres pomiaru wynosił 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 poziomieTYPE_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 standardemTYPE_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 wTYPE_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
igetHighestDirectReportRateLevel
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.
- POWINNA obsługiwać raportowanie zdarzeń przez kanał bezpośredni czujnika dla głównego
czujnik (wariant wybudzenia) tych typów:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. Czujniki biometryczne
Więcej informacji na temat mierzenia zabezpieczeń odblokowywania biometrycznego: Dokumentacja zabezpieczeń biometrycznych
Jeśli implementacje urządzeń obejmują bezpieczny ekran blokady:
- POWINNA zawierać czujnik biometryczny
Czujniki biometryczne mogą należeć do klasy 3 (wcześniej Silne), Klasa 2 (wcześniej Słaba) lub Klasa 1 (wcześniej Wygodna) na podstawie wskaźników akceptacji za podszywanie się pod inne osoby oraz bezpieczeństwa biometrycznego potoku. Ta klasyfikacja określa możliwości czujnik biometryczny musi łączyć się z platformą oraz z zewnętrznym aplikacji. Czujniki muszą spełniać dodatkowe wymagania opisane poniżej, jeśli chce zostać sklasyfikowany jako klasa 1, klasa 2 lub klasa 3. Zarówno biometria klasy 2, jak i klasy 3 zyskują dodatkowe możliwości: podane niżej.
Jeśli implementacje urządzeń udostępniają czujnik biometryczny innym firmom aplikacji za pomocą android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, i android.provider.Settings.ACTION_BIOMETRIC_ENROLL, one:
- [C-4-1] MUSI spełniać wymagania dotyczące danych biometrycznych klasy 3 lub klasy 2 zgodnie z definicją podaną w tym dokumencie.
- [C-4-2] MUSI rozpoznawać i uwzględniać każdą nazwę parametru zdefiniowaną jako stałą na stronie Authenticators, i ich kombinacji. I na odwrót NIE MOŻE spełniać ani rozpoznawać stałych liczb całkowitych przekazywanych do funkcji canAuthenticate(int), i setAllowedAuthenticators(int) metod innych niż te opisane jako stałe publiczne Uwierzytelnianie oraz ich kombinacji.
- [C-4-3] MUSI obsługiwać funkcję ACTION_BIOMETRIC_ENROLL na urządzeniach z biometrią klasy 3 lub klasy 2. To działanie MUSI przedstawiać tylko punkty wejścia do rejestracji dla klasy 3. lub danych biometrycznych klasy 2.
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-11] MUSI mieć współczynnik akceptacji fałszywych informacji niż 30%. z (1) współczynnikiem akceptacji podszywania się pod inne osoby w prezentacji poziomu A gatunki instrumentów atakowych (PAI) nie większe niż 30%; oraz (2) imitacja współczynnik akceptacji oszustów na poziomie B PAI nie wyższy niż 40%, z użyciem protokołów biometrycznych Androida.
- [C-1-4] MUSI uniemożliwiać dodawanie nowych danych biometrycznych bez uprzedniego ustanowienia łańcuch zaufania – użytkownik może potwierdzić istniejące urządzenie lub dodać nowe. dane logowania (kod PIN/wzór/hasło) zabezpieczone przez TEE; Android Open Wdrożenie projektu źródłowego zapewnia mechanizm działania tak.
- [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
lubDevicePolicymanager.KEYGUARD_DISABLE_IRIS
). - [C-1-7] MUSI wymagać uwierzytelniania użytkownika za pomocą zalecanego podstawowego uwierzytelniania (np. kod PIN, wzór, hasło) co 24 godziny. Uwaga: uaktualnianie urządzeń z Androidem 9 lub starszym MUSI wymaganie od użytkownika wprowadzenia zalecanego podstawowego uwierzytelniania (np. kodu PIN, wzór, hasło) co 72 godziny.
- [C-1-8] MUSI wymagać od użytkownika pytania o zalecaną trasę podstawową
uwierzytelnianie (np. kod PIN, wzór, hasło) lub uwierzytelnianie biometryczne klasy 3 (STRONG)
po jednym z tych elementów:
- 4-godzinny limit czasu bezczynności LUB
- 3 nieudane próby uwierzytelnienia biometrycznego.
- Zresetowane są limity czasu bezczynności i liczba nieudanych uwierzytelniania po potwierdzeniu danych logowania urządzenia. Uwaga: uaktualnianie urządzeń z Androidem 9 lub starszym MOŻE zwolnione z opodatkowania w kategoriach C-1-8.
- [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%, z (1) współczynnikiem akceptacji podszywania się pod inne osoby w prezentacji poziomu A gatunki instrumentów atakujących (PAI) nie większe niż 20%; oraz (2) imitacja współczynnik akceptacji oszustów na temat gatunków PAI poziomu B nie wyższy niż 30%, mierzone przez Protokoły testów biometrycznych Androida.
[C-2-3] MUSI wykonać dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza Androidem użytkownika lub przestrzeni jądra systemu, 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 umożliwiać niezaszyfrowanego dostępu do danych biometrycznych możliwych do zidentyfikowania ani wszelkich danych uzyskanych z niej (takich jak wektory dystrybucyjne) do Podmiotu przetwarzającego aplikację poza kontekstem TEE. Uaktualnianie urządzeń z Androidem wersja 9 lub starsza 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. Uwaga: jeśli implementacje na urządzeniach zostały już wdrożone na urządzeniach z Androidem w wersji 9 lub wcześniej i nie może spełnić wymagań C-2-8 za pomocą oprogramowania systemowego aktualizacja, MOŻE być zwolniona z obowiązku spełnienia tego wymogu.
[C-SR-10] Zdecydowanie ZALECANE jest włączenie wykrywania żywotności w przypadku wszystkich modalności biometrycznej i wykrywania uwagi na potrzeby biometrii twarzy.
[C-2-9] MUSI udostępnić czujnik biometryczny innej firmy aplikacji.
Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 3. (dawniej Silne):
- [C-3-1] MUSI spełniać wszystkie wymagania klasy 2 powyżej oprócz [C-1-7] i [C-1-8].
- [C-3-2] MUSI mieć implementację magazynów kluczy wspieranych sprzętowo.
- [C-3-3] MUSI mieć współczynnik akceptacji imitacji nie wyższy niż 7%. z (1) współczynnikiem akceptacji fałszywych informacji dla gatunków instrumentów atakowych poziomu A (PAI) – nie więcej niż 7% gatunków; (2) współczynnik akceptacji imitacji przez oszustów lub innych gatunków pochodzących z PAI na poziomie B nie jest wyższy niż 20%, co mierzy Protokoły testów biometrycznych Androida.
- [C-3-4] MUSI wymagać od użytkownika pytania o zalecaną trasę podstawową uwierzytelnianie (np. kod PIN, wzór, hasło) 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.11. Czujnik pozycji
Implementacje na urządzeniach:
- MOŻE obsługiwać czujnik pozycji z 6 stopniami swobody.
Jeśli implementacje urządzeń obsługują czujnik pozycji z sześcioma stopniami swobody:
- [C-1-1] MUSI wdrożyć i zgłosić stronę
TYPE_POSE_6DOF
. - [C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.
7.3.12. Czujnik kąta nachylenia
Jeśli urządzenia obsługują czujnik kąta zawiasu:
- [C-1-1] MUSI wdrożyć i zgłosić stronę
TYPE_HINGLE_ANGLE
. - [C-1-2] MUSI obsługiwać co najmniej dwa odczyty od 0 do 360 stopni (włącznie, tzn.w tym od 0 do 360 stopni).
- [C-1-3] MUSI zwrócić wybudzenie
czujnik dla:
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.3.13. IEEE 802.1.15.4 [Przeniesiony do wersji 7.4.9]
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 zadeklarować
android.hardware.telephony.euicc
flagę funkcji.
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ć parametr
android.hardware.telephony.ims
flagę funkcji i zapewnić pełną implementację Interfejs ImsService API dla MMTEL i RCS User Capability Exchange API. - [C-5-2] MUSI zadeklarować 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.
Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.telephony
:
- [C-6-1]
SmsManager#sendTextMessage
iSmsManager#sendMultipartTextMessage
MUSI prowadzić do odpowiednich wywołańCarrierMessagingService
na potrzeby obsługi wiadomości tekstowych.SmsManager#sendMultimediaMessage
orazSmsManager#downloadMultimediaMessage
MUSI prowadzić do odpowiednich wywołańCarrierMessagingService
udostępniania funkcji wiadomości multimedialnych. - [C-6-2] Wniosek wskazany przez
android.provider.Telephony.Sms#getDefaultSmsPackage
MUSI używać SmsManager Interfejsy API do wysyłania i odbierania SMS-ów i MMS-ów. Dokumentacja AOSP wdrożenia w pakietach/aplikacjach/wiadomościach spełniają to wymaganie. - [C-6-3] Aplikacja, która odpowiada na
Intent#ACTION_DIAL
MUSI obsługiwać wpisywanie dowolnych kodów telefonu w formacie*#*#CODE#*#*
i aktywuje odpowiedniTelephonyManager#ACTION_SECRET_CODE
transmisję. - [C-6-4] Aplikacja odpowiadająca na
Intent#ACTION_DIAL
MUSI używaćVoicemailContract.Voicemails#TRANSCRIPTION
wyświetlanie użytkownikom transkrypcji wizualnej poczty głosowej, jeśli obsługuje ona zapisy tekstowe poczty głosowej. - [C-6-5] MUSI zawierać wszystkie elementy SubscriptionInfo wraz z ich odpowiednikiem
identyfikatory UUID grup
jako pojedynczą subskrypcję we wszystkich widocznych dla użytkowników aprobatach, które wyświetlają
kontrolować informacje na karcie SIM. Przykłady takich afordancji to m.in. ustawienia
które pasują do siebie
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
lubEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
- [C-6-6] NIE MOŻE wyświetlać informacji o subskrypcjach ani umożliwiać kontroli nad nimi za pomocą niepusty identyfikator UUID grupy i oportunistycznym widoczne dla użytkownika, umożliwiać konfigurowanie i kontrolowanie ustawień karty SIM.
Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.telephony
i wyświetl systemowy pasek stanu, a potem:
- [C-7-1] MUSI wybrać reprezentatywną aktywną subskrypcję dla danego identyfikator UUID grupy do wyświetlania użytkownikowi w dowolnej wersji, która zapewnia stan karty SIM i informacjami o nich. Przykładami takich afordancji jest pasek stanu komórkowy ikony sygnału lub kafelka szybkich ustawień.
- [C-SR-1] Zdecydowanie ZALECANE jest, aby reprezentatywna subskrypcja został wybrany na aktywna subskrypcja danych chyba że urządzenie ma włączony głos podczas której Zdecydowanie ZALECANE jest, aby przedstawiciel subskrypcja to subskrypcja aktywnej usługi Voice.
Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.telephony
:
- [C-6-7] MUSI być w stanie otwierać się w tym samym czasie liczba kanałów logicznych (łącznie 20) dla każdego interfejsu UICC według wytycznych ETSI TS 102 221.
- [C-6-8] NIE MOŻE wykonywać żadnych z poniższych działań w przypadku aktywnych aplikacji operatora
(zgodnie z wytycznymi podanymi przez:
TelephonyManager#getCarrierServicePackageName
) automatycznie lub bez wyraźnego potwierdzenia użytkownika:- Anuluj lub ogranicz dostęp do sieci
- Cofnij uprawnienia
- Ogranicz uruchamianie aplikacji w tle lub na pierwszym planie poza dotychczasowe funkcje zarządzania energią dostępne w AOSP
- Wyłączanie i odinstalowywanie aplikacji
Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.telephony
i
wszystkie aktywne,
subskrypcje nieoportunistyczne
które mają ten sam identyfikator UUID grupy,
fizycznie usunięte z urządzenia lub oznaczone jako oportunistyczne, wówczas urządzenie:
- [C-8-1] MUSI automatycznie wyłączyć wszystkie pozostałe elementy aktywne oportunistyczne subskrypcji w tej samej grupie.
Jeśli implementacje urządzeń obejmują usługę telefonii GSM, ale nie CDMA:
- [C-9-1] NIE MOŻE deklarować sekcji
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-9-2] MUSI rzucić
IllegalArgumentException
przy próbie ustawienia Typy sieci 3GPP2 w preferowanych lub dozwolonych maskach bitowych typu sieci. - [C-9-3] MUSI zwracać pusty ciąg z
TelephonyManager#getMeid
Jeśli implementacje urządzeń obsługują eUICC z wieloma portami i profilami, to:
- [C-10-1] MUSI zadeklarować
android.hardware.telephony.euicc.mep
flagę funkcji.
7.4.1.1 Zgodność z blokadami numerów
Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.telephony.calling
:
- [C-1-1] MUSI obsługiwać blokowanie numerów
- [C-1-2] MUSI w pełni zaimplementować
BlockedNumberContract
i odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu SDK. [C-1-3] MUSI blokować wszystkie połączenia i wiadomości z numeru telefonu w „BlockNumberProvider” bez interakcji z aplikacjami. Jedyny wyjątek gdy blokowanie numerów jest tymczasowo zniesione zgodnie z opisem w pakiecie SDK. dokumentacji.
[C-1-4] MUSI zapisywać dane do dostawcy rejestru połączeń platformy dla zablokowanego połączenia i MUSI filtrować połączenia z
BLOCKED_TYPE
w domyślny widok rejestru połączeń we wstępnie zainstalowanej aplikacji telefonu.[C-1-5] NIE MOŻE pisać do dostawcy usług telefonicznych w przypadku zablokowanej wiadomości.
[C-1-6] MUSI wdrożyć interfejs do zarządzania zablokowanymi numerami, który jest otwarty z intencją zwrócona przez funkcję
TelecomManager.createManageBlockedNumbersIntent()
.[C-1-7] NIE MOŻE zezwalać użytkownikom pomocniczym na wyświetlanie ani edytowanie zablokowanych numerów na danym urządzeniu, ponieważ platforma Android zakłada, że główny użytkownik ma nad usługami telefonicznymi na urządzeniu. Wszystkie UI powiązany z blokowaniem MUSI być ukryty dla użytkowników pomocniczych, a lista zablokowanych MUSI być ukryta które nadal będą szanowane.
PO KAŻDEJ aktualizacji urządzenia NALEŻY przenieść zablokowane numery do dostawcy usług. na Androida 7.0.
TRZEBA zapewnić użytkownikom możliwości wyświetlania zablokowanych połączeń Telefon.
7.4.1.2. Telecom API
Jeśli implementacje urządzeń zgłaszają android.hardware.telephony.calling
:
- [C-1-1] MUSI obsługiwać interfejsy API
ConnectionService
opisane w pakiecie SDK. - [C-1-2] MUSI wyświetlić nowe połączenie przychodzące i poinformować użytkownika
zaakceptować lub odrzucić połączenie przychodzące, gdy użytkownik jest w trakcie trwającego połączenia;
utworzone przez aplikację innej firmy, która nie obsługuje funkcji blokady;
określona przez
CAPABILITY_SUPPORT_HOLD
- [C-1-3] MUSI zawierać aplikację, która stosuje InCallService.
[C-SR-1] Zdecydowanie ZALECANE jest powiadomienie użytkownika o tym, że odpowiedź na połączenie przychodzące spowoduje zakończenie trwającego połączenia.
Implementacja AOSP spełnia te wymagania dzięki powiadomieniu z ostrzeżeniem który informuje, że odebranie połączenia przychodzącego spowoduje inne połączenie do usunięcia.
[C-SR-2] Zdecydowanie ZALECANE jest wstępne ładowanie domyślnej aplikacji telefonu, która pokazuje wpis w rejestrze połączeń i nazwę aplikacji innej firmy w rejestrze połączeń gdy aplikacja innej firmy ustawia
EXTRA_LOG_SELF_MANAGED_CALLS
na kluczu dodatków odPhoneAccount
dotrue
.[C-SR-3] Zdecydowanie ZALECANE jest obsługa Zdarzenia
KEYCODE_MEDIA_PLAY_PAUSE
iKEYCODE_HEADSETHOOK
dla miesiącaandroid.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
.
- Zadzwoń pod numer
7.4.1.3 Odciążanie sieci komórkowej NAT-T
Implementacje na urządzeniach:
- POWINNO obsługiwać funkcję utrzymywania aktywności sieci komórkowej.
Jeśli implementacje urządzeń obejmują obsługę funkcji utrzymywania aktywności sieci komórkowej ujawnia tę funkcję aplikacjom innych firm,
- [C-1-1] MUSI obsługiwać interfejs SocketKeepAlive API.
- [C-1-2] MUSI obsługiwać co najmniej 1 przedział utrzymywania aktywności równoczesnej przez sieć komórkową.
- [C-1-3] MUSI obsługiwać tyle równoczesnych przedziałów czasu utrzymywania aktywności sieci komórkowej obsługiwane przez Cellular Radio HAL.
- [C-SR-1] Zdecydowanie ZALECANE są obsługa co najmniej 3 komórek utrzymywania aktywności na instancję radiową.
Jeśli implementacje urządzeń nie obsługują funkcji utrzymywania aktywności sieci komórkowej, one:
- [C-2-1] MUSI zwrócić błąd ERROR_UNSUPPORTED.
7.4.2 IEEE 802.11 (Wi-Fi)
Implementacje na urządzeniach:
- POWINNO obsługiwać co najmniej jedną formę standardu 802.11.
Jeśli implementacje urządzeń obsługują standard 802.11 i udostępniają aplikacji innej firmy:
- [C-1-1] MUSI wdrożyć odpowiedni interfejs API Androida.
- [C-1-2] MUSI zgłosić flagę funkcji sprzętowej
android.hardware.wifi
. - [C-1-3] MUSI wdrożyć interfejs API multicast zgodnie z opisem w dokumentacji pakietu SDK.
- [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 metodyNetwork
, który jest domyślnie używany do obsługi ruchu w aplikacji i jest zwracany autor:ConnectivityManager
Metody API, takie jakgetActiveNetwork
orazregisterDefaultNetworkCallback
. 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ądzeniuNetwork
, gdy ocena wskazuje, że bieżącyNetwork
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 lubWIFI_MODE_FULL_LOW_LATENCY
zamek przez:WifiManager.createWifiLock()
iWifiManager.WifiLock.acquire()
Interfejsy API i blokada są aktywne. - [C-3-2] Średnie opóźnienie w obie strony między urządzeniem
i punktu dostępu, gdy na urządzeniu jest włączona blokada Wi-Fi z opóźnieniem
Tryb (
WIFI_MODE_FULL_LOW_LATENCY
) MUSI być mniejszy niż opóźnienia w trybie blokady Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] Zdecydowanie ZALECANE jest ograniczenie opóźnień przesyłania danych przez Wi-Fi w obie strony.
za każdym razem, gdy uzyskano blokadę o krótkim czasie oczekiwania (
WIFI_MODE_FULL_LOW_LATENCY
) i zaczyna obowiązywać.
Jeśli urządzenia obsługują Wi-Fi i używają Wi-Fi do skanowania lokalizacji, one:
- [C-2-1] MUSI udostępniać środki użytkownika, aby włączyć/wyłączyć odczytywaną wartość
przez
WifiManager.isScanAlwaysAvailable
API.
7.4.2.1. Wi-Fi Direct
Implementacje na urządzeniach:
- POWINNA obsługiwać technologię Wi-Fi Direct (typu Wi-Fi peer-to-peer).
Jeśli implementacje urządzeń obsługują Wi-Fi Direct:
- [C-1-1] MUSI wdrożyć odpowiedni interfejs API Androida. zgodnie z opisem w dokumentacji pakietu SDK.
- [C-1-2] MUSI zgłosić funkcję sprzętową
android.hardware.wifi.direct
. - [C-1-3] MUSI obsługiwać normalne działanie Wi-Fi.
- [C-1-4] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Direct.
- [C-SR-1] Zdecydowanie ZALECANE jest losowe wybór źródłowego adresu MAC dla wszystkich nowo utworzonych połączeń Wi-Fi Direct.
7.4.2.2. Konfiguracja bezpośredniego linku Wi-Fi
Implementacje na urządzeniach:
- POWINNA OBSŁUGIWAĆ pomoc dotyczącą Konfiguracja bezpośredniego połączenia przez tunel Wi-Fi (TDLS) zgodnie z opisem w dokumentacji pakietu Android SDK.
Jeśli implementacje urządzeń obejmują obsługę TDLS, a tag TDLS jest włączony w Wi-FiManager API:
- [C-1-1] MUSI zadeklarować obsługę TDLS do
WifiManager.isTdlsSupported
. - Narzędzia TDLS należy używać tylko wtedy, gdy jest to możliwe i korzystne.
- POWINNY jest działać mechanizm heurystyczny i NIE używać TDLS, gdy jego wydajność może być jest gorsza niż przez punkt dostępu Wi-Fi.
7.4.2.3 Rozpoznawalność Wi-Fi
Implementacje na urządzeniach:
- POWINNO_obsługiwać funkcję Wi-Fi Aware.
Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i udostępniają funkcji aplikacji innych firm, to:
- [C-1-1] MUSI wdrożyć interfejsy API
WifiAwareManager
w sposób opisany w Dokumentacja pakietu SDK. - [C-1-2] MUSI zadeklarować flagę funkcji
android.hardware.wifi.aware
. - [C-1-3] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Aware.
- [C-1-4] MUSI w odstępach losowych udostępniać adres interfejsu zarządzania Wi-Fi Aware nie może być dłuższy niż 30 minut i gdy jest włączona usługa Wi-Fi Aware, trwa operacja określania zakresu lub aktywna jest ścieżka danych Aware (randomizacja nie jest oczekiwana, dopóki ścieżka danych jest aktywna).
Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware oraz Lokalizacja Wi-Fi zgodnie z opisem w sekcji 7.4.2.5 i ujawnia te funkcje aplikacjom innych firm, to:
- [C-2-1] MUSI wdrożyć interfejsy API wykrywania lokalizacji: setRangingEnabled, setMinOdległośćMm, setMaxOdległośćMm 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 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:
- POWINIEN obsługiwać Lokalizację Wi-Fi.
Jeśli implementacje urządzeń obejmują obsługę lokalizacji Wi-Fi i udostępniają funkcji aplikacji innych firm, to:
- [C-1-1] MUSI wdrożyć interfejsy API
WifiRttManager
w sposób opisany w Dokumentacja pakietu SDK. - [C-1-2] MUSI zadeklarować flagę funkcji
android.hardware.wifi.rtt
. - [C-1-3] MUSI randomizować źródłowy adres MAC w przypadku każdej serii RTT który jest wykonywany podczas korzystania z interfejsu Wi-Fi używanego przez RTT nie jest powiązany z punktem dostępu.
- [C-1-4] MUSI być dokładność z dokładnością do 2 metrów przy przepustowości 80 MHz przy 68 MHz percentyl (obliczany za pomocą funkcji rozkładu skumulowanego).
- [C-SR-1] Zdecydowanie ZALECANE jest raportowanie go z dokładnością do 1,5 metra. przy przepustowości 80 MHz w 68 centylu (zgodnie z obliczeniem funkcja rozkładu skumulowanego).
7.4.2.6 Odciążanie Wi-Fi
Implementacje na urządzeniach:
- POWINNO_obsługiwać odciążanie Wi-Fi.
jeśli implementacje urządzeń obsługują odciążanie Wi-Fi, i udostępnić tę funkcję aplikacjom innych firm:
- [C-1-1] MUSI obsługiwać interfejs API SocketKeepAlive.
- [C-1-2] MUSI obsługiwać co najmniej trzy równoległe przedziały utrzymywania aktywności przez Wi-Fi.
Jeśli implementacje urządzeń nie obsługują odciążania Wi-Fi, one:
- [C-2-1] MUSI zwrócić
ERROR_UNSUPPORTED
.
7.4.2.7. Łatwe połączenie Wi-Fi (protokół obsługi administracyjnej urządzeń)
Implementacje na urządzeniach:
- POWINNO_obsługiwać Wi-Fi Easy Connect (DPP).
Jeśli urządzenia obsługują Wi-Fi Easy Connect i udostępnić funkcji aplikacji innych firm:
- [C-1-1] MUSI zawierać parametr WifiManager#isEasyConnectSupported().
zwraca wartość
true
.
7.4.2.8 Weryfikacja certyfikatu serwera Wi-Fi dla firm
Jeśli certyfikat serwera Wi-Fi nie został zweryfikowany lub serwer Wi-Fi nie został zweryfikowany nie ustawiono nazwy domeny, implementacje urządzeń:
- [C-SR-1] Zdecydowanie ZALECANE jest nieudostępnianie użytkownikowi opcji ręcznie dodaj firmową sieć Wi-Fi, w aplikacji Ustawienia.
7.4.2.9. Zaufanie przy pierwszym użyciu (TOFU)
Jeśli implementacje urządzenia obsługują funkcję „Zaufanie przy pierwszym użyciu” (TOFU), pozwalają użytkownikowi na definiowanie konfiguracji WPA/WPA2/WPA3-Enterprise; to:
- [C-4-1] MUSI umożliwiać użytkownikowi użycie usługi TOFU.
7.4.3 Bluetooth
Jeśli implementacje urządzenia obsługują profil audio Bluetooth:
- POWINNA obsługiwać zaawansowane kodeki audio i kodeki audio Bluetooth (np. LDAC) z A2DP.
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
iandroid.hardware.bluetooth_le
) i wdrożyć interfejsy API platformy. - NALEŻY zaimplementować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX, HFP itp. odpowiednio do urządzenia.
Jeśli implementacje urządzeń obejmują obsługę Bluetooth Low Energy (BLE), te funkcje:
- [C-3-1] MUSI zadeklarować funkcję sprzętową
android.hardware.bluetooth_le
. - [C-3-2] MUSI włączyć Bluetooth oparty na GATT (ogólnym profilu) interfejsów API opisanych w dokumentacji pakietu SDK oraz android.bluetooth
- [C-3-3] MUSI zgłaszać prawidłową wartość dla
BluetoothAdapter.isOffloadedFilteringSupported()
, aby wskazać, czy logika filtrowania w funkcji ScanFilter Wdrożono klasy interfejsu API. - [C-3-4] MUSI zgłaszać prawidłową wartość dla
BluetoothAdapter.isMultipleAdvertisementSupported()
, aby wskazać czy reklamy Low Energy Advertising są obsługiwane. - [C-3-5] TRZEBA wdrożyć limit czasu oczekiwania na odpowiedź RPA ponad 15 minut i zmieniać adres po upłynięciu czasu oczekiwania, aby chronić prywatność użytkowników gdy urządzenie aktywnie używa BLE do skanowania lub wyświetlania reklam. Aby zapobiec atakom czasowym, przedziały czasu oczekiwania MUSZĄ też być losowe od 5 do 15 minut.
- POWINNA obsługiwać przenoszenie logiki filtrowania do chipsetu Bluetooth podczas implementacji interfejsu API ScanFilter.
- POWINNO obsługiwać pobieranie skanowania zbiorczego do chipsetu Bluetooth.
- POWINNA obsługiwać wiele reklam z co najmniej 4 boksami.
Jeśli implementacje urządzeń obsługują Bluetooth LE i Bluetooth LE do skanowania lokalizacji,
- [C-4-1] MUSI udostępniać środki użytkownika, aby włączyć/wyłączyć odczytywaną wartość
za pomocą interfejsu System API
BluetoothAdapter.isBleScanAlwaysAvailable()
.
Jeśli implementacje urządzeń obejmują obsługę Bluetooth LE i aparatów słuchowych Profil, zgodnie z opisem w sekcji Obsługa dźwięku w aparacie słuchowym przy użyciu Bluetooth LE umożliwia:
- [C-5-1] MUSI zwrócić
true
za BluetoothAdapter.getProfileProxy(context, detektor, BluetoothProfile.HEARING_AID).
Jeśli implementacje urządzenia obejmują obsługę Bluetootha lub Bluetooth Low Energy, one:
- [C-6-1] MUSI ograniczać dostęp do metadanych Bluetooth (takich jak skanowanie
które mogą zostać użyte do określenia lokalizacji urządzenia, chyba że
aplikacja wysyłająca prośbę przekazuje
android.permission.ACCESS_FINE_LOCATION
sprawdzania uprawnień na podstawie jej bieżącego stanu na pierwszym planie/w tle.
Jeśli implementacje urządzenia obejmują obsługę Bluetootha lub Bluetooth Low Energy a manifest aplikacji nie zawiera deklaracji dewelopera, że nie korzystają z Bluetootha, to:
- [C-6-2] MUSI blokować dostęp do Bluetootha za urządzeniem
android.permission.ACCESS_FINE_LOCATION
.
Jeśli implementacje urządzeń zwracają wartość true
w przypadku parametru
BluetoothAdapter.isLeAudioSupported()
API, wówczas:
- [C-7-1] MUSI obsługiwać klienta unicast.
- [C-7-2] MUSI obsługiwać 2 mln PHY.
- [C-7-3] MUSI obsługiwać reklamy rozszerzone LE.
- [C-7-4] MUSI obsługiwać co najmniej 2 połączenia CIS w CIG.
- [C-7-5] MUSI włączyć klienta unicast BAP, koordynatora zestawu CSIP, serwer MCP kontroler VCP i serwer CCP jednocześnie.
- [C-SR-1] Zdecydowanie ZALECANE jest włączenie klienta HAP unicast.
Jeśli implementacje urządzeń zwracają wartość true
w przypadku parametru
BluetoothAdapter.isLeAudioBroadcastSourceSupported()
API, wówczas:
- [C-8-1] MUSI obsługiwać co najmniej 2 linki BIS w dużych liczbach.
- [C-8-2] MUSI włączyć źródło transmisji BAP, asystenta transmisji BAP jednocześnie.
- [C-8-3] MUSI obsługiwać reklamy okresowe LE.
Jeśli implementacje urządzeń zwracają wartość true
w przypadku parametru
BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API, wówczas:
- [C-9-1] MUSI obsługiwać okresowe przesyłanie synchronizacji reklam.
- [C-9-2] MUSI obsługiwać reklamy okresowe LE.
Jeśli implementacje urządzenia zadeklarują FEATURE_BLUETOOTH_LE
:
- [C-10-1] Pomiar RSSI MUSI mieścić się w zakresie +/-9 dB w przypadku 95%
w odległości 1 m od urządzenia referencyjnego transmitującego w odległości 1 m
ADVERTISE_TX_POWER_HIGH
w miejscu, w którym nic nie widać. - [C-10-2] MUSI zawierać korekty Rx/Tx, aby zmniejszyć odchylenia dla poszczególnych kanałów. aby pomiary na każdym z 3 kanałów, na każdej z anten (jeśli zastosowanych jest kilka) znajdują się w zakresie +/-3 dB od siebie w 95% pomiarów.
- [C-SR-2] Zdecydowanie ZALECANE jest mierzenie i kompensowanie przesunięcia Rx do
upewnij się, że mediana BLE RSSI wynosi -60 dBm +/-10 dB w odległości 1 m od
urządzenia referencyjnego nadającego w źródle
ADVERTISE_TX_POWER_HIGH
, gdzie urządzenia są zorientowane tak, że znajdują się na „równoległych płaszczyznach” z ekranami skierowanymi do siebie kierunek. - [C-SR-3] Zdecydowanie ZALECANE jest mierzenie i kompensowanie przesunięcia transakcji o
upewnij się, że mediana BLE RSSI wynosi -60 dBm +/-10 dB podczas skanowania z poziomu odniesienia
znajduje się w odległości 1 m i przesyła z częstotliwości
ADVERTISE_TX_POWER_HIGH
, gdzie urządzenia są ustawione tak, że są włączone; „samoloty równoległe” których ekrany są skierowane w tym samym kierunku.
Zdecydowanie ZALECANE jest wykonanie kroków konfiguracji pomiaru podanych w artykule Kalibracja obecności.
Jeśli implementacje urządzeń obsługują Bluetooth w wersji 5.0, to:
- [C-SR-4] Zdecydowanie ZALECANE jest zapewnienie pomocy w zakresie:
- LE 2M PHY
- LE Codec PHY
- LE Advertising Extension
- Okresowe reklamy
- Co najmniej 10 zestawów reklam.
- Co najmniej 8 równoczesnych połączeń LE. Każde połączenie może znajdować się w w zakresie topologii połączeń.
- LE Link Layer Privacy
- listę rozwiązań. rozmiar co najmniej 8 wpisów
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ługiandroid.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 Metodaandroid.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
wandroid.content.pm.PackageManager.hasSystemFeature
() . Nie jest to standardowa funkcja Androida, dlatego nie są wyświetlane jako stała w klasieandroid.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 jakAF_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.
- MUSI mieć pewność, że komunikacja IPv6 będzie równie niezawodna jak IPv4, na przykład:
- [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
lubSocket#getLocalPort
) i interfejsy API NDK, takie jakgetsockname()
czyIPV6_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 APIConnectivityManager#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
iandroid.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
dlaConnectivityManager.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.4.9. UWB
Jeśli implementacje urządzeń obsługują standard 802.1.15.4 i udostępniają aplikacji innej firmy, to:
- [C-1-1] MUSI zaimplementować odpowiedni interfejs API Androida w pliku android.uwb.
- [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.uwb.
- [C-1-3] MUSI obsługiwać wszystkie odpowiednie profile UWB zdefiniowane w Androidzie implementacji.
- [C-1-4] MUSI udostępniać informacje o produkcie, aby użytkownik mógł przełączyć UWB stanu włączenia/wyłączenia radia.
- [C-1-5] MUSI wymuszać, aby aplikacje korzystające z radia UWB miały uprawnienie UWB_RANGING (w grupie uprawnień NEARBY_devices).
[C-SR-1] Zdecydowanie ZALECANE jest przejście odpowiedniej zgodności i testów certyfikacyjnych zdefiniowanych przez standardowe organizacje, w tym FIRA, CCC i CSA.
- [C-1-6] MUSI mieć pewność, że pomiar odległości wynosi +/-15 cm w przypadku 95%. w miejscu widoczności z odległości 1 m w komorze nieodbiciowej.
- [C-1-7] MUSI zapewnić medianę odległości 1 m z urządzenia referencyjnego znajduje się w promieniu [0,75 m; 1,25 m], gdzie dane podstawowe Odległość mierzona od górnej krawędzi urządzenia DUT trzymanego pionowo do góry i przechylonego 45 stopni.
- [C-SR-2] Zdecydowanie ZALECANE jest wykonanie czynności wymaganych do konfiguracji pomiaru. określona w Kalibracja obecności.
7.5 Aparaty
Jeśli implementacje urządzeń obejmują co najmniej jedną kamerę:
- [C-1-1] MUSI zadeklarować flagę funkcji
android.hardware.camera.any
. - [C-1-2] MUSI być dostępna, aby aplikacja mogła jednocześnie przydzielać 3 mapy bitowe RGBA_8888 równe rozmiarowi obrazów wygenerowanych przez czujnika aparatu o największej rozdzielczości na urządzeniu, a aparat jest otwarty na potrzeby podstawowej wersji przedpremierowej.
- [C-1-3] MUSI mieć pewność, że zainstalowana jest domyślna aplikacja aparatu.
intencji obsługi
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, lubMediaStore.ACTION_VIDEO_CAPTURE
, odpowiada za usunięcie lokalizacji użytkownika z metadanych obrazu przed wysyłanie do aplikacji odbierającej, gdy aplikacja odbierająca nie mająACCESS_FINE_LOCATION
.
Jeśli implementacje urządzeń obsługują 10-bitowy HDR, to:
- [C-2-1] MUSI obsługiwać co najmniej profil HLG HDR w przypadku każdego aparatu. który obsługuje 10-bitowe pliki wyjściowe.
- [C-2-2] MUSI obsługiwać 10-bitowe wyjście dla głównego tylnego urządzenia lub głównego przedniego aparatu.
- [C-SR-1] Zdecydowanie ZALECANE jest obsługa 10-bitowych danych wyjściowych zarówno kamery.
- [C-2-3] MUSI obsługiwać te same profile HDR na wszystkich urządzeniach fizyczne podrzędne kamery kamery logicznej z obsługą funkcji BACKWARD_COMPATIBLE; przez aparat logiczny.
W przypadku aparatów logicznych, które obsługują 10-bitowy HDR,
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
. Są to:
- [C-3-1] MUSI obsługiwać przełączanie między wszystkimi urządzeniami fizycznymi zgodnymi wstecznie
za pomocą elementu sterującego
CONTROL_ZOOM_RATIO
na kamerze logicznej.
7.5.1 Kamera tylna
Tylny aparat to 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
iandroid.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 atrybutyFLASH_MODE_AUTO
lubFLASH_MODE_ON
Camera.Parameters
obiektu. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu systemowego, ale tylko aplikacji za pomocą interfejsuCamera.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
iandroid.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 funkcjiandroid.hardware.Camera.setDisplayOrientation()
. - [C-1-5] NIE MOŻE odzwierciedlać ostatecznej wersji zdjęć ani strumieni wideo w odpowiedzi na wywołania zwrotne aplikacji lub zadeklarowano do przechowywania multimediów.
- [C-1-6] MUSI w ten sam sposób odbić obraz wyświetlany po wyświetleniu jako strumień obrazów z podglądu z aparatu.
- MOŻE zawierać funkcje (takie jak autofokus, lampa błyskowa itp.) dostępne dla: tylnych aparatów zgodnie z opisem w sekcji 7.5.1.
Jeśli implementacje urządzeń mogą być objęte rotacji przez użytkownika (np. automatycznie za pomocą akcelerometru lub ręcznie na podstawie danych wejściowych użytkownika):
- [C-2-1] Podgląd z aparatu MUSI być odbicie lustrzane w poziomie bieżącej orientacji urządzenia.
7.5.3 Kamera zewnętrzna
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
iandroid.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łanaandroid.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 doonPreviewFrame()
. 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 aparacieandroid.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
iandroid.hardware.ImageFormat.JPEG
jako danych wyjściowych przez Interfejs APIandroid.media.ImageReader
dlaandroid.hardware.camera2
urządzeń, które ReklamujREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
wandroid.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
iandroid.hardware.camera2.CaptureRequest
. I odwrotnie, implementacje urządzeń NIE MOGĄ uznawać ani rozpoznawać stałych ciągów znaków. przekazywane do metodyandroid.hardware.Camera.setParameters()
innej niż te są udokumentowane jako stałe naandroid.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ługaandroid.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 interfejsieandroid.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
lubandroid.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 zsdcard
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.
- Gdy aplikacja wysłała żądanie
- [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 uprawnienieACCESS_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
- Identyfikator wykorzystania strony użycia (0xC) (0x0CD):
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
, IntencjeACTION_OPEN_DOCUMENT
iACTION_CREATE_DOCUMENT
. .
Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i USB Typ C, to:
- [C-4-1] MUSI zaimplementować funkcję podwójnego portu USB zgodnie z definicją podaną przez USB Specyfikacja typu C (art. 4.5.1.3.3). Dual Porty ról: na urządzeniach wyposażonych w gniazdo słuchawek 3,5 mm zlew USB wykrywanie (tryb hosta) MOŻE być domyślnie wyłączone, ale MUSI być dostępne w użytkownik, który ją włączy.
- [C-SR-2] Zdecydowanie zalecana do obsługi DisplayPort, POWINNA obsługiwać USB SuperSzybkość danych i Zdecydowanie ZALECANA do obsługi Power Delivery w celu zmiany ról związanych z danymi i zasilaniem.
- [C-SR-3] Zdecydowanie NIE zaleca się obsługi trybu akcesorium adaptera audio jako opisane w Załączniku A do Wersja 1.2 specyfikacji kabla USB typu C i złącza
- Trzeba wdrożyć model Try.*, który najlepiej pasuje do format urządzenia. Na przykład na urządzeniu przenośnym WARTO zaimplementować Model Try.SNK.
7.8 Dźwięk
7.8.1 mikrofon
Jeśli implementacje urządzeń zawierają mikrofon:
- [C-1-1] MUSI zgłaszać stałą funkcję
android.hardware.microphone
. - [C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku w art. 5.4.
- [C-1-3] MUSI spełniać wymagania dotyczące opóźnień dźwięku określone w artykuł 5.6.
- [C-SR-1] Zdecydowanie ZALECANE są w sposób opisany powyżej nagrywanie dźwięku bliskiego ultradźwięku. w sekcji 7.8.3.
Jeśli implementacje urządzenia pomijają mikrofon:
- [C-2-1] NIE MOŻE zgłaszać stałej funkcji
android.hardware.microphone
. - [C-2-2] MUSI wdrożyć interfejs API do nagrywania dźwięku co najmniej w trybie braku działań zgodnie z sekcja 7.
7.8.2 Wyjście audio
jeśli implementacje urządzeń obejmują głośnik lub wyjście audio/multimedialne, do urządzenia peryferyjnego wyjścia audio, takiego jak 4-kanałowe gniazdo słuchawek 3,5 mm lub Port w trybie hosta USB i z użyciem klasy audio USB:
- [C-1-1] MUSI zgłaszać stałą funkcję
android.hardware.audio.output
. - [C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku w sekcja 5.5.
- [C-1-3] MUSI spełniać wymagania dotyczące opóźnień dźwięku określone w artykuł 5.6.
- [C-SR-1] Zdecydowanie zalecana do odtwarzania dźwięku w trybie zbliżonym do ultradźwięków zgodnie z opisem w sekcji 7.8.3.
Jeśli urządzenia nie mają gniazda głośnika ani wyjścia audio:
- [C-2-1] NIE MOŻE zgłaszać funkcji
android.hardware.audio.output
. - [C-2-2] MUSI wdrożyć interfejsy API związane z wyjściem audio przynajmniej w trybie bezobsługowym.
Na potrzeby tej sekcji „port wyjściowy” jest interfejs fizyczny np.gniazdo słuchawek 3, 5 mm, HDMI lub port w trybie hosta USB z klasą audio USB. Obsługa wyjścia audio przez protokoły radiowe, takie jak Bluetooth, Wi-Fi 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 i 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
- Maks. 70 omów:
- [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
- 110–180 omów:
- [C-SR-2] Zdecydowanie ZALECANE są współdziałanie wtyczek audio z OMTP w kolejności odpinania.
- [C-SR-3] Zdecydowanie ZALECANE są obsługa nagrywania dźwięku ze źródeł stereo. zestawy słuchawkowe z mikrofonem.
Jeśli urządzenia są wyposażone w 4-żyłowe gniazdo słuchawek 3,5 mm i obsługują
i prześlij komunikat „android.intent.action.HEADSET_PLUG
” wraz z
mikrofon o dodatkowej wartości ustawiony na 1:
- [C-2-1] MUSI obsługiwać wykrywanie mikrofonu we podłączonym dźwięku akcesorium.
7.8.2.2. Cyfrowe porty audio
Wymagania związane z poszczególnymi urządzeniami znajdziesz w artykule 2.2.1.
7.8.3 Prawie ultradźwiękowy
Dźwięk Near ultradźwiękowy to pasmo 18,5–20 kHz.
Implementacje na urządzeniach:
- MUSI prawidłowo zgłaszać zespół pomocy 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 | < 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ównoVK_QUEUE_GRAPHICS_BIT
, jak iVK_QUEUE_COMPUTE_BIT
, iqueueCount
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
flagiAHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
iAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
zgodnie z wytycznymi NDK. - [C-1-10] MUSISZ zaimplementować obsługę komponentów
AHardwareBuffer
z dowolnymi kombinacja flag wykorzystaniaAHARDWAREBUFFER_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
interfejs API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
. Wymagania
klasy wydajności multimediów są zdefiniowane dla każdej wersji Androida, zaczynając od
R (wersja 30). Wartość specjalna 0 oznacza, że urządzenie nie jest
klasa skuteczności multimediów.
Jeśli implementacje urządzeń zwracają wartość inną niż zero dla argumentu
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
[C-1-1] MUSI zwracać co najmniej wartość
android.os.Build.VERSION_CODES.R
.[C-1-2] MUSI być implementacją na urządzeniach mobilnych.
[C-1-3] MUSI spełniać wszystkie wymagania dotyczące klasy „Media Performance Class” opisana w sekcji 2.2.7.
Inaczej mówiąc, klasa wydajności multimediów w Androidzie T jest zdefiniowana tylko dla: urządzeń mobilnych w wersji T, S lub R.
Szczegółowe informacje znajdziesz w sekcji 2.2.7. .
8. Wydajność i moc
Niektóre kryteria minimalnej wydajności i mocy mają kluczowe znaczenie dla wygody użytkowników. i wpłynąć na podstawowe założenia, jakich przyjmują deweloperzy przy opracowywaniu .
8.1. Spójność wrażeń użytkownika
Użytkownikom można zapewnić płynny interfejs, jeśli minimalne wymagania dla zapewnienia stałej liczby klatek i czasu reakcji aplikacji i gier. Implementacje urządzeń w zależności od ich typu MOŻE mieć mierzalne wymagania dotyczące czasu oczekiwania i zadania w interfejsie zgodnie z opisem w sekcji 2.
8.2. Skuteczność dostępu do plików
Wskazanie punktu odniesienia dla stałej wydajności dostępu do plików w
prywatne miejsce na dane aplikacji (partycja /data
) umożliwia deweloperom aplikacji
aby uzyskać odpowiednie oczekiwania, które ułatwią projektowanie oprogramowania. Urządzenie
implementacje MOGĄ mieć określone wymagania w zależności od typu urządzenia
opisanych w sekcji 2.
i operacji zapisu:
- Wydajność sekwencyjnego zapisu. Pomiar ten polega na zapisaniu pliku 256 MB za pomocą Bufor zapisu 10 MB.
- Losowa wydajność zapisu. Zmierzony przez zapisanie pliku 256 MB o rozmiarze 4 kB bufor zapisu.
- Wydajność sekwencyjnego odczytu. Pomiar dokonywany jest na podstawie odczytu pliku 256 MB za pomocą Bufor zapisu 10 MB.
- Losowa wydajność odczytu. Pomiar został zmierzony przy odczycie pliku 256 MB przy użyciu 4 KB bufor zapisu.
8.3. Tryby oszczędzania energii
jeśli implementacje urządzeń obejmują funkcje usprawniające zarządzanie energią urządzenia; uwzględnione w AOSP (np. zasobnik gotowości aplikacji, uśpienie) lub rozszerzenie funkcji w celu zastosowania silniejszych ograniczeń niż zasobnik gotowości aplikacji OGRANICZONE:
- [C-1-1] NIE MOŻE odbiegać od implementacji AOSP dla reguły, konserwację, algorytmy wybudzania i korzystanie z globalnych ustawień systemu lub DeviceConfig trybów Czuwanie aplikacji i Uśpienie.
- [C-1-2] NIE MOŻE odbiegać od implementacji AOSP w przypadku użycia globalnego lub DeviceConfig do zarządzania ograniczaniem liczby zadań, dla aplikacji w każdym zasobniku na potrzeby gotowości aplikacji.
- [C-1-3] NIE MOŻE odbiegać od implementacji AOSP dla liczby Zasobniki gotowości aplikacji uż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
zaPowerManager.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 procesoraPARTIAL_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 standardu
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
o wartościPROTECTION_FLAG_PRIVILEGED
MOŻE być przyznawana tylko aplikacjom wstępnie zainstalowanym w ścieżkach z podwyższonymi uprawnieniami obrazu systemu (jak również plików APEX) należących do podzbioru uprawnień poszczególnych aplikacji umieszczonych na liście dozwolonych. Implementacja AOSP spełnia to wymaganie, czytając i przestrzegając dostęp do wszystkich aplikacji z listy dozwolonych,etc/permissions/
i użycie ścieżkisystem/priv-app
jako parametru ś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. Jeśli implementacja urządzenia obsługuje urządzenie towarzyszące, urządzenie towarzyszące MOŻE udostępnić dodatkowy interfejs.
[C-0-5] NIE MOŻE przyznawać żadnych uprawnień czasu działania do chyba że:
- są instalowane w momencie wysyłki urządzenia ORAZ
Zgodę użytkownika można uzyskać przed złożeniem wniosku korzysta z tych uprawnień,
LUB
Uprawnienia czasu działania są przyznawane przez domyślna zasada przyznawania uprawnień lub pełnienia roli na platformie.
[C-0-6] MUSI przyznać uprawnienie
android.permission.RECOVER_KEYSTORE
tylko w przypadku aplikacji systemowych rejestrujących prawidłowo zabezpieczonego agenta odzyskiwania. O poprawnie zabezpieczony agent odzyskiwania jest zdefiniowany jako agent oprogramowania na urządzeniu; która synchronizuje się ze zdalnej pamięci masowej poza urządzeniem, która zawiera bezpieczny sprzęt z odpowiednią ochroną lub silniejszym opisane w Usługa Google Cloud Key Vault Service aby zapobiec atakom brute-force na podstawie wiedzy na ekranie blokady.
Implementacje na urządzeniach:
[C-0-7] MUSI przestrzegać właściwości dostępu do lokalizacji na Androidzie, gdy aplikacja wysyła żądanie danych o lokalizacji lub aktywności fizycznej za pomocą standardowego interfejsu API Androida. lub zastrzeżonego mechanizmu. Dane te obejmują między innymi:
- Lokalizacja urządzenia (np. szerokość i długość geograficzna) zgodnie z opisem w sekcji art. 9.8.8.
- Informacje, które mogą służyć do określenia lub oszacowania lokalizacja (np. identyfikator SSID, BSSID, identyfikator komórkowy lub lokalizacja sieci, urządzenie, z którym jest połączone urządzenie).
- Aktywność fizyczna lub klasyfikacja aktywności użytkownika.
Mówiąc bardziej szczegółowo o implementacjach na urządzeniach:
- [C-0-8] MUSI uzyskać zgodę użytkownika na dostęp do dane o lokalizacji czy aktywności fizycznej.
- [C-0-9] MUSI przyznawać uprawnienia w czasie działania TYLKO aplikacji, która zawiera
wystarczających uprawnień zgodnie z opisem w pakiecie SDK.
Przykład:
Menedżer połączeń#getServiceState
wymaga
android.permission.ACCESS_FINE_LOCATION
).
Jedynym wyjątkiem od powyższych właściwości dotyczących dostępu do lokalizacji na Androidzie są te, aplikacje nie mające dostępu do Lokalizacji w celu określenia lub ustalania lokalizacji użytkownika; a konkretnie:
- Gdy aplikacje mają uprawnienie
RADIO_SCAN_WITHOUT_LOCATION
. - W celach związanych z konfiguracją urządzenia, gdzie aplikacje systemowe przechowują
Uprawnienie
NETWORK_SETTINGS
lubNETWORK_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ługisoftRestricted
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
iCONFIG_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
lubCONFIG_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
lubCONFIG_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
lubCONFIG_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
lubCONFIG_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
lubEFI_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
iCONFIG_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
lubCONFIG_INIT_STACK_ALL_ZERO
). Ponadto implementacje urządzeń NIE POWINNY zakładać wartości używanej przez kompilatora do zainicjować zasoby lokalne.[C-SR-7] Zdecydowanie ZALECANE jest włączenie inicjowania stosu w jądrze. aby zapobiec używaniu niezainicjowanych alokacji sterty (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
), a NIE POWINNO przyjmować wartości używanej przez jądro zainicjuje te przydziały.
Jeśli implementacji na urządzeniach korzysta z jądra Linuksa, który obsługuje SELinux:
- [C-1-1] MUSI zaimplementować SELinux.
- [C-1-2] MUSI ustawić SELinux w tryb globalnego egzekwowania.
- [C-1-3] MUSI skonfigurować wszystkie domeny w trybie wymuszania. Brak trybu mniej rygorystycznego domeny, w tym domeny charakterystyczne dla danego urządzenia lub dostawcy.
- [C-1-4] NIE MOŻE modyfikować, pomijać ani zastępować obecnych reguł zezwalających w folderze system/sepolicy udostępnionym na nadrzędnym kanale open source Androida Projekt (AOSP) i zasada MUSZĄ skompilować wszystkie obecne reguły typu „Nigdy nie zezwalaj”, zarówno w domenach AOSP SELinux, jak i tych specyficznych dla urządzeń/dostawców.
- [C-1-5] MUSI uruchamiać aplikacje innych firm kierowane na interfejs API na poziomie 28 lub wyższym w piaskownicy SELinux z ograniczeniami SELinux dla poszczególnych aplikacji w katalogu prywatnych aplikacji.
- POWINNY jest zachować domyślną zasadę SELinux obowiązującą w systemie/zasadzie sekwencji. folderu nadrzędnego projektu Android Open Source, a do tego dla ich własnej konfiguracji.
Jeśli implementacje urządzeń wykorzystują jądro innego niż Linux lub Linux bez SELinux, one:
- [C-2-1] MUSI używać obowiązkowego systemu kontroli dostępu, który odpowiednika SELinux.
Jeśli implementacje urządzeń korzystają z urządzeń I/O obsługujących DMA:
- [C-SR-9] Zdecydowanie ZALECANE jest izolowanie każdego urządzenia wejścia-wyjścia obsługującego DMA, przy użyciu IOMMU (np. ARM SMMU).
Android zawiera wiele zaawansowanych funkcji obrony, które są wbudowane w urządzenie zabezpieczeń. Oprócz tego Android skupia się na redukcji kluczowych klas typowych błędów. które wpływają na niską jakość i bezpieczeństwo.
Aby ograniczyć błędy w pamięci, implementacje urządzeń:
- [C-SR-10] Zdecydowanie ZALECANE jest przetestowanie ich z wykorzystaniem błędu pamięci przestrzeni użytkownika. narzędzi do wykrywania takich jak MTE dla urządzeń z architekturą ARMv9, HWASan dla urządzeń ARMv8+ i ASan w przypadku innych typów urządzeń.
- [C-SR-11] Zdecydowanie ZALECANE jest przetestowanie z wykorzystaniem błędu pamięci jądra systemu takich jak KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS), Urządzenia ARMv9, CONFIG_KASAN_SW_TAGS dla urządzeń ARMv8 lub CONFIG_KASAN_GENERIC w przypadku innych typów urządzeń).
- [C-SR-12] Zdecydowanie ZALECANE jest korzystanie z narzędzi do wykrywania błędów pamięci w takich jak MTE, GWP-ASan i KFENCE.
Jeśli implementacje urządzeń korzystają z TEE opartego na Arm TrustZone:
- [C-SR-13] Zdecydowanie ZALECANE jest używanie standardowego protokołu pamięci w systemie Android i TEE, jak np. platforma Armware Framework Armv8-A (FF-A).
- [C-SR-14] Zdecydowanie ZALECANE jest ograniczenie dostępu zaufanych aplikacji tylko do użytkowników, dostęp do pamięci, która została mu udostępniona za pomocą powyższego protokołu. Jeśli urządzenie obsługuje poziom wyjątku Arm S-EL2, powinno być egzekwowane przez menedżera bezpiecznego partycji. W przeciwnym razie wymuszane przez system TEE OS.
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 APIIncidentManager
. - [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 ustawienieSERVICE_META_DATA_SUPPORTS_ALWAYS_ON
wartość atrybutufalse
.
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 lubAppSearchManager
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.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.Launcher.
- [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 zwrócić obciętych danych ze schowka (np.
ClipboardManager
API), chyba że domyślnym edytorem jest aplikacja innej firmy ma obecnie fokus. - [C-0-2] MUSI wyczyścić dane ze schowka po upływie maksymalnie 60 minut od ich ostatniego umieszczone w schowku lub odczytywane ze schowka.
9.8.8 Lokalizacja
Lokalizacja obejmuje informacje z klasy lokalizacji systemu Android( takie jak Współrzędne, długość i wysokość), a także identyfikatory, które można przekonwertować na lokalizację. Lokalizacja może być tak dokładna jak DGPS (różnicowy globalny system pozycjonowania) lub przybliżone jako lokalizacje na poziomie kraju (np. lokalizacja według kodu kraju – MCK – Komórki kod kraju).
Poniżej znajduje się lista typów lokalizacji, które bezpośrednio stanowią dla użytkownika do lokalizacji lub mogą zostać przekształcone na lokalizację użytkownika. Nie jest to wyczerpująca lista ale należy go używać jako przykładu do bezpośredniego lub pośrednio pochodzą z:
- GPS/GNSS/DGPS/PPP
- rozwiązanie do globalnego pozycjonowania, globalny system satelitarny lub Rozwiązanie do różnicowego pozycjonowania globalnego
- Obejmuje to również nieprzetworzone pomiary GNSS i stan GNSS
- Dokładną lokalizację można określić na podstawie nieprzetworzonych pomiarów GNSS
- Technologie bezprzewodowe o unikalnych identyfikatorach, takich jak:
- Punkty dostępu Wi-Fi (MAC, BSSID, nazwa lub SSID)
- Bluetooth/BLE (MAC, BSSID, nazwa lub SSID)
- UWB (MAC, BSSID, nazwa lub SSID)
- Identyfikator stacji bazowej 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
- Zrzut
- [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
iACTION_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ęć masową oznacza, że program rozruchowy może wykryć, czy nie ktoś manipulował w pamięci urządzenia z Androidem.
- [C-1-9] MUSI prosić użytkownika podczas korzystania z urządzenia i wymaga fizycznego potwierdzenia przed zezwoleniem na przejście z programu rozruchowego; z trybu blokady do trybu odblokowanego programu rozruchowego.
- [C-1-10] MUSI wdrożyć ochronę przed wycofywaniem zmian na partycjach używanych przez Androida (np. podczas uruchamiania czy na partycjach systemu) i przechowywać w pamięci masowej metadane używane do określenia minimalnej dopuszczalnej wersji systemu operacyjnego.
- [C-1-11] MUSI bezpiecznie wymazywać wszystkie dane użytkownika podczas odblokowywania programu rozruchowego i zgodnie ze standardem 9.12. „Usunięcie danych” (w tym partycji danych użytkownika spacji NVRAM).
- [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
zaConfirmationPrompt.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 RSA, AES, ECDSA, ECDH (jeśli obsługiwany jest system IKeyMintDevice), 3DES, i algorytmy kryptograficzne HMAC oraz hasz rodziny MD5, SHA1 i SHA-2 zapewnia prawidłową obsługę które są bezpiecznie odizolowane od kodu działającego na na jądrze i w nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy za pomocą którego jądro lub kod przestrzeni użytkownika może uzyskać dostęp do wewnętrznego stanu w odizolowanym środowisku, w tym DMA. Starsze oprogramowanie typu open source na Androida Projekt (AOSP) spełnia to wymaganie, wykorzystując Zaufane, ale inne rozwiązanie oparte na technologii ARM TrustZone lub zewnętrzne sprawdzone wdrożenie prawidłowej izolacji opartej na hipernadzorcy to alternatywne rozwiązanie .
- [C-1-3] MUSI przeprowadzić uwierzytelnianie ekranu blokady w i tylko wtedy, gdy wszystko się uda, zezwól na dostępnych kluczy. Dane logowania na ekran blokady MUSZĄ być przechowywane który umożliwia korzystanie z ekranu blokady wyłącznie izolowanemu środowisku wykonawczemu uwierzytelnianie. Główny projekt Android Open Source udostępnia Warstwa abstrakcji sprzętowej bramy (HAL) i Trusty. Można je wykorzystać, aby spełnić to wymaganie.
- [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 wystarczająco dużej liczbie urządzeń, by zapobiec używaniu kluczy jako identyfikatorów urządzenia. W jedną stronę spełnienia tego wymogu, aby używać tego samego klucza atestu, chyba że co najmniej 100 000 sztuk danego kodu SKU. Jeśli więcej niż 100 000 jednostek kodu SKU, dla każdej 100 000 jednostek MOG może zostać użyty 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,
- IKeyMintDevice w wersji 1 lub
- IKeyMintDevice w wersji 2.
- [C-SR-1] Zdecydowanie ZALECANY jest obsługa IKeyMintDevice w wersji 1.
9.11.1. Bezpieczny ekran blokady, uwierzytelnianie i urządzenia wirtualne
Implementacja AOSP korzysta z wielopoziomowego modelu uwierzytelniania, w którym Uwierzytelnianie podstawowe oparte na wiedzy może być poparte wtórną silny biometryczną lub słabszymi modalnościami trzeciorzędnymi.
Implementacje na urządzeniach:
- [C-SR-1] Zdecydowanie ZALECANE jest ustawienie tylko jednej z tych opcji jako podstawowego uwierzytelniania
:
- Numeryczny kod PIN
- Hasło alfanumeryczne
- Wzór przesuwania na siatce zawierającej dokładnie 3 x 3 kropki
Powyższe metody uwierzytelniania są nazywane podstawowych metod uwierzytelniania w tym dokumencie.
Jeśli implementacje urządzeń dodają lub zmieniają zalecane uwierzytelnianie podstawowe nowych metod uwierzytelniania jako bezpiecznych metod blokowania ekranu, nową metodę uwierzytelniania:
- [C-2-1] MUSI być metodą uwierzytelniania użytkownika opisaną w Wymaganie uwierzytelniania użytkowników przy użyciu klucza.
Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania na potrzeby odblokowywania ekranu blokady, jeśli jest on oparty na znanym obiekcie tajnym, i użyje nowego uwierzytelniania. , która jest traktowana jako bezpieczny sposób blokowania ekranu:
- [C-3-1] Entropia najkrótszej dozwolonej długości danych wejściowych MUSI być więcej niż 10 bitów.
- [C-3-2] Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18-bitowa.
- [C-3-3] Nowa metoda uwierzytelniania NIE MOŻE zastępować żadnych zalecane główne metody uwierzytelniania (np. kod PIN, wzór, hasło) zostały wdrożone i udostępnione w AOSP.
- [C-3-4] Nowa metoda uwierzytelniania MUSI być wyłączona, gdy Aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła hasło wymagania dotyczące DevicePolicyManager.setRequiredPasswordComplexity() o bardziej restrykcyjnej stałej złożoności niż PASSWORD_COMPLExitY_NONE lub za pomocą funkcji DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
- [C-3-5] Nowe metody uwierzytelniania MUSZĄ wrócić do zalecane główne metody uwierzytelniania (np. kod PIN, wzór, hasła) raz na 72 godziny LUB wyraźnie ujawnić że niektóre dane nie będą tworzone w celu zachowania kopii zapasowej ochrony prywatności ich danych.
Jeśli implementacje urządzeń dodają lub zmieniają zalecane uwierzytelnianie podstawowe do odblokowywania ekranu blokady i używania nowej metody uwierzytelniania, oparte na biometrii jako bezpiecznego sposobu blokowania ekranu, :
- [C-4-1] MUSI spełniać wszystkie wymagania opisane w sekcji 7.3.10 dla klasy 1 (wcześniej: Wygoda).
- [C-4-2] MUSI mieć mechanizm awaryjny, aby użyć jednego z zalecanych podstawowych metod uwierzytelniania opartych na znanym obiekcie tajnym.
- [C-4-3] MUSI być wyłączona i zezwalać tylko na zalecane główne
uwierzytelnianie, aby odblokować ekran, gdy kontroler zasad dotyczących urządzeń (DPC)
aplikacja ustawiła zasadę funkcji blokady klawiszy, wywołując metodę
DevicePolicyManager.setKeyguardDisabledFeatures()
, z wszelkimi powiązanymi flagami biometrycznymi (np.KEYGUARD_DISABLE_BIOMETRICS
,KEYGUARD_DISABLE_FINGERPRINT
,KEYGUARD_DISABLE_FACE
lubKEYGUARD_DISABLE_IRIS
).
Jeśli metody uwierzytelniania biometrycznego nie spełniają wymagań dla klasy 3 (dawniej Silne) zgodnie z opisem w sekcja 7.3.10:
- [C-5-1] Metody MUSZĄ być wyłączone, jeśli kontroler zasad dotyczących urządzeń (DPC)
aplikacja ustawiła politykę jakości wymagań dotyczących haseł za pośrednictwem:
funkcja DevicePolicyManager.setRequiredPasswordComplexity()
z bardziej restrykcyjnym zasobnikiem złożoności niż
PASSWORD_COMPLEXITY_LOW
lub za pomocą funkcji DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niżPASSWORD_QUALITY_BIOMETRIC_WEAK
. - [C-5-2] Użytkownik MUSI otrzymać prośbę o podanie zalecanej metody głównej uwierzytelniania (np. kodu PIN, wzoru, hasła) zgodnie z opisem w sekcjach [C-1-7] oraz [C-1-8] w sekcji 7.3.10.
- [C-5-3] Metody NIE MOGĄ być traktowane jako bezpieczny ekran blokady i MUSZĄ spełnia wymagania rozpoczynające się od C-8 w tej sekcji poniżej.
Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania na potrzeby odblokowywania ekran blokady, a nowa metoda uwierzytelniania jest oparta na tokenie fizycznym lub lokalizacja:
- [C-6-1] MUSZĄ mieć mechanizm awaryjny, aby użyć jednego z zalecanych podstawowych metod uwierzytelniania, które są oparte na znanym obiekcie tajnym i są wymagania dotyczące korzystania z bezpiecznego ekranu blokady.
- [C-6-2] Nowa metoda MUSI być wyłączona i zezwalać tylko na jeden
zalecane główne metody uwierzytelniania do odblokowywania ekranu,
Aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasadę:
-
DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
metoda -
DevicePolicyManager.setPasswordQuality()
o bardziej restrykcyjnej stałej jakości niżPASSWORD_QUALITY_NONE
DevicePolicyManager.setRequiredPasswordComplexity()
o bardziej restrykcyjnym zasobniku złożoności niżPASSWORD_COMPLEXITY_NONE
-
- [C-6-3] Użytkownik MUSI otrzymać wyzwanie dotyczące jednego z zalecanych głównych metody uwierzytelniania (np. kod PIN, wzór, hasło) co najmniej raz Nie dłużej niż 4 godziny. Gdy token fizyczny spełnia wymagania wymagania dotyczące implementacji TrustAgent w C-X, ograniczenia czasu oczekiwania zdefiniowane w artykule 9-5.
- [C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI pamiętaj o ograniczeniach wymienionych w punkcie C-8 poniżej.
Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jeden
który implementuje systemowy interfejs API TrustAgentService
:
- [C-7-1] MUSI mieć wyraźne oznaczenie w menu ustawień i na zamku ekranu, gdy blokada urządzenia zostanie odroczona lub może zostać odblokowana przez agenta zaufania. Na przykład AOSP spełnia to wymaganie, wyświetlając opis tekstowy dla: ustawienie „Automatycznie blokuj” i „Błyskawiczne blokowanie przycisku zasilania” w menu ustawień i wyróżniającą się ikonę na ekranie blokady.
- [C-7-2] MUSI respektować i w pełni wdrażać wszystkie interfejsy API agenta zaufania
DevicePolicyManager
, takie jakKEYGUARD_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 przezDevicePolicyManager.setRequiredPasswordComplexity()
o bardziej restrykcyjnej stałej złożoności niż „PASSWORD_COMPLExitY_NONE”. - [C-8-2] NIE MOŻE resetować liczników czasu wygaśnięcia haseł ustawionych przez
DevicePolicyManager.setPasswordExpirationTimeout()
- [C-8-3] NIE MOGĄ udostępniać interfejsu API do użytku przez aplikacje innych firm zmienić stan blokady.
Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych
wyświetlacze wirtualne
i nie obsługują powiązanych zdarzeń wejściowych, np. przez
VirtualDeviceManager
,
one:
- [C-9-1] MUSI zablokować te dodatkowe ekrany wirtualne, gdy domyślny wyświetlacz jest zablokowany i odblokuj dodatkowe wyświetlacze wirtualne, gdy: domyślny wyświetlacz urządzenia jest odblokowany.
Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych wyświetlaczy wirtualnych i obsługę powiązanych danych wejściowych zdarzeń, np. za pomocą narzędzia VirtualDeviceManager, mogą one:
- [C-10-1] MUSI obsługiwać osobne stany blokady na urządzeniu wirtualnym
- [C-10-2] MUSI odłączać wszystkie urządzenia wirtualne po przekroczeniu limitu czasu bezczynności
- [C-10-3] MUSI mieć limit czasu bezczynności
- [C-10-4] MUSI zablokować wszystkie ekrany po uruchomieniu blokadę ekranu, w tym dzięki subskrypcji, która jest wymagana w przypadku urządzeń mobilnych (patrz sekcja Sekcja 2.2.5[9.11/H-1-2])
- [C-10-5] MUSI mieć oddzielne instancje urządzeń wirtualnych na użytkownika
- [C-10-6] MUSI wyłączyć tworzenie powiązanych zdarzeń wejściowych za pomocą
VirtualDeviceManager
po wskazaniu przezDevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] MUSI mieć oddzielny schowek tylko dla każdego urządzenia wirtualnego (lub wyłącz schowek w przypadku urządzeń wirtualnych)
- [C-10-11] NALEŻY wyłączyć interfejs uwierzytelniania na urządzeniach wirtualnych, w tym wprowadzanie do czynnika wiedzy i prompt biometryczny
- [C-10-12] MUSI ograniczać wyświetlanie intencji inicjowanych z urządzenia wirtualnego tylko na tym samym urządzeniu wirtualnym
- [C-10-13] W ramach uwierzytelniania użytkownika nie wolno używać stanu blokady urządzenia wirtualnego
w systemie Android Keystore. Zobacz
KeyGenParameterSpec.Builder.setUserAuthentication*
Gdy implementacje urządzeń pozwalają użytkownikowi przenieść główną współczynnik wiedzy o uwierzytelnianiu z urządzenia źródłowego na urządzenie docelowe np. podczas wstępnej konfiguracji urządzenia docelowego:
- [C-11-1] MUSI szyfrować współczynnik wiedzy z gwarancjami podobnymi do tych opisanych w Usługa Google Cloud Key Vault Service na temat zabezpieczeń podczas z urządzenia źródłowego do urządzenia docelowego, tak aby Wiedza nie może być odszyfrowana zdalnie ani używana do zdalnego odblokowywania na każdym z tych urządzeń.
- [C-11-2] MUSI poprosić użytkownika na urządzeniu źródłowym o potwierdzenie współczynnik wiedzy o urządzeniu źródłowym przed przeniesieniem współczynnika wiedzy na urządzenie docelowe.
- [C-11-3] MUSI NA urządzeniu docelowym bez ustawionego podstawowego uwierzytelniania należy poprosić użytkownika o potwierdzenie przekazanego czynnika wiedzy na temat na urządzeniu docelowym przed ustawieniem tego współczynnika wiedzy jako głównego współczynnika wiedzy na temat uwierzytelniania na urządzeniu docelowym oraz przed wszystkie dane przesłane z urządzenia źródłowego.
Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jeden
agentów zaufania, które wywołują interfejs TrustAgentService.grantTrust()
System API z
flagę FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
:
- [C-12-1] MOŻE wywoływać funkcję
grantTrust()
tylko z flagą po połączeniu z w pobliżu urządzenia fizycznego z własnym ekranem blokady, a użytkownik musi uwierzytelnili swoją tożsamość na tym ekranie blokady. Urządzenia zbliżeniowe mogą używać mechanizmów wykrywania na nadgarstku lub kontaktu z ciałem po jednorazowym odblokowaniu urządzenia spełniają wymóg uwierzytelniania użytkownika. - [C-12-2] MUSI umieścić implementację urządzenia w sekcji
TrustState.TRUSTABLE
stanu, gdy ekran jest wyłączony (np. przez naciśnięcie przycisku lub wyświetlacza) przekroczono limit czasu), a agent TrustAgent nie unieważnił zaufania. AOSP jest zadowolony(-a) tego wymogu. - [C-12-3] MUSI przenosić urządzenie tylko z urządzenia
TrustState.TRUSTABLE
doTrustState.TRUSTED
, jeśli agent TrustAgent nadal przyznaje zaufanie na podstawie wymagania określone w kategorii C-12-1. - [C-12-4] MUSI zadzwonić do:
TrustManagerService.revokeTrust()
- po maksymalnie 24 godzinach od przyznania zaufania,
- po 8-godzinnym okresie bezczynności lub
- Jeśli implementacje nie korzystają z kryptograficznie bezpiecznych dokładnego zakresu zgodnie z definicją w dokumencie [C-12-5], gdy podstawowe połączenie z zbliżonego urządzenia fizycznego.
- [C-12-5] Implementacje polegają na bezpiecznym i dokładnym określaniu zakresu, aby
wymagania standardu [C-12-4] MUSZĄ skorzystać z jednego z tych rozwiązań:
- Implementacje korzystające z UWB:
- MUSI spełniać wymagania dotyczące zgodności, certyfikacji, dokładności i wymagania dotyczące kalibracji dla UWB opisanego w 7.4.9.
- MUSI używać jednego z trybów zabezpieczeń P-STS wymienionych w 7.4.9.
- Implementacje z wykorzystaniem sieci wykrywania okolic Wi-Fi (NAN):
- MUSI spełniać wymagania dotyczące dokładności w 2.2.1 [7.4.2.5/H-SR-1], użyj przepustowości 160 MHz (lub i postępuj zgodnie z instrukcjami konfiguracji pomiaru podanymi w Kalibracja obecności
- MUSI używać bezpiecznego LTF zgodnie z definicją w IEEE 802.11az
- Implementacje korzystające z UWB:
Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych wyświetlaczy wirtualnych i obsługę powiązanych danych wejściowych zdarzeń, np. za pomocą VirtualDeviceManager a wyświetlacze nie są oznaczone symbolem VIRTUAL_DISPLAY_FLAG_SECURE, ponieważ:
- [C-13-8] MUSI blokować aktywność z atrybutem android:canDisplayOnRemoteDevices lub meta-data android.activity.can_display_on_remote_devices ustawionym na false, aby nie uruchamiało się na wirtualnym urządzeniu. urządzenia.
- [C-13-9] MUSI blokować aktywność które nie umożliwiają strumieniowego przesyłania danych co oznacza, że wyświetlają treści poufne, w tym za pomocą SurfaceView#setSecure, FLAG_SECURE lub SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS przed zostało uruchomione na urządzeniu wirtualnym.
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 Zastosowanie potencjału ataku według Common Criteria Karty inteligentne.
- [C-1-11] MUSI zawierać oprogramowanie oceniane przez akredytowane w całym kraju laboratorium wykonujące testy na wysokim poziomie potencjalnych luk w zabezpieczeniach według Stosowanie potencjału ataku w przypadku kart inteligentnych (Common Criteria).
- [C-SR-2] Zdecydowanie ZALECANE jest dodanie sprzętu, który oceniane za pomocą celu zabezpieczeń, poziomu zapewniania oceny (EAL) 5, rozszerzony przez AVA_VAN.5. Certyfikat EAL 5 stanie się wymogiem w przyszłej wersji usługi.
- [C-SR-3] Zdecydowanie ZALECANE są zapewnić odporność na atak osób wtajemniczonych (IAR), co oznacza, że osoba wtajemniczona mająca dostęp do podpisywania oprogramowania Klucze nie mogą tworzyć oprogramowania, które powoduje wyciek StrongBox w celu obejścia zabezpieczeń lub w inny sposób umożliwiają dostęp do poufnych danych użytkownika. Zalecany sposób implementacji IAR zezwala na aktualizacje oprogramowania tylko wtedy, gdy główne hasło użytkownika jest udostępniany przez IAuthSecret HAL.
9.11.3 Dane logowania
System danych logowania tożsamości został zdefiniowany i osiągnięty przez wdrożenie wszystkich
Interfejsy API w
android.security.identity.*
pakietu SDK. Te interfejsy API pozwalają deweloperom aplikacji na przechowywanie i pobieranie tożsamości użytkowników
dokumenty. Implementacje na urządzeniach:
- Zdecydowanie ZALECANE jest wdrożenie Dokumentu tożsamości [C-SR-1]. System.
Jeśli implementacje urządzeń implementują system danych logowania tożsamości:
[C-1-1] MUSI zwracać wartość inną niż zero w przypadku IdentityCredentialStore#getInstance() .
[C-1-2] MUSI wdrożyć system danych logowania tożsamości (np.
android.security.identity.*
) za pomocą kodu komunikującego się z zaufanym aplikacji w obszarze, który jest bezpiecznie odizolowany od uruchomionego kodu na jądrze i w nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy za pomocą którego jądro lub kod przestrzeni użytkownika może uzyskać dostęp do wewnętrznego stanu w odizolowanym środowisku, w tym DMA.[C-1-3] Operacje kryptograficzne niezbędne do wdrożenia tożsamości System danych logowania (np. interfejsy API
android.security.identity.*
) MUSI być wyłącznie w zaufanej aplikacji, a materiał klucza prywatnego MUSI nigdy nie opuszczają izolowanego środowiska wykonawczego, chyba że jest to wymagane przez interfejsy API wyższego poziomu (np. createEphemeralKeyPair() ).[C-1-4] Zaufana aplikacja MUSI być zaimplementowana w taki sposób, nie ma wpływu na właściwości zabezpieczeń (np. dane logowania nie są udostępniane jeśli warunki kontroli dostępu nie są spełnione, nie można tworzyć adresów MAC dla dowolne dane), nawet jeśli Android działa w sposób niewłaściwy lub przejęty.
Dodatkowy projekt Android Open Source udostępnia wdrożenie zaufanej aplikacji (libeic), której można użyć do wdrożenia systemu danych logowania tożsamości.
9.12. Usuwanie danych
Wszystkie implementacje na urządzeniach:
- [C-0-1] MUSI udostępniać użytkownikom mechanizm przywracania danych fabrycznych.
- [C-0-2] MUSI usunąć wszystkie dane z systemu plików danych użytkownika podczas wykonywania „Przywracanie danych fabrycznych”.
- [C-0-3] MUSI usuwać dane w taki sposób, by zapewnić standardów branżowych, takich jak NIST SP800-88, Resetuj”.
- [C-0-4] MUSI wywołać powyższy „Przywracanie danych fabrycznych” gdy
DevicePolicyManager.wipeData()
Interfejs API jest wywoływany przez aplikację kontrolera zasad urządzeń głównego użytkownika. - MOŻE udostępnić opcję szybkiego czyszczenia danych, która przeprowadza tylko logiczne usuwanie danych.
9.13. Tryb bezpiecznego rozruchu
Android zapewnia tryb bezpiecznego rozruchu, który umożliwia użytkownikom uruchamianie urządzeń w tym trybie. gdzie mogą działać tylko wstępnie zainstalowane aplikacje systemowe, a wszystkie aplikacje innych firm Aplikacje są wyłączone. Ten tryb, nazywany „trybem bezpiecznego rozruchu”, umożliwia możliwość odinstalowywania potencjalnie szkodliwych aplikacji innych firm.
Implementacje urządzeń:
- [C-SR-1] Zdecydowanie ZALECANE jest wdrożenie trybu bezpiecznego rozruchu.
Jeśli implementacje urządzeń mają włączony tryb bezpiecznego rozruchu:
[C-1-1] MUSI dawać użytkownikowi możliwość włączać bezpiecznego rozruchu w taki sposób, że nie można go przerwać zainstalowane na urządzeniu, chyba że aplikacja innej firmy jest kontroler zasad dotyczących urządzeń i skonfigurował
UserManager.DISALLOW_SAFE_BOOT
flagę jako true (prawda).[C-1-2] MUSI umożliwiać użytkownikowi odinstaluj wszystkie aplikacje innych firm w trybie awaryjnym.
MUSI umożliwiać użytkownikowi włączenie trybu bezpiecznego rozruchu z przy użyciu przepływu pracy innego niż podczas normalnego uruchamiania.
9.14. Izolacja systemu samochodowego
Oczekuje się, że urządzenia z Androidem Automotive będą wymieniać dane z pojazdami o znaczeniu krytycznym podsystemów z wykorzystaniem kodu HAL pojazdu. do wysyłania i odbierania wiadomości w sieciach w pojeździe, takich jak magistrala CAN.
Wymianę danych można zabezpieczyć, implementując funkcje zabezpieczeń poniżej warstwy struktury Androida w celu zapobiegania złośliwej lub niezamierzonej interakcji z aplikacjami, dla tych podsystemów.
9.15. Abonamenty
„Abonamenty” zapoznaj się z podanymi szczegółami abonamentu relacji rozliczeniowych
przez operatora sieci komórkowej za pośrednictwem
SubscriptionManager.setSubscriptionPlans()
Wszystkie implementacje na urządzeniach:
- [C-0-1] MUSI zwracać abonamenty tylko aplikacji operatora komórkowego, która .
- [C-0-2] NIE MOŻESZ zdalnie przesyłać ani tworzyć kopii zapasowych abonamentów.
- [C-0-3] MUSI zezwalać tylko na zastąpienia, takie jak
SubscriptionManager.setSubscriptionOverrideCongested()
w aplikacji operatora komórkowego, który jest obecnie objęty aktualnym abonamentem.
9.16. Migracja danych aplikacji
Jeśli implementacje urządzeń obejmują możliwość migracji danych z urządzenia do z innego urządzenia i nie ograniczaj danych aplikacji do skonfigurowana przez dewelopera aplikacji w pliku manifestu za pomocą android:fullBackupContent, to:
- [C-1-1] NIE MOŻE inicjować przenoszenia danych aplikacji z urządzeń, na których użytkownik nie ustawił podstawowego uwierzytelniania jako opisane w 9.11.1 Bezpieczny ekran blokady i uwierzytelnianie.
- [C-1-2] MUSI bezpiecznie potwierdzić podstawowe uwierzytelnianie u źródła na urządzeniu i potwierdzić zamiar skopiowania danych u użytkownika. urządzenia, zanim jakiekolwiek dane zostaną przesłane.
- [C-1-3] MUSI korzystać z atestu klucza bezpieczeństwa, by zagwarantować, że zarówno źródło, i urządzenie docelowe w migracji między urządzeniami prawidłowe urządzenia z Androidem i zablokowany program rozruchowy.
- [C-1-4] MUSI migrować dane aplikacji tylko do tej samej aplikacji urządzenie docelowe o tej samej nazwie pakietu ORAZ certyfikacie podpisywania.
- [C-1-5] MUSI pokazywać, że na urządzeniu źródłowym znajdują się dane przeniesione przez migrację danych między urządzeniami w menu ustawień. Użytkownik NIE można usunąć tego oznaczenia.
9.17. Platforma wirtualizacji Androida
Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework (android.system.virtualmachine.*
), host Androida:
- [C-1-1] MUSI obsługiwać wszystkie interfejsy API zdefiniowane w
android.system.virtualmachine.*
pakiet. - [C-1-2] NIE MOŻE modyfikować modelu SELinux ani modelu uprawnień Androida dla i zarządzanie chronionymi maszynami wirtualnymi.
- [C-1-3] NIE MOŻE modyfikować, pomijać ani zastępować reguł nigdy znajdujących się w system/sepolicy podany w nadchodzącym projekcie Android Open Source (AOSP), a zasada MUSI skompilować wszystkie obecne reguły „Nigdy nie zezwalaj”.
- [C-1-4] NIE MOŻE zezwalać niezaufanemu kodowi (np. aplikacjom innych firm) na tworzenie i uruchamianie chroniona maszyna wirtualna. Uwaga: może się to zmienić w kolejnych wersjach Androida.
- [C-1-5] NIE MOŻE zezwalać chronionej maszynie wirtualnej na wykonywanie kodu, który nie są częścią obrazu fabrycznego ani ich aktualizacji. Wszystko, co nie jest objęte gwarancją za pomocą weryfikacji podczas uruchamiania Androida (np. plików pobranych z internetu lub nie może być uruchamiana w chronionej maszynie wirtualnej.
Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework (android.system.virtualmachine.*
), dowolna instancja chronionej maszyny wirtualnej:
- [C-2-1] MUSI obsługiwać wszystkie systemy operacyjne dostępne i wirtualizacji APEX w chronionej maszynie wirtualnej.
- [C-2-2] NIE MOŻE uruchamiać systemu operacyjnego chronionej maszyny wirtualnej niepodpisany przez implementatora urządzenia lub dostawcę systemu operacyjnego.
- [C-2-3] NIE MOŻE zezwalać chronionej maszynie wirtualnej na wykonywanie danych jako kodu (np. SELinux nigdy nie zezwala na wykonywanie polecenia).
- [C-2-4] NIE MOŻE modyfikować, pomijać ani zastępować reguł nigdy znajdujących się w system/sepolicy/mikrodroid podany w kodzie open source Androida Project (AOSP).
- [C-2-5] TRZEBA wdrożyć dogłębne mechanizmy obrony chronionej maszyny wirtualnej (np. SELinux w przypadku maszyn pVM) nawet w systemach operacyjnych innych niż Microdroid.
- [C-2-6] MUSI upewnić się, że oprogramowanie układowe pVM nie chce się uruchomić, jeśli nie może przeprowadzić weryfikacji obrazu początkowego.
- [C-2-7] MUSI upewnić się, że oprogramowanie układowe pVM nie chce się uruchomić, jeśli lub instancja.img została zhakowana.
Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework (android.system.virtualmachine.*
), hipernadzorca:
- [C-3-1] NIE MOŻE umożliwiać żadnej maszynie wirtualnej dostępu do strony należącej do innej podmiot (np. inny pVM lub hipernadzorca), chyba że strona wyraźnie go udostępnia właściciela. Obejmuje to hostowaną maszynę wirtualną. Dotyczy to dostępu zarówno do procesora, jak i do DMA.
- [C-3-2] MUSI wyczyścić stronę po użyciu jej przez maszynę wirtualną, ale przed jej zwróceniem. z hostem (np. pVM zostanie zniszczone).
- [C-3-3] MUSI upewnić się, że oprogramowanie układowe pVM zostało załadowane i wykonane przed dowolnego kodu w pVM.
- [C-3-4] MUSI zapewnić, że BCC i CDI zostaną przekazane do instancji pVM tylko wywodzących się z tego konkretnego wystąpienia.
Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework, a potem we wszystkich obszarach:
- [C-4-1] NIE MOŻE udostępniać funkcji maszyny wirtualnej umożliwiającej omijanie Model zabezpieczeń Androida.
Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework, wykonaj te czynności:
- [C-5-1] MUSI obsługiwać izolowaną kompilację aktualizacji środowiska wykonawczego ART.
Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework, to w przypadku zarządzania kluczami:
- [C-6-1] MUSI mieć dostęp do głównego łańcucha DICE w punkcie, którego użytkownik nie może modyfikować, nawet na bez blokady urządzeń. (aby zapewnić ochronę przed podszywaniem się pod inne osoby).
- [C-6-2] MUSI prawidłowo wykonać DICE, tj. podać poprawne wartości.
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 13.
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
Poniżej znajduje się podsumowanie zmian w definicji zgodności w tej wersja:
4 października 2023 roku
2. Typy urządzeń
-
Zobacz wersję
- [9.8/H-1-14] NALEŻY wyświetlać wskaźnik mikrofonu zgodnie z opisem w sekcji 9.8.2
[9.8/C-3-1], gdy pomyślne słowo-klucz zostanie przesłane do głosu
- [9.8/H-1-14] NALEŻY wyświetlać wskaźnik mikrofonu zgodnie z opisem w sekcji 9.8.2
-
Zobacz wersję
[5.1/H-1-7] W przypadku formatu [5.1/H-1-7] opóźnienie inicjowania kodeka musi wynosić maksymalnie 40 ms Sesja kodowania 1080p lub mniejsza w przypadku wszystkich sprzętowych koderów wideo a w trakcie wczytywania. Wczytywanie w tym miejscu jest zdefiniowane jako jednoczesna rozdzielczość od 1080p do 720p w trybie transkodowania tylko wideo za pomocą sprzętowych kodeków wideo Inicjowanie nagrywania dźwięku i obrazu w jakości 1080p. W przypadku kodeka Dolby Vision Opóźnienie inicjowania kodeka MUSI wynosić maksymalnie 50 ms.
[5.1/H-1-12] W przypadku formatu [5.1/H-1-12] opóźnienie inicjowania kodeka musi wynosić maksymalnie 40 ms Sesja dekodowania wideo 1080p lub mniejsza w przypadku wszystkich sprzętowych dekoderów wideo a w trakcie wczytywania. Wczytywanie w tym miejscu jest zdefiniowane jako jednoczesna rozdzielczość od 1080p do 720p w trybie transkodowania tylko wideo za pomocą sprzętowych kodeków wideo Inicjowanie odtwarzania dźwięku i wideo w rozdzielczości 1080p. W przypadku kodeka Dolby Vision opóźnienie inicjowania MUSI wynosić 50 ms lub mniej.
[5.1/H-1-13] W przypadku formatu [5.1/H-1-13] opóźnienie inicjowania kodeka musi wynosić maksymalnie 30 ms Sesja dekodowania dźwięku 128 kb/s lub niższa we wszystkich dekoderach audio, gdy: nie jest wczytywany. Wczytywanie tutaj jest zdefiniowane jako jednoczesny tryb odtwarzania filmów od 1080p do 720p i sesji transkodowania za pomocą sprzętowych kodeków wideo oraz funkcji 1080p. zainicjowanie odtwarzania dźwięku i filmu.
7.4. Połączenia danych
7.4.1.1. Zgodność numerów telefonów:
Zobacz wersję
Jeśli implementacje urządzenia zgłaszają funkcję
android.hardware.telephony.calling
:-
Zobacz wersję
Jeśli implementacje urządzeń zgłaszają
android.hardware.telephony.calling
:
9.11. Klucze i dane logowania
-
Zobacz wersję
jest udostępniany przez IAuthSecret HAL.
Usunięta funkcja IAR stanie się MUSIcznym wymaganiem w Androidzie 14.
26 czerwca 2023 r.
2. Typy urządzeń
-
Usunięto wymagania 7.2.3/H-0-5, 7.2.3/H-0-6, 7.2.3/H-0-7
Inna aktualizacja:
Zobacz wersję
Zdecydowanie ZALECANE jest wykonanie kroków konfiguracji pomiaru podanych w artykule
Wymaganiadotyczące kalibracji obecności.
-
Zobacz wersję
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
3. Oprogramowanie
3.2.3.5 Warunkowe intencje aplikacji
Zobacz wersję
Jeśli implementacje urządzenia zgłaszają android.hardware.telephony.calling
one:android.hardware.telephony
7. Zgodność sprzętu
-
Zobacz wersję
Wymaganiadotyczące kalibracji obecności.
9. Zgodność modelu zabezpieczeń
-
Zobacz wersję
Implementacje na urządzeniach:
[C-0-5] NIE MOŻE przyznawać żadnych uprawnień czasu działania aplikacji
wstępnie zainstalowanejchyba że:- są instalowane w momencie wysyłki urządzenia ORAZ
- Zgodę użytkownika można uzyskać przed złożeniem wniosku
korzysta z
tegouprawnienia,
LUB
- Uprawnienia czasu działania są przyznawane przez
domyślna zasada przyznawania uprawnień
lub pełnienia roli na platformie.
powiązany ze wzorcem intencji, dla których wstępnie zainstalowana aplikacja jest ustawiona jako domyślny moduł obsługi.
-
- Usunęliśmy wymagania [C-13-10] i 9.11.4.
20 marca 2023 r.
2. Typy urządzeń
-
Zobacz wersję
Jeśli aplikacja ustawień implementacji urządzenia mobilnego implementuje dzielonej funkcji, za pomocą umieszczania aktywności, to:
- [
C-17-13.2.3.1/ H-1-1] MUSI mieć działanie, które obsługuje Ustawienia#ACTION_SETTINGS_COMMENTER_DEEP_LINK_ACTIVITY przy włączonej funkcji podziału. Aktywność MUSI być chroniona przezandroid.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
i MUSI rozpocznij aktywność intencji analizowanej z Ustawienia#EXTRA_SETTINGS_COMMENTERDED_DEEP_LINK_INTENT_URI.
Zakończ nowe wymagania
- [
-
Zobacz wersję
Jeśli implementacje urządzeń telewizyjnych z dekoderami sprzętowymi VP9 obsługują ten format i profil dekodowania UHD:
- [5.3.7/T-
2-1SR1] Zdecydowanie ZALECANE jest obsługa dekodowania UHD. profil 2 z szybkością 60 klatek na sekundę (10-bitowa głębia kolorów).
- [5.3.7/T-
-
Zobacz wersję
Implementacje na urządzeniach motoryzacyjnych:
[7.3/A-
0-1SR1] Lokalizacja – łączenie danych 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–20–4] Lokalizacja żądane przez LocationManager#requestLocationUpdates() NIE MOŻE być dopasowana do mapy.
3. Oprogramowanie
-
Zobacz wersję
Konto domyślne dla nowych kontaktów: dostawca kontaktów udostępnia interfejsy API do zarządzania. ustawienia konta domyślnego podczas tworzenia nowego kontaktu.
Jeśli na urządzeniu są wstępnie załadowane aplikacje do obsługi kontaktów, aplikacja:
[C-2-1] MUSI obsługiwać intencję
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
, aby uruchomić interfejs użytkownika wybór konta i zapisanie go w sekcji Dostawca kontaktów, gdy konto zaznaczono.[C-2-2] MUSI uwzględniać domyślne ustawienia konta podczas obsługi
Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
dlaContactsContracts.Contacts.CONTENT_TYPE
iContactsContract.RawContacts.CONTENT_TYPE
, wybierając początkowo koncie.
Zakończ nowe wymagania
3.2.3.5 Warunkowe intencje aplikacji
Zobacz wersję
[Przeniesiono do wersji 2.2.3]
Jeśli aplikacja Ustawienia implementuje komponent dzielonej funkcji, za pomocą umieszczania aktywności, to:
- [C-17-1] MUSI mieć aktywność, która obsługuje
intencja Settings#ACTION_SETTINGS_COMMENTER_DEEP_LINK_ACTIVITY, gdy funkcja podziału jest włączona. Aktywność MUSI być chroniona przez usługę
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
i MUSI rozpocznij aktywność intencji analizowanej z Ustawienia#EXTRA_SETTINGS_COMMENTERDED_DEEP_LINK_INTENT_URI.
Zakończ nowe wymagania
- [C-17-1] MUSI mieć aktywność, która obsługuje
intencja Settings#ACTION_SETTINGS_COMMENTER_DEEP_LINK_ACTIVITY, gdy funkcja podziału jest włączona. Aktywność MUSI być chroniona przez usługę
6. Zgodność narzędzi i opcji dla programistów
6.1. Narzędzia dla programistów
Zobacz wersję
- Małpa
- [C-0-8] MUSI zawierać platformę Monkey i udostępnić ją i aplikacjach.
- Małpa
7. Zgodność sprzętu
-
Zobacz wersję
[Przeniesiono do wersji 7.4.9]
Jeśli implementacje urządzeń obsługują standard 802.1.15.4 i udostępniają aplikacji innej firmy:
- [C-1-1] MUSI zaimplementować odpowiedni interfejs API Androida w pliku android.uwb.
- [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.uwb.
- [C-1-3] MUSI obsługiwać wszystkie odpowiednie profile UWB zdefiniowane w Androidzie implementacji.
- [C-1-4] MUSI udostępniać informacje o produkcie, aby użytkownik mógł przełączyć UWB stanu włączenia/wyłączenia radia.
- [C-1-5] MUSI wymuszać, aby aplikacje korzystające z radia UWB miały uprawnienie UWB_RANGING (w grupie uprawnień NEARBY_devices).
- [C-1-6] Zdecydowanie ZALECANE jest przejście odpowiedniej zgodności i testów certyfikacyjnych zdefiniowanych przez standardowe organizacje, w tym FIRA, CCC i CSA.
Zakończ nowe wymagania
-
Zobacz wersję
Jeśli implementacje urządzeń
obejmują usługi telefoniczne GSM lub CDMA, zgłoś funkcjęandroid.hardware.telephony
, a następnie:- [C-6-1]
SmsManager#sendTextMessage
iSmsManager#sendMultipartTextMessage
MUSI prowadzić do odpowiednich wywołańCarrierMessagingService
na potrzeby obsługi wiadomości tekstowych.SmsManager#sendMultimediaMessage
iSmsManager#downloadMultimediaMessage
MUSI prowadzić do odpowiednich wywołańCarrierMessagingService
udostępniania funkcji wiadomości multimedialnych. - [C-6-2] Wniosek wskazany przez
android.provider.Telephony.Sms#getDefaultSmsPackage
MUSI używać SmsManager Interfejsy API do wysyłania i odbierania SMS-ów i MMS-ów. Dokumentacja AOSP wdrożenia w pakietach/aplikacjach/wiadomościach spełniają to wymaganie. - [C-6-3] Aplikacja, która odpowiada na
Intent#ACTION_DIAL
MUSI obsługiwać wpisywanie dowolnych kodów telefonu w formacie*#*#CODE#*#*
i aktywuje odpowiedniTelephonyManager#ACTION_SECRET_CODE
transmisję. - [C-6-4] Aplikacja odpowiadająca na
Intent#ACTION_DIAL
MUSI używaćVoicemailContract.Voicemails#TRANSCRIPTION
wyświetlanie użytkownikom transkrypcji wizualnej poczty głosowej, jeśli obsługuje ona zapisy tekstowe poczty głosowej. - [C-6-5] MUSI zawierać wszystkie elementy SubscriptionInfo wraz z ich odpowiednikiem
identyfikatory UUID grup
jako pojedynczą subskrypcję we wszystkich widocznych dla użytkowników aprobatach, które wyświetlają
kontrolować informacje na karcie SIM. Przykłady takich afordancji to m.in. ustawienia
które pasują do siebie
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
lubEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
- [C-6-6] NIE MOŻE wyświetlać informacji o subskrypcjach ani umożliwiać kontroli nad nimi za pomocą niepusty identyfikator UUID grupy i oportunistycznym widoczne dla użytkownika, umożliwiać konfigurowanie i kontrolowanie ustawień karty SIM.
Jeśli implementacje urządzenia
obejmują usługę telefonii GSM lub CDMA, zgłośandroid.hardware.telephony
i wyświetl systemowy pasek stanu, a potem:- [C-
6-7-1] MUSI wybrać reprezentatywną aktywną subskrypcję dla danej identyfikator UUID grupy do wyświetlania użytkownikowi w dowolnej wersji, która zapewnia stan karty SIM i informacjami o nich. Przykładami takich afordancji jest pasek stanu komórkowy ikony sygnału lub kafelka szybkich ustawień. - [C-SR-1] Zdecydowanie ZALECANE jest, aby reprezentatywna subskrypcja został wybrany na aktywna subskrypcja danych chyba że urządzenie ma włączony głos podczas której Zdecydowanie ZALECANE jest, aby przedstawiciel subskrypcja to subskrypcja aktywnej usługi Voice.
Jeśli implementacje urządzenia
obejmują usługę telefonii GSM lub CDMA,android.hardware.telephony
, a potem:- [C-6-
87] MUSI być w stanie otwierać się i jednocześnie wykorzystywać maksymalny liczba kanałów logicznych (łącznie 20) dla każdego interfejsu UICC według wytycznych ETSI TS 102 221. - [C-6-
108] NIE MOŻE wykonywać żadnych z poniższych działań w przypadku aktywnych aplikacji operatora (według oznaczeniaTelephonyManager#getCarrierServicePackageName
) automatycznie lub bez wyraźnego potwierdzenia użytkownika:- Anuluj lub ogranicz dostęp do sieci
- Cofnij uprawnienia
- Ogranicz uruchamianie aplikacji w tle lub na pierwszym planie poza dotychczasowe funkcje zarządzania energią dostępne w AOSP
- Wyłączanie i odinstalowywanie aplikacji
Jeśli implementacje urządzenia
obejmują usługę telefonii GSM lub CDMA, zgłoś funkcjęandroid.hardware.telephony
oraz wszystkie aktywne, nieoportunistyczne subskrypcje użytkowników z tym samym identyfikatorem UUID grupy zostaną wyłączone, fizyczne usunięte z urządzenia; lub oznaczone jako oportunistyczne, to urządzenie:- [C-
78-1] MUSI automatycznie wyłączyć wszystkie pozostałe elementy aktywne oportunistyczne subskrypcji w tej samej grupie.
Jeśli implementacje urządzeń obejmują usługę telefonii GSM, ale nie CDMA:
- [C-6-1]