Definicja zgodności z Androidem 15

1. Wprowadzenie

Ten dokument zawiera listę wymagań, które muszą zostać spełnione, aby urządzenia były zgodne z Androidem 15.

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 „implementer urządzenia” lub „implementer” to osoba lub organizacja opracowująca rozwiązanie sprzętowe/programowe z Androidem15. „Wdrażanie urządzenia” lub „wdrażanie” to opracowane rozwiązanie sprzętowo-programowe.

Aby uznać implementację urządzenia za zgodną z Androidem 15, należy spełnić wymagania podane w tej definicji zgodności, w tym wszelkie dokumenty uwzględnione w dokumentach referencyjnych.

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 dotyczy konkretnego typu 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 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 oprogramowanie, 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ć przekątną ekranu w zakresie od 4 do 8 cali;
• mieć interfejs dotykowy;

Dodatkowe wymagania w pozostałych częściach tej sekcji dotyczą implementacji na urządzeniach przenośnych z Androidem.

Uwaga: wymagania, które nie mają zastosowania do urządzeń z Androidem w formie tabletu, są oznaczone gwiazdką (*).

2.2.1. Sprzęt

Implementacje na urządzeniach przenośnych:

• [7.1.1.1/H-0-1] Musisz mieć co najmniej jeden wyświetlacz zgodny z Androidem o szerokości co najmniej 2,2 cala na krawędzi krótkiej i 3,4 cala na krawędzi długiej.

• [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 buforów graficznych o rozmiary co najmniej tak duże jak najwyższa rozdzielczość dowolnego wbudowanego wyświetlacza.

• [7.1.1.1/H-0-3]* Każdy UI_MODE_NORMAL wyświetlacz udostępniony aplikacjom innych firm MUSI być mapowany na niezakłócony fizyczny obszar wyświetlacza o długości co najmniej 2,2 cala po krótszym boku i 3,4 cala po dłuższym boku.

• [7.1.1.3/H-0-1]* NALEŻY ustawić wartość parametru DENSITY_DEVICE_STABLE na co najmniej 92% rzeczywistej gęstości fizycznej odpowiedniego wyświetlacza.

Jeśli implementacje na urządzeniach przenośnych obsługują Vulkan, muszą:

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

Jeśli implementacje urządzeń przenośnych obsługują wyświetlacze HDR za pomocą Configuration.isScreenHdr() , to:

• [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 i VK_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 określonych w dokumentacji Perffetto.
• [7.1.4.6/H-1-2] MUSI raportować wartości zgodne z wartościami licznikó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] MUST report a GPU Frequency punkt trasowania 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 MUSZĄ być wysyłane zdarzenia zarówno normalnego, jak i długiego naciśnięcia przycisku 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ęciu KEYCODE_MEDIA_PLAY_PAUSE lub KEYCODE_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 raportować 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:

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

Nowe wymagania dotyczące Androida 15

• [7.4.3/H] NALEŻY uwzględnić obsługę Bluetooth i Bluetooth LE.

Implementacje urządzeń przenośnych, które obejmują obsługę Bluetooth LE:

• [7.4.3/H-SR-1] WYJĄTKOWO MOCNO POLECA się obsługę rozszerzenia długości pakietu danych Bluetooth LE.

  Uwaga: ten wymóg [7.4.3/H-SR-1] stanie się wymogiem w przyszłej wersji Androida.

Koniec nowych wymagań

Jeśli urządzenia obsługują protokół NAN (Wi-Fi Neighbor Awareness Networking) przez zadeklarowanie PackageManager.FEATURE_WIFI_AWARE i lokalizacji Wi-Fi (czas RTT – Round Trip Time – w sieci Wi-Fi) przez zadeklarowanie 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 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 widać w interfejsie WifiRttManager#startRanging Android API.

MOCNO zalecamy wykonanie czynności konfiguracji pomiarów opisanych w sekcji Kalibracja obecności.

Jeśli implementacje urządzeń przenośnych deklarują FEATURE_BLUETOOTH_LE, muszą:

• [7.4.3/H-1-3] MUSI zmierzyć i skompensować przesunięcie Rx, aby zapewnić średnią wartość RSSI BLE na poziomie -50 dBm +/-15 dB w odległości 1 m od urządzenia referencyjnego nadającego z częstotliwością ADVERTISE_TX_POWER_HIGH.
• [7.4.3/H-1-4] NALEŻY zmierzyć i skompensować przesunięcie Tx, aby zapewnić, że średnia wartość RSSI BLE wynosi -50 dBm +/-15 dB podczas skanowania z urządzenia referencyjnego znajdującego się w odległości 1 m i transmitującego z prędkością ADVERTISE_TX_POWER_HIGH.

Jeśli implementacje urządzeń przenośnych zawierają 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 ono wynosić od 50 do 90 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” w przypadku ActivityManager.isLowRamDevice(), gdy do użycia przez jądro i przestrzeń użytkownika jest dostępne 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).

Powyższy opis „pamięci dostępnej 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.

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, nie spełniają one tych wymagań:

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

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń przenośnych zawierają port USB obsługujący kontroler działający w trybie peryferyjnym, muszą:

• [7.7.1/H-1-1] MUSI implementować interfejs API akcesoriów otwartych Androida (AOA).

Koniec nowych wymagań

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	Dane wejściowe: krótkie naciśnięcie Dane wyjściowe: 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 dotyczącej 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 rolę isSink(), jeśli pole typu terminala audio USB ma wartość 0x0302.

• [7.8.2.2/H-4-2] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i rolę isSink(), jeśli pole typu terminala audio USB ma wartość 0x0402.

• [7.8.2.2/H-4-3] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i rolę isSource(), jeśli pole typu terminala audio USB ma wartość 0x0402.

• [7.8.2.2/H-4-4] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i rolę 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ę zliczanie identyfikatorów USB, identyfikację typów terminali i wysyłanie komunikatu o intencji ACTION_HEADSET_PLUG w mniej niż 1000 ms.

Nowe wymagania dotyczące Androida 15

Jeśli w przypadku implementacji na urządzeniach przenośnych deklarujesz 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ć 300 ms w przypadku 5 pomiary, a średnia odchylenie bezwzględne nie może przekraczać 30 ms na następujących ścieżkach danych: „głośnik do mikrofonu”, przejściówka 3,5 mm (jeśli jest obsługiwana), przejściówka USB (jeśli jest obsługiwana).

• [5.6/H-1-2] Średnie opóźnienie od naciśnięcia do tonu MUSI wynosić 300 ms lub mniej w przynajmniej 5 przypadkach pomiarów na ścieżce danych od głośnika do mikrofonu.

Koniec nowych wymagań

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 aktywny element 7.10 do zastosowań ogólnych, to:

• [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] SHOULD move the haptic actuator in the X-axis (left-right) of the device's natural orientation.

Jeśli implementacje urządzeń przenośnych mają ogólnego przeznaczenia 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 przestrzegają mapowania stałych wartości haptycznych, muszą:

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

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

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

Implementacje na urządzeniach przenośnych MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

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

2.2.3. Oprogramowanie

Implementacje na urządzeniach przenośnych:

• [3.2.3.1/H-0-1] Aplikacja MUSI obsługiwać intencje ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE i ACTION_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 API DocumentsProvider.
• [3.2.3.1/H-0-2]* MUSI 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 i NotificationManager.
• [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 sterowanie 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ępnionych 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 jako true zgodnie z odpowiedziami wyświetlanymi przez Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR-1] MOCNO zaleca się wdrożenie na urządzeniu asystenta, który będzie obsługiwał 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 powiadomienie MediaStyle z tokenem MediaSession.

Jeśli implementacje urządzeń, w tym klucz nawigacyjny funkcji „Ostatnie”, opisane w sekcji 7.2.3 zmieniają interfejs, muszą:

• [3.8.3/H-1-1] NALEŻY wdrożyć funkcję przypinania ekranu i udostępnić użytkownikowi menu ustawień, aby włączyć tę funkcję.

Jeśli implementacje na urządzeniach przenośnych obsługują działanie Asystenta, mogą:

• [3.8.4/H-SR-2] Zdecydowanie 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 implementuje VoiceInteractionService, 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ługi 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, muszą:

• [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ą publikowanie elementów sterujących urządzeniami przez aplikacje innych firm, 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 umożliwić użytkownikowi dodawanie, edytowanie, wybieranie i sterowanie ulubionymi elementami sterowania urządzeniami z użyciem interfejsów API ControlsProviderService i Control 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 interfejsy Control 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 interfejsu Control Control.isAuthRequired API.

• [3.8.16/H-1-6] Implementacje na urządzeniach MUSZĄ poprawnie renderować interfejs użytkownika w ten sposób:

  • Jeśli urządzenie ma ustawioną wartość config_supportsMultiWindow=true, a aplikacja deklaruje metadane META_DATA_PANEL_ACTIVITY w deklaracji ControlsProviderService, w tym nazwę komponentu prawidłowej aktywności (zdefiniowanej przez interfejs API), aplikacja MUSI uwzględnić tę aktywność w interfejsie użytkownika.
  • Jeśli aplikacja nie deklaruje metadanych META_DATA_PANEL_ACTIVITY, musi renderować określone pola zgodnie z interfejsem ControlsProviderServiceAPI oraz dowolne określone pola udostępnione przez interfejsy Control.

• [3.8.16/H-1-7] Jeśli aplikacja deklaruje metadane META_DATA_PANEL_ACTIVITY, musi przekazać wartość ustawienia zdefiniowanego w [3.8.16/H-1-5] za pomocą EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLSpodczas uruchamiania wbudowanej aktywności.

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 the ControlsProviderService and the Control APIs.
• [3.8.16/H-2-2] NALEŻY zadeklarować flagę funkcji android.software.controls i ustawić ją na false.

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] MUSI wyświetlać użytkownikowi potwierdzenie, że dane zostały skopiowane do schowka (np. miniaturę lub alert „Treść skopiowana”). Dodatkowo określ, czy dane ze schowka będą synchronizowane na różnych urządzeniach.

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 uwzględnić 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 i android.media.action.STILL_IMAGE_CAMERA_SECUREintencji oraz uruchamiać aparat w trybie zdjęć zgodnie z opisem w pakiecie SDK.
• [7.5.4/H-1-2] MUSI obsługiwać android.media.action.VIDEO_CAMERAintencję uruchomienia aparatu w trybie wideo zgodnie z opisem w pakiecie SDK.

Jeśli aplikacja ustawień implementowana na urządzeniu korzysta z funkcji podzielonej, wykorzystując umieszczanie aktywności, to:

