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/oprogramowanie z systemem Android 7.0. „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 7.0, 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ą narzędzia 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 niektórych 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.

2. Typy urządzeń

Projekt Android Open Source Project jest wykorzystywany we wdrażaniu różnych typów urządzeń i formatów, jednak wiele aspektów dotyczących architektury i zgodności zostało zoptymalizowanych pod kątem urządzeń mobilnych. Począwszy od Androida 5.0 projekt Android Open Source Project ma na celu obsługę szerszej gamy typów urządzeń, co opisano w tej sekcji.

Przenośne urządzenie z Androidem to implementacja urządzenia z Androidem, w którym zazwyczaj trzymasz urządzenie w dłoni, np. odtwarzacze mp3, telefony i tablety. Implementacje na przenośne urządzenia z Androidem:

MUSI mieć osadzony ekran dotykowy.
MUSI mieć źródło zasilania, które zapewnia mobilność, np. baterię.

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”). Urządzenia telewizyjne z Androidem:

MUSI mieć wbudowany ekran LUB musi zawierać port wyjściowy wideo, np. VGA, HDMI lub port bezprzewodowy, aby móc korzystać z ekranu.
MUSI zadeklarować funkcje android.software.leanback i android.hardware.type.television.

Zegarek Android Watch odnosi się do implementacji urządzenia z Androidem przeznaczonej do noszenia na ciele, na przykład na nadgarstku, oraz:

MUSI mieć ekran o przekątnej fizycznej z zakresu od 1,1 do 2,5 cala.
MUSI zadeklarować funkcję android.hardware.type.watch.
MUSI obsługiwać parametr uiMode = UI_MODE_TYPE_WATCH.

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 Androida Automotive:

MUSI mieć ekran o przekątnej większej niż 6 cali.
MUSI zadeklarować funkcję android.hardware.type.automotive.
MUSI obsługiwać tryb uiMode = UI_MODE_TYPE_CAR.
Implementacje na Androida Automotive MUSZĄ obsługiwać wszystkie publiczne interfejsy API w przestrzeni nazw android.car.*.

Wszystkie implementacje urządzeń z Androidem, które nie pasują do żadnego z powyższych typów, MUSZĄ spełniać wszystkie wymagania opisane w tym dokumencie, by były zgodne z Androidem 7.0, chyba że jednoznacznie określono, że dotyczy tylko określonego typu urządzeń z Androidem wymienionych powyżej.

2.1 Konfiguracje urządzeń

To jest podsumowanie głównych różnic w konfiguracji sprzętu w zależności od typu urządzenia. (Puste komórki oznaczają „MAJ”). Nie wszystkie konfiguracje zostały uwzględnione w tej tabeli. Więcej informacji znajdziesz w odpowiednich sekcjach na temat sprzętu.

Kategoria	Funkcja	Sekcja	Kamera z ręki	Telewizja	Obejrzyj	Automotive	Inne
Wprowadź tekst	Pad kierunkowy	7.2.2 Nawigacja bezdotykowa		MUSI
	Ekran dotykowy	7.2.4 Wprowadzanie tekstu na ekranie dotykowym	MUSI		MUSI		POWINNO
	mikrofon	7.8.1. Mikrofon	MUSI	POWINNO	MUSI	MUSI	POWINNO
Czujniki	Akcelerometr	7.3.1 Akcelerometr	POWINNO		POWINNO		POWINNO
Czujniki	GPS	7.3.3 GPS	POWINNO			POWINNO
Łączność	Wi-Fi	7.4.2 IEEE 802.11	POWINNO	POWINNO		POWINNO	POWINNO
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	POWINNO	POWINNO			POWINNO
	Bluetooth	7.4.3 Bluetooth	POWINNO	MUSI	MUSI	MUSI	POWINNO
	Bluetooth Low Energy	7.4.3 Bluetooth	POWINNO	MUSI	POWINNO	POWINNO	POWINNO
	Radio komórkowe	7.4.5 Minimalne możliwości sieci				POWINNO
	Tryb hosta/urządzenia peryferyjnego USB	7.7. USB	POWINNO			POWINNO	POWINNO
Wyjście	Porty głośnika i/lub wyjścia audio	7.8.2 Wyjście audio	MUSI	MUSI		MUSI	MUSI

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. Implementacje na urządzeniach MUSZĄ zapewniać kompletne 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.

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

Implementacje na urządzeniu NIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów API ani ich podpisów, odbiegać od udokumentowanego zachowania ani zawierać elementów bez działania (chyba że jest to wyraźnie dozwolone przez tę definicję zgodności).

Ta definicja zgodności pozwala na pomijanie niektórych typów sprzętu, w przypadku których Android obejmuje interfejsy API. W takich przypadkach interfejsy API MUSZĄ być dostępne i działać w rozsądny sposób. 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. Implementacje na urządzeniach z Androidem MUSZĄ wstępnie wczytywać implementację AOSP zarówno zasobów wspólnych ExtShared, jak 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

Narzędzia implementujące urządzenia 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. 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 7.0.
WERSJA.SDK	Wersja obecnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 7.0 to pole MUSI mieć wartość całkowitą 7.0_INT.
VERSION.SDK_INT	Wersja obecnie uruchomionego systemu Android w formacie dostępnym dla kodu aplikacji innej firmy. W przypadku Androida 7.0 to pole MUSI mieć wartość całkowitą 7.0_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 też służyć 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 i pasuje do wyrażenia regularnego „^[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)/$(PRODUKT)/ $(DEVICE):$(VERSION.release)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Na przykład: acme/mojprodukt/ mydevice:7.0/LMYXX/3359:userdebug/test-keys Odcisk palca 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, za wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu („”).
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, za wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu („”).
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 i pasuje do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Ta nazwa produktu NIE MOŻE zmieniać się przez cały okres jego istnienia.
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: wersja-klucze, klucze deweloperskie lub klucze testowe.
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 („”).

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ń. Podstawowe aplikacje na Androida to:

Zegar biurkowy
Przeglądarka
Kalendarz
Kontakty
Galeria
Wyszukiwanie globalne
Wyrzutnia
Muzyka
Ustawienia

Implementacje na urządzeniu MUSZĄ obejmować odpowiednio podstawowe aplikacje na Androida lub komponent implementujący te same wzorce intencji zdefiniowane przez wszystkie komponenty działania lub usługi tych podstawowych aplikacji na Androida, które są bezpośrednio lub bezpośrednio dostępne dla innych aplikacji za pomocą atrybutu android:exported.

3.2.3.2. Rozwiązanie intencji

Android jest rozszerzalną 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. Programy wdrażające na urządzeniu NIE MOGĄ dołączać specjalnych uprawnień do aplikacji systemowych wykorzystywania tych wzorców intencji lub uniemożliwianie aplikacjom innych firm wiązania z nimi i przejmowania nad nimi kontroli. Zakaz ten obejmuje w szczególności m.in. wyłączenie interfejsu „Wybór”, który umożliwia użytkownikowi wybieranie spośród kilku aplikacji, które obsługują ten sam wzorzec intencji.

Implementacje urządzeń MUSZĄ udostępniać interfejs, który umożliwia użytkownikom modyfikowanie domyślnego działania związanego z intencjami.

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

MUSI spróbować zweryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji Digital Asset Links, które zostało zaimplementowane przez menedżera pakietów w starszym projekcie Android Open Source.
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:
- Użytkownik MUSI mieć możliwość całościowego zastępowania domyślnego działania linków aplikacji, tak aby aplikacja zawsze działała: zawsze otwieraj, zawsze pytaj lub nigdy nie otwieraj – to ustawienie musi mieć zastosowanie do wszystkich filtrów intencji URI kandydatów w równym stopniu.
- Użytkownik MUSI mieć dostęp do listy potencjalnych filtrów intencji URI.
- 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.
- Implementacja na urządzeniu MUSI zapewniać użytkownikom możliwość wyświetlenia i zastąpienia określonych filtrów intencji URI kandydatów, jeśli implementacja urządzenia umożliwia pomyślne przejście weryfikacji przez niektóre kandydujące filtry intencji URI, a inne – niepowodzenie.

3.2.3.3 Przestrzenie nazw intencji

Implementacje urządzeń NIE MOGĄ zawierać żadnego komponentu Androida, który obsługuje nowe intencje lub wzorce intencji transmisji za pomocą ciągu ACTION, CATEGORY lub innego kluczowego ciągu znaków w Androidzie. lub com.android.. Moduły implementujące urządzenia 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 ciągu kluczowego w przestrzeni pakietu należącej do innej organizacji. Implementacje na urządzeniu 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. Urządzenia zgodne z Androidem MUSZĄ transmitować publiczne intencje transmisji w odpowiedzi na odpowiednie zdarzenia systemowe. Intencje transmisji zostały 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.

Implementacje na urządzeniach:

MUSI wyświetlać intencję android.settings.HOME_SETTINGS, aby wyświetlać domyślne menu ustawień aplikacji na ekranie głównym, jeśli implementacja urządzenia zgłasza android.software.home_screen.
MUSI zawierać menu ustawień, które wywołuje intencję android.provider.Telephony.ACTION_CHANGE_DEFAULT, aby wyświetlić okno zmiany domyślnej aplikacji SMS, jeśli implementacja urządzenia zgłasza android.hardware.telephony.
MUSI wyświetlać intencję android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlać domyślne menu ustawień aplikacji z funkcją Zbliż i zapłać, jeśli w przypadku implementacji na urządzeniu pojawia się zgłoszenie android.hardware.nfc.hce.
MUSI uwzględniać intencję android.telecom.action.CHANGE_DEFAULT_DIALER, aby wyświetlać okno umożliwiające użytkownikowi zmianę domyślnej aplikacji Telefon, jeśli implementacja urządzenia zgłasza android.hardware.telephony .

3.3. Zgodność z natywnym interfejsem API

Zgodność kodu natywnego stanowi wyzwanie. Z tego powodu Zdecydowanie ZALECANE są narzędzia implementujące urządzenia do implementacji wymienionych poniżej bibliotek z wcześniejszego 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 urządzeń MUSZĄ być zgodne z co najmniej jednym zdefiniowanym interfejsem ABI i MUSZĄ być zgodne z pakietem Android NDK, jak pokazano poniżej.

Jeśli implementacja urządzenia obejmuje obsługę interfejsu ABI Androida:

MUSI zawierać 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).
MUSI być zgodna ze źródłem (tzn. z nagłówkiem) i binarnym (w przypadku interfejsu ABI) z każdą wymaganą biblioteką z poniższej listy.
MUSI obsługiwać odpowiednik 32-bitowego interfejsu ABI, jeśli obsługiwany jest dowolny 64-bitowy interfejs ABI.
MUSI dokładnie zgłosić natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie, używając android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS i android.os.Build.SUPPORTED_64_BIT_ABIS listy parametrów ABI uporządkowanych od najbardziej do najmniej preferowanego.
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 i MUSZĄ obsługiwać rozszerzenie Advanced SIMD (NEON).
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. Jeśli implementacja urządzenia jest niezgodna z istniejącym wstępnie zdefiniowanym interfejsem ABI, NIE MOŻE w ogóle raportować pomocy dla żadnych interfejsów ABI.

Dla aplikacji zawierających kod natywny MUSZĄ być dostępne następujące interfejsy API kodu natywnego:

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
Obsługa OpenGL została opisana poniżej.

W przypadku wymienionych powyżej bibliotek natywnych implementacja urządzenia NIE MOŻE dodawać ani usuwać funkcji publicznych.

Biblioteki natywne niewymienione powyżej, ale zaimplementowane i dostarczone w AOSP, ponieważ biblioteki systemowe są zarezerwowane i NIE MOGĄ być dostępne dla aplikacji innych firm kierujących reklamy na interfejs API na poziomie 24 lub wyższym.

Implementacje na urządzeniu MOGĄ dodawać biblioteki inne niż AOSP i udostępniać je bezpośrednio jako interfejs API aplikacjom innych firm, ale biblioteki dodatkowe POWINNY być w języku /vendor/lib lub /vendor/lib64 i MUSZĄ być wymienione w zasadzie /vendor/etc/public.libraries.txt .

Pamiętaj, że implementacje urządzenia MUSZĄ zawierać libGLESv3.so i z tego powodu MUSZĄ wyeksportować wszystkie symbole funkcji OpenGL ES 3.1 i Android Extension Pack zgodnie z definicją w wersji NDK na Androida-24. Choć muszą być obecne wszystkie symbole, tylko odpowiednie funkcje dla wersji OpenGL ES i rozszerzeń rzeczywiście obsługiwanych przez urządzenie muszą być w pełni zaimplementowane.

3.3.1.1 Biblioteki graficzne

Vulkan to wieloplatformowy interfejs API niskobudżetowy do obsługi wysokiej wydajności grafiki 3D. Implementacje urządzeń, nawet jeśli nie obsługują interfejsów API Vulkan, MUSZĄ spełniać te wymagania:

MUSI zawsze zawierać bibliotekę natywną o nazwie libvulkan.so, która eksportuje symbole funkcji głównego interfejsu API Vulkan 1.0, a także rozszerzeń VK_KHR_surface, VK_KHR_android_surface i VK_KHR_swapchain.

Implementacje urządzeń, z obsługą interfejsów Vulkan API:

TRZEBA zgłosić co najmniej jedną VkPhysicalDevices za pomocą połączenia vkEnumeratePhysicalDevices.
Każda wymieniona grupa VkPhysicalDevices MUSI w pełni implementować interfejs API Vulkan 1.0.
MUSI zgłosić prawidłowe flagi funkcji PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL i PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.
MUSI wyliczać warstwy zawarte w bibliotekach natywnych o nazwie libVkLayer*.so w katalogu biblioteki natywnej pakietu aplikacji przy użyciu funkcji vkEnumerateInstanceLayerProperties i vkEnumerateDeviceLayerProperties w programie libvulkan.so
NIE MOŻE definiować warstw udostępnianych przez biblioteki poza pakietem aplikacji ani udostępniać innych sposobów śledzenia lub przechwytywania interfejsu Vulkan API, chyba że aplikacja ma atrybut android:debuggable=”true”.

Implementacje urządzeń, z wyjątkiem obsługi interfejsów API Vulkan:

MUSI zgłosić 0 VkPhysicalDevices za pomocą wywołania vkEnumeratePhysicalDevices.
NIE MOŻE deklarować żadnych flag funkcji interfejsu Vulkan PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL ani PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.

3.3.2 Zgodność z 32-bitowym kodem natywnym ARM

Architektura ARMv8 wycofuje kilka operacji na CPU, w tym niektóre operacje używane w istniejącym kodzie natywnym. Na 64-bitowych urządzeniach z architekturą ARM następujące wycofane operacje MUSZĄ być dostępne dla 32-bitowego natywnego kodu ARM w ramach wbudowanej obsługi procesora lub emulacji oprogramowania:

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

Starsze wersje Androida NDK używały katalogu /proc/cpuinfo do wykrywania funkcji procesora z 32-bitowego kodu natywnego ARM. Aby uzyskać zgodność z aplikacjami utworzonymi przy użyciu tego pakietu NDK, urządzenia MUSZĄ zawierać w pliku /proc/cpuinfo następujące wiersze, gdy są one odczytywane przez 32-bitowe aplikacje ARM:

„Funkcje: ” oraz lista wszystkich opcjonalnych funkcji procesora ARMv7 obsługiwanych przez urządzenie.
„architektura procesora: ”, po której następuje liczba całkowita opisująca najwyżej obsługiwaną architekturę procesora ARM (np. „8” na urządzeniach z architekturą ARMv8).

Te wymagania mają zastosowanie tylko wtedy, gdy plik /proc/cpuinfo jest odczytywany przez 32-bitowe aplikacje ARM. Urządzenia nie POWINNY być zmieniane przez /proc/cpuinfo podczas odczytu przez 64-bitowe aplikacje z procesorami ARM lub inne aplikacje.

3.4 Zgodność z internetem

3.4.1. Zgodność z WebView

Urządzenia z Androidem Watch MAJ, ale we wszystkich innych implementacjach MUSZĄ udostępniać pełną implementację interfejsu android.webkit.Webview API.

Funkcja platformy android.software.webview MUSI być zgłaszana na każdym urządzeniu, które zapewnia pełną implementację interfejsu API android.webkit.WebView API, i NIE MOŻE być zgłaszane w przypadku urządzeń bez pełnej implementacji interfejsu API. Implementacja open source Androida korzysta z kodu z projektu Chromium do implementacji interfejsu android.webkit.WebView. W związku z tym, że nie jest możliwe opracowanie kompleksowego zestawu testów dla systemu renderowania internetowego, osoby implementujące urządzenia MUSZĄ używać w implementacji WebView konkretnej nadrzędnej kompilacji Chromium. Więcej szczegółów:

Implementacje na urządzeniu android.webkit.WebView MUSZĄ być oparte na kompilacji Chromium pochodzącej z nadrzędnego projektu Android Open Source dla Androida 7.0. Ta kompilacja zawiera określony zestaw funkcji i poprawek zabezpieczeń dla WebView.
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ą

Implementacje w Android TV, Watch i Android Automotive mogą pomijać przeglądarkę, ale MUSZĄ obsługiwać wzorce intencji publicznej opisane w sekcji 3.2.3.1. Wszystkie inne implementacje urządzeń MUSZĄ zawierać samodzielną aplikację przeglądarki do przeglądania internetu przez użytkowników.

Samodzielna przeglądarka MOŻE być oparta na technologii przeglądarki innej niż WebKit. Jednak nawet w przypadku używania alternatywnej przeglądarki, komponent android.webkit.WebView udostępniany aplikacjom innych firm MUSI być oparty na silniku WebKit, zgodnie z opisem w sekcji 3.4.1.

Implementacje MOGĄ wysyłać niestandardowy ciąg znaków klienta użytkownika do samodzielnej aplikacji przeglądarki.

Samodzielna aplikacja przeglądarki (oparta na nadrzędnej aplikacji przeglądarki WebKit lub za pomocą zamiennika innej firmy) POWINNA obsługiwać jak największą część HTML5. Implementacje na urządzeniach MUSZĄ obsługiwać co najmniej każdy z tych interfejsów API powiązanych z HTML5:

Dodatkowo implementacje urządzeń MUSZĄ obsługiwać interfejs webstorage API HTML5/W3C oraz interfejs IndexedDB 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.

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:

Urządzenia NIE MOGĄ zmieniać działania ani semantyki intencji standardowej.
Urządzenia NIE MOGĄ zmieniać semantyki cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (np. Service, Activity czy ContentProvider).
Urządzeń NIE MOŻNA zmieniać semantyki uprawnień standardowych.

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.*
słońce*.
android*.
com.android.*,

Niedozwolone modyfikacje obejmują :

Implementacje urządzeń NIE MOGĄ modyfikować publicznie dostępnych interfejsów API na platformie Androida przez zmianę jakichkolwiek podpisów klas ani przez usunięcie klas czy pól klas.
Moduły implementujące urządzenia MOGĄ zmodyfikować podstawową implementację interfejsów API, ale takie modyfikacje NIE MOGĄ mieć wpływu na określone działanie ani na podpis w języku Java żadnych publicznie udostępnionych interfejsów API.
Implementatory urządzeń NIE MOGĄ dodawać do powyższych interfejsów API żadnych publicznie dostępnych elementów (takich jak klasy lub interfejsy, pola czy metody w istniejących klasach czy interfejsach).

„Element widoczny publicznie” to każdy obiekt, który nie jest oznaczony znacznikiem „@hide” używanym w kodzie źródłowym Androida. Inaczej mówiąc, narzędzia implementujące urządzenia NIE MOGĄ udostępniać nowych interfejsów API ani zmieniać istniejących interfejsów API w przestrzeniach nazw wymienionych powyżej. Moduły implementujące urządzenia MOGĄ wprowadzać zmiany przeznaczone tylko do użytku wewnętrznego, ale te modyfikacje NIE MOGĄ być reklamowane ani w żaden inny sposób prezentowane deweloperom.

Moduły implementujące urządzenia MOGĄ dodawać niestandardowe interfejsy API, ale takie interfejsy API NIE MOGĄ znajdować się w przestrzeni nazw należącej do innej organizacji lub się do niej odwołują. Na przykład narzędzia implementujące urządzenia NIE MOGĄ dodawać interfejsów API do com.google.* ani podobnej przestrzeni nazw – może to robić tylko Google. Podobnie firma Google NIE MOŻE dodawać interfejsów API do innych firm przestrzeni nazw. Poza tym, jeśli implementacja urządzenia obejmuje niestandardowe interfejsy API poza standardową przestrzenią nazw Androida, MUSZĄ one być spakowane w udostępniane zasoby Androida, tak aby zwiększone wykorzystanie pamięci przez te interfejsy API miało wpływ tylko na aplikacje, które z nich korzystają (przez mechanizm <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 uczynić je wiążącymi przez włączenie ich do tej definicji zgodności.

3.7. Zgodność środowiska wykonawczego

Implementacje na urządzeniach MUSZĄ obsługiwać pełny format DEX (Dalvik Executable) oraz specyfikację i semantykę kodu bajtowego Dalvik. Implementatory urządzeń POWINNY są używać ART, referencyjnej nadrzędnej implementacji formatu Dalvik Executable Format i systemu zarządzania pakietami implementacji referencyjnej.

Implementacje na urządzeniach MUSZĄ skonfigurować środowiska wykonawcze Dalvik, aby przydzielać pamięć zgodnie z nadrzędną platformą Androida oraz zgodnie z tabelą poniżej. (definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1). 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)	36MB
	320 dpi (Xhdpi)	48MB
	360 dpi (360dpi)	48MB
	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)	32MB
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (Xhdpi)	80MB
	360 dpi (360dpi)	80MB
	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)	80MB
	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)	96MB
	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). Implementacje urządzeń, które umożliwiają aplikacjom innych firm zastępowanie ekranu głównego urządzenia, MUSZĄ zadeklarować funkcję platformy android.software.home_screen.

3.8.2 Widżety

Widżety są opcjonalne we wszystkich implementacjach urządzeń z Androidem, ale POWINNY być ich obsługiwane na przenośnej urządzeniach z Androidem.

Android określa typ komponentu oraz odpowiedni interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi widżetu „AppWidget”. Zdecydowanie ZALECANE jest działanie tej funkcji w implementacjach na urządzeniach mobilnych. Implementacje urządzeń, które obsługują umieszczanie widżetów na ekranie głównym, MUSZĄ spełniać poniższe wymagania i zadeklarować obsługę funkcji platformy android.software.app_Widgets.

Programy uruchamiające na urządzeniach MUSZĄ zawierać wbudowaną obsługę widżetów AppWidgets i udostępniać możliwości interfejsu użytkownika w celu dodawania, konfigurowania, wyświetlania i usuwania elementów AppWidgets bezpośrednio w Menu z aplikacjami.
Implementacje urządzeń MUSZĄ wyświetlać widżety 4 x 4 w standardowym rozmiarze siatki. Szczegółowe informacje znajdziesz we wskazówkach na temat projektowania widżetów aplikacji w dokumentacji pakietu Android SDK.
Implementacje urządzeń, które obsługują ekran blokady, MOGĄ obsługiwać widżety aplikacji na ekranie blokady.

3.8.3 Powiadomienia

Android zawiera interfejsy API, które umożliwiają deweloperom powiadamianie użytkowników o ważnych wydarzeniach za pomocą sprzętu i funkcji oprogramowania urządzenia.

Niektóre interfejsy API umożliwiają aplikacjom wysyłanie powiadomień lub przyciąganie uwagi przy użyciu sprzętu – w szczególności dźwięku, wibracji i światła. Implementacje urządzeń MUSZĄ obsługiwać powiadomienia używające funkcji sprzętowych zgodnie z dokumentacją pakietu SDK i w zakresie, w jakim jest to możliwe w przypadku danego sprzętu do implementacji. 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.

Dodatkowo implementacja MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki animacji itp.) znajdujące się w interfejsach API lub w przewodniku po stylu ikon na pasku stanu/systemu. W przypadku urządzeń z Androidem TV istnieje możliwość niewyświetlania powiadomień. Programy implementujące urządzenia MOGĄ zapewnić użytkownikom inne opcje obsługi powiadomień niż zapewniane przez referencyjną implementację Android Open Source. jednak takie alternatywne systemy powiadomień MUSZĄ obsługiwać istniejące zasoby powiadomień, tak jak powyżej.

Implementacje na Androida Automotive MOGĄ zarządzać widocznością i czasem powiadomień, aby ograniczyć rozpraszanie uwagi kierowcy, ale MUSZĄ wyświetlać powiadomienia korzystające z funkcji CarExtender, gdy o to poprosi aplikacje.

Android obsługuje różne powiadomienia, takie jak:

Rozszerzone powiadomienia Widoki interaktywne, w których pojawiają się bieżące powiadomienia.
Powiadomienia z ostrzeżeniem Użytkownicy w widokach interaktywnych mogą wykonywać lub odrzucać swoje działania bez opuszczania bieżącej aplikacji.
Powiadomienia na ekranie blokady Powiadomienia wyświetlane na ekranie blokady ze szczegółową kontrolą widoczności.

Implementacje na urządzeniach z Androidem, gdy takie powiadomienia są widoczne, MUSZĄ prawidłowo uruchamiać powiadomienia multimedialne i z ostrzeżeniem oraz zawierać tytuł, nazwę, ikonę i tekst w interfejsach API Androida.

