Definicja zgodności z Androidem 9

1. Wprowadzenie

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

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

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

Aby implementacje urządzenia zostały uznane za zgodne z Androidem 9, MUSZĄ one spełniać wymagania przedstawione w tej definicji zgodności, w tym wszystkie dokumenty dołączone przez odniesienie.

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

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

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

1.1 Struktura dokumentu

1.1.1 Wymagania według typu urządzenia

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

Wszystkie pozostałe wymagania, które obowiązują we wszystkich implementacjach urządzeń z Androidem, zostały wymienione w sekcjach po Sekcji 2. Wymagania te są nazywane w tym dokumencie „wymaganiami podstawowymi”.

1.1.2 Identyfikator wymagania

W przypadku wymagań MUSZĄ przypisano identyfikator wymagania.

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

Każdy identyfikator jest zdefiniowany poniżej:

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

1.1.3 Identyfikator wymagania w sekcji 2

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

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

2. Typy urządzeń

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

W tej sekcji znajdziesz opis tych typów urządzeń oraz dodatkowe wymagania i zalecenia dotyczące każdego z nich.

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

2.1 Konfiguracje urządzeń

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

2.2. Wymagania dotyczące urządzenia mobilnego

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

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

• mieć źródło zasilania, które pozwala na mobilność, np. baterię.
• mieć fizyczny ekran o przekątnej ekranu w zakresie od 2,5 do 8 cala.

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

2.2.1. Urządzenie

Implementacje na urządzeniach mobilnych:

• [7.1.1.1/H-0-1] MUSI mieć ekran o przekątnej co najmniej 2,5 cala.
• [7.1.1.3/H-SR] Zdecydowanie ZALECANE jest umożliwienie użytkownikom zmiany rozmiaru wyświetlacza.(Gęstość ekranu).

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

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

Implementacje na urządzeniach mobilnych:

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

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

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

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

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

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

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

Implementacje na urządzeniach mobilnych:

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

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

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

Implementacje na urządzeniach mobilnych:

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

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

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

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

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

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

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

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

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

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

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

Pamiętaj, że pojęcie „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do dostępnego miejsca, oprócz pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio czy film, i które nie są pod kontrolą jądra implementacji urządzeń.

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

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

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

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

Implementacje na urządzeniach mobilnych:

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

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

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

Implementacje na urządzeniach mobilnych:

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

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

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

2.2.2. Multimedia

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać to kodowanie dźwięku:

• [5.1.1/H-0-1] AMR-NB
• [5.1.1/H-0-2] AMR-WB
• [5.1.1/H-0-3] Profil AAC MPEG-4 (AAC LC)
• [5.1.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
• [5.1.1/H-0-5] AAC ELD (rozszerzony AAC z niskim opóźnieniem)

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać to dekodowanie dźwięku:

• [5.1.2/H-0-1] AMR-NB
• [5.1.2/H-0-2] AMR-WB

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać poniższe kodowanie wideo i udostępniać je aplikacjom innych firm:

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

Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać to dekodowanie wideo:

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

2.2.3. Oprogramowanie

Implementacje na urządzeniach mobilnych:

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

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

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

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

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

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

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

Implementacje na urządzeniach mobilnych:

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

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

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

2.2.4 Wydajność i moc

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

Implementacje na urządzeniach mobilnych:

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

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

• [8.3/H-1-1] MUSI umożliwiać użytkownikom włączanie i wyłączanie funkcji oszczędzania baterii.
• [8.3/H-1-2] MUSI zapewniać użytkownikom dostęp do wszystkich aplikacji zwolnionych z trybów czuwania aplikacji i uśpienia.

Implementacje na urządzeniach mobilnych:

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

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

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

2.2.5. Model zabezpieczeń

Implementacje na urządzeniach mobilnych:

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

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

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

2.3. Wymagania dotyczące telewizora

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

Implementacje na urządzeniach z Androidem zaliczają się do telewizorów, jeśli spełniają wszystkie te kryteria:

• udostępnić mechanizm zdalnego sterowania renderowanym interfejsem użytkownika na wyświetlaczu, który może znajdować się w odległości ok. 3 metrów od użytkownika;
• Ekran musi mieć przekątny ekranu o przekątnej większej niż 24 cale LUB mieć port wyjściowy wideo, np. VGA, HDMI, DisplayPort lub bezprzewodowy.

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

2.3.1 Urządzenie

Implementacje na urządzeniach telewizyjnych:

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

Jeśli żyroskop obejmuje żyroskop:

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

Implementacje na urządzeniach telewizyjnych:

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

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

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

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

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

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

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

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

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

Pamiętaj, że pojęcie „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do dostępnego miejsca, oprócz pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio czy film, i które nie są pod kontrolą jądra implementacji urządzeń.

Implementacje na urządzeniach telewizyjnych:

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

2.3.2. Multimedia

Implementacje na telewizorach MUSZĄ obsługiwać te formaty kodowania dźwięku:

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

Implementacje na telewizory MUSZĄ obsługiwać te formaty kodowania wideo:

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

Implementacje na urządzeniach telewizyjnych:

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

Implementacje na telewizory MUSZĄ obsługiwać te formaty dekodowania wideo:

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

Zdecydowanie ZALECANE są implementacje urządzeń telewizyjnych do obsługi następujących formatów dekodowania wideo:

• [5.3.1/T-SR] MPEG-2

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

• [5.3.4.4/T-1-1] 1080p HD przy 60 klatkach na sekundę z profilem bazowym
• [5.3.4.4/T-1-2] 1080p HD przy 60 klatkach na sekundę z profilem głównym
• [5.3.4.4/T-1-3] HD 1080p przy 60 klatkach na sekundę z poziomem wysokiego profilu 4.2

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

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

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

• [5.3.5.5/T-2-1] MUSI obsługiwać profil dekodowania UHD z szybkością 60 klatek na sekundę w przypadku głównego profilu w poziomie Main10 Level 5.

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

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

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

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

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

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

Implementacje na urządzeniach telewizyjnych:

• [5.5.3/T-0-1] MUSI obsługiwać wyciszanie głównej głośności systemu i cyfrowego wyjścia audio na obsługiwanych wyjściach, z wyjątkiem skompresowanego przekazującego wyjścia audio (gdzie na urządzeniu nie jest wykonywane dekodowanie dźwięku).
• [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 na wszystkich wyświetlaczach przewodowych.
• [5.8/T-SR] Zdecydowanie ZALECANE jest zapewnienie dla wszystkich wyświetlaczy przewodowych konfigurowanego przez użytkownika selektora częstotliwości odświeżania przez HDMI.
• [5.8/T-SR] Zdecydowanie ZALECANE jest umożliwienie jednoczesnego dekodowania bezpiecznych strumieni. Zdecydowanie ZALECANE jest co najmniej jednoczesne dekodowanie dwóch par.
• [5.8] NALEŻY ustawić częstotliwość odświeżania trybu wyjścia HDMI na 50 lub 60 Hz w zależności od częstotliwości odświeżania wideo w regionie, w którym urządzenie jest sprzedawane w przypadku wszystkich wyświetlaczy przewodowych.

Jeśli implementacje urządzeń telewizyjnych obsługują dekodowanie UHD i zewnętrzne wyświetlacze,:

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

Jeśli implementacje urządzeń telewizyjnych nie obsługują dekodowania UHD, ale obsługują wyświetlacze zewnętrzne:

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

2.3.3 Oprogramowanie

Implementacje na urządzeniach telewizyjnych:

• [3/T-0-1] MUSI zadeklarować funkcje android.software.leanback i android.hardware.type.television.
• [3.4.1/T-0-1] MUSI zapewniać pełną implementację interfejsu API android.webkit.Webview.

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

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

Implementacje na urządzeniach telewizyjnych:

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

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

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

Implementacje na urządzeniach telewizyjnych:

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

2.3.4 Wydajność i moc

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

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

• [8.3/T-1-1] MUSI umożliwiać użytkownikom włączanie i wyłączanie funkcji oszczędzania baterii.
• [8.3/T-1-2] MUSI zapewniać dostępność dla użytkowników w celu wyświetlania wszystkich aplikacji wyłączonych z trybów czuwania aplikacji i uśpienia.

Implementacje na urządzeniach telewizyjnych:

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

2.4. Wymagania dotyczące zegarka

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

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

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

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

2.4.1. Urządzenie

Implementacje na zegarkach:

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

• [7.2.3/W-0-1] MUSI mieć dostęp do funkcji ekranu głównego i funkcji Wstecz z wyjątkiem funkcji UI_MODE_TYPE_WATCH.

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

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

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

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

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

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

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

2.4.2 Multimedia

Brak dodatkowych wymagań.

2.4.3 Oprogramowanie

Implementacje na zegarkach:

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

Implementacje na zegarkach:

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

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

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

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

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

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

2.4.4 Wydajność i moc

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

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

Implementacje na zegarkach:

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

2.5. Wymagania dotyczące motoryzacji

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

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

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

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

2.5.1 Urządzenie

Implementacje na urządzeniach motoryzacyjnych:

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

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

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

• [7.2.3/A-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno zdarzenie normalnego, jak i przytrzymania funkcji Back (KEYCODE_BACK).

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

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

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

Jeśli żyroskop obejmuje urządzenia motoryzacyjne:

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

Implementacje na urządzeniach motoryzacyjnych:

• [7.3.11/A-0-1] MUSI podać aktualny sprzęt jako SENSOR_TYPE_GEAR.

Implementacje na urządzeniach motoryzacyjnych:

• [7.3.11.2/A-0-1] MUSI obsługiwać tryb dzienny/nocny zdefiniowany jako SENSOR_TYPE_NIGHT.
• [7.3.11.2/A-0-2] Wartość flagi SENSOR_TYPE_NIGHT MUSI być zgodna z trybem dziennym/nocnym na pulpicie i POWINNA być uzależniona od danych z czujnika jasności otoczenia.

• Czujnik jasności otoczenia MOŻE być taki sam jak Fotometr.

• [7.3.11.4/A-0-1] MUSI podawać prędkość pojazdu zdefiniowaną przez SENSOR_TYPE_CAR_SPEED.

• [7.3.11.5/A-0-1] MUSI podawać stan hamulca postojowego określony w dokumencie SENSOR_TYPE_PARKING_BRAKE.

• [7.4.3/A-0-1] MUSI obsługiwać Bluetooth i POWINNO obsługiwać Bluetooth LE.

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

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

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

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

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

Implementacje na urządzeniach motoryzacyjnych:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pamiętaj, że pojęcie „pamięć dostępna dla jądra i przestrzeni użytkownika” powyżej odnosi się do dostępnego miejsca, oprócz pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio czy film, i które nie są pod kontrolą jądra implementacji urządzeń.

Implementacje na urządzeniach motoryzacyjnych:

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

Implementacje na urządzeniach motoryzacyjnych:

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

Implementacje na urządzeniach motoryzacyjnych:

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

2.5.2 Multimedia

Implementacje na urządzeniach motoryzacyjnych MUSZĄ obsługiwać to kodowanie dźwięku:

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

Implementacje na urządzeniach motoryzacyjnych MUSZĄ obsługiwać to kodowanie wideo:

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

Implementacje na urządzeniach motoryzacyjnych MUSZĄ obsługiwać to dekodowanie wideo:

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

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

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

2.5.3 Oprogramowanie

Implementacje na urządzeniach motoryzacyjnych:

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

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

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

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

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

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

• [3.13/A-SR] Zdecydowanie ZALECANE jest dodanie komponentu Szybkie ustawienia.

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

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

Implementacje na urządzeniach motoryzacyjnych:

• [3.14/A-0-1] MUSI zawierać platformę interfejsu do obsługi aplikacji innych firm korzystających z interfejsów API multimediów zgodnie z opisem w sekcji 3.14.

2.5.4 Wydajność i moc

Jeśli implementacje urządzeń z branży motoryzacyjnej obejmują funkcje poprawiające zarządzanie energią urządzenia uwzględnione w AOSP lub rozszerzające funkcje dostępne w AOSP:

• [8.3/A-1-1] MUSI umożliwiać użytkownikom włączanie i wyłączanie funkcji oszczędzania baterii.
• [8.3/A-1-2] MUSI zapewniać dostępność dla użytkowników w celu wyświetlania wszystkich aplikacji wyłączonych z trybów czuwania aplikacji i uśpienia.

Implementacje na urządzeniach motoryzacyjnych:

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

2.5.5 Model zabezpieczeń

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

• [9.5/A-1-1] MUSI zawierać konto gościa, które umożliwia korzystanie ze wszystkich funkcji systemu pojazdu bez konieczności logowania się użytkownika.

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

• [9.9.2/A-1-1] MUSI obsługiwać szyfrowanie dla poszczególnych kluczy uwierzytelniania użytkowników. Jednym ze sposobów jest szyfrowanie oparte na plikach (FBE).

Implementacje na urządzeniach motoryzacyjnych:

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

2.6. Wymagania dotyczące tabletu

Tablet z Androidem odnosi się do implementacji urządzenia z Androidem, która spełnia wszystkie te kryteria:

• Zwykle używa się, trzymania w obu dłoniach.
• Nie ma konfiguracji w tradycyjnej obudowie ani urządzenia konwertowalnego.
• Każda implementacja klawiatury fizycznej używana z urządzeniem MUSI nawiązywać połączenie za pomocą standardowego połączenia.
• Ma źródło zasilania, które umożliwia mobilność, np. baterię.
• ma fizyczny ekran o przekątnej w przedziale od 7 do 18 cali.

Implementacje na tabletach mają podobne wymagania jak w przypadku urządzeń mobilnych. Wyjątki zostały w tej sekcji oznaczone symbolami i *, a wyjątki uwzględniono w tej sekcji.

2.4.1. Urządzenie

Rozmiar ekranu

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

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

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

Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)

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

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

Tryb rzeczywistości wirtualnej (art. 7.9.1)

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

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

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

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

Implementacje na urządzeniach:

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

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

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

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

• [C-0-5] MUSI ograniczać korzystanie przez aplikacje innych firm z ukrytych interfejsów API zdefiniowanych jako interfejsy API w przestrzeni nazw Androida ozdobionych adnotacją @hidden, ale nie przy użyciu adnotacji @SystemAPI lub @TestApi, zgodnie z opisem w dokumentach pakietu SDK, zgodnie z opisem w dokumentach pakietu SDK oraz wysyłane z każdym ukrytym interfejsem API na tych samych listach ograniczonych, które są dostępne na tych samych listach ograniczonych, na tych samych listach ograniczonych i plikach listy odrzuconych w ścieżce prebuilts/runtime/appcompat/ odpowiedniej gałęzi interfejsu API w odpowiedniej gałęzi interfejsu API. Pamiętaj jednak, że:

  • Jeśli nie ma ukrytego interfejsu API lub został on inaczej zaimplementowany w implementacji urządzenia, przenieś go na listę odrzuconych lub pomiń go na wszystkich listach objętych ograniczeniami.
  • MOŻE: jeśli w AOSP nie ma jeszcze ukrytego interfejsu API, dodaj go do dowolnej listy objętej ograniczeniami.
  • MOŻNA wdrożyć mechanizm aktualizacji dynamicznej, który przenosi ukryty interfejs API z listy ograniczonej na mniej restrykcyjną listę z wyjątkiem listy dozwolonych.

3.1.1. Rozszerzenia na Androida

Android umożliwia rozszerzenie zarządzanych interfejsów API przy zachowaniu tej samej wersji na poziomie interfejsu API.

• [C-0-1] Implementacje na urządzeniach z Androidem MUSZĄ wstępnie wczytywać implementację AOSP biblioteki wspólnej ExtShared i usług ExtServices w wersji wyższej lub równej minimalnej dozwolonej wersji na każdym poziomie interfejsu API. Na przykład urządzenia z Androidem 7.0 korzystające z interfejsu API na poziomie 24 MUSZĄ zawierać co najmniej wersję 1.

3.1.2. Biblioteka Androida

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

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

Implementacja AOSP spełnia te wymagania.

3.2. Zgodność Soft API

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

3.2.1. Uprawnienia

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

3.2.2. Parametry kompilacji

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

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

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

3.2.3 Zgodność intencji

3.2.3.1. Podstawowe intencje aplikacji

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

• [C-0-1] Implementacje urządzeń MUSZĄ wstępnie wczytywać co najmniej 1 aplikację lub komponent usługi z modułem obsługi intencji dla wszystkich wzorców filtra intencji publicznych zdefiniowanych przez te podstawowe aplikacje na Androida w AOSP:

  • Zegar biurkowy
  • Przeglądarka
  • Kalendarz
  • Kontakty
  • Galeria
  • Wyszukiwanie globalne
  • Wyrzutnia
  • Muzyka
  • Ustawienia

3.2.3.2. Rozwiązanie intencji

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

• [C-0-2] Implementatorzy oprogramowania NIE MOGĄ przypisywać specjalnych uprawnień do korzystania z tych wzorców intencji przez aplikacje systemowe ani uniemożliwiać aplikacjom innych firm wiązania tych wzorców i przejmowania nad nimi kontroli. Zakaz ten obejmuje w szczególności m.in. wyłączenie interfejsu „Wybór”, który pozwala użytkownikowi wybierać spośród wielu aplikacji, które obsługują ten sam wzorzec intencji.

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

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

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

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

3.2.3.3 Przestrzenie nazw intencji

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

3.2.3.4. Intencje związane z transmisją

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

Implementacje na urządzeniach:

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

3.2.3.5. Domyślne ustawienia aplikacji

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

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

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

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

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

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

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

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

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

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

• [C-3-1] MUSI uwzględniać intencję android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlać domyślne menu ustawień funkcji Zbliż i zapłać.

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

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

3.2.4 Działania na ekranach dodatkowych

Jeśli implementacje urządzeń pozwalają na uruchamianie zwykłych aktywności na Androidzie na ekranach dodatkowych:

• [C-1-1] MUSI ustawiać flagę funkcji android.software.activities_on_secondary_displays.
• [C-1-2] MUSI gwarantować zgodność z interfejsem API podobną do działania wykonywanego na ekranie głównym.
• [C-1-3] Nowa aktywność MUSI trafiać na ten sam ekran co aktywność, która uruchomiła je po uruchomieniu, bez określania docelowego sposobu wyświetlania przez interfejs API ActivityOptions.setLaunchDisplayId().
• [C-1-4] MUSI zniszczyć wszystkie działania, jeśli wyświetlany jest ekran z flagą Display.FLAG_PRIVATE.
• [C-1-5] MUSI odpowiednio dostosować rozmiar wszystkich działań na VirtualDisplay, jeśli rozmiar wyświetlacza się zmienia.
• MOŻE wyświetlić IME (edytor metody wprowadzania tekstu, czyli element sterujący, który umożliwia użytkownikom wpisywanie tekstu) na ekranie głównym, gdy pole tekstowe zostanie zaznaczone na wyświetlaczu dodatkowym.
• Trzeba ustawić fokus wejściowy na wyświetlaczu dodatkowym niezależnie od wyświetlacza głównego, jeśli obsługiwane są dane dotykowe lub klawisze.
• POWINNY jest zawierać parametr android.content.res.Configuration odpowiadający temu wyświetlaczowi, aby mógł być wyświetlany, działać prawidłowo i zachować zgodność w przypadku uruchomienia aktywności na wyświetlaczu dodatkowym.

Jeśli implementacje urządzeń pozwalają na uruchamianie zwykłych aktywności na Androidzie na ekranach dodatkowych, a ekrany główne i dodatkowe mają różne parametry android.util.DisplayMetrics:

• [C-2-1] Aktywności bez możliwości zmiany rozmiaru (które mają wartość resizeableActivity=false w AndroidManifest.xml) i aplikacje kierowane na interfejs API na poziomie 23 lub niższym NIE MOGĄ być dozwolone na wyświetlaczach dodatkowych.

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

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

3.3. Zgodność z natywnym interfejsem API

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

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

3.3.1 Interfejsy binarne aplikacji

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

Implementacje na urządzeniach:

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

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

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

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

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

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

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

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

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

3.3.2 Zgodność z 32-bitowym kodem natywnym ARM

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

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

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

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

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

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

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

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

3.4 Zgodność z internetem

3.4.1 Zgodność z WebView

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

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

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

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

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

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

3.4.2. Zgodność z przeglądarką

Jeśli implementacje urządzeń obejmują samodzielną aplikację przeglądarki do ogólnego przeglądania internetu, one:

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

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

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

3.5. Zgodność behawioralna interfejsu API

Implementacje na urządzeniach:

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

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

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

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

3.5.1 Ograniczenie działania w tle

Jeśli implementacje na urządzeniach uwzględniają ograniczenia aplikacji uwzględnione w AOSP lub rozszerzają ograniczenia aplikacji:

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

3.6. Przestrzenie nazw interfejsów API

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

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

Oznacza to, że:

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

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

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

Jednak narzędzia implementujące urządzenia MOGĄ dodawać niestandardowe interfejsy API poza standardową przestrzenią nazw Androida, ale niestandardowe interfejsy API:

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

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

Powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java. Ta sekcja ma tylko pomóc wzmocnić te konwencje i nadać im wiążący charakter przez uwzględnienie ich w tej definicji zgodności.

3.7. Zgodność środowiska wykonawczego

Implementacje na urządzeniach:

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

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

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

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

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

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

3.8. Zgodność interfejsu użytkownika

3.8.1 Menu z aplikacjami (ekran główny)

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

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

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

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

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

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

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

Jeśli implementacje urządzeń implementują domyślny program uruchamiający, który zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm przy użyciu interfejsu API Skrót Manager, powoduje to:

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

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

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

3.8.2 Widżety

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

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

• [C-1-1] MUSI zadeklarować obsługę funkcji platformy android.software.app_widgets.
• [C-1-2] MUSI zawierać wbudowaną obsługę widżetów AppWidgets i udostępniać afordancje interfejsu użytkownika w celu dodawania, konfigurowania, wyświetlania i usuwania elementów AppWidgets bezpośrednio w Menu z aplikacjami.
• [C-1-3] MUSI wyświetlać widżety o wymiarach 4 x 4 w standardowym rozmiarze siatki. Szczegółowe informacje znajdziesz w artykule App Widget DesignGuidelines w dokumentacji pakietu Android SDK.
• MOŻE obsługiwać widżety aplikacji na ekranie blokady.

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

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

3.8.3 Powiadomienia

Android obejmuje interfejsy API Notification i NotificationManager, które umożliwiają deweloperom aplikacji innych firm powiadamianie użytkowników o ważnych wydarzeniach i przyciąganie uwagi użytkowników za pomocą komponentów sprzętowych (np. dźwięku, wibracji i światła) oraz funkcji oprogramowania (takich jak obszar powiadomień czy pasek systemu) urządzenia.

3.8.3.1 Prezentacja powiadomień

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

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

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

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

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

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

3.8.3.2 Usługa powiadamiania słuchaczy

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

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

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

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

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

3.8.3.3 Nie przeszkadzać

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

• [C-1-1] MUSI zaimplementować działanie, które odpowiada na intencję ACTION_CONFIRM_POLICY_ACCESS_SETTINGS. W przypadku implementacji z interfejsem UI_MODE_TYPE_NORMAL MUSI być to działanie, w ramach którego użytkownik może przyznawać i odbierać dostęp aplikacji do konfiguracji zasad Nie przeszkadzać.
• [C-1-2] Jeśli implementacja urządzenia umożliwia użytkownikowi przyznawanie lub odrzucanie dostępu aplikacji innych firm do konfiguracji zasad Nie przeszkadzać, MUSI wyświetlać obok utworzonych przez użytkownika i wstępnie zdefiniowanych reguł Automatyczne reguły Nie przeszkadzać utworzone przez aplikacje.
• [C-1-3] MUSI uwzględniać wartości suppressedVisualEffects przekazywane w elemencie NotificationManager.Policy, a jeśli aplikacja ma ustawioną dowolną z flag SUPPRESSED_EFFECT_SCREEN_OFF lub SUPPRESSED_FE_SCREEN_ON, MUSI poinformować użytkownika, że efekty wizualne są wyłączone w menu ustawień Nie przeszkadzać.

3.8.4 Szukaj

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

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

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

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

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

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

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

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

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

3.8.5 Alerty i powiadomienia

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

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

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

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

3.8.6 Motywy graficzne

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

Android obejmuje rodzinę motywów „Holo” i „Materiał” jako zestaw stylów zdefiniowanych przez deweloperów aplikacji, których mogą używać, jeśli chcą pasować do wyglądu i stylu motywu Holo określonego w pakiecie SDK Androida.

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

• [C-1-1] NIE MOŻE zmieniać żadnych atrybutów motywu Holo, które są widoczne dla aplikacji.
• [C-1-2] MUSI obsługiwać motywy „Materiał” i NIE MOŻE zmieniać żadnych atrybutów motywu Material Design, ani ich zasobów widocznych dla aplikacji.

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

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

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

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

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

3.8.7 Animowane tapety

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

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

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

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

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

3.8.8 Przełączanie aktywności

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

Implementacje urządzeń obejmujące klawisz nawigacyjny funkcji najnowszych wiadomości zgodnie z opisem w sekcji 7.2.3 MOGĄ zmienić interfejs.

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

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

3.8.9 Zarządzanie danymi wejściowymi

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

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

• [C-1-1] MUSI zadeklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy API IME zgodnie z definicją w dokumentacji pakietu Android SDK.
• [C-1-2] MUSI udostępniać dostępny dla użytkownika mechanizm umożliwiający dodawanie i konfigurowanie metod wprowadzania innych firm w odpowiedzi na intencję android.settings.INPUT_METHOD_SETTINGS.

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

• [C-2-1] MUSI w pełni wdrożyć interfejsy API AutofillService i AutofillManager oraz przestrzegać intencji android.settings.REQUEST_SET_AUTOFILL_SERVICE, aby wyświetlać domyślne menu ustawień aplikacji, aby włączyć lub wyłączyć autouzupełnianie oraz zmienić domyślną usługę autouzupełniania dla użytkownika.

3.8.10. Sterowanie multimediami na ekranie blokady

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

3.8.11 Wygaszacze ekranu (wcześniej Sny)

Android zapewnia obsługę interaktywnych wygaszaczy ekranu, znanych wcześniej jako Dreams. Wygaszacze ekranu pozwalają użytkownikom korzystać z aplikacji, gdy urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji dokującej. Urządzenia Android Watch MOGĄ obsługiwać wygaszacze ekranu, ale inne implementacje urządzeń POWINNY zawierać ich obsługę oraz umożliwiać użytkownikom konfigurowanie wygaszaczy ekranu w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

3.8.12. Lokalizacja

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

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

3.8.13. Unicode i czcionka

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

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

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

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

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

3.8.14. Wiele okien

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

• [C-1-1] MUSI wdrożyć takie tryby wielu okien zgodnie z działaniami aplikacji i interfejsami API opisanymi w dokumentacji dotyczącej obsługi trybu wielu okien w pakiecie Android SDK oraz spełnić te wymagania:
• [C-1-2] Aplikacje można określić, czy mogą działać w trybie wielu okien w pliku AndroidManifest.xml. Można to zrobić jawnie przez ustawienie atrybutu android:resizeableActivity na true lub domyślnie przez ustawienie targetSdkVersion > 24. Aplikacje, w których w pliku manifestu ustawisz ten atrybut na false, NIE MOGĄ być uruchamiane w trybie wielu okien. Starsze aplikacje z targetSdkVersion < 24, w których nie ustawiono tego atrybutu android:resizeableActivity, MOGĄ zostać uruchomione w trybie wielu okien, ale system MUSI wyświetlać ostrzeżenie, że aplikacja może nie działać zgodnie z oczekiwaniami w tym trybie.
• [C-1-3] NIE MOŻE wyświetlać trybu podzielonego ani dowolnego ekranu, jeśli wysokość ekranu < 440 dp i szerokość ekranu < 440 dp.
• Implementacje na urządzeniach o rozmiarze ekranu xlarge POWINNY obsługiwać tryb dowolny.

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

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

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

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

3.8.15. Wycięcie w sieci reklamowej

Android obsługuje wycięcie w sieci reklamowej zgodnie z opisem w dokumencie na temat pakietu SDK. Interfejs API DisplayCutout definiuje na krawędzi wyświetlacza obszar, w którym nie można wyświetlać treści.

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

• [C-1-1] MUSI mieć wycięcia wyłącznie na krótkich krawędziach urządzenia. Jeśli natomiast 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 w ekranie ustawione przez aplikację za pomocą interfejsu API WindowManager.LayoutParams zgodnie z opisem w pakiecie SDK.
• [C-1-4] MUSI podawać prawidłowe wartości dla wszystkich danych o wycięciu zdefiniowanych w interfejsie API DisplayCutout.

3.9. Administracja urządzeniem

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

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

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

3.9.1 Obsługa administracyjna urządzeń

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

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

• [C-1-1] MUSI obsługiwać rejestrację klienta Device Policy (DPC) jako aplikacji właściciela urządzenia w sposób opisany poniżej:
  • Jeśli w implementacji urządzenia nie skonfigurowano jeszcze danych użytkownika:
    • [C-1-3] MUSI zgłosić true za DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] W odpowiedzi na działanie intencji android.app.action.PROVISION_MANAGED_DEVICE MUSI zarejestrować aplikację DPC jako właściciela urządzenia.
    • [C-1-5] MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia, jeśli urządzenie zadeklaruje obsługę komunikacji Near Field Communication (NFC) za pomocą flagi funkcji android.hardware.nfc i otrzyma wiadomość NFC zawierającą rekord z typem MIME MIME_TYPE_PROVISIONING_NFC.
  • Gdy implementacja urządzenia zawiera dane użytkownika:
    • [C-1-6] MUSI zgłosić false za DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] NIE MOŻE rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia.
• [C-1-2] MUSI wymagać uzyskania zgody na ustawienie aplikacji jako właściciela urządzenia podczas procesu obsługi administracyjnej. Zgodę można wyrazić w wyniku działania użytkownika lub w ramach automatyzacji podczas obsługi administracyjnej, 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ą funkcję android.software.device_admin, ale zawierają też zastrzeżone rozwiązanie do zarządzania właścicielem urządzenia oraz zapewniają mechanizm promowania aplikacji skonfigurowanej w danym rozwiązaniu jako „odpowiednika dla właściciela urządzenia” znanej przez standardowe interfejsy API Androida DevicePolicyManager, muszą one:

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

3.9.1.2 Obsługa administracyjna profili zarządzanych

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

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

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

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

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

3.9.2 Obsługa profilu zarządzanego

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

• [C-1-1] MUSI obsługiwać profile zarządzane za pomocą interfejsów API android.app.admin.DevicePolicyManager.
• [C-1-2] MUSI zezwalać na utworzenie tylko jednego profilu zarządzanego.
• [C-1-3] MUSI używać plakietki ikony (podobnej do odznaki AOSP dotyczącej pracy nad aplikacją) do reprezentowania zarządzanych aplikacji i widżetów oraz innych elementów interfejsu z plakietką, takich jak Ostatnie i powiadomienia.
• [C-1-4] MUSI wyświetlać ikonę powiadomień (podobną do plakietki służbowej AOSP na poziomie nadrzędnym), aby wskazać, że użytkownik korzysta z aplikacji profilu zarządzanego.
• [C-1-5] MUSI wyświetlać komunikat informujący o tym, że użytkownik korzysta z profilu zarządzanego, gdy urządzenie zostanie wybudzone (ACTION_USER_PRESENT), a aplikacja na pierwszym planie znajduje się w profilu zarządzanym.
• [C-1-6] Jeśli istnieje profil zarządzany, MUSI pokazywać wizualną afordancję w sekcji „Chooser” intencji, aby umożliwić użytkownikowi przekazywanie intencji z profilu zarządzanego głównemu użytkownikowi lub odwrotnie, jeśli ta funkcja jest włączona przez kontroler zasad dotyczących urządzeń.
• [C-1-7] Jeśli istnieje profil zarządzany, MUSI udostępniać następujące parametry użytkowników zarówno dla użytkownika głównego, jak i profilu zarządzanego:
  • Osobne zliczanie baterii, lokalizacji, mobilnej transmisji danych i wykorzystania miejsca na dane przez użytkownika głównego i profil zarządzany.
  • Niezależne zarządzanie aplikacjami VPN zainstalowanymi u głównego użytkownika lub profilu zarządzanego.
  • Niezależne zarządzanie aplikacjami zainstalowanymi u głównego użytkownika lub profilu zarządzanego.
  • Niezależne zarządzanie kontami w ramach głównego użytkownika lub profilu zarządzanego.
