Definicja zgodności z Androidem 8.1

1. Wprowadzenie

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

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

W tym dokumencie „implementator urządzeń” to osoba lub organizacja opracowująca sprzęt lub oprogramowanie z Androidem 8.1. „Implementacja na urządzeniu” lub „wdrożenie to rozwiązanie sprzętowe i programowe opracowane tak,

Aby urządzenia zostały uznane za zgodne z Androidem 8.1, MUSZĄ one spełniać wymagania przedstawione w tej definicji zgodności, w tym wszelkie dokumenty dołączając do nich przez odniesienie.

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

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

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

1.1 Struktura dokumentu

1.1.1 Wymagania według typu urządzenia

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

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

1.1.2 Identyfikator wymagania

W przypadku wymagań MUSZĄ przypisano identyfikator wymagania.

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

Każdy identyfikator jest zdefiniowany poniżej:

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

2. Typy urządzeń

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

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

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

2.1 Konfiguracje urządzeń

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

2.2. Wymagania dotyczące urządzenia mobilnego

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

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

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

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

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

2.2.1. Urządzenie

Rozmiar ekranu (artykuł 7.1.1.1)

Implementacje na urządzeniach mobilnych:

  • [H-0-1] MUSI mieć ekran o przekątnej co najmniej 2,5 cala*.

Gęstość ekranu (art. 7.1.1.3)

Implementacje na urządzeniach mobilnych:

  • [H-SR] Zdecydowanie ZALECANE jest zapewnienie użytkownikom możliwości zmiany rozmiaru wyświetlacza.

Starszy tryb zgodności aplikacji (art. 7.1.5)

Implementacje na urządzeniach mobilnych:

  • [H-0-1] MUSI obsługiwać starszy tryb zgodności aplikacji w obecnej wersji kodu open source Androida. Oznacza to, że implementacje urządzenia NIE MOGĄ zmieniać wyzwalaczy ani progów, po których aktywowany jest tryb zgodności. NIE MOGĄ też zmieniać działania samego trybu zgodności.

Klawiatura (sekcja 7.2.1)

Implementacje na urządzeniach mobilnych:

  • [H-0-1] MUSI obsługiwać zewnętrzne aplikacje edytora metody wprowadzania (IME).

Klawisze nawigacyjne (artykuł 7.2.3)

Implementacje na urządzeniach mobilnych:

  • [H-0-1] MUSI zawierać funkcje Ekran główny, Ostatnie i Wstecz.

  • [H-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno zdarzenie normalnego naciśnięcia, jak i przytrzymania funkcji Back (KEYCODE_BACK).

Wprowadzanie danych na ekranie dotykowym (sekcja 7.2.4)

Implementacje na urządzeniach mobilnych:

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

Akcelerometr (sekcja 7.3.1)

Implementacje na urządzeniach mobilnych:

  • [H-SR] Zdecydowanie ZALECANE jest użycie 3-osiowego akcelerometru.

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

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

Żyroskop (artykuł 7.3.4)

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

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

Czujnik zbliżeniowy (sekcja 7.3.8)

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

  • POWINIEN zawierać czujnik zbliżeniowy.

Czujnik pozycji (artykuł 7.3.12)

Implementacje na urządzeniach mobilnych:

  • są ZALECANE, aby obsługiwały czujnik pozycji z 6 stopniami swobody.

Bluetooth (art. 7.4.3)

Implementacje na urządzeniach mobilnych:

  • POWINNO obsługiwać Bluetooth i Bluetooth LE.

Oszczędzanie danych (art. 7.4.7)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pamięć współdzielona aplikacji (artykuł 7.6.2)

Implementacje na urządzeniach mobilnych:

  • [H-0-1] NIE MOŻE udostępniać pamięci współdzielonej aplikacji mniejszej niż 1 GiB.

Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)

Implementacje na urządzeniach mobilnych:

  • POWINIEN mieć port USB obsługujący tryb peryferyjny.

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

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

Mikrofon (sekcja 7.8.1)

Implementacje na urządzeniach mobilnych:

  • [H-0-1] MUSI zawierać mikrofon.

Wyjście audio (artykuł 7.8.2)

Implementacje na urządzeniach mobilnych:

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

Tryb rzeczywistości wirtualnej (art. 7.9.1)

Jeśli implementacje urządzeń mobilnych obsługują tryb VR:

  • [H-1-1] MUSI zadeklarować funkcję android.software.vr.mode*.

Jeśli implementacje urządzenia zadeklarują funkcję android.software.vr.mode:

  • [H-2-1] MUSI zawierać aplikację z włączoną funkcją android.service.vr.VrListenerService, która może być włączona przez aplikacje VR za pomocą android.app.Activity#setVrModeEnabled*.

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

Jeśli implementacje urządzeń mobilnych mogą spełnić wszystkie wymagania dotyczące zadeklarowania flagi funkcji android.hardware.vr.high_performance:

  • [H-1-1] MUSI zadeklarować flagę funkcji android.hardware.vr.high_performance*.

2.2.2. Multimedia

Kodowanie dźwięku (artykuł 5.1.1)

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

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

Dekodowanie dźwięku (artykuł 5.1.2)

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

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

Kodowanie wideo (artykuł 5.2)

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

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

Dekodowanie wideo (artykuł 5.3)

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

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

2.2.3. Oprogramowanie

Zgodność obiektów WebView (artykuł 3.4.1)

Implementacje na urządzeniach mobilnych:

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

Zgodność z przeglądarkami (sekcja 3.4.2)

Implementacje na urządzeniach mobilnych:

  • [H-0-1] MUSI zawierać samodzielną aplikację przeglądarki do przeglądania stron internetowych przez zwykłych użytkowników.

Menu z aplikacjami (sekcja 3.8.1)

Implementacje na urządzeniach mobilnych:

  • [H-SR] Zdecydowanie ZALECANE jest wdrożenie domyślnego programu uruchamiającego, który obsługuje przypinanie skrótów i widżetów w aplikacji.

  • [H-SR] Zdecydowanie ZALECANE jest wdrożenie domyślnego programu uruchamiającego, które zapewnia szybki dostęp do dodatkowych skrótów udostępnianych przez aplikacje innych firm przy użyciu interfejsu API ShortcutManager.

  • [H-SR] Zdecydowanie ZALECANE jest dodanie domyślnego programu uruchamiającego, który wyświetla plakietki przy ikonach aplikacji.

Widżety (sekcja 3.8.2)

Implementacje na urządzeniach mobilnych:

  • [H-SR] Zdecydowanie ZALECANE są obsługa widżetów aplikacji innych firm.

Powiadomienia (art. 3.8.3)

Implementacje na urządzeniach mobilnych:

  • [H-0-1] MUSI zezwalać aplikacjom innych firm na powiadamianie użytkowników o ważnych wydarzeniach za pomocą klas interfejsu Notification i NotificationManager.
  • [H-0-2] MUSI obsługiwać powiadomienia rozszerzone.
  • [H-0-3] MUSI obsługiwać powiadomienia HUD.
  • [H-0-4] MUSI zawierać obszar powiadomień zapewniający użytkownikowi możliwość bezpośredniego sterowania powiadomieniami (np. odpowiadania na wiadomości, drzemki, odrzucania, blokowania) przy użyciu funkcji interfejsu użytkownika, takich jak przyciski poleceń lub panel sterowania (jak w AOSP).

Wyszukiwarka (art. 3.8.4)

Implementacje na urządzeniach mobilnych:

Sterowanie multimediami na ekranie blokady (sekcja 3.8.10)

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

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

Administracja urządzeniem (artykuł 3.9)

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

Ułatwienia dostępu (sekcja 3.10)

Implementacje na urządzeniach mobilnych:

  • [H-SR] MUSI obsługiwać usługi ułatwień dostępu innych firm.

  • [H-SR] Zdecydowanie ZALECANE jest wstępne wczytywanie usług ułatwień dostępu na urządzeniu, które są porównywalne z funkcjami ułatwień dostępu Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie załadowany mechanizm zamiany tekstu na mowę) dostępnych w projekcie open source TalkBack.

Zamiana tekstu na mowę (sekcja 3.11)

Implementacje na urządzeniach mobilnych:

  • [H-0-1] MUSI obsługiwać silniki zamiany tekstu na mowę innych firm.

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

Szybkie ustawienia (sekcja 3.13)

Implementacje na urządzeniach mobilnych:

  • [H-SR] Zdecydowanie ZALECANE jest dodanie komponentu Szybkie ustawienia.

Parowanie urządzenia towarzyszącego (sekcja 3.15)

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

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

2.2.4 Wydajność i moc

Spójność z wrażeniami użytkowników (art. 8.1)

Na urządzeniach mobilnych:

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

Wydajność dostępu do plików (sekcja 8.2)

Implementacje na urządzeniach mobilnych:

  • [H-0-1] MUSI zapewnić wydajność sekwencyjnego zapisu wynoszącą co najmniej 5 MB/s.
  • [H-0-2] MUSI zapewniać wydajność przy losowym zapisie na poziomie co najmniej 0,5 MB/s.
  • [H-0-3] MUSI zapewniać wydajność sekwencyjnego odczytu co najmniej 15 MB/s.
  • [H-0-4] MUSI zapewniać wydajność losowego odczytu z szybkością co najmniej 3,5 MB/s.

Tryby oszczędzania energii (artykuł 8.3)

Na urządzeniach mobilnych:

  • [H-0-1] Wszystkie aplikacje, w przypadku których wyłączono tryby czuwania i uśpienia, MUSZĄ być widoczne dla użytkownika.
  • [H-0-2] Algorytmy wyzwalania, konserwacji, wybudzania i używania globalnych ustawień systemu w trybach czuwania aplikacji i oszczędzania energii w trybie uśpienia NIE MOGĄ odbiegać od zasad projektu Android Open Source Project.

Obliczanie zużycia energii (sekcje 8.4)

Implementacje na urządzeniach mobilnych:

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

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

2.2.5. Model zabezpieczeń

Uprawnienia (artykuły 9.1)

Implementacje na urządzeniach mobilnych:

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

2.3. Wymagania dotyczące telewizora

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

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

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

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

2.3.1 Urządzenie

Nawigacja bezdotykowa (sekcja 7.2.2)

Implementacje na urządzeniach telewizyjnych:

Klawisze nawigacyjne (artykuł 7.2.3)

Implementacje na urządzeniach telewizyjnych:

  • [T-0-1] MUSI udostępniać funkcje ekranu głównego i Wstecz.
  • [T-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno zdarzenie normalnego naciśnięcia, jak i przytrzymania funkcji Back (KEYCODE_BACK).

Przyporządkowanie przycisków (art. 7.2.6.1)

Implementacje na urządzeniach telewizyjnych:

  • [T-0-1] MUSI obejmować obsługę kontrolerów do gier i zadeklarować flagę funkcji android.hardware.gamepad.

Zdalne sterowanie (artykuł 7.2.7)

Implementacje na urządzeniach telewizyjnych:

Żyroskop (artykuł 7.3.4)

Jeśli żyroskop obejmuje żyroskop:

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

Bluetooth (art. 7.4.3)

Implementacje na urządzeniach telewizyjnych:

  • [T-0-1] MUSI obsługiwać Bluetooth i Bluetooth LE.

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

Implementacje na urządzeniach telewizyjnych:

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

Mikrofon (sekcja 7.8.1)

Implementacje na urządzeniach telewizyjnych:

  • POWINIEN zawierać mikrofon.

Wyjście audio (artykuł 7.8.2)

Implementacje na urządzeniach telewizyjnych:

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

2.3.2. Multimedia

Kodowanie dźwięku (artykuł 5.1)

Implementacje na telewizorach MUSZĄ obsługiwać to kodowanie dźwięku:

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

Kodowanie wideo (artykuł 5.2)

Implementacje na telewizorach MUSZĄ obsługiwać to kodowanie wideo:

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

H-264 (art. 5.2.2)

Implementacje urządzeń telewizyjnych:

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

Dekodowanie wideo (artykuł 5.3)

Implementacje na telewizory MUSZĄ obsługiwać to dekodowanie wideo:

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

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

  • [T-SR] MPEG-2

H.264 (art. 5.3.4)

Jeśli implementacje telewizorów obsługują dekodery H.264, umożliwiają one:

  • [T-1-1] MUSI obsługiwać profil High Profile Level 4.2 oraz profil dekodowania HD 1080p (przy 60 kl./s).
  • [T-1-2] MUSI dekodować filmy z profilami HD, zgodnie z informacjami w poniższej tabeli, oraz zakodować je przy użyciu profilu podstawowego, głównego lub wysokiego na poziomie 4.2.

H.265 (HEVC) (art. 5.3.5)

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

  • [T-1-1] MUSI obsługiwać poziom główny profilu głównego na poziomie 4.1.
  • [T-SR] Zdecydowanie ZALECANE jest włączenie szybkości 60 kl./s w przypadku rozdzielczości HD 1080p.

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

  • [T-2-1] Kodek MUSI obsługiwać profil główny poziomu 5 głównego poziomu 5.

VP8 (artykuł 5.3.6)

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

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

Jeśli implementacje urządzeń telewizyjnych obsługują kodek VP8 i rozdzielczość 720p, umożliwiają:

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

VP9 (artykuł 5.3.7)

Jeśli implementacje urządzeń telewizyjnych obsługują kodek VP9 i dekodowanie wideo UHD:

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

Jeśli implementacje urządzeń telewizyjnych obsługują kodek VP9, profil 1080p i sprzętowe dekodowanie formatu VP9:

  • [T-2-1] MUSI obsługiwać 60 kl./s w przypadku rozdzielczości 1080p.

Bezpieczne multimedia (art. 5.8)

Jeśli implementacjami urządzeń to urządzenia Android TV, które obsługują rozdzielczość 4K:

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

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

  • [T-2-1] MUSI obsługiwać standard HDCP 1.4 w przypadku wszystkich przewodowych wyświetlaczy zewnętrznych.

Implementacje na urządzeniach telewizyjnych:

  • [T-SR] Zdecydowanie ZALECANE są jednoczesne dekodowanie bezpiecznych strumieni. Zdecydowanie ZALECANE jest co najmniej jednoczesne dekodowanie dwóch par.

Głośność wyjścia audio (artykuł 5.5.3)

Implementacje na urządzeniach telewizyjnych:

  • [T-0-1] MUSI obsługiwać system wyciszania głównego wyjścia audio oraz dźwięku cyfrowego na obsługiwanych wyjściach, z wyjątkiem skompresowanego przelotowego wyjścia audio (gdzie na urządzeniu nie jest wykonywane dekodowanie dźwięku).

2.3.3 Oprogramowanie

Implementacje na urządzeniach telewizyjnych:

Zgodność z WebView (sekcja 3.4.1)

Implementacje na urządzeniach telewizyjnych:

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

Sterowanie multimediami na ekranie blokady (sekcja 3.8.10)

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

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

Wiele okien (sekcja 3.8.14)

Implementacje na urządzeniach telewizyjnych:

  • [T-SR] Zdecydowanie ZALECANE jest włączenie obsługi wielu okien w trybie obrazu w obrazie (PIP).

Ułatwienia dostępu (sekcja 3.10)

Implementacje na urządzeniach telewizyjnych:

  • [T-SR] MUSI obsługiwać usługi ułatwień dostępu innych firm.

  • [T-SR] Zdecydowanie ZALECANE jest włączenie na urządzeniu implementacji usług ułatwień dostępu porównywalnych do funkcji ułatwień dostępu Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie wczytany mechanizm zamiany tekstu na mowę) zgodnie z projektem open source TalkBack.

Zamiana tekstu na mowę (sekcja 3.11)

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

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

  • [T-0-1] MUSI obsługiwać mechanizm zamiany tekstu na mowę innych firm.

Platforma danych wejściowych dotyczących telewizji (art. 3.12)

Implementacje na urządzeniach telewizyjnych:

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

2.2.4 Wydajność i moc

Spójność z wrażeniami użytkowników (art. 8.1)

Urządzenia telewizyjne:

  • [T-0-1] Stałe opóźnienie klatek. Niespójne opóźnienie renderowania klatki lub opóźnienie renderowania klatek NIE MOŻE mieć miejsca częściej niż 5 klatek na sekundę oraz POWINNY być mniej niż 1 klatka na sekundę.

Wydajność dostępu do plików (sekcja 8.2)

Implementacje na urządzeniach telewizyjnych:

  • [T-0-1] MUSI zadbać o wydajność zapisu sekwencyjnego z szybkością co najmniej 5 MB/s.
  • [T-0-2] MUSI zapewniać wydajność zapisu przy losowym połączeniu z szybkością co najmniej 0,5 MB/s.
  • [T-0-3] MUSI zapewniać wydajność sekwencyjnego odczytu z szybkością co najmniej 15 MB/s.
  • [T-0-4] MUSI zapewniać prędkość odczytu z szybkością losowej co najmniej 3,5 MB/s.

Tryby oszczędzania energii (artykuł 8.3)

Urządzenia telewizyjne:

  • [T-0-1] Wszystkie aplikacje, w przypadku których wyłączono tryby czuwania i uśpienia, MUSZĄ być widoczne dla użytkownika.
  • [T-0-2] Algorytmy wyzwalania, konserwacji, wybudzania oraz korzystanie z globalnych ustawień systemu w trybach Czuwanie aplikacji i Tryb uśpienia nie mogą odbiegać od zasad projektu Android Open Source Project.

Obliczanie zużycia energii (sekcje 8.4)

Implementacje na urządzeniach telewizyjnych:

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

2.4. Wymagania dotyczące zegarka

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

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

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

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

2.4.1. Urządzenie

Rozmiar ekranu (artykuł 7.1.1.1)

Implementacje na zegarkach:

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

Klawisze nawigacyjne (artykuł 7.2.3)

Implementacje na zegarkach:

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

Wprowadzanie danych na ekranie dotykowym (sekcja 7.2.4)

Implementacje na zegarkach:

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

Akcelerometr (sekcja 7.3.1)

Implementacje na zegarkach:

  • [W-SR] Zdecydowanie ZALECANE jest użycie 3-osiowego akcelerometru.

Bluetooth (art. 7.4.3)

Implementacje na zegarkach:

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

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

Implementacje na zegarkach:

  • [W-0-1] MUSI mieć co najmniej 1 GB nieulotnej pamięci masowej na prywatne dane aplikacji (partycja „/data”).
  • [W-0-2] MUSI mieć co najmniej 416 MB pamięci dostępnej dla jądra i przestrzeni użytkownika.

Mikrofon (sekcja 7.8.1)

Implementacje na zegarkach:

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

Wyjście audio (artykuł 7.8.1)

Implementacje na zegarkach:

  • MOŻE BYĆ, ale NIE POWINNO mieć wyjścia audio.

2.4.2 Multimedia

Brak dodatkowych wymagań.

2.4.3 Oprogramowanie

Implementacje na zegarkach:

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

Wyszukiwarka (art. 3.8.4)

Implementacje na zegarkach:

Ułatwienia dostępu (sekcja 3.10)

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

  • [W-1-1] MUSI obsługiwać usługi ułatwień dostępu innych firm.

  • [W-SR] Zdecydowanie ZALECANE jest wstępne wczytywanie usług ułatwień dostępu na urządzeniu, które są porównywalne z funkcjami ułatwień dostępu Switch Access i TalkBack (w przypadku języków obsługiwanych przez wstępnie załadowany mechanizm zamiany tekstu na mowę) dostępnych w projekcie open source TalkBack.

Zamiana tekstu na mowę (sekcja 3.11)

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

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

  • [W-0-1] MUSI obsługiwać mechanizm zamiany tekstu na mowę innych firm.

2.5. Wymagania dotyczące motoryzacji

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

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

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

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

2.5.1 Urządzenie

Rozmiar ekranu (artykuł 7.1.1.1)

Implementacje na urządzeniach motoryzacyjnych:

  • [A-0-1] MUSI mieć przekątną ekranu o przekątnej co najmniej 6 cali.
  • [A-0-2] MUSI mieć układ ekranu o wymiarach co najmniej 750 dp x 480 dp.

Klawisze nawigacyjne (artykuł 7.2.3)

Implementacje na urządzeniach motoryzacyjnych:

  • [A-0-1] MUSI zawierać funkcję ekranu głównego, a MOŻE udostępniać funkcje Wstecz i Ostatnie.
  • [A-0-2] MUSI wysyłać do aplikacji na pierwszym planie zarówno zdarzenie normalnego naciśnięcia, jak i przytrzymania funkcji Back (KEYCODE_BACK).

Akcelerometr (sekcja 7.3.1)

Implementacje na urządzeniach motoryzacyjnych:

  • [A-SR] Zdecydowanie ZALECANE jest użycie 3-osiowego akcelerometru.

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

GPS (artykuł 7.3.3)

Jeśli implementacje urządzeń motoryzacyjnych obejmują odbiornik GPS/GNSS i zgłaszają taką możliwość aplikacjom, możesz użyć flagi funkcji android.hardware.location.gps:

  • [A-1-1] Technologia GNSS MUSI generować rok „2017” lub nowszy.

Żyroskop (artykuł 7.3.4)

Jeśli żyroskop obejmuje urządzenia motoryzacyjne:

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

Czujniki tylko w Androidzie Automotive (art. 7.3.11) Obecne akcesoria (art. 7.3.11.1)

Implementacje na urządzeniach motoryzacyjnych:

  • TRZEBA podać obecny sprzęt jako SENSOR_TYPE_GEAR.

Tryb nocny (sekcja 7.3.11.2)

Implementacje na urządzeniach motoryzacyjnych:

  • [A-0-1] MUSI obsługiwać tryb dzienny/nocny zdefiniowany jako SENSOR_TYPE_NIGHT.
  • [A-0-2] Wartość flagi SENSOR_TYPE_NIGHT MUSI być zgodna z trybem dziennym/nocnym na pulpicie i POWINNA być opracowana na podstawie danych z czujnika jasności otoczenia.
  • Czujnik jasności otoczenia MOŻE być taki sam jak Fotometr.

Stan jazdy (art. 7.3.11.3)

Implementacje na urządzeniach motoryzacyjnych:

  • [A-0-1] MUSI obsługiwać stan jazdy zdefiniowany jako SENSOR_TYPE_DRIVING_STATUS z wartością domyślną DRIVE_STATUS_UNRESTRICTED po zatrzymaniu i zaparkowaniu pojazdu. Producenci urządzeń muszą skonfigurować SENSOR_TYPE_DRIVING_STATUS pod kątem zgodności z wszystkimi przepisami i regulacjami prawnymi obowiązującymi na rynkach, na które produkt jest wysyłany.

Prędkość koła (art. 7.3.11.4)

Implementacje na urządzeniach motoryzacyjnych:

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

Bluetooth (art. 7.4.3)

Implementacje na urządzeniach motoryzacyjnych:

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

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

    • Nawiązywanie połączeń telefonicznych przez profil HFP.
    • Odtwarzanie multimediów przez profil dystrybucji dźwięku (A2DP).
    • Sterowanie odtwarzaniem multimediów w profilu pilota (AVRCP).
    • Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).
  • MUSI obsługiwać profil dostępu do wiadomości (MAP).

Minimalna funkcjonalność sieci (art. 7.4.5)

Implementacje na urządzeniach motoryzacyjnych:

  • POWINNA obsługiwać połączenia transmisji danych przez sieć komórkową.

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

Implementacje na urządzeniach motoryzacyjnych:

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

Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)

Implementacje na urządzeniach motoryzacyjnych:

  • POWINIEN mieć port USB obsługujący tryb peryferyjny.

Mikrofon (sekcja 7.8.1)

Implementacje na urządzeniach motoryzacyjnych:

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

Wyjście audio (artykuł 7.8.2)

Implementacje na urządzeniach motoryzacyjnych:

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

2.5.2 Multimedia

Kodowanie dźwięku (artykuł 5.1)

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

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

Kodowanie wideo (artykuł 5.2)

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

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

Dekodowanie wideo (artykuł 5.3)

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

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

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

  • [A-SR] H.265 HEVC

2.5.3 Oprogramowanie

Implementacje na urządzeniach motoryzacyjnych:

  • [A-0-1] MUSI zadeklarować funkcję android.hardware.type.automotive.
  • [A-0-2] MUSI obsługiwać tryb uiMode = UI_MODE_TYPE_CAR.
  • [A-0-3] Implementacje na Androida Automotive MUSZĄ obsługiwać wszystkie publiczne interfejsy API w przestrzeni nazw android.car.*.

Zgodność obiektów WebView (artykuł 3.4.1)

Implementacje na urządzeniach motoryzacyjnych:

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

Powiadomienia (art. 3.8.3)

Implementacje na urządzeniach z Androidem Automotive:

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

Wyszukiwarka (art. 3.8.4)

Implementacje na urządzeniach motoryzacyjnych:

Interfejs multimediów (sekcja 3.14)

Implementacje na urządzeniach motoryzacyjnych:

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

2.2.4 Wydajność i moc

Tryby oszczędzania energii (artykuł 8.3)

W przypadku implementacji na urządzeniach z branży motoryzacyjnej:

  • [A-0-1] Wszystkie aplikacje zwolnione z trybu czuwania i uśpienia MUSZĄ być widoczne dla użytkownika.
  • [A-0-2] Algorytmy wyzwalania, konserwacji, wybudzania i używania globalnych ustawień systemu w trybach Czuwanie aplikacji i Tryb uśpienia nie mogą odbiegać od zasad projektu Android Open Source Project.

