Definicja zgodności z Androidem 9

1. Wprowadzenie

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

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

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

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

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

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

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

1.1 Struktura dokumentu

1.1.1. Wymagania według typu urządzenia

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

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

1.1.2. Identyfikator wymagania

Identyfikator wymagania jest przypisywany do wymagań MUST.

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

Każdy identyfikator jest zdefiniowany w ten sposób:

  • Identyfikator typu urządzenia (więcej informacji znajdziesz w sekcji 2. Typy urządzeń)
    • C: podstawowe (wymagania, które mają zastosowanie do wszystkich implementacji urządzeń z Androidem);
    • H: urządzenie przenośne z Androidem
    • T: urządzenie z Androidem TV
    • A: Wdrożenie Androida Automotive
    • Karta: wdrożenie na tablecie z Androidem
  • Identyfikator warunku
    • Jeśli wymaganie jest bezwarunkowe, ten identyfikator ma wartość 0.
    • Jeśli wymaganie jest warunkowe, przypisujemy mu wartość 1 w przypadku pierwszego warunku, a w ramach tej samej sekcji i tego samego typu urządzenia zwiększamy tę wartość o 1.
  • Identyfikator wymagania
    • Identyfikator zaczyna się od 1 i zwiększa się o 1 w ramach tej samej sekcji i tego samego warunku.

1.1.3. Identyfikator wymagania w sekcji 2

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

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

2. Typy urządzeń

Projekt Android Open Source udostępnia stos oprogramowania, który można wykorzystywać na różnych typach urządzeń i w różnych formach, ale w przypadku niektórych typów urządzeń ekosystem dystrybucji aplikacji jest lepiej rozwinięty.

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

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

2.1 Konfiguracje urządzeń

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

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

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

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

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

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

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

2.2.1. Sprzęt

Implementacje na urządzeniach przenośnych:

  • [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 zaleca się udostępnienie użytkownikom możliwości zmiany rozmiaru wyświetlania (gęstości ekranu).

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

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

Implementacje na urządzeniach przenośnych:

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

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

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

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

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

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

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

Implementacje na urządzeniach przenośnych:

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

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

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

Implementacje na urządzeniach przenośnych:

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

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

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

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

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

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

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

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

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

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

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

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

Jeśli urządzenia przenośne mają nie więcej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

  • [7.6.1/H-9-1] MUSI zadeklarować flagę funkcji android.hardware.ram.low.
  • [7.6.1/H-9-2] MUSI mieć co najmniej 1,1 GB pamięci trwałej na prywatne dane aplikacji (czyli partycję „/data”).

Jeśli urządzenia przenośne mają więcej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika:

  • [7.6.1/H-10-1] MUSI mieć co najmniej 4 GB pamięci trwałej dostępnej na prywatne dane aplikacji (czyli partycję „/data”).
  • POWINIEN zadeklarować flagę funkcji android.hardware.ram.normal.

Implementacje na urządzeniach przenośnych:

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

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

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

Implementacje na urządzeniach przenośnych:

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

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

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

2.2.2. Multimedia

Urządzenia przenośne 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 MPEG-4 AAC (AAC LC)
  • [5.1.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
  • [5.1.1/H-0-5] AAC ELD (enhanced low delay AAC)

Urządzenia przenośne MUSZĄ obsługiwać dekodowanie dźwięku w tych formatach:

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

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

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

Urządzenia przenośne MUSZĄ obsługiwać dekodowanie wideo w tych formatach:

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

2.2.3. Oprogramowanie

Implementacje na urządzeniach przenośnych:

  • [3.2.3.1/H-0-1] MUSI mieć aplikację, która obsługuje intencje ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE i ACTION_CREATE_DOCUMENT zgodnie z opisem w dokumentach pakietu SDK oraz zapewnia użytkownikowi możliwość dostępu do danych dostawcy dokumentów za pomocą interfejsu DocumentsProvider API.
  • [3.4.1/H-0-1] MUSI udostępniać pełną implementację interfejsu android.webkit.Webview API.
  • [3.4.2/H-0-1] MUSI zawierać samodzielną aplikację przeglądarki do ogólnego przeglądania internetu przez użytkowników.
  • [3.8.1/H-SR] Zdecydowanie zaleca się wdrożenie domyślnego programu uruchamiającego, który obsługuje przypinanie w aplikacji skrótów, widżetów i widgetFeatures.
  • [3.8.1/H-SR] ZDECYDOWANIE ZALECA się wdrożenie domyślnego programu uruchamiającego, który zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu ShortcutManager API.
  • [3.8.1/H-SR] Zdecydowanie zaleca się, aby zawierały domyślną aplikację uruchamiającą, która wyświetla plakietki na ikonach aplikacji.
  • [3.8.2/H-SR] Zdecydowanie zalecane jest obsługiwanie widżetów aplikacji innych firm.
  • [3.8.3/H-0-1] MUSI zezwalać aplikacjom innych firm na powiadamianie użytkowników o ważnych wydarzeniach za pomocą klas interfejsu API Notification i NotificationManager.
  • [3.8.3/H-0-2] MUSI obsługiwać powiadomienia z elementami rozszerzonymi.
  • [3.8.3/H-0-3] MUSI obsługiwać powiadomienia w formie wyskakujących okienek.
  • [3.8.3/H-0-4] MUSI zawierać panel powiadomień, który umożliwia użytkownikowi bezpośrednie sterowanie powiadomieniami (np. odpowiadanie na nie, odkładanie ich, zamykanie i blokowanie) za pomocą elementów interfejsu, takich jak przyciski działań lub panel sterowania zaimplementowany w AOSP.
  • [3.8.3/H-0-5] MUSI wyświetlać w obszarze powiadomień opcje podane w RemoteInput.Builder setChoices().
  • [3.8.3/H-SR] Zdecydowanie zaleca się wyświetlanie pierwszego wyboru udostępnionego przez RemoteInput.Builder setChoices() w obszarze powiadomień bez dodatkowej interakcji ze strony użytkownika.
  • [3.8.3/H-SR] ZDECYDOWANIE ZALECA SIĘ wyświetlanie wszystkich opcji podanych w RemoteInput.Builder setChoices() w obszarze powiadomień, gdy użytkownik rozwinie wszystkie powiadomienia w tym obszarze.
  • [3.8.4/H-SR] Zdecydowanie zalecamy wdrożenie na urządzeniu asystenta, który będzie obsługiwać działanie Assist.

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

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

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

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

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

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

Implementacje na urządzeniach przenośnych:

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

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

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

2.2.4. Wydajność i moc

  • [8.1/H-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie klatek lub opóźnienie renderowania klatek NIE MOŻE występować częściej niż 5 klatek na sekundę i POWINNO być mniejsze niż 1 klatka na sekundę.
  • [8.1/H-0-2] Opóźnienie interfejsu. Implementacje urządzeń MUSZĄ zapewniać użytkownikom małe opóźnienia, przewijając listę 10 tys. pozycji zgodnie z definicją w pakiecie testów zgodności Androida (CTS) w czasie krótszym niż 36 sekund.
  • [8.1/H-0-3] Przełączanie zadań. Ponowne uruchomienie aplikacji, która jest już uruchomiona, musi trwać krócej niż 1 sekundę.

Implementacje na urządzeniach przenośnych:

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

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

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

Implementacje na urządzeniach przenośnych:

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

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

2.2.5. Model zabezpieczeń

Implementacje na urządzeniach przenośnych:

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

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

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

2.3. Wymagania dotyczące telewizora

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

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

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

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

2.3.1. Sprzęt

Implementacje na urządzeniach telewizyjnych:

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

Jeśli urządzenia telewizyjne mają żyroskop:

  • [7.3.4/T-1-1] MUSI mieć możliwość raportowania zdarzeń 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 pamięci trwałej dostępnej na prywatne dane aplikacji (czyli partycję „/data”).

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

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

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

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

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

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

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

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

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

Implementacje na urządzeniach telewizyjnych:

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

2.3.2. Multimedia

Implementacje urządzeń telewizyjnych MUSZĄ obsługiwać te formaty kodowania dźwięku:

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

Urządzenia telewizyjne MUSZĄ obsługiwać te formaty kodowania wideo:

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

Implementacje na urządzeniach telewizyjnych:

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

Urządzenia telewizyjne MUSZĄ obsługiwać te formaty dekodowania wideo:

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

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

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

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

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

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

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

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

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

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

  • [5.3.7.4/T-1-1] HD 1080p przy 60 kl./s z profilem 0 (8-bitowa głębia kolorów)

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

  • [5.3.7.5/T-2-1] MUSI obsługiwać profil dekodowania UHD przy 60 klatkach na sekundę z profilem 0 (8-bitowa głębia kolorów).
  • [5.3.7.5/T-2-1] ZDECYDOWANIE ZALECA się obsługę profilu dekodowania UHD przy 60 klatkach na sekundę z profilem 2 (10-bitowa głębia kolorów).

Implementacje na urządzeniach telewizyjnych:

  • [5.5.3/T-0-1] MUSI obsługiwać systemową głośność główną i tłumienie głośności cyfrowego wyjścia audio na obsługiwanych wyjściach, z wyjątkiem wyjścia przekazywania skompresowanego dźwięku (w przypadku którego urządzenie nie dekoduje 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 z częstotliwością odświeżania 50 Hz lub 60 Hz w przypadku wszystkich wyświetlaczy przewodowych.
  • [5.8/T-SR] Zdecydowanie zaleca się udostępnienie użytkownikowi możliwości wyboru częstotliwości odświeżania HDMI dla wszystkich wyświetlaczy przewodowych.
  • [5.8/T-SR] Zdecydowanie zaleca się obsługę jednoczesnego dekodowania bezpiecznych strumieni. ZDECYDOWANIE ZALECA się jednoczesne dekodowanie co najmniej 2 strumieni.
  • [5.8] POWINNO ustawiać częstotliwość odświeżania trybu wyjścia HDMI na 50 Hz lub 60 Hz w zależności od częstotliwości odświeżania wideo w regionie, w którym urządzenie jest sprzedawane, w przypadku wszystkich wyświetlaczy przewodowych.

Jeśli urządzenia telewizyjne obsługują dekodowanie UHD i wyświetlacze zewnętrzne:

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

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

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

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

Implementacje na urządzeniach telewizyjnych:

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

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

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

Implementacje na urządzeniach telewizyjnych:

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

2.3.4. Wydajność i moc

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

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

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

Implementacje na urządzeniach telewizyjnych:

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

2.4. Wymagania dotyczące zegarka

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

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

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

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

2.4.1. Sprzęt

Implementacje urządzeń z Androidem:

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

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

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

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

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

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

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

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

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

2.4.2. Multimedia

Brak dodatkowych wymagań.

2.4.3. Oprogramowanie

Implementacje urządzeń z Androidem:

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

Implementacje urządzeń z Androidem:

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

Obserwuj wdrożenia na urządzeniach, które deklarują flagę funkcji android.hardware.audio.output:

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

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

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

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

2.4.4. Wydajność i moc

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

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

Implementacje urządzeń z Androidem:

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

2.5. Wymagania dotyczące motoryzacji

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

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

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

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

2.5.1. Sprzęt

Implementacje na urządzeniach samochodowych:

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

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

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

  • [7.2.3/A-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno normalne, jak i długie naciśnięcie funkcji Wstecz (KEYCODE_BACK).

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

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

Jeśli urządzenia samochodowe mają żyroskop:

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

Implementacje na urządzeniach samochodowych:

  • [7.3.11/A-0-1] MUSI podawać aktualny bieg jako SENSOR_TYPE_GEAR.

Implementacje na urządzeniach samochodowych:

  • [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 desce rozdzielczej i POWINNA być oparta na danych z czujnika światła otoczenia.

  • Czujnik światła otoczenia MOŻE być taki sam jak fotometr.

  • [7.3.11.4/A-0-1] MUSI podawać prędkość pojazdu zgodnie z definicją w SENSOR_TYPE_CAR_SPEED.

  • [7.3.11.5/A-0-1] MUSI podawać stan hamulca postojowego zgodnie z definicją w 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 Androida Automotive MUSZĄ obsługiwać te profile Bluetooth:
    • Połączenia telefoniczne przez profil zestawu głośnomówiącego (HFP).
    • odtwarzanie multimediów za pomocą profilu dystrybucji audio (A2DP);
    • sterowanie odtwarzaniem multimediów za pomocą profilu zdalnego sterowania (AVRCP);
    • Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).

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

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

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

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

Implementacje na urządzeniach samochodowych:

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

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

  • [7.6.1/A-SR] Zdecydowanie zaleca się zmniejszenie obciążenia operacji wejścia/wyjścia wykonywanych na pamięci zewnętrznej, np. przez użycie SDCardFS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementacje na urządzeniach samochodowych:

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

Implementacje na urządzeniach samochodowych:

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

Implementacje na urządzeniach samochodowych:

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

2.5.2. Multimedia

Implementacje urządzeń samochodowych MUSZĄ obsługiwać to kodowanie audio:

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

Implementacje urządzeń samochodowych MUSZĄ obsługiwać to kodowanie wideo:

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

Urządzenia samochodowe MUSZĄ obsługiwać dekodowanie wideo w tych formatach:

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

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

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

2.5.3. Oprogramowanie

Implementacje na urządzeniach samochodowych:

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

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

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

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

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

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

  • [3.13/A-SR] Zdecydowanie zaleca się uwzględnienie komponentu interfejsu Szybkich ustawień.

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

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

Implementacje na urządzeniach samochodowych:

  • [3.14/A-0-1] MUSI zawierać platformę interfejsu, która obsługuje aplikacje innych firm korzystające z interfejsów API multimediów zgodnie z opisem w sekcji 3.14.

2.5.4. Wydajność i moc

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

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

Implementacje na urządzeniach samochodowych:

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

2.5.5. Model zabezpieczeń

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

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

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

Implementacje na urządzeniach samochodowych:

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

2.6. Wymagania dotyczące tabletów

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

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

Wymagania dotyczące implementacji na tabletach są podobne do wymagań dotyczących implementacji na urządzeniach przenośnych. Wyjątki są oznaczone symbolem * w odpowiedniej sekcji i wskazane w tej sekcji.

2.4.1. Sprzęt

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 (sekcja 7.6.1)

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

Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)

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

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

Tryb wirtualnej rzeczywistości (sekcja 7.9.1)

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

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

3. Oprogramowanie

3.1. Zgodność zarządzanego interfejsu API

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

Implementacje na urządzeniach:

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

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

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

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

  • [C-0-5] MUSI ograniczać używanie przez aplikacje innych firm ukrytych interfejsów API, zdefiniowanych jako interfejsy API w przestrzeni nazw Androida oznaczone adnotacją @hidden, ale nie adnotacją @SystemAPI ani @TestApi, zgodnie z opisem w dokumentach pakietu SDK, i dostarczać każdy ukryty interfejs API na tych samych listach ograniczonych, które są udostępniane w plikach listy tymczasowej i listy zablokowanych w ścieżce prebuilts/runtime/appcompat/ dla odpowiedniej gałęzi poziomu interfejsu API w AOSP. Jednak:

    • Mogą one przenieść ukryty interfejs API na listę zablokowanych lub pominąć go na wszystkich listach ograniczonych, jeśli jest on niedostępny lub zaimplementowany w inny sposób na urządzeniu.
    • MAJ, jeśli ukryty interfejs API nie istnieje jeszcze w AOSP, dodaj go do dowolnej listy ograniczeń.
    • MOŻE wdrożyć mechanizm dynamicznej aktualizacji, który przenosi ukryty interfejs API z listy ograniczonej na listę mniej ograniczoną, z wyjątkiem listy dozwolonych.

3.1.1. Rozszerzenia Androida

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

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

3.1.2. Biblioteka Androida

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

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

Implementacja AOSP spełnia te wymagania.

3.2. Zgodność interfejsu API

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

3.2.1. Uprawnienia

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

3.2.2. Parametry kompilacji

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

  • [C-0-1] Aby zapewnić spójne i znaczące wartości w różnych implementacjach urządzeń, tabela poniżej zawiera dodatkowe ograniczenia dotyczące formatów tych wartości, do których implementacje urządzeń MUSZĄ być zgodne.
Parametr Szczegóły
VERSION.RELEASE Wersja aktualnie działającego systemu Android w formacie czytelnym dla człowieka. To pole MUSI mieć jedną z wartości ciągu znaków zdefiniowanych w sekcji 9.
VERSION.SDK Wersja aktualnie działającego 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 aktualnie działającego 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.INCREMENTAL Wartość wybrana przez producenta urządzenia, która określa konkretną kompilację aktualnie działającego systemu Android w formacie czytelnym dla człowieka. Tej wartości NIE WOLNO używać ponownie w przypadku różnych kompilacji udostępnianych użytkownikom. Typowym zastosowaniem tego pola jest wskazanie, który numer kompilacji lub identyfikator zmiany w systemie kontroli wersji został użyty do wygenerowania kompilacji. Nie ma wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
PLANSZOWE Wartość wybrana przez producenta urządzenia, która identyfikuje konkretny sprzęt wewnętrzny używany przez urządzenie w formacie czytelnym dla człowieka. Można go użyć do wskazania konkretnej wersji płyty zasilającej urządzenie. Wartość tego pola MUSI być kodowana jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”.
BRAND Wartość odzwierciedlająca nazwę marki powiązaną z urządzeniem, znaną użytkownikom. MUSI być w formacie czytelnym dla człowieka i POWINNA reprezentować producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być kodowana jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_32_BIT_ABIS Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_64_BIT_ABIS Nazwa drugiego zestawu 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 zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
URZĄDZENIE Wartość wybrana przez producenta urządzenia, która zawiera nazwę programistyczną lub kodową identyfikującą konfigurację funkcji sprzętowych i wzornictwo przemysłowe urządzenia. Wartość tego pola MUSI być kodowana jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Nazwa urządzenia NIE MOŻE się zmieniać przez cały okres użytkowania produktu.
FINGERPRINT Ciąg znaków, który jednoznacznie identyfikuje tę kompilację. POWINIEN być w miarę czytelny dla człowieka. Musi być zgodny 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 palca NIE MOŻE zawierać znaków odstępu. Jeśli inne pola uwzględnione w szablonie powyżej zawierają znaki odstępu, MUSZĄ one zostać zastąpione w odcisku palca kompilacji innym znakiem, np. podkreśleniem („_”). Wartość tego pola MUSI być kodowana jako 7-bitowy ASCII.

SPRZĘT Nazwa sprzętu (z wiersza poleceń jądra lub z pliku /proc). POWINIEN być w miarę czytelny dla człowieka. Wartość tego pola MUSI być kodowana jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”.
GOSPODARZ Ciąg znaków, który w formacie zrozumiałym dla człowieka jednoznacznie identyfikuje hosta, na którym utworzono kompilację. Nie ma wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
ID Identyfikator wybrany przez producenta urządzenia, który odnosi się do konkretnej wersji i jest czytelny dla człowieka. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINNO mieć wartość wystarczająco znaczącą, aby użytkownicy mogli odróżnić kompilacje oprogramowania. Wartość tego pola MUSI być kodowana jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9._-]+$”.
PRODUCENT Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono być wartością null ani pustym ciągiem znaków („”). To pole NIE MOŻE się zmieniać w okresie istnienia produktu.
MODEL Wartość wybrana przez producenta urządzenia, która zawiera nazwę urządzenia znaną użytkownikowi. Powinna to być ta sama nazwa, pod którą urządzenie jest sprzedawane użytkownikom. Nie ma wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono być wartością null ani pustym ciągiem znaków („”). To pole NIE MOŻE się zmieniać w okresie istnienia produktu.
USŁUGA Wartość wybrana przez producenta urządzenia, która zawiera nazwę deweloperską lub kodową konkretnego produktu (SKU) i musi być unikalna w ramach tej samej marki. MUSI być czytelny dla człowieka, ale niekoniecznie jest przeznaczony do wyświetlania użytkownikom. Wartość tego pola MUSI być kodowana jako 7-bitowy ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Nazwa produktu NIE MOŻE się zmieniać w okresie jego istnienia.
SERIAL MUSI zwrócić wartość „UNKNOWN”.
TAGI Lista tagów rozdzielonych przecinkami wybranych przez producenta urządzenia, które dodatkowo odróżniają kompilację. To pole MUSI mieć jedną z wartości odpowiadających 3 typowym konfiguracjom podpisywania na platformie Android: release-keys, dev-keys, test-keys.
CZAS Wartość reprezentująca sygnaturę czasową, kiedy nastąpiła kompilacja.
TYP Wartość wybrana przez producenta urządzenia, która określa konfigurację kompilacji w czasie działania. 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, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
SECURITY_PATCH Wartość wskazująca poziom aktualizacji zabezpieczeń kompilacji. MUSI to oznaczać, że kompilacja nie jest w żaden sposób podatna na żadne problemy opisane w odpowiednim publicznym Biuletynie bezpieczeństwa Androida. Musi być w formacie [RRRR-MM-DD] i odpowiadać zdefiniowanemu ciągowi znaków udokumentowanemu w publicznym Biuletynie bezpieczeństwa Androida lub w poradniku dotyczącym bezpieczeństwa Androida, np. „2015-11-01”.
BASE_OS Wartość reprezentująca parametr FINGERPRINT kompilacji, która jest identyczna z tą kompilacją, z wyjątkiem poprawek podanych w publicznym biuletynie bezpieczeństwa Androida. Musi podawać prawidłową wartość, a jeśli taka kompilacja nie istnieje, musi podawać pusty ciąg znaków ("").
BOOTLOADER Wartość wybrana przez producenta urządzenia, która identyfikuje konkretną wewnętrzną wersję programu rozruchowego używaną na urządzeniu, w formacie czytelnym dla człowieka. Wartość tego pola MUSI być kodowana jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9._-]+$”.
getRadioVersion() MUSI (być lub zwracać) wartość wybraną przez producenta urządzenia, która identyfikuje konkretną wewnętrzną wersję radia/modemu używaną w urządzeniu, w formacie czytelnym dla człowieka. Jeśli urządzenie nie ma wewnętrznego radia lub modemu, MUSI zwrócić wartość NULL. Wartość tego pola MUSI być kodowana jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9._-,]+$”.
getSerial() MUSI być (lub zwracać) numer seryjny sprzętu, który MUSI być dostępny i niepowtarzalny na urządzeniach tego samego MODELU i PRODUCENTA. Wartość tego pola MUSI być kodowana jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9._-,]+$”.

3.2.3. Zgodność z intencją

3.2.3.1. Intencje aplikacji podstawowych

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

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

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

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

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

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

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

Android zawiera też mechanizm, który umożliwia aplikacjom innych firm deklarowanie autorytatywnego domyślnego zachowania linków do aplikacji w przypadku niektórych typów intencji URI w internecie. Jeśli takie deklaracje autorytatywne są zdefiniowane we wzorcach filtrów intencji aplikacji, implementacje urządzeń:

  • [C-0-4] MUSI próbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji protokołu Digital Asset Links, które są zaimplementowane przez Menedżera pakietów w projekcie Android Open Source Project.
  • [C-0-5] MUSI próbować zweryfikować filtry intencji podczas instalacji aplikacji i ustawić wszystkie pomyślnie zweryfikowane filtry intencji URI jako domyślne programy obsługi URI.
  • MOGĄ ustawić konkretne filtry intencji URI jako domyślne programy obsługi identyfikatorów URI, jeśli zostaną one zweryfikowane, ale inne filtry URI nie przejdą weryfikacji. Jeśli implementacja urządzenia to robi, MUSI udostępniać użytkownikowi odpowiednie zastąpienia wzorców dla poszczególnych adresów URI w menu ustawień.
  • MUSI udostępniać użytkownikowi w Ustawieniach elementy sterujące linkami do aplikacji dla poszczególnych aplikacji w ten sposób:
    • [C-0-6] Użytkownik MUSI mieć możliwość globalnego zastąpienia domyślnego działania linków do aplikacji, aby aplikacja zawsze się otwierała, zawsze pytała lub nigdy się nie otwierała. Musi to dotyczyć wszystkich filtrów intencji URI.
    • [C-0-7] Użytkownik MUSI mieć możliwość wyświetlenia listy filtrów intencji URI kandydata.
    • Implementacja urządzenia MOŻE umożliwiać użytkownikowi zastępowanie poszczególnych filtrów intencji kandydatów URI, które zostały pomyślnie zweryfikowane.
    • [C-0-8] Implementacja urządzenia MUSI umożliwiać użytkownikom wyświetlanie i zastępowanie konkretnych filtrów intencji URI kandydatów, jeśli implementacja urządzenia pozwala na pomyślne przejście weryfikacji przez niektóre filtry intencji URI kandydatów, a inne mogą nie przejść weryfikacji.
3.2.3.3. Przestrzenie nazw zamiarów
  • [C-0-1] Implementacje urządzeń NIE MOGĄ zawierać żadnego komponentu Androida, który obsługuje nowe intencje lub wzorce intencji rozgłoszeniowych przy użyciu ACTION, CATEGORY lub innego kluczowego ciągu znaków w przestrzeni nazw android. lub com.android..
  • [C-0-2] Producenci urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub intencji rozgłoszeniowych przy użyciu ACTION, CATEGORY lub innego kluczowego ciągu znaków w przestrzeni pakietu należącej do innej organizacji.
  • [C-0-3] Producenci urządzeń NIE MOGĄ zmieniać ani rozszerzać żadnych wzorców intencji używanych przez aplikacje podstawowe wymienione w sekcji 3.2.3.1.
  • Implementacje urządzeń MOGĄ zawierać wzorce intencji korzystające z przestrzeni nazw wyraźnie i oczywiście powiązanych z ich własną organizacją. Ten zakaz jest analogiczny do zakazu określonego w sekcji 3.6 w przypadku klas języka Java.
3.2.3.4. Zamiary związane z transmisją

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

Implementacje na urządzeniach:

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

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

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

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

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

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

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

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

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

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

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

3.2.4. Aktywności na dodatkowych ekranach

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych aktywności Androida na dodatkowych wyświetlaczach:

  • [C-1-1] MUSI ustawić flagę funkcji android.software.activities_on_secondary_displays.
  • [C-1-2] MUSI gwarantować zgodność interfejsu API podobną do zgodności działania na wyświetlaczu głównym.
  • [C-1-3] MUSI uruchamiać nową aktywność na tym samym wyświetlaczu co aktywność, która ją uruchomiła, gdy nowa aktywność jest uruchamiana bez określania wyświetlacza docelowego za pomocą interfejsu ActivityOptions.setLaunchDisplayId() API.
  • [C-1-4] MUSI usuwać wszystkie działania, gdy ekran z flagą Display.FLAG_PRIVATE zostanie usunięty.
  • [C-1-5] MUSI odpowiednio zmieniać rozmiar wszystkich działań na VirtualDisplay, jeśli sam wyświetlacz zostanie zmieniony.
  • MOŻE wyświetlać edytor IME (edytor metody wprowadzania, element sterujący, który umożliwia użytkownikom wpisywanie tekstu) na wyświetlaczu głównym, gdy pole wprowadzania tekstu zostanie aktywowane na wyświetlaczu dodatkowym.
  • W przypadku obsługi dotyku lub klawiatury POWINNA implementować fokus wejściowy na wyświetlaczu dodatkowym niezależnie od wyświetlacza głównego.
  • POWINIEN mieć android.content.res.Configuration odpowiadający temu wyświetlaczowi, aby wyświetlać treści, działać prawidłowo i zachować zgodność, jeśli aktywność zostanie uruchomiona na wyświetlaczu dodatkowym.

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych aktywności Androida na dodatkowych wyświetlaczach, a wyświetlacze podstawowy i dodatkowy mają różne wartości android.util.DisplayMetrics:

  • [C-2-1] Aplikacje i aktywności, których rozmiaru nie można zmieniać (które mają wartość resizeableActivity=false w AndroidManifest.xml) i które są kierowane na interfejs API na poziomie 23 lub niższym, NIE MOGĄ być dozwolone na wyświetlaczach dodatkowych.

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

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

3.3. Zgodność z natywnym interfejsem API

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

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

3.3.1. Interfejsy binarne aplikacji

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

Implementacje na urządzeniach:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4. Zgodność z internetem

3.4.1. Zgodność z WebView

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

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

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

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

    • Wartość ciągu $(VERSION) MUSI być taka sama jak wartość android.os.Build.VERSION.RELEASE.
    • Ciąg $(MODEL) MOŻE być pusty, ale jeśli nie jest pusty, MUSI mieć taką samą wartość jak android.os.Build.MODEL.
    • „Build/$(BUILD)” MOŻE zostać pominięty, ale jeśli jest obecny, ciąg $(BUILD) MUSI być taki sam jak wartość android.os.Build.ID.
    • Wartość ciągu $(CHROMIUM_VER) MUSI być wersją Chromium w projekcie Android Open Source Project.
    • Implementacje urządzeń MOGĄ pomijać ciąg znaków klienta użytkownika „Mobile”.

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

3.4.2. Zgodność z przeglądarką

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

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

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

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

3.5. Zgodność behawioralna interfejsu API

Implementacje na urządzeniach:

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

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

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

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