Android obejmuje interfejsy API usługi detektora powiadomień, które umożliwiają aplikacjom (raz jawnie włączone przez użytkownika) otrzymywanie kopii wszystkich powiadomień w miarę ich publikowania lub aktualizacji. Implementacje urządzeń MUSZĄ poprawnie i bezzwłocznie wysyłać w całości powiadomienia do wszystkich zainstalowanych i włączonych przez użytkownika usług detektorów, w tym wszystkie metadane dołączone do obiektu Notification.

Implementacje urządzeń, które obsługują funkcję Nie przeszkadzać (Nie przeszkadzać) MUSZĄ spełniać te wymagania:

MUSI zaimplementować działanie, które będzie reagowało 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ć.
Jeśli implementacja urządzenia zapewnia użytkownikowi możliwość przyznania lub odmowy dostępu aplikacji innych firm do konfiguracji zasad Nie przeszkadzać, MUSI wyświetlić Automatyczne reguły Nie przeszkadzać utworzone przez aplikacje obok utworzonych przez użytkownika i wstępnie zdefiniowanych reguł.
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_EFFECT_SCREEN_ON, MUSI poinformować użytkownika o tym, że efekty wizualne zostały wyłączone w menu ustawień Nie przeszkadzać.

3.8.4 Szukaj

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. Implementacje urządzeń POWINNY być implementowanie interfejsów API, które umożliwiają programistom ponowne wykorzystywanie tego interfejsu użytkownika do prowadzenia wyszukiwania we własnych aplikacjach. Implementacje urządzeń, które implementują globalny interfejs wyszukiwania, MUSZĄ implementować interfejsy API, które pozwalają aplikacjom innych firm na dodawanie sugestii do pola wyszukiwania uruchomionego w trybie wyszukiwania globalnego. Jeśli nie zainstalowano żadnych aplikacji innych firm, które korzystają z tej funkcji, domyślnym działaniem POWINNY jest wyświetlanie wyników i sugestii wyszukiwarki internetowej.

Implementacje na urządzeniach z Androidem i Androida Automotive MUSZĄ wdrożyć na urządzeniu asystenta do obsługi działania wspomagającego.

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. Implementacje urządzeń obsługujące działanie wspomagające MUSZĄ wyraźnie informować użytkownika o tym, że kontekst jest udostępniany, przez wyświetlanie białego światła wokół krawędzi ekranu. Aby zapewnić wyraźną widoczność dla użytkownika, oznaczenie MUSI być zgodne z czasem trwania oraz jasnością określonego w projekcie Android Open Source Project.

3.8.5 Tosty

Aplikacje mogą używać interfejsu API „Toast” do wyświetlania użytkownikowi krótkich ciągów niemodalnych, które znikają po krótkim czasie. Implementacje urządzeń MUSZĄ wyświetlać użytkownikom powiadomienia z aplikacji w sposób dobrze widoczny.

3.8.6 Motywy

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

Android zawiera rodzinę motywów „Holo” w postaci zestawu stylów, z których mogą korzystać deweloperzy aplikacji, jeśli chcą dopasować wygląd i styl motywu Holo określone w pakiecie SDK Androida. Implementacje na urządzeniu NIE MOGĄ zmieniać żadnych atrybutów motywu Holo widocznych dla aplikacji.

Android obejmuje rodzinę motywów „Materiał” jako zestaw zdefiniowanych stylów, które mogą wykorzystać deweloperzy, jeśli chcą dopasować wygląd i działanie motywu graficznego do wyglądu i stylu różnych typów urządzeń z Androidem. Implementacje na urządzeniu MUSZĄ obsługiwać rodzinę motywów „Material” i NIE MOGĄ zmieniać żadnych atrybutów motywu Material Design, ani ich zasobów widocznych dla aplikacji.

Android zawiera także rodzinę motywów „Ustawienie domyślne urządzenia” jako zestaw zdefiniowanych stylów, które deweloperzy mogą wykorzystać, jeśli chcą dopasować wygląd i sposób działania motywu urządzenia określonego przez narzędzie do implementacji. Implementacje na urządzeniach MOGĄ zmodyfikować atrybuty domyślnego motywu urządzenia widoczne dla aplikacji.

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ń. Dlatego implementacje urządzeń z Androidem MUSZĄ używać białego koloru przy ikonach 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 wyświetlenie na jasnym pasku stanu za pomocą flagi SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Gdy aplikacja prosi o wyświetlenie paska stanu diody, implementacje urządzeń z Androidem MUSZĄ 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 urządzeń z możliwością niezawodnego wyświetlania animowanych tapet zgodnie z opisem powyżej POWINNY o wdrażać animowane tapety, a po wdrożeniu MUSI zgłosić flagę funkcji platformy android.software.live_wallpaper.

3.8.8 Przełączanie aktywności

Klawisz nawigacji w ostatniej funkcji jest OPCJONALNY, dlatego wymaganie wdrożenia ekranu Przegląd jest OPCJONALNE w przypadku implementacji na zegarkach z Androidem Watch i Android Automotive oraz ZALECANE na urządzeniach z Androidem TV. W Androidzie Automotive POWINNA istnieć metoda przełączania się między aktywnościami.

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Ą zmieniać interfejs, ale MUSZĄ spełniać te wymagania:

MUSI obsługiwać co najmniej 6 wyświetlanych działań.
NALEŻY wyświetlać przynajmniej tytuł 4 aktywności jednocześnie.
MUSI włączyć przypinanie ekranu i udostępnić użytkownikowi menu ustawień umożliwiające włączenie tej funkcji.
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
MOŻE wyświetlać ostatnie powiązane zdjęcia jako grupę poruszającą się razem.
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.

Zdecydowanie ZALECANE są wdrożenia na urządzeniach, z których będzie widoczny interfejs użytkownika na Androidzie (lub podobny interfejs oparty 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. Implementacje urządzeń, które pozwalają użytkownikom na używanie na urządzeniu metod wejściowych innych firm, MUSZĄ zadeklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy API IME zgodnie z definicją w dokumentacji pakietu Android SDK.

Implementacje urządzeń, które deklarują funkcję android.software.input_methods, MUSZĄ udostępniać dostępny dla użytkownika mechanizm dodawania i konfigurowania metod wprowadzania innych firm. Implementacje na urządzeniu MUSZĄ wyświetlać interfejs ustawień w odpowiedzi na intencję android.settings.INPUT_METHOD_SETTINGS.

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. Implementacje na urządzeniach, które obsługują ekran blokady, z wyjątkiem implementacji na urządzeniach z Androidem Automotive lub zegarkiem, MUSZĄ wyświetlać powiadomienia na ekranie blokady, w tym szablon powiadomień o multimediach.

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ądzenie jest wyposażone w czujnik sprzętowy (np. GPS), który może określać współrzędne lokalizacji, w menu Lokalizacja MUSZĄ być wyświetlane tryby lokalizacji.

3.8.13. Unicode i czcionka

Android obsługuje znaki emoji zdefiniowane w standardzie Unicode 9.0. Wszystkie implementacje urządzeń MUSZĄ renderować znaki emotikonów w kolorze glifu kolorów, a w przypadku implementacji na urządzeniach z Androidem edytor IME MUSI udostępniać metodę wprowadzania znaków.

Urządzenia mobilne z Androidem POWINNO obsługiwać odcień skóry i różnorodne emotikony rodzinne zgodnie z opisem w raporcie technicznym nr 51 Unicode.

Android zapewnia obsługę czcionki Roboto 2 o różnych wagach: sans-szeryfowa-cienka, bezszeryfowa-lekka, bezszeryfowa-średnia, bezszeryfowa-czarna, bezszeryfowa, bezszeryfowa, bezszeryfowa-skondensowana-lekka.

3.8.14. Wiele okien

Implementacja na urządzeniu MOŻE nie włączać żadnych trybów wielu okien, ale jeśli może wyświetlać wiele aktywności jednocześnie, MUSI je wdrożyć zgodnie z działaniem aplikacji i interfejsami API opisanymi w dokumentacji obsługi trybu wielu okien w pakiecie Android SDK oraz spełniać te wymagania:

Aplikacje mogą określać w pliku AndroidManifest.xml, czy mogą działać w trybie wielu okien, jawnie za pomocą atrybutu android:resizeableActivity lub domyślnie za pomocą atrybutu targetSdkVersion > 24. Aplikacje, w których w pliku manifestu ustawisz wartość tego atrybutu na „false”, NIE MOGĄ być uruchamiane w trybie wielu okien. Aplikacje, które nie mają ustawionego atrybutu w pliku manifestu (targetSdkVersion < 24), mogą zostać uruchomione w trybie wielu okien, ale system MUSI wyświetlać ostrzeżenie, że aplikacja może nie działać w tym trybie zgodnie z oczekiwaniami.
Implementacje na urządzeniach NIE MOGĄ udostępniać trybu podzielonego ekranu ani dowolnego trybu, jeśli wysokość i szerokość ekranu są mniejsze niż 440 dp.
Implementacje na urządzeniach o rozmiarze ekranu xlarge POWINNY obsługiwać tryb dowolny.
Implementacje urządzeń telewizyjnych na Androida MUSZĄ obsługiwać tryb wielu okien trybu obrazu w obrazie (PIP). Gdy tryb PIP jest włączony, ta funkcja powinna znajdować się w prawym górnym rogu.
Implementacje urządzeń z obsługą wielu okien w trybie PIP MUSZĄ przydzielić dla okna PIP co najmniej 240 x 135 dp.
Jeśli tryb wielu okien PIP jest obsługiwany, do sterowania oknem PIP MUSISZ używać klucza KeyEvent.KEYCODE_WINDOW. W przeciwnym razie klucz MUSI być dostępny dla działania na pierwszym planie.

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. Implementacje na urządzeniach MUSZĄ zawierać implementację klasy DevicePolicyManager. Implementacje urządzeń, które obsługują bezpieczny ekran blokady, MUSZĄ wdrożyć pełny zakres zasad administrowania urządzeniem zdefiniowanych w dokumentacji pakietu Android SDK i zgłaszać funkcję platformy android.software.device_admin.

3.9.1 Obsługa administracyjna urządzeń

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

Jeśli implementacja urządzenia deklaruje funkcję android.software.device_admin, MUSI wdrożyć obsługę aplikacji Właściciel urządzenia klienta Device Policy (DPC) w sposób opisany poniżej:

Jeśli w implementacji urządzenia nie skonfigurowano jeszcze danych użytkownika, oznacza to, że:
- MUSI zgłosić true za DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
- W odpowiedzi na działanie intencji android.app.action.PROVISION_MANAGED_DEVICE MUSI zarejestrować aplikację DPC jako aplikację właściciela urządzenia.
- Jeśli urządzenie deklaruje obsługę komunikacji Near-Field Communications (NFC) za pomocą flagi funkcji android.hardware.nfc i otrzymuje wiadomość NFC z rekordem z typem MIME MIME_TYPE_PROVISIONING_NFC, MUSI zarejestrować aplikację DPC jako właściciela urządzenia.
Gdy implementacja urządzenia ma dane użytkownika:
- MUSI zgłosić false za DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
- NIE MOŻE rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia.

Implementacje urządzeń MOGĄ mieć wstępnie zainstalowaną aplikację wykonującą funkcje administrowania urządzeniem, ale NIE MOŻE ona być ustawiona jako aplikacja właściciela urządzenia bez wyraźnej zgody użytkownika lub administratora urządzenia.

3.9.1.2 Obsługa administracyjna profili zarządzanych

Jeśli implementacja urządzenia deklaruje atrybut android.software.managed_users, MUSISZ mieć możliwość zarejestrowania aplikacji kontrolera zasad urządzeń (DPC) jako właściciela nowego profilu zarządzanego.

Proces obsługi administracyjnej profilu zarządzanego (proces zainicjowany przez android.app.action.PROVISION_MANAGED_PROFILE) MUSI być zgodny z implementacją AOSP.

Implementacje urządzeń MUSZĄ udostępniać w interfejsie Ustawień użytkownika podane niżej funkcje, aby poinformować użytkownika o wyłączeniu danej funkcji systemu 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

Urządzenia obsługujące profil zarządzany to urządzenia, które:

Zadeklaruj uprawnienie android.software.device_admin (zobacz sekcję 3.9 Administrowanie urządzeniem).
Nie są urządzeniami z małą ilością pamięci RAM (patrz sekcja 7.6.1).
Przydziel pamięć wewnętrzną (niewymienny) jako pamięć współdzieloną (zobacz sekcja 7.6.2).

Urządzenia obsługujące profil zarządzany MUSZĄ:

Zadeklaruj flagę funkcji platformy android.software.managed_users .
Obsługuj profile zarządzane za pomocą interfejsów API android.app.admin.DevicePolicyManager.
Zezwalaj na utworzenie tylko jednego profilu zarządzanego.
Użyj plakietki ikony (podobnej do plakietki „Praca nadrzędna AOSP”) do reprezentowania zarządzanych aplikacji i widżetów oraz innych elementów interfejsu z plakietką, takich jak Ostatnie i Powiadomienia.
Wyświetlaj ikonę powiadomień (podobną do plakietki służbowej AOSP), która informuje, że użytkownik korzysta z aplikacji profilu zarządzanego.
Wyświetlaj komunikat informujący o tym, że użytkownik jest w profilu zarządzanym, gdy urządzenie zostanie wybudzone (ACTION_USER_PRESENT), a aplikacja na pierwszym planie znajduje się w profilu zarządzanym.
Jeśli istnieje profil zarządzany, pokaż wizualną afordancję w sekcji „Wybór intencji” , aby umożliwić użytkownikowi przekazywanie intencji z profilu zarządzanego na użytkownika głównego lub na odwrót, jeśli funkcja jest włączona przez kontroler zasad dotyczących urządzeń.
Jeśli istnieje profil zarządzany, udostępnij następujące parametry użytkowników zarówno w przypadku 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.
Upewnij się, że wstępnie zainstalowane aplikacje telefonu, kontakty i komunikatory 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). 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 być opatrzone plakietką informującą o aplikacjach profilu zarządzanego.
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.
Obsługa możliwości określenia osobnego ekranu blokady spełniającego poniższe wymagania w celu przyznania dostępu 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.

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ą implementacje usługi ułatwień dostępu otrzymywanie wywołań zwrotnych dla zdarzeń użytkownika i zdarzeń systemowych oraz generują alternatywne mechanizmy informacji zwrotnych, takie jak zamiana tekstu na mowę, reakcje haptyczne czy nawigacja za pomocą trackballa lub pada kierunkowego.

Implementacje urządzeń obejmują te wymagania:

Implementacje w Androidzie Automotive POWINNY BYĆ spójna z implementacją ułatwień dostępu w Androidzie zgodną z domyślną implementacją Androida.
Implementacje na urządzeniach (z wyłączeniem Androida Automotive) MUSZĄ zapewniać implementację ułatwień dostępu na urządzeniach z Androidem zgodnie z domyślną implementacją.
Implementacje na urządzeniach (z wyłączeniem Androida Automotive) MUSZĄ obsługiwać implementacje usług ułatwień dostępu innych firm za pomocą interfejsów API android.accessibilityservice.
Implementacje na urządzeniach (z wyłączeniem Androida Automotive) MUSZĄ generować zdarzenia AccessibilityEvents i dostarczać te zdarzenia do wszystkich zarejestrowanych implementacji AccessibilityService w sposób zgodny z domyślną implementacją Androida.
Implementacje urządzeń (urządzenia z Androidem Automotive i zegarkami z Androidem bez wyjścia audio) MUSZĄ udostępniać dostępny dla użytkownika mechanizm włączania i wyłączania usług ułatwień dostępu oraz MUSI wyświetlać ten interfejs w odpowiedzi na intencję android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
Zdecydowanie ZALECANE są implementacje urządzeń z Androidem z wyjściem audio, jeśli chodzi o implementacje usług ułatwień dostępu na urządzeniu porównywalnym do funkcjonalności TalkBack** i usług ułatwień dostępu Switch Access (https://github.com/google/talkback).
Zegarki z Androidem Watch z wyjściem audio POWINNY być implementowane na urządzeniu usługi ułatwień dostępu porównywalne lub przewyższające funkcjonalność usługi ułatwień dostępu TalkBack (https://github.com/google/talkback).
Implementacje na urządzeniach POWINNY BYĆ WŁĄCZONY 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 wyświetlacza oraz gestów powiększenia.

** Dotyczy języków obsługiwanych przez zamianę tekstu na mowę.

Pamiętaj też, że jeśli dostępna jest wstępnie załadowana usługa ułatwień dostępu, MUSI być to aplikacja bezpośredniego rozruchu {directBootAware}, jeśli urządzenie szyfrowało pamięć urządzenia przy użyciu szyfrowania opartego na plikach (FBE).

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ę. Implementacje urządzeń zgłaszające funkcję android.hardware.audio.output MUSZĄ spełniać te wymagania związane z platformą TTS Androida.

Implementacje na Androida Automotive:

MUSI obsługiwać interfejsy API platformy TTS Androida.
MOŻE MOŻE obsługiwać instalację silników zamiany tekstu na mowę innych firm. Partnerzy MUSZĄ udostępniać dostępny dla użytkownika interfejs umożliwiający wybór mechanizmu zamiany tekstu na mowę do użycia na poziomie systemu, o ile jest on obsługiwany.

Pozostałe implementacje urządzeń:

MUSI obsługiwać interfejsy API platformy TTS Androida i POWINIEN zawierać mechanizm zamiany tekstu na mowę obsługującą języki dostępne na urządzeniu. Pamiętaj, że starsze oprogramowanie open source Androida zawiera pełną implementację mechanizmu zamiany tekstu na mowę.
MUSI obsługiwać instalację silników zamiany tekstu na mowę innych firm.
MUSI udostępniać dostępny dla użytkownika interfejs umożliwiający użytkownikom wybór mechanizmu 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. Implementacje urządzeń Android TV MUSZĄ obsługiwać platformę wejścia TV.

Implementacje urządzeń, które obsługują TIF, MUSZĄ zadeklarować funkcję platformy android.software.live_tv.

3.12.1. Aplikacja TV

Każde wdrożenie na urządzeniu z deklaracją obsługi funkcji Live TV MUSI mieć zainstalowaną aplikację TV. W ramach projektu Android Open Source w ramach projektu Android TV jest dostępna implementacja aplikacji telewizyjnej.

Aplikacja TV MUSI mieć możliwość instalacji i używania kanałów telewizyjnych oraz spełniać następujące wymagania:

Implementacje urządzeń MUSZĄ zezwalać na instalowanie 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 MOGĄ wyświetlać źródeł zewnętrznych w odległości więcej niż jednego działania nawigacji od aplikacji TV (tj. przez rozwijanie listy źródeł zewnętrznych w aplikacji TV).

3.12.1.1. Elektroniczny przewodnik po programach

Implementacje urządzeń Android TV MUSZĄ 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. Elektroniczny przewodnik po programach MUSI spełniać te wymagania:

elektroniczny przewodnik po programach MUSI wyświetlać informacje ze wszystkich zainstalowanych źródeł sygnału oraz źródeł zewnętrznych.
EPG MAY umożliwia wizualną różnicę między zainstalowanymi wejściami a wejściami innych firm.
ZAWSZE ZALECANE jest wyświetlanie w równym stopniu zainstalowanych źródeł wejściowych i wejścia innych firm. elektroniczny przewodnik po programach NIE MOŻE wyświetlać urządzeń wejściowych innych firm w odległości więcej niż jednego działania nawigacji od zainstalowanych źródeł EPG.
Przy zmianie kanału implementacje MUSZĄ wyświetlać dane EPG aktualnie odtwarzanego programu.

3.12.1.2. Nawigacja

Aplikacja TV MUSI umożliwiać korzystanie z tych funkcji za pomocą przycisków kierunkowych, Wstecz i Ekran główny na urządzeniach wejściowych urządzenia Android TV (tj. pilota, aplikacja pilota lub kontroler do gier):

Zmiana kanałów telewizyjnych
Otwieram elektroniczny przewodnik po programach
Konfigurowanie i dostrajanie zewnętrznych źródeł sygnału TIF
Otwieranie menu Ustawienia

Aplikacja TV POWINIEN przekazywać kluczowe zdarzenia do wejść HDMI przez CEC.

3.12.1.3 Łączenie aplikacji wejścia TV

Implementacje urządzeń Android TV MUSZĄ obsługiwać łączenie aplikacji do wprowadzania danych TV, co umożliwia przekazywanie linków do innych aktywności z bieżącej aktywności (np. do linków z programu na żywo do powiązanych treści). Aplikacja TV MUSI pokazywać połączenie aplikacji wejściowej TV, jeśli jest dostępna.

3.12.1.4. Przesunięcie w czasie

Implementacje na urządzeniach Android TV MUSZĄ obsługiwać przesunięcie w czasie, które umożliwia użytkownikowi wstrzymywanie i wznawianie transmisji na żywo. Implementacje na urządzeniu MUSZĄ umożliwiać użytkownikowi wstrzymanie i wznowienie odtwarzania aktualnie odtwarzanego programu, jeśli dostępne jest dla niego przesunięcie w czasie.

3.12.1.5. Nagranie telewizyjne

Zdecydowanie ZALECANE są implementacje urządzeń Android TV do obsługi nagrywania programów telewizyjnych. Jeśli wejście TV obsługuje nagrywanie, elektroniczny przewodnik po programach może umożliwiać nagranie programu, o ile nagrywanie takiego programu nie jest zabronione. Implementacje urządzeń POWINIEN mieć interfejs użytkownika do odtwarzania nagranych programów.

3.13. Szybkie ustawienia

Implementacje urządzeń z Androidem POWINNY zawierać komponent interfejsu Szybkich ustawień, który zapewnia szybki dostęp do często używanych lub pilnych działań.

Android zawiera interfejs API quicksettings, który umożliwia aplikacjom innych firm wdrażanie kafelków, które użytkownik może dodawać razem z kafelkami udostępnionymi przez system w komponencie interfejsu Szybkich ustawień. Jeśli implementacja urządzenia ma komponent interfejsu Szybkich ustawień,:

MUSI zezwalać użytkownikowi na dodawanie i usuwanie kafelków z aplikacji innej firmy w Szybkich ustawieniach.
NIE MOŻE automatycznie dodawać kafelka z aplikacji innej firmy bezpośrednio do Szybkich ustawień.
MUSI wyświetlać wszystkie dodane przez użytkowników kafelki z aplikacji innych firm razem z udostępnionymi przez system kafelkami szybkich ustawień.

3.14. Interfejsy API do UI w pojazdach

3.14.1. Interfejs multimediów w pojeździe

Każde wdrożenie na urządzeniu, które deklaruje obsługę motoryzacji MUSI zawierać platformę interfejsu do obsługi aplikacji innych firm korzystających z interfejsów API Media Browser i MediaSession.

Platforma interfejsu obsługująca aplikacje innych firm zależne od Media Browser i MediaSession ma te wymagania wizualne:

Ikony MediaItem i ikony powiadomień MUSZĄ wyświetlać w niezmienionej postaci.
MUSI wyświetlać te elementy w sposób opisany przez MediaSession, np. metadane, ikony, obrazy.
MUSI pokazywać tytuł aplikacji.
MUSI zawierać szufladę, aby przedstawić hierarchię Media Browser.

4. Zgodność pakietów aplikacji

Implementacje na urządzeniu MUSZĄ zainstalować i uruchomić pliki „.apk” Androida wygenerowane za pomocą narzędzia „aapt” zawartego w oficjalnym pakiecie SDK na Androida. Z tego powodu implementacje na urządzeniach POWINNY być używane przez system zarządzania pakietami implementacji referencyjnej.

Menedżer pakietów MUSI obsługiwać weryfikację plików „.apk” przy użyciu schematu podpisu plików APK w wersji 2 i podpisywania plików JAR.

Implementacje urządzeń NIE MOGĄ rozszerzać formatów .apk, pliku manifestu Androida, kodu bajtowego Dalvik ani RenderScriptu w taki sposób, aby uniemożliwiać prawidłowe instalowanie i działanie tych plików na innych zgodnych urządzeniach.

5. Zgodność multimediów

5.1. Kodeki multimediów

Implementacje na urządzeniach:

MUSI obsługiwać podstawowe formaty multimediów określone w dokumentacji pakietu Android SDK, z wyjątkiem sytuacji, które są jednoznacznie dozwolone w tym dokumencie.
MUSI obsługiwać formaty multimediów, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w tabelach poniżej i raportowane za pomocą MediaCodecList.
MUSI też mieć możliwość dekodowania wszystkich profili zgłoszonych w CamcorderProfile.
MUSI dekodować wszystkie formaty. Dotyczy to wszystkich strumieni bitowych generowanych przez kodery.

Kodeki POWINNY dążą do minimalnego opóźnienia kodeka, czyli kodeków,

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 tabeli poniżej zostały udostępnione jako implementacje oprogramowania w preferowanej implementacji na Androida pochodzącą z 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 typu open source lub „shareware”, wymagało licencji opatentowanych przez właścicieli odpowiednich patentów.

5.1.1 Kodeki audio

Format/kodek	za pomocą kodera.	Dekoder	Szczegóły	Obsługiwane typy plików/formaty kontenerów
Profil AAC MPEG-4 (AAC LC)	WYMAGANE¹	WYMAGANE	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, dekodowanie w Androidzie 3.1 lub nowszym, kodowanie w Androidzie 4.0 lub nowszym, format ADIF nie jest obsługiwany) MPEG-TS (.ts, brak możliwości przewijania, Android 3.0 lub nowszy)
Profil MPEG-4 HE AAC (AAC+)	WYMAGANE¹ (Android 4.1 lub nowszy)	WYMAGANE	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 (rozszerzony AAC+)		WYMAGANE	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)	WYMAGANE¹ (Android 4.1 lub nowszy)	WYMAGANE (Android 4.1 lub nowszy)	Obsługa treści mono/stereo ze standardowymi częstotliwościami próbkowania od 16 do 48 kHz.
AMR-NB	WYMAGANE³	WYMAGANE³	4,75–12,2 kb/s, próbkowanie przy 8 kHz	3GPP (.3GPP)
AMR-WB	WYMAGANE³	WYMAGANE³	9 częstotliwości od 6,60 kb/s do 23,85 kb/s, próbkowanie przy 16 kHz
FLAC		WYMAGANE (Android 3.1 lub nowszy)	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 odświeżania 48–44,1 kHz nie zawiera filtra dolnoprzepustowego. 16-bitowa RECOMMENDED; nie zastosowano trybu 24-bitowego.	Tylko FLAC (.flac)
MP3		WYMAGANE	Stała szybkość transmisji bitów mono/Stereo 8–320 kb/s (CBR) lub zmienna szybkość transmisji bitów (VBR)	MP3 (.mp3)
MIDI		WYMAGANE	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		WYMAGANE		Ogg (.ogg) Matroska (.mkv, Android 4.0 lub nowszy)
PCM/WAVE	WYMAGANE⁴ (Android 4.1 lub nowszy)	WYMAGANE	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		WYMAGANE (Android 5.0 lub nowszy)		matroska (.mkv), Ogg(.ogg)