• [C-1-8] Zainstalowane aplikacje do połączeń telefonicznych, kontaktów i wiadomości mogą wyszukiwać i wyszukiwać informacje o rozmówcy z profilu zarządzanego (jeśli taki istnieje) razem z profilami głównymi (jeśli kontroler zasad dotyczących urządzeń na to zezwala).
• [C-1-9] MUSI spełniać wszystkie wymagania bezpieczeństwa obowiązujące na urządzeniu z włączoną obsługą wielu użytkowników (patrz sekcja 9.5), mimo że profil zarządzany nie jest liczony jako inny użytkownik oprócz głównego użytkownika.
• [C-1-10] MUSI obsługiwać możliwość określenia osobnego ekranu blokady spełniającego poniższe wymagania, aby przyznać dostęp do aplikacji działających w profilu zarządzanym.
  • Implementacje urządzeń MUSZĄ spełniać intencję DevicePolicyManager.ACTION_SET_NEW_PASSWORD i zawierać interfejs umożliwiający skonfigurowanie osobnych danych logowania na ekranie blokady dla profilu zarządzanego.
  • Dane logowania na ekran blokady profilu zarządzanego MUSZĄ korzystać z tego samego magazynu danych logowania i mechanizmów zarządzania co w profilu nadrzędnym, co zostało opisane na stronie projektu Android Open Source.
  • Zasady dotyczące haseł DPC MUSZĄ mieć zastosowanie tylko do danych logowania na ekranie blokady profilu zarządzanego, chyba że zostaną wywołane przez wystąpienie DevicePolicyManager zwrócone przez getParentProfileInstance.
• Gdy kontakty z profilu zarządzanego są wyświetlane we wstępnie zainstalowanym rejestrze połączeń, interfejsie połączenia, powiadomieniach w toku i nieodebranych połączeniach, kontaktach i aplikacjach do obsługi wiadomości, powinny mieć tę samą plakietkę, która oznacza aplikacje profilu zarządzanego.

3.9.3 Zarządzana pomoc dla użytkowników

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

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

3.10. Ułatwienia dostępu

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

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

• [C-1-1] MUSI zawierać implementację platformy ułatwień dostępu w Androidzie w sposób opisany w dokumentacji pakietu SDK interfejsów Accessibility API.
• [C-1-2] MUSI generować zdarzenia ułatwień dostępu i dostarczać odpowiednie AccessibilityEvent we wszystkich zarejestrowanych implementacjach AccessibilityService zgodnie z dokumentacją w pakiecie SDK.
• [C-1-3] MUSI uwzględniać intencję android.settings.ACCESSIBILITY_SETTINGS zapewniającą dostępny dla użytkowników mechanizm włączania i wyłączania usług ułatwień dostępu innych firm obok wstępnie zainstalowanych usług 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 zadeklarują element AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Pamiętaj, że w przypadku implementacji urządzeń bez paska nawigacyjnego systemu ten wymóg nie ma zastosowania, ale implementacje urządzeń MUSZĄ dawać użytkownikowi możliwość sterowania tymi usługami ułatwień dostępu.

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

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

3.11. Przekształcanie tekstu na mowę

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

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

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

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

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

3.12. Platforma wejścia TV

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

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

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

3.13. Szybkie ustawienia

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

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

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

3.14. Interfejs multimediów

Jeśli implementacje urządzeń obejmują platformę interfejsu obsługującą aplikacje innych firm, które korzystają z MediaBrowser i MediaSession, to:

• [C-1-1] Ikony MediaItem i ikony powiadomień MUSZĄ wyświetlać w niezmienionej formie.
• [C-1-2] MUSI wyświetlać te elementy w sposób opisany przez MediaSession, np. metadane, ikony, obrazy.
• [C-1-3] MUSI pokazywać tytuł aplikacji.
• [C-1-4] MUSI zawierać panel lub inny mechanizm wyświetlający hierarchię Media Browser i zapewnić aprobatę użytkownika w hierarchii Media Browser.
• [C-1-5] W przypadku MediaSession.Callback#onMediaButtonEvent MUSISZ kliknąć dwukrotnie KEYCODE_HEADSETHOOK lub KEYCODE_MEDIA_PLAY_PAUSE jako KEYCODE_MEDIA_NEXT.

3.15. Aplikacje błyskawiczne

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

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

3.16. Parowanie urządzenia towarzyszącego

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

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

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

3.17. Aplikacje do wagi

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

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

Jeśli implementacje na urządzeniach nie zadeklarują funkcji FEATURE_CANT_SAVE_STATE, wówczas:

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

4. Zgodność pakietów aplikacji

Implementacje urządzeń:

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

Implementacje na urządzeniach:

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

• [C-0-4] NIE MOŻE zezwalać aplikacjom innym niż obecny „instalator, który zarejestrował” pakiet na dyskretne odinstalowanie aplikacji bez potwierdzenia ze strony użytkownika, zgodnie z opisem w pakiecie SDK dotyczącym uprawnień DELETE_PACKAGE. Jedynymi wyjątkami są aplikacja weryfikatora pakietów systemowych obsługująca intencję PACKAGE_NEEDS_VERIFICATION i intencja ACTION_MANAGE_STORAGE aplikacji menedżera miejsca.

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

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

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

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

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

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

5. Zgodność multimediów

Implementacje na urządzeniach:

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

Implementacje na urządzeniach:

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

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

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

5.1. Kodeki multimediów

5.1.1 Kodowanie dźwięku

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

Jeśli implementacje urządzeń deklarują android.hardware.microphone, MUSZĄ obsługiwać to kodowanie dźwięku:

• [C-1-1] PCM/WAVE

5.1.2 Dekodowanie dźwięku

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

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

• [C-1-1] Profil AAC MPEG-4 (AAC LC)
• [C-1-2] Profil AAC MPEG-4 HE (AAC+)
• [C-1-3] Profil MPEG-4 HE AACv2 (ulepszony AAC+)
• [C-1-4] AAC ELD (rozszerzony format AAC z niskim opóźnieniem)
• [C-1-11] xHE-AAC (Rozszerzony profil HE AAC zgodny ze standardem ISO/IEC 23003-3 zawierający profil bazowy USAC oraz profil kontroli zakresu dynamiki ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE
• [C-1-10] Opus

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

• [C-2-1] Dekodowanie MUSI być wykonywane bez redmiksowania (np. strumień AAC 5.0 musi być zdekodowany na 5 kanałów PCM, a strumień AAC 5.1 – na 6 kanałów PCM).
• [C-2-2] Metadane zakresu dynamicznego MUSZĄ być zgodne z definicją w dokumencie „Dynamic Range Control (DRC)” w standardzie ISO/IEC 14496-3 oraz kluczami DRC android.media.MediaFormat w celu skonfigurowania działania dekodera dźwięku w zakresie dynamiki. Klucze AAC DRC zostały wprowadzone w interfejsie API 21. Są to: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_ENCODED_TARGET_LEVEL.

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

• [C-3-1] Natężenie dźwięku i metadane DRC MUSZĄ być interpretowane i stosowane zgodnie z poziomem 1 profilu kontroli zakresu dynamiki MPEG-D DRC.
• [C-3-2] Dekoder MUSI działać zgodnie z konfiguracją ustawioną za pomocą tych kluczy android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_DRC_EFFECT_TYPE.

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

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

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

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

5.1.3 Szczegóły kodeków audio

Format/kodek	Szczegóły	Obsługiwane typy plików/formaty kontenerów
Profil AAC MPEG-4 (AAC LC)	Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 8 do 48 kHz.	3GPP (.3GPP) MPEG-4 (.mp4, .m4a) Nieprzetworzony kod AAC ADTS (AAC, ADIF nie jest obsługiwany) MPEG-TS (.ts, bez możliwości przewijania)
Profil MPEG-4 HE AAC (AAC+)	Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.
MPEG-4 HE AACv2 Profil (ulepszony AAC+)	Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.
AAC ELD (rozszerzone AAC z niskim opóźnieniem)	Obsługa treści mono/stereo ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.
USAC	Obsługa treści mono/stereo ze standardowymi częstotliwościami próbkowania od 7,35 do 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75–12,2 kb/s, próbkowanie przy 8 kHz	3GPP (.3GPP)
AMR-WB	9 częstotliwości od 6,60 kb/s do 23,85 kb/s, próbkowanie przy 16 kHz
FLAC	Mono/Stereo (brak wielokanałowego). Częstotliwość próbkowania do 48 kHz (zalecamy ustawienie maks. 44,1 kHz w przypadku urządzeń z częstotliwością wyjściową 44,1 kHz, ponieważ redukcja częstotliwości próbkowania od 48 do 44,1 kHz nie zawiera filtra dolnoprzepustowego. 16-bitowy (ZALECANY) bez ditheringu w przypadku wersji 24-bitowej.	Tylko FLAC (.flac)
MP3	Stała szybkość transmisji bitów mono/Stereo 8–320 kb/s (CBR) lub zmienna szybkość transmisji bitów (VBR)	MP3 (.mp3)
MIDI	MIDI typu 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody	Wpisz 0 i 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		Ogg (.ogg) Matroska (.mkv, Android 4.0 lub nowszy)
PCM/WAVE	16-bitowy linearny PCM (oprocentowanie do limitu sprzętowego). Urządzenia MUSZĄ obsługiwać częstotliwość próbkowania w przypadku nieprzetworzonego nagrywania PCM przy częstotliwościach 8000, 11025, 16 000 i 44 100 Hz.	WAVE (.wav)
Opus		matroska (.mkv), Ogg(.ogg)

5.1.4 Kodowanie obrazu

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

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

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

5.1.5 Dekodowanie obrazu

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

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

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

5.1.6 Szczegóły kodeków obrazu

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

5.1.7 Kodeki wideo

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

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

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

• [C-1-2] Kodery i dekodery wideo MUSZĄ obsługiwać elastyczny format kolorów YUV420 (color_FormatYUV420Elastyczne).

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

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

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

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

5.1.8 Lista kodeków wideo

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

5.2. Kodowanie wideo

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

• W 2 przesuniętych oknach NIE POWINNO być o więcej niż 15% powyżej szybkości transmisji bitów między interwałami w ramce (I-frame).
• Szybkość transmisji bitów NIE POWINNO przekraczać ok. 100% w przesuwanym oknie o długości 1 sekundy.

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

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

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

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

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

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

5.2.1 H.263

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

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

5.2.2 H-264

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

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

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

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

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

5.2.3 VP8

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

• [C-1-1] MUSI obsługiwać profile kodowania wideo SD.
• POWINNA obsługiwać poniższe profile kodowania wideo HD (High Definition).
• MUSI obsługiwać tworzenie plików Matroska WebM.
• W celu zapewnienia akceptowalnej jakości strumieniowych transmisji wideo w internecie i usług do prowadzenia rozmów wideo POWINNY jest używać sprzętowego kodeka VP8, który spełnia wymagania dotyczące sprzętowego kodowania RTC w projekcie WebM.

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

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

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

5.2.4 VP9

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

• MUSI obsługiwać tworzenie plików Matroska WebM.

5.3. Dekodowanie wideo

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

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

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

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

5.3.1 MPEG-2

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

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

5.3.2 H.263

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

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

5.3.3 MPEG-4

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

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

5.3.4 H.264

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

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

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

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

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

5.3.5 H.265 (HEVC)

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

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

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

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

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

5.3.6 VP8

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

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

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

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

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

5.3.7 VP9

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

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

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

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

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

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

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

5.4. Nagrywanie dźwięku

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

5.4.1 Przechwytywanie nieprzetworzonego dźwięku

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

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

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

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

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

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

  • Format: linearny PCM, 16-bitowy
  • Częstotliwość próbkowania: 22 050, 48 000 Hz
  • Kanały: stereo

Jeśli implementacje urządzeń umożliwiają przechwytywanie nieprzetworzonych treści audio za pomocą radia AM i DVD w jakości:

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

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

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

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

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

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

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

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

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

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

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

5.5. Odtwarzanie dźwięku

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

5.5.1 Odtwarzanie surowego dźwięku

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

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

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

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

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

5.5.2 Efekty audio

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

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

• [C-1-1] MUSI obsługiwać implementacje EFFECT_TYPE_EQUALIZER i EFFECT_TYPE_LOUDNESS_ENHANCER sterowane za pomocą podklasy AudioEffect Equalizer, LoudnessEnhancer.
• [C-1-2] MUSI obsługiwać implementację interfejsu API wizualizacji, którą można kontrolować za pomocą klasy Visualizer.
• [C-1-3] MUSI obsługiwać implementację EFFECT_TYPE_DYNAMICS_PROCESSING sterowaną przez podklasę AudioEffect DynamicsProcessing.
• POWINNA obsługiwać implementacje EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB i EFFECT_TYPE_VIRTUALIZER, które można kontrolować za pomocą klas podrzędnych BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.AudioEffect

5.5.3 Wyjściowa głośność dźwięku

Implementacje na urządzeniach motoryzacyjnych:

• POWINNY jest zezwalać na dostosowanie głośności dźwięku oddzielnie dla każdego strumienia audio z użyciem typu lub użycia treści zdefiniowanego w Atrybutach audio oraz użycia audio w samochodzie (zgodnie z definicją w zasadzie android.car.CarAudioManager).

5.6. Opóźnienie dźwięku

Opóźnienie dźwięku to czas, w którym sygnał audio przechodzi przez system. Wiele klas aplikacji korzysta z krótkich czasów oczekiwania, aby uzyskać efekty dźwiękowe w czasie rzeczywistym.

Na potrzeby tej sekcji należy stosować następujące definicje:

• opóźnienia wyjścia. Odstęp czasu między momentem, w którym aplikacja zapisuje ramkę danych kodowanych w PCM, a odebraniem odpowiedniego dźwięku w środowisku przez przetwornik lub sygnał urządzenia.
• opóźnienia „na zimno”. Opóźnienie wyjścia dla pierwszej klatki, gdy system wyjściowy audio był bezczynny i wyłączony przed żądaniem.
• ciągły czas oczekiwania na sygnał wyjściowy. Opóźnienie wyjściowe kolejnych klatek po odtworzeniu dźwięku na urządzeniu.
• opóźnienia sygnału wejściowego. Odstęp czasu między momentem, w którym otoczenie trafia do urządzenia z przetwornikiem lub sygnałem na urządzeniu, a odstępem między momentem, w którym aplikacja odczytuje odpowiednią ramkę danych kodowanych w PCM.
• utraconych danych wejściowych. Początkowa część sygnału wejściowego, który jest bezużyteczny lub niedostępny.
• opóźnienia „zimnego sygnału wejściowego”. Suma utraconego czasu sygnału wejściowego i opóźnienia wejściowego dla pierwszej klatki, gdy system wejścia audio był bezczynny i wyłączony przed żądaniem.
• ciągłe opóźnienie sygnału wejściowego. Opóźnienie sygnału wejściowego dla kolejnych klatek, gdy urządzenie rejestruje dźwięk.
• zakłócenia przy zimnie. Zmienność między osobnymi pomiarami wartości czasu oczekiwania na zimne wyjście.
• zakłócenia przy zimnie. Zmienność między osobnymi pomiarami wartości czasu oczekiwania na zimno.
• ciągłe opóźnienie w obie strony. Suma ciągłych opóźnień sygnału wejściowego i ciągłego czasu oczekiwania na dane wyjściowe plus 1 okres buforowania. Okres buforowania daje aplikacji czas na przetworzenie sygnału i czas potrzebny aplikacji na zniwelowanie różnicy fazowej między strumieniami wejściowymi i wyjściowymi.
• Interfejs API kolejki buforowej OpenSL ES PCM. Zestaw interfejsów API OpenSL ES związanych z PCM w Androidzie NDK.
• Natywny interfejs API audio audio Zestaw interfejsów API AAudio w systemie Android NDK.
• Sygnatura czasowa. Para składająca się z względnego położenia klatki w strumieniu i szacunkowego czasu, w którym dana klatka pojawia się w potoku przetwarzania dźwięku lub go opuszcza w powiązanym punkcie końcowym. Zobacz też AudioTimestamp.

Jeśli implementacje urządzeń deklarują użycie funkcji android.hardware.audio.output, Zdecydowanie ZALECANE jest spełnienie lub przekroczenie tych wymagań:

• [C-SR] Opóźnienie podczas wczytywania „na zimno” (maksymalnie 100 milisekund)
• [C-SR] Ciągłe opóźnienie sygnału wyjściowego wynoszące maksymalnie 45 milisekund
• [C-SR] Zminimalizuj zakłócenia na zimno
• [C-SR] Sygnatura czasowa wyjścia zwracana przez funkcję AudioTrack.getTimestamp i AAudioStream_getTimestamp ma dokładność z dokładnością do +/- 1 ms.

Jeśli implementacje urządzeń spełniają powyższe wymagania, po pierwszej kalibracji i korzystanie z kolejki bufora OpenSL ES PCM i natywnych interfejsów API audio AAudio, pod kątem ciągłego opóźnienia wyjściowego i opóźnienia „na zimno” na co najmniej jednym obsługiwanym urządzeniu wyjściowym audio, są to:

• [C-SR] Zdecydowanie ZALECANE jest przesyłanie dźwięku z małym opóźnieniem przez zadeklarowanie flagi funkcji android.hardware.audio.low_latency.
• [C-SR] Zdecydowanie ZALECANE jest spełnienie wymagań dotyczących dźwięku z małym opóźnieniem przez interfejs AAudio API.
• [C-SR] Zdecydowanie zalecamy, aby w przypadku strumieni, które zwracają wartość AAUDIO_PERFORMANCE_MODE_LOW_LATENCY z AAudioStream_getPerformanceMode(), wartość zwrócona przez AAudioStream_getFramesPerBurst() jest mniejsza lub równa wartości zwróconej przez android.media.AudioManager.getProperty(String) dla klucza usługi AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Jeśli implementacje urządzeń nie spełniają wymagań dotyczących dźwięku z małym opóźnieniem w kolejce bufora OpenSL ES PCM i natywnych interfejsach API audio AAudio:

• [C-1-1] NIE MOŻE zgłaszać obsługi dźwięku z małym opóźnieniem.

Jeśli implementacje urządzeń obejmują android.hardware.microphone, Zdecydowanie ZALECANE są, aby spełniały one te wymagania dotyczące wejściowego dźwięku:

• [C-SR] Opóźnienie reakcji „na zimno” nie większe niż 100 milisekund.
• [C-SR] Ciągłe opóźnienie sygnału wejściowego wynoszące maksymalnie 30 milisekund.
• [C-SR] Ciągłe opóźnienie w obie strony wynoszące maksymalnie 50 milisekund.
• [C-SR] Minimalizuj zakłócenia sygnału wejściowego „na zimno”.
• [C-SR] Ogranicz błąd w wejściowych sygnaturach czasowych zwracanych przez funkcję AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/- 1 ms.

5.7. Protokoły sieciowe

Implementacje urządzeń MUSZĄ obsługiwać protokoły sieci multimedialnej do odtwarzania dźwięku i obrazu zgodnie z opisem w dokumentacji pakietu Android SDK.

Jeśli implementacje urządzeń obejmują dekoder dźwięku lub wideo:

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

• [C-1-2] MUSI obsługiwać formaty segmentów multimediów podane w tabeli „Media Segment Formats” (Formaty segmentu multimediów poniżej) w przypadku protokołu transmisji na żywo przez HTTP w wersji 7 (w wersji roboczej).

• [C-1-3] MUSI obsługiwać poniższy profil audio-wideo RTP i powiązane kodeki z tabeli RTSP poniżej. Informacje o wyjątkach znajdziesz w przypisach w sekcji 5.1.

Formaty segmentów multimediów

Formaty segmentów	Pliki referencyjne	Wymagana obsługa kodeka
Zapis strumienia MPEG-2	ISO 13818	Kodeki wideo: H264 AVC MPEG-4 SP MPEG-2 Szczegółowe informacje o kodach H264 AVC, MPEG2-4 SP i MPEG-2 znajdziesz w sekcji 5.1.3. Kodeki audio: AAC Więcej informacji o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
AAC z kadrowaniem ADTS i tagami ID3	ISO 13818-7	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1
WebVTT	WebVTT

RTSP (RTP, SDP)

Nazwa profilu	Pliki referencyjne	Wymagana obsługa kodeka
H264 AVC	RFC 6184	Szczegółowe informacje o AVC H264 znajdziesz w sekcji 5.1.3.
MP4A-LATM	RFC 6416	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1
H263–1998	RFC 3551 RFC 4629 RFC 2190	Szczegółowe informacje o H263 znajdziesz w sekcji 5.1.3.
H263–2000	RFC 4629	Szczegółowe informacje o H263 znajdziesz w sekcji 5.1.3.
AMR	RFC 4867	Szczegółowe informacje o AMR-NB znajdziesz w sekcji 5.1.1.
AMR-WB	RFC 4867	Szczegółowe informacje o AMR-WB znajdziesz w sekcji 5.1.1.
MP4V-ES	RFC 6416	Szczegółowe informacje o MPEG-4 SP znajdziesz w sekcji 5.1.3
mpeg4-generic,	RFC 3640	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1
Plik MP2T	RFC 2250	Więcej informacji znajdziesz w sekcji Strumień transportu MPEG-2 pod nagłówkiem Transmisja na żywo przez HTTP

5.8. Bezpieczne nośniki

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

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

Jeśli implementacje urządzeń deklarują obsługę Display.FLAG_SECURE i protokołu wyświetlania bezprzewodowego,:

• [C-2-1] W przypadku ekranów połączonych protokołami bezprzewodowymi, np. Miracast, połączenie MUSI zabezpieczyć link silnym kryptograficznie mechanizmem, np. HDCP 2.x lub nowszym.

Jeśli implementacje urządzeń deklarują obsługę interfejsu Display.FLAG_SECURE i przewodowego wyświetlacza zewnętrznego,:

• [C-3-1] MUSI obsługiwać standard HDCP 1.2 lub nowszy w przypadku wszystkich wyświetlaczy zewnętrznych podłączonych do dostępnego dla użytkownika portu przewodowego.

5.9. Interfejs MIDI (Musical Instrument Digital Interface)

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

• [C-1-1] MUSI obsługiwać MIDI we wszystkich transportach sprzętowych obsługujących MIDI, dla których zapewniają ogólne łącza inne niż MIDI, tam, gdzie takie dane:

  • Tryb hosta USB, sekcja 7.7
  • Tryb urządzenia peryferyjnego USB, sekcja 7.7
  • MIDI przez Bluetooth LE w głównej roli, sekcja 7.4.3

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

5.10. Profesjonalne treści audio

Jeśli implementacje urządzeń zgłaszają obsługę funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager, to:

• [C-1-1] MUSI zgłosić wsparcie funkcji android.hardware.audio.low_latency.
• [C-1-2] MUSI mieć ciągłe opóźnienie dźwięku w obie strony określone w sekcji 5.6 Opóźnienia dźwięku, MUSI wynosić nie więcej niż 20 milisekund i 10 milisekund w przypadku co najmniej jednej obsługiwanej ścieżki.
• [C-1-3] MUSI zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
• [C-1-4] MUSI zgłosić wsparcie funkcji android.software.midi.
• [C-1-5] MUSI spełniać wymagania dotyczące czasów oczekiwania i dźwięku USB, korzystając zarówno z kolejki bufora PCM OpenSL ES, jak i z natywnych interfejsów audio AAudio.
• [SR] Zdecydowanie ZALECANE jest zapewnienie stałego poziomu wydajności procesora przy włączonym dźwięku, a jego obciążenie jest zmienną. Przetestuj to za pomocą zatwierdzenia SimpleSynth 1bd6391. Aplikację SimpleSynth należy uruchamiać z poniższymi parametrami i osiągnąć zero niedopełnienia po 10 minutach:
  • Cykle pracy: 200 000
  • Zmienne obciążenie: WŁĄCZONE (przełącza się między 100% a 10% wartości cykli roboczych co 2 sekundy i ma na celu przetestowanie działania regulatora procesora)
  • Stabilizowane obciążenie: WYŁ.
• POWINNO zminimalizować niedokładność zegara audio i dryf w stosunku do czasu standardowego.
• POWINNO zminimalizować dryf zegara audio w stosunku do CPU CLOCK_MONOTONIC, gdy obie te wartości są aktywne.
• POWINNO Zminimalizować opóźnienie dźwięku przez przetworniki na urządzeniu.
• POWINNO zminimalizować opóźnienie dźwięku podczas korzystania z dźwięku cyfrowego przez USB.
• POWINIEN udokumentować pomiary opóźnienia dźwięku na wszystkich ścieżkach.
• POWINNY być zminimalizowanie zakłóceń podczas wywołań zwrotnych pełnego bufora audio, ponieważ wpływa to na procent wykorzystania pełnej przepustowości procesora przez wywołanie zwrotne.
• W normalnym trybie użytkowania z zgłoszonym opóźnieniem nie powinno być żadnych zakłóceń dźwięku (wyjściowych) ani przelotów (wejście).
• POWINNA SIĘ znajdować zerową różnicę czasu oczekiwania między kanałami.
• POWINNA Zminimalizować średni czas oczekiwania MIDI podczas wszystkich transmisji.
• POWINNO zminimalizować zmienność opóźnienia MIDI podczas obciążenia (zakłócenia) podczas wszystkich transmisji.
• NALEŻY podawać dokładne sygnatury czasowe MIDI we wszystkich transmisjach.
• POWINNO zminimalizować szum sygnału audio przez przetworniki urządzenia, w tym przez okres tuż po uruchomieniu „na zimno”.
• TRZEBA zadbać o zerową różnicę zegara audio między stroną wejściową a wyjściową odpowiednich punktów końcowych, gdy oba te punkty są aktywne. Przykładami odpowiednich punktów końcowych są mikrofon i głośnik urządzenia oraz wejście i wyjście gniazda słuchawek.
• NALEŻY obsługiwać wywołania zwrotne uzupełniania bufora audio po stronach wejściowych i wyjściowych odpowiednich punktów końcowych w tym samym wątku, gdy oba są aktywne, i wprowadzać wyjściowe wywołanie zwrotne tuż po zwrocie z wejściowego wywołania zwrotnego. A jeśli nie możesz obsłużyć wywołań zwrotnych w tym samym wątku, wpisz wyjściowe wywołanie zwrotne krótko po wprowadzeniu wywołania zwrotnego, aby aplikacja mogła mieć spójny czas na danych wejściowych i wyjściowych.
• NALEŻY zminimalizować różnicę fazową między buforowaniem dźwięku HAL po stronie wejścia i wyjścia odpowiednich punktów końcowych.
• POWINNO zminimalizować opóźnienie dotyku.
• POWINNO zminimalizować zmienność czasu oczekiwania na dotknięcie przy obciążeniu (zakłócenia).
• Opóźnienie pomiędzy sygnałem dotykowym a sygnałem audio nie może przekraczać 40 ms.

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

• [SR] ZALECANE jest zgłoszenie pomocy dotyczącej funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager.

Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3, 5 mm:

• [C-2-1] Ciągłe opóźnienie dźwięku w obie strony musi wynosić maksymalnie 20 milisekund na ścieżce audio.
• [SR] ZALECANE jest zachowanie zgodności z sekcją Specyfikacja urządzenia mobilnego (gniazdo) w specyfikacji przewodowego zestawu słuchawkowego (wersja 1.1).
• Ciągłe opóźnienie dźwięku w obie strony NIE powinno przekraczać 10 milisekund na ścieżce audio.

Jeśli implementacje urządzeń pomijają 4-kanałowe gniazdo słuchawek 3, 5 mm i są wyposażone w porty USB obsługujące tryb hosta USB:

• [C-3-1] MUSI zaimplementować klasę audio USB.
• [C-3-2] MUSI mieć ciągłe opóźnienie dźwięku w obie strony wynoszące maksymalnie 20 milisekund przez port w trybie hosta USB z użyciem klasy audio USB.
• Ciągłe opóźnienie dźwięku w obie strony NIE powinno przekraczać 10 milisekund w przypadku portu w trybie hosta USB z użyciem klasy audio USB.

Jeśli urządzenia są wyposażone w port HDMI:

• [C-4-1] MUSI obsługiwać wyjście stereo i 8 kanałów z głębią 20- lub 24-bitową oraz 192 kHz bez utraty głębi bitowej lub resamplingu w co najmniej jednej konfiguracji.

5.11. Zrób zdjęcie, aby nie zostały przetworzone

Android umożliwia nagrywanie nieprzetworzonego dźwięku przez źródło dźwięku android.media.MediaRecorder.AudioSource.UNPROCESSED. W OpenSL ES można uzyskać do niego dostęp za pomocą gotowego ustawienia rekordów SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Jeśli implementacja urządzenia ma obsługiwać nieprzetworzone źródło dźwięku i udostępniać je aplikacjom innych firm:

• [C-1-1] MUSI zgłosić pomoc za pomocą android.media.AudioManager usługi PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] MUSI wykazywać w przybliżeniu płaską amplitudę względem częstotliwości w średnim zakresie częstotliwości: ±10 dB od 100 Hz do 7000 Hz dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-3] MUSI mieć poziom amplitudy w niskim zakresie: od ±20 dB od 5 Hz do 100 Hz w porównaniu ze średnim zakresem częstotliwości dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-4] MUSI mieć poziom amplitudy w zakresie wysokich częstotliwości: od ±30 dB od 7000 Hz do 22 kHz w porównaniu ze średnim zakresem częstotliwości dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-5] MUSI ustawić czułość sygnału wejściowego dźwięku tak, aby źródło tonów sinusoidalnych 1000 Hz odtwarzane przy poziomie ciśnienia akustycznego 94 dB (SPL) dało odpowiedź z RMS 520 dla 16-bitowych próbek (lub -36 dB pełnej skali w przypadku każdego źródła zmiennoprzecinkowego lub podwójnej precyzji użytego źródła dźwięku z mikrofonem).

• [C-1-6] MUSI mieć współczynnik sygnału do szumu (SNR) wynoszący 60 dB lub więcej dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku. (SNR jest mierzony jako różnica między 94 dB SPL a równoważnym SPL własnym szumem ważonym A).

• [C-1-7] W przypadku 1 kHz przy 90 dB poziomu wejściowego SPL całkowite zniekształcenie harmoniczne (THD) musi być mniejsze niż 1% dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• NIE MOŻESZ obsługiwać żadnego innego przetwarzania sygnału (np. automatycznej kontroli wzmocnienia, filtra górnoprzepustowego ani usuwania echa) na ścieżce innej niż mnożnik poziomu umożliwiający uzyskanie pożądanego poziomu. Krótko mówiąc:

• [C-1-8] Jeśli z jakiegoś powodu w architekturze obecne jest przetwarzanie sygnału, MUSI być ono wyłączone i w efekcie powodować zero opóźnienia lub dodatkowe opóźnienia na ścieżce sygnału.
• [C-1-9] Mnożnik poziomu, który może znajdować się na ścieżce, NIE MOŻE wywoływać opóźnienia na ścieżce sygnału.

Wszystkie pomiary SPL są wykonywane bezpośrednio obok testowanego mikrofonu. W przypadku różnych konfiguracji mikrofonów te wymagania dotyczą każdego z nich.

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

• [C-2-1] W przypadku metody API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) MUSI zwracać wartość null, aby prawidłowo wskazać brak obsługi.
• Zdecydowanie ZALECANE jest spełnienie jak największej liczby wymagań dotyczących ścieżki sygnału dla nieprzetworzonego źródła nagrania.

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

6.1. Narzędzia dla programistów

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać narzędzia dla programistów aplikacji na Androida zawarte w pakiecie Android SDK.

• Android Debug Bridge (adb)

  • [C-0-2] MUSI obsługiwać narzędzie adb zgodnie z opisem w pakiecie SDK do Androida i polecenia powłoki podane w AOSP, których mogą używać deweloperzy aplikacji, w tym dumpsys i cmd stats.
  • [C-0-3] NIE MOŻE zmieniać formatu ani zawartości zdarzeń systemowych urządzenia (batterystats , Disstats, odcisków cyfrowych, Graphstats, netstats, notification, procstats) zarejestrowanych przy użyciu polecenia dumpsys.
  • [C-0-10] MUSI rejestrować bez pomijania oraz udostępniać poniższe zdarzenia poleceniem powłoki cmd stats i klasie systemowego interfejsu API StatsManager.
    • Zmieniono stan działania pierwszego planu
    • Wykryto anomalię
    • Zgłoszono menu nawigacyjne aplikacji
    • Wystąpiła awaria
    • Uruchomienie aplikacji
    • Poziom baterii został zmieniony
    • Zmieniono stan trybu oszczędzania baterii
    • Odebrano BleScanResult
    • Stan BleScanState zmieniony
    • Zmieniono stan ładowania
    • Zmieniono stan bezczynności urządzenia
    • Zmieniono stan usługi na pierwszym planie
    • Zmieniono stan skanowania GPS
    • Stan zadania zmieniony
    • Stan wtyczki zmieniony
    • Zmieniono stan zaplanowanego zadania
    • Zmieniono stan ekranu
    • SyncState (Zmiana stanu)
    • Czas rzeczywisty po upłynięciu systemu
    • Zmieniono stan procesu UidProcess
    • Stan uśpienia został zmieniony
    • Pojawił się Budzik
    • Zmiana stanu blokady Wi-Fi
    • Zmiana stanu blokady Wi-FiMulticastLock
    • Zmiana stanu skanowania Wi-Fi
  • [C-0-4] demon adb po stronie urządzenia MUSI być domyślnie nieaktywny i musi istnieć dostępny dla użytkownika mechanizm umożliwiający włączenie narzędzia Android Debug Bridge.
  • [C-0-5] MUSI obsługiwać bezpieczne narzędzie adb. Android zapewnia obsługę bezpiecznego pliku adb. Bezpieczny adb włącza narzędzie adb na znanych uwierzytelnionych hostach.

  • [C-0-6] MUSI zapewniać mechanizm umożliwiający połączenie narzędzia adb z komputera hosta. Na przykład:

    • Implementacje urządzeń bez portu USB obsługującego tryb peryferyjny MUSZĄ obsługiwać adb przez sieć lokalną (np. Ethernet lub Wi-Fi).
    • MUSI zawierać sterowniki dla Windows 7, 9 i 10, które umożliwiają programistom połączenie się z urządzeniem za pomocą protokołu adb.

