Definicja zgodności z Androidem 8.0

1. Wprowadzenie

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

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 „implementer” to osoba lub organizacja opracowująca rozwiązanie sprzętowe lub programowe na Androida 8.0. „Wdrożeniem urządzenia” lub „wdrożeniem” jest opracowane rozwiązanie sprzętowo-programowe.

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

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

Uwaga: wymagania, które nie mają zastosowania do urządzeń z Androidem w formie tabletu, są oznaczone gwiazdką (*).

2.2.1. Sprzęt

Implementacje na urządzeniach przenośnych:

  • [7.1.1.1/H-0-1] Ekran musi mieć co najmniej 2,5 cala przekątnej.
  • [7.1.1.3/H-SR] MOCNO POLECAMY, aby umożliwić użytkownikom zmianę rozmiaru wyświetlacza.(Gęstość ekranu)
  • [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-1] MUSI zawierać funkcje Strona główna, Ostatnie i Wstecz.
  • [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).
  • [7.2.4/H-0-1] MUSI obsługiwać wprowadzanie danych za pomocą ekranu dotykowego.
  • [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ą żyroskop, muszą:

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

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.12/H-SR] Zaleca się, aby obsługiwać czujnik 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.

Implementacje na urządzeniach przenośnych:

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

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

  • [7.6.1/H-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/H-2-1] 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/H-3-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.

  • [7.6.1/H-4-1] 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ń przenośnych są 64-bitowe:

  • [7.6.1/H-5-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/H-6-1] 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/H-7-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.

  • [7.6.1/H-8-1] 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 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.

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 urządzeń przenośnych obejmują obsługę trybu VR, muszą:

  • [7.9.1/H-1-1] MUST declare the android.software.vr.mode feature.

Jeśli implementacje na urządzeniu deklarują funkcję android.software.vr.mode, muszą:

  • [7.9.1/H-2-1] Musisz umieścić w aplikacji funkcję android.service.vr.VrListenerService, którą aplikacje VR mogą włączyć za pomocą android.app.Activity#setVrModeEnabled.

Jeśli implementacje na urządzeniach przenośnych spełniają wszystkie wymagania dotyczące deklarowania flagi funkcji android.hardware.vr.high_performance, muszą:

  • [7.9.2/-1-1] NALEŻY zadeklarować flagę funkcji android.hardware.vr.high_performance.

2.2.2. Multimedia

Implementacje na urządzeniach przenośnych MUSZĄ obsługiwać te kodowania dźwięku:

  • [5.1.1/H-0-1] AMR-NB
  • [5.1.1/H-0-2] AMR-WB
  • [5.1.1/H-0-3] Profil MPEG-4 AAC (AAC LC)
  • [5.1.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
  • [5.1.1/H-0-5] AAC ELD (AAC z ulepszona kompresją i małym opóźnieniem)

Implementacje na urządzeniach przenośnych MUSZĄ obsługiwać te algorytmy dekodowania dźwięku:

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

Implementacje na urządzeniach przenośnych MUSZĄ obsługiwać te 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 metody dekodowania wideo:

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

2.2.3. Oprogramowanie

Implementacje na urządzeniach przenośnych:

  • [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ślnego programu uruchamiającego, który obsługuje przypinanie skrótów i widżetów 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.4/H-SR] MOCNO POLECAMY wdrożenie na urządzeniu asystenta, który będzie obsługiwał działanie asystenta.

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

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 załadowany mechanizm przetwarzania tekstu na mowę) zgodnie z projektem open source TalkBack.
  • [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.15/H-1-1] MUSI obsługiwać funkcję parowania urządzenia towarzyszącego.

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.
  • [8.3/H-0-1] Wszystkie aplikacje wyłączone z trybów oszczędzania energii App Standby i Doze MUSZĄ być widoczne dla użytkownika.
  • [8.3/H-0-2] Algorytmy uruchamiania, konserwacji i budzenia oraz użycie globalnych ustawień systemu w trybach oszczędzania energii App Standby i Doze NIE MOGĄ odbiegać od projektu Android Open Source.

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ą:

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.

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;
  • mieć wbudowany ekran o przekątnej większej niż 24 cale LUB mieć port wyjścia wideo, np. VGA, HDMI, DisplayPort lub bezprzewodowy port wyświetlacza;

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ą żyroskop:

  • [7.3.4/T-1-1] Musi być możliwe zgłaszanie zdarzeń z częstotliwością co najmniej 100 Hz.

Implementacje na telewizorach:

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

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 kodowania audio:

  • [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 standardy kodowania wideo:

  • [5.2/T-0-1] H.264 AVC
  • [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.
  • [5.22/T-SR] MOCNO zaleca się obsługę kodowania H.264 wideo w rozdzielczości 1080p przy szybkości 30 klatek na sekundę (fps).

Implementacje telewizorów MUSZĄ obsługiwać te metody dekodowania wideo:

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

W przypadku implementacji urządzeń telewizyjnych MOCNO POLECAMY obsługę tych funkcji dekodowania wideo:

  • [5.3/T-SR] MPEG-2

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

  • [5.3.4/T-1-1] MUSI obsługiwać profil High Profile Level 4.2 oraz profil dekodowania HD 1080p (przy 60 kl./s).
  • [5.3.4/T-1-2] MUSI być w stanie dekodować filmy z obydwoma profilami HD, jak wskazano w poniższej tabeli, i zakodowane za pomocą profilu podstawowego, profilu głównego lub profilu wysokiego poziomu 4.2

Jeśli implementacje telewizorów obsługują kodek H.265 i profil dekodowania HD 1080p, to:

  • [5.3.5/T-1-1] MUSI obsługiwać poziom głównego profilu 4.1.
  • [5.3.5/T-SR] MOCNO zalecane jest, aby obsługiwać częstotliwość 60 FPS dla rozdzielczości HD 1080p.

Jeśli implementacje telewizorów obsługują kodek H.265 i profil dekodowania UHD:

  • [5.3.5/T-2-1] Kodeki MUSZĄ obsługiwać profil Main10 Level 5 Main Tier.

Jeśli implementacje telewizorów obsługują kodek VP8, to:

  • [5.3.6/T-1-1] MUSI obsługiwać profil dekodowania HD 1080p60.

Jeśli implementacje telewizorów obsługują kodek VP8 i 720p, to:

  • [5.3.6/T-2-1] MUSI obsługiwać profil dekodowania HD 720p60.

Jeśli implementacje telewizorów obsługują kodek VP9 i dekodowanie filmów UHD, to:

  • [5.3.7/T-1-1] MUSI obsługiwać 8-bitową głębię kolorów i POWINNA obsługiwać profil VP9 2 (10-bitowy).

Jeśli implementacje telewizorów obsługują kodek VP9, profil 1080p i sprzętowe dekodowanie VP9, to:

  • [5.3.7/T-2-1] MUSI obsługiwać 60 kl./s w trybie 1080p.

Implementacje na telewizorach:

  • [5.8/T-SR] MOCNO ZALECANA obsługa jednoczesnego dekodowania chronionych strumieni. Zdecydowanie zalecamy jednoczesne dekodowanie co najmniej 2 strumyków.

Jeśli implementacje urządzeń to urządzenia z Androidem TV i obsługują rozdzielczość 4K, to:

  • [5.8/T-1-1] MUSI obsługiwać HDCP 2.2 w przypadku wszystkich zewnętrznych wyświetlaczy przewodowych.

Jeśli implementacje telewizorów nie obsługują rozdzielczości 4K, nie mogą:

  • [5.8/T-2-1] W przypadku wszystkich zewnętrznych wyświetlaczy przewodowych MUSI być obsługiwana funkcja HDCP 1.4.

Implementacje na telewizorach:

  • [5.5.3/T-0-1] MUSI zawierać obsługę systemowej głośności głównej i tłumienia 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 nie jest wykonywane dekodowanie dźwięku na urządzeniu).

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] 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 załadowany 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.2.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.

  • [8.3/T-0-1] Wszystkie aplikacje wyłączone z trybów oszczędzania energii App Standby i Doze MUSZĄ być widoczne dla użytkownika.

  • [8.3/T-0-2] Wyzwalanie, konserwacja, algorytmy budzenia i użycie globalnych ustawień systemowych trybów oszczędzania energii App Standby i Doze NIE MOGĄ odbiegać od projektu Android Open Source.

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

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

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

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

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

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

2.4.2. Multimedia

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] 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 załadowany mechanizm przetwarzania tekstu na mowę) zgodnie z projektem open source TalkBack.

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

  • [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.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.1/A-SR] MOCNO ZALECAMY uwzględnienie 3-osiowego akcelerometru.

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

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

  • [7.3.3/A-1-1] Generacja technologii GNSS MUSI być „2017” lub nowsza.

Jeśli implementacje urządzeń samochodowych zawierają żyroskop, muszą:

  • [7.3.4/A-1-1] Musi być możliwe zgłaszanie zdarzeń z częstotliwością co najmniej 100 Hz.

Implementacje na urządzeniach samochodowych:

  • [7.3.11/A] NALEŻY podać bieżący bieg jako SENSOR_TYPE_GEAR.

Implementacje na urządzeniach samochodowych:

  • [7.3.11.2/A-0-1] MUSI obsługiwać tryb dzień/noc zdefiniowany jako SENSOR_TYPE_NIGHT.
  • [7.3.11.2/A-0-2] Wartość flagi SENSOR_TYPE_NIGHT MUSI być zgodna z trybem dnia/nocy w panelu i POWINNA być oparta na danych z czujnika światła otoczenia.

  • Podrzędny czujnik jasności otoczenia MOŻE być taki sam jak fotometr.

  • [7.3.11.3/A-0-1] MUSI obsługiwać stan jazdy zdefiniowany jako SENSOR_TYPE_DRIVING_STATUS, z wartością domyślną DRIVE_STATUS_UNRESTRICTED, gdy pojazd jest całkowicie zatrzymany i zaparkowany. Konfigurowanie SENSOR_TYPE_DRIVING_STATUS zgodnie ze wszystkimi przepisami i regulacjami obowiązującymi na rynkach, na których jest on dostępny, jest obowiązkiem producentów urządzeń.

  • [7.3.11.4/A-0-1] NALEŻY podać prędkość pojazdu zdefiniowaną jako SENSOR_TYPE_CAR_SPEED.

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

  • [7.4.3/A-0-2] Implementacje Androida Automotive MUSZĄ obsługiwać te profile Bluetooth:
    • Połączenia telefoniczne przez profil zestawu głośnomówiącego (HFP).
    • Odtwarzanie multimediów za pomocą profilu dystrybucji audio (A2DP).
    • sterowanie odtwarzaniem multimediów za pomocą profilu zdalnego sterowania (AVRCP);
    • Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).

  • [7.4.3/A] NALEŻY obsługiwać profil dostępu do wiadomości (MAP).

  • [7.4.5/A] NALEŻY uwzględnić obsługę połączeń danych w sieci komórkowej.

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

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 kodowania audio:

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

Implementacje urządzeń samochodowych MUSZĄ obsługiwać te standardy kodowania wideo:

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

  • [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] Implementacje Androida Automotive MUSZĄ obsługiwać wszystkie publiczne interfejsy API w przestrzeni nazw android.car.*.

  • [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-0-1] NALEŻY zaimplementować na urządzeniu asystenta, aby obsłużyć działanie Asystenta.

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