Obliczanie zużycia energii (sekcje 8.4)

Implementacje na urządzeniach motoryzacyjnych:

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

2.2.5. Model zabezpieczeń

Obsługa wielu użytkowników (art. 9.5)

Jeśli w implementacjach na urządzeniach z branży motoryzacyjnej uwzględniono wielu użytkowników:

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

Izolacja systemu w pojazdach samochodowych (art. 9.14)

Implementacje na urządzeniach motoryzacyjnych:

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

2.6. Wymagania dotyczące tabletu

Tablet z Androidem oznacza wdrożenie urządzenia z Androidem, w którym zazwyczaj trzymasz urządzenie obiema dłońmi, a nie w tradycyjnej obudowie.

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

  • mieć źródło zasilania, które pozwala na mobilność, np. baterię.
  • mieć ekran o przekątnej fizycznej, czyli o przekątnej od 7 do 18 cali.

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

2.4.1. Urządzenie

Rozmiar ekranu (artykuł 7.1.1.1)

Implementacje na tabletach:

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

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

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

Tryb urządzenia peryferyjnego USB (sekcja 7.7.1)

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

  • MOŻESZ wdrożyć interfejs Android Open Accessory API (AOA).

Tryb rzeczywistości wirtualnej (art. 7.9.1)

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

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

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

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

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

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

  • [C-0-3] Implementacje urządzeń NIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów API ani podpisów, odbiegać od udokumentowanego działania ani zawierać elementów bez działania, z wyjątkiem przypadków wyraźnie dozwolonych w tej definicji zgodności.

  • [C-0-4] Implementacje na urządzeniach MUSZĄ nadal utrzymywać interfejsy API i działać w sposób rozsądny, nawet jeśli niektóre funkcje sprzętowe, w przypadku których Android obsługuje interfejsy API, są pomijane. Szczegółowe informacje o wymaganiach w tym scenariuszu znajdziesz w sekcji 7.

3.1.1. Rozszerzenia na Androida

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

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

3.2. Zgodność Soft API

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

3.2.1. Uprawnienia

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

3.2.2. Parametry kompilacji

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

  • [C-0-1] Aby zapewnić spójne, istotne wartości w różnych implementacjach urządzeń, w tabeli poniżej znajdziesz dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi implementacje MUSZĄ być zgodne.
Parametr Szczegóły
WERSJA.PREMIERA Wersja obecnie uruchomionego systemu Android w formacie zrozumiałym dla człowieka. To pole MUSI mieć jedną z wartości ciągu znaków zdefiniowanych w 8.1.
WERSJA.SDK Wersja obecnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 8.1 to pole MUSI zawierać wartość całkowitą 8.1_INT.
VERSION.SDK_INT Wersja obecnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 8.1 to pole MUSI zawierać wartość całkowitą 8.1_INT.
WERSJA.INCREMENTALNA Wartość wybrana przez mechanizm implementujący urządzenie, oznaczający konkretną kompilację obecnie działającego systemu Android, w formacie zrozumiałym dla człowieka. Tej wartości NIE WOLNO używać ponownie w różnych kompilacjach udostępnianych użytkownikom. Typowym zastosowaniem tego pola jest wskazywanie numeru kompilacji lub identyfikatora zmiany źródła, które zostały użyte do wygenerowania kompilacji. Nie ma wymagań dotyczących konkretnego formatu tego pola, za wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu („”).
PLANSZOWE Wartość wybrana przez mechanizm implementujący urządzenie, określający konkretny wewnętrzny sprzęt używany przez urządzenie, w formacie zrozumiałym dla człowieka. To pole może być użyte do wskazania konkretnej wersji płyty zasilającej urządzenie. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
MARKI Wartość odzwierciedlająca markę powiązaną z urządzeniem znana użytkownikom. MUSI mieć format zrozumiały dla człowieka i MUSI reprezentować producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
OBSŁUGI_MOŻLIWOŚCI Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
OBSŁUGI_32_BIT_ABIS Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
OBSŁUGI_64_BIT_ABIS Nazwa drugiego zbioru instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI2 Nazwa drugiego zbioru instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
URZĄDZENIE Wartość wybrana przez program implementujący urządzenie, zawierająca nazwę deweloperską lub nazwę kodową identyfikującą konfigurację funkcji sprzętowych i konstrukcję przemysłową urządzenia. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi być zgodna z wyrażeniem regularnym „^[a-zA-Z0-9_-]+$”. Ta nazwa urządzenia NIE MOŻE zmieniać się przez cały okres użytkowania produktu.
DŹWIĘK Ciąg jednoznacznie identyfikujący tę kompilację. MUSI być łatwo zrozumiała dla człowieka. MUSI być zgodna z tym szablonem:

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

Na przykład:

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

Odcisk cyfrowy NIE MOŻE zawierać odstępów. Jeśli inne pola w powyższym szablonie zawierają odstępy, MUSZĄ one zostać zastąpione w odcisku cyfrowym kompilacji innym znakiem, np. znakiem podkreślenia („_”). Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII.

SPRZĘT Nazwa sprzętu (z wiersza poleceń jądra lub /proc). MUSI być łatwo zrozumiała dla człowieka. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
GOSPODARZE Ciąg jednoznacznie identyfikujący hosta, na którym została utworzona kompilacja, w formacie zrozumiałym dla człowieka. Nie ma wymagań dotyczących konkretnego formatu tego pola, za wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu („”).
ID Identyfikator wybrany przez mechanizm implementujący urządzenie w celu odwołania się do konkretnej wersji w formacie zrozumiałym dla człowieka. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale MUSI zawierać wartość na tyle zrozumiałą, aby użytkownicy mogli odróżnić kompilacje oprogramowania. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
PRODUCENT Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma wymagań dotyczących konkretnego formatu tego pola. NIE MOŻE ono mieć wartości null ani pustego ciągu („”). To pole NIE MOŻE się zmieniać przez cały okres użytkowania produktu.
MODEL Wartość wybrana przez program implementujący urządzenie, zawierająca znaną użytkownikowi nazwę urządzenia. POWINIEN być pod tą samą nazwą, pod którą urządzenie jest sprzedawane i sprzedawane użytkownikom. Nie ma wymagań dotyczących konkretnego formatu tego pola. NIE MOŻE ono mieć wartości null ani pustego ciągu („”). To pole NIE MOŻE się zmieniać przez cały okres użytkowania produktu.
USŁUGA Wartość wybrana przez program implementujący urządzenie, zawierająca nazwę programistyczną lub nazwę kodową konkretnego produktu (SKU), która MUSI być niepowtarzalna w ramach tej samej marki. MUSI być zrozumiała dla człowieka, ale niekoniecznie przeznaczona dla użytkowników. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII. Musi ona pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Ta nazwa produktu NIE MOŻE zmieniać się przez cały okres użytkowania produktu.
SERYJNY Numer seryjny sprzętu. MUSI być dostępny i unikalny na wszystkich urządzeniach z tym samym modelem MODEL i MANUFACTURER. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^([a-zA-Z0-9]{6,20}$”).
TAGI Rozdzielona przecinkami lista tagów wybranych przez mechanizm implementujący urządzenie, który dokładniej rozróżnia kompilację. To pole MUSI mieć jedną z wartości odpowiadających 3 typowym konfiguracjom podpisywania platformy Androida: Release-keys, dev-keys lub test-keys.
CZAS Wartość reprezentująca sygnaturę czasową wystąpienia kompilacji.
TYP Wartość wybrana przez narzędzie implementujące urządzenie, określająca konfigurację środowiska wykonawczego kompilacji. To pole MUSI mieć jedną z wartości odpowiadających 3 typowym konfiguracjom środowiska wykonawczego Androida: user, userdebug lub eng.
UŻYTKOWNIK Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował kompilację. Nie ma wymagań dotyczących konkretnego formatu tego pola, za wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu („”).
PAKIET_BEZPIECZEŃSTWA Wartość wskazująca poziom poprawki zabezpieczeń kompilacji. MUSI wskazywać, że kompilacja nie jest w żaden sposób podatna na ataki opisane w wyznaczonym biuletynie na temat bezpieczeństwa publicznego w Androidzie. MUSI mieć format [RRRR-MM-DD] i odpowiadać zdefiniowanym ciągiem znaków udokumentowanym w biuletynie dotyczącym bezpieczeństwa w Androidzie lub w dokumencie Android Security Advisory, na przykład „2015-11-01”.
PODSTAWY_systemu operacyjnego Wartość reprezentująca parametr FINGERINSERT kompilacji, która jest identyczna z tą kompilacją poza poprawkami wymienionymi w biuletynie na temat bezpieczeństwa publicznego w Androidzie. MUSI zgłosić prawidłową wartość. Jeśli taka kompilacja nie istnieje, zgłoś pusty ciąg znaków („”).
WŁAŚCICIEL MOTYWACYJNY Wartość wybrana przez mechanizm implementujący urządzenie identyfikujący konkretną wersję wewnętrznego programu rozruchowego używaną na urządzeniu w formacie zrozumiałym dla człowieka. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
getRadioVersion() MUSI (być lub zwracać) wartość wybraną przez mechanizm implementujący urządzenie identyfikującą konkretną wewnętrzną wersję radia/modemu używaną w urządzeniu, w formacie zrozumiałym dla człowieka. Jeśli urządzenie nie ma wewnętrznego radia/modema, MUSI zwracać wartość NULL. Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego „^[a-zA-Z0-9._-,]+$”.

3.2.3 Zgodność intencji

3.2.3.1. Podstawowe intencje aplikacji

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

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

    • Zegar biurkowy
    • Przeglądarka
    • Kalendarz
    • Kontakty
    • Galeria
    • Wyszukiwanie globalne
    • Wyrzutnia
    • Muzyka
    • Ustawienia
3.2.3.2. Rozwiązanie intencji
  • [C-0-1] Android jest rozszerzoną platformą, dlatego implementacje urządzeń MUSZĄ zezwalać na zastąpienie każdego wzorca intencji wymienionego w sekcji 3.2.3.1 przez aplikacje innych firm. Implementacja open source Androida na to pozwala domyślnie.

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

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

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

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

  • [C-0-4] MUSI spróbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji linków do zasobów cyfrowych, zgodnie z implementacją Menedżera pakietów w starszym projekcie Android Open Source.
  • [C-0-5] MUSI próbować zweryfikować filtry intencji podczas instalacji aplikacji i ustawić wszystkie zweryfikowane filtry intencji UIR jako domyślne moduły obsługi aplikacji (UIR).
  • MOGĄ ustawić filtry intencji URI jako domyślne moduły obsługi ich identyfikatorów URI, jeśli zostaną one zweryfikowane, ale inne filtry URI kandydata nie przejdą weryfikacji. Jeśli tak działa implementacja na urządzeniu, MUSI udostępniać w menu ustawień odpowiednie zastąpienia wzorca identyfikatora URI.
  • MUSI udostępniać w Ustawieniach te opcje linków do aplikacji w poszczególnych aplikacjach:
    • [C-0-6] Użytkownik MUSI mieć możliwość całościowego zastępowania domyślnego działania linków aplikacji: zawsze otwieraj, zawsze pytaj lub nigdy nie otwieraj – to ustawienie musi mieć zastosowanie do wszystkich kandydujących filtrów intencji URI.
    • [C-0-7] Użytkownik MUSI wyświetlić listę filtrów intencji URI kandydatów.
    • Implementacja na urządzeniu MOŻE dać użytkownikowi możliwość zastąpienia wybranych filtrów intencji URI, które zostały zweryfikowane, na podstawie poszczególnych intencji.
    • [C-0-8] Implementacja na urządzeniu MUSI zapewniać użytkownikom możliwość wyświetlenia i zastąpienia konkretnych filtrów intencji URI kandydatów, jeśli implementacja urządzenia umożliwia pomyślne przejście weryfikacji przez niektóre filtry intencji URI kandydatów, a inne – niepowodzeniem.
3.2.3.3 Przestrzenie nazw intencji
  • [C-0-1] Implementacje urządzeń NIE MOGĄ zawierać żadnych komponentów Androida, które uwzględniają nowe intencje lub wzorce intencji transmisji za pomocą ciągu ACTION, CATEGORY lub innego klucza w przestrzeni nazw android. lub com.android..
  • [C-0-2] Moduły implementujące urządzenia NIE MOGĄ zawierać żadnych komponentów Androida, które uwzględniają nowe intencje lub wzorce intencji transmisji używających ACTION, CATEGORY lub innego ciągu kluczowego w przestrzeni pakietu należącej do innej organizacji.
  • [C-0-3] Mechanizmy implementujące urządzenia NIE MOGĄ zmieniać ani rozszerzać żadnych wzorców intencji używanych przez podstawowe aplikacje wymienione w sekcji 3.2.3.1.
  • Implementacje na urządzeniach MOGĄ zawierać wzorce intencji wykorzystujące przestrzenie nazw w jasny i wyraźny sposób powiązane z ich własną organizacją. Zakaz ten jest podobny do zakazu określonego dla klas języka Java w sekcji 3.6.
3.2.3.4. Intencje związane z transmisją

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

Implementacje na urządzeniach:

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

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

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

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

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

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

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

3.2.4 Działania na ekranach dodatkowych

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

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

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

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

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

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

3.3. Zgodność z natywnym interfejsem API

Implementacje na urządzeniach to:

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

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

3.3.1 Interfejsy binarne aplikacji

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

Implementacje na urządzeniach:

  • [C-0-1] MUSI być zgodny z co najmniej 1 interfejsem ABI i musi być zgodny z pakietem Android NDK.
  • [C-0-2] MUSI obejmować obsługę kodu działającego w środowisku zarządzanym w celu wywołania kodu natywnego z użyciem standardowej semantyki JNI (Java Native Interface).
  • [C-0-3] MUSI być zgodna ze źródłem (tzn. z nagłówkiem) i z kodem binarnym (w przypadku interfejsu ABI) z każdą wymaganą biblioteką z poniższej listy.
  • [C-0-4] MUSI obsługiwać odpowiednik 32-bitowego interfejsu ABI, jeśli obsługiwany jest dowolny 64-bitowy interfejs ABI.
  • [C-0-5] MUSI podawać dokładne raporty dotyczące natywnego interfejsu binarnego aplikacji (ABI) obsługiwanego przez urządzenie, za pomocą parametrów android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS i android.os.Build.SUPPORTED_64_BIT_ABIS. Każdy interfejs ABI jest oddzielony przecinkami w kolejności od najbardziej do najmniej preferowanego.
  • [C-0-6] MUSI zgłaszać za pomocą powyższych parametrów tylko interfejsy ABI udokumentowane i opisane w najnowszej wersji dokumentacji zarządzania ABI w Androidzie NDK. MUSZĄ obsługiwać rozszerzenie Advanced SIMD (NEON).

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

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

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

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

Kolejne wersje pakietu Android NDK mogą wprowadzić obsługę dodatkowych interfejsów ABI.

3.3.2 Zgodność z 32-bitowym kodem natywnym ARM

W przypadku urządzeń z 64-bitową architekturą ARM:

  • [C-1-1] Chociaż architektura ARMv8 wycofuje kilka operacji procesora, w tym niektóre operacje używane w istniejącym kodzie natywnym, poniższe wycofane operacje MUSZĄ pozostać dostępne w 32-bitowym natywnym kodzie ARM – zarówno przez natywnego procesora CPU, jak i przez emulację oprogramowania:

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

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

  • [C-2-1] W polu /proc/cpuinfo MUSI zawierać te wiersze, jeśli jest odczytywany przez 32-bitowe aplikacje ARM, aby zapewnić zgodność z aplikacjami utworzonymi za pomocą starszych wersji Androida NDK.

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

  • Nie wolno zmieniać /proc/cpuinfo podczas odczytu przez 64-bitowe aplikacje z architekturą ARM lub inne aplikacje.

3.4 Zgodność z internetem

3.4.1 Zgodność z WebView

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

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

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

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

    • Wartość ciągu $(VERSION) MUSI być taka sama jak wartość android.os.Build.VERSION.Release.
    • Wartość ciągu $(MODEL) MUSI być taka sama jak wartość android.os.Build.MODEL.
    • Wartość ciągu $(BUILD) MUSI być taka sama jak wartość android.os.Build.ID.
    • Wartość ciągu $(CHROMIUM_VER) MUSI być wersją przeglądarki Chromium z nadrzędnego projektu Android Open Source.
    • Implementacje na urządzeniach MOGĄ pominąć element „mobilny” w ciągu znaków klienta użytkownika.

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

3.4.2. Zgodność z przeglądarką

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

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

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

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

3.5. Zgodność behawioralna interfejsu API

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

  • [C-0-1] Urządzenia NIE MOGĄ zmieniać działania ani semantyki intencji standardowej.
  • [C-0-2] Urządzenia NIE MOGĄ zmieniać semantyki cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (np. Service, Activity czy ContentProvider).
  • [C-0-3] Urządzenia NIE MOGĄ zmieniać semantyki uprawnień standardowych.
  • Urządzenia NIE MOGĄ zmieniać ograniczeń nałożonych na aplikacje w tle. Dotyczy to zwłaszcza aplikacji działających w tle:
    • [C-0-4] Aby otrzymywać dane wyjściowe z GnssMeasurement i GnssNavigationMessage, MUSISZ przestać wykonywać wywołania zwrotne zarejestrowane przez aplikację.
    • [C-0-5] MUSI ograniczać częstotliwość aktualizacji dostarczanych do aplikacji za pomocą klasy interfejsu API LocationManager lub metody WifiManager.startScan().
    • [C-0-6] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, NIE MOŻE umożliwiać rejestrowania odbiorników na potrzeby niejawnych komunikatów Androida w pliku manifestu, chyba że intencja transmisji wymaga uprawnienia "signature" lub "signatureOrSystem" protectionLevel lub znajduje się na liście wykluczeń.
    • [C-0-7] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI zatrzymywać usługi w tle, tak jakby aplikacja wywołała metodę stopSelf(), chyba że aplikacja znajduje się na tymczasowej liście dozwolonych, aby umożliwić wykonywanie zadania, które jest widoczne dla użytkownika.
    • [C-0-8] Jeśli aplikacja jest kierowana na interfejs API na poziomie 25 lub wyższym, MUSI uruchamiać blokady uśpienia ustawione przez aplikację.

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

3.6. Przestrzenie nazw interfejsów API

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

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

Oznacza to, że:

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

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

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

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

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

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

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

3.7. Zgodność środowiska wykonawczego

Implementacje na urządzeniach:

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

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

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

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

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

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

3.8. Zgodność interfejsu użytkownika

3.8.1 Menu z aplikacjami (ekran główny)

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

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

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

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

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

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

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

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

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

3.8.2 Widżety

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

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

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

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

3.8.3 Powiadomienia

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

3.8.3.1 Prezentacja powiadomień

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

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

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

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

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

  • [C-3-1] Przy prezentowaniu powiadomień z ostrzeżeniem MUSI używać widoku powiadomień HUD i zasobów zgodnie z opisem w klasie interfejsu API Notification.Builder.
3.8.3.2 Usługa powiadamiania słuchaczy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.5 Alerty i powiadomienia

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

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

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

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

3.8.6 Motywy graficzne

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

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

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

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

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

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

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

3.8.7 Animowane tapety

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

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

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

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

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

3.8.8 Przełączanie aktywności

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

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

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

  • [C-1-1] MUSI obsługiwać do 7 wyświetlonych działań.
  • NALEŻY wyświetlać przynajmniej tytuł 4 aktywności jednocześnie.
  • [C-1-2] MUSI włączyć przypinanie ekranu i umożliwiać użytkownikowi włączenie funkcji w menu ustawień.
  • W ostatnich przypadkach MUSI wyświetlać kolor zaznaczenia, ikonę i tytuł ekranu.
  • POWINIEN wyświetlać afordancję zamykającą („x”), ale MOŻE opóźnić ją do czasu interakcji użytkownika z ekranami.
  • Trzeba wdrożyć skrót, który umożliwi łatwe przechodzenie do poprzedniej aktywności
  • POWINNY jest uruchamiać działanie szybkiego przełączania między 2 ostatnio używanymi aplikacjami, gdy klawisz funkcyjny ostatnich jest naciśnięty dwukrotnie.
  • POWINNY jest wyzwalać tryb wielu okien podzielonego ekranu, jeśli jest obsługiwany, przy przytrzymaniu klawisza funkcji ostatnich okien.

  • MOŻE wyświetlać ostatnie powiązane zdjęcia jako grupę poruszającą się razem.

  • [SR] Zdecydowanie ZALECANE jest użycie nadrzędnego interfejsu użytkownika Androida (lub podobnego interfejsu opartego na miniaturach) na ekranie przeglądowym.

3.8.9 Zarządzanie danymi wejściowymi

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

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

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

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

3.8.10. Sterowanie multimediami na ekranie blokady

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

3.8.11 Wygaszacze ekranu (wcześniej Sny)

Android zapewnia obsługę interaktywnych wygaszaczy ekranu, znanych wcześniej jako Dreams. Wygaszacze ekranu pozwalają użytkownikom korzystać z aplikacji, gdy urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji dokującej. Urządzenia Android Watch MOGĄ obsługiwać wygaszacze ekranu, ale w innych implementacjach należy włączyć obsługę wygaszaczy ekranu i udostępniać użytkownikom opcję ustawień, które pozwalają skonfigurować wygaszacze ekranu w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

3.8.12. Lokalizacja

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

  • [C-1-1] Tryby lokalizacji MUSZĄ być wyświetlane w menu Lokalizacja w sekcji Ustawienia.

3.8.13. Unicode i czcionka

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

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

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

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

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

3.8.14. Wiele okien

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

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

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

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

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

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

3.9. Administracja urządzeniem

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

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

  • [C-1-1] MUSI zadeklarować: android.software.device_admin.
  • [C-1-2] MUSI obsługiwać obsługę administracyjną właściciela urządzenia zgodnie z opisem w sekcji 3.9.1 i sekcji 3.9.1.1.
  • [C-1-3] MUSI zadeklarować obsługę profili zarządzanych za pomocą flagi funkcji android.software.managed_users z wyjątkiem sytuacji, gdy urządzenie jest skonfigurowane w taki sposób, aby zgłaszało samo jako urządzenie z małą ilością pamięci RAM lub przydzielało pamięć wewnętrzną (niemożliwą) jako pamięć współdzieloną.

3.9.1 Obsługa administracyjna urządzeń

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

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

Jeśli implementacje urządzeń deklarują funkcję android.software.device_admin, ale zawierają też zastrzeżone rozwiązanie do zarządzania właścicielem urządzenia oraz zapewniają mechanizm promowania aplikacji skonfigurowanej w danym rozwiązaniu jako „odpowiednika dla właściciela urządzenia” znanej przez standardowe interfejsy API Androida DevicePolicyManager, muszą one:

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

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

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

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

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

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

3.9.2 Obsługa profilu zarządzanego

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

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

3.10. Ułatwienia dostępu

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

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

  • [C-1-1] MUSI zawierać implementację platformy ułatwień dostępu w Androidzie w sposób opisany w dokumentacji pakietu SDK interfejsów Accessibility API.
  • [C-1-2] MUSI generować zdarzenia ułatwień dostępu i dostarczać odpowiednie AccessibilityEvent we wszystkich zarejestrowanych implementacjach AccessibilityService zgodnie z dokumentacją w pakiecie SDK.
  • [C-1-3] MUSI uwzględniać intencję android.settings.ACCESSIBILITY_SETTINGS, aby zapewnić dostępny dla użytkownika mechanizm włączania i wyłączania usług ułatwień dostępu innych firm wraz z wstępnie załadowanymi usługami ułatwień dostępu.
  • [C-1-4] MUSI dodać przycisk na pasku nawigacyjnym systemu, który umożliwia użytkownikowi sterowanie usługą ułatwień dostępu, gdy włączone usługi ułatwień dostępu zadeklarują element AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Pamiętaj, że w przypadku implementacji urządzeń bez paska nawigacyjnego systemu ten wymóg nie ma zastosowania, ale implementacje urządzeń MUSZĄ dawać użytkownikowi możliwość sterowania tymi usługami ułatwień dostępu.

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

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

3.11. Przekształcanie tekstu na mowę

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

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

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

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

3.12. Platforma wejścia TV

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

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

  • [C-1-1] MUSI zadeklarować funkcję platformy android.software.live_tv.
  • [C-1-2] MUSI mieć wstępnie zainstalowaną aplikację telewizyjną i spełniać wszystkie wymagania opisane w sekcji 3.12.1.

3.12.1. Aplikacja TV

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

  • [C-1-1] Aplikacja TV MUSI udostępniać kanały telewizyjne do instalacji i korzystania z nich oraz spełniać te wymagania:

Aplikacja na telewizory wymagana w przypadku implementacji na urządzeniach z Androidem z deklaracją funkcji android.software.live_tv, MUSI spełniać te wymagania:

  • Implementacje na urządzeniu POWINNY być dozwolone wpisywanie danych wejściowych innych firm oparte na TIF (dane wejściowe innych firm) i zarządzanie nimi.
  • Implementacje na urządzeniach MOGĄ dawać możliwość wizualnego rozdzielenia wejściówek opartych na TIF (zainstalowanych danych wejściowych) od źródeł innych firm.
  • Implementacje urządzeń NIE POWINNY wyświetlać danych wejściowych innych firm w odległości więcej niż jednego działania nawigacji od aplikacji TV (np. przez rozwinięcie listy źródeł zewnętrznych w aplikacji TV).