• Usługa monitorowania debugowania Dalvik (ddms)

  • [C-0-7] MUSI obsługiwać wszystkie funkcje ddms zgodnie z dokumentacją pakietu Android SDK. Ponieważ pakiet ddms używa narzędzia adb, obsługa ddms jest domyślnie nieaktywna, ale MUSI być obsługiwana za każdym razem, gdy użytkownik aktywuje Android Debug Bridge (jak powyżej).
• Małpa
  • [C-0-8] MUSI zawierać platformę Monkey i udostępniać ją aplikacjom.
• SysTrace
  • [C-0-9] MUSI obsługiwać narzędzie systrace zgodnie z opisem w pakiecie SDK na Androida. System musi być domyślnie nieaktywny, a jego włączenie MUSI mieć dostępny dla użytkownika mechanizm.

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

• [C-1-1] MUSI zapewniać deweloperowi aplikacji możliwość włączenia/wyłączenia warstw debugowania GPU.
• [C-1-2] Gdy włączone są warstwy debugowania GPU, należy wyliczać warstwy w bibliotekach dostarczanych 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 interfejsu API vkEnumerateInstanceLayerWłaściwości() i vkCreateInstance().

6.2. Opcje programisty

Android zapewnia programistom możliwość konfigurowania ustawień związanych z programowaniem aplikacji.

Implementacje na urządzeniu MUSZĄ zapewniać spójny interfejs Opcji programisty, ponieważ:

• [C-0-1] MUSI uwzględniać intencję android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z programowaniem. Nadrzędna implementacja Androida ukrywa menu Opcje programisty i umożliwia użytkownikom uruchomienie Opcji programisty po naciśnięciu 7 (7) razy w menu Ustawienia > Informacje o urządzeniu > Numer kompilacji.
• [C-0-2] Domyślnie MUSI ukryć Opcje programisty.
• [C-0-3] MUSI zawierać jasny mechanizm, który umożliwia korzystanie z Opcji dewelopera na preferencyjnym poziomie wobec jednej aplikacji innej firmy. MUSI udostępnić publicznie widoczny dokument lub witrynę opisującą, jak włączyć Opcje programisty. Dokument lub witryna MUSI zawierać link w dokumentach pakietu Android SDK.
• POWINNY być stale widoczne dla użytkownika powiadomienie wizualne, gdy Opcje programisty są włączone, a użytkownik jest w trosce o bezpieczeństwo.
• MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty, ukrywając je lub wyłączając je, aby nie rozpraszać uwagi użytkowników w sytuacjach, gdy jest obawa o bezpieczeństwo użytkownika.

7. Zgodność sprzętu

Jeśli urządzenie jest wyposażone w konkretny komponent sprzętowy, który ma odpowiedni interfejs API dla zewnętrznych programistów:

• [C-0-1] Implementacja na urządzeniu MUSI implementować ten interfejs API w sposób opisany w dokumentacji pakietu Android SDK.

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

• [C-0-2] Nadal MUSISZ przedstawiać pełne definicje klas (zgodnie z dokumentacją w pakiecie SDK) dla interfejsów API komponentów.
• [C-0-3] Działanie interfejsu API MUSI być w jakiś rozsądny sposób implementowane jako brak działań.
• [C-0-4] Metody interfejsu API MUSZĄ zwracać wartości null tam, gdzie jest to dozwolone w dokumentacji pakietu SDK.
• [C-0-5] Metody interfejsu API MUSZĄ zwracać implementacje klas bezobsługowych, w których wartości null są niedozwolone w dokumentacji pakietu SDK.
• [C-0-6] Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, których nie opisano w dokumentacji pakietu SDK.
• [C-0-7] Implementacje urządzeń MUSZĄ spójnie zgłaszać dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) z klasą android.content.pm.PackageManager dla tego samego odcisku cyfrowego kompilacji.

Typowym przykładem sytuacji, w której obowiązują te wymagania, jest interfejs telefoniczny API. Te interfejsy API należy wdrożyć bez żadnych działań nawet na urządzeniach innych niż telefony.

7.1. Wyświetlacz i grafika

Android zawiera elementy, które automatycznie dostosowują zasoby aplikacji i układy interfejsu użytkownika do urządzenia, aby aplikacje innych firm działały prawidłowo na różnych konfiguracjach sprzętowych. Urządzenia MUSZĄ prawidłowo implementować te interfejsy API i działania, jak opisano w tej sekcji.

Jednostki, do których odnoszą się wymagania w tej sekcji, są zdefiniowane w następujący sposób:

• fizyczny rozmiar przekątnej. Wyrażona w calach odległość między dwoma przeciwległymi rogami podświetlonej części wyświetlacza.
• punktów na cal (dpi). Liczba pikseli w obrębie liniowej, poziomej lub pionowej rozpiętości wynoszącej 1. Przy podanych wartościach dpi wartość zarówno w poziomie, jak i w pionie musi mieścić się w zakresie.
• format obrazu. Stosunek liczby pikseli dłuższego wymiaru do krótszego wymiaru ekranu. Na przykład przy rozmiarze 480 x 854 piksele będzie to 854/480 = 1, 779, czyli w przybliżeniu „16:9”.
• piksel niezależny od gęstości (dp). Jednostka wirtualnego piksela znormalizowana do ekranu o rozdzielczości 160 dpi. Wartość jest obliczana według wzoru: piksele = dps * (gęstość/160).

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar i kształt ekranu

Platforma interfejsu Androida obsługuje różne logiczne rozmiary układu ekranu i umożliwia aplikacjom wysyłanie zapytań o rozmiar układu ekranu w bieżącej konfiguracji za pomocą interfejsu Configuration.screenLayout z użyciem SCREENLAYOUT_SIZE_MASK i Configuration.smallestScreenWidthDp.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłosić prawidłowy rozmiar układu elementu Configuration.screenLayout zgodnie z definicją w dokumentacji pakietu Android SDK. Implementacje urządzeń MUSZĄ zgłaszać prawidłowe wymiary ekranu niezależne od gęstości logicznej (dp) jak poniżej:

  • Urządzenia, które mają ustawioną wartość Configuration.uiMode jako dowolną inną niż UI_MODE_TYPE_WATCH i przesyłający zgłoszenie o rozmiarze small dla elementu Configuration.screenLayout MUSZĄ mieć co najmniej 426 dp x 320 dp.
  • Urządzenia zgłaszające rozmiar normal w polu Configuration.screenLayout MUSZĄ mieć co najmniej 480 dp x 320 dp.
  • Urządzenia zgłaszające rozmiar large dla elementu Configuration.screenLayout MUSZĄ mieć co najmniej 640 dp x 480 dp.
  • Urządzenia zgłaszające rozmiar xlarge dla elementu Configuration.screenLayout MUSZĄ mieć co najmniej 960 dp x 720 dp.

• [C-0-2] MUSI prawidłowo szanować obsługę rozmiarów ekranu w aplikacjach za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml, zgodnie z dokumentacją pakietu Android SDK.

• MOŻE mieć wyświetlacz z zaokrąglonymi rogami.

Jeśli implementacje urządzeń obsługują UI_MODE_TYPE_NORMAL i zawierają wyświetlacz z zaokrąglonymi rogami:

• [C-1-1] MUSI mieć pewność, że promień zaokrąglonych rogów nie przekracza 38 dp.
• POWIADOMIENIA, Żeby użytkownik mógł przełączyć się na tryb wyświetlania z prostokątnymi narożnikami, należy uwzględnić danie użytkownika.

7.1.1.2. Współczynnik proporcji ekranu

Chociaż nie ma ograniczeń co do wartości współczynnika proporcji fizycznego wyświetlacza, współczynnik proporcji ekranu logicznego, w którym są renderowane aplikacje innych firm, który można określić na podstawie wartości wysokości i szerokości zgłaszanych za pomocą interfejsów API view.Display i interfejsu Configuration API, MUSI spełniać te wymagania:

• [C-0-1] Implementacje na urządzeniach, w których Configuration.uiMode ma wartość UI_MODE_TYPE_NORMAL, MUSZĄ mieć współczynnik proporcji z zakresu od 1,3333 (4:3) do 1,86 (ok. 16:9), chyba że aplikację można uznać za gotową do dłuższego rozciągania, spełniając jeden z tych warunków:

  • Aplikacja zadeklarowała, że obsługuje większy format obrazu za pomocą wartości metadanych android.max_aspect.
  • Aplikacja deklaruje, że rozmiar można zmienić w atrybucie android:resizeableActivity.
  • Aplikacja jest kierowana na interfejs API na poziomie 24 lub wyższym i nie deklaruje interfejsu android:MaxAspectRatio, który ograniczałby dozwolony format obrazu.

• [C-0-2] Implementacje na urządzeniach, w których Configuration.uiMode ma wartość UI_MODE_TYPE_WATCH, MUSZĄ mieć format obrazu ustawiony na 1,0 (1:1).

7.1.1.3 Gęstość ekranu

Platforma UI Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić programistom kierowanie zasobów aplikacji.

• [C-0-1] Domyślnie implementacje urządzeń MUSZĄ zgłaszać za pomocą interfejsu API DENSITY_DEVICE_STABLE tylko jedną z poniższych gęstości logicznej platformy Androida. Ta wartość NIE MOŻE być zmieniana w żadnym momencie. Urządzenie MOŻE jednak zgłosić inną gęstość zależnie od zmian w konfiguracji wyświetlacza wprowadzonych przez użytkownika (np. rozmiaru wyświetlacza) ustawionych po pierwszym uruchomieniu.

  • 120 dpi (ldpi)
  • 160 dpi (mdpi)
  • 213 dpi (tvdpi)
  • 240 dpi (hdpi)
  • 260 dpi (260dpi)
  • 280 dpi (280dpi)
  • 300 dpi (300dpi)
  • 320 dpi (Xhdpi)
  • 340 dpi (340dpi)
  • 360 dpi (360dpi)
  • 400 dpi (400dpi)
  • 420 dpi (420dpi)
  • 480 dpi (xxhdpi)
  • 560 dpi (560dpi)
  • 640 dpi (xxxhdpi)

• Implementacje na urządzeniach NALEŻY zdefiniować standardową gęstość platformy Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, chyba że taka gęstość sprowadza raportowany rozmiar ekranu poniżej obsługiwanego minimum. Jeśli standardowa gęstość platformy Androida, która jest najbliższa liczbowo gęstości fizycznej, powoduje, że rozmiar ekranu jest mniejszy niż najmniej obsługiwany obsługiwany rozmiar ekranu (320 dp), implementacje urządzeń POWINNY zgłaszać następny najniższy standardowy poziom gęstości platformy.

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

• [C-1-1] Rozmiar wyświetlacza NIE MOŻE być skalowany większy niż 1,5 raza gęstości natywnej ani nie może powodować, że minimalny rozmiar ekranu będzie mniejszy niż 320 dp (odpowiednik kwalifikatora zasobów sw320dp – w zależności od tego, co nastąpi wcześniej).
• [C-1-2] Rozmiar wyświetlacza NIE MOŻE być skalowany w sposób mniejszy niż 0,85 raza gęstości natywnej.
• Aby zapewnić wygodę obsługi i spójne rozmiary czcionek, ZALECANE jest użycie poniższych opcji skalowania reklam natywnych w sieci reklamowej (zgodnie z powyższymi limitami).
• Małe: 0,85x
• Domyślnie: 1x (natywna skala wyświetlania)
• Duży: 1,15x
• Większe: 1,3x
• Największy 1,45x

7.1.2. Wyświetl dane

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

• [C-1-1] MUSI podawać prawidłowe wartości dla wszystkich wyświetlanych danych zdefiniowanych w interfejsie API android.util.DisplayMetrics.

Jeśli implementacje urządzeń nie zawierają osadzonego ekranu lub wyjścia wideo:

• [C-2-1] MUSI podawać rozsądne wartości dla wszystkich danych o wyświetlaniu zdefiniowanych w interfejsie API android.util.DisplayMetrics dla emulowanej domyślnej wartości view.Display.

7.1.3 Orientacja ekranu

Implementacje na urządzeniach:

• [C-0-1] MUSI podawać obsługiwane orientacje ekranu (android.hardware.screen.portrait lub android.hardware.screen.landscape) i MUSI podawać co najmniej jedną obsługiwaną orientację. Na przykład urządzenie ze stałą orientacją poziomą, takie jak telewizor czy laptop, MUSI zgłosić tylko wartość android.hardware.screen.landscape.
• [C-0-2] MUSI zgłaszać prawidłową wartość w przypadku bieżącej orientacji urządzenia w przypadku wysyłania zapytań za pomocą interfejsu android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innych interfejsów API.

Jeśli implementacje urządzeń obsługują obie orientacje ekranu, umożliwiają one:

• [C-1-1] MUSI obsługiwać orientację dynamiczną w aplikacjach w orientacji pionowej lub poziomej. Oznacza to, że urządzenie musi uwzględniać żądanie aplikacji dotyczące określonej orientacji ekranu.
• [C-1-2] NIE MOŻE zmieniać zgłoszonego rozmiaru ani gęstości ekranu podczas zmiany orientacji.
• MOGĄ wybrać orientację pionową lub poziomą jako domyślną.

7.1.4. Przyspieszenie działania grafiki 2D i 3D

7.1.4.1 OpenGL ES

Implementacje na urządzeniach:

• [C-0-1] MUSI poprawnie identyfikować obsługiwane wersje OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) za pomocą zarządzanych interfejsów API (np. GLES10.getString()) i natywnych interfejsów API.
• [C-0-2] MUSI obsługiwać wszystkie odpowiednie zarządzane interfejsy API i natywne interfejsy API dla każdej wersji OpenGL ES, którą zidentyfikowano jako obsługiwane.

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

• [C-1-1] MUSI obsługiwać zarówno platformę OpenGL ES 1.1, jak i 2.0, zgodnie z opisem w dokumentacji pakietu SDK na Androida.
• Zdecydowanie ZALECANE jest umożliwienie obsługi trybu OpenGL ES 3.1.
• MUSI obsługiwać standard OpenGL ES 3.2.

Jeśli implementacje urządzeń obsługują dowolną wersję OpenGL ES:

• [C-2-1] MUSI zgłaszać za pomocą zarządzanych interfejsów API OpenGL ES i natywnych interfejsów API wszystkie inne zaimplementowane rozszerzenia OpenGL ES i NIE MOŻE zgłaszać ciągów rozszerzeń, które nie są obsługiwane.
• [C-2-2] MUSI obsługiwać rozszerzenia EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage i EGL_ANDROID_recordable.
• Zdecydowanie ZALECANE jest umożliwienie obsługi EGL_KHR_partial_update.
• POWINNY jest dokładne raportowanie za pomocą metody getString(), czyli dowolnego obsługiwanego formatu kompresji tekstur, który jest zwykle zależny od dostawcy.

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

• [C-3-1] Oprócz symboli funkcji OpenGL ES 2.0 z biblioteki libGLESv2.so MUSI wyeksportować odpowiednie symbole funkcji dla tej wersji.

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

• [C-4-1] MUSI obsługiwać w całości pakiet rozszerzeń OpenGL ES na Androida.

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

• [C-5-1] MUSI określać pomoc za pomocą flagi funkcji android.hardware.opengles.aep.

Jeśli implementacje urządzeń zapewniają obsługę rozszerzenia EGL_KHR_mutable_render_buffer:

• [C-6-1] MUSI też obsługiwać rozszerzenie EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 interfejs Vulkan

Android obsługuje Vulkan – niskobudżetowy, wieloplatformowy interfejs API do wysokiej wydajności grafiki 3D.

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

• [SR] Zdecydowanie ZALECANE jest włączenie obsługi Vulkan 1.1.

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

• POWINNO obsługiwać platformę Vulkan 1.1.

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

• [C-1-1] MUSI podawać prawidłową liczbę całkowitą z flagami funkcji android.hardware.vulkan.level i android.hardware.vulkan.version.
• [C-1-2] MUSI wyliczać co najmniej 1 VkPhysicalDevice dla natywnego interfejsu API Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] MUSI w pełni wdrożyć interfejsy Vulkan 1.0 API w przypadku każdego wymienionego parametru VkPhysicalDevice.
• [C-1-4] MUSI wyliczać warstwy zawarte w bibliotekach natywnych o nazwie libVkLayer*.so w katalogu biblioteki natywnej pakietu aplikacji przy użyciu natywnych interfejsów API Vulkan vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties() .
• [C-1-5] NIE MOŻE wyliczać warstw dostarczanych przez biblioteki poza pakietem aplikacji ani udostępniać innych sposobów śledzenia lub przechwytywania interfejsu Vulkan API, chyba że aplikacja ma atrybut android:debuggable ustawiony jako true.
• [C-1-6] MUSI zgłaszać wszystkie ciągi rozszerzeń, które obsługują przez natywne interfejsy API Vulkan, i NIE MOGĄ raportować ciągów rozszerzeń, które nie są prawidłowo obsługiwane.
• [C-1-7] MUSI obsługiwać rozszerzenia VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain i VK_KHR_incremental_present.

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

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

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

• [C-3-1] MUSI udostępniać obsługę zewnętrznych semaforów i typów uchwytu SYNC_FD.
• [SR] Zdecydowanie ZALECANE jest obsługa rozszerzenia VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Implementacje na urządzeniach MUSZĄ obsługiwać protokół Android RenderScript, zgodnie z opisem w dokumentacji pakietu Android SDK.

Przyspieszenie grafiki 2D 7.1.4.4

Android zawiera mechanizm deklarowania przez aplikacje, że chcą włączyć akcelerację sprzętową grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku. Służy do tego tag manifestu android:hardwareAccelerated lub bezpośrednie wywołania interfejsu API.

Implementacje na urządzeniach:

• [C-0-1] MUSI domyślnie włączać akcelerację sprzętową i MUSI wyłączyć akcelerację sprzętową, jeśli deweloper o to poprosi, ustawiając parametr android:hardwareAccelerated="false” lub wyłączając akcelerację sprzętową bezpośrednio przez interfejsy Android View API.
• [C-0-2] MUSI działać zgodnie z opisem w dokumentacji pakietu Android SDK na temat akceleracji sprzętowej.

Android zawiera obiekt TextureView, który umożliwia programistom bezpośrednią integrację z akceleracją sprzętową tekstur OpenGL ES jako celów renderowania w hierarchii UI.

Implementacje na urządzeniach:

• [C-0-3] MUSI obsługiwać interfejs TextureView API i MUSI działać w spójny sposób z wcześniejszą implementacją Androida.

7.1.4.5 Wyświetlacze o szerokiej gamie

Jeśli implementacji na urządzeniu informują o obsłudze ekranów o szerokiej gamie za pomocą Configuration.isScreenWideColorGamut():

• [C-1-1] MUSI mieć wyświetlacz z kalibracją kolorów.
• [C-1-2] MUSI mieć wyświetlacz, którego zakres obejmuje całą paletę kolorów sRGB w przestrzeni CIE 1931 xyY.
• [C-1-3] MUSI mieć wyświetlacz o gatunku równym co najmniej 90% obszaru DCI-P3 w przestrzeni CIE 1931 xyY.
• [C-1-4] MUSI obsługiwać standard OpenGL ES 3.1 lub 3.2 i prawidłowo go zgłaszać.
• [C-1-5] MUSI reklamować obsługę rozszerzeń EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3 i EGL_KHR_gl_colorspace_display_p3.
• [SR] Zdecydowanie ZALECANE jest wsparcie dla zasobu GL_EXT_sRGB.

Jeśli natomiast implementacje urządzeń nie obsługują wyświetlaczy o szerokim zakresie kolorów:

• [C-2-1] POWINNA obejmować co najmniej 100% przestrzeni sRGB w przestrzeni CIE 1931 xyY, ale gama kolorów ekranu jest nieokreślona.

7.1.5 Tryb zgodności starszych aplikacji

Android określa „tryb zgodności”, w którym platforma działa w trybie „normalnego” rozmiaru ekranu (szerokości 320 dp), co umożliwia korzystanie ze starszych aplikacji nieopracowanych na potrzeby starszych wersji Androida, które wcześniej nie były niezależne od rozmiaru ekranu.

7.1.6 Technologia ekranu

Platforma Androida zawiera interfejsy API umożliwiające aplikacjom renderowanie bogatej grafiki na wyświetlaczu. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zgodnie z definicją w pakiecie Android SDK, o ile nie jest to wyraźnie dozwolone w tym dokumencie.

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać wyświetlacze z możliwością renderowania 16-bitowej grafiki w kolorze.
• NALEŻY obsługiwać wyświetlacze z 24-bitową grafiką w 24-bitowych kolorach.
• [C-0-2] MUSI obsługiwać wyświetlacze z możliwością renderowania animacji.
• [C-0-3] MUSI używać technologii wyświetlania o współczynniku proporcji piksela (PAR) w zakresie od 0,9 do 1,15. Oznacza to, że format obrazu MUSI być kwadratowy (1,0) i z tolerancją 10–15%.

7.1.7 Wyświetlacze dodatkowe

Android obsługuje wyświetlacz dodatkowy, który umożliwia udostępnianie multimediów, a interfejsy API dla programistów umożliwiają dostęp do wyświetlaczy zewnętrznych.

Jeśli implementacje urządzeń obsługują wyświetlacz zewnętrzny za pośrednictwem połączenia przewodowego, bezprzewodowego lub wbudowanego wyświetlacza dodatkowego, zapewniają one:

• [C-1-1] MUSI zaimplementować usługę systemową i interfejs API DisplayManager w sposób opisany w dokumentacji pakietu Android SDK.

7.2. Urządzenia wejściowe

Implementacje na urządzeniach:

• [C-0-1] Do poruszania się między elementami interfejsu MUSI zawierać mechanizm wprowadzania danych, np. ekran dotykowy lub nawigację bezdotykową.

7.2.1. Klawiatura

Jeśli implementacje urządzeń obejmują obsługę zewnętrznych aplikacji edytora metody wprowadzania (IME), te funkcje:

• [C-1-1] MUSI zadeklarować flagę funkcji android.software.input_methods.
• [C-1-2] MUSI obsługiwać w całości Input Management Framework
• [C-1-3] MUSI mieć wstępnie zainstalowaną klawiaturę programową.

Implementacje na urządzeniach: * [C-0-1] NIE MOŻE zawierać klawiatury sprzętowej w żadnym z formatów określonych w zasadzie android.content.res.Configuration.keyboard (QWERTY lub 12-key). * POWINNY BYĆ dodatkowe implementacje klawiatury programowej. * MOŻE zawierać klawiaturę sprzętową.

7.2.2 Nawigacja bezdotykowa

W Androidzie można używać pada kierunkowego, trackballa i kółka jako mechanizmów do nawigacji bezdotykowej.

Implementacje na urządzeniach:

• [C-0-1] MUSI zgłosić prawidłową wartość atrybutu android.content.res.Configuration.navigation.

Jeśli w urządzeniach nie ma nawigacji niedotykowej:

• [C-1-1] MUSI zapewniać uzasadniony alternatywny interfejs użytkownika do wyboru i edytowania tekstu, zgodny z mechanizmami zarządzania danymi wejściowymi. Implementacja open source Androida obejmuje mechanizm wyboru odpowiedni do zastosowania w urządzeniach, które nie zawierają nawigacji bezdotykowej.

7.2.3 Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz są zwykle dostępne w wyniku interakcji z osobnym przyciskiem fizycznym lub konkretną częścią ekranu dotykowego. Mają więc kluczowe znaczenie dla nawigacji na Androidzie, dlatego są niezbędne do implementacji na urządzeniach:

• [C-0-1] MUSI zapewniać użytkownikowi możliwość uruchamiania zainstalowanych aplikacji, w których przypadku funkcja <intent-filter> jest ustawiona na wartości ACTION=MAIN i CATEGORY=LAUNCHER lub CATEGORY=LEANBACK_LAUNCHER w przypadku implementacji na urządzeniach telewizyjnych. Funkcja Home POWINNA być mechanizmem dla tej afordancji użytkownika.
• POWINNY jest dostęp do przycisków funkcji Ostatnie i Wstecz.

Jeśli dostępne są funkcje Ekran główny, Ostatnie i Wstecz, umożliwiają one:

• [C-1-1] MUSI być dostępne w wyniku jednej czynności (np. kliknięcia lub dwukrotnego kliknięcia albo gestu), jeśli któreś z nich są dostępne.
• [C-1-2] MUSI wyraźnie wskazywać, które działanie może wywołać daną funkcję. Może to być na przykład widoczna ikona nadrukowana na przycisku, ikona oprogramowania na pasku nawigacyjnym albo instrukcja pokazująca krok po kroku podczas konfiguracji po rozpakowaniu urządzenia.

Implementacje na urządzeniach:

• Zdecydowanie ZALECANE jest nieudostępnianie mechanizmu wprowadzania danych w funkcji menu, ponieważ od wersji Androida 4.0 wycofano ją i zastąpił pasek działań.

Jeśli implementacje urządzeń zapewniają funkcję menu, są to:

• [C-2-1] MUSI wyświetlać przycisk przepełnienia działania, gdy rozszerzone menu czynności nie jest puste i widoczny jest pasek działań.
• [C-2-2] NIE MOŻE zmieniać pozycji wyświetlanego wyskakującego okienka działania przez kliknięcie przycisku rozszerzania działania na pasku działań, ale MOGĄ renderować wyskakujące okienko rozszerzania działania w zmodyfikowanym położeniu na ekranie, gdy jest wyświetlane po wybraniu funkcji Menu.

Jeśli implementacje urządzenia nie obsługują funkcji Menu, w celu zapewnienia zgodności wstecznej: * [C-3-1] MUSZĄ udostępnić funkcję Menu w przypadku, gdy targetSdkVersion ma mniej niż 10 lat (za pomocą fizycznego przycisku, klawisza oprogramowania lub gestów). Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacyjnymi.

Jeśli implementacje urządzenia umożliwiają funkcję wspomagania: * [C-4-1] MUSI umożliwić korzystanie z tej funkcji jednym działaniem (np. kliknięciem, dwukrotnym kliknięciem lub gestem), gdy dostępne są inne klawisze nawigacyjne. * [SR] Zdecydowanie ZALECANE jest użycie funkcji EKRAN GŁÓWNY, gdy jest to wyznaczona interakcja.

Jeśli implementacje urządzeń wykorzystują osobną część ekranu do wyświetlania klawiszy nawigacyjnych:

• [C-5-1] Klawisze nawigacyjne MUSZĄ zajmować wyraźną część ekranu, nie są dostępne dla aplikacji i NIE MOGĄ w żaden inny sposób zasłaniać tej części ekranu dostępnej dla aplikacji.
• [C-5-2] MUSI udostępniać część wyświetlacza aplikacjom spełniającym wymagania określone w sekcji 7.1.1.
• [C-5-3] MUSI uwzględniać flagi ustawione przez aplikację za pomocą metody interfejsu API View.setSystemUiVisibility(), tak aby ta odrębna część ekranu (czyli pasek nawigacyjny) była prawidłowo ukryta w sposób opisany w pakiecie SDK.

7.2.4 Wprowadzanie tekstu z ekranu dotykowego

Android obsługuje różne systemy wprowadzania danych wskaźnikami, takie jak ekrany dotykowe, pady dotykowe i fałszywe urządzenia dotykowe. Implementacje na urządzeniach z ekranem dotykowym są powiązane z ekranem w taki sposób, że użytkownik ma wrażenie bezpośredniego manipulacji elementami na ekranie. Ponieważ użytkownik bezpośrednio dotyka ekranu, system nie wymaga żadnych dodatkowych afordancji wskazujących manipulowane obiekty.

Implementacje na urządzeniach:

• POWINNY jest mieć jakikolwiek system wprowadzania danych za pomocą wskaźnika (na przykład myszy lub dotyku).
• POWINNA obsługiwać w pełni niezależnie śledzone wskaźniki.

Jeśli urządzenia są wyposażone w ekran dotykowy (pojedynczy przycisk dotykowy lub inny), działają one:

• [C-1-1] MUSI zgłosić wartość TOUCHSCREEN_FINGER w polu interfejsu API Configuration.touchscreen.
• [C-1-2] MUSI zgłosić flagi funkcji android.hardware.touchscreen i android.hardware.faketouch.

Jeśli implementacje urządzeń obejmują ekran dotykowy, który może śledzić więcej niż jeden dotyk:

• [C-2-1] MUSI zgłosić odpowiednie flagi funkcji android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct i android.hardware.touchscreen.multitouch.jazzhand odpowiednie dla typu konkretnego ekranu dotykowego urządzenia.

Jeśli implementacje urządzeń nie zawierają ekranu dotykowego (i korzystają wyłącznie z urządzenia wskazującego) i spełniają wymagania dotyczące fałszywego dotyku opisane w sekcji 7.2.5:

• [C-3-1] NIE MOŻE zgłaszać żadnych flag funkcji rozpoczynających się od android.hardware.touchscreen i MOŻE zgłaszać tylko android.hardware.faketouch.

7.2.5 Wprowadzanie tekstu fałszywego dotykiem

Fałszywy interfejs dotykowy udostępnia system wprowadzania danych, który w przybliżeniu przedstawia podzbiór możliwości z ekranu dotykowego. Na przykład mysz lub pilot, który steruje kursorem na ekranie, przybliża go do kliknięcia, ale wymaga od użytkownika najpierw wyśledzenia lub zaznaczenia, a następnie kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, mysz powietrzna z żyroskopem, żyroskop, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe. Android ma stałą funkcję android.hardware.faketouch, która odpowiada wysokiej jakości bezdotykowemu urządzeniu wejściowemu (opartemu na wskaźniku), takim jak mysz lub trackpad, które może odpowiednio emulować obsługę dotykową (w tym podstawową obsługę gestów). Wskazuje ona, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.

Jeśli urządzenia nie zawierają ekranu dotykowego, ale zawierają inny system wprowadzania danych, który ma zostać udostępniony, to:

• Trzeba zadeklarować obsługę flagi funkcji android.hardware.faketouch.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.faketouch, będą to:

• [C-1-1] MUSI podawać bezwzględne położenie ekranu na osi X i Y oraz wyświetlać wskaźnik wizualny na ekranie.
• [C-1-2] MUSI zgłaszać zdarzenie dotknięcia za pomocą kodu działania, który określa zmianę stanu, która następuje po przesuwaniu się w dół lub w górę ekranu przez wskaźnik.
• [C-1-3] MUSI obsługiwać kursor w dół i w górę na obiekcie na ekranie, co umożliwia użytkownikom emulację dotknięcia obiektu na ekranie.
• [C-1-4] MUSI obsługiwać wskaźnik w dół, w górę i w dół, a następnie powinien wskazywać w górę to samo miejsce na obiekcie na ekranie w wyznaczonym przedziale czasu. Umożliwia to użytkownikom emulację dwukrotnego kliknięcia obiektu na ekranie.
• [C-1-5] MUSI obsługiwać kursor w dół w dowolnym punkcie na ekranie. Wskaźnik powinien przesunąć się do dowolnego innego punktu na ekranie, a po nim przesuń wskaźnik w górę, co pozwoli użytkownikowi emulować przeciąganie dotykiem.
• [C-1-6] MUSI obsługiwać wskaźnik w dół, a następnie umożliwiać użytkownikom szybkie przeniesienie obiektu w inne miejsce na ekranie i przesunięcie go w górę, co umożliwia przesuwanie obiektu na ekranie.
• [C-1-7] MUSI zgłosić wartość TOUCHSCREEN_NOTOUCH w polu interfejsu API Configuration.touchscreen.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.faketouch.multitouch.distinct, będą to:

• [C-2-1] MUSI zadeklarować obsługę interfejsu android.hardware.faketouch.
• [C-2-2] MUSI obsługiwać odrębne śledzenie co najmniej 2 niezależnych danych wejściowych wskaźnika.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.faketouch.multitouch.jazzhand, będą to:

• [C-3-1] MUSI zadeklarować obsługę interfejsu android.hardware.faketouch.
• [C-3-2] MUSI obsługiwać odrębne śledzenie 5 (śledzenie dłoni) lub większej liczby niezależnie od siebie wprowadzania wskaźnika.

7.2.6 Obsługa kontrolera gier

7.2.6.1 Mapowania przycisków

Jeśli implementacje urządzeń zadeklarują flagę funkcji android.hardware.gamepad:

• [C-1-1] MUSI mieć umieszczony kontroler lub dostarczyć w pudełku osobny kontroler, który umożliwia wprowadzanie wszystkich zdarzeń wymienionych w tabelach poniżej.
• [C-1-2] MUSI być w stanie mapować zdarzenia HID na powiązane stałe view.InputEvent Androida, jak podano w tabelach poniżej. Implementacja Androida obejmuje wdrożenie na kontrolery gier, które spełniają to wymaganie.

Przycisk	Wykorzystanie HID2	Przycisk Androida
A1	0x09 0x0001	KEYCODE_PRZYCISK_A (96)
B1	0x09 0x0002	KEYCODE_PRZYCISK_B (97)
X1	0x09 0x0004	KEYCODE_PRZYCISK_X (99)
T1	0x09 0x0005	KEYCODE_PRZYCISK_Y (100)
Pad kierunkowy w górę1 Na padzie kierunkowym w dół1	0x01 0x00393	AXIS_HAT_Y4
Pad kierunkowy w lewo1 Pad kierunkowy w prawo1	0x01 0x00393	AXIS_HAT_X4
Przycisk na lewym ramieniu1	0x09 0x0007	KEYCODE_Button_L1 (102)
Przycisk na prawym ramieniu1	0x09 0x0008	KEYCODE_PRZYCISK_R1 (103)
Kliknięcie lewym drążkiem1	0x09 0x000E	KEYCODE_button_THUMBL (106)
Kliknięcie prawym przyciskiem myszy1	0x09 0x000F	KEYCODE_button_THUMBR (107)
Strona główna1	0x0c 0x0223	KEYCODE_HOME (3)
Wstecz1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Powyższe przypadki użycia HID muszą być zadeklarowane w amerykańskim urzędzie certyfikacji pada do gier (0x01 0x0005).

3. Wartość logiczna musi wynosić 0, logiczne maksimum to 7, fizyczne minimum to 0, maksimum fizyczne 315, jednostki w stopniach i rozmiar raportu 4. Wartość logiczna oznacza obrót w prawo od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i naciśnięty przycisk w górę, a wartość logiczna 1 oznacza obrót o 45 stopni oraz naciskanie klawiszy strzałek w górę i w lewo.

4 MotionEvent

Elementy sterujące analogowe1	Wykorzystanie HID	Przycisk Androida
Lewy spust	0x02 0x00C5	AXIS_LTRIGGER
Prawy aktywator	0x02 0x00C4	AXIS_RTRIGGER
Lewy joystick	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Prawy joystick	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7 Pilot

Wymagania związane z poszczególnymi urządzeniami znajdziesz w artykule 2.3.1.

7.3. Czujniki

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który ma odpowiedni interfejs API dla programistów zewnętrznych, MUSISZ zaimplementować ten interfejs API w sposób opisany w dokumentacji pakietu Android SDK oraz w dokumentacji Androida open source dotyczącej czujników.

Implementacje na urządzeniach:

• [C-0-1] MUSI dokładnie zgłaszać obecność lub brak czujników dla klasy android.content.pm.PackageManager.
• [C-0-2] MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() i podobnych metod.
• [C-0-3] MUSI działać rozsądnie w przypadku wszystkich innych interfejsów API czujników (na przykład przez zwracanie odpowiednio parametru true lub false, gdy aplikacje próbują zarejestrować detektory, lub nie wywoływać odbiorników, gdy odpowiednie czujniki nie są dostępne itp.).

Jeśli implementacje urządzeń obejmują konkretny typ czujnika, który ma odpowiedni interfejs API dla zewnętrznych programistów, te elementy:

• [C-1-1] MUSI raportować wszystkie pomiary z czujników, używając odpowiednich wartości Międzynarodowego Systemu Jednostek (danych) dla każdego typu czujnika zgodnie z definicją w dokumentacji pakietu Android SDK.
• [C-1-2] MUSI zgłaszać dane z czujnika z maksymalnym opóźnieniem 100 milisekund + 2 * parametr sample_time w przypadku transmisji z czujnika z minimalnym wymaganym czasem oczekiwania wynoszącym 5 ms + 2 * sample_time, gdy procesor aplikacji jest aktywny. Opóźnienie to nie uwzględnia opóźnień w filtrowaniu.
• [C-1-3] MUSI zgłosić pierwszą próbkę z czujnika w ciągu 400 milisekund + 2 * czas_próbki (sample_time) od aktywacji czujnika. W przypadku tej próby można mieć dokładność 0.

• [SR] NALEŻY raportować czas zdarzenia w nanosekundach, zgodnie z definicją w dokumentacji pakietu Android SDK. Musi on przedstawiać czas wystąpienia zdarzenia i zsynchronizowany z zegarem SystemClock.elapsedRealtimeNano(). Zdecydowanie ZALECANE zarówno istniejące, jak i nowe urządzenia z Androidem, tak aby spełniały te wymagania, umożliwiając ich uaktualnienie do przyszłych wersji platformy, w których może to stać się WYMAGANY komponentem. Błąd synchronizacji POWINNY być mniejszy niż 100 milisekund.

• [C-1-4] W przypadku interfejsów API wskazanych w dokumentacji pakietu Android SDK jako czujników ciągłych implementacje urządzeń MUSZĄ stale dostarczać okresowe próbki danych, w których zakłócenia są zdefiniowane jako standardowe odchylenie różnicy pomiędzy kolejnymi zdarzeniami.

• [C-1-5] MUSI mieć pewność, że strumień zdarzeń z czujnika NIE MOŻE zapobiegać przełączeniu procesora urządzenia w stan zawieszenia lub wybudzeniem procesora ze stanu zawieszenia.

• Gdy aktywowanych jest kilka czujników, zużycie energii NIE POWINNO przekraczać sumy zużycia energii przez poszczególne czujniki.

Powyższa lista nie jest wyczerpująca. Udokumentowane działanie pakietu Android SDK i dokumentacji open source Androida dotyczące czujników należy uznać za wiarygodne.

Niektóre typy czujników są złożone, co oznacza, że mogą pochodzić z danych dostarczanych przez co najmniej jeden inny czujnik. (Na przykład czujnik orientacji i czujnika przyspieszenia liniowego).

Implementacje na urządzeniach:

• POWINNA SIĘ stosować te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w sekcji Typy czujników.

Jeśli implementacje urządzeń zawierają czujnik kompozytowy,:

• [C-2-1] MUSI zamontować czujnik w sposób opisany w dokumentacji Androida Open Source dotyczącej czujników złożonych.

7.3.1 Akcelerometr

• Wdrożenia urządzeń POWINIEN zawierać 3-osiowy akcelerometr.

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

• [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-2] MUSI zaimplementować i zgłosić czujnik TYPE_ACCELEROMETER.
• [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Androida zgodnie z opisem w interfejsach API Androida.
• [C-1-4] MUSI być w stanie mierzyć od swobodnego spadania do 4-krotności grawitacji(4g) lub większej na dowolnej osi.
• Rozdzielczość [C-1-5] MUSI mieć co najmniej 12 bitów.
• [C-1-6] MUSI mieć odchylenie standardowe nie większe niż 0,05 m/s^, przy czym odchylenie standardowe powinno być obliczane na podstawie każdej osi dla próbek zebranych w okresie co najmniej 3 sekund z największą częstotliwością próbkowania.
• Zdecydowanie ZALECANE jest wdrożenie czujnika złożonego TYPE_SIGNIFICANT_MOTION.
• Zdecydowanie ZALECANE jest wdrożenie czujnika TYPE_ACCELEROMETER_UNCALIBRATED, jeśli dostępna jest kalibracja akcelerometru online.
• NALEŻY zaimplementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR i TYPE_STEP_COUNTER zgodnie z opisem w dokumentacji pakietu Android SDK.
• POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.
• Rozdzielczość powinna wynosić co najmniej 16 bitów.
• POWINNY być kalibrowane podczas używania, jeśli charakterystyka zmieni się w trakcie cyklu życia i zostanie skompensowana, oraz zachowaj parametry kompensacji między restartami urządzenia.
• POWINNA być kompensowana temperatura.
• NALEŻY też zaimplementować czujnik TYPE_ACCELEROMETER_UNCALIBRATED.

Jeśli implementacje urządzeń obejmują 3-osiowy akcelerometr oraz dowolny z czujników złożonych TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR i TYPE_STEP_COUNTER:

• [C-2-1] Suma ich zużycia energii MUSI zawsze wynosić mniej niż 4 mW.
• Gdy urządzenie jest w stanie dynamicznym lub statycznym, POWINIEN mieć poniżej 2 mW oraz 0,5 mW.

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

• [C-3-1] MUSI zaimplementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• NALEŻY zaimplementować czujnik kompozytowy TYPE_GAME_ROTATION_VECTOR.
• [SR] Zdecydowanie ZALECANE jest wdrożenie czujnika TYPE_GAME_ROTATION_VECTOR w dotychczasowych i nowych urządzeniach z Androidem.

Jeśli urządzenia są wyposażone w 3-osiowy akcelerometr, żyroskop i czujnik magnetometru:

• [C-4-1] MUSI zaimplementować czujnik kompozytowy TYPE_ROTATION_VECTOR.

7.3.2 Magnetometr

• Urządzenie POWINIEN zawierać 3-osiowy magnetometr (kompas).

Jeśli urządzenia są wyposażone w 3-osiowy magnetometr:

• [C-1-1] MUSI zamocować czujnik TYPE_MAGNETIC_FIELD.
• [C-1-2] MUSI zgłaszać zdarzenia z częstotliwością co najmniej 10 Hz i POWINNY zgłaszać zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-3] MUSI być zgodny z układem współrzędnych czujnika Androida zgodnie z opisem w interfejsach API Androida.
• [C-1-4] MUSI być w stanie zmierzyć wartość od -900 μT do +900 μT na każdej osi bez nasycenia.
• [C-1-5] MUSI mieć wartość przesunięcia twardego żelaza na poziomie mniejszą niż 700 μT, a magnetometr musi mieć wartość poniżej 200 μT przez umieszczanie magnetometru z dala od dynamicznych (wywoływanych prądem) i statycznych (wywołanych przez magnesem) pól magnetycznych.
• [C-1-6] MUSI mieć rozdzielczość równą lub większą niż 0,6 μT.
• [C-1-7] MUSI obsługiwać kalibrację online i kompensację odchylenia twardego żelaza oraz zachowywać parametry kompensacji między restartami urządzenia.
• [C-1-8] MUSI mieć kompensację miękkiego żelaza – kalibrację można przeprowadzić podczas używania lub produkcji urządzenia.
• [C-1-9] MUSI mieć odchylenie standardowe obliczone na poziomie osi dla próbek zebranych w okresie co najmniej 3 sekund z największą częstotliwością próbkowania, nie większym niż 1,5 μT; odchylenie standardowe nie może przekraczać 0,5 μT.
• NALEŻY zaimplementować czujnik TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] Zdecydowanie ZALECANE jest wdrożenie czujnika TYPE_MAGNETIC_FIELD_UNCALIBRATED w dotychczasowych i nowych urządzeniach z Androidem.

Jeśli urządzenia są wyposażone w 3-osiowy magnetometr, akcelerometr i żyroskop:

• [C-2-1] MUSI zaimplementować czujnik kompozytowy TYPE_ROTATION_VECTOR.

Jeśli urządzenia są wyposażone w 3-osiowy magnetometr (akcelerometr):

• MOŻESZ zastosować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Jeśli urządzenia są wyposażone w 3-osiowy magnetometr, akcelerometr i czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR:

• [C-3-1] MUSI zużywać mniej niż 10 mW.
• Gdy czujnik jest zarejestrowany w trybie wsadowym z częstotliwością 10 Hz, NALEŻY zużywać mniej niż 3 mW.

7.3.3 GPS

Implementacje na urządzeniach:

• POWINIEN zawierać odbiornik GPS/GNSS.

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

• [C-1-1] MUSI obsługiwać dane wyjściowe lokalizacji z częstotliwością co najmniej 1 Hz, gdy jest wymagane przez LocationManager#requestLocationUpdate.
• [C-1-2] MUSI określić lokalizację na otwartym niebie (silne sygnały, niedostateczna ścieżka wielościeżkowa, HDOP < 2) w ciągu 10 sekund (szybszy czas do pierwszej naprawy) przy połączeniu z internetem o szybkości 0,5 Mb/s lub szybszej. Wymóg ten można zazwyczaj spełnić, stosując technikę wspomaganego lub przewidywanego GPS/GNSS w celu zminimalizowania czasu blokady GPS/GNSS (dane pomocnicze obejmują czas odniesienia, lokalizację referencyjną oraz satelitarne dane efemeryczne/zegar).
  • [C-1-6] Po obliczeniu takiej lokalizacji implementacje urządzenia MUSZĄ określić jego lokalizację na niebie w ciągu 5 sekund, gdy żądania lokalizacji są ponownie uruchamiane, maksymalnie do godziny po początkowym obliczeniu lokalizacji, nawet jeśli kolejne żądanie jest wysyłane bez połączenia do transmisji danych lub po wyłączeniu i włączeniu zasilania.

• Na otwartym niebie po określeniu lokalizacji, gdy jesteś w miejscu lub poruszasz się z przyspieszeniem poniżej 1 metra na sekundę do kwadratu:

  • [C-1-3] MUSI określić lokalizację z dokładnością do 20 metrów i z prędkością do 0, 5 metra na sekundę, w co najmniej 95% przypadków.
  • [C-1-4] MUSI jednocześnie śledzić i raportować za pomocą GnssStatus.Callback co najmniej 8 satelitów z 1 konstelacji.
  • MUSI być w stanie jednocześnie śledzić co najmniej 24 satelity pochodzące z wielu konstelacji (np. GPS + przynajmniej jeden Glonass, Beidou, Galileo).
  • [C-1-5] MUSI zgłaszać generowanie technologii GNSS za pomocą testowego interfejsu API „getGnssYearOfHardware”.
  • [SR] Podczas alarmowego połączenia telefonicznego należy nadal przesyłać zwykłe dane o lokalizacji GPS/GNSS.
  • [SR] Raportuje pomiary GNSS ze wszystkich śledzonych konstelacji (zgodnie z informacjami w komunikatach GnssStatus), z wyjątkiem SBAS.
  • [SR] Raport AGC i częstotliwość pomiaru GNSS.
  • [SR] Raportuje wszystkie szacowane wartości dokładności (w tym kierunek, prędkość i pionową lokalizację) dla każdej lokalizacji GPS/GNSS.
  • Zdecydowanie ZALECANE jest spełnienie jak największej liczby dodatkowych wymagań związanych z urządzeniami zgłaszającymi rok „2016” lub „2017” za pomocą interfejsu Test API LocationManager.getGnssYearOfHardware().

Jeśli implementacje urządzeń obejmują odbiornik GPS/GNSS i zgłaszają możliwość aplikacji za pomocą flagi funkcji android.hardware.location.gps oraz raportu LocationManager.getGnssYearOfHardware() Test API z roku 2016 lub nowszego,:

• [C-2-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja określona na podstawie GPS/GNSS nie jest jeszcze dostępna.
• [C-2-2] MUSI zgłaszać pseudozakresy i częstotliwości pseudozakresów GNSS, jeśli w warunkach na niebie po określeniu lokalizacji, gdy przebywasz w miejscu lub jesteś w ruchu z przyspieszeniem poniżej 0, 2 metra na sekundę do kwadratu, wystarczają do obliczenia pozycji z dokładnością do 20 metrów, a prędkość z zakresu 0, 2 metra na sekundę – co najmniej 95%

Jeśli implementacje urządzeń obejmują odbiornik GPS/GNSS i zgłaszają takie możliwości aplikacjom za pomocą flagi funkcji android.hardware.location.gps i raportów interfejsu LocationManager.getGnssYearOfHardware() Test API z roku 2017 lub nowszego,:

• [C-3-1] MUSI dalej korzystać z normalnych danych o lokalizacji GPS/GNSS podczas połączeń alarmowych.
• [C-3-2] MUSI raportować pomiary GNSS ze wszystkich śledzonych konstelacji (zgodnie z informacjami o stanie GnssStatus), z wyjątkiem SBAS.
• [C-3-3] MUSI podawać raporty AGC i częstotliwość pomiarów GNSS.
• [C-3-4] MUSI podawać wszystkie szacunkowe dane o dokładności (w tym kierunek, prędkość i pionową lokalizację) w ramach każdej lokalizacji GPS/GNSS.

Jeśli implementacje urządzeń obejmują odbiornik GPS/GNSS i zgłaszają takie możliwości aplikacjom za pomocą flagi funkcji android.hardware.location.gps i raportów interfejsu LocationManager.getGnssYearOfHardware() Test API z roku 2018 lub nowszego,:

• [C-4-1] MUSI dalej dostarczać normalne dane wyjściowe GPS/GNSS do aplikacji podczas zainicjowanego przez sieć połączenia alarmowego zainicjowanego przez stację komórkową.
• [C-4-2] MUSI przekazywać informacje o położeniu i pomiarach do interfejsu API GNSS Location Provider.

7.3.4 Żyroskop

Implementacje na urządzeniach:

• POWINIEN zawierać żyroskop (czujnik zmian kątowych).
• NIE POWINNO spełniać czujnika żyroskopu, chyba że wraz z nim jest także 3-osiowy akcelerometr.

Jeśli urządzenia są wyposażone w żyroskop:

• [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• [C-1-2] MUSI zaimplementować czujnik TYPE_GYROSCOPE. POWINIEN też zaimplementować czujnik TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-3] MUSI być w stanie mierzyć zmiany orientacji kamery do 1000 stopni na sekundę.
• Rozdzielczość [C-1–4] MUSI mieć co najmniej 12 bitów, a powinna mieć rozdzielczość co najmniej 16 bitów.
• [C-1-5] MUSI mieć kompensację temperatury.
• [C-1-6] MUSI być skalibrowany i skompensowany podczas używania. Zachowaj parametry kompensacji między restartami urządzenia.
• [C-1-7] MUSI mieć wariancję nie większą niż 1e-7 rad^2 / s^2 na Hz (wariancja na Hz lub rad^2 / s). Wariancja może się zmieniać wraz z częstotliwością próbkowania, ale MUSI być ograniczana przez tę wartość. Inaczej mówiąc, jeśli mierzysz wariancję żyroskopu przy częstotliwości próbkowania 1 Hz, POWINIEN wynosić nie więcej niż 1e–7 rad^2/s^2.
• [SR] Zdecydowanie ZALECANE jest wdrożenie czujnika SENSOR_TYPE_GYROSCOPE_UNCALIBRATED w dotychczasowych i nowych urządzeniach z Androidem.
• [SR] ZALECANE jest, aby błąd kalibracji wynosił mniej niż 0,01 rad/s, gdy urządzenie pozostaje w temperaturze pokojowej.
• POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.

Jeśli implementacje urządzeń obejmują żyroskop, akcelerometr i czujnik magnetometrowy:

• [C-2-1] MUSI zaimplementować czujnik kompozytowy TYPE_ROTATION_VECTOR.

Jeśli urządzenia są wyposażone w żyroskop i akcelerometr:

• [C-3-1] MUSI zaimplementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [SR] Zdecydowanie ZALECANE jest wdrożenie czujnika TYPE_GAME_ROTATION_VECTOR w dotychczasowych i nowych urządzeniach z Androidem.
• NALEŻY zaimplementować czujnik kompozytowy TYPE_GAME_ROTATION_VECTOR.

7.3.5 Barometr

• Urządzenie POWINIEN zawierać barometr (czujnik ciśnienia powietrza w tle).

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

• [C-1-1] MUSI zaimplementować i zgłosić czujnik TYPE_PRESSURE.
• [C-1-2] MUSI być w stanie przesyłać zdarzenia z częstotliwością 5 Hz lub większą.
• [C-1-3] MUSI mieć kompensację temperatury.
• [SR] Zdecydowanie ZALECANE jest raportowanie ciśnienia w zakresie od 300 hPa do 1100 hPa.
• Całkowita dokładność 1hPa.
• MUSI mieć względną dokładność 0,12 hPa w zakresie 20 hPa (odpowiednik dokładności ok. 1 m na poziomie ok. 200 m na poziomie morza).

7.3.6 Thermometer

Implementacje urządzeń: * MAJ może zawierać termometr otoczenia (czujnik temperatury). * MOŻNA, ale NIE POWINNO zawierać czujnika temperatury procesora.

Jeśli urządzenia są wyposażone w termometr otoczenia (czujnik temperatury):

• [C-1-1] MUSI być zdefiniowany jako SENSOR_TYPE_AMBIENT_TEMPERATURE i MUSI mierzyć temperaturę otoczenia (w pomieszczeniu lub kabinie pojazdu) w miejscu, w którym użytkownik wchodzi w interakcję z urządzeniem, wyrażoną w stopniach Celsjusza.
• [C-1-2] MUSI być zdefiniowany jako SENSOR_TYPE_TEMPERATURE.
• [C-1-3] MUSI mierzyć temperaturę procesora urządzenia.
• [C-1-4] NIE MOŻE mierzyć żadnych innych temperatury.

Pamiętaj, że w Androidzie 4.0 typ czujnika SENSOR_TYPE_TEMPERATURE został wycofany.

7.3.7 Fotometr

• Urządzenia MOGĄ zawierać fotometr (czujnik jasności otoczenia).

7.3.8 Czujnik zbliżeniowy

• Urządzenia MOGĄ zawierać czujnik zbliżeniowy.

Jeśli urządzenia są wyposażone w czujnik zbliżeniowy:

• [C-1-1] MUSI mierzyć bliskość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI wykrywać obiekty znajdujące się blisko ekranu, ponieważ jego głównym celem jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacje urządzeń obejmują czujnik zbliżeniowy o innej orientacji, NIE MOŻE być dostępny za pomocą tego interfejsu API.
• [C-1-2] MUSI mieć co najmniej 1 bit z dokładnością.

7.3.9. Czujniki wysokiej jakości

Jeśli implementacje urządzeń obejmują zestaw czujników o wyższej jakości (jak opisano w tej sekcji), i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI identyfikować możliwość za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

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

• [C-2-1] MUSI mieć czujnik TYPE_ACCELEROMETER, który:

  • MUSI mieć zakres pomiarów od -8 g do +8 g, a zakres pomiaru od -16 g do +16 g.
  • Rozdzielczość pomiaru MUSI mieć wartość co najmniej 2048 LSB/g.
  • Minimalna częstotliwość pomiaru musi wynosić 12,5 Hz lub mniejszą.
  • MUSI mieć maksymalną częstotliwość pomiaru 400 Hz lub większą. POWINNA obsługiwać kanał SensorDirectChannel RATE_VERY_FAST.
  • Poziom szumu pomiarowego MUSZĄ być większy niż 400 μg/√Hz.
  • MUSISZ zaimplementować typ czujnika bez wybudzania z możliwością buforowania wynoszącą co najmniej 3000 zdarzeń.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 3 mW.
  • [C-SR] Zdecydowanie zalecana jest przepustowość pomiaru na poziomie 3 dB na poziomie co najmniej 80% częstotliwości Nyquist oraz spektrum szumu białego w ramach tej przepustowości.
  • TREŚCI POWINNY być testowane przy przyspieszeniu losowy spacer o wartości poniżej 30 μg √Hz w temperaturze pokojowej.
  • MUSISZ mieć zmianę odchylenia w porównaniu z temperaturą na poziomie ≤ +/- 1 mg/°C.
  • Optymalna nieliniowość w zakresie ≤ 0,5% oraz zmiana czułości względem temperatury na poziomie ≤ 0,03%/C°.
  • Czułość krzyżowa powinna wynosić < 2,5%, a jej różnica w zakresie temperatur działania urządzenia wynosi < 0,2%.

• [C-2-2] MUSI mieć TYPE_ACCELEROMETER_UNCALIBRATED z takimi samymi wymaganiami dotyczącymi jakości jak TYPE_ACCELEROMETER.

• [C-2-3] MUSI mieć czujnik TYPE_GYROSCOPE, który:

  • MUSI mieć zakres pomiaru od -1000 do +1000 dps.
  • Rozdzielczość pomiaru MUSI mieć co najmniej 16 LSB/dps.
  • Minimalna częstotliwość pomiaru musi wynosić 12,5 Hz lub mniejszą.
  • MUSI mieć maksymalną częstotliwość pomiaru 400 Hz lub większą. POWINNA obsługiwać kanał SensorDirectChannel RATE_VERY_FAST.
  • Poziom szumu pomiarowego MUSZĄ być większy niż 0,014°/s/√Hz.
  • [C-SR] Zdecydowanie zalecana jest przepustowość pomiaru na poziomie 3 dB na poziomie co najmniej 80% częstotliwości Nyquist oraz spektrum szumu białego w ramach tej przepustowości.
  • Częstotliwość losowych spacerów MUSI być testowana w temperaturze pokojowej na poziomie niższym niż 0,001°/s √ Hz.
  • MUSI mieć zmianę odchylenia w porównaniu z temperaturą na poziomie ≤ +/- 0,05°/ s / °C.
  • TRZEBA zmienić czułość w porównaniu z temperaturą na poziomie ≤ 0,02% / °C.
  • Optymalny rozmiar nieliniowości musi wynosić ≤ 0,2%.
  • Gęstość szumu powinna wynosić ≤ 0,007°/s/√ Hz.
  • Błąd kalibracji powinien wynosić mniej niż 0,002 rad/s w zakresie temperatur od 10 do 40 °C, gdy urządzenie jest nieruchome.
  • Czułość g powinna być mniejsza niż 0,1°/s/g.
  • Czułość krzyżowa powinna wynosić < 4,0%, a zmienność czułości wyników między osiami powinna wynosić < 0,3% w zakresie temperatur działania urządzenia.

• [C-2-4] MUSI mieć TYPE_GYROSCOPE_UNCALIBRATED z takimi samymi wymaganiami dotyczącymi jakości jak TYPE_GYROSCOPE.

• [C-2-5] MUSI mieć czujnik TYPE_GEOMAGNETIC_FIELD, który:

  • MUSI mieć zakres pomiaru od -900 do +900 μT.
  • MUSI mieć rozdzielczość pomiaru wynoszącą co najmniej 5 LSB/uT.
  • MUSI mieć minimalną częstotliwość pomiaru 5 Hz lub mniejszą.
  • Maksymalna częstotliwość pomiaru MUSI 50 Hz lub większa.
  • MUSI zawierać szum pomiarowy nie większy niż 0,5 uT.

• [C-2-6] MUSI mieć TYPE_MAGNETIC_FIELD_UNCALIBRATED z tymi samymi wymaganiami dotyczącymi jakości co TYPE_GEOMAGNETIC_FIELD, a także:

  • MUSISZ zaimplementować typ czujnika bez wybudzania z możliwością buforowania wynoszącą co najmniej 600 zdarzeń czujnika.
  • [C-SR] Zdecydowanie ZALECANE jest użycie widma szumu białego w zakresie od 1 Hz do co najmniej 10 Hz, gdy częstotliwość raportowania wynosi 50 Hz lub więcej.

• [C-2-7] MUSI mieć czujnik TYPE_PRESSURE, który:

  • MUSI mieć zakres pomiaru od 300 do 1100 hPa.
  • Rozdzielczość pomiaru MUSI mieć co najmniej 80 LSB/hPa.
  • Minimalna częstotliwość pomiaru musi wynosić 1 Hz lub mniejszą.
  • Maksymalna częstotliwość pomiaru MUSI wynosić 10 Hz lub więcej.
  • Poziom szumu pomiarowego MUSI być większy niż 2 Pa/√ Hz.
  • Czujnik MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 300 zdarzeń.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 2 mW.
• [C-2-8] MUSI mieć czujnik TYPE_GAME_ROTATION_VECTOR, który:
  • Czujnik MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 300 zdarzeń.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 4 mW.
• [C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:
  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
• [C-2-10] MUSI mieć czujnik TYPE_STEP_DETECTOR, który:
  • Czujnik MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 100 zdarzeń.
  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
  • Zużycie energii w grupie MUSI nie być mniejsze niż 4 mW.
• [C-2-11] MUSI mieć czujnik TYPE_STEP_COUNTER, który:
  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
• [C-2-12] MUSI mieć czujnik TILT_DETECTOR, który:
  • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
• [C-2-13] Sygnatura czasowa tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr, żyroskop i magnetometr MUSI zawierać się w odległości maksymalnie 2, 5 milisekunda. Sygnatura czasowa tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr i żyroskop POWINIEN być oddalona od siebie w odległości maksymalnie 0,25 milisekundy.
• [C-2-14] MUSI mieć sygnatury czasowe zdarzeń z czujnika żyroskopu z tego samego okresu co podsystem kamery i z dokładnością do 1 milisekundy do wystąpienia błędu.
• [C-2-15] MUSI dostarczyć próbki do aplikacji w ciągu 5 milisekund od momentu, gdy dane są dostępne w dowolnym z powyższych czujników fizycznych do aplikacji.
• [C-2-16] NIE MOŻE generować mocy o mocy większej niż 0,5 mW, gdy urządzenie jest statyczne, i 2,0 mW, gdy jest w ruchu, jeśli włączona jest dowolna kombinacja tych czujników:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] MOŻE mieć czujnik TYPE_PROXIMITY, ale jeśli jest zainstalowany, MUSI mieć co najmniej 100 zdarzeń na buforze.

Wszystkie wymagania dotyczące zużycia energii opisane w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje on moc wykorzystywaną przez cały łańcuch czujników – czujnik, dowolny układ pomocniczy, dowolny dedykowany system przetwarzania czujników itp.

Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników:

• [C-3-1] MUSI prawidłowo zadeklarować obsługę typów kanałów bezpośrednich i poziomu stawek bezpośrednich podwładnych za pomocą interfejsów API isDirectChannelTypeSupported i getHighestDirectReportRateLevel.
• [C-3-2] MUSI obsługiwać co najmniej 1 z 2 typów kanałów bezpośrednich czujnika w przypadku wszystkich czujników, które deklarują obsługę kanału bezpośredniego.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• POWINNA obsługiwać raportowanie zdarzeń przez kanał bezpośredni czujnika głównego czujnika (wariant wybudzenia) tych typów:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Czujniki biometryczne

7.3.10.1. Czytniki linii papilarnych

Jeśli implementacje urządzeń obejmują bezpieczny ekran blokady:

• POWINIEN zawierać czytnik linii papilarnych.

Jeśli implementacje urządzenia obejmują czytnik linii papilarnych i udostępniają go aplikacjom innych firm:

• [C-1-1] MUSI zadeklarować obsługę funkcji android.hardware.fingerprint.
• [C-1-2] MUSI w pełni wdrożyć odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK.
• [C-1-3] MUSI mieć współczynnik fałszywych akceptacji nie wyższy niż 0,002%.
• [SR] Zdecydowanie ZALECANE jest, aby wskaźnik akceptacji i podszywania się podszył się na poziomie nie wyższym niż 7%.
• [C-1-4] MUSI ujawniać, że ten tryb może być mniej bezpieczny niż trudny wzór, silny kod PIN lub hasło i wyraźnie wyliczać ryzyko jego włączenia, jeśli odsetek przypadków podszywania się pod inne osoby jest wyższy niż 7%.
• [C-1-5] W celu weryfikacji odciskiem palca MUSISZ próbować ograniczyć liczbę żądań przez co najmniej 30 sekund po 5 fałszywych próbach weryfikacji odciskiem palca.
• [C-1-6] MUSI mieć implementację magazynu kluczy wspieranego sprzętowo i dopasowywać odciski palców w zaufanym środowisku TEE lub za pomocą układu z bezpiecznym kanałem TEE.
• [C-1-7] MUSI mieć zaszyfrowane i uwierzytelnione kryptograficznie wszystkie dane odcisków palców, tak aby nie można było ich pozyskać, odczytać ani zmienić poza TEE, lub mieć układ z bezpiecznym kanałem dla TEE, zgodnie z wytycznymi dotyczącymi wdrażania na stronie Android Open Source Project.
• [C-1-8] MUSI uniemożliwiać dodanie odcisku palca bez wcześniejszego budowania łańcucha zaufania przez potwierdzenie istniejących danych logowania do urządzenia lub dodanie nowych danych uwierzytelniających urządzenia (kodu PIN, wzoru/hasła) zabezpieczonego przez TEE. Wdrożenie projektu Android Open Source Project zapewnia w ramach ten mechanizm.
• [C-1-9] NIE MOŻE umożliwiać aplikacjom innych firm rozróżniania poszczególnych odcisków palców.
• [C-1-10] MUSI uwzględniać flagę DevicePolicyManager.KEYGUARD_DISABLE_FINGERDR.
• [C-1-11] Po uaktualnieniu z wersji starszej niż 6.0 dane odcisku palca MUSZĄ bezpiecznie przenieść lub usunąć odcisk palca, aby spełnić powyższe wymagania.
• [C-1-12] Po usunięciu konta użytkownika (także po przywróceniu ustawień fabrycznych) MUSI całkowicie usunąć wszystkie dane odcisku palca umożliwiające identyfikację użytkownika.
• [C-1-13] NIE MOŻE zezwalać na niezaszyfrowany dostęp do rozpoznawalnych odcisków palców ani żadnych danych uzyskanych z nich (takich jak wektory dystrybucyjne) do Podmiotu przetwarzającego.
• [SR] Zdecydowanie ZALECANE jest, aby wskaźnik fałszywych odrzuceń wynosił mniej niż 10%, zgodnie z pomiarem na urządzeniu.
• [SR] ZALECANE jest opóźnienie poniżej 1 sekundy, mierzone od chwili dotknięcia czytnika linii papilarnych do momentu odblokowania ekranu w przypadku 1 zarejestrowanego palca.
• NALEŻY użyć ikony odcisku palca Android dostępnej w projekcie Android Open Source Project.

7.3.10.2. Inne czujniki biometryczne

Jeśli implementacje urządzeń zawierają co najmniej 1 czujnik biometryczny niezwiązany z odciskiem palca i udostępniają go aplikacjom innych firm:

• [C-1-1] MUSI mieć współczynnik fałszywych akceptacji nie wyższy niż 0,002%.
• [C-SR] Zdecydowanie ZALECANE jest, aby odsetek przypadków podszywania się pod inne osoby i ich akceptacji nie przekraczał 7%.
• [C-1-2] MUSI ujawniać, że ten tryb może być mniej bezpieczny niż silny kod PIN, wzór lub hasło i wyraźnie wyliczać ryzyko jego włączenia, jeśli odsetek prób podszywania się i akceptowania oszustów przekracza 7%.
• [C-1-3] W celu weryfikacji biometrycznej MUSISZ próbować ograniczyć częstotliwość prób przez co najmniej 30 sekund po 5 fałszywych testach biometrycznych. Fałszywy test oznacza próbę o dostatecznej jakości zapisu (ACQUIRED_GOOD), która nie zgadza się z zarejestrowaną danymi biometrycznymi
• [C-1-4] MUSI mieć wdrożenie magazynu kluczy wspieranego sprzętowo i dopasowywać biometryczne urządzenie TEE lub układ scalony z bezpiecznym kanałem.
• [C-1-5] MUSI mieć zaszyfrowane i uwierzytelnione kryptograficznie wszystkie dane umożliwiające identyfikację, tak aby nie można było ich pozyskać, odczytać ani zmienić poza TEE, lub mieć układ z bezpiecznym kanałem dla TEE, zgodnie z wytycznymi dotyczącymi wdrażania na stronie Android Open Source Project.
• [C-1-6] MUSI powstrzymywać dodawanie nowych danych biometrycznych bez wcześniejszego budowania łańcucha zaufania przez potwierdzenie istniejących danych uwierzytelniających urządzenia lub dodanie nowych danych uwierzytelniających urządzenia (kodu PIN, wzoru/hasła) zabezpieczonego przez TEE. Wdrożenie projektu Android Open Source Project zapewnia w ramach ten mechanizm.
• [C-1-7] NIE MOŻE umożliwiać aplikacjom innych firm rozróżniania rejestracji biometrycznych.
• [C-1-8] MUSI uwzględniać flagę poszczególnych danych biometrycznych (np. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE lub DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-9] MUSI całkowicie usunąć wszystkie dane biometryczne umożliwiające identyfikację użytkownika po usunięciu jego konta (w tym po przywróceniu ustawień fabrycznych).
• [C-1-10] NIE MOŻE zezwalać na niezaszyfrowany dostęp do możliwych do zidentyfikowania danych biometrycznych lub danych pochodzących z nich (takich jak wektory dystrybucyjne) do podmiotu przetwarzającego aplikację poza kontekstem TEE.
• [C-SR] Zdecydowanie ZALECANE jest, aby wskaźnik fałszywych odrzuceń wynosił mniej niż 10%, zgodnie z pomiarem na urządzeniu.
• [C-SR] Zdecydowanie ZALECANE jest opóźnienie poniżej 1 sekundy, mierzone od momentu wykrycia biometrii do momentu odblokowania ekranu w przypadku każdego zarejestrowanego urządzenia biometrycznego.

7.3.11. Czujniki tylko w Androidzie Automotive

Czujniki samochodowe są zdefiniowane w dokumencie android.car.CarSensorManager API.

7.3.11.1 Obecny sprzęt

Wymagania związane z konkretnymi urządzeniami znajdziesz w Sekcji 2.5.1.

7.3.11.2. Tryb dzienny/nocny

Wymagania związane z konkretnymi urządzeniami znajdziesz w Sekcji 2.5.1.

7.3.11.3 Stan jazdy

To wymaganie zostało wycofane.

7.3.11.4. Prędkość koła

Wymagania związane z konkretnymi urządzeniami znajdziesz w Sekcji 2.5.1.

7.3.11.5. Hamulec parkingowy

Wymagania związane z konkretnymi urządzeniami znajdziesz w Sekcji 2.5.1.

7.3.12. Czujnik pozycji

Implementacje na urządzeniach:

• MOŻE obsługiwać czujnik pozycji z 6 stopniami swobody.

Jeśli implementacje urządzeń obsługują czujnik pozycji z sześcioma stopniami swobody:

• [C-1-1] MUSI zaimplementować i zgłosić czujnik TYPE_POSE_6DOF.
• [C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.

7.4 Połączenie transmisji danych

7.4.1 Telefonia

Termin „telefonia” jest używany w interfejsach API Androida, a ten dokument odnosi się w szczególności do sprzętu do nawiązywania połączeń głosowych i wysyłania SMS-ów przez sieć GSM lub CDMA. Choć w tych połączeniach głosowych może być włączona funkcja przełączania pakietów, ale nie jest to konieczne, do celów związanych z Androidem uważa się je za niezależne od wszelkich transmisji danych, które mogą być realizowane w tej samej sieci. Innymi słowy, funkcje „telefonii” i interfejsy API w Androidzie odnoszą się w szczególności do połączeń głosowych i SMS-ów. Na przykład urządzenia, które nie mogą nawiązywać połączeń ani wysyłać/odbierać SMS-ów, nie są uznawane za urządzenia telefoniczne, niezależnie od tego, czy korzystają z sieci komórkowej do przesyłania danych.

• Android MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami, które nie są telefonami.

Jeśli implementacje urządzeń obejmują usługę telefonii GSM lub CDMA:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.telephony i inne flagi funkcji podrzędnych zgodnie z technologią.
• [C-1-2] MUSI wdrożyć pełną obsługę interfejsu API dla danej technologii.

Jeśli implementacje urządzenia nie obejmują sprzętu telefonicznego:

• [C-2-1] MUSI wdrożyć pełne interfejsy API w trybie bezobsługowym.

7.4.1.1 Zgodność z blokadami numerów

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

• [C-1-1] MUSI obsługiwać blokowanie numerów
• [C-1-2] MUSI w pełni zaimplementować usługę BlockedNumberContract i odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-3] MUSI blokować wszystkie połączenia i wiadomości z numeru telefonu w polu „BlockedNumberProvider” bez interakcji z aplikacjami. Jedynym wyjątkiem jest sytuacja, w której blokowanie numerów jest tymczasowo zniesione zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-4] W przypadku zablokowanego połączenia NIE MOŻE zapisywać danych do dostawcy rejestru połączeń na platformie.
• [C-1-5] NIE MOŻE pisać do dostawcy usług telefonicznych w przypadku zablokowanej wiadomości.
• [C-1-6] MUSI wdrożyć interfejs zarządzania zablokowanymi numerami, który jest otwierany z intencją zwracaną przez metodę TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NIE MOŻE umożliwiać użytkownikom pomocniczym wyświetlania ani edytowania zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że główny użytkownik ma pełną kontrolę nad poszczególnymi instancjami usług telefonicznych na urządzeniu. Każdy interfejs związany z blokowaniem MUSI być ukryty dla użytkowników pomocniczych, a lista zablokowanych MUSI być respektowana.
• W przypadku aktualizacji Androida do wersji 7.0 NALEŻY przenieść zablokowane numery do dostawcy.