2.2.4. Wydajność i moc

Implementacje na urządzeniach samochodowych:

  • [8.3/A-0-1] Wszystkie aplikacje wyłączone z trybów oszczędzania energii App Standby i Doze MUSZĄ być widoczne dla użytkownika.

  • [8.3/A-0-2] Algorytmy uruchamiania, konserwacji i budzenia oraz użycie globalnych ustawień systemu w trybach oszczędzania energii App Standby i Doze NIE MOGĄ odbiegać od projektu Android Open Source.

  • [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.2.5. Model zabezpieczeń

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

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

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.6. Wymagania dotyczące tabletów

Tablet z Androidem to urządzenie z Androidem, które zwykle jest używane w obu rękach, a nie w formie clamshell.

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

  • mieć źródło zasilania, które zapewnia mobilność, np. baterię;
  • mieć przekątną ekranu o długości od 7 do 18 cali;

Implementacje na tabletach mają podobne wymagania jak implementacje na urządzeniach przenośnych. Wyjątki są oznaczone symbolem * w tej sekcji i wymienione w celu informacji.

2.4.1. Sprzęt

Rozmiar ekranu

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

Minimalna 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]MAY implement the Android Open Accessory (AOA) API.

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.

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.

  • [C-0-1] Implementacje na urządzeniu MUSZĄ zawierać pełne implementacje, w tym wszystkie udokumentowane zachowania, interfejsów API udostępnionych przez pakiet SDK Androida lub interfejsów API oznaczonych znacznikiem „@SystemApi” w kodziku źródłowym Androida.

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

  • [C-0-3] Implementacje na urządzeniach NIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów lub podpisów interfejsów API, odbiegać od udokumentowanego zachowania ani zawierać operacji pustych, z wyjątkiem przypadków, w których jest to wyraźnie dozwolone przez tę definicję zgodności.

  • [C-0-4] Implementacje na urządzeniach MUSZĄ nadal zawierać interfejsy API i działać w rozsądny sposób, nawet jeśli pominięto niektóre funkcje sprzętowe, dla których Android zawiera interfejsy API. Więcej informacji o wymaganiach w tym scenariuszu znajdziesz w sekcji 7.

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.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.
Parametr Szczegóły
VERSION.RELEASE Wersja aktualnie uruchomionego systemu Android w czytelnym dla człowieka formacie. To pole MUSI zawierać jeden z ciągów znaków zdefiniowanych w sekcji 8.0.
WERSJ.SDK Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 8.0 to pole MUSI zawierać wartość całkowitą 8.0_INT.
VERSION.SDK_INT Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 8.0 to pole MUSI zawierać wartość całkowitą 8.0_INT.
VERSION.INCREMENTAL Wartość wybrana przez implementatora urządzenia, która w czytelnym dla człowieka formacie określa konkretną wersję aktualnie uruchomionego systemu Android. Tej wartości NIE MOŻNA używać ponownie w przypadku różnych wersji udostępnionych użytkownikom. Typowe zastosowanie tego pola to wskazanie, który numer wersji lub identyfikator zmiany kontroli źródłowej został użyty do wygenerowania wersji. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono być puste ani zawierać pustego ciągu znaków („”).
PLANSZOWE Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretny sprzęt wewnętrzny używany przez urządzenie w czytelnym dla człowieka formacie. To pole może służyć do wskazania konkretnej wersji płyty głównej zasilającej urządzenie. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
MARKA Wartość odzwierciedlająca nazwę marki powiązaną z urządzeniem, jaką znają użytkownicy. MUSI być w formacie zrozumiałym dla człowieka i POWINIEN wskazywać producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_32_BIT_ABIS Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_64_BIT_ABIS Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI2 Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
URZĄDZENIE Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową identyfikującą konfigurację funkcji sprzętowych i wzornictwo przemysłowe urządzenia. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Nazwa urządzenia NIE MOŻE się zmieniać w trakcie trwania produktu.
FINGERPRINT Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być zrozumiały dla człowieka. Musi on być zgodny z tym szablonem:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

Na przykład:

acme/myproduct/
    mydevice:8.0/LMYXX/3359:userdebug/test-keys

Odcisk palca NIE MOŻE zawierać znaków odstępów. Jeśli inne pola w powyższym szablonie zawierają znaki odstępu, należy je zastąpić w odciskach palców wersji innym znakiem, np. podkreśleniem („_”). Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII.

SPRZĘT Nazwa sprzętu (z wiersza poleceń jądra lub /proc). Powinien być zrozumiały dla człowieka. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
HOST Ciąg tekstowy jednoznacznie identyfikujący hosta, na którym została utworzona kompilacja, w zrozumiałym dla człowieka formacie. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono być puste ani zawierać pustego ciągu znaków („”).
ID Identyfikator wybrany przez implementatora urządzenia, który odnosi się do konkretnej wersji w czytelnym dla człowieka formacie. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINIEN zawierać wartość wystarczająco znaczącą, aby użytkownicy mogli odróżnić różne wersje oprogramowania. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
PRODUCENT Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE może być ono puste ani nie może zawierać pustego ciągu znaków. W trakcie trwania produktu pole to NIE może się zmieniać.
MODEL Wartość wybrana przez implementatora urządzenia zawierająca nazwę urządzenia znaną użytkownikowi. Powinna to być ta sama nazwa, pod którą urządzenie jest sprzedawane i reklamowane. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE może być ono puste ani nie może zawierać pustego ciągu znaków. W trakcie trwania produktu pole to NIE może się zmieniać.
USŁUGA Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową konkretnego produktu (SKU), która MUSI być unikalna w ramach tej samej marki. Musi być czytelny dla człowieka, ale niekoniecznie musi być widoczny dla użytkowników. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Nazwa produktu NIE MOŻE się zmieniać w trakcie jego cyklu życia.
SERIAL Numer seryjny sprzętu, który MUSI być dostępny i niepowtarzalny w przypadku urządzeń z tym samym MODELEM i PRODUCENTEM. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^([a-zA-Z0-9]{6,20})$”.
TAGI Lista tagów wybranych przez implementatora urządzenia, rozdzielona przecinkami, która dodatkowo rozróżnia kompilację. To pole MUSI zawierać jedną z wartości odpowiadających 3 typowym konfiguracjom podpisywania na platformie Androida: release-keys, dev-keys, test-keys.
CZAS Wartość reprezentująca sygnaturę czasową utworzenia kompilacji.
TYP Wartość wybrana przez implementatora urządzenia, która określa konfigurację kompilacji w czasie wykonywania. To pole MUSI zawierać jedną z wartości odpowiadających 3 typowym konfiguracjom środowiska uruchomieniowego Androida: user, userdebug lub eng.
UŻYTKOWNIK Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował wersję. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono być puste ani zawierać pustego ciągu znaków („”).
SECURITY_PATCH Wartość wskazująca poziom poprawek zabezpieczeń danej kompilacji. Musi on oznaczać, że kompilacja nie jest w żaden sposób narażona na żadne z problemów opisanych w wybranym Biuletynie bezpieczeństwa Androida. Musi on mieć format [RRRR-MM-DD] i być zgodny z definiowanym ciągiem znaków udokumentowanym w publicznym biuletynie bezpieczeństwa Androida lub w informacjach o bezpieczeństwie Androida, np. „2015-11-01”.
BASE_OS Wartość reprezentująca parametr FINGERPRINT kompilacji, która jest identyczna z tą kompilacją, z wyjątkiem poprawek podanych w komunikatach o bezpieczeństwie Androida. Musi on zwracać prawidłową wartość. Jeśli taka wersja nie istnieje, musi zwracać pusty ciąg znaków („”).
BOOTLOADER Wartość wybrana przez implementatora urządzenia, która w czytelnym dla człowieka formacie identyfikuje konkretną wersję wewnętrznego programu rozruchowego używanego na urządzeniu. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
getRadioVersion() MUSI (być lub zwracać) wartość wybraną przez implementatora urządzenia, która identyfikuje specyficzną wewnętrzną wersję radia/modemu używaną na urządzeniu w czytelnym dla człowieka formacie. Jeśli urządzenie nie ma radia ani modemu wewnętrznego, musi zwrócić wartość NULL. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-,]+$”.

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Ą zawierać te aplikacje, komponenty usług lub co najmniej moduł obsługi dla wszystkich publicznych wzorów filtrów intencji zdefiniowanych przez te podstawowe aplikacje 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Ą umożliwiać zastąpienie przez aplikacje innych firm każdego wzorca intencji, do którego odwołuje się sekcja 3.2.3.1. 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ło ono takie: zawsze otwierać, zawsze pytać lub nigdy nie otwierać. Musi to dotyczyć wszystkich docelowych filtrów identyfikatorów URI w taki sam sposób.
    • [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 o intencji android.settings.HOME_SETTINGS, aby wyświetlić menu ustawień domyślnej aplikacji na ekranie głównym.

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

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

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

Jeśli implementacje na urządzeniu obsługują interfejs VoiceInteractionService:

3.2.4. Działania na dodatkowych wyświetlaczach

Jeśli implementacje urządzeń umożliwiają uruchamianie zwykłych czynności Androida na dodatkowych wyświetlaczach, 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 odpowiednio dostosować rozmiar wszystkich aktywności w VirtualDisplay, jeśli zmieni się rozmiar wyświetlacza.
  • MOŻE wyświetlać IME (edytor metody wprowadzania, element sterujący umożliwiający użytkownikom wprowadzanie tekstu) na ekranie głównym, gdy pole tekstowe staje się aktywne na ekranie dodatkowym.
  • NALEŻY zaimplementować fokus nawigacyjny na ekranie dodatkowym niezależnie od ekranu głównego, gdy obsługiwane są gesty dotykowe lub klawisze.
  • 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 główny i dodatkowy wyświetlacz mają różne wartości android.util.DisplayMetrics:

  • [C-2-1] Aktywności, których rozmiaru nie można zmienić (które mają resizeableActivity=false w AndroidManifest.xml), oraz aplikacje kierowane na interfejs API na poziomie 23 lub niższym NIE MOGĄ być dostępne na ekranach dodatkowych.

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-4] Musi obsługiwać odpowiedni interfejs ABI 32-bitowy, jeśli obsługiwany jest dowolny interfejs ABI 64-bitowy.
  • [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 zgłaszać za pomocą powyższych parametrów tylko te ABI, które są udokumentowane i opisane w najnowszej wersji dokumentacji Android NDK dotyczącej zarządzania ABI. NALEŻY też uwzględnić obsługę rozszerzenia Advanced SIMD (znanego też jako NEON).

  • [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)
    • 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)
    • 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] NALEŻY wyeksportować symbole funkcji dla funkcji z rdzenia Vulkan 1.0, a także dla 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 NDK na Androida możemy dodać obsługę dodatkowych ABI.

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

Jeśli implementacje urządzeń to 64-bitowe urządzenia ARM, to:

  • [C-1-1] Chociaż architektura ARMv8 wycofuje kilka operacji procesora, w tym niektóre operacje używane w dotychczasowym kodzie natywnym, te operacje wycofane MUSZĄ pozostać dostępne dla 32-bitowego kodu natywnego ARM, albo przez obsługę natywnego procesora, albo przez emulację oprogramowania:

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