W ramach Android Open Source Project opracowano implementację aplikacji telewizyjnej, która spełnia powyższe wymagania.

3.12.1.1. Elektroniczny przewodnik po programach

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

  • [C-1-1] MUSI wyświetlać informacyjną i interaktywną nakładkę, która MUSI zawierać elektroniczny przewodnik po programach (EPG) wygenerowany na podstawie wartości z pól TvContract.Programs.
  • [C-1-2] Przy zmianie kanału implementacje MUSZĄ wyświetlać dane EPG aktualnie odtwarzanego programu.
  • [SR] Zdecydowanie ZALECANE jest wyświetlanie w równym stopniu zainstalowanych danych wejściowych i danych innych firm. elektroniczny przewodnik po programach NIE POWINNO wyświetlać danych wejściowych innych firm w odległości więcej niż jednego działania nawigacji od zainstalowanych źródeł EPG.
  • Moduł EPG POWINNO wyświetlać informacje ze wszystkich zainstalowanych źródeł i wejścia innych firm.
  • elektroniczny przewodnik po programach może wizualnie rozróżniać zainstalowane wejścia i wejścia innych firm.
3.12.1.2. Nawigacja

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

  • [C-1-1] MUSI umożliwiać korzystanie z tych funkcji za pomocą pada kierunkowego, klawisza Wstecz i klawiszy Home na urządzeniu wejściowym urządzenia Android TV (tj. pilota, aplikacji pilota lub kontrolera do gier):

    • Zmiana kanałów telewizyjnych
    • Otwieram elektroniczny przewodnik po programach
    • Konfigurowanie i dostrajanie zewnętrznych źródeł sygnału TIF (jeśli są obsługiwane)
    • Otwieranie menu Ustawienia

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

3.12.1.3 Łączenie aplikacji wejścia TV

Implementacje na urządzeniach Android TV MUSZĄ obsługiwać łączenie aplikacji do wprowadzania danych TV, co umożliwia przekazywanie przez wszystkie źródła linków do innych działań (np. linków programów na żywo do powiązanych treści). Aplikacja TV POWINIEN pokazywać połączenie aplikacji wejściowej TV, jeśli jest dostępna.

3.12.1.4. Przesunięcie w czasie

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

  • [SR] Zdecydowanie ZALECANA do obsługi przesuwania czasowego, co pozwala użytkownikowi wstrzymywać i wznawiać transmisję na żywo.
  • MUSI umożliwiać użytkownikowi wstrzymanie i wznowienie aktualnie odtwarzanego programu, jeśli dostępne jest dla niego przesunięcie w czasie.
3.12.1.5. Nagranie telewizyjne

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

  • [SR] Zdecydowanie zalecana do obsługi nagrywania telewizyjnego.
  • Jeśli wejście TV obsługuje nagrywanie, a nagrywanie programu nie jest zabronione, elektroniczny przewodnik po programach może umożliwiać nagrywanie programu.

3.13. Szybkie ustawienia

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

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

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

3.14. Interfejs multimediów

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

3.15. Aplikacje błyskawiczne

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

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

3.16. Parowanie urządzenia towarzyszącego

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

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

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

4. Zgodność pakietów aplikacji

Implementacje urządzeń:

  • [C-0-1] MUSI mieć możliwość instalowania i uruchamiania plików „.apk” Androida generowanych za pomocą narzędzia „aapt” zawartego w oficjalnym pakiecie SDK na Androida.
  • Powyższe wymaganie może być trudne, dlatego ZALECANE jest użycie implementacji urządzenia w systemie zarządzania pakietami w ramach referencji AOSP.
  • [C-0-2] MUSI obsługiwać weryfikację plików „.apk” przy użyciu schematu podpisu pliku APK w wersji 2 i podpisywania plików JAR.
  • [C-0-3] NIE MOŻE zwiększać formatu .apk, pliku manifestu Androida, kodu bajtowego Dalvik ani RenderScriptu ani kodu bajtowego RenderScript w sposób, który uniemożliwiałby prawidłowe zainstalowanie i działanie tych plików na innych zgodnych urządzeniach.
  • [C-0-4] NIE MOŻE zezwalać aplikacjom innym niż obecny „instalator, który zarejestrował” pakiet na dyskretne odinstalowanie aplikacji bez pytania, zgodnie z opisem w pakiecie SDK dotyczącym uprawnienia DELETE_PACKAGE. Jedynymi wyjątkami są aplikacja weryfikatora pakietów systemowych obsługująca intencję PACKAGE_NEEDS_VERIFICATION i intencja ACTION_MANAGE_STORAGE aplikacji menedżera miejsca.

Implementacje na urządzeniu NIE MOGĄ instalować pakietów aplikacji z nieznanych źródeł, chyba że aplikacja, która żąda instalacji, spełnia wszystkie te wymagania:

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

Implementacje na urządzeniach MUSZĄ zawierać działanie obsługujące intencję android.settings.MANAGE_UNKNOWN_APP_SOURCES. POWINNY jest oferować użytkownikom zgodę na przyznanie lub unieważnienie uprawnień do instalowania aplikacji z nieznanych źródeł w danej aplikacji, lecz MOGĄ Państwo wdrożyć to rozwiązanie jako brak działania i zwrócić RESULT_CANCELED w przypadku domeny startActivityForResult(), jeśli implementacja urządzenia nie chce, aby użytkownicy mieli taki wybór. Jednak nawet w takich przypadkach należy poinformować użytkownika, dlaczego nie ma takiej możliwości.

5. Zgodność multimediów

Implementacje na urządzeniach:

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

Implementacje na urządzeniach:

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

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

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

5.1. Kodeki multimediów

5.1.1 Kodowanie dźwięku

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

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

  • [C-1-1] PCM/WAVE

5.1.2 Dekodowanie dźwięku

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

Jeśli implementacje urządzenia zadeklarują obsługę funkcji android.hardware.audio.output:

  • [C-1-1] Profil AAC MPEG-4 (AAC LC)
  • [C-1-2] Profil AAC MPEG-4 HE (AAC+)
  • [C-1-3] Profil MPEG-4 HE AACv2 (ulepszony AAC+)
  • [C-1-4] AAC ELD (rozszerzony format AAC z niskim opóźnieniem)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE
  • [C-1-10] Opus

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

  • [C-2-1] Dekodowanie MUSI być wykonywane bez redmiksowania (np. strumień AAC 5.0 musi być zdekodowany na 5 kanałów PCM, a strumień AAC 5.1 – na 6 kanałów PCM).
  • [C-2-2] Metadane zakresu dynamicznego MUSZĄ być zgodne z definicją w dokumencie „Dynamic Range Control (DRC)” w standardzie ISO/IEC 14496-3 oraz kluczami DRC android.media.MediaFormat w celu skonfigurowania działania dekodera dźwięku w zakresie dynamiki. Klucze AAC DRC zostały wprowadzone w interfejsie API 21. Te klucze 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/formaty kontenerów
Profil AAC MPEG-4
(AAC LC) 		Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 8 do 48 kHz.
  • 3GPP (.3GPP)
  • MPEG-4 (.mp4, .m4a)
  • Nieprzetworzony kod AAC ADTS (AAC, ADIF nie jest obsługiwany)
  • MPEG-TS (.ts, bez możliwości przewijania)
Profil MPEG-4 HE AAC (AAC+) Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.
MPEG-4 HE AACv2
Profil (ulepszony AAC+) 		Obsługa treści mono/stereo/5.0/5.1 ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.
AAC ELD (rozszerzone AAC z niskim opóźnieniem) Obsługa treści mono/stereo ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.
AMR-NB 4,75–12,2 kb/s, próbkowanie przy 8 kHz 3GPP (.3GPP)
AMR-WB 9 częstotliwości od 6,60 kb/s do 23,85 kb/s, próbkowanie przy 16 kHz
FLAC Mono/Stereo (brak wielokanałowego). Częstotliwość próbkowania do 48 kHz (zalecamy ustawienie maks. 44,1 kHz w przypadku urządzeń z częstotliwością wyjściową 44,1 kHz, ponieważ redukcja częstotliwości próbkowania od 48 do 44,1 kHz nie zawiera filtra dolnoprzepustowego. 16-bitowy (ZALECANY) bez ditheringu w przypadku wersji 24-bitowej. Tylko FLAC (.flac)
MP3 Stała szybkość transmisji bitów mono/Stereo 8–320 kb/s (CBR) lub zmienna szybkość transmisji bitów (VBR) MP3 (.mp3)
MIDI MIDI typu 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody
  • Wpisz 0 i 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • OTA (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0 lub nowszy)
PCM/WAVE 16-bitowy linearny PCM (oprocentowanie do limitu sprzętowego). Urządzenia MUSZĄ obsługiwać częstotliwość próbkowania w przypadku nieprzetworzonego nagrywania PCM przy częstotliwościach 8000, 11025, 16 000 i 44 100 Hz. WAVE (.wav)
Opus matroska (.mkv), Ogg(.ogg)

5.1.4 Kodowanie obrazu

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

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

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

5.1.5 Dekodowanie obrazu

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

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

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Nieprzetworzony

5.1.6 Szczegóły kodeków obrazu

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

5.1.7 Kodeki wideo

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

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

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

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

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

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

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

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

5.1.8 Lista kodeków wideo

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

5.2. Kodowanie wideo

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

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

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

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

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

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

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

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

5.2.1 H.263

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

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

5.2.2 H-264

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

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

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

  • [C-2-1] MUSI obsługiwać profile kodujące z poniższej tabeli.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 240 piks. 720 x 480 piks. 1280 x 720 piks. 1920 x 1080 piks.
Liczba klatek w filmie 20 kl./s 30 klatek/s 30 klatek/s 30 klatek/s
Szybkość transmisji wideo 384 Kb/s 2 Mb/s 4 Mb/s 10 Mb/s

5.2.3 VP8

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

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

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

  • [C-2-1] MUSI obsługiwać profile kodujące z poniższej tabeli.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 180 piks. 640 x 360 piks. 1280 x 720 piks. 1920 x 1080 piks.
Liczba klatek w filmie 30 klatek/s 30 klatek/s 30 klatek/s 30 klatek/s
Szybkość transmisji wideo 800 Kb/s 2 Mb/s 4 Mb/s 10 Mb/s

5.2.4 VP9

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

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

5.3. Dekodowanie wideo

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

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

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

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

5.3.1 MPEG-2

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

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

5.3.2 H.263

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

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

5.3.3 MPEG-4

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

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

5.3.4 H.264

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

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

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

  • [C-2-1] MUSI obsługiwać profile kodowania wideo HD 720p z poniższej tabeli.
  • [C-2-2] MUSI obsługiwać profile kodowania wideo HD 1080p z poniższej tabeli.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 240 piks. 720 x 480 piks. 1280 x 720 piks. 1920 x 1080 piks.
Liczba klatek w filmie 30 klatek/s 30 klatek/s 60 kl./s 30 kl./s (60 kl./s, telewizja)
Szybkość transmisji wideo 800 Kb/s 2 Mb/s 8 Mb/s 20 Mb/s

5.3.5 H.265 (HEVC)

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

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

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

  • [C-2-1] Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden dekodowanie H.265 lub VP9 w profilach 720, 1080 i UHD.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p UHD
Rozdzielczość wideo 352 x 288 piks. 720 x 480 piks. 1280 x 720 piks. 1920 x 1080 piks. 3840 x 2160 piks.
Liczba klatek w filmie 30 klatek/s 30 klatek/s 30 klatek/s 30/60 kl./s (60 kl./s, telewizja z dekodowaniem sprzętowym H.265) 60 kl./s
Szybkość transmisji wideo 600 Kb/s 1,6 Mb/s 4 Mb/s 5 Mb/s 20 Mb/s

5.3.6 VP8

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

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

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

  • [C-2-1] Implementacje na urządzeniach MUSZĄ obsługiwać profile 720p z tabeli poniżej.
  • [C-2-2] Implementacje urządzeń MUSZĄ obsługiwać profile 1080p z poniższej tabeli.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p
Rozdzielczość wideo 320 x 180 piks. 640 x 360 piks. 1280 x 720 piks. 1920 x 1080 piks.
Liczba klatek w filmie 30 klatek/s 30 klatek/s 30 kl./s (60 kl./s, telewizja) 30 (60 kl./s, telewizja)
Szybkość transmisji wideo 800 Kb/s 2 Mb/s 8 Mb/s 20 Mb/s

5.3.7 VP9

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

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

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

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

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

  • [C-3-1] Implementacje urządzenia MUSZĄ obsługiwać co najmniej 1 dekodowanie VP9 lub H.265 z profili 720, 1080 i UHD.
SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p UHD
Rozdzielczość wideo 320 x 180 piks. 640 x 360 piks. 1280 x 720 piks. 1920 x 1080 piks. 3840 x 2160 piks.
Liczba klatek w filmie 30 klatek/s 30 klatek/s 30 klatek/s 30 kl./s (60 kl./s, telewizja z sprzętowym dekodowaniem VP9) 60 kl./s
Szybkość transmisji wideo 600 Kb/s 1,6 Mb/s 4 Mb/s 5 Mb/s 20 Mb/s

5.4. Nagrywanie dźwięku

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

5.4.1 Przechwytywanie nieprzetworzonego dźwięku

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

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

  • Format: linearny PCM, 16-bitowy

  • Częstotliwość próbkowania: 8000, 11025, 16 000, 44 100 Hz

  • Kanały: mono

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

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

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

  • Format: linearny PCM, 16-bitowy

  • Częstotliwość próbkowania: 22 050, 48 000 Hz
  • Kanały: stereo

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

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

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

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

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

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

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

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

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

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

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

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

5.5. Odtwarzanie dźwięku

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

5.5.1 Odtwarzanie surowego dźwięku

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

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

    • Format: linearny PCM, 16-bitowy
    • Częstotliwość próbkowania: 8000, 11 025, 16 000, 22 050, 32 000, 44 100
    • Kanały: mono, stereo

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

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

5.5.2 Efekty audio

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

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

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

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

Implementacje na urządzeniach motoryzacyjnych:

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

5.6. Opóźnienie dźwięku

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

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

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

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

  • [SR] Opóźnienie na wyjściu „na zimno” (maks. 100 milisekund)
  • [SR] Ciągłe opóźnienie wyjściowe wynoszące maksymalnie 45 milisekund.
  • [SR] Zminimalizuj zakłócenia na zimno

Jeśli po przeprowadzeniu wstępnej kalibracji i używaniu interfejsu API kolejki buforowej OpenSL ES PCM implementacje urządzeń spełniają powyższe wymagania, ze względu na ciągłe opóźnienie sygnału wyjściowego i opóźnienie „na zimno” na co najmniej 1 obsługiwanym urządzeniu wyjściowym audio:

  • [SR] Zdecydowanie ZALECANE jest zgłaszanie dźwięku o krótkim czasie oczekiwania przez zadeklarowanie flagi funkcji android.hardware.audio.low_latency.
  • [SR] ZALECNIE ZALECANE jest też spełnienie wymagań dotyczących dźwięku z małym opóźnieniem przez interfejs AAudio API.

Jeśli implementacje urządzeń nie spełniają wymagań dotyczących dźwięku z małym opóźnieniem w interfejsie API kolejki buforowej OpenSL ES PCM:

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

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

  • [SR] Opóźnienie reakcji „na zimno”: maksymalnie 100 milisekund
  • [SR] Ciągłe opóźnienie sygnału wejściowego: maksymalnie 30 milisekund
  • [SR] Ciągłe opóźnienie w obie strony wynoszące maksymalnie 50 milisekund.
  • [SR] Zmniejszenie zakłóceń podczas działania „na zimno”

5.7. Protokoły sieciowe

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

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

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

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

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

Formaty segmentów multimediów

Formaty segmentów Pliki referencyjne Wymagana obsługa kodeka
Zapis strumienia MPEG-2 ISO 13818 Kodeki wideo:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
Szczegółowe informacje o kodach H264 AVC, MPEG2-4 SP
i MPEG-2 znajdziesz w sekcji 5.1.3.

Kodeki audio:

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

RTSP (RTP, SDP)

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

5.8. Bezpieczne nośniki

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

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

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

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

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

  • [C-3-1] Wszystkie przewodowe wyświetlacze zewnętrzne MUSZĄ obsługiwać standard HDCP 1.2 lub nowszy.

5.9. Interfejs MIDI (Musical Instrument Digital Interface)

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

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

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

5.10. Profesjonalne treści audio

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

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

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

Jeśli implementacje na urządzeniach spełniają wymagania interfejsu API kolejki buforowej OpenSL ES PCM:

  • [SR] Zdecydowanie ZALECANE jest też spełnienie tych samych wymagań przez interfejs API AAudio.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1. Narzędzia dla programistów

Implementacje na urządzeniach:

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

  • Android Debug Bridge (adb)

    • [C-0-2] MUSI obsługiwać wszystkie funkcje adb zgodnie z dokumentacją pakietu Android SDK, w tym dumpsys.
    • [C-0-3] NIE MOŻE zmieniać formatu ani zawartości zdarzeń systemowych urządzenia (batterystats , Disstats, odcisków palców, grafikistats, netstats, powiadomień, procstats) zarejestrowanych za pomocą dumpsys.
    • [C-0-4] demon adb po stronie urządzenia MUSI być domyślnie nieaktywny i musi istnieć dostępny dla użytkownika mechanizm umożliwiający włączenie narzędzia Android Debug Bridge.
    • [C-0-5] MUSI obsługiwać bezpieczne narzędzie adb. Android zapewnia obsługę bezpiecznego pliku adb. Bezpieczny adb włącza narzędzie adb na znanych uwierzytelnionych hostach.

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

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

  • Usługa monitorowania debugowania Dalvik (ddms)

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

6.2. Opcje programisty

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

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

  • [C-0-1] MUSI uwzględniać intencję android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z programowaniem. Nadrzędna implementacja Androida ukrywa menu Opcje programisty i umożliwia użytkownikom uruchomienie Opcji programisty po naciśnięciu 7 (7) razy w menu Ustawienia > Informacje o urządzeniu > Numer kompilacji.
  • [C-0-2] MUSI domyślnie ukrywać Opcje programisty i musi udostępniać mechanizm włączania Opcji programisty bez konieczności dodawania specjalnej listy dozwolonych.
  • MOŻE tymczasowo ograniczyć dostęp do menu Opcje programisty, ukrywając je lub wyłączając je, aby nie rozpraszać uwagi użytkowników w sytuacjach, gdy jest obawa o bezpieczeństwo użytkownika.

7. Zgodność sprzętu

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

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

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

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

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

7.1. Wyświetlacz i grafika

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

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

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

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar ekranu

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

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

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

  • [C-0-2] Implementacje na urządzeniach MUSZĄ poprawnie uwzględniać obsługę rozmiarów ekranu w atrybucie <supports-screens> w pliku AndroidManifest.xml w aplikacjach zgodnie z dokumentacją pakietu Android SDK.

7.1.1.2. Współczynnik proporcji ekranu

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

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

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

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

7.1.1.3 Gęstość ekranu

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

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

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

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

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

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

7.1.2. Wyświetl dane

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

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

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

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

7.1.3 Orientacja ekranu

Implementacje na urządzeniach:

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

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

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

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

7.1.4.1 OpenGL ES

Implementacje na urządzeniach:

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

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

  • [C-1-1] MUSI obsługiwać zarówno platformę OpenGL ES 1.0, jak i 2.0, zgodnie z opisem w dokumentacji pakietu SDK na Androida.
  • ZAWSZE ZALECANE są obsługa OpenGL ES 3.0.
  • MUSI obsługiwać standard OpenGL ES 3.1 lub 3.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • POWINNO obsługiwać platformę Vulkan 1.0.

Implementacje urządzeń z obsługą interfejsu Vulkan 1.0:

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

Implementacje na urządzeniach bez obsługi interfejsu Vulkan 1.0:

  • [C-2-1] NIE MOŻE deklarować żadnych flag funkcji interfejsu Vulkan (np. android.hardware.vulkan.level, android.hardware.vulkan.version).
  • [C-2-2] NIE MOŻE wyliczać żadnych elementów VkPhysicalDevice dla natywnego interfejsu API Vulkan vkEnumeratePhysicalDevices().
7.1.4.3 RenderScript
  • [C-0-1] Implementacje na urządzeniach MUSZĄ obsługiwać protokół Android RenderScript, zgodnie z opisem w dokumentacji pakietu Android SDK.
Przyspieszenie grafiki 2D 7.1.4.4

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

Implementacje na urządzeniach:

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

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

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

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

  • [C-1-1] MUSI mieć wyświetlacz z kalibracją kolorów.
  • [C-1-2] MUSI mieć wyświetlacz, którego zakres obejmuje całą paletę kolorów sRGB w przestrzeni CIE 1931 xyY.
  • [C-1-3] MUSI mieć wyświetlacz, którego gatunek ma obszar co najmniej 90% obszaru NTSC 1953 w przestrzeni CIE 1931 xyY.
  • [C-1-4] MUSI obsługiwać standard OpenGL ES 3.0, 3.1 lub 3.2 i prawidłowo go zgłaszać.
  • [C-1-5] MUSI reklamować wsparcie dotyczące 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] Zdecydowanie ZALECANE jest wsparcie dla zasobu GL_EXT_sRGB.

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

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

7.1.5 Tryb zgodności starszych aplikacji

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

7.1.6 Technologia ekranu

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

Implementacje na urządzeniach:

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

7.1.7 Wyświetlacze dodatkowe

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

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

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

7.2. Urządzenia wejściowe

Implementacje na urządzeniach:

7.2.1. Klawiatura

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

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

7.2.2 Nawigacja bezdotykowa

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

Implementacje na urządzeniach:

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

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

7.2.3 Klawisze nawigacyjne

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

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

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

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

Implementacje na urządzeniach:

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

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

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

Jeśli implementacje urządzeń nie obsługują funkcji menu, w celu zapewnienia zgodności wstecznej:

  • [C-3-1] MUSI udostępnić funkcję Menu aplikacjom, gdy targetSdkVersion ma mniej niż 10 lat za pomocą fizycznego przycisku, klawisza oprogramowania lub gestów. Ta funkcja menu powinna być dostępna, chyba że jest ukryta razem z innymi funkcjami nawigacyjnymi.

Jeśli implementacje urządzeń oferują funkcję wspomagania:

  • [C-4-1] MUSI umożliwiać korzystanie z funkcji Asystenta jednym działaniem (np. kliknięciem, dwukrotnym kliknięciem lub gestem), gdy dostępne są inne klawisze nawigacyjne.
  • Zdecydowanie ZALECANE jest użycie funkcji EKRAN GŁÓWNY, gdy jest to wyznaczona interakcja.

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

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

7.2.4 Wprowadzanie tekstu z ekranu dotykowego

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

Implementacje na urządzeniach:

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

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

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

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

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

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

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

7.2.5 Wprowadzanie tekstu fałszywego dotykiem

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

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

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

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

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

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

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

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

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

7.2.6 Obsługa kontrolera gier

7.2.6.1 Mapowania przycisków

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

  • [C-1-1] MUSI mieć umieszczony kontroler lub dostarczyć w pudełku osobny kontroler, który umożliwia wprowadzanie wszystkich zdarzeń wymienionych w tabelach poniżej.
  • [C-1-2] MUSI być w stanie mapować zdarzenia HID na powiązane stałe view.InputEvent Androida, jak podano w tabelach poniżej. Implementacja Androida obejmuje wdrożenie na kontrolery gier, które spełniają to wymaganie.
Przycisk Wykorzystanie HID2 Przycisk Androida
A1 0x09 0x0001 KEYCODE_PRZYCISK_A (96)
B1 0x09 0x0002 KEYCODE_PRZYCISK_B (97)
X1 0x09 0x0004 KEYCODE_PRZYCISK_X (99)
T1 0x09 0x0005 KEYCODE_PRZYCISK_Y (100)
Pad kierunkowy w górę1
Na padzie kierunkowym w dół1 		0x01 0x00393 AXIS_HAT_Y4
Pad kierunkowy w lewo1
Pad kierunkowy w prawo1 		0x01 0x00393 AXIS_HAT_X4
Przycisk na lewym ramieniu1 0x09 0x0007 KEYCODE_Button_L1 (102)
Przycisk na prawym ramieniu1 0x09 0x0008 KEYCODE_PRZYCISK_R1 (103)
Kliknięcie lewym drążkiem1 0x09 0x000E KEYCODE_button_THUMBL (106)
Kliknięcie prawym przyciskiem myszy1 0x09 0x000F KEYCODE_button_THUMBR (107)
Strona główna1 0x0c 0x0223 KEYCODE_HOME (3)
Wstecz1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

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

1 MotionEvent

7.2.7 Pilot

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

7.3. Czujniki

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

Implementacje na urządzeniach:

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

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

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

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

  • [C-1-7] W przypadku każdego interfejsu API wskazanego w dokumentacji pakietu Android SDK jako czujnika, implementacje urządzeń MUSZĄ stale dostarczać okresowe próbki danych, w których zakłócenia są zdefiniowane jako standardowe odchylenie różnicy pomiędzy kolejnymi zdarzeniami.

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

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

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

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

Implementacje na urządzeniach:

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

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

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

7.3.1 Akcelerometr

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

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

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

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

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

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

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

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

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

