Definicja zgodności z Androidem 11

1. Wprowadzenie

W tym dokumencie opisujemy wymagania, które muszą zostać spełnione, aby urządzenia były zgodne z Androidem 11.

Sformułowania „MUSISZ”, „NIE MOŻE”, „WYMAGANE”, „MUSZĄ”, „NIE POWINNY”, „NIE POWINNY”, „ZALECANE”, „MOŻLIWE” i „OPCJONALNIE” są zgodne ze standardem IETF zdefiniowanego w RFC2119.

Używany w tym dokumencie „program wdrażający urządzenie” to osoba lub organizacja opracowująca sprzęt lub oprogramowanie działające na Androidzie 11. „implementacja na urządzeniu” lub „wdrożenie”. to rozwiązanie sprzętowo-oprogramowania.

Aby urządzenia zostały uznane za zgodne z Androidem 11, MUSZĄ one spełniać wymagania przedstawione w tej definicji zgodności, w tym wszelkie dokumenty dołączając do nich przez odwołanie.

Jeśli ta definicja lub testy oprogramowania opisane w sekcji 10 są dyskretne, niejednoznaczne lub niepełne, to osoba implementująca urządzenie odpowiada za zgodność z istniejącymi implementacjami.

Z tego powodu Android Open Source Project jest zarówno referencją, jak i preferowaną implementacją Androida. ZAWSZE ZALECANE są rozwiązania implementujące urządzenia w maksymalnym możliwym stopniu na podstawie kodu źródłowego „nadrzędnego” dostępnego w ramach projektu Android Open Source Project. Chociaż niektóre komponenty można hipotetycznie zastąpić innymi, Zdecydowanie ZALECANE jest nie stosować tej praktyki, ponieważ zaliczenie testów oprogramowania będzie znacznie trudniejsze. Odpowiada on za zapewnienie pełnej zgodności ze standardową implementacją Androida, w tym z pakietem Compatibility Test Suite i nie tylko. Pamiętaj też, że ten dokument wyraźnie zabrania używania określonych zamienników i modyfikacji komponentów.

Wiele zasobów, do których prowadzą linki w tym dokumencie, pochodzi bezpośrednio lub pośrednio z pakietu Android SDK i będzie działać tak samo jak informacje zawarte w dokumentacji pakietu SDK. W każdym przypadku, gdy ta definicja zgodności lub pakiet Compatibility Test Suite nie zgadza się z dokumentacją pakietu SDK, jest ona uznawana za miarodajną. Wszelkie szczegóły techniczne wymienione w zasobach, do których prowadzą linki w tym dokumencie, uznaje się za uwzględnione w tej definicji zgodności.

1.1 Struktura dokumentu

1.1.1 Wymagania według typu urządzenia

Sekcja 2 zawiera wszystkie wymagania dotyczące określonego typu urządzenia. Każda podsekcja w sekcji 2 jest poświęcona konkretnemu typowi urządzenia.

Wszystkie pozostałe wymagania, które obowiązują we wszystkich implementacjach urządzeń z Androidem, zostały wymienione w sekcjach po Sekcji 2. Wymagania te noszą się jako „Podstawowe wymagania”. w tym dokumencie.

1.1.2 Identyfikator wymagania

W przypadku wymagań MUSZĄ przypisano identyfikator wymagania.

• Identyfikator jest przypisywany tylko w przypadku wymagań MUST.
• Zdecydowanie ZALECANE wymagania są oznaczone jako [SR], ale identyfikator nie jest przypisany.
• Identyfikator składa się z tych elementów : identyfikator typu urządzenia – identyfikator warunku – identyfikator wymagania (np. C-0-1).

Każdy identyfikator jest zdefiniowany poniżej:

• Identyfikator typu urządzenia (więcej informacji znajdziesz w sekcji 2. typy urządzeń)
  • C: podstawowy (wymagania dotyczące wszystkich implementacji na urządzeniach z Androidem)
  • H: przenośne urządzenie z Androidem
  • T: urządzenie z Androidem TV
  • O: Wdrożenie Androida Automotive
  • W: Implementacja na zegarku Android Watch
  • Karta: Implementacja na tabletach z Androidem
• Identyfikator warunku
  • Gdy wymaganie jest bezwarunkowe, ten identyfikator ma wartość 0.
  • Gdy wymaganie jest warunkowe, do pierwszego warunku zostaje przypisana wartość 1, a liczba zwiększa się o 1 w tej samej sekcji i na tym samym typie urządzenia.
• Identyfikator wymagania
  • Ten identyfikator rozpoczyna się od 1 i zwiększa o 1 w tej samej sekcji i w tym samym warunku.

1.1.3 Identyfikator wymagania w sekcji 2

Identyfikator wymagania w sekcji 2 zaczyna się od odpowiedniego identyfikatora sekcji, po którym następuje identyfikator wymagania opisany powyżej.

• Identyfikator w sekcji 2 składa się z tych elementów : identyfikator sekcji / identyfikator typu urządzenia – identyfikator warunku – identyfikator wymagania (np. 7.4.3/A-0-1).

2. Typy urządzeń

Projekt Android Open Source Project zapewnia pakiet oprogramowania przystosowany do różnych typów urządzeń i formatów. Istnieją jednak typy urządzeń o względnie lepiej rozwiniętym ekosystemie dystrybucji aplikacji.

W tej sekcji znajdziesz opis tych typów 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 wymienione w pozostałych sekcjach tej definicji zgodności.

2.1 Konfiguracje urządzeń

Informacje o głównych różnicach w konfiguracji sprzętu w zależności od typu urządzenia można znaleźć w poniższych wymaganiach dotyczących konkretnych urządzeń.

2.2. Wymagania dotyczące urządzenia mobilnego

Urządzenie mobilne z Androidem to implementacja urządzenia z Androidem, w którym zazwyczaj trzymasz urządzenie w dłoni, np. odtwarzacz mp3, telefon czy tablet.

Implementacje na urządzeniach z Androidem zaliczamy do urządzeń mobilnych, jeśli spełniają wszystkie te kryteria:

• mieć źródło zasilania, które pozwala na mobilność, np. baterię.
• mieć fizyczny ekran o przekątnej ekranu z przekątną od 3,3 cala (lub 2,5 cala w przypadku urządzeń uruchomionych na poziomie interfejsu API starszym niż Android 11) do 8 cali.

Dodatkowe wymagania opisane w pozostałej części tej sekcji dotyczą implementacji na urządzeniach mobilnych z Androidem.

Uwaga: wymagania, które nie dotyczą tabletów z Androidem, są oznaczone symbolem *.

2.2.1. Sprzęt

Implementacje na urządzeniach mobilnych:

• [7.1.1.1/H-0-1] MUSI mieć co najmniej jeden wyświetlacz zgodny z Androidem, który spełnia wszystkie wymagania opisane w tym dokumencie.
• [7.1.1.3/H-SR] Zdecydowanie ZALECANE jest umożliwienie użytkownikom zmiany rozmiaru wyświetlacza (gęstości ekranu).

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

• [7.1.1.1/H-1-1]* Ekran logiczny udostępniany aplikacjom innych firm MUSI mieć co najmniej 2 cale od krótszej krawędzi i 2,7 cala od dłuższej. Nie dotyczy to urządzeń, które zostały uruchomione na poziomie interfejsu API wcześniej niż ten dokument.

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

• [7.1.1.1/H-2-1]* Ekran logiczny udostępniany aplikacjom innych firm MUSI mieć co najmniej 2,7 cala od krótszej krawędzi. Nie dotyczy to urządzeń, które zostały uruchomione na poziomie interfejsu API wcześniej niż ten dokument.

Jeśli implementacji na urządzeniach mobilnych zapewniają obsługę wyświetlaczy o wysokim zakresie dynamiki (Configuration.isScreenHdr()), oznacza to, że:

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

• [7.1.4.6/H-0-1] MUSI podawać za pomocą właściwości systemowej graphics.gpu.profiler.support informację o tym, czy urządzenie obsługuje funkcję profilowania GPU.

Jeśli implementacje urządzeń mobilnych deklarują obsługę za pomocą właściwości systemowej graphics.gpu.profiler.support:

• [7.1.4.6/H-1-1] MUSI generować raport jako ślad protokołu zgodny ze schematem liczników GPU i procesorów renderowania GPU zdefiniowanych w dokumentacji Perfetto.
• [7.1.4.6/H-1-2] MUSI zgłaszać zgodne wartości liczników GPU urządzenia po protokole śledzenia pakietu GPU licznika.
• [7.1.4.6/H-1-3] MUSI zgłaszać zgodne wartości w procesie renderowania GPU urządzenia po protoku śledzenia pakietów śledzenia etapu renderowania.
• [7.1.4.6/H-1-4] MUSI zgłaszać punkt śledzenia częstotliwości GPU w formacie power/gpu_frequency.

Implementacje na urządzeniach mobilnych:

• [7.1.5/H-0-1] MUSI obsługiwać starszy tryb zgodności aplikacji w obecnej wersji kodu open source Androida. Oznacza to, że implementacje urządzenia NIE MOGĄ zmieniać wyzwalaczy ani progów, po których aktywowany jest tryb zgodności. NIE MOGĄ też zmieniać działania samego trybu zgodności.
• [7.2.1/H-0-1] MUSI obsługiwać zewnętrzne aplikacje edytora metody wprowadzania (IME).
• [7.2.3/H-0-3] MUSI zapewniać funkcję ekranu głównego na wszystkich wyświetlaczach zgodnych z Androidem, które obsługują ekran główny.
• [7.2.3/H-0-4] MUSI zapewniać funkcję Wstecz na wszystkich wyświetlaczach zgodnych z Androidem, a funkcję Ostatnie na co najmniej jednym z wyświetlaczy zgodnych z Androidem.
• [7.2.3/H-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno zdarzenie normalnego, jak i przytrzymania funkcji Back (KEYCODE_BACK). System NIE MOŻE być wywoływany przez system poza urządzeniem z Androidem (np. zewnętrzna klawiatura sprzętowa podłączona do urządzenia z Androidem).
• [7.2.4/H-0-1] MUSI obsługiwać wprowadzanie na ekranie dotykowym.
• [7.2.4/H-SR] Zdecydowanie ZALECANE jest uruchamianie wybranej przez użytkownika aplikacji asystującej, czyli aplikacji, która zawiera usługę VoiceInteractionService, lub działania obsługującego ACTION_ASSIST po przytrzymaniu przycisku KEYCODE_MEDIA_PLAY_PAUSE lub KEYCODE_HEADSETHOOK, jeśli działanie na pierwszym planie nie obsługuje zdarzeń przytrzymania.
• [7.3.1/H-SR] Zdecydowanie ZALECANE jest dodanie 3-osiowego akcelerometru.

Jeśli implementacje urządzeń mobilnych obejmują 3-osiowy akcelerometr:

• [7.3.1/H-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 100 Hz.

Jeśli implementacje urządzeń mobilnych obejmują odbiornik GPS/GNSS i zgłaszają takie możliwości aplikacjom za pomocą flagi funkcji android.hardware.location.gps, muszą one:

• [7.3.3/H-2-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną wykryte, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie jest jeszcze raportowana.
• [7.3.3/H-2-2] MUSI podawać wartości pseudozakresów i wskaźników pseudozakresowych GNSS po określeniu lokalizacji, że w warunkach na świeżym powietrzu po określeniu lokalizacji, gdy nieruchomo lub w ruchu z przyspieszeniem poniżej 0,2 metra na sekundę do kwadratu, wystarczają do obliczenia pozycji z dokładnością do 20 metrów, a prędkość do 0,9 metra na sekundę z dokładnością co najmniej 0,9 metra na sekundę.

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

• [7.3.4/H-3-1] MUSI raportować zdarzenia z częstotliwością co najmniej 100 Hz.
• [7.3.4/H-3-2] MUSI być w stanie mierzyć zmiany orientacji kamery do 1000 stopni na sekundę.

Implementacje urządzeń mobilnych, które umożliwiają wykonywanie połączeń głosowych i wskazują dowolną wartość inną niż PHONE_TYPE_NONE w getPhoneType:

• [7.3,8/H] POWINNY jest zawierać czujnik zbliżeniowy.

Implementacje na urządzeniach mobilnych:

• [7.3.11/H-SR] Są zalecane do obsługi czujnika pozycji z 6 stopniami swobody.
• [7.4.3/H] POWINNA obejmować obsługę Bluetootha i Bluetooth LE.

Jeśli implementacje na urządzeniach mobilnych obejmują połączenie z pomiarem użycia danych:

• [7.4.7/H-1-1] MUSI mieć włączony tryb oszczędzania danych.

Jeśli implementacje urządzeń mobilnych obejmują aparat logiczny z listą możliwości za pomocą CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA:

• [7,5,4/H-1-1] domyślnie MUSI mieć normalne pole widzenia, a muszą mieścić się w zakresie od 50 do 90 stopni.

Implementacje na urządzeniach mobilnych:

• [7.6.1/H-0-1] MUSI mieć co najmniej 4 GB nieulotnego miejsca na prywatne dane aplikacji (partycja „/data”).
• [7.6.1/H-0-2] MUSI zwracać wartość „true” (prawda) w przypadku ActivityManager.isLowRamDevice(), gdy w jądrze i przestrzeni użytkownika dostępnych jest mniej niż 1 GB pamięci.

Jeśli implementacje na urządzeniach mobilnych deklarują obsługę tylko 32-bitowego interfejsu ABI:

• [7.6.1/H-1-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 416 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora klatki do wartości qHD (np. FWVGA).

• [7.6.1/H-2-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 592 MB, jeśli wyświetlacz domyślny używa buforów klatek o rozdzielczości do HD+ (np. HD, WSVGA).

• [7.6.1/H-3-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 896 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora klatki do FHD (np. WSXGA+).

• [7.6.1/H-4-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 1344 MB, jeśli domyślny wyświetlacz używa rozdzielczości bufora klatek do QHD (np. QWXGA).

Jeśli implementacje na urządzeniach mobilnych deklarują obsługę dowolnego 64-bitowego interfejsu ABI (z 32-bitowym ABI lub bez):

• [7.6.1/H-5-1] Jeśli domyślny wyświetlacz używa rozdzielczości bufora klatek do wartości qHD (np. FWVGA), pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 816 MB.

• [7.6.1/H-6-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 944 MB, jeśli wyświetlacz domyślny używa buforów klatek o rozdzielczości do HD+ (np. HD, WSVGA).

• [7.6.1/H-7-1] Jeśli domyślny wyświetlacz używa rozdzielczości bufora klatek do FHD (np. WSXGA+), pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 1280 MB.

• [7.6.1/H-8-1] Jeśli domyślny wyświetlacz używa rozdzielczości bufora klatek do QHD (np. QWXGA), pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 1824 MB.

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do miejsca w pamięci, które jest dostępne jako uzupełnienie pamięci przeznaczonej już na komponenty sprzętowe, takie jak radio czy obraz, które nie są pod kontrolą jądra implementacji urządzenia.

Jeśli implementacje urządzeń mobilnych obejmują mniej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

• [7.6.1/H-9-1] MUSI zadeklarować flagę funkcji android.hardware.ram.low.
• [7.6.1/H-9-2] MUSI mieć co najmniej 1,1 GB nieulotnego miejsca na prywatne dane aplikacji (partycja „/data”).

Jeśli implementacje urządzeń mobilnych obejmują więcej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

• [7.6.1/H-10-1] MUSI mieć co najmniej 4 GB wolnej pamięci nieulotnej na prywatne dane aplikacji (partycja „/data”).
• NALEŻY zadeklarować flagę funkcji android.hardware.ram.normal.

Implementacje na urządzeniach mobilnych:

• [7.6.2/H-0-1] NIE MOŻE udostępniać pamięci współdzielonej aplikacji mniejszej niż 1 GiB.
• [7.7.1/H] POWINNY jest mieć port USB obsługujący tryb peryferyjny.

Jeśli urządzenia mobilne są wyposażone w port USB obsługujący tryb peryferyjny, te funkcje:

• [7.7.1/H-1-1] MUSI wdrożyć interfejs Android Open Accessory API (AOA).

Jeśli implementacje urządzeń mobilnych są wyposażone w port USB obsługujący tryb hosta:

• [7.7.2/H-1-1] MUSI zaimplementować klasę audio USB zgodnie z dokumentacją pakietu Android SDK.

Implementacje na urządzeniach mobilnych:

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

Jeśli implementacje urządzeń mobilnych mogą spełnić wszystkie wymagania dotyczące wydajności działania trybu VR i obsługują ten tryb, to:

• [7.9.1/H-1-1] MUSI zadeklarować flagę funkcji android.hardware.vr.high_performance.
• [7.9.1/H-1-2] MUSI zawierać aplikację z wdrożeniem android.service.vr.VrListenerService, która może być włączona przez aplikacje VR za pomocą android.app.Activity#setVrModeEnabled.

Jeśli implementacje urządzeń mobilnych obejmują co najmniej jeden port USB-C w trybie hosta i zaimplementujesz funkcję (klasa audio USB), oprócz wymagań opisanych w sekcji 7.7.2:

• [7.8.2.2/H-1-1] MUSI zawierać następujące oprogramowanie mapowania kodów HID:

Funkcja	Odwzorowania	Kontekst	Działanie
A	Strona o wykorzystaniu HID: 0x0C Użycie HID: 0x0CD Klucz jądra: KEY_PLAYPAUSE Klucz Androida: KEYCODE_MEDIA_PLAY_PAUSE	Odtwarzanie multimediów	Wejście: krótkie naciśnięcie Dane wyjściowe: odtwarzanie lub wstrzymywanie.
			Wejście: przytrzymaj Wyniki: Uruchom polecenie głosowe Wysłane: android.speech.action.VOICE_SEARCH_HANDS_FREE, gdy urządzenie jest zablokowane lub jego ekran jest wyłączony. W przeciwnym razie zostanie wysłana android.speech.RecognizerIntent.ACTION_WEB_SEARCH
		Połączenie przychodzące	Wejście: krótkie naciśnięcie Dane wyjściowe: Odbierz połączenie.
			Wejście: przytrzymaj Wyniki: Odrzuć połączenie
		Trwa rozmowa	Wejście: krótkie naciśnięcie Wyniki: Zakończ połączenie
			Wejście: przytrzymaj Wyjście: wycisz lub wyłącz wyciszenie mikrofonu.
B	Strona o wykorzystaniu HID: 0x0C Wykorzystanie HID: 0x0E9 Klucz jądra: KEY_VOLUMEUP Klucz Androida: VOLUME_UP	Odtwarzanie multimediów, rozmowa trwa	Wejście: krótkie lub długie naciśnięcie Wyjście: zwiększa głośność zestawu słuchawkowego lub systemu.
C	Strona o wykorzystaniu HID: 0x0C Wykorzystanie HID: 0x0EA Klucz jądra: KEY_VOLUMEDOWN Klucz Androida: VOLUME_DOWN	Odtwarzanie multimediów, rozmowa trwa	Wejście: krótkie lub długie naciśnięcie Wyjście: zmniejsza głośność systemu lub zestawu słuchawkowego.
D	Strona o wykorzystaniu HID: 0x0C Wykorzystanie HID: 0x0CF Klucz jądra: KEY_VOICECOMMAND Klucz Androida: KEYCODE_VOICE_ASSIST	Wszystkie. Może zostać aktywowany w każdej instancji.	Wejście: krótkie lub długie naciśnięcie Wyniki: Uruchom polecenie głosowe.

• [7.8.2.2/H-1-2] MUSI wywołać ACTION_HEADSET_PLUG po włożeniu wtyczki, ale dopiero po prawidłowym wyliczeniu interfejsów audio i punktów końcowych USB, aby można było zidentyfikować typ podłączonego złącza.

Po wykryciu złącza audio USB typu 0x0302:

• [7.8.2.2/H-2-1] MUSI transmitować intencję ACTION_HEADSET_PLUG i „mikrofon” dodatkowe ustawienie na 0.

Po wykryciu złącza audio USB typu 0x0402:

• [7.8.2.2/H-3-1] MUSI transmitować intencję ACTION_HEADSET_PLUG i „mikrofon” dodatkowe ustawienie ma wartość 1.

Gdy wywoływana jest funkcja API AudioManager.getDevices(), gdy urządzenie peryferyjne USB jest podłączone:

• [7.8.2.2/H-4-1] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i rolę isSink(), jeśli pole typu złącza USB audio to 0x0302.

• [7.8.2.2/H-4-2] Jeśli pole typu złącza USB audio to 0x0402, MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i rolę isSink().

• [7.8.2.2/H-4-3] Jeśli pole typu złącza USB audio to 0x0402, MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i role isSource().

• [7.8.2.2/H-4-4] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i rolę isSink(), jeśli pole typu złącza USB audio to 0x603.

• [7.8.2.2/H-4-5] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSource(), jeśli pole typu złącza USB audio to 0x604.

• [7.8.2.2/H-4-6] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i rolę isSink(), jeśli pole typu złącza USB audio to 0x400.

• [7.8.2.2/H-4-7] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSource(), jeśli pole typu złącza USB audio to 0x400.

• [7.8.2.2/H-SR] Zdecydowanie ZALECANE są po podłączeniu urządzenia peryferyjnego audio USB-C. Umożliwiają wyliczanie deskryptorów USB, identyfikowanie typów złączy i przesyłanie intencji ACTION_HEADSET_PLUG w czasie krótszym niż 1000 milisekund.

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

• [7.10/H-SR]* Zdecydowanie NIE ZALECAMY korzystania z nieśrodkowego mechanizmu haptycznego (wibratora) z nieśrodkową obrotową masą(ERM).
• [7.10/H]* NALEŻY umieścić urządzenie wykonawcze w pobliżu miejsca, w którym urządzenie zazwyczaj jest trzymane lub dotykane dłońmi.
• [7.10/H-SR]* Zdecydowanie ZALECANE jest wdrożenie wszystkich stałych publicznych dla wyraźnych reakcji haptycznych w android.view.HapticfeedbackConstants, czyli CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_KEY, KEYBOARD_TAP, LONG_MOVLE, i LONG_PRESS.
• [7.10/H-SR]* Zdecydowanie ZALECANE jest wdrożenie wszystkich stałych publicznych dla działania wyraźnej reakcji haptycznej w android.os.VibrationEffect, a w szczególności (EFEK_TICK, EFFECT_CLICK, SKU_HEAVY_KLIKNIJ i SKUF_DOUBLE_KLIKNIJ), a także wszystkie publiczne stałe (w kwocie PRITKposition.Combration oraz PRITosposition.
• [7.10/H-SR]* Zdecydowanie ZALECANE jest korzystanie z tych połączonych stałych haptycznych map.
• [7.10/H-SR]* Zdecydowanie ZALECANE jest wykonanie oceny jakości interfejsów API createOneShot() i createWaveform().
• [7.10/H-SR]* Zdecydowanie ZALECANE jest zweryfikowanie możliwości skalowalności amplitudy przez uruchomienie polecenia android.os.Vibrator.hasAmplitudeControl().

Liniowy rezonator rezonansowy (LRA) to układ ze sprężynami o pojedynczej masie, w którym dominuje częstotliwość rezonansowa, w której masa przewija się w kierunku pożądanego ruchu.

Jeśli implementacje urządzeń mobilnych obejmują co najmniej jeden liniowy przewodnik po rezonansach:

• [7.10/H]* NALEŻY przesunąć element haptyczny w orientacji pionowej do osi X.

Jeśli urządzenia mobilne są wyposażone w mechanizm haptyczny (LRA), który działa na osi X:

• [7.10/H-SR]* Zdecydowanie ZALECANE jest, aby częstotliwość rezonansowa jednostki LRA na osi X była mniejsza niż 200 Hz.

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

• [7.10/H-SR]* Zdecydowanie ZALECANE jest wykonanie oceny jakości stałych haptycznych.

2.2.2. Multimedia

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać następujące 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 AAC MPEG-4 (AAC LC)
• [5.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
• [5.1/H-0-5] AAC ELD (rozszerzony AAC z niskim opóźnieniem)

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać następujące formaty kodowania wideo i udostępniać je aplikacjom innych firm:

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

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać następujące 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

2.2.3. Oprogramowanie

Implementacje na urządzeniach mobilnych:

• [3.2.3.1/H-0-1] MUSI mieć aplikację, która obsługuje intencje ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE i ACTION_CREATE_DOCUMENT zgodnie z opisem w dokumentach pakietu SDK, oraz umożliwiać użytkownikom dostęp do danych dostawcy dokumentów za pomocą interfejsu API DocumentsProvider.
• [3.2.3.1/H-0-2]* MUSI wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji dla wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj przez poniższe intencje aplikacji.
• [3.2.3.1/H-SR] Zdecydowanie ZALECANE jest wstępne wczytanie aplikacji e-mailowej mogącej obsłużyć intencje ACTION_SENDTO, ACTION_SEND lub ACTION_SEND_MULTIPLE w celu wysłania e-maila.
• [3.4.1/H-0-1] MUSI zawierać pełną implementację interfejsu API android.webkit.Webview.
• [3.4.2/H-0-1] MUSI zawierać samodzielną aplikację przeglądarki do przeglądania internetu przez zwykłych użytkowników.
• [3.8.1/H-SR] Zdecydowanie ZALECANE jest wdrożenie domyślnego programu uruchamiającego, który obsługuje przypinanie w aplikacji skrótów, widżetów i WidgetFeatures.
• [3.8.1/H-SR] Zdecydowanie ZALECANE jest wdrożenie domyślnego programu uruchamiającego, które zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm przy użyciu interfejsu API ShortcutManager.
• [3.8.1/H-SR] Zdecydowanie ZALECANE jest dodanie domyślnego programu uruchamiającego, który wyświetla plakietki przy ikonach aplikacji.
• [3.8.2/H-SR] Zdecydowanie ZALECANE jest obsługa widżetów aplikacji innych firm.
• [3.8.3/H-0-1] MUSI zezwalać aplikacjom innych firm na powiadamianie użytkowników o ważnych wydarzeniach za pomocą klas interfejsu API Notification i NotificationManager.
• [3.8.3/H-0-2] MUSI obsługiwać powiadomienia rozszerzone.
• [3.8.3/H-0-3] MUSI obsługiwać powiadomienia HUD.
• [3.8.3/H-0-4] MUSI zawierać obszar powiadomień zapewniający użytkownikowi możliwość bezpośredniego sterowania powiadomieniami (np. odpowiadaniem, odkładaniem na później, odrzucaniem, blokowaniem) przy użyciu przycisków poleceń lub panelu sterowania w AOSP.
• [3.8.3/H-0-5] MUSI wyświetlać opcje dostępne w RemoteInput.Builder setChoices() w obszarze powiadomień.
• [3.8.3/H-SR] Zdecydowanie ZALECANE jest wyświetlanie pierwszej opcji dostępnej w RemoteInput.Builder setChoices() w obszarze powiadomień bez dodatkowej interakcji ze strony użytkownika.
• [3.8.3/H-SR] Zdecydowanie ZALECANE jest wyświetlanie wszystkich opcji dostępnych w RemoteInput.Builder setChoices() w obszarze powiadomień, gdy użytkownik rozwinie wszystkie powiadomienia w tym obszarze.
• [3.8.3.1/H-SR] Zdecydowanie ZALECANE jest wyświetlanie działań, dla których funkcja Notification.Action.Builder.setContextual ma ustawienie true obok odpowiedzi wyświetlanych przez Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR] Zdecydowanie ZALECANE jest wdrożenie na urządzeniu asystenta do obsługi działania wspomagającego.

Jeśli implementacje urządzeń mobilnych obsługują działanie wspomagające, mogą one:

• [3.8.4/H-SR] Zdecydowanie ZALECANE jest przytrzymanie klawisza HOME jako wyznaczonej interakcji do uruchomienia aplikacji asystującej, zgodnie z opisem w sekcji 7.2.3. MUSI uruchamiać wybraną przez użytkownika aplikację asystującą, czyli aplikację implementującą VoiceInteractionService lub działanie obsługujące intencję ACTION_ASSIST.

Jeśli implementacje urządzeń mobilnych obsługują conversation notifications i grupują je w osobnej sekcji niż alerty i ciche powiadomienia bez rozmowy, funkcje te:

• [3.8.4/H-1-1]* MUSI wyświetlać przed powiadomieniami inne niż rozmowy powiadomienia o rozmowach, z wyjątkiem bieżących powiadomień usługi na pierwszym planie i powiadomień znaczące:high.

Jeśli implementacje urządzeń mobilnych z Androidem obsługują ekran blokady:

• [3.8.10/H-1-1] MUSI wyświetlać powiadomienia na ekranie blokady, w tym szablon powiadomień o multimediach.

Jeśli implementacje urządzeń mobilnych obsługują bezpieczny ekran blokady:

• [3.9/H-1-1] MUSI wdrożyć pełny zakres zasad administrowania urządzeniami zdefiniowanych w dokumentacji pakietu Android SDK.
• [3.9/H-1-2] MUSI zadeklarować obsługę profili zarządzanych za pomocą flagi funkcji android.software.managed_users, chyba że urządzenie jest skonfigurowane w taki sposób, aby raportowało się jako urządzenie z małą ilością pamięci RAM lub przydzielało pamięć wewnętrzną (niemożliwą) jako pamięć współdzieloną.

Jeśli implementacje urządzeń mobilnych obejmują obsługę interfejsów API ControlsProviderService i Control oraz umożliwiają aplikacjom innych firm publikowanie elementów sterujących urządzeń, to:

• [3.8.16/H-1-1] MUSI zadeklarować flagę funkcji android.software.controls i ustawić ją na true.
• [3.8.16/H-1-2] MUSI zapewniać użytkownikowi możliwość dodawania, edytowania, wybierania i obsługiwania ulubionych elementów urządzenia użytkownika za pomocą elementów sterujących zarejestrowanych przez aplikacje innych firm za pomocą interfejsów API ControlsProviderService i Control.
• [3.8.16/H-1-3] MUSI zapewniać dostęp do tej funkcji użytkownika w ciągu 3 interakcji z domyślnego Menu z aplikacjami.
• [3.8.16/H-1-4] MUSI dokładnie renderować na tym urządzeniu użytkownika nazwę i ikonę każdej aplikacji innej firmy, która udostępnia elementy sterujące za pomocą interfejsu API ControlsProviderService, a także wszelkie określone pola dostarczane przez interfejsy API Control.

Jeśli natomiast implementacje urządzeń mobilnych nie mają takich ustawień, to:

• [3.8.16/H-2-1] MUSI zgłosić null dotyczący interfejsów API ControlsProviderService i Control.
• [3.8.16/H-2-2] MUSI zadeklarować flagę funkcji android.software.controls i ustawić ją na false.

Implementacje na urządzeniach mobilnych:

• [3.10/H-0-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.
• [3.10/H-SR] Zdecydowanie ZALECANE jest wstępne ładowanie na urządzeniu usług ułatwień dostępu porównywalnych lub przekraczających możliwości funkcji ułatwień dostępu Switch Access i TalkBack (w językach obsługiwanych przez wstępnie zainstalowany mechanizm zamiany tekstu na mowę) zgodnie z projektem open source TalkBack.
• [3.11/H-0-1] MUSI obsługiwać instalację silników zamiany tekstu na mowę innych firm.
• [3.11/H-SR] Zdecydowanie ZALECANE jest dodanie mechanizmu zamiany tekstu na mowę obsługującego języki dostępne na urządzeniu.
• [3.13/H-SR] Zdecydowanie ZALECANE jest dodanie komponentu Szybkie ustawienia.

Jeśli implementacje urządzeń mobilnych z Androidem deklarują obsługę FEATURE_BLUETOOTH lub FEATURE_WIFI, będą one spełniać te wymagania:

• [3.16/H-1-1] MUSI obsługiwać funkcję parowania urządzenia towarzyszącego.

Jeśli funkcja nawigacji jest udostępniana na ekranie za pomocą gestów:

• [7.2.3/H] Strefa rozpoznawania gestów w przypadku funkcji Home POWINNA znajdować się u dołu ekranu na wysokości nie większej niż 32 dp.

Jeśli implementacje urządzeń mobilnych oferują funkcję nawigacji w postaci gestu z dowolnego miejsca przy lewej i prawej krawędzi ekranu:

• [7.2.3/H-0-1] Obszar gestów funkcji nawigacji MUSI mieć mniej niż 40 dp szerokości po każdej stronie. Obszar gestu powinien mieć domyślnie szerokość 24 dp.

2.2.4 Wydajność i moc

• [8.1/H-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie renderowania klatki lub opóźnienie renderowania klatek NIE MOGĄ występować częściej niż 5 klatek na sekundę i POWINNY być poniżej 1 klatek na sekundę.
• [8.1/H-0-2] Opóźnienie interfejsu użytkownika. Implementacje na urządzeniach MUSZĄ zapewniać użytkownikom krótki czas oczekiwania przez przewijanie listy 10 tys. pozycji na liście zgodnie z definicją zawartą w narzędziu Android Compatibility Test Suite (CTS) w czasie krótszym niż 36 sekund.
• [8.1/H-0-3] Przełączanie zadań. W przypadku uruchomienia wielu aplikacji ponowne uruchomienie aplikacji już uruchomionej po uruchomieniu MUSI potrwać mniej niż 1 sekundę.

Implementacje na urządzeniach mobilnych:

• [8.2/H-0-1] MUSI zapewniać wydajność sekwencyjnego zapisu na poziomie co najmniej 5 MB/s.
• [8,2/H-0-2] MUSI zapewniać wydajność zapisu przy losowym połączeniu z szybkością co najmniej 0,5 MB/s.
• [8,2/H-0-3] MUSI zapewniać wydajność sekwencyjnego odczytu co najmniej 15 MB/s.
• [8,2/H-0-4] MUSI zapewniać wydajność odczytu w trybie losowym na poziomie co najmniej 3,5 MB/s.

Jeśli implementacje urządzeń mobilnych obejmują funkcje usprawniające zarządzanie energią urządzenia dostępne w AOSP lub rozszerzające funkcje dostępne w ramach AOSP:

• [8.3/H-1-1] MUSI umożliwiać użytkownikom włączanie i wyłączanie funkcji oszczędzania baterii.
• [8.3/H-1-2] MUSI zapewnić użytkownikom możliwość wyświetlania wszystkich aplikacji wyłączonych z trybów czuwania aplikacji i uśpienia.

Implementacje na urządzeniach mobilnych:

• [8.4/H-0-1] MUSI zawierać profil zasilania dla każdego komponentu, który określa wartość bieżącego zużycia energii przez każdy komponent sprzętowy oraz przybliżone zużycie baterii przez komponenty w danym okresie, zgodnie z dokumentem w witrynie Android Open Source Project.
• [8,4/H-0-2] MUSI podawać wszystkie wartości zużycia energii w miliiamperach godzin (mAh).
• [8.4/H-0-3] MUSI raportować zużycie energii procesora przez identyfikator UID każdego procesu. Projekt Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/H-0-4] MUSI udostępnić informacje o zużywaniu energii za pomocą polecenia powłoki adb shell dumpsys batterystats deweloperowi aplikacji.
• [8.4/H] POWINNA być przypisana do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii przez komponent sprzętowy aplikacji.

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

• [8.4/H-1-1] MUSI uwzględniać intencję android.intent.action.POWER_USAGE_SUMMARY i wyświetlać menu ustawień pokazujące to zużycie energii.

2.2.5. Model zabezpieczeń

Implementacje na urządzeniach mobilnych:

• [9.1/H-0-1] MUSI zezwalać aplikacjom innych firm na dostęp do statystyk użytkowania za pomocą uprawnienia android.permission.PACKAGE_USAGE_STATS i udostępniać dostępny dla użytkownika mechanizm przyznawania lub anulowania dostępu do takich aplikacji w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

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

• [9.11/H-0-2]* MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/H-0-3]* MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1 i SHA-2, aby zapewnić prawidłową obsługę algorytmów obsługiwanych przez system magazynu kluczy Androida w miejscu, które jest bezpiecznie odizolowane od kodu działającego w jądrze lub nowszym. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, dzięki którym jądro lub kod przestrzeni użytkownika mogą uzyskiwać dostęp do wewnętrznego stanu odizolowanego środowiska, w tym do aktu o rynkach cyfrowych. Dodatkowy projekt Android Open Source Project (AOSP) spełnia to wymaganie dzięki implementacji Trusty. Alternatywnym rozwiązaniem są inne rozwiązanie oparte na technologii ARM TrustZone lub sprawdzone i sprawdzone przez firmę zewnętrzną wdrożenie izolacji opartej na hipernadzorcy.
• [9.11/H-0-4]* MUSI przeprowadzić uwierzytelnianie ekranu blokady w izolowanym środowisku wykonywania. Tylko wtedy, gdy wszystko się uda, będzie trzeba zezwalać na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający uwierzytelnianie przy zablokowanym ekranie tylko w przypadku izolowanego środowiska wykonawczego. Nadrzędny projekt Android Open Source udostępnia platformę Gatekeeper Hardware Abstraction Layer (HAL) i Trusty, które można wykorzystać w celu spełnienia tego wymogu.
• [9.11/H-0-5]* MUSI obsługiwać atest klucza, gdy klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane z użyciem bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane przez wystarczającą liczbę urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie tego samego klucza atestu,chyba że zostanie wyprodukowanych co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowany zostanie więcej niż 100 tys. jednostek SKU, dla każdej z nich może zostać użyty inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na starszej wersji Androida, urządzenie zostanie zwolnione z obowiązku posiadania magazynu kluczy w osobnym środowisku wykonawczym oraz obsługi atestu klucza, chyba że zadeklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy działającej w odizolowanym środowisku wykonawczym.

Gdy implementacje urządzeń mobilnych obsługują bezpieczny ekran blokady:

• [9.11/H-1-1] MUSI umożliwiać użytkownikowi wybranie najkrótszego czasu uśpienia, czyli czasu przejścia z odblokowania do stanu blokady, wynoszącego maksymalnie 15 sekund.
• [9.11/H-1-2] MUSI umożliwiać użytkownikom ukrywanie powiadomień i wyłączanie wszystkich form uwierzytelniania oprócz podstawowego uwierzytelniania opisanego w artykule 9.11.1 Bezpieczny ekran blokady. AOSP spełnia wymagania w trybie blokady.

Jeśli implementacje urządzeń mobilnych obejmują wielu użytkowników i nie są zadeklarowane flagi funkcji android.hardware.telephony:

• [9.5/H-2-1] MUSI obsługiwać profile z ograniczonym dostępem – 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 skonfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej precyzyjnymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli implementacje urządzeń mobilnych obejmują wielu użytkowników i zadeklarują one flagę funkcji android.hardware.telephony:

• [9.5/H-3-1] NIE MOŻE obsługiwać profili z ograniczonym dostępem, ale MUSI być zgodny z mechanizmami kontroli opartymi na AOSP, które włączają lub wyłączają innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

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

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

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

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

• Perfetto
  • [6.1/H-0-2]* MUSI udostępniać użytkownikowi powłoki plik binarny /system/bin/perfetto. cmdline jest zgodny z dokumentacją perfetto.
  • [6.1/H-0-3]* Plik binarny perfetto MUSI akceptować jako dane wejściowe konfigurację protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/H-0-4]* Plik binarny perfetto MUSI zapisywać dane wyjściowe jako ślad protokołu protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/H-0-5]* MUSI podać, za pomocą pliku binarnego perfetto, przynajmniej źródła danych opisane w dokumentacji perfetto.
  • [6.1/H-0-6]* Demon śledzenia perfetto MUSI być domyślnie włączony (usługa systemowa persist.traced.enable).

2.2.7 Szkolenie z występów w przypadku urządzeń mobilnych

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

2.2.7.1. Multimedia

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

• [5.1/H-1-1] MUSI reklamować maksymalną liczbę sprzętowych dekoderów wideo które mogą być uruchamiane jednocześnie przy użyciu dowolnej kombinacji kodeka za pośrednictwem CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints() .
• [5.1/H-1-2] MUSI obsługiwać 6 wystąpień sesji sprzętowego dekodera wideo (AVC lub HEVC) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p rozdzielczość przy 30 kl./s
• [5.1/H-1-3] NALEŻY reklamować maksymalną liczbę sprzętowych koderów wideo. które mogą być uruchamiane jednocześnie przy użyciu dowolnej kombinacji kodeka za pośrednictwem CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] MUSI obsługiwać 6 wystąpień sesji kodera wideo. (AVC lub HEVC) w dowolnej kombinacji kodeków działających jednocześnie w rozdzielczości 720p rozdzielczość przy 30 kl./s
• [5.1/H-1-5] NALEŻY reklamować maksymalną liczbę sprzętowych koderów wideo. sesji dekodera i dekodera, które mogą być uruchamiane jednocześnie w dowolnej kombinacji kodeka. przez: CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] MUSI obsługiwać 6 instancji sprzętowych dekodera wideo i sprzętu sesji kodera wideo (AVC lub HEVC) w dowolnej kombinacji kodeka i jednocześnie w rozdzielczości 720p przy 30 kl./s.
• [5.1/H-1-7] W przypadku formatu [5.1/H-1-7] opóźnienie inicjowania kodeka musi wynosić maksymalnie 65 ms Sesja kodowania 1080p lub mniejsza w przypadku wszystkich sprzętowych koderów wideo (innego niż kodek Dolby Vision). Wczytywanie tutaj jest zdefiniowane jako jednoczesna sesja transkodowania transmisji wideo od 1080p do 720p przy użyciu sprzętowego wideo kodeków oraz inicjowanie nagrywania audio-wideo w rozdzielczości 1080p.
• [5.1/H-1-8] W przypadku formatu [5.1/H-1-8] opóźnienie inicjowania kodeka musi wynosić maksymalnie 50 ms Sesja kodowania dźwięku 128 kb/s lub niższa w przypadku wszystkich koderów audio, gdy w przypadku wczytywania. W tym miejscu definiuje się jednoczesną transmisję wideo w rozdzielczości od 1080p do 720p. i sesji transkodowania za pomocą sprzętowych kodeków wideo oraz funkcji 1080p. inicjowania nagrywania audio-wideo.
• [5.3/H-1-1] NIE MOŻE upuścić więcej niż 1 klatki w ciągu 10 sekund (mniej niż 0,333% spadku liczby klatek) podczas sesji wideo w rozdzielczości 1080p przy 30 klatkach na sekundę. nie jest wczytywany. Wczytywanie definiuje się jako równoczesne odtwarzanie filmów w rozdzielczości od 1080p do 720p transkodowania za pomocą sprzętowych kodeków wideo oraz Odtwarzanie dźwięku w formacie AAC z szybkością 128 kb/s.
• [5.3/H-1-2] W trakcie filmu NIE MOŻE upuścić więcej niż 1 klatki na 10 sekund zmiana rozdzielczości podczas wczytywania sesji wideo z szybkością 30 kl./s. Obciążenie jest zdefiniowane jako jednoczesna sesja transkodowania transmisji wideo od 1080p do 720p przy użyciu sprzętowego wideo oraz kodeki AAC z szybkością 128 kb/s.
• [5.6/H-1-1] MUSI mieć opóźnienie trwające krócej niż 100 milisekund. korzystając z testu tonacji w systemie OboeTester lub testu tonacji z narzędzia CTS Verifier.

2.2.7.2. Aparat

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

• [7.5/H-1-1] MUSI mieć główny tylny aparat o rozdzielczości co najmniej 12 megapikseli obsługujących nagrywanie wideo z szybkością 4k przy 30 kl./s. Podstawowy tylny aparat to tylny aparat z najniższym identyfikatorem.
• [7.5/H-1-2] MUSI mieć główny przedni aparat o rozdzielczości co najmniej 4 megapiksele obsługujące nagrywanie wideo w rozdzielczości 1080p przy 30 kl./s. Podstawowy przedni aparat to przedni aparat z najniższym identyfikatorem.
• [7.5/H-1-3] MUSI obsługiwać właściwość android.info.supportedHardwareLevel jako PEŁNY lub lepszy dla tylnej głównej i LIMITED lub lepszej dla głównego pokoju z przodu aparat fotograficzny.
• [7.5/H-1-4] MUSI obsługiwać Metadane kamery.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME dla obu aparatów głównych.
• [7.5/H-1-5] MUSI mieć opóźnienie na zapis w formacie Camera2 JPEG < 1000 ms przez Rozdzielczość 1080p mierzona w teście wydajności kamery CTS w Warunki oświetleniowe ITS (3000 K) dla obu głównych kamer.
• [7.5/H-1-6] MUSI mieć opóźnienie na uruchomienie kamery2 (otwórz aparat, aby wyświetlić pierwszy podgląd ramka) < 600 ms zgodnie z testem wydajności kamery CTS przeprowadzanym przez ITS warunków oświetleniowych (3000 K) obu aparatów głównych.

2.2.7.3 Sprzęt

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

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

2.2.7.4. Wydajność

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

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

2.3. Wymagania dotyczące telewizora

Urządzenie Android TV odnosi się do implementacji urządzenia z Androidem, która jest interfejsem rozrywkowym służącym do korzystania z mediów cyfrowych, filmów, gier, aplikacji lub telewizji na żywo dla użytkowników, którzy siedzą w odległości około 3,5 metra (tzw. „relaks” lub „3-metrowy interfejs użytkownika”).

Implementacje na urządzeniach z Androidem zaliczają się do telewizorów, 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 ok. 3 metrów od użytkownika;
• Ekran musi mieć przekątny ekranu o przekątnej większej niż 24 cale LUB mieć port wyjściowy wideo, np. VGA, HDMI, DisplayPort lub bezprzewodowy.

Dodatkowe wymagania podane w pozostałej części tej sekcji dotyczą urządzeń Android TV.

2.3.1 Sprzęt

Implementacje na urządzeniach telewizyjnych:

• [7.2.2/T-0-1] MUSI obsługiwać pada kierunkowego.
• [7.2.3/T-0-1] MUSI zawierać funkcje ekranu głównego i Wstecz.
• [7.2.3/T-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno zdarzenie normalnego, jak i przytrzymania funkcji Back (KEYCODE_BACK).
• [7.2.6.1/T-0-1] MUSI zawierać obsługę kontrolerów do gier i zadeklarować flagę funkcji android.hardware.gamepad.
• [7.2.7/T] POWINNY jest mieć pilota, za pomocą którego użytkownicy mogą uzyskiwać dostęp do danych wejściowych nawigacji bezdotykowej i głównych klawiszy nawigacyjnych.

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

• [7.3.4/T-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 100 Hz.
• [7.3.4/T-1-2] MUSI być w stanie mierzyć zmiany orientacji kamery do 1000 stopni na sekundę.

Implementacje na urządzeniach telewizyjnych:

• [7.4.3/T-0-1] MUSI obsługiwać Bluetooth i Bluetooth LE.
• [7.6.1/T-0-1] MUSI mieć co najmniej 4 GB nieulotnego miejsca na dane do przechowywania prywatnych danych aplikacji (partycja „/data”).

Jeśli implementacje telewizorów są wyposażone w port USB obsługujący tryb hosta:

• [7.5.3/T-1-1] MUSI obsługiwać kamerę zewnętrzną, która jest podłączana przez ten port USB, ale nie zawsze jest podłączona.

Jeśli implementacje na telewizorach są 32-bitowe:

• [7.6.1/T-1-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 896 MB, jeśli używana jest dowolna z tych gęstości:

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

Jeśli implementacje telewizorów są 64-bitowe:

• [7.6.1/T-2-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 1280 MB, jeśli używana jest dowolna z tych gęstości:

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

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do miejsca w pamięci, które jest dostępne jako uzupełnienie pamięci przeznaczonej już na komponenty sprzętowe, takie jak radio czy obraz, które nie są pod kontrolą jądra implementacji urządzenia.

Implementacje na urządzeniach telewizyjnych:

• [7.8.1/T] POWINNY być mikrofon.
• [7.8.2/T-0-1] MUSI mieć wyjście audio i zadeklarować android.hardware.audio.output.

2.3.2 Multimedia

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać następujące formaty kodowania i dekodowania dźwięku i udostępniać je aplikacjom innych firm:

• [5.1/T-0-1] Profil AAC MPEG-4 (AAC LC)
• [5.1/T-0-2] Profil MPEG-4 HE AAC (AAC+)
• [5.1/T-0-3] AAC ELD (rozszerzony AAC z niskim opóźnieniem)

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać następujące formaty kodowania wideo i udostępniać je aplikacjom innych firm:

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

Implementacje na urządzeniach telewizyjnych:

• [5.2.2/T-SR] Zdecydowanie zalecana jest obsługa kodowania H.264 w rozdzielczości 720p i 1080p przy 30 klatkach na sekundę.

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać następujące formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać dekodowanie w formacie MPEG-2, zgodnie z sekcją 5.3.1, ze standardową liczbą klatek i rozdzielczością nie mogą wykraczać poza te formaty:

• [5.3.1/T-1-1] 1080p przy 29,97 kl./s przy wysokim poziomie profilu głównego.
• [5.3.1/T-1-2] HD 1080i przy 59,94 klatce na sekundę przy wysokim poziomie profilu głównego. MUSI usunąć przeplot wideo w formacie MPEG-2 i udostępnić go aplikacjom innych firm.

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać dekodowanie w formacie H.264 (zgodnie z opisem w sekcji 5.3.4) w przypadku filmów z standardową liczbą klatek i rozdzielczością do następujących wartości:

• [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ę przy wysokim profilu 4.2

Implementacje urządzeń telewizyjnych z dekoderami sprzętowymi H.265 MUSZĄ obsługiwać dekodowanie H.265, zgodnie z sekcją 5.3.5, przy standardowych liczbach klatek i rozdzielczości do:

• [5.3.5/T-1-1] HD 1080p przy 60 klatkach na sekundę z profilem głównym 4.1

Jeśli implementacje telewizorów z dekoderami sprzętowymi H.265 obsługują dekodowanie H.265 i profil dekodowania UHD:

• [5.3.5/T-2-1] MUSI obsługiwać profil dekodowania UHD przy 60 klatkach na sekundę w przypadku głównego profilu w poziomie Main10 Level 5.

Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać dekodowanie VP8, zgodnie z opisem w sekcji 5.3.6, przy standardowych liczbach klatek na sekundę i rozdzielczościach do następujących:

• [5.3.6/T-1-1] 1080p HD przy 60 klatkach na sekundę (profil dekodowania)

Implementacje urządzeń telewizyjnych z dekoderami sprzętowymi VP9 MUSZĄ obsługiwać dekodowanie VP9 (zgodnie z opisem w sekcji 5.3.7) przy standardowych liczbach klatek na sekundę i rozdzielczościach obejmujących:

• [5.3.7/T-1-1] HD 1080p przy 60 klatkach na sekundę przy profilu 0 (8-bitowa głębia kolorów)

Jeśli implementacje urządzeń telewizyjnych z dekoderami sprzętowymi VP9 obsługują dekodowanie VP9 i profil dekodowania UHD:

• [5.3.7/T-2-1] MUSI obsługiwać profil dekodowania UHD przy 60 klatkach na sekundę z profilem 0 (8-bitowa głębia kolorów).
• [5.3.7/T-2-1] Zdecydowanie ZALECANE jest obsługa profilu dekodowania UHD z szybkością 60 klatek na sekundę z profilem 2 (10-bitowa głębia kolorów).

Implementacje na urządzeniach telewizyjnych:

• [5.5/T-0-1] MUSI obsługiwać system wyciszania głównego poziomu głośności oraz wyciszania cyfrowego wyjścia audio na obsługiwanych wyjściach, z wyjątkiem skompresowanego przekazującego wyjścia audio (gdzie na urządzeniu nie jest wykonywane dekodowanie dźwięku).

Jeśli modele telewizorów nie mają wbudowanego wyświetlacza, ale obsługują zewnętrzny wyświetlacz podłączony przez HDMI,:

• [5.8/T-0-1] MUSI ustawić tryb wyjścia HDMI, aby wybrać maksymalną rozdzielczość, jaką można obsługiwać przy częstotliwości odświeżania 50 Hz lub 60 Hz.
• [5.8/T-SR] Zdecydowanie ZALECANE jest zapewnienie konfigurowalnego selektora częstotliwości odświeżania HDMI.
• [5.8] NALEŻY ustawić częstotliwość odświeżania trybu 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 urządzenie jest sprzedawane.

Jeśli modele telewizorów nie mają wbudowanego wyświetlacza, ale obsługują zewnętrzny wyświetlacz podłączony przez HDMI,:

• [5.8/T-1-1] MUSI obsługiwać HDCP 2.2.

Jeśli implementacje urządzeń telewizyjnych nie obsługują dekodowania UHD, ale obsługują zewnętrzny wyświetlacz podłączony przez HDMI,:

• [5.8/T-2-1] MUSI obsługiwać HDCP 1.4

2.3.3 Oprogramowanie

Implementacje na urządzeniach telewizyjnych:

• [3/T-0-1] MUSI zadeklarować funkcje android.software.leanback i android.hardware.type.television.
• [3.2.3.1/T-0-1] W przypadku wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj MUSISZ wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji.
• [3.4.1/T-0-1] MUSI zapewniać pełną implementację interfejsu API android.webkit.Webview.

Jeśli implementacje urządzeń Android TV obsługują ekran blokady:

• [3.8.10/T-1-1] MUSI wyświetlać powiadomienia na ekranie blokady, w tym szablon powiadomień o multimediach.

Implementacje na urządzeniach telewizyjnych:

• [3.8.14/T-SR] Zdecydowanie ZALECANE jest obsługa wielu okien w trybie obraz w obrazie (PIP).
• [3.10/T-0-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.
• [3.10/T-SR] Zdecydowanie ZALECANE jest wstępne ładowanie na urządzeniu usług ułatwień dostępu porównywalnych lub przekraczających możliwości funkcji ułatwień dostępu Switch Access i TalkBack (w językach obsługiwanych przez wstępnie zainstalowany mechanizm zamiany tekstu na mowę) zgodnie z projektem open source TalkBack.

Jeśli implementacje urządzeń telewizyjnych zgłaszają funkcję android.hardware.audio.output:

• [3.11/T-SR] Zdecydowanie ZALECANE jest dodanie mechanizmu zamiany tekstu na mowę obsługującego języki dostępne na urządzeniu.
• [3.11/T-1-1] MUSI obsługiwać instalację silników zamiany tekstu na mowę innych firm.

Implementacje na urządzeniach telewizyjnych:

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

2.3.4 Wydajność i moc

• [8.1/T-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie renderowania klatki lub opóźnienie renderowania klatek NIE MOGĄ występować częściej niż 5 klatek na sekundę i POWINNY być poniżej 1 klatek na sekundę.
• [8.2/T-0-1] MUSI zadbać o wydajność zapisu sekwencyjnego z szybkością co najmniej 5 MB/s.
• [8.2/T-0-2] MUSI zapewniać wydajność zapisu przy losowym połączeniu z szybkością co najmniej 0,5 MB/s.
• [8.2/T-0-3] MUSI zapewniać wydajność sekwencyjnego odczytu co najmniej 15 MB/s.
• [8,2/T-0-4] MUSI zapewniać prędkość odczytu z prędkością co najmniej 3,5 MB/s w przypadku losowego odczytu.

Jeśli implementacje urządzeń telewizyjnych obejmują funkcje poprawiające zarządzanie energią urządzenia dostępne w AOSP lub rozszerzające funkcje dostępne w ramach AOSP:

• [8.3/T-1-1] MUSI umożliwiać użytkownikom włączanie i wyłączanie funkcji oszczędzania baterii.

Jeśli telewizory nie mają baterii:

• [8.3/T-1-2] MUSI rejestrować urządzenie jako urządzenie bez baterii zgodnie z opisem w artykule Obsługa urządzeń bez baterii.

Jeśli implementacje telewizorów mają baterię:

• [8.3/T-1-3] MUSI zapewniać dostępność dla użytkowników w celu wyświetlania wszystkich aplikacji wyłączonych z trybów czuwania aplikacji i uśpienia.

Implementacje na urządzeniach telewizyjnych:

• [8.4/T-0-1] MUSI zawierać profil zasilania dla każdego komponentu, który określa wartość bieżącego zużycia energii dla każdego komponentu oraz przybliżone zużycie baterii przez komponenty w danym okresie, zgodnie z dokumentacją projektu Android Open Source.
• [8.4/T-0-2] MUSI podawać wszystkie wartości zużycia energii w miliiamperach godzin (mAh).
• [8.4/T-0-3] MUSI raportować zużycie energii procesora przez identyfikator UID każdego procesu. Projekt Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/T] POWINNY być przypisane do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii przez komponent sprzętowy aplikacji.
• [8.4/T-0-4] MUSI udostępnić informacje o zużywaniu energii za pomocą polecenia powłoki adb shell dumpsys batterystats deweloperowi aplikacji.

2.3.5 Model zabezpieczeń

Implementacje na urządzeniach telewizyjnych:

• [9.11/T-0-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w odizolowanym środowisku wykonawczym.
• [9.11/T-0-2] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1 i SHA-2, aby zapewnić prawidłową obsługę obsługiwanych algorytmów systemu magazynu kluczy Android w miejscu, które jest bezpiecznie odizolowane od kodu działającego w jądrze lub nowszym. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, dzięki którym jądro lub kod przestrzeni użytkownika mogą uzyskiwać dostęp do wewnętrznego stanu odizolowanego środowiska, w tym do aktu o rynkach cyfrowych. Dodatkowy projekt Android Open Source Project (AOSP) spełnia to wymaganie dzięki implementacji Trusty. Alternatywnym rozwiązaniem są inne rozwiązanie oparte na technologii ARM TrustZone lub sprawdzone i sprawdzone przez firmę zewnętrzną wdrożenie izolacji opartej na hipernadzorcy.
• [9.11/T-0-3] MUSI przeprowadzić uwierzytelnianie ekranu blokady w izolowanym środowisku wykonawczym i tylko wtedy, gdy wszystko się uda, zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający uwierzytelnianie przy zablokowanym ekranie tylko w przypadku izolowanego środowiska wykonawczego. Nadrzędny projekt Android Open Source udostępnia platformę Gatekeeper Hardware Abstraction Layer (HAL) i Trusty, które można wykorzystać w celu spełnienia tego wymogu.
• [9.11/T-0-4] MUSI obsługiwać atest klucza, jeśli klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane z użyciem bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane przez wystarczającą liczbę urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie tego samego klucza atestu,chyba że zostanie wyprodukowanych co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowany zostanie więcej niż 100 tys. jednostek SKU, dla każdej z nich może zostać użyty inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na starszej wersji Androida, urządzenie zostanie zwolnione z obowiązku posiadania magazynu kluczy w osobnym środowisku wykonawczym oraz obsługi atestu klucza, chyba że zadeklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy działającej w odizolowanym środowisku wykonawczym.

Jeśli implementacje urządzeń telewizyjnych obsługują bezpieczny ekran blokady:

• [9.11/T-1-1] MUSI umożliwiać użytkownikowi wybranie limitu czasu uśpienia, po którym następuje przejście z odblokowanego w zablokowany. Minimalny dozwolony czas oczekiwania nie może przekraczać 15 sekund.

Jeśli implementacje urządzeń telewizyjnych uwzględniają wielu użytkowników i nie mają zadeklarowanej flagi funkcji android.hardware.telephony:

• [9.5/T-2-1] MUSI obsługiwać profile z ograniczonym dostępem – 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 skonfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej precyzyjnymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli implementacje urządzeń telewizyjnych obejmują wielu użytkowników i wymagają zadeklarowania flagi funkcji android.hardware.telephony:

• [9.5/T-3-1] NIE MOŻE obsługiwać profili z ograniczonym dostępem, ale MUSI być zgodny z mechanizmami kontroli opartymi na AOSP, które włączają lub wyłączają innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

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

Implementacje na urządzeniach telewizyjnych:

• Perfetto
  • [6.1/T-0-1] MUSI udostępniać użytkownikowi powłoki plik binarny /system/bin/perfetto, w przypadku którego interfejs cmdline jest zgodny z dokumentacją perfetto.
  • [6.1/T-0-2] Plik binarny perfetto MUSI akceptować jako dane wejściowe konfigurację protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/T-0-3] Plik binarny perfetto MUSI zapisywać dane wyjściowe jako ślad protokołu protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/T-0-4] MUSI podać, za pomocą pliku binarnego perfetto, przynajmniej źródła danych opisane w dokumentacji perfetto.

2.4. Wymagania dotyczące zegarka

Zegarek z Androidem oznacza urządzenie z Androidem przeznaczone do noszenia na ciele, na przykład na nadgarstku.

Implementacje na urządzeniach z Androidem są zaliczane do urządzeń z Androidem, jeśli spełniają wszystkie te kryteria:

• Ekran musi mieć przekątną fizyczną z zakresu od 1,1 do 2,5 cala.
• Mają mechanizm przeznaczony do noszenia przy ciele.

Dodatkowe wymagania podane w pozostałej części tej sekcji dotyczą wyłącznie implementacji na zegarku Android Watch.

2.4.1. Sprzęt

Implementacje na zegarkach:

• [7.1.1.1/W-0-1] MUSI mieć przekątną ekran o przekątnej w przedziale od 1,1 do 2,5 cala.

• [7.2.3/W-0-1] MUSI mieć dostęp do funkcji ekranu głównego i funkcji Wstecz, chyba że jest ustawiona na UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] MUSI obsługiwać wprowadzanie na ekranie dotykowym.

• [7.3.1/W-SR] Zdecydowanie ZALECANE jest dodanie 3-osiowego akcelerometru.

Jeśli implementacje na urządzeniach Watch obejmują odbiornik GPS/GNSS i zgłaszają takie możliwości aplikacjom za pomocą flagi funkcji android.hardware.location.gps,:

• [7.3.3/W-1-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną wykryte, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie jest jeszcze raportowana.
• [7.3,3/W-1-2] MUSI podawać wartości pseudozakresów i wskaźników pseudozakresowych GNSS, że w warunkach na świeżym powietrzu po określeniu lokalizacji, gdy nieruchomo lub poruszasz się z przyspieszeniem poniżej 0,2 metra na sekundę do kwadratu, wystarczają do obliczenia pozycji z dokładnością do 20 metrów, a prędkość do 0,9 metra na sekundę z dokładnością co najmniej 0,9 metra na sekundę.

Jeśli zegarki są wyposażone w 3-osiowy żyroskop:

• [7.3.4/W-2-1] MUSI być w stanie mierzyć zmiany orientacji kamery do 1000 stopni na sekundę.

Implementacje na zegarkach:

• [7.4.3/W-0-1] MUSI obsługiwać Bluetooth.

• [7.6.1/W-0-1] MUSI mieć co najmniej 1 GB nieulotnego miejsca na prywatne dane aplikacji (partycja „/data”).

• [7.6.1/W-0-2] MUSI mieć co najmniej 416 MB dostępnej pamięci dla jądra i przestrzeni użytkownika.

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

• [7.8,2/W] MOŻE mieć wyjście audio.

2.4.2 Multimedia

Brak dodatkowych wymagań.

2.4.3 Oprogramowanie

Implementacje na zegarkach:

• [3/W-0-1] MUSI zadeklarować funkcję android.hardware.type.watch.
• [3/W-0-2] MUSI obsługiwać parametr uiMode = UI_MODE_TYPE_WATCH.
• [3.2.3.1/W-0-1] W przypadku wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj MUSISZ wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji.

Implementacje na zegarkach:

• [3.8.4/W-SR] Zdecydowanie ZALECANE jest wdrożenie na urządzeniu asystenta do obsługi działania wspomagającego.

Implementacje zegarków deklarujące flagę funkcji android.hardware.audio.output:

• [3.10/W-1-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.
• [3.10/W-SR] Zdecydowanie ZALECANE jest wstępne ładowanie na urządzeniu usług ułatwień dostępu porównywalnych lub przekraczających możliwości funkcji ułatwień dostępu Switch Access i TalkBack (w językach obsługiwanych przez wstępnie zainstalowany mechanizm zamiany tekstu na mowę) zgodnie z projektem open source TalkBack.

Jeśli implementacje na zegarku zgłaszają funkcję android.hardware.audio.output:

• [3.11/W-SR] Zdecydowanie ZALECANE jest dodanie mechanizmu zamiany tekstu na mowę obsługującego języki dostępne na urządzeniu.

• [3.11/W-0-1] MUSI obsługiwać instalację silników zamiany tekstu na mowę innych firm.

2.4.4 Wydajność i moc

Jeśli implementacje urządzeń zegarka obejmują funkcje usprawniające zarządzanie energią urządzenia dostępne w AOSP lub rozszerzające funkcje dostępne w AOSP:

• [8.3/W-SR] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości wyświetlania wszystkich aplikacji wyłączonych z trybów czuwania aplikacji i uśpienia.
• [8.3/W-SR] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości włączenia i wyłączenia funkcji oszczędzania baterii.

Implementacje na zegarkach:

• [8.4/W-0-1] MUSI zawierać profil zasilania dla każdego komponentu, który określa wartość bieżącego zużycia energii przez każdy komponent sprzętowy oraz przybliżone zużycie baterii przez komponenty w danym okresie, zgodnie z dokumentem w witrynie Android Open Source Project.
• [8,4/W-0-2] MUSI podawać wszystkie wartości zużycia energii w miliiamperach godzin (mAh).
• [8.4/W-0-3] MUSI raportować zużycie energii procesora przez identyfikator UID każdego procesu. Projekt Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/W-0-4] MUSI udostępnić informacje o zużywaniu energii za pomocą polecenia powłoki adb shell dumpsys batterystats deweloperowi aplikacji.
• [8.4/W] Jeśli nie można przypisać zużycia energii przez komponent sprzętowy aplikacji, POWINNA być ona przypisana do samego komponentu sprzętowego.

2.4.5 Model zabezpieczeń

Jeśli implementacje na zegarkach obejmują wielu użytkowników i nie mają zadeklarowanej flagi funkcji android.hardware.telephony:

• [9.5/W-1-1] MUSI obsługiwać profile z ograniczonym dostępem – 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 skonfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej precyzyjnymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli implementacje na zegarkach obejmują wielu użytkowników i zadeklarują one flagę funkcji android.hardware.telephony:

• [9.5/W-2-1] NIE MOŻE obsługiwać profili z ograniczonym dostępem, ale MUSI być zgodny z mechanizmami kontroli opartymi na AOSP, które włączają lub wyłączają innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

2.5. Wymagania dotyczące motoryzacji

Implementacja na Androida Automotive oznacza radio w pojeździe z Androidem jako systemem operacyjnym z częścią lub całością obsługi systemu bądź funkcji informacyjno-rozrywkowych.

Implementacje na urządzeniach z Androidem są zaliczane do samochodów, jeśli zawierają zadeklarowaną funkcję android.hardware.type.automotive lub spełniają wszystkie poniższe kryteria.

• są umieszczone w pojeździe samochodowym lub mogą być do niego podłączone.
• korzystają z ekranu w rzędzie kierowcy jako głównego wyświetlacza.

Dodatkowe wymagania podane w pozostałej części tej sekcji dotyczą tylko implementacji na urządzeniach z Androidem Automotive.

2.5.1 Sprzęt

Implementacje na urządzeniach motoryzacyjnych:

• [7.1.1.1/A-0-1] MUSI mieć ekran o przekątnej co najmniej 6 cali.

• [7.1.1.1/A-0-2] MUSI mieć układ ekranu o wymiarach co najmniej 750 dp x 480 dp.

• [7.2.3/A-0-1] MUSI zawierać funkcję ekranu głównego, a może zawierać funkcje Wstecz i Ostatnie.

• [7.2.3/A-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno zdarzenie normalnego, jak i przytrzymania funkcji Back (KEYCODE_BACK).
• [7.3/A-0-1] MUSI wdrożyć i zgłaszać elementy GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED i PARKING_BRAKE_ON.
• [7.3/A-0-2] Wartość flagi NIGHT_MODE MUSI być zgodna z trybem dziennym i nocnym na panelu i POWINNA opisywać dane z czujnika jasności otoczenia. Czujnik jasności otoczenia MOŻE być taki sam jak Fotometr.
• [7.3/A-0-3] MUSI zawierać dodatkowe pole informacyjne TYPE_SENSOR_PLACEMENT czujnika w ramach parametru SensorAdditionalInfo w przypadku każdego dostarczonego czujnika.
• [7.3/A-0-1] MAJJONALNIE identyfikuje lokalizację przez połączenie GPS/GNSS z dodatkowymi czujnikami. Jeśli dane w kolumnie Lokalizacja są nieprawidłowe, Zdecydowanie ZALECANE jest wdrożenie i raportowanie odpowiednich typów czujników lub identyfikatorów właściwości pojazdu.
• [7.3/A-0-2] Żądanie dotyczące lokalizacji żądanej za pomocą funkcji LocationManager#requestLocationUpdates() NIE MOŻE być dopasowane do mapy.

Jeśli implementacje urządzeń motoryzacyjnych zawierają 3-osiowy akcelerometr:

• [7.3.1/A-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 100 Hz.
• [7.3.1/A-1-2] MUSI być zgodny z układem współrzędnych czujnika samochodowego Androida.

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

• [7.3.4/A-2-1] MUSI raportować zdarzenia z częstotliwością co najmniej 100 Hz.
• [7.3.4/A-2-2] MUSI też zamontować czujnik TYPE_GYROSCOPE_UNCALIBRATED.
• [7.3.4/A-2-3] MUSI być w stanie mierzyć zmiany orientacji ekranu do 250 stopni na sekundę.
• [7.3.4/A-SR] Zdecydowanie ZALECANE jest skonfigurowanie zakresu pomiaru żyroskopu na +/-250 dps w celu uzyskania maksymalnej możliwej rozdzielczości.

Jeśli implementacje urządzeń motoryzacyjnych zawierają odbiornik GPS/GNSS, ale nie uwzględniają komórkowej transmisji danych za pomocą sieci komórkowej, to:

• [7.3.3/A-3-1] MUSI określić lokalizację po pierwszym włączeniu odbiornika GPS/GNSS lub po upływie ponad 4 dni w ciągu 60 sekund.
• [7.3.3/A-3-2] MUSI spełniać kryteria dotyczące czasu do pierwszej korekty opisane w artykułach 7.3.3/C-1-2 i 7.3.3/C-1-6 w przypadku wszystkich pozostałych próśb o lokalizację (tj.próśb, które nie są wysyłane po raz pierwszy lub po upływie ponad 4 dni). Wymaganie 7.3.3/C-1-2 jest zazwyczaj spełnione w pojazdach, które nie korzystają z komórkowej łączności danych przez sieć komórkową, wykorzystując prognozy orbity GNSS obliczone na odbiorniku lub korzystając z ostatniej znanej lokalizacji pojazdu wraz z możliwością nieobsłużenia przez co najmniej 60 sekund z dokładnością pozycji na poziomie zgodnym z 7.3.3/C-1-3 lub połączeniem obu tych metod.

Implementacje na urządzeniach motoryzacyjnych:

• [7.4.3/A-0-1] MUSI obsługiwać Bluetooth i POWINNO obsługiwać Bluetooth LE.
• [7.4.3/A-0-2] Implementacje Androida Automotive MUSZĄ obsługiwać te profile Bluetooth:
  • Nawiązywanie połączeń telefonicznych przez profil HFP.
  • Odtwarzanie multimediów przez profil dystrybucji dźwięku (A2DP).
  • Sterowanie odtwarzaniem multimediów w profilu pilota (AVRCP).
  • Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).

• [7.4.3/A-SR] Zdecydowanie ZALECANE jest działanie usługi Message Access Profile (MAP).

• [7.4.5/A] POWINNA obsługiwać połączenia do transmisji danych za pomocą sieci komórkowej.

• [7.4.5/A] MOŻE używać stałej interfejsu System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID w przypadku sieci, które powinny być dostępne dla aplikacji systemowych.

Kamera z zewnątrz to aparat, który obrazuje sceny poza urządzeniem, np. przez kamerę samochodową.

Implementacje na urządzeniach motoryzacyjnych:

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

Jeśli implementacje urządzeń w samochodach obejmują kamerę w widoku zewnętrznym, w przypadku takiego aparatu:

• [7.5/A-1-1] NIE MOŻE mieć kamer widoku zewnętrznego dostępnych przez interfejsy API aparatu na Androida, chyba że są one zgodne z wymaganiami dotyczącymi podstawowych urządzeń.
• [7.5/A-SR] Zdecydowanie ZALECANE jest, aby nie obracać obrazu ani wyświetlać odbicia lustrzanego w poziomie.
• [7.5.5/A-SR] Zdecydowanie ZALECANE jest taka orientacja, tak aby długi wymiar aparatu był zgodny z horyzontem.
• [7.5/A-SR] Zdecydowanie ZALECANE jest rozdzielczość co najmniej 1,3 megapiksela.
• POWINNY być sprzęt o stałej ostrości lub EDOF (rozszerzona głębia ostrości).
• MUSI obsługiwać platformę synchronizacji Androida.
• W sterowniku aparatu MOŻE być zaimplementowany sprzętowy autofokus lub programowy autofokus.

Implementacje na urządzeniach motoryzacyjnych:

• [7.6.1/A-0-1] MUSI mieć co najmniej 4 GB nieulotnego miejsca na dane do przechowywania prywatnych danych aplikacji (partycja „/data”).

• [7.6.1/A] NALEŻY sformatować partycję danych w celu zwiększenia wydajności i trwałości w pamięci flash, na przykład przy użyciu systemu plików f2fs.

Jeśli implementacje urządzeń w samochodach zapewniają współdzieloną pamięć zewnętrzną z częścią wewnętrznej, niewymiennej pamięci masowej:

• [7.6.1/A-SR] Zdecydowanie ZALECANE jest ograniczenie dodatkowych operacji wejścia-wyjścia podczas operacji wykonywanych w pamięci zewnętrznej, na przykład przy użyciu SDCardFS.

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

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

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

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

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

• [7.6.1/A-1-3] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 896 MB w przypadku użycia dowolnej z tych gęstości:

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

• [7.6.1/A-1-4] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 1344 MB, jeśli używana jest jedna z tych gęstości:

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

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

• [7.6.1/A-2-1] Pamięć dostępna dla jądra i przestrzeń użytkownika MUSI mieć co najmniej 816 MB w przypadku użycia dowolnej z tych gęstości:

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

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

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

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

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

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

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

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do miejsca w pamięci, które jest dostępne jako uzupełnienie pamięci przeznaczonej już na komponenty sprzętowe, takie jak radio czy obraz, które nie są pod kontrolą jądra implementacji urządzenia.

Implementacje na urządzeniach motoryzacyjnych:

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

Implementacje na urządzeniach motoryzacyjnych:

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

Implementacje na urządzeniach motoryzacyjnych:

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

2.5.2 Multimedia

Implementacje na urządzeniach motoryzacyjnych MUSZĄ obsługiwać poniższe formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:

• [5.1/A-0-1] Profil AAC MPEG-4 (AAC LC)
• [5.1/A-0-2] Profil MPEG-4 HE AAC (AAC+)
• [5.1/A-0-3] AAC ELD (rozszerzony AAC z niskim opóźnieniem)

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

Zdecydowanie ZALECANE są wdrożenia na urządzeniach motoryzacyjnych do obsługi następujących dekodowania wideo:

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

2.5.3 Oprogramowanie

Implementacje na urządzeniach motoryzacyjnych:

• [3/A-0-1] MUSI zadeklarować funkcję android.hardware.type.automotive.

• [3/A-0-2] MUSI obsługiwać parametr uiMode = UI_MODE_TYPE_CAR.

• [3/A-0-3] MUSI obsługiwać wszystkie publiczne interfejsy API w przestrzeni nazw android.car.*.

Jeśli implementacje na urządzeniach z branży motoryzacyjnej udostępniają zastrzeżony interfejs API za pomocą android.car.CarPropertyManager z android.car.VehiclePropertyIds:

• [3/A-1-1] NIE MOŻE dołączać specjalnych uprawnień do korzystania z tych właściwości przez aplikację systemową ani uniemożliwiać aplikacjom innych firm korzystania z nich.
• [3/A-1-2] NIE MOŻE powielać właściwości pojazdu, która już istnieje w pakiecie SDK.

Implementacje na urządzeniach motoryzacyjnych:

• [3.2.1/A-0-1] MUSI obsługiwać i egzekwować wszystkie stałe uprawnienia zgodnie z dokumentacją na stronie z informacjami o uprawnieniach dotyczących motoryzacji.

• [3.2.3.1/A-0-1] W przypadku wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj MUSISZ wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji.

• [3.4.1/A-0-1] MUSI zapewniać pełną implementację interfejsu API android.webkit.Webview.

• [3.8.3/A-0-1] MUSI wyświetlać powiadomienia korzystające z interfejsu API Notification.CarExtender na żądanie aplikacji innych firm.

• [3.8.4/A-SR] Zdecydowanie zalecamy wdrożenie asystenta na urządzeniu do wykonywania działania wspomagającego.

Jeśli implementacje urządzeń motoryzacyjnych zawierają przycisk „Naciśnij, aby rozmawiać”,:

• [3.8.4/A-1-1] Trzeba wykonać krótkie naciśnięcie przycisku „Naciśnij, aby rozmawiać” jako określonej interakcji, aby uruchomić wybraną przez użytkownika aplikację asystującą, czyli aplikację, która implementuje VoiceInteractionService.

Implementacje na urządzeniach motoryzacyjnych:

• [3.8.3.1/A-0-1] MUSI prawidłowo renderować zasoby zgodnie z opisem w dokumentacji pakietu SDK Notifications on Automotive OS.
• [3.8.3.1/A-0-2] W przypadku działań związanych z powiadomieniami MUSI wyświetlać przyciski PLAY i MUTE zamiast opcji skonfigurowanych w Notification.Builder.addAction().
• [3.8.3.1/A] POWINNY jest ograniczać korzystanie ze szczegółowych zadań zarządzania, takich jak opcje dla poszczególnych kanałów powiadomień. W celu ograniczenia liczby elementów sterujących MOŻNA użyć kupna interfejsu dla poszczególnych aplikacji.

Implementacje na urządzeniach motoryzacyjnych:

• [3.14/A-0-1] MUSI zawierać platformę interfejsu do obsługi aplikacji innych firm korzystających z interfejsów API multimediów zgodnie z opisem w sekcji 3.14.
• [3.14/A-0-2] MUSI umożliwiać użytkownikowi bezpieczne korzystanie z aplikacji multimedialnych podczas prowadzenia pojazdu.
• [3.14/A-0-3] MUSI obsługiwać działanie intencji ogólnej CAR_INTENT_ACTION_MEDIA_TEMPLATE z dodatkowym CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] MUSI mieć zgodę na przechodzenie do działań związanych z ustawieniami w Aplikacji multimedialnej, ale MUSI ją włączać tylko wtedy, gdy nie obowiązują Ograniczenia dotyczące wygody użytkowania samochodu.
• [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 oraz ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] MUSI obsługiwać wyszukiwanie w aplikacji w przypadku aplikacji, które obsługują wyszukiwanie.
• [3.14/A-0-7] Podczas wyświetlania hierarchii Media Browser MUSI przestrzegać definicji CONTENT_STYLE_BROWSABLE_HINT i CONTENT_STYLE_PLAYABLE_HINT.

Jeśli implementacje urządzeń z Androidem obejmują domyślną aplikację uruchamiającą, te funkcje:

• [3.14/A-1-1] MUSI zawierać usługi multimedialne i otwierać je z intencją CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Implementacje na urządzeniach motoryzacyjnych:

• [3.8/A] MOŻE ograniczyć żądania aplikacji przejście do trybu pełnoekranowego zgodnie z opisem w artykule immersive documentation.
• [3.8/A] Pasek stanu i pasek nawigacyjny MOGĄ BYĆ widoczne przez cały czas.
• [3.8/A] MOŻE ograniczyć żądania aplikacji dotyczące zmiany kolorów elementów interfejsu systemu, aby były one zawsze wyraźnie widoczne.

2.5.4 Wydajność i moc

Implementacje na urządzeniach motoryzacyjnych:

• [8.2/A-0-1] MUSI podawać liczbę bajtów odczytanych i zapisanych w pamięci nieulotnej dla każdego identyfikatora UID każdego procesu, aby statystyki były dostępne dla programistów przez interfejs System API android.car.storagemonitoring.CarStorageMonitoringManager. Projekt Android Open Source Project spełnia wymagania dzięki modułowi jądra uid_sys_stats.
• [8.3/A-1-3] MUSI obsługiwać tryb garażu.
• [8.3/A] POWINNA być w trybie garażowym przez co najmniej 15 minut po każdym przejazdie, chyba że:
  • Bateria jest rozładowana.
  • Nie zaplanowano żadnych nieaktywnych zadań.
  • Kierowca wyłącza tryb garażowy.
• [8.4/A-0-1] MUSI zawierać profil zasilania dla każdego komponentu, który określa wartość bieżącego zużycia energii dla każdego komponentu oraz przybliżone zużycie baterii przez komponenty w danym okresie, zgodnie z dokumentacją projektu Android Open Source.
• [8.4/A-0-2] MUSI podawać wszystkie wartości zużycia energii w miliiamperach godzin (mAh).
• [8.4/A-0-3] MUSI raportować zużycie energii procesora przez identyfikator UID każdego procesu. Projekt Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/A] MUSI być przypisana do samego komponentu sprzętowego, jeśli nie można przypisać do aplikacji zużycia energii przez komponent sprzętowy.
• [8.4/A-0-4] MUSI udostępnić informacje o zużywaniu energii za pomocą polecenia powłoki adb shell dumpsys batterystats deweloperowi aplikacji.

2.5.5 Model zabezpieczeń

Jeśli implementacje urządzeń z branży motoryzacyjnej obsługują wielu użytkowników:

• [9.5/A-1-1] NIE MOŻE umożliwiać użytkownikom interakcji z użytkownikiem systemowym bez interfejsu graficznego ani przełączania się na niego, z wyjątkiem obsługi administracyjnej urządzeń.
• [9.5/A-1-2] MUSI przełączyć się na użytkownika dodatkowego do BOOT_COMPLETED.
• [9.5/A-1-3] MUSI obsługiwać możliwość tworzenia użytkownika gościa nawet po osiągnięciu maksymalnej liczby użytkowników na urządzeniu.

Implementacje na urządzeniach motoryzacyjnych:

• [9.11/A-0-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w odizolowanym środowisku wykonawczym.
• [9.11/A-0-2] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1 i SHA-2, aby zapewnić prawidłową obsługę obsługiwanych algorytmów systemu magazynu kluczy Android w obszarze bezpiecznie odizolowanym od kodu działającego w jednym jądrze lub nowszych. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, dzięki którym jądro lub kod przestrzeni użytkownika mogą uzyskiwać dostęp do wewnętrznego stanu odizolowanego środowiska, w tym do aktu o rynkach cyfrowych. Dodatkowy projekt Android Open Source Project (AOSP) spełnia to wymaganie dzięki implementacji Trusty. Alternatywnym rozwiązaniem są inne rozwiązanie oparte na technologii ARM TrustZone lub sprawdzone i sprawdzone przez firmę zewnętrzną wdrożenie izolacji opartej na hipernadzorcy.
• [9.11/A-0-3] MUSI przeprowadzić uwierzytelnianie ekranu blokady w izolowanym środowisku wykonawczym i tylko wtedy, gdy wszystko się uda, zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający uwierzytelnianie przy zablokowanym ekranie tylko w przypadku izolowanego środowiska wykonawczego. Nadrzędny projekt Android Open Source udostępnia platformę Gatekeeper Hardware Abstraction Layer (HAL) i Trusty, które można wykorzystać w celu spełnienia tego wymogu.
• [9.11/A-0-4] MUSI obsługiwać atest klucza, jeśli klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane z użyciem bezpiecznego sprzętu. Klucze podpisywania atestu MUSZĄ być udostępniane przez wystarczającą liczbę urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie tego samego klucza atestu,chyba że zostanie wyprodukowanych co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowany zostanie więcej niż 100 tys. jednostek SKU, dla każdej z nich może zostać użyty inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na starszej wersji Androida, urządzenie zostanie zwolnione z obowiązku posiadania magazynu kluczy w osobnym środowisku wykonawczym oraz obsługi atestu klucza, chyba że zadeklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy działającej w odizolowanym środowisku wykonawczym.

Implementacje na urządzeniach motoryzacyjnych:

• [9.14/A-0-1] MUSI przechowywać wiadomości z podsystemów pojazdów Android Framework, na przykład dodawać do listy dozwolonych dozwolone typy wiadomości i źródła wiadomości.
• [9.14/A-0-2] MUSISZ pilnować ataków typu Dog of Service za pomocą platformy Androida lub aplikacji innych firm. Zapewnia to ochronę przed złośliwym oprogramowaniem zapełniającym sieć pojazdu ruchami, które może prowadzić do awarii podsystemów pojazdu.

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

Implementacje na urządzeniach motoryzacyjnych:

• Perfetto
  • [6.1/A-0-1] MUSI udostępniać użytkownikowi powłoki plik binarny /system/bin/perfetto, w przypadku którego interfejs cmdline jest zgodny z dokumentacją perfetto.
  • [6.1/A-0-2] Plik binarny perfetto MUSI akceptować jako dane wejściowe konfigurację protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/A-0-3] Plik binarny perfetto MUSI zapisywać dane wyjściowe jako ślad protokołu protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/A-0-4] MUSI podać, za pomocą pliku binarnego perfetto, przynajmniej źródła danych opisane w dokumentacji perfetto.

2.6. Wymagania dotyczące tabletu

Tablet z Androidem oznacza implementację urządzenia z Androidem, które zwykle spełnia wszystkie te kryteria:

• Aby go użyć, przytrzymaj go w obu rękach.
• Nie ma konfiguracji w tradycyjnej obudowie ani urządzenia konwertowalnego.
• Implementacje klawiatury fizycznej używane z urządzeniem łączą się przez standardowe połączenie (np. USB lub Bluetooth).
• Ma źródło zasilania, które umożliwia mobilność, np. baterię.
• ma fizyczny ekran o przekątnej w przedziale od 7 do 18 cali.

Implementacje na tabletach mają podobne wymagania jak w przypadku urządzeń mobilnych. Wyjątki są w tej sekcji oznaczone symbolem *, a wyjątki uwzględniono w tej sekcji.

2.6.1 Sprzęt

Rozmiar ekranu

• [7.1.1.1/Tab-0-1] MUSI mieć ekran o przekątnej od 7 do 18 cali.

Żyroskop

Jeśli implementacje tabletów obejmują 3-osiowy żyroskop:

• [7.3.4/Tab-1-1] MUSI być w stanie mierzyć zmiany orientacji ekranu z dokładnością do 1000 stopni na sekundę.

Minimalna pamięć i miejsce na dane (artykuł 7.6.1)

Gęstości ekranu wymienione dla małych/normalnych ekranów zgodnie z wymaganiami urządzeń mobilnych nie mają zastosowania do tabletów.

Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)

Jeśli tablety wyposażone są w port USB obsługujący tryb peryferyjny, te funkcje:

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

Tryb rzeczywistości wirtualnej (art. 7.9.1)

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

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

2.6.2 Model zabezpieczeń

Klucze i dane logowania (art. 9.11)

Patrz [9.11].

Jeśli w implementacjach na tabletach jest wielu użytkowników i nie ma zadeklarowanej flagi funkcji android.hardware.telephony, oznacza to, że:

• [9.5/T-1-1] MUSI obsługiwać profile z ograniczonym dostępem – 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 skonfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej precyzyjnymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

Jeśli w implementacjach na tabletach uwzględnianych jest wielu użytkowników i zadeklarowana jest flaga funkcji android.hardware.telephony, oznacza to, że:

• [9.5/T-2-1] NIE MOŻE obsługiwać profili z ograniczonym dostępem, ale MUSI być zgodny z mechanizmami kontroli opartymi na AOSP, które włączają lub wyłączają innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

2.6.2 Oprogramowanie

• [3.2.3.1/Tab-0-1] W przypadku wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj MUSISZ wstępnie wczytać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji.

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

Podstawowym narzędziem dla aplikacji na Androida jest zarządzane środowisko wykonywania kodu bajtowego Dalvik. Interfejs programowania aplikacji na Androida (API) to zestaw interfejsów platformy Androida dostępnych dla aplikacji działających w zarządzanym środowisku wykonawczym.

Implementacje na urządzeniach:

• [C-0-1] MUSI zawierać pełne implementacje, w tym wszystkie udokumentowane działania, dowolnego udokumentowanego interfejsu API udostępnianego przez pakiet SDK do Androida lub dowolny interfejs API oznaczony znacznikiem „@SystemApi” w kodzie źródłowym Androida.

• [C-0-2] MUSI obsługiwać i zachowywać wszystkie klasy, metody i powiązane elementy oznaczone adnotacją TestApi (@TestApi).

• [C-0-3] NIE MOŻE pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów ani podpisów interfejsów API, odbiegać od udokumentowanego zachowania ani zawierać elementów bez działania, z wyjątkiem przypadków wyraźnie dozwolonych w tej definicji zgodności.

• [C-0-4] Interfejsy API MUSZĄ utrzymywać dostęp do interfejsów API i działać w sposób rozsądny, nawet jeśli niektóre funkcje sprzętowe, w przypadku których Android obejmuje interfejsy API, zostały pominięte. Szczegółowe informacje o wymaganiach w tym scenariuszu znajdziesz w sekcji 7.

• [C-0-5] NIE MOŻE zezwalać aplikacjom innych firm na korzystanie z interfejsów innych niż SDK, które są zdefiniowane jako metody i pola w pakietach językowych Javy znajdują się w ścieżce klasy rozruchowej w AOSP i nie należą do publicznego pakietu SDK. Obejmuje to interfejsy API oznaczone adnotacją @hide, ale bez @SystemAPI, zgodnie z opisem w dokumentach pakietu SDK oraz w materiałach uczestników zajęć prywatnych i prywatnych w pakiecie.

• [C-0-6] MUSI być dostarczany z każdym interfejsem innym niż SDK na tych samych listach ograniczonych podanych za pomocą flag listy tymczasowej i listy odrzuconych w ścieżce prebuilts/runtime/appcompat/hiddenapi-flags.csv dla odpowiedniej gałęzi interfejsu API w AOSP.

• [C-0-7] MUSI obsługiwać mechanizm aktualizacji dynamicznej podpisanej konfiguracji, aby usuwać interfejsy inne niż SDK z listy ograniczonej przez umieszczenie podpisanej konfiguracji w dowolnym pliku APK przy użyciu istniejących kluczy publicznych dostępnych w AOSP.

  Pamiętaj jednak, że:

  • Jeśli nie ma ukrytego interfejsu API lub został on inaczej zaimplementowany w implementacji urządzenia, przenieś go na listę odrzuconych lub pomiń go na wszystkich listach objętych ograniczeniami (np. jasnoszary, ciemnoszary, czarny).
  • MOŻE: jeśli w AOSP nie ma jeszcze ukrytego interfejsu API, dodaj go do dowolnej listy z ograniczeniami (np. jasnoszary, ciemnoszary, czarny).

3.1.1. Rozszerzenia na Androida

Android umożliwia rozszerzenie zarządzanego interfejsu API na określonym poziomie interfejsu API przez zaktualizowanie wersji rozszerzenia dla tego poziomu interfejsu API. Interfejs android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API zwraca wersję rozszerzenia podanej listy apiLevel, o ile istnieją rozszerzenia dla tego poziomu interfejsu API.

Implementacje na urządzeniach z Androidem:

• [C-0-1] MUSI wstępnie wczytywać implementację AOSP zarówno zasobów wspólnych ExtShared, jak i usług ExtServices, w wersji co najmniej takiej jak minimalna dozwolona na każdym poziomie interfejsu API. Na przykład urządzenia z Androidem 7.0 korzystające z interfejsu API na poziomie 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 zwrócone przez android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) w taki sam sposób jak inne zarządzane interfejsy API, z zastrzeżeniem wymagań opisanych w sekcji 3.1.

3.1.2. Biblioteka Androida

Ze względu na wycofanie klienta Apache HTTP implementacje urządzeń:

• [C-0-1] NIE MOŻE umieszczać biblioteki org.apache.http.legacy w ścieżce Bootclasspath.
• [C-0-2] MUSI dodać bibliotekę org.apache.http.legacy do ścieżki klasy aplikacji tylko wtedy, gdy aplikacja spełnia jeden z tych warunków:
  • Kierowanie na interfejs API na poziomie 28 lub niższym.
  • Deklaruje w pliku manifestu, że potrzebuje biblioteki, ustawiając atrybut android:name <uses-library> na org.apache.http.legacy.

Implementacja AOSP spełnia te wymagania.

3.2. Zgodność Soft API

Oprócz zarządzanych interfejsów API opisanych w sekcji 3.1 Android zapewnia też ważny „rozbudowany” interfejs API tylko w czasie działania. Mogą to być intencje, uprawnienia i podobne aspekty aplikacji na Androida, których nie można egzekwować podczas kompilowania aplikacji.

3.2.1. Uprawnienia

• [C-0-1] Implementacje urządzeń MUSZĄ obsługiwać i egzekwować wszystkie stałe uprawnień zgodnie z dokumentacją na stronie z informacjami o uprawnieniach. Pamiętaj, że sekcja 9 zawiera dodatkowe wymagania związane z modelem zabezpieczeń Androida.

3.2.2. Parametry kompilacji

Interfejsy API Androida zawierają pewną liczbę stałych w klasie android.os.Build, które służą do opisania bieżącego urządzenia.

• [C-0-1] Aby zapewnić spójne, istotne wartości w różnych implementacjach urządzeń, w tabeli poniżej znajdziesz dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi implementacje MUSZĄ być zgodne.

Parametr	Szczegóły
WERSJA.PREMIERA	Wersja obecnie uruchomionego systemu Android w formacie zrozumiałym dla człowieka. To pole MUSI mieć jedną z wartości ciągu znaków zdefiniowanych w 11.
WERSJA.SDK	Wersja obecnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 11 to pole MUSI mieć wartość całkowitą 11_INT.
VERSION.SDK_INT	Wersja obecnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 11 to pole MUSI mieć wartość całkowitą 11_INT.
WERSJA.INCREMENTALNA	Wartość wybrana przez mechanizm implementujący urządzenie, oznaczający konkretną kompilację obecnie działającego systemu Android, w formacie zrozumiałym dla człowieka. Tej wartości NIE WOLNO używać ponownie w różnych kompilacjach udostępnianych użytkownikom. Typowym zastosowaniem tego pola jest wskazywanie numeru kompilacji lub identyfikatora zmiany źródła, które zostały użyte do wygenerowania kompilacji. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII do wydrukowania i pasować do wyrażenia regularnego „^[^ :\/~]+$”.
PLANSZOWE	Wartość wybrana przez mechanizm implementujący urządzenie, określający konkretny wewnętrzny sprzęt używany przez urządzenie, w formacie zrozumiałym dla człowieka. To pole może być użyte do wskazania konkretnej wersji płyty zasilającej urządzenie. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
MARKI	Wartość odzwierciedlająca markę powiązaną z urządzeniem znaną użytkownikom. MUSI mieć format zrozumiały dla człowieka i MUSI reprezentować producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
OBSŁUGI_MOŻLIWOŚCI	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
OBSŁUGI_32_BIT_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
OBSŁUGI_64_BIT_ABIS	Nazwa drugiego zbioru 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ść z natywnym interfejsem API.
CPU_ABI2	Nazwa drugiego zbioru instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
URZĄDZENIE	Wartość wybrana przez program implementujący urządzenie, zawierająca nazwę deweloperską lub nazwę kodową identyfikującą konfigurację funkcji sprzętowych i konstrukcję przemysłową urządzenia. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Ta nazwa urządzenia NIE MOŻE zmieniać się przez cały okres użytkowania produktu.
DŹWIĘK	Ciąg jednoznacznie identyfikujący tę kompilację. MUSI być łatwo zrozumiała dla człowieka. MUSI być zgodna z tym szablonem: $(BRAND)/$(PRODUKT)/ $(DEVICE):$(VERSION.release)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Na przykład: acme/mojprodukt/ mydevice:11/LMYXX/3359:userdebug/test-keys Odcisk palca NIE MOŻE zawierać odstępów. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII.
SPRZĘT	Nazwa sprzętu (z wiersza poleceń jądra lub /proc). MUSI być łatwo zrozumiała dla człowieka. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
GOSPODARZE	Ciąg jednoznacznie identyfikujący hosta, na którym została utworzona kompilacja, w formacie zrozumiałym dla człowieka. Nie ma wymagań dotyczących konkretnego formatu tego pola, za wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu („”).
ID	Identyfikator wybrany przez mechanizm implementujący urządzenie w celu odwołania się do konkretnej wersji w formacie zrozumiałym dla człowieka. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale MUSI zawierać wartość na tyle zrozumiałą, aby użytkownicy mogli odróżnić kompilacje oprogramowania. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
PRODUCENT	Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma wymagań dotyczących konkretnego formatu tego pola, za wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu („”). To pole NIE MOŻE zmieniać się przez cały okres użytkowania usługi.
MODEL	Wartość wybrana przez program implementujący urządzenie, zawierająca znaną użytkownikowi nazwę urządzenia. POWINIEN być pod tą samą nazwą, pod którą urządzenie jest sprzedawane i sprzedawane użytkownikom. Nie ma wymagań dotyczących konkretnego formatu tego pola, za wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu („”). To pole NIE MOŻE zmieniać się przez cały okres użytkowania usługi.
USŁUGA	Wartość wybrana przez program implementujący urządzenie, zawierająca nazwę programistyczną lub nazwę kodową konkretnego produktu (SKU), która MUSI być niepowtarzalna w ramach tej samej marki. MUSI być zrozumiała dla człowieka, ale niekoniecznie przeznaczona dla użytkowników. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Ta nazwa produktu NIE MOŻE zmieniać się przez cały okres jego istnienia.
SERYJNY	MUSI zwracać wartość „UNKNOWN”.
TAGI	Rozdzielona przecinkami lista tagów wybranych przez mechanizm implementujący urządzenie, który dokładniej rozróżnia kompilację. Tagi MUSZĄ być zakodowane jako 7-bitowy kod ASCII, pasujące do wyrażenia regularnego „^[a-zA-Z0-9._-]+” i MUSZĄ mieć jedną z wartości odpowiadających 3 typowym konfiguracjom podpisywania platformy Androida: wersja-klucze, klucze dev i klucze testowe.
CZAS	Wartość reprezentująca sygnaturę czasową wystąpienia kompilacji.
TYP	Wartość wybrana przez narzędzie implementujące urządzenie, określająca konfigurację środowiska wykonawczego kompilacji. To pole MUSI mieć jedną z wartości odpowiadających 3 typowym konfiguracjom środowiska wykonawczego 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 konkretnego formatu tego pola, za wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu („”).
WERSJA.SECURITY_PATCH	Wartość wskazująca poziom poprawki zabezpieczeń kompilacji. MUSI wskazywać, że kompilacja nie jest w żaden sposób podatna na ataki opisane w wyznaczonym biuletynie na temat bezpieczeństwa publicznego w Androidzie. MUSI mieć format [RRRR-MM-DD] i odpowiadać zdefiniowanym ciągiem znaków udokumentowanym w biuletynie dotyczącym bezpieczeństwa w Androidzie lub w dokumencie Android Security Advisory, na przykład „2015-11-01”.
WERSJA.BASE_OS	Wartość reprezentująca parametr FINGERINSERT kompilacji, która jest identyczna z tą kompilacją poza poprawkami wymienionymi w biuletynie na temat bezpieczeństwa publicznego w Androidzie. MUSI zgłosić prawidłową wartość. Jeśli taka kompilacja nie istnieje, zgłoś pusty ciąg znaków („”).
WŁAŚCICIEL MOTYWACYJNY	Wartość wybrana przez mechanizm implementujący urządzenie identyfikujący konkretną wersję wewnętrznego programu rozruchowego używaną na urządzeniu w formacie zrozumiałym dla człowieka. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
getRadioVersion()	MUSI (być lub zwracać) wartość wybraną przez mechanizm implementujący urządzenie identyfikującą konkretną wewnętrzną wersję radia/modemu używaną w urządzeniu, w formacie zrozumiałym dla człowieka. Jeśli urządzenie nie ma wewnętrznego radia/modema, MUSI zwracać wartość NULL. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9._-,]+$”.
getSerial(),	MUSI (być lub zwracać) numer seryjny sprzętu, który MUSI być dostępny i unikalny na wszystkich urządzeniach z tym samym modelem MODEL i PRODUCENT. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9._-,]+$”.

3.2.3 Zgodność intencji

3.2.3.1. Częste intencje Application Intents

Intencje w Androidzie umożliwiają komponentom aplikacji żądanie działania funkcji z innych komponentów Androida. Projekt nadrzędny na Androida zawiera listę aplikacji, które implementują kilka wzorców intencji do wykonywania typowych działań.

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE jest wstępne wczytywanie co najmniej 1 aplikacji lub komponentu usługi z modułem obsługi intencji dla wszystkich wzorców filtrów intencji publicznych zdefiniowanych tutaj i dostarczanie realizacji, czyli spełnianie oczekiwań programistów w przypadku tych typowych intencji aplikacji, zgodnie z opisem w pakiecie SDK.

W Sekcji 2 znajdziesz obowiązkowe intencje aplikacji dla każdego typu urządzenia.

3.2.3.2. Rozwiązanie intencji

• [C-0-1] Android jest rozszerzoną platformą, dlatego implementacje urządzeń MUSZĄ zezwalać na zastępowanie przez aplikacje innych firm wszystkich wzorców intencji wymienionych w sekcji 3.2.3.1, z wyjątkiem ustawień. Implementacja open source Androida na to pozwala domyślnie.

• [C-0-2] Programy wdrażające na urządzeniu NIE MOGĄ przypisywać specjalnych uprawnień do aplikacji systemowych wykorzystywania tych wzorców intencji lub uniemożliwianie aplikacjom innych firm wiązania z nimi i przejmowania nad nimi kontroli. Zakaz ten obejmuje w szczególności m.in. wyłączenie interfejsu „Wybór”, który pozwala użytkownikowi wybierać spośród wielu aplikacji, które obsługują ten sam wzorzec intencji.

• [C-0-3] Implementacje urządzeń MUSZĄ udostępniać interfejs, który pozwala użytkownikom modyfikować domyślne działania pod kątem intencji.

• Implementacje urządzeń MOGĄ jednak udostępnić domyślne działania dla określonych wzorców identyfikatorów URI (np. http://play.google.com), jeśli działanie domyślne zawiera bardziej szczegółowy atrybut identyfikatora URI danych. Na przykład wzorzec filtra intencji określający identyfikator URI danych „http://www.android.com” jest bardziej szczegółowy niż podstawowy wzorzec intencji przeglądarki dla „http://”.

Android zawiera również mechanizm, który umożliwia aplikacjom innych firm deklarowanie wiarygodnego domyślnego działania związanego z łączeniem aplikacji w przypadku określonych typów intencji URI internetowego. Gdy takie wiarygodne deklaracje są zdefiniowane we wzorcach filtra intencji aplikacji, implementacje urządzeń:

• [C-0-4] MUSI spróbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji linków do zasobów cyfrowych, zgodnie z implementacją Menedżera pakietów w starszym projekcie Android Open Source.
• [C-0-5] MUSI próbować zweryfikować filtry intencji podczas instalacji aplikacji i ustawić wszystkie zweryfikowane filtry intencji URI jako domyślne moduły obsługi ich identyfikatorów URI.
• MOGĄ ustawić filtry intencji URI jako domyślne moduły obsługi ich identyfikatorów URI, jeśli zostaną one zweryfikowane, ale inne filtry URI kandydata nie przejdą weryfikacji. Jeśli tak działa implementacja na urządzeniu, MUSI udostępniać w menu ustawień odpowiednie zastąpienia wzorca identyfikatora URI.
• MUSI udostępniać w Ustawieniach te opcje linków do aplikacji w poszczególnych aplikacjach:
  • [C-0-6] Użytkownik MUSI mieć możliwość całościowego zastępowania domyślnego działania linków aplikacji: zawsze otwieraj, zawsze pytaj lub nigdy nie otwieraj – to ustawienie musi mieć zastosowanie do wszystkich kandydujących filtrów intencji URI.
  • [C-0-7] Użytkownik MUSI wyświetlić listę filtrów intencji URI kandydatów.
  • Implementacja na urządzeniu MOŻE dać użytkownikowi możliwość zastąpienia wybranych filtrów intencji URI, które zostały zweryfikowane, na podstawie poszczególnych intencji.
  • [C-0-8] Implementacja na urządzeniu MUSI zapewniać użytkownikom możliwość wyświetlenia i zastąpienia konkretnych filtrów intencji URI kandydatów, jeśli implementacja urządzenia umożliwia pomyślne przejście weryfikacji przez niektóre filtry intencji URI kandydatów, a inne – niepowodzeniem.

3.2.3.3 Przestrzenie nazw intencji

• [C-0-1] Implementacje urządzeń NIE MOGĄ zawierać żadnych komponentów Androida, które uwzględniają nowe intencje lub wzorce intencji przesyłania, używając atrybutów ACTION, CATEGORY lub innych kluczowych elementów w Androidzie. lub com.android..
• [C-0-2] Moduły implementujące urządzenia NIE MOGĄ zawierać żadnych komponentów Androida, które uwzględniają nowe intencje lub wzorce intencji transmisji używających ACTION, CATEGORY lub innego ciągu kluczowego w przestrzeni pakietu należącej do innej organizacji.
• [C-0-3] Osoby wdrażające urządzenie NIE MOGĄ zmieniać ani rozszerzać żadnych wzorców intencji wymienionych w sekcji 3.2.3.1.
• Implementacje na urządzeniach MOGĄ zawierać wzorce intencji wykorzystujące przestrzenie nazw w jasny i wyraźny sposób powiązane z ich własną organizacją. Zakaz ten jest podobny do zakazu określonego dla klas języka Java w sekcji 3.6.

3.2.3.4. Intencje związane z transmisją

Aplikacje innych firm korzystają z platformy do transmitowania określonych intencji w celu powiadomienia ich o zmianach w środowisku sprzętowym lub oprogramowania.

Implementacje na urządzeniach:

• [C-0-1] MUSI transmitować publiczne intencje transmisji wymienione tutaj w odpowiedzi na odpowiednie zdarzenia systemowe zgodnie z opisem w dokumentacji pakietu SDK. Pamiętaj, że to wymaganie nie jest sprzeczne z artykułem 3.5, ponieważ ograniczenie dotyczące aplikacji działających w tle zostało również opisane w dokumentacji pakietu SDK. Niektóre intencje transmisji zależą też od obsługi sprzętu. Jeśli urządzenie obsługuje niezbędny sprzęt, MUSI przekazywać intencje i działać zgodnie z dokumentacją pakietu SDK.

3.2.3.5. Warunkowe intencje aplikacji

Android zawiera ustawienia, które pozwalają użytkownikom w łatwy sposób wybierać domyślne aplikacje, takie jak ekran główny czy SMS-y.

W stosownych przypadkach implementacje urządzeń MUSZĄ zawierać podobne menu ustawień i być zgodne ze wzorcem filtra intencji i metodami interfejsu API opisanymi poniżej w dokumentacji pakietu SDK.

Jeśli implementacje urządzeń zgłaszają android.software.home_screen:

• [C-1-1] MUSI uwzględniać intencję android.settings.HOME_SETTINGS, aby wyświetlać domyślne menu ustawień aplikacji na ekranie głównym.

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

• [C-2-1] MUSI zawierać menu ustawień, które wywołuje intencję android.provider.Telephony.ACTION_CHANGE_DEFAULT, by wyświetlić okno umożliwiające zmianę domyślnej aplikacji SMS.

• [C-2-2] MUSI uwzględniać intencję android.telecom.action.CHANGE_DEFAULT_DIALER, aby wyświetlać okno umożliwiające użytkownikowi zmianę domyślnej aplikacji Telefon.

  • W przypadku połączeń przychodzących i wychodzących MUSI używać wybranego przez użytkownika domyślnego interfejsu aplikacji Telefon, z wyjątkiem połączeń alarmowych, które korzystają ze wstępnie zainstalowanej aplikacji Telefon.

• [C-2-3] MUSI uwzględniać intencję android.telecom.action.CHANGE_PHONE_ACCOUNTS w celu skonfigurowania ConnectionServices powiązanego z PhoneAccounts, a także domyślnego konta PhoneAccount, którego dostawca usług telekomunikacyjnych będzie używać do nawiązywania połączeń wychodzących. Implementacja AOSP spełnia to wymaganie, dodając opcję „Konta telefoniczne”. w menu „Połączenia”. menu ustawień.

• [C-2-4] MUSI zezwalać na dostęp android.telecom.CallRedirectionService w przypadku aplikacji z rolą android.app.role.CALL_REDIRECTION.

• [C-2-5] MUSI udostępniać informacje o zarobkach użytkownika, aby móc wybrać aplikację z przypisaną rolą android.app.role.CALL_REDIRECTION.
• [C-2-6] MUSI uwzględniać intencje android.intent.action.SENDTO i android.intent.action.VIEW oraz umożliwiać wysyłanie i wyświetlanie SMS-ów.
• [C-SR] Zdecydowanie zalecane są kreacje android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_Button, android.intent.action.VIEW i intencje android.intent.action.DIAL z wstępnie załadowaną aplikacją telefonu, która może obsługiwać te intencje i zapewniać realizację zgodnie z opisem w pakiecie SDK.

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

• [C-3-1] MUSI uwzględniać intencję android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlać domyślne menu ustawień aplikacji w przypadku płatności zbliżeniowych.
• [C-3-2] MUSI uwzględniać intencję android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT, aby wyświetlić działanie, które otwiera okno z prośbą o zmianę domyślnej usługi emulacji kart dla określonej kategorii zgodnie z opisem w pakiecie SDK.

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

• [C-4-1] MUSI uwzględniać te intencje: android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED i android.nfc.action.TECH_DISCOVERED, aby wyświetlić działanie, które spełnia oczekiwania deweloperów dotyczące tych intencji zgodnie z opisem w pakiecie SDK.

Jeśli implementacje urządzeń obsługują VoiceInteractionService i mają zainstalowaną więcej niż jedną aplikację korzystającą z tego interfejsu API, funkcje te:

• [C-4-1] MUSI uwzględniać intencję android.settings.ACTION_VOICE_INPUT_SETTINGS, aby wyświetlać domyślne menu ustawień aplikacji dla rozpoznawania i Asystenta głosowego.

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

• [C-5-1] MUSI uwzględniać intencję „android.bluetooth.adapter.action.REQUEST_ENABLE” i pokazywać aktywność systemu, aby użytkownik mógł włączyć Bluetooth.
• [C-5-2] MUSI uwzględniać intencję „android.bluetooth.adapter.action.REQUEST_DISCOVERABLE” i wyświetlać działanie systemu, które wymaga trybu wykrywalności.

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

• [C-6-1] MUSI zaimplementować działanie, które zareaguje na intencję ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. W przypadku implementacji z funkcją UI_MODE_TYPE_NORMAL MUSI być to działanie, w ramach którego użytkownik może przyznawać i odbierać dostęp aplikacji do konfiguracji zasad Nie przeszkadzać.

Jeśli implementacje urządzeń umożliwiają użytkownikom korzystanie z zewnętrznych metod wprowadzania na urządzeniu:

• [C-7-1] MUSI udostępniać dostępny dla użytkownika mechanizm do dodawania i konfigurowania zewnętrznych metod wejściowych w odpowiedzi na intencję android.settings.INPUT_METHOD_SETTINGS.

Jeśli implementacje urządzenia obsługują usługi ułatwień dostępu innych firm:

• [C-8-1] MUSI spełniać intencję android.settings.ACCESSIBILITY_SETTINGS, aby zapewnić dostępny dla użytkownika mechanizm włączania i wyłączania zewnętrznych usług ułatwień dostępu oprócz wstępnie załadowanych usług ułatwień dostępu.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Easy Connect i udostępnienie tej funkcji aplikacjom innych firm:

• [C-9-1] MUSI zaimplementować interfejsy API intencji Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI w sposób opisany w dokumentacji pakietu SDK.

Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych,: * [C-10-1] MUSI udostępniać w ustawieniach interfejs użytkownika, który obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, umożliwiając użytkownikom dodawanie aplikacji do listy dozwolonych lub usuwanie ich z niej.

Jeśli implementacje urządzeń nie obsługują trybu oszczędzania danych:

• [C-11-1] MUSI mieć działanie, które obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻE wdrożyć je jako no-op.

Jeśli implementacje urządzeń deklarują obsługę aparatu za pomocą interfejsu android.hardware.camera.any:

• [C-12-1] MUSI przestrzegać intencji android.media.action.STILL_IMAGE_CAMERA i android.media.action.STILL_IMAGE_CAMERA_SECURE oraz uruchamiać aparat w trybie nieruchomym zgodnie z opisem w pakiecie SDK.
• [C-12-2] MUSI uwzględniać intencję android.media.action.VIDEO_CAMERA uruchamiania kamery w trybie wideo zgodnie z opisem w pakiecie SDK.
• [C-12-3] MUSZĄ 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 implementacje urządzeń zgłaszają android.software.device_admin:

• [C-13-1] MUSI uwzględniać intencję android.app.action.ADD_DEVICE_ADMIN wywoływania interfejsu, która umożliwia użytkownikowi dodanie administratora urządzenia do systemu (lub umożliwienie mu jego odrzucenia).

• [C-13-2] MUSI uwzględniać intencje android.app.action.ADMIN_POLICY_COMPLIANCE, android.app.action.GET_PROVISIONING_MODE, android.app.action.PROVISIONING_successFUL, android.app.action.PROVISION_MANAGED_DEVICE, android.APP.PROFILE1.PROVISION_MANAGED_DEVICE, android.APP.PROFILE1.PROVIS. android.app.action.START_ENCRYPTION i mieć działanie zapewniające realizację tych intencji, zgodnie z opisem w pakiecie SDK tutaj.

Jeśli implementacje urządzeń zadeklarują flagę funkcji android.software.autofill:

• [C-14-1] MUSI w pełni wdrożyć interfejsy API AutofillService i AutofillManager oraz przestrzegać intencji android.settings.REQUEST_SET_AUTOFILL_SERVICE, aby wyświetlać domyślne menu ustawień aplikacji w celu włączenia i wyłączenia autouzupełniania oraz zmiany domyślnej usługi autouzupełniania dla użytkownika.

Jeśli implementacje na urządzeniu obejmują wstępnie zainstalowaną aplikację lub chcesz umożliwić aplikacjom innych firm dostęp do statystyk użytkowania:

• [C-SR] Zdecydowanie zalecamy, aby zapewnić dostępny dla użytkownika mechanizm przyznawania lub cofania dostępu do statystyk użytkowania w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS w przypadku aplikacji, które deklarują uprawnienia android.permission.PACKAGE_USAGE_STATS.

Jeśli implementacje urządzenia uniemożliwią dostęp do statystyk użytkowania aplikacjom, w tym także fabrycznie zainstalowanym użytkownikom,:

• [C-15-1] MUSI nadal mieć działanie obsługujące wzorzec intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale MUSI działać w trybie bez operacji – musi działać tak samo jak w przypadku odrzucenia prośby o dostęp.

Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.audio.output:

• [C-SR] Zdecydowanie zalecamy korzystanie z usług android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & Intencje android.speech.tts.engine.GET_SAMPLE_TEXT mają działanie zapewniające realizację tych intencji, zgodnie z opisem w pakiecie SDK tutaj.

Android obsługuje interaktywne wygaszacze ekranu (wcześniej znane jako Dreams). Wygaszacze ekranu pozwalają użytkownikom na interakcję z aplikacjami, gdy urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji dokującej. Implementacje na urządzeniach:

• MUSI obsługiwać wygaszacze ekranu i udostępniać użytkownikom opcję ustawień w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

3.2.4 Działania na dodatkowych/wielu wyświetlaczach

Jeśli implementacje urządzeń pozwalają na uruchamianie normalnych aktywności na Androidzie na więcej niż jednym wyświetlaczu:

• [C-1-1] MUSI ustawiać flagę funkcji android.software.activities_on_secondary_displays.
• [C-1-2] MUSI gwarantować zgodność z interfejsem API podobną do działania wykonywanego na ekranie głównym.
• [C-1-3] Nowa aktywność MUSI trafiać na ten sam ekran co aktywność, która uruchomiła je po uruchomieniu, bez określania docelowego sposobu wyświetlania przez interfejs API ActivityOptions.setLaunchDisplayId().
• [C-1-4] MUSI zniszczyć wszystkie działania, jeśli wyświetlany jest ekran z flagą Display.FLAG_PRIVATE.
• [C-1-5] MUSI bezpiecznie ukrywać treści na wszystkich ekranach, gdy urządzenie jest zablokowane za pomocą bezpiecznego ekranu blokady, chyba że aplikacja włączy opcję wyświetlania na górze ekranu blokady za pomocą interfejsu API Activity#setShowWhenLocked().
• POWINNY jest zawierać parametr android.content.res.Configuration odpowiadający temu wyświetlaczowi, aby mógł być wyświetlany, działać prawidłowo i zachować zgodność w przypadku uruchomienia aktywności na wyświetlaczu dodatkowym.

Jeśli implementacje urządzeń pozwalają na uruchamianie zwykłych aktywności na Androidzie na ekranach dodatkowych, a wyświetlacz dodatkowy ma flagę android.view.Display.FLAG_PRIVATE:

• [C-3-1] Tylko właściciel wyświetlacza i systemu oraz czynności, które są na nim widoczne, MUSI mieć możliwość uruchamiania na nim działań. Każdy może uruchomić ekran na wyświetlaczu z flagą android.view.Display.FLAG_PUBLIC.

3.3. Zgodność z natywnym interfejsem API

Zgodność kodu natywnego stanowi wyzwanie. Z tego powodu do implementacji na urządzeniach:

• [SR] ZDECYDOWANIE ZALECANA do wykorzystania wymienionych poniżej bibliotek z nadrzędnego projektu Android Open Source.

3.3.1 Interfejsy binarne aplikacji

Zarządzany kod bajtowy Dalvik może wywoływać kod natywny podany w pliku .apk aplikacji w postaci pliku ELF .so skompilowanego pod kątem odpowiedniej architektury sprzętowej urządzenia. Ponieważ kod natywny jest w dużej mierze zależny od bazowej technologii procesora, Android definiuje szereg interfejsów binarnych aplikacji (ang. Application Binary Interfaces) w pakiecie Android NDK.

Implementacje na urządzeniach:

• [C-0-1] MUSI być zgodny z co najmniej jednym zdefiniowanym interfejsem ABI Androida NDK.
• [C-0-2] MUSI obejmować obsługę kodu działającego w środowisku zarządzanym w celu wywołania kodu natywnego z użyciem standardowej semantyki JNI (Java Native Interface).
• [C-0-3] MUSI być zgodna ze źródłem (tzn. z nagłówkiem) i z kodem binarnym (w przypadku interfejsu ABI) z każdą wymaganą biblioteką z poniższej listy.
• [C-0-5] MUSI podawać dokładne raporty dotyczące natywnego interfejsu binarnego aplikacji (ABI) obsługiwanego przez urządzenie, za pomocą parametrów android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS i android.os.Build.SUPPORTED_64_BIT_ABIS. Każdy interfejs ABI jest oddzielony przecinkami w kolejności od najbardziej do najmniej preferowanego.

• [C-0-6] Za pomocą powyższych parametrów MUSI zgłaszać podzbiór interfejsów ABI z poniższej listy. NIE MOŻE zgłaszać żadnych interfejsów ABI, których nie ma na liście.

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

• [C-0-7] MUSI udostępnić wszystkie poniższe biblioteki udostępniające natywne interfejsy API, aby udostępniać je aplikacjom zawierającym kod natywny:

  • libaaudio.so (natywna obsługa dźwięku AAudio).
  • libamidi.so (natywna obsługa MIDI, jeśli funkcja android.software.midi jest objęta roszczeniem zgodnie z opisem w artykule 5.9)
  • libandroid.so (natywna obsługa aktywności na Androidzie)
  • libc (biblioteka C)
  • libcamera2ndk.so
  • libdl (dynamiczny tag łączący)
  • libEGL.so (natywne zarządzanie powierzchnią OpenGL)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (logowanie w systemie Android)
  • libmediandk.so (obsługa natywnych interfejsów API multimediów)
  • libm (biblioteka matematyczna)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (obsługa OpenMAX AL 1.0.1)
  • libOpenSLES.so (obsługa dźwięku OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (minimalna obsługa języka C++)
  • libvulkan.so (Vulkan)
  • libz (kompresja Zlib)
  • Interfejs JNI

• [C-0-8] NIE MOŻE dodawać ani usuwać funkcji publicznych dla wymienionych powyżej bibliotek natywnych.

• [C-0-9] MUSI zawierać dodatkowe biblioteki spoza AOSP dostępne bezpośrednio dla aplikacji innych firm w /vendor/etc/public.libraries.txt.
• [C-0-10] NIE MOŻE udostępniać żadnych innych bibliotek natywnych zaimplementowanych i udostępnionych w AOSP jako bibliotek systemowych aplikacjom innych firm kierowanych na interfejs API na poziomie 24 lub wyższym, ponieważ są one zarezerwowane.
• [C-0-11] MUSI wyeksportować wszystkie symbole funkcji OpenGL ES 3.1 i Android Extension Pack (zdefiniowane w NDK) za pomocą biblioteki libGLESv3.so. Pamiętaj, że chociaż MUSZĄ być obecne wszystkie symbole, w sekcji 7.1.4.1 bardziej szczegółowo opisano wymagania dotyczące momentu pełnej implementacji poszczególnych funkcji.
• [C-0-12] MUSI eksportować symbole funkcji podstawowych symboli funkcji Vulkan 1.0, a także rozszerzenia 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ż MUSZĄ być obecne wszystkie symbole, w sekcji 7.1.4.2 szczegółowo opisano wymagania dotyczące momentu pełnej implementacji poszczególnych funkcji.
• POWINNA budować z użyciem kodu źródłowego i plików nagłówka dostępnych w źródłowym projekcie Android Open Source

Pamiętaj, że w przyszłych wersjach Androida możesz wprowadzić obsługę dodatkowych interfejsów ABI.

3.3.2 Zgodność z 32-bitowym kodem natywnym ARM

Jeśli implementacje urządzeń zgłaszają obsługę interfejsu ABI armeabi:

• [C-3-1] MUSI też obsługiwać język armeabi-v7a i zgłaszać jego obsługę, ponieważ armeabi służy tylko do zapewniania zgodności wstecznej ze starszymi aplikacjami.

Jeśli implementacje urządzeń zgłaszają obsługę interfejsu ABI armeabi-v7a, w przypadku aplikacji korzystających z tego interfejsu ABI:

• [C-2-1] MUSI zawierać poniższe wiersze w języku /proc/cpuinfo i NIE POWINNO zmieniać wartości na tym samym urządzeniu, nawet jeśli są one odczytywane przez inne interfejsy ABI.

  • Features:, a następnie lista wszystkich opcjonalnych funkcji procesora ARMv7 obsługiwanych przez urządzenie.
  • CPU architecture:, po której następuje liczba całkowita opisująca najwyżej obsługiwaną architekturę ARM urządzenia (np. „8” na urządzeniach z architekturą ARMv8).

• [C-2-2] MUSI zawsze udostępniać te operacje, nawet w przypadku, gdy interfejs ABI jest zaimplementowany w architekturze ARMv8, przez natywnego wsparcia procesora lub przez emulację oprogramowania:

  • Instrukcje dotyczące SWP i SWPB.
  • SETEND instrukcję
  • Operacje na barierach CP15ISB, CP15DSB i CP15DMB.

• [C-2-3] MUSI obsługiwać rozszerzenie Advanced SIMD (NEON).

3.4 Zgodność z internetem

3.4.1 Zgodność z WebView

Jeśli implementacje urządzeń zapewniają pełną implementację interfejsu API android.webkit.Webview:

• [C-1-1] MUSI zgłosić użytkownika android.software.webview.
• [C-1-2] Żeby wdrożyć interfejs API android.webkit.WebView, [C-1-2] MUSI użyć projektu Chromium z wcześniejszego projektu Android Open Source w wersji Androida 11.

• [C-1-3] Ciąg znaków klienta użytkownika zgłoszony przez WebView MUSI mieć ten format:

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • Wartość ciągu $(VERSION) MUSI być taka sama jak wartość android.os.Build.VERSION.Release.
  • Ciąg $(MODEL) MOŻE być pusty, ale jeśli nie jest pusty, MUSI mieć tę samą wartość co android.os.Build.MODEL.
  • „Kompilacja/$(BUILD)” MOŻE zostać pominięty, ale jeśli jest podany, ciąg $(BUILD) MUSI być taki sam jak wartość android.os.Build.ID.
  • Wartość ciągu $(CHROMIUM_VER) MUSI być wersją przeglądarki Chromium z nadrzędnego projektu Android Open Source.
  • Implementacje na urządzeniach MOGĄ pominąć element „mobilny” w ciągu znaków klienta użytkownika.

• Komponent WebView POWINIEN obsługiwać jak najwięcej funkcji HTML5, a jeśli go obsługuje, POWINIEN być zgodny ze specyfikacją HTML5.

• [C-1-3] MUSI renderować podaną treść lub zawartość zdalnego adresu URL w procesie innym niż aplikacja, która tworzy wystąpienie komponentu WebView. W szczególności oddzielny proces renderowania MUSI mieć niższe uprawnienia, działać jako osobny identyfikator użytkownika, nie może mieć dostępu do katalogu danych aplikacji, nie może mieć bezpośredniego dostępu do sieci i mieć dostęp tylko do minimum wymaganych usług systemowych za pomocą Binder. Implementacja AOSP komponentu WebView spełnia to wymaganie.

Pamiętaj, że jeśli implementacje urządzeń są 32-bitowe lub mają zadeklarowaną flagę funkcji android.hardware.ram.low, są one zwolnione z obowiązku spełnienia 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, one:

• [C-1-1] MUSI obsługiwać każdy z tych interfejsów API powiązanych z HTML5:
  • pamięć podręczna aplikacji/operacja offline
  • <film>
  • geolokalizacja
• [C-1-2] MUSI obsługiwać interfejs webstorage API HTML5/W3C i interfejs IndexedDB API HTML5/W3C. Pamiętaj, że w związku z tym, że treści standardów tworzenia stron internetowych wolą korzystać z IndexedDB zamiast do przechowywania danych w internecie, IndexedDB może stać się wymaganym komponentem w przyszłej wersji Androida.
• MOŻE przesłać niestandardowy ciąg znaków klienta użytkownika do samodzielnej aplikacji przeglądarki.
• POWINNY jest wdrożyć obsługę jak największej ilości treści w języku HTML5 w samodzielnej aplikacji przeglądarki (niezależnie od tego, czy jest oparta na nadrzędnej aplikacji przeglądarki WebKit czy w zastępstwie innej firmy).

Jeśli jednak implementacje urządzeń nie zawierają samodzielnej aplikacji przeglądarki:

• [C-2-1] MUSI nadal obsługiwać wzorce intencji publicznej opisane w sekcji 3.2.3.1.

3.5. Zgodność behawioralna interfejsu API

Implementacje na urządzeniach:

• [C-0-9] MUSI dopilnować, aby wszystkie zainstalowane aplikacje były zgodne z funkcjami interfejsów API, chyba że dostęp do nich jest ograniczony w sposób opisany w artykule 3.5.1.
• [C-0-10] NIE MOŻE wdrażać metody dodawania do listy dozwolonych, która zapewnia zgodność działania interfejsu API tylko w przypadku aplikacji wybranych przez osoby zajmujące się implementacją urządzeń.

Działanie każdego z typów interfejsów API (zarządzane, elastyczne, natywne i internetowe) musi być zgodne z preferowaną implementacją projektu Android Open Source nadrzędnego. Oto niektóre obszary zgodności:

• [C-0-1] Urządzenia NIE MOGĄ zmieniać działania ani semantyki intencji standardowej.
• [C-0-2] Urządzenia NIE MOGĄ zmieniać semantyki cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (np. Service, Activity czy ContentProvider).
• [C-0-3] Urządzenia NIE MOGĄ zmieniać semantyki uprawnień standardowych.
• Urządzenia NIE MOGĄ zmieniać ograniczeń nałożonych na aplikacje w tle. Bardziej szczegółowo:
  • [C-0-4] Aby otrzymywać dane wyjściowe z GnssMeasurement i GnssNavigationMessage, MUSISZ przestać wykonywać wywołania zwrotne zarejestrowane przez aplikację.
  • [C-0-5] MUSI ograniczać częstotliwość aktualizacji dostarczanych do aplikacji za pomocą klasy interfejsu API LocationManager lub metody WifiManager.startScan().
  • [C-0-6] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, NIE MOŻE umożliwiać rejestrowania odbiorników na potrzeby niejawnych komunikatów Androida w pliku manifestu, chyba że intencja transmisji wymaga uprawnienia "signature" lub "signatureOrSystem" protectionLevel lub znajduje się na liście wykluczeń.
  • [C-0-7] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zatrzymywać usługi w tle, tak jakby aplikacja wywołała metodę stopSelf(), chyba że aplikacja znajduje się na tymczasowej liście dozwolonych, aby umożliwić wykonywanie zadania, które jest widoczne dla użytkownika.
  • [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI uruchamiać blokady uśpienia ustawione przez aplikację.
• [C-0-9] Urządzenia MUSZĄ zwracać tych dostawców zabezpieczeń w postaci pierwszych 7 wartości tablicy z metody Security.getProviders() w podanej kolejności, z podanymi nazwami (wyświetlanymi przez funkcję Provider.getName()) i klasami, chyba że aplikacja zmodyfikowała listę za pomocą funkcji insertProviderAt() lub removeProvider(). Urządzenia MOGĄ zwrócić listę dostawców z listy poniżej.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCObejście – android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

Powyższa lista nie jest wyczerpująca. Compatibility Test Suite (CTS) testuje znaczną część platformy pod kątem zgodności behawioralnej, ale nie wszystkie. Odpowiada on za zapewnienie zgodności behawioralnej z projektem Android Open Source. Z tego względu w miarę możliwości osoby wdrażające na urządzeniach POWINNY są używać kodu źródłowego dostępnego w ramach Android Open Source Project, zamiast ponownie wdrażać istotne części systemu.

3.5.1 Ograniczenie aplikacji

Jeśli na urządzeniach zaimplementowano zastrzeżony mechanizm ograniczania dostępu aplikacji, który jest bardziej restrykcyjny niż zasobnik gotowości aplikacji, to:

• [C-1-1] MUSI udostępniać listę aplikacji objętych ograniczeniami.
• [C-1-2] MUSI zapewniać użytkownikom kompetencje umożliwiające włączanie i wyłączanie ograniczeń w poszczególnych aplikacjach.
• [C-1-3] NIE MOŻE automatycznie stosować ograniczeń bez dowodów na słabe działanie systemu, ale MOŻESZ zastosować ograniczenia do aplikacji w przypadku wykrycia nieprawidłowego działania systemu, takich jak ciągłe blokady uśpienia, długo działające usługi i inne kryteria. Kryteria MOGĄ być określone przez osoby zajmujące się implementacją urządzenia, ale MUSZĄ być związane z wpływem aplikacji na stan systemu. Inne kryteria, które nie są bezpośrednio związane ze stanem systemu, takie jak brak popularności aplikacji na rynku, NIE mogą być brane pod uwagę.
• [C-1-4] NIE MOŻE automatycznie stosować ograniczeń dotyczących aplikacji, gdy użytkownik ręcznie wyłączył ograniczenia, i MOŻE zasugerować użytkownikowi zastosowanie ograniczeń
• [C-1-5] MUSI informować użytkowników, jeśli ograniczenia aplikacji są stosowane automatycznie. Takie informacje MUSZĄ zostać udostępnione w ciągu 24 godzin od zastosowania ograniczeń.
• [C-1-6] MUSI zwracać wartość true w przypadku ActivityManager.isBackgroundRestricted(), gdy aplikacja objęta ograniczeniami wywołuje ten interfejs API.
• [C-1-7] NIE MOŻE ograniczać aplikacji znajdującej się na pierwszym planie, która jest jawnie używana przez użytkownika.
• [C-1-8] MUSI zawiesić ograniczenia w aplikacji, która staje się główną aplikacją na pierwszym planie, gdy użytkownik wyraźnie zacznie używać aplikacji, która wcześniej była objęta ograniczeniami.

3.6. Przestrzenie nazw interfejsów API

Android przestrzega konwencji przestrzeni nazw pakietów i klas zdefiniowanych przez język programowania Java. Aby zapewnić zgodność z aplikacjami innych firm, implementujące urządzenia NIE MOGĄ wprowadzać żadnych zabronionych zmian w tych przestrzeniach nazw pakietów (patrz poniżej):

• java.*
• javax.*
• sun.*
• android.*
• androidx.*
• com.android.*

Oznacza to, że:

• [C-0-1] NIE MOŻE modyfikować publicznie dostępnych interfejsów API na platformie Androida przez zmianę podpisu metod lub podpisów klas bądź usuwanie klas bądź pól klas.
• [C-0-2] NIE MOŻE dodawać żadnych publicznie dostępnych elementów (takich jak klasy lub interfejsy, pola czy metody do istniejących klas lub interfejsów) ani testowych interfejsów API ani systemowych interfejsów API w powyższych przestrzeniach nazw. „Element widoczny publicznie” to każdy obiekt, który nie jest oznaczony znacznikiem „@hide” używanym w kodzie źródłowym Androida.

Implementacje na urządzeniach MOGĄ zmodyfikować podstawową implementację interfejsów API, ale takie modyfikacje:

• [C-0-3] NIE MOŻE wpływać na określone zachowanie ani na podpis w języku Java jakichkolwiek publicznie udostępnionych interfejsów API.
• [C-0-4] NIE POWINNY być reklamowane ani w żaden inny sposób prezentowane deweloperom.

Jednak twórcy implementacji urządzeń MOGĄ dodać niestandardowe interfejsy API poza standardową przestrzenią nazw Androida, ale niestandardowe interfejsy API:

• [C-0-5] NIE MOŻE znajdować się w przestrzeni nazw należącej do innej organizacji lub do innej organizacji. Na przykład narzędzia implementujące urządzenia NIE MOGĄ dodawać interfejsów API do przestrzeni nazw com.google.* ani do podobnej przestrzeni nazw – może to robić tylko Google. Podobnie firma Google NIE MOŻE dodawać interfejsów API do innych firm przestrzeni nazw.
• [C-0-6] MUSI być spakowana w bibliotece współdzielonej Androida, tak aby większe wykorzystanie pamięci przez interfejsy API miało wpływ tylko na aplikacje, które z nich korzystają (za pomocą mechanizmu <uses-library>).

Jeśli mechanizm implementujący urządzenia proponuje ulepszenie jednej z przestrzeni nazw pakietów powyżej (na przykład przez dodanie nowej przydatnej funkcji do istniejącego interfejsu API lub dodanie nowego interfejsu API), może on wejść na stronę source.android.com i rozpocząć proces przesyłania zmian i kodu, zgodnie z informacjami na tej stronie.

Powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java. ta sekcja ma tylko pomóc wzmocnić te konwencje i uczynić je wiążącymi przez włączenie ich do tej definicji zgodności.

3.7. Zgodność środowiska wykonawczego

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać pełny format DEX (Dalvik Executable) oraz specyfikację i semantykę kodu bajtowego Dalvik.

• [C-0-2] MUSI skonfigurować środowiska wykonawcze Dalvik, aby przydzielać pamięć zgodnie z nadrzędną platformą Androida oraz w tabeli poniżej. (definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).

• POWINIEN użyć środowiska wykonawczego Android (ART), referencyjnej nadrzędnej implementacji formatu wykonywalnego Dalvik i systemu zarządzania pakietami implementacji referencyjnej.

• W celu zapewnienia stabilności środowiska wykonawczego MUSISZ przeprowadzać testy rozmycia w różnych trybach wykonania i architekturach docelowych. Zapoznaj się z narzędziami JFuzz i DexFuzz na stronie projektu Android Open Source.

Pamiętaj, że podane poniżej wartości pamięci są uważane za wartości minimalne, a implementacje urządzeń MOGĄ przeznaczyć więcej pamięci na aplikację.

Układ ekranu	Gęstość ekranu	Minimalna pamięć aplikacji
Zegarek z Androidem	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)	36MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (Xhdpi)	48MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
mały/normalny	120 dpi (ldpi)	32MB
	140 dpi (140dpi)
	160 dpi (mdpi)
	180 dpi (180dpi)	48MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (Xhdpi)	80MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
duży	120 dpi (ldpi)	32MB
	140 dpi (140dpi)	48MB
	160 dpi (mdpi)
	180 dpi (180dpi)	80MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi (Xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
bardzo duża	120 dpi (ldpi)	48MB
	140 dpi (140dpi)	80MB
	160 dpi (mdpi)
	180 dpi (180dpi)	96MB
	200 dpi (200dpi)
	213 dpi (tvdpi)
	220 dpi (220dpi)
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (Xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8. Zgodność interfejsu użytkownika

3.8.1 Menu z aplikacjami (ekran główny)

Android zawiera aplikację uruchamiającą (ekran główny) i obsługę aplikacji innych firm, które zastępują program uruchamiający (ekran główny).

Jeśli implementacje urządzeń pozwalają aplikacjom innych firm na zastępowanie ekranu głównego urządzenia:

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.home_screen.
• [C-1-2] MUSI zwracać obiekt AdaptiveIconDrawable, gdy aplikacja innej firmy przesyła ikonę za pomocą tagu <adaptive-icon>, a metody pobierania ikon są wywoływane przez metody PackageManager.

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

• [C-2-1] MUSI zgłosić true za ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] MUSISZ mieć zgodę użytkownika na dodanie skrótu żądanego przez aplikacje za pomocą metody API ShortcutManager.requestPinShortcut().
• [C-2-3] MUSI obsługiwać przypięte skróty oraz skróty dynamiczne i statyczne zgodnie z dokumentacją na stronie Skróty aplikacji.

Jeśli implementacje urządzeń nie obsługują przypinania skrótów w aplikacji:

• [C-3-1] MUSI zgłosić false za ShortcutManager.isRequestPinShortcutSupported().

Jeśli implementacje urządzeń implementują domyślny program uruchamiający, który zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm przy użyciu interfejsu API Skrót Manager, powoduje 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 API ShortcutManager.

Jeśli implementacje urządzeń zawierają domyślną aplikację uruchamiającą, która wyświetla plakietki przy ikonach aplikacji:

• [C-5-1] MUSI respektować metodę interfejsu API NotificationChannel.setShowBadge(). Inaczej mówiąc, jeśli wartość jest ustawiona na true, pokazuj wizualizację powiązaną z ikoną aplikacji i nie pokazuj żadnych schematów plakietek ikony aplikacji, gdy wszystkie kanały powiadomień aplikacji mają ustawioną wartość false.
• MOŻE zastępować plakietki ikony aplikacji ich zastrzeżonym schematem, jeśli aplikacje innych firm wskazują na obsługę zastrzeżonego schematu plakietek za pomocą zastrzeżonych interfejsów API, lecz POWINNY jest korzystać z zasobów i wartości dostarczonych przez interfejsy API plakietek powiadomień opisane w pakiecie SDK, takie jak Notification.Builder.setNumber() i interfejs API Notification.Builder.setBadgeIconType().

3.8.2 Widżety

Android obsługuje widżety aplikacji innych firm, definiując typ komponentu i odpowiedni interfejs API oraz cykl życia, które pozwalają aplikacjom na udostępnianie użytkownikowi widżetu „AppWidget”.

Jeśli implementacje urządzeń obsługują widżety aplikacji innych firm:

• [C-1-1] MUSI zadeklarować obsługę funkcji platformy android.software.app_widgets.
• [C-1-2] MUSI zawierać wbudowaną obsługę widżetów AppWidgets i udostępniać afordancje interfejsu użytkownika, aby dodawać, konfigurować, wyświetlać i usuwać elementy AppWidgets bezpośrednio w Menu z aplikacjami.
• [C-1-3] MUSI wyświetlać widżety o wymiarach 4 x 4 w standardowym rozmiarze siatki. Szczegółowe informacje znajdziesz w artykule App Widget DesignGuidelines 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:

• [C-2-1] MUSI zgłosić true za AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] MUSISZ mieć zgodę użytkownika na dodanie skrótu żądanego przez aplikacje za pomocą metody API AppWidgetManager.requestPinAppWidget().

3.8.3 Powiadomienia

Android obejmuje interfejsy API Notification i NotificationManager, które umożliwiają deweloperom aplikacji innych firm powiadamianie użytkowników o ważnych wydarzeniach i przyciąganie uwagi, używając podzespołów (np. dźwięku, wibracji i światła) i funkcji oprogramowania (np. obszaru powiadomień, paska systemu) urządzenia.

3.8.3.1 Prezentacja powiadomień

Jeśli implementacje urządzeń umożliwiają aplikacjom innych firm powiadamianie użytkowników o ważnych wydarzeniach:

• [C-1-1] MUSI obsługiwać powiadomienia korzystające z funkcji sprzętowych zgodnie z dokumentacją pakietu SDK i w zakresie, w jakim jest to możliwe w przypadku implementacji sprzętowej. Jeśli na przykład urządzenie jest wyposażone w wibrator, MUSI prawidłowo wdrożyć interfejsy API wibracji. Jeśli w implementacji urządzenia nie ma sprzętu, odpowiednie interfejsy API MUSZĄ zostać wdrożone w trybie bezobsługowym. Szczegółowe informacje na ten temat znajdziesz w sekcji 7.
• [C-1-2] MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki animacji itp.) zawarte w interfejsach API lub w przewodniku po stylu ikon na pasku stanu/systemu. MOGĄ jednak zapewniać użytkownikom powiadomienia inne niż w przypadku referencyjnej implementacji Android Open Source.
• [C-1-3] MUSI spełniać i wdrażać odpowiednie działania opisane w przypadku interfejsów API w zakresie aktualizowania, usuwania i grupowania powiadomień.
• [C-1-4] MUSI zapewniać pełne działanie interfejsu API notificationChannel w dokumentacji pakietu SDK.
• [C-1-5] MUSI zapewniać użytkownikowi zgodę na blokowanie i modyfikowanie powiadomień z określonej aplikacji innej firmy na każdym poziomie kanału i pakietu aplikacji.
• [C-1-6] MUSI też zapewnić użytkownikowi możliwość wyświetlania usuniętych kanałów powiadomień.
• [C-1-7] MUSI prawidłowo renderować wszystkie zasoby (obrazy, naklejki, ikony itp.) dostępne w ramach funkcji notification.MessagingStyle obok tekstu powiadomienia bez dodatkowej interakcji ze strony użytkownika. Na przykład MUSZĄ wyświetlać wszystkie zasoby, w tym ikony udostępnione przez android.app.Person w rozmowie grupowej, która jest ustawiona za pomocą metody setGroupConversation.
• [C-SR] Zdecydowanie ZALECANE jest automatyczne wyświetlanie informacji o zainteresowaniu użytkowników w celu zablokowania powiadomienia z określonej aplikacji innej firmy na każdym kanale i poziomie pakietu aplikacji po kilkukrotnym odrzuceniu powiadomienia przez użytkownika.
• OBSŁUGA powiadomień rozszerzonych.
• TRZEBA pokazywać powiadomienia o wyższym priorytecie jako powiadomienia typu HUD.
• MUSISZ mieć możliwość uśpienia powiadomień.
• MOŻE zarządzać tylko widocznością i czasem, w którym aplikacje innych firm mogą powiadamiać użytkowników o ważnych wydarzeniach, aby zniwelować zagrożenia, takie jak rozpraszanie uwagi kierowcy.

Android 11 wprowadza obsługę powiadomień o rozmowach, czyli powiadomień korzystających z funkcji MessagingStyle i udostępnia opublikowany identyfikator skrótu People.

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE są grupy i wyświetlanie conversation notifications przed powiadomieniami innymi niż powiadomienia związane z rozmową, z wyjątkiem bieżących powiadomień usługi na pierwszym planie i powiadomień importance:high.

Jeśli implementacje na urządzeniach obsługują conversation notifications, a aplikacja dostarczy wymagane dane na potrzeby bubbles:

• [C-SR] Zdecydowanie ZALECANE jest wyświetlanie tej rozmowy w dymku. Implementacja AOSP spełnia te wymagania w domyślnym interfejsie systemu, ustawieniach i Menu z aplikacjami.

Jeśli implementacje urządzeń obsługują powiadomienia rozszerzone, zostaną w nich wprowadzone zmiany:

• [C-2-1] MUSI używać dokładnie takich samych zasobów jak w klasie interfejsu API Notification.Style i jej podklasach dla prezentowanych elementów zasobów.
• POWINNY jest przedstawiać każdy element zasobu (np. ikonę, tytuł i tekst podsumowania) zdefiniowany w klasie interfejsu API Notification.Style i jej podklasach.

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

• [C-3-1] Gdy wyświetlane są powiadomienia z ostrzeżeniem, MUSI używać widoku powiadomień HUD i zasobów zgodnie z opisem w klasie interfejsu API Notification.Builder.
• [C-3-2] MUSI wyświetlać działania wykonane w Notification.Builder.addAction() wraz z treścią powiadomienia bez dodatkowej interakcji z użytkownikiem, zgodnie z opisem w pakiecie SDK.

3.8.3.2 Usługa powiadamiania słuchaczy

Android obejmuje interfejsy API NotificationListenerService, które umożliwiają aplikacjom (raz wyraźnie włączone przez użytkownika) otrzymywanie kopii wszystkich powiadomień w miarę ich publikowania lub aktualizacji.

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo i niezwłocznie aktualizować wszystkie powiadomienia we wszystkich zainstalowanych i włączonych przez użytkownika usługach detektorów, w tym wszystkie metadane dołączone do obiektu Notification.
• [C-0-2] MUSI respektować wywołanie interfejsu API snoozeNotification() i odrzucać powiadomienie i wywołać wywołanie zwrotne po czasie drzemki ustawionym w wywołaniu interfejsu API.

Jeśli implementacje urządzeń pozwalają użytkownikom na uśpienie powiadomień:

• [C-1-1] MUSI prawidłowo odzwierciedlać stan odłożonych powiadomień za pomocą standardowych interfejsów API, takich jak NotificationListenerService.getSnoozedNotifications().
• [C-1-2] MUSI udostępnić tę funkcję uśpienia powiadomień z każdej zainstalowanej aplikacji innej firmy, chyba że pochodzą one z usług trwałych/działających na pierwszym planie.

3.8.3.3 Nie przeszkadzać

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

• [C-1-1] Jeśli implementacja urządzenia umożliwia użytkownikowi przyznawanie lub odrzucanie dostępu aplikacji innych firm do konfiguracji zasad Nie przeszkadzać, MUSI wyświetlać obok utworzonych przez użytkownika i wstępnie zdefiniowanych reguł Automatyczne reguły Nie przeszkadzać utworzone przez aplikacje.
• [C-1-3] MUSI uwzględniać wartości suppressedVisualEffects przekazywane w elemencie NotificationManager.Policy, a jeśli aplikacja ma ustawioną dowolną z flag SUPPRESSED_EFFECT_SCREEN_OFF lub SUPPRESSED_FE_SCREEN_ON, MUSI poinformować użytkownika, że efekty wizualne są wyłączone w menu ustawień Nie przeszkadzać.

3.8.4 Szukaj

Android zawiera interfejsy API, które pozwalają programistom wbudować wyszukiwarkę w aplikacje i udostępniać dane aplikacji w globalnym wyszukiwaniu w systemie. Ogólnie rzecz biorąc, funkcja składa się z pojedynczego interfejsu użytkownika dla całego systemu, który umożliwia użytkownikom wprowadzanie zapytań, wyświetlanie sugestii w miarę pisania i wyświetlanie wyników. Interfejsy API Androida umożliwiają programistom ponowne wykorzystanie tego interfejsu do wyszukiwania we własnych aplikacjach i dostarczania wyników do wspólnego globalnego interfejsu wyszukiwania.

• Implementacje na urządzeniach z Androidem POWINIEN obejmować wyszukiwanie globalne, pojedynczy, wspólny interfejs wyszukiwania dla całego systemu zdolny do generowania sugestii w czasie rzeczywistym w odpowiedzi na dane wejściowe użytkownika.

Jeśli implementacje urządzeń mają wdrożony globalny interfejs wyszukiwania:

• [C-1-1] MUSI wdrożyć interfejsy API, które pozwalają aplikacjom innych firm na dodawanie sugestii do pola wyszukiwania uruchomionego w trybie wyszukiwania globalnego.

Jeśli nie masz zainstalowanych żadnych aplikacji innych firm, które korzystają z wyszukiwania globalnego:

• Domyślnie POWINNY jest wyświetlać wyniki i sugestie wyszukiwarki internetowej.

Android obejmuje również interfejsy API Asystenta, które pozwalają aplikacjom decydować, ile informacji w bieżącym kontekście ma być udostępniane asystentowi na urządzeniu.

Jeśli implementacje urządzeń obsługują działanie wspomagające, mogą one:

• [C-2-1] MUSI jasno wskazywać użytkownikowi, kiedy kontekst jest udostępniany. Aby to zrobić:
  • Za każdym razem, gdy aplikacja asystująca uzyskuje dostęp do kontekstu i wokół krawędzi ekranu pada białe światło o czasie trwania i jasności zgodnym z implementacją Android Open Source Project lub dłuższy.
  • w przypadku wstępnie zainstalowanej aplikacji asystującej: zapewnienie użytkownikowi możliwości przechodzenia mniej niż 2 razy od domyślnego menu ustawień rozpoznawania mowy i Asystenta oraz udostępnianie kontekstu tylko wtedy, gdy użytkownik wyraźnie wywoła aplikację asystującą za pomocą słowa-klucza lub klawisza nawigacji wspomagającej.
• [C-2-2] Wyznaczona interakcja służąca do uruchomienia aplikacji asystującej zgodnie z opisem w sekcji 7.2.3 MUSI uruchomić wybraną przez użytkownika aplikację asystującą, czyli aplikację obsługującą VoiceInteractionService lub działanie obsługujące intencję ACTION_ASSIST.

3.8.5 Alerty i powiadomienia

Aplikacje mogą używać interfejsu API Toast do wyświetlania użytkownikowi krótkich, niemodalnych ciągó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ą wyjście ekranu lub wideo:

• [C-1-1] MUSI zapewniać użytkownikowi zgodę na zablokowanie wyświetlania przez aplikację okien alertów korzystających z TYPE_APPLICATION_OVERLAY . Implementacja AOSP spełnia to wymaganie, ponieważ zawiera opcje w obszarze powiadomień.

• [C-1-2] MUSI honorować interfejs Toast API i wyświetlać użytkownikom wygłaszane powiadomienia z aplikacji w jak najbardziej widoczny sposób.

3.8.6 Motywy

Android zapewnia „motywy” jako mechanizm, który pozwala aplikacjom stosować style w całej Aktywności lub w całej aplikacji.

Android obejmuje przyciski „Holo” i „Material”. rodzina motywów to zestaw stylów zdefiniowanych przez deweloperów aplikacji, które chcą pasować do wyglądu i stylu motywu Holo określonego w pakiecie SDK Androida.

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

• [C-1-1] NIE MOŻE zmieniać żadnych atrybutów motywu Holo, które są widoczne dla aplikacji.
• [C-1-2] MUSI obsługiwać motywy „Materiał” i NIE MOŻE zmieniać żadnych atrybutów motywu Material Design, ani ich zasobów widocznych dla aplikacji.
• [C-1-3] MUSI albo ustawić „sans-serif” rodzina czcionek na Roboto w wersji 2.x w przypadku języków obsługiwanych przez Roboto lub zapewnić użytkownikowi możliwość zmiany czcionki używanej w kodzie „sans-serif” rodziny czcionek na Roboto w wersji 2.x dla języków obsługiwanych przez Roboto.

Android zawiera także rodzinę motywów „Ustawienie domyślne urządzenia” jako zestaw zdefiniowanych stylów, które deweloperzy mogą wykorzystać, jeśli chcą dopasować wygląd i sposób działania motywu urządzenia określonego przez narzędzie do implementacji.

• Implementacje na urządzeniach MOGĄ zmodyfikować atrybuty domyślnego motywu urządzenia widoczne dla aplikacji.

Android obsługuje wariant z przezroczystymi paskami systemowymi, dzięki czemu deweloperzy aplikacji mogą wypełniać obszar za paskiem stanu i paskiem nawigacyjnym treścią aplikacji. Aby programiści mogli w sposób spójny korzystać z tej konfiguracji, zadbaj o zachowanie stylu ikony paska stanu w różnych implementacjach urządzeń.

Jeśli implementacje urządzeń mają systemowy pasek stanu:

• [C-2-1] MUSI używać białego koloru w przypadku ikon stanu systemu (takich jak siła sygnału czy poziom baterii) oraz powiadomień wysyłanych przez system, chyba że ikona wskazuje, że występuje problem, lub aplikacja prosi o podświetlenie paska stanu za pomocą flagi SYSTEM_UI_LIGHT_STATUS_BAR.
• [C-2-2] Gdy aplikacja prosi o wyświetlenie paska stanu diody, implementacja urządzenia z Androidem MUSI zmienić kolor ikon stanu systemu na czarny (szczegóły znajdziesz w sekcji R.style).

3.8.7 Animowane tapety

Android określa typ komponentu, odpowiedni interfejs API oraz cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi co najmniej jednej „animowanej tapety”. Animowane tapety to animacje, wzory lub podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które są wyświetlane jako tapeta za innymi aplikacjami.

Uznaje się, że urządzenie może niezawodnie wyświetlać animowane tapety, jeśli jest w stanie wyświetlać wszystkie animowane tapety bez ograniczeń w funkcjonalności i z rozsądną liczbą klatek na sekundę bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują awarię tapet lub aplikacji, a także inne zużywanie procesora lub baterii, zużywają nadmierną energię CPU lub baterii albo działają z niedostatecznie niską liczbą klatek, urządzenie nie może wyświetlać animowanych tapet. Na przykład niektóre animowane tapety mogą wykorzystywać kontekst OpenGL 2.0 lub 3.x do renderowania treści. Animowana tapeta nie będzie działać prawidłowo na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ użycie animowanej tapety z kontekstu OpenGL może kolidować z innymi aplikacjami, które korzystają też z kontekstu OpenGL.

• Implementacje animowanych tapet, które umożliwiają sprawne wyświetlanie animowanych tapet zgodnie z opisem powyżej, POWINNY SIĘ stosować do tapet animowanych.

Jeśli na urządzeniu są wdrożone animowane tapety:

• [C-1-1] MUSI zgłosić flagę funkcji platformy android.software.live_wallpaper.

3.8.8 Przełączanie aktywności

Nadrzędny kod źródłowy Androida zawiera ekran przeglądu, czyli systemowy interfejs użytkownika do przełączania zadań i wyświetlający ostatnio używane działania i zadania przy użyciu obrazu miniatury przedstawiającego graficzny stan aplikacji w momencie ostatniego opuszczenia aplikacji przez użytkownika.

Implementacje urządzeń korzystające z klawisza nawigacji funkcji ostatnich, zgodnie z opisem w sekcji 7.2.3, MOGĄ zmienić interfejs.

Jeśli implementacje urządzeń obejmujące klawisz nawigacyjny funkcji ostatnich zgodnie z opisem w sekcji 7.2.3 modyfikują interfejs, to:

• [C-1-1] MUSI obsługiwać do 7 wyświetlonych działań.
• NALEŻY wyświetlać przynajmniej tytuł 4 aktywności jednocześnie.
• [C-1-2] MUSI włączyć przypinanie ekranu i umożliwiać użytkownikowi włączenie funkcji w menu ustawień.
• W ostatnich przypadkach MUSI wyświetlać kolor zaznaczenia, ikonę i tytuł ekranu.
• POWINIEN wyświetlać afordancję zamykającą („x”), ale MOŻE opóźnić ją do czasu interakcji użytkownika z ekranami.
• NALEŻY zaimplementować skrót, który umożliwi łatwe przechodzenie do poprzedniej aktywności.
• POWINNY jest uruchamiać działanie szybkiego przełączania między 2 ostatnio używanymi aplikacjami, gdy klawisz funkcyjny ostatnich jest naciśnięty dwukrotnie.
• POWINNY jest wyzwalać tryb wielu okien podzielonego ekranu, jeśli jest obsługiwany, przy przytrzymaniu klawisza funkcji ostatnich okien.
• MOŻE wyświetlać ostatnie powiązane zdjęcia jako grupę poruszającą się razem.
• [SR] Zdecydowanie ZALECANE jest użycie nadrzędnego interfejsu użytkownika Androida (lub podobnego interfejsu opartego na miniaturach) na ekranie przeglądowym.

3.8.9 Zarządzanie danymi wejściowymi

Android zapewnia obsługę zarządzania danymi wejściowymi oraz zewnętrznych edytorów metody wprowadzania.

Jeśli implementacje urządzeń umożliwiają użytkownikom korzystanie z zewnętrznych metod wprowadzania na urządzeniu:

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy API IME zgodnie z definicją w dokumentacji pakietu Android SDK.

3.8.10. Sterowanie multimediami na ekranie blokady

Interfejs Remote Control Client API został wycofany z Androida 5.0 i zastąpiony szablonem powiadomienia multimedialnego, który umożliwia aplikacjom do multimediów integrowanie się z elementami sterującymi odtwarzaniem wyświetlanymi na ekranie blokady.

3.8.11 Wygaszacze ekranu (wcześniej Sny)

Informacje o ustawieniach używanych do konfigurowania wygaszacza ekranu znajdziesz w sekcji 3.2.3.5.

3.8.12. Lokalizacja

Jeśli urządzenia są wyposażone w czujnik sprzętowy (np. GPS), który może wskazać współrzędne lokalizacji,

• [C-1-2] MUSI wyświetlać aktualny stan lokalizacji w menu Lokalizacja w Ustawieniach.
• [C-1-3] NIE MOŻE wyświetlać trybów lokalizacji w menu Lokalizacja w Ustawieniach.

3.8.13. Unicode i czcionka

Android obsługuje znaki emoji zdefiniowane w standardzie Unicode 10.0.

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

• [C-1-1] MUSI być w stanie renderować znaki z emotikonów w kolorze glifu.
• [C-1-2] MUSI zawierać informacje dotyczące:
  • Czcionka Roboto 2 o różnych wagach – sans-szeryfowa-cienka, bezszeryfowa-lekka, bezszeryfowa-średnia, bezszeryfowa-czarna, bezszeryfowa-kondensowana, bezszeryfowa-kondensowana-light dla języków dostępnych na urządzeniu.
  • Pełne pokrycie Unicode 7.0 w alfabecie łacińskim, greckim i cyrylicy, w tym rozszerzone zakresy A, B, C i D w alfabecie łacińskim, a także wszystkie glify w bloku symboli walut w Unicode 7.0.
• POWINNA obsługiwać odcień skóry i różnorodne emotikony rodzinne zgodnie z raportem technicznym Unicode nr 51.

Jeśli implementacje urządzeń obejmują edytor IME:

• TRZEBA określić metodę wprowadzania znaków w przypadku tych emotikonów.

Android zapewnia obsługę renderowania czcionek birmańskich. Mjanma używa kilku czcionek niezgodnych ze standardem Unicode, znanych jako „Zawgyi”, które służą do renderowania w językach birmańskich.

Jeśli implementacje urządzeń obejmują obsługę języka birmańskiego:

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. Wiele okien

Jeśli implementacje urządzeń mogą wyświetlać wiele aktywności jednocześnie:

• [C-1-1] MUSI wdrożyć takie tryby wielu okien zgodnie z działaniami aplikacji i interfejsami API opisanymi w dokumentacji dotyczącej obsługi trybu wielu okien w pakiecie Android SDK oraz spełnić te wymagania:
• [C-1-2] MUSI uwzględniać wartość android:resizeableActivity ustawioną przez aplikację w pliku AndroidManifest.xml w sposób opisany w tym pakiecie SDK.
• [C-1-3] NIE MOŻE wyświetlać trybu podzielonego ani dowolnego ekranu, jeśli wysokość ekranu jest mniejsza niż 440 dp, a szerokość ekranu mniejsza niż 440 dp.
• [C-1-4] NIE MOŻNA zmienić rozmiaru aktywności do rozmiaru mniejszego niż 220 dp w trybach wielu okien innych niż obraz w obrazie.
• Implementacje na urządzeniach o rozmiarze ekranu xlarge POWINNA obsługiwać tryb dowolny.

Jeśli implementacje urządzeń obsługują tryby wielu okien i tryb podzielonego ekranu:

• [C-2-1] Domyślnie MUSI ładować program uruchamiający o zmienionym rozmiarze.
• [C-2-2] MUSI przyciąć zadokowaną aktywność w przypadku podzielonego ekranu wielu okien, ale POWINIEN pokazywać część jego zawartości, jeśli aplikacja Menu z aplikacjami jest zaznaczonym oknem.
• [C-2-3] MUSI uwzględniać zadeklarowane wartości AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight innej aplikacji uruchamiającej i nie mogą zastępować tych wartości podczas wyświetlania niektórych treści zadokowanej aktywności.

Jeśli implementacje urządzeń obsługują tryby wielu okien i obraz w obrazie, tryb wielu okien:

• [C-3-1] MUSI uruchamiać działania w trybie wielu okien w trybie obraz w obrazie, gdy aplikacja jest: * Kierowanie na interfejs API na poziomie 26 lub wyższym i deklarowane android:supportsPictureInPicture * Kierowanie na poziom API 25 lub niższy oraz deklarowanie zarówno android:resizeableActivity, jak i android:supportsPictureInPicture.
• [C-3-2] MUSI udostępniać działania w interfejsie SystemUI zgodnie z bieżącym działaniem PIP za pomocą interfejsu API setActions().
• [C-3-3] MUSI obsługiwać współczynniki proporcji większe lub równe 1:2,39 i mniejsze lub równe 2,39:1, zgodnie z aktywnością PIP podaną w interfejsie API setAspectRatio().
• [C-3-4] MUSI używać KeyEvent.KEYCODE_WINDOW do sterowania oknem PIP. Jeśli tryb PIP nie jest zaimplementowany, klucz MUSI być dostępny dla działania na pierwszym planie.
• [C-3-5] MUSI zapewniać użytkownikowi dostęp do funkcji blokowania wyświetlania aplikacji w trybie PIP. Implementacja AOSP spełnia to wymaganie dzięki elementom sterującym w obszarze powiadomień.

• [C-3-6] Gdy aplikacja nie zadeklaruje żadnej wartości dla AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight, MUSI przydzielić minimalną szerokość i wysokość okna PIP:

  • Urządzenia z funkcją Configuration.uiMode inną niż UI_MODE_TYPE_TELEVISION MUSZĄ przydzielać minimalną szerokość i wysokość 108 dp.
  • Urządzenia z funkcją Configuration.uiMode ustawioną na UI_MODE_TYPE_TELEVISION MUSZĄ przydzielać minimalną szerokość 240 dp i minimalną wysokość 135 dp.

3.8.15. Wycięcie w sieci reklamowej

Android obsługuje wycięcie w sieci reklamowej zgodnie z opisem w dokumencie na temat pakietu SDK. Interfejs DisplayCutout API określa obszar na krawędzi wyświetlacza, który może nie działać w danej aplikacji z powodu wycięcia w ekranie lub zakrzywionego wyświetlacza na krawędziach.

Jeśli implementacje urządzeń zawierają wycięcia w ekranie:

• [C-1-5] NIE MOŻE mieć wycięć, jeśli format obrazu wynosi 1,0 (1:1).
• [C-1-2] NIE MOŻE mieć więcej niż jednego wycięcia na krawędź.
• [C-1-3] MUSI uwzględniać flagi wycięcia w ekranie ustawione przez aplikację za pomocą interfejsu API WindowManager.LayoutParams zgodnie z opisem w pakiecie SDK.
• [C-1-4] MUSI podawać prawidłowe wartości dla wszystkich danych o wycięciu zdefiniowanych w interfejsie API DisplayCutout.

3.8.16. Sterowanie urządzeniami

Android obejmuje interfejsy API ControlsProviderService i Control, które umożliwiają aplikacjom innych firm publikowanie ustawień urządzenia, dzięki czemu użytkownicy mogą szybko określić stan urządzenia i podjąć odpowiednie działania.

Wymagania dla poszczególnych urządzeń znajdziesz w sekcji 2_2_3.

3.9. Administracja urządzeniem

Android zawiera funkcje, które umożliwiają aplikacjom wykrywającym zabezpieczenia wykonywanie funkcji administracyjnych na poziomie systemu, takich jak wymuszanie stosowania zasad dotyczących haseł czy zdalne czyszczenie pamięci przy użyciu interfejsu Android Device Administration API.

Jeśli implementacje urządzeń obejmują pełny zakres zasad administrowania urządzeniami zdefiniowanych w dokumentacji pakietu Android SDK, muszą one:

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

3.9.1 Obsługa administracyjna urządzeń

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

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

• [C-1-1] MUSI obsługiwać rejestrację klienta Device Policy (DPC) jako aplikacji właściciela urządzenia w sposób opisany poniżej:
  • Jeśli implementacja urządzenia nie ma jeszcze danych użytkownika, oznacza to, że:
    • [C-1-3] MUSI zgłosić true za DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] W odpowiedzi na działanie intencji android.app.action.PROVISION_MANAGED_DEVICE MUSI zarejestrować aplikację DPC jako właściciela urządzenia.
    • [C-1-5] MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia, jeśli urządzenie zadeklaruje obsługę komunikacji Near Field Communication (NFC) za pomocą flagi funkcji android.hardware.nfc i otrzyma wiadomość NFC zawierającą rekord z typem MIME MIME_TYPE_PROVISIONING_NFC.
  • Gdy implementacja urządzenia ma dane użytkownika:
    • [C-1-6] MUSI zgłosić false za DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] NIE MOŻE rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia.
• [C-1-2] MUSI wymagać wyrażenia zgody przed rozpoczęciem procesu obsługi administracyjnej lub w jego trakcie, aby uzyskać zgodę na ustawienie aplikacji jako właściciela urządzenia. Zgodę można wyrazić w wyniku działania użytkownika lub w inny sposób zautomatyzowany, ale przed rozpoczęciem obsługi administracyjnej właściciela urządzenia MUSI wyświetlić się odpowiednie powiadomienie (zgodnie z postanowieniami AOSP). Oprócz tego mechanizm udzielania zgody przez właściciela zautomatyzowanego urządzenia używany (przez firmy) do obsługi administracyjnej właściciela urządzenia NIE MOŻE zakłócać działania gotowego urządzenia w przypadku użytkowników indywidualnych.
• [C-1-3] NIE MOŻE kodować zgody na stałe ani uniemożliwiać korzystania z innych aplikacji właściciela urządzenia.

jeśli implementacje urządzeń deklarują android.software.device_admin, ale zawierają też zastrzeżone rozwiązanie do zarządzania właścicielem urządzenia i udostępniają mechanizm promowania aplikacji skonfigurowanej w danym rozwiązaniu jako „odpowiednika właściciela urządzenia”. na standardową opcję „Właściciel urządzenia”, są rozpoznawane przez standardowe interfejsy API Androida DevicePolicyManager, to:

• [C-2-1] MUSI mieć wdrożony proces pozwalający na sprawdzenie, czy promowana aplikacja należy do legalnego rozwiązania do zarządzania urządzeniami w firmie i została już skonfigurowana w zastrzeżonym rozwiązaniu tak, aby miała odpowiednie uprawnienia jako „Właściciel urządzenia”.
• [C-2-2] MUSI wyświetlać te same informacje o zgodzie właściciela urządzenia AOSP co w procesie zainicjowanym przez android.app.action.PROVISION_MANAGED_DEVICE przed zarejestrowaniem aplikacji DPC jako „właściciela urządzenia”.
• MOGĄ znajdować się na urządzeniu dane użytkownika, zanim aplikacja DPC zostanie zarejestrowana jako „Właściciel urządzenia”.

3.9.1.2 Obsługa administracyjna profili zarządzanych

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

• [C-1-1] MUSI wdrożyć interfejsy API, które pozwalają aplikacji kontrolera zasad dotyczących urządzeń (DPC) zostać właścicielem nowego profilu zarządzanego.

• [C-1-2] Proces obsługi administracyjnej profili zarządzanych (proces zainicjowany przez android.app.action.PROVISION_MANAGED_PROFILE) u użytkowników MUSI być zgodny z implementacją AOSP.

• [C-1-3] MUSI udostępniać w Ustawieniach następujące informacje o użytkownikach, aby wskazać użytkownikowi, że dana funkcja systemu została wyłączona przez kontroler zasad dotyczących urządzeń:

  • Spójna ikona lub inna informacja użytkownika (np. ikona informacji o AOSP) wskazująca, że konkretne ustawienie zostało ograniczone przez administratora urządzenia.
  • Krótki komunikat z wyjaśnieniem dostarczony przez administratora urządzenia na stronie setShortSupportMessage.
  • Ikona aplikacji DPC.

3.9.2 Obsługa profilu zarządzanego

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

• [C-1-1] MUSI obsługiwać profile zarządzane za pomocą interfejsów API android.app.admin.DevicePolicyManager.
• [C-1-2] MUSI zezwalać na utworzenie tylko jednego profilu zarządzanego.
• [C-1-3] MUSI używać plakietki ikony (podobnej do plakietki „Praca nadrzędna 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ę powiadomień (podobną do plakietki służbowej AOSP na poziomie nadrzędnym), aby wskazać, że użytkownik korzysta z aplikacji profilu zarządzanego.
• [C-1-5] MUSI wyświetlać komunikat informujący o tym, że użytkownik korzysta z profilu zarządzanego, gdy urządzenie zostanie wybudzone (ACTION_USER_PRESENT), a aplikacja na pierwszym planie znajduje się w profilu zarządzanym.
• [C-1-6] Jeśli istnieje profil zarządzany, MUSI wykazywać wizualną afordancję w intencji „Chooser” (Wybór). , aby umożliwić użytkownikowi przekazywanie intencji z profilu zarządzanego na użytkownika głównego lub na odwrót, jeśli funkcja jest włączona przez kontroler zasad dotyczących urządzeń.
• [C-1-7] Jeśli istnieje profil zarządzany, MUSI udostępniać następujące parametry użytkownika zarówno dla użytkownika głównego, jak i profilu zarządzanego:
  • Osobne zliczanie baterii, lokalizacji, mobilnej transmisji danych i wykorzystania miejsca na dane przez użytkownika głównego i profil zarządzany.
  • Niezależne zarządzanie aplikacjami VPN zainstalowanymi u głównego użytkownika lub profilu zarządzanego.
  • Niezależne zarządzanie aplikacjami zainstalowanymi u głównego użytkownika lub profilu zarządzanego.
  • Niezależne zarządzanie kontami w ramach głównego użytkownika lub profilu zarządzanego.
• [C-1-8] Zainstalowane aplikacje do połączeń telefonicznych, kontaktów i wiadomości mogą wyszukiwać i wyszukiwać informacje o rozmówcy z profilu zarządzanego (jeśli taki istnieje) razem z profilami głównymi (jeśli kontroler zasad dotyczących urządzeń na to zezwala).
• [C-1-9] MUSI spełniać wszystkie wymagania bezpieczeństwa obowiązujące na urządzeniu z włączoną obsługą wielu użytkowników (patrz sekcja 9.5), mimo że profil zarządzany nie jest liczony jako inny użytkownik oprócz głównego użytkownika.

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

• [C-2-1] MUSI obsługiwać możliwość określenia osobnego ekranu blokady spełniającego poniższe wymagania, aby przyznawać dostęp tylko do aplikacji działających w profilu zarządzanym.
  • Implementacje urządzeń MUSZĄ spełniać intencję DevicePolicyManager.ACTION_SET_NEW_PASSWORD i zawierać interfejs umożliwiający skonfigurowanie osobnych danych logowania na ekranie blokady dla profilu zarządzanego.
  • Dane logowania na ekran blokady profilu zarządzanego MUSZĄ korzystać z tego samego magazynu danych logowania i mechanizmów zarządzania co w profilu nadrzędnym, co zostało opisane na stronie projektu Android Open Source.
  • Zasady dotyczące haseł DPC MUSZĄ mieć zastosowanie tylko do danych logowania na ekranie blokady profilu zarządzanego, chyba że zostaną wywołane przez wystąpienie DevicePolicyManager zwrócone przez getParentProfileInstance.
• Gdy kontakty z profilu zarządzanego są wyświetlane we wstępnie zainstalowanym rejestrze połączeń, interfejsie połączenia, powiadomieniach w toku i nieodebranych połączeniach, kontaktach i aplikacjach do obsługi wiadomości, powinny mieć tę samą plakietkę, która oznacza aplikacje profilu zarządzanego.

3.9.3 Zarządzana pomoc dla użytkowników

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

• [C-1-1] MUSI zapewnić użytkownikowi możliwość wylogowania się z konta bieżącego i przełączenia się z powrotem na użytkownika głównego w sesji wielu użytkowników, gdy isLogoutEnabled zwróci wartość true. Informacje o użytkowniku MUSZĄ być dostępne na ekranie blokady bez odblokowywania urządzenia.

3.10. Ułatwienia dostępu

Android zapewnia warstwę ułatwień dostępu, która ułatwia użytkownikom z niepełnosprawnościami korzystanie z urządzeń. Dodatkowo Android udostępnia interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu otrzymywanie wywołań zwrotnych dla zdarzeń użytkownika i systemów oraz generują alternatywne mechanizmy informacji zwrotnych, takie jak zamiana tekstu na mowę, reakcje haptyczne czy nawigacja za pomocą trackballa/pada kierunkowego.

Jeśli implementacje urządzenia obsługują usługi ułatwień dostępu innych firm:

• [C-1-1] MUSI zawierać implementację platformy ułatwień dostępu w Androidzie w sposób opisany w dokumentacji pakietu SDK interfejsów Accessibility API.
• [C-1-2] MUSI generować zdarzenia ułatwień dostępu i dostarczać odpowiednie AccessibilityEvent we wszystkich zarejestrowanych implementacjach AccessibilityService zgodnie z dokumentacją w pakiecie SDK.
• [C-1-4] MUSI dodać przycisk na pasku nawigacyjnym systemu, który umożliwia użytkownikowi sterowanie usługą ułatwień dostępu, gdy włączone usługi ułatwień dostępu zadeklarują element AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Pamiętaj, że w przypadku implementacji urządzeń bez paska nawigacyjnego systemu ten wymóg nie ma zastosowania, ale implementacje urządzeń MUSZĄ dawać użytkownikowi możliwość sterowania tymi usługami ułatwień dostępu.

Jeśli implementacje urządzeń obejmują wstępnie zainstalowane usługi ułatwień dostępu, te funkcje:

• [C-2-1] MUSI wdrożyć te wstępnie zainstalowane usługi ułatwień dostępu jako aplikacje bezpośredniego rozruchu, gdy dane przechowywane są szyfrowane przy użyciu szyfrowania opartego na plikach (FBE).
• W gotowej konfiguracji powinien znajdować się mechanizm umożliwiający użytkownikom włączenie odpowiednich usług ułatwień dostępu, a także opcje umożliwiające dostosowanie rozmiaru czcionki i rozmiaru wyświetlacza oraz gestów powiększenia.

3.11. Przekształcanie tekstu na mowę

Android zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług zamiany tekstu na mowę i umożliwiają dostawcom usług ich implementację.

Jeśli implementacje urządzenia zgłaszają funkcję android.hardware.audio.output:

• [C-1-1] MUSI obsługiwać interfejsy API Android TTS Framework.

Jeśli implementacje na urządzeniach obsługują instalację mechanizmu zamiany tekstu na mowę firmy zewnętrznej, funkcje te:

• [C-2-1] MUSI zapewniać dostępność dla użytkownika, aby mógł on wybrać mechanizm zamiany tekstu na mowę do użycia na poziomie systemu.

3.12. Platforma wejścia TV

Android Television Interface Framework (TIF) ułatwia przesyłanie treści na żywo na urządzenia Android TV. TIF udostępnia standardowy interfejs API do tworzenia modułów wejściowych do sterowania urządzeniami Android TV.

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

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.live_tv.
• [C-1-2] MUSI obsługiwać wszystkie interfejsy API TIF, aby na urządzeniu mogły być instalowane i używane aplikacje, które korzystają z tych interfejsów oraz zewnętrzna usługa wprowadzania danych TIF.

3.13. Szybkie ustawienia

Android ma komponent interfejsu Szybkich ustawień, który zapewnia szybki dostęp do często używanych lub pilnych działań.

Jeśli implementacje urządzeń zawierają komponent interfejsu Szybkich ustawień i obsługują Szybkie ustawienia innych firm, te funkcje:

• [C-1-1] MUSI umożliwiać użytkownikowi dodawanie kafelków udostępnionych przez interfejsy API quicksettings w aplikacji innej firmy lub ich usuwanie.
• [C-1-2] NIE MOŻE automatycznie dodawać kafelka z aplikacji innej firmy bezpośrednio do Szybkich ustawień.
• [C-1-3] MUSI wyświetlać wszystkie dodane przez użytkowników kafelki z aplikacji innych firm razem z dostarczonymi przez system kafelkami szybkich ustawień.

3.14. Interfejs multimediów

Jeśli implementacje urządzeń obejmują aplikacje nieaktywowane głosem (aplikacje), które współdziałają z aplikacjami innych firm za pomocą MediaBrowser lub MediaSession, aplikacje:

• [C-1-2] MUSZĄ wyraźnie wyświetlać ikony uzyskane za pomocą getIconBitmap() lub getIconUri() oraz tytuły uzyskane za pomocą getTitle(), zgodnie z opisem na stronie MediaDescription. Mogą zostać skrócone, aby zapewnić zgodność z przepisami dotyczącymi bezpieczeństwa (np. aby rozpraszać uwagę kierowcy).

• [C-1-3] MUSI wyświetlać ikonę aplikacji innej firmy podczas wyświetlania materiałów dostarczanych przez tę aplikację.

• [C-1-4] MUSI umożliwiać użytkownikowi interakcję z całą hierarchią MediaBrowser. MOŻE ograniczać dostęp do określonej części hierarchii w celu zachowania zgodności z przepisami dotyczącymi bezpieczeństwa (np. aby rozpraszać uwagę kierowcy), ale NIE MOŻE traktować priorytetowo na podstawie treści lub dostawcy treści.

• [C-1-5] W przypadku MediaSession.Callback#onMediaButtonEvent MUSISZ kliknąć dwukrotnie KEYCODE_HEADSETHOOK lub KEYCODE_MEDIA_PLAY_PAUSE jako KEYCODE_MEDIA_NEXT.

3.15. Aplikacje błyskawiczne

Implementacje na urządzeniach MUSZĄ spełniać następujące wymagania:

• [C-0-1] Aplikacje błyskawiczne MUSZĄ mieć tylko uprawnienia, w których android:protectionLevel ma wartość "instant".
• [C-0-2] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcję z zainstalowanymi aplikacjami za pomocą intencji niejawnych, jeśli nie jest spełniony jeden z tych warunków:
  • Filtr wzorca intencji komponentu jest widoczny i ma wartość CATEGORY_BROWSABLE
  • Czynność: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
  • Miejsce docelowe jest bezpośrednio widoczne w tagu android:visibleTo InstantApps.
• [C-0-3] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami, chyba że komponent jest udostępniany przez android:visibleTo InstantApps.
• [C-0-4] Zainstalowane aplikacje NIE MOGĄ mieć dostępu do szczegółowych informacji o aplikacjach błyskawicznych na urządzeniu, chyba że zostaną z nimi jednoznacznie połączone.

Jeśli implementacje urządzeń obsługują aplikacje błyskawiczne:

• [C-1-1] MUSI udostępniać wymienione poniżej parametry pozwalające na korzystanie z aplikacji błyskawicznych. AOSP spełnia wymagania dotyczące domyślnego interfejsu systemu oraz ustawień i Menu z aplikacjami.
• [C-1-2] MUSI zapewnić użytkownikowi możliwość przeglądania i usuwania aplikacji błyskawicznych w pamięci podręcznej lokalnego pakietu aplikacji.
• [C-1-3] MUSI zawierać trwałe powiadomienie użytkownika, które można zwinąć, gdy aplikacja błyskawiczna działa na pierwszym planie. Powiadomienie użytkownika MUSI zawierać informację, że Aplikacje błyskawiczne nie wymagają instalacji, i oferować użytkownikom kierowanie na ekran z informacjami o aplikacji w Ustawieniach. Aplikacje błyskawiczne uruchamiane za pomocą intencji internetowych, które zostały zdefiniowane za pomocą intencji z działaniem ustawionym na Intent.ACTION_VIEW i ze schematem „http”. lub „https”, należy też zapewnić użytkownikowi dodatkowe możliwości, aby nie uruchamiać aplikacji błyskawicznej i uruchamiać powiązanego linku w skonfigurowanej przeglądarce, o ile taka przeglądarka jest dostępna na urządzeniu.
• [C-1-4] MUSI zezwalać na dostęp do uruchomionych aplikacji błyskawicznych z poziomu funkcji Ostatnie, jeśli na urządzeniu jest dostępna ta funkcja.
• [C-1-5] MUSI wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi za pomocą modułu obsługi intencji dla intencji wymienionych w tym miejscu w pakiecie SDK i umożliwić wyświetlanie intencji w aplikacjach błyskawicznych.

3.16. Parowanie urządzenia towarzyszącego

Android zapewnia obsługę parowania urządzeń towarzyszących, aby efektywniej zarządzać powiązaniem z urządzeniami towarzyszącymi. Udostępnia też interfejs API CompanionDeviceManager, dzięki któremu aplikacje mają dostęp do tej funkcji.

Jeśli implementacje urządzeń obsługują funkcję parowania urządzenia towarzyszącego, to:

• [C-1-1] MUSI zadeklarować flagę funkcji FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] MUSI upewnić się, że interfejsy API w pakiecie android.companion zostały w pełni zaimplementowane.
• [C-1-3] MUSI udostępniać informacje o produktach dostępnych dla użytkownika, które umożliwiają wybór i potwierdzenie dostępności urządzenia towarzyszącego.

3.17. Aplikacje do wagi

Jeśli implementacje urządzenia zadeklarują funkcję FEATURE_CANT_SAVE_STATE, to:

• [C-1-1] MUSI mieć zainstalowaną tylko jedną aplikację, która określa działanie cantSaveState w systemie naraz. Jeśli użytkownik opuszcza taką aplikację, nie wychodząc z niej bezpośrednio (np. naciskając przycisk ekranu głównego przy opuszczaniu aktywnej aktywności w systemie, zamiast rezygnować z aktywności, gdy nie ma już aktywnych działań w systemie), implementacje urządzenia MUSZĄ mieć priorytet dla tej aplikacji w pamięci RAM, tak samo jak w przypadku innych funkcji, które powinny 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 sieci.
• [C-1-2] MUSI mieć dostęp do interfejsu użytkownika, aby wybrać aplikację, która nie będzie korzystać z mechanizmu zapisywania/przywracania danych w zwykłym stanie, gdy użytkownik uruchomi drugą aplikację zadeklarowaną za pomocą atrybutu cantSaveState.
• [C-1-3] NIE MOŻE wprowadzać innych zmian w zasadach do aplikacji, dla których określono cantSaveState, takich jak zmiana wydajności procesora czy priorytety planowania.

Jeśli implementacje na urządzeniach nie zadeklarują funkcji FEATURE_CANT_SAVE_STATE, to:

• [C-1-1] MUSI ignorować atrybut cantSaveState ustawiony przez aplikacje i NIE MOŻE zmieniać działania aplikacji na podstawie tego atrybutu.

3.18. Kontakty

Android obejmuje interfejsy API Contacts Provider, które umożliwiają aplikacjom zarządzanie informacjami kontaktowymi przechowywanymi na urządzeniu. Dane kontaktowe wprowadzane bezpośrednio na urządzeniu są zwykle synchronizowane z usługą internetową, ale MOGĄ też znajdować się tylko lokalnie na urządzeniu. Kontakty zapisane tylko na urządzeniu są nazywane kontaktami lokalnymi.

Nieprzetworzone kontakty są „powiązane z” lub „zapisane w” Account, jeśli kolumny ACCOUNT_NAME i ACCOUNT_TYPE nieprzetworzonych kontaktów odpowiadają odpowiednim polu Account.name i Account.type na tym koncie.

Domyślne konto lokalne: konto do nieprzetworzonych kontaktów, które są przechowywane tylko na urządzeniu i nie są powiązane z kontem w usłudze AccountManager, które są tworzone z wartościami null w kolumnach ACCOUNT_NAME i ACCOUNT_TYPE.

Niestandardowe konto lokalne: konto do nieprzetworzonych kontaktów, które są przechowywane tylko na urządzeniu i nie są powiązane z kontem w usłudze AccountManager, które są utworzone z co najmniej jedną niepustą wartością w kolumnach ACCOUNT_NAME i ACCOUNT_TYPE.

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE jest, aby nie tworzyć niestandardowych kont lokalnych.

Jeśli implementacje urządzeń korzystają z niestandardowego konta lokalnego:

• [C-1-1] Dane ACCOUNT_NAME niestandardowego konta lokalnego MUSZĄ zostać zwrócone do ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] Dane ACCOUNT_TYPE niestandardowego konta lokalnego MUSZĄ zostać zwrócone do ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] Nieprzetworzone kontakty wstawione przez aplikacje innych firm na domyślnym koncie lokalnym (np. przez ustawienie wartości null dla ACCOUNT_NAME i ACCOUNT_TYPE) MUSZĄ zostać wstawione do niestandardowego konta lokalnego.
• [C-1-4] Nieprzetworzone kontakty wstawione do niestandardowego konta lokalnego NIE NALEŻY usuwać podczas dodawania lub usuwania kont.
• [C-1-5] Operacje usuwania wykonane na niestandardowym koncie lokalnym MUSZĄ spowodować natychmiastowe trwałe usunięcie nieprzetworzonych kontaktów (jak gdyby parametr CALLER_IS_SYNCADAPTER miał wartość Prawda), nawet jeśli parametr CALLER\_IS\_SYNCADAPTER ma wartość Fałsz lub nie został określony.

4. Zgodność pakietów aplikacji

Implementacje urządzeń:

• [C-0-1] MUSI mieć możliwość instalowania i uruchamiania plików „.apk” Androida generowanych za pomocą narzędzia „aapt” zawartego w oficjalnym pakiecie SDK na Androida.
• Powyższe wymaganie może być trudne, dlatego ZALECANE jest użycie systemu zarządzania pakietami implementacji referencyjnej AOSP na urządzeniach.

Implementacje na urządzeniach:

• [C-0-2] MUSI obsługiwać weryfikację plików „.apk” przy użyciu schematu podpisu APK w wersji 3 , schematu podpisu APK w wersji 2 i podpisywania plików JAR.
• [C-0-3] NIE MOŻE zwiększać formatu .apk, pliku manifestu Androida, kodu bajtowego Dalvik ani RenderScriptu ani kodu bajtowego RenderScript w sposób, który uniemożliwiałby prawidłowe zainstalowanie i działanie tych plików na innych zgodnych urządzeniach.

• [C-0-4] NIE MOŻE zezwalać na aplikacje inne niż bieżący „zainstalowany użytkownik” aby pakiet mógł odinstalować aplikację bez potwierdzenia ze strony użytkownika, tak jak to opisano w pakiecie SDK z uprawnieniami DELETE_PACKAGE. Jedynymi wyjątkami są aplikacja weryfikatora pakietów systemowych obsługująca intencję PACKAGE_NEEDS_VERIFICATION i intencja ACTION_MANAGE_STORAGE aplikacji menedżera miejsca.

• [C-0-5] MUSI mieć działanie, które obsługuje intencję android.settings.MANAGE_UNKNOWN_APP_SOURCES.

• [C-0-6] NIE MOŻE instalować pakietów aplikacji z nieznanych źródeł, chyba że aplikacja, która żąda instalacji, spełnia wszystkie poniższe wymagania:

  • MUSI zadeklarować uprawnienie REQUEST_INSTALL_PACKAGES lub mieć wartość android:targetSdkVersion ustawioną na 24 lub niższą.
  • MUSI on mieć uprawnienia do instalowania aplikacji z nieznanych źródeł.

• MUSISZ zapewnić użytkownikowi zgodę na przyznanie lub unieważnienie uprawnień do instalowania aplikacji z nieznanych źródeł w danej aplikacji, lecz MOŻE zwrócić taką możliwość w trybie braku działania i zwrócić funkcję RESULT_CANCELED w przypadku domeny startActivityForResult(), jeśli implementacja urządzenia nie chce, aby użytkownicy mieli taki wybór. Jednak nawet w takich przypadkach należy poinformować użytkownika, dlaczego nie ma takiego wyboru.

• [C-0-7] Przed uruchomieniem działania w aplikacji, która przez ten sam systemowy interfejs API PackageManager.setHarmfulAppWarning oznaczono jako potencjalnie szkodliwą, MUSI wyświetlić okno z ostrzeżeniem z ciągiem ostrzeżenia dostarczonym przez systemowy interfejs API PackageManager.setHarmfulAppWarning.

• MUSI udostępniać użytkownikowi możliwość odinstalowania lub uruchomienia aplikacji w oknie dialogowym ostrzeżenia.

• [C-0-8] MUSI wdrożyć obsługę przyrostowego systemu plików, jak opisano tutaj.

• [C-0-9] MUSI obsługiwać weryfikację plików .apk przy użyciu schematu podpisu pliku APK w wersji 4.

• Jeśli implementacje urządzeń zostały już wdrożone na starszej wersji Androida i w ramach aktualizacji oprogramowania systemowego nie spełniają wymagań [C-0-8] i [C-0-9], MOGĄ zostać zwolnione z tych wymagań.

5. Zgodność multimediów

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać formaty multimedialne, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w sekcji 5.1 dla każdego kodeka zadeklarowanego przez MediaCodecList.
• [C-0-2] MUSI zadeklarować obsługę koderów i dekoderów dostępnych dla aplikacji innych firm na MediaCodecList.
• [C-0-3] MUSI prawidłowo dekodować i udostępniać aplikacjom innych firm wszystkie formaty, które potrafią zakodować. Dotyczy to wszystkich strumieni bitowych generowanych przez kodery oraz profili raportowanych w CamcorderProfile.

Implementacje na urządzeniach:

• NALEŻY dążyć do minimalnego opóźnienia kodeka. Inaczej mówiąc,
  • NIE POWINNY jest wykorzystywać ani przechowywać buforów wejściowych ani zwracanych buforów wejściowych tylko po przetworzeniu.
  • NIE NALEŻY przechowywać zdekodowanych buforów przez czas dłuższy niż określony w standardzie (np. SPS).
  • NIE NALEŻY przechowywać kodowanych buforów dłużej niż jest to wymagane przez strukturę GOP.

Wszystkie kodeki wymienione w poniższej sekcji zostały udostępnione jako implementacje oprogramowania w preferowanej implementacji na Androida w ramach projektu Android Open Source.

Google ani stowarzyszenie Open Handset Alliance nie twierdzą, że kodeki są wolne od patentów innych firm. Wszystkim, którzy zamierzają korzystać z tego kodu źródłowego w sprzęcie lub oprogramowaniu, zalecamy, aby wdrożenie tego kodu, w tym w oprogramowaniu typu open source lub „shareware”, wymagało licencji opatentowanych przez właścicieli odpowiednich patentów.

5.1. Kodeki multimediów

5.1.1 Kodowanie dźwięku

Więcej informacji znajdziesz w artykule 5.1.3. Szczegóły kodeków audio.

Jeśli implementacje urządzeń zadeklarują android.hardware.microphone, MUSZĄ one 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] 16-bitowa natywna ramka audio PCM z 16-bitową kolejnością bajtów za pomocą interfejsu API android.media.MediaCodec.

5.1.2 Dekodowanie dźwięku

Więcej informacji znajdziesz w artykule 5.1.3. Szczegóły kodeków audio.

Jeśli implementacje urządzeń deklarują obsługę funkcji android.hardware.audio.output, muszą obsługiwać dekodowanie tych formatów audio:

• [C-1-1] Profil AAC MPEG-4 (AAC LC)
• [C-1-2] Profil AAC MPEG-4 HE (AAC+)
• [C-1-3] Profil MPEG-4 HE AACv2 (ulepszony AAC+)
• [C-1-4] AAC ELD (rozszerzony format AAC z niskim opóźnieniem)
• [C-1-11] xHE-AAC (Rozszerzony profil HE AAC zgodny ze standardem ISO/IEC 23003-3 zawierający profil bazowy USAC oraz profil kontroli zakresu dynamiki ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE, w tym formaty audio o wysokiej rozdzielczości do 24 bitów, częstotliwość próbkowania 192 kHz i 8 kanałów. Pamiętaj, że to wymaganie dotyczy wyłącznie dekodowania, a urządzenie może zmniejszać i miksować w fazie odtwarzania.
• [C-1-10] Opus

Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC strumieni wielokanałowych (tj. więcej niż 2 kanałów) do PCM za pomocą domyślnego dekodera dźwięku AAC w interfejsie API android.media.MediaCodec, MUSZĄ być obsługiwane te elementy:

• [C-2-1] Dekodowanie MUSI być wykonywane bez redmiksowania (np. strumień AAC 5.0 musi być zdekodowany na 5 kanałów PCM, a strumień AAC 5.1 – na 6 kanałów PCM).
• [C-2-2] Metadane zakresu dynamicznego MUSZĄ być zgodne z definicją w sekcji „Kontrola zakresu dynamicznego (DRC)” w normie ISO/IEC 14496-3 oraz klucze DRC android.media.MediaFormat do konfigurowania działania dekodera dźwięku w zakresie dynamiki. Klucze AAC DRC zostały wprowadzone w interfejsie API 21. Są to: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_ENCODED_TARGET_LEVEL.
• [SR] Zdecydowanie ZALECANE jest, by wszystkie dekodery audio AAC spełniają wymagania opisane powyżej w zakresie C-2-1 i C-2-2.

Podczas dekodowania dźwięku USAC MPEG-D (ISO/IEC 23003-4):

• [C-3-1] Natężenie dźwięku i metadane DRC MUSZĄ być interpretowane i stosowane zgodnie z poziomem 1 profilu kontroli zakresu dynamiki 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 profilu MPEG-4 AAC, HE AAC i HE AACv2:

• MOŻE obsługiwać sterowanie głośnością i zakresem dynamicznym zgodnie z normą ISO/IEC 23003-4 Dynamic Range Control Profile.

Jeśli obsługiwany jest standard ISO/IEC 23003-4, a metadane ISO/IEC 23003-4 i ISO/IEC 14496-3 znajdują się w zdekodowanym strumieniu bitowym, to:

• Metadane ISO/IEC 23003-4 MUSZĄ mieć pierwszeństwo.

Wszystkie dekodery audio MUSZĄ obsługiwać:

• [C-6-1] 16-bitowa natywna ramka audio PCM z 16-bitową kolejnością bajtów za pomocą interfejsu API android.media.MediaCodec.

5.1.3 Szczegóły kodeków audio

Format/kodek	Szczegóły	Obsługiwane typy plików i kontenerów
Profil AAC MPEG-4 (AAC LC)	Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 8 do 48 kHz.	3GPP (.3GPP) MPEG-4 (.mp4, .m4a) Nieprzetworzony kod AAC ADTS (AAC, ADIF nie jest obsługiwany) MPEG-TS (.ts, bez możliwości przewijania, tylko dekodowanie) matroska (.mkv, tylko dekodowanie)
Profil MPEG-4 HE AAC (AAC+)	Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.	3GPP (.3GPP) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profil (rozszerzony AAC+)	Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.	3GPP (.3GPP) MPEG-4 (.mp4, .m4a)
AAC ELD (rozszerzone AAC z niskim opóźnieniem)	Obsługa treści mono/stereo ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.	3GPP (.3GPP) MPEG-4 (.mp4, .m4a)
USAC	Obsługa treści mono/stereo ze standardowymi częstotliwościami próbkowania od 7,35 do 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75–12,2 kb/s, próbkowanie przy 8 kHz	3GPP (.3GPP)
AMR-WB	9 o częstotliwości od 6,60 kb/s do 23,85 kb/s, próbkowanie przy 16 kHz, zgodnie z definicją podaną na stronie AMR-WB, adaptacyjna wiele prędkości – szerokopasmowy kodek mowy	3GPP (.3GPP)
FLAC	Zarówno w przypadku kodera, jak i dekodera: MUSZĄ być obsługiwane przynajmniej tryby mono i stereo. MUSI być obsługiwana częstotliwość próbkowania do 192 kHz. Rozdzielczość 16-bitowa i 24-bitowa MUSI być obsługiwana. 24-bitowa obsługa danych audio FLAC MUSI być dostępna w konfiguracji dźwięku zmiennoprzecinkowego.	FLAC (.flac) MPEG-4 (.mp4, .m4a, tylko dekodowanie) matroska (.mkv, tylko dekodowanie)
MP3	Stała szybkość transmisji bitów mono/Stereo 8–320 kb/s (CBR) lub zmienna szybkość transmisji bitów (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, tylko dekodowanie) matroska (.mkv, tylko dekodowanie)
MIDI	MIDI typu 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody	Wpisz 0 i 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis		Ogg (.ogg) MPEG-4 (.mp4, .m4a, tylko dekodowanie) matroska (.mkv) Webm (.webm)
PCM/WAVE	Kodek PCM MUSI obsługiwać 16-bitowy linearny PCM i 16-bitową liczbę zmiennoprzecinkową. Ekstraktor WAVE musi obsługiwać 16-, 24-bitowy i 32-bitowy linearny PCM, oraz 32-bitową transmisję zmiennoprzecinkową (zmiennoprzecinkową do limitu sprzętowego). Częstotliwość próbkowania MUSI być obsługiwana w przedziale od 8 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, 12 000, 16 000, 24 000 i 48 000 Hz. Kodowanie: obsługa treści mono i stereo z częstotliwością próbkowania 8000, 12 000, 16 000, 24 000 i 48 000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, tylko dekodowanie) matroska (.mkv) Webm (.webm)

5.1.4 Kodowanie obrazu

Więcej informacji znajdziesz w artykule 5.1.6. Szczegóły kodeków graficznych.

Implementacje na urządzeniu MUSZĄ obsługiwać kodowanie obrazów:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

Jeśli implementacje urządzeń obsługują kodowanie HEIC przez android.media.MediaCodec w przypadku multimediów MIMETYPE_IMAGE_ANDROID_HEIC, funkcje te:

• [C-1-1] MUSI udostępniać kodek HEVC z akceleracją sprzętową, który obsługuje tryb sterowania szybkością transmisji bitów BITRATE_MODE_CQ, profil HEVCProfileMainStill i rozmiar klatki 512 x 512 pikseli.

5.1.5 Dekodowanie obrazu

Więcej informacji znajdziesz w artykule 5.1.6. Szczegóły kodeków graficznych.

Implementacje na urządzeniu MUSZĄ obsługiwać dekodowanie tego kodowania obrazu:

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Nieprzetworzony

Jeśli implementacje urządzeń obsługują dekodowanie wideo HEVC: * [C-1-1] MUSI obsługiwać dekodowanie obrazu HEIF (HEIC).

Dekodery obrazów, które obsługują format o dużej głębi bitowej (co najmniej 9 bitów na kanał):

• [C-2-1] MUSI obsługiwać wyświetlanie równoważnego formatu 8-bitowego, jeśli zażąda tego aplikacja, na przykład przy użyciu konfiguracji ARGB_8888 android.graphics.Bitmap.

5.1.6 Szczegóły kodeków obrazu

Format/kodek	Szczegóły	Obsługiwane typy plików/formaty kontenerów
JPEG	Podstawowy+progresywny	JPEG (.jpg)
GIF		GIF (GIF)
PNG		PNG (.png),
BMP		BMP (.bmp),
WebP		WebP (.webp)
Nieprzetworzony		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Obraz, kolekcja obrazów, sekwencja obrazów	HEIF (.heif), HEIC (.heic)

Koder obrazu i dekodery dostępne przez interfejs API MediaCodec

• [C-1-1] MUSI obsługiwać elastyczny format kolorów YUV420 w formacie 8:8:8 (COLOR_FormatYUV420Flexible) do CodecCapabilities.

• [SR] Zdecydowanie zalecana jest obsługa formatu kolorów RGB888 w trybie powierzchni wejściowej.

• [C-1-3] MUSI obsługiwać co najmniej jeden planarny lub półpłaszczyzny format kolorów YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (odpowiednik COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (odpowiednik COLOR_FormatYUV420SemiPlanar). Zdecydowanie zalecamy stosowanie tych rozwiązań w obu tych przypadkach.

5.1.7 Kodeki wideo

• Aby zapewnić akceptowalną jakość strumieniowego przesyłania treści wideo w internecie i usług do wideokonferencji, w implementacji urządzeń WYMAGANE jest użycie sprzętowego kodeka VP8 spełniającego wymagania.

Jeśli implementacje urządzeń obejmują dekoder lub koder wideo:

• [C-1-1] Kodeki wideo MUSZĄ obsługiwać rozmiary wyjściowego i wejściowego bufora bajtowego dla największej możliwej skompresowanej i nieskompresowanej klatki zgodnie ze standardem i konfiguracją, ale nie dla ogólnych zasad.

• [C-1-2] Kodery i dekodery wideo MUSZĄ obsługiwać elastyczne formaty kolorów YUV420 8:8:8 (COLOR_FormatYUV420Flexible) do CodecCapabilities.

• [C-1-3] Kodery i dekodery wideo MUSZĄ obsługiwać co najmniej jeden planarny lub półpłaszczyzny format kolorów YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (odpowiednik COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (odpowiednik COLOR_FormatYUV420SemiPlanar). Zdecydowanie zalecamy stosowanie tych rozwiązań w obu tych przypadkach.

• [SR] Zdecydowanie ZALECANE są kodery i dekodery wideo, które obsługują co najmniej jeden zoptymalizowany sprzętowo planarny lub półplanarny format kolorów YUV420 o współczynniku proporcji 8:8:8 (YV12, NV12, NV21 lub równoważny format zoptymalizowany przez dostawcę).

• [C-1-5] Dekodery wideo, które obsługują format o dużej głębi bitowej (co najmniej 9 bitów na kanał), MUSZĄ obsługiwać format 8-bitowy, jeśli wymaga tego aplikacja. MUSI to być odzwierciedlona przez obsługę formatu kolorów YUV420 o współczynniku proporcji 8:8:8 za pomocą pola android.media.MediaCodecInfo.

Jeśli implementacje urządzeń reklamują obsługę profilu HDR w Display.HdrCapabilities:

• [C-2-1] MUSI obsługiwać analizowanie i obsługę statycznych metadanych HDR.

Jeśli implementacje urządzeń sygnalizują obsługę wewnątrzodświeżania w ramach funkcji FEATURE_IntraRefresh w klasie MediaCodecInfo.CodecCapabilities:

• [C-3-1] MUSI obsługiwać okresy odświeżania w zakresie 10–60 klatek i dokładnie działać z dokładnością do 20% skonfigurowanego okresu odświeżania.

Jeśli w aplikacji nie określono inaczej przy użyciu klucza formatu KEY_COLOR_FORMAT, implementacje dekodera wideo:

• [C-4-1] MUSI domyślnie korzystać z formatu koloru zoptymalizowanego pod kątem sprzętu, jeśli został skonfigurowany z użyciem interfejsu Surface.
• [C-4-2] MUSI mieć domyślnie ustawiony format kolorów YUV420 o współczynniku proporcji 8:8:8 zoptymalizowany pod kątem odczytu przez procesor, jeśli skonfigurowano nieużywanie danych wyjściowych z powierzchni urządzenia.

5.1.8 Lista kodeków wideo

Format/kodek	Szczegóły	Obsługiwane typy plików i kontenerów
H.263		3GPP (.3GPP) MPEG-4 (MP4) matroska (.mkv, tylko dekodowanie)
H.264 AVC	Szczegółowe informacje znajdziesz w sekcjach 5.2 i 5.3.	3GPP (.3GPP) MPEG-4 (MP4) MPEG-2 TS (.ts, brak możliwości przewijania) matroska (.mkv, tylko dekodowanie)
H.265 HEVC	Więcej informacji znajdziesz w sekcji 5.3.	MPEG-4 (MP4) matroska (.mkv, tylko dekodowanie)
MPEG-2	Profil główny	MPEG2-TS (.ts, bez możliwości przewijania) MPEG-4 (.mp4, tylko dekodowanie) matroska (.mkv, tylko dekodowanie)
MPEG-4 SP		3GPP (.3GPP) MPEG-4 (MP4) matroska (.mkv, tylko dekodowanie)
VP8	Szczegółowe informacje znajdziesz w sekcjach 5.2 i 5.3.	WebM (.webm) matroska (.mkv)
VP9	Więcej informacji znajdziesz w sekcji 5.3.	WebM (.webm) matroska (.mkv)

5.1.9. Zabezpieczenia kodeka multimediów

Implementacja na urządzeniu MUSI zapewniać zgodność z opisanymi poniżej funkcjami zabezpieczeń kodeków multimediów.

Android zapewnia obsługę OMX, wieloplatformowego interfejsu multimedialnego acceleration API, a także Codec 2.0 – niskobudżetowym interfejsem multimedialnym acceleration API.

Jeśli implementacje urządzenia obsługują multimedia:

• [C-1-1] MUSI zapewniać obsługę kodeków multimedialnych za pomocą interfejsów OMX lub Codec 2.0 API (albo obu tych interfejsów), tak jak w projekcie Android Open Source Project, i nie może wyłączać ani omijać zabezpieczeń. Nie oznacza to, że każdy kodek MUSI korzystać z interfejsu API OMX lub Codec 2.0, tylko obsługa co najmniej jednego z tych interfejsów API MUSI być dostępna, a dostępne interfejsy API MUSZĄ obejmować zabezpieczenia.
• [C-SR] Zdecydowanie ZALECANE jest włączenie obsługi interfejsu API Codec 2.0.

Jeśli implementacje urządzeń nie obsługują interfejsu API Codec 2.0:

• [C-2-1] MUSI zawierać odpowiedni kodek OMX z projektu Android Open Source (jeśli jest dostępny) dla każdego formatu i typu multimediów (kodera lub dekodera) obsługiwanego przez urządzenie.
• [C-2-2] Kodeki, których nazwy zaczynają się od „OMX.google”. MUSI opierać się na kodzie źródłowym projektu Android Open Source.
• [C-SR] Zdecydowanie ZALECANE jest działanie kodeków oprogramowania OMX w ramach procesu kodeka, który nie ma dostępu do sterowników sprzętowych innych niż narzędzia do mapowania pamięci.

Jeśli implementacje urządzeń obsługują interfejs API Codec 2.0:

• [C-3-1] MUSI zawierać odpowiedni kodek oprogramowania Codec 2.0 z Android Open Source Project (jeśli jest dostępny) dla każdego formatu multimediów i typu (kodera lub dekodera) obsługiwanego przez urządzenie.
• [C-3-2] MUSI włączać kodeki Codec 2.0 w procesie kodeka, zgodnie z projektem Android Open Source Project, aby umożliwiać węższe przyznawanie dostępu do kodeków programowych.
• [C-3-3] Kodeki, których nazwy zaczynają się od „c2.android”. MUSI opierać się 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:

• [C-1-1] MUSI zwracać prawidłowe wartości charakteru kodeka multimediów za pomocą interfejsu API MediaCodecInfo.

W szczególności:

• [C-1-2] Kodeki o nazwach zaczynających się od „OMX”. MUSI używać interfejsów OMX API i mieć nazwy zgodne z wytycznymi dotyczącymi nazw OMX IL.
• [C-1-3] Kodeki o nazwach zaczynających się od „c2”. MUSI używać interfejsu API Codec 2.0 i mieć nazwy zgodne z wytycznymi dotyczącymi nazw dla systemu Android zgodnie z wytycznymi dla Kodeka 2.0.
• [C-1-4] Kodeki o nazwach zaczynających się od „OMX.google”. lub „c2.android”. NIE MOŻE być oznaczone jako „dostawca” ani jako z akceleracją sprzętową.
• [C-1-5] Kodeki działające w ramach procesu kodeka (od dostawcy lub systemu) z dostępem do sterowników sprzętowych innych niż przydzielające pamięć i programy do mapowania NIE mogą mieć charakteru „tylko oprogramowanie”.
• [C-1-6] Kodeki, których nie ma w projekcie Android Open Source lub nieoparte na kodzie źródłowym w tym projekcie, MUSZĄ być określone jako dostawca.
• [C-1-7] Kodeki korzystające z akceleracji sprzętowej MUSZĄ być opisane jako z akceleracją sprzętową.
• [C-1-8] Nazwy kodeków NIE MOGĄ wprowadzać w błąd. Na przykład kodeki o nazwie „dekodery” MUSI obsługiwać dekodowanie oraz elementy o nazwie „kodery”. MUSI obsługiwać kodowanie. Kodeki o nazwach zawierających formaty multimediów MUSZĄ obsługiwać te formaty.

Jeśli implementacje urządzenia obsługują kodeki wideo:

• [C-2-1] Wszystkie kodeki wideo MUSZĄ publikować dane o możliwej do osiągnięcia liczbie klatek w następujących rozmiarach, jeśli są one obsługiwane przez kodek:

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	176 x 144 piks. (H263, MPEG2, MPEG4) 352 x 288 pikseli (koder MPEG4, H263, MPEG2) 320 x 180 piks. (VP8, VP8) 320 x 240 piks. (inne)	704 x 576 piks. (H263) 640 x 360 piks. (VP8, VP9) 640 x 480 piks. (koder MPEG4) 720 x 480 piks. (inne)	1408 x 1152 piks. (H263) 1280 x 720 piks. (inne)	1920 x 1080 piks. (inne niż MPEG4)	3840 x 2160 piks. (HEVC, VP9)

• [C-2-2] Kodeki wideo z akceleracją sprzętową MUSZĄ publikować informacje o punktach wydajności. Każda z tych kategorii MUSI zawierać wszystkie obsługiwane standardowe punkty wydajności (wymienione w interfejsie API PerformancePoint), chyba że są objęte innym obsługiwanym standardowym wskaźnikiem wydajności.
• Dodatkowo POWINNY jest publikować rozszerzone punkty skuteczności, jeśli umożliwiają one utrzymanie wyników filmu innego niż jeden z wymienionych poniżej standardowych wyników.

5.2. Kodowanie wideo

Jeśli implementacje urządzeń obsługują koder wideo i udostępniają go aplikacjom innych firm, to:

• W dwóch oknach przesuwanych NIE POWINNO być o ponad 15% wyższe niż szybkość transmisji bitów między interwałami w ramce (I-frame).
• Szybkość transmisji bitów NIE POWINNO przekraczać 100% w przesuwanym oknie o długości 1 sekundy.

Jeśli implementacje urządzeń obejmują osadzony wyświetlacz o przekątnej co najmniej 2,5 cala, port wyjściowy wideo lub zadeklarowanie obsługi kamery za pomocą flagi funkcji android.hardware.camera.any, funkcje te:

• [C-1-1] MUSI obsługiwać co najmniej jeden z koderów wideo VP8 lub H.264 i udostępniać go w aplikacjach innych firm.
• POWINNA obsługiwać kodery wideo VP8 i H.264 oraz udostępniać je aplikacjom innych firm.

Jeśli implementacje urządzeń obsługują kodery wideo H.264, VP8, VP9 lub HEVC i udostępniają je aplikacjom innych firm:

• [C-2-1] MUSI obsługiwać dynamicznie konfigurowane szybkości transmisji bitów.
• Koder powinien obsługiwać zmienne liczby klatek, przy czym koder wideo POWINNY określać chwilowy czas trwania klatek na podstawie sygnatur czasowych buforów wejściowych i przydzielać zasobnik na podstawie czasu trwania klatek.

Jeśli implementacje urządzeń obsługują koder wideo MPEG-4 SP i udostępniają go aplikacjom innych firm, muszą one:

• POWINNA obsługiwać dynamicznie konfigurowane szybkości transmisji bitów dla obsługiwanego kodera.

Jeśli implementacje urządzeń oferują kodery wideo lub graficzne z akceleracją sprzętową i obsługują co najmniej 1 podłączoną lub podłączaną kamerę sprzętową dostępną za pomocą interfejsów API android.camera:

• [C-4-1] Wszystkie kodery wideo i obrazów z akceleracją sprzętową MUSZĄ obsługiwać kodowanie klatek z kamer sprzętowych.
• POWINNA obsługiwać kodowanie klatek z kamer sprzętowych we wszystkich koderach wideo i koderów graficznych.

5.2.1 H.263

Jeśli implementacje urządzeń obsługują kodery H.263 i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI obsługiwać profil podstawowy poziomu 45.
• POWINNA obsługiwać dynamicznie konfigurowane szybkości transmisji bitów dla obsługiwanego kodera.

5.2.2 H.264

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

• [C-1-1] MUSI obsługiwać profil podstawowy poziomu 3. Jednak obsługa ASO (Arbitrary Slice Ordering), FMO (elastyczne porządkowanie makr) i RS (nadmiarowe wycinki) jest OPCJONALNA. Co więcej, w celu zachowania zgodności z innymi urządzeniami z Androidem ZALECANA jest opcja używania przez kodery do profilu Baseline profilu ASO, FMO i RS.
• [C-1-2] MUSI obsługiwać profile kodowania wideo w jakości SD (standardowej rozdzielczości) z poniższej tabeli.
• POWINNY jest obsługiwać profil główny na poziomie 4.
• POWINNA obsługiwać profile kodowania wideo HD (High Definition) zgodnie z informacjami w tej tabeli.

Jeśli implementacje urządzeń zgłaszają obsługę kodowania H.264 w przypadku filmów w rozdzielczości 720p lub 1080p za pomocą interfejsów API multimediów:

• [C-2-1] MUSI obsługiwać profile kodujące z poniższej tabeli.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 240 piks.	720 x 480 piks.	1280 x 720 piks.	1920 x 1080 piks.
Liczba klatek w filmie	20 kl./s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	384 Kb/s	2 Mb/s	4 Mb/s	10 Mb/s

5.2.3 VP8

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

• [C-1-1] MUSI obsługiwać profile kodowania wideo SD.
• POWINNA obsługiwać poniższe profile kodowania wideo HD (High Definition).
• [C-1-2] MUSI obsługiwać zapisywanie plików Matroska WebM.
• POWINIEN dostarczyć sprzętowy kodek VP8, który spełnia wymagania dotyczące sprzętowego kodowania RTC w projektach WebM, aby zapewnić akceptowalną jakość strumieniowego przesyłania danych wideo w internecie i usług rozmów wideo.

Jeśli implementacje urządzeń zgłaszają obsługę kodowania VP8 w przypadku filmów w rozdzielczości 720p lub 1080p za pomocą interfejsów API multimediów:

• [C-2-1] MUSI obsługiwać profile kodujące z poniższej tabeli.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 180 piks.	640 x 360 piks.	1280 x 720 piks.	1920 x 1080 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	4 Mb/s	10 Mb/s

5.2.4 VP9

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

• [C-1-2] MUSI obsługiwać profil 0 na poziomie 3.
• [C-1-1] MUSI obsługiwać zapisywanie plików Matroska WebM.
• [C-1-3] MUSI generować dane CodecPrivate.
• KONIECZNIE jest obsługa profili dekodowania HD zgodnie z informacjami w poniższej tabeli.
• Jeśli używany jest koder sprzętowy, Zdecydowanie ZALECANE jest korzystanie z profili dekodowania HD zgodnie z informacjami w poniższej tabeli.

	SD	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	720 x 480 piks.	1280 x 720 piks.	1920 x 1080 piks.	3840 x 2160 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

Jeśli implementacje urządzeń twierdzą, że obsługują Profil 2 lub Profil 3 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 na poziomie 3.
• POWINNA obsługiwać profile kodowania HD zgodnie z informacjami w tej tabeli.
• Jeśli dostępny jest koder sprzętowy, ZDECYDOWANIE zaleca się korzystanie z profili kodowania HD zgodnie z informacjami w poniższej tabeli.

	SD	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	720 x 480 piks.	1280 x 720 piks.	1920 x 1080 piks.	3840 x 2160 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

5.3. Dekodowanie wideo

Jeśli implementacje urządzeń obsługują kodeki VP8, VP9, H.264 lub H.265:

• [C-1-1] MUSI obsługiwać dynamiczne przełączanie rozdzielczości wideo i przełączenia liczby klatek za pomocą standardowych interfejsów API Androida w tym samym strumieniu w przypadku wszystkich kodeków VP8, VP9, H.264 i H.265 w czasie rzeczywistym z maksymalną rozdzielczością obsługiwaną przez każdy kodek na urządzeniu.

5.3.1 MPEG-2

Jeśli implementacje urządzeń obsługują dekodery MPEG-2:

• [C-1-1] MUSI obsługiwać wysoki poziom profilu głównego.

5.3.2 H.263

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

• [C-1-1] MUSI obsługiwać profil podstawowy na poziomie 30 i 45.

5.3.3 MPEG-4

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

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

5.3.4 H.264

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

• [C-1-1] MUSI obsługiwać profil główny na poziomie 3.1 i profil podstawowy. Obsługa ASO (Arbitrary Slice Ordering), FMO (elastyczne porządkowanie makr) i RS (nadmiarowe wycinki) jest OPCJONALNA.
• [C-1-2] MUSI dekodować filmy za pomocą profili SD (standardowej rozdzielczości) wymienionych w tabeli poniżej i zakodować je przy użyciu profilu podstawowego i profilu głównego na poziomie 3.1 (w tym 720p30).
• MUSI dekodować filmy w profilach HD (High Definition) zgodnie z informacjami w poniższej tabeli.

Jeśli wysokość zgłaszana przez metodę Display.getSupportedModes() jest równa lub większa od rozdzielczości wideo, implementacje urządzeń:

• [C-2-1] MUSI obsługiwać profile dekodowania wideo HD 720p z tabeli poniżej.
• [C-2-2] MUSI obsługiwać profile dekodowania wideo HD 1080p z tabeli poniżej.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 240 piks.	720 x 480 piks.	1280 x 720 piks.	1920 x 1080 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	60 kl./s	30 kl./s (60 kl./s, ^telewizja)
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

5.3.5 H.265 (HEVC)

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

• [C-1-1] MUSI obsługiwać profil główny poziomu 3 i profile dekodowania wideo SD zgodnie z poniższą tabelą.
• KONIECZNIE jest obsługa profili dekodowania HD zgodnie z informacjami w poniższej tabeli.
• [C-1-2] W przypadku dekodera sprzętowego MUSI obsługiwać profile dekodowania HD zgodnie z informacjami w poniższej tabeli.

Jeśli wysokość zgłaszana przez metodę Display.getSupportedModes() jest równa rozdzielczości filmu lub od niej większa, to:

• [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden dekodowanie H.265 lub VP9 w profilach 720, 1080 i UHD.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	352 x 288 piks.	720 x 480 piks.	1280 x 720 piks.	1920 x 1080 piks.	3840 x 2160 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 klatek/s	30/60 kl./s (60 kl./s, ^telewizja z dekodowaniem sprzętowym H.265)	60 kl./s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

Jeśli implementacje urządzenia twierdzą, że obsługują profil HDR za pomocą interfejsów Media API:

• [C-3-1] Implementacje urządzeń MUSZĄ akceptować wymagane metadane HDR z aplikacji oraz obsługiwać wyodrębnianie i wyświetlanie wymaganych metadanych HDR z strumienia bitowego lub kontenera.
• [C-3-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR na ekranie urządzenia lub w standardowym porcie wyjściowym wideo (np. HDMI).

5.3.6 VP8

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

• [C-1-1] MUSI obsługiwać profile dekodowania SD z poniższej tabeli.
• NALEŻY użyć sprzętowego kodeka VP8, który spełnia wymagania.
• MUSI obsługiwać profile dekodowania HD z poniższej tabeli.

Jeśli wysokość zgłoszona przez metodę Display.getSupportedModes() jest równa lub większa od rozdzielczości wideo, to:

• [C-2-1] Implementacje na urządzeniach MUSZĄ obsługiwać profile 720p z tabeli poniżej.
• [C-2-2] Implementacje urządzeń MUSZĄ obsługiwać profile 1080p z poniższej tabeli.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p
Rozdzielczość wideo	320 x 180 piks.	640 x 360 piks.	1280 x 720 piks.	1920 x 1080 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 kl./s (60 kl./s, ^telewizja)	30 (60 kl./s, ^telewizja)
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

5.3.7 VP9

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

• [C-1-1] MUSI obsługiwać profile dekodowania wideo SD zgodnie z informacjami w tej tabeli.
• KONIECZNIE jest obsługa profili dekodowania HD zgodnie z informacjami w poniższej tabeli.

Jeśli implementacje urządzeń obsługują kodek VP9 i dekoder sprzętowy:

• [C-2-1] MUSI obsługiwać profile dekodowania HD zgodnie z informacjami w poniższej tabeli.

Jeśli wysokość zgłaszana przez metodę Display.getSupportedModes() jest równa rozdzielczości filmu lub od niej większa, to:

• [C-3-1] Implementacje urządzenia MUSZĄ obsługiwać co najmniej 1 dekodowanie VP9 lub H.265 z profili 720, 1080 i UHD.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	320 x 180 piks.	640 x 360 piks.	1280 x 720 piks.	1920 x 1080 piks.	3840 x 2160 piks.
Liczba klatek w filmie	30 klatek/s	30 klatek/s	30 klatek/s	30 kl./s (60 kl./s, ^telewizja z sprzętowym dekodowaniem VP9)	60 kl./s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

Jeśli implementacje urządzeń twierdzą, że obsługują media VP9Profile2 lub VP9Profile3 za pomocą interfejsów API multimediów 'CodecProfileLevel':

• Obsługa formatu 12-bitowego jest OPCJONALNA.

Jeśli implementacje urządzenia twierdzą, że obsługują profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) za pomocą interfejsów API multimediów:

• [C-4-1] Implementacje urządzenia MUSZĄ akceptować wymagane metadane HDR (KEY_HDR_STATIC_INFO w przypadku wszystkich profili HDR oraz KEY_HDR10_PLUS_INFO' dla profili HDR10Plus) z aplikacji. MUSZĄ też wyodrębniać i wyświetlać wymagane metadane HDR ze strumienia bitowego lub kontenera.
• [C-4-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR na ekranie urządzenia lub w standardowym porcie wyjściowym wideo (np. HDMI).

5.3.8 Dolby Vision

Jeśli implementacje urządzeń zadeklarują obsługę dekodera Dolby Vision w HDR_TYPE_DOLBY_VISION , będą to:

• [C-1-1] MUSI zawierać moduł wyodrębniający z obsługą Dolby Vision.
• [C-1-2] MUSI prawidłowo wyświetlać treści Dolby Vision na ekranie urządzenia lub w standardowym porcie wyjściowym wideo (np. HDMI).
• [C-1-3] MUSI ustawić indeks ścieżki zgodnych wstecznie warstw podstawowych (jeśli występują) na taki sam jak indeks ścieżki połączonej warstwy Dolby Vision.

5.3.9 AV1

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

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

5.4. Nagrywanie dźwięku

Chociaż od wersji Androida 4.3 niektóre z wymagań opisanych w tej sekcji są oznaczone jako POWINNY, definicja zgodności w przyszłych wersjach zostanie zmieniona na MUSZĄ. Zdecydowanie ZALECANE są zarówno istniejące, jak i nowe urządzenia z Androidem, które spełniają wymienione poniżej wymagania. W przeciwnym razie nie będą mogły uzyskać zgodności z Androidem po uaktualnieniu do nowej wersji.

5.4.1 Przechwycony dźwięk i informacje z mikrofonu

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

• [C-1-1] MUSI umożliwiać przechwytywanie nieprzetworzonych treści audio o następujących cechach:

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

• POWINNA przechwytywać nieprzetworzone treści audio o tych cechach:

  • Format: liniowy PCM, 16- i 24-bitowy
  • Częstotliwość próbkowania: 8000, 11025, 16 000, 22 050, 24 000, 32 000, 44 100, 48 000 Hz
  • Kanały: tyle kanałów, ile kanałów jest w urządzeniu.

• [C-1-2] MUSI przechwytywać z większą częstotliwością próbkowania bez próbkowania w górę.

• [C-1-3] MUSI zawierać odpowiedni filtr antyaliasing, jeśli podane powyżej częstotliwości próbkowania są odczytywane przy użyciu próbkowania w dół.

• NALEŻY zezwolić na przechwytywanie nieprzetworzonych treści audio w jakości radia AM i DVD, co oznacza następujące cechy:

  • Format: linearny PCM, 16-bitowy
  • Częstotliwość próbkowania: 22 050, 48 000 Hz
  • Kanały: stereo
  • [C-1-4] MUSI spełniać wymagania interfejsu API MicrophoneInfo i odpowiednio podawać informacje o mikrofonach dostępnych na urządzeniu dostępnych dla aplikacji innych firm przez interfejs API AudioManager.getMicrophones() oraz o aktywnych mikrofonach, które są dostępne dla aplikacji innych firm przez interfejsy API AudioRecord.getActiveMicrophones() i MediaRecorder.getActiveMicrophones(). Jeśli implementacje urządzeń umożliwiają przechwytywanie nieprzetworzonych treści audio za pomocą radia AM i DVD w jakości:

• [C-2-1] MUSI przechwytywać bez próbkowania w górę przy współczynniku wyższego niż 16 000:22050 lub 44100:48 000.

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

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

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

• [C-1-1] MUSI przechwytywać źródło dźwięku android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION z jedną z częstotliwości próbkowania – 44 100 lub 48 000.
• [C-1-2] Podczas nagrywania strumienia audio ze źródła dźwięku AudioSource.VOICE_RECOGNITION MUSISZ domyślnie wyłączyć przetwarzanie dźwięku z redukcją szumów.
• [C-1-3] Domyślnie MUSI wyłączyć automatyczną kontrolę wzmocnienia podczas nagrywania strumienia audio ze źródła dźwięku AudioSource.VOICE_RECOGNITION.
• NAGRYWAJ strumień audio rozpoznawania głosu o względnie płaskiej amplitudzie względem charakterystyki częstotliwości: w szczególności ±3 dB, od 100 Hz do 4000 Hz.
• TRZEBA nagrywać strumienia audio rozpoznawania głosu z ustawioną czułością sygnału wejściowego, tak aby źródło SPL (90 dB) o częstotliwości 1000 Hz generowało wartość RMS 2500 dla 16-bitowych próbek.
• MUSI nagrywać strumień audio rozpoznawania głosu, tak aby poziomy amplitudy PCM liniowo śledziły SPL na poziomie co najmniej 30 dB od -18 dB do +12 dB do 90 dB SPL przy mikrofonie.
• NALEŻY nagrywać strumień audio rozpoznawania głosu z całkowitym zniekształceniem harmonicznym (THD) poniżej 1% dla częstotliwości 1 kHz przy 90 dB poziomu wejściowego SPL mikrofonu.

Jeśli implementacje urządzeń zadeklarują android.hardware.microphone i technologie wyciszania szumów (redukcji szumów) dostosowanych do rozpoznawania mowy, te funkcje:

• [C-2-1] MUSI umożliwiać sterowanie tym efektem dźwiękowym za pomocą interfejsu API android.media.audiofx.NoiseSuppressor.
• [C-2-2] Każda implementacja technologii eliminowania szumów musi jednoznacznie identyfikować się w polu AudioEffect.Descriptor.uuid.

5.4.3 Zrób zdjęcie, aby zmienić trasę odtwarzania

Klasa android.media.MediaRecorder.AudioSource zawiera źródło dźwięku REMOTE_SUBMIX.

Jeśli implementacje urządzeń zadeklarują zarówno android.hardware.audio.output, jak i android.hardware.microphone:

• [C-1-1] MUSI prawidłowo zaimplementować źródło dźwięku REMOTE_SUBMIX, aby aplikacja, która nagrywa za pomocą interfejsu API android.media.AudioRecord, przechwytywała miks wszystkich strumieni audio z wyjątkiem tych:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4 Reduktor echa akustycznego

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

• NALEŻY wdrożyć technologię akustycznego anulowania echa (AEC) dostosowaną do komunikacji głosowej i zastosować do ścieżki przechwytywania podczas nagrywania z użyciem AudioSource.VOICE_COMMUNICATION

Jeśli implementacje urządzeń udostępniają akustyczną redukcję echa, która jest wstawiana w ścieżce przechwytywania dźwięku po wybraniu opcji AudioSource.VOICE_COMMUNICATION:

• [C-SR] jest STRONGLY_RECOMMENDED do zadeklarowania tego za pomocą metody AcousticEchoCanceler interfejsu API AcousticEchoCanceler.isAvailable()
• [C-SR] jest STRONGLY_RECOMMENDED wymagana, aby można było sterować tym efektem dźwiękowym za pomocą interfejsu API AcousticEchoCanceler.
• [C-SR] umożliwia jednoznaczne zidentyfikowanie każdej implementacji technologii AEC za pomocą pola AudioEffect.Descriptor.uuid.

5.4.5 Jednoczesne przechwytywanie

Jeśli implementacje urządzeń z zadeklarowaną wartością android.hardware.microphone MUSZĄ włączyć przechwytywanie równoległe,zgodnie z opisem w tym dokumencie. Więcej szczegółów:

• [C-1-1] MUSI zezwalać usłudze ułatwień dostępu na równoczesny dostęp do mikrofonu przechwytujący za pomocą AudioSource.VOICE_RECOGNITION i co najmniej jednej aplikacji przechwytującej za pomocą dowolnego AudioSource.
• [C-1-2] MUSI zezwalać na jednoczesne korzystanie z mikrofonu wstępnie zainstalowanej aplikacji, która pełni funkcję Asystenta, oraz co najmniej 1 aplikacji przechwytującej za pomocą dowolnego obiektu AudioSource oprócz AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER.
• [C-1-3] MUSI wyciszać przechwytywanie dźwięku w przypadku innej aplikacji oprócz usługi ułatwień dostępu, gdy aplikacja rejestruje za pomocą AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER. Jednak gdy aplikacja rejestruje za pomocą AudioSource.VOICE_COMMUNICATION, inna aplikacja może zarejestrować połączenie głosowe, jeśli jest to aplikacja uprzywilejowana (wstępnie zainstalowana) z uprawnieniami CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Jeśli co najmniej 2 aplikacje nagrywają jednocześnie i żadna z nich nie ma interfejsu użytkownika, to ta, która zaczęła rejestrować dźwięk jako ostatnia, odbiera dźwięk.

5.4.6 Poziomy wzmocnienia mikrofonu

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

• MUSZĄ one zachowywać mniej więcej płaską amplitudę względem częstotliwości w średnim zakresie częstotliwości: ±3 dB od 100 Hz do 4000 Hz dla każdego mikrofonu użytego do nagrywania źródła dźwięku rozpoznawania głosu.
• NALEŻY ustawić czułość sygnału wejściowego dźwięku w taki sposób, aby źródło sygnału sinusoidalnego o częstotliwości 1000 Hz odtwarzane przy poziomie ciśnienia akustycznego 90 dB (SPL) generowało odpowiedź z RMS 2500 dla 16-bitowych próbek (lub -22,35 dB w pełnej skali -22,35 dB w przypadku każdego źródła dźwięku/podwójnej precyzji rozpoznawania użytego źródła).
• Zdecydowanie zalecamy, aby dźwięk [C-SR] miał poziom amplitudy w niskim zakresie częstotliwości: konkretnie od ±20 dB od 5 Hz do 100 Hz w porównaniu ze średnim zakresem częstotliwości dla każdego mikrofonu użytego do nagrywania źródła dźwięku rozpoznawania głosu.
• Zdecydowanie zalecamy, aby dźwięk [C-SR] miał poziom amplitudy w zakresie wysokich częstotliwości: od ±30 dB od 4000 Hz do 22 kHz w porównaniu ze średnim zakresem częstotliwości dla każdego mikrofonu użytego do nagrywania źródła dźwięku rozpoznawania głosu.

5.5. Odtwarzanie dźwięku

Android zapewnia możliwość zezwalania aplikacjom na odtwarzanie dźwięku przez wyjście audio peryferyjnego urządzenia peryferyjnego zgodnie z definicją w sekcji 7.8.2.

5.5.1 Odtwarzanie surowego dźwięku

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

• [C-1-1] MUSI umożliwiać odtwarzanie nieprzetworzonych treści audio o następujących cechach:

  • Formaty źródłowe: linearny PCM, 16-bitowy, 8-bitowy, liczba zmiennoprzecinkowa
  • Kanały: mono, stereo, prawidłowe konfiguracje wielokanałowe, maksymalnie 8 kanałów
  • Częstotliwość próbkowania (w Hz):
    • 8000, 11025, 16000, 22050, 32000, 44100, 48000 w konfiguracjach kanałów wymienionych powyżej
    • 96 000 w mono i stereo

• POWINNY jest zezwalać na odtwarzanie nieprzetworzonej treści audio o następujących cechach:

  • Częstotliwość próbkowania: 24 000, 48 000

5.5.2 Efekty audio

Android udostępnia interfejs API do efektów dźwiękowych do implementacji na urządzeniach.

Jeśli implementacje urządzenia zadeklarują funkcję android.hardware.audio.output:

• [C-1-1] MUSI obsługiwać implementacje EFFECT_TYPE_EQUALIZER i EFFECT_TYPE_LOUDNESS_ENHANCER sterowane za pomocą podklasy 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 sterowaną przez podklasę AudioEffect DynamicsProcessing.
• POWINNA 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ą klas podrzędnych BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.AudioEffect
• [C-SR] Zdecydowanie ZALECANE jest obsługa efektów w formatach zmiennoprzecinkowych i wielokanałowych.

5.5.3 Wyjściowa głośność dźwięku

Implementacje na urządzeniach motoryzacyjnych:

• POWINNY jest zezwalać na dostosowanie głośności dźwięku oddzielnie dla każdego strumienia audio z użyciem typu lub użycia treści zdefiniowanego w Atrybutach audio oraz użycia audio w samochodzie (zgodnie z definicją w zasadzie android.car.CarAudioManager).

5.6. Opóźnienie dźwięku

Opóźnienie dźwięku to czas, w którym sygnał audio przechodzi przez system. Wiele klas aplikacji korzysta z krótkich czasów oczekiwania, aby uzyskać efekty dźwiękowe w czasie rzeczywistym.

Na potrzeby tej sekcji należy stosować następujące definicje:

• opóźnienia wyjścia. Odstęp czasu między momentem, w którym aplikacja zapisuje ramkę danych kodowanych w PCM, a odebraniem odpowiedniego dźwięku w otoczeniu za pomocą przetwornika lub sygnału urządzenia na urządzeniu i możliwości obserwacji na zewnątrz.
• opóźnienia „na zimno”. Opóźnienie wyjścia dla pierwszej klatki, gdy system wyjściowy audio był bezczynny i wyłączony przed żądaniem.
• ciągły czas oczekiwania na sygnał wyjściowy. Opóźnienie wyjściowe kolejnych klatek po odtworzeniu dźwięku na urządzeniu.
• opóźnienia wejściowe. Odstęp czasu między momentem, w którym otoczenie trafia do urządzenia z przetwornikiem lub sygnałem na urządzeniu, a odstępem między momentem, w którym aplikacja odczytuje odpowiednią ramkę danych kodowanych w PCM.
• utraconych danych wejściowych. Początkowa część sygnału wejściowego, który jest bezużyteczny lub niedostępny.
• opóźnienia „zimnego sygnału wejściowego”. Suma utraconego czasu sygnału wejściowego i opóźnienia wejściowego dla pierwszej klatki, gdy system wejścia audio był bezczynny i wyłączony przed żądaniem.
• ciągłe opóźnienie sygnału wejściowego. Opóźnienie sygnału wejściowego dla kolejnych klatek, gdy urządzenie rejestruje dźwięk.
• zakłócenia przy zimnie. Zmienność między osobnymi pomiarami wartości czasu oczekiwania na zimne wyjście.
• zakłócenia przy zimnie. Zmienność między osobnymi pomiarami wartości czasu oczekiwania na zimno.
• ciągłe opóźnienie w obie strony. Suma ciągłych opóźnień sygnału wejściowego i ciągłego czasu oczekiwania na dane wyjściowe plus 1 okres buforowania. Okres buforowania daje aplikacji czas na przetworzenie sygnału i czas na zniwelowanie różnicy fazowej między strumieniami wejściowymi i wyjściowymi.
• Interfejs API kolejki buforowej OpenSL ES PCM. Zestaw interfejsów API OpenSL ES związanych z PCM w Androidzie NDK.
• Natywny interfejs API audio audio Zestaw interfejsów API AAudio w systemie Android NDK.
• Sygnatura czasowa. Para złożona z względnego położenia klatki w strumieniu i szacunkowego czasu, w którym dana klatka pojawia się w potoku przetwarzania dźwięku lub go opuszcza w powiązanym punkcie końcowym. Zobacz też AudioTimestamp.
• glitch. Tymczasowa przerwa w działaniu lub nieprawidłowa wartość próbki w sygnale audio, zwykle spowodowana zaniżeniem bufora wyjściowego, przepełnieniem bufora na potrzeby wejścia lub jakimkolwiek innym źródłem szumów cyfrowych lub analogowych.

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

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

Jeśli implementacje urządzeń deklarują użycie funkcji android.hardware.audio.output, Zdecydowanie ZALECANE jest spełnienie lub przekroczenie tych wymagań:

• [C-SR] Opóźnienie podczas wczytywania „na zimno” nie dłuższe niż 100 milisekund. Dotychczasowe i nowe urządzenia, na których działa ta wersja Androida, Zdecydowanie Zdecydowanie Zdecydowanie Zdecydowanie Zdecydowanie Zdecydowanie zalecamy już teraz spełnić te wymagania; W przyszłej wersji platformy w 2021 roku będziemy wymagać, aby opóźnienie sygnału wyjściowego „na zimno” nie przekraczało 200 ms.
• [C-SR] Ciągłe opóźnienie sygnału wyjściowego wynoszące maksymalnie 45 milisekund.
• [C-SR] Zminimalizuj zakłócenia na zimno.
• [C-SR] Sygnatura czasowa wyjścia zwracana przez funkcję AudioTrack.getTimestamp i AAudioStream_getTimestamp ma dokładność z dokładnością do +/- 1 ms.

Jeśli implementacje urządzeń spełniają powyższe wymagania, po pierwszej kalibracji i korzystanie z kolejki bufora OpenSL ES PCM i natywnych interfejsów API audio AAudio, pod kątem ciągłego opóźnienia wyjściowego i opóźnienia „na zimno” na co najmniej jednym obsługiwanym urządzeniu wyjściowym audio, są to:

• [C-SR] Zdecydowanie ZALECANE jest przesyłanie dźwięku z małym opóźnieniem przez zadeklarowanie flagi funkcji android.hardware.audio.low_latency.
• [C-SR] Zdecydowanie ZALECANE jest spełnienie wymagań dotyczących dźwięku z małym opóźnieniem przez interfejs AAudio API.
• [C-SR] Zdecydowanie zalecamy, aby w przypadku strumieni, które zwracają wartość AAUDIO_PERFORMANCE_MODE_LOW_LATENCY z AAudioStream_getPerformanceMode(), wartość zwrócona przez AAudioStream_getFramesPerBurst() jest mniejsza lub równa wartości zwróconej przez android.media.AudioManager.getProperty(String) dla klucza usługi AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Jeśli implementacje urządzeń nie spełniają wymagań dotyczących dźwięku z małym opóźnieniem w kolejce bufora OpenSL ES PCM i natywnych interfejsach API audio AAudio:

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

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

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

Jeśli implementacje urządzeń obejmują android.hardware.microphone, Zdecydowanie ZALECANE są, aby spełniały one te wymagania dotyczące wejściowego dźwięku:

• [C-SR] Opóźnienie reakcji „na zimno” nie większe niż 100 milisekund. Dotychczasowe i nowe urządzenia, na których działa ta wersja Androida, Zdecydowanie Zdecydowanie Zdecydowanie Zdecydowanie Zdecydowanie Zdecydowanie zalecamy już teraz spełnić te wymagania; W przyszłej wersji platformy w 2021 roku będziemy wymagać, aby opóźnienia sygnału wejściowego „na zimno” nie przekraczały 200 ms.
• [C-SR] Ciągłe opóźnienie sygnału wejściowego wynoszące maksymalnie 30 milisekund.
• [C-SR] Ciągłe opóźnienie w obie strony wynoszące maksymalnie 50 milisekund.
• [C-SR] Minimalizuj zakłócenia sygnału wejściowego „na zimno”.
• [C-SR] Ogranicz błąd w wejściowych sygnaturach czasowych zwracanych przez funkcję AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/- 1 ms.

5.7. Protokoły sieciowe

Implementacje urządzeń MUSZĄ obsługiwać protokoły sieci multimedialnej do odtwarzania dźwięku i obrazu zgodnie z opisem w dokumentacji pakietu Android SDK.

Jeśli implementacje urządzeń obejmują dekoder dźwięku lub wideo:

• [C-1-1] MUSI obsługiwać wszystkie wymagane kodeki i formaty kontenerów opisane w sekcji 5.1 w standardzie HTTP(S).

• [C-1-2] MUSI obsługiwać formaty segmentów multimediów podane w tabeli „Media Segment Formats” (Formaty segmentu multimediów poniżej) w przypadku protokołu transmisji na żywo przez HTTP w wersji 7 (w wersji roboczej).

• [C-1-3] MUSI obsługiwać poniższy profil audio-wideo RTP i powiązane kodeki z tabeli RTSP poniżej. Informacje o wyjątkach znajdziesz w przypisach w sekcji 5.1.

Formaty segmentów multimediów

Formaty segmentów	Pliki referencyjne	Wymagana obsługa kodeka
Zapis strumienia MPEG-2	ISO 13818	Kodeki wideo: H264 AVC MPEG-4 SP MPEG-2 Szczegółowe informacje na temat H264 AVC i MPEG2-4 SP znajdziesz w sekcji 5.1.3. i MPEG-2. Kodeki audio: AAC Więcej informacji o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
AAC z kadrowaniem 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	Pliki referencyjne	Wymagana obsługa kodeka
H264 AVC	RFC 6184	Szczegółowe informacje o AVC H264 znajdziesz w sekcji 5.1.3.
MP4A-LATM	RFC 6416	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1
H263–1998	RFC 3551 RFC 4629 RFC 2190	Szczegółowe informacje o H263 znajdziesz w sekcji 5.1.3.
H263–2000	RFC 4629	Szczegółowe informacje o H263 znajdziesz w sekcji 5.1.3.
AMR	RFC 4867	Szczegółowe informacje o AMR-NB znajdziesz w sekcji 5.1.1.
AMR-WB	RFC 4867	Szczegółowe informacje o AMR-WB znajdziesz w sekcji 5.1.1.
MP4V-ES	RFC 6416	Szczegółowe informacje o MPEG-4 SP znajdziesz w sekcji 5.1.3
mpeg4-generic,	RFC 3640	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1
Plik MP2T	RFC 2250	Więcej informacji znajdziesz w sekcji Strumień transportu MPEG-2 pod nagłówkiem Transmisja na żywo przez HTTP

5.8. Bezpieczne nośniki

Jeśli implementacje urządzeń obsługują bezpieczne wyjście wideo i obsługują bezpieczne platformy:

• [C-1-1] MUSI zadeklarować obsługę interfejsu Display.FLAG_SECURE.

Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE i protokołu wyświetlania bezprzewodowego,:

• [C-2-1] W przypadku ekranów połączonych protokołami bezprzewodowymi, np. Miracast, połączenie MUSI zabezpieczyć link silnym kryptograficznie mechanizmem, np. HDCP 2.x lub nowszym.

Jeśli implementacje urządzeń deklarują obsługę interfejsu Display.FLAG_SECURE i przewodowego wyświetlacza zewnętrznego,:

• [C-3-1] MUSI obsługiwać standard HDCP 1.2 lub nowszy w przypadku wszystkich wyświetlaczy zewnętrznych podłączonych do dostępnego dla użytkownika portu przewodowego.

5.9. Interfejs MIDI (Musical Instrument Digital Interface)

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 we wszystkich transportach sprzętowych obsługujących MIDI, dla których zapewniają ogólne łącza inne niż MIDI, tam, gdzie takie dane:

  • Tryb hosta USB, sekcja 7.7
  • MIDI przez Bluetooth LE w głównej roli, sekcja 7.4.3

• [C-1-2] MUSI obsługiwać transport oprogramowania MIDI między aplikacjami (urządzenia wirtualne MIDI)

• [C-1-3] MUSI zawierać libamidi.so (natywna obsługa MIDI).

• POWINNA OBSŁUGA MIDI przez tryb urządzenia peryferyjnego USB (sekcja 7.7)

5.10. Profesjonalne treści audio

Jeśli implementacje urządzeń zgłaszają obsługę funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager, to:

• [C-1-1] MUSI zgłosić wsparcie funkcji android.hardware.audio.low_latency.
• [C-1-2] MUSI mieć ciągłe opóźnienie dźwięku w obie strony określone w sekcji 5.6 Opóźnienia dźwięku, MUSI wynosić nie więcej niż 20 milisekund oraz 10 milisekund w przypadku co najmniej jednej obsługiwanej ścieżki.
• [C-1-3] MUSI zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
• [C-1-4] MUSI zgłosić wsparcie funkcji android.software.midi.
• [C-1-5] MUSI spełniać wymagania dotyczące czasów oczekiwania i dźwięku USB, wykorzystując zarówno interfejs API kolejki buforowej PCM OpenSL ES, jak i co najmniej 1 ścieżkę natywnego audio AAudio.
• [SR] Zdecydowanie ZALECANE jest spełnienie wymagań dotyczących opóźnień i dźwięku USB przy użyciu interfejsu API AAudio natywnego audio w ścieżce MMAP.
• [C-1-6] Opóźnienie urządzenia „na zimno” musi wynosić maksymalnie 200 milisekund.
• [C-1-7] Opóźnienie reakcji „na zimno” nie może przekraczać 200 milisekund.
• [SR] Zdecydowanie ZALECANE jest zapewnienie stałego poziomu wydajności procesora przy włączonym dźwięku, a jego obciążenie jest zmienną. Przeprowadź test, korzystając z identyfikatora zatwierdzenia SynthMark w wersji aplikacji na Androida 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark korzysta z syntezatora programowego działającego na symulowanej platformie audio, który mierzy wydajność systemu. Aplikację SynthMark należy uruchomić przy użyciu opcji „Automatyczny test” i uzyskać następujące wyniki:
  • voicemark.90 >= 32 głosy
  • czas oczekiwania.fixed.little <= 15 ms
  • opóźnieniemark.dynamic.little <= 50 ms

Wyjaśnienie wartości porównawczych znajdziesz w dokumentacji SynthMark.

• POWINNO zminimalizować niedokładność zegara audio i dryf w stosunku do czasu standardowego.
• POWINNO zminimalizować dryf zegara audio w stosunku do CPU CLOCK_MONOTONIC, gdy obie te wartości są aktywne.
• POWINNO Zminimalizować opóźnienie dźwięku przez przetworniki na urządzeniu.
• POWINNO zminimalizować opóźnienie dźwięku podczas korzystania z dźwięku cyfrowego przez USB.
• POWINIEN udokumentować pomiary opóźnienia dźwięku na wszystkich ścieżkach.
• POWINNY być zminimalizowanie zakłóceń podczas wywołań zwrotnych pełnego bufora audio, ponieważ wpływa to na procent wykorzystania pełnej przepustowości procesora przez wywołanie zwrotne.
• Przy normalnym użytkowaniu z określonym opóźnieniem nie powinno być żadnych zakłóceń w dźwięku.
• POWINNA SIĘ znajdować zerową różnicę czasu oczekiwania między kanałami.
• POWINNA Zminimalizować średni czas oczekiwania MIDI podczas wszystkich transmisji.
• POWINNO zminimalizować zmienność opóźnienia MIDI podczas obciążenia (zakłócenia) podczas wszystkich transmisji.
• NALEŻY podawać dokładne sygnatury czasowe MIDI we wszystkich transmisjach.
• POWINNO zminimalizować szum sygnału audio przez przetworniki urządzenia, w tym przez okres tuż po uruchomieniu „na zimno”.
• TRZEBA zadbać o zerową różnicę zegara dźwięku między stroną wejściową a wyjściową odpowiednich punktów końcowych, gdy oba te punkty są aktywne. Przykładami odpowiednich punktów końcowych są mikrofon i głośnik urządzenia oraz wejście i wyjście gniazda słuchawek.
• NALEŻY obsługiwać wywołania zwrotne uzupełniania bufora audio po stronach wejściowych i wyjściowych odpowiednich punktów końcowych w tym samym wątku, gdy oba są aktywne, i wprowadzać wyjściowe wywołanie zwrotne tuż po zwrocie z wejściowego wywołania zwrotnego. A jeśli nie możesz obsłużyć wywołań zwrotnych w tym samym wątku, wpisz wyjściowe wywołanie zwrotne krótko po wprowadzeniu wywołania zwrotnego, aby aplikacja mogła mieć spójny czas na danych wejściowych i wyjściowych.
• 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.
• POWINNO zminimalizować opóźnienie dotyku.
• POWINNO zminimalizować zmienność czasu oczekiwania na dotknięcie przy obciążeniu (zakłócenia).
• Opóźnienie pomiędzy sygnałem dotykowym a sygnałem audio nie może przekraczać 40 ms.

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

• [SR] ZALECANE jest zgłoszenie pomocy dotyczącej funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager.

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

• [C-2-1] Ciągłe opóźnienie dźwięku w obie strony musi wynosić maksymalnie 20 milisekund na ścieżce audio.
• [SR] ZALECANE jest zachowanie zgodności z sekcją Specyfikacja urządzenia mobilnego (gniazdo) w specyfikacji przewodowego zestawu słuchawkowego (wersja 1.1).
• Ciągłe opóźnienie dźwięku w obie strony NIE powinno przekraczać 10 milisekund na ścieżce audio.

Jeśli implementacje urządzeń pomijają 4-kanałowe gniazdo słuchawek 3, 5 mm i są wyposażone w porty USB obsługujące tryb hosta USB:

• [C-3-1] MUSI zaimplementować klasę audio USB.
• [C-3-2] MUSI mieć ciągłe opóźnienie dźwięku w obie strony wynoszące maksymalnie 20 milisekund przez port w trybie hosta USB z użyciem klasy audio USB.
• Ciągłe opóźnienie dźwięku w obie strony NIE powinno przekraczać 10 milisekund w przypadku portu w trybie hosta USB z użyciem klasy audio USB.
• [C-SR] Zdecydowanie zalecana jest jednoczesna obsługa do 8 kanałów w każdym kierunku, częstotliwości próbkowania 96 kHz i głębi 24-bitowej lub 32-bitowej w przypadku używania z urządzeniami peryferyjnymi USB, które również spełniają te wymagania.

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

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

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

Android umożliwia nagrywanie nieprzetworzonego dźwięku przez źródło dźwięku android.media.MediaRecorder.AudioSource.UNPROCESSED. W OpenSL ES można uzyskać do niego dostęp za pomocą gotowego ustawienia rekordów SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Jeśli implementacja urządzenia ma obsługiwać nieprzetworzone źródło dźwięku i udostępniać je aplikacjom innych firm:

• [C-1-1] MUSI zgłosić pomoc za pomocą android.media.AudioManager usługi PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] MUSI wykazywać przybliżoną płaską amplitudę względem częstotliwości w średnim zakresie częstotliwości: ±10 dB od 100 Hz do 7000 Hz dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-3] MUSI mieć poziom amplitudy w niskim zakresie: od ±20 dB od 5 Hz do 100 Hz w porównaniu ze średnim zakresem częstotliwości dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-4] MUSI mieć poziom amplitudy w zakresie wysokich częstotliwości: od ±30 dB od 7000 Hz do 22 kHz w porównaniu ze średnim zakresem częstotliwości dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-5] MUSI ustawić czułość sygnału wejściowego dźwięku tak, aby źródło tonów sinusoidalnych 1000 Hz odtwarzane przy poziomie ciśnienia akustycznego 94 dB (SPL) dało odpowiedź z RMS 520 dla 16-bitowych próbek (lub -36 dB pełnej skali w przypadku każdego źródła zmiennoprzecinkowego lub podwójnej precyzji użytego źródła dźwięku z mikrofonem).

• [C-1-6] MUSI mieć współczynnik sygnału do szumu (SNR) wynoszący 60 dB lub więcej dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku. (SNR jest mierzony jako różnica między 94 dB SPL a równoważnym SPL własnym szumem ważonym A).

• [C-1-7] Wartość całkowitego zniekształcenia harmonicznego (THD) dla 1 kHZ przy 90 dB poziomu wejściowego SPL MUSI być mniejsza niż 1% dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• NIE MOŻESZ obsługiwać żadnego innego przetwarzania sygnału (np. automatycznej kontroli wzmocnienia, filtra górnoprzepustowego ani usuwania echa) na ścieżce innej niż mnożnik poziomu umożliwiający uzyskanie pożądanego poziomu. Krótko mówiąc:

• [C-1-8] Jeśli z jakiegoś powodu w architekturze obecne jest przetwarzanie sygnału, MUSI być ono wyłączone i w efekcie powodować zero opóźnienia lub dodatkowe opóźnienia na ścieżce sygnału.
• [C-1-9] Mnożnik poziomu, który może znajdować się na ścieżce, NIE MOŻE wywoływać opóźnienia na ścieżce sygnału.

Wszystkie pomiary SPL są wykonywane bezpośrednio obok testowanego mikrofonu. W przypadku różnych konfiguracji mikrofonów te wymagania dotyczą każdego z nich.

Jeśli implementacje urządzeń zadeklarują android.hardware.microphone, ale nie obsługują nieprzetworzonego źródła dźwięku:

• [C-2-1] W przypadku metody API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) MUSI zwracać wartość null, aby prawidłowo wskazać brak obsługi.
• Zdecydowanie ZALECANE jest spełnienie jak największej liczby wymagań dotyczących ścieżki sygnału dla nieprzetworzonego źródła nagrania.

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

6.1. Narzędzia dla programistów

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać narzędzia dla programistów aplikacji na Androida zawarte w pakiecie Android SDK.

• Android Debug Bridge (adb)

  • [C-0-2] MUSI obsługiwać narzędzie adb zgodnie z opisem w pakiecie SDK do Androida i polecenia powłoki podane w AOSP, których mogą używać deweloperzy aplikacji, w tym dumpsys cmd stats.
  • [C-0-11] MUSI obsługiwać polecenie powłoki cmd testharness. Uaktualnienie implementacji urządzeń z wcześniejszej wersji Androida bez trwałego bloku danych może zostać wyłączone ze standardu C-0-11.
  • [C-0-3] NIE MOŻE zmieniać formatu ani zawartości zdarzeń systemowych urządzenia (batterystats , Disstats, odcisków cyfrowych, Graphstats, netstats, notification, procstats) zarejestrowanych przy użyciu polecenia dumpsys.
  • [C-0-10] MUSI rejestrować bez pomijania oraz udostępniać poniższe zdarzenia poleceniem powłoki cmd stats i klasie systemowego interfejsu API StatsManager.
    • Zmieniono stan działania pierwszego planu
    • Wykryto anomalię
    • Zgłoszono menu nawigacyjne aplikacji
    • Wystąpiła awaria
    • Uruchomienie aplikacji
    • Poziom baterii został zmieniony
    • Zmieniono stan trybu oszczędzania baterii
    • Odebrano BleScanResult
    • Stan BleScanState zmieniony
    • Zmieniono stan ładowania
    • Zmieniono stan bezczynności urządzenia
    • Zmieniono stan usługi na pierwszym planie
    • Zmieniono stan skanowania GPS
    • Stan zadania zmieniony
    • Stan wtyczki zmieniony
    • Zmieniono stan zaplanowanego zadania
    • Zmieniono stan ekranu
    • SyncState (Zmiana stanu)
    • Czas rzeczywisty (system) w czasie rzeczywistym
    • Zmieniono stan procesu UidProcess
    • Stan uśpienia został zmieniony
    • Pojawił się Budzik
    • Zmiana stanu blokady Wi-Fi
    • Zmiana stanu blokady Wi-FiMulticastLock
    • Zmiana stanu skanowania Wi-Fi
  • [C-0-4] demon adb po stronie urządzenia MUSI być domyślnie nieaktywny i musi istnieć dostępny dla użytkownika mechanizm umożliwiający włączenie narzędzia Android Debug Bridge.
  • [C-0-5] MUSI obsługiwać bezpieczne narzędzie adb. Android zapewnia obsługę bezpiecznego pliku adb. Bezpieczny adb włącza narzędzie adb na znanych uwierzytelnionych hostach.
  • [C-0-6] MUSI zapewniać mechanizm umożliwiający połączenie narzędzia adb z komputera hosta. Więcej szczegółów:

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

  • [C-3-1] MUSI zaimplementować adb przez sieć lokalną (np. Ethernet lub Wi-Fi).
  • [C-3-2] MUSI zawierać sterowniki dla Windows 7, 8 i 10, które umożliwiają programistom połączenie się z urządzeniem za pomocą protokołu adb.

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

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

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

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

• Usługa monitorowania debugowania Dalvik (ddms)

  • [C-0-7] MUSI obsługiwać wszystkie funkcje ddms zgodnie z dokumentacją pakietu Android SDK. Ponieważ pakiet ddms używa narzędzia adb, obsługa ddms powinna być domyślnie nieaktywna, ale MUSI być obsługiwana za każdym razem, gdy użytkownik aktywuje Android Debug Bridge (jak powyżej).
• Małpa
  • [C-0-8] MUSI zawierać platformę Monkey i udostępniać ją aplikacjom.
• SysTrace,
  • [C-0-9] MUSI obsługiwać narzędzie systrace zgodnie z opisem w pakiecie SDK na Androida. System musi być domyślnie nieaktywny, a jego włączenie MUSI mieć dostępny dla użytkownika mechanizm.
• Perfetto
  • [C-SR] Zdecydowanie ZALECANE jest udostępnienie użytkownikowi powłoki pliku binarnego /system/bin/perfetto. Wiersz poleceń cmdline jest zgodny z dokumentacją perfetto.
  • [C-SR] Zdecydowanie zaleca się, aby plik binarny perfetto akceptuje jako dane wejściowe konfigurację protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR] Zdecydowanie zaleca się zapisać plik binarny perfetto jako dane wyjściowe logu czasu protokołu zgodnego ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR] Zdecydowanie ZALECANE jest podanie za pomocą pliku binarnego perfetto przynajmniej źródeł danych opisanych w dokumentacji perfetto.
• Narzędzie do ograniczania braku pamięci
  • [C-0-10] MUSI zapisać element LMK_KILL_OCCURRED_FIELD_NUMBER Atom w dzienniku statystycznym, gdy aplikacja zostanie zamknięta przez mechanizm kontroli małej pamięci.
• Tryb jarzma testowego Jeśli implementacje urządzeń obsługują polecenie powłoki cmd testharness i uruchamiają polecenie cmd testharness enable, funkcje te:
  • [C-2-1] MUSI zwrócić true za ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] MUSI wdrożyć tryb jarzma testowego zgodnie z opisem w dokumentacji trybu jarzma testowego.

Jeśli implementacje urządzeń zgłaszają obsługę interfejsu Vulkan 1.0 lub nowszego za pomocą flag funkcji android.hardware.vulkan.version, oznacza to, że:

• [C-1-1] MUSI zapewniać deweloperowi aplikacji możliwość włączenia/wyłączenia warstw debugowania GPU.
• [C-1-2] Gdy włączone są warstwy debugowania GPU, należy wyliczyć warstwy w bibliotekach udostępnianych przez narzędzia zewnętrzne (tj. niebędące częścią platformy ani pakietu aplikacji) znajdujące się w aplikacjach możliwych do debugowania w katalogu podstawowym do obsługi metod interfejsu API vkEnumerateInstanceLayerWłaściwości() i vkCreateInstance().

6.2. Opcje programisty

Android zapewnia programistom możliwość konfigurowania ustawień związanych z programowaniem aplikacji.

Implementacje na urządzeniu MUSZĄ zapewniać spójny interfejs Opcji programisty, ponieważ:

• [C-0-1] MUSI uwzględniać intencję android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z programowaniem. Nadrzędna implementacja Androida ukrywa menu Opcje programisty domyślnie i umożliwia użytkownikom uruchomienie Opcji programisty po naciśnięciu 7 (7) razy w sekcji Ustawienia > Informacje o urządzeniu > Pozycja menu Numer kompilacji.
• [C-0-2] Domyślnie MUSI ukryć Opcje programisty.
• [C-0-3] MUSI zawierać jasny mechanizm, który umożliwia korzystanie z Opcji dewelopera na preferencyjnym poziomie wobec jednej aplikacji innej firmy. MUSI udostępnić publicznie widoczny dokument lub witrynę opisującą, jak włączyć Opcje programisty. Dokument lub witryna MUSI zawierać link w dokumentach pakietu Android SDK.
• POWINNY być stale widoczne dla użytkownika powiadomienie wizualne, gdy Opcje programisty są włączone, a użytkownik jest w trosce o bezpieczeństwo.
• MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty, ukrywając je lub wyłączając je, aby nie rozpraszać uwagi użytkowników w sytuacjach, gdy jest obawa o bezpieczeństwo użytkownika.

7. Zgodność sprzętu

Jeśli urządzenie jest wyposażone w konkretny komponent sprzętowy, który ma odpowiedni interfejs API dla zewnętrznych programistów:

• [C-0-1] Implementacja na urządzeniu MUSI implementować ten interfejs API w sposób opisany w dokumentacji pakietu Android SDK.

Jeśli interfejs API w pakiecie SDK wchodzi w interakcję z komponentem sprzętowym, który jest określony jako opcjonalny, a implementacja urządzenia nie zawiera tego komponentu:

• [C-0-2] Nadal MUSISZ przedstawiać pełne definicje klas (zgodnie z dokumentacją w pakiecie SDK) dla interfejsów API komponentów.
• [C-0-3] Działanie interfejsu API MUSI być w jakiś rozsądny sposób implementowane jako brak działań.
• [C-0-4] Metody interfejsu API MUSZĄ zwracać wartości null tam, gdzie jest to dozwolone w dokumentacji pakietu SDK.
• [C-0-5] Metody interfejsu API MUSZĄ zwracać implementacje klas bezobsługowych, w których wartości null są niedozwolone w dokumentacji pakietu SDK.
• [C-0-6] Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, których nie opisano w dokumentacji pakietu SDK.
• [C-0-7] Implementacje urządzeń MUSZĄ spójnie zgłaszać dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) z klasą android.content.pm.PackageManager dla tego samego odcisku cyfrowego kompilacji.

Typowym przykładem sytuacji, w której obowiązują te wymagania, jest interfejs telefoniczny API. Te interfejsy API należy wdrożyć bez żadnych działań nawet na urządzeniach innych niż telefony.

7.1. Wyświetlacz i grafika

Android zawiera elementy, które automatycznie dostosowują zasoby aplikacji i układy interfejsu użytkownika do urządzenia, aby aplikacje innych firm działały prawidłowo na różnych konfiguracjach sprzętowych. Na wyświetlaczach zgodnych z Androidem, na których mogą być uruchamiane wszystkie aplikacje innych firm z Androidem, implementacje urządzeń MUSZĄ prawidłowo implementować te interfejsy API i działania zgodnie z opisem w tej sekcji.

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

• fizyczny rozmiar przekątnej. Wyrażona w calach odległość między dwoma przeciwległymi rogami podświetlonej części wyświetlacza.
• punktów na cal (dpi). Liczba pikseli nałożonych na liniową, poziomą lub pionową rozpiętość 1 cali”. Jeśli podane są wartości dpi, wartość dpi zarówno w poziomie, jak i w pionie musi mieścić się w zakresie.
• format obrazu. Stosunek liczby pikseli dłuższego wymiaru do krótszego wymiaru ekranu. Na przykład przy rozmiarze 480 x 854 piksele będzie to 854/480 = 1, 779, czyli w przybliżeniu „16:9”.
• piksel niezależny od gęstości (dp). Jednostka wirtualnego piksela znormalizowana do ekranu o rozdzielczości 160 dpi. Wartość jest obliczana według wzoru: piksele = dps * (gęstość/160).

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar i kształt ekranu

Platforma interfejsu Androida obsługuje różne logiczne rozmiary układu ekranu i umożliwia aplikacjom wysyłanie zapytań o rozmiar układu ekranu w bieżącej konfiguracji za pomocą interfejsu Configuration.screenLayout z użyciem SCREENLAYOUT_SIZE_MASK i Configuration.smallestScreenWidthDp.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłosić prawidłowy rozmiar układu elementu Configuration.screenLayout zgodnie z definicją w dokumentacji pakietu Android SDK. Implementacje urządzeń MUSZĄ zgłaszać prawidłowe wymiary ekranu niezależne od gęstości logicznej (dp) jak poniżej:

  • Urządzenia, które mają ustawioną wartość Configuration.uiMode jako dowolną inną niż UI_MODE_TYPE_WATCH i przesyłający zgłoszenie o rozmiarze small dla elementu Configuration.screenLayout MUSZĄ mieć co najmniej 426 dp x 320 dp.
  • Urządzenia zgłaszające rozmiar normal w polu Configuration.screenLayout MUSZĄ mieć co najmniej 480 dp x 320 dp.
  • Urządzenia zgłaszające rozmiar large dla elementu Configuration.screenLayout MUSZĄ mieć co najmniej 640 dp x 480 dp.
  • Urządzenia zgłaszające rozmiar xlarge dla elementu Configuration.screenLayout MUSZĄ mieć co najmniej 960 dp x 720 dp.

• [C-0-2] MUSI prawidłowo akceptować zgłoszenia dodaliśmy obsługę rozmiarów ekranu za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml, zgodnie z opisem w dokumentacji pakietu Android SDK.

• MOŻE mieć wyświetlacze zgodne z Androidem z zaokrąglonymi rogami.

Jeśli implementacje urządzeń obsługują UI_MODE_TYPE_NORMAL i zawierają wyświetlacze zgodne z Androidem z zaokrąglonymi rogami:

• [C-1-1] MUSI upewnić się, że spełniony jest co najmniej jeden z tych warunków:
• Promień zaokrąglonych rogów nie przekracza 38 dp.

• Gdy w każdym rogu wyświetlacza logicznego zakotwiczone jest pole o wymiarach 15 x 15 dp, na ekranie widoczny jest co najmniej 1 piksel z każdego pola.

• POWIADOMIENIA, Żeby użytkownik mógł przełączyć się na tryb wyświetlania z prostokątnymi narożnikami, należy uwzględnić danie użytkownika.

Jeśli implementacje urządzeń obejmują składane wyświetlacze zgodne z Androidem lub zawiasy umieszczone między wieloma panelami i udostępniają takie wyświetlacze do renderowania aplikacji innych firm:

• [C-2-1] Trzeba wdrożyć najnowszą stabilną wersję interfejsu API rozszerzeń lub stabilną wersję sidecar API, która ma być używana przez bibliotekę Window Manager Jetpack.

Jeśli urządzenia są wyposażone w składany wyświetlacz zgodny z Androidem lub składany zawias między kilkoma panelami, a zawias lub zawias przecina pełnoekranowe okno aplikacji:

• [C-3-1] MUSI zgłaszać do aplikacji położenie, granice i stan zawiasu lub zawinięcia za pomocą rozszerzeń lub interfejsów API pomocniczych.

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

7.1.1.2. Współczynnik proporcji ekranu

Chociaż nie ma ograniczeń co do formatu obrazu fizycznego wyświetlacza w przypadku wyświetlaczy zgodnych z Androidem, współczynnik proporcji obrazu logicznego, na którym są renderowane aplikacje innych firm, który można określić na podstawie wartości wysokości i szerokości zgłaszanych za pomocą interfejsów API view.Display i interfejsów API konfiguracji, MUSI spełniać te wymagania:

• [C-0-1] Implementacje na urządzeniach, w których Configuration.uiMode ma wartość UI_MODE_TYPE_NORMAL, MUSZĄ mieć współczynnik proporcji mniejszy lub równy 1,86 (około 16:9), chyba że aplikacja spełnia jeden z tych warunków:

  • Aplikacja zadeklarowała, że obsługuje większy format obrazu za pomocą wartości metadanych android.max_aspect.
  • Aplikacja deklaruje, że rozmiar można zmienić w atrybucie android:resizeableActivity.
  • Aplikacja jest kierowana na interfejs API na poziomie 24 lub wyższym i nie deklaruje interfejsu android:maxAspectRatio, który ograniczałby dozwolony format obrazu.

• [C-0-2] Implementacje na urządzeniach, w których Configuration.uiMode ma wartość UI_MODE_TYPE_NORMAL, MUSZĄ mieć współczynnik proporcji nie większy niż 1,3333 (4:3), chyba że aplikację można rozciągnąć w szerszym zakresie, spełniając jeden z tych warunków:

  • Aplikacja deklaruje, że rozmiar można zmienić w atrybucie android:resizeableActivity.
  • Aplikacja deklaruje element android:minAspectRatio, który ogranicza dozwolony format obrazu.

• [C-0-3] Implementacje na urządzeniach, w których Configuration.uiMode ma wartość UI_MODE_TYPE_WATCH, MUSZĄ mieć format obrazu ustawiony na 1,0 (1:1).

7.1.1.3 Gęstość ekranu

Platforma UI Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić programistom kierowanie zasobów aplikacji.

• [C-0-1] Domyślnie implementacje urządzeń MUSZĄ zgłaszać tylko jedną z gęstości platformy Androida wymienionych na liście DisplayMetrics przez DENSITY_DEVICE_STABLE API. Ta wartość NIE MOŻE się w żadnym momencie zmieniać. Urządzenie MOŻE jednak zgłosić inną gęstość zależnie od zmian w konfiguracji wyświetlacza wprowadzonych przez użytkownika (np. rozmiaru wyświetlacza) ustawionych po pierwszym uruchomieniu.

• Implementacje na urządzeniach NALEŻY zdefiniować standardową gęstość platformy Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, chyba że taka gęstość sprowadza raportowany rozmiar ekranu poniżej obsługiwanego minimum. Jeśli standardowa gęstość platformy Androida, która jest najbliższa liczbowo gęstości fizycznej, powoduje, że rozmiar ekranu jest mniejszy niż najmniej obsługiwany obsługiwany rozmiar ekranu (320 dp), implementacje urządzeń POWINNY zgłaszać następny najniższy standardowy poziom gęstości platformy.

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

• [C-1-1] Rozmiar wyświetlacza NIE MOŻE być skalowany większy niż 1,5 raza gęstości natywnej ani nie może powodować, że minimalny rozmiar ekranu będzie mniejszy niż 320 dp (odpowiednik kwalifikatora zasobów sw320dp – w zależności od tego, co nastąpi wcześniej).
• [C-1-2] Rozmiar wyświetlacza NIE MOŻE być skalowany w sposób mniejszy niż 0,85 raza gęstości natywnej.
• Aby zapewnić wygodę obsługi i spójne rozmiary czcionek, ZALECANE jest użycie poniższych opcji skalowania reklam natywnych w sieci reklamowej (zgodnie z powyższymi limitami).
• Małe: 0,85x
• Domyślnie: 1x (natywna skala wyświetlania)
• Duży: 1,15x
• Większe: 1,3x
• Największy 1,45x

7.1.2. Wyświetl dane

Jeśli implementacje urządzeń obejmują wyświetlacze lub ekrany zgodne z Androidem zgodne z Androidem, to:

• [C-1-1] MUSI podawać prawidłowe wartości dla wszystkich danych o wyświetlaczach zgodnych z Androidem zdefiniowanych w interfejsie API android.util.DisplayMetrics.

Jeśli implementacje urządzeń nie zawierają osadzonego ekranu lub wyjścia wideo:

• [C-2-1] MUSI zgłaszać prawidłowe wartości wyświetlacza zgodnego z Androidem zgodnie z definicją w interfejsie API android.util.DisplayMetrics dla emulowanej domyślnej wartości view.Display.

7.1.3 Orientacja ekranu

Implementacje na urządzeniach:

• [C-0-1] MUSI podawać obsługiwane orientacje ekranu (android.hardware.screen.portrait lub android.hardware.screen.landscape) i MUSI podawać co najmniej jedną obsługiwaną orientację. Na przykład urządzenie ze stałą orientacją poziomą, takie jak telewizor czy laptop, MUSI zgłosić tylko wartość android.hardware.screen.landscape.
• [C-0-2] MUSI zgłaszać prawidłową wartość w przypadku bieżącej orientacji urządzenia w przypadku wysyłania zapytań za pomocą interfejsu android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innych interfejsów API.

Jeśli implementacje urządzeń obsługują obie orientacje ekranu, umożliwiają one:

• [C-1-1] MUSI obsługiwać orientację dynamiczną w aplikacjach w orientacji pionowej lub poziomej. Oznacza to, że urządzenie musi uwzględniać żądanie aplikacji dotyczące określonej orientacji ekranu.
• [C-1-2] NIE MOŻE zmieniać zgłoszonego rozmiaru ani gęstości ekranu podczas zmiany orientacji.
• MOGĄ wybrać orientację pionową lub poziomą jako domyślną.

7.1.4. Przyspieszenie działania grafiki 2D i 3D

7.1.4.1 OpenGL ES

Implementacje na urządzeniach:

• [C-0-1] MUSI poprawnie identyfikować obsługiwane wersje OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) za pomocą zarządzanych interfejsów API (np. GLES10.getString()) i natywnych interfejsów API.
• [C-0-2] MUSI obsługiwać wszystkie odpowiednie zarządzane interfejsy API i natywne interfejsy API dla każdej wersji OpenGL ES, którą zidentyfikowano jako obsługiwane.

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

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

Jeśli implementacje urządzeń obsługują dowolną wersję OpenGL ES:

• [C-2-1] MUSI zgłaszać za pomocą zarządzanych interfejsów API OpenGL ES i natywnych interfejsów API wszystkie inne zaimplementowane rozszerzenia OpenGL ES i NIE MOŻE zgłaszać ciągów rozszerzeń, które nie są obsługiwane.
• [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-SR] Zdecydowanie ZALECANE jest obsługa rozszerzeń EGL_KHR_partial_update i OES_EGL_image_external.
• POWINNY jest dokładne raportowanie za pomocą metody getString(), czyli dowolnego obsługiwanego formatu kompresji tekstur, który jest zwykle zależny od dostawcy.

Jeśli implementacje urządzeń zadeklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2:

• [C-3-1] Oprócz symboli funkcji OpenGL ES 2.0 z biblioteki libGLESv2.so MUSI wyeksportować odpowiednie symbole funkcji dla tej wersji.
• [SR] Zdecydowanie ZALECANE jest obsługa rozszerzenia OES_EGL_image_external_essl3.

Jeśli implementacje urządzeń obsługują OpenGL ES 3.2:

• [C-4-1] MUSI obsługiwać w całości pakiet rozszerzeń OpenGL ES na Androida.

Jeśli implementacje urządzeń obsługują w całości pakiet rozszerzeń OpenGL ES, funkcje te:

• [C-5-1] MUSI określać pomoc za pomocą flagi funkcji android.hardware.opengles.aep.

Jeśli implementacje urządzeń zapewniają obsługę rozszerzenia EGL_KHR_mutable_render_buffer:

• [C-6-1] MUSI też obsługiwać rozszerzenie EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 interfejs Vulkan

Android obsługuje Vulkan – niskobudżetowy, wieloplatformowy interfejs API do wysokiej wydajności grafiki 3D.

Jeśli implementacje urządzeń obsługują OpenGL ES 3.1:

• [SR] Zdecydowanie ZALECANE jest włączenie obsługi Vulkan 1.1.

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

• POWINNO obsługiwać platformę Vulkan 1.1.

Testy Vulkan dEQP są podzielone na kilka list testowych, z których każda ma ustaloną datę i wersję. Znajdziesz je w drzewie źródłowym Androida pod adresem external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Urządzenie, które obsługuje Vulkana na samodzielnie zgłoszonym poziomie, wskazuje, że może zaliczyć testy dEQP na wszystkich listach testowych na tym poziomie i starszych.

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

• [C-1-1] MUSI podawać prawidłową liczbę całkowitą z flagami funkcji android.hardware.vulkan.level i android.hardware.vulkan.version.
• [C-1-2] MUSI wyliczać co najmniej 1 VkPhysicalDevice dla natywnego interfejsu API Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] MUSI w pełni wdrożyć interfejsy Vulkan 1.0 API w przypadku każdego wymienionego parametru VkPhysicalDevice.
• [C-1-4] MUSI wyliczać warstwy zawarte w bibliotekach natywnych o nazwie libVkLayer*.so w katalogu biblioteki natywnej pakietu aplikacji przy użyciu natywnych interfejsów API Vulkan vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties() .
• [C-1-5] NIE MOŻE wyliczać warstw dostarczanych przez biblioteki poza pakietem aplikacji ani udostępniać innych sposobów śledzenia lub przechwytywania interfejsu Vulkan API, chyba że aplikacja ma atrybut android:debuggable ustawiony jako true.
• [C-1-6] MUSI zgłaszać wszystkie ciągi rozszerzeń, które obsługują przez natywne interfejsy API Vulkan, i NIE MOGĄ raportować ciągów rozszerzeń, które nie są prawidłowo obsługiwane.
• [C-1-7] MUSI obsługiwać rozszerzenia VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain i VK_KHR_incremental_present.
• [C-1-8] MUSI zgłaszać maksymalną wersję testów Vulkan dEQP obsługiwanych za pomocą flagi funkcji android.software.vulkan.deqp.level.
• [C-1-9] MUSI obsługiwać co najmniej wersję 132317953 (od 1 marca 2019 r.) zgodnie z opisem we fladze funkcji android.software.vulkan.deqp.level.
• [C-1-10] MUSI przejść wszystkie testy Vulkan dEQP na listach testowych w wersji 132317953 a wersją określoną we fladze funkcji android.software.vulkan.deqp.level.
• [C-SR] Zdecydowanie ZALECANE jest obsługa rozszerzeń VK_KHR_driver_properties i VK_GOOGLE_display_timing.

Jeśli implementacje urządzeń nie obsługują interfejsu Vulkan 1.0:

• [C-2-1] NIE MOŻE deklarować żadnych flag funkcji interfejsu Vulkan (np. android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] NIE MOŻE wyliczać żadnych elementów VkPhysicalDevice dla natywnego interfejsu API Vulkan vkEnumeratePhysicalDevices().

Jeśli implementacje urządzeń obejmują obsługę interfejsu Vulkan 1.1 i zadeklarowane są jego flagi funkcji Vulkan, oznacza to, że:

• [C-3-1] MUSI udostępniać obsługę zewnętrznych semaforów i typów uchwytów SYNC_FD oraz rozszerzenia VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Implementacje na urządzeniach MUSZĄ obsługiwać protokół Android RenderScript, zgodnie z opisem w dokumentacji pakietu Android SDK.

Przyspieszenie grafiki 2D 7.1.4.4

Android zawiera mechanizm deklarowania przez aplikacje, że chcą włączyć akcelerację sprzętową grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku. Służy do tego tag manifestu android:hardwareAccelerated lub bezpośrednie wywołania interfejsu API.

Implementacje na urządzeniach:

• [C-0-1] MUSI domyślnie włączać akcelerację sprzętową i MUSI wyłączyć akcelerację sprzętową, jeśli deweloper o to poprosi, ustawiając parametr android:hardwareAccelerated="false" lub wyłączając akcelerację sprzętową bezpośrednio przez interfejsy Android View API.
• [C-0-2] MUSI działać zgodnie z opisem w dokumentacji pakietu Android SDK na temat akceleracji sprzętowej.

Android zawiera obiekt TextureView, który umożliwia programistom bezpośrednią integrację z akceleracją sprzętową tekstur OpenGL ES jako celów renderowania w hierarchii UI.

Implementacje na urządzeniach:

• [C-0-3] MUSI obsługiwać interfejs TextureView API i MUSI działać w spójny sposób z wcześniejszą implementacją Androida.

7.1.4.5 Wyświetlacze o szerokiej gamie

Jeśli implementacji na urządzeniu informują o obsłudze ekranów o szerokiej gamie za pomocą Configuration.isScreenWideColorGamut():

• [C-1-1] MUSI mieć wyświetlacz z kalibracją kolorów.
• [C-1-2] MUSI mieć wyświetlacz, którego zakres obejmuje całą paletę kolorów sRGB w przestrzeni CIE 1931 xyY.
• [C-1-3] MUSI mieć wyświetlacz o gatunku równym co najmniej 90% obszaru DCI-P3 w przestrzeni CIE 1931 xyY.
• [C-1-4] MUSI obsługiwać standard OpenGL ES 3.1 lub 3.2 i prawidłowo go zgłaszać.
• [C-1-5] MUSI reklamować 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] Zdecydowanie ZALECANE jest działanie funkcji GL_EXT_sRGB.

Jeśli natomiast implementacje urządzeń nie obsługują wyświetlaczy o szerokim zakresie kolorów:

• [C-2-1] POWINNA obejmować co najmniej 100% przestrzeni sRGB w przestrzeni CIE 1931 xyY, ale gama kolorów ekranu jest nieokreślona.

7.1.5 Tryb zgodności starszych aplikacji

Android określa „tryb zgodności”, w którym platforma działa w „normalnym” trybu odpowiadającego rozmiarowi ekranu (szerokości 320 dp) – z korzyścią dla starszych aplikacji nieopracowanych na potrzeby starszych wersji Androida, które wcześniej były niezależne od rozmiarów ekranu.

7.1.6 Technologia ekranu

Platforma Android zawiera interfejsy API umożliwiające aplikacjom renderowanie bogatej grafiki na wyświetlaczu zgodnym z systemem Android. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zgodnie z definicją w pakiecie Android SDK, o ile nie jest to wyraźnie dozwolone w tym dokumencie.

Wszystkie ekrany w implementacji na urządzeniach zgodnych z Androidem:

• [C-0-1] MUSI obsługiwać 16-bitową grafikę w kolorach.
• NALEŻY obsługiwać wyświetlacze z 24-bitową grafiką w 24-bitowych kolorach.
• [C-0-2] MUSI wyświetlać animacje.
• [C-0-3] MUSI mieć współczynnik proporcji piksela (PAR) z zakresu od 0,9 do 1,15. Oznacza to, że format obrazu MUSI być kwadratowy (1,0) i z tolerancją 10–15%.

7.1.7. Wyświetlacze dodatkowe

Android zapewnia obsługę dodatkowych wyświetlaczy zgodnych z Androidem, które umożliwiają udostępnianie multimediów, oraz interfejsów API dla programistów umożliwiających dostęp do wyświetlaczy zewnętrznych.

Jeśli implementacje urządzeń obsługują wyświetlacz zewnętrzny za pośrednictwem połączenia przewodowego, bezprzewodowego lub wbudowanego wyświetlacza dodatkowego,:

• [C-1-1] MUSI zaimplementować usługę systemową i interfejs API DisplayManager w sposób opisany w dokumentacji pakietu Android SDK.

7.2. Urządzenia wejściowe

Implementacje na urządzeniach:

• [C-0-1] Do poruszania się między elementami interfejsu MUSI zawierać mechanizm wprowadzania danych, np. ekran dotykowy lub nawigację bezdotykową.

7.2.1. Klawiatura

Jeśli implementacje urządzeń obejmują obsługę zewnętrznych aplikacji edytora metody wprowadzania (IME), te funkcje:

• [C-1-1] MUSI zadeklarować flagę funkcji android.software.input_methods.
• [C-1-2] MUSI obsługiwać w całości Input Management Framework
• [C-1-3] MUSI mieć wstępnie zainstalowaną klawiaturę programową.

Implementacje na urządzeniach: * [C-0-1] NIE MOŻE zawierać klawiatury sprzętowej w żadnym z formatów określonych w zasadzie android.content.res.Configuration.keyboard (QWERTY lub 12-key). * POWINNY BYĆ dodatkowe implementacje klawiatury programowej. * MOŻE zawierać klawiaturę sprzętową.

7.2.2 Nawigacja bezdotykowa

W Androidzie można używać pada kierunkowego, trackballa i kółka jako mechanizmów do nawigacji bezdotykowej.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłosić prawidłową wartość atrybutu android.content.res.Configuration.navigation.

Jeśli w urządzeniach nie ma nawigacji niedotykowej:

• [C-1-1] MUSI zapewniać uzasadniony alternatywny interfejs użytkownika do wyboru i edytowania tekstu, zgodny z mechanizmami zarządzania danymi wejściowymi. Implementacja open source Androida obejmuje mechanizm wyboru odpowiedni do zastosowania w urządzeniach, które nie zawierają nawigacji bezdotykowej.

7.2.3 Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz są zwykle dostępne w wyniku interakcji z osobnym przyciskiem lub wybraną częścią ekranu dotykowego. Mają więc kluczowe znaczenie dla nawigacji na Androidzie, a tym samym dla implementacji na urządzeniach:

• [C-0-1] MUSI zapewniać użytkownikowi możliwość uruchamiania zainstalowanych aplikacji, w których przypadku funkcja <intent-filter> jest ustawiona na wartości ACTION=MAIN i CATEGORY=LAUNCHER lub CATEGORY=LEANBACK_LAUNCHER w przypadku implementacji na urządzeniach telewizyjnych. Funkcja Home POWINNA być mechanizmem dla tej afordancji użytkownika.
• POWINNY jest dostęp do przycisków funkcji Ostatnie i Wstecz.

Jeśli dostępne są funkcje Ekran główny, Ostatnie i Wstecz, umożliwiają one:

• [C-1-1] MUSI być dostępny w ramach jednej czynności (np. kliknięcia lub dwukrotnego kliknięcia), jeśli którekolwiek z nich jest dostępne.
• [C-1-2] MUSI wyraźnie wskazywać, które działanie może wywołać daną funkcję. Może to być na przykład widoczna ikona nadrukowana na przycisku, ikona oprogramowania na pasku nawigacyjnym albo instrukcja pokazująca krok po kroku podczas konfiguracji po rozpakowaniu urządzenia.

Implementacje na urządzeniach:

• Zdecydowanie ZALECANE jest nieudostępnianie mechanizmu wprowadzania danych w funkcji menu, ponieważ od wersji Androida 4.0 wycofano ją i zastąpił pasek działań.

Jeśli implementacje urządzeń zapewniają funkcję menu, są to:

• [C-2-1] MUSI wyświetlać przycisk przepełnienia działania, gdy rozszerzone menu czynności nie jest puste i widoczny jest pasek działań.
• [C-2-2] NIE MOŻE zmieniać pozycji wyświetlanego wyskakującego okienka działania przez kliknięcie przycisku rozszerzania działania na pasku działań, ale MOGĄ renderować wyskakujące okienko rozszerzania działania w zmodyfikowanym położeniu na ekranie, gdy jest wyświetlane po wybraniu funkcji Menu.

Jeśli implementacje urządzeń nie obsługują funkcji menu, w celu zapewnienia zgodności wstecznej:

• [C-3-1] MUSI udostępnić funkcję Menu aplikacjom, gdy targetSdkVersion ma mniej niż 10 lat za pomocą fizycznego przycisku, klawisza oprogramowania lub gestów. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacyjnymi.

Jeśli implementacje urządzeń oferują funkcję wspomagania:

• [C-4-1] MUSI umożliwiać korzystanie z funkcji Asystenta jednym działaniem (np. kliknięciem, dwukrotnym kliknięciem lub gestem), gdy dostępne są inne klawisze nawigacyjne.
• Zdecydowanie ZALECANE jest użycie funkcji EKRAN GŁÓWNY, gdy jest to wyznaczona interakcja.

Jeśli implementacje urządzeń wykorzystują osobną część ekranu do wyświetlania klawiszy nawigacyjnych:

• [C-5-1] Klawisze nawigacyjne MUSZĄ zajmować wyraźną część ekranu, nie są dostępne dla aplikacji i NIE MOGĄ w żaden inny sposób zasłaniać tej części ekranu dostępnej dla aplikacji.
• [C-5-2] MUSI udostępnić część wyświetlacza aplikacjom spełniającym 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(), tak aby ta odrębna część ekranu (czyli pasek nawigacyjny) była prawidłowo ukryta w sposób opisany w pakiecie SDK.

Jeśli funkcja nawigacji jest udostępniana na ekranie za pomocą gestów:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() NALEŻY używać tylko do zgłaszania obszaru rozpoznawania gestów w domu.
• [C-6-2] Gesty, które rozpoczynają się w prostym obszarze wykluczenia przesłanym przez aplikację działającą na pierwszym planie za pomocą View#setSystemGestureExclusionRects(), ale poza WindowInsets#getMandatorySystemGestureInsets(), NIE MOGĄ przechwytywać przez funkcję nawigacji, jeśli prostokąt wykluczenia jest dozwolony w ramach maksymalnego limitu wykluczeń określonego w dokumentacji funkcji View#setSystemGestureExclusionRects().
• [C-6-3] MUSI wysłać do aplikacji na pierwszym planie zdarzenie MotionEvent.ACTION_CANCEL, gdy dotknięcia zostaną przechwycone w ramach gestu systemowego, jeśli aplikacja na pierwszym planie została wcześniej wysłana zdarzenie MotionEvent.ACTION_DOWN.
• [C-6-4] MUSI umożliwiać użytkownikowi przejście na ekranową nawigację opartą na przyciskach (na przykład w Ustawieniach).
• MUSI udostępnić funkcję ekranu głównego, czyli przesunięcie palcem w górę od dolnej krawędzi bieżącej orientacji ekranu.
• TRZEBA włączyć funkcję Ostatnie – przesuń palcem w górę i przytrzymaj przed zwolnieniem, z tego samego obszaru co gest ekranu głównego.
• Na gesty rozpoczynające się w obrębie WindowInsets#getMandatorySystemGestureInsets() NIE POWINNO mieć wpływu instrukcje wykluczania dostarczane przez aplikację działającą na pierwszym planie przez View#setSystemGestureExclusionRects().

Jeśli funkcja nawigacji jest dostępna z dowolnego miejsca przy lewej i prawej krawędzi bieżącej orientacji ekranu:

• [C-7-1] Funkcja nawigacji MUSI być dostępna w trybie Wstecz i być dostępna jako przesunięcie od lewej i prawej krawędzi bieżącej orientacji ekranu.
• [C-7-2] Jeśli niestandardowe przesuwane panele systemowe znajdują się na lewej lub prawej krawędzi, MUSZĄ być umieszczone w górnej 1/3 ekranu z wyraźnym, trwałym sygnałem wizualnym, że przeciąganie spowoduje wyświetlenie wspomnianych paneli, a więc nie Wstecz. Użytkownik MOŻE skonfigurować panel systemowy w taki sposób, aby znajdował się poniżej górnej 1/3 krawędzi ekranu, ale NIE MOŻE sięgać dalej niż 1/3 krawędzi.
• [C-7-3] Gdy aplikacja na pierwszym planie ma ustawione flagi View.SYSTEM_UI_FLAG_IMMERSIVE lub View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, przesuwanie od krawędzi MUSI działać tak samo jak w AOSP, co zostało opisane w pakiecie SDK.
• [C-7-4] Gdy aplikacja na pierwszym planie ma ustawioną flagę View.SYSTEM_UI_FLAG_IMMERSIVE lub View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, niestandardowe przesuwane panele systemowe MUSZĄ być ukryte, dopóki użytkownik nie wyświetli pasków systemowych (zwanych też paskami nawigacyjnymi lub paska stanu) zgodnie z implementacją w AOSP.

7.2.4 Wprowadzanie tekstu z ekranu dotykowego

Android obsługuje różne systemy wprowadzania danych wskaźnikami, takie jak ekrany dotykowe, pady dotykowe i fałszywe urządzenia dotykowe. Implementacje na urządzeniach z ekranem dotykowym są powiązane z ekranem w taki sposób, że użytkownik ma wrażenie bezpośredniego manipulacji elementami na ekranie. Ponieważ użytkownik bezpośrednio dotyka ekranu, system nie wymaga żadnych dodatkowych afordancji wskazujących manipulowane obiekty.

Implementacje na urządzeniach:

• POWINNY jest mieć jakikolwiek system wprowadzania danych za pomocą wskaźnika (na przykład myszy lub dotyku).
• POWINNA obsługiwać w pełni niezależnie śledzone wskaźniki.

Jeśli urządzenia są wyposażone w ekran dotykowy (dotykowo lub lepszy) na głównym wyświetlaczu zgodnym z Androidem:

• [C-1-1] MUSI zgłosić wartość TOUCHSCREEN_FINGER w polu interfejsu API Configuration.touchscreen.
• [C-1-2] MUSI zgłosić flagi funkcji android.hardware.touchscreen i android.hardware.faketouch.

Jeśli implementacje urządzeń obejmują ekran dotykowy, który może śledzić więcej niż jeden dotyk na głównym wyświetlaczu zgodnym z Androidem, to:

• [C-2-1] MUSI zgłosić odpowiednie flagi funkcji android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct i android.hardware.touchscreen.multitouch.jazzhand odpowiednie dla typu konkretnego ekranu dotykowego urządzenia.

Jeśli implementacje urządzeń wymagają zewnętrznego urządzenia wejściowego, takiego jak mysz lub kulka (czyli nie dotykają bezpośrednio ekranu) do wprowadzania danych na głównym wyświetlaczu zgodnym z Androidem, i spełniają wymagania dotyczące fałszywego dotyku opisane w sekcji 7.2.5, muszą one:

• [C-3-1] NIE MOŻE zgłaszać żadnych flag funkcji rozpoczynających się od android.hardware.touchscreen.
• [C-3-2] MUSI zgłosić tylko android.hardware.faketouch.
• [C-3-3] MUSI zgłosić wartość TOUCHSCREEN_NOTOUCH w polu interfejsu API Configuration.touchscreen.

7.2.5 Wprowadzanie tekstu fałszywego dotykiem

Fałszywy interfejs dotykowy udostępnia system wprowadzania danych, który w przybliżeniu przedstawia podzbiór możliwości z ekranu dotykowego. Na przykład mysz lub pilot, który steruje kursorem na ekranie, przybliża go do kliknięcia, ale wymaga od użytkownika najpierw wyśledzenia lub zaznaczenia, a następnie kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, mysz powietrzna z żyroskopem, żyroskop, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe. Android ma stałą funkcję android.hardware.faketouch, która odpowiada wysokiej jakości bezdotykowemu urządzeniu wejściowemu (opartemu na wskaźniku), takim jak mysz lub trackpad, które może odpowiednio emulować obsługę dotykową (w tym podstawową obsługę gestów). Wskazuje ona, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.

Jeśli urządzenia nie zawierają ekranu dotykowego, ale zawierają inny system wprowadzania danych, który ma zostać udostępniony, to:

• Trzeba zadeklarować obsługę flagi funkcji android.hardware.faketouch.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.faketouch, będą to:

• [C-1-1] MUSI podawać bezwzględne położenie ekranu na osi X i Y oraz wyświetlać wskaźnik wizualny na ekranie.
• [C-1-2] MUSI zgłaszać zdarzenie dotknięcia za pomocą kodu działania, który określa zmianę stanu, która następuje po przesuwaniu się w dół lub w górę ekranu przez wskaźnik.
• [C-1-3] MUSI obsługiwać kursor w dół i w górę na obiekcie na ekranie, co umożliwia użytkownikom emulację dotknięcia obiektu na ekranie.
• [C-1-4] MUSI obsługiwać wskaźnik w dół, w górę i w dół, a następnie powinien wskazywać w górę to samo miejsce na obiekcie na ekranie w wyznaczonym przedziale czasu. Umożliwia to użytkownikom emulację dwukrotnego kliknięcia obiektu na ekranie.
• [C-1-5] MUSI obsługiwać kursor w dół w dowolnym punkcie na ekranie. Wskaźnik powinien przesunąć się do dowolnego innego punktu na ekranie, a po nim przesuń wskaźnik w górę, co pozwoli użytkownikowi emulować przeciąganie dotykiem.
• [C-1-6] MUSI obsługiwać wskaźnik w dół, a następnie umożliwiać użytkownikom szybkie przeniesienie obiektu w inne miejsce na ekranie i przesunięcie go w górę, co umożliwia przesuwanie obiektu na ekranie.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.faketouch.multitouch.distinct, będą to:

• [C-2-1] MUSI zadeklarować obsługę interfejsu android.hardware.faketouch.
• [C-2-2] MUSI obsługiwać odrębne śledzenie co najmniej 2 niezależnych danych wejściowych wskaźnika.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.faketouch.multitouch.jazzhand, będą to:

• [C-3-1] MUSI zadeklarować obsługę interfejsu android.hardware.faketouch.
• [C-3-2] MUSI obsługiwać całkowicie niezależnie śledzenie 5 (śledzenie dłoni) lub większej liczby działań wskaźnika.

7.2.6 Obsługa kontrolera gier

7.2.6.1 Mapowania przycisków

Implementacje na urządzeniach:

• [C-1-1] MUSI być w stanie mapować zdarzenia HID na odpowiednie stałe InputEvent, jak podano w tabelach poniżej. Implementacja Androida spełnia to wymaganie.

Jeśli urządzenia są wyposażone w kontroler lub są dostarczane z osobnym kontrolerem, który umożliwiałby wprowadzanie wszystkich zdarzeń wymienionych w tabelach poniżej:

• [C-2-1] MUSI zadeklarować flagę funkcji android.hardware.gamepad

Przycisk	Wykorzystanie HID^2	Przycisk Androida
A^1	0x09 0x0001	KEYCODE_PRZYCISK_A (96)
B^1	0x09 0x0002	KEYCODE_PRZYCISK_B (97)
X^1	0x09 0x0004	KEYCODE_PRZYCISK_X (99)
T^1	0x09 0x0005	KEYCODE_PRZYCISK_Y (100)
Górny pad kierunkowy^1 Pad kierunkowy w dół^1	0x01 0x0039^3	AXIS_HAT_Y^4
Pad kierunkowy w lewo1 Pad kierunkowy w prawo^1	0x01 0x0039^3	AXIS_HAT_X^4
Przycisk na lewym ramieniu^1	0x09 0x0007	KEYCODE_Button_L1 (102)
Przycisk na prawym ramieniu^1	0x09 0x0008	KEYCODE_PRZYCISK_R1 (103)
Kliknięcie lewym drążkiem^1	0x09 0x000E	KEYCODE_button_THUMBL (106)
Kliknięcie prawym przyciskiem myszy^1	0x09 0x000F	KEYCODE_button_THUMBR (107)
Strona główna^1	0x0c 0x0223	KEYCODE_HOME (3)
Wstecz^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Powyższe przypadki użycia HID muszą być zadeklarowane w amerykańskim urzędzie certyfikacji pada do gier (0x01 0x0005).

3. Wartość logiczna musi wynosić 0, logiczne maksimum to 7, fizyczne minimum to 0, maksimum fizyczne 315, jednostki w stopniach i rozmiar raportu 4. Wartość logiczna oznacza obrót w prawo od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i naciśnięty przycisk w górę, a wartość logiczna 1 oznacza obrót o 45 stopni oraz naciskanie zarówno klawiszy strzałek w górę, jak i w lewo.

4 MotionEvent

Elementy sterujące analogowe^1	Wykorzystanie HID	Przycisk Androida
Lewy spust	0x02 0x00C5	AXIS_LTRIGGER
Prawy aktywator	0x02 0x00C4	AXIS_RTRIGGER
Lewy joystick	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Prawy joystick	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_Z

1 MotionEvent

7.2.7 Pilot

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

7.3. Czujniki

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który ma odpowiedni interfejs API dla programistów zewnętrznych, MUSISZ zaimplementować ten interfejs API w sposób opisany w dokumentacji pakietu Android SDK oraz w dokumentacji Androida open source dotyczącej czujników.

Implementacje na urządzeniach:

• [C-0-1] MUSI dokładnie zgłaszać obecność lub brak czujników dla klasy android.content.pm.PackageManager.
• [C-0-2] MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() i podobnych metod.
• [C-0-3] MUSI działać rozsądnie w przypadku wszystkich innych interfejsów API czujników (na przykład przez zwracanie odpowiednio parametru true lub false, gdy aplikacje próbują zarejestrować detektory, lub nie wywoływać odbiorników, gdy odpowiednie czujniki nie są dostępne itp.).

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który ma odpowiedni interfejs API dla zewnętrznych programistów, te elementy:

• [C-1-1] MUSI raportować wszystkie pomiary z czujników, korzystając z odpowiednich wartości międzynarodowych systemów jednostkowych (danych) dla każdego typu czujnika zgodnie z definicją w dokumentacji pakietu Android SDK.
• [C-1-2] MUSI zgłaszać dane z czujnika z maksymalnym opóźnieniem 100 milisekund + 2 * parametr sample_time w przypadku strumienia z czujnika z maksymalnym żądanym opóźnieniem 0 ms, gdy procesor aplikacji jest aktywny. Opóźnienie to nie uwzględnia opóźnień w filtrowaniu.
• [C-1-3] MUSI zgłosić pierwszą próbkę z czujnika w ciągu 400 milisekund + 2 * czas_próbki (sample_time) od aktywacji czujnika. W przypadku tej próby można mieć dokładność 0.
• [C-1-4] W przypadku interfejsów API wskazanych w dokumentacji pakietu Android SDK jako czujników ciągłych implementacje urządzeń MUSZĄ stale dostarczać okresowe próbki danych, w których zakłócenia są zdefiniowane jako standardowe odchylenie różnicy pomiędzy kolejnymi zdarzeniami.
• [C-1-5] MUSI mieć pewność, że strumień zdarzeń z czujnika NIE MOŻE zapobiegać przełączeniu procesora urządzenia w stan zawieszenia lub wybudzeniem procesora ze stanu zawieszenia.
• [C-1-6] MUSI raportować czas zdarzenia w nanosekundach, zgodnie z definicją w dokumentacji pakietu Android SDK. Musi on przedstawiać czas wystąpienia zdarzenia i być zsynchronizowany z zegarem SystemClock.elapsedRealtimeNano().
• [C-SR] ZALECANE jest, aby błąd synchronizacji sygnatury czasowej był krótszy niż 100 milisekund, a błąd synchronizacji sygnatury czasowej był niższy niż 1 milisekunda.
• Gdy aktywowanych jest kilka czujników, zużycie energii NIE POWINNO przekraczać sumy zużycia energii przez poszczególne czujniki.

Powyższa lista nie jest wyczerpująca. udokumentowane działanie pakietu Android SDK i dokumentacji Androida Open Source dotyczące czujników jest uznawane za miarodajne.

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który ma odpowiedni interfejs API dla zewnętrznych programistów, te elementy:

• [C-1-6] MUSI ustawić rozdzielczość inną niż 0 dla wszystkich czujników i zgłosić wartość za pomocą metody interfejsu API Sensor.getResolution().

Niektóre typy czujników są złożone, co oznacza, że mogą pochodzić z danych dostarczanych przez co najmniej jeden inny czujnik. (Na przykład czujnik orientacji i czujnika przyspieszenia liniowego).

Implementacje na urządzeniach:

• POWINNA SIĘ stosować te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w sekcji Typy czujników.

Jeśli implementacje urządzeń zawierają czujnik kompozytowy,:

• [C-2-1] MUSI zamontować czujnik w sposób opisany w dokumentacji Androida Open Source dotyczącej czujników złożonych.

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który ma odpowiedni interfejs API dla zewnętrznych programistów, a czujnik zgłasza tylko jedną wartość, to implementacje urządzenia:

• [C-3-1] MUSI ustawić rozdzielczość czujnika na 1 i zgłosić wartość za pomocą metody interfejsu API Sensor.getResolution().

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który obsługuje funkcję SensorAdditionalInfo#TYPE_VEC3_CALIBRATION, a czujnik jest widoczny dla programistów zewnętrznych, muszą one:

• [C-4-1] NIE MOŻE zawierać w dostarczanych danych żadnych stałych, określonych przez fabrykę parametrów kalibracji.

Jeśli implementacje urządzeń obejmują kombinację 3-osiowego akcelerometru, 3-osiowego żyroskopu lub czujnika magnetometru, są to:

• [C-SR] Zdecydowanie ZALECANE jest zapewnić stałe położenie względne akcelerometru, żyroskopu i magnesometru.Dzięki temu, jeśli urządzenie można przekształcać (np. składa się), osie czujnika pozostają wyrównane i spójne z układem współrzędnych czujnika we wszystkich możliwych stanach przekształcenia urządzenia.

7.3.1. Akcelerometr

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE jest użycie 3-osiowego akcelerometru.

Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr:

• [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-2] MUSI zaimplementować i zgłosić czujnik TYPE_ACCELEROMETER.
• [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Androida zgodnie z opisem w interfejsach API Androida.
• [C-1-4] MUSI być w stanie mierzyć od swobodnego spadania do 4-krotności grawitacji(4g) lub większej na dowolnej osi.
• Rozdzielczość [C-1-5] MUSI mieć co najmniej 12 bitów.
• [C-1-6] MUSI mieć odchylenie standardowe nie większe niż 0,05 m/s^, przy czym odchylenie standardowe powinno być obliczane na podstawie każdej osi dla próbek zebranych w okresie co najmniej 3 sekund z największą częstotliwością próbkowania.
• Zdecydowanie ZALECANE jest wdrożenie czujnika złożonego TYPE_SIGNIFICANT_MOTION.
• Zdecydowanie ZALECANE jest wdrożenie i zgłoszenie czujnika TYPE_ACCELEROMETER_UNCALIBRATED. Zdecydowanie ZALECANE są urządzenia z Androidem, które spełniają to wymaganie, dzięki czemu będą mogły zostać uaktualnione do kolejnej wersji platformy, w której może to stać się WYMAGANE.
• NALEŻY zaimplementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR i TYPE_STEP_COUNTER zgodnie z opisem w dokumentacji pakietu Android SDK.
• POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.
• Rozdzielczość powinna wynosić co najmniej 16 bitów.
• POWINNY być kalibrowane podczas używania, jeśli charakterystyka zmieni się w trakcie cyklu życia i zostanie skompensowana, oraz zachowaj parametry kompensacji między restartami urządzenia.
• POWINNA być kompensowana temperatura.

Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr oraz dowolny z czujników złożonych TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR i TYPE_STEP_COUNTER:

• [C-2-1] Suma ich zużycia energii MUSI zawsze wynosić mniej niż 4 mW.
• Gdy urządzenie jest w stanie dynamicznym lub statycznym, POWINIEN mieć poniżej 2 mW oraz 0,5 mW.

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

• [C-3-1] MUSI zaimplementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR] Zdecydowanie ZALECANE jest wdrożenie czujnika kompozytowego TYPE_GAME_ROTATION_VECTOR.

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

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

7.3.2 Magnetometr

Implementacje na urządzeniach:

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

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

• [C-1-1] MUSI zamocować czujnik TYPE_MAGNETIC_FIELD.
• [C-1-2] MUSI zgłaszać zdarzenia z częstotliwością co najmniej 10 Hz i POWINNY zgłaszać zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Androida zgodnie z opisem w interfejsach API Androida.
• [C-1-4] MUSI być w stanie zmierzyć wartość od -900 μT do +900 μT na każdej osi bez nasycenia.
• [C-1-5] MUSI mieć wartość przesunięcia twardego żelaza na poziomie mniejszą niż 700 μT, a magnetometr musi mieć wartość poniżej 200 μT przez umieszczanie magnetometru z dala od dynamicznych (wywoływanych prądem) i statycznych (wywoływanych przez magnesem) pól magnetycznych.
• [C-1-6] MUSI mieć rozdzielczość równą lub większą niż 0,6 μT.
• [C-1-7] MUSI obsługiwać kalibrację online i kompensację odchylenia twardego żelaza oraz zachowywać parametry kompensacji między restartami urządzenia.
• [C-1-8] MUSI mieć kompensację miękkiego żelaza – kalibrację można przeprowadzić podczas używania lub produkcji urządzenia.
• [C-1-9] MUSI mieć odchylenie standardowe obliczone na podstawie poszczególnych osi dla próbek zebranych w okresie co najmniej 3 sekund z największą częstotliwością próbkowania, nie większą niż 1, 5 μT; Odchylenie standardowe NIE powinno być większe niż 0,5 μT.
• [C-SR] Zdecydowanie ZALECANE jest wdrożenie czujnika TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

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

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

• MOŻESZ zastosować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Jeśli urządzenia są wyposażone w 3-osiowy magnetometr, akcelerometr i czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR:

• [C-3-1] MUSI zużywać mniej niż 10 mW.
• Gdy czujnik jest zarejestrowany w trybie wsadowym z częstotliwością 10 Hz, NALEŻY zużywać mniej niż 3 mW.

7.3.3 GPS

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE jest użycie odbiornika GPS/GNSS.

Jeśli implementacje urządzeń obejmują odbiornik GPS/GNSS i zgłaszają takie możliwości aplikacjom za pomocą flagi funkcji android.hardware.location.gps, muszą one:

• [C-1-1] MUSI obsługiwać dane wyjściowe lokalizacji z częstotliwością co najmniej 1 Hz, gdy jest wymagane przez LocationManager#requestLocationUpdate.
• [C-1-2] MUSI określić lokalizację na otwartym niebie (silne sygnały, niedostateczna ścieżka wielościeżkowa, HDOP < 2) w ciągu 10 sekund (szybszy czas do pierwszej naprawy) przy połączeniu z internetem o szybkości 0,5 Mb/s lub szybszej. Wymóg ten można zazwyczaj spełnić, stosując technikę wspomaganego lub przewidywanego GPS/GNSS w celu zminimalizowania czasu blokady GPS/GNSS (dane pomocnicze obejmują czas odniesienia, lokalizację referencyjną oraz satelitarne dane efemeryczne/zegar).
  • [C-1-6] Po obliczeniu takiej lokalizacji implementacje urządzenia MUSZĄ określić jego lokalizację na niebie w ciągu 5 sekund, gdy żądania lokalizacji są ponownie uruchamiane, maksymalnie do godziny po początkowym obliczeniu lokalizacji, nawet jeśli kolejne żądanie jest wysyłane bez połączenia do transmisji danych lub po wyłączeniu i włączeniu zasilania.

• Na otwartym niebie po określeniu lokalizacji, gdy jesteś w miejscu lub poruszasz się z przyspieszeniem poniżej 1 metra na sekundę do kwadratu:

  • [C-1-3] MUSI określić lokalizację z dokładnością do 20 metrów i z prędkością do 0, 5 metra na sekundę, w co najmniej 95% przypadków.
  • [C-1-4] MUSI jednocześnie śledzić i raportować za pomocą GnssStatus.Callback co najmniej 8 satelitów z 1 konstelacji.
  • MUSI być w stanie jednocześnie śledzić co najmniej 24 satelity pochodzące z wielu konstelacji (np. GPS + przynajmniej jeden Glonass, Beidou, Galileo).
  • [C-SR] Zdecydowanie ZALECANE jest dalsze wyświetlanie normalnych danych o lokalizacji GPS/GNSS przy użyciu interfejsu API GNSS Location Provider API podczas alarmowego połączenia telefonicznego.
  • [C-SR] Zdecydowanie ZALECANE jest raportowanie pomiarów GNSS ze wszystkich śledzonych konstelacji (informacja podana w komunikatach GnssStatus), z wyjątkiem SBAS.
  • [C-SR] Zdecydowanie ZALECANE jest raportowanie AGC i częstotliwość pomiaru GNSS.
  • [C-SR] Zdecydowanie ZALECANE jest raportowanie wszystkich szacunków dokładności (w tym położenia, prędkości i pionu) w ramach każdej lokalizacji GPS/GNSS.
  • [C-SR] Zdecydowanie ZALECANE jest zgłaszanie pomiarów GNSS, gdy tylko zostaną wykryte, nawet jeśli lokalizacja określona na podstawie GPS/GNSS nie jest jeszcze raportowana.
  • [C-SR] Zdecydowanie ZALECANE są raportowanie pseudozakresów i wskaźników pseudozakresów GNSS, że w warunkach na niebie po określeniu lokalizacji, gdy nieruchomo lub poruszasz się z przyspieszeniem poniżej 0, 2 metra na sekundę do kwadratu, wystarczają do obliczenia pozycji z dokładnością do 20 metrów i z prędkością co najmniej 0, 2 metra na sekundę z dokładnością co najmniej 0, 2 metra na sekundę.

7.3.4 Żyroskop

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE jest użycie czujnika żyroskopu.

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

• [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-2] NALEŻY zaimplementować czujnik TYPE_GYROSCOPE. ZDECYDOWANIE ZALECANA jest też do zastosowania czujnika TYPE_GYROSCOPE_UNCALIBRATED.
• Rozdzielczość [C-1–4] MUSI mieć co najmniej 12 bitów, a powinna mieć rozdzielczość co najmniej 16 bitów.
• [C-1-5] MUSI mieć kompensację temperatury.
• [C-1-6] MUSI być skalibrowany i skompensowany podczas używania. Zachowaj parametry kompensacji między restartami urządzenia.
• [C-1-7] MUSI mieć wariancję nie większą niż 1e-7 rad^2 / s^2 na Hz (wariancja na Hz lub rad^2 / s). Wariancja może się zmieniać wraz z częstotliwością próbkowania, ale MUSI być ograniczana przez tę wartość. Inaczej mówiąc, przy pomiarze wariancji żyroskopu przy częstotliwości próbkowania 1 Hz POWINIEN wynosić nie więcej niż 1e–7 rad^2/s^2.
• [SR] ZALECANE jest, aby błąd kalibracji wynosił mniej niż 0,01 rad/s, gdy urządzenie pozostaje w temperaturze pokojowej.
• POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.

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

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

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

• [C-3-1] MUSI zaimplementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR] Zdecydowanie ZALECANE jest wdrożenie czujnika kompozytowego TYPE_GAME_ROTATION_VECTOR.

7.3.5 barometr;

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE jest dodanie barometru (czujnika ciśnienia powietrza).

Jeśli implementacje urządzeń obejmują barometr:

• [C-1-1] MUSI zaimplementować i zgłosić czujnik TYPE_PRESSURE.
• [C-1-2] MUSI być w stanie przesyłać zdarzenia z częstotliwością 5 Hz lub większą.
• [C-1-3] MUSI mieć kompensację temperatury.
• [SR] Zdecydowanie ZALECANE jest raportowanie ciśnienia w zakresie od 300 hPa do 1100 hPa.
• Całkowita dokładność 1hPa.
• MUSI mieć względną dokładność 0,12 hPa w zakresie 20 hPa (odpowiednik dokładności ok. 1 m na poziomie ok. 200 m na poziomie morza).

7.3.6 Thermometer

Jeśli urządzenia są wyposażone w termometr otoczenia (czujnik temperatury):

• [C-1-1] MUSI zdefiniować parametr SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury otoczenia, a czujnik MUSI mierzyć temperaturę otoczenia (w pomieszczeniu lub kabinie pojazdu) w miejscu, w którym użytkownik wchodzi w interakcję z urządzeniem, wyrażoną w stopniach Celsjusza.

Jeśli implementacje urządzeń zawierają czujnik termometru, który mierzy temperaturę inną niż temperatura otoczenia (np. temperaturę procesora):

• [C-2-1] NIE MOŻE definiować parametru SENSOR_TYPE_AMBIENT_TEMPERATURE dla czujnika temperatury.

7.3.7 Fotometr

• Urządzenia MOGĄ zawierać fotometr (czujnik jasności otoczenia).

7.3.8 Czujnik zbliżeniowy

• Urządzenia MOGĄ zawierać czujnik zbliżeniowy.

Jeśli urządzenia są wyposażone w czujnik zbliżeniowy:

• [C-1-1] MUSI mierzyć bliskość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI wykrywać obiekty znajdujące się blisko ekranu, ponieważ jego głównym celem jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacje urządzeń obejmują czujnik zbliżeniowy o innej orientacji, NIE MOŻE być dostępny za pomocą tego interfejsu API.
• [C-1-2] MUSI mieć co najmniej 1 bit z dokładnością.

7.3.9. Czujniki wysokiej jakości

Jeśli implementacje urządzeń obejmują zestaw czujników o wyższej jakości (jak opisano w tej sekcji), i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI identyfikować możliwość za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

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

• [C-2-1] MUSI mieć czujnik TYPE_ACCELEROMETER, który:

  • MUSI mieć zakres pomiarowy od -8 g do +8 g. ZALECANY jest zakres pomiarów od -16 g do +16 g.
  • Rozdzielczość pomiaru MUSI mieć wartość co najmniej 2048 LSB/g.
  • Wymagana jest minimalna częstotliwość pomiaru 12,5 Hz lub mniejsza.
  • MUSI mieć maksymalną częstotliwość pomiaru 400 Hz lub większą. POWINNA obsługiwać kanał SensorDirectChannel RATE_VERY_FAST.
  • Poziom szumu pomiarowego MUSZĄ być większy niż 400 μg/√Hz.
  • MUSISZ zaimplementować typ czujnika bez wybudzania z możliwością buforowania wynoszącą co najmniej 3000 zdarzeń.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 3 mW.
  • [C-SR] Zdecydowanie zalecana jest przepustowość pomiaru na poziomie 3 dB na poziomie co najmniej 80% częstotliwości Nyquist oraz spektrum szumu białego w ramach tej przepustowości.
  • TREŚCI POWINNY być testowane przy przyspieszeniu losowy spacer o wartości poniżej 30 μg √Hz w temperaturze pokojowej.
  • MUSISZ mieć zmianę odchylenia w porównaniu z temperaturą na poziomie ≤ +/- 1 mg/°C.
  • Optymalna nieliniowość w zakresie ≤ 0,5% oraz zmiana czułości względem temperatury na poziomie ≤ 0,03%/C°.
  • Czułość krzyżowa powinna wynosić < 2,5 % i różnica czułości na wielu osiach < 0,2% w zakresie temperatur działania urządzenia.

• [C-2-2] MUSI mieć TYPE_ACCELEROMETER_UNCALIBRATED z takimi samymi wymaganiami dotyczącymi jakości jak TYPE_ACCELEROMETER.

• [C-2-3] MUSI mieć czujnik TYPE_GYROSCOPE, który:

  • MUSI mieć zakres pomiaru od -1000 do +1000 dps.
  • Rozdzielczość pomiaru MUSI mieć co najmniej 16 LSB/dps.
  • Wymagana jest minimalna częstotliwość pomiaru 12,5 Hz lub mniejsza.
  • MUSI mieć maksymalną częstotliwość pomiaru 400 Hz lub większą. POWINNA obsługiwać kanał SensorDirectChannel RATE_VERY_FAST.
  • Poziom szumu pomiarowego MUSZĄ być większy niż 0,014°/s/√Hz.
  • [C-SR] Zdecydowanie zalecana jest przepustowość pomiaru na poziomie 3 dB na poziomie co najmniej 80% częstotliwości Nyquist oraz spektrum szumu białego w ramach tej przepustowości.
  • Częstotliwość losowych spacerów MUSI być testowana w temperaturze pokojowej na poziomie niższym niż 0,001°/s √ Hz.
  • MUSI mieć zmianę odchylenia w porównaniu z temperaturą na poziomie ≤ +/- 0,05°/ s / °C.
  • TRZEBA zmienić czułość w porównaniu z temperaturą na poziomie ≤ 0,02% / °C.
  • Optymalny rozmiar nieliniowości musi wynosić ≤ 0,2%.
  • Gęstość szumu powinna wynosić ≤ 0,007°/s/√ Hz.
  • Błąd kalibracji powinien wynosić mniej niż 0,002 rad/s w zakresie temperatur od 10 do 40 °C, gdy urządzenie jest nieruchome.
  • Czułość g powinna być mniejsza niż 0,1°/s/g.
  • Czułość krzyżowa powinna wynosić < 4,0 % i różnica czułości na wielu osiach < 0,3% w zakresie temperatur działania urządzenia.

• [C-2-4] MUSI mieć TYPE_GYROSCOPE_UNCALIBRATED z takimi samymi wymaganiami dotyczącymi jakości jak TYPE_GYROSCOPE.

• [C-2-5] MUSI mieć czujnik TYPE_GEOMAGNETIC_FIELD, który:

  • MUSI mieć zakres pomiaru od -900 do +900 μT.
  • MUSI mieć rozdzielczość pomiaru wynoszącą co najmniej 5 LSB/uT.
  • MUSI mieć minimalną częstotliwość pomiaru 5 Hz lub mniejszą.
  • Maksymalna częstotliwość pomiaru MUSI 50 Hz lub większa.
  • MUSI zawierać szum pomiarowy nie większy niż 0,5 uT.

• [C-2-6] MUSI mieć TYPE_MAGNETIC_FIELD_UNCALIBRATED z tymi samymi wymaganiami dotyczącymi jakości co TYPE_GEOMAGNETIC_FIELD, a także:

  • MUSISZ zaimplementować typ czujnika bez wybudzania z możliwością buforowania wynoszącą co najmniej 600 zdarzeń czujnika.
  • [C-SR] Zdecydowanie ZALECANE jest użycie widma szumu białego 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:

  • MUSI mieć zakres pomiaru od 300 do 1100 hPa.
  • Rozdzielczość pomiaru MUSI mieć co najmniej 80 LSB/hPa.
  • Minimalna częstotliwość pomiaru musi wynosić 1 Hz lub mniejszą.
  • Maksymalna częstotliwość pomiaru MUSI wynosić 10 Hz lub więcej.
  • Poziom szumu pomiarowego MUSI być większy niż 2 Pa/√ Hz.
  • Czujnik MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 300 zdarzeń.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 2 mW.
• [C-2-8] MUSI mieć czujnik TYPE_GAME_ROTATION_VECTOR.
• [C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:
  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
• [C-2-10] MUSI mieć czujnik TYPE_STEP_DETECTOR, który:
  • Czujnik MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 100 zdarzeń.
  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 4 mW.
• [C-2-11] MUSI mieć czujnik TYPE_STEP_COUNTER, który:
  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
• [C-2-12] MUSI mieć czujnik TILT_DETECTOR, który:
  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
• [C-2-13] Sygnatura czasowa tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr, żyroskop i magnetometr MUSI zawierać się w odległości maksymalnie 2, 5 milisekundy. Sygnatura czasowa tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr i żyroskop POWINIEN być oddalona od siebie w odległości maksymalnie 0,25 milisekundy.
• [C-2-14] MUSI mieć sygnatury czasowe zdarzeń z czujnika żyroskopu z tego samego okresu co podsystem kamery i z dokładnością do 1 milisekundy do wystąpienia błędu.
• [C-2-15] MUSI dostarczyć próbki do aplikacji w ciągu 5 milisekund od momentu, gdy dane są dostępne w dowolnym z powyższych czujników fizycznych do aplikacji.
• [C-2-16] NIE MOŻE generować mocy o mocy większej niż 0,5 mW, gdy urządzenie jest statyczne, oraz 2,0 mW, gdy urządzenie jest w ruchu, jeśli 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 zainstalowany, MUSI mieć co najmniej 100 zdarzeń na buforze.

Wszystkie wymagania dotyczące zużycia energii opisane w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje on moc wykorzystywaną przez cały łańcuch czujników – czujnik, dowolny układ pomocniczy, dowolny dedykowany system przetwarzania czujników itp.

Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników:

• [C-3-1] MUSI prawidłowo zadeklarować obsługę typów kanałów bezpośrednich i poziomu stawek bezpośrednich podwładnych za pomocą interfejsów API isDirectChannelTypeSupported i getHighestDirectReportRateLevel.
• [C-3-2] MUSI obsługiwać co najmniej 1 z 2 typów kanałów bezpośrednich czujnika w przypadku wszystkich czujników, które deklarują obsługę kanału bezpośredniego.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• POWINNA obsługiwać raportowanie zdarzeń przez kanał bezpośredni czujnika głównego czujnika (wariant wybudzenia) tych typów:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Czujniki biometryczne

Więcej informacji na temat mierzenia zabezpieczeń odblokowywania biometrycznego znajdziesz w dokumentacji dotyczącej pomiaru zabezpieczeń biometrycznych.

Jeśli implementacje urządzeń obejmują bezpieczny ekran blokady:

• POWINNA zawierać czujnik biometryczny

Czujniki biometryczne mogą być klasyfikowane jako klasa 3 (wcześniej Silne), Klasa 2 (wcześniej słaba) lub klasa 1 (wcześniej Wygoda) na podstawie współczynnika akceptacji i podszywania się pod inne osoby, a także bezpieczeństwa potoku biometrycznego. Klasyfikacja ta określa możliwości czujnika biometrycznego, które może współpracować z platformą i aplikacjami innych firm. Czujniki są domyślnie klasyfikowane jako klasa 1. Jeśli mają zostać sklasyfikowane jako klasa 2 lub klasa 3, muszą spełniać dodatkowe wymagania opisane poniżej. Zarówno biometria klasy 2, jak i klasy 3 mają dodatkowe możliwości, które opisaliśmy poniżej.

Jeśli implementacje urządzeń udostępnią czujnik biometryczny aplikacjom innych firm za pomocą android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt i android.provider.Settings.ACTION_BIOMETRIC_ENROLL, będą one:

• [C-4-1] MUSI spełniać wymagania dotyczące biometrii klasy 3 lub klasy 2 zdefiniowane w tym dokumencie.
• [C-4-2] MUSI rozpoznawać i uwzględniać każdą nazwę parametru zdefiniowaną jako stałą w klasie Authenticators oraz wszelkich ich kombinacji. I odwrotnie, NIE MOŻE spełniać ani rozpoznawać stałych liczb całkowitych przekazywanych do metod canAuthenticate(int) i setAllowedAuthenticators(int), które nie jest zgodne ze stałymi publicznymi w narzędziu Authenticator, oraz ich kombinacjami.
• [C-4-3] MUSI zaimplementować działanie ACTION_BIOMETRIC_ENROLL na urządzeniach korzystających z biometrii klasy 3 lub klasy 2. To działanie MUSI zawierać tylko punkty wejścia do rejestracji w przypadku danych biometrycznych klasy 3 lub klasy 2.

Jeśli implementacje urządzeń obsługują pasywną biometrię:

• [C-5-1] Domyślnie MUSI wymagać dodatkowego potwierdzenia (np. naciśnięcia przycisku).
• [C-SR] Zdecydowanie ZALECANE jest ustawienie ustawienia pozwalającego użytkownikom na zastępowanie preferencji aplikacji i zawsze wymagać towarzyszącego kroku potwierdzenia.
• [C-SR] Zdecydowanie ZALECANE jest zabezpieczenie działania potwierdzającego w taki sposób, aby system operacyjny lub naruszenie zabezpieczeń jądra nie mogły zostać użyte przez kogoś innego. Na przykład oznacza to, że działanie potwierdzenia na podstawie fizycznego przycisku jest kierowane przez styk wejściowe/wyjściowe ogólnego przeznaczenia (GPIO) bezpiecznego elementu (SE), którego nie można wywołać inaczej niż przez naciśnięcie fizycznego przycisku.
• [C-5-2] MUSI dodatkowo zaimplementować proces uwierzytelniania niejawnego (bez kroku potwierdzenia) odpowiadający funkcji setConfirmationRequired(boolean), którą aplikacje mogą używać w procesach logowania.

Jeśli urządzenia są wyposażone w kilka czujników biometrycznych:

• [C-SR] Zdecydowanie ZALECANE jest konieczność potwierdzenia tylko 1 danych biometrycznych podczas uwierzytelniania (np. jeśli na urządzeniu są dostępne zarówno odciski palców, jak i czujniki twarzy, po potwierdzeniu dowolnego z nich należy wysłać onAuthenticationSucceeded).

Aby implementacje urządzeń umożliwiały dostęp aplikacji innych firm do kluczy magazynu kluczy:

• [C-6-1] MUSI spełniać wymagania dotyczące klasy 3 zdefiniowane w tej sekcji.
• [C-6-2] MUSI przedstawiać tylko dane biometryczne klasy 3, gdy uwierzytelnianie wymaga BIOMETRIC_STRONG lub uwierzytelnianie jest wywoływane za pomocą CryptoObject.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 1 (dawniej Wygoda), muszą:

• [C-1-1] MUSI mieć współczynnik fałszywych akceptacji niższy niż 0,002%.
• [C-1-2] MUSI ujawniać, że ten tryb może być mniej bezpieczny niż silny kod PIN, wzór lub hasło i wyraźnie informować o ryzyku jego włączenia, jeśli odsetek użytkowników, którzy podszywają się pod innych, i podszywanie się pod innych, przekracza 7%, zgodnie z pomiarami protokołów testów biometrycznych Androida.
• [C-1-3] W przypadku weryfikacji biometrycznej MUSISZ próbować ograniczyć liczbę żądań przez co najmniej 30 sekund po 5 fałszywych próbach. Fałszywy test oznacza próbę o dostatecznej jakości zapisu danych (BIOMETRIC_ACQUIRED_GOOD), która nie odpowiada zarejestrowanej biometrii.
• [C-1-4] MUSI powstrzymywać dodawanie nowych danych biometrycznych bez wcześniejszego budowania łańcucha zaufania przez potwierdzenie istniejących danych logowania lub dodanie nowych danych uwierzytelniających urządzenia (kodu PIN, wzoru lub hasła) zabezpieczonego przez TEE. projekt Android Open Source Project zapewnia w strukturze odpowiedni mechanizm.
• [C-1-5] MUSI całkowicie usunąć wszystkie dane biometryczne umożliwiające identyfikację użytkownika po usunięciu jego konta (m.in. po przywróceniu ustawień fabrycznych).
• [C-1-6] MUSI uwzględniać poszczególne oznaczenia biometryczne (tj. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE lub DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] MUSI wymagać od użytkownika przeprowadzenia zalecanego podstawowego uwierzytelniania (np. kodu PIN, wzoru, hasła) co 24 godziny lub częściej na nowych urządzeniach z Androidem w wersji 10 – co 72 godziny lub częściej w przypadku urządzeń, które przechodzą z wcześniejszej wersji Androida na wyższą wersję.

• [C-1-8] MUSI wymagać od użytkownika wykonania zalecanego podstawowego uwierzytelniania (np. kodu PIN, wzoru, hasła) po wystąpieniu jednej z następujących sytuacji:

  • 4-godzinny limit czasu bezczynności LUB
  • 3 nieudane próby uwierzytelnienia biometrycznego.
  • Limit czasu bezczynności i liczba nieudanych uwierzytelniania są resetowane po potwierdzeniu danych logowania urządzenia.

  Uaktualnienie urządzeń z wcześniejszej wersji Androida może być zwolnione z obowiązku spełnienia wymogów ustawy C-1–8. * [C-SR] Zdecydowanie ZALECANE jest użycie logiki w ramach platformy Android Open Source Project do egzekwowania w przypadku nowych urządzeń ograniczeń określonych w porządkach [C-1-7] i [C-1-8]. * [C-SR] Zdecydowanie ZALECANE jest, aby wskaźnik fałszywych odrzuceń wynosił mniej niż 10%, zgodnie z pomiarem na urządzeniu. * [C-SR] Zdecydowanie ZALECANE jest opóźnienie poniżej 1 sekundy, mierzone od momentu wykrycia biometrii do momentu odblokowania ekranu w przypadku każdego zarejestrowanego urządzenia biometrycznego.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 2 (wcześniej słabe), muszą one:

• [C-2-1] MUSI spełniać wszystkie wymagania dotyczące klasy 1 powyżej.
• [C-2-2] MUSI mieć współczynnik akceptacji fałszywych użytkowników nie wyższy niż 20%, zgodnie z pomiarami protokołów testów biometrycznych Androida.
• [C-2-3] MUSI przeprowadzić dopasowywanie biometryczne w wyizolowanym środowisku wykonawczym poza środowiskiem wykonawczym Androida i przestrzenią jądra, takim jak Trusted Execution Environment (TEE), lub na układzie z bezpiecznym kanałem łączącym środowisko wykonawcze od izolowanego środowiska wykonawczego.
• [C-2-4] MUSI mieć zaszyfrowane i uwierzytelnione kryptograficznie wszystkie dane umożliwiające identyfikację, tak aby nie można było ich pozyskać, odczytać ani zmienić poza wyodrębnionym środowiskiem wykonawczym lub elementem z bezpiecznym kanałem prowadzącym do wyodrębnionego środowiska wykonawczego, jak opisano w wytycznych dotyczących implementacji w witrynie projektu Android Open Source.
• [C-2-5] W przypadku uwierzytelniania biometrycznego lub rejestracji za pomocą aparatu biometrycznych:
  • MUSI obsługiwać kamerę w trybie, który uniemożliwia odczyt i zmienianie klatek kamery poza środowiskiem wykonawczym lub układowi z bezpiecznym kanałem prowadzącym do izolowanego środowiska wykonawczego.
  • W przypadku rozwiązań RGB z jedną kamerą ramki kamery MOGĄ być czytelne poza osobnym środowiskiem wykonawczym na potrzeby operacji takich jak podgląd w celu rejestracji, ale NIE MOŻNA tego zmieniać.
• [C-2-6] NIE MOŻE umożliwiać aplikacjom innych firm rozróżniania poszczególnych rejestracji biometrycznych.
• [C-2-7] NIE MOŻE umożliwiać niezaszyfrowanego dostępu do identyfikowalnych danych biometrycznych ani żadnych danych uzyskanych z nich (takich jak wektory dystrybucyjne) do podmiotu przetwarzającego aplikację poza kontekstem TEE.

• [C-2-8] MUSI mieć bezpieczny potok przetwarzania, dzięki któremu zabezpieczenia systemu operacyjnego lub jądra nie pozwalają na bezpośrednie wstrzykiwanie danych w celu fałszywego uwierzytelnienia użytkownika.

  Jeśli implementacje urządzeń zostały już wdrożone na starszej wersji Androida i nie mogą spełnić wymagania C-2-8 w ramach aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z tego wymogu.

• [C-SR] Zdecydowanie ZALECANE jest włączenie wykrywania życia we wszystkich modalnościach biometrycznych i wykrywania uwagi na potrzeby biometrii twarzy.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 3 (wcześniej Silne), muszą one:

• [C-3-1] MUSI spełniać wszystkie wymagania powyższej klasy 2 z wyjątkiem urządzeń [C-1-7] i [C-1-8]. Uaktualnienie urządzeń z wcześniejszej wersji Androida nie jest zwolnione z obowiązku posiadania licencji C-2-7.
• [C-3-2] MUSI mieć implementację magazynów kluczy wspieranych sprzętowo.
• [C-3-3] MUSI mieć wskaźnik akceptacji i podszywać się pod użytkowników na poziomie nie wyższym niż 7%, zgodnie z pomiarami protokołów testów biometrycznych Androida.
• [C-3-4] MUSI wymagać od użytkownika przeprowadzenia zalecanego podstawowego uwierzytelniania (np. kodu PIN, wzoru, hasła) co 72 godziny lub częściej.

7.3.12. Czujnik pozycji

Implementacje na urządzeniach:

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

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

• [C-1-1] MUSI zaimplementować i zgłosić czujnik TYPE_POSE_6DOF.
• [C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.

7.3.13. Czujnik kąta nachylenia

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

• [C-1-1] MUSI wdrożyć i zgłosić stronę TYPE_HINGLE_ANGLE.
• [C-1-2] MUSI obsługiwać co najmniej 2 odczyty od 0 do 360 stopni (włącznie, tzn. w tym od 0 do 360 stopni).
• [C-1-3] MUSI zwrócić czujnik wybudzenia urządzenia getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4 Połączenie transmisji danych

7.4.1 Telefonia

Termin „telefonia” jest używany w interfejsach API Androida, a ten dokument odnosi się w szczególności do sprzętu do nawiązywania połączeń głosowych i wysyłania SMS-ów przez sieć GSM lub CDMA. Choć w tych połączeniach głosowych może być włączona funkcja przełączania pakietów, ale nie jest to konieczne, do celów związanych z Androidem uważa się je za niezależne od wszelkich transmisji danych, które mogą być realizowane w tej samej sieci. Innymi słowy, funkcje „telefonii” i interfejsy API w Androidzie odnoszą się w szczególności do połączeń głosowych i SMS-ów. Na przykład urządzenia, które nie mogą nawiązywać połączeń ani wysyłać/odbierać SMS-ów, nie są uznawane za urządzenia telefoniczne, niezależnie od tego, czy korzystają z sieci komórkowej do przesyłania danych.

• Android MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami, które nie są telefonami.

Jeśli implementacje urządzeń obejmują usługę telefonii GSM lub CDMA:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.telephony i inne flagi funkcji podrzędnych zgodnie z technologią.
• [C-1-2] MUSI wdrożyć pełną obsługę interfejsu API dla danej technologii.

Jeśli implementacje urządzenia nie obejmują sprzętu telefonicznego:

• [C-2-1] MUSI wdrożyć pełne interfejsy API w trybie bezobsługowym.

Jeśli implementacje urządzeń obsługują karty eUICC lub eSIM/wbudowane karty SIM i zawierają zastrzeżony mechanizm udostępniania funkcji eSIM deweloperom zewnętrznym, muszą:

• [C-3-1] MUSI zawierać pełną implementację EuiccManager API.

7.4.1.1 Zgodność z blokadami numerów

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

• [C-1-1] MUSI obsługiwać blokowanie numerów
• [C-1-2] MUSI w pełni zaimplementować usługę BlockedNumberContract i odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-3] MUSI blokować wszystkie połączenia i wiadomości z numeru telefonu w polu „BlockedNumberProvider” bez interakcji z aplikacjami. Jedynym wyjątkiem jest sytuacja, w której blokowanie numerów jest tymczasowo zniesione zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-4] W przypadku zablokowanego połączenia NIE MOŻE zapisywać danych do dostawcy rejestru połączeń na platformie.
• [C-1-5] NIE MOŻE pisać do dostawcy usług telefonicznych w przypadku zablokowanej wiadomości.
• [C-1-6] MUSI wdrożyć interfejs zarządzania zablokowanymi numerami, który jest otwierany z intencją zwracaną przez metodę TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NIE MOŻE umożliwiać użytkownikom pomocniczym wyświetlania ani edytowania zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że główny użytkownik ma pełną kontrolę nad poszczególnymi instancjami usług telefonicznych na urządzeniu. Każdy interfejs związany z blokowaniem MUSI być ukryty dla użytkowników pomocniczych, a lista zablokowanych MUSI być respektowana.
• W przypadku aktualizacji Androida do wersji 7.0 NALEŻY przenieść zablokowane numery do dostawcy.

7.4.1.2. Telecom API

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

• [C-1-1] MUSI obsługiwać interfejsy API ConnectionService opisane w pakiecie SDK.
• [C-1-2] MUSI wyświetlić nowe połączenie przychodzące i zapewnić użytkownikom zgodę na odebranie lub odrzucenie połączenia przychodzącego, gdy jest on w trakcie trwającego połączenia wykonywanego przez aplikację innej firmy, która nie obsługuje funkcji blokady określonej w CAPABILITY_SUPPORT_HOLD.
• [C-1-3] MUSI mieć aplikację implementującą InCallService.

• [C-SR] Zdecydowanie ZALECANE jest powiadamianie użytkownika, że odebranie połączenia przychodzącego spowoduje przerwanie trwającego połączenia.

  Implementacja AOSP spełnia te wymagania dzięki wyświetlaniu powiadomienia HUD, które informuje użytkownika, że odebranie połączenia przychodzącego spowoduje odrzucenie drugiego połączenia.

• [C-SR] Zdecydowanie ZALECANE jest wstępne wczytywanie domyślnej aplikacji telefonu, która wyświetla wpis z rejestru połączeń i nazwę aplikacji innej firmy w rejestrze połączeń, gdy aplikacja innej firmy ustawi klucz dodatków EXTRA_LOG_SELF_MANAGED_CALLS na PhoneAccount na true.

• [C-SR] Zdecydowanie ZALECANE jest obsługa zdarzeń KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK zestawu słuchawkowego w interfejsach API android.telecom w ten sposób:
  • Wywołaj Connection.onDisconnect(), gdy zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia podczas trwającej rozmowy.
  • Wywołaj Connection.onAnswer(), gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia.
  • Wywołaj Connection.onReject(), gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia.
  • Przełącz stan wyciszenia elementu CallAudioState.

7.4.2 IEEE 802.11 (Wi-Fi)

Implementacje na urządzeniach:

• POWINNO obsługiwać co najmniej jedną formę standardu 802.11.

Jeśli implementacje urządzeń obejmują obsługę standardu 802.11 i udostępniają tę funkcję aplikacji innej firmy:

• [C-1-1] MUSI wdrożyć odpowiedni interfejs API Androida.
• [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.wifi.
• [C-1-3] MUSI zaimplementować interfejs API multicast w sposób opisany w dokumentacji pakietu SDK.
• [C-1-4] MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) podczas działania, w tym:
  • Nawet wtedy, gdy ekran nie jest aktywny.
  • Dotyczy urządzeń Android TV, nawet w trybie gotowości.
• [C-1-5] NIE MOŻE traktować wywołania metody interfejsu API WifiManager.enableNetwork() jako wystarczającego wskaźnika do zmiany aktywnej obecnie usługi Network, która jest domyślnie używana do obsługi ruchu w aplikacjach i jest zwracana przez metody interfejsu API ConnectivityManager, takie jak getActiveNetwork i registerDefaultNetworkCallback. Oznacza to, że MOGĄ wyłączyć dostęp do internetu zapewniany przez innego dostawcę (np. sieć komórkową) tylko wtedy, gdy uda mu się upewnić, że sieć Wi-Fi zapewnia dostęp do internetu.
• [C-1-6] Są Zdecydowanie ZALECANE, gdy po wywołaniu metody interfejsu API ConnectivityManager.reportNetworkConnectivity() należy ponownie ocenić dostęp do internetu na urządzeniu Network, a gdy po sprawdzeniu okaże się, że bieżący Network nie zapewnia już dostępu do internetu, należy przełączyć się na inną dostępną sieć (np. mobilną transmisję danych), która zapewnia dostęp do internetu.
• [C-SR] Zdecydowanie ZALECANE jest randomizowanie źródłowego adresu MAC i numeru sekwencyjnego żądań ramek sond, raz na początku każdego skanowania, gdy STA jest odłączone.
  • Każda grupa ramek żądania sondowania, która zawiera 1 skanowanie, powinna korzystać z 1 spójnego adresu MAC (NIE POWINNY być randomizowane adresy MAC w trakcie skanowania).
  • Numer sekwencyjny żądania sond powinien powtarzać się w normalny sposób (sekwency) w kolejnych żądaniach sondowania podczas skanowania.
  • Numer sekwencyjny żądania sond powinien być randomizowany między ostatnim żądaniem sondowania a pierwszym żądaniem sondowania w kolejnym skanowaniu.
• [C-SR] Są Zdecydowanie ZALECANE, gdy STA jest odłączone, aby w ramkach żądania sond mogły zostać tylko udostępnione te elementy:
  • Zestaw parametrów identyfikatora SSID (0)
  • Zestaw parametrów DS (3)

Jeśli implementacje urządzeń obejmują obsługę trybu oszczędzania energii Wi-Fi zgodnie ze standardem IEEE 802.11:

• [C-3-1] MUSI wyłączyć tryb oszczędzania energii Wi-Fi za każdym razem, 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(), gdy blokada jest aktywna.
• [C-3-2] Średnie opóźnienie przesyłania danych w obie strony między urządzeniem a punktem dostępu, gdy urządzenie jest w trybie blokady Wi-Fi z niskim opóźnieniem (WIFI_MODE_FULL_LOW_LATENCY) MUSI być mniejsze niż opóźnienie w trybie WIFI_MODE_FULL_HIGH_PERF o wysokiej wydajności.
• [C-SR] Zdecydowanie ZALECANE jest ograniczenie opóźnień przesyłania danych w obie strony po uzyskaniu i zastosowaniu blokad o krótkim czasie oczekiwania (WIFI_MODE_FULL_LOW_LATENCY).

Jeśli urządzenia obsługują Wi-Fi i używają Wi-Fi do skanowania lokalizacji, to:

• [C-2-1] MUSI udostępniać liczbę użytkowników, aby włączyć lub wyłączyć wartość odczytywaną za pomocą metody interfejsu API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementacje na urządzeniach:

• POWINNA obsługiwać technologię Wi-Fi Direct (typu Wi-Fi peer-to-peer).

Jeśli implementacje urządzeń obsługują Wi-Fi Direct:

• [C-1-1] MUSI zaimplementować odpowiedni interfejs API Androida w sposób opisany w dokumentacji pakietu SDK.
• [C-1-2] MUSI zgłosić funkcję sprzętową android.hardware.wifi.direct.
• [C-1-3] MUSI obsługiwać normalne działanie Wi-Fi.
• [C-1-4] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Direct.

7.4.2.2. Konfiguracja bezpośredniego linku Wi-Fi

Implementacje na urządzeniach:

• POWINNA spełniać obsługę konfiguracji bezpośredniego linku Wi-Fi (TDLS) zgodnie z opisem w dokumentacji pakietu Android SDK.

Jeśli implementacje urządzeń obejmują obsługę TDLS i TDLS włączone w API Wi-FiManager:

• [C-1-1] MUSI zadeklarować obsługę TDLS do WifiManager.isTdlsSupported.
• Narzędzia TDLS należy używać tylko wtedy, gdy jest to możliwe i korzystne.
• POWINNY jest działać mechanizm heurystyczny i NIE używać TDLS, gdy jego wydajność może być gorsza niż przez punkt dostępu Wi-Fi.

7.4.2.3 Rozpoznawalność Wi-Fi

Implementacje na urządzeniach:

• POWINNO_obsługiwać funkcję Wi-Fi Aware.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i udostępniają tę funkcję aplikacjom innych firm, to:

• [C-1-1] MUSI zaimplementować interfejsy API WifiAwareManager w sposób opisany w dokumentacji pakietu SDK.
• [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.aware.
• [C-1-3] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Aware.
• [C-1-4] MUSI losowego podziału adresu interfejsu zarządzania Wi-Fi Aware w odstępach nie dłuższych niż 30 minut i zawsze wtedy, gdy włączona jest funkcja Wi-Fi Aware, chyba że trwa operacja określania zakresu Aware lub jest aktywna ścieżka danych Aware (randomizacja nie jest oczekiwana tak długo, jak ścieżka danych jest aktywna).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i lokalizacji Wi-Fi (zgodnie z opisem w artykule 7.4.2.5) i ujawnianie tych funkcji aplikacjom innych firm, wtedy:

• [C-2-1] MUSI wdrożyć interfejsy API do wykrywania z uwzględnieniem lokalizacji: setRangingEnabled, setMinOdległośćMm, setMaxOdległośćMm i onServiceDiscoveredWithinRange.

7.4.2.4. Punkt dostępu Wi-Fi

Implementacje na urządzeniach:

• POWINNO_obsługiwać obsługę Wi-Fi Passpoint.

Jeśli implementacje urządzeń obsługują protokół Wi-Fi Passpoint:

• [C-1-1] MUSI zaimplementować interfejsy API WifiManager związane z Passpoint w sposób opisany w dokumentacji pakietu SDK.
• [C-1-2] MUSI obsługiwać standard IEEE 802.11u, zwłaszcza związany z wykrywaniem i wyborem sieci, na przykład w ramach usług GAS i Access Network Query Protocol (ANQP).

Jeśli implementacje urządzeń nie obsługują Passpoint Wi-Fi:

• [C-2-1] Implementacja interfejsów API WifiManager związanych z Passpoint MUSI zgłosić UnsupportedOperationException.

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

Implementacje na urządzeniach:

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

Jeśli implementacje urządzeń obejmują obsługę lokalizacji Wi-Fi i udostępniają tę funkcję aplikacjom innych firm, to:

• [C-1-1] MUSI zaimplementować interfejsy API WifiRttManager w sposób opisany w dokumentacji pakietu SDK.
• [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.rtt.
• [C-1-3] MUSI randomizować źródłowy adres MAC w przypadku każdej serii RTT, która jest wykonywana, podczas gdy interfejs Wi-Fi, za pomocą którego jest wykonywany RTT, nie jest powiązany z punktem dostępu.

7.4.2.6 Odciążanie Wi-Fi

Implementacje na urządzeniach:

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

Jeśli implementacje urządzeń obejmują obsługę odciążania Wi-Fi i udostępnianie tej funkcji aplikacjom innych firm:

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

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

Jeśli implementacje urządzeń nie obsługują odciążania Wi-Fi, mają one zapewnioną:

• [C-2-1] MUSI zwrócić ERROR_UNSUPPORTED.

7.4.2.7. Łatwe połączenie Wi-Fi (protokół obsługi administracyjnej urządzeń)

Implementacje na urządzeniach:

• POWINNO_obsługiwać Wi-Fi Easy Connect (DPP).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Easy Connect i udostępnienie tej funkcji aplikacjom innych firm:

• [C-1-1] MUSI mieć zwrot WifiManager#isEasyConnectSupported()metody true.

7.4.3 Bluetooth

Jeśli implementacje urządzenia obsługują profil audio Bluetooth:

• POWINNA obsługiwać zaawansowane kodeki audio i kodeki audio Bluetooth (np. LDAC).

Jeśli implementacje urządzeń obsługują HFP, A2DP i AVRCP:

• POWINNA OBSŁUGIWAĆ co najmniej 5 połączonych urządzeń.

Jeśli implementacje urządzenia zadeklarują funkcję android.hardware.vr.high_performance:

• [C-1-1] MUSI obsługiwać rozszerzenie Bluetooth 4.2 i Bluetooth LE.

Android obsługuje Bluetooth i Bluetooth Low Energy.

Jeśli implementacje urządzeń obejmują obsługę Bluetootha i Bluetooth Low Energy, aplikacje:

• [C-2-1] MUSI zadeklarować odpowiednie funkcje platformy (odpowiednio android.hardware.bluetooth i android.hardware.bluetooth_le) i wdrożyć interfejsy API platformy.
• NALEŻY zastosować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX, HFP itp., odpowiednie dla danego urządzenia.

Jeśli implementacje urządzeń obejmują obsługę Bluetooth Low Energy (BLE), te funkcje:

• [C-3-1] MUSI zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
• [C-3-2] MUSI włączyć interfejsy API Bluetooth oparte na GATT (ogólnym profilu) w sposób opisany w dokumentacji pakietu SDK i w android.bluetooth.
• [C-3-3] MUSI zgłosić prawidłową wartość BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy logika filtrowania klas interfejsu ScanFilter została zaimplementowana.
• [C-3-4] MUSI zgłosić prawidłową wartość pola BluetoothAdapter.isMultipleAdvertisementSupported(), aby wskazać, czy reklamy Low Energy Advertising są obsługiwane.
• [C-3-5] MUSI wdrożyć limit czasu oczekiwania na rozpoznawalny adres prywatny (RPA) nie dłuższy niż 15 minut i wykonywać rotację adresu po upływie limitu czasu, aby chronić prywatność użytkownika, gdy urządzenie aktywnie używa BLE do skanowania lub wyświetlania reklam. Aby zapobiec atakom czasowym, odstępy czasu oczekiwania MUSZĄ też być losowe z zakresu 5–15 minut.
• POWINNO obsługiwać przenoszenie logiki filtrowania na chipset Bluetooth podczas wdrażania interfejsu API ScanFilter.
• POWINNO obsługiwać pobieranie skanowania zbiorczego do chipsetu Bluetooth.
• POWINNA obsługiwać wiele reklam z co najmniej 4 boksami.

Jeśli implementacje urządzeń obsługują Bluetooth LE i używają Bluetooth LE do skanowania lokalizacji, to:

• [C-4-1] MUSI zapewnić użytkownika, aby włączyć/wyłączyć wartość odczytywaną za pośrednictwem interfejsu API systemu 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 dźwięku z aparatu słuchowego z wykorzystaniem Bluetooth LE:

• [C-5-1] MUSI zwracać wartość true w przypadku parametru BluetoothAdapter.getProfileProxy(context, detektor, BluetoothProfile.HEARING_AID).

7.4.4 Komunikacja Near Field Communication

Implementacje na urządzeniach:

• POWINIEN zawierać nadajnik i powiązany sprzęt do komunikacji Near-Field Communication (NFC).
• [C-0-1] MUSI zaimplementować interfejsy API android.nfc.NdefMessage i android.nfc.NdefRecord, nawet jeśli nie obsługują one NFC lub zadeklaruj funkcję android.hardware.nfc, ponieważ klasy przedstawiają format danych niezależny od protokołu.

Jeśli implementacje urządzeń obejmują sprzęt do komunikacji NFC i planują udostępnić tę funkcję aplikacjom innych firm:

• [C-1-1] MUSI zgłosić funkcję android.hardware.nfc za pomocą metody android.content.pm.PackageManager.hasSystemFeature().
• MUSI być w stanie odczytywać i zapisywać wiadomości NDEF z użyciem następujących standardów NFC, zgodnie z poniższymi standardami:
• [C-1-2] MUSI działać jako czytnik/zapisujący forum NFC (zgodnie ze specyfikacją techniczną NFC Forum-TS-DigitalProtocol-1.0) zgodnie z tymi standardami:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Typy tagów forum NFC 1, 2, 3, 4, 5 (zdefiniowane przez Forum NFC)

• Zdecydowanie zalecana jest możliwość odczytywania i zapisywania wiadomości NDEF, a także nieprzetworzonych danych przy użyciu następujących standardów NFC. Pamiętaj, że chociaż standardy NFC są określone jako Zdecydowanie ZALECANE, zgodnie z definicją zgodności w przyszłości planujemy zmienić je na MUSI. Standardy te są w tej wersji opcjonalne, ale będą wymagane w kolejnych. Zdecydowanie zalecamy spełnianie tych wymagań już teraz i na nowych urządzeniach, na których działa ta wersja Androida, aby umożliwić ich uaktualnienie do przyszłych wersji platformy.

• [C-1-13] W trybie wykrywania NFC MUSI przeprowadzać sondowanie w poszukiwaniu wszystkich obsługiwanych technologii.

• POWINNY być w trybie wykrywania NFC, gdy urządzenie jest wybudzone, a ekran jest aktywny, a ekran blokady jest odblokowany.
• MUSI być w stanie odczytać kod kreskowy i adres URL (jeśli jest zakodowany) produktów z kodem kreskowym Thinfilm NFC.

Pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku wymienionych powyżej specyfikacji JIS, ISO i NFC.

Android obsługuje tryb HCE (NFC).

Jeśli implementacje urządzeń obejmują chipset kontrolera NFC z obsługą HCE (NfcA lub NfcB) i obsługują routing na podstawie identyfikatora aplikacji (AID), te urządzenia:

• [C-2-1] MUSI zgłaszać stałą funkcję android.hardware.nfc.hce.
• [C-2-2] MUSI obsługiwać interfejsy NFC HCE API zgodnie z definicją w pakiecie Android SDK.

Jeśli używane urządzenia korzystają z chipsetu kontrolera NFC obsługującego HCE dla NfcF i wdrożą tę funkcję na potrzeby aplikacji innych firm:

• [C-3-1] MUSI zgłaszać stałą funkcję android.hardware.nfc.hcef.
• [C-3-2] MUSI zaimplementować interfejsy API karty NfcF zgodnie z definicją w pakiecie SDK na Androida.

Jeśli implementacje urządzeń obejmują ogólną obsługę NFC zgodnie z opisem w tej sekcji oraz technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF w MIFARE Classic) w roli odczytującego/zapisującego, użytkownicy:

• [C-4-1] MUSI wdrożyć odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
• [C-4-2] MUSI zgłosić funkcję com.nxp.mifare za pomocą metody android.content.pm.PackageManager.hasSystemFeature(). Pamiętaj, że nie jest to standardowa funkcja Androida, dlatego 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 Minimalne możliwości sieci

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać co najmniej jedną formę sieci danych. Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden standard danych o szybkości co najmniej 200 kb/s. Przykłady technologii, które spełniają to wymaganie, to EDGE, HSPA, EV-DO, 802.11g, Ethernet i Bluetooth PAN.
• POWINNA też obsługiwać co najmniej jeden popularny standard bezprzewodowych danych, taki jak 802.11 (Wi-Fi), gdy podstawowym połączeniem transmisji danych jest fizyczny standard sieci (np. Ethernet).
• MOŻESZ wdrożyć więcej niż jedną formę połączeń danych.

7.4.5.2 IPv6

Implementacje na urządzeniach:

• [C-0-2] MUSI zawierać stos sieci IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection, oraz natywnych interfejsów API, takich jak gniazda AF_INET6.
• [C-0-3] MUSI domyślnie włączać IPv6.
• MUSI mieć pewność, że komunikacja IPv6 będzie równie niezawodna jak IPv4, na przykład:
  • [C-0-4] MUSI utrzymywać połączenia IPv6 w trybie uśpienia.
  • [C-0-5] Ograniczenie szybkości NIE MOŻE spowodować utraty połączeń IPv6 w żadnej sieci zgodnej z IPv6, w której czas trwania RA wynosi co najmniej 180 sekund.
• [C-0-6] MUSI zapewniać zewnętrznym aplikacjom możliwość bezpośredniego połączenia IPv6 z siecią IPv6, bez konieczności lokalnej translacji adresów lub portów na urządzeniu. Zarówno zarządzane interfejsy API (np. Socket#getLocalAddress lub Socket#getLocalPort), jak i interfejsy API NDK, takie jak getsockname() lub IPV6_PKTINFO, MUSZĄ zwracać adres IP i port, które są rzeczywiście używane do wysyłania i odbierania pakietów w sieci i są widoczne jako źródłowy adres IP oraz port na serwery internetowe (internetowe).

Wymagany poziom obsługi IPv6 zależy od typu sieci, jak pokazano w wymaganiach poniżej.

Jeśli implementacje urządzeń obsługują Wi-Fi:

• [C-1-1] MUSI obsługiwać operacje na stosie podwójnym i tylko IPv6 w Wi-Fi.

Jeśli implementacje urządzeń obsługują protokół Ethernet:

• [C-2-1] MUSI obsługiwać operację podwójnego stosu i tylko IPv6 w sieci Ethernet.

Jeśli implementacje urządzeń obsługują komórkową transmisję danych:

• [C-3-1] MUSI obsługiwać operację IPv6 (tylko w przypadku protokołu IPv6 i ewentualnie podwójny stos) w sieci komórkowej.

Jeśli implementacje urządzeń obsługują więcej niż 1 typ sieci (np. Wi-Fi i komórkowa transmisja danych):

• [C-4-1] MUSI spełniać jednocześnie powyższe wymagania w każdej sieci, gdy urządzenie jest połączone z więcej niż jednym typem sieci.

7.4.5.3 Portale przechwytujące

Portal dostępowy to sieć, która wymaga zalogowania się w celu uzyskania dostępu do internetu.

Jeśli implementacje na urządzeniach zapewniają pełną implementację android.webkit.Webview API:

• [C-1-1] MUSI udostępnić aplikację portalu przechwytującego do obsługi intencji ACTION_CAPTIVE_PORTAL_SIGN_IN i wyświetlania strony logowania do portalu przechwytującego, wysyłając tę intencję w momencie wywołania do interfejsu API systemu ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] MUSI wykrywać portale przechwytujące i umożliwiać logowanie się przez aplikację 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 się do portali przechwytujących z użyciem jawnego tekstu DNS, gdy urządzenie jest skonfigurowane do korzystania z prywatnego trybu ścisłego DNS.
• [C-1-4] MUSI używać zaszyfrowanego DNS zgodnie z dokumentacją pakietu SDK na potrzeby android.net.LinkProperties.getPrivateDnsServerName i android.net.LinkProperties.isPrivateDnsActive w przypadku całego ruchu w sieci, który nie komunikuje się bezpośrednio z portalem przechwytującym.
• [C-1-5] MUSI mieć pewność, że podczas logowania się użytkownika do portalu przechwytującego domyślna sieć używana przez aplikacje (wyświetlana przez funkcje ConnectivityManager.getActiveNetwork i ConnectivityManager.registerDefaultNetworkCallback i domyślnie używana przez interfejsy sieciowe Java, np. java.net.Socket) oraz natywne interfejsy API, np. Connect()), to inna dostępna sieć, która zapewnia dostęp do internetu, o ile jest dostępna.

7.4.6 Ustawienia synchronizacji

Implementacje na urządzeniach:

• [C-0-1] MUSI mieć domyślnie włączone ustawienie autosynchronizacji głównej, aby metoda getMasterSyncAutomatically() zwracała wartość „true”.

7.4.7 Oszczędzanie danych

Jeśli implementacje urządzeń obejmują połączenie z pomiarem, będą to:

• [SR] Zdecydowanie ZALECANE jest włączenie trybu oszczędzania danych.

Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych:

• [C-1-1] MUSI obsługiwać wszystkie interfejsy API klasy ConnectivityManager w sposób opisany w dokumentacji pakietu SDK

Jeśli implementacje urządzeń nie obsługują trybu oszczędzania danych:

• [C-2-1] MUSI zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED dla ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NIE MOŻE rozgłaszać: ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8 Zabezpieczone elementy

Jeśli implementacje urządzeń obsługują bezpieczne elementy obsługujące Open Mobile API i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI wyliczać dostępne czytniki elementów zabezpieczonych za pomocą interfejsu API android.se.omapi.SEService.getReaders().

• [C-1-2] MUSI zadeklarować prawidłowe flagi funkcji przez android.hardware.se.omapi.uicc w przypadku urządzenia z elementami zabezpieczonymi opartymi na UICC, android.hardware.se.omapi.ese dla urządzenia z elementami zabezpieczonymi opartymi na eSE i android.hardware.se.omapi.sd dla urządzenia z elementami zabezpieczonymi opartymi na SD.

7.5 Aparaty

Jeśli implementacje urządzeń obejmują co najmniej jedną kamerę:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.camera.any.
• [C-1-2] Aplikacja musi mieć możliwość jednoczesnego przypisania 3 map bitowych RGBA_8888 odpowiadających rozmiarowi obrazu generowanego przez czujnik w aparacie o największej rozdzielczości w urządzeniu, a aparat jest otwarty na potrzeby podstawowego podglądu i rejestrowania.
• [C-1-3] MUSI upewnić się, że wstępnie zainstalowana domyślna aplikacja aparatu obsługująca intencje MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE lub MediaStore.ACTION_VIDEO_CAPTURE jest odpowiedzialna za usunięcie lokalizacji użytkownika z metadanych obrazu przed wysłaniem jej do aplikacji odbierającej, jeśli aplikacja odbierająca nie ma ACCESS_FINE_LOCATION.

7.5.1 Kamera tylna

Tylny aparat to kamera znajdująca się z boku urządzenia, naprzeciwko wyświetlacza. Oznacza to, że rejestruje sceny z daleka, jak w tradycyjnym aparacie.

Implementacje na urządzeniach:

• POWINIEN zawierać tylny aparat.

Jeśli urządzenia mają co najmniej 1 tylny aparat:

• [C-1-1] MUSI zgłosić flagę funkcji android.hardware.camera i android.hardware.camera.any.
• [C-1-2] MUSI mieć rozdzielczość co najmniej 2 megapiksele.
• W sterowniku aparatu musi być zaimplementowany sprzętowy autofokus lub programowy autofokus (przezroczysty dla oprogramowania).
• MOŻE mieć sprzęt o stałej ostrości lub EDOF (rozszerzona głębia ostrości).
• MOŻE zawierać obiekty flash.

Jeśli aparat ma lampę błyskową:

• [C-2-1] Lampa błyskowa NIE MOŻE się świecić, gdy zostało zarejestrowane wystąpienie android.hardware.Camera.PreviewCallback na platformie podglądu aparatu, chyba że aplikacja wyraźnie włączyła lampę błyskową przez włączenie atrybutu FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu na urządzeniu, a tylko aplikacji innych firm korzystających z Camera.PreviewCallback.

7.5.2 Przedni aparat

Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz. oznacza kamerę zwykle używaną do robienia zdjęć użytkownika, na przykład do rozmów wideo i w podobnych aplikacjach.

Implementacje na urządzeniach:

• MOŻE zawierać przedni aparat.

Jeśli implementacje urządzeń obejmują co najmniej jeden przedni aparat:

• [C-1-1] MUSI zgłosić flagę funkcji android.hardware.camera.any i android.hardware.camera.front.
• [C-1-2] MUSI mieć rozdzielczość co najmniej VGA (640 x 480 pikseli).
• [C-1-3] NIE MOŻE używać przedniego aparatu jako domyślnego dla interfejsu Camera API i NIE MOŻE konfigurować interfejsu API w taki sposób, aby traktował przedni aparat jako domyślny tylny aparat, nawet jeśli jest to jedyny aparat w urządzeniu.
• [C-1-4] Podgląd z kamery MUSI być odbiciem lustrzanym w poziomie względem orientacji określonej przez aplikację, gdy bieżąca aplikacja wprost zażąda obrócenia ekranu kamery przez wywołanie metody android.hardware.Camera.setDisplayOrientation(). Jeśli natomiast bieżąca aplikacja nie zażąda wprost obrócenia ekranu kamery przez wywołanie metody android.hardware.Camera.setDisplayOrientation(), podgląd MUSI być zduplikowany względem domyślnej osi poziomej urządzenia.
• [C-1-5] NIE MOŻE powielać ostatecznej wersji obrazu nieruchomego ani strumieni wideo zwróconych do wywołań zwrotnych aplikacji lub zadeklarowanych do przechowywania multimediów.
• [C-1-6] MUSI odbić obraz wyświetlany po wyświetleniu w taki sam sposób jak obraz podglądu z aparatu.
• MOŻE obejmować funkcje (takie jak autofokus, lampa błyskowa itp.) dostępne w przypadku tylnych aparatów zgodnie z opisem w sekcji 7.5.1.

Jeśli implementacje urządzeń mogą podlegać rotacji przez użytkownika (np. automatycznie za pomocą akcelerometru lub ręcznie za pomocą danych wejściowych użytkownika):

• [C-2-1] Podgląd z aparatu MUSI być odbicie lustrzane w poziomie względem bieżącej orientacji urządzenia.

7.5.3 Kamera zewnętrzna

Implementacje na urządzeniach:

• MOŻESZ obsługiwać kamerę zewnętrzną, która nie zawsze jest podłączona.

Jeśli implementacje urządzeń obejmują obsługę aparatu zewnętrznego:

• [C-1-1] MUSI zadeklarować flagę funkcji platformy android.hardware.camera.external i android.hardware camera.any.
• [C-1-2] MUSI obsługiwać standard USB Video Class (UVC 1.0 lub nowszy), jeśli kamera zewnętrzna jest podłączona przez port hosta USB.
• [C-1-3] MUSI przejść testy CTS kamery z podłączonym fizycznym aparatem zewnętrznym. Szczegółowe informacje o testowaniu CTS aparatu znajdziesz na stronie source.android.com.
• POWINNA obsługiwać kompresję wideo, taką jak MJPEG, by umożliwić przesyłanie niezakodowanych strumieni o wysokiej jakości (tj. nieprzetworzonych lub niezależnie skompresowanych strumieni obrazu).
• MOŻE obsługiwać wiele aparatów.
• MOŻE obsługiwać kodowanie wideo z użyciem kamery.

Jeśli obsługiwane jest kodowanie przy użyciu kamery:

• [C-2-1] Jednoczesny niezakodowany strumień / MJPEG (o rozdzielczości QVGA lub wyższej) MUSI być dostępny dla implementacji urządzenia.

7.5.4 Działanie interfejsu Camera API

Android zawiera 2 pakiety interfejsów API zapewniające dostęp do aparatu. Nowszy interfejs API android.hardware.camera2 zapewnia aplikacji dostęp do aparatu niższego poziomu, w tym wydajne serie bez żadnej kopii i strumieniowanie, które umożliwiają sterowanie ekspozycją, wzmocnieniem, wzmocnieniem bieli, konwertowaniem kolorów, wyciszaniem szumów, wyostrzaniem i nie tylko.

Starszy pakiet interfejsów API (android.hardware.Camera) jest oznaczony jako wycofany w Androidzie 5.0, ale nadal powinien być dostępny dla aplikacji. Implementacje na urządzeniach z Androidem MUSZĄ zapewnić nieprzerwaną obsługę interfejsu API zgodnie z opisem w tej sekcji oraz w pakiecie SDK na Androida.

Wszystkie funkcje typowe dla wycofanej klasy android.hardware.Camera i nowszym pakietem android.hardware.camera2 MUSZĄ mieć taką samą wydajność i jakość w obu interfejsach API. Na przykład przy równoważnych ustawieniach szybkość i dokładność autofokusa muszą być takie same, a jakość zrobionych zdjęć musi być taka sama. Funkcje, które zależą od semantyki obu interfejsów API, nie muszą do siebie pasować pod względem szybkości ani jakości, ale POWINNY być jak najbardziej zbliżone.

Implementacje urządzeń MUSZĄ implementować poniższe sposoby działania w przypadku interfejsów API związanych z aparatem w przypadku wszystkich dostępnych kamer. Implementacje na urządzeniach:

• [C-0-1] MUSI używać android.hardware.PixelFormat.YCbCr_420_SP do obsługi danych podglądu przesyłanych do wywołań zwrotnych aplikacji, gdy aplikacja nigdy nie wywołała android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] MUSI dodatkowo mieć format kodowania NV21, gdy aplikacja rejestruje wystąpienie android.hardware.Camera.PreviewCallback, a system wywołuje metodę onPreviewFrame(), a format podglądu to YCbCr_420_SP, czyli dane w bajcie[] przekazywane do onPreviewFrame(). Oznacza to, że NV21 MUSI być wartością domyślną.
• [C-0-3] MUSI obsługiwać format YV12 (oznaczony stałą wartością android.graphics.ImageFormat.YV12) w przypadku podglądu zarówno przedniego, jak i tylnego aparatu dla android.hardware.Camera. (Sprzętowy koder wideo i kamera mogą używać dowolnego natywnego formatu piksela, ale implementacja urządzenia MUSI obsługiwać konwersję na format YV12).
• [C-0-4] MUSI obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe przez interfejs API android.media.ImageReader w przypadku urządzeń android.hardware.camera2, które reklamują funkcję REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE w android.request.availableCapabilities.
• [C-0-5] Nadal musisz wdrożyć pełny interfejs Camera API podany w dokumentacji pakietu Android SDK, niezależnie od tego, czy urządzenie jest wyposażone w sprzętowy autofokus czy inne funkcje. Na przykład aparaty bez autofokusa MUSZĄ wywoływać dowolne zarejestrowane wystąpienia android.hardware.Camera.AutoFocusCallback (mimo że nie ma to związku z aparatem bez autofokusa). Pamiętaj, że dotyczy to przednich aparatów. Na przykład, mimo że większość przednich aparatów nie obsługuje autofokusa, wywołania zwrotne interfejsu API muszą być fałszywe, zgodnie z opisem.
• [C-0-6] MUSI rozpoznawać i przestrzegać wszystkich nazw parametrów zdefiniowanych jako stała w klasie android.hardware.Camera.Parameters i klasie android.hardware.camera2.CaptureRequest. I odwrotnie, implementacje urządzeń NIE MOGĄ uznawać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters() innych niż te, które są wymienione jako stałe w zasadzie android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry aparatu (o ile sprzęt na to pozwala) i NIE MOŻE obsługiwać niestandardowych typów parametrów aparatu. Na przykład implementacje urządzeń, które obsługują robienie zdjęć z użyciem technik obrazowania High Dynamic Range (HDR), MUSZĄ obsługiwać parametr Camera.SCENE_MODE_HDR aparatu.
• [C-0-7] MUSI zgłosić odpowiedni poziom pomocy przy użyciu właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i zgłaszać odpowiednie flagi funkcji platformy.
• [C-0-8] MUSI też zadeklarować możliwości poszczególnych kamer android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i zadeklarować odpowiednie flagi funkcji. MUSI zdefiniować flagę funkcji, jeśli któreś z podłączonych do niej urządzeń ją obsługuje.
• [C-0-9] MUSI transmitować intencję Camera.ACTION_NEW_PICTURE za każdym razem, gdy aparat zrobi nowe zdjęcie i zostanie dodane do sklepu multimedialnego.
• [C-0-10] MUSI transmitować intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy kamera zarejestruje nowy film i dodasz obraz do sklepu multimedialnego.
• [C-0-11] MUSI mieć dostęp do wszystkich kamer za pomocą wycofanego interfejsu API android.hardware.Camera oraz interfejsu API android.hardware.camera2.
• [C-0-12] MUSI dopilnować, aby wygląd twarzy NIE był zmieniany, w tym między innymi geometria, odcień skóry twarzy lub wygładzanie skóry twarzy w przypadku dowolnego interfejsu API android.hardware.camera2 lub android.hardware.Camera.
• [C-SR] W przypadku urządzeń z kilkoma kamerami RGB skierowanymi w tym samym kierunku Zdecydowanie ZALECANE jest włączenie obsługi kamery logicznej, która zawiera listę możliwości CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, czyli wszystkich kamer RGB skierowanych w tym kierunku jako fizyczne urządzenia podrzędne.

Jeśli implementacje urządzeń udostępniają zastrzeżony interfejs API aparatu aplikacjom innych firm:

• [C-1-1] MUSI wdrożyć taki interfejs API aparatu za pomocą interfejsu API android.hardware.camera2.
• MOŻE udostępniać tagi lub rozszerzenia dostawców do interfejsu API android.hardware.camera2.

7.5.5 Orientacja aparatu

Jeśli urządzenia mają aparat przedni lub tylny:

• [C-1-1] MUSI być zorientowana tak, by długi wymiar kamery był zgodny z długością ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparaty MUSZĄ robić zdjęcia w orientacji poziomej. Dotyczy to niezależnie od naturalnej orientacji urządzenia. Oznacza to, że ma ona zastosowanie zarówno do urządzeń głównych w orientacji poziomej, jak i pionowej.

7.6 Pamięć i miejsce na dane

7.6.1 Minimalna ilość pamięci i ilości miejsca na dane

Implementacje na urządzeniach:

• [C-0-1] MUSI zawierać menedżera pobierania, z którego aplikacje MOGĄ pobierać pliki danych. MUSZĄ one pobierać pojedyncze pliki o rozmiarze co najmniej 100 MB do domyślnej lokalizacji w „pamięci podręcznej”.

7.6.2 Pamięć współdzielona aplikacji

Implementacje na urządzeniach:

• [C-0-1] MUSI oferować miejsce na dane, które może być współużytkowane przez aplikacje, często nazywane też „wspólną pamięcią zewnętrzną” lub „pamięcią współdzieloną przez aplikację”. lub ścieżką Linuksa „/sdcard” na których są zamontowane.
• [C-0-2] MUSI być skonfigurowana z pamięcią współdzieloną domyślnie instalowaną, czyli bez względu na to, czy pamięć jest umieszczona w pamięci wewnętrznej czy na nośniku wymiennym (np. w gniazdku kart Secure Digital).
• [C-0-3] MUSI podłączyć pamięć współdzieloną aplikacji bezpośrednio w ścieżce Linuksa sdcard lub dołączyć łącze symboliczne Linuksa z sdcard do rzeczywistego punktu podłączania.
• [C-0-4] MUSI domyślnie włączać zakres miejsca na dane dla wszystkich aplikacji kierowanych na interfejs API na poziomie 29 lub wyższym, z wyjątkiem tych sytuacji:
  • Gdy aplikacja zażądała elementu android:requestLegacyExternalStorage="true" w pliku manifestu.
• [C-0-5] MUSI usuwać metadane lokalizacji, takie jak tagi GPS Exif, przechowywane w plikach multimedialnych, gdy uzyskuje się do nich dostęp przez MediaStore, chyba że aplikacja wywołująca ma uprawnienie ACCESS_MEDIA_LOCATION.

Implementacje na urządzeniach MOGĄ spełniać powyższe wymagania, jeśli użyjesz jednego z tych elementów:

• Pamięć wymienna dostępna dla użytkowników, np. gniazdo kart Secure Digital (SD).
• Część pamięci wewnętrznej (niewymiennej) wdrożona w ramach projektu Android Open Source Project (AOSP).

Jeśli implementacje urządzeń korzystają z pamięci wymiennej, aby spełnić powyższe wymagania:

• [C-1-1] MUSI zaimplementować tost lub wyskakujące okienko z ostrzeżeniem dla użytkownika, gdy w gnieździe nie ma nośnika pamięci.
• [C-1-2] MUSI zawierać nośnik pamięci w formacie FAT (np. kartę SD) lub widoczne na pudełku i inne materiały dostępne w momencie zakupu, że taki nośnik trzeba zakupić oddzielnie.

Jeśli implementacje urządzeń wykorzystują część pamięci niewymiennej w celu spełnienia powyższych wymagań:

• NALEŻY użyć implementacji AOSP pamięci współdzielonej aplikacji wewnętrznej.
• MOGĄ dzielić dostępne miejsce z prywatnymi danymi aplikacji.

Jeśli urządzenia są wyposażone w port USB z obsługą trybu urządzenia peryferyjnego USB:

• [C-3-1] MUSI udostępniać mechanizm uzyskiwania dostępu do danych w pamięci współdzielonej aplikacji z komputera hosta.
• Treści z obu ścieżek pamięci NALEŻY w przejrzysty sposób udostępniać za pomocą usługi skanera multimediów na Androidzie i usługi android.provider.MediaStore.
• MOŻNA korzystać z pamięci masowej USB, ale spełnienie tego wymagania POWINIEN korzystać z protokołu Media Transfer Protocol.

Jeśli urządzenia są wyposażone w port USB z trybem urządzenia peryferyjnego USB i obsługują protokół Media Transfer Protocol, umożliwiają one:

• POWINNA być zgodna z referencyjnym hostem MTP Androida i Android File Transfer.
• MUSISZ zgłosić klasę urządzenia USB 0x00.
• POWINIEN zgłosić nazwę interfejsu USB „MTP”.

7.6.3 Pamięć elastyczna

Jeśli oczekuje się, że urządzenie ma charakter mobilny (inaczej niż w przypadku telewizora), implementacje urządzeń są:

• [SR] Zdecydowanie ZALECANE jest wdrożenie pamięci adaptacyjnej w stabilnej lokalizacji długoterminowej, ponieważ przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

Jeśli wyjmowany port urządzenia pamięci masowej znajduje się w stabilnej lokalizacji długoterminowej, na przykład w komorze na baterię lub w innej osłonie ochronnej, sposób działania urządzenia:

• [SR] Zdecydowanie ZALECANE jest wdrożenie pamięci dostosowywanej.

7.7. USB

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

• POWINNA obsługiwać tryb urządzenia peryferyjnego USB i POWINNO obsługiwać tryb hosta USB.

7.7.1. Tryb urządzenia peryferyjnego USB

Jeśli używane urządzenia są wyposażone w port USB obsługujący tryb peryferyjny:

• [C-1-1] Port MUSI być podłączony do hosta USB ze standardowym portem USB typu A lub C.
• [C-1-2] MUSI zgłosić prawidłową wartość iSerialNumber w standardowym deskrypcie urządzenia USB do android.os.Build.SERIAL.
• [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem oporu typu C i MUSZĄ wykrywać zmiany w reklamach, jeśli obsługują USB typu C.
• [SR] Port powinien używać formatu micro-B, micro-AB lub USB typu C. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
• [SR] Port powinien znajdować się na spodzie urządzenia (zgodnie z naturalną orientacją) lub umożliwiać programowe obracanie ekranu we wszystkich aplikacjach (w tym na ekranie głównym), by ekran był prawidłowo wyświetlany, gdy urządzenie jest zorientowane na port u dołu. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
• [SR] POWINNO obsługiwać pobieranie prądu na poziomie 1,5 A podczas sygnału HS i ruchu zgodnie z opisem w specyfikacji ładowania baterii przez USB, wersja 1.2. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
• [SR] Zdecydowanie ZALECAM, aby nie obsługiwać zastrzeżonych metod ładowania, które zmieniają napięcie Vbus do wartości domyślnych lub zmieniają role zlewu/źródła, co może powodować problemy ze współdziałaniem z ładowarkami lub urządzeniami, które obsługują standardowe metody przesyłania przez USB Power Delivery. Choć ta funkcja nazywa się „Zdecydowanie ZALECANE”, w przyszłych wersjach Androida możemy WYMAGAĆ WYMAGANIE obsługi wszystkich urządzeń typu C w celu pełnej interoperacyjności ze standardowymi ładowarkami typu C.
• [SR] ZDECYDOWANIE ZALECANE jest w przypadku obsługi funkcji Power Delivery w przypadku wymiany ról danych i zasilania, jeśli obsługuje ona tryb hosta USB typu C i USB.
• POWINNA obsługiwać technologię Power Delivery w przypadku ładowania wysokiego napięcia oraz obsługa trybów alternatywnych, takich jak wyświetlacz na zewnątrz.
• NALEŻY zaimplementować interfejs API i specyfikację Android Open Accessory (AOA) w sposób opisany w dokumentacji pakietu Android SDK.

Jeśli urządzenia są wyposażone w port USB i stosują specyfikację AOA:

• [C-2-1] MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.accessory.
• [C-2-2] Klasa pamięci masowej USB MUSI zawierać ciąg „android” na końcu ciągu opisu interfejsu iInterface pamięci masowej USB

7.7.2 Tryb hosta USB

Jeśli implementacje urządzeń są wyposażone w port USB obsługujący tryb hosta:

• [C-1-1] MUSI zaimplementować interfejs Android USB Host API w sposób opisany w pakiecie Android SDK i MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.host.
• [C-1-2] MUSI zaimplementować obsługę podłączenia standardowych urządzeń peryferyjnych USB. Oznacza to, że MUSI:
  • urządzenie musi mieć port USB typu C lub musi być wyposażony w kable umożliwiające podłączenie zastrzeżonego portu urządzenia do standardowego portu USB typu C (urządzenie z USB typu C).
  • urządzenie musi być wyposażone w urządzenie typu A lub użyć kabli podłączających zastrzeżony port urządzenia do standardowego portu USB typu A.
  • Mieć na urządzeniu port micro-AB, który POWINNY być w dostarczeniu z kablem pasującym do standardowego portu typu A.
• [C-1-3] NIE MOŻE być dostarczany z przejściówką konwertowaną z portów USB typu A lub micro-AB na porty typu C (gniazdo).
• [C-SR] Zdecydowanie ZALECANE jest wdrożenie klasy audio USB w sposób opisany w dokumentacji pakietu Android SDK.
• POWINNO obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta. reklamując źródło prądu źródłowego o wartości co najmniej 1,5 A zgodnie z opisem w sekcji Parametry zakończenia w wersji 1.2 specyfikacji kabla USB typu C w przypadku złączy USB typu C lub korzystania z zakresu prądu wyjściowego używanego w złączach USB typu C(CDP), zgodnie ze specyfikacją ładowania baterii USB, wersja 1.2 dla złączy Micro-AB.
• KONIECZNIE jest wdrożenie i obsługa standardów USB typu C.

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i klasę audio USB, te funkcje:

• [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 wykorzystania USB HID i żądaniu użycia poleceń głosowych na stałe KeyEvent jak poniżej:
  ,
  • Identyfikator wykorzystania strony użycia (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Identyfikator wykorzystania strony wykorzystania (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • Identyfikator wykorzystania strony wykorzystania (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • Identyfikator wykorzystania strony użycia (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i platformę Storage Access Framework (SAF), funkcje te:

• [C-3-1] MUSI rozpoznawać zdalnie połączone urządzenia MTP (Media Transfer Protocol) i udostępniać ich treści za pomocą intencji ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT. .

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i USB typu C:

• [C-4-1] MUSI zaimplementować funkcję Dual Role Port zgodnie z definicją w specyfikacji USB typu C (sekcja 4.5.1.3.3).
• [SR] Zdecydowanie ZALECANE jest korzystanie z portu DisplayPort, obsługa technologii USB SuperSzybkości transmisji danych. Zdecydowanie ZALECANE jest obsługa usługi Power Delivery w celu wymiany ról związanych z danymi i zasilaniem.
• [SR] Zdecydowanie ZALECANY, aby NIE obsługiwać trybu akcesorium adaptera audio opisanego w Dodatku A do wersji 1.2 specyfikacji kabla USB typu C i złącza.
• NALEŻY zastosować model Try.*, który najlepiej pasuje do formatu urządzenia. Na przykład urządzenie przenośne POWINNO obsługiwać model Try.SNK.

7.8 Dźwięk

7.8.1 mikrofon

Jeśli implementacje urządzeń zawierają mikrofon:

• [C-1-1] MUSI zgłaszać stałą funkcję android.hardware.microphone.
• [C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku opisane w sekcji 5.4.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku opisane w sekcji 5.6.
• [SR] Zdecydowanie ZALECANE jest korzystanie z nagrywania w pobliżu ultradźwięków zgodnie z opisem w sekcji 7.8.3.

Jeśli implementacje urządzenia pomijają mikrofon:

• [C-2-1] NIE MOŻE zgłaszać stałej funkcji android.hardware.microphone.
• [C-2-2] MUSI wdrożyć interfejs API do nagrywania dźwięku co najmniej w trybie bezobsługowym, zgodnie z sekcją 7.

7.8.2 Wyjście audio

Jeśli używane urządzenia są wyposażone w głośnik lub port wyjściowy audio/multimedialny dla urządzenia peryferyjnego audio, takiego jak 4-kanałowe gniazdo słuchawek 3,5 mm lub port w trybie hosta USB klasa audio USB, to umożliwiają:

• [C-1-1] MUSI zgłaszać stałą funkcję android.hardware.audio.output.
• [C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku opisane w sekcji 5.5.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku opisane w sekcji 5.6.
• [SR] Zdecydowanie ZALECANE jest umożliwienie odtwarzania w trybie zbliżonym do ultradźwięków, zgodnie z opisem w sekcji 7.8.3.

Jeśli urządzenia nie mają gniazda głośnika ani wyjścia audio:

• [C-2-1] NIE MOŻE zgłaszać funkcji android.hardware.audio.output.
• [C-2-2] MUSI wdrożyć interfejsy API związane z wyjściem audio przynajmniej w trybie bezobsługowym.

Na potrzeby tej sekcji „port wyjściowy” 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 przez protokoły radiowe, takie jak Bluetooth, Wi-Fi czy sieć komórkowa, nie kwalifikuje się jako uwzględnienie „portu wyjściowego”.

7.8.2.1 Analogowe porty audio

Aby w całym ekosystemie Androida były one zgodne z zestawami słuchawkowymi i innymi akcesoriami audio, korzystając z wtyczki audio 3,5 mm w całym ekosystemie Androida, jeśli urządzenia zawierają co najmniej 1 analogowy port audio:

• [C-SR] Zdecydowanie ZALECANE jest użycie co najmniej jednego z portów audio jako 4-kanałowego gniazda słuchawek 3,5 mm.

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

• [C-1-1] MUSI obsługiwać odtwarzanie dźwięku w słuchawkach stereo i stereofonicznych zestawach słuchawkowych z mikrofonem.
• [C-1-2] MUSI obsługiwać wtyczki audio TRRS w kolejności styków CTIA.
• [C-1-3] MUSI obsługiwać wykrywanie i mapowanie kodów kluczy dla 3 zakresów równoważnych impedancji między mikrofonem a przewodnikami uziemiającymi we wtyczce audio:
  • Maks. 70 omów: KEYCODE_HEADSETHOOK
  • 210–290 omów: KEYCODE_VOLUME_UP
  • 360–680 omów: KEYCODE_VOLUME_DOWN
• [C-1-4] MUSI uruchamiać ACTION_HEADSET_PLUG po podłączeniu wtyczki, ale dopiero wtedy, gdy wszystkie kontakty podłączone do wtyczki dotykają odpowiednich segmentów gniazda.
• [C-1-5] MUSI NAPRAWDZAĆ co najmniej 150 mV ± 10% napięcia wyjściowego na głośniku o impedancji 32 om.
• [C-1-6] MUSI mieć napięcie odchylenia mikrofonu w zakresie 1,8 V ~ 2,9 V.
• [C-1-7] MUSI wykryć i zmapować kod klucza dla poniższego zakresu równoważnej impedancji między mikrofonem a przewodami uziemiającymi we wtyczce audio:
  • 110–180 omów: KEYCODE_VOICE_ASSIST
• [C-SR] Zdecydowanie ZALECANE jest obsługa wtyczek audio w kolejności pin-out w standardzie OMTP.
• [C-SR] Zdecydowanie ZALECANE jest umożliwienie nagrywania dźwięku z zestawów słuchawkowych stereo z mikrofonem.

Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3,5 mm i obsługują mikrofon oraz transmitują android.intent.action.HEADSET_PLUG z mikrofonem o dodatkowej wartości ustawionej na 1:

• [C-2-1] MUSI obsługiwać wykrywanie mikrofonu na podłączonych akcesorium audio.

7.8.2.2. Cyfrowe porty audio

W celu zachowania zgodności z zestawami słuchawkowymi i innymi akcesoriami audio przez złącze USB-C oraz wdrożenie (klasa audio USB) w ekosystemie Androida zgodnie z definicją podaną w specyfikacji zestawu słuchawkowego USB na Androida.

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

7.8.3 Prawie ultradźwiękowy

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

Implementacje na urządzeniach:

• MUSI prawidłowo zgłaszać obsługę funkcji audio bliskich ultradźwięków za pomocą interfejsu API AudioManager.getproperty w ten sposób:

Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND ma wartość „true”, źródła dźwięku VOICE_RECOGNITION i UNPROCESSED MUSZĄ spełniać te wymagania:

• [C-1-1] Średnia moc mikrofonu mikrofonu w paśmie 18,5–20 kHz MUSI być niższa niż 15 dB poniżej odpowiedzi przy 2 kHz.
• [C-1-2] Stosunek nieważonego sygnału do szumu mikrofonu powyżej 18,5–20 kHz dla tonu 19 kHz przy -26 dBFS MUSI być nie mniejszy niż 50 dB.

Jeśli PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „true” (prawda):

• [C-2-1] Średnia odpowiedź głośnika w zakresie 18,5 kHz – 20 kHz MUSI być niższa niż 40 dB poniżej odpowiedzi przy 2 kHz.

7.8.4 Integralność sygnałów

Implementacje na urządzeniach: * POWINNY jest zapewnić bezproblemową ścieżkę sygnału audio dla strumieni wejściowych i wyjściowych urządzeń mobilnych, zgodnie z definicją braku błędów mierzonych w trakcie testu trwającego 1 minutę na ścieżkę. Testuj za pomocą narzędzia [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) „Automated Glitch Test”.

Do testu potrzebne są klucze sprzętowe audio typu loopback używane bezpośrednio do gniazda słuchawek 3, 5 mm lub w połączeniu z przejściówką z USB-C na 3, 5 mm. Wszystkie porty wyjściowe audio MUSZĄ zostać przetestowane.

OboeTester obsługuje obecnie ścieżki AAudio, dlatego musisz przetestować te kombinacje pod kątem błędów:

Tryb Perf	Udostępnianie	Częstotliwość próbkowania wyjściowego	Chans	Piosenki zewnętrzne
LOW_LATENCY	WYJĄTKOWA OFERTA	NIEOKREŚLONY	1	2
LOW_LATENCY	WYJĄTKOWA OFERTA	NIEOKREŚLONY	2	1
LOW_LATENCY	UDOSTĘPNIONY	NIEOKREŚLONY	1	2
LOW_LATENCY	UDOSTĘPNIONY	NIEOKREŚLONY	2	1
BRAK	UDOSTĘPNIONY	48000	1	2
BRAK	UDOSTĘPNIONY	48000	2	1
BRAK	UDOSTĘPNIONY	44100	1	2
BRAK	UDOSTĘPNIONY	44100	2	1
BRAK	UDOSTĘPNIONY	16000	1	2
BRAK	UDOSTĘPNIONY	16000	2	1

Niezawodny strumień MUSI spełniać kryteria współczynnika sygnału do szumu (SNR) i całkowite zniekształcenie harmoniczne (THD) dla sinusa 2000 Hz.

Przetwornik	THD	numer SNR
główny wbudowany głośnik, mierzony za pomocą zewnętrznego mikrofonu referencyjnego	< 3,0%	>= 50 dB
główny wbudowany mikrofon, mierzony za pomocą zewnętrznego głośnika referencyjnego	< 3,0%	>= 50 dB
wbudowane analogowe gniazda słuchawek 3,5 mm, przetestowane z użyciem przejściówki typu loopback	<1%	>= 60 dB
Ładowarki USB dostarczone z telefonem, przetestowane z użyciem przejściówki typu loopback	&lt; 1%	>= 60 dB

7.9. Rzeczywistość wirtualna

Android udostępnia interfejsy API i obiekty do tworzenia „rzeczywistości wirtualnej” aplikacje (VR), w tym wysokiej jakości rzeczywistość wirtualną na urządzeniach mobilnych; Implementacje na urządzeniach MUSZĄ poprawnie 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 obsługuje stereoskopowe renderowanie powiadomień i wyłącza komponenty interfejsu monokularowego systemu, gdy aplikacja VR skupia się na użytkowniku.

7.9.2. Tryb rzeczywistości wirtualnej – wysoka wydajność

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

• [C-1-1] MUSI mieć co najmniej 2 rdzenie fizyczne.
• [C-1-2] MUSI zadeklarować funkcję android.hardware.vr.high_performance.
• [C-1-3] MUSI obsługiwać tryb utrzymującej wydajność.
• [C-1-4] Jest Zdecydowanie ZALECANY do obsługi OpenGL ES 3.2.
• [C-1-5] MUSI obsługiwać wartość android.hardware.vulkan.level 0.
• MUSI obsługiwać system android.hardware.vulkan.level w wersji 1 lub nowszej.
• [C-1-6] MUSI implementować EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace oraz udostępniać rozszerzenia z listy dostępnych rozszerzeń EGL.
• [C-1-8] MUSI zaimplementować GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures i udostępnić rozszerzenia z listy dostępnych rozszerzeń GL.
• [C-SR] Zdecydowanie ZALECANE jest wdrożenie GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture i udostępnienie rozszerzeń na liście dostępnych rozszerzeń GL.
• [C-SR] Zdecydowanie ZALECANE jest obsługa platformy Vulkan 1.1.
• [C-SR] Zdecydowanie ZALECANE jest wdrożenie VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing i VK_KHR_shared_presentable_image oraz umieszczenie ich na liście dostępnych rozszerzeń Vulkan.
• [C-SR] Zdecydowanie ZALECANE jest udostępnienie co najmniej jednej rodziny kolejek Vulkan, w której flags zawiera zarówno VK_QUEUE_GRAPHICS_BIT, jak i VK_QUEUE_COMPUTE_BIT, a queueCount to co najmniej 2.
• [C-1-7] GPU i wyświetlacz MUSZĄ synchronizować dostęp do wspólnego przedniego bufora, tak aby treści VR z prędkością 60 kl./s były wyświetlane z użyciem naprzemiennego renderowania treści VR z 2 kontekstami renderowania bez widocznych zakłóceń.
• [C-1-9] MUSI wdrożyć obsługę flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT zgodnie z opisem w NDK.
• [C-1-10] MUSI zaimplementować obsługę elementów AHardwareBuffer z dowolną kombinacją flag wykorzystania AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT w przypadku co najmniej tych formatów: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] Zdecydowanie ZALECANE jest obsługa alokacji zasobów typu AHardwareBuffer z więcej niż 1 warstwą oraz flagami i formatami określonymi w zasadzie C-1-10.
• [C-1-11] MUSI obsługiwać dekodowanie H.264 z szybkością co najmniej 3840 x 2160 przy 30 kl./s, skompresowaną do średniej szybkości 40 Mb/s (odpowiednik 4 instancji 1920 x 1080 przy 30 kl./s do 10 Mb/s lub 2 instancji przy 1920 x 6 Mb/s).
• [C-1-12] MUSI obsługiwać HEVC i VP9; MUSI obsługiwać dekodowanie 0 x 3 Mb/s przy szybkości co najmniej 1920 x 1080 przy 30 kl./s po skompresowaniu do średnio 10 Mb/s i wymaga dekodowania szybkości 3840 x 2160 przy szybkości 30 kl./s do 1 Mb/s (przy prędkości 30 kl./s do 20 Mb/s).
• [C-1-13] MUSI obsługiwać interfejs HardwarePropertiesManager.getDeviceTemperatures API i zwracać dokładne wartości temperatury skóry.
• [C-1-14] MUSI mieć wbudowany ekran, a jego rozdzielczość MUSI wynosić co najmniej 1920 x 1080 pikseli.
• [C-SR] Zdecydowanie zalecana rozdzielczość wyświetlacza to co najmniej 2560 x 1440.
• [C-1-15] Wyświetlacz MUSI aktualizować się z częstotliwością co najmniej 60 Hz w trybie VR.
• [C-1-17] Wyświetlacz MUSI obsługiwać tryb o małej trwałości o czasie trwania wynoszącym ≤ 5 milisekund, przy czym trwałość jest definiowana jako czas, przez jaki piksel emituje światło.
• [C-1-18] MUSI obsługiwać Bluetooth 4.2 oraz Bluetooth LE Data Length Data Extension w sekcji 7.4.3.
• [C-1-19] MUSI obsługiwać i prawidłowo zgłaszać 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] Zdecydowanie ZALECANE jest obsługa typu kanału bezpośredniego TYPE_HARDWARE_BUFFER we wszystkich wymienionych powyżej typach kanałów bezpośrednich.
• [C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru w przypadku urządzenia android.hardware.hifi_sensors, opisane w sekcji 7.3.9.
• [C-SR] Zdecydowanie ZALECANE jest obsługa funkcji android.hardware.sensor.hifi_sensors.
• [C-1-22] Opóźnienie ulotki dla ruchu do fotonów musi być nie większe niż 28 milisekund.
• [C-SR] Zdecydowanie ZALECANE jest, aby czas oczekiwania dla pełnego ruchu względem fotonów nie przekraczał 20 milisekund.
• [C-1-23] MUSI mieć współczynnik pierwszej klatki, czyli stosunek jasności pierwszej klatki po przejściu z czarnego do białego do jasności białych pikseli w stanie nieruchomym, na poziomie co najmniej 85%.
• [C-SR] Zdecydowanie ZALECANE jest, aby współczynnik pierwszej klatki wynosił co najmniej 90%.
• MOGĄ udostępniać wyłączne rdzeń aplikacji na pierwszym planie i obsługiwać interfejs API Process.getExclusiveCores w celu zwracania liczby rdzeni procesora dostępnych wyłącznie dla aplikacji na pierwszym planie.

Jeśli obsługiwana jest funkcja podstawowa, która obejmuje:

• [C-2-1] NIE MOŻE zezwalać na uruchamianie w niej żadnych innych procesów w przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE umożliwiać uruchomienie niektórych procesów jądra w razie potrzeby.

7.10. Reakcja na dotyk

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

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

O klasie wydajności mediów w przypadku implementacji urządzenia można uzyskać z interfejs API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Wymagania klasy wydajności multimediów są zdefiniowane dla każdej wersji Androida, zaczynając od R (wersja 30). Wartość specjalna 0 oznacza, że urządzenie nie jest klasa skuteczności multimediów.

Jeśli implementacje urządzeń zwracają wartość inną niż zero dla argumentu android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

• [C-1-1] MUSI zwracać co najmniej wartość android.os.Build.VERSION_CODES.R.

• [C-1-2] MUSI być implementacją na urządzeniach mobilnych.

• [C-1-3] MUSI spełniać wszystkie wymagania dotyczące klasy „Media Performance Class” opisana w sekcji 2.2.7.

Szczegółowe informacje znajdziesz w sekcji 2.2.7. .

8. Wydajność i moc

Niektóre kryteria dotyczące minimalnej wydajności i mocy mają kluczowe znaczenie dla wygody użytkowników i wpływają na podstawowe założenia, jakie deweloperzy powinni mieć przy tworzeniu aplikacji.

8.1. Spójność wrażeń użytkownika

Użytkownik może spełnić pewne wymagania minimalne, jeśli chodzi o stały czas reakcji i liczby klatek w aplikacjach i grach. W ten sposób można zapewnić użytkownikom płynny interfejs. Implementacje urządzeń, w zależności od typu urządzenia, MOGĄ wiązać się z wymiernymi wymaganiami dotyczącymi czasu oczekiwania w interfejsie i przełączania zadań. Opisaliśmy to w sekcji 2.

8.2. Skuteczność dostępu do plików

Określenie wspólnej wartości bazowej dla stałej wydajności dostępu do plików w prywatnym miejscu na dane aplikacji (partycja /data) umożliwia deweloperom aplikacji odpowiednie oczekiwania, które ułatwią projektowanie oprogramowania. Implementacje urządzeń, w zależności od typu urządzenia, MOGĄ BYĆ określone wymagania opisane w sekcji 2 dotyczące następujących operacji odczytu i zapisu:

• Wydajność sekwencyjnego zapisu. Pomiar ten polega na zapisaniu pliku o rozmiarze 256 MB w buforze zapisu o wielkości 10 MB.
• Losowa wydajność zapisu. Pomiar ten polega na zapisaniu pliku o wielkości 256 MB z użyciem bufora zapisu o wielkości 4 KB.
• Wydajność sekwencyjnego odczytu. Pomiar dokonywany jest przez odczytanie pliku o wielkości 256 MB z użyciem bufora zapisu o wielkości 10 MB.
• Losowa wydajność odczytu. Pomiar dokonywany jest przez odczytanie pliku o wielkości 256 MB z użyciem bufora zapisu o wielkości 4 KB.

8.3. Tryby oszczędzania energii

Jeśli implementacje urządzeń obejmują funkcje usprawniające zarządzanie energią, które są uwzględnione w AOSP (np. zasobnik gotowości aplikacji, uśpienie) lub rozszerzenie funkcji, które nie stosują bardziej restrykcyjnych ograniczeń niż zasobnik gotowości aplikacji, to:

• [C-1-1] NIE MOŻE odchodzić od implementacji AOSP w zakresie wyzwalania, konserwacji, wybudzania ani używania globalnych ustawień systemu w trybach C-1-1 i Trybów oszczędzania energii.
• [C-1-2] NIE MOŻE odchodzić od implementacji AOSP w zakresie użycia ustawień globalnych do zarządzania ograniczaniem zadań, alarmów i sieci dla aplikacji w każdym zasobniku w trybie gotowości aplikacji.
• [C-1-3] NIE MOŻE odbiegać od implementacji AOSP w przypadku liczby zasobników gotowości aplikacji używanych w trybie gotowości aplikacji.
• [C-1-4] MUSI zaimplementować zasobniki gotowości aplikacji i uśpienie zgodnie z opisem w artykule Zarządzanie energią.
• [C-1-5] MUSI zwracać urządzenie true za PowerManager.isPowerSaveMode(), gdy urządzenie jest w trybie oszczędzania energii.
• [C-SR] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości włączenia i wyłączenia funkcji oszczędzania baterii.
• [C-SR] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości wyświetlania wszystkich aplikacji zwolnionych z trybów czuwania aplikacji i uśpienia.

Jeśli implementacje urządzeń rozszerzają funkcje zarządzania energią dostępne w AOSP i to rozszerzenie stosuje bardziej rygorystyczne ograniczenia niż zasobnik gotowości do rzadkich aplikacji, zapoznaj się z sekcją 3.5.1.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ wdrożyć dowolny lub wszystkie 4 stany zasilania w trybie uśpienia zdefiniowany w dokumencie Advanced Configuration and Power Interface (ACPI).

Jeśli implementacje urządzeń implementują stany zasilania S4 określone przez ACPI:

• [C-1-1] MUSI przejść w ten stan tylko wtedy, gdy użytkownik wykona wyraźne działanie, aby przełączyć urządzenie w stan nieaktywny (np. przez zamknięcie pokrywy, która jest fizycznie częścią urządzenia, lub wyłączenie pojazdu bądź telewizora), a także przed ponownym włączeniem urządzenia (np. przez otwarcie pokrywy lub ponowne włączenie pojazdu lub telewizora).

Jeśli implementacje urządzeń implementują stany zasilania S3 zdefiniowane przez ACPI:

• [C-2-1] MUSI spełniać powyższe wymagania C-1-1 lub MUSI wprowadzać stan S3 tylko wtedy, gdy aplikacje innych firm nie potrzebują zasobów systemowych (np. ekranu czy procesora).

  I na odwrót, MUSI wyjść ze stanu S3, gdy aplikacje innych firm potrzebują zasobów systemowych, zgodnie z opisem w tym pakiecie SDK.

  Na przykład, gdy aplikacje innych firm żądają, aby ekran był włączony przez FLAG_KEEP_SCREEN_ON lub aby procesor działał przez PARTIAL_WAKE_LOCK, urządzenie NIE MOŻE przejść w stan S3, chyba że użytkownik zgodnie z opisem w punkcie C-1-1 użytkownik podejmie wyraźne działanie w celu ustanowienia urządzenia w stanie nieaktywnym. I na odwrót: w momencie uruchomienia zadania realizowanego przez aplikacje innych firm za pomocą JobScheduler lub pobrania Komunikacji w chmurze Firebase do aplikacji innych firm urządzenie MUSI wyjść ze stanu S3, chyba że użytkownik przełączy je w stan nieaktywny. Nie są to wyczerpujące przykłady, a AOSP wykorzystuje liczne sygnały wybudzenia, które aktywują dany stan.

8.4. Rachunkowanie zużycia energii

Dokładniejsze liczenie i raportowanie zużycia energii zapewnia deweloperom aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorca wykorzystania energii przez aplikację.

Implementacje na urządzeniach:

• [SR] ZALECANE jest podanie profilu zasilania dla poszczególnych komponentów, który określa wartość bieżącego zużycia energii przez poszczególne komponenty sprzętowe oraz przybliżone zużycie baterii przez komponenty w danym okresie, zgodnie z dokumentem w witrynie Android Open Source Project.
• [SR] Zdecydowanie ZALECANE jest raportowanie wszystkich wartości zużycia energii w miliiamperach godzin (mAh).
• [SR] Zdecydowanie ZALECANE jest raportowanie zużycia energii przez procesor według identyfikatora UID każdego procesu. Projekt Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [SR] Zdecydowanie ZALECANE jest udostępnienie tej informacji deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.
• MUSI być przypisana do samego komponentu sprzętowego, jeśli nie można przypisać do aplikacji zużycia energii przez komponent sprzętowy.

8.5. Stała skuteczność

W przypadku długotrwałych aplikacji o wysokiej wydajności wydajność może się znacznie wahać ze względu na inne aplikacje działające w tle lub ograniczenie procesora z powodu limitów temperatury. Android ma interfejsy automatyczne, dzięki czemu, gdy urządzenie ma odpowiednie możliwości, główna aplikacja na pierwszym planie może zażądać, aby system zoptymalizował przydział zasobów, aby uwzględnić takie wahania.

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo przekazywać informacje o obsłudze trybu zrównoważonej wydajności za pomocą metody interfejsu API PowerManager.isSustainedPerformanceModeSupported().

• POWINNA obsługiwać tryb stałej wydajności.

Jeśli implementacje urządzeń zgłaszają obsługę trybu trwałej wydajności:

• [C-1-1] MUSI zapewniać aplikacji znajdującej się na pierwszym planie stały poziom wydajności przez co najmniej 30 minut, gdy aplikacja o to poprosi.
• [C-1-2] MUSI spełniać warunki interfejsu API Window.setSustainedPerformanceMode() i innych powiązanych interfejsów API.

Jeśli implementacje urządzeń obejmują co najmniej 2 rdzenie procesora, są to:

• POWINIEN podać co najmniej 1 rdzeń wyłączny, który może być zarezerwowany przez aplikację główną na pierwszym planie.

Jeśli implementacje urządzeń obsługują rezerwowanie 1 wyłącznego rdzenia dla aplikacji najwyższego poziomu:

• [C-2-1] MUSI raportować za pomocą metody API Process.getExclusiveCores() numery identyfikacyjne wyłącznych rdzeni, które mogą zostać zarezerwowane przez aplikację główną na pierwszym planie.
• [C-2-2] NIE MOŻE zezwalać na uruchamianie żadnych procesów w przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację na uruchamianie wyłącznych rdzeni, ale MOŻE zezwalać na uruchamianie niektórych procesów jądra systemu, jeśli jest to konieczne.

Jeśli implementacje urządzeń nie obsługują rdzeni na wyłączność, są to:

• [C-3-1] MUSI zwracać pustą listę za pomocą metody interfejsu API Process.getExclusiveCores().

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniach:

• [C-0-1] MUSI wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, zgodnie z definicją podaną w dokumentacji dotyczącej zabezpieczeń i uprawnień w interfejsach API w dokumentacji dla programistów aplikacji na Androida.

• [C-0-2] MUSI obsługiwać samodzielnie podpisane aplikacje bez konieczności uzyskania dodatkowych pozwoleń/certyfikatów od osób trzecich/urzędów. Zgodne urządzenia MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w tych podpunktach.

9.1. Uprawnienia

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać model uprawnień Androida zdefiniowany w dokumentacji dla deweloperów aplikacji na Androida. W szczególności MUSZĄ wymuszać każde uprawnienie zdefiniowane w sposób opisany w dokumentacji pakietu SDK. żadne uprawnienia nie mogą zostać pominięte, zmienione ani zignorowane.

• MOŻE dodać więcej uprawnień, pod warunkiem że ciągi identyfikatorów nowych uprawnień nie znajdują się w przestrzeni nazw android.\*.

• [C-0-2] Uprawnienia z ustawieniem protectionLevel o wartości PROTECTION_FLAG_PRIVILEGED MUSZĄ być przyznawane tylko aplikacjom wstępnie zainstalowanym w ramach chronionych ścieżek obrazu systemu oraz w podzbiorze uprawnień poszczególnych aplikacji umieszczonych na liście dozwolonych. Implementacja AOSP spełnia to wymaganie, odczytując i uznając uprawnienia wszystkich aplikacji z listy dozwolonych z plików w ścieżce etc/permissions/ i używając ścieżki system/priv-app jako ścieżki uprzywilejowanej.

Uprawnienia z poziomem ochrony „Niebezpieczne” to uprawnienia w czasie działania. Aplikacje z: targetSdkVersion > 22 wysyłanie o niej prośby w czasie działania.

Implementacje na urządzeniach:

• [C-0-3] MUSI wyświetlić specjalny interfejs, w którym użytkownik może zdecydować, czy przyznać wymagane uprawnienia w czasie działania, oraz udostępnić interfejs do zarządzania uprawnieniami w czasie działania.
• [C-0-4] MUSI mieć tylko jedną implementację obu interfejsów użytkownika.
• [C-0-5] NIE MOŻE przyznawać żadnych uprawnień w czasie działania zainstalowanym wstępnie aplikacjom, chyba że:
  • Zgodę użytkownika można uzyskać, zanim aplikacja jej użyje.
  • Uprawnienia w czasie działania są powiązane ze wzorcem intencji, dla którego ustawiona jest wstępnie zainstalowana aplikacja jako domyślny moduł obsługi.
• [C-0-6] MUSI przyznawać uprawnienia android.permission.RECOVER_KEYSTORE tylko tym aplikacjom systemowym, które rejestrują prawidłowo zabezpieczonego agenta odzyskiwania. Prawidłowo zabezpieczony agent przywracania to działający na urządzeniu agent oprogramowania, który synchronizuje się ze zdalną pamięcią urządzenia, która jest wyposażona w bezpieczny sprzęt zapewniający odpowiedni poziom zabezpieczeń lub lepszy niż jest opisany w usłudze Google Cloud Key Vault. Pozwala to zapobiegać atakom brute-force na podstawie współczynnika wiedzy na ekranie blokady.

Implementacje na urządzeniach:

• [C-0-7] MUSI przestrzegać właściwości dostępu do lokalizacji na Androidzie, gdy aplikacja prosi o dostęp do lokalizacji lub danych o aktywności fizycznej za pomocą standardowego interfejsu API Androida lub zastrzeżonego mechanizmu. Dane te obejmują między innymi:

  • Lokalizacja urządzenia (np. szerokość i długość geograficzna).
  • Informacje, które mogą służyć do określenia lub oszacowania lokalizacji urządzenia (np. identyfikator SSID, identyfikator BSSID, identyfikator sieci komórkowej lub lokalizacja sieci, z którą urządzenie jest połączone).
  • Aktywność fizyczna lub klasyfikacja aktywności użytkownika.

Mówiąc bardziej szczegółowo o implementacjach na urządzeniach:

• [C-0-8] MUSI uzyskać zgodę użytkownika na dostęp do dane o lokalizacji czy aktywności fizycznej.
• [C-0-9] MUSI przyznawać uprawnienia w czasie działania TYLKO aplikacji, która zawiera wystarczających uprawnień zgodnie z opisem w pakiecie SDK. Przykład: TelephonyManager#getServiceState wymaga android.permission.ACCESS_FINE_LOCATION.

Uprawnienia można oznaczyć jako objęte ograniczeniami – wpływa to na ich działanie.

• [C-0-10] Uprawnienia oznaczone flagą hardRestricted NIE MOGĄ być przyznawane aplikacji, chyba że:

  • Plik APK aplikacji znajduje się na partycji systemowej.
  • Użytkownik przypisuje do aplikacji rolę powiązaną z uprawnieniami hardRestricted.
  • Instalator przydziela aplikacji hardRestricted.
  • Aplikacja otrzymuje uprawnienia hardRestricted w wcześniejszej wersji Androida.

• [C-0-11] Aplikacje z uprawnieniem softRestricted MUSZĄ mieć tylko ograniczony dostęp i NIE MOGĄ mieć pełnego dostępu, dopóki nie znajdą się na liście dozwolonych zgodnie z opisem w pakiecie SDK, gdzie dla każdego uprawnienia softRestricted (np. READ_EXTERNAL_STORAGE) jest zdefiniowany pełny i ograniczony dostęp.

Jeśli implementacje urządzeń umożliwiają użytkownikowi wybór aplikacji, które mogą wyświetlać się nad innymi aplikacjami wykorzystującymi intencję ACTION_MANAGE_OVERLAY_PERMISSION, użytkownik:

• [C-2-1] MUSI mieć pewność, że wszystkie działania z filtrami intencji dla intencji ACTION_MANAGE_OVERLAY_PERMISSION mają ten sam ekran interfejsu niezależnie od tego, jaka aplikacja inicjuje aplikację czy jakie informacje podaje.

9.2. UID i izolacja procesów

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja działa jako unikalny identyfikator UID systemu Unixstyle i w osobnym procesie.
• [C-0-2] MUSI obsługiwać wiele aplikacji z tym samym identyfikatorem użytkownika Linuksa, o ile są one prawidłowo podpisane i skonstruowane, zgodnie z opisem w dokumentacji zabezpieczeń i uprawnień.

9.3. Uprawnienia systemu plików

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać model uprawnień dostępu do plików na Androidzie zgodnie z definicją w dokumentacji dotyczącej zabezpieczeń i uprawnień.

9.4. Alternatywne środowiska wykonawcze

Implementacje na urządzeniach MUSZĄ zachowywać spójność z modelem zabezpieczeń i uprawnień Androida, nawet jeśli obejmują środowiska wykonawcze, w których są wykonywane aplikacje korzystające z innego oprogramowania lub technologii niż format wykonywalny Dalvik lub kod natywny. Krótko mówiąc:

• [C-0-1] Alternatywne środowiska wykonawcze MUSZĄ być aplikacjami na Androida i być zgodne ze standardowym modelem zabezpieczeń Androida opisanym w sekcji sekcja 9.

• [C-0-2] Alternatywne środowiska wykonawcze NIE MOGĄ mieć dostępu do zasobów chronionych przez uprawnienia, które nie są wymagane w pliku AndroidManifest.xml środowiska wykonawczego za pomocą tagu <uses-permission> .

• [C-0-3] Alternatywne środowiska wykonawcze NIE MOGĄ zezwalać aplikacjom na korzystanie z funkcji chronionych uprawnieniami Androida ograniczonych do aplikacji systemowych.

• [C-0-4] Alternatywne środowiska wykonawcze MUSZĄ być zgodne z modelem piaskownicy Androida, a zainstalowane aplikacje korzystające z alternatywnego środowiska NIE MOGĄ wykorzystywać środowiska piaskownicy dla żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida korzystających ze wspólnego identyfikatora użytkownika i certyfikatu podpisywania.

• [C-0-5] Alternatywne środowiska wykonawcze NIE MOGĄ uruchamiać się w środowiskach piaskownicy odpowiadających innym aplikacjom na Androida, przyznawać do nich dostępu ani przyznawać im do nich dostępu.

• [C-0-6] Alternatywnego środowiska wykonawczego NIE MOŻNA uruchamiać razem z innymi aplikacjami ani przyznawać im żadnych uprawnień superużytkownika (roota) ani żadnego innego identyfikatora użytkownika.

• [C-0-7] Jeśli plik .apk alternatywnych środowisk wykonawczych znajduje się w obrazie systemowym implementacji urządzenia, MUSI być podpisany kluczem innym niż klucz używany do podpisywania innych aplikacji uwzględnionych w implementacjach na urządzeniu.

• [C-0-8] Podczas instalowania aplikacji alternatywne środowiska wykonawcze MUSZĄ uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację.

• [C-0-9] Gdy aplikacja musi korzystać z zasobu urządzenia, do którego są przypisane uprawnienia Androida (takie jak Aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI informować użytkownika, że aplikacja będzie miała dostęp do tego zasobu.

• [C-0-10] Jeśli środowisko wykonawcze nie rejestruje możliwości aplikacji w ten sposób, podczas instalowania aplikacji korzystających z tego środowiska wykonawczego MUSI ono zawierać listę wszystkich uprawnień samego środowiska wykonawczego.

• Alternatywne środowiska wykonawcze MUSZĄ instalować aplikacje za pomocą interfejsu PackageManager w osobnych piaskownicy Androida (identyfikatory użytkowników systemu Linux itp.).

• Alternatywne środowiska wykonawcze MOGĄ udostępniać jedną piaskownicę Androida współużytkowaną przez wszystkie aplikacje korzystające z alternatywnego środowiska wykonawczego.

9.5. Obsługa wielu użytkowników

Android zapewnia obsługę wielu użytkowników i pełną izolację użytkowników.

• Implementacje urządzeń MOGĄ BYĆ, ale NIE POWINNY być włączane dla wielu użytkowników, jeśli korzystają z nośników wymiennych jako podstawowej pamięci zewnętrznej.

Jeśli implementacje urządzeń obejmują wielu użytkowników:

• [C-1-1] MUSI spełniać następujące wymagania związane z obsługą wielu użytkowników.
• [C-1-2] MUSI wdrożyć dla każdego użytkownika model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień w interfejsach API.
• [C-1-3] MUSI mieć oddzielne i odizolowane katalogi współdzielonej pamięci aplikacji (/sdcard) dla każdej instancji użytkownika.
• [C-1-4] MUSI mieć pewność, że aplikacje należące do danego użytkownika i uruchamiane w jego imieniu nie mogą wyświetlać, odczytywać ani zapisywać plików należących do innych użytkowników, nawet jeśli dane obu użytkowników są przechowywane w tym samym woluminie lub w tym samym systemie plików.
• [C-1-5] MUSI szyfrować zawartość karty SD, gdy jest włączony wielu użytkowników, przy użyciu klucza zapisanego wyłącznie na niewymiennym nośniku dostępnym tylko dla systemu, jeśli implementacje urządzenia korzystają z nośników wymiennych dla interfejsów API pamięci zewnętrznej. Ponieważ uniemożliwi to odczytanie multimediów na komputerze hosta, trzeba będzie wdrożyć urządzenia w systemie MTP lub podobnym, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika.

9.6 Ostrzeżenie SMS-a specjalnego

Android umożliwia ostrzeganie użytkowników o wychodzących SMS-ach premium. SMS-y specjalne to SMS-y wysyłane do usługi zarejestrowanej u operatora, za którą użytkownik może być obciążony.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.telephony, będą to:

• [C-1-1] MUSI ostrzegać użytkowników przed wysłaniem SMS-a na numery identyfikowane przez wyrażenia regularne zdefiniowane w pliku /data/misc/sms/codes.xml na urządzeniu. Rozwiązania Android Open Source Project, które opracowujemy na potrzeby platformy Android, to implementacja, która spełnia to wymaganie.

9.7. Funkcje zabezpieczeń

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń zarówno jądra, jak i platformy, jak opisano poniżej.

Piaskownica Androida obejmuje funkcje korzystające z systemu Security-Extended Linux (SELinux), obowiązkowej kontroli dostępu (MAC), seccomp sandbox (piaskownica seccomp) i inne funkcje zabezpieczeń jądra systemu Linux. Implementacje na urządzeniach:

• [C-0-1] MUSI zachować zgodność z istniejącymi aplikacjami, nawet jeśli SELinux lub inne funkcje zabezpieczeń są wdrożone poniżej platformy Androida.
• [C-0-2] NIE MOŻE mieć widocznego interfejsu użytkownika po wykryciu naruszenia bezpieczeństwa i zablokowaniu go przez funkcję zabezpieczeń wdrożoną poniżej platformy Androida, ale MOŻE mieć widoczny interfejs w przypadku wystąpienia niezablokowanego naruszenia zabezpieczeń, które skutkuje udanym exploitem.
• [C-0-3] NIE MOŻE udostępniać użytkownikowi ani deweloperowi aplikacji SELinux ani żadnych innych funkcji zabezpieczeń wdrożonych poniżej platformy Androida.
• [C-0-4] NIE MOŻE zezwalać aplikacji, która może wpływać na inną aplikację za pomocą interfejsu API (takiej jak interfejs Device Administration API), aby konfigurować zasady naruszające zgodność.
• [C-0-5] MUSI podzielić platformę multimediów na wiele procesów, aby możliwe było węższe przyznanie dostępu każdemu z nich, zgodnie z opisem na stronie projektu Android Open Source.
• [C-0-6] MUSI wdrożyć mechanizm piaskownicy aplikacji w jądrze, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnej zasady z programów wielowątkowych. Nadrzędny projekt Android Open Source Project spełnia to wymaganie przez włączenie seccomp-BPF z synchronizacją grup wątków (TSYNC) zgodnie z opisem w sekcji Konfiguracja jądra na stronie source.android.com.

Integralność jądra i funkcje samoochrony stanowią integralne elementy zabezpieczeń Androida. Implementacje na urządzeniach:

• [C-0-7] MUSI wdrożyć mechanizmy ochrony przed przepełnieniem bufora stosu jądra. Przykłady takich mechanizmów to CC_STACKPROTECTOR_REGULAR i CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] MUSI wdrożyć rygorystyczną ochronę pamięci jądra, w której kod wykonywalny jest tylko do odczytu, dane tylko do odczytu są niewykonywalne i niemożliwe do zapisu, a dane, które można zapisać, nie są możliwe do wykonania (np. CONFIG_DEBUG_RODATA lub CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] MUSI wdrożyć statyczne i dynamiczne ograniczenia rozmiaru obiektów do sprawdzania kopii między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY) na urządzeniach, które pierwotnie były wysyłane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-10] NIE MOŻE uruchamiać pamięci w przestrzeni użytkownika podczas wykonywania w trybie jądra (np. sprzętowego PXN lub emulowanego przez CONFIG_CPU_SW_DOMAIN_PAN bądź CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które zostały pierwotnie wysłane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-11] NIE MOŻE odczytywać ani zapisywać pamięci przestrzeni użytkownika w jądrze poza zwykłymi interfejsami API umożliwiającymi korzystanie z funkcji kopiowania przez użytkownika (np. sprzętowym numerem PAN lub emulowanym przez CONFIG_CPU_SW_DOMAIN_PAN bądź CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które pierwotnie były wysyłane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-12] MUSI wdrożyć izolację tabel stron jądra, jeśli sprzęt jest podatny na ataki CVE-2017-5754 na wszystkich urządzeniach oryginalnie wysłanych z interfejsem API na poziomie 28 lub wyższym (np. CONFIG_PAGE_TABLE_ISOLATION lub CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] MUSI wdrożyć wzmacnianie prognozowania gałęzi, jeśli sprzęt jest podatny na ataki CVE-2017-5715 na wszystkich urządzeniach, które pierwotnie były wysyłane z interfejsem API na poziomie 28 lub wyższym (np. CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] Zdecydowanie ZALECANE jest zachowanie danych jądra, które są zapisywane wyłącznie podczas inicjowania, oznaczone jako przeznaczone tylko do odczytu po zainicjowaniu (np. __ro_after_init).

• [C-SR] Zdecydowanie ZALECANE jest zastosowanie losowego układu kodu jądra i pamięci oraz unikanie ekspozycji, które mogłyby negatywnie wpłynąć na randomizację (np. CONFIG_RANDOMIZE_BASE z entropią programu rozruchowego przez /chosen/kaslr-seed Device Tree node lub EFI_RNG_PROTOCOL).

• [C-SR] Zdecydowanie ZALECANE jest włączenie integralności procesu sterowania (CFI) w jądrze, co zapewnia dodatkową ochronę przed atakami polegającymi na ponownym użyciu kodu (np. CONFIG_CFI_CLANG i CONFIG_SHADOW_CALL_STACK).

• [C-SR] Zdecydowanie ZALECANE jest, aby nie wyłączać funkcji Control-Flow Integrity (CFI), stosu wywołań obserwacyjnych (SCS) ani Integer Overflow Sanitization (IntSan) w komponentach, które mają włączoną tę funkcję.
• [C-SR] Zdecydowanie ZALECANE jest włączenie CFI, SCS i IntSan we wszystkich dodatkowych komponentach przestrzeni użytkownika zapewniających bezpieczeństwo, zgodnie z opisem w CFI i IntSan.
• [C-SR] Zdecydowanie ZALECANE jest włączenie inicjowania stosu w jądrze w celu uniemożliwienia użycia niezainicjowanych zmiennych lokalnych (CONFIG_INIT_STACK_ALL lub CONFIG_INIT_STACK_ALL_ZERO). Ponadto implementacje urządzeń NIE POWINNO przyjmować wartości używanej przez kompilator do inicjowania zasobów lokalnych.
• [C-SR] Zdecydowanie ZALECANE jest włączenie inicjowania stosu w jądrze w celu uniemożliwienia korzystania z niezainicjowanych alokacji sterty (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). NIE POWINNY jest też zakładać wartości używanej przez jądro do inicjowania tych alokacji.

Jeśli implementacje urządzeń korzystają z jądra systemu Linux:

• [C-1-1] MUSI zaimplementować SELinux.
• [C-1-2] MUSI ustawić SELinux w tryb globalnego egzekwowania.
• [C-1-3] MUSI skonfigurować wszystkie domeny w trybie wymuszania. Nie są dozwolone żadne domeny w trybie mniej rygorystycznym, w tym domeny specyficzne dla urządzenia lub dostawcy.
• [C-1-4] NIE MOŻE modyfikować, pomijać ani zastępować reguł nigdy, które znajdują się w folderze systemowym/sepolicy dostępnym w nadchodzącym projekcie Android Open Source Project (AOSP), a zasada MUSI skompilować wszystkie obecne reguły, zarówno dla domen AOSP SELinux, jak i specyficznych dla urządzeń/dostawców.
• [C-1-5] MUSI uruchamiać aplikacje innych firm kierowane na interfejs API na poziomie 28 lub wyższym w poszczególnych piaskownicy SELinux z ograniczeniami SELinux dla poszczególnych aplikacji w katalogach prywatnych danych.
• POWINIEN zachować domyślną zasadę SELinux w folderze systemowym/sekwencyjnym nadrzędnego projektu Android Open Source i dodać ją do tej zasady jedynie na potrzeby konfiguracji w określonym urządzeniu.

Jeśli implementacje urządzeń zostały już wdrożone na starszej wersji Androida i w ramach aktualizacji oprogramowania systemowego nie spełniają wymagań [C-1-1] i [C-1-5], MOGĄ zostać zwolnione z tych wymagań.

Jeśli implementacje urządzeń korzystają z jądra innego niż Linux:

• [C-2-1] MUSI używać obowiązkowego systemu kontroli dostępu równoważnego z SELinux.

Android zawiera wiele zaawansowanych funkcji obrony, które są wbudowane w zabezpieczenia urządzenia.

9.8. Prywatność

9.8.1. Historia wykorzystania

Android przechowuje historię wyborów użytkownika i zarządza nią w usłudze UsageStatsManager.

Implementacje na urządzeniach:

• [C-0-1] MUSI przechowywać taką historię użytkownika w rozsądnym czasie.
• [SR] Zdecydowanie ZALECANE jest zachowanie domyślnie skonfigurowanego 14-dniowego okresu przechowywania w implementacji AOSP.

Android przechowuje zdarzenia systemowe za pomocą identyfikatorów StatsLog i zarządza taką historią za pomocą interfejsów StatsManager i System API IncidentManager.

Implementacje na urządzeniach:

• [C-0-2] MUSI zawierać tylko pola oznaczone symbolem DEST_AUTOMATIC w raporcie o incydentach utworzonym przez klasę Systemowego interfejsu API IncidentManager.
• [C-0-3] NIE MOŻE używać identyfikatorów zdarzeń systemu do rejestrowania zdarzeń innych niż opisane w dokumentach dotyczących pakietu SDK StatsLog. W przypadku rejestrowania dodatkowych zdarzeń systemowych mogą one używać innego identyfikatora atomu z zakresu od 100 000 do 200 000.

9.8.2. Nagrywam

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE od razu ładować ani rozpowszechniać komponentów oprogramowania, które wysyłają z urządzenia prywatne informacje (np. o naciśnięciach klawiszy, tekście wyświetlanym na ekranie, zgłaszaniu błędów) bez zgody użytkownika lub bez wyraźnego powiadomienia o trwających zmianach.
• [C-0-2] MUSI wyświetlać i uzyskiwać wyraźną zgodę użytkownika na wykorzystanie danych wrażliwych informacje wyświetlane na ekranie użytkownika, przechwycone za każdym razem, przesyłanie ekranu lub nagrywanie ekranu jest włączone w MediaProjection lub zastrzeżone interfejsy API. NIE MOŻE zapewniać użytkownikom możliwości wyłączenia w przyszłości wyświetlania zgody użytkownika.
• [C-0-3] MUSI mieć włączone powiadomienie o trwającym czasie przesyłania ekranu lub nagrywanie ekranu. AOSP spełnia to wymaganie, wyświetlając ikonę powiadomień o trwającej aktywności na pasku stanu.

Jeśli implementacje urządzeń obejmują funkcje systemu, które umożliwiają przechwytywanie treści wyświetlanych na ekranie lub nagrywanie strumienia audio odtwarzanego na urządzeniu w inny sposób niż za pomocą interfejsu API systemu ContentCaptureService albo w inny zastrzeżony sposób opisany w artykule 9.8.6 Rejestrowanie treści:

• [C-1-1] MUSI mieć bieżące powiadomienie do użytkownika o włączeniu tej funkcji oraz aktywnym nagrywaniu i rejestrowaniu.

Jeśli implementacje urządzeń zawierają włączony od razu komponent, który umożliwia nagrywanie dźwięku otoczenia lub nagrywanie dźwięku odtwarzanego na urządzeniu w celu uzyskania przydatnych informacji o kontekście użytkownika:

• [C-2-1] NIE MOŻE przechowywać w trwałych pamięciach urządzeń ani przesyłać poza urządzenie nagranych, nieprzetworzonych plików audio ani żadnych formatów, które można przekonwertować z powrotem na oryginalny dźwięk lub faks, chyba że za wyraźną zgodą użytkownika.

9.8.3 Łączność

Jeśli urządzenia są wyposażone w port USB z obsługą trybu urządzenia peryferyjnego USB:

• [C-1-1] MUSI wyświetlić interfejs użytkownika z prośbą o zgodę na dostęp do zawartości pamięci współdzielonej przez port USB.

9.8.4 Ruch w sieci

Implementacje na urządzeniach:

• [C-0-1] MUSI zainstalować te same certyfikaty główne dla zaufanego systemu urzędu certyfikacji, które zostały dostarczone w nadrzędnym projekcie Android Open Source.
• [C-0-2] MUSI być wysyłany z pustym magazynem głównego urzędu certyfikacji użytkownika.
• [C-0-3] MUSI wyświetlać użytkownikowi ostrzeżenie informujące, że ruch sieciowy może być monitorowany po dodaniu głównego urzędu certyfikacji użytkownika.

Jeśli ruch z urządzenia jest kierowany przez VPN, takie implementacje urządzeń:

• [C-1-1] MUSI wyświetlać użytkownikowi ostrzeżenie:
  • Ruch w tej sieci może być monitorowany.
  • Ruch ten jest kierowany przez konkretną aplikację VPN udostępniającą tę sieć.

Jeśli implementacje urządzeń mają mechanizm, który jest domyślnie włączony po włączeniu i kieruje ruch danych sieci przez serwer proxy lub bramę VPN (np. wstępne wczytywanie usługi VPN z przyznanym ustawieniem android.permission.CONTROL_VPN), dzięki czemu:

• [C-2-1] MUSI prosić użytkownika o zgodę przed włączeniem tego mechanizmu, chyba że usługa VPN jest włączona przez kontroler zasad dotyczących urządzeń w narzędziu DevicePolicyManager.setAlwaysOnVpnPackage(). W takim przypadku użytkownik nie musi wyrażać osobnej zgody, a jedynie powinien zostać o tym powiadomiony.

Jeśli implementacje urządzeń uwzględniają finansowanie przez użytkownika, aby włączyć „stały VPN” aplikacji VPN innej firmy:

• [C-3-1] MUSI wyłączyć tę funkcję użytkownika dla aplikacji, które nie obsługują stałej sieci VPN w pliku AndroidManifest.xml przez ustawienie atrybutu SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

9.8.5 Identyfikatory urządzeń

Implementacje na urządzeniach:

• [C-0-1] MUSI uniemożliwiać dostęp do numeru seryjnego urządzenia, a w stosownych przypadkach także numeru IMEI/MEID, numeru seryjnego karty SIM oraz numeru IMSI (International Mobile Subscriber Identity) z aplikacji, chyba że aplikacja spełnia dowolne z tych wymagań:
  • to podpisana aplikacja operatora zweryfikowana przez producentów urządzeń.
  • Użytkownik otrzymał uprawnienie READ_PRIVILEGED_PHONE_STATE.
  • ma uprawnienia operatora określone w uprawnieniach operatora UICC.
  • to właściciel urządzenia lub właściciel profilu, który otrzymał uprawnienie READ_PHONE_STATE.
  • (tylko w przypadku numeru seryjnego karty SIM/identyfikatora ICCID) zgodnie z lokalnymi przepisami aplikacja wykrywa zmiany w tożsamości subskrybenta.

9.8.6 Rejestrowanie treści

Android, interfejs System API ContentCaptureService lub inne zastrzeżone środki, obsługuje mechanizm implementacji urządzeń w celu rejestrowania podanych niżej interakcji między aplikacjami a użytkownikiem.

• Tekst i grafiki renderowane na ekranie, w tym między innymi powiadomienia i dane wspomagające, które są renderowane przez interfejs AssistStructure API.
• Dane multimedialne, takie jak dźwięk i film, nagrane lub odtwarzane przez urządzenie.
• Zdarzenia dotyczące wprowadzania danych (np. klawisz, mysz, gest, głos, film i ułatwienia dostępu).
• Wszelkie inne zdarzenia przekazywane przez aplikację do systemu za pomocą interfejsu API Content Capture lub podobnego, zastrzeżonego interfejsu API o podobnych możliwościach.
• Jakikolwiek tekst i inne dane wysyłane przez TextClassifier API do systemu TextClassifier, tj.do usługi systemowej w celu zrozumienia znaczenia tekstu, a także generowania na jego podstawie przewidywań kolejnych działań.

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

• [C-1-1] MUSI szyfrować wszystkie takie dane, gdy są przechowywane na urządzeniu. Szyfrowanie MOŻE zostać zrealizowane z wykorzystaniem szyfrowania plików na Androidzie lub dowolnego mechanizmu szyfrowania wymienionego w interfejsie API w wersji 26 lub nowszej, zgodnie z opisem w Cipher SDK.
• [C-1-2] NIE MOŻE tworzyć kopii zapasowych nieprzetworzonych ani zaszyfrowanych danych przy użyciu metod tworzenia kopii zapasowych na Androidzie ani żadnych innych metod tworzenia kopii zapasowej.
• [C-1-3] MUSI wysyłać wszystkie takie dane oraz dziennik urządzenia tylko przy użyciu mechanizmu chroniącego prywatność. Mechanizm chroniący prywatność to „te, które umożliwiają tylko analizę zbiorczą i uniemożliwiają dopasowywanie zarejestrowanych zdarzeń lub wyników uzyskanych do poszczególnych użytkowników”, zapobiegając spojrzeniu na dane poszczególnych użytkowników (np. implementowane z wykorzystaniem technologii prywatności różnicowej, takiej jak RAPPOR).
• [C-1-4] NIE MOŻE wiązać takich danych z żadną tożsamością użytkownika (taką jak Account) na urządzeniu bez wyraźnej zgody użytkownika za każdym razem, gdy dane są powiązane.
• [C-1-5] NIE MOŻE udostępniać takich danych innym aplikacjom z wyjątkiem wyraźnej zgody użytkownika za każdym razem, gdy są one udostępniane.
• [C-1-6] MUSI zapewnić użytkownikowi możliwość usunięcia takich danych, które zbiera ContentCaptureService lub zastrzeżone środki, jeśli dane są przechowywane na urządzeniu w dowolnej formie.

Jeśli implementacje urządzeń obejmują usługę, która implementuje interfejs API systemu ContentCaptureService, lub dowolną zastrzeżoną usługę, która rejestruje dane w sposób opisany powyżej:

• [C-2-1] NIE MOŻE zezwalać użytkownikom na zastępowanie usługi przechwytywania treści aplikacją lub usługą możliwą do zainstalowania przez użytkownika i MUSI zezwalać na przechwytywanie takich danych wyłącznie przez zainstalowaną fabrycznie usługę.
• [C-2-2] NIE MOŻE zezwalać na przechwytywanie takich danych aplikacjom innym niż zainstalowany fabrycznie mechanizm usługi przechwytywania treści.
• [C-2-3] MUSI zapewniać korzyści dla użytkownika w celu wyłączenia usługi przechwytywania treści.
• [C-2-4] NIE MOŻE pomijać zgody użytkownika na zarządzanie uprawnieniami Androida przyznanymi przez usługę przechwytywania treści i zgodnie z modelem uprawnień Androida opisanym w Sekcji 9.1. Uprawnienia.

• [C-SR] Zdecydowanie ZALECANE jest rozdzielenie komponentów usługi przechwytywania treści, na przykład bez wiązania identyfikatorów usługi lub procesu udostępniania, od innych komponentów systemu z wyjątkiem tych:

  • Telefonia, kontakty, interfejs systemu i multimedia

9.8.7 Dostęp do schowka

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE zwracać w schowku obciętych danych (np. przez interfejs API ClipboardManager), chyba że aplikacja jest domyślnym edytorem IME lub jest aktualnie zaznaczonym.

9.8.8 Lokalizacja

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE włączać/wyłączać ustawień lokalizacji urządzenia ani skanowania Wi-Fi/Bluetooth bez wyraźnej zgody użytkownika lub jego zainicjowania.
• [C-0-2] W celu określenia lokalizacji użytkownik musi mieć dostęp do informacji związanych z lokalizacją, w tym do ostatnich próśb o lokalizację, uprawnień na poziomie aplikacji oraz korzystania ze skanowania Wi-Fi i Bluetooth.
• [C-0-3] MUSI upewnić się, że aplikacja korzystająca z interfejsu Emergency Location Bypass API [LocationRequest.setLocationSettingsignored()] jest sesją alarmową zainicjowaną przez użytkownika (np. wybierz numer 911 lub wyślij SMS-a pod 911). W przypadku motoryzacji pojazd MOŻE zainicjować sesję alarmową bez aktywnej interakcji użytkownika w przypadku wykrycia wypadku lub wypadku (np. w celu spełnienia wymagań dotyczących eCall).
• [C-0-4] MUSI zachować możliwość omijania ustawień lokalizacji urządzenia przez interfejs Emergency Location Bypass API bez ich zmiany.
• [C-0-5] MUSI zaplanować powiadomienie przypominające użytkownikowi, gdy aplikacja w tle uzyska dostęp do jego lokalizacji przy użyciu uprawnienia [ACCESS_BACKGROUND_LOCATION].

9.8.9. Zainstalowane aplikacje

Aplikacje na Androida kierowane na interfejs API na poziomie 30 lub wyższym domyślnie nie mogą wyświetlać szczegółów innych zainstalowanych aplikacji (zobacz Widoczność pakietów w dokumentacji pakietu Android SDK).

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE udostępniać żadnych aplikacji kierowanych na interfejs API na poziomie 30 lub wyższym, chyba że aplikacja ma już dostęp do informacji o innej zainstalowanej aplikacji za pomocą zarządzanych interfejsów API. Dotyczy to m.in. szczegółów ujawnianych przez niestandardowe interfejsy API dodane przez implementację urządzenia lub dostępne przez system plików.

9.8.10. Raport o błędzie z łącznością

Jeśli implementacje urządzeń generują raporty o błędach za pomocą interfejsu System API BUGREPORT_MODE_TELEPHONY w usłudze BugreportManager:

• [C-1-1] MUSI uzyskiwać zgodę użytkownika za każdym razem, gdy wywoływany jest interfejs BUGREPORT_MODE_TELEPHONY systemu API w celu wygenerowania raportu, i NIE MOŻE prosić użytkownika o zgodę na wszystkie przyszłe żądania z aplikacji.
• [C-1-2] MUSI wyświetlać i uzyskiwać wyraźną zgodę użytkownika podczas generowania raportu oraz NIE MOŻE zwracać wygenerowanego raportu do aplikacji, która wysłała prośbę, bez wyraźnej zgody użytkownika.
• [C-1-3] MUSI generować żądane raporty zawierające przynajmniej te informacje:
  • Zrzut danych TelephonyDebugService
  • Zrzut rejestru połączeń telefonicznych
  • Zrzut danych WifiService
  • Zrzut usługi ConnectivityService
  • Zrzut instancji CarrierService pakietu wywołującego (jeśli jest powiązany)
  • Bufor dziennika radiowego
• [C-1-4] W wygenerowanych raportach NIE MOŻE zawierać tych danych:
  • Wszelkie informacje niezwiązane z debugowaniem połączeń.
  • Wszelkie dzienniki ruchu z aplikacji zainstalowane przez użytkownika lub szczegółowe profile aplikacji lub pakietów zainstalowanych przez użytkownika (identyfikatory UID są dopuszczalne, nazwy pakietów nie są dopuszczalne).
• MOŻE zawierać dodatkowe informacje, które nie są powiązane z żadną tożsamością użytkownika. (np. dzienniki dostawcy).

Jeśli implementacje urządzeń zawierają w raporcie o błędzie dodatkowe informacje (np.dzienniki dostawcy) mające wpływ na prywatność, bezpieczeństwo, baterię, pamięć masową lub pamięć:

• [C-SR] Zdecydowanie ZALECANE jest domyślne wyłączenie ustawień dla programistów. Platforma AOSP udostępnia to rozwiązanie, udostępniając w ustawieniach dewelopera opcję Enable verbose vendor logging, która umożliwia uwzględnianie w raportach o błędach dodatkowych dzienników dostawcy związanych z konkretnym urządzeniem.

9.8.11. Udostępnianie blobów danych

Android za pomocą BlobStoreManager umożliwia aplikacjom przesyłanie do systemu blobów danych, które mogą być udostępniane wybranej grupie aplikacji.

Jeśli implementacje urządzeń obsługują udostępniane bloby danych zgodnie z opisem w dokumentacji pakietu SDK, umożliwiają one:

• [C-1-1] NIE MOŻE udostępniać blobów danych należących do aplikacji poza ich przeznaczeniem (tzn. zakres domyślnego dostępu i innych trybów dostępu, które można określić za pomocą funkcji BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() lub MU NOTStoreManager changed.session#allowPublicAccess(). Implementacja referencyjna AOSP spełnia te wymagania.
• [C-1-2] NIE MOŻE wysyłać poza urządzenie ani udostępniać innym aplikacjom bezpiecznych haszów blobów danych (które służą do kontroli dostępu).

9.9. Szyfrowanie magazynu danych

Wszystkie urządzenia MUSZĄ spełniać wymagania opisane w sekcji 9.9.1. Urządzenia, które zostały wprowadzone na poziomie interfejsu API wcześniej niż ten dokument, są zwolnione z wymagań opisanych w artykułach 9.9.2 i 9.9.3. MUSZĄ spełniać wymagania określone w sekcji 9.9 dokumentu definicji zgodności z Androidem odpowiednie dla poziomu interfejsu API, na którym uruchomiono urządzenie.

9.9.1. Bezpośredni rozruch

Implementacje na urządzeniach:

• [C-0-1] MUSI wdrożyć interfejsy API trybu bezpośredniego rozruchu, nawet jeśli nie obsługują szyfrowania pamięci.

• [C-0-2] Intencje ACTION_LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED MUSZĄ nadal być transmitowane, aby sygnalizować aplikacji, że dane w aplikacjach szyfrowanych na urządzeniu (DE) i z szyfrowaniem danych uwierzytelniających (CE) są dostępne.

9.9.2. Wymagania dotyczące szyfrowania

Implementacje na urządzeniach:

• [C-0-1] MUSI szyfrować prywatne dane aplikacji (partycja /data), a także partycję pamięci współdzielonej aplikacji (partycja /sdcard), jeśli jest to trwała, niemożliwa do usunięcia część urządzenia.
• [C-0-2] MUSI domyślnie włączać szyfrowanie danych, gdy użytkownik zakończy rozruchową konfigurację.

• [C-0-3] MUSI spełniać powyższe wymagania dotyczące szyfrowania miejsca na dane przez wdrożenie jednej 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 blokowania poszczególnych użytkowników opisane w sekcji 9.9.3.2.

9.9.3 Metody szyfrowania

Jeśli implementacje urządzeń są zaszyfrowane:

• [C-1-1] MUSI uruchomić się bez żądania podania danych logowania użytkownika i zezwolić aplikacjom wykrywającym bezpośrednie rozruchy na dostęp do pamięci zaszyfrowanej na urządzeniu (DE) po wysłaniu komunikatu ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] MUSI zezwalać na dostęp do pamięci z certyfikatem CE (Credential Encrypted – CE) tylko wtedy, gdy użytkownik odblokuje urządzenie, podając swoje dane logowania (np. hasło, kod PIN, wzór lub odcisk palca), a komunikat ACTION_USER_UNLOCKED zostanie wysłany.
• [C-1-13] NIE MOŻE oferować żadnej metody odblokowywania pamięci chronionej CE bez danych logowania podanych przez użytkownika, zarejestrowanego klucza depozytowego lub wznowienia po ponownym uruchomieniu spełniającego wymagania opisane w sekcji 9.9.4.
• [C-1-4] MUSI używać weryfikacji podczas uruchamiania.

9.9.3.1. Szyfrowanie oparte na plikach z szyfrowaniem metadanych

Jeśli implementacje urządzeń korzystają z szyfrowania opartego na plikach z szyfrowaniem metadanych:

• [C-1-5] MUSI szyfrować zawartość pliku i metadane systemu plików przy użyciu AES-256-XTS lub Adiantum. AES-256-XTS odnosi się do standardu Advanced Encryption Standard z 256-bitowym kluczem szyfrowania, który działa w trybie XTS. pełna długość klucza to 512 bitów. Adiantum odnosi się do Adiantum-XChaCha12-AES, jak podano na stronie https://github.com/google/adiantum. Metadane systemu plików to dane, takie jak rozmiary plików, własność, tryby i atrybuty rozszerzone (xattrs).
• [C-1-6] MUSI szyfrować nazwy plików przy użyciu AES-256-CBC-CTS lub Adiantum.
• [C-1-12] Jeśli urządzenie obsługuje instrukcje AES (Advanced Encryption Standard, np. ARMv8 Cryptography Extensions na urządzeniach z procesorami ARM lub AES-NI na urządzeniach z procesorami x86), należy używać powyższych opcji opartych na AES w przypadku nazwy pliku, jego zawartości i metadanych systemu plików, a nie Adiantum.
• [C-1-13] MUSI używać silnej kryptograficznie i nieodwracalnej funkcji derywacji kluczy (np. HKDF-SHA512), aby uzyskać potrzebne podklucze (np. klucze poszczególnych plików) z kluczy CE i DE. „Silne kryptograficznie i nieodwracalne” oznacza, że funkcja derywacji klucza ma poziom zabezpieczeń wynoszący co najmniej 256 bitów i działa jak rodzina funkcji pseudorandom dla jej danych wejściowych.

• [C-1-14] NIE MOŻE używać tych samych kluczy lub podkluczy szyfrowania FBE do różnych celów kryptograficznych (np. zarówno do szyfrowania, jak i wygenerowania kluczy lub do dwóch różnych algorytmów szyfrowania).

• Klucze chroniące obszary pamięci CE i DE oraz metadane systemu plików:

• [C-1-7] MUSI być kryptograficznie powiązany ze sprzętowym magazynem kluczy. Ten magazyn kluczy MUSI być powiązany z weryfikacją podczas uruchamiania i z sprzętowym systemem głównym zaufania urządzenia.

• [C-1-8] Klucze CE MUSZĄ być powiązane z danymi logowania na ekranie blokady użytkownika.
• [C-1-9] Jeśli użytkownik nie określił danych logowania na ekranie blokady, klucze CE MUSZĄ być powiązane z domyślnym kodem dostępu.
• [C-1-10] MUSI być niepowtarzalny, co oznacza, że żaden klucz CE lub DE użytkownika nie pasuje do żadnego klucza CE lub DE innego użytkownika.

• [C-1-11] MUSI używać obsługiwanych szyfrów, długości kluczy i trybów.

• Trzeba tylko skonfigurować wstępnie zainstalowane niezbędne aplikacje (np. Alarm, telefon, Messenger) i rozpoznawać funkcję bezpośredniego rozruchu.

Nadrzędny projekt Android Open Source oferuje preferowaną implementację szyfrowania opartego na plikach na podstawie jądra systemu Linux „fscrypt” funkcji szyfrowania oraz szyfrowania metadanych opartego na jądrze Linuksa „dm-default-key” funkcji.

9.9.3.2. Szyfrowanie na poziomie blokowania poszczególnych użytkowników

Jeśli implementacje urządzeń korzystają z szyfrowania na poziomie bloku dla poszczególnych użytkowników:

• [C-1-1] MUSI włączyć obsługę wielu użytkowników zgodnie z opisem w sekcji 9.5.
• [C-1-2] MUSI udostępniać partycje dla poszczególnych użytkowników przy użyciu partycji nieprzetworzonych lub woluminów logicznych.
• [C-1-3] MUSI używać unikalnych, unikalnych kluczy szyfrowania dla każdego użytkownika do szyfrowania podstawowych urządzeń blokujących.

• [C-1-4] MUSI używać AES-256-XTS do szyfrowania partycji użytkownika na poziomie bloku.

• Klucze chroniące urządzenia zaszyfrowane na poziomie bloku dla poszczególnych użytkowników:

• [C-1-5] MUSI być kryptograficznie powiązany ze sprzętowym magazynem kluczy. Ten magazyn kluczy MUSI być powiązany z weryfikacją podczas uruchamiania i z sprzętowym systemem głównym 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 wdrożyć za pomocą funkcji „dm-crypt” jądra Linuksa w przypadku partycji poszczególnych użytkowników.

9.9.4. Wznów po ponownym uruchomieniu

Funkcja Wznowienie przy ponownym uruchomieniu umożliwia odblokowanie pamięci CE wszystkich aplikacji, w tym tych, które jeszcze nie obsługują bezpośredniego rozruchu, po ponownym uruchomieniu zainicjowanym przez OTA. Ta funkcja umożliwia użytkownikom otrzymywanie powiadomień z zainstalowanych aplikacji po ponownym uruchomieniu.

Wdrożenie funkcji wznawiania po ponownym uruchomieniu musi zapewniać, że gdy urządzenie dostanie się w ręce atakującego, bardzo utrudnione będzie odzyskanie danych zaszyfrowanych przy użyciu systemu CE – nawet wtedy, gdy urządzenie jest włączone, pamięć CE jest odblokowana, a użytkownik odblokowuje urządzenie po otrzymaniu OTA. Ze względu na odporność na atak osób wtajemniczonych zakładamy także, że osoba przeprowadzająca atak uzyskuje dostęp do przesyłanych kryptograficznych kluczy podpisywania.

Więcej szczegółów:

• [C-0-1] Pamięć CE NIE MOŻE być czytelna dla osoby przeprowadzającej atak, który fizycznie ma urządzenie z następującymi możliwościami i ograniczeniami:

  • Może podpisywać dowolne wiadomości kluczem podpisywania dowolnego dostawcy lub firmy.
  • Może powodować odbieranie aktualizacji OTA przez urządzenie.
  • Może modyfikować działanie dowolnego sprzętu (AP, Flash itp.), z wyjątkiem przypadków opisanych poniżej, ale takie modyfikacje wymagają co najmniej godzinnego opóźnienia i cyklu zasilania, które niszczy zawartość pamięci RAM.
  • Nie można zmienić działania sprzętu odpornego na manipulacje (np. Titan M).
  • Nie można odczytać pamięci RAM aktywnego urządzenia.
  • Nie można uzyskać danych logowania użytkownika (kodu PIN, wzoru, hasła) ani w inny sposób spowodować ich wprowadzenia.

Na przykład implementacja urządzenia, która zawiera wszystkie elementy podane tutaj i jest z nimi zgodna, będzie zgodna z normą [C-0-1].

9.10. Integralność urządzenia

Te wymagania zapewniają przejrzystość stanu integralności urządzenia. Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo zgłaszać za pomocą metody System API PersistentDataBlockManager.getFlashLockState(), czy stan programu rozruchowego zezwala na flashowanie obrazu systemu. Stan FLASH_LOCK_UNKNOWN jest zarezerwowany dla wdrożeń na urządzeniach z wcześniejszą wersją Androida, w której nie istniała nowa metoda interfejsu API systemu.

• [C-0-2] MUSI obsługiwać weryfikację podczas uruchamiania, aby zapewnić integralność urządzenia.

Jeśli implementacje urządzeń zostały już wdrożone bez obsługi weryfikacji podczas uruchamiania we wcześniejszej wersji Androida i nie mogą dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, MOGĄ one zostać zwolnione z tego wymogu.

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

• [C-1-1] MUSI zadeklarować flagę funkcji platformy android.software.verified_boot.
• [C-1-2] MUSI przeprowadzić weryfikację przy każdej sekwencji uruchamiania.
• [C-1-3] MUSI rozpocząć weryfikację od stałego klucza sprzętowego, który jest źródłem zaufania, aż do poziomu partycji systemowej.
• [C-1-4] MUSI wdrożyć każdy etap weryfikacji, aby na następnym etapie sprawdzić integralność i autentyczność wszystkich bajtów, zanim wykonasz kod na kolejnym etapie.
• [C-1-5] MUSI używać algorytmów weryfikacji tak silnych jak obecne zalecenia NIST w zakresie algorytmów haszowania (SHA-256) i rozmiarów kluczy publicznych (RSA-2048).
• [C-1-6] NIE MOŻE umożliwiać uruchomienia urządzenia w przypadku niepowodzenia weryfikacji systemu, chyba że użytkownik mimo to wyrazi zgodę – wtedy nie wolno używać danych z niezweryfikowanych bloków pamięci masowej.
• [C-1-7] NIE MOŻE zezwalać na modyfikowanie zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokuje program rozruchowy.
• [C-SR] Jeśli w urządzeniu znajduje się wiele dyskretnych układów scalonych (np. radio, specjalny procesor obrazu), Zdecydowanie ZALECANY jest proces uruchamiania każdego z nich, aby sprawdzić każdy etap podczas uruchamiania.
• [C-1-8] MUSI korzystać z pamięci, w której nie wykryto manipulacji: do przechowywania, czy program rozruchowy jest odblokowany. Dzięki temu program rozruchowy może wykryć, czy ktoś manipulował przy użyciu systemu Android.
• [C-1-9] MUSI poprosić użytkownika podczas korzystania z urządzenia i wymaga fizycznego potwierdzenia przed zezwoleniem na przejście z trybu blokady programu rozruchowego na tryb odblokowany.
• [C-1-10] MUSI wdrożyć ochronę przed wycofywaniem partycji używanych przez Androida (np. podczas uruchamiania, partycje systemowe) i przechowywać metadane używane do określenia minimalnej dopuszczalnej wersji systemu operacyjnego, w pamięci, w której można sprawdzić działanie systemu.
• [C-SR] Zdecydowanie ZALECANA jest weryfikacja wszystkich plików APK aplikacji z odpowiednimi uprawnieniami, które są łańcuchem zaufania zakorzenionego w partycjach chronionych przez funkcję weryfikacji podczas uruchamiania.
• [C-SR] Zdecydowanie ZALECANE jest sprawdzanie wszystkich artefaktów wykonywalnych wczytywanych przez aplikację uprzywilejowaną spoza pliku APK (takiego jak dynamicznie ładowany lub skompilowany kod) przed ich wykonaniem lub Zdecydowanie ZALECANE jest ich niewykonanie.
• NALEŻY zaimplementować ochronę przywracania przed wycofywaniem każdego komponentu z trwałym oprogramowaniem układowym (np. modemu czy aparatu) oraz NALEŻY korzystać z pamięci, w trakcie której doszło do manipulacji, do przechowywania metadanych używanych do określenia minimalnej dopuszczalnej wersji.

Jeśli implementacje urządzeń zostały już wdrożone bez obsługi języków od C-1-8 do C-1-10 na starszej wersji Androida i nie mogą dodać świadczenia tych wymagań za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z tych wymagań.

Nadrzędny projekt Android Open Source zapewnia preferowaną implementację tej funkcji w repozytorium external/avb/, które można zintegrować z programem rozruchowym służącym do wczytywania Androida.

Implementacje na urządzeniach:

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

Jeśli implementacje urządzeń zostały już uruchomione bez możliwości weryfikacji zawartości pliku pod kątem zaufanego klucza we wcześniejszej wersji Androida i nie mogą dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z tego wymogu. Nadrzędny projekt Android Open Source udostępnia preferowaną implementację tej funkcji opartą na funkcji fs-verity jądra systemu Linux.

Implementacje na urządzeniach:

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

Jeśli implementacje urządzeń obsługują interfejs Android Protected confirmation API:

• [C-3-1] MUSI zgłosić parametr true w przypadku interfejsu API ConfirmationPrompt.isSupported().

• [C-3-2] MUSI mieć pewność, że kod uruchomiony w systemie operacyjnym Android, w tym jego jądro, złośliwy lub inny, nie może wygenerować pozytywnej odpowiedzi bez działania ze strony użytkownika.

• [C-3-3] MUSI upewnić się, że użytkownik jest w stanie sprawdzić i zatwierdzić wyświetlony komunikat, nawet jeśli system operacyjny Android i jego jądro zostaną przejęte.

9.11. Klucze i dane uwierzytelniające

System magazynu kluczy Android umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i wykorzystywanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub interfejsu Keystore API. Implementacje na urządzeniach:

• [C-0-1] MUSI umożliwiać zaimportowanie lub wygenerowanie co najmniej 8192 kluczy.
• [C-0-2] Uwierzytelnianie na ekranie blokady MUSI mieć limit prób ograniczania liczby żądań i MUSI mieć algorytm wzrastającego ponowienia. Powyżej 150 nieudanych prób opóźnienie MUSI wynosić co najmniej 24 godziny.
• NIE POWINNO ograniczać liczby kluczy, które można wygenerować

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady,:

• [C-1-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [C-1-2] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1 i SHA-2, aby zapewnić prawidłową obsługę algorytmów obsługiwanych przez system Android Keystore w obszarze odizolowanym od kodu działającego w jądrze i nowszych. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, dzięki którym jądro lub kod przestrzeni użytkownika mogą uzyskiwać dostęp do wewnętrznego stanu odizolowanego środowiska, w tym do aktu o rynkach cyfrowych. Dodatkowy projekt Android Open Source Project (AOSP) spełnia to wymaganie dzięki implementacji Trusty. Alternatywnym rozwiązaniem są inne rozwiązanie oparte na technologii ARM TrustZone lub sprawdzone i sprawdzone przez firmę zewnętrzną wdrożenie izolacji opartej na hipernadzorcy.
• [C-1-3] MUSI przeprowadzić uwierzytelnianie ekranu blokady w izolowanym środowisku wykonawczym i tylko wtedy, gdy wszystko się uda, zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający uwierzytelnianie przy zablokowanym ekranie tylko w przypadku izolowanego środowiska wykonawczego. Nadrzędny projekt Android Open Source udostępnia platformę Gatekeeper Hardware Abstraction Layer (HAL) i Trusty, które można wykorzystać w celu spełnienia tego wymogu.
• [C-1-4] MUSI obsługiwać atest klucza, gdy klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane na bezpiecznym sprzęcie. Klucze podpisywania atestu MUSZĄ być udostępniane przez wystarczającą liczbę urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie tego samego klucza atestu,chyba że zostanie wyprodukowanych co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowany zostanie więcej niż 100 tys. jednostek SKU, dla każdej z nich może zostać użyty inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na starszej wersji Androida, urządzenie zostanie zwolnione z obowiązku posiadania magazynu kluczy w osobnym środowisku wykonawczym oraz obsługi atestu klucza, chyba że zadeklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy działającej w odizolowanym środowisku wykonawczym.

• [C-1-5] MUSI umożliwiać użytkownikowi wybranie limitu czasu uśpienia, po którym następuje przejście z odblokowanego w zablokowany, przy minimalnym dozwolonym czasie oczekiwania do 15 sekund. Urządzenia motoryzacyjne, które blokują ekran po wyłączeniu radiowej lub przełączeniu użytkownika, MOGĄ NIE mieć konfiguracji czasu uśpienia.

9.11.1. Bezpieczny ekran blokady i uwierzytelnianie

Implementacja AOSP jest oparta na wielopoziomowym modelu uwierzytelniania, w którym podstawowe uwierzytelnianie oparte na fabryce wiedzy może być poparte albo dodatkowymi, silnymi danymi biometrycznymi, albo słabszymi modalnościami trzeciorzędnymi.

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE jest ustawienie tylko jednej z tych metod jako podstawowej metody uwierzytelniania:
  • Numeryczny kod PIN
  • Hasło alfanumeryczne
  • Wzór przesuwania na siatce zawierającej dokładnie 3 x 3 kropki

Pamiętaj, że w tym dokumencie powyższe metody uwierzytelniania są określane jako zalecane główne metody uwierzytelniania.

Jeśli implementacje urządzeń dodają lub zmieniają zalecane główne metody uwierzytelniania i używają nowej metody uwierzytelniania jako bezpiecznego sposobu blokowania ekranu, nowa metoda uwierzytelniania:

• [C-2-1] MUSI być metodą uwierzytelniania użytkownika opisaną w artykule Wymaganie uwierzytelniania użytkowników przed użyciem klucza.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania w celu odblokowywania ekranu blokady na podstawie znanego obiektu tajnego i używają nowej metody uwierzytelniania, która umożliwia blokowanie ekranu:

• [C-3-1] Entropia najkrótszej dozwolonej 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ępować żadnej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) wdrożonych i udostępnionych w AOSP.
• [C-3-4] Nowa metoda uwierzytelniania MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_SOMETHING.
• [C-3-5] Nowe metody uwierzytelniania MUSZĄ przechodzić na zalecane główne metody uwierzytelniania (np. kodem PIN, wzorem, hasłem) co 72 godziny lub rzadziej LUB wyraźnie informować użytkownika, że w celu zachowania prywatności jego danych nie zostanie utworzona kopia zapasowa niektórych danych.

Jeśli implementacje urządzeń dodają lub zmieniają zalecane główne metody uwierzytelniania na potrzeby odblokowywania ekranu blokady i korzystają z 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ące klasy 1 (wcześniej Wygoda).
• [C-4-2] MUSI mieć mechanizm awaryjny umożliwiający użycie jednej z zalecanych podstawowych metod uwierzytelniania, które są oparte na znanym obiekcie tajnym.
• [C-4-3] MUSI być wyłączona i zezwolić na zalecane główne uwierzytelnianie w celu odblokowywania ekranu tylko wtedy , gdy aplikacja kontrolera zasad urządzeń (DPC) ustawi zasadę funkcji blokady klawiszy, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures() z dowolnymi powiązanymi flagami biometrycznymi (np. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE lub KEYGUARD_DISABLE_IRIS).

Jeśli metody uwierzytelniania biometrycznego nie spełniają wymagań klasy 3 (wcześniej Silne) opisanej w sekcji 7.3.10:

• [C-5-1] Metody MUSZĄ być wyłączone, jeśli aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakością niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Użytkownik MUSI otrzymać prośbę o przeprowadzenie zalecanego podstawowego uwierzytelniania (np. kodu PIN, wzoru, hasła) zgodnie z opisami w punktach [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 poniższej sekcji rozpoczynające się od cyfry C-8.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania na potrzeby odblokowywania ekranu blokady, a nowa metoda uwierzytelniania jest oparta na tokenie fizycznym lub lokalizacji:

• [C-6-1] MUSZĄ one mieć mechanizm awaryjności umożliwiający użycie jednej z zalecanych podstawowych metod uwierzytelniania, które są oparte na znanym obiekcie tajnym i spełniać wymagania traktowania urządzenia jako bezpiecznego ekranu blokady.
• [C-6-2] Nowa metoda MUSI być wyłączona i umożliwiać odblokowywanie ekranu tylko jednej z zalecanych głównych metod uwierzytelniania, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasady za pomocą metody DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) lub DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakością niż PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] Użytkownik MUSI otrzymywać potwierdzenia użycia jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) co najmniej raz na 4 godziny.
• [C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI spełniać wymagania wymienione w punkcie C-8 poniżej.

Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jednego agenta zaufania, który implementuje systemowy interfejs API TrustAgentService:

• [C-7-1] MUSI być wyraźnie oznaczony w menu ustawień i na ekranie blokady, gdy blokada urządzenia jest odroczona lub może zostać odblokowana przez agenta zaufania. Na przykład AOSP spełnia to wymaganie, wyświetlając opis tekstowy ustawienia „Blokuj automatycznie”. i „Błyskawiczne blokowanie przycisku zasilania” w menu ustawień i wyróżniającą się ikonę na ekranie blokady.
• [C-7-2] MUSI respektować i w pełni wdrożyć wszystkie interfejsy API agenta zaufania w klasie DevicePolicyManager, takie jak stała KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NIE MOŻE w pełni wdrażać funkcji TrustAgentService.addEscrowToken() na urządzeniu, które jest podstawowym urządzeniem osobistym (np. podręcznym), ale MOŻE w pełni wdrożyć ją w typach urządzeń, które są zwykle używane (np. na urządzeniach z Androidem Television lub Automotive).
• [C-7-4] MUSI szyfrować wszystkie przechowywane tokeny dodane przez TrustAgentService.addEscrowToken().
• [C-7-5] NIE MOŻE przechowywać klucza szyfrowania ani tokena depozytowego na tym samym urządzeniu, na którym jest używany klucz. Przykładowo klucz zapisany na telefonie może służyć do odblokowywania konta użytkownika na telewizorze. W przypadku urządzeń motoryzacyjnych token powierniczy nie może być przechowywany w żadnej części pojazdu.
• [C-7-6] MUSI poinformować użytkownika o wpływie na bezpieczeństwo przed włączeniem tokena depozytowego na potrzeby odszyfrowywania magazynu danych.
• [C-7-7] MUSI mieć mechanizm awaryjny, aby umożliwić korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania.
• [C-7-8] Użytkownik MUSI otrzymywać potwierdzenia użycia jednej z zalecanych podstawowych metod uwierzytelniania (np.kodu PIN, wzoru, hasła) co najmniej raz na 72 godziny, chyba że zagraża to jego bezpieczeństwu (np. rozpraszającym uwagę kierowcy).
• [C-7-9] Użytkownik MUSI uzyskać dostęp do jednej z zalecanych podstawowych metod uwierzytelniania (np.kodu PIN, wzoru, hasła) opisanej w sekcjach [C-1-7] i [C-1-8] w sekcji 7.3.10, chyba że bezpieczeństwo użytkownika (np. rozpraszanie uwagi kierowcy) jest zagrożone.
• [C-7-10] NIE MOŻE być traktowane jako bezpieczny ekran blokady i MUSI spełniać wymagania opisane poniżej w punkcie C-8.
• [C-7-11] NIE MOŻE zezwalać agentom zaufania na podstawowych urządzeniach osobistych (np. urządzeniach przenośnych) na odblokowywanie urządzenia. Za pomocą tych urządzeń mogą one pozostawać odblokowane przez maksymalnie 4 godziny tylko w takim stanie. Domyślna implementacja TrustManagerService w AOSP spełnia to wymaganie.
• [C-7-12] MUSI używać bezpiecznego kryptograficznego kanału komunikacji (np.UKEY2), aby przekazać token depozytowy z urządzenia pamięci masowej do urządzenia docelowego.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania, aby odblokować ekran blokady, który nie jest bezpiecznym ekranem blokady, (jak opisano powyżej), i używaj nowej metody uwierzytelniania do odblokowywania ekranu blokady:

• [C-8-1] Nowa metoda MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] NIE MOŻE resetować liczników czasu wygaśnięcia haseł ustawionych przez DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] NIE MOGĄ udostępniać interfejsu API do zmiany stanu blokady aplikacji innych firm.

9.11.2. StrongBox,

System magazynu kluczy Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w specjalnym, bezpiecznym procesorze oraz w osobnym środowisku wykonawczym opisanym powyżej. Taki dedykowany bezpieczny procesor jest nazywany „StrongBox”. Poniższe wymagania określają wymagania, jakie urządzenie musi spełniać, aby zostało uznane za StrongBox.

Implementacje urządzeń, które mają dedykowany bezpieczny procesor:

• [C-SR] Zdecydowanie ZALECANE jest wsparcie dla StrongBox. StrongBox prawdopodobnie stanie się wymagany w przyszłej wersji.

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

• [C-1-1] MUSI zadeklarować FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] MUSI zapewniać specjalny bezpieczny sprzęt, który jest używany do tworzenia magazynów kluczy i bezpiecznego uwierzytelniania użytkowników. Dedykowany bezpieczny sprzęt może być też używany do innych celów.

• [C-1-3] MUSI mieć dyskretny procesor, który nie współdzieli pamięci podręcznej, pamięci DRAM, współprocesorów ani innych podstawowych zasobów z procesorem aplikacji.

• [C-1-4] MUSI upewnić się, że żadne urządzenia peryferyjne udostępniane punktowi dostępu nie mogą w żaden sposób zmieniać przetwarzania StrongBox ani uzyskiwać z niego żadnych informacji. AP MOŻE wyłączyć lub zablokować dostęp do StrongBox.

• [C-1-5] MUSI mieć wewnętrzny zegar z odpowiednią dokładnością (+-10%), który jest odporny na manipulacje ze strony punktu dostępu.

• [C-1-6] MUSI mieć prawdziwy generator liczb losowych, który generuje jednolicie rozłożone i nieprzewidywalne dane wyjściowe.

• [C-1-7] MUSI być odporny na manipulacje, w tym na przenikanie fizyczne i zakłócenia.

• [C-1-8] MUSI mieć opór w obrębie kanału, w tym na wyciek informacji przez zasilanie, czas, promieniowanie elektromagnetyczne lub boczne kanały promieniowania cieplnego.

• [C-1-9] MUSI mieć bezpieczne miejsce na dane, które zapewnia poufność, integralność, autentyczność, spójność i aktualność. Pamięć NIE MOŻE być odczytywana ani zmieniana, chyba że jest to dozwolone przez interfejsy API StrongBox.

• Aby sprawdzić zgodność z wymaganiami od [C-1-3] do [C-1-9], wdrożenia na urządzeniach:

  • [C-1-10] MUSI zawierać sprzęt z certyfikatem zgodnym z profilem ochrony bezpiecznego układu IC (BSI-CC-PP-0084-2014) lub oceniony przez akredytowane w kraju laboratorium badawcze, które wdrożyło ocenę wysokiego potencjału ataku zgodnie z zasadą Common Metrics Performance of Attack Effectives.
  • [C-1-11] MUSI zawierać oprogramowanie oceniane przez akredytowane w kraju laboratorium badawcze, korzystające z oceny pod kątem luk w zabezpieczeniach o wysokim potencjale ataku zgodnie z zasadami stosowania potencjału ataku na karty Smartcard według kryteriów Common Criteria.
  • [C-SR] Zdecydowanie ZALECANE jest dodanie sprzętu ocenianego za pomocą celu zabezpieczeń, Evaluation Assurance Level (EAL) 5 w wersji 5, rozszerzonego przez AVA_VAN.5. Certyfikat EAL 5 prawdopodobnie będzie wymagany w przyszłej wersji.

• [C-SR] Zdecydowanie ZALECANE jest zapewnienie odporności na atak typu „wewnętrzne” (IAR), co oznacza, że osoba wtajemniczona z dostępem do kluczy podpisywania oprogramowania nie może tworzyć oprogramowania, które powoduje wyciek obiektów tajnych przez StrongBox, ominięcie funkcjonalnych wymagań bezpieczeństwa lub w inny sposób umożliwia dostęp do poufnych danych użytkownika. Zalecanym sposobem implementacji IAR jest zezwolenie na aktualizacje oprogramowania tylko wtedy, gdy główne hasło użytkownika jest podane za pomocą interfejsu IAuthSecret HAL.

9.11.3 Dane logowania

System tożsamości tożsamości definiuje się i osiąga przez wdrożenie wszystkich interfejsów API w pakiecie android.security.identity.*. Te interfejsy API pozwalają deweloperom aplikacji na przechowywanie i pobieranie dokumentów tożsamości użytkowników. Implementacje na urządzeniach:

• Zdecydowanie ZALECANE jest wdrożenie systemu danych logowania tożsamości przez pracowników [C-SR].

Jeśli implementacje urządzeń implementują system danych logowania tożsamości:

• [C-0-1] W przypadku metody IdentityCredentialStore#getInstance() MUSI zwracać wartość inną niż null.

• [C-0-2] MUSI wdrożyć system tożsamości (np. interfejsy API android.security.identity.*) za pomocą kodu komunikującego się z zaufaną aplikacją w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i nowszych wersjach. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, dzięki którym jądro lub kod przestrzeni użytkownika mogą uzyskiwać dostęp do wewnętrznego stanu odizolowanego środowiska, w tym do aktu o rynkach cyfrowych.

• [C-0-3] Operacje kryptograficzne niezbędne do implementacji systemu danych logowania tożsamości (np. interfejsy API android.security.identity.*) MUSZĄ być wykonywane w całości w zaufanej aplikacji, a materiał klucza prywatnego MUSI nigdy nie opuszczać osobnego środowiska wykonawczego, chyba że jest to wymagane przez interfejsy API wyższego poziomu (np. metoda createEphemeralKeyPair()).

• [C-0-4] Zaufana aplikacja MUSI być zaimplementowana w taki sposób, by nie wpływało to na jej właściwości zabezpieczeń (np. dane logowania nie są publikowane bez spełnienia warunków kontroli dostępu, nie można tworzyć adresów MAC dla dowolnych danych), nawet jeśli Android działa w sposób niewłaściwy lub przejęty.

9.12. Usuwanie danych

Wszystkie implementacje na urządzeniach:

• [C-0-1] MUSI udostępniać użytkownikom mechanizm przywracania danych fabrycznych.
• [C-0-2] MUSI usunąć wszystkie dane z systemu plików danych użytkownika.
• [C-0-3] MUSI usuwać dane w sposób zgodny z odpowiednimi standardami branżowymi, takimi jak NIST SP800-88.
• [C-0-4] MUSI wywołać powyższy „Przywracanie danych fabrycznych” gdy interfejs API DevicePolicyManager.wipeData() jest wywoływany przez aplikację kontrolera zasad urządzeń użytkownika głównego.
• MOŻE udostępnić opcję szybkiego czyszczenia danych, która przeprowadza tylko logiczne usuwanie danych.

9.13. Tryb bezpiecznego rozruchu

Android zapewnia tryb bezpiecznego rozruchu, który umożliwia użytkownikom uruchamianie urządzenia w trybie, w którym mogą działać tylko wstępnie zainstalowane aplikacje systemowe, a wszystkie aplikacje innych firm są wyłączone. Ten tryb, nazywany „trybem bezpiecznego rozruchu”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.

Implementacje urządzeń:

• [SR] Zdecydowanie ZALECANE jest wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacje urządzeń mają włączony tryb bezpiecznego rozruchu:

• [C-1-1] MUSI umożliwiać użytkownikowi przejście w tryb bezpiecznego rozruchu w sposób uniemożliwiający jego przerwanie w aplikacjach innych firm zainstalowanych na urządzeniu, chyba że aplikacja innej firmy jest kontrolerem zasad dotyczących urządzeń i ma ustawioną flagę UserManager.DISALLOW_SAFE_BOOT na wartość true (prawda).

• [C-1-2] MUSI umożliwiać użytkownikowi odinstalowanie aplikacji innych firm w trybie awaryjnym.

• Trzeba udostępnić użytkownikowi opcję włączenia trybu bezpiecznego rozruchu z menu rozruchu przy użyciu przepływu pracy innego niż zwykły rozruch.

9.14. Izolacja systemu samochodowego

Oczekuje się, że urządzenia z Androidem Automotive będą wymieniać dane z najważniejszymi podsystemami w pojeździe, wykorzystując interfejs HAL pojazdu do wysyłania i odbierania wiadomości w sieciach pojazdu, takich jak magistrala CAN.

Wymianę danych można zabezpieczyć, implementując funkcje zabezpieczeń poniżej warstw platformy Android, zapobiegając złośliwej lub niezamierzonej interakcji z tymi podsystemami.

9.15. Abonamenty

„Abonamenty” zapoznaj się z informacjami o abonamencie objętym relacjami rozliczeniowymi dostarczonymi przez operatora komórkowego na stronie SubscriptionManager.setSubscriptionPlans().

Wszystkie implementacje na urządzeniach:

• [C-0-1] TRZEBA zwracać abonamentów tylko do aplikacji operatora komórkowego, która je udostępniła.
• [C-0-2] NIE MOŻESZ zdalnie przesyłać ani tworzyć kopii zapasowych abonamentów.
• [C-0-3] MUSI zezwalać na zastąpienia takie jak SubscriptionManager.setSubscriptionOverrideCongested() tylko w aplikacji operatora komórkowego, która obecnie dostarcza ważne abonamenty.

9.16. Migracja danych aplikacji

Jeśli implementacje urządzeń umożliwiają migrację danych z urządzenia na inne i nie ograniczają kopiowanych danych aplikacji do wartości skonfigurowanych przez dewelopera aplikacji w pliku manifestu przez atrybut android:fullBackupContent, oznacza to, że:

• [C-1-1] NIE MOŻE inicjować przesyłania danych aplikacji z urządzeń, na których użytkownik nie ustawił podstawowego uwierzytelniania, jak opisano w artykule 9.11.1 Bezpieczny ekran blokady i uwierzytelnianie.
• [C-1-2] MUSI bezpiecznie potwierdzić główne uwierzytelnianie na urządzeniu źródłowym i potwierdzić zamiar skopiowania danych na urządzenie źródłowe przed ich przesłaniem.
• [C-1-3] MUSI używać atestu klucza bezpieczeństwa, aby mieć pewność, że zarówno urządzenie źródłowe, jak i urządzenie docelowe w ramach migracji między urządzeniami są prawidłowe i mają zablokowany program rozruchowy.
• [C-1-4] MUSI migrować dane aplikacji tylko do tej samej aplikacji na urządzeniu docelowym, z tą samą nazwą pakietu ORAZ certyfikatem podpisywania.
• [C-1-5] MUSI zawierać w menu ustawień informację o tym, że dane z urządzenia źródłowego zostały przeniesione w ramach migracji danych z urządzenia na urządzenie. Użytkownik NIE POWINNO mieć możliwości usunięcia tego oznaczenia.

10. Testowanie zgodności oprogramowania

Implementacje na urządzeniach MUSZĄ przejść wszystkie testy opisane w tej sekcji. Należy jednak pamiętać, że żaden pakiet testów oprogramowania nie jest w pełni wszechstronny. Z tego powodu Zdecydowanie ZALECANE jest wprowadzenie jak najmniejszej liczby zmian w plikach referencyjnych i preferowanej implementacji Androida dostępnej w ramach projektu Android Open Source Project. Zminimalizuje to ryzyko wprowadzenia błędów, które powodują niezgodności, które wymagają przerobienia i potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje na urządzeniach:

• [C-0-1] MUSI przejść pakiet Android Compatibility Test Suite (CTS) dostępny w projekcie Android Open Source Project, korzystając z oprogramowania dostawy zainstalowanego na urządzeniu.

• [C-0-2] MUSI zapewniać zgodność w przypadku niejasności w CTS lub w przypadku wszelkich zmian implementacji części referencyjnego kodu źródłowego.

Narzędzie CTS zostało zaprojektowane tak, aby działać na prawdziwym urządzeniu. Podobnie jak w przypadku każdego oprogramowania, narzędzie CTS może zawierać błędy. Pakiet CTS będzie prowadzony niezależnie od tej definicji zgodności, a dla Androida 11 może zostać wydanych kilka wersji.

Implementacje na urządzeniach:

• [C-0-3] MUSI przejść najnowszą wersję CTS dostępną w chwili zakończenia działania oprogramowania urządzenia.

• NALEŻY w miarę możliwości korzystać z implementacji referencyjnej w drzewie Android Open Source.

10.2. Weryfikator CTS

CTS Verifier wchodzi w skład pakietu Compatibility Test Suite i może być uruchamiany przez człowieka w celu testowania funkcji, których zautomatyzowany system nie może przetestować, na przykład prawidłowego działania kamery i czujników.

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo wykonać wszystkie odpowiednie zgłoszenia weryfikatora CTS.

Weryfikator CTS wykonuje testy obejmujące różne rodzaje sprzętu, w tym sprzęt opcjonalny.

Implementacje na urządzeniach:

• [C-0-2] MUSI przejść wszystkie testy posiadanego sprzętu. na przykład jeśli urządzenie ma akcelerometr, MUSI prawidłowo wykonać test akcelerometru w narzędziu CTS Verifier.

Przypadki testowe funkcji oznaczonych w tym dokumencie definicji zgodności jako opcjonalne MOGĄ zostać pominięte lub pominięte.

• [C-0-2] Na każdym urządzeniu i każdej kompilacji MUSI działać weryfikator CTS zgodnie z opisem powyżej. Ponieważ jednak wiele kompilacji jest bardzo podobnych, narzędzia implementujące na urządzeniach nie powinny jawnie uruchamiać weryfikatora CTS w kompilacjach, które różnią się tylko w prosty sposób. Chodzi w szczególności o implementacje na urządzeniach, które różnią się od tych, które przeszły weryfikację przez weryfikatora CTS tylko przez zestaw uwzględnionych języków, oznaczenia marki itp. MOGĄ pominąć test weryfikatora CTS.

11. Oprogramowanie do aktualizacji

• [C-0-1] Implementacje na urządzeniu MUSZĄ zawierać mechanizm zastępujący całe oprogramowanie systemowe. Mechanizm nie musi przeprowadzać uaktualnień w czasie rzeczywistym – tzn. może być wymagane ponowne uruchomienie urządzenia. Można użyć dowolnej metody, pod warunkiem że może ona zastąpić całe oprogramowanie zainstalowane fabrycznie na urządzeniu. To wymaganie może zostać spełnione na przykład przez:

  • Pobieranie typu „bezprzewodowe (OTA)” z aktualizacją offline po ponownym uruchomieniu.
  • Opcja „w tetheringu” jest aktualizowana przez USB z komputera hosta.
  • „Tryb offline” aktualizuje się po ponownym uruchomieniu i aktualizacji z pliku w pamięci wymiennej.

• [C-0-2] Użyty mechanizm aktualizacji MUSI obsługiwać aktualizacje bez czyszczenia danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachować prywatne dane aplikacji i dane udostępnione przez aplikację. Pamiętaj, że wcześniejsze oprogramowanie Android ma mechanizm aktualizacji, który spełnia to wymaganie.

• [C-0-3] Cała aktualizacja MUSI być podpisana, a mechanizm aktualizacji działający na urządzeniu MUSI zweryfikować aktualizację i podpis w stosunku do klucza publicznego zapisanego na urządzeniu.

• [C-SR] Zdecydowanie ZALECANE jest użycie algorytmu podpisywania za pomocą algorytmu SHA-256 i jego walidacji względem klucza publicznego za pomocą algorytmu ECDSA NIST P-256.

Jeśli implementacja urządzenia obejmuje obsługę połączenia danych bez pomiaru użycia danych, np. profilu 802.11 lub profilu Bluetooth z numerem PAN (sieć osobista), to:

• [C-1-1] MUSI obsługiwać pobieranie OTA z aktualizacją offline po ponownym uruchomieniu.

W przypadku implementacji na urządzeniach z Androidem 6.0 i nowszym mechanizm aktualizacji POWINIEN obsługiwać sprawdzanie, czy obraz systemu jest binarnie identyczny z oczekiwanym wynikiem po aktualizacji OTA. To wymaganie spełnia oparta na blokowych implementacja OTA w źródłowym projekcie Android Open Source, dodana od Androida 5.1.

Implementacje na urządzeniach MUSZĄ też obsługiwać aktualizacje systemu A/B. AOSP implementuje tę funkcję przy użyciu interfejsu HAL kontroli rozruchu.

Jeśli w implementacji urządzenia po jej opublikowaniu, ale w rozsądnym okresie przydatności usługi, co zostanie określone po konsultacji z zespołem ds. zgodności na Androidzie w celu ograniczenia zgodności aplikacji innych firm, wykonaj te czynności:

• [C-2-1] Implementator urządzenia MUSI poprawić błąd, korzystając z 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 zainstalowana) na kontrolowanie instalowania aktualizacji systemu. Jeśli podsystem aktualizacji systemu dla urządzeń zgłasza android.software.device_admin, to:

• [C-3-1] MUSI zaimplementować działanie opisane w klasie SystemUpdatePolicy.

12. Historia zmian dokumentu

Podsumowanie zmian w definicji zgodności w tej wersji:

• Historia zmian dokumentu

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

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

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

Zmiany są oznaczane w ten sposób:

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

• Dokumenty
  Zmiany kosmetyczne lub zmiany związane z kompilacją.

Aby to zrobić, dołącz do adresów URL dziennika zmian parametry adresu URL pretty=full i no-merges.

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 Twoim zdaniem nie obejmują dokumentu.