3.5.1. Ograniczenie działania w tle

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

  • [C-SR] Zdecydowanie zalecamy udostępnienie użytkownikom możliwości wyświetlania listy aplikacji objętych ograniczeniami.
  • [C-1-2] MUSI umożliwiać użytkownikowi włączanie i wyłączanie ograniczeń w przypadku poszczególnych aplikacji.
  • [C-1-3] NIE WOLNO automatycznie stosować ograniczeń bez dowodu na nieprawidłowe działanie systemu, ale MOŻNA stosować ograniczenia w przypadku aplikacji po wykryciu nieprawidłowego działania systemu, takiego jak zablokowane wybudzenia, długo działające usługi i inne kryteria. Kryteria MOGĄ być określane przez producentów urządzeń, ale MUSZĄ być związane z wpływem aplikacji na stan systemu. Inne kryteria, które nie są bezpośrednio związane ze stanem systemu, takie jak brak popularności aplikacji na rynku, NIE MOGĄ być używane jako kryteria.
  • [C-1-4] NIE MOŻE automatycznie stosować ograniczeń dotyczących aplikacji, gdy użytkownik ręcznie wyłączył te ograniczenia, i MOŻE sugerować użytkownikowi zastosowanie ograniczeń dotyczących aplikacji.
  • [C-1-5] MUSI informować użytkowników, jeśli ograniczenia aplikacji są stosowane automatycznie.
  • [C-1-6] MUSI zwracać true w przypadku ActivityManager.isBackgroundRestricted(), gdy ograniczona aplikacja wywołuje ten interfejs API.
  • [C-1-7] NIE MOŻE ograniczać działania aplikacji na pierwszym planie, która jest wyraźnie używana przez użytkownika.
  • [C-1-8] MUSI zawiesić ograniczenia dotyczące aplikacji, która staje się aplikacją na pierwszym planie, gdy użytkownik wyraźnie zaczyna korzystać z aplikacji, która była wcześniej objęta ograniczeniami.

3.6. Przestrzenie nazw interfejsów API

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

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

Oznacza to, że:

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

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

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

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

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

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

Powyższe ograniczenia są zgodne ze standardowymi konwencjami nazewnictwa interfejsów API w języku programowania Java. Ta sekcja ma jedynie na celu wzmocnienie tych konwencji i uczynienie ich wiążącymi poprzez włączenie ich do tej definicji zgodności.

3.7. Zgodność środowiska wykonawczego

Implementacje na urządzeniach:

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

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

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

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

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

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

3.8. Zgodność interfejsu

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

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

Jeśli implementacje urządzeń umożliwiają aplikacjom innych firm zastąpienie ekranu głównego urządzenia:

  • [C-1-1] MUSI zadeklarować funkcję platformy android.software.home_screen.
  • [C-1-2] MUSI zwracać obiekt AdaptiveIconDrawable, gdy aplikacja innej firmy używa tagu <adaptive-icon> do udostępniania swojej ikony i wywoływane są metody PackageManager do pobierania ikon.

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

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

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

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

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

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

3.8.2. Widżety

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

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

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

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

3.8.3. Powiadomienia

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

3.8.3.1. Wyświetlanie powiadomień

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.5. Alerty i wyskakujące okienka

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

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

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

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

3.8.6. Motywy

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

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

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

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

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

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

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

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

3.8.7. Animowane tapety

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

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

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

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

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

3.8.8. Przełączanie aktywności

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

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

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

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

3.8.9. Zarządzanie danymi wejściowymi

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

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

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

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

3.8.10. Sterowanie multimediami z ekranu blokady

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

3.8.11. Wygaszacze ekranu (wcześniej Dreams)

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

3.8.12. Lokalizacja

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

3.8.13. Unicode i czcionka

Android obsługuje znaki emoji zdefiniowane w Unicode 10.0.

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

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

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

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

3.8.14. Wiele okien

Jeśli implementacje urządzeń umożliwiają wyświetlanie wielu aktywności jednocześnie:

  • [C-1-1] MUSI implementować tryby wielu okien zgodnie z zachowaniami aplikacji i interfejsami API opisanymi w dokumentacji pakietu Android SDK dotyczącej obsługi trybu wielu okien oraz spełniać te wymagania:
  • [C-1-2] Aplikacje mogą wskazywać, czy mogą działać w trybie wielu okien, w pliku AndroidManifest.xml. Mogą to zrobić wyraźnie, ustawiając atrybut android:resizeableActivity na wartość true, lub pośrednio, ustawiając wartość targetSdkVersion > 24. Aplikacji, które w pliku manifestu wyraźnie ustawiają ten atrybut na wartość false, NIE WOLNO uruchamiać w trybie wielu okien. Starsze aplikacje z wartością targetSdkVersion < 24, które nie ustawiły tego atrybutu android:resizeableActivity, MOGĄ być uruchamiane w trybie wielu okien, ale system MUSI wyświetlać ostrzeżenie, że aplikacja może nie działać w tym trybie zgodnie z oczekiwaniami.
  • [C-1-3] NIE MOŻE oferować trybu podzielonego ekranu ani trybu dowolnego, jeśli wysokość ekranu jest mniejsza niż 440 dp, a szerokość ekranu jest mniejsza niż 440 dp.
  • Urządzenia z ekranem o rozmiarze xlarge POWINNY obsługiwać tryb dowolny.

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

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

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

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

3.8.15. Wycięcie w ekranie

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

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

  • [C-1-1] Musi mieć wycięcia tylko na krótszych krawędziach urządzenia. Jeśli współczynnik proporcji urządzenia wynosi 1, 0 (1:1), NIE MOŻE ono mieć wycięć.
  • [C-1-2] NIE MOŻE mieć więcej niż jednego wycięcia na krawędź.
  • [C-1-3] MUSI uwzględniać flagi wycięcia na wyświetlaczu ustawione przez aplikację za pomocą interfejsu WindowManager.LayoutParams API zgodnie z opisem w pakiecie SDK.
  • [C-1-4] MUSI raportować prawidłowe wartości wszystkich danych dotyczących wycięć zdefiniowanych w interfejsie DisplayCutout API.

3.9. Administracja urządzeniem

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

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

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

3.9.1 Obsługa administracyjna urządzenia

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

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

  • [C-1-1] MUSI obsługiwać rejestrację klienta zasad dotyczących urządzeń (DPC) jako aplikacji właściciela urządzenia w sposób opisany poniżej:
  • [C-1-2] MUSI wymagać podjęcia określonego działania podczas procesu udostępniania, aby wyrazić zgodę na ustawienie aplikacji jako właściciela urządzenia. Zgoda może być wyrażona przez działanie użytkownika lub w sposób programowy podczas udostępniania, ale NIE MOŻE być zakodowana na stałe ani uniemożliwiać korzystania z innych aplikacji właściciela urządzenia.

Jeśli implementacje urządzeń deklarują android.software.device_admin, ale zawierają też zastrzeżone rozwiązanie do zarządzania właścicielem urządzenia i zapewniają mechanizm promowania aplikacji skonfigurowanej w ich rozwiązaniu jako „odpowiednik właściciela urządzenia” do standardowego „właściciela urządzenia” rozpoznawanego przez standardowe interfejsy API Androida DevicePolicyManager, to:

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

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

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

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

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

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

3.9.2 Obsługa profilu zarządzanego

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

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

3.9.3 Pomoc dla użytkowników zarządzanych

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

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

3.10. Ułatwienia dostępu

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

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

  • [C-1-1] MUSI udostępniać implementację platformy ułatwień dostępu na Androida zgodnie z opisem w dokumentacji pakietu SDK interfejsów API ułatwień dostępu.
  • [C-1-2] MUSI generować zdarzenia związane z ułatwieniami dostępu i przekazywać odpowiednie AccessibilityEvent do wszystkich zarejestrowanych implementacji AccessibilityService zgodnie z dokumentacją pakietu SDK.
  • [C-1-3] MUSI honorować intencję android.settings.ACCESSIBILITY_SETTINGS, aby udostępniać użytkownikowi mechanizm włączania i wyłączania usług ułatwień dostępu innych firm wraz z preinstalowanymi usługami ułatwień dostępu.
  • [C-1-4] MUSI dodać przycisk na pasku nawigacyjnym systemu, który umożliwia użytkownikowi sterowanie usługą ułatwień dostępu, gdy włączone usługi ułatwień dostępu deklarują AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . W przypadku urządzeń bez systemowego paska nawigacyjnego to wymaganie nie ma zastosowania, ale urządzenia POWINNY udostępniać użytkownikowi możliwość sterowania tymi usługami ułatwień dostępu.

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

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

3.11. Zamiana tekstu na mowę

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

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

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

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

3.12. TV Input Framework

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

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

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

3.13. Szybkie ustawienia

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

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

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

3.14. Interfejs multimediów

Jeśli implementacje urządzeń obejmują platformę interfejsu , która obsługuje aplikacje innych firm korzystające z MediaBrowser i MediaSession:

3.15. Aplikacje błyskawiczne

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

  • [C-0-1] Aplikacje natychmiastowe MUSZĄ mieć przyznane tylko te uprawnienia, które mają wartość android:protectionLevel ustawioną na "instant".
  • [C-0-2] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami za pomocą niejawnych intencji, chyba że spełniony jest jeden z tych warunków:
    • Filtr wzorca intencji komponentu jest widoczny i ma wartość CATEGORY_BROWSABLE.
    • Działanie to ACTION_SEND, ACTION_SENDTO lub ACTION_SEND_MULTIPLE.
    • Cel jest jawnie udostępniany za pomocą atrybutu android:visibleToInstantApps.
  • [C-0-3] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami, chyba że komponent jest udostępniany za pomocą atrybutu android:visibleToInstantApps.
  • [C-0-4] Zainstalowane aplikacje NIE MOGĄ widzieć szczegółów dotyczących aplikacji błyskawicznych na urządzeniu, chyba że aplikacja błyskawiczna wyraźnie połączy się z zainstalowaną aplikacją.

3.16. Parowanie urządzenia towarzyszącego

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

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

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

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

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

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

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

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

4. Zgodność pakowania aplikacji

Implementacje na urządzeniach:

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

Implementacje na urządzeniach:

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

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

  • [C-0-5] MUSI mieć aktywność, która obsługuje intencję android.settings.MANAGE_UNKNOWN_APP_SOURCES.

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

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

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

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

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

5. Zgodność z multimediami

Implementacje na urządzeniach:

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

Implementacje na urządzeniach:

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

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

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

5.1. Kodeki multimediów

5.1.1. Kodowanie dźwięku

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

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

  • [C-1-1] PCM/WAVE

5.1.2. Dekodowanie dźwięku

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

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

  • [C-1-1] Profil MPEG-4 AAC (AAC LC)
  • [C-1-2] MPEG-4 HE AAC Profile (AAC+)
  • [C-1-3] Profil MPEG-4 HE AACv2 (ulepszony AAC+)
  • [C-1-4] AAC ELD (ulepszony kodek AAC o niskim opóźnieniu)
  • [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, który obejmuje USAC Baseline Profile i ISO/IEC 23003-4 Dynamic Range Control Profile)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE
  • [C-1-10] Opus

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

  • [C-2-1] Dekodowanie MUSI odbywać się bez downmixingu (np. strumień AAC 5.0 musi być dekodowany do 5 kanałów PCM, a strumień AAC 5.1 musi być dekodowany do 6 kanałów PCM).
  • [C-2-2] Metadane zakresu dynamicznego MUSZĄ być zgodne z definicją „Dynamic Range Control (DRC)” w normie ISO/IEC 14496-3, a android.media.MediaFormat klucze DRC MUSZĄ konfigurować zachowania dekodera audio związane z zakresem dynamicznym. Klucze AAC DRC zostały wprowadzone w interfejsie API 21 i są to: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_ENCODED_TARGET_LEVEL.

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

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

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

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

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

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

5.1.3. Szczegóły kodeków audio