7.3.2 Magnetometr

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

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

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

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

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

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

  • MOŻESZ zastosować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

  • [C-3-1] MUSI zużywać mniej niż 10 mW.
  • Gdy czujnik jest zarejestrowany w trybie wsadowym z częstotliwością 10 Hz, NALEŻY zużywać mniej niż 3 mW.

7.3.3 GPS

Implementacje na urządzeniach:

  • POWINIEN zawierać odbiornik GPS/GNSS.

Jeśli implementacje urządzeń obejmują odbiornik GPS/GNSS i zgłaszają takie możliwości aplikacjom za pomocą flagi funkcji android.hardware.location.gps, muszą one:

  • [C-1-1] MUSI obsługiwać dane wyjściowe lokalizacji z częstotliwością co najmniej 1 Hz, gdy jest wymagane przez LocationManager#requestLocationUpdate.
  • [C-1-2] MUSI określić lokalizację na otwartym niebie (silne sygnały, niedostateczna ścieżka wielościeżkowa, HDOP < 2) w ciągu 10 sekund (szybszy czas do pierwszej naprawy) przy połączeniu z internetem o szybkości 0,5 Mb/s lub szybszej. Wymóg ten można zazwyczaj spełnić, stosując technikę wspomaganego lub przewidywanego GPS/GNSS w celu zminimalizowania czasu blokady GPS/GNSS (dane pomocnicze obejmują czas odniesienia, lokalizację referencyjną oraz satelitarne dane efemeryczne/zegar).
    • [SR] Zdecydowanie ZALECANE jest, aby urządzenie mogło określić jego lokalizację na niebie w ciągu 10 sekund po ponownym uruchomieniu żądania lokalizacji, nawet po upływie godziny od wstępnego obliczenia lokalizacji, nawet jeśli kolejne żądanie zostało wysłane bez połączenia do transmisji danych lub po wyłączeniu i włączeniu zasilania.

  • Na otwartym niebie po określeniu lokalizacji, gdy jesteś w miejscu lub poruszasz się z przyspieszeniem poniżej 1 metra na sekundę do kwadratu:

    • [C-1-3] MUSI określić lokalizację z dokładnością do 20 metrów i z prędkością do 0, 5 metra na sekundę, w co najmniej 95% przypadków.
    • [C-1-4] MUSI jednocześnie śledzić i raportować za pomocą GnssStatus.Callback co najmniej 8 satelitów z 1 konstelacji.
    • MUSI być w stanie jednocześnie śledzić co najmniej 24 satelity pochodzące z wielu konstelacji (np. GPS + przynajmniej jeden Glonass, Beidou, Galileo).
    • [C-1-5] MUSI zgłaszać generowanie technologii GNSS za pomocą testowego interfejsu API „getGnssYearOfHardware”.
    • [SR] Podczas alarmowego połączenia telefonicznego należy nadal przesyłać zwykłe dane o lokalizacji GPS/GNSS.
    • [SR] Raportuje pomiary GNSS ze wszystkich śledzonych konstelacji (zgodnie z informacjami w komunikatach GnssStatus), z wyjątkiem SBAS.
    • [SR] Raport AGC i częstotliwość pomiaru GNSS.
    • [SR] Raportuje wszystkie szacunkowe dane o dokładności (w tym kierunek, prędkość i pionową lokalizację) dla każdej lokalizacji GPS.
    • Zdecydowanie ZALECANE jest spełnienie jak największej liczby dodatkowych wymagań związanych z urządzeniami zgłaszającymi rok „2016” lub „2017” za pomocą interfejsu Test API LocationManager.getGnssYearOfHardware().

Jeśli implementacje urządzeń obejmują odbiornik GPS/GNSS i zgłaszają możliwość aplikacji za pomocą flagi funkcji android.hardware.location.gps oraz raportu LocationManager.getGnssYearOfHardware() Test API z roku 2016 lub nowszego,:

  • [C-2-1] MUSI zgłaszać pomiary GPS od razu po ich wykryciu, nawet jeśli lokalizacja określona na podstawie GPS/GNSS nie jest jeszcze raportowana.
  • [C-2-2] MUSI podawać pseudozakresy i częstotliwości pseudozakresów GPS, które w warunkach na niebie po określeniu lokalizacji, gdy nieruchomo lub są w ruchu z przyspieszeniem poniżej 0, 2 metra na sekundę do kwadratu, wystarczają do obliczenia pozycji z dokładnością do 20 metrów, a prędkość z zakresu 0, 2 metra na sekundę w co najmniej 95% przypadków.

Jeśli implementacje urządzeń obejmują odbiornik GPS/GNSS i zgłaszają takie możliwości aplikacjom za pomocą flagi funkcji android.hardware.location.gps i raportów interfejsu LocationManager.getGnssYearOfHardware() Test API z roku 2017 lub nowszego,:

  • [C-3-1] MUSI dalej korzystać z normalnych danych o lokalizacji GPS/GNSS podczas połączeń alarmowych.
  • [C-3-2] MUSI raportować pomiary GNSS ze wszystkich śledzonych konstelacji (zgodnie z informacjami o stanie GnssStatus), z wyjątkiem SBAS.
  • [C-3-3] MUSI podawać raporty AGC i częstotliwość pomiarów GNSS.
  • [C-3-4] MUSI podawać wszystkie szacowane wartości dokładności (w tym położenie, prędkość i pionową) w ramach każdej lokalizacji GPS.

7.3.4 Żyroskop

Implementacje na urządzeniach:

  • POWINIEN zawierać żyroskop (czujnik zmian kątowych).
  • NIE POWINNO spełniać czujnika żyroskopu, chyba że wraz z nim jest także 3-osiowy akcelerometr.

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

  • [C-1-1] MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz.
  • [C-1-2] MUSI zaimplementować czujnik TYPE_GYROSCOPE. POWINIEN też zaimplementować czujnik TYPE_GYROSCOPE_UNCALIBRATED.
  • [C-1-3] MUSI być w stanie mierzyć zmiany orientacji kamery do 1000 stopni na sekundę.
  • Rozdzielczość [C-1–4] MUSI mieć co najmniej 12 bitów, a powinna mieć rozdzielczość co najmniej 16 bitów.
  • [C-1-5] MUSI mieć kompensację temperatury.
  • [C-1-6] MUSI być skalibrowany i skompensowany podczas używania. Zachowaj parametry kompensacji między restartami urządzenia.
  • [C-1-7] MUSI mieć wariancję nie większą niż 1e-7 rad^2 / s^2 na Hz (wariancja na Hz lub rad^2 / s). Wariancja może się zmieniać wraz z częstotliwością próbkowania, ale MUSI być ograniczana przez tę wartość. Inaczej mówiąc, jeśli mierzysz wariancję żyroskopu przy częstotliwości próbkowania 1 Hz, POWINIEN wynosić nie więcej niż 1e–7 rad^2/s^2.
  • [SR] Zdecydowanie ZALECANE jest wdrożenie czujnika SENSOR_TYPE_GYROSCOPE_UNCALIBRATED w dotychczasowych i nowych urządzeniach z Androidem.
  • [SR] ZALECANE jest, aby błąd kalibracji wynosił mniej niż 0,01 rad/s, gdy urządzenie pozostaje w temperaturze pokojowej.
  • POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.

Jeśli implementacje urządzeń obejmują żyroskop, akcelerometr i czujnik magnetometrowy:

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

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

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

7.3.5 Barometr

  • Urządzenie POWINIEN zawierać barometr (czujnik ciśnienia powietrza w tle).

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

  • [C-1-1] MUSI zaimplementować i zgłosić czujnik TYPE_PRESSURE.
  • [C-1-2] MUSI być w stanie przesyłać zdarzenia z częstotliwością 5 Hz lub większą.
  • [C-1-3] MUSI mieć kompensację temperatury.
  • [SR] Zdecydowanie ZALECANE jest raportowanie ciśnienia w zakresie od 300 hPa do 1100 hPa.
  • Całkowita dokładność 1hPa.
  • MUSI mieć względną dokładność 0,12 hPa w zakresie 20 hPa (odpowiednik dokładności ok. 1 m na poziomie ok. 200 m na poziomie morza).

7.3.6 Thermometer

Implementacje na urządzeniach: MOŻE zawierać termometr otoczenia (czujnik temperatury). MOGĄ, ale NIE POWINNO zawierać czujnika temperatury procesora.

Jeśli urządzenia są wyposażone w termometr otoczenia (czujnik temperatury):

  • [C-1-1] MUSI być zdefiniowany jako SENSOR_TYPE_AMBIENT_TEMPERATURE i MUSI mierzyć temperaturę otoczenia (w pomieszczeniu lub kabinie pojazdu) w miejscu, w którym użytkownik wchodzi w interakcję z urządzeniem, wyrażoną w stopniach Celsjusza.
  • [C-1-2] MUSI być zdefiniowany jako SENSOR_TYPE_TEMPERATURE.
  • [C-1-3] MUSI mierzyć temperaturę procesora urządzenia.
  • [C-1-4] NIE MOŻE mierzyć żadnych innych temperatury.

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

7.3.7 Fotometr

  • Urządzenia MOGĄ zawierać fotometr (czujnik jasności otoczenia).

7.3.8 Czujnik zbliżeniowy

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

Jeśli urządzenia są wyposażone w czujnik zbliżeniowy:

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

7.3.9. Czujniki wysokiej jakości

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

  • [C-1-1] MUSI identyfikować możliwość za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

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

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

    • MUSI mieć zakres pomiaru od -8 g do +8 g.
    • Rozdzielczość pomiaru MUSI mieć wartość co najmniej 1024 LSB/G.
    • Minimalna częstotliwość pomiaru musi wynosić 12,5 Hz lub mniejszą.
    • Maksymalna częstotliwość pomiaru MUSI wynosić 400 Hz lub więcej.
    • Poziom hałasu pomiaru MUSI być większy niż 400 uG/√ Hz.
    • MUSISZ zaimplementować typ czujnika bez wybudzania z możliwością buforowania wynoszącą co najmniej 3000 zdarzeń.
    • Zużycie energii w grupie MUSI nie być mniejsze niż 3 mW.
    • Stabilność szumu musi być stała na poziomie \<15 μg √Hz z 24-godzinnego statycznego zbioru danych.
    • MUSISZ mieć zmianę odchylenia w porównaniu z temperaturą na poziomie ≤ +/- 1 mg / °C.
    • Optymalna nieliniowość w zakresie ≤ 0,5% oraz zmiana czułości względem temperatury na poziomie ≤ 0,03%/C°.
    • POWINIEN mieć widmo szumu białego, aby zapewnić odpowiednią kwalifikację integralności czujnika.

  • [C-2-2] MUSI mieć TYPE_ACCELEROMETER_UNCALIBRATED z takimi samymi wymaganiami dotyczącymi jakości jak TYPE_ACCELEROMETER.

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

    • MUSI mieć zakres pomiaru od -1000 do +1000 dps.
    • Rozdzielczość pomiaru MUSI mieć co najmniej 16 LSB/dps.
    • Minimalna częstotliwość pomiaru musi wynosić 12,5 Hz lub mniejszą.
    • Maksymalna częstotliwość pomiaru MUSI wynosić 400 Hz lub więcej.
    • Poziom szumu pomiarowego MUSZĄ być większy niż 0,014°/s/√Hz.
    • TREŚCI POWINNA być stała stabilność uprzedzeń na poziomie < 0,0002°/s √Hz z 24-godzinnego statycznego zbioru danych.
    • MUSI mieć zmianę odchylenia w porównaniu z temperaturą na poziomie ≤ +/- 0,05°/ s / °C.
    • TRZEBA zmienić czułość w porównaniu z temperaturą na poziomie ≤ 0,02% / °C.
    • Optymalny rozmiar nieliniowości musi wynosić ≤ 0,2%.
    • Gęstość szumu powinna wynosić ≤ 0,007°/s/√ Hz.
    • POWINIEN mieć widmo szumu białego, aby zapewnić odpowiednią kwalifikację integralności czujnika.
    • Błąd kalibracji powinien wynosić mniej niż 0,002 rad/s w zakresie temperatur od 10 do 40 °C, gdy urządzenie jest nieruchome.

  • [C-2-4] MUSI mieć TYPE_GYROSCOPE_UNCALIBRATED z takimi samymi wymaganiami dotyczącymi jakości jak TYPE_GYROSCOPE.

  • [C-2-5] MUSI mieć czujnik TYPE_GEOMAGNETIC_FIELD, który:
    • MUSI mieć zakres pomiaru od -900 do +900 uT.
    • MUSI mieć rozdzielczość pomiaru wynoszącą co najmniej 5 LSB/uT.
    • MUSI mieć minimalną częstotliwość pomiaru 5 Hz lub mniejszą.
    • Maksymalna częstotliwość pomiaru MUSI 50 Hz lub większa.
    • MUSI zawierać szum pomiarowy nie większy niż 0,5 uT.
  • [C-2-6] MUSI mieć TYPE_MAGNETIC_FIELD_UNCALIBRATED z tymi samymi wymaganiami dotyczącymi jakości co TYPE_GEOMAGNETIC_FIELD, a także:
    • MUSISZ zaimplementować typ czujnika bez wybudzania z możliwością buforowania wynoszącą co najmniej 600 zdarzeń czujnika.
    • POWINIEN mieć widmo szumu białego, aby zapewnić odpowiednią kwalifikację integralności czujnika.
  • [C-2-7] MUSI mieć czujnik TYPE_PRESSURE, który:
    • MUSI mieć zakres pomiaru od 300 do 1100 hPa.
    • Rozdzielczość pomiaru MUSI mieć co najmniej 80 LSB/hPa.
    • Minimalna częstotliwość pomiaru musi wynosić 1 Hz lub mniejszą.
    • Maksymalna częstotliwość pomiaru MUSI wynosić 10 Hz lub więcej.
    • Poziom szumu pomiarowego MUSI być większy niż 2 Pa/√ Hz.
    • Czujnik MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 300 zdarzeń.
    • Zużycie energii w grupie MUSI nie być mniejsze niż 2 mW.
  • [C-2-8] MUSI mieć czujnik TYPE_GAME_ROTATION_VECTOR, który:
    • Czujnik MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 300 zdarzeń.
    • Zużycie energii w grupie MUSI nie być mniejsze niż 4 mW.
  • [C-2-9] MUSI mieć czujnik TYPE_SIGNIFICANT_MOTION, który:
    • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
  • [C-2-10] MUSI mieć czujnik TYPE_STEP_DETECTOR, który:
    • Czujnik MUSI zastosować czujnik bez wybudzania z możliwością buforowania wynoszącą co najmniej 100 zdarzeń.
    • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
    • Zużycie energii w grupie MUSI nie być mniejsze niż 4 mW.
  • [C-2-11] MUSI mieć czujnik TYPE_STEP_COUNTER, który:
    • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
  • [C-2-12] MUSI mieć czujnik TILT_DETECTOR, który:
    • Zużycie energii MUSI nie być mniejsze niż 0,5 mW, gdy urządzenie jest statyczne, i 1,5 mW, gdy urządzenie jest w ruchu.
  • [C-2-13] Sygnatura czasowa tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr, żyroskop i magnetometr MUSI zawierać się w odległości maksymalnie 2,5 milisekundy.
  • [C-2-14] MUSI mieć sygnatury czasowe zdarzeń z czujnika żyroskopu z tego samego okresu co podsystem kamery i z dokładnością do 1 milisekundy do wystąpienia błędu.
  • [C-2-15] MUSI dostarczyć próbki do aplikacji w ciągu 5 milisekund od momentu, gdy dane są dostępne w dowolnym z powyższych czujników fizycznych do aplikacji.
  • [C-2-16] Zużycie energii nie może przekraczać 0,5 mW, gdy urządzenie jest statyczne, oraz 2,0 mW, gdy urządzenie jest w ruchu, jeśli włączona jest dowolna kombinacja tych czujników:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] MOŻE mieć czujnik TYPE_PROXIMITY, ale jeśli jest zainstalowany, MUSI mieć co najmniej 100 zdarzeń na buforze.

Wszystkie wymagania dotyczące zużycia energii opisane w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje on moc wykorzystywaną przez cały łańcuch czujników – czujnik, dowolny układ pomocniczy, dowolny dedykowany system przetwarzania czujników itp.

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

  • [C-3-1] MUSI prawidłowo zadeklarować obsługę typów kanałów bezpośrednich i poziomu stawek bezpośrednich podwładnych za pomocą interfejsów API isDirectChannelTypeSupported i getHighestDirectReportRateLevel.
  • [C-3-2] MUSI obsługiwać co najmniej 1 z 2 typów kanałów bezpośrednich czujnika w przypadku wszystkich czujników, które deklarują obsługę kanału bezpośredniego czujnika.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
  • POWINNA obsługiwać raportowanie zdarzeń przez kanał bezpośredni czujnika głównego czujnika (wariant wybudzenia) tych typów:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Czytnik linii papilarnych

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

  • POWINIEN zawierać czytnik linii papilarnych.

Jeśli implementacje urządzenia obejmują czytnik linii papilarnych i udostępniają go aplikacjom innych firm:

  • [C-1-1] MUSI zadeklarować obsługę funkcji android.hardware.fingerprint.
  • [C-1-2] MUSI w pełni wdrożyć odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK.
  • [C-1-3] MUSI mieć współczynnik fałszywych akceptacji nie wyższy niż 0,002%.
  • [SR] Zdecydowanie ZALECANE jest, aby wskaźnik akceptacji i podszywania się podszył się na poziomie nie wyższym niż 7%.
  • [C-1-4] MUSI ujawniać, że ten tryb może być mniej bezpieczny niż trudny wzór, silny kod PIN lub hasło i wyraźnie wyliczać ryzyko jego włączenia, jeśli odsetek przypadków podszywania się pod inne osoby jest wyższy niż 7%.
  • [C-1-5] W celu weryfikacji odciskiem palca MUSISZ próbować ograniczyć liczbę żądań przez co najmniej 30 sekund po 5 fałszywych próbach weryfikacji odciskiem palca.
  • [C-1-6] MUSI mieć implementację magazynu kluczy wspieranego sprzętowo i dopasowywać odciski palców w zaufanym środowisku TEE lub za pomocą układu z bezpiecznym kanałem TEE.
  • [C-1-7] Wszystkie odciski palców muszą być zaszyfrowane i uwierzytelnione kryptograficznie, tak aby nie można było ich pozyskać, odczytać ani zmienić poza zaufanym środowiskiem wykonawczym (TEE), zgodnie z wytycznymi dotyczącymi wdrażania na stronie Android Open Source Project.
  • [C-1-8] MUSI uniemożliwiać dodanie odcisku palca bez wcześniejszego budowania łańcucha zaufania przez potwierdzenie istniejących danych logowania do urządzenia lub dodanie nowych danych uwierzytelniających urządzenia (kodu PIN, wzoru/hasła) zabezpieczonego przez TEE. Wdrożenie projektu Android Open Source Project zapewnia w ramach ten mechanizm.
  • [C-1-9] NIE MOŻE umożliwiać aplikacjom innych firm rozróżniania poszczególnych odcisków palców.
  • [C-1-10] MUSI uwzględniać flagę DevicePolicyManager.KEYGUARD_DISABLE_FINGERDR.
  • [C-1-11] Po uaktualnieniu z wersji starszej niż 6.0 dane odcisku palca MUSZĄ bezpiecznie przenieść lub usunąć odcisk palca, aby spełnić powyższe wymagania.
  • [SR] Zdecydowanie ZALECANE jest, aby wskaźnik fałszywych odrzuceń wynosił mniej niż 10%, zgodnie z pomiarem na urządzeniu.
  • [SR] ZALECANE jest opóźnienie poniżej 1 sekundy, mierzone od chwili dotknięcia czytnika linii papilarnych do momentu odblokowania ekranu w przypadku 1 zarejestrowanego palca.
  • NALEŻY użyć ikony odcisku palca Android dostępnej w projekcie Android Open Source Project.

7.3.11. Czujniki tylko w Androidzie Automotive

Czujniki samochodowe są zdefiniowane w dokumencie android.car.CarSensorManager API.

7.3.11.1 Obecny sprzęt

Wymagania związane z konkretnymi urządzeniami znajdziesz w Sekcji 2.5.1.

7.3.11.2. Tryb dzienny/nocny

Wymagania związane z konkretnymi urządzeniami znajdziesz w Sekcji 2.5.1.

7.3.11.3 Stan jazdy

Wymagania związane z konkretnymi urządzeniami znajdziesz w Sekcji 2.5.1.

7.3.11.4. Prędkość koła

Wymagania związane z konkretnymi urządzeniami znajdziesz w Sekcji 2.5.1.

7.3.12. Czujnik pozycji

Implementacje na urządzeniach:

  • MOŻE obsługiwać czujnik pozycji z 6 stopniami swobody.

Jeśli implementacje urządzeń obsługują czujnik pozycji z sześcioma stopniami swobody:

  • [C-1-1] MUSI zaimplementować i zgłosić czujnik TYPE_POSE_6DOF.
  • [C-1-2] MUSI być dokładniejszy niż sam wektor obrotu.

7.4 Połączenie transmisji danych

7.4.1 Telefonia

Termin „telefonia” jest używany w interfejsach API Androida, a ten dokument odnosi się w szczególności do sprzętu do nawiązywania połączeń głosowych i wysyłania SMS-ów przez sieć GSM lub CDMA. Choć w tych połączeniach głosowych może być włączona funkcja przełączania pakietów, ale nie jest to konieczne, do celów związanych z Androidem uważa się je za niezależne od wszelkich transmisji danych, które mogą być realizowane w tej samej sieci. Innymi słowy, funkcje „telefonii” i interfejsy API w Androidzie odnoszą się w szczególności do połączeń głosowych i SMS-ów. Na przykład urządzenia, które nie mogą nawiązywać połączeń ani wysyłać/odbierać SMS-ów, nie są uznawane za urządzenia telefoniczne, niezależnie od tego, czy korzystają z sieci komórkowej do przesyłania danych.

  • Android MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami, które nie są telefonami.