7.4.1.2. Telecom API

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

• [C-1-1] MUSI obsługiwać interfejsy API ConnectionService opisane w pakiecie SDK.
• [C-1-2] MUSI wyświetlić nowe połączenie przychodzące i zapewnić użytkownikom zgodę na odebranie lub odrzucenie połączenia przychodzącego, gdy jest on w trakcie trwającego połączenia wykonywanego przez aplikację innej firmy, która nie obsługuje funkcji blokady określonej w CAPABILITY_SUPPORT_HOLD.

• [C-SR] Zdecydowanie ZALECANE jest powiadamianie użytkownika, że odebranie połączenia przychodzącego spowoduje przerwanie trwającego połączenia.

  Implementacja AOSP spełnia te wymagania dzięki wyświetlaniu powiadomienia HUD, które informuje użytkownika, że odebranie połączenia przychodzącego spowoduje odrzucenie drugiego połączenia.

• [C-SR] Zdecydowanie ZALECANE jest wstępne wczytywanie domyślnej aplikacji telefonu, która wyświetla wpis z rejestru połączeń i nazwę aplikacji innej firmy w rejestrze połączeń, gdy aplikacja innej firmy ustawi klucz dodatków EXTRA_LOG_SELF_MANAGED_CALLS na PhoneAccount na true.

• [C-SR] Zdecydowanie ZALECANE jest obsługa zdarzeń KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK zestawu słuchawkowego w interfejsach API android.telecom w ten sposób:
  • Wywołaj Connection.onDisconnect(), gdy zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia podczas trwającej rozmowy.
  • Wywołaj Connection.onAnswer(), gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia.
  • Wywołaj Connection.onReject(), gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia.
  • Przełącz stan wyciszenia elementu CallAudioState.

7.4.2 IEEE 802.11 (Wi-Fi)

Implementacje na urządzeniach:

• POWINNO obsługiwać co najmniej jedną formę standardu 802.11.

Jeśli implementacje urządzeń obejmują obsługę standardu 802.11 i udostępniają tę funkcję aplikacji innej firmy:

• [C-1-1] MUSI wdrożyć odpowiedni interfejs API Androida.
• [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.wifi.
• [C-1-3] MUSI zaimplementować interfejs API multicast w sposób opisany w dokumentacji pakietu SDK.
• [C-1-4] MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) podczas działania, w tym:
  • Nawet wtedy, gdy ekran nie jest aktywny.
  • Dotyczy urządzeń Android TV, nawet w trybie gotowości.
• [C-1-5] NIE MOŻE traktować wywołania metody interfejsu API WifiManager.enableNetwork() jako wystarczającego wskaźnika do zmiany aktywnej obecnie usługi Network, która jest domyślnie używana do obsługi ruchu w aplikacjach i jest zwracana przez metody interfejsu API ConnectivityManager, takie jak getActiveNetwork i registerDefaultNetworkCallback. Oznacza to, że MOGĄ wyłączyć dostęp do internetu zapewniany przez innego dostawcę (np. sieć komórkową) tylko wtedy, gdy uda mu się upewnić, że sieć Wi-Fi zapewnia dostęp do internetu.
• [C-SR] Zdecydowanie zalecamy, aby po wywołaniu metody interfejsu API ConnectivityManager.reportNetworkConnectivity() przeprowadzić ponowną ocenę dostępu do internetu w Network, a gdy po przeprowadzeniu oceny wykaże, że bieżący Network nie zapewnia już dostępu do internetu, przełącz się na inną dostępną sieć (np. mobilną transmisję danych), która zapewnia dostęp do internetu.
• [C-SR] Zdecydowanie ZALECANE jest randomizowanie źródłowego adresu MAC i numeru sekwencyjnego żądań ramek sond, raz na początku każdego skanowania, gdy STA jest odłączone.
  • Każda grupa ramek żądania sondowania, która zawiera 1 skanowanie, powinna korzystać z 1 spójnego adresu MAC (NIE POWINNY być randomizowane adresy MAC w trakcie skanowania).
  • Numer sekwencyjny żądania sond powinien powtarzać się w normalny sposób (sekwency) w kolejnych żądaniach sondowania podczas skanowania.
  • Numer sekwencyjny żądania sond powinien być randomizowany między ostatnim żądaniem sondowania a pierwszym żądaniem sondowania w kolejnym skanowaniu.
• [C-SR] Są Zdecydowanie ZALECANE, gdy STA jest odłączone, aby w ramkach żądań sond mogły zostać tylko udostępnione te elementy:
  • Zestaw parametrów identyfikatora SSID (0)
  • Zestaw parametrów DS (3)

Jeśli urządzenia obsługują Wi-Fi i używają Wi-Fi do skanowania lokalizacji, to:

• [C-2-1] MUSI udostępniać liczbę użytkowników, aby włączyć lub wyłączyć wartość odczytywaną za pomocą metody interfejsu API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementacje na urządzeniach:

• POWINNA obsługiwać technologię Wi-Fi Direct (typu Wi-Fi peer-to-peer).

Jeśli implementacje urządzeń obsługują Wi-Fi Direct:

• [C-1-1] MUSI zaimplementować odpowiedni interfejs API Androida w sposób opisany w dokumentacji pakietu SDK.
• [C-1-2] MUSI zgłosić funkcję sprzętową android.hardware.wifi.direct.
• [C-1-3] MUSI obsługiwać normalne działanie Wi-Fi.
• [C-1-4] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Direct.

7.4.2.2. Konfiguracja bezpośredniego linku Wi-Fi

Implementacje na urządzeniach:

• POWINNA spełniać obsługę konfiguracji bezpośredniego linku Wi-Fi (TDLS) zgodnie z opisem w dokumentacji pakietu Android SDK.

Jeśli implementacje urządzeń obejmują obsługę TDLS i TDLS włączone w API Wi-FiManager:

• [C-1-1] MUSI zadeklarować obsługę TDLS do WifiManager.isTdlsSupported.
• Narzędzia TDLS należy używać tylko wtedy, gdy jest to możliwe i korzystne.
• POWINNY jest działać mechanizm heurystyczny i NIE używać TDLS, gdy jego wydajność może być gorsza niż przez punkt dostępu Wi-Fi.

7.4.2.3 Rozpoznawalność Wi-Fi

Implementacje na urządzeniach:

• POWINNO_obsługiwać funkcję Wi-Fi Aware.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i udostępniają tę funkcję aplikacjom innych firm, to:

• [C-1-1] MUSI zaimplementować interfejsy API WifiAwareManager w sposób opisany w dokumentacji pakietu SDK.
• [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.aware.
• [C-1-3] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Aware.
• [C-1-4] MUSI losowo zmieniać adres interfejsu zarządzania Wi-Fi Aware w odstępach nie dłuższych niż 30 minut i przy włączonej funkcji Wi-Fi Aware.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i lokalizacji Wi-Fi (zgodnie z opisem w artykule 7.4.2.5) i ujawnianie tych funkcji aplikacjom innych firm, wtedy:

• [C-2-1] MUSI wdrożyć interfejsy API do wykrywania z uwzględnieniem lokalizacji: setRangingEnabled, setMinOdległośćMm, setMaxOdległośćMm i onServiceDiscoveredWithinRange.

7.4.2.4. Punkt dostępu Wi-Fi

Implementacje na urządzeniach:

• POWINNO_obsługiwać obsługę Wi-Fi Passpoint.

Jeśli implementacje urządzeń obsługują protokół Wi-Fi Passpoint:

• [C-1-1] MUSI zaimplementować interfejsy API WifiManager związane z Passpoint w sposób opisany w dokumentacji pakietu SDK.
• [C-1-2] MUSI obsługiwać standard IEEE 802.11u, zwłaszcza związany z wykrywaniem i wyborem sieci, na przykład w ramach usług GAS i Access Network Query Protocol (ANQP).

Jeśli implementacje urządzeń nie obsługują Passpoint Wi-Fi:

• [C-2-1] Implementacja interfejsów API WifiManager związanych z Passpoint MUSI zgłosić UnsupportedOperationException.

7.4.2.5. Lokalizacja Wi-Fi (czas w obie strony przez Wi-Fi – RTT)

Implementacje na urządzeniach:

• POWINNO_obsługiwać lokalizację przez Wi-Fi.

Jeśli implementacje urządzeń obejmują obsługę lokalizacji Wi-Fi i udostępniają tę funkcję aplikacjom innych firm, to:

• [C-1-1] MUSI zaimplementować interfejsy API WifiRttManager w sposób opisany w dokumentacji pakietu SDK.
• [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.rtt.
• [C-1-3] MUSI randomizować źródłowy adres MAC w przypadku każdej serii RTT, która jest wykonywana, podczas gdy interfejs Wi-Fi, za pomocą którego jest wykonywany RTT, nie jest powiązany z punktem dostępu.

7.4.3 Bluetooth

Jeśli implementacje urządzenia obsługują profil audio Bluetooth:

• POWINNA obsługiwać zaawansowane kodeki audio i kodeki audio Bluetooth (np. LDAC).

Jeśli implementacje urządzeń obsługują HFP, A2DP i AVRCP:

• POWINNA OBSŁUGIWAĆ co najmniej 5 połączonych urządzeń.

Jeśli implementacje urządzenia zadeklarują funkcję android.hardware.vr.high_performance:

• [C-1-1] MUSI obsługiwać rozszerzenie Bluetooth 4.2 i Bluetooth LE.

Android obsługuje Bluetooth i Bluetooth Low Energy.

Jeśli implementacje urządzeń obejmują obsługę Bluetootha i Bluetooth Low Energy, aplikacje:

• [C-2-1] MUSI zadeklarować odpowiednie funkcje platformy (odpowiednio android.hardware.bluetooth i android.hardware.bluetooth_le) i wdrożyć interfejsy API platformy.
• NALEŻY zastosować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX, HFP itp., odpowiednie dla danego urządzenia.

Jeśli implementacje urządzeń obejmują obsługę Bluetooth Low Energy, aplikacje:

• [C-3-1] MUSI zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
• [C-3-2] MUSI włączyć interfejsy API Bluetooth oparte na GATT (ogólnym profilu) w sposób opisany w dokumentacji pakietu SDK i w android.bluetooth.
• [C-3-3] MUSI zgłosić prawidłową wartość BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy logika filtrowania klas interfejsu ScanFilter została zaimplementowana.
• [C-3-4] MUSI zgłosić prawidłową wartość pola BluetoothAdapter.isMultipleAdvertisementSupported(), aby wskazać, czy reklamy Low Energy Advertising są obsługiwane.
• POWINNO obsługiwać przenoszenie logiki filtrowania na chipset Bluetooth podczas wdrażania interfejsu API ScanFilter.
• POWINNO obsługiwać pobieranie skanowania zbiorczego do chipsetu Bluetooth.

• POWINNA obsługiwać wiele reklam z co najmniej 4 boksami.

• [SR] Zdecydowanie ZALECANE jest wdrożenie limitu czasu oczekiwania na rozpoznawalny adres prywatny (RPA) nie dłuższy niż 15 minut i rotacja adresu po przekroczeniu limitu czasu w celu ochrony prywatności użytkowników.

Jeśli implementacje urządzeń obsługują Bluetooth LE i używają Bluetooth LE do skanowania lokalizacji, to:

• [C-4-1] MUSI zapewnić użytkownika, aby włączyć/wyłączyć wartość odczytywaną za pośrednictwem interfejsu API systemu BluetoothAdapter.isBleScanAlwaysAvailable().

7.4.4 Komunikacja Near Field Communication

Implementacje na urządzeniach:

• POWINIEN zawierać nadajnik i powiązany sprzęt do komunikacji Near-Field Communications (NFC).
• [C-0-1] MUSI zaimplementować interfejsy API android.nfc.NdefMessage i android.nfc.NdefRecord, nawet jeśli nie obsługują one NFC lub zadeklaruj funkcję android.hardware.nfc, ponieważ klasy przedstawiają format danych niezależny od protokołu.

Jeśli implementacje urządzeń obejmują sprzęt do komunikacji NFC i planują udostępnić tę funkcję aplikacjom innych firm:

• [C-1-1] MUSI zgłosić funkcję android.hardware.nfc za pomocą metody android.content.pm.PackageManager.hasSystemFeature().
• MUSI być w stanie odczytywać i zapisywać wiadomości NDEF z użyciem następujących standardów NFC, zgodnie z poniższymi standardami:
• [C-1-2] MUSI działać jako czytnik/zapisujący forum NFC (zgodnie ze specyfikacją techniczną NFC Forum-TS-DigitalProtocol-1.0) zgodnie z tymi standardami:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Typy tagów forum NFC 1, 2, 3, 4, 5 (zdefiniowane przez Forum NFC)

• Zdecydowanie zalecana jest możliwość odczytywania i zapisywania wiadomości NDEF, a także nieprzetworzonych danych przy użyciu następujących standardów NFC. Pamiętaj, że chociaż standardy NFC są określone jako Zdecydowanie ZALECANE, zgodnie z definicją zgodności w przyszłości planujemy zmienić je na MUSI. Standardy te są w tej wersji opcjonalne, ale będą wymagane w kolejnych. Zdecydowanie zalecamy spełnienie tych wymagań już teraz i na urządzeniach, na których działa ta wersja Androida, aby umożliwić ich uaktualnienie do przyszłych wersji platformy.

• [C-1-3] MUSI mieć możliwość transmisji i odbierania danych przy użyciu następujących standardów i protokołów peer-to-peer:

  • ISO 18092
  • LLCP 1.2 (zdefiniowane przez Forum NFC)
  • SDP 1.0 (zdefiniowane na Forum NFC)
  • Protokół NDEF Push
  • SNEP 1.0 (zdefiniowane przez Forum NFC)
• [C-1-4] MUSI obsługiwać funkcję Android Beam i POWINIEN domyślnie włączyć Android Beam.
• [C-1-5] MUSI mieć możliwość wysyłania i odbierania wiadomości za pomocą Android Beam, gdy włączona jest funkcja Android Beam lub inny zastrzeżony tryb NFC P2p.
• [C-1-6] MUSI zaimplementować domyślny serwer SNEP. Prawidłowe wiadomości NDEF odbierane przez domyślny serwer SNEP MUSZĄ być wysyłane do aplikacji przy użyciu intencji android.nfc.ACTION_NDEF_DISCOVERED. Wyłączenie Android Beam w ustawieniach NIE MOŻE wyłączać wysyłania przychodzących wiadomości NDEF.
• [C-1-7] MUSI wyświetlać ustawienia udostępniania NFC zgodnie z intencją android.settings.NFCSHARING_SETTINGS.
• [C-1-8] MUSI zaimplementować serwer NPP. Wiadomości odbierane przez serwer NPP MUSZĄ być przetwarzane w taki sam sposób, jak domyślny serwer SNEP.
• [C-1-9] MUSI zaimplementować klienta SNEP i próbować wysłać wychodzącego NDEF P2P do domyślnego serwera SNEP, gdy włączona jest funkcja Android Beam. Jeśli nie zostanie znaleziony domyślny serwer SNEP, klient MUSI spróbować wysłać wiadomość do serwera NPP.
• [C-1-10] MUSI zezwalać na działania na pierwszym planie na ustawianie wychodzących wiadomości NDEF P2P za pomocą metod android.nfc.NfcAdapter.setNdefPushMessage i android.nfc.NfcAdapter.setNdefPushMessageCallback oraz android.nfc.NfcAdapter.enableForegroundNdefPush.
• Przed wysłaniem wychodzących wiadomości P2P NDEF MUSISZ używać gestu lub potwierdzenia na ekranie, takiego jak „Dotknij, aby przesłać”.
• [C-1-11] MUSI obsługiwać przekazywanie połączenia NFC do Bluetooth, jeśli urządzenie obsługuje profil push obiektów Bluetooth.
• [C-1-12] MUSI obsługiwać przekazywanie połączenia do Bluetooth podczas korzystania z android.nfc.NfcAdapter.setBeamPushUris przez wdrożenie specyfikacji „przekazywania połączenia w wersji 1.2” i „bezpiecznego parowania Bluetooth przez NFC w wersji 1.0” na forum NFC. W takiej implementacji MUSI implementować usługę przekazywania LLCP z nazwą usługi „urn:nfc:sn:handover”, która służy do wymiany żądań przekazania/wyboru rekordów przez NFC. Do rzeczywistego przesyłania danych przez Bluetooth MUSI ona używać profilu push obiektu Bluetooth. Ze względów związanych ze starszymi rozwiązaniami (aby zachować zgodność z urządzeniami z Androidem 4.1), implementacja MUSI nadal akceptować żądania SNEP GET dotyczące wymiany żądań przekazania/wyboru rekordów przez NFC. Jednak sama implementacja NIE POWINNO wysyłać żądań SNEP GET do przekazywania połączeń.
• [C-1-13] W trybie wykrywania NFC MUSI przeprowadzać sondowanie w poszukiwaniu wszystkich obsługiwanych technologii.
• POWINNY być w trybie wykrywania NFC, gdy urządzenie jest wybudzone, a ekran jest aktywny, a ekran blokady jest odblokowany.
• MUSI być w stanie odczytać kod kreskowy i adres URL (jeśli jest zakodowany) produktów z kodem kreskowym Thinfilm NFC.

Pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku wymienionych powyżej specyfikacji JIS, ISO i NFC.

Android obsługuje tryb HCE (NFC).

Jeśli implementacje urządzeń zawierają chipset kontrolera NFC obsługujący HCE (NfcA lub NfcB) i obsługują routing na podstawie identyfikatora aplikacji (AID), te urządzenia:

• [C-2-1] MUSI zgłaszać stałą funkcję android.hardware.nfc.hce.
• [C-2-2] MUSI obsługiwać interfejsy NFC HCE API zgodnie z definicją w pakiecie Android SDK.

Jeśli używane urządzenia korzystają z chipsetu kontrolera NFC obsługującego HCE dla NfcF i wdrożą tę funkcję na potrzeby aplikacji innych firm:

• [C-3-1] MUSI zgłaszać stałą funkcję android.hardware.nfc.hcef.
• [C-3-2] MUSI zaimplementować interfejsy API karty NfcF zgodnie z definicją w pakiecie SDK na Androida.

Jeśli implementacje urządzeń obejmują ogólną obsługę NFC zgodnie z opisem w tej sekcji oraz technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF w MIFARE Classic) w roli odczytującego/zapisującego, użytkownicy:

• [C-4-1] MUSI wdrożyć odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
• [C-4-2] MUSI zgłosić funkcję com.nxp.mifare za pomocą metody android.content.pm.PackageManager.hasSystemFeature(). Pamiętaj, że nie jest to standardowa funkcja Androida, dlatego nie jest widoczna jako stała w klasie android.content.pm.PackageManager.

7.4.5 Minimalne możliwości sieci

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać co najmniej jedną formę sieci danych. Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden standard danych o szybkości co najmniej 200 kb/s. Przykłady technologii, które spełniają to wymaganie, to EDGE, HSPA, EV-DO, 802.11g, Ethernet i Bluetooth PAN.
• POWINNA też obsługiwać co najmniej jeden popularny standard bezprzewodowych danych, taki jak 802.11 (Wi-Fi), gdy podstawowym połączeniem transmisji danych jest fizyczny standard sieci (np. Ethernet).
• MOŻESZ wdrożyć więcej niż jedną formę połączeń danych.
• [C-0-2] MUSI zawierać stos sieci IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection, oraz natywnych interfejsów API, takich jak gniazda AF_INET6.
• [C-0-3] MUSI domyślnie włączać IPv6.
• MUSI mieć pewność, że komunikacja IPv6 będzie równie niezawodna jak IPv4. Na przykład:
  • [C-0-4] MUSI utrzymywać połączenia IPv6 w trybie uśpienia.
  • [C-0-5] Ograniczenie szybkości NIE MOŻE spowodować utraty połączeń IPv6 w żadnej sieci zgodnej z IPv6, w której czas trwania RA wynosi co najmniej 180 sekund.
• [C-0-6] MUSI zapewniać zewnętrznym aplikacjom możliwość bezpośredniego połączenia IPv6 z siecią IPv6, bez konieczności lokalnej translacji adresów lub portów na urządzeniu. Zarówno zarządzane interfejsy API, takie jak Socket#getLocalAddress czy Socket#getLocalPort), jak i interfejsy API NDK, takie jak getsockname() lub IPV6_PKTINFO, MUSZĄ zwracać adres IP i port, które są rzeczywiście używane do wysyłania i odbierania pakietów w sieci.

Wymagany poziom obsługi IPv6 zależy od typu sieci, jak pokazano w wymaganiach poniżej.

Jeśli implementacje urządzeń obsługują Wi-Fi:

• [C-1-1] MUSI obsługiwać operacje na stosie podwójnym i tylko IPv6 w Wi-Fi.

Jeśli implementacje urządzeń obsługują protokół Ethernet:

• [C-2-1] MUSI obsługiwać operację podwójnego stosu w sieci Ethernet.

Jeśli implementacje urządzeń obsługują komórkową transmisję danych:

• POWINNA obsługiwać operację IPv6 (tylko w przypadku protokołu IPv6 i ewentualnie stos podwójny) w sieci komórkowej.

Jeśli implementacje urządzeń obsługują więcej niż 1 typ sieci (np. Wi-Fi i komórkowa transmisja danych):

• [C-3-1] MUSI spełniać jednocześnie 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 ustawienie autosynchronizacji głównej, aby metoda getMasterSyncAutomatically() zwracała wartość „true”.

7.4.7 Oszczędzanie danych

Jeśli implementacje urządzeń obejmują połączenie z pomiarem, będą to:

• [SR] Zdecydowanie ZALECANE jest włączenie trybu oszczędzania danych.

Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych:

• [C-1-1] MUSI obsługiwać wszystkie interfejsy API klasy ConnectivityManager w sposób opisany w dokumentacji pakietu SDK
• [C-1-2] MUSI zawierać w ustawieniach interfejs użytkownika, który obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, umożliwiając użytkownikom dodawanie aplikacji do listy dozwolonych lub usuwanie ich z niej.

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

• [C-2-1] MUSI zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED dla ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NIE MOŻE rozgłaszać: ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
• [C-2-3] MUSI mieć działanie, które obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻE je wdrożyć jako no-op.

7.4.8 Zabezpieczone elementy

Jeśli implementacje urządzeń obsługują bezpieczne elementy obsługujące Open Mobile API i udostępniają je aplikacjom innych firm:

• [C-1-1] MUSI wyliczać dostępne czytniki elementów zabezpieczonych, gdy wywoływana jest metoda android.se.omapi.SEService.getReaders().

7.5 kamery,

Jeśli implementacje urządzeń obejmują co najmniej jedną kamerę:

• [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.camera.any.
• [C-1-2] Aplikacja musi mieć możliwość jednoczesnego przypisania 3 map bitowych RGBA_8888 odpowiadających rozmiarowi obrazu generowanego przez czujnik w aparacie o największej rozdzielczości w urządzeniu, a aparat jest otwarty na potrzeby podstawowego podglądu i rejestrowania.

7.5.1 Kamera tylna

Tylny aparat to kamera znajdująca się z boku urządzenia naprzeciw wyświetlacza. Oznacza to, że obrazuje sceny z daleka, tak jak tradycyjny aparat.

Implementacje na urządzeniach:

• POWINIEN zawierać tylny aparat.

Jeśli urządzenia mają co najmniej 1 tylny aparat:

• [C-1-1] MUSI zgłosić flagę funkcji android.hardware.camera i android.hardware.camera.any.
• [C-1-2] MUSI mieć rozdzielczość co najmniej 2 megapiksele.
• W sterowniku aparatu musi być zaimplementowany sprzętowy autofokus lub programowy autofokus (przezroczysty dla oprogramowania).
• MOŻE mieć sprzęt o stałej ostrości lub EDOF (rozszerzona głębia ostrości).
• MOŻE zawierać obiekty flash.

Jeśli aparat ma lampę błyskową:

• [C-2-1] Lampa błyskowa NIE MOŻE się świecić, gdy zostało zarejestrowane wystąpienie android.hardware.Camera.PreviewCallback na platformie podglądu aparatu, chyba że aplikacja wyraźnie włączyła lampę błyskową przez włączenie atrybutu FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu na urządzeniu, a tylko aplikacji innych firm korzystających z Camera.PreviewCallback.

7.5.2 Przedni aparat

Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz. Jest to kamera zwykle używana do nagrywania obrazu użytkownika, na przykład do wideokonferencji i w podobnych aplikacjach.

Implementacje na urządzeniach:

• MOŻE zawierać przedni aparat.

Jeśli implementacje urządzeń obejmują co najmniej jeden przedni aparat:

• [C-1-1] MUSI zgłosić flagę funkcji android.hardware.camera.any i android.hardware.camera.front.
• [C-1-2] MUSI mieć rozdzielczość co najmniej VGA (640 x 480 pikseli).
• [C-1-3] NIE MOŻE używać przedniego aparatu jako domyślnego dla interfejsu Camera API i NIE MOŻE konfigurować interfejsu API w taki sposób, aby traktował przedni aparat jako domyślny tylny aparat, nawet jeśli jest to jedyny aparat w urządzeniu.
• [C-1-4] Podgląd z kamery MUSI być odbiciem lustrzanym w poziomie względem orientacji określonej przez aplikację, gdy bieżąca aplikacja wprost zażąda obrócenia ekranu kamery przez wywołanie metody android.hardware.Camera.setDisplayOrientation(). Jeśli natomiast bieżąca aplikacja nie zażąda wprost obrócenia ekranu kamery przez wywołanie metody android.hardware.Camera.setDisplayOrientation(), podgląd MUSI być zduplikowany względem domyślnej osi poziomej urządzenia.
• [C-1-5] NIE MOŻE powielać ostatecznej wersji obrazu nieruchomego ani strumieni wideo zwróconych do wywołań zwrotnych aplikacji lub zadeklarowanych do przechowywania multimediów.
• [C-1-6] MUSI odbić obraz wyświetlany po wyświetleniu w taki sam sposób jak obraz podglądu z aparatu.
• MOŻE obejmować funkcje (takie jak autofokus, lampa błyskowa itp.) dostępne w przypadku tylnych aparatów zgodnie z opisem w sekcji 7.5.1.

Jeśli implementacje urządzeń mogą podlegać rotacji przez użytkownika (np. automatycznie za pomocą akcelerometru lub ręcznie za pomocą danych wejściowych użytkownika):

• [C-2-1] Podgląd z aparatu MUSI być odbicie lustrzane w poziomie względem bieżącej orientacji urządzenia.

7.5.3 Kamera zewnętrzna

Implementacje na urządzeniach:

• MOŻESZ obsługiwać kamerę zewnętrzną, która nie zawsze jest podłączona.

Jeśli implementacje urządzeń obejmują obsługę aparatu zewnętrznego:

• [C-1-1] MUSI zadeklarować flagę funkcji platformy android.hardware.camera.external i android.hardware camera.any.
• [C-1-2] MUSI obsługiwać standard USB Video Class (UVC 1.0 lub nowszy), jeśli kamera zewnętrzna jest podłączona przez port hosta USB.
• [C-1-3] MUSI przejść testy CTS kamery z podłączonym fizycznym aparatem zewnętrznym. Szczegółowe informacje o testowaniu CTS aparatu znajdziesz na stronie source.android.com.
• POWINNA obsługiwać kompresję wideo, taką jak MJPEG, by umożliwić przesyłanie niezakodowanych strumieni o wysokiej jakości (tj. nieprzetworzonych lub niezależnie skompresowanych strumieni obrazu).
• MOŻE obsługiwać wiele aparatów.
• MOŻE obsługiwać kodowanie wideo z użyciem kamery.

Jeśli obsługiwane jest kodowanie przy użyciu kamery:

• [C-2-1] Jednoczesny niezakodowany strumień / MJPEG (o rozdzielczości QVGA lub wyższej) MUSI być dostępny dla implementacji urządzenia.

7.5.4 Działanie interfejsu Camera API

Android zawiera 2 pakiety interfejsów API zapewniające dostęp do aparatu. Nowszy interfejs API android.hardware.camera2 zapewnia aplikacji dostęp do aparatu niższego poziomu, w tym wydajne serie bez żadnej kopii i strumieniowanie, które umożliwiają sterowanie ekspozycją, wzmocnieniem, wzmocnieniem bieli, konwertowaniem kolorów, wyciszaniem szumów, wyostrzaniem i nie tylko.

Starszy pakiet interfejsów API (android.hardware.Camera) jest oznaczony jako wycofany w Androidzie 5.0, ale nadal powinien być dostępny dla aplikacji. Implementacje na urządzeniach z Androidem MUSZĄ zapewnić nieprzerwaną obsługę interfejsu API zgodnie z opisem w tej sekcji oraz w pakiecie SDK na Androida.

Wszystkie funkcje typowe dla wycofanej klasy android.hardware.Camera i nowszym pakietem android.hardware.camera2 MUSZĄ mieć taką samą wydajność i jakość w obu interfejsach API. Na przykład przy równoważnych ustawieniach szybkość i dokładność autofokusa muszą być takie same, a jakość zrobionych zdjęć musi być taka sama. Funkcje, które zależą od semantyki obu interfejsów API, nie muszą do siebie pasować pod względem szybkości ani jakości, ale POWINNY być jak najbardziej zbliżone.

Implementacje urządzeń MUSZĄ implementować poniższe sposoby działania w przypadku interfejsów API związanych z aparatem w przypadku wszystkich dostępnych kamer. Implementacje na urządzeniach:

• [C-0-1] MUSI używać android.hardware.PixelFormat.YCbCr_420_SP do obsługi danych podglądu przekazywanych do wywołań zwrotnych aplikacji, gdy aplikacja nigdy nie wywołała android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] MUSI dodatkowo mieć format kodowania NV21, gdy aplikacja rejestruje wystąpienie android.hardware.Camera.PreviewCallback, a system wywołuje metodę onPreviewFrame(), a format podglądu to YCbCr_420_SP, czyli dane w bajcie[] przekazywane do onPreviewFrame(). Oznacza to, że NV21 MUSI być wartością domyślną.
• [C-0-3] MUSI obsługiwać format YV12 (oznaczony stałą wartością android.graphics.ImageFormat.YV12) w przypadku podglądu zarówno przedniego, jak i tylnego aparatu dla android.hardware.Camera. (Sprzętowy koder wideo i kamera mogą używać dowolnego natywnego formatu piksela, ale implementacja urządzenia MUSI obsługiwać konwersję na format YV12).
• [C-0-4] MUSI obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe przez interfejs API android.media.ImageReader w przypadku urządzeń android.hardware.camera2, które reklamują funkcję REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE w android.request.availableCapabilities.
• [C-0-5] Nadal musisz wdrożyć pełny interfejs Camera API podany w dokumentacji pakietu Android SDK, niezależnie od tego, czy urządzenie jest wyposażone w sprzętowy autofokus czy inne funkcje. Na przykład aparaty bez autofokusa MUSZĄ wywoływać dowolne zarejestrowane wystąpienia android.hardware.Camera.AutoFocusCallback (mimo że nie ma to związku z aparatem bez autofokusa). Pamiętaj, że dotyczy to przednich aparatów. Na przykład większość z nich nie obsługuje autofokusa, ale wywołania zwrotne interfejsu API muszą być „sfałszowane” zgodnie z opisem.
• [C-0-6] MUSI rozpoznawać i przestrzegać wszystkich nazw parametrów zdefiniowanych jako stała w klasie android.hardware.Camera.Parameters. I odwrotnie, implementacje urządzeń NIE MOGĄ uznawać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters() innych niż te, które są wymienione jako stałe w zasadzie android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry aparatu (o ile sprzęt na to pozwala) i NIE MOŻE obsługiwać niestandardowych typów parametrów aparatu. Na przykład implementacje urządzeń, które obsługują robienie zdjęć z użyciem technik obrazowania High Dynamic Range (HDR), MUSZĄ obsługiwać parametr Camera.SCENE_MODE_HDR aparatu.
• [C-0-7] MUSI zgłosić odpowiedni poziom pomocy przy użyciu właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i zgłaszać odpowiednie flagi funkcji platformy.
• [C-0-8] MUSI także zadeklarować możliwości poszczególnych kamer android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i zadeklarować odpowiednie flagi funkcji. MUSI zdefiniować flagę funkcji, jeśli któreś z podłączonych do niej kamer ją obsługuje.
• [C-0-9] MUSI transmitować intencję Camera.ACTION_NEW_PICTURE za każdym razem, gdy aparat zrobi nowe zdjęcie i zostanie dodane do sklepu multimedialnego.
• [C-0-10] MUSI transmitować intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy kamera zarejestruje nowy film i dodasz obraz do sklepu multimedialnego.
• [C-SR] Zdecydowanie ZALECANE jest obsługa urządzenia z funkcją logiczną CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA w przypadku urządzeń z kilkoma kamerami skierowanymi w tym samym kierunku, z których każdy jest skierowany w tym kierunku, o ile typ aparatu fizycznego jest obsługiwany przez platformę, a CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL w przypadku aparatów fizycznych – LIMITED, FULL lub LEVEL_3.

7.5.5 Orientacja aparatu

Jeśli urządzenia mają aparat przedni lub tylny:

• [C-1-1] MUSI być zorientowana tak, by długi wymiar kamery był zgodny z długością ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparaty MUSZĄ robić zdjęcia w orientacji poziomej. Dotyczy to niezależnie od naturalnej orientacji urządzenia, czyli zarówno orientacji poziomej, jak i pionowej.

7.6 Pamięć i miejsce na dane

7.6.1 Minimalna ilość pamięci i ilości miejsca na dane

Implementacje na urządzeniach:

• [C-0-1] MUSI zawierać menedżera pobierania, z którego aplikacje MOGĄ pobierać pliki danych. MUSZĄ one pobierać pojedyncze pliki o rozmiarze co najmniej 100 MB do domyślnej lokalizacji w „pamięci podręcznej”.

7.6.2 Pamięć współdzielona aplikacji

Implementacje na urządzeniach:

• [C-0-1] MUSI oferować pamięć współdzieloną przez aplikacje, często nazywana też „wspólną pamięcią zewnętrzną”, „pamięcią współdzieloną aplikacji” lub ścieżką systemu Linux „/sdcard”, w której jest podłączona.
• [C-0-2] MUSI być skonfigurowana z pamięcią współdzieloną domyślnie instalowaną, czyli bez względu na to, czy pamięć jest umieszczona w pamięci wewnętrznej czy na nośniku wymiennym (np. w gniazdku kart Secure Digital).
• [C-0-3] MUSI podłączyć pamięć współdzieloną aplikacji bezpośrednio w ścieżce Linuksa sdcard lub dołączyć łącze symboliczne Linuksa z sdcard do rzeczywistego punktu podłączania.
• [C-0-4] MUSI wymuszać uprawnienie android.permission.WRITE_EXTERNAL_STORAGE w tej pamięci współdzielonej zgodnie z dokumentacją w pakiecie SDK. W przeciwnym razie każda aplikacja uzyskująca to uprawnienie MUSI umożliwia zapis.

Implementacje na urządzeniach MOGĄ spełniać powyższe wymagania, jeśli użyjesz jednego z tych elementów:

• Pamięć wymienna dostępna dla użytkowników, np. gniazdo kart Secure Digital (SD).
• Część pamięci wewnętrznej (niewymiennej) wdrożona w ramach projektu Android Open Source Project (AOSP).

Jeśli implementacje urządzeń korzystają z pamięci wymiennej, aby spełnić powyższe wymagania:

• [C-1-1] MUSI zaimplementować tost lub wyskakujące okienko z ostrzeżeniem dla użytkownika, gdy w gnieździe nie ma nośnika pamięci.
• [C-1-2] MUSI zawierać nośnik pamięci w formacie FAT (np. kartę SD) lub widoczne na pudełku i inne materiały dostępne w momencie zakupu, że taki nośnik trzeba zakupić oddzielnie.

Jeśli implementacje urządzeń wykorzystują część pamięci niewymiennej w celu spełnienia powyższych wymagań:

• NALEŻY użyć implementacji AOSP pamięci współdzielonej aplikacji wewnętrznej.
• MOGĄ dzielić dostępne miejsce z prywatnymi danymi aplikacji.

Jeśli implementacje urządzeń obejmują wiele ścieżek pamięci współdzielonej (np. gniazdo kart SD i wspólną pamięć wewnętrzną), działają one:

• [C-2-1] MUSI zezwalać na zapis w dodatkowej pamięci zewnętrznej tylko wstępnie zainstalowanym i uprawnionym aplikacjom na Androida, które mają uprawnienia WRITE_EXTERNAL_STORAGE, z wyjątkiem zapisów w ich katalogach związanych z odpowiednimi pakietami lub w plikach URI zwróconych przez uruchomienie intencji ACTION_OPEN_DOCUMENT_TREE.

Jeśli urządzenia są wyposażone w port USB z obsługą trybu urządzenia peryferyjnego USB:

• [C-3-1] MUSI udostępniać mechanizm uzyskiwania dostępu do danych w pamięci współdzielonej aplikacji z komputera hosta.
• Treści z obu ścieżek pamięci NALEŻY w przejrzysty sposób udostępniać za pomocą usługi skanera multimediów na Androidzie i usługi android.provider.MediaStore.
• MOŻNA korzystać z pamięci masowej USB, ale spełnienie tego wymagania POWINIEN korzystać z protokołu Media Transfer Protocol.

Jeśli urządzenia są wyposażone w port USB z trybem urządzenia peryferyjnego USB i obsługują protokół Media Transfer Protocol, umożliwiają one:

• POWINNA być zgodna z referencyjnym hostem MTP Androida i Android File Transfer.
• MUSISZ zgłosić klasę urządzenia USB 0x00.
• POWINIEN zgłosić nazwę interfejsu USB „MTP”.

7.6.3 Pamięć elastyczna

Jeśli oczekuje się, że urządzenie ma charakter mobilny (inaczej niż w przypadku telewizora), implementacje urządzeń są:

• [SR] Zdecydowanie ZALECANE jest wdrożenie pamięci adaptacyjnej w stabilnej lokalizacji długoterminowej, ponieważ przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

Jeśli wyjmowany port urządzenia pamięci masowej znajduje się w stabilnej lokalizacji długoterminowej, na przykład w komorze na baterię lub w innej osłonie ochronnej, sposób działania urządzenia:

• [SR] Zdecydowanie ZALECANE jest wdrożenie pamięci dostosowywanej.

7.7. USB

Jeśli urządzenia są wyposażone w port USB:

• POWINNA obsługiwać tryb urządzenia peryferyjnego USB i POWINNO obsługiwać tryb hosta USB.

7.7.1. Tryb urządzenia peryferyjnego USB

Jeśli używane urządzenia są wyposażone w port USB obsługujący tryb peryferyjny:

• [C-1-1] Port MUSI być podłączony do hosta USB ze standardowym portem USB typu A lub C.
• [C-1-2] MUSI zgłosić prawidłową wartość iSerialNumber w standardowym deskrypcie urządzenia USB do android.os.Build.SERIAL.
• [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem oporu typu C i MUSZĄ wykrywać zmiany w reklamach, jeśli obsługują USB typu C.
• [SR] Port powinien używać formatu micro-B, micro-AB lub USB typu C. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
• [SR] Port powinien znajdować się u dołu urządzenia (zgodnie z naturalną orientacją) lub umożliwiać programowe obracanie ekranu we wszystkich aplikacjach (w tym na ekranie głównym), by ekran był prawidłowo wyświetlany, gdy urządzenie jest zorientowane na port u dołu. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
• [SR] POWINNO obsługiwać pobieranie prądu na poziomie 1,5 A podczas sygnału HS i ruchu zgodnie z opisem w specyfikacji ładowania baterii przez USB, wersja 1.2. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
• [SR] Zdecydowanie ZALECAM, aby nie obsługiwać zastrzeżonych metod ładowania, które zmieniają napięcie Vbus do wartości domyślnych lub zmieniają role zlewu/źródła, co może powodować problemy ze współdziałaniem z ładowarkami lub urządzeniami, które obsługują standardowe metody przesyłania przez USB Power Delivery. Choć ta funkcja nazywa się „Zdecydowanie ZALECANE”, w przyszłych wersjach Androida możemy WYMAGAĆ WYMAGANIE obsługi wszystkich urządzeń typu C w celu pełnej interoperacyjności ze standardowymi ładowarkami typu C.
• [SR] ZDECYDOWANIE ZALECANE jest w przypadku obsługi funkcji Power Delivery w przypadku wymiany ról danych i zasilania, jeśli obsługuje ona tryb hosta USB typu C i USB.
• POWINNA obsługiwać technologię Power Delivery w przypadku ładowania wysokiego napięcia oraz obsługa trybów alternatywnych, takich jak wyświetlacz na zewnątrz.
• NALEŻY zaimplementować interfejs API i specyfikację Android Open Accessory (AOA) w sposób opisany w dokumentacji pakietu Android SDK.

Jeśli urządzenia są wyposażone w port USB i stosują specyfikację AOA:

• [C-2-1] MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.accessory.
• [C-2-2] Klasa pamięci masowej USB MUSI zawierać ciąg „android” na końcu opisu interfejsu iInterface pamięci masowej USB

7.7.2 Tryb hosta USB

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

• [C-1-1] MUSI zaimplementować interfejs Android USB Host API w sposób opisany w pakiecie Android SDK i MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.host.
• [C-1-2] MUSI zapewnić obsługę podłączania standardowych urządzeń peryferyjnych USB. Oznacza to, że MUSI:
  • urządzenie musi mieć port USB typu C lub musi być wyposażony w kable umożliwiające podłączenie zastrzeżonego portu urządzenia do standardowego portu USB typu C (urządzenie z USB typu C).
  • urządzenie musi być wyposażone w urządzenie typu A lub użyć kabli podłączających zastrzeżony port urządzenia do standardowego portu USB typu A.
  • Musisz mieć na urządzeniu port micro-AB, który POWINNY być w dostarczeniu z kablem pasującym do standardowego portu typu A.
• [C-1-3] NIE MOŻE być dostarczany z przejściówką konwertowaną z portów USB typu A lub micro-AB na porty typu C (gniazdo).
• [SR] ZALECANE JEST wdrożenie klasy audio USB w sposób opisany w dokumentacji pakietu Android SDK.
• POWINNY jest obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta; reklamowanie źródła zasilania o natężeniu co najmniej 1, 5 A (zgodnie z opisem w sekcji Parametry zakończenia działania w wersji 1.2 specyfikacji kabla USB typu C i złącza w przypadku złączy USB typu C) lub używanie złącza ładowania USB typu C w zakresie natężenia prądu wyjściowego (CDP)
• KONIECZNIE jest wdrożenie i obsługa standardów USB typu C.

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i klasę audio USB, te funkcje:

• [C-2-1] MUSI obsługiwać klasę USB HID.
• [C-2-2] MUSI obsługiwać wykrywanie i mapowanie tych pól danych HID określonych w tabelach wykorzystania USB HID i Żądanie użycia Voice Command na stałe KeyEvent jak poniżej:
  • Identyfikator wykorzystania strony użycia (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Identyfikator wykorzystania strony wykorzystania (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • Identyfikator wykorzystania strony wykorzystania (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • Identyfikator wykorzystania strony użycia (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i platformę Storage Access Framework (SAF), funkcje te:

• [C-3-1] MUSI rozpoznawać zdalnie połączone urządzenia MTP (Media Transfer Protocol) i udostępniać ich treści za pomocą intencji ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT. .

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i USB typu C:

• [C-4-1] MUSI zaimplementować funkcję Dual Role Port zgodnie z definicją w specyfikacji USB typu C (sekcja 4.5.1.3.3).
• [SR] Zdecydowanie ZALECANE jest korzystanie z portu DisplayPort, obsługa technologii USB SuperSzybkości transmisji danych. Zdecydowanie ZALECANE jest obsługa usługi Power Delivery w celu wymiany ról związanych z danymi i zasilaniem.
• [SR] Zdecydowanie ZALECAM, aby NIE obsługiwać trybu akcesorium adaptera audio zgodnie z dodatkiem A do wersji 1.2 dotyczących kabla USB typu C i złącza.
• NALEŻY zastosować model Try.*, który najlepiej pasuje do formatu urządzenia. Na przykład urządzenie przenośne POWINNO obsługiwać model Try.SNK.

7.8 Dźwięk

7.8.1 Mikrofon

Jeśli implementacje urządzeń zawierają mikrofon:

• [C-1-1] MUSI zgłaszać stałą funkcję android.hardware.microphone.
• [C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku opisane w sekcji 5.4.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku opisane w sekcji 5.6.
• [SR] Zdecydowanie ZALECANE jest korzystanie z nagrywania w pobliżu ultradźwięków zgodnie z opisem w sekcji 7.8.3.

Jeśli implementacje urządzenia pomijają mikrofon:

• [C-2-1] NIE MOŻE zgłaszać stałej funkcji android.hardware.microphone.
• [C-2-2] MUSI wdrożyć interfejs API do nagrywania dźwięku co najmniej w trybie bezobsługowym, zgodnie z sekcją 7.

7.8.2 Wyjście audio

Jeśli używane urządzenia są wyposażone w głośnik lub port wyjściowy audio/multimedialny dla urządzenia peryferyjnego audio, takiego jak 4-kanałowe gniazdo słuchawek 3,5 mm lub port w trybie hosta USB klasa audio USB, to umożliwiają:

• [C-1-1] MUSI zgłaszać stałą funkcję android.hardware.audio.output.
• [C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku opisane w sekcji 5.5.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku opisane w sekcji 5.6.
• [SR] Zdecydowanie ZALECANE jest umożliwienie odtwarzania w trybie zbliżonym do ultradźwięków, zgodnie z opisem w sekcji 7.8.3.

Jeśli urządzenia nie mają gniazda głośnika ani wyjścia audio:

• [C-2-1] NIE MOŻE zgłaszać funkcji android.hardware.audio.output.
• [C-2-2] MUSI wdrożyć interfejsy API związane z wyjściem audio przynajmniej w trybie bezobsługowym.

Na potrzeby tej sekcji „port wyjściowy” to fizyczny interfejs, taki jak gniazdo słuchawek 3, 5 mm, port HDMI lub port trybu hosta USB z klasą audio USB. Obsługa wyjścia audio przez protokoły radiowe, takie jak Bluetooth, Wi-Fi czy sieć komórkowa, nie kwalifikuje się jako uwzględnienie „portu wyjściowego”.

7.8.2.1 Analogowe porty audio

Aby w całym ekosystemie Androida były one zgodne z zestawami słuchawkowymi i innymi akcesoriami audio, korzystając z wtyczki audio 3,5 mm w całym ekosystemie Androida, jeśli urządzenia zawierają co najmniej 1 analogowy port audio:

• [C-SR] Zdecydowanie ZALECANE jest użycie co najmniej jednego z portów audio jako 4-kanałowego gniazda słuchawek 3,5 mm.

Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3, 5 mm:

• [C-1-1] MUSI obsługiwać odtwarzanie dźwięku w słuchawkach stereo i stereofonicznych zestawach słuchawkowych z mikrofonem.
• [C-1-2] MUSI obsługiwać wtyczki audio TRRS w kolejności styków CTIA.
• [C-1-3] MUSI obsługiwać wykrywanie kodów kluczy i mapowanie ich na 3 zakresy równoważnej impedancji między mikrofonem a przewodami uziemiającymi we wtyczce audio:
  • Maks. 70 omów: KEYCODE_HEADSETHOOK
  • 210–290 omów: KEYCODE_VOLUME_UP
  • 360–680 omów: KEYCODE_VOLUME_DOWN
• [C-1-4] MUSI uruchamiać ACTION_HEADSET_PLUG po podłączeniu wtyczki, ale dopiero wtedy, gdy wszystkie kontakty podłączone do wtyczki dotykają odpowiednich segmentów gniazda.
• [C-1-5] MUSI NAPRAWDZAĆ co najmniej 150 mV ± 10% napięcia wyjściowego na głośniku o impedancji 32 om.
• [C-1-6] MUSI mieć napięcie odchylenia mikrofonu w zakresie 1,8 V ~ 2,9 V.
• [C-1-7] MUSI wykryć i zmapować kod klucza dla poniższego zakresu równoważnej impedancji między mikrofonem a przewodami uziemiającymi we wtyczce audio:
  • 110–180 omów: KEYCODE_VOICE_ASSIST
• [C-SR] Zdecydowanie ZALECANE jest obsługa wtyczek audio w kolejności pin-out w standardzie OMTP.
• [C-SR] Zdecydowanie ZALECANE jest umożliwienie nagrywania dźwięku z zestawów słuchawkowych stereo z mikrofonem.

Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3,5 mm i obsługują mikrofon oraz transmitują android.intent.action.HEADSET_PLUG z mikrofonem o dodatkowej wartości ustawionej na 1:

• [C-2-1] MUSI obsługiwać wykrywanie mikrofonu na podłączonych akcesorium audio.

7.8.3 Prawie ultradźwiękowy

Dźwięk Near ultradźwiękowy to pasmo 18,5–20 kHz.

Implementacje na urządzeniach:

• MUSI prawidłowo zgłaszać obsługę funkcji audio bliskich ultradźwięków za pomocą interfejsu API AudioManager.getproperty w ten sposób:

Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND ma wartość „true”, źródła dźwięku VOICE_RECOGNITION i UNPROCESSED MUSZĄ spełniać te wymagania:

• [C-1-1] Średnia moc mikrofonu mikrofonu w paśmie 18,5–20 kHz MUSI być niższa niż 15 dB poniżej odpowiedzi przy 2 kHz.
• [C-1-2] Stosunek nieważonego sygnału do szumu mikrofonu powyżej 18,5–20 kHz dla tonu 19 kHz przy -26 dBFS MUSI być nie mniejszy niż 50 dB.

Jeśli PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „true” (prawda):

• [C-2-1] Średnia odpowiedź głośnika w zakresie 18,5 kHz – 20 kHz MUSI być niższa niż 40 dB poniżej odpowiedzi przy 2 kHz.

7.9. Wirtualna rzeczywistość

Android zapewnia interfejsy API i infrastrukturę do tworzenia aplikacji do rzeczywistości wirtualnej (VR), takich jak wysokiej jakości rzeczywistość wirtualna na urządzeniach mobilnych. Implementacje na urządzeniach MUSZĄ poprawnie implementować te interfejsy API i zachowania, zgodnie z opisem w tej sekcji.

7.9.1. Tryb rzeczywistości wirtualnej

Android zapewnia obsługę trybu VR – funkcji, która obsługuje stereoskopowe renderowanie powiadomień i wyłącza komponenty interfejsu monokularowego systemu, gdy aplikacja VR skupia się na użytkowniku.

7.9.2. Tryb rzeczywistości wirtualnej – wysoka wydajność

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

• [C-1-1] MUSI mieć co najmniej 2 rdzenie fizyczne.
• [C-1-2] MUSI zadeklarować funkcję android.hardware.vr.high_performance.
• [C-1-3] MUSI obsługiwać tryb utrzymującej wydajność.
• [C-1-4] MUSI obsługiwać standard OpenGL ES 3.2.
• [C-1-5] MUSI obsługiwać wartość android.hardware.vulkan.level 0.
• MUSI obsługiwać system android.hardware.vulkan.level w wersji 1 lub nowszej.
• [C-1-6] MUSI implementować EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace oraz udostępniać rozszerzenia z listy dostępnych rozszerzeń EGL.
• [C-1-8] MUSI implementować GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture i GL_EXT_protected_textures oraz udostępniać rozszerzenia na liście dostępnych rozszerzeń GL.
• [C-SR] Zdecydowanie ZALECANE jest wdrożenie GL_EXT_external_buffer i GL_EXT_EGL_image_array oraz udostępnienie rozszerzeń na liście dostępnych rozszerzeń GL.
• [C-SR] Zdecydowanie ZALECANE jest obsługa platformy Vulkan 1.1.
• [C-SR] Zdecydowanie ZALECANE jest wdrożenie VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing i VK_KHR_shared_presentable_image oraz umieszczenie ich na liście dostępnych rozszerzeń Vulkan.
• [C-SR] Zdecydowanie ZALECANE jest udostępnienie co najmniej jednej rodziny kolejek Vulkan, w której flags zawiera zarówno VK_QUEUE_GRAPHICS_BIT, jak i VK_QUEUE_COMPUTE_BIT, a queueCount to co najmniej 2.
• [C-1-7] GPU i wyświetlacz MUSZĄ synchronizować dostęp do wspólnego przedniego bufora, tak aby treści VR z prędkością 60 kl./s były wyświetlane z użyciem naprzemiennego renderowania treści VR z 2 kontekstami renderowania bez widocznych zakłóceń.
• [C-1-9] MUSI wdrożyć obsługę flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT zgodnie z opisem w NDK.
• [C-1-10] MUSI zaimplementować obsługę elementów AHardwareBuffer z dowolną kombinacją flag wykorzystania AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT w przypadku co najmniej tych formatów: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] Zdecydowanie ZALECANE jest obsługa alokacji zasobów typu AHardwareBuffer z więcej niż 1 warstwą oraz flagami i formatami określonymi w zasadzie C-1-10.
• [C-1-11] MUSI obsługiwać dekodowanie H.264 z szybkością co najmniej 3840 x 2160 przy 30 kl./s, skompresowaną do średniej szybkości 40 Mb/s (odpowiednik 4 instancji 1920 x 1080 przy 30 kl./s do 10 Mb/s lub 2 instancji przy szybkości 1920 x 6 Mb/s).
• [C-1-12] MUSI obsługiwać HEVC i VP9; MUSI umożliwiać dekodowanie szybkości 0 x 3 Mb/s przy szybkości co najmniej 1920 x 1080 przy 30 kl./s po skompresowaniu do średniej szybkości 10 Mb/s i wymaga dekodowania 3840 x 2160 przy szybkości 30 kl./s do 1 Mb/s (przy prędkości 30 kl./s do 20 Mb/s).
• [C-1-13] MUSI obsługiwać interfejs HardwarePropertiesManager.getDeviceTemperatures API i zwracać dokładne wartości temperatury skóry.
• [C-1-14] MUSI mieć wbudowany ekran, a jego rozdzielczość MUSI wynosić co najmniej 1920 x 1080 pikseli.
• [C-SR] Zdecydowanie zalecana rozdzielczość wyświetlacza to co najmniej 2560 x 1440.
• [C-1-15] Wyświetlacz MUSI aktualizować się z częstotliwością co najmniej 60 Hz w trybie VR.
• [C-1-17] Wyświetlacz MUSI obsługiwać tryb o małej trwałości o czasie trwania wynoszącym ≤ 5 milisekund, przy czym trwałość jest definiowana jako czas, przez jaki piksel emituje światło.
• [C-1-18] MUSI obsługiwać Bluetooth 4.2 oraz Bluetooth LE Data Length Data Extension w sekcji 7.4.3.
• [C-1-19] MUSI obsługiwać i prawidłowo zgłaszać typ kanału bezpośredniego w przypadku wszystkich tych domyślnych typów czujników:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] Zdecydowanie ZALECANE jest obsługa typu kanału bezpośredniego TYPE_HARDWARE_BUFFER we wszystkich wymienionych powyżej typach kanałów bezpośrednich.
• [C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru w przypadku urządzenia android.hardware.hifi_sensors, opisane w sekcji 7.3.9.
• [C-SR] Zdecydowanie ZALECANE jest obsługa funkcji android.hardware.sensor.hifi_sensors.
• [C-1-22] Opóźnienie ulotki dla ruchu do fotonów musi być nie większe niż 28 milisekund.
• [C-SR] Zdecydowanie ZALECANE jest, aby czas oczekiwania dla pełnego ruchu względem fotonów nie przekraczał 20 milisekund.
• [C-1-23] MUSI mieć współczynnik pierwszej klatki, czyli stosunek jasności pierwszej klatki po przejściu z czarnego do białego do jasności białych pikseli w stanie nieruchomym, na poziomie co najmniej 85%.
• [C-SR] Zdecydowanie ZALECANE jest, aby współczynnik pierwszej klatki wynosił co najmniej 90%.
• MOGĄ udostępniać wyłączne rdzeń aplikacji na pierwszym planie i obsługiwać interfejs API Process.getExclusiveCores w celu zwrócenia liczby rdzeni procesora używanych wyłącznie dla aplikacji na pierwszym planie.

Jeśli obsługiwana jest podstawowa wersja podstawowa:

• [C-2-1] NIE MOŻE zezwalać na uruchamianie w niej żadnych innych procesów w przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE umożliwiać uruchomienie niektórych procesów jądra w razie potrzeby.

8. Wydajność i moc

Niektóre kryteria dotyczące minimalnej wydajności i mocy mają kluczowe znaczenie dla wygody użytkowników i wpływają na podstawowe założenia, jakie deweloperzy powinni mieć przy tworzeniu aplikacji.

8.1. Spójność wrażeń użytkownika

Użytkownik może spełnić pewne wymagania minimalne, jeśli chodzi o stały czas reakcji i liczby klatek w aplikacjach i grach. W ten sposób można zapewnić użytkownikom płynny interfejs. Implementacje urządzeń, w zależności od typu urządzenia, MOGĄ wiązać się z wymiernymi wymaganiami dotyczącymi czasu oczekiwania w interfejsie i przełączania zadań. Opisaliśmy to w sekcji 2.

8.2. Skuteczność dostępu do plików

Określenie wspólnej wartości bazowej dla stałej wydajności dostępu do plików w prywatnym miejscu na dane aplikacji (partycja /data) umożliwia deweloperom aplikacji odpowiednie oczekiwania, które ułatwią projektowanie oprogramowania. Implementacje urządzeń, w zależności od typu urządzenia, MOGĄ BYĆ określone wymagania opisane w sekcji 2 dotyczące następujących operacji odczytu i zapisu:

• Wydajność sekwencyjnego zapisu. Pomiar ten polega na zapisaniu pliku o rozmiarze 256 MB w buforze zapisu o wielkości 10 MB.
• Losowa wydajność zapisu. Pomiar ten polega na zapisaniu pliku o wielkości 256 MB z użyciem bufora zapisu o wielkości 4 KB.
• Wydajność sekwencyjnego odczytu. Pomiar dokonywany jest przez odczytanie pliku o wielkości 256 MB z użyciem bufora zapisu o wielkości 10 MB.
• Losowa wydajność odczytu. Pomiar dokonywany jest przez odczytanie pliku o wielkości 256 MB z użyciem bufora zapisu o wielkości 4 KB.

8.3. Tryby oszczędzania energii

Jeśli implementacje urządzeń obejmują funkcje usprawniające zarządzanie energią urządzenia uwzględnione w AOSP lub rozszerzające funkcje tego typu:

• [C-1-1] NIE MOŻE odchodzić od implementacji AOSP w zakresie wyzwalania, konserwacji, wybudzania ani używania globalnych ustawień systemu w trybach C-1-1 i Trybów oszczędzania energii.
• [C-1-2] NIE MOŻE odchodzić od implementacji AOSP w zakresie użycia ustawień globalnych do zarządzania ograniczaniem zadań, alarmów i sieci dla aplikacji w każdym zasobniku w trybie gotowości aplikacji.
• [C-1-3] NIE MOŻE odbiegać od implementacji AOSP w przypadku liczby zasobników gotowości aplikacji używanych w trybie gotowości aplikacji.
• [C-1-4] MUSI zaimplementować zasobniki gotowości aplikacji i uśpienie zgodnie z opisem w artykule Zarządzanie energią.
• [C-1-5] MUSI zwracać urządzenie true za PowerManager.isPowerSaveMode(), gdy urządzenie jest w trybie oszczędzania energii.
• [C-SR] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości włączenia i wyłączenia funkcji oszczędzania baterii.
• [C-SR] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości wyświetlania wszystkich aplikacji zwolnionych z trybów czuwania aplikacji i uśpienia.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ wdrożyć dowolny lub wszystkie 4 stany zasilania w trybie uśpienia zdefiniowany w dokumencie Advanced Configuration and Power Interface (ACPI).

Jeśli implementacje urządzeń implementują stany zasilania S4 określone przez ACPI:

• [C-1-1] MUSI przejść w ten stan tylko wtedy, gdy użytkownik wykona wyraźne działanie, aby przełączyć urządzenie w stan nieaktywny (np. przez zamknięcie pokrywy, która jest fizycznie częścią urządzenia, lub wyłączenie pojazdu bądź telewizora), a także przed ponownym włączeniem urządzenia (np. przez otwarcie pokrywy lub ponowne włączenie pojazdu lub telewizora).

Jeśli implementacje urządzeń implementują stany zasilania S3 zdefiniowane przez ACPI:

• [C-2-1] MUSI spełniać powyższe wymagania C-1-1 lub MUSI wprowadzać stan S3 tylko wtedy, gdy aplikacje innych firm nie potrzebują zasobów systemowych (np. ekranu czy procesora).

  I na odwrót, MUSI wyjść ze stanu S3, gdy aplikacje innych firm potrzebują zasobów systemowych, zgodnie z opisem w tym pakiecie SDK.

  Na przykład, gdy aplikacje innych firm żądają, aby ekran był włączony przez FLAG_KEEP_SCREEN_ON lub cały procesor działał przez PARTIAL_WAKE_LOCK, urządzenie NIE MOŻE przejść w stan S3, chyba że użytkownik zgodnie z opisem w C-1-1 podejmuje wyraźne działanie mające na celu ustanowienie urządzenia w stanie nieaktywnym. I na odwrót: w momencie uruchomienia zadania realizowanego przez aplikacje innych firm za pomocą JobScheduler lub pobrania Komunikacji w chmurze Firebase do aplikacji innych firm urządzenie MUSI wyjść ze stanu S3, chyba że użytkownik je aktywuje. Nie są to wyczerpujące przykłady, a AOSP wykorzystuje liczne sygnały wybudzenia, które aktywują dany stan.

8.4. Rachunkowanie zużycia energii

Dokładniejsze liczenie i raportowanie zużycia energii zapewnia deweloperom aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorca wykorzystania energii przez aplikację.

Implementacje na urządzeniach:

• [SR] ZALECANE jest podanie profilu zasilania dla poszczególnych komponentów, który określa wartość bieżącego zużycia energii przez poszczególne komponenty sprzętowe oraz przybliżone zużycie baterii przez komponenty w danym okresie, zgodnie z dokumentem w witrynie Android Open Source Project.
• [SR] Zdecydowanie ZALECANE jest raportowanie wszystkich wartości zużycia energii w miliiamperach godzin (mAh).
• [SR] Zdecydowanie ZALECANE jest raportowanie zużycia energii przez procesor według identyfikatora UID każdego procesu. Projekt Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [SR] Zdecydowanie ZALECANE jest udostępnienie tej informacji deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.
• MUSI być przypisana do samego komponentu sprzętowego, jeśli nie można przypisać do aplikacji zużycia energii przez komponent sprzętowy.

8.5. Stała skuteczność

W przypadku długotrwałych aplikacji o wysokiej wydajności wydajność może się znacznie wahać ze względu na inne aplikacje działające w tle lub ograniczenie procesora z powodu limitów temperatury. Android ma interfejsy automatyczne, dzięki czemu, gdy urządzenie ma odpowiednie możliwości, główna aplikacja na pierwszym planie może zażądać, aby system zoptymalizował przydział zasobów, aby uwzględnić takie wahania.

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo przekazywać informacje o obsłudze trybu zrównoważonej wydajności za pomocą metody interfejsu API PowerManager.isSustainedPerformanceModeSupported().

• POWINNA obsługiwać tryb stałej wydajności.

Jeśli implementacje urządzeń zgłaszają obsługę trybu trwałej wydajności:

• [C-1-1] MUSI zapewniać aplikacji znajdującej się na pierwszym planie stały poziom wydajności przez co najmniej 30 minut, gdy aplikacja o to poprosi.
• [C-1-2] MUSI spełniać warunki interfejsu API Window.setSustainedPerformanceMode() i innych powiązanych interfejsów API.

Jeśli implementacje urządzeń obejmują co najmniej 2 rdzenie procesora, są to:

• POWINIEN podać co najmniej 1 rdzeń wyłączny, który może być zarezerwowany przez aplikację znajdującą się na pierwszym planie.

Jeśli implementacje urządzeń obsługują rezerwowanie 1 wyłącznego rdzenia dla aplikacji najwyższego poziomu:

• [C-2-1] MUSI raportować za pomocą metody API Process.getExclusiveCores() numery identyfikacyjne wyłącznych rdzeni, które mogą zostać zarezerwowane przez aplikację główną na pierwszym planie.
• [C-2-2] NIE MOŻE zezwalać na uruchamianie żadnych procesów w przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację na uruchamianie wyłącznych rdzeni, ale MOŻE zezwalać na uruchamianie niektórych procesów jądra systemu, jeśli jest to konieczne.

Jeśli implementacje urządzeń nie obsługują rdzeni na wyłączność, są to:

• [C-3-1] MUSI zwracać pustą listę za pomocą metody interfejsu API Process.getExclusiveCores().

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniach:

• [C-0-1] MUSI wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, zgodnie z definicją podaną w dokumentacji dotyczącej zabezpieczeń i uprawnień w interfejsach API w dokumentacji dla programistów aplikacji na Androida.

• [C-0-2] MUSI obsługiwać samodzielnie podpisane aplikacje bez konieczności uzyskania dodatkowych pozwoleń/certyfikatów od osób trzecich/urzędów. Zgodne urządzenia MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w tych podpunktach.

9.1. Uprawnienia

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać model uprawnień Androida zdefiniowany w dokumentacji dla deweloperów aplikacji na Androida. W szczególności MUSZĄ wymuszać wszystkie uprawnienia zdefiniowane w sposób opisany w dokumentacji pakietu SDK. Żadne uprawnienia nie mogą zostać pominięte, zmienione ani ignorowane.

• MOŻE dodać więcej uprawnień, pod warunkiem że ciągi identyfikatorów nowych uprawnień nie znajdują się w przestrzeni nazw android.\*.

• [C-0-2] Uprawnienia z elementem protectionLevel o wartości PROTECTION_FLAG_PRIVILEGED MUSZĄ być przyznawane tylko aplikacjom wstępnie zainstalowanym w ramach chronionych ścieżek obrazu systemu oraz w podzbiorze uprawnień bezpośrednio na liście dozwolonych dla poszczególnych aplikacji. Implementacja AOSP spełnia to wymaganie, odczytując i przestrzegając uprawnień dozwolonych poszczególnych aplikacji z plików na ścieżce etc/permissions/ i używając ścieżki system/priv-app jako ścieżki uprzywilejowanej.

Uprawnienia z poziomem ochrony „Niebezpieczne” to uprawnienia w czasie działania. Aplikacje, które mają targetSdkVersion > 22, wysyłają żądania w czasie działania.

Implementacje na urządzeniach:

• [C-0-3] MUSI wyświetlić specjalny interfejs, w którym użytkownik może zdecydować, czy przyznać wymagane uprawnienia w czasie działania, oraz udostępnić interfejs do zarządzania uprawnieniami w czasie działania.
• [C-0-4] MUSI mieć tylko jedną implementację obu interfejsów użytkownika.
• [C-0-5] NIE MOŻE przyznawać żadnych uprawnień w czasie działania zainstalowanym wstępnie aplikacjom, chyba że:
  • Zgodę użytkownika można uzyskać, zanim aplikacja jej użyje.
  • Uprawnienia w czasie działania są powiązane ze wzorcem intencji, dla którego ustawiona jest wstępnie zainstalowana aplikacja jako domyślny moduł obsługi.
• [C-0-6] MUSI przyznawać uprawnienia android.permission.RECOVER_KEYSTORE tylko tym aplikacjom systemowym, które rejestrują prawidłowo zabezpieczonego agenta odzyskiwania. Prawidłowo zabezpieczony agent przywracania to działający na urządzeniu agent oprogramowania, który synchronizuje się ze zdalną pamięcią urządzenia, która jest wyposażona w bezpieczny sprzęt zapewniający odpowiedni poziom zabezpieczeń lub silniejszy niż jest opisany w usłudze Google Cloud Key Vault. Pozwala to zapobiegać atakom brute-force na podstawie współczynnika wiedzy na ekranie blokady.

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

• Zdecydowanie ZALECANE jest udostępnianie dostępnego dla użytkownika mechanizmu przyznawania lub cofania dostępu do statystyk użytkowania w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS w przypadku aplikacji, które deklarują uprawnienia android.permission.PACKAGE_USAGE_STATS.

Jeśli implementacje urządzenia uniemożliwią aplikacjom (w tym wstępnie zainstalowanym) dostęp do statystyk użytkowania:

• [C-1-1] MUSI nadal mieć działanie obsługujące wzorzec intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale MUSI go zaimplementować w trybie no-op, aby działał podobnie jak w przypadku odrzucenia prośby o dostęp.

9.2. UID i izolacja procesów

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja działa jako unikalny identyfikator UID systemu Unixstyle i w osobnym procesie.
• [C-0-2] MUSI obsługiwać wiele aplikacji z tym samym identyfikatorem użytkownika Linuksa, o ile są one prawidłowo podpisane i skonstruowane, zgodnie z opisem w dokumentacji zabezpieczeń i uprawnień.

9.3. Uprawnienia systemu plików

Implementacje na urządzeniach:

• [C-0-1] MUSI obsługiwać model uprawnień dostępu do plików na Androidzie zgodnie z definicją w dokumentacji dotyczącej zabezpieczeń i uprawnień.

9.4. Alternatywne środowiska wykonawcze

Implementacje na urządzeniach MUSZĄ zachowywać spójność z modelem zabezpieczeń i uprawnień Androida, nawet jeśli obejmują środowiska wykonawcze, w których są wykonywane aplikacje korzystające z innego oprogramowania lub technologii niż format wykonywalny Dalvik lub kod natywny. Krótko mówiąc:

• [C-0-1] Alternatywne środowiska wykonawcze MUSZĄ być aplikacjami na Androida i być zgodne ze standardowym modelem zabezpieczeń Androida opisanym w sekcji sekcja 9.

• [C-0-2] Alternatywne środowiska wykonawcze NIE MOGĄ mieć dostępu do zasobów chronionych przez uprawnienia, które nie są wymagane w pliku AndroidManifest.xml środowiska wykonawczego za pomocą mechanizmu <uses-permission>.

• [C-0-3] Alternatywne środowiska wykonawcze NIE MOGĄ zezwalać aplikacjom na korzystanie z funkcji chronionych uprawnieniami Androida ograniczonych do aplikacji systemowych.

• [C-0-4] Alternatywne środowiska wykonawcze MUSZĄ być zgodne z modelem piaskownicy Androida, a zainstalowane aplikacje korzystające z alternatywnego środowiska NIE MOGĄ wykorzystywać środowiska piaskownicy dla żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida korzystających ze wspólnego identyfikatora użytkownika i certyfikatu podpisywania.

• [C-0-5] Alternatywne środowiska wykonawcze NIE MOGĄ uruchamiać się w środowiskach piaskownicy odpowiadających innym aplikacjom na Androida, przyznawać do nich dostępu ani przyznawać im do nich dostępu.

• [C-0-6] Alternatywnego środowiska wykonawczego NIE MOŻNA uruchamiać razem z innymi aplikacjami ani przyznawać im żadnych uprawnień superużytkownika (roota) ani żadnego innego identyfikatora użytkownika.

• [C-0-7] Jeśli plik .apk alternatywnych środowisk wykonawczych znajduje się w obrazie systemowym implementacji urządzenia, MUSI być podpisany kluczem innym niż klucz używany do podpisywania innych aplikacji uwzględnionych w implementacjach na urządzeniu.

• [C-0-8] Podczas instalowania aplikacji alternatywne środowiska wykonawcze MUSZĄ uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację.

• [C-0-9] Gdy aplikacja musi korzystać z zasobu urządzenia, do którego są przypisane uprawnienia Androida (takie jak Aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI informować użytkownika, że aplikacja będzie miała dostęp do tego zasobu.

• [C-0-10] Jeśli środowisko wykonawcze nie rejestruje możliwości aplikacji w ten sposób, podczas instalowania aplikacji korzystających z tego środowiska wykonawczego MUSI ono zawierać listę wszystkich uprawnień samego środowiska wykonawczego.

• Alternatywne środowiska wykonawcze MUSZĄ instalować aplikacje za pomocą interfejsu PackageManager w osobnych piaskownicy Androida (identyfikatory użytkowników systemu Linux itp.).

• Alternatywne środowiska wykonawcze MOGĄ udostępniać jedną piaskownicę Androida współużytkowaną przez wszystkie aplikacje korzystające z alternatywnego środowiska wykonawczego.

9.5. Obsługa wielu użytkowników

Android zapewnia obsługę wielu użytkowników i pełną izolację użytkowników.

• Implementacje urządzeń MOGĄ BYĆ, ale NIE POWINNY być włączane dla wielu użytkowników, jeśli korzystają z nośników wymiennych jako podstawowej pamięci zewnętrznej.

Jeśli implementacje urządzeń obejmują wielu użytkowników:

• [C-1-1] MUSI spełniać następujące wymagania związane z obsługą wielu użytkowników.
• [C-1-2] MUSI wdrożyć dla każdego użytkownika model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień w interfejsach API.
• [C-1-3] MUSI mieć oddzielne i odizolowane katalogi współdzielonej pamięci aplikacji (/sdcard) dla każdej instancji użytkownika.
• [C-1-4] MUSI mieć pewność, że aplikacje należące do danego użytkownika i uruchamiane w jego imieniu nie mogą wyświetlać, odczytywać ani zapisywać plików należących do innych użytkowników, nawet jeśli dane obu użytkowników są przechowywane w tym samym woluminie lub w tym samym systemie plików.
• [C-1-5] MUSI szyfrować zawartość karty SD, gdy jest włączony wielu użytkowników, przy użyciu klucza zapisanego wyłącznie na niewymiennym nośniku dostępnym tylko dla systemu, jeśli implementacje urządzenia korzystają z nośników wymiennych dla interfejsów API pamięci zewnętrznej. Ponieważ uniemożliwi to odczytanie multimediów na komputerze hosta, trzeba będzie wdrożyć urządzenia na MTP lub podobny system, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika.

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

• [C-2-1] MUSI obsługiwać profile z ograniczonym dostępem – funkcję, która umożliwia właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko skonfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej precyzyjnymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.

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

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

9.6 Ostrzeżenie SMS-a specjalnego

Android umożliwia ostrzeganie użytkowników o wychodzących SMS-ach premium. SMS-y specjalne to SMS-y wysyłane do usługi zarejestrowanej u operatora, za którą użytkownik może być obciążony.

Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.telephony, będą to:

• [C-1-1] MUSI ostrzegać użytkowników przed wysłaniem SMS-a na numery identyfikowane przez wyrażenia regularne zdefiniowane w pliku /data/misc/sms/codes.xml na urządzeniu. Rozwiązania Android Open Source Project, które opracowujemy na potrzeby platformy Android, to implementacja, która spełnia to wymaganie.

9.7. Funkcje zabezpieczeń

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń zarówno jądra, jak i platformy, jak opisano poniżej.

Piaskownica Androida obejmuje funkcje korzystające z systemu Security-Extended Linux (SELinux), obowiązkowej kontroli dostępu (MAC), seccomp sandbox (piaskownica seccomp) i inne funkcje zabezpieczeń jądra systemu Linux. Implementacje na urządzeniach:

• [C-0-1] MUSI zachować zgodność z istniejącymi aplikacjami, nawet jeśli SELinux lub inne funkcje zabezpieczeń są wdrożone poniżej platformy Androida.
• [C-0-2] NIE MOŻE mieć widocznego interfejsu użytkownika po wykryciu naruszenia bezpieczeństwa i zablokowaniu go przez funkcję zabezpieczeń wdrożoną poniżej platformy Androida, ale MOŻE mieć widoczny interfejs w przypadku wystąpienia niezablokowanego naruszenia zabezpieczeń, które skutkuje udanym exploitem.
• [C-0-3] NIE MOŻE udostępniać użytkownikowi ani deweloperowi aplikacji SELinux ani żadnych innych funkcji zabezpieczeń wdrożonych poniżej platformy Androida.
• [C-0-4] NIE MOŻE zezwalać aplikacji, która może wpływać na inną aplikację za pomocą interfejsu API (takiej jak interfejs Device Administration API), aby konfigurować zasady naruszające zgodność.
• [C-0-5] MUSI podzielić platformę multimediów na wiele procesów, aby możliwe było węższe przyznanie dostępu każdemu z nich, zgodnie z opisem na stronie projektu Android Open Source.
• [C-0-6] MUSI wdrożyć mechanizm piaskownicy aplikacji w jądrze, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnej zasady z programów wielowątkowych. Nadrzędny projekt Android Open Source Project spełnia to wymaganie przez włączenie seccomp-BPF z synchronizacją grup wątków (TSYNC) zgodnie z opisem w sekcji Konfiguracja jądra na stronie source.android.com.

Integralność jądra i funkcje samoochrony stanowią integralne elementy zabezpieczeń Androida. Implementacje na urządzeniach:

• [C-0-7] MUSI wdrożyć zabezpieczenia przed przepełnieniem bufora stosu jądra (np. CONFIG_CC_STACKPROTECTOR_STRONG).
• [C-0-8] MUSI wdrożyć rygorystyczną ochronę pamięci jądra, w której kod wykonywalny jest tylko do odczytu, dane tylko do odczytu są niewykonywalne i niemożliwe do zapisu, a dane, które można zapisać, nie są możliwe do wykonania (np. CONFIG_DEBUG_RODATA lub CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] MUSI wdrożyć statyczne i dynamiczne ograniczenia rozmiaru obiektów do sprawdzania kopii między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY) na urządzeniach, które pierwotnie były wysyłane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-10] NIE MOŻE uruchamiać pamięci w przestrzeni użytkownika podczas wykonywania w trybie jądra (np. sprzętowego PXN lub emulowanego przez CONFIG_CPU_SW_DOMAIN_PAN bądź CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które zostały pierwotnie wysłane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-11] NIE MOŻE odczytywać ani zapisywać pamięci przestrzeni użytkownika w jądrze poza zwykłymi interfejsami API umożliwiającymi korzystanie z funkcji kopiowania przez użytkownika (np. sprzętowym numerem PAN lub emulowanym przez CONFIG_CPU_SW_DOMAIN_PAN bądź CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które pierwotnie były wysyłane z interfejsem API na poziomie 28 lub wyższym.
• [C-0-12] MUSI wdrożyć izolację tabel stron jądra na wszystkich urządzeniach, które pierwotnie były wysyłane z interfejsem API na poziomie 28 lub wyższym (np. CONFIG_PAGE_TABLE_ISOLATION lub `CONFIG_UNMAP_KERNEL_AT_EL0).
• [SR] Zdecydowanie ZALECANE jest zachowanie danych jądra, które są zapisywane wyłącznie podczas inicjowania, oznaczone jako przeznaczone tylko do odczytu po zainicjowaniu (np. __ro_after_init).
• [SR] Zdecydowanie ZALECANY jest losowy układ kodu jądra i pamięci oraz unikanie ekspozycji, które mogłyby negatywnie wpłynąć na randomizację (np. CONFIG_RANDOMIZE_BASE z entropią programu rozruchowego przez /chosen/kaslr-seed Device Tree node lub EFI_RNG_PROTOCOL).

Jeśli implementacje urządzeń korzystają z jądra systemu Linux:

• [C-1-1] MUSI zaimplementować SELinux.
• [C-1-2] MUSI ustawić SELinux w tryb globalnego egzekwowania.
• [C-1-3] MUSI skonfigurować wszystkie domeny w trybie wymuszania. Nie są dozwolone żadne domeny w trybie mniej rygorystycznym, w tym domeny specyficzne dla urządzenia lub dostawcy.
• [C-1-4] NIE MOŻE modyfikować, pomijać ani zastępować reguł nigdy, które znajdują się w folderze systemowym/sepolicy dostępnym w nadchodzącym projekcie Android Open Source Project (AOSP), a zasada MUSI skompilować wszystkie obecne reguły, zarówno dla domen AOSP SELinux, jak i specyficznych dla urządzeń/dostawców.
• [C-1-5] MUSI uruchamiać aplikacje innych firm kierowane na interfejs API na poziomie 28 lub wyższym w poszczególnych piaskownicy SELinux z ograniczeniami SELinux dla poszczególnych aplikacji w katalogach prywatnych danych.
• POWINIEN zachować domyślną zasadę SELinux w folderze systemowym/sekwencyjnym nadrzędnego projektu Android Open Source i dodać ją do tej zasady jedynie na potrzeby konfiguracji w określonym urządzeniu.

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

Jeśli implementacje urządzeń korzystają z jądra innego niż Linux:

• [C-2-1] MUSI używać obowiązkowego systemu kontroli dostępu równoważnego z SELinux.

Android zawiera wiele zaawansowanych funkcji obrony, które są wbudowane w zabezpieczenia urządzenia.

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE jest, aby nie wyłączać integralności Control-Flow Integrity (CFI) ani Integer Overflow Sanitization (IntSan) w przypadku komponentów, które mają włączoną tę funkcję.
• [C-SR] Zdecydowanie ZALECANE jest włączenie zarówno CFI, jak i IntSan w przypadku wszelkich dodatkowych komponentów w przestrzeni użytkownika związanych z bezpieczeństwem, co wyjaśniono w artykułach CFI i IntSan.

9.8. Prywatność

9.8.1. Historia wykorzystania

Android przechowuje historię wyborów użytkownika i zarządza nią w usłudze UsageStatsManager.

Implementacje na urządzeniach:

• [C-0-1] MUSI przechowywać taką historię użytkownika w rozsądnym czasie.
• [SR] Zdecydowanie ZALECANE jest zachowanie domyślnie skonfigurowanego 14-dniowego okresu przechowywania w implementacji AOSP.

Android przechowuje zdarzenia systemowe za pomocą identyfikatorów StatsLog i zarządza taką historią za pomocą interfejsów StatsManager i System API IncidentManager.

Implementacje na urządzeniach:

• [C-0-2] MUSI zawierać tylko pola oznaczone symbolem DEST_AUTOMATIC w raporcie o incydentach utworzonym przez klasę Systemowego interfejsu API IncidentManager.
• [C-0-3] NIE MOŻE używać identyfikatorów zdarzeń systemu do rejestrowania zdarzeń innych niż opisane w dokumentach dotyczących pakietu SDK StatsLog. W przypadku rejestrowania dodatkowych zdarzeń systemowych mogą one używać innego identyfikatora atomu z zakresu od 100 000 do 200 000.

9.8.2. Nagrywam

Implementacje na urządzeniach:

• [C-0-1] NIE MOŻE od razu ładować ani rozpowszechniać komponentów oprogramowania, które wysyłają prywatne informacje (np. o naciśnięciach klawiszy czy tekście wyświetlanym na ekranie) poza urządzenie bez jego zgody lub usuwania bieżących powiadomień.

Jeśli implementacje urządzeń obejmują funkcje, które umożliwiają przechwytywanie treści wyświetlanych na ekranie lub nagrywanie strumienia audio odtwarzanego na urządzeniu:

• [C-1-1] MUSI mieć bieżące powiadomienie do użytkownika o włączeniu tej funkcji oraz aktywnym nagrywaniu i rejestrowaniu.

Jeśli implementacje urządzeń zawierają włączony od razu komponent, który może rejestrować dźwięki otoczenia w celu uzyskania przydatnych informacji o kontekście użytkownika:

• [C-2-1] NIE MOŻE przechowywać w trwałych pamięciach urządzeń ani przesyłać poza urządzenie nagranych, nieprzetworzonych plików audio ani żadnych formatów, które można przekonwertować z powrotem na oryginalny dźwięk lub faks, chyba że za wyraźną zgodą użytkownika.

9.8.3 Połączenia

Jeśli urządzenia są wyposażone w port USB z obsługą trybu urządzenia peryferyjnego USB:

• [C-1-1] MUSI wyświetlić interfejs użytkownika z prośbą o zgodę na dostęp do zawartości pamięci współdzielonej przez port USB.

9.8.4 Ruch w sieci

Implementacje na urządzeniach:

• [C-0-1] MUSI zainstalować te same certyfikaty główne dla zaufanego systemu urzędu certyfikacji, które zostały dostarczone w nadrzędnym projekcie Android Open Source.
• [C-0-2] MUSI być wysyłany z pustym magazynem głównego urzędu certyfikacji użytkownika.
• [C-0-3] MUSI wyświetlać użytkownikowi ostrzeżenie informujące, że ruch sieciowy może być monitorowany po dodaniu głównego urzędu certyfikacji użytkownika.

Jeśli ruch z urządzenia jest kierowany przez VPN, takie implementacje urządzeń:

• [C-1-1] MUSI wyświetlać użytkownikowi ostrzeżenie:
  • Ruch w tej sieci może być monitorowany.
  • Ruch ten jest kierowany przez konkretną aplikację VPN udostępniającą tę sieć.

Jeśli implementacje urządzeń mają mechanizm, który jest domyślnie włączony po włączeniu i kieruje ruch danych sieci przez serwer proxy lub bramę VPN (np. wstępne wczytywanie usługi VPN z przyznanym ustawieniem android.permission.CONTROL_VPN), dzięki czemu:

• [C-2-1] MUSI prosić użytkownika o zgodę przed włączeniem tego mechanizmu, chyba że usługa VPN jest włączona przez kontroler zasad dotyczących urządzeń w narzędziu DevicePolicyManager.setAlwaysOnVpnPackage(). W takim przypadku użytkownik nie musi wyrażać osobnej zgody, a jedynie powinien zostać o tym powiadomiony.

Jeśli implementacje urządzeń implementują funkcję kupna-stałych użytkowników, aby włączyć funkcję „stały VPN” w aplikacji VPN innej firmy:

• [C-3-1] MUSI wyłączyć tę funkcję użytkownika dla aplikacji, które nie obsługują stałej sieci VPN w pliku AndroidManifest.xml przez ustawienie atrybutu SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

9.9. Szyfrowanie magazynu danych

Jeśli wydajność kryptografii AES (Advanced Encryption Standard) mierzona przy użyciu najskuteczniejszej technologii AES dostępnej na urządzeniu (np. rozszerzenia ARM Cryptography Extensions) przekracza 50 MiB/s, implementacje na urządzeniu:

• [C-1-1] MUSI obsługiwać szyfrowanie pamięci masowej danych prywatnych aplikacji (partycja /data), a także partycji pamięci współdzielonej aplikacji (partycji /sdcard), jeśli jest to trwała, niewymienna część urządzenia, z wyjątkiem implementacji, które zwykle są wspólne (np. telewizja).
• [C-1-2] MUSI domyślnie włączać szyfrowanie danych, gdy użytkownik zakończy gotową konfigurację, z wyjątkiem implementacji na urządzeniach, które są zwykle udostępniane (np. telewizor).

Jeśli wydajność kryptografii AES wynosi 50 MiB/s lub poniżej 50 MiB/s. [C-9.1] [C-1-5] [C-1-5] [C-1-5] [C-1-5] [C-1-5] [C-1-5] [C-1-5] [C-1-5] [C-1-5], [C-9.2], czy [C-1-5], [C-1-9], [.POMIAR, CZAS REALIZACJI]

Jeśli implementacje na urządzeniach zostały już wdrożone na starszej wersji Androida i nie mogą spełnić wymagań za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z powyższych wymagań.

Implementacje na urządzeniach:

• MUSI spełnić powyższe wymagania dotyczące szyfrowania danych dzięki wdrożeniu szyfrowania opartego na plikach (FBE).

9.9.1. Bezpośredni rozruch

Implementacje na urządzeniach:

• [C-0-1] MUSI wdrożyć interfejsy API trybu bezpośredniego rozruchu, nawet jeśli nie obsługują szyfrowania pamięci.

• [C-0-2] Intencje ACTION_LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED MUSZĄ nadal być transmitowane, aby sygnalizować aplikacji, że dane w aplikacjach szyfrowanych na urządzeniu (DE) i danych uwierzytelniających (CE) są dostępne.

9.9.2. Szyfrowanie oparte na plikach

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

• [C-1-1] MUSI uruchomić się bez żądania podania danych logowania użytkownika i zezwolić aplikacjom wykrywającym bezpośrednie rozruchy na dostęp do pamięci zaszyfrowanej na urządzeniu (DE) po wysłaniu komunikatu ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] MUSI zezwalać na dostęp do pamięci CE (Credential Encrypted) dopiero po odblokowaniu urządzenia przez użytkownika przez podanie danych logowania (np. kodu dostępu, kodu PIN, wzoru lub odcisku palca) po wysłaniu komunikatu ACTION_USER_UNLOCKED.
• [C-1-3] NIE MOŻE oferować żadnej metody odblokowywania pamięci chronionej CE bez podanych przez użytkownika danych logowania lub zarejestrowanego klucza depozytowego.
• [C-1-4] MUSI obsługiwać weryfikację podczas uruchamiania i upewnić się, że klucze DE są kryptograficznie powiązane ze sprzętowym źródłem zaufania urządzenia.
• [C-1-5] MUSI obsługiwać szyfrowanie zawartości pliku przy użyciu AES-256-XTS. AES-256-XTS odnosi się do standardu Advanced Encryption Standard z 256-bitowym kluczem obsługiwanym w trybie XTS. Pełna długość klucza XTS to 512 bitów.

• [C-1-6] MUSI obsługiwać szyfrowanie nazw plików przy użyciu AES-256 w trybie CBC-CTS.

• Klucze chroniące obszary przechowywania CE i DE:

• [C-1-7] MUSI być kryptograficznie powiązany ze sprzętowym magazynem kluczy.

• [C-1-8] Klucze CE MUSZĄ być powiązane z danymi logowania na ekranie blokady użytkownika.
• [C-1-9] Jeśli użytkownik nie określił danych logowania na ekranie blokady, klucze CE MUSZĄ być powiązane z domyślnym kodem dostępu.

• [C-1-10] MUSI być niepowtarzalny, co oznacza, że żaden klucz CE lub DE użytkownika nie pasuje do żadnego klucza CE lub DE innego użytkownika.

• [C-1-11] Domyślnie MUSI używać obsługiwanych szyfrów, długości kluczy i trybów.

• [C-SR] Zdecydowanie ZALECANE jest szyfrowanie metadanych systemu plików, takich jak rozmiar pliku, własność, tryby i atrybuty rozszerzone (xattrs), za pomocą klucza kryptograficznego powiązanego z sprzętowym elementem głównym zaufania urządzenia.

• Trzeba tylko skonfigurować wstępnie zainstalowane niezbędne aplikacje (np. Alarm, telefon, Messenger) i rozpoznawać funkcję bezpośredniego rozruchu.

• MOŻE obsługiwać alternatywne mechanizmy szyfrowania, długości kluczy i tryby w zakresie zawartości oraz szyfrowania nazw plików.

Nadrzędny projekt Android Open Source udostępnia preferowaną implementację tej funkcji opartą na funkcji szyfrowania ext4 jądra systemu Linux.

9.9.3 Pełne szyfrowanie dysku

Jeśli implementacje urządzeń obsługują pełne szyfrowanie dysku (FDE):

• [C-1-1] MUSI używać AES w trybie przeznaczonym do przechowywania danych (np. XTS lub CBC-ESSIV) z kluczem szyfrowania o długości co najmniej 128 bitów.
• [C-1-2] MUSI używać domyślnego kodu dostępu do pakowania klucza szyfrowania i NIE POWOLNO go zapisywać w pamięci klucza szyfrowania bez szyfrowania.
• [C-1-3] MUSI domyślnie szyfrować klucz szyfrowania AES, chyba że użytkownik zrezygnuje z tej funkcji, chyba że jest on aktywny, gdy dane logowania na ekranie blokady są rozciągnięte przy użyciu algorytmu powolnego rozciągania (np. PBKDF2 lub scrypt).
• [C-1-4] Powyższy domyślny algorytm rozciągania haseł MUSI być powiązany kryptograficznie z tym magazynem kluczy, gdy użytkownik nie określił danych logowania na ekranie blokady lub wyłączył możliwość używania hasła do szyfrowania, a urządzenie udostępnia sprzętowy magazyn kluczy.
• [C-1-5] NIE MOŻE wysyłać klucza szyfrowania poza urządzenie (nawet jeśli jest zapakowany wraz z kodem dostępu użytkownika lub kluczem sprzętowym).

Nadrzędny projekt Android Open Source udostępnia preferowaną implementację tej funkcji opartą na funkcji dm-crypt w jądrze Linuksa.

9.10. Integralność urządzenia

Te wymagania zapewniają przejrzystość stanu integralności urządzenia. Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo zgłaszać za pomocą metody System API PersistentDataBlockManager.getFlashLockState(), czy stan programu rozruchowego zezwala na flashowanie obrazu systemu. Stan FLASH_LOCK_UNKNOWN jest zarezerwowany dla wdrożeń na urządzeniach z wcześniejszą wersją Androida, w której nie istniała nowa metoda interfejsu API systemu.

• [C-0-2] MUSI obsługiwać weryfikację podczas uruchamiania, aby zapewnić integralność urządzenia.

Jeśli implementacje urządzeń zostały już wdrożone bez obsługi weryfikacji podczas uruchamiania we wcześniejszej wersji Androida i nie mogą dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, MOGĄ one zostać zwolnione z tego wymogu.

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

• [C-1-1] MUSI zadeklarować flagę funkcji platformy android.software.verified_boot.
• [C-1-2] MUSI przeprowadzić weryfikację przy każdej sekwencji uruchamiania.
• [C-1-3] MUSI rozpocząć weryfikację od stałego klucza sprzętowego, który jest podstawą zaufania, aż do poziomu partycji systemowej.
• [C-1-4] MUSI wdrożyć każdy etap weryfikacji, aby na następnym etapie sprawdzić integralność i autentyczność wszystkich bajtów, zanim wykonasz kod na kolejnym etapie.
• [C-1-5] MUSI używać algorytmów weryfikacji tak silnych jak obecne zalecenia NIST w zakresie algorytmów haszowania (SHA-256) i rozmiarów kluczy publicznych (RSA-2048).
• [C-1-6] NIE MOŻE umożliwiać uruchomienia urządzenia w przypadku niepowodzenia weryfikacji systemu, chyba że użytkownik mimo to wyrazi zgodę – wtedy nie wolno używać danych z niezweryfikowanych bloków pamięci masowej.
• [C-1-7] NIE MOŻE zezwalać na modyfikowanie zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokuje program rozruchowy.
• [C-SR] Jeśli w urządzeniu znajduje się wiele dyskretnych układów scalonych (np. radio, specjalny procesor obrazu), Zdecydowanie ZALECANY jest proces uruchamiania każdego z nich, aby sprawdzić każdy etap podczas uruchamiania.
• [C-1-8] MUSI korzystać z pamięci, w której nie wykryto manipulacji: do przechowywania, czy program rozruchowy jest odblokowany. Dzięki niemu program rozruchowy może wykryć, czy ktoś manipulował w pamięci Androida.
• [C-1-9] MUSI poprosić użytkownika podczas korzystania z urządzenia i wymaga fizycznego potwierdzenia przed zezwoleniem na przejście z trybu blokady programu rozruchowego na tryb odblokowany przez program rozruchowy.
• [C-1-10] MUSI wdrożyć ochronę przed wycofywaniem partycji używanych przez Androida (np. podczas uruchamiania, partycje systemowe) i przechowywać metadane używane do określenia minimalnej dopuszczalnej wersji systemu operacyjnego, w pamięci, w której można sprawdzić działanie systemu.
• [C-SR] Zdecydowanie ZALECANE są wszystkie pliki APK aplikacji z podwyższonymi uprawnieniami, które są powiązane z łańcuchem zaufania zakorzenionego w systemie /system i chronionym przez weryfikację podczas uruchamiania.
• [C-SR] Zdecydowanie ZALECANE jest sprawdzanie wszystkich artefaktów wykonywalnych wczytywanych przez aplikację uprzywilejowaną spoza pliku APK (takiego jak dynamicznie ładowany lub skompilowany kod) przed ich wykonaniem lub Zdecydowanie ZALECANE jest ich niewykonanie.
• NALEŻY zaimplementować ochronę przywracania przed wycofywaniem każdego komponentu z trwałym oprogramowaniem układowym (np. modemu czy aparatu) oraz NALEŻY korzystać z pamięci, w trakcie której doszło do manipulacji, do przechowywania metadanych używanych do określenia minimalnej dopuszczalnej wersji.

Jeśli implementacje urządzeń zostały już wdrożone bez obsługi języków od C-1-8 do C-1-10 na starszej wersji Androida i nie mogą dodać świadczenia tych wymagań za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z tych wymagań.

Projekt Android Open Source projektu zapewnia preferowaną implementację tej funkcji w repozytorium external/avb/, które można zintegrować z programem rozruchowym służącym do wczytywania Androida.

Implementacje na urządzeniach:

• [C-R] ZALECANE jest obsługa interfejsu Android Protected Confirmation API.

Jeśli implementacje urządzeń obsługują interfejs Android Protected confirmation API:

• [C-3-1] MUSI zgłosić parametr true w przypadku interfejsu API ConfirmationPrompt.isSupported().
• [C-3-2] MUSI mieć pewność, że bezpieczny sprzęt ma pełną kontrolę nad wyświetlaczem w taki sposób, że system operacyjny Android nie może go zablokować bez wykrycia przez bezpieczny sprzęt.
• [C-3-3] MUSI mieć pewność, że zabezpieczony sprzęt przejmie pełną kontrolę nad ekranem dotykowym.

9.11. Klucze i dane uwierzytelniające

System magazynu kluczy Android umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i wykorzystywanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub interfejsu Keystore API. Implementacje na urządzeniach:

• [C-0-1] MUSI umożliwiać zaimportowanie lub wygenerowanie co najmniej 8192 kluczy.
• [C-0-2] Uwierzytelnianie na ekranie blokady MUSI mieć limit prób ograniczania liczby żądań i MUSI mieć algorytm wzrastającego ponowienia. Powyżej 150 nieudanych prób opóźnienie MUSI wynosić co najmniej 24 godziny.
• NIE POWINNO ograniczać liczby kluczy, które można wygenerować

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady,:

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

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

9.11.1. Bezpieczny ekran blokady

Implementacja AOSP jest oparta na wielopoziomowym modelu uwierzytelniania, w którym podstawowe uwierzytelnianie oparte na fabryce wiedzy może być poparte albo dodatkowymi, silnymi danymi biometrycznymi, albo słabszymi modalnościami trzeciorzędnymi.

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE jest ustawienie tylko jednej z tych metod jako podstawowej metody uwierzytelniania:
  • Numeryczny kod PIN
  • Hasło alfanumeryczne
  • Wzór przesuwania na siatce zawierającej dokładnie 3 x 3 kropki

Pamiętaj, że w tym dokumencie powyższe metody uwierzytelniania są określane jako zalecane główne metody uwierzytelniania.

Jeśli implementacje urządzeń dodają lub zmieniają zalecane główne metody uwierzytelniania i używają nowej metody uwierzytelniania jako bezpiecznego sposobu blokowania ekranu, nowa metoda uwierzytelniania:

• [C-2-1] MUSI być metodą uwierzytelniania użytkownika opisaną w artykule Wymaganie uwierzytelniania użytkowników przed użyciem klucza.
• [C-2-2] MUSI odblokowywać wszystkie klucze aplikacji innej firmy, aby można było z niej korzystać, gdy użytkownik odblokowuje bezpieczny ekran blokady. Na przykład w przypadku aplikacji innej firmy MUSZĄ być dostępne wszystkie klucze za pomocą odpowiednich interfejsów API, takich jak createConfirmDeviceCredentialIntent i setUserAuthenticationRequired.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania w celu odblokowywania ekranu blokady na podstawie znanego obiektu tajnego i używają nowej metody uwierzytelniania, która umożliwia blokowanie ekranu:

• [C-3-1] Entropia najkrótszej dozwolonej długości danych wejściowych MUSI być większa niż 10 bitów.
• [C-3-2] Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18 bitów.
• [C-3-3] Nowa metoda uwierzytelniania NIE MOŻE zastępować żadnej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) wdrożonych i udostępnionych w AOSP.
• [C-3-4] Nowa metoda uwierzytelniania MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_SOMETHING.

Jeśli implementacje urządzeń dodają lub zmieniają zalecane główne metody uwierzytelniania na potrzeby odblokowywania ekranu blokady i korzystają z nowej metody uwierzytelniania opartej na danych biometrycznych, która ma być traktowana jako bezpieczny sposób blokowania ekranu, nowa metoda:

• [C-4-1] MUSI spełniać wszystkie wymagania opisane w sekcji 7.3.10.2.
• [C-4-2] MUSI mieć mechanizm awaryjny umożliwiający użycie jednej z zalecanych podstawowych metod uwierzytelniania, które są oparte na znanym obiekcie tajnym.
• [C-4-3] MUSI być wyłączona i zezwolić na zalecane główne uwierzytelnianie w celu odblokowywania ekranu tylko wtedy , gdy aplikacja kontrolera zasad urządzeń (DPC) ustawi zasadę funkcji keguard, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures() z dowolnymi powiązanymi flagami biometrycznymi (np. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE lub KEYGUARD_DISABLE_IRIS).
• [C-4-4] MUSI wymagać od użytkownika przeprowadzenia zalecanego podstawowego uwierzytelniania (np. kodu PIN, wzoru, hasła) co najmniej raz na 72 godziny.
• [C-4-5] MUSI mieć współczynnik fałszywych akceptacji, który jest równy lub wyższy niż wartość wymagana w przypadku czytnika linii papilarnych zgodnie z opisem w sekcji 7.3.10. W inny sposób MUSI być wyłączona i zezwalać zalecane uwierzytelnianie główne na odblokowanie ekranu tylko wtedy, gdy aplikacja kontrolera zasad urządzeń (DPC) ustawiła zasadę jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-SR] Zdecydowanie ZALECANE jest, aby współczynniki akceptacji i podszywanie się pod inne osoby były równe lub wyższe niż współczynnik wymagany w przypadku czytnika linii papilarnych zgodnie z opisem w sekcji 7.3.10.
• [C-4-6] MUSI mieć bezpieczny potok przetwarzania, dzięki któremu zabezpieczenia systemu operacyjnego lub jądra nie pozwalają na bezpośrednie wstrzykiwanie danych w celu fałszywego uwierzytelnienia użytkownika.
• [C-4-7] MUSI być powiązany z jednoznacznym potwierdzeniem (np.naciśnięciem przycisku), aby umożliwić dostęp do kluczy magazynu kluczy, jeśli aplikacja ustawia true dla KeyGenParameterSpec.Built.setUserAuthenticationRequired(), a uwierzytelnianie biometryczne jest pasywne (np. twarz lub tęczówka, gdy nie ma wyraźnego sygnału zamiaru).
• [C-SR] Zdecydowanie ZALECANE jest zabezpieczenie działania związanego z użyciem pasywnej biometrii w taki sposób, aby system operacyjny lub luka w jednaku nie mogły zostać użyte w celu podszywania się pod inne osoby. Na przykład oznacza to, że działanie potwierdzenia na podstawie fizycznego przycisku jest kierowane przez styk wejściowe/wyjściowe ogólnego przeznaczenia (GPIO) bezpiecznego elementu (SE), którego nie można wywołać inaczej niż przez naciśnięcie fizycznego przycisku.

Jeśli metody uwierzytelniania biometrycznego nie spełniają wskaźników akceptacji podszywania się pod inne osoby, zgodnie z opisem w sekcji 7.3.10:

• [C-5-1] Metody MUSZĄ być wyłączone, jeśli aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakością niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Po upływie 4-godzinnego limitu czasu bezczynności użytkownik MUSI zostać poproszony o wykonanie zalecanego podstawowego uwierzytelniania (np. kod PIN, wzór, hasło). Limit czasu bezczynności jest resetowany po potwierdzeniu danych logowania do urządzenia.
• [C-5-3] Metody NIE MOGĄ być traktowane jako bezpieczny ekran blokady i MUSZĄ spełniać wymagania opisane w poniższej sekcji rozpoczynające się od cyfry C-8.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania na potrzeby odblokowywania ekranu blokady, a nowa metoda uwierzytelniania jest oparta na tokenie fizycznym lub lokalizacji:

• [C-6-1] MUSZĄ one mieć mechanizm awaryjności umożliwiający użycie jednej z zalecanych podstawowych metod uwierzytelniania, które są oparte na znanym obiekcie tajnym i spełniać wymagania traktowania urządzenia jako bezpiecznego ekranu blokady.
• [C-6-2] Nowa metoda MUSI być wyłączona i umożliwiać odblokowywanie ekranu tylko jednej z zalecanych głównych metod uwierzytelniania, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasady za pomocą metody DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) lub DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakością niż PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] Użytkownik MUSI otrzymywać potwierdzenia użycia jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) co najmniej raz na 72 godziny.
• [C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI spełniać wymagania wymienione w punkcie C-8 poniżej.

Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jednego agenta zaufania, który implementuje systemowy interfejs API TrustAgentService:

• [C-7-1] MUSI być wyraźnie oznaczony w menu ustawień i na ekranie blokady, gdy blokada urządzenia jest odroczona lub może zostać odblokowana przez agenta zaufania. Na przykład AOSP spełnia to wymaganie, wyświetlając opis tekstowy w polach „Ustawienia automatycznie blokuj” i „Błyskawiczne blokowanie przycisku zasilania” w menu ustawień oraz wyraźną ikonę na ekranie blokady.
• [C-7-2] MUSI respektować i w pełni wdrożyć wszystkie interfejsy API agenta zaufania w klasie DevicePolicyManager, takie jak stała KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NIE MOŻE w pełni wdrażać funkcji TrustAgentService.addEscrowToken() na urządzeniu, które jest podstawowym urządzeniem osobistym (np. podręcznym), ale MOŻE w pełni wdrożyć ją w typach urządzeń, które są zwykle używane (np. na urządzeniach z Androidem Television lub Automotive).
• [C-7-4] MUSI szyfrować wszystkie przechowywane tokeny dodane przez TrustAgentService.addEscrowToken().
• [C-7-5] NIE MOŻE przechowywać klucza szyfrowania na tym samym urządzeniu, na którym jest używany. Przykładowo klucz zapisany na telefonie może służyć do odblokowywania konta użytkownika na telewizorze.
• [C-7-6] MUSI poinformować użytkownika o wpływie na bezpieczeństwo przed włączeniem tokena depozytowego na potrzeby odszyfrowywania magazynu danych.
• [C-7-7] MUSI mieć mechanizm awaryjny, aby umożliwić korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania.
• [C-7-8] Użytkownik MUSI otrzymywać potwierdzenia użycia jednej z zalecanych metod uwierzytelniania podstawowych (np. kodu PIN, wzoru, hasła) co najmniej raz na 72 godziny.
• [C-7-9] Po upływie 4-godzinnego limitu czasu bezczynności użytkownika MUSI zostać wyświetlona jedna z zalecanych metod uwierzytelniania podstawowych (np. kod PIN, wzór, hasło). Limit czasu bezczynności jest resetowany po potwierdzeniu danych logowania do urządzenia.
• [C-7-10] NIE MOŻE być traktowane jako bezpieczny ekran blokady i MUSI spełniać wymagania opisane poniżej w punkcie C-8.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania, aby odblokować ekran blokady, który nie jest bezpiecznym ekranem blokady, (jak opisano powyżej), i używaj nowej metody uwierzytelniania do odblokowywania ekranu blokady:

• [C-8-1] Nowa metoda MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] NIE MOŻE resetować liczników czasu wygaśnięcia haseł ustawionych przez DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] NIE MOŻESZ uwierzytelniać dostępu do magazynów kluczy, gdy aplikacja ustawia true dla KeyGenParameterSpec.Builder.setUserAuthenticationRequired().

9.11.2. StrongBox,

System magazynu kluczy Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w specjalnym, bezpiecznym procesorze oraz w osobnym środowisku wykonawczym opisanym powyżej.

Implementacje na urządzeniach:

• [C-SR] Zdecydowanie ZALECANE jest wsparcie dla StrongBox.

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

• [C-1-1] MUSI zadeklarować FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] MUSI zapewniać specjalny bezpieczny sprzęt, który jest używany do tworzenia magazynów kluczy i bezpiecznego uwierzytelniania użytkowników.

• [C-1-3] MUSI mieć dyskretny procesor, który nie współdzieli pamięci podręcznej, pamięci DRAM, współprocesorów ani innych podstawowych zasobów z procesorem aplikacji.

• [C-1-4] MUSI upewnić się, że żadne urządzenia peryferyjne udostępniane punktowi dostępu nie mogą w żaden sposób zmieniać przetwarzania StrongBox ani uzyskiwać z niego żadnych informacji. AP MOŻE wyłączyć lub zablokować dostęp do StrongBox.

• [C-1-5] MUSI mieć wewnętrzny zegar z odpowiednią dokładnością (+-10%), który jest odporny na manipulacje ze strony punktu dostępu.

• [C-1-6] MUSI mieć prawdziwy generator liczb losowych, który generuje jednolicie rozłożone i nieprzewidywalne dane wyjściowe.

• [C-1-7] MUSI być odporny na manipulacje, w tym na przenikanie fizyczne i zakłócenia.

• [C-1-8] MUSI mieć opór w obrębie kanału, w tym na wyciek informacji przez zasilanie, czas, promieniowanie elektromagnetyczne lub boczne kanały promieniowania cieplnego.

• [C-1-9] MUSI mieć bezpieczne miejsce na dane, które zapewnia poufność, integralność, autentyczność, spójność i aktualność. Pamięć NIE MOŻE być odczytywana ani zmieniana, chyba że jest to dozwolone przez interfejsy API StrongBox.

• Aby sprawdzić zgodność z wymaganiami od [C-1-3] do [C-1-9], wdrożenia na urządzeniach:

  • [C-1-10] MUSI zawierać sprzęt z certyfikatem zgodnym z profilem ochrony bezpiecznego układu IC (BSI-CC-PP-0084-2014) lub oceniony przez akredytowane w kraju laboratorium badawcze, które wdrożyło ocenę wysokiego potencjału ataku zgodnie z zasadą Common Metrics Performance of Attack Potential to Smartcard.
  • [C-1-11] MUSI zawierać oprogramowanie oceniane przez akredytowane w kraju laboratorium badawcze, korzystające z oceny pod kątem luk w zabezpieczeniach o wysokim potencjale ataku zgodnie z zasadami stosowania potencjału ataku na karty Smartcard według kryteriów Common Criteria.
  • [C-SR] Zdecydowanie ZALECANE jest dodanie sprzętu ocenianego za pomocą celu zabezpieczeń, Evaluation Assurance Level (EAL) 5 w wersji 5, rozszerzonego przez AVA_VAN.5. Certyfikat EAL 5 prawdopodobnie będzie wymagany w przyszłej wersji.

• [C-SR] Zdecydowanie ZALECANE jest zapewnienie odporności na atak typu „wewnętrzne” (IAR), co oznacza, że osoba wtajemniczona z dostępem do kluczy podpisywania oprogramowania nie może tworzyć oprogramowania, które powoduje wyciek obiektów tajnych przez StrongBox, ominięcie funkcjonalnych wymagań bezpieczeństwa lub w inny sposób umożliwia dostęp do poufnych danych użytkownika. Zalecanym sposobem implementacji IAR jest zezwolenie na aktualizacje oprogramowania tylko wtedy, gdy główne hasło użytkownika jest podane za pomocą interfejsu IAuthSecret HAL.

9.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 użytkowników. Oznacza to, że wszystkie dane oprócz tych:
  • Obraz systemu
  • wszystkie pliki systemu operacyjnego wymagane przez obraz systemu,
• [C-0-3] MUSI usuwać dane w sposób zgodny z odpowiednimi standardami branżowymi, takimi jak NIST SP800-88.
• [C-0-4] MUSI aktywować powyższy proces „przywracania danych fabrycznych” po wywołaniu interfejsu API DevicePolicyManager.wipeData() przez aplikację kontrolera zasad dotyczących urządzeń głównego użytkownika.
• MOŻE udostępnić opcję szybkiego czyszczenia danych, która przeprowadza tylko logiczne usuwanie danych.

9.13. Tryb bezpiecznego rozruchu

Android zapewnia tryb bezpiecznego rozruchu, który umożliwia użytkownikom uruchamianie urządzenia w trybie, w którym mogą działać tylko wstępnie zainstalowane aplikacje systemowe, a wszystkie aplikacje innych firm są wyłączone. Ten tryb, nazywany „trybem bezpiecznego rozruchu”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.

Implementacje urządzeń:

• [SR] Zdecydowanie ZALECANE jest wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacje urządzeń mają włączony tryb bezpiecznego rozruchu:

• [C-1-1] MUSI umożliwiać użytkownikowi przejście w tryb bezpiecznego rozruchu w sposób uniemożliwiający jego przerwanie w aplikacjach innych firm zainstalowanych na urządzeniu, chyba że aplikacja innej firmy jest kontrolerem zasad dotyczących urządzeń i ma ustawioną flagę UserManager.DISALLOW_SAFE_BOOT na wartość true (prawda).

• [C-1-2] MUSI umożliwiać użytkownikowi odinstalowanie aplikacji innych firm w trybie awaryjnym.

• Trzeba udostępnić użytkownikowi opcję włączenia trybu bezpiecznego rozruchu z menu rozruchu przy użyciu przepływu pracy innego niż zwykły rozruch.

9.14. Izolacja systemu samochodowego

Oczekuje się, że urządzenia z Androidem Automotive będą wymieniać dane z najważniejszymi podsystemami w pojeździe, wykorzystując interfejs HAL pojazdu do wysyłania i odbierania wiadomości w sieciach pojazdu, takich jak magistrala CAN.

Wymianę danych można zabezpieczyć, implementując funkcje zabezpieczeń poniżej warstw platformy Android, zapobiegając złośliwej lub niezamierzonej interakcji z tymi podsystemami.

9.15. Abonamenty

„Abonamenty” odnoszą się do szczegółów abonamentu oferowanych przez operatora komórkowego na stronie SubscriptionManager.setSubscriptionPlans().

Wszystkie implementacje na urządzeniach:

• [C-0-1] TRZEBA zwracać abonamentów tylko do aplikacji operatora komórkowego, która je udostępniła.
• [C-0-2] NIE MOŻESZ zdalnie przesyłać ani tworzyć kopii zapasowych abonamentów.
• [C-0-3] MUSI zezwalać na zastąpienia takie jak SubscriptionManager.setSubscriptionOverrideCongested() tylko w aplikacji operatora komórkowego, która obecnie dostarcza ważne abonamenty.

10. Testowanie zgodności oprogramowania

Implementacje na urządzeniach MUSZĄ przejść wszystkie testy opisane w tej sekcji. Należy jednak pamiętać, że żaden pakiet testów oprogramowania nie jest w pełni wszechstronny. Z tego powodu Zdecydowanie ZALECANE jest wprowadzenie jak najmniejszej liczby zmian w plikach referencyjnych i preferowanej implementacji Androida dostępnej w ramach projektu Android Open Source Project. Zminimalizuje to ryzyko wprowadzenia błędów, które powodują niezgodności, które wymagają przerobienia i potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje na urządzeniach:

• [C-0-1] MUSI przejść pakiet Android Compatibility Test Suite (CTS) dostępny w projekcie Android Open Source Project, korzystając z oprogramowania dostawy zainstalowanego na urządzeniu.

• [C-0-2] MUSI zapewniać zgodność w przypadku niejasności w CTS lub w przypadku wszelkich zmian implementacji części referencyjnego kodu źródłowego.

Narzędzie CTS zostało zaprojektowane tak, aby działać na prawdziwym urządzeniu. Podobnie jak w przypadku każdego oprogramowania, narzędzie CTS może zawierać błędy. Pakiet CTS będzie prowadzony niezależnie od tej definicji zgodności, a dla Androida 9 może zostać wydanych kilka wersji.

Implementacje na urządzeniach:

• [C-0-3] MUSI przejść najnowszą wersję CTS dostępną w chwili zakończenia działania oprogramowania urządzenia.

• NALEŻY w miarę możliwości korzystać z implementacji referencyjnej w drzewie Android Open Source.

10.2. Weryfikator CTS

CTS Verifier wchodzi w skład pakietu Compatibility Test Suite i może być uruchamiany przez człowieka w celu testowania funkcji, których zautomatyzowany system nie może przetestować, na przykład prawidłowego działania kamery i czujników.

Implementacje na urządzeniach:

• [C-0-1] MUSI prawidłowo wykonać wszystkie odpowiednie zgłoszenia weryfikatora CTS.

Weryfikator CTS wykonuje testy obejmujące różne rodzaje sprzętu, w tym sprzęt opcjonalny.

Implementacje na urządzeniach:

• [C-0-2] MUSI przejść wszystkie testy posiadanego sprzętu. Na przykład jeśli urządzenie ma akcelerometr, MUSI prawidłowo wykonać test akcelerometru w weryfikatorze CTS.

Przypadki testowe funkcji oznaczonych w tym dokumencie definicji zgodności jako opcjonalne MOGĄ zostać pominięte lub pominięte.

• [C-0-2] Na każdym urządzeniu i każdej kompilacji MUSI działać weryfikator CTS zgodnie z opisem powyżej. Ponieważ jednak wiele kompilacji jest bardzo podobnych, narzędzia implementujące na urządzeniach nie powinny jawnie uruchamiać weryfikatora CTS w kompilacjach, które różnią się tylko w prosty sposób. Chodzi w szczególności o implementacje na urządzeniach, które różnią się od tych, które przeszły weryfikację przez weryfikatora CTS tylko przez zestaw uwzględnionych języków, oznaczenia marki itp. MOGĄ pominąć test weryfikatora CTS.

11. Oprogramowanie do aktualizacji

• [C-0-1] Implementacje na urządzeniu MUSZĄ zawierać mechanizm zastępujący całe oprogramowanie systemowe. Mechanizm nie musi przeprowadzać uaktualnień w czasie rzeczywistym – tzn. może być wymagane ponowne uruchomienie urządzenia. Można użyć dowolnej metody, pod warunkiem że może ona zastąpić całe oprogramowanie zainstalowane fabrycznie na urządzeniu. To wymaganie może zostać spełnione na przykład przez:

  • Pobieranie typu „bezprzewodowe (OTA)” z aktualizacją offline po ponownym uruchomieniu.
  • Opcja „w tetheringu” jest aktualizowana przez USB z komputera hosta.
  • „Tryb offline” aktualizuje się po ponownym uruchomieniu i aktualizacji z pliku w pamięci wymiennej.

• [C-0-2] Użyty mechanizm aktualizacji MUSI obsługiwać aktualizacje bez czyszczenia danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachować prywatne dane aplikacji i dane udostępnione przez aplikację. Pamiętaj, że wcześniejsze oprogramowanie Android ma mechanizm aktualizacji, który spełnia to wymaganie.

Jeśli implementacja urządzenia obejmuje obsługę połączenia danych bez pomiaru użycia danych, np. profilu 802.11 lub profilu Bluetooth z numerem PAN (sieć osobista), to:

• [C-1-1] MUSI obsługiwać pobieranie OTA z aktualizacją offline po ponownym uruchomieniu.

W przypadku implementacji na urządzeniach z Androidem 6.0 i nowszym mechanizm aktualizacji POWINIEN obsługiwać sprawdzanie, czy obraz systemu jest binarnie identyczny z oczekiwanym wynikiem po aktualizacji OTA. To wymaganie spełnia oparta na blokowych implementacja OTA w źródłowym projekcie Android Open Source, dodana od Androida 5.1.

Implementacje na urządzeniach MUSZĄ też obsługiwać aktualizacje systemu A/B. AOSP implementuje tę funkcję przy użyciu interfejsu HAL kontroli rozruchu.

Jeśli w implementacji urządzenia po jej opublikowaniu, ale w rozsądnym okresie przydatności usługi, co zostanie określone po konsultacji z zespołem ds. zgodności na Androidzie w celu ograniczenia zgodności aplikacji innych firm, wykonaj te czynności:

• [C-2-1] Implementator urządzenia MUSI poprawić błąd, korzystając z dostępnej aktualizacji oprogramowania, którą można zastosować zgodnie z opisanym mechanizmem.

Android zawiera funkcje, które umożliwiają aplikacji Właściciel urządzenia (jeśli jest zainstalowana) na kontrolowanie instalowania aktualizacji systemu. Jeśli podsystem aktualizacji systemu dla urządzeń zgłasza android.software.device_admin, to:

• [C-3-1] MUSI zaimplementować działanie opisane w klasie SystemUpdatePolicy.

12. Historia zmian dokumentu

Podsumowanie zmian w definicji zgodności w tej wersji:

• Historia zmian dokumentu

Aby zobaczyć podsumowanie zmian w sekcjach dotyczących poszczególnych osób:

1. Wprowadzenie
2. Typy urządzeń
3. Oprogramowanie
4. Pakiety aplikacji
5. Multimedia
6. Narzędzia i opcje dla programistów
7. Zgodność sprzętu
8. Wydajność i moc
9. Model zabezpieczeń
10. Testowanie zgodności oprogramowania
11. Oprogramowanie, które można zaktualizować
12. Historia zmian dokumentu
13. Skontaktuj się z nami

12.1 Wskazówki dotyczące wyświetlania historii zmian

Zmiany są oznaczane w ten sposób:

• CDD
  Istotne zmiany w wymaganiach dotyczących zgodności.

• Dokumenty
  Zmiany kosmetyczne lub związane z tworzeniem.

Aby to zrobić, dołącz do adresów URL dziennika zmian parametry adresu URL pretty=full i no-merges.

13. Skontaktuj się z nami

Możesz dołączyć do forum dotyczącego zgodności z Androidem i poprosić o wyjaśnienia lub zgłosić problemy, które Twoim zdaniem nie obejmują dokumentu.