• [3.2.3.1/ H-1-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.

Jeśli implementacja urządzenia umożliwia użytkownikom nawiązywanie połączeń,

• [7.4.1.2/H-0-1] NALEŻY zadeklarować flagę funkcji android.software.telecom.
• [7.4.1.2/H-0-2] MUSISZ wdrożyć ramy telekomunikacyjne.

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ą spełniać te wymagania:

• [8.4/H-1-1] MUSI obsługiwać intencję android.intent.action.POWER_USAGE_SUMMARYi wyświetlać menu ustawień, które pokazuje zużycie energii.

Implementacje na urządzeniach przenośnych:

• [8.5/H-0-1] MUSISZ zapewnić użytkownikowi możliwość wyświetlenia wszystkich aplikacji z aktywnymi usługami na pierwszym planie lub zadaniami inicjowanymi przez użytkownika, w tym czasu trwania każdej z tych usług od momentu jej uruchomienia zgodnie z opisem w dokumencie pakietu SDK.

• [8.5/H-0-2]Musisz umożliwić użytkownikowi zatrzymanie aplikacji, która uruchamia usługę na pierwszym planie lub zadanie wywołane przez użytkownika.

2.2.5. Model zabezpieczeń

Implementacje na urządzeniach przenośnych:

• [9/H-0-1] NALEŻY zadeklarować funkcję android.hardware.security.model.compatible.
• [9.1/H-0-1] APLIKACJE MUSIAŁY ZEZWALAĆ na dostęp do statystyk dotyczących wykorzystania za pomocą uprawnienia android.permission.PACKAGE_USAGE_STATS oraz udostępnić użytkownikowi mechanizm umożliwiający przyznawanie i odbieranie dostępu do tych aplikacji w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Nowe wymagania dotyczące Androida 15

Implementacje urządzeń MUSZĄ deklarować obsługę: android.software.credentials oraz:

• [9/H-0-2] MUSI uwzględniać zamiar android.settings.CREDENTIAL_PROVIDER, aby umożliwić wybranie preferowanego dostawcy menedżera danych logowania. Ten dostawca będzie obsługiwany przez Autouzupełnianie i będzie też domyślną lokalizacją do zapisywania nowych danych logowania wprowadzonych za pomocą menedżera danych logowania.

• [9/H-0-3] MUSI obsługiwać co najmniej 2 jednoczesne dostawców danych logowania i umożliwiać użytkownikowi w aplikacji Ustawienia włączenie lub wyłączenie dostawców.

Koniec nowych wymagań

Jeśli implementacje na urządzeniu deklarują obsługę android.hardware.telephony, to:

• [9.5/H-1-1] NIE NALEŻY ustawiać parametru UserManager.isHeadlessSystemUserMode na true.

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

Nowe wymagania dotyczące Androida 15

• [9.11/H-0-5] MUSI obsługiwać atestakcję klucza, w której klucz do podpisywania atestacyjnym jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane na bezpiecznym sprzęcie. Klucze podpisywania atestacyjnym MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby zapobiec ich wykorzystaniu w celu trwałego identyfikowania 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 kodu SKU, dla każdej grupy 100 tys. jednostek MOŻE być używany inny klucz.

  Uwaga: aby spełnić to wymaganie, musisz udostępnić ten sam klucz uwierzytelniający dla danego kodu SKU,chyba że wyprodukowano co najmniej 100 tys. jego sztuk. Jeśli wyprodukowano ponad 100 tys. sztuk danego kodu SKU, w przypadku każdej kolejnej grupy 100 tys. sztuk MOŻE być używany inny klucz. Możesz też użyć rozwiązania do zdalnego udostępniania kluczy, aby udostępnić na urządzeniu klucze poświadczania o krótkim czasie ważności.

Koniec nowych wymagań

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 podstawowego uwierzytelniania opisanego w sekcji 9.11.1 Bezpieczny ekran blokady. AOSP spełnia ten wymóg jako tryb blokady.

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:

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

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 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 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 zezwalać /odblokowywać dostęp do połączeń głosowych i SMS-ów dla innych użytkowników.

Jeśli w implementacjach urządzeń przenośnych ustawiono wartość UserManager.isHeadlessSystemUserMode na true,

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

Android, za pomocą interfejsu System API VoiceInteractionService, obsługuje mechanizm bezpiecznego wykrywania słów-kluczy w trybie zawsze włączonym bez wskazania dostępu do mikrofonu oraz wykrywania zapytań w trybie zawsze włączonym bez wskazania dostępu do mikrofonu ani kamery.

Nowe wymagania dotyczące Androida 15

Ustawienia z ograniczeniami

Ustawienia ograniczone wyświetlają użytkownikowi widoczne ostrzeżenia i wymagają potwierdzenia, aby przyznać uprawnienia w przypadku każdej aplikacji, która:

• być zainstalowana po pobraniu z aplikacji (na przykład aplikacji do obsługi wiadomości lub przeglądarki) innej niż „sklep z aplikacjami” zidentyfikowana przez PackageManager jako PACKAGE_DOWNLOADED_FILE;
• została zainstalowana z pliku lokalnego (np. została zainstalowana w trybie sideload), a identyfikator PackageManager wskazuje, że jest to aplikacja PACKAGE_SOURCE_LOCAL_FILE;

W przypadku dowolnych wymaganych uprawnień i powiązanych z nimi identyfikatorów wymienionych w sekcji [9.8/H-0-5] poniżej.

Takie aplikacje są oznaczone etykietą „Aplikacje objęte wymaganiami” w przypadku wymagań wymienionych w tej sekcji.

Implementacje na urządzeniu:

• [9.8/H-0-1] NALEŻY wdrożyć ustawienia z ograniczeniami opisane powyżej w przypadku:

  • Uprawnienia specjalne
    • Dostępność (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
    • Odbiornik powiadomień (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
    • Aplikacje administratora urządzenia (Manifest.permission.BIND_DEVICE_ADMIN)
    • Wyświetlanie nad innymi aplikacjami (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
    • Dostęp do danych o wykorzystaniu (AppOpsManager.OPSTR_GET_USAGE_STATS)
  • Role (Aplikacje domyślne)
    • Dialer (RoleManager.ROLE_DIALER)
    • SMS (RoleManager.ROLE_SMS)
  • Uprawnienia czasu działania
    • Czas trwania SMS-a (Manifest.permission_group.SMS)

• [9.8/H-0-2] NALEŻY włączyć ustawienia ograniczone jako domyślne. MOCNO zalecamy, aby nie udostępniać użytkownikom możliwości wyłączenia ustawień ograniczonych we wszystkich aplikacjach.

• [9.8/H-0-3] NALEŻY zadbać o to, aby w przypadku każdej Aplikacji podlegającej przepisom użytkownik wyraził zgodę na przyznanie uprawnień na mocy przepisów.

• [9.8/H-0-4] Musisz zezwolić na potwierdzenie przez użytkownika w celu włączenia ustawień ograniczonych, które można uzyskać na stronie AppInfo aplikacji objętej zakresem, za pomocą interfejsu EnhancedConfirmationManager API.

• [9.8/H-0-5] W przypadku wszystkich specjalnych uprawnień ZALECAMY zintegrowanie się z klasą EnhancedConfirmationManager i wywołanie jej metod, aby dynamicznie określić, czy są to uprawnienia ograniczone.

  • Alarmy i przypomnienia: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • Dostęp do wszystkich plików: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
  • Wyświetlanie nad innymi aplikacjami: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
  • Instalowanie nieznanych aplikacji: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
  • Zarządzanie mediami: AppOpsManager.OPSTR_MANAGE_MEDIA
  • Zmień ustawienia systemu: AppOpsManager.OPSTR_WRITE_SETTINGS
  • Obraz w obrazie: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
  • Włączanie ekranu: AppOpsManager.OPSTR_TURN_SCREEN_ON
  • Powiadomienia pełnoekranowe: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
  • Sterowanie Wi-Fi: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
  • Dostępność: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
  • Odbiornik powiadomień: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
  • Dostęp do danych o użytkowaniu: AppOpsManager.OPSTR_GET_USAGE_STATS
  • Administrator urządzenia: Manifest.permission.BIND_DEVICE_ADMIN
  • Nie przeszkadzać: Manifest.permission.MANAGE_NOTIFICATIONS

Uwaga: ten wymóg jest spełniony przez upstreamowy projekt Android Open Source Project (AOSP) dzięki ustawieniuconfig_enhancedConfirmationModeEnabled na true w pliku konfiguracyjnym oraz integracji z interfejsem API EnhancedConfirmationManager.

Koniec nowych wymagań

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 systemu ContentCaptureService lub do usługi rozpoznawania mowy na urządzeniu utworzonej przez SpeechRecognizer#createOnDeviceSpeechRecognizer().
• [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 wyprowadzone za pomocą interfejsu HotwordDetectionService API lub do ContentCaptureService za pomocą interfejsu ContentCaptureManager 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 żądania do usługi wykrywania słów-kluczy nie wolno przesyłać do niej zasobów audio z mikrofonu z buforem 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 zezwalać na przesyłanie więcej niż 100 bajtów danych (z wyjątkiem strumieni audio) z usługi wykrywania słów kluczowych w przypadku każdego udanego wyniku wykrycia słowa kluczowego.
• [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] MUSI wyświetlać 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-1-15] NALEŻY zadbać o to, aby strumienie audio dostarczone w ramach wyników wykrywania słów-kluczy były przesyłane w jednym kierunku z usługi wykrywania słów-kluczy do usługi interakcji głosowej.

• [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 na urządzeniu 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ć danych 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 danych do usługi ContentCaptureService lub usługi rozpoznawania mowy na urządzeniu.

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

• [9.8/H-3-1] NALEŻY zadbać o to, aby usługa wykrywania zapytań mogła przesyłać dane tylko do systemu lub do usługi ContentCaptureService albo do usługi rozpoznawania mowy na urządzeniu (która została utworzona przez SpeechRecognizer#createOnDeviceSpeechRecognizer()).
• [9.8/H-3-2] NIE MOŻESZ zezwalać na przesyłanie jakichkolwiek informacji audio lub wideo poza VisualQueryDetectionService, z wyjątkiem ContentCaptureService lub usługi rozpoznawania mowy na urządzeniu.
• [9.8/H-3-3] NALEŻY wyświetlić użytkownikowi powiadomienie w interfejsie systemu, gdy urządzenie wykryje jego zamiar korzystania z aplikacji asystenta cyfrowego (np.przez wykrycie obecności użytkownika za pomocą kamery).
• [9.8/H-3-4] MUSI wyświetlać wskaźnik mikrofonu i wykrywanie zapytań użytkownika w interfejsie tuż po wykryciu zapytania.
• [9.8/H-3-5] Nie zezwalaj użytkownikowi na instalowanie aplikacji, która zapewnia usługę wykrywania zapytań wizualnych.

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ę Ostatnie i Aktywne aplikacje korzystające z mikrofonu, zwracaną przez PermissionManager.getIndicatorAppOpUsageData(), wraz z wszelkimi komunikatami atrybutu powiązanymi z tymi aplikacjami.
• [9.8.2/H-4-3] 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.
• [9.8.2/H-4-4] MUSI wyświetlać listę ostatnich i aktywnych aplikacji korzystających z mikrofonu, jak zwraca PermissionManager.getIndicatorAppOpUsageData(), wraz z wszelkimi komunikatami dotyczącymi atrybucji.

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.
• [9.8.2/H-5-3] 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.

Nowe wymagania dotyczące Androida 15

Weryfikacja podczas uruchamiania to funkcja, która zapewnia integralność oprogramowania urządzenia. Jeśli implementacje urządzeń obsługują tę funkcję, mogą:

• [9.10/H-1-1] NALEŻY zweryfikować wszystkie partycje tylko do odczytu zamontowane podczas sekwencji rozruchu Androida, a VBMeta digest musi uwzględniać te zweryfikowane partycje w swoim obliczeniu.

Uwaga: jeśli implementacje urządzeń zostały już uruchomione w wersji Androida wcześniejszej niż ta, która jest wymagana, i nie można dodać obsługi tych wymagań za pomocą aktualizacji oprogramowania systemowego, mogą być zwolnione z tych wymagań.

Koniec nowych wymagań

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.

Nowe wymagania dotyczące Androida 15

Implementacje na urządzeniach przenośnych (* Nie dotyczy tabletów):

• Perfetto
  • [6.1/H-0-2]* NALEŻY udostępnić użytkownikowi powłoki binarną /system/bin/perfetto kompilację, której wiersz poleceń jest zgodny z dokumentacją perfetto.
  • [6.1/H-0-3]* Plik binarny 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]* NALEŻY podać w pliku binarnym perfetto co najmniej te źródła danych, które są opisane w dokumentacji perfetto.
  • [6.1/H-0-6]*Daemon śledzenia perfetto MUSI być włączony domyślnie (właściwość systemowa persist.traced.enable).

Koniec nowych wymagań

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.U dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• MUSI spełniać wymagania dotyczące multimediów wymienione w sekcji 2.2.7.1 Warunków korzystania z usługi Androida 14.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń przenośnych zwracają wartość android.os.Build.VERSION_CODES.V w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

Koniec nowych wymagań

• [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() i VideoCapabilities.getSupportedPerformancePoints().

Nowe wymagania dotyczące Androida 15

• [5.1/H-1-2] MUSI obsługiwać 6 sesji sprzętowego dekodera wideo 8-bitowego (SDR) (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków działających jednocześnie z 3 sesjami w rozdzielczości 1080p przy 30 fps i 3 sesjami w rozdzielczości 4K przy 30 fps. W przypadku wszystkich sesji nie może wystąpić więcej niż 1 pominięta klatka na sekundę. Kodeki AV1 są wymagane tylko do obsługi rozdzielczości 1080p, ale nadal muszą obsługiwać 6 instancji przy 1080p30fps.

Koniec nowych wymagań

• [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() and VideoCapabilities.getSupportedPerformancePoints() methods.

Nowe wymagania dotyczące Androida 15

• [5.1/H-1-4] MUSI obsługiwać 6 sesji sprzętowego kodera wideo 8-bitowego (SDR) (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków działających jednocześnie z 4 sesjami w rozdzielczości 1080p przy 30 fps i 2 sesjami w rozdzielczości 4K przy 30 fps. W przypadku wszystkich sesji nie może wystąpić więcej niż 1 pominięta klatka na sekundę. Kodeki AV1 są wymagane tylko do obsługi rozdzielczości 1080p, ale nadal muszą obsługiwać 6 wystąpieni w rozdzielczości 1080p30fps.

Koniec nowych wymagań

• [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() i VideoCapabilities.getSupportedPerformancePoints().

Nowe wymagania dotyczące Androida 15

• [5.1/H-1-6] MUSI obsługiwać 6 sesji sprzętowego dekodera wideo 8-bitowego (SDR) oraz sprzętowych sesji kodera wideo (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków, które działają jednocześnie z 3 sesjami w rozdzielczości 4K przy 30 fps, z których co najwyżej 2 są sesjami kodera i 3 sesjami w rozdzielczości 1080p. W przypadku wszystkich sesji nie może wystąpić więcej niż 1 pominięta klatka na sekundę. Kodeki AV1 są wymagane tylko do obsługi rozdzielczości 1080p, ale nadal muszą obsługiwać 6 wystąpieni w rozdzielczości 1080p30fps.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

• [5.1/H-1-19] MUSI obsługiwać 3 instancje 10-bitowego (HDR) sprzętowego dekodera wideo oraz sesji sprzętowego kodera wideo (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 4K przy 30 fps, z których co najwyżej 1 to sesja kodera, która może być skonfigurowana w formacie wejściowym RGBA_1010102 za pomocą powierzchni GL. W przypadku wszystkich sesji NIE MOŻE wystąpić więcej niż 1 utracona klatka na sekundę. Generowanie metadanych HDR przez koder nie jest wymagane, jeśli kodowanie odbywa się z powierzchni GL. Sesje kodowania AV1 są wymagane tylko do obsługi rozdzielczości 1080p, nawet jeśli wymagają one rozdzielczości 4K.

Koniec nowych wymagań

• [5.1/H-1-7] W przypadku sesji kodowania wideo o rozdzielczości 1080p lub mniejszej we wszystkich sprzętowych kodeki wideo czas opóźnienia inicjalizacji kodeka MUSI wynosić 40 ms lub mniej. 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. W przypadku kodeka Dolby Vision opóźnienie inicjalizacji MUSI wynosić 50 ms lub mniej.
• [5.1/H-1-8] Czas opóźnienia inicjalizacji 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.

Nowe wymagania dotyczące Androida 15

• [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 zarówno w przypadku treści 8-bitowych (SDR), jak i 10-bitowych (HDR). W przypadku wszystkich sesji NIE MOŻE być więcej niż 1 utracona klatka na sekundę.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

• [5.1/H-1-10] MUSI obsługiwać 3 instancje sesji niechronionego sprzętowego dekodera wideo wraz z 1 sesją chronionego sprzętowego dekodera wideo (łącznie 4 sesje) (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków, które działają jednocześnie z 3 sesjami w rozdzielczości 4K przy 30 fps, w tym 1 sesja chronionego dekodera i 1 sesja niechroniona w rozdzielczości 1080p przy 30 fps, w której maksymalnie 2 sesje mogą być w trybie HDR 10-bitowym. W przypadku wszystkich sesji nie może wystąpić więcej niż 1 pominięta klatka na sekundę. Sesje kodowania AV1 są wymagane tylko do obsługi rozdzielczości 1080p, nawet jeśli wymagana jest rozdzielczość 4K.

Koniec nowych wymagań

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

Nowe wymagania dotyczące Androida 15

• [5.1/H-1-14] MUSI obsługiwać dekoder sprzętowy AV1 Main 10, poziom 4.1 oraz ziarnistość filmu z efektem ziarnistości filmu w ramach kompozycji GPU.

Koniec nowych wymagań

• [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 kodek wideo obsługujący 4K60.

Nowe wymagania dotyczące Androida 15

• [5.1/H-1-21] Musi obsługiwać FEATURE_DynamicColorAspect dla wszystkich dekoderów wideo sprzętowych (AVC, HEVC, VP9, AV1 lub nowszych). Uwaga: oznacza to, że aplikacje mogą aktualizować aspekty kolorów treści wideo podczas sesji dekodowania. Dekodery obsługujące treści 10- i 8-bitowe MUSZĄ obsługiwać dynamiczne przełączanie się między treściami 8- i 10-bitowymi w trybie Surface. Dekodery, które obsługują funkcję transferu HDR, MUSZĄ obsługiwać dynamiczne przełączanie między treściami SDR a HDR.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

• [5.1/H-1-22] MUSI obsługiwać kodowanie, dekodowanie, edycję na karcie graficznej i wyświetlanie treści wideo w formacie pionowym niezależnie od metadanych dotyczących obracania w przypadku największej obsługiwanej rozdzielczości kamery lub rozdzielczości 4K, zależnie od tego, która z nich jest mniejsza. Uwaga: obejmuje to profile HDR, jeśli kodek obsługuje HDR. Kodek AV1 jest wymagany tylko do obsługi rozdzielczości 1080p. Ten wymóg dotyczy tylko kodeków sprzętowych, procesorów graficznych i procesorów DPU.

Koniec nowych wymagań

• [5.3/H-1-1] W przypadku sesji wideo 4K 60 fps podczas wczytywania nie może wystąpić więcej niż 1 klatka na 10 sekund (czyli mniej niż 0,167% utraty klatek)
• [5.3/H-1-2] Nie wolno tracić więcej niż 1 klatki w ciągu 10 sekund podczas zmiany rozdzielczości w sesji wideo 60 kl./s podczas wczytywania sesji 4K.
• [5.6/H-1-1] Czas opóźnienia od dotknięcia do usłyszenia tonu nie może przekraczać 80 ms w ramach testu tap-to-tone w CTS Verifier.
• [5.6/H-1-2] Czas opóźnienia przesyłania i odbierania dźwięku musi wynosić 80 ms lub mniej na co najmniej jednej obsługiwanej ścieżce danych.
• [5.6/H-1-3] MUSI obsługiwać dźwięk 24-bitowy do wyjścia stereo 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 konfiguracji o niskiej latencji i strumieniowego przesyłania danych. W przypadku konfiguracji niskiego opóźnienia aplikacja powinna używać AAudio w trybie wywołania z niskim opóźnieniem. W przypadku konfiguracji strumieniowego przesyłania danych aplikacja powinna używać obiektu Java AudioTrack. Zarówno w przypadku konfiguracji z niską latencją, jak i konfiguracji strumieniowego przesyłania danych odbiornik wyjściowy HAL powinien akceptować format wyjściowy AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT lub AUDIO_FORMAT_PCM_FLOAT.

Nowe wymagania dotyczące Androida 15

• [5.6/H-1-4] MUSI obsługiwać urządzenia audio USB z powyżej 4 kanałami. (Używają go kontrolery DJ-a do podglądu utworów).

Koniec nowych wymagań

• [5.6/H-1-5] MUSI obsługiwać urządzenia MIDI zgodne z klasą i deklarować flagę funkcji MIDI.
• [5.6/H-1-9] MUSI obsługiwać miksowanie co najmniej 12 kanałów. Oznacza to możliwość otwarcia ścieżki audio z maską kanału 7.1.4 i prawidłowe zmapowanie lub zmapowanie w dół wszystkich kanałów do stereo.
• [5.6/H-SR] ZALECAMY obsługę miksowania 24 kanałów z co najmniej obsługą masek kanałów 9.1.6 i 22.2.
• [5.7/H-1-2] MUSI obsługiwać MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL z podanymi niżej możliwościami 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

• [5.1/H-1-17] MUSI mieć co najmniej 1 sprzętowy dekoder obrazów obsługujący profil podstawowy AVIF.
• [5.1/H-1-18] MUSI obsługiwać koder AV1, który może kodować do rozdzielczości 480p z szybkością 30 fps i 1 Mbps.

Nowe wymagania dotyczące Androida 15

• [5.1/H-1-20] MUSI obsługiwać funkcję Feature_HdrEditing dla wszystkich sprzętowych kodeków AV1 i HEVC obecnych na urządzeniu w rozdzielczości 4K lub największej rozdzielczości obsługiwanej przez kamerę, zależnie od tego, która z nich jest mniejsza.

Koniec nowych wymagań

• [5.12/H-SR] Zaleca się obsługę funkcji Feature_HdrEditing dla wszystkich koderów AV1 i HEVC na urządzeniu.
• [5.12/H-1-2] MUSI obsługiwać format kolorów RGBA_1010102 w przypadku wszystkich koderów AV1 i HEVC obecnych na urządzeniu.
• [5.12/H-1-3] MUST advertise support for the EXT_YUV_target extension to sample from YUV textures in both 8 and 10-bits.
• [7.1.4/H-1-1] W procesorze wyświetlacza (DPU) MUSI być co najmniej 6 przesłon sprzętowych, z których co najmniej 2 muszą obsługiwać wyświetlanie treści wideo 10-bitowych.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.V dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS i obsługują koder sprzętowy AVC lub HEVC, to:

Koniec nowych wymagań

• [5.2/H-2-1] MUSI spełniać minimalne wymagania dotyczące jakości zdefiniowane przez krzywe szybkości i zniekształceń kodera wideo dla kodeków AVC i HEVC na sprzęcie, zgodnie z testami jakości kodowania wideo (VEQ) w klasie wydajności 14 (PC14).

2.2.7.2. Aparat

Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.U dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• MUSI spełniać wymagania dotyczące multimediów wymienione w sekcji 2.2.7.2 Warunków korzystania z usługi w Androidzie 14.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń przenośnych zwracają wartość android.os.Build.VERSION_CODES.V w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

• [7.5/H-1-1] Urządzenie MUSI mieć główny tylny aparat o rozdzielczości co najmniej 12 Mpix, który umożliwia nagrywanie filmów w trybie 4K przy 30 FPS, 1080p przy 60 FPS i 720p przy 60 FPS. Główny tylny aparat to tylny aparat o najniższym identyfikatorze.

Koniec nowych wymagań

• [7.5/H-1-2] Urządzenie MUSI mieć przedni aparat o rozdzielczości co najmniej 6 Mpix i obsługiwać nagrywanie filmów w trybie 1080p przy 30 FPS. Główny aparat przedni to aparat przedni o najniższym identyfikatorze.
• [7.5/H-1-3] MUSI obsługiwać atrybuty android.info.supportedHardwareLevel jako FULL lub wyższą dla głównego tylnego aparatu oraz LIMITED lub wyższą dla 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] Czas oczekiwania na zrobienie zdjęcia JPEG w aparacie2 musi być krótszy niż 1000 ms w przypadku rozdzielczości 1080p, zmierzony za pomocą testu wydajności aparatu CTS w warunkach oświetlenia ITS (3000 K) w przypadku obu głównych aparatów.
• [7.5/H-1-6] Czas oczekiwania na uruchomienie aparatu 2 (od otwarcia aparatu do pierwszego podglądu obrazu) musi być mniejszy niż 500 ms, mierzony za pomocą testu wydajności aparatu CTS w warunkach oświetlenia ITS (3000 K) w przypadku obu aparatów głównych.
• [7.5/H-1-8] MUSI obsługiwać CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW i android.graphics.ImageFormat.RAW_SENSOR dla głównego tylnego aparatu.
• [7.5/H-1-9] Musi mieć tylną kamerę główną obsługującą rozdzielczość 720p lub 1080p przy 240 fps.
• [7.5/H-1-10] W przypadku aparatów głównych MUSISZ mieć minimalny współczynnik ZOOM_RATIO < 1.0, jeśli masz aparat ultraszerokokątny RGB skierowany w ten sam kierunek.
• [7.5/H-1-11] NALEŻY wdrożyć jednoczesne przesyłanie strumieniowe z przodu i z tyłu w przypadku kamer głównych.
• [7.5/H-1-12] Musi obsługiwać CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION zarówno w przypadku głównego przedniego, jak i głównego tylnego aparatu.
• [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 tylnia kamera RGB.
• [7.5/H-1-14] Musi obsługiwać funkcję STREAM_USE_CASE zarówno w przypadku głównego przedniego, jak i głównego tylnego aparatu.
• [7.5/H-1-15] MUSI obsługiwać rozszerzenia trybu nocnego za pomocą rozszerzeń CameraX i Camera2 dla głównych kamer.
• [7.5/H-1-16] MUSI obsługiwać opcję DYNAMIC_RANGE_TEN_BIT w przypadku kamer głównych.
• [7.5/H-1-17] MUSI obsługiwać CONTROL_SCENE_MODE_FACE_PRIORITY i wykrywanie twarzy (STATISTICS_FACE_DETECT_MODE_SIMPLE lub STATISTICS_FACE_DETECT_MODE_FULL) w przypadku aparatów głównych.

Nowe wymagania dotyczące Androida 15

• [7.5/H-1-18] Musi obsługiwać JPEG_R w przypadku głównego tylnego i głównego przedniego aparatu.
• [7.5/H-1-19] MUSI obsługiwaćCONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION podgląd HLG10 w 1080p z JPEG-em o maksymalnej rozdzielczości 16:9 oraz podgląd HLG10 w 720p z JPEG-em o maksymalnej rozdzielczości 16:9 w przypadku głównej kamery tylnej.
• [7.5/H-1-20] W domyślnej aplikacji aparatu wyjście JPEG_R musi być domyślnie ustawione dla głównego tylnego i głównego przedniego aparatu.

Koniec nowych wymagań

2.2.7.3. Sprzęt

Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.U dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• MUSI spełniać wymagania dotyczące multimediów wymienione w sekcji 2.2.7.3 Warunków korzystania z usługi Androida 14.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń przenośnych zwracają wartość android.os.Build.VERSION_CODES.V w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

Koniec nowych wymagań

• [7.1.1/H-2-1] Rozdzielczość ekranu MUSI wynosić co najmniej 1080p.

Nowe wymagania dotyczące Androida 15

• [7.1.1.3/H-2-1] NALEŻY mieć gęstość ekranu co najmniej 400 dpi, jeśli szerokość ekranu urządzenia jest mniejsza niż 600 dp.

Koniec nowych wymagań

• [7.1.1.3/H-3-1] Wymagana jest obsługa wyświetlacza HDR o średniej jasności co najmniej 1000 nit.

Nowe wymagania dotyczące Androida 15

• [7.6.1/H-2-1] Musi mieć co najmniej 8 GB pamięci fizycznej, z co najmniej 6,64 GB dostępnej dla jądra, zgodnie z informacjamiandroid.app.ActivityManager.MemoryInfo.totalMem.

Koniec nowych wymagań

2.2.7.4. Wydajność

Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.U dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• Musi spełniać wymagania dotyczące wydajności wymienione w sekcji 2.2.7.4 Warunków dystrybucyjnych Androida 14.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń przenośnych zwracają wartość android.os.Build.VERSION_CODES.V w przypadku android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

Koniec nowych wymagań

• [8.2/H-1-1] MUSI zapewnić wydajność zapisu sekwencyjnego co najmniej 150 MB/s.
• [8.2/H-1-2] MUSI zapewnić wydajność zapisu losowego 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] NALEŻY zapewnić wydajność losowego odczytu na poziomie co najmniej 100 MB/s.
• [8.2/H-1-5] MUSI zapewnić równoległą sekwencyjną wydajność odczytu i zapisu z 2 x wydajnością odczytu i 1 x wydajnością zapisu co najmniej 50 MB/s.

Nowe wymagania dotyczące Androida 15

2.2.7.5. Grafika

Jeśli implementacje na urządzeniach przenośnych zwracają wartość android.os.Build.VERSION_CODES.V dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• [7.1.4.1/H-1-2] MUSI obsługiwać rozszerzenia EGL_IMG_context_priority i EGL_EXT_protected_content.
• [7.1.4.1/H-1-3] MUSI obsługiwać VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory i VK_KHR_global_priority.

Koniec nowych wymagań

2.3. Wymagania dotyczące telewizorów

Urządzenie Android TV to implementacja urządzenia z Androidem, która jest interfejsem rozrywkowym do korzystania z multimediów, filmów, gier, aplikacji lub telewizji na żywo dla 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 danych prywatnych 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:

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

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
• [5.3.2/T-0-7] AV1

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ą deinterlować 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 (głębia kolorów 8 bitó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 szybkoś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 na najwyższą rozdzielczość dla wybranego formatu pikseli, który działa z częstotliwością odświeżania 50 Hz lub 60 Hz dla wyświetlacza zewnętrznego, w zależności od regionu, w którym sprzedawane jest urządzenie.
• [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 i android.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 zapewnić pełną implementację interfejsu 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 multimediów.

Implementacje na telewizorach:

• [3.8.14/T-SR-1] ZALECAMY obsługę trybu 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ą tę funkcję, android.hardware.audio.output:

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

Nowe wymagania dotyczące Androida 15

Implementacje na telewizorach:

• [3.12/T-0-1] MUSI obsługiwać platformę TV Input Framework.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

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.

Implementacje na telewizorach:

• [3/T-0-2] NALEŻY zadeklarować funkcję platformy.android.software.live_tv
• [3/T-0-3] MUSI obsługiwać wszystkie interfejsy TIF, tak aby można było zainstalować aplikację, która korzysta z tych interfejsów i z zewnętrznych danych wejściowych opartych na TIF, a następnie z niej korzystać na urządzeniu.

Framework tunera Androida TV (TF) umożliwia jednolite zarządzanie treściami na żywo z tunera i treściami strumieniowymi z adresu IP na urządzeniach z Androidem TV. Tuner Framework udostępnia standardowy interfejs API do tworzenia usług wejściowych, które korzystają z tunera Android Television.

Jeśli implementacje urządzeń obsługują Tuner, mogą:

• [3/T-1-1] MUSI obsługiwać wszystkie interfejsy API Tuner Framework, aby można było zainstalować aplikację korzystającą z tych interfejsów i z niej korzystać na urządzeniu.

Koniec nowych wymagań

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ść sekwencyjnego zapisu 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żytkownikowi 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 dla dewelopera aplikacji.

2.3.5. Model zabezpieczeń

Implementacje na telewizorach:

• [9/T-0-1] NALEŻY zadeklarować funkcję android.hardware.security.model.compatible.
• [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 przez system Android Keystore 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/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.

Nowe wymagania dotyczące Androida 15

• [9.11/T-0-4] MUSI obsługiwać atestację klucza, w której klucz do podpisywania atesta jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane na bezpiecznym sprzęcie. Klucze podpisywania zaświadczeń MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako trwałych 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 kodu SKU, dla każdej grupy 100 tys. jednostek MOŻE być używany inny klucz.

  Uwaga: aby spełnić to wymaganie, musisz udostępnić ten sam klucz uwierzytelniający dla danego kodu SKU,chyba że wyprodukowano co najmniej 100 tys. jego sztuk. Jeśli wyprodukowano ponad 100 tys. sztuk danego kodu SKU, w przypadku każdej kolejnej grupy 100 tys. sztuk MOŻE być używany inny klucz. Możesz też użyć rozwiązania do zdalnego udostępniania kluczy, aby udostępnić na urządzeniu klucze poświadczania o krótkim czasie ważności.

Koniec nowych wymagań

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 niezablokowanego stanu do zablokowanego, przy czym dopuszczalny czas bezczynności nie może być dłuższy niż 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 włączać i wyłączać dostęp innych użytkowników do połączeń głosowych i SMS-ów.

Jeśli implementacje urządzeń telewizyjnych deklarują android.hardware.microphone, to:

• [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. Dostęp do mikrofonu (CDD) z identyfikatorem 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 o rolach wymienionych 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

Nowe wymagania dotyczące Androida 15

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 podać w pliku binarnym perfetto co najmniej te źródła danych, które są opisane w dokumentacji perfetto.
  • [6.1/T-0-5] Demon śledzenia perfetto MUSI być włączony domyślnie (właściwość systemowa persist.traced.enable).

Koniec nowych wymagań

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 urządzeń 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] NALEŻY zgłaszać pseudozakresy i pseudozakresy GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, w stanie nieruchomym lub w ruchu z przyspieszeniem poniżej 0,2 metra na sekundę kwadratową, wystarczają do obliczenia pozycji z dokładnością do 20 metrów oraz prędkości z dokładnością do 0,2 metra na sekundę w co najmniej 95% czasu.

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] W przypadku wszystkich publicznych wzorów filtra intencji zdefiniowanych przez te aplikacje z intencją, które są wymienione tutaj, MUSISZ wstępnie załadować co najmniej jedną aplikację lub komponent usługi z obsługą intencji.

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ć usługi dostępności innych firm.
• [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ą dostępne w AOSP, lub rozszerzają funkcje dostępne w AOSP, muszą:

• [8.3/W-SR-1] WYJŚCIE Z ZALECENIA z zastosowaniem opcji wyświetlania wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.
• [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 innym użytkownikom do połączeń głosowych i SMS-ów.

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:

• [9.11.1/W-1-1] NALEŻY poprosić użytkownika o podanie danych uwierzytelniania za pomocą jednej z zalecanych metod uwierzytelniania podstawowego (np. kodu PIN, wzoru lub hasła) częściej niż raz na 72 godziny.

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 x 480 dp.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń Automotive obsługują równoczesną pracę wielu użytkowników (gdzie wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnego wyświetlacza, gdy włączona jest opcja config_multiuserVisibleBackgroundUsers), to:

• [7.1.1.1/A-1-1] Musisz mieć osobny ekran o przynajmniej 15 cm przekątnej dla każdego pasażera na wyświetlaczu głównym. W przypadku każdej strefy dla pasażera należy użyć tagu CarOccupantZoneManager.DISPLAY_TYPE_MAIN.
• [7.1.1.1/A-1-2] Rozmiar ekranu musi wynosić co najmniej 750 dp x 480 dp na każdym głównym wyświetlaczu.

Koniec nowych wymagań

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.

Implementacje na urządzeniach samochodowych:

Nowe wymagania dotyczące Androida 15

• [7.1.7/A-0-1] Wyświetlacze dodatkowe MUSZĄ być skonfigurowane w polu widzenia kierowcy jako FLAG_PRIVATE.

Koniec nowych wymagań

• [7.2.3/A-0-1] MUSI zawierać funkcję Wróć do ekranu głównego 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 and PARKING_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. Używany czujnik światła otoczenia MOŻE być taki sam jak fotometry.

• [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ę przez złączenie GPS/GNSS z dodatkowymi czujnikami. 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] Lokalizacja wymagana przez 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.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń Automotive obsługują równoczesną pracę wielu użytkowników (gdzie wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnego wyświetlacza, gdy włączona jest opcja config_multiuserVisibleBackgroundUsers), to:

• [7.3/A-1-1] Musisz ustawić wartość flagi NIGHT_MODE zgodnie z trybem dnia/nocy na desce rozdzielczej na wszystkich wyświetlaczach, w tym na wyświetlaczach na tylnych siedzeniach.

Koniec nowych wymagań

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 zgłaszać 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 POLECAMY 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] MUSI określić lokalizację za pierwszym razem, gdy odbiornik GPS/GNSS zostanie włączony, lub po 4 dniach (lub więcej) 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ć możliwe raportowanie zdarzeń 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).

Nowe wymagania dotyczące Androida 15

• [7.4.3/A-SR-1] W przypadku urządzeń z funkcją strefy kierowcy MOCNO zaleca się obsługę profilu dostępu do wiadomości (MAP).

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń Automotive obsługują równoczesną pracę wielu użytkowników (gdzie wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnego wyświetlacza, gdy włączona jest opcja config_multiuserVisibleBackgroundUsers), to:

• [7.4.3/A-1-1] MUSI być niezależny i NIE może zakłócać korzystania z BT przez innych użytkowników.

Koniec nowych wymagań

Implementacje na urządzeniach samochodowych:

• [7.4.5/A] NALEŻY uwzględnić obsługę połączeń danych w sieci komórkowej.
• [7.4.5/A] Możesz używać interfejsu System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID w przypadku sieci, które powinny być dostępne dla aplikacji systemowych.

Jeśli implementacje urządzeń obejmują obsługę radia AM/FM i udostępniają tę funkcję dowolnej aplikacji, muszą:

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

Tylny aparat to aparat skierowany na zewnątrz, który może znajdować się w dowolnym miejscu pojazdu i skierowany jest na zewnątrz kabiny. Oznacza to, że rejestruje on obrazy po przeciwnej stronie nadwozia pojazdu, tak jak tylna kamera.

Przedni aparat to kamera skierowana na użytkownika, która może znajdować się w dowolnym miejscu w samochodzie i jest skierowana do wnętrza kabiny. Może ona rejestrować obraz użytkownika, np. w przypadku konferencji wideo i podobnych aplikacji.

Implementacje na urządzeniach samochodowych:

• [7.5/A-SR-1] MOCNO ZALECAMY, aby uwzględnić co najmniej 1 kamerę skierowaną na zewnątrz.
• MOŻE zawierać co najmniej 1 kamerę skierowaną na użytkownika.
• [7.5/A-SR-2] ZALECAMY, aby obsługiwać jednoczesne przesyłanie strumieniowe z wielu kamer.

Jeśli implementacje urządzeń samochodowych obejmują co najmniej 1 kamerę skierowaną na zewnątrz, to w przypadku takiej kamery:

• [7.5/A-1-1] MUSI być zorientowany tak, aby dłuższy wymiar kamery był zgodny z płaszczyzną XY osi czujnika samochodowego Androida.
• [7.5/A-SR-3] MOCNO zalecamy posiadanie sprzętu z ostrzością stałą lub EDOF (rozszerzoną głębią ostrości).
• [7.5/A-1-2] Główna kamera skierowana na świat musi być kamerą skierowaną na świat o najniższym identyfikatorze.

Jeśli implementacje urządzeń samochodowych obejmują co najmniej 1 kamerę skierowaną na użytkownika, w przypadku takiej kamery:

• [7.5/A-2-1] Główny aparat skierowany na użytkownika MUSI być aparatem skierowanym na użytkownika z najniższym identyfikatorem kamery.
• MOŻE być ustawiony tak, aby dłuższy wymiar kamery był zgodny z płaszczyzną XY osi czujnika samochodowego Androida.

Jeśli implementacje urządzeń samochodowych obejmują kamerę, do której można uzyskać dostęp za pomocą interfejsu API android.hardware.Camera lub android.hardware.camera2, to:

• [7.5/A-3-1] MUSI spełniać podstawowe wymagania dotyczące aparatu podane w sekcji 7.5.

Jeśli implementacje urządzeń samochodowych obejmują kamerę, do której nie można uzyskać dostępu za pomocą interfejsu API android.hardware.Camera ani android.hardware.camera2, to:

• [7.5/A-4-1] MUSI być dostępny za pomocą usługi Extended View System.

Jeśli w implementacjach urządzeń samochodowych jest co najmniej 1 kamera dostępna za pomocą usługi systemowej Extended View, to:

• [7.5/A-5-1] Nie wolno obracać ani odbijać poziomo podglądu kamery.
• [7.5/A-SR-4] MOCNO ZALECAMY, aby rozdzielczość wynosiła co najmniej 1,3 Mpix.

Jeśli implementacje urządzeń samochodowych obejmują co najmniej 1 aparat, do którego można uzyskać dostęp za pomocą interfejsu Extended View System Service i interfejsu API android.hardware.Camera lub android.hardware.Camera2, to w przypadku takiego aparatu:

• [7.5/A-6-1] MUST report the same Camera ID.

Jeśli implementacje urządzeń samochodowych udostępniają firmowe interfejsy API aparatu, muszą:

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

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 (partycja /data).

• [7.6.1/A] NALEŻY sformatować partycję danych, aby zwiększyć wydajność i trwałość pamięci masowej 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 pamięci wewnętrznej, która nie jest wymienna, 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ą funkcji SDCardFS.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń Automotive obsługują równoczesną pracę wielu użytkowników (gdzie wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnego wyświetlacza, gdy włączona jest opcja config_multiuserVisibleBackgroundUsers), to:

• [7.6.1/A-1-1] W jednym wystąpieniu AAOS MUSI być co najmniej 4 GB pamięci nieulotnej dostępnej dla każdego użytkownika Androida, która jest używana do przechowywania danych prywatnych aplikacji (partycja /data).

Koniec nowych wymagań

Jeśli implementacje urządzeń samochodowych są 64-bitowe:

Nowe wymagania dotyczące Androida 15

• [7.6.1/A-2-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 816 MB na główny wyświetlacz, 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 ekranach bardzo dużych
  • 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 na główny wyświetlacz, 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 na główny ekran, 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 na główny ekran, 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.

Powyższy opis „pamięci dostępnej 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.

Koniec nowych wymagań

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.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń Automotive obsługują równoczesną pracę wielu użytkowników (gdzie wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnego wyświetlacza, gdy włączona jest opcja config_multiuserVisibleBackgroundUsers), to:

• [7.8.2/A-1-1] W przypadku systemów z wieloma użytkownikami na każdym głównym ekranie MUSI być urządzenie wyjściowe audio.
• [7.8.2/A-1-2] W strefie dźwiękowej kierowcy MUSI znajdować się głośnik globalny w całości kabiny. Strefa przedniego pasażera może korzystać z strefy dźwiękowej kierowcy lub mieć własne wyjście audio.

Koniec nowych wymagań

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 wideo i udostępniać je aplikacjom innych firm:

• [5.2/A-0-1] H.264 AVC
• [5.2/A-0-2] VP8

Implementacje urządzeń samochodowych MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

• [5.3/A-0-1] H.264 AVC
• [5.3/A-0-2] MPEG-4 SP
• [5.3/A-0-3] VP8
• [5.3/A-0-4] VP9

W przypadku implementacji urządzeń samochodowych MOCNO zalecamy obsługę tych formatów dekodowania wideo:

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

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń Automotive obsługują równoczesną pracę wielu użytkowników (gdzie wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnego wyświetlacza, gdy włączona jest opcja config_multiuserVisibleBackgroundUsers), to:

• [5.5.3/A-1-1] NALEŻY zdefiniować identyczne krzywe głośności dla wszystkich strumieni wyjściowych audio mapowanych na tę samą grupę głośności, jaką określono w pliku konfiguracyjnym dźwięku samochodu.

Koniec nowych wymagań

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ą firmowe interfejsy 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ącej uprawnień w przypadku pojazdów.

• [3.2.3.1/A-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/A-0-1] Musisz wdrożyć pełną implementację interfejsu API android.webkit.Webview.

Nowe wymagania dotyczące Androida 15

• [3.8/A-0-1] Nie zezwalaj użytkownikom dodatkowym, którzy nie są bieżącymi użytkownikami na pierwszym planie, na uruchamianie działań i dostęp do interfejsu na żadnych wyświetlaczach.

Jeśli implementacje urządzeń Automotive obsługują równoczesną pracę wielu użytkowników (gdzie wielu użytkowników Androida może jednocześnie korzystać z urządzenia, każdy z własnego wyświetlacza, gdy włączona jest opcja config_multiuserVisibleBackgroundUsers), to:

• [3.8/A-1-1] MUSISZ zaimplementować następującą wstępnie zdefiniowaną listę UserRestrictions dla pełnych użytkowników dodatkowych, którzy nie są bieżącym użytkownikiem na pierwszym planie, ale mają dostęp do interfejsu wyświetlacza przypisanego do nich. Lista wartości UserRestrictions: DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE i DISALLOW_MICROPHONE_TOGGLE.

• [3.8/A-1-2] NIE NALEŻY zezwalać użytkownikom drugorzędnym, którzy nie są bieżącymi użytkownikami na pierwszym planie, ale mają dostęp do interfejsu wyświetlacza przypisanego do nich, na pełną zmianę trybu dzień/noc, lokalizacji, daty, czasu, strefy czasowej ani funkcji wyświetlania kolorów (w tym jasności, trybu Night Light, funkcji Digital Wellbeing w skalach szarości i zmniejszania jasnych kolorów) dla innych użytkowników za pomocą ustawień lub interfejsu API.

Koniec nowych wymagań

Implementacje na urządzeniach samochodowych:

• [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] MUSI wyświetlać opcje odtwarzania i wyciszenia dla działań powiadomienia zamiast tych udostępnianych przez 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 intencyjne CAR_INTENT_ACTION_MEDIA_TEMPLATE z dodatkowym parametrem CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] MUSI zapewniać możliwość przejścia do aktywności preferencji aplikacji multimedialnej, ale TYLKO wtedy, gdy nie obowiązują ograniczenia 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 i ERROR_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 i CONTENT_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] Możesz mieć zawsze widoczny pasek stanu i pasek nawigacyjny.
• [3.8/A] MOŻE ograniczać prośby aplikacji o zmianę kolorów elementów interfejsu systemu, aby zapewnić ich dobrą widoczność przez cały czas.

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 APIandroid.car.storagemonitoring.CarStorageMonitoringManager. Projekt Android Open Source spełnia to wymaganie dzięki modułowi jądra uid_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 APLIKACJI MUSI udostępnić tę wartość za pomocą polecenia adb shell dumpsys batterystats w powłoce.

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] NALEŻY przełączyć się na użytkownika dodatkowego przed BOOT_COMPLETED.
• [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.microphone, to:

• [9.8.2/A-1-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/A-1-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.
• [9.8.2/A-1-3] MUSISZ umożliwić użytkownikowi przełączanie mikrofonu w aplikacji Ustawienia.

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 pełniące role zdefiniowane w sekcji 9.1 Uprawnienia z identyfikatorem CDD [C-4-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.
• [9.8.2/A-2-3] MUSISZ umożliwić użytkownikowi przełączanie kamery w aplikacji Ustawienia.
• [9.8.2/A-2-4] MUSI wyświetlać Ostatnie i Aktywne aplikacje przy użyciu aparatu zgodnie z informacjami z PermissionManager.getIndicatorAppOpUsageData() oraz wszelkie powiązane z nimi komunikaty dotyczące atrybucji.

Implementacje na urządzeniach samochodowych:

• [9/A-0-1] NALEŻY zadeklarować funkcję android.hardware.security.model.compatible.
• [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 Android Keystore 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.

Nowe wymagania dotyczące Androida 15

• [9.11/A-0-4] MUSI obsługiwać atestacjowanie klucza, w którym klucz podpisujący jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania atestacyjnym MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby zapobiec ich wykorzystaniu w celu trwałego identyfikowania 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 kodu SKU, dla każdej grupy 100 tys. jednostek MOŻE być używany inny klucz.

  Uwaga: aby spełnić to wymaganie, musisz udostępnić ten sam klucz uwierzytelniający dla danego kodu SKU,chyba że wyprodukowano co najmniej 100 tys. jego sztuk. Jeśli wyprodukowano ponad 100 tys. sztuk danego kodu SKU, w przypadku każdej kolejnej grupy 100 tys. sztuk MOŻE być używany inny klucz. Możesz też użyć rozwiązania do zdalnego udostępniania kluczy, aby udostępnić na urządzeniu klucze poświadczania o krótkim czasie ważności.

Koniec nowych wymagań

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ążeniu sieci pojazdu przez złośliwe oprogramowanie, które może spowodować nieprawidłowe działanie podsystemów pojazdu.

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

Nowe wymagania dotyczące Androida 15

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] Binarny plik 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-5] Demon śledzenia perfetto MUSI być włączony domyślnie (właściwość systemowa persist.traced.enable).

Koniec nowych wymagań

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 ilość pamięci i miejsca 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.

Nowe wymagania dotyczące Androida 15

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

Koniec nowych wymagań

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 udokumentowane zachowania, dowolnego udokumentowanego interfejsu API udostępnionego przez pakiet SDK Androida lub dowolnego interfejsu API ozdobionego znacznikiem „@SystemApi” w górnym 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] MUSI obsługiwać sygnaturę konfiguracji, aby za pomocą mechanizmu aktualizacji dynamicznej usuwać interfejsy inne niż SDK z listy ograniczeń. W tym celu należy umieścić podpisaną konfigurację w dowolnym pliku APK, używając istniejących kluczy publicznych obecnych w AOSP.

  Jednak:

  • W MAJA, jeśli ukryty interfejs API jest nieobecny lub jest inaczej zaimplementowany na urządzeniu, przenieś ukryty interfejs API na listę zablokowanych lub pomiń go na wszystkich listach ograniczeń.
  • W MAJA, jeśli ukryty interfejs API nie istnieje już w AOSP, dodaj go do dowolnej z list ograniczonych.

Nowe wymagania dotyczące Androida 15

• [C-0-8] NIE MOŻE obsługiwać instalowania aplikacji kierowanych na poziom interfejsu API poniżej 23 24.

Koniec nowych wymagań

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. Interfejs API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) zwraca wersję rozszerzenia podana w parametrze apiLevel, jeśli są dostępne rozszerzenia dla tego poziomu interfejsu API.

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ług ExtServices 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 na urządzeniach:

• [C-0-1] NIE WYMAGA 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> na org.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 wymienionych w sekcji 3.1 Android zawiera też „miękkie” interfejsy API, które są używane tylko w czasie działania. Dotyczy to na przykład intencji, uprawnień i podobnych aspektów aplikacji na Androida, 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 poświęconej uprawnieniom. Pamiętaj, że sekcja 9 zawiera dodatkowe wymagania dotyczące modelu zabezpieczeń Androida.

3.2.2. Parametry budowy

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 zdefiniowanych w dozwolonych ciągach wersji na potrzeby Androida 15.
WERSJ.SDK	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 15 to pole MUSI zawierać wartość całkowitą 15_INT.
VERSION.SDK_INT	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 15 to pole MUSI mieć wartość całkowitą 15_INT.
VERSION.INCREMENTAL	Wartość wybrana przez implementatora urządzenia, która określa wersję systemu Androida w konkretnej implementacji 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 odpowiadać wyrażeniu regularnemu ^[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ć kodowalna jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym ^[a-zA-Z0-9_-]+$.
OBUDOWYWANE ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność natywnego interfejsu API.
OBUDOWYWANE_32_BITOWE_ABIE	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność natywnego interfejsu API.
OBIETNICZONE_64_-BITOWE_ ABISY	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ć możliwa do zakodowania w 7-bitowym formacie ASCII i musi być zgodna z wyrażeniem regularnym ^[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)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Przykład: acme/myproduct/     mydevice:15/LMYXX/3359:userdebug/test-keys 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 odpowiadać wyrażeniu regularnemu ^[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ść na tyle zrozumiałą dla użytkowników, aby mogli oni odróżnić różne wersje oprogramowania. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym ^[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 nie może zawierać pustego ciągu znaków (""). To pole NIE MOŻE się zmieniać w trakcie trwania produktu.
SOC_MANUFACTURER	Nazwa handlowa producenta głównego układu systemowego (SOC) używanego w produkcie. Urządzenia z tym samym producentem układu 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 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 cyklu życia 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 pasować do wyrażenia regularnego ^([0-9A-Za-z ._/+-]+)$. Nie może się zaczynać ani kończyć odstępem ani nie może być równa „unknown”. To pole NIE MOŻE się zmienić w trakcie trwania cyklu życia 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 całego okresu istnienia 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 odpowiadać wyrażeniu regularnemu ^[a-zA-Z0-9_-]+$. Nazwa tego produktu NIE MOŻE się zmienić w trakcie jego trwania.
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ć kodowalne jako 7-bitowe dane ASCII, MUSZĄ być zgodne z wyrażeniem regularnym ^[a-zA-Z0-9._-]+ i MUSZĄ mieć 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ących 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 nie może zawierać pustego ciągu znaków („"”).
SECURITY_PATCH	Wartość wskazująca poziom aktualizacji zabezpieczeń danej kompilacji. Musi ono oznaczać, ż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 na temat zabezpieczeń Androida lub w  poradniku na temat zabezpieczeń Androida, 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ć kodowalna jako 7-bitowy kod ASCII i zgodna z wyrażeniem regularnym ^[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 radia/modemu wewnętrznego, musi zwrócić wartość NULL. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i odpowiadać wyrażeniu regularnemu ^[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 musi być zgodna z wyrażeniem regularnym ^[a-zA-Z0-9]+$.

3.2.3. Zgodność z zamiarem

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 każdy wzór intencji wymieniony w sekcji 3.2.3.1, z wyjątkiem ustawień, które mogą być zastąpione przez aplikacje innych firm. 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 w szczególności wyłączenie interfejsu „Wybór”, który umożliwia użytkownikowi wybór spośród wielu aplikacji, które obsługują 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 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 deklaracje autoryzowane 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 kroki weryfikacji 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ć określone 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 ten sposób:
  • [C-0-6] Użytkownik MUSI mieć możliwość globalnego zastąpienia domyślnego zachowania linków aplikacji, aby aplikacja działała w jednym z tych trybów: zawsze otwieraj, zawsze pytaj lub nigdy nie otwieraj, co musi 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 znaków 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ą ciągu znaków ACTION, CATEGORY lub innego ciągu klucza 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 korzystające z przestrzeni nazw wyraźnie powiązanych z daną 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 wdrożenia urządzeń zgłaszają android.hardware.telephony.calling, to:

• [C-2-1] Musisz udostępnić menu ustawień, które wywołuje 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_DIALERintencję 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 z PhoneAccounts, 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ć na android.telecom.CallRedirectionService.

• [C-2-5] NALEŻY umożliwić użytkownikowi wybranie aplikacji, która ma android.app.role.CALL_REDIRECTIONrolę.

• [C-2-6] Musisz obsługiwać intencje android.intent.action.SENDTO i android.intent.action.VIEW oraz udostępniać aktywność do wysyłania i wyświetlania 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] Musi 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ć android.settings.ACCESSIBILITY_SETTINGSintencję zapewnienia 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] NALEŻY 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 implementacja na urządzeniu nie zapewnia trybu oszczędzania danych, urządzenie:

• [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 i MediaStore.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 i AutofillManager 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 fabrycznie zainstalowaną aplikację lub jeśli chcesz zezwolić aplikacjom innych firm na dostęp do statystyk użytkowania, musisz:

• [C-SR-2] Zdecydowanie 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 w przypadku aplikacji, które deklarują uprawnienie android.permission.PACKAGE_USAGE_STATS.

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ć ją jako no-op, czyli tak, aby miała 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.

Jeśli implementacje na urządzeniu obsługują interfejs VoiceInteractionService i mają zainstalowaną 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] BARDZO ZALECAMY 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 nazywaliśmy „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.

Jeśli implementacje urządzeń zgłaszają android.hardware.nfc.uicc lub android.hardware.nfc.ese, to:

• [C-19-1] OBOWIĄZKOWO zaimplementuj interfejs NfcAdapter.ACTION_TRANSACTION_DETECTED API (jako „EVT_TRANSACTION” zdefiniowany w specyfikacji technicznej GSM Association TS.26 – Wymagania dotyczące telefonu z NFC).

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ż jednym wyświetlaczu, 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, 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ą biblioteką (w przypadku interfejsu ABI) z każdą wymaganą biblioteką 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, and android.os.Build.SUPPORTED_64_BIT_ABIS parameters, each a comma separated list of ABIs ordered from the most to the least preferred one.

Nowe wymagania dotyczące Androida 15

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

Koniec nowych wymagań

• [C-0-7] Musisz udostępnić aplikacjom zawierającym kod natywny następujące biblioteki, które udostępniają natywne interfejsy API:

  • 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 (natywna obsługa 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.1, a także rozszerzeń VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 i VK_KHR_get_physical_device_properties2 za pomocą biblioteki libvulkan.so. Pamiętaj, że chociaż wszystkie symbole MUSZĄ być obecne, sekcja 7.1.4.2 zawiera bardziej szczegółowe wymagania dotyczące pełnej implementacji poszczególnych funkcji.

• NALEŻY go skompilować, używając kodu źródłowego i plików nagłówków 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 implementacji interfejsu API android.webkit.WebView w ramach projektu Chromium MUSISZ użyć kompilacji projektu źródeł Androida w ramach projektu Android Open Source na gałęzi Androida 15.

• [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:
  • pamięć podręczna aplikacji/operacja offline
  • tag<video>
  • geolocation
• [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 zgodność behawioralna interfejsu 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ądzeń.

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 konkretne 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 i GnssNavigationMessage.
  • [C-0-5] NALEŻY ograniczyć częstotliwość aktualizacji przesyłanych do aplikacji za pomocą klasy interfejsu API LocationManager lub metody WifiManager.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 dla niejawnych transmisji standardowych intencji Androida w pliku manifestu aplikacji, chyba że intencja transmisji 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-11] Urządzenia MUSZĄ zwracać wymienionych dostawców zabezpieczeń jako pierwsze 7 wartości tablicy z metody Security.getProviders() w podanej kolejności i z podanymi nazwami (zwracanymi przez Provider.getName()) oraz klasami, chyba że aplikacja zmodyfikowała listę za pomocą metody insertProviderAt() lub removeProvider(). Urządzenia mogą zwracać dodatkowych dostawców po wskazanej liście dostawców poniżej.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround – android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore –android.security.keystore.AndroidKeyStoreProvider

Powyższa lista nie jest wyczerpująca. 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 należy 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 je wyłączył, 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ć, czyniąc ją 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 zostać 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 ten czas 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 poprzednim 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 pakietów (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 utrwalenie 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ą Androida źródłowego 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ń MOGĄ 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ń zezwalają aplikacjom innych firm na zastąpienie ekranu głównego urządzenia, 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 metody PackageManager są wywoływane w celu pobrania ikon.

Jeśli implementacje urządzeń obejmują domyślny program uruchamiający, który obsługuje przypinanie skrótów w aplikacji, muszą one:

• [C-2-1] MUST report true for ShortcutManager.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 for ShortcutManager.isRequestPinShortcutSupported().

Jeśli implementacje urządzeń korzystają z domyślnego menu uruchamiającego, 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 dla ikon 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 na true, i nie wyświetlaj żadnego schematu plakietki ikony aplikacji, jeśli wartość wszystkich kanałów powiadomień aplikacji jest ustawiona na false.
• 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() i Notification.Builder.setBadgeIconType().

Jeśli implementacje na urządzeniach obsługują ikony monochromatyczne, te ikony:

• [C-6-1] MUSI być używany tylko wtedy, gdy użytkownik wyraźnie go włączy (np. w menu Ustawienia lub selektorze tapety).

3.8.2. Widżety

Android obsługuje widżety aplikacji innych firm, definiując typ komponentu i odpowiednie 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 i zapewnić użytkownikom możliwości dodawania, konfigurowania, wyświetlania i usuwania widżetów aplikacji w interfejsie użytkownika.
• [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 for AppWidgetManager.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).

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 wdrażać 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 w pasku stanu/systemowym, mimo że 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] Musisz umożliwić użytkownikowi blokowanie i modyfikowanie powiadomień aplikacji innej firmy na poziomie każdego kanału i poziomu pakietu aplikacji.
• [C-1-6] Musisz też zapewnić użytkownikom możliwość wyświetlania 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 ZALECAMY, aby umożliwić użytkownikowi kontrolowanie powiadomień wyświetlanych aplikacjom, które mają uprawnienia 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 wiadomościach to powiadomienia wyświetlane użytkownikowi w chwili ich otrzymania niezależnie od tego, z czego korzysta. Jeśli implementacje urządzeń obsługują powiadomienia typu heads-up:

• [C-3-1] NALEŻY używać widoku powiadomienia z poprzednim powiadomieniem i zasobów opisanych w klasie interfejsu API Notification.Builder, gdy wyświetlane są powiadomienia z poprzednim powiadomieniem.
• [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 w przypadku wszystkich zainstalowanych usług odsłuchiwania, które są włączone przez użytkownika, w tym wszystkich metadanych dołączonych do obiektu powiadomienia.
• [C-0-2] MUSI obsługiwać wywołanie interfejsu API snoozeNotification(), zamykać powiadomienie i wywoływać ponownie 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 udostępnić użytkownikom możliwość odłożenia 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ść przyznania lub odmowy dostępu aplikacjom innych firm do konfiguracji zasad DND, wyświetlać automatyczne zasady DND utworzone przez aplikacje obok zdefiniowanych przez użytkownika i wstępnie zdefiniowanych zasad.
• [C-1-3] MUSI uwzględniać wartości suppressedVisualEffects przekazywane w NotificationManager.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ć.

Nowe wymagania dotyczące Androida 15

3.8.3.4. Ochrona powiadomień poufnych

Poufne informacje w powiadomieniach obejmują hasła jednorazowe, jednorazowe kody potwierdzenia i podobne kody uwierzytelniające lub resetowania, które mogą pojawiać się w powiadomieniach wysyłanych do użytkowników.

Jeśli implementacje urządzeń zezwalają aplikacjom innych firm na powiadamianie użytkowników o istotnych zdarzeniach, mogą:

• [C-1-1] NALEŻY usunąć poufne informacje z powiadomienia przed przekazaniem ich odbiorcom powiadomień, chyba że usługa odbiorcza jest jedną z tych:

  • Aplikacje podpisane przez system z uid < 10000
  • interfejs systemu
  • Pudrowy róż
  • Wyznaczona aplikacja na urządzeniu towarzyszącym (zdefiniowana przez CompanionDeviceManager)
  • SYSTEM_AUTOMOTIVE_PROJECTION rola
  • SYSTEM_NOTIFICATION_INTELLIGENCE rola
  • Rola DOM

Implementacja AOSP w NotificationAssistantServices spełnia te wymagania. Przykład znajdziesz w sekcji android.ext.services.notification.

Koniec nowych wymagań

3.8.4. Interfejsy API do pomocy

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ń komend głosowych 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] NALEŻY 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 całej aplikacji.

Android zawiera rodziny motywów „Holo” i „Material” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i wykonanie motywu Holo do 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 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 (patrz android.theme.customization.system_palette i android.theme.customization.theme_style).

• [C-1-5] NALEŻY wygenerować dynamiczne palety barw za pomocą stylów motywów kolorów wymienionych w dokumentacji Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (patrz android.theme.customization.theme_styles), a mianowicie TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD i MONOCHROMATIC.

  „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 dokumentacji Settings.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 na problem 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 jednej tapety na żywo. 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 klatek i bez negatywnego wpływu na inne aplikacje. 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 obsługi tapety 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 przez Ciebie kod źródłowy Androida obejmuje ekran przeglądu, czyli interfejs użytkownika na poziomie systemu służący do przełączania zadań i wyświetlania ostatnio używanych czynności i zadań za pomocą miniatury graficznego stanu aplikacji w momencie, gdy użytkownik ostatnio ją zamknął.

Implementacje na urządzeniu, w tym klawisz nawigacji funkcji ostatnich, zgodnie z opisem 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ć tytuły co najmniej 4 aktywności naraz.
• 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, dopóki użytkownik nie 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] NAJBARDZIEJ zalecamy używanie 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 Dreams)

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 podać współrzędne 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óżnorodną rodzinę, 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 Birmie do wyświetlania tekstów w językach birmańskich używa się kilku czcionek niezgodnych ze standardem 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 Unicode, JEDYNIE JEŚLI podano kod języka z kodem skryptu Qaag (np. my-Qaag). Do odwołania się do czcionki niezgodnej z Unicode w Mjanmie nie można używać żadnych innych kodów języków ani regionów ISO (zarówno przypisanych, nieprzypisanych, jak i zarezerwowanych). Deweloperzy aplikacji i twórcy stron internetowych mogą określić 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 ustawioną przez aplikację w pliku AndroidManifest.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] W trybach wielookiennych innych niż Picture-in-Picture rozmiar aktywności NIE MOŻE być mniejszy niż 220 dp.
• 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ęść jego zawartości, jeśli aplikacja Launcher jest oknem aktywnym.
• [C-2-3] MUSI uwzględniać zadeklarowane wartości AndroidManifestLayout_minWidth i AndroidManifestLayout_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 oraz android: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 co najmniej 1:2,39 i maksymalnie 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 i AndroidManifestLayout_minHeight:

  • Urządzenia z wartością Configuration.uiMode inną niż UI_MODE_TYPE_TELEVISION MUSZĄ mieć 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.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń zawierają więcej niż 1 obszar wyświetlania zgodny z Androidem i udostępniają takie obszary aplikacjom, muszą:

• [C-4-1] Musi obsługiwać tryb wielu okien.

Jeśli implementacje urządzeń obsługują tryb wielu okien, muszą:

• [C-5-1] NALEŻY zaimplementować prawidłową wersję rozszerzeń poziomu API menedżera okien zgodnie z opisem w WindowManagerExtensions.

Koniec nowych wymagań

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 wyświetlaczu 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 stosować 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.LayoutParamsAPI zgodnie z opisem w pakiecie SDK.
• [C-1-4] MUSI podawać prawidłowe wartości wszystkich danych typu cutout 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

Nowe wymagania dotyczące Androida 15

Android zawiera funkcje, które umożliwiają aplikacjom kontrolera zasad dotyczących urządzeń wykonywanie funkcji administracyjnych na poziomie systemu, takich jak wymuszanie zasad dotyczących haseł czy zdalne kasowanie danych, za pomocą interfejsu Android Device Administration API interfejsu Device Policy Manager API.

Jeśli implementacje urządzeń implementują pełny zakres zasad zarządzania urządzeniami zdefiniowanych w dokumentacji pakietu Android SDK, 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.

Koniec nowych wymagań

3.9.1. Obsługa administracyjna urządzenia

3.9.1.1. Właściciel 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 MIME MIME_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ć kreatora konfiguracji, dopóki aplikacja Właściciel urządzenia nie zakończy działania.
  • Jeśli implementacja urządzenia zawiera użytkowników lub ich dane:
    • [C-1-7] Nie można już rejestrować aplikacji DPC jako aplikacji właściciela urządzenia.

Nowe wymagania dotyczące Androida 15

• [C-1-2] MUSI wyświetlać odpowiednie powiadomienie (jak to w AOSP) i uzyskać wyraźną zgodę użytkownika przed ustanowieniem aplikacji jako właściciela urządzenia, chyba że urządzenie jest skonfigurowane programowo do trybu demonstracyjnego dla sprzedawców 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” będący odpowiednikiem standardowego „Właściciela urządzenia” rozpoznawanego 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ć te same informacje 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.

Koniec nowych wymagań

3.9.1.2. Obsługa administracyjna profilu zarządzanego

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.

Nowe wymagania dotyczące Androida 15

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

Koniec nowych wymagań

• [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ą 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ł określony, 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. Pomoc dotycząca 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 upstream AOSP) 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 kontrolera zasad 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 zezwala na to kontroler zasad urządzenia.
• [C-1-9] MUSI spełniać wszystkie wymagania dotyczące zabezpieczeń obowiązujące w przypadku urządzenia 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.
• [C-1-10] NALEŻY zadbać o to, aby dane zrzutu ekranu były zapisywane w pamięci profilu służbowego, gdy zrzut ekranu jest wykonywany za pomocą okna topActivity, które ma fokus (czyli to, z którym użytkownik ostatnio wszedł w interakcję spośród wszystkich aktywności) i należy do aplikacji na profilu służbowym.
• [C-1-11] NIE MOŻESZ uchwycić żadnej innej zawartości ekranu (paska systemowego, powiadomień ani treści na profilu osobistym), z wyjątkiem okna/okienek aplikacji na profilu służbowym podczas zapisywania zrzutu ekranu na profilu służbowym (aby mieć pewność, że dane na profilu osobistym nie zostaną zapisane na profilu służbowym).

Jeśli implementacje na urządzeniu deklarują android.software.managed_users i android.software.secure_lock_screen, mogą:

• [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 opisem na stronie projektu Android Open Source.
  • Zasady dotyczące haseł w DPC MUSZĄ dotyczyć tylko danych logowania na ekranie blokady profilu zarządzanego, chyba że są wywoływane w przypadku instancji DevicePolicyManager zwracanej przez getParentProfileInstance.
• 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 jest używany do oznaczania aplikacji na profilu zarządzanym.

3.9.3. Pomoc dla użytkowników zarządzanych

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 powraca true. 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 dodawanie 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 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.9.5. Ramy rozwiązywania problemów z zasadami dotyczącymi urządzeń

Jeśli implementacje na urządzeniach android.software.device_admin lub android.software.managed_users, to:

• [C-1-1] NALEŻY rozwiązać konflikty zasad dotyczących urządzeń zgodnie z opisem w ramach zasad dotyczących urządzeń.

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 implementacji AccessibilityService, 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, muszą:

• [C-2-1] Musisz umożliwić użytkownikowi wybranie silnika TTS do użycia na poziomie systemu.

Nowe wymagania dotyczące Androida 15

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

Koniec nowych wymagań

3.13. Szybkie ustawienia

Android udostępnia komponent interfejsu Szybkie ustawienia, który umożliwia szybki dostęp do często używanych lub pilnych 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() lub getIconUri() oraz tytuły uzyskane za pomocą getTitle() zgodnie z opisem w MediaDescription. 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 lub KEYCODE_MEDIA_PLAY_PAUSE jako KEYCODE_MEDIA_NEXT w przypadku MediaSession.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, które mają wartość android:protectionLevel równą "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 połą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 interakcja użytkownika POWINNA umożliwiać użytkownikowi nie uruchamianie aplikacji natychmiastowej, a zamiast tego uruchomienie powiązanego linku w skonfigurowanej przeglądarce internetowej, jeśli przeglądarka jest dostępna na urządzeniu.
  • [C-1-7] NALEŻY 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.

Nowe wymagania dotyczące Androida 15

• [C-1-3] Musisz umożliwić użytkownikowi wybranie/potwierdzenie obecności i działania urządzenia towarzyszącego.Musisz użyć tej samej wiadomości co w AOSP bez dodawania ani modyfikowania treści.

Koniec nowych wymagań

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 jedna 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 WOLNO 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 ustawiany 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 tabeli AccountManager. W kolumnach ACCOUNT_NAME i ACCOUNT_TYPE są one tworzone z wartościami null.

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 przez ContactsContract.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 i ACCOUNT_TYPE) MUSZĄ być wstawiane na niestandardowe konto lokalne.
• [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 parametr CALLER\_IS\_SYNCADAPTER został ustawiony na wartość false lub nie został określony.

Nowe wymagania dotyczące Androida 15

3.19. Ustawienia języka

Implementacje na urządzeniu:

• [C-0-1] NIE MOŻESZ udostępniać użytkownikom opcji wyboru języka w zależności od płci w przypadku języków, które nie obsługują tłumaczeń uwzględniających płeć. Więcej informacji znajdziesz w materiałach dotyczących gramatyki.

Koniec nowych wymagań

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 SDK do Androida.

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

• 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 dla startActivityForResult(), 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 systemu PackageManager.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ę systemów 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.

Uwaga: implementacje urządzeń z Androidem w wersji 10 lub starszej, które nie mogą spełniać wymagań [C-0-8] i [C-0-9] po aktualizacji oprogramowania systemowego, MOGĄ być zwolnione z tych wymagań.

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

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 dynamicznym 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 na urządzeniu obsługują dekodowanie buforów wejściowych AAC strumieni wielokanałowych (czyli więcej niż 2 kanałów) do formatu 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 i KEY_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 i KEY_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 API android.media.MediaCodec.

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łych android.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	Typy plików/formaty kontenerów, które mają być obsługiwane
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.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, ADIF nieobsługiwany) MPEG-TS (.ts, bez możliwości przeskakiwania, tylko dekodowanie) Matroska (.mkv, tylko dekodowanie)
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.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
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.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
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.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Obsługa treści mono lub stereo ze 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.	FLAC (.flac) MPEG-4 (.mp4, .m4a, tylko dekodowanie) Matroska (.mkv, tylko dekodowanie)
MP3	Mono/stereo 8–320 kb/s stała (CBR) lub zmienna szybkość transmisji (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, tylko dekodowanie) Matroska (.mkv, tylko dekodowanie)
MIDI	Typ MIDI 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonka RTTTL/RTX, OTA i iMelody	Typ 0 i 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Dekodowanie: obsługa treści mono, stereo, 5.0 i 5.1 z 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.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, tylko dekodowanie) Matroska (.mkv) WebM (.webm)
PCM/WAVE	Kodek PCM MUSI obsługiwać 16-bitowy linearny PCM i 16-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.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, tylko dekodowanie) Matroska (.mkv) WebM (.webm)

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
• [C-0-4] AVIF
  • Urządzenia muszą obsługiwać BITRATE_MODE_CQ i profil bazowy.

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 tryb kontroli szybkości transmisji bitów BITRATE_MODE_CQ, profil HEVCProfileMainStill oraz rozmiar ramki 512 x 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 formatów kodowania obrazów:

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Nieprzetworzone
• [C-0-7] AVIF (profil podstawowy)

Jeśli implementacje urządzeń obsługują dekodowanie wideo HEVC, to:

• [C-1-1] MUSI obsługiwać dekodowanie obrazu HEIF (HEIC).

Dekodery obrazu obsługujące format o wysokiej głębi bitów (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)
AVIF (profil podstawowy)	Obraz, kolekcja obrazów, sekwencja obrazów – profil podstawowy	Kontener HEIF (.avif)

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żny COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (równoważny COLOR_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żny COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (równoważny COLOR_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 przetwarzanie 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/formaty kontenerów, które mają być obsługiwane
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)
H.264 AVC	Więcej informacji znajdziesz w sekcji 5.2 i 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, bez możliwości przesuwania) Matroska (.mkv, tylko dekodowanie)
H.265 HEVC	Więcej informacji znajdziesz w sekcji 5.3.	MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)
MPEG-2	Profil główny	MPEG2-TS (.ts, nie można przesuwać do żądanego miejsca) MPEG-4 (.mp4, tylko dekodowanie) Matroska (.mkv, tylko dekodowanie)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)
VP8	Więcej informacji znajdziesz w sekcji 5.2 i 5.3.	WebM (.webm) Matroska (.mkv)
VP9	Więcej informacji znajdziesz w sekcji 5.3.	WebM (.webm) Matroska (.mkv)
AV1	Więcej informacji znajdziesz w sekcji 5.2 i 5.3.	MPEG-4 (.mp4) Matroska (.mkv, tylko dekodowanie)

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 o małym obciążeniu.

Jeśli implementacje urządzeń obsługują multimedia, mogą:

• [C-1-1] Musisz zapewnić obsługę kodeków multimedialnych za pomocą interfejsów OMX lub Codec 2.0 (lub obu), tak jak w projekcie Android Open Source Project, oraz nie wyłączać ani nie 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 obejmować 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] Zdecydowanie 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 MediaCodecInfo API.

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 Project 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 wykorzystuje akcelerację sprzętową, MUSI być opisany jako akcelerowany sprzętowo.
• [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	176 x 144 pikseli (H263, MPEG2, MPEG4) 352 x 288 pikseli (koder MPEG4, H263, MPEG2) 320 x 180 pikseli (VP8, VP8) 320 x 240 pikseli (inne)	704 x 576 pikseli (H263) 640 x 360 pikseli (VP8, VP9) 640 x 480 pikseli (koder MPEG4) 720 x 480 piks. (inne, AV1)	1408 x 1152 pikseli (H263) 1280 x 720 pikseli (inne, AV1)	1920 x 1080 piks. (inne niż MPEG4, AV1)	3840 x 2160 pikseli (HEVC, VP9, AV1)

• [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 są dostępne dla aplikacji innych firm, a ustawienie
MediaFormat.KEY_BITRATE_MODE to BITRATE_MODE_VBR tak, aby koder działał w trybie zmiennej szybkości transmisji bitów, to o ile nie wpływa to na minimalną jakość, kodowana szybkość transmisji bitów :

• W ramach jednego okna przesuwającego bitrate nie powinien przekraczać o 15% bitrate między interwałami klatek wewnątrzramkowych (I-frame).
• NIE POWINNA przekraczać 100% szybkości transmisji danych w przesuwalnym oknie 1 sekundy.

Jeśli implementacje na urządzeniu obsługują dowolny koder wideo i są dostępne dla aplikacji innych firm, a koder działa w trybie stałej szybkości transmisji bitów, to zakodowana szybkość transmisji bitów:MediaFormat.KEY_BITRATE_MODEBITRATE_MODE_CBR

• [C-SR-2] ZALECAMY, aby w przesuwalnym oknie 1 sekundy nie przekraczać o więcej niż 15% docelowej szybkości transmisji danych.

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 danych.
• 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] BARDZO ZALECAMY udostępnienie wtyczki dla interfejsu API do 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ć rozdzielczość QCIF (176 x 144) za pomocą profilu podstawowego poziomu 45. Rozdzielczość SQCIF jest opcjonalna.

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 ASo, FMO i RS w przypadku profilu podstawowego.
• [C-1-2] MUSI obsługiwać profile kodowania wideo SD (standardowa rozdzielczość) wymienione w tabeli poniżej.
• Powinien obsługiwać poziom 4 profilu głównego.
• Powinien obsługiwać profile kodowania filmów w rozdzielczości HD (wysoka rozdzielczość) zgodnie z informacjami podanymi w tabeli 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 obsługiwać profile dekodowania HD zgodnie z tabelą poniżej, jeśli istnieje koder sprzętowy.

	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 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ć profil główny poziomu 3 do rozdzielczości 512 x 512.
• [C-SR-1] ZALECAMY obsługę profilu SD 720 x 480 i profili kodowania HD zgodnie z tabelą poniżej, jeśli istnieje koder sprzętowy.

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

Jeśli implementacje na urządzeniach obsługują kodek AV1, to:

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

• [C-1-2] NALEŻY publikować dane o skuteczności, czyli zgłaszać dane o skuteczności za pomocą interfejsów API getSupportedFrameRatesFor() lub getSupportedPerformancePoints() dla obsługiwanych rozdzielczości w tabeli poniżej.

• [C-1-3] MUST accept HDR metadata and output it to the bitstream

Jeśli koder AV1 korzysta z akceleracji sprzętowej, to:

• [C-2-1] MUSI obsługiwać profil kodowania HD1080p z tabeli 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	5 Mb/s	8 Mb/s	16 Mb/s	50 Mb/s

5.3. Dekodowanie wideo

Jeśli implementacje urządzeń obsługują kodeki VP8, VP9, H.264 lub H.265, 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ć profil podstawowy na poziomie 30 (rozdzielczość CIF, QCIF i SQCIF przy 30 fps i 384 kbps) oraz poziom 45 (rozdzielczość QCIF i SQCIF przy 30 fps i 128 kbps).

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, mogą:

• [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./s^telewizor)
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 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 fps (60 fps ^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./s^telewizor)	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 tabeli poniżej.
• 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.

Nowe wymagania dotyczące Androida 15

• [C-1-2] MUSI prawidłowo wyświetlać treści Dolby Vision na ekranie urządzenia lub na zewnętrznym wyświetlaczu podłączonym za pomocą standardowego wyjścia wideo (np. HDMI).

Koniec nowych wymagań

• [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 i udostępniają go aplikacjom innych firm, mogą:

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

Jeśli implementacje urządzeń obsługują kodek AV1 ze sprzętowym dekoderem przyspieszonym sprzętowo, to:

• [C-2-1] Musi być możliwe dekodowanie profili dekodowania wideo HD 720p z tabeli poniżej, gdy wysokość zwracana przez metodę Display.getSupportedModes() jest równa lub większa niż 720p.
• [C-2-2] MUSI być w stanie dekodować co najmniej profile dekodowania wideo HD 1080p z tabeli poniżej, gdy wysokość zwracana przez metodę Display.getSupportedModes() jest równa lub większa niż 1080p.

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

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

• [C-3-1] MUSI obsługiwać wyodrębnianie i wyprowadzanie metadanych HDR z bitstremu lub kontenera.
• [C-3-2] NALEŻY prawidłowo wyświetlać treści HDR na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).

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 „NALEŻY”. 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] NALEŻY zezwalać na przechwytywanie surowych danych audio w przypadku dowolnego strumienia wejściowego AudioRecord lub AAudio, który został otwarty. 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, lub VOICE_PERFORMANCE. Dotyczy to też odpowiednich wstępnie ustawionych wartości wejściowych w AAudio, na przykład AAUDIO_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 API AudioManager.getMicrophones(), w przypadku aktywnego AudioRecord za pomocą MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED lub VOICE_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 (od ±20 dB w zakresie 30–100 Hz) były porównywalne z poziomami w zakresie ś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 (mierzonym 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 precyzją zmiennoprzecinkową/podwójną precyzją dla każdego mikrofonu używanego do nagrywania źródła audio do rozpoznawania głosu.

• NALEŻY nagrywać strumień audio do rozpoznawania mowy w taki sposób, aby poziomy amplitudy PCM śledziły liniowo zmiany SPL wejścia w zakresie co najmniej 30 dB od -18 do +12 dB w przypadku 90 dB SPL na 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) dostosowane 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] Identyfikator musi jednoznacznie wskazywać 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 API android.media.AudioRecord do nagrywania z tego źródła dźwięku rejestrowała miks wszystkich strumieni audio, z wyjątkiem tych:

  • 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] 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] MOCNO_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] Musisz zezwolić na jednoczesny dostęp do mikrofonu przez usługę ułatwień dostępu, która rejestruje dane za pomocą AudioSource.VOICE_RECOGNITION, oraz co najmniej 1 aplikację, która rejestruje dane za pomocą dowolnego AudioSource.
• [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ątkiem AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER.
• [C-1-3] Podczas nagrywania dźwięku za pomocą funkcji AudioSource.VOICE_COMMUNICATION lub AudioSource.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ą uprawnienia AudioSource.VOICE_COMMUNICATION, inna aplikacja może rejestrować połączenie głosowe, jeśli jest to aplikacja uprzywilejowana (wstępnie zainstalowana) z uprawnieniem CAPTURE_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.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 o tych cechach:

  • 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 i EFFECT_TYPE_LOUDNESS_ENHANCER, które można kontrolować za pomocą podklas AudioEffect Equalizer i LoudnessEnhancer.
• [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 AudioEffect DynamicsProcessing.

Nowe wymagania dotyczące Androida 15

• [C-1-4] MUSI obsługiwać efekty dźwiękowe z wejściami i wyjściami zmiennopozycyjnymi, gdy wyniki efektu są zwracane do ścieżki audio w ramach. Dotyczy to typowych efektów wstawiania lub efektów pomocniczych, takich jak korektor. Zalecamy stosowanie podobnego zachowania, gdy wyniki efektu są niewidoczne dla ścieżki audio frameworka (np. w przypadku efektów postprodukcyjnych lub przenoszonych).

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

• [C-1-5] Efekty dźwiękowe muszą obsługiwać wiele kanałów, aż do liczby kanałów miksera, znanej też jako FCC_LIMIT, gdy wyniki efektu są zwracane do ścieżki audio w ramach frameworka. Dotyczy to typowych efektów wstawiania lub efektów pomocniczych, ale nie obejmuje efektów specjalnych, takich jak downmix, upmix czy efekty przestrzenne, które zmieniają liczbę kanałów. Zaleca się podobne działanie, gdy efekty nie są widoczne w ramach przepływu danych audio w ramach frameworka (np. efekty końcowe lub przetwarzane poza procesorem).

Koniec nowych wymagań

• NALEŻY obsługiwać implementacje EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB i EFFECT_TYPE_VIRTUALIZER, które można kontrolować za pomocą podklas AudioEffect BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.
• [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ć dostosowywanie głośności dźwięku oddzielnie dla każdego strumienia audio, używając typu treści lub użycia zdefiniowanego za pomocą AudioAttributes oraz użycia dźwięku w samochodzie zdefiniowanego publicznie w android.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 zalecamy przycinanie odtwarzanych treści audio bez przerw między dwoma klipami o tym samym formacie, gdy 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 wyjście. Opóźnienie wyjściowe kolejnych klatek po rozpoczęciu odtwarzania dźwięku przez urządzenie.
• opóźnienie reakcji. Interval between when a sound is presented by environment to device at an on-device transducer or signal enters the device via a port and when an application reads the corresponding frame of PCM-coded data.
• 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 w przypadku wyjścia lub przepełnieniem bufora w przypadku wejścia albo jakimkolwiek innym źródłem szumu cyfrowego lub analogowego.
• średnie odchylenie bezwzględne (MAD). Średnia wartość bezwzględna odchyleń od średniej dla zbioru wartości.

Nowe wymagania dotyczące Androida 15

• Czas oczekiwania na sygnał (TTL), mierzony przez narzędzie CTS Verifier, to czas od momentu dotknięcia ekranu do momentu, gdy wygenerowany w efekcie tego dotknięcia sygnał jest słyszalny w głośniku. Jest to średnia z 5 pomiary wykonanych przy użyciu natywnego interfejsu API AAudio do generowania danych wyjściowych.

• Czas opóźnienia w obie strony (RTL) mierzony przez narzędzie CTS Verifier to średnia wartość opóźnienia ciągłego z 5 wyników pomiarów na ścieżce pętli, która przekazuje dane wyjściowe z powrotem do danych wejściowych za pomocą natywnego interfejsu API AAudio. Ścieżki pętli to:

  • Głośnik/mikrofon: wbudowany głośnik do wbudowanego mikrofonu.
  • Analogowe: gniazdo analogowe 3,5 mm i adapter pętli.
  • USB: przejściówka USB na 3,5 mm i przejściówka pętli lub interfejs audio USB i kable pętli.

• FEATURE_AUDIO_LOW_LATENCY. Funkcja android.hardware.audio.low_latency została zadeklarowana.

• FEATURE_AUDIO_PRO. Funkcja android.hardware.audio.pro została zadeklarowana.

• MPC. Klasa skuteczności kampanii w mediach.

• opóźnienie śledzenia ruchem głowy. Czas od ruchu głowy zarejestrowanego przez jednostkę pomiarową inercyjną (IMU) do wykrycia zmiany dźwięku spowodowanej przez ten ruch przez przetworniki słuchawek.

Koniec nowych wymagań

Jeśli implementacje urządzeń deklarują android.hardware.audio.output, MUSZĄ spełniać te wymagania:

Nowe wymagania dotyczące Androida 15

• [C-1-1] Sygnatura czasowa danych wyjściowych zwrócona przez AudioTrack.getTimestamp i AAudioStream_getTimestamp jest dokładna do +/- 2 ms.

Koniec nowych wymagań

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

Nowe wymagania dotyczące Androida 15

• [C-1-4] Obliczona na podstawie sygnatur czasowych wejścia i wyjścia zwracanych przez AAudioStream_getTimestamp opóźnienie w obie strony MUSI mieścić się w 200 ms mierzonej opóźnienia w obie strony w przypadku AAUDIO_PERFORMANCE_MODE_NONE i AAUDIO_PERFORMANCE_MODE_LOW_LATENCY w przypadku głośników, przewodowych i bezprzewodowych zestawów słuchawkowych.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

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 zimnego nieprzekraczające 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] Obliczone opóźnienia na podstawie sygnatury czasowej wejścia i wyjścia zwracanej przez AAudioStream_getTimestamp powinny mieścić się w zakresie 30 ms od zmierzonego opóźnienia na podstawie sygnatury czasowej wejścia i wyjścia zwracanej przez AAUDIO_PERFORMANCE_MODE_NONE i AAUDIO_PERFORMANCE_MODE_LOW_LATENCY w przypadku głośników, przewodowych i bezprzewodowych zestawów słuchawkowych.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

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 z AAudioStream_getPerformanceMode() wartość zwracana przez AAudioStream_getFramesPerBurst() była mniejsza lub równa wartości zwracanej przez android.media.AudioManager.getProperty(String) dla klucza usługi AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

Jeśli implementacje na urządzeniach nie spełniają wymagań dotyczących dźwięku o małej latencji za pomocą natywnego interfejsu AAudio, nie spełniają następujących wymagań:

• [C-2-1] NIE zgłaszaj obsługi dźwięku o małej latencji.

Koniec nowych wymagań

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

Nowe wymagania dotyczące Androida 15

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

Koniec nowych wymagań

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

Nowe wymagania dotyczące Androida 15

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 nieprzekraczające 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.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

Jeśli implementacje na urządzeniu deklarują android.hardware.audio.output i android.hardware.microphone, mogą:

• [C-SR-12] MOCNO ZALECAMY, aby średnia ciągła wartość opóźnienia w obie strony nie przekraczała 50 ms w 5 przypadkach pomiaru, a średnia bezwzględna odchyleń nie przekraczała 10 ms na co najmniej 1 obsługiwanej ścieżce.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

Tabela poniżej określa wymagania dotyczące języka arabskiego w orientacji poziomej w implementacjach na urządzeniach przenośnych (zgodnie z definicją w sekcji 2.2.1) deklarujących android.hardware.audio.output i android.hardware.microphone.

Urządzenia i deklaracje	RTL (ms)	MAD (ms)	Ścieżki sprzężenia zwrotnego
Kamera z ręki	250	30	głośnik/mikrofon, analogowe 3,5 mm (jeśli obsługiwane), USB (jeśli obsługiwane)
>= MPC_T (14)	80	15	co najmniej 1 ścieżkę
FEATURE_AUDIO_LOW_LATENCY	50	10	co najmniej 1 ścieżkę
FEATURE_AUDIO_PRO	25	5	co najmniej 1 ścieżkę
FEATURE_AUDIO_PRO	20	5	analog (jeśli jest obsługiwany)
FEATURE_AUDIO_PRO	25	5	USB (jeśli analog nie jest obsługiwany)

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

W tabeli poniżej określono wymagania dotyczące TTL w przypadku implementacji na urządzeniach przenośnych (zgodnie z definicją w sekcji 2.2.1), które deklarują android.hardware.audio.output i android.hardware.microphone.

Urządzenia i deklaracje	TTL (ms)
Kamera z ręki	250
>= MPC_T (14)	80
MPC_S (13)	100
FEATURE_AUDIO_PRO	80

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń obejmują obsługę spatial audio z śledzeniem głowy i deklarują flagę PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, to:

• [C-4-1] Maksymalny czas opóźnienia między śledzeniem ruchów głowy a aktualizacją dźwięku musi wynosić 300 ms.

Koniec nowych wymagań

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

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	Odsyłacze	Obsługa wymaganych kodeków
MPEG-2 Transport Stream	ISO 13818	Kodek wideo: H264 AVC MPEG-4 SP MPEG-2 Szczegółowe informacje o H264 AVC, MPEG2-4 SP, i MPEG-2 znajdziesz w sekcji 5.1.8. Kodeki audio: AAC Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.3.
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	Odsyłacze	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.

Nowe wymagania dotyczące Androida 15

• [C-1-2] Urządzenie musi mieć ciągłe opóźnienie w obie strony w przypadku dźwięku, spełniać wymagania dotyczące opóźnienia FEATURE_AUDIO_PRO określone w sekcji 5.6 Opóźnienie w ścieżce audio w wysokości 25 ms lub mniej w przypadku co najmniej jednej obsługiwanej ścieżki.

Koniec nowych wymagań

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

Nowe wymagania dotyczące Androida 15

• [C-1-5] Musisz spełnić opóźnienia i opóźnienia dźwięku USB za pomocą interfejsu API AAudio native audio i AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

Koniec nowych wymagań

• [C-1-6] Czas opóźnienia wyjściowego w przypadku zimnego uruchomienia musi wynosić 200 ms lub mniej.
• [C-1-7] Czas reakcji na zimny start musi wynosić 200 ms lub mniej.

Nowe wymagania dotyczące Androida 15

• [C-1-8] Średni czas opóźnienia od dotknięcia do wygenerowania 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 pomiarów 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 opóźnienia dźwięku w obie strony, opóźnienia wejścia i wyjścia oraz wymagań dotyczących dźwięku przez USB w ramach interfejsu API AAudio natywnej ścieżki dźwięku za pomocą ścieżki 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 na Androida SynthMark. 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ć następujące 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 stroną 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 wpisać 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ę fazową 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).

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

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ą klasy android.content.pm.PackageManager.

Koniec nowych wymagań

Jeśli implementacje urządzeń zawierają 4-żyłowe gniazdo słuchawek 3,5 mm, muszą:

Nowe wymagania dotyczące Androida 15

• [C-2-1] Średnie opóźnienie dźwięku w obie strony w ramach ciągłego połączenia, zgodnie z definicją w sekcji 5.6 Opóźnienie dźwięku, musi wynosić 20 ms lub mniej w ciągu 5 pomiary z średnim odchyleniem bezwzględnym poniżej 5 ms na ścieżce gniazda audio przy użyciu dongla audio.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

• [C-2-2] [C-SR-5] MOCNO zalecane MUSI spełniać wymagania podane w sekcji Specyfikacja urządzenia mobilnego (gniazdo) Specyfikacji słuchawek przewodowych (wersja 1.1).

Koniec nowych wymagań

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.

Nowe wymagania dotyczące Androida 15

• [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 kablowymi złączami 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.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

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ą oraz częstotliwością 192 kHz bez utraty głębi bitowej ani próbkowania.

Koniec nowych wymagań

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, zważonego 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, oprócz mnożnika poziomu, aby doprowadzić poziom do pożądanego zakresu. Krótko mówiąc:

  • [C-1-9] Jeśli architektura z jakiegokolwiek powodu zawiera przetwarzanie sygnału, musi ono być wyłączone i nie może wprowadzać opóźnienia ani dodatkowej zwłoki na ścieżce sygnału.
  • [C-1-10] Pomnażacz poziomu, 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 przy użyciu 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 dla wyjściowej powierzchni i czytelni dla procesora (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).

Uwaga: w Androidzie 13 ograniczenie P010 zostało złagodzone, aby umożliwić dowolny krok dla płaszczyzn Y i UV. (Ten format P010 MOŻE być zoptymalizowany i różnić się od formatu Camera2 P010).

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] Musi obsługiwać co najmniej 1 koderek wideo z akceleracją sprzętową dla każdej obsługiwanej technologii HDR.

• [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 mieć możliwość dekodowania zarejestrowanego strumienia 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ć precyzyjne (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] MUSI obsługiwać FEATURE_HdrEditing w przypadku wszystkich profili HDR reklamowanych przez ten kodek. Innymi słowy, MUSI obsługiwać generowanie metadanych HDR, gdy nie są one obecne w przypadku wszystkich obsługiwanych profili HDR, które używają metadanych HDR.

• [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 bufora bajtów. NALEŻY 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 Android SDK.
• Android Debug Bridge (adb)

Nowe wymagania dotyczące Androida 15

• [C-0-2] MUSI obsługiwać adb zgodnie z dokumentacją w pakiecie SDK Androida oraz komendami powłoki udostępnionymi w AOSP, których mogą używać deweloperzy aplikacji, w tym dumpsys, cmd stats i Simpleperf.

Koniec nowych wymagań

• [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 WOLNO zmieniać formatu ani zawartości zdarzeń systemu urządzenia (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) zapisanych za pomocą polecenia dumpsys.

Nowe wymagania dotyczące Androida 15

• [C-0-10] NALEŻY rejestrować bez pomijania i uzyskiwać dostęp do tych zdarzeń: cmd stats polecenie powłoki i klasa interfejsu API systemu StatsManager.
  • ActivityForegroundStateChanged
  • AnomalyDetected
  • AppBreadcrumbReported
  • AppCrashOccurred
  • AppStartOccurred
  • BatteryLevelChanged
  • BatterySaverModeStateChanged
  • BleScanResultReceived
  • BleScanStateChanged
  • ChargingStateChanged
  • DeviceIdleModeStateChanged
  • ForegroundServiceStateChanged
  • GpsScanStateChanged
  • InputDeviceUsageReported
  • JobStateChanged
  • KeyboardConfigured
  • KeyboardSystemsEventReported
  • PluggedStateChanged
  • ScheduledJobStateChanged
  • ScreenStateChanged
  • SyncStateChanged
  • SystemElapsedRealtime
  • TouchpadUsage
  • UidProcessStateChanged
  • WakelockStateChanged
  • WakeupAlarmOccurred
  • WifiLockStateChanged
  • WifiMulticastLockStateChanged
  • WifiScanStateChanged

Koniec nowych wymagań

• [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, mają te cechy:

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

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

• SysTrace

  • [C-0-9] Musi obsługiwać narzędzie systrace zgodnie z dokumentacją pakietu SDK Androida. Systrace musi być domyślnie nieaktywny i musi istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie Systrace.

• Perfetto

  • [C-SR-1] MOCNO POLECAMY 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 binarne dane wyjściowe perfetto zapisywały ścieżkę protobuf zgodną 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.

• Low Memory Killer

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

• Tryb jarzma testowego Jeśli implementacje urządzeń obsługują polecenie powłoki cmd testharness i uruchomienie cmd testharness enable, to:

  • [C-2-1] NALEŻY zwrócić true w przypadku ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] MUSISZ zaimplementować tryb jarzma testowego zgodnie z opisem w dokumentacji trybu jarzma testowego.

• Informacje o pracy GPU

  Implementacje na urządzeniu:

  • [C-0-13] NALEŻY zaimplementować polecenie powłoki dumpsys gpu --gpuwork, aby wyświetlić zagregowane dane pracy GPU zwrócone przez punkt śledzenia jądra power/gpu_work_period, lub nie wyświetlać żadnych danych, jeśli punkt śledzenia nie jest obsługiwany. Implementacja AOSP to frameworks/native/services/gpuservice/gpuwork/.

Jeśli implementacje urządzeń zgłaszają obsługę Vulkan 1.0 lub nowszej 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), które znajdują się w katalogu głównym aplikacji do debugowania, 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 intencji 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 kliknięciu 7 razy opcji 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(-a) z dokumentami pakietu Android SDK.
• 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 z odpowiednim interfejsem 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() i hasSystemFeature(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 do obsługi rozmów telefonicznych: 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 układy interfejsu do urządzenia, aby aplikacje innych firm działały prawidłowo na różnych wyświetlaczach i w różnych konfiguracjach sprzętowych. Ekran zgodny z Androidem to ekran, który implementuje wszystkie zachowania i interfejsy API opisane w dokumentacji dla deweloperów Androida – Omówienie zgodności ekranu, w tym rozdziale (7.1) i jego podrozdziałach, a także wszelkie dodatkowe zachowania specyficzne dla danego typu urządzenia opisane w sekcji 2 tych Warunków korzystania z usługi.

Implementacje na urządzeniu:

• [C-0-1] Domyślnie renderowanie aplikacji innych firm musi być ograniczone do wyświetlaczy zgodnych z Androidem.

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.
• gęstość. Liczba pikseli na odcinku poziomym lub pionowym o długości 1 cala, wyrażona w pikselach na cal (ppi lub dpi). W przypadku podanych wartości ppi i dpi zarówno dpi w poziomie, jak i w pionie muszą mieścić się w podanym zakresie.
• format. Stosunek pikseli dłuższego wymiaru do krótszego wymiaru ekranu. Na przykład wyświetlacz o wymiarach 480 x 854 pikseli 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 gęstości ekranu 160. Dla dowolnej gęstości d i liczby pikseli p liczba pikseli niezależnych od gęstości dp jest obliczana według wzoru: dp = (160 / d) * p.

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 umożliwia aplikacjom wysyłanie zapytań 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ą rozmiar small dla atrybutu Configuration.screenLayout, MUSZĄ mieć wymiary co najmniej 426 dp x 320 dp.
  • Urządzenia, które podają rozmiar normal dla Configuration.screenLayout, MUSZĄ mieć co najmniej 480 dp x 320 dp.
  • Urządzenia, które podają rozmiar large dla Configuration.screenLayout, MUSZĄ mieć wymiary co najmniej 640 x 480 dp.
  • Urządzenia zgłaszające rozmiar xlarge w przypadku Configuration.screenLayout MUSZĄ mieć co najmniej 960 dp x 720 dp.

• [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ą ekrany o konfiguracji rozmiaru UI_MODE_TYPE_NORMAL i używają wyświetlaczy fizycznych ze zaokrąglonymi rogami do renderowania tych ekranów, muszą:

• [C-1-1] NALEŻY zadbać o to, aby co najmniej jeden z tych wymagań był spełniony w przypadku każdego takiego wyświetlacza:

  • Promień zaokrąglonych rogów jest mniejszy lub równy 38 dp.
  • Gdy w każdym rogu logicznego wyświetlacza zamocujesz pole o wymiarach 18 x 18 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ń obsługują tylko konfigurację klawiatury NO_KEYS i chcą zgłosić obsługę konfiguracji trybu interfejsu UI_MODE_TYPE_NORMAL, muszą:

• [C-4-1] Rozmiar układu (z wyłączeniem wycięć na wyświetlaczu) musi wynosić co najmniej 596 x 384 dp.

Szczegółowe informacje o prawidłowym wdrażaniu interfejsów API sidecar lub rozszerzeń znajdziesz w publicznej dokumentacji Jetpacka Window Manager.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń zawierają co najmniej 1 obszar wyświetlacza zgodny z Androidem, który można złożyć, lub mają składany zawias między kilkoma obszarami panelu wyświetlacza zgodnego z Androidem i udostępniają te obszary wyświetlacza aplikacjom, muszą:

• [C-4-1] NALEŻY zaimplementować prawidłową wersję rozszerzeń poziomu API menedżera okien zgodnie z opisem w rozszerzeniach menedżera okien.

Koniec nowych wymagań

7.1.1.2. Format obrazu

Ta sekcja została usunięta w Androidzie 14.

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.

Implementacje na urządzeniu:

• [C-0-1] MUST report one of the Android framework densities that are listed on DisplayMetrics through the DENSITY_DEVICE_STABLE API and this value must be a static value for each physical display. Urządzenie MOŻE jednak zgłaszać inny DisplayMetrics.density w zależności od zmian w konfiguracji wyświetlacza wprowadzonych przez użytkownika (np. rozmiar wyświetlacza) po pierwszym uruchomieniu.

• NALEŻY zdefiniować standardową gęstość w ramach Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, lub wartość odpowiadającą tym samym pomiarom pola widzenia na urządzeniu przenośnym.

Jeśli implementacje urządzeń umożliwiają zmianę rozmiaru wyświetlacza, muszą:

• [C-1-1] NIE MOŻE zwiększyć wyświetlacza więcej niż 1,5 DENSITY_DEVICE_STABLE lub wygenerować skutecznej minimalnej wielkości ekranu mniejszej niż 320 dp (równa kwalifikatorowi zasobu sw320dp), w zależności od tego, co nastąpi pierwsze.
• [C-1-2] NIE MOŻNA zmniejszyć wyświetlacza do rozmiaru mniejszego niż 0,85 DENSITY_DEVICE_STABLE.
• 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ślnego view.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/or android.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ć tylko android.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ą:

Nowe wymagania dotyczące Androida 15

• [C-1-1] MUSI obsługiwać oba formaty OpenGL ES 1.1, i 2.0, 3.0 i 3.1, zgodnie z opisem w dokumentacji pakietu SDK Androida.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

• [C-SR-1] MOCNO ZALECAMY obsługę OpenGL ES 3.1.

Koniec nowych wymagań

• 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-master-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 i EGL_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 i OES_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 i EGL_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 zidentyfikować obsługę za pomocą 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] MOCNO 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-master-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, to:

• [C-1-1] Musisz podać prawidłową wartość całkowitą z flagami funkcji android.hardware.vulkan.level i android.hardware.vulkan.version.
• [C-1-2] MUST enumerate, at least one VkPhysicalDevice for the Vulkan native API vkEnumeratePhysicalDevices().
• [C-1-3] NALEŻY w pełni zaimplementować interfejsy API Vulkan 1.1 dla każdego z wymienionych VkPhysicalDevice.
• [C-1-4] NALEŻY wyliczyć warstwy zawarte w bibliotekach natywnych o nazwie libVkLayer*.so w katalogu bibliotek natywnych pakietu aplikacji za pomocą interfejsów API Vulkan vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties().
• [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 atrybut android:debuggabletrue lub metadane com.android.graphics.injectLayers.enabletrue.
• [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 TO ZROBIĆ, jeśli nie obsługuje się poprawnie ciągów znaków rozszerzeń.
• [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 funkcji android.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 funkcji android.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 i VK_GOOGLE_display_timing.
• [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 2022.
• [C-SR-5] ZDECYDOWANIE ZALECAMY obsługę VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory i VK_EXT_global_priority.
• [C-SR-6] Zdecydowanie zalecamy używanie SkiaVk z HWUI.

Nowe wymagania dotyczące Androida 15

Jeśli implementacje urządzeń obejmują obsługę Vulkana, to:

• [C-SR-8] MOCNO ZALECAMY, aby nie modyfikować ładowarki Vulkan.
• [C-1-14] NIE MOŻESZ wyliczać rozszerzeń Vulkan Device typu „KHR”, „GOOGLE” lub „ANDROID”, chyba że te rozszerzenia są uwzględnione w parametrze wiersza poleceń android.software.vulkan.deqp.level.

Koniec nowych wymagań

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 wartości VkPhysicalDevice.vkEnumeratePhysicalDevices()

Jeśli implementacje urządzeń obsługują Vulkan 1.1 i deklarują co najmniej 1 z flag funkcji Vulkan opisanych tutaj, to:

• [C-3-1] MUSI obsługiwać semantyka zewnętrznego semafora SYNC_FD oraz typy i rozszerzenie VK_ANDROID_external_memory_android_hardware_buffer.

• [C-SR-7] MOCNO POLECAMY udostępnienie rozszerzenia VK_KHR_external_fence_fd aplikacjom innych firm i zezwolenie tym aplikacjom na eksportowanie ładunku ogrodzenia i importowanie ładunku ogrodzenia z opisów pliku POSIX zgodnie z opisem tutaj.

7.1.4.3. RenderScript

Implementacje na urządzeniu:

• [C-0-1] MUSI obsługiwać Android RenderScript zgodnie z dokumentacją pakietu Android SDK.

7.1.4.4. Akceleracja grafiki 2D

Android zawiera mechanizm, który umożliwia aplikacjom oświadczenie o chęci włączenia akceleracji sprzętowej 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 Android View API.
• [C-0-2] Musi działać 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 dynamicznym

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 i EGL_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 jest niezdefiniowana.

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] Format obrazu w pikselach (PAR) MUSI mieścić się 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 za pomocą wbudowanego dodatkowego wyświetlacza, 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 open source w górnym systemie Android 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 na ACTION=MAIN oraz CATEGORY=LAUNCHER lub CATEGORY=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, muszą one:

• [C-1-1] Musi być dostępny za pomocą jednego działania (np. kliknięcia, podwójnego kliknięcia 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 trybie automatycznym.

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 na urządzeniach nie zapewniają funkcji menu, ze względu na zgodność wsteczną:

• [C-3-1] Funkcja menu MUSI być dostępna w aplikacjach, gdy targetSdkVersion jest mniejsza niż 10, za pomocą przycisku fizycznego, klawisza oprogramowania lub gestów. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacji.

Jeśli implementacje urządzeń zapewniają 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 obszarem WindowInsets#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 interfejsu View#setSystemGestureExclusionRects().
• [C-6-3] NALEŻY wysłać do aplikacji na pierwszym planie zdarzenie MotionEvent.ACTION_CANCEL, gdy dotknięcia są przechwytywane w celu wykonania gestu systemowego, jeśli wcześniej zostało wysłane zdarzenie MotionEvent.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 zapewnić 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 być funkcją Wstecz i musi być dostępna przez przesunięcie palcem od lewej i 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 and android.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 zaczynających 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 na ekranie, 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 użyciem żyroskopu, wskaźnik z użyciem żyroskopu, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe. Android zawiera stałą funkcję android.hardware.faketouch, która odpowiada urządzeniu do wprowadzania danych niebędącemu urządzeniem dotykowym (opartym na wskaźniku), takim jak mysz lub trackpad, które może odpowiednio emulować dane wprowadzane dotykiem (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] MUST report touch event with the action code that specifies the state change that occurs on the pointer going down or up on the screen.
• [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, przesunięcie 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 HID^2	Przycisk na Androida
A^1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B^1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X^1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y^1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Przycisk w górę na padzie kierunkowym^1 Przycisk w dół na padzie kierunkowym^1	0x01 0x0039^3	AXIS_HAT_Y^4
Przycisk w lewo na padzie kierunkowym1 Przycisk w prawo na padzie kierunkowym^1	0x01 0x0039^3	AXIS_HAT_X^4
Przycisk lewego uchwytu^1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Przycisk na prawym uchwycie^1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Kliknięcie lewej gałki^1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Kliknięcie prawego drążka^1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Wstecz^1	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 Controls^1	Użycie HID	Przycisk na Androida
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

1 MotionEvent

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] Musisz dokładnie podać obecność lub brak czujników w klasie android.content.pm.PackageManager.
• [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 innych interfejsów API czujników MUSI działać w racjonalny sposób (np. zwracać true lub false 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ądzeniu obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, deweloperzy:

• [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ń czujnika MUSI NIE UTRZYMYWAĆ procesora urządzenia w stanie zawieszenia ani nie aktywować go z tego stanu.
• [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ądzeniu obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, deweloperzy:

• [C-1-6] NALEŻY ustawić niezerową rozdzielczość dla wszystkich czujników i przekazać 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 urządzeń obejmują określony typ czujnika, który ma odpowiedni interfejs API dla zewnętrznych programistów, a czujnik raportuje tylko jedną wartość, implementacje urządzeń:

• [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 urządzeń 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 umożliwiać pomiar w trybie swobodnego spadania do wartości 4 ×gravity(4g) lub większej na 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 należy obliczyć 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.
• Rozdzielczość powinna wynosić co najmniej 16 bitów.
• 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 sensorów złożonych TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER:

• [C-4-1] Łączna wartość poboru mocy MUSI być zawsze mniejsza niż 4 mW.
• Wartości te powinny być niższe niż 2 mW i 0,5 mW w przypadku, gdy urządzenie jest w stanie dynamicznym lub stałym.

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

• [C-5-1] OBOWIĄZKOWA implementacja czujników złożonych TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR-7] MOCNO ZALECAMY wdrożenie czujnika złożonego TYPE_GAME_ROTATION_VECTOR.

Jeśli implementacje urządzeń zawierają 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 zera w przypadku układów scalonych 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ń obejmują 3-osiowy magnetometr i akcelerometr, muszą:

• MOŻE implementować 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 zastosowanie jakiejś formy wspomaganego lub przewidywanego systemu 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 zostało 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 zgłaszać co najmniej 8 satelitów z jednego konstelacji za pomocą GnssStatus.Callback.
  • 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ą interfejsów API dostawcy 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 prędkoś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] Musisz mieć odchylenie standardowe nie większe niż 1e-7 rad^2 / s^2 na Hz (odchylenie standardowe 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 i TYPE_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 raportowane 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żenia MUSI być skierowany na wykrywanie obiektów w pobliżu 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ść pomiaru 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 możliwością buforowania 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ć mniejsze niż 30 μg/√Hz przy testach w temperaturze pokojowej.
  • Zmiana stycznej w zależności od temperatury powinna wynosić ≤ +/- 1 mg/°C.
  • Krzywa najlepszego dopasowania powinna mieć nieliniowości ≤ 0,5%, a zmianę czułości w zależności od temperatury ≤ 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 co TYPE_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ść pomiaru 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 mieściło się w ramach co najmniej 80% częstotliwości Nyquista i by zawierało widmo szumu białego.
  • W temperaturze pokojowej szybkość losowego spaceru powinna wynosić mniej niż 0,001 °/s √Hz.
  • Zmiana przesunięcia względem temperatury powinna wynosić ≤ +/- 0,05°/ s / °C.
  • Zmiana czułości w zależności od temperatury powinna wynosić ≤ 0,02% / °C.
  • Współczynnik nieliniowości linii najlepszego dopasowania powinien wynosić ≤ 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 co TYPE_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 być większy niż 0,5 uT.

• [C-2-6] Musisz mieć TYPE_MAGNETIC_FIELD_UNCALIBRATED, który spełnia te same wymagania dotyczące jakości co TYPE_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 nieprzekraczające 2 mW.

• [C-2-8] MUSI mieć czujnik TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:

  • Zużycie energii MUSI wynosić nie 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 się mieścić w 2, 5 ms. 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 sygnatury czasowe zdarzeń z 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 zużycie energii 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, urządzenia te:

• [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 i getHighestDirectReportRateLevel.
• [C-3-2] Musi obsługiwać co najmniej 1 z 2 typów kanału bezpośredniego czujnika dla wszystkich czujników, które deklarują obsługę kanału bezpośredniego czujnika.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• 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 implementacje urządzeń obejmują zabezpieczony ekran blokady, muszą:

• 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 funkcje, 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.

Nowe wymagania dotyczące Androida 15

• [C-4-4] Musisz zezwolić aplikacjom na dodawanie niestandardowych treści do BiometricPrompt za pomocą formatów wyświetlania treści PromptContentView. Formaty wyświetlania treści NIE MOGĄ być rozszerzone o obrazy, linki, treści interaktywne ani inne formy mediów, które nie są już częścią interfejsu API BiometricPrompt. Dozwolone są korekty stylistyczne, które nie zmieniają, nie zasłaniają ani nie obcinają treści (np. zmiana pozycji, odstępów, marginesów i typografii).

Koniec nowych wymagań

Jeśli implementacje urządzeń obsługują biometryczne dane biometryczne, muszą:

• [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ą kilka czujników biometrycznych, muszą:

• [C-7-1] NALEŻY, gdy dane biometryczne są zablokowane (czyli są wyłączone, dopóki użytkownik nie odblokuje ich za pomocą uwierzytelniania podstawowego) lub zablokowane czasowo (czyli są tymczasowo wyłączone, dopóki użytkownik nie zaczeka na określony przedział czasu) z powodu zbyt dużej liczby nieudanych prób, również zablokować wszystkie inne dane biometryczne niższej klasy. W przypadku blokady czasowej czas do ponowienia weryfikacji biometrycznej MUSI być maksymalnym czasem do ponowienia wszystkich danych biometrycznych w ramach blokady czasowej.

• [C-SR-12] W przypadku zablokowania danych biometrycznych (czyli ich tymczasowego wyłączenia do czasu, aż użytkownik odblokuje je za pomocą uwierzytelniania podstawowego) lub blokady czasowej (czyli tymczasowego wyłączenia danych biometrycznych do czasu, aż użytkownik zaczeka pewien czas) z powodu zbyt dużej liczby nieudanych prób zalecamy blokowanie wszystkich innych danych biometrycznych tej samej klasy. W przypadku blokady czasowej MOCNO zalecamy, aby czas odroczenia weryfikacji biometrycznej był maksymalnym czasem odroczenia wszystkich danych biometrycznych w ramach blokady czasowej.

• [C-7-2] NALEŻY poprosić użytkownika o podanie zalecanego podstawowego uwierzytelnienia (np. kodu PIN, wzoru lub hasła), aby zresetować licznik blokady w przypadku zablokowania biometrycznego. Biometryka klasy 3 MOŻE być dozwolona do zresetowania licznika blokady w przypadku zablokowanej biometryki tej samej klasy lub niższej. Biometryka klasy 2 lub klasy 1 NIE MOŻE być używana do resetowania blokady w przypadku żadnej biometryki.

• [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 inną osobę i podstępnej podmiany danych przekraczają 7% zgodnie z protokołami testów danych biometrycznych na Androidzie.
• [C-1-9] MUSISZ poprosić użytkownika o zalecane podstawowe uwierzytelnianie (np. PIN, wzór, hasło) po maksymalnie 20 nieudanych próbach i nie krótszym niż 90-sekundowym czasie oczekiwania na weryfikację biometryczną, przy czym nieudana próba to próba o odpowiedniej jakości rejestracji (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanego wzoru biometrycznego.
• [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ć uwierzytelnianie biometryczne po tym, jak zostało uruchomione uwierzytelnianie zapasowe zgodnie z opisem w sekcji 9.11 w [C-0-2].
• [C-1-11] Procent akceptacji podszycia się pod inną osobę i podszycia się pod inny system nie może być wyższy niż 30%, 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ż 30%, 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ż 40%, zgodnie z protokołami testów funkcji 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 (kod PIN, wzór lub hasło) zabezpieczonego przez TEE. W ramach implementacji projektu Android Open Source Project udostępniono mechanizm umożliwiający wykonanie tej czynności.

Nowe wymagania dotyczące Androida 15

• [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 w wyniku przywracania do ustawień fabrycznych) lub gdy zostanie usunięta zalecana metoda uwierzytelniania podstawowego (np. PIN, wzór, hasło).

Koniec nowych wymagań

• [C-1-6] MUSI obsługiwać indywidualną flagę dla danego elementu biometrycznego (np. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE, DevicePolicymanager.KEYGUARD_DISABLE_IRIS).

Nowe wymagania dotyczące Androida 15

• [C-1-7] NALEŻY wymagać od użytkownika użycia zalecanej metody uwierzytelniania głównego (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.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

• [C-1-8] NALEŻY poprosić użytkownika o podanie danych uwierzytelniających (np. kodu PIN, wzoru lub hasła) lub danych biometrycznych klasy 3 (mocne) 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 licznik nieudanych prób uwierzytelniania są resetowane. Uwaga: urządzenia z Androidem w wersji 9 lub starszej mogą być zwolnione z wymagań C-1-8.

Koniec nowych wymagań

• [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 współczynnik fałszywych odrzuceń 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.
• [C-1-12] Proporcja akceptacji oszustwa i podmiany tożsamości MUSI wynosić nie więcej niż 40% na rodzaj środka do przeprowadzania ataków opartych na prezentowaniu (PAI), zgodnie z protokołami testów biometrycznych Androida.
• [C-SR-13] ZALECAMY, aby odsetek akceptacji spoofów i podwójnych kont nie przekraczał 30% na rodzaj narzędzia do ataków opartych na prezentowaniu (PAI), zgodnie z protokołami testów biometrycznych Androida.
• [C-SR-8] MOCNO zaleca się, aby współczynnik fałszywych odrzuceń był mniejszy niż 10%, mierzony na urządzeniu.

Nowe wymagania dotyczące Androida 15

• [C-1-15] NALEŻY zezwolić użytkownikom na usuwanie pojedynczych lub wielu rejestracji danych biometrycznych.

Koniec nowych wymagań

• [C-SR-14] ZALECAMY podanie klasy biometrycznej czujnika biometrycznego oraz związanych z nim zagrożeń.

• [C-SR-17] ZALECAMY wdrażanie nowych interfejsów AIDL (takich jak IFace.aidl i IFingerprint.aidl).

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 obiekt MUSI wynosić nie więcej niż 20%, przy czym (1) procent akceptacji podszycia się pod inną osobę i podszycia się pod inny obiekt w przypadku instrumentu do ataków na prezentację (PAI) poziomu A nie powinien przekraczać 20%, a (2) procent akceptacji podszycia się pod inną osobę i podszycia się pod inny obiekt w przypadku instrumentu do ataków na prezentację (PAI) poziomu B nie powinien przekraczać 30%, zgodnie z protokołami testów biometrycznych na urządzeniach z Androidem.
• [C-SR-15] ZALECAMY, aby współczynnik akceptacji spoof and imposter nie przekraczał 20% na rodzaj instrumentu ataku na podstawie pliku, 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ądra Androida, takim jak Trusted Execution Environment (TEE), na chipie z bezpiecznym kanałem do odizolowanego środowiska wykonawczego lub na chronionej maszynie wirtualnej, która spełnia wymagania podane w sekcji 9.17.
• [C-2-4] WSZYSTKIE dane identyfikacyjne MUSZĄ być zaszyfrowane i zaufalane kryptograficznie, tak aby nie mogły być pozyskiwane, odczytywane ani zmieniane poza izolowanym środowiskiem wykonawczym lub za pomocą układu scalonego z bezpiecznym kanałem do izolowanego środowiska wykonawczego zgodnie z opisem w wytycznych dotyczących implementacji na stronie projektu Android Open Source lub za pomocą chronionej maszyny wirtualnej kontrolowanej przez hypervisora, który spełnia wymagania podane w sekcji 9.17.
• [C-2-5] W przypadku uwierzytelniania lub rejestracji na podstawie danych biometrycznych z kamery:
  • NALEŻY obsługiwać kamerę w taki sposób, aby uniemożliwić odczytywanie lub modyfikowanie jej klatek poza odizolowanym środowiskiem wykonawczym. NALEŻY użyć układu z bezpiecznym kanałem do odizolowanego środowiska wykonawczego lub chronionej maszyny wirtualnej kontrolowanej przez hypervisora, który spełnia wymagania podane w sekcji 9.17.
  • W przypadku rozwiązań z jedną kamerą RGB ramki obrazu 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 wolno zezwalać na dostęp do nieszyfrowanych danych biometrycznych umożliwiających identyfikację ani do żadnych danych z nich pochodzących (takich jak elementy wbudowane) procesorowi aplikacji poza kontekstem TEE lub chronionej maszyny wirtualnej kontrolowanej przez hypervisora, który spełnia wymagania podane w sekcji 9.17. Urządzenia z Androidem w wersji 9 lub starszej nie są zwolnione z obowiązku stosowania 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 (wcześniej 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] MUSISZ mieć wskaźnik akceptacji podszycia się pod inną osobę i podszycia się pod inny system nie wyższy niż 7%, przy czym (1) wskaźnik akceptacji podszycia się pod inną osobę i podszycia się pod inny system w przypadku instrumentu do ataków na poziomie A nie powinien być wyższy niż 7%, a (2) wskaźnik akceptacji podszycia się pod inną osobę i podszycia się pod inny system w przypadku instrumentu do ataków na poziomie B nie powinien 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 elementu uwierzytelniania (np. kodu PIN, wzoru lub hasła) co 72 godziny lub rzadziej.
• [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ć obsługiwane przez aplikacje za pomocą danych biometrycznych.

• [C-SR-16] ZALECAMY, aby współczynnik akceptacji spoof i imposter nie przekraczał 7% na rodzaj instrumentu ataku na podstawie pliku, zgodnie z protokołami testów biometrycznych Androida.

Jeśli implementacje urządzeń zawierają czytnik linii papilarnych pod wyświetlaczem (UDFPS), powinny:

• [C-SR-11] ZDECYDOWANIE zalecamy, 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, muszą:

• [C-1-1] MUSISZ wdrożyć i zgłosić czujnik TYPE_POSE_6DOF.
• [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 (UWB)

Jeśli implementacje urządzeń obejmują obsługę standardu 802.1.15.4 i udostępniają te funkcje aplikacji innych firm, muszą:

• [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
• [C-1-3] MUSI obsługiwać wszystkie te zestawy konfiguracji (wstępnie zdefiniowane kombinacje parametrów FIRA UCI) zdefiniowane w implementacji AOSP.
  • CONFIG_ID_1: zdefiniowane przez FiRa unicastowe pomiary zasięgu STATIC STS DS-TWR, opóźniony tryb, interwał pomiarów zasięgu 240 ms.
  • CONFIG_ID_2: zdefiniowane przez FiRa pomiary typu jeden-do-wielu STATIC STS DS-TWR, opóźniony tryb, interwał pomiarowy 200 ms. Typowy przypadek użycia: telefon komórkowy współpracuje z wiele inteligentnymi urządzeniami.
  • CONFIG_ID_3: to samo co CONFIG_ID_1, z tym że nie są raportowane dane o kącie przybycia.
  • CONFIG_ID_4: to samo co CONFIG_ID_1, ale tryb zabezpieczeń P-STS jest włączony.
  • CONFIG_ID_5: to samo co CONFIG_ID_2, ale tryb zabezpieczeń P-STS jest włączony.
  • CONFIG_ID_6: to samo co CONFIG_ID_3, ale tryb zabezpieczeń P-STS jest włączony.
  • CONFIG_ID_7: to samo co CONFIG_ID_2, ale z włączonym trybem kontroli indywidualnych kluczy P-STS.
• [C-1-4] Musisz zapewnić użytkownikowi możliwość włączenia i wyłączenia radia UWB.
• [C-1-5] NALEŻY wymusić, aby aplikacje korzystające z radia UWB miały uprawnienie UWB_RANGING (w ramach grupy uprawnień NEARBY_DEVICES).

Zdanie odpowiednich testów zgodności i certyfikatów określonych przez organizacje standaryzacyjne, w tym FIRA, CCC i CSA, pomaga zapewnić prawidłowe działanie standardu 802.1.15.4.

7.4. Łączność z danymi

7.4.1. Połączenia telefoniczne

„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 lub nawiązywaniem połączeń przez sieć komórkową (np. GSM, CDMA, LTE, NR) lub CDMA. Urządzenie obsługujące „Telefonię” może oferować niektóre lub wszystkie usługi połączeń, wiadomości i danych, w zależności od produktu.

• 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 w pełni obsługiwać interfejs API dla danej 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ądzenia nie ustawiają właściwości systemowej ro.telephony.iwlan\_operation\_mode na „legacy”, to:

• [C-4-1] NIE MOŻESZ zgłaszać wartości „NETWORK_TYPE_IWLAN” za pomocą metody NetworkRegistrationInfo#getAccessNetworkTechnology(), gdy wartość zwracana przez metodę NetworkRegistrationInfo#getTransportType() to „TRANSPORT_TYPE_WWAN” w przypadku 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 i SmsManager#sendMultipartTextMessage MUSI wywoływać odpowiednie wywołania do funkcji CarrierMessagingService do obsługi funkcji SMS-ów. SmsManager#sendMultimediaMessage i SmsManager#downloadMultimediaMessage MUSIĄ wywoływać odpowiednie wywołania do CarrierMessagingService 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 kierunkowych w formacie *#*#CODE#*#* i wywoływanie odpowiedniej transmisji TelephonyManager#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 postaci wizualnej, jeśli obsługuje transkrypcje poczty głosowej w postaci wizualnej.
• [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ą doSettings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS lub EuiccManager#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 sprzyjającym 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 trakcie rozmowy głosowej, w której przypadku 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 stosować następujących funkcji:
  • 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 identyfikator 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 wysyłać wiadomości do dostawcy usług telefonicznych, jeśli została ona zablokowana.

• [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ą pojedynczą instancją 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 inną osobą w aplikacji innej firmy, która nie obsługuje funkcji wstrzymania określonej za pomocą CAPABILITY_SUPPORT_HOLD.
• [C-1-3] Aplikacja MUSI implementować interfejs InCallService.

• [C-SR-1] MOCNO zaleca się powiadomienie użytkownika, że odebranie przychodzącego połączenia 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 na true.EXTRA_LOG_SELF_MANAGED_CALLS

• [C-SR-3] ZALECAMY, aby obsłużyć zdarzenia KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK interfejsu API android.telecom w taki sposób:

  • Rozpocznij połączenie Connection.onDisconnect(), gdy podczas trwającego połączenia zostanie wykryte krótkie naciśnięcie klawisza.
  • Wywołanie Connection.onAnswer(), gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia.
  • Wywołanie Connection.onReject(), gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia.
  • Przełącz stan wyciszenia CallAudioState.

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ń obsługują funkcję przekierowania połączeń keepalive przez sieć komórkową 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] MUST return 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.

Nowe wymagania dotyczące Androida 15

• [C-1-4] MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251 lub ff02::fb) w żadnym momencie działania, w tym gdy ekran nie jest aktywny, chyba że odrzucenie lub odfiltrowanie tych pakietów jest konieczne, aby zachować zakresy zużycia energii wymagane przez przepisy obowiązujące na rynku docelowym.

• [C-1-4] Musi obsługiwać mDNS i NIE MOŻE filtrować pakietów mDNS (224.0.0.251 lub ff02::fb) w dowolnym momencie działania, w tym wtedy, gdy ekran nie jest aktywny, chyba że blokada multicast nie jest aktywna i pakiety są filtrowane przez APF. Pakiety nie są wymagane do obsługi operacji mDNS, o które aplikacje obecnie proszą za pomocą interfejsów API NsdManager. Urządzenie MOŻE jednak filtrować pakiety mDNS, jeśli jest to konieczne do utrzymania się w zakresie poboru mocy wymaganym przez przepisy obowiązujące na rynku docelowym.

Koniec nowych wymagań

• [C-1-5] NIE NALEŻY traktować wywołania metody interfejsu API WifiManager.enableNetwork() jako wystarczającej wskazówki do przełączenia obecnie aktywnego Network, który jest używany domyślnie do ruchu aplikacji i zwracany przez metody interfejsu API ConnectivityManager getActiveNetwork i registerDefaultNetworkCallback. 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ądzeniu Network.Jeśli okaże się, że obecne Network 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ń sondy, raz na początku każdego skanowania, gdy STA jest rozłączony.
• [C-1-8] NALEŻY używać 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ępu (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:

• POWINNA wyłączyć tryb oszczędzania energii Wi-Fi, gdy aplikacja uzyska blokadę WIFI_MODE_FULL_HIGH_PERF lub WIFI_MODE_FULL_LOW_LATENCY za pomocą interfejsów API WifiManager.createWifiLock() i WifiManager.WifiLock.acquire(), a blokada jest aktywna.
• [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 wydajność może być gorsza niż w przypadku korzystania z punktu 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 włączona jest funkcja Wi-Fi Aware, 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] MOCNO ZALECAMY, aby dokładność pomiaru nie przekraczała 1,5 metra przy przepustowości 80 MHz w 68.procentile (obliczonym za pomocą funkcji rozkładu skumulowanego).

7.4.2.6. Odciążenie utrzymywania aktywności przez Wi-Fi

Implementacje na urządzeniu:

• NALEŻY uwzględnić obsługę przenoszenia danych w ramach mechanizmu utrzymywania połączenia Wi-Fi.

Jeśli implementacje urządzeń obsługują funkcję przenoszenia utrzymania połączenia Wi-Fi 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 utrzymania 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 sieci 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 trybu TOFU.

7.4.3. Bluetooth

Jeśli implementacje urządzeń obsługują profil Bluetooth Audio, to:

• POWINNY obsługiwać zaawansowane kodeki audio i kodeki dźwięku Bluetooth (np.LDAC).

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 i android.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) nieprzekraczający 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, zgodnie z opisem w artykule Obsługa aparatów słuchowych za pomocą Bluetooth LE, urządzenia te:

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

• [C-6-2] NALEŻY zablokować dostęp do Bluetootha za pomocą 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ń na kanałach, tak aby pomiary na każdym z 3 kanałów i na każdej antenie (jeśli używane są liczne anteny) 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 szybkością ADVERTISE_TX_POWER_HIGH, przy czym urządzenia są ustawione w taki sposób, aby znajdowały się na „równoległych płaszczyznach”, a ekrany były zwrócone w ten sam kierunek.
• [C-SR-3] MOCNO zalecamy pomiar i kompensację przesunięcia nadawania, aby zapewnić średnią wartość RSSI BLE 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 częstotliwościADVERTISE_TX_POWER_HIGH, przy czym urządzenia są zorientowane w taki sposób, że znajdują się na „równoległych płaszczyznach”, a ich ekrany są skierowane w ten sam kierunek.

MOCNO zalecamy wykonanie czynności konfiguracyjnych pomiarów opisanych w artykule Wymagania dotyczące kalibracji obecności.

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 i android.nfc.NdefRecord, nawet jeśli nie obsługują one NFC ani nie deklarują funkcji android.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 the android.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 i dotychczasowe, 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 NFC Forum.

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 the android.content.pm.PackageManager.hasSystemFeature() method. Pamiętaj, że nie jest to standardowa funkcja Androida i nie jest widoczna jako stała w klasie android.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 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 i java.net.URLConnection, a także natywnych interfejsów API, takich jak AF_INET6sockets.
• [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.
• [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 lub Socket#getLocalPort, jak i interfejsy NDK, takie jak getsockname() lub IPV6_PKTINFO, MUSZĄ zwracać adres IP i port, który jest faktycznie używany 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ę w celu uzyskania dostępu 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 API ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] MUSI wykrywać portale przechwytujące i obsługiwać logowanie za pomocą aplikacji portalu przechwytującego, gdy urządzenie jest połączone z dowolnym typem sieci, w tym siecią komórkową/komórkową, 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 i android.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ą zapewniającą 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 „prawda”.

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 implementacja na urządzeniu nie zapewnia trybu oszczędzania danych, nie spełnia ona tych wymagań:

• [C-2-1] Musi zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED dla ConnectivityManager.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 i android.hardware.se.omapi.sd w przypadku urządzenia z elementami zabezpieczeń opartymi na SD.

7.4.9. UWB

Jeśli implementacje urządzeń obsługują 802.1.15.4 i udostępniają te funkcje aplikacji innych firm, muszą:

• [C-1-1] Należy zaimplementować odpowiedni interfejs API Androida w pliku android.uwb.
• [C-1-2] MUSISZ podać 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 ZALECAMY przeprowadzenie odpowiednich testów zgodności i certyfikatów zdefiniowanych 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 widoczności bezpośredniej w odległości 1 m w pomieszczeniu nieodblaskowym.
• [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 rzeczywista odległość jest mierzona od górnej krawędzi urządzenia testowanego.
• [C-SR-2] MOCNO zalecamy wykonanie czynności konfiguracji pomiaru opisanych w Wymaganiach kalibracji 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 lub MediaStore.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 stosowanie 10-bitowego wyjścia w przypadku obu głównych kamer.
• [C-2-3] Musi obsługiwać te same profile HDR dla wszystkich fizycznych podkamer aparatu logicznego zgodnych z BACKWARD_COMPATIBLE oraz dla samego aparatu logicznego.

Urządzenia z kamerą logiczną obsługujące 10-bitowy HDR i implementujące 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 to aparat skierowany na zewnątrz, który rejestruje obrazy z dalszej strony urządzenia, tak jak tradycyjny aparat. W przypadku urządzeń przenośnych jest to aparat znajdujący się po przeciwnej stronie wyświetlacza.

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 i android.hardware.camera.any.
• [C-1-2] Rozdzielczość musi wynosić co najmniej 2 Mpix.
• W sterowniku aparatu (niewidocznym dla oprogramowania aplikacji) powinien być zaimplementowany automatyczny autofokus sprzętowy lub automatyczny autofokus oprogramowania.
• 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 atrybuty FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu w systemie urządzenia, ale tylko aplikacji innych firm korzystających z Camera.PreviewCallback.

7.5.2. Przedni aparat

Przedni aparat to kamera skierowana na użytkownika, która zwykle służy do rejestrowania obrazu użytkownika, na przykład w przypadku konferencji wideo i podobnych aplikacji. W przypadku urządzeń przenośnych jest to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz.

Implementacje na urządzeniu:

• MOŻE zawierać przedni aparat.

Jeśli implementacje urządzeń zawierają co najmniej 1 przedni aparat:

• [C-1-1] MUSISZ zgłosić flagę funkcji android.hardware.camera.any i android.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(). Z drugiej strony, 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 metody android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NIE MOŻESZ lustrować końcowego obrazu nieruchomego ani strumieni wideo z powrotem do aplikacji lub do pamięci masowej.
• [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 aparatu MUSI być odbiciem poziomym w stosunku do bieżącego położenia urządzenia.

7.5.3. Kamera zewnętrzna

Kamera zewnętrzna to kamera, którą można w dowolnym momencie podłączyć lub odłączyć od urządzenia oraz która może być skierowana w dowolnym kierunku, np. kamery USB.

Implementacje na urządzeniu:

• MOŻE obsługiwać kamerę zewnętrzną, która nie musi być stale podłą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 i android.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 interfejsu 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 kontroli na poziomie poszczególnych klatek dotyczącej ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, redukcji szumów, wyostrzania itp.

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ównywalne osiągi 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 do onPreviewFrame(). 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ądzeniu android.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 i android.hardware.ImageFormat.JPEG jako dane wyjściowe w interfejsie android.media.ImageReader API na urządzeniach android.hardware.camera2, które reklamują REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLEw android.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ż aparatów przednich. Na przykład mimo że większość aparatów przednich nie obsługuje autofokusa, wywołania interfejsu API muszą być „udawane” 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 klasie android.hardware.camera2.CaptureRequest. Z drugiej strony implementacje urządzeń NIE MOGĄ obsługiwać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters(), które nie są opisane jako stałe w interfejsie android.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 obrazu za pomocą technik obrazowania o wysokim zakresie dynamicznym (HDR), MUSZĄ obsługiwać parametr kamery Camera.SCENE_MODE_HDR.
• [C-0-7] NALEŻY podać odpowiedni poziom obsługi za pomocą właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i 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ści android.request.availableCapabilities oraz zadeklarować odpowiednie flagi funkcji. NALEŻY zdefiniować flagę funkcji, jeśli którekolwiek z podłączonych kamer obsługuje tę funkcję.
• [C-0-9] MUSI przesyłać intencję Camera.ACTION_NEW_PICTUREza 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ć Camera.ACTION_NEW_VIDEO intencję 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 oraz interfejsu API android.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 lub android.hardware.Camera.
• [C-SR-1] W przypadku urządzeń z wieloma kamerami RGB w zbliżonej odległości i skierowanymi w ten sam kierunek MOCNO zalecamy obsługę logicznego urządzenia z kamerą, które zawiera informacje o możliwościachCameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, obejmujące wszystkie kamery RGB skierowane w ten sam kierunek jako fizyczne podurządzenia.

Jeśli implementacje na urządzeniach udostępniają firmom zewnętrznym zastrzeżony interfejs API aparatu, to:

• [C-1-1] NALEŻY zaimplementować taki interfejs API aparatu za pomocą interfejsu API android.hardware.camera2.
• MOŻE udostępniać tagi dostawcy lub rozszerzenia do interfejsu android.hardware.camera2API.

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 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).
• Implementacje urządzeń, których użytkownik nie może obracać, np. urządzenia samochodowe.

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ólne miejsce na dane zewnętrzne”, „wspólne miejsce 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 z sdcard do rzeczywistego punktu zamontowania.
• [C-0-4] MUSISZ włączyć storage skoncentrowane domyślnie we wszystkich aplikacjach kierowanych na interfejs API na poziomie 29 lub wyższym, z wyjątkiem tej sytuacji:
  • Gdy aplikacja poprosi o android:requestLegacyExternalStorage="true" w pliku manifestu.
• [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 uprawnienia ACCESS_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 musi być kupiony osobno.

Jeśli implementacje urządzeń używają części niewymiennej pamięci masowej, aby spełnić powyższe wymagania, muszą:

• NALEŻY używać 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 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 obsługą trybu peryferyjnego USB i protokołu 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] ZDECYDOWANIE POLECAMY stosowanie elastycznej pamięci 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, na przykład w komorze baterii lub innej osłonie ochronnej, implementacje urządzenia:

• [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 through android.os.Build.SERIAL.
• [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem rezystorów USB 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, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
• [C-SR-2] Port powinien znajdować się na dole urządzenia (zgodnie z naturalną orientacją) lub umożliwiać 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 zainstalować przyszłe wersje platformy.
• [C-SR-3] NALEŻY wdrożyć obsługę poboru prądu 1,5 A podczas przesyłania dźwięku w trybie HS oraz ruchu 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, ponieważ dzięki temu będą mogły korzystać z 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 zasilania, gdy urządzenia obsługują USB typu C i tryb hosta USB.
• Powinien 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, czyli 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 DOSTARCZAJĄCY CABLE ADAPTING TO STANDARD PORT TYPE-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.
• POWINNA 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ą „Termination Parameters” (Parametry zakończenia) w specyfikacji USB Type-C Cable and Connector Specification Revision 1.2 (Specyfikacja kabla i złącza USB typu C, wersja 1.2) w przypadku złączy USB typu C lub używać portu ładowania w dół (CDP) w zakresie prądu wyjściowego zgodnie ze specyfikacją USB Battery Charging specifications, revision 1.2 (Specyfikacja ł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 KeyEventkonstant 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

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 i ACTION_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 z wyjściami audio, takie jak 4-żyłowe gniazdo słuchawkowe 3,5 mm lub port w trybie hosta USB z klasą 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 częstotliwością zbliżoną do ultradźwięków 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 w ramach protokołów radiowych, takich jak Bluetooth, Wi-Fi czy 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 Ohm lub mniej: KEYCODE_HEADSETHOOK
  • 210–290 Ω: KEYCODE_VOLUME_UP
  • 360–680 ohm: KEYCODE_VOLUME_DOWN
• [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
• [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 w zakresie 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. Przeprowadź test 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] Musisz 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 i EGL_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 i GL_EXT_protected_textures oraz udostępnić je na liście dostępnych rozszerzeń GL.
• [C-SR-1] ZALECAMY WDRAŻENIE ROZWIĄZANIA GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, a także 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 i VK_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ówno VK_QUEUE_GRAPHICS_BIT, jak i VK_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 z częstotliwością 60 FPS z dwoma 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 i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT zgodnie z dokumentacją NDK.
• [C-1-10] NALEŻY wdrożyć obsługę AHardwareBuffer z dowolną kombinacją flag użycia AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT w przynajmniej tych formatach: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] ZALECAMY, aby obsługiwać alokację AHardwareBufferz 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ść jest zdefiniowana jako 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 jest to 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] 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 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

Urządzenia przeznaczone do trzymania w ręce lub do noszenia mogą zawierać ogólny mechanizm haptyczny, dostępny dla aplikacji do celów takich jak zwracanie uwagi za pomocą dzwonka, alarmu, powiadomień czy ogólnego wyczuwalnego sygnału.

Jeśli implementacje urządzeń NIE zawierają takiego ogólnego aktuatora haptycznego, to:

• [7.10/C] MUST zwracać wartość false dla Vibrator.hasVibrator().

Jeśli implementacje urządzeń zawierają co najmniej 1 taki ogólny siłownik haptyczny, muszą:

• [C-1-1] MUSI zwracać wartość „true” (prawda) w przypadku argumentu Vibrator.hasVibrator().
• NIE NALEŻY używać mimośrodowego aktuatora haptycznego (wibratora).
• NALEŻY zaimplementować wszystkie publiczne stałe dotyczące jasnych wibracji w android.view.HapticFeedbackConstants, a precyzyjniej w funkcjach CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START i GESTURE_END.
• NALEŻY zaimplementować wszystkie publiczne stałe dotyczące jasnych wibracji w android.os.VibrationEffect, a mianowicie: EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK i EFFECT_DOUBLE_CLICK, oraz wszystkie możliwe publiczne stałe PRIMITIVE_* dotyczące bogatych wibracji w android.os.VibrationEffect.Composition, a mianowicie: CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN i THUD. Niektóre z tych prymitywów, np. LOW_TICK i SPIN, mogą być możliwe tylko wtedy, gdy wibrator może obsługiwać stosunkowo niskie częstotliwości.
• NALEŻY przestrzegać wskazówek dotyczących mapowania stałych publicznych w android.view.HapticFeedbackConstants do zalecanych stałych android.os.VibrationEffect z odpowiednimi relacjami amplitudy.
• NALEŻY używać tych połączonych stałych wartości haptycznych mapowania.
• NALEŻY stosować ocena jakości w przypadku interfejsów API createOneShot() i createWaveform().
• POWINNA zweryfikować, czy wynik publicznego interfejsu API android.os.Vibrator.hasAmplitudeControl() poprawnie odzwierciedla możliwości wibratora.
• NALEŻY sprawdzić możliwości skalowania amplitudy, wykonując android.os.Vibrator.hasAmplitudeControl().

Jeśli implementacje urządzeń przestrzegają mapowania stałych wartości haptycznych, to:

• NALEŻY sprawdzić stan implementacji, uruchamiając interfejsy API android.os.Vibrator.areAllEffectsSupported() i android.os.Vibrator.arePrimitivesSupported().
• NALEŻY przeprowadzić ocenę jakości stałych haptycznych.
• NALEŻY sprawdzić i w razie potrzeby zaktualizować konfigurację zastępczą dla nieobsługiwanych prymitywów zgodnie z instrukcjami implementacji dotyczącymi stałych.
• NALEŻY zapewnić alternatywne wsparcie, aby ograniczyć ryzyko niepowodzenia, jak opisano tutaj.

7.11. Klasa Media Performance

Klasę wydajnoś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 wersji R (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] MUSI spełniać wszystkie wymagania dotyczące „Klasy skuteczności reklamy” 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 minimalne kryteria 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żytkownika

Aby zapewnić płynne działanie interfejsu użytkownika, należy spełnić określone wymagania minimalne, które gwarantują 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 referencyjnej dla spójnej wydajności dostępu do plików w pamięci na dane prywatne 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. Zmierzono podczas zapisywania pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
• Skuteczność zapisu losowego. Pomiar wykonano 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ć bardziej restrykcyjne ograniczenia niż grupa w trybie gotowości aplikacji ZRANIONY, 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 ramach funkcji App Standby.
• [C-1-3] Liczba poziomów aplikacji w stanie gotowości używanych w ramach funkcji aplikacji w stanie gotowości MUSI ZGADZAĆ SIĘ z implementacją AOSP.
• [C-1-4] NALEŻY wdrożyć grupy aplikacji w stanie gotowości i tryb Doze zgodnie z opisem w Zarządzanie energią.
• [C-1-5] NALEŻY zwrócić true, gdy urządzenie jest w trybie oszczędzania energii.PowerManager.isPowerSaveMode()
• [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] ZALECAMY, aby umożliwić użytkownikom wyświetlanie 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 i ta rozszerzona funkcjonalność nakłada 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).

  W przeciwnym razie MUSISZ wyjść ze stanu S3, gdy aplikacje innych firm potrzebują zasobów systemowych, zgodnie z opisem 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ą funkcji PARTIAL_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 nie są wyczerpujące przykłady, ponieważ 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. Spójna 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 zniwelować takie wahania.

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ć 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 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ść modelu 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 podrozdziałach.

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_PRIVILEGEDMUSZĄ 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żce etc/permissions/ i traktując ścieżkę system/priv-app jako ścieżkę uprzywilejowaną.

Nowe wymagania dotyczące Androida 15

• [C-SR-1] Uprawnienia o wartości protectionLevel PROTECTION_SIGNATURE MOCNO zalecamy, aby przyznawać je tylko w tych przypadkach:

  • Aplikacje wstępnie zainstalowane w pliku obrazu systemu (oraz pliki APEX).
  • aplikacje z dozwolonymi uprawnieniami, jeśli nie są uwzględnione w pliku obrazu systemu;
  Uwaga: implementacja AOSP spełnia ten wymóg, odczytując i przestrzegając uprawnień z dozwolonej listy dla każdej aplikacji z plików w ścieżce etc/permissions/.

Koniec nowych wymagań

Uprawnienia z poziomem ochrony niebezpieczny to uprawnienia czasu działania. Aplikacje z targetSdkVersion > 22 żądają 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-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 na podstawie domyślnych zasad przyznawania uprawnień lub 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 zabezpieczenia sprzętowe o odpowiedniej lub większej skuteczności niż te opisane w usłudze Google Cloud Key Vault, aby zapobiec atakom typu brute-force na element wiedzy związany z ekranem 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 za pomocą 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 tej aktywności.

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 lub NETWORK_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łny dostęp, dopóki nie zostaną dodane do listy dozwolonych w pakiecie SDK, gdzie dla każdego uprawnienia softRestricted zdefiniowano 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ą z ról 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 opisane w sekcji „9.8.6 Dane na poziomie systemu operacyjnego i otoczenia” oraz „9.8.15 Implementacje interfejsu API w sandboksie”.

Jeśli implementacje na urządzeniach zawierają domyślną aplikację obsługującą interfejs VoiceInteractionService, muszą one:

• [C-5-1] NIE NALEŻY przyznawać uprawnień ACCESS_FINE_LOCATION jako domyślnych w przypadku tej aplikacji.

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 uruchomieniowe 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ć korzystania z wielu użytkowników, jeśli używają 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 na tym samym woluminie lub w tym samym 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ępnego tylko dla systemu, jeśli implementacje urządzenia korzystają z interfejsów API zewnętrznej pamięci masowej na nośnikach wymiennych. Ponieważ spowoduje to, że 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 użyć, 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.

Jeśli implementacje urządzeń tworzą dodatkowy profil użytkownika, o którym mowa powyżej, to:

• [C-4-1] NALEŻY zezwolić na obsługę przez aplikacje głównego użytkownika na urządzeniu poniższych intencji pochodzących z dodatkowego profilu:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] Musisz odziedziczyć wszystkie ograniczenia dotyczące użytkownika w zasadach dotyczących urządzenia i wybrane ograniczenia dotyczące nieużytkownika restrictions(list below) zastosowane przez głównego użytkownika urządzenia w tym dodatkowym profilu użytkownika.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] Tylko zezwalaj na kontakty pisemne z tego dodatkowego profilu za pomocą tych intencji:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] NIE MOŻESZ uruchamiać synchronizacji kontaktów w przypadku aplikacji działających na tym dodatkowym profilu użytkownika.

• [C-4-5] Musisz zezwalać aplikacjom na dodatkowym profilu, które mają aktywność w inicjatorze, na dostęp do kontaktów, które są już dostępne na głównym 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, ale można użyć widocznego interfejsu użytkownika, gdy dochodzi do niezablokowanego 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 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 i CONFIG_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 lub CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] NALEŻY zaimplementować sprawdzanie rozmiaru statycznych i dynamicznych obiektów oraz ich granic na kopiach między przestrzenią użytkownika a jądrem (np. CONFIG_HARDENED_USERCOPY) na urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym.
• [C-0-10] NIE WYKONUJ kodu w pamięci przeznaczonej dla użytkownika podczas wykonywania kodu w trybie jądra (np. w ramach sprzętowego PXN lub emulacji za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_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 jądrze poza normalnymi interfejsami API dostępu do danych użytkownika (np. interfejs API PAN dla sprzętu lub emulowany za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub wyższym.
• [C-0-12] NALEŻY wdrożyć izolację tabeli stron jądra, jeśli sprzęt jest podatny na atak CVE-2017-5754 na wszystkich urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym (np. CONFIG_PAGE_TABLE_ISOLATION lub CONFIG_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 lub EFI_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 i CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] ZALECAMY NIE stosowanie wyłączania 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ą istotne z punktu widzenia 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 lub CONFIG_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 włączenia inicjalizacji stosu w jądrze, aby zapobiec używaniu nieinicjalizowanych alokacji stosu (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). Nie należy też zakładać wartości używanej przez jądro do inicjalizacji tych alokacji.

Jeśli implementacje urządzeń korzystają z jądra Linuksa, które obsługuje SELinux, to:

• [C-1-1] NALEŻY wdrożyć SELinux.
• [C-1-2] NALEŻY ustawić SELinux na tryb globalny.
• [C-1-3] NALEŻY skonfigurować wszystkie domeny w trybie wymuszania. Nie są dozwolone 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ń używają urządzeń wejścia/wyjścia obsługujących DMA, to:

• [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 zaleca się 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 produkcji 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.

Technologia ochrony pamięci to technologia, która z dużą (ponad 90%) prawdopodobieństwem zapobiega występowaniu w aplikacjach korzystających z opcji manifestu android:memtagMode następujących typów błędów:

• przepełnienie bufora stosu
• używanie po okresie bezpłatnym,
• podwójne zwolnienie
• wild free (bez wskaźnika niebędącego wskaźnikiem calloc)

Implementacje na urządzeniu:

• [C-SR-15] Zalecamy ustawienie opcji ro.arm64.memtag.bootctl_supported.

Jeśli implementacje urządzenia ustawiają właściwość systemową ro.arm64.memtag.bootctl_supported na wartość Prawda,:

• [C-3-1] NALEŻY zezwolić właściwości systemowej arm64.memtag.bootctl na akceptowanie listy wartości rozdzielonych przecinkami, która po ponownym uruchomieniu urządzenia będzie miała pożądany efekt:

  • memtag: włączona jest technologia ochrony pamięci zdefiniowana powyżej;
  • memtag-once: tymczasowo włączona technologia ochrony pamięci (zdefiniowana powyżej) jest automatycznie wyłączana po następnym ponownym uruchomieniu
  • memtag-off: wyłączona jest technologia ochrony pamięci zdefiniowana powyżej;

• [C-3-2] NALEŻY zezwolić użytkownikowi powłoki na ustawienie arm64.memtag.bootctl.

• [C-3-3] Musisz zezwolić dowolnemu procesowi na odczyt arm64.memtag.bootctl.

• [C-3-4] NALEŻY ustawić arm64.memtag.bootctl na aktualnie żądany stan. Po uruchomieniu NALEŻY również zaktualizować właściwość, jeśli implementacja urządzenia umożliwia modyfikowanie stanu bez zmiany właściwości systemowej.

• [C-SR-16] MOCNO ZALECAMY wyświetlanie ustawienia dla programistów, które ustawia tag memtag-once i restartuje urządzenie. Dzięki zgodnemu bootloaderowi projekt Android Open Source spełnia powyższe wymagania za pomocą protokołu bootloadera MTE.

Nowe wymagania dotyczące Androida 15

Jeśli urządzenie deklaruje android.hardware.telephony, obsługuje funkcję radiową CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK i zawiera modem komórkowy, który obsługuje połączenia 2G, implementacja urządzenia:

• [C-SR-17] MOCNO ZALECAMY, aby umożliwić użytkownikom wyłączenie i włączenie sieci 2G.

• [C-SR-18] Zdecydowanie zalecamy, aby nie zastępować możliwości użytkownika do wyłączania i włączania 2G za pomocą żadnego innego elementu urządzenia, z wyjątkiem administratora urządzenia korzystającego z UserManager.DISALLOW_CELLULAR_2G.

• [C-SR-19] W celu spełnienia tego wymagania MOCNO POLECAMY skontaktowanie się z działem TelephonyManager.setAllowedNetworkTypesForReason z powodem ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G.

• [C-SR-20] ZALECAMY określenie obsługi modemu komórkowego w sieci 2G przez telefon TelephonyManager.getSupportedRadioAccessFamily. Więcej informacji znajdziesz w artykule Wyłączanie sieci 2G.

Koniec nowych wymagań

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 jako DEST_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 są rejestrowane 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) z urządzenia bez jego zgody lub bez wyraźnych powiadomień.

• [C-0-2] MUSI wyświetlać ostrzeżenie i uzyskać wyraźną zgodę użytkownika na rejestrowanie wszelkich informacji poufnych wyświetlanych na ekranie użytkownika za każdym razem, gdy rozpoczyna się sesja rejestrowania ekranu za pomocą interfejsów MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay() lub zastrzeżonych interfejsów API.

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

• [C-SR-1] ZALECAMY wyświetlanie użytkownikowi ostrzeżenia, które jest dokładnie tym samym komunikatem co w AOSP, ale MOŻE zostać zmieniony, o ile wyraźnie ostrzega użytkownika, że wszelkie poufne informacje na ekranie są rejestrowane.

• [C-0-4] NIE NALEŻY udostępniać użytkownikom możliwości wyłączenia przyszłych monitów dotyczących zgody użytkownika na rejestrowanie ekranu, chyba że sesja została uruchomiona przez aplikację systemową, której użytkownik zezwolił na associate()android.app.role.COMPANION_DEVICE_APP_STREAMINGlub profil urządzenia android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.

Nowe wymagania dotyczące Androida 15

Implementacje na urządzeniu:

• [C-0-7] NIE NALEŻY nagrywać, wyświetlać ani przesyłać informacji poufnych, takich jak:
  • Treści poufne w powiadomieniach wymienione w sekcji 3.8.3.4 Ochrona powiadomień poufnych
  • okna aktywności aplikacji zawierające hasła jednorazowe;
  • treści poufne, takie jak nazwa użytkownika, hasło i dane karty kredytowej;

Koniec nowych wymagań

Jeśli implementacje na urządzeniu obejmują funkcje systemu, które rejestrują zawartość wyświetlaną na ekranie lub strumień audio odtwarzany na urządzeniu w inny sposób niż za pomocą interfejsu System API ContentCaptureService lub innych zastrzeżonych metod opisanych w sekcji 9.8.6 Dane na poziomie systemu i dane z otoczenia, 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 może rejestrować dźwięk z otoczenia lub dźwięk odtwarzany na urządzeniu, aby wywnioskować przydatne informacje 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żytkownik musi mieć świadomość, ż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łączony.

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, z którą zwraca 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 miejsca na dane 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łównego urzędu certyfikacji użytkownika.
• [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] MUSI prosić o zgodę użytkownika przed włączeniem tego mechanizmu, chyba że VPN jest włączony przez kontroler zasad urządzenia za pomocą DevicePolicyManager.setAlwaysOnVpnPackage(), w którym przypadku użytkownik nie musi wyrażać osobnej zgody, ale MUSI zostać powiadomiony.

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, ustawiając atrybut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

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. Dane na poziomie systemu operacyjnego i dane o otoczeniu

Android, za pomocą interfejsów System API, obsługuje mechanizm implementacji na urządzeniu, który umożliwia gromadzenie tych danych wrażliwych:

• 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 ekrany lub inne dane wysyłane przez AugmentedAutofillService do systemu.

• Dostęp do dowolnego ekranu lub innych danych za pomocą interfejsów APIContent Capture.

• wszelkie dane aplikacji przekazane do systemu przez interfejs API AppSearchManager i dostępne przez AppSearchGlobalManager.query.

• 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 i inne podobne dane.

• Dane audio uzyskane w wyniku użycia przez funkcję rozpoznawania mowy SpeechRecognizer#onDeviceSpeechRecognizer().

• Dane audio uzyskiwane w tle (ciągle) za pomocą interfejsów AudioRecord, SoundTrigger lub innych interfejsów API do obsługi dźwięku, które nie powodują wyświetlenia użytkownikowi żadnego wskaźnika

• dane z aparatu uzyskiwane w tle (ciągle) za pomocą interfejsu CameraManager lub innych interfejsów aparatu, bez wyświetlania użytkownikowi wskaźnika;

Jeśli implementacje urządzeń rejestrują którekolwiek z wymienionych powyżej danych, to:

• [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 Androida 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 poza urządzenie tylko za pomocą mechanizmu zapewniającego ochronę prywatności, z wyjątkiem sytuacji, gdy użytkownik wyrazi wyraźną zgodę na udostępnienie danych. Mechanizm ochrony prywatności jest zdefiniowany jako „taki, który umożliwia analizę tylko w ujęciu zbiorczym i zapobiega dopasowywaniu zdarzeń zarejestrowanych lub wyników pochodnych do poszczególnych użytkowników”. Ma to zapobiegać możliwości przeglądania jakichkolwiek 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 składnikom systemu operacyjnego, które nie spełniają wymagań opisanych w bieżącej sekcji (9.8.6 Dane na poziomie systemu operacyjnego i dane z otoczenia), chyba że użytkownik wyraźnie wyrazi na to zgodę za każdym razem, gdy dane są udostępniane. chyba że taka funkcja jest dostępna jako interfejs API pakietu SDK Androida (AmbientContext, HotwordDetectionService).
• [C-1-6] NALEŻY umożliwić użytkownikowi wymazanie danych, które są zbierane przez implementację lub za pomocą zastrzeżonych metod, gdy dane są przechowywane w dowolnej formie na urządzeniu. Jeśli użytkownik zdecyduje się na usunięcie danych, musi usunąć wszystkie zebrane dane historyczne.

• [C-1-7] Musisz umożliwić użytkownikowi rezygnację z wyświetlania danych zebranych przez AppSearch lub za pomocą zastrzeżonych metod na platformie Android (np. w wyszukiwarce).

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

• [C-SR-4] MOCNO zaleca się implementowanie ich za pomocą interfejsu API pakietu SDK Androida lub podobnego repozytorium open source należącego do OEM-a albo w ramach skonfigurowanej piaskownicy (patrz 9.8.15 Implementacje interfejsu API w skonfigurowanej piaskownicy).

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

9.8.7. Dostęp do schowka

Implementacje na urządzeniu:

• [C-0-1] NIE MOŻE zwracać danych z wykopczykowanych danych ze schowka (np. za pomocą interfejsu ClipboardManagerAPI), chyba że aplikacja innej firmy jest domyślną metodą wprowadzania lub jest aplikacją, która ma obecnie fokus.

• [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ą zostać w nią przekształcone. Ta lista nie jest wyczerpująca, ale powinna służyć jako przykład tego, co może być bezpośrednio lub pośrednio powiązane z lokalizacją:

• 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, takie 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] Aplikacja korzystająca z interfejsu API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] MUSI być aplikacją, która została uruchomiona przez użytkownika w ramach sesji awaryjnej (np. wybieranie numeru 112 lub wysyłanie SMS-a na 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ść ominięcia ustawień lokalizacji urządzenia bez ich zmiany za pomocą interfejsów API do omijania lokalizacji w trybie awaryjnym.
• [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 o innych zainstalowanych aplikacjach (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ą zarządzanych interfejsów API. Dotyczy to między innymi szczegółów udostępnianych przez niestandardowe interfejsy API dodane przez implementatora urządzenia lub dostępnych w systemie plików.
• [C-0-2] NIE MOŻESZ zezwalać żadnej aplikacji na odczyt ani zapisywanie plików w żadnym innym katalogu aplikacji na zewnętrznym urządzeniu pamięci masowej. Jedynymi wyjątkami są:
  • Dostawca autoryzacji pamięci zewnętrznej (np. aplikacje takie jak DocumentsUI).
  • Dostawca pobierania, który korzysta z 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 zrzut
  • TelephonyRegistry zrzut
  • WifiService zrzut
  • ConnectivityService zrzut
  • Dump instancji CarrierService pakietu wywołującego (jeśli jest powiązany)
  • Bufor dziennika radiowego
  • SubscriptionManagerService zrzut
• [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 loggingopcję 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 systemowi, aby udostępnić je wybranym aplikacjom.

Jeśli implementacje urządzeń obsługują wspólne 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, która implementuje 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 wymusić, 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 nagrania audio i przesyła je 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 żadnych nieprzetworzonych plików audio ani odcisków audio ani w pamięci przez dłużej niż 14 dni.
• [C-2-2] NIE MOŻESZ udostępniać takich danych poza MusicRecognitionService, chyba że użytkownik wyrazi na to wyraźną zgodę za każdym razem.

9.8.13. SensorPrivacyManager

Jeśli implementacja urządzenia umożliwia użytkownikowi wyłączenie wejścia z kamery lub mikrofonu, to:

• [C-1-1] W przypadku odpowiedniej metody interfejsu API supportsSensorToggle() MUSI zwracać wartość „prawda”.
• [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.8.14. Nie dotyczy

9.8.15. Implementacje interfejsów API w piaskownicy

Android, za pomocą zestawu interfejsów API zapewnia mechanizm do przetwarzania bezpiecznych danych na poziomie systemu operacyjnego i danych z otoczenia. Takie przetwarzanie może być delegowane do wstępnie zainstalowanej aplikacji z dostępem uprzywilejowanym i ograniczonymi możliwościami komunikacji, zwanej implementacją interfejsu API w piaskownicy.

W przypadku dowolnej implementacji interfejsu Sandboxed API:

• [C-0-1] NIE MOŻESZ poprosić o uprawnienia INTERNET.
• [C-0-2] Aplikacja MUSI uzyskiwać dostęp do internetu tylko za pomocą ustrukturyzowanych interfejsów API opartych na publicznie dostępnych implementacjach open source korzystających z mechanizmów ochrony prywatności lub pośrednio za pomocą interfejsów API pakietu Android SDK. Mechanizm ochrony prywatności jest zdefiniowany 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”. Ma to na celu zapobieganie możliwości wglądu w jakiekolwiek dane dotyczące poszczególnych użytkowników (np. za pomocą technologii prywatności różnicowej, takiej jak RAPPOR).
• [C-0-3] NALEŻY utrzymywać usługi oddzielnie od innych komponentów systemu (np. nie należy wiązać usługi ani udostępniać identyfikatorów procesów), z wyjątkiem:
  • Telefonia, Kontakty, UI systemu i multimedia
• [C-0-4] Nie wolno zezwalać użytkownikom na zastępowanie usług aplikacją lub usługą, którą mogą zainstalować
• [C-0-5] Tylko wstępnie zainstalowane usługi mogą zbierać takie dane. z wyjątkiem sytuacji, gdy funkcja zastępcza jest wbudowana w AOSP (np. w przypadku aplikacji Asystent cyfrowy).
• [C-0-6] NIE wolno zezwalać aplikacjom innym niż wstępnie zainstalowane usługi na rejestrowanie takich danych. z wyjątkiem sytuacji, gdy taka funkcja jest implementowana za pomocą interfejsu Android SDK API.
• [C-0-7] NALEŻY umożliwić użytkownikowi wyłączenie usług.
• [C-0-8] 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.

9.8.16. Dane z ciągłego dźwięku i kamery

Nowe wymagania dotyczące Androida 15

Oprócz wymagań opisanych w sekcjach 9.8.2 Nagrywanie, 9.8.6 Dane na poziomie systemu operacyjnego i dane z otoczenia oraz 9.8.15 Implementacje interfejsów API w sandboksie należy pamiętać o tym, że implementacje, które wykorzystują dane audio uzyskiwane w tle (ciągle) za pomocą interfejsów AudioRecord, SoundTrigger lub innych interfejsów API Audio LUB dane z kamery uzyskiwane w tle (ciągle) za pomocą interfejsów CameraManager lub innych interfejsów API dotyczących kamery:

Jeśli implementacje na urządzeniu rejestrują jakiekolwiek dane zgodnie z opisem w sekcji 9.8.2 lub 9.8.6, a takie implementacje korzystają z danych audio uzyskanych w tle (ciągle) przez AudioRecord, SoundTrigger lub inne interfejsy API dotyczące dźwięku LUB z danych z kamery uzyskanych w tle (ciągle) przez CameraManager lub inne interfejsy API dotyczące kamery, to:

Koniec nowych wymagań

• [C-0-1] MUSISZ wdrożyć odpowiedni wskaźnik (kamery lub mikrofonu zgodnie z sekcją 9.8.2 Nagrywanie), chyba że:
  • Dostęp jest realizowany w ramach implementacji w piaskownicy (patrz 9.8.15 Implementacja interfejsu API w piaskownicy) za pomocą pakietu zawierającego jedną lub więcej z tych ról: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence lub System Visual Intelligence.
  • Dostęp jest realizowany w piaskownicy, która jest implementowana i wymuszana za pomocą mechanizmów w AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
  • Dostęp do dźwięku jest realizowany w celu pomocy przez aplikację Asystent cyfrowy, która dostarcza SOURCE_HOTWORD jako źródło dźwięku.
  • Dostęp jest przyznawany przez system i wdrażany za pomocą kodu open source.
• [C-SR-1] MOCNO POLECAMY, aby wymagać od użytkowników zgody na każdą funkcję wykorzystującą takie dane i aby funkcja była domyślnie wyłączona.
• [C-SR-2] ZALECAMY stosowanie tych samych ograniczeń (tj. ograniczeń opisanych w sekcji 9.8.2 Nagrywanie, 9.8.6 Dane na poziomie systemu operacyjnego i dane z otoczenia, 9.8.15 Implementacje interfejsów API w sandboksie oraz 9.8.16 Ciągłe dane audio i z kamery) do danych z kamery pochodzących z zdalnego urządzenia do noszenia.

Nowe wymagania dotyczące Androida 15

Jeśli dane z kamery pochodzą z urządzenia do noszenia i są dostępne w niezaszyfrowanej formie poza systemem operacyjnym Android, w ramach piaskownicy lub w ramach funkcji w piaskownicy utworzonych przez WearableSensingManager, to:

Jeśli implementacje urządzeń otrzymują dane z kamery lub mikrofonu z urządzenia do noszenia, które znajduje się z dala od użytkownika, i dane te są dostępne w niezaszyfrowanej formie poza systemem operacyjnym Android, w ramach piaskownicy lub w ramach funkcji w piaskownicy utworzonej przez firmę WearableSensingManager, to:

Koniec nowych wymagań

• [C-1-1] MUSI wskazywać na urządzenie noszące, aby wyświetlić dodatkowy wskaźnik.

Jeśli urządzenia umożliwiają interakcję z aplikacją asystenta cyfrowego bez przypisanego słowa kluczowego (obsługując ogólne zapytania użytkowników lub analizując obecność użytkownika za pomocą kamery), nie mogą:

• [C-2-1] NALEŻY zadbać o to, aby takie wdrożenie zostało udostępnione przez pakiet zawierający rolę android.app.role.ASSISTANT.
• [C-2-2] Musisz mieć pewność, że taka implementacja korzysta z interfejsów API HotwordDetectionService lub VisualQueryDetectionService na Androida.

9.8.17. Telemetry

Android przechowuje dzienniki systemu i aplikacji za pomocą interfejsów StatsLog API. Tymi logami można zarządzać za pomocą interfejsów StatsManager API, których mogą używać aplikacje systemowe z podwyższonymi uprawnieniami.

Narzędzie StatsManager umożliwia też zbieranie danych sklasyfikowanych jako wrażliwe na prywatność z urządzeń z mechanizmem ochrony prywatności. W szczególności interfejs StatsManager::query API umożliwia wysyłanie zapytań do ograniczonych kategorii danych zdefiniowanych w pliku StatsLog.

Wszelkie implementacje, które wysyłają zapytania i zbierają dane objęte ograniczeniami z interfejsu StatsManager:

• [C-0-1] MUSI być jedyną aplikacją/implementacją na urządzeniu i mieć uprawnienie READ_RESTRICTED_STATS.
• [C-0-2] NALEŻY wysyłać tylko dane telemetryczne i dziennik urządzenia za pomocą mechanizmu ochrony prywatności. Mechanizm ochrony prywatności jest zdefiniowany 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”. Ma to zapobiegać możliwości wglądu w jakiekolwiek dane dotyczące poszczególnych użytkowników (np. za pomocą technologii ochrony prywatności różnicowej, takiej jak RAPPOR).
• [C-0-3] NIE MOŻESZ powiązać tych danych z żadną tożsamością użytkownika (np. kontem) na urządzeniu.
• [C-0-4] NIE MOŻNA udostępniać takich danych innym składnikom systemu operacyjnego, które nie spełniają wymagań opisanych w bieżącej sekcji (9.8.17 Telemetria z zachowaniem prywatności).
• [C-0-5] NALEŻY zapewnić użytkownikowi możliwość włączenia lub wyłączenia zbierania, wykorzystywania i udostępniania danych telemetrycznych w celu ochrony prywatności.
• [C-0-6] NALEŻY umożliwić użytkownikowi usunięcie danych, które aplikacja gromadzi, jeśli są one przechowywane w dowolnej formie na urządzeniu. Jeśli użytkownik zdecyduje się na wymazanie danych, musi usunąć wszystkie dane aktualnie zapisane na urządzeniu.
• [C-0-7] NALEŻY ujawnić implementację protokołu chroniącego prywatność w repozytorium open source.
• [C-0-8 ]NALEŻY wdrożyć zasady dotyczące wychodzących danych w tej sekcji, aby ograniczyć zbieranie danych w kategoriach danych objętych ograniczeniami zdefiniowanych w StatsLog.

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 zawarte 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 i ACTION_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;

Uwaga: implementacje urządzeń, które zostały dostarczone z poziomem interfejsu API 28 lub niższym i nie spełniają wymagań w sekcji 9.9.2, muszą zostać zaktualizowane za pomocą aktualizacji oprogramowania systemowego tak, aby spełniały wymagania w sekcji 9.9 dokumentu Definicja zgodności z Androidem odpowiadające poziomowi interfejsu API, z którym urządzenie zostało dostarczone.

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 tylko wtedy, gdy użytkownik odblokuje urządzenie, podając swoje dane logowania (np. kod dostępu, kod PIN, wzór lub odcisk palca), i gdy zostanie wysłane powiadomienie 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ść pliku i metadane systemu plików za pomocą AES-256-XTS lub Adiantum. AES-256-XTS odnosi się do standardu Advanced Encryption Standard (AES) z 256-bitowym kluczem szyfrującym, który działa w trybie XTS; pełna długość klucza to 512 bitów.Adiantum odnosi się do Adiantum-XChaCha12-AES, jak określono na stronie https://github.com/google/adiantum. Metadane systemu plików to dane takie jak 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, AES-256-HCTR2 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 ARM 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), aby wyprowadzić dowolne klucze podrzędne (np. klucze na poziomie pliku) z kluczy CE i DE. „Silnie szyfrowane i nieodwracalne” oznacza, że funkcja derywacji klucza ma moc szyfrowania co najmniej 256 bitów i działa jako 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 różnych 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.

Uwaga: implementacje urządzeń z poziomem interfejsu API 28 lub niższym, które nie spełniają wymagań w sekcji 9.9.3, muszą zostać zaktualizowane za pomocą aktualizacji oprogramowania systemowego. W tym celu należy spełnić wymagania w sekcji 9.9 dokumentu Definicja zgodności Androida odpowiadające poziomowi interfejsu API, na którym urządzenie zostało dostarczone.

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 szyfrowane 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 Linux „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ć, aby w przypadku, gdy urządzenie wpadnie w ręce atakującego, było dla niego bardzo trudne odzyskanie 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 wewnętrznych zagrożeń zakładamy też, że atakujący uzyska dostęp do kluczy 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 weryfikowanego uruchamiania w wersji Androida wcześniejszej niż 8.0 i nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, mogą być zwolnione z tego wymogu.

Weryfikacja podczas uruchamiania to funkcja, która gwarantuje integralność oprogramowania urządzenia. Jeśli implementacje urządzeń obsługują tę funkcję, mogą:

• [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-1-8] NALEŻY używać pamięci z funkcją wykrywania manipulacji: 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).

Nowe wymagania dotyczące Androida 15

• [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-14] NALEŻY zweryfikować podpis co najmniej raz podczas każdego uruchomienia w przypadku pakietów z dozwolonej listy, które są wymienione jako require-strict-signature w konfiguracji systemu.

Koniec nowych wymagań

• [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 wczytywanych przez aplikację uprzywilejowaną spoza pliku APK (np. kodu wczytywanego dynamicznie lub skompilowanego kodu) 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.

Nowe wymagania dotyczące Androida 15

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ą one być zwolnione z tych wymagań.

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

Jeśli implementacje na urządzeniu umożliwiają weryfikację zawartości pliku na podstawie każdej strony, to:

• [C-2-1] Obsługa weryfikacji treści pliku za pomocą szyfrowania bez odczytania całego pliku.

• [C-2-2] NIE wolno zezwalać na odczytywanie żądań dotyczących chronionego pliku, jeśli treści nie zostały zweryfikowane zgodnie z opisem w [C-2-1] powyżej.

• [C-2-4] W przypadku włączonych plików MUSI zwracać sumy kontrolne plików w czasie O(1).

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.

Nowe wymagania dotyczące Androida 15

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 the ConfirmationPrompt.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 jeśli system operacyjny Android (w tym jego jądro) został naruszony.

Koniec nowych wymagań

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ć zaimportowanie lub wygenerowanie 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, interwał 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 (w zależności 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 i HMAC oraz funkcji haszowania MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać obsługiwane przez system Android Keystore 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 na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w odizolowanym środowisku wykonania. Projekt Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.

Nowe wymagania dotyczące Androida 15

• [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 za pomocą certyfikatu MUSZĄ być udostępnione na wystarczająco dużej liczbie urządzeń, aby uniemożliwić użycie tych kluczy jako trwałych identyfikatorów urządzeń.

  Uwaga: aby spełnić to wymaganie, musisz udostępnić ten sam klucz uwierzytelniający dla danego kodu SKU,chyba że wyprodukowano co najmniej 100 tys. jednostek danego tego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, w przypadku kolejnych grup po 100 tys. jednostek można użyć innego klucza. Można też użyć rozwiązania do zdalnego udostępniania kluczy, aby udostępnić na urządzeniu krótkotrwałe klucze poświadczania.

Koniec nowych wymagań

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 metody biometryczne lub słabsze metody trzeciorzędowe.

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.

• [C-0-1] NALEŻY ograniczyć liczbę nieudanych prób uwierzytelnienia podstawowego.

• [C-SR-5] ZALECAMY, aby wdrożyć górną granicę 20 nieudanych prób uwierzytelnienia podstawowego. Jeśli użytkownicy wyrażą zgodę i zdecydują się na korzystanie z tej funkcji, po przekroczeniu limitu nieudanych prób uwierzytelnienia podstawowego należy wykonać „reset danych do ustawień fabrycznych”.

Jeśli implementacje urządzeń ustawiają numeryczny kod PIN jako zalecaną podstawową metodę uwierzytelniania, należy:

• [C-SR-6] W przypadku kodu PIN ZALECAMY, aby miał co najmniej 6 cyfr, co odpowiada 20-bitowej entropii.
• [C-SR-7] W przypadku kodu PIN o długości mniejszej niż 6 cyfr MOCNO ZALECAMY, aby nie zezwalać na automatyczne wpisywanie bez interakcji użytkownika, aby uniknąć ujawnienia długości kodu PIN.

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 długości 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 szyfrującego, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures() z dowolnym z powiązanych flag biometrycznych (np. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE lub KEYGUARD_DISABLE_IRIS).

Jeśli metody uwierzytelniania biometrycznego nie spełniają wymagań klasy 3 (dawniej silnego), o których mowa 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] Musisz mieć 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.
• [C-6-3] Użytkownik MUSI zostać poproszony o odpowiednie uwierzytelnienie za pomocą jednej z zalecanych podstawowych metod (np. kodu PIN, wzoru lub hasła) 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 poniżej.

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 opóźniona 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ła KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NIE NALEŻY w pełni wdrażać funkcji TrustAgentService.addEscrowToken() na urządzeniu używanym jako podstawowe urządzenie osobiste (np. 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 powiernikowego 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-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. 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ą metody DevicePolicyManager.setRequiredPasswordComplexity() z bardziej restrykcyjną stałą złożoności niż „PASSWORD_COMPLEXITY_NONE”.
• [C-8-2] Nie wolno resetować liczników czasu ważności hasła ustawionych przez DevicePolicyManager.setPasswordExpirationTimeout().
• [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 ekranów wirtualnych i obsługę powiązanych zdarzeń wejściowych, np. 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 wirtualnych urządzeń dla każdego użytkownika

Nowe wymagania dotyczące Androida 15

• [C-10-6] Należy wyłączyć tworzenie powiązanych zdarzeń wejściowych za pomocą VirtualDeviceManager, gdy jest to wskazane przez strumieniowe przesyłanie danych z aplikacji, jak to wskazano w dokumentacji DevicePolicyManager.setNearbyAppStreamingPolicy.

Koniec nowych wymagań

Nowe wymagania dotyczące Androida 15

• [C-10-7] MUSISZ:
  • Wyłączanie używania schowka
  • Włącz osobny schowek dla każdego urządzenia, które obsługuje schowek

• [C-10-7] NALEŻY używać oddzielnego schowka tylko dla każdego urządzenia wirtualnego (lub wyłączyć schowek dla urządzeń wirtualnych).

Koniec nowych wymagań

• [C-10-11] NALEŻY wyłączyć interfejs uwierzytelniania na urządzeniach wirtualnych, w tym pole hasła i prośbę o dane biometryczne

Nowe wymagania dotyczące Androida 15

• [C-10-12] NALEŻY ograniczyć intencje inicjowane z urządzenia wirtualnego tak, aby były wyświetlane tylko na tym samym urządzeniu wirtualnym

Koniec nowych wymagań

• [C-10-13] Nie wolno używać stanu blokady wirtualnego urządzenia jako uwierzytelniania użytkownika w systemie Android Keystore. Zobacz KeyGenParameterSpec.Builder.setUserAuthentication*.

Nowe wymagania dotyczące Androida 15

• [C-10-14] NALEŻY umożliwić użytkownikowi udostępnianie schowka między urządzeniami przed udostępnieniem danych schowka między urządzeniami fizycznymi i wirtualnymi, jeśli urządzenie obsługuje udostępnianie schowka.
• [C-10-15] NALEŻY wyświetlać powiadomienia, gdy dane ze schowka są dostępne na różnych urządzeniach, oraz NALEŻY uniemożliwić dostęp do treści po upływie 1 minuty od momentu początkowego udostępnienia.

Koniec nowych wymagań

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 element zaufania, który wywołuje interfejs API systemu TrustAgentService.grantTrust() 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 użytkownika.
• [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 stanu TrustState.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.

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.

Nowe wymagania dotyczące Androida 15

• [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, and FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.

Koniec nowych wymagań

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 określone w sekcji 9.11.1 lub danych biometrycznych spełniających co najmniej wymagania klasy 1 określone w sekcji 7.3.10, aby umożliwić niezależne odblokowywanie z poziomu domyślnego ekranu 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 nieprzewidywalne wyniki.

• [C-1-7] MUSI być odporny na próby manipulacji, w tym na włamanie się do niego fizycznie i na zakłócanie.

• [C-1-8] MUSI zapewniać odporność na kanały boczne, w tym na wyciek informacji przez kanały zasilania, czasu, promieniowania elektromagnetycznego i cieplnego.

• [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], wdrożenia na urządzeniu:

Nowe wymagania dotyczące Androida 15

• [C-1-10] MUSI zawierać sprzęt z certyfikatem zgodności z profilem ochrony karty inteligentnej BSI-CC-PP-0084-2014 lub BSI-CC-PP-0117-2022, lub musi zostać oceniony przez akredytowane na poziomie krajowym laboratorium testowe, uwzględniając ocenę podatności na ataki o wysokim potencjale zgodnie z kryteriami Common Criteria dla kart inteligentnych.

Koniec nowych wymagań

• [C-1-11] MUSI zawierać oprogramowanie sprzętowe, które zostało ocenione przez akredytowane na poziomie krajowym laboratorium testowe, uwzględniające ocenę podatności na ataki o wysokim potencjale zgodnie z kryteriami Common Criteria w przypadku kart inteligentnych.
• [C-SR-2] MOCNO POLECAMY uwzględnienie sprzętu, który został oceniony za pomocą Security Target, Evaluation Assurance Level (EAL) 5, uzupełnionego o AVA_VAN.5. Certyfikat EAL 5 prawdopodobnie stanie się wymagany w kolejnych wersjach.
• [C-SR-3] ZALECAMY zapewnienie odporności na ataki z zewnątrz (IAR), co oznacza, że osoba z dostępem do kluczy do podpisywania oprogramowania nie może wygenerować oprogramowania, które powoduje wyciek tajemnic StrongBox, obejście wymagań bezpieczeństwa funkcjonalnego lub w inny sposób umożliwi dostęp do poufnych danych użytkownika. Zalecane jest, aby umożliwić 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ści, muszą:

• [C-1-1] W przypadku metody 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óra może służyć do implementacji 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 mogą działać tylko wstępnie zainstalowane aplikacje systemowe, a 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 opcję 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ą kopiowanych danych aplikacji do tych skonfigurowanych przez dewelopera aplikacji w pliku manifestu 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 uzyskać potwierdzenie od użytkownika, że chce on skopiować dane na urządzeniu źródłowym, zanim zostaną one przeniesione.
• [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

Nowe wymagania dotyczące Androida 15

Interfejsy API Android Virtualization Framework (AVF) (android.system.virtualmachine.*) umożliwiają aplikacjom tworzenie na urządzeniu chronionych (pVM) i niechronionych (non-pVM) maszyn wirtualnych, które wczytują i uruchamiają natywnych binarnych plików danych.

Jeśli implementacje urządzenia ustawiają FEATURE_VIRTUALIZATION_FRAMEWORK na true, to:

• [C-1-1] Należy zapewnić, aby funkcja android.system.virtualmachine.VirtualMachineManager.getCapabilities() zwracała jedną z tych wartości:
  • CAPABILITY_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

Koniec nowych wymagań

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ń wprowadzenie 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 wysyłki.

• [C-0-2] Musisz zapewnić zgodność w przypadku niejednoznaczności w CTS oraz w przypadku każdej ponownej implementacji 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 15 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, takich jak prawidłowe działanie kamery i czujników.

Implementacje na urządzeniu:

• [C-0-1] MUSI prawidłowo 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, implementatorzy urządzeń nie muszą uruchamiać narzędzia 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ć aktualizacji „na żywo”, 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 pamięci wymiennej.

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

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 użytkowania 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:

• Zmiany w dokumentacji

13. Skontaktuj się z nami

Możesz dołączyć do forum dotyczącego zgodności z Androidem i poprosić o wyjaśnienia lub zgłosić problemy, które nie zostały opisane w dokumencie.