Jeśli implementacje urządzeń obejmują usługę telefonii GSM lub CDMA:

  • [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.telephony i inne flagi funkcji podrzędnych zgodnie z technologią.
  • [C-1-2] MUSI wdrożyć pełną obsługę interfejsu API dla danej technologii.

Jeśli implementacje urządzenia nie obejmują sprzętu telefonicznego:

  • [C-2-1] MUSI wdrożyć pełne interfejsy API w trybie bezobsługowym.
7.4.1.1 Zgodność z blokadami numerów

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

  • [C-1-1] MUSI obsługiwać blokowanie numerów
  • [C-1-2] MUSI w pełni zaimplementować usługę BlockedNumberContract i odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu SDK.
  • [C-1-3] MUSI blokować wszystkie połączenia i wiadomości z numeru telefonu w polu „BlockedNumberProvider” bez interakcji z aplikacjami. Jedynym wyjątkiem jest sytuacja, w której blokowanie numerów jest tymczasowo zniesione zgodnie z opisem w dokumentacji pakietu SDK.
  • [C-1-4] W przypadku zablokowanego połączenia NIE MOŻE zapisywać danych do dostawcy rejestru połączeń na platformie.
  • [C-1-5] NIE MOŻE pisać do dostawcy usług telefonicznych w przypadku zablokowanej wiadomości.
  • [C-1-6] MUSI wdrożyć interfejs zarządzania zablokowanymi numerami, który jest otwierany z intencją zwracaną przez metodę TelecomManager.createManageBlockedNumbersIntent().
  • [C-1-7] NIE MOŻE umożliwiać użytkownikom pomocniczym wyświetlania ani edytowania zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że główny użytkownik ma pełną kontrolę nad poszczególnymi instancjami usług telefonicznych na urządzeniu. Każdy interfejs związany z blokowaniem MUSI być ukryty dla użytkowników pomocniczych, a lista zablokowanych MUSI być respektowana.
  • W przypadku aktualizacji Androida do wersji 7.0 NALEŻY przenieść zablokowane numery do dostawcy.
7.4.1.2. Telecom API

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

  • [C-SR] Zdecydowanie ZALECANE jest obsługiwanie zdarzeń KEYCODE_MEDIA_PLAY_PAUSE i KEYCODE_HEADSETHOOK zestawu słuchawkowego w interfejsach API android.telecom w ten sposób:
    • Wywołaj Connection.onDisconnect(), gdy zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia podczas trwającej rozmowy.
    • Wywołaj Connection.onAnswer(), gdy podczas połączenia przychodzącego zostanie wykryte krótkie naciśnięcie kluczowego zdarzenia.
    • Wywołaj Connection.onReject(), gdy podczas połączenia przychodzącego zostanie wykryte długie naciśnięcie kluczowego zdarzenia.
    • Przełącz stan wyciszenia elementu CallAudioState

7.4.2 IEEE 802.11 (Wi-Fi)

Implementacje na urządzeniach:

  • POWINNO obsługiwać co najmniej jedną formę standardu 802.11.

Jeśli implementacje urządzeń obejmują obsługę standardu 802.11 i udostępniają tę funkcję aplikacji innej firmy,

  • [C-1-1] MUSI wdrożyć odpowiedni interfejs API Androida.
  • [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.wifi.
  • [C-1-3] MUSI zaimplementować interfejs API multicast w sposób opisany w dokumentacji pakietu SDK.
  • [C-1-4] MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) podczas działania, w tym:
    • Nawet wtedy, gdy ekran nie jest aktywny.
    • Dotyczy urządzeń Android TV, nawet w trybie gotowości.
  • NALEŻY randomizować źródłowy adres MAC oraz liczbę klatek żądań sondowania raz na początku każdego skanowania, gdy STA jest odłączona.
    • Każda grupa ramek żądania sondowania, która zawiera 1 skanowanie, powinna korzystać z 1 spójnego adresu MAC (NIE POWINNY być randomizowane adresy MAC w trakcie skanowania).
    • Numer sekwencyjny żądania sond powinien powtarzać się w normalny sposób (sekwency) pomiędzy żądaniami sondowania podczas skanowania
    • Numer sekwencyjny żądania sond powinien być randomizowany między ostatnim żądaniem sondowania w ramach skanowania a pierwszym żądaniem sondowania w kolejnym skanowaniu.
  • Gdy ramka STA jest odłączona, w ramkach żądań sond powinna być dopuszczana tylko te elementy informacji:
    • Zestaw parametrów identyfikatora SSID (0)
    • Zestaw parametrów DS (3)
7.4.2.1. Wi-Fi Direct

Implementacje na urządzeniach:

  • POWINNA obsługiwać technologię Wi-Fi Direct (typu Wi-Fi peer-to-peer).

Jeśli implementacje urządzeń obsługują Wi-Fi Direct:

  • [C-1-1] MUSI zaimplementować odpowiedni interfejs API Androida w sposób opisany w dokumentacji pakietu SDK.
  • [C-1-2] MUSI zgłosić funkcję sprzętową android.hardware.wifi.direct.
  • [C-1-3] MUSI obsługiwać normalne działanie Wi-Fi.
  • POWINNA obsługiwać jednocześnie Wi-Fi i Wi-Fi Direct.

Implementacje na urządzeniach:

Jeśli implementacje urządzeń obejmują obsługę TDLS i TDLS włączone w API Wi-FiManager:

  • [C-1-1] MUSI zadeklarować obsługę TDLS do WifiManager.isTdlsSupported.
  • Narzędzia TDLS należy używać tylko wtedy, gdy jest to możliwe i korzystne.
  • POWINNY jest działać mechanizm heurystyczny i NIE używać TDLS, gdy jego wydajność może być gorsza niż przez punkt dostępu Wi-Fi.
7.4.2.3 Rozpoznawalność Wi-Fi

Implementacje na urządzeniach:

Jeśli implementacje urządzeń obejmują obsługę Wi-Fi Aware i udostępniają tę funkcję aplikacjom innych firm, to:

  • [C-1-1] MUSI zaimplementować interfejsy API WifiAwareManager w sposób opisany w dokumentacji pakietu SDK.
  • [C-1-2] MUSI zadeklarować flagę funkcji android.hardware.wifi.aware.
  • [C-1-3] MUSI obsługiwać jednocześnie Wi-Fi i Wi-Fi Aware.
  • [C-1-4] MUSI losowo zmieniać adres interfejsu zarządzania Wi-Fi Aware w odstępach nie dłuższych niż 30 minut i przy włączonej funkcji Wi-Fi Aware.
7.4.2.4. Punkt dostępu Wi-Fi

Implementacje na urządzeniach:

Jeśli implementacje urządzeń obsługują protokół Wi-Fi Passpoint:

  • [C-1-1] MUSI zaimplementować interfejsy API WifiManager związane z Passpoint w sposób opisany w dokumentacji pakietu SDK.
  • [C-1-2] MUSI obsługiwać standard IEEE 802.11u, zwłaszcza związany z wykrywaniem i wyborem sieci, na przykład w ramach usług GAS i Access Network Query Protocol (ANQP).

Jeśli implementacje urządzeń nie obsługują Passpoint Wi-Fi:

  • [C-2-1] Implementacja interfejsów API WifiManager związanych z Passpoint MUSI zgłosić UnsupportedOperationException.

7.4.3 Bluetooth

Jeśli implementacje urządzenia obsługują profil audio Bluetooth:

  • POWINNA obsługiwać zaawansowane kodeki audio i kodeki audio Bluetooth (np. LDAC).

Jeśli implementacje urządzenia zadeklarują funkcję android.hardware.vr.high_performance:

  • [C-1-1] MUSI obsługiwać rozszerzenie Bluetooth 4.2 i Bluetooth LE.

Android obsługuje Bluetooth i Bluetooth Low Energy.

Jeśli implementacje urządzeń obejmują obsługę Bluetootha i Bluetooth Low Energy, aplikacje:

  • [C-2-1] MUSI zadeklarować odpowiednie funkcje platformy (odpowiednio android.hardware.bluetooth i android.hardware.bluetooth_le) i wdrożyć interfejsy API platformy.
  • NALEŻY zaimplementować odpowiednie profile Bluetooth, takie jak A2DP, AVCP, OBEX itp., odpowiednie dla danego urządzenia.

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

  • [C-3-1] MUSI zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
  • [C-3-2] MUSI włączyć interfejsy API Bluetooth oparte na GATT (ogólnym profilu) w sposób opisany w dokumentacji pakietu SDK i w android.bluetooth.
  • [C-3-3] MUSI zgłosić prawidłową wartość BluetoothAdapter.isOffloadedFilteringSupported(), aby wskazać, czy logika filtrowania klas interfejsu ScanFilter została zaimplementowana.
  • [C-3-4] MUSI zgłosić prawidłową wartość pola BluetoothAdapter.isMultipleAdvertisementSupported(), aby wskazać, czy reklamy Low Energy Advertising są obsługiwane.
  • POWINNO obsługiwać przenoszenie logiki filtrowania na chipset Bluetooth podczas wdrażania interfejsu API ScanFilter.
  • POWINNO obsługiwać pobieranie skanowania zbiorczego do chipsetu Bluetooth.

  • POWINNA obsługiwać wiele reklam z co najmniej 4 boksami.

  • [SR] Zdecydowanie ZALECANE jest wdrożenie limitu czasu oczekiwania na rozpoznawalny adres prywatny (RPA) nie dłuższy niż 15 minut i rotacja adresu po przekroczeniu limitu czasu w celu ochrony prywatności użytkowników.

7.4.4 Komunikacja Near Field Communication

Implementacje na urządzeniach:

  • POWINIEN zawierać nadajnik i powiązany sprzęt do komunikacji Near-Field Communications (NFC).
  • [C-0-1] MUSI zaimplementować interfejsy API android.nfc.NdefMessage i android.nfc.NdefRecord, nawet jeśli nie obsługują one NFC lub zadeklaruj funkcję android.hardware.nfc, ponieważ klasy przedstawiają format danych niezależny od protokołu.

Jeśli implementacje urządzeń obejmują sprzęt do komunikacji NFC i planują udostępnić tę funkcję aplikacjom innych firm:

  • [C-1-1] MUSI zgłosić funkcję android.hardware.nfc za pomocą metody android.content.pm.PackageManager.hasSystemFeature().
  • MUSI być w stanie odczytywać i zapisywać wiadomości NDEF z użyciem następujących standardów NFC, zgodnie z poniższymi standardami:
  • [C-1-2] MUSI działać jako czytnik/zapisujący forum NFC (zgodnie ze specyfikacją techniczną NFC Forum-TS-DigitalProtocol-1.0) zgodnie z tymi standardami:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Typy tagów forum NFC 1, 2, 3, 4, 5 (zdefiniowane przez Forum NFC)

  • Zdecydowanie zalecana jest możliwość odczytywania i zapisywania wiadomości NDEF, a także nieprzetworzonych danych przy użyciu następujących standardów NFC. Pamiętaj, że chociaż standardy NFC są określone jako Zdecydowanie ZALECANE, zgodnie z definicją zgodności w przyszłości planujemy zmienić je na MUSI. Standardy te są w tej wersji opcjonalne, ale będą wymagane w kolejnych. Zdecydowanie zalecamy spełnienie tych wymagań już teraz i na urządzeniach, na których działa ta wersja Androida, aby umożliwić ich uaktualnienie do przyszłych wersji platformy.

  • [C-1-3] MUSI mieć możliwość transmisji i odbierania danych przy użyciu następujących standardów i protokołów peer-to-peer:

  • ISO 18092
  • LLCP 1.2 (zdefiniowane przez Forum NFC)
  • SDP 1.0 (zdefiniowane na Forum NFC)
  • Protokół NDEF Push
  • SNEP 1.0 (zdefiniowane przez Forum NFC)
  • [C-1-4] MUSI obsługiwać funkcję Android Beam i POWINIEN domyślnie włączyć Android Beam.
  • [C-1-5] MUSI mieć możliwość wysyłania i odbierania wiadomości za pomocą Android Beam, gdy włączona jest funkcja Android Beam lub inny zastrzeżony tryb NFC P2p.
  • [C-1-6] MUSI zaimplementować domyślny serwer SNEP. Prawidłowe wiadomości NDEF odbierane przez domyślny serwer SNEP MUSZĄ być wysyłane do aplikacji przy użyciu intencji android.nfc.ACTION_NDEF_DISCOVERED. Wyłączenie Android Beam w ustawieniach NIE MOŻE wyłączać wysyłania przychodzących wiadomości NDEF.
  • [C-1-7] MUSI wyświetlać ustawienia udostępniania NFC zgodnie z intencją android.settings.NFCSHARING_SETTINGS.
  • [C-1-8] MUSI zaimplementować serwer NPP. Wiadomości odbierane przez serwer NPP MUSZĄ być przetwarzane w taki sam sposób, jak domyślny serwer SNEP.
  • [C-1-9] MUSI zaimplementować klienta SNEP i próbować wysłać wychodzącego NDEF P2P do domyślnego serwera SNEP, gdy włączona jest funkcja Android Beam. Jeśli nie zostanie znaleziony domyślny serwer SNEP, klient MUSI spróbować wysłać wiadomość do serwera NPP.
  • [C-1-10] MUSI zezwalać na działania na pierwszym planie na ustawianie wychodzących wiadomości NDEF P2P za pomocą metod android.nfc.NfcAdapter.setNdefPushMessage i android.nfc.NfcAdapter.setNdefPushMessageCallback oraz android.nfc.NfcAdapter.enableForegroundNdefPush.
  • Przed wysłaniem wychodzących wiadomości P2P NDEF MUSISZ używać gestu lub potwierdzenia na ekranie, takiego jak „Dotknij, aby przesłać”.
  • [C-1-11] MUSI obsługiwać przekazywanie połączenia NFC do Bluetooth, jeśli urządzenie obsługuje profil push obiektów Bluetooth.
  • [C-1-12] MUSI obsługiwać przekazywanie połączenia do Bluetooth podczas korzystania z android.nfc.NfcAdapter.setBeamPushUris przez wdrożenie specyfikacji „przekazywania połączenia w wersji 1.2” i „bezpiecznego parowania Bluetooth przez NFC w wersji 1.0” na forum NFC. W takiej implementacji MUSI implementować usługę przekazywania LLCP z nazwą usługi „urn:nfc:sn:handover”, która służy do wymiany żądań przekazania/wyboru rekordów przez NFC. Do rzeczywistego przesyłania danych przez Bluetooth MUSI ona używać profilu push obiektu Bluetooth. Ze względów związanych ze starszymi rozwiązaniami (aby zachować zgodność z urządzeniami z Androidem 4.1), implementacja MUSI nadal akceptować żądania SNEP GET dotyczące wymiany żądań przekazania/wyboru rekordów przez NFC. Jednak sama implementacja NIE POWINNO wysyłać żądań SNEP GET do przekazywania połączeń.
  • [C-1-13] W trybie wykrywania NFC MUSI przeprowadzać sondowanie w poszukiwaniu wszystkich obsługiwanych technologii.
  • POWINNY być w trybie wykrywania NFC, gdy urządzenie jest wybudzone, a ekran jest aktywny, a ekran blokady jest odblokowany.
  • MUSI być w stanie odczytać kod kreskowy i adres URL (jeśli jest zakodowany) produktów z kodem kreskowym Thinfilm NFC.

(Pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku wymienionych powyżej specyfikacji JIS, ISO i NFC).

Android obsługuje tryb HCE (NFC).

Jeśli implementacje urządzeń zawierają chipset kontrolera NFC obsługujący HCE (NfcA lub NfcB) i obsługują routing na podstawie identyfikatora aplikacji (AID), te urządzenia:

  • [C-2-1] MUSI zgłaszać stałą funkcję android.hardware.nfc.hce.
  • [C-2-2] MUSI obsługiwać interfejsy NFC HCE API zgodnie z definicją w pakiecie Android SDK.

Jeśli używane urządzenia korzystają z chipsetu kontrolera NFC obsługującego HCE dla NfcF i wdrożą tę funkcję na potrzeby aplikacji innych firm:

  • [C-3-1] MUSI zgłaszać stałą funkcję android.hardware.nfc.hcef.
  • [C-3-2] MUSI zaimplementować interfejsy API karty NfcF zgodnie z definicją w pakiecie SDK na Androida.

Jeśli implementacje urządzeń obejmują ogólną obsługę NFC zgodnie z opisem w tej sekcji oraz technologie MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF w MIFARE Classic) w roli odczytującego/zapisującego, użytkownicy:

  • [C-4-1] MUSI wdrożyć odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
  • [C-4-2] MUSI zgłosić funkcję com.nxp.mifare za pomocą metody android.content.pm.PackageManager.hasSystemFeature(). Pamiętaj, że nie jest to standardowa funkcja Androida, dlatego nie jest widoczna jako stała w klasie android.content.pm.PackageManager.

7.4.5 Minimalne możliwości sieci

Implementacje na urządzeniach:

  • [C-0-1] MUSI obsługiwać co najmniej jedną formę sieci danych. Implementacje urządzeń MUSZĄ obsługiwać co najmniej jeden standard danych o szybkości co najmniej 200 kb/s. Przykłady technologii, które spełniają to wymaganie, to EDGE, HSPA, EV-DO, 802.11g, Ethernet, PAN Bluetooth itp.
  • [C-0-2] MUSI zawierać stos sieci IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection, oraz natywnych interfejsów API, takich jak gniazda AF_INET6.
  • [C-0-3] MUSI domyślnie włączać IPv6.
  • MUSI zadbać o to, aby komunikacja IPv6 była równie niezawodna, jak na przykład IPv4.
  • [C-0-4] MUSI utrzymywać połączenia IPv6 w trybie uśpienia.
  • [C-0-5] Ograniczenie szybkości NIE MOŻE spowodować utraty połączeń IPv6 w żadnej sieci zgodnej z IPv6, w której czas trwania RA wynosi co najmniej 180 sekund.
  • POWINNA też obsługiwać co najmniej jeden popularny standard bezprzewodowych danych, taki jak 802.11 (Wi-Fi), gdy podstawowym połączeniem transmisji danych jest fizyczny standard sieci (np. Ethernet).
  • MOŻESZ wdrożyć więcej niż jedną formę połączeń danych.

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

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

  • [C-1-1] MUSI obsługiwać operacje na stosie podwójnym i tylko IPv6 w Wi-Fi.

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

  • [C-2-1] MUSI obsługiwać operację podwójnego stosu w sieci Ethernet.

Jeśli implementacje urządzeń obsługują komórkową transmisję danych:

  • [C-3-1] MUSI spełniać te wymagania w każdej sieci, do której jest połączone, gdy urządzenie jest jednocześnie połączone z kilkoma sieciami (np. Wi-Fi i komórkowa transmisja danych),
  • POWINNA obsługiwać operację IPv6 (tylko w przypadku protokołu IPv6 i ewentualnie stos podwójny) w ramach komórkowej transmisji danych.

7.4.6 Ustawienia synchronizacji

Implementacje na urządzeniach:

  • [C-0-1] MUSI mieć domyślnie włączone ustawienie autosynchronizacji głównej, aby metoda getMasterSyncAutomatically() zwracała wartość „true”.

7.4.7 Oszczędzanie danych

Jeśli implementacje urządzeń obejmują połączenie z pomiarem, będą to:

  • [SR] Zdecydowanie ZALECANE jest włączenie trybu oszczędzania danych.

Jeśli implementacje urządzeń zapewniają tryb oszczędzania danych:

Jeśli implementacje urządzeń nie obsługują trybu oszczędzania danych:

  • [C-2-1] MUSI zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED dla ConnectivityManager.getRestrictBackgroundStatus()
  • [C-2-2] NIE MOŻE rozgłaszać: ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.
  • [C-2-3] MUSI mieć działanie, które obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻE je wdrożyć jako no-op.

7.5 kamery,

Jeśli implementacje urządzeń obejmują co najmniej jedną kamerę:

  • [C-1-1] MUSI zadeklarować flagę funkcji android.hardware.camera.any.
  • [C-1-2] Aplikacja musi mieć możliwość jednoczesnego przypisania 3 map bitowych RGBA_8888 odpowiadających rozmiarowi obrazu generowanego przez czujnik w aparacie o największej rozdzielczości w urządzeniu, a aparat jest otwarty na potrzeby podstawowego podglądu i rejestrowania.

7.5.1 Kamera tylna

Tylny aparat to kamera znajdująca się z boku urządzenia naprzeciw wyświetlacza. Oznacza to, że obrazuje sceny z daleka, tak jak tradycyjny aparat.

Implementacje na urządzeniach:

  • POWINIEN zawierać tylny aparat.

Jeśli urządzenia mają co najmniej 1 tylny aparat:

  • [C-1-1] MUSI zgłosić flagę funkcji android.hardware.camera i android.hardware.camera.any.
  • [C-1-2] MUSI mieć rozdzielczość co najmniej 2 megapiksele.
  • W sterowniku aparatu musi być zaimplementowany sprzętowy autofokus lub programowy autofokus (przezroczysty dla oprogramowania).
  • MOŻE mieć sprzęt o stałej ostrości lub EDOF (rozszerzona głębia ostrości).
  • MOŻE zawierać obiekty flash.

Jeśli Aparat ma lampę błyskową:

  • [C-2-1] Lampa błyskowa NIE MOŻE się świecić, gdy zostało zarejestrowane wystąpienie android.hardware.Camera.PreviewCallback na platformie podglądu aparatu, chyba że aplikacja wyraźnie włączyła lampę błyskową przez włączenie atrybutu FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu na urządzeniu, a tylko aplikacji innych firm korzystających z Camera.PreviewCallback.

7.5.2 Przedni aparat

Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz. Jest to kamera zwykle używana do nagrywania obrazu użytkownika, na przykład do wideokonferencji i w podobnych aplikacjach.

Implementacje na urządzeniach:

  • MOŻE zawierać przedni aparat

Jeśli implementacje urządzeń obejmują co najmniej jeden przedni aparat:

  • [C-1-1] MUSI zgłosić flagę funkcji android.hardware.camera.any i android.hardware.camera.front.
  • [C-1-2] MUSI mieć rozdzielczość co najmniej VGA (640 x 480 pikseli).
  • [C-1-3] NIE MOŻE używać przedniego aparatu jako domyślnego dla interfejsu Camera API i NIE MOŻE konfigurować interfejsu API w taki sposób, aby traktował przedni aparat jako domyślny tylny aparat, nawet jeśli jest to jedyny aparat w urządzeniu.
  • [C-1-5] Podgląd z kamery MUSI być odbiciem lustrzanym w poziomie względem orientacji określonej przez aplikację, gdy bieżąca aplikacja wprost zażąda obrócenia ekranu kamery przez wywołanie metody android.hardware.Camera.setDisplayOrientation(). I odwrotnie, gdy bieżąca aplikacja nie prosi w sposób jednoznaczny o obrót wyświetlacza kamery przez wywołanie metody android.hardware.Camera.setDisplayOrientation(), podgląd MUSI być wyświetlany wzdłuż domyślnej osi poziomej urządzenia.
  • [C-1-6] NIE MOŻE powielać ostatecznej wersji zarejestrowanych obrazów ani strumieni wideo zwróconych do wywołań zwrotnych aplikacji lub zadeklarowanych do przechowywania multimediów.
  • [C-1-7] MUSI odbić obraz wyświetlany po wyświetleniu w taki sam sposób jak obraz podglądu z aparatu.
  • MOŻE obejmować funkcje (takie jak autofokus, lampa błyskowa itp.) dostępne w przypadku tylnych aparatów zgodnie z opisem w sekcji 7.5.1.

Jeśli implementacje urządzeń mogą podlegać rotacji przez użytkownika (np. automatycznie za pomocą akcelerometru lub ręcznie za pomocą danych wejściowych użytkownika):

  • [C-2-1] Podgląd z aparatu MUSI być odbicie lustrzane w poziomie względem bieżącej orientacji urządzenia.

7.5.3 Kamera zewnętrzna

Implementacje na urządzeniach:

  • MOŻESZ obsługiwać kamerę zewnętrzną, która nie zawsze jest podłączona.

Jeśli implementacje urządzeń obejmują obsługę aparatu zewnętrznego:

  • [C-1-1] MUSI zadeklarować flagę funkcji platformy android.hardware.camera.external i android.hardware camera.any.
  • [C-1-2] MUSI obsługiwać standard wideo USB (UVC 1.0 lub nowszy), jeśli kamera zewnętrzna jest podłączona przez port USB.
  • POWINNA obsługiwać kompresję wideo, taką jak MJPEG, by umożliwić przesyłanie niezakodowanych strumieni o wysokiej jakości (tj. nieprzetworzonych lub niezależnie skompresowanych strumieni obrazu).
  • MOŻE obsługiwać wiele aparatów.
  • MOŻE obsługiwać kodowanie wideo z użyciem kamery. Implementacja urządzenia MUSI mieć dostęp do równocześnie niezakodowanego strumienia MJPEG (o rozdzielczości QVGA lub większej), jeśli ta funkcja jest obsługiwana.

7.5.4 Działanie interfejsu Camera API

Android zawiera 2 pakiety interfejsów API zapewniające dostęp do aparatu. Nowszy interfejs API android.hardware.camera2 zapewnia aplikacji dostęp do aparatu niższego poziomu, w tym wydajne serie bez żadnej kopii i strumieniowanie, które umożliwiają sterowanie ekspozycją, wzmocnieniem, wzmocnieniem bieli, konwertowaniem kolorów, wyciszaniem szumów, wyostrzaniem i nie tylko.

Starszy pakiet interfejsu API (android.hardware.Camera) jest oznaczony jako wycofany w Androidzie 5.0, ale nadal powinien być dostępny dla aplikacji. Implementacje na urządzeniach z Androidem MUSZĄ zapewnić nieprzerwaną obsługę interfejsu API zgodnie z opisem w tej sekcji oraz w pakiecie SDK na Androida.

Implementacje urządzeń MUSZĄ implementować poniższe sposoby działania w przypadku interfejsów API związanych z aparatem w przypadku wszystkich dostępnych kamer. Implementacje na urządzeniach:

  • [C-0-1] MUSI używać android.hardware.PixelFormat.YCbCr_420_SP do obsługi danych podglądu przekazywanych do wywołań zwrotnych aplikacji, gdy aplikacja nigdy nie wywołała android.hardware.Camera.Parameters.setPreviewFormat(int).
  • [C-0-2] MUSI dodatkowo mieć format kodowania NV21, gdy aplikacja rejestruje wystąpienie android.hardware.Camera.PreviewCallback, a system wywołuje metodę onPreviewFrame(), a format podglądu to YCbCr_420_SP, czyli dane w bajcie[] przekazywane do onPreviewFrame(). Oznacza to, że NV21 MUSI być wartością domyślną.
  • [C-0-3] MUSI obsługiwać format YV12 (oznaczony stałą wartością android.graphics.ImageFormat.YV12) w przypadku podglądu zarówno przedniego, jak i tylnego aparatu dla android.hardware.Camera. (Sprzętowy koder wideo i kamera mogą używać dowolnego natywnego formatu piksela, ale implementacja urządzenia MUSI obsługiwać konwersję na format YV12).
  • [C-0-4] MUSI obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe przez interfejs API android.media.ImageReader w przypadku urządzeń android.hardware.camera2, które reklamują funkcję REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE w android.request.availableCapabilities.
  • [C-0-5] Nadal musisz wdrożyć pełny interfejs Camera API podany w dokumentacji pakietu Android SDK, niezależnie od tego, czy urządzenie jest wyposażone w sprzętowy autofokus czy inne funkcje. Na przykład aparaty bez autofokusa MUSZĄ wywoływać dowolne zarejestrowane wystąpienia android.hardware.Camera.AutoFocusCallback (mimo że nie ma to związku z aparatem bez autofokusa). Pamiętaj, że dotyczy to przednich aparatów. Na przykład większość z nich nie obsługuje autofokusa, ale wywołania zwrotne interfejsu API muszą być „sfałszowane” zgodnie z opisem.
  • [C-0-6] MUSI rozpoznawać i przestrzegać wszystkich nazw parametrów zdefiniowanych jako stała w klasie android.hardware.Camera.Parameters. I odwrotnie, implementacje urządzeń NIE MOGĄ uznawać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters() innych niż te, które są wymienione jako stałe w zasadzie android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry aparatu (o ile sprzęt na to pozwala) i NIE MOŻE obsługiwać niestandardowych typów parametrów aparatu. Na przykład implementacje urządzeń, które obsługują robienie zdjęć z użyciem technik obrazowania High Dynamic Range (HDR), MUSZĄ obsługiwać parametr Camera.SCENE_MODE_HDR aparatu.
  • [C-0-7] MUSI zgłosić odpowiedni poziom pomocy przy użyciu właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i zgłaszać odpowiednie flagi funkcji platformy.
  • [C-0-8] MUSI także zadeklarować możliwości poszczególnych kamer android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i zadeklarować odpowiednie flagi funkcji. MUSI zdefiniować flagę funkcji, jeśli któreś z podłączonych do niej kamer ją obsługuje.
  • [C-0-9] MUSI transmitować intencję Camera.ACTION_NEW_PICTURE za każdym razem, gdy aparat zrobi nowe zdjęcie i zostanie dodane do sklepu multimedialnego.
  • [C-0-10] MUSI transmitować intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy kamera zarejestruje nowy film i dodasz obraz do sklepu multimedialnego.