Format/kodek Szczegóły Obsługiwane typy plików i formaty kontenerów
MPEG-4 AAC Profile
(AAC LC) 		Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 8 kHz do 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS raw AAC (.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 kHz 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 kHz do 48 kHz.
AAC ELD (ulepszony kodek AAC o niskim opóźnieniu) 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 kHz do 48 kHz. MPEG-4 (.mp4, .m4a)
AMR-NB 4,75–12,2 kb/s próbkowane przy 8 kHz 3GPP (.3gp)
AMR-WB 9 szybkości transmisji bitów od 6,60 kb/s do 23,85 kb/s przy częstotliwości próbkowania 16 kHz
FLAC Mono/Stereo (bez dźwięku wielokanałowego). Częstotliwości próbkowania do 48 kHz (ale na urządzeniach z wyjściem 44,1 kHz ZALECA SIĘ częstotliwość do 44,1 kHz, ponieważ próbnik w dół z 48 do 44,1 kHz nie zawiera filtra dolnoprzepustowego). ZALECANA jest głębia 16-bitowa; w przypadku głębi 24-bitowej nie stosuje się ditheringu. Tylko FLAC (.flac)
MP3 Mono/Stereo 8–320 kb/s stała (CBR) lub zmienna szybkość transmisji (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
  • Typ 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 liniowy PCM (częstotliwości do limitu sprzętowego). Urządzenia MUSZĄ obsługiwać częstotliwości próbkowania dla nagrywania surowego PCM przy częstotliwościach 8000, 11025, 16000 i 44100 Hz. WAVE (.wav)
Opus Matroska (.mkv), Ogg(.ogg)

5.1.4. Kodowanie obrazu

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

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

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

5.1.5. Dekodowanie obrazu

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

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

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

5.1.6. Szczegóły kodeków obrazu

Format/kodek Szczegóły Obsługiwane typy plików i formaty kontenerów
JPEG Podstawa + progresywna 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 wideo w internecie i usług wideokonferencyjnych, urządzenia POWINNY korzystać z kodeka sprzętowego VP8, który spełnia wymagania.

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

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

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

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

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

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

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

5.1.8. Lista kodeków wideo

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

5.2. Kodowanie wideo

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

  • NIE POWINNA przekraczać w przypadku 2 okien przesuwnych o więcej niż ok. 15% szybkości transmisji bitów między interwałami klatek wewnątrzklatkowych (klatek I).
  • NIE POWINNA przekraczać o ponad 100% szybkości transmisji w 1-sekundowym oknie przesuwnym.

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

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

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

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

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

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

5.2.1. H.263

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

  • [C-1-1] MUSI obsługiwać profil podstawowy na poziomie 45.
  • POWINIEN obsługiwać dynamicznie konfigurowane szybkości transmisji bitów w przypadku obsługiwanego kodera.

5.2.2. H-264

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

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

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

  • [C-2-1] MUSI obsługiwać profile kodowania w tabeli poniżej.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 240 pikseli 720 x 480 pikseli 1280 x 720 pikseli 1920 x 1080 pikseli
Liczba klatek filmu 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.
  • POWINNY obsługiwać te profile kodowania wideo w wysokiej rozdzielczości (HD):
  • POWINIEN obsługiwać zapisywanie plików Matroska WebM.
  • POWINIEN używać sprzętowego kodeka VP8, który spełnia wymagania dotyczące sprzętowego kodowania w projekcie WebM RTC, aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo w internecie i usług wideokonferencyjnych.

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

  • [C-2-1] MUSI obsługiwać profile kodowania w tabeli poniżej.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 180 pikseli 640 x 360 pikseli 1280 x 720 pikseli 1920 x 1080 pikseli
Liczba klatek filmu 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:

  • POWINIEN obsługiwać zapisywanie 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 i liczby klatek na sekundę w ramach tego samego strumienia za pomocą standardowych interfejsów API Androida w przypadku wszystkich kodeków VP8, VP9, H.264 i H.265 w czasie rzeczywistym i do maksymalnej rozdzielczości obsługiwanej przez każdy kodek na urządzeniu.

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

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

5.3.1. MPEG-2

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

  • [C-1-1] MUSI obsługiwać profil główny na wysokim poziomie.

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

  • [C-1-1] MUSI obsługiwać Simple Profile Level 3.

5.3.4. H.264

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

  • [C-1-1] MUSI obsługiwać profil główny na poziomie 3.1 i profil podstawowy. Obsługa ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) i RS (Redundant Slices) jest OPCJONALNA.
  • [C-1-2] MUSI być w stanie dekodować filmy w profilach SD (Standard Definition) wymienionych w tabeli poniżej i zakodowanych w profilu Baseline i Main Level 3.1 (w tym 720p30).
  • POWINNO umożliwiać dekodowanie filmów w profilach HD (High Definition) zgodnie z tabelą poniżej.

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

  • [C-2-1] MUSI obsługiwać profile dekodowania wideo HD 720p podane w tabeli poniżej.
  • [C-2-2] MUSI obsługiwać profile dekodowania wideo HD 1080p podane w tabeli poniżej.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 240 pikseli 720 x 480 pikseli 1280 x 720 pikseli 1920 x 1080 pikseli
Liczba klatek filmu 30 klatek/s 30 klatek/s 60 kl./s 30 kl./s (60 kl./stelewizja)
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 na poziomie 3 i profil dekodowania wideo SD zgodnie z tabelą poniżej.
  • POWINIEN obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
  • [C-1-2] MUSI obsługiwać profile dekodowania HD wskazane w tabeli poniżej, jeśli jest dostępny dekoder sprzętowy.

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

  • [C-2-1] Urządzenia MUSZĄ obsługiwać dekodowanie co najmniej jednego z formatów H.265 lub VP9 w profilach 720, 1080 i UHD.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p UHD
Rozdzielczość wideo 352 x 288 pikseli 720 x 480 pikseli 1280 x 720 pikseli 1920 x 1080 pikseli 3840 x 2160 pikseli
Liczba klatek filmu 30 klatek/s 30 klatek/s 30 klatek/s 30/60 kl./s (60 kl./sTelewizor 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 w tabeli poniżej.
  • POWINIEN używać sprzętowego kodeka VP8, który spełnia wymagania.
  • POWINNO obsługiwać profile dekodowania HD w tabeli poniżej.

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

  • [C-2-1] Urządzenia MUSZĄ obsługiwać profile 720p z tabeli poniżej.
  • [C-2-2] Urządzenia MUSZĄ obsługiwać profile 1080p z tabeli poniżej.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 180 pikseli 640 x 360 pikseli 1280 x 720 pikseli 1920 x 1080 pikseli
Liczba klatek filmu 30 klatek/s 30 klatek/s 30 kl./s (60 kl./stelewizja) 30 (60 kl./stelewizja)
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 tabelą poniżej.
  • POWINIEN obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.

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

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

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

  • [C-3-1] Urządzenia MUSZĄ obsługiwać dekodowanie co najmniej jednego z formatów VP9 lub H.265 w przypadku profili 720, 1080 i UHD.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p UHD
Rozdzielczość wideo 320 x 180 pikseli 640 x 360 pikseli 1280 x 720 pikseli 1920 x 1080 pikseli 3840 x 2160 pikseli
Liczba klatek filmu 30 klatek/s 30 klatek/s 30 klatek/s 30 kl./s (60 kl./sTelewizor ze 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

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

5.4.1. Przechwytywanie surowego dźwięku

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

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

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

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

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

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

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

Jeśli implementacje urządzeń umożliwiają odbiór radia AM i nagrywanie surowych treści audio w jakości DVD:

  • [C-2-1] MUSI rejestrować bez upsamplingu przy dowolnym współczynniku wyższym niż 16000:22050 lub 44100:48000.
  • [C-2-2] MUSI zawierać odpowiedni filtr wygładzający w przypadku próbkowania w górę lub w dół.

5.4.2. Nagrywanie na potrzeby rozpoznawania głosu

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

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

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

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

5.4.3. Przechwytywanie na potrzeby przekierowania odtwarzania

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

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

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

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

5.5. Odtwarzanie dźwięku

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

5.5.1. Odtwarzanie surowego dźwięku

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

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

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

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

    • Częstotliwości próbkowania: 24000, 48000

5.5.2. Efekty audio

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

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

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

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

Implementacje na urządzeniach samochodowych:

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

5.6. Opóźnienie dźwięku

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

Na potrzeby tej sekcji używaj tych definicji:

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

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

  • [C-SR] Opóźnienie wyjścia w przypadku zimnego startu nie przekracza 100 milisekund.
  • [C-SR] Ciągłe opóźnienie wyjściowe nie większe niż 45 milisekund
  • [C-SR] Zminimalizuj drgania zimnego wyjścia
  • [C-SR] Sygnatura czasowa zwracana przez AudioTrack.getTimestamp i AAudioStream_getTimestamp ma dokładność +/- 1 ms.

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

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

  • [C-1-1] NIE MOŻE zgłaszać obsługi dźwięku o niskim opóźnieniu.

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

  • [C-SR] Opóźnienie wejścia „na zimno” nie przekracza 100 milisekund.
  • [C-SR] Ciągłe opóźnienie wejściowe nie przekracza 30 milisekund.
  • [C-SR] Ciągłe opóźnienie w obie strony nie przekracza 50 milisekund.
  • [C-SR] Zminimalizuj drgania wejścia „na zimno”.
  • [C-SR] Ogranicz błąd w sygnaturach czasowych danych wejściowych zwracanych przez funkcję AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/- 1 ms.

5.7. Protokoły sieciowe

Implementacje urządzeń MUSZĄ obsługiwać protokoły sieci multimedialnych do odtwarzania dźwięku i wideo zgodnie z dokumentacją pakietu Android SDK.

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

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

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

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

Formaty segmentów multimedialnych

Formaty segmentów Źródła Wymagana obsługa kodeków
Zapis strumienia MPEG-2 ISO 13818 Kodeki wideo:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Szczegółowe informacje o H264 AVC, MPEG2-4 SP i MPEG-2 znajdziesz w sekcji 5.1.3.

Kodeki audio:

  • AAC
Szczegółowe informacje o AAC i jego odmianach znajdziesz w sekcji 5.1.1.
AAC z ramkami ADTS i tagami ID3 ISO 13818-7 Szczegółowe informacje o AAC i jego odmianach znajdziesz w sekcji 5.1.1.
WebVTT WebVTT

RTSP (RTP, SDP)

Nazwa profilu Źródła Wymagana obsługa kodeków
H264 AVC RFC 6184 Szczegółowe informacje o H264 AVC znajdziesz w sekcji 5.1.3.
MP4A-LATM RFC 6416 Szczegółowe informacje o AAC i jego odmianach 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 odmianach znajdziesz w sekcji 5.1.1.
MP2T RFC 2250 Szczegółowe informacje znajdziesz w sekcji MPEG-2 Transport Stream poniżej Transmisji na żywo przez HTTP.

5.8. Secure Media

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

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

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

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

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

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

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

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

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

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

5.10. Profesjonalny dźwięk

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

  • [C-1-1] MUSI zgłaszać obsługę funkcji android.hardware.audio.low_latency.
  • [C-1-2] Ciągłe opóźnienie dźwięku w obie strony, zdefiniowane w sekcji 5.6 Opóźnienie dźwięku, MUSI wynosić 20 milisekund lub mniej, a w przypadku co najmniej jednej obsługiwanej ścieżki POWINNO wynosić 10 milisekund lub mniej.
  • [C-1-3] MUSI zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
  • [C-1-4] MUSI zgłaszać obsługę funkcji android.software.midi.
  • [C-1-5] MUSI spełniać wymagania dotyczące opóźnień i dźwięku USB przy użyciu zarówno kolejki bufora PCM OpenSL ES, jak i interfejsów API AAudio native audio.
  • [SR] Zdecydowanie zalecane, aby zapewnić stały poziom wydajności procesora podczas aktywności dźwięku i zmiennego obciążenia procesora. Należy to przetestować za pomocą wersji SimpleSynth 1bd6391. Aplikację SimpleSynth należy uruchomić z tymi parametrami i po 10 minutach nie może ona mieć żadnych niedoborów:
    • Cykle pracy: 200 000
    • Zmienne obciążenie: WŁ. (co 2 sekundy będzie się zmieniać między 100% a 10% wartości cykli pracy. To ustawienie służy do testowania działania zarządcy procesora).
    • Stabilizacja obciążenia: WYŁ.
  • POWINNO minimalizować niedokładność zegara audio i odchylenie od czasu standardowego.
  • POWINNO minimalizować odchylenie zegara audio względem zegara procesora CLOCK_MONOTONIC, gdy oba są aktywne.
  • POWINNO minimalizować opóźnienie dźwięku w przypadku przetworników na urządzeniu.
  • POWINNO minimalizować opóźnienie dźwięku w przypadku cyfrowego dźwięku USB.
  • POWINNY dokumentować pomiary opóźnienia dźwięku na wszystkich ścieżkach.
  • POWINIEN minimalizować wahania czasu wejścia wywołania zwrotnego zakończenia bufora audio, ponieważ wpływa to na procent wykorzystania pełnej przepustowości procesora przez wywołanie zwrotne.
  • W normalnych warunkach użytkowania przy zgłoszonym opóźnieniu NIE POWINNO występować ani jedno niedopełnienie (wyjście) ani jedno przepełnienie (wejście) dźwięku.
  • POWINNO zapewniać zerową różnicę opóźnienia między kanałami.
  • POWINIEN minimalizować średni czas oczekiwania MIDI we wszystkich transportach.
  • POWINIEN minimalizować zmienność opóźnienia MIDI pod obciążeniem (jitter) we wszystkich transportach.
  • POWINIEN zapewniać dokładne sygnatury czasowe MIDI we wszystkich protokołach.
  • POWINNO minimalizować szum sygnału audio na przetwornikach na urządzeniu, w tym w okresie bezpośrednio po uruchomieniu „na zimno”.
  • POWINIEN zapewniać zerową różnicę zegara audio między wejściem a wyjściem odpowiednich punktów końcowych, gdy oba są aktywne. Przykłady odpowiednich punktów końcowych to mikrofon i głośnik na urządzeniu lub wejście i wyjście gniazda audio.
  • POWINIEN obsługiwać wywołania zwrotne dotyczące zakończenia buforowania dźwięku po stronie wejściowej i wyjściowej odpowiednich punktów końcowych w tym samym wątku, gdy oba są aktywne, i przechodzić do wywołania zwrotnego po stronie wyjściowej natychmiast po powrocie z wywołania zwrotnego po stronie wejściowej. Jeśli obsługa wywołań zwrotnych w tym samym wątku nie jest możliwa, wprowadź wywołanie zwrotne danych wyjściowych krótko po wprowadzeniu wywołania zwrotnego danych wejściowych, aby zapewnić aplikacji spójne taktowanie po stronie danych wejściowych i wyjściowych.
  • POWINIEN minimalizować różnicę faz między buforowaniem dźwięku HAL po stronie wejściowej i wyjściowej odpowiednich punktów końcowych.
  • POWINNO minimalizować opóźnienie dotyku.
  • POWINIEN minimalizować zmienność czasu oczekiwania na dotyk pod obciążeniem (jitter).
  • POWINNO mieć opóźnienie od dotknięcia do wyjścia audio nie większe niż 40 ms.

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

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

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

  • [C-3-1] MUSI implementować klasę audio USB.
  • [C-3-2] MUSI mieć ciągłe opóźnienie dźwięku w obie strony wynoszące 20 milisekund lub mniej w porcie trybu hosta USB przy użyciu klasy audio USB.
  • Ciągłe opóźnienie dźwięku w obie strony POWINNO wynosić 10 milisekund lub mniej w przypadku portu hosta USB w trybie USB audio class.

Jeśli urządzenie ma port HDMI:

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

5.11. Przechwytywanie dla nieprzetworzonych

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-2-1] MUSI zwracać null w przypadku metody interfejsu AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API, aby prawidłowo wskazywać brak obsługi.
  • [SR] są nadal ZDECYDOWANIE ZALECANE, aby spełnić jak najwięcej wymagań dotyczących ścieżki sygnału dla nieprzetworzonego źródła nagrania.

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

6.1. Narzędzia dla programistów

Implementacje na urządzeniach:

  • [C-0-1] MUSI obsługiwać narzędzia dla deweloperów Androida dostępne w pakiecie Android SDK.

  • Android Debug Bridge (adb)

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

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

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

  • Dalvik Debug Monitor Service (ddms)

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

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

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

6.2. Opcje programisty

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

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

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

7. Zgodność sprzętu

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

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

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

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

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

7.1. Wyświetlacz i grafika

Android zawiera funkcje, które automatycznie dostosowują zasoby aplikacji i układy interfejsu do urządzenia, aby zapewnić prawidłowe działanie aplikacji innych firm na różnych konfiguracjach sprzętowych. Urządzenia MUSZĄ prawidłowo implementować te interfejsy API i zachowania, zgodnie z opisem w tej sekcji.

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

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

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar i kształt ekranu

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

Implementacje na urządzeniach:

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

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

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

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

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

  • [C-1-1] MUSI zapewnić, że promień zaokrąglonych rogów jest mniejszy lub równy 38 dp.
  • POWINNA zawierać element interfejsu użytkownika umożliwiający przełączenie na tryb wyświetlania z prostokątnymi rogami.
7.1.1.2. Format ekranu

Nie ma ograniczeń dotyczących wartości proporcji ekranu fizycznego, ale proporcje ekranu logicznego, w którym renderowane są aplikacje innych firm, wynikające z wartości wysokości i szerokości zgłaszanych przez interfejsy API view.Display i interfejs API Configuration, MUSZĄ spełniać te wymagania:

  • [C-0-1] Urządzenia, w których Configuration.uiMode ma wartość UI_MODE_TYPE_NORMAL, MUSZĄ mieć współczynnik proporcji obrazu w zakresie od 1,3333 (4:3) do 1,86 (w przybliżeniu 16:9), chyba że aplikacja może być uznana za gotową do rozciągnięcia, jeśli spełnia jeden z tych warunków:

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

  • [C-0-2] Urządzenia, w których implementacjach wartość Configuration.uiMode jest ustawiona na UI_MODE_TYPE_WATCH, MUSZĄ mieć format obrazu ustawiony na 1,0 (1:1).

7.1.1.3. Gęstość ekranu

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

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

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

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

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

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

7.1.2. Wyświetlanie danych

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

  • [C-1-1] MUSI raportować prawidłowe wartości wszystkich danych dotyczących wyświetleń zdefiniowanych w interfejsie API android.util.DisplayMetrics.

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

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

7.1.3. Orientacja ekranu

Implementacje na urządzeniach:

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

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

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

7.1.4. Akceleracja grafiki 2D i 3D

7.1.4.1. OpenGL ES

Implementacje na urządzeniach:

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

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

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

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

  • [C-2-1] MUSI raportować za pomocą interfejsów API zarządzanych przez OpenGL ES i interfejsów API natywnych wszystkie inne zaimplementowane rozszerzenia OpenGL ES i NIE MOŻE raportować ciągów rozszerzeń, których nie obsługuje.
  • [C-2-2] MUSI obsługiwać rozszerzenia EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage i EGL_ANDROID_recordable.
  • [SR] są ZDECYDOWANIE ZALECANE do obsługi EGL_KHR_partial_update.
  • POWINNY dokładnie zgłaszać za pomocą metody getString() wszystkie obsługiwane formaty kompresji tekstur, które są zwykle specyficzne dla danego dostawcy.

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

  • [C-3-1] MUSI eksportować odpowiednie symbole funkcji dla tych wersji oprócz symboli funkcji OpenGL ES 2.0 w bibliotece libGLESv2.so.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-3-1] MUSI udostępniać obsługę SYNC_FD zewnętrznych typów semaforów i uchwytów.
  • [SR] Are STRONGLY RECOMMENDED to support the VK_ANDROID_external_memory_android_hardware_buffer extension.
7.1.4.3 RenderScript
  • [C-0-1] Implementacje urządzeń MUSZĄ obsługiwać Android RenderScript zgodnie z dokumentacją pakietu Android SDK.
7.1.4.4 Akceleracja grafiki 2D

Android zawiera mechanizm, który umożliwia aplikacjom deklarowanie, że chcą włączyć akcelerację sprzętową grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku za pomocą tagu manifestu android:hardwareAccelerated lub bezpośrednich wywołań interfejsu API.

Implementacje na urządzeniach:

  • [C-0-1] MUSI domyślnie włączać akcelerację sprzętową i MUSI ją wyłączać, jeśli deweloper o to poprosi, ustawiając android:hardwareAccelerated="false” lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów API Android View.
  • [C-0-2] MUSI działać zgodnie z dokumentacją pakietu Android SDK dotyczącą akceleracji sprzętowej.

Android zawiera obiekt TextureView, który umożliwia deweloperom bezpośrednie integrowanie tekstur OpenGL ES akcelerowanych sprzętowo jako miejsc docelowych renderowania w hierarchii interfejsu.

Implementacje na urządzeniach:

  • [C-0-3] MUSI obsługiwać interfejs TextureView API i MUSI wykazywać spójne działanie z implementacją Androida wyższego poziomu.
7.1.4.5 Wyświetlacze o szerokiej gamie kolorów

Jeśli implementacje urządzeń deklarują obsługę wyświetlaczy o szerokiej gamie kolorów za pomocą Configuration.isScreenWideColorGamut() , to:

  • [C-1-1] MUSI mieć skalibrowany kolorystycznie wyświetlacz.
  • [C-1-2] MUSI mieć wyświetlacz, którego gama kolorów w przestrzeni CIE 1931 xyY w całości pokrywa gamę kolorów sRGB.
  • [C-1-3] MUSI mieć wyświetlacz, którego gamut obejmuje co najmniej 90% przestrzeni barw DCI-P3 w przestrzeni CIE 1931 xyY.
  • [C-1-4] MUSI obsługiwać OpenGL ES 3.1 lub 3.2 i prawidłowo to zgłaszać.
  • [C-1-5] MUSI reklamować obsługę rozszerzeń EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3 i EGL_KHR_gl_colorspace_display_p3.
  • [SR] Zdecydowanie ZALECA się obsługę GL_EXT_sRGB.

Jeśli urządzenia nie obsługują wyświetlaczy o szerokiej gamie kolorów:

  • [C-2-1] POWINIEN pokrywać co najmniej 100% sRGB w przestrzeni CIE 1931 xyY, chociaż gama kolorów ekranu jest niezdefiniowana.

7.1.5. Tryb zgodności ze starszymi aplikacjami

Android określa „tryb zgodności”, w którym platforma działa w trybie „normalnego” rozmiaru ekranu (320 dp szerokości) na potrzeby starszych aplikacji, które nie zostały opracowane dla starszych wersji Androida sprzed wprowadzenia niezależności od rozmiaru ekranu.

7.1.6. Technologia ekranu

Platforma Android zawiera interfejsy API, które umożliwiają aplikacjom renderowanie na wyświetlaczu bogatej grafiki. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zgodnie z definicją w pakiecie Android SDK, chyba że w tym dokumencie wyraźnie zezwala się na coś innego.

Implementacje na urządzeniach:

  • [C-0-1] MUSI obsługiwać wyświetlacze umożliwiające renderowanie 16-bitowej grafiki kolorowej.
  • POWINNY obsługiwać wyświetlacze obsługujące 24-bitową grafikę kolorową.
  • [C-0-2] MUSI obsługiwać wyświetlacze, które mogą renderować animacje.
  • [C-0-3] MUSI korzystać z technologii wyświetlania, która ma współczynnik proporcji piksela (PAR) w zakresie od 0,9 do 1,15. Oznacza to, że współczynnik proporcji piksela MUSI być zbliżony do kwadratu (1,0) z tolerancją 10–15%.

7.1.7. Wyświetlacze dodatkowe

Android obsługuje wyświetlacze dodatkowe, co umożliwia udostępnianie multimediów i korzystanie z interfejsów API dla programistów, które zapewniają dostęp do wyświetlaczy zewnętrznych.

Jeśli urządzenia obsługują wyświetlacz zewnętrzny przez połączenie przewodowe, bezprzewodowe lub wbudowany dodatkowy wyświetlacz:

  • [C-1-1] MUSI implementować usługę systemową i interfejs API DisplayManager zgodnie z opisem w dokumentacji pakietu Android SDK.

7.2. Urządzenia wejściowe

Implementacje na urządzeniach:

7.2.1. Klawiatura

Jeśli implementacje urządzeń obejmują obsługę aplikacji edytora metody wprowadzania (IME) innych firm:

Implementacje urządzeń: * [C-0-1] NIE MOGĄ zawierać klawiatury sprzętowej, która nie jest zgodna z jednym z formatów określonych w android.content.res.Configuration.keyboard (QWERTY lub 12-klawiszowa). * POWINNY zawierać dodatkowe implementacje klawiatury ekranowej. * MOŻE zawierać klawiaturę sprzętową.

7.2.2. Nawigacja bezdotykowa

Android obsługuje klawisz kierunkowy, trackball i kółko jako mechanizmy nawigacji bezdotykowej.

Implementacje na urządzeniach:

Jeśli implementacje urządzeń nie mają nawigacji bezdotykowej:

  • [C-1-1] MUSI udostępniać rozsądny alternatywny mechanizm interfejsu użytkownika do wybierania i edytowania tekstu, zgodny z silnikami zarządzania wprowadzaniem danych. Implementacja open source Androida obejmuje mechanizm wyboru odpowiedni do użycia na urządzeniach, które nie mają wejść nawigacyjnych innych niż dotykowe.

7.2.3. Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz, które są zwykle dostępne po naciśnięciu specjalnego przycisku fizycznego lub określonej części ekranu dotykowego, są niezbędne w przypadku nawigacji na Androidzie, a tym samym w przypadku implementacji na urządzeniach:

  • [C-0-1] MUSI udostępniać użytkownikowi możliwość uruchamiania zainstalowanych aplikacji, które mają działanie z wartością <intent-filter> ustawioną na ACTION=MAIN i CATEGORY=LAUNCHER lub CATEGORY=LEANBACK_LAUNCHER w przypadku implementacji na urządzeniach telewizyjnych. Funkcja Strona główna powinna być mechanizmem umożliwiającym użytkownikowi tę czynność.
  • POWINNY zawierać przyciski do funkcji Ostatnie i Wstecz.

Jeśli dostępne są funkcje Strona główna, Ostatnie lub Wstecz:

  • [C-1-1] MUSI być dostępny za pomocą jednego działania (np. kliknięcia, dwukrotnego kliknięcia lub gestu), gdy jest dostępny.
  • [C-1-2] MUSI wyraźnie wskazywać, które pojedyncze działanie wywoła każdą funkcję. Przykłady takich informacji to widoczna ikona na przycisku, ikona oprogramowania na pasku nawigacyjnym na ekranie lub przeprowadzenie użytkownika przez demonstrację krok po kroku podczas konfiguracji po wyjęciu z pudełka.

Implementacje na urządzeniach:

  • [SR] Zdecydowanie zalecamy, aby nie udostępniać mechanizmu wprowadzania danych dla funkcji Menu, ponieważ została ona wycofana na rzecz paska działań w Androidzie 4.0.

Jeśli implementacje urządzeń udostępniają funkcję Menu:

  • [C-2-1] MUSI wyświetlać przycisk menu dodatkowych działań, gdy wyskakujące menu dodatkowych działań nie jest puste i pasek działań jest widoczny.
  • [C-2-2] NIE MOŻE modyfikować pozycji wyskakującego okienka z dodatkowymi działaniami wyświetlanego po wybraniu przycisku dodatkowych działań na pasku działań, ale MOŻE renderować wyskakujące okienko z dodatkowymi działaniami w zmodyfikowanej pozycji na ekranie, gdy jest ono wyświetlane po wybraniu funkcji Menu.

Jeśli implementacje urządzeń nie udostępniają funkcji Menu, ze względu na zgodność wsteczną: * [C-3-1] MUSZĄ udostępniać funkcję Menu aplikacjom, gdy targetSdkVersion jest mniejsza niż 10, za pomocą przycisku fizycznego, klawisza programowego lub gestów. Funkcja Menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacyjnymi.

Jeśli implementacje urządzeń udostępniają funkcję Asystenta: * [C-4-1] MUSZĄ udostępniać funkcję Asystenta za pomocą jednego działania (np. kliknięcia, dwukrotnego kliknięcia lub gestu), gdy dostępne są inne klawisze nawigacyjne. * [SR] Zdecydowanie zalecamy używanie długiego naciśnięcia przycisku HOME jako wyznaczonej interakcji.

Jeśli implementacje urządzeń używają do wyświetlania klawiszy nawigacyjnych osobnej części ekranu:

  • [C-5-1] Klawisze nawigacyjne MUSZĄ zajmować odrębną część ekranu, niedostępną dla aplikacji, i NIE MOGĄ zasłaniać ani w inny sposób zakłócać działania części ekranu dostępnej dla aplikacji.
  • [C-5-2] MUSI udostępniać aplikacjom część wyświetlacza, która spełnia wymagania określone w sekcji 7.1.1.
  • [C-5-3] MUSI uwzględniać flagi ustawione przez aplikację za pomocą metody interfejsu API View.setSystemUiVisibility(), aby ta odrębna część ekranu (czyli pasek nawigacyjny) była prawidłowo ukryta zgodnie z dokumentacją pakietu SDK.

7.2.4. Wprowadzanie danych za pomocą ekranu dotykowego

Android obsługuje różne systemy wprowadzania danych za pomocą wskaźnika, takie jak ekrany dotykowe, panele dotykowe i urządzenia do wprowadzania danych za pomocą symulacji dotyku. Urządzenia z ekranem dotykowym są powiązane z wyświetlaczem w taki sposób, że użytkownik ma wrażenie, że bezpośrednio manipuluje elementami na ekranie. Ponieważ użytkownik dotyka ekranu bezpośrednio, system nie wymaga żadnych dodatkowych elementów, które wskazywałyby manipulowane obiekty.

Implementacje na urządzeniach:

  • POWINNO mieć jakiś system wprowadzania danych za pomocą wskaźnika (myszy lub dotyku).
  • POWINNY obsługiwać wskaźniki śledzone w pełni niezależnie.

Jeśli urządzenie ma ekran dotykowy (obsługujący co najmniej 1 punkt dotyku):

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

Jeśli urządzenie ma ekran dotykowy, który może śledzić więcej niż 1 dotyk, musi:

  • [C-2-1] MUSI zgłaszać odpowiednie flagi funkcji android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand odpowiadające typowi ekranu dotykowego na urządzeniu.

Jeśli urządzenie nie ma ekranu dotykowego (i korzysta tylko z urządzenia wskazującego) oraz spełnia wymagania dotyczące fałszywych dotknięć opisane w sekcji 7.2.5, to:

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

7.2.5. Symulowane dotykowe wprowadzanie danych

Symulowany interfejs dotykowy to system wprowadzania danych przez użytkownika, który przybliża podzbiór funkcji ekranu dotykowego. Na przykład mysz lub pilot, które sterują kursorem na ekranie, są podobne do dotyku, ale wymagają od użytkownika najpierw wskazania lub ustawienia ostrości, a potem kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, żyroskopowa mysz powietrzna, żyroskopowy wskaźnik, joystick i trackpad wielodotykowy, może obsługiwać interakcje z fałszywym dotykiem. Android zawiera funkcję constant android.hardware.faketouch, która odpowiada urządzeniu wejściowemu o wysokiej wierności, które nie jest dotykowe (oparte na wskaźniku), np. myszy lub trackpadzie, które może odpowiednio emulować dane wejściowe oparte na dotyku (w tym podstawową obsługę gestów), i wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.

Jeśli urządzenie nie ma ekranu dotykowego, ale ma inny system wejściowy wskaźnika, który ma być dostępny, należy:

  • POWINIEN deklarować obsługę flagi funkcji android.hardware.faketouch.

Jeśli implementacje urządzeń deklarują obsługę android.hardware.faketouch, to:

  • [C-1-1] MUSI zgłaszać bezwzględne położenie wskaźnika na ekranie w osiach X i Y oraz wyświetlać wskaźnik na ekranie.
  • [C-1-2] MUSI zgłaszać zdarzenie dotyku z kodem działania, który określa zmianę stanu wskaźnika podczas przesuwania w dół lub w górę ekranu.
  • [C-1-3] MUSI obsługiwać naciśnięcie i zwolnienie wskaźnika na obiekcie na ekranie, co umożliwia użytkownikom emulowanie kliknięcia obiektu na ekranie.
  • [C-1-4] MUSI obsługiwać naciśnięcie wskaźnika, zwolnienie wskaźnika, naciśnięcie wskaźnika, a następnie zwolnienie wskaźnika w tym samym miejscu na obiekcie na ekranie w określonym czasie, co umożliwia użytkownikom emulowanie dwukrotnego kliknięcia obiektu na ekranie.
  • [C-1-5] MUSI obsługiwać naciśnięcie wskaźnika w dowolnym punkcie ekranu, przesunięcie wskaźnika do dowolnego innego punktu ekranu, a następnie zwolnienie wskaźnika, co umożliwia użytkownikom emulowanie przeciągania dotykowego.
  • [C-1-6] MUSI obsługiwać naciśnięcie wskaźnika, a następnie umożliwiać użytkownikom szybkie przeniesienie obiektu w inne miejsce na ekranie i zwolnienie wskaźnika, co pozwala użytkownikom rzucać obiektem na ekranie.
  • [C-1-7] MUSI zgłaszać wartość TOUCHSCREEN_NOTOUCH w polu interfejsu API Configuration.touchscreen.

Jeśli implementacje urządzeń deklarują obsługę android.hardware.faketouch.multitouch.distinct, to:

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

Jeśli implementacje urządzeń deklarują obsługę android.hardware.faketouch.multitouch.jazzhand, to:

  • [C-3-1] MUSI deklarować obsługę android.hardware.faketouch.
  • [C-3-2] MUSI obsługiwać odrębne śledzenie co najmniej 5 wskaźników (śledzenie dłoni z palcami) w pełni niezależnie.

7.2.6. Obsługa kontrolera do gier

7.2.6.1. Mapowania przycisków

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

  • [C-1-1] MUSI zawierać kontroler wbudowany lub dostarczany w pudełku jako osobne urządzenie, które umożliwia wprowadzanie wszystkich zdarzeń wymienionych w tabelach poniżej.
  • [C-1-2] MUSI być w stanie mapować zdarzenia HID na powiązane z nimi stałe Androida view.InputEvent wymienione w tabelach poniżej. Implementacja Androida obejmuje implementację kontrolerów do gier, która spełnia to wymaganie.
Przycisk HID Usage2 Przycisk Androida
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
Przycisk w górę na padzie kierunkowym1
Przycisk w dół na padzie kierunkowym1 		0x01 0x00393 AXIS_HAT_Y4
Przycisk w lewo na padzie kierunkowym1
Przycisk w prawo na padzie kierunkowym1 		0x01 0x00393 AXIS_HAT_X4
Lewy przycisk na ramieniu1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Prawy przycisk na ramieniu1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Kliknięcie lewej gałki1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Kliknięcie prawego drążka1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Strona główna1 0x0c 0x0223 KEYCODE_HOME (3)
Wstecz1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 Powyższe zastosowania HID muszą być zadeklarowane w ramach urzędu certyfikacji Game pad (0x01 0x0005).

3 Wartość Logical Minimum musi wynosić 0, Logical Maximum – 7, Physical Minimum – 0, Physical Maximum – 315, Units – Degrees, a Report Size – 4. Wartość logiczna jest zdefiniowana jako obrót w kierunku zgodnym z ruchem wskazówek zegara od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i naciśnięcie przycisku w górę, a wartość logiczna 1 oznacza obrót o 45 stopni i naciśnięcie klawiszy w górę i w lewo.

4 MotionEvent

Ustawienia analogowe1 Użycie HID Przycisk Androida
Lewy spust 0x02 0x00C5 AXIS_LTRIGGER
Prawy spust 0x02 0x00C4 AXIS_RTRIGGER
Lewy joystick 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
Prawy joystick 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. Pilot

Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.3.1.

7.3. Czujniki

Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, implementacja urządzenia MUSI implementować ten interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK i dokumentacji Android Open Source dotyczącej czujników.

Implementacje na urządzeniach:

  • [C-0-1] MUSI dokładnie raportować obecność lub brak czujników w klasie android.content.pm.PackageManager.
  • [C-0-2] MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() i podobnych metod.
  • [C-0-3] MUSI działać w rozsądny sposób w przypadku wszystkich innych interfejsów API czujników (np. zwracać wartość true lub false w odpowiednich przypadkach, gdy aplikacje próbują zarejestrować odbiorniki, nie wywoływać odbiorników czujników, gdy odpowiednie czujniki nie są obecne itp.).

Jeśli implementacje urządzeń obejmują określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych:

  • [C-1-1] MUSI zgłaszać wszystkie pomiary czujników, używając odpowiednich wartości w Międzynarodowym Układzie Jednostek (metrycznym) dla każdego typu czujnika zgodnie z dokumentacją pakietu Android SDK.
  • [C-1-2] MUSI zgłaszać dane z czujnika z maksymalnym opóźnieniem wynoszącym 100 milisekund + 2 * sample_time w przypadku czujnika przesyłanego strumieniowo z minimalnym wymaganym opóźnieniem wynoszącym 5 ms + 2 * sample_time, gdy procesor aplikacji jest aktywny. To opóźnienie nie obejmuje żadnych opóźnień związanych z filtrowaniem.
  • [C-1-3] MUSI zgłosić pierwszą próbkę z czujnika w ciągu 400 milisekund + 2 * sample_time od aktywacji czujnika. Dopuszczalna jest dokładność próbki wynosząca 0.

  • [SR] POWINIEN raportować czas zdarzenia w nanosekundach zgodnie z dokumentacją pakietu Android SDK. Czas ten powinien odpowiadać momentowi wystąpienia zdarzenia i być zsynchronizowany z zegarem SystemClock.elapsedRealtimeNano(). ZDECYDOWANIE ZALECA SIĘ, aby obecne i nowe urządzenia z Androidem spełniały te wymagania, dzięki czemu będzie można je zaktualizować do przyszłych wersji platformy, w których ten komponent może być WYMAGANY. Błąd synchronizacji powinien być mniejszy niż 100 milisekund.

  • [C-1-4] W przypadku każdego interfejsu API, który zgodnie z dokumentacją pakietu Android SDK jest czujnikiem ciągłym, implementacje urządzeń MUSZĄ stale dostarczać okresowe próbki danych, których odchylenie powinno być mniejsze niż 3%. Odchylenie jest definiowane jako odchylenie standardowe różnicy zgłaszanych wartości sygnatury czasowej między kolejnymi zdarzeniami.

  • [C-1-5] MUSI zapewnić, że strumień zdarzeń z czujnika NIE BĘDZIE uniemożliwiał procesorowi urządzenia przejścia w stan zawieszenia ani wybudzenia się z niego.

  • Gdy kilka czujników jest aktywnych, zużycie energii NIE POWINNO przekraczać sumy zgłoszonego zużycia energii poszczególnych czujników.

Powyższa lista nie jest wyczerpująca. Za wiarygodne należy uznać udokumentowane działanie pakietu Android SDK i dokumentację Android Open Source dotyczącą czujników.

Niektóre typy czujników są złożone, co oznacza, że można je uzyskać na podstawie danych dostarczanych przez co najmniej 1 inny czujnik. (Przykłady to czujnik orientacji i czujnik przyspieszenia liniowego).

Implementacje na urządzeniach:

  • POWINNY implementować te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w sekcji Typy czujników.

Jeśli implementacje urządzeń obejmują czujnik złożony:

  • [C-2-1] MUSI implementować czujnik zgodnie z opisem w dokumentacji Android Open Source dotyczącej czujników złożonych.

7.3.1. Akcelerometr

  • Urządzenia POWINNY zawierać 3-osiowy akcelerometr.

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

  • [C-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz.
  • [C-1-2] MUSI implementować i zgłaszać czujnik TYPE_ACCELEROMETER.
  • [C-1-3] MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida.
  • [C-1-4] MUSI być w stanie mierzyć w zakresie od swobodnego spadania do czterokrotności przyspieszenia ziemskiego(4 g) lub więcej w dowolnej osi.
  • [C-1-5] MUSI mieć rozdzielczość co najmniej 12 bitów.
  • [C-1-6] MUSI mieć odchylenie standardowe nie większe niż 0,05 m/s², przy czym odchylenie standardowe należy obliczać dla każdej osi na podstawie próbek zebranych w okresie co najmniej 3 sekund przy największej szybkości próbkowania.
  • [SR] ZDECYDOWANIE ZALECA SIĘ wdrożenie TYPE_SIGNIFICANT_MOTION czujnika złożonego.
  • [SR] Zdecydowanie zalecamy wdrożenie czujnika TYPE_ACCELEROMETER_UNCALIBRATED, jeśli dostępna jest kalibracja akcelerometru online.
  • POWINIEN implementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR i TYPE_STEP_COUNTER zgodnie z opisem w dokumencie Android SDK.
  • POWINNY zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.
  • POWINNA mieć rozdzielczość co najmniej 16 bitów.
  • POWINIEN być kalibrowany podczas użytkowania, jeśli jego charakterystyka zmienia się w trakcie cyklu życia, a także kompensowany, a parametry kompensacji powinny być zachowywane między ponownymi uruchomieniami urządzenia.
  • POWINNY mieć kompensację temperatury.
  • POWINIEN też implementować czujnik TYPE_ACCELEROMETER_UNCALIBRATED.

Jeśli urządzenie ma 3-osiowy akcelerometr i którykolwiek z czujników złożonych TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER:

  • [C-2-1] Suma zużycia energii MUSI zawsze być mniejsza niż 4 mW.
  • POWINNY być mniejsze niż 2 mW i 0,5 mW, gdy urządzenie jest w stanie dynamicznym lub statycznym.

Jeśli urządzenie ma 3-osiowy akcelerometr i żyroskop, to:

  • [C-3-1] MUSI wdrożyć czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
  • POWINIEN implementować TYPE_GAME_ROTATION_VECTOR czujnik złożony.
  • [SR] W przypadku obecnych i nowych urządzeń z Androidem ZDECYDOWANIE ZALECA SIĘ wdrożenie TYPE_GAME_ROTATION_VECTOR.

Jeśli implementacje urządzenia obejmują 3-osiowy akcelerometr, czujnik żyroskopu i czujnik magnetometru:

  • [C-4-1] MUSI implementować TYPE_ROTATION_VECTOR czujnik złożony.

7.3.2. Magnetometr

  • Implementacje urządzeń POWINNY zawierać 3-osiowy magnetometr (kompas).

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

  • [C-1-1] MUSI wdrożyć czujnik TYPE_MAGNETIC_FIELD.
  • [C-1-2] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 10 Hz i POWINIEN raportować zdarzenia z częstotliwością co najmniej 50 Hz.
  • [C-1-3] MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida.
  • [C-1-4] MUSI być w stanie mierzyć wartości w zakresie od -900 µT do +900 µT na każdej osi, zanim osiągnie stan nasycenia.
  • [C-1-5] MUSI mieć wartość przesunięcia twardego żelaza mniejszą niż 700 µT i POWINIEN mieć wartość poniżej 200 µT, co można osiągnąć, umieszczając magnetometr z dala od dynamicznych (indukowanych prądem) i statycznych (indukowanych magnesem) pól magnetycznych.
  • [C-1-6] MUSI mieć rozdzielczość równą lub większą niż 0,6 µT.
  • [C-1-7] MUSI obsługiwać kalibrację online i kompensację odchylenia spowodowanego przez ferromagnetyki oraz zachowywać parametry kompensacji między ponownymi uruchomieniami urządzenia.
  • [C-1-8] MUSI mieć zastosowaną kompensację miękkiego żelaza – kalibrację można przeprowadzić podczas użytkowania lub produkcji urządzenia.
  • [C-1-9] MUSI mieć odchylenie standardowe obliczone dla każdej osi na podstawie próbek zebranych w okresie co najmniej 3 sekund przy największej częstotliwości próbkowania, nie większe niż 1,5 µT; POWINNO mieć odchylenie standardowe nie większe niż 0,5 µT.
  • POWINIEN implementować czujnik TYPE_MAGNETIC_FIELD_UNCALIBRATED.
  • [SR] W przypadku obecnych i nowych urządzeń z Androidem ZDECYDOWANIE ZALECA SIĘ wdrożenie TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Jeśli implementacje urządzenia obejmują 3-osiowy magnetometr, akcelerometr i żyroskop, to:

  • [C-2-1] MUSI implementować TYPE_ROTATION_VECTOR czujnik złożony.

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

  • MOŻE implementować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Jeśli implementacje urządzenia zawierają 3-osiowy magnetometr, akcelerometr i czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR:

  • [C-3-1] MUSI zużywać mniej niż 10 mW.
  • POWINIEN zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie wsadowym przy częstotliwości 10 Hz.

7.3.3. GPS

Implementacje na urządzeniach:

  • POWINIEN zawierać odbiornik GPS/GNSS.

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

  • [C-1-1] MUSI obsługiwać dane o lokalizacji z częstotliwością co najmniej 1 Hz, gdy są one wymagane w ramach żądania LocationManager#requestLocationUpdate.
  • [C-1-2] MUSI być w stanie określić lokalizację w warunkach otwartego nieba (silne sygnały, znikoma wielodrożność, HDOP < 2) w ciągu 10 sekund (szybki czas do pierwszego ustalenia pozycji), gdy jest połączony z internetem o szybkości transmisji danych co najmniej 0,5 Mb/s. Ten wymóg jest zwykle spełniany przez zastosowanie jakiejś formy wspomaganego lub prognozowanego GPS/GNSS, aby zminimalizować czas ustalania pozycji GPS/GNSS (dane wspomagające obejmują czas odniesienia, lokalizację odniesienia i efemerydy/zegar satelity).
    • [C-1-6] Po wykonaniu takiego obliczenia lokalizacji implementacje urządzeń MUSZĄ określić swoją lokalizację na otwartym niebie w ciągu 5 sekund od ponownego uruchomienia żądań lokalizacji, do godziny po początkowym obliczeniu lokalizacji, nawet jeśli kolejne żądanie zostanie wysłane bez połączenia transmisji danych lub po wyłączeniu i ponownym włączeniu zasilania.

  • W otwartej przestrzeni po określeniu lokalizacji, gdy urządzenie jest nieruchome lub porusza się z przyspieszeniem mniejszym niż 1 m/s²:

    • [C-1-3] MUSI być w stanie określić lokalizację z dokładnością do 20 metrów i prędkość z dokładnością do 0,5 metra na sekundę w co najmniej 95% przypadków.
    • [C-1-4] MUSI jednocześnie śledzić i zgłaszać za pomocą GnssStatus.Callback co najmniej 8 satelitów z jednej konstelacji.
    • POWINNO być w stanie śledzić jednocześnie co najmniej 24 satelity z różnych konstelacji (np. GPS i co najmniej 1 z systemów GLONASS, BeiDou lub Galileo).
    • [C-1-5] MUSI zgłaszać generację technologii GNSS za pomocą interfejsu API do testowania „getGnssYearOfHardware”.
    • [SR] Dalsze przekazywanie normalnych danych lokalizacji GPS/GNSS podczas połączenia alarmowego.
    • [SR] Zgłaszaj pomiary GNSS ze wszystkich śledzonych konstelacji (zgodnie z informacjami w wiadomościach GnssStatus) z wyjątkiem SBAS.
    • [SR] Raportowanie AGC i częstotliwości pomiaru GNSS.
    • [SR] Zgłaszaj wszystkie szacunki dokładności (w tym kierunek, prędkość i wysokość) w ramach każdej lokalizacji GPS/GNSS.
    • [SR] Zdecydowanie zalecamy spełnienie jak największej liczby dodatkowych wymagań obowiązkowych w przypadku urządzeń zgłaszających rok „2016” lub „2017” za pomocą interfejsu Test APILocationManager.getGnssYearOfHardware().

Jeśli implementacje urządzeń zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, a interfejs API testu LocationManager.getGnssYearOfHardware() zgłasza rok „2016” lub nowszy, to:

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

Jeśli implementacje urządzeń zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, a interfejs API testu LocationManager.getGnssYearOfHardware() zgłasza rok „2017” lub nowszy, to:

  • [C-3-1] MUSI nadal przekazywać normalne dane lokalizacji GPS/GNSS podczas połączenia alarmowego.
  • [C-3-2] MUSI raportować pomiary GNSS ze wszystkich śledzonych konstelacji (zgodnie z informacjami w wiadomościach GnssStatus), z wyjątkiem SBAS.
  • [C-3-3] MUSI raportować AGC i częstotliwość pomiaru GNSS.
  • [C-3-4] MUSI zgłaszać wszystkie szacunki dokładności (w tym kierunek, prędkość i wysokość) w ramach każdej lokalizacji GPS/GNSS.

Jeśli implementacje urządzeń zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, a interfejs API testu LocationManager.getGnssYearOfHardware() zgłasza rok „2018” lub nowszy, to:

  • [C-4-1] MUSI nadal dostarczać do aplikacji normalne dane wyjściowe GPS/GNSS podczas sesji połączenia alarmowego zainicjowanej przez sieć (MS-Based).
  • [C-4-2] MUSI zgłaszać pozycje i pomiary do interfejsów GNSS Location Provider API.

7.3.4. Żyroskop

Implementacje na urządzeniach:

  • POWINIEN zawierać żyroskop (czujnik zmiany kąta).
  • NIE POWINNY zawierać żyroskopu, chyba że jest też akcelerometr 3-osiowy.

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

  • [C-1-1] MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz.
  • [C-1-2] MUSI implementować czujnik TYPE_GYROSCOPE i POWINIEN implementować czujnik TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-3] MUSI być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.
  • [C-1-4] MUSI mieć rozdzielczość co najmniej 12 bitów i POWINIEN mieć rozdzielczość co najmniej 16 bitów.
  • [C-1-5] MUSI mieć kompensację temperatury.
  • [C-1-6] MUSI być kalibrowany i kompensowany podczas użytkowania oraz zachowywać parametry kompensacji między ponownymi uruchomieniami urządzenia.
  • [C-1-7] MUSI mieć wariancję nie większą niż 1e-7 rad^2 / s^2 na Hz (wariancja na Hz lub rad^2 / s). Wariancja może się zmieniać wraz z częstotliwością próbkowania, ale MUSI być ograniczona tą wartością. Inaczej mówiąc, jeśli zmierzysz wariancję żyroskopu przy częstotliwości próbkowania 1 Hz, NIE POWINNA ona przekraczać 1e-7 rad^2/s^2.
  • [SR] W przypadku obecnych i nowych urządzeń z Androidem ZDECYDOWANIE ZALECA SIĘ wdrożenie SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
  • [SR] Błąd kalibracji ZDECYDOWANIE ZALECA się, aby był mniejszy niż 0,01 rad/s, gdy urządzenie jest nieruchome w temperaturze pokojowej.
  • POWINNY zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.

Jeśli urządzenie ma żyroskop, akcelerometr i magnetometr:

  • [C-2-1] MUSI implementować TYPE_ROTATION_VECTOR czujnik złożony.

Jeśli urządzenie ma żyroskop i akcelerometr:

  • [C-3-1] MUSI wdrożyć czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
  • [SR] W przypadku obecnych i nowych urządzeń z Androidem ZDECYDOWANIE ZALECA SIĘ wdrożenie TYPE_GAME_ROTATION_VECTOR.
  • POWINIEN implementować TYPE_GAME_ROTATION_VECTOR czujnik złożony.

7.3.5. barometr;

  • Urządzenia POWINNY zawierać barometr (czujnik ciśnienia powietrza).

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

  • [C-1-1] MUSI implementować i zgłaszać TYPE_PRESSURE.
  • [C-1-2] MUSI być w stanie dostarczać zdarzenia z częstotliwością co najmniej 5 Hz.
  • [C-1-3] MUSI mieć kompensację temperatury.
  • [SR] ZDECYDOWANIE ZALECANE, aby można było raportować pomiary ciśnienia w zakresie od 300 hPa do 1100 hPa.
  • POWINNA mieć dokładność bezwzględną na poziomie 1 hPa.
  • POWINIEN mieć dokładność względną 0,12 hPa w zakresie 20 hPa (co odpowiada dokładności ok. 1 m przy zmianie wysokości o ok. 200 m na poziomie morza).

7.3.6. Termometr

Implementacje urządzeń: * MOGĄ zawierać termometr otoczenia (czujnik temperatury). * MOŻE, ale NIE POWINIEN zawierać czujnika temperatury procesora.

Jeśli urządzenie ma termometr otoczenia (czujnik temperatury):

  • [C-1-1] MUSI być zdefiniowany jako SENSOR_TYPE_AMBIENT_TEMPERATURE i MUSI mierzyć temperaturę otoczenia (pomieszczenia lub kabiny pojazdu) w miejscu, w którym użytkownik korzysta z urządzenia, w stopniach Celsjusza.
  • [C-1-2] MUSI być zdefiniowany jako SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] MUSI mierzyć temperaturę procesora urządzenia.
  • [C-1-4] NIE WOLNO mierzyć żadnej innej temperatury.

