1. Wprowadzenie
W tym dokumencie opisujemy wymagania, które muszą zostać spełnione, aby urządzenie aby była zgodna z Androidem 14.
określenia „MUSI”, „NIE MOŻE”, „WYMAGANE”, „WYMAGANE”, „WOLNE”, „NIE POWINNY”, „POWINNO”, „NIE POWINNO”, „ZALECANE”, „MOŻE” i „OPCJONALNE” jest zgodny ze standardem IETF zdefiniowane w dokumencie RFC2119.
Używana w tym dokumencie „narzędzie do implementacji urządzeń” lub „implementer” jest osobą albo organizacji opracowującej rozwiązanie sprzętowo-oprogramowania z Androidem. 14. „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 14, implementacje MUSZĄ spełniać wymagania przedstawione w tej specyfikacji definicji, w tym wszystkich dokumentów dołączonych przez odniesienie;
Gdzie ta definicja lub testy oprogramowania opisane w sekcja 10 jest cicha, niejednoznaczna lub niekompletna, to osoba implementująca urządzenie odpowiada za dopilnowanie, zgodność z istniejącymi implementacjami.
Z tego powodu projekt Android Open Source jest zarówno referencją, jak i preferowaną implementacją Androida. Urządzenie Zdecydowanie zaleca się, aby wdrażali wyłącznie w największym możliwym stopniu na „dodatku” z kodu źródłowego dostępnego w Projekt Android Open Source. Chociaż niektóre komponenty mogą być hipotetycznie zastąpione alternatywnymi implementacjami, ZDECYDOWANIE NIE zaleca się stosuj się do tej metody, ponieważ zaliczanie testów oprogramowania co jest utrudnione. Obowiązkiem wdrażającego jest dopilnowanie, zgodność behawioralną ze standardową implementacją Androida, w tym i poza platformą Compatibility Test Suite. Niektóre elementy podstawienia i modyfikacji jest wyraźnie zabronione w tym dokumencie.
Wiele zasobów, do których prowadzą linki w tym dokumencie, pochodzi bezpośrednio lub pośrednio z pakietu SDK Androida i będzie działać tak samo jak znajdziesz w dokumentacji tego pakietu SDK. W każdym przypadku, gdy taka zgodność Definicja lub zestaw testów zgodności nie zgadza się z pakietem SDK dokumentacja pakietu SDK jest uznawana za miarodajną. Wszystkie techniczne informacje podane w zasobach w tym dokumencie są które są uwzględnione w tej definicji zgodności.
1.1 Struktura dokumentu
1.1.1 Wymagania według typu urządzenia
Sekcja 2 zawiera wszystkie wymagania dotyczące konkretnego typu urządzenia. Każda podsekcja sekcji 2 jest przeznaczonego na konkretne typy urządzeń.
wszystkie inne wymagania, które obowiązują uniwersalnie na każdym urządzeniu z Androidem; implementacji są wymienione w sekcjach po Sekcji 2. Wymagania te noszą nazwę „Podstawowe wymagania”. w tym dokumencie.
1.1.2 Identyfikator wymagania
W przypadku wymagań MUSZĄ przypisano identyfikator wymagania.
- Identyfikator jest przypisywany tylko w przypadku wymagań MUST.
- Zdecydowanie ZALECANE wymagania są oznaczone jako [SR], ale identyfikator nie jest przypisany.
- Identyfikator składa się z tych elementów : identyfikator typu urządzenia – identyfikator warunku – identyfikator wymagania (np. C-0-1).
Każdy identyfikator jest zdefiniowany poniżej:
- Identyfikator typu urządzenia (więcej informacji znajdziesz w sekcji 2. typy urządzeń)
- C: podstawowy (wymagania dotyczące wszystkich implementacji na urządzeniach z Androidem)
- H: przenośne urządzenie z Androidem
- T: urządzenie z Androidem TV
- O: Wdrożenie Androida Automotive
- W: Implementacja na zegarku Android Watch
- Karta: Implementacja na tabletach z Androidem
- Identyfikator warunku
- Gdy wymaganie jest bezwarunkowe, ten identyfikator ma wartość 0.
- Gdy wymaganie jest warunkowe, za 1 miejsce zostanie przypisana wartość 1 , a liczba zwiększa się o 1 w tej samej sekcji i urządzenia tego samego typu.
- Identyfikator wymagania
- Ten identyfikator rozpoczyna się od 1 i zwiększa o 1 w tej samej sekcji oraz taki sam warunek.
1.1.3 Identyfikator wymagania w sekcji 2
Identyfikatory wymagań w sekcji 2 składają się z 2 części. Pierwszy odpowiada identyfikatorowi sekcji opisanym powyżej. Druga część określa format i wymagania dotyczące konkretnego formatu.
identyfikator sekcji, po którym następuje identyfikator wymagania opisany powyżej.
- Identyfikator podany w sekcji 2 składa się z tych elementów : Identyfikator sekcji / Identyfikator typu urządzenia – Identyfikator warunku – Identyfikator wymagania (np. 7.4.3/A-0-1).
2. Typy urządzeń
Android Open Source Project zapewnia stos oprogramowania, którego można używać do różnych typów urządzeń i formatów. Aby zapewnić bezpieczeństwo urządzeń, stosu oprogramowania, w tym 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ę.
- Mają ekran o przekątnej fizycznym w zakresie od
4 cale
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. - muszą mieć interfejs wprowadzania danych na ekranie dotykowym,
Dodatkowe wymagania opisane w pozostałej części tej sekcji dotyczą Androida Implementacje na urządzeniach mobilnych.
2.2.1. Sprzęt
Implementacje na urządzeniach mobilnych:
- [7.1.1.1/H-0-1] MUSI zawierać co najmniej jeden
Wyświetlacz
zgodny z Androidem, który spełnia wszystkie wymagania opisane w tym dokumencie.wyświetlacz o rozmiarze co najmniej 2,2 cala na krótszej krawędzi i 3,4 cala na dłuższej krawędzi. [7.1.1.3/H-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.
Zacznij nowe wymagania
[7.1.1.1/H-0-3]* MUSI zmapować
UI_MODE_NORMAL
na nieprzesłonięty ekran dostępny dla aplikacji innych firm fizyczny obszar wyświetlania o przekątnej co najmniej 2,2 cala od krótszej krawędzi i 3,4 cala. na dłuższej krawędzi.[7.1.1.3/H-0-1]* MUSI ustawiać wartość
DENSITY_DEVICE_STABLE
musi być o 92% lub więcej od rzeczywistej gęstości fizycznej odpowiedniego wyświetlacza.
Zakończ nowe wymagania
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.
Zacznij nowe wymagania
Jeśli implementacje urządzeń mobilnych obsługują język Vulkan:
- [7.1.4.2/H-1-1] MUSI spełniać wymagania określone w profilu Android Baseline 2021.
Zakończ nowe wymagania
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.
Zacznij nowe wymagania
Jeśli implementacje urządzeń mobilnych zadeklarują FEATURE_BLUETOOTH_LE
:
- [7.4.3/H-1-3] MUSI mierzyć i kompensować Rx
odsunięcie, by mediana BLE RSSI wynosiła -50 dBm +/-15 dB w odległości 1 m od
wysyłającego dane w źródle
ADVERTISE_TX_POWER_HIGH
. - [7.4.3/H-1-4] MUSI przeprowadzać pomiary i zrekompensować potencjalne przychody
w celu zapewnienia, że mediana BLE RSSI wynosi -50 dBm +/-15 dB podczas skanowania
urządzenia referencyjnego umieszczonego w odległości 1 m i wysyłającego na
ADVERTISE_TX_POWER_HIGH
Zakończ nowe wymagania
Jeśli implementacje urządzeń mobilnych obejmują aparat logiczny z listą
za pomocą funkcji
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
one:
- [7.5,4/H-1-1] Domyślnie MUSI mieć normalne pole widzenia. i MUSI mieścić się w przedziale od 50 do stopni.
Implementacje na urządzeniach mobilnych:
- [7.6.1/H-0-1] MUSI zawierać co najmniej 4 GB pamięć nieulotna dostępna na prywatne dane aplikacji (zwane też partycją „/data”).
- [7.6.1/H-0-2] MUSI zwracać wartość „true” 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 300 milisekund lub mniej więcej niż 5 pomiarów, przy średnim odchyleniu bezwzględnym mniejszym niż 30 ms, ponad te ścieżki 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” 300 milisekund lub mniej więcej w co najmniej 5 pomiarach przez głośnik 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]* NALEŻY zastosować wszystkie stałe publiczne dla wyraźny czujnik haptyczny w android.view.HapticfeedbackConstants (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_launch, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_release, CONFIRM, REJECT, GESTURE_START i GESTURE_END).
- [7.10/H]* NALEŻY zastosować wszystkie stałe publiczne dla
wyraźny czujnik haptyczny
w narzędziu android.os.VibrationEffect
mianowicie (EFFECT_TICK, osobiste_KLIKNIJ, 91.05.2014) i
EFFECT_DOUBLE_CLICK) i wszystkie publiczne
Stał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.
- [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.
Liniowy mechanizm rezonansowy (LRA) to jednomasowy system sprężyn częstotliwość rezonansowa dominującej, przy której masa przekłada się w kierunku pożądany ruch.
Jeśli implementacje urządzeń mobilnych obejmują co najmniej jeden ogólny 7.10 rezonansu rezonansowego.
Zacznij nowe wymagania
- [7.10/H] NALEŻY umieścić urządzenie wykonawcze w pobliżu w miejscu, w którym urządzenie jest zazwyczaj trzymane lub dotykane dłońmi.
Zakończ nowe wymagania
- [7,10/godz.]
MUSISZ przesunąć element uruchamiający haptyczny na osi X
(lewa–prawa) naturalnego urządzenia
orientacja pionowa.
Jeśli implementacje urządzeń mobilnych są uniwersalne jest to urządzenie uruchamiające rezonans haptyczny z osią X. Umożliwia ono:
- [7,10/godz.] Częstotliwość rezonansowa jednostki LRA na osi X powinna być mniejsza niż 200 Hz.
Jeśli implementacje urządzeń mobilnych bazują na mapowaniu stałych haptycznych:
- [7.10/H]* MUSI zweryfikować stan implementacji, uruchamiając android.os.Vibrator.areAllEffectsSupported() i android.os.Vibrator.arePrimitivesSupported() 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żety i funkcje widżetów.
- [3.8.1/H-SR-2] Zdecydowanie ZALECANE aby zaimplementować domyślny program uruchamiający, który zapewnia szybki dostęp do dodatkowych, skróty dostępne w aplikacjach innych firm za pomocą menedżera ShortcutManager API.
- [3.8.1/H-SR-3] Zdecydowanie ZALECANE , aby uwzględnić domyślną aplikację uruchamiającą, która wyświetla plakietki przy ikonach aplikacji.
- [3.8.2/H-SR-1] Zdecydowanie ZALECANE z widżetami aplikacji innych firm.
- [3.8.3/H-0-1] MUSI zezwalać na aplikacje innych firm
do powiadamiania użytkowników o ważnych wydarzeniach za pomocą
Notification
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
trasy (na przykład urządzenia Bluetooth i trasy udostępniane do usługi,
MediaRouter2Manager
) gdy aplikacja publikuje powiadomienieMediaStyle
z tokenemMediaSession
.
Zacznij nowe wymagania
Jeśli implementacje urządzeń obejmujące klawisz nawigacyjny funkcji Ostatnie jako opisane w sekcji 7.2.3 dotyczące zmian interfejsu:
- [3.8.3/H-1-1] MUSI umieścić ekran przypinania i udostępniać użytkownikowi menu ustawień, funkcji.
Zakończ nowe wymagania
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 oraz innych określonych polach dostarczonych 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
.
Zacznij nowe wymagania
- [3.8.16/H-1-6] Implementacje na urządzeniach
MUSI dokładnie renderować zarobki użytkownika w następujący sposób:
- Jeśli urządzenie ustawiło
config_supportsMultiWindow=true
, a aplikacja deklaruje metadaneMETA_DATA_PANEL_ACTIVITY
wControlsProviderService
z uwzględnieniem parametru KomponentName prawidłową aktywność (zgodnie z definicją interfejsu API), to aplikacja MUSI umieścić na stronie dla tych użytkowników. - Jeśli aplikacja nie zadeklaruje metadanych
META_DATA_PANEL_ACTIVITY
, MUSI renderować określone pola zgodnie zControlsProviderService
API oraz innych określonych polach dostarczonych przez Kontrolowane interfejsy API.
- Jeśli urządzenie ustawiło
- [3.8.16/H-1-7] Jeśli aplikacja deklaruje metadane
META_DATA_PANEL_ACTIVITY
, MUSI przekazywać wartość ustawienia zdefiniowanego w [3.8.16/H-1-5] za pomocąEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
podczas uruchamiania umieszczonej aktywności.
Zakończ nowe wymagania
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 implementuje dzielonej funkcji, za pomocą umieszczania aktywności, to:
- [3.2.3.1/ H-1-1] MUSI mieć działanie, które obsługuje
intencja Settings#ACTION_SETTINGS_COMMENTER_DEEP_LINK_ACTIVITY, gdy funkcja podziału jest włączona. Aktywność MUSI być chroniona przez 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.
Zacznij nowe wymagania
Jeśli implementacje urządzeń umożliwiają użytkownikom nawiązywanie jakichkolwiek połączeń,
- [7.4.1.2/H-0-1] MUSI zadeklarować flagę funkcji
android.software.telecom
. - [7.4.1.2/H-0-2] MUSI wdrożyć platformę telekomunikacyjną.
Zakończ nowe wymagania
2.2.4 Wydajność i moc
- [8.1/H-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie klatek lub opóźnienie renderowania klatek NIE MOŻE powtarzać się często niż 5 klatek na sekundę, a POWINNA być poniżej 1 klatki na sekundę.
- [8.1/H-0-2] Opóźnienie interfejsu użytkownika. Implementacje urządzeń MUSZĄ zapewniać użytkownikom niewielkie opóźnienia, przewijając lista 10 tys. pozycji zgodnie z definicją zawartą w narzędziu Android Compatibility Test Suite. (CTS) w niecałe 36 sekund.
- [8.1/H-0-3] Przełączanie zadań. Kiedy uruchomiono wiele aplikacji, co powoduje ponowne uruchomienie jednej z już uruchomionych aplikacji. od uruchomienia aplikacji MUSI trwać mniej niż 1 sekundę.
Implementacje na urządzeniach mobilnych:
- [8.2/H-0-1] MUSI zapewniać ciągłość działania z wydajnością zapisu co najmniej 5 MB/s.
- [8.2/H-0-2] MUSI zapewniać losowy zapis z wydajnością co najmniej 0,5 MB/s.
- [8.2/H-0-3] MUSI zapewniać sekwencyjny odczyt z wydajnością co najmniej 15 MB/s.
- [8.2/H-0-4] MUSI zapewniać losowy odczyt z wydajnością co najmniej 3,5 MB/s.
jeśli implementacje urządzeń mobilnych obejmują funkcje zwiększające wydajność urządzenia; funkcji zarządzania uwzględnionymi w AOSP lub rozszerzających dostępne funkcje. w AOSP:
- [8.3/H-1-1] MUSI zapewniać wygodę użytkowników, aby umożliwić i wyłączyć funkcję oszczędzania baterii.
- [8.3/H-1-2] MUSI zapewniać wygodę wyświetlania użytkownikom wszystkich aplikacji, które są wyłączone z trybów czuwania aplikacji i uśpienia.
Implementacje na urządzeniach mobilnych:
- [8.4/H-0-1] MUSI zawierać parametr profil zasilania na komponent, który określa bieżącą wartość zużycia dla każdego elementu sprzętowego i przybliżone zużycie baterii przez zgodnie z opisem w witrynie Android Open Source Project.
- [8.4/H-0-2] MUSI zgłaszać całą zasilanie wartości wykorzystania w miliiamperach godzin (mAh).
- [8.4/H-0-3] MUSI raportować moc procesora
na wykorzystanie identyfikatora UID każdego procesu. W projekcie Android Open Source Project
za pomocą modułu jądra
uid_cputime
. - [8.4/H-0-4] MUSI zapewniać to zużycie energii
dostępne w
adb shell dumpsys batterystats
należy użyć polecenia powłoki do dewelopera aplikacji. - [8.4/H] POWINNY być przypisane do sam komponent sprzętowy, jeśli nie można przypisać wykorzystania energii przez komponent sprzętowy. do aplikacji.
Jeśli implementacje urządzeń mobilnych obejmują wyjście ekranu lub wideo:
- [8.4/H-1-1] MUSI uwzględniać
android.intent.action.POWER_USAGE_SUMMARY
i wyświetli menu ustawień, które pokazuje to zużycie energii.
Implementacje na urządzeniach mobilnych:
- [8.5/H-0-1] MUSI zawierać
aprobatę użytkownika
w menu Ustawieniaaby wyświetlić wszystkie aplikacje z aktywnymi usługami na pierwszym planie lub zadań inicjowanych przez użytkownika, w tym czas trwania każdej z tych usług od momentu rozpoczęcia zgodnie z opisem w dokumentacji pakietu SDK.i zatrzymanie aplikacji działającej na pierwszym planie lub inicjowanym przez użytkownika zadaniu.możliwość zatrzymania aplikacji uruchomionej na pierwszym planie i wyświetlenia wszystkich aplikacji z aktywnymi usługami na pierwszym planie i czasu trwania każdego z tych elementów tych usług od czasu uruchomienia, jak opisano w Dokument pakietu SDK.- Niektóre aplikacje MOGĄ zostać zwolnione z zatrzymania lub umieszczenia w takim aprobatę dla użytkowników zgodnie z opisem w dokumentacji pakietu SDK.
Zacznij nowe wymagania
- [8.5/H-0-2]MUSI zapewniać zaoferowanie użytkownikowi Zatrzymać aplikację uruchomioną na pierwszym planie lub w zadaniu inicjowanym przez użytkownika.
Zakończ nowe wymagania
2.2.5. Model zabezpieczeń
Implementacje na urządzeniach mobilnych:
- [9/H-0-1] MUSI zadeklarować
android.hardware.security.model.compatible
funkcji. - [9.1/H-0-1] MUSI zezwalać aplikacjom innych firm na dostęp do
statystyki użytkowania z użyciem 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.
Zacznij nowe wymagania
Jeśli implementacje urządzeń zadeklarują obsługę android.hardware.telephony
,
one:
- [9.5/H-1-1] NIE MOŻE ustawiać
UserManager.isHeadlessSystemUserMode
dotrue
.
Zakończ nowe wymagania
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.
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.
Zacznij nowe wymagania
Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jednego agenta zaufania, który implementuje systemowy interfejs API TrustAgentService
:
- [9.11.1/H-1-1] MUSI prosić użytkownika o zastosowanie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) częściej niż raz na 72 godziny.
Zakończ nowe wymagania
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.
Zacznij nowe wymagania
Jeśli ustawiono wartość UserManager.isHeadlessSystemUserMode
w implementacjach na urządzeniach mobilnych
do: true
,
- [9.5/H-4-1] NIE MOŻE obsługiwać obsługi eUICC, ani w przypadku kart eSIM z możliwością połączeń.
- [9.5/H-4-2] NIE MOŻE deklarować obsługi
android.hardware.telephony
Zakończ nowe wymagania
Na Androidzie za pośrednictwem interfejsu System API VoiceInteractionService obsługuje mechanizm bezpieczne, zawsze włączone wykrywanie słów-kluczy bez wskaźnika dostępu do mikrofonu i zawsze włączone wykrywanie zapytań, bez mikrofonu i kamery wskaźnik dostępu.
Jeśli implementacje urządzeń mobilnych obsługują interfejs System API
HotwordDetectionService
lub inny mechanizm wykrywania słowa-klucza bez
dostęp do mikrofonu:
- [9.8/H-1-1] MUSI się upewnić, że usługa wykrywania słów-kluczy może przesyłać
dane do systemu,
ContentCaptureService
, lub usługa rozpoznawania mowy na urządzeniu utworzona przezSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-2] MUSI się upewnić, że usługa wykrywania słów-kluczy może przesyłać
z mikrofonu lub danych pozyskanych z tego mikrofonu na serwer systemowy
HotwordDetectionService
API lubContentCaptureService
do Interfejs APIContentCaptureManager
. - [9.8/H-1-3] NIE MOŻE dostarczać dźwięku z mikrofonu dłuższego niż 30 sekund przez żądań wyzwalanych przez sprzęt do usługi wykrywania słów-kluczy.
- [9.8/H-1-4] NIE MOŻE dostarczać buforowanego dźwięku z mikrofonu starszego niż 8 sekund przez do usługi wykrywania słów-kluczy.
- [9.8/H-1-5] NIE MOŻE przekazywać do usługi interakcji głosowej lub podobnego podmiotu.
- [9.8/H-1-6] NIE MOŻE zezwalać na więcej niż 100 bajtów danych są wysyłane poza usługę wykrywania słów-kluczy po każdym udanym działaniu wynik dla słowa-klucza oprócz danych dźwiękowych przekazywanych HotwordAudioStream –
- [9.8/H-1-7] NIE MOŻE zezwalać na przesyłanie więcej niż 5 bitów danych na zewnątrz usługi wykrywania słów-kluczy dla każdego z negatywnych słów-kluczy.
- [9.8/H-1-8] MUSI umożliwiać przesyłanie danych tylko poza słowo-klucz wykrywania w przypadku żądania weryfikacji słowa-klucza otrzymanego od serwera systemu.
- [9.8/H-1-9] NIE MOŻE zezwalać aplikacji instalowanej przez użytkownika na dostarczanie usługi wykrywania słów-kluczy.
- [9.8/H-1-10] NIE MOŻESZ wyświetlać w interfejsie użytkownika danych ilościowych o korzystaniu z mikrofonu przez dzięki usłudze wykrywania słów-kluczy.
- [9.8/H-1-11] MUSI rejestrować liczbę bajtów uwzględnionych w każdej transmisji z usługi wykrywania słów-kluczy, która umożliwia sprawdzenie pod kątem bezpieczeństwa i badań.
- [9.8/H-1-12] MUSI obsługiwać tryb debugowania, który rejestruje nieprzetworzoną zawartość każdego przesyłania z usługi wykrywania słów-kluczy, co pozwala na sprawdzenie i badaczy bezpieczeństwa.
- [9.8/H-1-14] NALEŻY wyświetlać wskaźnik mikrofonu, zgodnie z opisem w sekcji 9.8.2, jeśli udany wynik słowa-klucza zostanie przesłany do głosu usługi interakcji lub podobnego podmiotu.
Zacznij nowe wymagania
- [9.8/H-1-15] MUSI mieć pewność, że strumienie audio zostaną dostarczone po słowie-kluczu są przesyłane w jedną stronę z usługi wykrywania słów-kluczy do usługi interakcji głosowej.
Zakończ nowe wymagania
- [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łowa-klucza bez
wskazaniem użycia mikrofonu, aplikacja:
- [9.8/H-2-1] MUSI zawierać wyraźne powiadomienie o każdym słowie-kluczu obsługiwane.
- [9.8/H-2-2] NIE MOŻE zachowywać nieprzetworzonych danych dźwiękowych ani danych uzyskanych z nich. w usłudze wykrywania słów-kluczy.
- [9.8/H-2-3] NIE MOŻE przesyłać z usługi wykrywania słów-kluczy ani dźwięku
dane, które można wykorzystać do zrekonstruowania (całkowitej lub części) dźwięku,
lub treści audio niezwiązane z samym słowem-kluczem, z wyjątkiem
ContentCaptureService
lub mowa na urządzeniu usługi rozpoznawania twarzy.
Zacznij nowe wymagania
Jeśli implementacje urządzeń mobilnych obsługują interfejs System API
VisualQueryDetectionService
lub inny mechanizm wykrywania zapytań
bez wskazania dostępu do mikrofonu lub aparatu:
- [9.8/H-3-1] MUSI mieć pewność, że usługa wykrywania zapytań może przesyłać tylko
dane do systemu,
ContentCaptureService
lub mowę na urządzeniu usługa rozpoznawania (utworzona przezSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] NIE MOŻE umożliwiać przesyłania żadnych informacji dźwiękowych ani wideo
z
VisualQueryDetectionService
opróczContentCaptureService
lub usługi rozpoznawania mowy na urządzeniu. - [9.8/H-3-3] MUSI wyświetlać w interfejsie systemu powiadomienie użytkownika, gdy urządzenie wykryje użytkownika mają zamiary korzystać z aplikacji Asystent cyfrowy (np.przez przez kamerę).
- [9.8/H-3-4] MUSI wyświetlać wskaźnik mikrofonu i pokazywać wykryte bezpośrednio po wykryciu zapytania użytkownika.
- [9.8/H-3-5] NIE MOŻE zezwalać aplikacji instalowanej przez użytkownika na dostarczanie usługi wizualnego wykrywania zapytań.
Zakończ nowe wymagania
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.T
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania dotyczące multimediów wymienione w sekcji CDD na temat systemu Android 13 (sekcja 2.2.7.1).
Zacznij nowe wymagania
Jeśli implementacje urządzeń mobilnych zwracają wartośćandroid.os.Build.VERSION_CODES.U
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()
metody. - [5.1/H-1-2] MUSI obsługiwać 6 instancji sprzętowego dekodera wideo 8-bitowego (SDR) (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków jednocześnie z 3 sesjami w rozdzielczości 1080p przy 30 kl./s i 3 sesjami w 4K rozdzielczość przy 30 kl./s, chyba że format AV1 Kodeki AV1 są wymagane tylko do obsługi rozdzielczości 1080p, ale nadal są wymagane do obsługi 6 instancji przy 1080p30 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()
metody. - [5.1/H-1-4] MUSI obsługiwać 6 instancji sprzętowego kodera wideo 8-bitowego (SDR) (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków jednocześnie z 4 sesjami w rozdzielczości 1080p przy 30 kl./s i 2 sesjami w 4K rozdzielczość przy 30 kl./s, chyba że format AV1 Kodeki AV1 są wymagane tylko do obsługi rozdzielczości 1080p, ale nadal są wymagane do obsługi 6 instancji przy 1080p30 kl./s.
- [5.1/H-1-5] MUSI reklamować maksymalną liczbę sprzętowych koderów wideo
sesji dekodera, które mogą być uruchamiane równocześnie z użyciem dowolnej kombinacji kodeków za pośrednictwem
CodecCapabilities.getMaxSupportedInstances()
iVideoCapabilities.getSupportedPerformancePoints()
metody. - [5.1/H-1-6] MUSI obsługiwać 6 instancji sprzętowego dekodera wideo 8-bitowego (SDR) i sesji kodera wideo (AVC, HEVC, VP9, AV1 lub nowszego) w dowolnym kombinacja kodeków działających jednocześnie w 3 sesjach przy 4K przy 30 kl./s (z wyjątkiem AV1), przy czym najwyżej 2 to sesje kodera, a 3 sesji w rozdzielczości 1080p. Kodeki AV1 są wymagane tylko do obsługi rozdzielczości 1080p, ale nadal są wymagane do obsługi 6 instancji przy 1080p30 kl./s.
- [5.1/H-1-19] MUSI obsługiwać 3 instancje sprzętowego dekodera wideo 10-bitowego (HDR) i sesji kodera wideo (AVC, HEVC, VP9, AV1 lub nowszego) w dowolnym kombinacja kodeków działających jednocześnie w rozdzielczości 4K przy 30 kl./s (z wyjątkiem AV1). z których najwyżej 1 jest sesją kodera, którą można skonfigurować w Format wprowadzania RGBA_1010102 przez platformę GL. Generowanie metadanych HDR przez koder nie jest wymagany, jeśli jest kodowany z platformy GL. Sesje kodeka AV1 są wymagane tylko do obsługi rozdzielczości 1080p, nawet jeśli wymaga jakości 4K.
- [5.1/H-1-7] W przypadku formatu [5.1/H-1-7] opóźnienie inicjowania kodeka musi wynosić maksymalnie 40 ms Sesja kodowania 1080p lub mniejsza w przypadku wszystkich sprzętowych koderów wideo, gdy nie jest wczytywany. Wczytywanie tutaj jest zdefiniowane jako jednoczesny tryb odtwarzania filmów od 1080p do 720p i sesji transkodowania za pomocą sprzętowych kodeków wideo oraz funkcji 1080p. inicjowania nagrywania audio-wideo. W przypadku kodeka Dolby Vision opóźnienie inicjowania MUSI wynosić 50 ms lub mniej.
- [5.1/H-1-8] W przypadku formatu [5.1/H-1-8] opóźnienie inicjowania kodeka musi wynosić maksymalnie 30 ms Sesja kodowania dźwięku 128 kb/s lub niższa w przypadku wszystkich koderów audio, gdy nie jest wczytywany. Wczytywanie tutaj jest zdefiniowane jako jednoczesny tryb odtwarzania filmów od 1080p do 720p i sesji transkodowania za pomocą sprzętowych kodeków wideo oraz funkcji 1080p. inicjowania nagrywania audio-wideo.
- [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 4K przy 30 kl./s (z wyjątkiem AV1) zarówno w przypadku kart 8-bitowych (SDR), jak i tych 8-bitowych 10-bitowy film HDR. Sesje kodeka AV1 są wymagane tylko do obsługi rozdzielczości 1080p, nawet jeśli wymaga jakości 4K.
- [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 jednoczesne działanie 3 sesji w rozdzielczości 4K przy 30 kl./s (z wyjątkiem AV1), obejmuje 1 bezpieczną sesję dekodera i 1 sesję z zabezpieczeniem NW w 1080p rozdzielczość przy 30 kl./s, przy czym maksymalnie 2 sesje mogą odbywać się w 10-bitowym trybie HDR. Sesje kodeka AV1 są wymagane tylko do obsługi rozdzielczości 1080p, nawet jeśli wymaga jakości 4K.
- [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, Level 4.1) i film ziarna.
- [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 (tj.krócej niż 0,167% utraty klatki) podczas wczytywania sesji wideo 4K 60 kl./s.
- [5.3/H-1-2] W trakcie filmu NIE MOŻE upuścić więcej niż 1 klatki na 10 sekund zmiana rozdzielczości podczas wczytywania sesji wideo z prędkością 60 kl./s w przypadku sesji 4K.
- [5.6/H-1-1] Opóźnienie reakcji na dotknięcie to 80 milisekund lub mniej. który jest dostępny w narzędziu CTS Verifier.
- [5.6/H-1-2] MUSI mieć opóźnienie w obie strony wynoszące 80 milisekund lub w przypadku co najmniej 1 obsługiwanej ścieżki danych.
- [5.6/H-1-3] 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 przez USB audio, jeśli są obsługiwane w całej transmisji danych.
dla konfiguracji z krótkim czasem oczekiwania i strumieniem strumieniowania. Krótki czas oczekiwania
AAudio powinna być używana przez aplikację w wywołaniu zwrotnym z krótkim czasem oczekiwania
i trybu uzyskiwania zgody. Do konfiguracji strumieniowego przesyłania danych należy użyć funkcji Java AudioTrack
aplikację. Zarówno w konfiguracji z krótkim czasem oczekiwania, jak i w konfiguracji strumieniowania HAL
ujście wyjściowe powinno akceptować
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
lubAUDIO_FORMAT_PCM_FLOAT
dla docelowego formatu wyjściowego. - [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 ze standardem klasy i zadeklarować Flaga funkcji MIDI.
- [5.6/H-1-9] MUSI obsługiwać co najmniej 12-kanałowy miksowanie. Oznacza to, że aby uruchomić ścieżkę audio z maską 7.1.4 kanału przestrzennego lub typu Downmix wszystkich kanałów do stereo.
- [5.6/H-SR] Zdecydowanie ZALECANE jest obsługa 24-kanałowego miksowania za pomocą co najmniej obsługują maski kanału 9.1.6 i 22.2.
- [5.7/H-1-2] MUSI obsługiwać tag
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
z poniżej funkcji odszyfrowywania treści.
Minimalny rozmiar próbki | 4 MiB |
Minimalna liczba próbek podrzędnych – H264 lub HEVC | 32 |
Minimalna liczba próbek podrzędnych – VP9 | 9 |
Minimalna liczba próbek podrzędnych – AV1 | 288 |
Minimalny rozmiar bufora próbki podrzędnego | 1 MiB |
Minimalny rozmiar ogólnego bufora kryptograficznego | 500 KiB |
Minimalna liczba równoczesnych sesji | 30 |
Minimalna liczba kluczy na sesję | 20 |
Minimalna łączna liczba kluczy (wszystkie sesje) | 80 |
Minimalna łączna liczba kluczy DRM (wszystkie sesji) | 6 |
Rozmiar wiadomości | 16 KiB |
Odszyfrowane klatki na sekundę | 60 kl./s |
- [5.1/H-1-17] MUSI mieć co najmniej jeden sprzętowy dekoder obrazu obsługujący format AVIF Profil podstawowy.
- [5.1/H-1-18] MUSI obsługiwać koder AV1, który potrafi kodować do 480p. 30 kl./s i 1 Mb/s.
[5.12/H-1-1] MUSI[5.12/H-SR] Zdecydowanie zalecamy wsparcieFeature_HdrEditing
dla wszystkich sprzętowych koderów AV1 i HEVC dostępnych na urządzeniu.- [5.12/H-1-2] MUSI obsługiwać format kolorów RGBA_1010102 dla całego sprzętu AV1 i Urządzenie zawiera kodery HEVC.
- [5.12/H-1-3] MUSISZ reklamować obsługę rozszerzenia EXT_YUV_target w próbkę z tekstur YUV w 8 i 10-bitach.
- [7.1.4/H-1-1] W przetwarzaniu wyświetlacza MUSI mieć co najmniej 6 nakładek sprzętowych (DPU), przy czym co najmniej 2 z nich mogą wyświetlać 10-bitową treść wideo.
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.U
dla
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
oraz obejmują
obsługi sprzętowego kodera AVC lub HEVC, wówczas:
- [5.2/H-2-1] MUSI osiągnąć minimalną docelową jakość określoną w filmie. krzywe zniekształcenia szybkości kodera dla sprzętowych kodeków AVC i HEVC, zgodnie z definicją Przeprowadź testy jakości kodowania wideo (VEQ) w klasie wydajności 14 (PC14).
Zakończ nowe wymagania
2.2.7.2. Aparat
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.T
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania dotyczące multimediów wymienione w sekcji CDD na temat systemu Android 13 (sekcja 2.2.7.2).
Zacznij nowe wymagania
Jeśli implementacje urządzeń mobilnych zwracają wartośćandroid.os.Build.VERSION_CODES.U
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 6 megapikseli i umożliwia nagrywanie filmów w rozdzielczości 1080p przy 30 kl./s. Podstawowy przedni aparat to przedni aparat z najniższym identyfikatorem.
- [7.5/H-1-3] MUSI obsługiwać właściwość
android.info.supportedHardwareLevel
jakoFULL
lub więcej dla tylnej głównej iLIMITED
lub lepszej dla głównej części głównej aparat fotograficzny. - [7.5/H-1-4] MUSI obsługiwać
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
dla obu domen kamery. - [7.5/H-1-5] MUSI mieć opóźnienie na zapis w formacie JPEG w aparacie2 < 1000
900ms dla rozdzielczości 1080p mierzonej w teście wydajności kamery CTS w Warunki oświetleniowe ITS (3000 K) dla obu głównych kamer. - [7.5/H-1-6] MUSI mieć opóźnienie na uruchomienie kamery2 (otwórz aparat, aby wyświetlić pierwszy podgląd ramka) < 500 ms na podstawie wyników testu wydajności kamery CTS przeprowadzonego przez ITS warunków oświetleniowych (3000 K) obu aparatów głównych.
- [7.5/H-1-8] MUSI obsługiwać
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
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] MUSI zaimplementować równoczesne przesyłanie strumieniowe z przodu na stronie głównej kamery.
- [7.5/H-1-12] MUSI obsługiwać
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
dla obu domen przedni i główny tylny aparat. - [7.5/H-1-13] MUSI obsługiwać funkcję
LOGICAL_MULTI_CAMERA
dla głównego tylnego aparatu, jeśli masz więcej niż 1 RGB przez tylne aparaty. - [7.5/H-1-14] MUSI obsługiwać
STREAM_USE_CASE
w przypadku przedni i główny tylny aparat. - [7.5/H-1-15] MUSI obsługiwać
Bokeh iRozszerzenia trybu nocnego dla rozszerzeń podstawowych z AparatuX i Aparatu2 kamery. - [7.5/H-1-16] MUSI obsługiwać funkcję DYNAMIC_RANGE_TEN_BIT w kamery.
- [7.5/H-1-17] MUSI obsługiwać tryb control_SCENE_MODE_FACE_PRIORITY i wykrywanie twarzy (STATISTICS_FACE_DETECT_MODE_SIMPLE lub STATISTICS_FACE_DETECT_MODE_FULL) dla aparatów głównych.
Zakończ nowe wymagania
2.2.7.3 Sprzęt
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.T
dla
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania dotyczące multimediów wymienione w sekcji CDD na temat systemu Android 13 (sekcja 2.2.7.3).
Zacznij nowe wymagania
Jeśli implementacje urządzeń mobilnych zwracają wartośćandroid.os.Build.VERSION_CODES.U
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.1.1.3/H-3-1] MUSI mieć wyświetlacz HDR obsługujący co najmniej 1000 nitów średnią.
- [7.6.1/H-2-1] MUSI mieć co najmniej 8 GB pamięci fizycznej.
Zakończ nowe wymagania
2.2.7.4. Wydajność
Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.T
dla
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania dotyczące wydajności wymienione w sekcji CDD Androida 13 w sekcji 2.2.7.4.
Zacznij nowe wymagania
Jeśli implementacje urządzeń mobilnych zwracają wartośćandroid.os.Build.VERSION_CODES.U
dla
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- [8.2/H-1-1] MUSI zapewniać wydajność sekwencyjnego zapisu na poziomie co najmniej 150 MB/s.
- [8.2/H-1-2] MUSI zapewniać wydajność zapisu przy losowym połączeniu z szybkością co najmniej 10 MB/s.
- [8.2/H-1-3] MUSI zapewniać wydajność sekwencyjnego odczytu co najmniej 250 MB/s.
- [8.2/H-1-4] MUSI zapewniać wydajność losowego odczytu z szybkością co najmniej 100 MB/s.
- [8.2/H-1-5] MUSI zapewniać równoległą wydajność sekwencyjnego odczytu i zapisu z 2-krotnie większą wydajnością odczytu i 1-krotnego zapisu z szybkością co najmniej 50 MB/s.
Zakończ nowe wymagania
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ć HDMI
tryb wyjściowy na najwyższą rozdzielczość dla wybranego obsługiwanego formatu piksela
z częstotliwością odświeżania 50 Hz lub 60 Hz dla wyświetlacza zewnętrznego w zależności od filmu
częstotliwość odświeżania w regionie, w którym jest sprzedawane urządzenie.
MUSISZ 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. - [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] POWINNA być przypisana do sam komponent sprzętowy, jeśli nie można przypisać wykorzystania energii przez komponent sprzętowy. do aplikacji.
- [8.4/T-0-4] MUSI zapewniać to zużycie energii
dostępne w
adb shell dumpsys batterystats
należy użyć polecenia powłoki do dewelopera aplikacji.
2.3.5 Model zabezpieczeń
Implementacje na urządzeniach telewizyjnych:
- [9/T-0-1] MUSI zadeklarować
android.hardware.security.model.compatible
funkcji. - [9.11/T-0-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
- [9.11/T-0-2] MUSI zawierać implementacje RSA, AES, algorytmy kryptograficzne ECDSA i HMAC oraz rodzina MD5, SHA1 i SHA-2 funkcji skrótu do prawidłowej obsługi które są bezpiecznie odizolowane od kodu działającego na na jądrze i w nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy za pomocą którego jądro lub kod przestrzeni użytkownika może uzyskać dostęp do wewnętrznego stanu w odizolowanym środowisku, w tym DMA. Starsze oprogramowanie typu open source na Androida Projekt (AOSP) spełnia to wymaganie dzięki wdrożeniu Trusty. Rozwiązanie oparte na technologii ARM TrustZone lub zewnętrzne sprawdzone wdrożenie prawidłowej izolacji opartej na hipernadzorcy to alternatywne rozwiązanie .
- [9.11/T-0-3] MUSI obsługiwać ekran blokady w izolowanym środowisku wykonawczym i tylko wtedy, gdy pomyślne, zezwól na używanie kluczy powiązanych z uwierzytelnianiem. Ekran blokady dane logowania MUSZĄ być przechowywane w sposób umożliwiający wyłącznie izolowane uruchomienie aby przeprowadzić uwierzytelnianie przy zablokowanym ekranie. Nadrzędny Android Projekt open source zapewnia Warstwa abstrakcji sprzętowej bramy (HAL) i Trusty. Można je wykorzystać, aby spełnić to wymaganie.
- [9.11/T-0-4] MUSI obsługiwać atest klucza, w którym klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie to i bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby można było użyć kluczy jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie ten sam klucz atestu,chyba że zostało z całego świata. Jeśli wyprodukowana zostanie ponad 100 000 sztuk danego kodu SKU, klucz MOŻE zostać użyty na każde 100 000 jednostek.
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 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.
Zacznij nowe wymagania
Jeśli implementacje na zegarkach obsługują interfejs Vulkan:
- [7.1.4.2/W-1-1] MUSI spełniać wymagania określone w profilu Android Baseline 2021.
Zakończ nowe wymagania
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.
Zacznij nowe wymagania
Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jednego agenta zaufania, który implementuje systemowy interfejs API TrustAgentService
:
- [9.11.1/W-1-1] MUSI prosić użytkownika o zastosowanie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) częściej niż raz na 72 godziny.
Zakończ nowe wymagania
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 zawierać funkcję Home i MOŻE 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 Sensor typy lub identyfikatory nieruchomości pojazdów .
[7.3/A-0-4] Lokalizacja żądane za pomocą funkcji LocationManager#requestLocationUpdates() NIE MOŻE być dopasowana do mapy.
[7.3.1/A-0-4] MUSI być zgodna z układ współrzędnych czujnika samochodowego.
[7.3/A-SR-1] Są STRONGLY_RECOMMENDENDED 3-osiowy akcelerometr i 3-osiowy żyroskop.
[7.3/A-SR-2] Ssilnie_ZALECANE jest wdrożenie i raportowanie Czujnik
TYPE_HEADING
.
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.
Zacznij nowe wymagania
Jeśli implementacje urządzeń z Androidem obsługują język Vulkan:
- [7.1.4.2/A-1-1] MUSI spełniać wymagania określone w profilu Android Baseline 2021.
Zakończ nowe wymagania
Jeśli implementacje urządzeń motoryzacyjnych zawierają akcelerometr:
- [7.3.1/A-1-1] MUSI zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr:
- [7.3.1/A-SR-1] Zdecydowanie ZALECANE jest wdrożenie akcelerometru kompozytowego dla akcelerometru o ograniczonych osiach.
Jeśli implementacje urządzeń motoryzacyjnych obejmują akcelerometr z wartością mniejszą niż 3 osie:
- [7.3.1/A-1-3] MUSI wdrożyć i raportować
Czujnik
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] MUSI wdrożyć i raportować
Czujnik
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Jeśli żyroskop obejmuje urządzenia motoryzacyjne:
- [7.3.4/A-2-1] MUSI zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
- [7.3.4/A-2-3] MUSI być w stanie mierzyć zmiany orientacji ekranu. do 250 stopni na sekundę.
- [7.3.4/A-SR-1] Zdecydowanie ZALECANE jest skonfigurowanie żyroskopu w zakresie pomiarowym do +/-250 dps w celu maksymalizacji rozdzielczości. jak to tylko możliwe.
Jeśli implementacje urządzeń samochodowych obejmują 3-osiowy żyroskop:
- [7.3.4/A-SR-2] Zdecydowanie ZALECANE jest wdrożenie żyroskop z komponentem dla żyroskopu z ograniczonymi osiami.
Jeśli implementacje urządzeń w branży motoryzacyjnej obejmują żyroskop z mniej niż 3 osiami:
- [7.3.4/A-4-1] MUSI wdrożyć i raportować
Czujnik
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] MUSI wdrożyć i raportować
Czujnik
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
jeśli implementacje urządzeń samochodowych obejmują odbiornik GPS/GNSS, obejmują komórkową transmisję danych za pomocą sieci komórkowej, to:
- [7.3.3/A-3-1] MUSI określić lokalizację za pierwszym razem. odbiornik GPS/GNSS zostanie włączony lub upłynie ponad 4 dni w ciągu 60 sekund.
- [7.3.3/A-3-2] MUSI spełniać kryteria dotyczące czasu do pierwszej poprawki zgodnie opisane w artykułach 7.3.3/C-1-2 i 7.3.3/C-1-6 w przypadku wszystkich pozostałych próśb o lokalizację (tj.próśb, które nie są wysyłane po raz pierwszy) w dowolnym momencie lub po upływie 4+ dni). Wymaganie 7.3.3/C-1-2 to spotykane zwykle w pojazdach bez łączności komórkowej używanej do transmisji danych. wykorzystując prognozy orbity GNSS obliczone na odbiorniku lub ostatnią znaną lokalizację pojazdu wraz z możliwością realizacji transakcji co najmniej 60 sekund z satysfakcjonującą dokładnością pozycji 7.3.3/C-1-3 lub ich połączenie.
Jeśli implementacje urządzeń samochodowych obejmują czujnik TYPE_HEADING
:
- [7.3.4/A-4-3] MUSI zgłaszać zdarzenia z częstotliwością co najmniej 1 Hz.
- [7.3.4/A-SR-3] STRONGLY_RECOMMENDED raportowania zdarzeń do co najmniej 10 Hz.
- POWINNA odnosić się do rzeczywistej północy.
- POWINNA być dostępna, nawet gdy pojazd jest nieruchomy.
- Wymagana jest rozdzielczość co najmniej 1 stopnia.
Implementacje na urządzeniach motoryzacyjnych:
- [7.4.3/A-0-1] MUSI obsługiwać Bluetooth i POWINNO obsługują Bluetooth LE.
- [7.4.3/A-0-2] Implementacje w Androidzie Automotive
MUSI obsługiwać te profile Bluetooth:
- Nawiązywanie połączeń telefonicznych przez profil HFP.
- Odtwarzanie multimediów przez profil dystrybucji dźwięku (A2DP).
- Sterowanie odtwarzaniem multimediów w profilu pilota (AVRCP).
- Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).
[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.
Zacznij nowe wymagania
czy urządzenia obsługują odbiornik radiowy AM/FM i funkcje w dowolnej aplikacji:
- [7,4
,10/A-0-1] Trzeba zadeklarować obsługęFEATURE_BROADCAST_RADIO
.
Zakończ nowe wymagania
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.
Zacznij nowe wymagania
Tylny aparat oznacza kamerę „w kierunku świata”, którą można umieścić w dowolnym znajduje się na pojeździe i jest zwrócony na zewnątrz kabiny pojazdu; czyli np. obrazu z kamery tylnej.
Przedni aparat oznacza kamerę dla użytkownika, która znajduje się w każdym znajduje się na pojeździe i jest zwrócony do wnętrza kabiny pojazdu; to wszystko obrazów użytkownika, np. do wideokonferencji i podobnych aplikacji.
Implementacje na urządzeniach motoryzacyjnych:
- [7.5/A-SR-1] Zdecydowanie ZALECANE jest dodanie przynajmniej jednego widoku skierowanego do świata kamery.
- MOŻE zawierać co najmniej 1 kamerę skierowanym do użytkownika.
- [7.5/A-SR-2] Zdecydowanie ZALECANE jest umożliwienie jednoczesnej transmisji dla wielu kamer.
Jeśli implementacje urządzeń mobilnych obejmują co najmniej jeden aparat, w kierunku całego świata, w przypadku takiego aparatu:
- [7.5/A-1-1] MUSI być zorientowana tak, by długi wymiar kamery był taki sam. z płaszczyzną X-Y osi czujnika samochodowego w Androidzie.
- [7.5/A-SR-3] Zdecydowanie ZALECANE jest użycie stałej ostrości lub EDOF. (rozszerzona głębia ostrości).
- [7.5/A-1-2] MUSI mieć główny aparat skierowany na świat z najniższym identyfikatorem.
Jeśli implementacje urządzeń mobilnych obejmują co najmniej jeden aparat, dla użytkownika, w przypadku takiego aparatu:
- [7.5/A-2-1] Główny aparat skierowany do użytkownika MUSI być aparatem skierowanym do użytkownika z najniższym identyfikatorem kamery.
- MOŻE być zorientowane w taki sposób, aby długi wymiar kamery był zgodny z wymiarami X i Y. płaszczyzny czujników w samochodach z Androidem.
jeśli wdrożenia urządzeń w branży motoryzacyjnej obejmują aparat dostępny
android.hardware.Camera
lub android.hardware.camera2
API, wówczas:
- [7.5/A-3-1] MUSI być zgodny z podstawowymi wymaganiami dotyczącymi aparatu podanymi w sekcji 7.5.
jeśli implementacje urządzeń samochodowych zawierają niedostępną kamerę,
za pomocą interfejsu API android.hardware.Camera
lub android.hardware.camera2
, a następnie
one:
- [7.5/A-4-1] MUSI być dostępny w usłudze Extended View System.
jeśli implementacje urządzeń w branży motoryzacyjnej obejmują co najmniej jedną kamerę dostępną przez Usługa systemu Extended View (Rozszerzony widok) w przypadku takiego aparatu:
- [7.5/A-5-1] NIE MOŻE obracać obrazu z kamery ani wyświetlać jego odbicia lustrzanego w poziomie.
- [7.5/A-SR-4] Zdecydowanie ZALECANE jest ustawienie rozdzielczości co najmniej 1,3. megapiksela.
Jeśli implementacje urządzeń samochodowych zawierają co najmniej jedną kamerę,
dostępne zarówno przez usługę Extended View System, jak i android.hardware.Camera
lub interfejsu API android.hardware.Camera2
, a następnie w przypadku takiej kamery:
- [7.5/A-6-1] MUSI zgłosić ten sam identyfikator aparatu.
Jeśli implementacje urządzeń motoryzacyjnych udostępniają zastrzeżony interfejs API aparatu:
- [7.5/A-7-1] NALEŻY zaimplementować taki interfejs API aparatu za pomocą
android.hardware.camera2
API lub interfejs Extended View System API.
Zakończ nowe wymagania
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.
Zacznij nowe wymagania
- [3.8/A-0-1] NIE MOŻE zezwalać użytkownikom z pełnym dostępem pomocniczym, którzy nie są obecnymi użytkownikami na pierwszym planie, na uruchamianie działań i uzyskiwanie dostępu do interfejsu użytkownika na wyświetlaczu.
Zakończ nowe wymagania
[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.
Zacznij nowe wymagania
Jeśli implementacje na urządzeniach motoryzacyjnych zadeklarują android.hardware.microphone
,
one:
- [9.8.2/A-1-1] MUSI wyświetlać wskaźnik mikrofonu, gdy
aplikacja uzyskuje dostęp do danych dźwiękowych z mikrofonu, ale nie wtedy, gdy
dostęp do mikrofonu mają tylko
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
lub aplikacje pełniące role nazywane w artykuł 9.1 z identyfikatorem CDD [C-4-X]. - [9.8.2/A-1-2] NIE MOŻE ukrywać wskaźnika mikrofonu w aplikacje systemowe z widocznymi interfejsami lub bezpośrednią interakcją użytkownika.
- [9.8.2/A-1-3] MUSI umożliwiać użytkownikom przełączanie mikrofon w aplikacji Ustawienia.
Zakończ nowe wymagania
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 zgodnie z definicją
wskazanąw Uprawnienia art. 9.1 z identyfikatorem CDD [C-4-X][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.
Zacznij nowe wymagania
- [9.8.2/A-2-3] MUSI zapewniać użytkownikowi możliwość przełączania aparatu w aplikacji Ustawienia.
- [9.8.2/A-2-4] MUSI wyświetlać ostatnie i aktywne aplikacje z aparatem w takiej postaci, w jakiej został zwrócony
od
PermissionManager.getIndicatorAppOpUsageData()
oraz wszystkie wiadomości o atrybucji.
Zakończ nowe wymagania
Implementacje na urządzeniach motoryzacyjnych:
- [9/A-0-1] MUSI zadeklarować
android.hardware.security.model.compatible
funkcji. - [9.11/A-0-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
- [9.11/A-0-2] MUSI zawierać implementacje RSA, AES, algorytmy kryptograficzne ECDSA i HMAC oraz rodzina MD5, 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.
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.
Zacznij nowe wymagania
- [C-0-8] NIE MOŻE obsługiwać instalowania aplikacji kierowanych na poziom API mniej niż 23.
Zakończ nowe wymagania
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 dozwolone dla Androida 14. |
WERSJA.SDK | Wersja obecnie uruchomionego systemu Android w formacie kod aplikacji innej firmy. W przypadku Androida 14: to pole MUSI mieć wartość całkowitą 14_INT. |
VERSION.SDK_INT | Wersja obecnie uruchomionego systemu Android w formacie kod aplikacji innej firmy. W przypadku Androida 14: to pole MUSI mieć wartość całkowitą 14_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 Bezpieczeństwo publiczne Androida Newsletter lub Usługa Android Security Advisory, na przykład „2015-11-01”. |
PODSTAWY_systemu operacyjnego | Wartość reprezentująca parametr FINGERINSERT w kompilacji, która jest są identyczne z tą kompilacją, z wyjątkiem poprawek dostarczonych w Biuletyn o bezpieczeństwie w Androidzie. MUSI podawać prawidłową wartość i jeśli taka kompilacja nie istnieje, zgłoś pusty ciąg znaków („”). |
WŁAŚCICIEL MOTYWACYJNY | Wartość wybrana przez mechanizm implementujący urządzenie, identyfikujący konkretny wewnętrznej wersji programu rozruchowego używanej w urządzeniu w formacie zrozumiałym dla człowieka. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasować do wyrażenie regularne „^[a-zA-Z0-9._-]+$”. |
getRadioVersion() | MUSI (być lub zwracać) wartość wybraną przez mechanizm implementujący urządzenie określającą wewnętrzną wersję radia/modema używaną w urządzeniu, w formacie zrozumiałym dla człowieka. Jeśli urządzenie nie ma żadnych wewnętrznych radio/modem MUSI zwracać wartość NULL. Wartość w tym polu MUSI być możliwe do zakodowania jako 7-bitowego kodu ASCII i pasujące do wyrażenia regularnego „^[a-zA-Z0-9._-,]+$”. |
getSerial(), | MUSI (być lub zwracać) numer seryjny sprzętu, który MUSI być dostępny i unikalny na wszystkich urządzeniach z tym samym modelem MODEL i MANUFACTURER. Wartość to pole MUSI być zakodowane jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9]+$”. |
3.2.3 Zgodność intencji
3.2.3.1. Częste intencje Application Intents
Intencje w Androidzie umożliwiają komponentom aplikacji żądanie funkcji z innymi komponentami Androida. Projekt nadrzędny na Androida zawiera listę które implementują kilka wzorców intencji w celu wykonywania typowych działań.
Implementacje na urządzeniach:
- [C-SR-1] Zdecydowanie ZALECANE jest wstępne wczytanie jednej lub większej liczby aplikacji lub komponenty usługi z modułem obsługi intencji dla wszystkich filtrów intencji publicznych zdefiniowane przez te intencje aplikacji wymienione tutaj i dostarczanie realizacji, tj. spełnianie wymagań programisty w zakresie dla intencji aplikacji, zgodnie z opisem w pakiecie SDK.
Obowiązkowe intencje aplikacji znajdziesz w Sekcji 2. dla każdego typu urządzenia.
3.2.3.2. Rozwiązanie intencji
[C-0-1] Android jest rozszerzoną platformą, dlatego implementacje urządzeń MUSZĄ zezwól na każdy wzorzec intencji, o którym mowa w sekcji 3.2.3.1. , z wyjątkiem Ustawienia, aby zostały zastąpione przez aplikacje innych firm. pozwala na to domyślnie implementacja open source Androida.
[C-0-2] Moduły implementujące urządzenie NIE MOGĄ przypisywać specjalnych uprawnień do systemu aplikacji wykorzystywania tych wzorców intencji lub uniemożliwiać korzystanie z aplikacji innych firm. od wiązania do nich i przejmowania nad nimi kontroli. Ten zakaz obejmuje m.in. wyłączenie użytkownika „Wybór” który pozwala użytkownikowi wybierać spośród wielu aplikacji, obsługują ten sam wzorzec intencji.
[C-0-3] Implementacje urządzeń MUSZĄ zapewniać użytkownikom interfejs zmienić domyślną aktywność na potrzeby intencji.
Jednak implementacje na urządzeniach MOGĄ wyświetlić domyślne działania dla określonych URI (np. http://play.google.com), jeśli aktywność domyślna to bardziej szczegółowego atrybutu identyfikatora URI danych. Na przykład wzorzec filtra intencji Identyfikator URI danych „http://www.android.com” jest bardziej szczegółowy niż podstawowy wzorzec intencji przeglądarki dla „http://”.
Android zawiera również mechanizm deklarowania przez aplikacje innych firm domyślne linki do aplikacji dla określonych typów intencji identyfikatora URI. Gdy takie wiarygodne deklaracje są zdefiniowane we wzorach filtra intencji aplikacji, implementacje urządzeń:
- [C-0-4] MUSI próbować zweryfikować filtry intencji, wykonując metodę kroki weryfikacji opisane w specyfikacji linków do zasobów cyfrowych. zgodnie z implementacją za pomocą menedżera pakietów w nadrzędnym środowisku open source Androida. Projekt.
- [C-0-5] MUSI próbować zweryfikować filtry intencji podczas instalacji aplikacji oraz ustaw wszystkie poprawnie zweryfikowane filtry intencji URI na domyślnych modułów obsługi aplikacji dla ich identyfikatorów URI.
- MOŻE ustawić konkretne filtry intencji URI jako domyślne moduły obsługi aplikacji dla ich identyfikatorów URI po pomyślnej weryfikacji, ale niepowodzenie innych filtrów URI kandydatów weryfikacji. Jeśli tak jest, MUSI zawierać parametr odpowiednich dla użytkownika w menu ustawień.
- MUSI udostępniać w Ustawieniach opcje linków dla poszczególnych aplikacji jako
następujące:
- [C-0-6] Użytkownik MUSI mieć możliwość całościowego zastąpienia domyślnej aplikacji zachowanie linków w aplikacji: zawsze otwieraj, zawsze pytaj lub nigdy nie otwieraj, który musi mieć zastosowanie do wszystkich kandydujących filtrów intencji URI.
- [C-0-7] Użytkownik MUSI zobaczyć listę intencji URI kandydata filtry.
- Implementacja na urządzeniu MOŻE dawać użytkownikowi możliwość zastąp wybrane filtry intencji URI, które udało się zweryfikowanych za pomocą filtrów według intencji.
- [C-0-8] Wdrożenie na urządzeniu MUSI dawać użytkownikom możliwość wyświetlanie i zastępowanie określonych filtrów intencji URI kandydatów, jeśli urządzenie umożliwia zastosowanie niektórych filtrów intencji URI kandydatów weryfikacji, podczas gdy inne mogą się nie powieść.
3.2.3.3 Przestrzenie nazw intencji
- [C-0-1] Implementacje na urządzeniu NIE MOGĄ zawierać żadnych komponentów Androida, które uwzględnia nowe intencje lub wzorce zamiarów transmisji za pomocą atrybutów ACTION, CATEGORY lub w przestrzeni nazw android.* lub com.android.*.
- [C-0-2] Moduły implementujące urządzenia NIE MOGĄ zawierać żadnych komponentów Androida, które uwzględnianie nowych intencji lub wzorców zamiarów transmisji za pomocą atrybutów ACTION, CATEGORY lub inny ciąg klucza w obszarze pakietu należącym do innej organizacji.
- [C-0-3] Osoby wdrażające urządzenie NIE MOGĄ zmieniać ani rozszerzać żadnego z intencji wymienionych w sekcji 3.2.3.1.
- Implementacje na urządzeniach MOGĄ wyraźnie zawierać wzorce intencji wykorzystujących przestrzenie nazw i wyraźnie powiązanych z własną organizacją. Ten zakaz jest analogicznie do klasy określonej dla klas języka Java w sekcji 3.6.
3.2.3.4. Intencje związane z transmisją
Aplikacje innych firm korzystają z platformy, aby przesyłać określone intencje powiadamiać użytkownika o zmianach w środowisku sprzętowym lub oprogramowania.
Implementacje na urządzeniach:
- [C-0-1] MUSI transmitować publiczne komunikaty o transmisjach wymienione tutaj w reakcji na odpowiednie zdarzenia systemowe zgodnie z opisem w dokumentacji pakietu SDK. Ten wymóg nie jest sprzeczny z sekcją 3.5, ponieważ ograniczenia aplikacji działających w tle zostały również opisane w pakiecie SDK dokumentacji. Ponadto niektóre intencje transmisji zależą od sprzętu. obsługi klienta. Jeśli urządzenie obsługuje niezbędny sprzęt, MUSI transmitować intencjami i zapewnić działanie zgodnie z dokumentacją pakietu SDK.
3.2.3.5. Warunkowe intencje aplikacji
Android zawiera ustawienia, które ułatwiają użytkownikom domyślnych aplikacji, takich jak ekran główny czy SMS-y.
W stosownych przypadkach implementacje na urządzeniach MUSZĄ oferować podobne ustawienia oraz być zgodne ze wzorcem filtra intencji i opisanymi metodami interfejsu API. znajdziesz w dokumentacji pakietu SDK jak poniżej.
Jeśli implementacje urządzeń zgłaszają android.software.home_screen
:
- [C-1-1] MUSI spełniać warunki standardu
android.settings.HOME_SETTINGS
Nie chcesz już wyświetlać domyślnego menu ustawień na ekranie głównym.
Jeśli implementacje urządzeń zgłaszają android.hardware.telephony.calling
:
[C-2-1] MUSI zawierać menu ustawień, które wywoła funkcję
android.provider.Telephony.ACTION_CHANGE_DEFAULT
wyświetlić okno zmiany domyślnej aplikacji SMS.[C-2-2] MUSI spełniać warunki standardu
android.telecom.action.CHANGE_DEFAULT_DIALER
Wyświetlenie okna umożliwiającego zmianę domyślnego telefonu aplikacji.- MUSI używać wybranego przez użytkownika domyślnego interfejsu aplikacji Telefon do 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, udostępniać realizację zamówień w sposób opisany 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 wykrywalności.
Jeśli implementacje urządzeń obsługują tę funkcję:
- [C-6-1] MUSI wdrożyć działanie, które zareaguje na intencję
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
dla których w implementacjach z interfejsem UI_MODE_TYPE_NORMAL MUSI być to działanie, w którym użytkownik może przyznać lub odmówić aplikacji dostęp do konfiguracji zasad Nie przeszkadzać.
Jeśli implementacje urządzeń pozwalają użytkownikom na korzystanie z metod wprowadzania danych innych firm urządzenia, to:
- [C-7-1] MUSI zawierać dostępny dla użytkownika mechanizm umożliwiający dodawanie i konfigurowanie
zewnętrznych metod wprowadzania w odpowiedzi na
android.settings.INPUT_METHOD_SETTINGS
intencji.
Jeśli implementacje urządzenia obsługują usługi ułatwień dostępu innych firm:
- [C-8-1] MUSI spełniać warunki standardu
android.settings.ACCESSIBILITY_SETTINGS
udostępniającym dostępny dla użytkowników mechanizm włączania i wyłączania usługi ułatwień dostępu innych firm oprócz wstępnie wczytanych ułatwień dostępu usług Google.
Jeśli urządzenia obsługują Wi-Fi Easy Connect i udostępnić funkcji aplikacji innych firm:
- [C-9-1] MUSI zaimplementować Ustawienia#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Interfejsy API intencji zgodnie z opisem w dokumentacji pakietu SDK.
Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych:
- [C-10-1] MUSI zawierać w ustawieniach interfejs użytkownika, który obsługuje
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
Intencje, które pozwalają użytkownikom dodawać aplikacje do listę dozwolonych.
Jeśli implementacje urządzeń nie obsługują trybu oszczędzania danych:
- [C-11-1] MUSI mieć aktywność, która obsługuje
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
ale MOGĄ wdrożyć tę metodę jako no op.
Jeśli implementacje urządzenia zadeklarują obsługę 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 Ustawienia lub linki do haseł użytkowników przy użyciu podobnego mechanizmu:
- [C-16-1] MUSI wyświetlać takie linki w przypadku wszystkich zainstalowanych usług autouzupełniania.
Jeśli implementacje urządzeń obsługują VoiceInteractionService
i mają więcej
więcej niż jednej aplikacji korzystającej z tego interfejsu API, użytkownik:
- [C-18-1] MUSI spełniać warunki standardu
android.settings.ACTION_VOICE_INPUT_SETTINGS
z zamiarem wyświetlenia domyślnego menu ustawień aplikacji z funkcją głosowego wprowadzania tekstu i Asystenta.
Jeśli implementacje na urządzeniach zgłaszają funkcję android.hardware.audio.output
,
one:
- [C-SR-3] Zdecydowanie ZALECANE jest działanie funkcji android.intent.action.TTS_SERVICE. android.speech.tts.engine.INSTALL_TTS_DATA & Intencje android.speech.tts.engine.GET_SAMPLE_TEXT mają działanie, które zapewnia działanie dla tych intencji, jak opisano w tym artykule w pakiecie SDK.
Android zapewnia obsługę interaktywnych wygaszaczy ekranu. jak Marzy. Wygaszacze ekranu pozwalają użytkownikom na interakcję z aplikacjami, gdy urządzenie urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji biurkowej. Implementacje na urządzeniach:
- MUSI obsługiwać wygaszacze ekranu i opcję ustawień dla
konfigurowania wygaszaczy ekranu w odpowiedzi na
Intencja
android.settings.DREAM_SETTINGS
.
Zacznij nowe wymagania
Jeśli implementacje na urządzeniach zgłaszają android.hardware.nfc.uicc
lub android.hardware.nfc.ese
,
one:
- [C-19-1] MUSI zaimplementować parametr NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API (jako „EVT_TRANSACTION” zgodnie z definicją zawartą w specyfikacji technicznej Stowarzyszenia GSM TS.26 – Wymagania dotyczące telefonu NFC).
Zakończ nowe wymagania
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ń umożliwiają uruchamianie zwykłych aktywności na Androidzie na dodatkowych a dodatkowy 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 głównej
Vulkan 1.0Funkcja Vulkan 1.1 oraz symboleVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
iVK_KHR_get_physical_device_properties2
za pomocąlibvulkan.so
. Pamiętaj, że wszystkie symbole MUSZĄ być obecne, artykuł 7.1.4.2 bardziej szczegółowo opisuje wymagania dotyczące sytuacji, niektórych z tych funkcji.POWINNA budować za pomocą kodu źródłowego i plików nagłówka dostępnych projektu open source Androida.
Kolejne wersje Androida mogą wprowadzać obsługę interfejsy ABI.
3.3.2 Zgodność z 32-bitowym kodem natywnym ARM
Jeśli implementacje urządzeń zgłaszają obsługę interfejsu ABI armeabi
:
- [C-3-1] MUSI też obsługiwać usługę
armeabi-v7a
i zgłaszać jej wsparcie zgodnie z 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 przechowywać następujące operacje, nawet w w którym interfejs ABI jest wdrożony w architekturze ARMv8, za pomocą natywną obsługę procesora lub przez emulację oprogramowania:
- Instrukcje dotyczące SWP i SWPB.
- Operacje na barierach CP15ISB, CP15DSB i CP15DMB.
[C-2-3] MUSI obsługiwać zaawansowaną kartę SIMD (inaczej NEON).
3.4 Zgodność z internetem
3.4.1 Zgodność z WebView
Jeśli implementacje urządzeń zapewniają pełną implementację
android.webkit.Webview
. Są to:
- [C-1-1] MUSI zgłosić użytkownika
android.software.webview
. - [C-1-2] MUSI używać kompilacji z projektu Chromium
z projektu Android Open Source na Androida
14 która zajmuje się 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
udostępnianej aplikacji za pomocą
LocationManager
klasa interfejsu API lub parametrWifiManager.startScan()
. - [C-0-6] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, NIE MOŻE
pozwalają rejestrować odbiorniki na potrzeby niejawnych transmisji
standardowych intencji Androida w pliku manifestu aplikacji, chyba że
intencja wymaga
"signature"
lub"signatureOrSystem"
protectionLevel
lub znajdują się listę wykluczeń. - [C-0-7] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zostać zatrzymana
usług w tle, tak jakby aplikacja wywoływała
usług
stopSelf()
chyba że aplikacja została umieszczona na tymczasowej liście dozwolonych w celu obsługi widoczne dla użytkownika. - [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI JEST Puść blokady uśpienia ustawione przez aplikację.
- [C-0-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
siedem wartości tablicowych z argumentu
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 na urządzeniach rozszerzają wprowadzone ograniczenia aplikacji w AOSP:
- [C-2-1]MUSI postępować zgodnie z implementacją opisaną w tym dokumencie.
3.5.2 Hibernacja aplikacji
Jeśli implementacje urządzeń obejmują hibernację aplikacji w AOSP lub rozszerza funkcje uwzględnione w AOSP, to:
- [C-1-1] MUSI spełniać wszystkie wymagania określone w artykule 3.5.1 z wyjątkiem [C-1-6] i [C-1-3].
- [C-1-2] Ograniczenie obowiązuje w aplikacji w przypadku użytkownika tylko wtedy, gdy dowody na to, że użytkownik nie używał aplikacji od jakiegoś czasu. Ten ZALECANY jest czas trwania co najmniej 1 miesiąca. Wykorzystanie MUSI być jest definiowana przez bezpośrednią interakcję użytkownika UsageStats#getLastTimeVisible() interfejsu API lub innych elementów, które powodują wyjście aplikacji ze stanu wymuszonego zatrzymania. w tym powiązania usług, dostawców treści, transmisji dla pełnoletnich itp. który będzie śledzony 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
dynamicznych skrótów, przypinania 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 plakietek 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 umożliwiające dodawanie, konfigurowanie, wyświetlanie i usuwanie widżetów AppWidgets
[C-1-3] MUSI wyświetlać widżety o wymiarach 4 x 4 w standardowym rozmiarze siatki. Przeczytaj wytyczne dotyczące projektowania widżetów aplikacji. w dokumentacji pakietu Android SDK.
MOŻE obsługiwać widżety aplikacji na ekranie blokady.
jeśli implementacje urządzeń obsługują widżety i elementy w aplikacji innych firm; przypięcia skrótów:
- [C-2-1] MUSI zgłosić użytkownika
true
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 wibrator, MUSISZ 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 Asystenta 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
iMONOCHROMATIC
.„Kolor źródła” służy do generowania dynamicznych palet kolorów przy wysyłaniu z
android.theme.customization.system_palette
(jak opisano 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 Trzeba zachować styl ikony paska stanu 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ą wdrożone animowane tapety:
- [C-1-1] MUSI zgłosić flagę funkcji platformy android.software.live_wallpaper.
3.8.8 Przełączanie aktywności
Fragment kodu źródłowego Androida zawiera funkcje ekran Przegląd, interfejs użytkownika na poziomie systemu do przełączania zadań i wyświetlania ostatnio używanych za pomocą miniatury graficznej aplikacji w chwili ostatniego opuszczenia aplikacji przez użytkownika.
Implementacje na urządzeniach w tym klawisz nawigacyjny funkcji ostatnich, zgodnie z opisem w sekcja 7.2.3 MOŻE zmienić interfejs.
Jeśli implementacje urządzeń obejmujące klawisz nawigacyjny funkcji ostatnich, zgodnie z opisem w punktu 7.2.3 modyfikują interfejs, dlatego:
- [C-1-1] MUSI obsługiwać do 7 wyświetlonych działań.
- NALEŻY wyświetlać przynajmniej tytuł 4 aktywności jednocześnie.
- [C-1-2] MUSI obsługiwać przypinanie ekranu. i udostępnić użytkownikowi menu ustawień, w którym może włączyć tę funkcję.
- W ostatnich krokach 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.
- MUSI aktywować działanie szybkiej zmiany między dwoma ostatnio używanymi gdy klawisz funkcji ostatnich kliknięć trzeba nacisnąć dwukrotnie.
- POWINNY być wyzwalanie trybu wielu okien podzielonego ekranu, jeśli jest obsługiwany, gdy klawisz funkcji ostatnich jest wciśnięty i przytrzymaj.
- MOŻE wyświetlać ostatnie powiązane zdjęcia jako grupę poruszającą się razem.
- [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, potocznie nazywane „Zawgyi”, używane do renderowania birmańskiego języki.
Jeśli implementacje urządzeń obejmują obsługę języka birmańskiego:
- [C-2-1] Domyślnie MUSI renderować tekst z użyciem czcionki zgodnej z Unicode. czcionka niezgodna z Unicode NIE MOŻE być ustawiona jako domyślna, chyba że użytkownik wybierze go w selektorze języka.
- [C-2-2] MUSI obsługiwać czcionkę Unicode i czcionkę niezgodną z tym standardem, jeśli czcionka niezgodna z Unicode jest obsługiwana przez urządzenie. Niezgodne z Unicode czcionka zgodna z wymaganiami NIE MOŻE usuwać ani zastępować czcionki Unicode.
- [C-2-3] MUSI renderować tekst z użyciem czcionki niezgodnej z Unicode TYLKO JEŚLI kod języka z kod skryptu Qaag (np. my-Qaag). Brak innych kodów języków lub regionów w standardzie ISO (niezależnie od tego, przypisane, nieprzypisane lub zarezerwowane) mogą być używane w odniesieniu do znaków innych niż Unicode. czcionka zgodna z wymaganiami Mjanmy. Programiści aplikacji i autorzy stron internetowych mogą określ my-Qaag jako kod języka, tak jak w przypadku każdego innego innego języka.
3.8.14. Wiele okien
Jeśli implementacje urządzeń mają możliwość wyświetlania wielu działań Jednocześnie:
- [C-1-1] MUSI wdrożyć taki tryb wielu okien zgodnie z zachowania aplikacji i interfejsy API opisane w Android SDK dokumentacji obsługi trybu wielu okien oraz następujące wymagania:
- [C-1-2] MUSI uwzględniać:
android:resizeableActivity
jest ustawiona przez aplikację w 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, których tryb konfiguracji ma wartość „Configuration.uiMode”
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 dla poszczególnych urządzeń znajdziesz w sekcji 2_2_3.
3.8.17. Schowek
Implementacje na urządzeniach:
- [C-0-1] NIE MOŻE wysyłać danych ze schowka do żadnego komponentu, aktywności, usługi ani niezależnie od połączenia sieciowego, bez wyraźnej czynności ze strony użytkownika (np. naciśnięcia klawisza w nakładce), z wyjątkiem usług wymienionych w 9.8.6 Rejestrowanie treści i wyszukiwanie aplikacji.
czy implementacje urządzeń generują podgląd widoczny dla użytkowników podczas kopiowania treści,
do schowka dla dowolnego elementu ClipData
, gdzie
ClipData.getDescription().getExtras()
zawiera
android.content.extra.IS_SENSITIVE
, to:
- [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; zasad 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 sklepów przed interakcją użytkownika z reklamą. Jeśli implementacje urządzeń zadeklarują
android.software.device_admin
, ale również zawierają zastrzeżone rozwiązania do zarządzania urządzeniami i mechanizmu 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 funkcji ACTION_PROVISIONING_successFUL w profilu służbowym, jeśli został ustanowiony właściciel profilu podczas obsługa administracyjna jest inicjowana przez profil android.app.action.PROVISION_MANAGED_PROFILE. a DPC zaimplementował moduł obsługi.
[C-1-5] MUSI wysłać ACTION_PROFILE_PROVISIONING_COMPLETE są wysyłane do DPC profilu służbowego po zainicjowaniu obsługi administracyjnej android.app.action.PROVISION_MANAGED_PROFILE intencji.
[C-1-6] MUSI wysłać tryb ACTION_GET_PROVISIONING_MODE po uruchomieniu obsługi administracyjnej właściciela profilu, tak aby aplikacja DPC mogą zdecydować, czy zostać właścicielem urządzenia czy właścicielem profilu, chyba że obsługa administracyjna jest uruchamiana przez intencję android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] MUSI wysłać ACTION_ADMIN_POLICY_COMPLIANCE do profilu służbowego, gdy zostanie utworzony właściciel profilu obsługi administracyjnej niezależnie od używanej metody obsługi administracyjnej z wyjątkiem: gdy obsługa administracyjna jest uruchamiana przez intencję android.app.action.PROVISION_MANAGED_PROFILE. Użytkownik nie może mieć możliwości kontynuowania w kreatorze konfiguracji, dopóki profil nie zostanie Aplikacja właściciela kończy działanie.
[C-1-8] MUSI wysłać ACTION_MANAGED_PROFILE_PROVISIONED do profilu osobistego DPC po utworzeniu właściciela profilu. niezależnie od użytej metody obsługi administracyjnej.
3.9.2 Obsługa profilu zarządzanego
Jeśli implementacje urządzenia zadeklarują android.software.managed_users
:
- [C-1-1] MUSI obsługiwać profile zarządzane za pomocą
android.app.admin.DevicePolicyManager
API. - [C-1-2] MUSI zezwalać na utworzenie tylko jednego profilu zarządzanego.
- [C-1-3] MUSI używać plakietki ikony (podobnej do plakietki pracy nadającej AOSP) do reprezentują zarządzane aplikacje i widżety oraz inne elementy interfejsu z plakietką np. Ostatnie i Powiadomienia.
- [C-1-4] MUSI wyświetlać ikonę powiadomienia (podobna do działania na wyższym poziomie AOSP ) wskazującą, kiedy użytkownik korzysta z aplikacji profilu zarządzanego.
- [C-1-5] MUSI wyświetlać toast informujący o tym, że użytkownik korzysta z zarządzanej usługi profilu po wybudzeniu urządzenia (ACTION_USER_PRESENT). aplikacja na pierwszym planie znajduje się w profilu zarządzanym.
- [C-1-6] Jeśli istnieje profil zarządzany, MUSI wykazywać afordancję w sekcji Intencja „Chooser” aby umożliwić użytkownikowi przekazanie intencji z zarządzanego głównemu użytkownikowi lub odwrotnie, po włączeniu Zasad dotyczących urządzeń kontroler.
- [C-1-7] Jeśli istnieje profil zarządzany, MUSI udostępniać następujące konto użytkownika
zarówno dla użytkownika głównego, jak i profilu zarządzanego:
- Oddzielne zliczanie baterii, lokalizacji, mobilnej transmisji danych i wykorzystania miejsca na dane dla głównego użytkownika i profilu zarządzanego.
- Niezależne zarządzanie aplikacjami VPN zainstalowanymi w głównym użytkownika lub profilu zarządzanego.
- Niezależne zarządzanie aplikacjami zainstalowanymi u głównego użytkownika lub profilu zarządzanego.
- Niezależne zarządzanie kontami głównego użytkownika lub zarządzanych kont profil.
- [C-1-8] MUSI mieć zainstalowaną fabrycznie zainstalowaną aplikację telefonu, kontakty i wiadomości aplikacje mogą wyszukiwać i wyszukiwać informacje o rozmówcy w zarządzanych profilu (jeśli istnieje) i profilu głównego, jeśli Kontroler zasad dotyczących urządzeń na to zezwala.
- [C-1-9] MUSI mieć pewność, że spełnia wszystkie wymagania dotyczące bezpieczeństwa dotyczy urządzenia z włączonymi wieloma użytkownikami (patrz sekcja 9.5), nawet jeśli profil zarządzany nie jest liczony jako inny użytkownik oprócz użytkownika głównego.
Zacznij nowe wymagania
- [C-1-10] MUSI mieć pewność, że dane zrzutu ekranu są zapisane w profilu służbowym
w pamięci podręcznej.
topActivity
okno z ostrością (tę, z którą użytkownik wchodził w interakcję jako ostatnia spośród wszystkich aktywności) i należy do aplikację profilu służbowego. - [C-1-11] NIE MOŻE przechwytywać żadnej innej zawartości ekranu (paska systemowego, powiadomień i treści z profilu osobistego) z wyjątkiem profilu służbowego okno/okna aplikacji przy zapisywaniu zrzutu ekranu w profilu służbowym (aby mieć pewność, nie są zapisywane w profilu służbowym).
Zakończ nowe wymagania
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
Zacznij nowe wymagania
3.9.5 Zasady rozwiązywania problemów z urządzeniami
Jeśli implementacje urządzeń zgłaszają android.software.device_admin
lub
android.software.managed_users
, to:
- [C-1-1] MUSI rozwiązywać konflikty zasad dotyczących urządzeń zgodnie z opisem w Zasady dotyczące urządzeń z Androidem.
Zakończ nowe wymagania
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 wejściowe dane wejściowe innych firm oparte na TIF usługa może być zainstalowana i używana na urządzeniu.
3.13. Szybkie ustawienia
Android zapewnia komponent interfejsu Szybkich ustawień, który zapewnia szybki dostęp do często używane lub pilnie potrzebne działania.
jeśli implementacje urządzeń zawierają komponent interfejsu Szybkich ustawień i obsługują aplikacje innych firm, Szybkie ustawienia:
- [C-1-1] MUSI umożliwiać użytkownikowi dodawanie lub usuwanie kafelków udostępnionych przez
quicksettings
Interfejsy API z aplikacji innej firmy. - [C-1-2] NIE MOŻE automatycznie dodawać kafelka bezpośrednio z aplikacji innej firmy otwórz Szybkie ustawienia.
- [C-1-3] MUSI wyświetlać wszystkie kafelki dodane przez użytkowników z aplikacji innych firm obok dostępnych przez system kafelków szybkich ustawień.
3.14. Interfejs multimediów
Jeśli implementacje urządzeń obejmują aplikacje nieaktywowane głosem (aplikacje), które współdziałają
aplikacji innych firm w ramach usługi MediaBrowser
lub MediaSession
,
Aplikacje:
[C-1-2] MUSZĄ wyraźnie wyświetlać ikony uzyskane za pomocą
getIconBitmap()
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ądzenia zadeklarują funkcję FEATURE_CANT_SAVE_STATE
,
to:
- [C-1-1] MUSI mieć zainstalowaną tylko jedną aplikację, która określa
cantSaveState
działające w systemie w tym samym czasie. Jeśli użytkownik opuszcza aplikację bez jej zamykania (np. naciskając w domu i zostawić aktywną aktywność, zamiast naciskać przycisk „Wstecz” bez aktywnych działań w systemie), a następnie wdrożenia na urządzeniu MUSZĄ priorytetowo traktować tę aplikację w pamięci RAM tak jak w przypadku innych rzeczy, które powinny pozostać uruchomione, na przykład usługi na pierwszym planie. Gdy taka aplikacja działa w tle, system może nadal zasilać urządzenie. funkcji zarządzania, np. ograniczania dostępu do procesora i sieci. - [C-1-2] MUSI udostępniać zasoby UI, by wybrać aplikację, która nie chce
korzystają z mechanizmu zapisywania/przywracania stanu normalnego, gdy użytkownik
uruchamia drugą aplikację zadeklarowaną przy użyciu
cantSaveState
. - [C-1-3] NIE MOŻE stosować innych zmian zasad do aplikacji, które określają
cantSaveState
na przykład zmień wydajność procesora lub priorytety planowania.
Jeśli implementacje urządzeń nie zadeklarują funkcji
FEATURE_CANT_SAVE_STATE
to:
- [C-1-1] MUSI ignorować
cantSaveState
ustawiony przez aplikacje i NIE MOŻE zmieniać działania aplikacji na podstawie tego .
3.18. Kontakty
Android obejmuje
Contacts Provider
Interfejsy API umożliwiające aplikacjom zarządzanie informacjami kontaktowymi przechowywanymi na urządzeniu.
Dane kontaktowe wprowadzane bezpośrednio na urządzeniu są zwykle synchronizowane
z usługą internetową, ale dane MOGĄ też być przechowywane tylko lokalnie na urządzeniu.
Kontakty przechowywane tylko na urządzeniu są określane jako lokalne
kontaktów.
Nieprzetworzone kontakty
są „powiązane z” lub „zapisane w”
Konto
gdy
ACCOUNT_NAME
,
oraz
ACCOUNT_TYPE
kolumny nieprzetworzonych kontaktów pasują do odpowiednich
Nazwa.konta
oraz
Typ konta
pola na koncie.
Domyślne konto lokalne: konto dla nieprzetworzonych kontaktów, które są przechowywane tylko
urządzenie i nie jest powiązane z kontem w
AccountManager
utworzone z wartościami null dla
ACCOUNT_NAME
,
oraz
ACCOUNT_TYPE
,
kolumny.
Niestandardowe konto lokalne: konto dla nieprzetworzonych kontaktów, które są przechowywane tylko na
i nie są powiązane z kontem w usłudze AccountManager, które są
utworzony z co najmniej 1 wartością niepustą dla argumentu
ACCOUNT_NAME
,
oraz
ACCOUNT_TYPE
kolumny.
Implementacje na urządzeniach:
- [C-SR-1] Zdecydowanie ZALECANE jest nietworzenie niestandardowych kont lokalnych.
Jeśli implementacje urządzeń korzystają z niestandardowego konta lokalnego:
- [C-1-1]
ACCOUNT_NAME
z niestandardowego konta lokalnego MUSZĄ zostać zwrócone 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 pliku „.apk” systemu Android pliki jako generowanych przez „aapt” narzędzia zawartego w oficjalnym pakiecie SDK na Androida.
- Powyższe wymaganie może być wyzwaniem, dlatego implementacje na urządzeniach ZALECANE jest korzystanie z zarządzania pakietami implementacji referencyjnej AOSP systemu.
[C-0-2] MUSI obsługiwać weryfikację pliku „.apk” za pomocą Schemat podpisu APK w wersji 3.1, Schemat podpisu pliku APK w wersji 3, Schemat podpisu pliku APK w wersji 2 i podpisywanie plików JAR.
[C-0-3] NIE MOŻE wydłużać pliki .apk, Plik manifestu Androida kod bajtowy Dalvik lub z kodami bajtowymi RenderScript tak, aby uniemożliwiały one instaluje się i działa prawidłowo na innych zgodnych urządzeniach.
[C-0-4] NIE MOŻE zezwalać na aplikacje inne niż „zarejestrowany użytkownik” aby pakiet mógł odinstalować aplikację bez żadnych potwierdzania przez użytkownika, zgodnie z dokumentacją pakietu SDK
DELETE_PACKAGE
uprawnienia. Jedynym wyjątkiem jest obsługa aplikacji weryfikatora pakietów systemu PACKAGE_NEEDS_VERIFICATION intencję i obsługę aplikacji przez menedżera miejsca ACTION_MANAGE_STORAGE intencji.[C-0-5] MUSI mieć aktywność, która obsługuje
android.settings.MANAGE_UNKNOWN_APP_SOURCES
intencji.[C-0-6] NIE MOŻE instalować pakietów aplikacji z nieznanych źródeł, chyba że aplikacja, która żąda instalacji, spełnia wszystkie te wymagania:
- MUSI zadeklarować
REQUEST_INSTALL_PACKAGES
uprawnienia albo 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 no-op i zwróć
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
Zacznij nowe wymagania
- [C-0-4] AVIF
- Urządzenia muszą obsługiwać profil
BITRATE_MODE_CQ
i profil podstawowy.
- Urządzenia muszą obsługiwać profil
Zakończ nowe wymagania
Jeśli implementacje urządzeń obsługują kodowanie HEIC przez android.media.MediaCodec
dla typu mediów MIMETYPE_IMAGE_ANDROID_HEIC
,
one:
- [C-1-1] MUSI udostępniać kodek HEVC z akceleracją sprzętową,
obsługuje
BITRATE_MODE_CQ
tryb sterowania szybkością transmisji bitów.HEVCProfileMainStill
profilu i rozmiaru ramki 512 x 512 pikseli.
5.1.5 Dekodowanie obrazu
Więcej informacji znajdziesz w artykule 5.1.6. Szczegóły kodeków graficznych.
Implementacje na urządzeniu MUSZĄ obsługiwać dekodowanie tego kodowania obrazu:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] Nieprzetworzony
- [C-0-7] AVIF (profil podstawowy)
Jeśli implementacje urządzeń obsługują dekodowanie wideo HEVC: * [C-1-1] MUSI obsługiwać dekodowanie obrazu HEIF (HEIC).
Dekodery obrazów, które obsługują format o dużej głębi bitowej (co najmniej 9 bitów na kanał):
- [C-2-1] MUSI obsługiwać wyświetlanie równoważnego formatu 8-bitowego, jeśli zostanie zażądany przez
aplikacji, na przykład za pomocą narzędzia
ARGB_8888
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) |
AVIF (profil podstawowy) | Obraz, kolekcja obrazów, profil podstawowy sekwencji obrazów | Kontener HEIF (.avif) |
Koder obrazu i dekodery dostępne przez interfejs API MediaCodec
[C-1-1] MUSI obsługiwać elastyczny kolor YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) 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. |
|
AV1 | Szczegółowe informacje znajdziesz w sekcjach 5.2 i 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 i AV1) | 3840 x 2160 piks. (HEVC, VP9, AV1) |
- [C-2-2] Kodeki wideo z akceleracją sprzętową MUSZĄ
publikowanie informacji o punktach wydajności. Każda lista MUSI być obsługiwana
standardowe punkty skuteczności (wymienione w sekcji
PerformancePoint
) API), chyba że są one objęte innym obsługiwanym wskaźnikiem wydajności. - Dodatkowo POWINNY jest opublikować rozszerzone punkty wydajności, jeśli: pomagają utrzymać długotrwałe wyniki filmu inne niż wymienione powyżej.
5.2. Kodowanie wideo
- 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ę.
Zacznij nowe wymagania
Jeśli implementacje urządzeń obsługują koder wideo i udostępniają go aplikacji innych firm i ustawMediaFormat.KEY_BITRATE_MODE
na
BITRATE_MODE_VBR
aby koder działał w trybie zmiennej szybkości transmisji bitów, a następnie
o ile nie ma to wpływu na minimalną jakość,
zakodowana szybkość transmisji bitów :
[C-5-1] MUSINIE POWINNY być, więcej niż jeden okno przesuwane o ponad 15% powyżej szybkości transmisji bitów między ramkami (I-frame). interwały.[C-5-2] MUSINIE POWINNO być większe niż 100% powyżej szybkości transmisji bitów w oknie przesuwanym o długości 1 sekundy.
Jeśli implementacje urządzeń obsługują koder wideo i udostępniają go
aplikacji innych firm i ustawiać
MediaFormat.KEY_BITRATE_MODE
do
BITRATE_MODE_CBR
więc koder działa ze stałą szybkością transmisji bitów, wówczas
[C-6-1] MUSI[C-SR-2] Zdecydowanie ZALECANY dla NIE może przekraczać docelowej szybkości transmisji bitów o więcej niż 15% w oknie przesuwanym o długości 1 sekundy.
Zakończ nowe wymagania
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ć rozdzielczość QCIF (176 x 144) przy użyciu profilu bazowego poziomu 45. Rozdzielczość SQCIF jest opcjonalna.
Dynamiczne konfigurowane szybkości transmisji bitów muszą być obsługiwane z 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 poziomu 3 do Rozdzielczość 512 x 512.
POWINNO obsługiwać profile kodujące HD zgodnie ze wskazanymi instrukcjami w poniższej tabeli.- [C-SR-1] Zdecydowanie ZALECANE jest wsparcie Profil SD 720 x 480 Profile kodujące HD opisane w tej tabeli, jeśli koder sprzętowy.
SD | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|
Rozdzielczość wideo | 720 x 480 piks. | 1280 x 720 piks. | 1920 x 1080 piks. | 3840 x 2160 piks. |
Liczba klatek w filmie | 30 klatek/s | 30 klatek/s | 30 klatek/s | 30 klatek/s |
Szybkość transmisji wideo | 1,6 Mb/s | 4 Mb/s | 5 Mb/s | 20 Mb/s |
Zacznij nowe wymagania
5.2.6 AV1
Jeśli implementacje urządzeń obsługują kodek AV1, wówczas:
- [C-1-1] MUSI obsługiwać profil główny, w tym treści 8- i 10-bitowe.
[C-1-2] MUSI publikować dane o skuteczności, tj. raportować dane o skuteczności w
getSupportedFrameRatesFor()
lubgetSupportedPerformancePoints()
Interfejsy API obsługujące obsługiwane rozwiązania znajdziesz w tabeli poniżej.[C-1-3] MUSI akceptować metadane HDR i przesyłać je do strumienia bitowego
Jeśli koder AV1 ma przyspieszanie sprzętowe, to:
- [C-2-1] MUSI obsługiwać maksymalnie profil kodowania HD1080p z tabeli poniżej:
SD | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|
Rozdzielczość wideo | 720 x 480 piks. | 1280 x 720 piks. | 1920 x 1080 piks. | 3840 x 2160 piks. |
Liczba klatek w filmie | 30 klatek/s | 30 klatek/s | 30 klatek/s | 30 klatek/s |
Szybkość transmisji wideo | 5 Mb/s | 8 Mb/s | 16 Mb/s | 50 Mb/s |
Zakończ nowe wymagania
5.3. Dekodowanie wideo
Jeśli implementacje urządzeń obsługują kodeki VP8, VP9, H.264 lub H.265:
- [C-1-1] MUSI obsługiwać dynamiczną rozdzielczość obrazu i przełączanie liczby klatek za pomocą standardowych interfejsów API Androida w tym samym strumieniu dla wszystkich kodeków VP8, VP9, Kodeki H.264 i H.265 w czasie rzeczywistym i z maksymalną obsługiwaną rozdzielczością przy użyciu każdego kodeka urządzenia.
5.3.1 MPEG-2
Jeśli implementacje urządzeń obsługują dekodery MPEG-2:
- [C-1-1] MUSI obsługiwać wysoki poziom profilu głównego.
5.3.2 H.263
Jeśli implementacje urządzeń obsługują dekodery H.263:
- [C-1-1] MUSI obsługiwać profil podstawowy poziomu 30 (rozdzielczości CIF, QCIF i SQCIF przy 30 kl./s 384 kb/s) i poziom 45 (rozdzielczości QCIF i SQCIF przy 30 kl./s 128 kb/s).
5.3.3 MPEG-4
Urządzenia obsługujące dekodery MPEG-4:
- [C-1-1] MUSI obsługiwać prosty profil na poziomie 3.
5.3.4 H.264
Jeśli implementacje urządzeń obsługują dekodery H.264:
- [C-1-1] MUSI obsługiwać profil główny na poziomie 3.1 i profil podstawowy. 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
- [C-1-1] MUSI obsługiwać profil 0, w tym treści 10-bitowe.
Zacznij nowe wymagania
Jeśli implementacje urządzeń obsługują kodek AV1 i udostępniają go aplikacjom innych firm, to:- [C-1-1] MUSI obsługiwać profil główny, w tym treści 8- i 10-bitowe.
Jeśli implementacje urządzeń zapewniają obsługę kodeka AV1 za pomocą sprzętu z przyspieszonym dekoderem:
- [C-2-1] MUSI dekodować profile dekodowania wideo o rozdzielczości co najmniej HD 720p z
w tabeli poniżej, gdy wysokość podawana przez
Display.getSupportedModes()
jest równa lub większa niż 720p. - [C-2-2] MUSI dekodować profile dekodowania wideo w rozdzielczości co najmniej 1080p.
z poniższej tabeli, gdy wysokość podawana przez
Display.getSupportedModes()
ma wartość równą lub większą niż 1080p.
SD | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|
Rozdzielczość wideo | 720 x 480 piks. | 1280 x 720 piks. | 1920 x 1080 piks. | 3840 x 2160 piks. |
Liczba klatek w filmie | 30 klatek/s | 30 klatek/s | 30 klatek/s | 30 klatek/s |
Szybkość transmisji wideo | 5 Mb/s | 8 Mb/s | 16 Mb/s | 50 Mb/s |
Jeśli implementacje urządzeń obsługują profil HDR za pomocą interfejsów Media API, one:
- [C-3-1] MUSI obsługiwać wyodrębnianie i wyświetlanie metadanych HDR z lub w kontenerze.
- [C-3-2] MUSI prawidłowo wyświetlać treści HDR na ekranie urządzenia lub standardowym portem wyjściowym wideo (np. HDMI).
Zakończ nowe wymagania
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
w odległości 30 cm odobok 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.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
.
Zacznij nowe wymagania
- [C-1-4] MUSI obsługiwać efekty dźwiękowe w: zmiennoprzecinkowe dane wejściowe i wyjściowe.
- [C-1-5] Efekty dźwiękowe muszą obsługiwać wiele kanałów, liczba kanałów miksera, czyli FCC_LIMIT.
Zakończ nowe wymagania
- 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
według: AudioAttributes
i użytkowania w samochodzie, jak określono w
android.car.CarAudioManager
.
5.5.4 Odciążanie dźwięku
Jeśli implementacje urządzeń obsługują odciążanie odtwarzania dźwięku:
- [C-SR-1] Zdecydowanie ZALECANE są przycinanie odtwarzanych treści audio bez przerw między 2 klipami o tym samym formacie gdy zostanie określone przez Interfejs API AudioTrack bez przerw i kontenera multimediów.
5.6. Opóźnienie dźwięku
Opóźnienie dźwięku to czas, w którym sygnał audio przechodzi przez system. Wiele klas aplikacji korzysta z krótkich opóźnień, co pozwala uzyskać efekty dźwiękowe.
Na potrzeby tej sekcji należy stosować następujące definicje:
- opóźnienia wyjścia. Odstęp czasu, jaki upływa od momentu, gdy aplikacja zapisuje ramkę danych kodowanych w PCM i gdy odpowiedni dźwięk jest prezentowany w przetworniku urządzenia lub sygnał opuszcza urządzenie i można go obserwować zewnętrznie.
- opóźnienia „na zimno”. Czas między uruchomieniem strumienia wyjściowego a rozpoczęciem czas prezentacji pierwszej klatki na podstawie sygnatur czasowych, gdy wyjście audio system został bezczynny i wyłączony przed wykonaniem żądania.
- ciągły czas oczekiwania na sygnał wyjściowy. opóźnienie wyjściowe kolejnych klatek, gdy urządzenie zacznie odtwarzać dźwięk.
- opóźnienia sygnału wejściowego. Odstęp czasu pomiędzy momentem wyświetlenia dźwięku przez z urządzenia na przetworniku urządzenia lub sygnał trafia do urządzenia przez 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.
Zacznij nowe wymagania
- [C-SR-4] Czasy oczekiwania w obie strony obliczone na podstawie danych wejściowych i wyjściowych
Zdecydowanie ZALECANE są sygnatury czasowe zwracane przez usługę
AAudioStream_getTimestamp
nie więcej niż 30 ms od mierzonego opóźnienia w obie strony dlaAAUDIO_PERFORMANCE_MODE_NONE
iAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
do głośników, przewodowych i bezprzewodowych zestawów słuchawkowych.
Zakończ nowe wymagania
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 formacie 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 Nie dłuższa niż 25 milisekund w przypadku co najmniej 1 obsługiwanej ścieżki.
- [C-1-3] MUSI zawierać porty USB obsługujące tryb hosta USB i port USB trybu urządzenia peryferyjnego.
- [C-1-4] MUSI zgłosić wsparcie funkcji
android.software.midi
. - [C-1-5] MUSI spełniać wymagania dotyczące opóźnień i dźwięku przez USB,
Natywne reklamy audio AAudio
API 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 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ć używając 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żki słuchawek audio za pomocą Klucz sprzętowy do sprzężenia zwrotnego audio.
[C-SR-5] Zdecydowanie ZALECANE jest przestrzeganie sekcję Specyfikacja urządzenia mobilnego (gniazda słuchawek). specyfikacji przewodowego zestawu słuchawkowego do dźwięku (wersja 1.1).
Jeśli w implementacjach urządzenia pomijane są 4-kanałowe gniazdo słuchawek 3,5 mm musi mieć port lub porty USB obsługujące tryb hosta USB, więc:
- [C-3-1] MUSI zaimplementować klasę audio USB.
- [C-3-2] Ciągłe opóźnienie dźwięku w obie strony musi wynosić Nie więcej niż 25 milisekund, powyżej 5 pomiarów ze średnim odchyleniem bezwzględnym mniej niż 5 milisekund nad portem w trybie hosta USB za pomocą klasy audio USB. (Można to zmierzyć za pomocą przejściówki USB-3,5 mm i sprzężenia zwrotnego audio Użyj wtyczki sprzętowej lub interfejsu audio USB z kablem krosowym podłączającym dane wejściowe do danych wyjściowych).
- [C-SR-6] Zdecydowanie ZALECANE są jednoczesne korzystanie z maksymalnie 8 kanałów we/wy. w każdym kierunku, częstotliwość próbkowania 96 kHz i głębia 24- lub 32-bitowa (jeśli jest używana) z urządzeniami peryferyjnymi audio USB, które również spełniają te wymagania.
- [C-SR-7] Zdecydowanie ZALECANE jest spełnienia tej grupy wymagań przez zastosowanie natywnego interfejsu API audio AAudio w ramach ścieżki MMAP.
Jeśli urządzenia są wyposażone w port HDMI:
- POWINNA obsługiwać wyjście stereo i 8 kanałów 20-bitowych lub 24-bitowa głębia i 192 kHz bez utraty głębi bitowej ani ponownego próbkowania, w co najmniej 1 konfiguracji.
5.11. Zrób zdjęcie, aby nie zostały przetworzone
Android zapewnia obsługę nagrywania nieprzetworzonego dźwięku za pomocą
android.media.MediaRecorder.AudioSource.UNPROCESSED
źródło dźwięku. W
OpenSL ES, dostęp do niego można uzyskać za pomocą gotowego ustawienia rekordu
SL_ANDROID_RECORDING_PRESET_UNPROCESSED
Jeśli implementacja urządzenia ma obsługiwać nieprzetworzone źródło dźwięku i sprawia, aplikacji innych firm, mogą:
[C-1-1] MUSI zgłosić pomoc na stronie
android.media.AudioManager
właściwość PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.[C-1-2] MUSI wykazywać w przybliżeniu płaską amplitudę w porównaniu do częstotliwości. charakterystyki średniej częstotliwości: ±10 dB od 100 Hz–7000 Hz dla każdego mikrofonu użytego do nagrywania nieprzetworzonej źródła dźwięku.
[C-1-3] MUSI wykazywać poziomy amplitudy przy niskiej częstotliwości zakres: konkretnie od ±20 dB od 5 z do 100 Hz w porównaniu średniego zakresu częstotliwości dla każdego mikrofonu użytego do nagrywania nieprzetworzone źródło dźwięku.
[C-1-4] MUSI mieć poziom amplitudy w wysokiej częstotliwości zakres: konkretnie od ±30 dB od 7000 Hz do 22 kHz w porównaniu średniego zakresu częstotliwości dla każdego mikrofonu użytego do nagrywania nieprzetworzone źródło dźwięku.
[C-1-5] MUSI ustawić czułość wejścia audio na sinusoidalną 1000 Hz źródło tonu odtwarzanego przy poziomie ciśnienia akustycznego 94 dB (SPL) zwraca odpowiedź z Wartość RMS 520 dla próbek 16-bitowych (lub -36 dB w pełnej skali dla zmiennoprzecinkowego/podwójnej wartości próbek precyzji) dla każdego mikrofonu użytego do rejestracji nieprzetworzonej źródła dźwięku.
[C-1-6] MUSI mieć współczynnik sygnału do szumu (SNR) na poziomie 60 dB lub wyższym każdego mikrofonu użytego do nagrywania nieprzetworzonego źródła dźwięku. (nacisk SNR jest mierzony jako różnica między 94 dB SPL i równoważnym poziomem SPL dla szumu własnego, ważona A).
[C-1-7] Wartość całkowitego zniekształcenia harmonicznych (THD) musi być mniejsza niż 1% dla 1 kHz przy poziomie sygnału wejściowego SPL 90 dB na każdym mikrofonie używanym do nagrać nieprzetworzone źródło dźwięku.
[C-1-8] NIE MOŻE obsługiwać żadnych innych procesów przetwarzania sygnału (np.automatycznego wzmocnienia). kontrola, filtr górnoprzepustowy lub anulowanie echa) w ścieżce innej niż w celu dostosowania poziomu do pożądanego zakresu. Krótko mówiąc:
- [C-1-9] Jeśli w architekturze musi zostać wyłączony i w efekcie nie spowoduje opóźnienia lub i zwiększają opóźnienia w ścieżce sygnału.
- [C-1-10] Mnożnik poziomu, który może znajdować się na ścieżce, NIE MOŻE wprowadzić opóźnienia na ścieżce sygnału.
Wszystkie pomiary SPL są wykonywane bezpośrednio obok testowanego mikrofonu. W przypadku różnych konfiguracji mikrofonów te wymagania dotyczą każdego mikrofonu.
Jeśli implementacje urządzeń zadeklarują android.hardware.microphone
, ale nie
obsługują nieprzetworzone źródła dźwięku, to:
- [C-2-1] MUSI zwrócić
null
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 na urządzeniu obejmuje kodeki obsługujące FEATURE_HdrEditing
,
tych kodeków:
[C-7-1] MUSI obsługiwać co najmniej 1 profil HDR.
[C-7-2] MUSI obsługiwać format
FEATURE_HdrEditing
w przypadku wszystkich profili HDR reklamowanych przez tego kodeka. Innymi słowy, MUSZĄ one obsługiwać generowanie metadanych HDR, gdy: nie występuje w przypadku wszystkich obsługiwanych profili HDR, które korzystają z metadanych HDR.[C-7-3] MUSI obsługiwać poniższe formaty wejściowe kodera wideo, które w pełni zachowaj sygnał zdekodowany HDR:
- RGBA_1010102 (już na docelowej krzywej transferu) dla obu danych wejściowych i ByteBuffer oraz MUSZĄ 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
- Stan zadania zmieniony
- Stan wtyczki zmieniony
- Zmieniono stan zaplanowanego zadania
- Zmieniono stan ekranu
- SyncState (Zmiana stanu)
- Czas rzeczywisty po upłynięciu systemu
- Zmieniono stan procesu UidProcess
- Stan uśpienia został zmieniony
- Pojawił się Budzik
- Zmiana stanu blokady Wi-Fi
- Zmiana stanu blokady Wi-FiMulticastLock
- Zmiana stanu skanowania Wi-Fi
- [C-0-4] demon adb po stronie urządzenia MUSI być domyślnie nieaktywny i włączenie debugowania Androida MUSI dostępny dla użytkownika mechanizm. Most.
- [C-0-5] MUSI obsługiwać bezpieczne narzędzie adb. Android zapewnia obsługę adb. Bezpieczny adb włącza narzędzie adb na znanych uwierzytelnionych hostach.
- [C-0-6] MUSI zawierać mechanizm umożliwiający połączenie adb z na komputerze. Więcej szczegółów:
Jeśli implementacje urządzeń bez portu USB obsługują tryb peryferyjny:
- [C-3-1] MUSI zaimplementować adb przez sieć lokalną (np. Ethernet lub Wi-Fi).
- [C-3-2] MUSI dostarczyć sterowniki dla Windows 7, 8 i 10, co pozwala na łączenie się z urządzeniem przez protokół adb.
Jeśli implementacje urządzeń obsługują połączenia adb z hostem przez Wi-Fi 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.
- MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty wizualnie ukrywanie lub wyłączanie menu w celu uniknięcia rozproszenia uwagi w sytuacjach, w których bezpieczeństwo użytkowników.
7. Zgodność sprzętu
Jeśli urządzenie jest wyposażone w konkretny komponent sprzętowy, który ma Interfejs API dla zewnętrznych deweloperów:
- [C-0-1] Implementacja na urządzeniu MUSI obejmować API zgodnie z opisem w dokumentacji pakietu Android SDK.
Jeśli interfejs API w pakiecie SDK wchodzi w interakcję z komponentem sprzętowym, który jest określony jako opcjonalny, a tag implementacja na urządzeniu nie zawiera tego komponentu:
- [C-0-2] Pełne definicje klas (zgodnie z dokumentacją w pakiecie SDK) dla komponentu Interfejsy API MUSZĄ nadal być prezentowane.
- [C-0-3] Działanie interfejsu API MUSI być wdrożone jako brak działań w w świecie mody.
- [C-0-4] Metody interfejsu API MUSZĄ zwracać wartości null tam, gdzie jest to dozwolone przez SDK dokumentacji.
- [C-0-5] Metody interfejsu API MUSZĄ zwracać implementacje klas bezobsługowych, w których wartości null nie są dozwolone w dokumentacji pakietu SDK.
- [C-0-6] Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, których nie opisano w pakiecie SDK dokumentacji.
- [C-0-7] Implementacje urządzeń MUSZĄ konsekwentnie zgłaszać dokładne informacje dotyczące sprzętu
informacji o konfiguracji w interfejsach
getSystemAvailableFeatures()
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ład odpowiedni dla urządzenia, tak aby aplikacje innych firm
działają dobrze na różnych konfiguracjach sprzętowych.
Różne wyświetlacze i konfiguracje sprzętu. An
Wyświetlacz zgodny z Androidem to ekran, który obsługuje wszystkie
zachowania i interfejsy API opisane w artykule Android Developers – Zgodność ekranu
omówienie, to
(7.1) i jego podpunktów, a także wszelkie dodatkowe typy urządzeń
określonych zachowań opisanych w sekcji 2 dokumentu.
CDD.
Na wyświetlaczach zgodnych z Androidem, na których wszystkie
aplikacje MUSZĄ właściwie implementować te interfejsy API.
i zachowań, jak opisano w tej sekcji.
Zacznij nowe wymagania
Implementacje na urządzeniach:
- [C-0-1] Domyślnie MUSI renderować aplikacje innych firm tylko na Wyświetlacze zgodne z Androidem.
Zakończ nowe wymagania
Jednostki, do których odnoszą się wymagania w tej sekcji, są zdefiniowane w następujący sposób:
- fizyczny rozmiar przekątnej. Odległość między dwoma przeciwległymi obiektami w calach w rogach podświetlonej części wyświetlacza.
gęstość punktów na cal (dpi). Liczba pikseli ujętych przez obiekt liniowy pozioma lub pionowa rozpiętość 1”, wyrażona w pikselach na cal (ppi lub dpi). Gdziedpiwymienione są wartości ppi i dpi, dpi zarówno w poziomie, jak i w pionie musi mieścić się na liście zakres dat.- 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).
Wirtualna jednostka pikseli znormalizowane doekranu 160 dpi. gęstość ekranu wynosząca 160. Dla pewnej gęstości d i liczby p, czyli liczba pikseli niezależnych od gęstości dp, wynosi Wartość obliczana według wzoru:piksele = dps * (gęstość/160)dp = (160 / d) * p .
7.1.1. Konfiguracja ekranu
7.1.1.1. Rozmiar i kształt ekranu
Platforma interfejsu Androida obsługuje różne logiczne układy ekranu
rozmiarów i pozwala aplikacjom na wysyłanie zapytań dotyczących ekranu bieżącej konfiguracji.
rozmiar układu przez Configuration.screenLayout
z SCREENLAYOUT_SIZE_MASK
i Configuration.smallestScreenWidthDp
.
Implementacje na urządzeniach:
[C-0-1] MUSI zgłosić prawidłowy rozmiar układu dla
Configuration.screenLayout
zgodnie z definicją podaną w dokumentacji pakietu Android SDK. Przede wszystkim implementacje urządzeń MUSZĄ zgłaszać prawidłowe niezależne od gęstości pikseli (dp) wymiary ekranu jak poniżej:- Urządzenia, dla których parametr
Configuration.uiMode
jest ustawiony jako dowolna wartość inna niż UI_MODE_TYPE_WATCH i zgłasza 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 urządzeń obsługują ekrany obsługujące
Konfiguracja rozmiaru: UI_MODE_TYPE_NORMAL
i zgodne z Androidem
używaj ekranów fizycznych z
zaokrąglonych rogów do renderowania ekranu,
one:
[C-1-1] MUSI spełniać co najmniej jedno z następujących wymagań w przypadku każdego takiego wyświetlenia:
- Promień zaokrąglonych rogów nie przekracza 38 dp.
- Gdy
1518 dp do1518 Pole dp jest zakotwiczone w każdym rogu wyświetlacza logicznego, co najmniej jeden piksel każdej ramki jest widoczny na ekranie.
POWINNASZ uwzględniać końcową dostępność użytkownika dotyczącą przełączania na tryb wyświetlania za pomocą prostokątnych rogów.
Zacznij nowe wymagania
Jeśli implementacje urządzenia mogą skonfigurować tylko klawiaturę NO_KEYS
,
i zamierzam zgłosić pomoc w trybie interfejsu użytkownika UI_MODE_TYPE_NORMAL
, to znaczy, że:
- [C-4-1] MUSI mieć rozmiar co najmniej (z wyłączeniem wycięć w wyświetlaczu) 596 dp x 384 dp lub więcej.
Zakończ nowe wymagania
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.
Zacznij nowe wymagania
Jeśli implementacje urządzeń obejmują co najmniej jeden obszar wyświetlania zgodny z Androidem które są składane lub zawierają zawias obszarów panelu zgodnych z Androidem i udostępniać je tych aplikacji:
- [C-4-1] MUSI zaimplementować prawidłową wersję rozszerzeń menedżera okien Poziom interfejsu API opisany na stronie Rozszerzenia WindowManager.
Zakończ nowe wymagania
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.
Implementacje na urządzeniach:
- [C-0-1]
Domyślnie implementacje na urządzeniachMUSI zgłaszaćtylkojedną Gęstości platformy Androida wymienione naDisplayMetrics
za pomocą interfejsuDENSITY_DEVICE_STABLE
API a ta wartość musi być wartością statyczną dla każdego wyświetlacza fizycznego.NIE POWINNY BYĆ zmieniać. jednakJednak urządzenie MOŻE zgłaszają innągęstość przypadkową;DisplayMetrics.density
zgodnie ze zmianami w konfiguracji wyświetlacza wprowadzonymi przez użytkownika (na np. rozmiar wyświetlacza) ustawiony po pierwszym uruchomieniu.
- 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.
Zacznij nowe wymagania
- MUSI zdefiniować standardową gęstość platformy Androida, która jest liczbowa która jest najbliższa fizycznej gęstości ekranu lub wartości, która zostałaby zmapowana takich samych pomiarów pola widzenia jak w przypadku urządzenia mobilnego.
Zakończ nowe wymagania
Jeśli implementacje urządzeń zapewniają
istnieje atrakcja
zmienić rozmiar wyświetlacza urządzenia ,:
- [C-1-1]
Rozmiar wyświetlacza NIE MOŻE być skalowanyNIE MOŻE skalować wyświetlacza większa niż 1,5 razaDENSITY_DEVICE_STABLE
gęstość natywnalub ustaw minimalny rozmiar ekranu mniejszy niż 320 dp (odpowiednik do kwalifikatora zasobów sw320dp) w zależności od tego, co nastąpi wcześniej. - [C-1-2]
Rozmiar wyświetlacza NIE MOŻE być skalowanyNIE MOŻE skalować wyświetlacza mniejsza niż 0,85 raza niżgęstość natywnaDENSITY_DEVICE_STABLE
. - Aby zapewnić wygodę użytkowania i spójne rozmiary czcionek, ZALECANE jest dodanie
podane niżej opcje skalowania opcji natywnych reklam displayowych (przy zachowaniu zgodności z limitami:
określone powyżej)
- Małe: 0,85x
- Domyślnie: 1x (natywna skala wyświetlania)
- Duży: 1,15x
- Większe: 1,3x
- Największy 1,45x
7.1.2. Wyświetl dane
Jeśli implementacje urządzeń obejmują wyświetlacze zgodne z Androidem lub wideo na ekrany displayowe zgodne z Androidem:
- [C-1-1] MUSI podawać prawidłowe wartości w przypadku wszystkich wyświetlaczy zgodnych z Androidem
zdefiniowanych w
android.util.DisplayMetrics
API.
Jeśli implementacje urządzeń nie zawierają osadzonego ekranu lub wyjścia wideo, one:
- [C-2-1] MUSI podawać prawidłowe wartości wyświetlacza zgodnego z Androidem
zgodnie z definicją podaną w interfejsie API
android.util.DisplayMetrics
. dla emulowanej wartości domyś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
Google:
- [C-6-1] MUSI też obsługiwać
EGL_ANDROID_front_buffer_auto_refresh
.
7.1.4.2 interfejs Vulkan
Android zapewnia obsługę Vulkan – niewymagający dużych nakładów pracy, wieloplatformowy interfejs API do obsługi wysokiej wydajności grafiki 3D.
Jeśli implementacje urządzeń obsługują OpenGL ES 3.1:
- [C-SR-1] Zdecydowanie ZALECANE jest dodanie obsługi: Vulkan 1.3
- [C-4-1] NIE MOŻE obsługiwać wersji interfejsu Vulkan (tj. wariantu) części podstawowej interfejsu Vulkan MUSI mieć wartość zero).
Jeśli implementacje urządzeń obejmują wyjście ekranu lub wideo:
- [C-SR-2] Zdecydowanie ZALECANE jest dodanie obsługi Vulkan 1.3
Testy Vulkan dEQP są podzielone na kilka list testowych, z których każda zawiera parametr
powiązanej daty/wersji. Znajdziesz je w drzewie źródłowym Androida na stronie
external/deqp/android/cts/main/vk-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ń obejmują obsługę interfejsu Vulkan
w wersji 1.0 lub nowszej:
- [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 natywnego interfejsu APIvkEnumeratePhysicalDevices()
. - [C-1-3] MUSI w pełni wdrożyć
Vulkan 1.0Interfejsy API Vulkan 1.1 dla każdego wymienionegoVkPhysicalDevice
- [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
ustawiono jakotrue
lub metadanecom.android.graphics.injectLayers.enable
ustaw natrue
. - [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-1-13] MUSI spełniać wymagania określone w profilu Android Baseline 2021.
- [C-SR-4] Zdecydowanie ZALECANE jest spełnić wymagania określone przez profilu Android Baseline 2022,
Zacznij nowe wymagania
[C-SR-5] Zdecydowanie ZALECANE jest działanie funkcji
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
iVK_EXT_global_priority
.[C-SR-6] Zdecydowanie ZALECANE jest użycie narzędzia
SkiaVk
z HWUI.
Zakończ nowe wymagania
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 interfejsu Vulkan opisane tutaj , one:
- [C-3-1] MUSI udostępniać obsługę zewnętrznego semfora i uchwytu
SYNC_FD
i rozszerzenieVK_ANDROID_external_memory_android_hardware_buffer
.
Zacznij nowe wymagania
- [C-SR-7] Zdecydowanie ZALECANE jest wykonanie
VK_KHR_external_fence_fd
rozszerzenie dostępne dla aplikacji innych firm i włączenie aplikacji do eksportowania ładunku ogrodzenia do i importowania ładunku ogrodzenia z pliku POSIX deskryptory zgodnie z opisem tutaj.
Zakończ nowe wymagania
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 natomiast implementacje urządzeń nie obsługują wyświetlaczy o szerokim zakresie kolorów:
- [C-2-1] POWINNA pokryć co najmniej 100% pamięci sRGB w przestrzeni CIE 1931 xyY, chociaż gama kolorów ekranu jest nieokreślona.
7.1.5 Tryb zgodności starszych aplikacji
Android określa „tryb zgodności”, w którym platforma działa „normalny” tryb równoważny rozmiarem ekranu (szerokości 320 dp) aplikacje nieopracowane na starsze wersje Androida starsze niż niezależnie od rozmiaru ekranu.
7.1.6 Technologia ekranu
Platforma Androida zawiera interfejsy API, które umożliwiają aplikacjom renderowanie na wyświetlacz zgodny z Androidem. Urządzenia MUSZĄ obsługiwać wszystkie te funkcje Interfejsy API zdefiniowane w pakiecie Android SDK, chyba że jest to wyraźnie dozwolone w tym dokumencie.
Wszystkie ekrany w implementacji na urządzeniach zgodnych z Androidem:
- [C-0-1] MUSI obsługiwać 16-bitową grafikę w kolorach.
- NALEŻY obsługiwać wyświetlacze z 24-bitową grafiką w 24-bitowych kolorach.
- [C-0-2] MUSI wyświetlać animacje.
- [C-0-3] MUSI mieć współczynnik proporcji piksela (PAR) pomiędzy 0,9 a 1,15. Oznacza to, że proporcje piksela MUSZĄ być zbliżone do kwadratu (1,0) z tolerancją wynoszącą 10 ~ 15%.
7.1.7 Wyświetlacze dodatkowe
Android zapewnia obsługę dodatkowych wyświetlaczy zgodnych z tym systemem, funkcje udostępniania multimediów i interfejsy API dla programistów umożliwiające dostęp do wyświetlaczy zewnętrznych.
Jeśli urządzenia obsługują zewnętrzny wyświetlacz za pomocą przewodowego, bezprzewodowe lub połączenie z dodatkowym ekranem:
- [C-1-1] MUSI wdrożyć komponent
DisplayManager
i usług systemowych oraz interfejsu API zgodnie z opisem w dokumentacji pakietu Android SDK.
7.2. Urządzenia wejściowe
Implementacje na urządzeniach:
- [C-0-1] MUSI zawierać mechanizm wprowadzania danych, taki jak ekran dotykowy lub nawigacja bezdotykowa, do poruszania się między elementami interfejsu.
7.2.1. Klawiatura
Jeśli implementacje urządzeń obejmują obsługę rozwiązań innych firm aplikacje edytora metod wprowadzania (IME);
- [C-1-1] MUSI zadeklarować parametr
android.software.input_methods
flagę funkcji. - [C-1-2] MUSI obsługiwać w całości
Input Management Framework
- [C-1-3] MUSI mieć wstępnie zainstalowaną klawiaturę programową.
Implementacje na urządzeniach:
- [C-0-1] NIE MOŻE zawierać klawiatury sprzętowej, która nie pasuje do formatów określonych w argumencie android.content.res.Configuration.keyboard, (QWERTY lub 12-klawiszowy).
- POWINNY BYĆ dodatkowe implementacje klawiatury programowej.
- MOŻE zawierać klawiaturę sprzętową.
7.2.2 Nawigacja bezdotykowa
Android zapewnia obsługę pada kierunkowego, trackballa i kółka bezdotykowa nawigacja.
Implementacje na urządzeniach:
- [C-0-1] MUSI zgłaszać prawidłową wartość dla android.content.res.Configuration.navigation
Jeśli w urządzeniach nie ma nawigacji niedotykowej:
- [C-1-1] MUSI zapewniać uzasadniony alternatywny mechanizm interfejsu użytkownika zaznaczania i edytowania tekstu, kompatybilna z mechanizmami zarządzania danymi wejściowymi. implementacja open source Androida obejmuje mechanizm wyboru. odpowiedni do użytku z urządzeniami, które nie mają dotykowego, bezdotykowego wejścia do nawigacji.
7.2.3 Klawisze nawigacyjne
Strona główna, Ostatnie, i Wstecz funkcje obsługiwane zwykle przez interakcję z dedykowanym przyciskiem fizycznym lub odrębnej części ekranu dotykowego są niezbędne paradygmat nawigacji, a tym samym wdrożenia urządzeń:
- [C-0-1] MUSI zapewniać użytkownikowi możliwości uruchamiania zainstalowanych aplikacji
ma aktywność z elementem
<intent-filter>
ustawionym z 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. kliknięcia, dwukrotnego kliknięcia lub gestu palca), gdy którekolwiek z nich jest dostępne.
- [C-1-2] MUSI wyraźnie wskazywać, które działanie może wywołać działanie. dla każdej funkcji. z nadrukowaną ikoną na przycisku oraz informacją o oprogramowaniu; znajdującą się na pasku nawigacyjnym albo prowadząc użytkownika przez szczegółowe instrukcje konfigurowania podczas konfiguracji na przykłady tego typu wskazania.
Implementacje na urządzeniach:
Zdecydowanie ZALECANE jest nieudostępnianie mechanizmu wprowadzania danych dla funkcji Funkcja menu ponieważ w Androidzie 4.0 został wycofany pasek działań.
[C-SR-2] Zdecydowanie zaleca się zapewnić wszystkie funkcje nawigacyjne nie można anulować. „Można anulować” jest zdolność użytkownika do zapobiegania nie zostanie wykonana funkcja nawigacji (np. powrót do domu, powrót do domu itp.), jeśli funkcja nie udaje się przekroczyć określonego progu.
Jeśli implementacje urządzeń zapewniają funkcję menu, są to:
- [C-2-1] MUSI wyświetlać dodatkowy przycisk działania, gdy działanie nie jest puste, a pasek działań jest widoczny.
- [C-2-2] NIE MOŻE zmieniać pozycji wyskakującego okienka rozszerzonego działania wyświetlane po kliknięciu przycisku rozszerzonego na pasku działań, ale MOGĄ wyskakujące okienko działania w zmodyfikowanym położeniu na ekranie, gdy jest można wyświetlić po wybraniu funkcji menu.
Jeśli implementacje urządzeń nie udostępniają funkcji menu, w przypadku instrukcji wstecznych zgodność ze standardami:
- [C-3-1] MUSI udostępnić funkcję Menu aplikacjom, gdy
Wartość
targetSdkVersion
jest mniejsza niż 10 (przy użyciu fizycznego przycisku, klucza oprogramowania) lub gestami. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z z innych funkcji nawigacji.
Jeśli implementacje na urządzeniach udostępniają funkcję wspomagania, one:
- [C-4-1] MUSI udostępnić funkcję wspomagania jednym działaniem. (np. klikając, dwukrotnie lub przy użyciu gestów), gdy dostępne są inne klawisze nawigacyjne.
- [C-SR-3] Zdecydowanie zalecamy przytrzymanie funkcji ekranu głównego, ponieważ wyznaczonej interakcji.
Jeśli implementacje urządzeń wykorzystują osobną część ekranu do wyświetlania klawisze nawigacyjne:
- [C-5-1] Klawisze nawigacyjne MUSZĄ zajmować osobną część ekranu, nie i NIE MOŻE zasłaniać ani w inny sposób zakłócać fragmentu ekranu dostępnego dla aplikacji.
- [C-5-2] MUSI udostępniać część wyświetlacza aplikacjom, spełnia wymagania określone w sekcji 7.1.1.
- [C-5-3] MUSI uwzględniać flagi ustawione przez aplikację w
View.setSystemUiVisibility()
. API, aby ta charakterystyczna część ekranu (inaczej pasek nawigacyjny) jest poprawnie ukryty, jak opisano w pakietu SDK.
Jeśli funkcja nawigacji jest udostępniana na ekranie za pomocą gestów:
- [K-6–1]
WindowInsets#getMandatorySystemGestureInsets()
MOŻNA używać tylko do zgłaszania obszaru rozpoznawania gestów na ekranie głównym. - [C-6-2] Gesty rozpoczynające się w polu prostokątnym zdefiniowanym w parametrze
aplikacji działających na pierwszym planie za pośrednictwem
View#setSystemGestureExclusionRects()
ale 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ć przesuń palcem od lewej i prawej krawędzi bieżącej orientacji ekranu.
- [C-7-2] Jeśli po lewej stronie lub krawędzie, należy je umieścić w górnej 1/3 wyraźny, stały sygnał wizualny, że przeciągnięcie reklamy wywoła wspomnianych paneli, a więc nie Wstecz. Panel systemowy MOŻE być skonfigurowane przez użytkownika w taki sposób, że znajdują się poniżej 1/3 górnej części ekranu krawędzie, ale panel systemowy NIE MOŻE być dłuższy niż 1/3.
- [C-7-3] Gdy aplikacja na pierwszym planie ma albo View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub Ustawiono flagi WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SSTORAGE, przesunięcie od krawędzi MUSI działać tak samo jak w AOSP, o treściach udokumentowanych w pakiecie SDK.
- [C-7-4] Gdy aplikacja na pierwszym planie ma parametr View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub Ustawiono flagi WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SSTORAGE, niestandardowe przesuwane panele systemowe MUSZĄ być ukryte do czasu, aż użytkownik wejdzie Usuwa przyciemnienie pasków systemowych (tzw. nawigacji i paska stanu) po zaimplementowaniu w AOSP.
Jeśli dostępna jest funkcja przechodzenia wstecz, a użytkownik anuluje gestu, a następnie:
- [C-8-1] Trzeba zadzwonić do użytkownika
OnBackInvokedCallback.onBackCancelled()
. - [C-8-2] NIE NALEŻY wywoływać funkcji
OnBackInvokedCallback.onBackInvoked()
. - [C-8-3] Zdarzenie KEYCODE_BACK NIE MOŻE być wysyłane.
Jeśli podana jest funkcja przechodzenia wstecz, ale aplikacja na pierwszym planie ją
NIE masz zarejestrowanego konta OnBackInvokedCallback
, to wtedy:
- System powinien udostępnić animację na pierwszym planie, która sugeruje, że użytkownik wraca, zgodnie z AOSP.
Jeśli implementacje urządzeń zapewniają obsługę systemowego interfejsu API setNavBarMode
do
zezwól dowolnej aplikacji systemowej z uprawnieniami android.permission.STATUS_BAR
na ustawianie
trybu paska nawigacyjnego, a następnie:
- [C-9-1] MUSI obsługiwać ikony przyjazne dzieciom lub wykorzystujące przyciski nawigacji zgodnie z kodem AOSP.
7.2.4 Wprowadzanie tekstu z ekranu dotykowego
Android zapewnia obsługę różnych systemów wprowadzania danych wskaźnikach, takich jak ekrany dotykowe, pady dotykowe i imitacje dotykowych urządzeń wejściowych. Implementacje na urządzeniach z ekranem dotykowym są powiązane z reklamą displayową, tak aby użytkownik miał wrażenie, do manipulowania elementami na ekranie. Użytkownik dotyka bezpośrednio ekranu, system nie wymaga żadnych dodatkowych afordancji wskazujących obiekty być manipulowany.
Implementacje na urządzeniach:
- POWINNY jest mieć jakiś system wprowadzania danych z użyciem wskaźników (jak mysz lub dotyk).
- POWINNA obsługiwać w pełni niezależnie śledzone wskaźniki.
Jeśli urządzenia są wyposażone w ekran dotykowy (pojedynczy dotyk lub lepszy) głównych wyświetlaczy zgodnych z Androidem:
- [C-1-1] MUSI zgłosić
TOUCHSCREEN_FINGER
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 kliknięcia na głównym wyświetlaczu zgodnym z Androidem:
- [C-2-1] MUSI zgłosić odpowiednie flagi funkcji
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
android.hardware.touchscreen.multitouch.jazzhand
odpowiadający typowi ekranu dotykowego urządzenia.
korzystanie z zewnętrznego urządzenia wejściowego, takiego jak mysz czy kulka (tj. nie dotykając ekranu bezpośrednio) w celu wprowadzania na Wyświetlacz zgodny z Androidem i spełnianie wymagań dotyczących fałszywego dotyku art. 7.2.5:
- [C-3-1] NIE MOŻE zgłaszać żadnych flag funkcji rozpoczynających się od
android.hardware.touchscreen
- [C-3-2] MUSI zgłosić tylko
android.hardware.faketouch
. - [C-3-3] MUSI zgłosić użytkownika
TOUCHSCREEN_NOTOUCH
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 zmiana stanu występująca we wskaźniku w górę lub w dół ekranu.
- [C-1-3] MUSI obsługiwać wskaźnik w dół i w górę na obiekcie na ekranie, co pozwala emulować kliknięcie obiektu na ekranie.
- [C-1-4] MUSI obsługiwać wskaźnik w dół, wskaźnik w górę, wskaźnik w dół, a następnie w górę. w tym samym miejscu na obiekcie na ekranie w czasie, który umożliwia użytkownikom emulację dwukrotnego dotknięcia. na obiekcie na ekranie.
- [C-1-5] MUSI obsługiwać kursor w dowolnym punkcie na ekranie. przesuń wskaźnik do dowolnego innego punktu na ekranie, a po nim wskaźnik w górę, co umożliwia emulację przeciągnięcia dotykiem.
- [C-1-6] MUSI zapewniać wsparcie w dół, a następnie umożliwiać użytkownikom szybkie ustaw obiekt w innym miejscu na ekranie, a następnie wskaż kursorem w górę, które umożliwia użytkownikom przesuwanie obiektu na ekranie.
Jeśli implementacje urządzeń zadeklarują obsługę
android.hardware.faketouch.multitouch.distinct
, to:
- [C-2-1] MUSI zadeklarować obsługę interfejsu
android.hardware.faketouch
. - [C-2-2] MUSI obsługiwać odrębne śledzenie co najmniej dwóch niezależnych wskaźników danych wejściowych.
Jeśli implementacje urządzeń zadeklarują obsługę
android.hardware.faketouch.multitouch.jazzhand
, to:
- [C-3-1] MUSI zadeklarować obsługę interfejsu
android.hardware.faketouch
. - [C-3-2] MUSI obsługiwać odrębne śledzenie 5 (śledzenie dłoni) całkowicie niezależnie.
7.2.6 Obsługa kontrolera gier
7.2.6.1 Mapowania przycisków
Implementacje na urządzeniach:
- [C-1-1] MUSI być w stanie mapować zdarzenia HID na odpowiednie stałe
InputEvent
, jak podano w tabelach poniżej. Implementacja Androida spełnia to wymaganie.
Jeśli urządzenia są wyposażone w kontroler lub są dostarczane z osobnym kontrolerem, który umożliwiałby wprowadzanie wszystkich zdarzeń wymienionych w tabelach poniżej:
- [C-2-1] MUSI zadeklarować flagę funkcji
android.hardware.gamepad
Przycisk | Wykorzystanie HID2 | Przycisk Androida |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_PRZYCISK_A (96) |
B1 | 0x09 0x0002 | KEYCODE_PRZYCISK_B (97) |
X1 | 0x09 0x0004 | KEYCODE_PRZYCISK_X (99) |
T1 | 0x09 0x0005 | KEYCODE_PRZYCISK_Y (100) |
Górny pad kierunkowy1 Pad kierunkowy w dół1 |
0x01 0x00393 | AXIS_HAT_Y4 |
Pad kierunkowy w lewo1 Pad kierunkowy w prawo1 |
0x01 0x00393 | AXIS_HAT_X4 |
Przycisk na lewym ramieniu1 | 0x09 0x0007 | KEYCODE_Button_L1 (102) |
Przycisk na prawym ramieniu1 | 0x09 0x0008 | KEYCODE_PRZYCISK_R1 (103) |
Kliknięcie lewym drążkiem1 | 0x09 0x000E | KEYCODE_button_THUMBL (106) |
Kliknięcie prawym przyciskiem myszy1 | 0x09 0x000F | KEYCODE_button_THUMBR (107) |
Wstecz1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 Powyższe przypadki użycia HID muszą być zadeklarowane w grze pad CA (0x01 0x0005).
3 To użycie musi mieć wartość logiczną minimum 0, Logiczne maksimum: 7, fizyczne minimum: 0, fizyczne maksimum: 315, jednostki w stopniach i 4. Wartość logiczna jest zdefiniowana jako obracanie w prawo od osi pionowej; na przykład wartość logiczna 0 oznacza brak obrotu i naciśnięty przycisk w górę, a wartość logiczna 1 oznacza obrót o 45 stopni oraz klawisze w górę i w lewo są naciśnięto.
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 sposób rozsądny 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 wartości zużycie energii MUSI zawsze wynosić mniej niż 4 mW.
- Gdy urządzenie znajduje się w trybie dynamicznym lub statycznego warunku.
Jeśli urządzenia są wyposażone w 3-osiowy akcelerometr i 3-osiowy żyroskop, one:
- [C-5-1] MUSI wdrożyć zasady
TYPE_GRAVITY
iTYPE_LINEAR_ACCELERATION
i komponentów. - [C-SR-7] Zdecydowanie ZALECANE jest wdrożenie
Czujnik kompozytowy
TYPE_GAME_ROTATION_VECTOR
.
Jeśli w urządzeniach jest 3-osiowy akcelerometr, 3-osiowy żyroskop i czujnik magnetometru:
- [C-6-1] NALEŻY zastosować czujnik kompozytowy
TYPE_ROTATION_VECTOR
.
7.3.2 Magnetometr
Implementacje na urządzeniach:
- [C-SR-1] Zdecydowanie ZALECANE jest użycie 3-osiowego magnetometru (kompasu).
Jeśli urządzenia są wyposażone w 3-osiowy magnetometr:
- [C-1-1] MUSI zamocować czujnik
TYPE_MAGNETIC_FIELD
. - [C-1-2] MUSI raportować zdarzenia z częstotliwością co najmniej 10 Hz i POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 50 Hz.
- [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Android. jak podano w Interfejsy API dla Androida.
- [C-1-4] MUSI mierzyć od -900 μT do +900 μT w każdym przed nasyceniem.
- [C-1-5] MUSI mieć wartość przesunięcia twardego żelaza mniejszą niż 700 μT i POWINNA poniżej 200 μT, umieszczając magnetometr w odległości dynamicznych (wywołanych prądem) i statycznych (wywoływanych magnesem) pól magnetycznych.
- [C-1-6] MUSI mieć rozdzielczość równą lub większą niż 0,6 μT.
- [C-1-7] MUSI obsługiwać kalibrację online i kompensację twardego żelaza i zachować parametry kompensacji między restartami urządzeń.
- [C-1-8] MUSI zastosować kompensację miękkiego żelaza – kalibrację można zarówno podczas użytkowania, jak i produkcji urządzenia.
- [C-1-9] MUSI mieć odchylenie standardowe obliczone na podstawie jednej osi próbki zebrane w okresie co najmniej 3 sekund z najszybszym próbkowaniem współczynnik klikalności, nie większy niż 1,5 μT; Odchylenie standardowe musi mieć wartość nie większą niż 0,5 μT.
- [C-1-10] MUSI zaimplementować
TYPE_MAGNETIC_FIELD_UNCALIBRATED
.
Jeśli urządzenia są wyposażone w 3-osiowy magnetometr, akcelerometr i 3-osiowy żyroskop:
- [C-2-1] MUSI zaimplementować czujnik kompozytowy
TYPE_ROTATION_VECTOR
.
Jeśli urządzenia są wyposażone w 3-osiowy magnetometr (akcelerometr):
- MOŻESZ zastosować czujnik
TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
Jeśli urządzenia są wyposażone w 3-osiowy magnetometr, akcelerometr i
Czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
- [C-3-1] MUSI zużywać mniej niż 10 mW.
- POWINNO zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie wsadowym 10 Hz.
7.3.3 GPS
Implementacje na urządzeniach:
- [C-SR-1] Zdecydowanie ZALECANE jest użycie odbiornika GPS/GNSS.
Jeśli implementacje urządzeń obejmują odbiornik GPS/GNSS i poinformują o możliwości
do aplikacji za pomocą flagi funkcji android.hardware.location.gps
, spowoduje to:
- [C-1-1] MUSI obsługiwać dane wyjściowe z lokalizacją z częstotliwością co najmniej 1 Hz, gdy
wysłano prośbę za pośrednictwem:
LocationManager#requestLocationUpdate
. - [C-1-2] MUSI określić lokalizację na otwartym niebie
(silne sygnały, pomijane ścieżki wielościeżkowe, HDOP < 2) w ciągu 10 sekund (szybkie)
czas do pierwszej naprawy), przy połączeniu z szybkością co najmniej 0,5 Mb/s.
i połączenia z internetem. Ten wymóg jest zwykle spełniany przez zastosowanie
forma metody wspomaganego lub przewidywanego GPS/GNSS.
do zminimalizowania czasu blokady GPS/GNSS (dane pomocy obejmują czas odniesienia,
Lokalizacja odniesienia i satelitarny efemeris/zegar).
- [C-1-6] Po wyliczeniu lokalizacji implementacje MUSZĄ określić swoją lokalizację, na otwartym niebie, w po 5 sekundach, jeśli żądania lokalizacji są ponownie uruchamiane, maksymalnie do godziny po tym czasie. początkowe obliczenie lokalizacji, nawet jeśli kolejne żądanie wykonane bez połączenia do transmisji danych lub po wyłączeniu i włączeniu zasilania.
Na otwartym niebie po określeniu lokalizacji, na siedzącym lub poruszając się z przyspieszeniem poniżej 1 metra na sekundę do kwadratu:
- [C-1-3] MUSI określić lokalizację w promieniu 20 metrów i prędkość z dokładnością do 0,5 metra na sekundę, przez co najmniej 95% czasu.
- [C-1-4] MUSI jednocześnie śledzić i raportować przez
GnssStatus.Callback
co najmniej 8 satelitów z 1 konstelacji. - POWINNA być w stanie jednocześnie śledzić co najmniej 24 satelity, wiele konstelacji (np. GPS + przynajmniej jeden z Glonass, Beidou, Galileusza).
[C-SR-2] Zdecydowanie ZALECANE jest dalsze działanie normalnego systemu GPS/GNSS. dane o lokalizacji przesyłane za pomocą interfejsu GNSS Location Provider API w czasie połączenia alarmowego .
[C-SR-3] Zdecydowanie ZALECANE są raportowanie pomiarów GNSS we wszystkich śledzone konstelacje (zgodnie z raportem w komunikatach GnssStatus), z wyjątkiem przedsiębiorcy SBAS.
[C-SR-4] Zdecydowanie ZALECANE jest raportowanie AGC oraz częstotliwość GNSS pomiar skuteczności.
[C-SR-5] Zdecydowanie ZALECANE jest raportowanie wszystkich szacunków dokładności (w tym Orientacja, Prędkość i Orientacja pionowa) jako część każdej lokalizacji GPS/GNSS.
[C-SR-6] Zdecydowanie ZALECANE jest zgłaszanie pomiarów GNSS, gdy tylko nawet jeśli lokalizacja określona na podstawie GPS/GNSS nie została jeszcze zostało zgłoszone.
[C-SR-7] Zdecydowanie ZALECANE są zgłaszanie pseudozakresów GNSS i współczynniki pseudozakresów, które w warunkach na niebie po określeniu lokalizacji nieruchome lub poruszające się z szybkością mniejszą niż 0,2 metra na sekundę do kwadratu przyspieszenie, wystarczają do obliczenia pozycji z odległości do 20 metrów, a prędkość z dokładnością do 0,2 metra na sekundę, przez co najmniej 95% czasu.
7.3.4 Żyroskop
Implementacje na urządzeniach:
- [C-SR-1] Zdecydowanie ZALECANE jest użycie czujnika żyroskopu.
Jeśli urządzenia są wyposażone w ż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 ZALECAMY zakres pomiaru na poziomie co najmniej -16 g i +16 g.
- Rozdzielczość pomiaru MUSI mieć wartość co najmniej 2048 LSB/g.
- Minimalna częstotliwość pomiaru musi wynosić 12,5 Hz lub mniejszą.
- MUSI mieć maksymalną częstotliwość pomiaru 400 Hz lub większą. POWINNO
obsługuje SensorDirectChannel
RATE_VERY_FAST
. - Poziom szumu pomiarowego MUSZĄ być większy niż 400 μg/√Hz.
- MUSI zastosować czujnik nie wybudzany z buforowaniem z możliwością co najmniej 3000 zdarzeń z czujnika.
- Zużycie energii w grupie MUSI nie być mniejsze niż 3 mW.
- [C-SR-1] Zdecydowanie ZALECANE jest ustawienie przepustowości pomiaru na poziomie 3 dB na poziomie co najmniej 80% częstotliwości Nyquist i widmo białego szumu połączenia internetowego.
- W przypadku przyspieszenia testowane losowe spacery powinny mieć wartość mniejszą niż 30 μg √Hz temperatury w pomieszczeniu.
- MUSISZ mieć zmianę odchylenia w porównaniu z temperaturą na poziomie ≤ +/- 1 mg/°C.
- Optymalna nieliniowość w zakresie ≤ 0,5% oraz zmiana czułości względem temperatury na poziomie ≤ 0,03%/C°.
- Czułość krzyżowa powinna wynosić < 2,5 % i zmienność czułość obrazu na osi < 0,2% w zakresie temperatur działania urządzenia.
[C-2-2] MUSI mieć
TYPE_ACCELEROMETER_UNCALIBRATED
o takim samym identyfikatorze wymagania dotyczące jakości na 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.
- Wymagana jest minimalna częstotliwość pomiaru 12,5 Hz lub mniejsza.
- 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 dostarczać 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:
Zacznij nowe wymagania
[C-7-1] MUSI być wyłączony, gdy urządzenie biometryczne jest zablokowane (tzn. jeśli dane biometryczne są wyłączone do momentu odblokowania urządzenia za pomocą uwierzytelniania podstawowego) lub tymczasowej blokady (np. dane biometryczne są tymczasowo wyłączone, dopóki użytkownik nie poczeka przez jakiś czas (interwał) z powodu zbyt wielu nieudanych prób, zablokuj też wszystkie pozostałe dane biometryczne z niższej klasy. W przypadku blokady ograniczonej czasowo czas do ponowienia w przypadku weryfikacji biometrycznej MUSI być maksymalnym czasem ponowienia wszystkich danych biometrycznych z blokadą z ograniczeniem czasowym.
[C-SR-12] Są Zdecydowanie ZALECANE, gdy dane biometryczne są zablokowane (np. dane biometryczne są wyłączone, dopóki użytkownik nie odblokuje się za pomocą podstawowego uwierzytelniania) lub blokada ograniczona czasowo (tzn. biometria jest tymczasowo wyłączona do (oczekuje określony przedział czasu) z powodu zbyt wielu nieudanych prób, aby zablokować wszystkie pozostałe funkcje biometryczne z tej samej klasy. W przypadku blokada ograniczona czasowo, czas do ponowienia w przypadku weryfikacji biometrycznej BARDZO ZALECANY jest maksymalnym czasem do ponowienia w przypadku wszystkich danych biometrycznych w określonym czasie. blokady.
[C-7-2] MUSI wymagać od użytkownika skonfigurowania zalecanego podstawowego uwierzytelniania (np. kod PIN, wzór, hasło) do zresetowania licznika blokady uwierzytelniania biometrycznego dostęp do informacji. Urządzenie biometryczne klasy 3 MOŻE zresetuje blokadę dla zablokowanej metody biometrycznej tej samej lub niższej klasy. Klasa 2 lub Urządzenia biometryczne klasy 1 NIE MOGĄ mieć możliwości dokończenia blokady resetowania w przypadku dowolnej biometrii.
Zakończ nowe wymagania
- [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.
Zacznij nowe wymagania
[C-1-12] MUSI mieć współczynnik akceptacji fałszywych informacji niż 40% gatunków przyrządów atakujących (PAI) – zgodnie z pomiarami Protokoły testów biometrycznych Androida.
[C-SR-13] Zdecydowanie ZALECANE jest wyrażenie zgody na podszywanie się pod inne osoby odsetek gatunków przyrządów atakujących (PAI) nie wyższy niż 30%, zgodnie z danymi protokołów testów biometrycznych Androida.
[C-SR-14] Zdecydowanie ZALECANE jest podanie klasy biometrycznej czujnika biometrycznego i powiązane z nim ryzyko jego włączenia.
[C-SR-17] Zdecydowanie ZALECANE jest wdrożenie nowych interfejsów AIDL. (na przykład
IFace.aidl
iIFingerprint.aidl
).
Zakończ nowe wymagania
Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 2. (dawniej Słabe), to:
[C-2-1] MUSI spełniać wszystkie wymagania dotyczące klasy 1 powyżej.
[C-2-2] MUSI mieć współczynnik akceptacji imitacji nie wyższy niż 20%, z (1) współczynnikiem akceptacji fałszywych informacji dla Gatunek instrumentu atakowego poziomu A (PAI) nie więcej niż 20%, oraz (2) współczynnik akceptacji i oszustw w przypadku gatunku PAI poziomu B, które nie są zgodne z zasadami. powyżej 30%, co mierze Protokoły testów biometrycznych Androida.
Zacznij nowe wymagania
- [C-SR-15] Zdecydowanie ZALECANE jest wyrażenie zgody na podszywanie się pod inne osoby współczynnik nie wyższy niż 20% na narzędzie do ataku na prezentację (PAI) gatunków, co jest mierzone przez Protokoły testów biometrycznych Androida.
Zakończ nowe wymagania
- [C-2-3] MUSI wykonać
dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza Androidem
użytkownika lub przestrzeni jądra systemu, takiego jak Trusted Execution Environment (TEE),
lubna układzie z bezpiecznym kanałem i izolowanym środowiskiem wykonawczym lub na chronionej maszynie wirtualnej spełniającej wymagania artykułu 9.17. - [C-2-4] MUSI mieć zaszyfrowane i kryptograficzne dane umożliwiające identyfikację uwierzytelnionych w taki sposób, że nie można ich pozyskać, odczytać ani zmienić poza izolowane środowisko wykonawcze lub układ z bezpiecznym kanałem izolowane środowisko wykonawcze, zgodnie z opisem w implementacji wytycznych w witrynie Android Open Source Project lub chronionej maszyny wirtualnej kontrolowanej przez hipernadzorcę, która spełnia wymagania podane w artykule 9.17.
- [C-2-5] Uwierzytelnianie biometryczne z użyciem aparatu i uwierzytelnianie biometryczne
lub rejestracja ma miejsce:
- MUSI obsługiwać aparat w trybie, który uniemożliwia być odczytywana lub zmieniana poza izolowanym środowiskiem wykonawczym lub elementem z bezpiecznym kanałem izolowanego środowiska wykonawczego. lub chronionej maszyny wirtualnej sterowanej przez hipernadzorcę, która spełnia wymagania podane w artykule 9.17.
- W przypadku rozwiązań RGB z jedną kamerą ramki aparatu mogą być czytelna poza izolowanym środowiskiem wykonawczym na potrzeby operacji np. podglądu rejestracji, ale NIE WOLNO zmieniać tego ustawienia.
- [C-2-6] NIE MOŻE umożliwiać aplikacjom innych firm odróżniania rejestracje biometryczne.
- [C-2-7] NIE MOŻE umożliwiać niezaszyfrowanego dostępu do danych biometrycznych możliwych do zidentyfikowania ani wszelkich danych uzyskanych z niej (takich jak wektory dystrybucyjne) do Podmiotu przetwarzającego aplikację poza kontekstem TEE. lub chronionej maszyny wirtualnej kontrolowanej przez hipernadzorcę, która spełnia wymagania podane w artykule 9.17. Uaktualnienie urządzeń z Androidem w wersji 9 lub starszej nie jest wyjątkiem od kierownictwa C-2-7.
[C-2-8] MUSI mieć bezpieczny potok przetwarzania, tak aby w wyniku naruszenia zabezpieczeń systemu lub jądra nie można zezwolić na bezpośrednie wstrzykiwanie danych nie uwierzytelniają się jako użytkownik. Uwaga: jeśli implementacje na urządzeniach zostały już wdrożone na urządzeniach z Androidem w wersji 9 lub wcześniej i nie może spełnić wymagań C-2-8 za pomocą oprogramowania systemowego aktualizacja, MOŻE być zwolniona z obowiązku spełnienia tego wymogu.
[C-SR-10] Zdecydowanie ZALECANE jest włączenie wykrywania żywotności w przypadku wszystkich modalności biometrycznej i wykrywania uwagi na potrzeby biometrii twarzy.
[C-2-9] MUSI udostępnić czujnik biometryczny innej firmy aplikacji.
Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 3. (dawniej Silne):
- [C-3-1] MUSI spełniać wszystkie wymagania klasy 2 powyżej oprócz [C-1-7] i [C-1-8].
- [C-3-2] MUSI mieć implementację magazynów kluczy wspieranych sprzętowo.
- [C-3-3] MUSI mieć współczynnik akceptacji imitacji nie wyższy niż 7%. z (1) współczynnikiem akceptacji fałszywych informacji dla gatunków instrumentów atakowych poziomu A (PAI) – nie więcej niż 7% gatunków; (2) współczynnik akceptacji imitacji przez oszustów lub innych gatunków pochodzących z PAI na poziomie B nie jest wyższy niż 20%, co mierzy Protokoły testów biometrycznych Androida.
- [C-3-4] MUSI wymagać od użytkownika pytania o zalecaną trasę podstawową uwierzytelnianie (np. kod PIN, wzór, hasło) 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.
Zacznij nowe wymagania
- [C-SR-16] Zdecydowanie ZALECANE jest wyrażenie zgody na podszywanie się pod inne osoby odsetek gatunków instrumentów atakujących (PAI) nie wyższy niż 7%, zgodnie z danymi protokołów testów biometrycznych Androida.
Zakończ nowe wymagania
Jeśli urządzenia mają czytnik linii papilarnych pod wyświetlaczem: one:
- [C-SR-11] Zdecydowanie ZALECANE jest niedostosowanie do dotykowego obszaru UDFPS. zakłócające nawigację przy użyciu 3 przycisków( co niektórzy użytkownicy mogą wymagać związane z ułatwieniami dostępu).
7.3.11. Czujnik pozycji
Implementacje na urządzeniach:
- MOŻE obsługiwać czujnik pozycji z 6 stopniami swobody.
Jeśli implementacje urządzeń obsługują czujnik pozycji z sześcioma stopniami swobody:
- [C-1-1] MUSI wdrożyć i zgłosić stronę
TYPE_POSE_6DOF
. - [C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.
7.3.12. Czujnik kąta nachylenia
Jeśli urządzenia obsługują czujnik kąta zawiasu:
- [C-1-1] MUSI wdrożyć i zgłosić stronę
TYPE_HINGLE_ANGLE
. - [C-1-2] MUSI obsługiwać co najmniej dwa odczyty od 0 do 360 stopni (włącznie, tzn. w tym od 0 do 360 stopni).
- [C-1-3] MUSI zwrócić wybudzenie
czujnik dla:
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.3.13. IEEE 802.1.15.4 (UWB)
Jeśli implementacje urządzeń obsługują standard 802.1.15.4 i udostępniają aplikacji innej firmy:
Zacznij nowe wymagania
- [C-1-2] MUSI zgłosić flagę funkcji sprzętowej
android.hardware.uwb
. - [C-1-3] MUSI obsługiwać wszystkie następujące zestawy konfiguracji (wstępnie zdefiniowane
kombinacji parametrów FIRA UCI)
zdefiniowane w implementacji AOSP.
CONFIG_ID_1
: zdefiniowany przez FiRa zakres typu unicastSTATIC STS DS-TWR
, tryb odroczenia z odstępem 240 ms.CONFIG_ID_2
: zdefiniowany przez FiR zakresSTATIC STS DS-TWR
w zakresie jeden do wielu, tryb odroczenia z zakresu 200 ms. Typowe zastosowanie: smartfon współdziała z wieloma urządzeniami.CONFIG_ID_3
: taka sama jakCONFIG_ID_1
, oprócz kąta przyjazdu (AoA) nie są uwzględniane w raportach.CONFIG_ID_4
: taki sam jak w przypadkuCONFIG_ID_1
, z wyjątkiem trybu zabezpieczeń P-STS: .CONFIG_ID_5
: taki sam jak w przypadkuCONFIG_ID_2
, z wyjątkiem trybu zabezpieczeń P-STS: .CONFIG_ID_6
: taki sam jak w przypadkuCONFIG_ID_3
, z wyjątkiem trybu zabezpieczeń P-STS: .CONFIG_ID_7
: taki sam jakCONFIG_ID_2
, oprócz indywidualnego kontrolera P-STS włączony jest tryb klawisza.
- [C-1-4] MUSI udostępniać informacje o produkcie, aby użytkownik mógł przełączyć UWB stanu włączenia/wyłączenia radia.
- [C-1-5] MUSI wymuszać, aby aplikacje korzystające z radia UWB zawierały
UWB_RANGING
(w grupie uprawnieńNEARBY_DEVICES
).
zaliczenie odpowiednich testów zgodności i certyfikatów określonych w standardzie. organizacji, w tym FIRA, CC oraz CSA zapewnia prawidłowe działanie standardu 802.1.15.4.
Zakończ nowe wymagania
7.4 Połączenie transmisji danych
7.4.1 Telefonia
Termin „telefonia” jest używany w interfejsach API Androida, a w tym dokumencie związane z nawiązywaniem połączeń głosowych i wysyłaniem wiadomości SMSoraz komunikacją komórkową za pośrednictwem sieci komórkowej (np. GSM, CDMA, LTE, NR) GSM lub CDMA. Urządzenie obsługujące „Połączenia telefoniczne” może oferować niektóre lub wszystkie usługi połączeń, wiadomości i transmisji danych odpowiednio do swoich potrzeb.
przez sieć GSM lub CDMA. Te połączenia głosowe mogą, ale nie muszą, podlegać przełączanie pakietów, ale do celów związanych z Androidem uważa się je za niezależne od wszelkich transmisji danych, które mogą być realizowane w tej samej sieci. Innymi słowy,funkcje „telefonii” i interfejsy API w Androidzie odnoszą się w szczególności do połączeń głosowych i SMS-ów. Na przykład urządzenia, które nie mogą nawiązywać połączeń ani wysyłać/odbierać SMS-ów, nie są uznawane za urządzenia telefoniczne, niezależnie od tego, czy korzystają z sieci komórkowej do przesyłania danych.
- Android MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. 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ą innych 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ć
android.hardware.telephony.ims.singlereg
flagę funkcji i zapewnić pełną implementację interfejsu SipTransport API. interfejs API GbaService, dedykowanych użytkowników za pomocą HAL IRadio 1.6 oraz udostępnianie przy użyciu serwera automatycznej konfiguracji (ACS) lub innej zastrzeżonej obsługi administracyjnej za pomocą interfejsu IMS Configuration API.
Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.telephony
:
- [C-6-1]
SmsManager#sendTextMessage
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
klucz dodatków na jego kluczu 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 lub ff02::fb)
w dowolnym momencie działania, również gdy ekran
nie jest w stanie aktywnym, chyba że usunięcie lub odfiltrowanie tych pakietów jest
niezbędne do utrzymania zużycia energii w zakresach wymaganych przez przepisy,
wymagania obowiązujące na rynku docelowym.
W przypadku implementacji na urządzeniach Android TV nawet w stanie gotowości. - [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 przez 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:
- POWINNO_obsługiwać lokalizację przez Wi-Fi.
Jeśli implementacje urządzeń obejmują obsługę lokalizacji Wi-Fi i udostępniają funkcji aplikacji innych firm, to:
- [C-1-1] MUSI wdrożyć interfejsy API
WifiRttManager
w sposób opisany w Dokumentacja pakietu SDK. - [C-1-2] MUSI zadeklarować flagę funkcji
android.hardware.wifi.rtt
. - [C-1-3] MUSI randomizować źródłowy adres MAC w przypadku każdej serii RTT który jest wykonywany podczas korzystania z interfejsu Wi-Fi używanego przez RTT nie jest powiązany z punktem dostępu.
- [C-1-4] MUSI być dokładność z dokładnością do 2 metrów przy przepustowości 80 MHz przy 68 MHz percentyl (obliczany za pomocą funkcji rozkładu skumulowanego).
- [C-SR-1] Zdecydowanie ZALECANE jest raportowanie go z dokładnością do 1,5 metra. przy przepustowości 80 MHz w 68 centylu (zgodnie z obliczeniem funkcja rozkładu skumulowanego).
7.4.2.6 Odciążanie Wi-Fi
Implementacje na urządzeniach:
- POWINNO_obsługiwać odciążanie Wi-Fi.
jeśli implementacje urządzeń obsługują odciążanie Wi-Fi, i udostę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)
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.Przeniesione wymagania [C-10-3] i [C-10-4] do 2.2.1. Urządzenie.
- [C-10-3] MUSI mierzyć i kompensować przesunięcie Rx do
upewnij się, że mediana BLE RSSI wynosi -55 dBm +/-10 dB w odległości 1 m od
urządzenie referencyjne przesyłające w źródle
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] MUSI mierzyć i kompensować przesunięcie przesunięcia do
upewnij się, że mediana BLE RSSI wynosi -55 dBm +/-10 dB podczas skanowania z użyciem pliku referencyjnego
znajduje się w odległości 1 m i przesyła z częstotliwości
ADVERTISE_TX_POWER_HIGH
Zdecydowanie ZALECANE jest wykonanie kroków konfiguracji pomiaru podanych w artykule Wymagania dotyczące kalibracji 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 np. 802.11 (Wi-Fi), w przypadku użycia sieci fizycznej (np. Ethernet) jest podstawowym połączeniem transmisji danych.
- MOŻESZ wdrożyć więcej niż jedną formę połączeń danych.
7.4.5.2 IPv6
Implementacje na urządzeniach:
- [C-0-2] MUSI zawierać stos sieci IPv6 i obsługiwać IPv6
komunikacji przy użyciu zarządzanych interfejsów API, takich jak
java.net.Socket
,java.net.URLConnection
oraz natywne interfejsy API, takie 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 w
android.hardware.se.omapi.uicc
dla urządzeń z elementami bezpiecznymi opartymi na UICC,android.hardware.se.omapi.ese
dla urządzeń z elementami zabezpieczonymi opartymi na eSE,android.hardware.se.omapi.sd
dla urządzenia z zabezpieczonymi elementami opartymi na SD.
7.4.9. UWB
Jeśli implementacje urządzeń obejmują obsługę w wersji 802.1.15.4 i udostępnić ją aplikacji innej firmy, to:
- [C-1-1] MUSI zaimplementować odpowiedni interfejs API Androida w pliku android.uwb.
- [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.uwb.
- [C-1-3] MUSI obsługiwać wszystkie odpowiednie profile UWB zdefiniowane w Androidzie implementacji.
- [C-1-4] MUSI udostępniać informacje o produkcie, aby użytkownik mógł przełączyć UWB stanu włączenia/wyłączenia radia.
- [C-1-5] MUSI wymuszać, aby aplikacje korzystające z radia UWB miały uprawnienie UWB_RANGING (w grupie uprawnień NEARBY_devices).
- [C-SR-1] Zdecydowanie ZALECANE jest przejście odpowiedniej zgodności i testów certyfikacyjnych zdefiniowanych przez standardowe organizacje, w tym FIRA, CCC i CSA.
- [C-1-6] MUSI mieć pewność, że pomiar odległości wynosi +/-15 cm w przypadku 95%. w miejscu widoczności z odległości 1 m w komorze nieodbiciowej.
- [C-1-7] MUSI zapewnić medianę odległości 1 m
z urządzenia referencyjnego znajduje się w promieniu [0,75 m; 1,25 m], gdzie dane podstawowe
odległość jest mierzona od górnej krawędzi urządzenia DUT.
Trzymając urządzenie pionową powierzchnią do góry i przechylone o 45 stopni. - [C-SR-2] Zdecydowanie ZALECANE jest wykonanie czynności wymaganych do konfiguracji pomiaru. określona w Wymagania dotyczące kalibracji obecności
7.5 Aparaty
Jeśli implementacje urządzeń obejmują co najmniej jedną kamerę:
- [C-1-1] MUSI zadeklarować flagę funkcji
android.hardware.camera.any
. - [C-1-2] MUSI być dostępna, aby aplikacja mogła jednocześnie przydzielać 3 mapy bitowe RGBA_8888 równe rozmiarowi obrazów wygenerowanych przez czujnika aparatu o największej rozdzielczości na urządzeniu, a aparat jest otwarty na potrzeby podstawowej wersji przedpremierowej.
- [C-1-3] MUSI mieć pewność, że zainstalowana jest domyślna aplikacja aparatu.
intencji obsługi
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, 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.
Zacznij nowe wymagania
Tylny aparat to aparat skierowany w stronę świata, który rejestruje sceny z daleka jak w przypadku tradycyjnego aparatu fotograficznego, na urządzeniach mobilnych, czyli aparatach, który znajduje się z boku urządzenia, naprzeciwko wyświetlacza.
Zakończ nowe wymagania
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.
Zacznij nowe wymagania
Przedni aparat to aparat skierowany do użytkownika, zwykle używany do robienia zdjęć. użytkownika, np. do obsługi rozmów wideo i podobnych aplikacji; na urządzeniu przenośnym czyli kamerę znajdującą się po tej samej stronie co wyświetlacz.
Zakończ nowe wymagania
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
Zacznij nowe wymagania
Kamera zewnętrzna to kamera, którą można fizycznie zamocować lub odłączyć. implementacji urządzenia w dowolnym momencie i mogą wystąpić w dowolnym kierunku; Na przykład USB kamery.
Zakończ nowe wymagania
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Ą uwzględniać 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] Urządzenia z wieloma kamerami RGB
są blisko siebie i są skierowane w tym samym kierunku,
Zdecydowanie zaleca się korzystanie z aparatu logicznego, który wyświetla listę
zdolność
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, obejmujący wszystkie kamery RGB skierowane w tym kierunku jako fizyczne urządzenia podrzędne.
Jeśli implementacje urządzeń udostępniają aplikacjom innych firm zastrzeżony interfejs API aparatu, one:
- [C-1-1] MUSI wdrożyć taki interfejs API aparatu za pomocą
android.hardware.camera2
API. - MOŻE udostępniać tagi lub rozszerzenia dostawców do
android.hardware.camera2
API.
7.5.5 Orientacja aparatu
Jeśli urządzenia mają aparat przedni lub tylny:
- [C-1-1] MUSI być zorientowana tak, by długi wymiar kamery był równy do długości ekranu. Oznacza to, że gdy urządzenie jest trzymane poziomo. aparaty MUSZĄ robić zdjęcia w orientacji poziomej. Ten obowiązuje niezależnie od naturalnej orientacji urządzenia; czyli dotyczy z urządzeniami głównymi w orientacji poziomej i pionowej.
Urządzenia, które spełniają wszystkie poniższe kryteria, są zwolnione z tego wymogu:
- Urządzenie ma ekrany o zmiennej geometrii, np. składane lub zawiasowe. i wyświetlacze.
- Gdy zmieni się stan złożenia lub zawiasu, urządzenie przełącza się od orientacji pionowej do podstawowej i poziomej.
Zacznij nowe wymagania
- Implementacje urządzeń, które nie mogą być rotowane przez użytkownika, takie jak jak urządzenia motoryzacyjne.
Zakończ nowe wymagania
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 dostęp do nich jest uzyskiwany w aplikacji
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 Zajęcia audio USB zgodnie z dokumentacją pakietu Android SDK.
- POWINNO obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB podczas hosta tryb; reklamujesz źródło prądu o wartości co najmniej 1,5 A, jak określono w Sekcja Parametry zakończenia Wersja 1.2 ze specyfikacją kabla USB typu C dla USB typu C lub korzystanie z zakresu prądu wyjściowego CDP (CDP) jako określona w tagu Specyfikacja ładowania baterii przez USB, wersja 1.2 dla złączy Micro-AB.
- KONIECZNIE jest wdrożenie i obsługa standardów USB typu C.
Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i port USB, podczas lekcji audio:
- [C-2-1] MUSI obsługiwać klasę USB HID.
- [C-2-2] MUSI obsługiwać wykrywanie i mapowanie tych danych HID
określone w tabelach użytkowania USB HID.
oraz Voice Command Usage Request
do
KeyEvent
takie jak poniżej:- Identyfikator wykorzystania strony użycia (0xC) (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- Identyfikator wykorzystania strony wykorzystania (0xC) (0x0E9):
KEYCODE_VOLUME_UP
- Identyfikator wykorzystania strony wykorzystania (0xC) (0x0EA):
KEYCODE_VOLUME_DOWN
- Identyfikator wykorzystania strony użycia (0xC) (0x0CF):
KEYCODE_VOICE_ASSIST
- 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 lub sieć komórkowa nie obejmuje „portu wyjściowego”.
7.8.2.1 Analogowe porty audio
Aby zapewnić zgodność z słuchawki i inne akcesoria audio z wtyczki audio 3,5 mm w całym ekosystemie Androida, jeśli urządzenie Możliwe zastosowania obejmują co najmniej jeden analogowy port audio. Są to:
- [C-SR-1] Zdecydowanie ZALECANE jest dodanie co najmniej jednej porty audio jako 4-kanałowe gniazdo słuchawek 3,5 mm.
Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3, 5 mm:
- [C-1-1] MUSI obsługiwać odtwarzanie dźwięku w słuchawkach stereo i zestawach słuchawkowych stereo za pomocą mikrofonu.
- [C-1-2] MUSI obsługiwać wtyczki audio TRRS w kolejności styków CTIA.
- [C-1-3] MUSI obsługiwać wykrywanie i mapowanie kodów klawiszy w
poniżej 3 zakresów równoważnych impedancji między mikrofonem a podłożem
przewodniki na wtyczce audio:
- Maks. 70 omów:
KEYCODE_HEADSETHOOK
- 210–290 omów:
KEYCODE_VOLUME_UP
- 360–680 omów:
KEYCODE_VOLUME_DOWN
- 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 dźwięku bliskiego ultradźwięku za pośrednictwem AudioManager.getWłaściwość 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
Zacznij nowe wymagania
Urządzenia przeznaczone do noszenia w ręce lub noszenia mogą obsługiwać reakcję haptyczną o ogólnym zastosowaniu. aktywator, dostępny dla aplikacji m.in. w celu zwrócenia uwagi dzwonki, alarmy, powiadomienia, a także ogólne sygnały dotykowe.
Jeśli implementacje urządzeń NIE zawierają tego ogólnego przeznaczenia czujnika haptycznego, one:
- [7.10/C] MUSI zwracać wartość fałsz dla funkcji
Vibrator.hasVibrator()
.
Jeśli implementacje urządzenia OBEJMUJĄ co najmniej jeden taki ogólny czujnik haptyczny użytkownika, to:
- [C-1-1] MUSI zwracać wartość „prawda” dla funkcji
Vibrator.hasVibrator()
. - NIE NALEŻY używać ekscentrycznego mechanizmu haptycznego (wibratora) z niecentryczną obrotową masą (ERM).
- NALEŻY zastosować wszystkie publiczne stałe, aby uzyskać wyraźne czujniki haptyczne.
w
android.view.HapticFeedbackConstants
(CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
iGESTURE_END
). - NALEŻY zastosować wszystkie publiczne stałe, aby uzyskać wyraźne czujniki haptyczne.
w
android.os.VibrationEffect
(EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
iEFFECT_DOUBLE_CLICK
) i wszystkie możliwe publiczne stałePRIMITIVE_*
dla reakcja haptyczna zaandroid.os.VibrationEffect.Composition
CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Niektóre z tych elementów podstawowych, na przykładLOW_TICK
aSPIN
może być możliwe tylko wtedy, gdy wibracje obsługują stosunkowo słabą jakość częstotliwości. - MUSISZ przestrzegać wytycznych dotyczących mapowania stałych publicznych
w
android.view.HapticFeedbackConstants
na zalecaną wartośćandroid.os.VibrationEffect
stałe o odpowiednich zależnościach amplitudy. - NALEŻY użyć tych połączonych stałych wartości haptycznych (mapowania).
- MUSI spełniać ocenę jakości.
dla
createOneShot()
icreateWaveform()
API. - MUSI sprawdzić, czy wynik publiczny
android.os.Vibrator.hasAmplitudeControl()
Interfejs API poprawnie odzwierciedla możliwości wibracji. - NALEŻY sprawdzić możliwości skalowalności amplitudy, uruchamiając polecenie
android.os.Vibrator.hasAmplitudeControl()
.
Jeśli implementacje urządzeń postępują zgodnie z mapowaniem stałych haptycznych:
- NALEŻY sprawdzić stan implementacji, uruchamiając polecenie
android.os.Vibrator.areAllEffectsSupported()
iandroid.os.Vibrator.arePrimitivesSupported()
API. - MUSISZ przeprowadzić ocenę jakości dla stałych haptycznych.
- TRZEBA zweryfikować i w razie potrzeby zaktualizować konfigurację zastępczą dla nieobsługiwane elementy podstawowe opisane we wskazówkach dotyczących implementacji. dla stałych.
- MUSI zapewnić pomoc zastępczą, aby zmniejszyć ryzyko awarii zgodnie z opisem tutaj.
Zakończ nowe wymagania
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żywany w trybie gotowości aplikacji.
- [C-1-4] MUSI wdrożyć zasobniki gotowości aplikacji i Uśpienie zgodnie z opisem w sekcji Zarządzanie zasilaniem.
- [C-1-5] MUSI zwrócić
true
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ż zasobnik gotowości do rzadkich aplikacji, zapoznaj się z sekcją 3.5.1.
Oprócz trybów oszczędzania energii wdrożenia na urządzeniach z Androidem MAJ zastosuj dowolny lub wszystkie 4 stany uśpienia, określone w Zaawansowanych Configuration and Power Interface (ACPI).
Jeśli implementacje urządzeń stosują stany zasilania S4 określone w ACPI:
- [C-1-1] MUSI wejść w ten stan tylko po wykonaniu wyraźnego działania przez użytkownika przełączyć urządzenie w stan nieaktywny (np. przez zamknięcie pokrywy, która fizycznie części urządzenia lub wyłączenia pojazdu lub telewizora) i przed użytkownik ponownie aktywuje urządzenie (np.otwierając pokrywę lub obracając pojazd). lub telewizor).
Jeśli implementacje urządzeń stosują stany zasilania S3 zdefiniowane w ACPI:
[C-2-1] MUSI spełniać powyższe wymagania C-1-1 lub MUSI wprowadzać stan S3 tylko w przypadku aplikacje nie potrzebują zasobów systemowych (np. ekranu czy procesora).
I na odwrót: MUSI wyjść ze stanu S3, gdy aplikacje innych firm wymagają wywołania zasobów systemowych, jak opisano w tym pakiecie SDK.
Gdy na przykład aplikacje innych firm proszą o zachowanie ekranu włącz do
FLAG_KEEP_SCREEN_ON
lub nie wyłączaj 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
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 (oraz APEX) i należących do podzbioru uprawnień poszczególnych aplikacji umieszczonych na liście dozwolonych. Implementacja AOSP spełnia to wymaganie, czytając i przestrzegając dostęp do wszystkich aplikacji z listy dozwolonych,etc/permissions/
i użycie ścież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.
[C-0-5] NIE MOŻE przyznawać aplikacjom żadnych uprawnień w czasie działania, chyba że:
- są instalowane w momencie wysyłki urządzenia ORAZ
Zgodę użytkownika można uzyskać przed złożeniem wniosku korzysta z tych uprawnień,
LUB
Przyznano uprawnienia w czasie działania aplikacji przez domyślną zasadę przyznawania uprawnień lub pełnienia roli na platformie.
[C-0-6] MUSI przyznać uprawnienie
android.permission.RECOVER_KEYSTORE
tylko w przypadku aplikacji systemowych rejestrujących prawidłowo zabezpieczonego agenta odzyskiwania. O poprawnie zabezpieczony agent odzyskiwania jest zdefiniowany jako agent oprogramowania na urządzeniu; która synchronizuje się ze zdalnej pamięci masowej poza urządzeniem, która zawiera bezpieczny sprzęt z odpowiednią ochroną lub silniejszym opisane w Usługa Google Cloud Key Vault Service aby zapobiec atakom brute-force na podstawie wiedzy na ekranie blokady.
Implementacje na urządzeniach:
[C-0-7] MUSI przestrzegać właściwości dostępu do lokalizacji na Androidzie, gdy aplikacja wysyła żądanie danych o lokalizacji lub aktywności fizycznej za pomocą standardowego interfejsu API Androida. lub zastrzeżonego mechanizmu. Dane te obejmują między innymi:
- Lokalizacja urządzenia (np. szerokość i długość geograficzna) zgodnie z opisem w sekcji art. 9.8.8.
- Informacje, które mogą służyć do określenia lub oszacowania lokalizacja (np. identyfikator SSID, BSSID, identyfikator komórkowy lub lokalizacja sieci, urządzenie, z którym jest połączone urządzenie).
- Aktywność fizyczna lub klasyfikacja aktywności użytkownika.
Mówiąc bardziej szczegółowo o implementacjach na urządzeniach:
- [C-0-8] MUSI uzyskać zgodę użytkownika na dostęp do dane o lokalizacji czy aktywności fizycznej.
- [C-0-9] MUSI przyznawać uprawnienia w czasie działania TYLKO aplikacji, która zawiera
wystarczających uprawnień zgodnie z opisem w pakiecie SDK.
Przykład:
Menedżer połączeń#getServiceState
wymaga
android.permission.ACCESS_FINE_LOCATION
).
Jedynym wyjątkiem od powyższych właściwości dotyczących dostępu do lokalizacji na Androidzie są te, aplikacje nie mające dostępu do Lokalizacji w celu określenia lub ustalania lokalizacji użytkownika; a konkretnie:
- Gdy aplikacje mają uprawnienie
RADIO_SCAN_WITHOUT_LOCATION
. - W celach związanych z konfiguracją urządzenia, gdzie aplikacje systemowe przechowują
Uprawnienie
NETWORK_SETTINGS
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 urządzeń
sekcje
„9.8.6 Rejestrowanie treści”„9.8.6 Dane na poziomie systemu operacyjnego i dźwięku otoczenia oraz 9.8.15 Implementacje interfejsu API w trybie piaskownicy”.
- [C-4-2] NIE MOŻE mieć uprawnienia android.permission.INTERNET. To jest bardziej rygorystyczne niż Zdecydowanie ZALECANE, wymienione w sekcji 9.8.6.
- [C-4-3] NIE MOŻE tworzyć innych aplikacji (z wyjątkiem tych aplikacji systemowych): Bluetooth, kontakty, multimedia, telefonia, SystemUI i komponenty zapewniające Internetowe interfejsy API. Jest to bardziej rygorystyczne niż Zdecydowanie ZALECANE tutaj sekcji 9.8.6.
Zacznij nowe wymagania
Jeśli implementacje urządzeń obejmują domyślną aplikację do obsługi
VoiceInteractionService
to:
- [C-5-1] NIE MOŻE przyznawać opcji
ACCESS_FINE_LOCATION
jako domyślnej w tym przypadku aplikacji.
Zakończ nowe wymagania
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 oraz zainstalowane aplikacje korzystające z alternatywnego środowiska wykonawczego NIE MOGĄ 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.
Zacznij nowe wymagania
Jeśli po wdrożeniu na urządzeniach zostanie utworzony dodatkowy profil użytkownika omówiony powyżej, to:
- [C-4-5] MUSI wizualnie odróżniać ikony aplikacji z dwiema instancjami, gdy ikony są wyświetlane użytkownikom.
- [C-4-6] MUSI zapewnić dostęp użytkownika do wszystkich danych profilu klonu.
- [C-4-7] MUSI odinstalować wszystkie aplikacje, sklonować je i usunąć prywatne dane aplikacji. i ich zawartości, a następnie usunąć sklonować dane profilu, gdy użytkownik postanowi usunąć wszystkie dane z sklonowanego profilu.
- POWINIEN prosić użytkownika o usunięcie wszystkich danych sklonowanego profilu, gdy ostatnie klonowanie aplikacji zostało usunięte.
- [C-4-8] MUSI poinformować użytkownika, że po skopiowaniu dane aplikacji zostaną usunięte aplikacja zostanie odinstalowana lub użytkownicy będą mogli zachować jej dane gdy aplikacja jest odinstalowana z urządzenia.
- [C-4-9] MUSI usunąć prywatne katalogi danych aplikacji i ich zawartość, gdy użytkownik usunie te dane podczas odinstalowywania.
[C-4-1] MUSI zezwalać na poniższe intencje pochodzące z dodatkowych który ma być obsługiwany przez aplikacje głównego użytkownika na urządzeniu:
Intent.ACTION_VIEW
Intent.ACTION_SENDTO
Intent.ACTION_SEND
Intent.ACTION_EDIT
Intent.ACTION_INSERT
Intent.ACTION_INSERT_OR_EDIT
Intent.ACTION_SEND_MULTIPLE
Intent.ACTION_PICK
Intent.ACTION_GET_CONTENT
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] MUSI dziedziczyć wszystkie ograniczenia zasad dotyczących urządzeń i wybrane ograniczenia niezwiązane z użytkownikami(lista poniżej) zastosowane do głównego użytkownika urządzenia do tego dodatkowego profilu użytkownika.
[C-4-3] MUSI zezwalać tylko na zapisywanie kontaktów z tego dodatkowego profilu przez z następującymi intencjami:
[C-4-4] NIE MOŻE uruchamiać synchronizacji kontaktów dla aplikacji działających w ten dodatkowy profil użytkownika.
- [C-4-14] MUSI mieć oddzielne uprawnienia i funkcje zarządzania miejscem na dane w aplikacje działające w tym dodatkowym profilu
- [C-4-5] MUSI zezwalać tylko na aplikacje w dodatkowym profilu, które mają działania programu uruchamiającego w celu uzyskania dostępu do kontaktów, które są już dostępne dla nadrzędnym profilu użytkownika.
Zakończ nowe wymagania
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 udostępniania danych między Androidem a TEE, jak np. platforma Armware Framework Armv8-A (FF-A).
- [C-SR-14] Zdecydowanie ZALECANE jest ograniczenie dostępu zaufanych aplikacji tylko do użytkowników, dostęp do pamięci, która została mu udostępniona za pomocą powyższego protokołu. Jeśli urządzenie obsługuje poziom wyjątku Arm S-EL2, powinno być egzekwowane przez menedżera bezpiecznego partycji. W przeciwnym razie wymuszane przez system TEE OS.
Zacznij nowe wymagania
Technologia bezpieczeństwa pamięci to technologia, która łagodzi co najmniej:
klasy błędów z wysokim prawdopodobieństwem (> 90%) w aplikacjach, które korzystają z funkcji
android:memtagMode
Opcja pliku manifestu:
- przepełnienie bufora sterty
- użyj po bezpłatnym
- podwójne wolne
- wolny (wild wolne) (bez wskaźnika niemalloc)
Implementacje na urządzeniach:
- [C-SR-15] Zdecydowanie ZALECANE jest ustawienie
ro.arm64.memtag.bootctl_supported
Jeśli implementacje urządzeń ustawiają właściwość systemową
ro.arm64.memtag.bootctl_supported
ma wartość prawda, to:
[C-3-1] MUSI zezwalać właściwości systemowej
arm64.memtag.bootctl
na zaakceptowanie rozdzielana przecinkami lista poniższych wartości z pożądanym efektem zostanie zastosowany przy następnym ponownym uruchomieniu:memtag
: włączono technologię bezpieczeństwa pamięci zdefiniowaną powyżejmemtag-once
: technologia zabezpieczeń pamięci (zgodnie z definicją powyżej) to jest tymczasowo włączony i jest automatycznie wyłączany, gdy, następnym razem Uruchom ponowniememtag-off
: technologia Bezpieczeństwo pamięci zgodnie z definicją powyżej jest wyłączona
[C-3-2] MUSI umożliwiać użytkownikowi powłoki ustawienie
arm64.memtag.bootctl
.[C-3-3] MUSI zezwalać dowolny proces na odczyt
arm64.memtag.bootctl
.[C-3-4] MUSI ustawić
arm64.memtag.bootctl
na obecny stan podczas uruchamiania MUSI też aktualizować właściwość, jeśli implementacja urządzenia umożliwia zmianę stanu bez zmiany właściwości systemowej.[C-SR-16] Zdecydowanie ZALECANE jest włączenie ustawienia dla programistów pozwalającego memtag-on. W przypadku zgodnego programu rozruchowego Android Open Source Project spełnia powyższe wymagania dzięki Protokół programu rozruchowego MTE.
- [C-SR-17] Zdecydowanie ZALECANE jest wyświetlenie ustawienia w sekcji Zabezpieczenia
Menu Ustawienia umożliwiające użytkownikowi włączenie
memtag
.
Zakończ nowe wymagania
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. W przypadku rejestrowania dodatkowych zdarzeń systemowych mogą one używać parametru różnych atomów z zakresu od 100 000 do 200 000.
9.8.2. Nagrywam
Implementacje na urządzeniach:
- [C-0-1] NIE WOLNO ładować wstępnie ani rozprowadzać komponentów oprogramowania, które są wysyłać informacje prywatne użytkownika (np. o naciśnięciach klawiszy czy tekście wyświetlanym na ekranu lub zgłaszania błędów) z urządzenia bez zgody użytkownika lub o trwających powiadomieniach.
- [C-0-2] MUSI wyświetlać ostrzeżenie użytkownika i uzyskać wyraźną zgodę użytkownika, zezwalając na przechwytywanie wszelkich informacji poufnych wyświetlanych na ekranie
, w tym: ten sam komunikat co AOSPzawszeza każdym razem, gdy sesja jest rejestrowana ekranprzesyłanie lub nagrywanie ekranujestwłączonarozpoczęte przezMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, lub zastrzeżone interfejsy API.NIE MOŻE udostępniać użytkownikom umożliwia wyłączenie wyświetlania zgody użytkownika w przyszłości. - [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.
Zacznij nowe wymagania
[C-SR-1] Zdecydowanie ZALECANE jest wyświetlanie ostrzeżenia użytkownika, które jest dokładnie takie samo jak w AOSP, ale MOŻNA je zmienić, o ile komunikat wyraźnie ostrzega użytkownika, że na jego ekranie widoczne są wszelkie informacje poufne.
[C-0-4] NIE MOŻE zapewniać użytkownikom możliwości wyłączenia w przyszłości użytkownik wyraża zgodę na zrzut ekranu, chyba że sesja zostanie uruchomiona przez aplikacja systemowa, na którą użytkownik zezwolił
associate()
zandroid.app.role.COMPANION_DEVICE_APP_STREAMING
lubandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
profil urządzenia.Zakończ nowe wymagania
Jeśli implementacje urządzeń obejmują funkcje systemu, które:
rejestruje treści wyświetlane na ekranie i/lub nagrywa strumień audio
odtwarzane na urządzeniu innym niż za pomocą interfejsu System API ContentCaptureService
lub
innych zastrzeżonych środków opisanych w
Artykuł 9.8.6 Dane na poziomie systemu operacyjnego i dane otoczenia:
- [C-1-1] MUSI mieć aktywne powiadomienie o tym, że jest włączona i aktywnie przechwytuje/rejestruje.
Jeśli implementacje urządzeń zawierają włączony od razu komponent, który może nagrywanie dźwięku otoczenia lub nagrywanie dźwięku odtwarzanego na urządzeniu w celu uzyskania przydatnych informacji o kontekście użytkownika:
- [C-2-1] NIE MOŻE przechowywać w pamięci trwałej na urządzeniu ani przesyłać poza Dotyczy to nagranych nieprzetworzonych plików dźwiękowych lub dowolnego formatu, który można przekonwertować z powrotem na oryginalnej ścieżki dźwiękowej lub zbliżonym faksem, chyba że użytkownik wyraził na to wyraźną zgodę.
„Wskaźnik mikrofonu” oznacza 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 aplikacjiDane na poziomie systemu operacyjnego i otoczenia
z Androidem przy użyciu systemowych interfejsów API , obsługuje mechanizm urządzenia
implementacji w celu rejestrowania następujących ContentCaptureService
,
AugmentedAutofillService
, AppSearchGlobalManager.query
lub inny użytkownik
zastrzeżonych środkówinterakcji danych aplikacji między aplikacjami
użytkownik
dane wrażliwe:
- 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).
Zacznij nowe wymagania
- Wszelkie ekrany i inne dane wysyłane przez
AugmentedAutofillService
do systemu. - dowolnego ekranu lub innych danych dostępnych przez
Content Capture
API. - Dowolny ekran lub inne dane dostępne przez interfejs API
FieldClassificationService
- Wszystkie dane aplikacji przekazywane do systemu przez interfejs API
AppSearchManager
i dostępne w usłudzeAppSearchGlobalManager.query
.
Zakończ nowe wymagania
- 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. do usługi systemowej, aby zrozumieć, znaczenia tekstu, a także generować przewidywanie dalszych działań na podstawie tekst. - Dane zindeksowane przez implementację AppSearch na platformie, w tym między innymi ograniczone do tekstu, grafiki, danych multimedialnych lub innych podobnych danych.
Zacznij nowe wymagania
- Dane audio uzyskane w wyniku użycia funkcji
SpeechRecognizer#onDeviceSpeechRecognizer()
dzięki rozpoznawaniu mowy Wdrożenie. - Dane dźwiękowe uzyskane w tle (ciągle) przez aplikację
AudioRecord
,SoundTrigger
lub inny interfejs API audio i nie powoduje, że plik cookie jest widoczny dla użytkownika. wskaźnik - Dane z kamery uzyskane w tle (ciągle) za pomocą usługi CameraManager lub innych interfejsów API aparatu i nie spowoduje wyświetlania wskaźnika widocznego dla użytkownika.
Zakończ nowe wymagania
Jeśli implementacje urządzeń rejestrują któreś z powyższych danych, to:
- [C-1-1] MUSI szyfrować wszystkie takie dane, gdy są przechowywane na urządzeniu. Ten szyfrowanie MOŻE zostać wykonane za pomocą szyfrowania opartego na plikach na Androidzie, mechanizmów szyfrowania wymienionych jako interfejs API w wersji 26 lub nowszej opisanych w artykule Cipher SDK.
- [C-1-2] NIE MOŻE tworzyć kopii zapasowych nieprzetworzonych ani zaszyfrowanych danych za pomocą Tworzenie kopii zapasowej danych z Androida lub inne sposoby za pomocą metody „up” (górnej).
- [C-1-3] MUSI wysyłać tylko takie dane
i dziennikkorzysta z mechanizmu ochrony prywatności, z wyjątkiem za każdym razem, gdy dane są Udostępnione. Mechanizm ochrony prywatności są definiowane jako „te, które umożliwiają tylko zbiorczą analizę i zapobiegają dopasowania zarejestrowanych zdarzeń lub wyników pochodnych do poszczególnych użytkowników”, zapobiegać spojrzeniu na dane poszczególnych użytkowników (np. implementowane za pomocą technologii prywatności różnicowej, takiej jakRAPPOR
). - [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ściNa poziomie systemu operacyjnego i elementów otoczenia ), chyba że za wyraźną zgodą użytkownika przy jego udostępnianiu. O ile taka funkcja nie jest stworzony jako interfejs API Android SDK (AmbientContext
,HotwordDetectionService
). - [C-1-6] MUSI dostarczyć informacje na temat możliwości usunięcia danych, które
. implementacji lub zastrzeżone środkiContentCaptureService
ifkiedy są przechowywane na urządzeniu w dowolnej formie. Jeśli deweloper zdecyduje się usunąć dane, MUSI usunąć wszystkie zebrane danych. - [C-1-7] MUSI zapewniać użytkownikowi zgodę na rezygnację z zbierania danych za pośrednictwem AppSearch lub zastrzeżonych środków na platformie Android. np. Menu z aplikacjami.
- [C-SR-1] Zdecydowanie ZALECANE jest NIE prosić o uprawnienia INTERNET.
- [C-SR-2] Zdecydowanie ZALECANY jest dostęp do internetu tylko za pomocą uporządkowane interfejsy API korzystające z publicznie dostępnych implementacji typu open source.
Zacznij nowe wymagania
- [C-SR-4] Zdecydowanie ZALECANE są wdrożenie za pomocą interfejsu Android SDK API lub podobne repozytorium open source należące do OEM; i / lub być wykonywane Implementacja w trybie piaskownicy (patrz: 9.8.15 Implementacje interfejsu API w trybie piaskownicy).
Zakończ nowe wymagania
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 inna firma jest domyślnym edytorem IME lub jest aktualnie zaznaczony.[C-0-2] MUSI wyczyścić dane ze schowka po upływie maksymalnie 60 minut od ich ostatniego umieszczone w schowku lub odczytywane ze schowka.
9.8.8 Lokalizacja
Lokalizacja obejmuje informacje z klasy lokalizacji systemu Android( takie jak Współrzędne, długość i wysokość), a także identyfikatory, które można przekonwertować na lokalizację. Lokalizacja może być tak dokładna jak DGPS (różnicowy globalny system pozycjonowania) lub przybliżone jako lokalizacje na poziomie kraju (np. lokalizacja według kodu kraju – MCK – Komórki kod kraju).
Poniżej znajduje się lista typów lokalizacji, które bezpośrednio stanowią dla użytkownika do lokalizacji lub mogą zostać przekształcone na lokalizację użytkownika. Nie jest to wyczerpująca lista ale należy go używać jako przykładu do bezpośredniego lub pośrednio pochodzą z:
- GPS/GNSS/DGPS/PPP
- rozwiązanie do globalnego pozycjonowania, globalny system satelitarny lub Rozwiązanie do różnicowego pozycjonowania globalnego
- Obejmuje to również nieprzetworzone pomiary GNSS i stan GNSS
- Dokładną lokalizację można określić na podstawie nieprzetworzonych pomiarów GNSS
- Technologie bezprzewodowe o unikalnych identyfikatorach, takich jak:
- Punkty dostępu Wi-Fi (MAC, BSSID, nazwa lub SSID)
- Bluetooth/BLE (MAC, BSSID, nazwa lub SSID)
- UWB (MAC, BSSID, nazwa lub SSID)
- Identyfikator stacji bazowej 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
SubscriptionManagerService
- 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.
Zacznij nowe wymagania
9.8.14. Menedżer danych logowania
Usunięto.
9.8.15. Implementacje interfejsu API w trybie piaskownicy
Android za pomocą zestawu delegowanych interfejsów API zapewnia mechanizm przetwarzania bezpiecznych Dane na poziomie systemu operacyjnego i dane otoczenia. Takie przetwarzanie można przekazać do wstępnie zainstalowanego plik APK z uprzywilejowanym dostępem i ograniczonymi możliwościami komunikacji, znany jako Implementacja interfejsu API w trybie piaskownicy.
Dowolne wdrożenie interfejsu API w trybie piaskownicy:
- [C-0-1] NIE MOŻE prosić o uprawnienia INTERNET.
- [C-0-2] MUSI mieć dostęp do internetu tylko za pomocą uporządkowanych interfejsów API opartych na publicznie dostępnych implementacji open source z zachowaniem ochrony prywatności, za pomocą interfejsów API pakietu Android SDK. W przypadku tagu chroniącego prywatność są definiowane jako „te, które umożliwiają tylko analizę zagregowaną zapobiegać dopasowywaniu zarejestrowanych zdarzeń lub wyników pochodnych do poszczególnych użytkowników.", aby zapobiec spojrzeniu na dane poszczególnych użytkowników (np. implementowane za pomocą technologię prywatności różnicowej, taką jak RAPPOR).
- [C-0-3] Usługi MUSZĄ oddzielać usługi od innych komponentów systemu
(np. nie wiążą identyfikatorów usługi ani procesów udostępniania) z wyjątkiem
:
- Telefonia, kontakty, interfejs systemu i multimedia
- [C-0-4] NIE MOŻE zezwalać użytkownikom na zastępowanie usług aplikacja lub usługa instalowana przez użytkownika
- [C-0-5] MUSI zezwalać na zbieranie takich danych tylko wstępnie zainstalowanym usługom. Chyba że funkcja wymiany jest wbudowana w AOSP (np. w przypadku aplikacji cyfrowych, Aplikacje Asystenta).
- [C-0-6] NIE MOŻE zezwalać na aplikacje inne niż wstępnie zainstalowane usługi mechanizmu zbierania takich danych. Chyba że taka możliwość zapisu danych jest implementowana za pomocą interfejsu API pakietu Android SDK.
- [C-0-7] MUSI zapewniać koszty użytkownika w celu wyłączenia usług.
- [C-0-8] NIE MOŻE pomijać zgody użytkownika do zarządzania uprawnieniami Androida, które są przechowywane przez usługi i zgodnie z modelem uprawnień Androida, opisane w Artykuł 9.1. Uprawnienia.
9.8.16. Ciągły dźwięk i dane z aparatu
Oprócz wymagań opisanych w sekcjach 9.8.2 Nagrywanie, 9.8.6 na poziomie systemu operacyjnego oraz danych otoczenia oraz 9.8.15 implementacji interfejsu API w trybie piaskownicy, implementacji, które wykorzystywać dane audio uzyskane w tle (ciągły) przez AudioRecord, SoundTrigger lub inne interfejsy API audio LUB Dane kamery uzyskane w w tle (ciągle) za pomocą usługi CameraManager lub innych interfejsów API kamery:
- [C-0-1] MUSI wymuszać stosowanie odpowiedniego wskaźnika (aparat i/lub mikrofon jako
zgodnie z sekcją 9.8.2 Nagrywanie, chyba że:
- Ten dostęp jest wykonywany w ramach implementacji w trybie piaskownicy (zobacz 9.8.15 implementacji interfejsu API w trybie piaskownicy) za pomocą pakietu zawierającego jeden lub inne role: System UI Intelligence, System Ambient Audio Intelligence System Audio Intelligence System Notification Intelligence, System Text Intelligence lub Systemowa inteligencja wizualna.
- Dostęp jest przeprowadzany w piaskownicy, zaimplementowany i
egzekwowane za pomocą mechanizmów AOSP (
HotwordDetectionService
,WearableSensingService
iVisualQueryDetector
). - Dostęp do dźwięku jest przeprowadzany w celach wspomagających przez
Aplikacja Asystent, przesyłając
SOURCE_HOTWORD
jako źródło dźwięku. - Dostęp jest wykonywany przez system i implementowany za pomocą kodu open source.
- [C-SR-1] Zdecydowanie ZALECANE jest wymaganie zgody użytkownika za każdym razem, korzystające z takich danych i domyślnie wyłączone.
- [C-SR-2] Zdecydowanie ZALECANE jest zastosowanie tej samej metody leczenia (tj. ograniczeń opisanych w sekcjach 9.8.2 Nagrywanie, 9.8.6 dane na poziomie systemu operacyjnego i dane otoczenia 9.8.15 Implementacje interfejsów API w trybie piaskownicy oraz 9.8.16 Tryb ciągłego dźwięku i kamery danych) do danych kamery z zdalnego urządzenia do noszenia.
Jeśli dane z kamery pochodzą ze zdalnego urządzenia do noszenia i są dostępne w
niezaszyfrowany formularz poza systemem operacyjnym Android, implementacja w piaskownicy lub piaskownica
funkcje stworzone przez WearableSensingManager
, to:
- [C-1-1] MUSI wskazywać na zdalne urządzenie do noszenia, wyświetli się tam dodatkowy wskaźnik.
Jeśli urządzenia umożliwiają interakcję z aplikacją Asystenta cyfrowego bez przypisanego słowa kluczowego (obsługa ogólnych zapytań użytkownika, obecność użytkownika za pomocą kamery):
- [C-2-1] MUSI zapewnić taką implementację przez pakiet zawierający
Rola użytkownika
android.app.role.ASSISTANT
. - [C-2-2] MUSI mieć pewność, że w takiej implementacji wykorzystywana jest właściwość
HotwordDetectionService
lubVisualQueryDetectionService
interfejsów API Androida.
9.8.17. Telemetry
Android przechowuje dzienniki systemowe i dzienniki aplikacji za pomocą interfejsów StatsLog API. Tymi logami są zarządzane za pośrednictwem interfejsów API StatsManager, których mogą używać aplikacje systemowe z podwyższonymi uprawnieniami.
StatsManager umożliwia też zbieranie danych sklasyfikowanych jako dotyczące prywatności
wrażliwych od urządzeń
z mechanizmem chroniącym prywatność. W szczególności
Interfejs API StatsManager::query
umożliwia wysyłanie zapytań dotyczących danych objętych ograniczeniami
Zdefiniowano kategorie
w Statystykach Google.
Każda implementacja, która wysyła zapytania i zbiera dane objęte ograniczeniami Menedżer statystyk:
- [C-0-1] MUSI być jedyną aplikacją lub implementacją na urządzeniu i blokować
uprawnienia
READ_RESTRICTED_STATS
. - [C-0-2] MOŻE wysyłać dane telemetryczne i dziennik urządzenia tylko za pomocą mechanizm ochrony prywatności. Mechanizm ochrony prywatności został zdefiniowany które umożliwiają tylko zbiorczą analizę i uniemożliwiają dopasowywanie zdarzeń rejestrowanych przez użytkownika ani wyników pochodnych dla poszczególnych użytkowników”, dane poszczególnych użytkowników, które można spostrzegać (np. zaimplementowane za pomocą metody różnicowej technologię ochrony prywatności, taką jak RAPPOR).
- [C-0-3] NIE MOŻE wiązać takich danych z żadną tożsamością użytkownika (np. Konto) na urządzeniu.
- [C-0-4] NIE MOŻE udostępniać takich danych innym komponentom systemu operacyjnego, które nie są zgodne wymagania opisane w obecnej sekcji (9.8.17 Polityka prywatności Dane telemetryczne).
- [C-0-5] MUSI udostępniać dodatkowe korzyści, aby włączyć/wyłączyć ochronę prywatności zbieranie, wykorzystywanie i udostępnianie danych telemetrycznych.
- [C-0-6] MUSI dostarczyć informacje na temat możliwości usunięcia danych, które zostały jeśli dane są przechowywane na urządzeniu w jakiejkolwiek formie. Jeśli użytkownik zdecydował się usunąć dane, MUSISZ usunąć wszystkie dane przechowywane obecnie na urządzenia.
- [C-0-7] MUSI ujawniać podstawowe wdrożenie protokołu chroniącego prywatność w repozytorium open source.
- [C-0-8 ]MUSI egzekwować zasady ruchu wychodzącego danych w tej sekcji, aby zablokować zbieranie danych danych z kategorii wskaźników podlegających ograniczeniom zdefiniowanych w StatsLog.
Zakończ nowe wymagania
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, AES-256-HCTR2, czy Adiantum.
- [C-1-12] Jeśli urządzenie obsługuje standard AES (Advanced Encryption Standard) (np. ARMv8 Cryptography Extensions na urządzeniach z procesorami ARM lub AES-NI 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 p