7.5.5 Orientacja aparatu

Jeśli urządzenia mają aparat przedni lub tylny:

  • [C-1-1] MUSI być zorientowana tak, by długi wymiar kamery był zgodny z długością ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparaty MUSZĄ robić zdjęcia w orientacji poziomej. Dotyczy to niezależnie od naturalnej orientacji urządzenia, czyli zarówno orientacji poziomej, jak i pionowej.

7.6 Pamięć i miejsce na dane

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

Implementacje na urządzeniach:

  • [C-0-1] MUSI zawierać menedżera pobierania, z którego aplikacje MOGĄ pobierać pliki danych. MUSZĄ one pobierać pojedyncze pliki o rozmiarze co najmniej 100 MB do domyślnej lokalizacji w „pamięci podręcznej”.

7.6.2 Pamięć współdzielona aplikacji

Implementacje na urządzeniach:

  • [C-0-1] MUSI oferować pamięć współdzieloną przez aplikacje, często nazywana też „wspólną pamięcią zewnętrzną”, „pamięcią współdzieloną aplikacji” lub ścieżką systemu Linux „/sdcard”, w której jest podłączona.
  • [C-0-2] MUSI być skonfigurowana z pamięcią współdzieloną domyślnie instalowaną, czyli bez względu na to, czy pamięć jest umieszczona w pamięci wewnętrznej czy na nośniku wymiennym (np. w gniazdku kart Secure Digital).
  • [C-0-3] MUSI podłączyć pamięć współdzieloną aplikacji bezpośrednio w ścieżce Linuksa sdcard lub dołączyć łącze symboliczne Linuksa z sdcard do rzeczywistego punktu podłączania.
  • [C-0-4] MUSI wymuszać uprawnienie android.permission.WRITE_EXTERNAL_STORAGE w tej pamięci współdzielonej zgodnie z dokumentacją w pakiecie SDK. W przeciwnym razie każda aplikacja uzyskująca to uprawnienie MUSI umożliwia zapis.

Implementacje na urządzeniach MOGĄ spełniać powyższe wymagania, jeśli:

  • pamięci wymiennej dostępnej dla użytkowników, takiej jak gniazdo kart Secure Digital (SD).
  • część pamięci wewnętrznej (niewymiennej) zgodnie z implementacją w ramach projektu Android Open Source Project (AOSP).

Jeśli implementacje urządzeń korzystają z pamięci wymiennej, aby spełnić powyższe wymagania:

  • [C-1-1] MUSI zaimplementować tost lub wyskakujące okienko z ostrzeżeniem dla użytkownika, gdy w gnieździe nie ma nośnika pamięci.
  • [C-1-2] MUSI zawierać nośnik pamięci w formacie FAT (np. kartę SD) lub widoczne na pudełku i inne materiały dostępne w momencie zakupu, że taki nośnik trzeba zakupić oddzielnie.

Jeśli implementacje urządzeń korzystają z pamięci niewymiennej, aby spełnić powyższe wymagania:

  • NALEŻY użyć implementacji AOSP pamięci współdzielonej aplikacji wewnętrznej.
  • MOGĄ dzielić dostępne miejsce z prywatnymi danymi aplikacji.

Jeśli implementacje urządzeń obejmują wiele ścieżek pamięci współdzielonej (np. gniazdo kart SD i wspólną pamięć wewnętrzną), działają one:

  • [C-3-1] MUSI zezwalać na zapis w dodatkowej pamięci zewnętrznej tylko wstępnie zainstalowanym i uprawnionym aplikacjom na Androida, które mają uprawnienia WRITE_EXTERNAL_STORAGE, z wyjątkiem zapisów w katalogach związanych z odpowiednimi pakietami lub w plikach URI zwróconych przez uruchomienie intencji ACTION_OPEN_DOCUMENT_TREE.

Jeśli urządzenia są wyposażone w port USB z obsługą trybu urządzenia peryferyjnego USB:

  • [C-3-1] MUSI udostępniać mechanizm uzyskiwania dostępu do danych w pamięci współdzielonej aplikacji z komputera hosta.
  • Treści z obu ścieżek pamięci NALEŻY w przejrzysty sposób udostępniać za pomocą usługi skanera multimediów na Androidzie i usługi android.provider.MediaStore.
  • MOŻNA korzystać z pamięci masowej USB, ale spełnienie tego wymagania POWINIEN korzystać z protokołu Media Transfer Protocol.

Jeśli urządzenia są wyposażone w port USB z trybem urządzenia peryferyjnego USB i obsługują protokół Media Transfer Protocol, umożliwiają one:

  • POWINNA być zgodna z referencyjnym hostem MTP Androida i Android File Transfer.
  • MUSISZ zgłosić klasę urządzenia USB 0x00.
  • POWINIEN zgłosić nazwę interfejsu USB „MTP”.

7.6.3 Pamięć elastyczna

Jeśli oczekuje się, że urządzenie ma charakter mobilny (inaczej niż w przypadku telewizora), implementacje urządzeń są:

  • [SR] Zdecydowanie ZALECANE jest wdrożenie pamięci adaptacyjnej w stabilnej lokalizacji długoterminowej, ponieważ przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

Jeśli wyjmowany port urządzenia pamięci masowej znajduje się w stabilnej lokalizacji długoterminowej, na przykład w komorze na baterię lub w innej osłonie ochronnej, sposób działania urządzenia:

7.7. USB

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

  • POWINNA obsługiwać tryb urządzenia peryferyjnego USB i POWINNO obsługiwać tryb hosta USB.

7.7.1. Tryb urządzenia peryferyjnego USB

Jeśli używane urządzenia są wyposażone w port USB obsługujący tryb peryferyjny:

  • [C-1-1] Port MUSI być podłączony do hosta USB ze standardowym portem USB typu A lub C.
  • [C-1-2] MUSI zgłosić prawidłową wartość iSerialNumber w standardowym deskrypcie urządzenia USB do android.os.Build.SERIAL.
  • [C-1-3] MUSI wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem oporu typu C i MUSZĄ wykrywać zmiany w reklamach, jeśli obsługują USB typu C.
  • [SR] Port powinien używać formatu micro-B, micro-AB lub USB typu C. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
  • [SR] Port powinien znajdować się u dołu urządzenia (zgodnie z naturalną orientacją) lub umożliwiać programowe obracanie ekranu we wszystkich aplikacjach (w tym na ekranie głównym), by ekran był prawidłowo wyświetlany, gdy urządzenie jest zorientowane na port u dołu. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
  • [SR] POWINNO obsługiwać pobieranie prądu na poziomie 1,5 A podczas sygnału HS i ruchu zgodnie z opisem w specyfikacji ładowania baterii przez USB, wersja 1.2. ZALECANE JEST spełnienie tych wymagań i dotychczasowych urządzeń z Androidem, dzięki czemu będą one mogły zostać uaktualnione do przyszłych wersji platformy.
  • [SR] Zdecydowanie ZALECAM, aby nie obsługiwać zastrzeżonych metod ładowania, które zmieniają napięcie Vbus do wartości domyślnych lub zmieniają role zlewu/źródła, co może powodować problemy ze współdziałaniem z ładowarkami lub urządzeniami, które obsługują standardowe metody przesyłania przez USB Power Delivery. Choć ta funkcja nazywa się „Zdecydowanie ZALECANE”, w przyszłych wersjach Androida możemy WYMAGAĆ WYMAGANIE obsługi wszystkich urządzeń typu C w celu pełnej interoperacyjności ze standardowymi ładowarkami typu C.
  • [SR] ZDECYDOWANIE ZALECANE jest w przypadku obsługi funkcji Power Delivery w przypadku wymiany ról danych i zasilania, jeśli obsługuje ona tryb hosta USB typu C i USB.
  • POWINNA obsługiwać technologię Power Delivery w przypadku ładowania wysokiego napięcia oraz obsługa trybów alternatywnych, takich jak wyświetlacz na zewnątrz.
  • NALEŻY zaimplementować interfejs API i specyfikację Android Open Accessory (AOA) w sposób opisany w dokumentacji pakietu Android SDK.

Jeśli urządzenia są wyposażone w port USB, zaimplementuj specyfikację AOA:

  • [C-2-1] MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.accessory.
  • [C-2-2] Klasa pamięci masowej USB MUSI zawierać ciąg „android” na końcu opisu interfejsu iInterface pamięci masowej USB

7.7.2 Tryb hosta USB

