Definicja zgodności z Androidem 10

1. Wprowadzenie

Ten dokument zawiera listę wymagań, które muszą zostać 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. „Wdrażanie urządzenia” lub „wdrażanie” 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 zapewnić 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 wymiany 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 pakietu SDK Androida i pod względem funkcjonalności jest 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ą uważane za część tej definicji zgodności.

1.1 Struktura dokumentu

1.1.1. Wymagania według typu urządzenia

Sekcja 2 zawiera wszystkie wymagania dotyczące konkretnego typu urządzenia. Każda sekcja w sekcji 2 dotyczy konkretnego typu 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 MOCNO ZALECANE są oznaczone jako [SR], ale nie przypisano do nich 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] MUSISZ 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 nie mogą 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ępnić funkcję ekranu głównego na wszystkich wyświetlaczach zgodnych z Androidem, które wyświetlają ekran główny.
• [7.2.3/H-0-4] Musisz zapewnić 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 zalecamy uruchomienie wybranej przez użytkownika aplikacji asystującej, czyli aplikacji, która implementuje interfejs VoiceInteractionService, lub aktywności obsługującej 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, musi:

• [7.3.1/H-1-1] Musi być możliwe raportowanie zdarzeń z częstotliwością co najmniej 100 Hz.

Jeśli implementacje urządzeń przenośnych zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, 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 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 limitem danych, 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 prywatnych danych 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).

„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 udostępnić aplikację z implementacją android.service.vr.VrListenerService, którą można włączyć za pomocą android.app.Activity#setVrModeEnabled w aplikacjach VR.

Jeśli implementacja urządzenia przenośnego obejmuje co najmniej 1 port USB-C w trybie hosta i implementuje (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 oprogramowania kodów HID:

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

Gdy wykryto terminal 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 terminal audio USB typu 0x0402:

• [7.8.2.2/H-3-1] NALEŻY nadać Intent ACTION_HEADSET_PLUG z dodatkowym parametrem „microphone” ustawionym na 1.

Gdy wywołysz interfejs API AudioManager.getDevices() podczas podłączenia 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] W polu typu terminala audio USB (type) musi być podany typ 0x0402.

• [7.8.2.2/H-4-3] W przypadku pola typu terminala audio USB o wartości 0x0402 MUSISZ podać urządzenie typu AudioDeviceInfo.TYPE_USB_HEADSET i role isSource().

• [7.8.2.2/H-4-4] NALEŻY 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] Musisz podać urządzenie typu AudioDeviceInfo.TYPE_USB_DEVICE i role isSource(), jeśli pole typu terminala audio USB ma wartość 0x604.

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

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

• [7.8.2.2/H-SR] W przypadku podłączenia urządzenia peryferyjnego USB-C MOCNO zaleca się wykonanie enumeracji deskryptorów USB, zidentyfikowanie typów terminali i wysłanie Intencji ACTION_HEADSET_PLUG w mniej niż 1000 ms.

2.2.2. Multimedia

Implementacje na urządzeniach 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 mniejszym 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 uruchamiającej, 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] Aplikacje innych firm MUSZĄ umożliwiać 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 wdrożenia 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] MOCNO ZALECAMY wyświetlanie w pasku powiadomień pierwszej opcji dostępnej w RemoteInput.Builder setChoices() bez dodatkowej interakcji użytkownika.
• [3.8.3/H-SR] MOCNO 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] MOCNO POLECAMY wyświetlanie działań, 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 na urządzeniach przenośnych obsługują działanie Asystenta, 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, muszą:

• [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ę) lub o większej funkcjonalności, zgodnie z projektem 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 dla 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 od lewej lub prawej krawędzi 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 powinno być mniejsze niż 1 raz na sekundę.
• [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 w mniej niż 36 sekund, zgodnie z wymaganiami pakietu testów zgodności (CTS) dla 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ść zapisu sekwencyjnego 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ść odczytu losowego 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 wartość bieżącego 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ą:

• [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żytkowania 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 wykonawczym 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. Projekt Android Open Source udostępnia interfejs HAL (Gatekeeper 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, nie dłuższego 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 w trybie 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]* Musi udostępniać użytkownikowi powłoki binarną wersję /system/bin/perfetto, której wiersz poleceń jest zgodny z dokumentacją perfetto.
  • [6.1/H-0-3]* Plik binarne 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 zapisywać 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 te źródła danych, które są opisane w dokumentacji perfetto.

2.3. Wymagania dotyczące telewizji

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 siedzących 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 zgłaszanie 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.

„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 przy 30 klatkach 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ą deinterlaceować 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 sprzętowymi dekoderami 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 klatek na sekundę 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 (8-bitowa głębia koloró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 szybkością 60 FPS z profilem 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] Większość urządzeń zaleca się, aby obsługiwały tryb obrazu w obrazie (PIP) w wielu oknach.
• [3.10/T-0-1] MUSI obsługiwać zewnętrzne usługi ułatwień dostępu.
• [3.10/T-SR] ZALECAMY WYMAGANIE, aby na urządzeniu były wstępnie załadowane usługi 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 zaleca się 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 powinno być mniejsze niż 1 raz na sekundę.
• [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ść odczytu sekwencyjnego co najmniej 15 MB/s.
• [8.2/T-0-4] NALEŻY zapewnić wydajność odczytu losowego na poziomie co najmniej 3,5 MB/s.

Jeśli implementacje telewizorów zawierają funkcje poprawiające zarządzanie energią urządzenia, które są zawarte w AOSP, lub rozszerzają funkcje zawarte 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ę:

• [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 energii 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 izolacyjnym środowisku wykonawczym.
• [9.11/T-0-2] MUSI zawierać 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 wykonawczym 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. Projekt Android Open Source udostępnia interfejs HAL (Gatekeeper 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 MUSI obsługiwać profili z ograniczonymi uprawnieniami, ale MUSI być zgodna z implementacją ustawień w 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] Binar perfetto MUSI przyjmować 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 pakietu 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 zegarek, 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 Androidem:

• [7.1.1.1/W-0-1] Musi mieć ekran o fizycznej przekątnej w zakresie 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] MUSI zgłaszać pomiary GNSS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
• [7.3.3/W-1-2] MUST report GNSS pseudoranges and pseudorange rates, that, in conditions of 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 być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.

Implementacje na urządzeniach z Androidem:

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

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

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

Nie ma dodatkowych wymagań.

2.4.3. Oprogramowanie

Implementacje na urządzeniach z Androidem:

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

• [3.8.4/W-SR] MOCNO POLECAMY wdrożenie na urządzeniu asystenta, który będzie obsługiwał 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ć zewnętrzne usługi ułatwień dostępu.

• [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 POLECAĆ wyświetlanie 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 Androidem:

• [8.4/W-0-1] MUSISZ podać profil zasilania dla poszczególnych komponentów, który definiuje wartość bieżącego zużycia 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/W-0-2] Musisz podać wszystkie wartości zużycia energii w miliamperogodzinach (mAh).
• [8.4/W-0-3] MUSI raportować zużycie 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.
• [8.4/W-0-4] DEWELOPER APLIKACJI 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, muszą:

• [9.5/W-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.

2.5. Wymagania dotyczące pojazdó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ę Wróć do ekranu głównego i 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 przytrzymania 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 dniem lub nocą w panelu i powinna być określana na podstawie 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 do mapy.

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, to:

• [7.3.4/A-2-1] MUSI być w stanie zgłaszać zdarzenia 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 Bluetootha:

  • 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ŻESZ 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 obraz 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ę widoku zewnętrznego, w przypadku takiej kamery:

• [7.5/A-1-1] Nie wolno używać kamer zewnętrznych dostępnych za pomocą interfejsów API aparatu Androida, chyba że spełniają 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 automatycznego ustawiania ostrości sprzętowej lub programowej w sterowniku aparatu.

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 wewnętrznej pamięci niewymiennej, 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.

„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 małym 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 obsłuży działanie asystenta.

Jeśli w przypadku wdrożeń 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 „Naciśnij, aby mówić” 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ć domyślną akcję CAR_INTENT_ACTION_MEDIA_TEMPLATE z dodatkiem CAR_EXTRA_MEDIA_PACKAGE.
• [3.14/A-0-4] Musisz umożliwić przejście do aktywności preferencyjnej aplikacji multimedialnej, ale musisz to umożliwić tylko wtedy, gdy ograniczenia dotyczące UX w samochodzie nie są aktywne.
• [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ć stale widoczny pasek stanu i pasek nawigacyjny.
• [3.8/A] MOŻE ograniczyć prośby aplikacji, aby ograniczyć możliwość zmiany kolorów elementów interfejsu systemu, tak aby były one wyraźnie widoczne przez cały czas, zgodnie z opisem w WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS i WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION.

2.5.4. Wydajność i moc

Implementacje na urządzeniach samochodowych:

• [8.2/A-0-1] 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 poboru mocy dla poszczególnych komponentów, który definiuje wartość bieżącego 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/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 użytkownikiem systemu bez głowy ani na przełączenie się na niego, z wyjątkiem zarządzania urządzeniami.
• [9.5/A-1-2] Przed BOOT_COMPLETED musisz przejść na użytkownika pomocniczego.
• [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 wykonawczym 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. Projekt Android Open Source udostępnia interfejs HAL (Gatekeeper 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 sprzęt zabezpieczający, a podpisywanie odbywa się na sprzęcie zabezpieczonym. 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 z rozblokowanego do zablokowanego stanu spoczynku, przy czym minimalny dopuszczalny 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] Musi 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ŻE implementować interfejs API Android Open Accessory (AOA).

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 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ń typu tablet obsługują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony, muszą:

• [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 Android udostępnianych 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 ozdobionego znacznikiem „@SystemApi” w górnym kodzie ź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 ani dołączać operacji pustych, z wyjątkiem przypadków, w których jest to wyraźnie dozwolone przez tę definicję zgodności.

• [C-0-4] Musisz zachować interfejsy API i działać 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 wolno zezwalać aplikacjom innych firm na korzystanie z 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 ukryty interfejs API do dowolnej z list ograniczeń.

• [C-0-7] Musi obsługiwać mechanizm aktualizacji dynamicznej za pomocą podpisanej konfiguracji, aby usuwać interfejsy inne niż SDK z listy ograniczeń przez umieszczanie podpisanej konfiguracji w dowolnym pliku APK przy użyciu 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 dozwolonym wersjom dla każdego poziomu interfejsu API. Na przykład implementacje na urządzeniach z Androidem 7.0, które korzystają z poziomu 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 WYMAGA 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 jedną z tych przesłanek:
  • 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ękkie” interfejsy API działające tylko w czasie działania, takie jak intencje, uprawnienia i inne aspekty 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 budowy

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 i znaczeniowe 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 co najmniej 1 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
  • Program uruchamiający
  • 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 umożliwiający 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 danych URI. 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ępniać użytkownikowi odpowiednie zastąpienia wzorców dla poszczególnych adresów 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ą ciągu znaków ACTION, CATEGORY lub innego klucza 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 urządzeń MOGĄ zawierać wzorce intencji korzystające z 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] NALEŻY 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ć na android.telecom.CallRedirectionService aplikacji, która ma rolę android.app.role.CALL_REDIRECTION.

• [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, który ma 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] ZALECAMY używanie implementacji bibliotek wymienionych poniżej z 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 interfejsem 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 należy zgłaszać informacje. NALEŻY NIE zgłaszać żadnych ABI, których nie ma na 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 (wbudowane wsparcie dla 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 (logowanie 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ę kolejnych 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] Musisz też obsługiwać armeabi-v7a i zgłaszać tę obsługę, ponieważ armeabi jest przeznaczone 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 wtedy, gdy 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ądzeniu 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 informacje o mobilności.

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

• [C-1-4] NALEŻY renderować dostarczone treści lub treści z dostępnego zdalnie 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 to wymaganie.

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 stron internetowych, 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 organy standaryzacyjne zajmujące się tworzeniem 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 stosowania 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 standardowej intencji.
• [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 dostarczanych do 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 w celu wykonania zadania widocznego 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ć podanych 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 poniżej liście dostawców.
  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 wszystkich. Implementator jest odpowiedzialny za zapewnienie zgodności z zachowaniem projektu Android Open Source. Dlatego implementatorzy urządzeń powinni w miarę możliwości korzystać z kodu źródłowego dostępnego w ramach Projektu Android Open Source, a nie ponownie implementować istotnych części systemu.

3.5.1. Ograniczenie działania w tle

Jeśli implementacje na urządzeniach zawierają ograniczenia aplikacji zawarte w AOSP lub rozszerzają te ograniczenia, 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 mogą być określane przez implementatorów urządzenia, ale MUSZĄ być związane z wpływem aplikacji na stan systemu. Nie wolno używać innych kryteriów, które nie są związane z działaniem systemu, np. braku 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ŻE ograniczać głównej aplikacji na pierwszym planie, z której użytkownik wyraźnie korzysta.
• [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 rozpocznie korzystanie z aplikacji, która była wcześniej ograniczona.

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 tych 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] Nie wolno dodawać do interfejsów API w wymienionych powyżej przestrzeniach nazw ż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ą źródłową Androida i zgodnie z tabelą 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 architekturach docelowych, aby zapewnić stabilność środowiska uruchomieniowego. Na stronie Projektu Android Open Source znajdziesz informacje o narzędziach JFuzz i DexFuzz.

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 (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ń implementują domyślny program uruchamiający, który zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm za pomocą interfejsu ShortcutManager API, 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] NALEŻY 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 wyszukiwarce.
• [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ń czy paska systemowego).

3.8.3.1. Prezentacja powiadomień

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

• [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. Więcej informacji o tym 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ż w przypadku referencyjnej implementacji 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 również 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 MUSI wyświetlać się wszystkie zasoby, w tym ikony udostępnione przez android.app.Person.
• [C-SR] MOCNO ZALECAMY 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 zamknął powiadomienie.
• Powinien obsługiwać powiadomienia z elementami rozszerzonymi.
• NALEŻY wyświetlać niektóre powiadomienia o wyższym priorytecie 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 o zbliżającym się terminie:

• [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 we wszystkich zainstalowanych usługach odsłuchujących, w tym wszystkie metadane dołączone 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 wstrzymanego za pomocą standardowych interfejsów API, takich jak NotificationListenerService.getSnoozedNotifications().
• [C-2-2] NALEŻY udostępnić użytkownikom możliwość odkładania 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 gdy implementacja na urządzeniu umożliwia użytkownikowi zezwolenie lub odmowę zezwolenia aplikacjom innych firm na dostęp do konfiguracji zasad DND, należy wyświetlić automatyczne zasady DND 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 ich 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 zachowanie to wyświetlanie sugestii i wyników 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, 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. Udostępnianie kontekstu powinno być możliwe tylko wtedy, gdy użytkownik wywoła aplikację asystenta za pomocą słowa kluczowego lub przycisku nawigacyjnego.
• [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ć użytkownikowi krótkie niemodalne ciągi znaków, które znikają po krótkim czasie, oraz interfejsu API typu okna TYPE_APPLICATION_OVERLAY, aby wyświetlać okna alertów jako nakładki na inne aplikacje.

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

• [C-1-1] NALEŻY umożliwić użytkownikowi zablokowanie 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] Musisz obsługiwać interfejs Toast API i wyświetlać komunikaty Toast z aplikacji do użytkowników 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ępnionych 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) i 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Ą zmieniać 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 odpowiedni 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ż tapeta na żywo korzysta z kontekstu OpenGL, który może wchodzić w kolizję z innymi aplikacjami, które również korzystają z tego kontekstu.

• Urządzenia, które mogą niezawodnie wyświetlać tapety na żywo w sposób opisany powyżej, POWINNY obsługiwać tapety na żywo.

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

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

3.8.8. Przełączanie aktywności

W upstreamowym kodzie źródłowym Androida znajduje się ekran przeglądu, czyli interfejs użytkownika na poziomie systemu umożliwiający 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 Ostatnie, opisane w sekcji 7.2.3, MOGĄ zmienić interfejs.

Jeśli implementacje urządzeń, w tym klucz nawigacji funkcji ostatnich, 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 do momentu, gdy 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 użytkownik dwukrotnie kliknie przycisk funkcji Ostatnio używane.
• POWINIEN aktywować tryb wielookienkowy (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 interfejsu Androida (lub podobnego interfejsu opartego na miniaturach).

3.8.9. Zarządzanie wejściami

Android obsługuje zarządzanie wprowadzaniem oraz edytory metod wprowadzania 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 na urządzeniu 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, aby wyświetlić domyślne menu ustawień aplikacji, w którym można włączyć i wyłączyć autouzupełnianie oraz zmienić domyślną usługę 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 interakcję z aplikacjami, gdy urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji dokującej. Urządzenia z Androidem Watch MOGĄ implementować wygaszacze, ale inne typy urządzeń MUSZĄ 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ć bieżący 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 renderowania języków mjanma używa się kilku czcionek niezgodnych z Unicode, powszechnie znanych jako „Zawgyi”.

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

* [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] Musisz zaimplementować takie tryby wielookienności zgodnie z zachowaniem aplikacji i interfejsami API opisanymi w dokumentacji obsługi trybu wielookienności pakietu SDK Androida oraz spełniać te wymagania:
• [C-1-2] Musi obsługiwać 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 rozmiarze 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ć rozmiarem.
• [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 z dockowanej aktywności.

Jeśli implementacje urządzeń obsługują tryb wielu okien i tryb obrazu 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 zaimplementowany, 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ą:

• [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 zarejestrować się 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 żądania NALEŻY wymagać od użytkownika podjęcia jakiegoś działania, aby wyraził zgodę na ustawienie aplikacji jako właściciela urządzenia. Zgodę można uzyskać za pomocą działania użytkownika lub za pomocą pewnych programowych środków podczas obsługi, ale NIE można jej zakodować na stałe ani uniemożliwić korzystania z innych aplikacji właściciela urządzenia.

Jeśli implementacje na urządzeniu 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 na Androidzie, to:

• [C-2-1] Konieczne jest wdrożenie procesu weryfikacji, który sprawdza, czy promowana aplikacja należy do legalnego rozwiązania do zarządzania urządzeniami w firmie i czy została już skonfigurowana w ramach rozwiązania firmowego, aby mieć 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 przypadku procesu inicjowanego 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] NALEŻY zaimplementować 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 (proces inicjowany przez 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):

  • Ujednolicony symbol lub inny element interfejsu użytkownika (np. ikona informacji o AOSP na upstreamie) wskazujący, ż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ŁUCHANIA: użyj 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 intencji” MUSI być widoczna opcja pozwalająca użytkownikowi przekazać intencję z profilu zarządzanego do głównego użytkownika lub odwrotnie, jeśli jest to możliwe w ramach kontrolera 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 zezwala na to.
• [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Ą używać 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 trwającym i nieodebranych połączeniach, kontaktach i aplikacjach do obsługi wiadomości, powinny być oznaczone tym samym znacznikiem, który służy do wskazywania aplikacji na profilu zarządzanym.

3.9.3 Pomoc dla użytkowników zarządzanych

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. Android udostępnia też 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] NALEŻY przestrzegać zamiaru 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 zaimplementować 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 ramowego systemu 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 i zewnętrznych danych wejściowych na podstawie TIF, oraz z niej korzystać 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 na urządzeniach obejmują element interfejsu Szybkich ustawień, muszą:

• [C-1-1] Musisz umożliwić 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 multimedió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] Musisz wyświetlać ikonę aplikacji innej firmy, gdy prezentujesz 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.
  • docelowe jest jawnie udostępniane 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. Dostęp do tej funkcji mają aplikacje korzystające z interfejsu CompanionDeviceManager.

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 musi być zainstalowana tylko 1 aplikacja, która określa cantSaveState. Jeśli użytkownik opuści taką aplikację bez jej zamykania (np. naciśnie przycisk Home, gdy w systemie jest aktywna aktywność, zamiast nacisnąć przycisk Wstecz, gdy w systemie nie ma żadnych aktywnych aktywności), implementacje na urządzeniu 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 jej przypadku funkcje zarządzania energią, takie jak ograniczanie dostępu do procesora i do sieci.
• [C-1-2] Musisz zapewnić w interfejsie 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] NIE WOLNO stosować innych zmian w zasadach do aplikacji, które określają cantSaveState, 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 MOŻESZ 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 w aplikacji aktywności oznaczonej przez ten sam interfejs API PackageManager.setHarmfulAppWarning jako potencjalnie szkodliwej.

• 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 raportowane w CamcorderProfile.

Implementacje na urządzeniu:

• NALEŻY dążyć do minimalnej latencji 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 PCM 16-bitowe w natywnym porządku 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 (profil HE AAC rozszerzony ISO/IEC 23003-3, który obejmuje profil podstawowy 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 dźwięku 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ć przeprowadzone bez downmixowania (np. strumień AAC 5.0 MUSI być zdekodowany do 5 kanałów PCM, a strumień AAC 5.1 MUSI być zdekodowany do 6 kanałów PCM).
• [C-2-2] Metadane zakresu dynamicznego MUSZĄ być zdefiniowane zgodnie z „Dynamic Range Control (DRC)” w normie 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 opisane powyżej.

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 są obecne metadane ISO/IEC 23003-4 oraz ISO/IEC 14496-3, wykonaj te czynności:

• Należy stosować 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 obrazu w tych formatach:

• [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] NALEŻY dostarczyć koder HEVC z akceleracją sprzętową, 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 typó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 nie mogą też 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 obsługujące format o wysokiej głębi bitowej (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żywany format wyjściowy 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 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 uruchamianie kodeków oprogramowania OMX w procesie kodeka, który nie ma dostępu do sterowników sprzętowych innych niż mapery pamięci.

Jeśli implementacje urządzeń 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 UŻYWAĆ odpowiedniego kodeka Codec 2.0 z projektu Open Source Androida (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 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ć określony 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 o wydajności.
• Dodatkowo powinni opublikować rozszerzone punkty dotyczące skuteczności, jeśli obsługują trwałą skuteczność filmu inną niż standardowa wymieniona powyżej.

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 POWINIEN przekraczać 100% szybkości transmisji danych w przesuwalnym oknie 1 sekundy.

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 udostępnić ją aplikacjom 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ć mu zasobnik bitów na podstawie tego czasu trwania.

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 przyspieszeniem sprzętowym 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 (niepotrzebne 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 wymienione 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 WebM w formacie Matroska.
• NALEŻY zapewnić sprzętowy kodek VP8, który spełnia wymagania projektu WebM RTC dotyczące kodowania na sprzęcie, 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 wymienione 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 Matroska.
• [C-1-3] MUSI generować dane CodecPrivate.
• NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• [SR] MOCNO ZALECAMY 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ć poziomy profilu podstawowego 30 i 45.

5.3.3. MPEG-4

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

• [C-1-1] Musi obsługiwać profil prosty poziomu 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 (zduplikowane 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ść zwrócona 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 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 dla profili HDR10Plus 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 poniższej tabeli.

5.3.7. VP9

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

• [C-1-1] MUSI obsługiwać profile dekodowania 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ść zwrócona 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ń twierdzą, że 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 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-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 Androida 4.3 oznaczone jako „NALEŻY”, w definicji zgodności w przyszłych wersjach zostaną one zmienione na „NALEŻY”. Istniejące i nowe urządzenia z Androidem MUSZĄ spełniać te wymagania, 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 surowego dźwięku o tych właściwościach:

  • 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 uwzględnić odpowiedni filtr antyaliasingu, gdy wymienione powyżej częstotliwości próbkowania 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 stosunku 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. Uchwyć głos na potrzeby 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 stosunku do 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 redukcji szumów 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ądzeniu 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_ZALECANE jest zadeklarowanie tego za pomocą metody interfejsu API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
• [C-SR] MOCNO_ZALECANA możliwość sterowania tym efektem dźwiękowym za pomocą interfejsu AcousticEchoCanceler API.
• [C-SR] ZALECAMY jednoznaczne identyfikowanie każdej implementacji technologii AEC za pomocą pola AudioEffect.Descriptor.uuid.

5.4.5. Nagrywanie równoległe

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] NALEŻY 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 z innych aplikacji (z wyjątkiem usług 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:

• POWINIEN mieć w zakresie średnich częstotliwości w przybliżeniu płaską charakterystykę amplitudy w funkcji częstotliwości: dokładnie ±3 dB od 100 Hz do 4000 Hz w przypadku 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 wynoszącą 2500 dla próbek 16-bitowych (lub -22,35 dB w przypadku próbek z precyzją zmiennoprzecinkową/podwójną) dla każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania mowy.
• [C-SR] BARDZO ZALECAMY, aby poziomy amplitudy w zakresie niskich częstotliwości (od ±20 dB w zakresie 5–100 Hz) były porównywalne z zakresem średnich częstotliwości w przypadku każdego mikrofonu używanego do nagrywania źródła dźwięku do rozpoznawania głosu.
• [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 urządzenie wyjściowe dźwięku zgodnie z definicją 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 surowego dźwięku 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ądzeniu 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.
• NALEŻY 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, używając typu treści lub użycia zgodnie z definicją w AudioAttributes i użycia dźwięku w samochodzie zgodnie z publiczną definicją 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 środowisku na przetworniku na urządzeniu lub sygnał opuszcza urządzenie przez port i może być obserwowany zewnętrznie.
• 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 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 wejścia „na zimno”.
• 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 wyjścia zwrócona 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 wyjścia „na zimno”.
• [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 zimnego wyjścia na co najmniej 1 obsługiwanym urządzeniu wyjściowym 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 spełnianie wymagań dotyczących 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ądzeniu 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ą następujących 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ścia audio:

• [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] Minimalizuj 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ę protokołu 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, to:

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

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 przenośne z obsługą MIDI, dla których zapewniają one ogólne połączenia nie-MIDI. Takie urządzenia przenośne:

  • 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 API kolejki bufora OpenSL ES PCM oraz co najmniej 1 ścieżki interfejsu API dźwięku natywnego 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] Opóźnienie wyjściowe w przypadku zimnego uruchomienia MUSI wynosić 200 ms lub mniej.
• [C-1-7] Czas reakcji na zimny start musi wynosić 200 ms lub mniej.
• [SR] MOCNO ZALECANA jest zapewnienie stabilnego poziomu wydajności procesora podczas odtwarzania dźwięku i zmiennego obciążenia procesora. Należy to przetestować, używając wersji aplikacji na Androida z identyfikatorem zatwierdzenia SynthMark 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark używa syntezatora programowego działającego w 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 względem 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 przesyłanego 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 procentowy udział w pełnej przepustowości procesora w wywołaniu zwrotnym.
• POWINNA zapewniać brak zakłóceń dźwięku przy normalnym użytkowaniu przy zgłoszonym opóźnieniu.
• 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 stronami 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 dotykowe.
• 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, aby zgłosić obsługę 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 ścieżce audio przez złącze audio.
• [SR] ZALECAMY stosowanie się do sekcji Specyfikacja urządzenia mobilnego (gniazdo) w specyfikacji przewodowych słuchawek nausznych (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, a 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 trybie hosta USB przy użyciu klasy audio USB.
• Ciągłe opóźnienie w obie strony w przypadku audio NIE POWINNA 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 jednoczesne wejście/wyjście do 8 kanałów w każdą stronę, częstotliwość próbkowania 96 kHz oraz głębię 24-bitową lub 32-bitową.

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

• W przynajmniej jednej konfiguracji MUSI obsługiwać wyjście stereo i 8 kanałów z głębią bitową 20- lub 24-bitową i częstotliwością próbkowania 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] NALEŻY zgłaszać obsługę za pomocą właściwości android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] MUSI wykazywać w przybliżeniu płaską charakterystykę amplitudy w funkcji częstotliwości w zakresie średnich 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: dokładnie 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 nagrania 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 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 innej niż mnożnik poziomu, aby 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ć, aby nie powodować opóźnień na ścieżce sygnału.
• [C-1-9] Pomnażacz poziomu, mimo że może się znajdować na ścieżce, NIE MOŻE powodować opóźnień w przekazywaniu 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ń za pomocą polecenia cmd stats w powłoce i klasy interfejsu System API StatsManager.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] 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 umożliwia korzystanie z adb na znanych uwierzytelnionych hostach.

  • [C-0-6] MUSI zawierać mechanizm umożliwiający połączenie adb z maszyny hosta. Na 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).
    • MUSI zawierać sterowniki dla Windowsa 7, 9 i 10, aby umożliwić deweloperom połączenie 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 plik 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] MOCNO zalecamy podanie w pliku binarnym perfetto co najmniej źródeł danych opisanych 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ę interfejsu Vulkan 1.0 lub nowszego 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 zapewnia deweloperom możliwość konfigurowania ustawień związanych z tworzeniem aplikacji.

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

• [C-0-1] Musisz 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ć, gdy 7 razy klikną element 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 w stosunku do innej, aby włączyć opcje dla deweloperów. MUSISZ przesłać publicznie dostępny dokument lub stronę internetową z instrukcjami włączania opcji dla programistó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 do obsługi 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 na urządzeniu 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 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 obrazu. 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 = dpi * (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 w przypadku 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, można uzyskać na podstawie wartości wysokości i szerokości z interfejsów view.Display i Configuration. Muszą one spełniać te wymagania:

• [C-0-1] Wdrożenia na urządzeniach z wartością Configuration.uiMode równą UI_MODE_TYPE_NORMAL MUSZĄ mieć format obrazu o wartości mniejszej lub równej 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 elementu 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ć w żaden sposób. 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żej 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 stosowanie 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] MUST report the correct integer value with the android.hardware.vulkan.level and android.hardware.vulkan.version feature flags.
• [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] Musisz wyliczać warstwy zawarte w bibliotekach natywnych o nazwie libVkLayer*.so w katalogu bibliotek natywnych pakietu aplikacji za pomocą interfejsów API natywnych Vulkana vkEnumerateInstanceLayerProperties() i vkEnumerateDeviceLayerProperties() .
• [C-1-5] NIE wolno 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 atrybuty android:debuggable ustawione 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. NALEŻY natomiast pominąć ciągi znaków rozszerzeń, których nie obsługuje się 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] W przypadku interfejsu API natywnego Vulkan vkEnumeratePhysicalDevices() NIE MOŻNA wymieniać żadnych VkPhysicalDevice.

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 semapó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ądzeniu 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 o chęci włączenia akceleracji sprzętowej 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średnie zintegrowanie tekstur OpenGL ES przyspieszonych 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ć w stanie renderować grafikę w 16-bitowej kolorystyce.
• 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] Musisz 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 upstreamowej implementacji Androida typu open source jest dostępny mechanizm wyboru odpowiedni do stosowania na urządzeniach, które nie mają niedotykowych elementów sterujących.

7.2.3. Klawisze nawigacyjne

Funkcje Ekran główny, Ostatnie i Wstecz są zwykle dostępne po naciśnięciu odpowiedniego przycisku fizycznego lub po użyciu 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 udostępnić przyciski Ostatnie i Wstecz.

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

• [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] Musisz wyraźnie wskazać, które pojedyncze działanie uruchamia każdą funkcję. Przykłady takich wskazówek to widoczna ikona na przycisku, ikona oprogramowania na pasku nawigacyjnym lub szczegółowe instrukcje w ramach procesu 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, dwukrotnego 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, i NIE MOGĄ zasłaniać ani w inny sposób zakłócać działania części ekranu dostępnej dla aplikacji.
• [C-5-2] MUSI udostępniać 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 ekranowej nawigacji opartej na przyciskach (np. w Ustawieniach).
• NALEŻY zapewnić funkcję ekranu głównego jako przesunięcie palcem od dołu ekranu w bieżącym układzie.
• 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 to zaimplementowane w AOSP, zgodnie z dokumentacją pakietu SDK.
• [C-7-4] Jeśli 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 sterowania za pomocą wskaźnika, takie jak ekrany dotykowe, panele dotykowe i urządzenia dotykowe z fałszywym wejściem. 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łszywego dotykania 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 odpowiada podzbiorowi możliwości ekranu dotykowego. Na przykład mysz lub pilot, który steruje kursorem na ekranie, naśladuje dotyk, 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 żyroskopem, wskaźnik z żyroskopem, 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 bezdotykowego o wysokiej jakości (z wskaźnikiem), takiego jak mysz lub trackpad, 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ć na ekranie wizualny wskaźnik.
• [C-1-2] MUST report touch event with the action code that specifies the state change that occurs on the pointer going down or up on the screen.
• [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 naśladować dwukrotne dotknięcie obiektu na ekranie.
• [C-1-5] Musi obsługiwać wciśnięcie wskaźnika w dowolnym miejscu na ekranie, przesuwanie 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 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 wejść 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 kontrolerami, które spełnia ten wymóg.

1 KeyEvent

2 Powyższe zastosowania HID muszą być zadeklarowane w CA kontrolera do gier (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 odpowiednie czujniki są nieobecne itp.).

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

• [C-1-1] Zgłoszenie wszystkich pomiarów czujnika musi 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 procesor aplikacji jest aktywny, 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 Android SDK. Czas ten powinien być zsynchronizowany 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ń czujnika NIE PRZESZKADZAŁ procesorowi na wejście w stan zawieszenia lub wyjście z niego.

• 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ć tworzone na podstawie 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, jak określono w interfejsach API Androida.
• [C-1-4] MUSI być w stanie mierzyć od swobodnego spadania do 4 razy większej siły grawitacji(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, gdzie 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.
• Powinien 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 powinien zachowywać parametry kompensacji między ponownymi uruchamianiami 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.
• Należy je ustawić na wartość poniżej 2 mW i 0,5 mW, gdy urządzenie jest w stanie dynamicznym lub stałym.

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

• [C-3-1] OBOWIĄZKOWA implementacja czujników złożonych TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR] MOCNO 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] NALEŻY zastosować czujnik złożony TYPE_ROTATION_VECTOR.

7.3.2. Magnetometr

Implementacje na urządzeniu:

• [C-SR] ZALECAMY stosowanie 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, jak określono 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 WARTO, aby była 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 podczas 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 dotychczasowych i nowych urządzeń z Androidem MOCNO POLECAMY wdrożenie czujnika TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Jeśli implementacje urządzenia 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ądzeń zawierają 3-osiowy magnetometr, akcelerometr i czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR, muszą:

• [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, pomijalne wielościeżkowe, 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, gdy żądania lokalizacji są ponownie uruchamiane, do godziny po początkowym obliczeniu lokalizacji, nawet jeśli kolejne żądanie jest wysyłane bez połączenia z internetem 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 1 z Glonass, 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 POLECAMY 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] Zdecydowanie zalecamy raportowanie 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 zalecamy 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. Zalecamy też zaimplementowanie czujnika TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-4] Rozdzielczość musi wynosić co najmniej 12 bitów, a zalecana rozdzielczość to co najmniej 16 bitów.
• [C-1-5] MUSI być wyposażony w 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 standardowego 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.
• Powinien 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ń zawierają 3-osiowy akcelerometr i 3-osiowy żyroskop, muszą:

• [C-3-1] OBOWIĄZKOWA implementacja czujników złożonych TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
• [C-SR] MOCNO 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ć kompensowany temperaturowo.
• [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 wynosić co najmniej -8 g do +8 g, a powinien wynosić co najmniej -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 poboru mocy w ramach przetwarzania w partiach nie większe niż 3 mW.
  • [C-SR] MOCNO ZALECAMY, aby pasmo pomiarowe 3 dB wynosiło co najmniej 80% częstotliwości Nyquista, a spektrum szumu białego mieściło 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 mieć 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 spektrum szumu białego mieściło się w tym paśmie.
  • W temperaturze pokojowej szybkość losowego chodzenia 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 wynosić ≤ 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 dotyczące jakości 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 być większy niż 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 użycie widma szumu białego o częstotliwości 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] MUSI mieć czujnik TYPE_GAME_ROTATION_VECTOR.
• [C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:
  • MUSI mieć zużycie energii nie większe niż 0,5 mW 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 włączonych czujników urządzenie NIE MOŻE zużywać więcej niż 0,5 mW, gdy jest nieruchome, i 2,0 mW, gdy się porusza:
  • 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ń przez kanał bezpośredni czujnika w przypadku czujnika głównego (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 biometrycznego.

Jeśli implementacje urządzeń obejmują bezpieczny ekran blokady, muszą:

• 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 podwójnej identyfikacji oraz bezpieczeństwa łańcucha przetwarzania danych biometrycznych. Ta klasyfikacja określa możliwości interfejsu sensora biometrycznego w połączeniu z platformą i aplikacjami innych firm. Sensory są domyślnie klasyfikowane jako Wygodne i muszą spełniać dodatkowe wymagania opisane poniżej, aby można je było sklasyfikować jako Słabe lub Silne. 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 silnych lub słabych danych biometrycznych zgodnie z definicją w tym dokumencie.

Aby zezwolić aplikacjom innych firm i implementacjom urządzeń na dostęp do kluczy w magazynie kluczy:

• [C-0-2] MUSI spełniać wymagania dotyczące silnego zdefiniowane w tym dokumencie.

Dodatkowo:

• [C-0-3] Musi być połączony z wyraźnym potwierdzeniem (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 w elemencie bezpiecznym (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 uaktualnioną wcześniejszą wersją Androida – co 72 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, liczone od momentu wykrycia danych biometrycznych do odblokowania ekranu.

Jeśli implementacje na urządzeniach 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 treści podszywających się pod inne treści nie może przekraczać 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 zostać pozyskane, odczytane ani zmienione poza odizolowanym środowiskiem wykonawczym lub za pomocą chipa z bezpiecznym kanałem do odizolowanego środowiska wykonawczego zgodnie z opisem w wytycznych dotyczących implementacji na stronie projektu Android Open Source.
• [C-2-5] W przypadku uwierzytelniania lub rejestracji na podstawie danych biometrycznych:
  • Musi obsługiwać kamerę w taki sposób, aby uniemożliwić odczytywanie lub zmienianie ramek kamery poza izolowanym środowiskiem wykonawczym, lub musi być chipem z bezpiecznym kanałem do izolowanego środowiska wykonawczego.
  • W przypadku rozwiązań z jedną kamerą RGB ramki kamery mogą być odczytywalne poza izolowanym środowiskiem wykonania, aby umożliwić wykonywanie takich operacji jak podgląd w celu rejestracji, ale nie mogą być zmieniane.
• [C-2-6] NIE NALEŻY 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] Musisz mieć bezpieczny proces przetwarzania, który uniemożliwia wstrzyknięcie danych bezpośrednio w system operacyjny lub jądro, aby nie można było sfałszować uwierzytelnienia.

  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 zwolnić je z tego wymogu.

Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako Silny, muszą:

• [C-3-1] MUSI spełniać wszystkie wymagania dotyczące słabej jakości opisane powyżej. Uaktualnianie urządzeń z wcześniejszej wersji Androida nie jest zwolnione z obowiązku stosowania wytycznych 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 sposobu uwierzytelniania (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, to:

• [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 wdrożyć pełną obsługę interfejsu API dla tej 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 udostępnia funkcje eSIM deweloperom zewnętrznym, muszą:

• [C-3-1] Musisz wdrożyć EuiccManager API.

7.4.1.1. Zgodność z blokowaniem numerów

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

• [C-1-1] 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 ‘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 wolno zapisywać danych w rejestratorze połączeń platformy.
• [C-1-5] NIE NALEŻY pisać do dostawcy usług telefonicznych w przypadku 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, pojedynczym wystąpieniem 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 powinny zostać przeniesione 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 ta aplikacja ustawia w kluczu extras PhoneAccount parametr EXTRA_LOG_SELF_MANAGED_CALLS na true.

• [C-SR] ZALECAMY, aby obsłużyć zdarzenia KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK słuchawek na podczerwień w ramach interfejsów android.telecom API w ten sposób:
  • Wywołanie Connection.onDisconnect() po wykryciu krótkiego naciśnięcia kluczowego zdarzenia podczas trwającego połączenia.
  • Wywołanie Connection.onAnswer() po wykryciu krótkiego naciśnięcia klawisza podczas połączenia przychodzącego.
  • Wywołaj funkcję Connection.onReject(), gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia.
  • Przełącz wyciszenie 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 API multicast 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. dane komórkowe), jeśli potwierdzą, że sieć Wi-Fi zapewnia dostęp do internetu.
• [C-1-6] W przypadku wywołania metody interfejsu API ConnectivityManager.reportNetworkConnectivity() zaleca się ponowną ocenę dostępu do internetu na urządzeniu Network.Jeśli po tej ocenie okaże się, że bieżące Network nie zapewnia już dostępu do internetu, należy przejść na inną dostępną sieć (np. transmisję danych mobilnych), która zapewnia dostęp do internetu.
• [C-SR] MOCNO zaleca się 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 z niskim opóźnieniem (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] 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 punktami dostępu, MUSISZ losowo generować źródłowy adres MAC.

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 utrzymania połączenia Wi-Fi.

Jeśli implementacje urządzeń obejmują obsługę funkcji 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 keepalive przez Wi-Fi i co najmniej 1 gniazdo keepalive przez sieć komórkową.

Jeśli implementacje urządzeń nie obsługują przenoszenia funkcji utrzymywania połączenia Wi-Fi, nie:

• [C-2-1] Musisz podać 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 wdrożyć odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX, HFP itp., w sposób odpowiedni dla urządzenia.

Jeśli implementacje urządzeń obejmują obsługę Bluetooth Low Energy, urządzenia te:

• [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ć reklamy wielokrotne 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, to:

• [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, jak opisano w artykule Obsługa aparatów słuchowych za pomocą Bluetooth LE, to:

• [C-5-1] W przypadku metody 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] NALEŻY zaimplementować interfejsy API android.nfc.NdefMessage i android.nfc.NdefRecord, nawet jeśli nie obsługują one NFC ani nie deklarują funkcji android.hardware.nfc, ponieważ te 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 być w stanie odczytywać i zapisywać komunikaty 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 i 5 (zdefiniowane przez NFC Forum)

• [SR] ZALECAMY, aby odczytywanie i zapisywanie wiadomości NDEF oraz danych w postaci danych nieprzetworzonych odbywało się 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 NFC Forum.

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 zawierać obsługę co najmniej jednej formy sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o szybkoś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] Musisz zapewnić aplikacjom innych firm bezpośrednią łączność IPv6 z siecią, gdy urządzenie jest połączone z siecią IPv6, bez żadnej formy tłumaczenia adresu lub portu 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ż 1 typ sieci (np. Wi-Fi i komórkową), to:

• [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ń zapewniają 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 działanie Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, pozwalając użytkownikom dodawać aplikacje do listy dozwolonych lub usuwać je z niej.

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. Bezpieczne elementy

Jeśli implementacje urządzeń obsługują interfejs Open Mobile API i zabezpieczone elementy, które są dostępne dla aplikacji innych firm, to:

• [C-1-1] W przypadku wywołania metody android.se.omapi.SEService.getReaders() należy wyliczyć dostępne czytniki Secure Elements.

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, jeśli aplikacja odbiorcza nie ma uprawnienia 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ą spełniać te wymagania:

• [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 interfejsu Camera API. Nie wolno też skonfigurować 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ć lustrzaniem końcowego obrazu stałego lub strumieni wideo zwróconych do aplikacji w ramach wywołań zwrotnych lub zapisanych 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 w przypadku tylnych aparatów 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 do kamery. 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] Na urządzeniu MUSI być dostępny jednoczesny strumień nieskompresowany / MJPEG (w rozdzielczości QVGA lub wyższej).

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 różnych semantyk obu interfejsów API, nie muszą mieć takiej samej szybkości ani jakości, ale powinny być jak najbardziej zbliżone.

Implementacje urządzeń MUSZĄ implementować te zachowania w przypadku interfejsów API związanych z aparatem w przypadku wszystkich dostępnych aparatów. 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] NALEŻY 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 nadal wdrożyć pełne Camera API zawarte w dokumentacji pakietu Android SDK, 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 aparatów. Na przykład mimo że większość przednich aparatów 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ą dokumentowane 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 użyciem wysokiego zakresu dynamicznego (HDR), MUSZĄ obsługiwać parametr kamery Camera.SCENE_MODE_HDR.
• [C-0-7] Musisz podać odpowiedni poziom obsługi za pomocą właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i przekazać 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 API android.hardware.camera2.
• 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 wszystkich urządzeń, niezależnie od ich naturalnej orientacji, 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. Pamięć i miejsce 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ć możliwe pobieranie domyślnej lokalizacji „bufora” pojedynczych plików o rozmiarze co najmniej 100 MB.

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, innymi słowy „od razu po wyjęciu z pudła”, niezależnie od tego, czy pamięć jest implementowana na wewnętrznym komponencie pamięci czy 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 skonfigurowany na potrzeby, 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 dotyczące lokalizacji, takie jak tagi GPS Exif, 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 SD;
• Część pamięci wewnętrznej (nieusuwalna) w ramach Projektu Android Open Source (AOSP).

Jeśli implementacje urządzeń korzystają z wymiennej pamięci, 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 dodatkowym 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 inencji 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 z 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ądzeń zawierają 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 rezystorów Type-C oraz MUSI wykrywać zmiany w reklamie, jeśli obsługuje USB Type-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 1.2. 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] 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 gniazdem typu 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.
• POWINNY 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ą w pakiecie 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 micro-AB na port 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; reklamować 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 wdrożyć 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 żądaniu użycia 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 o podwójnej roli 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 przesyłania danych i zasilania.
• [SR] BARDZO ZALECAMY, aby nie obsługiwać trybu akcesoriów adaptera 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ądzeń peryferyjnych z wyjściami audio, takie jak 4-przewodowe gniazdo słuchawek 3,5 mm lub port w trybie hosta USB z klasą 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 korzystającymi z wtyczki audio 3,5 mm w ekosystemie Androida, jeśli implementacje urządzeń zawierają co najmniej 1 port analogowy do przesyłania dźwięku, muszą:

• [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 mikrofonem a przewodami masy na wtyczce 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 wtedy, gdy wszystkie styki wtyczki dotykają 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 ziemią 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ść z zestawami słuchawkowymi i innymi urządzeniami audio korzystającymi z złączy USB-C i implementującymi (klasa audio USB) w całym 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 od 18,5 kHz do 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 API AudioManager.getProperty w ten sposób:

Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND ma wartość „true”, źródła dźwięku VOICE_RECOGNITION i UNPROCESSED MUSZĄ spełniać te wymagania:

• [C-1-1] Średnia moc 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 waż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 sprawdzić, czy nie występują w nich błędy, korzystając z AAudio w przypadku tych kombinacji:

Niezawodny strumień POWINIEN spełniać te kryteria w przypadku stosunku sygnału do szumu (SNR) i całkowitego zniekształcenia harmonicznego (THD) dla częstotliwości 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 stosować 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ć wersję 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 zaimplementować 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 umieścić je na liście dostępnych rozszerzeń GL.
• [C-SR] ZALECAMY wdrażanie rozszerzeń GL_EXT_external_buffer i GL_EXT_EGL_image_array oraz udostępnianie ich 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Ą być w stanie zsynchronizować dostęp do wspólnego bufora przedniego w taki sposób, aby renderowanie treści VR z wymiennym renderowaniem oczu z prędkoś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 sekcji 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, aby rozdzielczość wyświetlacza wynosiła co najmniej 2560 x 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 od 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żytkowników 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

Interfejs użytkownika może działać płynnie, jeśli są spełnione określone wymagania dotyczące aplikacji i gier, które zapewniają stałą liczbę klatek na sekundę i czas reakcji. 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ępnianie 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 ZGADAJAĆ SIĘ Z WERSJĄ AOSP.
• [C-1-4] NALEŻY wdrożyć grupy aplikacji w stanie gotowości i stan 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ń obsługują 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, jak opisano w tym pakiecie SDK.

  Podczas gdy aplikacje innych firm proszą o utrzymanie ekranu w stanie włączonym przez FLAG_KEEP_SCREEN_ON lub uruchomienie procesora przez 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 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] ZALECAMY zgłaszanie wszystkich wartości zużycia energii w miliamperogodzinach (mAh).
• [SR] ZDECYDZIE ZALECAMY zgłaszanie 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 ZALECANE: udostępnij ten tryb działania 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, które działają przez dłuższy czas. Może to być spowodowane innymi aplikacjami działającymi w tle lub ograniczeniem 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 Sustained Performance za pomocą metody interfejsu API PowerManager.isSustainedPerformanceModeSupported().

• Powinien obsługiwać tryb Sustained Performance.

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] Musisz przestrzegać interfejsu API Window.setSustainedPerformanceMode() i innych powiązanych interfejsów 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 procesorów, które mogą być zarezerwowane przez 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ć wszystkie uprawnienia 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 identyfikatorów 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 większą liczbą niż 22 żądają ich w czasie wykonywania.targetSdkVersion

Implementacje na urządzeniu:

• [C-0-3] Musisz wyświetlić użytkownikowi specjalny interfejs, aby umożliwić mu podjęcie decyzji, 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 urządzeniami pamięci masowej. Te urządzenia są wyposażone w sprzęt z zabezpieczeniami równoważnymi lub silniejszymi niż te opisane w usłudze Google Cloud Key Vault, aby zapobiec atakom z wykorzystaniem metody brute force na czynniku wiedzy związanym z ekranem 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] NALEŻY 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 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łnego dostępu, 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ą fabrycznie zainstalowaną aplikację lub jeśli chcesz zezwolić aplikacjom innych firm na dostęp do statystyk użytkowania, musisz:

• [SR] BARDZO ZALECAMY udostępnienie użytkownikom mechanizmu przyznawania i odbierania dostępu do statystyk użytkowania 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] Musisz nadal mieć aktywność, która obsługuje wzór intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale musisz go zaimplementować jako no-op, czyli tak, aby dział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 opisem 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 wykonawcze, 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 wolno 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. Nie może też przyznawać uprawnień innym aplikacjom.

• [C-0-7] Jeśli pliki .apk alternatywnych środowisk wykonawczych są uwzględnione w pliku obrazu systemu implementacji urządzenia, muszą być podpisane kluczem innym 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. aparatu lub GPS-u), 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. Obsługa 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łównego urządzenia do przechowywania danych.

Jeśli implementacje urządzeń obejmują wielu użytkowników, muszą one:

• [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 na temat 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 (inaczej /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 przed wysyłaniem specjalnych SMS-ów. 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 zidentyfikowanych za pomocą wyrażeń regularnych zdefiniowanych w pliku /data/misc/sms/codes.xml na urządzeniu. Górny projekt Android Open Source udostępnia 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, jak opisano poniżej.

Bezpieczna piaskownica Androida zawiera funkcje korzystające z systemu obowiązkowej kontroli dostępu (MAC) Security-Enhanced Linux (SELinux), piaskownicy seccomp i innych funkcji zabezpieczeń w rdzeniu 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 nie zablokowane naruszenie bezpieczeństwa spowoduje skuteczne wykorzystanie luki.
• [C-0-3] Nie wolno zezwalać użytkownikowi ani deweloperowi aplikacji na konfigurowanie SELinux ani innych funkcji zabezpieczeń implementowanych 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 grup (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 granic rozmiaru 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 użytkownika podczas działania w trybie jądra (np. sprzętowego PXN lub emulowanego 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 PAN dla sprzętu lub emulowany za pomocą 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 dostarczanych z poziomem interfejsu API 28 lub nowszym (np. CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] MOCNO ZALECAMY, aby dane jądra, które są zapisywane tylko podczas inicjalizacji, były po inicjalizacji oznaczone jako 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] W przypadku wszystkich dodatkowych komponentów przestrzeni użytkownika, które są wrażliwe na zagrożenia, MOCNO POLECAMY włączenie funkcji CFI, SCS i IntSan, 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] Aplikacje innych firm na poziomie interfejsu API 28 lub nowszym MUSZĄ działać 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, raport o błędach) z urządzenia bez jego zgody lub bez wyraźnych powiadomień.

• [C-0-2] NALEŻY wyświetlać i uzyskiwać wyraźną zgodę użytkownika, która zawiera w podstawie tę samą wiadomość co w Android Open Source Project, gdy włączone jest przesyłanie lub nagrywanie ekranu za pomocą interfejsów MediaProjection lub firmowych interfejsów API. NIE MOŻESZ udostępnić użytkownikom opcji wyłączenia 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 na pasku stanu ikonę powiadomienia o bieżącym zadaniu.

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 API systemu ContentCaptureService lub innych zastrzeżonych metod opisanych w sekcji 9.8.6 Przechwytywanie treści, 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ółdzielonej pamięci masowej 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 urzędów certyfikacji (CA) w systemie, które zostały dostarczone w ramach projektu 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 dodano użytkowy główny certyfikat uwierzytelniający.

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. w ramach wstępnego wczytania usługi VPN z uprawnieniem 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żytkownikom przełączanie funkcji „stały VPN” w aplikacji VPN innej firmy, muszą one:

• [C-3-1] W pliku AndroidManifest.xml należy zwolnić tę funkcję dla aplikacji, które nie obsługują stałej sieci VPN, przez ustawienie atrybutu 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 co najmniej 1 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 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 film, nagrane lub odtworzone przez urządzenie;
• zdarzenia związane z wprowadzaniem danych (np. klawisze, mysz, gesty, głos, wideo i ułatwienia dostępu);
• 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 zostać wykonane 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 surowej lub zaszyfrowanej przy użyciu metod tworzenia kopii zapasowych 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 jest zdefiniowany jako „taki, który umożliwia analizę tylko w ujęciu zbiorczym i uniemożliwia dopasowywanie zarejestrowanych zdarzeń lub wyników pochodnych do poszczególnych użytkowników”, aby zapobiec możliwości przeglądania jakichkolwiek danych dotyczących 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 rejestrowanie tych 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, i stosować 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ślną metodą wprowadzania 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ą wywołaną przez użytkownika w ramach sesji alarmowej (np. wybieranie numeru 112 lub wysyłanie 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 Direct Boot, 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 się uruchamiać bez żądania podania 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 komunikat ACTION_USER_UNLOCKED.
• [C-1-3] NIE wolno oferować żadnej metody odblokowania chronionego magazynu CE bez podania przez użytkownika danych logowania 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 szyfrowania zaawansowanego z 256-bitowym kluczem szyfrowania, 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 szyfrowania 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 (xattr), za pomocą klucza powiązanego 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 preferowane wdrożenie 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 prawidłowo 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 weryfikacji podczas uruchamiania w starszej wersji Androida 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) zalecanych przez NIST.
• [C-1-6] NIE wolno dopuścić do uruchomienia systemu, gdy nie udaje się przeprowadzić weryfikacji, chyba że użytkownik wyrazi zgodę na próbę uruchomienia, w którym przypadku nie wolno używać danych z niezweryfikowanych 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 POLECAMY sprawdzenie każdego etapu uruchamiania tych układów.
• [C-1-8] NALEŻY używać pamięci z funkcją ochrony przed modyfikacją: do przechowywania informacji o tym, czy bootloader jest odblokowany. 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ć magazynu 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 funkcję bezpiecznego rozruchu.
• [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, kamery) i NALEŻY użyć magazynu z funkcją wykrywania manipulacji do przechowywania metadanych używanych 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 Android Protected Confirmation API, to:

• [C-3-1] MUST report true for the ConfirmationPrompt.isSupported() API.

• [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ć importowanie lub generowanie co najmniej 8192 kluczy.
• [C-0-2] Uwierzytelnianie na ekranie blokady MUSI stosować limitowanie prób i MUSI używać algorytmu wygaszania wykładniczego. 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 magazynu kluczy 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 dopiero po pomyślnym uwierzytelnieniu zezwolić na używanie kluczy powiązanych z uwierzytelnieniem. 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. Projekt Android Open Source udostępnia interfejs HAL (Gatekeeper 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 podstawowe uwierzytelnianie oparte na fabryce wiedzy może być wspierane przez drugorzędne silne metody 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) skonfigurowała 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 najwyżej co 72 godziny przechodzić na 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 sekrecie.
• [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 flagą biometryczną (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 agenta zaufania. 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ółdzielone (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 wykonanie jednej z zalecanych metod uwierzytelniania podstawowego (np. PIN, wzór, hasło), 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.
• [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 kwalifikować się jako 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ć dostępu do jakichkolwiek informacji z StrongBox. 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] Musisz mieć prawdziwy generator liczb losowych, który generuje wyjście o jednolitej dystrybucji i nieprzewidywalnym wyniku.

• [C-1-7] Musi być odporny na próby manipulacji, w tym próby fizycznego wtargnięcia i uszkodzenia.

• [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 miejsce przechowywania, które zapewnia poufność, integralność, autentyczność, spójność i aktualność treści. Nie można odczytywać ani zmieniać danych w magazynie, z wyjątkiem sytuacji dozwolonych przez interfejsy StrongBox API.

• Aby sprawdzić zgodność z wymaganiami [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, aby zapewnić odporność na ataki z wewnętrznego źródła (IAR). Oznacza to, że osoba z dostępem do kluczy do podpisywania oprogramowania niemożliwa do zablokowania przez StrongBox nie może wyprodukować oprogramowania, które powoduje wyciek tajemnic, obchodzenie wymagań bezpieczeństwa funkcjonalnego lub w inny sposób umożliwia dostęp do poufnych danych użytkownika. Zalecane jest, aby zezwolenie na aktualizacje oprogramowania odbywało się tylko wtedy, gdy hasło głównego użytkownika zostanie podane za pomocą interfejsu IAuthSecret HAL.

9.12. Usuwanie danych

Wszystkie implementacje na urządzeniach:

• [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 POLECANE: wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacja urządzenia obejmuje tryb bezpiecznego uruchamiania, należy:

• [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 powinny wymieniać dane z podsystemami pojazdu za pomocą 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śliwemu lub niezamierzonemu oddziaływaniu na te podsystemy.

9.15. Plany abonamentowe

„Plany subskrypcji” to szczegóły planu rozliczeniowego udostępniane przez operatora komórkowego za pomocą SubscriptionManager.setSubscriptionPlans().

Wszystkie implementacje na urządzeniach:

• [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] Dozwolić należy tylko na zastąpienie, np. SubscriptionManager.setSubscriptionOverrideCongested(), w 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 odwodzonej i preferowanej implementacji Androida dostępnej w ramach Projektu Android Open Source. Pozwoli to zminimalizować ryzyko wprowadzenia błędów, które powodują niezgodności wymagające ponownego wykonania pracy i ewentualnych 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 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 dotyczące 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, nie oczekuje się, aby implementatorzy urządzeń uruchamiali narzędzie 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 zestawem obsługiwanych języków, logotypem 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 wymagać ponownego uruchomienia 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ć dane prywatne i dane udostępnione przez aplikację. 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] Silnie zaleca się, 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 uruchamianie.

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 rozruchem.

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

Oto 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.