Jeśli implementacje urządzeń obejmują 32-bitowy interfejs ARM ABI, to:

  • [C-2-1] W pliku /proc/cpuinfo, który jest odczytywany przez 32-bitowe aplikacje ARM, MUSZĄ się znajdować te linie kodu, aby zapewnić zgodność z aplikacjami utworzonymi za pomocą starszych wersji Android NDK.

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

  • Nie należy zmieniać wartości /proc/cpuinfo, gdy jest odczytywana przez 64-bitowe aplikacje ARM lub inne aplikacje.

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

  • [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.
    • Wartość ciągu $(MODEL) MUSI być taka sama jak wartość android.os.Build.MODEL.
    • Wartość ciągu znaków $(BUILD) MUSI być taka sama 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.

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

Zachowanie każdego z typów interfejsu API (zarządzanego, miękkiego, natywnego i internetowego) 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.

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.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.*
  • 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ę.

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

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:

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

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] MUSI deklarować 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ą:

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ą one:

  • [C-1-1] MUSI obsługiwać powiadomienia, które korzystają z funkcji sprzętowych zgodnie z dokumentacją pakietu SDK oraz w jak największym stopniu z urządzenia implementującego sprzęt. Jeśli na przykład implementacja urządzenia zawiera wibrator, musi on prawidłowo implementować interfejsy API wibracji. Jeśli implementacja urządzenia nie zawiera sprzętu, odpowiednie interfejsy API MUSZĄ być zaimplementowane jako no-ops. 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 paska stanu/paska systemowego, ale MOŻE oferować alternatywne wrażenia użytkownika w przypadku powiadomień niż te oferowane przez referencyjną implementację na Androidzie w wersji open source.
  • [C-1-3] MUSISZ prawidłowo stosować zachowania opisane w interfejsach API, aby aktualizować, usuwać i grupować powiadomienia.
  • [C-1-4] NALEŻY podać pełne informacje o zachowaniu interfejsu NotificationChannel w dokumentacji pakietu SDK.
  • [C-1-5] Musisz umożliwić użytkownikowi zablokowanie i zmodyfikowanie powiadomienia określonej aplikacji innej firmy na każdym poziomie kanału i poziomu pakietu aplikacji.
  • [C-1-6] NALEŻY też umożliwić użytkownikowi wyświetlanie usuniętych kanałów powiadomień.
  • 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żytkownikom wyciszanie 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.
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.

Implementacje na urządzeniu:

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

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

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

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

  • [C-1-1] NALEŻY zaimplementować aktywność, która będzie odpowiadać na intencję ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. W przypadku implementacji z UI_MODE_TYPE_NORMAL musi to być aktywność, w której użytkownik może zezwolić lub odmówić aplikacji dostępu do konfiguracji zasad Nie przeszkadzać.
  • [C-1-2] W przypadku 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.

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.
  • [C-SR] ZALECAMY mocno naciśnięcie klawisza HOME jako interakcję.

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ą:

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.

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 20 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, który umożliwia łatwe przełączanie się do poprzedniej aktywności.
  • 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.

  • [C-SR] W przypadku implementacji urządzeń MOCNO zaleca się używanie na ekranie przeglądu interfejsu użytkownika 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ą:

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 ekrany blokady interaktywnej, 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Ą stosować wygaszacze, ale inne typy urządzeń powinny zawierać obsługę wygaszaczy i opcję ustawień, która umożliwia użytkownikom skonfigurowanie wygaszaczy w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

3.8.12. Lokalizacja

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

  • [C-1-1] Tryby lokalizacji muszą być wyświetlane 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.

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] Aplikacje mogą wskazywać, czy są zdolne do działania w trybie wielookiennym w pliku AndroidManifest.xml, albo jawnie przez ustawienie atrybutu android:resizeableActivity na true, albo domyślnie przez ustawienie parametru targetSdkVersion > 24. Aplikacje, które w pliku manifestu mają ten atrybut ustawiony na false, NIE MOGĄ być uruchamiane w trybie wielookiennym. Starsze aplikacje z wartością targetSdkVersion < 24, które nie mają ustawionego tego atrybutu android:resizeableActivity, MOGĄ być uruchamiane w trybie wielu okien, ale system MUSI wyświetlić ostrzeżenie, że aplikacja może nie działać zgodnie z oczekiwaniami w tym trybie.
  • [C-1-3] Nie wolno oferować trybu podzielonego ekranu ani trybu swobodnego, jeśli wysokość ekranu < 440 dp i szerokość ekranu < 440 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 minimalną szerokość 240 dp i wysokość 135 dp, gdy element Configuration.uiMode jest skonfigurowany jako UI_MODE_TYPE_TELEVISION

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.
  • [C-1-3] MUST declare the support of manged profiles via the android.software.managed_users feature flag, except for when the device is configured so that it report itself as a low RAM device or so that it allocate internal (non-removable) storage as shared storage.

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:
  • [C-1-2] NIE NALEŻY ustawiać aplikacji (w tym wstępnie zainstalowanej) jako aplikacji właściciela urządzenia bez wyraźnej zgody lub działania użytkownika lub administratora 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ądzenia z włączoną obsługą wielu użytkowników (patrz sekcja 9.5), mimo że 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.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 honorować android.settings.ACCESSIBILITY_SETTINGS, aby udostępnić użytkownikowi mechanizm umożliwiający włączenie i wyłączenie usług ułatwień dostępu innych firm obok wstępnie zainstalowanych usług ułatwień dostępu.
  • [C-1-4] NALEŻY dodać przycisk na pasku nawigacyjnym systemu, który umożliwia użytkownikowi kontrolowanie usługi ułatwień dostępu, gdy włączone usługi ułatwień dostępu deklarują AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Pamiętaj, że w przypadku implementacji urządzenia bez paska nawigacji systemu ten wymóg nie ma zastosowania, ale implementacje urządzenia POWINNY umożliwiać użytkownikowi kontrolowanie tych usług ułatwień dostępu.

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

  • [C-2-1] NALEŻY zaimplementować te wstępnie załadowane usługi ułatwień dostępu jako aplikacje Direct Boot Aware, gdy pamięć danych jest szyfrowana za pomocą szyfrowania na poziomie pliku (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ą:

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] Musisz wstępnie wczytać aplikację na telewizor i spełniać wszystkie wymagania opisane w sekcji 3.12.1.

3.12.1. Aplikacja TV

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

  • [C-1-1] Aplikacja na telewizor MUSI umożliwiać instalowanie i używanie kanałów telewizyjnych oraz spełniać te wymagania.

Aplikacja na telewizor, która jest wymagana w przypadku implementacji na urządzeniach z Androidem deklarujących flagę funkcji android.software.live_tv, MUSI spełniać te wymagania:

  • Implementacje urządzeń powinny umożliwiać instalowanie i zarządzanie danymi wejściowymi innych firm (danymi wejściowymi innych firm) opartymi na TIF.
  • Implementacje urządzeń MOGĄ zapewniać wizualne oddzielenie wstępnie zainstalowanych wejść opartych na TIF (zainstalowanych wejść) od wejść innych firm.
  • Implementacje urządzeń NIE powinny wyświetlać elementów wprowadzania danych innych firm, które wymagają więcej niż jednego działania nawigacyjnego, aby opuścić aplikację na telewizor (np. rozwinięcia listy elementów wprowadzania danych innych firm w aplikacji na telewizor).

Projekt Android Open Source udostępnia implementację aplikacji na telewizor, która spełnia powyższe wymagania.

3.12.1.1. Elektroniczny przewodnik po programach

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

  • [C-1-1] MUSI wyświetlać nakładkę informacyjną i interaktywną, która MUSI zawierać elektroniczny przewodnik po programach (EPG) wygenerowany na podstawie wartości w polach TvContract.Programs.
  • [C-1-2] Po zmianie kanału implementacje urządzeń MUSZĄ wyświetlać dane EPG dla aktualnie odtwarzanego programu.
  • [SR] W ramach EPG MOCNO POLECAMY wyświetlanie zainstalowanych wejść i wejść innych firm z jednakową widocznością. EPG NIE POWINIEN wyświetlać danych wejściowych innych firm, które są oddalone od zainstalowanych danych wejściowych na EPG o więcej niż jedno działanie nawigacyjne.
  • EPG powinien wyświetlać informacje ze wszystkich zainstalowanych wejść i wejść innych firm.
  • EPG MOŻE zapewnić wizualne oddzielenie zainstalowanych wejść od wejść zewnętrznych.
3.12.1.2. Nawigacja

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

  • [C-1-1] NALEŻY umożliwić nawigację za pomocą przycisków D-pad, Wstecz i Ekran główny na urządzeniach wejściowych (np. pilocie, aplikacji sterującej lub kontrolerze do gier) urządzenia Android TV w przypadku tych funkcji:

    • Zmiana kanałów telewizyjnych
    • Otwieranie EPG
    • Konfigurowanie i dostrajanie pod kątem danych wejściowych innych firm opartych na formacie TIF
    • Otwieranie menu Ustawienia

  • NALEŻY przekazywać kluczowe zdarzenia do wejść HDMI przez CEC.

3.12.1.3. Łączenie aplikacji z wejściem TV

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

  • [C-1-1] Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać linkowanie aplikacji z wejściem TV, co pozwala na tworzenie linków między bieżącą aktywnością a inną aktywnością (np. link od transmisji na żywo do powiązanych treści).
  • [C-1-2] Aplikacja na telewizor MUSI wyświetlać łącze do aplikacji z wejściami na telewizor, jeśli jest ono dostępne.
3.12.1.4. Przesuwanie w czasie

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

  • [SR] ZALECAMY obsługę przesunięcia czasowego, która umożliwia użytkownikowi wstrzymywanie i wznawianie odtwarzania treści na żywo.
  • NALEŻY zapewnić użytkownikowi możliwość wstrzymania i wznowienia odtwarzanego programu, jeśli jest dostępna funkcja przesuwania w czasie.