Jeśli implementacje urządzeń są wyposażone w port USB obsługujący tryb hosta:

  • [C-1-1] MUSI zaimplementować interfejs Android USB Host API w sposób opisany w pakiecie Android SDK i MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.host.
  • [C-1-2] MUSI zapewnić obsługę podłączania standardowych urządzeń peryferyjnych USB. Oznacza to, że MUSI:
    • urządzenie musi mieć port USB typu C lub musi być wyposażony w kable umożliwiające podłączenie zastrzeżonego portu urządzenia do standardowego portu USB typu C (urządzenie z USB typu C).
    • urządzenie musi być wyposażone w urządzenie typu A lub użyć kabli podłączających zastrzeżony port urządzenia do standardowego portu USB typu A.
    • Musisz mieć na urządzeniu port micro-AB, który POWINNY być w dostarczeniu z kablem pasującym do standardowego portu typu A.
  • [C-1-3] NIE MOŻE być dostarczany z przejściówką konwertowaną z portów USB typu A lub micro-AB na porty typu C (gniazdo).
  • [SR] ZALECANE JEST wdrożenie klasy audio USB w sposób opisany w dokumentacji pakietu Android SDK.
  • POWINNY jest obsługiwać ładowanie podłączonego urządzenia peryferyjnego USB w trybie hosta; reklamowanie źródła zasilania o natężeniu co najmniej 1, 5 A (zgodnie z opisem w sekcji Parametry zakończenia działania w wersji 1.2 specyfikacji kabla USB typu C i złącza w przypadku złączy USB typu C) lub używanie złącza ładowania USB typu C w zakresie natężenia prądu wyjściowego (CDP)
  • KONIECZNIE jest wdrożenie i obsługa standardów USB typu C.

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i klasę audio USB, te funkcje:

  • [C-2-1] MUSI obsługiwać klasę USB HID
  • [C-2-2] MUSI obsługiwać wykrywanie i mapowanie tych pól danych HID określonych w tabelach wykorzystania USB HID i Żądanie użycia Voice Command na stałe KeyEvent jak poniżej:
    • Identyfikator wykorzystania strony użycia (0xC) (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
    • Identyfikator wykorzystania strony wykorzystania (0xC) (0x0E9): KEYCODE_VOLUME_UP
    • Identyfikator wykorzystania strony wykorzystania (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
    • Identyfikator wykorzystania strony użycia (0xC) (0x0CF): KEYCODE_VOICE_ASSIST

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i platformę Storage Access Framework (SAF), funkcje te:

  • [C-3-1] MUSI rozpoznawać zdalnie połączone urządzenia MTP (Media Transfer Protocol) i udostępniać ich treści za pomocą intencji ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT. .

Jeśli implementacje urządzeń obejmują port USB obsługujący tryb hosta i USB typu C:

  • [C-4-1] MUSI zaimplementować funkcję Dual Role Port zgodnie z definicją w specyfikacji USB typu C (sekcja 4.5.1.3.3).
  • [SR] Zdecydowanie ZALECANE jest korzystanie z portu DisplayPort, obsługa technologii USB SuperSzybkości transmisji danych. Zdecydowanie ZALECANE jest obsługa usługi Power Delivery w celu wymiany ról związanych z danymi i zasilaniem.
  • [SR] Zdecydowanie ZALECAM, aby NIE obsługiwać trybu akcesorium adaptera audio zgodnie z dodatkiem A do wersji 1.2 dotyczących kabla USB typu C i złącza.
  • NALEŻY zastosować model Try.*, który najlepiej pasuje do formatu urządzenia. Na przykład urządzenie przenośne POWINNO obsługiwać model Try.SNK.

7.8 Dźwięk

7.8.1 Mikrofon

Jeśli implementacje urządzeń zawierają mikrofon:

  • [C-1-1] MUSI zgłaszać stałą funkcję android.hardware.microphone.
  • [C-1-2] MUSI spełniać wymagania dotyczące nagrywania dźwięku opisane w sekcji 5.4.
  • [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku opisane w sekcji 5.6.
  • [SR] Zdecydowanie ZALECANE jest korzystanie z nagrywania bliskiego ultradźwięków, zgodnie z opisem w sekcji 7.8.3.

Jeśli implementacje urządzenia pomijają mikrofon:

  • [C-2-1] NIE MOŻE zgłaszać stałej funkcji android.hardware.microphone.
  • [C-2-2] MUSI wdrożyć interfejs API do nagrywania dźwięku co najmniej w trybie bezobsługowym, zgodnie z sekcją 7.

7.8.2 Wyjście audio

Jeśli używane urządzenia są wyposażone w głośnik lub port wyjściowy audio/multimedialny dla urządzenia peryferyjnego audio, takiego jak 4-kanałowe gniazdo słuchawek 3,5 mm lub port w trybie hosta USB klasa audio USB, to umożliwiają:

  • [C-1-1] MUSI zgłaszać stałą funkcję android.hardware.audio.output.
  • [C-1-2] MUSI spełniać wymagania dotyczące odtwarzania dźwięku opisane w sekcji 5.5.
  • [C-1-3] MUSI spełniać wymagania dotyczące opóźnienia dźwięku opisane w sekcji 5.6.
  • [SR] Zdecydowanie ZALECANE jest umożliwienie odtwarzania w trybie zbliżonym do ultradźwięków, zgodnie z opisem w sekcji 7.8.3.

Jeśli urządzenia nie mają gniazda głośnika ani wyjścia audio:

  • [C-2-1] NIE MOŻE zgłaszać funkcji android.hardware.audio.output.
  • [C-2-2] MUSI wdrożyć interfejsy API związane z wyjściem audio przynajmniej w trybie bezobsługowym.

Na potrzeby tej sekcji „port wyjściowy” to fizyczny interfejs, taki jak gniazdo słuchawek 3, 5 mm, port HDMI lub port trybu hosta USB z klasą audio USB. Obsługa wyjścia audio przez protokoły radiowe, takie jak Bluetooth, Wi-Fi czy sieć komórkowa, nie kwalifikuje się jako uwzględnienie „portu wyjściowego”.

7.8.2.1 Analogowe porty audio

Aby urządzenie było zgodne z zestawami słuchawkowymi i innymi akcesoriami audio z wtyczką audio 3,5 mm w całym ekosystemie Androida, jeśli używane urządzenie obejmuje co najmniej 1 analogowy port audio, co najmniej 1 z tych portów POWINIEN być 4-kanałowym gniazdem słuchawek 3,5 mm.

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

  • [C-1-1] MUSI obsługiwać odtwarzanie dźwięku w słuchawkach stereo i stereofonicznych zestawach słuchawkowych z mikrofonem.
  • [C-1-2] MUSI obsługiwać wtyczki audio TRRS w kolejności styków CTIA.
  • [C-1-3] MUSI obsługiwać wykrywanie kodów kluczy i mapowanie ich na 3 zakresy równoważnej impedancji między mikrofonem a przewodami uziemiającymi we wtyczce audio:
    • Maks. 70 omów: KEYCODE_HEADSETHOOK
    • 210–290 omów: KEYCODE_VOLUME_UP
    • 360–680 omów: KEYCODE_VOLUME_DOWN
  • [C-1-4] MUSI uruchamiać ACTION_HEADSET_PLUG po podłączeniu wtyczki, ale dopiero wtedy, gdy wszystkie kontakty podłączone do wtyczki dotykają odpowiednich segmentów gniazda.
  • [C-1-5] MUSI NAPRAWDZAĆ co najmniej 150 mV ± 10% napięcia wyjściowego na głośniku o impedancji 32 om.
  • [C-1-6] MUSI mieć napięcie odchylenia mikrofonu w zakresie 1,8 V ~ 2,9 V.
  • [SR] Zdecydowanie ZALECANE jest wykrywanie i zmapowanie do kodu klucza dla poniższego zakresu równoważnej impedancji między mikrofonem a przewodami uziemiającymi we wtyczce audio:
    • 110–180 omów: KEYCODE_VOICE_ASSIST
  • POWINNA obsługiwać wtyczki audio zgodnie z kolejnością pinów OMTP.
  • POWINNA obsługiwać nagrywanie dźwięku ze stereofonicznego zestawu słuchawkowego z mikrofonem.

Jeśli urządzenia są wyposażone w 4-kanałowe gniazdo słuchawek 3,5 mm i obsługują mikrofon oraz transmitują android.intent.action.HEADSET_PLUG z mikrofonem o dodatkowej wartości ustawionej na 1:

  • [C-2-1] MUSI obsługiwać wykrywanie mikrofonu na podłączonych akcesorium audio.

7.8.3 Prawie ultradźwiękowy

Dźwięk Near ultradźwiękowy to pasmo 18,5–20 kHz.

Implementacje na urządzeniach:

  • MUSI prawidłowo zgłaszać obsługę funkcji audio bliskich ultradźwięków za pomocą interfejsu API AudioManager.getproperty w ten sposób:

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

  • [C-1-1] Średnia moc mikrofonu mikrofonu w paśmie 18,5–20 kHz MUSI być niższa niż 15 dB poniżej odpowiedzi przy 2 kHz.
  • [C-1-2] Stosunek nieważonego sygnału do szumu mikrofonu powyżej 18,5–20 kHz dla tonu 19 kHz przy -26 dBFS MUSI być nie mniejszy niż 50 dB.

Jeśli PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „true” (prawda):

  • [C-2-1] Średnia odpowiedź głośnika w zakresie 18,5 kHz – 20 kHz MUSI być niższa niż 40 dB poniżej odpowiedzi przy 2 kHz.

7.9. Wirtualna rzeczywistość

Android zapewnia interfejsy API i infrastrukturę do tworzenia aplikacji do rzeczywistości wirtualnej (VR), takich jak wysokiej jakości rzeczywistość wirtualna na urządzeniach mobilnych. Implementacje na urządzeniach MUSZĄ poprawnie implementować te interfejsy API i zachowania, zgodnie z opisem w tej sekcji.

7.9.1. Tryb rzeczywistości wirtualnej

Android zapewnia obsługę trybu VR – funkcji, która obsługuje stereoskopowe renderowanie powiadomień i wyłącza komponenty interfejsu monokularowego systemu, gdy aplikacja VR skupia się na użytkowniku.

7.9.2. Rzeczywistość wirtualna o wysokiej wydajności

Jeśli implementacje urządzeń sygnalizują obsługę wysokiej wydajności VR przez dłuższy czas za pomocą flagi funkcji android.hardware.vr.high_performance:

  • [C-1-1] MUSI mieć co najmniej 2 rdzenie fizyczne.
  • [C-1-2] MUSI zadeklarować android.software.vr.mode feature.
  • [C-1-3] MUSI obsługiwać tryb utrzymującej wydajność.
  • [C-1-4] MUSI obsługiwać standard OpenGL ES 3.2.
  • [C-1-5] MUSI obsługiwać sprzęt Vulkan na poziomie 0, MUSI obsługiwać sprzęt Vulkan na poziomie 1.
  • [C-1-6] MUSI zaimplementować EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content oraz udostępnić rozszerzenia na liście dostępnych rozszerzeń EGL.
  • [C-1-7] GPU i wyświetlacz MUSZĄ synchronizować dostęp do wspólnego przedniego bufora, tak aby treści VR z prędkością 60 kl./s były wyświetlane z użyciem naprzemiennego renderowania treści VR z 2 kontekstami renderowania bez widocznych zakłóceń.
  • [C-1-8] MUSI zaimplementować GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures, GL_EXT_EGL_image_array, GL_EXT_external_buffer oraz udostępnić rozszerzenia na liście dostępnych rozszerzeń GL.
  • [C-1-9] MUSI 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] MUSI zaimplementować obsługę AHardwareBuffers z więcej niż jedną warstwą.
  • [C-1-11] MUSI obsługiwać dekodowanie H.264 z szybkością co najmniej 3840 x 2160 przy 30 kl./s do 40 Mb/s (odpowiednik 4 instancji 1920 x 1080 przy 30 kl./s-10 Mb/s lub 2 instancji 1920 x 1080 przy 60 kl./s–20 Mb/s).
  • [C-1-12] MUSI obsługiwać HEVC i VP9; MUSI być w stanie dekodować z szybkością co najmniej 1920 x 1080 przy 30 kl./s-10 Mb/s oraz dekodować 3840 x 2160 przy 30 kl./s–20 Mb/s (odpowiednik 4 instancji 1920 kl./s do 1920 Mb/s).
  • [C-1-13] MUSI obsługiwać interfejs HardwarePropertiesManager.getDeviceTemperatures API i zwracać dokładne wartości temperatury skóry.
  • [C-1-14] MUSI mieć wbudowany ekran, a jego rozdzielczość MUSI być co najmniej równa FullHD(1080p) i ZALECNIE ZALECANEJ WARTOŚCI QuadHD (1440p) lub wyższej.
  • [C-1-15] Wyświetlacz MUSI aktualizować się z częstotliwością co najmniej 60 Hz w trybie VR.
  • [C-1-16] Opóźnienie wyświetlania (mierzone w przypadku kolorów szarości i szarości, bieli na czerń i czerni na biel) MUSI wynosić ≤ 6 milisekund.
  • [C-1-17] Wyświetlacz MUSI obsługiwać tryb o małej trwałości o czasie trwania wynoszącym ≤ 5 milisekund, przy czym trwałość jest definiowana jako czas, przez jaki piksel emituje światło.
  • [C-1-18] MUSI obsługiwać Bluetooth 4.2 oraz Bluetooth LE Data Length Data Extension w sekcji 7.4.3.
  • [C-1-19] MUSI obsługiwać i prawidłowo zgłaszać typ kanału bezpośredniego w przypadku wszystkich tych domyślnych typów czujników:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-1-20] MUSI obsługiwać typ kanału bezpośredniego TYPE_HARDWARE_BUFFER w przypadku wszystkich typów kanałów bezpośrednich wymienionych powyżej.
  • [SR] Zdecydowanie ZALECANE jest działanie funkcji android.hardware.sensor.hifi_sensors. MUSZĄ spełniać wymagania dotyczące żyroskopu, akcelerometru i magnetometru dla urządzenia android.hardware.hifi_sensors.
  • MOGĄ udostępniać wyłączne rdzeń aplikacji na pierwszym planie i obsługiwać interfejs API Process.getExclusiveCores w celu zwrócenia liczby rdzeni procesora używanych wyłącznie dla aplikacji na pierwszym planie. Jeśli obsługiwany jest rdzeń na wyłączność, rdzeń NIE MOŻE zezwalać na uruchamianie w niej żadnych innych procesów w przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE zezwolić na uruchamianie niektórych procesów jądra w razie potrzeby.

8. Wydajność i moc

Niektóre kryteria dotyczące minimalnej wydajności i mocy mają kluczowe znaczenie dla wygody użytkowników i wpływają na podstawowe założenia, jakie deweloperzy powinni mieć przy tworzeniu aplikacji.

8.1. Spójność wrażeń użytkownika

Użytkownik może spełnić pewne wymagania minimalne, jeśli chodzi o stały czas reakcji i liczby klatek w aplikacjach i grach. W ten sposób można zapewnić użytkownikom płynny interfejs. Implementacje urządzeń, w zależności od typu urządzenia, MOGĄ wiązać się z wymiernymi wymaganiami dotyczącymi czasu oczekiwania w interfejsie i przełączania zadań. Opisaliśmy to w sekcji 2.

8.2. Skuteczność dostępu do plików

Określenie wspólnej wartości bazowej dla stałej wydajności dostępu do plików w prywatnym miejscu na dane aplikacji (partycja /data) umożliwia deweloperom aplikacji odpowiednie oczekiwania, które ułatwią projektowanie oprogramowania. Implementacje urządzeń, w zależności od typu urządzenia, MOGĄ BYĆ określone wymagania opisane w sekcji 2 dotyczące następujących operacji odczytu i zapisu:

  • Wydajność sekwencyjnego zapisu. Pomiar ten polega na zapisaniu pliku o rozmiarze 256 MB w buforze zapisu o wielkości 10 MB.
  • Losowa wydajność zapisu. Pomiar ten polega na zapisaniu pliku o wielkości 256 MB z użyciem bufora zapisu o wielkości 4 KB.
  • Wydajność sekwencyjnego odczytu. Pomiar dokonywany jest przez odczytanie pliku o wielkości 256 MB z użyciem bufora zapisu o wielkości 10 MB.
  • Losowa wydajność odczytu. Pomiar dokonywany jest przez odczytanie pliku o wielkości 256 MB z użyciem bufora zapisu o wielkości 4 KB.

8.3. Tryby oszczędzania energii

Android obejmuje tryby czuwania aplikacji i uśpienia, które pozwalają zoptymalizować wykorzystanie baterii. [SR] ZDECYDOWANIE, aby wszystkie aplikacje zwolnione z tych trybów były widoczne dla użytkowników. [SR] Zdecydowanie NIE ZALECAMY stosowania algorytmów wyzwalających, konserwacji, wybudzania i używania globalnych ustawień systemu w tych trybach oszczędzania energii, aby NIE odbiegać od projektu Android Open Source Project.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ wdrożyć dowolny lub wszystkie 4 stany zasilania w trybie uśpienia zdefiniowany w dokumencie Advanced Configuration and Power Interface (ACPI).

Jeśli implementacje urządzeń stosują stany zasilania S3 i S4 określone w ACPI:

  • [C-1-1] NALEŻY wprowadzać te stany tylko przy zamykaniu pokrywy, która jest fizycznie częścią urządzenia.

8.4. Rachunkowanie zużycia energii

Dokładniejsze liczenie i raportowanie zużycia energii zapewnia deweloperom aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorca wykorzystania energii przez aplikację.

Implementacje na urządzeniach:

  • [SR] ZALECANE jest podanie profilu zasilania dla poszczególnych komponentów, który określa wartość bieżącego zużycia energii przez poszczególne komponenty sprzętowe oraz przybliżone zużycie baterii przez komponenty w danym okresie, zgodnie z dokumentem w witrynie Android Open Source Project.
  • [SR] Zdecydowanie ZALECANE jest raportowanie wszystkich wartości zużycia energii w miliiamperach godzin (mAh).
  • [SR] Zdecydowanie ZALECANE jest raportowanie zużycia energii przez procesor według identyfikatora UID każdego procesu. Projekt Android Open Source Project spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
  • [SR] Zdecydowanie ZALECANE jest udostępnienie tej informacji deweloperowi aplikacji za pomocą polecenia powłoki adb shell dumpsys batterystats.
  • MUSI być przypisana do samego komponentu sprzętowego, jeśli nie można przypisać do aplikacji zużycia energii przez komponent sprzętowy.

8.5. Stała skuteczność

W przypadku długotrwałych aplikacji o wysokiej wydajności wydajność może się znacznie wahać ze względu na inne aplikacje działające w tle lub ograniczenie procesora z powodu limitów temperatury. Android ma interfejsy automatyczne, dzięki czemu, gdy urządzenie ma odpowiednie możliwości, główna aplikacja na pierwszym planie może zażądać, aby system zoptymalizował przydział zasobów, aby uwzględnić takie wahania.

Implementacje na urządzeniach:

Jeśli implementacje urządzeń zgłaszają obsługę trybu trwałej wydajności:

  • [C-1-1] MUSI zapewniać aplikacji znajdującej się na pierwszym planie stały poziom wydajności przez co najmniej 30 minut, gdy aplikacja o to poprosi.
  • [C-1-2] MUSI spełniać warunki interfejsu API Window.setSustainedPerformanceMode() i innych powiązanych interfejsów API.

Jeśli implementacje urządzeń obejmują co najmniej 2 rdzenie procesora, są to:

  • POWINIEN podać co najmniej 1 rdzeń wyłączny, który może być zarezerwowany przez aplikację znajdującą się na pierwszym planie.

Jeśli implementacje urządzeń obsługują rezerwowanie 1 wyłącznego rdzenia dla aplikacji najwyższego poziomu:

  • [C-2-1] MUSI raportować za pomocą metody API Process.getExclusiveCores() numery identyfikacyjne wyłącznych rdzeni, które mogą zostać zarezerwowane przez aplikację główną na pierwszym planie.
  • [C-2-2] NIE MOŻE zezwalać na uruchamianie żadnych procesów w przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację na uruchamianie wyłącznych rdzeni, ale MOŻE zezwalać na uruchamianie niektórych procesów jądra systemu, jeśli jest to konieczne.

Jeśli implementacje urządzeń nie obsługują rdzeni na wyłączność, są to:

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniach:

  • [C-0-1] MUSI wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, zgodnie z definicją podaną w dokumentacji dotyczącej zabezpieczeń i uprawnień w interfejsach API w dokumentacji dla programistów aplikacji na Androida.

  • [C-0-2] MUSI obsługiwać samodzielnie podpisane aplikacje bez konieczności uzyskania dodatkowych pozwoleń/certyfikatów od osób trzecich/urzędów. Zgodne urządzenia MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w tych podpunktach.

9.1. Uprawnienia

Implementacje na urządzeniach:

  • [C-0-1] MUSI obsługiwać model uprawnień Androida zdefiniowany w dokumentacji dla deweloperów aplikacji na Androida. W szczególności MUSZĄ wymuszać wszystkie uprawnienia zdefiniowane w sposób opisany w dokumentacji pakietu SDK. Żadne uprawnienia nie mogą zostać pominięte, zmienione ani ignorowane.

  • MOŻE dodać więcej uprawnień, pod warunkiem że ciągi identyfikatorów nowych uprawnień nie znajdują się w przestrzeni nazw android.\*.

  • [C-0-2] Uprawnienia z wartością protectionLevel PROTECTION_FLAG_PRIVILEGED MUSZĄ być przyznawane tylko aplikacjom wstępnie wczytanym na ścieżce z podwyższonymi uprawnieniami w obrazie systemu i będącym częścią podzbioru uprawnień bezpośrednio na liście dozwolonych dla poszczególnych aplikacji. Implementacja AOSP spełnia to wymaganie, odczytując i przestrzegając uprawnień dozwolonych poszczególnych aplikacji z plików na ścieżce etc/permissions/ i używając ścieżki system/priv-app jako ścieżki uprzywilejowanej.

Uprawnienia z poziomem ochrony „Niebezpieczne” to uprawnienia w czasie działania. Aplikacje, które mają targetSdkVersion > 22, wysyłają żądania w czasie działania.

Implementacje na urządzeniach:

  • [C-0-3] MUSI wyświetlić specjalny interfejs, w którym użytkownik może zdecydować, czy przyznać wymagane uprawnienia w czasie działania, oraz udostępnić interfejs do zarządzania uprawnieniami w czasie działania.
  • [C-0-4] MUSI mieć tylko jedną implementację obu interfejsów użytkownika.
  • [C-0-5] NIE MOŻE przyznawać żadnych uprawnień w czasie działania zainstalowanym wstępnie aplikacjom, chyba że:
  • zgody użytkownika można uzyskać przed użyciem jej przez aplikację.
  • uprawnienia w czasie działania są powiązane ze wzorcem intencji, dla którego wstępnie zainstalowana aplikacja jest ustawiona jako domyślny moduł obsługi.

Jeśli implementacje na urządzeniu obejmują wstępnie zainstalowaną aplikację lub chcesz umożliwić aplikacjom innych firm dostęp do statystyk użytkowania:

  • [C-1-1] Zdecydowanie zalecamy, aby zapewnić dostępny dla użytkownika mechanizm przyznawania i unieważniania dostępu do statystyk użytkowania w odpowiedzi na intencję android.settings.ACTION_USAGE_ACCESS_SETTINGS w przypadku aplikacji, które deklarują uprawnienia android.permission.PACKAGE_USAGE_STATS.

Jeśli implementacje urządzenia uniemożliwią dostęp do statystyk użytkowania aplikacjom, w tym także fabrycznie zainstalowanym użytkownikom,:

  • [C-2-1] MUSI nadal mieć działanie obsługujące wzorzec intencji android.settings.ACTION_USAGE_ACCESS_SETTINGS, ale MUSI go zaimplementować w trybie no-op, aby działał podobnie jak w przypadku odrzucenia prośby o dostęp.

9.2. UID i izolacja procesów

Implementacje na urządzeniach:

  • [C-0-1] MUSI obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja działa jako unikalny identyfikator UID systemu Unixstyle i w osobnym procesie.
  • [C-0-2] MUSI obsługiwać wiele aplikacji z tym samym identyfikatorem użytkownika Linuksa, o ile są one prawidłowo podpisane i skonstruowane, zgodnie z opisem w dokumentacji zabezpieczeń i uprawnień.

9.3. Uprawnienia systemu plików

Implementacje na urządzeniach:

9.4. Alternatywne środowiska wykonawcze

Implementacje na urządzeniach MUSZĄ zachowywać spójność z modelem zabezpieczeń i uprawnień Androida, nawet jeśli obejmują środowiska wykonawcze, w których są wykonywane aplikacje korzystające z innego oprogramowania lub technologii niż format wykonywalny Dalvik lub kod natywny. Krótko mówiąc:

  • [C-0-1] Alternatywne środowiska wykonawcze MUSZĄ być aplikacjami na Androida i być zgodne ze standardowym modelem zabezpieczeń Androida opisanym w sekcji sekcja 9.

  • [C-0-2] Alternatywne środowiska wykonawcze NIE MOGĄ mieć dostępu do zasobów chronionych przez uprawnienia, które nie są wymagane w pliku AndroidManifest.xml środowiska wykonawczego za pomocą mechanizmu <uses-permission>.

  • [C-0-3] Alternatywne środowiska wykonawcze NIE MOGĄ zezwalać aplikacjom na korzystanie z funkcji chronionych uprawnieniami Androida ograniczonych do aplikacji systemowych.

  • [C-0-4] Alternatywne środowiska wykonawcze MUSZĄ być zgodne z modelem piaskownicy Androida, a zainstalowane aplikacje korzystające z alternatywnego środowiska NIE MOGĄ wykorzystywać środowiska piaskownicy dla żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida korzystających ze wspólnego identyfikatora użytkownika i certyfikatu podpisywania.

  • [C-0-5] Alternatywne środowiska wykonawcze NIE MOGĄ uruchamiać się w środowiskach piaskownicy odpowiadających innym aplikacjom na Androida, przyznawać do nich dostępu ani przyznawać im do nich dostępu.

  • [C-0-6] Alternatywnego środowiska wykonawczego NIE MOŻNA uruchamiać razem z innymi aplikacjami ani przyznawać im żadnych uprawnień superużytkownika (roota) ani żadnego innego identyfikatora użytkownika.

  • [C-0-7] Jeśli plik .apk alternatywnych środowisk wykonawczych znajduje się w obrazie systemowym implementacji urządzenia, MUSI być podpisany kluczem innym niż klucz używany do podpisywania innych aplikacji uwzględnionych w implementacjach na urządzeniu.

  • [C-0-8] Podczas instalowania aplikacji alternatywne środowiska wykonawcze MUSZĄ uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację.

  • [C-0-9] Gdy aplikacja musi korzystać z zasobu urządzenia, do którego są przypisane uprawnienia Androida (takie jak Aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI informować użytkownika, że aplikacja będzie miała dostęp do tego zasobu.

  • [C-0-10] Jeśli środowisko wykonawcze nie rejestruje możliwości aplikacji w ten sposób, podczas instalowania aplikacji korzystających z tego środowiska wykonawczego MUSI ono zawierać listę wszystkich uprawnień samego środowiska wykonawczego.

  • Alternatywne środowiska wykonawcze MUSZĄ instalować aplikacje za pomocą interfejsu PackageManager w osobnych piaskownicy Androida (identyfikatory użytkowników systemu Linux itp.).

  • Alternatywne środowiska wykonawcze MOGĄ udostępniać jedną piaskownicę Androida współużytkowaną przez wszystkie aplikacje korzystające z alternatywnego środowiska wykonawczego.

9.5. Obsługa wielu użytkowników

Android zapewnia obsługę wielu użytkowników i pełną izolację użytkowników.

  • Implementacje urządzeń MOGĄ BYĆ, ale NIE POWINNY być włączane dla wielu użytkowników, jeśli korzystają z nośników wymiennych jako podstawowej pamięci zewnętrznej.

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

  • [C-1-1] MUSI spełniać następujące wymagania związane z obsługą wielu użytkowników.
  • [C-1-2] MUSI wdrożyć dla każdego użytkownika model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień w interfejsach API.
  • [C-1-3] MUSI mieć oddzielne i odizolowane katalogi współdzielonej pamięci aplikacji (/sdcard) dla każdej instancji użytkownika.
  • [C-1-4] MUSI mieć pewność, że aplikacje należące do danego użytkownika i uruchamiane w jego imieniu nie mogą wyświetlać, odczytywać ani zapisywać plików należących do innych użytkowników, nawet jeśli dane obu użytkowników są przechowywane w tym samym woluminie lub w tym samym systemie plików.
  • [C-1-5] MUSI szyfrować zawartość karty SD, gdy jest włączony wielu użytkowników, przy użyciu klucza zapisanego wyłącznie na niewymiennym nośniku dostępnym tylko dla systemu, jeśli implementacje urządzenia korzystają z nośników wymiennych dla interfejsów API pamięci zewnętrznej. Ponieważ uniemożliwi to odczytanie multimediów na komputerze hosta, trzeba będzie wdrożyć urządzenia na MTP lub podobny system, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika.

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

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

Jeśli implementacje urządzeń obejmują wielu użytkowników i zadeklarują flagę funkcji android.hardware.telephony, oznacza to, że:

  • [C-3-1] NIE MOŻE obsługiwać profili z ograniczonym dostępem, ale MUSI być zgodny z mechanizmami kontroli AOSP, które włączają lub wyłączają innym użytkownikom dostęp do połączeń głosowych i SMS-ów.

9.6 Ostrzeżenie SMS-a specjalnego

Android umożliwia ostrzeganie użytkowników o wychodzących SMS-ach premium. SMS-y specjalne to SMS-y wysyłane do usługi zarejestrowanej u operatora, za którą użytkownik może być obciążony.

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

  • [C-1-1] MUSI ostrzegać użytkowników przed wysłaniem SMS-a na numery identyfikowane przez wyrażenia regularne zdefiniowane w pliku /data/misc/sms/codes.xml na urządzeniu. Rozwiązania Android Open Source Project, które opracowujemy na potrzeby platformy Android, to implementacja, która spełnia to wymaganie.

9.7. Funkcje zabezpieczeń jądra systemu

Piaskownica Androida obejmuje funkcje korzystające z systemu Security-Extended Linux (SELinux), obowiązkowej kontroli dostępu (MAC), seccomp sandbox (piaskownica seccomp) i inne funkcje zabezpieczeń jądra systemu Linux. Implementacje na urządzeniach:

  • [C-0-1] MUSI zachować zgodność z istniejącymi aplikacjami, nawet jeśli SELinux lub inne funkcje zabezpieczeń są wdrożone poniżej platformy Androida.
  • [C-0-2] NIE MOŻE mieć widocznego interfejsu użytkownika po wykryciu naruszenia bezpieczeństwa i zablokowaniu go przez funkcję zabezpieczeń wdrożoną poniżej platformy Androida, ale MOŻE mieć widoczny interfejs w przypadku wystąpienia niezablokowanego naruszenia zabezpieczeń, które skutkuje udanym exploitem.
  • [C-0-3] NIE MOŻE udostępniać użytkownikowi ani deweloperowi aplikacji SELinux ani żadnych innych funkcji zabezpieczeń wdrożonych poniżej platformy Androida.
  • [C-0-4] NIE MOŻE zezwalać aplikacji, która może wpływać na inną aplikację za pomocą interfejsu API (takiej jak interfejs Device Administration API), aby konfigurować zasady naruszające zgodność.
  • [C-0-5] MUSI podzielić platformę multimediów na wiele procesów, aby możliwe było węższe przyznanie dostępu każdemu z nich, zgodnie z opisem na stronie projektu Android Open Source.
  • [C-0-6] MUSI wdrożyć mechanizm piaskownicy aplikacji w jądrze, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnej zasady z programów wielowątkowych. Nadrzędny projekt Android Open Source Project spełnia to wymaganie przez włączenie seccomp-BPF z synchronizacją grup wątków (TSYNC) zgodnie z opisem w sekcji Konfiguracja jądra na stronie source.android.com.

Integralność jądra i funkcje samoochrony stanowią integralne elementy zabezpieczeń Androida. Implementacje na urządzeniach:

  • [C-0-7] MUSI wdrożyć zabezpieczenia przed przepełnieniem bufora stosu jądra (np. CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] MUSI wdrożyć rygorystyczną ochronę pamięci jądra, w której kod wykonywalny jest tylko do odczytu, dane tylko do odczytu są niewykonywalne i niemożliwe do zapisu, a dane, które można zapisać, nie są możliwe do wykonania (np. CONFIG_DEBUG_RODATA lub CONFIG_STRICT_KERNEL_RWX).
  • [SR] Zdecydowanie ZALECANE jest zachowanie danych jądra, które są zapisywane wyłącznie podczas inicjowania, oznaczone jako przeznaczone tylko do odczytu po zainicjowaniu (np. __ro_after_init).
  • [SR} Zdecydowanie ZALECANE jest wdrożenie statycznych i dynamicznych granic obiektów dynamicznych, które umożliwiają sprawdzanie kopii między przestrzenią użytkownika a przestrzenią jądra (np. CONFIG_HARDENED_USERCOPY).
  • [SR] Zdecydowanie ZALECANE, aby nigdy nie wykonywać pamięci w przestrzeni użytkownika podczas działania w jądrze (np. sprzętowego PXN bądź emulowanej przez CONFIG_CPU_SW_DOMAIN_PAN lub CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] Zdecydowanie ZALECANE jest, aby nigdy nie odczytywać ani zapisywać pamięci przestrzeni użytkownika w jądrze poza zwykłymi interfejsami API z dostępem do kopii przez użytkownika (np. sprzętowym numerem PAN lub emulowaną przez CONFIG_CPU_SW_DOMAIN_PAN bądź CONFIG_ARM64_SW_TTBR0_PAN).
  • [SR] Zdecydowanie ZALECANY jest losowy układ kodu jądra i pamięci oraz unikanie ekspozycji, które mogłyby negatywnie wpłynąć na randomizację (np. CONFIG_RANDOMIZE_BASE z entropią programu rozruchowego przez /chosen/kaslr-seed Device Tree node lub EFI_RNG_PROTOCOL).

Jeśli implementacje urządzeń korzystają z jądra systemu Linux:

  • [C-1-1] MUSI zaimplementować SELinux.
  • [C-1-2] MUSI ustawić SELinux w tryb globalnego egzekwowania.
  • [C-1-3] MUSI skonfigurować wszystkie domeny w trybie wymuszania. Nie są dozwolone żadne domeny w trybie mniej rygorystycznym, w tym domeny specyficzne dla urządzenia lub dostawcy.
  • [C-1-4] NIE MOŻE modyfikować, pomijać ani zastępować reguł nigdy, które znajdują się w folderze systemowym/sepolicy dostępnym w nadchodzącym projekcie Android Open Source Project (AOSP), a zasada MUSI skompilować wszystkie obecne reguły, zarówno dla domen AOSP SELinux, jak i specyficznych dla urządzeń/dostawców.
  • POWINIEN zachować domyślną zasadę SELinux w folderze systemowym/sekwencyjnym nadrzędnego projektu Android Open Source i dodać ją do tej zasady jedynie na potrzeby konfiguracji w określonym urządzeniu.

Jeśli implementacje urządzeń korzystają z jądra innego niż Linux:

  • [C-2-1] MUSI używać obowiązkowego systemu kontroli dostępu równoważnego z SELinux.

9.8. Prywatność

9.8.1. Historia wykorzystania

Android przechowuje historię wyborów użytkownika i zarządza nią w usłudze UsageStatsManager.

Implementacje na urządzeniach:

  • [C-1-1] MUSI przechowywać taką historię użytkownika w rozsądnym czasie.
  • [SR] Zdecydowanie ZALECANE jest zachowanie domyślnie skonfigurowanego 14-dniowego okresu przechowywania w implementacji AOSP.

9.8.2. Nagrywam

Jeśli implementacje urządzeń obejmują funkcje, które umożliwiają przechwytywanie treści wyświetlanych na ekranie lub nagrywanie strumienia audio odtwarzanego na urządzeniu:

  • [C-1-1] MUSI mieć bieżące powiadomienie do użytkownika o włączeniu tej funkcji oraz aktywnym nagrywaniu i rejestrowaniu.

Jeśli implementacje urządzeń zawierają włączony od razu komponent, który może rejestrować dźwięki otoczenia w celu uzyskania przydatnych informacji o kontekście użytkownika:

  • [C-2-1] NIE MOŻE przechowywać w trwałych pamięciach urządzeń ani przesyłać poza urządzenie nagranych, nieprzetworzonych plików audio ani żadnych formatów, które można przekonwertować z powrotem na oryginalny dźwięk lub faks, chyba że za wyraźną zgodą użytkownika.

9.8.3 Połączenia

Jeśli urządzenia są wyposażone w port USB z obsługą trybu urządzenia peryferyjnego USB:

  • [C-1-1] MUSI wyświetlić interfejs użytkownika z prośbą o zgodę na dostęp do zawartości pamięci współdzielonej przez port USB.

9.8.4 Ruch w sieci

Implementacje na urządzeniach:

  • [C-0-1] MUSI zainstalować te same certyfikaty główne dla zaufanego systemu urzędu certyfikacji, które zostały dostarczone w nadrzędnym projekcie Android Open Source.
  • [C-0-2] MUSI być wysyłany z pustym magazynem głównego urzędu certyfikacji użytkownika.
  • [C-0-3] MUSI wyświetlać użytkownikowi ostrzeżenie informujące, że ruch sieciowy może być monitorowany po dodaniu głównego urzędu certyfikacji użytkownika.

Jeśli ruch z urządzenia jest kierowany przez VPN, takie implementacje urządzeń:

  • [C-1-1] MUSI wyświetlać użytkownikowi ostrzeżenie:
    • Ruch w tej sieci może być monitorowany.
    • Ruch ten jest kierowany przez konkretną aplikację VPN udostępniającą tę sieć.

Jeśli implementacje urządzeń mają mechanizm, który jest domyślnie włączony po włączeniu i kieruje ruch danych sieci przez serwer proxy lub bramę VPN (np. wstępne wczytywanie usługi VPN z przyznanym ustawieniem android.permission.CONTROL_VPN), dzięki czemu:

  • [C-2-1] MUSI prosić użytkownika o zgodę przed włączeniem tego mechanizmu, chyba że usługa VPN jest włączona przez kontroler zasad dotyczących urządzeń w narzędziu DevicePolicyManager.setAlwaysOnVpnPackage(). W takim przypadku użytkownik nie musi wyrażać osobnej zgody, a jedynie powinien zostać o tym powiadomiony.

Jeśli implementacje urządzeń implementują funkcję kupna-stałych użytkowników, aby włączyć funkcję „stały VPN” w aplikacji VPN innej firmy:

  • [C-3-1] MUSI wyłączyć tę funkcję użytkownika dla aplikacji, które nie obsługują stałej sieci VPN w pliku AndroidManifest.xml przez ustawienie atrybutu SERVICE_META_DATA_SUPPORTS_ALWAYS_ON na false.

9.9. Szyfrowanie magazynu danych

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

  • [C-1-1] MUSI obsługiwać szyfrowanie przechowywanych danych na potrzeby prywatnych danych aplikacji (/data partition), a także partycji pamięci współdzielonej aplikacji (/sdcard partition), jeśli stanowi ona trwałą, niemożliwą do usunięcia część urządzenia.

Jeśli implementacje urządzeń obsługują bezpieczny ekran blokady zgodnie z opisem w sekcji 9.11.1 oraz szyfrowanie przechowywania danych z wykorzystaniem technologii AES o wydajności powyżej 50 MiB/s:

  • [C-2-1] MUSI domyślnie włączać szyfrowanie danych, gdy użytkownik zakończy rozruchową konfigurację. Jeśli implementacje urządzeń zostały już wdrożone na starszej wersji Androida z domyślnie wyłączonym szyfrowaniem, takie urządzenie nie może spełnić wymagań w ramach aktualizacji oprogramowania systemowego, więc MOŻE zostać wykluczone.

  • MUSI spełnić powyższe wymagania dotyczące szyfrowania danych dzięki wdrożeniu szyfrowania opartego na plikach (FBE).

9.9.1. Bezpośredni rozruch

Implementacje na urządzeniach:

9.9.2. Szyfrowanie oparte na plikach

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

  • [C-1-1] MUSI uruchomić się bez żądania podania danych logowania użytkownika i zezwolić aplikacjom wykrywającym bezpośrednie rozruchy na dostęp do pamięci zaszyfrowanej na urządzeniu (DE) po wysłaniu komunikatu ACTION_LOCKED_BOOT_COMPLETED.
  • [C-1-2] MUSI zezwalać na dostęp do pamięci CE (Credential Encrypted) dopiero po odblokowaniu urządzenia przez użytkownika przez podanie danych logowania (np. kodu dostępu, kodu PIN, wzoru lub odcisku palca) po wysłaniu komunikatu ACTION_USER_UNLOCKED.
  • [C-1-3] NIE MOŻE proponować żadnej metody odblokowywania pamięci chronionej znakiem CE bez danych logowania podanych przez użytkownika.
  • [C-1-4] MUSI obsługiwać weryfikację podczas uruchamiania i upewnić się, że klucze DE są kryptograficznie powiązane ze sprzętowym źródłem zaufania urządzenia.
  • [C-1-5] MUSI obsługiwać szyfrowanie zawartości pliku przy użyciu AES z kluczem 256-bitowym w trybie XTS.

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

  • Klucze chroniące obszary przechowywania CE i DE:

  • [C-1-7] MUSI być kryptograficznie powiązany ze sprzętowym magazynem kluczy.

  • [C-1-8] Klucze CE MUSZĄ być powiązane z danymi logowania na ekranie blokady użytkownika.
  • [C-1-9] Jeśli użytkownik nie określił danych logowania na ekranie blokady, klucze CE MUSZĄ być powiązane z domyślnym kodem dostępu.

  • [C-1-10] MUSI być niepowtarzalny, co oznacza, że żaden klucz CE lub DE użytkownika nie pasuje do żadnego klucza CE lub DE innego użytkownika.

  • TREŚCI MUSZĄ umożliwiać wykrywanie najważniejszych aplikacji (np. Alarm, Telefony, Messenger) przy bezpośrednim rozruchu.

  • MOŻE obsługiwać alternatywne mechanizmy szyfrowania, długości kluczy i tryby w przypadku zawartości pliku oraz szyfrowania nazw plików, ale MUSI domyślnie korzystać z obsługiwanych szyfrów, długości kluczy i trybów.

Nadrzędny projekt Android Open Source udostępnia preferowaną implementację tej funkcji opartą na funkcji szyfrowania ext4 jądra systemu Linux.

9.9.3 Pełne szyfrowanie dysku

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

  • [C-1-1] MUSI używać AES z kluczem 128-bitowym (lub większym) i trybem przeznaczonym do przechowywania danych (np. AES-XTS, AES-CBC-ESSIV).
  • [C-1-2] MUSI używać domyślnego kodu dostępu do pakowania klucza szyfrowania i NIE POWOLNO go zapisywać w pamięci klucza szyfrowania bez szyfrowania.
  • [C-1-3] MUSI domyślnie szyfrować klucz szyfrowania AES, chyba że użytkownik zrezygnuje z tej funkcji, chyba że jest on aktywny, gdy dane logowania na ekranie blokady są rozciągnięte przy użyciu algorytmu powolnego rozciągania (np. PBKDF2 lub scrypt).
  • [C-1-4] Powyższy domyślny algorytm rozciągania haseł MUSI być powiązany kryptograficznie z tym magazynem kluczy, gdy użytkownik nie określił danych logowania na ekranie blokady lub wyłączył możliwość używania hasła do szyfrowania, a urządzenie udostępnia sprzętowy magazyn kluczy.
  • [C-1-5] NIE MOŻE wysyłać klucza szyfrowania poza urządzenie (nawet jeśli jest zapakowany wraz z kodem dostępu użytkownika lub kluczem sprzętowym).

Nadrzędny projekt Android Open Source udostępnia preferowaną implementację tej funkcji opartą na funkcji dm-crypt w jądrze Linuksa.

9.10. Integralność urządzenia

Te wymagania zapewniają przejrzystość stanu integralności urządzenia. Implementacje na urządzeniach:

  • [C-0-1] MUSI prawidłowo zgłaszać za pomocą metody System API PersistentDataBlockManager.getFlashLockState(), czy stan programu rozruchowego zezwala na flashowanie obrazu systemu. Stan FLASH_LOCK_UNKNOWN jest zarezerwowany dla wdrożeń na urządzeniach z wcześniejszą wersją Androida, w której nie istniała nowa metoda interfejsu API systemu.

Weryfikacja podczas uruchamiania to funkcja, która gwarantuje integralność oprogramowania urządzenia. Jeśli implementacja urządzenia obsługuje tę funkcję, oznacza to, że:

  • [C-1-1] MUSI zadeklarować flagę funkcji platformy android.software.verified_boot.
  • [C-1-2] MUSI przeprowadzić weryfikację przy każdej sekwencji uruchamiania.
  • [C-1-3] MUSI rozpocząć weryfikację od stałego klucza sprzętowego, który jest podstawą zaufania, aż do poziomu partycji systemowej.
  • [C-1-4] MUSI wdrożyć każdy etap weryfikacji, aby na następnym etapie sprawdzić integralność i autentyczność wszystkich bajtów, zanim wykonasz kod na kolejnym etapie.
  • [C-1-5] MUSI używać algorytmów weryfikacji tak silnych jak obecne zalecenia NIST w zakresie algorytmów haszowania (SHA-256) i rozmiarów kluczy publicznych (RSA-2048).
  • [C-1-6] NIE MOŻE umożliwiać uruchomienia urządzenia w przypadku niepowodzenia weryfikacji systemu, chyba że użytkownik mimo to wyrazi zgodę – wtedy nie wolno używać danych z niezweryfikowanych bloków pamięci masowej.
  • [C-1-7] NIE MOŻE zezwalać na modyfikowanie zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokuje program rozruchowy.
  • [SR] Jeśli w urządzeniu znajduje się wiele dyskretnych układów scalonych (np. radio, specjalistyczny procesor obrazu), Zdecydowanie ZALECANY jest proces uruchamiania każdego z nich, aby sprawdzić każdy etap podczas uruchamiania.
  • [SR] Zdecydowanie ZALECANE jest użycie pamięci, w której wykryto manipulacje: gdy program rozruchowy jest odblokowany. Magazyn danych potwierdzający ingerencję oznacza, że program rozruchowy może wykryć, czy nie manipulowano w pamięci HLOS (wysokiego poziomu systemu operacyjnego).
  • [SR] ZALECNIE ZALECANE jest poproszenie użytkownika o zgodę podczas korzystania z urządzenia i wymaganie fizycznego potwierdzenia przed zezwoleniem na przejście z trybu blokady programu rozruchowego na tryb odblokowany przez program rozruchowy.
  • [SR] ZDECYDOWANIE ZALECANE jest wdrożenie ochrony przed wycofywaniem HLOS (np. podczas uruchamiania, partycje systemowe) i użycie pamięci masowej z możliwością wykrycia ingerencji do przechowywania metadanych używanych do określenia minimalnej dopuszczalnej wersji systemu operacyjnego.
  • NALEŻY zaimplementować ochronę przywracania przed wycofywaniem każdego komponentu z trwałym oprogramowaniem układowym (np. modemu czy aparatu) oraz NALEŻY korzystać z pamięci, w trakcie której doszło do manipulacji, do przechowywania metadanych używanych do określenia minimalnej dopuszczalnej wersji.

Projekt Android Open Source projektu zapewnia preferowaną implementację tej funkcji w repozytorium external/avb/, które można zintegrować z programem rozruchowym służącym do wczytywania Androida.

Jeśli implementacje urządzenia zgłaszają flagę funkcji android.hardware.ram.normal, oznacza to, że:

  • [C-2-1] MUSI obsługiwać weryfikację rozruchu, aby zapewnić integralność urządzenia.

Jeśli implementacja urządzenia została już rozpoczęta i nie obsługuje weryfikacji rozruchu we wcześniejszej wersji Androida, takie urządzenie nie może dodać obsługi tej funkcji w ramach aktualizacji oprogramowania systemowego, więc jest zwolnione z tego wymogu.

9.11. Klucze i dane uwierzytelniające

System magazynu kluczy Android umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i wykorzystywanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub interfejsu Keystore API. Implementacje na urządzeniach:

  • [C-0-1] MUSI umożliwiać zaimportowanie co najmniej 8192 kluczy.
  • [C-0-2] Uwierzytelnianie na ekranie blokady MUSI mieć limit prób ograniczania liczby żądań i MUSI mieć algorytm wzrastającego ponowienia. Powyżej 150 nieudanych prób opóźnienie MUSI wynosić co najmniej 24 godziny.
  • NIE POWINNO ograniczać liczby kluczy, które można wygenerować

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady,:

  • [C-1-1] MUSI utworzyć kopię zapasową implementacji magazynu kluczy za pomocą bezpiecznego sprzętu.
  • [C-1-2] MUSI zawierać implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1 i SHA-2, aby zapewnić prawidłową obsługę algorytmów obsługiwanych przez system Android Keystore w obszarze odizolowanym od kodu działającego w jądrze i nowszych. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, dzięki którym jądro lub kod przestrzeni użytkownika mogą uzyskiwać dostęp do wewnętrznego stanu odizolowanego środowiska, w tym do aktu o rynkach cyfrowych. Dodatkowy projekt Android Open Source Project (AOSP) spełnia to wymaganie dzięki implementacji Trusty. Alternatywnym rozwiązaniem są inne rozwiązanie oparte na technologii ARM TrustZone lub sprawdzone i sprawdzone przez firmę zewnętrzną wdrożenie izolacji opartej na hipernadzorcy.
  • [C-1-3] MUSI przeprowadzić uwierzytelnianie ekranu blokady w izolowanym środowisku wykonawczym i tylko wtedy, gdy wszystko się uda, zezwolić na używanie kluczy powiązanych z uwierzytelnianiem. Dane logowania na ekranie blokady MUSZĄ być przechowywane w sposób umożliwiający uwierzytelnianie przy zablokowanym ekranie tylko w przypadku izolowanego środowiska wykonawczego. Nadrzędny projekt Android Open Source udostępnia platformę Gatekeeper Hardware Abstraction Layer (HAL) i Trusty, które można wykorzystać w celu spełnienia tego wymogu.
  • [C-1-4] MUSI obsługiwać atest klucza, gdy klucz podpisywania atestu jest chroniony przez bezpieczny sprzęt, a podpisywanie jest wykonywane na bezpiecznym sprzęcie. Klucze podpisywania atestu MUSZĄ być udostępniane przez wystarczającą liczbę urządzeń, aby nie można było ich używać jako identyfikatorów urządzeń. Jednym ze sposobów spełnienia tego wymogu jest udostępnianie tego samego klucza atestu,chyba że zostanie wyprodukowanych co najmniej 100 tys. jednostek danego kodu SKU. Jeśli wyprodukowany zostanie więcej niż 100 tys. jednostek SKU, dla każdej z nich może zostać użyty inny klucz.

Pamiętaj, że jeśli implementacja urządzenia została już wprowadzona we wcześniejszej wersji Androida, urządzenie zostanie zwolnione z obowiązku posiadania sprzętowego magazynu kluczy, chyba że zadeklaruje funkcję android.hardware.fingerprint, która wymaga takiego magazynu.

9.11.1. Bezpieczny ekran blokady

Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jednego agenta zaufania, który implementuje systemowy interfejs API TrustAgentService, następuje wtedy wykonanie tych czynności:

  • [C-1-1] MUSI wskazywać użytkownika w interfejsie Ustawienia i Ekran blokady w sytuacjach, gdy automatyczna blokada ekranu jest odroczona lub blokada ekranu może zostać odblokowana przez agenta zaufania. System AOSP spełnia to wymaganie, wyświetlając opis tekstowy w menu „Ustawienia Automatycznie blokuj” i „Przycisk zasilania natychmiast blokuje ustawienia” oraz wyróżniającą ikonę na ekranie blokady.
  • [C-1-2] MUSI respektować i w pełni wdrożyć wszystkie interfejsy API agenta zaufania w klasie DevicePolicyManager, takie jak stała KEYGUARD_DISABLE_TRUST_AGENTS.
  • [C-1-3] NIE MOŻE w pełni wdrażać funkcji TrustAgentService.addEscrowToken() na urządzeniu używanym jako główne urządzenie osobiste (np. podręczne), ale MOŻE w pełni wdrożyć tę funkcję w typowych implementacjach urządzeń.
  • [C-1-4] MUSI zaszyfrować tokeny dodane przez TrustAgentService.addEscrowToken(), zanim zapiszesz je na urządzeniu.
  • [C-1-5] NIE MOŻE przechowywać klucza szyfrowania na urządzeniu.
  • [C-1-6] MUSI poinformować użytkownika o wpływie na bezpieczeństwo przed włączeniem tokena depozytowego na potrzeby odszyfrowywania magazynu danych.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania w celu odblokowywania ekranu, wtedy taka metoda uwierzytelniania może być traktowana jako bezpieczny sposób blokowania ekranu:

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania w celu odblokowywania ekranu blokady, jeśli są one oparte na znanym obiekcie tajnym, to aby taka metoda uwierzytelniania została uznana za bezpieczny sposób blokowania ekranu:

  • [C-3-1] Entropia najkrótszej dozwolonej długości danych wejściowych MUSI być większa niż 10 bitów.
  • [C-3-2] Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18 bitów.
  • [C-3-3] NIE MOŻE zastępować żadnej z istniejących metod uwierzytelniania (kodu PIN,wzoru, hasła) wdrożonych i przekazanych w AOSP.
  • [C-3-4] MUSI być wyłączona, gdy aplikacja kontrolera zasad urządzeń (DPC) ustawiła zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_SOMETHING.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania w celu odblokowywania ekranu blokady, jeśli są oparte na tokenie fizycznym lub lokalizacji, to aby taka metoda uwierzytelniania mogła być traktowana jako bezpieczny sposób blokowania ekranu, musi:

  • [C-4-1] MUSI mieć mechanizm zastępczy umożliwiający użycie jednej z podstawowych metod uwierzytelniania, które są oparte na znanym obiekcie tajnym i spełniają wymagania traktowania jako bezpiecznego ekranu blokady.
  • [C-4-2] MUSI być wyłączona i zezwalać głównemu uwierzytelnianiemu na odblokowanie ekranu tylko wtedy, gdy aplikacja kontrolera zasad dotyczących urządzeń ustawiła zasadę za pomocą metody DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) lub metody DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_UNSPECIFIED.
  • [C-4-3] Użytkownik MUSI otrzymywać potwierdzenie podstawowego uwierzytelniania (np. kodu PIN, wzoru, hasła) co najmniej raz na 72 godziny.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania w celu odblokowywania ekranu blokady na podstawie danych biometrycznych, to aby ta metoda uwierzytelniania mogła być traktowana jako bezpieczny sposób blokowania ekranu, muszą one:

  • [C-5-1] MUSI mieć mechanizm zastępczy umożliwiający użycie jednej z podstawowych metod uwierzytelniania, które są oparte na znanym obiekcie tajnym i spełniają wymagania traktowania jako bezpiecznego ekranu blokady.
  • [C-5-2] MUSI być wyłączona i zezwolić na odblokowywanie ekranu przy użyciu podstawowego uwierzytelniania tylko wtedy, gdy aplikacja kontrolera zasad urządzeń (DPC) ustawi zasadę funkcji keguard, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
  • [C-5-3] MUSI mieć współczynnik fałszywych akceptacji, który jest równy lub wyższy niż wartość wymagana w przypadku czytnika linii papilarnych zgodnie z opisem w sekcji 7.3.10, lub w inny sposób MUSI być wyłączona i zezwalać podstawowe uwierzytelnianie na odblokowanie ekranu tylko wtedy, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
  • [SR] Zdecydowanie ZALECANE jest, aby współczynniki akceptacji i podszywanie się pod inne osoby były równe lub wyższe niż wymagane przez czytnik linii papilarnych zgodnie z opisem w artykule 7.3.10.

Jeśli współczynniki akceptacji i podszywanie się pod inne osoby nie są równe lub wyższe niż wymagane w przypadku czytnika linii papilarnych zgodnie z opisem w sekcji 7.3.10, a aplikacja kontrolera zasad urządzeń (DPC) ustawiła zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakością niż PASSWORD_QUALITY_BIOMETRIC_WEAK, a następnie:

  • [C-6-1] MUSI wyłączyć te metody biometryczne i odblokowywać ekran tylko przy użyciu podstawowego uwierzytelniania.
  • [C-6-2] MUSI wymagać od użytkownika przeprowadzenia podstawowego uwierzytelniania (np. kodu PIN, wzoru, hasła) co najmniej raz na 72 godziny.

Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania na potrzeby odblokowywania ekranu blokady i takie uwierzytelnianie jest używane do odblokowywania blokady ekranu, ale nie jest traktowane jako bezpieczny ekran blokady, wtedy:

9.12. Usuwanie danych

Wszystkie implementacje na urządzeniach:

  • [C-0-1] MUSI udostępniać użytkownikom mechanizm przywracania danych fabrycznych.
  • [C-0-2] MUSI usunąć wszystkie dane użytkowników. Oznacza to, że wszystkie dane oprócz tych:
    • Obraz systemu
    • wszystkie pliki systemu operacyjnego wymagane przez obraz systemu,
  • [C-0-3] MUSI usuwać dane w sposób zgodny z odpowiednimi standardami branżowymi, takimi jak NIST SP800-88.
  • [C-0-4] MUSI aktywować powyższy proces „przywracania danych fabrycznych” po wywołaniu interfejsu API DevicePolicyManager.wipeData() przez aplikację kontrolera zasad dotyczących urządzeń głównego użytkownika.
  • MOŻE udostępnić opcję szybkiego czyszczenia danych, która przeprowadza tylko logiczne usuwanie danych.

9.13. Tryb bezpiecznego rozruchu

Android zapewnia tryb bezpiecznego rozruchu, który umożliwia użytkownikom uruchamianie urządzenia w trybie, w którym mogą działać tylko wstępnie zainstalowane aplikacje systemowe, a wszystkie aplikacje innych firm są wyłączone. Ten tryb, nazywany „trybem bezpiecznego rozruchu”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.

Implementacje urządzeń:

  • [SR] Zdecydowanie ZALECANE jest wdrożenie trybu bezpiecznego rozruchu.

Jeśli implementacje urządzeń mają włączony tryb bezpiecznego rozruchu:

  • [C-1-1] MUSI umożliwiać użytkownikowi przejście w tryb bezpiecznego rozruchu w sposób uniemożliwiający jego przerwanie w aplikacjach innych firm zainstalowanych na urządzeniu, chyba że aplikacja innej firmy jest kontrolerem zasad dotyczących urządzeń i ma ustawioną flagę UserManager.DISALLOW_SAFE_BOOT na wartość true (prawda).

  • [C-1-2] MUSI umożliwiać użytkownikowi odinstalowanie aplikacji innych firm w trybie awaryjnym.

  • Trzeba udostępnić użytkownikowi opcję włączenia trybu bezpiecznego rozruchu z menu rozruchu przy użyciu przepływu pracy innego niż zwykły rozruch.

9.14. Izolacja systemu samochodowego

Oczekuje się, że urządzenia z Androidem Automotive będą wymieniać dane z najważniejszymi podsystemami w pojeździe, wykorzystując interfejs HAL pojazdu do wysyłania i odbierania wiadomości w sieciach pojazdu, takich jak magistrala CAN.

Wymianę danych można zabezpieczyć, implementując funkcje zabezpieczeń poniżej warstw platformy Android, zapobiegając złośliwej lub niezamierzonej interakcji z tymi podsystemami.

10. Testowanie zgodności oprogramowania

Implementacje na urządzeniach MUSZĄ przejść wszystkie testy opisane w tej sekcji.

Należy jednak pamiętać, że żaden pakiet testów oprogramowania nie jest w pełni wszechstronny. Z tego powodu Zdecydowanie ZALECANE jest wprowadzenie jak najmniejszej liczby zmian w plikach referencyjnych i preferowanej implementacji Androida dostępnej w ramach projektu Android Open Source Project. Zminimalizuje to ryzyko wprowadzenia błędów, które powodują niezgodności, które wymagają przerobienia i potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje urządzeń MUSZĄ przejść test Android Compatibility Test Suite (CTS) dostępny w projekcie Android Open Source przy użyciu gotowego oprogramowania do wysyłki. Dodatkowo osoby implementujące urządzenia POWINNY W jak największym stopniu korzystać z implementacji referencyjnej w drzewie Android Open Source i MUSZĄ zadbać o zgodność w przypadku niejasności w interfejsie CTS oraz w przypadku wszelkich zmian implementacji części referencyjnego kodu źródłowego.

Narzędzie CTS zostało zaprojektowane tak, aby działać na prawdziwym urządzeniu. Podobnie jak w przypadku każdego oprogramowania, narzędzie CTS może zawierać błędy. Pakiet CTS będzie prowadzony niezależnie od tej definicji zgodności, a dla Androida 8.1 może zostać wydanych kilka wersji. Implementacje na urządzeniu MUSZĄ przekazywać najnowszą wersję CTS dostępną w chwili zakończenia działania oprogramowania urządzenia.

10.2. Weryfikator CTS

Implementacje na urządzeniach MUSZĄ prawidłowo wykonywać wszystkie odpowiednie przypadki weryfikatora CTS. CTS Verifier wchodzi w skład pakietu Compatibility Test Suite i może być uruchamiany przez człowieka w celu testowania funkcji, których zautomatyzowany system nie może przetestować, na przykład prawidłowego działania kamery i czujników.

Weryfikator CTS wykonuje testy obejmujące różne rodzaje sprzętu, w tym sprzęt opcjonalny. Implementacje urządzeń MUSZĄ przejść wszystkie testy posiadanego sprzętu. Jeśli na przykład urządzenie ma akcelerometr, MUSI prawidłowo wykonać test akcelerometru w weryfikatorze CTS. Przypadki testowe funkcji oznaczonych w tym dokumencie definicji zgodności jako opcjonalne MOGĄ zostać pominięte lub pominięte.

Na każdym urządzeniu i każdej kompilacji MUSI uruchomić się weryfikator CTS zgodnie z opisem powyżej. Ponieważ jednak wiele kompilacji jest bardzo podobnych, narzędzia implementujące na urządzeniach nie powinny jawnie uruchamiać weryfikatora CTS w kompilacjach, które różnią się tylko w prosty sposób. Chodzi w szczególności o implementacje na urządzeniach, które różnią się od tych, które przeszły weryfikację przez weryfikatora CTS tylko przez zestaw uwzględnionych języków, oznaczenia marki itp. MOGĄ pominąć test weryfikatora CTS.

11. Oprogramowanie do aktualizacji

Implementacje na urządzeniu MUSZĄ zawierać mechanizm zastępujący całe oprogramowanie systemowe. Mechanizm nie musi przeprowadzać uaktualnień w czasie rzeczywistym – tzn. może być wymagane ponowne uruchomienie urządzenia.

Można użyć dowolnej metody, pod warunkiem że może ona zastąpić całe oprogramowanie zainstalowane fabrycznie na urządzeniu. To wymaganie może zostać spełnione na przykład przez:

  • Pobieranie typu „bezprzewodowe (OTA)” z aktualizacją offline po ponownym uruchomieniu.
  • Opcja „w tetheringu” jest aktualizowana przez USB z komputera hosta.
  • „Tryb offline” aktualizuje się po ponownym uruchomieniu i aktualizacji z pliku w pamięci wymiennej.

Jeśli jednak implementacja urządzenia obejmuje obsługę połączenia danych bez pomiaru użycia danych, np. 802.11 lub profilu Bluetooth z numerem PAN (sieć osobista), MUSI obsługiwać pobieranie OTA z aktualizacją offline po ponownym uruchomieniu.

Używany mechanizm aktualizacji MUSI obsługiwać aktualizacje bez czyszczenia danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachować prywatne dane aplikacji i dane udostępnione przez aplikację. Pamiętaj, że wcześniejsze oprogramowanie Android ma mechanizm aktualizacji, który spełnia to wymaganie.

W przypadku implementacji na urządzeniach z Androidem 6.0 i nowszym mechanizm aktualizacji POWINIEN obsługiwać sprawdzanie, czy obraz systemu jest binarnie identyczny z oczekiwanym wynikiem po aktualizacji OTA. To wymaganie spełnia oparta na blokowych implementacja OTA w źródłowym projekcie Android Open Source, dodana od Androida 5.1.

Implementacje na urządzeniach MUSZĄ też obsługiwać aktualizacje systemu A/B. AOSP implementuje tę funkcję przy użyciu interfejsu HAL kontroli rozruchu.

Jeśli po wprowadzeniu zmian na urządzeniu zostanie wykryty błąd, ale w rozsądnym okresie istnienia usługi, co zostanie określone po konsultacji z zespołem ds. zgodności z Androidem w celu zmiany zgodności aplikacji innych firm, osoba implementująca urządzenie MUSI poprawić błąd, korzystając z dostępnej aktualizacji oprogramowania, którą można zastosować zgodnie z opisanym mechanizmem.

Android zawiera funkcje, które umożliwiają aplikacji Właściciel urządzenia (jeśli jest zainstalowana) na kontrolowanie instalowania aktualizacji systemu. Aby to ułatwić, podsystem do aktualizacji systemu urządzeń zgłaszających plik android.software.device_admin MUSI zaimplementować działanie opisane w klasie SystemUpdatePolicy.

12. Historia zmian dokumentu

Podsumowanie zmian w definicji zgodności w tej wersji:

Aby zobaczyć podsumowanie zmian w sekcjach dotyczących poszczególnych osób:

  1. Wprowadzenie
  2. Typy urządzeń
  3. Oprogramowanie
  4. Pakiety aplikacji
  5. Multimedia
  6. Narzędzia i opcje dla programistów
  7. Zgodność sprzętu
  8. Wydajność i moc
  9. Model zabezpieczeń
  10. Testowanie zgodności oprogramowania
  11. Oprogramowanie, które można zaktualizować
  12. Historia zmian dokumentu
  13. Skontaktuj się z nami

12.1 Wskazówki dotyczące wyświetlania historii zmian

Zmiany są oznaczane w ten sposób:

  • CDD
    Istotne zmiany w wymaganiach dotyczących zgodności.

  • Dokumenty
    Zmiany kosmetyczne lub związane z tworzeniem.

Aby to zrobić, dołącz do adresów URL dziennika zmian parametry adresu URL pretty=full i no-merges.

13. Skontaktuj się z nami

Możesz dołączyć do forum dotyczącego zgodności z Androidem i poprosić o wyjaśnienia lub zgłosić problemy, które Twoim zdaniem nie obejmują dokumentu.