1 Wymagany w przypadku implementacji na urządzeniach, które definiują android.hardware.microphone, ale opcjonalne w przypadku implementacji na zegarkach z Androidem Watch.

2 Nagrywanie lub odtwarzanie MOŻE być wykonywane w trybie mono lub stereo, ale dekodowanie buforów wejściowych AAC strumieni wielokanałowych (tzn. więcej niż 2 kanałów) do PCM za pomocą domyślnego dekodera dźwięku AAC w interfejsie android.media.MediaCodec API, MUSI być obsługiwane:

dekodowanie jest wykonywane bez miksowania (np. strumień AAC 5.0 musi być zdekodowany na 5 kanałów PCM, a strumień AAC 5.1 – na 6 kanałów PCM),
metadane zakresu dynamicznego, zgodnie z definicją w dokumencie „Dynamic Range Control (DRC)”. w normie ISO/IEC 14496-3 i kluczach DRC android.media.MediaFormat, które pozwalają skonfigurować działanie dekodera dźwięku związane z zakresem dynamicznym 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

3 Wymagany w przypadku implementacji na urządzeniach mobilnych z Androidem.

4 Wymagane w przypadku implementacji na urządzeniach, które definiują android.hardware.microphone, w tym implementacji na zegarkach z Androidem Watch.

5.1.2 Kodeki obrazów

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

5.1.3 Kodeki wideo

Obsługa profilu HDR reklamującego kodeki MUSI obsługiwać analizę i obsługę statycznych metadanych HDR.
Jeśli kodek multimediów reklamuje obsługę wewnętrznego odświeżania, MUSI obsługiwać okresy odświeżania wynoszące 10–60 klatek i musi działać dokładnie w zakresie 20% skonfigurowanego okresu odświeżania.
Kodeki wideo MUSZĄ obsługiwać rozmiary wyjściowego i wejściowego bufora bajtowego zgodne z największą możliwą dopuszczalną skompresowaną i nieskompresowaną klatką zgodnie ze standardem i konfiguracją, ale nie w ogóle.
Kodery i dekodery wideo MUSZĄ obsługiwać elastyczny format kolorów YUV420 (color_FormatYUV420Elastyczne).

Format/kodek	za pomocą kodera.	Dekoder	Szczegóły	Obsługiwane typy plików/ Formaty kontenerów
H.263	MAJ	MAJ		3GPP (.3GPP) MPEG-4 (MP4)
H.264 AVC	WYMAGANE²	WYMAGANE²	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		WYMAGANE⁵	Więcej informacji znajdziesz w sekcji 5.3.	MPEG-4 (MP4)
MPEG-2		Zdecydowanie ZALECANE⁶	Profil główny	MPEG2-TS
MPEG-4 SP		WYMAGANE²		3GPP (.3GPP)
VP8 ³	WYMAGANE² (Android 4.3 lub nowszy)	WYMAGANE² (Android 2.3.3 lub nowszy)	Szczegółowe informacje znajdziesz w sekcjach 5.2 i 5.3.	WebM (.webm) Matroska (.mkv, Android 4.0 lub nowszy)⁴
VP9		WYMAGANE² (Android 4.4 lub nowszy)	Więcej informacji znajdziesz w sekcji 5.3.	WebM (.webm) Matroska (.mkv, Android 4.0 lub nowszy)⁴

1 Wymagany w przypadku implementacji urządzeń, które obejmują sprzęt z aparatem i definiują android.hardware.camera lub android.hardware.camera.front.

2 Wymagany w przypadku implementacji na urządzeniach z wyjątkiem Android Watch.

3 Aby zapewnić akceptowalną jakość strumieniowych transmisji wideo w internecie i usług do wideokonferencji, w implementacjach urządzeń MUSISZ używać sprzętowego kodeka VP8 spełniającego wymagania.

4 Implementacje na urządzeniach POWINNY obsługiwać zapisywanie plików Matroska WebM.

5 ZALECANE w przypadku Androida Automotive, opcjonalne w przypadku Android Watch i wymagane w przypadku wszystkich innych typów urządzeń.

6 Dotyczy to tylko implementacji na urządzeniach z Android TV.

5.2. Kodowanie wideo

W przypadku implementacji na zegarkach z Androidem Watch kodeki wideo są opcjonalne.

Kodery wideo H.264, VP8, VP9 i HEVC:

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.

Koder wideo H.263 i MPEG-4 POWINNY obsługiwać dynamicznie konfigurowane szybkości transmisji bitów.

Wszystkie kodery wideo MUSZĄ spełniać następujące wymagania dotyczące szybkości transmisji bitów w dwóch oknach przesuwnych:

Wartość nie powinna przekraczać 15% szybkości transmisji bitów między interwałami wewnątrzklatki (I-frame).
Szybkość transmisji bitów nie może przekraczać 100% w przesuwanym oknie wynoszącym 1 sekundę.

5.2.1 H.263

Implementacje na urządzeniach z Androidem z koderami H.263 MUSZĄ obsługiwać profil podstawowy poziomu 45.

5.2.2 H-264

Implementacje na urządzeniach z Androidem z obsługą kodeka H.264:

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.
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.
Ponadto Zdecydowanie ZALECANE są urządzenia Android TV do kodowania filmów HD 1080p przy 30 kl./s.

	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

1 Obsługiwany przez sprzęt, ale Zdecydowanie ZALECANY w przypadku urządzeń Android TV.

5.2.3 VP8

Implementacje urządzeń z Androidem z obsługą kodeka VP8 MUSZĄ obsługiwać profile kodowania wideo SD i MUSZĄ obsługiwać poniższe profile kodowania wideo HD (High Definition).

	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

1 Gdy jest obsługiwany przez sprzęt.

5.3. Dekodowanie wideo

W przypadku implementacji na zegarkach z Androidem Watch kodeki wideo są opcjonalne.

Implementacje na urządzeniach:

MUSI obsługiwać dynamiczną rozdzielczość filmów i przełączanie liczby klatek przy użyciu standardowych interfejsów API Androida w tym samym strumieniu w przypadku wszystkich kodeków VP8, VP9, H.264 i H.265 w czasie rzeczywistym i z maksymalną rozdzielczością obsługiwaną przez każdy kodek na urządzeniu.
Implementacje, które obsługują dekoder Dolby Vision:
MUSI udostępnić moduł wyodrębniający z obsługą Dolby Vision.
MUSI prawidłowo wyświetlać treści Dolby Vision na ekranie urządzenia lub na standardowym porcie wyjściowym wideo (np. HDMI).
Implementacje, które umożliwiają wyodrębnianie z obsługą Dolby Vision, MUSZĄ ustawiać 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

Implementacje urządzeń z Androidem z dekoderami MPEG-2 muszą obsługiwać wysoki poziom profilu głównego.

5.3.2 H.263

Implementacje na urządzeniach z Androidem z dekoderami H.263 MUSZĄ obsługiwać profil Baseline na poziomie 30 i 45.

5.3.3 MPEG-4

Implementacje na urządzeniach z Androidem z dekoderami MPEG-4 MUSZĄ obsługiwać prosty profil poziomu 3.

5.3.4 H.264

Implementacje na urządzeniach z Androidem z dekoderami H.264:

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.
MUSI mieć możliwość dekodowania filmów za pomocą profili SD (standardowej rozdzielczości) wymienionych w tabeli poniżej i zakodowanych za pomocą 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.
Ponadto urządzenia Android TV:
- MUSI obsługiwać profil High Profile Level 4.2 oraz profil dekodowania HD 1080p60.
- MUSI mieć możliwość dekodowania filmów za pomocą obu profili HD, zgodnie z informacjami w poniższej tabeli, oraz być kodowanych za pomocą profilu podstawowego, głównego lub wysokiego na poziomie 4.2.

	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²)
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

1 WYMAGANE, gdy wysokość raportowana przez metodę Display.getSupportedModes() jest równa lub większa od rozdzielczości wideo.

2 WYMAGANE w przypadku implementacji na urządzeniach Android TV.

5.3.5 H.265 (HEVC)

Implementacje na urządzeniach z Androidem obsługujących kodek H.265 zgodnie z opisem w sekcji 5.1.3:

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.
W przypadku dekodera sprzętowego MUSI obsługiwać profile dekodowania HD, zgodnie z informacjami w tej tabeli.
Ponadto urządzenia Android TV:
MUSI obsługiwać profil dekodowania HD 720p.
Zdecydowanie zalecana obsługa profilu dekodowania HD 1080p. Jeśli profil dekodowania HD 1080p jest obsługiwany, MUSI obsługiwać profil główny na poziomie 4.1.
MUSI obsługiwać profil dekodowania UHD. Jeśli profil dekodowania UHD jest obsługiwany, kodek MUSI obsługiwać profil główny poziomu 5 (Main10 Level 5).

	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 kl./s (60 kl./s¹)	60 kl./s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

1 WYMAGANE w przypadku implementacji urządzeń Android TV z dekodowaniem sprzętowym H.265.

5.3.6 VP8

Implementacje na urządzeniach z Androidem obsługujących kodek VP8 zgodnie z opisem w sekcji 5.1.3:

MUSI obsługiwać profile dekodowania SD z poniższej tabeli.
MUSI obsługiwać profile dekodowania HD z poniższej tabeli.
Urządzenia telewizyjne z Androidem MUSZĄ obsługiwać profil dekodowania HD 1080p60.

	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²)	30 (60 kl./s²)
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

1 WYMAGANE, gdy wysokość raportowana przez metodę Display.getSupportedModes() jest równa lub większa od rozdzielczości wideo.

2 WYMAGANE w przypadku implementacji na urządzeniach Android TV.

5.3.7 VP9

Implementacje na urządzeniach z Androidem obsługujących kodek VP9 zgodnie z opisem w sekcji 5.1.3:

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 jest dekoder sprzętowy, MUSI obsługiwać profile dekodowania HD, zgodnie z informacjami w tej tabeli.
Ponadto urządzenia Android TV:
- MUSI obsługiwać profil dekodowania HD 720p.
- Zdecydowanie zalecana obsługa profilu dekodowania HD 1080p.
- MUSI obsługiwać profil dekodowania UHD. Jeśli profil dekodowania wideo UHD jest obsługiwany, MUSI obsługiwać 8-bitową głębię kolorów i Profil 2 (10-bitowy).

	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¹)	60 kl./s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

1 WYMAGANE w przypadku implementacji urządzeń Android TV ze sprzętowym dekodowaniem formatu VP9.

5.4. Nagrywanie dźwięku

Chociaż od wersji Androida 4.3 niektóre z wymagań opisanych w tej sekcji są określone jako POWINNY, planujemy zmienić definicję zgodności w przyszłej wersji na MUSZĄ. Zdecydowanie ZALECANE są zarówno istniejące, jak i nowe urządzenia z Androidem, które spełniają te wymagania – w przeciwnym razie nie będą mogły uzyskać zgodności z Androidem po uaktualnieniu do przyszłej wersji.

5.4.1 Przechwytywanie nieprzetworzonego dźwięku

Implementacje urządzeń z zadeklarowaniem android.hardware.microphone MUSZĄ umożliwiać przechwytywanie surowych treści audio o tych cechach:

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

Przechwytywanie powyżej częstotliwości próbkowania MUSI być rejestrowane bez próbkowania w górę, a zmniejszanie MUSI zawierać odpowiedni filtr antyaliasingowy.

Implementacje urządzeń z zadeklarowaniem android.hardware.microphone MUSZĄ umożliwiać przechwytywanie surowych treści audio o tych cechach:

Format : linearny PCM, 16-bitowy
Częstotliwość próbkowania : 22 050, 48 000
Kanały : stereo

Jeśli przechwytywanie odbywa się z użyciem powyższych częstotliwości, MUSI być przechwytywany bez konieczności zwiększania próbkowania przy współczynnikach większych niż 16 000:22050 lub 44100:48000. Wszelkie próbkowanie w górę lub w dół MUSI zawierać odpowiedni filtr antyaliasing.

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

Źródło dźwięku android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION MUSI obsługiwać przechwytywanie przy częstotliwości próbkowania – 44 100 lub 48 000.

Oprócz powyższych specyfikacji dotyczących nagrywania, gdy aplikacja rozpoczęła nagrywanie strumienia audio przy użyciu źródła dźwięku android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

Urządzenie POWINNO wykazywać około płaską amplitudę w odniesieniu do częstotliwości: ±3 dB, od 100 Hz do 4000 Hz.
Czułość wejścia audio POWINNA być ustawiona tak, aby źródło mocy akustycznej o wartości 90 dB (SPL) o częstotliwości 1000 Hz dawało RMS 2500 dla próbek 16-bitowych.
Poziomy amplitudy PCM POWINNY liniowo śledzić zmiany poziomu SPL na wejściu w zakresie co najmniej 30 dB od -18 dB do +12 dB re 90 dB SPL dla mikrofonu.
Całkowite zniekształcenie harmoniczne POWINIEN być mniejsze niż 1% dla 1 kHz przy poziomie sygnału wejściowego SPL mikrofonu 90 dB.
Przetwarzanie redukcji szumów MUSI być wyłączone, jeśli jest dostępne.
Automatyczna kontrola wzmocnienia MUSI być wyłączona, jeśli jest dostępna.

Jeśli platforma obsługuje technologie wyciszania szumów dostrojone pod kątem rozpoznawania mowy, efekt MUSI być sterowany przy użyciu interfejsu android.media.audiofx.NoiseSuppressor API. Ponadto pole UUID deskryptora efektów tłumienia szumu MUSI jednoznacznie identyfikować każdą implementację technologii eliminowania szumu.

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. Na urządzeniach z deklaracją parametru android.hardware.audio.output MUSZĄ prawidłowo implementować źródło dźwięku REMOTE_SUBMIX, aby aplikacja, która nagrywa za pomocą interfejsu android.media.AudioRecord API z tego źródła dźwięku, mogła rejestrować kombinację wszystkich strumieni audio z wyjątkiem tych:

PIERŚCIENI_TRANSMISJI
STRUMIEŃ_ALARM
POWIADOMIENIE_TRANSMISJI

5.5. Odtwarzanie dźwięku

Implementacje urządzeń z deklaracją android.hardware.audio.output MUSZĄ spełniać wymagania opisane w tej sekcji.

5.5.1. Odtwarzanie surowego dźwięku

Urządzenie MUSI umożliwiać odtwarzanie nieprzetworzonej treści audio o następujących cechach:

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

Urządzenie POWINNO obsługiwać 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. Implementacje urządzeń z zadeklarowaną funkcją android.hardware.audio.output:

MUSI obsługiwać implementacje EFFECT_TYPE_EQUALIZER i EFFECT_TYPE_LOUDNESS_ENHANCER sterowane za pomocą podklasy AudioEffect, Equalizer, LoudnessIncreaser.
MUSI obsługiwać implementację interfejsu Visualizer API, którą można sterować za pomocą klasy Visualizer.
POWINNY jest obsługiwać implementacje EFFECT_TYPE_BASS_BOOST, Effect_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB i cost_TYPE_VIRTUALIZER, które można kontrolować za pomocą podklasy AudioEffect: BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.

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

Implementacje urządzeń z Android TV MUSZĄ obsługiwać system główny głośności oraz wyciszać cyfrowe wyjścia audio na obsługiwanych wyjściach, z wyjątkiem skompresowanego przelotowego wyjścia audio (gdzie na urządzeniu nie jest wykonywane dekodowanie dźwięku).

Implementacje na urządzeniach z Androidem Automotive POWINIEN zezwalać na regulację głośności dźwięku oddzielnie dla każdego strumienia audio z użyciem typu lub użycia treści określonego w Atrybutach Audio oraz wykorzystania sprzętu audio w samochodzie zgodnie z publicznie zdefiniowanym w 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óźnienie 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 otoczeniu za pomocą przetwornika lub sygnału urządzenia na urządzeniu i możliwości obserwacji na zewnątrz.
opóźnienie „na zimno” . Opóźnienie wyjścia dla pierwszej klatki, gdy system wyjściowy audio był bezczynny i wyłączony przed żądaniem.
opóźnienie ciągłego sygnału wyjściowego . Opóźnienie wyjściowe kolejnych klatek po odtworzeniu dźwięku na urządzeniu.
opóźnienie 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.
utracone dane . Początkowa część sygnału wejściowego, który jest bezużyteczny lub niedostępny.
opóźnienie „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.
opóźnienie ciągłego sygnału wejściowego . Opóźnienie sygnału wejściowego dla kolejnych klatek, gdy urządzenie rejestruje dźwięk.
zakłócenia przy zimnym działaniu . Zmienność między osobnymi pomiarami wartości czasu oczekiwania na zimne wyjście.
zakłócenia związane z zimnym źródłem sygnału . 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 OpenSL ES API związanych z PCM w Androidzie NDK.

Zdecydowanie ZALECANE są wdrożenia urządzeń z deklaracją android.hardware.audio.output, aby spełnić lub przewyższyć te wymagania dotyczące wyjścia audio:

czas oczekiwania „na zimno” nie może przekraczać 100 milisekund
ciągłe opóźnienie wyjściowe wynoszące maksymalnie 45 milisekund
zminimalizuj zakłócenia na zimno

Jeśli po przeprowadzeniu wstępnej kalibracji i używaniu interfejsu API kolejki buforowej OpenSL ES PCM wdrożenie urządzenia spełnia wymagania wymienione w tej sekcji, to ze względu na ciągłe opóźnienie wyjścia i opóźnienie „na zimno” w przypadku co najmniej jednego obsługiwanego urządzenia wyjściowego audio Zdecydowanie ZALECANE jest zgłoszenie obsługi dźwięku z małym opóźnieniem przez zgłoszenie funkcji android.hardware.audio.low_latency przy użyciu interfejsu android.content.audio.low_latency przy użyciu interfejsu android.content.audio.low_latency. Jeśli natomiast implementacja urządzenia nie spełnia tych wymagań, NIE MOŻE zgłaszać obsługi dźwięku z małym opóźnieniem.

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

opóźnienie sygnału wejściowego „na zimno” wynoszący maksymalnie 100 milisekund
opóźnienie ciągłego sygnału wejściowego wynoszące 30 milisekund lub mniej
ciągłe opóźnienie w obie strony wynoszące maksymalnie 50 milisekund
zminimalizuj zakłócenia w działaniu urządzenia „na zimno”

5.7. Protokoły sieciowe

Urządzenia MUSZĄ obsługiwać protokoły sieci multimedialnej do odtwarzania dźwięku i wideo zgodnie z opisem w dokumentacji pakietu Android SDK. W szczególności urządzenia MUSZĄ obsługiwać następujące protokoły sieci medialnych:

strumieniowanie progresywne HTTP(S)
Wszystkie wymagane kodeki i formaty kontenerów opisane w sekcji 5.1 MUSZĄ być obsługiwane przez HTTP(S)
Protokół HTTP Transmisja na żywo w wersji roboczej, wersja 7
Te formaty segmentów MUSZĄ być obsługiwane:

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 na temat H264 AVC i MPEG2-4 SP znajdziesz w sekcji 5.1.3. i MPEG-2. 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

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 na temat H264 AVC i MPEG2-4 SP znajdziesz w sekcji 5.1.3.
i MPEG-2.

Kodeki audio:

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

RTSP (RTP, SDP)

Ten profil audio-wideo RTP i powiązane kodeki MUSZĄ być obsługiwane. Informacje o wyjątkach znajdziesz w przypisach w sekcji 5.1.

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

Implementacje urządzeń, które obsługują bezpieczne wyjście wideo i obsługują bezpieczne platformy, MUSZĄ zadeklarować obsługę Display.FLAG_SECURE. Jeśli urządzenia zadeklarują obsługę protokołu Display.FLAG_SECURE, jeśli obsługują protokół wyświetlania bezprzewodowego, MUSZĄ zabezpieczyć połączenie za pomocą silnego kryptograficznego mechanizmu, np. HDCP 2.x lub nowszego w przypadku wyświetlaczy bezprzewodowych Miracast. Podobnie, jeśli urządzenia obsługują przewodowy wyświetlacz zewnętrzny, implementacje urządzeń MUSZĄ obsługiwać standard HDCP 1.2 lub nowszy. Implementacje urządzeń telewizji z Androidem MUSZĄ obsługiwać standard HDCP 2.2 w przypadku urządzeń obsługujących rozdzielczość 4K oraz HDCP 1.4 lub nowsze w przypadku niższej rozdzielczości. Implementacja open source Androida obejmuje obsługę wyświetlaczy bezprzewodowych (Miracast) i przewodowych (HDMI), które spełniają to wymaganie.

5.9. Interfejs MIDI (Musical Instrument Digital Interface)

Jeśli implementacja urządzenia obsługuje transport oprogramowania MIDI (wirtualne urządzenia MIDI) i obsługuje MIDI w przypadku wszystkich wymienionych poniżej transportów sprzętowych obsługujących MIDI, dla których zapewnia ono ogólne połączenia inne niż MIDI, Zdecydowanie ZALECANE jest zgłoszenie obsługi funkcji android.software.midi za pomocą klasy android.content.pm.PackageManager.

Transport sprzętowy obsługujący MIDI to:

Tryb hosta USB (sekcja 7.7 USB)
Tryb urządzenia peryferyjnego USB (sekcja 7.7 USB)
MIDI przez Bluetooth LE odgrywa główną rolę (sekcja 7.4.3 Bluetooth)

Jeśli natomiast implementacja urządzenia zapewnia ogólne połączenie inne niż MIDI przez określony powyżej transport sprzętowy obsługujący MIDI, ale nie obsługuje MIDI przez ten transport sprzętowy, NIE MOŻE zgłaszać obsługi funkcji android.software.midi.

5.10. Profesjonalne treści audio

Jeśli implementacja urządzenia spełnia wszystkie te wymagania, Zdecydowanie ZALECANE jest zgłoszenie obsługi funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager.

Implementacja na urządzeniu MUSI zgłaszać obsługę funkcji android.hardware.audio.low_latency.
Ciągłe opóźnienie dźwięku w obie strony, określone w sekcji 5.6 Opóźnienie dźwięku, MUSI wynosić nie więcej niż 20 milisekund oraz 10 milisekund w przypadku co najmniej jednej obsługiwanej ścieżki.
Jeśli urządzenie jest wyposażone w 4-kanałowe gniazdo słuchawek 3, 5 mm, ciągłe opóźnienie dźwięku w obie strony MUSI wynosić nie więcej niż 20 ms na ścieżkę audio i 10 milisekund lub mniej na ścieżce audio.
Implementacja urządzenia MUSI zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
Tryb hosta USB MUSI obsługiwać klasę audio USB.
Jeśli urządzenie jest wyposażone w port HDMI, implementacja MUSI obsługiwać wyjście stereo i 8 kanałów z głębią kolorów 20- lub 24-bitową i 192 kHz bez utraty głębi bitowej i ponownego próbkowania.
Implementacja na urządzeniu MUSI zgłaszać obsługę funkcji android.software.midi.
Jeśli urządzenie jest wyposażone w 4-kanałowe gniazdo słuchawek 3,5 mm, ZALECANE jest wdrożenie urządzenia zgodnego z sekcją Specyfikacja urządzenia mobilnego (gniazdo słuchawek) w specyfikacji przewodowego zestawu słuchawkowego audio (wersja 1.1).

Opóźnienia i wymagania dotyczące dźwięku USB MUSZĄ być spełnione przy użyciu interfejsu API kolejki buforowej PCM OpenSL ES.

Ponadto implementacja urządzenia, która zgłasza obsługę tej funkcji, POWINIEN:

Zapewnij stabilną wydajność procesora przy włączonym dźwięku.
Zminimalizuj dokładność zegara audio i odchylenia w stosunku do czasu standardowego.
Zminimalizuj dryf zegara audio w odniesieniu do CPU CLOCK_MONOTONIC, gdy obie te wartości są aktywne.
Zminimalizuj opóźnienie dźwięku z przetworników na urządzeniu.
Minimalizuj opóźnienie dźwięku podczas korzystania z cyfrowego dźwięku USB.
Dokumentowanie pomiarów opóźnienia dźwięku na wszystkich ścieżkach.
Zminimalizuj zakłócenia podczas włączania wywołań zwrotnych uzupełniania bufora audio, ponieważ wpływa to na procent wykorzystania pełnej przepustowości procesora przez wywołanie zwrotne.
Zapewniają zerowe przerwy w działaniu dźwięku (wyjściowe) lub przeloty (wejście) podczas normalnego użytkowania z raportowanym opóźnieniem.
Nie ma różnicy w opóźnieniach między kanałami.
Minimalizuj średni czas oczekiwania MIDI podczas wszystkich transmisji.
Minimalizuj zmienność czasu oczekiwania MIDI podczas wczytywania (zakłócenia) we wszystkich transmisjach.
Podawaj dokładne sygnatury czasowe MIDI we wszystkich transmisjach.
Zminimalizuj szum sygnału dźwiękowego generowanego przez przetworniki urządzenia, również w okresie bezpośrednio po uruchomieniu „na zimno”.
Zadbaj o zerową różnicę zegara audio między wejściem a wyjściem 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.
Obsługuj 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 wprowadź 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.
Zminimalizuj różnicę fazową między buforowaniem dźwięku HAL po stronie wejścia i wyjścia odpowiednich punktów końcowych.
Zminimalizuj opóźnienie dotyku.
Minimalizuj zmienność czasu oczekiwania na wczytanie (zakłócenia).

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

W Androidzie 7.0 dodaliśmy nowe źródło nagrywania. Można uzyskać do niego dostęp za pomocą źródła dźwięku android.media.MediaRecorder.AudioSource.UNPROCESSED. W OpenSL ES można uzyskać dostęp za pomocą gotowego ustawienia rekordów SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Aby zgłosić obsługę nieprzetworzonego źródła dźwięku za pomocą właściwości android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED, urządzenie MUSI spełniać wszystkie te wymagania:

Urządzenie MUSI wykazywać mniej więcej płaską amplitudę w porównaniu z częstotliwością w średnim zakresie częstotliwości: ±10 dB od 100 do 7000 Hz.
Urządzenie MUSI wykazywać amplitudę w niskim zakresie: od ±20 dB od 5 Hz do 100 Hz w porównaniu ze średnim zakresem częstotliwości.
Urządzenie MUSI wykazywać amplitudę w zakresie wysokich częstotliwości: od ±30 dB od 7000 Hz do 22 kHz w porównaniu ze średnim zakresem częstotliwości.
Czułość wejścia audio MUSI być ustawiona 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 w pełnej skali w przypadku próbek zmiennoprzecinkowych lub podwójnej precyzji).
SNR > 60 dB (różnica między 94 dB SPL a równoważnym SPL własnym szumem, ważonym A).
Całkowite zniekształcenie harmoniczne MUSI być mniejsze niż 1% dla 1 kHZ przy poziomie sygnału wejściowego SPL mikrofonu 90 dB.
Jedynym przetwarzaniem sygnałów dozwolonym na ścieżce jest mnożnik poziomu umożliwiający uzyskanie pożądanego zakresu. Ten mnożnik poziomu NIE MOŻE wywoływać opóźnienia ani opóźnienia na ścieżce sygnału.
Na ścieżce nie jest dozwolone żadne inne przetwarzanie sygnałów, takie jak automatyczna kontrola wzmocnienia, filtr górnoprzepustowy czy anulowanie echa. Jeśli z jakiegoś powodu w architekturze obecne jest przetwarzanie sygnału, MUSI zostać ono wyłączone i w efekcie powodować zero opóźnienia lub dodatkowe 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.

Zdecydowanie ZALECANE jest, by urządzenie spełniało jak najwięcej wymagań dotyczących ścieżki sygnału dla nieprzetworzonego źródła nagrania. jednak urządzenie musi spełniać wszystkie te wymagania, jeśli ma obsługiwać nieprzetworzone źródło dźwięku.

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

6.1. Narzędzia dla programistów

Implementacje na urządzeniu MUSZĄ obsługiwać narzędzia Android Developer Tools dostarczane w pakiecie Android SDK. Urządzenia zgodne z Androidem MUSZĄ być zgodne z:

Android Debug Bridge (adb)
- Implementacje na urządzeniach MUSZĄ obsługiwać wszystkie funkcje adb zgodnie z dokumentacją pakietu Android SDK, w tym dumpsys.
- 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 Android Debug Bridge. Jeśli urządzenie pomija tryb peryferyjny USB, MUSI wdrożyć Android Debug Bridge przez sieć lokalną (np. Ethernet lub 802.11).
- Android zapewnia obsługę bezpiecznego pliku adb. Bezpieczny adb włącza narzędzie adb na znanych uwierzytelnionych hostach. Implementacje na urządzeniach MUSZĄ obsługiwać bezpieczne narzędzie adb.
Usługa monitorowania debugowania Dalvik (ddms)
- Implementacje na urządzeniach MUSZĄ obsługiwać wszystkie funkcje DDMS zgodnie z dokumentacją w pakiecie SDK na Androida.
- Ponieważ pakiet ddms używa narzędzia adb, obsługa ddms powinna być domyślnie nieaktywna, ale MUSI być obsługiwana za każdym razem, gdy użytkownik aktywuje Android Debug Bridge (jak powyżej).
Monkey Implementacje urządzeń MUSZĄ zawierać platformę Monkey i udostępniać ją aplikacjom.
SysTrace,
- Implementacje na urządzeniach MUSZĄ 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.
- Większość systemów Linux i Apple Macintosh rozpoznaje urządzenia z Androidem za pomocą standardowych narzędzi Android SDK, bez dodatkowej obsługi. ale systemy Microsoft Windows zazwyczaj wymagają sterownika dla nowych urządzeń z Androidem. (Na przykład nowe identyfikatory dostawców, a czasem nowe identyfikatory urządzeń wymagają niestandardowych sterowników USB dla systemów Windows).
- Jeśli narzędzie adb nie rozpozna implementacji urządzenia w sposób podany w standardowym pakiecie SDK Androida, narzędzia implementujące urządzenia MUSZĄ dostarczyć sterowniki systemu Windows umożliwiające programistom połączenie się z urządzeniem przy użyciu protokołu adb. Te sterowniki MUSZĄ być udostępnione dla systemów Windows XP, Windows Vista, Windows 7, Windows 8 i Windows 10 zarówno w wersji 32-bitowej, jak i 64-bitowej.

6.2. Opcje programisty

Android zapewnia programistom możliwość konfigurowania ustawień związanych z programowaniem aplikacji. Implementacje na urządzeniach MUSZĄ być zgodne z intencją android.settings.APPLICATION_DEVELOPMENT_SETTINGS w celu wyświetlania ustawień związanych z programowaniem. Nadrzędna implementacja Androida ukrywa menu Opcje programisty domyślnie i umożliwia użytkownikom uruchamianie Opcji programisty po naciśnięciu 7 (7) razy w sekcji Ustawienia > Informacje o urządzeniu > Pozycja menu Numer kompilacji. Implementacje na urządzeniach MUSZĄ zapewniać spójny interfejs Opcji programisty. W szczególności implementacje urządzeń MUSZĄ domyślnie ukrywać Opcje programisty i MUSZĄ udostępniać mechanizm włączania Opcji programisty zgodny z wcześniejszą implementacją Androida.

Implementacje na Androida Automotive MOGĄ ograniczać dostęp do menu Opcje programisty przez wizualne ukrywanie lub wyłączenie menu, gdy pojazd jest w ruchu.

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

Pełne definicje klas (zgodnie z dokumentacją w pakiecie SDK) dla interfejsów API komponentu MUSZĄ być nadal przedstawiane.
Działanie interfejsu API MUSI zostać wdrożone w jakiś rozsądny sposób jako brak działań.
Metody interfejsu API MUSZĄ zwracać wartości null tam, gdzie jest to dozwolone w dokumentacji pakietu SDK.
Metody interfejsu API MUSZĄ zwracać implementacje klas bezobsługowych, przy których wartości null są niedozwolone w dokumentacji pakietu SDK.
Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, których nie opisano w dokumentacji pakietu SDK.

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.

Implementacje urządzeń MUSZĄ spójnie zgłaszać dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager w przypadku tego samego odcisku cyfrowego kompilacji.

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.
punkty na cal (dpi) Liczba pikseli nałożonych na liniową, poziomą lub pionową rozpiętość 1 cali”. Jeśli podane są wartości dpi, wartość dpi 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

Zegarki z Androidem Watch (opisane w sekcji 2) MOGĄ mieć mniejsze ekrany (jak opisano w tej sekcji).

Interfejs Androida obsługuje różne rozmiary ekranów i umożliwia aplikacjom wysyłanie zapytań o rozmiar ekranu urządzenia (tzw. „układ ekranu”) za pomocą metody android.content.res.Configuration.screenLayout z użyciem komponentu SCREENLAYOUT_SIZE_MASK. Implementacje na urządzeniu MUSZĄ zgłaszać prawidłowy rozmiar ekranu określony w dokumentacji pakietu Android SDK i określony przez źródłową platformę Androida. Implementacje urządzeń MUSZĄ zgłaszać odpowiedni rozmiar ekranu zgodnie z następującymi wymiarami ekranu niezależnego od gęstości logicznej (dp).

Ekran urządzenia MUSI mieć co najmniej 426 dp x 320 dp („mały”), chyba że jest to zegarek Android Watch.
Urządzenia, które zgłaszają rozmiar ekranu jako „normalny”, MUSZĄ mieć rozdzielczość co najmniej 480 dp x 320 dp.
Urządzenia zgłaszające rozmiar ekranu „duży” MUSZĄ mieć co najmniej 640 dp x 480 dp.
Urządzenia zgłaszające rozmiar ekranu „xduży” MUSZĄ mieć wymiary co najmniej 960 dp x 720 dp.

Ponadto:

Zegarki z Androidem MUSZĄ mieć ekran o przekątnej ekranu z zakresu od 1,1 do 2,5 cala.
Urządzenia z Androidem Automotive MUSZĄ mieć ekran o przekątnej co najmniej 6 cali.
Urządzenia z Androidem Automotive MUSZĄ mieć ekran o wymiarach co najmniej 750 dp x 480 dp.
Inne implementacje urządzeń z Androidem, z fizycznie zintegrowanym ekranem, MUSZĄ mieć ekran o przekątnej co najmniej 2,5 cala.

Urządzeń NIE MOŻNA w żadnym momencie zmieniać zgłaszanego rozmiaru ekranu.

Aplikacje opcjonalnie wskazują obsługiwane rozmiary ekranów za pomocą parametru <supports-screen> w pliku AndroidManifest.xml. Implementacje na urządzeniach MUSZĄ poprawnie spełniać warunki stwierdzono, że obsługiwane są małe, zwykłe, duże i bardzo duże ekrany, zgodnie z opisem w dokumentacji pakietu SDK na Androida.

7.1.1.2. Współczynnik proporcji ekranu

Chociaż nie ma ograniczeń co do wartości współczynnika proporcji fizycznego wyświetlacza ekranu, współczynnik proporcji powierzchni, na której są renderowane aplikacje innych firm, i które można ustalić na podstawie wartości raportowanych za pomocą DisplayMetrics MUSI spełniać te wymagania:

Jeśli tryb uiMode jest skonfigurowany jako UI_MODE_TYPE_WATCH, format obrazu MOŻE zostać ustawiony na 1,0 (1:1).
Jeśli aplikacja innej firmy informuje, że można zmienić jej rozmiar za pomocą atrybutu android:resizeableActivity, nie ma żadnych ograniczeń dotyczących wartości współczynnika proporcji.
We wszystkich innych przypadkach współczynnik proporcji MUSI mieć wartość z zakresu od 1,3333 (4:3) do 1,86 (około 16:9), chyba że aplikacja wyraźnie poinformuje, że obsługuje wyższy współczynnik proporcji ekranu za pomocą wartości metadanych maxAspectRatio.

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. Implementacje urządzeń MUSZĄ zgłaszać za pomocą interfejsów android.util.DisplayMetrics interfejsy API android.util.DisplayMetrics tylko jedną z poniższych gęstości logicznych. NIE MOGĄ też w każdej chwili zmieniać wartości dla domyślnego wyświetlacza.

120 dpi (ldpi)
160 dpi (mdpi)
213 dpi (tvdpi)
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (Xhdpi)
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.

Zdecydowanie ZALECANE są implementacje urządzeń, w których użytkownicy mają możliwość zmiany rozmiaru wyświetlacza. Jeśli występuje implementacja zmiany rozmiaru wyświetlacza urządzenia, MUSI być zgodna z implementacją AOSP zgodnie z poniższym opisem:

Rozmiar wyświetlacza NIE MOŻE być skalowany jako 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.
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

Implementacje na urządzeniach MUSZĄ podawać prawidłowe wartości wszystkich danych o wyświetlaniu zdefiniowanych w android.util.DisplayMetrics i MUSZĄ podawać te same wartości niezależnie od tego, czy jako wyświetlacz domyślny jest ustawiony ekran osadzony, czy zewnętrzny.

7.1.3 Orientacja ekranu

Urządzenia MUSZĄ zgłaszać obsługiwane orientacje ekranu (android.hardware.screen.portrait lub android.hardware.screen.landscape) i MUSZĄ zgłaszać co najmniej jedną obsługiwaną orientację. Na przykład w przypadku urządzenia ze stałą orientacją poziomą, np. telewizora lub laptopa, MUSISZ zgłosić tylko parametr android.hardware.screen.landscape.

Urządzenia, które zgłaszają obie orientacje ekranu, MUSZĄ obsługiwać orientację dynamiczną przez aplikacje w orientacji pionowej lub poziomej. Oznacza to, że urządzenie musi uwzględniać żądanie aplikacji dotyczące określonej orientacji ekranu. Implementacje na urządzeniach MOGĄ domyślnie wybrać orientację pionową lub poziomą.

Urządzenia MUSZĄ zgłaszać prawidłową wartość w 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.

Podczas zmiany orientacji urządzeń NIE MOŻESZ zmieniać zgłaszanego rozmiaru ani gęstości ekranu.

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

Implementacje na urządzeniach MUSZĄ obsługiwać zarówno standard OpenGL ES 1.0, jak i 2.0, zgodnie z dokumentacją pakietu Android SDK. Implementacje urządzeń MUSZĄ obsługiwać standard OpenGL ES 3.0, 3.1 lub 3.2 na urządzeniach, które go obsługują. Implementacje na urządzeniach MUSZĄ też obsługiwać protokół Android RenderScript, zgodnie z informacjami podanymi w dokumentacji pakietu Android SDK.

Implementacje urządzenia MUSZĄ także poprawnie identyfikować się z obsługą OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, OpenGL 3.1 lub OpenGL 3.2. To oznacza, że

Zarządzane interfejsy API (na przykład korzystające z metody GLES10.getString()) MUSZĄ zgłaszać obsługę interfejsów OpenGL ES 1.0 i OpenGL ES 2.0.
Natywne interfejsy API C/C++ OpenGL (interfejsy API dostępne dla aplikacji przez libGLES_v1CM.so, libGLES_v2.so lub libEGL.so) MUSZĄ zgłaszać obsługę interfejsów OpenGL ES 1.0 i OpenGL ES 2.0.
Implementacje urządzeń, które zadeklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2 MUSZĄ obsługiwać odpowiednie zarządzane interfejsy API i obsługiwać natywne interfejsy API C/C++. W przypadku implementacji, które deklarują obsługę standardu OpenGL ES 3.0, 3.1 lub 3.2 libGLESv2.2, oprócz symboli funkcji OpenGL ES 2.0 MUSISZ wyeksportować odpowiednie symbole funkcji.

Android zapewnia pakiet rozszerzeń OpenGL ES z interfejsami Java i natywną obsługą zaawansowanych funkcji graficznych, takich jak tessellation i format kompresji tekstur ASTC. Implementacje na urządzeniach z Androidem MUSZĄ obsługiwać pakiet rozszerzeń, jeśli urządzenie obsługuje standard OpenGL ES 3.2 i MOŻE obsługiwać go w innych przypadkach. Jeśli pakiet rozszerzeń jest obsługiwany w całości, urządzenie MUSI je identyfikować za pomocą flagi funkcji android.hardware.opengles.aep.

Ponadto implementacje na urządzeniach MOGĄ wdrożyć dowolne rozszerzenia OpenGL ES. Jednak implementacje urządzeń MUSZĄ raportować przez zarządzane i natywne interfejsy API OpenGL ES wszystkie obsługiwane ciągi rozszerzeń i odwrotnie NIE MOGĄ zgłaszać ciągów rozszerzeń, które nie są obsługiwane.

Pamiętaj, że Android obsługuje aplikacje, które mogą opcjonalnie określić, że wymagają one określonych formatów kompresji tekstury OpenGL. Te formaty są zwykle zależne od dostawcy. Android nie musi wdrażać na urządzeniach żadnych konkretnych formatów kompresji tekstur. Należy jednak dokładnie zgłaszać wszystkie obsługiwane formaty kompresji tekstur, korzystając z metody getString() w interfejsie OpenGL API.

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 urządzeń MUSZĄ domyślnie włączyć akcelerację sprzętową i MUSZĄ ją wyłączyć, jeśli deweloper o to poprosi, ustawiając parametr android:hardwareAccelerated="false" lub wyłączając akcelerację sprzętową bezpośrednio w interfejsach Android View API.

Dodatkowo implementacja urządzeń 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. Implementacje na urządzeniach MUSZĄ obsługiwać interfejs TextureView API i MUSZĄ zachowywać spójność z wcześniejszą implementacją Androida.

Android obsługuje EGL_ANDROID_RECORDABLE, czyli atrybut EGLConfig, który wskazuje, czy EGLConfig obsługuje renderowanie na urządzeniu ANativeWindow, który rejestruje obrazy w filmie. Implementacje na urządzeniach MUSZĄ obsługiwać rozszerzenie EGL_ANDROID_RECORDABLE.

7.1.5 Tryb zgodności starszych aplikacji

Android określa „tryb zgodności”, w którym platforma działa w „normalnym” trybu odpowiadającego rozmiarowi ekranu (szerokości 320 dp) – z korzyścią dla starszych aplikacji nieopracowanych na potrzeby starszych wersji Androida, które wcześniej były niezależne od rozmiarów ekranu.

Android Automotive nie obsługuje starszego trybu zgodności.
Wszystkie pozostałe implementacje urządzeń MUSZĄ obsługiwać starszy tryb zgodności aplikacji, który został zaimplementowany przez wcześniejszy kod 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.

7.1.6 Technologia ekranu

Platforma Androida zawiera interfejsy API, które umożliwiają 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.

Urządzenia MUSZĄ obsługiwać wyświetlacze z obsługą 16-bitowej grafiki w kolorze i POWINNY obsługiwać wyświetlacze z 24-bitową grafiką w kolorze.
Urządzenia MUSZĄ obsługiwać wyświetlacze obsługujące wyświetlanie animacji.
Używana technologia wyświetlania MUSI mieć współczynnik proporcji piksela (PAR) z zakresu 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 urządzenie obsługuje zewnętrzny wyświetlacz za pomocą połączenia przewodowego, bezprzewodowego lub zewnętrznego wyświetlacza, w implementacji MUSISZ zaimplementować interfejs Display Manager API zgodnie z dokumentacją pakietu Android SDK.

7.2. Urządzenia wejściowe

Urządzenia MUSZĄ obsługiwać ekran dotykowy lub spełniać wymagania wymienione w sekcji 7.2.2 w przypadku nawigacji bezdotykowej.

7.2.1. Klawiatura

Implementacje w Android Watch i Androidzie Automotive MOGĄ zawierać klawiaturę programową. We wszystkich innych implementacjach urządzeń MUSISZ zaimplementować klawiaturę programową oraz:

Implementacje na urządzeniach:

MUSI zawierać obsługę platformy zarządzania danymi wejściowymi (umożliwiającej zewnętrznym programistom tworzenie edytorów metody wprowadzania – np. klawiatury programowej) – zgodnie z opisem na stronie http://developer.android.com.
MUSI obsługiwać co najmniej jedną klawiaturę programową (niezależnie od tego, czy jest zainstalowana klawiatura twarda), z wyjątkiem urządzeń z Androidem Watch, na których rozmiar ekranu sprawia, że korzystanie z klawiatury programowej jest mniej rozsądne.
MOŻE obejmować dodatkowe implementacje klawiatury programowej.
MOŻE zawierać klawiaturę sprzętową.
NIE MOŻE zawierać klawiatury sprzętowej w formacie niezgodnym z formatem android.content.res.Configuration.keyboard (QWERTY lub 12-klawiszowy).

7.2.2 Nawigacja bezdotykowa

Urządzenia telewizyjne z Androidem MUSZĄ obsługiwać pad kierunkowy.

Implementacje na urządzeniach:

MOGĄ pominąć opcje nawigacji bezdotykowej (kulka, pad kierunkowy lub kółko), jeśli urządzeniem nie jest Android TV.
MUSI zgłosić prawidłową wartość parametru android.content.res.Configuration.navigation.
MUSI zapewniać uzasadniony alternatywny mechanizm interfejsu 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

Wymagania dotyczące dostępności i widoczności funkcji Dom, Ostatnie i Wstecz różnią się w zależności od typu urządzenia, co opisano w tej sekcji.

Funkcje Home, Ostatnie i Wstecz (zmapowane na kluczowe zdarzenia KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK) są niezbędne dla paradygmatu nawigacji Androida, więc:

Implementacje na przenośne urządzenia z Androidem MUSZĄ udostępniać funkcje ekranu głównego, ostatnich i Wstecz.
Telewizory z Androidem muszą obsługiwać funkcje ekranu głównego i Wstecz.
Na urządzeniach z Androidem Watch MUSI być dostępna funkcja ekranu głównego oraz funkcja Wstecz (z wyjątkiem sytuacji, gdy funkcja UI_MODE_TYPE_WATCH jest ustawiona).
Implementacje na urządzeniach Android Watch i żadne inne typy urządzeń z Androidem MOGĄ przetworzyć zdarzenie przytrzymania w kluczowym zdarzeniu KEYCODE_BACK i pominąć je przed wysłaniem do aplikacji na pierwszym planie.
Implementacje na Androidzie Automotive MUSZĄ zawierać funkcję ekranu głównego, a MOGĄ umożliwiać korzystanie z funkcji Wstecz i Ostatnie.
Pozostałe implementacje urządzeń MUSZĄ udostępniać funkcje ekranu głównego i Wstecz.

Te funkcje MOGĄ obsługiwać za pomocą specjalnych przycisków fizycznych (takich jak mechaniczne lub pojemnościowe przyciski dotykowe). MOGĄ również być implementowane za pomocą specjalnych klawiszy oprogramowania w oddzielnej części ekranu, gestów, panelu dotykowego itp. Android obsługuje obie te metody. Wszystkie te funkcje MUSZĄ być dostępne w ramach pojedynczej czynności (np. kliknięcia, dwukrotnego kliknięcia lub gestu), gdy są widoczne.

Funkcja Ostatnie, jeśli jest dostępna, MUSI mieć widoczny przycisk lub ikonę, chyba że jest ukryta razem z innymi funkcjami nawigacji w trybie pełnoekranowym. Nie dotyczy to urządzeń, które przechodzą z wcześniejszych wersji Androida na aktualizacje, które mają fizyczne przyciski nawigacji i nie mają klucza ostatnich.

Każda z tych funkcji MUSI mieć widoczny przycisk lub ikonę, chyba że są one ukryte razem z innymi funkcjami nawigacji w trybie pełnoekranowym lub gdy interfejs uiMode UI_MODE_TYPE_MASK ma wartość UI_MODE_TYPE_WATCH.

W Androidzie 4.0 funkcja menu została wycofana i zastąpiona paskiem działań. Dlatego nowe urządzenia wdrażające Androida w wersji 7.0 i nowszych NIE MOGĄ zawierać osobnego fizycznego przycisku do obsługi menu. Starsze implementacje urządzeń NIE NALEŻY wdrażać dedykowanego fizycznego przycisku do obsługi funkcji Menu, ale jeśli fizyczny przycisk Menu jest zaimplementowany, a na urządzeniu są uruchomione aplikacje z targetSdkVersion > 10, implementacja urządzenia:

MUSI wyświetlać na pasku działań przycisk rozszerzonego menu czynności, gdy jest widoczny, a powstałe w ten sposób wyskakujące menu nie jest puste. ZALECANE jest to w przypadku implementacji na urządzeniach sprzed wersji Androida 4.4, ale aktualizacji do Androida 7.0.
NIE MOŻE zmieniać pozycji wyświetlanego wyskakującego okienka działania przez wybranie odpowiedniego przycisku na pasku działań.
MOGĄ wyrenderować wyskakujące okienko rozszerzone działania w zmodyfikowanym miejscu na ekranie, gdy jest ono wyświetlane po kliknięciu fizycznego przycisku menu.

Aby zapewnić zgodność wsteczną, implementacje urządzeń MUSZĄ udostępnić funkcję Menu aplikacjom, gdy wartość targetSdkVersion wynosi mniej niż 10 przy użyciu fizycznego przycisku, klawisza oprogramowania lub gestów. Ta funkcja menu powinna być prezentowana, chyba że jest ukryta razem z innymi funkcjami nawigacyjnymi.