Pamiętaj, że typ czujnika SENSOR_TYPE_TEMPERATURE został wycofany w Androidzie 4.0.

7.3.7. Fotometr

  • Urządzenia MOGĄ zawierać fotometr (czujnik światła otoczenia).

7.3.8. Czujnik zbliżeniowy

  • Urządzenia MOGĄ zawierać czujnik zbliżeniowy.

Jeśli implementacje urządzeń obejmują czujnik zbliżeniowy:

  • [C-1-1] MUSI mierzyć odległość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI być zorientowany w taki sposób, aby wykrywać obiekty znajdujące się blisko ekranu, ponieważ jego głównym zadaniem jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacje urządzenia zawierają czujnik zbliżeniowy w dowolnej innej orientacji, NIE MOŻE on być dostępny za pomocą tego interfejsu API.
  • [C-1-2] MUSI mieć dokładność co najmniej 1 bit.

7.3.9. Czujniki o wysokiej wierności

Jeśli implementacje urządzeń obejmują zestaw czujników wyższej jakości zdefiniowanych w tej sekcji i udostępniają je aplikacjom innych firm:

  • [C-1-1] MUSI identyfikować funkcję za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

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

  • [C-2-1] MUSI mieć czujnik TYPE_ACCELEROMETER, który:

    • MUSI mieć zakres pomiarowy co najmniej od -8 g do +8 g, POWINIEN mieć zakres pomiarowy co najmniej od -16 g do +16 g.
    • MUSI mieć rozdzielczość pomiaru co najmniej 2048 LSB/g.
    • MUSI mieć minimalną częstotliwość pomiaru wynoszącą 12,5 Hz lub mniej.
    • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz; POWINIEN obsługiwać SensorDirectChannel RATE_VERY_FAST.
    • MUSI mieć szum pomiarowy nie większy niż 400 μg/√Hz.
    • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z możliwością buforowania co najmniej 3000 zdarzeń.
    • MUSI mieć zużycie energii w przypadku przetwarzania wsadowego nie większe niż 3 mW.
    • [C-SR] Zdecydowanie zaleca się, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a w tym paśmie znajdowało się widmo szumu białego.
    • POWINIEN mieć losowy błąd przyspieszenia mniejszy niż 30 μg √Hz testowany w temperaturze pokojowej.
    • POWINIEN mieć zmianę odchylenia w stosunku do temperatury ≤ +/- 1 mg/°C.
    • POWINIEN mieć nieliniowość linii dopasowania ≤ 0,5% i zmianę czułości w stosunku do temperatury ≤ 0,03%/°C.
    • POWINIEN mieć czułość w kierunku osi poprzecznej < 2,5 % i zmienność czułości w kierunku osi poprzecznej < 0,2% w zakresie temperatury pracy urządzenia.

  • [C-2-2] MUSI mieć TYPE_ACCELEROMETER_UNCALIBRATED o takich samych wymaganiach dotyczących jakości jak TYPE_ACCELEROMETER.

  • [C-2-3] MUSI mieć czujnik TYPE_GYROSCOPE, który:

    • MUSI mieć zakres pomiarowy co najmniej od -1000 do +1000 dps.
    • MUSI mieć rozdzielczość pomiaru co najmniej 16 LSB/dps.
    • MUSI mieć minimalną częstotliwość pomiaru wynoszącą 12,5 Hz lub mniej.
    • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz; POWINIEN obsługiwać SensorDirectChannel RATE_VERY_FAST.
    • MUSI mieć szum pomiarowy nie większy niż 0,014°/s/√Hz.
    • [C-SR] Zdecydowanie zaleca się, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a w tym paśmie znajdowało się widmo szumu białego.
    • POWINIEN mieć błąd losowy szybkości mniejszy niż 0,001°/s √Hz testowany w temperaturze pokojowej.
    • POWINIEN mieć zmianę odchylenia w stosunku do temperatury ≤ +/- 0,05°/ s / °C.
    • POWINIEN mieć zmianę czułości w stosunku do temperatury ≤ 0,02% / °C.
    • POWINIEN mieć nieliniowość linii najlepszego dopasowania ≤ 0,2%.
    • POWINIEN mieć gęstość szumu ≤ 0,007°/s/√Hz.
    • Gdy urządzenie jest nieruchome, błąd kalibracji powinien być mniejszy niż 0,002 rad/s w zakresie temperatur 10–40°C.
    • POWINIEN mieć czułość na przyspieszenie grawitacyjne mniejszą niż 0,1°/s/g.
    • POWINIEN mieć czułość w kierunku poprzecznym < 4,0 % i zmienność czułości w kierunku poprzecznym < 0,3% w zakresie temperatury pracy urządzenia.

  • [C-2-4] MUSI mieć TYPE_GYROSCOPE_UNCALIBRATED o takich samych wymaganiach dotyczących jakości jak TYPE_GYROSCOPE.

  • [C-2-5] MUSI mieć czujnik TYPE_GEOMAGNETIC_FIELD, który:

    • MUSI mieć zakres pomiarowy co najmniej od -900 μT do +900 μT.
    • MUSI mieć rozdzielczość pomiaru co najmniej 5 LSB/uT.
    • Musi mieć minimalną częstotliwość pomiaru wynoszącą 5 Hz lub mniej.
    • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 50 Hz.
    • MUSI mieć szum pomiarowy nieprzekraczający 0,5 uT.

  • [C-2-6] MUSI mieć TYPE_MAGNETIC_FIELD_UNCALIBRATED o takich samych wymaganiach dotyczących jakości jak TYPE_GEOMAGNETIC_FIELD, a dodatkowo:

    • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z możliwością buforowania co najmniej 600 zdarzeń.
    • [C-SR] Zdecydowanie zaleca się, aby przy częstotliwości raportowania wynoszącej 50 Hz lub więcej szum biały miał spektrum od 1 Hz do co najmniej 10 Hz.

  • [C-2-7] MUSI mieć czujnik TYPE_PRESSURE, który:

    • MUSI mieć zakres pomiarowy co najmniej od 300 hPa do 1100 hPa.
    • MUSI mieć rozdzielczość pomiaru co najmniej 80 LSB/hPa.
    • Musi mieć minimalną częstotliwość pomiaru wynoszącą 1 Hz lub mniej.
    • MUSI mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 10 Hz.
    • MUSI mieć szum pomiarowy nie większy niż 2 Pa/√Hz.
    • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z możliwością buforowania co najmniej 300 zdarzeń.
    • Musi mieć zużycie energii w trybie przetwarzania wsadowego nie większe niż 2 mW.
  • [C-2-8] MUSI mieć czujnik TYPE_GAME_ROTATION_VECTOR, który:
    • MUSI implementować wersję tego czujnika, która nie wybudza urządzenia, z możliwością buforowania co najmniej 300 zdarzeń.
    • Musi mieć zużycie energii w trybie wsadowym nie większe niż 4 mW.
  • [C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:
    • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest nieruchome, i 1,5 mW, gdy urządzenie jest w ruchu.
  • [C-2-10] MUSI mieć czujnik TYPE_STEP_DETECTOR, który:
    • MUSI implementować ten czujnik w wersji bez wybudzania z możliwością buforowania co najmniej 100 zdarzeń.
    • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest nieruchome, i 1,5 mW, gdy urządzenie jest w ruchu.
    • Musi mieć zużycie energii w trybie wsadowym nie większe niż 4 mW.
  • [C-2-11] MUSI mieć czujnik TYPE_STEP_COUNTER, który:
    • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest nieruchome, i 1,5 mW, gdy urządzenie jest w ruchu.
  • [C-2-12] MUSI mieć czujnik TILT_DETECTOR, który:
    • MUSI mieć zużycie energii nie większe niż 0,5 mW, gdy urządzenie jest nieruchome, i 1,5 mW, gdy urządzenie jest w ruchu.
  • [C-2-13] Sygnatura czasowa zdarzenia tego samego zdarzenia fizycznego zgłaszanego przez akcelerometr, żyroskop i magnetometr MUSI różnić się od siebie o nie więcej niż 2, 5 milisekundy. Znacznik czasu zdarzenia tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr i żyroskop POWINIEN różnić się od siebie o nie więcej niż 0,25 milisekundy.
  • [C-2-14] MUSI mieć sygnatury czasowe zdarzeń z żyroskopu na tej samej podstawie czasu co podsystem aparatu i z błędem nie większym niż 1 milisekunda.
  • [C-2-15] MUSI dostarczać próbki do aplikacji w ciągu 5 milisekund od momentu, w którym dane są dostępne w aplikacji z dowolnego z wymienionych powyżej czujników fizycznych.
  • [C-2-16] NIE MOŻE mieć poboru mocy większego niż 0,5 mW, gdy urządzenie jest nieruchome, i 2,0 mW, gdy urządzenie jest w ruchu, przy włączonej dowolnej kombinacji tych czujników:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] MOŻE mieć czujnik TYPE_PROXIMITY, ale jeśli jest obecny, MUSI mieć minimalną pojemność bufora wynoszącą 100 zdarzeń z czujnika.

Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje ona moc pobieraną przez cały łańcuch czujników – czujnik, wszelkie obwody pomocnicze, dedykowany system przetwarzania danych z czujników itp.

Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników:

  • [C-3-1] MUSI prawidłowo deklarować obsługę typów kanałów bezpośrednich i poziomów bezpośrednich stawek raportowania za pomocą interfejsów API isDirectChannelTypeSupported i getHighestDirectReportRateLevel.
  • [C-3-2] MUSI obsługiwać co najmniej 1 z 2 typów kanałów bezpośrednich czujnika w przypadku wszystkich czujników, które deklarują obsługę kanału bezpośredniego czujnika.
  • POWINIEN obsługiwać raportowanie zdarzeń za pomocą bezpośredniego kanału czujnika w przypadku głównego czujnika (wersja bez wybudzania) tych typów:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Czujniki biometryczne

7.3.10.1. Czytniki linii papilarnych

Jeśli implementacje urządzeń obejmują bezpieczny ekran blokady:

  • POWINIEN zawierać czytnik linii papilarnych.