3.12.1.5. Nagrywanie telewizji

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

  • [SR] MOCNO ZALECANA obsługa nagrywania telewizji.
  • NALEŻY udostępnić interfejs do odtwarzania nagranych programów.
  • Jeśli wejście telewizora obsługuje nagrywanie, a nagrywanie programu nie jest zabronione, EPG MOŻE udostępnić sposób nagrywania programu.

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ń zawierają platformę UI obsługującą aplikacje innych firm, które zależą od MediaBrowser i MediaSession, muszą:

  • [C-1-1] Ikony MediaItem i ikony powiadomień muszą być wyświetlane w niezmienionej formie.
  • [C-1-2] MUST display those items as described by MediaSession, e.g., metadata, icons, imagery.
  • [C-1-3] Wymagane: musi zawierać tytuł aplikacji.
  • [C-1-4] Musisz mieć szufladę, aby wyświetlić hierarchię MediaBrowser.

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 "ephemeral".
  • [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Ą widzieć szczegółów aplikacji błyskawicznych na urządzeniu, chyba że aplikacja błyskawiczna wyraźnie łączy się z zainstalowaną aplikacją.

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.

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, aby implementacje na urządzeniach korzystały z systemu zarządzania pakietami implementacji referencyjnej AOSP.
  • [C-0-2] MUSI obsługiwać weryfikację plików „.apk” przy użyciu schematu podpisu 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 żadnego promptu, 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.

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 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ć te kodowania dźwięku:

  • [C-1-1] PCM/WAVE

5.1.2. Dekodowanie dźwięku

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

Jeśli implementacje urządzeń deklarują obsługę funkcji android.hardware.audio.output, muszą obsługiwać te dekodery 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-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE
  • [C-1-10] Opus

Jeśli implementacje urządzeń obsługują dekodowanie buforów wejściowych AAC strumieni wielokanałowych (czyli więcej niż 2 kanałó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 zostać zdekodowany do 5 kanałów PCM, a strumień AAC 5.1 musi zostać 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.

5.1.3. Szczegóły kodeków audio

Format/kodek Szczegóły Obsługiwane typy plików i formaty kontenerów
MPEG-4 Profile AAC
(AAC LC) 		Obsługa treści mono, stereo, 5.0 i 5.1 ze standardową częstotliwością próbkowania od 8 do 48 kHz.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS raw AAC (.aac, ADIF nieobsługiwany)
  • MPEG-TS (.ts, nieprzeskakuj)
MPEG-4 HE AAC Profile (AAC+) Obsługa treści mono/stereo/5.0/5.1 ze standardową częstotliwością próbkowania od 16 do 48 kHz.
MPEG-4 HE AACv2
Profil (ulepszona wersja AAC+) 		Obsługa treści mono/stereo/5.0/5.1 ze standardową częstotliwością próbkowania od 16 do 48 kHz.
AAC ELD (ulepszona wersja AAC o niskim opóźnieniu) Obsługa treści mono lub stereo ze standardową częstotliwością próbkowania od 16 do 48 kHz.
AMR-NB 4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz 3GPP (.3gp)
AMR-WB 9 szybkości od 6,60 kb/s do 23,85 kb/s z częstotliwością próbkowania 16 kHz
FLAC Mono/Stereo (bez kanałów dodatkowych). Częstotliwości próbkowania do 48 kHz (ale na urządzeniach z wyjściami 44,1 kHz zaleca się stosowanie częstotliwości do 44,1 kHz, ponieważ konwerter 48 kHz na 44,1 kHz nie zawiera filtra dolnoprzepustowego). ZALECANA 16-bitowa głębia bitowa; w przypadku 24-bitowej głębi bitowej nie stosuje się rozmycia. Tylko FLAC (.flac)
MP3 Mono/Stereo 8–320 kb/s stała (CBR) lub zmienna szybkość transmisji (VBR) MP3 (.mp3)
MIDI Typ MIDI 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody
  • Typ 0 i 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0 lub nowszy)
PCM/WAVE 16-bitowy PCM liniowy (szybkość do limitu sprzętowego). Urządzenia MUSZĄ obsługiwać częstotliwości próbkowania dla nieskompresowanych nagrań PCM o częstotliwości 8000, 11025, 16000 i 44100 Hz. WAVE (.wav)
Opus Matroska (.mkv), Ogg(.ogg)

5.1.4. Kodowanie obrazu

Więcej informacji znajdziesz w sekcji 5.1.6. Szczegóły 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

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ć kodowanie tych typów dekodowania 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

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

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

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ć elastyczny format kolorów YUV420 (COLOR_FormatYUV420Flexible).

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.

5.1.8. Lista kodeków wideo

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

5.2. Kodowanie wideo

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

  • W 2 przesuwających się oknach nie powinna przekraczać o ponad 15% szybkości transmisji bitów między interwałami klatek wewnątrzramkowych (I-frame).
  • Nie powinna przekraczać o więcej niż około 100% szybkości transmisji danych w oknie przesuwającym się o 1 sekundę.

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.

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.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 240 pikseli 720 x 480 piks. 1280 x 720 pikseli 1920 x 1080 piks.
liczba klatek na sekundę, 20 kl./s 30 klatek/s 30 klatek/s 30 klatek/s
Szybkość transmisji wideo 384 kbps 2 Mb/s 4 Mb/s 10 Mb/s

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).
  • Powinien obsługiwać zapisywanie plików WebM w formacie Matroska.
  • NALEŻY użyć kodeka VP8 na potrzeby sprzętu, który spełnia wymagania dotyczące kodowania sprzętowego RTC projektu WebM, aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo i usług wideokonferencji.

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

  • [C-2-1] MUSI obsługiwać profile kodowania wymienione w tabeli poniżej.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 180 pikseli 640 x 360 pikseli 1280 x 720 pikseli 1920 x 1080 piks.
liczba klatek na sekundę, 30 klatek/s 30 klatek/s 30 klatek/s 30 klatek/s
Szybkość transmisji wideo 800 Kb/s 2 Mb/s 4 Mb/s 10 Mb/s

5.2.4. VP9

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

  • Powinien obsługiwać zapisywanie plików WebM w formacie Matroska.

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.

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

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

5.3.1. MPEG-2

Jeśli implementacje urządzeń obsługują dekodery MPEG-2, 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.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 240 pikseli 720 x 480 piks. 1280 x 720 pikseli 1920 x 1080 piks.
liczba klatek na sekundę, 30 klatek/s 30 klatek/s 60 kl./s 30 kl./s (60 kl./stelewizor)
Szybkość transmisji wideo 800 Kb/s 2 Mb/s 8 Mb/s 20 Mb/s

5.3.5. H.265 (HEVC)

Jeśli implementacje urządzeń obsługują kodek H.265, 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 przypadku dekodowania profili 720, 1080 i UHD.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p UHD
Rozdzielczość wideo 352 x 288 pikseli 720 x 480 piks. 1280 x 720 pikseli 1920 x 1080 piks. 3840 x 2160 pikseli
liczba klatek na sekundę, 30 klatek/s 30 klatek/s 30 klatek/s 30/60 fps (60 fps telewizor z sprzętem do dekodowania H.265 na poziomie sprzętowym) 60 kl./s
Szybkość transmisji wideo 600 Kb/s 1,6 Mb/s 4 Mb/s 5 Mb/s 20 Mb/s

5.3.6. VP8

Jeśli implementacje urządzeń obsługują kodek VP8, 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.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 180 pikseli 640 x 360 pikseli 1280 x 720 pikseli 1920 x 1080 piks.
liczba klatek na sekundę, 30 klatek/s 30 klatek/s 30 kl./s (60 kl./stelewizor) 30 (60 fps, telewizor)
Szybkość transmisji wideo 800 Kb/s 2 Mb/s 8 Mb/s 20 Mb/s

5.3.7. VP9

Jeśli implementacje urządzeń obsługują kodek VP9, 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 1 z 2 formatów: VP9 lub H.265 w przypadku profili 720, 1080 i UHD.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p UHD
Rozdzielczość wideo 320 x 180 pikseli 640 x 360 pikseli 1280 x 720 pikseli 1920 x 1080 piks. 3840 x 2160 pikseli
liczba klatek na sekundę, 30 klatek/s 30 klatek/s 30 klatek/s 30 kl./s (60 kl./s telewizor z sprzętowym dekodowaniem VP9) 60 kl./s
Szybkość transmisji wideo 600 Kb/s 1,6 Mb/s 4 Mb/s 5 Mb/s 20 Mb/s

5.4. Nagrywanie dźwięku

Chociaż 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 ZALECAMY, aby spełniały te wymagania, które są oznaczone jako „NALEŻY”, ponieważ w przeciwnym razie nie będą zgodne z Androidem po aktualizacji do przyszłej wersji.

5.4.1. Przechwytywanie dźwięku w formacie RAW

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 Hz
    • Kanały: mono

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

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ć kontrolowanie tego efektu dźwiękowego za pomocą interfejsu API android.media.audiofx.NoiseSuppressor.
  • [C-2-2] W polu AudioEffect.Descriptor.uuid należy jednoznacznie określić każdą implementację technologii redukcji szumów.

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

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

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

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

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

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.

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

  • [SR] Opóźnienie wyjścia „na zimno” nie większe niż 100 ms
  • [SR] Ciągły czas oczekiwania na wyjście nie dłuższy niż 45 ms
  • [SR] Minimalizuj jitter wyjścia „na zimno”

Jeśli implementacje urządzeń spełniają powyższe wymagania po początkowej kalibracji przy użyciu interfejsu API kolejki bufora OpenSL ES PCM, opóźnienie ciągłego wyjścia i opóźnienie zimnego wyjścia na co najmniej 1 obsługiwanym urządzeniu do wyjścia audio wynoszą:

  • [SR] ZALECAMY zgłaszanie dźwięku o krótkim czasie oczekiwania przez oznaczenie flagą funkcji android.hardware.audio.low_latency.
  • [SR] ZALECAMY MOCNO spełnienie wymagań dotyczących dźwięku o niskim opóźnieniu za pomocą interfejsu AAudio API.

Jeśli implementacje na urządzeniach nie spełniają wymagań dotyczących dźwięku o małej latencji za pomocą interfejsu OpenSL ES PCM buffer queue API, nie:

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

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

  • [SR] Opóźnienie w przypadku zimnego uruchomienia nie większe niż 100 ms
  • [SR] Ciągłe opóźnienie na wejściu nieprzekraczające 30 ms
  • [SR] Ciągłe opóźnienie w obie strony nie większe niż 50 ms
  • [SR] Minimalizowanie jittera danych wejściowych „na zimno”

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 pokazane 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

Formaty segmentów Odsyłacze Obsługa wymaganych kodeków
MPEG-2 Transport Stream ISO 13818 Kodek wideo:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Szczegółowe informacje o H.264 AVC, MPEG2-4 SP,
i MPEG-2 znajdziesz w sekcji 5.1.3.

Kodeki audio:

  • AAC
Więcej informacji o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
AAC z ramowaniem ADTS i tagami ID3 ISO 13818-7 Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
WebVTT WebVTT

RTSP (RTP, SDP)

Nazwa profilu Odsyłacze Obsługa wymaganych kodeków
H264 AVC RFC 6184 Szczegółowe informacje na temat H264 AVC znajdziesz w sekcji 5.1.3.
MP4A-LATM RFC 6416 Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
H263-1998 RFC 3551
RFC 4629
RFC 2190 		Szczegółowe informacje o H.263 znajdziesz w sekcji 5.1.3.
H263-2000 RFC 4629 Szczegółowe informacje o H.263 znajdziesz w sekcji 5.1.3.
AMR RFC 4867 Szczegółowe informacje o AMR-NB znajdziesz w sekcji 5.1.1.
AMR-WB RFC 4867 Szczegółowe informacje o AMR-WB znajdziesz w sekcji 5.1.1.
MP4V-ES RFC 6416 Szczegółowe informacje o MPEG-4 SP znajdziesz w sekcji 5.1.3.
mpeg4-generic RFC 3640 Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
MP2T RFC 2250 Szczegółowe informacje znajdziesz w sekcji MPEG-2 Transport Stream w sekcji Transmisja na żywo przez HTTP.

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] W przypadku wszystkich przewodowych wyświetlaczy zewnętrznych MUSI obsługiwać HDCP 1.2 lub nowszą wersję.

5.9. MusicaI Instrument Digital Interface (MIDI)

Jeśli implementacja urządzenia obsługuje przesyłanie danych MIDI między aplikacjami (wirtualne urządzenia MIDI) i obsługuje MIDI przez wszystkie te obsługiwane przez sprzętowe interfejsy MIDI, dla których zapewnia ono ogólne połączenia niebędące MIDI:

Urządzenia MIDI:

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

