Definicja zgodności z Androidem 10

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

1. Wprowadzenie

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

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

W tym dokumencie „implementator urządzenia” to osoba lub organizacja opracowująca rozwiązanie sprzętowe lub programowe z Androidem 10. „Wdrożenie urządzenia” lub „wdrożenie” to opracowane rozwiązanie sprzętowe lub programowe.

Aby uznać implementację urządzenia za zgodną z Androidem 10, MUSI ona spełniać wymagania podane w tej definicji zgodności, w tym wszelkie dokumenty włączone przez odwołanie.

Jeśli definicja lub testy oprogramowania opisane w sekcji 10 są niejasne, niepełne lub nieprecyzyjne, implementator urządzenia musi zadbać o zgodność z dotychczasowymi implementacjami.

Z tego powodu Android Open Source Project jest zarówno referencyjnym, jak i preferowanym wdrożeniem Androida. Wdrożeniom urządzeń MOCNO zaleca się, aby w jak największym stopniu opierać swoje implementacje na „upstreamowym” 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 nie stosować tej praktyki, ponieważ przejście testów oprogramowania będzie znacznie trudniejsze. Obowiązkiem implementatora jest zapewnienie pełnej zgodności z zachowaniem standardowej implementacji Androida, w tym w ramach pakietu testów zgodności i poza nim. Pamiętaj, że niektóre zamiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.

Wiele zasobów, do których linki znajdują się w tym dokumencie, pochodzi bezpośrednio lub pośrednio z Android SDK i będzie funkcjonalnie identyczne z informacjami w dokumentacji tego pakietu. W każdym przypadku, gdy definicja zgodności lub zestaw testów zgodności są niezgodne z dokumentacją pakietu SDK, decydująca jest dokumentacja pakietu SDK. Wszelkie szczegóły techniczne podane w powiązanych zasobach w tym dokumencie są uznawane za część tej definicji zgodności.

1.1 Struktura dokumentu

1.1.1. Wymagania według typu urządzenia

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

Pozostałe wymagania, które obowiązują w przypadku wszystkich implementacji urządzeń z Androidem, są wymienione w sekcjach po sekcji 2. W tym dokumencie te wymagania są określane jako „Wymagania podstawowe”.

1.1.2. Identyfikator wymagań

Identyfikator wymagania jest przypisany do wymagań MUST.

• Identyfikator jest przypisany tylko do wymagań MUST.
• Wymagania ZALECANE są oznaczone jako [SR], ale nie mają przypisanego identyfikatora.
• Identyfikator składa się z identyfikatora typu urządzenia, identyfikatora stanu i identyfikatora wymagań (np. C-0-1).

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

• Identyfikator typu urządzenia (więcej informacji znajdziesz w sekcji 2. Typy urządzeń)
  • C: Core (wymagania stosowane do wszystkich implementacji na urządzeniach z Androidem)
  • H: urządzenie przenośne z Androidem
  • T: urządzenie z Androidem TV
  • Odp.: wdrożenie Androida Automotive
  • W: Implementacja na zegarku z Androidem
  • Karta: implementacja na tabletach z Androidem
• Identyfikator warunku
  • Gdy wymaganie jest bezwarunkowe, ten identyfikator ma wartość 0.
  • Jeśli wymagania są warunkowe, dla pierwszego warunku przypisuje się wartość 1, a w ramach tej samej sekcji i tego samego typu urządzenia liczba ta zwiększa się o 1.
• Identyfikator wymagań:
  • Ten identyfikator zaczyna się od 1 i zwiększa się o 1 w tej samej sekcji i przy tej samej wartości warunku.

1.1.3. Identyfikator wymagań w sekcji 2

Identyfikator wymagań w sekcji 2 zaczyna się od odpowiedniego identyfikatora sekcji, a za nim następuje identyfikator wymagań opisany powyżej.

• Identyfikator w sekcji 2 składa się z identyfikatora sekcji / identyfikatora typu urządzenia – identyfikatora warunku – identyfikatora wymagań (np. 7.4.3/A-0-1).

2. Typy urządzeń

Chociaż projekt Android Open Source udostępnia pakiet oprogramowania, który można stosować na różnych typach i w różnych formach urządzeń, istnieje kilka typów urządzeń, które mają stosunkowo lepiej rozwiniętą platformę dystrybucji aplikacji.

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

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

2.1 Konfiguracje urządzenia

Najważniejsze różnice w konfiguracji sprzę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ęku, np. odtwarzacz MP3, telefon lub tablet.

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

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

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

2.2.1. Sprzęt

Implementacje na urządzeniach przenośnych:

• [7.1.1.1/H-0-1] Musi być co najmniej 1 wyświetlacz zgodny z Androidem o fizycznej przekątnej co najmniej 2,5 cala.Każdy wyświetlacz zgodny z Androidem MUSI spełniać wszystkie wymagania opisane w tym dokumencie.
• [7.1.1.3/H-SR] Zdecydowanie zalecamy, aby umożliwić użytkownikom zmianę rozmiaru wyświetlacza (gęstości ekranu).

Jeśli implementacje urządzeń przenośnych obsługują wyświetlacze o wysokim zakresie dynamicznym za pomocą Configuration.isScreenHdr() , muszą:

• [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 zawierać obsługę starszego trybu zgodności aplikacji, który jest implementowany przez kod źródłowy Androida open source. Oznacza to, że implementacje na urządzeniach NIE MOGĄ zmieniać wyzwalaczy ani progów, przy których aktywowany jest tryb zgodności, ani zmieniać działania samego trybu zgodności.
• [7.2.1/H-0-1] MUSI zawierać obsługę aplikacji innych firm do edycji metody wprowadzania.
• [7.2.3/H-0-3] Musisz udostępniać funkcję „Strona główna” na wszystkich wyświetlaczach zgodnych z Androidem, które mają ekran główny.
• [7.2.3/H-0-4] MUSI zawierać funkcję Wstecz na wszystkich wyświetlaczach zgodnych z Androidem oraz funkcję Ostatnie na co najmniej jednym wyświetlaczu zgodnym z Androidem.
• [7.2.3/H-0-2] DO aplikacji na pierwszym planie należy wysłać zdarzenie naciśnięcia i długiego naciśnięcia przycisku Wstecz (KEYCODE_BACK). Te zdarzenia NIE MOGĄ być wykorzystywane przez system i MOGĄ być wywoływane z zewnątrz urządzenia z Androidem (np. za pomocą zewnętrznej klawiatury sprzętowej podłączonej 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] W przypadku długiego naciśnięcia przycisku KEYCODE_MEDIA_PLAY_PAUSE lub KEYCODE_HEADSETHOOK (jeśli aktywność na pierwszym planie nie obsługuje tych zdarzeń długiego naciśnięcia) MOCNO zaleca się uruchamianie wybranej przez użytkownika aplikacji asystującej, czyli aplikacji, która implementuje interfejs VoiceInteractionService, lub aktywności obsługującej zdarzenie ACTION_ASSIST.
• [7.3.1/H-SR] MOCNO zaleca się uwzględnienie 3-osiowego akcelerometru.

Jeśli implementacja urządzenia przenośnego zawiera 3-osiowy akcelerometr, urządzenie:

• [7.3.1/H-1-1] MUSI być w stanie zgłaszać zdarzenia z częstotliwością co najmniej 100 Hz.

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

• [7.3.3/H-2-1] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
• [7.3.3/H-2-2] MUST report GNSS pseudoranges and pseudorange rates, that, in conditions open-sky after determining the location, while stationary or moving with less than 0.2 meter per second squared of acceleration, are sufficient to calculate position within 20 meters, and speed within 0.2 meters per second, at least 95% of the time.

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

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

Implementacje urządzeń przenośnych, które mogą nawiązywać połączenia głosowe i wskazywać dowolną wartość inną niż PHONE_TYPE_NONE w pliku getPhoneType:

• [7.3.8/H] NALEŻY uwzględnić czujnik zbliżeniowy.

Implementacje na urządzeniach przenośnych:

• [7.3.11/H-SR] Zaleca się obsługę czujnika postawy z 6 stopniami swobody.
• [7.4.3/H] NALEŻY uwzględnić obsługę Bluetooth i Bluetooth LE.

Jeśli implementacje urządzeń przenośnych obejmują połączenie z licznikiem, mogą:

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

Jeśli implementacje urządzeń przenośnych zawierają logiczne urządzenie z kamerą, które wymienia funkcje za pomocą CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, to:

• [7.5.4/H-1-1] Domyślnie musi mieć normalne pole widzenia (FOV) w zakresie 50–90 stopni.

Implementacje na urządzeniach przenośnych:

• [7.6.1/H-0-1] Na potrzeby danych prywatnych aplikacji (czyli partycji „/data”) musi być dostępne co najmniej 4 GB pamięci nieulotnej.
• [7.6.1/H-0-2] MUSI zwracać „true” dla ActivityManager.isLowRamDevice(), gdy dla jądra i przestrzeni użytkownika jest dostępne mniej niż 1 GB pamięci.

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

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

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

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

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

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

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

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

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

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

Uwaga: „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do pamięci dostępnej oprócz pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro w implementacjach urządzenia.

Jeśli implementacje urządzeń przenośnych mają mniej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, nie spełniają wymagań:

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

Jeśli implementacje urządzeń przenośnych zawierają więcej niż 1 GB pamięci dostępnej dla jądra i przestrzeni użytkownika, muszą:

• [7.6.1/H-10-1] Musi być dostępne co najmniej 4 GB pamięci nieulotnej na potrzeby danych prywatnych aplikacji (czyli na partycji „/data”).
• NALEŻY zadeklarować flagę funkcji android.hardware.ram.normal.

Implementacje na urządzeniach przenośnych:

• [7.6.2/H-0-1] NIE MOŻESZ udostępnić aplikacji miejsca na dane mniejszego niż 1 GiB.
• [7.7.1/H] NALEŻY uwzględnić port USB obsługujący tryb peryferyjny.

Jeśli implementacje urządzeń przenośnych zawierają port USB obsługujący tryb urządzeń peryferyjnych, muszą:

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

Jeśli implementacje urządzeń przenośnych zawierają port USB obsługujący tryb hosta, muszą:

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

Implementacje na urządzeniach przenośnych:

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

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

• [7.9.1/H-1-1] NALEŻY zadeklarować flagę funkcji android.hardware.vr.high_performance.
• [7.9.1/H-1-2] Musisz umieścić w aplikacji implementację android.service.vr.VrListenerService, którą aplikacje VR mogą włączyć za pomocą android.app.Activity#setVrModeEnabled.

Jeśli implementacje urządzeń przenośnych zawierają co najmniej 1 port USB-C w trybie hosta i implementują (klasa audio USB), oprócz wymagań podanych w sekcji 7.7.2:

• [7.8.2.2/H-1-1] NALEŻY podać następujące mapowanie kodu HID w oprogramowaniu:

• [7.8.2.2/H-1-2] NALEŻY wywołać ACTION_HEADSET_PLUG po włożeniu wtyczki, ale dopiero po prawidłowym zliczeniu interfejsów audio USB i punktów końcowych w celu identyfikacji typu podłączonego terminala.

Po wykryciu terminala audio USB typu 0x0302:

• [7.8.2.2/H-2-1] MUST broadcast Intent ACTION_HEADSET_PLUG with "microphone" extra set to 0.

Gdy wykryto typy terminali audio USB 0x0402,:

• [7.8.2.2/H-3-1] MUST broadcast Intent ACTION_HEADSET_PLUG with "microphone" extra set to 1.

Gdy wywołysz interfejs API AudioManager.getDevices() podczas podłączania urządzenia peryferyjnego USB, wykonaj te czynności:

• [7.8.2.2/H-4-1] NALEŻY podać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i role isSink(), jeśli pole typu terminala audio USB ma wartość 0x0302.

• [7.8.2.2/H-4-2] NALEŻY podać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i role isSink(), jeśli pole typu terminala audio USB ma wartość 0x0402.

• [7.8.2.2/H-4-3] NALEŻY podać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i role isSource(), jeśli pole typu terminala audio USB ma wartość 0x0402.

• [7.8.2.2/H-4-4] Musisz podać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSink(), jeśli pole typu terminala audio USB ma wartość 0x603.

• [7.8.2.2/H-4-5] MUST list a device of type AudioDeviceInfo.TYPE_USB_DEVICE and role isSource() if the USB audio terminal type field is 0x604.

• [7.8.2.2/H-4-6] NALEŻY podać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSink(), jeśli pole typu terminala audio USB ma wartość 0x400.

• [7.8.2.2/H-4-7] W przypadku pola typu terminala audio USB o wartości 0x400 MUSI być podany typ urządzenia AudioDeviceInfo.TYPE_USB_DEVICE i rola isSource().

• [7.8.2.2/H-SR] W przypadku podłączenia urządzenia peryferyjnego do przesyłania dźwięku za pomocą złącza USB-C MOCNO zaleca się wykonanie enumeracji opisów USB, identyfikację typów terminali i wysłanie intencji ACTION_HEADSET_PLUG w mniej niż 1000 ms.

2.2.2. Multimedia

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

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] Profil MPEG-4 AAC (AAC LC)
• [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
• [5.1/H-0-5] AAC ELD (ulepszona jakość dźwięku AAC z małym opóźnieniem)

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

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

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

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

2.2.3. Oprogramowanie

Implementacje na urządzeniach przenośnych:

• [3.2.3.1/H-0-1] Aplikacja MUSI obsługiwać intencje ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE i ACTION_CREATE_DOCUMENT zgodnie z opisem w dokumentacji pakietu SDK oraz udostępniać użytkownikowi możliwość uzyskania dostępu do danych dostawcy dokumentów za pomocą interfejsu API DocumentsProvider.
• [3.4.1/H-0-1] Musisz wdrożyć interfejs API android.webkit.Webview.
• [3.4.2/H-0-1] Musisz udostępnić samodzielną aplikację przeglądarki do ogólnego przeglądania Internetu przez użytkownika.
• [3.8.1/H-SR] MOCNO POLECAMY wdrożenie domyślnej aplikacji, która obsługuje przypinanie skrótów, widżetów i widgetFeatures w aplikacji.
• [3.8.1/H-SR] MOCNO zalecamy wdrożenie domyślnej aplikacji, która zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu ShortcutManager API.
• [3.8.1/H-SR] MOCNO ZALECAMY dodanie domyślnej aplikacji uruchamiającej, która wyświetla plakietki dla ikon aplikacji.
• [3.8.2/H-SR] Zaleca się, aby obsługiwać widżety aplikacji innych firm.
• [3.8.3/H-0-1] Musisz zezwolić aplikacjom innych firm na powiadamianie użytkowników o istotnych zdarzeniach za pomocą klas interfejsu API Notification i NotificationManager.
• [3.8.3/H-0-2] Musi obsługiwać powiadomienia z elementami rozszerzonymi.
• [3.8.3/H-0-3] MUSI obsługiwać powiadomienia w ramkach.
• [3.8.3/H-0-4] Musi zawierać panel powiadomień, który umożliwia użytkownikowi bezpośrednie zarządzanie powiadomieniami (np. odpowiadanie na nie, odkładanie, zamykanie i blokowanie) za pomocą przycisków akcji lub panelu sterowania zaimplementowanego w AOSP.
• [3.8.3/H-0-5] W polu powiadomień MUSI wyświetlać opcje udostępnione w RemoteInput.Builder setChoices().
• [3.8.3/H-SR] ZALECAMY wyświetlanie w pasku powiadomień pierwszej opcji dostępnej w RemoteInput.Builder setChoices() bez dodatkowej interakcji użytkownika.
• [3.8.3/H-SR] ZALECAMY wyświetlanie wszystkich opcji udostępnionych w RemoteInput.Builder setChoices() w obszarze powiadomień, gdy użytkownik rozwinie wszystkie powiadomienia w obszarze powiadomień.
• [3.8.3.1/H-SR] NALEŻY WYŚWIETLAC OPCJE, dla których Notification.Action.Builder.setContextual jest ustawiona jako true zgodnie z odpowiedziami wyświetlanymi przez Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR] MOCNO POLECAMY wdrożenie na urządzeniu asystenta, który będzie obsługiwał działanie asystenta.

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

• [3.8.4/H-SR] MOCNO POLECAMY użycie długiego naciśnięcia przycisku HOME jako wyznaczonej interakcji w celu uruchomienia aplikacji asystenta zgodnie z opisem w sekcji 7.2.3. MUSI uruchamiać wybraną przez użytkownika aplikację asystenta, czyli aplikację, która implementuje VoiceInteractionService, lub aktywność obsługującą intencję ACTION_ASSIST.

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

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

Jeśli implementacje urządzeń przenośnych obsługują bezpieczny ekran blokady, to:

• [3.9/H-1-1] NALEŻY wdrożyć pełny zakres zasad zarządzania 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ło się jako urządzenie z małą ilością pamięci RAM lub przydzielało pamięć wewnętrzną (niewymienną) jako pamięć współdzielona.

Implementacje na urządzeniach przenośnych:

• [3.10/H-0-1] MUSI obsługiwać usługi dostępności innych firm.
• [3.10/H-SR] Zdecydowanie zalecamy wstępne załadowanie na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z funkcjonalnością usług Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) w ramach projektu TalkBack open source.
• [3.11/H-0-1] MUSI obsługiwać instalację zewnętrznych silników TTS.
• [3.11/H-SR] MOCNO zaleca się uwzględnienie silnika TTS obsługującego języki dostępne na urządzeniu.
• [3.13/H-SR] ZALECAMY DODANIE komponentu UI Szybkich ustawień.

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

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

Jeśli funkcja nawigacji jest obsługiwana jako działanie na ekranie oparte na gestach:

• [7.2.3/H] Strefa rozpoznawania gestów w funkcji Home powinna mieć wysokość nie większą niż 32 dp od dołu ekranu.

Jeśli implementacje na urządzeniach przenośnych umożliwiają nawigację za pomocą gestów wykonywanych w dowolnym miejscu po lewej i prawej stronie ekranu:

• [7.2.3/H-0-1] Szerokość obszaru gestów funkcji nawigacji MUSI być mniejsza niż 40 dp po każdej stronie. Domyślna szerokość obszaru gestów powinna wynosić 24 dp.

2.2.4. Wydajność i moc

• [8.1/H-0-1] Stała wartość opóźnienia ramki. Niespójny czas oczekiwania na wyświetlenie lub opóźnienie w renderowaniu klatek NIE MOŻE występować częściej niż 5 razy na sekundę, a liczba klatek na sekundę powinna być mniejsza niż 1.
• [8.1/H-0-2] Czas reakcji interfejsu użytkownika. Implementacje urządzeń MUSZĄ zapewniać użytkownikom niskie opóźnienia, umożliwiając przewijanie listy 10 tys. pozycji na liście w mniej niż 36 sekund, zgodnie z definicją w pakiecie testów zgodności (CTS) Androida.
• [8.1/H-0-3] Przełączanie zadań. Gdy uruchomionych jest kilka aplikacji, ponowne uruchomienie już uruchomionej aplikacji MUSI zająć mniej niż 1 sekundę.

Implementacje na urządzeniach przenośnych:

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

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

• [8.3/H-1-1] MUSISZ umożliwić użytkownikowi włączenie i wyłączenie funkcji oszczędzania baterii.
• [8.3/H-1-2] Musisz umożliwić użytkownikowi wyświetlanie wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.

Implementacje na urządzeniach przenośnych:

• [8.4/H-0-1] MUSI zawierać profil poboru mocy dla poszczególnych komponentów, który definiuje bieżącą wartość poboru energii dla każdego komponentu sprzętowego oraz przybliżony pobór energii z baterii spowodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie Projektu Android Open Source.
• [8.4/H-0-2] Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
• [8.4/H-0-3] MUST report CPU power consumption per each process's UID. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/H-0-4] DEWELOPER APLIKACJI MUSI udostępnić ten pobór mocy za pomocą polecenia adb shell dumpsys batterystats w powłoce.
• [8,4/h] NALEŻY przypisać do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.

Jeśli implementacje urządzeń przenośnych obejmują ekran lub wyjście wideo, muszą spełniać te wymagania:

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

2.2.5. Model zabezpieczeń

Implementacje na urządzeniach przenośnych:

• [9.1/H-0-1] Musisz zezwolić aplikacjom innych firm na dostęp do statystyk użycia za pomocą uprawnienia android.permission.PACKAGE_USAGE_STATS i zapewnić użytkownikom mechanizm umożliwiający przyznawanie i odbieranie dostępu do takich aplikacji w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS.

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

• [9.11/H-0-2]* Musisz utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
• [9.11/H-0-3]* Musisz mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać obsługiwane algorytmy systemu Keystore na Androidzie w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i powyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source Project (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
• [9.11/H-0-4]* NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonywania i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem tylko wtedy, gdy proces uwierzytelniania zakończy się sukcesem. Dane uwierzytelniające na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w odizolowanym środowisku wykonania. Wspólny projekt Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.
• [9.11/H-0-5]* MUSI obsługiwać atestacjowanie klucza, w którym klucz podpisujący jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania certyfikatów MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻE być używany inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi spełniać wymagań dotyczących posiadania repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania i obsługiwania uwierzytelniania klucza, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania.

Gdy implementacje urządzeń przenośnych obsługują bezpieczny ekran blokady, mogą:

• [9.11/H-1-1] Musisz umożliwić użytkownikowi wybranie najkrótszego czasu bezczynności, czyli czasu przejścia z niezablokowanego do zablokowanego stanu, w długości nie większej niż 15 sekund.
• [9.11/H-1-2] MUSISZ umożliwić użytkownikowi ukrywanie powiadomień i wyłączanie wszystkich form uwierzytelniania z wyjątkiem podstawowego uwierzytelniania opisanego w sekcji 9.11.1 Bezpieczny ekran blokady. AOSP spełnia wymagania dotyczące trybu blokady.

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

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

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

• [9.5/H-3-1] NIE MUSI obsługiwać profili z ograniczonymi uprawnieniami, ale MUSI być zgodny z implementacją ustawień w AOSP, aby umożliwić /zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

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

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

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

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

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

2.3. Wymagania dotyczące telewizorów

Urządzenie Android TV to urządzenie z Androidem, które jest interfejsem rozrywkowym do korzystania z multimediów cyfrowych, filmów, gier, aplikacji lub telewizji na żywo. Jest przeznaczone dla użytkowników, którzy siedzą w odległości około 3 metrów (interfejs „lean back” lub „10-foot user interface”).

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

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

Pozostałe wymagania w tej sekcji dotyczą implementacji na urządzeniach z Androidem TV.

2.3.1. Sprzęt

Implementacje na telewizorach:

• [7.2.2/T-0-1] MUSI obsługiwać D-pad.
• [7.2.3/T-0-1] MUSI zawierać funkcje Wróć i Strona główna.
• [7.2.3/T-0-2] DO aplikacji na pierwszym planie należy wysłać zdarzenie naciśnięcia i długiego naciśnięcia przycisku Wstecz (KEYCODE_BACK).
• [7.2.6.1/T-0-1] MUSI zawierać obsługę kontrolerów gier i ogłosić flagę funkcji android.hardware.gamepad.
• [7.2.7/T] NALEŻY zapewnić zdalne sterowanie, za pomocą którego użytkownicy mogą korzystać z nawigacji bezdotykowej i podstawowych przycisków nawigacyjnych.

Jeśli implementacje telewizorów zawierają 3-osiowy żyroskop, muszą:

• [7.3.4/T-1-1] Musi być możliwe raportowanie zdarzeń z częstotliwością co najmniej 100 Hz.
• [7.3.4/T-1-2] MUSI być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.

Implementacje na telewizorach:

• [7.4.3/T-0-1] MUSI obsługiwać Bluetooth i Bluetooth LE.
• [7.6.1/T-0-1] Na potrzeby prywatnych danych aplikacji (czyli partycji „/data”) musi być dostępne co najmniej 4 GB pamięci nieulotnej.

Jeśli implementacje telewizorów zawierają port USB obsługujący tryb hosta, muszą:

• [7.5.3/T-1-1] MUSI zawierać obsługę zewnętrznej kamery, która jest podłączona przez ten port USB, ale nie zawsze musi być podłączona.

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

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

  • 400 dpi lub więcej na małych/normalnych ekranach
  • xhdpi lub wyższa na dużych ekranach
  • tvdpi lub wyższa na bardzo dużych ekranach.

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

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

  • 400 dpi lub więcej na małych/normalnych ekranach
  • xhdpi lub wyższa na dużych ekranach
  • tvdpi lub wyższa na bardzo dużych ekranach.

Uwaga: „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do pamięci dostępnej oprócz pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro w implementacjach urządzenia.

Implementacje na telewizorach:

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

2.3.2. Multimedia

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

• [5.1/T-0-1] Profil MPEG-4 AAC (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/T-0-3] AAC ELD (ulepszona jakość dźwięku AAC z małym opóźnieniem)

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

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

Implementacje na telewizorach:

• [5.2.2/T-SR] MOCNO POLECAMY obsługę kodowania H.264 filmów w rozdzielczości 720p i 1080p z szybkością 30 klatek na sekundę.

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

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

Implementacje urządzeń telewizyjnych MUSZĄ obsługiwać dekodowanie MPEG-2 zgodnie z opisem w sekcji 5.3.1 przy standardowych częstotliwościach klatek i rozdzielczościach do:

• [5.3.1/T-1-1] HD 1080p przy 29,97 klatek na sekundę z profilem głównym High Level.
• [5.3.1/T-1-2] HD 1080i przy 59,94 klatkach na sekundę z profilem głównym High Level. Muszą deinterlować przeplotowane wideo MPEG-2 i udostępnić je aplikacjom innych firm.

Implementacje urządzeń telewizyjnych MUSZĄ obsługiwać dekodowanie H.264 zgodnie z opisem w sekcji 5.3.4 przy standardowych częstotliwościach klatek i rozdzielczościach do:

• [5.3.4/T-1-1] HD 1080p przy 60 klatkach na sekundę z profilem podstawowym
• [5.3.4/T-1-2] HD 1080p przy 60 klatkach na sekundę z profilem głównym
• [5.3.4/T-1-3] HD 1080p przy 60 klatkach na sekundę z profilem wysokim poziomu 4.2

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

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

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

• [5.3.5/T-2-1] MUSI obsługiwać profil dekodowania UHD z szybkością 60 FPS w profilu Main10 poziomu 5.

Implementacje telewizorów MUSZĄ obsługiwać dekodowanie VP8 zgodnie z opisem w sekcji 5.3.6 przy standardowych częstotliwościach klatek i rozdzielczościach wideo do:

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

Implementacje telewizorów z dekoderami sprzętowymi VP9 MUSZĄ obsługiwać dekodowanie formatu VP9 zgodnie z opisem w sekcji 5.3.7 przy standardowych częstotliwościach klatek i rozdzielczościach wideo do:

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

Jeśli implementacje telewizorów z dekoderami sprzętowymi VP9 obsługują dekodowanie VP9 i profil dekodowania UHD, to:

• [5.3.7/T-2-1] MUSI obsługiwać profil dekodowania UHD z szybkością 60 klatek na sekundę w profilu 0 (głębia kolorów 8-bitowa).
• [5.3.7/T-2-1] BARDZO ZALECAMY obsługę profilu dekodowania UHD z 60 klatkami na sekundę w profilu 2 (głębia kolorów 10 bitów).

Implementacje na telewizorach:

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

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

• [5.8/T-0-1] NALEŻY ustawić tryb wyjścia HDMI, aby wybrać maksymalną rozdzielczość, która może być obsługiwana przy częstotliwości odświeżania 50 Hz lub 60 Hz.
• [5.8/T-SR] MOCNO ZALECAMY udostępnienie użytkownikowi opcji wyboru częstotliwości odświeżania HDMI.
• [5.8] NALEŻY ustawić częstotliwość odświeżania w trybie wyjścia HDMI na 50 Hz lub 60 Hz w zależności od częstotliwości odświeżania wideo w regionie, w którym sprzedawane jest urządzenie.

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

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

Jeśli implementacje telewizorów nie obsługują dekodowania UHD, ale obsługują wyświetlacz zewnętrzny podłączony przez HDMI, mogą:

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

2.3.3. Oprogramowanie

Implementacje na telewizorach:

• [3/T-0-1] NALEŻY zadeklarować funkcje android.software.leanback i android.hardware.type.television.
• [3.4.1/T-0-1] Musisz wdrożyć interfejs API android.webkit.Webview.

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

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

Implementacje na telewizorach:

• [3.8.14/T-SR] W przypadku trybu obrazu w obrazie (PIP) MOCNO zaleca się obsługę wielu okien.
• [3.10/T-0-1] MUSI obsługiwać zewnętrzne usługi ułatwień dostępu.
• [3.10/T-SR] ZALECAMY WYMAGANIE wstępnego załadowania na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z funkcjonalnością usług Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) zgodnie z projektem open source TalkBack.

Jeśli implementacje telewizorów obsługują funkcję android.hardware.audio.output, to:

• [3.11/T-SR] MOCNO zalecamy uwzględnienie silnika TTS obsługującego języki dostępne na urządzeniu.
• [3.11/T-1-1] MUSI obsługiwać instalację silników TTS innych firm.

Implementacje na telewizorach:

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

2.3.4. Wydajność i moc

• [8.1/T-0-1] Stabilne opóźnienie klatek. Niespójny czas oczekiwania na wyświetlenie lub opóźnienie w renderowaniu klatek NIE MOŻE występować częściej niż 5 razy na sekundę, a liczba klatek na sekundę powinna być mniejsza niż 1.
• [8.2/T-0-1] MUSI zapewnić wydajność sekwencyjnego zapisu co najmniej 5 MB/s.
• [8.2/T-0-2] MUSI zapewnić wydajność zapisu losowego co najmniej 0,5 MB/s.
• [8.2/T-0-3] NALEŻY zapewnić wydajność sekwencyjnego odczytu na poziomie co najmniej 15 MB/s.
• [8.2/T-0-4] MUSI zapewnić wydajność odczytu losowego co najmniej 3,5 MB/s.

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

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

Jeśli implementacje telewizorów nie mają baterii:

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

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

• [8.3/T-1-3] Musisz umożliwić użytkownikowi wyświetlanie wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.

Implementacje na telewizorach:

• [8.4/T-0-1] MUSI zawierać profil poboru mocy dla poszczególnych komponentów, który definiuje wartość bieżącego zużycia energii dla każdego komponentu sprzętowego oraz przybliżony pobór mocy z baterii spowodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
• [8.4/T-0-2] Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
• [8.4/T-0-3] MUST report CPU power consumption per each process's UID. 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 komponentu sprzętowego do aplikacji.
• [8.4/T-0-4] DEWELOPER APLIKACJI MUSI udostępnić ten pobór mocy za pomocą polecenia adb shell dumpsys batterystats w powłoce.

2.3.5. Model zabezpieczeń

Implementacje na telewizorach:

• [9.11/T-0-1] Musisz utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
• [9.11/T-0-2] Musisz mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać obsługiwane algorytmy systemu Keystore na Androidzie w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i powyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source Project (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
• [9.11/T-0-3] NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonania i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem tylko wtedy, gdy uwierzytelnianie się powiedzie. Dane uwierzytelniające na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w odizolowanym środowisku wykonania. Wspólny projekt Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.
• [9.11/T-0-4] MUSI obsługiwać atestacjowanie klucza, w którym klucz podpisujący jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania certyfikatów MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻE być używany inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi spełniać wymagań dotyczących posiadania repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania i obsługiwania uwierzytelniania klucza, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania.

Jeśli implementacje telewizorów obsługują bezpieczny ekran blokady, muszą:

• [9.11/T-1-1] Musisz umożliwić użytkownikowi wybranie czasu przejścia w stan uśpienia z otwartego na zamknięty, z minimalnym dozwolonym czasem do 15 sekund.

Jeśli implementacje telewizorów obsługują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, nie mogą:

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

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

• [9.5/T-3-1] NIE MOŻE obsługiwać profili z ograniczonymi uprawnieniami, ale MUSI być zgodna z implementacją ustawień AOSP, aby umożliwić /zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

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

Implementacje na telewizorach:

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

2.4. Wymagania dotyczące oglądania

Urządzenie typu zegarek z Androidem 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 fizycznej przekątnej 1,1–2,5 cala;
• mieć mechanizm umożliwiający noszenie na ciele;

Pozostałe wymagania w tej sekcji dotyczą implementacji na urządzeniach z Androidem Watch.

2.4.1. Sprzęt

Implementacje na urządzeniach z obsługą zegarka:

• [7.1.1.1/W-0-1] Musi mieć ekran o fizycznej przekątnej o długości od 1,1 do 2,5 cala.

• [7.2.3/W-0-1] Użytkownik MUSI mieć dostęp do funkcji Wróć do ekranu głównego oraz do funkcji Wstecz, z wyjątkiem sytuacji, gdy jest w trybie UI_MODE_TYPE_WATCH.

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

• [7.3.1/W-SR] MOCNO zaleca się uwzględnienie 3-osiowego akcelerometru.

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

• [7.3.3/W-1-1] MUST report GNSS measurements, as soon as they are found, even if a location calculated from GPS/GNSS is not yet reported.
• [7.3.3/W-1-2] MUST report GNSS pseudoranges and pseudorange rates, that, in conditions open-sky after determining the location, while stationary or moving with less than 0.2 meter per second squared of acceleration, are sufficient to calculate position within 20 meters, and speed within 0.2 meters per second, at least 95% of the time.

Jeśli implementacje urządzeń Watch zawierają 3-osiowy żyroskop:

• [7.3.4/W-2-1] MUSI umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę.

Implementacje na urządzeniach z obsługą zegarka:

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

• [7.6.1/W-0-1] Musisz mieć co najmniej 1 GB pamięci nieulotnej dostępnej dla danych prywatnych aplikacji (czyli partycji „/data”).

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

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

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

2.4.2. Multimedia

Brak dodatkowych wymagań.

2.4.3. Oprogramowanie

Implementacje na urządzeniach z obsługą zegarka:

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

Implementacje na urządzeniach z obsługą zegarka:

• [3.8.4/W-SR] MOCNO ZALECAMY wdrożenie na urządzeniu asystenta, który obsłuży działanie asystenta.

Sprawdź implementacje na urządzeniach, które deklarują flagę funkcji android.hardware.audio.output:

• [3.10/W-1-1] MUSI obsługiwać usługi dostępności innych firm.

• [3.10/W-SR] ZALECAMY WYMAGANIE wstępnego załadowania na urządzeniu usług ułatwień dostępu o funkcjonalności porównywalnej z funkcjonalnością usług Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie zainstalowany mechanizm przetwarzania tekstu na mowę) zgodnie z projektem open source TalkBack.

• [3.11/W-SR] MOCNO zaleca się uwzględnienie silnika TTS obsługującego języki dostępne na urządzeniu.

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

2.4.4. Wydajność i moc

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

• [8.3/W-SR] NALEŻY MOCNO ZALECAĆ wyświetlanie użytkownikowi wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.
• [8.3/W-SR] MOCNO zalecamy umożliwienie użytkownikowi włączenia i wyłączenia funkcji oszczędzania baterii.

Implementacje na urządzeniach z obsługą zegarka:

• [8.4/W-0-1] MUSISZ podać profil zasilania dla poszczególnych komponentów, który definiuje wartość bieżącego zużycia energii dla każdego komponentu sprzętowego oraz przybliżony pobór energii z baterii spowodowany przez te komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
• [8.4/W-0-2] Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
• [8.4/W-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• [8.4/W-0-4] DEWELOPER MUSI udostępnić ten pobór mocy 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 komponentu sprzętowego do aplikacji.

2.4.5. Model zabezpieczeń

Jeśli implementacje urządzeń Watch obejmują wielu użytkowników i nie deklarują flagi funkcji android.hardware.telephony, nie mogą:

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

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

• [9.5/W-2-1] NIE MUSI obsługiwać profili z ograniczonymi uprawnieniami, ale MUSI być zgodny z implementacją kontroli AOSP, aby umożliwić /zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

2.5. Wymagania dotyczące samochodów

Wdrożeniem Androida Automotive jest panel pojazdu z Androidem jako systemem operacyjnym dla części lub całości systemu 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 samochód lub są w nim wpinane.
• Używasz ekranu w rzędzie siedzeń kierowcy jako głównego wyświetlacza.

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

2.5.1. Sprzęt

Implementacje na urządzeniach samochodowych:

• [7.1.1.1/A-0-1] Ekran musi mieć przekątną o długości co najmniej 6 cali.

• [7.1.1.1/A-0-2] Rozmiar ekranu musi wynosić co najmniej 750 dp x 480 dp.

• [7.2.3/A-0-1] MUSI zawierać funkcję strony głównej oraz MOŻE zawierać funkcje Wstecz i Ostatnie.

• [7.2.3/A-0-2] DO aplikacji na pierwszym planie należy wysłać zdarzenie naciśnięcia i długiego naciśnięcia przycisku Wstecz (KEYCODE_BACK).
• [7.3/A-0-1] MUSISZ wdrożyć i zgłosić GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED oraz PARKING_BRAKE_ON.
• [7.3/A-0-2] Wartość flagi NIGHT_MODE MUSI być zgodna z trybem dnia/nocy w panelu i POWINNA być oparta na danych z czujnika światła otoczenia. Podrzędny czujnik jasności otoczenia MOŻE być taki sam jak fotometr.
• [7.3/A-0-3] W przypadku każdego czujnika w polu SensorAdditionalInfo MUSISZ podać pole dodatkowych informacji o czujniku TYPE_SENSOR_PLACEMENT.
• [7.3/A-0-1] MOŻE obliczać lokalizację metodą dead reckoningu, łącząc dane z GPS/GNSS z danymi z dodatkowych czujników. Jeśli lokalizacja jest określana metodą dead reckoning, MOCNO zalecamy implementację i raportowanie odpowiednich typów czujnika lub identyfikatorów właściwości pojazdu.
• [7.3/A-0-2] Lokalizacja żądana za pomocą metody LocationManager#requestLocationUpdates() NIE MOŻE być dopasowywana na mapie.

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

• [7.3.1/A-1-1] Musi być możliwe zgłaszanie zdarzeń z częstotliwością co najmniej 100 Hz.
• [7.3.1/A-1-2] MUSI być zgodny z systemem współrzędnych czujnika samochodowego Androida.

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

• [7.3.4/A-2-1] Musi być możliwe zgłaszanie zdarzeń z częstotliwością co najmniej 100 Hz.
• [7.3.4/A-2-2] NALEŻY też zaimplementować czujnik TYPE_GYROSCOPE_UNCALIBRATED.
• [7.3.4/A-2-3] MUSI być w stanie mierzyć zmiany orientacji do 250 stopni na sekundę.
• [7.3.4/A-SR] ZALECAMY, aby skonfigurować zakres pomiarowy żyroskopu na +/-250 dps, aby zmaksymalizować możliwą rozdzielczość.

Implementacje na urządzeniach samochodowych:

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

• [7.4.3/A-0-2] Implementacje Androida Automotive MUSZĄ obsługiwać te profile Bluetooth:

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

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

• [7.4.5/A] NALEŻY uwzględnić obsługę transmisji danych przez sieć komórkową.

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

Kamera zewnętrzna to kamera, która rejestruje obrazy z zewnętrznej części urządzenia, np. kamera samochodowa.

Implementacje na urządzeniach samochodowych:

• POWINNY zawierać co najmniej 1 kamerę zewnętrzną.

Jeśli implementacje urządzeń samochodowych obejmują kamerę zewnętrzną, w przypadku takiej kamery:

• [7.5/A-1-1] Nie można używać interfejsów API aparatu Androida do obsługi kamer zewnętrznych, chyba że spełniają one podstawowe wymagania dotyczące aparatu.
• [7.5/A-SR] ZDECYTOWANIE POLECAMY nie obracać ani nie odwracać poziomo podglądu kamery.
• [7.5.5/A-SR] MOCNO zaleca się, aby orientacja była taka, aby dłuższy bok aparatu był wyrównany z horyzontem.
• [7.5/A-SR] MOCNO ZALECAMY, aby rozdzielczość wynosiła co najmniej 1,3 Mpix.
• NALEŻY użyć aparatu z stałym ustawieniem ostrości lub z wydłużoną głębią ostrości.
• MOŻE mieć wbudowany mechanizm autofokusu sprzętowego lub oprogramowania.

Implementacje na urządzeniach samochodowych:

• [7.6.1/A-0-1] Na potrzeby danych prywatnych aplikacji (czyli partycji „/data”) musi być dostępne co najmniej 4 GB pamięci nieulotnej.

• [7.6.1/A] NALEŻY sformatować partycję danych, aby zwiększyć wydajność i trwałość pamięci flash, na przykład za pomocą systemu plików f2fs.

Jeśli implementacje urządzeń samochodowych udostępniają zewnętrzne miejsce na dane za pomocą części pamięci wewnętrznej, która nie może być usunięta, muszą:

• [7.6.1/A-SR] Zdecydowanie zalecamy zmniejszenie obciążenia operacjami wejścia/wyjścia w przypadku operacji wykonywanych na pamięci zewnętrznej, na przykład za pomocą 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 wynosić co najmniej 512 MB, jeśli używana jest dowolna z tych gęstości:

  • 280 dpi lub mniej na małych/normalnych ekranach
  • ldpi lub niższą na bardzo dużych ekranach.
  • mdpi lub niższym na dużych ekranach.

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

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

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

  • 400 dpi lub więcej na małych/normalnych ekranach
  • xhdpi lub wyższa na dużych ekranach
  • tvdpi lub wyższa na bardzo dużych ekranach.

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

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

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 wynosić co najmniej 816 MB, jeśli używana jest dowolna z tych gęstości:

  • 280 dpi lub mniej na małych/normalnych ekranach
  • ldpi lub niższą na bardzo dużych ekranach.
  • mdpi lub niższym na dużych ekranach.

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

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

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

  • 400 dpi lub więcej na małych/normalnych ekranach
  • xhdpi lub wyższa na dużych ekranach
  • tvdpi lub wyższa na bardzo dużych ekranach.

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

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

Uwaga: „pamięć dostępna dla jądra i przestrzeni użytkownika” odnosi się do pamięci dostępnej oprócz pamięci już przeznaczonej dla komponentów sprzętowych, takich jak radio, wideo itp., które nie są kontrolowane przez jądro w implementacjach urządzenia.

Implementacje na urządzeniach samochodowych:

• [7.7.1/A] NALEŻY uwzględnić port USB obsługujący tryb peryferyjny.

Implementacje na urządzeniach samochodowych:

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

Implementacje na urządzeniach samochodowych:

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

2.5.2. Multimedia

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

• [5.1/A-0-1] Profil MPEG-4 AAC (AAC LC)
• [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/A-0-3] AAC ELD (ulepszona jakość dźwięku AAC z minimalnym opóźnieniem)

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

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

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

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

W przypadku implementacji urządzeń samochodowych MOCNO zaleca się obsługę tych algorytmów dekodowania wideo:

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

2.5.3. Oprogramowanie

Implementacje na urządzeniach samochodowych:

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

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

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

• [3.2.1/A-0-1] MUSI obsługiwać i stosować wszystkie stałe uprawnienia zgodnie z dokumentacją na stronie referencyjnej dotyczącą uprawnień w automotive.

• [3.4.1/A-0-1] Musisz wdrożyć interfejs API android.webkit.Webview.

• [3.8.3/A-0-1] MUSI wyświetlać powiadomienia, które korzystają z interfejsu API Notification.CarExtender, gdy zostaną przesłane przez aplikacje innych firm.

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

Jeśli w implementacjach urządzeń samochodowych jest dostępny przycisk „push-to-talk”, muszą one:

• [3.8.4/A-1-1] NALEŻY użyć krótkiego naciśnięcia przycisku „push-to-talk” jako wyznaczonej interakcji w celu uruchomienia wybranej przez użytkownika aplikacji asystenta, czyli aplikacji, która implementuje VoiceInteractionService.

Implementacje na urządzeniach samochodowych:

• [3.8.3.1/A-0-1] MUSI prawidłowo renderować zasoby zgodnie z opisem w dokumentacji pakietu SDK (Notifications on Automotive OS).
• [3.8.3.1/A-0-2] W miejscu akcji podanych w Notification.Builder.addAction() MUSI wyświetlać opcje „ODTWÓRZ” i „WYCISZ”.
• [3.8.3.1/A] NALEŻY ograniczyć korzystanie z zaawansowanych zadań związanych z zarządzaniem, takich jak ustawienia dotyczące kanałów powiadomień. MOŻE używać interfejsu użytkownika w poszczególnych aplikacjach, aby ograniczyć liczbę elementów sterujących.

Implementacje na urządzeniach samochodowych:

• [3.14/A-0-1] MUSI zawierać interfejs użytkownika, który obsługuje aplikacje innych firm korzystające z interfejsów API mediów zgodnie z opisem w sekcji 3.14.
• [3.14/A-0-2] Aplikacja MUSI umożliwiać użytkownikowi bezpieczne korzystanie z aplikacji multimedialnych podczas jazdy.
• [3.14/A-0-3] Musi obsługiwać ukryte działanie CAR_INTENT_ACTION_MEDIA_TEMPLATE z dodatkiem CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] MUSISZ udostępnić możliwość przejścia do aktywności preferencyjnej aplikacji do multimediów, ale TYLKO wtedy, gdy nie obowiązują ograniczenia dotyczące UX w samochodzie.
• [3.14/A-0-5] MUSI wyświetlać komunikaty o błędach ustawione przez aplikacje multimedialne i MUSI obsługiwać opcjonalne dodatki ERROR_RESOLUTION_ACTION_LABEL i ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] Musisz obsługiwać wyszukiwanie w aplikacji w przypadku aplikacji, które obsługują wyszukiwanie.
• [3.14/A-0-7] Podczas wyświetlania hierarchii MediaBrowser należy przestrzegać definicji CONTENT_STYLE_BROWSABLE_HINT i CONTENT_STYLE_PLAYABLE_HINT.

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

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

Implementacje na urządzeniach samochodowych:

• [3.8/A] MOŻNA ograniczyć żądania aplikacji, aby ograniczyć możliwość przejścia do trybu pełnoekranowego zgodnie z opisem w immersive documentation.
• [3.8/A] Możesz mieć zawsze widoczny pasek stanu i pasek nawigacyjny.
• [3.8/A] MOŻE ograniczyć żądania aplikacji, aby ograniczyć możliwość zmiany kolorów elementów interfejsu systemu, i zapewnić, aby elementy te były zawsze wyraźnie widoczne, zgodnie z opisem w sekcjach WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS i WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION.

2.5.4. Wydajność i moc

Implementacje na urządzeniach samochodowych:

• [8.2/A-0-1] MUST report the number of bytes read and written to non-volatile storage per each process's UID so the stats are available to developers through System API android.car.storagemonitoring.CarStorageMonitoringManager. Projekt Android Open Source spełnia wymagania dzięki modułowi jądra uid_sys_stats.
• [8.3/A-1-3] Przed wyłączeniem samochodu NALEŻY co najmniej raz uruchomić tryb garażu.
• [8.3/A-1-4] MUSI znajdować się w trybie garażu przez co najmniej 15 minut, chyba że:
  • Bateria jest rozładowana.
  • Nie zaplanowano żadnych zadań nieczynnych.
  • Kierowca wyłącza tryb garażu.
• [8.4/A-0-1] MUSI zawierać profil energetyczny poszczególnych komponentów, który definiuje wartość bieżącego zużycia energii dla każdego komponentu sprzętowego oraz przybliżone zużycie baterii spowodowane przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
• [8.4/A-0-2] Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
• [8.4/A-0-3] MUSI raportować zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia 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 komponentu sprzętowego do aplikacji.
• [8.4/A-0-4] DEWELOPER APLIKACJI MUSI udostępnić ten pobór mocy za pomocą polecenia powłoki adb shell dumpsys batterystats.

2.5.5. Model zabezpieczeń

Jeśli implementacje urządzeń Automotive obsługują wielu użytkowników, muszą:

• [9.5/A-1-1] NIE MOŻESZ zezwolić użytkownikom na interakcję z Headless System User ani przełączanie się na niego, z wyjątkiem zarządzania urządzeniami.
• [9.5/A-1-2] Przed BOOT_COMPLETED musisz przejść na użytkownika dodatkowego.
• [9.5/A-1-3] MUSI obsługiwać możliwość utworzenia użytkownika-gościa, nawet jeśli została osiągnięta maksymalna liczba użytkowników na urządzeniu.

Implementacje na urządzeniach samochodowych:

• [9.11/A-0-1] Musisz utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
• [9.11/A-0-2] Musisz mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać obsługiwane algorytmy systemu Keystore na Androidzie w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze lub wyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source Project (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
• [9.11/A-0-3] NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonywania i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem tylko wtedy, gdy uwierzytelnianie zakończy się powodzeniem. Dane uwierzytelniające na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w odizolowanym środowisku wykonania. Wspólny projekt Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.
• [9.11/A-0-4] MUSI obsługiwać atestacjowanie klucza, w którym klucz podpisujący jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania certyfikatów MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻE być używany inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi spełniać wymagań dotyczących posiadania repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania i obsługiwania uwierzytelniania klucza, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania.

Jeśli implementacje urządzeń samochodowych obsługują bezpieczny ekran blokady, to:

• [9.11/A-1-1] Musisz umożliwić użytkownikowi wybranie czasu przejścia w stan uśpienia z otwartego na zamknięty, przy czym minimalny dozwolony czas nie może przekraczać 15 sekund.

Implementacje na urządzeniach samochodowych:

• [9.14/A-0-1] MUST gatekeep messages from Android framework vehicle subsystems, e.g., allowlisting permitted message types and message sources.
• [9.14/A-0-2] MUSI chronić przed atakami typu „odmowa usługi” z ramy Androida lub aplikacji innych firm. Zapobiega to zasypywaniu sieci pojazdu przez złośliwe oprogramowanie, co może prowadzić do nieprawidłowego działania podsystemów pojazdu.

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

Implementacje na urządzeniach samochodowych:

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

2.6. Wymagania dotyczące tabletów

Tablet z Androidem to implementacja urządzenia z Androidem, która spełnia wszystkie te kryteria:

• Zwykle trzymane w obu rękach.
• Nie ma konfiguracji składanej ani składanej z klapką.
• Implementacja każdej klawiatury fizycznej używanej z urządzeniem MUSI umożliwiać połączenie za pomocą standardowego połączenia.
• Ma źródło zasilania, które zapewnia mobilność, np. baterię.
• Fizyczna przekątna ekranu ma rozmiar od 7 do 18 cali.

Implementacje na tabletach mają podobne wymagania jak implementacje na urządzeniach przenośnych. Wyjątki są oznaczone gwiazdką (*) w tej sekcji i wymienione w celu ułatwienia nawigacji.

2.6.1. Sprzęt

Rozmiar ekranu

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

Żyroskop

Jeśli implementacje urządzeń typu tablet obejmują 3-osiowy żyroskop, muszą:

• [7.3.4/Tab-1-1] MUSI umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę.

Minimalna ilość pamięci i miejsca na dane (sekcja 7.6.1)

Gęstości ekranu wymienione w wymaganiach dotyczących urządzeń przenośnych 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 tabletów obejmują port USB obsługujący tryb peryferyjny, muszą:

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

Tryb rzeczywistości wirtualnej (sekcja 7.9.1)

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

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

2.6.2. Model zabezpieczeń

Klucze i dane uwierzytelniające (sekcja 9.11)

Patrz sekcja [9.11].

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

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

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

• [9.5/T-2-1] NIE MUSI obsługiwać profili z ograniczonymi uprawnieniami, ale MUSI być zgodny z implementacją funkcji sterowania w AOSP, aby umożliwić /zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

Zarządzane środowisko wykonywania kodu bajtowego Dalvik jest głównym narzędziem do uruchamiania aplikacji na Androida. Interfejs programowania aplikacji (API) Androida to zestaw interfejsów platformy Androida udostępnionych aplikacjom działającym w środowisku zarządzanego środowiska wykonawczego.

Implementacje na urządzeniu:

• [C-0-1] Musisz udostępnić kompletne implementacje, w tym wszystkie udokumentowane zachowania, dowolnego udokumentowanego interfejsu API udostępnionego przez pakiet Android SDK lub dowolnego interfejsu API otagowanego znacznikiem „@SystemApi” w kodziku źródłowym Androida.

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

• [C-0-3] Nie wolno pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów ani podpisów interfejsów API, odbiegać od udokumentowanego zachowania lub dołączać operacji pustych, z wyjątkiem przypadków, w których jest to wyraźnie dozwolone w tej definicji zgodności.

• [C-0-4] Musisz zachować interfejsy API i zachować się w rozsądny sposób, nawet jeśli pominiesz niektóre funkcje sprzętowe, dla których Android zawiera interfejsy API. Więcej informacji o wymaganiach w tym scenariuszu znajdziesz w sekcji 7.

• [C-0-5] NIE MOŻESZ zezwolić aplikacjom innych firm na używanie interfejsów spoza pakietu SDK, które są zdefiniowane jako metody i pola w pakietach języka Java, znajdujące się na ścieżce ładowania w AOSP i nie należące do publicznego pakietu SDK. Dotyczy to interfejsów API otagowanych adnotacją @hide, ale nie @SystemAPI, zgodnie z opisem w dokumentacji pakietu SDK oraz elementów klas prywatnych i prywatnych w ramach pakietu.

• [C-0-6] MUST ship with each and every non-SDK interface on the same restricted lists as provided via the provisional list and denylist flags in prebuilts/runtime/appcompat/hiddenapi-flags.csv path for the appropriate API level in the AOSP.

  Jednak:

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

• [C-0-7] MUSI obsługiwać mechanizm aktualizacji dynamicznej zaszyfrowanej konfiguracji, aby usuwać interfejsy inne niż SDK z listy ograniczeń przez umieszczenie zaszyfrowanej konfiguracji w dowolnym pliku APK za pomocą istniejących kluczy publicznych obecnych w AOSP.

3.1.1. Rozszerzenia Androida

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

• [C-0-1] Implementacje na urządzeniach z Androidem MUSZĄ wstępnie wczytać implementację AOSP zarówno udostępnionej biblioteki ExtShared, jak i usług ExtServices w wersjach nowszych lub równych minimalnym wersjom dozwolonym dla każdego poziomu interfejsu API. Na przykład implementacje na urządzeniach z Androidem 7.0 i poziomem interfejsu API 24 MUSZĄ zawierać co najmniej wersję 1.

3.1.2. Biblioteka Androida

Z powodu wycofania klienta HTTP Apache implementacje urządzeń:

• [C-0-1] NIE WYMAGAMY umieszczania biblioteki org.apache.http.legacy w ścieżce ładowania.
• [C-0-2] NALEŻY dodać bibliotekę org.apache.http.legacy do ścieżki klas aplikacji tylko wtedy, gdy aplikacja spełnia jeden z tych warunków:
  • Kieruje na interfejs API na poziomie 28 lub niższym.
  • w swoim pliku manifestu deklaruje, że potrzebuje biblioteki, ustawiając atrybut android:name w elementach <uses-library> na org.apache.http.legacy;

Implementacja AOSP spełnia te wymagania.

3.2. Zgodność z interfejsem API w wersji próbnej

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

3.2.1. Uprawnienia

• [C-0-1] Implementatorzy urządzeń MUSZĄ obsługiwać i stosować wszystkie stałe uprawnienia zgodnie z dokumentacją na stronie referencyjnej dotyczącej uprawnień. Pamiętaj, że w sekcji 9 znajdziesz dodatkowe wymagania dotyczące modelu zabezpieczeń Androida.

3.2.2. Parametry tworzenia

Interfejsy API Androida zawierają wiele stałych wartości w klasie android.os.Build, które opisują bieżące urządzenie.

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

3.2.3. Zgodność z zamiarem

3.2.3.1. Główne intencje aplikacji

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

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

  • Zegar biurkowy
  • Przeglądarka
  • Kalendarz
  • kontakty,
  • Galeria
  • GlobalSearch
  • Wyrzutnia
  • Muzyka
  • Ustawienia

3.2.3.2. Rozwiązywanie intencji

• [C-0-1] Ponieważ Android jest platformą rozszerzalną, implementacje urządzeń MUSZĄ zezwalać na zastąpienie przez aplikacje innych firm każdego wzorca intencji wymienionego w sekcji 3.2.3.1, z wyjątkiem ustawień. Implementacja open source w górnym łańcuchu Androida umożliwia to domyślnie.

• [C-0-2] Implementatorzy urządzeń NIE MOGĄ dołączać specjalnych uprawnień do korzystania z tych wzorów intencji przez aplikacje systemowe ani uniemożliwiać aplikacjom innych firm wiązania się z tymi wzorami i przejmowania nad nimi kontroli. Zakaz ten obejmuje m.in. wyłączenie interfejsu „Wybór”, który umożliwia użytkownikowi wybór spośród wielu aplikacji obsługujących ten sam wzór intencji.

• [C-0-3] Implementacje na urządzeniach MUSZĄ zawierać interfejs użytkownika, który umożliwia modyfikowanie domyślnej aktywności dla intencji.

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

Android zawiera też mechanizm, który umożliwia aplikacjom innych firm deklarowanie wiarygodnego domyślnego zachowania w przypadku łączenia aplikacji w przypadku niektórych typów intencji identyfikatora URI internetowego. Gdy w wzorach filtrów intencji aplikacji zdefiniowane są takie autorytatywne deklaracje, implementacje na urządzeniach:

• [C-0-4] NALEŻY spróbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji Digital Asset Links, jak to zostało zaimplementowane przez menedżera pakietów w górnym projekcie Android Open Source.
• [C-0-5] NALEŻY spróbować zweryfikować filtry intencji podczas instalacji aplikacji i ustawić wszystkie zweryfikowane filtry intencji identyfikatora URI jako domyślne moduły obsługi aplikacji dla ich identyfikatorów URI.
• MOGĄ ustawić określone filtry intencji URI jako domyślne moduły obsługi aplikacji dla swoich identyfikatorów URI, jeśli zostaną one pomyślnie zweryfikowane, ale inne potencjalne filtry URI nie przejdą weryfikacji. Jeśli implementacja urządzenia wykonuje tę funkcję, MUSI udostępnić użytkownikowi odpowiednie zastąpienia wzorca na podstawie URI w menu ustawień.
• MUSI udostępniać użytkownikom ustawienia dotyczące linków do aplikacji w ustawieniach aplikacji w ten sposób:
  • [C-0-6] Użytkownik MUSI mieć możliwość globalnego zastąpienia domyślnego zachowania linków aplikacji, aby były one zawsze otwierane, zawsze pytały lub nigdy nie otwierały się. Zasada ta MUSI dotyczyć wszystkich docelowych filtrów identyfikatorów URI.
  • [C-0-7] Użytkownik MUSI mieć możliwość wyświetlenia listy docelowych filtrów intencji URI.
  • Implementacja urządzenia MOŻE umożliwić użytkownikowi zastąpienie konkretnych docelowych filtrów intencji URI, które zostały zweryfikowane, na podstawie każdego filtra intencji.
  • [C-0-8] Implementacja na urządzeniu MUSI umożliwiać użytkownikom wyświetlanie i zastępowanie konkretnych docelowych filtrów identyfikatora URI, jeśli implementacja na urządzeniu pozwala na przeprowadzenie weryfikacji niektórych docelowych filtrów identyfikatora URI, podczas gdy inne mogą nie przejść weryfikacji.

3.2.3.3. Przestrzenie nazw intencji

• [C-0-1] Implementacje urządzeń NIE MOGĄ zawierać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub rozgłaszania intencji za pomocą działania, kategorii lub innego kluczowego ciągu znaków w przestrzeni nazw android. lub com.android..
• [C-0-2] Implementatorzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub rozgłaszania intencji za pomocą działania, kategorii lub innego ciągu kluczy w przestrzeni pakietu należącej do innej organizacji.
• [C-0-3] Implementatorzy urządzeń NIE MOGĄ zmieniać ani rozszerzać żadnych wzorów intencji używanych przez podstawowe aplikacje wymienione w sekcji 3.2.3.1.
• Implementacje na urządzeniach MOGĄ zawierać wzorce intencji, które używają przestrzeni nazw wyraźnie i wyraźnie powiązanych z własną organizacją. Ten zakaz jest analogiczny do zakazu dotyczącego zajęć z języka Java w sekcji 3.6.

3.2.3.4. Zamiary związane z transmisją

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

Implementacje na urządzeniu:

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

3.2.3.5. Domyślne ustawienia aplikacji

Android zawiera ustawienia, które umożliwiają użytkownikom łatwe wybieranie domyślnych aplikacji, np. na ekran główny lub do wysyłania SMS-ów.

W przypadku urządzeń, w których ma to sens, implementacje MUSZĄ udostępniać podobne menu ustawień i być zgodne z wzorcem filtra intencji oraz metodami interfejsu API opisanymi w dokumentacji pakietu SDK, jak pokazano poniżej.

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

• [C-1-1] MUSI obsługiwać działanie android.settings.HOME_SETTINGS polegające na wyświetlaniu menu ustawień domyślnej aplikacji na ekranie głównym.

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

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

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

  • W przypadku połączeń przychodzących i wychodzących należy UŻYWAĆ interfejsu domyślnej aplikacji Telefon wybranej przez użytkownika, z wyjątkiem połączeń alarmowych, które będą korzystać z zainstalowanej fabrycznie aplikacji Telefon.

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

• [C-2-4] Musisz zezwolić aplikacji, która ma rolę android.app.role.CALL_REDIRECTION, na dostęp do uprawnienia android.telecom.CallRedirectionService.

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

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

• [C-3-1] Musi obsługiwać działanie okna dialogowego android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlić menu ustawień domyślnej aplikacji do płatności Zbliż i zapłać.

Jeśli implementacje na urządzeniu obsługują interfejs VoiceInteractionService i na urządzeniu jest zainstalowanych jednocześnie kilka aplikacji korzystających z tego interfejsu API, to:

• [C-4-1] MUSI obsługiwać działanie android.settings.ACTION_VOICE_INPUT_SETTINGS polegające na wyświetleniu menu ustawień domyślnej aplikacji do wprowadzania i obsługi poleceń głosowych.

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

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych czynności Androida na więcej niż 1 ekranie, muszą:

• [C-1-1] NALEŻY ustawić flagę funkcji android.software.activities_on_secondary_displays.
• [C-1-2] NALEŻY zagwarantować zgodność z interfejsem API podobną do tej, która występuje w przypadku działania na ekranie głównym.
• [C-1-3] Nowa aktywność MUSI być wyświetlana na tym samym ekranie co aktywność, która ją uruchomiła, gdy nowa aktywność jest uruchamiana bez określenia wyświetlacza docelowego za pomocą interfejsu API ActivityOptions.setLaunchDisplayId().
• [C-1-4] Należy usunąć wszystkie aktywności, gdy usunie się wyświetlacz z flagą Display.FLAG_PRIVATE.
• [C-1-5] NALEŻY bezpiecznie ukryć treści na wszystkich ekranach, gdy urządzenie jest zablokowane za pomocą bezpiecznego ekranu blokady, chyba że aplikacja chce wyświetlać treści na górze ekranu blokady za pomocą interfejsu API Activity#setShowWhenLocked().
• android.content.res.Configuration powinien być zgodny z tym wyświetlaczem, aby można było go wyświetlić, aby 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 czynnoś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 działalności, które są już na wyświetlaczu, MUSI mieć możliwość uruchomienia wyświetlacza. 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 do osiągnięcia. Dlatego implementatorzy urządzeń:

• [SR] MOCNO ZALECAMY korzystanie z implementacji bibliotek wymienionych poniżej z wyższego projektu Android Open Source.

3.3.1. Interfejsy binarne aplikacji

Zarządzany kod bajtowy Dalvik może wywoływać kod natywny dostarczony w pliku aplikacji .apk jako plik ELF .so skompilowany pod kątem odpowiedniej architektury sprzętowej urządzenia. Ponieważ kod natywny jest w dużej mierze zależny od podstawowej technologii procesora, Android definiuje w NDK Androida kilka interfejsów binarnych aplikacji (ABI).

Implementacje na urządzeniu:

• [C-0-1] MUSI być zgodny z co najmniej 1 zdefiniowanym ABI i implementować zgodność z Android NDK.
• [C-0-2] MUSI zawierać obsługę kodu działającego w środowisku zarządzanym, aby wywoływać kod natywny za pomocą standardowej semantyki interfejsu JNI (Java Native Interface).
• [C-0-3] Musi być zgodny z źródłem (czyli z nagłówkiem) i binarną wersją (w przypadku interfejsu ABI) każdej wymaganej biblioteki na liście poniżej.
• [C-0-5] MUST accurately report the native Application Binary Interface (ABI) supported by the device, via the android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, and android.os.Build.SUPPORTED_64_BIT_ABIS parameters, each a comma separated list of ABIs ordered from the most to the least preferred one.

• [C-0-6] NALEŻY podać za pomocą powyższych parametrów podzbiór z listy ABI, o których mowa poniżej. NIE NALEŻY podać żadnych ABI, których nie ma na tej liście.

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

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

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

  • libamidi.so (wbudowane wsparcie MIDI, jeśli funkcja android.software.midi jest obsługiwana zgodnie z opisem w sekcji 5.9)
  • libandroid.so (obsługa natywnej aktywności Androida)
  • libc (biblioteka C)
  • libcamera2ndk.so
  • libdl (linker dynamiczny)
  • libEGL.so (własne 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 (rejestrowanie na Androidzie)
  • libmediandk.so (obsługa natywnych interfejsów API multimediów)
  • libm (biblioteka matematyczna)
  • libneuralnetworks.so (interfejs Neural Networks API)
  • libOpenMAXAL.so (obsługa OpenMAX AL 1.0.1)
  • libOpenSLES.so (obsługa dźwięku OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (minimalna obsługa C++)
  • libvulkan.so (Vulkan)
  • libz (kompresja Zlib)
  • Interfejs JNI

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

• [C-0-9] W /vendor/etc/public.libraries.txt MUSISZ podać listę dodatkowych bibliotek innych niż AOSP udostępnionych bezpośrednio aplikacjom innych firm.
• [C-0-10] NIE wolno udostępniać aplikacji innych firm kierowanych na poziom interfejsu API 24 lub nowszy żadnych innych bibliotek natywnych, które są implementowane i udostępniane w AOSP jako biblioteki systemowe, ponieważ są zarezerwowane.
• [C-0-11] NALEŻY wyeksportować wszystkie symbole funkcji OpenGL ES 3.1 i pakietu rozszerzeń Androida zdefiniowane w NDK za pomocą biblioteki libGLESv3.so. Pamiętaj, że chociaż wszystkie symbole MUSZĄ być obecne, w sekcji 7.1.4.1 podano bardziej szczegółowe wymagania dotyczące pełnej implementacji poszczególnych funkcji.
• [C-0-12] Musisz wyeksportować 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 chociaż wszystkie symbole MUSZĄ być obecne, w sekcji 7.1.4.2 podano bardziej szczegółowe wymagania dotyczące pełnej implementacji poszczególnych funkcji.
• NALEŻY go skompilować, używając kodu źródłowego i plików nagłówków dostępnych w upstreamowym projekcie Android Open Source.

Pamiętaj, że w przyszłych wersjach Androida możemy dodać obsługę dodatkowych ABI.

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

Jeśli implementacje na urządzeniu zgłaszają obsługę ABI armeabi, to:

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

Jeśli implementacje urządzeń zgłaszają obsługę ABI armeabi-v7a, aplikacje korzystające z tego ABI:

• [C-2-1] W pliku /proc/cpuinfo MUSISZ uwzględnić podane niżej wiersze i NIE wolno Ci zmieniać wartości na tym samym urządzeniu, nawet jeśli są one odczytywane przez inne ABI.

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

• [C-2-2] NALEŻY zawsze mieć dostępne te operacje, nawet jeśli ABI jest implementowany na architekturze ARMv8, za pomocą natywnego wsparcia procesora lub emulacji oprogramowania:

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

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

3.4. Zgodność z przeglądarką

3.4.1. Zgodność WebView

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

• [C-1-1] MUST report android.software.webview.
• [C-1-2] Do implementacji interfejsu API android.webkit.WebView MUSISZ użyć kompilacji projektu Chromium z upstreamowego projektu Android Open Source na gałęzi Androida 10.

• [C-1-3] Ciąg tekstowy klienta użytkownika przesyłany przez WebView MUSI mieć format:

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

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

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

• [C-1-4] NALEŻY renderować dostarczone treści lub treści z odległego adresu URL w procesie, który jest odrębny od aplikacji, która instancjuje WebView. Proces oddzielnego renderera MUSI mieć mniejsze uprawnienia, działać jako oddzielny identyfikator użytkownika, nie mieć dostępu do katalogu danych aplikacji, nie mieć bezpośredniego dostępu do sieci i mieć dostęp tylko do minimalnych wymaganych usług systemowych za pomocą Bindera. Implementacja WebView w AOSP spełnia ten wymóg.

Pamiętaj, że jeśli implementacje urządzeń są 32-bitowe lub deklarują flagę funkcji android.hardware.ram.low, są one wyłączone z wymagań C-1-3.

3.4.2. Zgodność z przeglądarką

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

• [C-1-1] MUSI obsługiwać wszystkie te interfejsy API związane z HTML5:
  • pamięć podręczna aplikacji/operacja offline
  • tag<video>
  • geolocation
• [C-1-2] MUSI obsługiwać interfejs webstorage API w HTML5/W3C oraz ZALECA się obsługę interfejsu IndexedDB API w HTML5/W3C. Pamiętaj, że organizacje opracowujące standardy dotyczące tworzenia stron internetowych przechodzą na IndexedDB zamiast Web Storage, dlatego IndexedDB ma stać się wymaganym komponentem w przyszłej wersji Androida.
• W samodzielnej aplikacji przeglądarki MOŻNA przesyłać niestandardowy ciąg znaków klienta użytkownika.
• NALEŻY wdrożyć obsługę jak największej części HTML5 w samodzielnej aplikacji przeglądarki (opracowanej na podstawie przeglądarki WebKit lub zastępczej przeglądarki innej firmy).

Jeśli jednak implementacje na urządzeniach nie obejmują samodzielnej aplikacji przeglądarki, nie mogą:

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

3.5. Zgodność zachowania interfejsu API

Implementacje na urządzeniu:

• [C-0-9] NALEŻY zadbać o to, aby zgodność z zachowaniem interfejsu API była stosowana we wszystkich zainstalowanych aplikacjach, chyba że są one ograniczone zgodnie z opisem w sekcji 3.5.1.
• [C-0-10] NIE WDRAŻAJ metody listy dozwolonych, która zapewnia zgodność zachowania interfejsu API tylko w przypadku aplikacji wybranych przez implementatorów urządzeń.

Zachowanie każdego z typów interfejsów API (zarządzanych, miękkich, natywnych i internetowych) MUSI być zgodne z preferowaną implementacją Android Open Source Project. Niektóre konkretne obszary zgodności to:

• [C-0-1] Urządzenia NIE MOGĄ zmieniać działania ani semantyki standardowego zamiaru.
• [C-0-2] Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (np. usługi, aktywności, dostawcy treści itp.).
• [C-0-3] Urządzenia NIE MOGĄ zmieniać semantyki standardowych uprawnień.
• Urządzenia NIE MOGĄ zmieniać ograniczeń narzucanych na aplikacje działające w tle. W szczególności w przypadku aplikacji działających w tle:
  • [C-0-4] NALEŻY zatrzymać wykonywanie wywołań zwrotnych zarejestrowanych przez aplikację w celu otrzymywania danych wyjściowych z GnssMeasurement i GnssNavigationMessage.
  • [C-0-5] NALEŻY ograniczyć częstotliwość aktualizacji przekazywanych aplikacji za pomocą klasy interfejsu API LocationManager lub metody WifiManager.startScan().
  • [C-0-6] Jeśli aplikacja jest kierowana na poziom interfejsu API 25 lub wyższy, NIE MOŻE ona 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 poziom interfejsu API 25 lub wyższy, MUSI zatrzymać usługi działające w tle, tak jakby aplikacja wywołała metodę stopSelf() usługi, chyba że aplikacja została umieszczona na liście dozwolonych tymczasowo, aby obsłużyć zadanie widoczne dla użytkownika.
  • [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zwolnić blokady aktywacji, którą posiada.
• [C-0-9] Urządzenia MUSZĄ zwracać wymienionych dostawców zabezpieczeń jako pierwsze 7 wartości tablicy z metody Security.getProviders(), w podanej kolejności i z podanymi nazwami (zwróconymi przez Provider.getName()) oraz klasami, chyba że aplikacja zmodyfikowała listę za pomocą metody insertProviderAt() lub removeProvider(). Urządzenia MOGĄ zwracać dodatkowych dostawców po wskazanej liście dostawców poniżej.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider – sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround – android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore –android.security.keystore.AndroidKeyStoreProvider

Powyższa lista nie jest wyczerpująca. Pakiet Compatibility Test Suite (CTS) testuje znaczne części platformy pod kątem zgodności behawioralnej, ale nie wszystkie. Implementator musi zadbać o zachowanie zgodności z Android Open Source Project. Dlatego implementatorzy urządzeń powinni w miarę możliwości używać kodu źródłowego dostępnego w ramach Projektu Android Open Source, a nie ponownie wdrażać istotnych części systemu.

3.5.1. Ograniczenie działania w tle

Jeśli implementacje urządzeń implementują ograniczenia aplikacji zawarte w AOSP lub rozszerzają ograniczenia aplikacji, muszą:

• [C-1-1] Musisz umożliwić użytkownikowi wyświetlenie listy aplikacji objętych ograniczeniami.
• [C-1-2] NALEŻY umożliwić użytkownikowi włączenie lub wyłączenie ograniczeń w poszczególnych aplikacjach.
• [C-1-3] Nie wolno automatycznie stosować ograniczeń bez dowodu na nieprawidłowe działanie systemu, ale można stosować ograniczenia w przypadku wykrycia nieprawidłowego działania systemu, takiego jak zablokowane blokady budzenia, długotrwałe uruchamianie usług i inne kryteria. Kryteria MOŻNA określić w ramach implementacji urządzenia, ale MUSZĄ one być związane z wpływem aplikacji na stan systemu. Nie wolno używać innych kryteriów, które nie są związane wyłącznie ze stanem systemu, takich jak brak popularności aplikacji na rynku.
• [C-1-4] NIE WOLNO automatycznie stosować ograniczeń aplikacji, gdy użytkownik ręcznie je wyłączył. MOŻNA zasugerować użytkownikowi zastosowanie ograniczeń aplikacji.
• [C-1-5] NALEŻY informować użytkowników, jeśli ograniczenia są stosowane automatycznie.
• [C-1-6] W przypadku wywołania tego interfejsu API przez aplikację z ograniczonym dostępem musi on zwracać wartość true dla ActivityManager.isBackgroundRestricted().
• [C-1-7] NIE MOŻESZ ograniczać działania aplikacji na pierwszym planie, której użytkownik używa w pełni.
• [C-1-8] NALEŻY zawiesić ograniczenia dotyczące aplikacji, która staje się główną aplikacją na pierwszym planie, gdy użytkownik wyraźnie zacznie z niej korzystać.

3.6. Nazwy katalogów interfejsu API

Android stosuje konwencje dotyczące przestrzeni nazw pakietów i klas zdefiniowane przez język programowania Java. Aby zapewnić zgodność z aplikacjami innych firm, implementatorzy urządzeń NIE MOGĄ wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w następujących przestrzeniach nazw pakietów:

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

Oznacza to, że:

• [C-0-1] Nie wolno modyfikować publicznie udostępnionych interfejsów API na platformie Androida przez zmianę sygnatur metod lub klas albo usunięcie klas lub pól klas.
• [C-0-2] DO interfejsów API w wymienionych powyżej przestrzeniach nazw NIE MOŻESZ dodawać żadnych publicznie dostępnych elementów (np. klas, interfejsów, pól lub metod do istniejących klas lub interfejsów) ani interfejsów API Test lub System. „Publicznie dostępny element” to dowolna konstrukcja, która nie jest ozdobiona znacznikiem „@hide” używanym w poprzednim kodzie źródłowym Androida.

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

• [C-0-3] NIE MOŻE wpływać na opisane zachowanie i sygnatura języka Java w żadnym z publicznie udostępnionych interfejsów API.
• [C-0-4] NIE MOŻE być reklamowany ani w inny sposób udostępniany deweloperom.

Implementatorzy urządzeń mogą jednak dodawać niestandardowe interfejsy API poza standardową przestrzenią nazw Androida, ale te niestandardowe interfejsy API:

• [C-0-5] NIE MOŻE znajdować się w przestrzeni nazw należącej do innej organizacji ani nie może odnosić się do innej organizacji. Na przykład implementatorzy urządzeń NIE MOGĄ dodawać interfejsów API do przestrzeni nazw com.google.* ani podobnych: może to robić tylko Google. Podobnie Google NIE MOŻE dodawać interfejsów API do przestrzeni nazw innych firm.
• [C-0-6] Musi być zapakowany w bibliotece współdzielonej Androida, aby tylko aplikacje, które z nich korzystają (za pomocą mechanizmu <uses-library>), były objęte zwiększonym zużyciem pamięci przez te interfejsy API.

Jeśli implementator urządzenia zamierza ulepszyć jedną z wymienionych powyżej przestrzeni nazw pakietów (np. przez dodanie nowej przydatnej 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.

Pamiętaj, że powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java. Celem tej sekcji jest po prostu wzmocnienie tych konwencji i ustanowienie ich jako wiążących poprzez uwzględnienie w tej definicji zgodności.

3.7. Zgodność w czasie działania

Implementacje na urządzeniu:

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

• [C-0-2] NALEŻY skonfigurować środowisko uruchomieniowe Dalvik tak, aby przydzielać pamięć zgodnie z platformą Android na wyższym poziomie i zgodnie z danymi podanymi w tabeli poniżej. (Definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).

• NALEŻY użyć Android RunTime (ART), referencyjnej implementacji upstream formatu wykonywalnego Dalvik oraz systemu zarządzania pakietami referencyjnej implementacji.

• NALEŻY przeprowadzić testy fuzz w różnych trybach wykonywania i na różnych architekturach docelowych, aby zapewnić stabilność środowiska uruchomieniowego. Zapoznaj się z informacjami o JFuzz i DexFuzz na stronie Projektu Android Open Source.

Pamiętaj, że podane poniżej wartości pamięci są wartościami minimalnymi, a implementacje urządzeń MOŻE przydzielić więcej pamięci na aplikację.

3.8. Zgodność interfejsu

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

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

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

• [C-1-1] NALEŻY zadeklarować funkcję platformy android.software.home_screen.
• [C-1-2] NALEŻY zwrócić obiekt AdaptiveIconDrawable, gdy aplikacja innej firmy używa tagu <adaptive-icon> do wyświetlenia ikony i wywołuje metody PackageManager, aby pobrać ikony.

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

• [C-2-1] MUST report true for ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] Przed dodaniem skrótu żądanego przez aplikacje za pomocą metody interfejsu API ShortcutManager.requestPinShortcut() należy poprosić użytkownika o pozwolenie.
• [C-2-3] MUSI obsługiwać przypięte skróty oraz skróty dynamiczne i statyczne zgodnie z informacjami na stronie Skróty do aplikacji.

Jeśli implementacja urządzenia nie obsługuje przypinania skrótów w aplikacji, nie można:

• [C-3-1] MUST report false for ShortcutManager.isRequestPinShortcutSupported().

Jeśli implementacje urządzeń korzystają z 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, to:

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

Jeśli implementacje urządzeń obejmują domyślną aplikację uruchamiającą, która wyświetla plakietki dla ikon aplikacji, muszą one:

• [C-5-1] MUSI przestrzegać metody interfejsu API NotificationChannel.setShowBadge(). Innymi słowy, wyświetlaj wizualną ikonę powiązaną z ikoną aplikacji, jeśli wartość jest ustawiona na true, i nie wyświetlaj żadnego schematu plakietki ikony aplikacji, gdy wszystkie kanały powiadomień aplikacji mają wartość ustawioną na false.
• MOGĄ zastąpić plakietki ikon aplikacji zastrzeżonymi schematami plakietek, gdy aplikacje innych firm wskazują na obsługę zastrzeżonych schematów plakietek za pomocą 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, takich jak Notification.Builder.setNumber() i interfejs API Notification.Builder.setBadgeIconType().

3.8.2. Widżety

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

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

• [C-1-1] MUSISZ zadeklarować obsługę funkcji platformy android.software.app_widgets.
• [C-1-2] Musisz uwzględnić wbudowane funkcje obsługi widżetów aplikacji i zapewnić użytkownikom możliwość dodawania, konfigurowania, wyświetlania i usuwania widżetów bezpośrednio w wyskakującym okienku.
• [C-1-3] Musi być możliwe renderowanie widżetów o wymiarach 4 x 4 w standardowym rozmiarze siatki. Szczegółowe informacje znajdziesz w wytycznych dotyczących projektowania widżetów aplikacji w dokumentacji pakietu Android SDK.
• MOŻE obsługiwać widżety aplikacji na ekranie blokady.

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

• [C-2-1] MUST report true for AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] Przed dodaniem skrótu żądanego przez aplikacje za pomocą metody interfejsu API AppWidgetManager.requestPinAppWidget() należy poprosić użytkownika o pozwolenie.

3.8.3. Powiadomienia

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

3.8.3.1. Prezentacja powiadomień

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

• [C-1-1] MUSI obsługiwać powiadomienia, które korzystają z funkcji sprzętowych zgodnie z dokumentacją pakietu SDK oraz w jak największym stopniu z urządzenia implementującego sprzęt. Jeśli na przykład implementacja urządzenia zawiera wibrator, musi on prawidłowo implementować interfejsy API wibracji. Jeśli implementacja urządzenia nie zawiera sprzętu, odpowiednie interfejsy API MUSZĄ być zaimplementowane jako no-ops. Szczegółowe informacje na ten temat znajdziesz w sekcji 7.
• [C-1-2] Aplikacja MUSI prawidłowo wyświetlać wszystkie zasobów (ikony, pliki animacji itp.) udostępnione w interfejsach API lub w przewodniku po stylu ikon w pasku stanu/systemowym, ale MOGĄ one zapewniać użytkownikom inne wrażenia w przypadku powiadomień niż te oferowane przez referencyjną implementację na Androida w wersji open source.
• [C-1-3] MUSISZ prawidłowo stosować zachowania opisane w interfejsach API, aby aktualizować, usuwać i grupować powiadomienia.
• [C-1-4] NALEŻY podać pełne informacje o zachowaniu interfejsu NotificationChannel w dokumentacji pakietu SDK.
• [C-1-5] Musisz umożliwić użytkownikowi zablokowanie i zmodyfikowanie powiadomienia określonej aplikacji innej firmy na każdym poziomie kanału i poziomu pakietu aplikacji.
• [C-1-6] NALEŻY też zapewnić użytkownikowi możliwość wyświetlenia usuniętych kanałów powiadomień.
• [C-1-7] NALEŻY prawidłowo renderować wszystkie zasoby (obrazy, naklejki, ikony itp.) udostępniane za pomocą Notification.MessagingStyle wraz z tekstem powiadomienia bez dodatkowej interakcji użytkownika. Na przykład w rozmowie grupowej ustawionej za pomocą setGroupConversation MUSISZ wyświetlać wszystkie zasoby, w tym ikony, które są dostarczane przez android.app.Person.
• [C-SR] MOCNO POLECAMY automatyczne wyświetlanie użytkownikowi opcji blokowania powiadomień z określonej aplikacji innej firmy w przypadku każdego kanału i poziomu pakietu aplikacji po tym, jak użytkownik wielokrotnie zamknie powiadomienie.
• Powinien obsługiwać powiadomienia z elementami rozszerzonymi.
• Niektóre powiadomienia o wyższym priorytecie powinny być wyświetlane jako powiadomienia z ostrzeżeniem.
• NALEŻY umożliwić użytkownikowi wyciszenie powiadomień.
• MOŻE zarządzać widocznością i czasem, w którym aplikacje innych firm mogą powiadamiać użytkowników o istotnych zdarzeniach, aby ograniczyć problemy związane z bezpieczeństwem, takie jak rozproszenie uwagi kierowcy.

Jeśli implementacje urządzeń obsługują powiadomienia z zawartością multimedialną, mogą:

• [C-2-1] W przypadku prezentowanych elementów zasobów NALEŻY używać zasobów dokładnie takich, jakie są dostarczane przez klasę interfejsu API Notification.Style i jej podklasy.
• NALEŻY przedstawić wszystkie elementy zasobu (np. ikonę, tytuł i tekst podsumowania) zdefiniowane w klasie interfejsu API Notification.Style i jej podklasach.

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

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

3.8.3.2. Usługa odbiornika powiadomień

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

Jeśli implementacje na urządzeniach zgłaszają flagę funkcji android.hardware.ram.normal, to:

• [C-1-1] NALEŻY prawidłowo i na bieżąco aktualizować powiadomienia w całości w przypadku wszystkich zainstalowanych usług odsłuchujących, w tym wszystkich metadanych dołączonych do obiektu powiadomienia.
• [C-1-2] MUSI obsługiwać wywołanie interfejsu API snoozeNotification(), zamknąć powiadomienie i wykonać wywołanie zwrotne po upływie czasu odroczenia ustawionego w wywołaniu interfejsu API.

Jeśli implementacje urządzeń umożliwiają użytkownikom wyciszanie powiadomień, muszą one:

• [C-2-1] MUSI prawidłowo odzwierciedlać stan powiadomienia wyciszonego za pomocą standardowych interfejsów API, takich jak NotificationListenerService.getSnoozedNotifications().
• [C-2-2] NALEŻY umożliwić użytkownikom odkładanie powiadomień z każdej zainstalowanej aplikacji innej firmy, chyba że pochodzą one z usług działających w tle lub na pierwszym planie.

3.8.3.3. Nie przeszkadzać

Jeśli implementacje urządzeń obsługują funkcję DND, to:

• [C-1-1] NALEŻY zaimplementować aktywność, która będzie odpowiadać na intencję ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. W przypadku implementacji z UI_MODE_TYPE_NORMAL musi to być aktywność, w której użytkownik może zezwolić lub odmówić aplikacji dostępu do konfiguracji zasad Nie przeszkadzać.
• [C-1-2] W przypadku implementacji na urządzeniu, która umożliwia użytkownikowi zezwolenie lub odmowę zezwolenia aplikacjom innych firm na dostęp do konfiguracji trybu Nie przeszkadzać, należy wyświetlić automatyczne zasady trybu Nie przeszkadzać utworzone przez aplikacje obok zdefiniowanych przez użytkownika i wstępnie zdefiniowanych zasad.
• [C-1-3] MUSI obsługiwać wartości suppressedVisualEffects przekazywane w ramach NotificationManager.Policy. Jeśli aplikacja ma ustawione flagi SUPPRESSED_EFFECT_SCREEN_OFF lub SUPPRESSED_EFFECT_SCREEN_ON, POWINNA poinformować użytkownika, że efekty wizualne są tłumione w menu ustawień DND.

3.8.4. Szukaj

Android zawiera interfejsy API, które umożliwiają deweloperom włączanie wyszukiwania w aplikacjach i udostępnianie danych aplikacji w globalnym wyszukiwaniu systemowym. Ogólnie ta funkcja składa się z jednego interfejsu użytkownika obejmującego cały system, który umożliwia wpisywanie zapytań, wyświetlanie sugestii podczas pisania i wyświetlanie wyników. Interfejsy API Androida umożliwiają deweloperom ponowne używanie tego interfejsu do udostępniania wyszukiwania w ich własnych aplikacjach oraz dostarczania wyników do wspólnego globalnego interfejsu wyszukiwania.

• Implementacje na urządzeniach z Androidem powinny zawierać 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 na urządzeniach korzystają z globalnego interfejsu wyszukiwania, muszą:

• [C-1-1] NALEŻY wdrożyć interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii do pola wyszukiwania, gdy jest ono używane w trybie wyszukiwania globalnego.

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

• Domyślne działanie powinno polegać na wyświetlaniu wyników i sugestii wyszukiwarki internetowej.

Android zawiera też interfejsy API Asystenta, które umożliwiają aplikacjom określenie, ile informacji o bieżącym kontekście ma być udostępniane Asystentowi na urządzeniu.

Jeśli implementacje urządzeń obsługują działanie Asystent:

• [C-2-1] NALEŻY wyraźnie poinformować użytkownika o tym, kiedy kontekst jest udostępniany, w ten sposób:
  • Za każdym razem, gdy aplikacja asystująca uzyskuje dostęp do kontekstu, wyświetla białe światło na krawędziach ekranu, które odpowiada lub przekracza czas trwania i jasność implementacji projektu Android Open Source.
  • W przypadku wstępnie zainstalowanej aplikacji asystenta użytkownik musi mieć możliwość wykonania nie więcej niż 2 operacji nawigacyjnych od domyślnego menu ustawień głosowego wprowadzania danych i aplikacji asystenta. Użytkownik może udostępnić kontekst tylko wtedy, gdy aplikacja asystenta zostanie wywołana przez użytkownika za pomocą słowa kluczowego lub przycisku nawigacyjnego asystenta.
• [C-2-2] Wyznaczona interakcja, która uruchamia aplikację asystenta zgodnie z opisem w sekcji 7.2.3, MUSI uruchamiać wybraną przez użytkownika aplikację asystenta, czyli aplikację, która implementuje VoiceInteractionService, lub aktywność obsługującą intencję ACTION_ASSIST.

3.8.5. Alerty i powiadomienia wyświetlane na ekranie

Aplikacje mogą używać interfejsu API Toast, aby wyświetlać krótkie niemodalne ciągi tekstowe, które znikają po krótkim czasie, oraz interfejsu API typu okna TYPE_APPLICATION_OVERLAY, aby wyświetlać okna z ostrzeżeniem jako nakładkę na inne aplikacje.

Jeśli implementacje urządzeń obejmują ekran lub wyjście wideo, muszą:

• [C-1-1] Konieczne jest zapewnienie użytkownikowi możliwości zablokowania wyświetlania przez aplikację okien alertów, które używają TYPE_APPLICATION_OVERLAY . Implementacja AOSP spełnia ten wymóg, ponieważ zawiera elementy sterujące w pasku powiadomień.

• [C-1-2] NALEŻY stosować interfejs Toast API i wyświetlać komunikaty Toast użytkownikom w wyraźnie widoczny sposób.

3.8.6. Motywy

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

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

Jeśli implementacje urządzeń obejmują ekran lub wyjście wideo, muszą:

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

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

• Implementacje na urządzeniu mogą modyfikować atrybuty motywu domyślnego urządzenia udostępniane aplikacjom.

Android obsługuje wariant motywu z przezroczystymi paskami systemu, co pozwala deweloperom aplikacji wypełnić obszar za paskiem stanu i paskiem nawigacji treściami aplikacji. Aby zapewnić spójne środowisko deweloperów w ramach tej konfiguracji, ważne jest, aby styl ikony paska stanu był zachowany na różnych urządzeniach.

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

• [C-2-1] Należy używać koloru białego do ikon stanu systemu (takich jak siła sygnału i poziom naładowania baterii) oraz powiadomień wysyłanych przez system, chyba że ikona wskazuje stan problemowy lub aplikacja prosi o jasny pasek stanu za pomocą flagi SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
• [C-2-2] Implementacje urządzeń z Androidem MUSZĄ zmienić kolor ikon stanu systemu na czarny (szczegóły znajdziesz w R.style), gdy aplikacja poprosi o jasny pasek stanu.

3.8.7. Animowane tapety

Android definiuje typ komponentu oraz odpowiadający mu interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi co najmniej 1 animowanej tapety. Tapety na żywo to animacje, wzory lub podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które wyświetlają się jako tapeta za innymi aplikacjami.

Urządzenie jest uznawane za zdolne do niezawodnego wyświetlania tapet na żywo, jeśli może odtwarzać wszystkie tapety na żywo bez ograniczeń funkcjonalności, przy rozsądznej częstotliwości klatek i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują, że tapety lub aplikacje ulegają awarii, nie działają prawidłowo, zużywają zbyt dużo energii procesora lub baterii albo działają z niedopuszczalnie niską liczbą klatek na sekundę, sprzęt jest uznawany za niezdolny do obsługi tapety na żywo. Na przykład niektóre tapety na żywo mogą używać kontekstu OpenGL 2.0 lub 3.x do renderowania treści. Tapeta na żywo nie będzie działać prawidłowo na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ używanie przez nią tego kontekstu może powodować konflikty z innymi aplikacjami, które również go używają.

• Urządzenia, które mogą niezawodnie wyświetlać tapety na żywo zgodnie z opisem powyżej, POWINNY obsługiwać tapety na żywo.

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

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

3.8.8. Przełączanie aktywności

Dostarczony przez Ciebie kod źródłowy Androida obejmuje ekran przeglądu, czyli interfejs użytkownika na poziomie systemu, który umożliwia przełączanie zadań i wyświetlanie ostatnio używanych czynności i zadań za pomocą miniatury graficznego stanu aplikacji w momencie, gdy użytkownik ostatnio ją zamknął.

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

Jeśli implementacje urządzeń, w tym klucz nawigacyjny funkcji Ostatnie, zgodnie z opisem w sekcji 7.2.3 zmieniają interfejs, muszą:

• [C-1-1] Musi obsługiwać co najmniej 7 wyświetlanych aktywności.
• POWINIEN wyświetlać co najmniej tytuł 4 aktywności naraz.
• [C-1-2] NALEŻY wdrożyć zachowanie przypinania ekranu i udostępnić użytkownikowi menu ustawień, aby włączyć tę funkcję.
• NALEŻY wyświetlić kolor wyróżnienia, ikonę i tytuł ekranu w ostatnich.
• NALEŻY wyświetlić opcję zamknięcia („x”), ale MOŻNA opóźnić to, aż użytkownik wejdzie w interakcję z ekranami.
• NALEŻY wdrożyć skrót umożliwiający łatwe przełączanie się na poprzednią aktywność.
• POWINIEN wywoływać szybkie przełączanie między 2 ostatnio używanymi aplikacjami, gdy dwukrotnie kliknie się przycisk funkcji Ostatnio używane.
• POWINIEN aktywować tryb wielookien podzielonego ekranu (jeśli jest obsługiwany), gdy przycisk funkcji ostatnich aplikacji jest długo naciśnięty.
• MOŻNA wyświetlać powiązane ostatnie elementy jako grupę, która porusza się razem.
• [SR] NAJLEPSZEJ jest użycie na ekranie przeglądu górnego interfejsu użytkownika Androida (lub podobnego interfejsu opartego na miniaturach).

3.8.9. Zarządzanie wejściami

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

Jeśli implementacje urządzeń umożliwiają użytkownikom korzystanie z metod wprowadzania danych innych firm, użytkownicy mogą:

• [C-1-1] NALEŻY zadeklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy API IME zgodnie z dokumentacją pakietu Android SDK.
• [C-1-2] Musisz udostępnić użytkownikowi mechanizm umożliwiający dodawanie i konfigurowanie metod wprowadzania innych firm w odpowiedzi na intencję android.settings.INPUT_METHOD_SETTINGS.

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

• [C-2-1] NALEŻY w pełni wdrożyć interfejsy API AutofillService i AutofillManager oraz uwzględnić intencję android.settings.REQUEST_SET_AUTOFILL_SERVICE wyświetlania menu ustawień domyślnej aplikacji w celu włączenia i wyłączenia autouzupełniania oraz zmiany domyślnej usługi autouzupełniania dla użytkownika.

3.8.10. Sterowanie multimediami na ekranie blokady

W Androidzie 5.0 interfejs Remote Control Client API został wycofany na rzecz szablonu powiadomienia multimedialnego, który umożliwia aplikacjom multimedialnym integrację z elementami sterowania odtwarzaniem wyświetlanymi na ekranie blokady.

3.8.11. Wygaszacze ekranu (wcześniej Dreams)

Android obsługuje interaktywne wygaszacze ekranu, które wcześniej nazywano „marzeniami”. Wygaszacze ekranu umożliwiają użytkownikom korzystanie z aplikacji, 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, ale inne typy urządzeń powinny zawierać obsługę wygaszaczy i opcję ustawień, która umożliwia użytkownikom skonfigurowanie wygaszaczy w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

3.8.12. Lokalizacja

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

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

3.8.13. Unicode i czcionka

Android obsługuje znaki emoji zdefiniowane w Unicode 10.0.

Jeśli implementacje urządzeń obejmują ekran lub wyjście wideo, muszą:

• [C-1-1] Musi być możliwe renderowanie tych emotikonów w kolorze.
• [C-1-2] MUSI obsługiwać:
  • czcionka Roboto 2 w różnych grubościach: sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light w przypadku języków dostępnych na urządzeniu.
  • Pełna obsługa Unicode 7.0 w przypadku alfabetów łacińskiego, greckiego i cyrylicy, w tym zakresów A, B, C i D łacińskiego rozszerzonego oraz wszystkich znaków w bloku symboli walut w Unicode 7.0.
• POWINNY obsługiwać odcienie skóry i emotikony przedstawiające różne rodziny, zgodnie z raportami technicznymi Unicode nr 51.

Jeśli implementacje na urządzeniach obejmują IME, muszą:

• NALEŻY podać użytkownikowi metodę wprowadzania tych emotikonów.

Android obsługuje renderowanie czcionek birmańskich. W Mjanmie do wyświetlania języków mjanma używa się kilku czcionek niezgodnych z Unicode, powszechnie znanych jako „Zawgyi”.

Jeśli implementacja urządzenia obejmuje obsługę języka birmańskiego, urządzenie:

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

3.8.14. Wiele okien

Jeśli implementacje urządzeń mają możliwość wyświetlania wielu aktywności jednocześnie, muszą:

• [C-1-1] NALEŻY wdrożyć takie tryby wielookien zgodnie z zachowaniem aplikacji i interfejsami API opisanymi w dokumentacji obsługi trybu wielookienistego pakietu SDK Androida oraz spełnić te wymagania:
• [C-1-2] Musi uwzględniać wartość android:resizeableActivity ustawioną przez aplikację w pliku AndroidManifest.xml zgodnie z opisem w tym pakiecie SDK.
• [C-1-3] Nie wolno oferować trybu podzielonego ekranu ani trybu swobodnego, jeśli wysokość ekranu jest mniejsza niż 440 dp, a szerokość mniejsza niż 440 dp.
• [C-1-4] W trybach wielookiennych innych niż tryb obraz w obrazie rozmiar aktywności NIE MOŻE być mniejszy niż 220 dp.
• Implementacje urządzeń o rozmiarach ekranu xlarge POWINNY obsługiwać tryb swobodny.

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

• [C-2-1] NALEŻY wstępnie wczytać jako domyślny moduł uruchamiający aplikację, który można zmieniać rozmiar.
• [C-2-2] Należy przyciąć dokowane okno w ramach podzielonego ekranu, ale NALEŻY pokazać część jego zawartości, jeśli aplikacja Launcher jest oknem aktywnym.
• [C-2-3] MUSI honorować zadeklarowane wartości AndroidManifestLayout_minWidth i AndroidManifestLayout_minHeight aplikacji uruchamiającej innej firmy oraz nie może zastępować tych wartości podczas wyświetlania niektórych treści w ramach zadokowanej aktywności.

Jeśli implementacje urządzeń obsługują tryb wielu okien i tryb wielu okien z obrazem w obrazie, muszą:

• [C-3-1] Musisz uruchamiać czynności w wielozadaniowym trybie obrazu w obrazie, gdy aplikacja: * jest kierowana na interfejs API na poziomie 26 lub nowszym 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 SystemUI zgodnie z bieżącą aktywnością PIP za pomocą interfejsu API setActions().
• [C-3-3] Musi obsługiwać formaty obrazu o stosunkach od 1:2,39 do 2,39:1, zgodnie z określeniami aktywności okna w wyświetlaczu w ramach interfejsu API setAspectRatio().
• [C-3-4] DO sterowania oknem PIP należy UŻYWAĆ KeyEvent.KEYCODE_WINDOW; jeśli tryb PIP nie jest wdrożony, klucz MUSI być dostępny dla aktywności na pierwszym planie.
• [C-3-5] Musisz umożliwić użytkownikowi zablokowanie wyświetlania aplikacji w trybie obrazu w obrazie. Implementacja AOSP spełnia ten wymóg dzięki elementom sterującym w pasku powiadomień.
• [C-3-6] W przypadku okna PIP należy przypisać minimalną szerokość i wysokość 108 dp, a w przypadku okna PIP z ustawieniem Configuration.uiMode UI_MODE_TYPE_TELEVISION – minimalną szerokość 240 dp i wysokość 135 dp.

3.8.15. Wycięcie w ekranie

Android obsługuje wycięcie wyświetlacza zgodnie z opisem w dokumentacji pakietu SDK. Interfejs API DisplayCutout definiuje obszar na krawędzi wyświetlacza, który nie jest przeznaczony do wyświetlania treści.

Jeśli implementacje urządzeń zawierają wycięcia w ekranie, muszą spełniać te wymagania:

• [C-1-1] Wycięcia mogą znajdować się tylko na krótkich krawędziach urządzenia. Jeśli natomiast współczynnik proporcji urządzenia wynosi 1, 0 (1:1), nie może ono mieć wycięć.
• [C-1-2] Nie może być więcej niż 1 wycięcia na krawędź.
• [C-1-3] MUSI obsługiwać flagi wycięcia wyświetlacza ustawione przez aplikację za pomocą interfejsu API WindowManager.LayoutParams zgodnie z opisem w pakiecie SDK.
• [C-1-4] MUSI raportować prawidłowe wartości wszystkich danych wycinków zdefiniowanych w interfejsie API DisplayCutout.

3.9. Administracja urządzeniem

Android zawiera funkcje, które umożliwiają aplikacjom z zabezpieczeniami wykonywanie funkcji administracyjnych na poziomie systemu, takich jak egzekwowanie zasad dotyczących haseł czy zdalne wymazywanie danych, za pomocą interfejsu Android Device Administration API.

Jeśli implementacje urządzeń implementują pełny zakres zasad zarządzania urządzeniami zdefiniowanych w dokumentacji pakietu SDK Androida, to:

• [C-1-1] MUST declare android.software.device_admin.
• [C-1-2] MUSI obsługiwać konfigurowanie właściciela urządzenia zgodnie z opisem w sekcji 3.9.1 i sekcji 3.9.1.1.

3.9.1 Obsługa administracyjna urządzenia

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

Jeśli implementacje na urządzeniu deklarują android.software.device_admin, to:

• [C-1-1] MUSI obsługiwać rejestrowanie klienta Device Policy (DPC) jako aplikacji właściciela urządzenia w sposób opisany poniżej:
  • Jeśli implementacja urządzenia nie ma jeszcze skonfigurowanych danych użytkownika, to:
    • [C-1-3] MUST report true for DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] W odpowiedzi na działanie intencyjne android.app.action.PROVISION_MANAGED_DEVICE aplikacja DPC MUSI zostać zarejestrowana jako aplikacja właściciela urządzenia.
    • [C-1-5] NALEŻY zarejestrować aplikację DPC jako aplikację właściciela urządzenia, jeśli urządzenie deklaruje obsługę komunikacji Near Field Communication (NFC) za pomocą flagi funkcji android.hardware.nfc i odbiera wiadomość NFC zawierającą rekord z typem MIME MIME_TYPE_PROVISIONING_NFC.
  • Gdy implementacja urządzenia zawiera dane użytkownika, to:
    • [C-1-6] MUST report false for the DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] Nie wolno już rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia.
• [C-1-2] W trakcie procesu obsługi musisz wymagać od użytkownika wykonania jakiegoś działania, aby wyraził zgodę na ustawienie aplikacji jako właściciela urządzenia. Użytkownik może wyrazić zgodę na przetwarzanie danych podczas konfiguracji, ale nie może być ona 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 mechanizm promowania aplikacji skonfigurowanej w ich rozwiązaniu jako „odpowiednik właściciela urządzenia” dla standardowego „właściciela urządzenia” rozpoznawanego przez standardowe interfejsy API DevicePolicyManager w Androidzie, to:

• [C-2-1] Konieczne jest wdrożenie procesu weryfikacji, który potwierdza, że reklamowana aplikacja należy do legalnego rozwiązania do zarządzania urządzeniami firmowymi i została już skonfigurowana w ramach rozwiązania firmowego w taki sposób, aby miała prawa równoważne z prawami „Właściciela urządzenia”.
• [C-2-2] NALEŻY wyświetlić tę samą informację o zgodzie właściciela urządzenia w ramach AOSP, co w procesie inicjowanym przez android.app.action.PROVISION_MANAGED_DEVICE przed zarejestrowaniem aplikacji DPC jako „Właściciel urządzenia”.
• MOŻE zawierać dane użytkownika na urządzeniu przed zarejestrowaniem aplikacji DPC jako „Właściciel urządzenia”.

3.9.1.2 Zarządzanie profilem zarządzanym

Jeśli implementacje na urządzeniu deklarują android.software.managed_users, to:

• [C-1-1] IMPLEMENTOWAĆ interfejsy API, które umożliwiają aplikacji kontrolera zasad dotyczących urządzeń (DPC) stać się właścicielem nowego profilu zarządzanego.

• [C-1-2] Proces obsługi inicjowany przez użytkowników w ramach zarządzanego profilu (android.app.action.PROVISION_MANAGED_PROFILE) MUSI być zgodny z implementacją AOSP.

• [C-1-3] W ustawieniach należy DOSTARCZYC użytkownikowi następujące opcje, aby poinformować go, że dana funkcja systemu została wyłączona przez kontroler zasad dotyczących urządzeń (DPC):

  • Ujednoliconą ikonę lub inny element interfejsu użytkownika (np. ikonę informacji o AOSP w górę) wskazującą, że określone ustawienie jest ograniczone przez administratora urządzenia.
  • Krótki komunikat wyjaśniający, który administrator urządzenia udostępnia za pomocą setShortSupportMessage.
  • Ikona aplikacji DPC

3.9.2 Obsługa profilu zarządzanego

Jeśli implementacje na urządzeniu deklarują android.software.managed_users, to:

• [C-1-1] Musi obsługiwać profile zarządzane za pomocą interfejsów API android.app.admin.DevicePolicyManager.
• [C-1-2] NALEŻY zezwolić na utworzenie tylko 1 profila zarządzanego.
• [C-1-3] DO ZASŁANIA: musisz użyć plakietki ikony (podobnej do plakietki AOSP upstream) do reprezentowania zarządzanych aplikacji i widżetów oraz innych elementów interfejsu z plakietką, takich jak Ostatnie i Powiadomienia.
• [C-1-4] Musi wyświetlać ikonę powiadomienia (podobną do plakietki AOSP upstream) wskazującą, że użytkownik jest w aplikacji na zarządzanym profilu.
• [C-1-5] NALEŻY wyświetlić komunikat podpowiadający, że użytkownik jest w profilu zarządzanym, gdy urządzenie się obudzi (ACTION_USER_PRESENT) i aplikacja na pierwszym planie znajduje się w profilu zarządzanym.
• [C-1-6] Jeśli istnieje profil zarządzany, w oknie „Wybieranie” należy wyświetlić wizualną opcję umożliwiającą użytkownikowi przekierowanie intencji z profilu zarządzanego do głównego użytkownika lub odwrotnie, jeśli jest to możliwe w ramach sterownika zasad urządzenia.
• [C-1-7] Jeśli istnieje profil zarządzany, NALEŻY udostępnić użytkownikowi podstawowemu i profilowi zarządzanemu te funkcje:
  • oddzielne rozliczanie baterii, lokalizacji, danych mobilnych i zajęcia miejsca na dane w przypadku głównego użytkownika i profilu zarządzanego;
  • niezależne zarządzanie aplikacjami VPN zainstalowanymi w profilu głównego użytkownika lub zarządzanym.
  • niezależne zarządzanie aplikacjami zainstalowanymi na profilu głównego użytkownika lub profilu zarządzanym;
  • niezależne zarządzanie kontami w ramach profilu głównego lub profilu zarządzanego,
• [C-1-8] NALEŻY zadbać o to, aby wbudowane aplikacje do wybierania numerów, kontaktów i wiadomości mogły wyszukiwać i wyświetlać informacje o dzwoniącym z profilu zarządzanego (jeśli istnieje) obok informacji z profilu głównego, jeśli kontroler zasad urządzenia na to zezwala.
• [C-1-9] MUSI spełniać wszystkie wymagania dotyczące zabezpieczeń obowiązujące w przypadku urządzeń z włączoną funkcją wielu użytkowników (patrz sekcja 9.5), nawet jeśli profil zarządzany nie jest liczony jako dodatkowy użytkownik oprócz głównego użytkownika.
• [C-1-10] Musisz obsługiwać możliwość określenia osobnego ekranu blokady, który spełnia te wymagania, aby zezwolić na 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 na ekranie blokady dla profilu zarządzanego.
  • Dane logowania na ekranie blokady w profilu zarządzanym MUSZĄ korzystać z tych samych mechanizmów przechowywania i zarządzania danymi logowania co profil nadrzędny, zgodnie z dokumentacją na stronie projektu Androida Open Source.
  • Zasady dotyczące haseł w DPC MUSZĄ dotyczyć tylko danych logowania na ekranie blokady w profilu zarządzanym, chyba że są wywoływane w przypadku instancji DevicePolicyManager zwracanej przez funkcję getParentProfileInstance.
• Gdy kontakty z profilu zarządzanego są wyświetlane w preinstalowanym dzienniku połączeń, interfejsie podczas połączenia, powiadomieniach o rozmowie w toku i nieodebranych połączeniach, kontaktach i aplikacjach do obsługi wiadomości, powinny być oznaczone tym samym znacznikiem, który jest używany do wskazywania aplikacji na profilu zarządzanym.

3.9.3 Pomoc dla zarządzanych użytkowników

Jeśli implementacje na urządzeniu deklarują android.software.managed_users, to:

• [C-1-1] NALEŻY zapewnić użytkownikowi możliwość wylogowania się z bieżącego konta i powrotu do konta głównego w sesji dla wielu użytkowników, gdy isLogoutEnabled wróci do 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 ułatwia osobom niepełnosprawnym poruszanie się po urządzeniach. Ponadto Android udostępnia interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu odbieranie wywołań zwrotnych dotyczących zdarzeń związanych z użytkownikiem i systemem oraz generowanie alternatywnych mechanizmów sprzężenia zwrotnego, takich jak odczytywanie tekstu na głos, sprzężenie zwrotne haptyczne i sterowanie za pomocą kulki sterującej lub panelu dotykowego.

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

• [C-1-1] NALEŻY zaimplementować platformę dostępności Androida zgodnie z opisem w dokumentacji pakietu SDK interfejsów API dostępności.
• [C-1-2] Musi generować zdarzenia ułatwień dostępu i przekazywać odpowiednie AccessibilityEvent do wszystkich zarejestrowanych implementacji AccessibilityService zgodnie z dokumentacją pakietu SDK.
• [C-1-3] MUSI honorować android.settings.ACCESSIBILITY_SETTINGS, aby udostępnić użytkownikowi mechanizm umożliwiający włączenie i wyłączenie usług ułatwień dostępu innych firm obok wstępnie zainstalowanych usług ułatwień dostępu.
• [C-1-4] NALEŻY dodać przycisk na pasku nawigacyjnym systemu, który umożliwia użytkownikowi kontrolowanie usługi ułatwień dostępu, gdy włączone usługi ułatwień dostępu deklarują AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Pamiętaj, że w przypadku implementacji urządzenia bez paska nawigacji systemu ten wymóg nie ma zastosowania, ale implementacje urządzenia POWINNY umożliwiać użytkownikowi kontrolowanie tych usług ułatwień dostępu.

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

• [C-2-1] NALEŻY wdrożyć te wstępnie zainstalowane usługi ułatwień dostępu jako aplikacje Direct Boot Aware, gdy pamięć danych jest szyfrowana za pomocą szyfrowania na poziomie plików (FBE).
• NALEŻY zapewnić w ramach procesu konfiguracji mechanizm umożliwiający użytkownikom włączanie odpowiednich usług ułatwień dostępu, a także opcje dostosowywania rozmiaru czcionki, rozmiaru wyświetlacza i gestyk powiększania.

3.11. Zamiana tekstu na mowę

Android zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług konwersji tekstu na mowę (TTS), a także umożliwia dostawcom usług implementowanie usług TTS.

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

• [C-1-1] Musi obsługiwać interfejsy API ramowiska TTS na Androida.

Jeśli implementacje urządzeń obsługują instalację zewnętrznych mechanizmów TTS, mogą:

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

3.12. Framework wejścia TV

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

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

• [C-1-1] NALEŻY zadeklarować funkcję platformy android.software.live_tv.
• [C-1-2] MUSI obsługiwać wszystkie interfejsy TIF API, aby można było zainstalować aplikację, która korzysta z tych interfejsów, oraz korzystać z usługi zewnętrznego dostawcy, która korzysta z danych wejściowych TIF 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 pilnych działań.

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

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

3.14. Interfejs mediów

Jeśli implementacje urządzeń obejmują aplikacje nieaktywne głosowo (Aplikacje), które współpracują z aplikacjami innych firm za pomocą MediaBrowser lub MediaSession, Aplikacje:

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

• [C-1-3] NALEŻY wyświetlić ikonę aplikacji innej firmy, gdy wyświetlane są treści dostarczane przez tę aplikację.

• [C-1-4] Musisz umożliwić użytkownikowi interakcję z całą hierarchią MediaBrowser. MOŻE ograniczyć dostęp do części hierarchii, aby przestrzegać przepisów bezpieczeństwa (np. dotyczących rozpraszania uwagi kierowcy), ale NIE MOŻE faworyzować treści lub dostawcy treści.

• [C-1-5] NALEŻY uznać dwukrotne kliknięcie KEYCODE_HEADSETHOOK lub KEYCODE_MEDIA_PLAY_PAUSE za KEYCODE_MEDIA_NEXT w przypadku MediaSession.Callback#onMediaButtonEvent.

3.15. Aplikacje błyskawiczne

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

• [C-0-1] Aplikacjom błyskawicznym NALEŻY przyznać tylko uprawnienia, dla których wartość android:protectionLevel wynosi "instant".
• [C-0-2] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami za pomocą domyślnych intencji, chyba że występuje jedna z tych sytuacji:
  • Filtr wzoru intencji komponentu jest dostępny i ma wartość CATEGORY_BROWSABLE.
  • Działanie to jedno z tych: ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE.
  • element docelowy jest jawnie udostępniany za pomocą atrybutu android:visibleToInstantApps,
• [C-0-3] Aplikacje błyskawiczne NIE MOGĄ wchodzić w interakcje z zainstalowanymi aplikacjami, chyba że komponent jest widoczny dla aplikacji błyskawicznych za pomocą android:visibleToInstantApps.
• [C-0-4] Zainstalowane aplikacje NIE MOGĄ wyświetlać szczegółów aplikacji błyskawicznych na urządzeniu, chyba że aplikacja błyskawiczna wyraźnie połączy się z zainstalowaną aplikacją.
• Implementacje urządzeń MUSZĄ zapewniać użytkownikom te możliwości interakcji z aplikacją błyskawiczną. AOSP spełnia wymagania dzięki domyślnemu interfejsowi systemu, ustawieniom i wywoływaczowi. Implementacje na urządzeniach:
  • [C-0-5] NALEŻY zapewnić użytkownikowi możliwość wyświetlania i usuwania aplikacji błyskawicznych zapisanych lokalnie w pamięci podręcznej w przypadku każdego pojedynczego pakietu aplikacji.
  • [C-0-6] Musisz wyświetlać stałe powiadomienie, które można zwinąć, gdy aplikacja błyskawiczna działa na pierwszym planie. Powiadomienie musi zawierać informację, że aplikacje błyskawiczne nie wymagają instalacji, oraz opcję przekierowania użytkownika do ekranu z informacjami o aplikacji w Ustawieniach. W przypadku aplikacji natychmiastowych uruchamianych za pomocą intencji internetowych, zdefiniowanych za pomocą intencji z działaniem ustawionym na Intent.ACTION_VIEW i schematem „http” lub „https”, dodatkowe opcje interfejsu użytkownika POWINNY umożliwiać użytkownikowi nie tylko uruchomienie aplikacji natychmiastowej, ale też uruchomienie powiązanego linku w skonfigurowanej przeglądarce internetowej, jeśli jest ona dostępna na urządzeniu.
  • [C-0-7] NALEŻY zezwolić na dostęp do uruchomionych aplikacji błyskawicznych z funkcji Ostatnie, jeśli jest ona dostępna na urządzeniu.

3.16. Parowanie urządzenia towarzyszącego

Android obsługuje parowanie urządzeń towarzyszących, aby umożliwić skuteczniejsze zarządzanie powiązaniem z urządzeniami towarzyszącymi. Udostępnia też interfejs API CompanionDeviceManager, który umożliwia aplikacjom dostęp do tej funkcji.

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

• [C-1-1] NALEŻY zadeklarować flagę funkcji FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] Musisz mieć pewność, że interfejsy API w pakiecie android.companion są w pełni zaimplementowane.
• [C-1-3] NALEŻY zapewnić użytkownikowi możliwość wybrania/potwierdzenia, że urządzenie towarzyszące jest obecne i działa.

3.17. Aplikacje o dużej pojemności

Jeśli implementacje na urządzeniu deklarują funkcję FEATURE_CANT_SAVE_STATE, to:

• [C-1-1] W systemie może być uruchomiona tylko 1 aplikacja, która określa cantSaveState. Jeśli użytkownik opuszcza taką aplikację bez jej zamykania (np. naciskając przycisk „Strona główna” podczas korzystania z aktywnej aktywności w systemie zamiast nacisnąć przycisk „Wstecz” bez żadnych aktywnych aktywności w systemie), implementacje urządzeń MUSZĄ nadać tej aplikacji priorytet w pamięci RAM, tak jak w przypadku innych elementów, które mają pozostać uruchomione, takich jak usługi na pierwszym planie. Gdy taka aplikacja działa w tle, system może nadal stosować w niej funkcje zarządzania energią, takie jak ograniczanie dostępu do procesora i do sieci.
• [C-1-2] Musisz zapewnić możliwość wybrania aplikacji, która nie będzie korzystać z normalnego mechanizmu zapisywania/przywracania stanu, gdy użytkownik uruchomi drugą aplikację zadeklarowaną za pomocą atrybutu cantSaveState.
• [C-1-3] DO aplikacji, które określają cantSaveState, NIE MOŻNA stosować innych zmian w zasadach, takich jak zmiana wydajności procesora lub zmiana priorytetów harmonogramu.

Jeśli implementacje na urządzeniu nie deklarują funkcji FEATURE_CANT_SAVE_STATE, to:

• [C-1-1] Musisz zignorować atrybut cantSaveState ustawiony przez aplikacje i nie możesz zmienić zachowania aplikacji na podstawie tego atrybutu.

4. Zgodność z pakietem aplikacji

Implementacje na urządzeniach:

• [C-0-1] Aplikacja MUSI umożliwiać instalowanie i uruchamianie plików „.apk” na Androida wygenerowanych przez narzędzie „aapt” zawarte w oficjalnym pakiecie Android SDK.
• Powyższe wymaganie może być trudne do spełnienia, dlatego zalecamy używanie systemu zarządzania pakietami w implementacji referencyjnej AOSP.

Implementacje na urządzeniu:

• [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ŻESZ rozszerzać formatów .apk, Android Manifest, Dalvik bytecode ani RenderScript bytecode w sposób uniemożliwiający ich prawidłowe instalowanie i uruchamianie na innych zgodnych urządzeniach.

• [C-0-4] NIE WOLNO zezwalać aplikacjom innym niż bieżący „instalator” pakietu na automatyczne odinstalowanie aplikacji bez potwierdzenia przez użytkownika, zgodnie z dokumentacją pakietu SDK dla uprawnienia DELETE_PACKAGE. Jedynymi wyjątkami są aplikacja weryfikująca pakiet systemowy, która obsługuje intencję PACKAGE_NEEDS_VERIFICATION, oraz aplikacja menedżera pamięci, która obsługuje intencję ACTION_MANAGE_STORAGE.

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

• [C-0-6] NIE WOLNO instalować pakietów aplikacji z nieznanych źródeł, chyba że aplikacja, która prosi o instalację, spełnia wszystkie te wymagania:

  • Musisz zadeklarować uprawnienie REQUEST_INSTALL_PACKAGES lub ustawić wartość android:targetSdkVersion na 24 lub niższą.
  • Użytkownik musi zezwolić na instalowanie aplikacji z nieznanych źródeł.

• NALEŻY umożliwić użytkownikowi udzielenie/wycofanie uprawnienia do instalowania aplikacji z nieznanych źródeł w przypadku każdej aplikacji, ale MOŻNA zaimplementować to jako no-op i zwrócić RESULT_CANCELED dla startActivityForResult(), jeśli implementacja urządzenia nie chce udostępniać użytkownikom tej opcji. Nawet w takich przypadkach należy jednak poinformować użytkownika, dlaczego nie ma takiej opcji.

• [C-0-7] MUSI wyświetlać użytkownikowi okno z ostrzeżeniem zawierającym ciąg znaków ostrzeżenia udostępniany 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.

• NALEŻY umożliwić użytkownikowi odinstalowanie lub uruchomienie aplikacji w oknie z ostrzeżeniem.

5. Zgodność multimedialna

Implementacje na urządzeniu:

• [C-0-1] MUSI obsługiwać formaty multimediów, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w sekcji 5.1 dla każdego z kodeków zadeklarowanych przez MediaCodecList.
• [C-0-2] NALEŻY zadeklarować i zgłosić obsługę koderów i dekoderów dostępnych dla aplikacji innych firm za pomocą MediaCodecList.
• [C-0-3] MUSI być w stanie prawidłowo dekodować i udostępniać aplikacjom innych firm wszystkie formaty, które może kodować. Obejmuje to wszystkie strumienie bitowe generowane przez jego kodery oraz profile zgłoszone w CamcorderProfile.

Implementacje na urządzeniu:

• NALEŻY dążyć do minimalnego opóźnienia kodeka, innymi słowy:
  • NIE POWINNA zużywać ani przechowywać buforów wejściowych i zwracać buforów wejściowych tylko po przetworzeniu.
  • NIE NALEŻY przechowywać odkodowanych buforów dłużej niż określono w standardzie (np. SPS).
  • NIE POWINIEN przechowywać zakodowanych buforów dłużej niż wymaga tego struktura GOP.

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

Należy pamiętać, że ani Google, ani Open Handset Alliance nie gwarantują, że te kodeki są wolne od patentów innych firm. Osoby, które chcą używać tego kodu źródłowego w urządzeniach lub produktach programowych, powinny wiedzieć, że implementacje tego kodu, w tym w oprogramowaniu open source lub shareware, mogą wymagać licencji na patenty od odpowiednich właścicieli patentów.

5.1. Kodeki multimedialne

5.1.1. Kodowanie dźwięku

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

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

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

Wszystkie kodery audio MUSZĄ obsługiwać:

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

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] MPEG-4 HE AACv2 Profile (ulepszona wersja AAC+)
• [C-1-4] AAC ELD (ulepszona jakość dźwięku AAC z małym opóźnieniem)
• [C-1-11] xHE-AAC (rozszerzony profil HE AAC ISO/IEC 23003-3, który obejmuje podstawowy profil USAC i profil ISO/IEC 23003-4 z kontrolą zakresu dynamiki)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE, w tym formaty audio o wysokiej rozdzielczości do 24 bitów, częstotliwość próbkowania 192 kHz i 8 kanałów. Pamiętaj, że ten wymóg dotyczy tylko dekodowania, a urządzenie może zmniejszać próbkowanie i poziom miksowania podczas odtwarzania.
• [C-1-10] Opus

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

• [C-2-1] Dekodowanie MUSI być wykonywane bez downmixowania (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ć zdefiniowane zgodnie z „Dynamic Range Control (DRC)” w ISO/IEC 14496-3 oraz kluczami DRC android.media.MediaFormat, aby skonfigurować zachowanie dekodera audio związane z zakresem dynamicznym. Klucze AAC DRC zostały wprowadzone w interfejsie API 21 i są to: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_ENCODED_TARGET_LEVEL.
• [SR] Zdecydowanie zalecamy, aby wszystkie dekodery audio AAC spełniały wymagania C-2-1 i C-2-2.

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

• [C-3-1] Metadane dotyczące głośności i DRC muszą być interpretowane i stosowane zgodnie z profilem MPEG-D DRC poziomu 1.
• [C-3-2] Dekoder MUSI działać zgodnie z konfiguracją ustawioną za pomocą tych kluczy android.media.MediaFormat: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_DRC_EFFECT_TYPE.

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

• MOŻE obsługiwać głośność i kontrolę zakresu dynamicznego za pomocą profilu ISO/IEC 23003-4.

Jeśli obsługiwana jest norma ISO/IEC 23003-4 i w dekodowanym strumieniu bitów znajdują się metadane ISO/IEC 23003-4 oraz ISO/IEC 14496-3, wykonaj te czynności:

• W przypadku konfliktu mają pierwszeństwo metadane ISO/IEC 23003-4.

Wszystkie dekodery audio MUSZĄ obsługiwać te formaty wyjściowe:

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

5.1.3. Szczegóły kodeków audio

5.1.4. Kodowanie obrazu

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

Implementacje urządzeń MUSZĄ obsługiwać kodowanie tych typów obrazów:

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

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

• [C-1-1] MUSI zawierać koder HEVC z przyspieszeniem sprzętowym, który obsługuje tryb kontroli szybkości transmisji bitów BITRATE_MODE_CQ, profil HEVCProfileMainStill i rozmiar ramki 512 × 512 pikseli.

5.1.5. Dekodowanie obrazu

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

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

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

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

• [C-1-1] MUSI obsługiwać format wyjściowy 8-bitowy, jeśli aplikacja tego zażąda, na przykład za pomocą konfiguracji ARGB_8888 w android.graphics.Bitmap.

5.1.6. Szczegóły kodeków obrazów

kodery i dekodery obrazów udostępnione za pomocą interfejsu MediaCodec API;

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

• [SR] ZALECAMY obsługę formatu kolorów RGB888 w trybie powierzchni.

• [C-1-3] Musi obsługiwać co najmniej jeden z formatów planarnych lub półpłaskich YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (równoważny COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (równoważny COLOR_FormatYUV420SemiPlanar). Zdecydowanie zalecamy obsługę obu formatów.

5.1.7. Kodeki wideo

• Aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo i usług wideokonferencji, implementacje urządzeń POWINNY używać sprzętowego kodeka VP8, który spełnia wymagania.

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

• [C-1-1] Kodeki wideo MUSZĄ obsługiwać rozmiary buforów bajtów wejścia i wyjścia, które umożliwiają wyświetlanie największej możliwej ramki skompresowanej i nieskompresowanej zgodnie ze standardem i konfiguracją, ale też nie mogą przydzielać zbyt dużo zasobów.

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

• [C-1-3] Kodery i dekodery wideo MUSZĄ obsługiwać co najmniej jeden z formatów kolorów planarnych lub półpłaskich YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (równoważny COLOR_FormatYUV420Planar) lub COLOR_FormatYUV420PackedSemiPlanar (równoważny COLOR_FormatYUV420SemiPlanar). Zdecydowanie zalecamy obsługę obu formatów.

• [SR] Silnie zaleca się, aby kodery i dekodery wideo obsługiwały co najmniej jeden z formatów kolorów płaskich lub półpłaskich YUV420 8:8:8 zoptymalizowanych sprzętowo (YV12, NV12, NV21 lub równoważny format zoptymalizowany przez producenta).

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

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

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

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

• [C-3-1] MUSI obsługiwać okresy odświeżania w zakresie 10–60 ramek i działać prawidłowo w granicach 20% skonfigurowanego okresu odświeżania.

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

• [C-4-1] NALEŻY ustawić domyślnie format kolorów zoptymalizowany pod kątem wyświetlacza sprzętowego, jeśli jest on skonfigurowany za pomocą wyjścia Surface.
• [C-4-2] NALEŻY ustawić domyślnie format kolorów YUV420 8:8:8 zoptymalizowany pod kątem odczytu przez procesor, jeśli nie ma być używane wyjście Surface.

5.1.8. Lista kodeków wideo

5.1.9. Bezpieczeństwo kodeków multimedialnych

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

Android obsługuje OMX, interfejs API do akceleracji multimediów na różnych platformach, a także Codec 2.0, interfejs API do akceleracji multimediów o małym obciążeniu.

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

• [C-1-1] Musi obsługiwać kodeki multimedialne za pomocą interfejsów OMX lub Codec 2.0 (lub obu), tak jak w projekcie Android Open Source Project, oraz nie może wyłączać ani obchodzić zabezpieczeń. Nie oznacza to, że każdy kodek MUSI używać interfejsu OMX lub Codec 2.0, tylko że MUSI być dostępna obsługa co najmniej jednego z tych interfejsów API, a obsługa dostępnych interfejsów API MUSI obejmować zabezpieczenia.
• [C-SR] MOCNO ZALECAMY uwzględnienie obsługi interfejsu Codec 2.0 API.

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

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

Jeśli implementacje na urządzeniu obsługują interfejs Codec 2.0 API, to:

• [C-3-1] W przypadku każdego formatu i typu multimediów (koderek lub dekoder) obsługiwanego przez urządzenie należy DODAWAĆ odpowiedni kodek oprogramowania Codec 2.0 z projektu Android Open Source (jeśli jest dostępny).
• [C-3-2] Kodery 2.0 muszą być umieszczone w procesie kodeka oprogramowania zgodnie z informacjami podanymi w projekcie Android Open Source, aby umożliwić bardziej precyzyjne przyznawanie dostępu do kodeków oprogramowania.
• [C-3-3] Kodeki, których nazwy zaczynają się od „c2.android. MUSI być oparty na kodzie źródłowym Projektu Android Open Source.

5.1.10. Charakterystyka kodeka multimediów

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

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

W szczególności:

• [C-1-2] Kodeki o nazwach zaczynających się od „OMX”. MUSI używać interfejsów API OMX i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa OMX IL.
• [C-1-3] Kodeki o nazwach zaczynających się od „c2”. MUSI używać interfejsu Codec 2.0 API i mieć nazwy zgodne z wytycznymi dotyczącymi nazewnictwa w przypadku Codec 2.0 na Androida.
• [C-1-4] Kodeki o nazwach zaczynających się od „OMX.google.” lub „c2.android.” NIE MOŻE być opisany jako pochodzący od konkretnego dostawcy lub przyspieszony przez sprzęt.
• [C-1-5] Kodeki, które działają w procesie kodeka (dostawcy lub systemu) i mają dostęp do sterowników sprzętowych innych niż przydzielacze i mapery pamięci, NIE MOGĄ być opisane jako oprogramowanie.
• [C-1-6] Kodek, który nie jest dostępny w projekcie Android Open Source lub nie jest oparty na kodzie źródłowym w tym projekcie, MUSI być opisany jako pochodzący od dostawcy.
• [C-1-7] Kodeki, które korzystają z akceleracji sprzętowej, MUSZĄ być opisane jako korzystające z akceleracji sprzętowej.
• [C-1-8] Nazwy kodeków NIE MOGĄ wprowadzać w błąd. Na przykład kodeki o nazwie „decoders” MUSZĄ obsługiwać dekodowanie, a kodeki o nazwie „encoders” MUSZĄ obsługiwać kodowanie. Kodeki o nazwach zawierających formaty multimediów MUSZĄ obsługiwać te formaty.

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

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

• [C-2-2] Kodek wideo, który jest przyspieszony sprzętowo, MUSI publikować informacje o punktach wydajności. Muszą one zawierać wszystkie obsługiwane standardowe punkty danych o wydajności (wymienione w interfejsie API PerformancePoint), chyba że są one objęte innym obsługiwanym standardowym punktem danych.
• Dodatkowo powinni opublikować rozszerzone punkty skuteczności, jeśli obsługują trwałą skuteczność filmu inną niż standardowa wymieniona w tabeli.

5.2. Kodowanie wideo

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

• W 2 przesuwających się oknach nie powinien przekraczać o więcej niż 15% przepływności danych między interwałami klatek wewnątrzramkowych (I-frame).
• NIE POWINNA przekraczać 100% szybkości transmisji danych w przesuwalnym oknie liczonym w sekundach.

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

• [C-1-1] Musisz uwzględnić obsługę co najmniej jednego z enkoderów wideo VP8 lub H.264 i uzyskać dostęp do aplikacji innych firm.
• NALEŻY obsługiwać kodery wideo VP8 i H.264 oraz udostępniać je aplikacjom innych firm.

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

• [C-2-1] Musi obsługiwać dynamicznie konfigurowalne szybkości transmisji danych.
• NALEŻY obsługiwać zmienne liczby klatek, przy czym koder wideo NALEŻY określać chwilowy czas trwania klatki na podstawie sygnałów czasowych buforów wejściowych i przydzielać zasobnik bitów na podstawie tego czasu trwania klatki.

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

• Powinien obsługiwać dynamicznie konfigurowalne bitrate’y dla obsługiwanego kodera.

Jeśli implementacje urządzeń zapewniają kodery wideo lub obrazów z przyspieszeniem sprzętowym i obsługują co najmniej 1 dołączoną lub podłączaną kamerę sprzętową udostępnioną przez interfejsy API android.camera:

• [C-4-1] Wszystkie kodery wideo i obrazu z akseleracją sprzętową MUSZĄ obsługiwać kodowanie klatek z kamery sprzętowej.
• NALEŻY obsługiwać kodowanie klatek z kamer sprzętowych za pomocą wszystkich koderów wideo lub obrazu.

5.2.1. H.263

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

• [C-1-1] Musi obsługiwać profil podstawowy na poziomie 45.
• Powinien obsługiwać dynamicznie konfigurowalne bitrate’y dla obsługiwanego kodera.

5.2.2. H.264

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

• [C-1-1] Musi obsługiwać profil podstawowy poziomu 3. Obsługa ASO (dowolne sortowanie segmentów), FMO (elastyczne sortowanie makrobloków) i RS (nadmiarowe segmenty) jest jednak opcjonalna. Ponadto, aby zachować zgodność z innymi urządzeniami z Androidem, zalecamy, aby kodery nie używały funkcji ASO, FMO i RS w przypadku profilu podstawowego.
• [C-1-2] MUSI obsługiwać profile kodowania wideo SD (standardowa rozdzielczość) podane w tabeli poniżej.
• Powinien obsługiwać poziom profilu głównego 4.
• Powinien obsługiwać profile kodowania filmów HD (High Definition) zgodnie z tabelą poniżej.

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

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

5.2.3. VP8

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

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

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

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

5.2.4. VP9

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

• [C-1-2] Musi obsługiwać profil 0 na poziomie 3.
• [C-1-1] MUSI obsługiwać zapisywanie plików WebM w formacie Matroska.
• [C-1-3] MUSI generować dane CodecPrivate.
• NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• [SR] MOCNO zaleca się obsługę profili dekodowania HD, jak wskazano w tabeli poniżej, jeśli istnieje koder sprzętowy.

Jeśli implementacje na urządzeniu twierdzą, że obsługują profil 2 lub profil 3 za pomocą interfejsów Media API:

• Obsługa formatu 12-bitowego jest OPCJONALNA.

5.2.5. H.265

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

• [C-1-1] Musi obsługiwać profil główny na poziomie 3.
• NALEŻY obsługiwać profile kodowania HD zgodnie z tabelą poniżej.
• [SR] MOCNO ZALECAMY obsługę profili kodowania HD, jak wskazano w tabeli poniżej, jeśli istnieje koder sprzętowy.

5.3. Dekodowanie wideo

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

• [C-1-1] MUSI obsługiwać dynamiczne przełączanie rozdzielczości wideo i szybkości klatek za pomocą standardowych interfejsów API Androida w ramach tego samego strumienia dla wszystkich kodeków VP8, VP9, H.264 i H.265 w czasie rzeczywistym oraz do maksymalnej rozdzielczości obsługiwanej przez każdy z kodeków na urządzeniu.

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

• [C-1-1] Musi obsługiwać poziom profilu podstawowego 30 i 45.

5.3.3. MPEG-4

W przypadku implementacji dekoderów MPEG-4 na urządzeniach:

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

5.3.4. H.264

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

• [C-1-1] Musi obsługiwać profil główny na poziomie 3.1 i profil podstawowy. Obsługa ASO (dowolne sortowanie segmentów), FMO (elastyczne sortowanie makrobloków) i RS (niepotrzebne segmenty) jest OPCJONALNA.
• [C-1-2] MUSI być w stanie dekodować filmy z profilami SD (standardowej rozdzielczości) wymienionymi w poniższej tabeli i zakodowanymi za pomocą profilu podstawowego i profilu głównego poziomu 3.1 (w tym 720p30).
• POWINIEN być w stanie dekodować filmy z profilami HD (High Definition) zgodnie z tabelą poniżej.

Jeśli wysokość zwracana przez metodę Display.getSupportedModes() jest równa lub większa niż rozdzielczość filmu, implementacje urządzeń:

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

5.3.5. H.265 (HEVC)

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

• [C-1-1] MUSI obsługiwać poziom główny profilu głównego na poziomie 3 oraz profile dekodowania wideo SD zgodnie z tabelą poniżej.
• NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• [C-1-2] W przypadku dekodera sprzętowego MUSI obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.

Jeśli wysokość zwracana przez metodę Display.getSupportedModes() jest równa lub większa niż rozdzielczość filmu, wtedy:

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

Jeśli implementacje urządzeń twierdzą, że obsługują profil HDR (HEVCProfileMain10HDR10, HEVCProfileMain10HDR10Plus) za pomocą interfejsów Media API:

• [C-3-1] Implementacje urządzeń MUSZĄ akceptować wymagane metadane HDR (MediaFormat#KEY_HDR_STATIC_INFO dla wszystkich profili HDR) z aplikacji korzystającej z interfejsu MediaCodec API, a także obsługiwać wyodrębnianie wymaganych metadanych HDR (MediaFormat#KEY_HDR_STATIC_INFO dla wszystkich profili HDR, a także MediaFormat#KEY_HDR10_PLUS_INFO dla profili HDR10Plus) z bitowego strumienia danych lub kontenera zgodnie z odpowiednimi specyfikacjami. Muszą one również obsługiwać wyjście wymaganych metadanych HDR (MediaFormat#KEY_HDR_STATIC_INFO dla wszystkich profili HDR) z bitstremu lub kontenera zgodnie z odpowiednimi specyfikacjami.

• [C-SR] W implementacjach urządzeń MOCNO zaleca się obsługę danych metadanych MediaFormat#KEY_HDR10_PLUS_INFO w przypadku profili HDR10 Plus za pomocą metody MediaCodec#getOutputFormat(int).

• [C-3-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR dla profilu HEVCProfileMain10HDR10 na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).

• [C-SR] W przypadku implementacji urządzeń ZALECAMY, aby poprawnie wyświetlać treści HDR dla profilu HEVCProfileMain10HDR10Plus na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).

5.3.6. VP8

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

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

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

• [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać profile 720p wymienione w tabeli poniżej.
• [C-2-2] Implementacje urządzeń MUSZĄ obsługiwać profile 1080p podane w tabeli poniżej.

5.3.7. VP9

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

• [C-1-1] MUSI obsługiwać profile dekodowania filmów SD zgodnie z tabelą poniżej.
• NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.

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

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

Jeśli wysokość zwracana przez metodę Display.getSupportedModes() jest równa lub większa niż rozdzielczość filmu, wtedy:

• [C-3-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden z formatów VP9 lub H.265 w przypadku dekodowania profili 720, 1080 i UHD.

Jeśli implementacje urządzeń obsługują VP9Profile2 lub VP9Profile3 za pomocą interfejsów API mediów CodecProfileLevel:

• Obsługa formatu 12-bitowego jest OPCJONALNA.

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

• [C-4-1] Implementacje urządzeń MUSZĄ akceptować wymagane metadane HDR (MediaFormat#KEY_HDR_STATIC_INFO w przypadku wszystkich profili HDR oraz parametr MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO w przypadku profili HDR10Plus) z aplikacji korzystającej z interfejsu MediaCodec API, a także obsługiwać wyodrębnianie wymaganych metadanych HDR (MediaFormat#KEY_HDR_STATIC_INFO w przypadku wszystkich profili HDR oraz parametr MediaFormat#KEY_HDR10_PLUS_INFO w przypadku profili HDR10Plus) z bitowego strumienia danych lub kontenera zgodnie z odpowiednimi specyfikacjami. Muszą one też obsługiwać wyjście wymaganych metadanych HDR (MediaFormat#KEY_HDR_STATIC_INFO dla wszystkich profili HDR) z bitstremu lub kontenera zgodnie z odpowiednimi specyfikacjami.

• [C-4-2] Implementacje urządzeń MUSZĄ prawidłowo wyświetlać treści HDR dla profili VP9Profile2HDR i VP9Profile3HDR na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).

• [C-SR] W przypadku implementacji urządzeń MOCNO zaleca się obsługę zapisywania metadanych MediaFormat#KEY_HDR10_PLUS_INFO dla profili HDR10Plus za pomocą MediaCodec#getOutputFormat(int).

• [C-SR] W przypadku implementacji urządzeń MOCNO zaleca się prawidłowe wyświetlanie treści HDR dla profili VP9Profile2HDR10Plus i VP9Profile3HDR10Plus na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).

5.3.8. Dolby Vision

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

• [C-1-1] MUSISZ podać narzędzie do wyodrębniania obsługujące Dolby Vision.
• [C-1-2] NALEŻY prawidłowo wyświetlać treści Dolby Vision na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).
• [C-1-3] NALEŻY ustawić indeks ścieżki warstw zgodnych z wersjami starszymi (jeśli występują) tak, aby był taki sam jak indeks ścieżki połączonej warstwy Dolby Vision.

5.3.9. AV1

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

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

5.4. Nagrywanie dźwięku

Chociaż niektóre wymagania opisane w tej sekcji są od wersji 4.3 Androida oznaczone jako „NALEŻY”, w definicji zgodności w przyszłych wersjach zostaną one zmienione na „NALEŻY”. Zalecamy, aby istniejące i nowe urządzenia z Androidem spełniały te wymagania (oznaczone jako „NALEŻY”), ponieważ w przeciwnym razie nie będą zgodne z Androidem po aktualizacji do przyszłej wersji.

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

Jeśli implementacje na urządzeniu deklarują android.hardware.microphone, to:

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

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

• NALEŻY zezwolić na rejestrowanie surowych treści audio o tych cechach:

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

• [C-1-2] NALEŻY nagrywać z częstotliwością próbkowania wyższą niż 48 kHz bez próbkowania w górę.

• [C-1-3] NALEŻY użyć odpowiedniego filtra antyaliasingu, gdy częstotliwości próbkowania podane powyżej są rejestrowane z obniżeniem próbkowania.

• POWINNA umożliwiać rejestrowanie surowych treści audio w jakości radia AM i DVD, co oznacza te cechy:

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

• [C-1-4] MUSI obsługiwać interfejs API MicrophoneInfo i odpowiednio wypełniać informacje o dostępnych mikrofonach na urządzeniu dostępnych dla aplikacji innych firm za pomocą interfejsu API AudioManager.getMicrophones() oraz o obecnie aktywnych mikrofonach dostępnych dla aplikacji innych firm za pomocą interfejsów API AudioRecord.getActiveMicrophones() i MediaRecorder.getActiveMicrophones(). Jeśli implementacje urządzeń umożliwiają przechwytywanie nieprzetworzonych treści audio w jakości radia AM i DVD, mogą:

• [C-2-1] NALEŻY rejestrować bez próbkowania w górę w dowolnym formacie wyższym niż 16000:22050 lub 44100:48000.

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

5.4.2. Przechwytywanie danych do rozpoznawania głosu

Jeśli implementacje na urządzeniu deklarują android.hardware.microphone, to:

• [C-1-1] NALEŻY zarejestrować źródło dźwięku android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION z częstotliwością próbkowania 44 100 lub 48 000.
• [C-1-2] Domyślnie musisz wyłączyć wszelkie przetwarzanie dźwięku w celu redukcji szumów podczas nagrywania strumienia audio ze źródła audio AudioSource.VOICE_RECOGNITION.
• [C-1-3] Domyślnie należy wyłączyć automatyczne sterowanie wzmocnieniem podczas nagrywania strumienia audio ze źródła audio AudioSource.VOICE_RECOGNITION.
• NALEŻY nagrywać strumień audio do rozpoznawania głosu z około płaską charakterystyką amplitudy w zależności od częstotliwości: konkretnie ±3 dB w zakresie 100–4000 Hz.
• NALEŻY nagrywać strumień audio do rozpoznawania głosu z ustawieniami czułości wejścia takimi, aby źródło o poziomie mocy dźwięku (SPL) 90 dB przy 1000 Hz dawało wartość RMS 2500 dla próbek 16-bitowych.
• NALEŻY nagrywać strumień audio do rozpoznawania mowy w taki sposób, aby poziomy amplitudy PCM śledziły liniowo zmiany SPL wejścia w zakresie co najmniej 30 dB od -18 dB do +12 dB w skali 90 dB SPL na mikrofonie.
• NALEŻY nagrywać strumień audio do rozpoznawania głosu z całkowitym zniekształceniem harmonicznym (THD) mniejszym niż 1% dla 1 kHz przy poziomie wejściowym 90 dB SPL na mikrofonie.

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

• [C-2-1] NALEŻY umożliwić sterowanie tym efektem dźwiękowym za pomocą interfejsu API android.media.audiofx.NoiseSuppressor.
• [C-2-2] Identyfikuj jednoznacznie każdą implementację technologii redukcji szumów za pomocą pola AudioEffect.Descriptor.uuid.

5.4.3. Przechwytywanie w celu przekierowania odtwarzania

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

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

• [C-1-1] NALEŻY prawidłowo zaimplementować źródło dźwięku REMOTE_SUBMIX, aby aplikacja korzystająca z interfejsu API android.media.AudioRecord do nagrywania z tego źródła dźwięku rejestrowała miks wszystkich strumieni audio, z wyjątkiem:

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

5.4.4. Usuwanie echa akustycznego

Jeśli implementacje na urządzeniu deklarują android.hardware.microphone, to:

• NALEŻY wdrożyć technologię usuwania echa akustycznego (AEC) dostosowaną do komunikacji głosowej i zastosowaną do ścieżki przechwytywania podczas przechwytywania za pomocą AudioSource.VOICE_COMMUNICATION

Jeśli implementacje na urządzeniach zapewniają funkcję usuwania echa, która jest wstawiana na ścieżce przechwytywania dźwięku, gdy wybrana jest opcja AudioSource.VOICE_COMMUNICATION, to:

• [C-SR] MOCNO_ZALECANA deklaracja za pomocą metody interfejsu API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
• [C-SR] MOCNO_ZALECANA możliwość sterowania tym efektem dźwiękowym za pomocą interfejsu API AcousticEchoCanceler.
• [C-SR] ZALECAMY jednoznaczne identyfikowanie każdej implementacji technologii AEC za pomocą pola AudioEffect.Descriptor.uuid.

5.4.5. Jednoczesne nagrywanie

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

• [C-1-1] Musisz zezwolić na jednoczesny dostęp do mikrofonu przez usługę ułatwień dostępu, która rejestruje dane za pomocą funkcji AudioSource.VOICE_RECOGNITION, oraz co najmniej 1 aplikacji, która rejestruje dane za pomocą dowolnej funkcji AudioSource.
• [C-1-2] MUSI zezwalać na jednoczesny dostęp do mikrofonu przez wstępnie zainstalowaną aplikację, która pełni rolę Asystenta, oraz co najmniej jedną aplikację, która rejestruje dźwięk za pomocą dowolnego AudioSource, z wyjątkiem AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER.
• [C-1-3] Podczas nagrywania dźwięku za pomocą funkcji AudioSource.VOICE_COMMUNICATION lub AudioSource.CAMCORDER aplikacja MUSI wyciszyć dźwięk w innych aplikacjach (z wyjątkiem aplikacji ułatwień dostępu). Jeśli jednak aplikacja rejestruje dane za pomocą AudioSource.VOICE_COMMUNICATION, inna aplikacja może rejestrować rozmowę głosową, jeśli jest to uprzywilejowana (zainstalowana fabrycznie) aplikacja z uprawnieniami CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Jeśli 2 lub więcej aplikacji nagrywa jednocześnie i żadna z nich nie ma interfejsu na górze, dźwięk jest przesyłany z aplikacji, która rozpoczęła nagrywanie jako ostatnia.

5.4.6. Poziomy wzmocnienia mikrofonu

Jeśli implementacje na urządzeniu deklarują android.hardware.microphone, to:

• POWINNY wykazywać w zakresie średnich częstotliwości w przybliżeniu płaskie charakterystyki amplitudy w funkcji częstotliwości: konkretnie ±3 dB w zakresie 100–4000 Hz dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania głosu.
• NALEŻY ustawić czułość wejścia audio tak, aby sygnał sinusoidalny o częstotliwości 1000 Hz odtwarzany z poziomem ciśnienia akustycznego (SPL) 90 dB dawał odpowiedź z wartością RMS 2500 dla próbek 16-bitowych (lub -22,35 dB w zakresie pełnej skali dla próbek z pływającą kropką/podwójną precyzją) dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania mowy.
• [C-SR] ZALECAMY, aby poziomy amplitudy w zakresie niskich częstotliwości wynosiły ±20 dB w zakresie 5–100 Hz w porównaniu z zakresem średnich częstotliwości w przypadku każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania mowy.
• [C-SR] ZALECAMY, aby poziomy amplitudy w zakresie wysokich częstotliwości wynosiły ±30 dB w zakresie od 4000 Hz do 22 kHz w porównaniu z zakresem średnich częstotliwości dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania głosu.

5.5. Odtwarzanie dźwięku

Android obsługuje odtwarzanie dźwięku przez peryferyjne wyjście audio zgodnie z opisem w sekcji 7.8.2.

5.5.1. Odtwarzanie dźwięku w postaci surowych danych

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

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

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

• NALEŻY zezwolić na odtwarzanie surowych treści audio o tych cechach:

  • Częstotliwości próbkowania: 24 000

5.5.2. Efekty dźwiękowe

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

Jeśli implementacje na urządzeniach deklarują funkcję android.hardware.audio.output, muszą:

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

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

Implementacje na urządzeniach samochodowych:

• NALEŻY umożliwić dostosowywanie głośności dźwięku osobno dla każdego strumienia audio, korzystając z typu treści lub użycia określonego przez AudioAttributes oraz użycia dźwięku w samochodzie określonego publicznie w android.car.CarAudioManager.

5.6. Opóźnienie dźwięku

Opóźnienie dźwięku to czas opóźnienia sygnału dźwiękowego w systemie. Wiele rodzajów aplikacji wymaga niskich opóźnień, aby uzyskać efekty dźwiękowe w czasie rzeczywistym.

W rozumieniu tego punktu stosuje się następujące definicje:

• opóźnienie wyjścia. Interval między zapisaniem przez aplikację ramki danych zakodowanych w formacie PCM a momentem, w którym odpowiedni dźwięk jest prezentowany otoczeniu przez przetwornik na urządzeniu lub sygnał opuszcza urządzenie przez port i może być obserwowany z zewnątrz.
• opóźnienie zimnego wyjścia. Opóźnienie wyjścia dla pierwszego obrazu, gdy system wyjścia audio był nieaktywny i wyłączony przed żądaniem.
• ciągły czas oczekiwania na wyjście. Opóźnienie wyjściowe kolejnych klatek po rozpoczęciu odtwarzania dźwięku przez urządzenie.
• opóźnienie reakcji. Interval between when a sound is presented by environment to device at an on-device transducer or signal enters the device via a port and when an application reads the corresponding frame of PCM-coded data.
• utracił(a) dane wejściowe. Początkowa część sygnału wejściowego, która jest nieprzydatna lub niedostępna.
• Opóźnienie w przypadku zimnego wejścia. Suma utraconego czasu wprowadzania danych i opóźnienia wprowadzania danych dla pierwszej klatki, gdy system wprowadzania danych audio był nieaktywny i wyłączony przed żądaniem.
• ciągłe opóźnienie wejścia. Opóźnienie wejścia w przypadku kolejnych klatek podczas rejestrowania dźwięku przez urządzenie.
• tylko w przypadku jittera na wyjściu. zmienność między poszczególnymi pomiarami wartości opóźnienia wyjścia bez uczenia
• Jitter na zimnym wejściu. zmienność między poszczególnymi pomiarami wartości opóźnienia zimnego wejścia;
• ciągłe opóźnienie w obie strony. Suma opóźnienia ciągłego wejścia i opóźnienia ciągłego wyjścia oraz jeden okres buforowania. Okres buforowania daje aplikacji czas na przetworzenie sygnału i zmniejszenie różnicy fazy między strumieniami wejściowym i wyjściowym.
• OpenSL ES PCM buffer queue API. Zestaw interfejsów API OpenSL ES związanych z PCM w Android NDK.
• AAudio – natywny interfejs API do obsługi dźwięku. Zestaw interfejsów AAudio w ramach Android NDK.
• sygnatura czasowa. Para składająca się z względnej pozycji klatki w strumieniach i szacowanego czasu, w którym dana klatka wchodzi do potoku przetwarzania dźwięku lub z niego wychodzi na powiązanym urządzeniu końcowym. Zobacz też AudioTimestamp.
• glitch. Tymczasowe przerwanie lub nieprawidłowa wartość próbki w sygnale audio, zwykle spowodowane niedostatecznym wypełnieniem bufora w przypadku danych wyjściowych, przepełnieniem bufora w przypadku danych wejściowych lub jakimkolwiek innym źródłem szumu cyfrowego lub analogowego.

Jeśli implementacje na urządzeniu deklarują android.hardware.audio.output, muszą spełniać te wymagania:

• [C-1-1] Sygnatura czasowa zwracana przez AudioTrack.getTimestamp i AAudioStream_getTimestamp jest dokładna do +/- 2 ms.
• [C-1-2] Opóźnienie wyjściowe na zimno nie większe niż 500 ms.

Jeśli implementacje na urządzeniach deklarują android.hardware.audio.output, to MOCNO zalecamy, aby spełniały te wymagania lub je przekraczały:

• [C-SR] Opóźnienie wyjściowe na zimno nie większe niż 100 ms. BARDZO ZALECAMY, aby istniejące i nowe urządzenia z tą wersją Androida spełniały te wymagania. W przyszłej wersji platformy w 2021 r. wymagamy, aby opóźnienie wyjściowe w przypadku zimnego uruchomienia nie przekraczało 200 ms.
• [C-SR] Ciągłe opóźnienie wyjściowe nie większe niż 45 ms.
• [C-SR] Zminimalizuj jitter w przypadku zimnego uruchomienia.
• [C-SR] Sygnatura czasowa wyjściowa zwracana przez AudioTrack.getTimestamp i AAudioStream_getTimestamp jest dokładna do +/- 1 ms.

Jeśli implementacje urządzeń spełniają powyższe wymagania, po początkowej kalibracji, przy użyciu kolejki buforów OpenSL ES PCM i natywnych interfejsów API AAudio, opóźnienie ciągłego wyjścia i opóźnienie wyjścia po zimnym uruchomieniu na co najmniej 1 obsługiwanym urządzeniu z wyjściami audio wynosi:

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

Jeśli implementacje na urządzeniach nie spełniają wymagań dotyczących niskiej latencji dźwięku za pomocą kolejki buforów OpenSL ES PCM i natywnego interfejsu API AAudio, nie spełniają też tych wymagań:

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

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

• [C-3-1] Ogranicz błąd w sygnaturach czasowych wejścia zwracanych przez funkcję AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/- 2 ms. „Błąd” oznacza tu odchylenie od prawidłowej wartości.
• [C-3-2] Opóźnienie w przypadku zimnego uruchomienia nie większe niż 500 ms.

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

• [C-SR] Opóźnienie wejścia „na zimno” nie większe niż 100 ms. BARDZO ZALECAMY, aby istniejące i nowe urządzenia z tą wersją Androida spełniały te wymagania. W przyszłej wersji platformy w 2021 r. wymagamy, aby opóźnienie w przypadku zimnego wejścia nie przekraczało 200 ms.
• [C-SR] Ciągłe opóźnienie wejścia nieprzekraczające 30 ms.
• [C-SR] Ciągłe opóźnienie w obie strony nie większe niż 50 ms.
• [C-SR] Zminimalizuj jitter w przypadku zimnego wejścia.
• [C-SR] Ogranicz błąd w sygnaturach czasowych wejścia zwracanych przez AudioRecord.getTimestamp lub AAudioStream_getTimestamp do +/- 1 ms.

5.7. Protokoły sieciowe

Implementacje na urządzeniach MUSZĄ obsługiwać protokoły sieci multimedialnej do odtwarzania dźwięku i obrazu zgodnie z dokumentacją pakietu Android SDK.

Jeśli implementacje na urządzeniach obejmują dekoder audio lub wideo, muszą:

• [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 multimediów podane w tabeli Formaty segmentów multimediów poniżej w ramach protokołu HTTP Live Streaming w wersji 7.

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

Formaty segmentów multimediów

RTSP (RTP, SDP)

5.8. Secure Media

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

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

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

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

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

• [C-3-1] W przypadku wszystkich zewnętrznych wyświetlaczy podłączonych przez port przewodowy dostępny dla użytkownika MUSI być obsługiwana technologia HDCP 1.2 lub nowsza.

5.9. MusicaI Instrument Digital Interface (MIDI)

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

• [C-1-1] MUSI obsługiwać MIDI przez wszystkie urządzenia transportowe z obsługą MIDI, dla których zapewniają one ogólne połączenia nie-MIDI. Takie urządzenia transportowe:

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

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

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

5.10. Profesjonalny dźwięk

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

• [C-1-1] MUST report support for feature android.hardware.audio.low_latency.
• [C-1-2] MUSI mieć ciągłe opóźnienie dźwięku w obie strony, zgodnie z definicją w sekcji 5.6 Opóźnienie dźwięku, nieprzekraczające 20 ms, a na co najmniej jednej obsługiwanej ścieżce nieprzekraczające 10 ms.
• [C-1-3] Musi zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
• [C-1-4] MUST report support for feature android.software.midi.
• [C-1-5] Musi spełniać wymagania dotyczące opóźnień i dźwięku USB, korzystając z interfejsu sterującego kolejką bufora OpenSL ES PCM oraz co najmniej jednej ścieżki interfejsu sterującego dźwiękiem AAudio.
• [SR] ZALECAMY stosowanie interfejsu API AAudio native audio, aby spełnić wymagania dotyczące opóźnień i dźwięku USB, zamiast korzystania z ścieżki MMAP.
• [C-1-6] Czas opóźnienia na wyjściu z urządzenia w trybie zimnym musi wynosić 200 ms lub mniej.
• [C-1-7] Opóźnienie w przypadku zimnego wejścia nie może przekraczać 200 ms.
• [SR] MOCNO ZALECANA jest zapewnienie stałego poziomu wydajności procesora, gdy dźwięk jest aktywny, a obciążenie procesora się zmienia. Należy to przetestować, używając wersji aplikacji na Androida z identyfikatorem zatwierdzenia SynthMark 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark używa syntezatora programowego działającego na symulowanym środowisku audio, które mierzy wydajność systemu. Aplikację SynthMark należy uruchomić, korzystając z opcji „Automatyczny test”, i uzyskać następujące wyniki:
  • voicemark.90 > 32 głosów
  • latencymark.fixed.little <= 15 ms
  • latencymark.dynamic.little <= 50 ms

Więcej informacji o benchmarkach znajdziesz w dokumentacji SynthMark.

• NALEŻY zminimalizować niedokładność zegara audio i jego odchylenia w stosunku do czasu standardowego.
• NALEŻY zminimalizować przesunięcie zegara audio względem procesora CLOCK_MONOTONIC, gdy oba są aktywne.
• NALEŻY zminimalizować opóźnienie dźwięku na przetwornikach na urządzeniu.
• NALEŻY zminimalizować opóźnienie dźwięku w przypadku dźwięku cyfrowego przez USB.
• NALEŻY udokumentować pomiary opóźnienia dźwięku na wszystkich ścieżkach.
• NALEŻY zminimalizować jitter w czasie wywołania zwrotnego zakończenia bufora audio, ponieważ wpływa to na użyteczny procent pełnej przepustowości procesora w wywołaniu zwrotnym.
• W przypadku normalnego użytkowania przy zgłoszonym opóźnieniu nie powinno być żadnych zakłóceń dźwięku.
• NALEŻY zapewnić zerową różnicę opóźnień między kanałami.
• NALEŻY zminimalizować średni czas oczekiwania MIDI w przypadku wszystkich transportów.
• NALEŻY zminimalizować zmienność opóźnienia MIDI pod obciążeniem (jitter) we wszystkich transporcie.
• NALEŻY podać dokładne sygnatury czasowe MIDI w przypadku wszystkich transportów.
• NALEŻY zminimalizować szum sygnału audio na przetwornikach na urządzeniu, w tym w okresie bezpośrednio po uruchomieniu „na zimno”.
• NALEŻY zapewnić zerową różnicę zegara audio między stroną wejścia i wyjścia 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.
• NALEŻY obsłużyć wywołania zwrotne zakończenia buforowania dźwięku po stronie wejścia i wyjścia odpowiednich punktów końcowych w tym samym wątku, gdy oba są aktywne, oraz wejść w wywołanie zwrotne wyjścia bezpośrednio po powrocie z wywołania zwrotnego wejścia. Jeśli nie można obsłużyć wywołań zwrotnych w tym samym wątku, wpisz wywołanie zwrotne wyjścia tuż po wywołaniu zwrotnym wejścia, aby umożliwić aplikacji spójne ustalanie czasu po stronie wejścia i wyjścia.
• NALEŻY zminimalizować różnicę fazową między buforowaniem dźwięku HAL po stronie wejścia i wyjścia odpowiednich punktów końcowych.
• NALEŻY zminimalizować opóźnienie dotyku.
• NALEŻY zminimalizować zmienność opóźnienia dotyku pod obciążeniem (jitter).
• Opóźnienie od dotknięcia do wyjścia dźwiękowego nie powinno przekraczać 40 ms.

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

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

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

• [C-2-1] Opóźnienie dźwięku w obie strony nie może przekraczać 20 ms na wyjściu audio.
• [SR] ZALECAMY stosowanie się do sekcji Specyfikacja urządzeń mobilnych (gniazdo) w specyfikacji przewodowych zestawów słuchawkowych (w wersji 1.1).
• Ciągłe opóźnienie w obie strony w przypadku gniazda audio nie powinno przekraczać 10 ms.

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

• [C-3-1] Musisz zaimplementować klasę audio USB.
• [C-3-2] Urządzenie MUSI mieć ciągłe opóźnienie dźwięku w obie strony nieprzekraczające 20 ms w porcie w trybie hosta USB przy użyciu klasy audio USB.
• Ciągłe opóźnienie w obie strony nie powinno przekraczać 10 ms w przypadku portu w trybie hosta USB przy użyciu klasy audio USB.
• [C-SR] Zaleca się, aby podczas korzystania z urządzeń peryferyjnych USB obsługujących te wymagania urządzenie obsługiwało jednocześnie do 8 kanałów wejściowych i wyjściowych, częstotliwość próbkowania 96 kHz oraz głębię 24- lub 32-bitową.

Jeśli implementacje urządzeń zawierają port HDMI, muszą:

• W co najmniej jednej konfiguracji MUSI obsługiwać wyjście stereo i 8 kanałów z głębią bitową 20- lub 24-bitową i częstotliwością 192 kHz bez utraty głębi bitowej ani próbkowania.

5.11. Rejestrowanie nieprzetworzonych

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

Jeśli implementacje urządzeń mają obsługiwać nieprzetworzone źródło dźwięku i udzielać do niego dostępu aplikacjom innych firm, muszą:

• [C-1-1] Właściwość android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED MUSI raportować obsługę.

• [C-1-2] W zakresie średnich częstotliwości muszą występować w przybliżeniu płaskie charakterystyki amplitudy w funkcji częstotliwości: dokładnie ±10 dB od 100 Hz do 7000 Hz w przypadku każdego mikrofonu użytego do nagrywania nieprzetworzonego źródła dźwięku.

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

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

• [C-1-5] NALEŻY ustawić czułość wejścia audio tak, aby sygnał sinusoidalny o częstotliwości 1000 Hz odtwarzany z poziomem ciśnienia akustycznego (SPL) wynoszącym 94 dB dawał odpowiedź z wartością RMS wynoszącą 520 dB dla próbek 16-bitowych (lub -36 dB w skali pełnej dla próbek z dokładnością zmiennoprzecinkową/podwójną) dla każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku.

• [C-1-6] W przypadku każdego mikrofonu używanego do nagrywania nieprzetworzonego źródła dźwięku MUSI występować stosunek sygnału do szumu (SNR) wynoszący 60 dB lub więcej. (gdzie SNR jest mierzony jako różnica między 94 dB SPL a ekwiwalent SPL własnego szumu, z wagami A).

• [C-1-7] Łączne zniekształcenie harmoniczne (THD) musi być mniejsze niż 1% przy 1 kHz przy poziomie wejściowym 90 dB SPL 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 czy eliminacji echa) na ścieżce, oprócz mnożnika poziomu, który ma doprowadzić poziom do pożądanego zakresu. Krótko mówiąc:

• [C-1-8] Jeśli architektura z jakiegokolwiek powodu zawiera przetwarzanie sygnału, należy je wyłączyć i wprowadzić zerowe opóźnienie lub dodatkowe opóźnienie na ścieżce sygnału.
• [C-1-9] Pomnóżnik poziomu, mimo że może się znajdować na ścieżce, NIE MOŻE powodować opóźnień na ścieżce sygnału.

Wszystkie pomiary SPL są wykonywane bezpośrednio przy mikrofonie, który jest testowany. W przypadku wielu konfiguracji mikrofonów te wymagania mają zastosowanie do każdego mikrofonu.

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

• [C-2-1] W przypadku metody interfejsu API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) musisz zwrócić wartość null, aby prawidłowo wskazać brak obsługi.
• [SR] nadal MOCNO zaleca się, aby spełniały jak najwięcej wymagań dotyczących ścieżki sygnału dla nieprzetworzonego źródła nagrania.

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

6.1. Narzędzia dla programistów

Implementacje na urządzeniu:

• [C-0-1] Musi obsługiwać narzędzia dla deweloperów Androida udostępniane w pakiecie Android SDK.

• Android Debug Bridge (adb)

  • [C-0-2] MUSI obsługiwać adb zgodnie z dokumentacją do pakietu Android SDK i komendy powłoki dostępne w AOSP, których mogą używać deweloperzy aplikacji, w tym dumpsys cmd stats
  • [C-SR] ZDECYDOWANIE ZALECAMY obsługę polecenia powłoki cmd testharness.
  • [C-0-3] Nie wolno zmieniać formatu ani zawartości zdarzeń systemowych urządzenia (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) zarejestrowanych za pomocą polecenia dumpsys.
  • [C-0-10] NALEŻY rejestrować bez pomijania i uzyskiwać dostęp do tych zdarzeń, aby były dostępne dla polecenia cmd stats w powłoce i klasy interfejsu API StatsManager System.
    • 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] Domyślnie demon adb na urządzeniu MUSI być nieaktywny i MUSI istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie Android Debug Bridge.
  • [C-0-5] Musi obsługiwać bezpieczny interfejs ADB. Android obsługuje bezpieczne połączenia ADB. Bezpieczny adb włącza adb na znanych uwierzytelnionych hostach.

  • [C-0-6] MUSI zawierać mechanizm umożliwiający połączenie adb z maszyny hosta. Przykład:

    • W przypadku urządzeń bez portu USB obsługującego tryb peryferyjny należy zaimplementować adb za pomocą sieci lokalnej (np. Ethernet lub Wi-Fi).
    • Musisz udostępnić sterowniki dla Windowsa 7, 9 i 10, aby umożliwić deweloperom nawiązywanie połączenia z urządzeniem za pomocą protokołu ADB.

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] Musi obsługiwać wszystkie funkcje DMS zgodnie z dokumentacją pakietu Android SDK. Ponieważ ddms używa adb, obsługa ddms powinna być domyślnie nieaktywna, ale MUSI być obsługiwana, gdy użytkownik aktywuje Android Debug Bridge (ADB), jak opisano powyżej.
• Monkey
  • [C-0-8] Musisz uwzględnić platformę Monkey i uzyskać do niej dostęp w aplikacji.
• SysTrace
  • [C-0-9] Musi obsługiwać narzędzie systrace zgodnie z dokumentacją w pakiecie Android SDK. Systrace MUSI być domyślnie nieaktywny i MUSI istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie Systrace.

• Perfetto

  • [C-SR] Zdecydowanie zalecamy udostępnienie użytkownikowi powłoki binarnego pliku /system/bin/perfetto, którego wiersz poleceń jest zgodny z dokumentacją perfetto.
  • [C-SR] Zalecamy, aby binarny pakiet perfetto przyjmował jako dane wejściowe konfigurację protobuf zgodną ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR] Zalecamy, aby binarny plik perfetto zapisywał jako dane wyjściowe ślad protobuf zgodny ze schematem zdefiniowanym w dokumentacji perfetto.
  • [C-SR] NALEŻY podać w pliku binarnym perfetto co najmniej źródła danych opisane w dokumentacji perfetto.

• Tryb jarzma testowego

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

  • [C-2-1] MUST return true for ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] NALEŻY zaimplementować tryb jarzma testowego zgodnie z opisem w dokumentacji trybu jarzma.

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

• [C-1-1] NALEŻY zapewnić deweloperowi aplikacji możliwość włączania i wyłączania warstw debugowania GPU.
• [C-1-2] Gdy włączone są warstwy debugowania GPU, MUSISZ wyliczać warstwy w bibliotekach udostępnianych przez zewnętrzne narzędzia (czyli niebędące częścią platformy ani pakietu aplikacji) znajdujące się w katalogu głównym aplikacji, aby obsługiwać metody interfejsu API vkEnumerateInstanceLayerProperties() i vkCreateInstance().

6.2. Opcje programisty

Android zawiera funkcje umożliwiające deweloperom konfigurowanie ustawień związanych z tworzeniem aplikacji.

Implementacje na urządzeniach MUSZĄ zapewniać spójne opcje dla deweloperów. Muszą one:

• [C-0-1] MUSI obsługiwać działanie okna dialogowego android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z rozwojem aplikacji. W dolnej implementacji Androida menu Opcje dewelopera jest domyślnie ukryte, a użytkownicy mogą je otworzyć po naciśnięciu siedmiu (7) razy elementu menu Ustawienia > Informacje o urządzeniu > Numer kompilacji.
• [C-0-2] Domyślnie należy ukryć Opcje programisty.
• [C-0-3] Musisz zapewnić przejrzysty mechanizm, który nie faworyzuje jednej aplikacji zewnętrznej kosztem innej, aby włączyć opcje dla deweloperów. MUSISZ przesłać publicznie dostępny dokument lub stronę internetową z instrukcjami włączania opcji dla deweloperów. Ten dokument lub witryna MUSI być powiązana z dokumentami pakietu SDK Androida.
• POWINIEN wyświetlać użytkownikowi stałe wizualne powiadomienie, gdy opcje programisty są włączone, a bezpieczeństwo użytkownika jest zagrożone.
• MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty, ukrywając je wizualnie lub wyłączając, aby zapobiec rozproszeniu w sytuacjach, w których bezpieczeństwo użytkownika jest zagrożone.

7. Zgodność sprzętowa

Jeśli urządzenie zawiera określony komponent sprzętowy z odpowiednim interfejsem API dla deweloperów innych firm:

• [C-0-1] Implementacja na urządzeniu MUSI implementować to API zgodnie z opisem w dokumentacji Android SDK.

Jeśli interfejs API w pakiecie SDK współdziała ze sprzętowym komponentem, który jest oznaczony jako opcjonalny, a urządzenie nie ma tego komponentu:

• [C-0-2] W przypadku interfejsów API komponentów nadal MUSISZ podać pełne definicje klas (opisane w pakiecie SDK).
• [C-0-3] Zachowanie interfejsu API MUSI być zaimplementowane w taki sposób, aby nie wymagało żadnych działań.
• [C-0-4] Metody interfejsu API MUSZĄ zwracać wartości null, gdy jest to dozwolone przez dokumentację pakietu SDK.
• [C-0-5] Metody interfejsu API MUSZĄ zwracać implementacje klas bez operacji, w których wartości null nie są dozwolone w dokumentacji pakietu SDK.
• [C-0-6] Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, które nie są opisane w dokumentacji pakietu SDK.
• [C-0-7] Implementacje urządzeń MUSZĄ konsekwentnie przekazywać dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager dla tego samego odcisku palca kompilacji.

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

7.1. Wyświetlanie i grafika

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

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

• fizyczna przekątna. Odległość w calach między dwoma przeciwległymi rogami podświetlonej części wyświetlacza.
• punkty na cal (dpi). Liczba pikseli zawartych w liniowym zakresie poziomym lub pionowym 1”. Jeśli podano wartości dpi, zarówno poziomy, jak i pionowy dpi MUSZĄ mieścić się w zakresie.
• format. Stosunek pikseli dłuższego wymiaru do krótszego wymiaru ekranu. Na przykład wyświetlacz o wymiarach 480 x 854 pikseli miałby współczynnik 854/480 = 1, 779, czyli mniej więcej „16:9”.
• piksel niezależny od gęstości (dp). Wirtualna jednostka piksela znormalizowana do ekranu o wyświetlaniu 160 dpi, obliczona jako: piksele = dps * (gęstość/160).

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar i kształt ekranu

Interfejs użytkownika Androida obsługuje różne rozmiary układów ekranu i pozwala aplikacjom wysyłać zapytanie o rozmiar układu ekranu w bieżącej konfiguracji za pomocą interfejsu Configuration.screenLayout z użyciem metod SCREENLAYOUT_SIZE_MASK i Configuration.smallestScreenWidthDp.

Implementacje na urządzeniu:

• [C-0-1] Musisz podać prawidłowy rozmiar układu dla Configuration.screenLayout zgodnie z definicją w dokumentacji pakietu SDK Androida. W szczególności implementacje urządzeń MUSZĄ zgłaszać prawidłowe wymiary ekranu w pikselach niezależnych od gęstości (dp) zgodnie z poniższymi wartościami:

  • Urządzenia z wartością parametru Configuration.uiMode inną niż UI_MODE_TYPE_WATCH, które podają rozmiar small dla atrybutu Configuration.screenLayout, MUSZĄ mieć 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, które podają rozmiar large dla Configuration.screenLayout, MUSZĄ mieć wymiary co najmniej 640 x 480 dp.
  • Urządzenia zgłaszające rozmiar xlarge w przypadku Configuration.screenLayout MUSZĄ mieć co najmniej 960 dp x 720 dp.

• [C-0-2] MUSI prawidłowo obsługiwać deklarowane przez aplikację rozmiary ekranów za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml zgodnie z dokumentacją pakietu SDK Androida.

• MOŻE mieć wyświetlacze zgodne z Androidem z zaokrąglonymi rogami.

Jeśli implementacje urządzeń obsługują UI_MODE_TYPE_NORMAL i obejmują wyświetlacze zgodne z Androidem z zaokrąglonymi rogami, to:

• [C-1-1] Promień zaokrąglonych rogów musi być mniejszy lub równy 38 dp.
• NALEŻY uwzględnić możliwość przełączenia się do trybu wyświetlania za pomocą prostokątnych rogów.

7.1.1.2. Format obrazu

Chociaż nie ma ograniczeń dotyczących proporcji fizycznych ekranów zgodnych z Androidem, proporcje ekranu logicznego, na którym renderowane są aplikacje innych firm, muszą być zgodne z tymi wymaganiami:view.Display

• [C-0-1] Urządzenia z wartością Configuration.uiMode równą UI_MODE_TYPE_NORMAL MUSZĄ mieć współczynnik kształtu obrazu mniejszy niż 1,86 (około 16:9), chyba że aplikacja spełnia jedną z tych 2 warunków:

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

• [C-0-2] Wdrożenia na urządzeniach z wartością Configuration.uiMode równą UI_MODE_TYPE_NORMAL MUSZĄ mieć współczynnik proporcji równy lub większy niż 1,3333 (4:3), chyba że aplikacja może zostać rozciągnięta w szerzy, gdy spełniony jest jeden z tych warunków:

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

• [C-0-3] Wdrożenia urządzenia z wartością Configuration.uiMode ustawioną jako UI_MODE_TYPE_WATCH MUSZĄ mieć wartość formatu obrazu ustawioną jako 1,0 (1:1).

7.1.1.3. Gęstość ekranu

Interfejs użytkownika Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić deweloperom aplikacji kierowanie zasobów aplikacji.

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

• Implementacje urządzeń powinny zdefiniować standardową gęstość w ramach Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, chyba że ta gęstość logiczna spowoduje, że zgłaszany rozmiar ekranu będzie niższy niż minimalny obsługiwany rozmiar. Jeśli standardowa gęstość ramki Androida, która pod względem liczbowym jest najbliższa fizycznej gęstości, powoduje, że rozmiar ekranu jest mniejszy niż najmniejszy obsługiwany zgodny rozmiar ekranu (szerokość 320 dp), implementacje urządzeń POWINNY zgłaszać następną niższą standardową gęstość ramki Androida.

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

• [C-1-1] Rozmiar wyświetlacza NIE MOŻE być powiększony ponad 1,5-krotną wartość gęstości natywnej ani nie może powodować, że minimalny wymiar ekranu będzie mniejszy niż 320 dp (co odpowiada kwalifikatorowi zasobu sw320dp), w zależności od tego, co nastąpi pierwsze.
• [C-1-2] Rozmiar wyświetlacza NIE MOŻE być przeskalowany do wartości mniejszej niż 0,85 krotna gęstości natywnej.
• Aby zapewnić dobrą użyteczność i spójność rozmiarów czcionek, zalecamy zastosowanie tych opcji skalowania wyświetlania natywnych (z zachowaniem limitów określonych powyżej).
• Małe: 0,85 x
• Domyślnie: 1x (rodzinna skala wyświetlacza)
• Duża: 1,15 x
• Większy: 1,3 x
• Największy 1,45x

7.1.2. Dane dotyczące wyświetleń

Jeśli implementacje urządzeń obejmują wyświetlacze zgodne z Androidem lub wyjście wideo na ekrany zgodne z Androidem, muszą:

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

Jeśli implementacje urządzeń nie zawierają wbudowanego ekranu ani wyjścia wideo, nie mogą:

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

7.1.3. Orientacja ekranu

Implementacje na urządzeniu:

• [C-0-1] MUST report which screen orientations they support (android.hardware.screen.portrait or android.hardware.screen.landscape) and MUST report at least one supported orientation. Na przykład urządzenie z niezmienną orientacją poziomą ekranu, takie jak telewizor czy laptop, POWINNA zgłaszać tylko android.hardware.screen.landscape.
• [C-0-2] MUSI zwracać prawidłową wartość bieżącej orientacji urządzenia, gdy zostanie zapytany za pomocą interfejsów API android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innych.

Jeśli implementacje urządzeń obsługują obie orientacje ekranu, muszą:

• [C-1-1] Aplikacje MUSZĄ obsługiwać dynamiczną orientację ekranu w orientacji poziomej lub pionowej. Oznacza to, że urządzenie MUSI uwzględnić żądaną przez aplikację orientację ekranu.
• [C-1-2] Zmieniając orientację, NIE MOŻESZ zmienić zgłaszanego rozmiaru ekranu ani gęstości.
• MOŻE wybrać orientację pionową lub poziomą jako domyślną.

7.1.4. akceleracja grafiki 2D i 3D;

7.1.4.1 OpenGL ES

Implementacje na urządzeniu:

• [C-0-1] MUSI prawidłowo identyfikować obsługiwane wersje OpenGL ES (1.1, 2.0, 3.0, 3.1, 3.2) za pomocą zarządzanych interfejsów API (np. za pomocą metody GLES10.getString()) i natywnych interfejsów API.
• [C-0-2] MUSI zawierać obsługę wszystkich odpowiednich zarządzanych interfejsów API i natywnych interfejsów API we wszystkich wersjach OpenGL ES, które zostały wskazane jako obsługiwane.

Jeśli implementacje urządzeń obejmują ekran lub wyjście wideo, muszą:

• [C-1-1] Musi obsługiwać OpenGL ES 1.1 i 2.0 zgodnie z opisem w dokumentacji pakietu SDK Androida.
• [C-SR] MOCNO zalecamy obsługę OpenGL ES 3.1.
• NALEŻY obsługiwać OpenGL ES 3.2.

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

• [C-2-1] NALEŻY zgłaszać za pomocą interfejsów API zarządzanych OpenGL ES i natywnych interfejsów API wszystkie zaimplementowane rozszerzenia OpenGL ES. Z drugiej strony, NALEŻY NIE zgłaszać ciągów znaków rozszerzenia, których nie obsługuje.
• [C-2-2] MUSI obsługiwać rozszerzenia EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable i EGL_ANDROID_GLES_layers.
• [C-SR] ZALECAMY obsługę rozszerzeń EGL_KHR_partial_update i OES_EGL_image_external.
• NALEŻY dokładnie podać za pomocą metody getString() dowolny obsługiwany format kompresji tekstur, który jest zwykle specyficzny dla dostawcy.

Jeśli implementacje na urządzeniu deklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2, muszą:

• [C-3-1] NALEŻY wyeksportować odpowiadające symbole funkcji dla tych wersji, oprócz symboli funkcji OpenGL ES 2.0 w bibliotece libGLESv2.so.
• [SR] MOCNO zalecamy obsługę rozszerzenia OES_EGL_image_external_essl3.

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

• [C-4-1] Aplikacja MUSI obsługiwać cały pakiet rozszerzeń OpenGL ES na Androida.

Jeśli implementacje urządzeń obsługują w pełni pakiet rozszerzeń OpenGL ES na Androida, to:

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

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

• [C-6-1] Musi obsługiwać rozszerzenie EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

Android obsługuje interfejs Vulkan , czyli wieloplatformowy interfejs API o niskim obciążeniu, który umożliwia tworzenie wydajnej grafiki 3D.

Jeśli implementacje na urządzeniu obsługują OpenGL ES 3.1, to:

• [SR] ZDECYDOWANIE zaleca się uwzględnienie obsługi Vulkan 1.1.

Jeśli implementacje urządzeń obejmują ekran lub wyjście wideo, muszą:

• NALEŻY uwzględnić obsługę Vulkan 1.1.

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

• [C-1-1] Musisz podać prawidłową wartość całkowitą za pomocą flag funkcji android.hardware.vulkan.level i android.hardware.vulkan.version.
• [C-1-2] MUST enumerate, at least one VkPhysicalDevice for the Vulkan native API vkEnumeratePhysicalDevices() .
• [C-1-3] NALEŻY w pełni zaimplementować interfejsy API Vulkan 1.0 dla każdego z wymienionych VkPhysicalDevice.
• [C-1-4] NALEŻY wyliczyć warstwy zawarte w bibliotekach natywnych o nazwie libVkLayer*.so w katalogu bibliotek natywnych pakietu aplikacji za pomocą interfejsów API natywnych Vulkan vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties() .
• [C-1-5] NIE MOŻESZ wymieniać warstw udostępnianych przez biblioteki spoza pakietu aplikacji ani udostępniać innych sposobów śledzenia lub przechwytywania interfejsu Vulkan API, chyba że aplikacja ma atrybut android:debuggable ustawiony jako true.
• [C-1-6] NALEŻY podać wszystkie ciągi znaków rozszerzeń, które są obsługiwane za pomocą natywnych interfejsów Vulkan, i odwrotnie – NALEŻY NIE podać ciągów znaków rozszerzeń, które nie są obsługiwane prawidłowo.
• [C-1-7] Musi obsługiwać rozszerzenia VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain i VK_KHR_incremental_present.
• [C-SR] MOCNO ZALECAMY obsługę rozszerzeń VK_KHR_driver_properties i VK_GOOGLE_display_timing.

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

• [C-2-1] NIE NALEŻY deklarować żadnych flag funkcji Vulkana (np. android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] NIE MOŻNA wymieniać żadnych wartości VkPhysicalDevice w przypadku interfejsu API natywnego Vulkan vkEnumeratePhysicalDevices().

Jeśli implementacje na urządzeniu obejmują obsługę Vulkan 1.1 i deklarują co najmniej 1 flagę funkcji Vulkan, muszą:

• [C-3-1] MUSI obsługiwać typy zewnętrznych semantów i uchwytów SYNC_FD oraz rozszerzenie VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

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

7.1.4.4 Akceleracja grafiki 2D

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

Implementacje na urządzeniu:

• [C-0-1] NALEŻY włączyć akcelerację sprzętową domyślnie i NALEŻY ją wyłączyć, jeśli deweloper tak zażąda, ustawiając android:hardwareAccelerated="false” lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów Android View API.
• [C-0-2] Musi działać zgodnie z dokumentacją pakietu SDK Androida dotyczącą przyspieszania sprzętowego.

Android zawiera obiekt TextureView, który umożliwia deweloperom bezpośrednią integrację tekstur OpenGL ES przyspieszanych sprzętowo jako celów renderowania w hierarchii interfejsu.

Implementacje na urządzeniu:

• [C-0-3] MUSI obsługiwać interfejs TextureView API i MUSI zachowywać się zgodnie z implementacją na Androidzie.

7.1.4.5 Wyświetlacze o szerokim zakresie dynamiki

Jeśli implementacje urządzeń obsługują wyświetlacze o szerokim zakresie tonalnym za pomocą Configuration.isScreenWideColorGamut() , muszą:

• [C-1-1] Musisz mieć wyświetlacz z kalibracją kolorów.
• [C-1-2] Wyświetlacz musi mieć gamę, która całkowicie pokrywa gamę kolorów sRGB w przestrzeni CIE 1931 xyY.
• [C-1-3] Musisz mieć wyświetlacz, którego paleta ma obszar co najmniej 90% DCI-P3 w przestrzeni CIE 1931 xyY.
• [C-1-4] Musi obsługiwać OpenGL ES 3.1 lub 3.2 i odpowiednio to zgłaszać.
• [C-1-5] MUSISZ reklamować obsługę rozszerzeń EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear i EGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR] Zdecydowanie zalecamy obsługę GL_EXT_sRGB.

Jeśli implementacje urządzeń nie obsługują wyświetlaczy o szerokim zakresie, nie mogą:

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

7.1.5. Tryb zgodności ze starszymi wersjami aplikacji

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

7.1.6. Technologia ekranu

Platforma Android zawiera interfejsy API, które umożliwiają aplikacjom renderowanie bogatych grafik na wyświetlaczu zgodnym z Androidem. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zgodnie z definicją w pakiecie SDK Androida, chyba że w tym dokumencie jest to wyraźnie dozwolone.

Wszystkie wyświetlacze zgodne z Androidem w ramach implementacji urządzenia:

• [C-0-1] Musi być możliwe renderowanie grafiki w kolorze 16-bitowym.
• NALEŻY obsługiwać wyświetlacze obsługujące 24-bitową grafikę kolorową.
• [C-0-2] Musi być możliwe renderowanie animacji.
• [C-0-3] Współczynnik proporcji pikseli (PAR) MUSI mieścić się w zakresie od 0,9 do 1,15. Oznacza to, że współczynnik proporcji piksela MUSI być zbliżony do kwadratu (1,0) z tolerancją 10–15%.

7.1.7. Wyświetlacze dodatkowe

Android obsługuje dodatkowe wyświetlacze zgodne z Androidem, aby umożliwić udostępnianie multimediów, oraz interfejsy API dla programistów, które umożliwiają dostęp do wyświetlaczy zewnętrznych.

Jeśli implementacje urządzeń obsługują wyświetlacz zewnętrzny przez połączenie przewodowe, bezprzewodowe lub wbudowane dodatkowe wyświetlacze, muszą:

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

7.2. Urządzenia wejściowe

Implementacje na urządzeniu:

• [C-0-1] Musisz uwzględnić mechanizm wprowadzania danych, np. ekran dotykowy lub nawigację bezdotykowej, aby nawigować między elementami interfejsu.

7.2.1. Klawiatura

Jeśli implementacje urządzeń obejmują obsługę zewnętrznych edytorów metody wprowadzania (IME), muszą:

• [C-1-1] NALEŻY zadeklarować flagę funkcji android.software.input_methods.
• [C-1-2] NALEŻY w pełni wdrożyć Input Management Framework
• [C-1-3] Musi być wstępnie zainstalowana klawiatura programowa.

Implementacje na urządzeniu: * [C-0-1] NIE MOŻE zawierać klawiatury sprzętowej, która nie pasuje do jednego z formatów określonych w android.content.res.Configuration.keyboard (QWERTY lub 12 klawiszy). * NALEŻY uwzględnić dodatkowe implementacje klawiatury ekranowej. * MOŻE zawierać klawiaturę sprzętową.

7.2.2. Nawigacja bezdotykowa

Android obsługuje panel kierunkowy, kulkę kierunkową i koło jako mechanizmy nawigacji bezdotykowej.

Implementacje na urządzeniu:

• [C-0-1] NALEŻY podać prawidłową wartość dla android.content.res.Configuration.navigation.

Jeśli implementacje na urządzeniach nie obsługują nawigacji bezdotykowej, mogą:

• [C-1-1] Musisz zapewnić rozsądny alternatywny mechanizm interfejsu użytkownika do zaznaczania i edytowania tekstu, który jest zgodny z silnikami zarządzania danymi wejściowymi. W ramach implementacji open source Androida dodany został mechanizm wyboru odpowiedni do korzystania z urządzeń, które nie mają elementów sterujących dotykowych.

7.2.3. Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz są zwykle dostępne po naciśnięciu odpowiedniego przycisku fizycznego lub określonej części ekranu dotykowego. Są one niezbędne w ramach paradygmatu nawigacji w Androidzie, a dlatego są też implementowane na urządzeniach:

• [C-0-1] Musisz umożliwić użytkownikowi uruchamianie zainstalowanych aplikacji, które mają działanie z <intent-filter> ustawionym na ACTION=MAIN i CATEGORY=LAUNCHER lub CATEGORY=LEANBACK_LAUNCHER w przypadku implementacji na telewizorach. Funkcja Home powinna być mechanizmem umożliwiającym użytkownikowi wykonanie tej czynności.
• NALEŻY zapewnić przyciski Ostatnie i Wstecz.

Jeśli dostępne są funkcje ekranu głównego, Ostatnie lub Wstecz, muszą one:

• [C-1-1] Musi być możliwe do wykonania jednym działaniem (np. dotknięciem, dwukrotnym kliknięciem lub gestem), gdy którekolwiek z nich jest dostępne.
• [C-1-2] NALEŻY wyraźnie wskazać, które pojedyncze działanie uruchamia każdą funkcję. Może to być widoczna ikona na przycisku, ikona oprogramowania na pasku nawigacyjnym lub szczegółowy samouczek podczas konfiguracji.

Implementacje na urządzeniu:

• [SR] ZALECAMY, aby nie udostępniać mechanizmu wprowadzania danych w funkcji menu, ponieważ od wersji 4.0 Androida jest on wycofany na rzecz paska czynności.

Jeśli implementacje urządzeń udostępniają funkcję menu, muszą:

• [C-2-1] NALEŻY wyświetlić przycisk menu akcji, gdy menu akcji nie jest puste i widoczny jest pasek akcji.
• [C-2-2] NIE wolno modyfikować pozycji wyskakującego okienka akcji wyświetlanego po kliknięciu przycisku przepełnienia w pasku akcji, ale można wyświetlić to wyskakujące okienko w zmodyfikowanej pozycji na ekranie po kliknięciu funkcji menu.

Jeśli implementacje urządzeń nie zapewniają funkcji menu, ze względu na zgodność wsteczną: * [C-SR] ZALECAMY udostępnienie funkcji menu aplikacjom, gdy targetSdkVersion jest mniejsza niż 10, za pomocą przycisku fizycznego, klawisza programowego lub gestów. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacji.

Jeśli implementacje urządzeń obsługują funkcję pomocy, to:

• [C-4-1] Funkcja pomocy musi być dostępna za pomocą pojedynczego działania (np. kliknięcia, podwójnego kliknięcia lub gestu), gdy inne klawisze nawigacyjne są dostępne.
• [SR] MOCNO ZALECANA długotrwała aktywacja funkcji ekranu głównego.

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

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

Jeśli funkcja nawigacji jest obsługiwana jako działanie na ekranie oparte na gestach:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() NALEŻY używać tylko do raportowania obszaru rozpoznawania gestu Home.
• [C-6-2] Gesty, które rozpoczynają się w prostokącie wykluczenia udostępnionym przez aplikację na pierwszym planie za pomocą interfejsu View#setSystemGestureExclusionRects(), ale poza obszarem WindowInsets#getMandatorySystemGestureInsets(), NIE POWINNY być przechwytywane przez funkcję nawigacji, o ile prostokąt wykluczenia jest dozwolony w ramach maksymalnego limitu wykluczenia określonego w dokumentacji do interfejsu View#setSystemGestureExclusionRects().
• [C-6-3] Gdy aplikacja na pierwszym planie otrzyma zdarzenie MotionEvent.ACTION_CANCEL, musi wysłać zdarzenie MotionEvent.ACTION_DOWN, gdy wykryje dotknięcia przechwytywane przez gest systemowy.
• [C-6-4] NALEŻY umożliwić użytkownikowi przejście do sterowania za pomocą przycisków na ekranie (np. w Ustawieniach).
• NALEŻY zapewnić funkcję ekranu głównego jako przesunięcie palcem od dolnej krawędzi w bieżącym położeniu ekranu.
• NALEŻY udostępnić funkcję Ostatnie jako gest przesunięcia w górę i przytrzymania przed zwalnieniem, z tego samego obszaru co gest powrotu do ekranu głównego.
• Gesty, które zaczynają się w aplikacji WindowInsets#getMandatorySystemGestureInsets(), NIE powinny być blokowane przez prostokąty wykluczenia udostępniane przez aplikację na pierwszym planie za pomocą View#setSystemGestureExclusionRects().

Jeśli funkcja nawigacji jest dostępna w dowolnym miejscu po lewej i po prawej stronie ekranu w zależności od bieżącej orientacji ekranu:

• [C-7-1] Funkcja nawigacji MUSI być funkcją Wstecz i musi być dostępna przez przesunięcie palcem od lewej i prawej krawędzi ekranu w zależności od bieżącej orientacji ekranu.
• [C-7-2] Jeśli po lewej lub prawej stronie ekranu dostępne są niestandardowe panele systemowe, które można przesunąć, muszą one znajdować się w górnej 1/3 ekranu. Muszą też być wyraźnie oznaczone wizualnie, aby użytkownik wiedział, że przesunięcie palcem spowoduje wyświetlenie wspomnianych paneli, a nie przycisku Wstecz. Panel systemowy MOŻE zostać skonfigurowany przez użytkownika tak, aby znajdował się poniżej górnej 1/3 krawędzi ekranu, ale panel systemowy NIE MOŻE zajmować więcej niż 1/3 krawędzi.
• [C-7-3] Gdy aplikacja na pierwszym planie ma ustawione flagi View.SYSTEM_UI_FLAG_IMMERSIVE lub View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, przesuwanie palcem od krawędzi MUSI działać tak, jak zostało zaimplementowane w AOSP, zgodnie z dokumentacją pakietu SDK.
• [C-7-4] Gdy aplikacja na pierwszym planie ma ustawione flagi View.SYSTEM_UI_FLAG_IMMERSIVE lub View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, niestandardowe panele systemowe, które można przesuwać, MUSZĄ być ukryte, dopóki użytkownik nie wyświetli pasków systemowych (czyli paska nawigacyjnego i paska stanu) zgodnie z implementacją w AOSP.

7.2.4. Dotykowe wprowadzanie danych

Android obsługuje różne systemy wskaźników, takie jak ekrany dotykowe, panele dotykowe i urządzenia dotykowe z fałszywym dotykiem. Implementacje urządzeń z ekranem dotykowym są powiązane z ekranem w taki sposób, aby użytkownik miał wrażenie bezpośredniej manipulacji elementami na ekranie. Ponieważ użytkownik dotyka ekranu bezpośrednio, system nie wymaga żadnych dodatkowych elementów, które wskazywałyby na obiekty, którymi można manipulować.

Implementacje na urządzeniu:

• POWINIEN zawierać system sterowania kursorem (podobny do myszy lub dotykowy).
• NALEŻY obsługiwać wskaźniki śledzone niezależnie.

Jeśli implementacje urządzeń obejmują ekran dotykowy (jednodotykowy lub lepszy), muszą:

• [C-1-1] W polu interfejsu API Configuration.touchscreen musisz podać wartość TOUCHSCREEN_FINGER.
• [C-1-2] MUST report the android.hardware.touchscreen and android.hardware.faketouch feature flags.

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

• [C-2-1] NALEŻY podać odpowiednie flagi funkcji android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand odpowiadające typowi konkretnego ekranu dotykowego na urządzeniu.

Jeśli implementacje urządzeń nie obejmują ekranu dotykowego (i korzystają tylko z urządzenia wskazującego) oraz spełniają wymagania dotyczące fałszywych dotknięć podane w sekcji 7.2.5, to:

• [C-3-1] NIE wolno raportować żadnych flag funkcji zaczynających się od android.hardware.touchscreen. Należy raportować tylko flagi zaczynające się od android.hardware.faketouch.

7.2.5. Symulowane dotykowe wprowadzanie danych

Symulowany interfejs dotykowy zapewnia system wprowadzania danych użytkownika, który w przybliżeniu odwzorowuje możliwości ekranu dotykowego. Na przykład mysz lub pilot, który steruje kursorem na ekranie, umożliwia działanie zbliżone do dotyku, ale wymaga od użytkownika najpierw wskazania lub skupienia się na obiekcie, a potem kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, mysz powietrzna z użyciem żyroskopu, wskaźnik z użyciem żyroskopu, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe. Android zawiera stałą android.hardware.faketouch, która odpowiada urządzeniu do wprowadzania danych niebędącemu urządzeniem dotykowym (z wskaźnikiem), np. myszce lub trackpadowi, które może odpowiednio emulować dane dotykowe (w tym obsługę podstawowych gestów) i wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego.

Jeśli implementacje urządzeń nie obejmują ekranu dotykowego, ale zawierają inny system wprowadzania danych za pomocą wskaźnika, który chcą udostępnić, muszą:

• NALEŻY zadeklarować obsługę flagi funkcji android.hardware.faketouch.

Jeśli implementacje na urządzeniach deklarują obsługę android.hardware.faketouch, muszą:

• [C-1-1] MUSI raportować absolutne pozycje X i Y na ekranie wskaźnika oraz wyświetlać go na ekranie.
• [C-1-2] NALEŻY zgłaszać zdarzenie dotyku z kodem działania, który określa stan zmiany wskaźnika przemieszczającego się w dół lub w górę po ekranie.
• [C-1-3] Musi obsługiwać kursor w dół i w górę na obiekcie na ekranie, co pozwala użytkownikom emulować kliknięcie obiektu na ekranie.
• [C-1-4] MUSI obsługiwać gesty w dół, w górę i znów w dół w tym samym miejscu na ekranie w ramach określonego progu czasowego, co pozwala użytkownikom zasymulować dwukrotne kliknięcie na ekranie.
• [C-1-5] Musi obsługiwać wciśnięcie wskaźnika w dowolnym miejscu na ekranie, przesunięcie wskaźnika do dowolnego innego miejsca na ekranie, a następnie zwolnienie wskaźnika, co pozwala użytkownikom emulować przeciąganie palcem.
• [C-1-6] MUSI obsługiwać wskaźnik w dół, a następnie musi umożliwiać użytkownikom szybkie przenoszenie obiektu w inne miejsce na ekranie, a następnie wskaźnik w górę na ekranie, co pozwala użytkownikom rzucać obiektem na ekranie.
• [C-1-7] W polu interfejsu API Configuration.touchscreen MUSISZ podać wartość TOUCHSCREEN_NOTOUCH.

Jeśli implementacje na urządzeniach deklarują obsługę android.hardware.faketouch.multitouch.distinct, muszą:

• [C-2-1] MUST declare support for android.hardware.faketouch.
• [C-2-2] MUSI obsługiwać oddzielne śledzenie co najmniej 2 niezależnych sygnałów wejściowych wskaźnika.

Jeśli implementacje na urządzeniach deklarują obsługę android.hardware.faketouch.multitouch.jazzhand, muszą:

• [C-3-1] MUSISZ zadeklarować obsługę android.hardware.faketouch.
• [C-3-2] MUSI obsługiwać oddzielne śledzenie co najmniej 5 (śledzenie ręki z palcami) lub więcej urządzeń wskazujących w pełni niezależnie.

7.2.6. Obsługa kontrolera gier

7.2.6.1. Mapowania przycisków

Jeśli implementacje na urządzeniu deklarują flagę funkcji android.hardware.gamepad, mogą:

• [C-1-1] Musisz umieścić w urządzeniu kontroler lub dołączyć do niego oddzielny kontroler w kartonie, który umożliwi wprowadzanie wszystkich zdarzeń wymienionych w tabeli poniżej.
• [C-1-2] MUSI być w stanie mapować zdarzenia HID na powiązane stałe Androida view.InputEvent, jak podano w tabelach poniżej. Wdrożenie na Androidzie obejmuje sterowanie kontrolerem, które spełnia ten wymóg.

1 KeyEvent

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

3 W tym przypadku minimalna wartość logiczna musi wynosić 0, maksymalna – 7, minimalna wartość fizyczna – 0, maksymalna – 315, jednostki – stopnie, a rozmiar raportu – 4. Wartość logiczna jest zdefiniowana jako obrót zgodnie z ruchem wskazówek zegara od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i wciśnięcie przycisku w górę, a wartość logiczna 1 oznacza obrót o 45° i wciśnięcie przycisków w górę i w lewo.

4. MotionEvent

1 MotionEvent

7.2.7. Pilot

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

7.3. Czujniki

Jeśli implementacja urządzenia zawiera określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów innych firm, implementacja urządzenia MUSI implementować ten interfejs API zgodnie z opisem w dokumentacji pakietu SDK Androida i dokumentacji Androida Open Source dotyczącej czujników.

Implementacje na urządzeniu:

• [C-0-1] Musisz dokładnie podać obecność lub brak czujników zgodnie z klasą android.content.pm.PackageManager.
• [C-0-2] Musisz zwrócić dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() lub podobnej.
• [C-0-3] Musi działać prawidłowo w przypadku wszystkich innych interfejsów API czujników (np. zwracać true lub false w odpowiednich przypadkach, gdy aplikacje próbują zarejestrować słuchaczy, nie wywoływać słuchaczy czujników, gdy nie ma odpowiednich czujników itp.).

Jeśli implementacje urządzeń zawierają określony typ czujnika z odpowiednim interfejsem API dla deweloperów zewnętrznych, mogą one:

• [C-1-1] Zgłoszenia wszystkich pomiarów czujników muszą być dokonywane z użyciem odpowiednich wartości z Międzynarodowego Systemu Jednostek (metrycznych) dla każdego typu czujnika zgodnie z definicją w dokumentacji Android SDK.
• [C-1-2] W przypadku strumienia danych z czujnika z maksymalnie żądaną latencją 0 ms, gdy aktywny jest procesor aplikacji, MUSI przesyłać dane z czujnika z maksymalnie 100 ms opóźnienia + 2 * sample_time. To opóźnienie nie obejmuje opóźnień związanych z filtrowaniem.
• [C-1-3] NALEŻY zgłaszać pierwszą próbkę czujnika w ciągu 400 milisekund + 2 * sample_time od momentu aktywacji czujnika. W przypadku tej próbki dopuszczalna jest dokładność 0.

• [SR] Raportuj czas zdarzenia w nanosekundach zgodnie z definicją w dokumentacji pakietu SDK Androida. Czas zdarzenia jest synchronizowany z zegarem SystemClock.elapsedRealtimeNano(). Zalecamy, aby i obecne, i nowe urządzenia z Androidem spełniały te wymagania, ponieważ dzięki temu będą mogły przejść na przyszłe wersje platformy, w których mogą stać się wymaganym elementem. Błąd synchronizacji powinien być mniejszy niż 100 ms.

• [C-1-4] W przypadku każdego interfejsu API oznaczonego w dokumentacji pakietu Android SDK jako ciągły czujnik implementacje na urządzeniu MUSZĄ stale dostarczać okresowych próbek danych, które POWINNY mieć jitter poniżej 3%, gdzie jitter jest zdefiniowany jako odchylenie standardowe różnicy wartości raportowanych sygnatur czasowych między kolejnymi zdarzeniami.

• [C-1-5] NALEŻY zadbać o to, aby strumień zdarzeń z czujników NIE PRZESZKADZAŁ procesorowi w wejściu w stan zawieszenia ani w wybudzeniu z tego stanu.

• Gdy aktywowanych jest kilka czujników, zużycie energii NIE POWINNA przekraczać sumy zużycia energii poszczególnych czujników.

Powyższa lista nie jest wyczerpująca. Należy wziąć pod uwagę udokumentowane działanie pakietu Android SDK i dokumentację na temat czujników w dokumentacji do Androida w wersji open source.

Niektóre typy czujników są złożone, co oznacza, że mogą być wyprowadzone z danych pochodzących z co najmniej jednego innego czujnika. (np. czujnik orientacji i czujnik przyspieszenia liniowego).

Implementacje na urządzeniu:

• NALEŻY zaimplementować te typy czujników, jeśli zawierają one wymagane czujniki fizyczne opisane w sekcji Typy czujników.

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

• [C-2-1] NALEŻY zaimplementować czujnik zgodnie z opisem w dokumentacji dotyczącej złożonych czujników w systemie Android Open Source.

7.3.1. Akcelerometr

Implementacje na urządzeniu:

• [C-SR] Zdecydowanie zalecamy dodanie 3-osiowego akcelerometru.

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

• [C-1-1] Musisz mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz.
• [C-1-2] MUSISZ wdrożyć i zgłosić 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ć od swobodnego spadania do 4 krotności przyspieszenia ziemskiego(4 g) lub więcej na dowolnej osi.
• [C-1-5] Rozdzielczość musi wynosić co najmniej 12 bitów.
• [C-1-6] MUSI mieć odchylenie standardowe nie większe niż 0,05 m/s2, przy czym odchylenie standardowe NALEŻY obliczać dla każdej osi na podstawie próbek zebranych w ciągu co najmniej 3 sekund z najwyższą częstotliwością próbkowania.
• [SR] MOCNO ZALECAMY wdrożenie złożonego czujnika TYPE_SIGNIFICANT_MOTION.
• [SR] ZALECAMY Z MOCĄ zaimplementowanie i raportowanie czujnika TYPE_ACCELEROMETER_UNCALIBRATED. Zalecamy, aby urządzenia z Androidem spełniały to wymaganie, ponieważ w przyszłości może ono stać się wymagane.
• NALEŻY zaimplementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER zgodnie z opisem w dokumentacji pakietu Android SDK.
• Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.
• NALEŻY mieć rozdzielczość co najmniej 16-bitową.
• POWINIEN być kalibrowany podczas użytkowania, jeśli jego właściwości zmieniają się w trakcie cyklu życia, oraz kompensować i zachowywać parametry kompensacji między ponownymi uruchamieniami urządzenia.
• POWINIEN być kompensowany temperaturowo.

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

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

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

• [C-3-1] OBOWIĄZKOWO stosować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR] Zdecydowanie zalecamy wdrożenie czujnika złożonego TYPE_GAME_ROTATION_VECTOR.

Jeśli implementacje urządzenia obejmują 3-osiowy akcelerometr, 3-osiowy czujnik żyroskopowy i czujnik magnetyczny, muszą:

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

7.3.2. Magnetometr

Implementacje na urządzeniu:

• [C-SR] Zdecydowanie zalecamy uwzględnienie 3-osiowego magnetometru (kompasu).

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

• [C-1-1] MUSISZ zaimplementować czujnik TYPE_MAGNETIC_FIELD.
• [C-1-2] Musi być możliwe raportowanie zdarzeń z częstotliwością co najmniej 10 Hz i należy 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 od -900 µT do +900 µT na każdej osi przed nasyceniem.
• [C-1-5] Wartość przesunięcia pola magnetycznego stałego żelaza MUSI być mniejsza niż 700 µT, a powinna być mniejsza niż 200 µT. Aby to osiągnąć, należy umieścić magnetometr z dala od pól magnetycznych dynamicznych (wywołanych przez prąd) i statycznych (wywołanych przez magnes).
• [C-1-6] Rozdzielczość musi być równa lub większa niż 0,6 µT.
• [C-1-7] MUSI obsługiwać kalibrację online i kompensację błędów zniekształcenia oraz zachowywać parametry kompensacji po ponownym uruchomieniu urządzenia.
• [C-1-8] NALEŻY zastosować kompensację miękkiego żelaza. Kalibrację można przeprowadzić podczas użytkowania lub produkcji urządzenia.
• [C-1-9] Musi mieć odchylenie standardowe obliczone dla każdej osi na podstawie próbek zebranych w ciągu co najmniej 3 sekund z najwyższą częstotliwością próbkowania nie większą niż 1, 5 µT; powinno mieć odchylenie standardowe nie większe niż 0, 5 µT.
• NALEŻY zastosować czujnik TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] W przypadku obecnych i nowych urządzeń z Androidem MOCNO POLECAMY wdrożenie czujnika TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Jeśli implementacje urządzeń zawierają 3-osiowy magnetometr, akcelerometr i 3-osiowy żyroskop, muszą spełniać te wymagania:

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

Jeśli implementacje urządzeń zawierają 3-osiowy magnetometr i akcelerometr, muszą:

• MOŻNA zaimplementować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

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

7.3.3. GPS

Implementacje na urządzeniu:

• [C-SR] Zdecydowanie zalecamy dodanie odbiornika GPS/GNSS.

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

• [C-1-1] Musi obsługiwać dane wyjściowe lokalizacji z częstotliwością co najmniej 1 Hz, gdy zostaną przesłane za pomocą LocationManager#requestLocationUpdate.
• [C-1-2] Musi być możliwe określenie lokalizacji w warunkach otwartego nieba (silne sygnały, pomijalny wielościeżkowy sygnał, HDOP < 2) w ciągu 10 sekund (szybki czas do pierwszego wyznaczenia pozycji) po połączeniu z internetem o szybkości co najmniej 0,5 Mb/s. Wymaganie to jest zwykle realizowane przez użycie jakiejś formy wspomaganego lub przewidywanego GPS-u/GNSS w celu zminimalizowania czasu ustalania pozycji przez GPS-a/GNSS (dane wspomagania obejmują czas odniesienia, lokalizację odniesienia i ephemeridy satelity/zegar).
  • [C-1-6] Po obliczeniu lokalizacji implementacje urządzeń MUSZĄ określić lokalizację na otwartym niebie w ciągu 5 sekund od ponownego uruchomienia żądań lokalizacji, maksymalnie do godziny od początkowego obliczenia lokalizacji, nawet jeśli kolejne żądanie zostanie wysłane bez połączenia danych lub po wyłączeniu i ponownie włączeniu urządzenia.

• W warunkach otwartego nieba po określeniu lokalizacji, w stanie nieruchomym lub w ruchu z przyspieszeniem poniżej 1 metra na sekundę kwadratową:

  • [C-1-3] W co najmniej 95% czasu urządzenie MUSI być w stanie określić lokalizację z dokładnością do 20 metrów, a szybkość z dokładnością do 0, 5 metra na sekundę.
  • [C-1-4] MUSI jednocześnie śledzić i przekazywać informacje za pomocą GnssStatus.Callback co najmniej 8 satelitów z jednej konstelacji.
  • POWINNA być w stanie śledzić jednocześnie co najmniej 24 satelity z różnych konstelacji (np. GPS + co najmniej jeden z Glonas, BeiDou, Galileo).
  • [C-SR] MOCNO POLECAMY, aby podczas połączenia alarmowego nadal dostarczać normalne dane o lokalizacji GPS/GNSS za pomocą interfejsów API dostawcy lokalizacji GNSS.
  • [C-SR] MOCNO zalecamy raportowanie pomiarów GNSS ze wszystkich śledzonych konstelacji (jak podano w wiadomościach GnssStatus), z wyjątkiem SBAS.
  • [C-SR] MOCNO zalecamy raportowanie AGC i częstości pomiaru GNSS.
  • [C-SR] MOCNO POLECAMY raportowanie wszystkich szacunków dokładności (w tym kierunku, prędkości i pionowości) w ramach każdej lokalizacji GPS/GNSS.
  • [C-SR] MOCNO zalecamy zgłaszanie pomiarów GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
  • [C-SR] MOCNO zaleca się zgłaszanie pseudozakresów i szybkości GNSS, które w warunkach otwartego nieba po określeniu lokalizacji, w stanie spoczynku lub w ruchu z przyspieszeniem poniżej 0,2 metra na sekundę kwadratową, wystarczają do obliczenia pozycji z dokładnością do 20 metrów i szybkości z dokładnością do 0,2 metra na sekundę w co najmniej 95% czasu.

7.3.4. Żyroskop

Implementacje na urządzeniu:

• [C-SR] MOCNO POLECAMY uwzględnienie czujnika żyroskopu, chyba że urządzenie ma też 3-osiowy akcelerometr.

Jeśli implementacja urządzenia obejmuje 3-osiowy żyroskop:

• [C-1-1] Musisz mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz.
• [C-1-2] NALEŻY zaimplementować czujnik TYPE_GYROSCOPE. BARDZO ZALECAMY też zaimplementowanie czujnika TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-4] Rozdzielczość musi wynosić co najmniej 12 bitów, a najlepiej 16 bitów.
• [C-1-5] MUSI być z kompensacją temperatury.
• [C-1-6] MUSI być skalibrowany i skompensowany podczas użytkowania oraz zachowywać parametry kompensacji po ponownym uruchomieniu urządzenia.
• [C-1-7] Wariancja musi być mniejsza niż 1e-7 rad^2 / s^2 na Hz (wartość na Hz lub rad^2 / s). Wartość odchylenia może się zmieniać wraz z częstotliwością próbkowania, ale MUSI być ograniczona do tej wartości. Inaczej mówiąc, jeśli zmierzymy odchylenie standardowe żyroskopu przy częstotliwości próbkowania 1 Hz, nie powinno ono przekraczać 1 e-7 rad^2/s^2.
• [SR] Błąd kalibracji powinien być mniejszy niż 0,01 rad/s, gdy urządzenie jest nieruchome w temperaturze pokojowej.
• Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.

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

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

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

• [C-3-1] OBOWIĄZKOWO stosować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR] Zdecydowanie zalecamy wdrożenie czujnika złożonego TYPE_GAME_ROTATION_VECTOR.

7.3.5. barometr;

Implementacje na urządzeniu:

• [C-SR] MOCNO zalecamy uwzględnienie barometru (czujnika ciśnienia otoczenia).

Jeśli implementacja urządzenia zawiera barometr, musi:

• [C-1-1] MUSISZ wdrożyć i zgłosić czujnik TYPE_PRESSURE.
• [C-1-2] MUSI być w stanie przesyłać zdarzenia z częstotliwością co najmniej 5 Hz.
• [C-1-3] MUSI być z kompensacją temperatury.
• [SR] ZALECAMY, aby urządzenie było w stanie raportować pomiary ciśnienia w zakresie 300–1100 hPa.
• Powinien mieć bezwzględną dokładność 1 hPa.
• Powinien mieć dokładność względną 0,12 hPa w zakresie 20 hPa (co odpowiada dokładności około 1 m przy zmianie wysokości około 200 m na poziomie morza).

7.3.6. Termometr

Implementacje na urządzeniu:

• MOŻE zawierać termometr otoczenia (czujnik temperatury).
• MOŻE, ale NIE MUSI zawierać czujnika temperatury procesora.

Jeśli implementacje urządzeń zawierają termometr otoczenia (czujnik temperatury), muszą:

• [C-1-1] MUSI być zdefiniowany jako SENSOR_TYPE_AMBIENT_TEMPERATURE i MUSI mierzyć temperaturę otoczenia (temperaturę w pomieszczeniu lub kabinie pojazdu), w której użytkownik korzysta z urządzenia, w stopniach Celsjusza.
• [C-1-2] MUSI być zdefiniowany jako SENSOR_TYPE_TEMPERATURE.
• [C-1-3] NALEŻY zmierzyć 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

• Implementacje urządzeń MOGĄ zawierać fotometr (czujnik jasności otoczenia).

7.3.8. Czujnik zbliżeniowy

• Urządzenia mogą być wyposażone w czujnik zbliżeniowy.

Jeśli implementacja urządzenia obejmuje czujnik zbliżeniowy, urządzenie:

• [C-1-1] NALEŻY mierzyć odległość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI być zorientowany tak, aby wykrywać obiekty w pobliżu ekranu, ponieważ głównym celem tego typu czujnika jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy w dowolnej innej orientacji, nie może być on dostępny za pomocą tego interfejsu API.
• [C-1-2] Musi mieć co najmniej 1 bita dokładności.

7.3.9. Czujniki o wysokiej wierności

Jeśli implementacje urządzeń zawierają zestaw czujników o wyższej jakości, zgodnie z definicją w tej sekcji, i są dostępne dla aplikacji innych firm, muszą:

• [C-1-1] Identyfikator musi być podany za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

Jeśli implementacje na urządzeniu deklarują android.hardware.sensor.hifi_sensors, to:

• [C-2-1] Musi zawierać czujnik TYPE_ACCELEROMETER, który:

  • Zakres pomiarowy musi mieścić się w zakresie od -8 g do +8 g. Zaleca się, aby zakres pomiarowy mieścił się w zakresie od -16 g do +16 g.
  • Rozdzielczość pomiaru MUSI wynosić co najmniej 2048 LSB/g.
  • Częstotliwość pomiaru musi wynosić co najmniej 12,5 Hz.
  • Musi mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz. Zaleca się obsługę interfejsu SensorDirectChannel RATE_VERY_FAST.
  • Szum pomiarowy nie może przekraczać 400 μg/√Hz.
  • MUSI implementować niebudzącą formę tego czujnika z możliwością buforowania co najmniej 3000 zdarzeń czujnika.
  • Musisz mieć ustawienie batchingu z poziomem poboru mocy nie większym niż 3 mW.
  • [C-SR] MOCNO zalecamy, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a spektr szumu białego mieścił się w tym paśmie.
  • Przyspieszenie powinno być mniejsze niż 30 μg √Hz przy temperaturze pokojowej.
  • Zmiana stycznej w zależności od temperatury powinna wynosić ≤ +/- 1 mg/°C.
  • USTAWIĆ nieliniowości linii dopasowania najlepszego do danych na poziomie ≤ 0,5% oraz zmianę czułości w zależności od temperatury na poziomie ≤ 0,03%/°C.
  • W zakresie temperatury pracy urządzenia czułość na osi poprzecznej powinna wynosić mniej niż 2,5%, a jej zmienność – mniej niż 0,2%.

• [C-2-2] Musisz mieć TYPE_ACCELEROMETER_UNCALIBRATED, który spełnia te same wymagania dotyczące jakości co TYPE_ACCELEROMETER.

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

  • Zakres pomiarowy musi wynosić co najmniej -1000 do +1000 dps.
  • Rozdzielczość pomiaru MUSI wynosić co najmniej 16 LSB/dps.
  • Częstotliwość pomiaru musi wynosić co najmniej 12,5 Hz.
  • Musi mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz. Zaleca się obsługę interfejsu SensorDirectChannel RATE_VERY_FAST.
  • Szum pomiarowy nie może być większy niż 0,014°/s/√Hz.
  • [C-SR] MOCNO zalecamy, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a spektr szumu białego mieścił się w tym paśmie.
  • W temperaturze pokojowej szybkość losowego spaceru powinna wynosić mniej niż 0,001 °/s √Hz.
  • Zmiana przesunięcia w zależności od temperatury powinna wynosić ≤ ± 0,05°/s/°C.
  • Zmiana czułości w zależności od temperatury powinna wynosić ≤ 0,02% / °C.
  • Współczynnik nieliniowości linii najlepszego dopasowania powinien być mniejszy niż 0,2%.
  • gęstość szumów powinna wynosić ≤ 0,007 °/s/√Hz;
  • Błąd kalibracji powinien być mniejszy niż 0,002 rad/s w zakresie temperatury 10–40 °C, gdy urządzenie jest nieruchome.
  • Czułość na przyspieszenie powinna być mniejsza niż 0,1°/s/g.
  • W zakresie temperatury pracy urządzenia czułość na osi poprzecznej powinna wynosić < 4,0%, a jej zmienność < 0,3%.

• [C-2-4] Musisz mieć TYPE_GYROSCOPE_UNCALIBRATED, który spełnia te same wymagania jakościowe co TYPE_GYROSCOPE.

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

  • Zakres pomiarowy musi wynosić co najmniej -900 do +900 μT.
  • Rozdzielczość pomiaru musi wynosić co najmniej 5 LSB/uT.
  • Częstotliwość pomiaru MUSI wynosić co najmniej 5 Hz.
  • Maksymalna częstotliwość pomiaru musi wynosić co najmniej 50 Hz.
  • Szum pomiarowy nie może przekraczać 0,5 uT.

• [C-2-6] Musisz mieć TYPE_MAGNETIC_FIELD_UNCALIBRATED, który spełnia te same wymagania dotyczące jakości co TYPE_GEOMAGNETIC_FIELD, a dodatkowo:

  • MUSI implementować niebudzącą formę tego czujnika z możliwością buforowania co najmniej 600 zdarzeń czujnika.
  • [C-SR] MOCNO ZALECAMY stosowanie widma szumu białego w zakresie od 1 Hz do co najmniej 10 Hz, gdy częstotliwość raportowania wynosi 50 Hz lub więcej.

• [C-2-7] MUSI mieć czujnik TYPE_PRESSURE, który:

  • Zakres pomiarowy musi wynosić co najmniej 300–1100 hPa.
  • Musi mieć rozdzielczość pomiaru co najmniej 80 LSB/hPa.
  • Częstotliwość pomiaru MUSI wynosić co najmniej 1 Hz.
  • Maksymalna częstotliwość pomiaru musi wynosić co najmniej 10 Hz.
  • Szum pomiarowy nie może przekraczać 2 Pa/√Hz.
  • NALEŻY wdrożyć niebudzącą formę tego czujnika z możliwością buforowania co najmniej 300 zdarzeń czujnika.
  • Musisz mieć ustawienie poboru mocy w ramach przetwarzania w partiach nie większe niż 2 mW.
• [C-2-8] MUSISZ mieć czujnik TYPE_GAME_ROTATION_VECTOR.
• [C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:
  • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
• [C-2-10] MUSI mieć czujnik TYPE_STEP_DETECTOR, który:
  • NALEŻY wdrożyć tę funkcję w formie niewybudzającej z możliwością buforowania co najmniej 100 zdarzeń czujnika.
  • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
  • Musi mieć zużycie energii na etapie grupowania 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 w stanie spoczynku i 1,5 mW w ruchu.
• [C-2-12] MUSI mieć czujnik TILT_DETECTOR, który:
  • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
• [C-2-13] Czas stempla zdarzeń tego samego zdarzenia fizycznego zarejestrowanego przez akcelerometr, żyroskop i magnetometr MUSI mieścić się w zakresie 2, 5 ms. Sygnatura czasowa zdarzenia zarejestrowanego przez akcelerometr i żyroskop w ramach tego samego zdarzenia fizycznego POWINNA mieścić się w zakresie 0,25 ms.
• [C-2-14] Musisz mieć sygnatury czasowe zdarzeń czujnika żyroskopu oparte na tej samej podstawie czasowej co podsystem kamery i z dokładnością do 1 milisekundy.
• [C-2-15] NALEŻY przesyłać próbki do aplikacji w ciągu 5 milisekund od momentu, gdy dane są dostępne na dowolnym z wymienionych powyżej czujników fizycznych.
• [C-2-16] Podczas korzystania z dowolnej kombinacji tych czujników: zużycie energii nie może być większe niż 0,5 mW w stanie spoczynku i 2,0 mW w ruchu:
  • 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ć co najmniej 100 miejsc na dane w buforze.

Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje to moc pobieraną przez cały łańcuch czujników: czujnik, wszelkie układy pomocnicze, dedykowany system przetwarzania czujników itp.

Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników, urządzenia te:

• [C-3-1] NALEŻY prawidłowo zadeklarować obsługę typów kanałów bezpośrednich i poziomu stawek raportowania bezpośredniego za pomocą interfejsu API isDirectChannelTypeSupported i getHighestDirectReportRateLevel.
• [C-3-2] Musi obsługiwać co najmniej 1 z 2 typów bezpośrednich kanałów czujników we wszystkich czujnikach, które deklarują obsługę bezpośredniego kanału czujnika.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• Powinien obsługiwać raportowanie zdarzeń za pomocą kanału bezpośredniego czujnika w przypadku głównego czujnika (wersja nieobsługująca funkcji budzenia) o tych typach:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Czujniki biometryczne

Więcej informacji o pomiarach bezpieczeństwa odblokowywania biometrycznego znajdziesz w dokumentacji pomiaru bezpieczeństwa zabezpieczeń biometrycznych.

Jeśli implementacja urządzenia obejmuje bezpieczny ekran blokady, musi:

• NALEŻY użyć czujnika biometrycznego

Czujniki biometryczne można podzielić na silne, słabe i wygodne na podstawie współczynników akceptacji oszustwa i podmiany oraz bezpieczeństwa łańcucha przetwarzania danych biometrycznych. Ta klasyfikacja określa możliwości interfejsu czujnika biometrycznego w połączeniu z platformą i aplikacjami firm zewnętrznych. Sensory są domyślnie klasyfikowane jako Wygodne i muszą spełniać dodatkowe wymagania opisane poniżej, aby można je było zaklasyfikować jako Słabe lub Mocne. Zarówno słabe, jak i mocne dane biometryczne zyskują dodatkowe możliwości, opisane poniżej.

Aby udostępnić czujnik biometryczny aplikacjom innych firm i w ramach implementacji na urządzeniach:

• [C-0-1] MUSI spełniać wymagania dotyczące silnego lub słabego uwierzytelnienia biometrycznego zgodnie z definicją w tym dokumencie.

Aby zezwolić aplikacjom innych firm na dostęp do kluczy w magazynie kluczy:

• [C-0-2] MUSI spełniać wymagania dotyczące silnego zdefiniowane w tym dokumencie.

Dodatkowo:

• [C-0-3] Musi być połączone z wyraźnym działaniem potwierdzającym (np. naciśnięciem przycisku), jeśli silna metoda biometryczna jest bierna (np. twarz lub tęczówka, gdzie nie ma wyraźnego sygnału o zamiarze użytkownika).
  • [C-SR] W przypadku działania potwierdzenia dla biometryki pasywnej MOCNO zaleca się zabezpieczenie w taki sposób, aby nie można było go sfałszować w systemie operacyjnym lub jądrze. Oznacza to na przykład, że działanie potwierdzenia oparte na przycisku fizycznym jest kierowane przez pin wejścia/wyjścia ogólnego przeznaczenia (GPIO) tylko do odczytu elementu bezpiecznego (SE), który nie może być sterowany w żaden inny sposób niż przez naciśnięcie przycisku fizycznego.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako wygodność, muszą:

• [C-1-1] Wskaźnik fałszywych akceptacji musi być mniejszy niż 0,002%.
• [C-1-2] NALEŻY poinformować, że ten tryb może być mniej bezpieczny niż silny kod PIN, wzór lub hasło, oraz wyraźnie wymienić zagrożenia związane z jego włączeniem, jeśli wskaźnik akceptacji podszycia się pod kogoś innego i podstępnego włamania jest wyższy niż 7%.
• [C-1-3] W przypadku weryfikacji biometrycznej po 5 nieudanych próbach należy ograniczyć liczbę prób do 30 sekund. Nieudana próba to próba o odpowiedniej jakości obrazu (BIOMETRIC_ACQUIRED_GOOD), która nie pasuje do zarejestrowanych danych biometrycznych.
• [C-1-4] NALEŻY uniemożliwić dodawanie nowych danych biometrycznych bez uprzedniego ustanowienia łańcucha zaufania, prosząc użytkownika o potwierdzenie istniejących lub dodanie nowych danych logowania na urządzeniu (kod PIN, wzór lub hasło) chronionych przez TEE. W ramach implementacji projektu Android Open Source udostępniono mechanizm umożliwiający wykonanie tej czynności.
• [C-1-5] NALEŻY całkowicie usunąć wszystkie dane biometryczne umożliwiające identyfikację użytkownika, gdy jego konto zostanie usunięte (w tym przywracanie do ustawień fabrycznych).
• [C-1-6] MUSI obsługiwać indywidualną flagę dla danego elementu biometrycznego (np. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE lub DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] W przypadku nowych urządzeń z Androidem w wersji 10 lub nowszej należy prosić użytkownika o polecane uwierzytelnienie podstawowe (np.kod PIN, wzór lub hasło) co 24 godziny lub rzadziej, a w przypadku urządzeń z Androidem w wersji 10 lub nowszej należy prosić użytkownika o polecane uwierzytelnienie podstawowe (np. kod PIN, wzór lub hasło) co 24 godziny lub rzadziej.

• [C-1-8] NALEŻY poprosić użytkownika o podanie danych uwierzytelniania podstawowego (np. kodu PIN, wzoru lub hasła) po wykonaniu jednej z tych czynności:

  • 4-godzinny okres bezczynności LUB
  • 3 nieudane próby uwierzytelnienia biometrycznego.
  • Po potwierdzeniu danych logowania na urządzeniu okres bezczynności i licznik nieudanych prób uwierzytelniania są resetowane.

  Wymagania C-1-8 nie dotyczą urządzeń, które są aktualizowane z wersji Androida 1.

• [C-SR] MOCNO ZALECANA wartość odsetka błędów odrzucenia na poziomie poniżej 10%, zmierzonego na urządzeniu.

• [C-SR] W przypadku każdej zarejestrowanej metody biometrycznej ZALECAMY, aby opóźnienie było krótsze niż 1 s (mierzone od momentu wykrycia danych biometrycznych do odblokowania ekranu).

Jeśli implementacje na urządzeniu chcą traktować czujnik biometryczny jako słaby, muszą:

• [C-2-1] MUSI spełniać wszystkie wymagania dotyczące wygody wymienione powyżej, z wyjątkiem [C-1-2].
• [C-2-2] Procentowy wskaźnik akceptacji spoofów i podróbek nie może być wyższy niż 20%.
• [C-2-3] MUSISZ mieć implementację magazynu kluczy opartą na sprzęcie i wykonywać dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza przestrzenią użytkownika lub jądra Androida, takim jak Trusted Execution Environment (TEE), lub na chipie z bezpiecznym kanałem do odizolowanego środowiska wykonawczego.
• [C-2-4] WSZYSTKIE dane identyfikacyjne MUSZĄ być zaszyfrowane i uwierzytelnione kryptograficznie, tak aby nie mogły być pobierane, odczytywane ani zmieniane poza izolowanym środowiskiem wykonania lub za pomocą chipa z bezpiecznym kanałem do izolowanego środowiska wykonania zgodnie z dokumentacją w wytycznych dotyczących implementacji na stronie projektu Android Open Source.
• [C-2-5] W przypadku uwierzytelniania lub rejestrowania danych biometrycznych na podstawie kamery:
  • Musi obsługiwać kamerę w taki sposób, aby uniemożliwić odczytywanie lub zmienianie ramek poza izolowanym środowiskiem wykonywania. Może to być też chip z bezpiecznym kanałem do izolowanego środowiska wykonywania.
  • W przypadku rozwiązań z jedną kamerą RGB ramki kamery MOGĄ być odczytywane poza izolowanym środowiskiem wykonania, aby obsługiwać operacje takie jak podgląd w celu rejestracji, ale NIE MOGĄ być zmieniane.
• [C-2-6] NIE WOLNO zezwalać aplikacjom innych firm na rozróżnianie poszczególnych rejestracji biometrycznych.
• [C-2-7] NIE MOŻESZ zezwolić na dostęp do niezaszyfrowanych danych biometrycznych umożliwiających identyfikację lub danych z nich pochodzących (np. danych wbudowanych) procesorowi aplikacji poza kontekstem TEE.

• [C-2-8] MUSI zawierać bezpieczny kanał przetwarzania, który uniemożliwia wstrzykiwanie danych bezpośrednio w system operacyjny lub jądro w celu fałszywego uwierzytelnienia jako użytkownik.

  Jeśli implementacje urządzeń zostały już uruchomione w starszej wersji Androida i nie można ich dostosować do wymogu C-2-8 za pomocą aktualizacji oprogramowania systemowego, MOŻNA je zwolnić z tego wymogu.

Jeśli implementacje na urządzeniach chcą traktować czujnik biometryczny jako silny, muszą:

• [C-3-1] MUSI spełniać wszystkie wymagania dotyczące słabej jakości. Uaktualnianie urządzeń z wcześniejszej wersji Androida nie jest zwolnione z obowiązku stosowania C-2-7.
• [C-3-2] Procentowy wskaźnik akceptacji spoof i imposter nie może być wyższy niż 7%.
• [C-3-3] NALEŻY wymagać od użytkownika użycia zalecanego głównego uwierzytelnienia (np. kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny.

7.3.12. Czujnik postawy

Implementacje na urządzeniu:

• MOŻE obsługiwać czujnik postawy z 6 stopniami swobody.

Jeśli implementacje urządzeń obsługują czujnik postawy z 6 stopniami swobody, mogą:

• [C-1-1] MUSISZ wdrożyć i zgłosić czujnik TYPE_POSE_6DOF.
• [C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.

7.4. Łączność z danymi

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 nawiązywaniem połączeń głosowych i wysyłaniem SMS-ów za pomocą sieci GSM lub CDMA. Podczas gdy te połączenia głosowe mogą być przełączane pakietowo, w przypadku Androida są one traktowane niezależnie od połączeń danych, które mogą być stosowane w ramach tej samej sieci. Innymi słowy, funkcje i interfejsy API „telefonii” w Androidzie odnoszą się wyłącznie do połączeń głosowych i SMS-ów. Na przykład implementacje urządzeń, które nie mogą nawiązywać połączeń ani wysyłać/odbierać SMS-ów, nie są uważane za urządzenia telefoniczne, niezależnie od tego, czy do łączności danych używają sieci komórkowej.

• Android MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami, które nie są telefonami.

Jeśli implementacje urządzeń obejmują telefonię GSM lub CDMA, muszą:

• [C-1-1] NALEŻY zadeklarować flagę funkcji android.hardware.telephony i inne flagi podfunkcji zgodnie z technologią.
• [C-1-2] Należy w pełni obsługiwać interfejs API dla danej technologii.

Jeśli implementacje urządzeń nie obejmują sprzętu telefonicznego, nie mogą:

• [C-2-1] NALEŻY wdrożyć pełne interfejsy API jako no-ops.

Jeśli implementacje urządzeń obsługują karty eUICC lub eSIM/wbudowane karty SIM i zawierają zastrzeżoną technologię, która umożliwia udostępnienie funkcji eSIM zewnętrznym deweloperom, muszą:

• [C-3-1] Musisz w pełni wdrożyć EuiccManager API.

7.4.1.1. Zgodność z blokowaniem numeru

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

• [C-1-1] MUST include number blocking support
• [C-1-2] NALEŻY w pełni zaimplementować BlockedNumberContract i odpowiednie API zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-3] Musi blokować wszystkie połączenia i wiadomości z numeru telefonu w ramach usługi BlockedNumberProvider bez interakcji z aplikacją. Jedynym wyjątkiem jest tymczasowe odblokowanie blokady numeru zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-4] W przypadku zablokowanego połączenia NIE MOŻESZ zapisywać danych w rejestratorze połączeń platformy.
• [C-1-5] NIE MOŻESZ napisać do dostawcy usług telefonicznych w sprawie zablokowanej wiadomości.
• [C-1-6] NALEŻY wdrożyć interfejs zarządzania zablokowanymi numerami, który otwiera się za pomocą intencji zwracanej przez metodę TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] Nie należy zezwalać użytkownikom dodatkowym na wyświetlanie ani edytowanie zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że użytkownik główny ma pełną kontrolę nad usługami telefonicznymi, które są dostępne w jednym egzemplarzu na urządzeniu. Wszystkie elementy interfejsu związane z blokowaniem MUSZĄ być ukryte dla użytkowników dodatkowych, a lista zablokowanych użytkowników MUSI być nadal uwzględniana.
• Blokowane numery NALEŻY przenieść do dostawcy, gdy urządzenie zostanie zaktualizowane do Androida 7.0.

7.4.1.2. Interfejs Telecom API

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

• [C-1-1] Musi obsługiwać interfejsy API ConnectionService opisane w pakiecie SDK.
• [C-1-2] NALEŻY wyświetlić nowe połączenie przychodzące i umożliwić użytkownikowi zaakceptowanie lub odrzucenie połączenia przychodzącego, gdy użytkownik jest w trakcie rozmowy z inną osobą w aplikacji innej firmy, która nie obsługuje funkcji wstrzymania określonej w CAPABILITY_SUPPORT_HOLD.
• [C-1-3] Aplikacja MUSI implementować interfejs InCallService.

• [C-SR] MOCNO ZALECAMY powiadomienie użytkownika, że odebranie połączenia spowoduje przerwanie 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 przerwanie innego połączenia.

• [C-SR] MOCNO POLECAMY wstępne załadowanie domyślnej aplikacji do wybierania numerów, która wyświetla w dzienniku połączeń wpis i nazwę aplikacji innej firmy, gdy aplikacja innej firmy ustawia klucz dodatkowych informacji EXTRA_LOG_SELF_MANAGED_CALLS w kluczu PhoneAccount na true.

• [C-SR] ZALECAMY obsługę zdarzeń KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK słuchawek na podczerwień w przypadku interfejsów android.telecom w ten sposób:
  • Po krótkim naciśnięciu kluczowego zdarzenia podczas trwającego połączenia zostanie wykonane wywołanie Connection.onDisconnect().
  • Wywołanie Connection.onAnswer() po wykryciu krótkiego naciśnięcia klawisza podczas połączenia przychodzącego.
  • Wywołanie Connection.onReject(), gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia.
  • Przełącz stan wyciszenia CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementacje na urządzeniu:

• POWINNA obejmować obsługę co najmniej jednej formy 802.11.

Jeśli implementacje urządzeń obejmują obsługę 802.11 i udostępniają tę funkcję aplikacji innych firm, muszą:

• [C-1-1] MUSISZ zaimplementować odpowiedni interfejs API Androida.
• [C-1-2] MUST report the hardware feature flag android.hardware.wifi.
• [C-1-3] MUSISZ zaimplementować interfejs multicast API 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 implementacji urządzeń z Androidem TV nawet w stanie gotowości.
• [C-1-5] Nie należy traktować wywołania metody interfejsu API WifiManager.enableNetwork() jako wystarczającej wskazówki do przełączenia obecnie aktywnego Network, który jest używany domyślnie do ruchu aplikacji i zwracany przez metody interfejsu API ConnectivityManager, takie jak getActiveNetwork i registerDefaultNetworkCallback. Innymi słowy, mogą wyłączyć dostęp do internetu przez dowolnego innego dostawcę sieci (np. danych komórkowych), jeśli potwierdzą, że sieć Wi-Fi zapewnia dostęp do internetu.
• [C-1-6] MOCNO zalecamy, aby po wywołaniu metody interfejsu API ConnectivityManager.reportNetworkConnectivity() ponownie sprawdzić dostęp do internetu na urządzeniu Network.Jeśli po tej weryfikacji okaże się, że bieżąca sieć Network nie zapewnia już dostępu do internetu, należy przejść na dowolną inną dostępną sieć (np. mobilną) zapewniającą dostęp do internetu.
• [C-SR] MOCNO ZALECAMY losowanie adresu MAC źródła i numeru sekwencji ramek żądań sondowania raz na początku każdego skanowania, gdy STA jest odłączony.
  • Każda grupa ramek żądania sondowania, która obejmuje jedno skanowanie, POWINNA używać jednego stałego adresu MAC (NIE NALEŻY losować adresu MAC w połowie skanowania).
  • Numer sekwencyjny żądania sondowania POWINIEN być iterowany normalnie (sekwencyjnie) między żądaniami sondowania w skanowaniu.
  • Numer porządkowy żądania sondowania powinien być losowo generowany między ostatnim żądaniem sondowania w ramach jednego skanowania a pierwszym żądaniem sondowania w ramach następnego skanowania.
• [C-SR] MOCNO ZALECANA, gdy STA jest odłączony, aby zezwolić tylko na te elementy w ramkach żądania sondy:
  • Zestaw parametrów SSID (0)
  • Zestaw parametrów DS (3)

Jeśli implementacje urządzeń obejmują obsługę trybu oszczędzania energii Wi-Fi zgodnie ze standardem IEEE 802.11, urządzenia te:

• [C-3-1] Należy wyłączyć tryb oszczędzania energii Wi-Fi, gdy aplikacja uzyska blokadę WIFI_MODE_FULL_HIGH_PERF lub WIFI_MODE_FULL_LOW_LATENCY za pomocą interfejsów API WifiManager.createWifiLock() i WifiManager.WifiLock.acquire(), a blokada jest aktywna.
• [C-3-2] Średni czas oczekiwania w obie strony między urządzeniem a punktem dostępu w trybie Wi-Fi Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) MUSI być krótszy niż czas oczekiwania w trybie Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] ZALECAMY zminimalizowanie opóźnień w transmisji Wi-Fi, gdy zostanie uzyskany i zacznie obowiązywać blokada o niskim opóźnieniu (WIFI_MODE_FULL_LOW_LATENCY).

Jeśli implementacje urządzeń obsługują Wi-Fi i korzystają z niego do skanowania lokalizacji, muszą:

• [C-2-1] NALEŻY zapewnić użytkownikowi możliwość włączenia lub wyłączenia wartości odczytanej za pomocą metody interfejsu API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementacje na urządzeniu:

• NALEŻY uwzględnić obsługę Wi-Fi Direct (Wi-Fi peer-to-peer).

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Direct, urządzenia te:

• [C-1-1] NALEŻY zaimplementować odpowiednie interfejsy API Androida zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] MUST report the hardware feature android.hardware.wifi.direct.
• [C-1-3] MUSI obsługiwać zwykłe działanie Wi-Fi.
• [C-1-4] MUSI obsługiwać operacje Wi-Fi i Wi-Fi Direct jednocześnie.

7.4.2.2. Konfiguracja połączenia bezpośredniego z tunelowaniem Wi-Fi

Implementacje na urządzeniu:

• POWINIEN zawierać obsługę konfiguracji tunelowanej bezpośredniej łączności Wi-Fi (TDLS) zgodnie z opisem w dokumentacji pakietu Android SDK.

Jeśli implementacje urządzeń obsługują TDLS, a TDLS jest włączone przez interfejs API WiFiManager, urządzenia te:

• [C-1-1] MUSI deklarować obsługę TDLS za pomocą WifiManager.isTdlsSupported.
• NALEŻY używać TDLS tylko wtedy, gdy jest to możliwe i korzystne.
• Powinien zawierać heurystyki i NIE używać TDLS, gdy jego wydajność może być gorsza niż w przypadku korzystania z punktu dostępu Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implementacje na urządzeniu:

• POWINIEN zawierać obsługę Wi-Fi Aware.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i udostępniają tę funkcję aplikacjom innych firm, muszą:

• [C-1-1] NALEŻY zaimplementować interfejsy API WifiAwareManager zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] NALEŻY zadeklarować flagę funkcji android.hardware.wifi.aware.
• [C-1-3] MUSI obsługiwać operacje Wi-Fi i Wi-Fi Aware jednocześnie.
• [C-1-4] NALEŻY losowo generować adres interfejsu zarządzania Wi-Fi Aware w odstępach nie dłuższych niż 30 minut i zawsze, 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 oraz udostępniają te funkcje aplikacjom innych firm, muszą:

• [C-2-1] NALEŻY zaimplementować interfejsy API wykrywania z uwzględnieniem lokalizacji: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm i onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Implementacje na urządzeniu:

• POWINIEN zawierać obsługę Wi-Fi Passpoint.

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Passpoint, urządzenia te:

• [C-1-1] NALEŻY zaimplementować interfejsy API WifiManager związane z Passpoint 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. Generic Advertisement Service (GAS) i Access Network Query Protocol (ANQP).

Jeśli implementacja urządzenia nie obsługuje Wi-Fi Passpoint:

• [C-2-1] Implementacja interfejsów API WifiManager związanych z Passpoint MUSI zgłaszać błąd UnsupportedOperationException.

7.4.2.5. Lokalizacja Wi-Fi (czas błądzenia Wi-Fi – RTT)

Implementacje na urządzeniu:

• POWINIEN zawierać obsługę lokalizacji Wi-Fi.

Jeśli implementacje urządzeń obejmują obsługę lokalizacji Wi-Fi i udostępniają tę funkcję aplikacjom innych firm, muszą:

• [C-1-1] NALEŻY zaimplementować interfejsy API WifiRttManager zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] NALEŻY zadeklarować flagę funkcji android.hardware.wifi.rtt.
• [C-1-3] NALEŻY losowo zmienić źródłowy adres MAC w przypadku każdego wysyłania RTT, które jest wykonywane, gdy interfejs Wi-Fi, na którym jest wykonywane RTT, nie jest powiązany z punktem dostępu.

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

Implementacje na urządzeniu:

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

Jeśli implementacje urządzeń obsługują funkcję przenoszenia obsługi Wi-Fi keepalive i udostępniają tę funkcję aplikacjom innych firm, muszą:

• [C-1-1] Musi obsługiwać interfejs API SocketKeepAlive.

• [C-1-2] Musi obsługiwać co najmniej 3 jednoczesne gniazda utrzymywania połączenia przez Wi-Fi i co najmniej 1 gniazdo utrzymywania połączenia przez sieć komórkową.

Jeśli implementacje urządzeń nie obsługują przenoszenia funkcji utrzymywania połączenia Wi-Fi, nie:

• [C-2-1] NALEŻY zwrócić ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protokół Device Provisioning Protocol)

Implementacje na urządzeniu:

• NALEŻY uwzględnić obsługę Wi-Fi Easy Connect (DPP).

Jeśli implementacje urządzeń obejmują obsługę funkcji Wi-Fi Easy Connect i udostępniają tę funkcję aplikacjom innych firm, muszą:

• [C-1-1] MUSISZ zaimplementować interfejsy API Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent zgodnie z opisem w dokumentacji pakietu SDK.
• [C-1-2] Metoda WifiManager#isEasyConnectSupported() MUSI zwracać wartość true.

7.4.3. Bluetooth

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

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

Jeśli implementacje urządzeń obsługują HFP, A2DP i AVRCP, to:

• NALEŻY obsługiwać co najmniej 5 połączonych urządzeń.

Jeśli implementacje na urządzeniu deklarują funkcję android.hardware.vr.high_performance, muszą:

• [C-1-1] MUSI obsługiwać Bluetooth 4.2 i Bluetooth LE Data Length Extension.

Android obsługuje Bluetooth i Bluetooth Low Energy.

Jeśli implementacje urządzeń obejmują obsługę Bluetooth i Bluetooth Low Energy, mogą:

• [C-2-1] NALEŻY zadeklarować odpowiednie funkcje platformy (odpowiednio android.hardware.bluetooth i android.hardware.bluetooth_le) oraz zaimplementować interfejsy API platformy.
• NALEŻY zaimplementować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX, HFP itp., w sposób odpowiedni dla danego urządzenia.

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

• [C-3-1] NALEŻY zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
• [C-3-2] NALEŻY włączyć interfejsy API Bluetooth oparte na GATT (ogólnym profilu atrybutów) zgodnie z dokumentacją pakietu SDK i android.bluetooth.
• [C-3-3] NALEŻY podać prawidłową wartość dla BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy logika filtrowania dla klas interfejsu API ScanFilter została zaimplementowana.
• [C-3-4] Musisz podać prawidłową wartość atrybutu BluetoothAdapter.isMultipleAdvertisementSupported(), aby wskazać, czy reklamy o niskiej mocy są obsługiwane.
• NALEŻY obsługiwać przenoszenie logiki filtrowania na układ Bluetooth podczas implementowania interfejsu ScanFilter API.
• NALEŻY obsługiwać przenoszenie skanowania zbiorczego na układ Bluetooth.

• NALEŻY obsługiwać wiele reklam z co najmniej 4 miejscami.

• [SR] ZALECAMY stosowanie limitu czasu adresu prywatnego, który można rozwiązać (RPA), nie dłuższego niż 15 minut, oraz rotowanie adresu po upływie tego czasu, aby chronić prywatność użytkownika.

Jeśli implementacje urządzeń obsługują Bluetooth LE i korzystają z Bluetooth LE do skanowania lokalizacji, mogą:

• [C-4-1] NALEŻY zapewnić użytkownikowi możliwość włączenia lub wyłączenia wartości odczytanej za pomocą interfejsu System API BluetoothAdapter.isBleScanAlwaysAvailable().

Jeśli implementacje urządzeń obejmują obsługę Bluetooth LE i profilu aparatów słuchowych, zgodnie z opisem w artykule Obsługa aparatów słuchowych za pomocą Bluetooth LE, urządzenia te:

• [C-5-1] W funkcji BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) musi zostać zwrócona wartość true.

7.4.4. Komunikacja Near Field Communication

Implementacje na urządzeniu:

• POWINIEN zawierać transceiver i powiązany sprzęt do komunikacji Near Field Communication (NFC).
• [C-0-1] MUSI implementować interfejsy API android.nfc.NdefMessage i android.nfc.NdefRecord, nawet jeśli nie obsługują NFC ani nie deklarują funkcji android.hardware.nfc, ponieważ klasy reprezentują format reprezentacji danych niezależny od protokołu.

Jeśli implementacje urządzeń obejmują sprzęt NFC i planują udostępnić go aplikacjom innych firm, muszą:

• [C-1-1] Musisz podać funkcję android.hardware.nfc z użyciem metody android.content.pm.PackageManager.hasSystemFeature().
• MUSI umożliwiać odczytywanie i zapisywanie komunikatów NDEF za pomocą tych standardów NFC:
• [C-1-2] MUSI być w stanie działać jako czytnik/nagrywarka NFC Forum (zgodnie ze specyfikacją techniczną NFC Forum NFCForum-TS-DigitalProtocol-1.0) za pomocą tych standardów NFC:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Typy tagów NFC Forum 1, 2, 3, 4, 5 (zdefiniowane przez NFC Forum)

• [SR] MOCNO ZALECANA obsługa odczytu i zapisu komunikatów NDEF oraz danych nieprzetworzonych za pomocą tych standardów NFC. Pamiętaj, że chociaż standardy NFC są opisane jako „MOCNO ZALECANE”, w przyszłej wersji definicji zgodności planujemy zmienić je na „WYMAGANE”. Te standardy są opcjonalne w tej wersji, ale będą wymagane w przyszłych wersjach. Zachęcamy, aby istniejące i nowe urządzenia z tą wersją Androida spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.

• [C-1-13] W trybie wykrywania NFC musi sprawdzać wszystkie obsługiwane technologie.

• NALEŻY ustawić tryb wykrywania NFC, gdy urządzenie jest aktywne, ekran jest włączony, a ekran blokady odblokowany.
• POWINIEN odczytywać kody kreskowe i adresy URL (jeśli są zakodowane) produktów z kodami kreskowymi Thinfilm NFC.

Pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku wymienionych powyżej specyfikacji JIS, ISO i forum NFC.

Android obsługuje tryb hosta karty NFC (HCE).

Jeśli implementacje urządzeń zawierają chipset kontrolera NFC obsługujący HCE (dla NfcA lub NfcB) i obsługują routing identyfikatora aplikacji (AID), to:

• [C-2-1] MUST report the android.hardware.nfc.hce feature constant.
• [C-2-2] MUSI obsługiwać interfejsy API NFC HCE zdefiniowane w pakiecie Android SDK.

Jeśli implementacje urządzeń zawierają chipset kontrolera NFC obsługujący HCE dla NfcF i implementują tę funkcję w przypadku aplikacji innych firm, muszą:

• [C-3-1] MUST report the android.hardware.nfc.hcef feature constant.
• [C-3-2] MUSISZ zaimplementować interfejsy API do emulacji karty NfcF zgodnie z definicją w pakiecie SDK Androida.

Jeśli implementacje urządzeń obejmują ogólne wsparcie NFC zgodnie z opisem w tej sekcji i obsługują technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF na MIFARE Classic) w roli czytnika/nagrywarki, to:

• [C-4-1] NALEŻY zaimplementować odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
• [C-4-2] MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() method. Pamiętaj, że nie jest to standardowa funkcja Androida i nie jest wyświetlana jako stała w klasie android.content.pm.PackageManager.

7.4.5. Minimalna funkcjonalność sieci

Implementacje na urządzeniu:

• [C-0-1] MUSI obsługiwać co najmniej jedną formę sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o przepustowości co najmniej 200 kbps. Przykłady technologii, które spełniają to wymaganie, to EDGE, HSPA, EV-DO, 802.11g, Ethernet i PAN Bluetooth.
• NALEŻY również uwzględnić obsługę co najmniej jednego popularnego standardu bezprzewodowego przesyłania danych, takiego jak 802.11 (Wi-Fi), gdy podstawowym połączeniem danych jest standard fizyczny sieci (taki jak Ethernet).
• MOŻNA stosować więcej niż jedną formę łączności danych.
• [C-0-2] MUSI zawierać stos sieciowy IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection, a także natywnych interfejsów API, takich jak gniazda AF_INET6.
• [C-0-3] Protokół IPv6 MUSI być domyślnie włączony.
• MUSISZ zadbać o to, aby komunikacja IPv6 była tak samo niezawodna jak IPv4, na przykład:
  • [C-0-4] W trybie Doze musi być zachowana łączność IPv6.
  • [C-0-5] Ograniczenie szybkości NIE MOŻE spowodować utraty łączności IPv6 w żadnej sieci zgodnej z IPv6, która używa okresów ważności RA wynoszący co najmniej 180 sekund.
• [C-0-6] Musi zapewniać aplikacjom innych firm bezpośrednią łączność IPv6 z siecią, gdy urządzenie jest połączone z siecią IPv6, bez żadnej formy tłumaczenia adresów ani portów na poziomie lokalnym. Zarówno zarządzane interfejsy API, takie jak Socket#getLocalAddress lub Socket#getLocalPort, jak i interfejsy NDK, takie jak getsockname() lub IPV6_PKTINFO, MUSZĄ zwracać adres IP i port, który jest faktycznie używany do wysyłania i odbierania pakietów w sieci.

Wymagany poziom obsługi IPv6 zależy od typu sieci, jak pokazano w tych wymaganiach.

Jeśli implementacje urządzeń obsługują Wi-Fi, to:

• [C-1-1] MUSI obsługiwać stos podwójny i IPv6 w sieci Wi-Fi.

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

• [C-2-1] Musi obsługiwać działanie w ramach podwójnego stosu w sieci Ethernet.

Jeśli implementacje urządzeń obsługują dane komórkowe, to:

• NALEŻY 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ż jeden typ sieci (np. Wi-Fi i komórkową), mogą:

• [C-3-1] MUSI jednocześnie spełniać powyższe wymagania w przypadku każdej sieci, gdy urządzenie jest jednocześnie połączone z większą liczbą typów sieci.

7.4.6. Ustawienia synchronizacji

Implementacje na urządzeniu:

• [C-0-1] Ustawienie głównej automatycznej synchronizacji MUSI być domyślnie włączone, aby metoda getMasterSyncAutomatically() zwracała „true”.

7.4.7. Oszczędzanie danych

Jeśli implementacje urządzeń obejmują połączenie z licznikiem, są:

• [SR] MOCNO ZALECANA funkcja trybu oszczędzania danych.

Jeśli implementacje urządzeń udostępniają tryb oszczędzania danych, muszą:

• [C-1-1] Musi obsługiwać wszystkie interfejsy API z klasy ConnectivityManager zgodnie z opisem w dokumentacji pakietu SDK
• [C-1-2] W ustawieniach musisz udostępnić interfejs, który obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, umożliwiającą użytkownikom dodawanie aplikacji do listy dozwolonych lub usuwanie ich z tej listy.

Jeśli implementacje na urządzeniach nie zapewniają trybu oszczędzania danych, nie spełniają one tych wymagań:

• [C-2-1] W przypadku argumentu ConnectivityManager.getRestrictBackgroundStatus() musi zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED
• [C-2-2] NIE MOŻNA nadawać ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
• [C-2-3] Musisz mieć aktywność, która obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻESZ ją zaimplementować jako no-op.

7.4.8. Secure Elements

Jeśli implementacje urządzeń obsługują interfejs Open Mobile API i dostępne dla aplikacji innych firm elementy zabezpieczeń, mogą:

• [C-1-1] Należy wyliczyć dostępne czytniki Secure Elements, gdy wywoływana jest metoda android.se.omapi.SEService.getReaders().

7.5. Aparaty

Jeśli implementacje urządzeń zawierają co najmniej 1 kamerę, muszą:

• [C-1-1] NALEŻY zadeklarować flagę funkcji android.hardware.camera.any.
• [C-1-2] Aplikacja MUSI mieć możliwość jednoczesnego przydzielenia 3 bitmap RGBA_8888 o rozmiarze równym rozmiarowi obrazów generowanych przez czujnik aparatu o najwyższej rozdzielczości na urządzeniu, gdy kamera jest otwarta na potrzeby podstawowego podglądu i robienia zdjęć.
• [C-1-3] Musisz mieć pewność, że wstępnie zainstalowana domyślna aplikacja do obsługi aparatu, która obsługuje intencje MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE lub MediaStore.ACTION_VIDEO_CAPTURE, jest odpowiedzialna za usunięcie lokalizacji użytkownika w metadanych obrazu przed wysłaniem go do aplikacji odbiorczej, gdy ta nie ma dostępu ACCESS_FINE_LOCATION.

7.5.1. Tylny aparat

Tylny aparat znajduje się po przeciwnej stronie urządzenia niż wyświetlacz, czyli rejestruje obrazy po drugiej stronie urządzenia, tak jak tradycyjny aparat.

Implementacje na urządzeniu:

• NALEŻY umieścić tylny aparat.

Jeśli implementacje urządzeń zawierają co najmniej 1 aparat skierowany do tyłu, muszą:

• [C-1-1] MUST report the feature flag android.hardware.camera and android.hardware.camera.any.
• [C-1-2] Rozdzielczość musi wynosić co najmniej 2 Mpix.
• W sterowniku aparatu powinien być ZREALIZOWANY autofokus sprzętowy lub automatyczny autofokus oprogramowania (niewidoczny dla oprogramowania aplikacji).
• MOŻE mieć sprzęt z ostrzością stałą lub EDOF (rozszerzoną głębią ostrości).
• MOŻE zawierać błysk.

Jeśli aparat ma lampę błyskową:

• [C-2-1] Lampa błyskowa NIE MOŻE być włączona, gdy instancja android.hardware.Camera.PreviewCallback została zarejestrowana na powierzchni podglądu aparatu, chyba że aplikacja wyraźnie włączyła lampę błyskową, włączając atrybuty FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu, ale tylko aplikacji innych firm korzystających z funkcji Camera.PreviewCallback.

7.5.2. Przedni aparat

Przedni aparat to aparat znajdujący się po tej samej stronie urządzenia co wyświetlacz, czyli aparat zwykle używany do robienia zdjęć użytkownikowi, na przykład w przypadku konferencji wideo i podobnych aplikacji.

Implementacje na urządzeniu:

• MOŻE zawierać przedni aparat.

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

• [C-1-1] MUST report the feature flag android.hardware.camera.any and android.hardware.camera.front.
• [C-1-2] Rozdzielczość musi wynosić co najmniej VGA (640 x 480 pikseli).
• [C-1-3] Nie wolno używać przedniego aparatu jako domyślnego aparatu w interfejsie Camera API ani 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 kamery MUSI być odbiciem lustrzanym w orientacji określonej przez aplikację, gdy aplikacja wyraźnie poprosi o obrócenie wyświetlacza aparatu za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation(). Z drugiej strony, podgląd MUSI być odzwierciedlony wzdłuż domyślnej osi poziomej urządzenia, gdy bieżąca aplikacja nie prosi wyraźnie o obrócenie wyświetlacza aparatu za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NIE MOŻESZ odbić lustrzanego obrazu z ostatecznego uchwytu lub strumienia wideo zwracanego do aplikacji w ramach wywołania zwrotnego lub zapisanego w magazynie multimediów.
• [C-1-6] Obraz wyświetlany przez postview MUSI być odbiciem lustrzanym w taki sam sposób jak strumień obrazu z podglądu kamery.
• MOŻE zawierać funkcje (takie jak autofokus czy lampa błyskowa) dostępne dla tylnych kamer zgodnie z opisem w sekcji 7.5.1.

Jeśli implementacje na urządzeniach mogą być obracane przez użytkownika (np. automatycznie za pomocą akcelerometru lub ręcznie za pomocą danych wejściowych użytkownika):

• [C-2-1] Podgląd w kamerze MUSI być odbitykiem poziomym bieżącej orientacji urządzenia.

7.5.3. Kamera zewnętrzna

Implementacje na urządzeniu:

• MOŻE obejmować obsługę zewnętrznej kamery, która nie musi być zawsze podłączona.

Jeśli implementacje urządzeń obejmują obsługę kamery zewnętrznej, muszą:

• [C-1-1] NALEŻY zadeklarować flagi funkcji platformy android.hardware.camera.external i android.hardware camera.any.
• [C-1-2] Musi obsługiwać USB Video Class (UVC 1.0 lub nowszy), jeśli kamera zewnętrzna łączy się przez port hosta USB.
• [C-1-3] Musi przejść testy CTS aparatu z podłączonym fizycznym zewnętrznym urządzeniem z kamerą. Szczegółowe informacje o testach CTS aparatu są dostępne na stronie source.android.com.
• POWINIEN obsługiwać kompresję wideo, np. MJPEG, aby umożliwić przesyłanie nieskompresowanych strumieni o wysokiej jakości (czyli strumieni nieprzetworzonych lub niezależnie skompresowanych).
• MOŻE obsługiwać wiele kamer.
• MOŻE obsługiwać kodowanie wideo na podstawie kamery.

Jeśli kodowanie wideo na podstawie kamery jest obsługiwane:

• [C-2-1] Jednoczesny strumień nieskompresowany / MJPEG (w rozdzielczości QVGA lub wyższej) MUSI być dostępny dla implementacji urządzenia.

7.5.4. Zachowanie interfejsu Camera API

Android zawiera 2 pakiety interfejsów API umożliwiające dostęp do aparatu. Nowszy interfejs android.hardware.camera2 API udostępnia aplikacji niższy poziom kontroli nad aparatem, w tym wydajne przepływy zdjęć seryjnych/strumieniowych bez kopiowania i kontroli na poziomie pojedynczego klatki dotyczące ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, redukcji szumów i wyostrzenia.

Starszy pakiet interfejsu API (android.hardware.Camera) jest oznaczony jako przestarzały w Androidzie 5.0, ale nadal powinien być dostępny dla aplikacji. Implementacje na urządzeniach z Androidem MUSZĄ zapewniać ciągłą obsługę interfejsu API zgodnie z opisem w tej sekcji i w pakiecie SDK Androida.

Wszystkie funkcje wspólne dla przestarzałej klasy android.hardware.Camera i nowszego pakietu android.hardware.camera2 MUSZĄ mieć porównywalne osiągi i jakość w obu interfejsach API. Na przykład przy takich samych ustawieniach szybkość i dokładność autofokusa MUSZĄ być identyczne, a jakość zarejestrowanych obrazów MUSI być taka sama. Funkcje, które zależą od odmiennej semantyki obu interfejsów API, nie muszą mieć takiej samej szybkości ani jakości, ale powinny być jak najbardziej zbliżone.

W przypadku wszystkich dostępnych aparatów wdrożenia urządzeń MUSZĄ implementować te zachowania w przypadku interfejsów API związanych z aparatami. Implementacje na urządzeniu:

• [C-0-1] DO użycia android.hardware.PixelFormat.YCbCr_420_SP dla 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 dalszym ciągu w formacie kodowania NV21, gdy aplikacja rejestruje wystąpienie android.hardware.Camera.PreviewCallback, system wywołuje metodę onPreviewFrame(), a format podglądu to YCbCr_420_SP, a dane w byte[] przekazane do onPreviewFrame(). Oznacza to, że NV21 MUSI być ustawiony jako domyślny.
• [C-0-3] Musi obsługiwać format YV12 (oznaczony za pomocą stałej android.graphics.ImageFormat.YV12) w przypadku podglądów z kamery przedniej i tylnej w urządzeniu android.hardware.Camera. (Sprzętowy koder wideo i kamera mogą używać dowolnego natywnego formatu pikseli, ale implementacja urządzenia MUSI obsługiwać konwersję do YV12).
• [C-0-4] Musi obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe w interfejsie API android.media.ImageReader na urządzeniach android.hardware.camera2, które reklamują obsługę funkcji REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE w android.request.availableCapabilities.
• [C-0-5] NALEŻY w pełni zaimplementować interfejs Camera API zawarty w dokumentacji pakietu SDK Androida, niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład aparaty bez autofokusa MUSZĄ wywoływać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback (nawet jeśli nie mają one zastosowania do aparatu bez autofokusa). Pamiętaj, że dotyczy to również przednich kamer. Na przykład mimo że większość przednich kamer nie obsługuje autofokusa, wywołania interfejsu API MUSZĄ być „fałszowane” w sposób opisany powyżej.
• [C-0-6] MUSI rozpoznawać i szanować nazwy parametrów zdefiniowane jako stałe w klasie android.hardware.Camera.Parameters i android.hardware.camera2.CaptureRequest. Z drugiej strony implementacje urządzeń NIE MOGĄ obsługiwać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters() 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 sprzęt na to pozwala, i NIE MOGĄ obsługiwać niestandardowych typów parametrów aparatu. Na przykład implementacje urządzeń, które obsługują techniki rejestrowania obrazu z wysokim zakresem dynamicznym (HDR), MUSZĄ obsługiwać parametr aparatu Camera.SCENE_MODE_HDR.
• [C-0-7] NALEŻY podać odpowiedni poziom obsługi za pomocą właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i podać odpowiednie flagi funkcji frameworka.
• [C-0-8] MUSI również zadeklarować indywidualne możliwości kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i zadeklarować odpowiednie flagi funkcji; MUSI zdefiniować flagę funkcji, jeśli którekolwiek z podłączonych urządzeń z kamerą obsługują tę funkcję.
• [C-0-9] NALEŻY nadawać intencję Camera.ACTION_NEW_PICTURE za każdym razem, gdy aparat zrobi nowe zdjęcie i jego wpis zostanie dodany do magazynu multimediów.
• [C-0-10] NALEŻY przesyłać intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy aparat nagrywa nowy film, a zdjęcie jest dodawane do magazynu multimediów.
• [C-0-11] Wszystkie kamery dostępne za pomocą przestarzałego interfejsu API android.hardware.Camera muszą być też dostępne za pomocą interfejsu API android.hardware.camera2.
• [C-SR] W przypadku urządzeń z większą liczbą kamer RGB skierowanych w ten sam kierunek MOCNO zalecamy obsługę logicznego urządzenia z kamerą, które zawiera informacje o możliwości CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, obejmujące wszystkie kamery RGB skierowane w ten sam kierunek jako fizyczne podurządzenia.

Jeśli implementacje na urządzeniach udostępniają firmom zewnętrznym firmowe interfejsy API aparatu, mogą:

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

7.5.5. Orientacja aparatu

Jeśli implementacje urządzeń mają przednie lub tylne kamery:

• [C-1-1] Musi być ustawiona tak, aby dłuższy wymiar kamery był wyrównany z dłuższym wymiarem ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparaty MUSZĄ robić zdjęcia w orientacji poziomej. Dotyczy to niezależnie od naturalnej orientacji urządzenia, czyli zarówno urządzeń z główną orientacją poziomą, jak i z główną orientacją pionową.

7.6. Pamięć i miejsce na dane

7.6.1. Minimalna ilość pamięci i miejsca na dane

Implementacje na urządzeniu:

• [C-0-1] Musi zawierać menedżera pobierania, którego aplikacje MOGĄ używać do pobierania plików danych. Musi być w stanie pobierać pojedyncze pliki o rozmiarze co najmniej 100 MB do domyślnej lokalizacji „bufora”.

7.6.2. Pamięć współdzielona aplikacji

Implementacje na urządzeniu:

• [C-0-1] MUSI oferować miejsce na dane, które może być udostępniane przez aplikacje. Jest ono często nazywane „wspólnym miejscem na dane zewnętrzne”, „wspólnym miejscem na dane aplikacji” lub ścieżką Linuxa „/sdcard”, na której jest zamontowane.
• [C-0-2] Musi być skonfigurowany z udziałem pamięci współdzielonej zamontowanej domyślnie, czyli „od razu po wyjęciu z pudła”, niezależnie od tego, czy pamięć jest implementowana na wewnętrznym komponencie pamięci czy na wymiennym nośniku pamięci (np. gniazdo karty Secure Digital).
• [C-0-3] NALEŻY zamontować udostępnioną pamięć aplikacji bezpośrednio na ścieżce Linuxa sdcard lub umieścić link symboliczny Linuxa z sdcard do rzeczywistego punktu zamontowania.
• [C-0-4] W pamięci współdzielonej należy ZAWSZE stosować uprawnienia android.permission.WRITE_EXTERNAL_STORAGE zgodnie z dokumentacją pakietu SDK.
• [C-0-5] W przypadku wszystkich aplikacji kierowanych na interfejs API na poziomie 29 lub wyższym MUSISZ domyślnie włączyć storage ujęty w zakresie, z wyjątkiem następujących sytuacji:
  • gdy aplikacja została zainstalowana przed uaktualnieniem urządzenia do poziomu interfejsu API 29, niezależnie od docelowego interfejsu API aplikacji;
  • gdy aplikacja poprosi o android:requestLegacyExternalStorage="true" w swoim pliku manifestu.
  • gdy aplikacja ma przyznane uprawnienie android.permission.WRITE_MEDIA_STORAGE.
• [C-0-6] Aplikacje z włączonym ograniczonym miejscem na dane NIE MOGĄ mieć bezpośredniego dostępu do plików spoza katalogów specyficznych dla aplikacji, zwracanych przez metody interfejsu API Context, takie jak Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs() i Context.getObbDirs().
• [C-0-7] NALEŻY usunąć metadane lokalizacji, takie jak znaczniki EXIF GPS, przechowywane w plikach multimedialnych, gdy te pliki są dostępne przez MediaStore, z wyjątkiem sytuacji, gdy aplikacja wywołująca ma uprawnienia ACCESS_MEDIA_LOCATION.

Implementacje urządzeń MOGĄ spełniać powyższe wymagania, korzystając z jednego z tych rozwiązań:

• wymienna pamięć dostępna dla użytkownika, np. gniazdo karty Secure Digital (SD);
• Część pamięci wewnętrznej (nieusuwalna) w ramach Projektu Android Open Source (AOSP).

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

• [C-1-1] W interfejsie należy DODAWAĆ toast lub wyskakujące okienko z ostrzeżeniem dla użytkownika, gdy w gniazdo nie jest włożone żadne medium.
• [C-1-2] MUSI zawierać nośnik danych w formacie FAT (np. kartę SD) lub na pudełku i w innych materiałach dostępnych w momencie zakupu musi być wskazane, że nośnik danych należy kupić osobno.

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

• NALEŻY użyć implementacji AOSP dotyczącej wewnętrznej pamięci współdzielonej aplikacji.
• MOŻE udostępniać miejsce na dane aplikacji z danymi prywatnymi.

Jeśli implementacje urządzeń zawierają wiele ścieżek do współdzielonej pamięci (np. gniazdo karty SD i wspólna pamięć wewnętrzna), muszą:

• [C-2-1] Tylko wstępnie zainstalowane i uprzywilejowane aplikacje na Androida z uprawnieniami WRITE_MEDIA_STORAGE mogą zapisywać dane na zewnętrznym urządzeniu do przechowywania danych, z wyjątkiem sytuacji, gdy zapisują dane w katalogach specyficznych dla pakietu lub w ramach URI zwracanego przez wywołanie intencji ACTION_OPEN_DOCUMENT_TREE.
• [C-2-2] Koniecznie wymagaj, aby dostęp bezpośredni powiązany z uprawnieniem android.permission.WRITE_MEDIA_STORAGE był przyznawany tylko aplikacjom widocznym dla użytkownika, gdy przyznane jest też uprawnienie android.permission.WRITE_EXTERNAL_STORAGE.
• [SR] MOCNO ZALECAMY, aby w celu interakcji z urządzeniami magazynującymi fabrycznie zainstalowane i uprzywilejowane aplikacje na Androida korzystały z publicznych interfejsów API, takich jak MediaStore, zamiast z bezpośredniego dostępu przyznanego przez android.permission.WRITE_MEDIA_STORAGE.

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB, muszą:

• [C-3-1] Musisz udostępnić mechanizm dostępu do danych w wspólnej pamięci aplikacji z komputera hosta.
• NALEŻY udostępniać treści z obu ścieżek pamięci w przejrzysty sposób za pomocą usługi skanowania multimediów w Androidzie i android.provider.MediaStore.
• Możesz użyć pamięci masowej USB, ale musisz użyć protokołu Media Transfer Protocol, aby spełnić ten wymóg.

Jeśli implementacje urządzeń mają port USB z trybem urządzenia peryferyjnego USB i obsługują protokół Media Transfer Protocol, to:

• Powinien być zgodny z hostem MTP na Androidzie, czyli aplikacją Android File Transfer.
• NALEŻY podać klasę urządzenia USB 0x00.
• Powinien zwracać nazwę interfejsu USB „MTP”.

7.6.3. Pamięć dostosowywana

Jeśli urządzenie ma być mobilne (w przeciwieństwie do telewizora), implementacje urządzenia muszą:

• [SR] MOCNO ZALECAMY stosowanie przenośnego miejsca na dane w stabilnej lokalizacji, ponieważ przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

Jeśli port wymiennego urządzenia pamięci masowej znajduje się w stabilnym miejscu, np. w komorze baterii lub innej osłonie ochronnej, implementacje urządzenia są następujące:

• [SR] ZDECYDOWANIE POLECAMY wdrożenie pamięci dostosowywanej.

7.7. USB

Jeśli implementacje urządzeń mają port USB, muszą:

• Powinien obsługiwać tryb urządzenia peryferyjnego USB i tryb hosta USB.

7.7.1. Tryb urządzenia peryferyjnego USB

Jeśli implementacje urządzenia obejmują port USB obsługujący tryb peryferyjny:

• [C-1-1] Port MUSI umożliwiać podłączenie do hosta USB z standardowym portem USB typu A lub C.
• [C-1-2] W standardowym opisie urządzenia USB (android.os.Build.SERIAL) MUSI być podana prawidłowa wartość iSerialNumber.
• [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem rezystancyjnego ładowania typu C oraz MUSI wykrywać zmiany w reklamie, jeśli obsługuje USB typu C.
• [SR] Port powinien używać formatu USB micro-B, micro-AB lub typu C. Zalecamy, aby istniejące i nowe urządzenia z Androidem spełniały te wymagania, ponieważ dzięki temu będą mogły przejść na przyszłe wersje platformy.
• [SR] Port powinien znajdować się na dole urządzenia (zgodnie z naturalną orientacją) lub umożliwiać obrócenie ekranu w ramach oprogramowania we wszystkich aplikacjach (w tym na ekranie głównym), aby wyświetlacz był prawidłowo wyświetlany, gdy port znajduje się na dole. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
• [SR] NALEŻY wdrożyć obsługę poboru prądu 1,5 A podczas szumowania i przesyłania danych w trybie HS zgodnie ze specyfikacją USB Battery Charging Specification, edycja 1.2. Zalecamy, aby istniejące i nowe urządzenia z Androidem spełniały te wymagania, aby można było je uaktualnić do przyszłych wersji platformy.
• [SR] MOCNO POLECANE jest, aby nie obsługiwać zastrzeżonych metod ładowania, które modyfikują napięcie Vbus poza domyślnymi poziomami lub zmieniają role odbiornika/źródła, ponieważ może to spowodować problemy ze zgodnością z ładowarkami lub urządzeniami, które obsługują standardowe metody dostarczania mocy przez USB. Chociaż jest to „ZALECANA” opcja, w przyszłych wersjach Androida możemy wymagać, aby wszystkie urządzenia z typem C obsługiwały pełną interoperacyjność ze standardowymi ładowarkami typu C.
• [SR] MOCNO POLECANE jest, aby obsługiwać Power Delivery do przesyłania danych i wymiany ról zasilania, gdy urządzenia obsługują USB typu C i tryb hosta USB.
• POWINIEN obsługiwać Power Delivery do ładowania wysokiego napięcia i obsługiwać tryby alternatywne, takie jak wyświetlacz zewnętrzny.
• NALEŻY zaimplementować interfejs API i specyfikację Android Open Accessory (AOA) zgodnie z dokumentacją pakietu Android SDK.

Jeśli implementacje urządzeń zawierają port USB i spełniają wymagania specyfikacji AOA, muszą:

• [C-2-1] MUSI deklarować obsługę funkcji sprzętowej android.hardware.usb.accessory.
• [C-2-2] Klasa pamięci masowej USB MUSI zawierać ciąg znaków „android” na końcu ciągu znaków iInterface opisu interfejsu pamięci masowej USB.

7.7.2. Tryb hosta USB

Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta, muszą:

• [C-1-1] MUSI implementować interfejs API hosta USB Androida zgodnie z dokumentacją do pakietu Android SDK i MUSI deklarować obsługę funkcji sprzętowej android.hardware.usb.host.
• [C-1-2] MUSI obsługiwać standardowe urządzenia peryferyjne USB, czyli MUSI:
  • Urządzenie musi mieć port typu C lub być dostarczane z kablami umożliwiającymi dostosowanie portu własnego urządzenia do standardowego portu USB typu C (urządzenie z USB typu C).
  • Urządzenie musi mieć port typu A lub być dostarczane z kablami umożliwiającymi dostosowanie portu własnego urządzenia do standardowego portu USB typu A.
  • Urządzenie musi mieć port micro-AB, do którego DOSTARCZA się kabel dopasowujący do standardowego portu typu A.
• [C-1-3] Nie wolno dostarczać adaptera do konwersji portów USB typu A lub mikro-AB na porty typu C (gniazdo).
• [C-SR] MOCNO ZALECAMY implementację klasy audio USB zgodnie z dokumentacją pakietu SDK Androida.
• POWINNY obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta; podawać prąd źródła 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 używać portu podrzędnego ładowania(CDP) w zakresie prądu wyjściowego zgodnie z specyfikacją ładowania baterii USB w wersji 1.2 w przypadku złączy Micro-AB.
• NALEŻY zaimplementować i obsługiwać standardy USB typu C.

Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i klasę audio USB, muszą:

• [C-2-1] MUSI obsługiwać klasę USB HID.
• [C-2-2] MUSI obsługiwać wykrywanie i mapowanie tych pól danych HID określonych w tabelach użycia USB HID i zapytaniu o użycie polecenia głosowego na stałe KeyEvent w ten sposób:
  • Strona użycia (0xC) Identyfikator użycia (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Strona z informacjami o korzystaniu (0xC) Identyfikator informacji o korzystaniu (0x0E9): KEYCODE_VOLUME_UP
  • Strona Użycie (0xC) Identyfikator użycia (0x0EA): KEYCODE_VOLUME_DOWN
  • Strona wykorzystania (0xC) Identyfikator wykorzystania (0x0CF): KEYCODE_VOICE_ASSIST

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i ramę Storage Access Framework (SAF), muszą:

• [C-3-1] MUSI rozpoznawać wszystkie urządzenia połączone zdalnie przez protokół MTP (Media Transfer Protocol) i uzyskiwać dostęp do ich zawartości za pomocą intencji ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT.

Jeśli implementacje urządzeń zawierają port USB obsługujący tryb hosta i USB typu C, muszą:

• [C-4-1] MUSI implementować funkcję portu podwójnego zastosowania zgodnie ze specyfikacją USB Type-C (sekcja 4.5.1.3.3).
• [SR] ZALECAMY obsługę interfejsu DisplayPort, obsługę interfejsu USB SuperSpeed oraz obsługę funkcji Power Delivery na potrzeby wymiany danych i mocy.
• [SR] BARDZO ZALECAMY, aby nie obsługiwać trybu akcesoriów przejściówki audio opisanego w Załączniku A w specyfikacji kabla i złącza USB typu C w wersji 1.2.
• NALEŻY zastosować model Try.* najbardziej odpowiedni dla formatu urządzenia. Na przykład urządzenie ręczne POWINNA stosować model Try.SNK.

7.8. Audio

7.8.1. mikrofon

Jeśli implementacje urządzeń zawierają mikrofon, muszą:

• [C-1-1] NALEŻY podać stałą android.hardware.microphone.
• [C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku podane w sekcji 5.4.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku podane w sekcji 5.6.
• [SR] ZALECAMY, aby obsługiwać nagrywanie w zakresie ultradźwięków zgodnie z opisem w sekcji 7.8.3.

Jeśli implementacje urządzeń pomijają mikrofon, mogą:

• [C-2-1] NIE należy raportować stałej funkcji android.hardware.microphone.
• [C-2-2] NALEŻY zaimplementować interfejs API do nagrywania dźwięku zgodnie z sekcją 7.

7.8.2. Wyjście audio

Jeśli implementacje urządzeń zawierają głośnik lub port wyjściowy audio/multimedia dla urządzenia peryferyjnego wyjścia audio, takie jak 4-przewodowe gniazdo słuchawek 3,5 mm lub port w trybie hosta USB za pomocą klasy audio USB, muszą:

• [C-1-1] NALEŻY podać stałą android.hardware.audio.output.
• [C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku podane w sekcji 5.5.
• [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku podane w sekcji 5.6.
• [SR] MOCNO ZALECAMY obsługę odtwarzania z użyciem ultradźwięków, jak opisano w sekcji 7.8.3.

Jeśli implementacje urządzeń nie zawierają głośnika ani portu wyjściowego audio, nie mogą:

• [C-2-1] NIE należy zgłaszać funkcji android.hardware.audio.output.
• [C-2-2] NALEŻY zaimplementować interfejsy API związane z wyjściami audio jako co najmniej no-ops.

W celu tej sekcji „port wyjściowy” to interfejs fizyczny, taki jak gniazdo słuchawek 3, 5 mm, port HDMI lub port w trybie 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 kwalifikuje się jako „port wyjściowy”.

7.8.2.1. Gniazda analogowe

Aby zapewnić zgodność z zestawami słuchawkowymi i innymi akcesoriami audio, które korzystają z wtyczki audio 3,5 mm w ekosystemie Androida, implementacje urządzeń muszą zawierać co najmniej 1 port analogowy do przesyłania dźwięku.W takim przypadku muszą one:

• [C-SR] MOCNO ZALECAMY, aby co najmniej 1 port audio był 4-żyłowym gniazdem słuchawek 3,5 mm.

Jeśli implementacje urządzeń mają 4-żyłowe złącze jack 3,5 mm, muszą:

• [C-1-1] Musi obsługiwać odtwarzanie dźwięku w słuchawkach stereo i zestawach słuchawkowych stereo z mikrofonem.
• [C-1-2] MUSI obsługiwać wtyczki audio TRRS z kolejnością styków zgodną ze standardem CTIA.
• [C-1-3] Musi obsługiwać wykrywanie i mapowanie na kody klawiszy dla tych 3 zakresów równoważnej impedancji między przewodami mikrofonu i uziemienia w złączu audio:
  • 70 omów lub mniej: KEYCODE_HEADSETHOOK
  • 210–290 Ω: KEYCODE_VOLUME_UP
  • 360–680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] Musi aktywować ACTION_HEADSET_PLUG po włożeniu wtyczki, ale dopiero po tym, jak wszystkie styki wtyczki dotkną odpowiednich segmentów gniazda.
• [C-1-5] MUSI być w stanie wygenerować co najmniej 150 mV ± 10% napięcia wyjściowego przy impedancji głośnika 32 Ohm.
• [C-1-6] Napięcie polaryzacji mikrofonu MUSI mieścić się w zakresie 1,8–2,9 V.
• [C-1-7] MUSI wykrywać i mapować kody kluczy dla następującego zakresu impedancji pozornej między mikrofonem a przewodami masy na wtyczce audio:
  • 110–180 om: KEYCODE_VOICE_ASSIST
• [C-SR] ZALECAMY obsługę wtyczek audio z kolejnością styków OMTP.
• [C-SR] MOCNO POLECAMY obsługę nagrywania dźwięku ze słuchawek stereo z mikrofonem.

Jeśli implementacje urządzeń mają 4-żyłowe gniazdo słuchawek 3,5 mm i obsługują mikrofon, a także nadają 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 urządzeniu audio.

7.8.2.2. Porty dźwięku cyfrowego

Zgodność ze słuchawkami i innymi urządzeniami audio korzystającymi z złączy USB-C i implementującymi (klasa audio USB) w ekosystemie Androida zgodnie ze specyfikacją zestawów słuchawkowych USB na Androida.

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

7.8.3. Zbliżenie ultradźwiękowe

Dźwięk w zakresie ultradźwięku to pasmo 18,5–20 kHz.

Implementacje na urządzeniu:

• MUSI prawidłowo zgłaszać obsługę funkcji dźwięku w zakresie ultradźwięków za pomocą interfejsu AudioManager.getProperty API w ten sposób:

Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND ma wartość „true”, źródła audio VOICE_RECOGNITION i UNPROCESSED MUSZĄ spełniać te wymagania:

• [C-1-1] Średnia moc wyjściowa mikrofonu w zakresie 18,5–20 kHz MUSI być niższa o nie więcej niż 15 dB od wartości w zakresie 2 kHz.
• [C-1-2] Współczynnik sygnału do szumu mikrofonu bez wyważenia w zakresie 18,5–20 kHz dla tonu 19 kHz przy -26 dBFS MUSI wynosić co najmniej 50 dB.

Jeśli PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „prawda”:

• [C-2-1] Średnia wartość głośnika w zakresie 18,5–20 kHz MUSI być co najmniej 40 dB poniżej wartości głośnika w zakresie 2 kHz.

7.8.4. Integralność sygnału

Implementacje na urządzeniu:

• NALEŻY zapewnić ścieżkę sygnału audio bez zakłóceń zarówno dla strumieni wejściowych, jak i wyjściowych na urządzeniach przenośnych, co oznacza brak zakłóceń zmierzonych podczas testu trwającego minutę na ścieżce. Przeprowadź test za pomocą [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) „Automated Glitch Test”.

Test wymaga przejściówki audio, która jest używana bezpośrednio w gniazdku słuchawek 3,5 mm lub w połączeniu z przejściówką USB-C na 3,5 mm. NALEŻY przetestować wszystkie porty wyjściowe audio.

OboeTester obsługuje obecnie ścieżki AAudio, więc należy przetestować te kombinacje, aby wykryć błędy w AAudio:

Niezawodny strumień POWINIEN spełniać te kryteria w przypadku stosunku sygnału do szumu (SNR) i całkowitego zniekształcenia harmonicznego (THD) dla sygnału sinusoidalnego 2000 Hz.

7.9. Rzeczywistość wirtualna

Android zawiera interfejsy API i funkcje do tworzenia aplikacji do rzeczywistości wirtualnej (VR), w tym aplikacji do mobilnej rzeczywistości wirtualnej o wysokiej jakości. Implementacje na urządzeniach MUSZĄ prawidłowo wdrażać te interfejsy API i zachowania zgodnie z opisem w tej sekcji.

7.9.1. Tryb rzeczywistości wirtualnej

Android obsługuje tryb VR, który umożliwia renderowanie powiadomień w stereoskopowym obrazie i wyłącza monokularne komponenty interfejsu systemu, gdy aplikacja VR ma na siebie nałożony fokus użytkownika.

7.9.2. Tryb rzeczywistości wirtualnej – wysoka wydajność

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

• [C-1-1] Musi mieć co najmniej 2 rdzenie fizyczne.
• [C-1-2] NALEŻY zadeklarować funkcję android.hardware.vr.high_performance.
• [C-1-3] Musi obsługiwać tryb stałej wydajności.
• [C-1-4] MUSI obsługiwać OpenGL ES 3.2.
• [C-1-5] MUST support android.hardware.vulkan.level 0.
• NALEŻY obsługiwać android.hardware.vulkan.level 1 lub nowszą.
• [C-1-6] NALEŻY wdrożyć rozszerzenia EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content i EGL_EXT_image_gl_colorspace oraz udostępnić je na liście dostępnych rozszerzeń EGL.
• [C-1-8] NALEŻY wdrożyć rozszerzenia GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture i GL_EXT_protected_textures oraz udostępnić je na liście dostępnych rozszerzeń GL.
• [C-SR] MOCNO POLECAMY 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 zalecamy obsługę Vulkan 1.1.
• [C-SR] BARDZO ZALECAMY wdrożenie VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing i VK_KHR_shared_presentable_image oraz dodanie go do listy dostępnych rozszerzeń Vulkan.
• [C-SR] MOCNO zalecamy udostępnienie co najmniej 1 rodziny kolejek Vulkan, w której flags zawiera zarówno VK_QUEUE_GRAPHICS_BIT, jak i VK_QUEUE_COMPUTE_BIT, a wartość queueCount wynosi co najmniej 2.
• [C-1-7] GPU i wyświetlacz MUSZĄ umożliwiać synchronizowanie dostępu do wspólnego bufora przedniego w taki sposób, aby renderowanie treści VR z wymiennym wyświetlaniem obrazu na lewe i prawe oko z częstotliwością 60 FPS z dwoma kontekstami renderowania było wyświetlane bez widocznych artefaktów rozrywania obrazu.
• [C-1-9] NALEŻY wdrożyć obsługę flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA i AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT zgodnie z opisem w NDK.
• [C-1-10] NALEŻY wdrożyć obsługę AHardwareBuffer z dowolną kombinacją flag użycia AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT co najmniej w tych formatach: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] ZALECAMY uwzględnienie przydziału AHardwareBuffer z większą liczbą 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 fps, skompresowane do średnio 40 Mb/s (co odpowiada 4 przypadkom 1920 x 1080 przy 30 fps i 10 Mb/s lub 2 przypadkom 1920 x 1080 przy 60 fps i 20 Mb/s).
• [C-1-12] MUSI obsługiwać HEVC i VP9, MUSI być w stanie dekodować co najmniej 1920 x 1080 przy 30 fps skompresowanych do średnio 10 Mb/s i POWINNA być w stanie dekodować 3840 x 2160 przy 30 fps i 20 Mb/s (co odpowiada 4 przypadkom 1920 x 1080 przy 30 fps i 5 Mb/s).
• [C-1-13] Musi obsługiwać interfejs API HardwarePropertiesManager.getDeviceTemperatures i zwracać dokładne wartości temperatury skóry.
• [C-1-14] Musi mieć wbudowany ekran o rozdzielczości co najmniej 1920 x 1080.
• [C-SR] MOCNO ZALECAMY korzystanie z rozdzielczości co najmniej 2560 × 1440.
• [C-1-15] Wyświetlacz MUSI odświeżać obraz co najmniej z częstotliwością 60 Hz w trybie VR.
• [C-1-17] Wyświetlacz MUSI obsługiwać tryb niskiej trwałości z trwałością do 5 ms, przy czym trwałość jest definiowana jako czas, przez który piksel emituje światło.
• [C-1-18] MUSI obsługiwać rozszerzenie długości danych Bluetooth 4.2 i Bluetooth LE sekcja 7.4.3.
• [C-1-19] MUSI obsługiwać i odpowiednio raportować Typ kanału bezpośredniego w przypadku wszystkich tych domyślnych typów czujników:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] BARDZO ZALECAMY obsługę typu kanału bezpośredniego TYPE_HARDWARE_BUFFER we wszystkich wymienionych powyżej typach kanałów bezpośrednich.
• [C-1-21] MUSI spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru dla android.hardware.hifi_sensors, jak określono w sekcji 7.3.9.
• [C-SR] MOCNO POLECAMY obsługę funkcji android.hardware.sensor.hifi_sensors.
• [C-1-22] Musisz mieć opóźnienie od ruchu do fotonu nie większe niż 28 milisekund.
• [C-SR] MOCNO ZALECAMY, aby opóźnienie od początku do końca procesu generowania ruchu do fotonu nie przekraczało 20 ms.
• [C-1-23] Pierwszy obraz musi mieć współczynnik pierwszego obrazu, który jest stosunkiem jasności pikseli na pierwszym obrazie po przejściu od czerni do bieli i jasności białych pikseli w stanie ustalonym, wynoszącym co najmniej 85%.
• [C-SR] ZALECAMY, aby współczynnik pierwszego kadru wynosił co najmniej 90%.
• MOŻE udostępniać procesor wyłącznie aplikacji na pierwszym planie i MOŻE obsługiwać interfejs API Process.getExclusiveCores, aby zwracać liczby rdzeni procesora, które są dostępne wyłącznie dla aplikacji na pierwszym planie.

Jeśli obsługiwany jest rdzeń wyłączny, to:

• [C-2-1] NIE MOŻE uruchamiać żadnych innych procesów 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.

8. Wydajność i moc

Niektóre minimalne kryteria wydajności i mocy są kluczowe dla wrażeń użytkownika i mają wpływ na założenia wyjściowe, które deweloperzy powinni uwzględnić podczas tworzenia aplikacji.

8.1. Spójność w interfejsie użytkownika

Aby zapewnić płynne działanie interfejsu użytkownika, należy spełnić określone wymagania minimalne, które zagwarantują stałą liczbę klatek na sekundę i czas reakcji w przypadku aplikacji i gier. Wdrożenia na urządzeniach, w zależności od typu urządzenia, MOGĄ mieć mierzalne wymagania dotyczące opóźnień interfejsu użytkownika i przełączania zadań, jak opisano w sekcji 2.

8.2. Wydajność dostępu do plikowego wejścia/wyjścia

Udostępnienie wspólnej wartości granicznej dla spójnej wydajności dostępu do plików w ramach prywatnego miejsca na dane aplikacji (partycji /data) pozwala deweloperom aplikacji określić odpowiednie oczekiwania, które pomogą im w projektowaniu oprogramowania. W zależności od typu urządzenia implementacje MOŻE wymagać spełnienia określonych w sekcji 2 wymagań dotyczących tych operacji odczytu i zapisu:

• Wydajność sekwencyjnego zapisu. Zmierzono podczas zapisywania pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
• Skuteczność losowych operacji zapisu. Zmierzono podczas zapisywania pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.
• Wydajność sekwencyjnego odczytu. Zmierzono podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
• Skuteczność losowego odczytu. Zmierzono podczas odczytu pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 4 KB.

8.3. Tryby oszczędzania energii

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

• [C-1-1] NIE MOŻE odbiegać od implementacji AOSP w przypadku algorytmów uruchamiania, konserwacji i budzenia oraz globalnych ustawień systemu w trybach oszczędzania energii App Standby i Doze.
• [C-1-2] NIE MOŻE odbiegać od implementacji AOSP w zakresie korzystania z ustawień globalnych do zarządzania ograniczeniem szybkości wykonywania zadań, alarmów i sieci w przypadku aplikacji w każdej grupie w trybie czuwania aplikacji.
• [C-1-3] Liczba poziomów aplikacji w stanie gotowości używanych w przypadku aplikacji w stanie gotowości MUSI ZGADZAĆ SIĘ z implementacją AOSP.
• [C-1-4] NALEŻY wdrożyć grupy aplikacji w stanie gotowości i tryb Doze zgodnie z opisem w Zarządzanie energią.
• [C-1-5] W trybie oszczędzania energii na urządzeniu true musi zwracać wartość PowerManager.isPowerSaveMode().
• [C-SR] MOCNO zalecamy, aby umożliwić użytkownikom włączenie i wyłączenie funkcji oszczędzania baterii.
• [C-SR] ZDECYDOWANIE zalecamy, aby umożliwić użytkownikom wyświetlanie wszystkich aplikacji, które są wyłączone z trybów oszczędzania energii App Standby i Doze.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ wykorzystywać dowolne lub wszystkie 4 stany uśpienia zdefiniowane przez interfejs ACPI (Advanced Configuration and Power Interface).

Jeśli implementacje urządzeń implementują stany zasilania S4 zgodnie z definicją ACPI, to:

• [C-1-1] MUST enter this state only after the user has taken an explicit action to put the device in an inactive state (e.g. by closing a lid that is physically part of the device or turning off a vehicle or television) and before the user re-activates the device (e.g. by opening the lid or turning the vehicle or television back on).

Jeśli implementacje urządzeń implementują stany zasilania S3 zgodnie z definicją ACPI, to:

• [C-2-1] MUSI spełniać wymagania podane w sekcji C-1-1 lub MUSI wejść w stan S3 tylko wtedy, gdy aplikacje innych firm nie potrzebują zasobów systemowych (np. ekranu czy procesora).

  Z drugiej strony, gdy aplikacje innych firm potrzebują zasobów systemowych, muszą opuścić stan S3, zgodnie z opisem w tym pakiecie SDK.

  Podczas gdy aplikacje innych firm proszą o utrzymanie ekranu w stanie włączonym (FLAG_KEEP_SCREEN_ON) lub uruchomionego procesora (PARTIAL_WAKE_LOCK), urządzenie NIE MOŻE przejść w stan S3, chyba że użytkownik wykona wyraźne działanie, aby umieścić urządzenie w stanie nieaktywnym, jak opisano w sekcji C-1-1. Z drugiej strony, gdy uruchamiane jest zadanie implementowane przez aplikacje innych firm za pomocą JobSchedulera lub gdy aplikacje innych firm otrzymują wiadomości z Komunikacji w chmurze Firebase, urządzenie MUSI opuścić stan S3, chyba że użytkownik przełączy je w stan nieaktywny. To nie są wyczerpujące przykłady, ponieważ AOSP implementuje rozbudowane sygnały budzenia, które powodują wybudzanie z tego stanu.

8.4. Rachunkowość zużycia energii

Dokładniejsze rozliczanie i raportowanie zużycia energii daje deweloperowi aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorców zużycia energii przez aplikację.

Implementacje na urządzeniu:

• [SR] BARDZO ZALECAMY podanie profilu zasilania dla poszczególnych komponentów, który definiuje wartość bieżącego zużycia energii dla każdego komponentu sprzętowego oraz przybliżone zużycie baterii spowodowane przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
• [SR] MOCNO ZALECANA: podawaj wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
• [SR] ZDECYDOWANIE POLECAMY raportowanie zużycia energii procesora 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 POLECANE: udostępnij ten tryb zużycia energii za pomocą polecenia adb shell dumpsys batterystats w powłoce dla dewelopera aplikacji.
• POWINIEN być przypisany do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.

8.5. Spójna wydajność

Wydajność może się znacznie wahać w przypadku aplikacji o wysokiej wydajności i długim czasie działania z powodu innych aplikacji działających w tle lub ograniczania procesora z powodu limitów temperatury. Android zawiera interfejsy programowe, dzięki którym aplikacja na pierwszym planie może poprosić system o zoptymalizowanie przydziału zasobów w celu łagodzenia takich wahań.

Implementacje na urządzeniu:

• [C-0-1] NALEŻY prawidłowo zgłaszać obsługę trybu ciągłej wydajności za pomocą metody interfejsu API PowerManager.isSustainedPerformanceModeSupported().

• Powinien obsługiwać tryb ciągłej wydajności.

Jeśli implementacje urządzeń zgłaszają obsługę trybu ciągłej wydajności, to:

• [C-1-1] Musisz zapewnić najwyższej aplikacji na pierwszym planie spójny poziom wydajności przez co najmniej 30 minut, gdy aplikacja tego zażąda.
• [C-1-2] MUSI obsługiwać interfejs API Window.setSustainedPerformanceMode() i inne powiązane interfejsy API.

Jeśli implementacje urządzeń zawierają co najmniej 2 rdzenie procesora, muszą:

• NALEŻY zapewnić co najmniej 1 rdzeń, który może być zarezerwowany przez aplikację na pierwszym planie.

Jeśli implementacje urządzeń obsługują rezerwowanie 1 rdzenia wyłącznie dla głównej aplikacji na pierwszym planie, to:

• [C-2-1] Musisz podać za pomocą metody interfejsu API Process.getExclusiveCores() numery identyfikatorów rdzeni, które mogą być zarezerwowane przez główną aplikację na pierwszym planie.
• [C-2-2] Nie wolno zezwalać na uruchamianie na rdzeniach wyłącznych żadnych procesów w przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację, ale można zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.

Jeśli implementacje urządzeń nie obsługują rdzenia wyłącznego, nie:

• [C-3-1] Musi zwracać pustą listę za pomocą metody interfejsu API Process.getExclusiveCores().

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniu:

• [C-0-1] NALEŻY zaimplementować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji interfejsów API w dokumentacji dla deweloperów Androida.

• [C-0-2] MUSI obsługiwać instalowanie samodzielnie podpisanych aplikacji bez konieczności uzyskiwania dodatkowych uprawnień lub certyfikatów od stron trzecich/autorytetów. W szczególności kompatybilne urządzenia MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w następnych podrozdziałach.

9.1. Uprawnienia

Implementacje na urządzeniu:

• [C-0-1] Musi obsługiwać model uprawnień Androida zgodnie z definicją w dokumentacji dla deweloperów Androida. W szczególności muszą one egzekwować każde uprawnienie zdefiniowane w dokumentacji pakietu SDK. Żadne uprawnienia nie mogą być pomijane, zmieniane ani ignorowane.

• MOŻE dodawać dodatkowe uprawnienia, pod warunkiem że nowe ciągi znaków identyfikatora uprawnień nie znajdują się w przestrzeni nazw android.\*.

• [C-0-2] Uprawnienia z protectionLevel PROTECTION_FLAG_PRIVILEGED MUSZĄ być przyznawane tylko aplikacjom wstępnie zainstalowanym na ścieżkach uprzywilejowanych obrazu systemu i w ramach podzbioru uprawnień dozwolonych w przypadku każdej aplikacji. Implementacja AOSP spełnia ten wymóg, odczytując i przestrzegając uprawnień dozwolonych dla każdej aplikacji z plików na ścieżce etc/permissions/ i traktując ścieżkę system/priv-app jako ścieżkę uprzywilejowaną.

Uprawnienia z poziomem ochrony niebezpieczny to uprawnienia czasu działania. Aplikacje z targetSdkVersion > 22 żądają ich w czasie wykonywania.

Implementacje na urządzeniu:

• [C-0-3] MUSI wyświetlać specjalny interfejs, aby użytkownik mógł zdecydować, czy przyznać żądane uprawnienia w czasie działania, a także udostępnić interfejs do zarządzania uprawnieniami w czasie działania.
• [C-0-4] Musisz mieć jedną i tylko jedną implementację obu interfejsów użytkownika.
• [C-0-5] NIE NALEŻY przyznawać żadnych uprawnień w czasie działania w przypadku wstępnie zainstalowanych aplikacji, chyba że:
  • Zgoda użytkownika może zostać uzyskana przed użyciem danych przez aplikację.
  • Uprawnienia w czasie działania są powiązane z wzorcem intencji, dla którego domyślnym modułem obsługi jest wstępnie zainstalowana aplikacja.
• [C-0-6] NALEŻY przyznać uprawnienie android.permission.RECOVER_KEYSTORE tylko aplikacjom systemowym, które rejestrują odpowiednio zabezpieczonego agenta odzyskiwania danych. Prawidłowo zabezpieczony agent odzyskiwania to oprogramowanie na urządzeniu, które synchronizuje się z zdalnymi miejscami na dane poza urządzeniem. Takie miejsce na dane jest wyposażone w bezpieczny sprzęt z ochroną równoważną lub silniejszą niż ta opisana w usłudze Google Cloud Key Vault, aby zapobiec atakom z wykorzystaniem metody siłowego doboru prób w przypadku czynnika wiedzy na ekranie blokady.

Implementacje na urządzeniu:

• [C-0-7] Aplikacja MUSI przestrzegać właściwości uprawnień dotyczących lokalizacji na Androidzie, gdy prosi o dane o lokalizacji lub aktywności fizycznej za pomocą standardowego interfejsu API Androida lub zastrzeżonego mechanizmu. Dane te obejmują:

  • lokalizacja urządzenia (np. szerokość i długość geograficzna).
  • Informacje, które mogą służyć do określenia lub oszacowania lokalizacji urządzenia (np. SSID, BSSID, identyfikator komórki, skanowanie Bluetooth lub lokalizacja sieci, z którą jest połączone urządzenie).
  • Aktywność fizyczna użytkownika lub klasyfikacja aktywności fizycznej.

W szczególności dotyczy to implementacji na urządzeniach:

• [C-0-8] Musisz uzyskać zgodę użytkownika na dostęp aplikacji do danych o lokalizacji lub aktywności fizycznej.
• [C-0-9] MUST grant a runtime permission ONLY to the app that holds sufficient permission as described on SDK. Na przykład metoda TelephonyManager#getServiceState wymaga uprawnienia android.permission.ACCESS_FINE_LOCATION.

Uprawnienia mogą być oznaczone jako ograniczone, co zmienia ich działanie.

• [C-0-10] Uprawnienia oznaczone flagą hardRestricted NIE MOGĄ zostać przyznane aplikacji, chyba że:

  • Plik APK aplikacji znajduje się na partycji systemowej.
  • Użytkownik przypisuje do aplikacji rolę powiązaną z uprawnieniami hardRestricted.
  • Instalator przyznaje aplikacji uprawnienia hardRestricted.
  • Aplikacja ma przyznane uprawnienie hardRestricted w poprzedniej wersji Androida.

• [C-0-11] Aplikacje z uprawnieniami softRestricted MUSZĄ mieć tylko ograniczony dostęp i NIE mogą uzyskać pełny dostęp, dopóki nie zostaną dodane do listy dozwolonych zgodnie z opisem w pakiecie SDK, gdzie dla każdego uprawnienia softRestricted zdefiniowano pełny i ograniczony dostęp (np. WRITE_EXTERNAL_STORAGE i READ_EXTERNAL_STORAGE).

Jeśli implementacje urządzeń obejmują wstępnie zainstalowaną aplikację lub jeśli chcesz zezwolić aplikacjom innych firm na dostęp do statystyk użytkowania, musisz:

• [SR] MOCNO ZALECAMY udostępnienie użytkownikom mechanizmu przyznawania i odbierania dostępu do statystyk użycia w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS w przypadku aplikacji, które deklarują uprawnienie android.permission.PACKAGE_USAGE_STATS.

Jeśli implementacje na urządzeniach mają uniemożliwiać dostęp do statystyk użytkowania wszystkim aplikacjom, w tym wstępnie zainstalowanym, muszą:

• [C-1-1] Nadal MUSISZ mieć aktywność, która obsługuje wzór intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale MUSISZ zaimplementować ją jako no-op, czyli tak, aby działała tak samo jak w przypadku odmowy dostępu.

9.2. UID i izolacja procesów

Implementacje na urządzeniu:

• [C-0-1] Musi obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja działa jako unikalny identyfikator UID w stylu Unixa i w oddzielnym procesie.
• [C-0-2] MUSI obsługiwać uruchamianie wielu aplikacji z użyciem tego samego identyfikatora użytkownika Linuxa, pod warunkiem że aplikacje są prawidłowo podpisane i skonstruowane zgodnie z definicją w dokumentacji dotyczącej zabezpieczeń i uprawnień.

9.3. Uprawnienia do systemu plików

Implementacje na urządzeniu:

• [C-0-1] MUSI obsługiwać model uprawnień dostępu do plików w Androidzie zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień.

9.4. Alternatywne środowiska wykonawcze

Implementacje urządzeń MUSZĄ zachować spójność modelu zabezpieczeń i uprawnień Androida, nawet jeśli zawierają środowiska uruchomieniowe, które wykonują aplikacje za pomocą innego oprogramowania lub technologii niż format wykonywalny Dalvik czy kod natywny. Krótko mówiąc:

• [C-0-1] Alternatywny czas wykonywania MUSI być aplikacją na Androida i stosować się do standardowego modelu zabezpieczeń Androida, jak opisano w sekcji 9.

• [C-0-2] Alternatywnym środowiskom uruchomieniowym NIE MOŻNA przyznawać dostępu do zasobów chronionych przez uprawnienia, których nie żądano w pliku AndroidManifest.xml środowiska uruchomieniowego za pomocą mechanizmu <uses-permission>.

• [C-0-3] Alternatywny czas wykonywania NIE MOŻE zezwalać aplikacjom na korzystanie z funkcji chronionych przez uprawnienia Androida, które są ograniczone do aplikacji systemowych.

• [C-0-4] Alternatywne środowisko uruchomieniowe MUSI być zgodne z modelem piaskownicy Androida, a zainstalowane aplikacje korzystające z alternatywnego środowiska uruchomieniowego NIE MOGĄ ponownie używać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida dotyczących udostępnionego identyfikatora użytkownika i certyfikatu podpisywania.

• [C-0-5] Alternatywny środowisko uruchomieniowe NIE MOŻE uruchamiać, przyznawać ani uzyskiwać dostępu do piaskownicy odpowiadającej innym aplikacjom na Androida.

• [C-0-6] Alternatywny czas wykonywania NIE MOŻE być uruchamiany z uprawnieniami superużytkownika (root) ani nie może przyznawać takich uprawnień innym aplikacjom.

• [C-0-7] Jeśli pliki .apk alternatywnych środowisk wykonawczych są zawarte w pliku obrazu systemu implementacji urządzenia, muszą być podpisane za pomocą klucza innego niż klucz używany do podpisywania innych aplikacji zawartych w implementacjach urządzenia.

• [C-0-8] Podczas instalowania aplikacji alternatywne środowisko uruchomieniowe MUSI uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację.

• [C-0-9] Gdy aplikacja potrzebuje zasobu urządzenia, dla którego istnieje odpowiednie uprawnienie Androida (np. aparat, GPS itp.), alternatywny czas wykonywania MUSI poinformować użytkownika, że aplikacja będzie mieć dostęp do tego zasobu.

• [C-0-10] Jeśli środowisko uruchomieniowe nie rejestruje w taki sposób możliwości aplikacji, MUSI ono podać wszystkie uprawnienia posiadane przez samo środowisko uruchomieniowe podczas instalowania dowolnej aplikacji korzystającej z tego środowiska.

• Alternatywny czas wykonywania POWINIEN instalować aplikacje za pomocą PackageManager w oddzielnych piaskownicach Androida (identyfikatory użytkowników systemu Linux itp.).

• Alternatywny czas wykonywania MOŻE udostępniać jedną piaskownicę Androida, z której korzystają wszystkie aplikacje korzystające z alternatywnego czasu wykonywania.

9,5. Pomoc dla wielu użytkowników

Android obsługuje wielu użytkowników i pozwala na pełną izolację użytkowników.

• Implementacje urządzeń MOGĄ, ale NIE POWINNY umożliwiać korzystania z wielu użytkowników, jeśli używają wymiennych nośników danych jako głównej pamięci zewnętrznej.

Jeśli implementacje urządzeń obejmują wielu użytkowników, mogą:

• [C-1-1] MUSI spełniać te wymagania dotyczące obsługi wielu użytkowników.
• [C-1-2] W przypadku każdego użytkownika należy wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji referencyjnej Zasady zabezpieczeń i uprawnień dotyczącej interfejsów API.
• [C-1-3] W przypadku każdego wystąpienia użytkownika MUSISZ mieć osobne i odizolowane katalogi współdzielonego miejsca na dane aplikacji (zwanego też /sdcard).
• [C-1-4] NALEŻY zadbać o to, aby aplikacje należące do danego użytkownika i działające w jego imieniu nie mogły wyświetlać, odczytywać ani zapisywać plików należących do innego użytkownika, nawet jeśli dane obu użytkowników są przechowywane w tym samym woluminie lub systemie plików.
• [C-1-5] NALEŻY szyfrować zawartość karty SD, gdy włączona jest obsługa wielu użytkowników, za pomocą klucza przechowywanego tylko na niewymiennym nośniku, dostępnego tylko dla systemu, jeśli implementacje urządzeń używają wymiennych nośników dla interfejsów API zewnętrznego miejsca na dane. Ponieważ spowoduje to, że media nie będą czytelne dla komputera hosta, implementacje urządzeń będą musiały przejść na MTP lub podobny system, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika.

9,6. Ostrzeżenie dotyczące SMS-ów specjalnych

Android obsługuje ostrzeżenia użytkowników o wysyłanych SMS-ach premium. SMS-y premium to wiadomości tekstowe wysyłane do usługi zarejestrowanej u operatora, za którą może być pobierana opłata od użytkownika.

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

• [C-1-1] NALEŻY ostrzegać użytkowników przed wysłaniem SMS-a do numerów zdefiniowanych za pomocą wyrażeń regularnych w pliku /data/misc/sms/codes.xml na urządzeniu. Dostępny w górę projektu Android Open Source Project zapewnia implementację, która spełnia ten wymóg.

9,7. Funkcje zabezpieczeń

Implementacje urządzeń MUSZĄ zapewniać zgodność z funkcjami zabezpieczeń w jądrze i na platformie zgodnie z opisem poniżej.

Piaskownica Androida zawiera funkcje korzystające z systemu kontroli dostępu (MAC) Security-Enhanced Linux (SELinux), piaskownicy seccomp i innych funkcji zabezpieczeń w jądrze systemu Linux. Implementacje na urządzeniu:

• [C-0-1] Musi być zgodny z dotychczasowymi aplikacjami, nawet jeśli SELinux lub inne funkcje zabezpieczeń są implementowane poniżej platformy Android.
• [C-0-2] Nie wolno stosować widocznego interfejsu użytkownika, gdy naruszenie bezpieczeństwa zostanie wykryte i skutecznie zablokowane przez funkcję zabezpieczeń zaimplementowaną poniżej platformy Android, ale można użyć widocznego interfejsu użytkownika, gdy nastąpi nieblokowane naruszenie bezpieczeństwa, które spowoduje skuteczne wykorzystanie luki.
• [C-0-3] Nie wolno zezwalać użytkownikowi ani deweloperowi aplikacji na konfigurowanie SELinux ani innych funkcji zabezpieczeń zaimplementowanych poniżej platformy Android.
• [C-0-4] Nie wolno zezwalać aplikacji, która może wpływać na inną aplikację za pomocą interfejsu API (np. interfejsu Device Administration API), na konfigurowanie zasad, które naruszają zgodność.
• [C-0-5] NALEŻY podzielić framework multimediów na kilka procesów, aby umożliwić bardziej precyzyjne przyznawanie dostępu do poszczególnych procesów, zgodnie z opisem na stronie projektu Android Open Source.
• [C-0-6] NALEŻY zaimplementować mechanizm piaskownicy aplikacji jądra, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnych zasad z programów wielowątkowych. Projekt Android Open Source na upstreamie spełnia ten wymóg dzięki włączeniu seccomp-BPF z synchronizacją wątków (TSYNC), zgodnie z opisem w sekcji Konfiguracja jądra na stronie source.android.com.

Funkcje integralności i samoochrony jądra są integralną częścią zabezpieczeń Androida. Implementacje na urządzeniu:

• [C-0-7] NALEŻY wdrożyć mechanizmy ochrony przed przepełnieniem bufora stosu jądra. Przykładami takich mechanizmów są CC_STACKPROTECTOR_REGULAR i CONFIG_CC_STACKPROTECTOR_STRONG.
• [C-0-8] NALEŻY wdrożyć ścisłe zabezpieczenia pamięci jądra, w których kod wykonywalny jest tylko do odczytu, dane tylko do odczytu są tylko do odczytu i nie do zapisu, a dane tylko do zapisu są tylko do zapisu (np. CONFIG_DEBUG_RODATA lub CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] NALEŻY zaimplementować sprawdzanie zakresów rozmiarów statycznych i dynamicznych obiektów w kopiach między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY) na urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym.
• [C-0-10] NIE WOLNO wykonywać kodu w pamięci na poziomie użytkownika podczas działania w trybie jądra (np. w ramach sprzętowego interfejsu PXN lub w ramach emulacji za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym.
• [C-0-11] NIE MOŻESZ odczytywać ani zapisywać danych w pamięci użytkownika w rdzeniu poza normalnymi interfejsami API dostępu do danych użytkownika (np. interfejs API sterowania sprzętem lub emulowany przez CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN) na urządzeniach pierwotnie dostarczanych z interfejsem API na poziomie 28 lub wyższym.
• [C-0-12] NALEŻY zaimplementować izolację tabeli stron jądra, jeśli sprzęt jest podatny na atak CVE-2017-5754 na wszystkich urządzeniach pierwotnie dostarczanych z poziomem interfejsu API 28 lub nowszym (np. CONFIG_PAGE_TABLE_ISOLATION lub CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] NALEŻY wdrożyć wzmocnienie przewidywania rozgałęzi, jeśli sprzęt jest podatny na atak CVE-2017-5715 na wszystkich urządzeniach pierwotnie wysyłanych z poziomem interfejsu API 28 lub nowszym (np. CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] MOCNO ZALECANA jest zmiana po inicjalizacji danych jądra, które są zapisywane tylko podczas inicjalizacji, na dane tylko do odczytu (np. __ro_after_init).

• [C-SR] Zdecydowanie zalecamy losowanie rozkładu kodu jądra i pamięci oraz unikanie sytuacji, które mogłyby zagrozić losowości (np. CONFIG_RANDOMIZE_BASE z entropią programu rozruchowego za pomocą /chosen/kaslr-seed Device Tree node lub EFI_RNG_PROTOCOL).

• [C-SR] Zdecydowanie zalecamy włączenie integralności przepływu sterowania (CFI) w jądrze, aby zapewnić dodatkową ochronę przed atakami polegającymi na ponownym użyciu kodu (np. CONFIG_CFI_CLANG i CONFIG_SHADOW_CALL_STACK).

• [C-SR] W przypadku komponentów, w których są włączone mechanizmy CFI, SCS lub IntSan, MOCNO zalecamy, aby ich nie wyłączać.
• [C-SR] MOCNO POLECAMY włączenie CFI, SCS i IntSan w przypadku wszystkich dodatkowych komponentów przestrzeni użytkownika, które są wrażliwe na zagrożenia związane z bezpieczeństwem, zgodnie z opisem w artykułach CFI i IntSan.

Jeśli implementacje urządzeń korzystają z jądra Linuksa, muszą:

• [C-1-1] NALEŻY zaimplementować SELinux.
• [C-1-2] NALEŻY ustawić SELinux na tryb globalny.
• [C-1-3] NALEŻY skonfigurować wszystkie domeny w trybie wymuszania. Niedozwolone są domeny w trybie dozwolonym, w tym domeny związane z urządzeniem lub dostawcą.
• [C-1-4] Nie wolno modyfikować, pomijać ani zastępować reguł neverallow znajdujących się w folderze system/sepolicy udostępnianym w ramach projektu źródłowego Android Open Source (AOSP). Zasady muszą być zgodne ze wszystkimi regułami neverallow, zarówno w przypadku domen AOSP SELinux, jak i w przypadku domen konkretnych urządzeń lub dostawców.
• [C-1-5] NALEŻY uruchamiać aplikacje innych firm przeznaczone dla interfejsu API w wersji 28 lub nowszej w oddzielnych piaskownicach SELinux dla każdej aplikacji z ograniczeniami SELinux dla każdej aplikacji w przypadku katalogu danych prywatnych każdej aplikacji.
• NALEŻY zachować domyślną zasadę SELinux udostępnioną w folderze system/sepolicy w ramach projektu źródłowego Androida Open Source i tylko dodać do tej zasady własną konfigurację urządzenia.

Jeśli implementacje urządzeń zostały już uruchomione w starszej wersji Androida i nie spełniają wymagań [C-1-1] i [C-1-5] w ramach aktualizacji oprogramowania systemowego, mogą być zwolnione z tych wymagań.

Jeśli implementacje urządzeń używają jądra innego niż Linux:

• [C-2-1] NALEŻY używać systemu obowiązkowej kontroli dostępu, który jest odpowiednikiem SELinux.

Android zawiera wiele zaawansowanych funkcji ochrony, które są integralną częścią zabezpieczeń urządzenia.

9,8. Prywatność

9.8.1. Historia użycia

Android przechowuje historię wyborów użytkownika i zarządza nią za pomocą UsageStatsManager.

Implementacje na urządzeniu:

• [C-0-1] NALEŻY zachować rozsądny okres przechowywania takiej historii użytkownika.
• [SR] ZALECAMY, aby okres przechowywania wynosił 14 dni, zgodnie z domyślną konfiguracją w implementacji AOSP.

Android przechowuje zdarzenia systemowe za pomocą identyfikatorów StatsLog i zarządza taką historią za pomocą interfejsów StatsManager i IncidentManager System API.

Implementacje na urządzeniu:

• [C-0-2] W raporcie o incydencie utworzonym przez klasę interfejsu System API IncidentManager MUSISZ uwzględnić tylko pola oznaczone jako DEST_AUTOMATIC.
• [C-0-3] NIE WOLNO używać identyfikatorów zdarzeń systemowych do rejestrowania innych zdarzeń niż te opisane w dokumentach pakietu SDK StatsLog. Jeśli są rejestrowane dodatkowe zdarzenia systemowe, mogą one używać innego identyfikatora atomu w zakresie od 100 000 do 200 000.

9.8.2. Nagrywam

Implementacje na urządzeniu:

• [C-0-1] NIE WOLNO wstępnie wczytywać ani rozpowszechniać komponentów oprogramowania, które wysyłają prywatne informacje użytkownika (np. naciśnięcia klawiszy, tekst wyświetlany na ekranie, raporty o błędach) z urządzenia bez jego zgody lub bez wyraźnego powiadomienia.

• [C-0-2] NALEŻY wyświetlać i uzyskiwać wyraźną zgodę użytkownika, która zawiera w przybliżeniu tę samą wiadomość co AOSP, gdy włączone jest przesyłanie lub nagrywanie ekranu za pomocą interfejsów API MediaProjection lub firmowych interfejsów API. NIE MOŻESZ udostępnić użytkownikom opcji, która umożliwia wyłączenie wyświetlania prośby o zgodę.

• [C-0-3] Podczas udostępniania ekranu lub nagrywania ekranu MUSI być wyświetlane ciągłe powiadomienie dla użytkownika. AOSP spełnia ten wymóg, wyświetlając ikonę powiadomienia na pasku stanu.

Jeśli implementacje na urządzeniu obejmują funkcje systemu, które umożliwiają przechwytywanie treści wyświetlanych na ekranie lub nagrywanie strumienia audio odtwarzanego na urządzeniu w inny sposób niż za pomocą interfejsu System API ContentCaptureService lub innych zastrzeżonych metod opisanych w sekcji 9.8.6 Content Capture, muszą:

• [C-1-1] NALEŻY wyświetlać użytkownikowi ciągłe powiadomienie, gdy ta funkcja jest włączona i aktywnie rejestruje/nagrywa.

Jeśli implementacje urządzeń zawierają komponent, który jest domyślnie włączony i umożliwia nagrywanie dźwięku z otoczenia lub dźwięku odtwarzanego na urządzeniu w celu wywnioskowania przydatnych informacji o kontekście użytkownika, to:

• [C-2-1] Nie wolno przechowywać w pamięci trwałej na urządzeniu ani przesyłać z urządzenia nagranego dźwięku w postaci surowych danych lub w dowolnym formacie, który można przekonwertować z powrotem na oryginalny dźwięk lub jego zbliżone kopie, z wyjątkiem sytuacji, gdy użytkownik wyrazi wyraźną zgodę.

9.8.3. Łączność

Jeśli implementacje urządzeń mają port USB z obsługą trybu urządzenia peryferyjnego USB, muszą:

• [C-1-1] NALEŻY wyświetlić interfejs z prośbą o zgodę użytkownika przed przyznaniem dostępu do zawartości wspólnego miejsca na dane przez port USB.

9.8.4. Ruch w sieci

Implementacje na urządzeniu:

• [C-0-1] NALEŻY wstępnie zainstalować te same certyfikaty główne dla zaufanych przez system urzędów certyfikacji (CA) jak podane w poprzednim projekcie Android Open Source.
• [C-0-2] Musi być dostarczany z pusta pamięcią głównego urzędu certyfikacji użytkownika.
• [C-0-3] NALEŻY wyświetlić użytkownikowi ostrzeżenie, że ruch w sieci może być monitorowany, gdy dodawane jest główne urzędu certyfikacji urzędu.

Jeśli ruch na urządzeniu jest kierowany przez sieć VPN, implementacje urządzeń:

• [C-1-1] MUSI wyświetlać użytkownikowi ostrzeżenie zawierające:
  • Ruch w sieci może być monitorowany.
  • Ruch sieciowy jest przekierowywany przez konkretną aplikację VPN, która zapewnia VPN.

Jeśli implementacje urządzeń mają mechanizm, który jest domyślnie włączony i przekierowuje ruch danych sieciowych przez serwer proxy lub bramę VPN (np. wstępnie wczytując usługę VPN z uprawnieniami android.permission.CONTROL_VPN), to:

• [C-2-1] NALEŻY poprosić o zgodę użytkownika przed włączeniem tego mechanizmu, chyba że VPN jest włączony przez kontroler zasad urządzenia za pomocą DevicePolicyManager.setAlwaysOnVpnPackage(). W tym przypadku użytkownik nie musi wyrażać osobnej zgody, ale NALEŻY go o to powiadomić.

Jeśli implementacje urządzeń zawierają opcję umożliwiającą użytkownikowi przełączanie funkcji „Stały VPN” w aplikacji VPN innej firmy, muszą:

• [C-3-1] W pliku AndroidManifest.xml należy DISABLE (WYŁĄCZ) tę funkcję dla aplikacji, które nie obsługują stałej usługi VPN. W tym celu należy ustawić atrybut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

9.8.5. Identyfikatory urządzeń

Implementacje na urządzeniu:

• [C-0-1] Aplikacja NIE MOŻE umożliwiać dostępu do numeru seryjnego urządzenia ani, w stosownych przypadkach, numeru IMEI/MEID, numeru seryjnego karty SIM i identyfikatora IMSI, chyba że spełnia jeden z tych wymagań:
  • jest podpisaną aplikacją operatora, która została zweryfikowana przez producentów urządzeń.
  • otrzymało uprawnienie READ_PRIVILEGED_PHONE_STATE.
  • ma uprawnienia operatora zdefiniowane w Uprawnieniach operatora UICC.
  • jest właścicielem urządzenia lub właścicielem profilu, któremu przyznano uprawnienia READ_PHONE_STATE.
  • (Tylko w przypadku numeru seryjnego karty SIM lub identyfikatora ICCID) zgodnie z lokalnymi przepisami aplikacja musi wykrywać zmiany tożsamości abonenta.

9.8.6. Rejestrowanie treści

Android, za pomocą interfejsu System API ContentCaptureService lub innych zastrzeżonych metod, obsługuje mechanizm umożliwiający implementacje urządzeń do rejestrowania następujących interakcji między aplikacjami a użytkownikiem.

• Tekst i grafika renderowane na ekranie, w tym między innymi powiadomienia i dane asystenta za pomocą interfejsu API AssistStructure.
• dane multimedialne, takie jak dźwięk lub wideo, nagrane lub odtworzone przez urządzenie;
• zdarzenia związane z wprowadzaniem danych (np. klawiatura, mysz, gesty, głos, wideo i dostępność);
• wszelkie inne zdarzenia, które aplikacja przekazuje systemowi za pomocą interfejsu Content Capture API lub podobnego zastrzeżonego interfejsu API;

Jeśli implementacje urządzeń rejestrują powyższe dane, mogą:

• [C-1-1] NALEŻY szyfrować wszystkie takie dane, gdy są przechowywane na urządzeniu. Szyfrowanie MOŻE być wykonywane za pomocą szyfrowania opartego na plikach w Androidzie lub dowolnego szyfru wymienionego jako wersja interfejsu API 26 lub nowsza w pakiecie Cipher SDK.
• [C-1-2] NIE wolno tworzyć kopii zapasowych danych w postaci nieprzetworzonej lub zaszyfrowanej przy użyciu metod tworzenia kopii zapasowej na Androidzie ani żadnych innych metod.
• [C-1-3] NALEŻY wysyłać wszystkie takie dane i dziennik urządzenia tylko przy użyciu mechanizmu ochrony prywatności. Mechanizm ochrony prywatności to „takie mechanizmy, które umożliwiają analizę tylko w ujęciu zbiorczym i uniemożliwiają dopasowywanie zarejestrowanych zdarzeń lub wyników pochodnych do poszczególnych użytkowników”. Ma to na celu zapobieganie możliwości wglądu w jakiekolwiek dane dotyczące poszczególnych użytkowników (np. za pomocą technologii prywatności różnicowej, takiej jak RAPPOR).
• [C-1-4] NIE MOŻNA wiązać tych danych z żadną tożsamością użytkownika (np. Account) na urządzeniu, chyba że użytkownik wyrazi wyraźną zgodę na każde takie powiązanie.
• [C-1-5] NIE MOŻESZ udostępniać takich danych innym aplikacjom, chyba że użytkownik wyrazi na to zgodę za każdym razem.
• [C-1-6] NALEŻY umożliwić użytkownikowi usunięcie danych, które ContentCaptureService lub zastrzeżone metody gromadzą, jeśli dane są przechowywane w dowolnej formie na urządzeniu.

Jeśli implementacje na urządzeniu obejmują usługę, która implementuje interfejs System API ContentCaptureService, lub dowolną zastrzeżoną usługę, która rejestruje dane w sposób opisany powyżej, to:

• [C-2-1] NIE wolno zezwalać użytkownikom na zastąpienie usługi przechwytywania treści aplikacją lub usługą instalowaną przez użytkownika. NALEŻY zezwolić na przechwytywanie takich danych tylko w ramach wstępnie zainstalowanej usługi.
• [C-2-2] NIE wolno zezwalać żadnym aplikacjom innym niż wstępnie zainstalowany mechanizm usługi przechwytywania treści na możliwość przechwytywania takich danych.
• [C-2-3] NALEŻY zapewnić użytkownikowi możliwość wyłączenia usługi przechwytywania treści.
• [C-2-4] NIE MOŻNA pominąć możliwości zarządzania uprawnieniami Androida, które są wymagane przez usługę rejestrowania treści. Należy przestrzegać modelu uprawnień Androida zgodnie z opisem w sekcji 9.1. Uprawnienia.

• [C-SR] MOCNO zalecamy oddzielne przechowywanie komponentów usługi rejestrującej treści, np. niewiązanie usługi ani udostępnianie identyfikatorów procesów z innymi komponentami systemu, z wyjątkiem tych:

  • Telefonia, Kontakty, UI systemu i multimedia

9.8.7. Dostęp do schowka

Implementacje na urządzeniu:

• [C-0-1] NIE MOŻE zwracać danych z wykadrowania na schowku (np. za pomocą interfejsu API ClipboardManager), chyba że aplikacja jest domyślnym IME lub jest aplikacją, która ma obecnie fokus.

9.8.8. Lokalizacja

Implementacje na urządzeniu:

• [C-0-1] NIE MOŻESZ włączać ani wyłączać ustawień lokalizacji urządzenia oraz ustawień skanowania Wi-Fi/Bluetooth bez wyraźnej zgody użytkownika lub jego inicjatywy.
• [C-0-2] Musisz umożliwić użytkownikowi dostęp do informacji związanych z lokalizacją, w tym ostatnich próśb o lokalizację, uprawnień na poziomie aplikacji i skanowania Wi-Fi/Bluetooth w celu określenia lokalizacji.
• [C-0-3] Aplikacja korzystająca z interfejsu API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] MUSI być aplikacją, która została uruchomiona przez użytkownika w ramach sesji alarmowej (np. po wywołaniu numeru 112 lub wysłaniu SMS-a na numer 112).
• [C-0-4] NALEŻY zachować możliwość pominięcia ustawień lokalizacji urządzenia przez interfejs API Emergency Location Bypass bez zmiany tych ustawień.
• [C-0-5] NALEŻY zaplanować wysłanie powiadomienia, które przypomina użytkownikowi, że aplikacja w tle uzyskała dostęp do jego lokalizacji za pomocą uprawnienia [ACCESS_BACKGROUND_LOCATION].

9.9. Szyfrowanie danych przechowywanych

Wszystkie urządzenia muszą spełniać wymagania podane w sekcji 9.9.1. Urządzenia, które zostały uruchomione na poziomie interfejsu API wcześniejszym niż w tym dokumencie, są zwolnione z wymagań zawartych w sekcjach 9.9.2 i 9.9.3. Zamiast tego muszą spełniać wymagania podane w sekcji 9.9 dokumentu Definicja zgodności z Androidem odpowiadające poziomowi interfejsu API, na którym urządzenie zostało uruchomione.

9.9.1. Bezpośredni rozruch

Implementacje na urządzeniu:

• [C-0-1] NALEŻY zaimplementować interfejsy API Tryb bezpośredniego uruchamiania, nawet jeśli nie obsługują one szyfrowania pamięci masowej.

• [C-0-2] Intencje ACTION_LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED MUSZĄ być nadal nadawane, aby sygnalizować aplikacjom obsługującym bezpośrednie uruchamianie, że dostępne są dla użytkownika szyfrowane miejsca na dane na urządzeniu (DE) i szyfrowane miejsca na dane z danymi logowania (CE).

9.9.2. Wymagania dotyczące szyfrowania

Implementacje na urządzeniu:

• [C-0-1] Musisz zaszyfrować prywatne dane aplikacji (partycja /data) oraz partycję współdzielonego miejsca na dane aplikacji (partycja /sdcard), jeśli jest to stała, nieusuwalna część urządzenia.
• [C-0-2] Domyślnie musisz włączyć szyfrowanie danych w momencie, gdy użytkownik zakończy konfigurację urządzenia.
• [C-0-3] NALEŻY spełnić powyższy wymóg szyfrowania danych poprzez wdrożenie szyfrowania na poziomie pliku (FBE).

9.9.3. Szyfrowanie oparte na plikach

Zaszyfrowane urządzenia:

• [C-1-1] Musi uruchamiać się bez żądania od użytkownika danych uwierzytelniających i umożliwiać aplikacjom obsługującym bezpośrednie uruchamianie dostęp do zaszyfrowanej pamięci urządzenia (DE) po przesłaniu komunikatu ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] NALEŻY zezwalać na dostęp do zaszyfrowanej pamięci tylko wtedy, gdy użytkownik odblokuje urządzenie, podając swoje dane logowania (np. kod dostępu, kod PIN, wzór lub odcisk palca) i wyświetli się wiadomość ACTION_USER_UNLOCKED.
• [C-1-3] NIE wolno oferować żadnej metody odblokowania chronionego magazynu CE bez podania danych logowania podanych przez użytkownika lub zarejestrowanego klucza powiernikowego.
• [C-1-4] NALEŻY używać weryfikacji podczas uruchamiania i zadbać o to, aby klucze DE były powiązane kryptograficznie z zaufanym korzeniami wiarygodności sprzętowej urządzenia.
• [C-1-5] NALEŻY szyfrować zawartość pliku za pomocą AES-256-XTS lub Adiantum. AES-256-XTS to standard Advanced Encryption Standard z 256-bitowym kluczem szyfrującym, który działa w trybie XTS. Pełna długość klucza to 512 bitów. Adiantum to Adiantum-XChaCha12-AES, jak określono na stronie https://github.com/google/adiantum.
• [C-1-6] NALEŻY szyfrować nazwy plików za pomocą AES-256-CBC-CTS lub Adiantum.

• [C-1-12] NALEŻY używać algorytmu AES-256-XTS do treści plików i AES-256-CBC-CTS do nazw plików (zamiast Adiantum), jeśli urządzenie ma instrukcje dotyczące zaawansowanego standardu szyfrowania (AES). Instrukcje AES to rozszerzenia kryptograficzne ARMv8 na urządzeniach z procesorami ARM lub AES-NI na urządzeniach z procesorami x86. Jeśli urządzenie nie ma instrukcji AES, MOŻE ono używać Adiantum.

• Klucze chroniące obszary pamięci CE i DE:

• [C-1-7] MUSI być powiązany z kluczem sprzętowym.

• [C-1-8] Klucze CE MUSZĄ być powiązane z danymi uwierzytelniania na ekranie blokady użytkownika.
• [C-1-9] Klucze CE muszą być powiązane z domyślnym kodem dostępu, gdy użytkownik nie podał danych logowania na ekranie blokady.
• [C-1-10] Musi być unikalny i niepowtarzalny, co oznacza, że klucz CE lub DE żadnego użytkownika nie może być taki sam jak klucz CE lub DE innego użytkownika.
• [C-1-11] NALEŻY używać szyfrów, długości kluczy i trybów obsługiwanych obligatoryjnie.

• [C-SR] MOCNO POLECAMY szyfrowanie metadanych systemu plików, takich jak rozmiary plików, własność, tryby i rozszerzone atrybuty (xattrs), za pomocą klucza powiązanego kryptograficznie z korzeniami zaufania sprzętowego urządzenia.

• NALEŻY zadbać o to, aby wbudowane niezbędne aplikacje (np. Alarm, Telefon, Messenger) były świadome bezpośredniego uruchamiania.

Wspólny projekt Android Open Source udostępnia preferowaną implementację tej funkcji na podstawie funkcji szyfrowania „fscrypt” jądra Linuksa.

9.10. Integralność urządzenia

Wymagania te zapewniają przejrzystość stanu integralności urządzenia. Implementacje na urządzeniu:

• [C-0-1] MUSI poprawnie zgłaszać za pomocą metody interfejsu System API PersistentDataBlockManager.getFlashLockState(), czy stan bootloadera zezwala na flashowanie obrazu systemu. Stan FLASH_LOCK_UNKNOWN jest zarezerwowany dla implementacji urządzeń uaktualnianych z wcześniejszej wersji Androida, w której nie istniała ta nowa metoda interfejsu API.

• [C-0-2] Musi obsługiwać zweryfikowany rozruch w celu zapewnienia integralności urządzenia.

Jeśli implementacje urządzeń zostały już uruchomione bez obsługi Verified Boot w wersji Androida wcześniejszej niż 9.0 i nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego, mogą być zwolnione z tego wymogu.

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

• [C-1-1] NALEŻY zadeklarować flagę funkcji platformy android.software.verified_boot.
• [C-1-2] NALEŻY przeprowadzić weryfikację w ramach każdego sekwencji uruchamiania.
• [C-1-3] NALEŻY rozpocząć weryfikację od niezmiennego klucza sprzętowego, który jest zaufanym źródłem, i przeprowadzić ją aż do partycji systemowej.
• [C-1-4] NALEŻY wdrożyć każdy etap weryfikacji, aby sprawdzić integralność i autentyczność wszystkich bajtów na następnym etapie przed wykonaniem kodu na tym etapie.
• [C-1-5] NALEŻY używać algorytmów weryfikacji o tak silnej sile jak w przypadku algorytmów szyfrowania (SHA-256) i kluczy publicznych (RSA-2048) zgodnie z aktualnymi zaleceniami NIST.
• [C-1-6] NIE wolno dopuścić do uruchomienia, gdy weryfikacja systemu się nie powiedzie, chyba że użytkownik wyrazi zgodę na próbę uruchomienia, w którym to przypadku nie wolno używać danych z niezatwierdzonych bloków pamięci.
• [C-1-7] NIE wolno zezwalać na modyfikowanie zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokował bootloader.
• [C-SR] Jeśli na urządzeniu jest kilka oddzielnych układów (np. radio, wyspecjalizowany procesor obrazu), MOCNO zalecamy, aby podczas rozruchu zweryfikować każdy etap uruchamiania każdego z tych układów.
• [C-1-8] MUST use tamper-evident storage: for storing whether the bootloader is unlocked. Pamięć z funkcją wykrywania manipulacji oznacza, że bootloader może wykryć, czy pamięć została naruszona z poziomu Androida.
• [C-1-9] NALEŻY wyświetlić użytkownikowi odpowiedni komunikat podczas korzystania z urządzenia i wymagać fizycznego potwierdzenia przed przejściem z trybu zablokowanego programu rozruchowego do trybu odblokowanego programu rozruchowego.
• [C-1-10] NALEŻY wdrożyć ochronę przed cofnięciem zmian na partycjach używanych przez Androida (np. partycjach rozruchu i systemowych) oraz używać pamięci z funkcją wykrywania manipulacji do przechowywania metadanych służących do określania minimalnej dozwolonej wersji systemu operacyjnego.
• [C-SR] MOCNO ZALECAMY weryfikowanie wszystkich plików APK aplikacji uprzywilejowanej za pomocą łańcucha zaufania z korzeniami w partycjach chronionych przez weryfikowany rozruch.
• [C-SR] MOCNO ZALECAMY weryfikowanie wszystkich artefaktów wykonywalnych załadowanych przez aplikację uprzywilejowaną spoza pliku APK (np. kodu skompilowanego lub kodu wczytywanego dynamicznie) przed ich wykonaniem lub MOCNO ZALECAMY, aby w ogóle ich nie wykonywać.
• NALEŻY wdrożyć ochronę przed przywracaniem w przypadku każdego komponentu z trwałym oprogramowaniem sprzętowym (np. modemu czy kamery) i NALEŻY użyć magazynu z funkcją wykrywania manipulacji do przechowywania metadanych służących do określania minimalnej dozwolonej wersji.

Jeśli implementacje urządzeń zostały już wdrożone 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ą być zwolnione z tych wymagań.

Projekt Android Open Source udostępnia preferowaną implementację tej funkcji w repozytorium external/avb/, która może być zintegrowana z bootloaderem używanym do ładowania Androida.

Implementacje na urządzeniu:

• [C-R] Zaleca się obsługę interfejsu Android Protected Confirmation API.

Jeśli implementacje urządzeń obsługują interfejs Protected Confirmation API, to:

• [C-3-1] W przypadku interfejsu API ConfirmationPrompt.isSupported() należy zgłaszać dane true.

• [C-3-2] NALEŻY zadbać o to, aby kod działający w systemie operacyjnym Android, w tym jego jądro, złośliwy lub inny, nie mógł wygenerować pozytywnej odpowiedzi bez interakcji użytkownika.

• [C-3-3] NALEŻY zadbać o to, aby użytkownik mógł przejrzeć i zatwierdzić wyświetlaną wiadomość nawet wtedy, gdy system operacyjny Android (w tym jego jądro) został naruszony.

9.11. Klucze i dane logowania

System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i używanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub Keystore API. Implementacje na urządzeniu:

• [C-0-1] MUSI umożliwiać zaimportowanie lub wygenerowanie co najmniej 8192 kluczy.
• [C-0-2] Uwierzytelnianie na ekranie blokady MUSI stosować limitowanie prób i musi zawierać algorytm wygaszania. Po 150 nieudanych próbach opóźnienie musi wynosić co najmniej 24 godziny na próbę.
• NIE należy ograniczać liczby kluczy, które mogą być generowane

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady, urządzenie:

• [C-1-1] NALEŻY utworzyć kopię zapasową implementacji Keystore w odizolowanym środowisku wykonawczym.
• [C-1-2] Musisz mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2, aby prawidłowo obsługiwać obsługiwane algorytmy systemu Keystore na Androidzie w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze i powyżej. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source Project (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
• [C-1-3] NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonywania i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem tylko wtedy, gdy uwierzytelnianie się powiedzie. Dane uwierzytelniające na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający przeprowadzanie uwierzytelniania na ekranie blokady tylko w odizolowanym środowisku wykonania. Wspólny projekt Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.
• [C-1-4] MUSI obsługiwać atesta klucza, w którym klucz podpisujący jest chroniony przez bezpieczny sprzęt, a podpisywanie odbywa się na bezpiecznym sprzęcie. Klucze podpisywania certyfikatów MUSZĄ być udostępniane na wystarczająco dużej liczbie urządzeń, aby uniemożliwić ich użycie jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymagania jest udostępnienie tego samego klucza uwierzytelniania,chyba że wyprodukowano co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowano ponad 100 tys. jednostek danego kodu SKU, dla każdej grupy 100 tys. jednostek MOŻE być używany inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida, nie musi spełniać wymagań dotyczących posiadania repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania i obsługiwania uwierzytelniania klucza, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga repozytorium kluczy obsługiwanego przez odizolowane środowisko wykonywania.

• [C-1-5] NALEŻY umożliwić użytkownikowi wybranie czasu bezczynności w trybie uśpienia, który umożliwia przejście z otwartego do zamkniętego stanu, z minimalnym dozwolonym czasem bezczynności do 15 sekund.

9.11.1. Bezpieczna blokada ekranu i uwierzytelnianie

Implementacja AOSP opiera się na modelach uwierzytelniania wielopoziomowego, w których uwierzytelnianie podstawowe oparte na fabryce wiedzy może być wspierane przez drugorzędne silne dane biometryczne lub słabsze metody uwierzytelniania na poziomie trzecim.

Implementacje na urządzeniu:

• [C-SR] MOCNO POLECAMY ustawienie jako podstawowej metody uwierzytelniania tylko jednej z tych opcji:
  • numeryczny kod PIN;
  • Hasło alfanumeryczne
  • Wzór przesunięcia na siatce dokładnie 3 x 3 kropek

Pamiętaj, że w tym dokumencie powyższe metody uwierzytelniania są określane jako zalecane podstawowe metody uwierzytelniania.

Jeśli implementacje urządzeń dodają lub modyfikują zalecane podstawowe metody uwierzytelniania i używają nowej metody uwierzytelniania jako bezpiecznego sposobu blokowania ekranu, nowa metoda uwierzytelniania:

• [C-2-1] MUSI to być metoda uwierzytelniania użytkownika opisana w sekcji Wymaganie uwierzytelniania użytkownika w przypadku korzystania z klucza.
• [C-2-2] NALEŻY odblokować wszystkie klucze, aby aplikacja dewelopera innej firmy mogła być używana po odblokowaniu przez użytkownika ekranu blokady zabezpieczeń. Na przykład wszystkie klucze MUSZĄ być dostępne dla aplikacji dewelopera zewnętrznego za pomocą odpowiednich interfejsów API, takich jak createConfirmDeviceCredentialIntent i setUserAuthenticationRequired.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, jeśli są oparte na znanym tajnym kluczu i korzystają z nowej metody uwierzytelniania, która ma być traktowana jako bezpieczny sposób blokowania ekranu:

• [C-3-1] Entropia najkrótszych dozwolonych długości danych wejściowych MUSI być większa niż 10 bitów.
• [C-3-2] Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18 bitów.
• [C-3-3] Nowa metoda uwierzytelniania NIE MOŻE zastąpić żadnej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) zaimplementowanych i dostępnych w AOSP.
• [C-3-4] Nowa metoda uwierzytelniania MUSI być wyłączona, gdy aplikacja DPC (Device Policy Controller) ustawia zasady dotyczące jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_SOMETHING.
• [C-3-5] Nowe metody uwierzytelniania MUSZĄ co najpóźniej co 72 godziny stosować zalecane podstawowe metody uwierzytelniania (np. kod PIN, wzór, hasło) LUB wyraźnie informować użytkownika, że niektóre dane nie będą szyfrowane, aby zachować prywatność jego danych.

Jeśli implementacje urządzeń dodają lub modyfikują zalecane podstawowe metody uwierzytelniania, aby odblokować ekran blokady i używać nowej metody uwierzytelniania opartej na danych biometrycznych, która ma być traktowana jako bezpieczny sposób blokowania ekranu, nowa metoda:

• [C-4-1] MUSI spełniać wszystkie wymagania opisane w sekcji 7.3.10 dotyczące wygody.
• [C-4-2] MUSI zawierać mechanizm zapasowy umożliwiający korzystanie z jednej z zalecanych podstawowych metod uwierzytelniania, która opiera się na znanym kluczu.
• [C-4-3] NALEŻY wyłączyć i zezwolić tylko na zalecane uwierzytelnianie podstawowe na potrzeby odblokowywania ekranu , gdy aplikacja Device Policy Controller (DPC) ustawiła zasady funkcji klucza blokady, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures() z dowolnym powiązanym znacznikiem biometrycznym (np. KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE lub KEYGUARD_DISABLE_IRIS).

Jeśli metody uwierzytelniania biometrycznego nie spełniają wymagań dotyczących silnego uwierzytelniania opisanych w sekcji 7.3.10:

• [C-5-1] Metody MUSZĄ być wyłączone, jeśli aplikacja kontrolera zasad dotyczących urządzeń (DPC) skonfigurowała zasady jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] Po upływie 4-godzinnego okresu bezczynności użytkownik MUSI zostać poproszony o zalecane uwierzytelnienie podstawowe (np. za pomocą kodu PIN, wzoru lub hasła). Czas bezczynności jest resetowany po każdym potwierdzeniu danych logowania na urządzeniu.
• [C-5-3] Metody NIE MOGĄ być traktowane jako bezpieczny ekran blokady i MUSZĄ spełniać wymagania opisane w tej sekcji od C-8.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, a nowa metoda uwierzytelniania opiera się na fizycznym tokenie lub lokalizacji:

• [C-6-1] Muszą mieć mechanizm zapasowy, który umożliwia korzystanie z jednej z zalecanych metod uwierzytelniania podstawowego opartej na znanym kluczu tajnym i spełniającej wymagania dotyczące traktowania jako bezpieczny ekran blokady.
• [C-6-2] Nowa metoda MUSI być wyłączona i zezwalać na odblokowanie ekranu tylko przy użyciu jednej z zalecanych podstawowych metod uwierzytelniania, gdy aplikacja Device Policy Controller (DPC) skonfigurowała 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 zostać poproszony o wykonanie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru lub hasła) co najmniej raz na 4 godziny.
• [C-6-4] Nowa metoda NIE MOŻE być traktowana jako bezpieczny ekran blokady i MUSI być zgodna z ograniczeniami wymienionymi w sekcji C-8.

Jeśli implementacje urządzeń mają zabezpieczony ekran blokady i zawierają co najmniej 1 usługę zaufania, która implementuje interfejs API systemu TrustAgentService, to:

• [C-7-1] W menu ustawień i na ekranie blokady musi być wyraźnie wskazane, kiedy blokada urządzenia jest odroczona lub może być odblokowana przez zaufanego agenta. Na przykład AOSP spełnia ten wymóg, wyświetlając w menu ustawień opis tekstowy „Automatyczne blokowanie” i „Przycisk zasilania natychmiast blokuje”, a na ekranie blokady – różniącą się ikonę.
• [C-7-2] MUSISZ przestrzegać i w pełni wdrażać wszystkie interfejsy API zaufanego agenta w klasie DevicePolicyManager, np. stałą KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NIE WOLNO w pełni wdrażać funkcji TrustAgentService.addEscrowToken() na urządzeniu używanym jako podstawowe urządzenie osobiste (np. urządzenie przenośne), ale MOŻNA w pełni wdrażać tę funkcję na urządzeniach, które są zwykle współużytkowane (np. Android TV lub urządzenie samochodowe).
• [C-7-4] NALEŻY zaszyfrować wszystkie zapisane tokeny dodane przez TrustAgentService.addEscrowToken().
• [C-7-5] Nie przechowuj klucza szyfrowania ani tokena powiernikowego na tym samym urządzeniu, na którym używany jest klucz. Na przykład klucz przechowywany na telefonie może odblokować konto użytkownika na telewizorze.
• [C-7-6] NALEŻY poinformować użytkownika o konsekwencjach bezpieczeństwa przed włączeniem tokena powiernikowego w celu odszyfrowania danych.
• [C-7-7] MUSI zawierać mechanizm zapasowy umożliwiający korzystanie z jednej z zalecanych metod uwierzytelniania podstawowego.
• [C-7-8] Użytkownik MUSI zostać poproszony o podanie danych uwierzytelniających przy użyciu jednej z zalecanych metod uwierzytelniania podstawowego (np.kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny, chyba że chodzi o bezpieczeństwo użytkownika (np. rozproszenie uwagi kierowcy).
• [C-7-9] Po upływie 4-godzinnego okresu bezczynności użytkownik MUSI zostać poproszony o podanie danych uwierzytelniających za pomocą jednej z zalecanych metod uwierzytelniania podstawowego (np. kodu PIN, wzoru lub hasła), chyba że chodzi o bezpieczeństwo użytkownika (np. rozproszenie uwagi kierowcy). Czas bezczynności jest resetowany po każdym potwierdzeniu danych logowania na urządzeniu.
• [C-7-10] NIE MOŻE być traktowany jako bezpieczny ekran blokady i musi spełniać ograniczenia wymienione w sekcji C-8 poniżej.
• [C-7-11] NIE MOŻESZ zezwalać zaufanym agentom na głównych urządzeniach osobistych (np. na urządzeniach przenośnych) na odblokowywanie urządzenia. Możesz używać ich tylko do utrzymywania już odblokowanego urządzenia w stanie odblokowanym przez maksymalnie 4 godziny. Domyślna implementacja usługi TrustManagerService w AOSP spełnia to wymaganie.
• [C-7-12] NALEŻY używać szyfrowanego kanału komunikacji (np.UKEY2) do przekazywania tokena powiernikowego z urządzenia magazynującego na urządzenie docelowe.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, który nie jest zabezpieczony zgodnie z opisem powyżej, i używają nowej metody uwierzytelniania do odblokowania ekranu blokady:

• [C-8-1] Nowa metoda MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) skonfigurowała zasady dotyczące jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] Nie wolno resetować ustawień czasu ważności hasła przez DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] Nie wolno im udostępniać interfejsu API do użytku przez aplikacje innych firm w celu zmiany stanu blokady.

9.11.2. StrongBox

System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych na dedykowanym bezpiecznym procesorze, a także w opisanym powyżej odizolowanym środowisku wykonywania. Taki dedykowany bezpieczny procesor nazywa się „StrongBox”. Wymagania C-1-3 do C-1-11 poniżej określają wymagania, które MUSI spełniać urządzenie, aby mogło być uznane za StrongBox.

Implementacje urządzeń z dedykowanym bezpiecznym procesorem:

• [C-SR] Zdecydowanie zalecamy obsługę StrongBox. W kolejnych wersjach będzie to wymagane.

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

• [C-1-1] NALEŻY zadeklarować FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] MUSI zapewnić specjalny sprzęt zabezpieczający, który służy do tworzenia kopii zapasowych magazynu kluczy i bezpiecznego uwierzytelniania użytkowników. Specjalne bezpieczne urządzenia mogą być używane również do innych celów.

• [C-1-3] Musi zawierać procesor, który nie udostępnia procesorowi aplikacji (AP) pamięci podręcznej, pamięci DRAM, procesorów pomocniczych ani innych zasobów rdzenia.

• [C-1-4] NALEŻY zadbać o to, aby żadne urządzenia peryferyjne udostępnione AP nie mogły w żaden sposób zmienić przetwarzania StrongBox ani uzyskać żadnych informacji z tego urządzenia. AP MOŻE wyłączyć lub zablokować dostęp do StrongBox.

• [C-1-5] Musi mieć wewnętrzny zegar o rozsądnej dokładności (+-10%), który jest odporny na manipulacje ze strony AP.

• [C-1-6] MUSI zawierać prawdziwy generator liczb losowych, który generuje wyjście o jednolitej dystrybucji i nieprzewidywalnym charakterze.

• [C-1-7] Musi być odporny na próby manipulacji, w tym na włamanie fizyczne i zakłócenia.

• [C-1-8] MUSI być odporny na kanały boczne, w tym na wyciek informacji przez kanały boczne związane z zasilaniem, czasem, promieniowaniem elektromagnetycznym i promieniowaniem cieplnym.

• [C-1-9] MUSI być zapewnione bezpieczne przechowywanie, które zapewnia poufność, integralność, autentyczność, spójność i świeżość treści. Nie można odczytywać ani zmieniać danych w magazynie, z wyjątkiem sytuacji dozwolonych przez interfejsy StrongBox API.

• Aby sprawdzić zgodność z [C-1-3] do [C-1-9], implementacje na urządzeniach:

  • [C-1-10] MUSI zawierać sprzęt z certyfikatem zgodności z profilem ochrony kart inteligentnych BSI-CC-PP-0084-2014 lub oceniony przez akredytowane na poziomie krajowym laboratorium testowe, które uwzględniło ocenę podatności na ataki o wysokim potencjale zgodnie z kryteriami Common Criteria dla kart inteligentnych.
  • [C-1-11] MUSI zawierać oprogramowanie sprzętowe, które zostało ocenione przez akredytowane w danym kraju laboratorium testowe, uwzględniając ocenę podatności na ataki o wysokim potencjale zgodnie z kryteriami Common Criteria dla kart inteligentnych.
  • [C-SR] MOCNO zalecamy uwzględnienie sprzętu, który został oceniony przy użyciu Security Target, Evaluation Assurance Level (EAL) 5, uzupełnionego o AVA_VAN.5. Certyfikat EAL 5 prawdopodobnie stanie się wymagany w kolejnych wersjach.

• [C-SR] ZALECAMY stosowanie funkcji odporności na ataki z zewnątrz (IAR), co oznacza, że osoba z dostępem do kluczy do podpisywania oprogramowania nie może wygenerować oprogramowania, które powoduje wyciek tajemnic w StrongBox, pozwala na obejście wymagań dotyczących bezpieczeństwa funkcjonalnego lub umożliwia w inny sposób uzyskanie dostępu do poufnych danych użytkownika. Zalecane jest, aby zezwolenie na aktualizacje oprogramowania sprzętowego było możliwe tylko wtedy, gdy hasło głównego użytkownika zostanie podane za pomocą interfejsu IAuthSecret HAL.

9.12. Usuwanie danych

Wszystkie implementacje urządzeń:

• [C-0-1] Musisz udostępniać użytkownikom mechanizm umożliwiający przywrócenie ustawień fabrycznych.
• [C-0-2] NALEŻY usunąć wszystkie dane z systemu plików userdata.
• [C-0-3] NALEŻY usunąć dane w sposób zgodny z odpowiednimi standardami branżowymi, takimi jak NIST SP800-88.
• [C-0-4] NALEŻY wywołać powyższy proces „Resetowania danych do ustawień fabrycznych”, gdy interfejs API DevicePolicyManager.wipeData() zostanie wywołany przez aplikację Kontroler zasad urządzenia należącą do głównego użytkownika.
• MOŻE udostępnić opcję szybkiego wymazywania danych, która polega tylko na logicznym usunięciu danych.

9.13. Tryb bezpiecznego rozruchu

Android udostępnia tryb bezpiecznego rozruchu, który umożliwia użytkownikom uruchamianie urządzenia w trybie, w którym mogą działać tylko wstępnie zainstalowane aplikacje systemowe, a aplikacje innych firm są wyłączone. Ten tryb, znany jako „Tryb bezpiecznego uruchamiania”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.

Implementacje na urządzeniach:

• [SR] ZDECYDOWANIE ZALECAMY wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacja urządzenia obejmuje tryb bezpiecznego uruchamiania, to:

• [C-1-1] NALEŻY zapewnić użytkownikowi opcję uruchomienia trybu bezpiecznego rozruchu w sposób, który nie może być zakłócany przez aplikacje innych firm zainstalowane na urządzeniu, z wyjątkiem sytuacji, gdy aplikacja innej firmy jest kontrolerem zasad urządzenia i ma ustawioną flagę UserManager.DISALLOW_SAFE_BOOT jako true.

• [C-1-2] Musisz umożliwić użytkownikowi odinstalowanie dowolnej aplikacji innej firmy w trybie bezpiecznym.

• NALEŻY umożliwić użytkownikowi uruchomienie trybu bezpiecznego uruchamiania z menu uruchamiania za pomocą procesu różniącego się od normalnego uruchamiania.

9.14. Izolacja systemów pojazdów samochodowych

Urządzenia z Androidem Automotive mają wymieniać dane z krytycznymi podsystemami pojazdu, korzystając z interfejsu HAL pojazdu do wysyłania i odbierania wiadomości przez sieci pojazdu, takie jak magistrala CAN.

Wymiana danych może być zabezpieczona przez wdrożenie funkcji bezpieczeństwa poniżej warstw Androida, aby zapobiec złośliwej lub niezamierzonej interakcji z tymi podsystemami.

9.15. Plany abonamentowe

„Plany subskrypcji” to szczegóły planu rozliczeniowego udostępniane przez operatora komórkowego za pomocą SubscriptionManager.setSubscriptionPlans().

Wszystkie implementacje urządzeń:

• [C-0-1] MUST return subscription plans only to the mobile carrier app that has originally provided them.
• [C-0-2] Nie wolno tworzyć kopii zapasowych ani przesyłać planów subskrypcji zdalnie.
• [C-0-3] Dopuszcza się tylko zastąpienia, takie jak SubscriptionManager.setSubscriptionOverrideCongested(), z aplikacji operatora komórkowego, która obecnie udostępnia ważne plany subskrypcji.

10. Testowanie zgodności oprogramowania

Implementacje urządzeń MUSZĄ przejść wszystkie testy opisane w tej sekcji. Pamiętaj jednak, że żaden pakiet testów oprogramowania nie jest w pełni kompleksowy. Dlatego zalecamy deweloperom urządzeń, aby wprowadzali jak najmniej zmian w dostępnej w ramach Projektu Android Open Source referencyjnej i preferowanej implementacji Androida. Pozwoli to zminimalizować ryzyko wprowadzenia błędów, które powodują niezgodności wymagające ponownego wykonania i potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje na urządzeniu:

• [C-0-1] Musi przejść testy zgodności Android Compatibility Test Suite (CTS) dostępne w ramach projektu Android Open Source, używając oprogramowania do ostatecznej wersji urządzenia.

• [C-0-2] NALEŻY zapewnić zgodność w przypadku niejednoznaczności w CTS oraz w przypadku każdej ponownej implementacji części kodu źródłowego referencyjnego.

Test CTS jest przeznaczony do uruchamiania na rzeczywistym urządzeniu. Podobnie jak inne oprogramowanie, CTS może zawierać błędy. Wersje CTS będą wydawane niezależnie od tej definicji zgodności, a w przypadku Androida 10 może być udostępnionych kilka wersji CTS.

Implementacje na urządzeniu:

• [C-0-3] Musi przejść najnowszą wersję CTS dostępną w momencie ukończenia oprogramowania urządzenia.

• NALEŻY w jak największym stopniu korzystać z implementacji referencyjnej w drzewie Android Open Source.

10.2. Weryfikator CTS

Narzędzie CTS Verifier jest dostępne w ramach pakietu Compatibility Test Suite i ma być używane przez operatora w celu testowania funkcji, których nie można przetestować za pomocą automatycznego systemu, np. prawidłowego działania kamery i czujników.

Implementacje na urządzeniu:

• [C-0-1] MUSI prawidłowo wykonać wszystkie odpowiednie przypadki w weryfikatorze CTS.

Narzędzie CTS Verifier zawiera testy wielu rodzajów sprzętu, w tym niektórych opcjonalnych.

Implementacje na urządzeniu:

• [C-0-2] Musi przejść wszystkie testy sprzętowe, które posiada. Jeśli na przykład urządzenie ma akcelerometr, MUSI poprawnie wykonać test akcelerometru w CTS Verifier.

Przypadki testowe funkcji oznaczonych w tym dokumencie definicji zgodności jako opcjonalne MOGĄ zostać pominięte.

• [C-0-2] Każde urządzenie i każda kompilacja MUSZĄ prawidłowo działać z narzędziem CTS Verifier, jak opisano powyżej. Ponieważ jednak wiele wersji jest bardzo podobnych, implementatorzy urządzeń nie muszą uruchamiać narzędzia CTS Verifier w przypadku wersji, które różnią się tylko nieznacznie. W szczególności implementacje urządzeń, które różnią się od implementacji, która przeszła weryfikację CTS Verifier, tylko pod względem zestawu obsługiwanych języków, marki itp., MOGĄ pominąć test CTS Verifier.

11. Oprogramowanie z możliwością aktualizacji

• [C-0-1] Implementacje urządzeń MUSZĄ zawierać mechanizm zastępujący cały system operacyjny. Mechanizm nie musi wykonywać aktualizacji „na żywo”, czyli może być wymagane ponowne uruchomienie urządzenia. Można użyć dowolnej metody, o ile pozwala ona na zastąpienie całego fabrycznie zainstalowanego oprogramowania. Na przykład dowolne z tych rozwiązań spełni to wymaganie:

  • Bezprzewodowe (OTA) pobieranie 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 kasowania danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachowywać prywatne i udostępnione dane aplikacji. Pamiętaj, że oprogramowanie Androida na poziomie dostawcy zawiera mechanizm aktualizacji, który spełnia ten wymóg.

• [C-0-3] Cała aktualizacja MUSI być podpisana, a mechanizm aktualizacji na urządzeniu MUSI weryfikować aktualizację i podpis za pomocą klucza publicznego przechowywanego na urządzeniu.

• [C-SR] Zalecamy, aby mechanizm podpisywania szyfrował aktualizację za pomocą algorytmu SHA-256 i sprawdzał skrót za pomocą klucza publicznego za pomocą algorytmu ECDSA NIST P-256.

Jeśli implementacje urządzeń obejmują obsługę nielimitowanego połączenia danych, takiego jak 802.11 lub profil Bluetooth PAN (Personal Area Network), muszą:

• [C-1-1] MUSI obsługiwać pobieranie OTA z aktualizacją offline przez ponowne uruchomienie.

W przypadku implementacji urządzeń z Androidem 6.0 lub nowszym mechanizm aktualizacji POWINIEN obsługiwać weryfikację, czy obraz systemu jest identyczny z oczekiwanym wynikiem po aktualizacji OTA. Implementacja OTA na podstawie bloków w ramach projektu źródłowego Android Open Source, dodanego w Androidzie 5.1, spełnia ten wymóg.

Implementacje urządzeń powinny też obsługiwać aktualizacje systemu A/B. AOSP wdraża tę funkcję za pomocą interfejsu HAL sterowania uruchamianiem.

Jeśli po wydaniu urządzenia, ale w ramach jego rozsądnego okresu użytkowania, który został ustalony w konsultacji z zespołem ds. zgodności Androida, zostanie w nim znaleziony błąd wpływający na zgodność aplikacji innych firm, należy:

• [C-2-1] Implementator urządzenia MUSI poprawić błąd za pomocą aktualizacji oprogramowania, którą można zastosować zgodnie z opisanym mechanizmem.

Android zawiera funkcje, które umożliwiają aplikacji Właściciel urządzenia (jeśli jest dostępna) kontrolowanie instalacji aktualizacji systemu. Jeśli podsystem aktualizacji systemu dla urządzeń raportuje android.software.device_admin, to:

• [C-3-1] NALEŻY zaimplementować zachowanie opisane w klasie SystemUpdatePolicy.

12. Historia zmian dokumentu

Aby uzyskać podsumowanie zmian w definicji zgodności w tej wersji:

• Zmiany w dokumentacji

Podsumowanie zmian w poszczególnych sekcjach:

1. Wprowadzenie
2. Typy urządzeń
3. Oprogramowanie
4. Opakowanie aplikacji
5. Multimedia
6. Narzędzia i opcje dla programistów
7. Zgodność sprzętowa
8. Wydajność i moc
9. Model zabezpieczeń
10. testy zgodności oprogramowania,
11. Oprogramowanie z możliwością aktualizacji
12. Historia zmian dokumentu
13. Skontaktuj się z nami

12.1. Wskazówki dotyczące wyświetlania historii zmian

Zmiany są oznaczone w ten sposób:

• CDD
  Znaczne zmiany wymagań dotyczących zgodności.

• Dokumenty
  Zmiany kosmetyczne lub związane z kompilacją.

Aby zapewnić najlepszą widoczność, dodaj parametry adresu URL pretty=full i no-merges do adresów URL strony z informacjami o zmianach.

13. Skontaktuj się z nami

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