Jeśli urządzenia są wyposażone w czytnik linii papilarnych i udostępniają go aplikacjom innych firm:

  • [C-1-1] MUSI deklarować obsługę funkcji android.hardware.fingerprint.
  • [C-1-2] MUSI w pełni implementować odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK.
  • [C-1-3] MUSI mieć odsetek fałszywych akceptacji nie wyższy niż 0,002%.
  • [SR] Zdecydowanie zalecamy, aby współczynnik akceptacji fałszywych tożsamości i podszywania się pod inne osoby nie przekraczał 7%.
  • [C-1-4] MUSI informować, że ten tryb może być mniej bezpieczny niż silny kod PIN, wzór lub hasło, i wyraźnie wymieniać zagrożenia związane z jego włączeniem, jeśli odsetek akceptacji fałszywych tożsamości i podszywania się jest wyższy niż 7%.
  • [C-1-5] MUSI ograniczać liczbę prób weryfikacji odcisku palca przez co najmniej 30 sekund po 5 nieudanych próbach.
  • [C-1-6] MUSI mieć implementację magazynu kluczy opartego na sprzęcie i przeprowadzać dopasowywanie odcisków palców w zaufanym środowisku wykonawczym (TEE) lub na układzie z bezpiecznym kanałem do TEE.
  • [C-1-7] MUSI mieć wszystkie dane odcisków palców umożliwiające identyfikację zaszyfrowane i uwierzytelnione kryptograficznie w taki sposób, aby nie można było ich uzyskać, odczytać ani zmienić poza środowiskiem TEE lub układem z bezpiecznym kanałem do środowiska TEE, zgodnie z dokumentacją w wytycznych dotyczących implementacji na stronie projektu Android Open Source.
  • [C-1-8] MUSI uniemożliwiać dodawanie odcisku palca bez wcześniejszego utworzenia łańcucha zaufania przez potwierdzenie przez użytkownika istniejących lub dodanie nowych danych logowania na urządzeniu (PIN, wzór, hasło) zabezpieczonych przez TEE. Implementacja w projekcie Android Open Source Project udostępnia mechanizm, który to umożliwia.
  • [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_FINGERPRINT.
  • [C-1-11] MUSI po aktualizacji z wersji starszej niż Android 6.0 bezpiecznie przenieść dane odcisku palca, aby spełnić powyższe wymagania, lub usunąć te dane.
  • [C-1-12] MUSI całkowicie usuwać wszystkie dane odcisków palców umożliwiające identyfikację użytkownika, gdy jego konto zostanie usunięte (w tym w wyniku przywrócenia urządzenia do ustawień fabrycznych).
  • [C-1-13] NIE MOŻE zezwalać na niezaszyfrowany dostęp do danych odcisków palców umożliwiających identyfikację ani do żadnych danych z nich pochodzących (np. osadzeń) w procesorze aplikacji.
  • [SR] Zdecydowanie zaleca się, aby wskaźnik fałszywych odrzuceń wynosił mniej niż 10% – pomiarów należy dokonywać na urządzeniu.
  • [SR] Zdecydowanie zaleca się, aby opóźnienie w przypadku jednego zarejestrowanego palca było mniejsze niż 1 sekunda, mierzone od momentu dotknięcia czytnika linii papilarnych do odblokowania ekranu.
  • POWINNA używać ikony odcisku palca na Androida udostępnionej w projekcie Android Open Source.
7.3.10.2. Inne czujniki biometryczne

Jeśli implementacje urządzeń zawierają co najmniej 1 czujnik biometryczny inny niż czytnik linii papilarnych i udostępniają go aplikacjom innych firm:

  • [C-1-1] MUSI mieć odsetek fałszywych akceptacji nie większy niż 0,002%.
  • [C-SR] Zdecydowanie zalecamy, aby współczynnik akceptacji fałszywych i podszywających się tożsamości nie przekraczał 7%.
  • [C-1-2] MUSI informować, że ten tryb może być mniej bezpieczny niż silny kod PIN, wzór lub hasło, i wyraźnie wymieniać zagrożenia związane z jego włączeniem, jeśli wskaźniki akceptacji fałszywych tożsamości i podszywania się są wyższe niż 7%.
  • [C-1-3] MUSI ograniczać liczbę prób przez co najmniej 30 sekund po 5 nieudanych próbach weryfikacji biometrycznej – nieudana próba to próba o odpowiedniej jakości rejestracji (ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.
  • [C-1-4] MUSI mieć implementację magazynu kluczy opartego na sprzęcie i przeprowadzać dopasowywanie biometryczne w TEE lub na układzie z bezpiecznym kanałem do TEE.
  • [C-1-5] MUSI mieć wszystkie dane umożliwiające identyfikację zaszyfrowane i uwierzytelnione kryptograficznie w taki sposób, aby nie można było ich uzyskać, odczytać ani zmienić poza środowiskiem TEE lub układem z bezpiecznym kanałem do środowiska TEE, zgodnie z dokumentacją w wytycznych dotyczących implementacji na stronie projektu Android Open Source.
  • [C-1-6] MUSI uniemożliwiać dodawanie nowych danych biometrycznych bez wcześniejszego utworzenia łańcucha zaufania przez potwierdzenie przez użytkownika istniejących lub dodanie nowych danych logowania na urządzeniu (PIN, wzór, hasło) zabezpieczonych przez TEE. Implementacja w ramach projektu Android Open Source Project udostępnia mechanizm, który to umożliwia.
  • [C-1-7] NIE MOŻE umożliwiać aplikacjom innych firm rozróżniania rejestracji biometrycznych.
  • [C-1-8] MUSI uwzględniać indywidualną flagę dla danego biometru (np. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE lub DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
  • [C-1-9] MUSI całkowicie usuwać wszystkie dane biometryczne umożliwiające identyfikację użytkownika, gdy jego konto zostanie usunięte (w tym w wyniku przywrócenia urządzenia do ustawień fabrycznych).
  • [C-1-10] NIE MOŻE zezwalać na niezaszyfrowany dostęp do danych biometrycznych umożliwiających identyfikację lub do danych z nich pochodzących (np. osadzonych) w procesorze aplikacji poza kontekstem TEE.
  • [C-SR] Zdecydowanie zaleca się, aby wskaźnik fałszywych odrzuceń mierzony na urządzeniu był mniejszy niż 10%.
  • [C-SR] Zdecydowanie zaleca się, aby w przypadku każdego zarejestrowanego elementu biometrycznego opóźnienie od momentu wykrycia elementu biometrycznego do odblokowania ekranu było mniejsze niż 1 sekunda.

7.3.11. Czujniki dostępne tylko w Androidzie Automotive

Czujniki samochodowe są zdefiniowane w android.car.CarSensorManager API.

7.3.11.1. Obecny sprzęt

Wymagania dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.5.1.

7.3.11.2. Tryb dzienny/nocny

Wymagania dotyczące poszczególnych urządzeń 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 dotyczące poszczególnych urządzeń znajdziesz w sekcji 2.5.1.

7.3.11.5. Hamulec postojowy

Wymagania dotyczące poszczególnych urządzeń 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 6 stopniami swobody:

  • [C-1-1] MUSI implementować i zgłaszać czujnik TYPE_POSE_6DOF.
  • [C-1-2] MUSI być dokładniejszy niż sam wektor rotacji.

7.4. Łączność danych

7.4.1. Połączenia telefoniczne

Termin „telefonia” używany w interfejsach API Androida i w tym dokumencie odnosi się konkretnie do sprzętu związanego z wykonywaniem połączeń głosowych i wysyłaniem SMS-ów w sieci GSM lub CDMA. Chociaż połączenia głosowe mogą być lub nie być przełączane pakietowo, na potrzeby Androida są one traktowane jako niezależne od połączenia do transmisji danych, które może być realizowane w tej samej sieci. Innymi słowy, funkcje i interfejsy API „telefonia” na Androidzie odnoszą się konkretnie do połączeń głosowych i SMS-ów. Na przykład urządzenia, które nie mogą wykonywać połączeń ani wysyłać i odbierać SMS-ów, nie są uważane za urządzenia telefoniczne, niezależnie od tego, czy korzystają z sieci komórkowej do transmisji danych.

  • Systemu Android MOŻNA używać na urządzeniach, które nie mają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami innymi niż telefony.

Jeśli implementacje urządzeń obejmują telefonię GSM lub CDMA:

  • [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.telephony i inne flagi podrzędnych funkcji zgodnie z technologią.
  • [C-1-2] MUSI wdrożyć pełną obsługę interfejsu API dla tej technologii.

Jeśli implementacje urządzeń nie obejmują sprzętu telefonicznego:

  • [C-2-1] MUSI zaimplementować pełne interfejsy API jako operacje bez efektu.
7.4.1.1. Zgodność z blokowaniem numerów

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

  • [C-1-1] MUSI obsługiwać blokowanie numerów
  • [C-1-2] MUSI w pełni implementować BlockedNumberContract i odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu SDK.
  • [C-1-3] MUSI blokować wszystkie połączenia i wiadomości z numeru telefonu w „BlockedNumberProvider” bez interakcji z aplikacjami. Jedynym wyjątkiem jest sytuacja, gdy blokowanie numerów zostanie tymczasowo zniesione w sposób opisany w dokumentacji pakietu SDK.
  • [C-1-4] NIE MOŻE zapisywać informacji w rejestrze połączeń platformy w przypadku zablokowanego połączenia.
  • [C-1-5] NIE MOŻE wysyłać do operatora telefonicznego informacji o zablokowanej wiadomości.
  • [C-1-6] MUSI implementować interfejs zarządzania zablokowanymi numerami, który jest otwierany za pomocą intencji zwracanej przez metodę TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] NIE MOŻE zezwalać użytkownikom dodatkowym na wyświetlanie ani edytowanie zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że użytkownik podstawowy ma pełną kontrolę nad usługami telefonicznymi (jedną instancją) na urządzeniu. Wszystkie elementy interfejsu związane z blokowaniem MUSZĄ być ukryte dla użytkowników dodatkowych, a lista zablokowanych MUSI być nadal uwzględniana.
  • POWINNY przenosić zablokowane numery do dostawcy, gdy urządzenie zostanie zaktualizowane do Androida 7.0.
7.4.1.2. Telecom API

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

  • [C-1-1] MUSI obsługiwać interfejsy API ConnectionService opisane w pakiecie SDK.
  • [C-1-2] MUSI wyświetlać nowe połączenie przychodzące i umożliwiać użytkownikowi zaakceptowanie lub odrzucenie połączenia przychodzącego, gdy użytkownik prowadzi połączenie zainicjowane przez aplikację innej firmy, która nie obsługuje funkcji wstrzymania określonej za pomocą CAPABILITY_SUPPORT_HOLD.

  • [C-SR] ZDECYDOWANIE ZALECA się powiadamianie użytkownika, że odebranie połączenia przychodzącego spowoduje zakończenie trwającego połączenia.

    Implementacja AOSP spełnia te wymagania dzięki powiadomieniu, które informuje użytkownika, że odebranie połączenia przychodzącego spowoduje rozłączenie innego połączenia.

  • [C-SR] ZDECYDOWANIE ZALECA się wstępne wczytywanie domyślnej aplikacji do wybierania numerów, która wyświetla wpis w historii połączeń i nazwę aplikacji innej firmy w swojej historii połączeń, gdy aplikacja innej firmy ustawia klucz dodatkowy EXTRA_LOG_SELF_MANAGED_CALLS w swoim elemencie PhoneAccount na wartość true.

  • [C-SR] Zdecydowanie zaleca się obsługę zdarzeń KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK słuchawek audio w przypadku interfejsów API android.telecom w sposób opisany poniżej:
    • Wywołaj Connection.onDisconnect(), gdy podczas trwającej rozmowy zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia.
    • Wywołaj Connection.onAnswer(), gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie klawisza.
    • Wywołaj Connection.onReject(), gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia.
    • Przełącz stan wyciszenia CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementacje na urządzeniach:

  • POWINIEN obsługiwać co najmniej jeden standard 802.11.

Jeśli implementacje urządzeń obsługują standard 802.11 i udostępniają tę funkcję aplikacji innej firmy:

  • [C-1-1] MUSI implementować odpowiedni interfejs API Androida.
  • [C-1-2] MUSI raportować flagę funkcji sprzętowej android.hardware.wifi.
  • [C-1-3] MUSI implementować interfejs API multiemisji zgodnie z opisem w dokumentacji pakietu SDK.
  • [C-1-4] MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) w żadnym momencie działania, w tym:
    • Nawet wtedy, gdy ekran nie jest aktywny.
    • W przypadku urządzeń z Androidem TV, nawet w trybie gotowości.
  • [C-1-5] NIE WOLNO traktować wywołania metody interfejsu API WifiManager.enableNetwork() jako wystarczającej wskazówki do przełączenia aktualnie aktywnego Network, który jest domyślnie używany w przypadku ruchu aplikacji i jest zwracany przez metody interfejsu API ConnectivityManager, takie jak getActiveNetwork i registerDefaultNetworkCallback. Innymi słowy, mogą one WYŁĄCZYĆ dostęp do internetu zapewniany przez innego dostawcę sieci (np. mobilną transmisję danych) TYLKO wtedy, gdy potwierdzą, że sieć Wi-Fi zapewnia dostęp do internetu.
  • [C-SR] Zdecydowanie zaleca się, aby po wywołaniu metody interfejsu API ConnectivityManager.reportNetworkConnectivity() ponownie ocenić dostęp do internetu na urządzeniu Network i gdy ocena wykaże, że bieżące urządzenie Network nie zapewnia już dostępu do internetu, przełączyć się na dowolną inną dostępną sieć (np. dane komórkowe), która zapewnia dostęp do internetu.
  • [C-SR] ZDECYDOWANIE ZALECA się losowanie źródłowego adresu MAC i numeru sekwencyjnego ramek żądania sondy raz na początku każdego skanowania, gdy stacja jest odłączona.
    • Każda grupa ramek żądania sondowania składająca się na jeden skan powinna używać jednego spójnego adresu MAC (NIE należy randomizować adresu MAC w połowie skanowania).
    • Numer sekwencyjny żądania sondy powinien być normalnie (sekwencyjnie) zwiększany między żądaniami sondy w skanowaniu.
    • Numer sekwencyjny żądania sondowania powinien być losowy pomiędzy ostatnim żądaniem sondowania w skanowaniu a pierwszym żądaniem sondowania w następnym skanowaniu.
  • [C-SR] są ZDECYDOWANIE ZALECANE, gdy STA jest odłączony, aby zezwalać w ramkach żądań sondowania tylko na te elementy:
    • Zestaw parametrów SSID (0)
    • DS Parameter Set (3)

Jeśli urządzenia obsługują Wi-Fi i używają tej sieci do skanowania lokalizacji:

  • [C-2-1] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania odczytu wartości za pomocą metody interfejsu API WifiManager.isScanAlwaysAvailable.
7.4.2.1. Wi-Fi Direct

Implementacje na urządzeniach:

  • POWINNO obejmować obsługę Wi-Fi Direct (Wi-Fi peer-to-peer).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Direct:

  • [C-1-1] MUSI implementować odpowiedni interfejs API Androida zgodnie z opisem w dokumentacji pakietu SDK.
  • [C-1-2] MUSI raportować funkcję sprzętową android.hardware.wifi.direct.
  • [C-1-3] MUSI obsługiwać standardowe działanie Wi-Fi.
  • [C-1-4] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Direct.

Implementacje na urządzeniach:

Jeśli implementacje urządzeń obejmują obsługę TDLS, a TDLS jest włączony przez interfejs WiFiManager API:

  • [C-1-1] MUSI deklarować obsługę TDLS za pomocą WifiManager.isTdlsSupported.
  • TDLS należy używać tylko wtedy, gdy jest to możliwe I korzystne.
  • POWINNO mieć pewne heurystyki i NIE używać TDLS, gdy jego wydajność może być gorsza niż w przypadku połączenia przez punkt dostępu Wi-Fi.
7.4.2.3. Wi-Fi Aware

Implementacje na urządzeniach:

Jeśli implementacje urządzeń obsługują Wi-Fi Aware i udostępniają tę funkcję aplikacjom innych firm, to:

  • [C-1-1] MUSI implementować interfejsy API WifiAwareManager zgodnie z opisem w dokumentacji pakietu SDK.
  • [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.aware.
  • [C-1-3] MUSI obsługiwać jednocześnie operacje Wi-Fi i Wi-Fi Aware.
  • [C-1-4] MUSI losowo zmieniać adres interfejsu zarządzania Wi-Fi Aware w interwałach nie dłuższych niż 30 minut i za każdym razem, gdy włączona jest funkcja Wi-Fi Aware.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i lokalizacji Wi-Fi zgodnie z opisem w sekcji 7.4.2.5 i udostępniają te funkcje aplikacjom innych firm, to:

7.4.2.4. Wi-Fi Passpoint

Implementacje na urządzeniach:

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Passpoint:

  • [C-1-1] MUSI implementować interfejsy API związane z Passpointem WifiManager zgodnie z opisem w dokumentacji pakietu SDK.
  • [C-1-2] MUSI obsługiwać standard IEEE 802.11u, w szczególności w zakresie wykrywania i wybierania sieci, np. protokoły GAS (Generic Advertisement Service) i ANQP (Access Network Query Protocol).

Jeśli implementacje urządzeń nie obejmują obsługi Wi-Fi Passpoint:

  • [C-2-1] Implementacja interfejsów API związanych z Passpoint WifiManager MUSI zgłaszać wyjątek UnsupportedOperationException.
7.4.2.5. Lokalizacja Wi-Fi (czas błądzenia Wi-Fi – RTT)

Implementacje na urządzeniach:

Jeśli implementacje urządzeń obsługują lokalizację Wi-Fi i udostępniają tę funkcję aplikacjom innych firm, to:

  • [C-1-1] MUSI implementować interfejsy API WifiRttManager zgodnie z opisem w dokumentacji pakietu SDK.
  • [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.rtt.
  • [C-1-3] MUSI losowo generować źródłowy adres MAC dla każdego pakietu RTT wykonywanego, gdy interfejs Wi-Fi, na którym jest wykonywany RTT, nie jest powiązany z punktem dostępu.

7.4.3. Bluetooth

Jeśli implementacje urządzeń obsługują profil audio Bluetooth:

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

Jeśli implementacje urządzeń obsługują profile HFP, A2DP i AVRCP, to:

  • POWINNO obsługiwać co najmniej 5 połączonych urządzeń.

Jeśli implementacje urządzeń deklarują funkcję android.hardware.vr.high_performance:

  • [C-1-1] MUSI obsługiwać Bluetooth 4.2 i rozszerzenie długości danych Bluetooth LE.

Android obsługuje Bluetooth i Bluetooth Low Energy.

Jeśli urządzenia obsługują Bluetooth i Bluetooth Low Energy:

  • [C-2-1] MUSI zadeklarować odpowiednie funkcje platformy (android.hardware.bluetooth i android.hardware.bluetooth_le) oraz zaimplementować interfejsy API platformy.
  • POWINNO implementować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX, HFP itp., w zależności od urządzenia.

Jeśli urządzenia obsługują Bluetooth Low Energy:

  • [C-3-1] MUSI zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
  • [C-3-2] MUSI włączyć interfejsy API Bluetooth oparte na GATT (generic attribute profile) zgodnie z opisem w dokumentacji pakietu SDK i android.bluetooth.
  • [C-3-3] MUSI zgłaszać prawidłową wartość parametru BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy zaimplementowano logikę filtrowania klas interfejsu API ScanFilter.
  • [C-3-4] MUSI zgłaszać prawidłową wartość atrybutu BluetoothAdapter.isMultipleAdvertisementSupported(), aby wskazać, czy reklamy o niskim zużyciu energii są obsługiwane.
  • W przypadku implementacji interfejsu ScanFilter API powinien obsługiwać przenoszenie logiki filtrowania do chipsetu Bluetooth.
  • POWINIEN obsługiwać przenoszenie skanowania wsadowego do chipsetu Bluetooth.

  • POWINIEN obsługiwać wiele reklam z co najmniej 4 slotami.

  • [SR] Zdecydowanie zalecamy wdrożenie limitu czasu dla adresu prywatnego z możliwością rozwiązania (RPA) nie dłuższego niż 15 minut i rotację adresu po upływie limitu czasu w celu ochrony prywatności użytkownika.

Jeśli urządzenia obsługują Bluetooth LE i używają go do skanowania lokalizacji:

  • [C-4-1] MUSI udostępniać użytkownikowi możliwość włączania i wyłączania odczytu wartości za pomocą interfejsu System API BluetoothAdapter.isBleScanAlwaysAvailable().

7.4.4. Komunikacja bliskiego pola

Implementacje na urządzeniach:

  • POWINIEN zawierać nadajnik-odbiornik i powiązany sprzęt do komunikacji Near Field Communication (NFC).
  • [C-0-1] MUSI implementować interfejsy API android.nfc.NdefMessage i android.nfc.NdefRecord, nawet jeśli nie obsługują one NFC lub nie deklarują funkcji android.hardware.nfc, ponieważ klasy reprezentują format reprezentacji danych niezależny od protokołu.

Jeśli implementacje urządzeń zawierają sprzęt NFC i mają być udostępniane aplikacjom innych firm:

  • [C-1-1] MUSI zgłaszać funkcję android.hardware.nfc z android.content.pm.PackageManager.hasSystemFeature() metody.
  • MUSI umożliwiać odczytywanie i zapisywanie wiadomości NDEF za pomocą tych standardów NFC:
  • [C-1-2] MUSI być w stanie działać jako czytnik/zapisywarka NFC Forum (zgodnie ze specyfikacją techniczną NFC Forum NFCForum-TS-DigitalProtocol-1.0) w ramach tych standardów NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NFC-F (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Typy tagów NFC Forum 1, 2, 3, 4, 5 (zdefiniowane przez NFC Forum)

  • [SR] ZDECYDOWANIE ZALECANE jest, aby urządzenie obsługiwało odczyt i zapis wiadomości NDEF oraz surowych danych zgodnie z tymi standardami NFC: Pamiętaj, że chociaż standardy NFC są ZDECYDOWANIE ZALECANE, w przyszłej wersji definicji zgodności planujemy zmienić je na WYMAGANE. W tej wersji te standardy są opcjonalne, ale w przyszłych wersjach będą wymagane. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z tą wersją Androida spełniały te wymagania już teraz, aby można było je zaktualizować do przyszłych wersji platformy.

  • [C-1-3] MUSI mieć możliwość przesyłania i odbierania danych za pomocą tych standardów i protokołów peer-to-peer:

    • ISO 18092
    • LLCP 1.2 (zdefiniowany przez NFC Forum)
    • SDP 1.0 (zdefiniowany przez NFC Forum)
    • NDEF Push Protocol
    • SNEP 1.0 (zdefiniowany przez NFC Forum)
  • [C-1-4] MUSI obsługiwać Androida Beam i POWINIEN domyślnie włączać Androida Beam.
  • [C-1-5] MUSI mieć możliwość wysyłania i odbierania danych za pomocą Androida Beam, gdy ta funkcja jest włączona lub gdy włączony jest inny tryb NFC P2P.
  • [C-1-6] MUSI implementować domyślny serwer SNEP. Prawidłowe wiadomości NDEF odebrane przez domyślny serwer SNEP MUSZĄ być przekazywane do aplikacji za pomocą intencji android.nfc.ACTION_NDEF_DISCOVERED. Wyłączenie Androida Beam w ustawieniach NIE MOŻE powodować wyłączenia wysyłania przychodzących wiadomości NDEF.
  • [C-1-7] MUSI uwzględniać intencję android.settings.NFCSHARING_SETTINGS wyświetlania ustawień udostępniania NFC.
  • [C-1-8] MUSI implementować serwer NPP. Wiadomości otrzymane przez serwer NPP MUSZĄ być przetwarzane w taki sam sposób jak domyślny serwer SNEP.
  • [C-1-9] MUSI implementować klienta SNEP i próbować wysyłać wychodzące dane NDEF P2P do domyślnego serwera SNEP, gdy funkcja Android Beam jest włączona. Jeśli nie zostanie znaleziony domyślny serwer SNEP, klient MUSI spróbować wysłać dane do serwera NPP.
  • [C-1-10] MUSI zezwalać na ustawianie wychodzącej wiadomości NDEF P2P przez działania na pierwszym planie za pomocą android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback i android.nfc.NfcAdapter.enableForegroundNdefPush.
  • POWINIEN używać gestu lub potwierdzenia na ekranie, np. „Dotknij, aby przesłać”, przed wysłaniem wychodzących wiadomości NDEF P2P.
  • [C-1-11] MUSI obsługiwać przekazywanie połączenia NFC do Bluetootha, jeśli urządzenie obsługuje profil Bluetooth Object Push Profile.
  • [C-1-12] MUSI obsługiwać przekazywanie połączenia do Bluetooth podczas korzystania z android.nfc.NfcAdapter.setBeamPushUris, poprzez wdrożenie specyfikacji „Connection Handover version 1.2” i „Bluetooth Secure Simple Pairing Using NFC version 1.0” z NFC Forum. Taka implementacja MUSI implementować usługę przekazywania LLCP o nazwie „urn:nfc:sn:handover” do wymiany rekordów żądania/wyboru przekazywania przez NFC i MUSI używać profilu Bluetooth Object Push do rzeczywistego transferu danych przez Bluetooth. Ze względu na starsze wersje (aby zachować zgodność z urządzeniami z Androidem 4.1) implementacja POWINNA nadal akceptować żądania SNEP GET dotyczące wymiany żądania przekazania/wybranych rekordów przez NFC. Jednak sama implementacja NIE POWINNA wysyłać żądań SNEP GET w celu przekazania połączenia.
  • [C-1-13] MUSI odpytywać wszystkie obsługiwane technologie w trybie wykrywania NFC.
  • POWINNO być w trybie wykrywania NFC, gdy urządzenie jest włączone, ekran jest aktywny, a ekran blokady jest odblokowany.
  • POWINNA być w stanie odczytać kod kreskowy i adres URL (jeśli jest zakodowany) produktów Thinfilm NFC Barcode.

Pamiętaj, że w przypadku wymienionych powyżej specyfikacji JIS, ISO i NFC Forum nie są dostępne publicznie linki.

Android obsługuje tryb emulacji karty hosta (HCE) NFC.

Jeśli implementacje urządzeń obejmują chipset kontrolera NFC obsługujący HCE (w przypadku NfcA lub NfcB) i routing identyfikatora aplikacji (AID), muszą:

  • [C-2-1] MUSI zgłaszać stałą funkcji android.hardware.nfc.hce.
  • [C-2-2] MUSI obsługiwać interfejsy NFC HCE API zdefiniowane w pakiecie Android SDK.

Jeśli implementacje urządzeń zawierają chipset kontrolera NFC obsługujący HCE dla NfcF i wdrażają tę funkcję w aplikacjach innych firm:

Jeśli implementacje urządzeń obejmują ogólną obsługę NFC opisaną w tej sekcji i obsługują technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF na MIFARE Classic) w roli czytnika/zapisywarki:

  • [C-4-1] MUSI implementować odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
  • [C-4-2] MUSI zgłaszać funkcję com.nxp.mifare z metody android.content.pm.PackageManager.hasSystemFeature(). Pamiętaj, że nie jest to standardowa funkcja Androida, dlatego nie występuje jako stała w klasie android.content.pm.PackageManager.

7.4.5. Minimalna funkcjonalność sieci

Implementacje na urządzeniach:

  • [C-0-1] MUSI obsługiwać co najmniej 1 formę sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o przepustowości co najmniej 200 kbit/s. Przykłady technologii spełniających to wymaganie to EDGE, HSPA, EV-DO, 802.11g, Ethernet i Bluetooth PAN.
  • Powinno też obsługiwać co najmniej jeden popularny standard bezprzewodowej transmisji danych, np. 802.11 (Wi-Fi), gdy podstawowym połączeniem do transmisji danych jest fizyczny standard sieciowy (np. Ethernet).
  • MOŻE obsługiwać więcej niż 1 rodzaj połączenia do transmisji danych.
  • [C-0-2] MUSI zawierać stos sieciowy IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection, oraz natywnych interfejsów API, takich jak gniazda AF_INET6.
  • [C-0-3] MUSI domyślnie włączać protokół IPv6.
  • MUSI zapewnić, że komunikacja IPv6 jest tak samo niezawodna jak IPv4, np.:
    • [C-0-4] MUSI utrzymywać łączność IPv6 w trybie uśpienia.
    • [C-0-5] Ograniczanie szybkości NIE MOŻE powodować utraty łączności IPv6 na żadnej sieci zgodnej z IPv6, która używa czasu życia RA wynoszącego co najmniej 180 sekund.
  • [C-0-6] MUSI zapewniać aplikacjom innych firm bezpośrednie połączenie z siecią IPv6, gdy urządzenie jest połączone z siecią IPv6, bez żadnego tłumaczenia adresów lub portów lokalnie na urządzeniu. Zarówno interfejsy API zarządzane, takie jak Socket#getLocalAddress czy Socket#getLocalPort), jak i interfejsy NDK API, takie jak getsockname() czy IPV6_PKTINFO, MUSZĄ zwracać adres IP i port, które są faktycznie używane do wysyłania i odbierania pakietów w sieci.

Wymagany poziom obsługi IPv6 zależy od typu sieci, jak pokazują poniższe wymagania.

Jeśli urządzenia obsługują Wi-Fi:

  • [C-1-1] MUSI obsługiwać podwójny stos i działanie tylko w IPv6 w sieci Wi-Fi.

Jeśli urządzenia obsługują Ethernet, to:

  • [C-2-1] MUSI obsługiwać działanie w trybie dual-stack w sieci Ethernet.

Jeśli implementacje urządzeń obsługują komórkową transmisję danych:

  • POWINNO obsługiwać działanie IPv6 (tylko IPv6 i ewentualnie podwójny stos) w sieci komórkowej.

Jeśli implementacje urządzeń obsługują więcej niż 1 typ sieci (np. Wi-Fi i komórkowej transmisji danych):

  • [C-3-1] MUSI jednocześnie spełniać powyższe wymagania w każdej sieci, gdy urządzenie jest jednocześnie połączone z więcej niż 1 rodzajem sieci.

7.4.6. Ustawienia synchronizacji

Implementacje na urządzeniach:

  • [C-0-1] Musi mieć domyślnie włączone główne ustawienie automatycznej synchronizacji, aby metoda getMasterSyncAutomatically() zwracała wartość „true”.

7.4.7. Oszczędzanie danych

Jeśli implementacje urządzeń obejmują połączenie taryfowe, są to:

  • [SR] Zdecydowanie zalecamy udostępnienie trybu oszczędzania danych.

Jeśli implementacje urządzeń udostępniają tryb oszczędzania danych:

Jeśli implementacje urządzeń nie udostępniają trybu oszczędzania danych:

  • [C-2-1] MUSI zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED dla ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] NIE WOLNO nadawać ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] MUSI mieć aktywność, która obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻE ją zaimplementować jako operację bez efektu.

7.4.8. Secure Elements

Jeśli implementacje urządzeń obsługują Open Mobile API, które umożliwia korzystanie z bezpiecznych elementów, i udostępniają je aplikacjom innych firm:

7.5. Aparaty

Jeśli implementacje urządzeń obejmują co najmniej 1 aparat, to:

  • [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.camera.any.
  • [C-1-2] Aplikacja MUSI mieć możliwość jednoczesnego przydzielenia 3 map bitowych RGBA_8888 o rozmiarze równym rozmiarowi obrazów generowanych przez czujnik aparatu o najwyższej rozdzielczości na urządzeniu, gdy aparat jest otwarty w celu podstawowego podglądu i wykonywania zdjęć.

7.5.1. Tylny aparat

Tylny aparat to aparat znajdujący się po stronie urządzenia przeciwnej do wyświetlacza. Rejestruje on obraz sceny po drugiej stronie urządzenia, tak jak tradycyjny aparat.

Implementacje na urządzeniach:

  • POWINNO zawierać tylny aparat.

Jeśli urządzenie ma co najmniej 1 aparat skierowany do tyłu:

  • [C-1-1] MUSI zgłaszać flagę funkcji android.hardware.camera i android.hardware.camera.any.
  • [C-1-2] MUSI mieć rozdzielczość co najmniej 2 megapikseli.
  • POWINIEN mieć w sterowniku aparatu zaimplementowaną funkcję automatycznego ustawiania ostrości sprzętowego lub programowego (niewidoczną dla oprogramowania aplikacji).
  • MOŻE mieć sprzęt z stałą ostrością lub EDOF (rozszerzoną głębią ostrości).
  • MOŻE zawierać lampę błyskową.

Jeśli aparat ma lampę błyskową:

  • [C-2-1] Lampa błyskowa NIE MOŻE być włączona, gdy na powierzchni podglądu kamery zarejestrowano instancję android.hardware.Camera.PreviewCallback, chyba że aplikacja wyraźnie włączyła lampę błyskową, włączając atrybuty FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu systemowego urządzenia, ale tylko aplikacji innych firm korzystających z Camera.PreviewCallback.

7.5.2. Przedni aparat

Przedni aparat to aparat znajdujący się po tej samej stronie urządzenia co wyświetlacz. Jest on zwykle używany do rejestrowania obrazu użytkownika, np. podczas wideokonferencji i podobnych zastosowań.

Implementacje na urządzeniach:

  • MOŻE zawierać przedni aparat.

Jeśli urządzenia mają co najmniej 1 aparat przedni:

  • [C-1-1] MUSI zgłaszać flagę funkcji android.hardware.camera.any i android.hardware.camera.front.
  • [C-1-2] MUSI mieć rozdzielczość co najmniej VGA (640 x 480 pikseli).
  • [C-1-3] NIE MOŻE używać przedniego aparatu jako domyślnego w przypadku interfejsu Camera API i NIE MOŻE konfigurować interfejsu tak, aby traktował przedni aparat jako domyślny tylny aparat, nawet jeśli jest to jedyny aparat na urządzeniu.
  • [C-1-4] Podgląd z kamery MUSI być odwrócony w poziomie względem orientacji określonej przez aplikację, jeśli bieżąca aplikacja wyraźnie zażądała obrócenia wyświetlacza kamery za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation(). Natomiast podgląd MUSI być odwrócony wzdłuż domyślnej osi poziomej urządzenia, jeśli bieżąca aplikacja nie zażąda wyraźnie obrócenia ekranu aparatu za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation().
  • [C-1-5] NIE MOŻE tworzyć odbicia lustrzanego końcowego zarejestrowanego obrazu lub strumieni wideo zwracanych do wywołań zwrotnych aplikacji ani zapisywanych w pamięci multimediów.
  • [C-1-6] MUSI odzwierciedlać obraz wyświetlany przez widok po zrobieniu zdjęcia w taki sam sposób jak strumień obrazu z podglądu z kamery.
  • MOŻE zawierać funkcje (takie jak automatyczne ustawianie ostrości, lampa błyskowa itp.) dostępne w przypadku aparatów skierowanych do tyłu, zgodnie z opisem w sekcji 7.5.1.

Jeśli urządzenia można obracać (np. automatycznie za pomocą akcelerometru lub ręcznie przez użytkownika):

  • [C-2-1] Podgląd z kamery MUSI być odbity w poziomie względem bieżącej orientacji urządzenia.

7.5.3. Aparat zewnętrzny

Implementacje na urządzeniach:

  • MOŻE obejmować obsługę kamery zewnętrznej, która nie musi być zawsze podłączona.

Jeśli implementacje urządzeń obejmują obsługę kamery zewnętrznej:

  • [C-1-1] MUSI zadeklarować flagi funkcji platformy android.hardware.camera.external i android.hardware camera.any.
  • [C-1-2] MUSI obsługiwać klasę wideo USB (UVC 1.0 lub nowszą), jeśli kamera zewnętrzna łączy się przez port hosta USB.
  • [C-1-3] MUSI przejść testy CTS kamery z podłączonym fizycznym zewnętrznym urządzeniem z kamerą. Szczegółowe informacje o testowaniu kamery w ramach CTS znajdziesz na stronie source.android.com.
  • POWINNO obsługiwać kompresję wideo, np.MJPEG, aby umożliwić przesyłanie strumieni niekodowanych w wysokiej jakości (tj. strumieni obrazów surowych lub skompresowanych niezależnie).
  • MOŻE obsługiwać wiele kamer.
  • MOŻE obsługiwać kodowanie wideo oparte na kamerze.

Jeśli kodowanie wideo oparte na kamerze jest obsługiwane:

  • [C-2-1] Urządzenie MUSI mieć dostęp do równoczesnego strumienia nieskompresowanego lub MJPEG (o rozdzielczości QVGA lub wyższej).

7.5.4. Działanie interfejsu Camera API

Android zawiera 2 pakiety interfejsów API do uzyskiwania dostępu do aparatu. Nowszy interfejs android.hardware.camera2 API udostępnia aplikacji kontrolę nad aparatem na niższym poziomie, w tym wydajne przepływy zdjęć seryjnych i strumieniowania bez kopiowania oraz sterowanie ekspozycją, wzmocnieniem, wzmocnieniem balansu bieli, konwersją kolorów, odszumianiem, wyostrzaniem i innymi parametrami w przypadku każdej klatki.

Starszy pakiet interfejsu APIandroid.hardware.Camera jest oznaczony jako wycofany w Androidzie 5.0, ale powinien być nadal dostępny dla aplikacji. Implementacje urządzeń z Androidem MUSZĄ zapewniać dalszą obsługę interfejsu API zgodnie z opisem w tej sekcji i w pakiecie Android SDK.

Wszystkie funkcje wspólne dla wycofanej klasy android.hardware.Camera i nowszego pakietu android.hardware.camera2 MUSZĄ mieć równoważną wydajność i jakość w obu interfejsach API. Na przykład przy równoważnych ustawieniach szybkość i dokładność autofokusa muszą być identyczne, a jakość zarejestrowanych obrazów musi być taka sama. Funkcje, które zależą od różnych semantyk obu interfejsów API, nie muszą mieć identycznej szybkości ani jakości, ale POWINNY być jak najbardziej zbliżone.

Implementacje urządzeń MUSZĄ obsługiwać te zachowania w przypadku interfejsów API związanych z aparatem dla wszystkich dostępnych aparatów. Implementacje na urządzeniach:

  • [C-0-1] MUSI używać android.hardware.PixelFormat.YCbCr_420_SP w przypadku danych podglądu przekazywanych do wywołań zwrotnych aplikacji, gdy aplikacja nigdy nie wywołała funkcji android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] MUSI być w formacie kodowania NV21, gdy aplikacja rejestruje instancję android.hardware.Camera.PreviewCallback, a system wywołuje metodę onPreviewFrame(), a format podglądu to YCbCr_420_SP. Dane w tablicy byte[] przekazywanej do onPreviewFrame(). Oznacza to, że format NV21 MUSI być domyślny.
  • [C-0-3] MUSI obsługiwać format YV12 (oznaczony stałą android.graphics.ImageFormat.YV12) w przypadku podglądu z kamery przedniej i tylnej na urządzeniach android.hardware.Camera. (Sprzętowy koder wideo i aparat mogą używać dowolnego natywnego formatu pikseli, ale implementacja urządzenia MUSI obsługiwać konwersję do formatu YV12).
  • [C-0-4] MUSI obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe za pomocą interfejsu API android.media.ImageReader na android.hardware.camera2 urządzeniach, które reklamują funkcję REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE w android.request.availableCapabilities.
  • [C-0-5] MUSI nadal implementować pełny interfejs Camera API zawarty w dokumentacji pakietu Android SDK, niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład kamery bez autofokusa MUSZĄ nadal wywoływać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback (nawet jeśli nie ma to znaczenia w przypadku kamery bez autofokusa). Pamiętaj, że dotyczy to aparatów przednich. Na przykład, mimo że większość aparatów przednich nie obsługuje autofokusa, wywołania zwrotne interfejsu API muszą być „symulowane” w opisany sposób.
  • [C-0-6] MUSI rozpoznawać i honorować każdą nazwę parametru zdefiniowaną jako stała w klasie android.hardware.Camera.Parameters. Z kolei implementacje urządzeń NIE MOGĄ honorować ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters() innych niż te, które są udokumentowane jako stałe w android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry aparatu, jeśli pozwala na to sprzęt, i NIE MOGĄ obsługiwać niestandardowych typów parametrów aparatu. Na przykład implementacje urządzeń, które obsługują rejestrowanie obrazów z użyciem technik obrazowania o wysokim zakresie dynamiki (HDR), MUSZĄ obsługiwać parametr aparatu Camera.SCENE_MODE_HDR.
  • [C-0-7] MUSI zgłaszać odpowiedni poziom obsługi za pomocą właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i zgłaszać odpowiednie flagi funkcji platformy.
  • [C-0-8] MUSI też zadeklarować indywidualne możliwości kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i odpowiednich flag funkcji; MUSI zdefiniować flagę funkcji, jeśli którekolwiek z dołączonych urządzeń z kamerą obsługuje tę funkcję.
  • [C-0-9] MUSI wysyłać intencję Camera.ACTION_NEW_PICTURE za każdym razem, gdy aparat zrobi nowe zdjęcie i zostanie ono dodane do magazynu multimediów.
  • [C-0-10] MUSI wysyłać intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy kamera nagra nowy film, a wpis dotyczący zdjęcia zostanie dodany do magazynu multimediów.
  • [C-SR] Zdecydowanie zaleca się obsługę logicznego urządzenia z aparatem, które ma funkcję CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, w przypadku urządzeń z kilkoma aparatami skierowanymi w tym samym kierunku, składających się z każdego aparatu fizycznego skierowanego w tym kierunku, o ile typ aparatu fizycznego jest obsługiwany przez platformę, a wartość CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL dla aparatów fizycznych to LIMITED, FULL lub LEVEL_3.

7.5.5. Orientacja aparatu

Jeśli urządzenie ma aparat przedni lub tylny, to:

  • [C-1-1] MUSI być zorientowana tak, aby dłuższy bok kamery był równoległy do dłuższego boku ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, kamery MUSZĄ rejestrować obrazy w orientacji poziomej. Dotyczy to wszystkich urządzeń, niezależnie od ich naturalnej orientacji, czyli zarówno urządzeń z orientacją poziomą, jak i pionową.

7.6. Pamięć i miejsce na dane

7.6.1. Minimalna ilość pamięci i miejsca na dane

Implementacje na urządzeniach:

  • [C-0-1] MUSI zawierać menedżera pobierania, którego aplikacje MOGĄ używać do pobierania plików danych. Menedżer MUSI umożliwiać pobieranie pojedynczych plików o rozmiarze co najmniej 100 MB do domyślnej lokalizacji „pamięci podręcznej”.

7.6.2. Pamięć współdzielona aplikacji

Implementacje na urządzeniach:

  • [C-0-1] MUSI oferować pamięć współdzieloną przez aplikacje, często nazywaną też „udostępnionym miejscem zewnętrznym”, „udostępnionym miejscem na dane aplikacji” lub ścieżką Linux „/sdcard”, na której jest zamontowana.
  • [C-0-2] MUSI być skonfigurowane z domyślnie zamontowanym miejscem na dane współdzielone, czyli „od razu po wyjęciu z pudełka”, niezależnie od tego, czy miejsce na dane jest zaimplementowane w komponencie pamięci wewnętrznej, czy na wymiennym nośniku danych (np. gnieździe karty SD).
  • [C-0-3] MUSI zamontować pamięć współdzieloną aplikacji bezpośrednio w ścieżce systemu Linux sdcard lub uwzględnić symboliczny link systemu Linux z sdcard do rzeczywistego punktu montowania.
  • [C-0-4] MUSI wymuszać uprawnienia android.permission.WRITE_EXTERNAL_STORAGE w przypadku tej pamięci współdzielonej zgodnie z dokumentacją pakietu SDK. Pamięć współdzielona MUSI być dostępna do zapisu dla każdej aplikacji, która uzyska to uprawnienie.

Urządzenia MOGĄ spełniać powyższe wymagania w jeden z tych sposobów:

  • Wymienna pamięć dostępna dla użytkownika, np. gniazdo karty SD.
  • Część pamięci wewnętrznej (niewymiennej) zaimplementowanej w ramach Projektu Android Open Source (AOSP).

Jeśli implementacje urządzeń korzystają z pamięci wymiennej, aby spełnić powyższe wymagania:

  • [C-1-1] MUSI implementować interfejs użytkownika w postaci wyskakującego okienka lub powiadomienia, które ostrzega użytkownika, gdy w gnieździe nie ma nośnika danych.
  • [C-1-2] MUSI zawierać nośnik pamięci sformatowany w systemie FAT (np. kartę SD) lub informację na opakowaniu i innych materiałach dostępnych w momencie zakupu, że nośnik pamięci należy kupić osobno.

Jeśli implementacje urządzeń wykorzystują część pamięci trwałej do spełnienia powyższych wymagań:

  • POWINNA korzystać z implementacji AOSP wewnętrznej pamięci współdzielonej aplikacji.
  • MOŻE udostępniać miejsce na dane prywatnym danym aplikacji.

Jeśli implementacje urządzeń obejmują wiele ścieżek pamięci współdzielonej (np. gniazdo karty SD i współdzieloną pamięć wewnętrzną):

  • [C-2-1] MUSI zezwalać na zapisywanie danych w dodatkowej pamięci zewnętrznej tylko wstępnie zainstalowanym i uprzywilejowanym aplikacjom na Androida z uprawnieniem WRITE_EXTERNAL_STORAGE, z wyjątkiem zapisywania danych w katalogach specyficznych dla pakietu lub w katalogu URI zwróconym przez wywołanie intencji ACTION_OPEN_DOCUMENT_TREE.

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB:

  • [C-3-1] MUSI udostępniać mechanizm dostępu do danych w pamięci współdzielonej aplikacji z komputera hosta.
  • POWINNY udostępniać treści z obu ścieżek przechowywania w sposób przejrzysty za pomocą usługi skanera multimediów Androida i android.provider.MediaStore.
  • MOŻE używać pamięci masowej USB, ale POWINIEN używać protokołu przesyłania multimediów, aby spełnić ten wymóg.

Jeśli implementacje urządzeń mają port USB z trybem urządzenia peryferyjnego USB i obsługują protokół przesyłania multimediów, to:

  • POWINIEN być zgodny z referencyjnym hostem MTP Androida, czyli Android File Transfer.
  • POWINIEN zgłaszać klasę urządzenia USB 0x00.
  • POWINIEN zgłaszać nazwę interfejsu USB „MTP”.

7.6.3. Pamięć dostosowywana

Jeśli urządzenie ma być mobilne, w przeciwieństwie do telewizora, implementacje urządzenia są następujące:

  • [SR] Zdecydowanie zalecamy wdrożenie pamięci adaptacyjnej w stabilnej lokalizacji, ponieważ przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

Jeśli port urządzenia pamięci wymiennej znajduje się w stabilnym miejscu, np. w komorze baterii lub pod inną osłoną ochronną, urządzenie:

7.7. USB

Jeśli urządzenie ma port USB:

  • POWINIEN obsługiwać tryb urządzenia peryferyjnego USB i tryb hosta USB.

7.7.1. Tryb urządzenia peryferyjnego USB

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

  • [C-1-1] Port MUSI umożliwiać podłączenie do hosta USB ze standardowym portem USB typu A lub typu C.
  • [C-1-2] MUSI zgłaszać prawidłową wartość iSerialNumber w standardowym deskryptorze urządzenia USB za pomocą android.os.Build.SERIAL.
  • [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem rezystora typu C i MUSI wykrywać zmiany w reklamie, jeśli obsługuje USB typu C.
  • [SR] Port powinien mieć format micro-B, micro-AB lub USB typu C. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z Androidem spełniały te wymagania, dzięki czemu będzie można je uaktualnić do przyszłych wersji platformy.
  • [SR] Port powinien znajdować się na spodzie urządzenia (zgodnie z naturalną orientacją) lub umożliwiać obracanie ekranu we wszystkich aplikacjach (w tym na ekranie głównym), tak aby wyświetlacz był prawidłowo rysowany, gdy urządzenie jest zorientowane portem do dołu. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z Androidem spełniały te wymagania, dzięki czemu będzie można je uaktualnić do przyszłych wersji platformy.
  • [SR] POWINIEN obsługiwać pobieranie prądu o natężeniu 1,5 A podczas sygnału HS i transmisji danych zgodnie ze specyfikacją USB Battery Charging, wersja 1.2. Zdecydowanie zalecamy, aby obecne i nowe urządzenia z Androidem spełniały te wymagania, dzięki czemu będzie można je uaktualnić do przyszłych wersji platformy.
  • [SR] ZDECYDOWANIE ZALECAMY, aby nie obsługiwać zastrzeżonych metod ładowania, które modyfikują napięcie Vbus poza domyślne poziomy lub zmieniają role odbiornika/źródła, ponieważ może to powodować problemy z interoperacyjnością z ładowarkami lub urządzeniami obsługującymi standardowe metody USB Power Delivery. Chociaż jest to „ZDECYDOWANIE ZALECANE”, w przyszłych wersjach Androida możemy WYMAGAĆ, aby wszystkie urządzenia ze złączem typu C obsługiwały pełną interoperacyjność ze standardowymi ładowarkami typu C.
  • [SR] ZDECYDOWANIE ZALECANE jest obsługiwanie zasilania Power Delivery do zamiany ról danych i zasilania, jeśli obsługują one USB typu C i tryb hosta USB.
  • POWINNY obsługiwać Power Delivery do ładowania wysokim napięciem oraz tryby alternatywne, takie jak wyjście wideo.
  • POWINNO implementować interfejs Android Open Accessory (AOA) i specyfikację zgodnie z dokumentacją pakietu Android SDK.

Jeśli urządzenia mają port USB i są zgodne ze specyfikacją AOA:

  • [C-2-1] MUSI deklarować obsługę funkcji sprzętowej android.hardware.usb.accessory.
  • [C-2-2] Klasa pamięci masowej USB MUSI zawierać ciąg znaków „android” na końcu ciągu znaków iInterface opisu interfejsu pamięci masowej USB.

7.7.2. Tryb hosta USB

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta:

  • [C-1-1] MUSI implementować interfejs Android USB host API zgodnie z dokumentacją w pakiecie Android SDK i MUSI deklarować obsługę funkcji sprzętowej android.hardware.usb.host.
  • [C-1-2] MUSI obsługiwać połączenie standardowych urządzeń peryferyjnych USB, czyli MUSI:
    • mają port typu C lub są dostarczane z kablami, które umożliwiają podłączenie portu zastrzeżonego na urządzeniu do standardowego portu USB typu C (urządzenie USB typu C);
    • Musi mieć port typu A lub być dostarczany z kablami, które umożliwiają podłączenie portu zastrzeżonego na urządzeniu do standardowego portu USB typu A.
    • Musi mieć port micro-AB, do którego powinien być dołączony kabel z adapterem do standardowego portu typu A.
  • [C-1-3] NIE MOŻE być dostarczany z adapterem konwertującym porty USB typu A lub micro-AB na port typu C (gniazdo).
  • [SR] Zdecydowanie zalecamy wdrożenie klasy audio USB zgodnie z dokumentacją pakietu Android SDK.
  • POWINNO obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta, reklamując prąd źródłowy o wartości co najmniej 1,5 A zgodnie z sekcją Parametry zakończenia w specyfikacji kabla i złącza USB typu C w wersji 1.2 w przypadku złączy USB typu C lub korzystając z zakresu prądu wyjściowego portu ładowania(CDP) zgodnie ze specyfikacjami ładowania baterii USB w wersji 1.2 w przypadku złączy Micro-AB.
  • POWINNY wdrażać i obsługiwać standardy USB typu C.

Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i klasę audio USB:

  • [C-2-1] MUSI obsługiwać klasę USB HID.
  • [C-2-2] MUSI obsługiwać wykrywanie i mapowanie tych pól danych HID określonych w tabelach zastosowań USB HID i żądaniu zastosowania polecenia głosowego na stałe wartości KeyEvent w sposób podany poniżej:
    • Strona użycia (0xC), identyfikator użycia (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Strona użycia (0xC), identyfikator użycia (0x0E9): KEYCODE_VOLUME_UP
    • Strona użycia (0xC), identyfikator użycia (0x0EA): KEYCODE_VOLUME_DOWN
    • Strona użycia (0xC), identyfikator użycia (0x0CF): KEYCODE_VOICE_ASSIST

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i Storage Access Framework (SAF):

  • [C-3-1] MUSI rozpoznawać wszystkie urządzenia MTP (Media Transfer Protocol) połączone zdalnie i udostępniać ich zawartość za pomocą intencji ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT. .

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i USB typu C:

  • [C-4-1] MUSI obsługiwać funkcję portu o podwójnej roli zgodnie ze specyfikacją USB Type-C (sekcja 4.5.1.3.3).
  • [SR] Zdecydowanie zalecane jest obsługiwanie DisplayPort, zalecane jest obsługiwanie szybkości przesyłania danych USB SuperSpeed, a zdecydowanie zalecane jest obsługiwanie Power Delivery na potrzeby zamiany ról danych i zasilania.
  • [SR] ZDECYDOWANIE ZALECANE jest NIEobsługiwanie trybu akcesoriów adaptera audio opisanego w dodatku A do specyfikacji kabla i złącza USB typu C w wersji 1.2.
  • POWINIEN implementować model Try.*, który jest najbardziej odpowiedni dla danego formatu urządzenia. Na przykład urządzenie przenośne POWINNO implementować model Try.SNK.

7.8. Audio

7.8.1. Mikrofon

Jeśli urządzenie ma mikrofon:

  • [C-1-1] MUSI zgłaszać stałą funkcji android.hardware.microphone.
  • [C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku określone w sekcji 5.4.
  • [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku określone w sekcji 5.6.
  • [SR] ZDECYDOWANIE ZALECANE jest obsługiwanie nagrywania w zakresie bliskim ultradźwiękom zgodnie z opisem w sekcji 7.8.3.

Jeśli urządzenie nie ma mikrofonu:

  • [C-2-1] NIE MOŻE zgłaszać stałej funkcji android.hardware.microphone.
  • [C-2-2] MUSI zaimplementować interfejs API nagrywania dźwięku przynajmniej jako operację bez efektu, zgodnie z sekcją 7.

7.8.2. Wyjście audio

Jeśli implementacje urządzeń obejmują głośnik lub port wyjściowy audio/multimedia dla urządzenia peryferyjnego wyjścia audio, takiego jak 4-żyłowe gniazdo słuchawek 3,5 mm lub port trybu hosta USB korzystający z klasy audio USB, to:

  • [C-1-1] MUSI zgłaszać stałą funkcji android.hardware.audio.output.
  • [C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku określone w sekcji 5.5.
  • [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku określone w sekcji 5.6.
  • [SR] ZDECYDOWANIE ZALECANE jest obsługiwanie odtwarzania dźwięków o częstotliwości zbliżonej do ultradźwięków zgodnie z opisem w sekcji 7.8.3.

Jeśli urządzenie nie ma głośnika ani portu wyjścia audio:

  • [C-2-1] NIE MOŻE zgłaszać funkcji android.hardware.audio.output.
  • [C-2-2] MUSI implementować interfejsy API związane z wyjściem audio jako operacje bez efektu.

Na potrzeby tej sekcji „port wyjściowy” to fizyczny interfejs, taki jak gniazdo audio 3, 5 mm, HDMI lub port hosta USB z klasą audio USB. Obsługa wyjścia audio za pomocą protokołów radiowych, takich jak Bluetooth, Wi-Fi lub sieć komórkowa, nie jest traktowana jako „port wyjściowy”.

7.8.2.1. Analogowe porty audio

Aby zapewnić zgodność z zestawami słuchawkowymi i innymi akcesoriami audio korzystającymi z wtyczki audio 3,5 mm w ekosystemie Androida, jeśli implementacje urządzeń obejmują co najmniej 1 analogowy port audio, muszą:

  • [C-SR] Zdecydowanie zaleca się, aby co najmniej jedno gniazdo audio było 4-żyłowym gniazdem słuchawkowym 3,5 mm.

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

  • [C-1-1] MUSI obsługiwać odtwarzanie dźwięku na słuchawkach stereo i zestawach słuchawkowych stereo z mikrofonem.
  • [C-1-2] MUSI obsługiwać wtyczki audio TRRS z układem pinów CTIA.
  • [C-1-3] MUSI obsługiwać wykrywanie i mapowanie na kody klawiszy w przypadku tych 3 zakresów równoważnej impedancji między mikrofonem a przewodnikami uziemiającymi na wtyczce audio:
    • 70 omów lub mniej: KEYCODE_HEADSETHOOK
    • 210–290 omów: KEYCODE_VOLUME_UP
    • 360–680 omów: KEYCODE_VOLUME_DOWN
  • [C-1-4] MUSI wywoływać zdarzenie ACTION_HEADSET_PLUG po włożeniu wtyczki, ale tylko wtedy, gdy wszystkie styki wtyczki dotykają odpowiednich segmentów gniazda.
  • [C-1-5] MUSI być w stanie zapewnić napięcie wyjściowe o wartości co najmniej 150 mV ± 10% przy impedancji głośnika 32 omy.
  • [C-1-6] MUSI mieć napięcie polaryzacji mikrofonu w zakresie 1,8–2,9 V.
  • [C-1-7] MUSI wykrywać i mapować na kod klucza następujący zakres równoważnej impedancji między mikrofonem a przewodami uziemiającymi na wtyczce audio:
    • 110–180 omów: KEYCODE_VOICE_ASSIST
  • [C-SR] Zdecydowanie zalecane jest obsługiwanie wtyczek audio z układem pinów OMTP.
  • [C-SR] Zdecydowanie zalecamy obsługę nagrywania dźwięku ze stereofonicznych zestawów słuchawkowych z mikrofonem.

Jeśli implementacje urządzeń mają 4-żyłowe gniazdo słuchawek 3, 5 mm i obsługują mikrofon oraz emitują wartość android.intent.action.HEADSET_PLUG z dodatkową wartością mikrofonu ustawioną na 1, to:

  • [C-2-1] MUSI obsługiwać wykrywanie mikrofonu w podłączonym akcesorium audio.

7.8.3. Dźwięki zbliżone do ultradźwięków

Dźwięk w zakresie bliskim ultradźwiękom to pasmo od 18,5 kHz do 20 kHz.

Implementacje na urządzeniach:

  • MUSI prawidłowo zgłaszać obsługę dźwięku w zakresie bliskim ultradźwiękom za pomocą interfejsu AudioManager.getProperty API w ten sposób:

Jeśli wartość PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND to „true”, źródła dźwięku VOICE_RECOGNITION i UNPROCESSED MUSZĄ spełniać te wymagania:

  • [C-1-1] Średnia charakterystyka mocy mikrofonu w zakresie od 18,5 kHz do 20 kHz MUSI być nie więcej niż 15 dB poniżej charakterystyki przy 2 kHz.
  • [C-1-2] Nieważony stosunek sygnału do szumu mikrofonu w zakresie od 18,5 kHz do 20 kHz dla tonu o częstotliwości 19 kHz przy poziomie -26 dBFS MUSI wynosić co najmniej 50 dB.

Jeśli PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „true”:

  • [C-2-1] Średnia odpowiedź głośnika w zakresie 18,5 kHz–20 kHz MUSI być nie niższa niż 40 dB poniżej odpowiedzi przy 2 kHz.

7.9. Rzeczywistość wirtualna

Android zawiera interfejsy API i narzędzia do tworzenia aplikacji w technologii wirtualnej rzeczywistości (VR), w tym wysokiej jakości aplikacji VR na urządzenia mobilne. Implementacje urządzeń MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z opisem w tej sekcji.

7.9.1. Tryb rzeczywistości wirtualnej

Android obsługuje tryb VR, czyli funkcję, która odpowiada za stereoskopowe renderowanie powiadomień i wyłączanie monokularnych komponentów interfejsu systemu, gdy użytkownik korzysta z aplikacji VR.

7.9.2. Tryb rzeczywistości wirtualnej – wysoka wydajność

Jeśli urządzenia obsługują tryb VR:

  • [C-1-1] MUSI mieć co najmniej 2 rdzenie fizyczne.
  • [C-1-2] MUSI zadeklarować funkcję android.hardware.vr.high_performance.
  • [C-1-3] MUSI obsługiwać tryb stałej wydajności.
  • [C-1-4] MUSI obsługiwać OpenGL ES 3.2.
  • [C-1-5] MUSI obsługiwać android.hardware.vulkan.level 0.
  • POWINIEN obsługiwać android.hardware.vulkan.level w wersji 1 lub nowszej.
  • [C-1-6] MUSI implementować rozszerzenia EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace i udostępniać je na liście dostępnych rozszerzeń EGL.
  • [C-1-8] MUSI implementować GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures i udostępniać rozszerzenia na liście dostępnych rozszerzeń GL.
  • [C-SR] Zdecydowanie zaleca się wdrożenie GL_EXT_external_buffer, GL_EXT_EGL_image_array i udostępnienie rozszerzeń na liście dostępnych rozszerzeń GL.
  • [C-SR] Zdecydowanie zaleca się obsługę interfejsu Vulkan 1.1.
  • [C-SR] Zdecydowanie zaleca się wdrożenie VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image i udostępnienie ich na liście dostępnych rozszerzeń Vulkan.
  • [C-SR] Zdecydowanie zaleca się udostępnienie co najmniej 1 rodziny kolejek Vulkan, w której flags zawiera zarówno VK_QUEUE_GRAPHICS_BIT, jak i VK_QUEUE_COMPUTE_BIT, a queueCount wynosi co najmniej 2.
  • [C-1-7] Procesor graficzny i wyświetlacz MUSZĄ być w stanie zsynchronizować dostęp do wspólnego bufora przedniego, tak aby renderowanie treści VR w trybie naprzemiennym dla każdego oka z częstotliwością 60 klatek na sekundę w 2 kontekstach renderowania było wyświetlane bez widocznych artefaktów rozrywania obrazu.
  • [C-1-9] MUSI obsługiwać flagi AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT zgodnie z opisem w NDK.
  • [C-1-10] MUSI obsługiwać AHardwareBuffer z dowolną kombinacją flag użycia AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT w przypadku co najmniej tych formatów: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
  • [C-SR] Zdecydowanie zaleca się obsługę przydzielania AHardwareBuffer z więcej niż jedną warstwą oraz flag i formatów określonych w C-1-10.
  • [C-1-11] MUSI obsługiwać dekodowanie H.264 w rozdzielczości co najmniej 3840 x 2160 przy 30 kl./s, skompresowane do średniej wartości 40 Mb/s (co odpowiada 4 instancjom 1920 x 1080 przy 30 kl./s – 10 Mb/s lub 2 instancjom 1920 x 1080 przy 60 kl./s – 20 Mb/s).
  • [C-1-12] MUSI obsługiwać HEVC i VP9, MUSI być w stanie dekodować co najmniej 1920 x 1080 przy 30 kl./s skompresowane do średnio 10 Mb/s i POWINIEN być w stanie dekodować 3840 x 2160 przy 30 kl./s i 20 Mb/s (co odpowiada 4 instancjom 1920 x 1080 przy 30 kl./s i 5 Mb/s).
  • [C-1-13] MUSI obsługiwać HardwarePropertiesManager.getDeviceTemperatures API i zwracać dokładne wartości temperatury skóry.
  • [C-1-14] MUSI mieć wbudowany ekran, a jego rozdzielczość MUSI wynosić co najmniej 1920 x 1080.
  • [C-SR] Zdecydowanie zalecamy, aby miały rozdzielczość co najmniej 2560 x 1440.
  • [C-1-15] Wyświetlacz MUSI odświeżać obraz z częstotliwością co najmniej 60 Hz w trybie VR.
  • [C-1-17] Wyświetlacz MUSI obsługiwać tryb niskiej trwałości z trwałością ≤ 5 milisekund. Trwałość to czas, przez jaki piksel emituje światło.
  • [C-1-18] MUSI obsługiwać Bluetooth 4.2 i rozszerzenie długości danych Bluetooth LE (sekcja 7.4.3).
  • [C-1-19] MUSI obsługiwać i prawidłowo raportować Direct Channel Type w przypadku wszystkich tych domyślnych typów czujników:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] Zdecydowanie zalecamy obsługę typu kanału bezpośredniego TYPE_HARDWARE_BUFFER dla wszystkich typów kanałów bezpośrednich wymienionych powyżej.
  • [C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru w przypadku android.hardware.hifi_sensors, zgodnie z sekcją 7.3.9.
  • [C-SR] są ZDECYDOWANIE ZALECANE do obsługi funkcji android.hardware.sensor.hifi_sensors.
  • [C-1-22] MUSI mieć opóźnienie od ruchu do fotonu nie większe niż 28 milisekund.
  • [C-SR] ZDECYDOWANIE ZALECA się, aby opóźnienie od ruchu do fotonu nie przekraczało 20 milisekund.
  • [C-1-23] MUSI mieć współczynnik pierwszej klatki, czyli stosunek jasności pikseli w pierwszej klatce po przejściu z czerni do bieli do jasności białych pikseli w stanie ustalonym, wynoszący co najmniej 85%.
  • [C-SR] Zdecydowanie zalecamy, aby współczynnik pierwszej klatki wynosił co najmniej 90%.
  • MOŻE udostępniać wyłączny rdzeń aplikacji na pierwszym planie i MOŻE obsługiwać interfejs Process.getExclusiveCores API, aby zwracać numery rdzeni procesora, które są wyłączne dla aplikacji na pierwszym planie.

Jeśli dedykowany rdzeń jest obsługiwany, to:

  • [C-2-1] NIE MOŻE zezwalać na uruchamianie na nim żadnych innych procesów przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE zezwalać na uruchamianie niektórych procesów jądra, jeśli jest to konieczne.

8. Wydajność i moc

Niektóre minimalne kryteria wydajności i mocy mają kluczowe znaczenie dla wrażeń użytkowników i wpływają na podstawowe założenia, które deweloperzy przyjmują podczas tworzenia aplikacji.

8.1. Spójność interfejsu użytkownika

Płynny interfejs użytkownika można zapewnić użytkownikowi końcowemu, jeśli spełnione są określone minimalne wymagania, które gwarantują stałą liczbę klatek na sekundę i czas reakcji aplikacji i gier. Wdrożenia na urządzeniach, w zależności od typu urządzenia, MOGĄ mieć mierzalne wymagania dotyczące opóźnienia interfejsu użytkownika i przełączania zadań, jak opisano w sekcji 2.

8.2. Wydajność dostępu do wejścia/wyjścia plików

Zapewnienie wspólnego punktu odniesienia dla spójnej wydajności dostępu do plików w prywatnym obszarze pamięci danych aplikacji (partycja /data) umożliwia deweloperom aplikacji określenie odpowiednich oczekiwań, które pomogą im w projektowaniu oprogramowania. Wdrożenia urządzeń, w zależności od typu urządzenia, MOGĄ mieć określone wymagania opisane w sekcji 2 w przypadku tych operacji odczytu i zapisu:

  • Szybkość zapisu sekwencyjnego Pomiar wykonany podczas zapisywania pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
  • Wydajność zapisu losowego Pomiar polega na zapisaniu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.
  • Szybkość odczytu sekwencyjnego Pomiar wykonany podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
  • Wydajność odczytu losowego Pomiar wykonany podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.

8.3. Tryby oszczędzania energii

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

  • [C-1-1] NIE MOŻE odbiegać od implementacji AOSP w zakresie algorytmów wywoływania, konserwacji i wybudzania oraz korzystania z globalnych ustawień systemowych trybów oszczędzania energii w przypadku gotowości aplikacji i uśpienia.
  • [C-1-2] NIE MOŻE odbiegać od implementacji AOSP w zakresie używania ustawień globalnych do zarządzania ograniczaniem zadań, alarmów i sieci w przypadku aplikacji w każdym koszyku w trybie gotowości aplikacji.
  • [C-1-3] NIE MOŻE odbiegać od implementacji AOSP w zakresie liczby zasobników gotowości aplikacji używanych w przypadku gotowości aplikacji.
  • [C-1-4] MUSI implementować zasobniki gotowości aplikacji i tryb uśpienia zgodnie z opisem w sekcji Zarządzanie energią.
  • [C-1-5] MUSI zwracać true dla PowerManager.isPowerSaveMode(), gdy urządzenie jest w trybie oszczędzania energii.
  • [C-SR] Zdecydowanie zaleca się udostępnienie użytkownikowi możliwości włączania i wyłączania funkcji oszczędzania baterii.
  • [C-SR] ZDECYDOWANIE ZALECA SIĘ udostępnienie użytkownikowi możliwości wyświetlania wszystkich aplikacji zwolnionych z trybów oszczędzania energii „Aplikacja w trybie gotowości” i „Drzemka”.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ implementować dowolne lub wszystkie 4 stany uśpienia zdefiniowane przez interfejs ACPI (Advanced Configuration and Power Interface).

Jeśli implementacje urządzeń obsługują stany zasilania S4 zdefiniowane przez ACPI:

  • [C-1-1] MUSI przejść w ten stan tylko wtedy, gdy użytkownik wykona wyraźną czynność, aby wprowadzić urządzenie w stan nieaktywny (np. zamknie pokrywę, która jest fizycznie częścią urządzenia, lub wyłączy pojazd lub telewizor), i zanim ponownie aktywuje urządzenie (np. otworzy pokrywę lub ponownie włączy pojazd lub telewizor).

Jeśli implementacje urządzeń obsługują stany zasilania S3 zdefiniowane przez ACPI:

  • [C-2-1] MUSI spełniać wymagania C-1-1 powyżej LUB MUSI przechodzić w stan S3 tylko wtedy, gdy aplikacje innych firm nie potrzebują zasobów systemowych (np. ekranu, procesora).

    Z kolei MUSI wyjść ze stanu S3, gdy aplikacje innych firm potrzebują zasobów systemowych, jak opisano w tym pakiecie SDK.

    Na przykład, gdy aplikacje innych firm żądają utrzymania włączonego ekranu za pomocą FLAG_KEEP_SCREEN_ON lub utrzymania działania procesora za pomocą PARTIAL_WAKE_LOCK, urządzenie NIE MOŻE przejść w stan S3, chyba że użytkownik wykonał wyraźną czynność, aby wprowadzić urządzenie w stan nieaktywny, zgodnie z opisem w sekcji C-1-1. Z kolei w momencie, gdy zadanie, które aplikacje innych firm realizują za pomocą JobScheduler, zostanie wywołane lub gdy Komunikacja w chmurze Firebase zostanie dostarczona do aplikacji innych firm, urządzenie MUSI wyjść ze stanu S3, chyba że użytkownik wprowadził je w stan nieaktywności. To nie są wyczerpujące przykłady. AOSP implementuje wiele sygnałów wybudzania, które wywołują wybudzenie z tego stanu.

8.4. Rozliczanie zużycia energii

Dokładniejsze rozliczanie i raportowanie zużycia energii daje deweloperowi aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorca zużycia energii przez aplikację.

Implementacje na urządzeniach:

  • [SR] Zdecydowanie zalecamy podanie profilu zasilania poszczególnych komponentów, który określa wartość zużycia prądu dla każdego komponentu sprzętowego oraz przybliżone zużycie baterii przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source Project.
  • [SR] Zdecydowanie zalecamy podawanie wszystkich wartości zużycia energii w miliamperogodzinach (mAh).
  • [SR] ZDECYDOWANIE ZALECANE jest raportowanie zużycia energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
  • [SR] ZDECYDOWANIE ZALECANE jest udostępnienie deweloperowi aplikacji informacji o zużyciu energii za pomocą polecenia powłoki adb shell dumpsys batterystats.
  • Jeśli nie można przypisać zużycia energii przez komponent sprzętowy do aplikacji, należy przypisać je do samego komponentu.

8.5. Stabilna wydajność

W przypadku aplikacji o wysokiej wydajności działających przez dłuższy czas wydajność może się znacznie wahać z powodu innych aplikacji działających w tle lub ograniczenia mocy procesora ze względu na limity temperatury. Android zawiera interfejsy programowe, dzięki którym w razie potrzeby aplikacja na pierwszym planie może poprosić system o zoptymalizowanie przydziału zasobów w celu poradzenia sobie z takimi wahaniami.

Implementacje na urządzeniach:

Jeśli implementacje urządzeń zgłaszają obsługę trybu stałej wydajności:

  • [C-1-1] MUSI zapewniać aplikacji na pierwszym planie stały poziom wydajności przez co najmniej 30 minut, gdy aplikacja tego wymaga.
  • [C-1-2] MUSI obsługiwać interfejs Window.setSustainedPerformanceMode() API i inne powiązane interfejsy API.

Jeśli implementacje urządzeń obejmują co najmniej 2 rdzenie procesora, muszą:

  • POWINIEN udostępniać co najmniej 1 wyłączny rdzeń, który może być zarezerwowany przez aplikację działającą na pierwszym planie.

Jeśli implementacje urządzeń obsługują rezerwowanie jednego rdzenia na wyłączność dla aplikacji działającej na pierwszym planie, to:

  • [C-2-1] MUSI zgłaszać za pomocą metody interfejsu API Process.getExclusiveCores() numery identyfikacyjne wyłącznych rdzeni, które mogą być zarezerwowane przez aplikację na pierwszym planie.
  • [C-2-2] NIE MOŻE zezwalać na uruchamianie na wyłącznych rdzeniach żadnych procesów przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację, ale MOŻE zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.

Jeśli implementacje urządzeń nie obsługują wyłącznego rdzenia, to:

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniach:

  • [C-0-1] MUSI wdrażać model bezpieczeństwa zgodny z modelem bezpieczeństwa platformy Android zdefiniowanym w dokumencie referencyjnym dotyczącym bezpieczeństwa i uprawnień w interfejsach API w dokumentacji dla deweloperów Androida.

  • [C-0-2] MUSI obsługiwać instalację aplikacji podpisanych samodzielnie bez konieczności uzyskiwania dodatkowych uprawnień lub certyfikatów od osób trzecich lub organów. W szczególności zgodne urządzenia MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w kolejnych podrozdziałach.

9.1. Uprawnienia

Implementacje na urządzeniach:

  • [C-0-1] MUSI obsługiwać model uprawnień Androida zdefiniowany w dokumentacji dla deweloperów Androida. W szczególności MUSZĄ egzekwować każde uprawnienie zdefiniowane zgodnie z opisem w dokumentacji pakietu SDK. Nie można pomijać, zmieniać ani ignorować żadnych uprawnień.

  • MOŻE dodawać dodatkowe uprawnienia, pod warunkiem że nowe ciągi identyfikatorów uprawnień nie znajdują się w przestrzeni nazw android.\*.

  • [C-0-2] Uprawnienia z wartością protectionLevel PROTECTION_FLAG_PRIVILEGED MUSZĄ być przyznawane tylko aplikacjom preinstalowanym w ścieżkach uprzywilejowanych obrazu systemu i w podzbiorze uprawnień wyraźnie dodanych do listy dozwolonych dla każdej aplikacji. Implementacja AOSP spełnia to wymaganie, odczytując i uwzględniając uprawnienia dodane do listy dozwolonych dla każdej aplikacji z plików w ścieżce etc/permissions/ i używając ścieżki system/priv-app jako ścieżki uprzywilejowanej.

Uprawnienia o poziomie ochrony „niebezpieczne” to uprawnienia czasu działania. Aplikacje z wartością targetSdkVersion > 22 wysyłają żądania w czasie działania.

Implementacje na urządzeniach:

  • [C-0-3] MUSI wyświetlać specjalny interfejs, w którym użytkownik może zdecydować, czy przyznać żądane uprawnienia w czasie działania, a także interfejs do zarządzania tymi uprawnieniami.
  • [C-0-4] MUSI mieć tylko jedną implementację obu interfejsów użytkownika.
  • [C-0-5] NIE WOLNO przyznawać żadnych uprawnień przy uruchamianiu preinstalowanym aplikacjom, chyba że:
    • Zgodę użytkownika można uzyskać przed użyciem aplikacji.
    • Uprawnienia w czasie działania są powiązane z wzorcem intencji, dla którego preinstalowana aplikacja jest ustawiona jako domyślny moduł obsługi.
  • [C-0-6] MUSI przyznawać uprawnienia android.permission.RECOVER_KEYSTORE tylko aplikacjom systemowym, które rejestrują odpowiednio zabezpieczonego agenta odzyskiwania. Odpowiednio zabezpieczony agent odzyskiwania to agent oprogramowania na urządzeniu, który synchronizuje się ze zdalnym magazynem poza urządzeniem i jest wyposażony w bezpieczny sprzęt z ochroną równoważną lub silniejszą niż opisana w usłudze Google Cloud Key Vault, aby zapobiegać atakom siłowym na składnik wiedzy dotyczący ekranu blokady.

Jeśli implementacje urządzeń obejmują wstępnie zainstalowaną aplikację lub chcą zezwolić aplikacjom innych firm na dostęp do statystyk użytkowania:

  • [SR] Zdecydowanie zalecamy, aby aplikacje, które deklarują uprawnienie android.permission.PACKAGE_USAGE_STATS, udostępniały użytkownikom mechanizm przyznawania lub cofania dostępu do statystyk użytkowania w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Jeśli implementacje urządzeń mają uniemożliwiać dostęp do statystyk użycia dowolnym aplikacjom, w tym aplikacjom wstępnie zainstalowanym:

  • [C-1-1] MUSI nadal mieć aktywność, która obsługuje wzorzec intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale MUSI implementować go jako operację bez efektu, czyli zachowywać się tak, jakby użytkownikowi odmówiono dostępu.

9.2. Identyfikator UID i izolacja procesów

Implementacje na urządzeniach:

  • [C-0-1] MUSI obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja jest uruchamiana jako unikalny identyfikator UID w stylu systemu Unix i w osobnym procesie.
  • [C-0-2] MUSI obsługiwać uruchamianie wielu aplikacji z tym samym identyfikatorem użytkownika systemu Linux, pod warunkiem że aplikacje są prawidłowo podpisane i zbudowane zgodnie z definicją w dokumentacji dotyczącej bezpieczeństwa i uprawnień.

9.3. Uprawnienia do systemu plików

Implementacje na urządzeniach:

9.4. Alternatywne środowiska wykonawcze

Implementacje urządzeń MUSZĄ zachowywać spójność modelu zabezpieczeń i uprawnień Androida, nawet jeśli zawierają środowiska wykonawcze, które uruchamiają aplikacje przy użyciu innego oprogramowania lub technologii niż format wykonywalny Dalvik lub kod natywny. Krótko mówiąc:

  • [C-0-1] Alternatywne środowiska wykonawcze MUSZĄ być aplikacjami na Androida i muszą być zgodne ze standardowym modelem zabezpieczeń Androida, jak opisano w sekcji 9.

  • [C-0-2] Alternatywne środowiska wykonawcze NIE MOGĄ mieć dostępu do zasobów chronionych przez uprawnienia, o które nie poproszono w pliku AndroidManifest.xml środowiska wykonawczego za pomocą mechanizmu <uses-permission>.

  • [C-0-3] Alternatywne środowiska wykonawcze NIE MOGĄ zezwalać aplikacjom na korzystanie z funkcji chronionych przez uprawnienia Androida, które są ograniczone do aplikacji systemowych.

  • [C-0-4] Alternatywne środowiska wykonawcze MUSZĄ być zgodne z modelem piaskownicy Androida, a zainstalowane aplikacje korzystające z alternatywnego środowiska wykonawczego NIE MOGĄ ponownie używać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida, takich jak udostępniony identyfikator użytkownika i certyfikat podpisu.

  • [C-0-5] Alternatywne środowiska wykonawcze NIE MOGĄ uruchamiać piaskownic odpowiadających innym aplikacjom na Androida ani przyznawać do nich dostępu.

  • [C-0-6] Alternatywne środowiska wykonawcze NIE MOGĄ być uruchamiane z uprawnieniami superużytkownika (root) ani żadnego innego identyfikatora użytkownika, ani nie mogą przyznawać takich uprawnień innym aplikacjom.

  • [C-0-7] Jeśli w obrazie systemu implementacji urządzenia znajdują się pliki .apk alternatywnych środowisk wykonawczych, MUSZĄ one być podpisane kluczem innym niż klucz używany do podpisywania innych aplikacji dołączonych do implementacji urządzenia.

  • [C-0-8] Podczas instalowania aplikacji alternatywne środowiska wykonawcze MUSZĄ uzyskiwać zgodę użytkownika na uprawnienia Androida używane przez aplikację.

  • [C-0-9] Gdy aplikacja musi użyć zasobu urządzenia, dla którego istnieje odpowiednie uprawnienie Androida (np. aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI poinformować użytkownika, że aplikacja będzie mogła uzyskać dostęp do tego zasobu.

  • [C-0-10] Jeśli środowisko wykonawcze nie rejestruje możliwości aplikacji w ten sposób, podczas instalowania dowolnej aplikacji za pomocą tego środowiska wykonawczego MUSI ono wyświetlać listę wszystkich uprawnień, które posiada.

  • Alternatywne środowiska wykonawcze POWINNY instalować aplikacje za pomocą PackageManager w oddzielnych piaskownicach Androida (identyfikatory użytkowników Linuxa itp.).

  • Alternatywne środowiska wykonawcze MOGĄ udostępniać jedną piaskownicę Androida współdzieloną przez wszystkie aplikacje korzystające z tego środowiska.

9.5. Obsługa wielu użytkowników

Android obsługuje wielu użytkowników i zapewnia pełną izolację użytkowników.

  • Urządzenia MOGĄ, ale NIE POWINNY włączać obsługi wielu użytkowników, jeśli jako podstawową pamięć zewnętrzną wykorzystują nośniki wymienne.

Jeśli implementacje urządzeń obejmują wielu użytkowników:

  • [C-1-1] MUSI spełniać te wymagania dotyczące obsługi wielu użytkowników.
  • [C-1-2] MUSI w przypadku każdego użytkownika w interfejsach API wdrażać model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android zdefiniowanym w dokumencie referencyjnym dotyczącym zabezpieczeń i uprawnień.
  • [C-1-3] MUSI mieć oddzielne i odizolowane katalogi współdzielonego miejsca na aplikacje (tzw. /sdcard) dla każdej instancji użytkownika.
  • [C-1-4] MUSI zapewniać, że aplikacje należące do danego użytkownika i uruchamiane w jego imieniu nie mogą wyświetlać, odczytywać ani zapisywać plików należących do innego użytkownika, nawet jeśli dane obu użytkowników są przechowywane na tym samym woluminie lub w tym samym systemie plików.
  • [C-1-5] MUSI szyfrować zawartość karty SD, gdy włączona jest funkcja wielu użytkowników, za pomocą klucza przechowywanego tylko na nośniku niewymiennym, do którego dostęp ma tylko system, jeśli implementacje urządzeń używają nośników wymiennych w przypadku interfejsów API pamięci zewnętrznej. Spowoduje to, że nośnik będzie nieczytelny dla komputera hosta, więc implementacje urządzeń będą musiały przełączyć się na MTP lub podobny system, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika.

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

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

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

  • [C-3-1] NIE MOŻE obsługiwać profili z ograniczeniami, ale MUSI być zgodny z implementacją AOSP dotyczącą ustawień umożliwiających włączanie i wyłączanie dostępu innych użytkowników do połączeń głosowych i SMS-ów.

9.6. Ostrzeżenie dotyczące SMS-ów specjalnych

Android obsługuje ostrzeganie użytkowników o wszystkich wychodzących SMS-ach premium. SMS-y specjalne to wiadomości tekstowe wysyłane do usługi zarejestrowanej u operatora, za które użytkownik może ponosić opłaty.

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

  • [C-1-1] MUSI ostrzegać użytkowników przed wysłaniem SMS-a na numery zidentyfikowane przez wyrażenia regularne zdefiniowane w pliku /data/misc/sms/codes.xml na urządzeniu. Projekt Android Open Source udostępnia implementację, która spełnia to wymaganie.

9.7. Funkcje zabezpieczeń

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń zarówno w jądrze, jak i na platformie, zgodnie z opisem poniżej.

Piaskownica Androida zawiera funkcje, które korzystają z systemu obowiązkowej kontroli dostępu (MAC) Security-Enhanced Linux (SELinux), piaskownicy seccomp i innych funkcji zabezpieczeń w jądrze systemu Linux. Implementacje na urządzeniach:

  • [C-0-1] MUSI zachowywać zgodność z istniejącymi aplikacjami, nawet jeśli SELinux lub inne funkcje zabezpieczeń są zaimplementowane poniżej platformy Androida.
  • [C-0-2] NIE MOŻE mieć widocznego interfejsu użytkownika, gdy wykryte zostanie naruszenie bezpieczeństwa i zostanie ono skutecznie zablokowane przez funkcję zabezpieczeń zaimplementowaną poniżej struktury Androida, ale MOŻE mieć widoczny interfejs użytkownika, gdy wystąpi niezablokowane naruszenie bezpieczeństwa, które doprowadzi do skutecznego wykorzystania luki.
  • [C-0-3] NIE MOŻE udostępniać użytkownikowi ani deweloperowi aplikacji możliwości konfigurowania SELinux ani żadnych innych funkcji zabezpieczeń zaimplementowanych poniżej platformy Androida.
  • [C-0-4] NIE MOŻE zezwalać aplikacji, która może wpływać na inną aplikację za pomocą interfejsu API (np. interfejsu Device Administration API), na konfigurowanie zasad, które powodują utratę zgodności.
  • [C-0-5] MUSI podzielić platformę multimedialną na wiele procesów, aby można było bardziej precyzyjnie przyznawać dostęp do każdego z nich, jak opisano na stronie projektu Android Open Source.
  • [C-0-6] MUSI implementować mechanizm piaskownicy aplikacji w jądrze, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnych zasad w programach wielowątkowych. Projekt Android Open Source spełnia to wymaganie, umożliwiając seccomp-BPF z synchronizacją grupy wątków (TSYNC), jak opisano w sekcji Konfiguracja jądra na stronie source.android.com.

Integralność jądra i funkcje samoobrony są nieodłączną częścią zabezpieczeń Androida. Implementacje na urządzeniach:

  • [C-0-7] MUSI implementować ochronę przed przepełnieniem bufora stosu jądra (np. CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] MUSI wdrażać ścisłą ochronę pamięci jądra, w której kod wykonywalny jest tylko do odczytu, dane tylko do odczytu nie są wykonywalne ani zapisywalne, a dane zapisywalne nie są wykonywalne (np. CONFIG_DEBUG_RODATA lub CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] MUSI implementować statyczne i dynamiczne sprawdzanie rozmiaru obiektów kopiowanych między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY) na urządzeniach, które pierwotnie były dostarczane z interfejsem API na poziomie 28 lub wyższym.
  • [C-0-10] NIE MOŻE wykonywać pamięci przestrzeni użytkownika podczas wykonywania w trybie jądra (np. sprzętowy PXN lub emulowany za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które pierwotnie były dostarczane z poziomem interfejsu API 28 lub wyższym.
  • [C-0-11] NIE WOLNO odczytywać ani zapisywać pamięci przestrzeni użytkownika w jądrze poza normalnymi interfejsami API dostępu do kopiowania użytkownika (np. sprzętowy PAN lub emulowany za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach, które pierwotnie były dostarczane z interfejsem API na poziomie 28 lub wyższym.
  • [C-0-12] MUSI implementować izolację tabeli stron jądra na wszystkich urządzeniach, które pierwotnie były dostarczane z interfejsem API na poziomie 28 lub wyższym (np. CONFIG_PAGE_TABLE_ISOLATION lub `CONFIG_UNMAP_KERNEL_AT_EL0).
  • [SR] Zdecydowanie zalecamy, aby po inicjowaniu dane jądra, które są zapisywane tylko podczas inicjowania, były oznaczone jako tylko do odczytu (np. __ro_after_init).
  • [SR] Zdecydowanie zalecamy losowe rozmieszczenie kodu jądra i pamięci oraz unikanie sytuacji, które mogłyby naruszyć losowość (np. CONFIG_RANDOMIZE_BASE z entropią programu rozruchowego za pomocą /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 implementować SELinux.
  • [C-1-2] MUSI ustawić SELinux w trybie globalnego wymuszania.
  • [C-1-3] MUSI skonfigurować wszystkie domeny w trybie egzekwowania. Nie są dozwolone żadne domeny w trybie zezwalającym, w tym domeny specyficzne dla urządzenia lub dostawcy.
  • [C-1-4] NIE WOLNO modyfikować, pomijać ani zastępować reguł neverallow znajdujących się w folderze system/sepolicy dostarczonym w ramach Projektu Android Open Source (AOSP). Zasady MUSZĄ być kompilowane ze wszystkimi regułami neverallow, zarówno w przypadku domen SELinux AOSP, jak i domen specyficznych dla urządzenia lub dostawcy.
  • [C-1-5] MUSI uruchamiać aplikacje innych firm kierowane na interfejs API na poziomie 28 lub wyższym w piaskownicach SELinux dla poszczególnych aplikacji z ograniczeniami SELinux dla poszczególnych aplikacji w prywatnym katalogu danych każdej aplikacji.
  • POWINNI zachować domyślne zasady SELinux udostępnione w folderze system/sepolicy w projekcie Android Open Source Project i tylko rozszerzać te zasady o własną konfigurację specyficzną dla urządzenia.

Jeśli implementacje urządzeń zostały już wprowadzone na rynek w starszej wersji Androida i nie mogą spełniać wymagań [C-1-1] i [C-1-5] za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać z nich zwolnione.

Jeśli implementacje urządzeń korzystają z jądra innego niż Linux:

  • [C-2-1] MUSI używać systemu obowiązkowej kontroli dostępu, który jest odpowiednikiem SELinux.

Android zawiera wiele funkcji ochrony wielowarstwowej, które są integralną częścią zabezpieczeń urządzenia.

Implementacje na urządzeniach:

  • [C-SR] Zdecydowanie zaleca się, aby nie wyłączać funkcji Control-Flow Integrity (CFI) ani Integer Overflow Sanitization (IntSan) w komponentach, w których są one włączone.
  • [C-SR] Zdecydowanie zalecamy włączenie zarówno CFI, jak i IntSan w przypadku wszystkich dodatkowych komponentów przestrzeni użytkownika, które są wrażliwe na kwestie bezpieczeństwa, zgodnie z opisem w sekcjach CFI i IntSan.

9.8. Prywatność

9.8.1. Historia użycia

Android przechowuje historię wyborów użytkownika i zarządza nią za pomocą interfejsu UsageStatsManager.

Implementacje na urządzeniach:

  • [C-0-1] MUSI zachować rozsądny okres przechowywania historii użytkownika.
  • [SR] Zdecydowanie zalecamy zachowanie 14-dniowego okresu przechowywania skonfigurowanego domyślnie w implementacji AOSP.

Android przechowuje zdarzenia systemowe za pomocą identyfikatorów StatsLog i zarządza taką historią za pomocą interfejsów API StatsManager i IncidentManager.

Implementacje na urządzeniach:

  • [C-0-2] MUSI zawierać tylko pola oznaczone symbolem DEST_AUTOMATIC w raporcie o incydencie utworzonym przez klasę interfejsu System API IncidentManager.
  • [C-0-3] NIE WOLNO używać identyfikatorów zdarzeń systemowych do rejestrowania żadnych innych zdarzeń niż te opisane w dokumentach pakietu SDK StatsLog. Jeśli rejestrowane są dodatkowe zdarzenia systemowe, MOGĄ one używać innego identyfikatora atomu z zakresu od 100 000 do 200 000.

9.8.2. Nagrywam

Implementacje na urządzeniach:

  • [C-0-1] NIE WOLNO wstępnie instalować ani rozpowszechniać komponentów oprogramowania, które wysyłają z urządzenia prywatne informacje użytkownika (np. naciśnięcia klawiszy, tekst wyświetlany na ekranie) bez jego zgody lub bez wyświetlania jasnych, ciągłych powiadomień.

Jeśli implementacje urządzeń zawierają funkcje systemowe, które rejestrują treści wyświetlane na ekranie lub nagrywają strumień audio odtwarzany na urządzeniu:

  • [C-1-1] MUSI wyświetlać użytkownikowi ciągłe powiadomienie, gdy ta funkcja jest włączona i aktywna (rejestruje lub nagrywa).

Jeśli implementacje urządzeń zawierają komponent włączony od razu po wyjęciu z pudełka, który może nagrywać dźwięk otoczenia w celu wywnioskowania przydatnych informacji o kontekście użytkownika:

  • [C-2-1] NIE WOLNO przechowywać w pamięci trwałej urządzenia ani przesyłać poza urządzenie nagranego surowego dźwięku ani żadnego formatu, który można przekonwertować z powrotem na oryginalny dźwięk lub jego niemal identyczną kopię, z wyjątkiem sytuacji, gdy użytkownik wyrazi na to wyraźną zgodę.

9.8.3. Łączność

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB:

  • [C-1-1] MUSI wyświetlać interfejs użytkownika z prośbą o zgodę użytkownika przed zezwoleniem na dostęp do zawartości pamięci współdzielonej przez port USB.

9.8.4. Ruch w sieci

Implementacje na urządzeniach:

  • [C-0-1] MUSI wstępnie instalować te same certyfikaty główne w magazynie zaufanych przez system urzędów certyfikacji, które są udostępniane w projekcie Android Open Source Project.
  • [C-0-2] MUSI być dostarczany z pustym magazynem głównych urzędów certyfikacji użytkownika.
  • [C-0-3] MUSI wyświetlać ostrzeżenie dla użytkownika informujące, że ruch w sieci może być monitorowany, gdy dodany zostanie główny certyfikat CA użytkownika.

Jeśli ruch na urządzeniu jest kierowany przez sieć VPN, implementacje na urządzeniu:

  • [C-1-1] MUSI wyświetlać ostrzeżenie dla użytkownika wskazujące:
    • Ten ruch w sieci może być monitorowany.
    • Ruch sieciowy jest kierowany przez konkretną aplikację VPN, która zapewnia VPN.

Jeśli implementacje urządzeń mają mechanizm, który jest domyślnie włączony i kieruje ruch danych sieciowych przez serwer proxy lub bramę VPN (np. wstępne wczytywanie usługi VPN z przyznanym uprawnieniem android.permission.CONTROL_VPN), to:

  • [C-2-1] MUSI poprosić użytkownika o zgodę przed włączeniem tego mechanizmu, chyba że sieć VPN jest włączana przez kontroler zasad dotyczących urządzenia za pomocą interfejsu DevicePolicyManager.setAlwaysOnVpnPackage(). W takim przypadku użytkownik nie musi wyrażać osobnej zgody, ale MUSI otrzymać powiadomienie.

Jeśli implementacje urządzeń udostępniają użytkownikowi możliwość włączania i wyłączania funkcji „stałego VPN” aplikacji VPN innej firmy:

  • [C-3-1] MUSI wyłączyć tę funkcję dla aplikacji, które nie obsługują stałej sieci VPN, w pliku AndroidManifest.xml, ustawiając atrybut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

9.9. Szyfrowanie danych przechowywanych

Jeśli wydajność kryptograficzna standardu AES (Advanced Encryption Standard) mierzona za pomocą najbardziej wydajnej technologii AES dostępnej na urządzeniu (np. rozszerzeń kryptograficznych ARM) przekracza 50 MiB/s, implementacje urządzeń:

  • [C-1-1] MUSI obsługiwać szyfrowanie danych przechowywanych w pamięci prywatnej aplikacji (partycja /data), a także w pamięci współdzielonej aplikacji (partycja /sdcard), jeśli jest ona stałą, nieusuwalną częścią urządzenia, z wyjątkiem urządzeń, które są zwykle współdzielone (np. telewizor).
  • [C-1-2] MUSI domyślnie włączać szyfrowanie pamięci danych po zakończeniu przez użytkownika konfiguracji początkowej, z wyjątkiem urządzeń, które są zwykle współdzielone (np. telewizorów).

Jeśli wydajność szyfrowania AES wynosi co najmniej 50 MiB/s, implementacje urządzeń MOGĄ używać Adiantum-XChaCha12-AES zamiast formy AES wymienionej w jednym z tych punktów: AES-256-XTS w sekcji 9.9.2 [C-1-5]; AES-256 w trybie CBS-CTS w sekcji 9.9.2 [C-1-6]; AES w sekcji 9.9.3 [C-1-1]; AES w sekcji 9.9.3 [C-1-3].

Jeśli implementacje urządzeń zostały już wprowadzone na rynek w starszej wersji Androida i nie spełniają wymagań w ramach aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z powyższych wymagań.

Implementacje na urządzeniach:

9.9.1. Bezpośredni rozruch

Implementacje na urządzeniach:

  • [C-0-1] MUSI implementować interfejsy API trybu bezpośredniego rozruchu, nawet jeśli nie obsługuje szyfrowania pamięci.

  • [C-0-2] Intencje ACTION_LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED MUSZĄ być nadal rozgłaszane, aby poinformować aplikacje obsługujące bezpośrednie uruchamianie, że lokalizacje pamięci zaszyfrowanej na urządzeniu (DE) i zaszyfrowanej za pomocą danych logowania (CE) są dostępne dla użytkownika.

9.9.2. Szyfrowanie oparte na plikach

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

  • [C-1-1] MUSI uruchamiać się bez proszenia użytkownika o dane logowania i umożliwiać aplikacjom obsługującym bezpośrednie uruchamianie dostęp do pamięci zaszyfrowanej na urządzeniu (DE) po wyemitowaniu komunikatu ACTION_LOCKED_BOOT_COMPLETED.
  • [C-1-2] MUSI zezwalać na dostęp do zaszyfrowanej pamięci danych logowania (CE) tylko po odblokowaniu urządzenia przez użytkownika za pomocą danych logowania (np. kodu dostępu, kodu PIN, wzoru lub odcisku palca) i po wyemitowaniu komunikatu ACTION_USER_UNLOCKED.
  • [C-1-3] NIE MOŻE oferować żadnej metody odblokowywania pamięci chronionej przez CE bez podania przez użytkownika danych logowania lub zarejestrowanego klucza depozytowego.
  • [C-1-4] MUSI obsługiwać weryfikację podczas uruchamiania i zapewniać, ż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 plików za pomocą algorytmu AES-256-XTS. AES-256-XTS to standard szyfrowania zaawansowanego z 256-bitowym kluczem, działający w trybie XTS. Pełna długość klucza XTS wynosi 512 bitów.

  • [C-1-6] MUSI obsługiwać szyfrowanie nazw plików za pomocą algorytmu AES-256 w trybie CBC-CTS.

  • Klucze chroniące obszary pamięci CE i DE:

  • [C-1-7] MUSI być kryptograficznie powiązany z magazynem kluczy wspieranym sprzętowo.

  • [C-1-8] Klucze CE MUSZĄ być powiązane z danymi logowania do ekranu blokady użytkownika.
  • [C-1-9] Klucze CE MUSZĄ być powiązane z domyślnym hasłem, jeśli użytkownik nie określił danych logowania do ekranu blokady.

  • [C-1-10] MUSI być unikalny i odrębny, tzn. klucz CE lub DE żadnego użytkownika nie może być zgodny z kluczem CE lub DE innego użytkownika.

  • [C-1-11] MUSI domyślnie używać obowiązkowo obsługiwanych szyfrów, długości kluczy i trybów.

  • [C-SR] Zdecydowanie zaleca się szyfrowanie metadanych systemu plików, takich jak rozmiary plików, własność, tryby i atrybuty rozszerzone (xattrs), za pomocą klucza kryptograficznie powiązanego ze sprzętowym źródłem zaufania urządzenia.

  • POWINNY obsługiwać bezpośrednie uruchamianie wstępnie zainstalowane aplikacje podstawowe (np. Alarm, Telefon, Messenger).

  • MOŻE obsługiwać alternatywne szyfry, długości kluczy i tryby szyfrowania zawartości i nazw plików.

Projekt Android Open Source udostępnia preferowaną implementację tej funkcji opartą na funkcji szyfrowania ext4 jądra Linuksa.

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ć algorytmu AES w trybie przeznaczonym do przechowywania danych (np. XTS lub CBC-ESSIV) z kluczem szyfrującym o długości co najmniej 128 bitów.
  • [C-1-2] MUSI używać domyślnego kodu dostępu do opakowania klucza szyfrowania i NIE MOŻE w żadnym momencie zapisywać klucza szyfrowania w pamięci bez szyfrowania.
  • [C-1-3] MUSI domyślnie szyfrować klucz szyfrowania za pomocą AES, chyba że użytkownik wyraźnie zrezygnuje z tej opcji, z wyjątkiem sytuacji, gdy klucz jest aktywnie używany.W takim przypadku dane logowania ekranu blokady muszą być rozszerzane za pomocą powolnego algorytmu rozszerzania (np. PBKDF2 lub scrypt).
  • [C-1-4] Powyższy domyślny algorytm rozciągania hasła MUSI być kryptograficznie powiązany z tym magazynem kluczy, gdy użytkownik nie określił danych logowania ekranu blokady lub wyłączył używanie kodu dostępu do szyfrowania, a urządzenie udostępnia magazyn kluczy obsługiwany sprzętowo.
  • [C-1-5] NIE WOLNO wysyłać klucza szyfrowania z urządzenia (nawet jeśli jest on opakowany hasłem użytkownika lub kluczem powiązanym ze sprzętem).

Projekt Android Open Source udostępnia preferowaną implementację tej funkcji opartą na funkcji jądra Linuksa dm-crypt.

9.10. Integralność urządzenia

Poniższe wymagania zapewniają przejrzystość stanu integralności urządzenia. Implementacje na urządzeniach:

  • [C-0-1] MUSI prawidłowo zgłaszać za pomocą metody interfejsu System API PersistentDataBlockManager.getFlashLockState(), czy stan programu rozruchowego umożliwia flashowanie obrazu systemu. Stan FLASH_LOCK_UNKNOWN jest zarezerwowany dla implementacji urządzeń, które są uaktualniane z wcześniejszej wersji Androida, w której nie było tej nowej metody interfejsu API systemu.

  • [C-0-2] MUSI obsługiwać zweryfikowane uruchamianie w celu zapewnienia integralności urządzenia.

Jeśli urządzenia zostały już wprowadzone na rynek bez obsługi weryfikacji podczas uruchamiania w starszej wersji Androida i nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać zwolnione z tego wymagania.

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

  • [C-1-1] MUSI zadeklarować flagę funkcji platformy android.software.verified_boot.
  • [C-1-2] MUSI przeprowadzać weryfikację przy każdej sekwencji uruchamiania.
  • [C-1-3] MUSI rozpocząć weryfikację od niezmiennego klucza sprzętowego, który jest źródłem zaufania, i przejść aż do partycji systemowej.
  • [C-1-4] MUSI wdrażać każdy etap weryfikacji, aby sprawdzać integralność i autentyczność wszystkich bajtów na następnym etapie przed wykonaniem kodu na tym etapie.
  • [C-1-5] MUSI używać algorytmów weryfikacji o mocy co najmniej takiej, jak zalecenia NIST dotyczące algorytmów szyfrowania (SHA-256) i rozmiarów kluczy publicznych (RSA-2048).
  • [C-1-6] NIE MOŻE zezwalać na ukończenie rozruchu, gdy weryfikacja systemu zakończy się niepowodzeniem, chyba że użytkownik wyrazi zgodę na podjęcie próby rozruchu. W takim przypadku NIE MOŻNA używać danych z żadnych niezweryfikowanych bloków pamięci.
  • [C-1-7] NIE MOŻE zezwalać na modyfikowanie zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokuje program rozruchowy.
  • [C-SR] Jeśli urządzenie zawiera wiele oddzielnych układów (np. radio, specjalistyczny procesor obrazu), ZDECYDOWANIE ZALECA SIĘ weryfikowanie każdego etapu procesu uruchamiania każdego z tych układów.
  • [C-1-8] MUSI używać pamięci odpornej na manipulacje: do przechowywania informacji o tym, czy program rozruchowy jest odblokowany. Oznacza to, że program rozruchowy może wykryć, czy pamięć została zmodyfikowana z poziomu Androida.
  • [C-1-9] MUSI wyświetlać użytkownikowi prośbę o potwierdzenie fizyczne podczas korzystania z urządzenia i wymagać takiego potwierdzenia przed zezwoleniem na przejście z trybu zablokowanego programu rozruchowego do trybu odblokowanego programu rozruchowego.
  • [C-1-10] MUSI wdrażać ochronę przed wycofaniem zmian w przypadku partycji używanych przez Androida (np. partycji rozruchowych i systemowych) oraz używać pamięci masowej odpornej na manipulacje do przechowywania metadanych używanych do określania minimalnej dopuszczalnej wersji systemu operacyjnego.
  • [C-SR] Zdecydowanie zaleca się weryfikowanie wszystkich plików APK aplikacji z uprawnieniami za pomocą łańcucha zaufania zakorzenionego w /system, który jest chroniony przez zweryfikowany rozruch.
  • [C-SR] Zdecydowanie zaleca się weryfikowanie wszystkich artefaktów wykonywalnych wczytywanych przez aplikację z uprawnieniami z zewnątrz pliku APK (np. dynamicznie wczytywanego lub skompilowanego kodu) przed ich wykonaniem lub zdecydowanie zaleca się, aby w ogóle ich nie wykonywać.
  • POWINNY wdrażać ochronę przed wycofaniem w przypadku wszystkich komponentów z trwałym oprogramowaniem (np. modemu, aparatu) i POWINNY używać pamięci odpornej na manipulacje do przechowywania metadanych używanych do określania minimalnej dopuszczalnej wersji.

Jeśli urządzenia zostały już wprowadzone na rynek bez obsługi wymagań C-1-8 do C-1-10 w starszej wersji Androida i nie można dodać obsługi tych wymagań za pomocą aktualizacji oprogramowania systemowego, MOGĄ zostać z nich zwolnione.

Projekt Android Open Source Project udostępnia preferowaną implementację tej funkcji w repozytorium external/avb/, którą można zintegrować z programem rozruchowym używanym do ładowania Androida.

Implementacje na urządzeniach:

Jeśli implementacje urządzeń obsługują interfejs Android Protected Confirmation API:

  • [C-3-1] MUSI zgłaszać true w przypadku interfejsu ConfirmationPrompt.isSupported() API.
  • [C-3-2] MUSI zapewnić, że bezpieczny sprzęt w pełni kontroluje wyświetlacz w taki sposób, aby system operacyjny Android nie mógł go zablokować bez wykrycia przez bezpieczny sprzęt.
  • [C-3-3] MUSI zapewnić, że bezpieczny sprzęt przejmuje pełną kontrolę nad ekranem dotykowym.

9.11. Klucze i dane uwierzytelniające

System Android Keystore umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i używanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub interfejsu Keystore API. Implementacje na urządzeniach:

  • [C-0-1] MUSI umożliwiać importowanie lub generowanie co najmniej 8192 kluczy.
  • [C-0-2] Uwierzytelnianie na ekranie blokady MUSI ograniczać liczbę prób i MUSI korzystać z algorytmu wykładniczego wycofywania. Po 150 nieudanych próbach opóźnienie MUSI wynosić co najmniej 24 godziny na próbę.
  • NIE POWINNO ograniczać liczby kluczy, które można wygenerować.

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady:

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

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

9.11.1. Bezpieczny ekran blokady

Implementacja AOSP jest zgodna z wielopoziomowym modelem uwierzytelniania, w którym podstawowe uwierzytelnianie oparte na czynniku wiedzy może być wspierane przez drugorzędne silne uwierzytelnianie biometryczne lub słabsze metody trzeciorzędne.

Implementacje na urządzeniach:

  • [C-SR] Zdecydowanie zalecamy ustawienie tylko jednej z tych metod jako podstawowej metody uwierzytelniania:
    • numeryczny kod PIN,
    • hasło alfanumeryczne;
    • wzorzec przesunięcia na siatce składającej się z 9 punktów (3 x 3).

Pamiętaj, że powyższe metody uwierzytelniania są w tym dokumencie określane jako zalecane podstawowe metody uwierzytelniania.

Jeśli implementacje urządzeń dodają lub modyfikują zalecane podstawowe metody uwierzytelniania i używają nowej metody uwierzytelniania jako bezpiecznego sposobu blokowania ekranu, nowa metoda uwierzytelniania:

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady na podstawie znanego sekretu, i używają nowej metody uwierzytelniania, która ma być traktowana jako bezpieczny sposób blokowania ekranu:

  • [C-3-1] Entropia najkrótszej dozwolonej długości danych wejściowych MUSI być większa niż 10 bitów.
  • [C-3-2] Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18 bitów.
  • [C-3-3] Nowa metoda uwierzytelniania NIE MOŻE zastępować żadnej z zalecanych podstawowych metod uwierzytelniania (tj. kodu PIN, wzoru, hasła) zaimplementowanych i udostępnianych w AOSP.
  • [C-3-4] Nowa metoda uwierzytelniania MUSI zostać wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasady dotyczące jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_SOMETHING.

Jeśli implementacje urządzeń dodają lub modyfikują zalecane podstawowe metody uwierzytelniania w celu odblokowania ekranu blokady i używają nowej metody uwierzytelniania opartej na danych biometrycznych, która jest traktowana jako bezpieczny sposób blokowania ekranu, nowa metoda:

  • [C-4-1] MUSI spełniać wszystkie wymagania opisane w sekcji 7.3.10.2.
  • [C-4-2] MUSI mieć mechanizm rezerwowy, który umożliwia korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania opartych na znanym sekrecie.
  • [C-4-3] MUSI być wyłączona i umożliwiać odblokowanie ekranu tylko za pomocą zalecanego uwierzytelniania podstawowego , gdy aplikacja kontrolera zasad urządzenia (DPC) ustawiła zasadę funkcji keguard, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures() z dowolną z powiązanych flag biometrycznych (np. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE lub KEYGUARD_DISABLE_IRIS).
  • [C-4-4] MUSI wymagać od użytkownika zalecanego podstawowego uwierzytelnienia (np. kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny lub rzadziej.
  • [C-4-5] MUSI mieć odsetek fałszywych akceptacji równy lub niższy niż wymagany w przypadku czytnika linii papilarnych zgodnie z opisem w sekcji 7.3.10. W przeciwnym razie MUSI być wyłączony i umożliwiać odblokowanie ekranu tylko za pomocą zalecanej podstawowej metody uwierzytelniania, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasady jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej rygorystyczną stałą jakości niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-SR] ZALECANE jest, aby miały współczynniki akceptacji fałszywych i podrobionych danych, które są równe lub wyższe niż wymagane w przypadku czytnika linii papilarnych, zgodnie z opisem w sekcji 7.3.10.
  • [C-4-6] MUSI mieć bezpieczny potok przetwarzania, tak aby naruszenie bezpieczeństwa systemu operacyjnego lub jądra nie umożliwiało bezpośredniego wstrzykiwania danych w celu fałszywego uwierzytelniania jako użytkownik.
  • [C-4-7] MUSI być połączony z wyraźnym działaniem potwierdzającym (np.naciśnięciem przycisku), aby umożliwić dostęp do kluczy magazynu kluczy, jeśli aplikacja ustawi wartość true dla parametru KeyGenParameterSpec.Built.setUserAuthenticationRequired(), a dane biometryczne są pasywne (np. twarz lub tęczówka, w przypadku których nie ma wyraźnego sygnału zamiaru).
  • [C-SR] Potwierdzenie działania w przypadku pasywnych danych biometrycznych ZDECYDOWANIE ZALECA się zabezpieczyć w taki sposób, aby naruszenie systemu operacyjnego lub jądra nie mogło go sfałszować. Oznacza to na przykład, że działanie potwierdzenia oparte na przycisku fizycznym jest kierowane przez ogólnego przeznaczenia pin wejścia/wyjścia (GPIO) tylko do wprowadzania danych w bezpiecznym elemencie (SE), którego nie można sterować w inny sposób niż przez naciśnięcie przycisku fizycznego.

Jeśli metody uwierzytelniania biometrycznego nie spełniają poziomów akceptacji fałszywych tożsamości i podszywania się pod inne osoby opisanych w sekcji 7.3.10:

  • [C-5-1] Metody MUSZĄ być wyłączone, jeśli aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasady jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() ze stałą jakością o większych ograniczeniach niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [C-5-2] Po 4-godzinnym okresie bezczynności użytkownik MUSI zostać poproszony o podanie zalecanego podstawowego uwierzytelnienia (np. kodu PIN, wzoru lub hasła). Okres bezczynności jest resetowany po każdym pomyślnym potwierdzeniu danych logowania na urządzenie.
  • [C-5-3] Metody NIE MOGĄ być traktowane jako bezpieczny ekran blokady i MUSZĄ spełniać wymagania, które zaczynają się od C-8 w tej sekcji poniżej.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania w celu odblokowania ekranu blokady, a nowa metoda uwierzytelniania jest oparta na fizycznym tokenie lub lokalizacji:

  • [C-6-1] Muszą mieć mechanizm rezerwowy, który umożliwia korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania opartych na znanym sekrecie i spełniających wymagania dotyczące bezpiecznego ekranu blokady.
  • [C-6-2] Nowa metoda MUSI być wyłączona i umożliwiać odblokowanie ekranu tylko za pomocą jednej z zalecanych podstawowych metod uwierzytelniania, gdy aplikacja kontrolera zasad urządzenia (DPC) ustawi zasady za pomocą metody DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) lub metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_UNSPECIFIED.
  • [C-6-3] Użytkownik MUSI być proszony o użycie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny lub rzadziej.
  • [C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI spełniać ograniczenia wymienione poniżej w sekcji C-8.

Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej 1 agenta zaufania, który implementuje interfejs TrustAgentService API systemu, to:

  • [C-7-1] W menu ustawień i na ekranie blokady musi być wyraźnie widoczna informacja o tym, że blokada urządzenia jest odroczona lub można ją odblokować za pomocą zaufanych usług. Na przykład AOSP spełnia to wymaganie, wyświetlając opis tekstowy ustawień „Automatyczne blokowanie” i „Przycisk zasilania natychmiast blokuje” w menu ustawień oraz charakterystyczną ikonę na ekranie blokady.
  • [C-7-2] MUSI respektować i w pełni implementować wszystkie interfejsy API agenta zaufania w klasie DevicePolicyManager, takie jak stała KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-7-3] NIE WOLNO w pełni implementować funkcji TrustAgentService.addEscrowToken() na urządzeniu, które jest używane jako główne urządzenie osobiste (np. urządzenie przenośne), ale MOŻNA w pełni implementować tę funkcję na urządzeniach, które są zwykle udostępniane (np. telewizor z Androidem lub urządzenie samochodowe).
  • [C-7-4] MUSI szyfrować wszystkie zapisane tokeny dodane przez TrustAgentService.addEscrowToken().
  • [C-7-5] NIE WOLNO przechowywać klucza szyfrowania na tym samym urządzeniu, na którym jest on używany. Na przykład klucz przechowywany na telefonie może odblokować konto użytkownika na telewizorze.
  • [C-7-6] MUSI poinformować użytkownika o konsekwencjach związanych z bezpieczeństwem przed włączeniem tokena depozytowego do odszyfrowania pamięci danych.
  • [C-7-7] MUSI mieć mechanizm rezerwowy, który umożliwia korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania.
  • [C-7-8] Użytkownik MUSI być proszony o użycie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny lub rzadziej.
  • [C-7-9] Po 4-godzinnym okresie bezczynności użytkownik MUSI zostać poproszony o użycie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru lub hasła). Okres bezczynności jest resetowany po każdym pomyślnym potwierdzeniu danych logowania na urządzenie.
  • [C-7-10] NIE MOŻE być traktowany jako bezpieczny ekran blokady i MUSI spełniać ograniczenia wymienione w punkcie C-8 poniżej.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania w celu odblokowania ekranu blokady, który nie jest bezpiecznym ekranem blokady opisanym powyżej, i używają nowej metody uwierzytelniania do odblokowania ekranu blokady:

9.11.2. StrongBox

System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w dedykowanym bezpiecznym procesorze, a także w opisanym powyżej odizolowanym środowisku wykonawczym.

Implementacje na urządzeniach:

  • [C-SR] Zdecydowanie zalecane jest obsługiwanie StrongBox.

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

  • [C-1-1] MUSI deklarować FEATURE_STRONGBOX_KEYSTORE.

  • [C-1-2] MUSI udostępniać dedykowany bezpieczny sprzęt, który jest używany do obsługi magazynu kluczy i bezpiecznego uwierzytelniania użytkownika.

  • [C-1-3] MUSI mieć osobny procesor, który nie współdzieli pamięci podręcznej, pamięci DRAM, koprocesorów ani innych zasobów podstawowych z procesorem aplikacji (AP).

  • [C-1-4] MUSI zapewnić, że żadne urządzenia peryferyjne udostępniane procesorowi aplikacji nie mogą w żaden sposób zmieniać przetwarzania w StrongBox ani uzyskiwać z niego żadnych informacji. Punkt dostępu MOŻE wyłączyć lub zablokować dostęp do StrongBox.

  • [C-1-5] MUSI mieć wewnętrzny zegar o rozsądnej dokładności (±10%), który jest odporny na manipulacje ze strony punktu dostępu.

  • [C-1-6] MUSI mieć generator prawdziwych liczb losowych, który generuje równomiernie rozłożone i nieprzewidywalne dane wyjściowe.

  • [C-1-7] MUSI być odporny na manipulacje, w tym na fizyczne wnikanie i błędy.

  • [C-1-8] MUSI być odporny na ataki z użyciem kanałów bocznych, w tym na wyciek informacji przez kanały boczne związane z zasilaniem, czasem, promieniowaniem elektromagnetycznym i promieniowaniem cieplnym.

  • [C-1-9] MUSI mieć bezpieczne miejsce do przechowywania, które zapewnia poufność, integralność, autentyczność, spójność i aktualność treści. Pamięci NIE WOLNO odczytywać ani zmieniać, z wyjątkiem przypadków dozwolonych przez interfejsy API StrongBox.

  • Aby potwierdzić zgodność z wymaganiami [C-1-3]–[C-1-9], implementacje urządzeń:

    • [C-1-10] MUSI zawierać sprzęt certyfikowany zgodnie z profilem ochrony układów scalonych BSI-CC-PP-0084-2014 lub oceniony przez akredytowane w danym kraju laboratorium testowe z uwzględnieniem oceny podatności na ataki o wysokim potencjale zgodnie z dokumentem Common Criteria Application of Attack Potential to Smartcards.
    • [C-1-11] MUSI zawierać oprogramowanie sprzętowe, które zostało ocenione przez akredytowane na poziomie krajowym laboratorium testowe z uwzględnieniem oceny podatności na ataki o wysokim potencjale zgodnie z dokumentem Common Criteria Application of Attack Potential to Smartcards.
    • [C-SR] Zdecydowanie zaleca się uwzględnienie sprzętu, który jest oceniany na podstawie profilu bezpieczeństwa, poziomu pewności oceny (EAL) 5, rozszerzonego o AVA_VAN.5. Certyfikat EAL 5 prawdopodobnie stanie się wymagany w przyszłej wersji.

  • [C-SR] są ZDECYDOWANIE ZALECANE, aby zapewnić odporność na ataki wewnętrzne (IAR), co oznacza, że osoba z dostępem do kluczy podpisywania oprogramowania sprzętowego nie może utworzyć oprogramowania sprzętowego, które powoduje wyciek informacji tajnych z StrongBox, ominięcie funkcjonalnych wymagań bezpieczeństwa ani w inny sposób umożliwić dostęp do poufnych danych użytkownika. Zalecanym sposobem wdrożenia IAR jest zezwalanie na aktualizacje oprogramowania tylko wtedy, gdy hasło użytkownika głównego jest podawane za pomocą interfejsu HAL IAuthSecret.

9.12. Usuwanie danych

Wszystkie implementacje na urządzeniach:

  • [C-0-1] MUSI udostępniać użytkownikom mechanizm przywracania danych fabrycznych.
  • [C-0-2] MUSI usunąć wszystkie dane wygenerowane przez użytkownika. Oznacza to, że masz dostęp do wszystkich danych z wyjątkiem tych:
    • Obraz systemu
    • wszystkie pliki systemu operacyjnego wymagane przez obraz systemu;
  • [C-0-3] MUSI usunąć dane w sposób zgodny z odpowiednimi standardami branżowymi, takimi jak NIST SP800-88.
  • [C-0-4] MUSI uruchamiać powyższy proces „Przywracanie ustawień fabrycznych”, gdy interfejs DevicePolicyManager.wipeData() API jest wywoływany przez aplikację Kontroler zasad urządzenia użytkownika podstawowego.
  • MOŻE udostępniać opcję szybkiego usuwania danych, która przeprowadza tylko logiczne usuwanie danych.

9.13. Tryb bezpiecznego rozruchu

Android udostępnia tryb bezpiecznego rozruchu, który umożliwia użytkownikom uruchamianie urządzenia w trybie, w którym działają tylko wstępnie zainstalowane aplikacje systemowe, a wszystkie aplikacje innych firm są wyłączone. Ten tryb, zwany „trybem bezpiecznego uruchamiania”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.

Implementacje urządzeń:

  • [SR] Zdecydowanie zalecamy wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacje urządzeń obsługują tryb bezpiecznego uruchamiania:

  • [C-1-1] MUSI udostępniać użytkownikowi opcję przejścia do trybu bezpiecznego rozruchu w sposób, który nie jest przerywany przez aplikacje innych firm zainstalowane na urządzeniu, z wyjątkiem sytuacji, gdy aplikacja innej firmy jest kontrolerem zasad dotyczących urządzeń i ustawiła flagę UserManager.DISALLOW_SAFE_BOOT na wartość „prawda”.

  • [C-1-2] MUSI umożliwiać użytkownikowi odinstalowanie dowolnych aplikacji innych firm w trybie bezpiecznym.

  • POWINIEN udostępniać użytkownikowi opcję przejścia do trybu awaryjnego z menu rozruchu za pomocą procesu innego niż w przypadku normalnego rozruchu.

9.14. Izolacja systemu pojazdu samochodowego

Urządzenia z Androidem Automotive powinny wymieniać dane z krytycznymi podsystemami pojazdu za pomocą HAL pojazdu, aby wysyłać i odbierać wiadomości w sieciach pojazdu, takich jak magistrala CAN.

Wymiana danych może być zabezpieczona przez wdrożenie funkcji zabezpieczeń poniżej warstw platformy Android, aby zapobiec złośliwym lub niezamierzonym interakcjom z tymi podsystemami.

9.15. Abonamenty

„Abonamenty” to szczegóły planu rozliczeniowego udostępniane przez operatora sieci komórkowej za pomocą SubscriptionManager.setSubscriptionPlans().

Wszystkie implementacje na urządzeniach:

  • [C-0-1] MUSI zwracać plany subskrypcji tylko do aplikacji operatora komórkowego, która pierwotnie je udostępniła.
  • [C-0-2] NIE MOŻE zdalnie tworzyć kopii zapasowych ani przesyłać abonamentów.
  • [C-0-3] MUSI zezwalać na zastępowanie, np. SubscriptionManager.setSubscriptionOverrideCongested(), tylko w przypadku aplikacji operatora komórkowego, który obecnie oferuje ważne abonamenty.

10. Testowanie zgodności oprogramowania

Implementacje urządzeń MUSZĄ przejść wszystkie testy opisane w tej sekcji. Pamiętaj jednak, że żaden pakiet testów oprogramowania nie jest w pełni kompleksowy. Dlatego ZDECYDOWANIE ZALECA SIĘ, aby producenci urządzeń wprowadzali jak najmniej zmian w referencyjnej i preferowanej implementacji Androida dostępnej w ramach Projektu Android Open Source. Zminimalizuje to ryzyko wprowadzenia błędów, które powodują niezgodności wymagające ponownej pracy i potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje na urządzeniach:

  • [C-0-1] MUSI przejść pakiet testów zgodności z Androidem (CTS) dostępny w ramach Projektu Android Open Source, korzystając z ostatecznej wersji oprogramowania dostarczanej na urządzeniu.

  • [C-0-2] MUSI zapewniać zgodność w przypadku niejednoznaczności w CTS i w przypadku ponownego wdrożenia części referencyjnego kodu źródłowego.

Zestaw CTS jest przeznaczony do uruchamiania na rzeczywistym urządzeniu. Podobnie jak każde inne oprogramowanie, CTS może zawierać błędy. Pakiet CTS będzie wersjonowany niezależnie od tej definicji zgodności, a w przypadku Androida 9 może zostać opublikowanych kilka jego wersji.

Implementacje na urządzeniach:

  • [C-0-3] MUSI przejść najnowszą wersję CTS dostępną w momencie ukończenia oprogramowania urządzenia.

  • W miarę możliwości powinny korzystać z implementacji referencyjnej w drzewie Android Open Source.

10.2. Weryfikator CTS

Weryfikator CTS jest częścią pakietu testów zgodności i jest przeznaczony do uruchamiania przez operatora w celu testowania funkcji, których nie można sprawdzić za pomocą systemu automatycznego, np. prawidłowego działania kamery i czujników.

Implementacje na urządzeniach:

  • [C-0-1] MUSI prawidłowo wykonać wszystkie odpowiednie przypadki w weryfikatorze CTS.

Weryfikator CTS zawiera testy wielu rodzajów sprzętu, w tym niektórych opcjonalnych.

Implementacje na urządzeniach:

  • [C-0-2] MUSZĄ przejść wszystkie testy sprzętu, który posiadają. Jeśli na przykład urządzenie ma akcelerometr, MUSI prawidłowo wykonać test akcelerometru w CTS Verifier.

Przypadki testowe funkcji oznaczonych w tym dokumencie definicji zgodności jako opcjonalne MOŻNA pominąć.

  • [C-0-2] Każde urządzenie i każda kompilacja MUSZĄ prawidłowo uruchamiać weryfikator CTS zgodnie z powyższymi informacjami. Jednak ponieważ wiele kompilacji jest bardzo podobnych, nie oczekuje się, że producenci urządzeń będą uruchamiać weryfikator CTS na kompilacjach, które różnią się tylko w niewielkim stopniu. W szczególności implementacje urządzeń, które różnią się od implementacji, która przeszła test CTS Verifier, tylko zestawem uwzględnionych ustawień regionalnych, brandingiem itp., MOGĄ pominąć test CTS Verifier.

11. Oprogramowanie z możliwością aktualizacji

  • [C-0-1] Implementacje urządzeń MUSZĄ zawierać mechanizm umożliwiający zastąpienie całego oprogramowania systemowego. Mechanizm nie musi przeprowadzać aktualizacji „na żywo”, czyli ponowne uruchomienie urządzenia MOŻE być wymagane. Możesz użyć dowolnej metody, o ile pozwala ona zastąpić całe oprogramowanie fabrycznie zainstalowane na urządzeniu. Wymaganie to spełnia np. każda z tych metod:

    • Pobieranie „bezprzewodowe” (OTA) z aktualizacją offline po ponownym uruchomieniu.
    • „Przywiązane” aktualizacje przez USB z komputera hosta.
    • Aktualizacje „offline” przez ponowne uruchomienie i aktualizację z pliku na nośniku wymiennym.

  • [C-0-2] Używany mechanizm aktualizacji MUSI obsługiwać aktualizacje bez usuwania danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachowywać prywatne dane aplikacji i dane udostępnione aplikacji. Pamiętaj, że oprogramowanie Androida wyższego poziomu zawiera mechanizm aktualizacji, który spełnia to wymaganie.

Jeśli implementacja urządzenia obejmuje obsługę połączenia do transmisji danych bez limitu, np. 802.11 lub profilu Bluetooth PAN (Personal Area Network), to:

  • [C-1-1] MUSI obsługiwać pobieranie aktualizacji OTA z aktualizacją offline po ponownym uruchomieniu.

W przypadku urządzeń wprowadzanych na rynek z Androidem 6.0 lub nowszym mechanizm aktualizacji POWINIEN obsługiwać weryfikację, czy obraz systemu jest binarnie identyczny z oczekiwanym wynikiem po aktualizacji OTA. Wdrożenie aktualizacji OTA opartej na blokach w projekcie Android Open Source Project, dodane w Androidzie 5.1, spełnia to wymaganie.

Implementacje urządzeń POWINNY też obsługiwać aktualizacje systemu A/B. AOSP implementuje tę funkcję za pomocą interfejsu HAL sterowania rozruchem.

Jeśli po wprowadzeniu urządzenia na rynek, ale w rozsądnym okresie jego użytkowania (określonym w porozumieniu z zespołem ds. zgodności Androida) zostanie wykryty błąd w jego implementacji, który wpływa na zgodność aplikacji innych firm, wówczas:

  • [C-2-1] Producent urządzenia MUSI naprawić błąd za pomocą aktualizacji oprogramowania, którą można zastosować zgodnie z opisanym powyżej mechanizmem.

Android zawiera funkcje, które umożliwiają aplikacji właściciela urządzenia (jeśli jest obecna) kontrolowanie instalacji aktualizacji systemu. Jeśli podsystem aktualizacji systemu na urządzeniach zgłasza android.software.device_admin, oznacza to, że:

12. Historia zmian dokumentu

Podsumowanie zmian w definicji zgodności w tej wersji:

Podsumowanie zmian w poszczególnych sekcjach:

  1. Wprowadzenie
  2. Typy urządzeń
  3. Oprogramowanie
  4. Pakowanie aplikacji
  5. Multimedia
  6. Narzędzia i opcje dla programistów
  7. Zgodność sprzętu
  8. Wydajność i zasilanie
  9. Model zabezpieczeń
  10. Testowanie zgodności oprogramowania
  11. Oprogramowanie, które można aktualizować
  12. Historia zmian dokumentu
  13. Skontaktuj się z nami

12.1. Wskazówki dotyczące przeglądania historii zmian

Zmiany są oznaczone w ten sposób:

  • CDD
    Istotne zmiany w wymaganiach dotyczących zgodności.

  • Dokumenty
    Zmiany kosmetyczne lub związane z kompilacją.

Aby uzyskać najlepszy widok, dołącz do adresów URL dziennika zmian parametry URL pretty=full i no-merges.

13. Skontaktuj się z nami

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