Jeśli implementacja urządzenia zapewnia ogólne połączenie nie-MIDI za pomocą określonego sprzętowego interfejsu MIDI wymienionego powyżej, ale nie obsługuje MIDI za pomocą tego sprzętowego interfejsu, to:

  • [C-1-1] NIE należy zgłaszać obsługi funkcji android.software.midi.

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] Ciągłe opóźnienie w obie strony w przypadku dźwięku, zgodnie z definicją w sekcji 5.6 Opóźnienie w przypadku dźwięku, MUSI wynosić 20 ms lub mniej i POWINIEN wynosić 10 ms lub mniej w przypadku co najmniej jednej obsługiwanej ścieżki.
  • [C-1-3] Musi zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
  • [C-1-4] MUST report support for feature android.software.midi.
  • [C-1-5] MUSI spełniać wymagania dotyczące opóźnień i dźwięku USB za pomocą interfejsu API kolejki bufora PCM OpenSL ES.
  • POWINIEN zapewniać stabilną wydajność procesora podczas odtwarzania dźwięku.
  • 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.
  • POWINIEN zapewniać brak dźwięku w ramach opóźnienia oraz brak przepełnienia dźwięku w ramach opóźnienia.
  • 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).

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

Jeśli implementacje na urządzeniach spełniają wymagania za pomocą interfejsu API kolejki bufora OpenSL ES PCM, to:

  • [SR] MOCNO ZALECANA zgodność z tymi samymi wymaganiami w interfejsie AAudio API.

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

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

  • [C-3-1] Opóźnienie w obie strony nie może przekraczać 20 ms.
  • 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.

Jeśli implementacje urządzeń zawierają porty USB obsługujące tryb hosta USB, muszą:

  • [C-4-1] MUSI implementować klasę audio USB.

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

  • [C-5-1] MUSI obsługiwać wyjście stereo i 8 kanałów z głębokością bitową 20- lub 24-bitową i częstotliwością 192 kHz bez utraty głębokości bitowej lub 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 udostępniać je 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 ani 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ć wszystkie funkcje adb zgodnie z dokumentacją pakietu Android SDK, w tym dumpsys.
    • [C-0-3] NIE wolno zmieniać formatu ani zawartości zdarzeń systemowych urządzenia (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) zarejestrowanych za pomocą dumpsys.
    • [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ą pakietu Android SDK. Systrace musi być domyślnie nieaktywny i musi istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie Systrace.

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] NALEŻY ukryć opcje dla deweloperów domyślnie i NALEŻY zapewnić mechanizm umożliwiający włączenie opcji dla deweloperów bez konieczności dodania ich do listy dozwolonych.
  • MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty, ukrywając je wizualnie lub wyłączając, aby zapobiec rozproszeniu w sytuacjach, w których bezpieczeństwo użytkownika jest zagrożone.

7. Zgodność sprzętowa

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

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

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

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

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

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. Urządzenia MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z opisem w tej sekcji.

Jednostki, do których odwołują się wymagania w tej sekcji, są zdefiniowane w 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 cala. W przypadku podanych 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 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.

  • [C-0-1] Implementacje na urządzeniu MUSZĄ zgłaszać 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] Implementacje urządzeń MUSZĄ prawidłowo obsługiwać deklarowaną przez aplikacje obsługę rozmiarów ekranu za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml zgodnie z dokumentacją Android SDK.

7.1.1.2. Format obrazu

Chociaż nie ma ograniczeń dotyczących wartości proporcji ekranu fizycznego, proporcje ekranu logicznego, na którym renderowane są aplikacje innych firm, obliczone na podstawie wartości wysokości i szerokości z interfejsów API view.Display i Configuration, MUSZĄ spełniać te wymagania:

  • [C-0-1] Wdrożenia urządzenia z ustawionym parametrem Configuration.uiMode jako UI_MODE_TYPE_NORMAL MUSZĄ mieć wartość współczynnika proporcji w zakresie od 1,3333 (4:3) do 1,86 (około 16:9), chyba że aplikacja może zostać rozciągnięta w dłuższym kierunku, ponieważ spełnia jeden z tych warunków:

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

  • [C-0-2] Wdrożenia urządzeń z wartością Configuration.uiMode ustawioną jako UI_MODE_TYPE_WATCH MUSZĄ mieć ustawioną wartość formatu obrazu 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 tych logicznych gęstości interfejsu Androida za pomocą interfejsu API DENSITY_DEVICE_STABLE. Wartość ta 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 wprowadzonych przez użytkownika w konfiguracji wyświetlacza (np. rozmiar wyświetlacza) po pierwszym uruchomieniu.

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

  • 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ą ekran lub wyjście wideo, muszą:

  • [C-1-1] MUSI raportować prawidłowe wartości wszystkich danych wyświetlania 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 raportować rozsądne wartości wszystkich danych o wyświetlaniu zdefiniowanych w interfejsie API android.util.DisplayMetrics dla emulowanego domyślnego view.Display.

7.1.3. Orientacja ekranu

Implementacje na urzą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ć interfejs OpenGL ES 1.0 i 2.0 zgodnie z opisem w dokumentacji pakietu SDK Androida.
  • [SR] MOCNO ZALECAMY obsługę OpenGL ES 3.0.
  • NALEŻY obsługiwać OpenGL ES 3.1 lub 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 i EGL_ANDROID_recordable.
  • [SR] MOCNO ZALECAMY obsługę EGL_KHR_partial_update.
  • 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.

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 urządzeń obsługują OpenGL ES 3.0 lub 3.1, to:

  • [SR] MOCNO ZALECAMY uwzględnienie obsługi Vulkan 1.0 .

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

  • NALEŻY uwzględnić obsługę Vulkana 1.0.

Implementacje na urządzeniach, jeśli obsługują Vulkan 1.0:

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

Implementacje na urządzeniach, które nie obsługują Vulkan 1.0:

  • [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.
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] Wyświetlacz musi mieć gamę o obszarze co najmniej 90% NTSC 1953 w przestrzeni CIE 1931 xyY.
  • [C-1-4] MUSI obsługiwać OpenGL ES 3.0, 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_colorspace_scrgb_linear i EGL_GL_colorspace_display_p3.
  • [SR] ZALECAMY świadczenie pomocy w sprawie 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 ekranie. 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.

Implementacje na urządzeniu:

  • [C-0-1] MUSI obsługiwać wyświetlacze, które mogą renderować 16-bitową kolorową grafikę.
  • NALEŻY obsługiwać wyświetlacze obsługujące 24-bitową grafikę kolorową.
  • [C-0-2] Musi obsługiwać wyświetlacze, które mogą renderować animacje.
  • [C-0-3] NALEŻY używać technologii wyświetlacza, która ma współczynnik proporcji pikseli (PAR) w zakresie od 0,9 do 1,15. Oznacza to, że współczynnik proporcji piksela MUSI być zbliżony do kwadratu (1,0) z tolerancją 10–15%.

7.1.7. Wyświetlacze dodatkowe

Android obsługuje wyświetlacz dodatkowy, aby umożliwić udostępnianie multimediów, oraz interfejsy API dla deweloperów, aby umożliwić 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:

7.2.1. Klawiatura

Jeśli implementacje urządzeń obejmują obsługę zewnętrznych edytorów metody wprowadzania (IME), muszą:

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:

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 określonej części ekranu dotykowego. Są one niezbędne w ramach paradygmatu nawigacji w Androidzie, dlatego:

  • [C-0-1] Musisz udostępnić funkcję Home.
  • 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ą muszą: * [C-3-1] MUSZĄ udostępnić aplikacjom funkcję Menu, gdy targetSdkVersion jest mniejsza niż 10, za pomocą przycisku fizycznego, klawisza oprogramowania lub gestów. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacji.

Jeśli implementacje urządzeń udostępniają funkcję pomocy, muszą: [C-4-1] MUSISZ udostępnić funkcję pomocy za pomocą pojedynczego działania (np. kliknięcia, podwójnego kliknięcia lub gestu), gdy inne przyciski 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.

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 urządzeń deklarują flagę funkcji android.hardware.gamepad, muszą: [C-1-1] MUSISZ umieścić w urządzeniu kontroler lub dołączyć do niego oddzielny kontroler, 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 view.InputEvent Androida zgodnie z tabelami poniżej. Wdrożenie na Androidzie obejmuje sterowanie kontrolerami, które spełnia ten wymóg.

Przycisk Użycie HID2 Przycisk Android
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
Przycisk w górę na padzie kierunkowym1
Przycisk w dół na padzie kierunkowym1 		0x01 0x00393 AXIS_HAT_Y4
Przycisk w lewo na padzie kierunkowym1
Przycisk w prawo na padzie kierunkowym1 		0x01 0x00393 AXIS_HAT_X4
Przycisk lewego uchwytu1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
Przycisk na prawym uchwycie1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
Kliknięcie lewej gałki1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
Kliknięcie prawego drążka1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Strona główna1 0x0c 0x0223 KEYCODE_HOME (3)
Wstecz1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 Powyższe zastosowania HID muszą być zadeklarowane w ramach CA kontrolera do gier (0x01 0x0005).

3 Ta wartość musi mieć minimalną wartość logiczną 0, maksymalną wartość logiczną 7, minimalną wartość fizyczną 0, maksymalną wartość fizyczną 315, jednostki w stopniach oraz 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

Analog Controls1 Użycie HID Przycisk Android
Lepiej: 0x02 0x00C5 AXIS_LTRIGGER
Prawy spust 0x02 0x00C4 AXIS_RTRIGGER
Lewy joystick 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
Prawy joystick 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. Pilot

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

7.3. Czujniki

Jeśli 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] Musi przekazywać dane z czujnika z maksymalnym opóźnieniem 100 ms
  • 2 * sample_time w przypadku strumieniowego przesyłania danych z czujnika z minimalnym opóźnieniem 5 ms + 2 * sample_time, gdy aktywny jest procesor aplikacji. 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 dotychczasowe, 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 komponentem. 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 urządzeń powinny zawierać 3-osiowy akcelerometr.

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 powinno być 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.
  • [SR] MOCNO POLECAMY implementację złożonego czujnika TYPE_SIGNIFICANT_MOTION.
  • [SR] ZDECYDOWANIE POLECAMY wdrożenie czujnika TYPE_ACCELEROMETER_UNCALIBRATED, jeśli dostępna jest internetowa kalibracja akcelerometru.
  • 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.
  • NALEŻY też zaimplementować czujnik TYPE_ACCELEROMETER_UNCALIBRATED.

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 czujnik żyroskopowy, muszą:

  • [C-3-1] OBOWIĄZKOWA implementacja czujników złożonych TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
  • NALEŻY zaimplementować czujnik złożony TYPE_GAME_ROTATION_VECTOR.
  • [SR] W przypadku dotychczasowych i nowych urządzeń z Androidem MOCNO POLECAMY wdrożenie czujnika TYPE_GAME_ROTATION_VECTOR.

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

  • [C-4-1] NALEŻY zastosować czujnik złożony TYPE_ROTATION_VECTOR.