Implementacje urządzeń z Androidem, które obsługują działanie wspomagające lub VoiceInteractionService, MUSZĄ uruchamiać aplikację asystującą za pomocą pojedynczej interakcji (np. kliknięcia, dwukrotnego kliknięcia lub gestu), gdy widoczne są inne klawisze nawigacyjne. Zdecydowanie ZALECANE jest przytrzymanie przycisku ekranu głównego jako tej interakcji. Wyznaczona interakcja MUSI uruchamiać wybraną przez użytkownika aplikację asystującą, czyli aplikację implementującą VoiceInteractionService lub działanie obsługujące intencję ACTION_ASSIST.

Implementacje na urządzeniu MOGĄ wykorzystać odrębną część ekranu do wyświetlania klawiszy nawigacyjnych, ale jeśli tak, MUSZĄ spełniać te wymagania:

Klawisze nawigacyjne implementacji urządzenia MUSZĄ zajmować wyraźną część ekranu, niedostępne dla aplikacji i NIE MOGĄ zasłaniać części ekranu dostępnej dla aplikacji ani w inny sposób zakłócać jej działania.
Implementacje urządzenia MUSZĄ udostępnić część wyświetlacza aplikacjom spełniającym wymagania określone w sekcji 7.1.1.
Implementacje urządzeń MUSZĄ wyświetlać klawisze nawigacyjne, gdy aplikacje nie określają trybu interfejsu systemu ani nie określają SYSTEM_UI_FLAG_VISIBLE.
Implementacje na urządzeniu MUSZĄ wyświetlać klawisze nawigacyjne w dyskretnym trybie „niskim profilem” (np. przyciemnionym), gdy aplikacje mają określony profil SYSTEM_UI_FLAG_LOW_PROFILE.
Implementacje urządzeń MUSZĄ ukryć klawisze nawigacyjne, gdy aplikacje mają określony element SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4 Wprowadzanie tekstu z ekranu dotykowego

Zegarki i telefony z Androidem MUSZĄ obsługiwać wprowadzanie z ekranu dotykowego.

Urządzenia MUSZĄ być wyposażone w system wprowadzania danych za pomocą wskaźnika (typu mysz lub dotyk). Jeśli jednak implementacja urządzenia nie obsługuje systemu wprowadzania danych wskaźnika, NIE MOŻE zgłaszać stałej funkcji android.hardware.touchscreen ani android.hardware.faketouch. Implementacje urządzeń, które zawierają system wprowadzania danych wskaźnika:

POWINNY jest obsługiwać w pełni niezależnie śledzone wskaźniki, jeśli system wejściowy urządzenia obsługuje wiele wskaźników.
MUSI zgłosić wartość android.content.res.Configuration.touchscreen o typie konkretnego ekranu dotykowego na urządzeniu.

Android obsługuje różne ekrany dotykowe, pady dotykowe i fałszywe dotykowe urządzenia wejściowe. 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. Fałszywy interfejs dotykowy stanowi natomiast system wprowadzania danych użytkownika, który w przybliżeniu udostępnia niektóre funkcje 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. Implementacje urządzeń, w których deklarowane są fałszywe funkcje dotykowe, MUSZĄ spełniać wymagania dotyczące fałszywego dotyku opisane w sekcji 7.2.5.

Implementacje na urządzeniu MUSZĄ zgłaszać właściwą funkcję odpowiadającą typowi używanego urządzenia. Implementacje urządzeń obejmujące ekran dotykowy (jedno dotknięcie lub lepsze) MUSZĄ zgłaszać stały dostęp do funkcji platformy android.hardware.touchscreen. Implementacje urządzeń, które zgłaszają stałą funkcję platformy android.hardware.touchscreen MUSZĄ także podawać stałą android.hardware.faketouch. Implementacje urządzeń, które nie zawierają ekranu dotykowego (i są oparte wyłącznie na urządzeniu wskaźnika), NIE MOGĄ zgłaszać żadnych funkcji takich ekranów. MUSZĄ zgłaszać tylko android.hardware.faketouch, jeśli spełniają wymagania dotyczące fałszywego dotyku opisane w sekcji 7.2.5.

7.2.5 Wprowadzanie tekstu fałszywego dotykiem

Implementacje urządzeń z deklaracją obsługi android.hardware.faketouch:

MUSI podawać bezwzględne położenie ekranu na osi X i Y oraz wyświetlać wskaźnik wizualny na ekranie.
MUSI zgłaszać zdarzenie dotknięcia za pomocą kodu działania, który określa zmianę stanu, która zachodzi, gdy wskaźnik przesuwa się w dół lub w górę na ekranie.
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.
MUSI obsługiwać wskaźnik w dół, wskaźnik w górę i w dół, a następnie wskazujący w górę to samo miejsce na obiekcie na ekranie w ramach określonego progu czasowego. Umożliwia to użytkownikom emulację dwukrotnego kliknięcia obiektu na ekranie.
MUSI obsługiwać kursor w dół w wybranym punkcie na ekranie. Wskaźnik przesuwa się do dowolnego innego punktu na ekranie, a potem powinien przechodzić w górę, co pozwala emulować przeciąganie dotykiem.
MUSI obsługiwać wskaźnik w dół, a następnie umożliwiać użytkownikom szybkie przenoszenie obiektu w inne miejsce na ekranie oraz wskazanie go w górę, co umożliwia przesuwanie obiektu na ekranie.

Urządzenia deklarujące obsługę technologii android.hardware.faketouch.multitouch.distinct MUSZĄ spełniać podane wyżej wymagania dotyczące fałszywego dotyku i MUSZĄ obsługiwać odrębne śledzenie co najmniej 2 niezależnych wejść wskaźnika.

7.2.6 Obsługa kontrolera gier

Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać mapowanie przycisków na kontrolerach do gier, jak opisano poniżej. Implementacja Androida obejmuje wdrożenie na kontrolery gier, które spełniają to wymaganie.

7.2.6.1 Mapowania przycisków

Implementacje urządzeń Android TV MUSZĄ obsługiwać następujące mapowania klawiszy:

Przycisk	Wykorzystanie HID²	Przycisk Androida
A ¹	0x09 0x0001	KEYCODE_PRZYCISK_A (96)
MLD ¹	0x09 0x0002	KEYCODE_PRZYCISK_B (97)
X ¹	0x09 0x0004	KEYCODE_PRZYCISK_X (99)
T ¹	0x09 0x0005	KEYCODE_PRZYCISK_Y (100)
Górny pad kierunkowy ¹ Pad kierunkowy w dół ¹	0x01 0x0039 ³	AXIS_HAT_Y ⁴
Pad kierunkowy w lewo 1 Pad kierunkowy w prawo ¹	0x01 0x0039 ³	AXIS_HAT_X ⁴
Przycisk na lewym ramieniu ¹	0x09 0x0007	KEYCODE_Button_L1 (102)
Przycisk na prawym ramieniu ¹	0x09 0x0008	KEYCODE_PRZYCISK_R1 (103)
Kliknięcie lewym drążkiem ¹	0x09 0x000E	KEYCODE_button_THUMBL (106)
Kliknięcie prawym przyciskiem myszy ¹	0x09 0x000F	KEYCODE_button_THUMBR (107)
Strona główna ¹	0x0c 0x0223	KEYCODE_HOME (3)
Wstecz ¹	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 zarówno klawiszy strzałek w górę, jak i w lewo.

4 MotionEvent

Elementy sterujące analogowe ¹	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_Z

1 MotionEvent

7.2.7 Pilot

Urządzenia Android TV POWINNY być wyposażone w pilota umożliwiający dostęp do interfejsu telewizora. Pilot MOŻE być fizycznym pilotem lub może być programowym pilotem, z którego można korzystać na telefonie komórkowym lub tablecie. Pilot MUSI spełniać wymagania określone poniżej.

Afordancja w sieci wyszukiwania Implementacje urządzenia MUSZĄ uruchamiać polecenie KEYCODE_SEARCH, gdy użytkownik wywoła wyszukiwanie głosowe na pilocie fizycznym lub programowym.
Nawigacja Wszystkie piloty do telewizorów z Androidem MUSZĄ zawierać przyciski Wstecz, Ekran główny i Wybierz oraz obsługiwać zdarzenia za pomocą pada kierunkowego.

7.3. Czujniki

Android zawiera interfejsy API umożliwiające dostęp do różnych typów czujników. Implementacje urządzeń mogą zwykle pomijać te czujniki, jak opisano w kolejnych podpunktach. Jeśli urządzenie jest wyposażone w czujnik określonego typu, który ma odpowiedni interfejs API dla programistów zewnętrznych, implementacja urządzenia MUSI ją zaimplementować w sposób opisany w dokumentacji pakietu Android SDK i w dokumentacji Androida Open Source dotyczącej czujników. Przykłady implementacji na urządzeniach:

MUSI dokładnie zgłaszać obecność lub brak czujników za pomocą klasy android.content.pm.PackageManager.
MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() i podobnych.
W przypadku wszystkich innych interfejsów API czujników MUSI zachowywać się rozsądnie (na przykład przez zwracanie odpowiednio wartości „prawda” lub „fałsz”, gdy aplikacje próbują rejestrować detektory, lub niewywoływanie detektorów, gdy odpowiednie czujniki nie są dostępne itp.).
MUSI raportować wszystkie pomiary z czujników, używając odpowiednich wartości międzynarodowych systemów jednostkowych (danych) dla każdego typu czujnika zgodnie z opisem w dokumentacji pakietu Android SDK.
MUSISZ 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.
MUSI zgłaszać dane z czujnika z maksymalnym opóźnieniem 100 milisekund + 2 * sample_time w przypadku przesyłania strumieniowego 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.
MUSI zgłosić pierwszą próbkę czujnika w ciągu 400 milisekund + 2 * czas parametru sample_time czujnika. W przypadku tej próby można mieć dokładność 0.

Powyższa lista nie jest wyczerpująca. udokumentowane działanie pakietu Android SDK i dokumentacji Androida Open Source dotyczące czujników jest uznawane za miarodajne.

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 urządzeń POWINNY być implementowane w tych typach czujników, jeśli zawierają wymagane czujniki fizyczne opisane w sekcji Typy czujników. Jeśli urządzenie zawiera czujnik kompozytowy, MUSI go zaimplementować w sposób opisany w dokumentacji Androida Open Source dotyczącej czujników złożonych.

Niektóre czujniki Androida obsługują „ciągły” tryb wyzwalania, który stale zwraca dane. Aby interfejs API wskazano w dokumentacji pakietu Android SDK jako czujnik ciągły, implementacje urządzeń MUSZĄ stale dostarczać okresowe próbki danych, w których zakłócenia są zdefiniowane jako odchylenie standardowe między kolejnymi zdarzeniami.

Pamiętaj, że implementacje urządzenia MUSZĄ mieć pewność, że strumień zdarzeń z czujnika NIE MOŻE zapobiegać przechodzeniu procesora w stan zawieszenia lub wybudzeniem procesora ze stanu zawieszenia.

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

7.3.1 Akcelerometr

Wdrożenia urządzeń POWINIEN zawierać 3-osiowy akcelerometr. ZALECANE są dodanie tego czujnika na przenośne urządzenia z Androidem, implementacje systemu Android Automotive i urządzenia z Androidem Watch. Jeśli urządzenie ma 3-osiowy akcelerometr:

MUSI zaimplementować i zgłosić czujnik TYPE_ACCELEROMETER.
MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz w przypadku zegarków Android Watch, ponieważ urządzenia te mają bardziej rygorystyczne ograniczenia zasilania i 100 Hz w przypadku pozostałych typów urządzeń.
POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.
MUSI być zgodna z układem współrzędnych czujnika Androida zgodnie z opisem w interfejsach API Androida. Implementacje na Androida Automotive MUSZĄ być zgodne z systemem współrzędnych samochodowych Androida.
MUSI być w stanie mierzyć od swobodnego spadania do 4-krotności grawitacji (4g) lub większej na dowolnej osi.
Rozdzielczość MUSI mieć co najmniej 12 bitów, a rozdzielczość 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.
Odchylenie standardowe MUSI mieć wartość nie większą niż 0,05 m/s^, przy czym odchylenie standardowe należy obliczać na podstawie każdej osi dla próbek zebranych w okresie co najmniej 3 sekund z największą częstotliwością próbkowania.
POWINIEN zaimplementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER zgodnie z opisem w dokumentacji pakietu Android SDK. W przypadku dotychczasowych i nowych urządzeń z Androidem Zdecydowanie ZALECANE jest wdrożenie czujnika kompozytowego TYPE_SIGNIFICANT_MOTION. Gdy zamontowany jest którykolwiek z tych czujników, suma ich zużycia energii musi zawsze wynosić mniej niż 4 mW, a w przypadku urządzeń dynamicznych lub statycznych 0,5 mW, a każdy powinien być mniejszy niż 2 mW.
Jeśli dołączony jest czujnik żyroskopowy, MUSISZ zaimplementować czujniki kompozytowe TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION oraz czujnik kompozytowy TYPE_GAME_ROTATION_VECTOR. Zdecydowanie ZALECANE jest zastosowanie czujnika TYPE_GAME_ROTATION_VECTOR na dotychczasowych i nowych urządzeniach z Androidem.
Jeśli dołączony jest też żyroskop i czujnik magnetometru, MUSISZ wdrożyć czujnik kompozytowy TYPE_ROTATION_VECTOR.

7.3.2 Magnetometr

Urządzenie POWINIEN zawierać 3-osiowy magnetometr (kompas). Jeśli urządzenie ma 3-osiowy magnetometr:

NALEŻY zaimplementować czujnik TYPE_MAGNETIC_FIELD oraz czujnik TYPE_MAGNETIC_FIELD_UNCALIBRATED. Zdecydowanie ZALECANE jest wdrożenie czujnika TYPE_MAGNETIC_FIELD_UNCALIBRATED na dotychczasowych i nowych urządzeniach z Androidem.
MUSI raportować zdarzenia z częstotliwością co najmniej 10 Hz i POWINNY zgłaszać zdarzenia z częstotliwością co najmniej 50 Hz.
MUSI być zgodna z układem współrzędnych czujnika Androida zgodnie z opisem w interfejsach API Androida.
Przed nasyceniem funkcja MUSI być w stanie zmierzyć wartość od -900 μT do +900 μT na każdej osi.
Musi mieć wartość przesunięcia twardego żelaza na poziomie mniejszą niż 700 μT oraz wartość poniżej 200 μT przez umieszczenie magnetometru z dala od dynamicznych (wywoływanych prądem) i statycznych (wywołanych przez magnesu) pól magnetycznych.
Musi mieć rozdzielczość równą lub większą niż 0,6 μT oraz większą niż 0,2 μT.
POWINNA być kompensowana temperatura.
MUSI obsługiwać kalibrację online i kompensację twardego odchylenia oraz zachowywać parametry kompensacji między restartami urządzenia.
TRZEBA zastosować kompensację miękkiego żelaza – kalibrację można przeprowadzić podczas używania lub produkcji urządzenia.
Odchylenie standardowe powinno być obliczane na podstawie poszczególnych osi na podstawie próbek zebranych w okresie co najmniej 3 sekund z najszybszą częstotliwością próbkowania, nie większą niż 0, 5 μT.
Jeśli dołączony jest czujnik akcelerometru i czujnik żyroskopowy, MUSI zastosować czujnik kompozytowy TYPE_ROTATION_VECTOR.
MOŻE zostać zastosowany czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR, jeśli został również wdrożony czujnik przyspieszeniomierza. Jeśli jednak jest zaimplementowany, MUSI zużywać mniej niż 10 mW i POTRZEBA zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie wsadowym z częstotliwością 10 Hz.

7.3.3 GPS

Urządzenia POWINIEN zawierać odbiornik GPS/GNSS. Jeśli implementacja urządzenia obejmuje odbiornik GPS/GNSS i poinformuje o tym aplikacje, użyj flagi funkcji android.hardware.location.gps:

Zdecydowanie ZALECANE jest, aby urządzenie nadal wysyłało do aplikacji normalne dane wyjściowe GPS/GNSS podczas połączeń alarmowych, a dane o lokalizacji nie były blokowane podczas połączeń alarmowych.
MUSI obsługiwać dane wyjściowe lokalizacji z częstotliwością co najmniej 1 Hz, gdy jest wymagane przez LocationManager#requestLocationUpdate .
Przy połączeniu z internetem o szybkości 0, 5 Mb/s lub szybszej transmisji danych MUSI być w stanie określić lokalizację w miejscach na otwartym niebie (silne sygnały, znikome sygnały wielościeżkowe, HDOP < 2) w ciągu 10 sekund (szybszy czas do pierwszego naprawienia). 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).
- Po wykonaniu takiego obliczenia lokalizacji Zdecydowanie ZALECANE jest, aby urządzenie mogło określić jego lokalizację na otwartym niebie w ciągu 10 sekund, gdy żądania lokalizacji zostały ponownie uruchomione, nawet w ciągu godziny od początkowego 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:
- Musi być w stanie określić lokalizację z odległości do 20 metrów, a prędkość do 0,5 metra na sekundę, w co najmniej 95% przypadków.
- MUSI jednocześnie śledzić i raportować za pomocą funkcji GnssStatus.Callback co najmniej 8 satelitów z 1 konstelacji.
- Może ona jednocześnie śledzić co najmniej 24 satelity pochodzące z wielu konstelacji (np. GPS + przynajmniej jeden Glonass, Beidou, Galileo).
MUSI raportować technologię GNSS za pomocą testowego interfejsu API „getGnssYearOfHardware” (getGnssYearOfHardware).
Zdecydowanie ZALECANE jest spełnienie wszystkich poniższych wymagań, jeśli w danych o generowaniu technologii GNSS raportowany jest rok „2016”. lub nowsza.
- MUSI zgłaszać pomiary GPS od razu po ich wykryciu, nawet jeśli lokalizacja obliczana na podstawie GPS/GNSS nie jest jeszcze raportowana.
- MUSI podawać pseudozakresy i częstotliwości pseudozakresów GPS, które w warunkach na niebie po określeniu lokalizacji, gdy nieruchomo lub w ruchu z przyspieszeniem mniejszym niż 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 wystarcza do obliczenia pozycji z dokładnością do 20 metrów.

Pamiętaj, że choć niektóre z powyższych wymagań dotyczących GPS-a są określone jako Zdecydowanie ZALECANE, to definicja zgodności dla następnej wersji głównej prawdopodobnie zmieni je na TRZEBA.

7.3.4 Żyroskop

Urządzenia POWINIEN zawierać żyroskop (czujnik zmian kątowych). Urządzenia NIE POWINNY zawierać czujnika żyroskopu, chyba że wraz z nim jest także 3-osiowy akcelerometr. Jeśli urządzenie zawiera żyroskop:

NALEŻY zaimplementować czujnik TYPE_GYROSCOPE oraz czujnik TYPE_GYROSCOPE_UNCALIBRATED. Zdecydowanie ZALECANE jest zastosowanie czujnika SENSOR_TYPE_GYROSCOPE_UNCALIBRATED na dotychczasowych i nowych urządzeniach z Androidem.
MUSI być w stanie mierzyć zmiany orientacji obrazu do 1000 stopni na sekundę.
MUSI raportować zdarzenia z częstotliwością co najmniej 50 Hz w przypadku zegarków Android Watch, ponieważ takie urządzenia mają bardziej rygorystyczne ograniczenia zasilania i 100 Hz w przypadku pozostałych typów urządzeń.
POWINNA zgłaszać zdarzenia z częstotliwością co najmniej 200 Hz.
Wymagana jest rozdzielczość co najmniej 12-bitowa, a rozdzielczość 16-bitowa lub większa.
MUSI być kompensowana temperatura.
MUSI być kalibrowana i skompensowana podczas używania. Zachowuj parametry kompensacji między restartami urządzenia.
Wariancja MUSI mieć nie więcej niż 1e–7 rad^2 / s^2 na Hz (wariancja na Hz lub rad^2 / s). Wariancja może się zmieniać zależnie od 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, wartość ta nie powinna przekraczać 1e-7 rad^2/s^2.
MUSI zastosować czujnik kompozytowy TYPE_ROTATION_VECTOR, jeśli dołączony jest także czujnik akcelerometru i czujnik magnetometru.
Jeśli dołączony jest czujnik akcelerometru, MUSI zaimplementować czujniki kompozytowe TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION oraz czujnik kompozytowy TYPE_GAME_ROTATION_VECTOR. Zdecydowanie ZALECANE jest zastosowanie czujnika TYPE_GAME_ROTATION_VECTOR na dotychczasowych i nowych urządzeniach z Androidem.

7.3.5 barometr;

Urządzenie POWINIEN zawierać barometr (czujnik ciśnienia powietrza w tle). Jeśli na urządzeniu jest wbudowany barometr:

MUSI zaimplementować i zgłosić czujnik TYPE_PRESSURE.
MUSI obsługiwać zdarzenia z częstotliwością 5 Hz lub większą.
MUSI mieć wystarczającą dokładność, aby umożliwić oszacowanie wysokości.
MUSI być kompensowana temperatura.

7.3.6 Thermometer

Implementacje urządzeń MOGĄ zawierać termometr otoczenia (czujnik temperatury). Jeśli jest dostępna, MUSI być zdefiniowana jako SENSOR_TYPE_AMBIENT_TEMPERATURE i MUSI mierzyć temperaturę otoczenia (pokojową) w stopniach Celsjusza.

Implementacje urządzeń MOGĄ BYĆ, ale NIE POWINNY zawierać czujnika temperatury procesora. Jeśli ten parametr jest dostępny, MUSI być zdefiniowany jako SENSOR_TYPE_TEMPERATURE, MUSI mierzyć temperaturę procesora urządzenia i NIE MOŻE mierzyć innych temperatury. Pamiętaj, że typ czujnika SENSOR_TYPE_TEMPERATURE został wycofany w Androidzie 4.0.

W przypadku implementacji na Androidzie Automotive SENSOR_TYPE_AMBIENT_TEMPERATURE MUSI mierzyć temperaturę w kabinie pojazdu.

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. Urządzenia, które mogą nawiązywać połączenia głosowe i wskazywać w getPhoneType dowolną wartość inną niż PHONE_TYPE_NONE, POWINNY zawierać czujnik zbliżeniowy. Jeśli implementacja urządzenia ma czujnik zbliżeniowy,:

MUSI mierzyć odległość od 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 implementacja urządzenia zawiera czujnik zbliżeniowy o jakiejkolwiek innej orientacji, NIE MOŻE być dostępny za pomocą tego interfejsu API.
Wymaga dokładności co najmniej 1 bitu.

7.3.9. Czujniki wysokiej jakości

Implementacje urządzeń obsługujące zestaw czujników wyższej jakości, które mogą spełnić wszystkie wymagania wymienione w tej sekcji, MUSZĄ informować o obsłudze za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

Urządzenie deklarujące funkcję android.hardware.sensor.hifi_sensors MUSI obsługiwać wszystkie te typy czujników spełniające poniższe wymagania dotyczące jakości:

SENSOR_TYPE_ACCELEROMETER
- 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°.
CZUJNIK_TYPE_GYROSCOPE
- 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.
- MUSI mieć nieruchomą stabilność uprzedzenia < 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.
SENSOR_TYPE_GYROSCOPE_UNCALIBRATED z tymi samymi wymaganiami dotyczącymi jakości co SENSOR_TYPE_GYROSCOPE.
SENSOR_TYPE_GEOMAGNETIC_FIELD:
- 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.
SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED z tymi samymi wymaganiami dotyczącymi jakości co SENSOR_TYPE_GEOMAGNETIC_FIELD, a dodatkowo:
- MUSISZ zaimplementować typ czujnika bez wybudzania z możliwością buforowania wynoszącą co najmniej 600 zdarzeń czujnika.
CIŚNIENIE_TYPU_CZUJNIKA
- 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.
CZUJNIK_TYPE_GAME_ROTATION_VECTOR
- 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.
SENSOR_TYPE_SIGNIFICANT_MOTION
- 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.
CZUJNIK_TYP_KROKÓW_CZYNNIKA
- 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.
SENSOR_TYPE_STEP_COUNTER
- 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.
WYKRYWANIE_WYKRYWANIA_CZUJNIKA
- 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.

Takie urządzenie MUSI też spełniać następujące wymagania podsystemu czujnika:

Sygnatura czasowa tego samego zdarzenia fizycznego zgłoszonego przez akcelerometr, żyroskop i magnetometr MUSI zawierać się w odległości maksymalnie 2,5 milisekundy.
Sygnatury czasowe zdarzeń z czujnika żyroskopu MUSZĄ pochodzić z tej samej podstawy czasowej co podsystem kamery i nie mogą przekraczać 1 milisekundy od błędu.
Czujniki wysokiej wierności MUSZĄ dostarczać próbki do aplikacji w ciągu 5 milisekund od momentu, gdy dane znajdują się w czujniku fizycznym.
Pobór mocy 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
- CZUJNIK_TYP_KROKÓW_CZYNNIKA
- SENSOR_TYPE_STEP_COUNTER
- CZUJNIK_przechylenia

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.

Te typy czujników MOGĄ również być obsługiwane przez implementację urządzenia z deklaracją android.hardware.sensor.hifi_sensors, ale jeśli są dostępne te typy czujników, MUSZĄ one spełniać te minimalne wymagania dotyczące buforowania:

SENSOR_TYPE_PROXIMITY: 100 zdarzeń z czujnika

