Definicja zgodności z Androidem 10

1. Wprowadzenie

W tym dokumencie znajdziesz wymagania, które muszą spełniać urządzenia, aby były zgodne z Androidem 10.

Użycie słów „MUST”, „MUST NOT”, „REQUIRED”, „SHALL”, „SHALL NOT”, „SHOULD”, „SHOULD NOT”, „RECOMMENDED”, „MAY” i „OPTIONAL” jest zgodne ze standardem IETF zdefiniowanym w dokumencie RFC2119.

W tym dokumencie „wdrażający urządzenie” lub „wdrażający” to osoba lub organizacja, która opracowuje rozwiązanie sprzętowe lub programowe działające na Androidzie 10. „Wdrożenie urządzenia” lub „wdrożenie” to opracowane w ten sposób rozwiązanie sprzętowe lub programowe.

Aby urządzenie było uznawane za zgodne z Androidem 10, jego implementacja MUSI spełniać wymagania przedstawione w niniejszej definicji zgodności, w tym wszystkie dokumenty włączone przez odniesienie.

Jeśli ta definicja lub testy oprogramowania opisane w sekcji 10 są niejasne, niepełne lub nie zawierają wszystkich informacji, za zapewnienie zgodności z istniejącymi implementacjami odpowiada podmiot wdrażający urządzenie.

Dlatego Projekt Android Open Source jest zarówno referencyjną, jak i preferowaną implementacją Androida. Producentom urządzeń ZDECYDOWANIE ZALECA SIĘ, aby w jak największym stopniu opierali swoje implementacje na „nadrzędnym” kodzie źródłowym dostępnym w ramach Projektu Android Open Source. Chociaż niektóre komponenty można teoretycznie zastąpić alternatywnymi implementacjami, ZDECYDOWANIE ZALECAMY, aby tego nie robić, ponieważ zdanie testów oprogramowania będzie znacznie trudniejsze. Obowiązkiem osoby wdrażającej jest zapewnienie pełnej zgodności zachowania z standardową implementacją Androida, w tym zgodności z pakietem testów zgodności i innych. Pamiętaj, że niektóre zamiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.

Wiele zasobów, do których linki znajdziesz w tym dokumencie, pochodzi bezpośrednio lub pośrednio z pakietu Android SDK i jest funkcjonalnie identycznych z informacjami w dokumentacji tego pakietu. W przypadku jakichkolwiek rozbieżności między tą definicją zgodności lub pakietem testów zgodności a dokumentacją pakietu SDK za wiążącą uznaje się dokumentację pakietu SDK. Wszelkie szczegóły techniczne podane w zasobach, do których odwołujemy się w tym dokumencie, są uważane za część tej definicji zgodności.

1.1 Struktura dokumentu

1.1.1. Wymagania według typu urządzenia

Sekcja 2 zawiera wszystkie wymagania, które dotyczą konkretnego typu urządzenia. Każda podsekcja sekcji 2 jest poświęcona konkretnemu typowi urządzenia.

Wszystkie pozostałe wymagania, które mają zastosowanie do wszystkich implementacji na urządzeniach z Androidem, są wymienione w sekcjach po sekcji 2. W tym dokumencie te wymagania są określane jako „Wymagania podstawowe”.

1.1.2. Identyfikator wymagania

Identyfikator wymagania jest przypisywany do wymagań MUST.

• Identyfikator jest przypisywany tylko w przypadku wymagań MUST.
• Wymagania ZDECYDOWANIE ZALECANE są oznaczone jako [SR], ale nie mają przypisanego identyfikatora.
• 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 w ten sposób:

• Identyfikator typu urządzenia (więcej informacji znajdziesz w sekcji 2. Typy urządzeń)
  • C: podstawowe (wymagania, które mają zastosowanie do wszystkich implementacji urządzeń z Androidem);
  • H: urządzenie przenośne z Androidem
  • T: urządzenie z Androidem TV
  • A: Wdrożenie Androida Automotive
  • W: Wdrożenie na zegarku z Androidem
  • Karta: wdrożenie na tablecie z Androidem
• Identyfikator warunku
  • Jeśli wymaganie jest bezwarunkowe, ten identyfikator ma wartość 0.
  • Jeśli wymaganie jest warunkowe, przypisujemy mu wartość 1 w przypadku pierwszego warunku, a w ramach tej samej sekcji i tego samego typu urządzenia zwiększamy tę wartość o 1.
• Identyfikator wymagania
  • Identyfikator zaczyna się od 1 i zwiększa się o 1 w ramach tej samej sekcji i tego samego 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 udostępnia stos oprogramowania, który można wykorzystywać na różnych typach urządzeń i w różnych formach, ale w przypadku niektórych typów urządzeń ekosystem dystrybucji aplikacji jest lepiej rozwinięty.

W tej sekcji opisujemy te typy urządzeń oraz dodatkowe wymagania i zalecenia dotyczące każdego z nich.

Wszystkie implementacje urządzeń z Androidem, które nie pasują do żadnego z opisanych typów urządzeń, MUSZĄ spełniać wszystkie wymagania z innych sekcji tej definicji zgodności.

2.1 Konfiguracje urządzeń

Główne różnice w konfiguracji sprzętu w zależności od typu urządzenia znajdziesz w wymaganiach dotyczących poszczególnych urządzeń w tej sekcji.

2.2. Wymagania dotyczące urządzeń przenośnych

Urządzenie przenośne z Androidem to urządzenie z Androidem, które zwykle trzyma się w ręce, np. odtwarzacz MP3, telefon lub tablet.

Implementacje urządzeń z Androidem są klasyfikowane jako urządzenia przenośne, jeśli spełniają wszystkie te kryteria:

• mieć źródło zasilania, które zapewnia mobilność, np. baterię;
• ma fizyczną przekątną ekranu w zakresie od 2,5 do 8 cali;

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

2.2.1. Sprzęt

Implementacje na urządzeniach przenośnych:

• [7.1.1.1/H-0-1] MUSI mieć co najmniej 1 wyświetlacz zgodny z Androidem o przekątnej co najmniej 2,5 cala, a każdy wyświetlacz zgodny z Androidem MUSI spełniać wszystkie wymagania opisane w tym dokumencie.
• [7.1.1.3/H-SR] Zdecydowanie zaleca się udostępnienie użytkownikom możliwości zmiany rozmiaru wyświetlacza (gęstości ekranu).

Jeśli implementacje urządzeń przenośnych deklarują obsługę wyświetlaczy o wysokim zakresie dynamiki za pomocą Configuration.isScreenHdr() , to:

• [7.1.4.5/H-1-1] MUSI reklamować obsługę rozszerzeń EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace i VK_EXT_hdr_metadata.

Implementacje na urządzeniach przenośnych:

• [7.1.5/H-0-1] MUSI obsługiwać tryb zgodności ze starszymi aplikacjami zaimplementowany w kodzie źródłowym Androida. Oznacza to, że implementacje urządzeń NIE MOGĄ zmieniać wyzwalaczy ani progów, przy których aktywowany jest tryb zgodności, ani samego działania trybu zgodności.
• [7.2.1/H-0-1] MUSI obsługiwać aplikacje edytora metody wprowadzania (IME) innych firm.
• [7.2.3/H-0-3] MUSI udostępniać funkcję ekranu głównego na wszystkich wyświetlaczach zgodnych z Androidem, które wyświetlają ekran główny.
• [7.2.3/H-0-4] MUSI udostępniać funkcję Wstecz na wszystkich wyświetlaczach zgodnych z Androidem oraz funkcję Ostatnie na co najmniej jednym wyświetlaczu zgodnym z Androidem.
• [7.2.3/H-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno normalne, jak i długie naciśnięcie przycisku Wstecz (KEYCODE_BACK). System NIE MOŻE przetwarzać tych zdarzeń, a zdarzenia te MOGĄ być wywoływane poza urządzeniem z Androidem (np. przez zewnętrzną klawiaturę sprzętową podłączoną do urządzenia z Androidem).
• [7.2.4/H-0-1] MUSI obsługiwać wprowadzanie danych za pomocą ekranu dotykowego.
• [7.2.4/H-SR] Zdecydowanie zaleca się uruchamianie wybranej przez użytkownika aplikacji wspomagającej, czyli aplikacji, która implementuje VoiceInteractionService, lub aktywności obsługującej ACTION_ASSIST po długim naciśnięciu KEYCODE_MEDIA_PLAY_PAUSE lub KEYCODE_HEADSETHOOK, jeśli aktywność na pierwszym planie nie obsługuje tych zdarzeń długiego naciśnięcia.
• [7.3.1/H-SR] Zdecydowanie zaleca się, aby zawierały 3-osiowy akcelerometr.

Jeśli urządzenia przenośne są wyposażone w 3-osiowy akcelerometr:

• [7.3.1/H-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 100 Hz.

Jeśli implementacje urządzeń przenośnych zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, to:

• [7.3.3/H-2-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
• [7.3.3/H-2-2] MUSI zgłaszać pseudoodległości i szybkości pseudoodległości GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 0,2 m/s², wystarczają do obliczenia pozycji z dokładnością do 20 metrów i prędkości z dokładnością do 0,2 m/s co najmniej w 95% przypadków.

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

• [7.3.4/H-3-1] MUSI mieć możliwość zgłaszania zdarzeń z częstotliwością co najmniej 100 Hz.
• [7.3.4/H-3-2] MUSI być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.

Urządzenia przenośne, które mogą nawiązywać połączenia głosowe i wskazywać dowolną wartość inną niż PHONE_TYPE_NONE w getPhoneType:

• [7.3.8/H] POWINIEN zawierać czujnik zbliżeniowy.

Implementacje na urządzeniach przenośnych:

• [7.3.11/H-SR] ZALECANE jest obsługiwanie czujnika pozycji z 6 stopniami swobody.
• [7.4.3/H] POWINNO obejmować obsługę Bluetooth i Bluetooth LE.

Jeśli implementacje na urządzeniach przenośnych obejmują połączenie rozliczane według ilości przesyłanych danych:

• [7.4.7/H-1-1] MUSI udostępniać tryb oszczędzania danych.

Jeśli implementacje urządzeń przenośnych obejmują logiczne urządzenie aparatu, które wyświetla możliwości za pomocą CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, to:

• [7.5.4/H-1-1] MUSI mieć domyślnie normalne pole widzenia (FOV) w zakresie od 50 do 90 stopni.

Implementacje na urządzeniach przenośnych:

• [7.6.1/H-0-1] MUSI mieć co najmniej 4 GB pamięci trwałej dostępnej na prywatne dane aplikacji (czyli partycję „/data”).
• [7.6.1/H-0-2] MUSI zwracać wartość „true” dla ActivityManager.isLowRamDevice(), gdy jądro i przestrzeń użytkownika mają do dyspozycji mniej niż 1 GB pamięci.

Jeśli implementacje urządzeń przenośnych deklarują obsługę tylko 32-bitowego interfejsu ABI:

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

• [7.6.1/H-2-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 592 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do HD+ (np. HD, WSVGA).

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

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

Jeśli implementacje urządzeń przenośnych deklarują obsługę dowolnego 64-bitowego interfejsu ABI (z dowolnym 32-bitowym interfejsem ABI lub bez niego):

• [7.6.1/H-5-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 816 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do qHD (np. FWVGA).

• [7.6.1/H-6-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 944 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do HD+ (np. HD, WSVGA).

• [7.6.1/H-7-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 1280 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do FHD (np. WSXGA+).

• [7.6.1/H-8-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI wynosić co najmniej 1824 MB, jeśli domyślny wyświetlacz korzysta z rozdzielczości bufora ramki do QHD (np. QWXGA).

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do przestrzeni pamięci udostępnianej oprócz pamięci już przypisanej do komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro na urządzeniach.

Jeśli urządzenia przenośne mają nie więcej 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 pamięci trwałej na prywatne dane aplikacji (czyli partycję „/data”).

Jeśli urządzenia przenośne mają 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 pamięci trwałej dostępnej na prywatne dane aplikacji (czyli partycję „/data”).
• POWINIEN zadeklarować flagę funkcji android.hardware.ram.normal.

Implementacje na urządzeniach przenośnych:

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

Jeśli urządzenia przenośne mają port USB obsługujący tryb urządzenia peryferyjnego:

• [7.7.1/H-1-1] MUSI implementować interfejs Android Open Accessory (AOA).

Jeśli urządzenia przenośne mają port USB obsługujący tryb hosta:

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

Implementacje na urządzeniach przenośnych:

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

Jeśli implementacje na urządzeniach przenośnych spełniają wszystkie wymagania dotyczące wydajności w trybie VR i obsługują ten tryb:

• [7.9.1/H-1-1] MUSI deklarować android.hardware.vr.high_performance flagę funkcji.
• [7.9.1/H-1-2] MUSI zawierać aplikację implementującą android.service.vr.VrListenerService, którą aplikacje VR mogą włączać za pomocą android.app.Activity#setVrModeEnabled.

Jeśli urządzenia przenośne mają co najmniej 1 port USB-C w trybie hosta i obsługują klasę audio USB, oprócz wymagań podanych w sekcji 7.7.2 muszą:

• [7.8.2.2/H-1-1] MUSI udostępniać następujące mapowanie oprogramowania kodów HID:

• [7.8.2.2/H-1-2] MUSI wywoływać ACTION_HEADSET_PLUG po włożeniu wtyczki, ale tylko po prawidłowym wyliczeniu interfejsów i punktów końcowych audio USB w celu określenia typu podłączonego terminala.

Gdy wykryte zostaną terminale audio USB typu 0x0302, wykonują one te czynności:

• [7.8.2.2/H-2-1] MUSI emitować intencję ACTION_HEADSET_PLUG z dodatkowym parametrem „microphone” ustawionym na 0.

Gdy wykryte zostaną terminale audio USB typu 0x0402, wykonują one te czynności:

• [7.8.2.2/H-3-1] MUSI wysyłać intencję ACTION_HEADSET_PLUG z dodatkowym parametrem „microphone” ustawionym na 1.

Gdy wywoływane jest API AudioManager.getDevices(), a urządzenie peryferyjne USB jest podłączone:

• [7.8.2.2/H-4-1] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET, a jego rola musi być isSink(), jeśli pole typu terminala audio USB ma wartość 0x0302.

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

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

• [7.8.2.2/H-4-4] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE, a pole roli musi mieć wartość isSink(), jeśli pole typu terminala audio USB ma wartość 0x603.

• [7.8.2.2/H-4-5] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE, a pole role musi mieć wartość isSource(), jeśli pole typu terminala audio USB ma wartość 0x604.

• [7.8.2.2/H-4-6] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE, a pole role isSink() musi mieć wartość true, jeśli pole typu terminala audio USB ma wartość 0x400.

• [7.8.2.2/H-4-7] MUSI zawierać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE, a pole role isSource() musi mieć wartość true, jeśli pole typu terminala audio USB ma wartość 0x400.

• [7.8.2.2/H-SR] Po podłączeniu urządzenia audio USB-C ZDECYDOWANIE ZALECA SIĘ wykonanie wyliczania deskryptorów USB, identyfikowanie typów terminali i nadawanie intencji ACTION_HEADSET_PLUG w czasie krótszym niż 1000 milisekund.

2.2.2. Multimedia

Urządzenia przenośne MUSZĄ obsługiwać te formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] Profil MPEG-4 AAC (AAC LC)
• [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
• [5.1/H-0-5] AAC ELD (enhanced low delay AAC)

Implementacje na urządzeniach przenośnych MUSZĄ obsługiwać te 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 przenośnych MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

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

2.2.3. Oprogramowanie

Implementacje na urządzeniach przenośnych:

• [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 zapewnia użytkownikowi możliwość dostępu do danych dostawcy dokumentów za pomocą interfejsu DocumentsProvider API.
• [3.4.1/H-0-1] MUSI udostępniać pełną implementację interfejsu android.webkit.Webview API.
• [3.4.2/H-0-1] MUSI zawierać samodzielną aplikację przeglądarki do ogólnego przeglądania internetu przez użytkowników.
• [3.8.1/H-SR] Zdecydowanie zaleca się 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 ZALECA się wdrożenie domyślnego programu uruchamiającego, który zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu ShortcutManager API.
• [3.8.1/H-SR] Zdecydowanie zaleca się, aby zawierały domyślną aplikację uruchamiającą, która wyświetla plakietki na ikonach aplikacji.
• [3.8.2/H-SR] Zdecydowanie zalecane jest obsługiwanie 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 z elementami rozszerzonymi.
• [3.8.3/H-0-3] MUSI obsługiwać powiadomienia w formie wyskakujących okienek.
• [3.8.3/H-0-4] MUSI zawierać panel powiadomień, który umożliwia użytkownikowi bezpośrednie sterowanie powiadomieniami (np. odpowiadanie na nie, odkładanie ich, zamykanie i blokowanie) za pomocą elementów interfejsu, takich jak przyciski działań lub panel sterowania zaimplementowany w AOSP.
• [3.8.3/H-0-5] MUSI wyświetlać w obszarze powiadomień opcje podane w RemoteInput.Builder setChoices().
• [3.8.3/H-SR] Zdecydowanie zaleca się wyświetlanie pierwszego wyboru udostępnionego przez RemoteInput.Builder setChoices() w obszarze powiadomień bez dodatkowej interakcji ze strony użytkownika.
• [3.8.3/H-SR] ZDECYDOWANIE ZALECA SIĘ wyświetlanie wszystkich opcji podanych w RemoteInput.Builder setChoices() w obszarze powiadomień, gdy użytkownik rozwinie wszystkie powiadomienia w tym obszarze.
• [3.8.3.1/H-SR] Zdecydowanie zaleca się wyświetlanie działań, dla których Notification.Action.Builder.setContextual jest ustawione jako true w linii z odpowiedziami wyświetlanymi przez Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR] Zdecydowanie zalecamy wdrożenie na urządzeniu asystenta, który będzie obsługiwać działanie Assist.

Jeśli implementacje urządzeń przenośnych obsługują działanie Asystenta, to:

• [3.8.4/H-SR] ZDECYDOWANIE ZALECA się używanie długiego naciśnięcia klawisza HOME jako wyznaczonej interakcji do uruchamiania aplikacji wspomagającej zgodnie z opisem w sekcji 7.2.3. MUSI uruchomić wybraną przez użytkownika aplikację wspomagającą, czyli aplikację, która implementuje VoiceInteractionService, lub aktywność obsługującą intencję ACTION_ASSIST.

Jeśli urządzenia przenośne z Androidem obsługują ekran blokady:

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

Jeśli urządzenia przenośne obsługują bezpieczny ekran blokady:

• [3.9/H-1-1] MUSI implementować pełny zakres zasad administrowania urządzeniem zdefiniowanych w dokumentacji pakietu Android SDK.
• [3.9/H-1-2] MUSI deklarować obsługę profili zarządzanych za pomocą flagi funkcji android.software.managed_users, z wyjątkiem sytuacji, gdy urządzenie jest skonfigurowane tak, aby zgłaszać się jako urządzenie z małą ilością pamięci RAM lub gdy przydziela wewnętrzną (niewymienną) pamięć jako pamięć współdzieloną.

Implementacje na urządzeniach przenośnych:

• [3.10/H-0-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.
• [3.10/H-SR] Zdecydowanie zaleca się wstępne wczytywanie na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z usługami Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany silnik zamiany tekstu na mowę) lub większej niż one, 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 zaleca się, aby zawierały silnik TTS obsługujący języki dostępne na urządzeniu.
• [3.13/H-SR] Zdecydowanie zaleca się uwzględnienie komponentu interfejsu Szybkich ustawień.

Jeśli implementacje urządzeń przenośnych z Androidem deklarują obsługę FEATURE_BLUETOOTH lub FEATURE_WIFI:

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

Jeśli funkcja nawigacji jest dostępna jako działanie na ekranie oparte na gestach:

• [7.2.3/H] Strefa rozpoznawania gestów dla funkcji Home NIE POWINNA być wyższa niż 32 dp od dolnej krawędzi ekranu.

Jeśli implementacje na urządzeniach przenośnych zapewniają funkcję nawigacji w postaci gestu wykonywanego w dowolnym miejscu na lewej i prawej krawędzi ekranu:

• [7.2.3/H-0-1] Obszar gestów funkcji nawigacji MUSI mieć szerokość mniejszą niż 40 dp po każdej stronie. Obszar gestów 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 klatek lub opóźnienie renderowania klatek NIE MOŻE występować częściej niż 5 klatek na sekundę i POWINNO być mniejsze niż 1 klatka na sekundę.
• [8.1/H-0-2] Opóźnienie interfejsu. Implementacje urządzeń MUSZĄ zapewniać użytkownikom małe opóźnienia, przewijając listę 10 tys. pozycji zgodnie z definicją w pakiecie testów zgodności Androida (CTS) w czasie krótszym niż 36 sekund.
• [8.1/H-0-3] Przełączanie zadań. Ponowne uruchomienie aplikacji, która jest już uruchomiona, musi trwać krócej niż 1 sekundę.

Implementacje na urządzeniach przenośnych:

• [8.2/H-0-1] MUSI zapewniać wydajność zapisu sekwencyjnego na poziomie co najmniej 5 MB/s.
• [8.2/H-0-2] MUSI zapewniać wydajność zapisu losowego na poziomie co najmniej 0,5 MB/s.
• [8.2/H-0-3] MUSI zapewniać wydajność odczytu sekwencyjnego na poziomie co najmniej 15 MB/s.
• [8.2/H-0-4] MUSI zapewniać wydajność odczytu losowego na poziomie co najmniej 3,5 MB/s.

Jeśli implementacje urządzeń przenośnych zawierają funkcje poprawiające zarządzanie energią urządzenia, które są uwzględnione w AOSP lub rozszerzają funkcje uwzględnione w AOSP:

• [8.3/H-1-1] MUSI umożliwiać użytkownikowi włączanie i wyłączanie funkcji oszczędzania baterii.
• [8.3/H-1-2] MUSI udostępniać użytkownikowi możliwość wyświetlania wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii „Aplikacja w trybie gotowości” i „Drzemka”.

Implementacje na urządzeniach przenośnych:

• [8.4/H-0-1] MUSI udostępniać profil zasilania poszczególnych komponentów, który określa wartość zużycia prądu każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją na stronie Projektu Android Open Source.
• [8.4/H-0-2] MUSI podawać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
• [8.4/H-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/H-0-4] MUSI udostępniać informacje o zużyciu energii deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.
• [8.4/H] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji.

Jeśli urządzenia przenośne mają ekran lub wyjście wideo:

• [8.4/H-1-1] MUSI uwzględniać intencję android.intent.action.POWER_USAGE_SUMMARY i wyświetlać menu ustawień, w którym widoczne jest zużycie energii.

2.2.5. Model zabezpieczeń

Implementacje na urządzeniach przenośnych:

• [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ć użytkownikowi mechanizm przyznawania lub odbierania dostępu do takich aplikacji w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

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

• [9.11/H-0-2]* MUSI tworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/H-0-3]* MUSI mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji skrótu MD5, SHA1 i SHA-2, aby prawidłowo obsługiwać algorytmy obsługiwane przez system Android Keystore w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i wyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego izolowanego środowiska, w tym DMA. Wymaganie to jest spełnione w przypadku projektu Android Open Source Project (AOSP) dzięki implementacji Trusty, ale alternatywnymi rozwiązaniami są inne rozwiązania oparte na ARM TrustZone lub sprawdzone przez zewnętrzną firmę bezpieczne implementacje odpowiedniej izolacji opartej na hiperwizorze.
• [9.11/H-0-4]* MUSI przeprowadzić uwierzytelnianie na ekranie blokady w izolowanym środowisku wykonawczym i tylko w przypadku powodzenia zezwolić na użycie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób, który umożliwia uwierzytelnianie na ekranie blokady tylko w izolowanym środowisku wykonawczym. Projekt Android Open Source udostępnia warstwę abstrakcji sprzętu (HAL) Gatekeeper i Trusty, które mogą być używane do spełnienia tego wymagania.
• [9.11/H-0-5]* MUSI obsługiwać atestację klucza, w której klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania atestu MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnianie tego samego klucza atestu,chyba że wyprodukowano co najmniej 100 000 sztuk danego kodu SKU. Jeśli wyprodukowano więcej niż 100 000 sztuk danego kodu SKU, dla każdych 100 000 sztuk MOŻE być użyty inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na wcześniejszej wersji Androida, takie urządzenie jest zwolnione z wymogu posiadania magazynu kluczy obsługiwanego przez odizolowane środowisko wykonawcze i obsługi atestowania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy obsługiwanego przez odizolowane środowisko wykonawcze.

Jeśli urządzenia przenośne obsługują bezpieczny ekran blokady:

• [9.11/H-1-1] MUSI umożliwiać użytkownikowi wybranie najkrótszego czasu oczekiwania na uśpienie, czyli czasu przejścia ze stanu odblokowanego do zablokowanego, wynoszącego 15 sekund lub mniej.
• [9.11/H-1-2] MUSI udostępniać użytkownikowi możliwość ukrywania powiadomień i wyłączania wszystkich form uwierzytelniania z wyjątkiem podstawowego uwierzytelniania opisanego w sekcji 9.11.1 Bezpieczny ekran blokady. AOSP spełnia wymagania trybu blokady.

Jeśli implementacje na urządzeniach przenośnych obejmują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, to:

• [9.5/H-2-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom ograniczonym właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, w których można zarządzać bardziej szczegółowymi ograniczeniami w aplikacjach.

Jeśli implementacje urządzeń przenośnych obejmują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony, to:

• [9.5/H-3-1] NIE MOŻE obsługiwać profili z ograniczeniami, ale MUSI być zgodny z implementacją AOSP elementów sterujących, które umożliwiają innym użytkownikom włączanie i wyłączanie dostępu do połączeń głosowych i SMS-ów.

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

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

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

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

• Perfetto
  • [6.1/H-0-2]* MUSI udostępniać użytkownikowi powłoki plik binarny /system/bin/perfetto, którego wiersz poleceń jest zgodny z dokumentacją narzędzia Perfetto.
  • [6.1/H-0-3]* Plik binarny perfetto MUSI akceptować jako dane wejściowe konfigurację bufora protokołu zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/H-0-4]* Plik binarny perfetto MUSI zapisywać jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [6.1/H-0-5]* MUSI udostępniać za pomocą pliku binarnego perfetto co najmniej źródła danych opisane w dokumentacji perfetto.

2.3. Wymagania dotyczące telewizora

Urządzenie z Androidem TV to implementacja urządzenia z Androidem, która jest interfejsem rozrywkowym do korzystania z mediów cyfrowych, filmów, gier, aplikacji lub telewizji na żywo przez użytkowników siedzących w odległości około 3 metrów (interfejs „lean back” lub „10-foot user interface”).

Implementacje na urządzeniach z Androidem są klasyfikowane jako telewizory, jeśli spełniają wszystkie te kryteria:

• zapewnia mechanizm zdalnego sterowania renderowanym interfejsem użytkownika na wyświetlaczu, który może znajdować się w odległości 3 metrów od użytkownika.
• Musi mieć wbudowany wyświetlacz o przekątnej większej niż 24 cale LUB port wyjścia wideo, taki jak VGA, HDMI, DisplayPort lub port bezprzewodowy do wyświetlania.

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

2.3.1. Sprzęt

Implementacje na urządzeniach telewizyjnych:

• [7.2.2/T-0-1] MUSI obsługiwać pad kierunkowy.
• [7.2.3/T-0-1] MUSI udostępniać funkcje Strona główna i Wstecz.
• [7.2.3/T-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno normalne, jak i długie naciśnięcie funkcji Wstecz (KEYCODE_BACK).
• [7.2.6.1/T-0-1] MUSI obsługiwać kontrolery do gier i deklarować flagę funkcji android.hardware.gamepad.
• [7.2.7/T] POWINNO udostępniać pilota, za pomocą którego użytkownicy mogą korzystać z nawigacji bezdotykowej i podstawowych klawiszy nawigacyjnych.

Jeśli urządzenia telewizyjne mają 3-osiowy żyroskop:

• [7.3.4/T-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 100 Hz.
• [7.3.4/T-1-2] MUSI być w stanie mierzyć zmiany orientacji 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 pamięci trwałej dostępnej na prywatne dane aplikacji (czyli partycję „/data”).

Jeśli urządzenia telewizyjne mają port USB obsługujący tryb hosta:

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

Jeśli urządzenia TV są 32-bitowe:

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

  • co najmniej 400 dpi na małych i normalnych ekranach,
  • xhdpi lub wyższa na dużych ekranach,
  • tvdpi lub wyższa na bardzo dużych ekranach,

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

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

  • co najmniej 400 dpi na małych i normalnych ekranach,
  • xhdpi lub wyższa na dużych ekranach,
  • tvdpi lub wyższa na bardzo dużych ekranach,

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do przestrzeni pamięci udostępnianej oprócz pamięci już przypisanej do komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro na urządzeniach.

Implementacje na urządzeniach telewizyjnych:

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

2.3.2. Multimedia

Implementacje urządzeń telewizyjnych MUSZĄ obsługiwać te formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:

• [5.1/T-0-1] Profil MPEG-4 AAC (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/T-0-3] AAC ELD (enhanced low delay AAC)

Urządzenia telewizyjne MUSZĄ obsługiwać te formaty kodowania wideo i udostępniać je aplikacjom innych firm:

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

Implementacje na urządzeniach telewizyjnych:

• [5.2.2/T-SR] ZDECYDOWANIE ZALECA się obsługę kodowania H.264 filmów o rozdzielczości 720p i 1080p przy 30 kl./s.

Urządzenia telewizyjne MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

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

Urządzenia telewizyjne MUSZĄ obsługiwać dekodowanie MPEG-2 zgodnie z opisem w sekcji 5.3.1 przy standardowych częstotliwościach klatek i rozdzielczościach wideo, w tym:

• [5.3.1/T-1-1] HD 1080p przy 29,97 kl./s z profilem głównym na wysokim poziomie.
• [5.3.1/T-1-2] HD 1080i przy 59,94 kl./s z profilem głównym na wysokim poziomie. MUSZĄ usuwać przeplot z przeplatanego wideo MPEG-2 i udostępniać je aplikacjom innych firm.

Urządzenia telewizyjne MUSZĄ obsługiwać dekodowanie H.264 zgodnie z opisem w sekcji 5.3.4 przy standardowych częstotliwościach klatek i rozdzielczościach wideo, w tym:

• [5.3.4/T-1-1] HD 1080p przy 60 kl./s z profilem podstawowym
• [5.3.4/T-1-2] HD 1080p przy 60 kl./s z profilem głównym
• [5.3.4/T-1-3] HD 1080p przy 60 kl./s z profilem High Profile Level 4.2

Urządzenia telewizyjne z dekoderami sprzętowymi H.265 MUSZĄ obsługiwać dekodowanie H.265 zgodnie z opisem w sekcji 5.3.5 przy standardowych częstotliwościach klatek i rozdzielczościach wideo do:

• [5.3.5/T-1-1] HD 1080p przy 60 kl./s z profilem głównym na poziomie 4.1

Jeśli urządzenia telewizyjne z dekoderami sprzętowymi H.265 obsługują dekodowanie H.265 i profil dekodowania UHD, to:

• [5.3.5/T-2-1] MUSI obsługiwać profil dekodowania UHD przy 60 klatkach na sekundę z profilem Main10 Level 5 Main Tier.

Urządzenia telewizyjne MUSZĄ obsługiwać dekodowanie VP8 zgodnie z opisem w sekcji 5.3.6 przy standardowych liczbach klatek i rozdzielczościach do:

• [5.3.6/T-1-1] Profil dekodowania HD 1080p przy 60 kl./s

Implementacje urządzeń telewizyjnych ze sprzętowymi dekoderami VP9 MUSZĄ obsługiwać dekodowanie VP9 zgodnie z opisem w sekcji 5.3.7 przy standardowych częstotliwościach klatek i rozdzielczościach wideo do:

• [5.3.7/T-1-1] HD 1080p przy 60 kl./s z profilem 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 ZALECA się obsługę profilu dekodowania UHD przy 60 klatkach na sekundę z profilem 2 (10-bitowa głębia kolorów).

Implementacje na urządzeniach telewizyjnych:

• [5.5/T-0-1] MUSI obsługiwać systemową głośność główną i tłumienie głośności cyfrowego wyjścia audio na obsługiwanych wyjściach, z wyjątkiem wyjścia przekazywania skompresowanego dźwięku (gdzie na urządzeniu nie jest wykonywane dekodowanie dźwięku).

Jeśli urządzenia telewizyjne nie mają wbudowanego wyświetlacza, ale obsługują wyświetlacz zewnętrzny podłączony przez HDMI:

• [5.8/T-0-1] MUSI ustawić tryb wyjścia HDMI, aby wybrać maksymalną rozdzielczość, która może być obsługiwana przy częstotliwości odświeżania 50 Hz lub 60 Hz.
• [5.8/T-SR] Zdecydowanie zaleca się udostępnienie użytkownikowi selektora częstotliwości odświeżania HDMI.
• [5.8] POWINNO 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 urządzenia telewizyjne nie mają wbudowanego wyświetlacza, ale obsługują wyświetlacz zewnętrzny podłączony przez HDMI:

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

Jeśli urządzenia telewizyjne 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 deklarować funkcje android.software.leanback i android.hardware.type.television.
• [3.4.1/T-0-1] MUSI udostępniać pełną implementację interfejsu API android.webkit.Webview.

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

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

Implementacje na urządzeniach telewizyjnych:

• [3.8.14/T-SR] Zdecydowanie zaleca się obsługę trybu obrazu w obrazie w wielu oknach.
• [3.10/T-0-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.
• [3.10/T-SR] Zdecydowanie zaleca się wstępne wczytywanie na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z usługami Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany silnik przetwarzania tekstu na mowę) lub większej niż te usługi, zgodnie z projektem open source TalkBack.

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

• [3.11/T-SR] Zdecydowanie zaleca się, aby zawierały silnik TTS obsługujący języki dostępne na urządzeniu.
• [3.11/T-1-1] MUSI obsługiwać instalację silników TTS innych firm.

Implementacje na urządzeniach telewizyjnych:

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

2.3.4. Wydajność i moc

• [8.1/T-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie klatek lub opóźnienie renderowania klatek NIE MOŻE występować częściej niż 5 klatek na sekundę i POWINNO być mniejsze niż 1 klatka na sekundę.
• [8.2/T-0-1] MUSI zapewniać wydajność zapisu sekwencyjnego na poziomie co najmniej 5 MB/s.
• [8.2/T-0-2] MUSI zapewniać wydajność zapisu losowego na poziomie co najmniej 0,5 MB/s.
• [8.2/T-0-3] MUSI zapewniać wydajność odczytu sekwencyjnego na poziomie co najmniej 15 MB/s.
• [8.2/T-0-4] MUSI zapewniać wydajność odczytu losowego na poziomie co najmniej 3,5 MB/s.

Jeśli implementacje urządzeń telewizyjnych zawierają funkcje poprawiające zarządzanie energią urządzenia, które są uwzględnione w AOSP lub rozszerzają funkcje uwzględnione w AOSP:

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

Jeśli urządzenia telewizyjne nie mają baterii:

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

Jeśli urządzenia telewizyjne mają baterię:

• [8.3/T-1-3] MUSI udostępniać użytkownikowi możliwość wyświetlania wszystkich aplikacji, które są zwolnione z trybów oszczędzania energii „Aplikacja w trybie gotowości” i „Drzemka”.

Implementacje na urządzeniach telewizyjnych:

• [8.4/T-0-1] MUSI udostępniać profil zasilania poszczególnych komponentów, który określa wartość zużycia prądu każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
• [8.4/T-0-2] MUSI podawać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
• [8.4/T-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/T] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji.
• [8.4/T-0-4] MUSI udostępniać informacje o zużyciu energii deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.

2.3.5. Model zabezpieczeń

Implementacje na urządzeniach telewizyjnych:

• [9.11/T-0-1] MUSI tworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/T-0-2] MUSI mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji skrótu MD5, SHA1 i SHA-2, aby prawidłowo obsługiwać algorytmy obsługiwane przez system Android Keystore w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i wyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego izolowanego środowiska, w tym DMA. Wymaganie to jest spełnione w przypadku projektu Android Open Source Project (AOSP) dzięki implementacji Trusty, ale alternatywnymi rozwiązaniami są inne rozwiązania oparte na ARM TrustZone lub sprawdzone przez zewnętrzną firmę bezpieczne implementacje odpowiedniej izolacji opartej na hiperwizorze.
• [9.11/T-0-3] MUSI przeprowadzać uwierzytelnianie na ekranie blokady w izolowanym środowisku wykonawczym i tylko w przypadku powodzenia zezwalać na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób, który umożliwia uwierzytelnianie na ekranie blokady tylko w izolowanym środowisku wykonawczym. Projekt Android Open Source udostępnia warstwę abstrakcji sprzętu (HAL) Gatekeeper i Trusty, które mogą być używane do spełnienia tego wymagania.
• [9.11/T-0-4] MUSI obsługiwać atestowanie kluczy, w przypadku którego klucz podpisu atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania atestu MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnianie tego samego klucza atestu,chyba że wyprodukowano co najmniej 100 000 sztuk danego kodu SKU. Jeśli wyprodukowano więcej niż 100 000 sztuk danego kodu SKU, dla każdych 100 000 sztuk MOŻE być użyty inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na wcześniejszej wersji Androida, takie urządzenie jest zwolnione z wymogu posiadania magazynu kluczy obsługiwanego przez odizolowane środowisko wykonawcze i obsługi atestowania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy obsługiwanego przez odizolowane środowisko wykonawcze.

Jeśli urządzenia telewizyjne obsługują bezpieczny ekran blokady:

• [9.11/T-1-1] MUSI umożliwiać użytkownikowi wybór czasu bezczynności przed przejściem z odblokowanego do zablokowanego stanu, przy czym minimalny dopuszczalny czas bezczynności wynosi maksymalnie 15 sekund.

Jeśli implementacje urządzeń telewizyjnych obsługują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, to:

• [9.5/T-2-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom ograniczonym właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, w których można zarządzać bardziej szczegółowymi ograniczeniami w aplikacjach.

Jeśli implementacje urządzeń telewizyjnych obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony:

• [9.5/T-3-1] NIE MOŻE obsługiwać profili z ograniczeniami, ale MUSI być zgodny z implementacją AOSP elementów sterujących, które umożliwiają włączanie i wyłączanie dostępu innych użytkowników 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, którego wiersz poleceń jest zgodny z dokumentacją narzędzia Perfetto.
  • [6.1/T-0-2] Plik binarny Perfetto MUSI akceptować jako dane wejściowe konfigurację bufora protokołu zgodną ze schematem zdefiniowanym w dokumentacji Perfetto.
  • [6.1/T-0-3] Plik binarny Perfetto MUSI zapisywać jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji Perfetto.
  • [6.1/T-0-4] MUSI udostępniać za pomocą pliku binarnego perfetto co najmniej źródła danych opisane w dokumentacji perfetto.

2.4. Wymagania dotyczące zegarka

Urządzenie z Androidem Watch to urządzenie z Androidem przeznaczone do noszenia na ciele, np. na nadgarstku.

Implementacje urządzeń z Androidem są klasyfikowane jako zegarki, jeśli spełniają wszystkie te kryteria:

• mieć ekran o przekątnej od 1,1 cala do 2,5 cala;
• musi mieć mechanizm umożliwiający noszenie na ciele;

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

2.4.1. Sprzęt

Implementacje urządzeń z Androidem:

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

• [7.2.3/W-0-1] MUSI udostępniać użytkownikowi funkcję Strona główna i funkcję Wstecz, z wyjątkiem sytuacji, gdy jest w UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] MUSI obsługiwać wprowadzanie danych za pomocą ekranu dotykowego.

• [7.3.1/W-SR] Zdecydowanie zaleca się, aby zawierały 3-osiowy akcelerometr.

Jeśli implementacje urządzeń z Androidem Wear OS zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, to:

• [7.3.3/W-1-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
• [7.3.3/W-1-2] MUSI zgłaszać pseudoodległości i szybkości pseudoodległości GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 0,2 m/s², wystarczają do obliczenia pozycji z dokładnością do 20 metrów i prędkości z dokładnością do 0,2 m/s co najmniej w 95% przypadków.

Jeśli implementacje urządzeń z Wear OS zawierają 3-osiowy żyroskop:

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

Implementacje urządzeń z Androidem:

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

• [7.6.1/W-0-1] MUSI mieć co najmniej 1 GB pamięci trwałej dostępnej na prywatne dane aplikacji (czyli partycję „/data”).

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

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

• [7.8.2/W] MOŻE, ale NIE POWINNO mieć wyjścia audio.

2.4.2. Multimedia

Brak dodatkowych wymagań.

2.4.3. Oprogramowanie

Implementacje urządzeń z Androidem:

• [3/W-0-1] MUSISZ zadeklarować funkcję android.hardware.type.watch.
• [3/W-0-2] MUSI obsługiwać uiMode = UI_MODE_TYPE_WATCH.

Implementacje urządzeń z Androidem:

• [3.8.4/W-SR] Zdecydowanie zaleca się wdrożenie na urządzeniu asystenta do obsługi działania Assist.

Obserwuj wdrożenia na urządzeniach, które deklarują 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 zaleca się wstępne wczytywanie na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z usługami Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany silnik zamiany tekstu na mowę) lub większej niż te usługi, zgodnie z projektem open source TalkBack.

• [3.11/W-SR] Zdecydowanie zaleca się, aby zawierały silnik TTS obsługujący języki dostępne na urządzeniu.

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

2.4.4. Wydajność i moc

Jeśli implementacje urządzeń z Wear OS zawierają funkcje poprawiające zarządzanie energią urządzenia, które są dostępne w AOSP lub rozszerzają funkcje dostępne w AOSP:

• [8.3/W-SR] Zdecydowanie zaleca się udostępnienie użytkownikowi możliwości wyświetlania wszystkich aplikacji, które są zwolnione z trybów oszczędzania energii „Wstrzymanie aplikacji” i „Drzemka”.
• [8.3/W-SR] Zdecydowanie zalecamy, aby użytkownik mógł włączać i wyłączać funkcję oszczędzania baterii.

Implementacje urządzeń z Androidem:

• [8.4/W-0-1] MUSI udostępniać profil zasilania poszczególnych komponentów, który określa wartość zużycia prądu każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source Project.
• [8.4/W-0-2] MUSI podawać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
• [8.4/W-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/W-0-4] MUSI udostępniać to zużycie energii deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.
• [8.4/W] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji.

2.4.5. Model zabezpieczeń

Jeśli implementacje urządzeń z Wear OS obsługują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, to:

• [9.5/W-1-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom ograniczonym właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, w których można zarządzać bardziej szczegółowymi ograniczeniami w aplikacjach.

Jeśli implementacje urządzeń z Wear OS obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony, to:

• [9.5/W-2-1] NIE MOŻE obsługiwać profili z ograniczeniami, ale MUSI być zgodny z implementacją AOSP elementów sterujących, które umożliwiają włączanie i wyłączanie dostępu innych użytkowników do połączeń głosowych i SMS-ów.

2.5. Wymagania dotyczące motoryzacji

Implementacja Androida Automotive odnosi się do radioodtwarzacza w samochodzie, który używa Androida jako systemu operacyjnego dla części lub całości systemu i/lub funkcji multimedialnych.

Implementacje urządzeń z Androidem są klasyfikowane jako Automotive, jeśli deklarują funkcję android.hardware.type.automotive lub spełniają wszystkie te kryteria:

• są wbudowane w pojazd lub można je do niego podłączyć.
• używasz ekranu w rzędzie fotela kierowcy jako głównego wyświetlacza;

Dodatkowe wymagania w pozostałej części tej sekcji dotyczą implementacji urządzeń z Androidem Automotive.

2.5.1. Sprzęt

Implementacje na urządzeniach samochodowych:

• [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 rozmiarze co najmniej 750 dp x 480 dp.

• [7.2.3/A-0-1] MUSI udostępniać funkcję Strona główna i MOŻE udostępniać funkcje Wstecz i Ostatnie.

• [7.2.3/A-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno normalne, jak i długie naciśnięcie funkcji Wstecz (KEYCODE_BACK).
• [7.3/A-0-1] MUSI wdrażać i zgłaszać parametry 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/nocnym na desce rozdzielczej i POWINNA być oparta na danych z czujnika światła otoczenia. Czujnik światła otoczenia MOŻE być taki sam jak fotometr.
• [7.3/A-0-3] MUSI podać pole dodatkowych informacji o czujniku TYPE_SENSOR_PLACEMENT w ramach elementu SensorAdditionalInfo dla każdego podanego czujnika.
• [7.3/A-0-1] MAY dead reckon Location by fusing GPS/GNSS with additional sensors. Jeśli Lokalizacja jest obliczana na podstawie ostatniej znanej pozycji, ZDECYDOWANIE ZALECA SIĘ wdrożenie i raportowanie odpowiednich typów czujników lub używanych identyfikatorów właściwości pojazdu.
• [7.3/A-0-2] Lokalizacja żądana za pomocą funkcji LocationManager#requestLocationUpdates() NIE MOŻE być dopasowana do mapy.

Jeśli urządzenia samochodowe mają 3-osiowy akcelerometr:

• [7.3.1/A-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 100 Hz.
• [7.3.1/A-1-2] MUSI być zgodny z układem współrzędnych czujników samochodowych w Androidzie.

Jeśli urządzenia samochodowe mają 3-osiowy żyroskop:

• [7.3.4/A-2-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 100 Hz.
• [7.3.4/A-2-2] MUSI też implementować czujnik TYPE_GYROSCOPE_UNCALIBRATED.
• [7.3.4/A-2-3] MUSI być w stanie mierzyć zmiany orientacji do 250 stopni na sekundę.
• [7.3.4/A-SR] Zdecydowanie zaleca się skonfigurowanie zakresu pomiarowego żyroskopu na +/-250 dps, aby zmaksymalizować możliwą rozdzielczość.

Implementacje na urządzeniach samochodowych:

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

  • Połączenia telefoniczne przez profil zestawu głośnomówiącego (HFP).
  • odtwarzanie multimediów za pomocą profilu dystrybucji audio (A2DP);
  • sterowanie odtwarzaniem multimediów za pomocą profilu zdalnego sterowania (AVRCP);
  • Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).

• [7.4.3/A-SR] Zdecydowanie zaleca się obsługę profilu dostępu do wiadomości (MAP).

• [7.4.5/A] POWINNO obejmować obsługę łączności danych w sieci komórkowej.

• [7.4.5/A] MOŻE używać stałej interfejsu System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID w przypadku sieci dostępnych dla aplikacji systemowych.

Kamera zewnętrzna to kamera, która rejestruje obraz scen poza urządzeniem, np. kamera samochodowa.

Implementacje na urządzeniach samochodowych:

• POWINNY zawierać co najmniej 1 kamerę z widokiem na zewnątrz.

Jeśli urządzenia samochodowe mają kamerę z widokiem zewnętrznym, w przypadku takiej kamery:

• [7.5/A-1-1] NIE MOŻE mieć kamer z widokiem na zewnątrz dostępnych za pomocą interfejsów API aparatu na Androida, chyba że spełniają one podstawowe wymagania dotyczące kamer.
• [7.5/A-SR] Zdecydowanie zaleca się, aby nie obracać ani nie odzwierciedlać w poziomie podglądu z kamery.
• [7.5.5/A-SR] ZDECYDOWANIE ZALECA się, aby były one ustawione tak, aby dłuższy bok aparatu był równoległy do horyzontu.
• [7.5/A-SR] Zdecydowanie zaleca się, aby miały rozdzielczość co najmniej 1,3 megapiksela.
• POWINIEN mieć sprzęt z stałą ostrością lub EDOF (rozszerzoną głębią ostrości).
• MOŻE mieć w sterowniku kamery zaimplementowaną automatyczną regulację ostrości sprzętową lub programową.

Implementacje na urządzeniach samochodowych:

• [7.6.1/A-0-1] MUSI mieć co najmniej 4 GB pamięci trwałej dostępnej na prywatne dane aplikacji (czyli partycję „/data”).

• [7.6.1/A] POWINIEN sformatować partycję danych, aby zapewnić lepszą wydajność i trwałość pamięci flash, np. za pomocą systemu plików f2fs.

Jeśli implementacje urządzeń samochodowych udostępniają współdzielone miejsce zewnętrzne za pomocą części wewnętrznej, nieusuwalnej pamięci, to:

• [7.6.1/A-SR] ZDECYDOWANIE ZALECA się zmniejszenie obciążenia operacjami wejścia/wyjścia wykonywanymi na pamięci zewnętrznej, np. przez użycie SDCardFS.

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

• [7.6.1/A-1-1] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 512 MB, jeśli używane są którekolwiek z tych gęstości:

  • 280 dpi lub mniej na małych i normalnych ekranach
  • ldpi lub niższa na bardzo dużych ekranach;
  • mdpi lub niższa na dużych ekranach;

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

  • xhdpi lub wyższa na małych i normalnych ekranach,
  • hdpi lub wyższa na dużych ekranach,
  • mdpi lub wyższa na bardzo dużych ekranach,

• [7.6.1/A-1-3] Pamięć dostępna dla jądra i przestrzeni użytkownika MUSI mieć co najmniej 896 MB, jeśli używana jest którakolwiek z tych gęstości:

  • co najmniej 400 dpi na małych i normalnych ekranach,
  • xhdpi lub wyższa na dużych ekranach,
  • tvdpi lub wyższa na bardzo dużych ekranach,

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

  • 560 dpi lub więcej na małych i normalnych ekranach
  • 400 dpi lub więcej na dużych ekranach
  • xhdpi lub wyższa na bardzo dużych ekranach,

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

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

  • 280 dpi lub mniej na małych i normalnych ekranach
  • ldpi lub niższa na bardzo dużych ekranach;
  • mdpi lub niższa na dużych ekranach;

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

  • xhdpi lub wyższa na małych i normalnych ekranach,
  • hdpi lub wyższa na dużych ekranach,
  • mdpi lub wyższa na bardzo dużych ekranach,

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

  • co najmniej 400 dpi na małych i normalnych ekranach,
  • xhdpi lub wyższa na dużych ekranach,
  • tvdpi lub wyższa na bardzo dużych ekranach,

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

  • 560 dpi lub więcej na małych i normalnych ekranach
  • 400 dpi lub więcej na dużych ekranach
  • xhdpi lub wyższa na bardzo dużych ekranach,

Pamiętaj, że „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do przestrzeni pamięci udostępnianej oprócz pamięci już przypisanej do komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro na urządzeniach.

Implementacje na urządzeniach samochodowych:

• [7.7.1/A] POWINIEN zawierać port USB obsługujący tryb urządzenia peryferyjnego.

Implementacje na urządzeniach samochodowych:

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

Implementacje na urządzeniach samochodowych:

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

2.5.2. Multimedia

Urządzenia samochodowe MUSZĄ obsługiwać te formaty kodowania i dekodowania dźwięku oraz udostępniać je aplikacjom innych firm:

• [5.1/A-0-1] Profil MPEG-4 AAC (AAC LC)
• [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/A-0-3] AAC ELD (enhanced low delay AAC)

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

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

Urządzenia samochodowe MUSZĄ obsługiwać te formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

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

W przypadku urządzeń samochodowych ZDECYDOWANIE ZALECA SIĘ obsługę dekodowania tych formatów wideo:

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

2.5.3. Oprogramowanie

Implementacje na urządzeniach samochodowych:

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

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

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

• [3.2.1/A-0-1] MUSI obsługiwać i egzekwować wszystkie stałe uprawnień zgodnie z dokumentacją na stronie referencyjnej uprawnień w branży motoryzacyjnej.

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

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

• [3.8.4/A-SR] Zdecydowanie zaleca się wdrożenie na urządzeniu asystenta, który będzie obsługiwać działanie Assist.

Jeśli urządzenia samochodowe mają przycisk „naciśnij i mów”, to:

• [3.8.4/A-1-1] MUSI używać krótkiego naciśnięcia przycisku „naciśnij i mów” jako wyznaczonego działania do uruchamiania wybranej przez użytkownika aplikacji wspomagającej, czyli aplikacji, która implementuje VoiceInteractionService.

Implementacje na urządzeniach samochodowych:

• [3.8.3.1/A-0-1] MUSI prawidłowo renderować zasoby zgodnie z opisem w dokumentacji pakietu SDK Notifications on Automotive OS.
• [3.8.3.1/A-0-2] W przypadku działań związanych z powiadomieniami MUSI wyświetlać opcje ODTWÓRZ i WYCISZ zamiast tych, które są dostępne w Notification.Builder.addAction().
• [3.8.3.1/A] POWINNY ograniczać korzystanie z zaawansowanych funkcji zarządzania, takich jak ustawienia poszczególnych kanałów powiadomień. MOŻE używać elementów interfejsu użytkownika w poszczególnych aplikacjach, aby ograniczyć liczbę elementów sterujących.

Implementacje na urządzeniach samochodowych:

• [3.14/A-0-1] MUSI zawierać platformę interfejsu, która obsługuje aplikacje innych firm korzystające 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 jazdy.
• [3.14/A-0-3] MUSI obsługiwać działanie CAR_INTENT_ACTION_MEDIA_TEMPLATE niejawnego zamiaru z dodatkiem CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] MUSI udostępniać możliwość przejścia do aktywności związanej z ustawieniami aplikacji multimedialnej, ale MUSI ją włączać tylko wtedy, gdy nie obowiązują ograniczenia dotyczące interfejsu użytkownika w samochodzie.
• [3.14/A-0-5] MUSI wyświetlać komunikaty o błędach ustawione przez aplikacje multimedialne i MUSI obsługiwać opcjonalne dodatki ERROR_RESOLUTION_ACTION_LABEL i ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] MUSI obsługiwać w aplikacji funkcję wyszukiwania w przypadku aplikacji, które obsługują wyszukiwanie.
• [3.14/A-0-7] MUSI uwzględniać definicje CONTENT_STYLE_BROWSABLE_HINT i CONTENT_STYLE_PLAYABLE_HINT podczas wyświetlania hierarchii MediaBrowser.

Jeśli implementacje urządzeń Automotive zawierają domyślną aplikację uruchamiającą:

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

Implementacje na urządzeniach samochodowych:

• [3.8/A] MOŻE ograniczać żądania aplikacji, aby ograniczyć możliwość przejścia do trybu pełnoekranowego zgodnie z opisem w sekcji immersive documentation.
• [3.8/A] MOŻE utrzymywać pasek stanu i pasek nawigacyjny zawsze widoczne.
• [3.8/A] MOŻE ograniczyć żądania aplikacji, aby ograniczyć możliwość zmiany kolorów elementów interfejsu systemu, aby zapewnić, że te elementy będą zawsze dobrze widoczne, zgodnie z opisem w WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS i WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION.

2.5.4. Wydajność i moc

Implementacje na urządzeniach samochodowych:

• [8.2/A-0-1] MUSI raportować liczbę bajtów odczytanych i zapisanych w pamięci trwałej dla każdego identyfikatora UID procesu, aby statystyki były dostępne dla deweloperów za pomocą interfejsu API systemu android.car.storagemonitoring.CarStorageMonitoringManager. Projekt Android Open Source spełnia to wymaganie dzięki uid_sys_stats.
• [8.3/A-1-3] MUSI włączyć tryb garażowy co najmniej raz przed wyłączeniem samochodu.
• [8.3/A-1-4] MUSI być w trybie garażowym przez co najmniej 15 minut, chyba że:
  • Bateria jest rozładowana.
  • Nie ma zaplanowanych zadań bezczynnych.
  • Kierowca wychodzi z trybu garażowego.
• [8.4/A-0-1] MUSI udostępniać profil zasilania poszczególnych komponentów, który określa wartość zużycia prądu każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source Project.
• [8.4/A-0-2] MUSI podawać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
• [8.4/A-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/A] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji.
• [8.4/A-0-4] MUSI udostępniać te informacje o zużyciu energii deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.

2.5.5. Model zabezpieczeń

Jeśli urządzenia Automotive obsługują wielu użytkowników:

• [9.5/A-1-1] NIE MOŻE zezwalać użytkownikom na interakcje z użytkownikiem systemu bez monitora ani na przełączanie się na niego, z wyjątkiem udostępniania urządzenia.
• [9.5/A-1-2] Musi przełączyć się na użytkownika dodatkowego przed BOOT_COMPLETED.
• [9.5/A-1-3] MUSI obsługiwać możliwość utworzenia użytkownika-gościa nawet wtedy, gdy na urządzeniu osiągnięto maksymalną liczbę użytkowników.

Implementacje na urządzeniach samochodowych:

• [9.11/A-0-1] MUSI tworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [9.11/A-0-2] MUSI mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji skrótu MD5, SHA1 i SHA-2, aby prawidłowo obsługiwać algorytmy obsługiwane przez system Android Keystore w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i wyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego izolowanego środowiska, w tym DMA. Wymaganie to jest spełnione w przypadku projektu Android Open Source Project (AOSP) dzięki implementacji Trusty, ale alternatywnymi rozwiązaniami są inne rozwiązania oparte na ARM TrustZone lub sprawdzone przez zewnętrzną firmę bezpieczne implementacje odpowiedniej izolacji opartej na hiperwizorze.
• [9.11/A-0-3] MUSI przeprowadzać uwierzytelnianie na ekranie blokady w izolowanym środowisku wykonawczym i tylko w przypadku powodzenia zezwalać na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób, który umożliwia uwierzytelnianie na ekranie blokady tylko w izolowanym środowisku wykonawczym. Projekt Android Open Source udostępnia warstwę abstrakcji sprzętu (HAL) Gatekeeper i Trusty, które mogą być używane do spełnienia tego wymagania.
• [9.11/A-0-4] MUSI obsługiwać atestację klucza, w której klucz podpisywania atestacji jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania atestu MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnianie tego samego klucza atestu,chyba że wyprodukowano co najmniej 100 000 sztuk danego kodu SKU. Jeśli wyprodukowano więcej niż 100 000 sztuk danego kodu SKU, dla każdych 100 000 sztuk MOŻE być użyty inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na wcześniejszej wersji Androida, takie urządzenie jest zwolnione z wymogu posiadania magazynu kluczy obsługiwanego przez odizolowane środowisko wykonawcze i obsługi atestowania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy obsługiwanego przez odizolowane środowisko wykonawcze.

Jeśli urządzenia samochodowe obsługują bezpieczny ekran blokady:

• [9.11/A-1-1] MUSI umożliwiać użytkownikowi wybór czasu bezczynności przed przejściem z odblokowanego do zablokowanego stanu, przy czym minimalny dopuszczalny czas bezczynności wynosi maksymalnie 15 sekund.

Implementacje na urządzeniach samochodowych:

• [9.14/A-0-1] MUSI ograniczać dostęp do wiadomości z podsystemów pojazdu w ramach Androida, np. zezwalać na określone typy wiadomości i źródła wiadomości.
• [9.14/A-0-2] MUSI chronić przed atakami typu DoS ze strony platformy Android lub aplikacji innych firm. Zapobiega to zalewaniu sieci pojazdu ruchem przez złośliwe oprogramowanie, co może prowadzić do nieprawidłowego działania podsystemów pojazdu.

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

Implementacje na urządzeniach samochodowych:

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

2.6. Wymagania dotyczące tabletów

Tablet z Androidem to urządzenie z Androidem, które spełnia wszystkie te kryteria:

• Zwykle używany w obu rękach.
• Nie ma konfiguracji typu clamshell ani convertible.
• Każda klawiatura fizyczna używana z urządzeniem MUSI łączyć się za pomocą standardowego połączenia.
• ma źródło zasilania, które zapewnia mobilność, np. baterię;
• ma fizyczną przekątną ekranu w zakresie od 7 do 18 cali;

Wymagania dotyczące implementacji na tabletach są podobne do wymagań dotyczących implementacji na urządzeniach przenośnych. Wyjątki są oznaczone w tej sekcji gwiazdką (*) i w celach informacyjnych wymienione 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 tablety mają 3-osiowy żyroskop:

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

Minimalna pamięć i miejsce na dane (sekcja 7.6.1)

Gęstości ekranu wymienione w wymaganiach dotyczących urządzeń przenośnych w przypadku małych i normalnych ekranów nie mają zastosowania do tabletów.

Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)

Jeśli implementacje urządzeń typu tablet zawierają port USB obsługujący tryb urządzenia peryferyjnego:

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

Tryb wirtualnej rzeczywistości (sekcja 7.9.1)

Wysoka wydajność w wirtualnej rzeczywistości (sekcja 7.9.2)

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

2.6.2. Model zabezpieczeń

Klucze i dane logowania (sekcja 9.11)

Patrz sekcja [9.11].

Jeśli implementacje urządzeń typu tablet obsługują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony:

• [9.5/T-1-1] MUSI obsługiwać profile ograniczone, czyli funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom ograniczonym właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, w których można zarządzać bardziej szczegółowymi ograniczeniami w aplikacjach.

Jeśli implementacje na tabletach obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony, to:

• [9.5/T-2-1] NIE MOŻE obsługiwać profili z ograniczeniami, ale MUSI być zgodny z implementacją AOSP elementów sterujących, które umożliwiają innym użytkownikom dostęp do połączeń głosowych i SMS-ów lub go wyłączają.

3. Oprogramowanie

3.1. Zgodność zarządzanego interfejsu API

Zarządzane środowisko wykonywania kodu bajtowego Dalvik jest podstawowym narzędziem dla aplikacji na Androida. Interfejs API Androida to zestaw interfejsów platformy Android udostępnianych aplikacjom działającym w zarządzanym środowisku wykonawczym.

Implementacje na urządzeniach:

• [C-0-1] MUSI udostępniać pełne implementacje wszystkich udokumentowanych interfejsów API udostępnianych przez pakiet Android SDK lub dowolny interfejs API oznaczony w źródłowym kodzie Androida znacznikiem „@SystemApi”, w tym wszystkie udokumentowane zachowania.

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

• [C-0-3] NIE WOLNO pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów ani sygnatur API, odbiegać od udokumentowanego zachowania ani uwzględniać operacji bez efektu, z wyjątkiem przypadków wyraźnie dozwolonych przez tę definicję zgodności.

• [C-0-4] MUSI nadal udostępniać interfejsy API i działać w rozsądny sposób, nawet jeśli niektóre funkcje sprzętowe, dla których Android udostępnia interfejsy API, są pominięte. Wymagania dotyczące tego scenariusza znajdziesz w sekcji 7.

• [C-0-5] NIE MOŻE zezwalać aplikacjom innych firm na używanie interfejsów spoza SDK, które są zdefiniowane jako metody i pola w pakietach języka Java znajdujących się w ścieżce klasy rozruchowej w AOSP i nie stanowią części publicznego pakietu SDK. Obejmuje to interfejsy API oznaczone adnotacją @hide, ale nie adnotacją @SystemAPI, zgodnie z opisem w dokumentach pakietu SDK, a także prywatne i dostępne tylko w pakiecie elementy klasy.

• [C-0-6] MUSI być dostarczany z każdym interfejsem innym niż SDK na tych samych listach z ograniczeniami, które są udostępniane za pomocą flag listy tymczasowej i listy zablokowanych w prebuilts/runtime/appcompat/hiddenapi-flags.csv ścieżce odpowiedniej gałęzi poziomu API w AOSP.

  Jednak:

  • Mogą one przenieść ukryty interfejs API na listę zablokowanych lub pominąć go na wszystkich listach ograniczonych, jeśli jest on niedostępny lub zaimplementowany w inny sposób na urządzeniu.
  • MAJ, jeśli ukryty interfejs API nie istnieje jeszcze w AOSP, dodaj go do dowolnej listy ograniczeń.

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

3.1.1. Rozszerzenia Androida

Android obsługuje rozszerzanie zarządzanych interfejsów API przy zachowaniu tej samej wersji poziomu API.

• [C-0-1] Implementacje urządzeń z Androidem MUSZĄ wstępnie wczytywać implementację AOSP zarówno biblioteki współdzielonej ExtShared, jak i usług ExtServices w wersjach wyższych lub równych minimalnym wersjom dozwolonym na każdym poziomie API. Na przykład implementacje urządzeń z Androidem 7.0, które działają na poziomie API 24, MUSZĄ zawierać co najmniej wersję 1.

3.1.2. Biblioteka Androida

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

• [C-0-1] NIE WOLNO umieszczać biblioteki org.apache.http.legacy w ścieżce rozruchowej.
• [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:
  • kierowana na interfejs API na poziomie 28 lub niższym.
  • W pliku manifestu deklaruje, że potrzebuje biblioteki, ustawiając atrybut android:name elementu <uses-library> na wartość org.apache.http.legacy.

Implementacja AOSP spełnia te wymagania.

3.2. Zgodność interfejsu API

Oprócz zarządzanych interfejsów API wymienionych w sekcji 3.1 Android zawiera też ważny „miękki” interfejs API działający tylko w czasie działania, w postaci intencji, uprawnień i podobnych aspektów aplikacji na Androida, których nie można wymusić w czasie kompilacji aplikacji.

3.2.1. Uprawnienia

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

3.2.2. Parametry kompilacji

Interfejsy API Androida zawierają wiele stałych w klasie android.os.Build, które mają opisywać bieżące urządzenie.

• [C-0-1] Aby zapewnić spójne i znaczące wartości w różnych implementacjach urządzeń, tabela poniżej zawiera dodatkowe ograniczenia dotyczące formatów tych wartości, do których implementacje urządzeń MUSZĄ być zgodne.

3.2.3. Zgodność z intencją

3.2.3.1. Intencje aplikacji podstawowych

Intencje Androida umożliwiają komponentom aplikacji żądanie funkcji od innych komponentów Androida. Projekt Android upstream zawiera listę aplikacji uznawanych za podstawowe aplikacje na Androida, które implementują kilka wzorców intencji do wykonywania typowych działań.

• [C-0-1] Urządzenia MUSZĄ wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi z procedurą obsługi intencji dla wszystkich publicznych wzorców filtrów intencji zdefiniowanych przez te podstawowe aplikacje na Androida w AOSP:

  • Zegar biurkowy
  • Przeglądarka
  • Kalendarz
  • kontakty,
  • Galeria
  • GlobalSearch
  • Program uruchamiający
  • Muzyka
  • Ustawienia

3.2.3.2. Rozpoznawanie intencji

• [C-0-1] Android to platforma rozszerzalna, więc implementacje urządzeń MUSZĄ umożliwiać zastępowanie przez aplikacje innych firm każdego wzorca intencji wymienionego w sekcji 3.2.3.1, z wyjątkiem Ustawień. Domyślnie umożliwia to implementacja open source Androida.

• [C-0-2] Producenci urządzeń NIE MOGĄ przyznawać specjalnych uprawnień aplikacjom systemowym w zakresie używania tych wzorców intencji ani uniemożliwiać aplikacjom innych firm wiązania się z tymi wzorcami i przejmowania nad nimi kontroli. Zakaz ten obejmuje w szczególności wyłączanie interfejsu użytkownika „Wybór”, który umożliwia użytkownikowi wybór spośród wielu aplikacji obsługujących ten sam wzorzec intencji.

• [C-0-3] Urządzenia MUSZĄ udostępniać interfejs użytkownika, który umożliwia modyfikowanie domyślnego działania w przypadku intencji.

• Jednak implementacje urządzeń MOGĄ udostępniać domyślne działania dla określonych wzorców URI (np. http://play.google.com), gdy domyślne działanie udostępnia bardziej szczegółowy atrybut dla 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 też mechanizm, który umożliwia aplikacjom innych firm deklarowanie autorytatywnego domyślnego zachowania linków do aplikacji w przypadku niektórych typów intencji URI w internecie. Jeśli takie deklaracje autorytatywne są zdefiniowane we wzorcach filtrów intencji aplikacji, implementacje urządzeń:

• [C-0-4] MUSI próbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji protokołu Digital Asset Links, które są zaimplementowane przez Menedżera pakietów w projekcie Android Open Source Project.
• [C-0-5] MUSI próbować zweryfikować filtry intencji podczas instalacji aplikacji i ustawić wszystkie pomyślnie zweryfikowane filtry intencji URI jako domyślne programy obsługi URI.
• MOGĄ ustawić konkretne filtry intencji URI jako domyślne programy obsługi identyfikatorów URI, jeśli zostaną one zweryfikowane, ale inne filtry URI nie przejdą weryfikacji. Jeśli implementacja urządzenia to robi, MUSI udostępniać użytkownikowi odpowiednie zastąpienia wzorców dla poszczególnych adresów URI w menu ustawień.
• MUSI udostępniać użytkownikowi w Ustawieniach elementy sterujące linkami do aplikacji dla poszczególnych aplikacji w ten sposób:
  • [C-0-6] Użytkownik MUSI mieć możliwość globalnego zastąpienia domyślnego działania linków do aplikacji, aby aplikacja zawsze się otwierała, zawsze pytała lub nigdy się nie otwierała. MUSI to dotyczyć wszystkich filtrów intencji URI.
  • [C-0-7] Użytkownik MUSI mieć możliwość wyświetlenia listy filtrów intencji URI kandydata.
  • Implementacja urządzenia MOŻE umożliwiać użytkownikowi zastępowanie poszczególnych filtrów intencji kandydatów URI, które zostały pomyślnie zweryfikowane.
  • [C-0-8] Implementacja urządzenia MUSI umożliwiać użytkownikom wyświetlanie i zastępowanie konkretnych filtrów intencji URI kandydatów, jeśli implementacja urządzenia pozwala na pomyślne przejście weryfikacji przez niektóre filtry intencji URI kandydatów, a inne mogą nie przejść weryfikacji.

3.2.3.3. Przestrzenie nazw zamiarów

• [C-0-1] Implementacje urządzeń NIE MOGĄ zawierać żadnego komponentu Androida, który obsługuje nowe intencje lub wzorce intencji rozgłoszeniowych przy użyciu ACTION, CATEGORY lub innego kluczowego ciągu znaków w przestrzeni nazw android. lub com.android..
• [C-0-2] Producenci urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub intencji rozgłaszania przy użyciu ACTION, CATEGORY lub innego kluczowego ciągu znaków w przestrzeni pakietu należącej do innej organizacji.
• [C-0-3] Producenci urządzeń NIE MOGĄ zmieniać ani rozszerzać żadnych wzorców intencji używanych przez aplikacje podstawowe wymienione w sekcji 3.2.3.1.
• Implementacje urządzeń MOGĄ zawierać wzorce intencji korzystające z przestrzeni nazw wyraźnie i oczywiście powiązanych z ich własną organizacją. Ten zakaz jest analogiczny do zakazu określonego w sekcji 3.6 w przypadku klas języka Java.

3.2.3.4. Zamiary związane z transmisją

Aplikacje innych firm polegają na platformie, która rozsyła określone intencje, aby powiadamiać je o zmianach w środowisku sprzętowym lub programowym.

Implementacje na urządzeniach:

• [C-0-1] MUSI wysyłać publiczne intencje transmisji w odpowiedzi na odpowiednie zdarzenia systemowe zgodnie z opisem w dokumentacji pakietu SDK. Pamiętaj, że to wymaganie nie jest sprzeczne z sekcją 3.5, ponieważ ograniczenia dotyczące aplikacji działających w tle są również opisane w dokumentacji pakietu SDK.

3.2.3.5. Domyślne ustawienia aplikacji

Android ma ustawienia, które ułatwiają użytkownikom wybieranie aplikacji domyślnych, np. ekranu głównego lub aplikacji do SMS-ów.

W odpowiednich przypadkach implementacje urządzeń MUSZĄ udostępniać podobne menu ustawień i być zgodne z wzorcem filtra intencji oraz metodami interfejsu API opisanymi w dokumentacji pakietu SDK, jak poniżej.

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

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

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

• [C-2-1] MUSI udostępniać menu ustawień, które wywołuje intencję RoleManager.createRequestRoleIntent(String) z parametrem RoleManager.ROLE_SMS, aby wyświetlić okno umożliwiające zmianę domyślnej aplikacji do SMS-ów.

• [C-2-2] MUSI uwzględniać intencję android.telecom.action.CHANGE_DEFAULT_DIALER wyświetlenia okna dialogowego, które umożliwi użytkownikowi zmianę domyślnej aplikacji do telefonowania.

  • MUSI używać interfejsu wybranej przez użytkownika domyślnej aplikacji Telefon do połączeń przychodzących i wychodzących, z wyjątkiem połączeń alarmowych, które będą korzystać z zainstalowanej fabrycznie aplikacji Telefon.

• [C-2-3] MUSI obsługiwać intencję android.telecom.action.CHANGE_PHONE_ACCOUNTS, aby umożliwić użytkownikowi skonfigurowanie ConnectionServices powiązanego z PhoneAccounts, a także domyślnego konta PhoneAccount, którego dostawca usług telekomunikacyjnych będzie używać do wykonywania połączeń wychodzących. Implementacja AOSP spełnia to wymaganie, ponieważ w menu ustawień „Połączenia” znajduje się menu „Konta połączeń”.

• [C-2-4] MUSI zezwalać na android.telecom.CallRedirectionService w przypadku aplikacji, która ma rolę android.app.role.CALL_REDIRECTION.

• [C-2-5] MUSI udostępniać użytkownikowi możliwość wyboru aplikacji, która pełni rolę android.app.role.CALL_REDIRECTION.

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

• [C-3-1] MUSI obsługiwać intencję android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlać domyślne menu ustawień aplikacji do płatności w systemie Zbliż i zapłać.

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

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

3.2.4. Aktywności na dodatkowych/wielu wyświetlaczach

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych aktywności Androida na więcej niż jednym wyświetlaczu:

• [C-1-1] MUSI ustawić flagę funkcji android.software.activities_on_secondary_displays.
• [C-1-2] MUSI gwarantować zgodność interfejsu API podobną do zgodności działania na wyświetlaczu głównym.
• [C-1-3] MUSI uruchamiać nową aktywność na tym samym wyświetlaczu co aktywność, która ją uruchomiła, gdy nowa aktywność jest uruchamiana bez określania wyświetlacza docelowego za pomocą interfejsu ActivityOptions.setLaunchDisplayId() API.
• [C-1-4] MUSI usuwać wszystkie działania, gdy ekran z flagą Display.FLAG_PRIVATE zostanie usunięty.
• [C-1-5] MUSI bezpiecznie ukrywać treści na wszystkich ekranach, gdy urządzenie jest zablokowane za pomocą bezpiecznej blokady ekranu, chyba że aplikacja zdecyduje się na wyświetlanie na ekranie blokady za pomocą interfejsu Activity#setShowWhenLocked() API.
• POWINIEN mieć android.content.res.Configuration odpowiadający temu wyświetlaczowi, aby wyświetlać treści, działać prawidłowo i zachować zgodność, jeśli aktywność zostanie uruchomiona na wyświetlaczu dodatkowym.

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych aktywności Androida na dodatkowych wyświetlaczach, a dodatkowy wyświetlacz ma flagę android.view.Display.FLAG_PRIVATE:

• [C-3-1] Tylko właściciel wyświetlacza, systemu i aktywności, które są już na tym wyświetlaczu, MUSI mieć możliwość uruchomienia ich na tym wyświetlaczu. Każdy może uruchomić wyświetlacz z flagą android.view.Display.FLAG_PUBLIC.

3.3. Zgodność z natywnym interfejsem API

Zgodność kodu natywnego jest trudna. Z tego powodu producenci urządzeń:

• [SR] ZDECYDOWANIE ZALECA SIĘ korzystanie z implementacji bibliotek wymienionych poniżej z projektu Android Open Source Project.

3.3.1. Interfejsy binarne aplikacji

Zarządzany kod bajtowy Dalvik może wywoływać kod natywny dostarczony w pliku .apk aplikacji jako plik ELF .so skompilowany dla odpowiedniej architektury sprzętowej urządzenia. Kod natywny jest w dużym stopniu zależny od technologii procesora, dlatego w Android NDK zdefiniowano kilka interfejsów binarnych aplikacji (ABI).

Implementacje na urządzeniach:

• [C-0-1] MUSI być zgodny z co najmniej jednym zdefiniowanym interfejsem ABI i zapewniać zgodność z Android NDK.
• [C-0-2] MUSI obsługiwać wywoływanie kodu natywnego przez kod działający w środowisku zarządzanym przy użyciu standardowej semantyki interfejsu Java Native Interface (JNI).
• [C-0-3] MUSI być zgodna ze źródłem (tj. zgodna z nagłówkami) i binarnie (w przypadku interfejsu ABI) z każdą wymaganą biblioteką na liście poniżej.
• [C-0-5] MUSI dokładnie raportować natywny interfejs binarny aplikacji (ABI) obsługiwany 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 z nich to rozdzielona przecinkami lista interfejsów ABI uporządkowana od najbardziej do najmniej preferowanego.

• [C-0-6] MUSI raportować za pomocą powyższych parametrów podzbiór poniższej listy interfejsów ABI i NIE MOŻE raportować żadnego interfejsu ABI, którego nie ma na liście.

  • armeabi
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

  • [C-0-7] MUSI udostępniać aplikacjom zawierającym kod natywny wszystkie te biblioteki z natywnymi interfejsami API:

  • libaaudio.so (natywna obsługa dźwięku AAudio)

  • libamidi.so (natywna obsługa MIDI, jeśli funkcja android.software.midi jest zadeklarowana zgodnie z opisem w sekcji 5.9)
  • libandroid.so (obsługa natywnej aktywności Androida)
  • libc (biblioteka C)
  • libcamera2ndk.so
  • libdl (dynamic linker)
  • 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 Androidzie)
  • 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 C++)
  • libvulkan.so (Vulkan)
  • libz (kompresja Zlib)
  • Interfejs JNI

• [C-0-8] NIE WOLNO dodawać ani usuwać funkcji publicznych w przypadku wymienionych powyżej bibliotek natywnych.

• [C-0-9] MUSI podać dodatkowe biblioteki inne niż AOSP udostępniane bezpośrednio aplikacjom innych firm w /vendor/etc/public.libraries.txt.
• [C-0-10] NIE WOLNO udostępniać żadnych innych bibliotek natywnych zaimplementowanych i udostępnianych w AOSP jako biblioteki systemowe aplikacjom innych firm kierowanym na interfejs API na poziomie 24 lub wyższym, ponieważ są one zarezerwowane.
• [C-0-11] MUSI eksportować wszystkie symbole funkcji OpenGL ES 3.1 i Android Extension Pack zdefiniowane w NDK za pomocą biblioteki libGLESv3.so. Pamiętaj, że wszystkie symbole MUSZĄ być obecne, ale w sekcji 7.1.4.1 znajdziesz szczegółowe wymagania dotyczące tego, kiedy oczekiwane jest pełne wdrożenie poszczególnych funkcji.
• [C-0-12] MUSI eksportować symbole funkcji dla podstawowych symboli funkcji Vulkan 1.0, a także rozszerzeń VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 i VK_KHR_get_physical_device_properties2 za pomocą biblioteki libvulkan.so. Pamiętaj, że wszystkie symbole MUSZĄ być obecne, ale w sekcji 7.1.4.2 znajdziesz szczegółowe wymagania dotyczące tego, kiedy oczekiwane jest pełne wdrożenie poszczególnych funkcji.
• POWINNY być tworzone przy użyciu kodu źródłowego i plików nagłówkowych dostępnych w projekcie Android Open Source Project.

Pamiętaj, że w przyszłych wersjach Androida może zostać wprowadzona obsługa dodatkowych interfejsów ABI.

3.3.2. Zgodność z 32-bitowym kodem natywnym ARM

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

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

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

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

  • Features:, a następnie lista opcjonalnych funkcji procesora ARMv7 obsługiwanych przez urządzenie.
  • CPU architecture:, a po nim liczba całkowita opisująca najwyższą obsługiwaną architekturę ARM urządzenia (np. „8” w przypadku urządzeń ARMv8).

• [C-2-2] MUSI zawsze udostępniać te operacje, nawet jeśli interfejs ABI jest zaimplementowany na architekturze ARMv8, za pomocą natywnej obsługi procesora lub emulacji oprogramowania:

  • Instrukcje dotyczące SWP i SWPB.
  • Instrukcja SETEND.
  • operacje bariery CP15ISB, CP15DSB i CP15DMB.

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

3.4. Zgodność z internetem

3.4.1. Zgodność z WebView

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

• [C-1-1] MUSI zgłaszać android.software.webview.
• [C-1-2] MUSI używać kompilacji projektu Chromium z projektu Android Open Source Project w gałęzi Androida 10 do implementacji interfejsu API android.webkit.WebView.

• [C-1-3] Ciąg znaków klienta użytkownika zgłaszany 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ć taką samą wartość jak android.os.Build.MODEL.
  • „Build/$(BUILD)” MOŻE zostać pominięty, ale jeśli jest obecny, ciąg $(BUILD) MUSI być taki sam jak wartość android.os.Build.ID.
  • Wartość ciągu $(CHROMIUM_VER) MUSI być wersją Chromium w projekcie Android Open Source Project.
  • Implementacje urządzeń MOGĄ pomijać ciąg znaków klienta użytkownika „Mobile”.

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

• [C-1-4] MUSI renderować dostarczone treści lub treści z odległego adresu URL w procesie odrębnym od aplikacji, która tworzy instancję WebView. W szczególności oddzielny proces renderowania MUSI mieć niższe uprawnienia, działać z użyciem oddzielnego identyfikatora użytkownika, nie mieć dostępu do katalogu danych aplikacji, nie mieć bezpośredniego dostępu do sieci i mieć dostęp tylko do minimalnej liczby wymaganych usług systemowych za pomocą interfejsu Binder. Implementacja WebView w AOSP spełnia to wymaganie.

Pamiętaj, że jeśli implementacje urządzeń są 32-bitowe lub deklarują flagę funkcji android.hardware.ram.low, są zwolnione z wymagania 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:

• [C-1-1] MUSI obsługiwać każdy z tych interfejsów API powiązanych z HTML5:
  • pamięć podręczna aplikacji/działanie w trybie offline
  • Tag<video>
  • geolocation
• [C-1-2] MUSI obsługiwać interfejs webstorage API w HTML5/W3C i POWINIEN obsługiwać interfejs IndexedDB API w HTML5/W3C. Pamiętaj, że organizacje zajmujące się standardami tworzenia stron internetowych przechodzą na IndexedDB zamiast webstorage, więc w przyszłej wersji Androida IndexedDB będzie prawdopodobnie wymaganym komponentem.
• MOŻE wysyłać niestandardowy ciąg znaków klienta użytkownika w samodzielnej aplikacji przeglądarki.
• POWINNA implementować w samodzielnej aplikacji przeglądarki jak najwięcej funkcji HTML5 (niezależnie od tego, czy jest ona oparta na aplikacji przeglądarki WebKit, czy na zamienniku innej firmy).

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

• [C-2-1] MUSI nadal obsługiwać wzorce intencji publicznych zgodnie z opisem w sekcji 3.2.3.1.

3.5. Zgodność behawioralna interfejsu API

Implementacje na urządzeniach:

• [C-0-9] MUSI zapewnić zgodność zachowania interfejsu API we wszystkich zainstalowanych aplikacjach, chyba że są one ograniczone w sposób opisany w sekcji 3.5.1.
• [C-0-10] NIE WOLNO wdrażać podejścia opartego na liście dozwolonych, które zapewnia zgodność zachowania interfejsu API tylko w przypadku aplikacji wybranych przez producentów urządzeń.

Działanie każdego typu interfejsu API (zarządzanego, łagodnego, natywnego i internetowego) MUSI być zgodne z preferowaną implementacją projektu Android Open Source Project. Oto niektóre obszary zgodności:

• [C-0-1] Urządzenia NIE MOGĄ zmieniać działania ani semantyki standardowego zamiaru.
• [C-0-2] Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (np. usługi, aktywności, dostawcy treści itp.).
• [C-0-3] Urządzenia NIE MOGĄ zmieniać semantyki standardowego uprawnienia.
• Urządzenia NIE MOGĄ zmieniać ograniczeń nałożonych na aplikacje działające w tle. W przypadku aplikacji działających w tle:
  • [C-0-4] MUSZĄ przestać wykonywać wywołania zwrotne zarejestrowane przez aplikację w celu otrzymywania danych wyjściowych z funkcji GnssMeasurement i GnssNavigationMessage.
  • [C-0-5] MUSZĄ ograniczać częstotliwość aktualizacji przekazywanych do aplikacji za pomocą klasy interfejsu API LocationManager lub metody WifiManager.startScan().
  • [C-0-6] Jeśli aplikacja jest kierowana na interfejs API w wersji 25 lub nowszej, NIE MOŻE zezwalać na rejestrowanie odbiorników transmisji w przypadku niejawnych transmisji standardowych intencji Androida w pliku manifestu aplikacji, chyba że intencja transmisji wymaga uprawnienia "signature" lub "signatureOrSystem" protectionLevel albo znajduje się na liście wyjątków.
  • [C-0-7] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zatrzymać usługi działające w tle, tak jakby wywołała metodę stopSelf() tych usług, chyba że aplikacja znajduje się na tymczasowej liście dozwolonych, aby wykonać zadanie widoczne dla użytkownika.
  • [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zwalniać blokady wybudzania, które utrzymuje.
• [C-0-9] Urządzenia MUSZĄ zwracać te dostawców zabezpieczeń jako pierwsze 7 wartości tablicy z metody Security.getProviders() w podanej kolejności i z podanymi nazwami (zwracanymi przez Provider.getName()) oraz klasami, chyba że aplikacja zmodyfikowała listę za pomocą insertProviderAt() lub removeProvider(). Urządzenia MOGĄ zwracać dodatkowych dostawców po określonej liście dostawców poniżej.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

Powyższa lista nie jest wyczerpująca. Pakiet testów zgodności (CTS) sprawdza znaczną część platformy pod kątem zgodności zachowań, ale nie wszystkie. Osoba wdrażająca jest odpowiedzialna za zapewnienie zgodności zachowania z projektem Android Open Source Project. Z tego powodu producenci urządzeń POWINNI w miarę możliwości korzystać z kodu źródłowego dostępnego w ramach Projektu Android Open Source, zamiast ponownie implementować znaczną część systemu.

3.5.1. Ograniczenie działania w tle

Jeśli implementacje urządzeń wdrażają ograniczenia aplikacji, które są zawarte w AOSP, lub rozszerzają te ograniczenia:

• [C-1-1] MUSI udostępniać użytkownikowi możliwość wyświetlenia listy aplikacji z ograniczeniami.
• [C-1-2] MUSI umożliwiać użytkownikowi włączanie i wyłączanie ograniczeń w przypadku poszczególnych aplikacji.
• [C-1-3] NIE MOŻE automatycznie stosować ograniczeń bez dowodu na nieprawidłowe działanie systemu, ale MOŻE stosować ograniczenia w przypadku aplikacji po wykryciu nieprawidłowego działania systemu, takiego jak zablokowane wybudzenia, długo działające usługi i inne kryteria. Kryteria MOGĄ być określane przez producentów urządzeń, 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ć używane jako kryteria.
• [C-1-4] NIE MOŻE automatycznie stosować ograniczeń dotyczących aplikacji, gdy użytkownik ręcznie wyłączył te ograniczenia, i MOŻE sugerować użytkownikowi zastosowanie ograniczeń dotyczących aplikacji.
• [C-1-5] MUSI informować użytkowników, jeśli ograniczenia aplikacji są stosowane automatycznie.
• [C-1-6] MUSI zwracać true w przypadku ActivityManager.isBackgroundRestricted(), gdy ograniczona aplikacja wywołuje ten interfejs API.
• [C-1-7] NIE MOŻE ograniczać działania aplikacji na pierwszym planie, która jest wyraźnie używana przez użytkownika.
• [C-1-8] MUSI zawiesić ograniczenia dotyczące aplikacji, która staje się aplikacją na pierwszym planie, gdy użytkownik wyraźnie zaczyna korzystać z aplikacji, która była wcześniej 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, producenci urządzeń NIE MOGĄ wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w tych przestrzeniach nazw pakietów:

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

Oznacza to, że:

• [C-0-1] NIE WOLNO modyfikować publicznie udostępnianych interfejsów API na platformie Android, zmieniając sygnatury metod lub klas ani usuwając klas lub pól klas.
• [C-0-2] NIE WOLNO dodawać do interfejsów API w przestrzeniach nazw wymienionych powyżej żadnych elementów publicznych (takich jak klasy lub interfejsy albo pola lub metody do istniejących klas lub interfejsów) ani interfejsów API testowych lub systemowych. „Publicznie udostępniony element” to dowolna konstrukcja, która nie jest oznaczona markerem „@hide” używanym w źródłowym kodzie Androida.

Producenci urządzeń MOGĄ modyfikować implementację interfejsów API, ale takie modyfikacje:

• [C-0-3] NIE MOŻE wpływać na deklarowane działanie ani sygnaturę w języku Java żadnych publicznie udostępnianych interfejsów API.
• [C-0-4] NIE MOŻE być reklamowany ani w inny sposób udostępniany deweloperom.

Producenci urządzeń MOGĄ jednak dodawać niestandardowe interfejsy API poza standardową przestrzenią nazw Androida, ale te niestandardowe interfejsy API:

• [C-0-5] NIE MOŻE znajdować się w przestrzeni nazw należącej do innej organizacji lub odnoszącej się do niej. Na przykład producenci urządzeń NIE MOGĄ dodawać interfejsów API do przestrzeni nazw com.google.* ani podobnych: może to robić tylko Google. Podobnie Google NIE MOŻE dodawać interfejsów API do przestrzeni nazw innych firm.
• [C-0-6] MUSI być spakowany w postaci biblioteki współdzielonej Androida, aby zwiększone zużycie pamięci przez takie interfejsy API wpływało tylko na aplikacje, które z nich korzystają (za pomocą mechanizmu <uses-library>).

Jeśli producent urządzenia zaproponuje ulepszenie jednej z przestrzeni nazw pakietów wymienionych powyżej (np. przez dodanie przydatnej nowej funkcji do istniejącego interfejsu API lub dodanie nowego interfejsu API), powinien odwiedzić stronę source.android.com i rozpocząć proces przesyłania zmian i kodu zgodnie z informacjami na tej stronie.

Powyższe ograniczenia są zgodne ze standardowymi konwencjami nazewnictwa interfejsów API w języku programowania Java. Ta sekcja ma jedynie na celu wzmocnienie tych konwencji i uczynienie ich wiążącymi poprzez 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 pliku wykonywalnego Dalvik (DEX) oraz specyfikację i semantykę kodu bajtowego Dalvik.

• [C-0-2] MUSI skonfigurować środowiska wykonawcze Dalvik tak, aby przydzielały pamięć zgodnie z platformą Android i zgodnie z tabelą poniżej. (Definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).

• POWINNA używać środowiska Android RunTime (ART), referencyjnej implementacji formatu wykonywalnego Dalvik, oraz systemu zarządzania pakietami referencyjnej implementacji.

• POWINNY przeprowadzać testy fuzzing w różnych trybach wykonywania i na różnych architekturach docelowych, aby zapewnić stabilność środowiska wykonawczego. Więcej informacji znajdziesz na stronach JFuzz i DexFuzz w witrynie Projektu Android Open Source.

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

3.8. Zgodność interfejsu

3.8.1. Menu z aplikacjami (ekran główny)

Android zawiera aplikację uruchamiającą (ekran główny) i obsługuje aplikacje innych firm, które mogą zastąpić aplikację uruchamiającą urządzenia (ekran główny).

Jeśli implementacje urządzeń umożliwiają aplikacjom innych firm zastąpienie 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 używa tagu <adaptive-icon> do udostępniania swojej ikony i wywoływane są metody PackageManager do pobierania ikon.

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łaszać true w przypadku ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] MUSI mieć funkcję, która przed dodaniem skrótu zażądanego przez aplikacje za pomocą metody interfejsu API ShortcutManager.requestPinShortcut() wyświetla użytkownikowi prośbę o potwierdzenie.
• [C-2-3] MUSI obsługiwać przypięte skróty oraz skróty dynamiczne i statyczne zgodnie z dokumentacją na stronie Skróty do aplikacji.

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

• [C-3-1] MUSI zgłaszać false w przypadku ShortcutManager.isRequestPinShortcutSupported().

Jeśli implementacje urządzeń zawierają domyślny program uruchamiający, który zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu ShortcutManager API:

• [C-4-1] MUSI obsługiwać wszystkie udokumentowane funkcje skrótów (np. skróty statyczne i dynamiczne, przypinanie skrótów) i w pełni implementować interfejsy API klasy ShortcutManager.

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

• [C-5-1] MUSI respektować metodę interfejsu API NotificationChannel.setShowBadge(). Innymi słowy, jeśli wartość jest ustawiona jako true, wyświetlaj wizualny element interfejsu powiązany z ikoną aplikacji. Jeśli wszystkie kanały powiadomień aplikacji mają wartość ustawioną jako false, nie wyświetlaj żadnego schematu oznaczeń ikony aplikacji.
• MOGĄ zastępować plakietki ikon aplikacji własnym schematem plakietek, gdy aplikacje innych firm wskazują, że obsługują ten schemat, korzystając z zastrzeżonych interfejsów API, ale POWINNY używać zasobów i wartości udostępnianych przez interfejsy API plakietek powiadomień opisane w pakiecie SDK, takie jak interfejsy API Notification.Builder.setNumber() i Notification.Builder.setBadgeIconType().

3.8.2. Widżety

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

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

• [C-1-1] MUSI deklarować obsługę funkcji platformy android.software.app_widgets.
• [C-1-2] MUSI zawierać wbudowaną obsługę widżetów aplikacji i udostępniać interfejs użytkownika umożliwiający dodawanie, konfigurowanie, wyświetlanie i usuwanie widżetów aplikacji bezpośrednio w programie uruchamiającym.
• [C-1-3] MUSI być w stanie renderować widżety o rozmiarze 4 x 4 w standardowej siatce. Szczegółowe informacje znajdziesz w wytycznych dotyczących projektowania widżetów aplikacji w dokumentacji pakietu Android SDK.
• MOŻE obsługiwać widżety aplikacji na ekranie blokady.

Jeśli implementacje urządzeń obsługują widżety aplikacji innych firm i przypinanie skrótów w aplikacjach:

• [C-2-1] MUSI zgłaszać true w przypadku AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] MUSI mieć funkcję, która przed dodaniem skrótu zażądanego przez aplikacje za pomocą metody interfejsu API AppWidgetManager.requestPinAppWidget() wyświetla użytkownikowi prośbę o potwierdzenie.

3.8.3. Powiadomienia

Android zawiera interfejsy API Notification i NotificationManager, które umożliwiają deweloperom aplikacji innych firm powiadamianie użytkowników o ważnych zdarzeniach i przyciąganie ich uwagi za pomocą komponentów sprzętowych (np. dźwięku, wibracji i światła) oraz funkcji oprogramowania (np. panelu powiadomień, paska systemowego) urządzenia.

3.8.3.1. Wyświetlanie powiadomień

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

• [C-1-1] MUSI obsługiwać powiadomienia korzystające z funkcji sprzętowych zgodnie z opisem w dokumentacji pakietu SDK i w zakresie, w jakim jest to możliwe w przypadku sprzętu urządzenia. Jeśli na przykład implementacja urządzenia zawiera wibrator, MUSI prawidłowo implementować interfejsy API wibracji. Jeśli implementacja urządzenia nie ma sprzętu, odpowiednie interfejsy API MUSZĄ być zaimplementowane jako operacje bez efektu. Więcej informacji o tym znajdziesz w sekcji 7.
• [C-1-2] MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki animacji itp.) udostępnione w interfejsach API lub w przewodniku po stylu ikon na pasku stanu lub systemowym, ale MOŻE zapewniać alternatywne wrażenia użytkownika w przypadku powiadomień niż te, które są dostępne w referencyjnej implementacji Androida Open Source.
• [C-1-3] MUSI prawidłowo obsługiwać i wdrażać zachowania opisane w interfejsach API w celu aktualizowania, usuwania i grupowania powiadomień.
• [C-1-4] MUSI udostępniać pełne działanie interfejsu NotificationChannel API udokumentowane w pakiecie SDK.
• [C-1-5] MUSI udostępniać użytkownikowi możliwość blokowania i modyfikowania powiadomień określonej aplikacji innej firmy na poziomie każdego kanału i pakietu aplikacji.
• [C-1-6] MUSI też udostępniać użytkownikowi możliwość wyświetlania usuniętych kanałów powiadomień.
• [C-1-7] MUSI prawidłowo renderować wszystkie zasoby (obrazy, naklejki, ikony itp.) dostarczone za pomocą Notification.MessagingStyle wraz z tekstem powiadomienia bez dodatkowej interakcji użytkownika. Na przykład MUSI wyświetlać wszystkie zasoby, w tym ikony udostępniane przez android.app.Person, w rozmowie grupowej ustawionej za pomocą setGroupConversation.
• [C-SR] Zdecydowanie zaleca się automatyczne wyświetlanie użytkownikowi możliwości zablokowania powiadomień określonej aplikacji innej firmy na poziomie każdego kanału i pakietu aplikacji po tym, jak użytkownik wielokrotnie odrzuci to powiadomienie.
• POWINIEN obsługiwać powiadomienia z elementami rozszerzonymi.
• POWINNY wyświetlać niektóre powiadomienia o wyższym priorytecie jako powiadomienia z ostrzeżeniem.
• POWINNA mieć możliwość wyciszania powiadomień.
• MAY może zarządzać tylko widocznością i czasem, w którym aplikacje innych firm mogą powiadamiać użytkowników o istotnych zdarzeniach, aby ograniczyć problemy z bezpieczeństwem, takie jak rozproszenie uwagi kierowcy.

Jeśli implementacje urządzeń obsługują powiadomienia z elementami multimedialnymi:

• [C-2-1] W przypadku prezentowanych elementów zasobów MUSI używać dokładnych zasobów udostępnianych przez klasę interfejsu API Notification.Style i jej podklasy.
• POWINNA prezentować wszystkie elementy zasobu (np. ikonę, tytuł i tekst podsumowania) zdefiniowane w klasie interfejsu Notification.Style API i jej podklasach.

Jeśli implementacje urządzeń obsługują powiadomienia heads-up:

• [C-3-1] MUSI używać widoku i zasobów powiadomień typu heads-up zgodnie z opisem w klasie interfejsu API Notification.Builder, gdy wyświetlane są powiadomienia typu heads-up.
• [C-3-2] MUSI wyświetlać działania udostępniane przez interfejs Notification.Builder.addAction() wraz z treścią powiadomienia bez dodatkowej interakcji użytkownika, zgodnie z opisem w pakiecie SDK.

3.8.3.2. Usługa odbiornika powiadomień

Android zawiera interfejsy API NotificationListenerService, które umożliwiają aplikacjom (po wyraźnym włączeniu przez użytkownika) otrzymywanie kopii wszystkich powiadomień w momencie ich opublikowania lub zaktualizowania.

Jeśli implementacje urządzeń zgłaszają flagę funkcji android.hardware.ram.normal:

• [C-1-1] MUSI prawidłowo i niezwłocznie aktualizować powiadomienia w całości we wszystkich zainstalowanych i włączonych przez użytkownika usługach odbiorczych, w tym wszystkie metadane dołączone do obiektu powiadomienia.
• [C-1-2] MUSI uwzględniać wywołanie interfejsu API snoozeNotification() i zamykać powiadomienie oraz wywoływać funkcję zwrotną po upływie czasu odroczenia ustawionego w wywołaniu interfejsu API.

Jeśli implementacje urządzeń mają funkcję wyciszania powiadomień, to:

• [C-2-1] MUSI prawidłowo odzwierciedlać stan odroczonego powiadomienia za pomocą standardowych interfejsów API, takich jak NotificationListenerService.getSnoozedNotifications().
• [C-2-2] MUSI udostępniać użytkownikowi możliwość odraczania powiadomień z każdej zainstalowanej aplikacji innej firmy, z wyjątkiem powiadomień z usług działających na pierwszym planie lub usług trwałych.

3.8.3.3. Nie przeszkadzać

Jeśli implementacje urządzeń obsługują funkcję Nie przeszkadzać:

• [C-1-1] MUSI implementować aktywność, która odpowiada na intencję ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. W przypadku implementacji z UI_MODE_TYPE_NORMAL MUSI to być aktywność, w której użytkownik może przyznać lub odmówić aplikacji dostępu do konfiguracji zasad „Nie przeszkadzać”.
• [C-1-2] MUSI wyświetlać automatyczne reguły trybu „Nie przeszkadzać” utworzone przez aplikacje obok reguł utworzonych przez użytkownika i reguł predefiniowanych, jeśli implementacja urządzenia umożliwia użytkownikowi przyznawanie lub odmawianie aplikacjom innych firm dostępu do konfiguracji zasad trybu „Nie przeszkadzać”.
• [C-1-3] MUSI uwzględniać wartości suppressedVisualEffects przekazywane w ramach NotificationManager.Policy. Jeśli aplikacja ustawiła którykolwiek z tych flag: SUPPRESSED_EFFECT_SCREEN_OFF lub SUPPRESSED_EFFECT_SCREEN_ON, POWINNA poinformować użytkownika, że efekty wizualne są wyłączone w menu ustawień trybu „Nie przeszkadzać”.

3.8.4. Szukaj

Android zawiera interfejsy API, które umożliwiają deweloperom włączenie wyszukiwania do aplikacji i udostępnianie danych aplikacji w globalnym wyszukiwaniu systemowym. Ogólnie rzecz biorąc, ta funkcja składa się z jednego interfejsu użytkownika w całym systemie, który umożliwia użytkownikom wpisywanie zapytań, wyświetla sugestie podczas pisania i wyświetla wyniki. Interfejsy API Androida umożliwiają deweloperom ponowne wykorzystanie tego interfejsu do wyszukiwania w ich własnych aplikacjach oraz dostarczanie wyników do wspólnego interfejsu wyszukiwania globalnego.

• Implementacje urządzeń z Androidem POWINNY obejmować wyszukiwanie globalne, czyli jeden wspólny interfejs wyszukiwania w całym systemie, który może wyświetlać sugestie w czasie rzeczywistym w odpowiedzi na dane wejściowe użytkownika.

Jeśli implementacje urządzeń implementują interfejs wyszukiwania globalnego:

• [C-1-1] MUSI implementować interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii do pola wyszukiwania, gdy jest ono uruchomione w trybie wyszukiwania globalnego.

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

• Domyślnie POWINNY być wyświetlane wyniki i sugestie wyszukiwarki.

Android zawiera też interfejsy Assist API, które umożliwiają aplikacjom określanie, ile informacji o bieżącym kontekście jest udostępnianych asystentowi na urządzeniu.

Jeśli implementacje urządzeń obsługują działanie Asystuj, to:

• [C-2-1] MUSI wyraźnie informować użytkownika o udostępnianiu kontekstu, w jeden z tych sposobów:
  • Za każdym razem, gdy aplikacja asystująca uzyskuje dostęp do kontekstu, wokół krawędzi ekranu wyświetla się białe światło, które spełnia lub przekracza czas trwania i jasność implementacji w ramach projektu Android Open Source.
  • W przypadku preinstalowanej aplikacji wspomagającej udostępnianie użytkownikowi możliwości wykonania mniej niż 2 nawigacji od menu ustawień domyślnej aplikacji do wprowadzania głosowego i aplikacji wspomagającej oraz udostępnianie kontekstu tylko wtedy, gdy aplikacja wspomagająca jest wyraźnie wywoływana przez użytkownika za pomocą słowa aktywującego lub klawisza nawigacji wspomagającej.
• [C-2-2] Wyznaczona interakcja służąca do uruchamiania aplikacji wspomagającej opisana w sekcji 7.2.3 MUSI uruchamiać wybraną przez użytkownika aplikację wspomagającą, czyli aplikację, która implementuje VoiceInteractionService, lub aktywność obsługującą intencję ACTION_ASSIST.

3.8.5. Alerty i wyskakujące okienka

Aplikacje mogą używać interfejsu Toast API do wyświetlania użytkownikowi krótkich ciągów znaków, które nie są modalne i znikają po krótkim czasie, oraz interfejsu TYPE_APPLICATION_OVERLAY API typu okna do wyświetlania okien alertów jako nakładki na inne aplikacje.

Jeśli urządzenie ma ekran lub wyjście wideo:

• [C-1-1] MUSI udostępniać użytkownikowi możliwość blokowania wyświetlania przez aplikację okien alertów korzystających z TYPE_APPLICATION_OVERLAY . Implementacja AOSP spełnia to wymaganie, ponieważ elementy sterujące znajdują się w panelu powiadomień.

• [C-1-2] MUSI obsługiwać interfejs Toast API i wyświetlać użytkownikom powiadomienia Toast z aplikacji w sposób dobrze widoczny.

3.8.6. Motywy

Android udostępnia „motywy” jako mechanizm stosowania stylów w całej aktywności lub aplikacji.

Android zawiera rodzinę motywów „Holo” i „Material” jako zestaw zdefiniowanych stylów, z których mogą korzystać deweloperzy aplikacji, jeśli chcą dopasować wygląd i działanie motywu Holo zdefiniowane w pakiecie Android SDK.

Jeśli urządzenie ma ekran lub wyjście wideo:

• [C-1-1] NIE WOLNO zmieniać żadnych atrybutów motywu Holo udostępnianych aplikacjom.
• [C-1-2] MUSI obsługiwać rodzinę motywów „Material” i NIE MOŻE zmieniać żadnych atrybutów motywu Material ani zasobów udostępnianych aplikacjom.

Android zawiera też rodzinę motywów „Domyślny motyw urządzenia” jako zestaw zdefiniowanych stylów, których mogą używać deweloperzy aplikacji, jeśli chcą dopasować wygląd i sposób obsługi motywu urządzenia zdefiniowanego przez producenta urządzenia.

• Implementacje urządzeń MOGĄ modyfikować atrybuty domyślnego motywu urządzenia udostępniane aplikacjom.

Android obsługuje wariant motywu z półprzezroczystymi paskami systemowymi, co pozwala deweloperom aplikacji wypełniać obszar za paskiem stanu i paskiem nawigacyjnym treściami aplikacji. Aby zapewnić spójność środowiska deweloperskiego w tej konfiguracji, ważne jest, aby styl ikony paska stanu był zachowany w różnych implementacjach urządzenia.

Jeśli implementacje urządzeń zawierają pasek stanu systemu:

• [C-2-1] MUSI używać białego koloru w przypadku ikon stanu systemu (takich jak siła sygnału i poziom baterii) oraz powiadomień wydawanych przez system, chyba że ikona wskazuje problematyczny stan lub aplikacja żąda jasnego paska stanu za pomocą flagi SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
• [C-2-2] Implementacje urządzeń z Androidem MUSZĄ zmieniać kolor ikon stanu systemu na czarny (szczegółowe informacje znajdziesz w R.style), gdy aplikacja zażąda jasnego paska stanu.

3.8.7. Animowane tapety

Android definiuje typ komponentu oraz odpowiedni interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikom co najmniej 1 „tapety na żywo”. Animowane tapety to animacje, wzory lub podobne obrazy o ograniczonych możliwościach interakcji, które wyświetlają się jako tapeta za innymi aplikacjami.

Urządzenie jest uznawane za zdolne do niezawodnego uruchamiania animowanych tapet, jeśli może uruchamiać wszystkie animowane tapety bez ograniczeń funkcjonalności, z rozsądną liczbą klatek na sekundę i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują awarie tapet lub aplikacji, ich nieprawidłowe działanie, nadmierne zużycie procesora lub baterii albo działanie z niedopuszczalnie niską liczbą klatek na sekundę, uznaje się, że sprzęt nie jest w stanie obsługiwać tapety animowanej. Na przykład niektóre tapety na żywo mogą używać kontekstu OpenGL 2.0 lub 3.x do renderowania treści. Animowana tapeta nie będzie działać niezawodnie na urządzeniach, które nie obsługują wielu kontekstów OpenGL, ponieważ używanie kontekstu OpenGL przez animowaną tapetę może powodować konflikty z innymi aplikacjami, które również korzystają z kontekstu OpenGL.

• Implementacje urządzeń, które mogą niezawodnie obsługiwać animowane tapety w sposób opisany powyżej, POWINNY je implementować.

Jeśli urządzenia obsługują animowane tapety:

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

3.8.8. Przełączanie aktywności

W źródłowym kodzie Androida znajduje się ekran podglądu, czyli interfejs użytkownika na poziomie systemu, który służy do przełączania zadań i wyświetlania ostatnio używanych działań i zadań za pomocą miniatury stanu graficznego aplikacji w momencie, gdy użytkownik ostatnio ją opuścił.

Implementacje urządzeń, w tym klawisz nawigacyjny funkcji ostatnich aplikacji, zgodnie z opisem w sekcji 7.2.3, MOGĄ zmieniać interfejs.

Jeśli implementacje urządzeń, w tym klawisz nawigacyjny funkcji ostatnich aplikacji, zgodnie z sekcją 7.2.3 zmieniają interfejs, to:

• [C-1-1] MUSI obsługiwać co najmniej 7 wyświetlanych aktywności.
• POWINNA wyświetlać co najmniej tytuły 4 aktywności jednocześnie.
• [C-1-2] MUSI implementować zachowanie przypinania ekranu i udostępniać użytkownikowi menu ustawień, w którym można włączać i wyłączać tę funkcję.
• POWINNA wyświetlać kolor wyróżnienia, ikonę i tytuł ekranu w sekcji Ostatnie.
• POWINNA wyświetlać element zamykający („x”), ale MOŻE opóźnić to do momentu, gdy użytkownik wejdzie w interakcję z ekranami.
• POWINIEN zawierać skrót umożliwiający łatwe przełączenie się na poprzednią aktywność.
• POWINNO wywoływać szybkie przełączanie między dwiema ostatnio używanymi aplikacjami, gdy dwukrotnie naciśniesz klawisz funkcji ostatnich aplikacji.
• POWINNO włączać tryb wielookienkowy na podzielonym ekranie, jeśli jest obsługiwany, gdy klawisz funkcji ostatnich aplikacji jest przytrzymywany.
• MOGĄ wyświetlać powiązane ostatnie wyszukiwania jako grupę, która przesuwa się razem.
• [SR] Zdecydowanie zalecamy używanie interfejsu użytkownika Androida (lub podobnego interfejsu opartego na miniaturach) na ekranie przeglądu.

3.8.9. Zarządzanie danymi wejściowymi

Android obsługuje zarządzanie wprowadzaniem i edytory metod wprowadzania innych firm.

Jeśli implementacje urządzeń umożliwiają użytkownikom korzystanie na urządzeniu z metod wprowadzania dostarczanych przez inne firmy:

• [C-1-1] MUSI deklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy API IME zgodnie z dokumentacją pakietu Android SDK.
• [C-1-2] MUSI udostępniać użytkownikowi mechanizm dodawania i konfigurowania metod wprowadzania innych firm w odpowiedzi na intencję android.settings.INPUT_METHOD_SETTINGS.

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

• [C-2-1] MUSI w pełni implementować interfejsy API AutofillService i AutofillManager oraz uwzględniać intencję android.settings.REQUEST_SET_AUTOFILL_SERVICE, aby wyświetlać domyślne menu ustawień aplikacji, które umożliwia włączanie i wyłączanie autouzupełniania oraz zmianę domyślnej usługi autouzupełniania dla użytkownika.

3.8.10. Sterowanie multimediami z ekranu blokady

Interfejs Remote Control Client API jest od Androida 5.0 wycofany na rzecz szablonu powiadomienia o multimediach, który umożliwia aplikacjom multimedialnym integrację z elementami sterującymi odtwarzaniem wyświetlanymi na ekranie blokady.

3.8.11. Wygaszacze ekranu (wcześniej Dreams)

Android obsługuje interaktywne wygaszacze ekranu, wcześniej nazywane snami. Wygaszacze ekranu umożliwiają użytkownikom interakcję z aplikacjami, gdy urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji dokującej. Urządzenia z Androidem Watch MOGĄ implementować wygaszacze ekranu, ale inne typy urządzeń POWINNY obsługiwać wygaszacze ekranu i udostępniać użytkownikom opcję ustawień, która umożliwia konfigurowanie wygaszaczy ekranu w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

3.8.12. Lokalizacja

Jeśli implementacje urządzeń obejmują czujnik sprzętowy (np. GPS), który może podawać współrzędne lokalizacji,

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

3.8.13. Unicode i czcionka

Android obsługuje znaki emoji zdefiniowane w Unicode 10.0.

Jeśli urządzenie ma ekran lub wyjście wideo:

• [C-1-1] MUSI być w stanie renderować te emotikony w postaci kolorowych glifów.
• [C-1-2] MUSI obsługiwać:
  • Czcionka Roboto 2 o różnej grubości: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light w językach dostępnych na urządzeniu.
  • Pełna obsługa standardu Unicode 7.0 w zakresie alfabetów łacińskiego, greckiego i cyrylicy, w tym zakresów Latin Extended A, B, C i D oraz wszystkich znaków w bloku symboli walut w standardzie Unicode 7.0.
• POWINIEN obsługiwać emotikony przedstawiające odcienie skóry i różnorodne rodziny zgodnie z raportem technicznym Unicode nr 51.

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

• POWINIEN udostępniać użytkownikowi metodę wprowadzania tych emotikonów.

Android obsługuje renderowanie czcionek w języku birmańskim. W Mjanmie do renderowania języków mjanma używa się kilku czcionek niezgodnych ze standardem Unicode, powszechnie znanych jako „Zawgyi”.

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ń umożliwiają wyświetlanie wielu aktywności jednocześnie:

• [C-1-1] MUSI implementować tryby wielu okien zgodnie z zachowaniami aplikacji i interfejsami API opisanymi w dokumentacji pakietu Android SDK dotyczącej obsługi trybu wielu okien oraz spełniać te wymagania:
• [C-1-2] MUSI uwzględniać wartość android:resizeableActivity ustawioną przez aplikację w pliku AndroidManifest.xml zgodnie z opisem w tym pakiecie SDK.
• [C-1-3] NIE MOŻE oferować trybu podzielonego ekranu ani trybu dowolnego, jeśli wysokość ekranu jest mniejsza niż 440 dp, a szerokość ekranu jest mniejsza niż 440 dp.
• [C-1-4] Aktywność NIE MOŻE być zmieniana do rozmiaru mniejszego niż 220 dp w trybach wielu okien innych niż obraz w obrazie.
• Urządzenia z ekranem o rozmiarze xlarge POWINNY obsługiwać tryb dowolny.

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

• [C-2-1] MUSI domyślnie wstępnie wczytywać zmienialny program uruchamiający.
• [C-2-2] MUSI przycinać zadokowaną aktywność w trybie podzielonego ekranu, ale POWINIEN wyświetlać część jej zawartości, jeśli aplikacja uruchamiająca jest aktywnym oknem.
• [C-2-3] MUSI uwzględniać zadeklarowane wartości AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight aplikacji uruchamiającej innej firmy i nie może ich zastępować podczas wyświetlania treści zadokowanej aktywności.

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

• [C-3-1] MUSI uruchamiać aktywności w trybie wielu okien obraz w obrazie, gdy aplikacja: * jest kierowana na interfejs API na poziomie 26 lub wyższym i deklaruje android:supportsPictureInPicture; * jest kierowana na interfejs API na poziomie 25 lub niższym i deklaruje zarówno android:resizeableActivity, jak i android:supportsPictureInPicture.
• [C-3-2] MUSI udostępniać działania w interfejsie SystemUI zgodnie z bieżącą aktywnością PIP za pomocą interfejsu API setActions().
• [C-3-3] MUSI obsługiwać formaty obrazu większe lub równe 1:2,39 i mniejsze lub równe 2,39:1, zgodnie z określeniem aktywności PIP za pomocą interfejsu API setAspectRatio().
• [C-3-4] MUSI używać KeyEvent.KEYCODE_WINDOW do sterowania oknem obrazu w obrazie; jeśli tryb obrazu w obrazie nie jest zaimplementowany, klawisz MUSI być dostępny dla aktywności na pierwszym planie.
• [C-3-5] MUSI udostępniać użytkownikowi możliwość zablokowania wyświetlania aplikacji w trybie obrazu w obrazie. Wymaganie to jest spełnione w implementacji AOSP, która zawiera elementy sterujące w panelu powiadomień.
• [C-3-6] MUSI przydzielać minimalną szerokość i wysokość 108 dp dla okna obrazu w obrazie oraz minimalną szerokość 240 dp i wysokość 135 dp dla okna obrazu w obrazie, gdy Configuration.uiMode jest skonfigurowany jako UI_MODE_TYPE_TELEVISION.

3.8.15. Wycięcie w ekranie

Android obsługuje wycięcie na wyświetlaczu, co opisano w dokumentacji pakietu SDK. Interfejs DisplayCutout API określa obszar na krawędzi wyświetlacza, który nie służy do wyświetlania treści.

Jeśli implementacje urządzeń obejmują wycięcia na wyświetlaczu:

• [C-1-1] Musi mieć wycięcia tylko na krótszych krawędziach urządzenia. Jeśli współczynnik proporcji urządzenia wynosi 1, 0 (1:1), NIE MOŻE ono mieć wycięć.
• [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 na wyświetlaczu ustawione przez aplikację za pomocą interfejsu WindowManager.LayoutParams API zgodnie z opisem w pakiecie SDK.
• [C-1-4] MUSI raportować prawidłowe wartości wszystkich danych dotyczących wycięć zdefiniowanych w interfejsie DisplayCutout API.

3.9. Administracja urządzeniem

Android zawiera funkcje, które umożliwiają aplikacjom dbającym o bezpieczeństwo wykonywanie funkcji administracji urządzeniem na poziomie systemu, takich jak wymuszanie zasad dotyczących haseł czy zdalne czyszczenie pamięci, za pomocą interfejsu Android Device Administration API.

Jeśli implementacje urządzeń obsługują pełen zakres zasad administrowania urządzeniami zdefiniowanych w dokumentacji pakietu Android SDK:

• [C-1-1] MUSISZ zadeklarować android.software.device_admin.
• [C-1-2] MUSI obsługiwać udostępnianie właścicielowi urządzenia zgodnie z opisem w sekcji 3.9.1 i sekcji 3.9.1.1.

3.9.1 Obsługa administracyjna urządzenia

3.9.1.1 Obsługa administracyjna urządzenia należącego do firmy

Jeśli implementacje urządzeń deklarują android.software.device_admin, to:

• [C-1-1] MUSI obsługiwać rejestrację klienta zasad dotyczących urządzeń (DPC) jako aplikacji właściciela urządzenia w sposób opisany poniżej:
  • Jeśli na urządzeniu nie skonfigurowano jeszcze danych użytkownika:
    • [C-1-3] MUSI zgłaszać true w przypadku DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia w odpowiedzi na działanie intencji android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia, jeśli urządzenie deklaruje obsługę komunikacji NFC za pomocą flagi funkcji android.hardware.nfc i odbiera wiadomość NFC zawierającą rekord z typem MIME MIME_TYPE_PROVISIONING_NFC.
  • Jeśli wdrożenie urządzenia zawiera dane użytkownika:
    • [C-1-6] MUSI zgłaszać false w przypadku 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ć podjęcia określonego działania podczas procesu udostępniania, aby wyrazić zgodę na ustawienie aplikacji jako właściciela urządzenia. Zgoda może być wyrażona przez działanie użytkownika lub w sposób programowy podczas udostępniania, ale NIE MOŻE być zakodowana 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 zapewniają mechanizm promowania aplikacji skonfigurowanej w ich rozwiązaniu jako „odpowiednik właściciela urządzenia” do standardowego „właściciela urządzenia” rozpoznawanego przez standardowe interfejsy API Androida DevicePolicyManager, to:

• [C-2-1] MUSI mieć proces weryfikacji, czy promowana aplikacja należy do legalnego rozwiązania do zarządzania urządzeniami firmowymi i czy została już skonfigurowana w rozwiązaniu własnym w taki sposób, aby mieć uprawnienia równoważne z uprawnieniami „właściciela urządzenia”.
• [C-2-2] MUSI wyświetlać te same informacje o uzyskiwaniu zgody użytkownika na bycie właścicielem urządzenia w AOSP, co proces inicjowany przez android.app.action.PROVISION_MANAGED_DEVICE, zanim zarejestruje aplikację DPC jako „właściciela urządzenia”.
• MOŻE zawierać dane użytkownika przed zarejestrowaniem aplikacji DPC jako „Właściciel urządzenia”.

3.9.1.2 Udostępnianie profilu zarządzanego

Jeśli implementacje urządzeń deklarują android.software.managed_users, to:

• [C-1-1] MUSI implementować interfejsy API umożliwiające aplikacji kontrolera zasad dotyczących urządzeń (DPC) stanie się właścicielem nowego profilu zarządzanego.

• [C-1-2] Proces udostępniania profilu zarządzanego (proces inicjowany przez działanie android.app.action.PROVISION_MANAGED_PROFILE) musi być zgodny z implementacją AOSP.

• [C-1-3] MUSI udostępniać w Ustawieniach te informacje dla użytkownika, aby wskazywać, kiedy określona funkcja systemu została wyłączona przez kontroler zasad dotyczących urządzeń (DPC):

  • Spójna ikona lub inny element interfejsu użytkownika (np. ikona informacji AOSP) wskazujący, że dane ustawienie jest ograniczone przez administratora urządzenia.
  • Krótki komunikat z wyjaśnieniem podany przez administratora urządzenia za pomocą interfejsu setShortSupportMessage.
  • Ikona aplikacji DPC.

3.9.2 Obsługa profilu zarządzanego

Jeśli implementacje urządzeń deklarują android.software.managed_users, to:

• [C-1-1] MUSI obsługiwać profile zarządzane za pomocą interfejsów API android.app.admin.DevicePolicyManager.
• [C-1-2] MUSI zezwalać na utworzenie tylko jednego profilu zarządzanego.
• [C-1-3] MUSI używać plakietki ikony (podobnej do plakietki aplikacji służbowej AOSP) do oznaczania zarządzanych aplikacji i widżetów oraz innych elementów interfejsu z plakietkami, takich jak Ostatnie i Powiadomienia.
• [C-1-4] MUSI wyświetlać ikonę powiadomienia (podobną do plakietki profilu służbowego w AOSP), aby wskazywać, kiedy użytkownik korzysta z aplikacji w profilu zarządzanym.
• [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 wyświetlać w „selektorze” intencji element wizualny, który umożliwia użytkownikowi przekazywanie intencji z profilu zarządzanego do użytkownika głównego lub odwrotnie, jeśli jest to włączone przez kontroler zasad dotyczących urządzeń.
• [C-1-7] Jeśli istnieje profil zarządzany, MUSI udostępniać te funkcje użytkownikowi głównemu i profilowi zarządzanemu:
  • Oddzielne rozliczanie zużycia baterii, lokalizacji, mobilnej transmisji danych i pamięci w przypadku głównego użytkownika i zarządzanego profilu.
  • Niezależne zarządzanie aplikacjami VPN zainstalowanymi w profilu głównym lub zarządzanym.
  • Niezależne zarządzanie aplikacjami zainstalowanymi w profilu głównym lub zarządzanym.
  • niezależne zarządzanie kontami w ramach głównego profilu użytkownika lub profilu zarządzanego,
• [C-1-8] MUSI zapewniać, że preinstalowane aplikacje do wybierania numerów, kontaktów i wiadomości mogą wyszukiwać i wyszukiwać informacje o dzwoniącym z profilu zarządzanego (jeśli taki istnieje) oraz z profilu głównego, jeśli zezwala na to kontroler zasad dotyczących urządzeń.
• [C-1-9] MUSI spełniać wszystkie wymagania dotyczące bezpieczeństwa obowiązujące w przypadku urządzenia z włączoną obsługą wielu użytkowników (patrz sekcja 9.5), mimo że profil zarządzany nie jest traktowany jako dodatkowy użytkownik oprócz użytkownika głównego.
• [C-1-10] MUSI obsługiwać możliwość określenia osobnego ekranu blokady spełniającego poniższe wymagania, aby przyznawać dostęp do aplikacji działających w profilu zarządzanym.
  • Implementacje urządzeń MUSZĄ obsługiwać intencję DevicePolicyManager.ACTION_SET_NEW_PASSWORD i wyświetlać interfejs do konfigurowania osobnych danych logowania do blokady ekranu w przypadku profilu zarządzanego.
  • Dane logowania na ekranie blokady profilu zarządzanego MUSZĄ korzystać z tych samych mechanizmów przechowywania i zarządzania danymi logowania co profil nadrzędny, zgodnie z dokumentacją na stronie projektu Android Open Source.
  • Zasady dotyczące haseł DPC MUSZĄ być stosowane tylko do danych logowania na ekranie blokady profilu zarządzanego, chyba że są wywoływane w przypadku instancji DevicePolicyManager zwróconej przez getParentProfileInstance.
• Gdy kontakty z profilu zarządzanego są wyświetlane w preinstalowanym dzienniku połączeń, interfejsie połączenia, powiadomieniach o trwających i nieodebranych połączeniach, aplikacjach do obsługi kontaktów i wiadomości, powinny być oznaczone tą samą plakietką, która jest używana do oznaczania aplikacji z profilu zarządzanego.

3.9.3 Pomoc dla użytkowników zarządzanych

Jeśli implementacje urządzeń deklarują android.software.managed_users, to:

• [C-1-1] MUSI udostępniać użytkownikowi możliwość wylogowania się z bieżącego użytkownika i powrotu do użytkownika głównego w sesji wielu użytkowników, gdy isLogoutEnabled zwraca true. Element interfejsu użytkownika MUSI być dostępny na ekranie blokady bez odblokowywania urządzenia.

3.10. Ułatwienia dostępu

Android udostępnia warstwę ułatwień dostępu, która pomaga osobom z niepełnosprawnościami łatwiej korzystać z urządzeń. Android udostępnia też interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu otrzymywanie wywołań zwrotnych dotyczących zdarzeń użytkownika i systemu oraz generowanie alternatywnych mechanizmów informacji zwrotnej, takich jak zamiana tekstu na mowę, wibracje i nawigacja za pomocą trackballa lub pada kierunkowego.

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

• [C-1-1] MUSI udostępniać implementację platformy ułatwień dostępu na Androida zgodnie z opisem w dokumentacji pakietu SDK interfejsów API ułatwień dostępu.
• [C-1-2] MUSI generować zdarzenia związane z ułatwieniami dostępu i przekazywać odpowiednie AccessibilityEvent do wszystkich zarejestrowanych implementacji AccessibilityService zgodnie z dokumentacją pakietu SDK.
• [C-1-3] MUSI honorować intencję android.settings.ACCESSIBILITY_SETTINGS, aby udostępnić użytkownikowi mechanizm włączania i wyłączania usług ułatwień dostępu innych firm wraz z preinstalowanymi usługami ułatwień dostępu.
• [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 deklarują AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . W przypadku urządzeń bez systemowego paska nawigacyjnego to wymaganie nie ma zastosowania, ale urządzenia POWINNY udostępniać 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:

• [C-2-1] MUSI implementować te preinstalowane usługi ułatwień dostępu jako aplikacje Direct Boot Aware, gdy pamięć masowa jest szyfrowana za pomocą szyfrowania opartego na plikach (FBE).
• POWINIEN udostępniać w procesie konfiguracji po wyjęciu z pudełka mechanizm umożliwiający użytkownikom włączanie odpowiednich usług ułatwień dostępu, a także opcje dostosowywania rozmiaru czcionki, rozmiaru wyświetlacza i gestów powiększania.

3.11. Zamiana tekstu na mowę

Android zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług zamiany tekstu na mowę (TTS), a dostawcom usług – udostępnianie implementacji usług TTS.

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

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

Jeśli implementacje urządzeń obsługują instalację silników TTS innych firm:

• [C-2-1] MUSI udostępniać użytkownikowi możliwość wyboru silnika TTS do użycia na poziomie systemu.

3.12. TV Input Framework

Android Television Input Framework (TIF) upraszcza dostarczanie treści na żywo na urządzenia z Androidem TV. TIF udostępnia standardowy interfejs API do tworzenia modułów wejściowych, które sterują urządzeniami z Androidem TV.

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

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.live_tv.
• [C-1-2] MUSI obsługiwać wszystkie interfejsy API TIF, aby aplikację, która korzysta z tych interfejsów API i usługi danych wejściowych opartych na TIF innych firm, można było zainstalować i używać na urządzeniu.

3.13. Szybkie ustawienia

Android udostępnia komponent interfejsu Szybkie ustawienia, który umożliwia szybki dostęp do często używanych lub pilnie potrzebnych działań.

Jeśli implementacje urządzeń zawierają komponent interfejsu Szybkich ustawień:

• [C-1-1] MUSI umożliwiać użytkownikowi dodawanie lub usuwanie kafelków udostępnianych przez interfejsy API quicksettings z aplikacji innej firmy.
• [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 kafelki dodane przez użytkownika z aplikacji innych firm obok kafelków szybkich ustawień dostarczonych przez system.

3.14. Interfejs multimediów

Jeśli implementacje urządzeń obejmują aplikacje niewłączane głosem (Aplikacje), które wchodzą w interakcje z aplikacjami innych firm za pomocą MediaBrowser lub MediaSession, Aplikacje:

• [C-1-2] MUSI wyraźnie wyświetlać ikony uzyskane za pomocą funkcji getIconBitmap() lub getIconUri() oraz tytuły uzyskane za pomocą funkcji getTitle() zgodnie z opisem w sekcji MediaDescription. Może skrócić tytuły, aby zachować zgodność z przepisami dotyczącymi bezpieczeństwa (np. rozpraszania uwagi kierowcy).

• [C-1-3] MUSI wyświetlać ikonę aplikacji innej firmy za każdym razem, gdy wyświetla treści dostarczane przez tę aplikację.

• [C-1-4] MUSI umożliwiać użytkownikowi interakcję z całą hierarchią MediaBrowser. MOŻE ograniczyć dostęp do części hierarchii, aby zachować zgodność z przepisami dotyczącymi bezpieczeństwa (np. rozpraszania uwagi kierowcy), ale NIE MOŻE przyznawać preferencyjnego traktowania na podstawie treści lub dostawcy treści.

• [C-1-5] MUSI traktować dwukrotne kliknięcie KEYCODE_HEADSETHOOK lub KEYCODE_MEDIA_PLAY_PAUSE jako KEYCODE_MEDIA_NEXT w przypadku MediaSession.Callback#onMediaButtonEvent.

3.15. Aplikacje błyskawiczne

Implementacje urządzeń MUSZĄ spełniać te wymagania:

• [C-0-1] Aplikacje natychmiastowe MUSZĄ mieć przyznane tylko te uprawnienia, które mają wartość android:protectionLevel ustawioną na "instant".
• [C-0-2] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami za pomocą niejawnych intencji, chyba że spełniony jest jeden z tych warunków:
  • Filtr wzorca intencji komponentu jest widoczny i ma wartość CATEGORY_BROWSABLE.
  • Działanie to ACTION_SEND, ACTION_SENDTO lub ACTION_SEND_MULTIPLE.
  • Cel jest jawnie udostępniany za pomocą atrybutu android:visibleToInstantApps.
• [C-0-3] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami, chyba że komponent jest udostępniany za pomocą atrybutu android:visibleToInstantApps.
• [C-0-4] Zainstalowane aplikacje NIE MOGĄ widzieć szczegółów dotyczących aplikacji błyskawicznych na urządzeniu, chyba że aplikacja błyskawiczna wyraźnie połączy się z zainstalowaną aplikacją.
• Implementacje urządzeń MUSZĄ zapewniać użytkownikom te możliwości interakcji z aplikacjami błyskawicznymi: AOSP spełnia wymagania z domyślnym interfejsem systemu, Ustawieniami i Launcherem. Implementacje urządzeń:
  • [C-0-5] MUSI udostępniać użytkownikowi możliwość wyświetlania i usuwania lokalnie zapisanych pakietów aplikacji natychmiastowych dla każdej aplikacji.
  • [C-0-6] MUSI wyświetlać stałe powiadomienie użytkownika, które można zwinąć, gdy aplikacja błyskawiczna działa na pierwszym planie. To powiadomienie MUSI zawierać informację, że aplikacji błyskawicznych nie trzeba instalować, oraz element interfejsu, który przekierowuje użytkownika do ekranu informacji o aplikacji w Ustawieniach. W przypadku aplikacji natychmiastowych uruchamianych za pomocą intencji internetowych (zdefiniowanych przez użycie intencji z działaniem ustawionym na Intent.ACTION_VIEW i schematem „http” lub „https”) dodatkowa funkcja powinna umożliwiać użytkownikowi nieuruchamianie aplikacji natychmiastowej i otwieranie powiązanego linku w skonfigurowanej przeglądarce internetowej, jeśli jest ona dostępna na urządzeniu.
  • [C-0-7] MUSI umożliwiać dostęp do aplikacji natychmiastowych z funkcji Ostatnie, jeśli jest ona dostępna na urządzeniu.

3.16. Parowanie urządzenia towarzyszącego

Android obsługuje parowanie urządzeń towarzyszących, aby skuteczniej zarządzać powiązaniami z nimi. Udostępnia też interfejs API CompanionDeviceManager, który umożliwia aplikacjom korzystanie z tej funkcji.

Jeśli implementacje urządzeń obsługują funkcję parowania urządzeń towarzyszących:

• [C-1-1] MUSI zadeklarować flagę funkcji FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] MUSI zapewnić pełne wdrożenie interfejsów API w pakiecie android.companion.
• [C-1-3] MUSI udostępniać użytkownikowi elementy interfejsu, które pozwalają mu wybrać lub potwierdzić, że urządzenie towarzyszące jest obecne i działa.

3.17. Aplikacje zużywające dużo zasobów

Jeśli implementacje urządzeń deklarują funkcję FEATURE_CANT_SAVE_STATE, to:

• [C-1-1] W systemie musi być zainstalowana tylko 1 aplikacja, która określa cantSaveState. Jeśli użytkownik opuści taką aplikację bez jej wyraźnego zamknięcia (np. naciśnie przycisk ekranu głównego, gdy aktywność jest nadal aktywna w systemie, zamiast nacisnąć przycisk Wstecz, gdy w systemie nie ma już żadnych aktywnych działań), implementacje urządzenia MUSZĄ traktować tę aplikację priorytetowo w pamięci RAM, tak jak w przypadku innych elementów, które powinny pozostać uruchomione, np. usług na pierwszym planie. Gdy taka aplikacja działa w tle, system może nadal stosować do niej funkcje zarządzania energią, takie jak ograniczenie dostępu do procesora i sieci.
• [C-1-2] MUSI udostępniać interfejs umożliwiający wybranie aplikacji, która nie będzie uczestniczyć w mechanizmie zapisywania i przywracania normalnego stanu po uruchomieniu przez użytkownika drugiej aplikacji zadeklarowanej za pomocą atrybutu cantSaveState.
• [C-1-3] NIE WOLNO wprowadzać innych zmian w zasadach w przypadku aplikacji, które określają cantSaveState, np. zmieniać wydajności procesora lub priorytetu planowania.

Jeśli implementacje urządzeń nie deklarują funkcji FEATURE_CANT_SAVE_STATE, to:

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

4. Zgodność pakowania aplikacji

Implementacje na urządzeniach:

• [C-0-1] MUSI umożliwiać instalowanie i uruchamianie plików „.apk” na Androida wygenerowanych za pomocą narzędzia „aapt” dołączonego do oficjalnego pakietu Android SDK.
• Powyższe wymaganie może być trudne do spełnienia, dlatego zalecamy, aby implementacje urządzeń korzystały z systemu zarządzania pakietami w referencyjnej implementacji AOSP.

Implementacje na urządzeniach:

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

• [C-0-4] NIE MOŻE zezwalać aplikacjom innym niż bieżący „instalator” pakietu na ciche odinstalowywanie aplikacji bez potwierdzenia przez użytkownika, zgodnie z dokumentacją pakietu SDK dotyczącą uprawnienia DELETE_PACKAGE. Wyjątkiem jest tylko aplikacja weryfikująca pakiety systemowe, która obsługuje intencję PACKAGE_NEEDS_VERIFICATION, oraz aplikacja do zarządzania pamięcią, która obsługuje intencję ACTION_MANAGE_STORAGE.

• [C-0-5] MUSI mieć aktywność, która 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 te wymagania:

  • Musi deklarować uprawnienie REQUEST_INSTALL_PACKAGES lub mieć ustawioną wartość android:targetSdkVersion na 24 lub niższą.
  • Użytkownik MUSI zezwolić na instalowanie aplikacji z nieznanych źródeł.

• POWINIEN udostępniać użytkownikowi możliwość przyznawania i cofania uprawnień do instalowania aplikacji z nieznanych źródeł w przypadku poszczególnych aplikacji, ale MOŻE zaimplementować to jako operację bez efektu i zwracać wartość RESULT_CANCELED dla startActivityForResult(), jeśli implementacja urządzenia nie chce zezwalać użytkownikom na taki wybór. Jednak nawet w takich przypadkach POWINNI poinformować użytkownika, dlaczego nie ma takiej opcji.

• [C-0-7] MUSI wyświetlać użytkownikowi okno dialogowe z ostrzeżeniem zawierającym ciąg znaków ostrzegawczych dostarczony przez interfejs API systemu PackageManager.setHarmfulAppWarning przed uruchomieniem aktywności w aplikacji, która została oznaczona przez ten sam interfejs API systemu PackageManager.setHarmfulAppWarning jako potencjalnie szkodliwa.

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

5. Zgodność z multimediami

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać formaty multimediów, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w sekcji 5.1 dla każdego kodeka zadeklarowanego przez MediaCodecList.
• [C-0-2] MUSI deklarować i zgłaszać obsługę koderów i dekoderów dostępnych dla aplikacji innych firm za pomocą interfejsu MediaCodecList.
• [C-0-3] MUSI prawidłowo dekodować i udostępniać aplikacjom innych firm wszystkie formaty, które może kodować. Obejmuje to wszystkie strumienie bitów generowane przez jego kodery i profile zgłaszane w jego CamcorderProfile.

Implementacje na urządzeniach:

• POWINNY dążyć do minimalnego opóźnienia kodeka, czyli
  • NIE POWINNA zużywać i przechowywać buforów wejściowych, a buforów wejściowych powinna zwracać tylko po przetworzeniu.
  • NIE POWINNA przechowywać zdekodowanych buforów dłużej niż jest to określone w standardzie (np. SPS).
  • NIE POWINNO przechowywać zakodowanych buforów dłużej niż jest to wymagane przez strukturę GOP.

Wszystkie kodeki wymienione w sekcji poniżej są udostępniane jako implementacje oprogramowania w preferowanej implementacji Androida z projektu Android Open Source Project.

Ani Google, ani Open Handset Alliance nie gwarantują, że te kodeki nie są objęte patentami osób trzecich. Osoby, które zamierzają używać tego kodu źródłowego w produktach sprzętowych lub programowych, powinny pamiętać, że wdrożenia tego kodu, w tym w oprogramowaniu open source lub shareware, mogą wymagać licencji patentowych od odpowiednich właścicieli patentów.

5.1. Kodeki multimediów

5.1.1. Kodowanie dźwięku

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

Jeśli implementacje urządzeń deklarują android.hardware.microphone, MUSZĄ obsługiwać kodowanie tych formatów audio i udostępniać je aplikacjom innych firm:

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

Wszystkie kodery audio MUSZĄ obsługiwać:

• [C-3-1] Ramki audio PCM 16-bitowe w natywnej kolejności bajtów za pomocą interfejsu android.media.MediaCodec API.

5.1.2. Dekodowanie dźwięku

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

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

• [C-1-1] Profil MPEG-4 AAC (AAC LC)
• [C-1-2] MPEG-4 HE AAC Profile (AAC+)
• [C-1-3] Profil MPEG-4 HE AACv2 (ulepszony AAC+)
• [C-1-4] AAC ELD (ulepszony kodek AAC o niskim opóźnieniu)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, który obejmuje USAC Baseline Profile i ISO/IEC 23003-4 Dynamic Range Control Profile)
• [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 wysokiej rozdzielczości do 24 bitów, częstotliwość próbkowania 192 kHz i 8 kanałów. Pamiętaj, że to wymaganie dotyczy tylko dekodowania, a urządzenie może zmniejszać częstotliwość próbkowania i liczbę kanałów podczas odtwarzania.
• [C-1-10] Opus

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

• [C-2-1] Dekodowanie MUSI odbywać się bez downmixingu (np. strumień AAC 5.0 MUSI być dekodowany do 5 kanałów PCM, a strumień AAC 5.1 MUSI być dekodowany do 6 kanałów PCM).
• [C-2-2] Metadane zakresu dynamicznego MUSZĄ być zgodne z definicją „Dynamic Range Control (DRC)” w normie ISO/IEC 14496-3, a android.media.MediaFormat klucze DRC MUSZĄ konfigurować zachowania dekodera audio związane z zakresem dynamicznym. Klucze AAC DRC zostały wprowadzone w interfejsie API 21 i 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 ZALECA SIĘ, aby wszystkie dekodery audio AAC spełniały wymagania C-2-1 i C-2-2 powyżej.

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

• [C-3-1] Metadane głośności i DRC MUSZĄ być interpretowane i stosowane zgodnie z profilem kontroli zakresu dynamicznego MPEG-D DRC na poziomie 1.
• [C-3-2] Dekoder MUSI działać zgodnie z konfiguracją ustawioną za pomocą tych klawiszy: android.media.MediaFormat, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_DRC_EFFECT_TYPE.

Dekodery profili MPEG-4 AAC, HE AAC i HE AACv2:

• MOŻE obsługiwać głośność i sterowanie zakresem dynamicznym za pomocą profilu sterowania zakresem dynamicznym ISO/IEC 23003-4.

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

• Metadane ISO/IEC 23003-4 mają pierwszeństwo.

Wszystkie dekodery audio MUSZĄ obsługiwać wyjście:

• [C-6-1] Ramki audio PCM 16-bitowe w natywnej kolejności bajtów za pomocą interfejsu android.media.MediaCodec API.

5.1.3. Szczegóły kodeków audio

5.1.4. Kodowanie obrazu

Więcej informacji znajdziesz w sekcji 5.1.6. Szczegóły dotyczące kodeków obrazu

Implementacje urządzeń MUSZĄ obsługiwać kodowanie obrazu w tym formacie:

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

Jeśli implementacje urządzeń obsługują kodowanie HEIC za pomocą android.media.MediaCodec w przypadku typu multimediów MIMETYPE_IMAGE_ANDROID_HEIC:

• [C-1-1] MUSI udostępniać kodek HEVC z akceleracją sprzętową, który obsługuje tryb kontroli 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 sekcji 5.1.6. Szczegóły dotyczące kodeków obrazu

Implementacje urządzeń MUSZĄ obsługiwać dekodowanie tych formatów obrazu:

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Surowy
• [C-0-7] HEIF (HEIC)

dekodery obrazów obsługujące format o wysokiej głębi bitowej (co najmniej 9 bitów na kanał);

• [C-1-1] MUSI obsługiwać generowanie 8-bitowego formatu równoważnego, jeśli zażąda tego aplikacja, np. za pomocą konfiguracji ARGB_8888 w android.graphics.Bitmap.

5.1.6. Szczegóły kodeków obrazu

enkodery i dekodery obrazów udostępniane przez interfejs MediaCodec API;

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

• [SR] ZDECYDOWANIE ZALECANE jest obsługiwanie formatu kolorów RGB888 w trybie Surface wejściowym.

• [C-1-3] MUSI obsługiwać co najmniej jeden z tych formatów kolorów YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (odpowiednik COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (odpowiednik COLOR_FormatYUV420SemiPlanar). ZDECYDOWANIE ZALECA SIĘ obsługę obu tych formatów.

5.1.7. Kodeki wideo

• Aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo w internecie i usług wideokonferencyjnych, urządzenia POWINNY korzystać z kodeka sprzętowego VP8, który spełnia wymagania.

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

• [C-1-1] Kodeki wideo MUSZĄ obsługiwać rozmiary wyjściowych i wejściowych buforów bajtowych, które mieszczą największą możliwą skompresowaną i nieskompresowaną klatkę zgodnie ze standardem i konfiguracją, ale nie mogą być zbyt duże.

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

• [C-1-3] Enkodery i dekodery wideo MUSZĄ obsługiwać co najmniej 1 z tych formatów kolorów: YUV420 8:8:8 w formacie płaskim lub półpłaskim: COLOR_FormatYUV420PackedPlanar (odpowiednik COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (odpowiednik COLOR_FormatYUV420SemiPlanar). ZDECYDOWANIE ZALECA SIĘ obsługę obu tych formatów.

• [SR] Koderom i dekoderom wideo ZDECYDOWANIE ZALECA SIĘ obsługę co najmniej jednego z formatów kolorów YUV420 8:8:8 zoptymalizowanych sprzętowo: planarnego lub półplanarnego (YV12, NV12, NV21 lub równoważnego formatu zoptymalizowanego przez dostawcę).

• [C-1-5] Dekodery wideo obsługujące format o wysokiej głębi bitowej (co najmniej 9 bitów na kanał) MUSZĄ obsługiwać format wyjściowy o równoważnej głębi bitowej 8 bitów, jeśli zażąda tego aplikacja. Musi to być odzwierciedlone przez obsługę formatu kolorów YUV420 8:8:8 za pomocą android.media.MediaCodecInfo.

Jeśli implementacje urządzeń reklamują obsługę profilu HDR za pomocą Display.HdrCapabilities, to:

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

Jeśli implementacje urządzeń reklamują obsługę odświeżania wewnątrzklatkowego za pomocą FEATURE_IntraRefresh w klasie MediaCodecInfo.CodecCapabilities, to:

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

O ile aplikacja nie określi inaczej za pomocą klucza formatu KEY_COLOR_FORMAT, implementacje dekodera wideo:

• [C-4-1] MUSI domyślnie używać formatu kolorów zoptymalizowanego pod kątem wyświetlacza sprzętowego, jeśli jest skonfigurowany przy użyciu wyjścia Surface.
• [C-4-2] Jeśli wyjście powierzchniowe nie jest używane, MUSI domyślnie używać formatu kolorów YUV420 8:8:8 zoptymalizowanego pod kątem odczytu przez procesor.

5.1.8. Lista kodeków wideo

5.1.9. Bezpieczeństwo kodeków multimediów

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń kodeków multimedialnych opisanymi poniżej.

Android obsługuje OMX, wieloplatformowy interfejs API przyspieszający działanie multimediów, a także Codec 2.0, interfejs API przyspieszający działanie multimediów o niskim obciążeniu.

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

• [C-1-1] MUSI obsługiwać kodeki multimedialne za pomocą interfejsów OMX lub Codec 2.0 (lub obu) zgodnie z Android Open Source Project i nie może wyłączać ani omijać zabezpieczeń. Nie oznacza to, że każdy kodek MUSI używać interfejsu API OMX lub Codec 2.0, tylko że musi być dostępna obsługa co najmniej jednego z tych interfejsów API, a obsługa dostępnych interfejsów API musi obejmować zabezpieczenia.
• [C-SR] Zdecydowanie zaleca się obsługę interfejsu Codec 2.0 API.

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

• [C-2-1] MUSI zawierać odpowiedni kodek oprogramowania OMX z projektu Android Open Source Project (jeśli jest dostępny) dla każdego formatu i typu multimediów (enkoder lub dekoder) obsługiwanego przez urządzenie.
• [C-2-2] Kodeki, których nazwy zaczynają się od „OMX.google”. MUSI być oparta na kodzie źródłowym Projektu Android Open Source.
• [C-SR] ZDECYDOWANIE ZALECA się, aby kodeki oprogramowania OMX działały w procesie kodeka, który nie ma dostępu do sterowników sprzętu innych niż mapery pamięci.

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

• [C-3-1] MUSI zawierać odpowiedni kodek oprogramowania Codec 2.0 z Android Open Source Project (jeśli jest dostępny) dla każdego formatu i typu multimediów (enkoder lub dekoder) obsługiwanego przez urządzenie.
• [C-3-2] MUSI zawierać kodeki oprogramowania Codec 2.0 w procesie kodeka oprogramowania zgodnie z projektem Android Open Source, aby umożliwić bardziej precyzyjne przyznawanie dostępu do kodeków oprogramowania.
• [C-3-3] Kodeki, których nazwy zaczynają się od „c2.android.”. MUSI być oparta na kodzie źródłowym Projektu Android Open Source.

5.1.10. Charakterystyka kodeka multimediów

Jeśli implementacje urządzeń obsługują kodeki multimediów:

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

W szczególności:

• [C-1-2] Kodeki, których nazwy zaczynają się od „OMX”. MUSI korzystać z interfejsów API OMX i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa OMX IL.
• [C-1-3] Kodeki, których nazwy zaczynają się od „c2.”. MUSZĄ korzystać z interfejsu Codec 2.0 API i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa Codec 2.0 na Androidzie.
• [C-1-4] Kodeki, których nazwy zaczynają się od „OMX.google.” lub „c2.android.”. NIE MOŻE być określana jako dostawca ani jako akcelerowana sprzętowo.
• [C-1-5] Kodeki działające w procesie kodeka (dostawcy lub systemu), które mają dostęp do sterowników sprzętu innych niż alokatory i mapery pamięci, NIE MOGĄ być określane jako działające wyłącznie w oprogramowaniu.
• [C-1-6] Kodeki, które nie są obecne w projekcie Android Open Source Project lub nie są oparte na kodzie źródłowym w tym projekcie, MUSZĄ być oznaczone jako kodeki dostawcy.
• [C-1-7] Kodeki, które korzystają z akceleracji sprzętowej, MUSZĄ być oznaczone jako akcelerowane sprzętowo.
• [C-1-8] Nazwy kodeków NIE MOGĄ wprowadzać w błąd. Na przykład kodeki o nazwie „dekodery” MUSZĄ obsługiwać dekodowanie, a kodeki o nazwie „enkodery” MUSZĄ obsługiwać kodowanie. Kodeki, których nazwy zawierają formaty multimediów, MUSZĄ obsługiwać te formaty.

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

• [C-2-1] Wszystkie kodeki wideo MUSZĄ publikować dane o osiągalnej liczbie klatek na sekundę w przypadku tych rozmiarów, jeśli są obsługiwane przez kodek:

• [C-2-2] Kodeki wideo, które są określane jako przyspieszane sprzętowo, MUSZĄ publikować informacje o punktach wydajności. Każdy z nich MUSI zawierać listę wszystkich obsługiwanych standardowych punktów wydajności (wymienionych w interfejsie API PerformancePoint), chyba że są one objęte innym obsługiwanym standardowym punktem wydajności.
• Powinny też publikować rozszerzone punkty wydajności, jeśli obsługują utrzymywaną wydajność wideo inną niż jedna ze standardowych wymienionych powyżej.

5.2. Kodowanie wideo

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

• NIE POWINNA przekraczać w przypadku dwóch okien przesuwnych o więcej niż 15% szybkości transmisji bitów między interwałami klatek kluczowych (I-frame).
• NIE POWINNA przekraczać o więcej niż 100% szybkości transmisji w 1-sekundowym oknie przesuwnym.

Jeśli implementacje urządzeń obejmują wbudowany wyświetlacz o przekątnej co najmniej 2,5 cala lub port wyjścia wideo albo deklarują obsługę aparatu za pomocą flagi funkcji android.hardware.camera.any, muszą:

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

Jeśli implementacje urządzeń obsługują dowolny z enkoderów wideo H.264, VP8, VP9 lub HEVC i udostępniają go aplikacjom innych firm:

• [C-2-1] MUSI obsługiwać dynamicznie konfigurowane szybkości transmisji.
• POWINIEN obsługiwać zmienną liczbę klatek na sekundę, w przypadku której koder wideo POWINIEN określać chwilowy czas trwania klatki na podstawie sygnatur czasowych buforów wejściowych i przydzielać zasobnik bitów na podstawie czasu trwania klatki.

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

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

Jeśli implementacje urządzeń udostępniają akcelerowane sprzętowo kodery wideo lub obrazów i obsługują co najmniej 1 podłączoną lub wtykaną kamerę sprzętową udostępnianą przez interfejsy API android.camera:

• [C-4-1] wszystkie akcelerowane sprzętowo kodery wideo i obrazów MUSZĄ obsługiwać kodowanie klatek z kamer sprzętowych.
• POWINIEN obsługiwać kodowanie klatek z kamer sprzętowych za pomocą wszystkich koderów wideo lub obrazów.

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 na poziomie 45.
• POWINIEN obsługiwać dynamicznie konfigurowane szybkości transmisji bitów w przypadku 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 na poziomie 3. Obsługa ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) i RS (Redundant Slices) jest jednak OPCJONALNA. Ponadto, aby zachować zgodność z innymi urządzeniami z Androidem, ZALECAMY, aby koderzy nie używali ASO, FMO i RS w przypadku profilu podstawowego.
• [C-1-2] MUSI obsługiwać profile kodowania wideo SD (Standard Definition) w tabeli poniżej.
• POWINIEN obsługiwać profil główny na poziomie 4.
• POWINIEN obsługiwać profile kodowania wideo HD (High Definition) zgodnie z tabelą poniżej.

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

• [C-2-1] MUSI obsługiwać profile kodowania w tabeli poniżej.

5.2.3. VP8

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

• [C-1-1] MUSI obsługiwać profile kodowania wideo SD.
• POWINNY obsługiwać te profile kodowania wideo w wysokiej rozdzielczości (HD):
• [C-1-2] MUSI obsługiwać zapisywanie plików Matroska WebM.
• POWINIEN udostępniać sprzętowy kodek VP8, który spełnia wymagania projektu WebM dotyczące sprzętowego kodowania RTC, aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo w internecie i usług wideokonferencyjnych.

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

• [C-2-1] MUSI obsługiwać profile kodowania w tabeli poniżej.

5.2.4. VP9

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

• [C-1-2] MUSI obsługiwać profil 0 poziom 3.
• [C-1-1] MUSI obsługiwać zapisywanie plików Matroska WebM.
• [C-1-3] MUSI generować dane CodecPrivate.
• POWINIEN obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• [SR] są ZDECYDOWANIE ZALECANE do obsługi profili dekodowania HD zgodnie z tabelą poniżej, jeśli występuje koder sprzętowy.

Jeśli implementacje urządzeń deklarują obsługę profilu 2 lub profilu 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.
• POWINIEN obsługiwać profile kodowania HD zgodnie z tabelą poniżej.
• [SR] Zdecydowanie zaleca się obsługę profili kodowania HD wskazanych w tabeli poniżej, jeśli dostępny jest koder sprzętowy.

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 i liczby klatek na sekundę w ramach tego samego strumienia za pomocą standardowych interfejsów API Androida w przypadku wszystkich kodeków VP8, VP9, H.264 i H.265 w czasie rzeczywistym i do maksymalnej rozdzielczości obsługiwanej 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ć profil główny na wysokim poziomie.

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

Jeśli urządzenia mają dekodery MPEG-4:

• [C-1-1] MUSI obsługiwać Simple Profile Level 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 (Flexible Macroblock Ordering) i RS (Redundant Slices) jest OPCJONALNA.
• [C-1-2] MUSI być w stanie dekodować filmy w profilach SD (Standard Definition) wymienionych w tabeli poniżej i zakodowanych w profilu Baseline i Main Level 3.1 (w tym 720p30).
• POWINNO umożliwiać dekodowanie filmów w profilach HD (High Definition) zgodnie z tabelą poniżej.

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

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

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 na poziomie 3 i profil dekodowania wideo SD zgodnie z tabelą poniżej.
• POWINIEN obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• [C-1-2] MUSI obsługiwać profile dekodowania HD wskazane w tabeli poniżej, jeśli jest dostępny dekoder sprzętowy.

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

• [C-2-1] Urządzenia MUSZĄ obsługiwać dekodowanie co najmniej jednego z formatów H.265 lub VP9 w profilach 720, 1080 i UHD.

Jeśli implementacje urządzeń deklarują obsługę profilu HDR (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) za pomocą interfejsów Media API:

• [C-3-1] Urządzenia MUSZĄ akceptować wymagane metadane HDR (MediaFormat#KEY_HDR_STATIC_INFO dla wszystkich profili HDR) z aplikacji korzystającej z interfejsu MediaCodec API, a także obsługiwać wyodrębnianie wymaganych metadanych HDR (MediaFormat#KEY_HDR_STATIC_INFO dla wszystkich profili HDR oraz MediaFormat#KEY_HDR10_PLUS_INFO dla profili HDR10Plus) ze strumienia bitów lub kontenera zgodnie z odpowiednimi specyfikacjami. Muszą one też obsługiwać wyprowadzanie wymaganych metadanych HDR (MediaFormat#KEY_HDR_STATIC_INFO w przypadku wszystkich profili HDR) ze strumienia bitów lub kontenera zgodnie z odpowiednimi specyfikacjami.

• [C-SR] Zdecydowanie zaleca się, aby implementacje urządzeń obsługiwały wyjściowe metadane MediaFormat#KEY_HDR10_PLUS_INFO dla profili HDR10Plus za pomocą MediaCodec#getOutputFormat(int)..

• [C-3-2] Urządzenia MUSZĄ prawidłowo wyświetlać treści HDR w profilu HEVCProfileMain10HDR10 na ekranie urządzenia lub na standardowym porcie wyjściowym wideo (np. HDMI).

• [C-SR] Zdecydowanie zaleca się, aby urządzenia prawidłowo wyświetlały treści HDR w HEVCProfileMain10HDR10Plus na ekranie urządzenia lub na standardowym porcie wyjścia 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 w tabeli poniżej.
• POWINIEN używać sprzętowego kodeka VP8, który spełnia wymagania.
• POWINNO obsługiwać profile dekodowania HD w tabeli poniżej.

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

• [C-2-1] Urządzenia MUSZĄ obsługiwać profile 720p z tabeli poniżej.
• [C-2-2] Urządzenia MUSZĄ obsługiwać profile 1080p z tabeli poniżej.

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 tabelą poniżej.
• POWINIEN obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.

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

• [C-2-1] MUSI obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.

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

• [C-3-1] Urządzenia MUSZĄ obsługiwać dekodowanie co najmniej jednego z formatów VP9 lub H.265 w przypadku profili 720, 1080 i UHD.

Jeśli implementacje urządzeń deklarują obsługę VP9Profile2 lub VP9Profile3 za pomocą interfejsów API multimediów „CodecProfileLevel”:

• Obsługa formatu 12-bitowego jest OPCJONALNA.

Jeśli implementacje urządzeń deklarują obsługę profilu HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) za pomocą interfejsów API multimediów:

• [C-4-1] Urządzenia MUSZĄ akceptować wymagane metadane HDR (MediaFormat#KEY_HDR_STATIC_INFO dla wszystkich profili HDR oraz parametr MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO dla profili HDR10Plus) z aplikacji za pomocą interfejsu MediaCodec API, a także obsługiwać wyodrębnianie wymaganych metadanych HDR (MediaFormat#KEY_HDR_STATIC_INFO dla wszystkich profili HDR oraz MediaFormat#KEY_HDR10_PLUS_INFO dla profili HDR10Plus) ze strumienia bitów lub kontenera zgodnie z odpowiednimi specyfikacjami. Muszą one również obsługiwać wyprowadzanie wymaganych metadanych HDR (MediaFormat#KEY_HDR_STATIC_INFO dla wszystkich profili HDR) ze strumienia bitów lub kontenera zgodnie z odpowiednimi specyfikacjami.

• [C-4-2] Urządzenia MUSZĄ prawidłowo wyświetlać treści HDR w profilach VP9Profile2HDR i VP9Profile3HDR na ekranie urządzenia lub na standardowym porcie wyjściowym wideo (np. HDMI).

• [C-SR] Zdecydowanie zaleca się, aby implementacje urządzeń obsługiwały wyjściowe metadane MediaFormat#KEY_HDR10_PLUS_INFO dla profili HDR10Plus za pomocą MediaCodec#getOutputFormat(int).

• [C-SR] Zdecydowanie zaleca się, aby urządzenia prawidłowo wyświetlały treści HDR w przypadku profili VP9Profile2HDR10Plus i VP9Profile3HDR10Plus na ekranie urządzenia lub na standardowym porcie wyjścia wideo (np. HDMI).

5.3.8. Dolby Vision

Jeśli implementacje urządzeń deklarują obsługę dekodera Dolby Vision za pomocą HDR_TYPE_DOLBY_VISION , to:

• [C-1-1] MUSI udostępniać ekstraktor obsługujący Dolby Vision.
• [C-1-2] MUSI prawidłowo wyświetlać treści w Dolby Vision na ekranie urządzenia lub na standardowym porcie wyjściowym wideo (np. HDMI).
• [C-1-3] MUSI ustawić indeks ścieżki warstw podstawowych zgodnych wstecznie (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

Niektóre wymagania wymienione w tej sekcji są oznaczone jako SHOULD od Androida 4.3, ale w przyszłych wersjach definicji zgodności planujemy zmienić je na MUST. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z Androidem spełniały te wymagania, które są oznaczone jako „SHOULD”. W przeciwnym razie po uaktualnieniu do przyszłej wersji nie będą one zgodne z Androidem.

5.4.1. Przechwytywanie surowego dźwięku i informacje o mikrofonie

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

• [C-1-1] MUSI umożliwiać rejestrowanie surowych treści audio o tych cechach:

  • Format: Linear PCM, 16-bit
  • Częstotliwości próbkowania: 8000, 11025, 16000, 44100, 48000 Hz
  • Kanały: mono

• POWINNO umożliwiać rejestrowanie surowych treści audio o tych cechach:

  • Format: Linear PCM, 16-bitowy i 24-bitowy
  • Częstotliwości próbkowania: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
  • Kanały: tyle kanałów, ile mikrofonów ma urządzenie.

• [C-1-2] MUSI rejestrować dźwięk z częstotliwością próbkowania powyżej podanej, bez upsamplingu.

• [C-1-3] MUSI zawierać odpowiedni filtr wygładzający, gdy podane powyżej częstotliwości próbkowania są rejestrowane z użyciem downsamplingu.

• POWINNY umożliwiać nagrywanie surowych treści audio w jakości radia AM i DVD, co oznacza, że powinny mieć te cechy:

  • Format: Linear PCM, 16-bit
  • Częstotliwości próbkowania: 22050, 48000 Hz
  • Kanały: stereo

• [C-1-4] MUSI obsługiwać interfejs MicrophoneInfo API i prawidłowo wypełniać informacje o dostępnych mikrofonach na urządzeniu, do których aplikacje innych firm mają dostęp za pomocą interfejsu AudioManager.getMicrophones() API, oraz o aktualnie aktywnych mikrofonach, do których aplikacje innych firm mają dostęp za pomocą interfejsów AudioRecord.getActiveMicrophones() i MediaRecorder.getActiveMicrophones() API. Jeśli implementacje urządzeń umożliwiają odbiór radia AM i nagrywanie surowych treści audio w jakości DVD:

• [C-2-1] MUSI rejestrować bez upsamplingu przy dowolnym współczynniku wyższym niż 16000:22050 lub 44100:48000.

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

5.4.2. Nagrywanie na potrzeby rozpoznawania głosu

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

• [C-1-1] MUSI przechwytywać źródło dźwięku android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION z jedną z tych częstotliwości próbkowania: 44 100 i 48 000.
• [C-1-2] MUSI domyślnie wyłączać przetwarzanie dźwięku w celu redukcji szumów podczas nagrywania strumienia audio ze źródła dźwięku AudioSource.VOICE_RECOGNITION.
• [C-1-3] MUSI domyślnie wyłączać automatyczną regulację wzmocnienia podczas nagrywania strumienia audio ze źródła dźwięku AudioSource.VOICE_RECOGNITION.
• POWINNO nagrywać strumień audio rozpoznawania głosu z charakterystyką amplitudy w przybliżeniu płaską w funkcji częstotliwości, a konkretnie ±3 dB w zakresie od 100 Hz do 4000 Hz.
• POWINIEN nagrywać strumień audio rozpoznawania głosu z czułością wejściową ustawioną tak, aby źródło o poziomie mocy dźwięku 90 dB (SPL) przy częstotliwości 1000 Hz dawało wartość RMS równą 2500 dla 16-bitowych próbek.
• POWINNO nagrywać strumień audio rozpoznawania głosu w taki sposób, aby poziomy amplitudy PCM liniowo śledziły zmiany SPL wejściowego w zakresie co najmniej 30 dB od -18 dB do +12 dB w odniesieniu do 90 dB SPL przy mikrofonie.
• POWINNO nagrywać strumień audio rozpoznawania głosu z całkowitymi zniekształceniami harmonicznymi (THD) mniejszymi niż 1% dla 1 kHz przy poziomie wejściowym 90 dB SPL w mikrofonie.

Jeśli implementacje urządzeń deklarują android.hardware.microphone i technologie tłumienia (redukcji) szumów dostosowane do rozpoznawania mowy:

• [C-2-1] MUSI umożliwiać sterowanie tym efektem dźwiękowym za pomocą interfejsu android.media.audiofx.NoiseSuppressor API.
• [C-2-2] MUSI jednoznacznie identyfikować każdą implementację technologii tłumienia szumów za pomocą pola AudioEffect.Descriptor.uuid.

5.4.3. Przechwytywanie na potrzeby przekierowania odtwarzania

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

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

• [C-1-1] MUSI prawidłowo wdrożyć REMOTE_SUBMIX źródło dźwięku, aby w przypadku, gdy aplikacja używa interfejsu android.media.AudioRecord API do nagrywania z tego źródła dźwięku, rejestrowała miks wszystkich strumieni audio z wyjątkiem tych:

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

5.4.4. Usuwanie echa akustycznego

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

• POWINNO implementować technologię usuwania echa akustycznego (AEC) dostosowaną do komunikacji głosowej i stosowaną na ścieżce przechwytywania podczas nagrywania za pomocą AudioSource.VOICE_COMMUNICATION.

Jeśli implementacja urządzenia udostępnia funkcję Acoustic Echo Canceler, która jest wstawiana na ścieżkę przechwytywania dźwięku po wybraniu opcji AudioSource.VOICE_COMMUNICATION, to:

• [C-SR] Zdecydowanie zalecamy deklarowanie tej funkcji za pomocą metody interfejsu API AcousticEchoCanceler AcousticEchoCanceler.isAvailable().
• [C-SR] Zdecydowanie zalecamy, aby ten efekt dźwiękowy można było kontrolować za pomocą interfejsu AcousticEchoCanceler.
• [C-SR] Zdecydowanie zalecamy jednoznaczne identyfikowanie każdej implementacji technologii AEC za pomocą pola AudioEffect.Descriptor.uuid.

5.4.5. Równoczesne rejestrowanie

Jeśli implementacje urządzeń deklarują android.hardware.microphone,MUSZĄ implementować równoczesne przechwytywanie zgodnie z opisem w tym dokumencie . Więcej szczegółów:

• [C-1-1] MUSI zezwalać na jednoczesny dostęp do mikrofonu przez usługę ułatwień dostępu rejestrującą dźwięk za pomocą AudioSource.VOICE_RECOGNITION i co najmniej 1 aplikację rejestrującą dźwięk za pomocą dowolnego AudioSource.
• [C-1-2] MUSI zezwalać na jednoczesny dostęp do mikrofonu preinstalowanej aplikacji, która pełni rolę Asystenta, oraz co najmniej 1 aplikacji rejestrującej dźwięk za pomocą dowolnego interfejsu API AudioSource z wyjątkiem AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER.
• [C-1-3] MUSI wyciszać przechwytywanie dźwięku w przypadku wszystkich innych aplikacji, z wyjątkiem usług ułatwień dostępu, gdy aplikacja przechwytuje dźwięk za pomocą funkcji AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER. Jeśli jednak aplikacja nagrywa dźwięk za pomocą AudioSource.VOICE_COMMUNICATION, inna aplikacja może nagrywać rozmowę głosową, jeśli jest to aplikacja uprzywilejowana (zainstalowana fabrycznie) z uprawnieniem CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Jeśli 2 lub więcej aplikacji rejestruje dźwięk jednocześnie i żadna z nich nie ma interfejsu na wierzchu, dźwięk otrzymuje ta, która rozpoczęła rejestrowanie jako ostatnia.

5.4.6. Poziomy wzmocnienia mikrofonu

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

• POWINNY wykazywać w zakresie średnich częstotliwości w przybliżeniu płaską charakterystykę amplitudy w funkcji częstotliwości, a konkretnie ±3 dB w zakresie od 100 Hz do 4000 Hz w przypadku każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania mowy.
• POWINIEN ustawić czułość wejścia audio tak, aby źródło dźwięku w postaci sygnału sinusoidalnego o częstotliwości 1000 Hz odtwarzanego na poziomie ciśnienia akustycznego 90 dB (SPL) dawało odpowiedź o wartości RMS 2500 dla 16-bitowych próbek (lub –22,35 dB w pełnej skali dla próbek zmiennoprzecinkowych lub o podwójnej precyzji) dla każdego mikrofonu używanego do nagrywania źródła dźwięku rozpoznawania głosu.
• [C-SR] ZDECYDOWANIE ZALECA się, aby wykazywały poziomy amplitudy w zakresie niskich częstotliwości, a konkretnie od ±20 dB od 5 Hz do 100 Hz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu używanego do nagrywania źródła dźwięku rozpoznawania głosu.
• [C-SR] ZDECYDOWANIE ZALECA się, aby wykazywały poziomy amplitudy w zakresie wysokich częstotliwości: w szczególności od ±30 dB od 4000 Hz do 22 kHz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu używanego do nagrywania źródła dźwięku rozpoznawania głosu.

5.5. Odtwarzanie dźwięku

Android obsługuje odtwarzanie dźwięku przez aplikacje za pomocą urządzenia wyjściowego audio zgodnie z sekcją 7.8.2.

5.5.1. Odtwarzanie surowego dźwięku

Jeśli implementacje urządzeń deklarują android.hardware.audio.output, to:

• [C-1-1] MUSI umożliwiać odtwarzanie surowych treści audio o tych cechach:

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

• POWINNO umożliwiać odtwarzanie surowych treści audio o tych cechach:

  • Częstotliwości próbkowania: 24000

5.5.2. Efekty audio

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

Jeśli implementacje urządzenia deklarują funkcję android.hardware.audio.output, to:

• [C-1-1] MUSI obsługiwać implementacje EFFECT_TYPE_EQUALIZER i EFFECT_TYPE_LOUDNESS_ENHANCER, którymi można sterować za pomocą podklas AudioEffect Equalizer i LoudnessEnhancer.
• [C-1-2] MUSI obsługiwać implementację interfejsu API wizualizatora, którą można sterować za pomocą klasy Visualizer.
• [C-1-3] MUSI obsługiwać implementację EFFECT_TYPE_DYNAMICS_PROCESSING, którą można kontrolować za pomocą podklasy AudioEffect DynamicsProcessing.
• POWINIEN obsługiwać implementacje EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB i EFFECT_TYPE_VIRTUALIZER, którymi można sterować za pomocą podklas AudioEffect: BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.
• [C-SR] Zdecydowanie zaleca się obsługę efektów w przypadku liczb zmiennoprzecinkowych i wielokanałowych.

5.5.3. Głośność wyjścia audio

Implementacje na urządzeniach samochodowych:

• POWINIEN umożliwiać dostosowywanie głośności dźwięku osobno dla każdego strumienia audio na podstawie typu treści lub użycia zdefiniowanego przez AudioAttributes oraz użycia dźwięku w samochodzie zdefiniowanego publicznie w android.car.CarAudioManager.

5.6. Opóźnienie dźwięku

Opóźnienie dźwięku to czas, jaki upływa od momentu, w którym sygnał audio przechodzi przez system. Wiele klas aplikacji wymaga krótkich opóźnień, aby uzyskać efekty dźwiękowe w czasie rzeczywistym.

Na potrzeby tej sekcji używaj tych definicji:

• opóźnienie wyjściowe. Odstęp czasu między momentem, w którym aplikacja zapisuje ramkę danych zakodowanych w formacie PCM, a momentem, w którym odpowiedni dźwięk jest odtwarzany w otoczeniu przez przetwornik na urządzeniu lub sygnał opuszcza urządzenie przez port i może być obserwowany z zewnątrz.
• opóźnienie wyjścia w przypadku zimnego startu; Opóźnienie wyjścia pierwszej klatki, gdy system wyjścia audio był bezczynny i wyłączony przed żądaniem.
• ciągłe opóźnienie wyjściowe. Opóźnienie wyjściowe w przypadku kolejnych klatek po rozpoczęciu odtwarzania dźwięku przez urządzenie.
• opóźnienie reakcji. Odstęp czasu między momentem, w którym dźwięk jest prezentowany przez środowisko na urządzeniu za pomocą przetwornika lub sygnał dociera do urządzenia przez port, a momentem, w którym aplikacja odczytuje odpowiednią ramkę danych zakodowanych w formacie PCM.
• utracone dane wejściowe. Początkowa część sygnału wejściowego, która jest bezużyteczna lub niedostępna.
• opóźnienie przy zimnym starcie. Suma utraconego czasu wprowadzania i opóźnienia wprowadzania w przypadku pierwszej klatki, gdy system wejścia audio był nieaktywny i wyłączony przed żądaniem.
• ciągłe opóźnienie wejścia. Opóźnienie wejściowe w przypadku kolejnych klatek podczas rejestrowania dźwięku przez urządzenie.
• zimny jitter wyjściowy. Zmienność poszczególnych pomiarów wartości opóźnienia wyjścia na zimno.
• drgania zimnego wejścia. Zmienność poszczególnych pomiarów wartości opóźnienia wejścia „na zimno”.
• ciągłe opóźnienie w obie strony. Suma opóźnienia ciągłego wejścia, opóźnienia ciągłego wyjścia i jednego okresu buforowania. Okres buforowania umożliwia aplikacji przetworzenie sygnału i zmniejszenie różnicy faz między strumieniami wejściowym i wyjściowym.
• OpenSL ES PCM buffer queue API Zestaw interfejsów API OpenSL ES związanych z PCM w ramach Android NDK.
• AAudio native audio API. Zestaw interfejsów API AAudio w ramach Android NDK.
• timestamp. Para składająca się z względnej pozycji klatki w strumieniu i szacowanego czasu, w którym ta klatka wchodzi do potoku przetwarzania dźwięku na powiązanym punkcie końcowym lub z niego wychodzi. Zobacz też AudioTimestamp.
• glitch. Chwilowe przerwanie lub nieprawidłowa wartość próbki w sygnale audio, zwykle spowodowane niedoborem bufora w przypadku wyjścia, przepełnieniem bufora w przypadku wejścia lub innym źródłem szumu cyfrowego lub analogowego.

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

• [C-1-1] Sygnatura czasowa zwracana przez funkcje AudioTrack.getTimestamp i AAudioStream_getTimestamp ma dokładność +/- 2 ms.
• [C-1-2] Opóźnienie wyjścia w przypadku zimnego startu nie przekracza 500 milisekund.

Jeśli implementacje urządzeń deklarują android.hardware.audio.output, ZDECYDOWANIE ZALECA SIĘ, aby spełniały lub przekraczały te wymagania:

• [C-SR] Opóźnienie wyjścia w przypadku zimnego startu nie przekracza 100 milisekund. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z tą wersją Androida spełniały te wymagania już teraz. W przyszłej wersji platformy w 2021 r. będziemy wymagać, aby opóźnienie wyjścia w trybie zimnym wynosiło maksymalnie 200 ms.
• [C-SR] Ciągłe opóźnienie wyjściowe nie większe niż 45 milisekund.
• [C-SR] Zminimalizuj drgania wyjścia w stanie zimnym.
• [C-SR] Sygnatura czasowa zwracana przez AudioTrack.getTimestamp i AAudioStream_getTimestamp ma dokładność +/- 1 ms.

Jeśli implementacje urządzeń spełniają powyższe wymagania, po wstępnej kalibracji, podczas korzystania z kolejki buforów PCM OpenSL ES i natywnych interfejsów API audio AAudio, w przypadku ciągłego i początkowego opóźnienia wyjściowego na co najmniej jednym obsługiwanym urządzeniu wyjściowym audio:

• [C-SR] Zdecydowanie zalecamy zgłaszanie dźwięku o małym opóźnieniu przez zadeklarowanie flagi funkcji android.hardware.audio.low_latency.
• [C-SR] ZDECYDOWANIE ZALECANE, aby spełniać wymagania dotyczące dźwięku o niskim opóźnieniu za pomocą interfejsu AAudio API.
• [C-SR] Zdecydowanie zalecamy, aby w przypadku strumieni, które zwracają AAUDIO_PERFORMANCE_MODE_LOW_LATENCY z AAudioStream_getPerformanceMode(), wartość zwracana przez AAudioStream_getFramesPerBurst() była mniejsza lub równa wartości zwracanej przez android.media.AudioManager.getProperty(String) w przypadku klucza właściwości AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Jeśli implementacje urządzeń nie spełniają wymagań dotyczących dźwięku o niskim opóźnieniu za pomocą kolejki buforów PCM OpenSL ES i natywnych interfejsów API dźwięku AAudio:

• [C-2-1] NIE MOŻE zgłaszać obsługi dźwięku o niskiej latencji.

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

• [C-3-1] Ogranicz błąd sygnatur czasowych danych wejściowych zwracanych przez funkcję AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/- 2 ms. „Błąd” oznacza tu odchylenie od prawidłowej wartości.
• [C-3-2] Opóźnienie wejścia „na zimno” nie przekracza 500 milisekund.

Jeśli implementacje urządzeń obejmują android.hardware.microphone, ZDECYDOWANIE ZALECA SIĘ, aby spełniały te wymagania dotyczące dźwięku wejściowego:

• [C-SR] Opóźnienie wejścia „na zimno” nie przekracza 100 milisekund. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z tą wersją Androida spełniały te wymagania już teraz. W przyszłej wersji platformy w 2021 r. będziemy wymagać, aby opóźnienie przy zimnym starcie wynosiło maksymalnie 200 ms.
• [C-SR] Ciągłe opóźnienie wejściowe nie przekracza 30 milisekund.
• [C-SR] Ciągłe opóźnienie w obie strony nie przekracza 50 milisekund.
• [C-SR] Zminimalizuj drgania wejścia „na zimno”.
• [C-SR] Ogranicz błąd w sygnaturach czasowych danych wejściowych 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 multimedialnych do odtwarzania dźwięku i wideo zgodnie z dokumentacją pakietu Android SDK.

Jeśli implementacje urządzeń zawierają dekoder audio lub wideo:

• [C-1-1] MUSI obsługiwać wszystkie wymagane kodeki i formaty kontenerów wymienione w sekcji 5.1 w protokole HTTP(S).

• [C-1-2] MUSI obsługiwać formaty segmentów multimedialnych podane w tabeli Formaty segmentów multimedialnych poniżej w ramach wersji 7 roboczego protokołu transmisji na żywo przez HTTP.

• [C-1-3] MUSI obsługiwać ten profil audio i wideo RTP oraz powiązane kodeki w tabeli RTSP poniżej. Wyjątki znajdziesz w przypisach do tabeli w sekcji 5.1.

Formaty segmentów multimedialnych

RTSP (RTP, SDP)

5.8. Secure Media

Jeśli implementacje urządzeń obsługują bezpieczne wyjście wideo i bezpieczne powierzchnie, to:

• [C-1-1] MUSI deklarować obsługę Display.FLAG_SECURE.

Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE i obsługują protokół wyświetlania bezprzewodowego:

• [C-2-1] MUSI zabezpieczać połączenie za pomocą silnego mechanizmu kryptograficznego, takiego jak HDCP 2.x lub nowszy, w przypadku wyświetlaczy podłączonych za pomocą protokołów bezprzewodowych, takich jak Miracast.

Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE i obsługują przewodowy wyświetlacz zewnętrzny:

• [C-3-1] MUSI obsługiwać HDCP w wersji 1.2 lub nowszej w przypadku wszystkich wyświetlaczy zewnętrznych podłączonych przez dostępny dla użytkownika port przewodowy.

5.9. Cyfrowy interfejs do instrumentów muzycznych (MIDI)

Jeśli implementacje urządzeń zgłaszają obsługę funkcji android.software.midi za pomocą klasy android.content.pm.PackageManager:

• [C-1-1] MUSI obsługiwać MIDI we wszystkich transportach sprzętowych obsługujących MIDI, w przypadku których zapewnia ogólną łączność nieobsługującą MIDI, jeśli są to:

  • Tryb hosta USB, sekcja 7.7
  • Tryb urządzenia peryferyjnego USB, sekcja 7.7
  • MIDI over Bluetooth LE w roli centralnej, sekcja 7.4.3

• [C-1-2] MUSI obsługiwać transport oprogramowania MIDI między aplikacjami (wirtualne urządzenia MIDI)

• [C-1-3] MUSI zawierać bibliotekę libamidi.so (natywna obsługa MIDI)

5.10. Profesjonalny dźwięk

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łaszać obsługę funkcji android.hardware.audio.low_latency.
• [C-1-2] MUSI mieć ciągłe opóźnienie dźwięku w obie strony, zdefiniowane w sekcji 5.6 Opóźnienie dźwięku, wynoszące 20 milisekund lub mniej i POWINNO wynosić 10 milisekund lub mniej na co najmniej 1 obsługiwanej ścieżce.
• [C-1-3] MUSI zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
• [C-1-4] MUSI zgłaszać obsługę funkcji android.software.midi.
• [C-1-5] MUSI spełniać wymagania dotyczące opóźnień i dźwięku USB przy użyciu interfejsu OpenSL ES PCM buffer queue API i co najmniej jednej ścieżki interfejsu AAudio native audio API.
• [SR] Zdecydowanie zalecamy spełnianie wymagań dotyczących opóźnień i dźwięku USB za pomocą interfejsu AAudio native audio zamiast ścieżki MMAP.
• [C-1-6] MUSI mieć opóźnienie wyjścia w trybie zimnym nie większe niż 200 milisekund.
• [C-1-7] MUSI mieć opóźnienie wejścia w trybie zimnym wynoszące 200 milisekund lub mniej.
• [SR] Zdecydowanie zalecane, aby zapewnić stały poziom wydajności procesora podczas aktywności dźwięku i zmiennego obciążenia procesora. Należy to przetestować za pomocą wersji aplikacji na Androida SynthMark o identyfikatorze zatwierdzenia 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark korzysta z syntezatora programowego działającego w symulowanym środowisku audio, które mierzy wydajność systemu. Aplikację SynthMark należy uruchomić za pomocą opcji „Automated Test” (Test automatyczny) i uzyskać te wyniki:
  • voicemark.90 >= 32 głosy
  • latencymark.fixed.little <= 15 ms
  • latencymark.dynamic.little <= 50 ms

Wyjaśnienie testów porównawczych znajdziesz w dokumentacji SynthMark.

• POWINNO minimalizować niedokładność zegara audio i odchylenie od czasu standardowego.
• POWINNO minimalizować odchylenie zegara audio względem zegara procesora CLOCK_MONOTONIC, gdy oba są aktywne.
• POWINNO minimalizować opóźnienie dźwięku w przypadku przetworników na urządzeniu.
• POWINNO minimalizować opóźnienie dźwięku w przypadku cyfrowego dźwięku USB.
• POWINNY dokumentować pomiary opóźnienia dźwięku na wszystkich ścieżkach.
• POWINIEN minimalizować wahania czasu wejścia wywołania zwrotnego zakończenia bufora audio, ponieważ wpływa to na procent wykorzystania pełnej przepustowości procesora przez wywołanie zwrotne.
• POWINNO zapewniać brak zakłóceń dźwięku przy normalnym użytkowaniu przy zgłoszonym opóźnieniu.
• POWINNO zapewniać zerową różnicę opóźnienia między kanałami.
• POWINIEN minimalizować średni czas oczekiwania MIDI we wszystkich transportach.
• POWINIEN minimalizować zmienność opóźnienia MIDI pod obciążeniem (jitter) we wszystkich transportach.
• POWINIEN zapewniać dokładne sygnatury czasowe MIDI we wszystkich protokołach.
• POWINNO minimalizować szum sygnału audio na przetwornikach na urządzeniu, w tym w okresie bezpośrednio po uruchomieniu „na zimno”.
• POWINIEN zapewniać zerową różnicę zegara audio między wejściem a wyjściem odpowiednich punktów końcowych, gdy oba są aktywne. Przykłady odpowiednich punktów końcowych to mikrofon i głośnik na urządzeniu lub wejście i wyjście gniazda audio.
• POWINIEN obsługiwać wywołania zwrotne dotyczące zakończenia buforowania dźwięku po stronie wejściowej i wyjściowej odpowiednich punktów końcowych w tym samym wątku, gdy oba są aktywne, i przechodzić do wywołania zwrotnego po stronie wyjściowej natychmiast po powrocie z wywołania zwrotnego po stronie wejściowej. Jeśli obsługa wywołań zwrotnych w tym samym wątku nie jest możliwa, wprowadź wywołanie zwrotne danych wyjściowych krótko po wprowadzeniu wywołania zwrotnego danych wejściowych, aby zapewnić aplikacji spójne taktowanie po stronie danych wejściowych i wyjściowych.
• POWINIEN minimalizować różnicę faz między buforowaniem dźwięku HAL po stronie wejściowej i wyjściowej odpowiednich punktów końcowych.
• POWINNO minimalizować opóźnienie dotyku.
• POWINIEN minimalizować zmienność czasu oczekiwania na dotyk pod obciążeniem (jitter).
• POWINNO mieć opóźnienie od dotknięcia do wyjścia audio nie większe niż 40 ms.

Jeśli implementacje urządzeń spełniają wszystkie powyższe wymagania:

• [SR] Zdecydowanie zalecamy zgłaszanie obsługi funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager.

Jeśli urządzenia mają 4-żyłowe gniazdo słuchawek 3, 5 mm:

• [C-2-1] MUSI mieć ciągłe opóźnienie dźwięku w obie strony wynoszące maksymalnie 20 milisekund w przypadku ścieżki gniazda audio.
• [SR] ZDECYDOWANIE ZALECANE, aby spełniać wymagania sekcji Specyfikacje urządzenia mobilnego (gniazdo) w specyfikacji przewodowego zestawu słuchawkowego (wersja 1.1).
• Ciągłe opóźnienie dźwięku w obie strony POWINNO wynosić 10 milisekund lub mniej w przypadku ścieżki gniazda audio.

Jeśli urządzenia nie mają 4-żyłowego gniazda słuchawek 3,5 mm, ale mają porty USB obsługujące tryb hosta USB:

• [C-3-1] MUSI implementować klasę audio USB.
• [C-3-2] MUSI mieć ciągłe opóźnienie dźwięku w obie strony wynoszące 20 milisekund lub mniej w porcie trybu hosta USB przy użyciu klasy audio USB.
• Ciągłe opóźnienie dźwięku w obie strony POWINNO wynosić 10 milisekund lub mniej w przypadku portu hosta USB w trybie USB audio class.
• [C-SR] Zdecydowanie zaleca się obsługę jednoczesnego wejścia/wyjścia 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 korzystania z urządzeń peryferyjnych audio USB, które również obsługują te wymagania.

Jeśli urządzenie ma port HDMI:

• POWINNO obsługiwać wyjście stereo i 8 kanałów o głębi bitowej 20 lub 24 bitów i częstotliwości próbkowania 192 kHz bez utraty głębi bitowej lub ponownego próbkowania w co najmniej 1 konfiguracji.

5.11. Przechwytywanie dla nieprzetworzonych

Android obsługuje nagrywanie nieprzetworzonego dźwięku za pomocą źródła dźwięku android.media.MediaRecorder.AudioSource.UNPROCESSED. W OpenSL ES można uzyskać do niego dostęp za pomocą ustawienia wstępnego nagrywania SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Jeśli implementacje urządzeń mają obsługiwać nieprzetworzone źródło dźwięku i udostępniać je aplikacjom innych firm:

• [C-1-1] MUSI zgłaszać obsługę za pomocą właściwości android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] MUSI wykazywać w zakresie średnich częstotliwości w przybliżeniu płaską charakterystykę amplitudy w funkcji częstotliwości, a konkretnie ±10 dB w zakresie od 100 Hz do 7000 Hz w przypadku każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.

• [C-1-3] MUSI wykazywać poziomy amplitudy w zakresie niskich częstotliwości: w szczególności od ±20 dB w zakresie od 5 Hz do 100 Hz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.

• [C-1-4] MUSI wykazywać poziomy amplitudy w zakresie wysokich częstotliwości: w szczególności od ±30 dB w zakresie od 7000 Hz do 22 kHz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu użytego do nagrania nieprzetworzonego źródła dźwięku.

• [C-1-5] MUSI ustawić czułość wejścia audio tak, aby źródło dźwięku w postaci tonu sinusoidalnego o częstotliwości 1000 Hz odtwarzanego na poziomie ciśnienia akustycznego 94 dB dawało odpowiedź o wartości RMS 520 dla 16-bitowych próbek (lub –36 dB w pełnej skali dla próbek zmiennoprzecinkowych lub o podwójnej precyzji) dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-6] MUSI mieć stosunek sygnału do szumu (SNR) na poziomie co najmniej 60 dB w przypadku każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku. (natomiast SNR jest mierzony jako różnica między 94 dB SPL a równoważnym SPL szumu własnego, ważonym A).

• [C-1-7] MUSI mieć całkowite zniekształcenia harmoniczne (THD) mniejsze niż 1% przy poziomie wejściowym 90 dB SPL przy 1 kHz w przypadku każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• NIE MOŻE zawierać żadnego innego przetwarzania sygnału (np. automatycznej regulacji wzmocnienia, filtra górnoprzepustowego lub eliminacji echa) poza mnożnikiem poziomu, który doprowadza poziom do żądanego zakresu. Krótko mówiąc:

• [C-1-8] Jeśli w architekturze z jakiegokolwiek powodu występuje przetwarzanie sygnału, MUSI ono być wyłączone i nie może wprowadzać żadnego opóźnienia ani dodatkowej latencji na ścieżce sygnału.
• [C-1-9] Mnożnik poziomu może znajdować się na ścieżce, ale NIE MOŻE wprowadzać opóźnienia ani latencji na ścieżce sygnału.

Wszystkie pomiary SPL są wykonywane bezpośrednio obok testowanego mikrofonu. W przypadku konfiguracji z wieloma mikrofonami te wymagania dotyczą każdego z nich.

Jeśli implementacje urządzeń deklarują android.hardware.microphone, ale nie obsługują nieprzetworzonego źródła dźwięku:

• [C-2-1] MUSI zwracać null w przypadku metody interfejsu AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API, aby prawidłowo wskazywać brak obsługi.
• [SR] są nadal ZDECYDOWANIE ZALECANE, aby spełnić jak najwięcej 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 deweloperów Androida dostępne w pakiecie Android SDK.

• Android Debug Bridge (adb)

  • [C-0-2] MUSI obsługiwać adb zgodnie z dokumentacją pakietu Android SDK i poleceniami powłoki udostępnianymi w AOSP, z których mogą korzystać deweloperzy aplikacji, w tym dumpsys cmd stats
  • [C-SR] Zdecydowanie zalecane jest obsługiwanie polecenia powłoki cmd testharness.
  • [C-0-3] NIE WOLNO zmieniać formatu ani zawartości zdarzeń systemowych urządzenia (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) rejestrowanych za pomocą polecenia dumpsys.
  • [C-0-10] MUSI rejestrować bez pominięć i udostępniać następujące zdarzenia poleceniu powłoki cmd stats i klasie interfejsu API systemu StatsManager.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] Musi mieć domyślnie nieaktywny demon adb po stronie urządzenia i musi istnieć dostępny dla użytkownika mechanizm włączania Android Debug Bridge.
  • [C-0-5] MUSI obsługiwać bezpieczne adb. Android obsługuje bezpieczne adb. Bezpieczny adb umożliwia korzystanie z adb na znanych, uwierzytelnionych hostach.

  • [C-0-6] MUSI udostępniać mechanizm umożliwiający połączenie adb z maszyny hosta. Na przykład:

    • Implementacje urządzeń bez portu USB obsługującego tryb urządzenia peryferyjnego MUSZĄ implementować adb za pomocą sieci lokalnej (np. Ethernet lub Wi-Fi).
    • MUSI udostępniać sterowniki dla systemów Windows 7, 9 i 10, które umożliwiają programistom łączenie się z urządzeniem za pomocą protokołu ADB.

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] MUSI obsługiwać wszystkie funkcje ddms zgodnie z dokumentacją pakietu Android SDK. Ponieważ ddms korzysta z adb, obsługa ddms POWINNA być domyślnie nieaktywna, ale MUSI być obsługiwana, gdy użytkownik aktywuje Android Debug Bridge, jak opisano powyżej.
• Monkey
  • [C-0-8] MUSI zawierać platformę Monkey i udostępniać ją aplikacjom.
• SysTrace
  • [C-0-9] MUSI obsługiwać narzędzie systrace zgodnie z dokumentacją pakietu Android SDK. Narzędzie Systrace MUSI być domyślnie nieaktywne i MUSI istnieć mechanizm dostępny dla użytkownika, który umożliwia jego włączenie.

• Perfetto

  • [C-SR] Zdecydowanie zalecamy udostępnienie użytkownikowi powłoki pliku binarnego, którego wiersz poleceń jest zgodny z /system/bin/perfettodokumentacją Perfetto.
  • [C-SR] Zdecydowanie zalecamy, aby plik binarny perfetto akceptował jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR] Zdecydowanie zalecamy, aby plik binarny perfetto zapisywał jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR] Zdecydowanie zaleca się, aby za pomocą pliku binarnego perfetto dostarczać co najmniej źródła danych opisane w dokumentacji perfetto.

• Tryb jarzma testowego

  Jeśli implementacje urządzeń obsługują polecenie powłoki cmd testharness i uruchamiają cmd testharness enable, to:

  • [C-2-1] MUSI zwrócić true za ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] MUSI implementować tryb jarzma testowego zgodnie z opisem w dokumentacji trybu jarzma.

Jeśli implementacje urządzeń zgłaszają obsługę interfejsu Vulkan w wersji 1.0 lub nowszej za pomocą flag funkcji android.hardware.vulkan.version, to:

• [C-1-1] MUSI udostępniać deweloperowi aplikacji możliwość włączania i wyłączania warstw debugowania GPU.
• [C-1-2] MUSI, gdy włączone są warstwy debugowania GPU, wyliczać warstwy w bibliotekach dostarczonych przez narzędzia zewnętrzne (tj. niebędące częścią platformy ani pakietu aplikacji) znajdujące się w katalogu podstawowym aplikacji z możliwością debugowania, aby obsługiwać metody API vkEnumerateInstanceLayerProperties() i vkCreateInstance().

6.2. Opcje programisty

Android umożliwia deweloperom konfigurowanie ustawień związanych z tworzeniem aplikacji.

Implementacje urządzeń MUSZĄ zapewniać spójne działanie opcji programisty. W tym celu:

• [C-0-1] MUSI obsługiwać intencję android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z tworzeniem aplikacji. W przypadku Androida menu Opcje dewelopera jest domyślnie ukryte, a użytkownicy mogą je uruchomić, klikając 7 razy kolejno Ustawienia > Informacje o urządzeniu > Numer kompilacji.
• [C-0-2] MUSI domyślnie ukrywać Opcje programisty.
• [C-0-3] MUSI udostępniać przejrzysty mechanizm, który nie faworyzuje jednej aplikacji innej firmy w stosunku do innej, aby włączyć opcje programisty. MUSISZ podać publicznie dostępny dokument lub stronę internetową z opisem sposobu włączania opcji programisty. Ten dokument lub witryna MUSI być połączony z dokumentami pakietu Android SDK.
• POWINNA stale wyświetlać użytkownikowi powiadomienie wizualne, gdy opcje programisty są włączone i istnieje obawa o bezpieczeństwo użytkownika.
• MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty, ukrywając je lub wyłączając, aby nie rozpraszać użytkownika w sytuacjach, w których jego bezpieczeństwo jest zagrożone.

7. Zgodność sprzętu

Jeśli urządzenie zawiera określony komponent sprzętowy, który ma odpowiedni interfejs API dla deweloperów zewnętrznych:

• [C-0-1] Implementacja urządzenia MUSI implementować ten interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK.

Jeśli interfejs API w pakiecie SDK wchodzi w interakcję z komponentem sprzętowym, który jest opcjonalny, a implementacja urządzenia nie zawiera tego komponentu:

• [C-0-2] Muszą być nadal prezentowane pełne definicje klas (zgodnie z dokumentacją pakietu SDK) dla interfejsów API komponentów.
• [C-0-3] Działanie interfejsu API MUSI być zaimplementowane w rozsądny sposób jako operacja bez efektu.
• [C-0-4] Metody interfejsu API MUSZĄ zwracać wartości null w miejscach dozwolonych w dokumentacji pakietu SDK.
• [C-0-5] Metody interfejsu API MUSZĄ zwracać implementacje klas, które nie wykonują żadnych działań, jeśli dokumentacja pakietu SDK nie zezwala na wartości null.
• [C-0-6] Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, które nie są udokumentowane w dokumentacji pakietu SDK.
• [C-0-7] Implementacje urządzeń MUSZĄ konsekwentnie raportować dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager dla tego samego odcisku palca kompilacji.

Typowym przykładem scenariusza, w którym obowiązują te wymagania, jest interfejs API telefonii: nawet na urządzeniach innych niż telefony te interfejsy API MUSZĄ być zaimplementowane jako rozsądne operacje bezczynne.

7.1. Wyświetlacz i grafika

Android zawiera funkcje, które automatycznie dostosowują zasoby aplikacji i układy interfejsu do urządzenia, aby zapewnić prawidłowe działanie aplikacji innych firm na różnych konfiguracjach sprzętowych. Na wyświetlaczach zgodnych z Androidem, na których można uruchamiać wszystkie aplikacje innych firm zgodne z Androidem, implementacje urządzeń MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z opisem w tej sekcji.

Jednostki, do których odwołują się wymagania w tej sekcji, są zdefiniowane w ten sposób:

• fizyczną przekątną. Odległość w calach między dwoma przeciwległymi rogami oświetlonej części wyświetlacza.
• punkty na cal (dpi). Liczba pikseli obejmujących liniowy zakres poziomy lub pionowy o długości 1 cala. Jeśli podane są wartości dpi, zarówno pozioma, jak i pionowa wartość dpi MUSI mieścić się w zakresie.
• format obrazu. Stosunek pikseli dłuższego boku ekranu do pikseli krótszego boku. Na przykład wyświetlacz o rozdzielczości 480 x 854 pikseli ma współczynnik proporcji 854/480 = 1, 779, czyli w przybliżeniu „16:9”.
• piksel niezależny od gęstości (dp). Wirtualna jednostka piksela znormalizowana do ekranu o gęstości 160 dpi, obliczana jako: piksele = dp * (gęstość/160).

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar i kształt ekranu

Platforma interfejsu Androida obsługuje różne rozmiary układu ekranu logicznego i umożliwia aplikacjom sprawdzanie rozmiaru układu ekranu bieżącej konfiguracji za pomocą Configuration.screenLayout z SCREENLAYOUT_SIZE_MASK i Configuration.smallestScreenWidthDp.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłaszać prawidłowy rozmiar układu dla elementu Configuration.screenLayout zgodnie z dokumentacją pakietu SDK na Androida. W szczególności implementacje urządzeń MUSZĄ zgłaszać prawidłowe wymiary ekranu w pikselach niezależnych od gęstości (dp), jak poniżej:

  • Urządzenia, w których atrybut Configuration.uiMode ma wartość inną niż UI_MODE_TYPE_WATCH, a które zgłaszają rozmiar small dla atrybutu Configuration.screenLayout, MUSZĄ mieć wymiary co najmniej 426 dp x 320 dp.
  • Urządzenia zgłaszające rozmiar normal dla Configuration.screenLayout MUSZĄ mieć co najmniej 480 dp x 320 dp.
  • Urządzenia zgłaszające rozmiar large dla Configuration.screenLayout MUSZĄ mieć co najmniej 640 dp x 480 dp.
  • Urządzenia zgłaszające rozmiar xlarge dla Configuration.screenLayout MUSZĄ mieć co najmniej 960 dp x 720 dp.

• [C-0-2] MUSI prawidłowo uwzględniać deklarowaną przez aplikacje obsługę rozmiarów ekranu za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml, zgodnie z opisem w dokumentacji pakietu SDK do Androida.

• MOGĄ mieć wyświetlacze zgodne z Androidem i zaokrąglone rogi.

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 zapewnić, że promień zaokrąglonych rogów jest mniejszy lub równy 38 dp.
• POWINNA zawierać element interfejsu użytkownika umożliwiający przełączenie na tryb wyświetlania z prostokątnymi rogami.

7.1.1.2. Format ekranu

Chociaż nie ma ograniczeń dotyczących proporcji fizycznego wyświetlacza w przypadku wyświetlaczy zgodnych z Androidem, proporcje wyświetlacza logicznego, na którym renderowane są aplikacje innych firm, które można uzyskać na podstawie wartości wysokości i szerokości zgłaszanych przez interfejsy API view.Display i interfejsy API Configuration, MUSZĄ spełniać te wymagania:

• [C-0-1] Urządzenia, w których parametr Configuration.uiMode ma wartość UI_MODE_TYPE_NORMAL, MUSZĄ mieć współczynnik proporcji mniejszy lub równy 1,86 (w przybliżeniu 16:9), chyba że aplikacja spełnia jeden z tych warunków:

  • Aplikacja zadeklarowała, że obsługuje większy format ekranu, za pomocą wartości metadanych android.max_aspect.
  • Aplikacja deklaruje, że można zmienić jej rozmiar, za pomocą atrybutu android:resizeableActivity.
  • Aplikacja jest kierowana na poziom API 24 lub wyższy i nie deklaruje elementu android:maxAspectRatio, który ograniczałby dozwolony współczynnik proporcji.

• [C-0-2] Urządzenia z wartością Configuration.uiMode ustawioną na UI_MODE_TYPE_NORMAL MUSZĄ mieć współczynnik proporcji równy lub większy niż 1,3333 (4:3), chyba że aplikację można rozciągnąć, spełniając jeden z tych warunków:

  • Aplikacja deklaruje, że można zmienić jej rozmiar, za pomocą atrybutu android:resizeableActivity.
  • Aplikacja deklaruje android:minAspectRatio, które ogranicza dozwolony format obrazu.

• [C-0-3] Urządzenia, w których Configuration.uiMode jest ustawione jako UI_MODE_TYPE_WATCH, MUSZĄ mieć format obrazu ustawiony na 1,0 (1:1).

7.1.1.3. Gęstość ekranu

Platforma interfejsu Androida określa zestaw standardowych gęstości logicznych, aby ułatwić deweloperom aplikacji kierowanie zasobów aplikacji.

• [C-0-1] Domyślnie implementacje urządzeń MUSZĄ zgłaszać tylko jedną z gęstości struktury Androida wymienionych na stronie DisplayMetrics za pomocą interfejsu API DENSITY_DEVICE_STABLE, a ta wartość NIE MOŻE się zmieniać w żadnym momencie. Urządzenie MOŻE jednak zgłaszać inną dowolną gęstość w zależności od zmian konfiguracji wyświetlacza wprowadzonych przez użytkownika (np. rozmiaru wyświetlacza) po początkowym uruchomieniu.

• Implementacje urządzeń POWINNY definiować standardową gęstość platformy Android, która jest numerycznie najbliższa fizycznej gęstości ekranu, chyba że ta logiczna gęstość powoduje, że zgłaszany rozmiar ekranu jest mniejszy niż minimalny obsługiwany. Jeśli standardowa gęstość platformy Android, która jest numerycznie najbliższa gęstości fizycznej, powoduje, że rozmiar ekranu jest mniejszy niż najmniejszy obsługiwany zgodny rozmiar ekranu (320 dp szerokości), implementacje urządzeń POWINNY zgłaszać kolejną najniższą standardową gęstość platformy Android.

Jeśli istnieje możliwość zmiany rozmiaru wyświetlacza urządzenia:

• [C-1-1] Rozmiar wyświetlacza NIE MOŻE być skalowany do więcej niż 1,5-krotności natywnej gęstości ani powodować, że efektywny minimalny wymiar ekranu będzie mniejszy niż 320 dp (odpowiednik kwalifikatora zasobu sw320dp), w zależności od tego, co nastąpi wcześniej.
• [C-1-2] Rozmiar wyświetlacza NIE MOŻE być skalowany do wartości mniejszej niż 0,85-krotność natywnej gęstości.
• Aby zapewnić dobrą użyteczność i spójne rozmiary czcionek, ZALECA się podanie tych opcji skalowania wyświetlania natywnego (z zachowaniem podanych powyżej limitów):
• Mała: 0,85x
• Domyślnie: 1x (natywna skala wyświetlania)
• Duży: 1,15x
• Większy: 1,3x
• Największy 1,45x

7.1.2. Wyświetlanie danych

Jeśli implementacje urządzeń obejmują wyświetlacze zgodne z Androidem lub wyjście wideo do ekranów wyświetlaczy zgodnych z Androidem:

• [C-1-1] MUSI raportować prawidłowe wartości wszystkich danych wyświetlania zgodnych z Androidem zdefiniowanych w interfejsie android.util.DisplayMetrics API.

Jeśli urządzenie nie ma wbudowanego ekranu ani wyjścia wideo:

• [C-2-1] MUSI zgłaszać prawidłowe wartości wyświetlacza zgodnego z Androidem zgodnie z interfejsem API android.util.DisplayMetrics dla emulowanego domyślnego view.Display.

7.1.3. Orientacja ekranu

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłaszać obsługiwane orientacje ekranu (android.hardware.screen.portrait lub android.hardware.screen.landscape) i MUSI zgłaszać co najmniej jedną obsługiwaną orientację. Na przykład urządzenie z ekranem o stałej orientacji poziomej, takie jak telewizor lub laptop, POWINNO zgłaszać tylko wartość android.hardware.screen.landscape.
• [C-0-2] MUSI zgłaszać prawidłową wartość bieżącej orientacji urządzenia, gdy jest o to pytany za pomocą interfejsów android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innych interfejsów API.

Jeśli urządzenia obsługują obie orientacje ekranu:

• [C-1-1] MUSI obsługiwać dynamiczną zmianę orientacji przez aplikacje na pionową lub poziomą. Oznacza to, że urządzenie MUSI uwzględniać żądanie aplikacji dotyczące konkretnej orientacji ekranu.
• [C-1-2] NIE MOŻE zmieniać zgłoszonego rozmiaru ani gęstości ekranu podczas zmiany orientacji.
• MOŻE wybrać orientację pionową lub poziomą jako domyślną.

7.1.4. Akceleracja grafiki 2D i 3D

7.1.4.1. OpenGL ES

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo identyfikować obsługiwane wersje OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) za pomocą zarządzanych interfejsów API (np. za pomocą metody GLES10.getString()) i natywnych interfejsów API.
• [C-0-2] MUSI obejmować obsługę wszystkich odpowiednich zarządzanych interfejsów API i natywnych interfejsów API dla każdej wersji OpenGL ES, która jest obsługiwana.

Jeśli urządzenie ma ekran lub wyjście wideo:

• [C-1-1] MUSI obsługiwać interfejsy OpenGL ES 1.1 i 2.0, zgodnie z opisem w dokumentacji pakietu Android SDK.
• [C-SR] Zdecydowanie zaleca się obsługę OpenGL ES 3.1.
• POWINNO obsługiwać OpenGL ES 3.2.

Jeśli implementacje urządzeń obsługują którąkolwiek z wersji OpenGL ES:

• [C-2-1] MUSI raportować za pomocą interfejsów API zarządzanych przez OpenGL ES i interfejsów API natywnych wszystkie inne zaimplementowane rozszerzenia OpenGL ES i NIE MOŻE raportować ciągów rozszerzeń, których nie obsługuje.
• [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 zalecamy obsługę rozszerzeń EGL_KHR_partial_update i OES_EGL_image_external.
• POWINNY dokładnie zgłaszać za pomocą metody getString() wszystkie obsługiwane formaty kompresji tekstur, które są zwykle specyficzne dla danego dostawcy.

Jeśli implementacje urządzeń deklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2:

• [C-3-1] MUSI eksportować odpowiednie symbole funkcji dla tych wersji oprócz symboli funkcji OpenGL ES 2.0 w bibliotece libGLESv2.so.
• [SR] Are STRONGLY RECOMMENDED to support the OES_EGL_image_external_essl3 extension.

Jeśli implementacje urządzeń obsługują OpenGL ES 3.2:

• [C-4-1] MUSI w pełni obsługiwać pakiet rozszerzeń OpenGL ES na Androida.

Jeśli implementacje urządzeń w całości obsługują pakiet rozszerzeń Androida OpenGL ES, to:

• [C-5-1] MUSI identyfikować obsługę za pomocą flagi funkcji android.hardware.opengles.aep.

Jeśli implementacje urządzeń udostępniają 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 Vulkan

Android obsługuje Vulkana, wieloplatformowy interfejs API o niskim obciążeniu do obsługi wydajnej grafiki 3D.

Jeśli implementacje urządzeń obsługują OpenGL ES 3.1:

• [SR] ZDECYDOWANIE ZALECA się obsługę interfejsu Vulkan 1.1.

Jeśli urządzenie ma ekran lub wyjście wideo:

• POWINNO obejmować obsługę interfejsu Vulkan 1.1.

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

• [C-1-1] MUSI zgłaszać prawidłową wartość całkowitą z użyciem flag funkcji android.hardware.vulkan.level i android.hardware.vulkan.version.
• [C-1-2] MUSI zawierać co najmniej 1 element VkPhysicalDevice w przypadku natywnego interfejsu Vulkan API vkEnumeratePhysicalDevices() .
• [C-1-3] MUSI w pełni implementować interfejsy API Vulkan 1.0 dla każdego wymienionego VkPhysicalDevice.
• [C-1-4] MUSI wyliczać warstwy zawarte w bibliotekach natywnych o nazwach libVkLayer*.so w katalogu bibliotek natywnych pakietu aplikacji za pomocą natywnych interfejsów API Vulkan vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties() .
• [C-1-5] NIE MOŻE wyliczać warstw udostępnianych przez biblioteki spoza pakietu aplikacji ani udostępniać innych sposobów śledzenia lub przechwytywania interfejsu Vulkan API, chyba że aplikacja ma atrybut android:debuggable ustawiony jako true.
• [C-1-6] MUSZĄ zgłaszać wszystkie obsługiwane ciągi rozszerzeń za pomocą natywnych interfejsów API Vulkan i odwrotnie: NIE MOGĄ zgłaszać ciągów rozszerzeń , których nie obsługują prawidłowo.
• [C-1-7] MUSI obsługiwać rozszerzenia VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain i VK_KHR_incremental_present.
• [C-SR] Zdecydowanie zalecane jest obsługiwanie rozszerzeń VK_KHR_driver_properties i VK_GOOGLE_display_timing.

Jeśli implementacje urządzeń nie obsługują interfejsu Vulkan 1.0, to:

• [C-2-1] NIE MOŻE deklarować żadnych flag funkcji Vulkana (np. android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] NIE MOŻE wyliczać żadnych VkPhysicalDevice dla natywnego interfejsu Vulkan API vkEnumeratePhysicalDevices().

Jeśli implementacje urządzeń obsługują interfejs Vulkan 1.1 i deklarują dowolne flagi funkcji Vulkan, to:

• [C-3-1] MUSI udostępniać obsługę SYNC_FD zewnętrznych typów semaforów i uchwytów oraz rozszerzenia VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Implementacje urządzeń MUSZĄ obsługiwać Android RenderScript zgodnie z dokumentacją pakietu Android SDK.

7.1.4.4 Akceleracja grafiki 2D

Android zawiera mechanizm, który umożliwia aplikacjom deklarowanie, że chcą włączyć akcelerację sprzętową grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku za pomocą tagu manifestu android:hardwareAccelerated lub bezpośrednich wywołań interfejsu API.

Implementacje na urządzeniach:

• [C-0-1] MUSI domyślnie włączać akcelerację sprzętową i MUSI ją wyłączać, jeśli deweloper o to poprosi, ustawiając android:hardwareAccelerated="false” lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów API Android View.
• [C-0-2] MUSI działać zgodnie z dokumentacją pakietu Android SDK dotyczącą akceleracji sprzętowej.

Android zawiera obiekt TextureView, który umożliwia deweloperom bezpośrednie integrowanie tekstur OpenGL ES akcelerowanych sprzętowo jako miejsc docelowych renderowania w hierarchii interfejsu.

Implementacje na urządzeniach:

• [C-0-3] MUSI obsługiwać interfejs TextureView API i MUSI wykazywać spójne działanie z implementacją Androida wyższego poziomu.

7.1.4.5 Wyświetlacze o szerokiej gamie kolorów

Jeśli implementacje urządzeń deklarują obsługę wyświetlaczy o szerokiej gamie kolorów za pomocą Configuration.isScreenWideColorGamut() , to:

• [C-1-1] MUSI mieć skalibrowany kolorystycznie wyświetlacz.
• [C-1-2] MUSI mieć wyświetlacz, którego gama kolorów w przestrzeni CIE 1931 xyY w całości pokrywa gamę kolorów sRGB.
• [C-1-3] MUSI mieć wyświetlacz, którego gamut obejmuje co najmniej 90% przestrzeni barw DCI-P3 w przestrzeni CIE 1931 xyY.
• [C-1-4] MUSI obsługiwać OpenGL ES 3.1 lub 3.2 i prawidłowo to 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 zalecamy obsługę GL_EXT_sRGB.

Jeśli urządzenia nie obsługują wyświetlaczy o szerokiej gamie kolorów:

• [C-2-1] POWINIEN pokrywać co najmniej 100% sRGB w przestrzeni CIE 1931 xyY, chociaż gama kolorów ekranu jest niezdefiniowana.

7.1.5. Tryb zgodności ze starszymi aplikacjami

Android określa „tryb zgodności”, w którym platforma działa w trybie „normalnego” rozmiaru ekranu (320 dp szerokości) na potrzeby starszych aplikacji, które nie zostały opracowane dla starszych wersji Androida sprzed wprowadzenia niezależności od rozmiaru ekranu.

7.1.6. Technologia ekranu

Platforma Android zawiera interfejsy API, które umożliwiają aplikacjom renderowanie bogatej grafiki na wyświetlaczu zgodnym z Androidem. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zgodnie z definicją w pakiecie Android SDK, chyba że w tym dokumencie wyraźnie zezwala się na coś innego.

Wszystkie wyświetlacze zgodne z Androidem w ramach implementacji urządzenia:

• [C-0-1] MUSI obsługiwać renderowanie grafiki w 16-bitowej palecie kolorów.
• POWINNY obsługiwać wyświetlacze obsługujące 24-bitową grafikę kolorową.
• [C-0-2] MUSI obsługiwać renderowanie animacji.
• [C-0-3] MUSI mieć współczynnik proporcji piksela (PAR) w zakresie od 0,9 do 1,15. Oznacza to, że współczynnik proporcji piksela MUSI być zbliżony do kwadratu (1,0) z tolerancją 10–15%.

7.1.7. Wyświetlacze dodatkowe

Android obsługuje dodatkowe wyświetlacze zgodne z Androidem, aby umożliwić udostępnianie multimediów i interfejsy API dla programistów umożliwiające dostęp do wyświetlaczy zewnętrznych.

Jeśli urządzenia obsługują wyświetlacz zewnętrzny przez połączenie przewodowe, bezprzewodowe lub wbudowany dodatkowy wyświetlacz:

• [C-1-1] MUSI implementować usługę systemową i interfejs API DisplayManager zgodnie z opisem w dokumentacji pakietu Android SDK.

7.2. Urządzenia wejściowe

Implementacje na urządzeniach:

• [C-0-1] MUSI zawierać mechanizm wprowadzania danych, taki jak ekran dotykowy lub nawigacja bezdotykowa, umożliwiający poruszanie się między elementami interfejsu.

7.2.1. Klawiatura

Jeśli implementacje urządzeń obejmują obsługę aplikacji edytora metody wprowadzania (IME) innych firm:

• [C-1-1] MUSI zadeklarować flagę funkcji android.software.input_methods.
• [C-1-2] MUSI w pełni implementować Input Management Framework
• [C-1-3] MUSI mieć wstępnie zainstalowaną klawiaturę programową.

Implementacje urządzeń: * [C-0-1] NIE MOGĄ zawierać klawiatury sprzętowej, która nie jest zgodna z jednym z formatów określonych w android.content.res.Configuration.keyboard (QWERTY lub 12-klawiszowa). * POWINNY zawierać dodatkowe implementacje klawiatury ekranowej. * MOŻE zawierać klawiaturę sprzętową.

7.2.2. Nawigacja bezdotykowa

Android obsługuje klawisz kierunkowy, trackball i kółko jako mechanizmy nawigacji bezdotykowej.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłaszać prawidłową wartość parametru android.content.res.Configuration.navigation.

Jeśli implementacje urządzeń nie mają nawigacji bezdotykowej:

• [C-1-1] MUSI udostępniać rozsądny alternatywny mechanizm interfejsu użytkownika do wybierania i edytowania tekstu, zgodny z silnikami zarządzania wprowadzaniem danych. Implementacja open source Androida obejmuje mechanizm wyboru odpowiedni do użycia na urządzeniach, które nie mają wejść nawigacyjnych innych niż dotykowe.

7.2.3. Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz, które są zwykle dostępne po naciśnięciu specjalnego przycisku fizycznego lub określonej części ekranu dotykowego, są niezbędne w przypadku nawigacji na Androidzie, a tym samym w przypadku implementacji na urządzeniach:

• [C-0-1] MUSI udostępniać użytkownikowi możliwość uruchamiania zainstalowanych aplikacji, które mają działanie z wartością <intent-filter> ustawioną na ACTION=MAIN i CATEGORY=LAUNCHER lub CATEGORY=LEANBACK_LAUNCHER w przypadku implementacji na urządzeniach telewizyjnych. Funkcja Strona główna powinna być mechanizmem umożliwiającym użytkownikowi tę czynność.
• POWINNY zawierać przyciski do funkcji Ostatnie i Wstecz.

Jeśli dostępne są funkcje Strona główna, Ostatnie lub Wstecz:

• [C-1-1] MUSI być dostępny za pomocą jednego działania (np. kliknięcia, dwukrotnego kliknięcia lub gestu), gdy jest dostępny.
• [C-1-2] MUSI wyraźnie wskazywać, które pojedyncze działanie wywoła każdą funkcję. Przykłady takich informacji to widoczna ikona na przycisku, ikona oprogramowania na pasku nawigacyjnym na ekranie lub przeprowadzenie użytkownika przez demonstrację krok po kroku podczas konfiguracji po wyjęciu z pudełka.

Implementacje na urządzeniach:

• [SR] Zdecydowanie zalecamy, aby nie udostępniać mechanizmu wprowadzania danych dla funkcji Menu, ponieważ została ona wycofana na rzecz paska działań w Androidzie 4.0.

Jeśli implementacje urządzeń udostępniają funkcję Menu:

• [C-2-1] MUSI wyświetlać przycisk menu dodatkowych działań, gdy wyskakujące menu dodatkowych działań nie jest puste i pasek działań jest widoczny.
• [C-2-2] NIE MOŻE modyfikować pozycji wyskakującego okienka z dodatkowymi działaniami wyświetlanego po wybraniu przycisku dodatkowych działań na pasku działań, ale MOŻE renderować wyskakujące okienko z dodatkowymi działaniami w zmodyfikowanej pozycji na ekranie, gdy jest ono wyświetlane po wybraniu funkcji Menu.

Jeśli implementacje urządzeń nie udostępniają funkcji Menu, ze względu na zgodność wsteczną: * [C-SR] ZDECYDOWANIE ZALECA SIĘ udostępnianie funkcji Menu aplikacjom, gdy targetSdkVersion jest mniejsze niż 10, za pomocą fizycznego przycisku, klawisza programowego lub gestów. Ta funkcja menu POWINNA być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacyjnymi.

Jeśli implementacje urządzeń udostępniają funkcję pomocy, to:

• [C-4-1] MUSI udostępniać funkcję Asystenta za pomocą pojedynczej czynności (np. kliknięcia, dwukrotnego kliknięcia lub gestu), gdy dostępne są inne klawisze nawigacyjne.
• [SR] Zdecydowanie zalecamy używanie funkcji długiego naciśnięcia przycisku HOME jako wyznaczonej interakcji.

Jeśli implementacje urządzeń używają do wyświetlania klawiszy nawigacyjnych osobnej części ekranu:

• [C-5-1] Klawisze nawigacyjne MUSZĄ zajmować odrębną część ekranu, niedostępną dla aplikacji, i NIE MOGĄ zasłaniać ani w inny sposób zakłócać działania części ekranu dostępnej dla aplikacji.
• [C-5-2] MUSI udostępniać aplikacjom część wyświetlacza, która spełnia wymagania określone w sekcji 7.1.1.
• [C-5-3] MUSI uwzględniać flagi ustawione przez aplikację za pomocą metody interfejsu API View.setSystemUiVisibility(), aby ta odrębna część ekranu (czyli pasek nawigacyjny) była prawidłowo ukryta zgodnie z dokumentacją pakietu SDK.

Jeśli funkcja nawigacji jest dostępna jako działanie na ekranie oparte na gestach:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() MUSI być używany tylko do raportowania obszaru rozpoznawania gestu „Strona główna”.
• [C-6-2] Gesty, które zaczynają się w obszarze wykluczenia podanym przez aplikację działającą na pierwszym planie za pomocą View#setSystemGestureExclusionRects(), ale poza WindowInsets#getMandatorySystemGestureInsets(), NIE MOGĄ być przechwytywane na potrzeby funkcji nawigacji, o ile obszar wykluczenia mieści się w maksymalnym limicie wykluczenia określonym w dokumentacji View#setSystemGestureExclusionRects().
• [C-6-3] MUSI wysłać do aplikacji na pierwszym planie zdarzenie MotionEvent.ACTION_CANCEL, gdy tylko dotknięcia zaczną być przechwytywane na potrzeby gestu systemowego, jeśli wcześniej do aplikacji na pierwszym planie zostało wysłane zdarzenie MotionEvent.ACTION_DOWN.
• [C-6-4] MUSI udostępniać użytkownikowi możliwość przełączenia się na nawigację ekranową opartą na przyciskach (np. w Ustawieniach).
• POWINIEN zapewniać funkcję ekranu głównego w postaci przesunięcia palcem od dolnej krawędzi ekranu w górę w bieżącej orientacji ekranu.
• POWINIEN udostępniać funkcję Ostatnie jako przesunięcie palcem w górę i przytrzymanie przed zwolnieniem w tym samym obszarze co gest Home.
• Gesty rozpoczynające się w obszarze WindowInsets#getMandatorySystemGestureInsets() NIE POWINNY być objęte prostokątami wykluczenia podanymi przez aplikację na pierwszym planie za pomocą metody View#setSystemGestureExclusionRects().

Jeśli funkcja nawigacji jest dostępna w dowolnym miejscu na lewej i prawej krawędzi ekranu w bieżącej orientacji:

• [C-7-1] Funkcja nawigacji MUSI być funkcją Wstecz i musi być dostępna jako przesunięcie od lewej i prawej krawędzi ekranu w bieżącej orientacji.
• [C-7-2] Jeśli na lewej lub prawej krawędzi ekranu znajdują się niestandardowe panele systemowe, które można przesuwać, MUSZĄ one być umieszczone w górnej 1/3 ekranu i MUSZĄ mieć wyraźny, trwały wskaźnik wizualny, który informuje, że przeciągnięcie do wewnątrz spowoduje wyświetlenie wspomnianych paneli, a nie powrót. Panel systemowy MOŻE być skonfigurowany przez użytkownika tak, aby znajdował się poniżej górnej 1/3 krawędzi ekranu, ale NIE MOŻE zajmować więcej niż 1/3 krawędzi.
• [C-7-3] Jeśli 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, jak zaimplementowano to w AOSP, co zostało opisane w pakiecie SDK.
• [C-7-4] Jeśli aplikacja na pierwszym planie ma ustawioną flagę View.SYSTEM_UI_FLAG_IMMERSIVE lub View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, niestandardowe panele systemowe z możliwością przesuwania MUSZĄ być ukryte, dopóki użytkownik nie wyświetli pasków systemowych (czyli paska nawigacyjnego i paska stanu) w sposób zaimplementowany w AOSP.

7.2.4. Wprowadzanie danych za pomocą ekranu dotykowego

Android obsługuje różne systemy wprowadzania danych za pomocą wskaźnika, takie jak ekrany dotykowe, panele dotykowe i urządzenia do wprowadzania danych za pomocą symulacji dotyku. Urządzenia z ekranem dotykowym są powiązane z wyświetlaczem w taki sposób, że użytkownik ma wrażenie, że bezpośrednio manipuluje elementami na ekranie. Ponieważ użytkownik dotyka ekranu bezpośrednio, system nie wymaga żadnych dodatkowych elementów, które wskazywałyby manipulowane obiekty.

Implementacje na urządzeniach:

• POWINNO mieć jakiś system wprowadzania danych za pomocą wskaźnika (myszy lub dotyku).
• POWINNY obsługiwać wskaźniki śledzone w pełni niezależnie.

Jeśli urządzenie ma ekran dotykowy (obsługujący co najmniej 1 punkt dotyku):

• [C-1-1] MUSI zgłaszać wartość TOUCHSCREEN_FINGER w przypadku pola interfejsu API Configuration.touchscreen.
• [C-1-2] MUSI zgłaszać flagi funkcji android.hardware.touchscreen i android.hardware.faketouch.

Jeśli urządzenie ma ekran dotykowy, który może śledzić więcej niż 1 dotyk, musi:

• [C-2-1] MUSI zgłaszać odpowiednie flagi funkcji android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand odpowiadające typowi ekranu dotykowego na urządzeniu.

Jeśli urządzenie nie ma ekranu dotykowego (i korzysta tylko z urządzenia wskazującego) oraz spełnia wymagania dotyczące fałszywych dotknięć opisane w sekcji 7.2.5, to:

• [C-3-1] NIE MOŻE zgłaszać żadnych flag funkcji zaczynających się od android.hardware.touchscreen i MOŻE zgłaszać tylko android.hardware.faketouch.

7.2.5. Symulowane dotykowe wprowadzanie danych

Symulowany interfejs dotykowy to system wprowadzania danych przez użytkownika, który przybliża podzbiór funkcji ekranu dotykowego. Na przykład mysz lub pilot, które sterują kursorem na ekranie, są podobne do dotyku, ale wymagają od użytkownika najpierw wskazania lub ustawienia ostrości, a potem kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, żyroskopowa mysz powietrzna, żyroskopowy wskaźnik, joystick i trackpad wielodotykowy, może obsługiwać interakcje z fałszywym dotykiem. Android zawiera funkcję constant android.hardware.faketouch, która odpowiada urządzeniu wejściowemu o wysokiej wierności, które nie jest dotykowe (oparte na wskaźniku), np. myszy lub trackpadzie, które może odpowiednio emulować dane wejściowe oparte na dotyku (w tym podstawową obsługę gestów), i wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.

Jeśli urządzenie nie ma ekranu dotykowego, ale ma inny system wejściowy wskaźnika, który ma być dostępny, należy:

• POWINIEN deklarować obsługę flagi funkcji android.hardware.faketouch.

Jeśli implementacje urządzeń deklarują obsługę android.hardware.faketouch, to:

• [C-1-1] MUSI zgłaszać bezwzględne położenie wskaźnika na ekranie w osiach X i Y oraz wyświetlać wskaźnik na ekranie.
• [C-1-2] MUSI zgłaszać zdarzenie dotyku z kodem działania, który określa zmianę stanu wskaźnika podczas przesuwania w dół lub w górę ekranu.
• [C-1-3] MUSI obsługiwać naciśnięcie i zwolnienie wskaźnika na obiekcie na ekranie, co umożliwia użytkownikom emulowanie kliknięcia obiektu na ekranie.
• [C-1-4] MUSI obsługiwać naciśnięcie wskaźnika, zwolnienie wskaźnika, naciśnięcie wskaźnika, a następnie zwolnienie wskaźnika w tym samym miejscu na obiekcie na ekranie w określonym czasie, co umożliwia użytkownikom emulowanie dwukrotnego kliknięcia obiektu na ekranie.
• [C-1-5] MUSI obsługiwać naciśnięcie wskaźnika w dowolnym punkcie ekranu, przesunięcie wskaźnika do dowolnego innego punktu ekranu, a następnie zwolnienie wskaźnika, co umożliwia użytkownikom emulowanie przeciągania dotykowego.
• [C-1-6] MUSI obsługiwać naciśnięcie wskaźnika, a następnie umożliwiać użytkownikom szybkie przeniesienie obiektu w inne miejsce na ekranie i zwolnienie wskaźnika, co pozwala użytkownikom rzucać obiektem na ekranie.
• [C-1-7] MUSI zgłaszać wartość TOUCHSCREEN_NOTOUCH w polu interfejsu API Configuration.touchscreen.

Jeśli implementacje urządzeń deklarują obsługę android.hardware.faketouch.multitouch.distinct, to:

• [C-2-1] MUSI deklarować obsługę 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ądzeń deklarują obsługę android.hardware.faketouch.multitouch.jazzhand, to:

• [C-3-1] MUSI deklarować obsługę android.hardware.faketouch.
• [C-3-2] MUSI obsługiwać odrębne śledzenie co najmniej 5 wskaźników (śledzenie dłoni z palcami) w pełni niezależnie.

7.2.6. Obsługa kontrolera do gier

7.2.6.1. Mapowania przycisków

Jeśli implementacje urządzeń deklarują flagę funkcji android.hardware.gamepad, to:

• [C-1-1] MUSI zawierać kontroler wbudowany lub dostarczany w pudełku jako osobne urządzenie, które umożliwia wprowadzanie wszystkich zdarzeń wymienionych w tabelach poniżej.
• [C-1-2] MUSI mieć możliwość mapowania zdarzeń HID na powiązane z nimi stałe Androida view.InputEvent wymienione w tabelach poniżej. Implementacja Androida obejmuje implementację kontrolerów do gier, która spełnia to wymaganie.

1 KeyEvent

2 Powyższe zastosowania HID MUSZĄ być zadeklarowane w ramach urzędu certyfikacji Game pad (0x01 0x0005).

3 To użycie MUSI mieć wartość Logical Minimum równą 0, Logical Maximum równą 7, Physical Minimum równą 0, Physical Maximum równą 315, jednostki w stopniach i rozmiar raportu równy 4. Wartość logiczna jest zdefiniowana jako obrót w kierunku zgodnym z ruchem wskazówek zegara od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i naciśnięcie przycisku w górę, a wartość logiczna 1 oznacza obrót o 45 stopni i naciśnięcie klawiszy w górę i w lewo.

4 MotionEvent

1 MotionEvent

7.2.7. Pilot

Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.3.1.

7.3. Czujniki

Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, implementacja urządzenia MUSI implementować ten interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK i dokumentacji Android Open Source dotyczącej czujników.

Implementacje na urządzeniach:

• [C-0-1] MUSI dokładnie raportować obecność lub brak czujników w klasie android.content.pm.PackageManager.
• [C-0-2] MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() i podobnych metod.
• [C-0-3] MUSI działać w rozsądny sposób w przypadku wszystkich innych interfejsów API czujników (np. zwracać wartość true lub false w odpowiednich przypadkach, gdy aplikacje próbują zarejestrować odbiorniki, nie wywoływać odbiorników czujników, gdy odpowiednie czujniki nie są obecne itp.).

Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych:

• [C-1-1] MUSI zgłaszać wszystkie pomiary czujników, używając odpowiednich wartości w Międzynarodowym Układzie Jednostek (metrycznym) dla każdego typu czujnika zgodnie z dokumentacją pakietu Android SDK.
• [C-1-2] MUSI zgłaszać dane z czujnika z maksymalnym opóźnieniem wynoszącym 100 milisekund + 2 * sample_time w przypadku strumienia danych z czujnika z maksymalnym żądanym opóźnieniem wynoszącym 0 ms, gdy procesor aplikacji jest aktywny. To opóźnienie nie obejmuje żadnych opóźnień związanych z filtrowaniem.
• [C-1-3] MUSI zgłosić pierwszą próbkę z czujnika w ciągu 400 milisekund + 2 * sample_time od aktywacji czujnika. Dopuszczalna jest dokładność próbki wynosząca 0.

• [SR] POWINIEN raportować czas zdarzenia w nanosekundach zgodnie z dokumentacją pakietu Android SDK. Czas ten powinien odpowiadać momentowi wystąpienia zdarzenia i być zsynchronizowany z zegarem SystemClock.elapsedRealtimeNano(). Zdecydowanie zalecamy, aby obecne i nowe urządzenia z Androidem spełniały te wymagania, dzięki czemu będzie można je zaktualizować do przyszłych wersji platformy, w których ten komponent może być WYMAGANY. Błąd synchronizacji powinien być mniejszy niż 100 milisekund.

• [C-1-4] W przypadku każdego interfejsu API, który zgodnie z dokumentacją pakietu Android SDK jest czujnikiem ciągłym, implementacje urządzeń MUSZĄ stale dostarczać okresowe próbki danych, których odchylenie powinno być mniejsze niż 3%. Odchylenie jest definiowane jako odchylenie standardowe różnicy zgłaszanych wartości sygnatury czasowej między kolejnymi zdarzeniami.

• [C-1-5] MUSI zapewnić, że strumień zdarzeń z czujnika NIE BĘDZIE uniemożliwiał procesorowi urządzenia przejścia w stan zawieszenia ani wybudzenia się z niego.

• Gdy kilka czujników jest aktywnych, zużycie energii NIE POWINNO przekraczać sumy zgłoszonego zużycia energii poszczególnych czujników.

Powyższa lista nie jest wyczerpująca. Za wiarygodne należy uznać udokumentowane działanie pakietu Android SDK i dokumentację Android Open Source dotyczącą czujników.

Niektóre typy czujników są złożone, co oznacza, że można je uzyskać na podstawie danych dostarczanych przez co najmniej 1 inny czujnik. (Przykłady to czujnik orientacji i czujnik przyspieszenia liniowego).

Implementacje na urządzeniach:

• POWINNY implementować te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w sekcji Typy czujników.

Jeśli implementacje urządzeń obejmują czujnik złożony:

• [C-2-1] MUSI implementować czujnik zgodnie z opisem w dokumentacji Android Open Source dotyczącej czujników złożonych.

7.3.1. Akcelerometr

Implementacje na urządzeniach:

• [C-SR] ZDECYDOWANIE ZALECA się wyposażenie w 3-osiowy akcelerometr.

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

• [C-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz.
• [C-1-2] MUSI implementować i zgłaszać czujnik TYPE_ACCELEROMETER.
• [C-1-3] MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida.
• [C-1-4] MUSI być w stanie mierzyć w zakresie od swobodnego spadania do czterokrotności przyspieszenia ziemskiego(4 g) lub więcej w dowolnej osi.
• [C-1-5] MUSI mieć rozdzielczość 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 dla każdej osi na podstawie próbek zebranych w okresie co najmniej 3 sekund przy największej szybkości próbkowania.
• [SR] Zdecydowanie zalecamy wdrożenie czujnika złożonego TYPE_SIGNIFICANT_MOTION.
• [SR] Zdecydowanie zalecamy wdrożenie i raportowanie danych z TYPE_ACCELEROMETER_UNCALIBRATED czujnika. Zdecydowanie ZALECA się, aby urządzenia z Androidem spełniały to wymaganie, dzięki czemu będzie można je uaktualnić do przyszłej wersji platformy, w której to wymaganie może być OBOWIĄZKOWE.
• POWINIEN implementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR i TYPE_STEP_COUNTER zgodnie z opisem w dokumencie Android SDK.
• POWINNY zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.
• POWINNA mieć rozdzielczość co najmniej 16 bitów.
• POWINIEN być kalibrowany podczas użytkowania, jeśli jego charakterystyka zmienia się w trakcie cyklu życia, a także kompensowany, a parametry kompensacji powinny być zachowywane między ponownymi uruchomieniami urządzenia.
• POWINNY mieć kompensację temperatury.

Jeśli urządzenie ma 3-osiowy akcelerometr i którykolwiek z czujników złożonych TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER:

• [C-2-1] Suma zużycia energii MUSI zawsze być mniejsza niż 4 mW.
• POWINNY być mniejsze niż 2 mW i 0,5 mW, gdy urządzenie jest w stanie dynamicznym lub statycznym.

Jeśli urządzenie ma 3-osiowy akcelerometr i 3-osiowy żyroskop, to:

• [C-3-1] MUSI wdrożyć czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR] Zdecydowanie zaleca się wdrożenie czujnika złożonego TYPE_GAME_ROTATION_VECTOR.

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

• [C-4-1] MUSI implementować TYPE_ROTATION_VECTOR czujnik złożony.

7.3.2. Magnetometr

Implementacje na urządzeniach:

• [C-SR] ZDECYDOWANIE ZALECA się uwzględnienie 3-osiowego magnetometru (kompasu).

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

• [C-1-1] MUSI wdrożyć czujnik TYPE_MAGNETIC_FIELD.
• [C-1-2] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 10 Hz i POWINIEN raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-3] MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida.
• [C-1-4] MUSI być w stanie mierzyć wartości w zakresie od -900 µT do +900 µT na każdej osi, zanim osiągnie stan nasycenia.
• [C-1-5] MUSI mieć wartość przesunięcia twardego żelaza mniejszą niż 700 µT i POWINIEN mieć wartość poniżej 200 µT, co można osiągnąć, umieszczając magnetometr z dala od dynamicznych (indukowanych prądem) i statycznych (indukowanych 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 spowodowanego przez ferromagnetyki oraz zachowywać parametry kompensacji między ponownymi uruchomieniami urządzenia.
• [C-1-8] MUSI mieć zastosowaną kompensację miękkiego żelaza – kalibrację można przeprowadzić podczas użytkowania lub produkcji urządzenia.
• [C-1-9] MUSI mieć odchylenie standardowe obliczone dla każdej osi na podstawie próbek zebranych w okresie co najmniej 3 sekund przy największej częstotliwości próbkowania, nie większe niż 1,5 µT; POWINNO mieć odchylenie standardowe nie większe niż 0,5 µT.
• POWINIEN implementować czujnik TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] W przypadku obecnych i nowych urządzeń z Androidem ZDECYDOWANIE ZALECA SIĘ wdrożenie TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Jeśli urządzenie zawiera 3-osiowy magnetometr, akcelerometr i 3-osiowy żyroskop, to:

• [C-2-1] MUSI implementować TYPE_ROTATION_VECTOR czujnik złożony.

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

• MOŻE implementować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Jeśli implementacje urządzenia zawierają 3-osiowy magnetometr, akcelerometr i czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR:

• [C-3-1] MUSI zużywać mniej niż 10 mW.
• POWINIEN zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie wsadowym przy częstotliwości 10 Hz.

7.3.3. GPS

Implementacje na urządzeniach:

• [C-SR] ZDECYDOWANIE ZALECA się, aby zawierały odbiornik GPS/GNSS.

Jeśli implementacje urządzeń zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, to:

• [C-1-1] MUSI obsługiwać dane o lokalizacji z częstotliwością co najmniej 1 Hz, gdy są one wymagane w ramach żądania LocationManager#requestLocationUpdate.
• [C-1-2] MUSI być w stanie określić lokalizację w warunkach otwartego nieba (silne sygnały, znikoma wielodrożność, HDOP < 2) w ciągu 10 sekund (szybki czas do pierwszego ustalenia pozycji), gdy jest połączony z internetem o szybkości transmisji danych co najmniej 0,5 Mb/s. Ten wymóg jest zwykle spełniany przez zastosowanie jakiejś formy wspomaganego lub prognozowanego GPS/GNSS, aby zminimalizować czas ustalania pozycji GPS/GNSS (dane wspomagające obejmują czas odniesienia, lokalizację odniesienia i efemerydy/zegar satelity).
  • [C-1-6] Po wykonaniu takiego obliczenia lokalizacji implementacje urządzeń MUSZĄ określić swoją lokalizację na otwartym niebie w ciągu 5 sekund od ponownego uruchomienia żądań lokalizacji, do godziny po początkowym obliczeniu lokalizacji, nawet jeśli kolejne żądanie zostanie wysłane bez połączenia transmisji danych lub po wyłączeniu i ponownym włączeniu zasilania.

• W otwartej przestrzeni po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 1 m/s²:

  • [C-1-3] MUSI być w stanie określić lokalizację z dokładnością do 20 metrów i prędkość z dokładnością do 0,5 metra na sekundę w co najmniej 95% przypadków.
  • [C-1-4] MUSI jednocześnie śledzić i zgłaszać za pomocą GnssStatus.Callback co najmniej 8 satelitów z jednej konstelacji.
  • POWINNO być w stanie śledzić jednocześnie co najmniej 24 satelity z różnych konstelacji (np. GPS i co najmniej 1 z systemów GLONASS, BeiDou lub Galileo).
  • [C-SR] ZDECYDOWANIE ZALECA się, aby podczas połączenia alarmowego nadal przekazywać normalne dane lokalizacji GPS/GNSS za pomocą interfejsów GNSS Location Provider API.
  • [C-SR] Zdecydowanie zaleca się zgłaszanie pomiarów GNSS ze wszystkich śledzonych konstelacji (zgłaszanych w wiadomościach GnssStatus), z wyjątkiem SBAS.
  • [C-SR] Zdecydowanie zalecamy raportowanie AGC i częstotliwości pomiaru GNSS.
  • [C-SR] Zdecydowanie zaleca się zgłaszanie wszystkich szacunków dokładności (w tym kierunku, prędkości i wysokości) w ramach każdej lokalizacji GPS/GNSS.
  • [C-SR] Zdecydowanie zaleca się zgłaszanie pomiarów GNSS od razu po ich wykryciu, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
  • [C-SR] Zdecydowanie zaleca się zgłaszanie pseudoodległości i szybkości pseudoodległości GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 0,2 m/s², wystarczają do obliczenia pozycji z dokładnością do 20 metrów i prędkości z dokładnością do 0,2 m/s w co najmniej 95% przypadków.

7.3.4. Żyroskop

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie zaleca się, aby urządzenia STRONGLY RECOMMENDED zawierały czujnik żyroskopowy, chyba że mają też 3-osiowy akcelerometr.

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

• [C-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz.
• [C-1-2] MUSI implementować czujnik TYPE_GYROSCOPE i ZDECYDOWANIE ZALECA SIĘ implementowanie czujnika TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-4] MUSI mieć rozdzielczość co najmniej 12 bitów i POWINIEN mieć rozdzielczość co najmniej 16 bitów.
• [C-1-5] MUSI mieć kompensację temperatury.
• [C-1-6] MUSI być kalibrowany i kompensowany podczas użytkowania oraz zachowywać parametry kompensacji między ponownymi uruchomieniami 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ć ograniczona tą wartością. Inaczej mówiąc, jeśli zmierzysz wariancję żyroskopu przy częstotliwości próbkowania 1 Hz, NIE POWINNA ona przekraczać 1e-7 rad^2/s^2.
• [SR] Błąd kalibracji ZDECYDOWANIE ZALECA się, aby był mniejszy niż 0,01 rad/s, gdy urządzenie jest nieruchome w temperaturze pokojowej.
• POWINNY zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.

Jeśli implementacje urządzenia zawierają 3-osiowy żyroskop, akcelerometr i magnetometr:

• [C-2-1] MUSI implementować TYPE_ROTATION_VECTOR czujnik złożony.

Jeśli urządzenie ma 3-osiowy akcelerometr i 3-osiowy żyroskop, to:

• [C-3-1] MUSI wdrożyć czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR] Zdecydowanie zaleca się wdrożenie czujnika złożonego TYPE_GAME_ROTATION_VECTOR.

7.3.5. barometr;

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie zaleca się, aby zawierały barometr (czujnik ciśnienia powietrza).

Jeśli implementacje urządzeń obejmują barometr:

• [C-1-1] MUSI implementować i zgłaszać TYPE_PRESSURE.
• [C-1-2] MUSI być w stanie dostarczać zdarzenia z częstotliwością co najmniej 5 Hz.
• [C-1-3] MUSI mieć kompensację temperatury.
• [SR] ZDECYDOWANIE ZALECANE, aby można było raportować pomiary ciśnienia w zakresie od 300 hPa do 1100 hPa.
• POWINNA mieć dokładność bezwzględną na poziomie 1 hPa.
• POWINIEN mieć dokładność względną 0,12 hPa w zakresie 20 hPa (co odpowiada dokładności ok. 1 m przy zmianie wysokości o ok. 200 m na poziomie morza).

7.3.6. Termometr

Implementacje na urządzeniach:

• MOŻE zawierać termometr otoczenia (czujnik temperatury).
• MOŻE, ale NIE POWINIEN zawierać czujnika temperatury procesora.

Jeśli urządzenie ma termometr otoczenia (czujnik temperatury):

• [C-1-1] MUSI być zdefiniowany jako SENSOR_TYPE_AMBIENT_TEMPERATURE i MUSI mierzyć temperaturę otoczenia (pomieszczenia lub kabiny pojazdu) w miejscu, w którym użytkownik korzysta z urządzenia, w stopniach Celsjusza.
• [C-1-2] MUSI być zdefiniowany jako SENSOR_TYPE_TEMPERATURE.
• [C-1-3] MUSI mierzyć temperaturę procesora urządzenia.
• [C-1-4] NIE WOLNO mierzyć żadnej innej temperatury.

Pamiętaj, że typ czujnika SENSOR_TYPE_TEMPERATURE został wycofany w Androidzie 4.0.

7.3.7. Fotometr

• Urządzenia MOGĄ zawierać fotometr (czujnik światła otoczenia).

7.3.8. Czujnik zbliżeniowy

• Urządzenia MOGĄ zawierać czujnik zbliżeniowy.

Jeśli implementacje urządzeń obejmują czujnik zbliżeniowy:

• [C-1-1] MUSI mierzyć odległość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI być zorientowany w taki sposób, aby wykrywać obiekty znajdujące się blisko ekranu, ponieważ jego głównym zadaniem jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacje urządzenia zawierają czujnik zbliżeniowy w dowolnej innej orientacji, NIE MOŻE on być dostępny za pomocą tego interfejsu API.
• [C-1-2] MUSI mieć dokładność co najmniej 1 bit.

7.3.9. Czujniki o wysokiej wierności

Jeśli implementacje urządzeń obejmują zestaw czujników wyższej jakości zdefiniowanych w tej sekcji i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI identyfikować funkcję za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

Jeśli implementacje urządzeń deklarują android.hardware.sensor.hifi_sensors, to:

• [C-2-1] MUSI mieć czujnik TYPE_ACCELEROMETER, który:

  • MUSI mieć zakres pomiarowy co najmniej od -8 g do +8 g, POWINIEN mieć zakres pomiarowy co najmniej od -16 g do +16 g.
  • MUSI mieć rozdzielczość pomiaru co najmniej 2048 LSB/g.
  • MUSI mieć minimalną częstotliwość pomiaru wynoszącą 12,5 Hz lub mniej.
  • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz; POWINIEN obsługiwać SensorDirectChannel RATE_VERY_FAST.
  • MUSI mieć szum pomiarowy nie większy niż 400 μg/√Hz.
  • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z możliwością buforowania co najmniej 3000 zdarzeń.
  • MUSI mieć zużycie energii w przypadku przetwarzania wsadowego nie większe niż 3 mW.
  • [C-SR] Zdecydowanie zaleca się, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a w tym paśmie znajdowało się widmo szumu białego.
  • POWINIEN mieć losowy błąd przyspieszenia mniejszy niż 30 μg √Hz testowany w temperaturze pokojowej.
  • POWINIEN mieć zmianę odchylenia w stosunku do temperatury ≤ +/- 1 mg/°C.
  • POWINIEN mieć nieliniowość linii dopasowania ≤ 0,5% i zmianę czułości w stosunku do temperatury ≤ 0,03%/°C.
  • POWINIEN mieć czułość w kierunku osi poprzecznej < 2,5 % i zmienność czułości w kierunku osi poprzecznej < 0,2% w zakresie temperatury pracy urządzenia.

• [C-2-2] MUSI mieć TYPE_ACCELEROMETER_UNCALIBRATED o takich samych wymaganiach dotyczących jakości jak TYPE_ACCELEROMETER.

• [C-2-3] MUSI mieć czujnik TYPE_GYROSCOPE, który:

  • MUSI mieć zakres pomiarowy co najmniej od -1000 do +1000 dps.
  • MUSI mieć rozdzielczość pomiaru co najmniej 16 LSB/dps.
  • MUSI mieć minimalną częstotliwość pomiaru wynoszącą 12,5 Hz lub mniej.
  • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz; POWINIEN obsługiwać SensorDirectChannel RATE_VERY_FAST.
  • MUSI mieć szum pomiarowy nie większy niż 0,014°/s/√Hz.
  • [C-SR] Zdecydowanie zaleca się, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a w tym paśmie znajdowało się widmo szumu białego.
  • POWINIEN mieć błąd losowy szybkości mniejszy niż 0,001°/s √Hz testowany w temperaturze pokojowej.
  • POWINIEN mieć zmianę odchylenia w stosunku do temperatury ≤ +/- 0,05°/ s / °C.
  • POWINIEN mieć zmianę czułości w stosunku do temperatury ≤ 0,02% / °C.
  • POWINIEN mieć nieliniowość linii najlepszego dopasowania ≤ 0,2%.
  • POWINIEN mieć gęstość szumu ≤ 0,007°/s/√Hz.
  • Gdy urządzenie jest nieruchome, błąd kalibracji powinien być mniejszy niż 0,002 rad/s w zakresie temperatur 10–40°C.
  • POWINIEN mieć czułość na przyspieszenie grawitacyjne mniejszą niż 0,1°/s/g.
  • POWINIEN mieć czułość w kierunku poprzecznym < 4,0 % i zmienność czułości w kierunku poprzecznym < 0,3% w zakresie temperatury pracy urządzenia.

• [C-2-4] MUSI mieć TYPE_GYROSCOPE_UNCALIBRATED o takich samych wymaganiach dotyczących jakości jak TYPE_GYROSCOPE.

• [C-2-5] MUSI mieć czujnik TYPE_GEOMAGNETIC_FIELD, który:

  • MUSI mieć zakres pomiarowy co najmniej od -900 μT do +900 μT.
  • MUSI mieć rozdzielczość pomiaru co najmniej 5 LSB/uT.
  • Musi mieć minimalną częstotliwość pomiaru wynoszącą 5 Hz lub mniej.
  • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 50 Hz.
  • MUSI mieć szum pomiarowy nieprzekraczający 0,5 uT.

• [C-2-6] MUSI mieć TYPE_MAGNETIC_FIELD_UNCALIBRATED o takich samych wymaganiach dotyczących jakości jak TYPE_GEOMAGNETIC_FIELD, a dodatkowo:

  • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z możliwością buforowania co najmniej 600 zdarzeń.
  • [C-SR] Zdecydowanie zaleca się, aby przy częstotliwości raportowania wynoszącej 50 Hz lub więcej szum biały miał spektrum od 1 Hz do co najmniej 10 Hz.

• [C-2-7] MUSI mieć czujnik TYPE_PRESSURE, który:

  • MUSI mieć zakres pomiarowy co najmniej od 300 hPa do 1100 hPa.
  • MUSI mieć rozdzielczość pomiaru co najmniej 80 LSB/hPa.
  • Musi mieć minimalną częstotliwość pomiaru wynoszącą 1 Hz lub mniej.
  • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 10 Hz.
  • MUSI mieć szum pomiarowy nie większy niż 2 Pa/√Hz.
  • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z możliwością buforowania co najmniej 300 zdarzeń.
  • Musi mieć zużycie energii w trybie przetwarzania wsadowego nie większe niż 2 mW.
• [C-2-8] MUSI mieć czujnik TYPE_GAME_ROTATION_VECTOR.
• [C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:
  • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest nieruchome, i 1,5 mW, gdy urządzenie jest w ruchu.
• [C-2-10] MUSI mieć czujnik TYPE_STEP_DETECTOR, który:
  • MUSI implementować ten czujnik w wersji bez wybudzania z możliwością buforowania co najmniej 100 zdarzeń.
  • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest nieruchome, i 1,5 mW, gdy urządzenie jest w ruchu.
  • Musi mieć zużycie energii w trybie wsadowym nie większe niż 4 mW.
• [C-2-11] MUSI mieć czujnik TYPE_STEP_COUNTER, który:
  • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest nieruchome, i 1,5 mW, gdy urządzenie jest w ruchu.
• [C-2-12] MUSI mieć czujnik TILT_DETECTOR, który:
  • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest nieruchome, i 1,5 mW, gdy urządzenie jest w ruchu.
• [C-2-13] Sygnatura czasowa zdarzenia tego samego zdarzenia fizycznego zgłaszanego przez akcelerometr, żyroskop i magnetometr MUSI różnić się od siebie o nie więcej niż 2, 5 milisekundy. Znacznik czasu zdarzenia tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr i żyroskop POWINIEN różnić się od siebie o nie więcej niż 0,25 milisekundy.
• [C-2-14] MUSI mieć sygnatury czasowe zdarzeń z żyroskopu na tej samej podstawie czasu co podsystem aparatu i z błędem nie większym niż 1 milisekunda.
• [C-2-15] MUSI dostarczać próbki do aplikacji w ciągu 5 milisekund od momentu, w którym dane są dostępne w aplikacji z dowolnego z wymienionych powyżej czujników fizycznych.
• [C-2-16] NIE MOŻE mieć poboru mocy większego niż 0,5 mW, gdy urządzenie jest nieruchome, i 2,0 mW, gdy urządzenie jest w ruchu, przy włączonej dowolnej kombinacji tych czujników:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] MOŻE mieć czujnik TYPE_PROXIMITY, ale jeśli jest obecny, MUSI mieć minimalną pojemność bufora wynoszącą 100 zdarzeń z czujnika.

Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje ona moc pobieraną przez cały łańcuch czujników – czujnik, wszelkie obwody pomocnicze, dedykowany system przetwarzania danych z czujników itp.

Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników:

• [C-3-1] MUSI prawidłowo deklarować obsługę typów kanałów bezpośrednich i poziomów bezpośrednich stawek raportowania 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 czujnika.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• POWINIEN obsługiwać raportowanie zdarzeń za pomocą bezpośredniego kanału czujnika w przypadku głównego czujnika (wersja bez wybudzania) tych typów:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Czujniki biometryczne

Więcej informacji o pomiarze bezpieczeństwa odblokowywania biometrycznego znajdziesz w dokumentacji dotyczącej pomiaru bezpieczeństwa biometrycznego.

Jeśli implementacje urządzeń obejmują bezpieczny ekran blokady:

• POWINIEN zawierać czujnik biometryczny

Czujniki biometryczne można podzielić na silne, słabe i wygodne na podstawie współczynników akceptacji fałszywych danych i podszywania się oraz bezpieczeństwa potoku biometrycznego. Ta klasyfikacja określa możliwości, jakie czujnik biometryczny ma w zakresie interakcji z platformą i aplikacjami innych firm. Czujniki są domyślnie klasyfikowane jako wygodne i muszą spełniać dodatkowe wymagania opisane poniżej, aby można było je zaklasyfikować jako słabe lub silne. Zarówno słabe, jak i silne dane biometryczne zyskują dodatkowe możliwości, które opisujemy poniżej.

Aby udostępnić czujnik biometryczny aplikacjom innych firm, implementacje urządzeń:

• [C-0-1] MUSI spełniać wymagania dotyczące biometrii silnej lub słabej zgodnie z definicjami w tym dokumencie.

Aby zezwolić aplikacjom innych firm i implementacjom urządzeń na dostęp do kluczy w magazynie kluczy:

• [C-0-2] MUSI spełniać wymagania dotyczące silnego uwierzytelniania zdefiniowane w tym dokumencie.

Dodatkowo:

• [C-0-3] MUSI być połączona z wyraźnym działaniem potwierdzającym (np. naciśnięciem przycisku), jeśli silna biometria jest pasywna (np. twarz lub tęczówka, w przypadku których nie ma wyraźnego sygnału o intencjach użytkownika).
  • [C-SR] Potwierdzenie działania w przypadku pasywnych danych biometrycznych ZDECYDOWANIE ZALECA się zabezpieczyć w taki sposób, aby naruszenie systemu operacyjnego lub jądra nie mogło go sfałszować. Oznacza to na przykład, że działanie potwierdzenia oparte na przycisku fizycznym jest kierowane przez ogólnego przeznaczenia pin wejścia/wyjścia (GPIO) tylko do wprowadzania danych w bezpiecznym elemencie (SE), którego nie można sterować w inny sposób niż przez naciśnięcie przycisku fizycznego.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako wygodny, muszą:

• [C-1-1] MUSI mieć odsetek fałszywych akceptacji mniejszy niż 0,002%.
• [C-1-2] MUSI informować, że ten tryb może być mniej bezpieczny niż silny kod PIN, wzór lub hasło, i wyraźnie wymieniać zagrożenia związane z jego włączeniem, jeśli wskaźniki akceptacji fałszywych tożsamości i podszywania się są wyższe niż 7%.
• [C-1-3] MUSI ograniczać liczbę prób przez co najmniej 30 sekund po 5 nieudanych próbach weryfikacji biometrycznej. Nieudana próba to próba o odpowiedniej jakości rejestracji (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.
• [C-1-4] MUSI uniemożliwiać dodawanie nowych danych biometrycznych bez wcześniejszego utworzenia łańcucha zaufania przez potwierdzenie przez użytkownika istniejących lub dodanie nowych danych logowania na urządzeniu (kodu PIN, wzoru lub hasła) zabezpieczonych przez TEE. Implementacja w ramach Android Open Source Project udostępnia mechanizm, który to umożliwia.
• [C-1-5] MUSI całkowicie usuwać wszystkie dane biometryczne umożliwiające identyfikację użytkownika, gdy jego konto zostanie usunięte (w tym w wyniku przywrócenia urządzenia do ustawień fabrycznych).
• [C-1-6] MUSI uwzględniać indywidualną flagę dla danego rodzaju danych biometrycznych (np. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE lub DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] MUSI co 24 godziny lub rzadziej w przypadku nowych urządzeń z Androidem 10 oraz co 72 godziny lub rzadziej w przypadku urządzeń, które zostały zaktualizowane z wcześniejszej wersji Androida, wymagać od użytkownika zalecanego podstawowego uwierzytelnienia (np. kodu PIN, wzoru lub hasła).

• [C-1-8] MUSI poprosić użytkownika o podanie zalecanego podstawowego sposobu uwierzytelniania (np. kodu PIN, wzoru lub hasła) w jednym z tych przypadków:

  • 4-godzinny okres nieaktywności LUB
  • 3 nieudane próby uwierzytelnienia biometrycznego.
  • Okres bezczynności i liczba nieudanych prób uwierzytelnienia są resetowane po każdej udanej weryfikacji danych logowania na urządzenie.

  Aktualizacja urządzeń ze starszej wersji Androida może być zwolniona z wymogu C-1-8.

• [C-SR] Zdecydowanie zaleca się, aby wskaźnik fałszywych odrzuceń wynosił mniej niż 10% (pomiar na urządzeniu).

• [C-SR] Zdecydowanie zaleca się, aby w przypadku każdego zarejestrowanego elementu biometrycznego opóźnienie od momentu wykrycia elementu biometrycznego do odblokowania ekranu było mniejsze niż 1 sekunda.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako słaby, muszą:

• [C-2-1] MUSI spełniać wszystkie wymagania dotyczące wygody wymienione powyżej, z wyjątkiem [C-1-2].
• [C-2-2] MUSI mieć współczynnik akceptacji fałszywych tożsamości i podszywania się nie wyższy niż 20%.
• [C-2-3] MUSI mieć implementację magazynu kluczy opartego na sprzęcie i przeprowadzać dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza przestrzenią użytkownika lub jądra Androida, np. w zaufanym środowisku wykonawczym (TEE) lub na układzie z bezpiecznym kanałem do odizolowanego środowiska wykonawczego.
• [C-2-4] MUSI mieć wszystkie dane umożliwiające identyfikację zaszyfrowane i uwierzytelnione kryptograficznie w taki sposób, aby nie można było ich uzyskać, odczytać ani zmienić poza odizolowanym środowiskiem wykonawczym lub układem z bezpiecznym kanałem do odizolowanego środowiska wykonawczego, zgodnie z dokumentacją w wytycznych dotyczących implementacji na stronie Android Open Source Project.
• [C-2-5] W przypadku biometrii opartej na kamerze podczas uwierzytelniania lub rejestracji biometrycznej:
  • MUSI obsługiwać kamerę w trybie, który uniemożliwia odczytywanie lub modyfikowanie klatek kamery poza odizolowanym środowiskiem wykonawczym lub układem z bezpiecznym kanałem do odizolowanego środowiska wykonawczego.
  • W przypadku rozwiązań z jedną kamerą RGB klatki kamery MOGĄ być odczytywane poza odizolowanym środowiskiem wykonawczym, aby obsługiwać operacje takie jak podgląd podczas rejestracji, ale NIE MOGĄ być zmieniane.
• [C-2-6] NIE MOŻE umożliwiać aplikacjom innych firm rozróżniania poszczególnych rejestracji danych biometrycznych.
• [C-2-7] NIE MOŻE zezwalać na niezaszyfrowany dostęp do danych biometrycznych umożliwiających identyfikację lub danych z nich pochodzących (np. osadzeń) w procesorze aplikacji poza kontekstem TEE.

• [C-2-8] MUSI mieć bezpieczny potok przetwarzania, tak aby naruszenie bezpieczeństwa systemu operacyjnego lub jądra nie umożliwiało bezpośredniego wstrzykiwania danych w celu fałszywego uwierzytelniania jako użytkownik.

  Jeśli implementacje urządzeń zostały już wprowadzone na rynek w starszej wersji Androida i nie mogą spełnić wymagania C-2-8 za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać z niego zwolnione.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako silny, muszą:

• [C-3-1] MUSI spełniać wszystkie wymagania dotyczące słabego sygnału wymienione powyżej. Uaktualnianie urządzeń z wcześniejszej wersji Androida nie jest zwolnione z wymogu C-2-7.
• [C-3-2] MUSI mieć odsetek akceptacji fałszywych tożsamości i podszywania się nie wyższy niż 7%.
• [C-3-3] MUSI co 72 godziny lub rzadziej wymagać od użytkownika zalecanego podstawowego uwierzytelnienia (np. kodu PIN, wzoru lub hasła).

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 6 stopniami swobody:

• [C-1-1] MUSI implementować i zgłaszać czujnik TYPE_POSE_6DOF.
• [C-1-2] MUSI być dokładniejszy niż sam wektor rotacji.

7.4. Łączność danych

7.4.1. Połączenia telefoniczne

Termin „telefonia” używany w interfejsach API Androida i w tym dokumencie odnosi się konkretnie do sprzętu związanego z wykonywaniem połączeń głosowych i wysyłaniem SMS-ów w sieci GSM lub CDMA. Chociaż połączenia głosowe mogą być lub nie być przełączane pakietowo, na potrzeby Androida są one traktowane jako niezależne od połączenia do transmisji danych, które może być realizowane w tej samej sieci. Innymi słowy, funkcje i interfejsy API „telefonia” na Androidzie odnoszą się konkretnie do połączeń głosowych i SMS-ów. Na przykład urządzenia, które nie mogą wykonywać połączeń ani wysyłać i odbierać SMS-ów, nie są uważane za urządzenia telefoniczne, niezależnie od tego, czy korzystają z sieci komórkowej do transmisji danych.

• Systemu Android MOŻNA używać na urządzeniach, które nie mają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami innymi niż telefony.

Jeśli implementacje urządzeń obejmują telefonię GSM lub CDMA:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.telephony i inne flagi podrzędnych funkcji zgodnie z technologią.
• [C-1-2] MUSI wdrożyć pełną obsługę interfejsu API dla tej technologii.

Jeśli implementacje urządzeń nie obejmują sprzętu telefonicznego:

• [C-2-1] MUSI zaimplementować pełne interfejsy API jako operacje bez efektu.

Jeśli implementacje urządzeń obsługują karty eUICC lub eSIM/wbudowane karty SIM i zawierają mechanizm własny, który udostępnia funkcje eSIM deweloperom zewnętrznym:

• [C-3-1] MUSI udostępniać pełną implementację EuiccManager API.

7.4.1.1. Zgodność z blokowaniem numerów

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

• [C-1-1] MUSI obsługiwać blokowanie numerów
• [C-1-2] MUSI w pełni implementować 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 „BlockedNumberProvider” bez interakcji z aplikacjami. Jedynym wyjątkiem jest sytuacja, gdy blokowanie numerów zostanie tymczasowo zniesione w sposób opisany w dokumentacji pakietu SDK.
• [C-1-4] NIE MOŻE zapisywać informacji w rejestrze połączeń platformy w przypadku zablokowanego połączenia.
• [C-1-5] NIE MOŻE wysyłać do operatora telefonicznego informacji o zablokowanej wiadomości.
• [C-1-6] MUSI implementować interfejs zarządzania zablokowanymi numerami, który jest otwierany za pomocą intencji zwracanej przez metodę TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NIE MOŻE zezwalać użytkownikom dodatkowym na wyświetlanie ani edytowanie zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że użytkownik podstawowy ma pełną kontrolę nad usługami telefonicznymi (jedną instancją) na urządzeniu. Wszystkie elementy interfejsu związane z blokowaniem MUSZĄ być ukryte dla użytkowników dodatkowych, a lista zablokowanych MUSI być nadal uwzględniana.
• POWINNY przenosić zablokowane numery do dostawcy, gdy urządzenie zostanie zaktualizowane do Androida 7.0.

7.4.1.2. Telecom API

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

• [C-1-1] MUSI obsługiwać interfejsy API ConnectionService opisane w pakiecie SDK.
• [C-1-2] MUSI wyświetlać nowe połączenie przychodzące i umożliwiać użytkownikowi zaakceptowanie lub odrzucenie połączenia przychodzącego, gdy użytkownik prowadzi połączenie zainicjowane przez aplikację innej firmy, która nie obsługuje funkcji wstrzymania określonej za pomocą CAPABILITY_SUPPORT_HOLD.
• [C-1-3] MUSI mieć aplikację, która implementuje InCallService.

• [C-SR] ZDECYDOWANIE ZALECA się powiadamianie użytkownika, że odebranie połączenia przychodzącego spowoduje zakończenie trwającego połączenia.

  Implementacja AOSP spełnia te wymagania dzięki powiadomieniu, które informuje użytkownika, że odebranie połączenia przychodzącego spowoduje rozłączenie innego połączenia.

• [C-SR] ZDECYDOWANIE ZALECA się wstępne wczytywanie domyślnej aplikacji do wybierania numerów, która wyświetla wpis w historii połączeń i nazwę aplikacji innej firmy w swojej historii połączeń, gdy aplikacja innej firmy ustawia klucz dodatkowy EXTRA_LOG_SELF_MANAGED_CALLS w swoim elemencie PhoneAccount na wartość true.

• [C-SR] Zdecydowanie zaleca się obsługę zdarzeń KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK słuchawek audio w przypadku interfejsów API android.telecom w sposób opisany poniżej:
  • Wywołaj Connection.onDisconnect(), gdy podczas trwającej rozmowy zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia.
  • Wywołaj Connection.onAnswer(), gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie klawisza.
  • Wywołaj Connection.onReject(), gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia.
  • Przełącz stan wyciszenia CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementacje na urządzeniach:

• POWINIEN obsługiwać co najmniej jeden standard 802.11.

Jeśli implementacje urządzeń obsługują standard 802.11 i udostępniają tę funkcję aplikacji innej firmy:

• [C-1-1] MUSI implementować odpowiedni interfejs API Androida.
• [C-1-2] MUSI raportować flagę funkcji sprzętowej android.hardware.wifi.
• [C-1-3] MUSI implementować interfejs API multiemisji zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-4] MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) w żadnym momencie działania, w tym:
  • Nawet wtedy, gdy ekran nie jest aktywny.
  • W przypadku urządzeń z Androidem TV, nawet w trybie gotowości.
• [C-1-5] NIE WOLNO traktować wywołania metody interfejsu API WifiManager.enableNetwork() jako wystarczającej wskazówki do przełączenia aktualnie aktywnego Network, który jest domyślnie używany w przypadku ruchu aplikacji i jest zwracany przez metody interfejsu API ConnectivityManager, takie jak getActiveNetwork i registerDefaultNetworkCallback. Innymi słowy, mogą one WYŁĄCZYĆ dostęp do internetu zapewniany przez innego dostawcę sieci (np. mobilną transmisję danych) TYLKO wtedy, gdy potwierdzą, że sieć Wi-Fi zapewnia dostęp do internetu.
• [C-1-6] ZDECYDOWANIE ZALECA SIĘ, aby po wywołaniu metody interfejsu API ConnectivityManager.reportNetworkConnectivity() ponownie ocenić dostęp do internetu na urządzeniu Network i gdy ocena wykaże, że bieżące urządzenie Network nie zapewnia już dostępu do internetu, przełączyć się na dowolną inną dostępną sieć (np. mobilną transmisję danych), która zapewnia dostęp do internetu.
• [C-SR] ZDECYDOWANIE ZALECA się losowanie źródłowego adresu MAC i numeru sekwencyjnego ramek żądania sondy raz na początku każdego skanowania, gdy stacja jest odłączona.
  • Każda grupa ramek żądań sondowania składająca się z jednego skanowania POWINNA używać jednego spójnego adresu MAC (NIE POWINNA randomizować adresu MAC w połowie skanowania).
  • Numer sekwencyjny żądania sondy POWINIEN być zwiększany w normalny sposób (sekwencyjnie) między żądaniami sondy w skanowaniu.
  • Numer sekwencyjny żądania sondy POWINIEN być losowy między ostatnim żądaniem sondy skanowania a pierwszym żądaniem sondy następnego skanowania.
• [C-SR] są ZDECYDOWANIE ZALECANE, gdy STA jest odłączony, aby zezwalać w ramkach żądań sondowania tylko na te elementy:
  • Zestaw parametrów SSID (0)
  • DS Parameter Set (3)

Jeśli implementacje urządzeń obejmują obsługę trybu oszczędzania energii Wi-Fi zgodnie z definicją w standardzie IEEE 802.11:

• [C-3-1] MUSI wyłączać tryb oszczędzania energii Wi-Fi, gdy aplikacja uzyska blokadę WIFI_MODE_FULL_HIGH_PERF lub blokadę WIFI_MODE_FULL_LOW_LATENCY za pomocą interfejsów API WifiManager.createWifiLock() i WifiManager.WifiLock.acquire(), a blokada jest aktywna.
• [C-3-2] Średni czas oczekiwania w ruchu w obie strony między urządzeniem a punktem dostępu, gdy urządzenie jest w trybie blokady Wi-Fi o niskim opóźnieniu (WIFI_MODE_FULL_LOW_LATENCY), MUSI być mniejszy niż czas oczekiwania w trybie blokady Wi-Fi o wysokiej wydajności (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] są ZDECYDOWANIE ZALECANE, aby zminimalizować opóźnienie w obie strony w przypadku Wi-Fi, gdy tylko zostanie uzyskana i zacznie obowiązywać blokada niskiego opóźnienia (WIFI_MODE_FULL_LOW_LATENCY).

Jeśli urządzenia obsługują Wi-Fi i używają tej sieci do skanowania lokalizacji:

• [C-2-1] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania odczytu wartości za pomocą metody interfejsu API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementacje na urządzeniach:

• POWINNO obejmować obsługę Wi-Fi Direct (Wi-Fi peer-to-peer).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Direct:

• [C-1-1] MUSI implementować odpowiedni interfejs API Androida zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] MUSI raportować funkcję sprzętową android.hardware.wifi.direct.
• [C-1-3] MUSI obsługiwać standardowe działanie Wi-Fi.
• [C-1-4] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Direct.

7.4.2.2. Konfiguracja tunelowanego bezpośredniego połączenia Wi-Fi

Implementacje na urządzeniach:

• POWINNY obsługiwać konfigurację tunelowanego bezpośredniego połączenia Wi-Fi (TDLS) zgodnie z dokumentacją pakietu Android SDK.

Jeśli implementacje urządzeń obejmują obsługę TDLS, a TDLS jest włączony przez interfejs WiFiManager API:

• [C-1-1] MUSI deklarować obsługę TDLS za pomocą WifiManager.isTdlsSupported.
• TDLS należy używać tylko wtedy, gdy jest to możliwe I korzystne.
• POWINNO mieć pewne heurystyki i NIE używać TDLS, gdy jego wydajność może być gorsza niż w przypadku połączenia przez punkt dostępu Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementacje na urządzeniach:

• POWINIEN obsługiwać Wi-Fi Aware.

Jeśli implementacje urządzeń obsługują Wi-Fi Aware i udostępniają tę funkcję aplikacjom innych firm, to:

• [C-1-1] MUSI implementować interfejsy API WifiAwareManager zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.aware.
• [C-1-3] MUSI obsługiwać jednocześnie operacje Wi-Fi i Wi-Fi Aware.
• [C-1-4] MUSI losowo zmieniać adres interfejsu zarządzania Wi-Fi Aware w interwałach nie dłuższych niż 30 minut i za każdym razem, gdy włączona jest funkcja Wi-Fi Aware.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i lokalizacji Wi-Fi zgodnie z opisem w sekcji 7.4.2.5 i udostępniają te funkcje aplikacjom innych firm, to:

• [C-2-1] MUSI implementować interfejsy API wykrywania z uwzględnieniem lokalizacji: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm i onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Implementacje na urządzeniach:

• POWINIEN obsługiwać Wi-Fi Passpoint.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Passpoint:

• [C-1-1] MUSI implementować interfejsy API związane z Passpointem WifiManager zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] MUSI obsługiwać standard IEEE 802.11u, w szczególności w zakresie wykrywania i wybierania sieci, np. protokoły GAS (Generic Advertisement Service) i ANQP (Access Network Query Protocol).

Jeśli implementacje urządzeń nie obejmują obsługi Wi-Fi Passpoint:

• [C-2-1] Implementacja interfejsów API związanych z Passpoint WifiManager MUSI zgłaszać wyjątek UnsupportedOperationException.

7.4.2.5. Lokalizacja Wi-Fi (czas błądzenia Wi-Fi – RTT)

Implementacje na urządzeniach:

• POWINIEN obsługiwać lokalizację Wi-Fi.

Jeśli implementacje urządzeń obsługują lokalizację Wi-Fi i udostępniają tę funkcję aplikacjom innych firm, to:

• [C-1-1] MUSI implementować interfejsy API WifiRttManager zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.rtt.
• [C-1-3] MUSI losowo generować źródłowy adres MAC dla każdego pakietu RTT wykonywanego, gdy interfejs Wi-Fi, na którym jest wykonywany RTT, nie jest powiązany z punktem dostępu.

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

Implementacje na urządzeniach:

• POWINIEN obsługiwać odciążanie funkcji utrzymywania połączenia Wi-Fi.

Jeśli implementacje urządzeń obsługują przenoszenie działania Wi-Fi keepalive i udostępniają tę funkcję aplikacjom innych firm:

• [C-1-1] MUSI obsługiwać interfejs SocketKeepAlive API.

• [C-1-2] MUSI obsługiwać co najmniej 3 równoczesne gniazda keepalive przez Wi-Fi i co najmniej 1 gniazdo keepalive przez sieć komórkową.

Jeśli implementacje urządzeń nie obsługują przenoszenia na Wi-Fi funkcji keepalive, to:

• [C-2-1] MUSI zwrócić ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protokół udostępniania urządzenia)

Implementacje na urządzeniach:

• POWINNO obsługiwać Wi-Fi Easy Connect (DPP).

Jeśli implementacje urządzeń obsługują Wi-Fi Easy Connect i udostępniają tę funkcję aplikacjom innych firm:

• [C-1-1] MUSI implementować interfejsy API intencji Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] MUSI zwracać wartość true w metodzie WifiManager#isEasyConnectSupported().

7.4.3. Bluetooth

Jeśli implementacje urządzeń obsługują profil audio Bluetooth:

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

Jeśli implementacje urządzeń obsługują profile HFP, A2DP i AVRCP, to:

• POWINNO obsługiwać co najmniej 5 połączonych urządzeń.

Jeśli implementacje urządzeń deklarują funkcję android.hardware.vr.high_performance:

• [C-1-1] MUSI obsługiwać Bluetooth 4.2 i rozszerzenie długości danych Bluetooth LE.

Android obsługuje Bluetooth i Bluetooth Low Energy.

Jeśli urządzenia obsługują Bluetooth i Bluetooth Low Energy:

• [C-2-1] MUSI zadeklarować odpowiednie funkcje platformy (android.hardware.bluetooth i android.hardware.bluetooth_le) oraz zaimplementować interfejsy API platformy.
• POWINNO implementować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX, HFP itp., w zależności od urządzenia.

Jeśli urządzenia obsługują Bluetooth Low Energy:

• [C-3-1] MUSI zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
• [C-3-2] MUSI włączyć interfejsy API Bluetooth oparte na GATT (generic attribute profile) zgodnie z opisem w dokumentacji pakietu SDK i android.bluetooth.
• [C-3-3] MUSI zgłaszać prawidłową wartość parametru BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy zaimplementowano logikę filtrowania klas interfejsu API ScanFilter.
• [C-3-4] MUSI zgłaszać prawidłową wartość atrybutu BluetoothAdapter.isMultipleAdvertisementSupported(), aby wskazać, czy reklamy o niskim zużyciu energii są obsługiwane.
• W przypadku implementacji interfejsu ScanFilter API powinien obsługiwać przenoszenie logiki filtrowania do chipsetu Bluetooth.
• POWINIEN obsługiwać przenoszenie skanowania wsadowego do chipsetu Bluetooth.

• POWINIEN obsługiwać wiele reklam z co najmniej 4 slotami.

• [SR] Zdecydowanie zalecamy wdrożenie limitu czasu dla adresu prywatnego z możliwością rozwiązania (RPA) nie dłuższego niż 15 minut i rotację adresu po upływie limitu czasu w celu ochrony prywatności użytkownika.

Jeśli urządzenia obsługują Bluetooth LE i używają go do skanowania lokalizacji:

• [C-4-1] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania odczytu wartości za pomocą interfejsu System API BluetoothAdapter.isBleScanAlwaysAvailable().

Jeśli implementacje urządzeń obejmują obsługę Bluetooth LE i profilu aparatów słuchowych, zgodnie z opisem w sekcji Obsługa dźwięku z aparatów słuchowych za pomocą Bluetooth LE, to:

• [C-5-1] MUSI zwracać true w przypadku wywołania funkcji BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

7.4.4. Komunikacja bliskiego pola

Implementacje na urządzeniach:

• POWINIEN zawierać nadajnik-odbiornik i powiązany sprzęt do komunikacji Near Field Communication (NFC).
• [C-0-1] MUSI implementować interfejsy API android.nfc.NdefMessage i android.nfc.NdefRecord, nawet jeśli nie obsługują one NFC lub nie deklarują funkcji android.hardware.nfc, ponieważ klasy reprezentują format reprezentacji danych niezależny od protokołu.

Jeśli implementacje urządzeń zawierają sprzęt NFC i mają być udostępniane aplikacjom innych firm:

• [C-1-1] MUSI zgłaszać funkcję android.hardware.nfc z android.content.pm.PackageManager.hasSystemFeature() metody.
• MUSI umożliwiać odczytywanie i zapisywanie wiadomości NDEF za pomocą tych standardów NFC:
• [C-1-2] MUSI być w stanie działać jako czytnik/zapisywarka NFC Forum (zgodnie ze specyfikacją techniczną NFC Forum NFCForum-TS-DigitalProtocol-1.0) w ramach tych standardów NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NFC-F (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Typy tagów NFC Forum 1, 2, 3, 4, 5 (zdefiniowane przez NFC Forum)

• [SR] ZDECYDOWANIE ZALECANE jest, aby urządzenie obsługiwało odczyt i zapis wiadomości NDEF oraz surowych danych zgodnie z tymi standardami NFC: Pamiętaj, że chociaż standardy NFC są ZDECYDOWANIE ZALECANE, w przyszłej wersji definicji zgodności planujemy zmienić je na WYMAGANE. W tej wersji te standardy są opcjonalne, ale w przyszłych wersjach będą wymagane. W przypadku obecnych i nowych urządzeń z tą wersją Androida ZDECYDOWANIE ZALECA się spełnienie tych wymagań już teraz, aby można było je uaktualnić do przyszłych wersji platformy.

• [C-1-13] MUSI odpytywać wszystkie obsługiwane technologie w trybie wykrywania NFC.

• POWINNO być w trybie wykrywania NFC, gdy urządzenie jest włączone, ekran jest aktywny, a ekran blokady jest odblokowany.
• POWINNA być w stanie odczytać kod kreskowy i adres URL (jeśli jest zakodowany) produktów Thinfilm NFC Barcode.

Pamiętaj, że w przypadku wymienionych powyżej specyfikacji JIS, ISO i NFC Forum nie są dostępne publicznie linki.

Android obsługuje tryb emulacji karty hosta (HCE) NFC.

Jeśli implementacje urządzeń obejmują chipset kontrolera NFC obsługujący HCE (w przypadku NfcA lub NfcB) i routing identyfikatora aplikacji (AID), muszą:

• [C-2-1] MUSI zgłaszać stałą funkcji android.hardware.nfc.hce.
• [C-2-2] MUSI obsługiwać interfejsy NFC HCE API zdefiniowane w pakiecie Android SDK.

Jeśli implementacje urządzeń zawierają chipset kontrolera NFC obsługujący HCE dla NfcF i wdrażają tę funkcję w aplikacjach innych firm:

• [C-3-1] MUSI zgłaszać android.hardware.nfc.hcef stałą funkcji.
• [C-3-2] MUSI implementować interfejsy API emulacji kart NFC-F zdefiniowane w pakiecie Android SDK.

Jeśli implementacje urządzeń obejmują ogólną obsługę NFC opisaną w tej sekcji i obsługują technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF na MIFARE Classic) w roli czytnika/zapisywarki:

• [C-4-1] MUSI implementować odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
• [C-4-2] MUSI zgłaszać funkcję com.nxp.mifare z metody android.content.pm.PackageManager.hasSystemFeature(). Pamiętaj, że nie jest to standardowa funkcja Androida, dlatego nie występuje jako stała w klasie android.content.pm.PackageManager.

7.4.5. Minimalna funkcjonalność sieci

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać co najmniej 1 formę sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o przepustowości co najmniej 200 kbit/s. Przykłady technologii spełniających to wymaganie to EDGE, HSPA, EV-DO, 802.11g, Ethernet i Bluetooth PAN.
• Powinno też obsługiwać co najmniej jeden popularny standard bezprzewodowej transmisji danych, np. 802.11 (Wi-Fi), gdy podstawowym połączeniem do transmisji danych jest fizyczny standard sieciowy (np. Ethernet).
• MOŻE obsługiwać więcej niż 1 rodzaj połączenia do transmisji danych.
• [C-0-2] MUSI zawierać stos sieciowy IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection, oraz natywnych interfejsów API, takich jak gniazda AF_INET6.
• [C-0-3] MUSI domyślnie włączać protokół IPv6.
• MUSI zapewnić, że komunikacja IPv6 jest tak samo niezawodna jak IPv4, np.:
  • [C-0-4] MUSI utrzymywać łączność IPv6 w trybie uśpienia.
  • [C-0-5] Ograniczanie szybkości NIE MOŻE powodować utraty łączności IPv6 na żadnej sieci zgodnej z IPv6, która używa czasu życia RA wynoszącego co najmniej 180 sekund.
• [C-0-6] MUSI zapewniać aplikacjom innych firm bezpośrednie połączenie z siecią IPv6, gdy urządzenie jest połączone z siecią IPv6, bez żadnego tłumaczenia adresów lub portów lokalnie na urządzeniu. Zarówno interfejsy API zarządzane, takie jak Socket#getLocalAddress czy Socket#getLocalPort), jak i interfejsy NDK API, takie jak getsockname() czy IPV6_PKTINFO, MUSZĄ zwracać adres IP i port, które są faktycznie używane do wysyłania i odbierania pakietów w sieci.

Wymagany poziom obsługi IPv6 zależy od typu sieci, jak pokazują poniższe wymagania.

Jeśli urządzenia obsługują Wi-Fi:

• [C-1-1] MUSI obsługiwać podwójny stos i działanie tylko w IPv6 w sieci Wi-Fi.

Jeśli urządzenia obsługują Ethernet, to:

• [C-2-1] MUSI obsługiwać działanie w trybie dual-stack w sieci Ethernet.

Jeśli implementacje urządzeń obsługują komórkową transmisję danych:

• POWINNO obsługiwać działanie IPv6 (tylko 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órkowej transmisji danych):

• [C-3-1] MUSI jednocześnie spełniać powyższe wymagania w każdej sieci, gdy urządzenie jest jednocześnie połączone z więcej niż jednym typem sieci.

7.4.6. Ustawienia synchronizacji

Implementacje na urządzeniach:

• [C-0-1] Musi mieć domyślnie włączone główne ustawienie automatycznej synchronizacji, aby metoda getMasterSyncAutomatically() zwracała wartość „true”.

7.4.7. Oszczędzanie danych

Jeśli implementacje urządzeń obejmują połączenie taryfowe, są to:

• [SR] Zdecydowanie zalecamy udostępnienie trybu oszczędzania danych.

Jeśli implementacje urządzeń udostępniają tryb oszczędzania danych:

• [C-1-1] MUSI obsługiwać wszystkie interfejsy API w klasie ConnectivityManager zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] MUSI udostępniać w ustawieniach interfejs, który obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, umożliwiając użytkownikom dodawanie aplikacji do listy dozwolonych i usuwanie ich z niej.

Jeśli implementacje urządzeń nie udostępniają trybu oszczędzania danych:

• [C-2-1] MUSI zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED dla ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NIE WOLNO nadawać ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
• [C-2-3] MUSI mieć aktywność, która obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻE ją zaimplementować jako operację bez efektu.

7.4.8. Secure Elements

Jeśli implementacje urządzeń obsługują Open Mobile API, które umożliwia korzystanie z bezpiecznych elementów, i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI wymieniać dostępne czytniki Secure Element, gdy wywoływana jest metoda android.se.omapi.SEService.getReaders().

7.5. Aparaty

Jeśli implementacje urządzeń obejmują co najmniej 1 aparat, to:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.camera.any.
• [C-1-2] Aplikacja MUSI mieć możliwość jednoczesnego przydzielenia 3 map bitowych RGBA_8888 o rozmiarze równym rozmiarowi obrazów generowanych przez czujnik aparatu o najwyższej rozdzielczości na urządzeniu, gdy aparat jest otwarty w celu podstawowego podglądu i wykonywania zdjęć.
• [C-1-3] MUSI zapewnić, że preinstalowana 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 usuwanie lokalizacji użytkownika z metadanych obrazu przed wysłaniem go do aplikacji odbierającej, jeśli aplikacja odbierająca nie ma uprawnienia ACCESS_FINE_LOCATION.

7.5.1. Tylny aparat

Tylny aparat to aparat znajdujący się po stronie urządzenia przeciwnej do wyświetlacza. Rejestruje on obraz sceny po drugiej stronie urządzenia, tak jak tradycyjny aparat.

Implementacje na urządzeniach:

• POWINNO zawierać tylny aparat.

Jeśli urządzenie ma co najmniej 1 aparat skierowany do tyłu:

• [C-1-1] MUSI zgłaszać flagę funkcji android.hardware.camera i android.hardware.camera.any.
• [C-1-2] MUSI mieć rozdzielczość co najmniej 2 megapikseli.
• POWINIEN mieć w sterowniku aparatu zaimplementowaną funkcję automatycznego ustawiania ostrości sprzętowego lub programowego (niewidoczną dla oprogramowania aplikacji).
• MOŻE mieć sprzęt z stałą ostrością lub EDOF (rozszerzoną głębią ostrości).
• MOŻE zawierać lampę błyskową.

Jeśli aparat ma lampę błyskową:

• [C-2-1] Lampa błyskowa NIE MOŻE być włączona, gdy na powierzchni podglądu kamery zarejestrowano instancję android.hardware.Camera.PreviewCallback, chyba że aplikacja wyraźnie włączyła lampę błyskową, włączając atrybuty FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu systemowego urządzenia, ale tylko aplikacji innych firm korzystających z Camera.PreviewCallback.

7.5.2. Przedni aparat

Przedni aparat to aparat znajdujący się po tej samej stronie urządzenia co wyświetlacz. Jest on zwykle używany do rejestrowania obrazu użytkownika, np. podczas wideokonferencji i podobnych zastosowań.

Implementacje na urządzeniach:

• MOŻE zawierać przedni aparat.

Jeśli urządzenia mają co najmniej 1 aparat przedni:

• [C-1-1] MUSI zgłaszać 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 w przypadku interfejsu Camera API i NIE MOŻE konfigurować interfejsu tak, aby traktował przedni aparat jako domyślny tylny aparat, nawet jeśli jest to jedyny aparat na urządzeniu.
• [C-1-4] Podgląd z kamery MUSI być odwrócony w poziomie względem orientacji określonej przez aplikację, jeśli bieżąca aplikacja wyraźnie zażądała obrócenia wyświetlacza kamery za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation(). Natomiast podgląd MUSI być odwrócony wzdłuż domyślnej osi poziomej urządzenia, jeśli bieżąca aplikacja nie zażąda wyraźnie obrócenia ekranu aparatu za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NIE MOŻE tworzyć odbicia lustrzanego końcowego zarejestrowanego obrazu lub strumieni wideo zwracanych do wywołań zwrotnych aplikacji ani zapisywanych w pamięci multimediów.
• [C-1-6] MUSI odzwierciedlać obraz wyświetlany przez widok po zrobieniu zdjęcia w taki sam sposób jak strumień obrazu z podglądu z kamery.
• MOŻE zawierać funkcje (takie jak automatyczne ustawianie ostrości, lampa błyskowa itp.) dostępne w przypadku aparatów skierowanych do tyłu, zgodnie z opisem w sekcji 7.5.1.

Jeśli urządzenia można obracać (np. automatycznie za pomocą akcelerometru lub ręcznie przez użytkownika):

• [C-2-1] Podgląd z kamery MUSI być odbity w poziomie względem bieżącej orientacji urządzenia.

7.5.3. Aparat zewnętrzny

Implementacje na urządzeniach:

• MOŻE obejmować obsługę kamery zewnętrznej, która nie musi być zawsze podłączona.

Jeśli implementacje urządzeń obejmują obsługę kamery zewnętrznej:

• [C-1-1] MUSI zadeklarować flagi funkcji platformy android.hardware.camera.external i android.hardware camera.any.
• [C-1-2] MUSI obsługiwać klasę wideo USB (UVC 1.0 lub nowszą), jeśli kamera zewnętrzna łączy się przez port hosta USB.
• [C-1-3] MUSI przejść testy CTS kamery z podłączonym fizycznym zewnętrznym urządzeniem z kamerą. Szczegółowe informacje o testowaniu kamery w ramach CTS znajdziesz na stronie source.android.com.
• POWINNO obsługiwać kompresję wideo, np.MJPEG, aby umożliwić przesyłanie strumieni niekodowanych w wysokiej jakości (tj. strumieni obrazów surowych lub skompresowanych niezależnie).
• MOŻE obsługiwać wiele kamer.
• MOŻE obsługiwać kodowanie wideo oparte na kamerze.

Jeśli kodowanie wideo oparte na kamerze jest obsługiwane:

• [C-2-1] Urządzenie MUSI mieć dostęp do równoczesnego strumienia nieskompresowanego lub MJPEG (o rozdzielczości QVGA lub wyższej).

7.5.4. Działanie interfejsu Camera API

Android zawiera 2 pakiety interfejsów API do uzyskiwania dostępu do aparatu. Nowszy interfejs android.hardware.camera2 API udostępnia aplikacji kontrolę nad aparatem na niższym poziomie, w tym wydajne przepływy zdjęć seryjnych i strumieniowania bez kopiowania oraz sterowanie ekspozycją, wzmocnieniem, wzmocnieniem balansu bieli, konwersją kolorów, odszumianiem, wyostrzaniem i innymi parametrami w przypadku każdej klatki.

Starszy pakiet interfejsu API, android.hardware.Camera, jest oznaczony jako wycofany w Androidzie 5.0, ale POWINIEN być nadal dostępny do użycia w aplikacjach. Implementacje urządzeń z Androidem MUSZĄ zapewniać dalszą obsługę interfejsu API zgodnie z opisem w tej sekcji i w pakiecie Android SDK.

Wszystkie funkcje wspólne dla wycofanej klasy android.hardware.Camera i nowszego pakietu android.hardware.camera2 MUSZĄ mieć równoważną wydajność i jakość w obu interfejsach API. Na przykład przy równoważnych ustawieniach szybkość i dokładność autofokusa MUSZĄ być identyczne, a jakość zarejestrowanych obrazów MUSI być taka sama. Funkcje, które zależą od różnych semantyk obu interfejsów API, nie muszą mieć identycznej szybkości ani jakości, ale POWINNY być jak najbardziej zbliżone.

Implementacje urządzeń MUSZĄ obsługiwać te zachowania w przypadku interfejsów API związanych z aparatem dla wszystkich dostępnych aparatów. Implementacje na urządzeniach:

• [C-0-1] MUSI używać android.hardware.PixelFormat.YCbCr_420_SP w przypadku danych podglądu przekazywanych do wywołań zwrotnych aplikacji, gdy aplikacja nigdy nie wywołała funkcji android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] MUSI być w formacie kodowania NV21, gdy aplikacja rejestruje instancję android.hardware.Camera.PreviewCallback, a system wywołuje metodę onPreviewFrame(), a format podglądu to YCbCr_420_SP. Dane w tablicy byte[] przekazywanej do onPreviewFrame(). Oznacza to, że format NV21 MUSI być domyślny.
• [C-0-3] MUSI obsługiwać format YV12 (oznaczony stałą android.graphics.ImageFormat.YV12) w przypadku podglądu z kamery przedniej i tylnej na urządzeniach android.hardware.Camera. (Sprzętowy koder wideo i aparat mogą używać dowolnego natywnego formatu pikseli, ale implementacja urządzenia MUSI obsługiwać konwersję do formatu YV12).
• [C-0-4] MUSI obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe za pomocą interfejsu API android.media.ImageReader na android.hardware.camera2 urządzeniach, które reklamują funkcję REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE w android.request.availableCapabilities.
• [C-0-5] MUSI nadal implementować pełny interfejs Camera API zawarty w dokumentacji pakietu Android SDK, niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład kamery bez autofokusa MUSZĄ nadal wywoływać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback (nawet jeśli nie ma to znaczenia w przypadku kamery bez autofokusa). Pamiętaj, że dotyczy to aparatów przednich. Na przykład, mimo że większość aparatów przednich nie obsługuje autofokusa, wywołania zwrotne interfejsu API MUSZĄ być „symulowane” w opisany sposób.
• [C-0-6] MUSI rozpoznawać i uwzględniać każdą nazwę parametru zdefiniowaną jako stała w klasie android.hardware.Camera.Parameters i klasie android.hardware.camera2.CaptureRequest. Z kolei implementacje urządzeń NIE MOGĄ honorować ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters() innych niż te, które są udokumentowane jako stałe w android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry aparatu, jeśli pozwala na to sprzęt, i NIE MOGĄ obsługiwać niestandardowych typów parametrów aparatu. Na przykład implementacje urządzeń, które obsługują rejestrowanie obrazów z użyciem technik obrazowania o wysokim zakresie dynamiki (HDR), MUSZĄ obsługiwać parametr aparatu Camera.SCENE_MODE_HDR.
• [C-0-7] MUSI zgłaszać odpowiedni poziom obsługi za pomocą 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ć indywidualne możliwości kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i odpowiednich flag funkcji; MUSI zdefiniować flagę funkcji, jeśli którekolwiek z dołączonych urządzeń z kamerą obsługuje tę funkcję.
• [C-0-9] MUSI wysyłać intencję Camera.ACTION_NEW_PICTURE za każdym razem, gdy aparat zrobi nowe zdjęcie i zostanie ono dodane do magazynu multimediów.
• [C-0-10] MUSI wysyłać intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy kamera nagra nowy film, a wpis dotyczący zdjęcia zostanie dodany do magazynu multimediów.
• [C-0-11] WSZYSTKIE kamery dostępne za pomocą wycofanego interfejsu API android.hardware.Camera MUSZĄ być też dostępne za pomocą interfejsu API android.hardware.camera2.
• [C-SR] W przypadku urządzeń z kilkoma kamerami RGB skierowanymi w tym samym kierunku ZDECYDOWANIE ZALECA SIĘ obsługę logicznego urządzenia kamery, które zawiera funkcję CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA składającą się ze wszystkich kamer RGB skierowanych w tym kierunku jako urządzeń podrzędnych.

Jeśli implementacje urządzeń udostępniają aplikacjom innych firm zastrzeżony interfejs API aparatu, to:

• [C-1-1] MUSI implementować taki interfejs API aparatu za pomocą interfejsu android.hardware.camera2 API.
• MOŻE przekazywać tagi dostawcy lub rozszerzenia do interfejsu android.hardware.camera2 API.

7.5.5. Orientacja aparatu

Jeśli urządzenie ma aparat przedni lub tylny, to:

• [C-1-1] MUSI być zorientowana tak, aby dłuższy bok kamery był równoległy do dłuższego boku ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, kamery MUSZĄ rejestrować obrazy w orientacji poziomej. Dotyczy to wszystkich urządzeń, niezależnie od ich naturalnej orientacji, czyli zarówno urządzeń z orientacją poziomą, jak i pionową.

7.6. Pamięć i miejsce na dane

7.6.1. Minimalna ilość pamięci i miejsca na dane

Implementacje na urządzeniach:

• [C-0-1] MUSI zawierać menedżera pobierania, którego aplikacje MOGĄ używać do pobierania plików danych. Menedżer MUSI umożliwiać pobieranie pojedynczych plików o rozmiarze co najmniej 100 MB do domyślnej lokalizacji „pamięci podręcznej”.

7.6.2. Pamięć współdzielona aplikacji

Implementacje na urządzeniach:

• [C-0-1] MUSI oferować pamięć współdzieloną przez aplikacje, często nazywaną też „udostępnionym miejscem zewnętrznym”, „udostępnionym miejscem na dane aplikacji” lub ścieżką Linux „/sdcard”, na której jest zamontowana.
• [C-0-2] MUSI być skonfigurowane z domyślnie zamontowanym miejscem na dane współdzielone, czyli „od razu po wyjęciu z pudełka”, niezależnie od tego, czy miejsce na dane jest zaimplementowane w komponencie pamięci wewnętrznej, czy na wymiennym nośniku danych (np. gnieździe karty SD).
• [C-0-3] MUSI zamontować pamięć współdzieloną aplikacji bezpośrednio w ścieżce systemu Linux sdcard lub uwzględnić symboliczny link systemu Linux z sdcard do rzeczywistego punktu montowania.
• [C-0-4] MUSI wymuszać uprawnienia android.permission.WRITE_EXTERNAL_STORAGE w przypadku tej pamięci współdzielonej zgodnie z dokumentacją pakietu SDK.
• [C-0-5] MUSI domyślnie włączać pamięć o ograniczonym zakresie w przypadku wszystkich aplikacji kierowanych na interfejs API na poziomie 29 lub wyższym, z wyjątkiem tych sytuacji:
  • gdy aplikacja została zainstalowana przed uaktualnieniem urządzenia do poziomu interfejsu API 29, niezależnie od docelowego interfejsu API aplikacji.
  • gdy aplikacja zażąda android:requestLegacyExternalStorage="true" w swoim manifeście.
  • gdy aplikacja otrzyma uprawnienia z grupy android.permission.WRITE_MEDIA_STORAGE.
• [C-0-6] MUSI wymuszać, aby aplikacje z włączonym zakresem pamięci nie miały bezpośredniego dostępu do plików poza katalogami specyficznymi dla aplikacji, zwracanymi przez metody interfejsu API Context, takie jak Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() i Context.getObbDirs().
• [C-0-7] MUSI usuwać metadane lokalizacji, takie jak tagi EXIF GPS, przechowywane w plikach multimedialnych, gdy dostęp do tych plików jest uzyskiwany za pomocą MediaStore, z wyjątkiem sytuacji, gdy aplikacja wywołująca ma uprawnienie ACCESS_MEDIA_LOCATION.

Urządzenia MOGĄ spełniać powyższe wymagania w jeden z tych sposobów:

• Wymienna pamięć dostępna dla użytkownika, np. gniazdo karty SD.
• Część pamięci wewnętrznej (niewymiennej) zaimplementowanej w ramach Projektu Android Open Source (AOSP).

Jeśli implementacje urządzeń korzystają z pamięci wymiennej, aby spełnić powyższe wymagania:

• [C-1-1] MUSI implementować interfejs użytkownika w postaci wyskakującego okienka lub powiadomienia, które ostrzega użytkownika, gdy w gnieździe nie ma nośnika danych.
• [C-1-2] MUSI zawierać nośnik pamięci sformatowany w systemie FAT (np. kartę SD) lub informację na opakowaniu i innych materiałach dostępnych w momencie zakupu, że nośnik pamięci należy kupić osobno.

Jeśli implementacje urządzeń wykorzystują część pamięci trwałej do spełnienia powyższych wymagań:

• POWINNA korzystać z implementacji AOSP wewnętrznej pamięci współdzielonej aplikacji.
• MOŻE udostępniać miejsce na dane prywatnym danym aplikacji.

Jeśli implementacje urządzeń obejmują wiele ścieżek pamięci współdzielonej (np. gniazdo karty SD i współdzieloną pamięć wewnętrzną):

• [C-2-1] MUSI zezwalać na zapisywanie danych na dodatkowej pamięci zewnętrznej tylko wstępnie zainstalowanym i uprzywilejowanym aplikacjom na Androida z uprawnieniem WRITE_MEDIA_STORAGE, z wyjątkiem zapisywania danych w katalogach specyficznych dla pakietu lub w katalogu URI zwróconym przez wywołanie intencji ACTION_OPEN_DOCUMENT_TREE.
• [C-2-2] MUSI wymagać, aby bezpośredni dostęp powiązany z uprawnieniem android.permission.WRITE_MEDIA_STORAGE był przyznawany aplikacjom widocznym dla użytkownika tylko wtedy, gdy przyznane jest również uprawnienie android.permission.WRITE_EXTERNAL_STORAGE.
• [SR] ZDECYDOWANIE ZALECA się, aby fabrycznie zainstalowane i uprzywilejowane aplikacje na Androida korzystały z publicznych interfejsów API, takich jak MediaStore, do interakcji z urządzeniami pamięci masowej, zamiast polegać na bezpośrednim dostępie przyznawanym przez android.permission.WRITE_MEDIA_STORAGE.

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB:

• [C-3-1] MUSI udostępniać mechanizm dostępu do danych w pamięci współdzielonej aplikacji z komputera hosta.
• POWINNY udostępniać treści z obu ścieżek przechowywania w sposób przejrzysty za pomocą usługi skanera multimediów Androida i android.provider.MediaStore.
• MOŻE używać pamięci masowej USB, ale POWINIEN używać protokołu przesyłania multimediów, aby spełnić ten wymóg.

Jeśli implementacje urządzeń mają port USB z trybem urządzenia peryferyjnego USB i obsługują protokół przesyłania multimediów, to:

• POWINIEN być zgodny z referencyjnym hostem MTP Androida, czyli Android File Transfer.
• POWINIEN zgłaszać klasę urządzenia USB 0x00.
• POWINIEN zgłaszać nazwę interfejsu USB „MTP”.

7.6.3. Pamięć dostosowywana

Jeśli urządzenie ma być mobilne, w przeciwieństwie do telewizora, implementacje urządzenia są następujące:

• [SR] Zdecydowanie zalecamy wdrożenie pamięci adaptacyjnej w stabilnej lokalizacji, ponieważ przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

Jeśli port urządzenia pamięci wymiennej znajduje się w stabilnym miejscu, np. w komorze baterii lub pod inną osłoną ochronną, urządzenie:

• [SR] Zdecydowanie zalecamy wdrożenie pamięci dostosowywanej.

7.7. USB

Jeśli urządzenie ma port USB:

• POWINIEN obsługiwać tryb urządzenia peryferyjnego USB i tryb hosta USB.

7.7.1. Tryb urządzenia peryferyjnego USB

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb urządzenia peryferyjnego:

• [C-1-1] Port MUSI umożliwiać podłączenie do hosta USB ze standardowym portem USB typu A lub typu C.
• [C-1-2] MUSI zgłaszać prawidłową wartość iSerialNumber w standardowym deskryptorze urządzenia USB za pomocą android.os.Build.SERIAL.
• [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem rezystora typu C i MUSI wykrywać zmiany w reklamie, jeśli obsługuje USB typu C.
• [SR] Port powinien mieć format micro-B, micro-AB lub USB typu C. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z Androidem spełniały te wymagania, dzięki czemu będzie można je uaktualnić do przyszłych wersji platformy.
• [SR] Port powinien znajdować się na spodzie urządzenia (zgodnie z naturalną orientacją) lub umożliwiać obracanie ekranu we wszystkich aplikacjach (w tym na ekranie głównym), tak aby wyświetlacz był prawidłowo rysowany, gdy urządzenie jest zorientowane portem do dołu. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z Androidem spełniały te wymagania, dzięki czemu będzie można je uaktualnić do przyszłych wersji platformy.
• [SR] POWINIEN obsługiwać pobieranie prądu o natężeniu 1,5 A podczas sygnału HS i transmisji danych zgodnie ze specyfikacją USB Battery Charging, wersja 1.2. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z Androidem spełniały te wymagania, dzięki czemu będzie można je uaktualnić do przyszłych wersji platformy.
• [SR] ZDECYDOWANIE ZALECAMY, aby nie obsługiwać zastrzeżonych metod ładowania, które modyfikują napięcie Vbus poza domyślne poziomy lub zmieniają role odbiornika/źródła, ponieważ może to powodować problemy z interoperacyjnością z ładowarkami lub urządzeniami obsługującymi standardowe metody USB Power Delivery. Chociaż jest to „ZDECYDOWANIE ZALECANE”, w przyszłych wersjach Androida możemy WYMAGAĆ, aby wszystkie urządzenia ze złączem typu C obsługiwały pełną interoperacyjność ze standardowymi ładowarkami typu C.
• [SR] ZDECYDOWANIE ZALECANE jest obsługiwanie zasilania Power Delivery do zamiany ról danych i zasilania, jeśli obsługują one USB typu C i tryb hosta USB.
• POWINNY obsługiwać Power Delivery do ładowania wysokim napięciem oraz tryby alternatywne, takie jak wyjście wideo.
• POWINNO implementować interfejs Android Open Accessory (AOA) i specyfikację zgodnie z dokumentacją pakietu Android SDK.

Jeśli urządzenia mają port USB i są zgodne ze specyfikacją AOA:

• [C-2-1] MUSI deklarować obsługę funkcji sprzętowej android.hardware.usb.accessory.
• [C-2-2] Klasa pamięci masowej USB MUSI zawierać ciąg znaków „android” na końcu ciągu znaków iInterface opisu interfejsu pamięci masowej USB.

7.7.2. Tryb hosta USB

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta:

• [C-1-1] MUSI implementować interfejs Android USB host API zgodnie z dokumentacją w pakiecie Android SDK i MUSI deklarować obsługę funkcji sprzętowej android.hardware.usb.host.
• [C-1-2] MUSI obsługiwać połączenie standardowych urządzeń peryferyjnych USB, czyli MUSI:
  • mają port typu C lub są dostarczane z kablami, które umożliwiają podłączenie portu zastrzeżonego na urządzeniu do standardowego portu USB typu C (urządzenie USB typu C);
  • Musi mieć port typu A lub być dostarczany z kablami, które umożliwiają podłączenie portu zastrzeżonego na urządzeniu do standardowego portu USB typu A.
  • Musi mieć port micro-AB, do którego powinien być dołączony kabel z adapterem do standardowego portu typu A.
• [C-1-3] NIE MOŻE być dostarczany z adapterem konwertującym porty USB typu A lub micro-AB na port typu C (gniazdo).
• [C-SR] Zdecydowanie zaleca się wdrożenie klasy audio USB zgodnie z dokumentacją pakietu Android SDK.
• POWINNO obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta, reklamując prąd źródłowy o wartości co najmniej 1,5 A zgodnie z sekcją Parametry zakończenia w specyfikacji kabla i złącza USB typu C w wersji 1.2 w przypadku złączy USB typu C lub korzystając z zakresu prądu wyjściowego portu ładowania(CDP) zgodnie ze specyfikacjami ładowania baterii USB w wersji 1.2 w przypadku złączy Micro-AB.
• POWINNY wdrażać i obsługiwać standardy USB typu C.

Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i klasę audio USB:

• [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 zastosowań USB HID i żądaniu zastosowania polecenia głosowego na stałe wartości KeyEvent w sposób podany poniżej:
  • Strona użycia (0xC), identyfikator użycia (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Strona użycia (0xC), identyfikator użycia (0x0E9): KEYCODE_VOLUME_UP
  • Strona użycia (0xC), identyfikator użycia (0x0EA): KEYCODE_VOLUME_DOWN
  • Strona użycia (0xC), identyfikator użycia (0x0CF): KEYCODE_VOICE_ASSIST

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i Storage Access Framework (SAF):

• [C-3-1] MUSI rozpoznawać wszystkie urządzenia MTP (Media Transfer Protocol) połączone zdalnie i udostępniać ich zawartość 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 obsługiwać funkcję portu o podwójnej roli zgodnie ze specyfikacją USB Type-C (sekcja 4.5.1.3.3).
• [SR] Zdecydowanie zalecane jest obsługiwanie DisplayPort, zalecane jest obsługiwanie szybkości przesyłania danych USB SuperSpeed, a zdecydowanie zalecane jest obsługiwanie Power Delivery na potrzeby zamiany ról danych i zasilania.
• [SR] ZDECYDOWANIE ZALECANE jest NIEobsługiwanie trybu akcesoriów adaptera audio opisanego w dodatku A do specyfikacji kabla i złącza USB typu C w wersji 1.2.
• POWINIEN implementować model Try.*, który jest najbardziej odpowiedni dla danego formatu urządzenia. Na przykład urządzenie przenośne POWINNO implementować model Try.SNK.

7.8. Audio

7.8.1. Mikrofon

Jeśli urządzenie ma mikrofon:

• [C-1-1] MUSI zgłaszać stałą funkcji android.hardware.microphone.
• [C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku określone w sekcji 5.4.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku określone w sekcji 5.6.
• [SR] ZDECYDOWANIE ZALECANE jest obsługiwanie nagrywania w zakresie bliskim ultradźwiękom zgodnie z opisem w sekcji 7.8.3.

Jeśli urządzenie nie ma mikrofonu:

• [C-2-1] NIE MOŻE zgłaszać stałej funkcji android.hardware.microphone.
• [C-2-2] MUSI zaimplementować interfejs API nagrywania dźwięku przynajmniej jako operację bez efektu, zgodnie z sekcją 7.

7.8.2. Wyjście audio

Jeśli implementacje urządzeń obejmują głośnik lub port wyjściowy audio/multimedia dla urządzenia peryferyjnego wyjścia audio, takiego jak 4-żyłowe gniazdo słuchawek 3,5 mm lub port trybu hosta USB korzystający z klasy audio USB, to:

• [C-1-1] MUSI zgłaszać stałą funkcji android.hardware.audio.output.
• [C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku określone w sekcji 5.5.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku określone w sekcji 5.6.
• [SR] ZDECYDOWANIE ZALECANE jest obsługiwanie odtwarzania dźwięków o częstotliwości zbliżonej do ultradźwięków zgodnie z opisem w sekcji 7.8.3.

Jeśli urządzenie nie ma głośnika ani portu wyjścia audio:

• [C-2-1] NIE MOŻE zgłaszać funkcji android.hardware.audio.output.
• [C-2-2] MUSI implementować interfejsy API związane z wyjściem audio jako operacje bez efektu.

Na potrzeby tej sekcji „port wyjściowy” to fizyczny interfejs, taki jak gniazdo audio 3, 5 mm, HDMI lub port hosta USB z klasą audio USB. Obsługa wyjścia audio za pomocą protokołów radiowych, takich jak Bluetooth, Wi-Fi lub sieć komórkowa, nie jest traktowana jako „port wyjściowy”.

7.8.2.1. Analogowe porty audio

Aby zapewnić zgodność z zestawami słuchawkowymi i innymi akcesoriami audio korzystającymi z wtyczki audio 3,5 mm w ekosystemie Androida, jeśli implementacje urządzeń obejmują co najmniej 1 analogowy port audio, muszą:

• [C-SR] Zdecydowanie zaleca się, aby co najmniej jedno gniazdo audio było 4-żyłowym gniazdem słuchawkowym 3,5 mm.

Jeśli urządzenia mają 4-żyłowe gniazdo audio 3, 5 mm:

• [C-1-1] MUSI obsługiwać odtwarzanie dźwięku na słuchawkach stereo i zestawach słuchawkowych stereo z mikrofonem.
• [C-1-2] MUSI obsługiwać wtyczki audio TRRS z układem pinów CTIA.
• [C-1-3] MUSI obsługiwać wykrywanie i mapowanie na kody klawiszy w przypadku tych 3 zakresów równoważnej impedancji między mikrofonem a przewodnikami uziemiającymi na wtyczce audio:
  • 70 omów lub mniej: KEYCODE_HEADSETHOOK
  • 210–290 omów: KEYCODE_VOLUME_UP
  • 360–680 omów: KEYCODE_VOLUME_DOWN
• [C-1-4] MUSI wywoływać zdarzenie ACTION_HEADSET_PLUG po włożeniu wtyczki, ale tylko wtedy, gdy wszystkie styki wtyczki dotykają odpowiednich segmentów gniazda.
• [C-1-5] MUSI być w stanie zapewnić napięcie wyjściowe o wartości co najmniej 150 mV ± 10% przy impedancji głośnika 32 omy.
• [C-1-6] MUSI mieć napięcie polaryzacji mikrofonu w zakresie 1,8–2,9 V.
• [C-1-7] MUSI wykrywać i mapować na kod klucza następujący zakres równoważnej impedancji między mikrofonem a przewodami uziemiającymi na wtyczce audio:
  • 110–180 omów: KEYCODE_VOICE_ASSIST
• [C-SR] Zdecydowanie zalecane jest obsługiwanie wtyczek audio z układem pinów OMTP.
• [C-SR] Zdecydowanie zalecane jest obsługiwanie nagrywania dźwięku ze stereofonicznych zestawów słuchawkowych z mikrofonem.

Jeśli implementacje urządzeń mają 4-żyłowe gniazdo słuchawek 3, 5 mm i obsługują mikrofon oraz emitują wartość android.intent.action.HEADSET_PLUG z dodatkową wartością mikrofonu ustawioną na 1, to:

• [C-2-1] MUSI obsługiwać wykrywanie mikrofonu w podłączonym akcesorium audio.

7.8.2.2. Cyfrowe porty audio

Aby zapewnić zgodność z zestawami słuchawkowymi i innymi akcesoriami audio korzystającymi ze złączy USB-C i implementującymi (klasę audio USB) w ekosystemie Androida zgodnie ze specyfikacją Android USB headset specification.

Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.2.1.

7.8.3. Dźwięki zbliżone do ultradźwięków

Dźwięk w zakresie bliskim ultradźwiękom to pasmo od 18,5 kHz do 20 kHz.

Implementacje na urządzeniach:

• MUSI prawidłowo zgłaszać obsługę dźwięku w zakresie bliskim ultradźwiękom za pomocą interfejsu AudioManager.getProperty API w ten sposób:

Jeśli wartość PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND to „true”, źródła dźwięku VOICE_RECOGNITION i UNPROCESSED MUSZĄ spełniać te wymagania:

• [C-1-1] Średnia charakterystyka mocy mikrofonu w zakresie od 18,5 kHz do 20 kHz MUSI być nie więcej niż o 15 dB niższa niż charakterystyka przy 2 kHz.
• [C-1-2] Nieważony stosunek sygnału do szumu mikrofonu w zakresie od 18,5 kHz do 20 kHz dla tonu o częstotliwości 19 kHz przy poziomie -26 dBFS MUSI wynosić co najmniej 50 dB.

Jeśli PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „true”:

• [C-2-1] Średnia odpowiedź głośnika w zakresie 18,5 kHz–20 kHz MUSI być nie niższa niż 40 dB poniżej odpowiedzi przy 2 kHz.

7.8.4. Integralność sygnału

Implementacje na urządzeniach:

• POWINNY zapewniać ścieżkę sygnału audio bez zakłóceń zarówno w przypadku strumieni wejściowych, jak i wyjściowych na urządzeniach przenośnych, zgodnie z definicją zerowych zakłóceń zmierzonych podczas jednominutowego testu każdej ścieżki. Przeprowadź test za pomocą [OboeTestera] (https://github.com/google/oboe/tree/master/apps/OboeTester) „Automated Glitch Test”.

Test wymaga klucza sprzętowego do testowania dźwięku, który jest używany bezpośrednio w gnieździe 3,5 mm lub w połączeniu z przejściówką USB-C na 3,5 mm. Należy przetestować wszystkie porty wyjścia audio.

OboeTester obsługuje obecnie ścieżki AAudio, więc w przypadku tych kombinacji NALEŻY przetestować występowanie zakłóceń za pomocą AAudio:

Niezawodny strumień POWINIEN spełniać te kryteria dotyczące stosunku sygnału do szumu (SNR) i całkowitych zniekształceń harmonicznych (THD) dla sinusa o częstotliwości 2000 Hz.

7.9. Rzeczywistość wirtualna

Android zawiera interfejsy API i narzędzia do tworzenia aplikacji w technologii wirtualnej rzeczywistości (VR), w tym wysokiej jakości aplikacji VR na urządzenia mobilne. Implementacje urządzeń MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z opisem w tej sekcji.

7.9.1. Tryb rzeczywistości wirtualnej

Android obsługuje tryb VR, czyli funkcję, która odpowiada za stereoskopowe renderowanie powiadomień i wyłączanie monokularnych komponentów interfejsu systemu, gdy użytkownik korzysta z aplikacji VR.

7.9.2. Tryb rzeczywistości wirtualnej – wysoka wydajność

Jeśli urządzenia 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 stałej wydajności.
• [C-1-4] MUSI obsługiwać OpenGL ES 3.2.
• [C-1-5] MUSI obsługiwać android.hardware.vulkan.level 0.
• POWINIEN obsługiwać android.hardware.vulkan.level w wersji 1 lub nowszej.
• [C-1-6] MUSI implementować rozszerzenia EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace i udostępniać je na liście dostępnych rozszerzeń EGL.
• [C-1-8] MUSI implementować GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures i udostępniać rozszerzenia na liście dostępnych rozszerzeń GL.
• [C-SR] Zdecydowanie zaleca się wdrożenie GL_EXT_external_buffer, GL_EXT_EGL_image_array i udostępnienie rozszerzeń na liście dostępnych rozszerzeń GL.
• [C-SR] Zdecydowanie zaleca się obsługę interfejsu Vulkan 1.1.
• [C-SR] Zdecydowanie zaleca się wdrożenie VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image i udostępnienie go na liście dostępnych rozszerzeń Vulkan.
• [C-SR] Zdecydowanie zaleca się udostępnienie co najmniej 1 rodziny kolejek Vulkan, w której flags zawiera zarówno VK_QUEUE_GRAPHICS_BIT, jak i VK_QUEUE_COMPUTE_BIT, a queueCount wynosi co najmniej 2.
• [C-1-7] Procesor graficzny i wyświetlacz MUSZĄ być w stanie zsynchronizować dostęp do wspólnego bufora przedniego, tak aby renderowanie treści VR w trybie naprzemiennym dla każdego oka z częstotliwością 60 klatek na sekundę w 2 kontekstach renderowania było wyświetlane bez widocznych artefaktów rozrywania obrazu.
• [C-1-9] MUSI obsługiwać flagi 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 obsługiwać AHardwareBuffer z dowolną kombinacją flag użycia AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, 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 zaleca się obsługę przydzielania AHardwareBuffer z więcej niż jedną warstwą oraz flag i formatów określonych w C-1-10.
• [C-1-11] MUSI obsługiwać dekodowanie H.264 w rozdzielczości co najmniej 3840 x 2160 przy 30 kl./s, skompresowane do średniej wartości 40 Mb/s (co odpowiada 4 instancjom 1920 x 1080 przy 30 kl./s – 10 Mb/s lub 2 instancjom 1920 x 1080 przy 60 kl./s – 20 Mb/s).
• [C-1-12] MUSI obsługiwać HEVC i VP9, MUSI być w stanie dekodować co najmniej 1920 x 1080 przy 30 kl./s skompresowane do średnio 10 Mb/s i POWINIEN być w stanie dekodować 3840 x 2160 przy 30 kl./s i 20 Mb/s (co odpowiada 4 instancjom 1920 x 1080 przy 30 kl./s i 5 Mb/s).
• [C-1-13] MUSI obsługiwać 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.
• [C-SR] Zdecydowanie zalecamy, aby miały rozdzielczość co najmniej 2560 x 1440.
• [C-1-15] Wyświetlacz MUSI odświeżać obraz z częstotliwością co najmniej 60 Hz w trybie VR.
• [C-1-17] Wyświetlacz MUSI obsługiwać tryb niskiej trwałości z trwałością ≤ 5 milisekund. Trwałość to czas, przez jaki piksel emituje światło.
• [C-1-18] MUSI obsługiwać Bluetooth 4.2 i rozszerzenie długości danych Bluetooth LE (sekcja 7.4.3).
• [C-1-19] MUSI obsługiwać i prawidłowo raportować Direct Channel Type 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 zalecamy obsługę typu kanału bezpośredniego TYPE_HARDWARE_BUFFER dla wszystkich typów kanałów bezpośrednich wymienionych powyżej.
• [C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru w przypadku android.hardware.hifi_sensors, zgodnie z sekcją 7.3.9.
• [C-SR] są ZDECYDOWANIE ZALECANE do obsługi funkcji android.hardware.sensor.hifi_sensors.
• [C-1-22] MUSI mieć opóźnienie od ruchu do fotonu nie większe niż 28 milisekund.
• [C-SR] ZDECYDOWANIE ZALECA się, aby opóźnienie od ruchu do fotonu nie przekraczało 20 milisekund.
• [C-1-23] MUSI mieć współczynnik pierwszej klatki, czyli stosunek jasności pikseli w pierwszej klatce po przejściu z czerni do bieli do jasności białych pikseli w stanie ustalonym, wynoszący co najmniej 85%.
• [C-SR] Zdecydowanie zalecamy, aby współczynnik pierwszej klatki wynosił co najmniej 90%.
• MOŻE udostępniać wyłączny rdzeń aplikacji na pierwszym planie i MOŻE obsługiwać interfejs Process.getExclusiveCores API, aby zwracać numery rdzeni procesora, które są wyłączne dla aplikacji na pierwszym planie.

Jeśli dedykowany rdzeń jest obsługiwany, to:

• [C-2-1] NIE MOŻE zezwalać na uruchamianie na nim żadnych innych procesów przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE zezwalać na uruchamianie niektórych procesów jądra, jeśli jest to konieczne.

8. Wydajność i moc

Niektóre minimalne kryteria wydajności i mocy mają kluczowe znaczenie dla wrażeń użytkowników i wpływają na podstawowe założenia, które deweloperzy przyjmują podczas tworzenia aplikacji.

8.1. Spójność interfejsu użytkownika

Płynny interfejs użytkownika można zapewnić użytkownikowi końcowemu, jeśli spełnione są określone minimalne wymagania, które gwarantują stałą liczbę klatek na sekundę i czas reakcji aplikacji i gier. Wdrożenia na urządzeniach, w zależności od typu urządzenia, MOGĄ mieć mierzalne wymagania dotyczące opóźnienia interfejsu użytkownika i przełączania zadań, jak opisano w sekcji 2.

8.2. Wydajność dostępu do wejścia/wyjścia plików

Zapewnienie wspólnego punktu odniesienia dla spójnej wydajności dostępu do plików w prywatnym obszarze pamięci danych aplikacji (partycja /data) umożliwia deweloperom aplikacji określenie odpowiednich oczekiwań, które pomogą im w projektowaniu oprogramowania. Wdrożenia urządzeń, w zależności od typu urządzenia, MOGĄ mieć określone wymagania opisane w sekcji 2 w przypadku tych operacji odczytu i zapisu:

• Szybkość zapisu sekwencyjnego Pomiar wykonany podczas zapisywania pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
• Wydajność zapisu losowego Pomiar polega na zapisaniu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.
• Szybkość odczytu sekwencyjnego Pomiar wykonany podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
• Wydajność odczytu losowego Pomiar wykonany podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.

8.3. Tryby oszczędzania energii

Jeśli implementacje urządzeń zawierają funkcje poprawiające zarządzanie energią urządzenia, które są uwzględnione w AOSP lub rozszerzają funkcje uwzględnione w AOSP:

• [C-1-1] NIE MOŻE odbiegać od implementacji AOSP w zakresie algorytmów wywoływania, konserwacji i wybudzania oraz korzystania z globalnych ustawień systemowych trybów oszczędzania energii w przypadku gotowości aplikacji i uśpienia.
• [C-1-2] NIE MOŻE odbiegać od implementacji AOSP w zakresie używania ustawień globalnych do zarządzania ograniczaniem zadań, alarmów i sieci w przypadku aplikacji w każdym koszyku w trybie gotowości aplikacji.
• [C-1-3] NIE MOŻE odbiegać od implementacji AOSP w zakresie liczby zasobników gotowości aplikacji używanych w przypadku gotowości aplikacji.
• [C-1-4] MUSI implementować zasobniki gotowości aplikacji i tryb uśpienia zgodnie z opisem w sekcji Zarządzanie energią.
• [C-1-5] MUSI zwracać true dla PowerManager.isPowerSaveMode(), gdy urządzenie jest w trybie oszczędzania energii.
• [C-SR] Zdecydowanie zaleca się udostępnienie użytkownikowi możliwości włączania i wyłączania funkcji oszczędzania baterii.
• [C-SR] ZDECYDOWANIE ZALECA SIĘ udostępnienie użytkownikowi możliwości wyświetlania wszystkich aplikacji zwolnionych z trybów oszczędzania energii „Aplikacja w trybie gotowości” i „Drzemka”.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ implementować dowolne lub wszystkie 4 stany uśpienia zdefiniowane przez interfejs ACPI (Advanced Configuration and Power Interface).

Jeśli implementacje urządzeń obsługują stany zasilania S4 zdefiniowane przez ACPI:

• [C-1-1] MUSI przejść w ten stan tylko wtedy, gdy użytkownik wykona wyraźną czynność, aby wprowadzić urządzenie w stan nieaktywny (np. zamknie pokrywę, która jest fizycznie częścią urządzenia, lub wyłączy pojazd lub telewizor), i zanim ponownie aktywuje urządzenie (np. otworzy pokrywę lub ponownie włączy pojazd lub telewizor).

Jeśli implementacje urządzeń obsługują stany zasilania S3 zdefiniowane przez ACPI:

• [C-2-1] MUSI spełniać wymagania C-1-1 powyżej LUB MUSI przechodzić w stan S3 tylko wtedy, gdy aplikacje innych firm nie potrzebują zasobów systemowych (np. ekranu, procesora).

  Z kolei MUSI wyjść ze stanu S3, gdy aplikacje innych firm potrzebują zasobów systemowych, jak opisano w tym pakiecie SDK.

  Na przykład, gdy aplikacje innych firm żądają utrzymania włączonego ekranu za pomocą FLAG_KEEP_SCREEN_ON lub utrzymania działania procesora za pomocą PARTIAL_WAKE_LOCK, urządzenie NIE MOŻE przejść w stan S3, chyba że użytkownik wykonał wyraźną czynność, aby wprowadzić urządzenie w stan nieaktywny, zgodnie z opisem w sekcji C-1-1. Z kolei w momencie, gdy zadanie zaimplementowane przez aplikacje innych firm za pomocą JobScheduler zostanie wywołane lub gdy Komunikacja w chmurze Firebase zostanie dostarczona do aplikacji innych firm, urządzenie MUSI wyjść ze stanu S3, chyba że użytkownik wprowadził je w stan nieaktywności. To nie są wyczerpujące przykłady. AOSP implementuje wiele sygnałów wybudzania, które wywołują wybudzenie z tego stanu.

8.4. Rozliczanie zużycia energii

Dokładniejsze rozliczanie i raportowanie zużycia energii daje deweloperowi aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorca zużycia energii przez aplikację.

Implementacje na urządzeniach:

• [SR] Zdecydowanie zalecamy podanie profilu zasilania poszczególnych komponentów, który określa wartość zużycia prądu dla każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source Project.
• [SR] Zdecydowanie zalecamy podawanie wszystkich wartości zużycia energii w miliamperogodzinach (mAh).
• [SR] ZDECYDOWANIE ZALECANE jest raportowanie zużycia energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [SR] ZDECYDOWANIE ZALECANE jest udostępnienie deweloperowi aplikacji informacji o zużyciu energii za pomocą polecenia powłoki adb shell dumpsys batterystats.
• Jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji, należy przypisać je do samego komponentu.

8.5. Stabilna wydajność

W przypadku długo działających aplikacji o wysokiej wydajności wydajność może się znacznie wahać z powodu innych aplikacji działających w tle lub ograniczenia mocy procesora ze względu na limity temperatury. Android zawiera interfejsy programowe, dzięki którym w razie potrzeby aplikacja na pierwszym planie może poprosić system o zoptymalizowanie przydziału zasobów w celu poradzenia sobie z takimi wahaniami.

Implementacje na urządzeniach:

• [C-0-1] MUSI dokładnie zgłaszać obsługę trybu stałej wydajności za pomocą metody interfejsu PowerManager.isSustainedPerformanceModeSupported() API.

• POWINIEN obsługiwać tryb stałej wydajności.

Jeśli implementacje urządzeń zgłaszają obsługę trybu stałej wydajności:

• [C-1-1] MUSI zapewniać aplikacji na pierwszym planie stały poziom wydajności przez co najmniej 30 minut, gdy aplikacja tego wymaga.
• [C-1-2] MUSI obsługiwać interfejs Window.setSustainedPerformanceMode() API i inne powiązane interfejsy API.

Jeśli implementacje urządzeń obejmują co najmniej 2 rdzenie procesora, muszą:

• POWINIEN udostępniać co najmniej 1 wyłączny rdzeń, który może być zarezerwowany przez aplikację działającą na pierwszym planie.

Jeśli implementacje urządzeń obsługują rezerwowanie jednego rdzenia na wyłączność dla aplikacji działającej na pierwszym planie, to:

• [C-2-1] MUSI zgłaszać za pomocą metody interfejsu API Process.getExclusiveCores() numery identyfikacyjne wyłącznych rdzeni, które mogą być zarezerwowane przez aplikację na pierwszym planie.
• [C-2-2] NIE MOŻE zezwalać na uruchamianie na wyłącznych rdzeniach żadnych procesów przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację, ale MOŻE zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.

Jeśli implementacje urządzeń nie obsługują wyłącznego rdzenia, to:

• [C-3-1] MUSI zwracać pustą listę za pomocą metody interfejsu Process.getExclusiveCores() API.

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniach:

• [C-0-1] MUSI wdrażać model bezpieczeństwa zgodny z modelem bezpieczeństwa platformy Android zdefiniowanym w dokumencie referencyjnym dotyczącym bezpieczeństwa i uprawnień w interfejsach API w dokumentacji dla deweloperów Androida.

• [C-0-2] MUSI obsługiwać instalację aplikacji podpisanych samodzielnie bez konieczności uzyskiwania dodatkowych uprawnień lub certyfikatów od osób trzecich lub organów. W szczególności zgodne urządzenia MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w kolejnych podsekcjach.

9.1. Uprawnienia

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać model uprawnień Androida zdefiniowany w dokumentacji dla deweloperów Androida. W szczególności MUSZĄ egzekwować każde uprawnienie zdefiniowane zgodnie z opisem w dokumentacji pakietu SDK. Nie można pomijać, zmieniać ani ignorować żadnych uprawnień.

• MOŻE dodawać dodatkowe uprawnienia, pod warunkiem że nowe ciągi identyfikatorów uprawnień nie znajdują się w przestrzeni nazw android.\*.

• [C-0-2] Uprawnienia z wartością protectionLevel PROTECTION_FLAG_PRIVILEGED MUSZĄ być przyznawane tylko aplikacjom preinstalowanym w ścieżkach uprzywilejowanych obrazu systemu i w podzbiorze uprawnień wyraźnie dodanych do listy dozwolonych dla każdej aplikacji. Implementacja AOSP spełnia to wymaganie, odczytując i uwzględniając uprawnienia dodane do listy dozwolonych dla każdej aplikacji z plików w ścieżce etc/permissions/ i używając ścieżki system/priv-app jako ścieżki uprzywilejowanej.

Uprawnienia o poziomie ochrony „niebezpieczne” to uprawnienia czasu działania. Aplikacje z wartością targetSdkVersion > 22 wysyłają żądania w czasie działania.

Implementacje na urządzeniach:

• [C-0-3] MUSI wyświetlać specjalny interfejs, w którym użytkownik może zdecydować, czy przyznać żądane uprawnienia w czasie działania, a także interfejs do zarządzania tymi uprawnieniami.
• [C-0-4] MUSI mieć tylko jedną implementację obu interfejsów użytkownika.
• [C-0-5] NIE WOLNO przyznawać żadnych uprawnień przy uruchamianiu preinstalowanym aplikacjom, chyba że:
  • Zgodę użytkownika można uzyskać przed użyciem aplikacji.
  • Uprawnienia w czasie działania są powiązane z wzorcem intencji, dla którego preinstalowana aplikacja jest ustawiona jako domyślny moduł obsługi.
• [C-0-6] MUSI przyznawać uprawnienia android.permission.RECOVER_KEYSTORE tylko aplikacjom systemowym, które rejestrują odpowiednio zabezpieczonego agenta odzyskiwania. Odpowiednio zabezpieczony agent odzyskiwania to agent oprogramowania na urządzeniu, który synchronizuje się ze zdalnym magazynem poza urządzeniem i jest wyposażony w bezpieczny sprzęt z ochroną równoważną lub silniejszą niż opisana w usłudze Google Cloud Key Vault, aby zapobiegać atakom siłowym na składnik wiedzy dotyczący ekranu blokady.

Implementacje na urządzeniach:

• [C-0-7] MUSI przestrzegać właściwości uprawnień do lokalizacji w Androidzie, gdy aplikacja prosi o dane o lokalizacji lub aktywności fizycznej za pomocą standardowego interfejsu API Androida lub mechanizmu własnego. Dane te obejmują m.in.:

  • Lokalizacja urządzenia (np. szerokość i długość geograficzna).
  • Informacje, które mogą być używane do określania lub szacowania lokalizacji urządzenia (np. identyfikator SSID, BSSID, identyfikator komórki, skanowanie Bluetootha lub lokalizacja sieci, z którą połączone jest urządzenie).
  • aktywność fizyczna użytkownika lub jej klasyfikacja;

W szczególności implementacje urządzeń:

• [C-0-8] MUSI uzyskać zgodę użytkownika na dostęp aplikacji do danych o lokalizacji lub aktywności fizycznej.
• [C-0-9] MUSI przyznawać uprawnienia w czasie działania TYLKO aplikacji, która ma wystarczające uprawnienia zgodnie z opisem w pakiecie SDK. Na przykład TelephonyManager#getServiceState wymaga uprawnienia android.permission.ACCESS_FINE_LOCATION).

Uprawnienia można oznaczyć jako ograniczone, co zmieni 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 przyznaje hardRestricted aplikacji.
  • Aplikacja otrzymuje uprawnienie hardRestricted we wcześniejszej wersji Androida.

• [C-0-11] Aplikacje z uprawnieniami softRestricted MUSZĄ mieć tylko ograniczony dostęp i NIE MOGĄ uzyskać pełnego dostępu, dopóki nie zostaną dodane do listy dozwolonych zgodnie z opisem w pakiecie SDK, w którym zdefiniowano pełny i ograniczony dostęp dla każdego uprawnienia softRestricted (np. WRITE_EXTERNAL_STORAGE i READ_EXTERNAL_STORAGE).

Jeśli implementacje urządzeń obejmują wstępnie zainstalowaną aplikację lub chcą zezwolić aplikacjom innych firm na dostęp do statystyk użytkowania:

• [SR] Zdecydowanie zalecamy, aby aplikacje, które deklarują uprawnienie android.permission.PACKAGE_USAGE_STATS, udostępniały użytkownikom mechanizm przyznawania lub cofania dostępu do statystyk użytkowania w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Jeśli implementacje urządzeń mają uniemożliwiać dostęp do statystyk użycia wszystkim aplikacjom, w tym aplikacjom wstępnie zainstalowanym:

• [C-1-1] MUSI nadal mieć aktywność, która obsługuje wzorzec intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale MUSI implementować go jako operację bez efektu, czyli zachowywać się tak, jakby użytkownikowi odmówiono dostępu.

9.2. Identyfikator 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 jest uruchamiana jako unikalny identyfikator UID w stylu systemu Unix i w osobnym procesie.
• [C-0-2] MUSI obsługiwać uruchamianie wielu aplikacji z tym samym identyfikatorem użytkownika systemu Linux, pod warunkiem że aplikacje są prawidłowo podpisane i zbudowane zgodnie z definicją w dokumentacji dotyczącej bezpieczeństwa i uprawnień.

9.3. Uprawnienia do systemu plików

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać model uprawnień dostępu do plików na Androidzie zgodnie z opisem w dokumentacji dotyczącej bezpieczeństwa i uprawnień.

9.4. Alternatywne środowiska wykonawcze

Implementacje urządzeń MUSZĄ zachowywać spójność modelu zabezpieczeń i uprawnień Androida, nawet jeśli zawierają środowiska wykonawcze, które uruchamiają aplikacje przy użyciu 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 muszą być zgodne ze standardowym modelem zabezpieczeń Androida, jak opisano w sekcji 9.

• [C-0-2] Alternatywne środowiska wykonawcze NIE MOGĄ mieć dostępu do zasobów chronionych przez uprawnienia, o które nie poproszono w pliku AndroidManifest.xml środowiska wykonawczego za pomocą mechanizmu <uses-permission>.

• [C-0-3] Alternatywne środowiska wykonawcze NIE MOGĄ zezwalać aplikacjom na korzystanie z funkcji chronionych przez uprawnienia Androida, które są ograniczone do aplikacji systemowych.

• [C-0-4] Alternatywne środowiska wykonawcze MUSZĄ być zgodne z modelem piaskownicy Androida, a zainstalowane aplikacje korzystające z alternatywnego środowiska wykonawczego NIE MOGĄ ponownie używać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida, takich jak udostępniony identyfikator użytkownika i certyfikat podpisu.

• [C-0-5] Alternatywne środowiska wykonawcze NIE MOGĄ uruchamiać piaskownic odpowiadających innym aplikacjom na Androida ani przyznawać do nich dostępu.

• [C-0-6] Alternatywne środowiska wykonawcze NIE MOGĄ być uruchamiane z uprawnieniami superużytkownika (root) ani żadnego innego identyfikatora użytkownika, ani nie mogą przyznawać takich uprawnień innym aplikacjom.

• [C-0-7] Jeśli w obrazie systemu implementacji urządzenia znajdują się pliki .apk alternatywnych środowisk wykonawczych, MUSZĄ one być podpisane kluczem innym niż klucz używany do podpisywania innych aplikacji dołączonych do implementacji urządzenia.

• [C-0-8] Podczas instalowania aplikacji alternatywne środowiska wykonawcze MUSZĄ uzyskiwać zgodę użytkownika na uprawnienia Androida używane przez aplikację.

• [C-0-9] Gdy aplikacja musi użyć zasobu urządzenia, dla którego istnieje odpowiednie uprawnienie Androida (np. aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI poinformować użytkownika, że aplikacja będzie mogła uzyskać dostęp do tego zasobu.

• [C-0-10] Jeśli środowisko wykonawcze nie rejestruje możliwości aplikacji w ten sposób, podczas instalowania dowolnej aplikacji za pomocą tego środowiska wykonawczego MUSI ono wyświetlać listę wszystkich uprawnień, które posiada.

• Alternatywne środowiska wykonawcze POWINNY instalować aplikacje za pomocą PackageManager w oddzielnych piaskownicach Androida (identyfikatory użytkowników Linuxa itp.).

• Alternatywne środowiska wykonawcze MOGĄ udostępniać jedną piaskownicę Androida współdzieloną przez wszystkie aplikacje korzystające z tego środowiska.

9.5. Obsługa wielu użytkowników

Android obsługuje wielu użytkowników i zapewnia pełną izolację użytkowników.

• Urządzenia MOGĄ, ale NIE POWINNY włączać obsługi wielu użytkowników, jeśli jako podstawową pamięć zewnętrzną wykorzystują nośniki wymienne.

Jeśli implementacje urządzeń obejmują wielu użytkowników:

• [C-1-1] MUSI spełniać te wymagania dotyczące obsługi wielu użytkowników.
• [C-1-2] MUSI w przypadku każdego użytkownika w interfejsach API wdrażać model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android zdefiniowanym w dokumencie referencyjnym dotyczącym zabezpieczeń i uprawnień.
• [C-1-3] MUSI mieć oddzielne i odizolowane katalogi współdzielonego miejsca na aplikacje (tzw. /sdcard) dla każdej instancji użytkownika.
• [C-1-4] MUSI zapewniać, ż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 innego użytkownika, nawet jeśli dane obu użytkowników są przechowywane na tym samym woluminie lub w tym samym systemie plików.
• [C-1-5] MUSI szyfrować zawartość karty SD, gdy włączona jest funkcja wielu użytkowników, za pomocą klucza przechowywanego tylko na nośniku niewymiennym, do którego dostęp ma tylko system, jeśli implementacje urządzeń używają nośników wymiennych w przypadku interfejsów API pamięci zewnętrznej. Spowoduje to, że nośnik będzie nieczytelny dla komputera hosta, więc implementacje urządzeń będą musiały przełączyć się na MTP lub podobny system, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika.

9.6. Ostrzeżenie dotyczące SMS-ów specjalnych

Android obsługuje ostrzeganie użytkowników o wszystkich wychodzących SMS-ach premium. SMS-y specjalne to wiadomości tekstowe wysyłane do usługi zarejestrowanej u operatora, za które użytkownik może ponosić opłaty.

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

• [C-1-1] MUSI ostrzegać użytkowników przed wysłaniem SMS-a na numery zidentyfikowane przez wyrażenia regularne zdefiniowane w pliku /data/misc/sms/codes.xml na urządzeniu. Projekt Android Open Source udostępnia implementację, która spełnia to wymaganie.

9.7. Funkcje zabezpieczeń

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń zarówno w jądrze, jak i na platformie, zgodnie z opisem poniżej.

Piaskownica Androida zawiera funkcje, które korzystają z systemu obowiązkowej kontroli dostępu (MAC) Security-Enhanced Linux (SELinux), piaskownicy seccomp i innych funkcji zabezpieczeń w jądrze systemu Linux. Implementacje na urządzeniach:

• [C-0-1] MUSI zachowywać zgodność z istniejącymi aplikacjami, nawet jeśli SELinux lub inne funkcje zabezpieczeń są zaimplementowane poniżej platformy Androida.
• [C-0-2] NIE MOŻE mieć widocznego interfejsu użytkownika, gdy wykryte zostanie naruszenie bezpieczeństwa i zostanie ono skutecznie zablokowane przez funkcję zabezpieczeń zaimplementowaną poniżej struktury Androida, ale MOŻE mieć widoczny interfejs użytkownika, gdy wystąpi niezablokowane naruszenie bezpieczeństwa, które doprowadzi do skutecznego wykorzystania luki.
• [C-0-3] NIE MOŻE udostępniać użytkownikowi ani deweloperowi aplikacji możliwości konfigurowania SELinux ani żadnych innych funkcji zabezpieczeń zaimplementowanych 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 (np. interfejsu Device Administration API), na konfigurowanie zasad, które powodują utratę zgodności.
• [C-0-5] MUSI podzielić platformę multimedialną na wiele procesów, aby można było bardziej precyzyjnie przyznawać dostęp do każdego z nich, jak opisano na stronie projektu Android Open Source.
• [C-0-6] MUSI implementować mechanizm piaskownicy aplikacji w jądrze, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnych zasad w programach wielowątkowych. Projekt Android Open Source spełnia to wymaganie, umożliwiając seccomp-BPF z synchronizacją grupy wątków (TSYNC), jak opisano w sekcji Konfiguracja jądra na stronie source.android.com.

Integralność jądra i funkcje samoobrony są nieodłączną częścią zabezpieczeń Androida. Implementacje na urządzeniach:

• [C-0-7] MUSI implementować mechanizmy ochrony przed przepełnieniem bufora stosu jądra. Przykładami takich mechanizmów są CC_STACKPROTECTOR_REGULAR i CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] MUSI wdrażać ścisłą ochronę pamięci jądra, w której kod wykonywalny jest tylko do odczytu, dane tylko do odczytu nie są wykonywalne ani zapisywalne, a dane zapisywalne nie są wykonywalne (np. CONFIG_DEBUG_RODATA lub CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] MUSI implementować statyczne i dynamiczne sprawdzanie rozmiaru obiektów kopiowanych między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY) na urządzeniach, które pierwotnie były dostarczane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-10] NIE MOŻE wykonywać pamięci przestrzeni użytkownika podczas wykonywania w trybie jądra (np. sprzętowy PXN lub emulowany za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które pierwotnie były dostarczane z poziomem interfejsu API 28 lub wyższym.
• [C-0-11] NIE WOLNO odczytywać ani zapisywać pamięci przestrzeni użytkownika w jądrze poza normalnymi interfejsami API dostępu do kopiowania użytkownika (np. sprzętowy PAN lub emulowany za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które pierwotnie były dostarczane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-12] MUSI implementować izolację tabeli stron jądra, jeśli sprzęt jest podatny na CVE-2017-5754 na wszystkich urządzeniach, które pierwotnie były dostarczane z poziomem interfejsu API 28 lub nowszym (np. CONFIG_PAGE_TABLE_ISOLATION lub CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] MUSI wdrażać wzmocnienie przewidywania rozgałęzień, jeśli sprzęt jest podatny na CVE-2017-5715 na wszystkich urządzeniach, które pierwotnie były dostarczane z poziomem interfejsu API 28 lub nowszym (np. CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] Zdecydowanie zalecamy, aby po inicjowaniu dane jądra, które są zapisywane tylko podczas inicjowania, były oznaczone jako tylko do odczytu (np. __ro_after_init).

• [C-SR] Zdecydowanie zaleca się randomizację układu kodu jądra i pamięci oraz unikanie sytuacji, które mogłyby naruszyć randomizację (np. CONFIG_RANDOMIZE_BASE z entropią programu rozruchowego za pomocą /chosen/kaslr-seed Device Tree node lub EFI_RNG_PROTOCOL).

• [C-SR] ZDECYDOWANIE ZALECA się włączenie w jądrze funkcji kontroli integralności przepływu (CFI), aby zapewnić dodatkową ochronę przed atakami polegającymi na ponownym wykorzystaniu kodu (np. CONFIG_CFI_CLANG i CONFIG_SHADOW_CALL_STACK).

• [C-SR] Zdecydowanie zaleca się, aby nie wyłączać funkcji Control-Flow Integrity (CFI), Shadow Call Stack (SCS) ani Integer Overflow Sanitization (IntSan) w komponentach, w których są one włączone.
• [C-SR] Zdecydowanie zalecamy włączenie CFI, SCS i IntSan w przypadku wszystkich dodatkowych komponentów przestrzeni użytkownika, które są wrażliwe na kwestie bezpieczeństwa, zgodnie z opisem w sekcjach CFI i IntSan.

Jeśli implementacje urządzeń korzystają z jądra systemu Linux:

• [C-1-1] MUSI implementować SELinux.
• [C-1-2] MUSI ustawić SELinux w trybie globalnego wymuszania.
• [C-1-3] MUSI skonfigurować wszystkie domeny w trybie egzekwowania. Nie są dozwolone żadne domeny w trybie zezwalającym, w tym domeny specyficzne dla urządzenia lub dostawcy.
• [C-1-4] NIE WOLNO modyfikować, pomijać ani zastępować reguł neverallow znajdujących się w folderze system/sepolicy dostarczonym w ramach Projektu Android Open Source (AOSP). Zasady MUSZĄ być kompilowane ze wszystkimi regułami neverallow, zarówno w przypadku domen SELinux AOSP, jak i domen specyficznych dla urządzenia lub dostawcy.
• [C-1-5] MUSI uruchamiać aplikacje innych firm kierowane na interfejs API na poziomie 28 lub wyższym w piaskownicach SELinux dla poszczególnych aplikacji z ograniczeniami SELinux dla poszczególnych aplikacji w prywatnym katalogu danych każdej aplikacji.
• POWINNI zachować domyślne zasady SELinux udostępnione w folderze system/sepolicy w projekcie Android Open Source Project i tylko rozszerzać te zasady o własną konfigurację specyficzną dla urządzenia.

Jeśli implementacje urządzeń zostały już wprowadzone na rynek w starszej wersji Androida i nie mogą spełniać wymagań [C-1-1] i [C-1-5] za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać z nich zwolnione.

Jeśli implementacje urządzeń korzystają z jądra innego niż Linux:

• [C-2-1] MUSI używać systemu obowiązkowej kontroli dostępu, który jest odpowiednikiem SELinux.

Android zawiera wiele funkcji ochrony wielowarstwowej, które są integralną częścią zabezpieczeń urządzenia.

9.8. Prywatność

9.8.1. Historia użycia

Android przechowuje historię wyborów użytkownika i zarządza nią za pomocą interfejsu UsageStatsManager.

Implementacje na urządzeniach:

• [C-0-1] MUSI zachować rozsądny okres przechowywania historii użytkownika.
• [SR] Zdecydowanie zalecamy zachowanie 14-dniowego okresu przechowywania skonfigurowanego domyślnie w implementacji AOSP.

Android przechowuje zdarzenia systemowe za pomocą identyfikatorów StatsLog i zarządza taką historią za pomocą interfejsów API StatsManager i IncidentManager.

Implementacje na urządzeniach:

• [C-0-2] MUSI zawierać tylko pola oznaczone symbolem DEST_AUTOMATIC w raporcie o incydencie utworzonym przez klasę interfejsu System API IncidentManager.
• [C-0-3] NIE WOLNO używać identyfikatorów zdarzeń systemowych do rejestrowania żadnych innych zdarzeń niż te opisane w dokumentach pakietu SDK StatsLog. Jeśli rejestrowane są dodatkowe zdarzenia systemowe, 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 WOLNO wstępnie instalować ani rozpowszechniać komponentów oprogramowania, które wysyłają prywatne informacje użytkownika (np. naciśnięcia klawiszy, tekst wyświetlany na ekranie, raport o błędach) z urządzenia bez zgody użytkownika lub bez wyświetlania jasnych, ciągłych powiadomień.

• [C-0-2] MUSI wyświetlać i uzyskiwać wyraźną zgodę użytkownika, która zawiera w zasadzie tę samą wiadomość co AOSP, za każdym razem, gdy włączone jest przesyłanie lub nagrywanie ekranu za pomocą interfejsów API MediaProjection lub interfejsów API własnych. NIE MOŻE umożliwiać użytkownikom wyłączenia wyświetlania w przyszłości prośby o zgodę.

• [C-0-3] MUSI wyświetlać użytkownikowi ciągłe powiadomienie, gdy włączone jest przesyłanie lub nagrywanie ekranu. AOSP spełnia to wymaganie, wyświetlając ikonę bieżącego powiadomienia na pasku stanu.

Jeśli implementacje urządzeń zawierają funkcje systemowe, które rejestrują treści wyświetlane na ekranie lub nagrywają strumień audio odtwarzany na urządzeniu w inny sposób niż za pomocą interfejsu System APIContentCaptureService lub innych zastrzeżonych środków opisanych w sekcji 9.8.6 Rejestrowanie treści, muszą:

• [C-1-1] MUSI wyświetlać użytkownikowi ciągłe powiadomienie, gdy ta funkcja jest włączona i aktywna (rejestruje lub nagrywa).

Jeśli implementacje urządzeń zawierają komponent włączony od razu po wyjęciu z pudełka, który może nagrywać dźwięk otoczenia lub dźwięk odtwarzany na urządzeniu w celu wywnioskowania przydatnych informacji o kontekście użytkownika, to:

• [C-2-1] NIE WOLNO przechowywać w pamięci trwałej urządzenia ani przesyłać poza urządzenie nagranego surowego dźwięku ani żadnego formatu, który można przekonwertować z powrotem na oryginalny dźwięk lub jego niemal identyczną kopię, z wyjątkiem sytuacji, gdy użytkownik wyrazi na to wyraźną zgodę.

9.8.3. Łączność

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB:

• [C-1-1] MUSI wyświetlać interfejs użytkownika z prośbą o zgodę użytkownika przed zezwoleniem 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 wstępnie instalować te same certyfikaty główne w magazynie zaufanych przez system urzędów certyfikacji, które są udostępniane w projekcie Android Open Source Project.
• [C-0-2] MUSI być dostarczany z pustym magazynem głównych urzędów certyfikacji użytkownika.
• [C-0-3] MUSI wyświetlać ostrzeżenie dla użytkownika informujące, że ruch w sieci może być monitorowany, gdy dodany zostanie główny certyfikat CA użytkownika.

Jeśli ruch na urządzeniu jest kierowany przez sieć VPN, implementacje na urządzeniu:

• [C-1-1] MUSI wyświetlać ostrzeżenie dla użytkownika wskazujące:
  • Ten ruch w sieci może być monitorowany.
  • Ruch sieciowy jest kierowany przez konkretną aplikację VPN, która zapewnia VPN.

Jeśli implementacje urządzeń mają mechanizm, który jest domyślnie włączony i kieruje ruch danych sieciowych przez serwer proxy lub bramę VPN (np. wstępne wczytywanie usługi VPN z przyznanym uprawnieniem android.permission.CONTROL_VPN), to:

• [C-2-1] MUSI poprosić użytkownika o zgodę przed włączeniem tego mechanizmu, chyba że sieć VPN jest włączana przez kontroler zasad dotyczących urządzenia za pomocą interfejsu DevicePolicyManager.setAlwaysOnVpnPackage(). W takim przypadku użytkownik nie musi wyrażać osobnej zgody, ale MUSI otrzymać powiadomienie.

Jeśli implementacje urządzeń udostępniają użytkownikowi możliwość włączania i wyłączania funkcji „stałego VPN” aplikacji VPN innej firmy:

• [C-3-1] MUSI wyłączyć tę funkcję dla aplikacji, które nie obsługują stałej sieci VPN, w pliku AndroidManifest.xml, ustawiając atrybut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

9.8.5. Identyfikatory urządzeń

Implementacje na urządzeniach:

• [C-0-1] MUSI uniemożliwiać aplikacjom dostęp do numeru seryjnego urządzenia oraz, w stosownych przypadkach, do numeru IMEI/MEID, numeru seryjnego karty SIM i identyfikatora IMSI (International Mobile Subscriber Identity), chyba że aplikacja spełnia jedno z tych wymagań:
  • jest podpisaną aplikacją operatora, która została zweryfikowana przez producentów urządzeń.
  • otrzymał uprawnienie READ_PRIVILEGED_PHONE_STATE.
  • ma uprawnienia operatora zdefiniowane w UICC Carrier Privileges.
  • jest właścicielem urządzenia lub profilu, któremu przyznano uprawnienie READ_PHONE_STATE.
  • (Dotyczy tylko numeru seryjnego karty SIM lub numeru ICCID) musi spełniać wymagania lokalnych przepisów, zgodnie z którymi aplikacja ma wykrywać zmiany tożsamości subskrybenta.

9.8.6. Rejestrowanie treści

Android za pomocą interfejsu System API ContentCaptureService lub innych metod własnych obsługuje mechanizm, który umożliwia implementacjom urządzeń rejestrowanie tych interakcji między aplikacjami a użytkownikiem:

• Tekst i grafika wyświetlane na ekranie, w tym powiadomienia i dane pomocnicze, za pomocą interfejsu AssistStructure API.
• dane multimedialne, takie jak dźwięk lub wideo, nagrane lub odtwarzane przez urządzenie;
• zdarzenia wejściowe (np. klawisze, mysz, gesty, głos, wideo i ułatwienia dostępu);
• Wszystkie inne zdarzenia, które aplikacja przekazuje do systemu za pomocą interfejsu Content Capture API lub podobnego interfejsu API własnego.

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 być przeprowadzane przy użyciu szyfrowania plików na Androidzie lub dowolnego z szyfrów wymienionych w sekcji API w wersji 26 lub nowszej, opisanych w pakiecie SDK do szyfrowania.
• [C-1-2] NIE WOLNO tworzyć kopii zapasowych danych w formie nieprzetworzonej ani zaszyfrowanej przy użyciu metod tworzenia kopii zapasowych na Androidzie ani żadnych innych metod tworzenia kopii zapasowych.
• [C-1-3] MUSI wysyłać wszystkie te dane i dziennik urządzenia tylko za pomocą mechanizmu chroniącego prywatność. Mechanizm ochrony prywatności jest zdefiniowany jako „mechanizm, który umożliwia tylko analizę zbiorczą i uniemożliwia dopasowywanie zarejestrowanych zdarzeń lub uzyskanych wyników do poszczególnych użytkowników”, aby zapobiec możliwości wglądu w dane poszczególnych użytkowników (np. zaimplementowany przy użyciu technologii prywatności różnicowej, takiej jak RAPPOR).
• [C-1-4] NIE WOLNO wiązać takich danych z tożsamością użytkownika (np. Account) na urządzeniu, chyba że użytkownik wyrazi na to wyraźną zgodę za każdym razem, gdy dane są wiązane.
• [C-1-5] NIE WOLNO udostępniać takich danych innym aplikacjom, chyba że użytkownik wyrazi na to zgodę za każdym razem, gdy dane są udostępniane.
• [C-1-6] MUSI udostępniać użytkownikowi możliwość usunięcia danych zbieranych przez ContentCaptureService lub za pomocą środków własnych, jeśli dane są przechowywane w jakiejkolwiek formie na urządzeniu.

Jeśli implementacje urządzeń obejmują usługę, która implementuje interfejs System APIContentCaptureService, lub dowolną usługę własną, 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ą instalowaną przez użytkownika i MOŻE zezwalać na przechwytywanie takich danych tylko preinstalowanej usłudze.
• [C-2-2] NIE MOŻE zezwalać żadnym aplikacjom innym niż preinstalowany mechanizm usługi przechwytywania treści na przechwytywanie takich danych.
• [C-2-3] MUSI udostępniać użytkownikowi możliwość wyłączenia usługi przechwytywania treści.
• [C-2-4] NIE WOLNO pomijać możliwości zarządzania przez użytkownika uprawnieniami Androida, które są przyznane usłudze przechwytywania treści, ani nie wolno naruszać modelu uprawnień Androida opisanego w sekcji 9.1. Uprawnienia.

• [C-SR] Zdecydowanie zaleca się, aby komponenty usługi przechwytywania treści były oddzielone od innych komponentów systemu, z wyjątkiem tych, które są wymienione poniżej. Nie należy na przykład wiązać usługi ani udostępniać identyfikatorów procesów.

  • Telefonia, Kontakty, Interfejs systemu i Media

9.8.7. Dostęp do schowka

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE zwracać przyciętych danych do schowka (np. za pomocą interfejsu ClipboardManager API), chyba że aplikacja jest domyślnym edytorem IME lub jest aplikacją, która jest obecnie aktywna.

9.8.8. Lokalizacja

Implementacje na urządzeniach:

• [C-0-1] NIE WOLNO włączać ani wyłączać ustawień lokalizacji urządzenia oraz ustawień skanowania Wi-Fi/Bluetooth bez wyraźnej zgody użytkownika lub jego działania.
• [C-0-2] MUSI udostępniać użytkownikowi interfejs umożliwiający dostęp do informacji związanych z lokalizacją, w tym do ostatnich próśb o lokalizację, uprawnień na poziomie aplikacji i korzystania ze skanowania Wi-Fi/Bluetooth w celu określenia lokalizacji.
• [C-0-3] MUSI zapewnić, że aplikacja korzystająca z interfejsu Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] jest sesją alarmową zainicjowaną przez użytkownika (np. połączenie z numerem 112 lub wysłanie SMS-a pod ten numer).
• [C-0-4] MUSI zachować możliwość pomijania ustawień lokalizacji urządzenia przez interfejs Emergency Location Bypass API bez zmiany tych ustawień.
• [C-0-5] MUSI zaplanować powiadomienie, które przypomni użytkownikowi, że aplikacja działająca w tle uzyskała dostęp do jego lokalizacji za pomocą uprawnienia [ACCESS_BACKGROUND_LOCATION].

9.9. Szyfrowanie danych przechowywanych

Wszystkie urządzenia MUSZĄ spełniać wymagania sekcji 9.9.1. Urządzenia, które zostały wprowadzone na rynek z poziomem API wcześniejszym niż ten, którego dotyczy ten dokument, są zwolnione z wymagań sekcji 9.9.2 i 9.9.3. Zamiast tego MUSZĄ spełniać wymagania sekcji 9.9 dokumentu definicji zgodności z Androidem odpowiadające poziomowi API, z którym urządzenie zostało wprowadzone na rynek.

9.9.1. Bezpośredni rozruch

Implementacje na urządzeniach:

• [C-0-1] MUSI implementować interfejsy API trybu bezpośredniego rozruchu, nawet jeśli nie obsługuje szyfrowania pamięci.

• [C-0-2] Intencje ACTION_LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED MUSZĄ być nadal rozgłaszane, aby poinformować aplikacje obsługujące bezpośrednie uruchamianie, że lokalizacje pamięci zaszyfrowanej na urządzeniu (DE) i zaszyfrowanej za pomocą danych logowania (CE) są dostępne dla użytkownika.

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 ona stałą, nieusuwalną częścią urządzenia.
• [C-0-2] MUSI domyślnie włączać szyfrowanie pamięci danych, gdy użytkownik zakończy początkową konfigurację.
• [C-0-3] MUSI spełniać powyższe wymagania dotyczące szyfrowania pamięci masowej danych poprzez wdrożenie szyfrowania opartego na plikach (FBE).

9.9.3. Szyfrowanie oparte na plikach

Zaszyfrowane urządzenia:

• [C-1-1] MUSI uruchamiać się bez proszenia użytkownika o dane logowania i umożliwiać aplikacjom obsługującym bezpośrednie uruchamianie dostęp do pamięci zaszyfrowanej na urządzeniu (DE) po wyemitowaniu komunikatu ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] MUSI zezwalać na dostęp do zaszyfrowanej pamięci danych logowania (CE) tylko po odblokowaniu urządzenia przez użytkownika za pomocą danych logowania (np. kodu dostępu, kodu PIN, wzoru lub odcisku palca) i po wyemitowaniu komunikatu ACTION_USER_UNLOCKED.
• [C-1-3] NIE MOŻE oferować żadnej metody odblokowywania pamięci chronionej przez CE bez podania przez użytkownika danych logowania lub zarejestrowanego klucza depozytowego.
• [C-1-4] MUSI używać weryfikacji podczas uruchamiania i zapewniać, że klucze DE są kryptograficznie powiązane ze sprzętowym źródłem zaufania urządzenia.
• [C-1-5] MUSI szyfrować zawartość plików za pomocą algorytmu AES-256-XTS lub Adiantum. AES-256-XTS to standard AES z 256-bitowym kluczem szyfrującym działającym w trybie XTS. Pełna długość klucza wynosi 512 bitów. Adiantum odnosi się do Adiantum-XChaCha12-AES, zgodnie z opisem na stronie https://github.com/google/adiantum.
• [C-1-6] MUSI szyfrować nazwy plików za pomocą AES-256-CBC-CTS lub Adiantum.

• [C-1-12] MUSI używać algorytmu AES-256-XTS do szyfrowania zawartości plików i algorytmu AES-256-CBC-CTS do szyfrowania nazw plików (zamiast algorytmu Adiantum), jeśli urządzenie ma instrukcje standardu AES. Instrukcje AES to rozszerzenia kryptograficzne ARMv8 na urządzeniach z procesorami ARM lub AES-NI na urządzeniach z procesorami x86. Jeśli urządzenie nie ma instrukcji AES, MOŻE używać Adiantum.

• Klucze chroniące obszary pamięci CE i DE:

• [C-1-7] MUSI być kryptograficznie powiązany z magazynem kluczy wspieranym sprzętowo.

• [C-1-8] Klucze CE MUSZĄ być powiązane z danymi logowania do ekranu blokady użytkownika.
• [C-1-9] Klucze CE MUSZĄ być powiązane z domyślnym hasłem, jeśli użytkownik nie określił danych logowania do ekranu blokady.
• [C-1-10] MUSI być unikalny i odrębny, tzn. klucz CE lub DE żadnego użytkownika nie może być zgodny z kluczem CE lub DE innego użytkownika.
• [C-1-11] MUSI używać obowiązkowo obsługiwanych szyfrów, długości kluczy i trybów.

• [C-SR] Zdecydowanie zaleca się szyfrowanie metadanych systemu plików, takich jak rozmiary plików, własność, tryby i atrybuty rozszerzone (xattrs), za pomocą klucza kryptograficznie powiązanego ze sprzętowym źródłem zaufania urządzenia.

• POWINNY obsługiwać bezpośrednie uruchamianie wstępnie zainstalowane aplikacje podstawowe (np. Alarm, Telefon, Messenger).

Projekt Android Open Source udostępnia preferowaną implementację tej funkcji opartą na funkcji szyfrowania „fscrypt” jądra Linuksa.

9.10. Integralność urządzenia

Poniższe wymagania zapewniają przejrzystość stanu integralności urządzenia. Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo zgłaszać za pomocą metody interfejsu System API PersistentDataBlockManager.getFlashLockState(), czy stan programu rozruchowego umożliwia flashowanie obrazu systemu. Stan FLASH_LOCK_UNKNOWN jest zarezerwowany dla implementacji urządzeń, które są uaktualniane z wcześniejszej wersji Androida, w której nie było tej nowej metody interfejsu API systemu.

• [C-0-2] MUSI obsługiwać zweryfikowane uruchamianie w celu zapewnienia integralności urządzenia.

Jeśli urządzenia zostały już wprowadzone na rynek bez obsługi weryfikacji podczas uruchamiania w starszej wersji Androida i nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z tego wymagania.

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

• [C-1-1] MUSI zadeklarować flagę funkcji platformy android.software.verified_boot.
• [C-1-2] MUSI przeprowadzać weryfikację przy każdej sekwencji uruchamiania.
• [C-1-3] MUSI rozpocząć weryfikację od niezmiennego klucza sprzętowego, który jest źródłem zaufania, i przejść aż do partycji systemowej.
• [C-1-4] MUSI wdrażać każdy etap weryfikacji, aby sprawdzać integralność i autentyczność wszystkich bajtów na następnym etapie przed wykonaniem kodu na tym etapie.
• [C-1-5] MUSI używać algorytmów weryfikacji o mocy co najmniej takiej, jak zalecenia NIST dotyczące algorytmów szyfrowania (SHA-256) i rozmiarów kluczy publicznych (RSA-2048).
• [C-1-6] NIE MOŻE zezwalać na ukończenie rozruchu, gdy weryfikacja systemu zakończy się niepowodzeniem, chyba że użytkownik wyrazi zgodę na podjęcie próby rozruchu. W takim przypadku NIE MOŻNA używać danych z żadnych niezweryfikowanych bloków pamięci.
• [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 urządzenie zawiera wiele oddzielnych układów (np. radio, specjalistyczny procesor obrazu), ZDECYDOWANIE ZALECA SIĘ weryfikowanie każdego etapu procesu uruchamiania każdego z tych układów.
• [C-1-8] MUSI używać pamięci odpornej na manipulacje: do przechowywania informacji o tym, czy program rozruchowy jest odblokowany. Oznacza to, że program rozruchowy może wykryć, czy pamięć została zmodyfikowana z poziomu Androida.
• [C-1-9] MUSI wyświetlać użytkownikowi prośbę o potwierdzenie fizyczne podczas korzystania z urządzenia i wymagać tego potwierdzenia przed zezwoleniem na przejście z trybu zablokowanego programu rozruchowego do trybu odblokowanego programu rozruchowego.
• [C-1-10] MUSI wdrażać ochronę przed wycofaniem zmian w przypadku partycji używanych przez Androida (np. partycji rozruchowych i systemowych) oraz używać pamięci masowej odpornej na manipulacje do przechowywania metadanych używanych do określania minimalnej dopuszczalnej wersji systemu operacyjnego.
• [C-SR] Zdecydowanie zaleca się weryfikację wszystkich plików APK aplikacji z uprawnieniami za pomocą łańcucha zaufania zakorzenionego w partycjach chronionych przez zweryfikowany rozruch.
• [C-SR] Zdecydowanie zaleca się weryfikowanie wszystkich artefaktów wykonywalnych wczytywanych przez aplikację z uprawnieniami z zewnątrz pliku APK (np. dynamicznie wczytywanego lub skompilowanego kodu) przed ich wykonaniem lub zdecydowanie zaleca się, aby w ogóle ich nie wykonywać.
• POWINNY wdrażać ochronę przed wycofaniem w przypadku wszystkich komponentów z trwałym oprogramowaniem (np. modemu, aparatu) i POWINNY używać pamięci odpornej na manipulacje do przechowywania metadanych używanych do określania minimalnej dopuszczalnej wersji.

Jeśli urządzenia zostały już wprowadzone na rynek bez obsługi wymagań C-1-8 do C-1-10 w starszej wersji Androida i nie można dodać obsługi tych wymagań za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać z nich zwolnione.

Projekt Android Open Source udostępnia preferowaną implementację tej funkcji w repozytorium external/avb/, którą można zintegrować z programem rozruchowym używanym do ładowania Androida.

Implementacje na urządzeniach:

• [C-R] ZALECA się obsługę interfejsu Android Protected Confirmation API.

Jeśli implementacje urządzeń obsługują interfejs Android Protected Confirmation API:

• [C-3-1] MUSI zgłaszać true w przypadku interfejsu ConfirmationPrompt.isSupported() API.

• [C-3-2] MUSI zapewnić, że kod działający w systemie Android, w tym jego jądro, złośliwy lub inny, nie może generować pozytywnej odpowiedzi bez interakcji z użytkownikiem.

• [C-3-3] MUSI zapewnić, że użytkownik będzie mógł przejrzeć i zatwierdzić wyświetlony komunikat nawet w przypadku naruszenia bezpieczeństwa systemu operacyjnego Android, w tym jego jądra.

9.11. Klucze i dane uwierzytelniające

System Android Keystore umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i używanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub interfejsu Keystore API. Implementacje na urządzeniach:

• [C-0-1] MUSI umożliwiać importowanie lub generowanie co najmniej 8192 kluczy.
• [C-0-2] Uwierzytelnianie na ekranie blokady MUSI ograniczać liczbę prób i MUSI korzystać z algorytmu wykładniczego wycofywania. Po 150 nieudanych próbach opóźnienie MUSI wynosić co najmniej 24 godziny na próbę.
• NIE POWINNO ograniczać liczby kluczy, które można wygenerować.

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady:

• [C-1-1] MUSI tworzyć kopię zapasową implementacji magazynu kluczy w izolowanym środowisku wykonawczym.
• [C-1-2] MUSI mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji skrótu MD5, SHA1 i SHA-2, aby prawidłowo obsługiwać algorytmy obsługiwane przez system Android Keystore w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i powyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego izolowanego środowiska, w tym DMA. Wymaganie to jest spełnione w przypadku projektu Android Open Source Project (AOSP) dzięki implementacji Trusty, ale alternatywnymi rozwiązaniami są inne rozwiązania oparte na ARM TrustZone lub sprawdzone przez zewnętrzną firmę bezpieczne implementacje odpowiedniej izolacji opartej na hiperwizorze.
• [C-1-3] MUSI przeprowadzać uwierzytelnianie na ekranie blokady w izolowanym środowisku wykonawczym i tylko w przypadku powodzenia zezwalać na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania do ekranu blokady MUSZĄ być przechowywane w sposób, który umożliwia uwierzytelnianie na ekranie blokady tylko w izolowanym środowisku wykonawczym. Projekt Android Open Source udostępnia warstwę abstrakcji sprzętu (HAL) Gatekeeper i Trusty, które mogą być używane do spełnienia tego wymagania.
• [C-1-4] MUSI obsługiwać atestację klucza, w której klucz podpisu atestacji jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się w bezpiecznym sprzęcie. Klucze podpisywania atestu MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnianie tego samego klucza atestu,chyba że wyprodukowano co najmniej 100 000 sztuk danego kodu SKU. Jeśli wyprodukowano więcej niż 100 000 sztuk danego kodu SKU, dla każdych 100 000 sztuk MOŻE być użyty inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona na wcześniejszej wersji Androida, takie urządzenie jest zwolnione z wymogu posiadania magazynu kluczy obsługiwanego przez odizolowane środowisko wykonawcze i obsługi atestowania kluczy, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy obsługiwanego przez odizolowane środowisko wykonawcze.

• [C-1-5] MUSI umożliwiać użytkownikowi wybór czasu bezczynności przed przejściem z odblokowanego do zablokowanego stanu, przy czym minimalny dopuszczalny czas bezczynności wynosi 15 sekund.

9.11.1. Bezpieczny ekran blokady i uwierzytelnianie

Implementacja AOSP jest zgodna z wielopoziomowym modelem uwierzytelniania, w którym podstawowe uwierzytelnianie oparte na czynniku wiedzy może być wspierane przez drugorzędne silne uwierzytelnianie biometryczne lub słabsze metody trzeciorzędne.

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie zalecamy ustawienie tylko jednej z tych metod jako podstawowej metody uwierzytelniania:
  • numeryczny kod PIN,
  • hasło alfanumeryczne;
  • wzorzec przesunięcia na siatce składającej się z 9 punktów (3 x 3).

Pamiętaj, że powyższe metody uwierzytelniania są w tym dokumencie określane jako zalecane podstawowe metody uwierzytelniania.

Jeśli implementacje urządzeń dodają lub modyfikują zalecane podstawowe metody uwierzytelniania i używają nowej metody uwierzytelniania jako bezpiecznego sposobu blokowania ekranu, nowa metoda uwierzytelniania:

• [C-2-1] MUSI być metodą uwierzytelniania użytkownika opisaną w sekcji Wymaganie uwierzytelniania użytkownika w przypadku używania klucza.
• [C-2-2] MUSI odblokować wszystkie klucze, aby aplikacja dewelopera zewnętrznego mogła ich używać, gdy użytkownik odblokuje bezpieczny ekran blokady. Na przykład wszystkie klucze MUSZĄ być dostępne dla aplikacji dewelopera zewnętrznego za pomocą odpowiednich interfejsów API, takich jak createConfirmDeviceCredentialIntent i setUserAuthenticationRequired.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady na podstawie znanego sekretu, i używają nowej metody uwierzytelniania, która ma być traktowana jako bezpieczny sposób blokowania 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 (tj. kodu PIN, wzoru, hasła) zaimplementowanych i udostępnianych w AOSP.
• [C-3-4] Nowa metoda uwierzytelniania MUSI zostać wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasady dotyczące jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_SOMETHING.
• [C-3-5] Nowe metody uwierzytelniania MUSZĄ co 72 godziny lub rzadziej wracać do zalecanych podstawowych metod uwierzytelniania (tj. PIN-u, wzoru lub hasła) LUB wyraźnie informować użytkownika, że niektóre dane nie będą tworzone w celu zachowania prywatności danych.

Jeśli implementacje urządzeń dodają lub modyfikują zalecane podstawowe metody uwierzytelniania w celu odblokowania ekranu blokady i używają nowej metody uwierzytelniania opartej na danych biometrycznych, która jest 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 wygody.
• [C-4-2] MUSI mieć mechanizm rezerwowy, który umożliwia korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania opartych na znanym sekrecie.
• [C-4-3] MUSI być wyłączona i umożliwiać odblokowanie ekranu tylko za pomocą zalecanego podstawowego uwierzytelniania , gdy aplikacja kontrolera zasad urządzenia (DPC) ustawiła zasadę funkcji blokady ekranu, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures() z dowolną z powiązanych flag biometrycznych (np. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE lub KEYGUARD_DISABLE_IRIS).

Jeśli metody uwierzytelniania biometrycznego nie spełniają wymagań dotyczących silnego uwierzytelniania opisanych 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 hasła za pomocą metody DevicePolicyManager.setPasswordQuality() ze stałą jakością o większych ograniczeniach niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Po 4-godzinnym okresie bezczynności użytkownik MUSI zostać poproszony o podanie zalecanego podstawowego uwierzytelnienia (np. kodu PIN, wzoru lub hasła). Okres bezczynności jest resetowany po każdym pomyślnym potwierdzeniu danych logowania na urządzenie.
• [C-5-3] Metody NIE MOGĄ być traktowane jako bezpieczny ekran blokady i MUSZĄ spełniać wymagania, które zaczynają się od C-8 w tej sekcji poniżej.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania w celu odblokowania ekranu blokady, a nowa metoda uwierzytelniania jest oparta na fizycznym tokenie lub lokalizacji:

• [C-6-1] Muszą mieć mechanizm rezerwowy, który umożliwia korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania opartych na znanym sekrecie i spełniających wymagania dotyczące bezpiecznego ekranu blokady.
• [C-6-2] Nowa metoda MUSI być wyłączona i umożliwiać odblokowanie ekranu tylko za pomocą jednej z zalecanych podstawowych metod uwierzytelniania, gdy aplikacja kontrolera zasad urządzenia (DPC) ustawi zasady za pomocą metody DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) lub metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] Użytkownik MUSI być proszony o użycie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru lub hasła) co najmniej raz na 4 godziny lub rzadziej.
• [C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI spełniać ograniczenia wymienione poniżej w sekcji C-8.

Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej 1 agenta zaufania, który implementuje interfejs TrustAgentService API systemu, to:

• [C-7-1] W menu ustawień i na ekranie blokady musi być wyraźnie widoczna informacja o tym, że blokada urządzenia jest odroczona lub może być utrzymywana w stanie odblokowanym przez zaufane usługi. Na przykład AOSP spełnia to wymaganie, wyświetlając opis tekstowy ustawień „Automatyczne blokowanie” i „Przycisk zasilania natychmiast blokuje” w menu ustawień oraz charakterystyczną ikonę na ekranie blokady.
• [C-7-2] MUSI respektować i w pełni implementować wszystkie interfejsy API agenta zaufania w klasie DevicePolicyManager, takie jak stała KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NIE WOLNO w pełni implementować funkcji TrustAgentService.addEscrowToken() na urządzeniu, które jest używane jako główne urządzenie osobiste (np. urządzenie przenośne), ale MOŻNA w pełni implementować tę funkcję na urządzeniach, które są zwykle udostępniane (np. telewizor z Androidem lub urządzenie samochodowe).
• [C-7-4] MUSI szyfrować wszystkie zapisane 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. Na przykład klucz przechowywany na telefonie może odblokować konto użytkownika na telewizorze.
• [C-7-6] MUSI poinformować użytkownika o konsekwencjach związanych z bezpieczeństwem przed włączeniem tokena depozytowego do odszyfrowania pamięci danych.
• [C-7-7] MUSI mieć mechanizm rezerwowy, który umożliwia korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania.
• [C-7-8] Użytkownik MUSI być proszony o użycie jednej z zalecanych podstawowych metod uwierzytelniania (np.kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny lub rzadziej, chyba że bezpieczeństwo użytkownika (np. rozproszenie uwagi kierowcy) budzi obawy.
• [C-7-9] Po 4-godzinnym okresie bezczynności użytkownik MUSI zostać poproszony o użycie jednej z zalecanych podstawowych metod uwierzytelniania (np. PIN-u, wzoru lub hasła), chyba że bezpieczeństwo użytkownika (np. rozproszenie uwagi kierowcy) jest zagrożone. Okres bezczynności jest resetowany po każdym pomyślnym potwierdzeniu danych logowania na urządzenie.
• [C-7-10] NIE MOŻE być traktowany jako bezpieczny ekran blokady i MUSI spełniać ograniczenia wymienione w punkcie C-8 poniżej.
• [C-7-11] NIE MOŻE zezwalać agentom zaufania na odblokowywanie urządzenia głównego (np.przenośnego) i może ich używać tylko do utrzymywania już odblokowanego urządzenia w stanie odblokowanym przez maksymalnie 4 godziny. Domyślna implementacja usługi TrustManagerService w AOSP spełnia to wymaganie.
• [C-7-12] MUSI używać szyfrowanego kanału komunikacji (np.UKEY2) do przekazywania tokena depozytowego z urządzenia pamięci masowej na urządzenie docelowe.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania w celu odblokowania ekranu blokady, który nie jest bezpiecznym ekranem blokady opisanym powyżej, i używają nowej metody uwierzytelniania do odblokowania 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() ze stałą jakością bardziej restrykcyjną niż PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] NIE WOLNO resetować liczników czasu wygaśnięcia hasła ustawionych przez DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] NIE WOLNO udostępniać interfejsu API do użytku przez aplikacje innych firm w celu zmiany stanu blokady.

9.11.2. StrongBox

System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w dedykowanym bezpiecznym procesorze, a także w opisanym powyżej odizolowanym środowisku wykonawczym. Taki dedykowany bezpieczny procesor nazywa się „StrongBox”. Wymagania C-1-3 do C-1-11 poniżej określają, jakie wymagania MUSI spełniać urządzenie, aby kwalifikować się jako StrongBox.

Implementacje urządzeń z dedykowanym bezpiecznym procesorem:

• [C-SR] Zdecydowanie zalecane jest obsługiwanie StrongBox. W przyszłej wersji StrongBox prawdopodobnie stanie się wymaganiem.

Jeśli implementacje urządzeń obsługują StrongBox, to:

• [C-1-1] MUSI deklarować FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] MUSI udostępniać dedykowany bezpieczny sprzęt, który jest używany do obsługi magazynu kluczy i bezpiecznego uwierzytelniania użytkownika. Dedykowany bezpieczny sprzęt może być też używany do innych celów.

• [C-1-3] MUSI mieć osobny procesor, który nie współdzieli pamięci podręcznej, pamięci DRAM, koprocesorów ani innych zasobów podstawowych z procesorem aplikacji (AP).

• [C-1-4] MUSI zapewnić, że żadne urządzenia peryferyjne udostępniane procesorowi aplikacji nie mogą w żaden sposób zmieniać przetwarzania w StrongBox ani uzyskiwać z niego żadnych informacji. Punkt dostępu MOŻE wyłączyć lub zablokować dostęp do StrongBox.

• [C-1-5] MUSI mieć wewnętrzny zegar o rozsądnej dokładności (±10%), który jest odporny na manipulacje ze strony punktu dostępu.

• [C-1-6] MUSI mieć generator prawdziwych liczb losowych, który generuje równomiernie rozłożone i nieprzewidywalne dane wyjściowe.

• [C-1-7] MUSI być odporny na manipulacje, w tym na fizyczne wnikanie i błędy.

• [C-1-8] MUSI być odporny na ataki z użyciem kanałów bocznych, w tym na wyciek informacji przez kanały boczne związane z zasilaniem, czasem, promieniowaniem elektromagnetycznym i promieniowaniem cieplnym.

• [C-1-9] MUSI mieć bezpieczne miejsce do przechowywania, które zapewnia poufność, integralność, autentyczność, spójność i aktualność treści. Pamięci NIE WOLNO odczytywać ani zmieniać, z wyjątkiem przypadków dozwolonych przez interfejsy API StrongBox.

• Aby potwierdzić zgodność z wymaganiami [C-1-3]–[C-1-9], implementacje urządzeń:

  • [C-1-10] MUSI zawierać sprzęt certyfikowany zgodnie z profilem ochrony układów scalonych BSI-CC-PP-0084-2014 lub oceniony przez akredytowane w danym kraju laboratorium testowe z uwzględnieniem oceny podatności na ataki o wysokim potencjale zgodnie z dokumentem Common Criteria Application of Attack Potential to Smartcards.
  • [C-1-11] MUSI zawierać oprogramowanie sprzętowe, które zostało ocenione przez akredytowane na poziomie krajowym laboratorium testowe z uwzględnieniem oceny podatności na ataki o wysokim potencjale zgodnie z dokumentem Common Criteria Application of Attack Potential to Smartcards.
  • [C-SR] Zdecydowanie zaleca się uwzględnienie sprzętu, który jest oceniany na podstawie profilu bezpieczeństwa, poziomu pewności oceny (EAL) 5, rozszerzonego o AVA_VAN.5. Certyfikat EAL 5 prawdopodobnie stanie się wymagany w przyszłej wersji.

• [C-SR] są ZDECYDOWANIE ZALECANE, aby zapewnić odporność na ataki wewnętrzne (IAR), co oznacza, że osoba z dostępem do kluczy podpisywania oprogramowania sprzętowego nie może utworzyć oprogramowania sprzętowego, które powoduje wyciek informacji tajnych z StrongBox, ominięcie funkcjonalnych wymagań bezpieczeństwa ani w inny sposób umożliwić dostęp do poufnych danych użytkownika. Zalecanym sposobem wdrożenia IAR jest zezwalanie na aktualizacje oprogramowania tylko wtedy, gdy hasło użytkownika głównego jest podawane za pomocą interfejsu HAL IAuthSecret.

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 userdata.
• [C-0-3] MUSI usunąć dane w sposób zgodny z odpowiednimi standardami branżowymi, takimi jak NIST SP800-88.
• [C-0-4] MUSI uruchamiać powyższy proces „Przywracanie ustawień fabrycznych”, gdy interfejs DevicePolicyManager.wipeData() API jest wywoływany przez aplikację Kontroler zasad urządzenia użytkownika podstawowego.
• MOŻE udostępniać opcję szybkiego usuwania danych, która przeprowadza tylko logiczne usuwanie danych.

9.13. Tryb bezpiecznego rozruchu

Android udostępnia tryb bezpiecznego rozruchu, który umożliwia użytkownikom uruchamianie urządzenia w trybie, w którym działają tylko wstępnie zainstalowane aplikacje systemowe, a wszystkie aplikacje innych firm są wyłączone. Ten tryb, zwany „trybem bezpiecznego uruchamiania”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.

Implementacje urządzeń:

• [SR] Zdecydowanie zalecamy wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacje urządzeń obsługują tryb bezpiecznego uruchamiania:

• [C-1-1] MUSI udostępniać użytkownikowi opcję przejścia do trybu bezpiecznego rozruchu w sposób, który nie jest przerywany przez aplikacje innych firm zainstalowane na urządzeniu, z wyjątkiem sytuacji, gdy aplikacja innej firmy jest kontrolerem zasad dotyczących urządzeń i ustawiła flagę UserManager.DISALLOW_SAFE_BOOT na wartość „prawda”.

• [C-1-2] MUSI umożliwiać użytkownikowi odinstalowanie dowolnych aplikacji innych firm w trybie bezpiecznym.

• POWINIEN udostępniać użytkownikowi opcję przejścia do trybu awaryjnego z menu rozruchu za pomocą procesu innego niż w przypadku normalnego rozruchu.

9.14. Izolacja systemu pojazdu samochodowego

Urządzenia z Androidem Automotive powinny wymieniać dane z krytycznymi podsystemami pojazdu za pomocą HAL pojazdu, aby wysyłać i odbierać wiadomości w sieciach pojazdu, takich jak magistrala CAN.

Wymiana danych może być zabezpieczona przez wdrożenie funkcji zabezpieczeń poniżej warstw platformy Android, aby zapobiec złośliwym lub niezamierzonym interakcjom z tymi podsystemami.

9.15. Abonamenty

„Abonamenty” to szczegóły planu rozliczeniowego udostępniane przez operatora sieci komórkowej za pomocą SubscriptionManager.setSubscriptionPlans().

Wszystkie implementacje na urządzeniach:

• [C-0-1] MUSI zwracać plany subskrypcji tylko do aplikacji operatora komórkowego, która pierwotnie je udostępniła.
• [C-0-2] NIE MOŻE zdalnie tworzyć kopii zapasowych ani przesyłać abonamentów.
• [C-0-3] MUSI zezwalać na zastępowanie, np. SubscriptionManager.setSubscriptionOverrideCongested(), tylko w przypadku aplikacji operatora komórkowego, który obecnie oferuje ważne abonamenty.

10. Testowanie zgodności oprogramowania

Implementacje urządzeń MUSZĄ przejść wszystkie testy opisane w tej sekcji. Pamiętaj jednak, że żaden pakiet testów oprogramowania nie jest w pełni kompleksowy. Z tego powodu zdecydowanie zalecamy producentom urządzeń wprowadzanie jak najmniejszej liczby zmian w referencyjnej i preferowanej implementacji Androida dostępnej w ramach Projektu Android Open Source. Zminimalizuje to ryzyko wprowadzenia błędów, które powodują niezgodności wymagające ponownej pracy i potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje na urządzeniach:

• [C-0-1] MUSI przejść pakiet testów zgodności z Androidem (CTS) dostępny w ramach Projektu Android Open Source, korzystając z ostatecznej wersji oprogramowania dostarczonej na urządzeniu.

• [C-0-2] MUSI zapewniać zgodność w przypadku niejednoznaczności w CTS i w przypadku ponownego wdrożenia części referencyjnego kodu źródłowego.

Zestaw CTS jest przeznaczony do uruchamiania na rzeczywistym urządzeniu. Podobnie jak każde inne oprogramowanie, CTS może zawierać błędy. Pakiet CTS będzie wersjonowany niezależnie od tej definicji zgodności, a w przypadku Androida 10 może zostać opublikowanych wiele wersji pakietu CTS.

Implementacje na urządzeniach:

• [C-0-3] MUSI przejść najnowszą wersję CTS dostępną w momencie ukończenia oprogramowania urządzenia.

• W miarę możliwości powinny korzystać z implementacji referencyjnej w drzewie Android Open Source.

10.2. Weryfikator CTS

Weryfikator CTS jest częścią pakietu testów zgodności i jest przeznaczony do uruchamiania przez operatora w celu testowania funkcji, których nie można sprawdzić za pomocą systemu automatycznego, np. prawidłowego działania kamery i czujników.

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo wykonać wszystkie odpowiednie przypadki w weryfikatorze CTS.

Weryfikator CTS zawiera testy wielu rodzajów sprzętu, w tym niektórych opcjonalnych.

Implementacje na urządzeniach:

• [C-0-2] MUSZĄ przejść wszystkie testy sprzętu, który posiadają. Jeśli na przykład urządzenie ma akcelerometr, MUSI prawidłowo wykonać test akcelerometru w CTS Verifier.

Przypadki testowe funkcji oznaczonych w tym dokumencie definicji zgodności jako opcjonalne MOŻNA pominąć.

• [C-0-2] Każde urządzenie i każda kompilacja MUSZĄ prawidłowo uruchamiać weryfikator CTS zgodnie z powyższymi informacjami. Jednak ponieważ wiele kompilacji jest bardzo podobnych, nie oczekuje się, że producenci urządzeń będą uruchamiać weryfikator CTS na kompilacjach, które różnią się tylko w niewielkim stopniu. W szczególności implementacje urządzeń, które różnią się od implementacji, która przeszła test CTS Verifier, tylko zestawem uwzględnionych ustawień regionalnych, brandingiem itp., MOGĄ pominąć test CTS Verifier.

11. Oprogramowanie z możliwością aktualizacji

• [C-0-1] Implementacje urządzeń MUSZĄ zawierać mechanizm umożliwiający zastąpienie całego oprogramowania systemowego. Mechanizm nie musi przeprowadzać aktualizacji „na żywo”, czyli ponowne uruchomienie urządzenia MOŻE być wymagane. Możesz użyć dowolnej metody, o ile pozwala ona zastąpić całe oprogramowanie fabrycznie zainstalowane na urządzeniu. Wymaganie to spełnia np. każda z tych metod:

  • Pobieranie „bezprzewodowe” (OTA) z aktualizacją offline po ponownym uruchomieniu.
  • „Przywiązane” aktualizacje przez USB z komputera hosta.
  • Aktualizacje „offline” przez ponowne uruchomienie i aktualizację z pliku na nośniku wymiennym.

• [C-0-2] Używany mechanizm aktualizacji MUSI obsługiwać aktualizacje bez usuwania danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachowywać prywatne dane aplikacji i dane udostępnione aplikacji. Pamiętaj, że oprogramowanie Androida wyższego poziomu zawiera mechanizm aktualizacji, który spełnia to wymaganie.

• [C-0-3] Cała aktualizacja MUSI być podpisana, a mechanizm aktualizacji na urządzeniu MUSI weryfikować aktualizację i podpis względem klucza publicznego przechowywanego na urządzeniu.

• [C-SR] Mechanizm podpisywania ZDECYDOWANIE ZALECA się, aby zaszyfrować aktualizację za pomocą SHA-256 i zweryfikować skrót za pomocą klucza publicznego przy użyciu ECDSA NIST P-256.

Jeśli implementacja urządzenia obejmuje obsługę połączenia do transmisji danych bez limitu, np. 802.11 lub profilu Bluetooth PAN (Personal Area Network), to:

• [C-1-1] MUSI obsługiwać pobieranie aktualizacji OTA z aktualizacją offline po ponownym uruchomieniu.

W przypadku urządzeń wprowadzanych na rynek z Androidem 6.0 lub nowszym mechanizm aktualizacji POWINIEN obsługiwać weryfikację, czy obraz systemu jest binarnie identyczny z oczekiwanym wynikiem po aktualizacji OTA. Wdrożenie aktualizacji OTA opartej na blokach w projekcie Android Open Source Project, dodane w Androidzie 5.1, spełnia to wymaganie.

Implementacje urządzeń POWINNY też obsługiwać aktualizacje systemu A/B. AOSP implementuje tę funkcję za pomocą interfejsu HAL sterowania rozruchem.

Jeśli po wprowadzeniu urządzenia na rynek, ale w rozsądnym okresie jego użytkowania (określonym w porozumieniu z zespołem ds. zgodności Androida) zostanie wykryty błąd w jego implementacji, który wpływa na zgodność aplikacji innych firm, wówczas:

• [C-2-1] Producent urządzenia MUSI naprawić błąd za pomocą aktualizacji oprogramowania, którą można zastosować zgodnie z opisanym powyżej mechanizmem.

Android zawiera funkcje, które umożliwiają aplikacji właściciela urządzenia (jeśli jest obecna) kontrolowanie instalacji aktualizacji systemu. Jeśli podsystem aktualizacji systemu na urządzeniach zgłasza android.software.device_admin, oznacza to, że:

• [C-3-1] MUSI implementować zachowanie opisane w klasie SystemUpdatePolicy.

12. Historia zmian dokumentu

Podsumowanie zmian w definicji zgodności w tej wersji:

• Dziennik zmian dokumentu

Podsumowanie zmian w poszczególnych sekcjach:

1. Wprowadzenie
2. Typy urządzeń
3. Oprogramowanie
4. Pakowanie aplikacji
5. Multimedia
6. Narzędzia i opcje dla programistów
7. Zgodność sprzętu
8. Wydajność i zasilanie
9. Model zabezpieczeń
10. Testowanie zgodności oprogramowania
11. Oprogramowanie, które można aktualizować
12. Historia zmian dokumentu
13. Skontaktuj się z nami

12.1. Wskazówki dotyczące przeglądania historii zmian

Zmiany są oznaczone w ten sposób:

• CDD
  Istotne zmiany w wymaganiach dotyczących zgodności.

• Dokumenty
  Zmiany kosmetyczne lub związane z kompilacją.

Aby uzyskać najlepszy widok, dołącz do adresów URL dziennika zmian parametry URL pretty=full i no-merges.

13. Skontaktuj się z nami

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