7.3.2. Magnetometr

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

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 obejmują 3-osiowy magnetometr, akcelerometr i żyroskop, muszą:

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

  • Powinien zawierać odbiornik GPS/GNSS.

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

  • [C-1-1] Musi obsługiwać dane 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).
    • [SR] Po obliczeniu lokalizacji zaleca się, aby urządzenie było w stanie określić swoją lokalizację na otwartym niebie w ciągu 10 sekund od ponownego wysłania żądania lokalizacji, nawet jeśli kolejne żądanie zostanie wysł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-1-5] NALEŻY podać generację technologii GNSS za pomocą testowego interfejsu API „getGnssYearOfHardware”.
    • [SR] Kontynuuj dostarczanie normalnych danych wyjściowych lokalizacji GPS/GNSS podczas połączenia alarmowego.
    • [SR] Raportowanie pomiarów GNSS ze wszystkich śledzonych konstelacji (jak podano w wiadomościach GnssStatus), z wyjątkiem SBAS.
    • [SR] Raport AGC i częstotliwość pomiaru GNSS.
    • [SR] Raport z szacowanymi wartościami dokładności (w tym kierunek, prędkość i pion) w ramach każdej lokalizacji GPS.
    • [SR] ZALECAMY, aby spełniać jak najwięcej dodatkowych wymagań dla urządzeń raportujących rok „2016” lub „2017” za pomocą interfejsu Test API LocationManager.getGnssYearOfHardware().

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

  • [C-2-1] NALEŻY zgłaszać pomiary GPS, gdy tylko zostaną znalezione, nawet jeśli lokalizacja obliczona na podstawie danych z GPS/GNSS nie została jeszcze zgłoszona.
  • [C-2-2] MUST report GPS pseudoranges and pseudorange rates, that, in open-sky conditions 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ń zawierają odbiornik GPS/GNSS i zgłaszają tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps, a interfejs Test API LocationManager.getGnssYearOfHardware() zgłasza rok „2017” lub nowszy, to:

  • [C-3-1] Podczas połączenia alarmowego telefon MUSI nadal dostarczać normalne dane wyjściowe z usługi GPS/GNSS.
  • [C-3-2] MUST report GNSS measurements from all constellations tracked (as reported in GnssStatus messages), with the exception of SBAS.
  • [C-3-3] MUSI raportować AGC i częstotliwość pomiaru GNSS.
  • [C-3-4] NALEŻY podać wszystkie szacunki dokładności (w tym kierunek, prędkość i pion) w ramach każdej lokalizacji GPS.

7.3.4. Żyroskop

Implementacje na urządzeniu:

  • Powinien zawierać żyroskop (czujnik zmiany kątowej).
  • NIE należy dołączać czujnika żyroskopu, chyba że jest też dostępny 3-osiowy akcelerometr.