7.3.10. Czytnik linii papilarnych

Urządzenia z bezpiecznym ekranem blokady POWINNY być wyposażone w czytnik linii papilarnych. Jeśli implementacja urządzenia obejmuje czytnik linii papilarnych i ma odpowiedni interfejs API dla zewnętrznych deweloperów:

MUSI zadeklarować obsługę funkcji android.hardware.fingerprint.
MUSI w pełni zaimplementować odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK.
Wartość MUSI mieć współczynnik fałszywych akceptacji nie wyższy niż 0,002%.
Zdecydowanie ZALECANE jest, aby wskaźnik fałszywych odrzuceń wynosił mniej niż 10%, zgodnie z pomiarem na urządzeniu.
ZALECANE jest opóźnienie poniżej 1 sekundy, mierzone od chwili dotknięcia czytnika linii papilarnych do momentu odblokowania ekranu. Dotyczy to 1 zarejestrowanego palca.
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.
MUSI mieć wdrożony magazyn kluczy wspierany sprzętowo i dopasowywać odciski palców w zaufanym środowisku TEE lub za pomocą układu z bezpiecznym kanałem TEE.
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.
MUSI uniemożliwiać dodanie odcisku palca bez uprzedniego 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. projekt Android Open Source Project zapewnia w strukturze odpowiedni mechanizm.
NIE MOŻE umożliwiać aplikacji innych firm rozróżniania poszczególnych odcisków palców.
MUSI uwzględniać flagę DevicePolicyManager.KEYGUARD_DISABLE_FINGERDR.
Po przejściu z wersji wcześniejszej niż 6.0 MUSISZ bezpiecznie przenieść odciski palców, aby spełnić powyższe wymagania, lub usunąć te dane.
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

Implementacje Androida Automotive POWINNY być dostępne jako SENSOR_TYPE_GEAR.

7.3.11.2. Tryb dzienny/nocny

Implementacje Androida Automotive MUSZĄ obsługiwać tryb dzienny/nocny zdefiniowany jako SENSOR_TYPE_NIGHT. Wartość tej flagi MUSI być zgodna z trybem dziennym/nocnym na pulpicie i POWINIEN być oparta na danych z czujnika jasności otoczenia. Czujnik jasności otoczenia MOŻE być taki sam jak Fotometr.

7.3.11.3 Stan jazdy

Implementacje na Androida Automotive MUSZĄ 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 zgodnie ze wszystkimi przepisami i regulacjami prawnymi obowiązującymi na rynkach, na które produkt jest wysyłany.

7.3.11.4. Prędkość koła

Implementacje Androida Automotive MUSZĄ podawać szybkość pojazdu zdefiniowaną jako SENSOR_TYPE_CAR_SPEED.

7.3.12. Czujnik pozycji

Implementacje urządzeń MOGĄ obsługiwać czujnik pozycji z 6 stopniami swobody. Do obsługi tego czujnika ZALECANE są mobilne urządzenia z Androidem. Jeśli implementacja urządzenia obsługuje czujnik pozycji z sześcioma stopniami swobody,:

MUSI zaimplementować i zgłosić czujnik TYPE_POSE_6DOF.
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 MOGĄ zgłaszać funkcji android.hardware.telephony ani żadnych podfunkcji, 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 jednak wdrożenie urządzenia obejmuje usługę telefonii GSM lub CDMA, MUSI obsługiwać pełną obsługę interfejsu API dla tej technologii. Implementacje urządzeń, które nie obejmują sprzętu telefonicznego, MUSZĄ wdrożyć pełne interfejsy API w trybie bezobsługowym.

7.4.1.1 Zgodność z blokadami numerów

Implementacje urządzeń telefonicznych z Androidem MUSZĄ obejmować obsługę blokowania numerów oraz:

Trzeba w pełni zaimplementować parametr BlockedNumberContract i odpowiedni interfejs API zgodnie z opisem w dokumentacji pakietu SDK.
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.
W przypadku zablokowanego połączenia NIE MOŻE zapisywać danych do dostawcy rejestru połączeń platformy.
NIE MOŻE pisać do dostawcy usług telefonicznych w przypadku zablokowanej wiadomości.
MUSI zaimplementować interfejs zarządzania zablokowanymi liczbami, który jest otwierany za pomocą intencji zwracanej przez metodę TelecomManager.createManageBlockedNumbersIntent().
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 usługami telefonicznymi 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.2 IEEE 802.11 (Wi-Fi)

Wszystkie implementacje urządzeń z Androidem MUSZĄ obsługiwać co najmniej jedną formę standardu 802.11. Jeśli implementacja urządzenia obsługuje standard 802.11 i udostępnia tę funkcję aplikacji innej firmy, MUSI zaimplementować odpowiedni interfejs API Androida oraz:

MUSI zgłosić flagę funkcji sprzętowej android.hardware.wifi.
MUSI zaimplementować interfejs API multicast w sposób opisany w dokumentacji pakietu SDK.
MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) podczas wykonywania operacji, w tym:
- Nawet wtedy, gdy ekran nie jest aktywny.
- Dotyczy urządzeń Android TV, nawet w trybie gotowości.

7.4.2.1. Wi-Fi Direct

Implementacje urządzenia POWINIEN obsługiwać protokół Wi-Fi Direct (typu Wi-Fi peer-to-peer). Jeśli implementacja urządzenia obsługuje Wi-Fi Direct, MUSI wdrożyć odpowiedni interfejs API Androida zgodnie z dokumentacją pakietu SDK. Jeśli implementacja urządzenia obejmuje obsługę Wi-Fi Direct, to:

MUSI zgłosić funkcję sprzętową android.hardware.wifi.direct.
MUSI obsługiwać normalne działanie Wi-Fi.
POWINNA obsługiwać jednoczesne działanie Wi-Fi i Wi-Fi Direct.

7.4.2.2. Konfiguracja bezpośredniego linku Wi-Fi

Implementacje na urządzeniach MUSZĄ obsługiwać konfigurację bezpośredniego linku Wi-Fi (TDLS) zgodnie z opisem w dokumentacji pakietu Android SDK. Jeśli implementacja urządzenia obejmuje obsługę TDLS, a w interfejsie API Wi-FiManager urządzenie jest włączone TDLS:

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

Implementacje na zegarku Android Watch MUSZĄ obsługiwać Bluetooth. Implementacje telewizji na Androida MUSZĄ obsługiwać Bluetooth i Bluetooth LE. Implementacje na Androida Automotive MUSZĄ obsługiwać Bluetooth i POWINNO obsługiwać Bluetooth LE.

Implementacje urządzeń, które obsługują funkcję android.hardware.vr.high_performance, MUSZĄ obsługiwać Bluetooth 4.2 i rozszerzenie długości danych Bluetooth LE.

Android obsługuje Bluetooth i Bluetooth Low Energy. Implementacje urządzeń, które obejmują obsługę Bluetootha i Bluetooth Low Energy, MUSZĄ zadeklarować odpowiednie funkcje platformy (odpowiednio android.hardware.bluetooth i android.hardware.bluetooth_le) i wdrożyć interfejsy API platformy. Przy implementacji na urządzeniu NALEŻY zastosować odpowiednie profile Bluetooth, takie jak A2DP, AVCP, OBEX itp., w zależności od urządzenia.

Implementacje na Androida Automotive POWINNY obsługiwać profil dostępu do wiadomości (MAP). 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).

Implementacje urządzeń, w tym obsługa Bluetooth Low Energy:

MUSI zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
MUSI włączyć interfejsy API Bluetooth oparte na GATT (ogólnym profilu) w sposób opisany w dokumentacji pakietu SDK i w android.bluetooth.
Zdecydowanie ZALECANE jest wdrożenie limitu czasu oczekiwania na rozpoznawalny adres prywatny (RPA) nie dłuższy niż 15 minut i rotacja adresu po upłynięciu czasu oczekiwania w celu ochrony prywatności użytkownika.
Implementacja interfejsu API Skanera POWINNA obsługiwać odciążanie logiki filtrowania na chipset Bluetooth i musi podawać prawidłową wartość miejsca implementacji logiki filtrowania w przypadku każdego zapytania z użyciem metody android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported().
POWINNO obsługiwać przechodzenie ze skanowania zbiorczego na chipset Bluetooth, ale jeśli nie jest obsługiwane, MUSI podawać wartość „false” przy wysyłaniu zapytania za pomocą metody android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported().
POWINNA jest obsługiwać wiele reklam z co najmniej 4 przedziałami. Jeśli jednak nie jest obsługiwane, MUSI podawać wartość „false” za każdym razem, gdy wysyła się zapytanie za pomocą metody android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported().

7.4.4 Komunikacja Near Field Communication

Urządzenia POWINIEN zawierać nadajnik i odpowiedni sprzęt do komunikacji Near-Field Communications (NFC). Jeśli implementacja urządzenia obejmuje sprzęt do komunikacji NFC i planuje udostępnić ją aplikacjom innych firm, to:

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:
- MUSI działać jako czytnik/zapisujący forum NFC (zgodnie z definicją w specyfikacji technicznej NFC Forum-TS-DigitalProtocol-1.0) przy użyciu następujących standardów NFC:
  - NfcA (ISO14443-3A)
  - NfcB (ISO14443-3B)
  - NfcF (JIS X 6319-4)
  - IsoDep (ISO 14443-4)
  - Tag forum NFC – typy 1, 2, 3, 4 (zdefiniowane przez Forum NFC)
- Zdecydowanie zalecana jest możliwość odczytywania i zapisywania wiadomości NDEF, a także nieprzetworzonych danych zgodnie z poniższymi standardami NFC. Pamiętaj, że chociaż poniższe standardy NFC są określane 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łnianie tych wymagań już teraz i na nowych urządzeniach, na których działa ta wersja Androida, aby umożliwić ich uaktualnienie do przyszłych wersji platformy.
  - NfcV (ISO 15693)
- MUSI być w stanie odczytać kod kreskowy i adres URL (jeśli jest zakodowany) produktów z kodem kreskowym Thinfilm NFC.
- 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)
- MUSI obsługiwać funkcję Android Beam.
- MUSI zaimplementować domyślny serwer SNEP. Prawidłowe wiadomości NDEF odebrane 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.
- MUSI uwzględniać intencję android.settings.NFCSHARING_SETTINGS, aby wyświetlać ustawienia udostępniania NFC.
- MUSI zaimplementować serwer NPP. Wiadomości odbierane przez serwer NPP MUSZĄ być przetwarzane w taki sam sposób, jak domyślny serwer SNEP.
- MUSI zaimplementować klienta SNEP i próbować wysyłać wychodzące połączenia P2P NDEF 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.
- Aby ustawić wychodzącą wiadomość NDEF P2P przy użyciu metod android.nfc.NfcAdapter.setNdefPushMessage i android.nfc.NfcAdapter.setNdefPushMessageCallback lub android.nfc.NfcAdapter.enableForegroundNdefPush, MUSI zezwalać na działania na pierwszym planie.
- Przed wysłaniem wychodzących wiadomości P2P NDEF NALEŻY używać gestu lub potwierdzenia na ekranie, takiego jak „Dotknij, aby przesłać”.
- MUSI włączyć domyślnie Android Beam. MUSI mieć możliwość wysyłania i odbierania wiadomości przez Android Beam, nawet jeśli włączony jest inny zastrzeżony tryb NFC P2p.
- MUSI obsługiwać przekazywanie połączenia NFC do Bluetooth, gdy urządzenie obsługuje Bluetooth Object Push Profile. Jeśli używasz android.nfc.NfcAdapter.setBeamPushUris, implementacje urządzenia MUSZĄ obsługiwać przekazywanie połączenia do Bluetootha przez wdrożenie specyfikacji „przekazywania połączenia w wersji 1.2” i „bezpiecznego parowania Bluetooth przez NFC w wersji 1.0” z Forum NFC. W takiej implementacji MUSISZ wdrożyć usługę przenoszenia obiektów 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 w celu wykonania przekazania połączenia.
- 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.

