1. Wprowadzenie
Ten dokument zawiera listę wymagań, które muszą być spełnione, aby urządzenia były zgodne z Androidem 13.
Użycie słów „MUST” (musi), „MUST NOT” (nie musi), „REQUIRED” (wymagane), „SHALL” (musi), „SHALL NOT” (nie musi), „SHOULD” (zalecane), „MAY” (możliwe) i „OPTIONAL” (opcjonalne) jest zgodne ze standardem IETF zdefiniowanym w specyfikacji RFC2119.
W tym dokumencie „wdrożyciel urządzenia” lub „wdrożyciel” to osoba lub organizacja opracowująca rozwiązanie sprzętowe lub programowe na Androida.13 „Wdrożenie na urządzeniu” lub „wdrożenie” to opracowane rozwiązanie sprzętowo-programowe.
Aby uznać implementację urządzenia za zgodną z Androidem 13, należy spełnić wymagania podane w tej Definicji zgodności, w tym wszelkie dokumenty włączone przez odwołanie.
Jeśli definicja lub testy oprogramowania opisane w sekcji 10 są niejasne, niepełne lub nieprecyzyjne, to implementator urządzenia jest odpowiedzialny za zapewnienie zgodności z dotychczasowymi implementacjami.
Z tego powodu projekt Android Open Source jest zarówno referencją, jak i preferowanym sposobem implementacji Androida. IMPLEMENTATOROM URZĄDZEŃ ZALECAMY, aby w jak największym stopniu opierali swoje implementacje na kodzie źródłowym „górnego poziomu” dostępnym w ramach projektu Android Open Source. Chociaż niektóre komponenty można teoretycznie zastąpić innymi implementacjami, ZDECYDOWANIE zaleca się, aby nie stosować tej praktyki, ponieważ przejście testów oprogramowania stanie się znacznie trudniejsze. Obowiązkiem implementatora jest zapewnienie pełnej zgodności z zachowaniem standardowej implementacji Androida, w tym w ramach pakietu Compatibility Test Suite i poza nim. Pamiętaj, że niektóre zamiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.
Wiele zasobów, do których prowadzą linki w tym dokumencie, pochodzi bezpośrednio lub pośrednio z pakietu SDK Androida i pod względem funkcjonalności jest identyczne z informacjami w dokumentacji tego pakietu. W każdym przypadku, gdy ta definicja zgodności lub zestaw testów zgodności są niezgodne z dokumentacją pakietu SDK, za wiarygodną uznaje się dokumentację pakietu SDK. Wszelkie szczegóły techniczne podane w połączonych zasobach w tym dokumencie są uznawane za część tej definicji zgodności.
1.1 Struktura dokumentu
1.1.1. Wymagania według typu urządzenia
Sekcja 2 zawiera wszystkie wymagania dotyczące konkretnego typu urządzenia. Każda sekcja sekcji 2 jest poświęcona konkretnemu typowi urządzenia.
Pozostałe wymagania, które obowiązują w przypadku wszystkich implementacji na urządzeniach z Androidem, są wymienione w sekcjach po sekcji 2. W tym dokumencie te wymagania są określane jako „Wymagania podstawowe”.
1.1.2. Identyfikator wymagań
Identyfikator wymagania jest przypisany do wymagań MUST.
- Identyfikator jest przypisany tylko do wymagań MUST.
- Wymagania ZALECANE są oznaczone jako [SR], ale nie przypisano do nich identyfikatora.
- Identyfikator składa się z identyfikatora typu urządzenia, identyfikatora stanu i identyfikatora wymagań (np. C-0-1).
Każdy identyfikator jest zdefiniowany w ten sposób:
- Identyfikator typu urządzenia (więcej informacji znajdziesz w sekcji 2. Typy urządzeń)
- C: Core (wymagania stosowane do wszystkich implementacji na urządzeniach z Androidem)
- H: urządzenie przenośne z Androidem
- T: urządzenie z Androidem TV
- Odp.: wdrożenie Androida Automotive
- W: Implementacja na zegarku z Androidem
- Karta: implementacja na tabletach z Androidem
- Identyfikator warunku
- Gdy wymaganie jest bezwarunkowe, ten identyfikator ma wartość 0.
- Jeśli wymagania są warunkowe, dla pierwszego warunku przypisuje się wartość 1, a w ramach tej samej sekcji i tego samego typu urządzenia liczba ta zwiększa się o 1.
- Identyfikator wymagań
- Ten identyfikator zaczyna się od 1 i zwiększa się o 1 w tej samej sekcji i przy tej samej regule.
1.1.3. Identyfikator wymagań w sekcji 2
Identyfikatory wymagań w sekcji 2 składają się z 2 części. Pierwszy z nich odpowiada identyfikatorowi sekcji, jak opisano powyżej. Druga część identyfikuje format i odpowiadające mu wymagania.
identyfikator sekcji poprzedzony identyfikatorem wymagań opisanym powyżej.
- Identyfikator w sekcji 2 składa się z tych elementów: Identyfikator sekcji / Identyfikator typu urządzenia – Identyfikator warunku – Identyfikator wymagań (np. 7.4.3/A-0-1).
2. Typy urządzeń
Projekt Android Open Source udostępnia zestaw oprogramowania, który można stosować na różnych typach i w różnych formatach urządzeń. Aby zapewnić bezpieczeństwo urządzeń, oczekuje się, że pakiet oprogramowania, w tym system operacyjny zastępczy lub alternatywne jądro, będzie działać w bezpiecznym środowisku zgodnie z opisem w sekcji 9 i w innych miejscach w tym dokumencie. Istnieje kilka typów urządzeń, które mają stosunkowo lepiej rozwiniętą platformę dystrybucji aplikacji.
W tej sekcji opisujemy te typy urządzeń oraz dodatkowe wymagania i zalecenia dotyczące każdego z nich.
Wszystkie implementacje urządzeń z Androidem, które nie pasują do żadnego z opisanych typów urządzeń, MUSZĄ spełniać wszystkie wymagania podane w innych sekcjach tej Definicji zgodności.
2.1 Konfiguracje urządzenia
Najważniejsze różnice w konfiguracji sprzętowej w zależności od typu urządzenia znajdziesz w wymaganiach dotyczących poszczególnych urządzeń w tej sekcji.
2.2. Wymagania dotyczące urządzeń przenośnych
Urządzenie przenośne z Androidem to urządzenie z Androidem, które jest zwykle używane w ręce, np. odtwarzacz MP3, telefon lub tablet.
Implementacje urządzeń z Androidem są klasyfikowane jako urządzenia przenośne, jeśli spełniają wszystkie te kryteria:
- mieć źródło zasilania, które zapewnia mobilność, np. baterię;
- mieć fizyczny rozmiar ekranu w zakresie od 3,3 cala (lub 2,5 cala w przypadku implementacji urządzeń z poziomem interfejsu API 29 lub wcześniejszym) do 8 cali;
Dodatkowe wymagania w pozostałych częściach tej sekcji dotyczą implementacji na urządzeniach przenośnych z Androidem.
2.2.1. Sprzęt
Implementacje na urządzeniach przenośnych:
- [7.1.1.1/H-0-1] MUSI zawierać co najmniej 1 ekran zgodny z Androidem, który spełnia wszystkie wymagania opisane w tym dokumencie.
[7.1.1.3/H-SR-1] ZALECAMY, aby umożliwić użytkownikom zmianę rozmiaru wyświetlacza (gęstości ekranu).
[7.1.1.1/H-0-2] MUSI obsługiwać tworzenie kompozycji za pomocą GPU w buforach graficznych o rozmiarach co najmniej tak dużych jak najwyższa rozdzielczość dowolnego wbudowanego wyświetlacza.
Jeśli implementacje urządzeń przenośnych obsługują obrócenie ekranu za pomocą oprogramowania, mogą:
- [7.1.1.1/H-1-1]* Ekran logiczny udostępniany aplikacjom zewnętrznym MUSI mieć co najmniej 2 cale(5,08 cm) na krawędziach krótkich i 2,7 cala(6,35 cm) na krawędziach długich. Urządzenia z Androidem na poziomie interfejsu API 29 lub niższym MOGĄ być zwolnione z tego wymogu.
Jeśli implementacje urządzeń przenośnych nie obsługują obrócenia ekranu za pomocą oprogramowania, to:
- [7.1.1.1/H-2-1]* Ekran logiczny udostępniany aplikacjom innych firm MUSI mieć co najmniej 2,7 cala na krótszych krawędziach. Urządzenia z Androidem na poziomie interfejsu API 29 lub niższym MOGĄ być zwolnione z tego wymogu.
Jeśli implementacje urządzeń przenośnych obsługują wyświetlacze HDR za pomocą Configuration.isScreenHdr()
:
- [7.1.4.5/H-1-1] MUSI reklamować obsługę rozszerzeń
EGL_EXT_gl_colorspace_bt2020_pq
,EGL_EXT_surface_SMPTE2086_metadata
,EGL_EXT_surface_CTA861_3_metadata
,VK_EXT_swapchain_colorspace
iVK_EXT_hdr_metadata
.
Implementacje na urządzeniach przenośnych:
- [7.1.4.6/H-0-1] MUST report whether the device
supports the GPU profiling capability via a system property
graphics.gpu.profiler.support
.
Jeśli implementacje urządzeń przenośnych deklarują obsługę za pomocą właściwości systemowej
graphics.gpu.profiler.support
, to:
- [7.1.4.6/H-1-1] Musisz podać jako dane wyjściowe ślad protobuf zgodny ze schematem dotyczącym liczników GPU i etapów renderowania GPU zdefiniowanymi w dokumentacji Perffetto.
- [7.1.4.6/H-1-2] MUSI raportować wartości zgodne z wartościami zliczników GPU urządzenia zgodnie z protokołem gpu counter trace packet.
- [7.1.4.6/H-1-3] MUSI raportować wartości zgodne z GPU RenderStages zgodnie z protokołem render stage trace packet.
- [7.1.4.6/H-1-4] MUSI raportować punkt danych o częstotliwości GPU zgodnie z formatem: power/gpu_frequency.
Implementacje na urządzeniach przenośnych:
- [7.1.5/H-0-1] MUSI zawierać obsługę starszego trybu zgodności aplikacji, który jest implementowany przez kod źródłowy na platformie Android na licencji open source. Oznacza to, że implementacje na urządzeniach NIE MOGĄ zmieniać wyzwalaczy ani progów, przy których aktywowany jest tryb zgodności, ani zmieniać zachowania samego trybu zgodności.
- [7.2.1/H-0-1] MUSI zawierać obsługę aplikacji edytora metody wprowadzania (IME) innych firm.
- [7.2.3/H-0-2] DO aplikacji na pierwszym planie należy wysłać zdarzenie naciśnięcia i długiego naciśnięcia funkcji Wstecz (
KEYCODE_BACK
). System NIE MOŻE używać tych zdarzeń i MOŻE je wywoływać z zewnątrz urządzenia z Androidem (np. zewnętrzna klawiatura sprzętowa podłączona do urządzenia z Androidem). - [7.2.3/H-0-3] MUSI zapewniać funkcję „Strona główna” na wszystkich wyświetlaczach zgodnych z Androidem, które wyświetlają ekran główny.
- [7.2.3/H-0-4] Musisz udostępnić funkcję Wstecz na wszystkich wyświetlaczach zgodnych z Androidem oraz funkcję Ostatnie na co najmniej jednym wyświetlaczu zgodnym z Androidem.
- [7.2.4/H-0-1] MUSI obsługiwać wprowadzanie danych za pomocą ekranu dotykowego.
- [7.2.4/H-SR-1] MOCNO zalecane jest uruchamianie wybranej przez użytkownika aplikacji asystenta, czyli aplikacji, która implementuje VoiceInteractionService, lub aktywności obsługującej
ACTION_ASSIST
po długim naciśnięciuKEYCODE_MEDIA_PLAY_PAUSE
lubKEYCODE_HEADSETHOOK
, jeśli aktywność na pierwszym planie nie obsługuje tych zdarzeń długiego naciśnięcia. - [7.3.1/H-SR-1] MOCNO ZALECAMY uwzględnienie 3-osiowego akcelerometru.
Jeśli implementacja urządzenia przenośnego zawiera 3-osiowy akcelerometr, urządzenie:
- [7.3.1/H-1-1] MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
Jeśli implementacje urządzeń przenośnych zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps
, to:
- [7.3.3/H-2-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
- [7.3.3/H-2-2] MUST report GNSS pseudoranges and pseudorange rates, that, in conditions of open sky after determining the location, while stationary or moving with less than 0.2 meter per second squared of acceleration, are sufficient to calculate position within 20 meters, and speed within 0.2 meters per second, at least 95% of the time.
Jeśli implementacje urządzeń przenośnych zawierają 3-osiowy żyroskop, muszą:
- [7.3.4/H-3-1] MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
- [7.3.4/H-3-2] MUSI umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę.
Implementacje urządzeń przenośnych, które mogą nawiązywać połączenia głosowe i wskazują dowolną wartość inną niż PHONE_TYPE_NONE
w polecenie getPhoneType
:
- [7.3.8/H] NALEŻY uwzględnić czujnik zbliżeniowy.
Implementacje na urządzeniach przenośnych:
- [7.3.11/H-SR-1] ZALECAMY wspieranie czujnika postawy z 6 stopniami swobody.
- [7.4.3/H] NALEŻY uwzględnić obsługę Bluetooth i Bluetooth LE.
Jeśli urządzenia obsługują protokół NAN (WiFi Neighbor Awareness Networking) przez deklarowanie PackageManager.FEATURE_WIFI_AWARE
oraz lokalizację Wi-Fi (czas RTT Wi-Fi) przez deklarowanie PackageManager.FEATURE_WIFI_RTT
, to:
[7.4.2.5/H-1-1] MUSI dokładnie raportować zasięg w zakresie +/-1 m przy przepustowości 160 MHz w 68. percentilu (obliczonej za pomocą funkcji rozkładu kumulacyjnego), +/-2 m przy przepustowości 80 MHz w 68. percentilu, +/-4 m przy przepustowości 40 MHz w 68. percentilu oraz +/-8 m przy przepustowości 20 MHz w 68. percentilu w odległościach 10 cm, 1 m, 3 m i 5 m, jak to widać w interfejsie API Androida WifiRttManager#startRanging.
[7.4.2.5/H-SR-1] MOCNO POLECAMY podawanie dokładnego zasięgu z dokładnością do +/-1 metra przy przepustowości 160 MHz na 90. percentile (obliczonej za pomocą funkcji rozkładu kumulacyjnego), +/-2 metrów przy przepustowości 80 MHz na 90. percentile, +/-4 metrów przy przepustowości 40 MHz na 90. percentile oraz +/-8 metrów przy przepustowości 20 MHz na 90. percentile w odległości 10 cm, jak to zostało zaobserwowane za pomocą interfejsu API Androida WifiRttManager#startRanging.
MOCNO zalecamy wykonanie czynności konfiguracji pomiarów opisanych w sekcji Kalibracja obecności.
Jeśli implementacje urządzeń przenośnych obejmują logiczne urządzenie z kamerą, które wymienia funkcje za pomocą CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, to:
- [7.5.4/H-1-1] Domyślnie musi mieć normalne pole widzenia (FOV) i musi wynosić od 50 do 95 stopni.
Implementacje na urządzeniach przenośnych:
- [7.6.1/H-0-1] Musisz mieć co najmniej 4 GB pamięci nieulotnej dostępnej dla danych prywatnych aplikacji (czyli partycji „/data”).
- [7.6.1/H-0-2] MUSI zwracać „true” dla
ActivityManager.isLowRamDevice()
, gdy do użycia przez jądro i przestrzeń użytkownika jest mniej niż 1 GB pamięci.
Jeśli implementacje na urządzeniach przenośnych deklarują obsługę tylko 32-bitowego ABI:
[7.6.1/H-1-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 416 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora ramki do qHD (np. FWVGA).
[7.6.1/H-2-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 592 MB, jeśli domyślny wyświetlacz używa pamięci podręcznej w rozdzielczości do HD+ (np. HD, WSVGA).
[7.6.1/H-3-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 896 MB, jeśli domyślny wyświetlacz używa rozdzielczości framebuffera do FHD (np. WSXGA+).
[7.6.1/H-4-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1344 MB, jeśli domyślny wyświetlacz używa rozdzielczości framebuffera do QHD (np. QWXGA).
Jeśli implementacje urządzeń przenośnych deklarują obsługę dowolnego 64-bitowego ABI (z dowolnym 32-bitowym ABI lub bez niego):
[7.6.1/H-5-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 816 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora ramki do qHD (np. FWVGA).
[7.6.1/H-6-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 944 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora ramki do HD+ (np. HD, WSVGA).
[7.6.1/H-7-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1280 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora ramki do FHD (np. WSXGA+).
[7.6.1/H-8-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1824 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora ramki do QHD (np. QWXGA).
Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do przestrzeni pamięci udostępnionej dodatkowo do pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro w implementacjach urządzenia.
Jeśli implementacje urządzeń przenośnych mają mniej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, to:
- [7.6.1/H-9-1] NALEŻY zadeklarować flagę funkcji
android.hardware.ram.low
. - [7.6.1/H-9-2] Musisz mieć co najmniej 1,1 GB pamięci nieulotnej na dane prywatne aplikacji (na przykład na partycji „/data”).
Jeśli implementacje urządzeń przenośnych mają więcej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, muszą:
- [7.6.1/H-10-1] Musi być dostępne co najmniej 4 GB pamięci nieulotnej na potrzeby danych prywatnych aplikacji (czyli na partycji „/data”).
- NALEŻY zadeklarować flagę funkcji
android.hardware.ram.normal
.
Jeśli implementacje urządzeń przenośnych mają co najmniej 2 GB i nie więcej niż 4 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, to:
- [7.6.1/H-SR-1] ZALECAMY obsługę tylko 32-bitowej przestrzeni użytkownika (zarówno aplikacji, jak i kodu systemowego)
Jeśli implementacje urządzeń przenośnych mają mniej niż 2 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, to:
- [7.6.1/H-1-1] MUSI obsługiwać tylko jeden interfejs ABI (tylko 64-bitowy lub tylko 32-bitowy).
Implementacje na urządzeniach przenośnych:
- [7.6.2/H-0-1] NIE MOŻESZ udostępnić aplikacji pamięci współdzielonej o pojemności mniejszej niż 1 GiB.
- [7.7.1/H] NALEŻY uwzględnić port USB obsługujący tryb peryferyjny.
Jeśli implementacje urządzeń przenośnych zawierają port USB obsługujący tryb peryferyjny, muszą:
- [7.7.1/H-1-1] MUSI implementować interfejs API akcesoriów otwartych Androida (AOA).
Jeśli implementacje urządzeń przenośnych zawierają port USB obsługujący tryb hosta, muszą:
- [7.7.2/H-1-1] NALEŻY zaimplementować klasę audio USB zgodnie z dokumentacją pakietu Android SDK.
Implementacje na urządzeniach przenośnych:
- [7.8.1/H-0-1] MUSI zawierać mikrofon.
- [7.8.2/H-0-1] MUSI mieć wyjście audio i być zadeklarowane jako
android.hardware.audio.output
.
Jeśli implementacje urządzeń przenośnych spełniają wszystkie wymagania dotyczące wydajności w trybie VR i obsługują ten tryb, muszą:
- [7.9.1/H-1-1] NALEŻY zadeklarować flagę funkcji
android.hardware.vr.high_performance
. - [7.9.1/H-1-2] Musisz umieścić w aplikacji funkcję
android.service.vr.VrListenerService
, którą można włączyć za pomocą aplikacji VR za pomocąandroid.app.Activity#setVrModeEnabled
.
Jeśli implementacja urządzenia przenośnego zawiera co najmniej 1 port USB-C w trybie hosta i implementuje klasę audio USB, oprócz wymagań podanych w sekcji 7.7.2:
- [7.8.2.2/H-1-1] MUST provide the following software mapping of HID codes:
Funkcja | Mapowania | Kontekst | Działanie |
---|---|---|---|
A | Strona dotyczącej użycia 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 Wyjście: odtwarzanie lub wstrzymywanie |
Wejście: długie naciśnięcie Wyjście: polecenie głosowe Wyślij: android.speech.action.VOICE_SEARCH_HANDS_FREE jeśli urządzenie jest zablokowane lub ma wyłączony ekran. W innym przypadkuandroid.speech.RecognizerIntent.ACTION_WEB_SEARCH |
|||
Połączenie przychodzące | Wejście: krótkie naciśnięcie Wyjście: zaakceptuj połączenie |
||
Dane wejściowe: naciśnij i przytrzymaj Dane wyjściowe: odrzuć połączenie |
|||
Trwa rozmowa | Dane wejściowe: krótkie naciśnięcie Dane wyjściowe: zakończenie połączenia |
||
Wejście: naciśnij i przytrzymaj Wyjście: wycisz lub wyłącz wyciszenie mikrofonu |
|||
B | Strona użycia HID: 0x0C Użycie HID: 0x0E9 Klucz jądra: KEY_VOLUMEUP Klucz Androida: VOLUME_UP |
Odtwarzanie multimediów, Trwające połączenie | Wejście: krótkie lub długie naciśnięcie Wyjście: zwiększa głośność systemu lub zestawu słuchawkowego |
C | Strona użycia HID: 0x0C Użycie HID: 0x0EA Klucz jądra: KEY_VOLUMEDOWN Klucz Androida: VOLUME_DOWN |
Odtwarzanie multimediów, Trwające połączenie | Wejście: krótkie lub długie naciśnięcie Wyjście: zmniejsza głośność systemu lub zestawu słuchawkowego |
D | Strona dotyczące użycia HID: 0x0C Użycie HID: 0x0CF Klucz jądra: KEY_VOICECOMMAND Klucz Androida: KEYCODE_VOICE_ASSIST |
Wszystkie. Może być wywoływany w dowolnej instancji. | Wejście: krótkie lub długie naciśnięcie Wyjście: polecenie głosowe |
- [7.8.2.2/H-1-2] MUSI wywołać ACTION_HEADSET_PLUG po włożeniu wtyczki, ale dopiero po prawidłowym zliczeniu interfejsów audio USB i punktów końcowych w celu zidentyfikowania typu podłączonego terminala.
Po wykryciu terminala audio USB typu 0x0302:
- [7.8.2.2/H-2-1] MUST broadcast Intent ACTION_HEADSET_PLUG with "microphone" extra set to 0.
Gdy wykryto typy terminali audio USB 0x0402,:
- [7.8.2.2/H-3-1] MUST broadcast Intent ACTION_HEADSET_PLUG with "microphone" extra set to 1.
Gdy wywołysz interfejs API AudioManager.getDevices() podczas połączenia urządzenia peryferyjnego USB:
[7.8.2.2/H-4-1] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i role isSink(), jeśli pole typu terminala audio USB ma wartość 0x0302.
[7.8.2.2/H-4-2] MUST list a device of type AudioDeviceInfo.TYPE_USB_HEADSET and role isSink() if the USB audio terminal type field is 0x0402.
[7.8.2.2/H-4-3] MUST list a device of type AudioDeviceInfo.TYPE_USB_HEADSET and role isSource() if the USB audio terminal type field is 0x0402.
[7.8.2.2/H-4-4] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSink(), jeśli pole typu terminala audio USB ma wartość 0x603.
[7.8.2.2/H-4-5] MUST list a device of type AudioDeviceInfo.TYPE_USB_DEVICE and role isSource() if the USB audio terminal type field is 0x604.
[7.8.2.2/H-4-6] MUST list a device of type AudioDeviceInfo.TYPE_USB_DEVICE and role isSink() if the USB audio terminal type field is 0x400.
[7.8.2.2/H-4-7] MUST list a device of type AudioDeviceInfo.TYPE_USB_DEVICE and role isSource() if the USB audio terminal type field is 0x400.
[7.8.2.2/H-SR-1] W przypadku podłączenia urządzenia peryferyjnego USB-C MOCNO zaleca się wykonanie enumeracji opisów USB, identyfikację typów terminali i wysłanie komunikatu o intencji ACTION_HEADSET_PLUG w mniej niż 1000 ms.
Jeśli implementacje na urządzeniach przenośnych deklarują android.hardware.audio.output
i android.hardware.microphone
, to:
[5.6/H-1-1] Średnia ciągła opóźnienie w obie strony nie może przekraczać 500 ms w przypadku 5 pomiary, a średnia odchylenie bezwzględne nie może przekraczać 50 ms na następujących ścieżkach danych: „głośnik do mikrofonu”, przejściówka z 3,5 mm (jeśli jest obsługiwana), pętla USB (jeśli jest obsługiwana).
[5.6/H-1-2] Średnie opóźnienie od dotknięcia do tonu MUSI wynosić 500 ms lub mniej w przynajmniej 5 przypadkach pomiarów na ścieżce danych od głośnika do mikrofonu.
Jeśli implementacje urządzeń przenośnych zawierają co najmniej 1 aktywator haptyczny, muszą:
- [7.10/H]* NIE NALEŻY używać mimośrodowo obracającej się masy (ERM) aktywatora haptycznego (wibratora).
- [7.10/H]* NALEŻY umieścić siłownik w pobliżu miejsca, w którym urządzenie jest zwykle trzymane lub dotykane rękami.
- [7.10/H]* NALEŻY zaimplementować wszystkie publiczne stałe dotyczące czystych wibracji w android.view.HapticFeedbackConstants, a mianowicie: CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START i GESTURE_END.
- [7.10/H]* NALEŻY zaimplementować wszystkie publiczne stałe czystych wibracji
w android.os.VibrationEffect, a mianowicie: EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK i EFFECT_DOUBLE_CLICK, oraz wszystkie możliwe publiczne
PRIMITIVE_*
stałe bogatych wibracji w android.os.VibrationEffect.Composition, a mianowicie: CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD. Niektóre z tych prymitywów, takie jak LOW_TICK i SPIN, mogą być możliwe tylko wtedy, gdy wibrator może obsługiwać stosunkowo niskie częstotliwości. [7.10/H]* NALEŻY przestrzegać wskazówek dotyczących mapowania stałych publicznych w android.view.HapticFeedbackConstants na zalecane stałe android.os.VibrationEffect z odpowiednimi stosunkami amplitudy.
[7.10/H]* NALEŻY stosować ocena jakości interfejsów API createOneShot() i createWaveform().
[7.10/H]* NALEŻY sprawdzić, czy wynik interfejsu API android.os.Vibrator.hasAmplitudeControl() poprawnie odzwierciedla możliwości wibratora.
Silnik rezonansowy liniowy (LRA) to system sprężynowy o jednej masie, który ma dominującą częstotliwość rezonansową, w której masa przemieszcza się w kierunku pożądanego ruchu.
Jeśli implementacje urządzeń przenośnych zawierają co najmniej 1 aktywator liniowy rezonansowy, muszą:
- [7.10/H]* NALEŻY przesunąć siłownik haptyczny w kierunku osi X (z lewej na prawo) w orientacji pionowej.
Jeśli implementacje urządzeń przenośnych mają siłownik haptyczny, który jest liniowym rezonansowym siłownikiem (LRA) na osi X, to:
- [7.10/H]* Częstotliwość rezonansowa LRA osi X powinna wynosić poniżej 200 Hz.
Jeśli implementacje na urządzeniach przenośnych są zgodne z mapowaniem stałych wartości haptycznych, mają te cechy:
- [7.10/H]* NALEŻY sprawdzić stan implementacji, wykonując wywołania android.os.Vibrator.areAllEffectsSupported() i android.os.Vibrator.arePrimitivesSupported() interfejsu API.
[7.10/H]* NALEŻY przeprowadzić ocenę jakości stałych haptycznych.
[7.10/H]* NALEŻY sprawdzić i w razie potrzeby zaktualizować konfigurację awaryjnego dla nieobsługiwanych prymitywów zgodnie z wskazówkami dotyczącymi implementacji w przypadku stałych.
2.2.2. Multimedia
Implementacje urządzeń przenośnych MUSZĄ obsługiwać te formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] Profil MPEG-4 AAC (AAC LC)
- [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
- [5.1/H-0-5] AAC ELD (ulepszona jakość dźwięku AAC z małym opóźnieniem)
Implementacje na urządzeniach przenośnych MUSZĄ obsługiwać te formaty kodowania filmów i udostępniać je aplikacjom innych firm:
Implementacje na urządzeniach przenośnych MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:
2.2.3. Oprogramowanie
Implementacje na urządzeniach przenośnych:
- [3.2.3.1/H-0-1] Aplikacja MUSI obsługiwać intencje
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
iACTION_CREATE_DOCUMENT
zgodnie z opisem w dokumentach pakietu SDK oraz udostępniać użytkownikowi możliwość uzyskania dostępu do danych dostawcy dokumentów za pomocą interfejsu APIDocumentsProvider
. - [3.2.3.1/H-0-2]* Musisz wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji dla wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez te aplikacje z intencją wymienione tutaj.
- [3.2.3.1/H-SR-1] MOCNO POLECAMY wstępne załadowanie aplikacji poczty e-mail, która może obsługiwać intencje ACTION_SENDTO lub ACTION_SEND lub ACTION_SEND_MULTIPLE w celu wysłania e-maila.
- [3.4.1/H-0-1] Musisz zapewnić pełną implementację interfejsu
android.webkit.Webview
API. - [3.4.2/H-0-1] Musisz udostępnić samodzielną aplikację przeglądarki do ogólnego przeglądania Internetu przez użytkowników.
- [3.8.1/H-SR-1] MOCNO POLECAMY wdrożenie domyślnej aplikacji, która obsługuje przypinanie skrótów, widżetów i widgetFeatures w aplikacji.
- [3.8.1/H-SR-2] MOCNO POLECAMY wdrożenie domyślnej aplikacji uruchamiającej, która zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu ShortcutManager API.
- [3.8.1/H-SR-3] MOCNO POLECAMY uwzględnienie domyślnej aplikacji uruchamiającej, która wyświetla plakietki dla ikon aplikacji.
- [3.8.2/H-SR-1] SĄ BARDZO ZALECANE do obsługi widżetów aplikacji innych firm.
- [3.8.3/H-0-1] Musisz zezwolić aplikacjom innych firm na powiadamianie użytkowników o istotnych zdarzeniach za pomocą klas interfejsu API
Notification
iNotificationManager
. - [3.8.3/H-0-2] MUSI obsługiwać powiadomienia multimedialne.
- [3.8.3/H-0-3] MUSI obsługiwać powiadomienia typu heads-up.
- [3.8.3/H-0-4] MUSI zawierać panel powiadomień, który umożliwia użytkownikowi bezpośrednie zarządzanie powiadomieniami (np. odpowiadanie na nie, odkładanie na później, odrzucanie i blokowanie) za pomocą przycisków lub panelu sterowania zaimplementowanego w AOSP.
- [3.8.3/H-0-5] MUST display the choices
provided through
RemoteInput.Builder setChoices()
in the notification shade. - [3.8.3/H-SR-1] ZALECAMY wyświetlanie pierwszej opcji w
RemoteInput.Builder setChoices()
w pasku powiadomień bez dodatkowej interakcji użytkownika. - [3.8.3/H-SR-2] ZALECAMY wyświetlanie wszystkich opcji udostępnianych w
RemoteInput.Builder setChoices()
w obszarze powiadomień, gdy użytkownik rozwinie wszystkie powiadomienia w obszarze powiadomień. - [3.8.3.1/H-SR-1] ZALECAMY wyświetlanie działań, dla których parametr
Notification.Action.Builder.setContextual
jest ustawiony jakotrue
zgodnie z odpowiedziami wyświetlanymi przezNotification.Remoteinput.Builder.setChoices
. - [3.8.4/H-SR-1] MOCNO zaleca się wdrożenie na urządzeniu asystenta, który obsłuży działanie asystenta.
Jeśli implementacje na urządzeniach przenośnych obsługują powiadomienia w stylu multimediów, to:
- [3.8.3.1/H-SR-2] ZALECAMY
dodanie opcji (np. przełącznika wyjścia) dostępnej z poziomu interfejsu systemu, która umożliwia użytkownikom przełączanie się między odpowiednimi dostępnymi ścieżkami multimediów (np. urządzeniami Bluetooth i ścieżkami udostępnionymi
MediaRouter2Manager
), gdy aplikacja publikuje powiadomienieMediaStyle
z tokenemMediaSession
.
Jeśli implementacje na urządzeniach przenośnych obsługują działanie Asystenta, mogą:
- [3.8.4/H-SR-2] MOCNO zalecamy używanie długiego naciśnięcia przycisku
HOME
jako wyznaczonej interakcji w celu uruchomienia aplikacji Asystent, zgodnie z opisem w sekcji 7.2.3. MUSI uruchamiać wybraną przez użytkownika aplikację wspomagającą, czyli aplikację, która implementujeVoiceInteractionService
, lub aktywność obsługującą intencjęACTION_ASSIST
.
Jeśli implementacje na urządzeniach przenośnych obsługują conversation notifications
i umieszczają je w oddzielnej sekcji od powiadomień alarmowych i cichych powiadomień niebędących rozmowami, to:
- [3.8.4/H-1-1]* MUSI wyświetlać powiadomienia o rozmowie przed powiadomieniami o innych zdarzeniach, z wyjątkiem powiadomień o działaniach usług na pierwszym planie i powiadomień o istotności:wysoka.
Jeśli implementacje urządzeń z Androidem obsługują ekran blokady, muszą:
- [3.8.10/H-1-1] MUSI wyświetlać powiadomienia na ekranie blokady, w tym szablon powiadomienia z multimediów.
Jeśli implementacje urządzeń przenośnych obsługują bezpieczny ekran blokady, to:
- [3.9/H-1-1] NALEŻY wdrożyć pełny zakres zasad zarządzania urządzeniem zdefiniowanych w dokumentacji pakietu Android SDK.
Jeśli implementacje urządzeń przenośnych obsługują interfejsy API ControlsProviderService
i Control
oraz umożliwiają aplikacjom innych firm publikowanie elementów sterujących urządzeniami, to:
- [3.8.16/H-1-1] NALEŻY zadeklarować flagę funkcji
android.software.controls
i ustawić ją na wartośćtrue
. - [3.8.16/H-1-2] Musisz zapewnić użytkownikowi możliwość dodawania, edytowania, wybierania i sterowania ulubionymi elementami sterowania urządzeniami z użyciem interfejsów
ControlsProviderService
i interfejsów APIControl
zarejestrowanych przez aplikacje innych firm. - [3.8.16/H-1-3] MUSI zapewnić użytkownikowi dostęp do tej opcji w ciągu 3 interakcji z domyślnym menu z aplikacjami.
[3.8.16/H-1-4] W tym interfejsie użytkownika MUSISZ poprawnie wyświetlać nazwę i ikonę każdej aplikacji innej firmy, która udostępnia opcje sterujące za pomocą interfejsu
ControlsProviderService
API, a także wszystkie określone pola udostępniane przez interfejsyControl
API.[3.8.16/H-1-5] Musisz umożliwić użytkownikowi rezygnację z kontroli urządzeń z użyciem autoryzacji przypisanej aplikacji z kontroli zarejestrowanych przez aplikacje innych firm za pomocą interfejsu
ControlsProviderService
i interfejsuControl
Control.isAuthRequired
API.
Jeśli implementacja na urządzeniach przenośnych nie zawiera takich elementów sterujących, to:
- [3.8.16/H-2-1] MUST report
null
for theControlsProviderService
and theControl
APIs. - [3.8.16/H-2-2] NALEŻY zadeklarować flagę funkcji
android.software.controls
i ustawić ją nafalse
.
Jeśli implementacje na urządzeniach przenośnych nie działają w trybie blokady, gdy treści są kopiowane do schowka, to:
- [3.8.17/H-1-1] MUST present a confirmation to the user that data has been copied to the clipboard (e.g., a thumbnail or alert of “Content copied.”). Additionally, include here an indication if clipboard data will be synced across devices.
Implementacje na urządzeniach przenośnych:
- [3.10/H-0-1] MUSI obsługiwać usługi dostępności innych firm.
- [3.10/H-SR-1] ZALECAMY WYMAGANIE wstępnie załadowanych usług ułatwień dostępu na urządzeniu, które są porównywalne z funkcjonalnością Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) lub ją przewyższają, zgodnie z projektem open source TalkBack.
- [3.11/H-0-1] MUSI obsługiwać instalację zewnętrznych silników TTS.
- [3.11/H-SR-1] MOCNO ZALECAMY uwzględnienie mechanizmu TTS obsługującego języki dostępne na urządzeniu.
- [3.13/H-SR-1] ZALECAMY, aby dodać komponent UI Szybkich ustawień.
Jeśli implementacje urządzeń przenośnych z Androidem deklarują obsługę FEATURE_BLUETOOTH
lub
FEATURE_WIFI
, muszą:
- [3.16/H-1-1] MUSI obsługiwać funkcję parowania urządzenia towarzyszącego.
Jeśli funkcja nawigacji jest obsługiwana jako działanie na ekranie oparte na gestach:
- [7.2.3/H] Strefa rozpoznawania gestów w funkcji Home powinna mieć wysokość nie większą niż 32 dp od dołu ekranu.
Jeśli implementacje urządzeń przenośnych zapewniają funkcję nawigacji jako gest wykonywany w dowolnym miejscu po lewej i prawej stronie ekranu:
- [7.2.3/H-0-1] Szerokość obszaru gestów funkcji nawigacji MUSI być mniejsza niż 40 dp po każdej stronie. Domyślna szerokość obszaru gestów powinna wynosić 24 dp.
Jeśli implementacje urządzeń przenośnych obsługują bezpieczny ekran blokady i mają co najmniej 2 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, to:
- [3.9/H-1-2] MUST declare the support of managed profiles via the
android.software.managed_users
feature flag.
Jeśli implementacje urządzeń przenośnych z Androidem deklarują obsługę kamery za pomocą
android.hardware.camera.any
, muszą:
- [7.5.4/H-1-1] MUSI obsługiwać działanie
android.media.action.STILL_IMAGE_CAMERA
iandroid.media.action.STILL_IMAGE_CAMERA_SECURE
, a także uruchamiać aparat w trybie zdjęć zgodnie z opisem w pakiecie SDK. - [7.5.4/H-1-2] MUSI obsługiwać
android.media.action.VIDEO_CAMERA
intencję uruchomienia aparatu w trybie wideo zgodnie z opisem w pakiecie SDK.
Jeśli aplikacja ustawień na urządzeniu przenośnym implementuje funkcje podzielone, korzystając z osadzania aktywności, to:
- [3.2.3.1/ H-1-1]
Musi zawierać aktywność, która obsługuje działanie Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY, gdy włączona jest funkcja podziału. Aktywność MUSI być chroniona przez
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
i MUSI uruchamiać aktywność zamierzoną w ramach zamiaru z Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
2.2.4. Wydajność i moc
- [8.1/H-0-1] Stała wartość opóźnienia ramki. Niespójny czas oczekiwania na renderowanie lub opóźnienie w renderowaniu klatek NIE POWINNY występować częściej niż 5 razy na sekundę, a ich liczba POWINNA być mniejsza niż 1 raz na sekundę.
- [8.1/H-0-2] Czas reakcji interfejsu użytkownika. Implementacje na urządzeniach MUSZĄ zapewniać użytkownikom niskie opóźnienia podczas przewijania listy zawierającej 10 tys. pozycji, zgodnie z definicją w pakiecie testów zgodności Androida (CTS) w mniej niż 36 sekund.
- [8.1/H-0-3] Przełączanie zadań. Po uruchomieniu wielu aplikacji ponowne uruchomienie już uruchomionej aplikacji MUSI zająć mniej niż 1 sekundę.
Implementacje na urządzeniach przenośnych:
- [8.2/H-0-1] MUSI zapewnić wydajność zapisu sekwencyjnego co najmniej 5 MB/s.
- [8.2/H-0-2] MUSI zapewnić wydajność zapisu losowego co najmniej 0,5 MB/s.
- [8.2/H-0-3] MUSI zapewnić wydajność sekwencyjnego odczytu na poziomie co najmniej 15 MB/s.
- [8.2/H-0-4] MUSI zapewnić wydajność losowego odczytu na poziomie co najmniej 3,5 MB/s.
Jeśli implementacje urządzeń przenośnych zawierają funkcje poprawiające zarządzanie energią urządzenia, które są dostępne w AOSP, lub rozszerzają funkcje dostępne w AOSP, muszą:
- [8.3/H-1-1] MUSISZ umożliwić użytkownikowi włączenie i wyłączenie funkcji oszczędzania baterii.
- [8.3/H-1-2] MUSISZ umożliwić użytkownikowi wyświetlanie wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.
Implementacje na urządzeniach przenośnych:
- [8.4/H-0-1] MUSISZ podać profil poboru mocy dla każdego komponentu, który definiuje wartość bieżącego poboru energii dla każdego komponentu sprzętowego oraz przybliżony pobór energii z baterii spowodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie Projektu Android Open Source.
- [8.4/H-0-2] Musisz podać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
- [8.4/H-0-3] MUST report CPU power
consumption per each process's UID. Projekt Android Open Source spełnia wymagania dzięki implementacji modułu jądra
uid_cputime
. - [8.4/H-0-4] DEWELOPER MUSI udostępnić tę wartość za pomocą polecenia
adb shell dumpsys batterystats
w powłoce dla dewelopera aplikacji. - [8.4/H] POWINIEN być przypisany do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.
Jeśli implementacje urządzeń przenośnych obejmują ekran lub wyjście wideo, muszą:
- [8.4/H-1-1] MUSI obsługiwać intencję
android.intent.action.POWER_USAGE_SUMMARY
i wyświetlać menu ustawień, które pokazuje zużycie energii.
Implementacje na urządzeniach przenośnych:
- [8.5/H-0-1] W menu Ustawienia należy udostępnić użytkownikowi możliwość zatrzymania aplikacji, która uruchamia usługę na pierwszym planie, oraz wyświetlić wszystkie aplikacje z aktywnymi usługami na pierwszym planie i czas trwania każdej z tych usług od momentu jej uruchomienia, zgodnie z opisem w dokumencie SDK.
- Niektóre aplikacje mogą być wyłączone z możliwości zatrzymania lub wyświetlenia w takim interfejsie użytkownika, jak opisano w dokumencie pakietu SDK.
2.2.5. Model zabezpieczeń
Implementacje na urządzeniach przenośnych:
- [9.1/H-0-1] Musisz zezwolić aplikacjom innych firm na dostęp do statystyk użycia za pomocą uprawnienia
android.permission.PACKAGE_USAGE_STATS
oraz udostępnić użytkownikom mechanizm przyznawania i odbierania dostępu do takich aplikacji w odpowiedzi na ich intencjęandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
.
Implementacje na urządzeniach przenośnych:
- [9.11/H-0-2] Musisz utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
- [9.11/H-0-3] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać obsługiwane algorytmy systemu Keystore na Androidzie w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i powyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest też inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
- [9.11/H-0-4] NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonywania i dopiero po pomyślnym uwierzytelnieniu zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w otoczeniu odizolowanego wykonania. Projekt źródłowy Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymogu.
- [9.11/H-0-5] MUSI obsługiwać atestację klucza, w której klucz do podpisywania jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania muszą być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻE być używany inny klucz.
- [9/H-0-1] NALEŻY zadeklarować funkcję „android.hardware.security.model.compatible”.
Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi ona spełniać wymagań dotyczących posiadania magazynu kluczy obsługiwanego przez odizolowane środowisko wykonywania i obsługiwania uwierzytelniania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint
, która wymaga magazynu kluczy obsługiwanego przez odizolowane środowisko wykonywania.
Gdy implementacje urządzeń przenośnych obsługują bezpieczny ekran blokady, mogą:
- [9.11/H-1-1] Musisz umożliwić użytkownikowi wybranie najkrótszego czasu bezczynności (czasu przejścia z niezablokowanego do zablokowanego stanu) nie dłuższego niż 15 sekund.
- [9.11/H-1-2] MUSISZ umożliwić użytkownikowi ukrywanie powiadomień i wyłączanie wszystkich form uwierzytelniania z wyjątkiem uwierzytelniania podstawowego opisanego w sekcji 9.11.1 Bezpieczny ekran blokady. AOSP spełnia ten wymóg jako tryb blokady.
Jeśli implementacje na urządzeniach przenośnych obsługują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony
, nie mogą:
- [9.5/H-2-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która pozwala właścicielom urządzeń zarządzać dodatkowymi użytkownikami i ich uprawnieniami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, z możliwością zarządzania bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.
Jeśli implementacje na urządzeniach przenośnych obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony
, muszą:
- [9.5/H-3-1] NIE MUSI obsługiwać profili ograniczonych, ale MUSI być zgodny z implementacją kontroli AOSP, aby włączać i wyłączać dostęp innych użytkowników do połączeń głosowych i SMS-ów.
Android, za pomocą interfejsu System API VoiceInteractionService obsługuje mechanizm bezpiecznego wykrywania słów-kluczy w trybie ciągłego działania bez wskazania dostępu do mikrofonu.
Jeśli implementacje urządzeń przenośnych obsługują interfejs System APIHotwordDetectionService
lub inny mechanizm wykrywania słów kluczowych bez wskazania dostępu do mikrofonu, to:
- [9.8/H-1-1] NALEŻY zadbać o to, aby usługa wykrywania słów kluczowych mogła przesyłać dane tylko do System lub ContentCaptureService
- [9.8/H-1-2] NALEŻY się upewnić, że usługa wykrywania słów kluczowych może przesyłać do serwera systemu tylko dane audio z mikrofonu lub dane z nich pochodzące za pomocą interfejsu
HotwordDetectionService
API lub doContentCaptureService
za pomocą interfejsuContentCaptureManager
API. - [9.8/H-1-3] Nie wolno przesyłać dźwięku z mikrofonu dłuższego niż 30 sekund w przypadku pojedynczego żądania wywołanego przez sprzęt do usługi wykrywania słów kluczowych.
- [9.8/H-1-4] W przypadku pojedynczego zapytania do usługi wykrywania słów-kluczy nie wolno przesyłać do niej zasobów dźwiękowych z buforu mikrofonu starszych niż 8 sekund.
- [9.8/H-1-5] Do usługi interakcji głosowej lub podobnego podmiotu NIE MOŻNA przesyłać do bufora dźwięku z mikrofonu starszego niż 30 sekund.
- [9.8/H-1-6] NIE wolno przesyłać więcej niż 100 bajtów danych niebędących danymi audio z usługi wykrywania słów-kluczy w przypadku każdego wyniku wykrycia słowa-klucza.
- [9.8/H-1-7] NIE wolno zezwalać na przesyłanie więcej niż 5 bitów danych z usługi wykrywania słów kluczowych w przypadku każdego wyniku wykluczającego słowo kluczowe.
- [9.8/H-1-8] NALEŻY zezwalać na przesyłanie danych z usługi wykrywania słów kluczowych tylko w odpowiedzi na żądanie weryfikacji słowa kluczowego z serwera systemowego.
- [9.8/H-1-9] NIE wolno zezwalać aplikacji instalowanej przez użytkownika na świadczenie usługi wykrywania słów kluczowych.
- [9.8/H-1-10] W interfejsie nie mogą być widoczne dane ilościowe dotyczące używania mikrofonu przez usługę wykrywania słów kluczowych.
- [9.8/H-1-11] NALEŻY rejestrować liczbę bajtów zawartych w każdej transmisji z usługi wykrywania słów kluczowych, aby umożliwić badaczom bezpieczeństwa jej sprawdzenie.
- [9.8/H-1-12] MUSI obsługiwać tryb debugowania, który rejestruje surowe treści każdej transmisji z usługi wykrywania słów kluczowych, aby umożliwić badaczom bezpieczeństwa ich sprawdzenie.
- [9.8/H-1-14] NALEŻY wyświetlić wskaźnik mikrofonu zgodnie z opisem w sekcji 9.8.2, gdy wynik działania słówka aktywującego zostanie przekazany do usługi interakcji głosowej lub podobnego podmiotu.
- [9.8/H-SR-1] ZDECYTOWANIE zaleca się powiadomienie użytkowników przed ustawieniem aplikacji jako dostawcy usługi wykrywania słów kluczowych.
- [9.8/H-SR-2] ZDECYDOWANIE zalecamy zablokowanie przesyłania danych nieuporządkowanych z usługi wykrywania słów kluczowych.
- [9.8/H-SR-3] ZALECAMY, aby proces hostujący usługę wykrywania słów kluczowych był ponownie uruchamiany co godzinę lub co 30 zdarzeń wywołanych przez 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 APIHotwordDetectionService
lub podobnego mechanizmu wykrywania słów kluczowych bez wskazania użycia mowy, aplikacja:
- [9.8/H-2-1] MUST provide explicit notice to the user for each hotword phrase supported.
- [9.8/H-2-2] NIE NALEŻY zachowywać surowych danych audio ani danych z nich pochodzących w usłudze wykrywania słów kluczowych.
- [9.8/H-2-3] NIE wolno przesyłać z usługi wykrywania słów kluczowych danych audio, danych, które mogą posłużyć do odtworzenia (w całości lub częściowo) dźwięku, ani treści audio niezwiązanych ze słowem kluczowym, z wyjątkiem tych przesyłanych do
ContentCaptureService
.
Jeśli implementacje urządzeń przenośnych deklarują android.hardware.microphone
, muszą:
- [9.8.2/H-4-1] MUSI wyświetlać wskaźnik mikrofonu, gdy aplikacja uzyskuje dostęp do danych audio z mikrofonu, ale nie wtedy, gdy mikrofon jest używany tylko przez
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
lub aplikacje, które mają role wymienione w sekcji 9.1 z identyfikatorem CDD [C-4-X]. - [9.8.2/H-4-2] MUSI wyświetlać listę ostatnich i aktywnych aplikacji korzystających z mikrofonu, zwracaną przez
PermissionManager.getIndicatorAppOpUsageData()
, wraz z wszelkimi komunikatami atrybutu powiązanymi z tymi aplikacjami.
Jeśli implementacje urządzeń przenośnych deklarują android.hardware.camera.any
, muszą:
- [9.8.2/H-5-1] Musi wyświetlać wskaźnik kamery, gdy aplikacja uzyskuje dostęp do danych z kamery na żywo, ale nie wtedy, gdy dostęp do kamery mają tylko aplikacje, które mają role wymienione w sekcji 9.1 z identyfikatorem CDD [C-4-X].
- [9.8.2/H-5-2] MUSI wyświetlać Ostatnie i Aktywne aplikacje korzystające z kamery zgodnie z informacjami z
PermissionManager.getIndicatorAppOpUsageData()
, wraz z wszelkimi komunikatami dotyczącymi atrybucji.
2.2.6. Zgodność narzędzi dla programistów i opcji
Implementacje na urządzeniach przenośnych (* Nie dotyczy tabletów):
- [6.1/H-0-1]* MUSI obsługiwać polecenie w powłoce
cmd testharness
.
Implementacje na urządzeniach przenośnych (* Nie dotyczy tabletów):
- Perfetto
- [6.1/H-0-2]* Musi udostępniać użytkownikowi powłoki binarny plik
/system/bin/perfetto
, którego cmdline jest zgodny z dokumentacją perfetto. - [6.1/H-0-3]* Binarny pakiet perfetto MUSI akceptować jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/H-0-4]* Binarny plik perfetto MUSI zapisywać jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/H-0-5]* Musisz zapewnić w pliku binarnym perfetto co najmniej te źródła danych, które są opisane w dokumentacji perfetto.
- [6.1/H-0-6]* Demon śledzenia perfetto MUSI być domyślnie włączony (właściwość systemowa
persist.traced.enable
).
- [6.1/H-0-2]* Musi udostępniać użytkownikowi powłoki binarny plik
2.2.7. Klasa dotycząca wydajności urządzeń przenośnych
Definicję klasy skuteczności mediów znajdziesz w sekcji 7.11.
2.2.7.1. Multimedia
Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.S
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania dotyczące multimediów wymienione w dokumentacji dotyczącej Androida 12 w sekcji 2.2.7.1.
Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.T
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- [5.1/H-1-1] NALEŻY podać maksymalną liczbę sesji dekodera wideo sprzętowego, które mogą być wykonywane jednocześnie w dowolnej kombinacji kodeków za pomocą metod
CodecCapabilities.getMaxSupportedInstances()
iVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] MUSI obsługiwać 6 sesji dekodera wideo sprzętowego (AVC, HEVC, VP9, AV1 lub nowszy) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 1080p przy 30 fps.
- [5.1/H-1-3] MUST advertise the maximum number of hardware video encoder
sessions that can be run concurrently in any codec combination via the
CodecCapabilities.getMaxSupportedInstances()
andVideoCapabilities.getSupportedPerformancePoints()
methods. - [5.1/H-1-4] MUSI obsługiwać 6 sesji sprzętowego kodera wideo (AVC, HEVC, VP9, AV1 lub nowszy) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 1080p przy 30 fps.
- [5.1/H-1-5] NALEŻY reklamować maksymalną liczbę sesji kodowania i dekodowania wideo za pomocą sprzętu, które mogą być wykonywane jednocześnie w dowolnej kombinacji kodeków za pomocą metod
CodecCapabilities.getMaxSupportedInstances()
iVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] MUSI obsługiwać 6 sesji sprzętowego dekodera wideo i sprzętowego kodera wideo (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 1080p przy 30 fps.
- [5.1/H-1-7] W przypadku sesji kodowania wideo w rozdzielczości 1080p lub niższej we wszystkich sprzętowych kodekiach wideo czas opóźnienia inicjalizacji kodeka MUSI wynosić 40 ms lub mniej. Obciążenie jest tu zdefiniowane jako jednoczesna sesja transkodowania wideo z 1080p na 720p z wykorzystaniem kodeków wideo sprzętowych oraz inicjalizacja nagrywania dźwięku i obrazu w rozdzielczości 1080p. W przypadku kodeka Dolby Vision opóźnienie inicjowania kodeka MUSI wynosić 50 ms lub mniej.
- [5.1/H-1-8] Latency początkowej konfiguracji kodeka MUSI wynosić 30 ms lub mniej w przypadku sesji kodowania dźwięku o szybkości transmisji 128 kb/s lub niższej dla wszystkich koderów audio podczas obciążenia. Obciążenie jest tu zdefiniowane jako równoległa sesja transkodowania z 1080p na 720p tylko dla wideo, która wykorzystuje kodeki wideo sprzętowe, oraz inicjalizacja nagrywania dźwięku i obrazu w rozdzielczości 1080p.
- [5.1/H-1-9] MUSI obsługiwać 2 wystąpienia sesji bezpiecznego sprzętowego dekodera wideo (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 1080p przy 30 fps.
- [5.1/H-1-10] MUSI obsługiwać 3 sesje niechronionego sprzętowego dekodera wideo oraz 1 sesję chronionego sprzętowego dekodera wideo (łącznie 4 sesje) (AVC, HEVC, VP9, AV1 lub nowszy) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 1080p przy 30 fps.
- [5.1/ H-1-11] MUSI obsługiwać bezpieczny dekoder dla każdego sprzętowego dekodera AVC, HEVC, VP9 lub AV1 na urządzeniu.
- [5.1/H-1-12] Czas opóźnienia inicjalizacji kodeka musi wynosić 40 ms lub mniej w przypadku sesji dekodowania wideo w rozdzielczości 1080p lub niższej dla wszystkich dekoderów wideo sprzętowych podczas obciążenia. Obciążenie jest tu zdefiniowane jako jednoczesna sesja transkodowania z 1080p na 720p tylko wideo z wykorzystaniem kodeków wideo sprzętowych oraz inicjalizacja odtwarzania dźwięku i obrazu w jakości 1080p. W przypadku kodeka Dolby Vision opóźnienie inicjalizacji musi wynosić 50 ms lub mniej.
- [5.1/H-1-13] Czas opóźnienia inicjalizacji kodeka MUSI wynosić 30 ms lub mniej w przypadku sesji dekodowania dźwięku o szybkości transmisji 128 kb/s lub niższej dla wszystkich dekoderów audio podczas obciążenia. Obciążenie jest tu zdefiniowane jako równoległa sesja transkodowania z 1080p na 720p tylko wideo za pomocą kodeków wideo sprzętowych oraz inicjalizacja odtwarzania dźwięku i obrazu w jakości 1080p.
- [5.1/H-1-14] MUSI obsługiwać dekoder sprzętowy AV1 Main 10, poziom 4.1.
- [5.1/H-SR-1] MOCNO ZALECAMY obsługę ziarna filmowego dla dekodera AV1.
- [5.1/H-1-15] Musisz mieć co najmniej 1 sprzętowy dekoder wideo obsługujący 4K60.
- [5.1/H-1-16] MUSISZ mieć co najmniej 1 sprzętowy koder wideo obsługujący 4K60.
- [5.3/H-1-1] W przypadku sesji wideo 1080p 60 fps NIE MOŻE utracić więcej niż 1 klatka w ciągu 10 sekund (czyli mniej niż 0,167 proc. utraty klatek) podczas wczytywania. Obciążenie jest zdefiniowane jako jednoczesna sesja transkodowania wideo z 1080p na 720p z wykorzystaniem kodeków wideo sprzętowych oraz odtwarzanie dźwięku AAC 128 kbps.
- [5.3/H-1-2] Nie wolno tracić więcej niż 1 klatkę na 10 sekund podczas zmiany rozdzielczości w trakcie wczytywania sesji wideo z szybkością 60 fps. Obciążenie jest zdefiniowane jako jednoczesna sesja transkodowania wideo z 1080p na 720p przy użyciu kodeków wideo sprzętowych oraz odtwarzanie dźwięku AAC 128 kbps.
- [5.6/H-1-1] MUSI mieć opóźnienie tap-to-tone na poziomie 80 ms lub mniej, zmierzone za pomocą testu tap-to-tone OboeTester lub testu tap-to-tone CTS Verifier.
- [5.6/H-1-2] Musi mieć opóźnienie audio w obie strony nieprzekraczające 80 ms na co najmniej jednej obsługiwanej ścieżce danych.
- [5.6/H-1-3] MUSI obsługiwać dźwięk 24-bitowy w przypadku wyjścia stereofonicznego przez gniazdo audio 3,5 mm (jeśli jest dostępne) i przez USB (jeśli jest obsługiwane) na całej ścieżce danych w przypadku niskiej latencji i konfiguracji przesyłania strumieniowego. W przypadku konfiguracji o niskim opóźnieniu aplikacja powinna używać AAudio w trybie wywołania zwrotnego o niskim opóźnieniu. W przypadku konfiguracji strumieniowego przesyłania danych aplikacja powinna używać obiektu Java AudioTrack. Zarówno w przypadku konfiguracji o niskiej latencji, jak i konfiguracji strumieniowego przesyłania danych odbiornik HAL powinien akceptować
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
lubAUDIO_FORMAT_PCM_FLOAT
jako docelowy format wyjściowy. - [5.6/H-1-4] MUSI obsługiwać urządzenia audio USB z co najmniej 4 kanałami (służą one do podłączania kontrolerów DJ do podglądu utworów).
- [5.6/H-1-5] MUSI obsługiwać urządzenia MIDI zgodne z klasą i deklarować flagę funkcji MIDI.
- [5.7/H-1-2] MUSI obsługiwać
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
z tymi funkcjami odszyfrowywania treści:
Minimalna wielkość próby | 4 MiB |
Minimalna liczba podpróbek – H.264 lub HEVC | 32 |
Minimalna liczba podpróbek – VP9 | 9 |
Minimalna liczba podpróbek – AV1 | 288 |
Minimalny rozmiar bufora podpróbki | 1 MiB |
Minimalny rozmiar ogólnego bufora szyfrowania | 500 KiB |
Minimalna liczba jednoczesnych sesji | 30 |
Minimalna liczba kluczy na sesję | 20 |
Minimalna łączna liczba kluczy (wszystkie sesje) | 80 |
Minimalna łączna liczba kluczy DRM (wszystkie sesje) | 6 |
Rozmiar wiadomości | 16 KiB |
Deszyfrowane klatki na sekundę | 60 fps |
2.2.7.2. Aparat
Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.S
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania dotyczące aparatu wymienione w dokumentacji CDD Androida 12 w sekcji 2.2.7.2.
Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.T
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- [7.5/H-1-1] Urządzenie MUSI mieć tylną kamerę o rozdzielczości co najmniej 12 Mpix, która umożliwia nagrywanie filmów w rozdzielczości 4K przy 30 fps. Główny tylny aparat to tylny aparat o najniższym identyfikatorze.
- [7.5/H-1-2] Musisz mieć główną przednią kamerę o rozdzielczości co najmniej 5 Mpix i obsługującą nagrywanie filmów w rozdzielczości 1080p przy 30 fps. Główny aparat przedni to aparat przedni o najniższym identyfikatorze.
- [7.5/H-1-3] MUSI obsługiwać właściwości
android.info.supportedHardwareLevel
jakoFULL
lub wyższą w przypadku głównego tylnego aparatu orazLIMITED
lub wyższą w przypadku głównego przedniego aparatu. - [7.5/H-1-4] Musi obsługiwać
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
w przypadku obu głównych kamer. - [7.5/H-1-5] W przypadku aparatu 2 opóźnienie w przypadku formatu JPEG musi wynosić mniej niż 1000 ms w rozdzielczości 1080p, mierzone przez test wydajności aparatu CTS w warunkach oświetlenia ITS (3000 K) w przypadku obu aparatów głównych.
- [7.5/H-1-6] Czas oczekiwania na uruchomienie aplikacji camera2 (od otwarcia aparatu do pierwszego podglądu obrazu) musi być mniejszy niż 500 ms, mierzony za pomocą testu PerformanceTest w ramach CTS w warunkach oświetlenia ITS (3000 K) w przypadku obu głównych aparatów.
- [7.5/H-1-8] MUST support
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
andandroid.graphics.ImageFormat.RAW_SENSOR
for the primary back camera. - [7.5/H-1-9] Urządzenie MUSI mieć tylny aparat główny obsługujący rozdzielczość 720p lub 1080p przy 240 fps.
- [7.5/H-1-10] W przypadku kamer głównych MUSISZ mieć minimalny współczynnik ZOOM_RATIO < 1.0, jeśli istnieje kamera ultraszerokokątna RGB skierowana w ten sam kierunek.
- [7.5/H-1-11] NALEŻY wdrożyć jednoczesny streaming z przodu i z tyłu na głównych kamerach.
- [7.5/H-1-12] MUST support
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
for the primary back camera. - [7.5/H-1-13] Musi obsługiwać funkcję
LOGICAL_MULTI_CAMERA
w przypadku głównego tylnego aparatu, jeśli jest więcej niż 1 RGB-owy tylny aparat. - [7.5/H-1-14] Musi obsługiwać funkcję
STREAM_USE_CASE
zarówno w przypadku głównego aparatu przedniego, jak i głównego aparatu tylnego.
2.2.7.3. Sprzęt
Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.S
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- Muszą spełniać wymagania sprzętowe wymienione w dokumentacji CDD Androida 12 w sekcji 2.2.7.3.
Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.T
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- [7.1.1/H-2-1] Rozdzielczość ekranu MUSI wynosić co najmniej 1080p.
- [7.1.1.3/H-2-1] gęstość pikseli na ekranie MUSI wynosić co najmniej 400 dpi.
- [7.6.1/H-2-1] Musisz mieć co najmniej 8 GB pamięci fizycznej.
2.2.7.4. Wydajność
Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.S
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- MUSI spełniać wymagania dotyczące wydajności wymienione w dokumentacji CDD dla Androida 12 w sekcji 2.2.7.4.
Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.T
dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, to:
- [8.2/H-1-1] MUSI zapewnić wydajność sekwencyjnego zapisu co najmniej 125 MB/s.
- [8.2/H-1-2] NALEŻY zapewnić wydajność zapisu losowego na poziomie co najmniej 10 MB/s.
- [8.2/H-1-3] MUSI zapewnić wydajność sekwencyjnego odczytu co najmniej 250 MB/s.
- [8.2/H-1-4] MUSI zapewnić wydajność losowego odczytu na poziomie co najmniej 40 MB/s.
2.3. Wymagania dotyczące telewizorów
Urządzenie Android TV to implementacja urządzenia z Androidem, która jest interfejsem rozrywkowym do oglądania mediów cyfrowych, filmów, gier, aplikacji lub telewizji na żywo przez użytkowników siedzących w odległości około 3 metrów (interfejs „lean back” lub „10-foot user interface”).
Implementacje urządzeń z Androidem są klasyfikowane jako telewizory, jeśli spełniają wszystkie te kryteria:
- udostępnić mechanizm zdalnego sterowania renderowanym interfejsem użytkownika na wyświetlaczu, który może znajdować się w odległości 3 metrów od użytkownika;
- Urządzenie musi mieć wbudowany ekran o przekątnej większej niż 24 cale LUB musi mieć port wyjścia wideo, np. VGA, HDMI, DisplayPort lub port bezprzewodowy do wyświetlania.
Dodatkowe wymagania w pozostałych częściach tej sekcji dotyczą implementacji na urządzeniach z Androidem.
2.3.1. Sprzęt
Implementacje na telewizorach:
- [7.2.2/T-0-1] MUSI obsługiwać D-pad.
- [7.2.3/T-0-1] MUSI zawierać funkcje Wstecz i Wstecz.
- [7.2.3/T-0-2] DO aplikacji na pierwszym planie należy wysłać zdarzenie naciśnięcia i długiego naciśnięcia przycisku Wstecz (
KEYCODE_BACK
). - [7.2.6.1/T-0-1] MUSI zawierać obsługę kontrolerów gier i ogłosić flagę funkcji
android.hardware.gamepad
. - [7.2.7/T] NALEŻY zapewnić zdalne sterowanie, za pomocą którego użytkownicy mogą korzystać z nawigacji bezdotykowej i podstawowych klawiszy nawigacyjnych.
Jeśli implementacje telewizorów zawierają 3-osiowy żyroskop, muszą:
- [7.3.4/T-1-1] MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
- [7.3.4/T-1-2] MUSI umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę.
Implementacje na telewizorach:
- [7.4.3/T-0-1] MUSI obsługiwać Bluetooth i Bluetooth LE.
- [7.6.1/T-0-1] Musi być dostępne co najmniej 4 GB pamięci nieulotnej na potrzeby prywatnych danych aplikacji (czyli na partycji „/data”).
Jeśli implementacje telewizorów zawierają port USB obsługujący tryb hosta, to:
- [7.5.3/T-1-1] MUSI obsługiwać kamerę zewnętrzną, która łączy się przez ten port USB, ale nie musi być zawsze podłączona.
Jeśli implementacje urządzeń TV są 32-bitowe:
[7.6.1/T-1-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 896 MB, jeśli używana jest dowolna z tych gęstości:
- 400 dpi lub więcej na małych/normalnych ekranach
- xhdpi lub wyższa na dużych ekranach
- tvdpi lub wyższa na bardzo dużych ekranach.
Jeśli implementacje urządzeń TV są 64-bitowe:
[7.6.1/T-2-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1280 MB, jeśli używana jest dowolna z tych gęstości:
- 400 dpi lub więcej na małych/normalnych ekranach
- xhdpi lub wyższa na dużych ekranach
- tvdpi lub wyższa na bardzo dużych ekranach.
Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do przestrzeni pamięci udostępnionej oprócz pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro w implementacjach urządzenia.
Implementacje na telewizorach:
- [7.8.1/T] NALEŻY uwzględnić mikrofon.
- [7.8.2/T-0-1] MUSI mieć wyjście audio i deklarować
android.hardware.audio.output
.
2.3.2. Multimedia
Implementacje urządzeń telewizyjnych MUSZĄ obsługiwać te formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:
- [5.1/T-0-1] Profil MPEG-4 AAC (AAC LC)
- [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/T-0-3] AAC ELD (ulepszona jakość dźwięku AAC z małym opóźnieniem)
Implementacje urządzeń telewizyjnych MUSZĄ obsługiwać te formaty kodowania wideo i udostępniać je aplikacjom innych firm:
Implementacje na telewizorach:
- [5.2.2/T-SR-1] MOCNO POLECAMY obsługę kodowania H.264 filmów w rozdzielczości 720p i 1080p z szybkością 30 klatek na sekundę.
Implementacje urządzeń telewizyjnych MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
Implementacje telewizorów MUSZĄ obsługiwać dekodowanie MPEG-2 zgodnie z opisem w sekcji 5.3.1 przy standardowych częstotliwościach klatek i rozdzielczościach do:
- [5.3.1/T-1-1] HD 1080p z szybkością 29,97 klatek na sekundę z profilem głównym High Level.
- [5.3.1/T-1-2] HD 1080i przy 59,94 klatkach na sekundę z profilem głównym High Level. Muszą deinterlaceować przeplotowane wideo MPEG-2 i udostępnić je aplikacjom innych firm.
Implementacje telewizorów MUSZĄ obsługiwać dekodowanie H.264 zgodnie z opisem w sekcji 5.3.4 przy standardowych częstotliwościach klatek i rozdzielczościach do:
- [5.3.4/T-1-1] HD 1080p przy 60 klatkach na sekundę z profilem podstawowym
- [5.3.4/T-1-2] HD 1080p przy 60 klatkach na sekundę z profilem głównym
- [5.3.4/T-1-3] HD 1080p przy 60 klatkach na sekundę z profilem High Level 4.2
Implementacje telewizorów z dekoderami sprzętowymi H.265 MUSZĄ obsługiwać dekodowanie H.265 zgodnie z opisem w sekcji 5.3.5 przy standardowych szybkościach klatek wideo i rozdzielczościach do:
- [5.3.5/T-1-1] HD 1080p przy 60 kl./s z profilem głównym poziomu 4.1
Jeśli implementacje telewizorów z dekoderami sprzętowymi H.265 obsługują dekodowanie H.265 i profil dekodowania UHD, to:
- [5.3.5/T-2-1] MUSI obsługiwać profil dekodowania UHD przy 60 klatkach na sekundę z profilem Main10 Level 5 Main Tier
Implementacje telewizorów MUSZĄ obsługiwać dekodowanie VP8 zgodnie z opisem w sekcji 5.3.6 przy standardowych częstotliwościach klatek i rozdzielczościach do:
- [5.3.6/T-1-1] Profil dekodowania HD 1080p przy 60 kl./s
Implementacje telewizorów z dekoderami sprzętowymi VP9 MUSZĄ obsługiwać dekodowanie VP9 zgodnie z opisem w sekcji 5.3.7 przy standardowych częstotliwościach klatek i rozdzielczościach wideo do:
- [5.3.7/T-1-1] HD 1080p przy 60 klatkach na sekundę z profilem 0 (8-bitowa głębia kolorów)
Jeśli implementacje telewizorów z dekoderami sprzętowymi VP9 obsługują dekodowanie VP9 i profil dekodowania UHD, to:
- [5.3.7/T-2-1] MUSI obsługiwać profil dekodowania UHD z szybkością 60 FPS z profilem 0 (głębia kolorów 8 bitów).
- [5.3.7/T-SR1] MOCNO POLECAMY obsługę profilu dekodowania UHD z prędkością 60 FPS z profilem 2 (10-bitowa głębia kolorów).
Implementacje na telewizorach:
- [5.5/T-0-1] MUSI obsługiwać system Master Volume i obniżanie głośności wyjścia audio cyfrowego na obsługiwanych wyjściach, z wyjątkiem wyjścia z przepuszczaniem skompresowanego dźwięku (gdzie nie jest wykonywane dekodowanie dźwięku na urządzeniu).
Jeśli implementacje telewizorów nie mają wbudowanego wyświetlacza, ale obsługują wyświetlacz zewnętrzny podłączony przez HDMI, to:
- [5.8/T-0-1] NALEŻY ustawić tryb wyjścia HDMI, aby wybrać maksymalną rozdzielczość, która może być obsługiwana przy częstotliwości odświeżania 50 Hz lub 60 Hz.
- [5.8/T-SR-1] MOCNO POLECAMY udostępnienie użytkownikowi opcji wyboru częstotliwości odświeżania HDMI.
- [5.8] NALEŻY ustawić częstotliwość odświeżania w trybie wyjścia HDMI na 50 Hz lub 60 Hz w zależności od częstotliwości odświeżania wideo w regionie, w którym sprzedawane jest urządzenie.
Jeśli implementacje telewizorów nie mają wbudowanego wyświetlacza, ale obsługują wyświetlacz zewnętrzny podłączony przez HDMI, to:
- [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, to:
- [5.8/T-2-1] MUSI obsługiwać HDCP 1.4
2.3.3. Oprogramowanie
Implementacje na telewizorach:
- [3/T-0-1] NALEŻY zadeklarować funkcje
android.software.leanback
iandroid.hardware.type.television
. - [3.2.3.1/T-0-1] W przypadku wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez te intencje aplikacji (wymienione tutaj) MUSISZ wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji.
- [3.4.1/T-0-1] Musisz wdrożyć interfejs API
android.webkit.Webview
.
Jeśli implementacje urządzeń z Androidem TV obsługują ekran blokady:
- [3.8.10/T-1-1] Musi wyświetlać powiadomienia na ekranie blokady, w tym szablon powiadomienia z multimediami.
Implementacje na telewizorach:
- [3.8.14/T-SR-1] ZALECAMY, aby obsługiwać tryb obrazu w obrazie (PIP) w wielu oknach.
- [3.10/T-0-1] MUSI obsługiwać usługi dostępności innych firm.
- [3.10/T-SR-1] MOCNO POLECAMY wstępne załadowanie na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z funkcjonalnością usług Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) zgodnie z projektem TalkBack Open Source.
Jeśli implementacje telewizorów obsługują funkcję
android.hardware.audio.output
, to:
- [3.11/T-SR-1] MOCNO zaleca się uwzględnienie mechanizmu TTS obsługującego języki dostępne na urządzeniu.
- [3.11/T-1-1] MUSI obsługiwać instalację zewnętrznych silników TTS.
Implementacje na telewizorach:
- [3.12/T-0-1] MUSI obsługiwać platformę TV Input Framework.
2.3.4. Wydajność i moc
- [8.1/T-0-1] Stabilne opóźnienie klatek. Niespójny czas oczekiwania na renderowanie lub opóźnienie w renderowaniu klatek NIE POWINNY występować częściej niż 5 razy na sekundę, a ich liczba POWINNA być mniejsza niż 1 raz na sekundę.
- [8.2/T-0-1] MUSI zapewnić wydajność zapisu sekwencyjnego co najmniej 5 MB/s.
- [8.2/T-0-2] MUSI zapewnić wydajność zapisu losowego na poziomie co najmniej 0,5 MB/s.
- [8.2/T-0-3] NALEŻY zapewnić wydajność sekwencyjnego odczytu na poziomie co najmniej 15 MB/s.
- [8.2/T-0-4] MUSI zapewnić wydajność losowego odczytu na poziomie co najmniej 3,5 MB/s.
Jeśli implementacje telewizorów zawierają funkcje poprawiające zarządzanie energią urządzenia, które są zawarte w AOSP, lub rozszerzają funkcje zawarte w AOSP, muszą:
- [8.3/T-1-1] MUST provide user affordance to enable and disable the battery saver feature.
Jeśli implementacje telewizorów nie mają baterii:
- [8.3/T-1-2] NALEŻY zarejestrować urządzenie jako urządzenie bez baterii zgodnie z opisem w Obsługiwaniu urządzeń bez baterii.
Jeśli implementacje telewizorów mają baterię:
- [8.3/T-1-3] Musisz umożliwić użytkownikom wyświetlanie wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.
Implementacje na telewizorach:
- [8.4/T-0-1] MUSISZ podać profil poboru mocy dla każdego komponentu, który definiuje wartość bieżącego poboru energii dla każdego komponentu sprzętowego oraz przybliżony pobór energii z baterii spowodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie Projektu Android Open Source.
- [8.4/T-0-2] Musisz podać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
- [8.4/T-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia wymagania dzięki implementacji modułu jądra
uid_cputime
. - [8.4/T] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.
- [8.4/T-0-4] Musisz udostępnić ten pobór mocy za pomocą polecenia
adb shell dumpsys batterystats
w powłoce deweloperowi aplikacji.
2.3.5. Model zabezpieczeń
Implementacje na telewizorach:
- [9.11/T-0-1] Musisz utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
- [9.11/T-0-2] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać obsługiwane algorytmy systemu Keystore na Androidzie w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i powyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest też inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
- [9.11/T-0-3] NALEŻY przeprowadzić uwierzytelnianie ekranu blokady w odizolowanym środowisku wykonywania i dopiero po pomyślnym uwierzytelnieniu zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w otoczeniu odizolowanego wykonania. Projekt źródłowy Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymogu.
- [9.11/T-0-4] MUSI obsługiwać atestację klucza, w której klucz do podpisywania atestacji jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania muszą być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻE być używany inny klucz.
- [9/T-0-1] NALEŻY zadeklarować funkcję „android.hardware.security.model.compatible”.
Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi ona spełniać wymagań dotyczących posiadania magazynu kluczy obsługiwanego przez odizolowane środowisko wykonywania i obsługiwania uwierzytelniania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint
, która wymaga magazynu kluczy obsługiwanego przez odizolowane środowisko wykonywania.
Jeśli implementacje telewizorów obsługują bezpieczny ekran blokady, muszą:
- [9.11/T-1-1] NALEŻY umożliwić użytkownikowi wybranie czasu bezczynności przed przejściem z stanu odblokowanego do zablokowanego, z minimalnym dozwolonym czasem bezczynności wynoszącym maksymalnie 15 sekund.
Jeśli implementacje urządzeń telewizyjnych obejmują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony
, nie:
- [9.5/T-2-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która pozwala właścicielom urządzeń zarządzać dodatkowymi użytkownikami i ich uprawnieniami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, z możliwością zarządzania bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.
Jeśli implementacje telewizorów obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony
, muszą:
- [9.5/T-3-1] NIE MUSI obsługiwać profili ograniczonych, ale MUSI być zgodny z implementacją kontroli AOSP, aby umożliwić /zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.
Jeśli implementacje urządzeń telewizyjnych deklarują android.hardware.microphone
, muszą:
- [9.8.2/T-4-1] MUSI wyświetlać wskaźnik mikrofonu, gdy aplikacja uzyskuje dostęp do danych audio z mikrofonu, ale nie wtedy, gdy mikrofon jest używany tylko przez HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService lub aplikacje pełniące role wymienione w sekcji 9.1. Permissions with CDD identifier C-3-X].
- [9.8.2/T-4-2] Nie wolno ukrywać wskaźnika mikrofonu w przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.
Jeśli implementacje urządzeń telewizyjnych deklarują android.hardware.camera.any
, muszą:
- [9.8.2/T-5-1] MUSI wyświetlać wskaźnik kamery, gdy aplikacja uzyskuje dostęp do danych z kamery na żywo, ale nie wtedy, gdy dostęp do kamery mają tylko aplikacje, które pełnią role wymienione w sekcji 9.1. Uprawnienia z identyfikatorem CDD [C-3-X].
- [9.8.2/T-5-2] Nie wolno ukrywać wskaźnika kamery w przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub umożliwiają bezpośrednią interakcję z użytkownikiem.
2.3.6. Zgodność narzędzi dla programistów i opcji
Implementacje na telewizorach:
- Perfetto
- [6.1/T-0-1] NALEŻY udostępnić użytkownikowi powłoki binarną
/system/bin/perfetto
, której cmdline jest zgodny z dokumentacją perfetto. - [6.1/T-0-2] Binarny plik perfetto MUSI akceptować jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/T-0-3] Binarny plik perfetto MUSI zapisywać jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/T-0-4] Musisz udostępnić za pomocą binarnego pliku wykonywalnego perfetto co najmniej źródła danych opisane w dokumentacji perfetto.
- [6.1/T-0-1] NALEŻY udostępnić użytkownikowi powłoki binarną
2.4. Wymagania dotyczące zegarka
Urządzenie typu zegarek z Androidem to implementacja urządzenia z Androidem przeznaczona do noszenia na ciele, np. na nadgarstku.
Implementacje na urządzeniach z Androidem są klasyfikowane jako zegarek, jeśli spełniają wszystkie te kryteria:
- mieć ekran o fizycznej przekątnej o długości od 1,1 do 2,5 cala;
- mieć mechanizm umożliwiający noszenie na ciele;
Dodatkowe wymagania w pozostałych częściach tej sekcji dotyczą implementacji na urządzeniach z Androidem Watch.
2.4.1. Sprzęt
Implementacje na urządzeniach z obsługą zegarka:
[7.1.1.1/W-0-1] Musi mieć ekran o fizycznej przekątnej w zakresie od 1,1 do 2,5 cala.
[7.2.3/W-0-1] MUSI być dostępna funkcja „Strona główna” dla użytkownika oraz funkcja „Wstecz” z wyjątkiem sytuacji, gdy urządzenie jest w trybie
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] MUSI obsługiwać wprowadzanie danych za pomocą ekranu dotykowego.
[7.3.1/W-SR-1] W przypadku urządzeń mobilnych MOCNO POLECAMY uwzględnienie 3-osiowego akcelerometru.
Jeśli implementacje urządzeń Watch zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps
, to:
- [7.3.3/W-1-1] MUST report GNSS measurements, as soon as they are found, even if a location calculated from GPS/GNSS is not yet reported.
- [7.3.3/W-1-2] MUST report GNSS pseudoranges and pseudorange rates, that, in conditions of open sky after determining the location, while stationary or moving with less than 0.2 meter per second squared of acceleration, are sufficient to calculate position within 20 meters, and speed within 0.2 meters per second, at least 95% of the time.
Jeśli implementacje urządzeń Watch zawierają 3-osiowy żyroskop:
- [7.3.4/W-2-1] MUSI umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę.
Implementacje na urządzeniach z obsługą zegarka:
[7.4.3/W-0-1] MUSI obsługiwać Bluetooth.
[7.6.1/W-0-1] Musi być dostępne co najmniej 1 GB pamięci nieulotnej na potrzeby danych prywatnych aplikacji (czyli na partycji „/data”).
[7.6.1/W-0-2] Musisz mieć co najmniej 416 MB pamięci dostępnej 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
Nie ma dodatkowych wymagań.
2.4.3. Oprogramowanie
Implementacje na urządzeniach z obsługą zegarka:
- [3/W-0-1] NALEŻY zadeklarować funkcję
android.hardware.type.watch
. - [3/W-0-2] MUSI obsługiwać uiMode = UI_MODE_TYPE_WATCH.
- [3.2.3.1/W-0-1] MUSI wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji dla wszystkich publicznych wzorów filtra intencji zdefiniowanych przez te aplikacje lub komponenty usługi, które mają znaczenie dla intencji wymienionych tutaj.
Implementacje na urządzeniach z obsługą zegarka:
- [3.8.4/W-SR-1] WYMAGAMY wdrożenia na urządzeniu asystenta, który obsłuży działanie asystowania.
Sprawdź implementacje na urządzeniach, które deklarują flagę funkcji android.hardware.audio.output
:
- [3.10/W-1-1] MUSI obsługiwać zewnętrzne usługi ułatwień dostępu.
- [3.10/W-SR-1] MOCNO POLECAMY wstępnie załadować na urządzeniu usługi ułatwień dostępu o funkcjonalności porównywalnej z funkcjonalnością usług Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) zgodnie z projektem open source TalkBack.
Jeśli implementacje urządzeń Watch zgłaszają funkcję android.hardware.audio.output, to:
[3.11/W-SR-1] MOCNO zaleca się uwzględnienie mechanizmu TTS obsługującego języki dostępne na urządzeniu.
[3.11/W-0-1] MUSI obsługiwać instalację zewnętrznych silników TTS.
2.4.4. Wydajność i moc
Jeśli implementacje urządzeń Watch zawierają funkcje poprawiające zarządzanie energią urządzenia, które są zawarte w AOSP, lub rozszerzają funkcje zawarte w AOSP, muszą:
- [8.3/W-SR-1] W przypadku wszystkich aplikacji z wyłączonymi trybami App Standby i Doze MOCNO zaleca się wyświetlanie użytkownikowi informacji o tym, że aplikacja jest aktywna.
- [8.3/W-SR-2] MOCNO POLECAMY udostępnienie użytkownikowi możliwości włączania i wyłączania funkcji oszczędzania baterii.
Implementacje na urządzeniach z obsługą zegarka:
- [8.4/W-0-1] MUSISZ podać profil poboru mocy dla każdego komponentu, który definiuje wartość bieżącego poboru energii dla każdego komponentu sprzętowego oraz przybliżony pobór energii z baterii spowodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
- [8.4/W-0-2] Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
- [8.4/W-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia wymagania dzięki implementacji modułu jądra
uid_cputime
. - [8.4/W-0-4] Musisz udostępnić ten pobór mocy za pomocą polecenia
adb shell dumpsys batterystats
w powłoce dla dewelopera aplikacji. - [8.4/W] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.
2.4.5. Model zabezpieczeń
Implementacje na urządzeniach z obsługą zegarka:
- [9/W-0-1] NALEŻY zadeklarować funkcję
android.hardware.security.model.compatible
.
Jeśli implementacje urządzeń Watch obejmują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony
, nie:
- [9.5/W-1-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która pozwala właścicielom urządzeń zarządzać dodatkowymi użytkownikami i ich uprawnieniami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, z możliwością zarządzania bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.
Jeśli implementacje urządzeń Watch obejmują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony
, mają:
- [9.5/W-2-1] NIE MUSI obsługiwać profili ograniczonych, ale MUSI być zgodny z implementacją kontroli AOSP, aby zezwalać /odrzucać dostęp do połączeń głosowych i SMS-ów innym użytkownikom.
2.5. Wymagania dotyczące pojazdów
Wdrożeniem Androida Automotive nazywamy radioodtwarzacz pojazdu, w którym Android jest systemem operacyjnym częściowo lub w pełni obsługującym system lub funkcje multimedialne.
Implementacje urządzeń z Androidem są klasyfikowane jako Automotive, jeśli deklarują tę funkcję android.hardware.type.automotive
lub spełniają wszystkie te kryteria.
- są wbudowane w samochód lub są w nim wpinane.
- Używasz ekranu w rzędzie siedzeń kierowcy jako głównego wyświetlacza.
Dodatkowe wymagania w pozostałych częściach tej sekcji dotyczą implementacji na urządzeniach samochodowych z Androidem.
2.5.1. Sprzęt
Implementacje na urządzeniach samochodowych:
- [7.1.1.1/A-0-1] Ekran musi mieć co najmniej 6 cali przekątnej.
[7.1.1.1/A-0-2] Rozmiar ekranu musi wynosić co najmniej 750 dp x 480 dp.
[7.2.3/A-0-1] MUSI zawierać funkcję Wróć i MOŻE zawierać funkcje Wstecz i Ostatnie.
[7.2.3/A-0-2] DO aplikacji na pierwszym planie należy wysłać zdarzenie naciśnięcia i długiego naciśnięcia funkcji Wstecz (
KEYCODE_BACK
).[7.3/A-0-1] MUST implement and report
GEAR_SELECTION
,NIGHT_MODE
,PERF_VEHICLE_SPEED
andPARKING_BRAKE_ON
.[7.3/A-0-2] Wartość flagi
NIGHT_MODE
MUSI być zgodna z trybem dnia/nocy w panelu sterowania i POWINNA być oparta na danych z czujnika światła otoczenia. Czujnik światła otoczenia MOŻE być taki sam jak fotometr.[7.3/A-0-3] W przypadku każdego czujnika w polu SensorAdditionalInfo MUSISZ podać pole dodatkowych informacji o czujniku
TYPE_SENSOR_PLACEMENT
.[7.3/A-SR1] MOŻE obliczać lokalizację metodą bez użycia odbiornika GPS/GNSS, korzystając z dodatkowych czujników. Jeśli lokalizacja jest określana na podstawie danych z GPS, MOCNO zalecamy zaimplementowanie i raportowanie odpowiednich typów czujników lub identyfikatorów właściwości pojazdu.
[7.3/A-0-4] Lokalizacjapoproszona za pomocą LocationManager#requestLocationUpdates()NIE MOŻE być dopasowana do mapy.
[7.3.1/A-0-4] MUSI być zgodny z systemem współrzędnych czujnika samochodowego Androida.
[7.3/A-SR-1] MOCNO_ZALECANA obecność 3-osiowego akcelerometru i 3-osiowego żyroskopu.
[7.3/A-SR-2] MOCNO_ZALECANA implementacja i zgłaszanie czujnika
TYPE_HEADING
.
Jeśli implementacje urządzeń samochodowych obsługują OpenGL ES 3.1, to:
- [7.1.4.1/A-0-1] MUSI deklarować OpenGL ES 3.1 lub nowszą.
- [7.1.4.1/A-0-2] MUSI obsługiwać Vulkan 1.1.
- [7.1.4.1/A-0-3] MUSI zawierać ładowarkę Vulkana i eksportować wszystkie symbole.
Jeśli implementacje urządzeń samochodowych obejmują akcelerometr, muszą:
- [7.3.1/A-1-1] MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.
Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr, muszą:
- [7.3.1/A-SR-1] MOCNO zalecamy implementację złożonego czujnika w przypadku akcelerometru z ograniczoną liczbą osi.
Jeśli implementacje urządzeń samochodowych zawierają akcelerometr o mniej niż 3 osiach, nie mogą:
- [7.3.1/A-1-3] MUSISZ zaimplementować i zgłosić czujnik
TYPE_ACCELEROMETER_LIMITED_AXES
. - [7.3.1/A-1-4] MUSISZ zaimplementować i zgłosić czujnik
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Jeśli implementacje urządzeń samochodowych zawierają żyroskop, muszą:
- [7.3.4/A-2-1] MUSI być w stanie raportować zdarzenia z częstotliwością co najmniej 100 Hz.
- [7.3.4/A-2-3] MUSI umożliwiać pomiar zmian orientacji do 250 stopni na sekundę.
- [7.3.4/A-SR-1] ZALECAMY, aby zakres pomiarowy żyroskopu był ustawiony na +/- 250 dps, aby zmaksymalizować możliwą rozdzielczość.
Jeśli implementacje urządzeń samochodowych obejmują 3-osiowy żyroskop, muszą:
- [7.3.4/A-SR-2] MOCNO ZALECAMY implementację czujnika złożonego w przypadku żyroskopu z ograniczoną liczbą osi.
Jeśli implementacje urządzeń samochodowych zawierają żyroskop o mniej niż 3 osiach, nie mogą:
- [7.3.4/A-4-1] MUSISZ zaimplementować i zgłosić czujnik
TYPE_GYROSCOPE_LIMITED_AXES
. - [7.3.4/A-4-2] NALEŻY zaimplementować i zgłaszać dane z czujnika
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Jeśli implementacje urządzeń samochodowych obejmują odbiornik GPS/GNSS, ale nie obejmują łączności danych opartej na sieci komórkowej, muszą:
- [7.3.3/A-3-1] NALEŻY określić lokalizację za pierwszym razem, gdy odbiornik GPS/GNSS zostanie włączony, lub po upływie 4 dni w ciągu 60 sekund.
- [7.3.3/A-3-2] MUSI spełniać kryteria czasu do pierwszego rozwiązania określone w 7.3.3/C-1-2 i 7.3.3/C-1-6 w przypadku wszystkich innych żądań lokalizacji (czyli żądań, które nie są pierwszymi lub które nastąpiły po upływie ponad 4 dni). Wymaganie 7.3.3/C-1-2 jest zwykle spełnione w pojazdach bez łączności danych opartej na sieci komórkowej, za pomocą prognoz orbity GNSS obliczanej na odbiorniku lub za pomocą ostatniej znanej lokalizacji pojazdu wraz z możliwością nawigacji bez użycia przyrządów przez co najmniej 60 sekund z dokładnością do pozycji zgodną z 7.3.3/C-1-3 lub kombinacją obu tych metod.
Jeśli w implementacjach urządzeń samochodowych jest czujnik TYPE_HEADING
:
- [7.3.4/A-4-3] MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 1 Hz.
- [7.3.4/A-SR-3] MOCNO_ZALECANA częstotliwość raportowania zdarzeń: co najmniej 10 Hz.
- NALEŻY podać względem geograficznej północy.
- POWINNA być dostępna nawet wtedy, gdy pojazd stoi w bezruchu.
- Rozdzielczość powinna wynosić co najmniej 1 stopień.
Implementacje na urządzeniach samochodowych:
- [7.4.3/A-0-1] MUSI obsługiwać Bluetooth i POWINNA obsługiwać Bluetooth LE.
- [7.4.3/A-0-2] Implementacje Androida Automotive MUSZĄ obsługiwać te profile Bluetooth:
- Połączenia telefoniczne przez profil zestawu głośnomówiącego (HFP).
- Odtwarzanie multimediów za pomocą profilu dystrybucji audio (A2DP).
- sterowanie odtwarzaniem multimediów za pomocą profilu zdalnego sterowania (AVRCP);
- Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).
[7.4.3/A-SR-1] MOCNO POLECA się obsługę profilu dostępu do wiadomości (MAP).
[7.4.5/A] NALEŻY uwzględnić obsługę połączeń danych w sieci komórkowej.
[7.4.5/A] MOŻE używać stałej System API
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
w przypadku sieci, które powinny być dostępne dla aplikacji systemowych.
Kamera zewnętrzna to kamera, która rejestruje obraz z zewnętrznej części urządzenia, np. kamera cofania.
Implementacje na urządzeniach samochodowych:
- POWINNY zawierać co najmniej 1 kamerę zewnętrzną.
Jeśli implementacje urządzeń samochodowych obejmują kamerę widoku zewnętrznego, w przypadku takiej kamery:
- [7.5/A-1-1] Kamera zewnętrzna NIE MOŻE być dostępna za pomocą interfejsów API aparatu Androida, chyba że spełnia podstawowe wymagania dotyczące aparatu.
[7.5/A-SR-1] MOCNO zalecamy, aby nie obracać ani nie odwracać poziomo podglądu kamery.
[7.5/A-SR-2] MOCNO zalecamy, aby rozdzielczość wynosiła co najmniej 1,3 Mpix.
NALEŻY użyć sprzętu z ostrzością stałą lub z rozszerzoną głębią ostrości (EDOF).
MOŻE mieć wdrożony w sterowniku aparatu sprzętowy lub programowy autofokus.
Jeśli implementacje urządzeń samochodowych obejmują co najmniej 1 kamerę zewnętrzną i wczytują usługę systemu widoku zewnętrznego (EVS), to w przypadku takiej kamery:
- [7.5/A-2-1] NIE MOŻNA obracać ani odbijać poziomo podglądu kamery.
Implementacje na urządzeniach samochodowych:
- MOŻE zawierać co najmniej 1 kamerę, która jest dostępna dla aplikacji innych firm.
Jeśli w implementacjach urządzeń samochodowych jest co najmniej 1 kamera i jest ona dostępna dla aplikacji innych firm, urządzenia te:
- [7.5/A-3-1] MUST report the feature flag
android.hardware.camera.any
. - [7.5/A-3-2] NIE NALEŻY deklarować kamery jako kamery systemowej.
- MOŻE obsługiwać kamery zewnętrzne opisane w sekcji 7.5.3.
- MOŻE zawierać funkcje (takie jak autofokus) dostępne dla tylnych aparatów zgodnie z opisem w sekcji 7.5.1.
Implementacje na urządzeniach samochodowych:
[7.6.1/A-0-1] Musi być dostępne co najmniej 4 GB pamięci nieulotnej na potrzeby danych prywatnych aplikacji (czyli na partycji „/data”).
[7.6.1/A] NALEŻY sformatować partycję danych, aby zapewnić lepszą wydajność i trwałość pamięci flash, na przykład za pomocą systemu plików
f2fs
.
Jeśli implementacje urządzeń samochodowych udostępniają zewnętrzne miejsce na dane za pomocą części wewnętrznej pamięci niewymiennej, muszą:
- [7.6.1/A-SR-1] ZALECAMY, aby zredukować obciążenie operacjami wejścia/wyjścia podczas operacji wykonywanych na zewnętrznym urządzeniu pamięci masowej, na przykład za pomocą
SDCardFS
.
Jeśli implementacje urządzeń samochodowych są 64-bitowe:
[7.6.1/A-2-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 816 MB, jeśli używana jest dowolna z tych gęstości:
- 280 dpi lub mniej na małych/normalnych ekranach
- ldpi lub niższą na bardzo dużych ekranach.
- mdpi lub niższym na dużych ekranach.
[7.6.1/A-2-2] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 944 MB, jeśli używana jest dowolna z tych gęstości:
- xhdpi lub wyższa na małych/normalnych ekranach
- hdpi lub wyższa na dużych ekranach.
- mdpi lub wyższa na bardzo dużych ekranach.
[7.6.1/A-2-3] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1280 MB, jeśli używana jest dowolna z tych gęstości:
- 400 dpi lub więcej na małych/normalnych ekranach
- xhdpi lub wyższa na dużych ekranach
- tvdpi lub wyższa na bardzo dużych ekranach.
[7.6.1/A-2-4] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1824 MB, jeśli używana jest dowolna z tych gęstości:
- 560 dpi lub więcej na małych/normalnych ekranach
- 400 dpi lub więcej na dużych ekranach.
- xhdpi lub wyższa na bardzo dużych ekranach.
Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do przestrzeni pamięci udostępnionej dodatkowo do pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro w implementacjach urządzenia.
Implementacje na urządzeniach samochodowych:
- [7.7.1/A] NALEŻY uwzględnić port USB obsługujący tryb peryferyjny.
Implementacje na urządzeniach samochodowych:
- [7.8.1/A-0-1] MUSI zawierać mikrofon.
Implementacje na urządzeniach samochodowych:
- [7.8.2/A-0-1] MUSI mieć wyjście audio i deklarować
android.hardware.audio.output
.
2.5.2. Multimedia
Implementacje urządzeń samochodowych MUSZĄ obsługiwać te formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:
- [5.1/A-0-1] Profil MPEG-4 AAC (AAC LC)
- [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/A-0-3] AAC ELD (ulepszona jakość dźwięku AAC z minimalnym opóźnieniem)
Implementacje urządzeń samochodowych MUSZĄ obsługiwać te formaty kodowania filmów i udostępniać je aplikacjom innych firm:
Implementacje urządzeń samochodowych MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:
W przypadku implementacji urządzeń samochodowych MOCNO zalecamy obsługę tych formatów dekodowania wideo:
- [5.3/A-SR-1] H.265 HEVC
2.5.3. Oprogramowanie
Implementacje na urządzeniach samochodowych:
[3/A-0-1] NALEŻY zadeklarować funkcję
android.hardware.type.automotive
.[3/A-0-2] MUSI obsługiwać uiMode =
UI_MODE_TYPE_CAR
.[3/A-0-3] MUSI obsługiwać wszystkie publiczne interfejsy API w przestrzeni nazw
android.car.*
.
Jeśli implementacje urządzeń samochodowych udostępniają firmowy interfejs API za pomocą interfejsu android.car.CarPropertyManager
w ramach android.car.VehiclePropertyIds
, to:
- [3/A-1-1] Nie wolno przypisywać specjalnych uprawnień do korzystania z tych usług przez aplikację systemową ani uniemożliwiać korzystania z nich aplikacjom innych firm.
- [3/A-1-2] NIE POWINNA powielać właściwości pojazdu, która istnieje już w pakiecie SDK.
Implementacje na urządzeniach samochodowych:
[3.2.1/A-0-1] MUSI obsługiwać i egzekwować wszystkie stałe uprawnienia zgodnie z dokumentacją na stronie referencyjnej dotyczącą uprawnień w przypadku pojazdów autonomicznych.
[3.2.3.1/A-0-1] W przypadku wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez te intencje aplikacji (tutaj) MUSISZ wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji.
[3.4.1/A-0-1] Musisz wdrożyć pełną implementację interfejsu API
android.webkit.Webview
.[3.8.3/A-0-1] MUSI wyświetlać powiadomienia, które korzystają z interfejsu API
Notification.CarExtender
, gdy zostaną przesłane przez aplikacje innych firm.[3.8.4/A-SR-1] W przypadku implementacji asystenta na urządzeniu zaleca się obsługę działania Assist.
Jeśli wdrożenia urządzeń samochodowych obejmują przycisk „push-to-talk”, muszą:
- [3.8.4/A-1-1] Należy użyć krótkiego naciśnięcia przycisku „push-to-talk” jako wyznaczonej interakcji do uruchomienia aplikacji asystenta wybranej przez użytkownika, czyli aplikacji, która implementuje
VoiceInteractionService
.
Implementacje na urządzeniach samochodowych:
- [3.8.3.1/A-0-1] MUSI prawidłowo renderować zasoby zgodnie z opisem w dokumentacji
Notifications on Automotive OS
pakietu SDK. - [3.8.3.1/A-0-2] MUST display
PLAY and MUTE for notification actions in the place of those provided through
Notification.Builder.addAction()
- [3.8.3.1/A] NALEŻY ograniczyć stosowanie zaawansowanych zadań administracyjnych, takich jak ustawienia powiadomień na kanałach. MOŻE używać interfejsu użytkownika w poszczególnych aplikacjach, aby ograniczyć liczbę elementów sterujących.
Jeśli implementacje urządzeń samochodowych obsługują właściwości HAL użytkownika, to:
- [3.9.3/A-1-1] IMPLEMENTUJ WSZYSTKIE właściwości cyklu życia użytkownika.
INITIAL_USER_INFO
,SWITCH_USER
,CREATE_USER
,REMOVE_USER
.
Implementacje na urządzeniach samochodowych:
- [3.14/A-0-1] MUSI zawierać interfejs użytkownika, który obsługuje aplikacje innych firm korzystające z interfejsów API mediów zgodnie z opisem w sekcji 3.14.
- [3.14/A-0-2] Aplikacja MUSI umożliwiać użytkownikowi bezpieczne korzystanie z aplikacji multimedialnych podczas jazdy.
- [3.14/A-0-3] Musi obsługiwać ukryte działanie intencjonalne
CAR_INTENT_ACTION_MEDIA_TEMPLATE
z dodatkiemCAR_EXTRA_MEDIA_PACKAGE
. - [3.14/A-0-4] Musisz umożliwić przejście do aktywności preferencyjnej aplikacji multimedialnej, ale tylko wtedy, gdy nie obowiązują ograniczenia dotyczące interfejsu samochodowego.
- [3.14/A-0-5] MUSI wyświetlać komunikaty o błędach ustawione przez aplikacje multimedialne i MUSI obsługiwać opcjonalne dodatki
ERROR_RESOLUTION_ACTION_LABEL
iERROR_RESOLUTION_ACTION_INTENT
. - [3.14/A-0-6] Musisz obsługiwać wyszukiwanie w aplikacji w przypadku aplikacji, które obsługują wyszukiwanie.
- [3.14/A-0-7] MUSI przestrzegać definicji
CONTENT_STYLE_BROWSABLE_HINT
iCONTENT_STYLE_PLAYABLE_HINT
podczas wyświetlania hierarchii MediaBrowser.
Jeśli implementacje urządzeń samochodowych zawierają domyślną aplikację uruchamiającą, muszą:
- [3.14/A-1-1] MUSI zawierać usługi multimedialne i otwierać je za pomocą
CAR_INTENT_ACTION_MEDIA_TEMPLATE
intencji.
Implementacje na urządzeniach samochodowych:
- [3.8/A] MOŻE ograniczyć żądania aplikacji dotyczące włączenia trybu pełnoekranowego zgodnie z opisem w
immersive documentation
. - [3.8/A] PASEK STANÓW I PASEK NAWIGACYJNY MOGĄ BYĆ ZAWSZE WIDOCZNE.
- [3.8/A] MOŻE ograniczać prośby aplikacji o zmianę kolorów elementów interfejsu systemu, aby zapewnić, że elementy te będą zawsze wyraźnie widoczne.
2.5.4. Wydajność i moc
Implementacje na urządzeniach samochodowych:
- [8.2/A-0-1] NALEŻY zgłaszać liczbę bajtów odczytanych i zapisanych do pamięci nieulotnej dla każdego identyfikatora UID procesu, aby statystyki były dostępne dla deweloperów za pomocą interfejsu System API
android.car.storagemonitoring.CarStorageMonitoringManager
. Projekt Android Open Source 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] Powinien znajdować się w trybie garażu przez co najmniej 15 minut po każdej jeździe, chyba że:
- Bateria jest rozładowana.
- Nie zaplanowano żadnych zadań nieczynnych.
- Kierowca wyłącza tryb garażu.
- [8.4/A-0-1] MUSISZ podać profil energetyczny dla każdego komponentu, który definiuje wartość bieżącego poboru energii dla każdego komponentu sprzętowego oraz przybliżony pobór energii z baterii spowodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
- [8.4/A-0-2] Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
- [8.4/A-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia wymagania dzięki implementacji modułu jądra
uid_cputime
. - [8.4/A] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.
- [8.4/A-0-4] DEWELOPER MUSI udostępnić tę wartość za pomocą polecenia
adb shell dumpsys batterystats
w powłoce dla dewelopera aplikacji.
2.5.5. Model zabezpieczeń
Jeśli implementacje urządzeń Automotive obsługują wielu użytkowników, muszą:
- [9.5/A-1-1] NIE NALEŻY zezwalać użytkownikom na interakcję z użytkownikiem bezprzewodowego systemu ani na przełączanie się na niego, z wyjątkiem zarządzania urządzeniami.
- [9.5/A-1-2] Przed
BOOT_COMPLETED
musisz przejść na konto użytkownika dodatkowego. - [9.5/A-1-3] MUSI obsługiwać możliwość utworzenia użytkownika-gościa nawet wtedy, gdy osiągnięto maksymalną liczbę użytkowników na urządzeniu.
Jeśli implementacje urządzeń samochodowych deklarują android.hardware.camera.any
, to:
- [9.8.2/A-2-1] MUSI wyświetlać wskaźnik kamery, gdy aplikacja uzyskuje dostęp do danych z kamery na żywo, ale nie wtedy, gdy dostęp do kamery mają tylko aplikacje, które mają role wymienione w sekcji 9.1 Uprawnienia z identyfikatorem CDD [C-3-X].
- [9.8.2/A-2-2] Nie wolno ukrywać wskaźnika kamery w przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub bezpośrednią interakcję z użytkownikiem.
Implementacje na urządzeniach samochodowych:
- [9.11/A-0-1] Musisz utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
- [9.11/A-0-2] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać obsługiwane przez system Keystore Androida algorytmy w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i powyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest też inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
- [9.11/A-0-3] NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonywania i dopiero po pomyślnym uwierzytelnieniu zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w otoczeniu odizolowanego wykonania. Projekt źródłowy Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymogu.
- [9.11/A-0-4] MUSI obsługiwać atestację klucza, w której klucz podpisywania atestacji jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania muszą być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻE być używany inny klucz.
- [9/A-0-1] NALEŻY zadeklarować funkcję „android.hardware.security.model.compatible”.
Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi ona spełniać wymagań dotyczących posiadania magazynu kluczy obsługiwanego przez odizolowane środowisko wykonywania i obsługiwania uwierzytelniania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint
, która wymaga magazynu kluczy obsługiwanego przez odizolowane środowisko wykonywania.
Implementacje na urządzeniach samochodowych:
- [9.14/A-0-1] MUST gatekeep messages from Android framework vehicle subsystems, e.g., allowlisting permitted message types and message sources.
- [9.14/A-0-2] MUSI chronić przed atakami typu DoS z ramy Androida lub aplikacji innych firm. Zapobiega to przeciążaniu sieci pojazdu przez złośliwe oprogramowanie, co może prowadzić do nieprawidłowego działania podsystemów pojazdu.
2.5.6. Zgodność narzędzi dla programistów i opcji
Implementacje na urządzeniach samochodowych:
- Perfetto
- [6.1/A-0-1] NALEŻY udostępnić użytkownikowi powłoki binarną
/system/bin/perfetto
, której cmdline jest zgodna z dokumentacją perfetto. - [6.1/A-0-2] Binarny plik perfetto MUSI akceptować jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/A-0-3] Plik binarne perfetto MUSI zapisywać jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
- [6.1/A-0-4] Musisz udostępnić za pomocą binarnego pliku wykonywalnego perfetto co najmniej źródła danych opisane w dokumentacji perfetto.
- [6.1/A-0-1] NALEŻY udostępnić użytkownikowi powłoki binarną
2.6. Wymagania dotyczące tabletów
Tablet z Androidem to urządzenie z Androidem, które zazwyczaj spełnia wszystkie te kryteria:
- Używany do trzymania w obu rękach.
- Nie ma konfiguracji składanej ani składanej z klapką.
- Implementacje klawiatury fizycznej używane z urządzeniem łączą się za pomocą standardowego połączenia (np. USB, Bluetooth).
- Ma źródło zasilania, które zapewnia mobilność, np. baterię.
- ma ekran o rozmiarze większym niż 7 cali i mniejszym niż 18 cali (mierzone po przekątnej).
Implementacje na tabletach mają podobne wymagania jak implementacje na urządzeniach przenośnych. Wyjątki są oznaczone gwiazdką * w tej sekcji i wymienione w niej w celu ułatwienia nawigacji.
2.6.1. Sprzęt
Żyroskop
Jeśli implementacje urządzeń typu tablet obejmują 3-osiowy żyroskop, muszą:
- [7.3.4/Tab-1-1] MUSI być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.
Minimalna pamięć i miejsce na dane (sekcja 7.6.1)
Gęstości ekranu wymienione w wymaganiach dotyczących urządzeń przenośnych (małe/normalne) nie mają zastosowania do tabletów.
Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)
Jeśli implementacje tabletów obejmują port USB obsługujący tryb peryferyjny, muszą:
- [7.7.1/Tab] MOŻE implementować interfejs API AOA (Android Open Accessory).
Tryb rzeczywistości wirtualnej (sekcja 7.9.1)
Wysoka wydajność w wirtualnej rzeczywistości (sekcja 7.9.2)
Wymagania dotyczące rzeczywistości wirtualnej nie mają zastosowania do tabletów.
2.6.2. Model zabezpieczeń
Klucze i dane uwierzytelniające (sekcja 9.11)
Patrz sekcja [9.11].
Jeśli implementacje urządzeń typu tablet obsługują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony
, nie mogą:
- [9.5/T-1-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, z możliwością zarządzania bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.
Jeśli implementacje urządzeń z systemem Android obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony
, muszą:
- [9.5/T-2-1] NIE MUSI obsługiwać profili ograniczonych, ale MUSI być zgodny z implementacją funkcji kontroli AOSP, aby umożliwić /zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.
2.6.2. Oprogramowanie
- [3.2.3.1/Tab-0-1] Musisz wstępnie wczytać co najmniej jedną aplikację lub komponent usługi z obsługą intencji dla wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez te intencje aplikacji wymienione tutaj.
3. Oprogramowanie
3.1. Zgodność z zarządzanym interfejsem API
Zarządzane środowisko wykonywania kodu bajtowego Dalvik jest głównym narzędziem do uruchamiania aplikacji na Androida. Interfejs programowania aplikacji (API) Androida to zbiór interfejsów platformy Androida udostępnionych aplikacjom działającym w środowisku zarządzanego środowiska wykonawczego.
Implementacje na urządzeniu:
[C-0-1] Musisz udostępnić kompletne implementacje, w tym wszystkie opisane zachowania, dowolnego sdokumentowanego interfejsu API udostępnionego przez pakiet SDK Androida lub dowolnego interfejsu API o oznaczonym znacznikiem „@SystemApi” kodzie źródłowym Androida.
[C-0-2] MUSI obsługiwać/zachowywać wszystkie klasy, metody i powiązane elementy oznaczone adnotacją TestApi (@TestApi).
[C-0-3] Nie wolno pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów ani podpisów interfejsów API, odbiegać od udokumentowanego zachowania ani dołączać operacji pustych, z wyjątkiem przypadków, w których jest to wyraźnie dozwolone w tej definicji zgodności.
[C-0-4] Musisz zachować interfejsy API i działać w rozsądny sposób, nawet jeśli pominiesz niektóre funkcje sprzętowe, dla których Android zawiera interfejsy API. Więcej informacji o wymaganiach w tym scenariuszu znajdziesz w sekcji 7.
[C-0-5] NIE wolno zezwalać aplikacjom innych firm na korzystanie z interfejsów spoza pakietu SDK, które są zdefiniowane jako metody i pola w pakietach języka Java, znajdujące się w ścieżce klas Boot w AOSP i nie należące do publicznego pakietu SDK. Dotyczy to interfejsów API otagowanych adnotacją
@hide
, ale nie@SystemAPI
, zgodnie z opisem w dokumentacji pakietu SDK oraz członków klas prywatnych i prywatnych w ramach pakietu.[C-0-6] MUST ship with each and every non-SDK interface on the same restricted lists as provided via the provisional and denylist flags in
prebuilts/runtime/appcompat/hiddenapi-flags.csv
path for the appropriate API level branch in the AOSP.[C-0-7] Musisz obsługiwać mechanizm dynamicznych aktualizacji zaszyfrowanej konfiguracji, aby usuwać interfejsy inne niż SDK z listy ograniczeń. W tym celu należy umieścić zaszyfrowaną konfigurację w dowolnym pliku APK, używając istniejących kluczy publicznych obecnych w AOSP.
Jednak:
- W MAJA, jeśli ukryty interfejs API jest niedostępny lub jest inaczej zaimplementowany na urządzeniu, przenieś ukryty interfejs API na listę zablokowanych lub usuń go ze wszystkich list ograniczonych.
- W MAJA, jeśli ukryty interfejs API nie istnieje już w AOSP, dodaj go do dowolnej z list ograniczonych.
3.1.1. Rozszerzenia Androida
Android obsługuje rozszerzanie interfejsu zarządzanego interfejsu API danego poziomu API przez aktualizowanie wersji rozszerzenia dla tego poziomu API. Jeśli na danym poziomie interfejsu API są dostępne rozszerzenia, interfejs API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
zwraca wersję rozszerzenia podanego parametru apiLevel
.
Implementacje na urządzeniach z Androidem:
[C-0-1] NALEŻY wstępnie załadować implementację AOSP zarówno biblioteki współdzielonej
ExtShared
, jak i usługExtServices
w wersjach nowszych lub równych minimalnym wersjom dozwolonym dla danego poziomu interfejsu API. Na przykład implementacje urządzeń z Androidem 7.0 z poziomem interfejsu API 24 MUSZĄ zawierać co najmniej wersję 1.[C-0-2] MUSI zwracać tylko prawidłowy numer wersji rozszerzenia zdefiniowany przez AOSP.
[C-0-3] Musi obsługiwać wszystkie interfejsy API zdefiniowane przez wersje rozszerzenia zwracane przez
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
w taki sam sposób, w jaki obsługiwane są inne zarządzane interfejsy API zgodnie z wymaganiami podanymi w sekcji 3.1.
3.1.2. Biblioteka Androida
Z powodu wycofania klienta HTTP Apache implementacje urządzeń:
- [C-0-1] NIE WYMAGAMY umieszczania biblioteki
org.apache.http.legacy
w ścieżce ładowania. - [C-0-2] NALEŻY dodać bibliotekę
org.apache.http.legacy
do classpath aplikacji tylko wtedy, gdy aplikacja spełnia co najmniej 1 z tych warunków:- Kieruje na interfejs API na poziomie 28 lub niższym.
- W pliku manifestu deklaruje, że potrzebuje biblioteki, ustawiając atrybut
android:name
w elementach<uses-library>
naorg.apache.http.legacy
.
Implementacja AOSP spełnia te wymagania.
3.2. Zgodność z interfejsem API w wersji próbnej
Oprócz zarządzanych interfejsów API z sekcji 3.1 Android zawiera też „miękki” interfejs API działający tylko w czasie wykonywania. Dotyczy to takich elementów aplikacji na Androida jak intencje, uprawnienia i inne podobne aspekty, których nie można wymusić w czasie kompilacji aplikacji.
3.2.1. Uprawnienia
- [C-0-1] Implementatorzy urządzeń MUSZĄ obsługiwać i stosować wszystkie stałe dotyczące uprawnień zgodnie z dokumentacją na stronie referencyjnej dotyczącej uprawnień. Pamiętaj, że sekcja 9 zawiera dodatkowe wymagania dotyczące modelu zabezpieczeń Androida.
3.2.2. Parametry tworzenia
Interfejsy API Androida zawierają wiele stałych wartości w klasie android.os.Build, które służą do opisywania bieżącego urządzenia.
- [C-0-1] Aby zapewnić spójne, sensowne wartości we wszystkich implementacjach na urządzeniach, w tabeli poniżej podano dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi implementacje na urządzeniach MUSZĄ być zgodne.
Parametr | Szczegóły |
---|---|
VERSION.RELEASE | Wersja aktualnie uruchomionego systemu Android w czytelnym dla człowieka formacie. To pole MUSI zawierać jeden z ciągów określonych w dozwolonych ciągach wersji na Androida 13. |
WERSJ.SDK | Wersja aktualnie wykonywanego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 13 to pole MUSI mieć wartość całkowitą 13_INT. |
VERSION.SDK_INT | Wersja aktualnie wykonywanego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 13 to pole MUSI mieć wartość całkowitą 13_INT. |
VERSION.INCREMENTAL | Wartość wybrana przez implementatora urządzenia, która określa wersję bieżącego systemu Android w czytelnym dla człowieka formacie. Tej wartości NIE MOŻNA używać ponownie w przypadku różnych wersji udostępnionych użytkownikom. Typowe zastosowanie tego pola to wskazanie, który numer wersji lub identyfikator zmiany kontroli źródłowej posłużył do wygenerowania wersji. Wartość tego pola MUSI być możliwa do zakodowania jako drukowalny 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^[^ :\/~]+$”. |
PLANSZOWE | Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretny sprzęt wewnętrzny używany przez urządzenie w czytelnym dla człowieka formacie. Możliwe zastosowanie tego pola to wskazanie konkretnej wersji płyty głównej zasilającej urządzenie. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i MUSI być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”. |
MARKA | Wartość odzwierciedlająca nazwę marki powiązaną z urządzeniem, jaką znają użytkownicy. MUSI być w formacie zrozumiałym dla człowieka i POWINIEN wskazywać producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. |
SUPPORTED_ABIS | Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność natywnego interfejsu API. |
SUPPORTED_32_BIT_ABIS | Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność natywnego interfejsu API. |
SUPPORTED_64_BIT_ABIS | Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API. |
CPU_ABI | Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność natywnego interfejsu API. |
CPU_ABI2 | Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API. |
URZĄDZENIE | Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową identyfikującą konfigurację funkcji sprzętowych i przeznaczenie przemysłowe urządzenia. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Nazwa urządzenia NIE MOŻE się zmieniać w trakcie trwania cyklu życia produktu. |
FINGERPRINT | Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być w rozsądnym stopniu czytelny dla człowieka. Musi on być zgodny z tym szablonem:
$(BRAND)/$(PRODUCT)/ Przykład: acme/myproduct/ Odcisk palca NIE MOŻE zawierać znaków odstępów. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII. |
SPRZĘT | Nazwa sprzętu (z wiersza poleceń jądra lub katalogu /proc). Powinna być w rozsądnym stopniu czytelna dla człowieka. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. |
HOST | Ciąg tekstowy jednoznacznie identyfikujący hosta, na którym została utworzona kompilacja, w zrozumiałym dla człowieka formacie. Nie ma wymagań dotyczących formatu tego pola, z tym wyjątkiem, że NIE może być ono puste ani nie może zawierać pustego ciągu znaków („”). |
ID | Identyfikator wybrany przez implementatora urządzenia na potrzeby odniesienia do konkretnej wersji w czytelnym dla człowieka formacie. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINNA zawierać wartość wystarczająco znaczącą, aby użytkownicy mogli odróżnić różne wersje oprogramowania. Wartość tego pola MUSI być możliwa do zakodowania w 7-bitowym formacie ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”. |
PRODUCENT | Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani równe pustej sekwencji znaków. To pole NIE MOŻE się zmieniać w trakcie trwania produktu. |
SOC_MANUFACTURER | Nazwa handlowa producenta głównego układu na chipie (SOC) używanego w produkcie. Urządzenia z tym samym producentem SOC powinny używać tej samej wartości stałej. Aby uzyskać prawidłową stałą, skontaktuj się z producentem SOC. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII, MUSI być zgodna z wyrażeniem regularnym „^([0-9A-Za-z ]+)”, NIE MOŻE się zaczynać ani kończyć białą przestrzenią i NIE MOŻE być równa „unknown”. To pole NIE MOŻE się zmieniać w trakcie całego okresu istnienia produktu. |
SOC_MODEL | Nazwa modelu głównego układu systemowego (SOC) używanego w produkcie. Urządzenia z tym samym modelem SOC powinny używać tej samej stałej wartości. Aby uzyskać prawidłową stałą, skontaktuj się z producentem SOC. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^([0-9A-Za-z ._/+-]+)$”. Nie może się zaczynać ani kończyć białą przestrzenią i nie może być równa „unknown”. To pole NIE MOŻE się zmieniać w trakcie trwania produktu. |
MODEL | Wartość wybrana przez implementatora urządzenia zawierająca nazwę urządzenia znaną użytkownikowi. Powinna to być ta sama nazwa, pod którą urządzenie jest sprzedawane użytkownikom końcowym. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE może być ono puste ani nie może zawierać pustego ciągu znaków (""). To pole NIE może się zmieniać w trakcie trwania produktu. |
USŁUGA | Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową konkretnego produktu (SKU), która MUSI być unikalna w ramach tej samej marki. Musi być zrozumiały dla człowieka, ale niekoniecznie musi być widoczny dla użytkowników. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i MUSI być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”. Nazwa produktu NIE MOŻE się zmieniać w trakcie jego cyklu życia. |
ODM_SKU | Opcjonalna wartość wybrana przez implementatora urządzenia, która zawiera kod SKU (Stock Keeping Unit) używany do śledzenia określonych konfiguracji urządzenia, np. urządzeń peryferyjnych dołączonych do urządzenia w momencie sprzedaży.
Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym ^([0-9A-Za-z.,_-]+)$ . |
SERIAL | Musi zwracać wartość „UNKNOWN” (nieznany). |
TAGI | Lista tagów wybranych przez implementatora urządzenia, oddzielona przecinkami, która dodatkowo rozróżnia kompilację. Tagi MUSZĄ być kodowane jako 7-bitowy kod ASCII, MUSZĄ być zgodne z wyrażeniem regularnym „^[a-zA-Z0-9._-]+” i MUSZĄ zawierać jedną z wartości odpowiadających 3 typowym konfiguracjom podpisywania na platformie Android: release-keys, dev-keys i test-keys. |
CZAS | Wartość reprezentująca sygnaturę czasową utworzenia kompilacji. |
TYP | Wartość wybrana przez implementatora urządzenia określająca konfigurację kompilacji w czasie wykonywania. To pole MUSI zawierać jedną z wartości odpowiadającą 3 typowym konfiguracjom środowiska uruchomieniowego Androida: user, userdebug lub eng. |
UŻYTKOWNIK | Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował kompilację. Nie ma wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE może być ono puste ani zawierać pustego ciągu znaków („”). |
SECURITY_PATCH | Wartość wskazująca poziom aktualizacji zabezpieczeń danej kompilacji. Musi ona wskazywać, że kompilacja nie jest w żaden sposób narażona na żadne z opisanych problemów w specjalnym Biuletynie bezpieczeństwa Androida. Musi mieć format [RRRR-MM-DD], który odpowiada zdefiniowanemu ciągowi znaków w publicznym biuletynie o zabezpieczeniach Androida lub w poradniku Androida na temat zabezpieczeń, np. „2015-11-01”. |
BASE_OS | Wartość reprezentująca parametr FINGERPRINT kompilacji, która jest identyczna z tą kompilacją, z wyjątkiem poprawek dostarczonych w powiadomieniu o bezpieczeństwie Androida. Musi on zwracać prawidłową wartość. Jeśli taka wersja nie istnieje, należy zwrócić pusty ciąg znaków („”). |
BOOTLOADER | Wartość wybrana przez implementatora urządzenia, która identyfikuje wersję wewnętrznego bootloadera używaną na urządzeniu w czytelnym dla człowieka formacie. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”. |
getRadioVersion() | MUSI (być lub zwracać) wartość wybraną przez implementatora urządzenia identyfikującą konkretną wersję wewnętrznego radia/modemu używaną na urządzeniu w czytelnym dla człowieka formacie. Jeśli urządzenie nie ma żadnego wewnętrznego radia/modemu, musi zwrócić NULL. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-,]+$”. |
getSerial() | Musisz podać numer seryjny sprzętu, który musi być dostępny i unikalny w przypadku urządzeń z tym samym MODELEM i PRODUCENTEM. Wartość w tym polu MUSI być możliwa do zakodowania w 7-bitowym formacie ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9]+$”. |
3.2.3. Zgodność z intencją
3.2.3.1. Typowe przypadki użycia aplikacji
Intencje Androida umożliwiają komponentom aplikacji żądanie funkcji od innych komponentów Androida. Projekt upstream Androida zawiera listę aplikacji, które implementują kilka wzorów intencji do wykonywania typowych działań.
Implementacje na urządzeniu:
- [C-SR-1] MOCNO ZALECAMY wstępne załadowanie co najmniej 1 aplikacji lub komponentu usługi z obsługą intencji we wszystkich publicznych wzorach filtrów intencji zdefiniowanych przez te intencje aplikacji wymienione tutaj oraz zapewnienie realizacji, czyli spełnienie oczekiwań dewelopera w przypadku tych typowych intencji aplikacji zgodnie z opisem w pakiecie SDK.
Informacje o obowiązkowych intencjach aplikacji dla poszczególnych typów urządzeń znajdziesz w sekcji 2.
3.2.3.2. Rozwiązywanie intencji
[C-0-1] Ponieważ Android jest platformą rozszerzalną, implementacje urządzeń MUSZĄ zezwalać na zastąpienie przez aplikacje innych firm każdego wzorca intencji wymienionego w sekcji 3.2.3.1 (z wyjątkiem ustawień). Implementacja open source Androida w górnym strumieniu umożliwia to domyślnie.
[C-0-2] Implementatorzy urządzeń NIE MOGĄ dołączać specjalnych uprawnień do korzystania z tych wzorów intencji przez aplikacje systemowe ani uniemożliwiać aplikacjom innych firm wiązania się z tymi wzorami i przejmowania nad nimi kontroli. Zakaz ten obejmuje m.in. wyłączenie interfejsu „Wybór”, który umożliwia użytkownikowi wybór spośród wielu aplikacji obsługujących ten sam wzór intencji.
[C-0-3] Implementacje na urządzeniach MUSZĄ zawierać interfejs użytkownika umożliwiający modyfikowanie domyślnej aktywności dla intencji.
Implementacje urządzeń MOGĄ jednak udostępniać domyślne czynności dla określonych wzorów URI (np. http://play.google.com), gdy domyślna czynność udostępnia bardziej szczegółowy atrybut URI danych. Na przykład wzór filtra intencji określający identyfikator URI danych „http://www.android.com” jest bardziej szczegółowy niż podstawowy wzór intencji przeglądarki „http://”.
Android zawiera też mechanizm, który umożliwia aplikacjom innych firm deklarowanie autorytatywnych domyślnych zachowań dotyczących łączenia aplikacji w przypadku niektórych typów intencji identyfikatora URI internetowego. Gdy takie autorytatywne deklaracje są zdefiniowane w wzorach filtrów intencji aplikacji, implementacje na urządzeniu:
- [C-0-4] NALEŻY spróbować zweryfikować wszystkie filtry intencji, wykonując czynności weryfikacyjne zdefiniowane w specyfikacji protokołu Digital Asset Links, jak to zostało zaimplementowane przez menedżera pakietów w górnym projekcie Android Open Source.
- [C-0-5] NALEŻY spróbować zweryfikować filtry intencji podczas instalacji aplikacji i ustawić wszystkie zweryfikowane filtry intencji URI jako domyślne moduły obsługi aplikacji dla ich identyfikatorów URI.
- MOŻE ustawić konkretne filtry intencji URI jako domyślne moduły obsługi aplikacji dla swoich identyfikatorów URI, jeśli zostaną one pomyślnie zweryfikowane, ale inne potencjalne filtry URI nie przejdą weryfikacji. Jeśli implementacja urządzenia wykonuje tę funkcję, MUSI udostępniać użytkownikowi odpowiednie zastąpienia w menu ustawień na podstawie wzorca URI.
- Musisz udostępnić użytkownikowi ustawienia linków do aplikacji w ustawieniach aplikacji w następujący sposób:
- [C-0-6] Użytkownik MUSI mieć możliwość globalnego zastąpienia domyślnego zachowania linków aplikacji, aby aplikacja: zawsze otwierała, zawsze pytała lub nigdy nie otwierała linków. Musi to dotyczyć wszystkich docelowych filtrów identyfikatorów URI.
- [C-0-7] Użytkownik MUSI mieć możliwość wyświetlenia listy docelowych filtrów URI.
- Implementacja urządzenia MOŻE umożliwić użytkownikowi zastąpienie określonych docelowych filtrów URI, które zostały zweryfikowane, na podstawie każdego filtra intencji.
- [C-0-8] Implementacja na urządzeniu MUSI umożliwiać użytkownikom wyświetlanie i zastępowanie konkretnych docelowych filtrów identyfikatora URI, jeśli implementacja na urządzeniu umożliwia weryfikację niektórych docelowych filtrów identyfikatora URI, podczas gdy inne mogą nie przejść weryfikacji.
3.2.3.3. Przestrzenie nazw intencji
- [C-0-1] Implementacje urządzeń NIE MOGĄ zawierać żadnych komponentów Androida, które obsługują nowe intencje lub wzorce intencji przesyłania za pomocą działania, kategorii lub innego kluczowego ciągu w przestrzeni nazw android.* lub com.android.*.
- [C-0-2] Implementatorzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub rozgłaszają wzorce intencji za pomocą elementu ACTION, CATEGORY lub innego kluczowego ciągu znaków w przestrzeni pakietu należącej do innej organizacji.
- [C-0-3] Implementatorzy urządzeń NIE MOGĄ zmieniać ani rozszerzać żadnych wzorów intencji wymienionych w sekcji 3.2.3.1.
- Implementacje na urządzeniach MOGĄ zawierać wzorce intencji, które używają skojarzeń jednoznacznie powiązanych z organizacją. Ten zakaz jest analogiczny do tego, który dotyczy zajęć z języka Java w sekcji 3.6.
3.2.3.4. Zamiary związane z transmisją
Aplikacje innych firm polegają na platformie, która wysyła określone intencje, aby powiadomić je o zmianach w środowisku sprzętowym lub programowym.
Implementacje na urządzeniu:
- [C-0-1] MUSI wysyłać publiczne intencje transmisji wymienione tutaj w odpowiedzi na odpowiednie zdarzenia systemowe zgodnie z dokumentacją pakietu SDK. Pamiętaj, że to wymaganie nie jest sprzeczne z sekcją 3.5, ponieważ ograniczenia dotyczące aplikacji działających w tle są również opisane w dokumentacji pakietu SDK. Ponadto niektóre intencje transmisji są zależne od obsługi sprzętowej. Jeśli urządzenie obsługuje niezbędny sprzęt, intencje MUSZĄ być transmitowane i działać zgodnie z dokumentacją pakietu SDK.
3.2.3.5. Warunkowe intencje aplikacji
Android zawiera ustawienia, które umożliwiają użytkownikom łatwe wybieranie domyślnych aplikacji, na przykład na ekranie głównym lub do wysyłania SMS-ów.
W odpowiednich przypadkach implementacje na urządzeniach MUSZĄ udostępniać podobny menu ustawień i być zgodne z wzorcem filtra intencji oraz metodami interfejsu API opisanymi w dokumentacji pakietu SDK, jak pokazano poniżej.
Jeśli wdrożenia urządzeń zgłaszają android.software.home_screen
, to:
- [C-1-1] MUSI obsługiwać działanie okna sterującego
android.settings.HOME_SETTINGS
, aby wyświetlić menu ustawień domyślnej aplikacji na ekranie głównym.
Jeśli implementacje urządzeń zgłaszają android.hardware.telephony.calling, to:
[C-2-1] Musisz udostępnić menu ustawień, które wywoła działanie
android.provider.Telephony.ACTION_CHANGE_DEFAULT
, aby wyświetlić okno dialogowe umożliwiające zmianę domyślnej aplikacji do obsługi SMS-ów.[C-2-2] MUSI honorować
android.telecom.action.CHANGE_DEFAULT_DIALER
intencję wyświetlenia okna dialogowego, aby umożliwić użytkownikowi zmianę domyślnej aplikacji Telefon.- W przypadku połączeń przychodzących i wychodzących należy używać interfejsu domyślnej aplikacji Telefon wybranej przez użytkownika, z wyjątkiem połączeń alarmowych, które będą korzystać z zainstalowanej fabrycznie aplikacji Telefon.
[C-2-3] MUSI obsługiwać działanie android.telecom.action.CHANGE_PHONE_ACCOUNTS, aby umożliwić użytkownikowi skonfigurowanie
ConnectionServices
powiązanego zPhoneAccounts
, a także domyślnego konta PhoneAccount, którego dostawca usług telekomunikacyjnych będzie używać do wykonywania połączeń wychodzących. Implementacja AOSP spełnia ten wymóg, ponieważ zawiera menu „Opcja kont połączeń” w menu ustawień „Połączenia”.[C-2-4] W przypadku aplikacji, która ma rolę
android.app.role.CALL_REDIRECTION
, MUSISZ zezwolić naandroid.telecom.CallRedirectionService
.[C-2-5] NALEŻY umożliwić użytkownikowi wybranie aplikacji, która ma
android.app.role.CALL_REDIRECTION
rolę.[C-2-6] Musi obsługiwać intencje android.intent.action.SENDTO i android.intent.action.VIEW oraz zapewniać aktywność umożliwiającą wysyłanie/wyświetlanie SMS-ów.
[C-SR-1] BARDZO ZALECAMY uwzględnianie intencji android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW i android.intent.action.DIAL z wstępnie załadowaną aplikacją do wybierania numerów, która może obsługiwać te intencje i zapewniać realizację zgodnie z opisem w pakiecie SDK.
Jeśli wdrożenia urządzeń zgłaszają android.hardware.nfc.hce
, to:
- [C-3-1] Musisz obsługiwać działanie intencji android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlić menu ustawień domyślnej aplikacji do płatności zbliżeniowych.
- [C-3-2] Musisz obsługiwać działanie android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT, aby wyświetlić aktywność, która otwiera okno dialogowe z prośbą o zmianę domyślnej usługi emulacji karty w przypadku określonej kategorii, zgodnie z opisem w pakiecie SDK.
Jeśli wdrożenia urządzeń zgłaszają android.hardware.nfc
, to:
- [C-4-1] Musi obsługiwać te intencje: android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED, aby wyświetlić działanie, które spełnia oczekiwania dewelopera dotyczące tych intencji zgodnie z opisem w SDK.
Jeśli wdrożenia urządzeń zgłaszają android.hardware.bluetooth
, to:
- [C-5-1] Musisz obsługiwać działanie ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ i wyświetlać aktywność systemową, aby umożliwić użytkownikowi włączenie Bluetootha.
- [C-5-2] Musi obsługiwać działanie ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ i wyświetlać aktywność systemową, która prosi o włączenie trybu wykrywalności.
Jeśli implementacje urządzeń obsługują funkcję DND, to:
- [C-6-1] NALEŻY zaimplementować aktywność, która odpowiada na intencję
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
. W przypadku implementacji z UI_MODE_TYPE_NORMAL musi to być aktywność, w której użytkownik może zezwolić lub odmówić aplikacji dostępu do konfiguracji zasad Nie przeszkadzać.
Jeśli implementacje urządzeń umożliwiają użytkownikom korzystanie z metod wprowadzania danych innych firm na urządzeniu, użytkownicy:
- [C-7-1] Musisz udostępnić użytkownikom mechanizm umożliwiający dodawanie i konfigurowanie metod wprowadzania danych innych firm w odpowiedzi na intencję
android.settings.INPUT_METHOD_SETTINGS
.
Jeśli implementacje urządzeń obsługują usługi ułatwień dostępu innych firm, muszą:
- [C-8-1] MUSI uwzględniać intencję
android.settings.ACCESSIBILITY_SETTINGS
zapewniania użytkownikowi mechanizmu umożliwiającego włączenie i wyłączenie usług ułatwień dostępu innych firm oraz wstępnie załadowanych usług ułatwień dostępu.
Jeśli implementacje urządzeń obejmują obsługę funkcji Wi-Fi Easy Connect i udostępniają ją aplikacjom innych firm, muszą:
- [C-9-1] MUSISZ zaimplementować interfejsy API poleceń Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI zgodnie z opisem w dokumentacji pakietu SDK.
Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych, muszą:
- [C-10-1] W ustawieniach musisz udostępnić interfejs użytkownika, który obsługuje działanie
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
, umożliwiając użytkownikom dodawanie aplikacji do listy dozwolonych lub usuwanie ich z tej listy.
Jeśli implementacje na urządzeniach nie zapewniają trybu oszczędzania danych, nie spełniają one tych wymagań:
- [C-11-1] Musisz mieć aktywność, która obsługuje działanie
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
, ale MOŻESZ zaimplementować je jako nieaktywne.
Jeśli implementacje urządzeń deklarują obsługę kamery za pomocą interfejsu android.hardware.camera.any
, mogą:
- [C-12-3] MUSI obsługiwać i MUSI zezwalać tylko wstępnie zainstalowanym aplikacjom na Androida na obsługę tych intencji:
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
iMediaStore.ACTION_VIDEO_CAPTURE
, zgodnie z opisem w dokumentacji pakietu SDK.
Jeśli wdrożenia urządzeń zgłaszają android.software.device_admin
, to:
[C-13-1] MUSI uwzględniać intencję
android.app.action.ADD_DEVICE_ADMIN
, aby wywołać interfejs użytkownika w celu dodania administratora urządzenia do systemu (lub umożliwienia odrzucenia tej opcji).[C-13-2] MUSI obsługiwać intencje android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION oraz mieć aktywność, która zapewnia realizację tych intencji zgodnie z opisem w SDK tutaj.
Jeśli implementacje urządzeń deklarują flagę funkcji android.software.autofill
, muszą:
- [C-14-1] MUSISZ w pełni zaimplementować interfejsy API
AutofillService
iAutofillManager
oraz obsługiwać działanie intencji android.settings.REQUEST_SET_AUTOFILL_SERVICE, aby wyświetlić domyślne menu ustawień aplikacji umożliwiające włączenie i wyłączenie autouzupełniania oraz zmianę domyślnej usługi autouzupełniania dla użytkownika.
Jeśli implementacja na urządzeniu obejmuje wstępnie zainstalowaną aplikację lub jeśli chcesz zezwolić aplikacjom innych firm na dostęp do statystyk użytkowania, musisz:
- [C-SR-2] W przypadku aplikacji, które deklarują uprawnienie
android.permission.PACKAGE_USAGE_STATS
, ZALECAMY udostępnienie użytkownikowi mechanizmu przyznawania lub odmowy przyznania dostępu do statystyk użytkowania w odpowiedzi na działanie android.settings.ACTION_USAGE_ACCESS_SETTINGS.
Jeśli implementacje na urządzeniach mają uniemożliwiać dostęp do statystyk dotyczących użytkowania wszystkim aplikacjom, w tym wstępnie zainstalowanym, należy:
- [C-15-1] Musisz nadal mieć aktywność, która obsługuje wzór intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale musisz zaimplementować go jako no-op, czyli tak, aby miał on działanie równoważne z tym, gdy użytkownik odmówi dostępu.
Jeśli implementacje na urządzeniach wyświetlają linki do czynności określonych przez AutofillService_passwordsActivity w Ustawieniach lub linki do haseł użytkownika za pomocą podobnego mechanizmu, muszą:
[C-16-1] Musi wyświetlać takie linki w przypadku wszystkich zainstalowanych usług autouzupełniania.
[C-17-1] [Przeniesiono do wersji 2.2.3]
Jeśli implementacje na urządzeniu obsługują interfejs VoiceInteractionService
i mają zainstalowane więcej niż 1 aplikację korzystającą z tego interfejsu API, to:
- [C-18-1] MUSI obsługiwać działanie
android.settings.ACTION_VOICE_INPUT_SETTINGS
polegające na wyświetlaniu domyślnego menu ustawień aplikacji do wprowadzania i obsługi głosowej.
Jeśli implementacje na urządzeniach zgłaszają funkcję android.hardware.audio.output
, to:
- [C-SR-3] MOCNO POLECAMY uwzględnienie intencji android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA i android.speech.tts.engine.GET_SAMPLE_TEXT, które mają działanie zapewniające realizację tych intencji zgodnie z opisem w SDK tutaj.
Android obsługuje interaktywne wygaszacze ekranu, które wcześniej nazywano „Dreams”. Wygaszacze ekranu umożliwiają użytkownikom interakcję z aplikacjami, gdy urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji dokującej. Implementacje na urządzeniu:
- POWINIEN zawierać obsługę wygaszaczy ekranu i opcję ustawień, która umożliwia użytkownikom skonfigurowanie wygaszaczy ekranu w odpowiedzi na intencję
android.settings.DREAM_SETTINGS
.
3.2.4. Aktywności na dodatkowym ekranie lub na wielu ekranach
Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych czynności na Androidzie na więcej niż 1 ekranie, muszą:
- [C-1-1] NALEŻY ustawić flagę funkcji
android.software.activities_on_secondary_displays
. - [C-1-2] NALEŻY zagwarantować zgodność interfejsu API z działaniem wykonywanym na ekranie głównym.
- [C-1-3] Nowa aktywność MUSI uruchamiać się na tym samym wyświetlaczu, na którym została uruchomiona poprzednia aktywność, gdy nowa aktywność jest uruchamiana bez określenia wyświetlacza docelowego za pomocą interfejsu API
ActivityOptions.setLaunchDisplayId()
. - [C-1-4] Należy usunąć wszystkie aktywności, gdy wyświetlacz z flagą
Display.FLAG_PRIVATE
zostanie usunięty. - [C-1-5] NALEŻY bezpiecznie ukryć treści na wszystkich ekranach, gdy urządzenie jest zablokowane za pomocą bezpiecznego ekranu blokady, chyba że aplikacja zdecyduje się wyświetlać na ekranie blokady za pomocą interfejsu API
Activity#setShowWhenLocked()
. - Powinien mieć
android.content.res.Configuration
, który odpowiada temu wyświetlaczowi, aby wyświetlać, działać prawidłowo i utrzymywać zgodność, jeśli aktywność jest uruchamiana na wyświetlaczu dodatkowym.
Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych czynności na Androidzie na dodatkowych wyświetlaczach, a dodatkowy wyświetlacz ma flagę android.view.Display.FLAG_PRIVATE:
- [C-3-1] Tylko właściciel wyświetlacza, systemu i działalności, które są już wyświetlane na tym wyświetlaczu, MUSI mieć możliwość uruchomienia wyświetlacza. Każdy może uruchomić wyświetlacz, który ma flagę android.view.Display.FLAG_PUBLIC.
3.3. Zgodność z natywnym interfejsem API
Zgodność kodu natywnego jest trudna do osiągnięcia. Dlatego implementatorzy urządzeń:
- [C-SR-1] MOCNO ZALECAMY korzystanie z implementacji bibliotek wymienionych poniżej z Android Open Source Project.
3.3.1. Interfejsy binarne aplikacji
Zarządzany kod bajtowy Dalvik może wywoływać kod natywny zawarty w pliku .apk
aplikacji jako plik ELF .so
skompilowany pod kątem odpowiedniej architektury sprzętowej urządzenia. Ponieważ kod natywny jest silnie zależny od technologii procesora, Android definiuje w NDK Androida kilka interfejsów binarnych aplikacji (ABI).
Implementacje na urządzeniu:
- [C-0-1] MUSI być zgodny z co najmniej jednym zdefiniowanym Android NDK ABI.
- [C-0-2] MUSI zawierać obsługę kodu działającego w środowisku zarządzanym, aby wywoływać kod natywny za pomocą standardowej semantyki interfejsu JNI (Java Native Interface).
- [C-0-3] Musi być zgodny ze źródłem (czyli z nagłówkiem) i binarną wersją (w przypadku interfejsu ABI) każdej wymaganej biblioteki na liście poniżej.
- [C-0-5] MUST accurately report the native Application Binary Interface
(ABI) supported by the device, via the
android.os.Build.SUPPORTED_ABIS
,android.os.Build.SUPPORTED_32_BIT_ABIS
, andandroid.os.Build.SUPPORTED_64_BIT_ABIS
parameters, each a comma separated list of ABIs ordered from the most to the least preferred one. [C-0-6] NALEŻY podać za pomocą powyższych parametrów podzbiór z poniższej listy ABI. NALEŻY NIE raportować żadnych ABI, które nie znajdują się na liście.
armeabi
(NDK nie obsługuje już tego typu docelów)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] NALEŻY udostępnić wszystkie te biblioteki, które zapewniają natywne interfejsy API, aplikacjom zawierającym kod natywny:
- libaaudio.so (obsługa dźwięku AAudio)
- libamidi.so (wbudowane wsparcie MIDI, jeśli funkcja
android.software.midi
jest obsługiwana zgodnie z opisem w sekcji 5.9) - libandroid.so (obsługa natywnej aktywności Androida)
- libc (biblioteka C)
- libcamera2ndk.so
- libdl (linker dynamiczny)
- libEGL.so (własne 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 (rejestrowanie na Androidzie)
- libmediandk.so (obsługa natywnych interfejsów API multimediów)
- libm (biblioteka matematyczna)
- libneuralnetworks.so (interfejs 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 C++)
- libvulkan.so (Vulkan)
- libz (kompresja Zlib)
- Interfejs JNI
[C-0-8] NIE MOŻESZ dodawać ani usuwać publicznych funkcji w bibliotekach natywnych wymienionych powyżej.
[C-0-9] W
/vendor/etc/public.libraries.txt
NALEŻY podać listę dodatkowych bibliotek innych niż AOSP udostępnionych bezpośrednio aplikacjom innych firm.[C-0-10] Nie wolno udostępniać aplikacji innych firm na poziomie interfejsu API 24 lub wyższym żadnych innych bibliotek natywnych zaimplementowanych i dostarczonych w AOSP jako biblioteki systemowe, ponieważ są one zarezerwowane.
[C-0-11] NALEŻY wyeksportować wszystkie symbole funkcji OpenGL ES 3.1 i pakietu rozszerzeń Androida zdefiniowane w NDK za pomocą biblioteki
libGLESv3.so
. Pamiętaj, że chociaż wszystkie symbole MUSZĄ być obecne, w sekcji 7.1.4.1 opisano szczegółowo wymagania dotyczące pełnej implementacji poszczególnych odpowiednich funkcji.[C-0-12] NALEŻY wyeksportować symbole funkcji dla podstawowych symboli funkcji Vulkan 1.0, a także rozszerzeń
VK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
iVK_KHR_get_physical_device_properties2
za pomocą bibliotekilibvulkan.so
. Pamiętaj, że chociaż wszystkie symbole MUSZĄ być obecne, w sekcji 7.1.4.2 podano więcej informacji o wymaganiach dotyczących pełnej implementacji poszczególnych funkcji.NALEŻY go skompilować, używając kodu źródłowego i plików nagłówkowych dostępnych w upstreamowym projekcie Android Open Source.
Pamiętaj, że w przyszłych wersjach Androida możemy dodać obsługę dodatkowych ABI.
3.3.2. Zgodność z 32-bitowym kodem natywnym ARM
Jeśli implementacje na urządzeniu zgłaszają obsługę ABI armeabi
, to:
- [C-3-1] Musisz też obsługiwać
armeabi-v7a
i zgłaszać tę obsługę, ponieważarmeabi
jest przeznaczona tylko do zapewnienia zgodności wstecznej ze starszymi aplikacjami.
Jeśli implementacje na urządzeniu zgłaszają obsługę ABI armeabi-v7a
, aplikacje korzystające z tego ABI:
[C-2-1] W pliku
/proc/cpuinfo
MUSISZ uwzględnić podane niżej wiersze i NIE wolno Ci zmieniać wartości na tym samym urządzeniu, nawet jeśli są one odczytywane przez inne ABI.Features:
, a następnie listę opcjonalnych funkcji procesora ARMv7 obsługiwanych przez urządzenie.CPU architecture:
, a następnie liczba całkowita określająca najwyższą obsługiwaną architekturę ARM (np. „8” w przypadku urządzeń ARMv8).
[C-2-2] NALEŻY zawsze mieć dostępne te operacje, nawet w przypadku, gdy ABI jest implementowany na architekturze ARMv8, za pomocą natywnego wsparcia procesora lub emulacji oprogramowania:
- Instrukcje dotyczące SWP i SWPB.
- CP15ISB, CP15DSB i CP15DMB.
[C-2-3] Musi obsługiwać rozszerzenie Advanced SIMD (znane też jako NEON).
3.4. Zgodność z przeglądarką
3.4.1. Zgodność WebView
Jeśli implementacje na urządzeniu zapewniają pełną implementację interfejsu API android.webkit.Webview
, to:
- [C-1-1] MUST report
android.software.webview
. - [C-1-2] DO wdrażania interfejsu API
android.webkit.WebView
MUSISZ użyć kompilacji projektu Chromium z upstreamowego projektu Android Open Source na gałęzi Androida 13. [C-1-3] Ciąg tekstowy klienta użytkownika przesyłany przez WebView MUSI mieć 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.
- „Build/$(BUILD)” MOŻE być pominięty, ale jeśli jest obecny, ciąg znaków $(BUILD) MUSI być taki sam jak wartość android.os.Build.ID.
- Wartość ciągu $(CHROMIUM_VER) MUSI być wersją Chromium w górnym projekcie Android Open Source.
- Implementacje urządzeń MOGĄ pomijać w ciągu danych klienta użytkownika ciąg znaków Mobile.
Komponent WebView powinien obsługiwać jak najwięcej funkcji HTML5, a jeśli tak się dzieje, powinien być zgodny z specyfikacją HTML5.
[C-1-4] NALEŻY renderować dostarczone treści lub treści z odległego adresu URL w procesie, który jest odrębny od aplikacji, która instancjuje WebView. Proces oddzielnego renderera MUSI mieć mniejsze uprawnienia, działać pod oddzielnym identyfikatorem użytkownika, nie mieć dostępu do katalogu danych aplikacji, nie mieć bezpośredniego dostępu do sieci i mieć dostęp tylko do minimalnego zestawu usług systemowych za pomocą Bindera. Implementacja WebView w AOSP spełnia ten wymóg.
Pamiętaj, że jeśli implementacje urządzeń są 32-bitowe lub deklarują flagę funkcji
android.hardware.ram.low
, są one zwolnione z wymogów C-1-3.
3.4.2. Zgodność z przeglądarką
Jeśli implementacje urządzeń obejmują samodzielną aplikację przeglądarki do ogólnego przeglądania internetu, muszą:
- [C-1-1] MUSI obsługiwać wszystkie te interfejsy API związane z HTML5:
- [C-1-2] MUSI obsługiwać interfejs webstorage API w HTML5/W3C oraz IndexedDB API w HTML5/W3C. Pamiętaj, że ponieważ instytucje opracowujące standardy dotyczące tworzenia stron internetowych przechodzą na IndexedDB zamiast webstorage, IndexedDB ma stać się wymaganym komponentem w przyszłej wersji Androida.
- W samodzielnej aplikacji przeglądarki MOŻNA przesyłać niestandardowy ciąg znaków klienta użytkownika.
- NALEŻY wdrożyć obsługę jak największej części HTML5 w samodzielnej aplikacji przeglądarki (opracowanej na podstawie przeglądarki WebKit lub zastępczej przeglądarki innej firmy).
Jeśli jednak implementacje na urządzeniach nie obejmują samodzielnej aplikacji przeglądarki, nie mogą:
- [C-2-1] MUSI nadal obsługiwać wzorce intencji publicznych opisane w sekcji 3.2.3.1.
3.5. Zgodność zachowania interfejsu API
Implementacje na urządzeniu:
- [C-0-9] NALEŻY zadbać o to, aby kompatybilność z zachowaniem API była stosowana we wszystkich zainstalowanych aplikacjach, chyba że są one ograniczone zgodnie z opisem w sekcji 3.5.1.
- [C-0-10] NIE WOLNO stosować podejścia polegającego na użyciu listy dozwolonych, które zapewnia zgodność zachowania interfejsu API tylko w przypadku aplikacji wybranych przez implementatorów urządzenia.
Zachowanie każdego z typów interfejsu API (zarządzanego, miękkiego, natywnego i internetowego) musi być zgodne z preferowaną implementacją w górnym projekcie Android Open Source. Oto niektóre obszary zgodności:
- [C-0-1] Urządzenia NIE MOGĄ zmieniać działania ani semantyki standardowego zamiaru.
- [C-0-2] Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (np. usługi, aktywności, dostawcy treści itp.).
- [C-0-3] Urządzenia NIE MOGĄ zmieniać semantyki standardowych uprawnień.
- Urządzenia NIE MOGĄ zmieniać ograniczeń narzucanych na aplikacje działające w tle.
W szczególności w przypadku aplikacji działających w tle:
- [C-0-4] NALEŻY zatrzymać wykonywanie wywołań zwrotnych zarejestrowanych przez aplikację, aby otrzymywać dane wyjściowe z
GnssMeasurement
iGnssNavigationMessage
. - [C-0-5] NALEŻY ograniczyć częstotliwość aktualizacji przesyłanych do aplikacji za pomocą klasy interfejsu API
LocationManager
lub metodyWifiManager.startScan()
. - [C-0-6] jeśli aplikacja jest kierowana na poziom interfejsu API 25 lub nowszy, NIE MOŻE ona zezwalać na rejestrowanie odbiorników transmisji w ramach domyślnych intencji Androida w pliku manifestu aplikacji, chyba że intencja ta wymaga uprawnienia
"signature"
lub"signatureOrSystem"
protectionLevel
lub znajduje się na liście wyjątków. - [C-0-7] Jeśli aplikacja jest kierowana na poziom interfejsu API 25 lub wyższy, MUSI zatrzymać usługi działające w tle, tak jakby aplikacja wywołała metodę
stopSelf()
usługi, chyba że aplikacja została umieszczona na liście dozwolonych tymczasowo w celu wykonania zadania widocznego dla użytkownika. - [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zwolnić blokadę aktywacji, którą posiada.
- [C-0-4] NALEŻY zatrzymać wykonywanie wywołań zwrotnych zarejestrowanych przez aplikację, aby otrzymywać dane wyjściowe z
- [C-0-11] Urządzenia MUSZĄ zwracać te dostawcy zabezpieczeń jako pierwsze
7 wartości tablicy z metody
Security.getProviders()
w podanej kolejności i z podanymi nazwami (zwracanymi przezProvider.getName()
) i klasy, chyba że aplikacja zmodyfikowała listę za pomocąinsertProviderAt()
lubremoveProvider()
. Urządzenia mogą zwracać dodatkowych dostawców po wskazanej liście dostawców poniżej.- AndroidNSSP –
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL –
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider –
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround –
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. Pakiet Compatibility Test Suite (CTS) testuje znaczne części platformy pod kątem zgodności behawioralnej, ale nie wszystkie. Implementator jest odpowiedzialny za zapewnienie zgodności z zachowaniem projektu Android Open Source. Dlatego implementatorzy urządzeń powinni w miarę możliwości korzystać z kodu źródłowego dostępnego w ramach Projektu Android Open Source, a nie ponownie implementować istotnych części systemu.
3.5.1. Ograniczenie aplikacji
Jeśli implementacje na urządzeniach korzystają z zastrzeżonego mechanizmu ograniczania aplikacji (np. zmiany lub ograniczenia zachowania interfejsu API opisanego w pakiecie SDK), a mechanizm jest bardziej restrykcyjny niż element Restricted App Standby Bucket, to:
- [C-1-1] Musisz umożliwić użytkownikowi wyświetlenie listy aplikacji objętych ograniczeniami.
- [C-1-2] MUSISZ umożliwić użytkownikowi włączenie lub wyłączenie wszystkich tych zastrzeżeń w poszczególnych aplikacjach.
[C-1-3] NIE wolno automatycznie stosować tych zastrzeżonych ograniczeń bez dowodów na zły stan systemu, ale można stosować ograniczenia w aplikacjach po wykryciu złego stanu systemu, takiego jak zablokowane blokady budzenia, długotrwałe uruchamianie usług i inne kryteria. Kryteria mogą być określane przez implementatorów urządzeń, ale muszą być związane z wpływem aplikacji na stan systemu. Nie wolno używać innych kryteriów, które nie są związane z działaniem systemu, np. braku popularności aplikacji na rynku.
[C-1-4] NIE wolno automatycznie stosować tych zastrzeżonych ograniczeń w przypadku aplikacji, gdy użytkownik ręcznie wyłączył ograniczenia aplikacji, i MOŻNA zasugerować użytkownikowi zastosowanie tych zastrzeżonych ograniczeń.
[C-1-5] NALEŻY poinformować użytkowników, jeśli te ograniczenia własnościowe są automatycznie stosowane do aplikacji. Takie informacje MUSZĄ zostać podane w ciągu 24 godzin poprzedzających zastosowanie tych ograniczeń.
[C-1-6] W przypadku wywołań interfejsu API z aplikacji musisz zwracać wartość true w metodie ActivityManager.isBackgroundRestricted().
[C-1-7] NIE MOŻESZ ograniczać działania aplikacji na pierwszym planie, której użytkownik używa w pełni.
[C-1-8] NALEŻY zawiesić te ograniczenia w przypadku aplikacji, gdy użytkownik zaczyna z niej korzystać, co powoduje, że staje się ona aplikacją na pierwszym planie.
[C-1-10] Musisz udostępnić publiczny i jasny dokument lub stronę internetową, które opisują sposób stosowania ograniczeń zastrzeżonych. Ten dokument lub witryna MUSI być dostępna z dokumentów pakietu SDK Androida i MUSI zawierać:
- Warunki uruchamiające ograniczenia dotyczące własności.
- Co i jak można ograniczyć w aplikacji.
- Jak aplikacja może być wyłączona z takich ograniczeń.
- Jak aplikacja może poprosić o wyjątek od ograniczeń zastrzeżonych, jeśli obsługuje takie wyłączenie w przypadku aplikacji, które użytkownik może zainstalować.
Jeśli aplikacja jest fabrycznie zainstalowana na urządzeniu i użytkownik nie korzystał z niej przez ponad 30 dni, [C-1-3] [C-1-5] nie obowiązuje.
Jeśli implementacje na urządzeniach rozszerzają ograniczenia aplikacji zaimplementowane w AOSP, muszą:
- [C-2-1]NALEŻY przestrzegać implementacji opisanej w tym dokumencie.
3.5.2. Hibernacja aplikacji
Jeśli implementacje na urządzeniach obejmują funkcję hibernacji aplikacji, która jest zawarta w AOSP lub rozszerza funkcję zawartą w AOSP, to:
- [C-1-1] MUSI spełniać wszystkie wymagania podane w sekcji 3.5.1 z wyjątkiem [C-1-6] i [C-1-3].
- [C-1-2] NALEŻY zastosować ograniczenie dotyczące aplikacji tylko wtedy, gdy istnieją dowody, że użytkownik nie korzystał z niej przez pewien czas. MOCNO ZALECAMY, aby czas trwania wynosił co najmniej miesiąc. Korzystanie MUSI być zdefiniowane przez wyraźną interakcję użytkownika za pomocą interfejsu API UsageStats#getLastTimeVisible() lub cokolwiek, co spowoduje, że aplikacja przejdzie ze stanu zatrzymania wymuszonego do stanu użycia, w tym wiązania usług, wiązania dostawców treści, wyraźne transmisje itp., które będą śledzone przez nowy interfejs API UsageStats#getLastTimeAnyComponentUsed().
- [C-1-3] NALEŻY stosować ograniczenia wpływające na wszystkich użytkowników urządzenia tylko wtedy, gdy istnieją dowody, że pakiet nie był używany przez ŻADNEGO użytkownika przez pewien czas. Zdecydowanie zalecamy, aby ten okres wynosił co najmniej miesiąc.
- [C-1-4] Aplikacja NIE MOŻE być niezdolna do reagowania na intencje aktywności, powiązania usług, żądania dostawcy treści lub transmisje bezpośrednie.
Tryb uśpienia aplikacji w AOSP spełnia powyższe wymagania.
3.6. Nazwy katalogów interfejsu API
Android stosuje konwencje dotyczące przestrzeni nazw pakietów i klas zdefiniowane przez język programowania Java. Aby zapewnić zgodność z aplikacjami innych firm, implementatorzy urządzeń NIE MOGĄ wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w następujących przestrzeniach nazw pakietów:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
Oznacza to, że:
- [C-0-1] Nie wolno modyfikować publicznie udostępnionych interfejsów API na platformie Android poprzez zmianę sygnatur metod lub klas albo usuwanie klas lub pól klas.
- [C-0-2] NIE MOŻESZ dodawać żadnych publicznie dostępnych elementów (takich jak klasy, interfejsy, pola czy metody do istniejących klas lub interfejsów) ani interfejsów API Test czy System do interfejsów API w wymienionych powyżej przestrzeniach nazw. „Publicznie dostępny element” to dowolna konstrukcja, która nie jest ozdobiona znacznikiem „@hide” używanym w górnym kodzie źródłowym Androida.
Implementatorzy urządzeń MOGĄ modyfikować podstawową implementację interfejsów API, ale takie modyfikacje:
- [C-0-3] NIE MOŻE wpływać na opisane zachowanie i sygnatura języka Java interfejsów API udostępnionych publicznie.
- [C-0-4] NIE MOŻE być reklamowany ani w inny sposób udostępniany deweloperom.
Implementatorzy urządzeń mogą jednak dodawać niestandardowe interfejsy API poza standardową przestrzenią nazw Androida, ale te niestandardowe interfejsy API:
- [C-0-5] NIE MOŻE znajdować się w przestrzeni nazw należącej do innej organizacji lub do niej odwołującej. Na przykład implementatorzy urządzeń NIE MOGĄ dodawać interfejsów API do przestrzeni nazw
com.google.*
ani podobnych: może to robić tylko Google. Podobnie Google NIE MOŻE dodawać interfejsów API do przestrzeni nazw innych firm. - [C-0-6] Musi być zapakowany w bibliotece współdzielonej Androida, aby tylko aplikacje, które z nich korzystają (za pomocą mechanizmu <uses-library>), były na nie wpływały.
Implementatorzy urządzeń MOGĄ dodawać niestandardowe interfejsy API w natywnym języku, poza interfejsami NDK, ale niestandardowe interfejsy API:
- [C-1-1] NIE MOŻE BYĆ w bibliotece NDK ani w bibliotece należącej do innej organizacji, jak opisano tutaj.
Jeśli implementator urządzenia zamierza ulepszyć jedną z wymienionych powyżej nazw przestrzeni nazw pakietu (np. dodając nową przydatną funkcję do istniejącego interfejsu API lub dodając nowy interfejs API), powinien odwiedzić stronę source.android.com i rozpocząć proces przesyłania zmian i kodu zgodnie z informacjami na tej stronie.
Pamiętaj, że powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java. Celem tej sekcji jest po prostu wzmocnienie tych konwencji i ustanowienie ich jako wiążących poprzez uwzględnienie w tej Definicji zgodności.
3.7. Zgodność w czasie działania
Implementacje na urządzeniu:
[C-0-1] MUSI obsługiwać pełny format Dalvik Executable (DEX) oraz specyfikację i semantykę bajtkodów Dalvik.
[C-0-2] NALEŻY skonfigurować środowisko uruchomieniowe Dalvik tak, aby przydzielać pamięć zgodnie z platformą Android na wyższym poziomie i zgodnie z danymi podanymi w tabeli poniżej. (Definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).
NALEŻY użyć Android RunTime (ART), referencyjnej implementacji w górę formatu wykonywalnego Dalvik oraz systemu zarządzania pakietami referencyjnej implementacji.
NALEŻY przeprowadzić testy fuzz w różnych trybach wykonywania i na różnych architekturach docelowych, aby zapewnić stabilność środowiska uruchomieniowego. Zapoznaj się z informacjami o JFuzz i DexFuzz na stronie Projektu Android Open Source.
Pamiętaj, że podane poniżej wartości pamięci są wartościami minimalnymi, a implementacje urządzeń MOŻE przydzielić więcej pamięci na aplikację.
Układ ekranu | Gęstość ekranu | Minimalna pamięć aplikacji |
---|---|---|
Android Watch | 120 dpi (ldpi) | 32 MB |
140 dpi | ||
160 dpi (mdpi) | ||
180 dpi (180 dpi) | ||
200 dpi | ||
213 dpi (tvdpi) | ||
220 dpi | 36 MB | |
240 dpi (hdpi) | ||
280 dpi | ||
320 dpi (xhdpi) | 48 MB | |
360 dpi | ||
400 dpi (400 dpi) | 56 MB | |
420 dpi (420 dpi) | 64 MB | |
480 dpi (xxhdpi) | 88 MB | |
560 dpi (560 dpi) | 112 MB | |
640 dpi (xxxhdpi) | 154 MB | |
małe/normalne | 120 dpi (ldpi) | 32 MB |
140 dpi | ||
160 dpi (mdpi) | ||
180 dpi (180 dpi) | 48 MB | |
200 dpi | ||
213 dpi (tvdpi) | ||
220 dpi | ||
240 dpi (hdpi) | ||
280 dpi | ||
320 dpi (xhdpi) | 80 MB | |
360 dpi | ||
400 dpi (400 dpi) | 96 MB | |
420 dpi (420 dpi) | 112 MB | |
480 dpi (xxhdpi) | 128 MB | |
560 dpi (560 dpi) | 192 MB | |
640 dpi (xxxhdpi) | 256 MB | |
duży | 120 dpi (ldpi) | 32 MB |
140 dpi | 48 MB | |
160 dpi (mdpi) | ||
180 dpi (180 dpi) | 80 MB | |
200 dpi | ||
213 dpi (tvdpi) | ||
220 dpi | ||
240 dpi (hdpi) | ||
280 dpi | 96 MB | |
320 dpi (xhdpi) | 128 MB | |
360 dpi | 160 MB | |
400 dpi (400 dpi) | 192 MB | |
420 dpi (420 dpi) | 228 MB | |
480 dpi (xxhdpi) | 256 MB | |
560 dpi (560 dpi) | 384 MB | |
640 dpi (xxxhdpi) | 512 MB | |
bardzo duża | 120 dpi (ldpi) | 48 MB |
140 dpi | 80 MB | |
160 dpi (mdpi) | ||
180 dpi (180 dpi) | 96 MB | |
200 dpi | ||
213 dpi (tvdpi) | ||
220 dpi | ||
240 dpi (hdpi) | ||
280 dpi | 144 MB | |
320 dpi (xhdpi) | 192 MB | |
360 dpi | 240 MB | |
400 dpi (400 dpi) | 288 MB | |
420 dpi (420 dpi) | 336 MB | |
480 dpi (xxhdpi) | 384 MB | |
560 dpi (560 dpi) | 576 MB | |
640 dpi (xxxhdpi) | 768 MB |
3.8. Zgodność interfejsu
3.8.1. Menu z aplikacjami (ekran główny)
Android zawiera aplikację uruchamiającą (ekran główny) oraz obsługę aplikacji innych firm, które mogą zastąpić aplikację uruchamiającą urządzenie (ekran główny).
Jeśli implementacje urządzeń umożliwiają zastąpienie ekranu głównego urządzenia aplikacjami innych firm, muszą:
- [C-1-1] NALEŻY zadeklarować funkcję platformy
android.software.home_screen
. - [C-1-2] NALEŻY zwrócić obiekt
AdaptiveIconDrawable
, gdy aplikacja innej firmy używa tagu<adaptive-icon>
do wyświetlenia swojej ikony, a metodyPackageManager
służące do pobierania ikon są wywoływane.
Jeśli implementacje urządzeń zawierają domyślny program uruchamiający, który obsługuje przypinanie skrótów w aplikacji, muszą one:
- [C-2-1] MUST report
true
forShortcutManager.isRequestPinShortcutSupported()
. - [C-2-2] NALEŻY wyświetlić użytkownikowi prośbę o dodanie skrótu żądanego przez aplikacje za pomocą metody
ShortcutManager.requestPinShortcut()
interfejsu API. - [C-2-3] MUSI obsługiwać przypięte skróty oraz skróty dynamiczne i statyczne zgodnie z opisem na stronie Skróty do aplikacji.
Jeśli implementacja urządzenia nie obsługuje przypinania skrótów w aplikacji, skróty:
- [C-3-1] MUST report
false
forShortcutManager.isRequestPinShortcutSupported()
.
Jeśli implementacje urządzeń korzystają z domyślnego menu z aplikacjami, które zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu ShortcutManager API, to:
- [C-4-1] MUSI obsługiwać wszystkie udokumentowane funkcje skrótów (np. skróty statyczne i dynamiczne, przypinanie skrótów) oraz w pełni implementować interfejsy API klasy
ShortcutManager
.
Jeśli implementacje urządzeń obejmują domyślną aplikację uruchamiającą, która wyświetla plakietki na ikonach aplikacji, muszą one:
- [C-5-1] Musisz przestrzegać metody interfejsu API
NotificationChannel.setShowBadge()
. Innymi słowy, wyświetlaj wizualną ikonę powiązaną z ikoną aplikacji, jeśli wartość jest ustawiona natrue
, i nie wyświetlaj żadnego schematu plakietki ikony aplikacji, jeśli wartość wszystkich kanałów powiadomień aplikacji jest ustawiona nafalse
. - MOGĄ zastąpić plakietki ikon aplikacji za pomocą zastrzeżonego schematu plakietki, gdy aplikacje innych firm wskazują na obsługę zastrzeżonego schematu plakietki za pomocą zastrzeżonych interfejsów API, ale POWINNY używać zasobów i wartości udostępnianych przez interfejsy API plakietki powiadomień opisane w pakiecie SDK, takich jak
Notification.Builder.setNumber()
iNotification.Builder.setBadgeIconType()
.
Jeśli implementacje na urządzeniach obsługują ikony monochromatyczne, ikony te:
- [C-6-1] MUSI być używany tylko wtedy, gdy użytkownik wyraźnie go włączy (np. w menu Ustawienia lub w menu wyboru tapety).
3.8.2. Widżety
Android obsługuje widżety aplikacji innych firm, definiując typ komponentu i odpowiednie interfejsy API oraz cykl życia, które umożliwiają aplikacjom udostępnianie „widżetu aplikacji” użytkownikowi końcowemu.
Jeśli implementacje urządzeń obsługują widżety aplikacji innych firm, mogą:
- [C-1-1] NALEŻY zadeklarować obsługę funkcji platformy
android.software.app_widgets
. - [C-1-2] Musisz uwzględnić wbudowane funkcje obsługi widżetów aplikacji oraz udostępnić opcje interfejsu użytkownika umożliwiające dodawanie, konfigurowanie, wyświetlanie i usuwanie widżetów aplikacji.
- [C-1-3] Musi obsługiwać renderowanie widżetów o wymiarach 4 x 4 w standardowym rozmiarze siatki. Szczegółowe informacje znajdziesz w wytycznych dotyczących 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 aplikacji innych firm i przypinanie skrótów w aplikacji, muszą:
- [C-2-1] MUST report
true
forAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] NALEŻY wyświetlić użytkownikowi prośbę o dodanie skrótu żądanego przez aplikacje za pomocą metody
AppWidgetManager.requestPinAppWidget()
interfejsu API.
3.8.3. Powiadomienia
Android zawiera interfejsy API Notification
i NotificationManager
, które umożliwiają deweloperom aplikacji innych firm powiadamianie użytkowników o istotnych zdarzeniach i przyciąganie ich uwagi za pomocą komponentów sprzętowych (np. dźwięku, wibracji i światła) oraz funkcji oprogramowania (np. panelu powiadomień, paska systemowego) urządzenia.
3.8.3.1. Prezentacja powiadomień
Jeśli implementacje urządzeń zezwalają aplikacjom innych firm na powiadamianie użytkowników o istotnych zdarzeniach, mogą one:
- [C-1-1] MUSI obsługiwać powiadomienia, które korzystają z funkcji sprzętowych zgodnie z opisem w dokumentacji pakietu SDK i w zakresie możliwym w ramach implementacji sprzętu urządzenia. Jeśli na przykład implementacja urządzenia zawiera wibrator, musi prawidłowo implementować interfejsy API wibracji. Jeśli implementacja urządzenia nie zawiera sprzętu, odpowiednie interfejsy API MUSZĄ być zaimplementowane jako no-ops. Więcej informacji o tym znajdziesz w sekcji 7.
- [C-1-2] Musisz prawidłowo renderować wszystkie zasobów (ikony, pliki animacji itp.) udostępnione w interfejsach API lub w przewodniku po stylu ikon paska stanu/paska systemowego, chociaż mogą one zapewniać użytkownikom inne wrażenia w przypadku powiadomień niż w przypadku referencyjnej implementacji na Androidzie w wersji open source.
- [C-1-3] MUSISZ prawidłowo stosować zachowania opisane w przypadku interfejsów API na potrzeby aktualizowania, usuwania i grupowania powiadomień.
- [C-1-4] NALEŻY podać pełne informacje o zachowaniu interfejsu NotificationChannel API udokumentowanego w pakiecie SDK.
- [C-1-5] NALEŻY zapewnić użytkownikowi możliwość zablokowania i zmodyfikowania powiadomienia aplikacji innej firmy na każdym poziomie kanału i aplikacji.
- [C-1-6] Musisz też umożliwić użytkownikom wyświetlanie kanałów powiadomień, które zostały usunięte.
- [C-1-7] NALEŻY prawidłowo renderować wszystkie zasoby (obrazy, naklejki, ikony itp.) udostępnione za pomocą Notification.MessagingStyle wraz z tekstem powiadomienia bez dodatkowej interakcji użytkownika. Na przykład w rozmowie grupowej ustawionej za pomocą metody setGroupConversation MUSISZ wyświetlać wszystkie zasoby, w tym ikony udostępnione przez android.app.Person.
- [C-SR-1] MOCNO POLECAMY zapewnienie użytkownikowi możliwości kontrolowania powiadomień wyświetlanych aplikacjom, którym przyznano uprawnienie do odbioru powiadomień. Dokładność musi być taka, aby użytkownik mógł kontrolować, jakie typy powiadomień są przekazywane do tego odbiornika. Typy muszą obejmować powiadomienia „rozmowy”, „ostrzegające”, „ciche” i „ważne bieżące”.
- [C-SR-2] MOCNO ZALECAMY, aby umożliwić użytkownikom określenie aplikacji, które nie będą otrzymywać powiadomień od konkretnego odbiornika powiadomień.
- [C-SR-3] ZALECAMY, aby po wielokrotnym odrzuceniu powiadomienia przez użytkownika automatycznie wyświetlać użytkownikowi opcję zablokowania powiadomienia z konkretnej aplikacji innej firmy w ramach każdego kanału i pakietu aplikacji.
- Powinien obsługiwać powiadomienia z elementami rozszerzonymi.
- Niektóre powiadomienia o wyższym priorytecie powinny być wyświetlane jako powiadomienia z ostrzeżeniem.
- NALEŻY umożliwić użytkownikowi wyciszenie powiadomień.
- MOGĄ zarządzać widocznością i czasem, w którym aplikacje innych firm mogą powiadamiać użytkowników o istotnych zdarzeniach, aby ograniczać problemy związane z bezpieczeństwem, takie jak rozproszenie uwagi kierowcy.
Android 11 wprowadza obsługę powiadomień o rozmowie, czyli powiadomień, które korzystają z MessagingStyle i zawierają opublikowany identyfikator skrótu Osoby.
Implementacje na urządzeniu:
- [C-SR-4] ZALECAMY grupowanie i wyświetlanie
conversation notifications
powiadomień z wyjątkiem powiadomień z bieżącej usługi na pierwszym planie i powiadomieńimportance:high
.
Jeśli implementacje urządzeń obsługują conversation notifications
, a aplikacja udostępnia wymagane dane do bubbles
, to:
- [C-SR-5] MOCNO zalecamy wyświetlanie tej rozmowy jako dymka. Implementacja AOSP spełnia te wymagania dzięki domyślnemu interfejsowi System UI, ustawieniom i wywoływaczemu.
Jeśli implementacje urządzeń obsługują powiadomienia z zawartością multimedialną, mogą:
- [C-2-1] W przypadku prezentowanych elementów zasobów NALEŻY używać zasobów podanych w klasie interfejsu API
Notification.Style
i jej podklasach. - NALEŻY przedstawić wszystkie elementy zasobu (np. ikonę, tytuł i tekst podsumowania) zdefiniowane w klasie interfejsu API
Notification.Style
i jej podklasach.
Powiadomienia o ważnych informacjach to powiadomienia, które są wyświetlane użytkownikowi w chwili ich otrzymania niezależnie od tego, z czego korzysta. Jeśli implementacje urządzeń obsługują powiadomienia z wyprzedzeniem:
- [C-3-1] NALEŻY używać widoku powiadomień typu heads-up i zasobów opisanych w klasie interfejsu API
Notification.Builder
, gdy wyświetlane są powiadomienia typu heads-up. - [C-3-2] NALEŻY wyświetlać działania udostępniane za pomocą
Notification.Builder.addAction()
wraz z treścią powiadomienia bez dodatkowej interakcji użytkownika, zgodnie z opisem w pakiecie SDK.
3.8.3.2. Usługa odbiornika powiadomień
Android zawiera interfejsy API NotificationListenerService
, które umożliwiają aplikacjom (po wyraźnym włączeniu przez użytkownika) otrzymywanie kopii wszystkich powiadomień w miarę ich publikowania lub aktualizowania.
Implementacje na urządzeniu:
- [C-0-1] NALEŻY prawidłowo i na bieżąco aktualizować powiadomienia w całości do wszystkich zainstalowanych usług odsłuchiwania, w tym wszystkich metadanych dołączonych do obiektu powiadomienia.
- [C-0-2] NALEŻY przestrzegać wywołania interfejsu API
snoozeNotification()
, zamknąć powiadomienie i wykonać wywołanie zwrotne po upływie czasu opóźnienia ustawionego w wywołaniu interfejsu API.
Jeśli implementacje urządzeń umożliwiają użytkownikom wyciszanie powiadomień, muszą one:
- [C-1-1] MUSI prawidłowo odzwierciedlać stan powiadomienia wstrzymanego za pomocą standardowych interfejsów API, takich jak
NotificationListenerService.getSnoozedNotifications()
. - [C-1-2] Musisz umożliwić użytkownikom odkładanie powiadomień z każdej zainstalowanej aplikacji innej firmy, chyba że pochodzą one z trwałych usług działających na pierwszym planie.
3.8.3.3. Tryb Nie przeszkadzać/Tryb priorytetowy
Jeśli implementacje urządzeń obsługują funkcję DND (nazywanej też trybem priorytetowym), urządzenia te:
- [C-1-1] NALEŻY, gdy implementacja urządzenia zapewnia użytkownikowi możliwość zezwolenia lub odmowy zezwolenia aplikacjom innych firm na dostęp do konfiguracji zasad Nie przeszkadzać, wyświetlać automatyczne zasady Nie przeszkadzać utworzone przez aplikacje obok zdefiniowanych przez użytkownika i wstępnie zdefiniowanych zasad.
- [C-1-3] MUSI uwzględniać wartości
suppressedVisualEffects
przekazywane w ramachNotificationManager.Policy
, a jeśli aplikacja ma ustawione flagi SUPPRESSED_EFFECT_SCREEN_OFF lub SUPPRESSED_EFFECT_SCREEN_ON, POWINNA poinformować użytkownika, że efekty wizualne są tłumione w menu ustawień Nie przeszkadzać.
3.8.4. Interfejsy Assist API
Android zawiera interfejsy API Asystenta, które umożliwiają aplikacjom określenie, ile informacji o bieżącym kontekście ma być udostępniane Asystentowi na urządzeniu.
Jeśli implementacje urządzeń obsługują działanie Asystent:
- [C-2-1] NALEŻY wyraźnie poinformować użytkownika końcowego, kiedy kontekst jest udostępniany, w ten sposób:
- Za każdym razem, gdy aplikacja asystująca uzyskuje dostęp do kontekstu, wyświetla białe światło na krawędziach ekranu, które odpowiada lub przekracza czas trwania i jasność implementacji projektu Android Open Source.
- W przypadku wstępnie zainstalowanej aplikacji asystenta użytkownik powinien mieć możliwość wywołania asystenta w mniej niż 2 etapów od domyślnego menu ustawień głosowego wprowadzania danych i asystenta oraz udostępniania kontekstu tylko wtedy, gdy użytkownik wywoła asystenta za pomocą słowa kluczowego lub przycisku nawigacyjnego asystenta.
- [C-2-2] Wyznaczona interakcja, która uruchamia aplikację wspomagającą zgodnie z opisem w sekcji 7.2.3, MUSI uruchamiać wybraną przez użytkownika aplikację wspomagającą, czyli aplikację, która implementuje
VoiceInteractionService
, lub aktywność obsługującą intencjęACTION_ASSIST
.
3.8.5. Alerty i powiadomienia wyświetlane na ekranie
Aplikacje mogą używać interfejsu API Toast
, aby wyświetlać użytkownikowi krótkie, niemodalne ciągi znaków, które znikają po krótkim czasie, oraz interfejsu API typu okna TYPE_APPLICATION_OVERLAY
, aby wyświetlać okna alertów jako nakładki na inne aplikacje.
Jeśli implementacje urządzeń obejmują ekran lub wyjście wideo, muszą:
[C-1-1] Musisz umożliwić użytkownikowi zablokowanie wyświetlania przez aplikację okien alertów, które używają
TYPE_APPLICATION_OVERLAY
. Implementacja AOSP spełnia ten wymóg, ponieważ zawiera elementy sterujące w pasku powiadomień.[C-1-2] Musisz obsługiwać interfejs Toast API i wyświetlać komunikaty Toast użytkownikom w wyraźnie widoczny sposób.
3.8.6. Motywy
Android udostępnia „motywy” jako mechanizm umożliwiający aplikacjom stosowanie stylów w całym oknie lub aplikacji.
Android zawiera rodzinę motywów „Holo” i „Material” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd do motywu Holo zdefiniowanego w pakiecie Android SDK.
Jeśli implementacje urządzeń obejmują ekran lub wyjście wideo, muszą:
- [C-1-1] Nie wolno zmieniać żadnych atrybutów motywu Holo udostępnionych aplikacjom.
- [C-1-2] Musi obsługiwać rodzinę motywów „Material” i nie może zmieniać żadnych atrybutów motywu Material Design ani zasobów udostępnianych aplikacjom.
[C-1-3] NALEŻY ustawić rodzinę czcionek „sans-serif” na Roboto w wersji 2.x w przypadku języków obsługiwanych przez Roboto lub umożliwić użytkownikowi zmianę czcionki używanej w przypadku rodziny czcionek „sans-serif” na Roboto w wersji 2.x w przypadku języków obsługiwanych przez Roboto.
[C-1-4] MUSI generować dynamiczne palety barw zgodnie z dokumentacją AOSP dla
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(patrzandroid.theme.customization.system_palette
iandroid.theme.customization.theme_style
).[C-1-5] MUST generate dynamic color tonal palettes using color theme styles enumerated in the
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
documentation (seeandroid.theme.customization.theme_styles
), namelyTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
.„Kolor źródłowy” służy do generowania dynamicznych palet barw tonów, gdy jest wysyłany z użyciem parametru
android.theme.customization.system_palette
(jak opisano w dokumentacjiSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] Wartość chroma
CAM16
MUSI wynosić co najmniej 5.POWINIEN być wyprowadzony z tapety za pomocą funkcji
com.android.systemui.monet.ColorScheme#getSeedColors
, która udostępnia kilka prawidłowych kolorów źródłowych do wyboru.Jeśli żaden z podanych kolorów nie spełnia powyższego wymagania dotyczącego koloru źródłowego, należy użyć wartości
0xFF1B6EF3
.
Android zawiera też rodzinę motywów „Domyślny motyw urządzenia” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i wrażenia do motywu urządzenia określonego przez implementatora urządzenia.
- Implementacje na urządzeniu mogą modyfikować atrybuty motywu domyślnego urządzenia udostępniane aplikacjom.
Android obsługuje wariant motywu z przezroczystymi paskami systemu, co pozwala deweloperom aplikacji wypełnić obszar za paskiem stanu i paskiem nawigacji treściami aplikacji. Aby zapewnić spójne wrażenia dla deweloperów w ramach tej konfiguracji, ważne jest, aby styl ikony paska stanu był zachowany na różnych implementacjach urządzeń.
Jeśli implementacje urządzeń zawierają pasek stanu systemu, muszą:
- [C-2-1] W przypadku ikon stanu systemu (np. siły sygnału i poziomu naładowania baterii) oraz powiadomień wysyłanych przez system należy używać koloru białego, chyba że ikona wskazuje stan problemowy lub aplikacja prosi o jasny pasek stanu za pomocą flagi WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
- [C-2-2] Implementacje urządzeń z Androidem MUSZĄ zmienić kolor ikon stanu systemu na czarny (szczegóły znajdziesz w R.style), gdy aplikacja poprosi o jasny pasek stanu.
3.8.7. Animowane tapety
Android definiuje typ komponentu oraz odpowiadający mu interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi co najmniej tapety w ruchu. Animowane tapety to animacje, wzory lub podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które wyświetlają się jako tapeta za innymi aplikacjami.
Urządzenie jest uznawane za zdolne do niezawodnego wyświetlania tapet na żywo, jeśli może wyświetlać wszystkie tapety na żywo bez ograniczeń funkcjonalności, przy rozsądznej częstotliwości odświeżania i bez negatywnego wpływu na działanie innych aplikacji. Jeśli ograniczenia sprzętowe powodują, że tapety lub aplikacje ulegają awarii, nie działają prawidłowo, zużywają zbyt dużo energii procesora lub baterii albo działają z niedopuszczalnie niską liczbą klatek na sekundę, sprzęt jest uznawany za niezdolny do wyświetlania tapet na żywo. Na przykład niektóre tapety na żywo mogą używać kontekstu OpenGL 2.0 lub 3.x do renderowania treści. Tapeta na żywo nie będzie działać prawidłowo na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ używanie przez nią tego kontekstu może powodować konflikty z innymi aplikacjami, które również go używają.
- Urządzenia, które mogą niezawodnie wyświetlać animowane tapety zgodnie z opisem powyżej, POWINNY obsługiwać animowane tapety.
Jeśli implementacje urządzeń obsługują animowane tapety, mogą:
- [C-1-1] MUSI raportować flagę funkcji platformy android.software.live_wallpaper.
3.8.8. Przełączanie aktywności
Dostarczony kod źródłowy Androida obejmuje ekran przeglądu, czyli interfejs użytkownika na poziomie systemu umożliwiający przełączanie zadań i wyświetlanie ostatnio używanych czynności i zadań za pomocą miniatury graficznego stanu aplikacji w momencie jej ostatniego zamknięcia przez użytkownika.
Implementacje na urządzeniu, w tym klawisz nawigacji funkcji Ostatnie, opisane w sekcji 7.2.3, mogą zmieniać interfejs.
Jeśli implementacje urządzeń, w tym klucz nawigacyjny funkcji Ostatnie, zgodnie z opisem w sekcji 7.2.3 zmieniają interfejs, muszą:
- [C-1-1] Musi obsługiwać co najmniej 7 wyświetlanych aktywności.
- POWINIEN wyświetlać co najmniej tytuł 4 aktywności naraz.
- [C-1-2] NALEŻY wdrożyć zachowanie przypinania ekranu i udostępnić użytkownikowi menu ustawień, aby włączyć tę funkcję.
- NALEŻY wyświetlić kolor wyróżnienia, ikonę i tytuł ekranu w sekcji Ostatnie.
- NALEŻY wyświetlić opcję zamknięcia („x”), ale MOŻNA opóźnić to do momentu, gdy użytkownik wejdzie w interakcję z ekranami.
- NALEŻY wdrożyć skrót umożliwiający łatwe przełączanie się na poprzednią aktywność.
- POWINIEN wywoływać szybkie przełączanie między 2 ostatnio używanymi aplikacjami po dwukrotnym naciśnięciu klawisza funkcyjnego „Ostatnie”.
- POWINIEN aktywować tryb wielookienkowy z podzielonym ekranem (jeśli jest obsługiwany), gdy przycisk funkcji ostatnich aplikacji jest długo naciśnięty.
- MOŻNA wyświetlać powiązane ostatnie elementy jako grupę, która porusza się razem.
- [C-SR-1] NAJLEPSZEJ jest użycie na ekranie przeglądu interfejsu Androida (lub podobnego interfejsu opartego na miniaturach).
3.8.9. Zarządzanie wejściami
Android obsługuje zarządzanie metodą wprowadzania oraz edytory metod wprowadzania innych firm.
Jeśli implementacje urządzeń umożliwiają użytkownikom korzystanie z metod wprowadzania danych innych firm na urządzeniu, użytkownicy:
- [C-1-1] NALEŻY zadeklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy IME zgodnie z dokumentacją pakietu Android SDK.
3.8.10. Sterowanie multimediami na ekranie blokady
Od wersji 5.0 Androida interfejs Remote Control Client API jest wycofany na rzecz Media Notification Template, który umożliwia aplikacjom multimedialnym integrację z elementami sterowania odtwarzaniem wyświetlanymi na ekranie blokady.
3.8.11. Wygaszacze ekranu (wcześniej marzenia)
Aby dowiedzieć się, jak skonfigurować wygaszacze ekranu, zapoznaj się z sekcją 3.2.3.5.
3.8.12. Lokalizacja
Jeśli implementacje urządzeń zawierają czujnik sprzętowy (np. GPS), który może dostarczyć współrzędnych lokalizacji,
- [C-1-2] Musisz wyświetlić aktualny stan lokalizacji w menu Lokalizacja w Ustawieniach.
- [C-1-3] NIE MOŻNA 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ą ekran lub wyjście wideo, muszą:
- [C-1-1] Musi być możliwe renderowanie tych emotikonów w kolorze.
- [C-1-2] MUSI obsługiwać:
- czcionka Roboto 2 w różnych grubościach: bezszeryfowa cienka, bezszeryfowa lekka, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light w przypadku języków dostępnych na urządzeniu.
- Pełne pokrycie Unicode 7.0 dla alfabetów łacińskiego, greckiego i cyrylickiego, w tym zakresów łacińskiego rozszerzonego A, B, C i D oraz wszystkich znaków w bloku symboli walutowych w Unicode 7.0.
- [C-1-3] Nie wolno usuwać ani modyfikować pliku NotoColorEmoji.tff w pliku obrazu systemu. (dozwolone jest dodanie nowej czcionki emotikonów, aby zastąpić emotikony w pliku NotoColorEmoji.tff)
- POWINIEN obsługiwać odcienie skóry i emotikony przedstawiające różne rodziny, zgodnie z raportami technicznymi Unicode nr 51.
Jeśli implementacje na urządzeniach obejmują IME, muszą:
- NALEŻY podać użytkownikowi metodę wprowadzania tych emotikonów.
Android obsługuje renderowanie czcionek birmańskich. W Mjanmie do wyświetlania języków tego kraju używa się kilku czcionek niezgodnych z Unicode, powszechnie znanych jako „Zawgyi”.
Jeśli implementacja urządzenia obejmuje obsługę języka birmańskiego, urządzenie:
- [C-2-1] Domyślnie tekst MUSI być renderowany za pomocą czcionki zgodnej z Unicode. Czcionka niezgodna z Unicode NIE MOŻE być ustawiona jako domyślna, chyba że użytkownik wybierze ją w selektorze języka.
- [C-2-2] MUSI obsługiwać czcionkę zgodną z Unicode oraz czcionkę niezgodną z Unicode, jeśli taka czcionka jest obsługiwana na urządzeniu. Czcionka niezgodna z Unicode NIE MOŻE usuwać ani nadpisywać czcionki zgodnej z Unicode.
- [C-2-3] TRZEBA renderować tekst za pomocą czcionki niezgodnej z Unicodem, JEDYNIE JEŚLI podano kod języka z kodem skryptu Qaag (np. my-Qaag). Do odwołania się do czcionek niezgodnych z Unicode w przypadku języka birmańskiego nie można używać żadnych innych kodów ISO języka ani regionu (zarówno przypisanych, jak i nieprzypisanych oraz zarezerwowanych). Deweloperzy aplikacji i twórcy stron internetowych mogą podać my-Qaag jako kod języka, tak jak w przypadku każdego innego języka.
3.8.14. Wiele okien
Jeśli implementacje urządzeń mają możliwość wyświetlania wielu działań w tym samym czasie, muszą:
- [C-1-1] NALEŻY zaimplementować tryb wielu okien zgodnie z zachowaniem aplikacji i interfejsami API opisanymi w dokumentacji obsługi trybu wielu okien pakietu SDK Androida oraz spełnić te wymagania:
- [C-1-2] MUSI honorować wartość
android:resizeableActivity
, która jest ustawiana przez aplikację w plikuAndroidManifest.xml
zgodnie z opisem w tym pakiecie SDK. - [C-1-3] Nie wolno oferować trybu podzielonego ekranu ani trybu swobodnego, jeśli wysokość ekranu jest mniejsza niż 440 dp, a szerokość ekranu jest mniejsza niż 440 dp.
- [C-1-4] Rozmiar aktywności NIE MOŻE być mniejszy niż 220 dp w trybach wielookiennych innych niż obraz w obrazie.
- Implementacje urządzeń o rozmiarze ekranu
xlarge
POWINNY obsługiwać tryb swobodny.
Jeśli implementacje urządzeń obsługują tryb wielu okien i tryb podzielonego ekranu:
- [C-2-2] Należy przyciąć dokowane okno na podzielonym ekranie, ale należy pokazać część zawartości, jeśli okno aplikacji Launcher jest oknem aktywnym.
- [C-2-3] MUSI honorować zadeklarowane wartości
AndroidManifestLayout_minWidth
iAndroidManifestLayout_minHeight
aplikacji uruchamiającej innej firmy oraz nie może ich zastępować podczas wyświetlania niektórych treści z zadokowanej aktywności.
Jeśli implementacje urządzeń obsługują tryb wielu okien i tryb obrazu w obrazie, to:
- [C-3-1] Aplikacja MUSI uruchamiać czynności w wieloszybowym trybie obrazu w obrazie, gdy:
* jest kierowana na interfejs API na poziomie 26 lub wyższym i deklaruje:
android:supportsPictureInPicture
* jest kierowana na interfejs API na poziomie 25 lub niższym i deklaruje:android:resizeableActivity
orazandroid:supportsPictureInPicture
. - [C-3-2] Musisz udostępniać działania w SystemUI zgodnie z określeniami bieżącej aktywności PIP za pomocą interfejsu
setActions()
API. - [C-3-3] Musi obsługiwać formaty obrazu o stosunku większym niż 1:2,39 i mniejszym niż 2,39:1, jak określono w działalności PIP za pomocą interfejsu API
setAspectRatio()
. - [C-3-4] DO sterowania oknem PIP należy UŻYWAĆ
KeyEvent.KEYCODE_WINDOW
; jeśli tryb PIP nie jest zaimplementowany, klucz MUSI być dostępny dla aktywności na pierwszym planie. - [C-3-5] Musisz umożliwić użytkownikowi zablokowanie wyświetlania aplikacji w trybie PIP. Implementacja AOSP spełnia ten wymóg dzięki elementom sterującym w pasku powiadomień.
[C-3-6] W przypadku okna PIP, gdy aplikacja nie deklaruje wartości dla
AndroidManifestLayout_minWidth
iAndroidManifestLayout_minHeight
:- Urządzenia, na których wartość ustawienia Configuration.uiMode jest inna niż
UI_MODE_TYPE_TELEVISION
, MUSZĄ mieć przydzielone minimalną szerokość i wysokość 108 dp. - Urządzenia z wartością
UI_MODE_TYPE_TELEVISION
w ustawieniu Configuration.uiMode MUSZĄ mieć minimalną szerokość 240 dp i minimalną wysokość 135 dp.
- Urządzenia, na których wartość ustawienia Configuration.uiMode jest inna niż
3.8.15. Wycięcie w ekranie
Android obsługuje wycięcie wyświetlacza zgodnie z opisem w dokumentacji pakietu SDK. Interfejs API DisplayCutout
definiuje obszar na krawędzi ekranu, który może nie być dostępny dla aplikacji z powodu wycięcia na ekranie lub zakrzywionego ekranu na krawędziach.
Jeśli implementacje urządzeń zawierają wycięcia w ekranie, muszą spełniać te wymagania:
- [C-1-5] Nie wolno mieć wycięć, jeśli format obrazu urządzenia wynosi 1,0 (1:1).
- [C-1-2] Nie może być więcej niż 1 wycięcia na krawędź.
- [C-1-3] MUSI obsługiwać flagi wycięcia wyświetlacza ustawione przez aplikację za pomocą interfejsu
WindowManager.LayoutParams
API zgodnie z opisem w pakiecie SDK. - [C-1-4] MUSI raportować prawidłowe wartości wszystkich danych wycinków zdefiniowanych w interfejsie API
DisplayCutout
.
3.8.16. Sterowanie urządzeniami
Android zawiera interfejsy API ControlsProviderService
i Control
, które umożliwiają aplikacjom innych firm publikowanie elementów sterujących urządzeniem, aby użytkownicy mogli szybko sprawdzić jego stan i działania.
Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2_2_3.
3.8.17. Schowek
Implementacje na urządzeniu:
- [C-0-1] NIE WOLNO wysyłać danych z bufora wymiany do żadnego komponentu, aktywności, usługi ani przez żadne połączenie sieciowe bez wyraźnej czynności użytkownika (np. naciśnięcia przycisku na nakładce) lub wskazania treści, które mają być wysyłane, z wyjątkiem usług wymienionych w sekcji 9.8.6 Zapisywanie treści i wyszukiwanie w aplikacji.
Jeśli implementacje urządzeń generują widoczny dla użytkownika podgląd podczas kopiowania treści do schowka w przypadku dowolnego elementu ClipData
, w którym ClipData.getDescription().getExtras()
zawiera android.content.extra.IS_SENSITIVE
, to:
- [C-1-1] Konieczne jest usunięcie podglądu widocznego dla użytkownika
Implementacja referencyjna AOSP spełnia te wymagania dotyczące schowka.
3.9. Administracja urządzeniem
Android zawiera funkcje, które umożliwiają aplikacjom dbającym o bezpieczeństwo wykonywanie funkcji administracyjnych na poziomie systemu, takich jak egzekwowanie zasad dotyczących haseł czy zdalne wymazywanie danych, za pomocą interfejsu Android Device Administration API.
Jeśli implementacje urządzeń obsługują pełny zakres zasad zarządzania urządzeniami zdefiniowanych w dokumentacji pakietu SDK Androida, to:
- [C-1-1] MUST declare
android.software.device_admin
. - [C-1-2] MUSI obsługiwać konfigurowanie właściciela urządzenia zgodnie z opisem w sekcji 3.9.1 i sekcji 3.9.1.1.
3.9.1 Obsługa administracyjna urządzenia
3.9.1.1 Obsługa administracyjna właściciela urządzenia
Jeśli implementacje na urządzeniu deklarują android.software.device_admin
, to:
- [C-1-1] MUSI obsługiwać rejestrowanie klienta Device Policy (DPC) jako aplikacji właściciela urządzenia w sposób opisany poniżej:
- Jeśli implementacja urządzenia nie ma skonfigurowanych użytkowników ani danych użytkownika, to:
- [C-1-5] NALEŻY zarejestrować aplikację DPC jako aplikację właściciela urządzenia lub umożliwić aplikacji DPC wybranie, czy ma być właścicielem urządzenia czy właścicielem profilu, jeśli urządzenie deklaruje obsługę komunikacji w zakresie bliskim (NFC) za pomocą flagi funkcji
android.hardware.nfc
i odbiera wiadomość NFC zawierającą rekord z typem MIMEMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] NALEŻY wysłać działanie ACTION_GET_PROVISIONING_MODE po wywołaniu obsługi Provisioning Owner, aby aplikacja DPC mogła wybrać, czy ma być właścicielem urządzenia czy właścicielem profilu, w zależności od wartości parametru
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, chyba że z kontekstu wynika, że jest tylko jedna prawidłowa opcja. - [C-1-9] DO aplikacji Właściciel urządzenia MUSI zostać wysłana intencja ACTION_ADMIN_POLICY_COMPLIANCE, jeśli podczas obsługi zostaje utworzony Właściciel urządzenia, niezależnie od użytej metody obsługi. Użytkownik nie może kontynuować pracy w kreatorze konfiguracji, dopóki aplikacja Właściciel urządzenia nie zakończy działania.
- [C-1-5] NALEŻY zarejestrować aplikację DPC jako aplikację właściciela urządzenia lub umożliwić aplikacji DPC wybranie, czy ma być właścicielem urządzenia czy właścicielem profilu, jeśli urządzenie deklaruje obsługę komunikacji w zakresie bliskim (NFC) za pomocą flagi funkcji
- Jeśli implementacja urządzenia zawiera użytkowników lub ich dane:
- [C-1-7] NIE MOŻESZ już rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia.
- Jeśli implementacja urządzenia nie ma skonfigurowanych użytkowników ani danych użytkownika, to:
- [C-1-2] MUSI wyświetlać odpowiednie powiadomienie (takie jak opisane w AOSP) i uzyskać wyraźną zgodę użytkownika przed ustawieniem aplikacji jako właściciela urządzenia, chyba że urządzenie jest skonfigurowane programowo w trybie demonstracyjnym przed interakcją użytkownika na ekranie.
Jeśli implementacje urządzeń deklarują android.software.device_admin
, ale zawierają również zastrzeżone rozwiązanie do zarządzania urządzeniami i mechanizm promowania aplikacji skonfigurowanej w ich rozwiązaniu jako „Właściciel urządzenia” równoważny ze standardowym „Właścicielem urządzenia” rozpoznawanym przez standardowe interfejsy API DevicePolicyManager Androida, to:
- [C-2-1] NALEŻY wdrożyć proces weryfikacji, który potwierdza, że promowana aplikacja należy do legalnego rozwiązania dla firm do zarządzania urządzeniami i została skonfigurowana w ramach rozwiązania firmowego w taki sposób, aby mieć prawa równoważne z prawami „Właściciela urządzenia”.
- [C-2-2] NALEŻY wyświetlić tę samą informację o zgodzie właściciela urządzenia w ramach procesu AOSP, który został zainicjowany przez
android.app.action.PROVISION_MANAGED_DEVICE
przed zarejestrowaniem aplikacji DPC jako „Właściciel urządzenia”. - [C-2-3] Nie wolno zakodować w twardym kodzie zgody na przetwarzanie danych ani uniemożliwiać korzystania z innych aplikacji właściciela urządzenia.
3.9.1.2 Zarządzanie profilem zarządzanym
Jeśli implementacje na urządzeniu deklarują android.software.managed_users
, to:
[C-1-1] NALEŻY zaimplementować interfejsy API, które umożliwiają aplikacji kontrolera zasad dotyczących urządzeń (DPC) stać się właścicielem nowego profilu zarządzanego.
[C-1-2] Proces obsługi Provisioning w profilu zarządzanym (przepływ danych zainicjowany przez DPC za pomocą android.app.action.PROVISION_MANAGED_PROFILE lub przez platformę), ekran zgody i przebieg interakcji z użytkownikiem MUSZĄ być zgodne z implementacją AOSP.
[C-1-3] W ustawieniach należy DOSTARCZAĆ użytkownikowi następujące możliwości, aby poinformować go, że dana funkcja systemu została wyłączona przez kontroler zasad urządzenia (DPC):
- Ujednolicona ikona lub inna funkcja dla użytkownika (np. ikona informacji o AOSP w górę) wskazująca, że określone ustawienie jest ograniczone przez administratora urządzenia.
- Krótki komunikat wyjaśniający, który administrator urządzenia udostępnia za pomocą interfejsu
setShortSupportMessage
. - Ikona aplikacji DPC
[C-1-4] W profilu służbowym MUSISZ uruchomić w ramach intencją ACTION_PROVISIONING_SUCCESSFUL, jeśli właściciel profilu został ustalony, gdy inicjowanie obsługi zostało zainicjowane przez intencję android.app.action.PROVISION_MANAGED_PROFILE, a DPC zaimplementował uchwyt.
[C-1-5] NALEŻY wysłać transmisję ACTION_PROFILE_PROVISIONING_COMPLETE do DPC profilu służbowego, gdy inicjowanie obsługi jest wywoływane przez intencję android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] NALEŻY wysłać działanie ACTION_GET_PROVISIONING_MODE po wywołaniu obsługi konfiguracji właściciela profilu, aby aplikacja DPC mogła wybrać, czy ma być właścicielem urządzenia, czy właścicielem profilu, z wyjątkiem sytuacji, gdy obsługa jest wywoływana przez działanie android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] NALEŻY wysłać intencję ACTION_ADMIN_POLICY_COMPLIANCE do profilu służbowego, gdy podczas obsługi zostaje utworzony właściciel profilu, niezależnie od tego, która metoda obsługi jest używana, z wyjątkiem sytuacji, gdy obsługa jest wywoływana przez intencję android.app.action.PROVISION_MANAGED_PROFILE. Użytkownik nie może kontynuować pracy z kreatorem konfiguracji, dopóki aplikacja Właściciel profilu nie zakończy działania.
[C-1-8] NALEŻY wysłać ACTION_MANAGED_PROFILE_PROVISIONED broadcast do DPC profilu osobistego, gdy ustanowiono właściciela profilu, niezależnie od zastosowanej metody obsługi.
3.9.2 Obsługa profilu zarządzanego
Jeśli implementacje na urządzeniu deklarują android.software.managed_users
, to:
- [C-1-1] Musi obsługiwać profile zarządzane za pomocą interfejsów API
android.app.admin.DevicePolicyManager
. - [C-1-2] NALEŻY zezwolić na utworzenie tylko 1 profila zarządzanego.
- [C-1-3] NALEŻY użyć plakietki ikony (podobnej do plakietki AOSP upstream) do reprezentowania zarządzanych aplikacji i widżetów oraz innych elementów interfejsu z plakietką, takich jak Ostatnie i Powiadomienia.
- [C-1-4] Musi wyświetlać ikonę powiadomienia (podobną do plakietki AOSP) wskazującą, że użytkownik jest w aplikacji na profilu zarządzanym.
- [C-1-5] NALEŻY wyświetlić komunikat podpowiadający, że użytkownik jest w profilu zarządzanym, gdy urządzenie się obudzi (ACTION_USER_PRESENT) i aplikacja na pierwszym planie znajduje się w profilu zarządzanym.
- [C-1-6] Jeśli istnieje profil zarządzany, w oknie „Wybór intencji” MUSI być widoczna opcja pozwalająca użytkownikowi przekazać intencję z profilu zarządzanego do głównego użytkownika lub odwrotnie, jeśli jest to możliwe w ramach zasad dotyczących urządzenia.
- [C-1-7] Jeśli istnieje profil zarządzany, MUSI on udostępniać użytkownikowi te możliwości:
- oddzielne rozliczanie baterii, lokalizacji, danych mobilnych i zajęcia miejsca na dysku w przypadku głównego użytkownika i profilu zarządzanego;
- niezależne zarządzanie aplikacjami VPN zainstalowanymi na profilu głównego użytkownika lub profilu zarządzanym;
- niezależne zarządzanie aplikacjami zainstalowanymi w ramach profilu głównego użytkownika lub profilu zarządzanego.
- niezależne zarządzanie kontami w ramach profilu głównego użytkownika lub profilu zarządzanego.
- [C-1-8] NALEŻY zadbać o to, aby w preinstalowanych aplikacjach do wybierania numerów, kontaktów i wiadomości można było wyszukiwać i wyświetlać informacje o dzwoniącym z profilu zarządzanego (jeśli istnieje) obok informacji z profilu głównego, jeśli kontroler zasad urządzenia na to zezwala.
- [C-1-9] MUSI spełniać wszystkie wymagania dotyczące zabezpieczeń obowiązujące w przypadku urządzeń z włączoną obsługą wielu użytkowników (patrz sekcja 9.5), mimo że profil zarządzany nie jest liczony jako dodatkowy użytkownik oprócz głównego użytkownika.
Jeśli implementacje na urządzeniu deklarują android.software.managed_users
i android.software.secure_lock_screen
, to:
- [C-2-1] MUSI obsługiwać możliwość określenia osobnego ekranu blokady spełniającego poniższe wymagania w celu przyznawania dostępu tylko aplikacjom działającym w profilu zarządzanym.
- Implementacje urządzeń MUSZĄ obsługiwać intencję
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
i wyświetlać interfejs do konfigurowania osobnych danych logowania na ekranie blokady dla profilu zarządzanego. - Dane logowania na ekranie blokady w profilu zarządzanym MUSZĄ używać tych samych mechanizmów przechowywania i zarządzania danymi logowania co profil nadrzędny, zgodnie z dokumentacją na stronie projektu Android Open Source.
- Zasady dotyczące haseł w DPC MUSZĄ dotyczyć tylko danych logowania na ekranie blokady w profilu zarządzanym, chyba że są wywoływane w przypadku instancji
DevicePolicyManager
zwróconej przez getParentProfileInstance.
- Implementacje urządzeń MUSZĄ obsługiwać intencję
- Gdy kontakty z profilu zarządzanego są wyświetlane w preinstalowanym dzienniku połączeń, interfejsie podczas połączenia, powiadomieniach o rozmowie w toku i nieodebranych połączeniach, kontaktach i aplikacjach do obsługi wiadomości, powinny być oznaczone tym samym znacznikiem, który służy do wskazywania aplikacji na profilu zarządzanym.
3.9.3 Pomoc dla zarządzanych użytkowników
Jeśli implementacje na urządzeniu deklarują android.software.managed_users
, to:
- [C-1-1] NALEŻY zapewnić użytkownikowi możliwość wylogowania się z bieżącego konta i powrotu do konta głównego w sesji z wielu użytkowników, gdy
isLogoutEnabled
powracatrue
. Element interfejsu MUSI być dostępny na ekranie blokady bez odblokowywania urządzenia.
Jeśli implementacje na urządzeniu deklarują android.software.device_admin
i zapewniają użytkownikowi możliwość dodania dodatkowych użytkowników pomocniczych, to:
- [C-SR-1] ZALECAMY wyświetlanie tych samych informacji o zgodzie właściciela urządzenia AOSP, które zostały wyświetlone w ramach procesu inicjowanego przez android.app.action.PROVISION_MANAGED_DEVICE, przed zezwoleniem na dodanie kont przez nowego użytkownika dodatkowego, aby użytkownicy wiedzieli, że urządzenie jest zarządzane.
3.9.4 Wymagania dotyczące roli zarządzania zasadami dotyczącymi urządzeń
Jeśli implementacje na urządzeniach android.software.device_admin
lub
android.software.managed_users
, to:
- [C-1-1] MUSI obsługiwać rolę zarządzania zasadami urządzenia zgodnie z definicją w sekcji 9.1. Aplikacja, która ma rolę zarządzania zasadami urządzenia, MOŻE być zdefiniowana przez ustawienie
config_devicePolicyManagement
jako nazwa pakietu. Nazwa pakietu MUSI być poprzedzona:
i certyfikatem podpisywania, chyba że aplikacja jest preinstalowana.
Jeśli nazwa pakietu nie jest zdefiniowana w przypadku config_devicePolicyManagement
w sposób opisany powyżej:
- [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać wdrażanie bez aplikacji roli właściciela zasad zarządzania urządzeniem (AOSP udostępnia implementację referencyjną).
Jeśli nazwa pakietu jest zdefiniowana w przypadku config_devicePolicyManagement
zgodnie z opisem powyżej:
- [C-3-1] Aplikacja MUSI być zainstalowana na wszystkich profilach użytkownika.
- [C-3-2] Implementacje na urządzeniu MOGĄ zdefiniować aplikację, która aktualizuje właściciela roli zarządzania zasadami urządzenia przed ich wdrożeniem za pomocą ustawienia
config_devicePolicyManagementUpdater
.
Jeśli dla config_devicePolicyManagementUpdater
zdefiniowano nazwę pakietu w sposób opisany powyżej:
- [C-4-1] Aplikacja MUSI być wstępnie zainstalowana na urządzeniu.
- [C-4-2] Aplikacja MUSI implementować filtr intencji, który rozwiązuje
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
.
3.10. Ułatwienia dostępu
Android udostępnia warstwę ułatwień dostępu, która ułatwia użytkownikom z niepełnosprawnościami poruszanie się po urządzeniach. Android udostępnia też interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu otrzymywanie wywołań zwrotnych dotyczących zdarzeń użytkownika i systemu oraz generowanie alternatywnych mechanizmów informacji zwrotnej, takich jak odczytywanie tekstu, informacje zwrotne haptyczne i sterowanie za pomocą kulki lub panelu dotykowego.
Jeśli implementacje urządzeń obsługują usługi ułatwień dostępu innych firm, muszą:
- [C-1-1] NALEŻY zaimplementować interfejs API ułatwień dostępu na Androida zgodnie z opisem w dokumentacji pakietu SDK.
- [C-1-2] Musi generować zdarzenia ułatwień dostępu i przekazywać odpowiednie dane
AccessibilityEvent
do wszystkich zarejestrowanych implementacjiAccessibilityService
, zgodnie z dokumentacją pakietu SDK. - [C-1-4] NALEŻY zapewnić użytkownikowi możliwość sterowania usługami ułatwień dostępu, które deklarują flagę AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Pamiętaj, że w przypadku implementacji na urządzeniach z systemowym paskiem nawigacyjnym użytkownik powinien mieć opcję użycia przycisku na pasku nawigacyjnym systemu do sterowania tymi usługami.
Jeśli implementacje na urządzeniach obejmują wstępnie zainstalowane usługi ułatwień dostępu, muszą:
- [C-2-1] NALEŻY wdrożyć te wstępnie zainstalowane usługi ułatwień dostępu jako aplikacje Direct Boot Aware, gdy pamięć danych jest szyfrowana za pomocą szyfrowania plików (FBE).
- NALEŻY zapewnić w ramach procesu konfiguracji domyślnej mechanizm umożliwiający użytkownikom włączanie odpowiednich usług ułatwień dostępu, a także opcje dostosowywania rozmiaru czcionki, rozmiaru wyświetlacza i gestyk powiększania.
3.11. Zamiana tekstu na mowę
Android zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług konwersji tekstu na mowę (TTS), a także umożliwia dostawcom usług implementowanie usług TTS.
Jeśli implementacje urządzeń zgłaszają funkcję android.hardware.audio.output, to:
- [C-1-1] MUSI obsługiwać interfejsy API ram worka TTS na Androida.
Jeśli implementacje urządzeń obsługują instalację zewnętrznych mechanizmów TTS, mogą:
- [C-2-1] Musisz umożliwić użytkownikowi wybranie silnika TTS do użycia na poziomie systemu.
3.12. Framework wejścia TV
Android Television Input Framework (TIF) upraszcza dostarczanie treści na żywo na urządzeniach z Androidem TV. TIF udostępnia standardowy interfejs API do tworzenia modułów wejściowych, które sterują urządzeniami z Androidem TV.
Jeśli implementacje urządzeń obsługują format TIF, to:
- [C-1-1] NALEŻY zadeklarować funkcję platformy
android.software.live_tv
. - [C-1-2] MUSI obsługiwać wszystkie interfejsy TIF API, aby aplikacja, która korzysta z tych interfejsów API i danych wejściowych innych firm na podstawie TIF, mogła być instalowana i używana na urządzeniu.
3.13. Szybkie ustawienia
Android udostępnia komponent interfejsu Szybkie ustawienia, który umożliwia szybki dostęp do często używanych lub pilnie potrzebnych działań.
Jeśli implementacje urządzeń zawierają element interfejsu użytkownika Szybkich ustawień i obsługują Szybkie ustawienia innych firm, muszą:
- [C-1-1] Musisz zezwolić użytkownikowi na dodawanie i usuwanie kafelków udostępnianych przez interfejsy API
quicksettings
aplikacji innej firmy. - [C-1-2] Nie wolno automatycznie dodawać kafelka z aplikacji innej firmy bezpośrednio do Szybkich ustawień.
- [C-1-3] NALEŻY wyświetlać wszystkie kafelki dodane przez użytkownika z aplikacji innych firm obok kafelków szybkich ustawień dostarczonych przez system.
3.14. Interfejs multimediów
Jeśli implementacje urządzeń obejmują aplikacje nieaktywowane głosem (Aplikacje), które współpracują z aplikacjami innych firm za pomocą MediaBrowser
lub MediaSession
, Aplikacje:
[C-1-2] MUSI wyraźnie wyświetlać ikony uzyskane za pomocą
getIconBitmap()
lubgetIconUri()
oraz tytuły uzyskane za pomocągetTitle()
zgodnie z opisem wMediaDescription
. Możesz skrócić tytuły, aby zachować zgodność z przepisami dotyczącymi bezpieczeństwa (np. w przypadku rozpraszania uwagi kierowcy).[C-1-3] NALEŻY wyświetlać ikonę aplikacji innej firmy, gdy wyświetlane są treści dostarczane przez tę aplikację.
[C-1-4] Musisz umożliwić użytkownikowi interakcję z całą hierarchią
MediaBrowser
. MOŻE ograniczyć dostęp do części hierarchii, aby spełnić wymogi bezpieczeństwa (np. w przypadku rozpraszania uwagi kierowcy), ale NIE MOŻE faworyzować treści ani dostawcy treści.[C-1-5] NALEŻY wziąć pod uwagę dwukrotne kliknięcie
KEYCODE_HEADSETHOOK
lubKEYCODE_MEDIA_PLAY_PAUSE
jakoKEYCODE_MEDIA_NEXT
w przypadkuMediaSession.Callback#onMediaButtonEvent
.
3.15. Aplikacje błyskawiczne
Jeśli implementacje urządzeń obsługują aplikacje błyskawiczne, muszą spełniać te wymagania:
- [C-1-1] Aplikacje błyskawiczne MOGĄ mieć tylko te uprawnienia, dla których
android:protectionLevel
jest ustawione jako"instant"
. - [C-1-2] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami za pomocą domyślnych intencji, chyba że występuje jedna z tych sytuacji:
- Filtr wzoru intencji komponentu jest dostępny i ma wartość CATEGORY_BROWSABLE
- Działanie to jedno z tych: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE.
- element docelowy jest jawnie udostępniany za pomocą atrybutu android:visibleToInstantApps,
- [C-1-3] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interaktywność z zainstalowanymi aplikacjami, chyba że komponent jest udostępniany za pomocą android:visibleToInstantApps.
- [C-1-4] Zainstalowane aplikacje NIE MOGĄ uzyskiwać szczegółowych informacji o aplikacji błyskawicznej na urządzeniu, chyba że aplikacja błyskawiczna wyraźnie łączy się z zainstalowaną aplikacją.
Implementacje urządzeń MUSZĄ zapewniać użytkownikom te możliwości interakcji z aplikacją błyskawiczną: AOSP spełnia wymagania dzięki domyślnemu interfejsowi systemu, ustawieniom i wywoływaczemu. Implementacje na urządzeniu:
- [C-1-5] Musisz umożliwić użytkownikowi wyświetlanie i usuwanie Aplikacji błyskawicznych zapisanych lokalnie w pamięci podręcznej w przypadku każdego pojedynczego pakietu aplikacji.
- [C-1-6] Musisz wyświetlać użytkownikowi stałe powiadomienie, które można zwinąć, gdy aplikacja błyskawiczna działa na pierwszym planie. To powiadomienie MUSI zawierać informację, że aplikacje błyskawiczne nie wymagają instalacji, oraz opcję kierującą użytkownika do ekranu informacji o aplikacji w Ustawieniach. W przypadku aplikacji natychmiastowych uruchamianych za pomocą intencji internetowych, zdefiniowanych za pomocą intencji z działaniem ustawionym na
Intent.ACTION_VIEW
i schematem „http” lub „https”, dodatkowa opcja interakcji z użytkownikiem POWINNA umożliwiać użytkownikowi nie uruchamianie aplikacji natychmiastowej, a zamiast tego uruchomienie powiązanego linku w skonfigurowanej przeglądarce internetowej, jeśli jest ona dostępna na urządzeniu. - [C-1-7] Musisz zezwolić na dostęp do uruchomionych aplikacji błyskawicznych z funkcji Ostatnie, jeśli jest ona dostępna na urządzeniu.
[C-1-8] Musisz wstępnie wczytać co najmniej 1 aplikację lub komponent usługi z obsługą intencji wymienionych w pakiecie SDK tutaj i uczynić te intencje widoczne dla aplikacji błyskawicznych.
3.16. Parowanie urządzenia towarzyszącego
Android obsługuje parowanie urządzeń towarzyszących, aby umożliwić skuteczniejsze zarządzanie powiązaniem z urządzeniami towarzyszącymi. Udostępnia też interfejs API CompanionDeviceManager
, który pozwala aplikacjom korzystać z tej funkcji.
Jeśli implementacje urządzeń obsługują funkcję parowania urządzenia towarzyszącego:
- [C-1-1] NALEŻY zadeklarować flagę funkcji
FEATURE_COMPANION_DEVICE_SETUP
. - [C-1-2] Musisz mieć pewność, że interfejsy API w pakiecie
android.companion
są w pełni zaimplementowane. - [C-1-3] NALEŻY zapewnić użytkownikowi możliwość wybrania/potwierdzenia, że urządzenie towarzyszące jest dostępne i działa.
3.17. Aplikacje o dużej pojemności
Jeśli implementacje na urządzeniu deklarują funkcję FEATURE_CANT_SAVE_STATE
, to:
- [C-1-1] W systemie MUSI być zainstalowana tylko 1 aplikacja, która określa
cantSaveState
. Jeśli użytkownik opuści taką aplikację bez jej zamykania (np. przez naciśnięcie przycisku Home podczas korzystania z aktywnej aktywności w systemie zamiast naciśnięcia przycisku Wstecz, gdy w systemie nie ma już aktywnych aktywności), implementacje urządzeń MUSZĄ nadać priorytet tej aplikacji w pamięci RAM, tak jak w przypadku innych elementów, które mają pozostać uruchomione, takich jak usługi na pierwszym planie. Gdy taka aplikacja działa w tle, system może nadal stosować w niej funkcje zarządzania energią, takie jak ograniczanie dostępu do procesora i do sieci. - [C-1-2] Musisz zapewnić w interfejsie możliwość wybrania aplikacji, która nie będzie korzystać z normalnego mechanizmu zapisywania/przywracania stanu, gdy użytkownik uruchomi drugą aplikację zadeklarowaną za pomocą atrybutu
cantSaveState
. - [C-1-3] DO aplikacji, które określają
cantSaveState
, NIE MOŻNA stosować innych zmian w zasadach, takich jak zmiana wydajności procesora lub zmiana priorytetów harmonogramu.
Jeśli implementacje na urządzeniach nie deklarują funkcji
FEATURE_CANT_SAVE_STATE
,
to:
- [C-1-1] Musisz zignorować atrybut
cantSaveState
ustawiony przez aplikacje i nie możesz zmieniać zachowania aplikacji na podstawie tego atrybutu.
3.18. kontakty,
Android zawiera interfejsy API Contacts
Provider
, które umożliwiają aplikacjom zarządzanie informacjami o kontaktach zapisanymi na urządzeniu.
Dane kontaktów wprowadzane bezpośrednio na urządzeniu są zwykle synchronizowane z usługą internetową, ale mogą też znajdować się tylko lokalnie na urządzeniu.
Kontakty, które są przechowywane tylko na urządzeniu, są nazywane kontaktami lokalnymi.
RawContacts
są „powiązane z” lub „zmagazynowane na” koncie Account, gdy kolumny ACCOUNT_NAME
i ACCOUNT_TYPE
w przypadku kontaktów nieprzetworzonych pasują do odpowiednich pól Account.name i Account.type konta.
Domyślne konto lokalne: konto dla nieprzetworzonych kontaktów, które są przechowywane tylko na urządzeniu i nie są powiązane z kontem w AccountManager. Kontakty te są tworzone z wartościami null w kolumnach ACCOUNT_NAME
i ACCOUNT_TYPE
.
Niestandardowe konto lokalne: konto służące do przechowywania nieprzetworzonych kontaktów tylko na urządzeniu, które nie są powiązane z kontem w usłudze AccountManager. Takie kontakty są tworzone z co najmniej jedną wartością inną niż null w kolumnach ACCOUNT_NAME
i ACCOUNT_TYPE
.
Implementacje na urządzeniu:
- [C-SR-1] Zdecydowanie zalecamy, aby nie tworzyć niestandardowych kont lokalnych.
Jeśli implementacje urządzeń korzystają z niestandardowego konta lokalnego:
- [C-1-1] Musisz zwrócić
ACCOUNT_NAME
na niestandardowym koncie lokalnym:ContactsContract.RawContacts.getLocalAccountName
- [C-1-2] Wartość
ACCOUNT_TYPE
na niestandardowym koncie lokalnym MUSI zostać zwrócona przezContactsContract.RawContacts.getLocalAccountType
- [C-1-3] Nieprzetworzone kontakty wstawiane przez aplikacje innych firm za pomocą domyślnego konta lokalnego (czyli przez ustawienie wartości null dla pól
ACCOUNT_NAME
iACCOUNT_TYPE
) MUSZĄ być wstawiane na koncie lokalnym użytkownika. - [C-1-4] Niestandardowe kontakty wstawiane na niestandardowym koncie lokalnym NIE MOGĄ zostać usunięte podczas dodawania lub usuwania kont.
- [C-1-5] Operacje usuwania wykonywane na niestandardowym koncie lokalnym MUSZĄ powodować natychmiastowe usunięcie surowych kontaktów (tak, jakby parametr
CALLER_IS_SYNCADAPTER
był ustawiony na wartość true), nawet jeśli parametrCALLER\_IS\_SYNCADAPTER
był ustawiony na wartość false lub nie został określony.
4. Zgodność z pakietem aplikacji
Implementacje na urządzeniach:
[C-0-1] Musi być możliwe instalowanie i uruchamianie plików „.apk” na Androida wygenerowanych przez narzędzie „aapt” zawarte w oficjalnym pakiecie Android SDK.
- Powyższe wymaganie może być trudne do spełnienia, dlatego zalecamy używanie systemu zarządzania pakietami w implementacji referencyjnej AOSP.
[C-0-2] MUSI obsługiwać weryfikację plików „.apk” przy użyciu schematu podpisywania plików APK w wersji 3.1, schematu podpisywania plików APK w wersji 3, schematu podpisywania plików APK w wersji 2 oraz podpisywania plików JAR.
[C-0-3] NIE MOŻESZ rozszerzać formatów .apk, Android Manifest, Dalvik bytecode ani RenderScript bytecode w sposób uniemożliwiający ich prawidłową instalację i uruchamianie na innych zgodnych urządzeniach.
[C-0-4] NIE wolno zezwalać aplikacjom innym niż bieżący „instalator” pakietu na automatyczne odinstalowanie aplikacji bez potwierdzenia przez użytkownika, zgodnie z dokumentacją pakietu SDK dla uprawnienia
DELETE_PACKAGE
. Jedynymi wyjątkami są aplikacja weryfikująca pakiet systemowy, która obsługuje intencję PACKAGE_NEEDS_VERIFICATION, oraz aplikacja menedżera pamięci, która obsługuje intencję ACTION_MANAGE_STORAGE.[C-0-5] Musisz mieć aktywność, która obsługuje intencję
android.settings.MANAGE_UNKNOWN_APP_SOURCES
.[C-0-6] NIE WOLNO instalować pakietów aplikacji ze źródeł nieznanych, chyba że aplikacja, która prosi o instalację, spełnia wszystkie te wymagania:
- Musisz zadeklarować uprawnienie
REQUEST_INSTALL_PACKAGES
lub ustawić wartośćandroid:targetSdkVersion
na 24 lub niższą. - Użytkownik MUSI zezwolić na instalowanie aplikacji ze źródeł nieznanych.
- Musisz zadeklarować uprawnienie
NALEŻY umożliwić użytkownikowi przyznanie/wycofanie uprawnień do instalowania aplikacji z nieznanych źródeł, ale MOŻNA zaimplementować to jako funkcję nieaktywną i zwrócić
RESULT_CANCELED
dlastartActivityForResult()
, jeśli implementacja urządzenia nie chce udostępniać użytkownikom tej opcji. Nawet w takich przypadkach należy jednak poinformować użytkownika, dlaczego nie ma takiej opcji.[C-0-7] MUSI wyświetlać użytkownikowi okno z ostrzeżeniem zawierającym ciąg znaków dostarczony przez interfejs API systemu
PackageManager.setHarmfulAppWarning
przed uruchomieniem czynności w aplikacji, która została oznaczona przez ten sam interfejs API systemuPackageManager.setHarmfulAppWarning
jako potencjalnie szkodliwa.NALEŻY umożliwić użytkownikowi odinstalowanie lub uruchomienie aplikacji w oknie z ostrzeżeniem.
[C-0-8] NALEŻY wdrożyć obsługę systemu plików Incremental File System zgodnie z opisem tutaj.
[C-0-9] MUSI obsługiwać weryfikację plików .apk przy użyciu schematu podpisu plików APK w wersji 4 i schematu podpisu plików APK w wersji 4.1.
5. Zgodność multimedialna
Implementacje na urządzeniu:
- [C-0-1] MUSI obsługiwać formaty multimediów, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w sekcji 5.1 dla każdego z kodeków zadeklarowanych przez
MediaCodecList
. - [C-0-2] NALEŻY zadeklarować i zgłosić obsługę koderów i dekoderów dostępnych dla aplikacji innych firm za pomocą
MediaCodecList
. - [C-0-3] MUSI być w stanie prawidłowo dekodować i udostępniać aplikacjom innych firm wszystkie formaty, które może kodować. Obejmuje to wszystkie strumienie bitowe generowane przez jego kodery oraz profile raportowane w
CamcorderProfile
.
Implementacje na urządzeniu:
- NALEŻY dążyć do minimalnego opóźnienia kodeka, innymi słowy:
- NIE POWINNA zużywać ani przechowywać buforów wejściowych, a bufory wejściowe powinny być zwracane tylko po przetworzeniu.
- Nie należy przechowywać odkodowanych buforów dłużej niż określa to standard (np. SPS).
- NIE NALEŻY przechowywać zakodowanych buforów dłużej niż wymaga tego struktura GOP.
Wszystkie kodeki wymienione w sekcji poniżej są dostarczane jako implementacje oprogramowania w preferowanej implementacji Androida z projektu Android Open Source.
Pamiętaj, że ani Google, ani Open Handset Alliance nie gwarantują, że te kodeki są wolne od patentów innych firm. Osoby, które chcą używać tego kodu źródłowego w urządzeniach lub produktach programowych, powinny pamiętać, że implementacje tego kodu, w tym w oprogramowaniu open source lub shareware, mogą wymagać licencji patentowych od odpowiednich właścicieli patentów.
5.1. Kodeki multimedialne
5.1.1. Kodowanie dźwięku
Więcej informacji znajdziesz w sekcji 5.1.3. Szczegóły kodeków audio.
Jeśli implementacje urządzeń deklarują android.hardware.microphone
, muszą obsługiwać kodowanie tych formatów audio i udostępniać je aplikacjom innych firm:
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
Wszystkie kodery audio MUSZĄ obsługiwać:
- [C-3-1] Ramki audio w formacie PCM 16-bitowym w natywnej kolejności bajtów za pomocą interfejsu
android.media.MediaCodec
API.
5.1.2. Dekodowanie dźwięku
Więcej informacji znajdziesz w sekcji 5.1.3. Szczegóły kodeków audio.
Jeśli implementacje na urządzeniach deklarują obsługę funkcji
android.hardware.audio.output
, muszą obsługiwać dekodowanie tych formatów audio:
- [C-1-1] Profil MPEG-4 AAC (AAC LC)
- [C-1-2] MPEG-4 HE AAC Profile (AAC+)
- [C-1-3] MPEG-4 HE AACv2 Profile (ulepszona wersja AAC+)
- [C-1-4] AAC ELD (ulepszona jakość dźwięku AAC z małym opóźnieniem)
- [C-1-11] xHE-AAC (profil HE AAC rozszerzony ISO/IEC 23003-3, który obejmuje profil podstawowy USAC i profil sterowania zakresem dynamiki ISO/IEC 23003-4)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE, w tym formaty audio o wysokiej rozdzielczości do 24 bitów, częstotliwość próbkowania 192 kHz i 8 kanałów. Pamiętaj, że ten wymóg dotyczy tylko dekodowania, a urządzenie może zmniejszać próbkowanie i poziom miksowania podczas odtwarzania.
- [C-1-10] Opus
Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC strumieni wielokanałowych (czyli więcej niż 2 kanałów) na PCM za pomocą domyślnego dekodera audio AAC w interfejsie API android.media.MediaCodec
, MUSI być obsługiwane:
- [C-2-1] Dekodowanie MUSI być przeprowadzone bez downmixowania (np. strumień AAC 5.0 musi zostać zdekodowany do 5 kanałów PCM, a strumień AAC 5.1 musi zostać zdekodowany do 6 kanałów PCM).
- [C-2-2] Metadane zakresu dynamicznego MUSZĄ być zdefiniowane zgodnie z „Dynamic Range Control (DRC)” w normie ISO/IEC 14496-3 oraz kluczami DRC
android.media.MediaFormat
, aby skonfigurować zachowania dekodera audio 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 zalecamy, aby wszystkie dekodery audio AAC spełniały wymagania C-2-1 i C-2-2.
Podczas dekodowania dźwięku USAC w MPEG-D (ISO/IEC 23003-4):
- [C-3-1] Metadane dotyczące głośności i DRC muszą być interpretowane i stosowane zgodnie z poziomem 1 profilu MPEG-D DRC.
- [C-3-2] Dekoder MUSI działać zgodnie z konfiguracją ustawioną za pomocą tych kluczy
android.media.MediaFormat
:KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
iKEY_AAC_DRC_EFFECT_TYPE
.
Dekodery MPEG-4 AAC, HE AAC i HE AACv2:
- MOŻE obsługiwać głośność i kontrolę zakresu dynamicznego za pomocą profilu ISO/IEC 23003-4 Dynamic Range Control.
Jeśli obsługiwana jest norma ISO/IEC 23003-4 i w dekodowanym strumieniu bitów znajdują się metadane ISO/IEC 23003-4 oraz ISO/IEC 14496-3, wykonaj te czynności:
- W przypadku kolizji mają pierwszeństwo metadane ISO/IEC 23003-4.
Wszystkie dekodery audio MUSZĄ obsługiwać te formaty wyjściowe:
- [C-6-1] Ramki audio w formacie PCM 16-bitowym w natywnej kolejności bajtów za pomocą interfejsu
android.media.MediaCodec
API.
Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC strumieni wielokanałowych (czyli więcej niż 2 kanałów) na PCM za pomocą domyślnego dekodera audio AAC w interfejsie API android.media.MediaCodec
, MUSI być obsługiwane:
- [C-7-1] Aplikacja korzystająca z dekodowania MUSI mieć możliwość skonfigurowania klucza
KEY_MAX_OUTPUT_CHANNEL_COUNT
, aby kontrolować, czy treści są miksowane do stereo (przy użyciu wartości 2) czy są wyświetlane z użyciem natywnej liczby kanałów (przy użyciu wartości równej lub większej od tej liczby). Na przykład wartość 6 lub większa skonfiguruje dekoder na wyjście 6 kanałów, gdy podasz mu treści 5.1. - [C-7-2] Podczas dekodowania dekoder MUSI podać maskę kanału używaną w formacie wyjściowym za pomocą klucza
KEY_CHANNEL_MASK
, używając stałychandroid.media.AudioFormat
(np.CHANNEL_OUT_5POINT1
).
Jeśli implementacje urządzeń obsługują dekodery audio inne niż domyślny dekoder audio AAC i mogą wyświetlać dźwięk wielokanałowy (czyli więcej niż 2 kanały) po podaniu skompresowanych treści wielokanałowych, należy:
- [C-SR-2] Zaleca się, aby dekoder był konfigurowany przez aplikację za pomocą klucza dekodowania
KEY_MAX_OUTPUT_CHANNEL_COUNT
, aby kontrolować, czy treści są miksowane do stereo (przy użyciu wartości 2) lub czy są wyświetlane z wykorzystaniem natywnej liczby kanałów (przy użyciu wartości równej lub większej od tej liczby). Na przykład wartość 6 lub większa skonfiguruje dekoder na wyjście 6 kanałów, gdy podasz mu treści 5.1. - [C-SR-3] Podczas dekodowania zaleca się, aby dekoder podał informację o masce kanału używanej w formacie wyjściowym za pomocą klucza
KEY_CHANNEL_MASK
za pomocą stałych android.media.AudioFormat (np.CHANNEL_OUT_5POINT1
).
5.1.3. Szczegóły kodeków audio
Format/kodek | Szczegóły | Obsługiwane typy plików i formaty kontenerów |
---|---|---|
MPEG-4 AAC Profile (AAC LC) |
Obsługa treści mono, stereo, 5.0 i 5.1 z standardową częstotliwością próbkowania od 8 do 48 kHz. |
|
MPEG-4 HE AAC Profile (AAC+) | Obsługa treści mono, stereo, 5.0 i 5.1 ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz. |
|
MPEG-4 HE AACv2 Profile (enhanced AAC+) |
Obsługa treści mono, stereo, 5.0 i 5.1 ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz. |
|
AAC ELD (ulepszona wersja AAC o niskim opóźnieniu) | Obsługa treści mono lub stereo ze standardową częstotliwością próbkowania od 16 do 48 kHz. |
|
USAC | Obsługa treści mono lub stereo z standardową częstotliwością próbkowania od 7,35 do 48 kHz. | MPEG-4 (.mp4, .m4a) |
AMR-NB | 4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz | 3GPP (.3gp) |
AMR-WB | 9 szybkości od 6,60 kbit/s do 23,85 kbit/s z próbkowaniem 16 kHz, zgodnie z definicją w AMR-WB, Adaptive Multi-Rate – kodek mowy szerokopasmowej | 3GPP (.3gp) |
FLAC | W przypadku kodera i dekodera: MUSI być obsługiwany co najmniej tryb mono i stereo. NALEŻY obsługiwać częstotliwości próbkowania do 192 kHz; NALEŻY obsługiwać rozdzielczość 16- i 24-bitową. Obsługa danych audio FLAC 24-bitowych MUSI być dostępna w konfiguracji audio z użyciem liczb zmiennoprzecinkowych. |
|
MP3 | Mono/stereo 8–320 kb/s stała (CBR) lub zmienna szybkość transmisji (VBR) |
|
MIDI | Typ MIDI 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody |
|
Vorbis | Dekodowanie: obsługa treści mono, stereo, 5.0 i 5.1 z częstotliwością próbkowania 8000, 12000, 16000, 24000 i 48000 Hz. Kodowanie: obsługa treści mono i stereo z częstotliwością próbkowania 8000, 12000, 16000, 24000 i 48000 Hz. |
|
PCM/WAVE | Kodek PCM MUSI obsługiwać 16-bitowy linearny PCM i 16-bitowy format zmiennoprzecinkowy. Wyodrębniacz WAVE musi obsługiwać 16-bitowy, 24-bitowy, 32-bitowy liniowy PCM i 32-bitowy zmiennoprzecinkowy (szybkość do limitu sprzętowego). Częstotliwości próbkowania MUSZĄ być obsługiwane w zakresie od 8 kHz do 192 kHz. | WAVE (.wav) |
Opus | Dekodowanie: obsługa treści mono, stereo, 5.0 i 5.1 z częstotliwością próbkowania 8000, 12000, 16000, 24000 i 48000 Hz. Kodowanie: obsługa treści mono i stereo z częstotliwością próbkowania 8000, 12000, 16000, 24000 i 48000 Hz. |
|
5.1.4. Kodowanie obrazu
Więcej informacji znajdziesz w sekcji 5.1.6. Szczegóły kodeków obrazu.
Implementacje urządzeń MUSZĄ obsługiwać kodowanie tych typów obrazów:
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
Jeśli implementacje urządzeń obsługują kodowanie HEIC za pomocą android.media.MediaCodec
dla typu multimediów MIMETYPE_IMAGE_ANDROID_HEIC
, to:
- [C-1-1] MUSI zawierać koder HEVC z przyspieszeniem sprzętowym, który obsługuje
BITRATE_MODE_CQ
szybkość transmisji bitów, profilHEVCProfileMainStill
i rozmiar kadru 512 × 512 pikseli.
5.1.5. Dekodowanie obrazu
Więcej informacji znajdziesz w sekcji 5.1.6. Szczegóły kodeków obrazu.
Implementacje urządzeń MUSZĄ obsługiwać dekodowanie tych typów 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] Nieprzetworzone
Jeśli implementacje urządzeń obsługują dekodowanie wideo HEVC, muszą: * [C-1-1] MUSI obsługiwać dekodowanie obrazu HEIF (HEVC).
Dekodery obrazu obsługujące format o wysokiej głębi bitowej (co najmniej 9 bitów na kanał):
- [C-2-1] MUSI obsługiwać format wyjściowy 8-bitowy, jeśli aplikacja tego zażąda, na przykład za pomocą konfiguracji
ARGB_8888
android.graphics.Bitmap
.
5.1.6. Szczegóły kodeków obrazów
Format/kodek | Szczegóły | Obsługiwane typy plików i formaty kontenerów |
---|---|---|
JPEG | Podstawowe + progresywne | 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) |
kodery i dekodery obrazów udostępnione za pomocą interfejsu MediaCodec API;
[C-1-1] MUSI obsługiwać elastyczny format kolorów YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) za pomocąCodecCapabilities
.[C-SR-1] BARDZO ZALECANA obsługa formatu kolorów RGB888 w przypadku trybu wejściowego Surface.
[C-1-3] MUSI obsługiwać co najmniej jeden z formatów planarnych lub półpłaskich YUV420 8:8:8:
COLOR_FormatYUV420PackedPlanar
(równoważnyCOLOR_FormatYUV420Planar
) lubCOLOR_FormatYUV420PackedSemiPlanar
(równoważnyCOLOR_FormatYUV420SemiPlanar
). Zdecydowanie zaleca się obsługę obu formatów.
5.1.7. Kodeki wideo
- Aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo i usług wideokonferencji, implementacje urządzeń powinny używać sprzętowego kodeka VP8, który spełnia wymagania.
Jeśli implementacje na urządzeniu obejmują dekoder lub koder wideo:
[C-1-1] Kodeki wideo MUSZĄ obsługiwać rozmiary buforów bajtów wejścia i wyjścia, które umożliwiają obsługę największych możliwych ramek skompresowanych i nieskompresowanych zgodnie ze standardem i konfiguracją, ale też nie mogą przydzielać zbyt dużo zasobów.
[C-1-2] Kodery i dekodery wideo MUSZĄ obsługiwać elastyczne formaty kolorów YUV420 8:8:8 (
COLOR_FormatYUV420Flexible
) za pomocąCodecCapabilities
.[C-1-3] Kodery i dekodery wideo MUSZĄ obsługiwać co najmniej jeden z formatów kolorów planarnych lub semiplanarnych YUV420 8:8:8:
COLOR_FormatYUV420PackedPlanar
(równoważnyCOLOR_FormatYUV420Planar
) lubCOLOR_FormatYUV420PackedSemiPlanar
(równoważnyCOLOR_FormatYUV420SemiPlanar
). ZALECAMY obsługę obu formatów.[C-SR-1] W przypadku koderów i dekoderów wideo MOCNO zaleca się obsługę co najmniej jednego z formatów obrazu płaskiego lub półpłaskiego YUV420 8:8:8 zoptymalizowanego sprzętowo (YV12, NV12, NV21 lub równoważny format zoptymalizowany przez producenta).
[C-1-5] Dekodery wideo obsługujące format o wysokiej głębi bitowej (9 i więcej bitów na kanał) MUSZĄ obsługiwać format 8-bitowy, jeśli zostanie to zażądane przez aplikację. Musi to być odzwierciedlone przez obsługę formatu kolorów YUV420 8:8:8 za pomocą
android.media.MediaCodecInfo
.
Jeśli implementacje urządzeń reklamują obsługę profilu HDR za pomocą Display.HdrCapabilities
, muszą:
- [C-2-1] MUSI obsługiwać analizowanie i obsługę statycznych metadanych HDR.
Jeśli implementacje urządzeń reklamują obsługę odświeżania w ramach FEATURE_IntraRefresh
w klasie MediaCodecInfo.CodecCapabilities
, to:
- [C-3-1] MUSI obsługiwać okresy odświeżania w zakresie 10–60 ramek i działać prawidłowo w granicach 20% skonfigurowanego okresu odświeżania.
O ile aplikacja nie określi inaczej za pomocą klucza formatu KEY_COLOR_FORMAT
, implementacje dekodera wideo:
- [C-4-1] NALEŻY ustawić domyślnie format kolorów zoptymalizowany pod kątem wyświetlacza sprzętowego, jeśli został skonfigurowany przy użyciu wyjścia Surface.
- [C-4-2] NALEŻY domyślnie ustawić format kolorów YUV420 8:8:8 zoptymalizowany pod kątem odczytu przez procesor, jeśli nie ma być używane wyjście Surface.
5.1.8. Lista kodeków wideo
Format/kodek | Szczegóły | Typy plików lub formaty kontenerów, które mają być obsługiwane |
---|---|---|
H.263 |
|
|
H.264 AVC | Więcej informacji znajdziesz w sekcji 5.2 i 5.3. |
|
H.265 HEVC | Więcej informacji znajdziesz w sekcji 5.3. |
|
MPEG-2 | Profil główny |
|
MPEG-4 SP |
|
|
VP8 | Więcej informacji znajdziesz w sekcji 5.2 i 5.3. |
|
VP9 | Więcej informacji znajdziesz w sekcji 5.3. |
|
5.1.9. Zabezpieczenia kodeka multimediów
Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń kodeków multimedialnych opisanymi poniżej.
Android obsługuje interfejs OMX, który jest wieloplatformowym interfejsem API przyspieszającym multimedia, a także interfejs Codec 2.0, który jest interfejsem API przyspieszającym multimedia z małym obciążeniem.
Jeśli implementacje urządzeń obsługują multimedia, mogą:
- [C-1-1] MUSI obsługiwać kodeki multimedialne za pomocą interfejsów OMX lub Codec 2.0 (lub obu), tak jak w Android Open Source Project, oraz nie może wyłączać ani obchodzić zabezpieczeń. Nie oznacza to, że każdy kodek MUSI używać interfejsu OMX lub Codec 2.0 API, tylko że MUSI być dostępna obsługa co najmniej jednego z tych interfejsów API, a obsługa dostępnych interfejsów API MUSI uwzględniać obecne zabezpieczenia.
- [C-SR-1] MOCNO zalecamy uwzględnienie obsługi interfejsu Codec 2.0 API.
Jeśli implementacje urządzeń nie obsługują interfejsu Codec 2.0 API:
- [C-2-1] W przypadku każdego formatu i typu multimediów (kodowania lub dekodowania) obsługiwanego przez urządzenie należy DODAWAĆ odpowiedni kodek oprogramowania OMX z projektu Android Open Source (jeśli jest dostępny).
- [C-2-2] Kodeki, których nazwy zaczynają się od „OMX.google.” MUSI być oparty na kodzie źródłowym projektu Android Open Source.
- [C-SR-2] ZALECAMY, aby kodeki oprogramowania OMX działały w procesie kodeka, który nie ma dostępu do sterowników sprzętowych innych niż mapery pamięci.
Jeśli implementacje na urządzeniu obsługują interfejs Codec 2.0 API, to:
- [C-3-1] MUSI zawierać odpowiedni kodek oprogramowania Codec 2.0 z Android Open Source Project (jeśli jest dostępny) dla każdego formatu i typu multimediów (kodowania lub dekodowania) obsługiwanego przez urządzenie.
- [C-3-2] Musisz umieścić kodeki programowe Codec 2.0 w procesie obsługi kodeków programowych zgodnie z informacjami podanymi w projekcie Android Open Source, aby umożliwić bardziej szczegółowe przyznawanie dostępu do kodeków programowych.
- [C-3-3] Kodeki, których nazwy zaczynają się od „c2.android. MUSI być oparty na kodzie źródłowym projektu Android Open Source.
5.1.10. Charakterystyka kodeka multimediów
Jeśli implementacje urządzeń obsługują kodeki multimedialne, to:
- [C-1-1] MUSI zwracać prawidłowe wartości charakterystyki kodeka multimediów za pomocą interfejsu API
MediaCodecInfo
.
W szczególności:
- [C-1-2] Kodeki o nazwach zaczynających się od „OMX”. MUSI używać interfejsów API OMX i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa OMX IL.
- [C-1-3] Kodeki o nazwach zaczynających się od „c2”. MUSI używać interfejsu Codec 2.0 API i mieć nazwy zgodne ze wskazówkami dotyczącymi nazewnictwa w Codec 2.0 na Androida.
- [C-1-4] Kodeki o nazwach zaczynających się od „OMX.google.” lub „c2.android.” NIE można ich opisywać jako produktów danego dostawcy ani przyspieszonych sprzętowo.
- [C-1-5] Kodeki, które działają w procesie kodeka (dostawcy lub systemu) i mają dostęp do sterowników sprzętowych innych niż przydzielacze i mapery pamięci, NIE MOGĄ być opisane jako oprogramowanie.
- [C-1-6] Kodeki, których nie ma w projekcie Android Open Source lub które nie są oparte na kodzie źródłowym w tym projekcie, MUSZĄ być opisane jako pochodzące od dostawcy.
- [C-1-7] Kodek, który korzysta z akceleracji sprzętowej, MUSI być opisany jako korzystający z akceleracji sprzętowej.
- [C-1-8] Nazwy kodeków NIE MOGĄ wprowadzać w błąd. Na przykład kodeki o nazwie „decoders” MUSZĄ obsługiwać dekodowanie, a kodeki o nazwie „encoders” MUSZĄ obsługiwać kodowanie. Kodeki o nazwach zawierających formaty multimediów MUSZĄ obsługiwać te formaty.
Jeśli implementacje na urządzeniu obsługują kodeki wideo:
- [C-2-1] Wszystkie kodeki wideo MUSZĄ publikować dane dotyczące osiągalnej liczby klatek na sekundę w przypadku tych rozmiarów, jeśli są obsługiwane przez dany kodek:
SD (niska jakość) | SD (wysoka jakość) | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|---|
Rozdzielczość wideo |
|
|
|
1920 x 1080 pikseli (inne niż MPEG4) | 3840 x 2160 pikseli (HEVC, VP9) |
- [C-2-2] Kodek wideo, który jest przyspieszany sprzętowo, MUSI publikować informacje o punktach wydajności. Muszą one zawierać wszystkie obsługiwane standardowe punkty danych o wydajności (wymienione w interfejsie API
PerformancePoint
), chyba że są one objęte innym obsługiwanym standardowym punktem danych o wydajności. - Dodatkowo powinni publikować rozszerzone punkty skuteczności, jeśli obsługują trwałą skuteczność filmu inną niż standardowa.
5.2. Kodowanie wideo
Jeśli implementacje urządzeń obsługują dowolny koder wideo i udostępniają go aplikacjom innych firm, muszą:
- W ciągu 2 przesuwających się okien nie powinna przekraczać o więcej niż 15% szybkości transmisji danych między interwałami klatek wewnątrzramkowych (I-frame).
- Nie powinna przekraczać 100% szybkości transmisji w przesuwalnym oknie 1 sekundy.
Jeśli implementacje urządzeń zawierają wbudowany wyświetlacz z przekątną co najmniej 6,35 cm lub mają port wyjścia wideo albo deklarują obsługę kamery za pomocą flagi funkcji android.hardware.camera.any
, muszą:
- [C-1-1] MUSI obsługiwać co najmniej 1 kodek wideo VP8 lub H.264 i udostępniać go aplikacjom innych firm.
- NALEŻY obsługiwać kodery wideo VP8 i H.264 oraz udostępniać je aplikacjom innych firm.
Jeśli implementacje urządzeń obsługują dowolny z enkoderów H.264, VP8, VP9 lub HEVC i udostępniają je aplikacjom innych firm, muszą:
- [C-2-1] Musi obsługiwać dynamicznie konfigurowalne szybkości transmisji.
- POWINIEN obsługiwać zmienne liczby klatek, przy czym koder wideo POWINIEN określać bieżący czas trwania klatki na podstawie sygnałów czasowych buforów wejściowych i przydzielać bity na podstawie tego czasu trwania.
Jeśli implementacje urządzeń obsługują koder wideo MPEG-4 SP i udostępniają go aplikacjom innych firm, mogą:
- Powinien obsługiwać dynamicznie konfigurowalne bitrate’y dla obsługiwanego kodera.
Jeśli implementacje urządzeń zapewniają kodery wideo lub obrazów przyspieszone sprzętowo i obsługują co najmniej 1 podłączoną lub wpinaną kamerę sprzętową udostępnioną przez interfejsy API android.camera
:
- [C-4-1] Wszystkie enkodery wideo i obrazów przyspieszone sprzętowo MUSZĄ obsługiwać kodowanie klatek z kamery sprzętowej.
- NALEŻY obsługiwać kodowanie klatek z kamer sprzętowych za pomocą wszystkich koderów wideo lub obrazów.
Jeśli implementacje na urządzeniach obsługują kodowanie HDR, to:
- [C-SR-1] MOCNO zalecamy udostępnienie wtyczki dla interfejsu API płynnego transkodowania, aby przekonwertować format HDR na SDR.
5.2.1. H.263
Jeśli implementacje urządzeń obsługują kodery H.263 i udostępniają je aplikacjom innych firm, mogą:
- [C-1-1] Musi obsługiwać profil podstawowy na poziomie 45.
- Powinien obsługiwać dynamicznie konfigurowalne bitrate’y dla obsługiwanego kodera.
5.2.2. H.264
Jeśli implementacje urządzeń obsługują kodek H.264, to:
- [C-1-1] Musi obsługiwać profil podstawowy poziomu 3. Obsługa ASO (dowolne sortowanie segmentów), FMO (elastyczne sortowanie makrobloków) i RS (niepotrzebne segmenty) jest jednak OPCJONALNA. Ponadto w celu zachowania zgodności z innymi urządzeniami z Androidem zalecamy, aby kodery nie używały profili A/50, A/500 i A/5000.
- [C-1-2] MUSI obsługiwać profile kodowania filmów w standardowej rozdzielczości (SD) wymienione w tabeli poniżej.
- Powinien obsługiwać poziom profilu głównego 4.
- Powinien obsługiwać profile kodowania filmów HD (wysokiej rozdzielczości) zgodnie z tabelą poniżej.
Jeśli implementacje urządzeń zgłaszają obsługę kodowania H.264 dla filmów w rozdzielczości 720p lub 1080p za pomocą interfejsów API multimediów, to:
- [C-2-1] MUSI obsługiwać profile kodowania podane w tabeli poniżej.
SD (niska jakość) | SD (wysoka jakość) | HD – 720p | HD – 1080p | |
---|---|---|---|---|
Rozdzielczość wideo | 320 x 240 pikseli | 720 x 480 piks. | 1280 x 720 pikseli | 1920 x 1080 piks. |
liczba klatek na sekundę, | 20 kl./s | 30 klatek/s | 30 klatek/s | 30 klatek/s |
Szybkość transmisji wideo | 384 kbps | 2 Mb/s | 4 Mb/s | 10 Mb/s |
5.2.3. VP8
Jeśli implementacje urządzeń obsługują kodek VP8, to:
- [C-1-1] MUSI obsługiwać profile kodowania SD.
- NALEŻY obsługiwać te profile kodowania filmów w wysokiej rozdzielczości (HD).
- [C-1-2] Musi obsługiwać zapisywanie plików Matroska WebM.
- NALEŻY zapewnić sprzętowy kodek VP8, który spełnia wymagania projektu WebM dotyczące kodowania RTC na sprzęcie, aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo i usług wideokonferencji.
Jeśli implementacje urządzeń zgłaszają obsługę kodowania VP8 dla filmów w rozdzielczości 720p lub 1080p za pomocą interfejsów API multimediów, to:
- [C-2-1] MUSI obsługiwać profile kodowania podane w tabeli poniżej.
SD (niska jakość) | SD (wysoka jakość) | HD – 720p | HD – 1080p | |
---|---|---|---|---|
Rozdzielczość wideo | 320 x 180 pikseli | 640 x 360 pikseli | 1280 x 720 pikseli | 1920 x 1080 piks. |
liczba klatek na sekundę, | 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, to:
- [C-1-2] Musi obsługiwać profil 0 na poziomie 3.
- [C-1-1] MUSI obsługiwać zapisywanie plików WebM w formacie Matroska.
- [C-1-3] MUSI generować dane CodecPrivate.
- NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
- [C-SR-1] ZALECAMY, aby w przypadku obecności kodera sprzętowego obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
SD | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|
Rozdzielczość wideo | 720 x 480 piks. | 1280 x 720 pikseli | 1920 x 1080 piks. | 3840 x 2160 pikseli |
liczba klatek na sekundę, | 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 na urządzeniu obsługują Profile 2 lub Profile 3 za pomocą interfejsów Media API:
- Obsługa formatu 12-bitowego jest OPCJONALNA.
5.2.5. H.265
Jeśli implementacje urządzeń obsługują kodek H.265:
- [C-1-1] Musi obsługiwać poziom 3 głównego profilu.
- NALEŻY obsługiwać profile kodowania HD zgodnie z tabelą poniżej.
- [C-SR-1] MOCNO zalecamy obsługę profili kodowania HD wskazanych w tabeli poniżej, jeśli istnieje sprzętowy koder.
SD | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|
Rozdzielczość wideo | 720 x 480 piks. | 1280 x 720 pikseli | 1920 x 1080 piks. | 3840 x 2160 pikseli |
liczba klatek na sekundę, | 30 klatek/s | 30 klatek/s | 30 klatek/s | 30 klatek/s |
Szybkość transmisji wideo | 1,6 Mb/s | 4 Mb/s | 5 Mb/s | 20 Mb/s |
5.3. Dekodowanie wideo
Jeśli implementacje urządzeń obsługują kodeki VP8, VP9, H.264 lub H.265, to:
- [C-1-1] MUSI obsługiwać dynamiczne przełączanie rozdzielczości i liczby klatek na sekundę za pomocą standardowych interfejsów API Androida w ramach tego samego strumienia dla wszystkich kodeków VP8, VP9, H.264 i H.265 w czasie rzeczywistym oraz do maksymalnej rozdzielczości obsługiwanej przez każdy z kodeków na urządzeniu.
5.3.1. MPEG-2
Jeśli implementacje urządzeń obsługują dekodery MPEG-2, to:
- [C-1-1] Musi obsługiwać profil główny na wysokim poziomie.
5.3.2. H.263
Jeśli implementacje urządzeń obsługują dekodery H.263, to:
- [C-1-1] Musi obsługiwać poziom profilu podstawowego 30 i 45.
5.3.3. MPEG-4
W przypadku implementacji dekoderów MPEG-4 na urządzeniach:
- [C-1-1] Musi obsługiwać profil prosty poziomu 3.
5.3.4. H.264
Jeśli implementacje urządzeń obsługują dekodery H.264, to:
- [C-1-1] Musi obsługiwać profil główny na poziomie 3.1 i profil podstawowy. Obsługa ASO (dowolne sortowanie segmentów), FMO (elastyczne sortowanie makrobloków) i RS (niepotrzebne segmenty) jest OPCJONALNA.
- [C-1-2] MUSI być w stanie dekodować filmy z profilami SD (standardowa rozdzielczość) wymienionymi w poniższej tabeli i zakodowanymi za pomocą profilu podstawowego i profilu głównego poziomu 3.1 (w tym 720p30).
- Powinien być w stanie dekodować filmy z profilami HD (High Definition) zgodnie z tabelą poniżej.
Jeśli wysokość zwracana przez metodę Display.getSupportedModes()
jest równa lub większa niż rozdzielczość filmu, implementacje na urządzeniu:
- [C-2-1] MUSI obsługiwać profile dekodowania wideo HD 720p podane w tabeli.
- [C-2-2] MUSI obsługiwać profile dekodowania wideo HD 1080p podane w tabeli.
SD (niska jakość) | SD (wysoka jakość) | HD – 720p | HD – 1080p | |
---|---|---|---|---|
Rozdzielczość wideo | 320 x 240 pikseli | 720 x 480 piks. | 1280 x 720 pikseli | 1920 x 1080 piks. |
liczba klatek na sekundę, | 30 klatek/s | 30 klatek/s | 60 kl./s | 30 kl./s (60 kl./stelewizor) |
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 oraz profile dekodowania wideo SD zgodnie z danymi w tabeli poniżej.
- NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
- [C-1-2] MUSI obsługiwać profile dekodowania HD zgodnie z tabelą poniżej, jeśli jest dostępny dekoder sprzętowy.
Jeśli wysokość zwracana przez metodę Display.getSupportedModes()
jest równa lub większa niż rozdzielczość filmu:
- [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden z formatów H.265 lub VP9 do dekodowania profili 720, 1080 i UHD.
SD (niska jakość) | SD (wysoka jakość) | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|---|
Rozdzielczość wideo | 352 x 288 pikseli | 720 x 480 piks. | 1280 x 720 pikseli | 1920 x 1080 piks. | 3840 x 2160 pikseli |
liczba klatek na sekundę, | 30 klatek/s | 30 klatek/s | 30 klatek/s | 30/60 kl./s (60 kl./s telewizor z dekodowaniem sprzętowym H.265) | 60 kl./s |
Szybkość transmisji wideo | 600 Kb/s | 1,6 Mb/s | 4 Mb/s | 5 Mb/s | 20 Mb/s |
Jeśli implementacje urządzeń twierdzą, że obsługują profil HDR za pomocą interfejsów API Media:
- [C-3-1] Implementacje urządzeń MUSZĄ akceptować wymagane metadane HDR z aplikacji, a także obsługiwać wyodrębnianie i wyprowadzanie wymaganych metadanych HDR z bitowego strumienia danych lub kontenera.
- [C-3-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).
5.3.6. VP8
Jeśli implementacje urządzeń obsługują kodek VP8, to:
- [C-1-1] MUSI obsługiwać profile dekodowania SD podane w tabeli poniżej.
- NALEŻY użyć sprzętowego kodeka VP8, który spełnia wymagania.
- NALEŻY obsługiwać profile dekodowania HD podane w tabeli poniżej.
Jeśli wysokość podana przez metodę Display.getSupportedModes()
jest równa lub większa niż rozdzielczość filmu:
- [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać profile 720p podane w tabeli poniżej.
- [C-2-2] Implementacje urządzeń MUSZĄ obsługiwać profile 1080p wymienione w poniższej tabeli.
SD (niska jakość) | SD (wysoka jakość) | HD – 720p | HD – 1080p | |
---|---|---|---|---|
Rozdzielczość wideo | 320 x 180 pikseli | 640 x 360 pikseli | 1280 x 720 pikseli | 1920 x 1080 piks. |
liczba klatek na sekundę, | 30 klatek/s | 30 klatek/s | 30 kl./s (60 kl./stelewizor) | 30 (60 fps, telewizor) |
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, to:
- [C-1-1] MUSI obsługiwać profile dekodowania SD zgodnie z podanymi w poniższej tabeli.
- NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
Jeśli implementacje urządzeń obsługują kodek VP9 i dekoder sprzętowy:
- [C-2-1] MUSI obsługiwać profile dekodowania HD zgodnie z podanymi w tabeli poniżej.
Jeśli wysokość zwracana przez metodę Display.getSupportedModes()
jest równa lub większa niż rozdzielczość filmu:
- [C-3-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden z formatów VP9 lub H.265 do dekodowania profili 720, 1080 i UHD.
SD (niska jakość) | SD (wysoka jakość) | HD – 720p | HD – 1080p | UHD | |
---|---|---|---|---|---|
Rozdzielczość wideo | 320 x 180 pikseli | 640 x 360 pikseli | 1280 x 720 pikseli | 1920 x 1080 piks. | 3840 x 2160 pikseli |
liczba klatek na sekundę, | 30 klatek/s | 30 klatek/s | 30 klatek/s | 30 kl./s (60 kl./s telewizor z dekodowaniem sprzętowym VP9) | 60 kl./s |
Szybkość transmisji wideo | 600 Kb/s | 1,6 Mb/s | 4 Mb/s | 5 Mb/s | 20 Mb/s |
Jeśli implementacje urządzeń twierdzą, że obsługują VP9Profile2
lub VP9Profile3
za pomocą interfejsów API mediów 'CodecProfileLevel':
- Obsługa formatu 12-bitowego jest OPCJONALNA.
Jeśli implementacje urządzeń zgłaszają obsługę profilu HDR (VP9Profile2HDR
,
VP9Profile2HDR10Plus
, VP9Profile3HDR
, VP9Profile3HDR10Plus
) za pomocą interfejsów 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ą też obsługiwać wyodrębnianie i wyprowadzanie wymaganych metadanych HDR z bitowego strumienia danych lub kontenera. - [C-4-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).
5.3.8. Dolby Vision
Jeśli implementacje urządzeń deklarują obsługę dekodera Dolby Vision za pomocą interfejsu HDR_TYPE_DOLBY_VISION
, to:
- [C-1-1] MUSISZ podać narzędzie do wyodrębniania obsługujące Dolby Vision.
- [C-1-2] MUSI prawidłowo wyświetlać treści Dolby Vision na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).
- [C-1-3] Identyfikator ścieżki warstw podstawowych zgodnych z wsteczniejszymi wersjami (jeśli występują) MUSI być taki sam jak identyfikator ścieżki połączonej warstwy Dolby Vision.
5.3.9. AV1
Jeśli implementacje urządzeń obsługują kodek AV1, to:
- [C-1-1] MUSI obsługiwać profil 0, w tym treści 10-bitowe.
5.4. Nagrywanie dźwięku
Chociaż niektóre wymagania opisane w tej sekcji są oznaczone jako „NALEŻY”, od Androida 4.3 planujemy zmienić je na „MUSI”. W przypadku istniejących i nowych urządzeń z Androidem ZALECAMY spełnienie tych wymagań, które są oznaczone jako „NALEŻY”, ponieważ w przeciwnym razie nie będą one zgodne z Androidem po aktualizacji do przyszłej wersji.
5.4.1. Przechwytywanie nieprzetworzonego dźwięku i informacje o mikrofonie
Jeśli implementacje na urządzeniu deklarują android.hardware.microphone
, to:
[C-1-1] MUST allow capture of raw audio content for any
AudioRecord
orAAudio
INPUT stream that is opened successfully. Muszą być obsługiwane co najmniej te cechy:- Format: Linear PCM, 16-bit
- Częstotliwości próbkowania: 8000, 11025, 16000, 44100, 48000 Hz
- Kanały: mono
- Źródła dźwięku:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, lubVOICE_PERFORMANCE
. Dotyczy to też odpowiednich wstępnych ustawień wejścia wAAudio
, na przykładAAUDIO_INPUT_PRESET_CAMCORDER
.
NALEŻY zezwolić na rejestrowanie surowych treści audio o tych cechach:
- Format: PCM liniowy, 16- i 24-bitowy
- Częstotliwości próbkowania: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
- Kanały: tyle kanałów, ile mikrofonów jest na urządzeniu.
[C-1-2] NALEŻY nagrywać z wykorzystaniem współczynników próbkowania wyższych niż 48 kHz bez interpolacji.
[C-1-3] NALEŻY użyć odpowiedniego filtra antyaliasingu, gdy wymienione powyżej częstotliwości próbkowania są rejestrowane z użyciem próbkowania w dół.
POWINNA umożliwiać rejestrowanie surowych treści audio w jakości radia AM i DVD, co oznacza te cechy:
- Format: Linear PCM, 16-bitowy
- Częstotliwości próbkowania: 22050, 48000 Hz
- Kanały: stereo
[C-1-4] MUSI obsługiwać interfejs API
MicrophoneInfo
i odpowiednio wypełniać informacje o dostępnych mikrofonach na urządzeniu, które są dostępne dla aplikacji innych firm za pomocą interfejsu APIAudioManager.getMicrophones()
, w przypadku aktywnego AudioRecord za pomocąMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
lubVOICE_PERFORMANCE
.
Jeśli implementacje urządzeń umożliwiają przechwytywanie nieprzetworzonych treści audio w jakości radia AM i DVD, mogą:
- [C-2-1] NALEŻY nagrywać bez próbkowania w górę w dowolnym formacie wyższym niż 16000:22050 lub 44100:48000.
- [C-2-2] MUSI zawierać odpowiedni filtr antyaliasingu w przypadku próbkowania w górę lub w dół.
5.4.2. Przechwytywanie danych do rozpoznawania głosu
Jeśli implementacje na urządzeniu deklarują android.hardware.microphone
, to:
- [C-1-1] MUST capture
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
audio source at one of the sampling rates, 44100 and 48000. - [C-1-2] Domyślnie należy wyłączyć wszelkie przetwarzanie dźwięku w celu redukcji szumów podczas nagrywania strumienia audio z źródła
AudioSource.VOICE_RECOGNITION
. [C-1-3] Domyślnie należy wyłączyć automatyczne sterowanie wzmocnieniem podczas nagrywania strumienia audio z źródła audio
AudioSource.VOICE_RECOGNITION
.Powinny wykazywać w zakresie średnich częstotliwości w przybliżeniu płaskie charakterystyki amplitudy w funkcji częstotliwości: konkretnie ±3 dB od 100 Hz do 4000 Hz dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania głosu.
[C-SR-1] ZALECAMY, aby poziomy amplitudy w zakresie niskich częstotliwości (szczególnie w zakresie ±20 dB od 30 Hz do 100 Hz) były porównywalne z zakresem średnich częstotliwości w przypadku każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania głosu.
[C-SR-2] ZALECAMY, aby poziomy amplitudy w zakresie wysokich częstotliwości wynosiły ±30 dB w zakresie od 4000 Hz do 22 kHz w porównaniu z zakresem średnich częstotliwości w przypadku każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania mowy.
NALEŻY ustawić czułość wejścia audio tak, aby źródło tonów sinusoidalnych o częstotliwości 1000 Hz odtwarzane z poziomem ciśnienia akustycznego (SPL) wynoszącym 90 dB (zmierzonym obok mikrofonu) miało idealną wartość RMS 2500 w zakresie 1770–3530 dla próbek 16-bitowych (lub -22,35 dB ±3 dB dla pełnej skali z liczeniem zmiennoprzecinkowym/podwójnej precyzji dla próbek) dla każdego mikrofonu używanego do nagrywania źródła audio rozpoznawania głosu.
NALEŻY nagrywać strumień audio do rozpoznawania mowy tak, aby poziomy amplitudy PCM śledziły liniowo zmiany SPL wejścia w zakresie co najmniej 30 dB od -18 do +12 dB w porównaniu z 90 dB SPL w mikrofonie.
NALEŻY nagrywać strumień audio do rozpoznawania głosu z całkowitym zniekształceniem harmonicznym (THD) mniejszym niż 1% dla 1 kHz przy poziomie wejściowym 90 dB SPL na mikrofonie.
Jeśli implementacje na urządzeniach deklarują android.hardware.microphone
i technologię tłumienia szumów (redukcji) dostosowaną do rozpoznawania mowy, to:
- [C-2-1] NALEŻY zezwolić na sterowanie tym efektem dźwiękowym za pomocą interfejsu API
android.media.audiofx.NoiseSuppressor
. - [C-2-2] Identyfikuj jednoznacznie każdą implementację technologii redukcji szumów za pomocą pola
AudioEffect.Descriptor.uuid
.
5.4.3. Przechwytywanie w celu przekierowania odtwarzania
Klasa android.media.MediaRecorder.AudioSource
zawiera źródło audio REMOTE_SUBMIX
.
Jeśli implementacje urządzeń deklarują zarówno android.hardware.audio.output
, jak i android.hardware.microphone
, to:
[C-1-1] NALEŻY prawidłowo zaimplementować źródło dźwięku
REMOTE_SUBMIX
, aby aplikacja korzystająca z interfejsu APIandroid.media.AudioRecord
do nagrywania z tego źródła dźwięku rejestrowała miks wszystkich strumieni audio, z wyjątkiem:AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. Usuwanie echa akustycznego
Jeśli implementacje na urządzeniu deklarują android.hardware.microphone
, to:
- NALEŻY zastosować technologię usuwania echa akustycznego (AEC) dostosowaną do komunikacji głosowej i zastosowanej do ścieżki przechwytywania podczas przechwytywania za pomocą
AudioSource.VOICE_COMMUNICATION
.
Jeśli implementacje urządzeń zapewniają funkcję usuwania echa akustycznego, która jest wstawiana na ścieżce przechwytywania dźwięku po wybraniu opcji AudioSource.VOICE_COMMUNICATION
, to:
- [C-SR-1] Z_MOCNO_ZALECANE jest zadeklarowanie tego za pomocą metody AcousticEchoCanceler API AcousticEchoCanceler.isAvailable()
- [C-SR-2] ZALECAMY, aby ten efekt dźwiękowy był możliwy do kontrolowania za pomocą interfejsu API AcousticEchoCanceler.
- [C-SR-3] ZALECAMY jednoznaczne identyfikowanie każdej implementacji technologii AEC za pomocą pola AudioEffect.Descriptor.uuid.
5.4.5. Jednoczesne nagrywanie
Jeśli implementacje urządzeń deklarują android.hardware.microphone
,MUSZĄ zaimplementować jednoczesne przechwytywanie zgodnie z opisem w tym dokumencie. Więcej szczegółów:
- [C-1-1] MUSI umożliwiać jednoczesny dostęp do mikrofonu przez usługę ułatwień obsługi, która rejestruje dane za pomocą
AudioSource.VOICE_RECOGNITION
, oraz co najmniej 1 aplikacji, która rejestruje dane za pomocą dowolnegoAudioSource
. - [C-1-2] MUSI zezwalać na jednoczesny dostęp do mikrofonu przez wstępnie zainstalowaną aplikację, która pełni rolę Asystenta, oraz co najmniej jedną aplikację rejestrującą z dowolnym uprawnieniem
AudioSource
, z wyjątkiemAudioSource.VOICE_COMMUNICATION
lubAudioSource.CAMCORDER
. - [C-1-3] Podczas nagrywania dźwięku za pomocą funkcji
AudioSource.VOICE_COMMUNICATION
lubAudioSource.CAMCORDER
aplikacja MUSI wyciszyć dźwięk z innych aplikacji (z wyjątkiem aplikacji ułatwień dostępu). Jeśli jednak aplikacja rejestruje dane za pomocą uprawnieniaAudioSource.VOICE_COMMUNICATION
, inna aplikacja może rejestrować połączenia głosowe, jeśli jest to aplikacja uprzywilejowana (wstępnie zainstalowana) z uprawnieniemCAPTURE_AUDIO_OUTPUT
. - [C-1-4] Jeśli 2 lub więcej aplikacji nagrywa jednocześnie i żadna z nich nie ma interfejsu na górze, aplikacja, która rozpoczęła nagrywanie jako ostatnia, odbiera dźwięk.
5.4.6. Poziomy wzmocnienia mikrofonu [przeniesiono do wersji 5.4.2]
5.5. Odtwarzanie dźwięku
Android obsługuje odtwarzanie dźwięku przez peryferyjne urządzenie wyjściowe zgodnie z definicją w sekcji 7.8.2.
5.5.1. Odtwarzanie dźwięku w postaci surowych danych
Jeśli implementacje na urządzeniu deklarują android.hardware.audio.output
, to:
[C-1-1] MUSI umożliwiać odtwarzanie surowego dźwięku z tymi cechami:
- Formaty źródłowe: PCM liniowy, 16-bitowy, 8-bitowy, zmiennoprzecinkowy
- Kanały: mono, stereo, prawidłowe konfiguracje wielokanałowe z maksymalnie 8 kanałami
- Częstotliwości próbkowania (w Hz):
- 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 w przypadku konfiguracji kanałów wymienionych powyżej
- 96000 w mono i stereo
5.5.2. Efekty dźwiękowe
Android udostępnia interfejs API do efektów dźwiękowych na potrzeby implementacji na urządzeniach.
Jeśli implementacje na urządzeniu deklarują funkcję android.hardware.audio.output
, to:
- [C-1-1] Musi obsługiwać implementacje
EFFECT_TYPE_EQUALIZER
iEFFECT_TYPE_LOUDNESS_ENHANCER
, które można kontrolować za pomocą podklas efektów dźwiękowychEqualizer
iLoudnessEnhancer
. - [C-1-2] MUSI obsługiwać implementację interfejsu API wizualizacji, którą można kontrolować za pomocą klasy
Visualizer
. - [C-1-3] MUSI obsługiwać implementację
EFFECT_TYPE_DYNAMICS_PROCESSING
, którą można sterować za pomocą podklasy AudioEffectDynamicsProcessing
. - NALEŻY obsługiwać implementacje
EFFECT_TYPE_BASS_BOOST
,EFFECT_TYPE_ENV_REVERB
,EFFECT_TYPE_PRESET_REVERB
iEFFECT_TYPE_VIRTUALIZER
, które można kontrolować za pomocą podklasAudioEffect
BassBoost
,EnvironmentalReverb
,PresetReverb
iVirtualizer
. - [C-SR-1] Zdecydowanie zalecamy obsługę efektów w postaci liczb zmiennoprzecinkowych i wielokanałowy.
5.5.3. Głośność wyjścia audio
Implementacje na urządzeniach samochodowych:
- NALEŻY umożliwić regulację głośności dźwięku oddzielnie dla każdego strumienia audio, używając typu treści lub użycia zgodnie z definicją
AudioAttributes
oraz użycia dźwięku w samochodzie zgodnie z definicją publicznie dostępną w dokumentacjiandroid.car.CarAudioManager
.
5.5.4. Przesyłanie dźwięku
Jeśli implementacje urządzeń obsługują odtwarzanie z przesłanymi plikami audio, to:
- [C-SR-1] MOCNO POLECAMY przycinanie odtwarzanych treści audio bez przerw między dwoma klipami o tym samym formacie, jeśli jest to określone przez interfejs API AudioTrack gapless i kontener multimediów dla MediaPlayer.
5.6. Opóźnienie dźwięku
Opóźnienie dźwięku to czas opóźnienia sygnału dźwiękowego w systemie. Wiele klas aplikacji wymaga niskich opóźnień, aby uzyskać efekty dźwiękowe w czasie rzeczywistym.
W rozumieniu tego punktu stosuje się następujące definicje:
- opóźnienie wyjścia. Interval między zapisaniem przez aplikację ramki danych kodowanych w formacie PCM a momentem, w którym odpowiedni dźwięk jest prezentowany otoczeniu przez przetwornik na urządzeniu lub sygnał opuszcza urządzenie przez port i może być obserwowany zewnętrznie.
- opóźnienie zimnego wyjścia. Czas między rozpoczęciem strumienia wyjściowego a czasem wyświetlenia pierwszej ramki na podstawie sygnatur czasowych, gdy system wyjścia audio był nieaktywny i wyłączony przed żądaniem.
- ciągły czas oczekiwania na dane wyjściowe. Opóźnienie wyjściowe kolejnych klatek po rozpoczęciu odtwarzania dźwięku przez urządzenie.
- opóźnienie reakcji. Interval między momentem, w którym dźwięk jest prezentowany przez środowisko na urządzeniu do przetwornika na urządzeniu lub sygnał dostaje się na urządzenie przez port, a aplikacja odczytuje odpowiednią ramkę danych kodowanych w formacie PCM.
- utracił(a) dane wejściowe. Początkowa część sygnału wejściowego, która jest nieprzydatna lub niedostępna.
- Opóźnienie w przypadku zimnego wejścia. Czas między rozpoczęciem strumienia a otrzymaniem pierwszego prawidłowego kadru, gdy system wejścia dźwięku był nieaktywny i wyłączony przed wysłaniem żądania.
- ciągłe opóźnienie wejścia. Opóźnienie wejścia w przypadku kolejnych klatek podczas rejestrowania dźwięku przez urządzenie.
- ciągłe opóźnienie w obie strony. Suma opóźnienia ciągłego wejścia i opóźnienia ciągłego wyjścia oraz jeden okres buforowania. Okres buforowania zapewnia aplikacji czas na przetworzenie sygnału i zmniejszenie różnicy fazy między strumieniami wejściowym i wyjściowym.
- OpenSL ES PCM buffer queue API. Zestaw interfejsów API OpenSL ES związanych z PCM w Android NDK.
- AAudio – natywny interfejs API do obsługi dźwięku. Zestaw interfejsów AAudio w Android NDK.
- Sygnatura czasowa. Para składająca się z względnej pozycji klatki w strumieniach i szacowanego czasu, w którym dana klatka wchodzi do potoku przetwarzania audio lub z niego wychodzi na powiązanym urządzeniu końcowym. Zobacz też AudioTimestamp.
- glitch. Tymczasowe przerwanie lub nieprawidłowa wartość próbki w sygnale audio, zwykle spowodowane niedostatecznym wypełnieniem bufora na wyjściu, przepełnieniem bufora na wejściu lub innym źródłem szumu cyfrowego lub analogowego.
- średnie odchylenie bezwzględne. Średnia wartość bezwzględna odchyleń od średniej dla zbioru wartości.
- opóźnienie od kliknięcia do tonu. Czas od momentu dotknięcia ekranu do momentu, gdy głośnik odtworzy dźwięk wygenerowany w wyniku tego dotknięcia.
Jeśli implementacje urządzeń deklarują android.hardware.audio.output
, muszą spełniać te wymagania:
- [C-1-1] Sygnatura czasowa danych wyjściowych zwrócona przez AudioTrack.getTimestamp i
AAudioStream_getTimestamp
jest dokładna do +/- 2 ms. [C-1-2] Opóźnienie wyjścia w przypadku zimnego uruchomienia nie powinno przekraczać 500 ms.
[C-1-3] Otwieranie strumienia wyjściowego za pomocą
AAudioStreamBuilder_openStream()
MUSI zajmować mniej niż 1000 milisekund.
Jeśli implementacje na urządzeniu deklarują android.hardware.audio.output
, to MOCNO ZALECAMY, aby spełniały te wymagania lub je przekraczały:
- [C-SR-1] Opóźnienie wyjścia po uruchomieniu nie większe niż 100 ms na ścieżce danych głośnika.
[C-SR-2] Opóźnienie od dotknięcia do tonu nie większe niż 80 ms.
[C-SR-4] Sygnatura czasowa wyjściowa zwracana przez AudioTrack.getTimestamp i
AAudioStream_getTimestamp
jest z dokładnością do +/- 1 ms.
Jeśli implementacje urządzeń spełniają powyższe wymagania, po początkowej kalibracji przy użyciu natywnego interfejsu API AAudio opóźnienie ciągłego wyjścia i opóźnienie wyjścia po zimnym uruchomieniu na co najmniej 1 obsługiwanym urządzeniu wyjściowym audio wynosi:
- [C-SR-5] ZALECAMY zgłaszanie dźwięku o małej latencji przez zadeklarowanie flagi funkcji
android.hardware.audio.low_latency
. - [C-SR-6] ZALECAMY, aby spełnić wymagania dotyczące dźwięku o niskim opóźnieniu za pomocą interfejsu AAudio API.
- [C-SR-7] MOCNO ZALECAMY, aby w przypadku strumieni zwracających wartość
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
zAAudioStream_getPerformanceMode()
wartość zwracana przezAAudioStream_getFramesPerBurst()
była mniejsza lub równa wartości zwracanej przezandroid.media.AudioManager.getProperty(String)
dla klucza usługiAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
.
Jeśli implementacje na urządzeniach nie spełniają wymagań dotyczących dźwięku o małej latencji za pomocą natywnego interfejsu API AAudio, nie spełniają następujących wymagań:
- [C-2-1] NIE zgłaszaj obsługi dźwięku o małej latencji.
Jeśli implementacje urządzeń obejmują android.hardware.microphone
, muszą spełniać te wymagania dotyczące wejściowego dźwięku:
[C-3-1] Ogranicz błąd w sygnaturach czasowych wejścia zwracanych przez funkcję AudioRecord.getTimestamp lub
AAudioStream_getTimestamp
do +/- 2 ms. „Błąd” oznacza tu odchylenie od prawidłowej wartości.[C-3-2] Opóźnienie wejścia na zimno nie dłuższe niż 500 milisekund.
[C-3-3] Otwieranie strumienia wejściowego za pomocą
AAudioStreamBuilder_openStream()
MUSI zajmować mniej niż 1000 milisekund.
Jeśli implementacje urządzeń obejmują android.hardware.microphone
, to BARDZO ZALECAMY, aby spełniały te wymagania dotyczące dźwięku wejściowego:
[C-SR-8] Opóźnienie w przyjmowaniu danych na zimno nie większe niż 100 ms na ścieżce danych mikrofonu.
[C-SR-11] Ogranicz błąd w danych wejściowych (zwracanych przez AudioRecord.getTimestamp lub
AAudioStream_getTimestamp
) do +/- 1 ms.
Jeśli implementacje na urządzeniu deklarują android.hardware.audio.output
i android.hardware.microphone
, to:
- [C-SR-12] MOCNO ZALECAMY, aby średni czas oczekiwania na obie strony nieprzerywanej transmisji danych nie przekraczał 50 ms w przypadku 5 pomiary, a średnia odchylenie bezwzględne nie przekraczała 10 ms w przypadku co najmniej jednej obsługiwanej ścieżki.
5.7. Protokoły sieciowe
Implementacje na urządzeniach MUSZĄ obsługiwać protokoły sieci multimedialnych do odtwarzania dźwięku i obrazu zgodnie z dokumentacją pakietu Android SDK.
W przypadku każdego kodeka i formatu kontenera, które musi obsługiwać implementacja urządzenia:
[C-1-1] Musi obsługiwać ten kodek lub kontener przez HTTP i HTTPS.
[C-1-2] MUSI obsługiwać odpowiednie formaty segmentów multimediów zgodnie z tabelą formatów segmentów multimediów poniżej w protokole HTTP Live Streaming w wersji 7.
[C-1-3] MUSI obsługiwać odpowiednie formaty danych RTSP, jak pokazano w tabeli RTSP poniżej. Wyjątki znajdziesz w przypisach do tabeli w sekcji 5.1.
Formaty segmentów multimediów
Formaty segmentów | Źródła | Obsługa wymaganych kodeków |
---|---|---|
MPEG-2 Transport Stream | ISO 13818 |
Kodek wideo:
i MPEG-2 znajdziesz w sekcji 5.1.8. Kodeki audio:
|
AAC z ramowaniem ADTS i tagami ID3 | ISO 13818-7 | Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1 . |
WebVTT | WebVTT |
RTSP (RTP, SDP)
Nazwa profilu | Źródła | Obsługa wymaganych kodeków |
---|---|---|
H264 AVC | RFC 6184 | Szczegółowe informacje o H.264 AVC znajdziesz w sekcji 5.1.8. |
MP4A-LATM | RFC 6416 | Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.3. |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
Szczegółowe informacje o H.263 znajdziesz w sekcji 5.1.8. |
H263-2000 | RFC 4629 | Szczegółowe informacje o H.263 znajdziesz w sekcji 5.1.8. |
AMR | RFC 4867 | Szczegółowe informacje o AMR-NB znajdziesz w sekcji 5.1.3. |
AMR-WB | RFC 4867 | Szczegółowe informacje o AMR-WB znajdziesz w sekcji 5.1.3. |
MP4V-ES | RFC 6416 | Szczegółowe informacje o MPEG-4 SP znajdziesz w sekcji 5.1.8. |
mpeg4-generic | RFC 3640 | Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.3. |
MP2T | RFC 2250 | Szczegółowe informacje znajdziesz w sekcji MPEG-2 Transport Stream w sekcji Transmisja na żywo przez HTTP. |
5.8. Secure Media
Jeśli implementacje urządzeń obsługują bezpieczne wyjście wideo i mogą obsługiwać bezpieczne powierzchnie, to:
- [C-1-1] MUSISZ zadeklarować obsługę
Display.FLAG_SECURE
.
Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE
i obsługują protokół wyświetlania bezprzewodowego, to:
- [C-2-1] NALEŻY zabezpieczyć połączenie za pomocą silnego mechanizmu szyfrowania, takiego jak HDCP 2.x lub nowszy, w przypadku wyświetlaczy podłączonych za pomocą protokołów bezprzewodowych, takich jak Miracast.
Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE
i obsługują przewodowy wyświetlacz zewnętrzny, to:
- [C-3-1] MUSI obsługiwać HDCP 1.2 lub nowszą wersję w przypadku wszystkich zewnętrznych wyświetlaczy podłączonych przez port przewodowy dostępny dla użytkownika.
5.9. MusicaI Instrument Digital Interface (MIDI)
Jeśli implementacje urządzeń zgłaszają obsługę funkcji android.software.midi
za pomocą klasy android.content.pm.PackageManager
, to:
[C-1-1] MUSI obsługiwać MIDI przez wszystkie urządzenia transportowe z obsługą MIDI, dla których zapewniają one ogólne połączenia nie-MIDI. Takie urządzenia transportowe:
- Tryb hosta USB, sekcja 7.7
- MIDI przez Bluetooth LE w roli centralnej, sekcja 7.4.3
[C-1-2] MUSI obsługiwać przesyłanie danych MIDI między aplikacjami (wirtualne urządzenia MIDI)
[C-1-3] MUSI zawierać libamidi.so (obsługa MIDI natywnych)
POWINIEN obsługiwać MIDI przez USB w trybie peryferyjnym (sekcja 7.7).
5.10. Profesjonalny dźwięk
Jeśli implementacje na urządzeniach zgłaszają obsługę funkcji
android.hardware.audio.pro
za pomocą klasy android.content.pm.PackageManager, to:
- [C-1-1] MUST report support for feature
android.hardware.audio.low_latency
. - [C-1-2] W przynajmniej jednej obsługiwanej ścieżce opóźnienie w obie strony nie może przekraczać 25 ms.
- [C-1-3] MUSI zawierać port(y) USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
- [C-1-4] MUST report support for feature
android.software.midi
. - [C-1-5] NALEŻY spełnić wymagania dotyczące opóźnień i dźwięku USB za pomocą interfejsu API AAudio native audio i interfejsu
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [C-1-6] Czas opóźnienia wyjściowego w trybie zimnym musi wynosić 200 ms lub mniej.
- [C-1-7] Opóźnienie w przypadku zimnego wejścia musi wynosić 200 ms lub mniej.
- [C-1-8] Średnia wartość opóźnienia od dotknięcia do tonu nie może przekraczać 80 ms w przynajmniej 5 przypadkach pomiarów na ścieżce danych od głośnika do mikrofonu.
- [C-SR-1] ZALECAMY, aby opóźnienie było zgodne z definicją w sekcji 5.6 Opóźnienie sygnału audio, czyli wynosiło 20 ms lub mniej w przypadku 5 pomiary z wartością średniej bezwzględnej odchylenia mniejszą niż 5 ms na ścieżce od głośnika do mikrofonu.
- [C-SR-2] MOCNO zalecamy spełnienie wymagań dotyczących oprogramowania Pro Audio w zakresie opóźnienia dźwięku w obie strony, opóźnienia w przypadku zimnego wejścia i zimnego wyjścia oraz wymagań dotyczących dźwięku przez USB za pomocą interfejsu API AAudio natywnych dźwięku w drodze MMAP.
[C-SR-3] ZALECAMY zapewnienie stałego poziomu wydajności procesora, gdy dźwięk jest aktywny, a obciążenie procesora się zmienia. Należy to przetestować za pomocą aplikacji SynthMark na Androida. SynthMark używa syntezatora oprogramowania działającego na symulowanym środowisku audio, które mierzy wydajność systemu. Aby dowiedzieć się więcej o benchmarkach, zapoznaj się z dokumentacją SynthMark. Aplikację SynthMark należy uruchomić, korzystając z opcji „Automatyczny test”, i uzyskać te wyniki:
- voicemark.90 > 32 głosów
- latencymark.fixed.little <= 15 ms
- latencymark.dynamic.little <= 50 ms
NALEŻY zminimalizować niedokładność zegara audio i jego odchylenia względem czasu standardowego.
NALEŻY zminimalizować przesunięcie zegara dźwięku w stosunku do procesora
CLOCK_MONOTONIC
, gdy oba są aktywne.NALEŻY zminimalizować opóźnienie dźwięku na przetwornikach na urządzeniu.
NALEŻY zminimalizować opóźnienie dźwięku w przypadku dźwięku cyfrowego przez USB.
NALEŻY udokumentować pomiary opóźnienia dźwięku na wszystkich ścieżkach.
NALEŻY zminimalizować jitter w czasie wywołania zwrotnego zakończenia bufora audio, ponieważ wpływa to na użyteczny odsetek pełnej przepustowości procesora w wywołaniu zwrotnym.
W przypadku normalnego użytkowania przy zgłoszonym opóźnieniu nie powinno być żadnych zakłóceń dźwięku.
NALEŻY zapewnić zerową różnicę opóźnień między kanałami.
NALEŻY zminimalizować średni czas oczekiwania MIDI w przypadku wszystkich transportów.
NALEŻY zminimalizować zmienność opóźnienia MIDI pod obciążeniem (jitter) we wszystkich transporcie.
NALEŻY podać dokładne sygnatury czasowe MIDI w przypadku wszystkich transportów.
NALEŻY zminimalizować szum sygnału audio na przetwornikach na urządzeniu, w tym w okresie bezpośrednio po uruchomieniu „na zimno”.
NALEŻY zapewnić zerową różnicę zegara audio między stroną wejściową a wyjściową odpowiednich punktów końcowych, gdy oba są aktywne. Przykładami takich punktów końcowych są mikrofon i głośnik na urządzeniu lub wejście i wyjście gniazda audio.
NALEŻY obsłużyć wywołania zwrotne zakończenia buforowania dźwięku po stronie wejścia i wyjścia odpowiednich punktów końcowych w tym samym wątku, gdy oba są aktywne, oraz wejść do wywołania zwrotnego wyjścia bezpośrednio po powrocie z wywołania zwrotnego wejścia. Jeśli nie można obsłużyć wywołań zwrotnych w tym samym wątku, wywołanie zwrotne wyjścia należy umieścić tuż po wywołaniu zwrotnym wejścia, aby aplikacja miała spójne ustawienia czasu po stronie wejścia i wyjścia.
NALEŻY zminimalizować różnicę faz między buforowaniem dźwięku HAL po stronie wejścia i wyjścia odpowiednich punktów końcowych.
NALEŻY zminimalizować opóźnienie dotykowe.
NALEŻY zminimalizować zmienność opóźnienia dotyku pod obciążeniem (jitter).
Jeśli implementacje urządzeń spełniają wszystkie powyższe wymagania, mogą:
- [C-SR-4] MOCNO ZALECAMY zgłoszenie obsługi funkcji
android.hardware.audio.pro
za pomocą klasyandroid.content.pm.PackageManager
.
Jeśli implementacje urządzeń zawierają 4-żyłowe gniazdo słuchawek 3,5 mm, muszą:
- [C-2-1] Średnie opóźnienie dźwięku w obie strony w ramach ciągłego połączenia, określone w sekcji 5.6 Opóźnienie dźwięku, musi wynosić 20 ms lub mniej w ciągu 5 pomiarów z średnią odchyleniem bezwzględnym poniżej 5 ms na ścieżce gniazda audio przy użyciu dongla audio.
- [C-SR-5] ZALECAMY przestrzeganie sekcji Specyfikacja urządzeń mobilnych (gniazdo) Specyfikacji przewodowych słuchawek nausznych (wersja 1.1).
Jeśli implementacje urządzeń nie mają 4-żyłowego gniazda słuchawek 3,5 mm, a mają porty USB obsługujące tryb hosta USB, to:
- [C-3-1] Musisz zaimplementować klasę audio USB.
- [C-3-2] Średnia opóźnienie audio w ciągłym cyklu przesyłania i odtwarzania musi wynosić 25 ms lub mniej w przypadku 5 pomiary z średnią odchyleniem bezwzględnym poniżej 5 ms w przypadku portu w trybie hosta USB przy użyciu klasy audio USB. (Możesz to sprawdzić, używając adaptera USB-3,5 mm i dongla Audio Loopback lub interfejsu audio USB z kablami patchowymi łączącymi wejścia z wyjściami).
- [C-SR-6] MOCNO zaleca się obsługę do 8 kanałów wejść/wyjść w każdym kierunku, częstotliwość próbkowania 96 kHz oraz głębię 24-bitową lub 32-bitową, gdy urządzenie jest używane z peryferiami audio USB, które również spełniają te wymagania.
- [C-SR-7] MOCNO zalecamy spełnienie tej grupy wymagań za pomocą natywnego interfejsu API AAudio zamiast ścieżki MMAP.
Jeśli implementacje urządzeń zawierają port HDMI, muszą:
- W przynajmniej jednej konfiguracji NALEŻY obsługiwać wyjście stereo i 8 kanałów z głębią bitową 20- lub 24-bitową i częstotliwością próbkowania 192 kHz bez utraty głębi bitowej ani próbkowania.
5.11. Rejestrowanie nieprzetworzonych
Android obsługuje nagrywanie nieprzetworzonego dźwięku za pomocą źródła audio android.media.MediaRecorder.AudioSource.UNPROCESSED
. W OpenSL ES można uzyskać do niego dostęp za pomocą wstępnie ustawionego rekordu SL_ANDROID_RECORDING_PRESET_UNPROCESSED
.
Jeśli implementacje urządzeń mają obsługiwać nieprzetworzone źródło dźwięku i udostępniać je aplikacjom innych firm, muszą:
[C-1-1] NALEŻY zgłaszać obsługę za pomocą właściwości
android.media.AudioManager
PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.[C-1-2] MUSI wykazywać w przybliżeniu płaskie właściwości amplitudy w stosunku do częstotliwości w zakresie średnich częstotliwości: dokładnie ±10 dB od 100 Hz do 7000 Hz dla każdego mikrofonu użytego do nagrywania nieprzetworzonego źródła dźwięku.
[C-1-3] NALEŻY mieć poziomy amplitudy w zakresie niskich częstotliwości: dokładnie ±20 dB od 5 do 100 Hz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.
[C-1-4] NALEŻY mieć poziomy amplitudy w zakresie wysokich częstotliwości: ±30 dB od 7000 Hz do 22 kHz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.
[C-1-5] NALEŻY ustawić czułość wejścia audio tak, aby sygnał sinusoidalny o częstotliwości 1000 Hz odtwarzany z poziomem ciśnienia akustycznego (SPL) wynoszącym 94 dB dawał odpowiedź z wartością RMS wynoszącą 520 dB dla próbek 16-bitowych (lub -36 dB w pełnej skali dla próbek z dokładnością zmiennoprzecinkową/podwójną) dla każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.
[C-1-6] W przypadku każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku MUSI występować stosunek sygnału do szumu (SNR) wynoszący co najmniej 60 dB. (gdzie SNR jest mierzony jako różnica między 94 dB SPL a ekwiwalent SPL własnego szumu, z wagami A).
[C-1-7] Musisz mieć całkowite zniekształcenie harmoniczne (THD) mniejsze niż 1% dla 1 kHz przy poziomie wejściowym 90 dB SPL w każdym mikrofonie używanym do nagrywania nieprzetworzonego źródła dźwięku.
[C-1-8] NIE wolno stosować żadnego innego przetwarzania sygnału (np. automatycznej regulacji wzmocnienia, filtra górnoprzepustowego czy eliminacji echa) na ścieżce, z wyjątkiem mnożnika poziomu, który ma doprowadzić poziom do pożądanego zakresu. Krótko mówiąc:
- [C-1-9] Jeśli w architekturze występuje przetwarzanie sygnału z dowolnego powodu, należy je wyłączyć i nie wprowadzać opóźnienia ani dodatkowej zwłoki na ścieżce sygnału.
- [C-1-10] Pomnóż poziomów, który może się znajdować na ścieżce, NIE MOŻE powodować opóźnień na ścieżce sygnału.
Wszystkie pomiary SPL są wykonywane bezpośrednio przy mikrofonie, który jest testowany. W przypadku wielu konfiguracji mikrofonu te wymagania dotyczą każdego mikrofonu.
Jeśli implementacje na urządzeniu deklarują android.hardware.microphone
, ale nie obsługują nieprzetworzonego źródła dźwięku, to:
- [C-2-1] W przypadku metody interfejsu API
AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
musisz zwrócić wartośćnull
, aby prawidłowo wskazać brak obsługi. - [C-SR-1] nadal MOCNO zaleca się, aby spełniać jak najwięcej wymagań dotyczących ścieżki sygnału dla nieprzetworzonego źródła nagrania.
5.12. Wideo HDR
Android 13 obsługuje technologie HDR zgodnie z opisem w nadchodzącym dokumencie.
Format pikseli
Jeśli dekoder wideo reklamuje obsługę koloru COLOR_FormatYUVP010, to:
[C-1-1] MUSI obsługiwać format P010 do odczytu przez procesor (ImageReader, MediaImage, ByteBuffer). W Androidzie 13 ograniczenie P010 zostało złagodzone, aby umożliwić dowolny krok dla płaszczyzn Y i UV.
[C-1-2] Bufor wyjściowy P010 MUSI być dostępny do próbkowania przez GPU (gdy jest przypisany za pomocą użycia GPU_SAMPLING). Umożliwia to tworzenie kompozycji przez procesor GPU i niestandardowe mapowanie tonacji przez aplikacje.
Jeśli dekoder wideo reklamuje obsługę formatu COLOR_Format32bitABGR2101010, to:
- [C-2-1] Musi obsługiwać format RGBA_1010102 na wyjściowej powierzchni i do odczytu przez procesor (dane wyjściowe ByteBuffer).
Jeśli koder wideo reklamuje obsługę koloru COLOR_FormatYUVP010, to:
- [C-3-1] MUSI obsługiwać format P010 dla powierzchni wejściowej i danych wejściowych, które można zapisać w procesorze (ImageWriter, MediaImage, ByteBuffer).
Jeśli koder wideo reklamuje obsługę formatu COLOR_Format32bitABGR2101010, to:
- [C-4-1] MUSI obsługiwać format RGBA_1010102 dla powierzchni wejściowej i wejścia (ImageWriter, ByteBuffer), które można zapisać za pomocą procesora. Uwaga: w przypadku koderów nie trzeba przekształcać danych między różnymi krzywą przekształcenia.
Wymagania dotyczące przechwytywania HDR
W przypadku wszystkich koderów wideo, które obsługują profile HDR, implementacje urządzeń:
[C-5-1] NIE MOŻESZ zakładać, że metadane HDR są dokładne. Na przykład zakodowany kadr może zawierać piksele o luminancji przekraczającej poziom szczytowy lub histogram może nie być reprezentatywny dla kadru.
NALEŻY agregować dynamiczne metadane HDR, aby wygenerować odpowiednie statyczne metadane HDR dla zakodowanych strumieni. Należy je wygenerować na końcu każdej sesji kodowania.
Jeśli implementacje urządzeń obsługują nagrywanie HDR za pomocą interfejsów CamcorderProfile API, to:
[C-6-1] Musi obsługiwać przechwytywanie HDR za pomocą interfejsów API Camera2.
[C-6-2] W przypadku każdej obsługiwanej technologii HDR MUSI być obsługiwany co najmniej jeden koder wideo z akceleracją sprzętową.
[C-6-3] Musi obsługiwać (co najmniej) rejestrowanie w formacie HLG.
[C-6-4] Musi obsługiwać zapisywanie metadanych HDR (jeśli są one dostępne w przypadku danej technologii HDR) w nagranym pliku wideo. W przypadku formatów AV1, HEVC i Dolby Vision oznacza to dodanie metadanych do zakodowanego bitstremu.
[C-6-5] MUSI obsługiwać P010 i COLOR_FormatYUVP010.
[C-6-6] MUSI obsługiwać mapowanie tonacji HDR na SDR w domyślnym dekoderze przyspieszanym sprzętowo dla zarejestrowanego profilu. Inaczej mówiąc, jeśli urządzenie może rejestrować HDR10+ HEVC, domyślny dekoder HEVC MUSI być w stanie dekodować zarejestrowany strumień w SDR.
Wymagania dotyczące edycji HDR
Jeśli implementacje urządzeń obejmują kodery wideo obsługujące edycję HDR, to:
- NALEŻY używać minimalnego opóźnienia podczas generowania metadanych HDR, jeśli nie są obecne, i NALEŻY odpowiednio obsługiwać sytuacje, w których metadane są obecne w przypadku niektórych klatek, a w przypadku innych nie. Te metadane POWINNY być dokładne (np. odzwierciedlać rzeczywistą maksymalną luminancję i histogram kadru).
Jeśli implementacja na urządzeniu obejmuje kodeki obsługujące FEATURE_HdrEditing, to:
[C-7-1] MUSI obsługiwać co najmniej 1 profil HDR.
[C-7-2] MUST support FEATURE_HdrEditing for all HDR profiles advertised by that codec. In other words, they MUST support generating HDR metadata when not present for all HDR profiles supported that use HDR metadata.
[C-7-3] MUSI obsługiwać te formaty wejściowe kodera wideo, które w pełni zachowują sygnał dekodowany HDR:
- RGBA_1010102 (już w docelowej krzywej transferu) dla obu powierzchni wejściowych i ByteBuffer oraz MUSI reklamować obsługę COLOR_Format32bitABGR2101010.
Jeśli implementacja urządzenia zawiera kodeki obsługujące FEATURE_HdrEditing, to urządzenie:
- [C-7-4] MUST advertise support for EXT_YUV_target OpenGL extension.
6. Zgodność narzędzi dla programistów i opcji
6.1. Narzędzia dla programistów
Implementacje na urządzeniu:
- [C-0-1] Musi obsługiwać narzędzia dla deweloperów Androida udostępniane w pakiecie SDK Androida.
-
- [C-0-2] MUSI obsługiwać adb zgodnie z dokumentacją do pakietu Android SDK oraz poleceń powłoki udostępnionych 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
. Aktualizacja implementacji urządzenia z wersji Androida bez trwałego blokowania danych MOŻE być zwolniona z obowiązku przestrzegania C-0-11. - [C-0-3] NIE MOŻESZ zmienić formatu ani zawartości zdarzeń systemu urządzenia (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) zarejestrowanych za pomocą polecenia dumpsys.
- [C-0-10] NALEŻY rejestrować bez pomijania i uzyskiwać dostęp do tych zdarzeń, aby były dostępne dla polecenia
cmd stats
w powłoce i klasy interfejsu API systemuStatsManager
.- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- JobStateChanged
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
- [C-0-4] Domyślnie demon adb na urządzeniu MUSI być nieaktywny. Musi istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie mostu debugowania Androida.
- [C-0-5] MUSI obsługiwać bezpieczny interfejs ADB. Android obsługuje bezpieczne połączenia przez ADB. Bezpieczny adb włącza adb na znanych uwierzytelnionych hostach.
- [C-0-6] NALEŻY udostępnić mechanizm umożliwiający połączenie adb z komputera hosta. Więcej szczegółów:
Jeśli implementacje urządzeń bez portu USB obsługują tryb peryferyjny:
- [C-3-1] NALEŻY implementować adb za pomocą sieci lokalnej (np. Ethernet lub Wi-Fi).
- [C-3-2] Musisz dostarczyć sterowniki dla Windows 7, 8 i 10, które umożliwiają deweloperom połączenie z urządzeniem za pomocą protokołu ADB.
Jeśli implementacje urządzeń obsługują połączenia adb z hostem przez Wi-Fi lub Ethernet, muszą:
- [C-4-1] Musisz mieć metodę
AdbManager#isAdbWifiSupported()
zwracającątrue
.
Jeśli implementacje urządzeń obsługują połączenia adb z hostem przez Wi-Fi lub Ethernet i zawierają co najmniej 1 kamerę, to:
- [C-5-1] Musisz mieć metodę
AdbManager#isAdbWifiQrSupported()
, która zwracatrue
.
- [C-0-2] MUSI obsługiwać adb zgodnie z dokumentacją do pakietu Android SDK oraz poleceń powłoki udostępnionych w AOSP, których mogą używać deweloperzy aplikacji, w tym
Dalvik Debug Monitor Service (ddms)
- [C-0-7] Musi obsługiwać wszystkie funkcje DMS zgodnie z dokumentacją pakietu SDK Androida. Ponieważ ddms używa adb, obsługa ddms powinna być domyślnie nieaktywna, ale MUSI być obsługiwana, gdy użytkownik aktywuje Android Debug Bridge, jak opisano powyżej.
-
- [C-0-9] MUSI obsługiwać narzędzie systrace zgodnie z dokumentacją w pakiecie SDK Androida. Systrace musi być domyślnie nieaktywny i musi istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie Systrace.
-
- [C-SR-1] ZALECAMY udostępnienie użytkownikowi powłoki binarnego pliku
/system/bin/perfetto
, którego wiersz poleceń jest zgodny z dokumentacją perfetto. - [C-SR-2] Zalecamy, aby binarne pliki perfetto przyjmowały jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
- [C-SR-3] Zalecamy, aby binarny plik perfetto zapisywał jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
- [C-SR-4] MOCNO ZALECAMY podanie w pliku binarnym perfetto co najmniej źródeł danych opisanych w dokumentacji perfetto.
- [C-SR-1] ZALECAMY udostępnienie użytkownikowi powłoki binarnego pliku
-
- [C-0-12] MUST write a
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom to the statsd log when an app is terminated by the Low Memory Killer.
- [C-0-12] MUST write a
Tryb jarzma testowego Jeśli implementacje urządzeń obsługują polecenie powłoki
cmd testharness
i uruchomieniecmd testharness enable
, to:- [C-2-1] NALEŻY zwrócić
true
w przypadkuActivityManager.isRunningInUserTestHarness()
- [C-2-2] MUSISZ zaimplementować tryb jarzma testowego zgodnie z opisem w dokumentacji trybu jarzma testowego.
- [C-2-1] NALEŻY zwrócić
Informacje o pracy GPU
Implementacje na urządzeniu:
- [C-0-13] MUSI implementować polecenie powłoki
dumpsys gpu --gpuwork
, aby wyświetlić zagregowane dane pracy GPU zwrócone przez punkt pomiaru jądrapower/gpu_work_period
, lub nie wyświetlać żadnych danych, jeśli punkt pomiaru nie jest obsługiwany. Implementacja AOSP toframeworks/native/services/gpuservice/gpuwork/
.
- [C-0-13] MUSI implementować polecenie powłoki
Jeśli implementacje urządzeń zgłaszają obsługę interfejsu Vulkan 1.0 lub nowszego za pomocą flag funkcji android.hardware.vulkan.version
, to:
- [C-1-1] Musisz umożliwić deweloperowi aplikacji włączanie i wyłączanie warstw debugowania GPU.
- [C-1-2] Gdy włączone są warstwy debugowania GPU, należy wyliczyć warstwy w bibliotekach udostępnianych przez zewnętrzne narzędzia (czyli niebędące częścią platformy ani pakietu aplikacji) znajdujące się w katalogu głównym aplikacji, które można debugować, aby obsługiwać metody vkEnumerateInstanceLayerProperties() i vkCreateInstance() interfejsu API.
6.2. Opcje programisty
Android zapewnia deweloperom możliwość konfigurowania ustawień związanych z rozwojem aplikacji.
Implementacje na urządzeniach MUSZĄ zapewniać spójne działanie opcji dla deweloperów. Muszą one:
- [C-0-1] MUSI obsługiwać działanie okna dialogowego android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z rozwojem aplikacji. W dolnej implementacji Androida menu Opcje dewelopera jest domyślnie ukryte, a użytkownicy mogą je uruchomić po naciśnięciu 7 razy elementu menu Ustawienia > Informacje o urządzeniu > Numer kompilacji.
- [C-0-2] Domyślnie należy ukryć Opcje programisty.
- [C-0-3] Musisz udostępnić przejrzysty mechanizm, który nie faworyzuje jednej aplikacji innej firmy w porównaniu z inną, aby umożliwić korzystanie z opcji dla deweloperów. Musisz przesłać publicznie dostępny dokument lub stronę internetową z instrukcjami włączania opcji dla deweloperów. Ten dokument lub witryna MUSI być powiązany z dokumentami pakietu SDK Androida.
- APLIKACJA POWINNA wyświetlać użytkownikowi stałe wizualne powiadomienie, gdy opcje dla deweloperów są włączone, a bezpieczeństwo użytkownika jest zagrożone.
- MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty, ukrywając je wizualnie lub wyłączając, aby zapobiec rozproszeniu w sytuacjach, w których bezpieczeństwo użytkownika jest zagrożone.
7. Zgodność sprzętowa
Jeśli urządzenie zawiera określony komponent sprzętowy, który ma odpowiedni interfejs API dla deweloperów zewnętrznych:
- [C-0-1] Implementacja na urządzeniu MUSI implementować to API zgodnie z opisem w dokumentacji pakietu Android SDK.
Jeśli interfejs API w pakiecie SDK współdziała ze sprzętowym komponentem, który jest oznaczony jako opcjonalny, a urządzenie nie ma tego komponentu:
- [C-0-2] Musisz podać pełne definicje klas (opisane w pakiecie SDK) interfejsów API komponentu.
- [C-0-3] Zachowanie interfejsu API MUSI być zaimplementowane w taki sposób, aby nie wymagało żadnych działań.
- [C-0-4] Metody interfejsu API MUSZĄ zwracać wartości null, gdy jest to dozwolone przez dokumentację pakietu SDK.
- [C-0-5] Metody interfejsu API MUSZĄ zwracać implementacje klas bez operacji, gdy wartości null nie są dozwolone w dokumentacji pakietu SDK.
- [C-0-6] Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, które nie są opisane w dokumentacji pakietu SDK.
- [C-0-7] Implementacje urządzeń MUSZĄ konsekwentnie przekazywać dokładne informacje o konfiguracji sprzętu za pomocą metod
getSystemAvailableFeatures()
ihasSystemFeature(String)
w klasie android.content.pm.PackageManager dla tego samego odcisku palca kompilacji.
Typowym przykładem scenariusza, w którym obowiązują te wymagania, jest interfejs API telefonii: nawet na urządzeniach innych niż telefony te interfejsy API muszą być implementowane w sposób umożliwiający ich bezpieczne wyłączenie.
7.1. Wyświetlanie i grafika
Android zawiera funkcje, które automatycznie dostosowują zasoby aplikacji i rozkłady interfejsu do urządzenia, aby aplikacje innych firm działały prawidłowo w różnych konfiguracjach sprzętowych. Na wyświetlaczach zgodnych z Androidem, na których można uruchamiać wszystkie aplikacje innych firm zgodne z Androidem, implementacje na urządzeniach MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z opisem w tej sekcji.
Jednostki, do których odwołują się wymagania w tej sekcji, są zdefiniowane w następujący sposób:
- fizyczna przekątna. Odległość w calach między przeciwległymi narożnikami podświetlonej części wyświetlacza.
- punkty na cal (dpi). Liczba pikseli zawartych w liniowym zakresie poziomym lub pionowym 1 cal. Jeśli podano wartości dpi, zarówno poziomy, jak i pionowy dpi muszą mieścić się w zakresie.
- format. Stosunek pikseli dłuższego wymiaru do krótszego wymiaru ekranu. Na przykład wyświetlacz o wymiarach 480 x 854 piksele będzie miał współczynnik 854/480 = 1, 779, czyli mniej więcej „16:9”.
- piksel niezależny od gęstości (dp). Wirtualna jednostka piksela znormalizowana do ekranu o rozdzielczości 160 dpi, obliczona jako: piksele = dpi * (gęstość/160).
7.1.1. Konfiguracja ekranu
7.1.1.1. Rozmiar i kształt ekranu
Interfejs użytkownika Androida obsługuje różne rozmiary układu ekranu i pozwala aplikacjom wysyłać zapytania o rozmiar układu ekranu bieżącej konfiguracji za pomocą Configuration.screenLayout
z użyciem SCREENLAYOUT_SIZE_MASK
i Configuration.smallestScreenWidthDp
.
Implementacje na urządzeniu:
[C-0-1] Musisz podać prawidłowy rozmiar układu dla
Configuration.screenLayout
zgodnie z definicją w dokumentacji pakietu Android SDK. W szczególności implementacje urządzeń MUSZĄ zgłaszać prawidłowe wymiary ekranu w pikselach niezależnych od gęstości (dp) zgodnie z tymi wartościami:- Urządzenia, dla których atrybut
Configuration.uiMode
ma wartość inną niż UI_MODE_TYPE_WATCH, a które zgłaszają rozmiarsmall
dla atrybutuConfiguration.screenLayout
, MUSZĄ mieć wymiary co najmniej 426 dp x 320 dp. - Urządzenia, które podają rozmiar
normal
dlaConfiguration.screenLayout
, MUSZĄ mieć co najmniej 480 dp x 320 dp. - Urządzenia, które podają rozmiar
large
dlaConfiguration.screenLayout
, MUSZĄ mieć wymiary co najmniej 640 x 480 dp. - Urządzenia zgłaszające rozmiar
xlarge
w przypadkuConfiguration.screenLayout
MUSZĄ mieć co najmniej 960 dp x 720 dp.
- Urządzenia, dla których atrybut
[C-0-2] MUSI prawidłowo obsługiwać deklarowane przez aplikację rozmiary ekranów za pomocą atrybutu <
supports-screens
> w pliku AndroidManifest.xml zgodnie z opisem w dokumentacji pakietu SDK Androida.MOŻE mieć wyświetlacze zgodne z Androidem z zaokrąglonymi rogami.
Jeśli implementacje urządzeń obsługują UI_MODE_TYPE_NORMAL
i obejmują wyświetlacze zgodne z Androidem z zaokrąglonymi rogami, to:
[C-1-1] NALEŻY zadbać o to, aby spełnione było co najmniej 1 z tych wymagań:
- Promień zaokrąglonych rogów jest mniejszy lub równy 38 dp.
- Gdy w każdym narożniku logicznego wyświetlacza zamocujesz pole o wymiarach 15 dp na 15 dp, na ekranie będzie widoczny co najmniej 1 piksel każdego pola.
NALEŻY uwzględnić możliwość przełączenia się do trybu wyświetlania za pomocą prostokątnych rogów.
Jeśli implementacje urządzeń zawierają zgodne z Androidem wyświetlacze, które są składane lub mają składany zawias między wieloma panelami wyświetlacza i umożliwiają renderowanie aplikacji innych firm, muszą:
- [C-2-1] NALEŻY zaimplementować najnowszą dostępną stabilną wersję interfejsu extensions API lub stabilną wersję interfejsu sidecar API, aby biblioteka Jetpack Window Manager mogła z niego korzystać.
Jeśli implementacje urządzeń zawierają zgodne z Androidem wyświetlacze, które są składane, lub zawierają składany zawias między wieloma panelami wyświetlacza, a zawias lub składanie obejmuje okno aplikacji pełnoekranowej, muszą:
- [C-3-1] NALEŻY zgłaszać pozycję, granice i stan zawiasów lub składania za pomocą rozszerzeń lub interfejsów Sidecar do aplikacji.
Szczegółowe informacje o prawidłowym wdrażaniu interfejsów API sidecar lub rozszerzeń znajdziesz w publicznej dokumentacji Jetpacka Window Manager.
7.1.1.2. Format obrazu
Chociaż nie ma ograniczeń dotyczących proporcji fizycznego ekranu w przypadku wyświetlaczy zgodnych z Androidem, proporcje logicznego ekranu, na którym renderowane są aplikacje innych firm, można obliczyć na podstawie wartości wysokości i szerokości podanych przez interfejsy API view.Display
i Konfiguracja. Należy spełnić te wymagania:
[C-0-1] W przypadku implementacji urządzenia z wartością
Configuration.uiMode
równąUI_MODE_TYPE_NORMAL
format obrazu musi mieć wartość mniejszą lub równą 1,86 (około 16:9), chyba że aplikacja spełnia jedną z tych warunków:- Aplikacja zadeklarowała, że obsługuje większy format obrazu, podając wartość metadanych
android.max_aspect
. - Aplikacja deklaruje, że można zmienić jej rozmiar za pomocą atrybutu android:resizeableActivity.
- Aplikacja jest kierowana na interfejs API na poziomie 24 lub wyższym i nie deklaruje
android:maxAspectRatio
, który ogranicza dozwolony format obrazu.
- Aplikacja zadeklarowała, że obsługuje większy format obrazu, podając wartość metadanych
[C-0-3] Wdrożenia urządzenia z ustawionymi wartościami
Configuration.uiMode
UI_MODE_TYPE_WATCH
MUSZĄ mieć ustawioną wartość formatu obrazu jako 1,0 (1:1).
7.1.1.3. Gęstość ekranu
Interfejs użytkownika Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić deweloperom aplikacji kierowanie zasobów aplikacji.
[C-0-1] Domyślnie implementacje urządzeń MUSZĄ zgłaszać tylko jedną z gęstości ramki Androida wymienionych na stronie
DisplayMetrics
za pomocą interfejsu APIDENSITY_DEVICE_STABLE
. Wartość ta NIE MOŻE się zmieniać w żaden sposób. Urządzenie MOŻE jednak zgłaszać inną dowolną gęstość w zależności od zmian w konfiguracji wyświetlacza wprowadzonych przez użytkownika (np. rozmiar wyświetlacza) po pierwszym uruchomieniu.Implementacje urządzeń powinny zdefiniować standardową gęstość w ramach Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, chyba że ta gęstość logiczna spowoduje, że zgłaszany rozmiar ekranu będzie niższy niż minimalny obsługiwany rozmiar. Jeśli standardowa gęstość w ramach Androida, która jest liczbowo najbliższa fizycznej gęstości, powoduje, że rozmiar ekranu jest mniejszy niż najmniejszy obsługiwany rozmiar ekranu (szerokość 320 dp), implementacje urządzeń powinny zgłaszać standardową gęstość w ramach Androida o jednej pozycji niższą.
Jeśli istnieje możliwość zmiany rozmiaru wyświetlacza urządzenia:
- [C-1-1] Rozmiar wyświetlacza NIE MOŻE być powiększony ponad 1,5-krotność natywnej gęstości lub wygenerować skutecznej minimalnej wielkości ekranu mniejszej niż 320 dp (równa się kwalifikatorowi zasobów sw320dp), w zależności od tego, co nastąpi pierwsze.
- [C-1-2] Rozmiar wyświetlacza NIE MOŻE być przeskalowany do wartości mniejszej niż 0,85 krotna gęstości natywnej.
- Aby zapewnić dobrą użyteczność i spójność rozmiarów czcionek, zalecamy zastosowanie tych opcji skalowania wyświetlania natywnych (z zachowaniem podanych powyżej limitów):
- Małe: 0,85 x
- Domyślnie: 1x (rodzinna skala wyświetlacza)
- Duża: 1,15 x
- Większy: 1,3 x
- Największy 1,45 x
7.1.2. Dane wyświetleń
Jeśli implementacje urządzeń obejmują wyświetlacze zgodne z Androidem lub wyjście wideo na ekrany zgodne z Androidem, muszą:
- [C-1-1] MUSI raportować prawidłowe wartości wszystkich danych wyświetlania zgodnych z Androidem zdefiniowanych w interfejsie API
android.util.DisplayMetrics
.
Jeśli implementacje urządzeń nie zawierają wbudowanego ekranu ani wyjścia wideo, muszą:
- [C-2-1] MUSI raportować prawidłowe wartości wyświetlacza zgodnego z Androidem zgodnie z definicją w interfejsie API
android.util.DisplayMetrics
dla emulowanego domyślnegoview.Display
.
7.1.3. Orientacja ekranu
Implementacje na urządzeniu:
- [C-0-1] MUST report which screen orientations they support
(
android.hardware.screen.portrait
and/orandroid.hardware.screen.landscape
) and MUST report at least one supported orientation. Na przykład urządzenie z ustawionym orientacją poziomą ekranu, takie jak telewizor czy laptop, POWINNA raportować tylkoandroid.hardware.screen.landscape
. - [C-0-2] MUST report the correct value for the device’s
orientation, whenever queried via the
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
, or other APIs.
Jeśli implementacje urządzeń obsługują obie orientacje ekranu, muszą:
- [C-1-1] Aplikacje MUSZĄ obsługiwać dynamiczną orientację ekranu w orientacji poziomej lub pionowej. Oznacza to, że urządzenie musi uwzględnić prośbę aplikacji o określoną orientację ekranu.
- [C-1-2] Nie wolno zmieniać zgłaszanego rozmiaru ekranu ani gęstości podczas zmiany orientacji.
- MOŻE wybrać orientację pionową lub poziomą jako domyślną.
7.1.4. akceleracja grafiki 2D i 3D;
7.1.4.1 OpenGL ES
Implementacje na urządzeniu:
- [C-0-1] MUSI prawidłowo identyfikować obsługiwane wersje OpenGL ES (1.1, 2.0,
3.0, 3.1, 3.2) za pomocą zarządzanych interfejsów API (np. za pomocą metody
GLES10.getString()
) i natywnych interfejsów API. - [C-0-2] MUSI zawierać obsługę wszystkich odpowiednich zarządzanych interfejsów API oraz natywnych interfejsów API we wszystkich wersjach OpenGL ES, które zostały wskazane jako obsługiwane.
Jeśli implementacje urządzeń obejmują ekran lub wyjście wideo, muszą:
- [C-1-1] Musi obsługiwać interfejs OpenGL ES 1.1 i 2.0 zgodnie z opisem w dokumentacji pakietu SDK Androida.
- [C-SR-1] MOCNO ZALECAMY obsługę OpenGL ES 3.1.
- NALEŻY obsługiwać OpenGL ES 3.2.
Testy OpenGL ES dEQP są podzielone na kilka list testów, z których każda ma powiązaną datę lub numer wersji. Znajdziesz je w drzewie kodu źródłowego Androida na stronie external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
. Urządzenie, które obsługuje OpenGL ES na poziomie zgłoszonym przez producenta, oznacza, że może przejść testy dEQP na wszystkich listach testów od tego poziomu w górę.
Jeśli implementacje urządzeń obsługują dowolną wersję OpenGL ES, muszą:
- [C-2-1] NALEŻY zgłaszać za pomocą interfejsów API zarządzanych OpenGL ES i natywnych interfejsów API wszystkie zaimplementowane przez siebie rozszerzenia OpenGL ES. NALEŻY NIE zgłaszać ciągów znaków rozszerzenia, których nie obsługują.
- [C-2-2] MUSI obsługiwać rozszerzenia
EGL_KHR_image
,EGL_KHR_image_base
,EGL_ANDROID_image_native_buffer
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_wait_sync
,EGL_KHR_get_all_proc_addresses
,EGL_ANDROID_presentation_time
,EGL_KHR_swap_buffers_with_damage
,EGL_ANDROID_recordable
iEGL_ANDROID_GLES_layers
. - [C-2-3] MUST report the maximum version of the OpenGL ES dEQP tests
supported via the
android.software.opengles.deqp.level
feature flag. - [C-2-4] Musi obsługiwać co najmniej wersję 132383489 (od 1 marca 2020 r.), jak podano w flagach funkcji
android.software.opengles.deqp.level
. - [C-2-5] Musisz przejść wszystkie testy dEQP OpenGL ES na listach testów od wersji 132383489 do wersji określonej w opcji funkcji
android.software.opengles.deqp.level
w przypadku każdej obsługiwanej wersji OpenGL ES. - [C-SR-2] ZALECAMY stosowanie rozszerzeń
EGL_KHR_partial_update
iOES_EGL_image_external
. - NALEŻY dokładnie podać za pomocą metody
getString()
dowolny obsługiwany format kompresji tekstur, który jest zazwyczaj specyficzny dla dostawcy. - NALEŻY obsługiwać rozszerzenia
EGL_IMG_context_priority
iEGL_EXT_protected_content
.
Jeśli implementacje na urządzeniu deklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2, muszą:
- [C-3-1] NALEŻY wyeksportować odpowiadające symbole funkcji dla tych wersji oprócz symboli funkcji OpenGL ES 2.0 w bibliotece libGLESv2.so.
- [C-SR-3] MOCNO zalecamy obsługę rozszerzenia
OES_EGL_image_external_essl3
.
Jeśli implementacje urządzeń obsługują OpenGL ES 3.2, to:
- [C-4-1] Aplikacja MUSI obsługiwać cały pakiet rozszerzeń OpenGL ES na Androida.
Jeśli implementacje na urządzeniach obsługują pakiet rozszerzeń Androida OpenGL ES w całości, to:
- [C-5-1] MUSI zawierać informacje o wsparciu w formie flagi funkcji
android.hardware.opengles.aep
.
Jeśli implementacje urządzeń obsługują rozszerzenie EGL_KHR_mutable_render_buffer
:
- [C-6-1] Musi obsługiwać rozszerzenie
EGL_ANDROID_front_buffer_auto_refresh
.
7.1.4.2 Vulkan
Android obsługuje interfejs Vulkan, czyli wieloplatformowy interfejs API o niskim obciążeniu, który umożliwia tworzenie wydajnej grafiki 3D.
Jeśli implementacje na urządzeniu obsługują OpenGL ES 3.1, to:
- [C-SR-1] ZALECAMY uwzględnienie obsługi Vulkan 1.3.
- [C-4-1] NIE MOŻE obsługiwać wersji odmiany Vulkana (czyli część odmiany w wersji rdzenia Vulkana MUSI być równa zeru).
Jeśli implementacje urządzeń obejmują ekran lub wyjście wideo, muszą:
- [C-SR-2] ZALECAMY uwzględnienie obsługi Vulkan 1.3.
Testy Vulkan dEQP są podzielone na kilka list testów, z których każda ma powiązaną datę lub wersję. Znajdziesz je w drzewie kodu źródłowego Androida na stronie external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt
. Urządzenie, które obsługuje Vulkana na poziomie zgłoszonym przez producenta, oznacza, że może przejść testy dEQP na wszystkich listach testów od tego poziomu i wcześniejszych.
Jeśli implementacje urządzeń obsługują Vulkan 1.0 lub nowszą wersję, to:
- [C-1-1] Musisz podać prawidłową wartość całkowitą z flagami funkcji
android.hardware.vulkan.level
iandroid.hardware.vulkan.version
. - [C-1-2] MUST enumerate, at least one
VkPhysicalDevice
for the Vulkan native APIvkEnumeratePhysicalDevices()
. - [C-1-3] NALEŻY w pełni zaimplementować interfejsy API Vulkan 1.0 dla każdego z wymienionych
VkPhysicalDevice
. - [C-1-4] NALEŻY wyliczać warstwy zawarte w bibliotekach natywnych o nazwie
libVkLayer*.so
w katalogu bibliotek natywnych pakietu aplikacji za pomocą interfejsów API natywnych VulkanvkEnumerateInstanceLayerProperties()
ivkEnumerateDeviceLayerProperties()
. - [C-1-5] NIE MOŻESZ wymieniać warstw udostępnianych przez biblioteki spoza pakietu aplikacji ani udostępniać innych sposobów śledzenia lub przechwytywania interfejsu Vulkan API, chyba że aplikacja ma atrybuty
android:debuggable
ustawione jakotrue
. - [C-1-6] NALEŻY podać wszystkie ciągi znaków rozszerzeń, które są obsługiwane za pomocą interfejsów API natywnych Vulkan. NALEŻY natomiast nie podawać ciągów znaków rozszerzeń, których nie obsługuje się prawidłowo.
- [C-1-7] MUSI obsługiwać rozszerzenia VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain oraz VK_KHR_incremental_present.
- [C-1-8] MUST report the maximum version of the Vulkan dEQP Tests
supported via the
android.software.vulkan.deqp.level
feature flag. - [C-1-9] Musi obsługiwać co najmniej wersję
132317953
(od 1 marca 2019 r.), jak podano w flagach funkcjiandroid.software.vulkan.deqp.level
. - [C-1-10] Musisz przejść wszystkie testy dEQP Vulkana na listach testów między wersją
132317953
a wersją określoną w flagach funkcjiandroid.software.vulkan.deqp.level
. - [C-1-11] NIE MOŻESZ wymieniać obsługi rozszerzeń VK_KHR_video_queue, VK_KHR_video_decode_queue ani VK_KHR_video_encode_queue.
- [C-SR-3] MOCNO ZALECAMY obsługę rozszerzeń
VK_KHR_driver_properties
iVK_GOOGLE_display_timing
. - NALEŻY obsługiwać właściwości
VkPhysicalDeviceProtectedMemoryFeatures
iVK_EXT_global_priority
. - [C-1-12] NIE MOŻESZ wymieniać obsługi rozszerzenia VK_KHR_performance_query.
- [C-SR-4] MOCNO ZALECAMY spełnienie wymagań określonych w profilu Android Baseline 2021.
Jeśli implementacje urządzeń nie obsługują Vulkan 1.0, nie:
- [C-2-1] NIE NALEŻY deklarować żadnych flag funkcji Vulkana (np.
android.hardware.vulkan.level
,android.hardware.vulkan.version
). - [C-2-2] W przypadku interfejsu API natywnego Vulkan NIE MOŻNA wymieniać żadnych elementów
VkPhysicalDevice
.vkEnumeratePhysicalDevices()
Jeśli implementacje na urządzeniu obejmują obsługę Vulkan 1.1 i zadeklarują co najmniej 1 flagę funkcji Vulkan, muszą:
- [C-3-1] MUST expose support for the
SYNC_FD
external semaphore and handle types and theVK_ANDROID_external_memory_android_hardware_buffer
extension.
7.1.4.3 RenderScript
- [C-0-1] Implementacje na urządzeniach MUSZĄ obsługiwać Android RenderScript, zgodnie z opisem w dokumentacji pakietu Android SDK.
7.1.4.4 Akceleracja grafiki 2D
Android zawiera mechanizm, który umożliwia aplikacjom oświadczenie, że chcą włączyć akcelerację sprzętową grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku za pomocą tagu manifestu android:hardwareAccelerated lub bezpośrednich wywołań interfejsu API.
Implementacje na urządzeniu:
- [C-0-1] NALEŻY włączyć akcelerację sprzętową domyślnie i NALEŻY ją wyłączyć, jeśli deweloper zażąda tego, ustawiając android:hardwareAccelerated="false” lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów API Androida View.
- [C-0-2] Musi zachowywać się zgodnie z dokumentacją pakietu Android SDK dotyczącą przyspieszania sprzętowego.
Android zawiera obiekt TextureView, który pozwala deweloperom bezpośrednio integrować tekstury OpenGL ES przyspieszone sprzętowo jako docelowe elementy renderowania w hierarchii interfejsu użytkownika.
Implementacje na urządzeniu:
- [C-0-3] MUSI obsługiwać interfejs TextureView API i MUSI zachowywać się zgodnie z implementacją na Androidzie.
7.1.4.5 Wyświetlacze o szerokim zakresie dynamiki
Jeśli implementacje urządzeń obsługują wyświetlacze o szerokim zakresie tonalnym za pomocą
Configuration.isScreenWideColorGamut()
, to:
- [C-1-1] Musisz mieć wyświetlacz z kalibracją kolorów.
- [C-1-2] Musisz mieć wyświetlacz, którego gamut całkowicie pokrywa gamut sRGB w przestrzeni CIE 1931 xyY.
- [C-1-3] Musisz mieć wyświetlacz, którego gama kolorów ma obszar co najmniej 90% DCI-P3 w przestrzeni CIE 1931 xyY.
- [C-1-4] Musi obsługiwać OpenGL ES 3.1 lub 3.2 i odpowiednio to zgłaszać.
- [C-1-5] MUSISZ reklamować obsługę rozszerzeń
EGL_KHR_no_config_context
,EGL_EXT_pixel_format_float
,EGL_KHR_gl_colorspace
,EGL_EXT_gl_colorspace_scrgb
,EGL_EXT_gl_colorspace_scrgb_linear
,EGL_EXT_gl_colorspace_display_p3
,EGL_EXT_gl_colorspace_display_p3_linear
iEGL_EXT_gl_colorspace_display_p3_passthrough
. - [C-SR-1] Zalecamy obsługę
GL_EXT_sRGB
.
Jeśli implementacje urządzeń nie obsługują wyświetlaczy o szerokim zakresie, nie mogą:
- [C-2-1] POWINIEN obejmować co najmniej 100% przestrzeni sRGB w przestrzeni CIE 1931 xyY, chociaż gama kolorów ekranu nie jest zdefiniowana.
7.1.5. Tryb zgodności ze starszymi wersjami aplikacji
Android określa „tryb zgodności”, w którym framework działa w reżimie „normalnego” rozmiaru ekranu (szerokość 320 dp) na potrzeby starszych aplikacji, które nie zostały opracowane na potrzeby starszych wersji Androida, które nie obsługują niezależności od rozmiaru ekranu.
7.1.6. Technologia ekranu
Platforma Android zawiera interfejsy API, które umożliwiają aplikacjom renderowanie bogatych grafik na wyświetlaczu zgodnym z Androidem. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zgodnie z definicją w pakiecie SDK Androida, chyba że jest to wyraźnie dozwolone w tym dokumencie.
Wszystkie wyświetlacze zgodne z Androidem w ramach implementacji urządzenia:
- [C-0-1] Musi być możliwe renderowanie grafiki w kolorze 16-bitowym.
- NALEŻY obsługiwać wyświetlacze obsługujące 24-bitową grafikę kolorową.
- [C-0-2] Musi być możliwe renderowanie animacji.
- [C-0-3] Musi mieć współczynnik proporcji pikseli (PAR) w zakresie od 0,9 do 1,15. Oznacza to, że współczynnik proporcji piksela MUSI być zbliżony do kwadratu (1,0) z tolerancją 10–15%.
7.1.7. Wyświetlacze dodatkowe
Android obsługuje dodatkowe wyświetlacze zgodne z Androidem, aby umożliwić udostępnianie multimediów i użycie interfejsów API dla programistów do uzyskiwania dostępu do wyświetlaczy zewnętrznych.
Jeśli implementacje urządzeń obsługują wyświetlacz zewnętrzny przez połączenie przewodowe, bezprzewodowe lub wbudowane dodatkowe wyświetlacze, muszą:
- [C-1-1] NALEŻY zaimplementować usługę systemową
DisplayManager
i interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK.
7.2. Urządzenia wejściowe
Implementacje na urządzeniu:
- [C-0-1] Musisz uwzględnić mechanizm wprowadzania danych, np. ekran dotykowy lub nawigację bezdotykowej, aby nawigować między elementami interfejsu.
7.2.1. Klawiatura
Jeśli implementacje urządzeń obejmują obsługę zewnętrznych aplikacji edytorów metody wprowadzania (IME), muszą one:
- [C-1-1] NALEŻY zadeklarować flagę funkcji
android.software.input_methods
. - [C-1-2] NALEŻY w pełni wdrożyć
Input Management Framework
- [C-1-3] Musi być wstępnie zainstalowana klawiatura programowa.
Implementacje na urządzeniu:
- [C-0-1] NIE MOŻE zawierać klawiatury sprzętowej, która nie odpowiada żadnemu z formatów określonych w android.content.res.Configuration.keyboard (QWERTY lub 12 klawiszy).
- NALEŻY uwzględnić dodatkowe implementacje klawiatury ekranowej.
- MOŻE zawierać klawiaturę sprzętową.
7.2.2. Nawigacja bezdotykowa
Android obsługuje panel sterujący, kulkę i koło jako mechanizmy nawigacji bezdotykowej.
Implementacje na urządzeniu:
- [C-0-1] Musisz podać prawidłową wartość dla android.content.res.Configuration.navigation.
Jeśli implementacje na urządzeniach nie obsługują nawigacji bezdotykowej, mogą:
- [C-1-1] Musisz zapewnić rozsądny alternatywny mechanizm interfejsu użytkownika do zaznaczania i edytowania tekstu, który jest zgodny z silnikami zarządzania danymi wejściowymi. Implementacja na upstreamie w ramach Androida open source zawiera mechanizm wyboru odpowiedni do stosowania na urządzeniach, które nie mają niedotykowych elementów sterujących.
7.2.3. Klawisze nawigacyjne
Funkcje Ekran główny, Ostatnie i Wstecz, które są zwykle dostępne po naciśnięciu specjalnego przycisku fizycznego lub określonej części ekranu dotykowego, są niezbędne w ramach paradygmatu nawigacji w Androidzie, a zatem w implementacjach urządzeń:
- [C-0-1] NALEŻY zapewnić użytkownikowi możliwość uruchomienia zainstalowanych aplikacji, które mają działanie z
<intent-filter>
ustawionym naACTION=MAIN
orazCATEGORY=LAUNCHER
lubCATEGORY=LEANBACK_LAUNCHER
w przypadku implementacji na telewizorach. Funkcja Home powinna być mechanizmem umożliwiającym użytkownikom korzystanie z tej funkcji. - NALEŻY zapewnić przyciski Ostatnie i Wstecz.
Jeśli dostępne są funkcje ekranu głównego, Ostatnie lub Wstecz:
- [C-1-1] Musi być dostępny za pomocą jednego działania (np. kliknięcia, kliknięcia dwukrotnego lub gestu), gdy którykolwiek z nich jest dostępny.
- [C-1-2] NALEŻY wyraźnie wskazać, które pojedyncze działanie uruchamia każdą funkcję. Przykładami takich wskazówek są widoczna ikona na przycisku, ikona oprogramowania na pasku nawigacyjnym lub przeprowadzanie użytkownika przez szczegółowy proces konfiguracji podczas konfiguracji w wersji podstawowej.
Implementacje na urządzeniu:
[C-SR-1] Zdecydowanie zalecamy, aby nie udostępniać mechanizmu wprowadzania danych w funkcji menu, ponieważ od wersji 4.0 Androida jest on wycofany na rzecz paska czynności.
[C-SR-2] MOCNO ZALECAMY, aby wszystkie funkcje nawigacji były anulowalne. „Możliwość anulowania” oznacza możliwość zapobieżenia przez użytkownika wykonaniu funkcji nawigacji (np. powrotu do domu, cofnięcia itp.), jeśli przesunięcie nie zostanie zwolnione po przekroczeniu określonego progu.
Jeśli implementacje urządzeń udostępniają funkcję menu, muszą:
- [C-2-1] NALEŻY wyświetlić przycisk menu czynności, gdy menu czynności nie jest puste i widoczny jest pasek czynności.
- [C-2-2] NIE wolno modyfikować pozycji wyskakującego okienka akcji wyświetlanego po kliknięciu przycisku przepełnienia w pasku akcji, ale można wyświetlić to wyskakujące okienko w zmodyfikowanej pozycji na ekranie po kliknięciu funkcji menu.
Jeśli implementacje urządzeń nie zapewniają funkcji menu, ze względu na zgodność z poprzednimi wersjami:
* [C-3-1] MUSZĄ udostępnić aplikacjom funkcję menu, gdy targetSdkVersion
jest mniejsza niż 10, za pomocą przycisku fizycznego, klawisza programowego lub gestów. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacji.
Jeśli implementacje urządzeń obsługują funkcję pomocy:
- [C-4-1] Funkcja pomocy musi być dostępna po wykonaniu pojedynczego działania (np. kliknięcia, podwójnego kliknięcia lub gestu), gdy inne klawisze nawigacyjne są dostępne.
- [C-SR-3] ZALECAMY mocno używanie długiego naciśnięcia przycisku ekranu głównego jako tej wyznaczonej interakcji.
Jeśli implementacje urządzeń używają osobnej części ekranu do wyświetlania klawiszy nawigacyjnych, muszą:
- [C-5-1] Klawisze nawigacyjne MUSZĄ zajmować osobną część ekranu niedostępną dla aplikacji i NIE MOGĄ zasłaniać ani w inny sposób zakłócać części ekranu dostępnej dla aplikacji.
- [C-5-2] MUSI udostępniać część ekranu aplikacjom, które spełniają wymagania określone w sekcji 7.1.1.
- [C-5-3] Musi uwzględniać flagi ustawione przez aplikację za pomocą metody interfejsu API
View.setSystemUiVisibility()
, aby ta odrębna część ekranu (czyli pasek nawigacyjny) była odpowiednio ukryta zgodnie z dokumentacją pakietu SDK.
Jeśli funkcja nawigacji jest obsługiwana jako działanie na ekranie oparte na gestach:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
NALEŻY używać tylko do raportowania obszaru rozpoznawania gestu Home. - [C-6-2] Gesty, które rozpoczynają się w prostokącie wykluczenia udostępnionym przez aplikację na pierwszym planie za pomocą interfejsu
View#setSystemGestureExclusionRects()
, ale poza obszaremWindowInsets#getMandatorySystemGestureInsets()
, NIE POWINNY być przechwytywane przez funkcję nawigacji, o ile prostokąt wykluczenia mieści się w maks. limicie wykluczenia określonym w dokumentacji do interfejsuView#setSystemGestureExclusionRects()
. - [C-6-3] NALEŻY wysłać do aplikacji na pierwszym planie zdarzenie
MotionEvent.ACTION_CANCEL
, gdy dotknięcia zaczynają być przechwytywane w celu wykonania gestu systemowego, jeśli wcześniej zostało wysłane zdarzenieMotionEvent.ACTION_DOWN
. - [C-6-4] NALEŻY zapewnić użytkownikowi możliwość przełączenia się na ekranową nawigację opartą na przyciskach (np. w Ustawieniach).
- NALEŻY udostępnić funkcję ekranu głównego jako przesunięcie palcem od dołu ekranu w obecnej orientacji.
- NALEŻY udostępnić funkcję Ostatnie jako gest przesunięcia w górę i przytrzymania przed zwalnieniem, z tego samego obszaru co gest powrotu do ekranu głównego.
- Gesty, które rozpoczynają się w ramach aplikacji
WindowInsets#getMandatorySystemGestureInsets()
, NIE powinny być blokowane przez prostokąty wykluczenia udostępniane przez aplikację na pierwszym planie za pomocąView#setSystemGestureExclusionRects()
.
Jeśli funkcja nawigacji jest dostępna w dowolnym miejscu po lewej i po prawej stronie w ramach bieżącej orientacji ekranu:
- [C-7-1] Funkcja nawigacji MUSI umożliwiać powrót wstecz i musi być dostępna przez przesunięcie palcem od lewej lub prawej krawędzi ekranu w zależności od bieżącej orientacji ekranu.
- [C-7-2] Jeśli po lewej lub prawej stronie ekranu są dostępne niestandardowe panele systemowe, które można przesunąć, muszą one znajdować się w górnej 1/3 ekranu. Muszą też mieć wyraźny, trwały wizualny wskaźnik, że przesunięcie spowoduje wyświetlenie wspomnianych paneli, a nie przycisku Wstecz. Panel systemowy MOŻE zostać skonfigurowany przez użytkownika tak, aby znajdował się poniżej górnej 1/3 krawędzi ekranu, ale panel systemowy NIE MOŻE zajmować więcej niż 1/3 krawędzi.
- [C-7-3] Jeśli w aplikacji na pierwszym planie ustawione są flagi View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, przesuwanie palcem od krawędzi ekranu MUSI działać tak, jak zostało zaimplementowane w AOSP, co jest opisane w SDK.
- [C-7-4] Jeśli w aplikacji na pierwszym planie ustawione są flagi View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT lub WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, niestandardowe panele systemowe, które można przesuwać, MUSZĄ być ukryte, dopóki użytkownik nie wprowadzi lub nie rozjaśni pasków systemowych (np. paska nawigacyjnego i paska stanu) zgodnie z implementacją w AOSP.
Jeśli dostępna jest funkcja nawigacji wstecz, a użytkownik anuluje gest Wstecz:
- [C-8-1] Musi zostać wywołana funkcja
OnBackInvokedCallback.onBackCancelled()
. - [C-8-2] Nie należy wywoływać funkcji
OnBackInvokedCallback.onBackInvoked()
. - [C-8-3] Zdarzenie KEYCODE_BACK NIE MOŻE zostać wysłane.
Jeśli funkcja nawigacji wstecz jest dostępna, ale aplikacja na pierwszym planie NIE ma zarejestrowanego OnBackInvokedCallback
:
- System powinien wyświetlić animację dla aplikacji na pierwszym planie, która sugeruje, że użytkownik chce wrócić, zgodnie z AOSP.
Jeśli implementacje urządzeń obsługują interfejs API systemu setNavBarMode
, aby umożliwić każdej aplikacji systemowej z uprawnieniem android.permission.STATUS_BAR
ustawienie trybu paska nawigacyjnego, to:
- [C-9-1] Musisz zapewnić obsługę ikon przyjaznych dzieciom lub nawigacji opartej na przyciskach zgodnie z kodem AOSP.
7.2.4. Dotykowe wprowadzanie danych
Android obsługuje różne systemy wskaźników, takie jak ekrany dotykowe, panele dotykowe i urządzenia z fałszywym wejściem dotykowym. Implementacje urządzeń z ekranem dotykowym są powiązane z ekranem w taki sposób, aby użytkownik miał wrażenie bezpośredniej manipulacji elementami na ekranie. Ponieważ użytkownik dotyka ekranu bezpośrednio, system nie wymaga żadnych dodatkowych elementów, które wskazywałyby na manipulowanie obiektami.
Implementacje na urządzeniu:
- POWINIEN zawierać system sterowania za pomocą wskaźnika (podobny do myszy lub dotykowy).
- NALEŻY obsługiwać wskaźniki śledzone niezależnie.
Jeśli implementacje urządzeń zawierają ekran dotykowy (jednodotykowy lub lepszy) na głównym ekranie zgodnym z Androidem, muszą:
- [C-1-1] W polu interfejsu API
Configuration.touchscreen
musisz podać wartośćTOUCHSCREEN_FINGER
. - [C-1-2] MUST report the
android.hardware.touchscreen
andandroid.hardware.faketouch
feature flags.
Jeśli implementacje urządzeń obejmują ekran dotykowy, który może rejestrować więcej niż jedno dotknięcie na głównym ekranie zgodnym z Androidem, muszą:
- [C-2-1] NALEŻY podać odpowiednie flagi funkcji
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
,android.hardware.touchscreen.multitouch.jazzhand
, odpowiadające typowi konkretnego ekranu dotykowego na urządzeniu.
Jeśli implementacje urządzeń korzystają z zewnętrznego urządzenia wejściowego, takiego jak mysz lub trackball (czyli nie dotykasz bezpośrednio ekranu), do wprowadzania danych na głównym wyświetlaczu zgodnym z Androidem i spełniają wymagania dotyczące fałszywych dotknięć podane w sekcji 7.2.5, to:
- [C-3-1] NIE MOŻESZ zgłaszać żadnych flag funkcji, które zaczynają się od
android.hardware.touchscreen
. - [C-3-2] MUST report only
android.hardware.faketouch
. - [C-3-3] W polu API
Configuration.touchscreen
MUSISZ podać wartośćTOUCHSCREEN_NOTOUCH
.
7.2.5. Symulowane dotykowe wprowadzanie danych
Fałszywy interfejs dotykowy zapewnia system wprowadzania danych użytkownika, który w przybliżeniu odpowiada podzbiorowi funkcji ekranu dotykowego. Na przykład mysz lub pilot, które sterują kursorem ekranowym, naśladują dotyk, ale wymagają od użytkownika najpierw wskazania lub skoncentrowania się, a następnie kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, mysz powietrzna z żyroskopem, wskaźnik z żyroskopem, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe. Android zawiera stałą funkcję android.hardware.faketouch, która odpowiada wysokiej jakości urządzeniu wejściowemu bezdotykowemu (opartym na wskaźniku), takiemu jak mysz lub trackpad, które może odpowiednio emulować dane wejściowe oparte na dotyku (w tym obsługę podstawowych gestów) i wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.
Jeśli implementacje urządzeń nie obejmują ekranu dotykowego, ale zawierają inny system wprowadzania danych za pomocą wskaźnika, który chcą udostępnić, muszą:
- NALEŻY zadeklarować obsługę flagi funkcji
android.hardware.faketouch
.
Jeśli implementacje na urządzeniu deklarują obsługę android.hardware.faketouch
, to:
- [C-1-1] NALEŻY podać bezwzględne pozycje X i Y na ekranie wskaźnika oraz wyświetlić na ekranie wizualny wskaźnik.
- [C-1-2] NALEŻY zgłaszać zdarzenie dotknięcia za pomocą kodu działania, który określa stan, gdy wskaźnik przemieszcza się w dół lub w górę po ekranie.
- [C-1-3] Musi obsługiwać kursor w dół i w górę na obiekcie na ekranie, co umożliwia użytkownikom emulowanie kliknięcia obiektu na ekranie.
- [C-1-4] MUSI obsługiwać ruchy kursora w dół, w górę, w dół i znów w górę w tym samym miejscu na ekranie w ramach określonego progu czasowego, co pozwala użytkownikom emulować dwukrotne kliknięcie na ekranie.
- [C-1-5] Musi obsługiwać kliknięcie w dowolnym miejscu na ekranie, przesuwanie kursora do dowolnego innego miejsca na ekranie, a następnie kliknięcie kursora w górę, co pozwala użytkownikom emulować przeciąganie palcem.
- [C-1-6] Musi obsługiwać wskaźnik w dół, a następnie musi umożliwiać użytkownikom szybkie przeniesienie obiektu w inne miejsce na ekranie, a następnie wskaźnik w górę na ekranie, co pozwala użytkownikom rzucać obiektem na ekranie.
Jeśli implementacje na urządzeniach deklarują obsługę
android.hardware.faketouch.multitouch.distinct
, muszą:
- [C-2-1] MUST declare support for
android.hardware.faketouch
. - [C-2-2] MUSI obsługiwać oddzielne śledzenie co najmniej 2 niezależnych danych wejściowych wskaźnika.
Jeśli implementacje na urządzeniach deklarują obsługę
android.hardware.faketouch.multitouch.jazzhand
, muszą:
- [C-3-1] MUSISZ zadeklarować obsługę
android.hardware.faketouch
. - [C-3-2] MUSI obsługiwać oddzielne śledzenie 5 (śledzenie dłoni z palcami) lub więcej urządzeń wskazujących w pełni niezależnie.
7.2.6. Obsługa kontrolera gier
7.2.6.1. Mapowania przycisków
Implementacje na urządzeniu:
- [C-1-1] MUSI być możliwe mapowanie zdarzeń HID na odpowiadające im stałe
InputEvent
wymienione w tabelach poniżej. Wyższa implementacja Androida spełnia to wymaganie.
Jeśli implementacje urządzeń zawierają kontroler lub są dostarczane z oddzielnym kontrolerem, który umożliwia wprowadzanie wszystkich zdarzeń wymienionych w tabeli poniżej, muszą:
- [C-2-1] NALEŻY zadeklarować flagę funkcji
android.hardware.gamepad
Przycisk | Użycie HID2 | Przycisk Android |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
B1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
Y1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
Przycisk w górę na padzie kierunkowym1 Przycisk w dół na padzie kierunkowym1 |
0x01 0x00393 | AXIS_HAT_Y4 |
Przycisk w lewo na padzie kierunkowym1 Przycisk w prawo na padzie kierunkowym1 |
0x01 0x00393 | AXIS_HAT_X4 |
Przycisk lewego uchwytu1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
Przycisk na prawym uchwycie1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
Kliknięcie lewej gałki1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
Kliknięcie prawego drążka1 | 0x09 0x000F | KEYCODE_BUTTON_THUMBR (107) |
Wstecz1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 Powyższe zastosowania HID muszą być zadeklarowane w ramach Gamepad CA (0x01 0x0005).
3 Ta wartość musi mieć minimalną wartość logiczną 0, maksymalną wartość logiczną 7, minimalną wartość fizyczną 0, maksymalną wartość fizyczną 315, jednostki w stopniach oraz rozmiar raportu 4. Wartość logiczna jest zdefiniowana jako obrót zgodnie z kierunkiem wskazówek zegara od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i wciśnięcie przycisku w górę, a wartość logiczna 1 oznacza obrót o 45° i wciśnięcie przycisków w górę i w lewo.
4. MotionEvent
Analog Controls1 | Użycie HID | Przycisk Android |
---|---|---|
Lepiej: | 0x02 0x00C5 | AXIS_LTRIGGER |
Prawy spust | 0x02 0x00C4 | AXIS_RTRIGGER |
Lewy joystick | 0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
Prawy joystick | 0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
7.2.7. Pilot
Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.3.1.
7.3. Czujniki
Jeśli implementacje na urządzeniu obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, implementacja na urządzeniu MUSI implementować ten interfejs API zgodnie z dokumentacją pakietu Android SDK i dokumentacją na temat źródeł otwartych Androida dotyczącą czujników.
Implementacje na urządzeniu:
- [C-0-1] MUST accurately report the presence or absence of sensors per the
android.content.pm.PackageManager
class. - [C-0-2] MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody
SensorManager.getSensorList()
lub podobnych. - [C-0-3] W przypadku wszystkich pozostałych interfejsów API czujników MUSI działać w racjonalny sposób (np. zwracać
true
lubfalse
w odpowiednich przypadkach, gdy aplikacje próbują zarejestrować słuchaczy, nie wywoływać słuchaczy czujników, gdy odpowiednie czujniki są nieobecne itp.).
Jeśli implementacje na urządzeniach obejmują określony typ czujnika z odpowiednim interfejsem API dla deweloperów zewnętrznych, mogą one:
- [C-1-1] Zgłoszenie wszystkich pomiarów czujnika musi wykorzystywać odpowiednie wartości z Międzynarodowego Systemu Jednostek (metrycznych) dla każdego typu czujnika zgodnie z definicją w dokumentacji pakietu SDK Androida.
- [C-1-2] MUST report sensor data with a maximum latency of 100 milliseconds + 2 * sample_time for the case of a sensor stream with a maximum requested latency of 0 ms when the application processor is active. To opóźnienie nie obejmuje opóźnień związanych z filtrowaniem.
- [C-1-3] NALEŻY zgłaszać pierwszą próbkę czujnika w ciągu 400 milisekund + 2 * sample_time od momentu aktywacji czujnika. W przypadku tej próbki dopuszczalna jest dokładność 0.
- [C-1-4] W przypadku każdego interfejsu API oznaczonego w dokumentacji pakietu SDK Androida jako ciągły czujnik implementacje na urządzeniu MUSZĄ stale dostarczać okresowych próbek danych, których jitter (zdefiniowany jako odchylenie standardowe różnicy wartości raportowanych wartości sygnału czasowego między kolejnymi zdarzeniami) powinien być mniejszy niż 3%.
- [C-1-5] Musisz zadbać o to, aby strumień zdarzeń z czujnika: – nie uniemożliwi procesorowi na urządzeniu przejścia w stan zawieszenia ani nie wybudzi go ze stanu zawieszenia.
- [C-1-6] Zdarzenie musi przekazywać czas w nanosekundach zgodnie z definicją w dokumentacji Android SDK, reprezentujący czas wystąpienia zdarzenia i zsynchronizowany z zegarem SystemClock.elapsedRealtimeNano().
- [C-SR-1] Zalecamy, aby błąd synchronizacji sygnatury czasowej był mniejszy niż 100 milisekund, a błąd synchronizacji sygnatury czasowej powinien być mniejszy niż 1 milisekunda.
- Gdy aktywowanych jest kilka czujników, zużycie energii NIE POWINNA przekraczać sumy zużycia energii poszczególnych czujników.
Powyższa lista nie jest wyczerpująca. Należy uznać za wiarygodne udokumentowane działanie pakietu Android SDK oraz dokumentacja Androida na temat czujników w języku C.
Jeśli implementacje na urządzeniach obejmują określony typ czujnika z odpowiednim interfejsem API dla deweloperów zewnętrznych, mogą one:
- [C-1-6] NALEŻY ustawić niezerową rozdzielczość dla wszystkich czujników i przekazać tę wartość za pomocą metody interfejsu API
Sensor.getResolution()
.
Niektóre typy czujników są złożone, co oznacza, że można je uzyskać na podstawie danych pochodzących z co najmniej jednego innego czujnika. (np. czujnik orientacji i czujnik przyspieszenia liniowego).
Implementacje na urządzeniu:
- NALEŻY wdrożyć te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w typach czujników.
Jeśli implementacje urządzeń obejmują czujnik złożony, muszą:
- [C-2-1] NALEŻY zaimplementować czujnik zgodnie z opisem w dokumentacji do Androida Open Source dotyczącej złożonych czujników.
Jeśli implementacje na urządzeniach obejmują określony typ czujnika, który ma odpowiedni interfejs API dla zewnętrznych programistów, a czujnik raportuje tylko jedną wartość, implementacje na urządzeniach:
- [C-3-1] NALEŻY ustawić rozdzielczość na 1 dla czujnika i przekazać wartość za pomocą metody interfejsu API
Sensor.getResolution()
.
Jeśli implementacje urządzenia zawierają określony typ czujnika, który obsługuje SensorAdditionalInfo#TYPE_VEC3_CALIBRATION, a czujnik jest udostępniany deweloperom zewnętrznym, mogą oni:
- [C-4-1] W dostarczonych danych NIE MOŻE być żadnych stałych, fabrycznie określonych parametrów kalibracji.
Jeśli implementacje urządzeń zawierają kombinację 3-osiowego akcelerometru, 3-osiowego czujnika żyroskopowego lub czujnika magnetycznego, są:
- [C-SR-2] ZALECAMY, aby akcelerometr, żyroskop i magnetometr miały stałą pozycję względną, tak aby w przypadku urządzenia z możliwością zmiany kształtu (np. składanego) osie czujników były wyrównane i zgodne z systemem współrzędnych czujników w wszystkich możliwych stanach transformacji urządzenia.
7.3.1. Akcelerometr
Implementacje na urządzeniu:
- [C-SR-1] Zdecydowanie zalecamy dodanie 3-osiowego akcelerometru.
Jeśli implementacje na urządzeniu obejmują akcelerometr, muszą:
- [C-1-1] Musi być możliwe raportowanie zdarzeń z częstotliwością co najmniej 50 Hz.
- [C-1-3] MUSI być zgodny z systemem współrzędnych czujników Androida, jak określono w interfejsach API Androida.
- [C-1-4] MUSI być w stanie mierzyć przyspieszenie od swobodnego spadania do 4-krotnego przyspieszenia ziemskiego(4g) lub więcej w dowolnej osi.
- [C-1-5] Rozdzielczość musi wynosić co najmniej 12 bitów.
- [C-1-6] Musi mieć odchylenie standardowe nie większe niż 0,05 m/s2, gdzie odchylenie standardowe powinno być obliczane dla każdej osi na podstawie próbek zebranych w okresie co najmniej 3 sekund przy najszybszej częstotliwości próbkowania.
- Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.
- NALEŻY mieć rozdzielczość co najmniej 16-bitową.
- NALEŻY je kalibrować podczas użytkowania, jeśli ich właściwości zmieniają się w trakcie cyklu życia, oraz zachować parametry kompensacji między ponownymi uruchamianiami urządzenia.
- POWINIEN być kompensowany temperaturowo.
Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr, muszą:
- [C-2-1] MUSISZ wdrożyć i zgłosić czujnik
TYPE_ACCELEROMETER
. - [C-SR-4] MOCNO zalecamy wdrożenie złożonego czujnika
TYPE_SIGNIFICANT_MOTION
. - [C-SR-5] ZALECAMY wdrażanie i raportowanie czujnika
TYPE_ACCELEROMETER_UNCALIBRATED
. Zalecamy, aby urządzenia z Androidem spełniały ten wymóg, aby można było je zaktualizować do przyszłej wersji platformy, w której może on stać się wymagany. - NALEŻY zaimplementować czujniki złożone
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
zgodnie z opisem w dokumentacji pakietu Android SDK.
Jeśli implementacje urządzeń zawierają akcelerometr o mniej niż 3 osiach, nie mogą:
- [C-3-1] MUSISZ wdrożyć i zgłosić czujnik
TYPE_ACCELEROMETER_LIMITED_AXES
. - [C-SR-6] STRONGLY_RECOMMENDED wdrożenie i raportowanie czujnika
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
.
Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr i jeden z tych czujników złożonych: TYPE_SIGNIFICANT_MOTION
, TYPE_TILT_DETECTOR
, TYPE_STEP_DETECTOR
, TYPE_STEP_COUNTER
:
- [C-4-1] Łączna wartość zużycia energii MUSI być zawsze mniejsza niż 4 mW.
- Wartości te powinny być niższe niż 2 mW i 0,5 mW w przypadku dynamicznego lub statycznego stanu urządzenia.
Jeśli implementacje urządzenia obejmują 3-osiowy akcelerometr i 3-osiowy żyroskop:
- [C-5-1] OBOWIĄZKOWO wdrożyć czujniki złożone
TYPE_GRAVITY
iTYPE_LINEAR_ACCELERATION
. - [C-SR-7] MOCNO ZALECAMY wdrożenie czujnika złożonego
TYPE_GAME_ROTATION_VECTOR
.
Jeśli implementacje urządzenia obejmują 3-osiowy akcelerometr, 3-osiowy czujnik żyroskopowy i czujnik magnetyczny, muszą:
- [C-6-1] MUSISZ zastosować czujnik złożony
TYPE_ROTATION_VECTOR
.
7.3.2. Magnetometr
Implementacje na urządzeniu:
- [C-SR-1] Zdecydowanie zalecamy uwzględnienie 3-osiowego magnetometru (kompasu).
Jeśli implementacje urządzeń obejmują 3-osiowy magnetometr, muszą:
- [C-1-1] MUSISZ zaimplementować czujnik
TYPE_MAGNETIC_FIELD
. - [C-1-2] Musisz mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 10 Hz i powinnaś raportować zdarzenia z częstotliwością co najmniej 50 Hz.
- [C-1-3] MUSI być zgodny z systemem współrzędnych czujnika Androida, jak określono w interfejsach API Androida.
- [C-1-4] MUSI umożliwiać pomiar w zakresie od -900 µT do +900 µT na każdej osi przed nasyceniem.
- [C-1-5] WARTOŚĆ offsetu pola magnetycznego stałego żelaza MUSI być mniejsza niż 700 µT, a WARTOŚĆ offsetu pola magnetycznego stałego MUSI być mniejsza niż 200 µT. Aby to osiągnąć, należy umieścić magnetometr z dala od pól magnetycznych dynamicznych (wywołanych przez prąd) i statycznych (wywołanych przez magnes).
- [C-1-6] Rozdzielczość musi być równa lub większa niż 0,6 µT.
- [C-1-7] MUSI obsługiwać kalibrację online i kompensację błędu przesunięcia fazowego oraz zachowywać parametry kompensacji po ponownym uruchomieniu urządzenia.
- [C-1-8] NALEŻY zastosować kompensację miękkiego żelaza. Kalibrację można przeprowadzić podczas użytkowania lub podczas produkcji urządzenia.
- [C-1-9] Odchylenie standardowe obliczone dla każdej osi na podstawie próbek zebranych w ciągu co najmniej 3 sekund przy najszybszym tempie próbkowania nie może przekraczać 1, 5 µT; ODPOWIEDNIO powinno wynosić nie więcej niż 0, 5 µT.
- [C-1-10] OBOWIĄZKOWO wdrożyć czujnik
TYPE_MAGNETIC_FIELD_UNCALIBRATED
.
Jeśli implementacje urządzenia zawierają 3-osiowy magnetometr, akcelerometr i 3-osiowy żyroskop, to:
- [C-2-1] MUSISZ zastosować czujnik złożony
TYPE_ROTATION_VECTOR
.
Jeśli implementacje urządzeń zawierają 3-osiowy magnetometr i akcelerometr, muszą:
- MOŻNA zaimplementować czujnik
TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
Jeśli implementacje urządzeń zawierają 3-osiowy magnetometr, akcelerometr i czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR
, muszą:
- [C-3-1] MUSI zużywać mniej niż 10 mW.
- POWINIEN zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie zbiorczym przy 10 Hz.
7.3.3. GPS
Implementacje na urządzeniu:
- [C-SR-1] Zdecydowanie zalecamy dołączenie odbiornika GPS/GNSS.
Jeśli implementacje urządzeń zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps
, to:
- [C-1-1] Musi obsługiwać dane wyjściowe lokalizacji z częstotliwością co najmniej 1 Hz, gdy są one żądane za pomocą
LocationManager#requestLocationUpdate
. - [C-1-2] Musi być możliwe określenie lokalizacji w warunkach otwartego nieba (silne sygnały, pomiar HDOP < 2) w ciągu 10 sekund (szybki czas pierwszego wyznaczenia), gdy urządzenie jest połączone z internetem o szybkości co najmniej 0,5 Mb/s. Wymaganie to jest zwykle realizowane przez użycie jakiejś formy wspomaganej lub przewidywanej techniki GPS/GNSS w celu zminimalizowania czasu ustalania pozycji przez GPS/GNSS (dane wspomagania obejmują czas odniesienia, lokalizację odniesienia i ephemeridy satelity/zegar).
- [C-1-6] Po obliczeniu lokalizacji implementacje na urządzeniu MUSZĄ określić lokalizację na otwartym niebie w ciągu 5 sekund od ponownego uruchomienia żądań lokalizacji, maksymalnie do godziny od początkowego obliczenia lokalizacji, nawet jeśli kolejne żądanie zostanie wysłane bez połączenia danych lub po wyłączeniu i ponownie włączeniu zasilania.
W warunkach otwartego nieba po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 1 m/s²:
- [C-1-3] W co najmniej 95% czasu urządzenie MUSI być w stanie określić lokalizację z dokładnością do 20 metrów, a prędkość z dokładnością do 0, 5 metra na sekundę.
- [C-1-4] MUSI jednocześnie śledzić i przekazywać informacje za pomocą
GnssStatus.Callback
co najmniej 8 satelitów z jednej konstelacji. - POWINIEN być w stanie śledzić jednocześnie co najmniej 24 satelity z różnych konstelacji (np. GPS + co najmniej 1 z Glonas, BeiDou, Galileo).
[C-SR-2] MOCNO ZALECAMY, aby podczas połączenia alarmowego nadal dostarczać normalne dane o lokalizacji GPS/GNSS za pomocą interfejsu API dostawcy danych o lokalizacji GNSS.
[C-SR-3] MOCNO zalecamy raportowanie pomiarów GNSS ze wszystkich śledzonych konstelacji (jak podano w wiadomościach GnssStatus), z wyjątkiem SBAS.
[C-SR-4] MOCNO zaleca się raportowanie AGC i częstości pomiarów GNSS.
[C-SR-5] MOCNO zaleca się raportowanie wszystkich szacunków dokładności (w tym kierunku, prędkości i pionu) w ramach każdej lokalizacji GPS/GNSS.
[C-SR-6] MOCNO zalecamy zgłaszanie pomiarów GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
[C-SR-7] MOCNO ZALECAMY raportowanie pseudozakresów i szybkości GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, w stanie spoczynku lub przy przyspieszeniu poniżej 0,2 metra na sekundę kwadratową, wystarczają do obliczenia pozycji z dokładnością do 20 metrów i szybkości z dokładnością do 0,2 metra na sekundę w co najmniej 95% czasu.
7.3.4. Żyroskop
Implementacje na urządzeniu:
- [C-SR-1] Zdecydowanie zalecamy dodanie czujnika żyroskopu.
Jeśli implementacje urządzeń zawierają żyroskop:
- [C-1-1] Musi być możliwe raportowanie zdarzeń z częstotliwością co najmniej 50 Hz.
- [C-1-4] Rozdzielczość musi wynosić co najmniej 12 bitów.
- [C-1-5] MUSI być z kompensacją temperatury.
- [C-1-6] MUSI być skalibrowany i skompensowany podczas użytkowania oraz zachowywać parametry kompensacji po ponownym uruchomieniu urządzenia.
- [C-1-7] Wariancja musi być mniejsza niż 1e-7 rad^2 / s^2 na Hz (wartość na Hz lub rad^2 / s). Odchylenie może się zmieniać wraz z częstotliwością próbkowania, ale MUSI być ograniczone do tej wartości. Inaczej mówiąc, jeśli zmierzymy odchylenie od średniej żyroskopu przy częstotliwości próbkowania 1 Hz, nie powinno ono przekraczać 1e-7 rad^2/s^2.
- [C-SR-2] Błąd kalibracji powinien być mniejszy niż 0,01 rad/s, gdy urządzenie jest nieruchome w temperaturze pokojowej.
- [C-SR-3] Zaleca się, aby rozdzielczość była co najmniej 16-bitowa.
- Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.
Jeśli implementacja urządzenia obejmuje 3-osiowy żyroskop:
- [C-2-1] NALEŻY wdrożyć czujnik
TYPE_GYROSCOPE
. - [C-SR-4] Zdecydowanie zalecamy wdrożenie czujnika
TYPE_GYROSCOPE_UNCALIBRATED
.
Jeśli implementacja urządzenia zawiera żyroskop z mniej niż 3 osiami, urządzenie:
- [C-3-1] MUSISZ wdrożyć i zgłosić czujnik
TYPE_GYROSCOPE_LIMITED_AXES
. - [C-SR-5] STRONGLY_RECOMMENDED wdrożenie i raportowanie czujnika
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
.
Jeśli implementacje urządzenia zawierają 3-osiowy żyroskop, akcelerometr i magnetometr, muszą:
- [C-4-1] MUSISZ zastosować czujnik złożony
TYPE_ROTATION_VECTOR
.
Jeśli implementacje urządzeń zawierają 3-osiowy akcelerometr i 3-osiowy żyroskop:
- [C-5-1] OBOWIĄZKOWA implementacja czujników złożonych
TYPE_GRAVITY
iTYPE_LINEAR_ACCELERATION
. - [C-SR-6] MOCNO zalecamy wdrożenie czujnika złożonego
TYPE_GAME_ROTATION_VECTOR
.
7.3.5. barometr;
Implementacje na urządzeniu:
- [C-SR-1] BARDZO ZALECAMY uwzględnienie barometru (czujnika ciśnienia atmosferycznego).
Jeśli implementacja urządzenia zawiera barometr, musi:
- [C-1-1] MUSISZ wdrożyć i zgłosić czujnik
TYPE_PRESSURE
. - [C-1-2] MUSI być w stanie przesyłać zdarzenia z częstotliwością co najmniej 5 Hz.
- [C-1-3] MUSI być z kompensacją temperatury.
- [C-SR-2] ZALECAMY, aby pomiary ciśnienia były rejestrowane w zakresie 300–1100 hPa.
- Powinien mieć bezwzględną dokładność 1 hPa.
- POWINIEN mieć dokładność względną 0,12 hPa w zakresie 20 hPa (co odpowiada dokładności około 1 m przy zmianie wysokości około 200 m na poziomie morza).
7.3.6. Thermometer
Jeśli implementacje urządzeń zawierają termometr otoczenia (czujnik temperatury), to:
- [C-1-1] MUSI definiować
SENSOR_TYPE_AMBIENT_TEMPERATURE
dla czujnika temperatury otoczenia, a czujnik MUSI mierzyć temperaturę otoczenia (temperaturę w pomieszczeniu lub kabinie pojazdu), w którym użytkownik wchodzi w interakcję z urządzeniem, w stopniach Celsjusza.
Jeśli implementacje urządzeń zawierają czujnik temperatury, który mierzy temperaturę inną niż temperatura otoczenia, np. temperaturę procesora, muszą:
- [C-2-1] NIE NALEŻY definiować
SENSOR_TYPE_AMBIENT_TEMPERATURE
dla czujnika temperatury.
Jeśli implementacje urządzeń zawierają czujnik do monitorowania temperatury skóry, urządzenia te:
- [C-SR-1] ZALECAMY obsługę interfejsu API PowerManager.getThermalHeadroom.
7.3.7. Fotometr
- Implementacje urządzeń MOGĄ zawierać fotometr (czujnik jasności otoczenia).
7.3.8. Czujnik zbliżeniowy
- Urządzenia mogą być wyposażone w czujnik zbliżeniowy.
Jeśli implementacje urządzeń zawierają czujnik zbliżeniowy i przekazują tylko binarne odczyty „blisko” lub „daleko”, to:
- [C-1-1] NALEŻY mierzyć odległość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI być skierowany na obiekty znajdujące się blisko ekranu, ponieważ jego głównym celem jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy o dowolnej orientacji, NIE MOŻE być on dostępny za pomocą tego interfejsu API.
- [C-1-2] Musi mieć co najmniej 1 bita dokładności.
- [C-1-3] W przypadku odczytu z bliska należy użyć wartości 0 cm, a w przypadku odczytu z daleka – 5 cm.
- [C-1-4] NALEŻY podać maksymalny zakres i rozdzielczość 5.
7.3.9. Czujniki o wysokiej wierności
Jeśli implementacje urządzeń zawierają zestaw czujników o wyższej jakości, jak określono w tej sekcji, i są dostępne dla aplikacji innych firm, mogą:
- [C-1-1] Identyfikator musi być podany za pomocą flagi funkcji
android.hardware.sensor.hifi_sensors
.
Jeśli implementacje na urządzeniu deklarują android.hardware.sensor.hifi_sensors
, to:
[C-2-1] Musi zawierać czujnik
TYPE_ACCELEROMETER
, który:- Zakres pomiarowy musi wynosić co najmniej -8 g do +8 g. BARDZO ZALECAMY, aby zakres pomiarowy wynosił co najmniej -16 g do +16 g.
- Rozdzielczość pomiaru MUSI wynosić co najmniej 2048 LSB/g.
- Częstotliwość pomiarów musi wynosić co najmniej 12,5 Hz.
- Musi mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz. Zaleca się, aby obsługiwał interfejs SensorDirectChannel
RATE_VERY_FAST
. - Szum pomiarowy nie może przekraczać 400 μg/√Hz.
- NALEŻY wdrożyć niebudzącą formę tego czujnika z buforem o pojemności co najmniej 3000 zdarzeń czujnika.
- Musisz mieć ustawienie poboru mocy w ramach przetwarzania w partiach nie większe niż 3 mW.
- [C-SR-1] ZALECAMY, aby pasmo pomiarowe 3 dB mieściło się w ramach co najmniej 80% częstotliwości Nyquista i były ograniczone do widma szumu białego.
- Przyspieszenie powinno być losowo mniejsze niż 30 μg/√Hz przy temperaturze pokojowej.
- Zmiana stycznej w zależności od temperatury powinna wynosić ≤ +/- 1 mg/°C.
- USTAWIĆ nieliniowości linii dopasowania najlepszego do danych na poziomie ≤ 0,5% oraz zmianę czułości w zależności od temperatury na poziomie ≤ 0,03%/°C.
- POWINIEN mieć czułość na osi poprzecznej mniejszą niż 2,5 % i zmienność czułości na osi poprzecznej mniejszą niż 0,2% w zakresie temperatury pracy urządzenia.
[C-2-2] MUSI zawierać
TYPE_ACCELEROMETER_UNCALIBRATED
z tymi samymi wymaganiami jakościowymi coTYPE_ACCELEROMETER
.[C-2-3] MUSI zawierać czujnik
TYPE_GYROSCOPE
, który:- Zakres pomiarowy musi wynosić co najmniej -1000 do +1000 dps.
- Rozdzielczość pomiaru MUSI wynosić co najmniej 16 LSB/dps.
- Częstotliwość pomiarów musi wynosić co najmniej 12,5 Hz.
- Musi mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz. Zaleca się, aby obsługiwał interfejs SensorDirectChannel
RATE_VERY_FAST
. - Szum pomiarowy nie może być większy niż 0,014°/s/√Hz.
- [C-SR-2] MOCNO zaleca się, aby pasmo pomiarowe 3 dB było co najmniej 80% częstotliwości Nyquista, a spektr szumu białego mieścił się w tym paśmie.
- W temperaturze pokojowej szybkość losowego spaceru powinna wynosić mniej niż 0,001 °/s √Hz.
- Zmiana przesunięcia w zależności od temperatury powinna wynosić ≤ ± 0,05°/s/°C.
- Zmiana czułości w zależności od temperatury powinna wynosić ≤ 0,02% / °C.
- Powinien mieć linię najlepszego dopasowania o nielinearności mniejszej niż 0,2%.
- gęstość szumów powinna wynosić ≤ 0,007 °/s/√Hz;
- Błąd kalibracji powinien być mniejszy niż 0,002 rad/s w zakresie temperatury 10–40 °C, gdy urządzenie jest nieruchome.
- Czułość na przyspieszenie powinna być mniejsza niż 0,1°/s/g.
- W zakresie temperatury pracy urządzenia czułość na oś poprzeczną powinna wynosić < 4,0%, a różnica czułości na oś poprzeczną < 0,3%.
[C-2-4] Musisz mieć
TYPE_GYROSCOPE_UNCALIBRATED
spełniający te same wymagania dotyczące jakości coTYPE_GYROSCOPE
.[C-2-5] MUSI zawierać czujnik
TYPE_GEOMAGNETIC_FIELD
, który:- Zakres pomiarowy musi wynosić co najmniej -900 do +900 μT.
- Rozdzielczość pomiaru musi wynosić co najmniej 5 LSB/uT.
- Częstotliwość pomiaru MUSI wynosić co najmniej 5 Hz.
- Maksymalna częstotliwość pomiaru musi wynosić co najmniej 50 Hz.
- Szum pomiarowy nie może przekraczać 0,5 uT.
[C-2-6] Musisz mieć
TYPE_MAGNETIC_FIELD_UNCALIBRATED
, który spełnia te same wymagania dotyczące jakości coTYPE_GEOMAGNETIC_FIELD
, a dodatkowo:- NALEŻY wdrożyć niebudzącą formę tego czujnika z możliwością buforowania co najmniej 600 zdarzeń czujnika.
- [C-SR-3] MOCNO zalecamy, aby widmo szumu białego mieściło się w zakresie od 1 Hz do co najmniej 10 Hz, gdy częstotliwość raportowania wynosi 50 Hz lub więcej.
[C-2-7] MUSI mieć czujnik
TYPE_PRESSURE
, który:- Zakres pomiarowy musi wynosić co najmniej 300–1100 hPa.
- Musi mieć rozdzielczość pomiaru co najmniej 80 LSB/hPa.
- Częstotliwość pomiaru MUSI wynosić co najmniej 1 Hz.
- Maksymalna częstotliwość pomiaru musi wynosić co najmniej 10 Hz.
- Szum pomiarowy nie może przekraczać 2 Pa/√Hz.
- NALEŻY wdrożyć wersję tego czujnika bez funkcji budzenia z możliwością buforowania co najmniej 300 zdarzeń czujnika.
- Musisz mieć ustawienie poboru mocy w trybie zbiorczym nie większe niż 2 mW.
[C-2-8] MUSI zawierać czujnik
TYPE_GAME_ROTATION_VECTOR
.[C-2-9] MUSI mieć czujnik
TYPE_SIGNIFICANT_MOTION
, który:- Zużycie energii MUSI wynosić nie więcej niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
[C-2-10] MUSI mieć czujnik
TYPE_STEP_DETECTOR
, który:- NALEŻY zaimplementować wersję tego czujnika bez funkcji budzenia z możliwością buforowania co najmniej 100 zdarzeń czujnika.
- Zużycie energii MUSI wynosić nie więcej niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
- Musi zużywać nie więcej niż 4 mW energii podczas przetwarzania w grupach.
[C-2-11] MUSI mieć czujnik
TYPE_STEP_COUNTER
, który:- Zużycie energii MUSI wynosić nie więcej niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
[C-2-12] MUSI zawierać czujnik
TILT_DETECTOR
, który:- Zużycie energii MUSI wynosić nie więcej niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
[C-2-13] Czas stempla zdarzeń tego samego zdarzenia fizycznego zarejestrowanego przez akcelerometr, żyroskop i magnetometr MUSI mieścić się w 2, 5 milisekundy od siebie. Sygnatura czasowa zdarzenia fizycznego zarejestrowanego przez akcelerometr i żyroskop POWINNA różnić się od siebie o nie więcej niż 0,25 ms.
[C-2-14] Sygnatury czasowe zdarzeń czujnika żyroskopu muszą być podawane w tym samym systemie czasowym co sygnały czasowe podsystemu kamery i z dokładnością do 1 milisekundy.
[C-2-15] NALEŻY przesyłać próbki do aplikacji w ciągu 5 milisekund od momentu, gdy dane są dostępne w dowolnym z wymienionych powyżej czujników fizycznych, do aplikacji.
[C-2-16] NIE MOŻE zużywać więcej niż 0,5 mW, gdy urządzenie jest nieruchome, i 2,0 mW, gdy urządzenie się porusza, gdy włączona jest dowolna kombinacja tych czujników:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] MOŻE mieć czujnik
TYPE_PROXIMITY
, ale jeśli jest obecny, MUSI mieć minimalną pojemność bufora wynoszącą 100 zdarzeń czujnika.
Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje ona moc pobieraną przez cały łańcuch czujników, czyli czujnik, wszelkie układy pomocnicze, dedykowany system przetwarzania czujników itp.
Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników, muszą:
- [C-3-1] MUSISZ poprawnie zadeklarować obsługę typów kanałów bezpośrednich i poziom stawek raportowania bezpośredniego za pomocą interfejsu API
isDirectChannelTypeSupported
igetHighestDirectReportRateLevel
. - [C-3-2] Musi obsługiwać co najmniej 1 z 2 typów kanałów bezpośrednich czujników dla wszystkich czujników, które deklarują obsługę kanału bezpośredniego czujnika.
- Powinien obsługiwać raportowanie zdarzeń przez kanał bezpośredni czujnika w przypadku głównego czujnika (wersja bez funkcji budzenia) tych typów:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. Czujniki biometryczne
Więcej informacji o pomiarach bezpieczeństwa odblokowywania biometrycznego znajdziesz w dokumentacji Pomiar bezpieczeństwa biometrycznego.
Jeśli implementacja urządzenia obejmuje bezpieczny ekran blokady, musi:
- NALEŻY użyć czujnika biometrycznego
Sensory biometryczne można zaklasyfikować jako klasy 3 (dawniej silne), klasy 2 (dawniej słabe) lub klasy 1 (dawniej wygodne) na podstawie współczynników akceptacji fałszywych danych i podwójnych kont oraz bezpieczeństwa łańcucha przetwarzania danych biometrycznych. Ta klasyfikacja określa możliwości interfejsu czujnika biometrycznego w połączeniu z platformą i aplikacjami innych firm. Aby zostać sklasyfikowanym jako Class 1, Class 2 lub Class 3, czujnik musi spełniać dodatkowe wymagania podane poniżej. Zarówno dane biometryczne klasy 2, jak i klasy 3 zyskują dodatkowe możliwości, opisane poniżej.
Jeśli implementacje urządzeń udostępniają czujnik biometryczny aplikacjom innych firm za pomocą android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt i android.provider.Settings.ACTION_BIOMETRIC_ENROLL, to:
- [C-4-1] MUSI spełniać wymagania dotyczące danych biometrycznych klasy 3 lub klasy 2, zgodnie z definicją w tym dokumencie.
- [C-4-2] MUSI rozpoznawać i przestrzegać nazwy każdego parametru zdefiniowanego jako stała w klasie Authenticators oraz wszystkich jej kombinacji. Z drugiej strony NIE MOŻESZ uwzględniać ani rozpoznawać stałych liczb całkowitych przekazywanych do metod canAuthenticate(int) i setAllowedAuthenticators(int) innych niż te, które są udokumentowane jako stałe publiczne w Authenticators i w dowolnych ich kombinacjach.
- [C-4-3] NA URZĄDZENIACH Z TECHNIKAMI IDENTYFIKACJI BIOEMETRYCZNEJ Klasa 3 LUB Klasa 2 NALEŻY WDROŻYĆ DZIAŁANIE ACTION_BIOMETRIC_ENROLL. To działanie MUSI zawierać tylko punkty rejestracji dla klasy 3 lub klasy 2 danych biometrycznych.
Jeśli implementacje urządzeń obsługują biometrykę pasywną:
- [C-5-1] Domyślnie należy wymagać dodatkowego potwierdzenia (np. naciśnięcia przycisku).
- [C-SR-1] ZALECAMY, aby umożliwić użytkownikom zastąpienie ustawień aplikacji i wymaganie potwierdzenia.
- [C-SR-2] MOCNO POLECAMY zabezpieczenie działania potwierdzenia w taki sposób, aby nie można było go sfałszować w systemie operacyjnym lub jądrze. Oznacza to na przykład, że działanie potwierdzenia oparte na przycisku fizycznym jest kierowane przez pin wejścia/wyjścia ogólnego przeznaczenia (GPIO) elementu bezpiecznego (SE), który nie może być sterowany w żaden inny sposób niż przez naciśnięcie przycisku fizycznego.
- [C-5-2] NALEŻY dodatkowo wdrożyć proces domyślnego uwierzytelniania (bez kroku potwierdzenia) odpowiadający parametrowi setConfirmationRequired(boolean), który aplikacje mogą wykorzystywać w procesach logowania.
Jeśli implementacje urządzeń mają wiele czujników biometrycznych, muszą:
- [C-SR-3] MOCNO zalecamy, aby wymagać potwierdzenia tylko jednego elementu danych biometrycznych na jedno uwierzytelnienie (np. jeśli na urządzeniu dostępne są zarówno czytnik linii papilarnych, jak i czujnik twarzy, wywołanie onAuthenticationSucceeded powinno być wysyłane po potwierdzeniu dowolnego z nich).
Aby implementacje urządzeń zezwalały aplikacjom innych firm na dostęp do kluczy w magazynie kluczy, muszą:
- [C-6-1] MUSI spełniać wymagania dotyczące klasy 3 określone w tym paragrafie poniżej.
- [C-6-2] MUST present only Class 3 biometrics when the authentication requires BIOMETRIC_STRONG, or the authentication is invoked with a CryptoObject.
Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 1 (dawniej wygoda), muszą:
- [C-1-1] Wskaźnik fałszywych akceptacji musi być mniejszy niż 0,002%.
- [C-1-2] NALEŻY poinformować, że ten tryb może być mniej bezpieczny niż silny kod PIN, wzór lub hasło, oraz wyraźnie wymienić zagrożenia związane z jego włączeniem, jeśli wskaźniki akceptacji podszycia się pod kogoś innego i podstępnego włamywania się są wyższe niż 7%, zgodnie z protokołami testów biometrycznych na Androidzie.
- [C-1-9] NALEŻY poprosić użytkownika o polecenie użycia zalecanej metody uwierzytelniania głównego (np.kodu PIN, wzoru, hasła) po maksymalnie 20 nieudanych prób i nie mniej niż 90 sekundach od zakończenia weryfikacji biometrycznej. Nieudana próba to próba o odpowiedniej jakości (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.
- [C-SR-4] MOCNO POLECAMY zmniejszenie łącznej liczby prób fałszywych w przypadku weryfikacji biometrycznej określonej w [C-1-9], jeśli wskaźniki akceptacji próby oszustwa i podszycia się pod inną osobę są wyższe niż 7%, zgodnie z protokołami testów biometrycznych Androida.
- [C-1-3] NALEŻY ograniczyć liczbę prób weryfikacji biometrycznej – próba fałszywa to próba o odpowiedniej jakości obrazu (
BIOMETRIC_ACQUIRED_GOOD
), która nie pasuje do zarejestrowanych danych biometrycznych. - [C-SR-5] Zdecydowanie zalecamy ograniczenie liczby prób do 30 sekund po 5 nieudanych próbach weryfikacji biometrycznej (maksymalna liczba nieudanych prób zgodnie z [C-1-9]) – gdzie nieudana próba to próba z odpowiednim jakością uchwycenia (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.
- [C-SR-6] MOCNO zalecamy, aby cała logika ograniczania szybkości znajdowała się w TEE.
- [C-1-10] NALEŻY wyłączyć biometryczne uwierzytelnianie, gdy zostanie uruchomione uwierzytelnianie zapasowe, zgodnie z opisem w sekcji 9.11 w [C-0-2].
- [C-1-11] Procentowy wskaźnik akceptacji podszycia się pod kogoś innego i podszycia się pod kogoś innego nie może być wyższy niż 30%, przy czym (1) wskaźnik akceptacji podszycia się pod kogoś innego i podszycia się pod kogoś innego w przypadku narzędzia do ataków na poziomie prezentacji (PAI) na poziomie A nie może być wyższy niż 30%, a (2) wskaźnik akceptacji podszycia się pod kogoś innego i podszycia się pod kogoś innego w przypadku narzędzia do ataków na poziomie prezentacji (PAI) na poziomie B nie może być wyższy niż 40%, zgodnie z protokołami testów biometrycznych Androida.
- [C-1-4] NALEŻY uniemożliwić dodawanie nowych danych biometrycznych bez uprzedniego ustanowienia łańcucha zaufania, prosząc użytkownika o potwierdzenie istniejącego lub dodanie nowego elementu danych urządzenia (kod PIN, wzór lub hasło) chronionego przez TEE; implementacja projektu Android Open Source zapewnia mechanizm umożliwiający wykonanie tej czynności.
- [C-1-5] NALEŻY całkowicie usunąć wszystkie dane biometryczne umożliwiające identyfikację użytkownika, gdy jego konto zostanie usunięte (w tym przywracając ustawienia fabryczne).
- [C-1-6] MUSI obsługiwać indywidualną flagę dla danego elementu biometrycznego (np.
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
,DevicePolicymanager.KEYGUARD_DISABLE_FACE
lubDevicePolicymanager.KEYGUARD_DISABLE_IRIS
). - [C-1-7] NALEŻY poprosić użytkownika o podanie danych uwierzytelniających (np. kodu PIN, wzoru lub hasła) co najmniej raz na 24 godziny. Uwaga: urządzenia z Androidem 9 lub starszym, które są aktualizowane, MUSZĄ prosić użytkownika o zalecane uwierzytelnienie podstawowe (np. kod PIN, wzór lub hasło) co 72 godziny lub rzadziej.
- [C-1-8] NALEŻY poprosić użytkownika o podanie zalecanej podstawowej metody uwierzytelniania (np. kodu PIN, wzoru, hasła) lub danych biometrycznych klasy 3 (mocnych) po wykonaniu jednej z tych czynności:
- 4-godzinny limit czasu nieaktywności LUB
- 3 nieudane próby uwierzytelnienia biometrycznego.
- Po potwierdzeniu danych logowania na urządzeniu okres bezczynności i liczba nieudanych prób uwierzytelniania są resetowane. Uwaga: urządzenia z Androidem w wersji 9 lub starszej mogą być zwolnione z wymagań C-1-8.
- [C-SR-7] W przypadku nowych urządzeń MOCNO POLECAMY używanie logiki w ramach udostępnionych przez projekt Android Open Source, aby narzucić ograniczenia określone w [C-1-7] i [C-1-8].
- [C-SR-8] MOCNO zaleca się, aby odsetek błędów odrzucenia był mniejszy niż 10%, mierzony na urządzeniu.
- [C-SR-9] W przypadku każdej zarejestrowanej metody biometrycznej BARDZO ZALECAMY, aby opóźnienie było krótsze niż 1 sekunda, liczone od momentu wykrycia danych biometrycznych do odblokowania ekranu.
Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 2 (wcześniej słabą), muszą:
[C-2-1] MUSI spełniać wszystkie wymagania dotyczące klasy 1 wymienione powyżej.
[C-2-2] Procent akceptacji podszycia się pod inną osobę i podszycia się pod inny system nie może być wyższy niż 20%, przy czym (1) procent akceptacji podszycia się pod inną osobę i podszycia się pod inny system w przypadku narzędzia do ataków na poziomie A nie może być wyższy niż 20%, a (2) procent akceptacji podszycia się pod inną osobę i podszycia się pod inny system w przypadku narzędzia do ataków na poziomie B nie może być wyższy niż 30%, zgodnie z protokołami testów biometrycznych Androida.
[C-2-3] MUSI wykonywać dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza przestrzenią użytkownika lub jądrem Androida, takim jak zaufane środowisko wykonawcze (TEE), lub na chipie z bezpiecznym kanałem do odizolowanego środowiska wykonawczego.
[C-2-4] WSZYSTKIE dane identyfikacyjne MUSZĄ być zaszyfrowane i uwierzytelnione kryptograficznie, tak aby nie mogły być pobierane, odczytywane ani zmieniane poza izolowanym środowiskiem wykonawczym. Do tego celu można użyć chipa z bezpiecznym kanałem do izolowanego środowiska wykonawczego zgodnie z dokumentacją w wytycznych dotyczących implementacji na stronie projektu Android Open Source.
[C-2-5] W przypadku uwierzytelniania lub rejestracji biometrycznej za pomocą kamery:
- Musisz obsługiwać kamerę w taki sposób, aby uniemożliwić odczyt lub zmianę jej klatek poza odizolowanym środowiskiem wykonywania lub za pomocą układu z bezpiecznym kanałem do odizolowanego środowiska wykonywania.
- W przypadku rozwiązań z jedną kamerą RGB ramki kamery mogą być odczytywalne poza izolowanym środowiskiem wykonania w celu obsługi operacji takich jak podgląd do rejestracji, ale nie mogą być zmieniane.
[C-2-6] NIE wolno zezwalać aplikacjom innych firm na rozróżnianie poszczególnych rejestracji biometrycznych.
[C-2-7] NIE MOŻESZ zezwolić na dostęp do niezaszyfrowanych danych biometrycznych umożliwiających identyfikację lub danych z nich pochodzących (takich jak embeddingi) procesorowi aplikacji poza kontekstem TEE. Urządzenia z Androidem w wersji 9 lub starszej nie są zwolnione z wymagań C-2-7.
[C-2-8] Musisz mieć bezpieczny kanał przetwarzania, który uniemożliwia wstrzyknięcie danych bezpośrednio do systemu operacyjnego lub jądra w celu fałszywego uwierzytelnienia jako użytkownik. Uwaga: jeśli implementacje urządzeń zostały już uruchomione w wersji Androida 9 lub starszej i nie spełniają wymagań C-2-8, ale można je zaktualizować za pomocą aktualizacji oprogramowania systemowego, MOŻNA je zwolnić z tych wymagań.
[C-SR-10] MOCNO zalecamy uwzględnienie wykrywania żywotności we wszystkich trybach biometrycznych oraz wykrywania uwagi w przypadku biometryki twarzy.
[C-2-9] NALEŻY udostępnić czujnik biometryczny aplikacjom innych firm.
Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 3 (dawniej silne), muszą:
- [C-3-1] MUSI spełniać wszystkie wymagania dotyczące klasy 2 opisane powyżej, z wyjątkiem [C-1-7] i [C-1-8].
- [C-3-2] Musisz zaimplementować magazyn kluczy wspierany sprzętowo.
- [C-3-3] Procentowy wskaźnik akceptacji podszycia się pod inną osobę i podszycia się pod inny system nie może być wyższy niż 7%, przy czym (1) wskaźnik akceptacji podszycia się pod inną osobę i podszycia się pod inny system w przypadku instrumentu ataku na poziomie A nie może być wyższy niż 7%, a (2) wskaźnik akceptacji podszycia się pod inną osobę i podszycia się pod inny system w przypadku instrumentu ataku na poziomie B nie może być wyższy niż 20%, zgodnie z protokołami testów biometrycznych na urządzeniach z Androidem.
- [C-3-4] NALEŻY wymagać od użytkownika podania rekomendowanego głównego uwierzytelnienia (np. kodu PIN, wzoru lub hasła) co 72 godziny lub krócej.
- [C-3-5] NALEŻY ponownie wygenerować identyfikator uwierzytelniania dla wszystkich funkcji biometrycznych klasy 3 obsługiwanych na urządzeniu, jeśli którakolwiek z nich zostanie ponownie zarejestrowana.
- [C-3-6] Klucze w sklepie kluczy muszą być zabezpieczone za pomocą danych biometrycznych i dostępne dla aplikacji innych firm.
Jeśli implementacje urządzeń zawierają czytnik linii papilarnych pod wyświetlaczem (UDFPS), powinny:
- [C-SR-11] ZDECYDOWANIE zaleca się, aby obszar dotykowy UDFPS nie kolidował z sterowaniem za pomocą 3 przycisków (którego niektórzy użytkownicy mogą wymagać ze względu na ułatwienia dostępu).
7.3.11. Czujnik postawy
Implementacje na urządzeniu:
- MOŻE obsługiwać czujnik postawy z 6 stopniami swobody.
Jeśli implementacje urządzeń obsługują czujnik postawy z 6 stopniami swobody, mogą:
- [C-1-1] MUSISZ zaimplementować i zgłaszać
TYPE_POSE_6DOF
czujnik. - [C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.
7.3.12. Czujnik kąta zawiasu
Jeśli implementacje urządzeń obsługują czujnik kąta zawiasów, mogą:
- [C-1-1] NALEŻY wdrożyć i zgłosić
TYPE_HINGLE_ANGLE
. - [C-1-2] MUSI obsługiwać co najmniej 2 wartości z zakresu 0–360° (włącznie, tzn.w tym 0 i 360°).
- [C-1-3] Musisz zwrócić czujnik pobudki dla
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.3.13. IEEE 802.1.15.4 [Przeniesione do 7.4.9]
7.4. Łączność z danymi
7.4.1. Połączenia telefoniczne
Termin „telefonia” w rozumieniu interfejsów API Androida i tego dokumentu odnosi się konkretnie do sprzętu związanego z nawiązywaniem połączeń głosowych i wysyłaniem SMS-ów przez sieć GSM lub CDMA. Podczas gdy te połączenia głosowe mogą być przełączane pakietowo, w przypadku Androida są one traktowane niezależnie od wszelkich połączeń danych, które mogą być stosowane w ramach tej samej sieci. Innymi słowy, funkcje i interfejsy API dotyczące „telefonii” w Androidzie odnoszą się wyłącznie do połączeń głosowych i SMS-ów. Na przykład implementacje urządzeń, które nie mogą nawiązywać połączeń ani wysyłać/odbierać SMS-ów, nie są uważane za urządzenia telefoniczne, niezależnie od tego, czy do przesyłania danych używają sieci komórkowej.
- Android MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami, które nie są telefonami.
Jeśli implementacje urządzeń obejmują telefonię GSM lub CDMA, muszą:
- [C-1-1] NALEŻY zadeklarować flagę funkcji
android.hardware.telephony
i inne flagi podfunkcji zgodnie z technologią. - [C-1-2] Należy wdrożyć pełną obsługę interfejsu API dla tej technologii.
- POWINNA zezwalać na wszystkie dostępne typy usług komórkowych (2G, 3G, 4G, 5G itd.) podczas połączeń alarmowych (niezależnie od typów sieci ustawionych przez
SetAllowedNetworkTypeBitmap()
).
Jeśli implementacje urządzeń nie obejmują sprzętu telefonicznego, nie mogą:
- [C-2-1] NALEŻY wdrożyć pełne interfejsy API jako no-ops.
Jeśli implementacje urządzeń obsługują karty eUICC lub eSIM/wbudowane karty SIM i zawierają zastrzeżony mechanizm udostępniający funkcje eSIM deweloperom zewnętrznym, to:
- [C-3-1] Należy zadeklarować flagę funkcji
android.hardware.telephony.euicc
.
Jeśli implementacje urządzeń nie ustawiają właściwości systemowej ro.telephony.iwlan\_operation\_mode
na „legacy”, to:
- [C-4-1] NIE MOŻESZ raportować „NETWORK_TYPE_IWLAN” za pomocą metody NetworkRegistrationInfo#getAccessNetworkTechnology(), gdy metoda NetworkRegistrationInfo#getTransportType() zwraca „TRANSPORT_TYPE_WWAN” dla tej samej instancji NetworkRegistrationInfo.
Jeśli implementacje urządzeń obsługują rejestrację w ramach pojedynczego IP Multimedia Subsystem (IMS) dla funkcji multimedialnej usługi telefonicznej (MMTEL) i usług RCS oraz muszą spełniać wymagania operatora komórkowego dotyczące używania pojedynczej rejestracji IMS dla całego ruchu sygnalizacyjnego IMS, to:
- [C-5-1] NALEŻY zadeklarować flagę funkcji
android.hardware.telephony.ims
i zapewnić pełną implementację interfejsu ImsService API zarówno w przypadku MMTEL, jak i interfejsu User Capability Exchange API. - [C-5-2] NALEŻY zadeklarować flagę funkcji
android.hardware.telephony.ims.singlereg
i zapewnić pełną implementację interfejsu SipTransport API, interfejsu GbaService API, dedykowanych wskazań biernego za pomocą interfejsu IRadio 1.6 HAL oraz obsługi Provisioning za pomocą serwera Auto Configuration Server (ACS) lub innego zastrzeżonego mechanizmu obsługi Provisioning za pomocą interfejsu IMS Configuration API.
Jeśli implementacje urządzeń zgłaszają funkcję android.hardware.telephony
:
- [C-6-1] Funkcja
SmsManager#sendTextMessage
iSmsManager#sendMultipartTextMessage
MUSI wywoływać odpowiednie wywołania do funkcjiCarrierMessagingService
do obsługi funkcji SMS-ów.SmsManager#sendMultimediaMessage
iSmsManager#downloadMultimediaMessage
MUSIĄ wywoływać odpowiednie wywołania doCarrierMessagingService
w celu zapewnienia funkcji wiadomości multimedialnych. - [C-6-2] Aplikacja wyznaczona przez
android.provider.Telephony.Sms#getDefaultSmsPackage
MUSI używać interfejsów API SmsManager podczas wysyłania i odbierania wiadomości SMS i MMS. Implementacja referencyjna AOSP w pakietach/aplikacji/Menedżerze wiadomości spełnia ten wymóg. - [C-6-3] Aplikacja, która odpowiada na
Intent#ACTION_DIAL
, MUSI obsługiwać wpisywanie dowolnych kodów numerów w formacie*#*#CODE#*#*
i wywoływanie odpowiedniej transmisjiTelephonyManager#ACTION_SECRET_CODE
. - [C-6-4] Aplikacja, która reaguje na
Intent#ACTION_DIAL
, MUSI używaćVoicemailContract.Voicemails#TRANSCRIPTION
, aby wyświetlać użytkownikom transkrypcje poczty głosowej w formie wizualnej, jeśli obsługuje transkrypcje poczty głosowej w tej formie. - [C-6-5] MUST represent all SubscriptionInfo with equivalent
group UUIDs
as a single subscription in all user-visible affordances that display and
control SIM card information. Przykłady takich możliwości: interfejsy ustawień, które pasują do
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
lubEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
. - [C-6-6] NIE MOŻESZ wyświetlać ani zezwalać na kontrolowanie żadnych informacji o subskrypcji z niepustym identyfikatorem UUID grupy i bitem oportunistycznym w żadnych widocznych dla użytkownika elementach umożliwiających konfigurowanie lub kontrolowanie ustawień karty SIM.
Jeśli implementacje na urządzeniu zgłaszają funkcję android.hardware.telephony
i zawierają pasek stanu systemu:
- [C-7-1] NALEŻY wybrać aktywną subskrypcję reprezentującą daną grupę UUID, aby wyświetlić ją użytkownikowi w ramach wszelkich opcji, które podają informacje o stanie karty SIM. Przykładami takich elementów są ikona sygnału sieci komórkowej na pasku stanu lub kafelek Szybkie ustawienia.
- [C-SR-1] MOCNO zalecamy, aby wybrana subskrypcja reprezentacyjna była aktywną subskrypcją danych, chyba że urządzenie jest w trybie rozmowy głosowej, w którym MOCNO zalecamy, aby reprezentacyjna subskrypcja była aktywną subskrypcją głosową.
Jeśli implementacje urządzeń zgłaszają funkcję android.hardware.telephony
:
- [C-6-7] MUSI być w stanie otworzyć i jednocześnie korzystać z maksimum liczby kanałów logicznych (łącznie 20) dla każdego UICC zgodnie z normą ETSI TS 102 221.
- [C-6-8] W aktywnych aplikacjach operatora (oznaczonych jako
TelephonyManager#getCarrierServicePackageName
) nie wolno automatycznie ani bez wyraźnej zgody użytkownika wykonywać następujących czynności:- Odbieranie lub ograniczanie dostępu do sieci
- Odwołanie uprawnień
- Ograniczanie działania aplikacji w tle lub na pierwszym planie poza funkcjami zarządzania energią dostępnymi w AOSP
- Wyłączanie i odinstalowywanie aplikacji
Jeśli implementacje na urządzeniu zgłaszają funkcję android.hardware.telephony
, a wszystkie aktywne subskrypcje nieoportunistyczne, które mają ten sam UUID grupy, są wyłączone, usunięte fizycznie z urządzenia lub oznaczone jako oportunistyczne, urządzenie:
- [C-8-1] NALEŻY automatycznie wyłączyć wszystkie pozostałe aktywne subskrypcje oparte na dostępności w tej samej grupie.
Jeśli implementacje urządzeń obejmują telefonię GSM, ale nie telefonię CDMA, to:
- [C-9-1] NIE NALEŻY deklarować
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-9-2] MUST throw an
IllegalArgumentException
upon attempts to set any 3GPP2 network types in preferred or allowed network type bitmasks. - [C-9-3] Musi zwracać pusty ciąg znaków z
TelephonyManager#getMeid
.
Jeśli implementacje urządzeń obsługują karty eUICC z kilkoma portami i profilami, muszą:
- [C-10-1] NALEŻY zadeklarować flagę funkcji
android.hardware.telephony.euicc.mep
.
7.4.1.1. Zgodność z blokowaniem numeru
Jeśli implementacje na urządzeniach zgłaszają funkcję android.hardware.telephony.calling
, to:
- [C-1-1] MUST include number blocking support
- [C-1-2] NALEŻY w pełni zaimplementować
BlockedNumberContract
i odpowiednie API zgodnie z opisem w dokumentacji pakietu SDK. [C-1-3] Musi blokować wszystkie połączenia i wiadomości z numeru telefonu w interfejsie „BlockedNumberProvider” bez interakcji z aplikacją. Jedynym wyjątkiem jest tymczasowe odblokowanie numeru zgodnie z opisem w dokumentacji interfejsu SDK.
[C-1-4] NALEŻY napisać do dostawcy platformy rejestru połączeń w przypadku zablokowanego połączenia i NALEŻY odfiltrować połączenia z
BLOCKED_TYPE
z domyślnego widoku rejestru połączeń w zainstalowanej fabrycznie aplikacji Dialer.[C-1-5] NIE NALEŻY pisać do dostawcy usług telefonicznych w przypadku zablokowanej wiadomości.
[C-1-6] NALEŻY wdrożyć interfejs zarządzania zablokowanymi numerami, który otwiera się za pomocą intencji zwracanej przez metodę
TelecomManager.createManageBlockedNumbersIntent()
.[C-1-7] Nie wolno zezwalać użytkownikom dodatkowym na wyświetlanie ani edytowanie zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że użytkownik główny ma pełną kontrolę nad usługami telefonicznymi, które są dostępne w jednym egzemplarzu na urządzeniu. Wszystkie elementy interfejsu związane z blokowaniem MUSZĄ być ukryte dla użytkowników dodatkowych, a lista zablokowanych użytkowników MUSI być nadal respektowana.
Blokowane numery NALEŻY przenieść do dostawcy, gdy urządzenie zostanie zaktualizowane do Androida 7.0.
NALEŻY umożliwić użytkownikowi wyświetlanie zablokowanych połączeń w wstępnie zainstalowanej aplikacji Dialer.
7.4.1.2. Interfejs Telecom API
Jeśli wdrożenia urządzeń zgłaszają android.hardware.telephony.calling
, to:
- [C-1-1] Musi obsługiwać interfejsy API
ConnectionService
opisane w pakiecie SDK. - [C-1-2] NALEŻY wyświetlić nowe połączenie przychodzące i zapewnić użytkownikowi możliwość zaakceptowania lub odrzucenia połączenia przychodzącego, gdy użytkownik jest w trakcie rozmowy z aplikacją innej firmy, która nie obsługuje funkcji wstrzymania określonej przez
CAPABILITY_SUPPORT_HOLD
. - [C-1-3] Aplikacja MUSI implementować interfejs InCallService.
[C-SR-1] MOCNO zaleca się powiadomienie użytkownika, że odebranie połączenia przychodzącego spowoduje przerwanie bieżącego połączenia.
Implementacja AOSP spełnia te wymagania dzięki powiadomieniu, które informuje użytkownika, że odebranie połączenia przychodzącego spowoduje przerwanie innego połączenia.
[C-SR-2] ZALECAMY WYMAGANIE załadowanie domyślnej aplikacji do wybierania numerów, która wyświetla w dzienniku połączeń wpis z danymi i nazwę aplikacji innej firmy, gdy aplikacja innej firmy ustawia klucz
PhoneAccount
natrue
.EXTRA_LOG_SELF_MANAGED_CALLS
[C-SR-3] ZALECAMY, aby obsłużyć zdarzenia
KEYCODE_MEDIA_PLAY_PAUSE
iKEYCODE_HEADSETHOOK
interfejsu APIandroid.telecom
w taki sposób:- Rozpocznij połączenie
Connection.onDisconnect()
, gdy podczas trwającego połączenia zostanie wykryte krótkie naciśnięcie klawisza. - Wybieranie numeru
Connection.onAnswer()
, gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie klawisza. - Wybieranie numeru
Connection.onReject()
, gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia. - Przełącz stan wyciszenia
CallAudioState
.
- Rozpocznij połączenie
7.4.1.3. Odciążanie funkcji utrzymywania aktywności NAT-T w komórkach
Implementacje na urządzeniu:
- NALEŻY uwzględnić obsługę przekierowania danych keepalive do sieci komórkowej.
Jeśli implementacje urządzeń obejmują obsługę funkcji Cellular keepalive offload i udostępniają tę funkcję aplikacjom innych firm, muszą:
- [C-1-1] Musi obsługiwać interfejs SocketKeepAlive API.
- [C-1-2] Musi obsługiwać co najmniej 1 jednoczesny slot utrzymywania połączenia w sieci komórkowej.
- [C-1-3] MUSI obsługiwać tyle równoczesnych slotów utrzymywania połączenia, ile obsługuje interfejs HAL radia komórkowego.
- [C-SR-1] MOCNO zaleca się obsługę co najmniej 3 komórek keepalive na instancję radia.
Jeśli implementacje urządzeń nie obsługują przenoszenia funkcji keepalive do sieci komórkowej, urządzenia te:
- [C-2-1] ZAWSZE zwracaj ERROR_UNSUPPORTED.
7.4.2. IEEE 802.11 (Wi-Fi)
Implementacje na urządzeniu:
- POWINNA obejmować obsługę co najmniej jednej formy 802.11.
Jeśli implementacje urządzeń obejmują obsługę 802.11 i udostępniają te funkcje aplikacji innej firmy, muszą:
- [C-1-1] Musisz zaimplementować odpowiedni interfejs API Androida.
- [C-1-2] MUST report the hardware feature flag
android.hardware.wifi
. - [C-1-3] MUSISZ zaimplementować interfejs API multicast zgodnie z opisem w dokumentacji pakietu SDK.
- [C-1-4] MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) w żadnym momencie działania, w tym:
- nawet wtedy, gdy ekran nie jest aktywny.
- W przypadku implementacji urządzeń z Androidem TV nawet w stanie gotowości.
- [C-1-5] NIE NALEŻY traktować wywołania metody interfejsu API
WifiManager.enableNetwork()
jako wystarczającej wskazówki do przełączenia obecnie aktywnegoNetwork
, który jest używany domyślnie do ruchu aplikacji i zwracany przez metody interfejsu APIConnectivityManager
, takie jakgetActiveNetwork
iregisterDefaultNetworkCallback
. Innymi słowy, mogą wyłączyć dostęp do internetu, który jest zapewniany przez innego dostawcę sieci (np. dane mobilne), tylko wtedy, gdy potwierdzą, że sieć Wi-Fi zapewnia dostęp do internetu. - [C-1-6] W przypadku wywołania metody interfejsu API
ConnectivityManager.reportNetworkConnectivity()
ZALECAMY ponowną ocenę dostępu do Internetu na urządzeniuNetwork
.Jeśli okaże się, że bieżąceNetwork
nie zapewnia już dostępu do Internetu, należy przejść na inną dostępną sieć (np. dane mobilne), która zapewnia dostęp do Internetu. - [C-1-7] NALEŻY losowo zmienić źródłowy adres MAC i numer sekwencji ramek żądań sondowania, raz na początku każdego skanowania, gdy STA jest rozłączony.
- [C-1-8] NALEŻY użyć jednego stałego adresu MAC (NIE NALEŻY losować adresu MAC w połowie skanowania).
- [C-1-9] NALEŻY iterować numer sekwencji żądania sondowania w normalny sposób (sekwencyjnie) między żądaniami sondowania w skanowaniu.
- [C-1-10] MUSI losowo generować numer porządkowy żądania sondowania między ostatnim żądaniem sondowania w ramach skanowania a pierwszym żądaniem sondowania w ramach kolejnego skanowania.
- [C-SR-1] MOCNO zaleca się losowanie źródłowego adresu MAC używanego do komunikacji STA z punktem dostępowym (AP) podczas tworzenia i powiązania.
- Urządzenie MUSI używać innego losowego adresu MAC dla każdego SSID (FQDN dla Passpoint), z którym się komunikuje.
- Urządzenie MUSI oferować użytkownikowi opcję kontrolowania losowania na podstawie identyfikatora SSID (FQDN dla Passpoint) z opcjami losowania i nielosowania oraz MUSI ustawić domyślny tryb dla nowych konfiguracji Wi-Fi, aby losowanie było możliwe.
- [C-SR-2] Zdecydowanie zalecamy używanie losowego identyfikatora BSSID dla dowolnego punktu dostępu utworzonego przez użytkownika.
- Adres MAC MUSI być zrandomizowany i zachowywany w przypadku każdego SSID używanego przez AP.
- URZĄDZENIE MOŻE umożliwiać użytkownikowi wyłączenie tej funkcji. Jeśli taka opcja jest dostępna, losowanie MUSI być domyślnie włączone.
Jeśli implementacje urządzeń obejmują obsługę trybu oszczędzania energii Wi-Fi zgodnie ze standardem IEEE 802.11, urządzenia te:
- NALEŻY wyłączyć tryb oszczędzania energii Wi-Fi, gdy aplikacja uzyska blokadę
WIFI_MODE_FULL_HIGH_PERF
lubWIFI_MODE_FULL_LOW_LATENCY
za pomocą interfejsów APIWifiManager.createWifiLock()
iWifiManager.WifiLock.acquire()
. - [C-3-2] Średni czas oczekiwania w obie strony między urządzeniem a punktem dostępu w trybie Wi-Fi Low Latency Lock (
WIFI_MODE_FULL_LOW_LATENCY
) MUSI być krótszy niż czas oczekiwania w trybie Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] ZALECAMY zminimalizowanie opóźnień w transmisji Wi-Fi za każdym razem, gdy zostanie uzyskany i zacznie obowiązywać blokada opóźnienia niskiego poziomu (
WIFI_MODE_FULL_LOW_LATENCY
).
Jeśli implementacje urządzeń obsługują Wi-Fi i korzystają z niego do skanowania lokalizacji, to:
- [C-2-1] NALEŻY zapewnić użytkownikowi możliwość włączenia lub wyłączenia odczytu wartości za pomocą metody interfejsu API
WifiManager.isScanAlwaysAvailable
.
7.4.2.1. Wi-Fi Direct
Implementacje na urządzeniu:
- NALEŻY uwzględnić obsługę Wi-Fi Direct (Wi-Fi peer-to-peer).
Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Direct, urządzenia te:
- [C-1-1] NALEŻY zaimplementować odpowiednie interfejsy API Androida zgodnie z opisem w dokumentacji pakietu SDK.
- [C-1-2] MUST report the hardware feature
android.hardware.wifi.direct
. - [C-1-3] MUSI obsługiwać zwykłe działanie Wi-Fi.
- [C-1-4] MUSI obsługiwać operacje Wi-Fi i Wi-Fi Direct jednocześnie.
- [C-SR-1] MOCNO zaleca się losowanie adresu MAC źródła w przypadku wszystkich nowo utworzonych połączeń Wi-Fi Direct.
7.4.2.2. Konfiguracja połączenia bezpośredniego z tunelowaniem Wi-Fi
Implementacje na urządzeniu:
- POWINIEN zawierać obsługę konfiguracji tunelowanej bezpośredniej łączności Wi-Fi (TDLS) zgodnie z dokumentacją pakietu Android SDK.
Jeśli implementacje urządzeń obejmują obsługę TDLS, a TDLS jest włączone przez interfejs API WiFiManager, urządzenia te:
- [C-1-1] MUSI deklarować obsługę TDLS za pomocą
WifiManager.isTdlsSupported
. - NALEŻY używać TDLS tylko wtedy, gdy jest to możliwe i korzystne.
- Powinien zawierać heurystyki i NIE używać TDLS, gdy jego działanie może być gorsze niż przez punkt dostępu Wi-Fi.
7.4.2.3. Wi-Fi Aware
Implementacje na urządzeniu:
- POWINIEN zawierać obsługę Wi-Fi Aware.
Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i udostępniają tę funkcję aplikacjom innych firm, muszą:
- [C-1-1] NALEŻY zaimplementować interfejsy API
WifiAwareManager
zgodnie z opisem w dokumentacji pakietu SDK. - [C-1-2] NALEŻY zadeklarować flagę funkcji
android.hardware.wifi.aware
. - [C-1-3] MUSI obsługiwać operacje Wi-Fi i Wi-Fi Aware jednocześnie.
- [C-1-4] NALEŻY losowo generować adres interfejsu zarządzania Wi-Fi Aware co 30 minut i za każdym razem, gdy Wi-Fi Aware jest włączone, chyba że trwa operacja pomiaru Aware lub aktywna jest ścieżka danych Aware (losowanie nie jest wymagane, dopóki ścieżka danych jest aktywna).
Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i lokalizacji Wi-Fi zgodnie z opisem w sekcji 7.4.2.5 oraz udostępniają te funkcje aplikacjom innych firm, muszą:
- [C-2-1] NALEŻY zaimplementować interfejsy API wykrywania z uwzględnieniem lokalizacji: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm oraz onServiceDiscoveredWithinRange.
7.4.2.4. Wi-Fi Passpoint
Jeśli implementacje urządzeń obejmują obsługę 802.11 (Wi-Fi), urządzenia te:
- [C-1-1] MUSI obsługiwać Wi-Fi Passpoint.
- [C-1-2] NALEŻY zaimplementować interfejsy API
WifiManager
związane z Passpoint zgodnie z opisem 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. Generic Advertisement Service (GAS) i Access Network Query Protocol (ANQP).
- [C-1-4] Należy zadeklarować flagę funkcji
android.hardware.wifi.passpoint
. - [C-1-5] W celu wykrywania, dopasowywania i kojarzenia z sieciami Passpoint należy stosować implementację AOSP.
- [C-1-6] MUSI obsługiwać co najmniej ten podzbiór protokołów wdrożeniowych urządzeń zdefiniowanych w specyfikacji Wi-Fi Alliance Passpoint R2: uwierzytelnianie EAP-TTLS i SOAP-XML.
- [C-1-7] NALEŻY przetwarzać certyfikat serwera AAA zgodnie ze specyfikacją Hotspot 2.0 R3.
- [C-1-8] MUSI obsługiwać kontrolę użytkownika nad wdrożeniem za pomocą selektora Wi-Fi.
- [C-1-9] Konfiguracje Passpoint MUSZĄ być trwałe po ponownym uruchomieniu.
- [C-SR-1] MOCNO zalecamy dodanie funkcji akceptowania warunków.
- [C-SR-2] MOCNO POLECAMY obsługę funkcji informacji o miejscu.
Jeśli udostępniono globalny przełącznik kontroli użytkownika do wyłączania Passpoint, implementacje:
- [C-3-1] Domyślnie musi być włączony Passpoint.
7.4.2.5. Lokalizacja Wi-Fi (czas błądzenia Wi-Fi – RTT)
Implementacje na urządzeniu:
- POWINIEN zawierać obsługę lokalizacji Wi-Fi.
Jeśli implementacje urządzeń obejmują obsługę lokalizacji Wi-Fi i udostępniają tę funkcję aplikacjom innych firm, muszą:
- [C-1-1] NALEŻY zaimplementować interfejsy API
WifiRttManager
zgodnie z opisem w dokumentacji pakietu SDK. - [C-1-2] NALEŻY zadeklarować flagę funkcji
android.hardware.wifi.rtt
. - [C-1-3] NALEŻY losowo zmienić źródłowy adres MAC w przypadku każdego wysyłania RTT, które jest wykonywane, gdy interfejs Wi-Fi, na którym jest wykonywane RTT, nie jest powiązany z punktami dostępu.
- [C-1-4] Dokładność musi wynosić maksymalnie 2 metry przy przepustowości 80 MHz w 68. procentile (obliczonej za pomocą funkcji kumulatywnej rozkładu).
- [C-SR-1] ZALECAMY, aby dokładność pomiaru nie przekraczała 1,5 metra przy przepustowości 80 MHz w 68 procencie (obliczonej za pomocą funkcji rozkładu skumulowanego).
7.4.2.6. Odciążenie utrzymywania aktywności Wi-Fi
Implementacje na urządzeniu:
- NALEŻY uwzględnić obsługę przenoszenia danych w ramach funkcji keepalive Wi-Fi.
Jeśli implementacje urządzeń obejmują obsługę funkcji Wi-Fi keepalive offload i udostępniają tę funkcję aplikacjom innych firm, muszą:
- [C-1-1] Musi obsługiwać interfejs API SocketKeepAlive.
- [C-1-2] Musi obsługiwać co najmniej 3 jednoczesne sloty utrzymywania połączenia przez Wi-Fi.
Jeśli implementacje urządzeń nie obsługują przenoszenia funkcji utrzymywania połączenia Wi-Fi, urządzenia te:
- [C-2-1] Musi zwracać
ERROR_UNSUPPORTED
.
7.4.2.7. Wi-Fi Easy Connect (protokół Device Provisioning Protocol)
Implementacje na urządzeniu:
- NALEŻY uwzględnić obsługę Wi-Fi Easy Connect (DPP).
Jeśli implementacje urządzeń obejmują obsługę funkcji Wi-Fi Easy Connect i udostępniają ją aplikacjom innych firm, muszą:
- [C-1-1] Metoda WifiManager#isEasyConnectSupported() MUSI zwracać wartość
true
.
7.4.2.8. Weryfikacja certyfikatu serwera Wi-Fi w firmie
Jeśli certyfikat serwera Wi-Fi nie został zweryfikowany lub nazwa domeny serwera Wi-Fi nie została ustawiona, implementacje urządzenia:
- [C-SR-1] ZALECAMY, aby nie udostępniać użytkownikowi opcji ręcznego dodawania sieci Wi-Fi dla firm w aplikacji Ustawienia.
7.4.2.9. Zaufaj przy pierwszym użyciu (TOFU)
Jeśli implementacje urządzeń obsługują funkcję zaufania po pierwszym użyciu (TOFU) i pozwalają użytkownikowi zdefiniować konfiguracje WPA/WPA2/WPA3-Enterprise, to:
- [C-4-1] Musisz umożliwić użytkownikowi wybranie opcji korzystania z usług typu TOFU.
7.4.3. Bluetooth
Jeśli implementacje urządzeń obsługują profil Bluetooth Audio, to:
- NALEŻY obsługiwać zaawansowane kodeki audio i kodeki audio Bluetooth (np. LDAC) z A2DP.
Jeśli implementacje urządzeń obsługują protokoły HFP, A2DP i AVRCP, muszą:
- NALEŻY obsługiwać co najmniej 5 połączonych urządzeń.
Jeśli implementacje na urządzeniach deklarują funkcję android.hardware.vr.high_performance
, muszą:
- [C-1-1] MUSI obsługiwać Bluetooth 4.2 i Bluetooth LE Data Length Extension.
Android obsługuje Bluetooth i Bluetooth Low Energy.
Jeśli implementacje urządzeń obejmują obsługę Bluetooth i Bluetooth Low Energy, to:
- [C-2-1] NALEŻY zadeklarować odpowiednie funkcje platformy (odpowiednio
android.hardware.bluetooth
iandroid.hardware.bluetooth_le
) oraz zaimplementować interfejsy API platformy. - NALEŻY wdrożyć odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX, HFP itp., w zależności od urządzenia.
Jeśli implementacje urządzeń obejmują obsługę Bluetooth Low Energy (BLE), to:
- [C-3-1] NALEŻY zadeklarować funkcję sprzętową
android.hardware.bluetooth_le
. - [C-3-2] NALEŻY włączyć interfejsy API Bluetooth oparte na GATT (profil ogólny atrybutów) zgodnie z dokumentacją pakietu SDK i android.bluetooth.
- [C-3-3] NALEŻY podać prawidłową wartość parametru
BluetoothAdapter.isOffloadedFilteringSupported()
, aby wskazać, czy zaimplementowano logikę filtrowania dla klas interfejsu API ScanFilter. - [C-3-4] MUST report the correct value for
BluetoothAdapter.isMultipleAdvertisementSupported()
to indicate whether Low Energy Advertising is supported. - [C-3-5] NALEŻY wdrożyć limit czasu adresu prywatnego do rozwiązywania (RPA) nie dłuższy niż 15 minut i zmieniać adres po upływie tego czasu, aby chronić prywatność użytkownika, gdy urządzenie aktywnie korzysta z BLE do skanowania lub reklamowania. Aby zapobiec atakom czasowym, interwały limitu czasu muszą być losowe i mieć od 5 do 15 minut.
- NALEŻY obsługiwać przenoszenie logiki filtrowania na układ Bluetooth, gdy wdrażasz interfejs ScanFilter API.
- NALEŻY obsługiwać przenoszenie skanowania zbiorczego na układ Bluetooth.
- NALEŻY obsługiwać wiele reklam z co najmniej 4 miejscami.
Jeśli implementacje urządzeń obsługują Bluetooth LE i korzystają z Bluetooth LE do skanowania lokalizacji, to:
- [C-4-1] NALEŻY zapewnić użytkownikowi możliwość włączenia lub wyłączenia wartości odczytywanej za pomocą interfejsu System API
BluetoothAdapter.isBleScanAlwaysAvailable()
.
Jeśli implementacje urządzeń obejmują obsługę Bluetooth LE i profilu aparatów słuchowych, jak opisano w artykule Obsługa aparatów słuchowych za pomocą Bluetooth LE, to:
- [C-5-1] W funkcji BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) musi zostać zwrócona wartość
true
.
Jeśli implementacje urządzeń obejmują obsługę Bluetooth lub Bluetooth Low Energy, to:
- [C-6-1] NALEŻY ograniczyć dostęp do metadanych Bluetooth (takich jak wyniki skanowania), które mogą posłużyć do określenia lokalizacji urządzenia, chyba że aplikacja przesyłająca żądanie przeszła pomyślnie weryfikację uprawnień
android.permission.ACCESS_FINE_LOCATION
na podstawie bieżącego stanu (pierwszego lub tła).
Jeśli implementacje na urządzeniu obejmują obsługę Bluetootha lub Bluetootha Low Energy, a w pliku manifestu aplikacji nie ma deklaracji dewelopera, która potwierdza, że nie uzyskuje on lokalizacji z Bluetootha, to:
- [C-6-2] Koniecznie należy ograniczyć dostęp do Bluetootha do
android.permission.ACCESS_FINE_LOCATION
.
Jeśli implementacje na urządzeniu zwracają wartość true
dla interfejsu API BluetoothAdapter.isLeAudioSupported()
, to:
- [C-7-1] MUSI obsługiwać klienta unicast.
- [C-7-2] MUSI obsługiwać 2 M 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] NALEŻY jednocześnie włączyć klienta unicastowego BAP, koordynatora zestawu CSIP, serwer MCP, kontroler VCP i serwer CCP.
- [C-SR-1] ZDECYDOWANIE zalecamy włączenie klienta unicast HAP.
Jeśli implementacje na urządzeniu zwracają wartość true
dla interfejsu API BluetoothAdapter.isLeAudioBroadcastSourceSupported()
, to:
- [C-8-1] Musi obsługiwać co najmniej 2 linki BIS w ramach BIG.
- [C-8-2] NALEŻY jednocześnie włączyć źródło transmisji BAP i asystenta transmisji BAP.
- [C-8-3] Musi obsługiwać reklamy okresowe LE.
Jeśli implementacje na urządzeniu zwracają wartość true
dla interfejsu API BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
, to:
- [C-9-1] MUSI obsługiwać usługę PAST (Periodic Advertising Sync Transfer).
- [C-9-2] MUSI obsługiwać reklamy okresowe LE.
Jeśli implementacje na urządzeniu deklarują FEATURE_BLUETOOTH_LE
, to:
- [C-10-1] NALEŻY mieć pomiary RSSI w zakresie +/-9 dB przez 95% pomiarów w odległości 1 m od urządzenia referencyjnego przesyłającego dane z szybkością
ADVERTISE_TX_POWER_HIGH
w warunkach widoczności bezpośredniej. - [C-10-2] MUSI zawierać poprawki Rx/Tx w celu zmniejszenia odchyleń w poszczególnych kanałach, tak aby pomiary na każdym z 3 kanałów i na każdej antenie (jeśli są używane) mieściły się w zakresie +/-3 dB w 95% pomiarów.
- [C-SR-2] Zdecydowanie zalecamy pomiar i kompensację przesunięcia Rx, aby zapewnić średnią wartość RSSI BLE na poziomie -60 dBm +/-10 dB w odległości 1 m od urządzenia referencyjnego przesyłającego dane z urządzeniem BLE z ustawieniem
ADVERTISE_TX_POWER_HIGH
, przy czym urządzenia są zorientowane w taki sposób, że znajdują się na „równoległych płaszczyznach”, a ekrany skierowane są w ten sam kierunek. - [C-SR-3] MOCNO POLECAMY pomiar i kompensację przesunięcia nadawania, aby zapewnić medianę BLE RSSI na poziomie -60 dBm +/-10 dB podczas skanowania z urządzenia odniesienia znajdującego się w odległości 1 m i transmitującego na poziomie
ADVERTISE_TX_POWER_HIGH
, przy czym urządzenia są zorientowane w taki sposób, że znajdują się na „równoległych płaszczyznach”, a ekrany są skierowane w ten sam kierunek.
MOCNO zalecamy wykonanie czynności konfiguracji pomiarów opisanych w sekcji Kalibracja obecności.
Jeśli implementacje urządzeń obsługują Bluetooth w wersji 5.0, to:
- [C-SR-4] Zdecydowanie zalecamy, aby zapewnić pomoc w tych kwestiach:
- LE 2M PHY
- LE Codec PHY
- Rozszerzenie reklamy w e-mailu
- Reklamy okresowe
- Co najmniej 10 zestawów reklam
- co najmniej 8 równoczesnych połączeń LE, Każde połączenie może pełnić jedną z 2 ról w topologii połączenia.
- Prywatność na poziomie LE Link
- „Rozwiązująca lista” zawierająca co najmniej 8 pozycji
7.4.4. Komunikacja Near Field Communication
Implementacje na urządzeniu:
- POWINIEN zawierać transceiver i powiązany sprzęt do komunikacji Near Field Communication (NFC).
- [C-0-1] NALEŻY zaimplementować interfejsy API
android.nfc.NdefMessage
iandroid.nfc.NdefRecord
, nawet jeśli nie obsługują one NFC ani nie deklarują funkcjiandroid.hardware.nfc
, ponieważ klasy reprezentują format reprezentacji danych niezależny od protokołu.
Jeśli implementacje urządzeń obejmują sprzęt NFC i planują udostępnić go aplikacjom innych firm, muszą:
- [C-1-1] MUST report the
android.hardware.nfc
feature from theandroid.content.pm.PackageManager.hasSystemFeature()
method. - MUSI być w stanie odczytywać i zapisywać komunikaty NDEF za pomocą tych standardów NFC:
- [C-1-2] MUSI być w stanie działać jako czytnik/nagrywarka NFC Forum (zgodnie ze specyfikacją techniczną NFC Forum NFCForum-TS-DigitalProtocol-1.0) za pomocą tych standardów NFC:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Typy tagów NFC Forum 1, 2, 3, 4, 5 (zdefiniowane przez NFC Forum)
[C-SR-1] MOCNO ZALECANA obsługa odczytu i zapisu komunikatów NDEF, a także danych nieprzetworzonych za pomocą tych standardów NFC. Pamiętaj, że chociaż standardy NFC są opisane jako „MOCNO ZALECANE”, w przyszłej wersji definicji zgodności planujemy zmienić je na „WYMAGANE”. Te standardy są opcjonalne w tej wersji, ale będą wymagane w przyszłych wersjach. Zachęcamy, aby istniejące i nowe urządzenia z tą wersją Androida spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
[C-1-13] W trybie wykrywania NFC MUSI sprawdzać wszystkie obsługiwane technologie.
NALEŻY ustawić tryb wykrywania NFC, gdy urządzenie jest aktywne, ekran jest włączony, a ekran blokady odblokowany.
POWINIEN być w stanie odczytać kod kreskowy i adres URL (jeśli jest zakodowany) produktów z kodami kreskowymi Thinfilm NFC.
Pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku wymienionych powyżej specyfikacji JIS, ISO i forum NFC.
Android obsługuje tryb hosta karty NFC (HCE).
Jeśli implementacje urządzeń obejmują chipset kontrolera NFC obsługujący HCE (dla NfcA lub NfcB) i obsługują routing identyfikatora aplikacji (AID), to:
- [C-2-1] MUST report the
android.hardware.nfc.hce
feature constant. - [C-2-2] Musi obsługiwać interfejsy API NFC HCE zdefiniowane w pakiecie Android SDK.
Jeśli implementacje urządzeń zawierają chipset kontrolera NFC obsługujący HCE w przypadku NfcF i implementują tę funkcję w przypadku aplikacji innych firm, muszą:
- [C-3-1] MUST report the
android.hardware.nfc.hcef
feature constant. - [C-3-2] MUSISZ zaimplementować interfejsy API do emulacji karty NfcF zgodnie z definicją w pakiecie SDK Androida.
Jeśli implementacje urządzeń obejmują ogólne obsługiwanie NFC zgodnie z opisem w tej sekcji i obsługują technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF na MIFARE Classic) w roli czytnika/nagrywarki, to:
- [C-4-1] NALEŻY zaimplementować odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
- [C-4-2] MUST report the feature
com.nxp.mifare
from theandroid.content.pm.PackageManager.hasSystemFeature
() method. Pamiętaj, że nie jest to standardowa funkcja Androida i nie jest widoczna jako stała w klasieandroid.content.pm.PackageManager
.
7.4.5. Protokoły sieciowe i interfejsy API
7.4.5.1. Minimalna funkcjonalność sieci
Implementacje na urządzeniu:
- [C-0-1] MUSI obsługiwać co najmniej jedną formę sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o przepustowości co najmniej 200 kbit/s. Przykłady technologii spełniających ten wymóg to EDGE, HSPA, EV-DO, 802.11g, Ethernet i PAN Bluetooth.
- NALEŻY również uwzględnić obsługę co najmniej jednego popularnego standardu bezprzewodowej transmisji danych, takiego jak 802.11 (Wi-Fi), gdy podstawowym połączeniem danych jest standard fizyczny sieci (taki jak Ethernet).
- MOŻNA stosować więcej niż jedną formę łączności danych.
7.4.5.2. IPv6
Implementacje na urządzeniu:
- [C-0-2] MUSI zawierać stos sieciowy IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak
java.net.Socket
ijava.net.URLConnection
, a także natywnych interfejsów API, takich jakAF_INET6
sockets. - [C-0-3] Protokół IPv6 MUSI być domyślnie włączony.
- NALEŻY zadbać o to, aby komunikacja IPv6 była tak samo niezawodna jak IPv4, na przykład:
- [C-0-4] W trybie Doze MUSI być zachowana łączność IPv6.
- [C-0-5] Ograniczenie szybkości NIE MOŻE spowodować utraty łączności IPv6 w żadnej sieci zgodnej z IPv6, która używa okresów ważności RA wynoszący co najmniej 180 sekund.
- NALEŻY zadbać o to, aby komunikacja IPv6 była tak samo niezawodna jak IPv4, na przykład:
- [C-0-6] Musisz zapewnić aplikacjom innych firm bezpośrednie połączenie IPv6 z siecią, gdy urządzenie jest połączone z siecią IPv6, bez żadnej formy tłumaczenia adresów lub portów na poziomie lokalnym. Zarówno zarządzane interfejsy API, takie jak
Socket#getLocalAddress
lubSocket#getLocalPort
, jak i interfejsy NDK, takie jakgetsockname()
lubIPV6_PKTINFO
, MUSZĄ zwracać adres IP i port, które są faktycznie używane do wysyłania i odbierania pakietów w sieci, oraz być widoczne jako adres IP źródłowy i port serwerów internetowych.
Wymagany poziom obsługi IPv6 zależy od typu sieci, jak pokazano w tych wymaganiach.
Jeśli implementacje urządzeń obsługują Wi-Fi, to:
- [C-1-1] MUSI obsługiwać stos podwójny i IPv6 w sieci Wi-Fi.
Jeśli implementacje urządzeń obsługują Ethernet, to:
- [C-2-1] MUSI obsługiwać stos podwójny i IPv6 w sieci Ethernet.
Jeśli implementacje urządzeń obsługują dane komórkowe, to:
- [C-3-1] Musi obsługiwać działanie w sieci komórkowej w protokole IPv6 (tylko IPv6 lub ewentualnie w stosie podwójnym).
Jeśli implementacje urządzeń obsługują więcej niż jeden typ sieci (np. Wi-Fi i komórkowej transmisji danych), mogą:
- [C-4-1] MUSI jednocześnie spełniać powyższe wymagania w przypadku każdej sieci, gdy urządzenie jest jednocześnie połączone z większą liczbą typów sieci.
7.4.5.3. Portale przechwytujące
Portal przechwytujący to sieć, która wymaga zalogowania się, aby uzyskać dostęp do internetu.
Jeśli implementacje na urządzeniu zapewniają pełną implementację interfejsu android.webkit.Webview API
, to:
- [C-1-1] Musisz udostępnić aplikację portalu ograniczonego, która będzie obsługiwać intencję
ACTION_CAPTIVE_PORTAL_SIGN_IN
i wyświetlać stronę logowania portalu ograniczonego, wysyłając tę intencję w ramach wywołania interfejsu System APIConnectivityManager#startCaptivePortalApp(Network, Bundle)
. - [C-1-2] MUSI wykrywać portale ograniczonego dostępu i obsługiwać logowanie za pomocą aplikacji portalu ograniczonego dostępu, gdy urządzenie jest połączone z dowolnym typem sieci, w tym sieci komórkowej/komórkowej, Wi-Fi, Ethernet lub Bluetooth.
- [C-1-3] MUSI obsługiwać logowanie na portalach uwięzionych przy użyciu DNS w formie zwykłego tekstu, gdy urządzenie jest skonfigurowane do używania prywatnego DNS w trybie ścisłym.
- [C-1-4] W przypadku
android.net.LinkProperties.getPrivateDnsServerName
iandroid.net.LinkProperties.isPrivateDnsActive
należy używać szyfrowanego DNS zgodnie z dokumentacją pakietu SDK. Dotyczy to całego ruchu w sieci, który nie komunikuje się bezpośrednio z portalem ograniczonym. - [C-1-5] NALEŻY zadbać o to, aby podczas logowania się użytkownika w portalu uwięzionym domyślna sieć używana przez aplikacje (zwracana przez
ConnectivityManager.getActiveNetwork
,ConnectivityManager.registerDefaultNetworkCallback
i używana domyślnie przez interfejsy API sieci Java, takie jak java.net.Socket, oraz natywne interfejsy API, takie jak connect()) była dowolną inną dostępną siecią, która zapewnia dostęp do Internetu (jeśli jest dostępna).
7.4.6. Ustawienia synchronizacji
Implementacje na urządzeniu:
- [C-0-1] Ustawienie głównej autosynchronizacji MUSI być domyślnie włączone, aby metoda
getMasterSyncAutomatically()
zwracała wartość „true”.
7.4.7. Oszczędzanie danych
Jeśli implementacje urządzeń obejmują połączenie z licznikiem, są:
- [C-SR-1] ZALECAMY zaimplementowanie trybu oszczędzania danych.
Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych, muszą:
- [C-1-1] Musi obsługiwać wszystkie interfejsy API w klasie
ConnectivityManager
zgodnie z opisem w dokumentacji pakietu SDK.
Jeśli implementacje na urządzeniach nie zapewniają trybu oszczędzania danych, nie spełniają one tych wymagań:
- [C-2-1] Musi zwracać wartość
RESTRICT_BACKGROUND_STATUS_DISABLED
dlaConnectivityManager.getRestrictBackgroundStatus()
- [C-2-2] NIE MOŻNA nadawać
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
.
7.4.8. Bezpieczne elementy
Jeśli implementacje urządzeń obsługują interfejs Open Mobile API i zabezpieczone elementy, udostępniając je aplikacjom innych firm, mogą:
[C-1-1] NALEŻY wyliczyć dostępne czytniki elementów zabezpieczeń za pomocą interfejsu API
android.se.omapi.SEService.getReaders()
.[C-1-2] NALEŻY zadeklarować poprawne flagi funkcji za pomocą
android.hardware.se.omapi.uicc
w przypadku urządzenia z elementami zabezpieczeń opartymi na UICC,android.hardware.se.omapi.ese
w przypadku urządzenia z elementami zabezpieczeń opartymi na eSE iandroid.hardware.se.omapi.sd
w przypadku urządzenia z elementami zabezpieczeń opartymi na SD.
7.4.9. UWB
Jeśli implementacje urządzeń obejmują obsługę 802.1.15.4 i udostępniają te funkcje aplikacji innych firm, to:
- [C-1-1] Należy zaimplementować odpowiedni interfejs API Androida w pliku android.uwb.
- [C-1-2] MUSI zawierać flagę funkcji sprzętowej android.hardware.uwb.
- [C-1-3] MUSI obsługiwać wszystkie profile UWB zdefiniowane w implementacji Androida.
- [C-1-4] Musisz zapewnić użytkownikowi możliwość włączenia i wyłączenia radia UWB.
- [C-1-5] Aplikacje korzystające z radia UWB MUSZĄ mieć uprawnienie UWB_RANGING (w ramach grupy uprawnień NEARBY_DEVICES).
[C-SR-1] MOCNO zaleca się przeprowadzenie odpowiednich testów zgodności i certyfikatów określonych przez organizacje standaryzacyjne, w tym FIRA, CCC i CSA.
- [C-1-6] NALEŻY zadbać o to, aby pomiary odległości mieściły się w zakresie +/-15 cm w przypadku 95% pomiarów w środowisku z widocznością bezpośrednią w odległości 1 m w komorze bez odbicia.
- [C-1-7] NALEŻY zadbać o to, aby mediana pomiarów odległości w odległości 1 m od urządzenia referencyjnego mieściła się w zakresie [0,75 m, 1,25 m], gdzie odległość rzeczywista jest mierzona od górnej krawędzi badanego urządzenia trzymanego zwróconego do góry i z nachyleniem 45°.
- [C-SR-2] MOCNO zalecamy wykonanie czynności konfiguracji pomiaru opisanych w sekcji Kalibracja obecności.
7.5. Aparaty
Jeśli implementacje urządzeń zawierają co najmniej 1 kamerę, muszą:
- [C-1-1] NALEŻY zadeklarować flagę funkcji
android.hardware.camera.any
. - [C-1-2] Aplikacja MUSI mieć możliwość jednoczesnego przydzielenia 3 bitmap RGBA_8888 o rozmiarze równym rozmiarowi obrazów generowanych przez czujnik aparatu o najwyższej rozdzielczości na urządzeniu, gdy kamera jest otwarta na potrzeby podstawowego podglądu i robienia zdjęć.
- [C-1-3] NALEŻY zadbać o to, aby wstępnie zainstalowana domyślna aplikacja do obsługi aparatu (z intencją
MediaStore.ACTION_IMAGE_CAPTURE
,MediaStore.ACTION_IMAGE_CAPTURE_SECURE
lubMediaStore.ACTION_VIDEO_CAPTURE
) odpowiadała za usunięcie lokalizacji użytkownika z metadanych obrazu przed wysłaniem go do aplikacji odbiorczej, jeśli ta nie ma uprawnień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 urządzenia z kamerą, które obsługuje wyjście 10-bitowe.
- [C-2-2] MUSI obsługiwać 10-bitowe wyjście w przypadku głównego tylnego lub głównego przedniego aparatu.
- [C-SR-1] Zalecamy obsługę 10-bitowego wyjścia w przypadku obu głównych kamer.
- [C-2-3] Musi obsługiwać te same profile HDR dla wszystkich podkamer fizycznych kamery logicznej zgodnych z BACKWARD_COMPATIBLE oraz dla samej kamery logicznej.
Urządzenia z kamerą logiczną, które obsługują 10-bitowy HDR i implementują interfejs API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
:
- [C-3-1] Musi obsługiwać przełączanie się między wszystkimi fizycznymi aparatami zgodnymi ze starszymi wersjami za pomocą elementu sterującego
CONTROL_ZOOM_RATIO
w aparacie logicznym.
7.5.1. Tylny aparat
Tylny aparat znajduje się po przeciwnej stronie urządzenia niż wyświetlacz. Oznacza to, że rejestruje obrazy po przeciwnej stronie urządzenia, tak jak tradycyjny aparat.
Implementacje na urządzeniu:
- NALEŻY umieścić tylny aparat.
Jeśli implementacje urządzeń zawierają co najmniej 1 aparat skierowany do tyłu, muszą:
- [C-1-1] MUSISZ zgłosić flagę funkcji
android.hardware.camera
iandroid.hardware.camera.any
. - [C-1-2] Rozdzielczość musi wynosić co najmniej 2 Mpix.
- W sterowniku aparatu (niewidocznym dla oprogramowania aplikacji) powinien być zaimplementowany sprzętowy lub programowy autofokus.
- MOŻE mieć sprzęt z ostrzością stałą lub EDOF (rozszerzoną głębią ostrości).
- MOŻE zawierać błysk.
Jeśli aparat ma lampę błyskową:
- [C-2-1] Lampa błyskowa NIE MOŻE być włączona, gdy instancja
android.hardware.Camera.PreviewCallback
została zarejestrowana na powierzchni podglądu aparatu, chyba że aplikacja wyraźnie włączyła lampę błyskową, włączając atrybutyFLASH_MODE_AUTO
lubFLASH_MODE_ON
obiektuCamera.Parameters
. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu w urządzeniu, ale tylko aplikacji innych firm korzystających zCamera.PreviewCallback
.
7.5.2. Przedni aparat
Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz. Jest to kamera zwykle używana do robienia zdjęć użytkownikowi, na przykład w przypadku konferencji wideo i podobnych aplikacji.
Implementacje na urządzeniu:
- MOŻE zawierać przedni aparat.
Jeśli implementacje urządzeń zawierają co najmniej 1 przedni aparat, muszą spełniać te wymagania:
- [C-1-1] MUSISZ zgłosić flagę funkcji
android.hardware.camera.any
iandroid.hardware.camera.front
. - [C-1-2] Rozdzielczość musi wynosić co najmniej VGA (640 x 480 pikseli).
- [C-1-3] Nie wolno używać przedniego aparatu jako domyślnego aparatu w interfejsie Camera API. Nie wolno też skonfigurować interfejsu tak, aby traktował przedni aparat jako domyślny tylny aparat, nawet jeśli jest to jedyny aparat na urządzeniu.
- [C-1-4] Podgląd aparatu MUSI być odbiciem lustrzanym w orientacji określonej przez aplikację, gdy aplikacja wyraźnie poprosiła o obrócenie wyświetlacza aparatu za pomocą wywołania metody
android.hardware.Camera.setDisplayOrientation()
. Odwrotnie, podgląd MUSI być odzwierciedlony wzdłuż domyślnej osi poziomej urządzenia, gdy bieżąca aplikacja nie prosi wyraźnie o obrócenie wyświetlacza aparatu za pomocą wywołania metodyandroid.hardware.Camera.setDisplayOrientation()
. - [C-1-5] NIE MOŻESZ lustrować końcowego obrazu nieruchomego ani strumieni wideo zwróconych do aplikacji w ramach wywołań zwrotnych lub zapisanych w magazynie multimediów.
- [C-1-6] Obraz wyświetlany przez postview MUSI być odbiciem lustrzanym strumienia obrazu z podglądu kamery.
- MOŻE zawierać funkcje (takie jak autofokus, lampa błyskowa itp.) dostępne dla tylnych kamer zgodnie z opisem w sekcji 7.5.1.
Jeśli implementacje urządzeń mogą być obracane przez użytkownika (np. automatycznie za pomocą akcelerometru lub ręcznie za pomocą danych wejściowych użytkownika):
- [C-2-1] Podgląd w aparacie MUSI być odbitykiem poziomym względem bieżącego ustawienia urządzenia.
7.5.3. Kamera zewnętrzna
Implementacje na urządzeniu:
- MOŻE obejmować obsługę kamery zewnętrznej, która nie musi być zawsze połączona.
Jeśli implementacje urządzeń obejmują obsługę kamery zewnętrznej, muszą:
- [C-1-1] NALEŻY zadeklarować flagę funkcji platformy
android.hardware.camera.external
iandroid.hardware camera.any
. - [C-1-2] Musi obsługiwać USB Video Class (UVC 1.0 lub nowszy), jeśli zewnętrzna kamera łączy się przez port hosta USB.
- [C-1-3] Należy przejść testy CTS aparatu z podłączonym zewnętrznym aparatem. Szczegółowe informacje o testach CTS aparatu są dostępne na stronie source.android.com.
- POWINNA obsługiwać kompresję wideo, np. MJPEG, aby umożliwić przesyłanie nieskompresowanych strumieni o wysokiej jakości (czyli strumieni nieprzetworzonych lub niezależnie skompresowanych).
- MOŻE obsługiwać wiele kamer.
- MOŻE obsługiwać kodowanie wideo na podstawie kamery.
Jeśli kodowanie wideo na podstawie kamery jest obsługiwane:
- [C-2-1] Jednoczesny strumień niekodowany / MJPEG (w rozdzielczości QVGA lub wyższej) MUSI być dostępny dla implementacji urządzenia.
7.5.4. Zachowanie interfejsu Camera API
Android zawiera 2 pakiety interfejsów API umożliwiające dostęp do aparatu. Nowszy interfejs API android.hardware.camera2 udostępnia aplikacji niższy poziom kontroli nad aparatem, w tym wydajne przepływy zdjęć seryjnych/strumieniowych bez kopiowania i sterowanie poszczególnymi klatkami w zakresie ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, redukcji szumów i wyostrzania.
Starszy pakiet interfejsu API (android.hardware.Camera
) został oznaczony jako przestarzały w Androidzie 5.0, ale nadal powinien być dostępny dla aplikacji. Implementacje na urządzeniach z Androidem MUSZĄ zapewniać ciągłą obsługę interfejsu API zgodnie z opisem w tej sekcji i w pakiecie SDK Androida.
Wszystkie funkcje wspólne dla przestarzałej klasy android.hardware.Camera i nowszego pakietu android.hardware.camera2 MUSZĄ mieć porównywalna wydajność i jakość w obu interfejsach API. Na przykład przy takich samych ustawieniach szybkość i dokładność autofokusa muszą być identyczne, a jakość zarejestrowanych obrazów musi być taka sama. Funkcje, które zależą od odmiennej semantyki obu interfejsów API, nie muszą mieć takiej samej szybkości ani jakości, ale powinny być jak najbardziej zbliżone.
Implementacje urządzeń MUSZĄ implementować poniższe zachowania w przypadku interfejsów API związanych z kamerą we wszystkich dostępnych kamerach. Implementacje na urządzeniu:
- [C-0-1] DO stosowania w przypadku danych podglądu przekazywanych do wywołań zwrotnych aplikacji, gdy aplikacja nigdy nie wywołała funkcji
android.hardware.Camera.Parameters.setPreviewFormat(int)
.android.hardware.PixelFormat.YCbCr_420_SP
- [C-0-2] Musi być w dalszym ciągu w formacie kodowania NV21, gdy aplikacja rejestruje wystąpienie
android.hardware.Camera.PreviewCallback
, system wywołuje metodęonPreviewFrame()
, a format podglądu to YCbCr_420_SP, a dane w byte[] przekazane doonPreviewFrame()
. Oznacza to, że NV21 MUSI być ustawiony jako domyślny. - [C-0-3] MUSI obsługiwać format YV12 (oznaczony za pomocą stałej
android.graphics.ImageFormat.YV12
) w przypadku podglądów z obu kamer (przedniej i tylnej) w urządzeniuandroid.hardware.Camera
. (Sprzętowy koder wideo i kamera mogą używać dowolnego natywnego formatu pikseli, ale implementacja urządzenia MUSI obsługiwać konwersję do YV12). - [C-0-4] Musi obsługiwać formaty
android.hardware.ImageFormat.YUV_420_888
iandroid.hardware.ImageFormat.JPEG
jako dane wyjściowe w interfejsieandroid.media.ImageReader
API na urządzeniachandroid.hardware.camera2
, które reklamująREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
wandroid.request.availableCapabilities
. - [C-0-5] NALEŻY nadal wdrożyć pełne Camera API zawarte w dokumentacji pakietu Android SDK, niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład aparaty, które nie mają autofokusa, MUSZĄ wywoływać wszystkie zarejestrowane instancje
android.hardware.Camera.AutoFocusCallback
(nawet jeśli nie mają autofokusa). Pamiętaj, że dotyczy to również przednich aparatów. Na przykład mimo że większość przednich aparatów nie obsługuje autofokusa, wywołania interfejsu API muszą być „fałszowane” w sposób opisany powyżej. - [C-0-6] MUSI rozpoznawać i szanować nazwy parametrów zdefiniowane jako stałe w klasie
android.hardware.Camera.Parameters
i klasieandroid.hardware.camera2.CaptureRequest
. Z drugiej strony implementacje urządzeń NIE MOGĄ obsługiwać ani rozpoznawać stałych ciągów znaków przekazywanych do metodyandroid.hardware.Camera.setParameters()
, które nie są opisane jako stałe w interfejsieandroid.hardware.Camera.Parameters
. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry kamery, jeśli sprzęt na to pozwala, i NIE MOGĄ obsługiwać niestandardowych typów parametrów kamery. Na przykład implementacje urządzeń, które obsługują rejestrowanie obrazów za pomocą technik obrazowania o wysokim zakresie dynamicznym (HDR), MUSZĄ obsługiwać parametr kameryCamera.SCENE_MODE_HDR
. - [C-0-7] NALEŻY podać odpowiedni poziom obsługi za pomocą właściwości
android.info.supportedHardwareLevel
, jak opisano w pakiecie SDK Androida, oraz podać odpowiednie flagi funkcji frameworka. - [C-0-8] NALEŻY również zadeklarować poszczególne funkcje kamery
android.hardware.camera2
za pomocą właściwościandroid.request.availableCapabilities
oraz zadeklarować odpowiednie flagi funkcji. NALEŻY zdefiniować flagę funkcji, jeśli którekolwiek z podłączonych urządzeń z kamerą obsługuje tę funkcję. - [C-0-9] MUSI przesyłać intencję
Camera.ACTION_NEW_PICTURE
za każdym razem, gdy aparat zrobi nowe zdjęcie i jego wpis zostanie dodany do magazynu multimediów. - [C-0-10] NALEŻY przesyłać informację
Camera.ACTION_NEW_VIDEO
intent za każdym razem, gdy kamera nagra nowy film, a zdjęcie zostanie dodane do magazynu multimediów. - [C-0-11] Wszystkie kamery muszą być dostępne za pomocą przestarzałego interfejsu API
android.hardware.Camera
, a także za pomocą interfejsu APIandroid.hardware.camera2
. - [C-0-12] NALEŻY zadbać o to, aby wygląd twarzy NIE był zmieniany, w tym nie ograniczając się do zmiany geometrii twarzy, odcienia skóry twarzy lub wygładzania skóry twarzy w żadnym interfejsie
android.hardware.camera2
lubandroid.hardware.Camera
. - [C-SR-1] W przypadku urządzeń z większą liczbą kamer RGB skierowanych w ten sam kierunek MOCNO zalecamy obsługę urządzenia logicznego z kamerą, które zawiera informacje o możliwościach
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, w którym wszystkie kamery RGB są skierowane w ten sam kierunek jako fizyczne podurządzenia.
Jeśli implementacje na urządzeniach udostępniają firmom zewnętrznym firmowy interfejs API aparatu, muszą:
- [C-1-1] NALEŻY zaimplementować taki interfejs API aparatu za pomocą interfejsu
android.hardware.camera2
API. - MOŻE używać tagów dostawcy lub rozszerzeń w interfejsie
android.hardware.camera2
API.
7.5.5. Orientacja aparatu
Jeśli implementacje urządzeń mają przednie lub tylne kamery:
- [C-1-1] Musi być ustawiony tak, aby dłuższy wymiar kamery był wyrównany z dłuższym wymiarem ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparaty MUSZĄ robić zdjęcia w orientacji poziomej. Dotyczy to wszystkich urządzeń niezależnie od ich naturalnej orientacji, czyli zarówno urządzeń z główną orientacją poziomą, jak i urządzeń z główną orientacją pionową.
Powyższe wymagania nie dotyczą urządzeń, które spełniają wszystkie te kryteria:
- Urządzenie ma ekrany o zmiennej geometrii, takie jak składane lub składane na zawiasach.
- Gdy zmienia się stan zawiasów lub składania urządzenia, zmienia się orientacja urządzenia z głównej orientacji poziomej na główną orientację pionową (lub odwrotnie).
7.6. Pamięć i miejsce na dane
7.6.1. Minimalna ilość pamięci i miejsca na dane
Implementacje na urządzeniu:
- [C-0-1] MUSI zawierać Menedżera pobierania, którego aplikacje MOGĄ używać do pobierania plików danych. MUSI on umożliwiać pobieranie poszczególnych plików o rozmiarze co najmniej 100 MB do domyślnej lokalizacji „bufora”.
7.6.2. Pamięć współdzielona aplikacji
Implementacje na urządzeniu:
- [C-0-1] Musi oferować miejsce na dane, które mogą być udostępniane przez aplikacje. Jest to często nazywane „wspólnym zewnętrznym miejscem na dane”, „wspólnym miejscem na dane aplikacji” lub ścieżką Linuxa „/sdcard”, na której jest zamontowane.
- [C-0-2] MUSI być skonfigurowany z pamięcią współdzieloną zamontowaną domyślnie, innymi słowy „out of the box”, niezależnie od tego, czy pamięć jest implementowana na komponencie pamięci wewnętrznej czy wymiennym nośniku pamięci (np. gniazdo kart Secure Digital).
- [C-0-3] NALEŻY zamontować udostępnione miejsce na dane aplikacji bezpośrednio na ścieżce Linuxa
sdcard
lub umieścić link symboliczny Linuxa zsdcard
do rzeczywistego punktu zamontowania. - [C-0-4] MUSISZ włączyć storage ujęty w ramy
domyślnie we wszystkich aplikacjach kierowanych na interfejs API na poziomie 29 lub nowszym, z wyjątkiem tej sytuacji:
- Gdy aplikacja poprosi o
android:requestLegacyExternalStorage="true"
w pliku manifestu.
- Gdy aplikacja poprosi o
- [C-0-5] NALEŻY usunąć metadane dotyczące lokalizacji, takie jak tagi EXIF GPS, przechowywane w plikach multimedialnych, gdy te pliki są dostępne przez
MediaStore
, z wyjątkiem sytuacji, gdy wywołująca aplikacja ma uprawnieniaACCESS_MEDIA_LOCATION
.
Implementacje urządzeń mogą spełniać powyższe wymagania za pomocą jednej z tych metod:
- wymienna pamięć dostępna dla użytkownika, np. gniazdo karty Secure Digital (SD);
- Część pamięci wewnętrznej (nieusuwalna) w ramach Projektu Android Open Source (AOSP).
Jeśli implementacje urządzeń korzystają z wymiennej pamięci masowej, aby spełnić powyższe wymagania, muszą:
- [C-1-1] W interfejsie należy wyświetlić komunikat w oknie wyskakującym lub w powiadomieniu, gdy w gniazdo nie jest włożone żadne medium.
- [C-1-2] MUSI zawierać nośnik pamięci w formacie FAT (np. kartę SD) lub na opakowaniu i innych materiałach dostępnych w momencie zakupu musi być informacja, że nośnik pamięci należy kupić osobno.
Jeśli implementacje urządzeń używają części niewymiennej pamięci masowej, aby spełnić powyższe wymagania, muszą:
- NALEŻY użyć implementacji AOSP wewnętrznego współdzielonego magazynu aplikacji.
- MOŻE udostępniać miejsce na dane aplikacji z danymi prywatnymi.
Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB, to:
- [C-3-1] Musisz udostępnić mechanizm dostępu do danych w pamięci współdzielonej aplikacji z komputera hosta.
- NALEŻY udostępniać treści z obu ścieżek pamięci w przejrzysty sposób za pomocą usługi skanowania multimediów w Androidzie i funkcji
android.provider.MediaStore
. - Możesz użyć pamięci masowej USB, ale musisz użyć protokołu Media Transfer Protocol, aby spełnić to wymaganie.
Jeśli implementacje urządzeń mają port USB z trybem urządzenia peryferyjnego USB i obsługują protokół Media Transfer Protocol, muszą:
- POWINIEN być zgodny z hostem MTP na Androidzie, Android File Transfer.
- NALEŻY podać klasę urządzenia USB 0x00.
- Powinien zwracać nazwę interfejsu USB „MTP”.
7.6.3. Pamięć dostosowywana
Jeśli urządzenie ma być mobilne (w przeciwieństwie do telewizora), implementacje urządzenia muszą:
- [C-SR-1] BARDZO ZALECAMY stosowanie przenośnej pamięci masowej w stabilnej lokalizacji na dłuższy czas, ponieważ jej przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.
Jeśli port wymiennego urządzenia do przechowywania danych znajduje się w stabilnym miejscu, takim jak komora baterii lub inna obudowa ochronna, wdrożenia urządzenia muszą spełniać te wymagania:
- [C-SR-2] ZDECYDOWANIE POLECAMY wdrożenie pamięci dostosowywanej.
7.7. USB
Jeśli implementacje urządzeń mają port USB, muszą:
- Powinien obsługiwać tryb urządzenia peryferyjnego USB i tryb hosta USB.
- NALEŻY obsługiwać wyłączanie sygnalizacji danych przez USB.
7.7.1. Tryb urządzenia peryferyjnego USB
Jeśli implementacje urządzenia obejmują port USB obsługujący tryb peryferyjny:
- [C-1-1] Port MUSI umożliwiać podłączenie do hosta USB z standardowym portem USB typu A lub C.
- [C-1-2] MUST report the correct value of
iSerialNumber
in USB standard device descriptor throughandroid.os.Build.SERIAL
. - [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem rezystora typu C oraz MUSI wykrywać zmiany w reklamie, jeśli obsługuje USB typu C.
- [C-SR-1] Port powinien być w formacie micro-B, micro-AB lub USB typu C. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, aby można było je uaktualnić do przyszłych wersji platformy.
- [C-SR-2] Port powinien znajdować się na dole urządzenia (zgodnie z naturalną orientacją) lub umożliwić obrócenie ekranu w oprogramowaniu we wszystkich aplikacjach (w tym na ekranie głównym), aby wyświetlacz był prawidłowo wyświetlany, gdy port znajduje się na dole. Zalecamy, aby i stare, i nowe urządzenia z Androidem spełniały te wymagania, aby można było na nich instalować przyszłe wersje platformy.
- [C-SR-3] NALEŻY wdrożyć obsługę poboru prądu 1,5 A podczas korzystania z interfejsu HS chirp i przesyłania danych zgodnie ze specyfikacją USB Battery Charging specification, revision 1.2. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, aby można było je uaktualnić do przyszłych wersji platformy.
- [C-SR-4] ZDECYDOWANIE POLECANE: nie należy obsługiwać zastrzeżonych metod ładowania, które modyfikują napięcie Vbus poza domyślnymi poziomami lub zmieniają role odbiornika/źródła, ponieważ może to spowodować problemy ze zgodnością z ładowarkami lub urządzeniami, które obsługują standardowe metody przesyłania mocy przez USB. Chociaż jest to „MOCNO ZALECANE”, w przyszłych wersjach Androida możemy wymagać, aby wszystkie urządzenia z gniazdem typu C obsługiwały pełną interoperacyjność ze standardowymi ładowarkami typu C.
- [C-SR-5] ZALECAMY obsługę funkcji Power Delivery do przesyłania danych i przełączania ról w zasilaniu, gdy urządzenia obsługują USB typu C i tryb hosta USB.
- POWINNY obsługiwać Power Delivery do ładowania wysokiego napięcia oraz tryby alternatywne, takie jak wyświetlacz zewnętrzny.
- NALEŻY zaimplementować interfejs API i specyfikację Android Open Accessory (AOA) zgodnie z dokumentacją pakietu Android SDK.
Jeśli implementacje urządzeń zawierają port USB i spełniają specyfikację AOA, muszą:
- [C-2-1] MUSI deklarować obsługę funkcji sprzętowej
android.hardware.usb.accessory
. - [C-2-2] Klasa pamięci masowej USB MUSI zawierać ciąg znaków „android” na końcu ciągu znaków
iInterface
w opisie interfejsu pamięci masowej USB.
7.7.2. Tryb hosta USB
Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta, muszą:
- [C-1-1] NALEŻY zaimplementować interfejs API hosta USB Androida zgodnie z dokumentacją w pakiecie Android SDK i NALEŻY zadeklarować obsługę funkcji sprzętowej
android.hardware.usb.host
. - [C-1-2] MUSI obsługiwać standardowe urządzenia peryferyjne USB, a innymi słowy MUSI:
- Urządzenie musi mieć port typu C lub być dostarczane z kablami umożliwiającymi dostosowanie portu własnego urządzenia do standardowego portu USB typu C (urządzenie z USB typu C).
- Urządzenie musi mieć port typu A lub być dostarczane z kablami umożliwiającymi dostosowanie portu własnego urządzenia do standardowego portu USB typu A.
- Urządzenie musi mieć port micro-AB, do którego DOSTARCZALNIE JEST DOŁĄCZONY KABEL Z ADAPTEREM DO PORTU STANDARDOWEGO TYPU A.
- [C-1-3] Nie wolno dostarczać urządzenia z adapterem umożliwiającym konwersję portów USB typu A lub mikro-AB na porty typu C (gniazdo).
- [C-SR-1] MOCNO zalecamy implementację klasy audio USB zgodnie z dokumentacją pakietu SDK Androida.
- POWINNY obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta; reklamować prąd źródła co najmniej 1, 5 A zgodnie z sekcją „Parametry zakończenia” w specyfikacji kabla i złącza USB typu C (wersja 1.2) w przypadku złączy USB typu C lub używać portu CDP (portu doprowadzającego do ładowania) o zakresie prądu wyjściowego zgodnie z specyfikacją ładowania baterii USB (wersja 1.2) w przypadku złączy Micro-AB.
- NALEŻY wdrożyć i obsługiwać standardy USB typu C.
Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i klasę audio USB, muszą:
- [C-2-1] MUSI obsługiwać klasę USB HID.
- [C-2-2] MUSI obsługiwać wykrywanie i mapowanie tych pól danych HID określonych w tabelach użycia USB HID i żądaniu użycia polecenia głosowego do
KeyEvent
konstant w ten sposób:- Strona użycia (0xC) Identyfikator użycia (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- Strona z informacjami o użytkowaniu (0xC) Identyfikator użycia (0x0E9):
KEYCODE_VOLUME_UP
- Strona Użycie (0xC) Identyfikator użycia (0x0EA):
KEYCODE_VOLUME_DOWN
- Strona z informacjami o użytkowaniu (0xC) Identyfikator informacji o użytkowaniu (0x0CF):
KEYCODE_VOICE_ASSIST
- Strona użycia (0xC) Identyfikator użycia (0x0CD):
Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i ramę Storage Access Framework (SAF), muszą:
- [C-3-1] MUSI rozpoznawać wszystkie urządzenia połączone zdalnie przez protokół MTP (Media Transfer Protocol) i uzyskiwać dostęp do ich zawartości za pomocą intencji
ACTION_GET_CONTENT
,ACTION_OPEN_DOCUMENT
iACTION_CREATE_DOCUMENT
. .
Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i USB typu C, muszą:
- [C-4-1] MUSI implementować funkcję portu podwójnego zastosowania zgodnie ze specyfikacją USB Type-C (sekcja 4.5.1.3.3). W przypadku portów Dual Role na urządzeniach z gniazdem słuchawek 3, 5 mm wykrywanie USB (tryb hosta) MOŻE być domyślnie wyłączone, ale użytkownik MUSI mieć możliwość jego włączenia.
- [C-SR-2] ZALECAMY obsługę interfejsu DisplayPort, ZALECAMY obsługę szybkości transmisji danych SuperSpeed USB oraz ZALECAMY obsługę Power Delivery do przełączania ról danych i mocy.
- [C-SR-3] BARDZO ZALECAMY, aby nie obsługiwać trybu akcesoriów adaptera audio opisanego w Załączniku A w specyfikacji kabla i złącza USB Type-C w wersji 1.2.
- NALEŻY zaimplementować model Try.*, który jest najbardziej odpowiedni dla danego formatu urządzenia. Na przykład urządzenie przenośne POWINNA implementować model Try.SNK.
7.8. Audio
7.8.1. mikrofon
Jeśli implementacje urządzeń zawierają mikrofon, muszą:
- [C-1-1] NALEŻY podać stałą
android.hardware.microphone
. - [C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku podane w sekcji 5.4.
- [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku podane w sekcji 5.6.
- [C-SR-1] ZALECAMY, aby obsługiwać nagrywanie w zakresie ultradźwięków zgodnie z opisem w sekcji 7.8.3.
Jeśli implementacje na urządzeniu pomijają mikrofon, mogą:
- [C-2-1] NIE należy raportować stałej funkcji
android.hardware.microphone
. - [C-2-2] NALEŻY zaimplementować interfejs API do nagrywania dźwięku zgodnie z sekcją 7.
7.8.2. Wyjście audio
Jeśli implementacje urządzeń zawierają głośnik lub port wyjściowy audio/multimedia dla urządzeń peryferyjnych, takich jak 4-żyłowe gniazdo słuchawek 3,5 mm lub port w trybie hosta USB za pomocą klasy audio USB, muszą:
- [C-1-1] NALEŻY podać stałą
android.hardware.audio.output
. - [C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku podane w sekcji 5.5.
- [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku podane w sekcji 5.6.
- [C-SR-1] ZALECAMY, aby obsługiwać odtwarzanie z bliską ultradźwiękiem zgodnie z opisem w sekcji 7.8.3.
Jeśli implementacje urządzeń nie zawierają głośnika ani portu wyjściowego audio, nie mogą:
- [C-2-1] NIE należy zgłaszać funkcji
android.hardware.audio.output
. - [C-2-2] NALEŻY zaimplementować interfejsy API związane z wyjściami audio jako co najmniej operacje niewymagające działania.
W celu tej sekcji „port wyjściowy” to interfejs fizyczny, taki jak gniazdo słuchawek 3, 5 mm, HDMI lub port w trybie hosta USB z klasą audio USB. Obsługa wyjścia audio za pomocą protokołów radiowych, takich jak Bluetooth, Wi-Fi lub sieć komórkowa, nie kwalifikuje się jako „port wyjściowy”.
7.8.2.1. Gniazda analogowe
Aby zapewnić zgodność z zestawami słuchawkowymi i innymi akcesoriami audio korzystającymi z gniazda słuchawek 3,5 mm w ekosystemie Androida, jeśli implementacje urządzeń zawierają co najmniej 1 port analogowy do przesyłania dźwięku, muszą:
- [C-SR-1] MOCNO ZALECAMY, aby co najmniej 1 gniazdo audio było 4-żyłowym gniazdem słuchawek 3,5 mm.
Jeśli implementacje urządzeń mają 4-żyłowe złącze jack 3,5 mm, muszą:
- [C-1-1] MUSI obsługiwać odtwarzanie dźwięku w słuchawkach stereo i zestawach słuchawkowych stereo z mikrofonem.
- [C-1-2] MUSI obsługiwać wtyczki audio TRRS z kolejnością styków zgodną ze standardem CTIA.
- [C-1-3] MUSI obsługiwać wykrywanie i mapowanie na kody klawiszy dla 3 zakresów równoważnej impedancji między mikrofonem a uziemieniem na złączu audio:
- 70 omów lub mniej:
KEYCODE_HEADSETHOOK
- 210–290 Ω:
KEYCODE_VOLUME_UP
- 360–680 ohm:
KEYCODE_VOLUME_DOWN
- 70 omów lub mniej:
- [C-1-4] MUSI aktywować
ACTION_HEADSET_PLUG
po włożeniu wtyczki, ale tylko wtedy, gdy wszystkie styki wtyczki dotykają odpowiednich segmentów wtyczki. - [C-1-5] MUSI być w stanie wygenerować co najmniej 150 mV ± 10% napięcia wyjściowego przy impedancji głośnika 32 Ohm.
- [C-1-6] Napięcie polaryzacji mikrofonu MUSI mieścić się w zakresie 1,8–2,9 V.
- [C-1-7] MUSI wykrywać i mapować kody klucza dla następującego zakresu impedancji równoważnej między przewodami mikrofonu i uziemienia na wtyczce audio:
- 110–180 om:
KEYCODE_VOICE_ASSIST
- 110–180 om:
- [C-SR-2] ZALECAMY obsługę wtyczek audio z kolejnością styków OMTP.
- [C-SR-3] MOCNO zalecamy obsługę nagrywania dźwięku ze słuchawek stereo z mikrofonem.
Jeśli implementacje urządzeń mają 4-żyłowe gniazdo słuchawek 3,5 mm i obsługują mikrofon, a także transmitują android.intent.action.HEADSET_PLUG
z dodatkową wartością mikrofonu ustawioną na 1, to:
- [C-2-1] MUSI obsługiwać wykrywanie mikrofonu w podłączonym akcesorium audio.
7.8.2.2. Porty dźwięku cyfrowego
Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.2.1.
7.8.3. Zbliżenie ultradźwiękowe
Dźwięk w zakresie ultradźwięku to pasmo od 18,5 kHz do 20 kHz.
Implementacje na urządzeniu:
- MUSI prawidłowo zgłaszać obsługę funkcji audio zbliżonego do ultradźwięków za pomocą interfejsu API AudioManager.getProperty w ten sposób:
Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
jest ustawiona na „true”, źródła audio VOICE_RECOGNITION
i UNPROCESSED
MUSZĄ spełniać te wymagania:
- [C-1-1] Średnia moc wyjściowa mikrofonu w zakresie 18,5–20 kHz MUSI być niższa o nie więcej niż 15 dB od wartości w zakresie 2 kHz.
- [C-1-2] Współczynnik sygnału do szumu mikrofonu bez ważenia w zakresie 18,5–20 kHz dla tonu 19 kHz przy -26 dBFS MUSI wynosić co najmniej 50 dB.
Jeśli PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
ma wartość „prawda”:
- [C-2-1] Średnia odpowiedź głośnika w zakresie 18,5–20 kHz MUSI być wyższa o co najmniej 40 dB od odpowiedzi w zakresie 2 kHz.
7.8.4. Integralność sygnału
Implementacje na urządzeniu:
- NALEŻY zapewnić ścieżkę sygnału audio bez zakłóceń zarówno dla strumieni wejściowych, jak i wyjściowych na urządzeniach przenośnych, co oznacza brak zakłóceń zmierzonych podczas testu trwającego minutę na ścieżce. Testowanie za pomocą OboeTester „Automated Glitch Test”.
Do testu potrzebny jest dongiel do pętli audio, który jest używany bezpośrednio w gniazdku słuchawek 3,5 mm lub w połączeniu z przejściówką USB-C na 3,5 mm. NALEŻY przetestować wszystkie porty wyjściowe audio.
OboeTester obsługuje obecnie ścieżki AAudio, więc należy przetestować te kombinacje, aby wykryć błędy za pomocą AAudio:
Tryb wydajności | Udostępnianie | Częstotliwość próbkowania wyjściowego | W chansach | Out Chans |
---|---|---|---|---|
LOW_LATENCY | EKSKLUZYWNE | BRAK DANYCH | 1 | 2 |
LOW_LATENCY | EKSKLUZYWNE | BRAK DANYCH | 2 | 1 |
LOW_LATENCY | UDOSTĘPNIONY | BRAK DANYCH | 1 | 2 |
LOW_LATENCY | UDOSTĘPNIONY | BRAK DANYCH | 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ń powinien spełniać te kryteria w przypadku stosunku sygnału do szumu (SNR) i całkowitego zniekształcenia harmonicznego (THD) dla sygnału sinusoidalnego 2000 Hz.
Przetwornik | THD | SNR |
---|---|---|
główny wbudowany głośnik, zmierzony za pomocą zewnętrznego mikrofonu referencyjnego | < 3,0% | >= 50 dB |
główny wbudowany mikrofon, zmierzony za pomocą zewnętrznego głośnika referencyjnego; | < 3,0% | >= 50 dB |
wbudowane analogowe gniazda 3,5 mm, testowane przy użyciu adaptera pętli; | <1% | >= 60 dB |
Adaptery USB dostarczane z telefonem, testowane przy użyciu adaptera pętli zwrotnej | < 1,0% | >= 60 dB |
7.9. Rzeczywistość wirtualna
Android zawiera interfejsy API i funkcje do tworzenia aplikacji do rzeczywistości wirtualnej (VR), w tym aplikacji do VR mobilnego o wysokiej jakości. Implementacje na urządzeniu MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z opisem w tej sekcji.
7.9.1. Tryb rzeczywistości wirtualnej
Android obsługuje tryb VR, który umożliwia renderowanie powiadomień w stereoskopowym obrazie 3D i wyłącza jednooczne wyświetlanie elementów interfejsu systemu, gdy aplikacja VR ma na siebie nałożony fokus użytkownika.
7.9.2. Tryb rzeczywistości wirtualnej – wysoka wydajność
Jeśli implementacje urządzeń obsługują tryb VR, to:
- [C-1-1] Musi mieć co najmniej 2 rdzenie fizyczne.
- [C-1-2] NALEŻY zadeklarować funkcję
android.hardware.vr.high_performance
. - [C-1-3] MUSI obsługiwać tryb ciągłej wydajności.
- [C-1-4] MUSI obsługiwać OpenGL ES 3.2.
- [C-1-5] MUST support
android.hardware.vulkan.level
0. - NALEŻY obsługiwać
android.hardware.vulkan.level
1 lub nowszą. - [C-1-6] NALEŻY wdrożyć rozszerzenia
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
iEGL_EXT_image_gl_colorspace
oraz udostępnić je na liście dostępnych rozszerzeń EGL. - [C-1-8] NALEŻY zaimplementować rozszerzenia
GL_EXT_multisampled_render_to_texture2
,GL_OVR_multiview
,GL_OVR_multiview2
iGL_EXT_protected_textures
oraz udostępnić je na liście dostępnych rozszerzeń GL. - [C-SR-1] ZALECAMY WDRAŻENIE:
GL_EXT_external_buffer
,GL_EXT_EGL_image_array
,GL_OVR_multiview_multisampled_render_to_texture
, oraz udostępnienie rozszerzeń na liście dostępnych rozszerzeń GL. - [C-SR-2] Zdecydowanie zalecamy obsługę Vulkan 1.1.
- [C-SR-3] ZALECAMY wdrażanie interfejsów
VK_ANDROID_external_memory_android_hardware_buffer
,VK_GOOGLE_display_timing
iVK_KHR_shared_presentable_image
oraz wyświetlanie ich na liście dostępnych rozszerzeń Vulkan. - [C-SR-4] ZALECAMY udostępnienie co najmniej 1 rodziny kolejek Vulkan, w której
flags
zawiera zarównoVK_QUEUE_GRAPHICS_BIT
, jak iVK_QUEUE_COMPUTE_BIT
, a wartośćqueueCount
wynosi co najmniej 2. - [C-1-7] GPU i wyświetlacz MUSZĄ umożliwiać synchronizowanie dostępu do wspólnego bufora przedniego w taki sposób, aby renderowanie treści VR z wyświetlaniem naprzemiennym oczu w 60 FPS z 2 kontekstami renderowania było wyświetlane bez widocznych artefaktów rozrywania obrazu.
- [C-1-9] NALEŻY wdrożyć obsługę flag
AHardwareBuffer
AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
,AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
iAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
zgodnie z wymaganiami NDK. - [C-1-10] NALEŻY wdrożyć obsługę
AHardwareBuffer
z dowolną kombinacją flag użyciaAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
,AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
iAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
w przynajmniej tych formatach:AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
iAHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
. - [C-SR-5] ZALECAMY, aby obsługiwać alokację
AHardwareBuffer
z więcej niż 1 warstwą oraz flagami i formatami określonymi w C-1-10. - [C-1-11] MUSI obsługiwać dekodowanie H.264 w rozdzielczości co najmniej 3840 x 2160 przy 30 fps, skompresowane do średnio 40 Mb/s (co odpowiada 4 przypadkom 1920 x 1080 przy 30 fps i 10 Mb/s lub 2 przypadkom 1920 x 1080 przy 60 fps i 20 Mb/s).
- [C-1-12] MUSI obsługiwać HEVC i VP9, MUSI być w stanie dekodować co najmniej 1920 x 1080 przy 30 fps skompresowanych do średnio 10 Mb/s i POWINNA być w stanie dekodować 3840 x 2160 przy 30 fps i 20 Mb/s (co odpowiada 4 przypadkom 1920 x 1080 przy 30 fps i 5 Mb/s).
- [C-1-13] MUSI obsługiwać interfejs API
HardwarePropertiesManager.getDeviceTemperatures
i zwracać dokładne wartości temperatury skóry. - [C-1-14] Musi mieć wbudowany ekran o rozdzielczości co najmniej 1920 x 1080.
- [C-SR-6] MOCNO ZALECAMY, aby rozdzielczość wyświetlacza wynosiła co najmniej 2560 × 1440.
- [C-1-15] Wyświetlacz MUSI odświeżać obraz co najmniej z częstotliwością 60 Hz w trybie VR.
- [C-1-17] Wyświetlacz MUSI obsługiwać tryb o niskiej trwałości z trwałością do 5 ms, gdzie trwałość to czas, przez który piksel emituje światło.
- [C-1-18] MUSI obsługiwać rozszerzenie długości danych Bluetooth 4.2 i Bluetooth LE (sekcja 7.4.3).
- [C-1-19] MUSI obsługiwać i odpowiednio raportować Typ kanału bezpośredniego w przypadku wszystkich tych domyślnych typów czujników:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] ZALECAMY obsługę kanału bezpośredniego
TYPE_HARDWARE_BUFFER
dla wszystkich typów kanałów bezpośrednich wymienionych powyżej. - [C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru w urządzeniu
android.hardware.hifi_sensors
, jak określono w sekcji 7.3.9. - [C-SR-8] MOCNO zalecamy obsługę funkcji
android.hardware.sensor.hifi_sensors
. - [C-1-22] Musisz mieć opóźnienie od ruchu do fotonu nie większe niż 28 ms.
- [C-SR-9] MOCNO ZALECAMY, aby opóźnienie od ruchu do fotonu nie przekraczało 20 ms.
- [C-1-23] Współczynnik pierwszego kadru (first-frame ratio) musi wynosić co najmniej 85%, gdzie współczynnik ten jest obliczany jako stosunek jasności pikseli w pierwszym kadrze po przejściu od czerni do bieli do jasności białych pikseli w stanie ustalonym.
- [C-SR-10] MOCNO ZALECAMY, aby współczynnik pierwszego kadru wynosił co najmniej 90%.
- MOŻE udostępniać procesor wyłącznie aplikacji na pierwszym planie i MOŻE obsługiwać interfejs API
Process.getExclusiveCores
, aby zwracać liczbę rdzeni procesora, które są dostępne wyłącznie dla aplikacji na pierwszym planie.
Jeśli obsługiwany jest rdzeń wyłączny, to:
- [C-2-1] Aplikacja NIE MOŻE zezwalać na uruchamianie w sobie żadnych innych procesów w przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.
7.10. Reakcja na dotyk
Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.2.1.
7.11. Klasa Media Performance
Klasę skuteczności multimediów w implementacji urządzenia można uzyskać z interfejsu API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
. Wymagania dotyczące klasy wydajności multimediów są zdefiniowane dla każdej wersji Androida, począwszy od R (wersja 30). Specjalna wartość 0 oznacza, że urządzenie nie należy do klasy wydajności multimediów.
Jeśli implementacje urządzeń zwracają wartość niezerową dla 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ądzeniu przenośnym.
[C-1-3] NALEŻY spełnić wszystkie wymagania dotyczące „Klasy skuteczności reklamy medialnej” opisane w sekcji 2.2.7.
Inaczej mówiąc, klasa wydajności multimediów w Androidzie T jest zdefiniowana tylko w przypadku urządzeń przenośnych z Androidem w wersji T, S lub R.
Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.2.7.
8. Wydajność i moc
Niektóre kryteria minimalnej wydajności i mocy są kluczowe dla wrażeń użytkowników i mają wpływ na założenia wyjściowe, które deweloperzy powinni uwzględnić podczas tworzenia aplikacji.
8.1. Spójność wrażeń użytkowników
Aby zapewnić płynne działanie interfejsu użytkownika, należy spełnić określone wymagania minimalne, które zagwarantują spójną liczbę klatek na sekundę i czas reakcji w przypadku aplikacji i gier. W zależności od typu urządzenia implementacje MOŻE wymagać mierzalnych wartości opóźnień interfejsu użytkownika i przełączania zadań zgodnie z opisem w sekcji 2.
8.2. Wydajność dostępu do plików I/O
Udostępnianie wspólnej wartości granicznej dla spójnej wydajności dostępu do plików w pamięci na potrzeby prywatnych danych aplikacji (partycji /data
) pozwala deweloperom aplikacji na sformułowanie odpowiednich oczekiwań, które pomogą im w projektowaniu oprogramowania. W zależności od typu urządzenia implementacje MOŻE wymagać spełnienia pewnych wymagań opisanych w sekcji 2 w przypadku tych operacji odczytu i zapisu:
- Wydajność sekwencyjnego zapisu. Pomiar wykonano podczas zapisywania pliku o rozmiarze 256 MB za pomocą bufora zapisu o rozmiarze 10 MB.
- Skuteczność zapisu losowego. Pomiar dokonany podczas zapisywania pliku o rozmiarze 256 MB za pomocą bufora zapisu o rozmiarze 4 KB.
- Wydajność sekwencyjnego odczytu. Zmierzono podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
- Wydajność losowego odczytu. Zmierzono podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.
8.3. Tryby oszczędzania energii
Jeśli implementacje urządzeń zawierają funkcje poprawiające zarządzanie energią urządzenia, które są zawarte w AOSP (np. grupa w trybie gotowości aplikacji, Doze) lub rozszerzają funkcje, aby zastosować ograniczenia silniejsze niż grupa w trybie gotowości aplikacji ZROBIONEJ Z ZAKRESU ZARZĄDZANIA MOCĄ, muszą:
- [C-1-1] NIE MOŻE odbiegać od implementacji AOSP w zakresie uruchamiania, konserwacji, algorytmów wybudzania i używania globalnych ustawień systemu lub DeviceConfig w przypadku trybów oszczędzania energii App Standby i Doze.
- [C-1-2] NIE MOŻE odbiegać od implementacji AOSP w zakresie korzystania z ustawień globalnych lub DeviceConfig do zarządzania ograniczaniem szybkości wykonywania zadań, alarmów i sieci w przypadku aplikacji w każdej grupie w trybie gotowości aplikacji.
- [C-1-3] W przypadku liczby poziomów aplikacji w stanie gotowości używanych w ramach aplikacji w stanie gotowości NIE MOŻNA odbiegać od implementacji AOSP.
- [C-1-4] NALEŻY wdrożyć grupy czuwania aplikacji i funkcję Uśpienie zgodnie z opisem w Zarządzanie zasilaniem.
- [C-1-5] NALEŻY zwrócić
true
dlaPowerManager.isPowerSaveMode()
, gdy urządzenie jest w trybie oszczędzania energii. - [C-1-6] MUSISZ umożliwić użytkownikowi wyświetlanie wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze lub z optymalizacji baterii, a także MUSISZ zaimplementować działanie ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, aby poprosić użytkownika o zezwolenie na ignorowanie optymalizacji baterii przez aplikację.
- [C-SR-1] MOCNO ZALECAMY, aby umożliwić użytkownikom włączenie i wyłączenie funkcji oszczędzania baterii.
- [C-SR-2] MOCNO POLECAMY zapewnienie użytkownikom możliwości wyświetlania wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.
Jeśli implementacje na urządzeniach rozszerzają funkcje zarządzania energią zawarte w AOSP, a rozszerzenie to stosuje bardziej rygorystyczne ograniczenia niż kategoria rzadko używanych aplikacji w stanie gotowości, zapoznaj się z sekcją 3.5.1.
Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ wykorzystywać dowolne lub wszystkie 4 stany uśpienia określone przez interfejs ACPI (Advanced Configuration and Power Interface).
Jeśli implementacje urządzeń obsługują stany zasilania S4 zgodnie z definicją ACPI, to:
- [C-1-1] Musisz przejść do tego stanu tylko po tym, jak użytkownik wykonał wyraźne działanie, aby umieścić urządzenie w stanie nieaktywnym (np. przez zamknięcie pokrywy, która jest fizyczną częścią urządzenia, lub wyłączenie pojazdu lub telewizora) i zanim użytkownik ponownie aktywuje urządzenie (np. przez otwarcie pokrywy lub ponowne włączenie pojazdu lub telewizora).
Jeśli implementacje urządzeń implementują stany zasilania S3 zgodnie z definicją ACPI, to:
[C-2-1] MUSI spełniać wymagania podane w sekcji C-1-1 lub MUSI przejść w stan S3 tylko wtedy, gdy aplikacje innych firm nie potrzebują zasobów systemowych (np. ekranu czy procesora).
Z drugiej strony, gdy aplikacje innych firm potrzebują zasobów systemowych, muszą opuścić stan S3, jak opisano w tym pakiecie SDK.
Podczas gdy aplikacje innych firm proszą o utrzymanie ekranu włączonego za pomocą funkcji
FLAG_KEEP_SCREEN_ON
lub o utrzymanie procesora w stanie aktywnym za pomocą funkcjiPARTIAL_WAKE_LOCK
, urządzenie NIE MOŻE wejść w stan S3, chyba że użytkownik wykona wyraźne działanie, aby umieścić urządzenie w stanie nieaktywnym, jak opisano w sekcji C-1-1. Z drugiej strony, gdy zostanie wywołane zadanie implementowane przez aplikacje innych firm za pomocą JobSchedulera lub gdy Komunikacja w chmurze Firebase zostanie dostarczona do aplikacji innych firm, urządzenie MUSI opuścić stan S3, chyba że użytkownik przełączy je w stan nieaktywny. To niepełna lista przykładów. AOSP implementuje rozbudowane sygnały aktywacji, które powodują przebudzenie z tego stanu.
8.4. Rachunkowość zużycia energii
Dokładniejsze rejestrowanie i raportowanie zużycia energii daje deweloperowi aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorców zużycia energii aplikacji.
Implementacje na urządzeniu:
- [C-SR-1] BARDZO ZALECANA: podaj profil zużycia energii dla poszczególnych komponentów, który definiuje wartość bieżącego zużycia energii dla każdego komponentu sprzętowego oraz przybliżony pobór energii przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
- [C-SR-2] ZALECAMY, aby wszystkie wartości zużycia energii były podawane w miliamperogodzinach (mAh).
- [C-SR-3] MOCNO ZALECANA rejestracja zużycia energii przez procesor dla każdego identyfikatora UID procesu.
Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra
uid_cputime
. - [C-SR-4] ZDECYDOWANIE ZALECAMY udostępnienie tego użycia energii za pomocą polecenia
adb shell dumpsys batterystats
w powłoce dla dewelopera aplikacji. - NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.
8.5. Stabilna wydajność
Wydajność może się znacznie wahać w przypadku aplikacji o wysokiej wydajności, które działają przez dłuższy czas. Może to być spowodowane innymi aplikacjami działającymi w tle lub ograniczeniem procesora z powodu limitów temperatury. Android zawiera interfejsy programowe, dzięki którym aplikacja na pierwszym planie może poprosić system o zoptymalizowanie alokacji zasobów, aby poradzić sobie z takimi wahaniami.
Implementacje na urządzeniu:
[C-0-1] Musisz dokładnie zgłosić obsługę trybu ciągłej wydajności za pomocą metody interfejsu API
PowerManager.isSustainedPerformanceModeSupported()
.Powinien obsługiwać tryb ciągłej wydajności.
Jeśli implementacje urządzeń zgłaszają obsługę trybu ciągłej wydajności, to:
- [C-1-1] NALEŻY zapewnić najwyższej aplikacji na pierwszym planie spójny poziom wydajności przez co najmniej 30 minut, gdy aplikacja tego zażąda.
- [C-1-2] Musisz przestrzegać zasad interfejsu API
Window.setSustainedPerformanceMode()
i innych powiązanych interfejsów API.
Jeśli implementacje urządzeń zawierają co najmniej 2 rdzenie procesora, muszą:
- NALEŻY zapewnić co najmniej 1 rdzeń, który może być zarezerwowany przez aplikację na pierwszym planie.
Jeśli implementacje urządzeń obsługują rezerwowanie 1 rdzenia wyłącznie dla aplikacji na pierwszym planie, to:
- [C-2-1] Musisz przekazać przez metodę interfejsu API
Process.getExclusiveCores()
numery identyfikatorów zasobów jądrowych, które mogą być zarezerwowane przez główną aplikację na pierwszym planie. - [C-2-2] Nie wolno zezwalać na uruchamianie w rdzeniu aplikacji żadnych procesów w przestrzeni użytkownika z wyjątkiem sterowników urządzeń, ale można zezwolić na uruchamianie niektórych procesów jądra w razie potrzeby.
Jeśli implementacje urządzeń nie obsługują rdzenia wyłącznego, nie:
- [C-3-1] MUSI zwracać pustą listę za pomocą metody interfejsu API
Process.getExclusiveCores()
.
9. Zgodność z modelem zabezpieczeń
Implementacje na urządzeniu:
[C-0-1] NALEŻY zaimplementować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji interfejsów API w dokumentacji dla deweloperów Androida.
[C-0-2] MUSI obsługiwać instalowanie samodzielnie podpisanych aplikacji bez konieczności uzyskiwania dodatkowych zezwoleń lub certyfikatów od stron trzecich lub organów.
Jeśli implementacje na urządzeniach deklarują funkcję android.hardware.security.model.compatible
:
- [C-1-1] MUSI obsługiwać wymagania wymienione w następujących podpunktach.
9.1. Uprawnienia
Implementacje na urządzeniu:
[C-0-1] Aplikacja MUSI obsługiwać model uprawnień Androida i model ról Androida zdefiniowane w dokumentacji dla deweloperów Androida. W szczególności muszą one egzekwować wszystkie uprawnienia i role zdefiniowane w dokumentacji SDK. Żadnych uprawnień ani ról nie można pominąć, zmienić ani zignorować.
MOŻESZ dodać dodatkowe uprawnienia, o ile nowe ciągi znaków identyfikatora uprawnień nie znajdują się w przestrzeni nazw
android.\*
.[C-0-2] Uprawnienia z
protectionLevel
PROTECTION_FLAG_PRIVILEGED
MUSZĄ być przyznawane tylko aplikacjom wstępnie zainstalowanym na ścieżkach uprzywilejowanych obrazu systemu (a także plików APEX) i należeć do podzbioru uprawnień dozwolonych w przypadku każdej aplikacji. Implementacja AOSP spełnia ten wymóg, odczytując i szanując uprawnienia dozwolone dla każdej aplikacji z plików na ścieżceetc/permissions/
i traktując ścieżkęsystem/priv-app
jako ścieżkę uprzywilejowaną.
Uprawnienia z poziomem ochrony niebezpieczny to uprawnienia czasu działania.
Aplikacje z większą liczbą niż targetSdkVersion
> 22 wymagają ich w czasie wykonywania.
Implementacje na urządzeniu:
- [C-0-3] MUSI wyświetlać specjalny interfejs, aby użytkownik mógł zdecydować, czy przyznać żądane uprawnienia w czasie działania, a także udostępnić interfejs, za pomocą którego użytkownik może zarządzać uprawnieniami w czasie działania.
- [C-0-4] Musi istnieć tylko jedna implementacja obu interfejsów użytkownika. Jeśli implementacja urządzenia obsługuje urządzenie towarzyszące, urządzenie towarzyszące MOŻE udostępnić dodatkowy interfejs.
[C-0-5] NIE NALEŻY przyznawać aplikacji żadnych uprawnień czasu działania, chyba że:
- są instalowane w momencie wysyłki urządzenia, ORAZ
zgodę użytkownika można uzyskać przed użyciem uprawnienia przez aplikację,
LUB
Uprawnienia w czasie działania są przyznawane zgodnie z domyślnymi zasadami przyznawania uprawnień lub w przypadku posiadania roli na platformie.
[C-0-6] NALEŻY przyznać uprawnienia
android.permission.RECOVER_KEYSTORE
tylko aplikacjom systemowym, które rejestrują odpowiednio zabezpieczonego agenta odzyskiwania. prawidłowo zabezpieczony agent odzyskiwania to oprogramowanie na urządzeniu, które synchronizuje się z zdalnymi miejscami na dane poza urządzeniem. Oprogramowanie to jest wyposażone w sprzęt zabezpieczający o odpowiedniej jakości lub wyższej niż opisana w usłudze Google Cloud Key Vault, aby zapobiec atakom z wykorzystaniem metody brute force na czynniku wiedzy na ekranie blokady.
Implementacje na urządzeniu:
[C-0-7] Aplikacja MUSI przestrzegać właściwości uprawnień dotyczących lokalizacji na Androidzie, gdy prosi o dane o lokalizacji lub aktywności fizycznej za pomocą standardowego interfejsu API Androida lub zastrzeżonego mechanizmu. Dane te obejmują:
- Lokalizacja urządzenia (np. szerokość i długość geograficzna) zgodnie z opisem w sekcji 9.8.8.
- informacje, które mogą służyć do określenia lub oszacowania lokalizacji urządzenia (np. SSID, BSSID, identyfikator komórki lub lokalizacja sieci, z którą jest połączone urządzenie);
- Aktywność fizyczna użytkownika lub klasyfikacja aktywności fizycznej.
W szczególności dotyczy to implementacji na urządzeniach:
- [C-0-8] Musisz uzyskać zgodę użytkownika na dostęp aplikacji do danych o lokalizacji lub aktywności fizycznej.
- [C-0-9] MUST grant a runtime permission ONLY to the app that holds
sufficient permission as described on SDK.
Na przykład: TelephonyManager#getServiceState wymaga
android.permission.ACCESS_FINE_LOCATION
.
Jedynymi wyjątkami od powyższych właściwości uprawnień do lokalizacji na Androidzie są aplikacje, które nie uzyskują dostępu do lokalizacji w celu określenia lub identyfikacji lokalizacji użytkownika. Dotyczy to w szczególności:
- Gdy aplikacje mają uprawnienia
RADIO_SCAN_WITHOUT_LOCATION
. - w celu konfiguracji urządzenia, gdy aplikacje systemowe mają uprawnienia
NETWORK_SETTINGS
lubNETWORK_SETUP_WIZARD
;
Uprawnienia mogą być oznaczone jako ograniczone, co zmienia ich działanie.
[C-0-10] Uprawnienia oznaczone flagą
hardRestricted
NIE MOGĄ zostać przyznane aplikacji, chyba że:- Plik APK aplikacji znajduje się na partycji systemowej.
- Użytkownik przypisuje do aplikacji rolę powiązaną z uprawnieniami
hardRestricted
. - Instalator przyznaje aplikacji uprawnienia
hardRestricted
. - Aplikacja ma przyznane uprawnienie
hardRestricted
w poprzedniej wersji Androida.
[C-0-11] Aplikacje z uprawnieniami
softRestricted
MUSZĄ mieć tylko ograniczony dostęp i NIE MOGĄ uzyskać pełnego dostępu, dopóki nie zostaną dodane do listy dozwolonych w pakiecie SDK, gdzie dla każdego uprawnieniasoftRestricted
zdefiniowany jest pełny i ograniczony dostęp (np.READ_EXTERNAL_STORAGE
).[C-0-12] NIE MOŻESZ udostępniać żadnych funkcji ani interfejsów API, które umożliwiają obejście ograniczeń dostępu zdefiniowanych w interfejsach API setPermissionPolicy i setPermissionGrantState.
[C-0-13] DO nagrywania i śledzenia każdego dostępu do danych chronionych przez niebezpieczne uprawnienia z działalności i usług Androida należy używać interfejsów AppOpsManager API.
[C-0-14] NALEŻY przypisywać role tylko do aplikacji z funkcjami spełniającymi wymagania dotyczące ról.
[C-0-15] Nie wolno definiować ról, które są duplikatami lub superzbiorem funkcji ról zdefiniowanych przez platformę.
Jeśli urządzenia zgłaszają android.software.managed_users
, to:
- [C-1-1] Nie może mieć następujących uprawnień przyznanych przez administratora:
- Lokalizacja (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Aparat (CAMERA)
- Mikrofon (RECORD_AUDIO)
- Czujnik na ciele (BODY_SENSORS)
- Aktywność fizyczna (ACTIVITY_RECOGNITION)
Jeśli implementacje urządzeń umożliwiają użytkownikowi wybór aplikacji, które mogą rysować na innych aplikacjach za pomocą aktywności obsługującej intencję ACTION_MANAGE_OVERLAY_PERMISSION
, to:
- [C-2-1] Należy zadbać o to, aby wszystkie działania z filtrami intencji dla intencji
ACTION_MANAGE_OVERLAY_PERMISSION
miały ten sam ekran interfejsu niezależnie od aplikacji inicjującej i informacje, które ona udostępnia.
Jeśli implementacje urządzeń zgłaszają android.software.device_admin, to:
- [C-3-1] MUST show a disclaimer during fully managed device setup (device owner setup) stating that the IT admin will have the ability to allow apps to control settings on the phone including microphone, camera and location, with options for user to continue setup or exit setup UNLESS the admin has opted out of control of permissions on the device.
Jeśli implementacje urządzeń wstępnie instalują pakiety zawierające dowolną 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ń opisane w sekcji „9.8.6 Przechwytywanie treści”.
- [C-4-2] Aplikacja NIE MOŻE mieć uprawnienia android.permission.INTERNET. Jest to bardziej restrykcyjne niż zalecenie o wysokim priorytecie wymienione w sekcji 9.8.6.
- [C-4-3] NIE MOŻE wiązać się z innymi aplikacjami, z wyjątkiem tych aplikacji systemowych: Bluetooth, Kontakty, Media, Telefonia, SystemUI oraz komponentów udostępniających interfejsy internetowe.Jest to bardziej restrykcyjne niż zalecenie w sekcji 9.8.6.
9.2. UID i izolacja procesów
Implementacje na urządzeniu:
- [C-0-1] Musi obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja działa jako unikalny identyfikator UID w stylu Unixa i w oddzielnym procesie.
- [C-0-2] MUSI obsługiwać uruchamianie wielu aplikacji pod tym samym identyfikatorem użytkownika systemu Linux, pod warunkiem, że aplikacje są prawidłowo podpisane i skonstruowane zgodnie z definicją w dokumentacji Bezpieczeństwo i uprawnienia.
9.3. Uprawnienia do systemu plików
Implementacje na urządzeniu:
- [C-0-1] MUSI obsługiwać model uprawnień dostępu do plików Androida zgodnie z definicją w dokumentacji dotyczącej zabezpieczeń i uprawnień.
9.4. Alternatywne środowiska wykonawcze
Implementacje na urządzeniach MUSZĄ zachowywać spójność modelu zabezpieczeń i uprawnień Androida, nawet jeśli obejmują środowiska uruchomieniowe, które wykonują aplikacje za pomocą innego oprogramowania lub technologii niż kod wykonywalny Dalvik lub kod natywny. Krótko mówiąc:
[C-0-1] Alternatywny środowisko uruchomieniowe MUSI być aplikacją na Androida i stosować się do standardowego modelu zabezpieczeń Androida, zgodnie z opisem w sekcji 9.
[C-0-2] Alternatywnym środowiskom uruchomieniowym NIE NALEŻY przyznawać dostępu do zasobów chronionych uprawnieniami, których nie żądano w pliku
AndroidManifest.xml
środowiska uruchomieniowego za pomocą mechanizmu <uses-permission
>.[C-0-3] Alternatywny czas wykonywania NIE MOŻE zezwalać aplikacjom na korzystanie z funkcji chronionych przez uprawnienia Androida, które są ograniczone do aplikacji systemowych.
[C-0-4] Alternatywny czas wykonywania MUSI być zgodny z modelem piaskownicy Androida, a zainstalowane aplikacje korzystające z alternatywnego czasu wykonywania NIE MOGĄ ponownie używać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida dotyczących udostępnionego identyfikatora użytkownika i certyfikatu podpisywania.
[C-0-5] Alternatywny czas wykonywania NIE MOŻE uruchamiać, przyznawać ani uzyskiwać dostępu do piaskownicy odpowiadającej innym aplikacjom na Androida.
[C-0-6] Alternatywny czas wykonywania NIE MOŻE być uruchamiany z uprawnieniami superużytkownika (root) ani nie może przyznawać takich uprawnień innym aplikacjom ani innym identyfikatorom użytkownika.
[C-0-7] Jeśli pliki
.apk
alternatywnych środowisk wykonawczych są uwzględnione w pliku obrazu systemu implementacji urządzenia, muszą być podpisane za pomocą klucza innego niż klucz użyty do podpisania innych aplikacji zawartych w implementacjach urządzenia.[C-0-8] Podczas instalowania aplikacji alternatywne środowisko wykonawcze MUSI uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację.
[C-0-9] Gdy aplikacja potrzebuje użyć zasobu urządzenia, do którego dostęp jest możliwy na podstawie odpowiedniego uprawnienia Androida (np. aparatu lub GPS-a), środowisko uruchomieniowe MUSI poinformować użytkownika, że aplikacja będzie mogła uzyskać dostęp do tego zasobu.
[C-0-10] Jeśli środowisko uruchomieniowe nie rejestruje w taki sposób możliwości aplikacji, MUSI ono podać wszystkie uprawnienia, które posiada samo środowisko uruchomieniowe, podczas instalowania dowolnej aplikacji korzystającej z tego środowiska.
Alternatywny czas wykonywania POWINIEN instalować aplikacje za pomocą
PackageManager
w oddzielnych piaskownicach Androida (identyfikatory użytkowników Linuksa itp.).Alternatywny czas wykonywania MOŻE udostępniać jedną piaskownicę Androida, z której korzystają wszystkie aplikacje korzystające z tego alternatywnego środowiska uruchomieniowego.
9,5. Pomoc dla wielu użytkowników
Android obsługuje wielu użytkowników oraz zapewnia pełną izolację użytkowników i klonowanie profili użytkowników z częściową izolacją(np. pojedynczy dodatkowy profil użytkownika typu android.os.usertype.profile.CLONE
).
- Implementacje urządzeń MOGĄ, ale NIE POWINNY umożliwiać używania urządzenia przez wielu użytkowników, jeśli korzystają one z wymiennych nośników danych jako głównej pamięci zewnętrznej.
Jeśli implementacje urządzeń obsługują wielu użytkowników, muszą:
- [C-1-2] W przypadku każdego użytkownika MUSISZ wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji referencyjnej Bezpieczeństwo i uprawnienia dotyczącej interfejsów API.
- [C-1-3] Musisz mieć oddzielne i odizolowane katalogi współdzielonego miejsca na dane aplikacji (zwanego też
/sdcard
) dla każdej instancji użytkownika. - [C-1-4] NALEŻY zadbać o to, aby aplikacje należące do danego użytkownika i uruchamiane w jego imieniu nie mogły wyświetlać, odczytywać ani zapisywać plików należących do innego użytkownika, nawet jeśli dane obu użytkowników są przechowywane w tym samym woluminie lub systemie plików.
- [C-1-5] NALEŻY szyfrować zawartość karty SD, gdy włączono obsługę wielu użytkowników, używając klucza przechowywanego tylko na niewymiennym nośniku, dostępnym tylko dla systemu, jeśli implementacje urządzeń używają wymiennych nośników dla interfejsów API zewnętrznego magazynu danych. Ponieważ w takim przypadku media nie będą czytelne dla komputera hosta, implementacje urządzeń będą musiały przejść na MTP lub podobny system, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika.
Jeśli implementacje urządzeń obsługują wielu użytkowników, to w przypadku wszystkich użytkowników (z wyjątkiem użytkowników utworzonych specjalnie do uruchamiania dwóch instancji tej samej aplikacji) obowiązują następujące zasady:
- [C-2-1] Musisz mieć oddzielne i odizolowane katalogi wspólnej pamięci aplikacji (np. /sdcard) dla każdej instancji użytkownika.
- [C-2-2] NALEŻY zadbać o to, aby aplikacje należące do danego użytkownika i uruchamiane w jego imieniu nie mogły wyświetlać, odczytywać ani zapisywać plików należących do innego użytkownika, nawet jeśli dane obu użytkowników są przechowywane na tym samym woluminie lub w tym samym systemie plików.
Implementacje urządzeń mogą tworzyć dodatkowy profil użytkownika typu android.os.usertype.profile.CLONE
dla głównego użytkownika (i tylko dla głównego użytkownika) w celu uruchamiania dwóch instancji tej samej aplikacji. Te dwie instancje współdzielą częściowo odizolowane miejsce na dane, są prezentowane użytkownikowi w tym samym czasie w menu i wyświetlane w tym samym widoku Ostatnie.
Można go na przykład wykorzystać, aby umożliwić użytkownikowi zainstalowanie 2 oddzielnych instancji jednej aplikacji na urządzeniu z 2 kartami SIM.
Jeśli implementacje urządzeń tworzą dodatkowy profil użytkownika, o którym mowa powyżej, to:
- [C-3-1] MUSI zapewniać dostęp tylko do pamięci lub danych, które są już dostępne dla nadrzędnego profilu użytkownika lub są bezpośrednio własnością tego dodatkowego profilu użytkownika.
- [C-3-2] NIE MOŻE być to profil służbowy.
- [C-3-3] Musisz mieć odizolowane katalogi danych aplikacji od nadrzędnego konta użytkownika.
- [C-3-4] NIE wolno zezwalać na utworzenie dodatkowego profilu użytkownika, jeśli istnieje właściciel urządzenia (patrz sekcja 3.9.1) lub zezwalać na skonfigurowanie właściciela urządzenia bez wcześniejszego usunięcia dodatkowego profilu użytkownika.
9,6. Ostrzeżenie dotyczące SMS-ów specjalnych
Android obsługuje ostrzeżenia użytkowników przed wysyłaniem specjalnych SMS-ów. SMS-y specjalne to wiadomości tekstowe wysyłane do usługi zarejestrowanej u operatora, za którą użytkownik może zostać obciążony opłatą.
Jeśli implementacje na urządzeniu deklarują obsługę android.hardware.telephony
, to:
- [C-1-1] NALEŻY ostrzegać użytkowników przed wysyłaniem SMS-ów na numery zidentyfikowane za pomocą wyrażeń regularnych zdefiniowanych w pliku
/data/misc/sms/codes.xml
na urządzeniu. Dostępny w górę projekt Android Open Source udostępnia implementację, która spełnia ten wymóg.
9,7. Funkcje zabezpieczeń
Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń w jądrze i na platformie, jak opisano poniżej.
Piaskownica Androida zawiera funkcje korzystające z systemu kontroli dostępu (MAC) Security-Enhanced Linux (SELinux), piaskownicy seccomp i innych funkcji zabezpieczeń w rdzeniu systemu Linux. Implementacje na urządzeniu:
- [C-0-1] Musi być zgodny z dotychczasowymi aplikacjami, nawet jeśli SELinux lub inne funkcje zabezpieczeń są wdrażane poniżej platformy Android.
- [C-0-2] Nie wolno stosować widocznego interfejsu użytkownika, gdy wykryto naruszenie zabezpieczeń i udało się je zablokować za pomocą funkcji bezpieczeństwa zaimplementowanej poniżej platformy Android. Można jednak użyć widocznego interfejsu użytkownika, gdy dochodzi do nieblokowanego naruszenia zabezpieczeń, które umożliwia skuteczne wykorzystanie luki.
- [C-0-3] Nie wolno udostępniać użytkownikowi ani deweloperowi aplikacji możliwości konfigurowania SELinux ani innych funkcji zabezpieczeń zaimplementowanych poniżej platformy Android.
- [C-0-4] NIE wolno zezwalać aplikacji, która może wpływać na inną aplikację za pomocą interfejsu API (np. interfejsu Device Administration API) na konfigurowanie zasad, które naruszają zgodność.
- [C-0-5] NALEŻY podzielić framework multimediów na kilka procesów, aby można było przyznawać dostęp do poszczególnych procesów w sposób bardziej szczegółowy, zgodnie z opisem na stronie projektu Android Open Source.
- [C-0-6] NALEŻY wdrożyć mechanizm piaskownicy dla aplikacji jądra, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnych zasad z programów wielowątkowych. Projekt Android Open Source na upstreamie spełnia to wymaganie dzięki włączeniu seccomp-BPF z synchronizacją wątków (TSYNC), jak opisano w sekcji Konfiguracja jądra na stronie source.android.com.
Funkcje integralności i samoochrony jądra są integralną częścią zabezpieczeń Androida. Implementacje na urządzeniu:
- [C-0-7] NALEŻY wdrożyć mechanizmy ochrony przed przepełnieniem bufora stosu jądra.
Przykładami takich mechanizmów są
CC_STACKPROTECTOR_REGULAR
iCONFIG_CC_STACKPROTECTOR_STRONG
. - [C-0-8] Należy wdrożyć ścisłe zabezpieczenia pamięci jądra, w których kod wykonywalny jest tylko do odczytu, dane tylko do odczytu są tylko do odczytu i nie do zapisu, a dane tylko do zapisu są tylko do zapisu (np.
CONFIG_DEBUG_RODATA
lubCONFIG_STRICT_KERNEL_RWX
). - [C-0-9] NALEŻY zaimplementować sprawdzanie rozmiaru statycznych i dynamicznych obiektów oraz ich granic na urządzeniach z poziomem interfejsu API 28 lub nowszym (np.
CONFIG_HARDENED_USERCOPY
). - [C-0-10] NIE WYKONUJ kodu w pamięci przeznaczonej dla użytkownika podczas wykonywania kodu w trybie jądra (np. PXN na sprzęcie lub emulowany za pomocą
CONFIG_CPU_SW_DOMAIN_PAN
lubCONFIG_ARM64_SW_TTBR0_PAN
) na urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym. - [C-0-11] NIE MOŻESZ odczytywać ani zapisywać danych w pamięci użytkownika w rdzeniu poza interfejsami API dostępu do danych użytkownika (np. interfejs API PAN dla sprzętu lub emulowany za pomocą
CONFIG_CPU_SW_DOMAIN_PAN
lubCONFIG_ARM64_SW_TTBR0_PAN
) na urządzeniach pierwotnie dostarczanych z interfejsem API na poziomie 28 lub wyższym. - [C-0-12] NALEŻY wdrożyć izolację tabeli stron jądra, jeśli sprzęt jest podatny na luki CVE-2017-5754 na wszystkich urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym (np.
CONFIG_PAGE_TABLE_ISOLATION
lubCONFIG_UNMAP_KERNEL_AT_EL0
). - [C-0-13] NALEŻY wdrożyć wzmocnienie przewidywania rozgałęzi, jeśli sprzęt jest podatny na CVE-2017-5715 na wszystkich urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym (np.
CONFIG_HARDEN_BRANCH_PREDICTOR
). - [C-SR-1] ZALECAMY, aby dane jądra, które są zapisywane tylko podczas inicjowania, były po inicjowaniu oznaczone jako tylko do odczytu (np.
__ro_after_init
). [C-SR-2] Zdecydowanie zalecamy losowanie układu kodu jądra i pamięci oraz unikanie sytuacji, które mogłyby zagrozić losowości (np.
CONFIG_RANDOMIZE_BASE
z entropią programu rozruchowego za pomocą/chosen/kaslr-seed Device Tree node
lubEFI_RNG_PROTOCOL
).[C-SR-3] ZALECAMY stosowanie integralności przepływu sterowania (CFI) w jądrze, aby zapewnić dodatkową ochronę przed atakami polegającymi na ponownym użyciu kodu (np.
CONFIG_CFI_CLANG
iCONFIG_SHADOW_CALL_STACK
).[C-SR-4] ZALECAMY NIE stosowanie wyłączenia integralności kontroli przepływu (CFI), ścieżki wywołań cienia (SCS) ani sterowania przepełnieniem liczb całkowitych (IntSan) w komponentach, w których są one włączone.
[C-SR-5] ZDECYDOWANIE zalecamy włączenie CFI, SCS i IntSan w przypadku wszystkich dodatkowych komponentów przestrzeni użytkownika, które są wrażliwe na zagrożenia bezpieczeństwa, zgodnie z opisem w dokumentach CFI i IntSan.
[C-SR-6] Zdecydowanie zalecamy włączenie inicjalizacji stosu w rdzeniu, aby zapobiec używaniu niezinicjowanych zmiennych lokalnych (
CONFIG_INIT_STACK_ALL
lubCONFIG_INIT_STACK_ALL_ZERO
). Ponadto implementacje na urządzeniach NIE powinny przyjmować wartości używanej przez kompilator do inicjalizacji zmiennych lokalnych.[C-SR-7] ZALECAMY WYMAGANIE inicjowania stosu w jądrze, aby zapobiec używaniu nieinicjowanych alokacji stosu (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
). Nie należy zakładać wartości używanej przez jądro do inicjowania tych alokacji.
Jeśli implementacje urządzeń korzystają z jądra Linuksa, które obsługuje SELinux, to:
- [C-1-1] NALEŻY zaimplementować SELinux.
- [C-1-2] NALEŻY ustawić SELinux na tryb globalny.
- [C-1-3] NALEŻY skonfigurować wszystkie domeny w trybie wymuszania. Niedozwolone są domeny w trybie permisywnym, w tym domeny związane z urządzeniem lub dostawcą.
- [C-1-4] Nie wolno modyfikować, pomijać ani zastępować zasad neverallow w folderze system/sepolicy udostępnianym w ramach projektu upstream Android Open Source (AOSP). Zasady muszą być zgodne ze wszystkimi zasadami neverallow zarówno w przypadku domen AOSP SELinux, jak i w przypadku domen konkretnych urządzeń lub dostawców.
- [C-1-5] NALEŻY uruchamiać aplikacje innych firm przeznaczone dla interfejsu API w wersji 28 lub nowszej w oddzielnych piaskownicach SELinux z ograniczeniami SELinux dla każdej aplikacji w przypadku katalogu prywatnych danych każdej aplikacji.
- NALEŻY zachować domyślną zasadę SELinux udostępnioną w folderze system/sepolicy w ramach projektu źródłowego Androida Open Source i tylko dodać do tej zasady dodatkowe informacje dotyczące konfiguracji konkretnego urządzenia.
Jeśli implementacje urządzeń używają jądra innego niż Linux lub Linux bez SELinux, to:
- [C-2-1] NALEŻY używać systemu obowiązkowej kontroli dostępu, który jest równoważny z SELinux.
Jeśli implementacje urządzeń korzystają z urządzeń wejścia/wyjścia obsługujących DMA, mogą:
- [C-SR-9] ZALECAMY Izolowanie każdego urządzenia we/wy, które obsługuje DMA, za pomocą IOMMU (np. ARM SMMU).
Android zawiera wiele funkcji zabezpieczeń, które są integralną częścią zabezpieczeń urządzenia. Poza tym Android koncentruje się na ograniczaniu występowania kluczowych typów częstych błędów, które wpływają na niską jakość i bezpieczeństwo.
Aby ograniczyć błędy związane z pamięcią, implementacje na urządzeniach:
- [C-SR-10] MOCNO zalecamy przetestowanie za pomocą narzędzi do wykrywania błędów pamięci w przestrzeni użytkownika, takich jak MTE w przypadku urządzeń ARMv9, HWASan w przypadku urządzeń ARMv8+ lub ASan w przypadku innych typów urządzeń.
- [C-SR-11] MOCNO zalecamy przetestowanie za pomocą narzędzi do wykrywania błędów pamięci jądra, takich jak KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS dla urządzeń ARMv9, CONFIG_KASAN_SW_TAGS dla urządzeń ARMv8 lub CONFIG_KASAN_GENERIC dla innych typów urządzeń).
- [C-SR-12] MOCNO zalecamy używanie w wersji produkcyjnej narzędzi do wykrywania błędów pamięci, takich jak MTE, GWP-ASan i KFENCE.
Jeśli implementacje urządzeń korzystają z zaufanego środowiska wykonawczego TEE opartego na Arm TrustZone, to:
- [C-SR-13] MOCNO zalecamy używanie standardowego protokołu do udostępniania pamięci między Androidem a procesorem TEE, np. Arm Firmware Framework dla Armv8-A (FF-A).
- [C-SR-14] Zdecydowanie zalecamy ograniczenie zaufanych aplikacji do dostępu tylko do pamięci, do której zostały one wyraźnie dopuszczone za pomocą wymienionego powyżej protokołu. Jeśli urządzenie obsługuje poziom wyjątków Arm S-EL2, menedżer partycji zabezpieczonej powinien go wymuszać. W przeciwnym razie powinno to być wymuszane przez system operacyjny TEE.
9,8. Prywatność
9.8.1. Historia użycia
Android przechowuje historię wyborów użytkownika i zarządza nią za pomocą UsageStatsManager.
Implementacje na urządzeniu:
- [C-0-1] NALEŻY zachować rozsądny okres przechowywania takiej historii użytkownika.
- [C-SR-1] MOCNO ZALECAMY zachowanie okresu przechowywania wynoszącego 14 dni, który jest domyślnie skonfigurowany w implementacji AOSP.
Android przechowuje zdarzenia systemowe za pomocą identyfikatorów StatsLog
i zarządza taką historią za pomocą interfejsów StatsManager
i IncidentManager
System API.
Implementacje na urządzeniu:
- [C-0-2] W raporcie o incydencie utworzonym przez klasę System API
IncidentManager
MUSZ podać tylko pola oznaczone jakoDEST_AUTOMATIC
. - [C-0-3] NIE WOLNO używać identyfikatorów zdarzeń systemowych do rejestrowania innych zdarzeń niż te opisane w dokumentach dotyczących
StatsLog
pakietu SDK. Jeśli w dzienniku znajdują się dodatkowe zdarzenia systemowe, mogą one używać innego identyfikatora atomu w zakresie od 100 000 do 200 000.
9.8.2. Nagrywam
Implementacje na urządzeniu:
- [C-0-1] NIE WOLNO wstępnie wczytywać ani rozpowszechniać komponentów oprogramowania, które wysyłają prywatne informacje użytkownika (np. naciśnięcia klawiszy, tekst wyświetlany na ekranie, raport o błędach) poza urządzenie bez zgody użytkownika lub bez wyraźnych powiadomień.
- [C-0-2] NALEŻY wyświetlić i uzyskać wyraźną zgodę użytkownika na rejestrowanie wszelkich poufnych informacji wyświetlanych na ekranie użytkownika, gdy włączone jest przesyłanie ekranu lub nagrywanie ekranu za pomocą interfejsu
MediaProjection
lub zastrzeżonego interfejsu API. NIE MOŻESZ udostępniać użytkownikom opcji umożliwiającej wyłączenie wyświetlania prośby o zgodę. - [C-0-3] Należy wyświetlać użytkownikowi ciągłe powiadomienie, gdy włączone jest przesyłanie obrazu lub nagrywanie ekranu. AOSP spełnia ten wymóg, wyświetlając na pasku stanu ikonę trwającego powiadomienia.
Jeśli implementacje na urządzeniu obejmują funkcje systemu, które rejestrują treści wyświetlane na ekranie lub strumień audio odtwarzany na urządzeniu w inny sposób niż za pomocą interfejsu API systemu ContentCaptureService
lub innych zastrzeżonych metod opisanych w sekcji 9.8.6 „Zapisywanie treści”, muszą:
- [C-1-1] NALEŻY wyświetlać użytkownikowi ciągłe powiadomienie, gdy ta funkcja jest włączona i aktywnie rejestruje/nagrywa obraz.
Jeśli implementacje urządzeń zawierają komponent włączony domyślnie, który umożliwia rejestrowanie dźwięków otoczenia lub dźwięków odtwarzanych na urządzeniu w celu wywnioskowania przydatnych informacji o kontekście użytkownika, mogą:
- [C-2-1] Nie wolno przechowywać w pamięci trwałej na urządzeniu ani przesyłać z urządzenia nagranego dźwięku w postaci surowych danych lub w dowolnym formacie, który można przekonwertować z powrotem na oryginalny dźwięk lub jego kopie, chyba że użytkownik wyrazi na to zgodę.
„Wskaźnik mikrofonu” to widok na ekranie, który jest stale widoczny dla użytkownika i nie może być zasłonięty. Użytkownicy muszą rozumieć, że mikrofon jest używany(za pomocą unikalnego tekstu, koloru, ikony lub ich kombinacji).
„Wskaźnik kamery” to widok na ekranie, który jest stale widoczny dla użytkownika i nie może być zasłonięty, co pozwala użytkownikom zrozumieć, że kamera jest używana (za pomocą unikalnego tekstu, koloru, ikony lub ich kombinacji).
Po upływie pierwszej sekundy wyświetlania wskaźnik może się wizualnie zmienić, np. stać się mniejszy, i nie musi być wyświetlany w taki sposób, w jaki został pierwotnie przedstawiony i zrozumiany.
Wskaźnik mikrofonu może być połączony z wyświetlanym aktywnie wskaźnikiem kamery, o ile tekst, ikony lub kolory wskazują użytkownikowi, że mikrofon jest w użyciu.
Wskaźnik aparatu może być połączony z wskaźnikiem mikrofonu, o ile tekst, ikony lub kolory wskazują użytkownikowi, że aparat jest w użyciu.
Jeśli implementacje na urządzeniu deklarują android.hardware.microphone
, to:
- [C-SR-1] Zdecydowanie zalecamy wyświetlanie wskaźnika mikrofonu, gdy aplikacja uzyskuje dostęp do danych audio z mikrofonu, ale nie wtedy, gdy dostęp do mikrofonu mają tylko
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
lub aplikacje, które mają role wymienione w sekcji 9.1 Uprawnienia z identyfikatorem CDD [C-3-X]. . - [C-SR-2] MOCNO ZALECAMY wyświetlanie listy ostatnich i aktywnych aplikacji korzystających z mikrofonu, zwracanej przez funkcję
PermissionManager.getIndicatorAppOpUsageData()
, wraz z wszelkimi powiązanymi z nimi komunikatami dotyczącymi atrybucji. - [C-SR-3] MOCNO ZALECAMY, aby nie ukrywać wskaźnika mikrofonu w przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub bezpośrednią interakcję z użytkownikiem.
Jeśli implementacje na urządzeniu deklarują android.hardware.camera.any
, to:
- [C-SR-4] Zdecydowanie zalecamy wyświetlanie wskaźnika kamery, gdy aplikacja uzyskuje dostęp do danych z kamery na żywo, ale nie wtedy, gdy dostęp do kamery mają tylko aplikacje o rolach wymienionych w sekcji 9.1 Uprawnienia z identyfikatorem CDD [C-3-X].
- [C-SR-5] MOCNO POLECAMY wyświetlanie ostatnich i aktywnych aplikacji za pomocą kamery z użyciem danych z funkcji
PermissionManager.getIndicatorAppOpUsageData()
, wraz z wszelkimi powiązanymi z nimi komunikatami. - [C-SR-6] W przypadku aplikacji systemowych, które mają widoczne interfejsy użytkownika lub bezpośrednią interakcję z użytkownikiem, MOCNO POLECAMY, aby nie ukrywać wskaźnika użycia aparatu.
9.8.3. Łączność
Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB, to:
- [C-1-1] NALEŻY wyświetlić interfejs z prośbą o zgodę użytkownika przed udzieleniem dostępu do zawartości wspólnego magazynu danych przez port USB.
9.8.4. Ruch w sieci
Implementacje na urządzeniu:
- [C-0-1] NALEŻY wstępnie zainstalować te same certyfikaty główne urzędu certyfikacji (CA) zaufane przez system, które zostały dostarczone w poprzedniej wersji Android Open Source Project.
- [C-0-2] Musi być dostarczany z pusta pamięcią główną urzędu certyfikacji użytkowników.
- [C-0-3] NALEŻY wyświetlić użytkownikowi ostrzeżenie, że ruch w sieci może być monitorowany, gdy dodano główny urząd certyfikacji użytkownika.
Jeśli ruch na urządzeniu jest kierowany przez VPN, implementacje urządzenia:
- [C-1-1] MUSI wyświetlać użytkownikowi ostrzeżenie, które zawiera:
- Ruch w sieci może być monitorowany.
- Ruch sieciowy jest kierowany przez konkretną aplikację VPN, która zapewnia VPN.
Jeśli implementacje urządzeń mają mechanizm, który jest domyślnie włączony, przekierowuje ruch danych sieciowych przez serwer proxy lub bramę VPN (na przykład w ramach wstępnego wczytania usługi VPN z uprawnieniem android.permission.CONTROL_VPN
), to:
- [C-2-1] NALEŻY poprosić o zgodę użytkownika przed włączeniem tego mechanizmu,
chyba że VPN jest włączony przez kontroler zasad urządzenia za pomocą interfejsu
DevicePolicyManager.setAlwaysOnVpnPackage()
, w którym to przypadku użytkownik nie musi wyrażać osobnej zgody, ale NALEŻY go o to powiadomić.
Jeśli implementacje urządzeń umożliwiają użytkownikowi przełączanie funkcji „stały VPN” w aplikacji VPN innej firmy, muszą:
- [C-3-1] W pliku
AndroidManifest.xml
NALEŻY wyłączyć tę funkcję dla aplikacji, które nie obsługują stałej usługi VPN, przez ustawienie atrybutuSERVICE_META_DATA_SUPPORTS_ALWAYS_ON
nafalse
.
9.8.5. Identyfikatory urządzeń
Implementacje na urządzeniu:
- [C-0-1] Aplikacja MUSI uniemożliwić dostęp do numeru seryjnego urządzenia oraz, w stosownych przypadkach, numeru IMEI/MEID, numeru seryjnego karty SIM i identyfikatora IMSI, chyba że spełnia on co najmniej jeden z tych wymagań:
- jest podpisaną aplikacją operatora, która została zweryfikowana przez producentów urządzeń.
- otrzymało uprawnienie
READ_PRIVILEGED_PHONE_STATE
. - ma uprawnienia operatora zdefiniowane w Uprawnieniach operatora UICC.
- jest właścicielem urządzenia lub właścicielem profilu, któremu przyznano uprawnienia
READ_PHONE_STATE
. - (Tylko w przypadku numeru seryjnego karty SIM lub identyfikatora ICCID) zgodnie z lokalnymi przepisami aplikacja musi wykrywać zmiany tożsamości abonenta.
9.8.6. Rejestrowanie treści i wyszukiwanie aplikacji
Android, za pomocą interfejsu System API ContentCaptureService
, AugmentedAutofillService
, AppSearchGlobalManager.query
lub innych zastrzeżonych metod, obsługuje mechanizm implementacji urządzeń, który umożliwia rejestrowanie tych interakcji z danymi aplikacji między aplikacjami a użytkownikiem:
- Tekst i grafika renderowane na ekranie, w tym między innymi powiadomienia i dane pomocnicze za pomocą interfejsu API
AssistStructure
. - dane multimedialne, takie jak dźwięk lub film, nagrane lub odtworzone przez urządzenie;
- zdarzenia związane z wprowadzaniem danych (np. klawiatura, mysz, gesty, głos, wideo i dostępność);
- wszelkie inne zdarzenia dostarczane przez aplikację do systemu za pomocą interfejsu
Content Capture
API lub interfejsuAppSearchManager
API, który ma podobne możliwości i jest zastrzeżonym interfejsem API na Androida. - dowolny tekst lub inne dane wysyłane przez
TextClassifier API
do System TextClassifier, czyli do usługi systemowej, aby zrozumieć znaczenie tekstu, a także generować przewidywane następne działania na podstawie tekstu; - Dane zindeksowane przez implementację platformy AppSearch, w tym m.in. tekst, grafika, dane multimedialne lub inne podobne dane.
Jeśli implementacje urządzeń rejestrują powyższe dane, mogą:
- [C-1-1] NALEŻY szyfrować wszystkie takie dane, gdy są przechowywane na urządzeniu. Szyfrowanie MOŻE zostać wykonane za pomocą szyfrowania opartego na plikach w Androidzie lub dowolnego szyfru wymienionego jako wersja interfejsu API 26 lub nowsza w pakiecie Cipher SDK.
- [C-1-2] NIE wolno tworzyć kopii zapasowych danych w postaci nieprzetworzonej lub zaszyfrowanej za pomocą metod tworzenia kopii zapasowej na Androidzie ani żadnych innych metod tworzenia kopii zapasowych.
- [C-1-3] NALEŻY wysyłać wszystkie takie dane i dziennik urządzenia tylko przy użyciu mechanizmu zapewniającego ochronę prywatności. Mechanizm ochrony prywatności definiuje się jako „taki, który umożliwia analizę tylko w ujęciu zbiorczym i uniemożliwia dopasowywanie zarejestrowanych zdarzeń lub wyników pochodnych do poszczególnych użytkowników”, aby zapobiec możliwości analizowania danych dotyczących poszczególnych użytkowników (np. za pomocą technologii prywatności różnicowej, takiej jak
RAPPOR
). - [C-1-4] NIE wolno wiązać tych danych z żadną tożsamością użytkownika (np.
Account
) na urządzeniu, chyba że użytkownik wyrazi na to wyraźną zgodę za każdym razem, gdy dane zostaną powiązane. - [C-1-5] NIE MOŻESZ udostępniać takich danych innym komponentom systemu operacyjnego, które nie spełniają wymagań opisanych w tej sekcji (9.8.6 Zbieranie treści), chyba że użytkownik wyrazi zgodę na ich udostępnienie za każdym razem.
- [C-1-6] NALEŻY umożliwić użytkownikowi usunięcie danych, które
ContentCaptureService
lub zastrzeżone metody zbierają, jeśli dane są przechowywane w dowolnej formie na urządzeniu. - [C-1-7] MUST provide a user affordance to opt-out of the data, collected via AppSearch or proprietary means from being shown in platformę Android e.g. launcher.
- [C-SR-1] Zdecydowanie zalecamy, aby nie prosić o uprawnienia INTERNET.
- [C-SR-2] MOCNO POLECAMY korzystanie z internetu tylko za pomocą ustrukturyzowanych interfejsów API opartych na publicznie dostępnych implementacjach typu open source.
Jeśli implementacje na urządzeniu obejmują usługę, która implementuje interfejs System APIContentCaptureService
, AppSearchManager.index
lub dowolną własną usługę, która rejestruje dane w sposób opisany powyżej, to:
- [C-2-1] NIE wolno zezwalać użytkownikom na zastępowanie usług aplikacją lub usługą instalowaną przez użytkownika. NALEŻY zezwolić na rejestrowanie takich danych tylko w preinstalowanych usługach.
- [C-2-2] NIE NALEŻY zezwalać żadnym aplikacjom innym niż wstępnie zainstalowane usługi na rejestrowanie takich danych.
- [C-2-3] NALEŻY umożliwić użytkownikowi wyłączenie usług.
- [C-2-4] NIE MOŻNA pominąć możliwości zarządzania uprawnieniami Androida, które są wymagane przez usługi i które są zgodne z modelem uprawnień Androida opisanym w sekcji 9.1. Uprawnienia.
[C-SR-3] ZALECAMY, aby usługi były oddzielone od innych komponentów systemu(np. nie wiązać usługi ani nie udostępniać identyfikatorów procesów), z wyjątkiem:
- Telefonia, Kontakty, UI systemu i multimedia
Android za pomocą SpeechRecognizer#onDeviceSpeechRecognizer()
umożliwia rozpoznawanie mowy na urządzeniu bez udziału sieci.
Wszelkie implementacje usługi SpeechRecognizer na urządzeniu MUSZĄ być zgodne z zasadami opisanymi w tej sekcji.
9.8.7. Dostęp do schowka
Implementacje na urządzeniu:
- [C-0-1] NIE MOŻE zwracać danych z wykadrowania ze schowka (np. przez interfejs
ClipboardManager
API), chyba że aplikacja innej firmy jest domyślną metodą wprowadzania lub jest aplikacją, która jest obecnie aktywna. - [C-0-2] NALEŻY usunąć dane z bufora nawet po 60 minutach od ich umieszczenia w buforze lub odczytu z bufora.
9.8.8. Lokalizacja
Lokalizacja obejmuje informacje z klasy Lokalizacja Androida( np. szerokość, długość geograficzna, wysokość), a także identyfikatory, które można przekształcić w lokalizację. Lokalizacja może być tak dokładna jak DGPS (Differential Global Positioning System) lub tak ogólna jak lokalizacja na poziomie kraju (np. kod kraju – MCC – Mobile Country Code).
Poniżej znajdziesz listę typów lokalizacji, które są bezpośrednio powiązane z lokalizacją użytkownika lub mogą być w nią przekształcone. Ta lista nie jest wyczerpująca, ale powinna służyć jako przykład tego, co może być powiązane z lokalizacją bezpośrednio lub pośrednio:
- GPS/GNSS/DGPS/PPP
- Globalne rozwiązanie do pozycjonowania lub globalny system nawigacji satelitarnej lub różnicowe globalne rozwiązanie do pozycjonowania
- Obejmuje to również surowe pomiary GNSS i stan GNSS.
- Dokładną lokalizację można uzyskać na podstawie surowych pomiarów GNSS
- Technologie bezprzewodowe z unikalnymi identyfikatorami, takimi 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 wieży komórkowej (3G, 4G, 5G… w tym wszystkie przyszłe technologie modemu komórkowego, które mają unikalne identyfikatory)
Jako główne źródło informacji sprawdź interfejsy API Androida, które wymagają uprawnień ACCESS_FINE_LOCATION lub ACCESS_COARSE_Location.
Implementacje na urządzeniu:
- [C-0-1] NIE WOLNO włączać ani wyłączać ustawień lokalizacji urządzenia oraz ustawień skanowania Wi-Fi/Bluetooth bez wyraźnej zgody użytkownika lub jego inicjatywy.
- [C-0-2] Musisz umożliwić użytkownikowi dostęp do informacji związanych z lokalizacją, w tym ostatnich próśb o lokalizację, uprawnień na poziomie aplikacji i skanowania Wi-Fi/Bluetooth w celu określenia lokalizacji.
- [C-0-3] NALEŻY zadbać o to, aby aplikacja korzystająca z interfejsu API do pomijania lokalizacji w przypadku sytuacji alarmowej (LocationRequest.setLocationSettingsIgnored()) była inicjowana przez użytkownika sesja alarmowa (np. wybieranie numeru 112 lub wysyłanie SMS-a pod numer 112). W przypadku pojazdów jednak pojazd MOŻE zainicjować sesję awaryjną bez aktywnej interakcji użytkownika w przypadku wykrycia wypadku (np. w celu spełnienia wymagań eCall).
- [C-0-4] NALEŻY zachować możliwość pominięcia ustawień lokalizacji urządzenia przez interfejs API Emergency Location Bypass bez zmiany tych ustawień.
- [C-0-5] NALEŻY zaplanować wysłanie powiadomienia, które przypomina użytkownikowi, że aplikacja działająca w tle uzyskała dostęp do jego lokalizacji za pomocą uprawnienia [
ACCESS_BACKGROUND_LOCATION
].
9.8.9. Zainstalowane aplikacje
Aplikacje na Androida kierowane na interfejs API na poziomie 30 lub wyższym nie mogą domyślnie wyświetlać szczegółów innych zainstalowanych aplikacji (patrz Widoczność pakietu w dokumentacji pakietu SDK Androida).
Implementacje na urządzeniu:
- [C-0-1] Aplikacja kierowana na interfejs API na poziomie 30 lub wyższym NIE MOŻE udostępniać szczegółów dotyczących żadnej innej zainstalowanej aplikacji, chyba że aplikacja może już zobaczyć szczegóły dotyczące tej innej zainstalowanej aplikacji za pomocą interfejsów API zarządzanych. Dotyczy to między innymi szczegółów udostępnianych przez niestandardowe interfejsy API dodane przez implementatora urządzenia lub dostępnych za pomocą systemu plików.
- [C-0-2] NIE NALEŻY zezwalać żadnej aplikacji na odczytywanie ani zapisywanie plików w żadnym innym katalogu aplikacji w pamięci zewnętrznej. Jedynymi wyjątkami są:
- Autorytet dostawcy pamięci zewnętrznej (np. aplikacje takie jak DocumentsUI).
- Dostawca pobierania, który używa uprawnień dostawcy „pobierania” do pobierania plików do pamięci aplikacji.
- Aplikacje korzystające z protokołu przesyłania multimediów (MTP) podpisane przez platformę, które używają uprzywilejowanego uprawnienia ACCESS_MTP do przesyłania plików na inne urządzenie.
- Aplikacje, które instalują inne aplikacje i mają uprawnienie INSTALL_PACKAGES, mogą uzyskiwać dostęp tylko do katalogów „obb” w celu zarządzania plikami rozszerzenia APK.
9.8.10. Raport o błędzie związanym z łącznością
Jeśli implementacje urządzeń deklarują flagę funkcji android.hardware.telephony
, to:
- [C-1-1] Musi obsługiwać generowanie raportów o błędach dotyczących łączności za pomocą funkcji
BUGREPORT_MODE_TELEPHONY
w klasie BugreportManager. - [C-1-2] NALEŻY uzyskać zgodę użytkownika za każdym razem, gdy funkcja
BUGREPORT_MODE_TELEPHONY
jest używana do wygenerowania raportu. Nie należy prosić użytkownika o zgodę na wszystkie przyszłe żądania aplikacji. - [C-1-3] NIE MOŻESZ zwrócić wygenerowanego raportu do aplikacji przesyłającej żądanie bez wyraźnej zgody użytkownika.
- [C-1-4] Raporty wygenerowane za pomocą
BUGREPORT_MODE_TELEPHONY
MUSZĄ zawierać co najmniej te informacje:TelephonyDebugService
zrzutTelephonyRegistry
zrzutWifiService
zrzutConnectivityService
zrzut- Dump instancji
CarrierService
pakietu wywołującego (jeśli jest powiązany) - Bufor dziennika radiowego
- [C-1-5] W wygenerowanych raportach NIE MOŻNA uwzględniać tych informacji:
- wszelkie informacje, które nie są bezpośrednio związane z debugowaniem połączeń;
- dowolne dzienniki ruchu aplikacji zainstalowanych przez użytkownika lub szczegółowe profile aplikacji/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 tożsamością użytkownika. (np. logi dostawcy).
Jeśli implementacje urządzeń zawierają dodatkowe informacje (np. dzienniki dostawcy) w raportach o błędach, a informacje te mają wpływ na prywatność, bezpieczeństwo, baterię, pamięć lub pamięć masową, należy:
- [C-SR-1] ZALECAMY, aby ustawienie programisty było domyślnie wyłączone. Implementacja referencyjna AOSP spełnia to wymaganie, ponieważ udostępnia
Enable verbose vendor logging
opcję w ustawieniach dewelopera, która umożliwia dołączanie do raportów o błędach dodatkowych danych dostawcy dotyczących konkretnego urządzenia.
9.8.11. Udostępnianie zbiorów danych
Android za pomocą interfejsu BlobStoreManager umożliwia aplikacjom udostępnianie blobów danych w systemie wybranym aplikacjom.
Jeśli implementacje urządzeń obsługują udostępniane bloki danych zgodnie z opisem w dokumentacji pakietu SDK, to:
- [C-1-1] NIE wolno udostępniać blobów danych należących do aplikacji poza zakresem dozwolonym (czyli zakres dostępu domyślnego i innych trybów dostępu, które można określić za pomocą metod BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() lub BlobStoreManager.session#allowPublicAccess(). Nie wolno ich modyfikować). Implementacja referencyjna AOSP spełnia te wymagania.
- [C-1-2] NIE MOŻESZ wysyłać z urządzenia ani udostępniać innym aplikacjom bezpiecznych haszy blobów danych (które są używane do kontrolowania dostępu).
9.8.12. Rozpoznawanie muzyki
Android, za pomocą interfejsu System API MusicRecognitionManager, obsługuje mechanizm umożliwiający implementacje urządzeń do żądania rozpoznawania muzyki na podstawie nagrania audio i przekazywania rozpoznawania muzyki do aplikacji uprzywilejowanej implementującej interfejs MusicRecognitionService API.
Jeśli implementacje na urządzeniu obejmują usługę, która implementuje interfejs API systemu MusicRecognitionManager, lub dowolną zastrzeżoną usługę przesyłającą strumieniowo dane audio zgodnie z opisem powyżej, to:
- [C-1-1] NALEŻY wymagać, aby wywołujący MusicRecognitionManager miał uprawnienia
MANAGE_MUSIC_RECOGNITION
- [C-1-2] NALEŻY wymagać, aby jedna wstępnie zainstalowana aplikacja do rozpoznawania muzyki implementowała interfejs MusicRecognitionService.
- [C-1-3] Nie zezwalaj użytkownikom na zastępowanie usługi MusicRecognitionManagerService lub MusicRecognitionService aplikacją lub usługą instalowaną przez użytkownika.
- [C-1-4] NALEŻY zadbać o to, aby gdy MusicRecognitionManagerService uzyskuje dostęp do rekordu audio i przesyła go do aplikacji implementującej MusicRecognitionService, dostęp do dźwięku był śledzony za pomocą wywołań AppOpsManager.noteOp / startOp.
Jeśli implementacje MusicRecognitionManagerService lub MusicRecognitionService na urządzeniu przechowują jakiekolwiek dane audio, to:
- [C-2-1] Nie wolno przechowywać na dysku ani w pamięci żadnych nieprzetworzonych plików audio ani odcisków audio dłużej niż 14 dni.
- [C-2-2] NIE MOŻESZ udostępniać tych danych poza MusicRecognitionService, chyba że użytkownik wyrazi na to wyraźną zgodę za każdym razem.
9.8.13. SensorPrivacyManager
Jeśli implementacje urządzeń zapewniają użytkownikowi oprogramowanie umożliwiające wyłączenie wejścia z kamery lub mikrofonu, muszą:
- [C-1-1] MUSI zwracać wartość „true” w przypadku odpowiedniej metody interfejsu API supportsSensorToggle().
- [C-1-2] Gdy aplikacja próbuje uzyskać dostęp do zablokowanego mikrofonu lub aparatu, MUSI wyświetlić użytkownikowi nieusuwalny element interfejsu, który wyraźnie wskazuje, że czujnik jest zablokowany, oraz wymaga podjęcia decyzji o dalszym blokowaniu lub odblokowaniu zgodnie z implementacją AOSP, która spełnia ten wymóg.
- [C-1-3] Do aplikacji muszą być przekazywane tylko puste (lub fałszywe) dane z kamery i dźwięku. Nie wolno zgłaszać kodu błędu z powodu braku włączenia przez użytkownika kamery ani mikrofonu za pomocą interfejsu użytkownika przedstawionego w sekcji [C-1-2] powyżej.
9.9. Szyfrowanie danych przechowywanych
Wszystkie urządzenia MUSZĄ spełniać wymagania podane w sekcji 9.9.1. Urządzenia, które zostały uruchomione na poziomie interfejsu API wcześniejszym niż w tym dokumencie, są zwolnione z wymagań zawartych w sekcjach 9.9.2 i 9.9.3. Zamiast tego MUSZĄ spełniać wymagania podane w sekcji 9.9 dokumentu Definicja zgodności Androida odpowiadającej poziomowi interfejsu API, na którym urządzenie zostało uruchomione.
9.9.1. Bezpośredni rozruch
Implementacje na urządzeniu:
[C-0-1] NALEŻY zaimplementować interfejsy API Tryb bezpośredniego uruchamiania, nawet jeśli nie obsługują szyfrowania pamięci masowej.
[C-0-2] Intencje
ACTION_LOCKED_BOOT_COMPLETED
iACTION_USER_UNLOCKED
MUSZĄ być nadal nadawane, aby sygnalizować aplikacjom obsługującym bezpośrednie uruchamianie, że dostępne są szyfrowane miejsca na dane urządzenia (DE) i szyfrowane miejsca na dane poświadczeń (CE).
9.9.2. Wymagania dotyczące szyfrowania
Implementacje na urządzeniu:
- [C-0-1] Musisz zaszyfrować prywatne dane aplikacji (partycja
/data
) oraz partycję współdzielonego miejsca na dane aplikacji (partycja/sdcard
), jeśli jest to stała, nieusuwalna część urządzenia. - [C-0-2] Domyślnie musisz włączyć szyfrowanie danych w momencie, gdy użytkownik zakończy konfigurację urządzenia.
[C-0-3] NALEŻY spełniać powyższy wymóg szyfrowania danych, stosując jedną z tych 2 metod szyfrowania:
- Szyfrowanie oparte na plikach (FBE) i szyfrowanie metadanych zgodnie z opisem w sekcji 9.9.3.1.
- szyfrowanie na poziomie bloku dla poszczególnych użytkowników, jak opisano w sekcji 9.9.3.2;
9.9.3. Metody szyfrowania
Jeśli implementacje urządzeń są zaszyfrowane, to:
- [C-1-1] Musi uruchamiać się bez pytania użytkownika o dane logowania i umożliwiać aplikacjom obsługującym bezpośrednie uruchamianie dostęp do zaszyfrowanej pamięci urządzenia (DE) po przesłaniu wiadomości
ACTION_LOCKED_BOOT_COMPLETED
. - [C-1-2] NALEŻY zezwalać na dostęp do zaszyfrowanej pamięci z danymi logowania (CE) dopiero po odblokowaniu urządzenia przez użytkownika za pomocą danych logowania (np. kodu dostępu, kodu PIN, wzoru lub odcisku palca) i wysłaniu wiadomości
ACTION_USER_UNLOCKED
. - [C-1-13] NIE MOŻESZ oferować żadnej metody odblokowania chronionego magazynu CE bez podania danych logowania użytkownika, zarejestrowanego klucza powiernikowego lub wznowienia po restarcie, które spełnia wymagania podane w sekcji 9.9.4.
- [C-1-4] NALEŻY 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, to:
- [C-1-5] NALEŻY zaszyfrować zawartość plików i metadane systemu plików za pomocą AES-256-XTS lub Adiantum. AES-256-XTS odnosi się do standardu Advanced Encryption Standard z 256-bitowym kluczem szyfrowania, który działa w trybie XTS; pełna długość klucza to 512 bitów. Adiantum oznacza Adiantum-XChaCha12-AES, jak określono na stronie https://github.com/google/adiantum. Metadane systemu plików to dane takie jak rozmiary plików, własność, tryby i rozszerzone atrybuty (xattr).
- [C-1-6] NALEŻY szyfrować nazwy plików za pomocą AES-256-CBC-CTS lub Adiantum.
- [C-1-12] Jeśli urządzenie obsługuje instrukcje Advanced Encryption Standard (AES) (np. rozszerzenia szyfrowania ARMv8 na urządzeniach z procesorami ARMv8 lub AES-NI na urządzeniach z procesorami x86), NALEŻY użyć opcji szyfrowania nazwy pliku, zawartości pliku i metadanych systemu plików opartych na AES, a nie Adiantum.
- [C-1-13] NALEŻY użyć silnej kryptograficznie i nieodwracalnej funkcji derywacji klucza (np. HKDF-SHA512) do wyprowadzenia potrzebnych kluczy podrzędnych (np. kluczy na poziomie pliku) z kluczy CE i DE. „Silne pod względem kryptograficznym i nieodwracalne” oznacza, że funkcja derywacji klucza ma moc bezpieczeństwa co najmniej 256 bitów i działa jak rodzina funkcji pseudolosowych na swoich danych wejściowych.
- [C-1-14] NIE wolno używać tych samych kluczy szyfrowania opartego na plikach (FBE) lub podkluczy do różnych celów kryptograficznych (np. do szyfrowania i wyprowadzania kluczy lub do dwóch różnych algorytmów szyfrowania).
- [C-1-15] NALEŻY zadbać o to, aby wszystkie nieusunięte bloki zaszyfrowanej zawartości pliku w trwałym miejscu przechowywania były zaszyfrowane za pomocą kombinacji klucza szyfrowania i wektora inicjalizacji (IV), które zależą zarówno od pliku, jak i od przesunięcia w pliku. Ponadto wszystkie takie kombinacje MUSZĄ być różne, z wyjątkiem sytuacji, gdy szyfrowanie jest wykonywane za pomocą sprzętowego szyfrowania w internecie, które obsługuje tylko długość IV wynoszącą 32 bity.
- [C-1-16] NALEŻY zadbać o to, aby wszystkie nieusunięte zaszyfrowane nazwy plików w trwałym magazynie w oddzielnych katalogach zostały zaszyfrowane przy użyciu różnych kombinacji klucza szyfrującego i wektora inicjującego (IV).
[C-1-17] NALEŻY zadbać o to, aby wszystkie zaszyfrowane bloki metadanych systemu plików w trwałym magazynie były szyfrowane za pomocą różnych kombinacji klucza szyfrowania i wektora inicjalizacji (IV).
Klucze chroniące obszary pamięci CE i DE oraz metadane systemu plików:
- [C-1-7] MUSI być powiązany z kluczem sprzętowym za pomocą mechanizmu szyfrowania. Ten magazyn kluczy MUSI być powiązany z weryfikacją podczas uruchamiania i sprzętowym katalogiem zaufania urządzenia.
- [C-1-8] Klucze CE MUSZĄ być powiązane z danymi uwierzytelniania na ekranie blokady użytkownika.
- [C-1-9] Klucze CE MUSZĄ być powiązane z domyślnym kodem dostępu, gdy użytkownik ma nieokreślone dane logowania do ekranu blokady.
- [C-1-10] Musi być unikalny i różni się od kluczy CE lub DE innych użytkowników.
- [C-1-11] NALEŻY używać szyfrów, długości kluczy i trybów obsługiwanych obligatoryjnie.
- [C-1-12] NALEŻY je bezpiecznie usunąć podczas odblokowywania i blokowania programu rozruchowego w sposób opisany tutaj.
NALEŻY zadbać o to, aby wbudowane niezbędne aplikacje (np. Alarm, Telefon, Messenger) były świadome bezpośredniego uruchamiania.
Górny projekt Android Open Source udostępnia preferowaną implementację szyfrowania opartego na plikach na podstawie funkcji szyfrowania „fscrypt” jądra Linuksa oraz szyfrowania metadanych na podstawie funkcji „dm-default-key” jądra Linuksa.
9.9.3.2. Szyfrowanie na poziomie bloku dla poszczególnych użytkowników
Jeśli implementacje urządzeń korzystają z szyfrowania na poziomie bloku dla poszczególnych użytkowników, to:
- [C-1-1] NALEŻY włączyć obsługę wielu użytkowników zgodnie z opisem w sekcji 9.5.
- [C-1-2] MUSI zawierać partycje dla poszczególnych użytkowników, używając partycji nieprzetworzonych lub woluminów logicznych.
- [C-1-3] NALEŻY używać unikalnych i różnych kluczy szyfrowania na potrzeby szyfrowania poszczególnych użytkowników na urządzeniach blokowych.
[C-1-4] NALEŻY użyć AES-256-XTS do szyfrowania partycji użytkownika na poziomie bloku.
Klucze chroniące urządzenia z szyfrowaniem na poziomie bloku dla poszczególnych użytkowników:
- [C-1-5] MUSI być powiązany z kluczem sprzętowym. Ten magazyn kluczy MUSI być powiązany z weryfikacją podczas uruchamiania i sprzętowym katalogiem zaufania urządzenia.
- [C-1-6] MUSI być powiązany z danymi logowania na ekranie blokady odpowiedniego użytkownika.
Szyfrowanie na poziomie bloku dla poszczególnych użytkowników można zaimplementować za pomocą funkcji jądra Linuksa „dm-crypt” w przypadku partycji dla poszczególnych użytkowników.
9.9.4. Wznów po ponownym uruchomieniu
Funkcja wznawiania po restarcie umożliwia odblokowanie pamięci CE wszystkich aplikacji, w tym tych, które nie obsługują jeszcze bezpośredniego uruchamiania, po restarcie zainicjowanym przez OTA. Ta funkcja umożliwia użytkownikom otrzymywanie powiadomień z zainstalowanych aplikacji po ponownym uruchomieniu urządzenia.
Wdrożenie funkcji wznawiania po ponownym uruchomieniu musi nadal zapewniać, że gdy urządzenie wpadnie w ręce atakującego, będzie on miał ogromne trudności z odzyskaniem zaszyfrowanych danych użytkownika, nawet jeśli urządzenie jest włączone, pamięć CE jest odblokowana, a użytkownik odblokował urządzenie po otrzymaniu aktualizacji OTA. W przypadku odporności na ataki z zewnątrz zakładamy też, że atakujący uzyska dostęp do kluczy kryptograficznych do podpisywania transmisji.
Więcej szczegółów:
[C-0-1] Pamięć CE NIE MOŻE być czytelna nawet dla osoby przeprowadzającej atak, która ma fizyczny dostęp do urządzenia. W efekcie ma ona te możliwości i ograniczenia:
- Może używać klucza podpisywania dowolnego dostawcy lub firmy do podpisywania dowolnych wiadomości.
- Może spowodować, że urządzenie otrzyma aktualizację OTA.
- Może modyfikować działanie dowolnego sprzętu (AP, flash itp.) z wyjątkiem opisanych poniżej przypadków, ale taka modyfikacja wymaga opóźnienia o co najmniej godzinę i cyklu zasilania, który powoduje utratę zawartości pamięci RAM.
- Nie można modyfikować działania sprzętu chronionego przed ingerencją (np. Titan M).
- Nie można odczytać pamięci RAM urządzenia na żywo.
- Nie można uzyskać danych logowania użytkownika (kodu PIN, wzoru lub hasła) ani w inny sposób spowodować ich wpisania.
Na przykład implementacja urządzenia, która implementuje i przestrzega wszystkich opisów podanych tutaj, będzie zgodna z [C-0-1].
9.10. Integralność urządzenia
Wymagania te zapewniają przejrzystość stanu integralności urządzenia. Implementacje na urządzeniu:
[C-0-1] MUST correctly report through the System API method
PersistentDataBlockManager.getFlashLockState()
whether their bootloader state permits flashing of the system image.[C-0-2] Musi obsługiwać Verified Boot w celu zapewnienia integralności urządzenia.
Jeśli implementacje urządzeń zostały już uruchomione bez obsługi Verified Boot w wersji Androida wcześniejszej niż 9.0, a nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, mogą być zwolnione z tego wymagania.
Weryfikacja podczas uruchamiania to funkcja, która gwarantuje integralność oprogramowania urządzenia. Jeśli implementacje urządzeń obsługują tę funkcję, to:
- [C-1-1] NALEŻY zadeklarować flagę funkcji platformy
android.software.verified_boot
. - [C-1-2] NALEŻY przeprowadzić weryfikację w ramach każdej sekwencji uruchamiania.
- [C-1-3] Należy rozpocząć weryfikację od niezmiennego klucza sprzętowego, który jest zaufanym źródłem, i przeprowadzić ją aż do partycji systemowej.
- [C-1-4] NALEŻY wdrożyć każdy etap weryfikacji, aby sprawdzić integralność i autentyczność wszystkich bajtów na następnym etapie przed wykonaniem kodu na tym etapie.
- [C-1-5] NALEŻY używać algorytmów weryfikacji o tak silnym poziomie bezpieczeństwa, jak to wynika z aktualnych zaleceń NIST dotyczących algorytmów szyfrowania (SHA-256) i rozmiarów kluczy publicznych (RSA-2048).
- [C-1-6] NIE wolno dopuścić do uruchomienia, gdy weryfikacja systemu się nie powiedzie, chyba że użytkownik wyrazi zgodę na próbę uruchomienia, w którym przypadku nie wolno używać danych z niezatwierdzonych bloków pamięci.
- [C-1-7] NIE wolno zezwalać na modyfikowanie zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokował bootloader.
- [C-SR-1] Jeśli na urządzeniu jest kilka oddzielnych układów (np. radio, wyspecjalizowany procesor obrazu), MOCNO POLECAMY sprawdzenie każdego etapu podczas uruchamiania.
- [C-1-8] NALEŻY UŻYWAĆ miejsca na dane z funkcją ochrony przed modyfikacją: do przechowywania informacji o tym, czy bootloader jest odblokowany. Pamięć z funkcją wykrywania manipulacji oznacza, że bootloader może wykryć, czy pamięć została naruszona z poziomu Androida.
- [C-1-9] NALEŻY wyświetlić użytkownikowi odpowiedni komunikat podczas korzystania z urządzenia i wymagać fizycznego potwierdzenia przed przejściem z trybu zablokowanego programu rozruchowego do trybu odblokowanego programu rozruchowego.
- [C-1-10] NALEŻY wdrożyć ochronę przed cofnięciem zmian w przypadku partycji używanych przez Androida (np. partycji rozruchu, partycji systemowych) oraz używać magazynu z funkcją wykrywania próby manipulacji do przechowywania metadanych służących do określania minimalnej dozwolonej wersji systemu operacyjnego.
- [C-1-11] NALEŻY bezpiecznie usunąć wszystkie dane użytkownika podczas odblokowywania i blokowania programu rozruchowego zgodnie z sekcją 9.12. „Usuwanie danych” (w tym partycji userdata i dowolnych obszarach NVRAM).
- [C-SR-2] MOCNO ZALECAMY weryfikowanie wszystkich plików APK aplikacji z dostępem uprzywilejowanym za pomocą łańcucha zaufania z korzeniami w partycjach chronionych przez weryfikowany rozruch.
- [C-SR-3] MOCNO ZALECAMY weryfikowanie wszystkich artefaktów wykonywalnych załadowanych przez aplikację uprzywilejowaną spoza pliku APK (np. kodu skompilowanego lub kodu wczytywanego dynamicznie) przed ich wykonaniem lub MOCNO ZALECAMY, aby w ogóle ich nie wykonywać.
- NALEŻY wdrożyć ochronę przed przywracaniem w przypadku każdego komponentu z trwałym oprogramowaniem układowym (np. modemu lub kamery) oraz NALEŻY użyć pamięci z funkcją ochrony przed nieuprawnionym dostępem do przechowywania metadanych używanych do określania minimalnej dozwolonej wersji.
Jeśli implementacje urządzeń zostały już uruchomione bez obsługi wymagań C-1-8 do C-1-11 w starszej wersji Androida i nie można dodać obsługi tych wymagań za pomocą aktualizacji oprogramowania systemowego, mogą być zwolnione z tych wymagań.
Projekt Android Open Source udostępnia preferowaną implementację tej funkcji w repozytorium external/avb/
, która może być zintegrowana z bootloaderem używanym do ładowania Androida.
Implementacje na urządzeniu:
- [C-0-3] MUSI obsługiwać weryfikację treści pliku za pomocą szyfrowania przy użyciu zaufanych kluczy bez odczytywania całego pliku.
- [C-0-4] NIE NALEŻY zezwalać na odczytywanie żądań dotyczących chronionego pliku, gdy odczytywane treści nie są weryfikowane za pomocą zaufanego klucza.
Jeśli implementacje urządzeń zostały już wdrożone bez możliwości weryfikacji treści pliku za pomocą zaufanych kluczy w starszej wersji Androida i nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, mogą być zwolnione z tego wymogu. Wspólny projekt Android Open Source udostępnia preferowane wdrożenie tej funkcji na podstawie funkcji fs-verity jądra Linuksa.
Implementacje na urządzeniu:
- [C-SR-4] MOCNO zalecamy obsługę interfejsu Android Protected Confirmation API.
Jeśli implementacje na urządzeniach obsługują interfejs API Protected Confirmation na Androida, to:
[C-3-1] MUST report
true
for theConfirmationPrompt.isSupported()
API.[C-3-2] NALEŻY zadbać o to, aby kod działający w systemie operacyjnym Android, w tym jego jądro, złośliwe lub inne, nie mógł wygenerować pozytywnej odpowiedzi bez interakcji użytkownika.
[C-3-3] NALEŻY zadbać o to, aby użytkownik mógł przejrzeć i zatwierdzić wyświetlaną wiadomość nawet wtedy, gdy system operacyjny Android (w tym jego jądro) został naruszony.
9.11. Klucze i dane logowania
System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i używanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub Keystore API. Implementacje na urządzeniu:
- [C-0-1] MUSI umożliwiać importowanie lub generowanie co najmniej 8192 kluczy.
- [C-0-2] Uwierzytelnianie na ekranie blokady MUSI implementować interwał czasowy między nieudanymi próbami. Jeśli n to liczba nieudanych prób, odstęp czasowy MUSI wynosić co najmniej 30 sekund, gdy 9 < n < 30. W przypadku wartości n > 29 wartość przedziału czasowego MUSI wynosić co najmniej 30*2^floor((n-30)/10)) sekund lub co najmniej 24 godziny, zależnie od tego, która z tych wartości jest mniejsza.
- NIE należy ograniczać liczby kluczy, które mogą być generowane
Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady, urządzenie:
- [C-1-1] NALEŻY utworzyć kopię zapasową implementacji magazynu kluczy w odizolowanym środowisku wykonawczym.
- [C-1-2] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA, ECDH (jeśli jest obsługiwane urządzenie IKeyMintDevice), 3DES oraz HMAC, a także funkcje haszowania MD5, SHA1 i SHA-2, aby prawidłowo obsługiwać obsługiwane przez system Keystore Androida algorytmy w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i powyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt źródłowy Android Open Source (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest też inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odizolowania na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
- [C-1-3] NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonywania i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem tylko wtedy, gdy uwierzytelnianie się powiedzie. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania ekranu blokady tylko w odizolowanym środowisku wykonania. Projekt Android Open Source udostępnia interfejs HAL (Gatekeeper Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.
- [C-1-4] MUSI obsługiwać atesta klucza, w którym klucz podpisujący jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania certyfikatów MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻNA użyć innego klucza.
Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi ona spełniać wymagań dotyczących posiadania magazynu kluczy obsługiwanego przez odizolowane środowisko wykonywania i obsługiwania uwierzytelniania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint
, która wymaga magazynu kluczy obsługiwanego przez odizolowane środowisko wykonywania.
- [C-1-5] NALEŻY umożliwić użytkownikowi wybranie czasu bezczynności w trybie uśpienia podczas przechodzenia z otwartego stanu na zamknięty, z minimalnym dozwolonym czasem do 15 sekund. Urządzenia samochodowe, które blokują ekran, gdy wyłącza się jednostka główna lub gdy użytkownik zmieni się, MOGĄ NIE mieć konfiguracji uśpienia.
- [C-1-6] Musi obsługiwać jedną z tych opcji:
- IKeymasterDevice 3.0,
- IKeymasterDevice 4.0,
- IKeymasterDevice 4.1,
- IKeyMintDevice w wersji 1 lub
- IKeyMintDevice w wersji 2.
- [C-SR-1] ZDECYDOWANIE POLECAMY obsługę urządzenia IKeyMint w wersji 1.
9.11.1. Bezpieczna blokada ekranu, uwierzytelnianie i urządzenia wirtualne
Implementacja AOSP opiera się na modelach uwierzytelniania wielopoziomowego, w których uwierzytelnianie podstawowe oparte na fabryce wiedzy może być wspierane przez drugorzędne silne dane biometryczne lub słabsze metody uwierzytelniania na poziomie trzecim.
Implementacje na urządzeniu:
- [C-SR-1] MOCNO ZALECAMY skonfigurowanie jako podstawowej metody uwierzytelniania tylko jednej z tych opcji:
- numeryczny kod PIN;
- hasło alfanumeryczne
- Wzór przesunięcia na siatce dokładnie 3 x 3 kropek
Pamiętaj, że w tym dokumencie powyższe metody uwierzytelniania są określane jako zalecane podstawowe metody uwierzytelniania.
Jeśli implementacje urządzeń dodają lub modyfikują zalecane podstawowe metody uwierzytelniania i używają nowej metody uwierzytelniania jako bezpiecznego sposobu blokowania ekranu, nowa metoda uwierzytelniania:
- [C-2-1] MUSI to być metoda uwierzytelniania użytkownika opisana w sekcji Wymaganie uwierzytelniania użytkownika w przypadku korzystania z klucza.
Jeśli implementacje na urządzeniach dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, oparte na znanym kluczu tajnym i używają nowej metody uwierzytelniania, która ma być traktowana jako bezpieczny sposób blokowania ekranu:
- [C-3-1] Entropia najkrótszych dozwolonych danych wejściowych MUSI być większa niż 10 bitów.
- [C-3-2] Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18 bitów.
- [C-3-3] Nowa metoda uwierzytelniania NIE MOŻE zastąpić żadnej z zalecanych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) zaimplementowanych i dostępnych w AOSP.
- [C-3-4] Nowa metoda uwierzytelniania MUSI zostać wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawia zasady dotyczące haseł za pomocą metody DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjną stałą złożoności niż PASSWORD_COMPLEXITY_NONE lub za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
- [C-3-5] Nowe metody uwierzytelniania MUSZĄ co 72 godziny lub rzadziej stosować zalecane podstawowe metody uwierzytelniania (np. kod PIN, wzór lub hasło) LUB wyraźnie informować użytkownika, że niektóre dane nie będą szyfrowane, aby zachować prywatność jego danych.
Jeśli implementacje urządzeń dodają lub modyfikują zalecane metody uwierzytelniania, aby odblokować ekran blokady i użyć nowej metody uwierzytelniania opartej na danych biometrycznych, która ma być traktowana jako bezpieczny sposób blokowania ekranu, nowa metoda:
- [C-4-1] MUSI spełniać wszystkie wymagania opisane w sekcji 7.3.10 dotyczącej klasy 1 (dawniej wygoda).
- [C-4-2] MUSI zawierać mechanizm zapasowy umożliwiający korzystanie z jednej z zalecanych metod uwierzytelniania podstawowego opartego na znanym kluczu tajnym.
- [C-4-3] NALEŻY wyłączyć i zezwolić tylko na zalecane uwierzytelnianie podstawowe, aby odblokować ekran, gdy aplikacja Device Policy Controller (DPC) ustawiła zasady funkcji klucza za pomocą wywołania metody
DevicePolicyManager.setKeyguardDisabledFeatures()
z dowolnym z powiązanych flag biometrycznych (np.KEYGUARD_DISABLE_BIOMETRICS
,KEYGUARD_DISABLE_FINGERPRINT
,KEYGUARD_DISABLE_FACE
lubKEYGUARD_DISABLE_IRIS
).
Jeśli metody uwierzytelniania biometrycznego nie spełniają wymagań klasy 3 (dawniej silnego), opisanych w sekcji 7.3.10:
- [C-5-1] Metody MUSZĄ być wyłączone, jeśli aplikacja kontrolera zasad urządzenia (DPC) ma ustawioną politykę jakości haseł za pomocą metody DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjnym zasobnikiem złożoności niż
PASSWORD_COMPLEXITY_LOW
lub za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niżPASSWORD_QUALITY_BIOMETRIC_WEAK
. - [C-5-2] Należy poprosić użytkownika o podanie danych do logowania (np. kodu PIN, wzoru lub hasła) w ramach zalecanego głównego uwierzytelniania, jak opisano w [C-1-7] i [C-1-8] w sekcji 7.3.10.
- [C-5-3] Metody NIE mogą być traktowane jako bezpieczny ekran blokady i MUSZĄ spełniać wymagania opisane w tej sekcji (od C-8).
Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, a nowa metoda uwierzytelniania opiera się na fizycznym tokenie lub lokalizacji:
- [C-6-1] Musi być dostępny mechanizm zapasowy, który umożliwia korzystanie z jednej z zalecanych metod uwierzytelniania podstawowego opartej na znanym kluczu tajnym i spełniającej wymagania dotyczące ekranu blokady.
- [C-6-2] Nowa metoda MUSI być wyłączona i zezwalać tylko na jedną z zalecanych metod uwierzytelniania, aby odblokować ekran, gdy aplikacja Device Policy Controller (DPC) skonfigurowała zasadę za pomocą:
- Metoda
DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
- Metoda
DevicePolicyManager.setPasswordQuality()
z bardziej restrykcyjną stałą jakości niżPASSWORD_QUALITY_NONE
. - Metoda
DevicePolicyManager.setRequiredPasswordComplexity()
, która ma bardziej restrykcyjny zakres złożoności niżPASSWORD_COMPLEXITY_NONE
.
- Metoda
- [C-6-3] Użytkownik MUSI zostać poproszony o odpowiednie działanie w ramach jednej z zalecanych podstawowych metod uwierzytelniania (np. kod PIN, wzór, hasło) co najmniej raz na 4 godziny. Jeśli token fizyczny spełnia wymagania dotyczące implementacji TrustAgent w C-X, zamiast tego mają zastosowanie ograniczenia czasu oczekiwania zdefiniowane w C-9-5.
- [C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI spełniać ograniczenia wymienione w sekcji C-8.
Jeśli implementacje urządzeń mają zabezpieczony ekran blokady i zawierają co najmniej 1 usługę zaufania, która implementuje interfejs API systemu TrustAgentService
, to:
- [C-7-1] W menu ustawień i na ekranie blokady musi być wyraźnie wskazane, kiedy blokada urządzenia jest odroczona lub może zostać odblokowana przez zaufanego agenta. Na przykład AOSP spełnia ten wymóg, wyświetlając w menu ustawień opis opcji „Automatyczne blokowanie” i „Przycisk zasilania natychmiast blokuje” oraz wyróżniającą się ikonę na ekranie blokady.
- [C-7-2] MUSISZ przestrzegać i w pełni wdrażać wszystkie interfejsy API zaufanego agenta w klasie
DevicePolicyManager
, takie jak stałaKEYGUARD_DISABLE_TRUST_AGENTS
. - [C-7-3] NIE WOLNO w pełni wdrażać funkcji
TrustAgentService.addEscrowToken()
na urządzeniu używanym jako podstawowe urządzenie osobiste (np. urządzenie przenośne), ale można w pełni wdrażać tę funkcję na urządzeniach, które są zwykle współużytkowane (np. Android TV lub urządzenie samochodowe). - [C-7-4] NALEŻY zaszyfrować wszystkie zapisane tokeny dodane przez
TrustAgentService.addEscrowToken()
. - [C-7-5] Nie przechowuj klucza szyfrowania ani tokena powiernikowego na tym samym urządzeniu, na którym używany jest klucz. Na przykład klucz przechowywany na telefonie może służyć do odblokowania konta użytkownika na telewizorze. W przypadku urządzeń Automotive nie można przechowywać tokena escrow w żadnej części pojazdu.
- [C-7-6] NALEŻY poinformować użytkownika o konsekwencjach włączenia tokena powiernikowego do odszyfrowywania danych.
- [C-7-7] MUSI zawierać mechanizm zapasowy umożliwiający korzystanie z jednej z zalecanych metod uwierzytelniania podstawowego.
- [C-7-8] Użytkownik MUSI zostać poproszony o podanie danych uwierzytelniających przy użyciu jednej z zalecanych metod uwierzytelniania (np.kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny, chyba że chodzi o bezpieczeństwo użytkownika (np. rozproszenie uwagi kierowcy).
- [C-7-9] Użytkownik MUSI zostać poproszony o podanie danych uwierzytelniających za pomocą jednej z zalecanych metod uwierzytelniania (np.kodu PIN, wzoru lub hasła) opisanych w punktach [C-1-7] i [C-1-8] w sekcji 7.3.10, chyba że chodzi o bezpieczeństwo użytkownika (np. rozproszenie uwagi kierowcy).
- [C-7-10] NIE MOŻE być traktowany jako bezpieczny ekran blokady i MUSI spełniać ograniczenia wymienione w sekcji C-8 poniżej.
- [C-7-11] NIE NALEŻY zezwalać zaufanym agentom na głównych urządzeniach osobistych (np. na urządzeniach przenośnych) na odblokowywanie urządzenia. Można ich używać tylko do utrzymywania już odblokowanego urządzenia w stanie odblokowanym przez maksymalnie 4 godziny. Domyślna implementacja usługi TrustManagerService w AOSP spełnia to wymaganie.
- [C-7-12] NALEŻY używać szyfrowanego kanału komunikacji (np.UKEY2) do przekazywania tokena powiernikowego z urządzenia do przechowywania na urządzenie docelowe.
Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, który nie jest ekranem blokady zabezpieczonej zgodnie z opisem powyżej, i używają nowej metody uwierzytelniania do odblokowania ekranu blokady klawiatury:
- [C-8-1] Nowa metoda MUSI być wyłączona, gdy aplikacja Device Policy Controller (DPC) ustawiła zasady jakości hasła za pomocą metody
DevicePolicyManager.setPasswordQuality()
z bardziej restrykcyjną stałą jakości niżPASSWORD_QUALITY_NONE
lub za pomocą metodyDevicePolicyManager.setRequiredPasswordComplexity()
z bardziej restrykcyjną stałą złożoności niż „PASSWORD_COMPLEXITY_NONE”. - [C-8-2] Nie wolno resetować ustawionych przez
DevicePolicyManager.setPasswordExpirationTimeout()
timerów wygasania haseł. - [C-8-3] Nie wolno udostępniać interfejsu API aplikacjom innych firm do zmiany stanu blokady.
Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych ekranów wirtualnych i nie obsługują powiązanych zdarzeń wejściowych, takich jak VirtualDeviceManager
, to:
- [C-9-1] NALEŻY zablokować te dodatkowe wirtualne wyświetlacze, gdy ekran domyślny urządzenia jest zablokowany, oraz odblokować te dodatkowe wirtualne wyświetlacze, gdy ekran domyślny urządzenia jest odblokowany.
Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych wirtualnych wyświetlaczy i obsługują powiązane zdarzenia wejściowe, na przykład za pomocą interfejsu VirtualDeviceManager, to:
- [C-10-1] Musi obsługiwać oddzielne stany blokady na każde urządzenie wirtualne
- [C-10-2] MUST disconnect all virtual devices upon idle timeout
- [C-10-3] Musisz mieć określony limit czasu nieaktywności
- [C-10-4] NALEŻY zablokować wszystkie wyświetlacze, gdy użytkownik zainicjuje tryb blokady, w tym za pomocą interfejsu użytkownika wymaganego w przypadku urządzeń przenośnych (patrz sekcja 2.2.5[9.11/H-1-2]).
- [C-10-5] Musisz mieć osobne instancje wirtualnego urządzenia dla każdego użytkownika
- [C-10-6] NALEŻY wyłączyć tworzenie powiązanych zdarzeń wejściowych za pomocą interfejsu
VirtualDeviceManager
, gdyDevicePolicyManager.setNearbyAppStreamingPolicy
tak wskaże - [C-10-7] NALEŻY używać oddzielnego schowka tylko dla każdego urządzenia wirtualnego (lub wyłączyć schowek dla urządzeń wirtualnych)
- [C-10-11] NALEŻY wyłączyć interfejs uwierzytelniania na urządzeniach wirtualnych, w tym pole hasła i prośbę o dane biometryczne
- [C-10-12] NALEŻY ograniczyć intencje inicjowane z urządzenia wirtualnego do wyświetlania tylko na tym samym urządzeniu wirtualnym
- [C-10-13] Nie wolno używać stanu blokady wirtualnego urządzenia jako autoryzacji użytkownika w systemie Keystore Androida. Zobacz
KeyGenParameterSpec.Builder.setUserAuthentication*
.
Gdy implementacje urządzeń umożliwiają użytkownikowi przeniesienie głównego czynnika uwierzytelniania (czynnika wiedzy) z urządzenia źródłowego na urządzenie docelowe, na przykład w ramach początkowej konfiguracji urządzenia docelowego, muszą:
- [C-11-1] Podczas przenoszenia czynnika wiedzy z urządzenia źródłowego na urządzenie docelowe należy go zaszyfrować, zapewniając gwarancje bezpieczeństwa podobne do tych opisanych w białej księdze dotyczącej zabezpieczeń usługi Google Cloud Key Vault, tak aby nie można było go odszyfrować zdalnie ani użyć do zdalnego odblokowania żadnego z urządzeń.
- [C-11-2] Na urządzeniu źródłowym należy poprosić użytkownika o potwierdzenie czynnika wiedzy urządzenia źródłowego przed przeniesieniem czynnika wiedzy na urządzenie docelowe.
- [C-11-3] Na urządzeniu docelowym, na którym nie ma ustawionego pierwotnego czynnika uwierzytelniania, NALEŻY poprosić użytkownika o potwierdzenie przesłanego czynnika uwierzytelniania na urządzeniu docelowym przed ustanowieniem tego czynnika jako pierwotnego czynnika uwierzytelniania na urządzeniu docelowym i przed udostępnieniem jakichkolwiek danych przesłanych z urządzenia źródłowego.
Jeśli implementacje urządzeń mają zabezpieczony ekran blokady i zawierają co najmniej 1 usługę zaufania, która wywołuje interfejs TrustAgentService.grantTrust()
System API z flagą FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
, to:
- [C-12-1] Należy wywoływać funkcję
grantTrust()
z flagą tylko wtedy, gdy urządzenie jest połączone z najbliższym fizycznym urządzeniem z własnym ekranem blokady i gdy użytkownik uwierzytelnił swoją tożsamość na tym ekranie. Urządzenia proximate mogą używać mechanizmów wykrywania na nadgarstku lub na ciele po jednorazowym odblokowaniu przez użytkownika, aby spełnić wymagania dotyczące uwierzytelniania. - [C-12-2] Implementacja urządzenia MUSI przejść w stan
TrustState.TRUSTABLE
, gdy ekran jest wyłączony (np. po naciśnięciu przycisku lub przekroczeniu czasu wyświetlania) i gdy TrustAgent nie cofnie zaufania. AOSP spełnia to wymaganie. - [C-12-3] Urządzenie MUSI przejść ze stanu
TrustState.TRUSTABLE
do stanuTrustState.TRUSTED
tylko wtedy, gdy agent zaufania nadal przyznaje zaufanie na podstawie wymagań podanych w sekcji C-12-1. - [C-12-4] NALEŻY zadzwonić do firmy
TrustManagerService.revokeTrust()
- Po upływie maksymalnie 24 godzin od przyznania zaufania lub
- Po 8 godzinach bezczynności lub
- Jeśli implementacje nie korzystają z szyfrowania i dokładnego określania zasięgu zgodnie z opisem w [C-12-5], gdy utracono podstawowe połączenie z najbliższym urządzeniem fizycznym.
- [C-12-5] W implementacjach korzystających z funkcji bezpiecznego i dokładnego określania odległości, aby spełniać wymagania podane w [C-12-4], MUSISZ używać jednego z tych rozwiązań:
- Implementacje korzystające z UWB:
- MUSI spełniać wymagania dotyczące zgodności, certyfikacji, dokładności i kalibracji w przypadku UWB opisanego w sekcji 7.4.9.
- NALEŻY użyć jednego z trybów zabezpieczeń P-STS wymienionych w sekcji 7.4.9.
- Implementacje korzystające z Wi-Fi Neighbor Awareness Networking (NAN):
- MUSI spełniać wymagania dotyczące dokładności podane w sekcji 2.2.1 [7.4.2.5/H-SR-1], używać pasma o szerokości 160 MHz (lub większej) i wykonywać czynności konfiguracji pomiarów podane w sekcji Kalibracja obecności.
- NALEŻY używać bezpiecznego LTF zgodnie z definicją w normie IEEE 802.11az.
- Implementacje korzystające z UWB:
Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych wirtualnych ekranów i obsługę powiązanych zdarzeń wejściowych, np. za pomocą VirtualDeviceManager, a ekrany nie są oznaczone flagą VIRTUAL_DISPLAY_FLAG_SECURE, to:
- [C-13-8] NALEŻY zablokować aktywności z atrybutem android:canDisplayOnRemoteDevices lub metadanymi android.activity.can_display_on_remote_devices ustawionymi na „fałsz” przed uruchomieniem na urządzeniu wirtualnym.
- [C-13-9] NALEŻY zablokować czynności, które nie umożliwiają wyraźnie strumieniowego przesyłania danych i wskazują, że wyświetlają treści poufne, w tym za pomocą SurfaceView#setSecure, FLAG_SECURE lub SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, przed uruchomieniem na urządzeniu wirtualnym.
Jeśli implementacje urządzeń obsługują oddzielne stany zasilania ekranu za pomocą DeviceStateManager
I obsługują oddzielne stany blokowania ekranu za pomocą KeyguardDisplayManager
, to:
- [C-SR-2] ZALECAMY stosowanie danych logowania spełniających wymagania opisane w sekcji 9.11.1 lub danych biometrycznych spełniających co najmniej wymagania klasy 1 opisane w sekcji 7.3.10, aby umożliwić niezależne odblokowywanie z poziomu ekranu domyślnego urządzenia.
- [C-SR-3] ZALECAMY ograniczenie możliwości odblokowania wyświetlacza za pomocą osobnego przycisku za pomocą zdefiniowanego czasu oczekiwania wyświetlacza.
- [C-SR-4] ZALECAMY, aby umożliwić użytkownikowi globalne blokowanie wszystkich wyświetlaczy za pomocą blokady na głównym urządzeniu przenośnym.
9.11.2. StrongBox
System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych na dedykowanym bezpiecznym procesorze, a także w odizolowanym środowisku wykonywania opisanym powyżej. Taki dedykowany bezpieczny procesor nazywa się „StrongBox”. Wymagania C-1–3 do C-1–11 określają wymagania, które musi spełniać urządzenie, aby kwalifikować się jako StrongBox.
Implementacje urządzeń z dedykowanym bezpiecznym procesorem:
- [C-SR-1] Zdecydowanie zalecamy obsługę StrongBox. W przyszłej wersji StrongBox prawdopodobnie stanie się wymagany.
Jeśli implementacje urządzeń obsługują StrongBox, to:
[C-1-1] NALEŻY zadeklarować FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] MUSI zawierać specjalny sprzęt zabezpieczający, który służy do tworzenia kopii zapasowych magazynu kluczy i zabezpieczonego uwierzytelniania użytkownika. Specjalny bezpieczny sprzęt może być używany również do innych celów.
[C-1-3] Musi zawierać procesor, który nie udostępnia pamięci podręcznej, DRAM, procesorów pomocniczych ani innych podstawowych zasobów procesorowi aplikacji (AP).
[C-1-4] NALEŻY zadbać o to, aby żadne urządzenia peryferyjne udostępnione AP nie mogły w żaden sposób zmieniać przetwarzania StrongBox ani uzyskiwać żadnych informacji z tego urządzenia. AP MOŻE wyłączyć lub zablokować dostęp do StrongBox.
[C-1-5] Musi mieć wewnętrzny zegar o rozsądnej dokładności (+-10%), który jest odporny na manipulacje ze strony AP.
[C-1-6] Musisz mieć prawdziwy generator liczb losowych, który generuje dane o jednolitej dystrybucji i nieprzewidywalnym wyniku.
[C-1-7] Musi być odporny na próby manipulacji, w tym próby fizycznego wtargnięcia i uszkodzenia.
[C-1-8] MUSI zapewniać odporność na kanały boczne, w tym na wyciek informacji przez zasilanie, czasowanie, promieniowanie elektromagnetyczne i cieplne.
[C-1-9] Musisz mieć bezpieczne miejsce przechowywania, które zapewnia poufność, integralność, autentyczność, spójność i aktualność treści. Nie można odczytywać ani zmieniać danych w magazynie, z wyjątkiem sytuacji dozwolonych przez interfejsy StrongBox API.
Aby sprawdzić zgodność z [C-1-3] do [C-1-9], implementacje na urządzeniu:
- [C-1-10] MUSI zawierać sprzęt z certyfikatem zgodnie z profilem ochrony IC BSI-CC-PP-0084-2014 lub oceniony przez akredytowane na poziomie krajowym laboratorium testowe, uwzględniając ocenę podatności na ataki o wysokim potencjale zgodnie z kryteriami Common Criteria w odniesieniu do kart inteligentnych.
- [C-1-11] MUSI zawierać oprogramowanie sprzętowe, które zostało ocenione przez akredytowane na poziomie krajowym laboratorium testowe, uwzględniając ocenę podatności na ataki o wysokim potencjale zgodnie z Common Criteria Application of Attack Potential to Smartcards.
- [C-SR-2] MOCNO zalecamy uwzględnienie sprzętu, który został oceniony przy użyciu poziomu oceny zabezpieczeń (EAL) 5 z rozszerzeniem AVA_VAN.5. Certyfikat EAL 5 będzie wymagany w przyszłej wersji.
- [C-SR-3] MOCNO POLECAMY zapewnienie odporności na ataki z wewnętrznego źródła (IAR), co oznacza, że osoba z wewnętrznego źródła mająca dostęp do kluczy do podpisywania oprogramowania nie może wyprodukować oprogramowania, które powoduje wyciek tajemnic z StrongBox, aby obejść wymagania dotyczące bezpieczeństwa funkcjonalnego lub w inny sposób umożliwić dostęp do poufnych danych użytkownika. Zalecana metoda implementacji IAR polega na zezwalaniu na aktualizacje oprogramowania tylko wtedy, gdy hasło głównego użytkownika zostanie podane za pomocą interfejsu IAuthSecret HAL.
9.11.3. Identity Credential
System tożsamości jest zdefiniowany i osiągnięty przez implementację wszystkich interfejsów API w pakiecie android.security.identity.*
. Te interfejsy API umożliwiają deweloperom aplikacji przechowywanie i pobieranie dokumentów tożsamości użytkownika. Implementacje na urządzeniu:
- [C-SR-1] MOCNO ZALECAMY zaimplementowanie systemu tożsamości.
Jeśli implementacje urządzeń korzystają z systemu danych uwierzytelniających tożsamość, muszą:
[C-1-1] W metodzie IdentityCredentialStore#getInstance() musi zwracać wartość inną niż null.
[C-1-2] NALEŻY zaimplementować system tożsamości (np. interfejsy API
android.security.identity.*
) za pomocą kodu, który komunikuje się z zaufaną aplikacją w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i powyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA.[C-1-3] Operacje kryptograficzne potrzebne do wdrożenia systemu tożsamości i poświadczeń (np. interfejsy API
android.security.identity.*
) MUSZĄ być wykonywane wyłącznie w zaufanej aplikacji, a materiał klucza prywatnego NIGDY nie może opuszczać odizolowanego środowiska wykonania, chyba że jest to wymagane przez interfejsy API wyższego poziomu (np. metoda createEphemeralKeyPair()).[C-1-4] Zaufana aplikacja MUSI być zaimplementowana w taki sposób, aby nie wpływało to na jej właściwości zabezpieczeń (np. dane uwierzytelniające nie są ujawniane, chyba że są spełnione warunki kontroli dostępu, a MAC-y nie mogą być generowane dla dowolnych danych), nawet jeśli Android działa nieprawidłowo lub został naruszony.
Projekt Android Open Source udostępnia referencyjną implementację zaufanej aplikacji (libeic), której można używać do implementowania systemu danych uwierzytelniających tożsamości.
9.12. Usuwanie danych
Wszystkie implementacje urządzeń:
- [C-0-1] Musisz udostępniać użytkownikom mechanizm umożliwiający przywrócenie ustawień fabrycznych.
- [C-0-2] Podczas wykonywania „przywracania danych do ustawień fabrycznych” należy usunąć wszystkie dane z systemu plików userdata.
- [C-0-3] NALEŻY usunąć dane w sposób zgodny z odpowiednimi standardami branżowymi, takimi jak NIST SP800-88, podczas wykonywania „resetu danych fabrycznych”.
- [C-0-4] NALEŻY wywołać powyższy proces „Resetowania danych do ustawień fabrycznych”, gdy interfejs API
DevicePolicyManager.wipeData()
zostanie wywołany przez aplikację Kontroler zasad urządzenia należącą do głównego użytkownika. - MOŻE udostępnić opcję szybkiego wymazywania danych, która polega tylko na logicznym usunięciu danych.
9.13. Tryb bezpiecznego rozruchu
Android udostępnia tryb bezpiecznego rozruchu, który umożliwia użytkownikom uruchamianie urządzenia w trybie, w którym działają tylko wstępnie zainstalowane aplikacje systemowe, a wszystkie aplikacje innych firm są wyłączone. Ten tryb, zwany „trybem bezpiecznego uruchamiania”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.
Implementacje na urządzeniach:
- [C-SR-1] ZDECYDOWANIE POLECAMY wdrożenie trybu bezpiecznego rozruchu.
Jeśli implementacja urządzenia obejmuje tryb bezpiecznego uruchamiania, to:
[C-1-1] NALEŻY zapewnić użytkownikowi możliwość uruchomienia trybu bezpiecznego rozruchu w sposób, który nie może zostać przerwany przez aplikacje innych firm zainstalowane na urządzeniu, z wyjątkiem sytuacji, gdy aplikacja innej firmy jest kontrolerem zasad urządzenia i ma ustawioną flagę
UserManager.DISALLOW_SAFE_BOOT
na wartość prawda.[C-1-2] Musisz umożliwić użytkownikowi odinstalowanie aplikacji innych firm w trybie awaryjnym.
NALEŻY umożliwić użytkownikowi uruchomienie trybu bezpiecznego uruchamiania z menu uruchamiania za pomocą procesu różniącego się od normalnego uruchamiania.
9.14. Izolacja systemów pojazdów samochodowych
Urządzenia z Androidem Automotive powinny wymieniać dane z podsystemami pojazdu za pomocą interfejsu HAL pojazdu do wysyłania i odbierania wiadomości w sieciach pojazdu, takich jak magistrala CAN.
Wymiana danych może być zabezpieczona przez wdrożenie funkcji bezpieczeństwa poniżej warstw platformy Android, aby zapobiec złośliwej lub niezamierzonej interakcji z tymi podsystemami.
9.15. Plany abonamentowe
„Abonamenty” to szczegóły planu rozliczeniowego udostępnione przez operatora komórkowego za pomocą SubscriptionManager.setSubscriptionPlans()
.
Wszystkie implementacje urządzeń:
- [C-0-1] MUST return subscription plans only to the mobile carrier app that has originally provided them.
- [C-0-2] Nie wolno tworzyć kopii zapasowych ani przesyłać planów subskrypcji zdalnie.
- [C-0-3] DOZWOLONE są tylko zastąpienia, takie jak
SubscriptionManager.setSubscriptionOverrideCongested()
, z aplikacji operatora komórkowego, która obecnie udostępnia ważne plany subskrypcji.
9.16. Migracja danych aplikacji
Jeśli implementacje na urządzeniu obejmują możliwość migracji danych z jednego urządzenia na inne i nie ograniczają danych aplikacji do tych skonfigurowanych przez dewelopera aplikacji w manifeście za pomocą atrybutu android:fullBackupContent, to:
- [C-1-1] NIE WOLNO inicjować przesyłania danych aplikacji z urządzeń, na których użytkownik nie skonfigurował uwierzytelniania podstawowego zgodnie z opisem w sekcji 9.11.1 Zabezpieczenia ekranu blokady i uwierzytelnianie.
- [C-1-2] NALEŻY bezpiecznie potwierdzić uwierzytelnianie podstawowe na urządzeniu źródłowym i potwierdzić intencję użytkownika dotyczącą kopiowania danych na urządzeniu źródłowym przed przeniesieniem jakichkolwiek danych.
- [C-1-3] NALEŻY użyć uwierzytelnienia klucza bezpieczeństwa, aby mieć pewność, że zarówno urządzenie źródłowe, jak i docelowe w ramach migracji są autentycznymi urządzeniami z Androidem i mają zablokowany program rozruchowy.
- [C-1-4] NALEŻY przenieść dane aplikacji tylko do tej samej aplikacji na urządzeniu docelowym z tą samą nazwą pakietu i tym samym certyfikatem podpisywania.
- [C-1-5] W menu ustawień MUSI być widoczne wskazanie, że na urządzeniu źródłowym dane zostały przeniesione z urządzenia na urządzenie. Użytkownik NIE powinien mieć możliwości usunięcia tego wskazania.
9,17. Platforma wirtualizacji Androida
Jeśli urządzenie obsługuje interfejsy API platformy wirtualizacji Androida (android.system.virtualmachine.*
), host Androida:
- [C-1-1] Musi obsługiwać wszystkie interfejsy API zdefiniowane w pakiecie
android.system.virtualmachine.*
. - [C-1-2] NIE wolno modyfikować systemu SELinux ani modelu uprawnień Androida w celu zarządzania chronionymi maszynami wirtualnymi.
- [C-1-3] Nie wolno modyfikować, pomijać ani zastępować reguł neverallow obecnych w systemie/sepolicy udostępnianym w ramach projektu Android Open Source (AOSP). Polityka musi być zgodna ze wszystkimi regułami neverallow.
- [C-1-4] NIE wolno zezwalać niesprawdzonym kodem (np. aplikacjom innych firm) na tworzenie i uruchamianie chronionej maszyny wirtualnej. Uwaga: w kolejnych wersjach Androida może się to zmienić.
- [C-1-5] NIE wolno zezwalać chronionej maszynie wirtualnej na wykonywanie kodu, który nie jest częścią obrazu fabrycznego lub jego aktualizacji. Na maszynie wirtualnej chronionej nie wolno uruchamiać niczego, co nie jest objęte funkcją Verified Boot na Androidzie (np. plików pobranych z Internetu lub zainstalowanych z zewnętrznego źródła).
Jeśli urządzenie obsługuje interfejsy API platformy wirtualizacji Androida (android.system.virtualmachine.*
), każda instancja chronionej maszyny wirtualnej:
- [C-2-1] Musisz mieć możliwość uruchamiania wszystkich systemów operacyjnych dostępnych w ramach skonfigurowanej architektury APEX w chronionej maszynie wirtualnej.
- [C-2-2] NIE wolno zezwalać chronionej maszynie wirtualnej na uruchamianie systemu operacyjnego, który nie został podpisany przez implementatora urządzenia lub dostawcę systemu operacyjnego.
- [C-2-3] NIE NALEŻY zezwalać maszynie wirtualnej z ochroną na wykonywanie danych jako kodu (np. SELinux neverallow execmem).
- [C-2-4] Nie wolno modyfikować, pomijać ani zastępować reguł neverallow obecnych w systemie/sepolicy/microdroid udostępnianym w ramach projektu Android Open Source (AOSP).
- [C-2-5] NALEŻY wdrożyć szczegółowe mechanizmy ochrony maszyny wirtualnej (np. SELinux dla maszyn wirtualnych), nawet w przypadku systemów operacyjnych innych niż Microdroid.
- [C-2-6] NALEŻY zadbać o to, aby oprogramowanie pVM nie uruchamiało się, jeśli nie może zweryfikować obrazu początkowego.
- [C-2-7] NALEŻY zadbać o to, aby oprogramowanie pVM nie uruchamiało się, jeśli integralność pliku instance.img zostanie naruszona.
Jeśli urządzenie obsługuje interfejsy API platformy wirtualizacji Androida (android.system.virtualmachine.*
), to hypervisor:
- [C-3-1] Nie wolno zezwalać żadnemu procesowi wirtualnym na dostęp do strony należącej do innego podmiotu (np. innego procesu wirtualnego lub hiperwizora), chyba że właściciel strony wyraźnie udostępnił ją do użytku. Dotyczy to także maszyny wirtualnej hosta. Dotyczy to zarówno dostępu do procesora, jak i dostępu do DMA.
- [C-3-2] NALEŻY wymazać stronę po jej użyciu przez maszynę wirtualną i przed jej zwróceniem do hosta (np. zniszczyć maszynę pVM).
- [C-3-3] NALEŻY zadbać o to, aby oprogramowanie pVM zostało załadowane i wykonane przed wykonaniem dowolnego kodu w pVM.
- [C-3-4] NALEŻY zadbać o to, aby adresy UDW i CDIs podane w pVM mogły być używane tylko przez tę konkretną instancję.
Jeśli urządzenie obsługuje interfejsy API Android Virtualization Framework, to we wszystkich obszarach:
- [C-4-1] Nie wolno udostępniać w pVM funkcji, które umożliwiają obejście modelu zabezpieczeń Androida.
Jeśli urządzenie obsługuje interfejsy API Android Virtualization Framework:
- [C-5-1] MUSI obsługiwać kompilację odizolowaną aktualizacji środowiska wykonawczego ART.
Jeśli urządzenie obsługuje interfejsy API Android Virtualization Framework, a także zarządzanie kluczami:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (aby zapobiec podszywanie się).
- [C-6-2] MUST do DICE properly i.e. provide the correct values.
10. Testowanie zgodności oprogramowania
Implementacje urządzeń MUSZĄ przejść wszystkie testy opisane w tej sekcji. Pamiętaj jednak, że żaden pakiet testów oprogramowania nie jest w pełni kompleksowy. Dlatego ZALECAMY deweloperom implementacji urządzeń wprowadzanie jak najmniejszej liczby zmian w dostępnej w ramach Projektu Android Open Source referencyjnej i preferowanej implementacji Androida. Pozwoli to zminimalizować ryzyko wprowadzenia błędów, które powodują niezgodności i wymagają ponownego wykonania pracy oraz potencjalnych aktualizacji urządzenia.
10.1. Compatibility Test Suite
Implementacje na urządzeniu:
[C-0-1] Musisz przejść testy zgodności Androida (Compatibility Test Suite, CTS) dostępne w ramach projektu Android Open Source, używając oprogramowania na urządzeniu w wersji przeznaczonej do sprzedaży.
[C-0-2] NALEŻY zapewnić zgodność w przypadku niejednoznaczności w CTS oraz w przypadku każdej reimplementacji części kodu źródłowego referencyjnego.
Test CTS jest przeznaczony do uruchamiania na rzeczywistym urządzeniu. Podobnie jak inne oprogramowanie, CTS może zawierać błędy. Wersje CTS będą wydawane niezależnie od tej definicji zgodności, a w przypadku Androida 13 może być udostępnionych kilka wersji CTS.
Implementacje na urządzeniu:
[C-0-3] Musi przejść najnowszą wersję CTS dostępną w momencie ukończenia oprogramowania urządzenia.
NALEŻY w jak największym stopniu korzystać z implementacji referencyjnej w drzewie Android Open Source.
10.2. Weryfikator CTS
Narzędzie CTS Verifier jest częścią pakietu Compatibility Test Suite i ma być uruchamiane przez operatora w celu testowania funkcji, których nie można przetestować za pomocą automatycznego systemu, np. prawidłowego działania kamery i czujników.
Implementacje na urządzeniu:
- [C-0-1] Musisz poprawnie wykonać wszystkie odpowiednie przypadki w weryfikatorze CTS.
Narzędzie CTS Verifier zawiera testy wielu rodzajów sprzętu, w tym niektórych opcjonalnych.
Implementacje na urządzeniu:
- [C-0-2] Musi przejść wszystkie testy sprzętowe, które posiada. Jeśli na przykład urządzenie ma akcelerometr, MUSI poprawnie wykonać test akcelerometru w CTS Verifier.
Przypadki testowe funkcji oznaczonych w tym dokumencie z definicją zgodności jako opcjonalne MOGĄ zostać pominięte.
- [C-0-2] Każde urządzenie i każda kompilacja MUSZĄ prawidłowo działać z narzędziem CTS Verifier, jak opisano powyżej. Ponieważ jednak wiele wersji jest bardzo podobnych, nie oczekuje się, aby implementatorzy urządzeń uruchamiali narzędzie CTS Verifier w przypadku wersji, które różnią się tylko nieznacznie. W szczególności implementacje urządzeń, które różnią się od implementacji, która przeszła test CTS Verifier, tylko pod względem zestawu obsługiwanych języków, marki itp., MOGĄ pominąć test CTS Verifier.
11. Oprogramowanie z możliwością aktualizacji
[C-0-1] Implementacje urządzeń MUSZĄ zawierać mechanizm umożliwiający zastąpienie całego oprogramowania systemowego. Mechanizm nie musi wykonywać „na żywo” uaktualnień, czyli może być konieczne ponowne uruchomienie urządzenia. Można użyć dowolnej metody, o ile pozwala ona na zastąpienie całego wstępnie zainstalowanego oprogramowania na urządzeniu. Na przykład każde z tych rozwiązań spełnia to wymaganie:
- „Over-the-air (OTA)” – pobieranie z aktualizacją offline po ponownym uruchomieniu.
- „Przywiązane” aktualizacje przez USB z komputera hosta.
- „Offline” aktualizacje przez ponowne uruchomienie i aktualizację z pliku na wymiennym nośniku danych.
[C-0-2] Używany mechanizm aktualizacji MUSI obsługiwać aktualizacje bez kasowania danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachować dane prywatne aplikacji i dane udostępnione przez aplikację. Pamiętaj, że oprogramowanie Androida na poziomie upstream zawiera mechanizm aktualizacji, który spełnia ten wymóg.
[C-0-3] Cała aktualizacja MUSI być podpisana, a mechanizm aktualizacji na urządzeniu MUSI weryfikować aktualizację i podpis za pomocą klucza publicznego przechowywanego na urządzeniu.
[C-SR-1] W ramach mechanizmu podpisywania BARDZO ZALECAMY stosowanie szyfrowania SHA-256 i weryfikowania skrótu za pomocą klucza publicznego przy użyciu ECDSA NIST P-256.
Jeśli implementacje urządzeń obejmują obsługę nielimitowanego połączenia danych, takiego jak 802.11 lub profil Bluetooth PAN (Personal Area Network), to:
- [C-1-1] MUSI obsługiwać pobieranie OTA z aktualizacją offline przez ponowne uruchomienie.
Implementacje urządzeń powinny weryfikować, czy obraz systemu jest identyczny z oczekiwanym wynikiem po aktualizacji OTA. Ten wymóg spełnia implementacja OTA na podstawie bloków w upstreamowym projekcie Android Open Source, dodana od wersji Android 5.1.
Implementacje urządzeń powinny też obsługiwać aktualizacje systemu A/B. AOSP wdraża tę funkcję za pomocą interfejsu HAL sterowania uruchamianiem.
Jeśli po wydaniu urządzenia zostanie w nim znaleziony błąd, który wpływa na zgodność aplikacji innych firm, ale w rozsądnym okresie czasu od wydania urządzenia (określonym w konsultacji z zespołem ds. zgodności Androida), należy:
- [C-2-1] Implementator urządzenia MUSI poprawić błąd za pomocą dostępnej aktualizacji oprogramowania, którą można zastosować zgodnie z opisanym mechanizmem.
Android zawiera funkcje, które umożliwiają aplikacji Właściciel urządzenia (jeśli jest dostępna) kontrolowanie instalacji aktualizacji systemu. Jeśli podsystem aktualizacji systemu dla urządzeń zgłasza android.software.device_admin, to:
- [C-3-1] NALEŻY zaimplementować działanie opisane w klasie SystemUpdatePolicy.
12. Historia zmian dokumentu
Oto podsumowanie zmian w definicji zgodności w tej wersji:
4 października 2023 roku
2. Typy urządzeń
-
Wyświetlanie wersji
- [9.8/H-1-14] MUSI wyświetlać wskaźnik mikrofonu zgodnie z opisem w sekcji 9.8.2
[9.8/C-3-1], gdy do usługi głosowej zostanie przesłany pozytywny wynik wyszukiwania hasła
- [9.8/H-1-14] MUSI wyświetlać wskaźnik mikrofonu zgodnie z opisem w sekcji 9.8.2
-
Wyświetlanie wersji
[5.1/H-1-7] W przypadku sesji kodowania wideo w rozdzielczości 1080p lub niższej we wszystkich sprzętowych kodekiach wideo czas opóźnienia inicjalizacji kodeka MUSI wynosić 40 ms lub mniej. Obciążenie jest tu zdefiniowane jako jednoczesna sesja transkodowania wideo z 1080p na 720p z wykorzystaniem kodeków wideo sprzętowych oraz inicjalizacja nagrywania dźwięku i obrazu w rozdzielczości 1080p. W przypadku kodeka Dolby Vision opóźnienie inicjowania kodeka MUSI wynosić 50 ms lub mniej.
[5.1/H-1-12] Czas opóźnienia inicjalizacji kodeka musi wynosić 40 ms lub mniej w przypadku sesji dekodowania wideo w rozdzielczości 1080p lub niższej dla wszystkich dekoderów wideo sprzętowych podczas obciążenia. Obciążenie jest tu zdefiniowane jako jednoczesna sesja transkodowania z 1080p na 720p tylko wideo z wykorzystaniem kodeków wideo sprzętowych oraz inicjalizacja odtwarzania dźwięku i obrazu w jakości 1080p. W przypadku kodeka Dolby Vision opóźnienie inicjalizacji musi wynosić 50 ms lub mniej.
[5.1/H-1-13] Czas opóźnienia inicjalizacji kodeka MUSI wynosić 30 ms lub mniej w przypadku sesji dekodowania dźwięku o szybkości transmisji 128 kb/s lub niższej dla wszystkich dekoderów audio podczas obciążenia. Obciążenie jest tu zdefiniowane jako równoległa sesja transkodowania z 1080p na 720p tylko wideo za pomocą kodeków wideo sprzętowych oraz inicjalizacja odtwarzania dźwięku i obrazu w jakości 1080p.
7.4. Połączenie danych
7.4.1.1. Zgodność z blokowaniem numerów:
Wyświetlanie wersji
Jeśli implementacje na urządzeniach zgłaszają funkcję
android.hardware.telephony.calling
, to:7.4.1.2. Interfejs Telecom API:
Wyświetlanie wersji
Jeśli wdrożenia urządzeń zgłaszają
android.hardware.telephony.calling
, to:
9.11. Klucze i dane uwierzytelniające
-
Wyświetlanie wersji
jest udostępniany za pomocą interfejsu HAL IAuthSecret.
Usunięto IAR będzie wymagany w Androidzie 14.
26 czerwca 2023 r.
2. Typy urządzeń
-
Usunięto wymagania 7.2.3/H-0-5, 7.2.3/H-0-6 i 7.2.3/H-0-7
Inna aktualizacja:
Wyświetlanie wersji
MOCNO POLECAMY wykonanie czynności konfiguracji pomiaru opisanych w artykule Kalibracja obecności – wymagania
.
-
Wyświetlanie wersji
Jeśli implementacje urządzeń samochodowych są 32-bitowe:
[7.6.1/A-1-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 512 MB, jeśli używana jest dowolna z tych gęstości:
- 280 dpi lub mniej na małych/normalnych ekranach
- ldpi lub niższą na bardzo dużych ekranach.
- mdpi lub niższym na dużych ekranach.
[7.6.1/A-1-2] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 608 MB, jeśli używana jest dowolna z tych gęstości:
- xhdpi lub wyższa na małych/normalnych ekranach
- hdpi lub wyższa na dużych ekranach.
- mdpi lub wyższa na bardzo dużych ekranach.
[7.6.1/A-1-3] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 896 MB, jeśli używana jest dowolna z tych gęstości:
- 400 dpi lub więcej na małych/normalnych ekranach
- xhdpi lub wyższa na dużych ekranach
- tvdpi lub wyższa na bardzo dużych ekranach.
[7.6.1/A-1-4] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1344 MB, jeśli używana jest dowolna z tych gęstości:
- 560 dpi lub więcej na małych/normalnych ekranach
- 400 dpi lub więcej na dużych ekranach.
- xhdpi lub wyższa na bardzo dużych ekranach.
3. Oprogramowanie
3.2.3.5. Warunkowe intencje aplikacji
Wyświetlanie wersji
Jeśli implementacje na urządzeniu zgłaszają android.hardware.telephony.calling
, to:android.hardware.telephony
7. Zgodność sprzętu
-
Wyświetlanie wersji
Kalibracja obecności
wymagania.
9. Zgodność modelu zabezpieczeń
-
Wyświetlanie wersji
Implementacje na urządzeniu:
[C-0-5] NIE NALEŻY przyznawać żadnych uprawnień w czasie działania
wstępnie zainstalowanymaplikacjom, chyba że:- Są one instalowane w momencie wysyłki urządzenia, a także
- zgodę użytkownika można uzyskać przed użyciem przez aplikację
tegouprawnienia,
LUB
- Uprawnienia w czasie wykonywania są przyznawane przez domyślną zasadę przyznawania uprawnień lub w przypadku posiadania roli na platformie.
Powiązane z wzorcem intencji, dla którego wstępnie zainstalowana aplikacja jest ustawiona jako domyślny moduł obsługi.
9.11. Klucze i dane uwierzytelniające
- Usunięto wymagania [C-13-10] i 9.11.4.
20 marca 2023 r.
2. Typy urządzeń
-
Wyświetlanie wersji
Jeśli aplikacja ustawień na urządzeniu przenośnym implementuje funkcje podzielone, korzystając z osadzania aktywności, to:
- [
C-17-13.2.3.1/ H-1-1] Musi zawierać aktywność, która obsługuje działanie Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY, gdy włączona jest funkcja podziału. Aktywność MUSI być chroniona przezandroid.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
i MUSI uruchamiać aktywność zamierzoną w ramach zamiaru z Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
Koniec nowych wymagań
- [
-
Wyświetlanie wersji
Jeśli implementacje telewizorów z dekoderami sprzętowymi VP9 obsługują dekodowanie VP9 i profil dekodowania UHD, to:
- [5.3.7/T-
2-1SR1] MOCNO zalecane, aby obsługiwać profil dekodowania UHD z szybkością 60 FPS z profilem 2 (głębia kolorów 10 bitów).
- [5.3.7/T-
-
Wyświetlanie wersji
Implementacje na urządzeniach samochodowych:
[7.3/A-
0-1SR1] MAY dead reckon Location by fusing GPS/GNSS with additional sensors. Jeśli lokalizacja jest określana na podstawie danych z GPS, MOCNO zalecamy zaimplementowanie i raportowanie odpowiednich typów czujników lub identyfikatorów właściwości pojazdu.[7.3/A-
0-20-4] Lokalizacja wymagana przez LocationManager#requestLocationUpdates() NIE MOŻE być dopasowana do mapy.
3. Oprogramowanie
-
Wyświetlanie wersji
Domyślne konto dla nowych kontaktów: dostawca kontaktów udostępnia interfejsy API do zarządzania ustawieniem domyślnego konta podczas tworzenia nowego kontaktu.
Jeśli implementacje na urządzeniu wczytują wstępnie aplikację Kontakty, to wczytana wstępnie aplikacja Kontakty:
[C-2-1] MUSI obsługiwać intencję
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
, aby uruchomić interfejs użytkownika do wyboru konta i zapisz ustawienia w usługie kontaktów po wybraniu konta.[C-2-2] Podczas obsługi
Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
dlaContactsContracts.Contacts.CONTENT_TYPE
iContactsContract.RawContacts.CONTENT_TYPE
MUSISZ uwzględnić ustawienie domyślnego konta, wybierając je na początku.
Koniec nowych wymagań
3.2.3.5. Warunkowe intencje aplikacji
Wyświetlanie wersji
[Przeniesiono do sekcji 2.2.3]
Jeśli implementacja aplikacji Ustawienia na urządzeniu korzysta z funkcji podzielonej, wykorzystując umieszczanie aktywności, to:
- [C-17-1] Musisz mieć aktywność, która obsługuje działanie Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY, gdy włączona jest funkcja podziału. Aktywność MUSI być chroniona przez
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
i MUSI uruchamiać aktywność zamierzoną w ramach zamiaru z Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
Koniec nowych wymagań
- [C-17-1] Musisz mieć aktywność, która obsługuje działanie Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY, gdy włączona jest funkcja podziału. Aktywność MUSI być chroniona przez