Jeśli implementacje urządzeń zawierają żyroskop:

  • [C-1-1] Musisz mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz.
  • [C-1-2] MUSISZ zaimplementować czujnik TYPE_GYROSCOPE i MOŻESZ zaimplementować czujnik TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-3] MUSI umożliwiać pomiar zmian orientacji do 1000 stopni na sekundę.
  • [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] W przypadku dotychczasowych i nowych urządzeń z Androidem MOCNO POLECAMY wdrożenie czujnika SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
  • [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ądzeń zawierają żyroskop, akcelerometr i magnetometr, muszą:

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

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

  • [C-3-1] OBOWIĄZKOWA implementacja czujników złożonych TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION.
  • [SR] W przypadku dotychczasowych i nowych urządzeń z Androidem MOCNO POLECAMY wdrożenie czujnika TYPE_GAME_ROTATION_VECTOR.
  • NALEŻY zaimplementować czujnik złożony TYPE_GAME_ROTATION_VECTOR.

7.3.5. barometr;

  • Implementacje urządzenia POWINNY zawierać barometr (czujnik ciśnienia powietrza 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.
    • Rozdzielczość pomiaru MUSI wynosić co najmniej 1024 LSB/G.
    • Częstotliwość pomiaru musi wynosić co najmniej 12,5 Hz.
    • Musi mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz.
    • NAPISY musi mieć szum pomiaru nieprzekraczający 400 uG/√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.
    • Powinny mieć stałą stabilność błędu wynikającego z szumów na poziomie poniżej 15 μg √Hz na podstawie 24-godzinnego zbioru danych statycznych.
    • Zmiana spolaryzowania 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.
    • POWINIEN mieć widmo szumu białego, aby zapewnić odpowiednią ocenę integralności szumu czujnika.

  • [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.
    • Szum pomiarowy nie może być większy niż 0,014°/s/√Hz.
    • Powinien zapewniać stabilność stałego przesunięcia na poziomie poniżej 0,0002°/s √Hz na podstawie 24-godzinnego statycznego zbioru danych.
    • 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;
    • POWINIEN mieć widmo szumu białego, aby zapewnić odpowiednią ocenę integralności szumu czujnika.
    • Błąd kalibracji powinien być mniejszy niż 0,002 rad/s w zakresie temperatury 10–40 °C, gdy urządzenie jest nieruchome.

  • [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 mieć czujnik TYPE_GEOMAGNETIC_FIELD, który:
    • Zakres pomiarowy musi wynosić co najmniej -900 do +900 uT.
    • 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] MUSI zawierać TYPE_MAGNETIC_FIELD_UNCALIBRATED ze tymi samymi wymaganiami dotyczącymi 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.
    • POWINIEN mieć widmo szumu białego, aby zapewnić odpowiednią ocenę integralności szumu czujnika.
  • [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, który:
    • NALEŻY wdrożyć niebudzącą formę tego czujnika z możliwością buforowania co najmniej 300 zdarzeń czujnika.
    • Musi mieć zużycie energii na etapie grupowania nie większe niż 4 mW.
  • [C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:
    • MUSI mieć zużycie energii nie większe niż 0,5 mW 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 sygnału z urządzenia mierzącego przyspieszenie, który jest raportowany przez akcelerometr, żyroskop i magnetometr, MUSI się mieścić w 2,5 milisekundy.
  • [C-2-14] Musisz mieć sygnatury czasowe zdarzeń czujnika żyroskopu oparte na tej samej podstawie czasowej co podsystem kamery i z dokładnością do 1 milisekundy.
  • [C-2-15] NALEŻY przesyłać próbki do aplikacji w ciągu 5 milisekund od momentu, gdy dane są dostępne na dowolnym z wymienionych powyżej czujników fizycznych.
  • [C-2-16] Podczas korzystania z dowolnej kombinacji tych czujników:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] MOŻE mieć czujnik TYPE_PROXIMITY, ale jeśli jest obecny, MUSI mieć co najmniej 100 miejsc na dane w buforze.

Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje to moc pobieraną przez cały łańcuch czujników: czujnik, wszelkie układy pomocnicze, dedykowany system przetwarzania czujników itp.

Jeśli implementacje urządzeń obejmują bezpośrednią obsługę czujników, urządzenia te:

  • [C-3-1] NALEŻY prawidłowo zadeklarować obsługę typów kanałów bezpośrednich i poziomu stawek raportowania bezpośredniego za pomocą interfejsu API isDirectChannelTypeSupported i getHighestDirectReportRateLevel.
  • [C-3-2] Musi obsługiwać co najmniej 1 z 2 typów bezpośrednich kanałów czujników we wszystkich czujnikach, które deklarują obsługę bezpośredniego kanału czujnika
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
  • Powinien obsługiwać raportowanie zdarzeń za pomocą kanału bezpośredniego czujnika w przypadku czujnika głównego (wersja niewybudzająca) tych typów:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Czytnik linii papilarnych

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

  • POWINIEN zawierać czytnik linii papilarnych.

Jeśli implementacje urządzeń zawierają czytnik linii papilarnych i udostępniają go aplikacjom innych firm, muszą:

  • [C-1-1] MUSISZ zadeklarować obsługę funkcji android.hardware.fingerprint.
  • [C-1-2] NALEŻY w pełni zaimplementować odpowiednie API zgodnie z opisem w dokumentacji pakietu Android SDK.
  • [C-1-3] Wskaźnik fałszywych pozytywnych decyzji nie może być wyższy niż 0,002%.
  • [C-1-4] W przypadku weryfikacji odcisków palców po 5 nieudanych próbach należy ograniczyć liczbę prób do minimum 30 sekund.
  • [C-1-5] Musisz mieć implementację magazynu kluczy opartą na sprzęcie i wykonywać dopasowywanie odcisków palców w zaufanym środowisku wykonawczym (TEE) lub na chipie z bezpiecznym kanałem do TEE.
  • [C-1-6] WSZYSTKIE dane odcisku palca muszą być zaszyfrowane i uwierzytelnione kryptograficznie, tak aby nie można ich było pozyskać, odczytać ani zmienić poza zaufanym środowiskiem wykonawczym (TEE), zgodnie z dokumentacją w wytycznych dotyczących implementacji na stronie projektu Android Open Source.
  • [C-1-7] NALEŻY uniemożliwić dodanie odcisku palca bez uprzedniego ustanowienia łańcucha zaufania, prosząc użytkownika o potwierdzenie istniejących danych logowania na urządzeniu (kod PIN, wzór lub hasło) lub dodanie nowych, które są chronione przez TEE. W ramach implementacji projektu Android Open Source udostępniono mechanizm umożliwiający wykonanie tej czynności.
  • [C-1-8] NIE wolno zezwalać aplikacjom innych firm na rozróżnianie poszczególnych odcisków palców.
  • [C-1-9] MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT flag.
  • [C-1-10] W przypadku uaktualnienia z wersji starszej niż Android 6.0 należy bezpiecznie przenieść dane odcisku palca, aby spełniały powyższe wymagania, lub je usunąć.
  • [SR] MOCNO ZALECANA wartość odsetka fałszywych odrzuceń na poziomie poniżej 10%, zmierzona na urządzeniu.
  • [SR] ZALECAMY, aby opóźnienie od momentu dotknięcia czytnika linii papilarnych do odblokowania ekranu dla jednego zarejestrowanego palca było krótsze niż 1 s.
  • NALEŻY użyć ikony odcisku palca Androida udostępnionej w projekcie Android Open Source.

7.3.11. Czujniki dostępne tylko w Androidzie Automotive

Czujniki związane z motoryzacją są zdefiniowane w pliku android.car.CarSensorManager API.

7.3.11.1. Aktualny sprzęt

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

7.3.11.2. Tryb dzienny/nocny

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

7.3.11.3. Stan jazdy

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

7.3.11.4. Prędkość koła

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

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.
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.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] MUSI implementować 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.
  • Powinien losowo zmienić źródłowy adres MAC i numer sekwencji ramek żądań sondy, raz na początku każdego skanowania, gdy STA jest odłączony.
    • Każda grupa ramek żądań 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ć zwykły (kolejny) wśród żądań sondowania w skanowaniu
    • Numer sekwencyjny żądania sondowania powinien być losowy między ostatnim żądaniem sondowania w ramach skanowania a pierwszym żądaniem sondowania w ramach następnego skanowania.
  • W ramach żądania sondowania, gdy STA jest odłączony, NALEŻY zezwalać tylko na te elementy informacji:
    • Zestaw parametrów SSID (0)
    • Zestaw parametrów DS (3)
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.
  • NALEŻY obsługiwać operacje Wi-Fi i Wi-Fi Direct jednocześnie.

Implementacje na urządzeniu:

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:

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 jest włączona funkcja Wi-Fi Aware.
7.4.2.4. Wi-Fi Passpoint

Implementacje na urządzeniu:

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.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 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, AVCP, OBEX itp., w sposób odpowiedni dla danego 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.

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 i obecne, 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-3] MUSI umożliwiać przesyłanie i odbieranie danych za pomocą tych standardów i protokołów peer-to-peer:

    • ISO 18092
    • LLCP 1.2 (zdefiniowany przez NFC Forum)
    • SDP 1.0 (zdefiniowana przez NFC Forum)
    • Protokół NDEF Push
    • SNEP 1.0 (zdefiniowany przez NFC Forum)
  • [C-1-4] Musi obsługiwać Android Beam i powinna domyślnie włączać tę funkcję.
  • [C-1-5] MUSI być możliwe wysyłanie i odbieranie danych za pomocą funkcji Android Beam, gdy jest ona włączona lub gdy włączony jest inny zastrzeżony tryb NFC P2p.
  • [C-1-6] NALEŻY wdrożyć serwer domyślny SNEP. Prawidłowe komunikaty NDEF otrzymane przez domyślny serwer SNEP MUSZĄ zostać wysłane do aplikacji za pomocą intencji android.nfc.ACTION_NDEF_DISCOVERED. Wyłączenie funkcji Android Beam w ustawieniach NIE MOŻE spowodować wyłączenia wysyłania przychodzących wiadomości NDEF.
  • [C-1-7] MUSI honorować android.settings.NFCSHARING_SETTINGS, aby wyświetlić ustawienia udostępniania NFC.
  • [C-1-8] NALEŻY wdrożyć serwer NPP. Wiadomości odbierane przez serwer NPP MUSZĄ być przetwarzane w taki sam sposób jak przez serwer domyślny SNEP.
  • [C-1-9] NALEŻY zaimplementować klienta SNEP i spróbować wysłać wychodzące NDEF P2P do domyślnego serwera SNEP, gdy włączona jest funkcja Android Beam. Jeśli nie zostanie znaleziony domyślny serwer SNEP, klient MUSI spróbować wysłać wiadomość na serwer NPP.
  • [C-1-10] NALEŻY zezwolić aktywnościom na pierwszym planie na ustawienie wychodzącej wiadomości P2P NDEF za pomocą android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback i android.nfc.NfcAdapter.enableForegroundNdefPush.
  • NALEŻY użyć gestu lub potwierdzenia na ekranie (np. „Dotknij, aby przesłać”), zanim wyślesz wychodzące wiadomości P2P NDEF.
  • [C-1-11] MUSI obsługiwać przekazywanie połączenia NFC do Bluetooth, gdy urządzenie obsługuje profil Bluetooth Push Object.
  • [C-1-12] MUSI obsługiwać przekazywanie połączenia do Bluetooth podczas korzystania z android.nfc.NfcAdapter.setBeamPushUris, poprzez implementację specyfikacji „Connection Handover version 1.2” (Przekazywanie połączenia w wersji 1.2) i „Bluetooth Secure Simple Pairing Using NFC version 1.0” (Bezpieczne parowanie Bluetooth z użyciem NFC w wersji 1.0) z Forum NFC. Takie wdrożenie MUSI implementować usługę LLCP z nazwą „urn:nfc:sn:handover” do wymiany żądania przekazania/rekordów wyboru przez NFC i MUSI używać profilu Bluetooth Object Push do faktycznego przesyłania danych przez Bluetooth. Ze względów historycznych (aby zachować zgodność z urządzeniami z Androidem 4.1) implementacja powinna nadal akceptować żądania SNEP GET w celu wymiany żądania przekazania lub wybranych rekordów za pomocą NFC. Jednak sama implementacja NIE POWINNA wysyłać żądań SNEP GET w celu przejęcia połączenia.
  • [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 przepustowości co najmniej 200 kbps. Przykłady technologii, które spełniają to wymaganie, to EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN itp.
  • [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.
  • NALEŻY zadbać o to, aby komunikacja IPv6 była tak samo niezawodna jak IPv4.
  • [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.
  • POWINNA również obejmować obsługę co najmniej jednego popularnego standardu bezprzewodowego przesyłania danych, takiego jak 802.11 (Wi-Fi), gdy standard sieci fizycznej (taki jak Ethernet) jest podstawowym połączeniem danych.
  • MOŻNA stosować więcej niż jedną formę łączności danych.

Wymagany poziom obsługi IPv6 zależy od typu sieci:

Jeśli implementacje urządzeń obsługują sieci Wi-Fi, mogą:

  • [C-1-1] MUSI obsługiwać stos podwójny i IPv6 w sieci Wi-Fi.

Jeśli implementacje urządzeń obsługują sieci 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:

  • [C-3-1] MUSI spełniać te wymagania w przypadku każdej sieci, z którą jest połączone, gdy urządzenie jest jednocześnie połączone z większą liczbą sieci (np. Wi-Fi i komórkową transmisję danych).
  • NALEŻY obsługiwać działanie IPv6 (tylko IPv6 i ewentualnie skomplikowany stos) w przypadku danych komórkowych.

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ą:

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.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ęć.

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 USB.
  • 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 powinien być nadal 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.

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 w przypadku android.hardware.camera2.
  • [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 zdefiniowanych jako stałe w klasie android.hardware.Camera.Parameters. 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.

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. W przeciwnym razie pamięć współdzielona MUSI być dostępna do zapisu dla każdej aplikacji, która uzyskała to uprawnienie.

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

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:

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 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] 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, aby można było uaktualnić je do 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 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] MOCNO POLECANE jest, aby nie obsługiwać zastrzeżonych metod ładowania, które modyfikują napięcie Vbus poza domyślnymi poziomami lub zmieniają role odbiornika/źródła, ponieważ może to spowodować problemy ze zgodnością z ładowarkami lub urządzeniami, które obsługują standardowe metody dostarczania mocy przez USB. Chociaż jest to „ZALECANA” opcja, w przyszłych wersjach Androida możemy wymagać, aby wszystkie urządzenia z typem C obsługiwały pełną interoperacyjność ze standardowymi ładowarkami typu C.
  • [SR] MOCNO POLECANE jest, aby obsługiwać Power Delivery do przesyłania danych i wymiany ról zasilania, gdy urządzenia obsługują USB typu C i tryb hosta USB.
  • 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ń z portem USB spełniają specyfikację 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).
  • [SR] ZALECAMY wdrażanie klasy audio USB zgodnie z dokumentacją pakietu Android SDK.
  • 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 gniazda słuchawek 3,5 mm w ekosystemie Androida, jeśli implementacja urządzenia zawiera co najmniej 1 analogowe gniazdo audio, co najmniej 1 z nich MUSI 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.
  • [SR] ZALECAMY wykrywanie i mapowanie kodu klucza dla następującego zakresu impedancji pozornej między mikrofonem a przewodami masy na wtyczce audio:
    • 110–180 om: KEYCODE_VOICE_ASSIST
  • NALEŻY obsługiwać wtyczki audio z kolejnością styków OMTP.
  • NALEŻY obsługiwać nagrywanie dźwięku z zestawów słuchawkowych 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ą jako 1, to:

  • [C-2-1] MUSI obsługiwać wykrywanie mikrofonu w podłączonym urządzeniu audio.

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.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. Wysoka wydajność w rzeczywistości wirtualnej

Jeśli implementacje urządzeń wykrywają obsługę wysokiej jakości VR na dłuższe okresy użytkowania za pomocą flagi funkcji android.hardware.vr.high_performance, to:

  • [C-1-1] Musi mieć co najmniej 2 rdzenie fizyczne.
  • [C-1-2] MUSISZ zadeklarować android.software.vr.mode feature.
  • [C-1-3] MUSI obsługiwać tryb stałej wydajności.
  • [C-1-4] MUSI obsługiwać OpenGL ES 3.2.
  • [C-1-5] Musi obsługiwać interfejs Vulkan na poziomie sprzętowym 0 i powinien obsługiwać interfejs Vulkan na poziomie sprzętowym 1.
  • [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 i EGL_EXT_protected_content oraz udostępnić je na liście dostępnych rozszerzeń EGL.
  • [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-8] NALEŻY zaimplementować rozszerzenia GL_EXT_multisampled_render_to_texture, 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-1-9] NALEŻY wdrożyć obsługę flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER i AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA zgodnie z opisem w NDK.
  • [C-1-10] NALEŻY wdrożyć obsługę AHardwareBuffers z większą liczbą warstw.
  • [C-1-11] MUSI obsługiwać dekodowanie H.264 w co najmniej 3840 × 2160 przy 30 fps i 40 Mb/s (co odpowiada 4 przypadkom 1920 × 1080 przy 30 fps i 10 Mb/s lub 2 przypadkom 1920 × 1080 przy 60 fps i 20 Mb/s).
  • [C-1-12] MUSI obsługiwać HEVC i VP9, MUSI być w stanie dekodować co najmniej 1920x1080 przy 30 fps i 10 Mb/s oraz POWINIEN być w stanie dekodować 3840x2160 przy 30 fps i 20 Mb/s (co odpowiada 4 przypadkom 1920x1080 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 FullHD(1080p) i MOCNO zaleca się, aby była to rozdzielczość QuadHD (1440p) lub wyższa.
  • [C-1-15] Wyświetlacz MUSI odświeżać obraz co najmniej z częstotliwością 60 Hz w trybie VR.
  • [C-1-16] Czas reakcji wyświetlacza na przejście z szarego na szary, z białego na czarny i z czarnego na biały MUSI wynosić ≤ 3 ms.
  • [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.
  • [SR] ZALECAMY obsługę funkcji android.hardware.sensor.hifi_sensors i konieczne jest spełnienie wymagań dotyczących żyroskopu, akcelerometru i magnetometru dla android.hardware.hifi_sensors.
  • 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ń w interfejsie 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

Android zawiera tryby w oczekwaniu i oszczędzania energii, które optymalizują wykorzystanie baterii. [SR] Wszystkie aplikacje wyłączone z tych trybów powinny BYĆ WYRAŹNIE widoczne dla użytkownika. [SR] Zalecamy, aby nie odbiegać od projektu Android Open Source w zakresie uruchamiania, konserwacji, algorytmów wybudzania i ustawienia globalnych tych trybów oszczędzania energii.

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 S3 i S4 zgodnie z definicją ACPI, muszą:

  • [C-1-1] NALEŻY w tych stanach tylko wtedy, gdy zamykamy pokrywę, która jest fizyczną częścią urządzenia.

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:

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:

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 załadowanym na ścieżkach uprzywilejowanych obrazu systemu i tylko 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 MOŻESZ przyznawać żadnych uprawnień czasu 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.

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:

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.

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

  • [C-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 urządzeń obejmują wielu użytkowników i deklarują flagę funkcji android.hardware.telephony, muszą:

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

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ń jądra

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).
  • [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).
  • [SR] ZALECAMY stosowanie statycznych i dynamicznych ograniczeń rozmiaru obiektów w kopiach między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY).
  • [SR] ZALECAMY, aby nigdy nie wykonywać kodu w pamięci użytkownika podczas działania w rdzeniu (np. w ramach sprzętowego PXN lub emulacji za pomocą CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] ZDECYDOWANIE POLECANE: nigdy nie czytaj ani nie zapisuj danych w pamięci użytkownika w jądrze poza normalnymi interfejsami API dostępu do danych użytkownika (np. w ramach interfejsu sterownika PAN lub emulacji za pomocą funkcji CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] ZDECYDOWANIE POLECANE: losuj układ kodu jądra i pamięci oraz unikaj sytuacji, które mogłyby zagrozić losowości (np. CONFIG_RANDOMIZE_BASE z entropią bootloadera za pomocą /chosen/kaslr-seed Device Tree node lub EFI_RNG_PROTOCOL).

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

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.

9.8.2. Nagrywam

Jeśli implementacje na urządzeniu obejmują funkcje systemu, które rejestrują treści wyświetlane na ekranie lub nagrywają strumień audio odtwarzany na urządzeniu, nie mogą:

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

9.9. Szyfrowanie danych przechowywanych

Jeśli implementacje urządzeń obsługują bezpieczny ekran blokady zgodnie z opisem w sekcji 9.11.1, to:

  • [C-1-1] Musi obsługiwać szyfrowanie danych w pamięci aplikacji (/data partition) oraz partycji współdzielonej pamięci aplikacji (/sdcard partition), jeśli jest to stała, nieusuwalna część urządzenia.

Jeśli implementacje urządzeń obsługują bezpieczny ekran blokady zgodnie z opisem w sekcji 9.11.1 i obsługują szyfrowanie danych z wykorzystaniem standardu Advanced Encryption Standard (AES) o wydajności ponad 50 MiB/s, to:

  • [C-2-1] Domyślnie należy włączyć szyfrowanie danych w momencie, gdy użytkownik zakończy konfigurację. Jeśli implementacje urządzeń zostały już uruchomione w starszej wersji Androida z zaszyfrowaniem domyślnie wyłączonym, takie urządzenie nie może spełniać wymagań poprzez aktualizację oprogramowania systemowego i MOŻE być wyłączone z obowiązku.

  • POWINNY spełniać powyższy wymóg szyfrowania danych poprzez implementację szyfrowania na poziomie pliku (FBE).

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. Szyfrowanie oparte na plikach

Jeśli implementacje na urządzeniach obsługują FBE, to:

  • [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.
  • [C-1-4] MUSI obsługiwać weryfikację podczas uruchamiania i zapewniać, że klucze DE są przypisane kryptograficznie do zaufanego korzenia sprzętowego urządzenia.
  • [C-1-5] MUSI obsługiwać szyfrowanie zawartości pliku za pomocą AES z kluczem o długości 256 bitów w trybie XTS.

  • [C-1-6] MUSI obsługiwać szyfrowanie nazwy pliku za pomocą AES z kluczem o długości 256 bitów w trybie CBC-CTS.

  • 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] Domyślnie MUSI używać szyfrów, długości kluczy i trybów obsługiwanych obligatoryjnie.

  • NALEŻY zadbać o to, aby wstępnie zainstalowane niezbędne aplikacje (np. budzik, Telefon, Messenger) były świadome bezpośredniego uruchamiania.

  • MOŻE obsługiwać alternatywne szyfry, długości kluczy i tryby szyfrowania treści i nazw plików.

Wspólny projekt Android Open Source udostępnia preferowaną implementację tej funkcji na podstawie funkcji szyfrowania ext4 jądra Linuksa.

9.9.3. Pełne szyfrowanie dysku

Jeśli implementacje urządzeń obsługują pełne szyfrowanie dysku (FDE), to:

  • [C-1-1] NALEŻY użyć AES z kluczem 128-bitowym (lub większym) i trybem przeznaczonym do przechowywania (na przykład AES-XTS, AES-CBC-ESIV).
  • [C-1-2] NALEŻY użyć domyślnego kodu dostępu, aby opakować klucz szyfrowania. NALEŻY Upewnić się, że klucz szyfrowania NIE ZOSTAJE zapisany w magazynie w niezaszyfrowanej formie.
  • [C-1-3] NALEŻY zapewnić użytkownikowi możliwość zaszyfrowania klucza szyfrowania za pomocą algorytmu AES, z wyjątkiem sytuacji, gdy klucz jest aktywnie używany, a dane logowania na ekranie blokady są rozciągnięte za pomocą algorytmu powolnego rozciągania (np. PBKDF2 lub scrypt).
  • [C-1-4] Powyższy domyślny algorytm rozciągania hasła MUSI być powiązany z tym magazynem kluczy, gdy użytkownik nie określił danych logowania do ekranu blokady lub wyłączył użycie kodu dostępu do szyfrowania, a urządzenie udostępnia magazyn kluczy obsługiwany sprzętowo.
  • [C-1-5] NIE MOŻESZ wysyłać klucza szyfrowania poza urządzenie (nawet gdy jest on zaszyfrowany za pomocą hasła użytkownika lub klucza powiązanego ze sprzętem).

Wspólny projekt Android Open Source udostępnia preferowaną implementację tej funkcji na podstawie funkcji dm-crypt 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.

Weryfikacja podczas uruchamiania to funkcja, która gwarantuje integralność oprogramowania urządzenia. Jeśli implementacja urządzenia obsługuje 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 odblokuje program ładujący.
  • [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.
  • [SR] ZALECAMY używanie nośnika z funkcją ochrony przed modyfikacją: gdy bootloader jest odblokowany. Pamięć z funkcją wykrywania manipulacji oznacza, że ładowarka może wykryć, czy pamięć została naruszona z poziomu HLOS (system operacyjny wysokiego poziomu).
  • [SR] ZALECAMY, aby podczas korzystania z urządzenia wyświetlać użytkownikowi odpowiedni komunikat i wymagać fizycznego potwierdzenia przed przejściem z zamkniętego trybu programu rozruchowego do otwartego.
  • [SR] ZALECAMY wdrażanie ochrony przed cofnięciem zmian w systemie HLOS (np. w przypadku partycji rozruchu i partycji systemowych) oraz używanie magazynu z funkcją wykrywania manipulacji do przechowywania metadanych służących do określania minimalnej dopuszczalnej wersji systemu operacyjnego.
  • 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.

Projekt Android Open Source na upstreamie udostępnia preferowaną implementację tej funkcji w repozytorium external/avb/, która może być zintegrowana z ładownikiem używanym do ładowania Androida.

Implementacje urządzeń z wydajnością szyfrowania Advanced Encryption Standard (AES) powyżej 50 MiB/sekund:

  • [C-2-1] Musi obsługiwać uruchamianie w trybie zweryfikowanym w celu zapewnienia integralności urządzenia.

Jeśli implementacja urządzenia została już uruchomiona bez obsługi weryfikacji podczas uruchamiania w starszej wersji Androida, takie urządzenie nie może dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego i jest zatem zwolnione z tego wymogu.

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 zezwalać na importowanie 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 na bezpiecznym sprzęcie.
  • [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. 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 ona spełniać wymagań dotyczących sprzętowego magazynu kluczy i obsługi attestacji kluczy, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga sprzętowego magazynu kluczy.

9.11.1. Bezpieczna blokada ekranu

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-1-1] W interfejsie ustawień i ekranu blokady użytkownik MUSI zostać poinformowany o sytuacjach, w których automatyczne blokowanie ekranu jest opóźnione lub blokada ekranu może zostać odblokowana przez agenta zaufania. AOSP spełnia to wymaganie, wyświetlając opis tekstowy menu „Ustawienie automatycznego blokowania” i „Ustawienie natychmiastowego blokowania przyciskiem zasilania” oraz odróżnialną ikonę na ekranie blokady.
  • [C-1-2] MUSISZ uwzględnić i w pełni zaimplementować wszystkie interfejsy API zaufanego agenta w klasie DevicePolicyManager, takie jak stała KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-1-3] Nie należy w pełni wdrażać funkcji TrustAgentService.addEscrowToken() na urządzeniu używanym jako główne urządzenie osobiste (np. urządzenie przenośne), ale można w pełni wdrażać tę funkcję na urządzeniach zwykle udostępnianych.
  • [C-1-4] NALEŻY zaszyfrować tokeny dodane przez TrustAgentService.addEscrowToken() przed zapisaniem ich na urządzeniu.
  • [C-1-5] Nie przechowuj klucza szyfrowania na urządzeniu.
  • [C-1-6] NALEŻY poinformować użytkownika o konsekwencjach bezpieczeństwa przed włączeniem tokena powiernikowego w celu odszyfrowania danych.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, to aby taka metoda uwierzytelniania była traktowana jako bezpieczny sposób blokowania ekranu, musi:

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, jeśli są oparte na znanym sekretnym kluczu, to aby taka metoda uwierzytelniania była traktowana jako bezpieczny sposób blokowania ekranu, musi:

  • [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] NIE wolno zastępować żadnej z dotychczasowych metod uwierzytelniania (kod PIN,wzór, hasło) zaimplementowanych i dostępnych w AOSP.
  • [C-3-4] NALEŻY wyłączyć, gdy 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_SOMETHING.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, jeśli są oparte na fizycznym tokenie lub lokalizacji, to aby taka metoda uwierzytelniania była traktowana jako bezpieczny sposób blokowania ekranu, muszą:

  • [C-4-1] MUSI zawierać mechanizm zapasowy, który umożliwia korzystanie z jednej z podstawowych metod uwierzytelniania opartej na znanym kluczu tajnym i spełniającej wymagania dotyczące traktowania jako bezpieczny ekran blokady.
  • [C-4-2] NALEŻY wyłączyć i zezwolić na odblokowanie ekranu tylko za pomocą podstawowej metody 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-4-3] Użytkownik MUSI zostać poproszony o podanie danych do uwierzytelniania podstawowego (np. kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady na podstawie danych biometrycznych, aby taka metoda uwierzytelniania była traktowana jako bezpieczny sposób blokowania ekranu, muszą:

  • [C-5-1] MUSI zawierać mechanizm zapasowy, który umożliwia korzystanie z jednej z podstawowych metod uwierzytelniania opartej na znanym kluczu tajnym i spełniającej wymagania dotyczące traktowania jako bezpieczny ekran blokady.
  • [C-5-2] NALEŻY wyłączyć i zezwolić na uwierzytelnianie podstawowe, aby odblokować ekran, gdy aplikacja Device Policy Controller (DPC) ustawiła zasadę funkcji keguard, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • [C-5-3] MUSI mieć współczynnik błędów równy lub wyższy niż wymagany dla czytnika linii papilarnych zgodnie z opisem w sekcji 7.3.10. W przeciwnym razie MUSI być wyłączony i umożliwiać odblokowanie ekranu tylko za pomocą uwierzytelniania podstawowego, gdy aplikacja Device Policy Controller (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-4] Użytkownik MUSI zostać poproszony o podanie danych uwierzytelniających na potrzeby uwierzytelnienia podstawowego (np. kodu PIN, wzoru lub hasła) co najmniej raz na 72 godziny.

Jeśli implementacje urządzeń dodają lub modyfikują metody uwierzytelniania, aby odblokować ekran blokady, oraz jeśli taka metoda uwierzytelniania będzie używana do odblokowania ekranu blokady, ale nie będzie traktowana jako bezpieczna blokada ekranu, to:

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 utworzone przez użytkowników. Oznacza to wszystkie dane z wyjątkiem tych:
    • Obraz systemu
    • wszelkie pliki systemu operacyjnego wymagane przez obraz systemu.
  • [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.

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 MOCNO zaleca się, aby implementujący urządzenia wprowadzili jak najmniej zmian w implementacji referencyjnej 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 pakietu CTS będą wydawane niezależnie od tej definicji zgodności, a na potrzeby Androida 8.0 może być wydawanych wiele wersji pakietu 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.

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:

12. Historia zmian dokumentu

Oto podsumowanie zmian w definicji zgodności w tej wersji:

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.