(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 implementacja urządzenia zawiera chipset kontrolera NFC obsługujący HCE (NfcA lub NfcB) i obsługuje routing na podstawie identyfikatora aplikacji (AID), to:

MUSI zgłaszać stałą funkcję android.hardware.nfc.hce.
MUSI obsługiwać interfejsy NFC HCE API zgodnie z definicją w pakiecie Android SDK.

Jeśli implementacja urządzenia zawiera chipset kontrolera NFC obsługujący HCE dla NfcF i wdroży tę funkcję dla aplikacji innych firm, to:

MUSI zgłaszać stałą funkcję android.hardware.nfc.hcef.
TRZEBA zaimplementować interfejsy API Card Emulation API NfcF zgodnie z definicją w pakiecie SDK na Androida.

Dodatkowo implementacje urządzeń MOGĄ obejmować obsługę odczytu/zapisu w przypadku wymienionych poniżej technologii MIFARE.

MIFARE – klasyka
Ultralekkie MIFARE
NDEF w klasycznej wersji MIFARE

Pamiętaj, że Android zawiera interfejsy API dla tych typów MIFARE. Jeśli implementacja urządzenia obsługuje MIFARE w roli odczytującego/zapisującego, oznacza to, że:

MUSI zaimplementować odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
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.
NIE MOŻE wdrażać odpowiednich interfejsów API Androida ani zgłaszać funkcji com.nxp.mifare, chyba że jest też zaimplementowana ogólna obsługa NFC zgodnie z opisem w tej sekcji.

Jeśli implementacja urządzenia nie obejmuje modułu NFC, NIE MOŻE zadeklarować funkcji android.hardware.nfc w metodzie android.content.pm.PackageManager.hasSystemFeature(). MUSI zaimplementować interfejs Android NFC API w ramach funkcji no-op.

Ponieważ klasy android.nfc.NdefMessage i android.nfc.NdefRecord przedstawiają format danych niezależny od protokołu, implementacje urządzeń MUSZĄ wdrożyć te interfejsy API, nawet jeśli nie obsługują NFC lub zadeklarują funkcję android.hardware.nfc.

7.4.5 Minimalne możliwości sieci

Implementacje na urządzeniach MUSZĄ 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.

Implementacje urządzeń, w których podstawowym połączeniem do transmisji danych jest fizyczny standard sieci (np. Ethernet), POWINNY BYĆ również obsługiwany co najmniej jeden popularny standard bezprzewodowych danych, taki jak 802.11 (Wi-Fi).

Urządzenia MOGĄ obsługiwać więcej niż jedną formę połączeń danych.

Urządzenia MUSZĄ zawierać stos sieciowy IPv6 i obsługiwać komunikację IPv6 przy użyciu zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection , a także natywnych interfejsów API, takich jak gniazda AF_INET6. Wymagany poziom obsługi IPv6 zależy od typu sieci:

Urządzenia obsługujące sieci Wi-Fi MUSZĄ obsługiwać operacje na stosie podwójnym i tylko IPv6 w sieci Wi-Fi.
Urządzenia obsługujące sieci Ethernet MUSZĄ obsługiwać operację podwójnego stosu w sieci Ethernet.
Urządzenia obsługujące komórkową transmisję danych MUSZĄ obsługiwać operację IPv6 (tylko w przypadku protokołu IPv6, a w miarę możliwości podwójny stos) w przypadku komórkowej transmisji danych.
Gdy urządzenie jest jednocześnie połączone z kilkoma sieciami (np. Wi-Fi i komórkowej transmisji danych), MUSI spełniać te wymagania w każdej sieci, z którą jest nawiązane połączenie.

Protokół IPv6 MUSI być domyślnie włączony.

Aby komunikacja IPv6 była równie niezawodna jak IPv4, wysyłane do urządzenia pakiety IPv6 NIE MOGĄ być pomijane, nawet jeśli ekran nie jest aktywny. Nadmiarowe pakiety IPv6 multiemisji, takie jak powtarzające się identyczne reklamy routerów, MOGĄ być ograniczone w przypadku sprzętu lub oprogramowania układowego, jeśli jest to konieczne do oszczędzania energii. W takich przypadkach 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.

Połączenia IPv6 MUSZĄ pozostawać w trybie uśpienia.

7.4.6 Ustawienia synchronizacji

Implementacje na urządzeniach MUSZĄ mieć domyślnie włączone główne ustawienie autosynchronizacji, tak aby metoda getMasterSyncAutomatic() zwracała wartość „true”.

7.4.7 Oszczędzanie danych

Zdecydowanie ZALECANE są wdrożenia na urządzeniach korzystające z połączenia z pomiarem użycia danych w celu umożliwienia korzystania z trybu oszczędzania danych.

Jeśli implementacja urządzenia umożliwia korzystanie z trybu oszczędzania danych:

MUSI obsługiwać wszystkie interfejsy API klasy ConnectivityManager w sposób opisany w dokumentacji pakietu SDK.
MUSI udostępniać w ustawieniach interfejs użytkownika umożliwiający użytkownikom dodawanie aplikacji do listy dozwolonych lub usuwanie ich z niej.

Jeśli natomiast implementacja urządzenia nie udostępnia trybu oszczędzania danych:

MUSI zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED dla funkcji ConnectivityManager.getRestrictBackgroundStatus()
Nie może transmitować: ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
MUSI zawierać działanie, które obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻE wdrożyć je jako no-op.

7.5 Aparaty

Urządzenia POWINIEN zawierać tylny aparat, lecz MOŻE zawierać przedni aparat. Tylny aparat to kamera znajdująca się z boku urządzenia, naprzeciwko wyświetlacza. Oznacza to, że rejestruje sceny z daleka, jak w tradycyjnym aparacie. Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz. oznacza kamerę zwykle używaną do robienia zdjęć użytkownika, na przykład do rozmów wideo i w podobnych aplikacjach.

Jeśli w implementacji urządzenia jest co najmniej jedna kamera, aplikacja MUSI jednocześnie przydzielić 3 mapy bitowe RGBA_8888 równe rozmiarowi obrazów wygenerowanych przez czujnik aparatu o największej rozdzielczości w urządzeniu, a aparat jest otwarty na potrzeby podstawowego podglądu i rejestrowania.

7.5.1 Kamera tylna

Wdrożenia urządzeń POWINIEN zawierać tylny aparat. Jeśli implementacja urządzenia obejmuje co najmniej 1 tylny aparat:

MUSI zgłosić flagę funkcji android.hardware.camera i android.hardware.camera.any.
Rozdzielczość MUSI mieć 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ą, lampa błyskowa NIE MOŻE się świecić, gdy w polu podglądu aparatu zostało zarejestrowane wystąpienie zdarzenia android.hardware.Camera.PreviewCallback, 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 kamery systemu, a jedynie do aplikacji innych firm korzystających z funkcji Camera.PreviewCallback.

7.5.2 Przedni aparat

Implementacje na urządzeniach MOGĄ obejmować przedni aparat. Jeśli implementacja urządzenia obejmuje co najmniej 1 przedni aparat:

MUSI zgłosić flagę funkcji android.hardware.camera.any i android.hardware.camera.front.
MUSI mieć rozdzielczość co najmniej VGA (640 x 480 pikseli).
Jako domyślnego ustawienia interfejsu Camera API NIE MOŻE używać przedniego aparatu. Interfejs Camera API w Androidzie obsługuje przednie aparaty, a implementacje urządzeń NIE MOGĄ 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.
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.
MUSI odzwierciedlić strumień wyświetlany przez aplikację w podglądzie w aparacie w poziomie (tzn. powielać) w ten sposób:
- Jeśli implementacja urządzenia umożliwia obracanie działania przez użytkownika (np. automatycznie za pomocą akcelerometru lub ręcznie na podstawie danych wejściowych użytkownika), podgląd aparatu MUSI być odbicie lustrzane w poziomie względem bieżącej orientacji urządzenia.
- Jeśli bieżąca aplikacja zażądała obrócenia wyświetlacza kamery za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation(), podgląd z aparatu MUSI być powielany w poziomie względem orientacji określonej przez aplikację.
- W przeciwnym razie podgląd MUSI wyświetlić się na domyślnej osi poziomej urządzenia.
MUSI powielać zdjęcie wyświetlane po wyświetleniu w taki sam sposób jak obraz z podglądu z aparatu. Jeśli implementacja urządzenia nie obsługuje po obejrzeniu, ten wymóg oczywiście nie ma zastosowania.
NIE MOGĄ powielać ostatecznej wersji obrazu nieruchomego ani strumieni wideo zwróconych do wywołań zwrotnych aplikacji lub zadeklarowanych do przechowywania multimediów.

7.5.3 Kamera zewnętrzna

Implementacje urządzeń MOGĄ obsługiwać kamerę zewnętrzną, która nie zawsze jest podłączona. Jeśli urządzenie obsługuje zewnętrzny aparat:

TRZEBA zadeklarować flagę funkcji platformy android.hardware.camera.external i android.hardware camera.any .
MOŻE obsługiwać wiele aparatów.
MUSI obsługiwać standard USB Video Class (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ć 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 API, android.hardware.Camera, jest oznaczony jako wycofany w Androidzie 5.0, ale nadal powinien być dostępny dla aplikacji korzystających z implementacji na urządzeniach z Androidem, MUSI zapewnić nieprzerwaną obsługę interfejsu API w sposób opisany w tej sekcji oraz w pakiecie SDK Androida.

Implementacje urządzeń MUSZĄ implementować w przypadku wszystkich dostępnych aparatów te zachowania w przypadku interfejsów API związanych z aparatem:

Jeśli aplikacja nigdy nie wywołała funkcji android.hardware.Camera.Parameters.setPreviewFormat(int), urządzenie MUSI używać atrybutu android.hardware.PixelFormat.YCbCr_420_SP w przypadku danych podglądu przekazywanych do wywołań zwrotnych aplikacji.
Jeśli aplikacja rejestruje wystąpienie android.hardware.Camera.PreviewCallback, a system wywołuje metodę onPreviewFrame(), gdy format podglądu to YCbCr_420_SP, dane w bajcie[] przekazywane do funkcji onPreviewFrame() muszą być dodatkowo w formacie kodowania NV21. Oznacza to, że NV21 MUSI być wartością domyślną.
W przypadku tagu android.hardware.Camera implementacje urządzeń MUSZĄ obsługiwać format YV12 (co oznacza stałą android.graphics.ImageFormat.YV12) w przypadku podglądu z aparatu zarówno przednim, jak i tylnym. (Sprzętowy koder wideo i kamera mogą używać dowolnego natywnego formatu piksela, ale implementacja urządzenia MUSI obsługiwać konwersję na format YV12).
W przypadku android.hardware.camera2 implementacje urządzeń muszą obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe przez interfejs android.media.ImageReader API.

Implementacje urządzenia MUSZĄ nadal implementować 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 instancje 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, mimo że większość przednich aparatów nie obsługuje autofokusa, wywołania zwrotne interfejsu API muszą być fałszywe, zgodnie z opisem.

Implementacje urządzenia MUSZĄ rozpoznać i uznać każdą nazwę parametru zdefiniowaną jako stałą w klasie android.hardware.Camera.Parameters, jeśli dany sprzęt ją obsługuje. Jeśli sprzęt urządzenia nie obsługuje jakiejś funkcji, interfejs API musi działać zgodnie z opisem. 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 parametrze 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 urządzenia, które obsługują robienie zdjęć z użyciem technik obrazowania o wysokim zakresie dynamiki (HDR), MUSZĄ obsługiwać parametr aparatu Aparat.SCENE_MODE_HDR.

Nie wszystkie implementacje urządzeń mogą w pełni obsługiwać wszystkie funkcje interfejsu android.hardware.camera2 API, dlatego implementacje urządzeń MUSZĄ zgłaszać odpowiedni poziom obsługi za pomocą właściwości android.info.supportedHardwareLevel, zgodnie z opisem w pakiecie SDK Androida, oraz zgłaszać odpowiednie flagi funkcji platformy.

Implementacje urządzenia MUSZĄ także zadeklarować możliwości indywidualnego aparatu (android.hardware.camera2) za pomocą właściwości android.request.availableCapabilities i zadeklarować odpowiednie flagi funkcji. urządzenie musi zdefiniować flagę funkcji, jeśli którekolwiek z podłączonych do niej urządzeń obsługuje tę funkcję.

Implementacje na urządzeniu MUSZĄ rozpowszechniać intencję Aparat.ACTION_NEW_PICTURE za każdym razem, gdy aparat zrobi nowe zdjęcie i dodasz zdjęcie do sklepu multimedialnego.

Implementacje na urządzeniu MUSZĄ transmitować intencję Aparat.ACTION_NEW_VIDEO za każdym razem, gdy kamera zarejestruje nowy film i zostanie dodane zdjęcie do sklepu multimedialnego.

7.5.5 Orientacja aparatu

Zarówno przedni, jak i tylny aparat MUSI być zorientowany w taki sposób, aby długi wymiar aparatu 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. Oznacza to, że ma ona zastosowanie zarówno do urządzeń głównych w 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

Urządzenia Android TV MUSZĄ mieć co najmniej 4 GB pamięci nieulotnej przeznaczonej na prywatne dane aplikacji.

Pamięć dostępna dla jądra i przestrzeni użytkownika na urządzeniu MUSI być co najmniej równa wartościom minimalnym określonym w poniższej tabeli lub od niej większa. (Definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).

Gęstość i rozmiar ekranu	Urządzenie 32-bitowe	Urządzenie 64-bitowe
Zegarki z Androidem (ze względu na mniejsze ekrany)	416MB	Nie dotyczy
Rozdzielczość 280 dpi lub niższa na małych bądź normalnych ekranach mdpi lub niższy na dużych ekranach ldpi lub niższy na bardzo dużych ekranach	512MB	816MB
xhdpi lub wyższa na małych/normalnych ekranach rozdzielczość hdpi lub wyższa na dużych ekranach; mdpi lub więcej na bardzo dużych ekranach	608MB	944MB
Rozdzielczość 400 dpi lub większa na małych lub normalnych ekranach xhdpi lub więcej na dużych ekranach tvdpi lub więcej na bardzo dużych ekranach	896MB	1280MB
Rozdzielczość 560 dpi lub większa na małym lub normalnym ekranie rozdzielczość 400 dpi lub wyższa na dużych ekranach; xhdpi lub więcej na bardzo dużych ekranach	1344MB	1824MB

Minimalne wartości pamięci MUSZĄ zostać uzupełnione o miejsce w pamięci już przeznaczone dla komponentów sprzętowych, takich jak radio czy obraz, i tym samym, które nie są zarządzane przez jądro.

Implementacje urządzeń, które mają mniej niż 512 MB pamięci dostępnej dla jądra i przestrzeni użytkownika, chyba że zegarek Android Watch MUSI zwracać wartość „true” dla ActivityManager.isLowRamDevice().

Urządzenia Android TV MUSZĄ mieć co najmniej 4 GB, a inne implementacje MUSZĄ mieć co najmniej 3 GB nieulotnej pamięci masowej na prywatne dane aplikacji. Oznacza to, że partycja /data MUSI mieć co najmniej 4 GB w przypadku urządzeń z Android TV i co najmniej 3 GB w przypadku innych urządzeń. Implementacje na urządzeniach z Androidem są Zdecydowanie ZALECANEco najmniej 4 GB nieulotnej pamięci na prywatne dane aplikacji, co pozwoli na uaktualnienie do przyszłych wersji platformy.

Interfejsy API Androida zawierają menedżera pobierania, za pomocą którego aplikacje MOGĄ pobierać pliki danych. Menedżer pobierania na urządzeniu MUSI pobierać poszczególne 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ądzeniu MUSZĄ oferować pamięć współdzieloną dla aplikacji, często nazywanych też „wspólną pamięcią zewnętrzną”.

Implementacje urządzeń MUSZĄ być skonfigurowane z domyślnie podłączoną pamięcią współdzieloną „rozpakowaną”. Jeśli pamięć współdzielona nie jest podłączona do ścieżki Linuxpath /sdcard, urządzenie MUSI zawierać łącze symboliczne systemu Linux z katalogu /sdcard do rzeczywistego punktu podłączania.

Implementacje urządzeń MOGĄ BYĆ wyposażone w dostępne dla użytkowników nośniki wymienne, takie jak gniazdo kart Secure Digital (SD). Jeśli to gniazdo służy do spełnienia wymagań dotyczących pamięci współdzielonej, implementacja urządzenia:

MUSI zaimplementować wyświetlanie komunikatu lub wyskakującego okienka w interfejsie, które ostrzega użytkownika, gdy nie ma karty SD.
MUSI zawierać kartę SD w formacie FAT o rozmiarze co najmniej 1 GB LUB pokazywać na pudełku i inne materiały dostępne w momencie zakupu, które muszą być kupione oddzielnie.
Domyślnie MUSI podłączyć kartę SD.

Z kolei implementacje urządzeń MOGĄ przydzielać pamięć wewnętrzną (niewymienną) jako pamięć współdzieloną aplikacji w ramach nadrzędnego projektu Android Open Source. implementacje urządzeń POWINNY korzystać z tej konfiguracji i implementacji oprogramowania. Jeśli w celu spełnienia wymagań dotyczących pamięci współdzielonej implementacja urządzenia używa pamięci wewnętrznej (niewyjmowanej), podczas gdy pamięć ta MOŻE współdzielić przestrzeń z prywatnymi danymi aplikacji, MUSI mieć co najmniej 1 GB miejsca i być zamontowana na karcie /sdcard (lub /sdcard MUSI być symbolicznym linkiem do fizycznej lokalizacji, jeśli jest podłączona w innym miejscu).

Implementacje na urządzeniach MUSZĄ być egzekwowane w sposób opisany w uprawnieniu android.permission.WRITE_EXTERNAL_STORAGE w tej pamięci współdzielonej. W przeciwnym razie każda aplikacja uzyskująca to uprawnienie MUSI umożliwia zapis.

Implementacje urządzeń, które zawierają wiele ścieżek pamięci współdzielonej (np. gniazdo kart SD i współdzieloną pamięć wewnętrzną), MUSZĄ zezwalać tylko na wstępnie zainstalowane aplikacje na Androida z uprawnieniami WRITE_EXTERNAL_STORAGE z uprawnieniami do zapisu w dodatkowej pamięci zewnętrznej, z wyjątkiem zapisu w ich katalogach związanych z pakietami lub w środowisku URI zwróconym przez uruchomienie intencji ACTION_OPEN_DOCUMENT_TREE.

Jednak implementacje urządzeń MUSZĄ udostępniać treści z obu ścieżek pamięci w przejrzysty sposób przez usługę skanera multimediów na Androidzie oraz android.provider.MediaStore.

Niezależnie od rodzaju używanej pamięci współdzielonej, jeśli implementacja urządzenia jest wyposażona w port USB z obsługą trybu peryferyjnego USB, MUSI zapewniać jakiś mechanizm uzyskiwania dostępu do zawartości pamięci współdzielonej z komputera hosta. Implementacje na urządzeniach MOGĄ korzystać z pamięci masowej USB, ale aby spełnić to wymaganie, MUSISZ używać protokołu Media Transfer Protocol. Jeśli implementacja urządzenia obsługuje protokół Media Transfer Protocol,:

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

Zdecydowanie ZALECANE jest wdrożenie pamięci adaptacyjnej, jeśli port wymiennego urządzenia pamięci masowej znajduje się w stabilnej lokalizacji długoterminowej, np. w komorze na baterię lub w innej osłonie ochronnej.

Urządzenia takie jak telewizory MOGĄ umożliwiać korzystanie z tych interfejsów przez porty USB, ponieważ urządzenia są statyczne i nie mobilne. Jednak w przypadku innych implementacji urządzeń mobilnych Zdecydowanie ZALECANE jest wdrożenie możliwej pamięci masowej w stabilnej lokalizacji długoterminowej, ponieważ przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

7.7. USB

Implementacje urządzeń MUSZĄ obsługiwać tryb urządzenia peryferyjnego USB i POWINNY obsługiwać tryb hosta USB.

7.7.1. Tryb urządzenia peryferyjnego USB

Jeśli implementacja urządzenia obejmuje port USB obsługujący tryb peryferyjny:

Port MUSI być połączony z hostem USB ze standardowym portem USB typu A lub C.
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.
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.
MUSI zezwalać hostowi USB podłączonemu do urządzenia z Androidem na dostęp do zawartości pamięci współdzielonej przy użyciu pamięci masowej USB lub protokołu Media Transfer Protocol.
POWINNY jest wdrożyć interfejs API i specyfikację Android Open Accessory (AOA) zgodnie z dokumentacją pakietu Android SDK, a jeśli jest to przenośne urządzenie z Androidem, MUSI wdrożyć interfejs AOA API. Implementacje urządzeń stosujące specyfikację AOA:
- MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.accessory.
- TRZEBA zaimplementować klasę audio USB w sposób opisany w dokumentacji pakietu Android SDK.
- Klasa pamięci masowej USB MUSI zawierać ciąg „android” na końcu ciągu opisu interfejsu iInterface pamięci masowej USB
NALEŻY zaimplementować obsługę pobierania prądu o napięciu 1,5 A podczas sygnału HS i ruchu, zgodnie z opisem w specyfikacji ładowania baterii USB w wersji 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.
Urządzenia typu C MUSZĄ wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem oporników typu C i muszą wykrywać zmiany w reklamie.
Zdecydowanie ZALECANE są urządzenia typu C obsługujące tryb hosta USB, które umożliwiają zamianę ról danych i zasilania.
Urządzenia typu C powinny obsługiwać funkcję Power Delivery w przypadku ładowania wysokiego napięcia oraz obsługa trybów alternatywnych, takich jak wyświetlacz na zewnątrz.
Wartość iSerialNumber w standardowym deskrypcie urządzenia USB MUSI być równa wartości android.os.Build.SERIAL.
Zdecydowanie ZALECANE są, by urządzenia typu C nie obsługiwały zastrzeżonych metod ładowania, które zmieniają napięcie Vbus do wartości domyślnych lub zmieniają role zlewu/źródła. Może to 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.

7.7.2 Tryb hosta USB

Jeśli implementacja urządzenia zawiera port USB obsługujący tryb hosta:

UŻYJ portu USB typu C, jeśli implementacja urządzenia obsługuje USB 3.1.
MOŻNA użyć niestandardowego portu, ale w takim przypadku MUSI być dostarczany z kablem lub kablem podłączającym port do standardowego portu USB typu A lub C.
MOŻESZ użyć portu micro USB typu AB, ale w takim przypadku POWINNY jest w tym jeden kabel łączący port USB ze standardowym portem USB typu A lub C.
ZALECANE jest wdrożenie klasy audio USB zgodnie z dokumentacją pakietu Android SDK.
MUSI zaimplementować interfejs API hosta USB Android w sposób opisany w pakiecie Android SDK i MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.host.
POWINNA obsługiwać ładowanie urządzenia w trybie hosta; reklamując prąd źródłowy o natężeniu co najmniej 1,5 A, zgodnie z opisem w sekcji Parametry zakończenia ładowania [USB Type-C Cable and Connector Specification Revision 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) w przypadku złączy USB typu C lub korzystania ze złączy USB typu C w przypadku złączy USB typu C lub korzystania z złącza ładowania USB typu C w przypadku złącza ładowania USB typu C lub używania złącza Charging Downstream – zakres prądu wyjściowego – mikro1.

Zdecydowanie ZALECANE są urządzenia ze złączem USB typu C zgodne ze standardem DisplayPort. POWINNY BYĆ ZALECANE Szybkie przesyłanie danych przez USB. Zdecydowanie ZALECANE są też korzystanie z funkcji Power Delivery w celu wymiany ról użytkownika i danych.

Urządzenia z dowolnymi portami typu A lub AB NIE MOGĄ być wysyłane z adapterem konwertującym z tego portu na gniazdo typu C.

MUSI rozpoznawać zdalnie połączone urządzenia MTP (Media Transfer Protocol) i udostępniać ich zawartość za pomocą intencji ACTION_GET_CONTENT , ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT, jeśli platforma Storage Access Framework (SAF) jest obsługiwana.

W przypadku używania portu USB typu C i obsługi trybu peryferyjnego MUSISZ zaimplementować funkcję podwójnego portu USB typu C zgodnie ze specyfikacją USB typu C (sekcja 4.5.1.3.3).

Jeśli funkcja Dual Role Port jest obsługiwana, zaimplementuj model Try.*, który najlepiej pasuje do konstrukcji urządzenia. Na przykład urządzenie przenośne POWINNO obsługiwać model Try.SNK.

7.8 Audio

7.8.1 mikrofon

W aplikacjach z Androidem na telefony komórkowe, zegarek i samochody MUSZĄ zawierać mikrofon.

Implementacje na urządzeniu MOGĄ pominąć mikrofon. Jeśli jednak implementacja urządzenia pominie mikrofon, NIE MOŻE zgłaszać stałej funkcji android.hardware.microphone i MUSI zaimplementować interfejs API do nagrywania dźwięku w sposób niewymagający żadnych działań (zgodnie z sekcją 7). Natomiast w urządzeniach, które mają mikrofon:

MUSI zgłosić stałą funkcję android.hardware.microphone.
MUSI spełniać wymagania dotyczące nagrywania dźwięku opisane w sekcji 5.4.
MUSI spełniać wymagania dotyczące opóźnienia dźwięku opisane w sekcji 5.6.
Zdecydowanie ZALECANE jest korzystanie z nagrywania bliskiego ultradźwięków zgodnie z opisem w sekcji 7.8.3.

7.8.2 Wyjście audio

Urządzenia z Androidem Watch MOGĄ mieć wyjście audio.

Implementacje urządzeń obejmujące głośnik lub wyjście audio/multimedialne z wyjściem audio/multimedialnym jako urządzenia peryferyjnego jako zestaw słuchawkowy lub głośnik zewnętrzny:

MUSI zgłaszać stałą wartość funkcji android.hardware.audio.output.
MUSI spełniać wymagania dotyczące odtwarzania dźwięku opisane w sekcji 5.5.
MUSI spełniać wymagania dotyczące opóźnienia dźwięku opisane w sekcji 5.6.
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 natomiast implementacja urządzenia nie obejmuje portu głośnika ani portu wyjściowego audio, NIE MOŻE zgłaszać funkcji wyjścia android.hardware.audio i MUSI implementować interfejsy API związane z wyjściem audio przynajmniej w sposób niewymagający operacji.

Implementacja na zegarku Android Watch MOŻE mieć wyjście audio, ale inne sposoby implementacji na urządzeniach z Androidem MUSZĄ mieć wyjście audio i zadeklarować wartość android.hardware.audio.output.

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ądzenie ma 4-kanałowe gniazdo słuchawek 3, 5 mm:

MUSI obsługiwać odtwarzanie dźwięku ze słuchawkami stereo i stereofonicznymi słuchawkami z mikrofonem. POWINNA obsługiwać nagrywanie dźwięku z zestawów słuchawkowych stereo z mikrofonem.
MUSI obsługiwać wtyczki audio TRRS w kolejności wypięcia CTIA. POWINNA obsługiwać wtyczki audio w kolejności pin-out OMTP.
MUSI obsługiwać wykrywanie mikrofonu w podłączonym akcesorium audio, jeśli implementacja urządzenia obsługuje mikrofon, i przesyłać parametr android.intent.action.HEADSET_PLUG z dodatkową wartością mikrofonu ustawioną na 1.
MUSI obsługiwać wykrywanie i mapowanie kodów klawiszy w następujących 3 zakresach równoważnej impedancji między mikrofonem a przewodnikami uziemiającymi we wtyczce audio:
- Nie więcej niż 70 omów : KEYCODE_HEADSETHOOK
- 210–290 Ohm : KEYCODE_VOLUME_UP
- 360–680 Ohm : KEYCODE_VOLUME_DOWN
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
MUSI uruchamiać ACTION_HEADSET_PLUG po włożeniu wtyczki, ale dopiero wtedy, gdy wszystkie kontakty podłączone do wtyczki dotykają odpowiednich segmentów gniazda.
Musi być w stanie napędzać co najmniej 150 mV ± 10% napięcia wyjściowego na głośniku o impedancji 32 om.
Napięcie odchylenia mikrofonu MUSI mieć zakres od 1,8 V do 2,9 V.

7.8.3 Prawie ultradźwiękowy

Dźwięk Near ultradźwiękowy to pasmo 18,5–20 kHz. Implementacje urządzenia MUSZĄ prawidłowo informować o obsłudze funkcji dźwięku bliskiego ultradźwięku 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:
- Średnia moc reakcji mikrofonu w paśmie 18,5–20 kHz MUSI być niższa niż 15 dB poniżej wartości 2 kHz.
- 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 parametr PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „true”, średnia odpowiedź głośnika w zakresie 18,5–20 kHz MUSI być nie mniejsza niż 40 dB poniżej odpowiedzi przy 2 kHz.

7.9. Rzeczywistość wirtualna

Android udostępnia interfejsy API i obiekty do tworzenia „rzeczywistości wirtualnej” aplikacje (VR), w tym wysokiej jakości rzeczywistość wirtualną 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

Implementacje urządzeń mobilnych z Androidem, które obsługują tryb dla aplikacji VR, który obsługuje stereoskopowe renderowanie powiadomień i wyłącza komponenty interfejsu monokularnego systemu, podczas gdy aplikacja VR MUSI zadeklarować funkcję android.software.vr.mode. Urządzenia deklarujące tę funkcję MUSZĄ zawierać aplikację z włączoną funkcją android.service.vr.VrListenerService, którą aplikacje VR mogą włączyć za pomocą android.app.Activity#setVrModeEnabled .

7.9.2. Rzeczywistość wirtualna o wysokiej wydajności

Implementacje urządzeń mobilnych z Androidem MUSZĄ obsługiwać obsługę wysokiej wydajności rzeczywistości wirtualnej przez dłuższy okres czasu za pomocą flagi funkcji android.hardware.vr.high_performance i spełniać poniższe wymagania.

Implementacje urządzeń MUSZĄ mieć co najmniej 2 rdzenie fizyczne.
Implementacje urządzeń MUSZĄ zadeklarować funkcję android.software.vr.mode.
Implementacje na urządzeniach MOGĄ mieć wyłączny rdzeń aplikacji na pierwszym planie i MOGĄ obsługiwać interfejs Process.getUniqueCores API w celu zwracania 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 umożliwiać uruchamianie niektórych procesów jądra w razie potrzeby.
Implementacje na urządzeniach MUSZĄ obsługiwać tryb stałej wydajności.
Implementacje na urządzeniu MUSZĄ obsługiwać standard OpenGL ES 3.2.
Implementacje na urządzeniu MUSZĄ obsługiwać sprzęt Vulkan poziomu 0 i POWINNY obsługiwać sprzęt Vulkan na poziomie 1.
Implementacje na urządzeniu MUSZĄ obsługiwać EGL_KHR_mutable_render_buffer i EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync i EGL_KHR_wait_sync, tak aby można było ich używać w trybie współdzielonego bufora, oraz udostępniać rozszerzenia na liście dostępnych rozszerzeń EGL.
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 zamiennym renderowaniem treści VR z 2 kontekstami renderowania bez widocznych artefaktów przerywania działania.
Implementacje na urządzeniu MUSZĄ obsługiwać EGL_IMG_context_Priority i udostępnić rozszerzenie na liście dostępnych rozszerzeń EGL.
Implementacje na urządzeniach MUSZĄ implementować GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 i GL_OVR_multiview_multisampled_render_to_texture oraz udostępniać rozszerzenia na liście dostępnych rozszerzeń GL.
Implementacje na urządzeniu MUSZĄ zawierać implementacje EGL_EXT_protect_content i GL_EXT_protect_textures, tak aby mogły być używane do bezpiecznego odtwarzania tekstur, oraz udostępniać rozszerzenia na liście dostępnych rozszerzeń EGL i GL.
Implementacje urządzeń MUSZĄ 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).
Implementacje urządzenia MUSZĄ obsługiwać HEVC i VP9. MUSZĄ dekodować z szybkością co najmniej 1920 x 1080 przy 30 kl./s przy 10 Mb/s i MUSZĄ dekodować z szybkością 3840 x 2160 przy 30 kl./s do 20 Mb/s (odpowiednik 4 instancji 1930 x 1080 Mb/s).
Zdecydowanie ZALECANE są rozwiązania, które obsługują funkcję android.hardware.sensor.hifi_sensors i MUSZĄ spełniać wymagania dotyczące żyroskopu, akcelerometru i magnesometru dla urządzeń android.hardware.hifi_sensors.
Implementacje urządzenia MUSZĄ obsługiwać interfejs HardwareWłaściwości.getDeviceTemperatures API i zwracać dokładne wartości temperatury skóry.
Implementacja na urządzeniu MUSI mieć wbudowany ekran, a jego rozdzielczość MUSI co najmniej FullHD(1080p) i ZALECNIE ZALECANE JEST QuadHD (1440p) lub wyższa.
Wyświetlacz MUSI mieć rozmiar od 4,7 cala i 6 cali po przekątnej.
W trybie VR ekran MUSI aktualizować się z częstotliwością co najmniej 60 Hz.
Czas opóźnienia wyświetlania w przypadku kolorów szarości na szarość, bieli na czarny i czarnego na biały MUSI wynosić ≤ 3 ms.
Wyświetlacz MUSI obsługiwać tryb małej trwałości o trwałości wynoszącym ≤5 ms, a trwałość jest definiowana jako czas, przez jaki piksel emituje światło.
Implementacje urządzenia MUSZĄ obsługiwać Bluetooth 4.2 oraz Bluetooth LE Data Długość rozszerzenia danych w sekcji 7.4.3.

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. Urządzenia Android Watch MUSZĄ spełniać poniższe kryteria.

8.1. Spójność wrażeń użytkownika

Implementacja na urządzeniach MUSI zapewniać bezproblemowy interfejs użytkownika, zapewniając w aplikacjach i grach stałą liczbę klatek i czas reakcji. Implementacje na urządzeniach MUSZĄ spełniać następujące wymagania:

Stałe opóźnienie klatek . Niespójne opóźnienie renderowania klatki lub opóźnienie renderowania klatek NIE MOGĄ występować częściej niż 5 klatek na sekundę i POWINNY być poniżej 1 klatek na sekundę.
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.
Przełączanie zadań W przypadku uruchomienia wielu aplikacji ponowne uruchomienie aplikacji już uruchomionej po uruchomieniu MUSI potrwać mniej niż 1 sekundę.

8.2. Skuteczność dostępu do plików

Implementacje urządzeń MUSZĄ zapewnić spójność wydajności dostępu do plików w pamięci wewnętrznej w przypadku operacji odczytu i zapisu.

Zapis sekwencyjny . Implementacje na urządzeniu MUSZĄ zadbać o wydajność zapisu sekwencyjnego na poziomie co najmniej 5 MB/s w przypadku pliku 256 MB z buforem zapisu o wielkości 10 MB.
Zapis losowy . Implementacje na urządzeniu MUSZĄ zapewnić wydajność zapisu losowego na poziomie co najmniej 0,5 MB/s w przypadku pliku 256 MB z buforem zapisu o wielkości 4 KB.
Odczyt sekwencyjny . Implementacja na urządzeniu MUSI zapewniać wydajność sekwencyjnego odczytu na poziomie co najmniej 15 MB/s w przypadku pliku 256 MB z buforem zapisu o rozmiarze 10 MB.
Odczyt losowy . Implementacje na urządzeniu MUSZĄ zapewnić wydajność odczytu losowego na poziomie co najmniej 3,5 MB/s w przypadku pliku 256 MB z buforem zapisu o rozmiarze 4 KB.

8.3. Tryby oszczędzania energii

W Androidzie 6.0 wprowadzono tryby czuwania aplikacji i uśpienia, by zoptymalizować wykorzystanie baterii. Wszystkie aplikacje zwolnione z tych trybów MUSZĄ być widoczne dla użytkowników. Ponadto algorytmy wyzwalania, konserwacji, wybudzania i używania globalnych ustawień systemu w tych trybach oszczędzania energii nie mogą odbiegać od zasad projektu Android Open Source.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ WŁĄCZYĆ dowolny lub wszystkie 4 stany mocy uśpionych zgodnie z definicją w konfiguracji zaawansowanej i interfejsie zasilania (ACPI). Jeśli jednak zastosowano stany zasilania S3 i S4, te stany mogą wprowadzać tylko po zamknięciu 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ę. W związku z tym implementacje urządzeń:

MUSI być w stanie śledzić zużycie energii przez komponenty sprzętowe i przypisywać je do konkretnych aplikacji. W szczególności chodzi o implementacje:
- MUSI podać profil zasilania dla poszczególnych komponentów, 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 dokumentacją projektu Android Open Source.
- MUSI podawać wszystkie wartości zużycia energii w miliiamperach godzin (mAh).
- MUSI być przypisana do samego komponentu sprzętowego, jeśli nie można przypisać do aplikacji zużycia energii przez komponent sprzętowy.
- MUSI raportować 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 udostępnić informacje o zużywaniu energii za pomocą polecenia powłoki adb shell dumpsys batterystats deweloperowi aplikacji.
MUSI spełniać intencję android.intent.action.POWER_USAGE_SUMMARY i wyświetlać menu ustawień pokazujące to zużycie energii.

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 MUSZĄ obsługiwać tryb stałej wydajności, który może zapewnić głównej aplikacji na pierwszym planie spójny poziom wydajności przez dłuższy czas w przypadku żądania za pomocą metody interfejsu API Window.setSustainedPerformanceMode(). Implementacja na urządzeniu MUSI prawidłowo informować o obsłudze trybu zrównoważonej wydajności za pomocą metody interfejsu API PowerManager.isSustainedPerformanceModeSupported().

Implementacje urządzeń z co najmniej 2 rdzeniami procesora POWINNY BYĆ DOSTĘPNE co najmniej jeden wyłączny rdzeń, który można zarezerwować dla aplikacji najwyższego poziomu. Jeśli jest podany, implementacje MUSZĄ spełniać te wymagania:

Implementacje MUSZĄ raportować za pomocą metody API Process.getExclusiveCores() numery identyfikacyjne wyłącznych rdzeni, które mogą zostać zarezerwowane przez aplikację znajdującą się na pierwszym planie.
Implementacje urządzeń MUSZĄ jedynie zezwalać na procesy w przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację na uruchamianie na wyłącznych rdzeniach. MOGĄ jednak umożliwić uruchomienie niektórych procesów jądra w razie potrzeby.

Jeśli implementacja urządzenia nie obsługuje wyłącznego rdzenia, MUSI zwracać pustą listę za pomocą metody interfejsu API Process.getExclusiveCores().

9. Zgodność modelu zabezpieczeń

Implementacje urządzeń MUSZĄ wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień w interfejsach API w dokumentacji dla programistów aplikacji na Androida. Implementacje urządzeń MUSZĄ obsługiwać instalację samodzielnie podpisanych aplikacji bez konieczności uzyskania dodatkowych pozwoleń/certyfikatów od innych firm/instytucji. Zgodne urządzenia MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w tych podpunktach.

9.1. Uprawnienia

Implementacje na urządzeniach MUSZĄ obsługiwać model uprawnień Androida zdefiniowany w dokumentacji dla deweloperów aplikacji na Androida. W szczególności implementacje MUSZĄ wymuszać każde uprawnienie zdefiniowane w sposób opisany w dokumentacji pakietu SDK. żadne uprawnienia nie mogą zostać pominięte, zmienione ani zignorowane. Implementacje MOGĄ dawać dodatkowe uprawnienia, o ile ciągi nowych identyfikatorów uprawnień nie znajdują się w przestrzeni nazw android.*.

Uprawnienia z wartością protectionLevel „PROTECTION_FLAG_PRIVILEGED” MOŻNA przyznawać tylko aplikacjom wstępnie wczytanym na liście dozwolonych ścieżek uprzywilejowanych obrazu systemu, takich jak ścieżka system/priv-app w implementacji AOSP.

Uprawnienia z poziomem ochrony „Niebezpieczne” to uprawnienia w czasie działania. Aplikacje z targetSdkVersion > 22 wysyłanie o niej prośby w czasie działania. Implementacje na urządzeniach:

MUSI wyświetlać 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.
MUSI mieć tylko jedną implementację obu interfejsów użytkownika.
NIE MOŻE przyznawać żadnych uprawnień w czasie działania wstępnie zainstalowanym 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.

9.2. UID i izolacja procesów

Implementacje urządzeń MUSZĄ obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja działa jako unikalny identyfikator UID w stylu Unixstyle i w osobnym procesie. Implementacje na urządzeniu MUSZĄ obsługiwać wiele aplikacji z tym samym identyfikatorem użytkownika Linuksa, o ile aplikacje są prawidłowo podpisane i skonstruowane, zgodnie z opisem w dokumentacji zabezpieczeń i uprawnień.

9.3. Uprawnienia systemu plików

Implementacje na urządzeniu MUSZĄ obsługiwać model uprawnień dostępu do plików na Androidzie zgodnie z opisem w artykule o zabezpieczeniach i uprawnieniach.

9.4. Alternatywne środowiska wykonawcze

Implementacje na urządzeniach MOGĄ obejmować środowiska wykonawcze, w których uruchamia się aplikacje przy użyciu innego oprogramowania lub technologii niż Dalvik Executable Format lub kod natywny. Jednak takie alternatywne środowiska wykonawcze NIE MOGĄ naruszać modelu zabezpieczeń Androida ani bezpieczeństwa zainstalowanych aplikacji na Androida, jak opisano w tej sekcji.

Alternatywne środowiska wykonawcze MUSZĄ być aplikacjami na Androida i być zgodne ze standardowym modelem zabezpieczeń Androida zgodnie z opisem w sekcji 9.

Alternatywne środowiska wykonawcze NIE MOGĄ mieć dostępu do zasobów chronionych uprawnieniami, które nie są wymagane w pliku AndroidManifest.xml środowiska wykonawczego za pomocą tagu <uses-permission> .

Alternatywne środowiska wykonawcze NIE MOGĄ zezwalać aplikacjom na korzystanie z funkcji chronionych uprawnieniami Androida, które są ograniczone do aplikacji systemowych.

Alternatywne środowiska wykonawcze MUSZĄ być zgodne z modelem piaskownicy Androida. A konkretnie alternatywne środowiska wykonawcze:

NALEŻY instalować aplikacje za pomocą PackageManagera w oddzielnych piaskownicach Androida (identyfikatory użytkowników systemu Linux itp.).
MOŻE udostępnić jedną piaskownicę Androida współużytkowaną przez wszystkie aplikacje korzystające z alternatywnego środowiska wykonawczego.
Zainstalowane aplikacje korzystające z alternatywnego środowiska wykonawczego NIE MOGĄ wykorzystywać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida korzystających z udostępnianego identyfikatora użytkownika i certyfikatu podpisywania.
NIE MOGĄ uruchamiać aplikacji w piaskownicy odpowiadających innym aplikacjom na Androida, przyznawać im do nich dostępu ani przyznawać im do nich dostępu.
NIE MOŻNA uruchamiać aplikacji przy użyciu ani przyznawać innym aplikacjom żadnych uprawnień superużytkownika (roota) ani żadnego innego identyfikatora użytkownika.

Pliki .apki alternatywnych środowisk wykonawczych MOGĄ być uwzględnione w obrazie systemowym implementacji urządzenia, ale MUSZĄ być podpisane kluczem innym niż klucz używany do podpisywania innych aplikacji uwzględnionych w implementacji urządzenia.

Podczas instalowania aplikacji alternatywne środowiska wykonawcze MUSZĄ uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację. Jeśli aplikacja musi korzystać z zasobu urządzenia, do którego są przypisane odpowiednie uprawnienia Androida (takiego jak Aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI poinformować użytkownika, że aplikacja będzie miała dostęp do tego zasobu. Jeśli środowisko wykonawcze nie rejestruje w ten sposób możliwości aplikacji, podczas instalowania aplikacji korzystających z tego środowiska wykonawczego MUSI ono wyświetlać wszystkie uprawnienia samego środowiska wykonawczego.

9.5. Obsługa wielu użytkowników

Ta funkcja jest opcjonalna dla wszystkich typów urządzeń.

Android zapewnia obsługę wielu użytkowników i pełną izolację użytkowników. Implementacje urządzeń MOGĄ obsługiwać wielu użytkowników, ale po włączeniu MUSZĄ spełniać następujące wymagania związane z obsługą wielu użytkowników:

Implementacje urządzeń z Androidem Automotive z włączoną obsługą wielu użytkowników MUSZĄ zawierać konto gościa, które umożliwia korzystanie ze wszystkich funkcji systemu pojazdu bez konieczności logowania się.
Implementacje urządzeń, które nie mają zadeklarowanej flagi funkcji android.hardware.telephony, MUSZĄ 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.
Odwrotnie implementacje urządzeń, w których zadeklarowana jest flaga funkcji android.hardware.telephony, NIE MOGĄ obsługiwać profili z ograniczonym dostępem, ale MUSZĄ być zgodne z implementacją ustawień AOSP umożliwiających /wyłączenie dostępu innych użytkowników do połączeń głosowych i SMS-ów.
W przypadku każdego użytkownika MUSISZ wdrożyć model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień w interfejsach API.
Każda instancja użytkownika na urządzeniu z Androidem MUSI mieć oddzielne i odizolowane katalogi pamięci zewnętrznej. Implementacje na urządzeniach MOGĄ przechowywać na tym samym woluminie lub w tym samym systemie plików. Implementacja urządzenia MUSI jednak mieć pewność, że aplikacje należące do danego użytkownika i uruchomione w jego imieniu nie mogą wyświetlać, odczytywać ani zapisywać danych należących do innych użytkowników. Pamiętaj, że nośniki wymienne, takie jak gniazda kart SD, mogą umożliwić jednemu użytkownikowi dostęp do danych innego użytkownika przy użyciu komputera PC. Z tego powodu, jeśli obsługa wielu użytkowników jest włączona, implementacje urządzeń, które do obsługi interfejsów API pamięci zewnętrznej korzystają z nośników wymiennych, MUSZĄ szyfrować zawartość karty SD przy użyciu klucza zapisanego wyłącznie na nośniku niewymiennym dostępnym tylko dla systemu. 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. W związku z tym implementacje urządzeń MOGĄ BYĆ, ale NIE powinny włączać obsługi wielu użytkowników, jeśli korzystają z nośników wymiennych jako podstawowej pamięci zewnętrznej.

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. Implementacje urządzenia, które deklarują obsługę android.hardware.telephony, MUSZĄ 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. SELinux lub inne funkcje zabezpieczeń skonfigurowane na platformie Androida:

MUSI zachować zgodność z istniejącymi aplikacjami.
NIE MOŻE mieć widocznego interfejsu użytkownika po wykryciu i zablokowaniu naruszenia bezpieczeństwa, ale MOŻE wyświetlać interfejs użytkownika w przypadku wystąpienia niezablokowanego naruszenia zabezpieczeń, które spowoduje udany lukę w zabezpieczeniach.
NIE POWINNO być konfigurowalne dla użytkownika ani programisty.

Jeśli dowolny interfejs API służący do konfigurowania zasad jest dostępny dla aplikacji, która może mieć wpływ na inną aplikację (taką jak interfejs Device Administration API), ten interfejs API NIE MOŻE zezwalać na konfiguracje powodujące niezgodność.

Urządzenia MUSZĄ wdrożyć system SELinux lub, jeśli używasz jądra innego niż Linux, równoważny system obowiązkowej kontroli dostępu. Urządzenia MUSZĄ również spełniać poniższe wymagania, które są spełnione przez implementację referencyjną w nadrzędnym projekcie Android Open Source.

Implementacje na urządzeniach:

MUSI ustawić SELinux na tryb globalnego wymuszania.
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.
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 nigdy, zarówno w domenach AOSP SELinux, jak i w domenach konkretnych urządzeń/dostawców.
MUSI podzielić platformę multimediów na wiele procesów, aby można było węższy dostęp do każdego z nich, zgodnie z opisem na stronie projektu Android Open Source.

Implementacje na urządzeniach MUSZĄ zachować domyślną zasadę SELinux znajdującą się w folderze systemowym/sepolicy nadrzędnego projektu Android Open Source projektu i dodawać do tej zasady jedynie na potrzeby własnej konfiguracji na danym urządzeniu. Implementacje urządzeń MUSZĄ być zgodne z nadrzędnym projektem Android Open Source.

Urządzenia MUSZĄ wdrożyć mechanizm piaskownicy aplikacji jądra, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnych zasad 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.

9.8. Prywatność

Jeśli urządzenie ma wdrożoną funkcję, która rejestruje treści wyświetlane na ekranie lub nagrywa strumień audio odtwarzany na urządzeniu, MUSI stale powiadamiać użytkownika, gdy ta funkcja jest włączona i powoduje aktywne nagrywanie/nagrywanie.

Jeśli implementacja urządzenia ma mechanizm, który domyślnie kieruje ruch związany z danymi sieci przez serwer proxy lub bramę VPN (na przykład wstępne ładowanie usługi VPN z uprawnieniami android.permission.Control_VPN), przed włączeniem tego mechanizmu implementacja urządzenia MUSI prosić użytkownika o zgodę. Nie dotyczy to sieci VPN włączanej przez kontroler zasad dotyczących urządzeń za pomocą narzędzia DevicePolicyManager.setAlwaysOnVpnPackage(). W takim przypadku użytkownik nie musi wyrazić osobnej zgody, ale MUSI jedynie wyrazić zgodę.

Implementacje urządzeń MUSZĄ być wysyłane z pustym dodanym przez użytkownika magazynem urzędu certyfikacji. MUSZĄ wstępnie zainstalować te same certyfikaty główne dla zaufanego systemu, które są dostarczone w źródłowym projekcie Android Open Source.

Jeśli urządzenia są kierowane przez VPN lub zainstalowany jest główny urząd certyfikacji użytkownika, implementacja MUSI wyświetlać ostrzeżenie z informacją, że ruch w sieci może być monitorowany przez użytkownika.

Jeśli implementacja urządzenia ma port USB z obsługą trybu urządzenia peryferyjnego USB, MUSI wyświetlić interfejs użytkownika z prośbą o zgodę, zanim będzie mógł korzystać z pamięci współdzielonej przez port USB.

9.9. Szyfrowanie magazynu danych

Opcjonalne w przypadku implementacji na urządzeniach z Androidem bez bezpiecznego ekranu blokady.

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady zgodnie z opisem w sekcji 9.11.1, urządzenie MUSI obsługiwać szyfrowanie danych prywatnych aplikacji (partycja danych) i partycji pamięci współdzielonej aplikacji (partycja /sdcard), o ile jest ona trwałą, niemożliwą do usunięcia częścią urządzenia.

W przypadku urządzeń, które obsługują szyfrowanie przechowywania danych, i wydajność kryptografii standardu AES (Advanced Encryption Standard) powyżej 50 MiB/s, szyfrowanie miejsca na dane MUSI być domyślnie włączone, gdy użytkownik zakończy rozruchową konfigurację. Jeśli implementacja urządzenia została już wprowadzona we wcześniejszej 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.

Implementacje urządzeń MUSZĄ spełniać podane wyżej wymagania dotyczące szyfrowania danych dzięki wdrożeniu szyfrowania opartego na plikach (FBE).

9.9.1. Bezpośredni rozruch

Wszystkie urządzenia MUSZĄ wdrożyć interfejsy API bezpośredniego rozruchu, nawet jeśli nie obsługują szyfrowania pamięci. W szczególności intencje LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED muszą być nadal transmitowane, aby sygnalizować aplikacjom świadomym rozruchu, że dla użytkownika dostępne są lokalizacje pamięci masowej zaszyfrowane na urządzeniu (DE) lub Credential Encrypted (CE).

9.9.2. Szyfrowanie oparte na plikach

Implementacje urządzeń obsługujące FBE:

MUSI uruchomić się bez pytania użytkownika o dane logowania i zezwolić aplikacjom rozpoznającym bezpośrednie rozruchy na dostęp do pamięci zaszyfrowanej na urządzeniu (DE) po wysłaniu komunikatu LOCKED_BOOT_COMPLETED.
TRZEBA zezwolić na dostęp do pamięci masowej Credential Encrypted (CE) tylko po odblokowaniu urządzenia przez użytkownika, podając dane logowania (np. hasło, kod PIN, wzór lub odcisk palca) i wysłany komunikat ACTION_USER_UNLOCKED. Implementacje na urządzeniu NIE MOGĄ dawać żadnej metody odblokowywania pamięci chronionej CE bez podania danych logowania użytkownika.
MUSI obsługiwać weryfikację podczas uruchamiania i upewnić się, że klucze DE są kryptograficznie powiązane ze sprzętowym głównym źródłem zaufania urządzenia.
MUSI obsługiwać szyfrowanie zawartości pliku przy użyciu AES z kluczem 256-bitowym w trybie XTS.
MUSI obsługiwać szyfrowanie nazwy pliku za pomocą AES o długości klucza 256-bitowego w trybie CBC-CTS.
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.
TREŚCI MUSZĄ umożliwiać wykrywanie najważniejszych aplikacji (np. Alarm, Telefony, Messenger) przy bezpośrednim rozruchu.

Klucze chroniące obszary przechowywania CE i DE:

MUSI być kryptograficznie powiązana ze sprzętowym magazynem kluczy. Klucze CE muszą być powiązane z danymi logowania na ekranie blokady użytkownika. Jeśli użytkownik nie określił żadnych danych logowania na ekranie blokady, klucze CE MUSZĄ być powiązane z domyślnym hasłem.
MUSI być niepowtarzalny i niepowtarzalny. Oznacza to, że żaden klucz CE lub DE użytkownika nie może pasować do żadnego klucza CE lub DE innego użytkownika.

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

Implementacje urządzeń obsługujące pełne szyfrowanie dysku (FDE). MUSI używać AES z kluczem 128-bitowym (lub większym) i trybem zaprojektowanym do przechowywania (np. AES-XTS, AES-CBC-ESSIV). Klucza szyfrowania NIE MOŻNA zapisywać w pamięci bez szyfrowania. Klucz szyfrowania POWINNY być zaszyfrowany w AES za pomocą algorytmu powolnego rozciągania (np. PBKDF2 lub scrypt), chyba że jest używany podczas aktywnego użytkowania. Jeśli użytkownik nie podał danych logowania na ekranie blokady lub wyłączył możliwość używania kodu dostępu do szyfrowania, system POWINNY jest używać domyślnego kodu dostępu do opakowania klucza szyfrowania. Jeśli urządzenie udostępnia sprzętowy magazyn kluczy, algorytm rozciągania haseł MUSI być z nim powiązany kryptograficznie. Klucza szyfrowania NIE MOŻNA wysyłać poza urządzenie (nawet jeśli jest zapakowane razem z hasłem 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 urządzenia MUSZĄ poprawnie zgłaszać za pomocą metody interfejsu 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ę, MUSI:

Zadeklaruj flagę funkcji platformy android.software.Verified_boot.
Przeprowadź weryfikację przy każdej sekwencji rozruchu.
Rozpocznij weryfikację od stałego klucza sprzętowego, który jest podstawą zaufania, i przejdź aż do partycji systemowej.
Wdróż każdy etap weryfikacji, aby na następnym etapie sprawdzać integralność i autentyczność wszystkich bajtów, zanim wykonasz kod w kolejnym.
Stosuj algorytmy weryfikacji tak silne, jak aktualne zalecenia NIST w zakresie algorytmów haszowania (SHA-256) i rozmiarów kluczy publicznych (RSA-2048).
NIE MOŻE umożliwiać dokończenia rozruchu w przypadku niepowodzenia weryfikacji systemu, chyba że użytkownik mimo to zgodzi się na próbę uruchomienia. W takim przypadku danych z niezweryfikowanych bloków pamięci masowej NIE NALEŻY używać.
NIE MOŻE zezwalać na modyfikowanie zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokuje program rozruchowy.

Główny projekt Android Open Source Project zapewnia preferowaną implementację tej funkcji na podstawie funkcji dm-verity jądra systemu Linux.

Od Androida 6.0 implementacje kryptograficzne oparte na standardzie AES (Advanced Encryption Standard) o wydajności powyżej 50 MiB/s MUSZĄ obsługiwać weryfikację podczas uruchamiania, 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.

Wszystkie implementacje urządzeń z Androidem MUSZĄ spełniać następujące wymagania:

NIE POWINNO ograniczać liczby kluczy, które można wygenerować,i MUSI umożliwiać zaimportowanie co najmniej 8192 kluczy.
Uwierzytelnianie na ekranie blokady MUSI ograniczać liczbę prób i MUSI mieć algorytm wzrastającego ponowienia. Powyżej 150 nieudanych prób opóźnienie MUSI wynosić co najmniej 24 godziny.
Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady, MUSI utworzyć kopię zapasową implementacji magazynu kluczy za pomocą bezpiecznego sprzętu i spełniać te wymagania:
- MUSI zawierać oparte na sprzęcie implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcje skrótu rodziny MD5, SHA1, SHA-2, aby prawidłowo obsługiwać algorytmy obsługiwane przez system magazynu kluczy Android.
- MUSI przeprowadzać uwierzytelnianie ekranu blokady na bezpiecznym sprzęcie i tylko wtedy, gdy uda się uzyskać dostęp do kluczy powiązanych z uwierzytelnianiem. Nadrzędny projekt Android Open Source udostępnia platformę Gatekeeper Hardware Abstraction Layer (HAL), która może zostać użyta w celu spełnienia tego wymogu.

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

Implementacje urządzeń MOGĄ dodać lub zmodyfikować metody uwierzytelniania potrzebne do odblokowania ekranu, ale MUSZĄ spełniać te wymagania:

Metoda uwierzytelniania oparta na znanym obiekcie tajnym NIE MOŻE być traktowana jako bezpieczny ekran blokady, chyba że spełnia wszystkie te wymagania:
- Entropia najkrótszej dozwolonej długości danych wejściowych MUSI być większa niż 10 bitów.
- Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18 bitów.
- NIE MOŻE zastępować żadnej z istniejących metod uwierzytelniania (kodu PIN, wzoru, hasła) zaimplementowanego i przekazanego w AOSP.
- MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących 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 .
Metoda uwierzytelniania, która opiera się na fizycznym tokenie lub lokalizacji, NIE MOŻE być traktowana jako bezpieczny ekran blokady, chyba że spełnia wszystkie te wymagania:
- Musi mieć mechanizm awaryjności umożliwiający użycie jednej z głównych metod uwierzytelniania, która opiera się na znanym obiekcie tajnym i spełnia wymagania traktowania jako bezpiecznego ekranu blokady.
- Funkcja MUSI być wyłączona i zezwalać na odblokowywanie ekranu przez główne uwierzytelnianie tylko wtedy, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasadę za pomocą metody DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) lub DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_UNSPECIFIED .
Metoda uwierzytelniania, która korzysta z danych biometrycznych, NIE MOŻE być traktowana jako bezpieczny ekran blokady, chyba że spełnia wszystkie te wymagania:
- Musi mieć mechanizm awaryjności umożliwiający użycie jednej z głównych metod uwierzytelniania, która opiera się na znanym obiekcie tajnym i spełnia wymagania traktowania jako bezpiecznego ekranu blokady.
- MUSI być wyłączona i zezwalać podstawowe uwierzytelnianie na odblokowanie ekranu tylko wtedy, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawi zasadę funkcji zabezpieczenia hasłem, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT).
- 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 .
Jeśli metody uwierzytelniania nie można traktować jako bezpiecznego ekranu blokady:
- MUSI zwracać wartość false w przypadku metod KeyguardManager.isKeyguardSecure() i KeyguardManager.isDeviceSecure().
- MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) ustawiła zasady jakości haseł za pomocą metody DevicePolicyManager.setPasswordQuality() o bardziej restrykcyjnej stałej jakości niż PASSWORD_QUALITY_UNSPECIFIED .
- NIE MOŻE resetować liczników czasu wygaśnięcia haseł ustawionych przez usługę DevicePolicyManager.setPasswordExpirationTimeout().
- NIE MOŻE uwierzytelniać dostępu do magazynów kluczy, jeśli aplikacja wywołała KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)).
Jeśli metoda uwierzytelniania opiera się na fizycznym tokenie, lokalizacji lub danych biometrycznych o wyższym wskaźniku fałszywej akceptacji niż wymagana przez czujniki linii papilarnych zgodnie z opisem w sekcji 7.3.10, to:
- NIE MOŻE resetować liczników czasu wygaśnięcia haseł ustawionych przez usługę DevicePolicyManager.setPasswordExpirationTimeout().
- NIE MOŻE uwierzytelniać dostępu do magazynów kluczy, jeśli aplikacja wywołała KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).

9.12. Usuwanie danych

Urządzenia MUSZĄ udostępniać użytkownikom mechanizm przywracania danych fabrycznych który umożliwia logiczne i fizyczne usuwanie wszystkich danych z wyjątkiem tych:

Obraz systemu
wszystkie pliki systemu operacyjnego wymagane przez obraz systemu,

Wszystkie dane użytkowników MUSZĄ usunąć. MUSI spełniać odpowiednie standardy branżowe dotyczące usuwania danych, takie jak NIST SP800-88. MUSI być używana do implementacji interfejsu API wymazania danych() (część interfejsu Android Device Administration API) opisanego w sekcji 3.9 Administrowanie urządzeniem.

Urządzenia MOGĄ szybko wyczyścić dane i przeprowadzić logiczne usuwanie danych.

9.13. Tryb bezpiecznego rozruchu

Android zapewnia tryb, w którym użytkownicy mogą uruchamiać się 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.

Zdecydowanie ZALECANE są implementacje urządzeń z Androidem w celu zaimplementowania trybu bezpiecznego rozruchu i spełnienia tych wymagań:

Implementacje na urządzeniu MUSZĄ umożliwiać użytkownikowi włączenie trybu bezpiecznego rozruchu z menu rozruchu, do którego dostęp jest uzyskiwany w ramach przepływu pracy innego niż normalny proces uruchamiania.
Implementacje na urządzeniu MUSZĄ umożliwiać użytkownikowi przejście w tryb bezpiecznego rozruchu w taki sposób, aby aplikacje innych firm zainstalowane na urządzeniu nie zakłócały jego działania. Wyjątkiem jest sytuacja, gdy aplikacja innej firmy jest kontrolerem zasad dotyczących urządzeń i ma ustawioną wartość „prawda” UserManager.DISALLOW_SAFE_BOOT.
Implementacje na urządzeniu MUSZĄ umożliwiać użytkownikowi odinstalowanie wszelkich aplikacji innych firm w trybie awaryjnym.

9.14. Izolacja systemu samochodowego

Oczekuje się, że urządzenia z Androidem Automotive będą wymieniać dane z najważniejszymi podsystemami pojazdu, np. przez wykorzystanie interfejsu HAL pojazdu do wysyłania i odbierania wiadomości przez sieci pojazdu, takie jak magistrala CAN. Implementacje na urządzeniach z Androidem Automotive MUSZĄ wdrożyć funkcje zabezpieczeń poniżej warstw platformy Android, aby zapobiegać złośliwej lub przypadkowej interakcji między platformą Androida, aplikacjami innych firm i podsystemami pojazdu. Oto te funkcje zabezpieczeń:

Ochrona wiadomości z podsystemów pojazdu Android Framework, np. umieszczanie dozwolonych typów wiadomości i źródeł wiadomości na liście dozwolonych.
Monitorowanie ataków typu DoS za pomocą platformy Androida lub aplikacji innych firm. Zapewnia to ochronę przed złośliwym oprogramowaniem zapełniającym sieć pojazdu ruchami, które może prowadzić do awarii podsystemów pojazdu.

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 ostatecznego oprogramowania do wysyłki dostępnego na urządzeniu. 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 7.0 może zostać wydanych wiele 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. na przykład jeśli urządzenie ma akcelerometr, MUSI prawidłowo wykonać test akcelerometru w narzędziu CTS Verifier. 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 7.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.

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:

Historia zmian dokumentu

Aby zobaczyć podsumowanie zmian w sekcjach dotyczących poszczególnych osób:

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 zmiany związane z kompilacją.

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.