Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.

Ta strona została przetłumaczona przez Cloud Translation API.

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

Definicja zgodności z Androidem 4.1
Wersja 3
Ostatnia aktualizacja: 24 czerwca 2013 r.
Copyright © 2012, Google Inc. Wszelkie prawa zastrzeżone.
compatibility@android.com
Spis treści
1. Wprowadzenie
2. Zasoby
3. Oprogramowanie
3.1. Zarządzana zgodność z interfejsem API
3 .2. Zgodność z miękkim interfejsem API
3.2.1. Uprawnienia
3.2.2. Parametry tworzenia3 .2.3.
Zgodność z zamiarem
3.2.3.1. Intencje aplikacji podstawowej
3.2.3.2. Zastąpienia intencji
3.2.3.3. Przestrzenie nazw intencji
3.2.3.4. Intencje transmisji
3.3. Zgodność z natywnym interfejsem API
3.3.1 Interfejsy binarne aplikacji
3.4. Zgodność z przeglądarką internetową
3.4.1. Zgodność WebView
3.4.2. Zgodność z przeglądarką
3.5. Zgodność behaworialna interfejsu API
3.6. Przestrzenie nazw interfejsu API
3.7. Zgodność z maszynami wirtualnymi
3.8. Zgodność interfejsu użytkownika zwymaganiami
3.8.1. Widgety
3.8.2. Powiadomienia
3.8.3. Sieć wyszukiwania
3.8.4. Toasty
3.8.5. Motywy
3.8.6. Live Wal papers
3.8.7. Najnowsza wersja aplikacji Display
3 .8.8. Zarządzanie wejściami Ustawienia
3.8.9. Ekran blokady – zdalne sterowanie
3.9 Administrowanie urządzeniem
3.10 Ułatwienia dostępu
3.11 Tekst na mowę
4. Zgodność opakowania aplikacji
5. Zgodność multimedialna
5.1. Kodeki multimedialne
5.2. Kodowanie wideo
5.3. Nagranie dźwiękowe
5.4. Czas oczekiwania na dźwięk
5.5. Protokoły sieciowe
6. Developer Tool Compatibility
7. Zgodność sprzętowa
7.1. Wyświetlacz i grafika
7.1.1. Konfiguracja ekranu
7.1.2. Dane z sieci reklamowej
7.1.3. Ustawienia orientacji ekranu
7.1.4. Akceleracja grafiki 2D i 3D
7 .1.5. Starsza wersja aplikacji tryb zgodności
7.1.6. Typy ekranów
7.1.7. Technologia ekranu
7.2. W sekcji Urządzenia do wprowadzania danych
7.2.1. Klawiatura
7.2.2. Nawigacja bezdotykowa
7.2.3. Klawisze nawigacyjne
7.2.4. Dotykowe wprowadzanie danych
7.2.5. Symulowane dane wejściowe dotykowe
7.2.6. Mikrofon
7.3. Czujniki
7.3.1. Akcelerometr

7.3.1. Akcelerometr
7.3.2. Magnetometer
7.3.3. GPS
7.3.4. Żyroskop
7.3.5. Barometer
7.3.6. Termometr
7.3.7. Fotometry
7.3.8. Czujnik zbliżeniowy
7.4. Połączenia danych
7.4.1. Usługi telefoniczne
7.4.2. IEEE 802.11 (Wi-Fi)
7.4.2.1. Wi-Fi Direct
7.4.3. Bluetooth
7.4.4. Komunikacja Near Field Communication
7.4.5. Minimalna funkcjonalność sieci
7.5. Kamera
7.5.1. Tylnyaparat
7.5.2. Przedni aparat
7.5.3. Zachowanie interfejsu Camera API
7.5.4. Orientacja aparatu
7.6. Pamięć i miejsce na dane
7.6.1. Minimalna pamięć i miejsce na dane
7.6.2. Pamięć współdzielona aplikacji
7.7. USB
8. Performance Compatibility
9. Zgodność modelu zabezpieczeń
9.1. Uprawnienia
9.2. Identyfikator UID i Proces Isolation
9.3. Uprawnienia do systemu plików
9.4. Inne środowiska wykonawcze
10. Sprawdzanie zgodności oprogramowania
10.1. Compatibility Test Suite
10.2. CTS Verifier
10.3. Aplikacje referencyjne
11. Uaktualizowane oprogramowanie
12. Contact Us
Appendix A - Bluetooth Test Procedure

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

Użycie słów „must” (musi), „must not” (nie musi), „required” (wymagane), „shal” (shal), „shal not” (shal nie), „should” (powinien), „should not” (nie powinien),
„recommended” (zalecane), „may” (można) i „optional” (opcjonalnie) jest zgodne ze standardem IETF zdefiniowanym w RFC2119
[Zasoby, 1].
W tym dokumencie „wdrożyciel urządzenia” lub „wdrożyciel” to osoba lub organizacja opracowująca rozwiązanie sprzętowe/programowe z Androidem 4.1.
„Wdrożenie na urządzeniu
” lub „wdrożenie” to opracowane rozwiązanie sprzętowo-programowe.
Aby urządzenie było uznawane za zgodne z Androidem 4.1, jego implementacja MUSI spełniać
wymagania podane w tej definicji zgodności, w tym wszelkie dokumenty
uwzględnione w niej.
Jeśli definicja lub testy oprogramowania opisane w sekcji 10 są niejasne,
niejednoznaczne lub niekompletne, odpowiedzialność za zapewnienie
zgodności z dotychczasowymi implementacjami spoczywa na deweloperze implementującym.
Dlatego też projekt Android Open Source [Zasoby, 3] jest zarówno odniesieniem
, jak i preferowaną implementacją Androida.Deweloperzy implementacji na urządzeniach
są�
Chociaż niektóre
komponenty można hipotetycznie zastąpić innymi implementacjami,
zdecydowanie odradzamy tę praktykę, ponieważ przejście testów oprogramowania
będzie znacznie trudniejsze. Obowiązek zapewnienia pełnej zgodności z funkcjonalnością
standardowej implementacji Androida, w tym w ramach pakietu testów zgodności
, spoczywa na implementatorze. Na koniec pamiętaj, że niektóre wymiany i modyfikacje komponentów
są wyraźnie zabronione w tym dokumencie.
2. Materiały
1.  IETF RFC2119 Requirement Levels: http://www.ietf.org/rfc/rfc2119.txt
2.  Omówienie programu zgodności z Androidem:
http://source.android.com/compatibility/index.html
3.  Projekt Android Open Source: http://source.android.com/
4.  Definicje i dokumentacja interfejsu API:
http://developer.android.com/reference/packages.html
5.  Informacje o uprawnieniach Androida:
http://developer.android.com/reference/android/Manifest.permission.html
6.  Informacje o android.os.Build:
http://developer.android.com/reference/android/os/Build.html
7.  Dozwolone ciągi znaków wersji Androida 4.1:
http://source.android.com/compatibility/4.1/versions.html
8.  Renderscript:
http://developer.android.com/guide/topics/graphics/renderscript.html
9.  Akceleracja sprzętowa:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
10.  Klasa android.webkit.WebView:
http://developer.android.com/reference/android/webkit/WebView.html
11.  HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12.  Możliwości offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13.  Tag wideo HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14.  HTML5/interfejs API W3C do określania lokalizacji: http://www.w3.org/TR/geolocation-API/
15.  HTML5/W3C webdatabase API: http://www.w3.org/TR/webdatabase/
16.  HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
17.  Specyfikacja maszyny wirtualnej Dalvik: dostępna w źródle Androida
dalvik/docs
18.  Widgety aplikacji:
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19.  Powiadomienia:
http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20.  Zasoby aplikacji: http://code.google.com/android/reference/available-
resources.html
21.  Przewodnik po stylu ikon na pasku stanu:
http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22.  Menedżer wyszukiwania:
http://developer.android.com/reference/android/app/SearchManager.html
23.  Toasty: http://developer.android.com/reference/android/widget/Toast.html
24.  Motywy: http://developer.android.com/guide/topics/ui/themes.html

25.  Klasa R.style: http://developer.android.com/reference/android/R.style.html
26.  Tapety na żywo: http://developer.android.com/resources/articles/live-
wal papers.html
27.  Administracja urządzenia z Androidem:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  android.app.admin.DevicePolicyManager class:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29.  Interfejsy API usługi dostępności Androida:
http://developer.android.com/reference/android/accessibilityservice/package-
summary.html
30.  Interfejsy API dostępności Androida:
http://developer.android.com/reference/android/view/accessibility/package-
summary.html
31.  Projekt Eyes Free: http://code.google.com/p/eyes-free
32.  API Text-To-Speech:
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33.  Dokumentacja narzędzia (dla adb, aapt, ddms):
http://developer.android.com/guide/developing/tools/index.html
34.  Opis pliku APK na Androida:
http://developer.android.com/guide/topics/fundamentals.html
35.  Pliki manifestu: http://developer.android.com/guide/topics/manifest/manifest-
intro.html
36.  Narzędzie do testowania Monkey:
https://developer.android.com/studio/test/other-testing-tools/monkey
37.  Klasa Android android.content.pm.PackageManager i funkcje sprzętowe
Lista:
http://developer.android.com/reference/android/content/pm/PackageManager.html
38.  Obsługa wielu ekranów:
http://developer.android.com/guide/practices/screens_support.html
39.  android.util.DisplayMetrics:
http://developer.android.com/reference/android/util/DisplayMetrics.html
40.  android.content.res.Configuration:
http://developer.android.com/reference/android/content/res/Configuration.html
41.  android.hardware.SensorEvent:
http://developer.android.com/reference/android/hardware/SensorEvent.html
42.  Bluetooth API:
http://developer.android.com/reference/android/bluetooth/package-summary.html
43.  Protokół NDEF Push: http://source.android.com/compatibility/ndef-push-
protocol.pdf
44.  MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45.  MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46.  MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47.  MIFARE MF0ICU2:
http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48.  MIFARE AN130511:
http://www.nxp.com/documents/application_note/AN130511.pdf
49.  MIFARE AN130411:
http://www.nxp.com/documents/application_note/AN130411.pdf
50.  Interfejs API orientacji aparatu:
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51.  android.hardware.Camera:
http://developer.android.com/reference/android/hardware/Camera.html
52.  Urządzenia peryferyjne z Androidem Open:
http://developer.android.com/guide/topics/usb/accessory.html
53.  Interfejs API hosta USB: http://developer.android.com/guide/topics/usb/host.html
54.  Informacje o bezpieczeństwie i uprawnieniach w Androidzie:
http://developer.android.com/guide/topics/security/security.html
55.  Aplikacje na Androida: http://code.google.com/p/apps-for-android
56.  Klasa android.app.DownloadManager:
http://developer.android.com/reference/android/app/DownloadManager.html
57.  Android File Transfer: http://www.android.com/filetransfer
58.  Formaty multimediów na Androidzie: http://developer.android.com/guide/appendix/media-
formats.html
59.  HTTP Live Streaming Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-
live-streaming-03
60.  Przenoszenie połączenia NFC: http://www.nfc-
forum.org/specs/spec_list/#conn_handover
61.  Łączenie Bluetooth Secure Simple za pomocą NFC: http://www.nfc-
forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62.  Interfejs Wifi Multicast API:
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

63.  Asystent działań:
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64.  Specyfikacja ładowania przez USB:
http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65.  Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66.  Android USB Audio:
http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67.  Ustawienia udostępniania NFC na Androidzie:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68.  Wifi Direct (Wifi P2P):
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69.  Klient sterowania multimediami:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  Motion Event API:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  Konfiguracja dotykowego wejścia: http://source.android.com/tech/input/touch-
devices.html
Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z Androida 4.1 SDK
i będzie funkcjonalnie identyczne z informacjami w dokumentacji tego SDK. W każdym
przypadku, gdy ta definicja zgodności lub zestaw testów zgodności są niezgodne z
dokumentacją pakietu SDK, za wiarygodną uznaje się dokumentację pakietu SDK. Wszelkie
szczegóły techniczne podane w wymienionych powyżej materiałach są
uważane za część tej definicji zgodności.
3. Oprogramowanie
3.1. Zgodność z interfejsem API zarządzanym
Zarządzane środowisko wykonywania (oparte na Dalviku) jest głównym sposobem uruchamiania aplikacji na Androida
. Interfejs programowania aplikacji (API) Androida to zbiór interfejsów
platformy Androida udostępnionych aplikacjom działającym w środowisku zarządzanej maszyny wirtualnej
. Wdrożenia na urządzeniu MUSZĄ zawierać pełne wdrożenia,
w tym wszystkie opisane zachowania, wszystkich zdokumentowanych interfejsów API udostępnionych przez pakiet SDK Androida
4.1 [Resources, 4].
Implementacje na urządzeniu MNIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów API ani podpisów
, odbiegać od udokumentowanego zachowania ani zawierać operacji niemających żadnego efektu, z wyjątkiem sytuacji, w których
jest to wyraźnie dozwolone przez tę definicję zgodności.
Ta definicja zgodności umożliwia pominięcie przez implementacje urządzenia interfejsów API Androida
przeznaczonych dla niektórych typów sprzętu. W takich przypadkach interfejsy API MUSZĄ
być nadal dostępne i działać w rozsądny sposób. W sekcji 7 znajdziesz szczegółowe
wymagania dotyczące tego scenariusza.
3.2. Zgodność z interfejsami API o zwiększonej kontroli
Oprócz interfejsów API zarządzanych wymienionych w sekcji 3.1 Android zawiera również ważne
interfejsy API o zwiększonej kontroli, które działają tylko w czasie wykonywania. Dotyczy to na przykład intencji, uprawnień i
innych aspektów aplikacji na Androida, których nie można wymusić w czasie kompilacji aplikacji
.
3.2.1. Uprawnienia
Wdrożyciele na urządzeniach MUSZĄ obsługiwać i stosować wszystkie stałe uprawnienia zgodnie z dokumentacją
na stronie referencyjnej Uprawnienia [Zasoby, 5]. Uwaga: sekcja 10
zawiera dodatkowe wymagania dotyczące modelu zabezpieczeń Androida.
3.2.2. Parametry kompilacji
Interfejsy API Androida zawierają w klasie android.os.Build
[Zasoby, 6] kilka stałych wartości, które służą do opisu bieżącego urządzenia. Aby zapewnić spójne i
znaczeniowe wartości we wszystkich implementacjach na urządzeniach,w tabeli poniżej podano dodatkowe
ograniczenia dotyczące formatów tych wartości, z którymi implementacje na urządzeniach MUSZĄ
się zgodzać.
Parametr
Komentarze
Wersja aktualnie działającego systemu Android w czytelnym dla człowieka formacie. To pole MUSI zawierać jedno
android.os.Build.VERSION.RELEASE
z wartości ciągu zdefiniowanych w [Resources, 7].
Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm.
android.os.Build.VERSION.SDK
W przypadku Androida 4.1 to pole MUSI mieć wartość całkowitą 16.

Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm.
android.os.Build.VERSION.SDK_INT
W przypadku Androida 4.1 to pole MUSI mieć wartość całkowitą 16.
Wartość wybrana przez implementatora urządzenia, która oznacza wersję systemu Android
obecnie uruchomionego w czytelnym dla człowieka formacie. Tej wartości NIE MOŻNA używać ponownie w przypadku różnych wersji udostępnionych użytkownikom
android.os.Build.VERSION.INCREMENTAL
. Typowe zastosowanie tego pola to wskazanie, który numer kompilacji lub identyfikator zmiany w kontroli źródłowej został
użyty do wygenerowania kompilacji. Nie ma wymagań dotyczących formatu tego pola, z tym że MUSI
być niezerowy i nie może być pusty (\"\").
Wartość wybrana przez implementatora urządzenia, identyfikująca konkretny sprzęt wewnętrzny używany przez urządzenie, w formacie
czytelnym dla człowieka. Możliwe zastosowanie tego pola to wskazanie konkretnej wersji płyty głównej
android.os.Build.BOARD
na urządzeniu. Wartość tego pola MUSI być kodowalna jako 7-bitowy ASCI i pasować do wyrażenia regularnego
"^[a-zA-Z0-9.,_-]+$".
Wartość wybrana przez implementatora urządzenia identyfikująca nazwę firmy, organizacji, osoby itp.
, która wyprodukowała urządzenie, w formacie zrozumiałym dla człowieka. Możliwe zastosowanie tego pola to wskazanie OEM
android.os.Build.BRAND
lub operatora, który sprzedał urządzenie. Wartość tego pola MUSI być kodowana jako 7-bitowy kod ASCI i pasować do wyrażenia regularnego
„^[a-zA-Z0-9.,_-]+$”.
Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3: Natywne interfejsy API
android.os.Build.CPU_ABI
Zgodność
Nazwa drugiego zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3: Natywne
android.os.Build.CPU_ABI2
API Zgodność
Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretną konfigurację lub wersję korpusu
android.os.Build.DEVICE
(czasami nazywany „przemysłowym wzornictwem”) urządzenia. Wartość tego pola MUSI być kodowalna jako 7-bitowa
ASCI i pasować do wyrażenia regularnego „^[a-zA-Z0-9.,_-]+$”.
Ciąg znaków jednoznacznie identyfikujący tę wersję. POWINNA być w rozsądnym stopniu czytelna dla człowieka. Musi ona spełniać te wymagania:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Na przykład:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
W fingerprincie nie można używać znaków spacji.
Jeśli inne pola w tym szablonie zawierają znaki odstępu
, należy je zastąpić w odciskach palców wersji innym znakiem, np. podkreśleniem
(„_”). Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCI.
Nazwa sprzętu (z poziomu wiersza poleceń jądra lub katalogu /proc). Powinien być zrozumiały dla człowieka
android.os.Build.HARDWARE
Wartość tego pola MUSI być kodowana jako 7-bitowy ASCI i pasować do wyrażenia regularnego „^[a-
zA-Z0-9.,_-]+$”.
Ciąg znaków jednoznacznie identyfikujący hosta, na którym została utworzona kompilacja, w formatowalnym dla człowieka formacie. Nie ma
android.os.Build.HOST
wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono być równe 0 ani pustemu ciągowi znaków („"”).
Identyfikator wybrany przez implementatora urządzenia, aby odwoływać się do konkretnej wersji, w formie zrozumiałej dla człowieka. To
pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINNA mieć wartość
android.os.Build.ID
wystarczająco zrozumiałą dla użytkowników, aby odróżnić różne wersje oprogramowania. Wartość tego pola MUSI być kodowalna w formacie 7-bitowej kodyfikacji ASCI i pasować do wyrażenia regularnego „^[a-zA-Z0-9.,_-]+$”.
Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu.
Nie ma wymagań dotyczących
android.os.Build.MANUFACTURER
formatu tego pola, z tym że NIE MOŻE to być zero lub pusty ciąg znaków („"").
Wartość wybrana przez implementatora urządzenia zawierająca nazwę urządzenia znaną użytkownikowi końcowemu. Ta
android.os.Build.MODEL
powinna być taka sama jak nazwa, pod którą urządzenie jest sprzedawane użytkownikom. Nie ma
wymagań dotyczących formatu tego pola, z wyjątkiem tego, że nie może być on równy 0 ani nie może być pustym ciągiem znaków („"”).
Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową produktu
android.os.Build.PRODUCT
(SKU). MUSI być zrozumiały dla człowieka, ale nie musi być widoczny dla użytkowników. Wartość tego
pola MUSI być kodowana jako 7-bitowy kod ASCI i pasować do wyrażenia regularnego „^[a-zA-Z0-9.,_-]+$”.
Numer seryjny sprzętu (jeśli jest dostępny). Wartość tego pola MUSI być kodowana jako 7-bitowy ASCI i pasować do
android.os.Build.SERIAL
wyrażenia regularnego „^([a-zA-Z0-9]{0,20})$”.
Lista tagów wybranych przez implementatora urządzenia, oddzielonych przecinkami, które dodatkowo odróżniają wersję.
android.os.Build.TAGS
na przykład „unsigned,debug”. Wartość tego pola MUSI być kodowalna jako 7-bitowy ASCI i pasować do wyrażenia regularnego
"^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME
Wartość reprezentująca sygnaturę czasową kompilacji.
Wartość wybrana przez implementatora urządzenia, która określa konfigurację środowiska uruchomieniowego kompilacji. W tym polu
NALEŻY podać jedną z wartości odpowiadających 3 typowym konfiguracjom środowiska uruchomieniowego Androida: „user” (użytkownik),
android.os.Build.TYPE
„userdebug” lub „eng”. Wartość tego pola MUSI być kodowana jako 7-bitowy ASCI i pasować do wyrażenia regularnego
„^[a-zA-Z0-9.,_-]+$”.
Nazwa lub identyfikator użytkownika (lub użytkownika zautomatyzowanego), który wygenerował wersję.
android.os.Build.USER
Nie ma wymagań dotyczących formatu tego pola, z tym że nie może ono być równe 0 ani pustym ciągowi znaków („"”).
3.2.3. Zgodność z intencją
Wdrożenia na urządzeniu MUSZĄ uwzględniać system intencji o luźnym powiązaniu w Androidzie, jak

opisane w sekcjach poniżej. „Spełnianie” oznacza, że implementator urządzenia
MUSI udostępnić aktywność lub usługę Androida, która określa pasujący filtr intencji oraz
wiąże się z właściwym działaniem dla każdego określonego wzorca intencji.
3.2.3.1. Główne intencje aplikacji
Projekt Android upstream definiuje kilka podstawowych aplikacji, takich jak kontakty,
kalendarz, galeria zdjęć, odtwarzacz muzyki itp. Implementujący urządzenie MOŻE zastąpić
te aplikacje ich alternatywnymi wersjami.
Wszystkie takie alternatywne wersje MUSZĄ uwzględniać te same wzorce intencji
z poprzedniego projektu. Jeśli na przykład urządzenie zawiera alternatywny odtwarzacz muzyki,
musi on nadal obsługiwać wzór intencji określony przez aplikacje innych firm w celu wybrania utworu.
Te aplikacje są uważane za podstawowe aplikacje systemu Android:
Zegary
Przeglądarka
Kalendarze
Kontakty
Galeria
Wyszukiwarka globalna
Ikona
Muzyka
Ustawienia
Podstawowe aplikacje systemu Android obejmują różne komponenty aktywności lub usługi
, które są uważane za „publiczne”. Oznacza to, że atrybut „android:exported” może być nieobecny lub może mieć wartość „true” (prawda).

W przypadku każdej aktywności lub usługi zdefiniowanej w jednej z podstawowych aplikacji systemu Android, która nie jest
oznaczona jako niepubliczna za pomocą atrybutu android:exported o wartości „false”, implementacje na urządzeniu
MUSZĄ zawierać komponent tego samego typu, który implementuje te same
wzorce filtra intencji co podstawowa aplikacja systemu Android.
Innymi słowy, implementacja na urządzeniu MOŻE zastąpić podstawową aplikację systemu Android;
jeśli tak się stanie, implementacja na urządzeniu MUSI obsługiwać wszystkie wzorce filtra intencji zdefiniowane
przez każdą podstawową aplikację systemu Android, którą zastępuje.
3.2.3.2. Zastąpienia intencji
Ponieważ Android jest platformą rozszerzalną, implementacje na urządzeniach MUSZĄ zezwalać na zastąpienie przez aplikacje innych firm każdego wzorca intencji
wymienionego w sekcji 3.2.3.2.
Implementacja w górę źródeł Androida na licencji open source umożliwia to domyślnie; implementatorzy
urządzeń NIE MOGĄ dołączać specjalnych uprawnień do aplikacji systemowych korzystających z
tych wzorów intencji ani blokować aplikacji innych firm w zakresie wiązania się z tymi wzorami i przejmowania nad nimi kontroli.
Zakaz ten obejmuje w szczególności
wyłączenie interfejsu „Wybór”, który umożliwia użytkownikowi wybór spośród kilku
aplikacji obsługujących ten sam wzorzec intencji.
Niektóre implementacje urządzeń mogą jednak udostępniać domyślne działania w przypadku określonych wzorów adresów URI
(np. http://play.google.com), jeśli domyślne działanie zapewnia bardziej szczegółowy filtr
dla adresu URI danych. Na przykład filtr intencji określający URI danych
"http://www.android.com" jest bardziej szczegółowy niż filtr przeglądarki dla ciągu „http://”. Wdrożenia na urządzeniu
MUSZĄ zawierać interfejs użytkownika, który umożliwia modyfikowanie domyślnej aktywności
dla zamiarów.
3.2.3.3. Nazwy przestrzeni nazw intencji
Wdrożenia na urządzeniu NIE mogą zawierać żadnych komponentów Androida, które obsługują jakiekolwiek
nowe wzorce intencji lub intencji rozgłoszeniowych za pomocą działania, kategorii lub innego klucza
string w nazwie przestrzeni android.* lub com.android.*. Implementujący na urządzeniu NIE MOŻE
uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub intencji rozgłoszeniowych
z użyciem działania, kategorii lub innego kluczowego ciągu znaków w przestrzeni pakietu należącej do innej organizacji.
Implementatorzy urządzeń NIE MOGĄ zmieniać ani rozszerzać żadnych wzorów intencji
używanych przez podstawowe aplikacje wymienione w sekcji 3.2.3.1. Wdrożenia na urządzeniu MOŻE
obejmować wzorce intencji korzystające z przestrzeni nazw wyraźnie i wyraźnie powiązanych z ich
własną organizacją.
Ta blokada jest analogiczna do tej określonej w sekcji
3.6 dotyczącej klas języka Java.
3.2.3.4. Rozgłaszanie intencji
Aplikacje innych firm polegają na platformie, aby rozgłaszać określone intencje, aby powiadomić je

o zmianach w środowisku sprzętowym lub programowym. Urządzenia zgodne z Androidem
MUSZĄ nadawać publiczne intencje w odpowiedzi na odpowiednie zdarzenia
systemowe. Intencje przesyłania są opisane w dokumentacji pakietu SDK.
3.3. Zgodność z natywnymi interfejsami API
3.3.1 Interfejsy binarne aplikacji
Zarządzany kod działający w Dalvik może wywoływać kod natywny z pliku aplikacji
.apk jako plik ELF .so skompilowany dla odpowiedniej architektury sprzętowej urządzenia.
Ponieważ kod natywny jest w dużej mierze zależny od podstawowej technologii procesora, Android
definiuje w NDK Androida (w pliku
docs/CPU-ARCH-ABIS.html) kilka interfejsów binarnych aplikacji (ABI). Jeśli implementacja urządzenia jest zgodna z jednym lub większą liczbą
określonych interfejsów ABI, TO POWINNA być zgodna z NDK Androida, jak opisano poniżej.
Jeśli implementacja urządzenia zawiera obsługę interfejsu ABI Androida, musi:
MUSI zawierać obsługę kodu działającego w scentralizowanym środowisku, aby wywoływać
kod natywny za pomocą standardowej składni interfejsu JNI (Java Native Interface).
MUSI być zgodny ze źródłem (czyli z pliku nagłówka) i z binarnym interfejsem (w przypadku interfejsu ABI) każdej z wymaganych bibliotek na liście poniżej.
MUSI prawidłowo raportować interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pomocą interfejsu android.os.Build.CPU_ABI.
MUSI raportować tylko te interfejsy ABI, które są opisane w najnowszej wersji Androida NDK w pliku docs/CPU-ARCH-ABIS.txt.
MUSI być skompilowany za pomocą kodu źródłowego i plików nagłówka dostępnych w upstreamowym projekcie open source Androida.
W przypadku aplikacji zawierających kod natywny interfejsy API muszą być dostępne za pomocą:
libc (biblioteka C)
libm (biblioteka matematyczna)
Minimalna obsługa C++
Interfejs JNI
liblog (logowanie na Androidzie)
libz (kompresja Zlib)
libdl (linker dynamiczny)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (zarządzanie natywnym obszarem OpenGL)
libjnigraphics.so
libOpenSLES.so (obsługa dźwięku OpenSL ES 1.0.1)
libOpenMAXAL.so (obsługa OpenMAX AL 1.0.1)
libandroid.so (obsługa aktywności natywnej Androida)
Obsługa OpenGL zgodnie z opisem poniżej
Uwaga: przyszłe wersje Androida NDK mogą zawierać obsługę dodatkowych interfejsów ABI.

Jeśli implementacja urządzenia nie jest zgodna z dotychczasowym wstępnie zdefiniowanym ABI,
NIE MOŻE raportować obsługi żadnego ABI .
Zgodność z kodem natywnym jest trudna do osiągnięcia. Po raz kolejny prosimy o to, aby deweloperzy urządzeń
używali implementacji bibliotek wymienionych powyżej
, aby zapewnić zgodność.
3.4. Zgodność z przeglądarką
3.4.1. Zgodność z WebView
Implementacja na Androida w wersji open source korzysta z obsługi renderowania WebKit do
implementowania interfejsu android.webkit.WebView. Ponieważ niemożliwe jest opracowanie
kompleksowego zestawu testów dla systemu renderowania stron internetowych, implementatorzy urządzeń MUSZĄ użyć
konkretnej kompilacji WebKit w implementacji WebView. W szczególności:
implementacje android.webkit.WebView na urządzeniu MUSZĄ
być oparte na wersji 534.30 pakietu WebKit z gałęzi źródłowej kodu źródłowego Androida Open Source
na potrzeby Androida 4.1. Ta kompilacja zawiera określony zestaw funkcji i poprawek zabezpieczeń
dla WebView. Deweloperzy urządzeń mogą dodawać własne funkcje do implementacji
WebKit. Nie mogą jednak zmieniać
zachowania WebView, w tym renderowania.
Ciąg klienta użytkownika zwracany przez WebView MUSI mieć taki format:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
Wartość ciągu $(VERSION) MUSI być taka sama jak wartość

Wartość ciągu $(VERSION) MUSI być taka sama jak wartość
android.os.Build.VERSION.RELEASE
Wartość ciągu $(LOCALE) MUSI być zgodna z konwencjami ISO dla
kodu kraju i języka oraz MUSI odnosić się do bieżącego skonfigurowanego lokalu
urządzenia.
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
W implementacji urządzenia można pominąć ciąg „Mobile” w kliencie użytkownika
Komponent WebView MUSI obsługiwać jak najwięcej funkcji HTML5
[Resources, 11]. W minimalnej implementacji na urządzeniu MUSI być obsługiwany każdy z tych interfejsów API
powiązanych z HTML5 w komponencie WebView:
pamięć podręczna aplikacji/działanie offline [Resources, 12]
tag <video> [Resources, 13]
lokalizacja geograficzna [Resources, 14]
Dodatkowo w implementacji na urządzeniu MUSI być obsługiwany interfejs API webstorage HTML5/W3C
[Resources, 15], a powinien być obsługiwany interfejs API IndexedDB HTML5/W3C [Resources,
16]. Pamiętaj, że organizacje zajmujące się standardami rozwoju sieci przechodzą na korzystanie z
IndexedDB zamiast webstorage. IndexedDB ma stać się wymaganą
częścią w przyszłej wersji Androida.
Interfejsy API HTML5, podobnie jak interfejsy API JavaScript, MUSZĄ być domyślnie wyłączone w komponencie WebView.
Nie dotyczy to sytuacji,gdy deweloper wyraźnie je włączy za pomocą zwykłych interfejsów API Androida.
3.4.2. Zgodność z przeglądarką
Wdrożenia na urządzeniu MUSZĄ obejmować samodzielną aplikację przeglądarki do ogólnego
przeglądania stron internetowych. Samodzielna przeglądarka MOŻE być o zasadzie oparte na technologii przeglądarki
innej niż WebKit. Nawet jeśli używana jest inna aplikacja przeglądarki, komponent
android.webkit.WebView udostępniany aplikacjom innych firm MUSI
być oparty na WebKit, zgodnie z opisem w sekcji 3.4.1.
W implementacjach MOŻNA wysyłać niestandardowy ciąg znaków klienta użytkownika w samodzielnej aplikacji przeglądarki
.
Samodzielna aplikacja przeglądarki (oparta na aplikacji WebKit Browser
lub na zamienniku od zewnętrznego dostawcy) MUSI obsługiwać jak najwięcej funkcji
HTML5 [Resources, 11]. W minimalnej implementacji na urządzeniu MUSI być obsługiwany
każdy z tych interfejsów API powiązanych z HTML5:
pamięć podręczna aplikacji/operacje offline [Resources, 12]
tag <video> [Resources, 13]
lokalizacja geograficzna [Resources, 14]
W dodatkowej implementacji na urządzeniu MUSI być obsługiwany interfejs API webstorage HTML5/W3C
[Resources, 15], a NALEŻY obsługiwać interfejs API IndexedDB HTML5/W3C [Resources,
16]. Pamiętaj, że organizacje opracowujące standardy dotyczące tworzenia stron internetowych przechodzą na
IndexedDB zamiast webstorage, dlatego IndexedDB ma stać się wymaganą
częścią Androida w przyszłej wersji.
3.5. Zgodność zachowań interfejsu API
Zachowania każdego z typów interfejsu API (zarządzanego, miękkiego, natywnego i internetowego) muszą być
zgodne z preferowaną implementacją projektu Androida open source
[Zasoby, 3]. Dotyczy to na przykład:
Urządzenia NIE MOGĄ zmieniać zachowania ani semantyki standardowego zamiaru
Devices NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu
elementu systemu (np. usługi, aktywności, dostawcy treści itp.)
Urządzenia NIE MOGĄ zmieniać semantyki standardowego uprawnienia
Powyższa lista nie jest pełna. Pakiet Compatibility Test Suite (CTS) testuje
znaczące części platformy pod kątem zgodności behawioralnej, ale nie wszystkich .
Obowiązkiem implementatora jest zapewnienie zgodności z zachowaniem aplikacji Android
Open Source. Z tego powodu implementujący powinni w miarę możliwości używać kodu źródłowego
dostępnego w ramach projektu Android Open Source, a nie ponownie
implementować istotnych części systemu.
3.6. Nazwy przestrzeni nazw API
Android przestrzega konwencji dotyczących nazw pakietów i klas zdefiniowanych przez język programowania Java

. Aby zapewnić zgodność z aplikacjami innych firm, implementatorzy
urządzeń MUSZĄ UNIKNĄĆ wprowadzania jakichkolwiek zabronionych modyfikacji (patrz poniżej) w tych przestrzeniach nazw pakietów:
java.*
javax.*
sun.*
android.*
com.android.*

Zabronione modyfikacje:
Implementacje na urządzeniu NIE MOGĄ modyfikować publicznie udostępnionych interfejsów API na platformie
Androida przez zmianę podpisów metod lub klas ani usuwanie
klas lub pól klas.
Implementacje na urządzeniu MOGĄ modyfikować podstawową implementację interfejsów API, ale
takie modyfikacje NIE MOGĄ wpływać na określone zachowanie i podpis
języka Java dowolnego publicznie udostępnionego interfejsu API.
Implementacje na urządzeniu NIE MOGĄ dodawać żadnych publicznie udostępnionych elementów (takich jak
klasy lub interfejsy, pola lub metody do istniejących klas lub interfejsów).

„Publicznie dostępny element” to dowolna konstrukcja, która nie jest ozdobiona znacznikiem „@hide”
, jak to ma miejsce w kodach źródłowych Androida. Innymi słowy, implementatorzy urządzeń
NIE MOGĄ udostępniać nowych interfejsów API ani modyfikować istniejących interfejsów API w przestrzeniach nazw
wymienionych powyżej. Implementatorzy urządzeń MOGĄ wprowadzić modyfikacje tylko na potrzeby wewnętrzne, ale te
modyfikacje NIE MOGĄ być reklamowane ani w inny sposób udostępniane deweloperom.
Implementatorzy urządzeń MOGĄ dodawać niestandardowe interfejsy API, ale nie mogą one być w przestrzeni nazw
należącej do innej organizacji ani do niej odwołującej się. Na przykład implementatorzy
urządzeń NIE MOGĄ dodawać interfejsów API do przestrzeni nazw com.google.* ani podobnych. Mogą to robić tylko
Google. Podobnie Google NIE MOŻE dodawać interfejsów API do przestrzeni nazw
innych firm. Dodatkowo, jeśli implementacja urządzenia zawiera niestandardowe interfejsy API spoza
standardowej przestrzeni nazw Androida, te interfejsy API MUSZĄ być zapakowane w bibliotece współdzielonej Androida
, aby tylko aplikacje, które ich używają (za pomocą mechanizmu <uses-library>
), były objęte zwiększonym zużyciem pamięci przez te interfejsy API.
Jeśli implementator urządzenia zaproponował ulepszenie jednej z wymienionych powyżej przestrzeni nazw pakietów
(np. przez dodanie nowej przydatnej funkcji do istniejącego interfejsu API lub dodanie nowego interfejsu API), powinien odwiedzić stronę source.android.com i rozpocząć proces udostępniania
zmian i kodu zgodnie z informacjami na tej stronie.

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

3.7. Zgodność z maszynami wirtualnymi
Wdrożenia na urządzeniu MUSZĄ obsługiwać pełną specyfikację kodu bajtowego Dalvik (DEX)
i semantykę maszyny wirtualnej Dalvik [Resources, 17].
Wdrożenia na urządzeniu MUSZĄ skonfigurować Dalvik w taki sposób, aby przydzielić pamięć zgodnie z
platformą Android na poziomie źródła i zgodnie z informacjami w tej tabeli. Definicje rozmiaru i gęstości ekranu znajdziesz w
sekcji 7.1.1.
Należy pamiętać, że wartości pamięci określone poniżej są uważane za minimalne, a urządzenie
i implementacja mogą przydzielić więcej pamięci na aplikację.
Rozmiar ekranu
Gęstość pikseli
Pamięć aplikacji
smal  / normal / large
ldpi / mdpi
16 MB
smal  / normal / large
tvdpi / hdpi
32 MB
smal  / normal / large
xhdpi
64 MB
xlarge
mdpi
32 MB
xlarge
tvdpi / hdpi
64 MB
xlarge
xhdpi
128 MB
3.8. Zgodność interfejsu użytkownika
3.8.1. Widżety
Android definiuje typ komponentu i odpowiadające mu interfejsy API oraz cykl życia, które umożliwiają

aplikacjom udostępnianie użytkownikowi końcowemu „widżetu aplikacji” [Resources, 18]. Wersja referencyjnaAndroida
na licencji Open Source zawiera aplikację Launcher, która zawiera elementy interfejsu użytkownika
umożliwiające dodawanie, wyświetlanie i usuwanie widżetów aplikacji na
ekranie głównym.
Wdrożenia na urządzeniu MOGĄ zastępować standardowy program uruchamiający (np.
ekran główny). Alternatywne wygaszacze powinny obsługiwać wbudowane widżety aplikacji
oraz umożliwiać dodawanie, konfigurowanie, wyświetlanie i usuwanie
widżetów bezpośrednio w wygaszaczu. Alternatywne aplikacje wyświetlające MOGĄ nie zawierać tych elementów
interfejsu użytkownika, jednak jeśli tak się dzieje, w ramach implementacji urządzenia MUSI być dostępna osobna aplikacja,z poziomu której użytkownicy mogą dodawać,
konfigurować, wyświetlać i usuwać widżety aplikacji.

Wdrożenia na urządzeniach MUSZĄ umożliwiać renderowanie widżetów o standardowym rozmiarze siatki
4 x 4. Szczegółowe informacje znajdziesz w dokumentacji pakietu SDK Androida
[Zasoby, 18].
3.8.2. Powiadomienia
Android zawiera interfejsy API, które umożliwiają deweloperom powiadamianie użytkowników o istotnych zdarzeniach
[Zasoby, 19], korzystając z funkcji sprzętowych i programowych urządzenia.
Niektóre interfejsy API umożliwiają aplikacjom wysyłanie powiadomień lub przyciąganie uwagi za pomocą sprzętu, w tym dźwięku, wibracji i światła.
Wdrożenia na urządzeniu MUSZĄ
obsługiwać powiadomienia, które korzystają z funkcji sprzętowych, zgodnie z opisem w dokumentacji
pakietu SDK oraz w zakresie możliwości sprzętu wdrożenia.
Na przykład jeśli wdrożenie na urządzeniu obejmuje wibrator, MUSI prawidłowo
implementować interfejs API wibracji. Jeśli implementacja urządzenia nie zawiera sprzętu,
odpowiednie interfejsy API MUSZĄ być zaimplementowane jako no-ops. Szczegółowe informacje na temat tego zachowania
znajdziesz w sekcji 7.
Ponadto w ramach implementacji należy poprawnie wyświetlać wszystkie zasoby (ikony, pliki
dźwięku itp.) udostępnione w interfejsach API [Zasoby, 20] lub w przewodniku po stylach ikony
paska stanu/paska systemowego [Zasoby, 21].Deweloperzy urządzeń mogą zaimplementować
alternatywny system powiadomień, który będzie się różnił od implementacji referencyjnej
w systemie Android Open Source. Takie alternatywne systemy powiadomień MUSZĄ jednak obsługiwać istniejące
zasoby powiadomień, jak opisano powyżej.
Android 4.1 obsługuje powiadomienia multimedialne, np. interaktywne widoki dla
powiadomień ciągłych. Implementacje na urządzeniach MUSZĄ prawidłowo wyświetlać i wykonywać powiadomienia
, zgodnie z dokumentacją interfejsów API Androida.
3.8.3. Wyszukiwanie
Android zawiera interfejsy API [Resources, 22], które umożliwiają deweloperom tworzenie wyszukiwarek w
ich aplikacjach i udostępnianie danych aplikacji w globalnym wyszukiwaniu systemowym.
Ogólnie rzecz biorąc, ta funkcja składa się z jednego interfejsu użytkownika
, który umożliwia użytkownikom wpisywanie zapytań, wyświetlanie sugestii podczas pisania i
wyników. Interfejsy API Androida umożliwiają deweloperom ponowne użycie tego interfejsu do udostępniania wyszukiwania
w ramach własnych aplikacji oraz dostarczanie wyników do wspólnego globalnego
interfejsu wyszukiwania.
Wdrożenia na urządzeniach MUSZĄ zawierać jeden wspólny interfejs użytkownika wyszukiwarki
, który może wyświetlać sugestie w czasie rzeczywistym w odpowiedzi na dane wejściowe użytkownika. Wdrożenia na urządzeniach
muszą implementować interfejsy API, które umożliwiają deweloperom ponowne użycie tego interfejsu użytkownika
w celu udostępnienia wyszukiwania w ich własnych aplikacjach. Wdrożenia na urządzeniach
MUSZĄ implementować interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii do pola wyszukiwania
w trybie wyszukiwania globalnego. Jeśli nie masz
zainstalowanych aplikacji innych firm, które korzystają z tej funkcji, domyślnie powinny wyświetlać się
sugestie i wyniki wyszukiwania w internecie.
3.8.4. Toasty
Aplikacje mogą używać interfejsu Toast API (zdefiniowanego w sekcji [Resources, 23]) do wyświetlania krótkich nie
modalnych ciągów znaków użytkownikowi końcowemu, które znikają po krótkim czasie. Na urządzeniach
musi być zapewniona możliwość wyświetlania komunikatów typu Toast z aplikacji do użytkowników w sposób zapewniający dobrą widoczność
.
3.8.5. Motywy
Android udostępnia „motywy” jako mechanizm umożliwiający aplikacjom stosowanie stylów w całości
aktywności lub aplikacji. W Androidzie 3.0 wprowadzono nowy motyw „Holo” lub „holograficzny”
, który jest zbiorem zdefiniowanych stylów przeznaczonych dla deweloperów aplikacji, którzy chcą dopasować wygląd i wrażenia do motywu Holo określonego w pakiecie Android SDK [Resources, 24].
Urządzenia
NIE MOGĄ zmieniać żadnych atrybutów motywu Holo udostępnionych dla aplikacji

[Zasoby, 25]
W Androidzie 4.0 wprowadzono nowy motyw „Domyślny dla urządzenia” jako zestaw zdefiniowanych stylów dla
programistów aplikacji, którzy chcą dopasować wygląd i wrażenia do motywu
urządzenia zgodnie z definicją implementatora urządzenia. Implementacje na urządzeniu MOGĄ zmodyfikować atrybuty motywu
DeviceDefault udostępniane aplikacjom [Resources, 25].
3.8.6. Animowane tapety
Android definiuje typ komponentu i odpowiadające mu API oraz cykl życia, które umożliwiają
aplikacjom wyświetlanie jednej lub większej liczby „animowanych tapet” użytkownikowi końcowemu [Resources, 26].
Animowane tapety to animacje, wzory lub podobne obrazy z ograniczonymi możliwościami wejścia
, które wyświetlają się jako tapeta za innymi aplikacjami.
Sprzęt jest uznawany za zdolny do niezawodnego wyświetlania tapet na żywo, jeśli może wyświetlać wszystkie tapety na żywo
bez ograniczeń funkcjonalności, przy rozsądnej liczbie klatek na sekundę i bez
negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują, że tapety
lub aplikacje się zawieszają, działają nieprawidłowo, zużywają zbyt dużo energii procesora lub baterii albo
działają z niedopuszczalnie niską liczbą klatek na sekundę, sprzęt jest uznawany za niezdolny do obsługi
tapet na żywo. Na przykład niektóre tapety na żywo mogą używać kontekstu Open GL 1.0 lub 2.0
do renderowania treści. Tapeta na żywo nie będzie działać niezawodnie na sprzęcie, który
nie obsługuje wielu kontekstów OpenGL, ponieważ korzystanie z
kontekstu OpenGL przez tapetę na żywo może wchodzić w kolizję z innymi aplikacjami, które również korzystają z kontekstu OpenGL.
Wdrożenia na urządzeniach, które mogą niezawodnie wyświetlać tapety na żywo zgodnie z opisem powyżej, POWINNY wykorzystywać tapety na żywo.
Wdrożenia na urządzeniach, które nie
działają niezawodnie w przypadku wyświetlania na żywo dokumentów PDF z certyfikatem COVID-19, jak opisano powyżej, NIE MOGĄ stosować wyświetlania na żywo dokumentów PDF z certyfikatem COVID-19.
3.8.7. Wyświetlanie ostatnio używanych aplikacji
Kod źródłowy Androida 4.1 zawiera interfejs użytkownika do wyświetlania ostatnio
używanych aplikacji za pomocą miniatury stanu graficznego aplikacji w momencie
jej ostatniego zamknięcia przez użytkownika. Wdrożenia na urządzeniach MOGĄ zmienić lub
usunąć ten interfejs. W przyszłej wersji Androida planujemy jednak bardziej rozbudowane wykorzystanie tej funkcji.
W przypadku najnowszych aplikacji zdecydowanie
zalecamy korzystanie z interfejsu użytkownika Androida 4.1 (lub podobnego interfejsu opartego na miniaturach
), ponieważ starsze wersje mogą nie być zgodne z
przyszłą wersją Androida.
3.8.8. Ustawienia zarządzania wejściem
Android 4.1 obsługuje mechanizmy zarządzania wejściem. Interfejsy API Androida 4.1
umożliwiają skonfigurowanie niestandardowych aplikacji IME. Wdrożenia na urządzeniach
MUSZĄ zawierać sposób na dostęp do ustawień IME w każdej chwili, gdy wyświetla się IME
, które zapewnia takie ustawienia.
3.8.9. Ekran blokady z dalszym sterowaniem
W Androidzie 4.0 wprowadzono obsługę interfejsu Remote Control API, która umożliwia aplikacjom multimedialnym
integrację z elementami sterującymi odtwarzaniem wyświetlanymi w widoku zdalnym, takim jak ekran blokady urządzenia
[Resources, 69]. Wdrożenia na urządzeniu POWINNY obejmować obsługę
wstawiania elementów sterowania na ekranie blokady urządzenia.
3.9 Zarządzanie urządzeniami
Android 4.1 zawiera funkcje, które umożliwiają aplikacjom z funkcjami zabezpieczeń wykonywanie funkcji
zarządzania urządzeniem na poziomie systemu, takich jak egzekwowanie zasad dotyczących haseł lub
usuwanie danych z urządzenia z dalnie za pomocą interfejsu API Androida do zarządzania urządzeniami [Resources,
27]. Wdrożenia na urządzeniu MUSZĄ zawierać implementację klasy
DevicePolicyManager [Resources, 28] i POWINNY obsługiwać pełny zakres
zasad administracyjnych urządzenia zdefiniowanych w dokumentacji pakietu Android SDK [Resources,
27].
Uwaga: chociaż niektóre z wymienionych powyżej wymagań są oznaczone jako „NALEŻY” w przypadku
Androida 4.1, w przyszłej definicji kompatybilności
zostaną one zmienione na „NALEŻY”. Oznacza to, że te wymagania są opcjonalne w Androidzie 4.1, ale będą
wymagane w przyszłej wersji. Istniejace i nowe urządzenia z Androidem 4.1 bardzo
powinny spełniać te wymagania w Androidzie 4.1, ponieważ w przeciwnym razie
nie będą kompatybilne z Androidem po przejściu na nowszą wersję.
3.1 Ułatwienia dostępu
Android 4.1 zawiera warstwę ułatwień dostępu, która ułatwia poruszanie się po urządzeniu
użytkownikom z niepełnosprawnościami. Android 4.1 udostępnia interfejsy API platformy, które umożliwiają

implementacjom usług ułatwień dostępu odbiór danych o zdarzeniach związanych z użytkownikiem i systemem
oraz generowanie alternatywnych mechanizmów informacji zwrotnej, takich jak odczyt na głos, informacja zwrotna haptyczna
i sterowanie za pomocą trackballa lub panelu dotykowego [Resources, 29]. Device implementations
MUSZĄ zapewnić implementację ram Android Accessibility w sposób zgodny
z domyślną implementacją Androida. W szczególności implementacje na urządzeniach MUSZ
spełniać te wymagania:
Wdrożenia na urządzeniu MUSZĄ obsługiwać usługi ułatwień dostępu innych firm
i implementacje
tych usług za pomocą interfejsu API android.accessibilityservice [Resources,
30].
Wdrożenia na urządzeniu MUSZĄ generować zdarzenia AccessibilityEvents i przekazywać
te zdarzenia do wszystkich zarejestrowanych implementacji AccessibilityService w sposób
zgodny z domyślną implementacją na Androidzie.
Wdrożenia na urządzeniu MUSZĄ udostępniać mechanizm umożliwiający użytkownikom aktywowanie
i wyłączanie usług ułatwień dostępu oraz MUSZĄ wyświetlać ten interfejs w odpowiedzi na intencję android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.
Ponadto na urządzeniach należy zaimplementować
ułatwienia dostępu oraz zapewnić użytkownikom mechanizm
włączania ułatwień dostępu podczas konfigurowania urządzenia. Implementacja usługi ułatwień dostępu typu open source
jest dostępna w ramach projektu Eyes Free [Zasoby, 31].
3.11 Zamiana tekstu na mowę
Android 4.1 zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług zamiany tekstu na mowę (TTS)
, a także umożliwia dostawcom usług implementowanie usług TTS
[Resources, 32]. Implementacje na urządzeniu MUSZĄ spełniać te wymagania dotyczące
tramy TTS na Androida :
Implementacje na urządzeniu MUSZĄ obsługiwać interfejsy API ramy TTS na Androida i
POWINNY zawierać mechanizm TTS obsługujący języki dostępne na
urządzeniu. Pamiętaj, że oprogramowanie na Androida w wersji na potrzeby upstream o źródle otwartym zawiera pełną implementację silnika TTS
.
Implementacje na urządzeniu MUSZĄ obsługiwać instalowanie silników TTS innych firm.
Implementacje na urządzeniu MUSZĄ udostępniać interfejs dostępny dla użytkownika, który pozwala
użytkownikom wybrać silnik TTS do użycia na poziomie systemu.
4. Zgodność z opakowaniem aplikacji
W implementacjach na urządzeniu MUSISZ instalować i uruchamiać pliki „.apk” na Androida wygenerowane przez narzędzie „aapt” zawarte w oficjalnym pakiecie Android SDK [Zasoby, 33].

Implementacje na urządzeniach NIE MOGĄ rozszerzać formatów .apk [zasobów, 34], pliku manifestu Androida
[zasobów, 35], kodu bajtowego Dalvik [zasobów, 17] ani kodu bajtowego renderscript
w taki sposób, aby uniemożliwić ich prawidłową instalację i uruchomienie na innych kompatybilnych urządzeniach.
Implementacje na urządzeniu powinny używać referencyjnej implementacji
Dalvik i systemu zarządzania pakietami
referencyjnej implementacji.
5. Zgodność multimedialna
Wdrożenia na urządzeniu MUSZĄ zawierać co najmniej 1 formę wyjścia audio, taką jak
głośniki, gniazdo słuchawek, połączenie z głośnikami zewnętrznymi itp.
5.1. Kodeki multimedialne
Implementacje na urządzeniu MUSZĄ obsługiwać podstawowe formaty multimediów określone w
dokumentacji pakietu Android SDK [Resources, 58], z wyjątkiem przypadków, w których jest to wyraźnie dozwolone w tym
dokumencie. W szczególności implementacje urządzeń MUSZĄ obsługiwać formaty multimediów,
kodeki, dekodery, typy plików i formaty kontenerów zdefiniowane w tabelach poniżej. Wszystkie
te kodeki są udostępniane jako implementacje oprogramowania w ramach preferowanej implementacji
na Androida w ramach projektu Android Open Source.
Zarówno Google, jak i Open Handset Alliance nie gwarantują
, że te kodeki nie są objęte patentami osób trzecich.
Osoby, które zamierzają używać tego kodu źródłowego w sprzęcie lub oprogramowaniu,
powinny pamiętać, że wdrożenia tego kodu, w tym w oprogramowaniu typu open source
lub shareware, mogą wymagać licencji na patenty od odpowiednich właścicieli patentów.
Należy pamiętać, że te tabele nie zawierają wymagań dotyczących szybkości transmisji danych w przypadku większości kodeków wideo
, ponieważ obecny sprzęt urządzenia niekoniecznie obsługuje szybkość transmisji danych, która jest dokładnie zgodna z wymaganą szybkością transmisji danych określoną w odpowiednich standardach.
Zamiast tego implementacje na urządzeniach
powinny obsługiwać najwyższy możliwy bitrate na sprzęcie, aż do wartości

określonej w specyfikacji.

Typy plików /
Format /
Typ
Kodowanie
Dekodowanie
Szczegóły
Kontener
Kodek
Formaty
Wsparcie
WYMAGANE
mono/stereo/5.0/5.1*
MPEG-4
Wymagane dla implementacji urządzenia
treści z
Profilem AAC
z włączonym mikrofonem
WYMAGANE
standardowym próbkowaniem
(AAC LC)
i definicją
3GPP
o częstotliwości od 8 do 48
android.hardware.microphone.
(.3gp)
kHz.
MPEG-4
Obsługa
(.mp4,
MPEG-4
mono/stereo/5.0/5.1*
.m4a)
HE AAC
treści z
ADTS raw

WYMAGANE
Profile
standardowa próbkowanie
AAC (.aac,
(AAC+)
szybkości od 16 do 48
dekodowanie w
kHz.
Android
3.1 lub nowszy,
obsługa
MPEG-4
WYMAGANA dla urządzenia
kodowania w formatach
mono/stereo/5.0/5.1*
HE AAC v2
implementacji, które obejmują
Android
treści z
Profile
mikrofonem

4.0 lub nowszy, ADIF
standard
(ulepszone
definiowanie
nie
szybkości od 16 do 48
AAC+)
android.hardware.microphone
obsługiwane)
kHz.
MPEG-TS
MPEG-4
(.ts, nie
Audio
WYMAGANE na urządzeniu
Wsparcie dla
możliwości przewijania
Object Type
implementacji,które obejmują
mono/stereo
Android
ER AAC
microphone hardware and
WYMAGANE
z standardem
3.0+)
ELD
define
sampling rates from
(Enhanced
android.hardware.microphone
16 do 48 kHz.
Niska opóźnienie
AAC)
WYMAGANE
Wymagane w implementacji na urządzeniu
4,75–12,2 kbps
AMR-NB
z wbudowanym mikrofonem
WYMAGANE
3GPP (.3gp)
próbkowanie @ 8 kHz
i zdefiniuj
android.hardware.microphone.
WYMAGANE
Wymagane w implementacji na urządzeniu
9 częstotliwości od 6,60
AMR-WB
z uwzględnieniem mikrofonu sprzętowego
WYMAGANE
kbit/s do 23,85 kbit/s
3GPP (.3gp)
i define
próbkowanie @ 16 kHz
android.hardware.microphone.
Mono/Stereo (bez
wielokanalności).
Dźwięk
Częstotliwości próbkowania do
48 kHz (ale do
44,1 kHz
zalecane na
urządzeniach z 44,1
WYMAGANE
FLAC

kHz wyjścia, ponieważ 48
FLAC (.flac) tylko
(Android 3.1+)
do 44,1 kHz
downsampler
nie zawiera filtra niskiej
przepustowości). Zaleca się 16-bitową
. Nie należy stosować ditherowania w przypadku 24-bitowej
.

Mono/Stereo 8-
320Kbps constant
MP3

WYMAGANE
MP3 (.mp3)
(CBR) lub variable
bit-rate (VBR)
Typ 0 i
MIDI Type 0 i 1.
1 (.mid,
DLS Version 1 i
.xmf, .mxmf)
2. XMF i Mobile
RTTTL/RTX
MIDI

WYMAGANE
XMF. Obsługa
(.rtttl, .rtx)
formatów dzwonów
OTA (.ota)
RTTTL/RTX, OTA,
iMelody
i iMelody
(.imy)

Ogg (.ogg)
Vorbis

WYMAGANE

Matroska
(.mkv)
8-bit i 16-bit
linear PCM** (rates
up to limit of
hardware).Devices
MUST support
PCM/WAVE
WYMAGANE
WYMAGANE
WAVE (.wav)
sampling rates for
raw PCM recording
at 8000,16000 and
44100 Hz
frequencies
JPEG
WYMAGANE
WYMAGANE
Base+progressive
JPEG (.jpg)
GIF

WYMAGANE

GIF (.gif)
Image
PNG
WYMAGANE
WYMAGANE

PNG (.png)
BMP

WYMAGANE

BMP (.bmp)
WEBP
WYMAGANE
WYMAGANE

WebP (.webp)
WYMAGANE
Wymagane dla implementacji urządzenia
3GPP
that include camera hardware and
(.3gp)
H.263
WYMAGANE

define android.hardware.camera
MPEG-4
or
(.mp4)
android.hardware.camera.front.
3GPP
(.3gp)
WYMAGANE
MPEG-4
(.mp4)
Wymagane w przypadku implementacji na urządzeniu
MPEG-TS
z uwzględnieniem sprzętu kamery
Profil podstawowy
Wideo
H.264 AVC
WYMAGANE

3GPP (.3gp)
SP
WebM (.webm)
WYMAGANE
i Matroska
VP8

(Android
2.3.3+)
4.0+)
*Uwaga: wymagane jest tylko zmieszanie treści 5.0/5.1; nagrywanie lub renderowanie większej liczby niż 2
kanały jest opcjonalne.

**Uwaga: wymagane jest 16-bitowe linearne przechwytywanie PCM. 8-bitowy linearny PCM
nie jest wymagany.
5.2 Kodowanie wideo
Wdrożenia urządzeń z Androidem, które zawierają tylną kamerę i deklarują
android.hardware.camera, POWINNA obsługiwać te profile kodowania wideo.
HD (jeśli jest obsługiwane przez

sprzęt)
H.264 Baseline
H.264 Baseline
Kodek wideo
H.264 Baseline Profile
Profile
Profile
Wideo
176 x 144 px
480 x 360 px
1280 x 720 px
rozdzielczość
Ramka wideo12 fps
30 fps
30 fps
rate
500 Kbps lub
Prędkość transmisji danych wideo56 Kbps
2 Mbps lub wyższy
wyższy
Kodek audioAAC-LC
AAC-LC
AAC-LC

Dźwięk
1 (mono)
2 (stereo)
2 (stereo)
kanałów
Prędkość transmisji danych audio24 Kbps
128 Kbps
192 Kbps
5.3.
Nagrywanie dźwięku
Gdy aplikacja użyje interfejsu API android.media.AudioRecord do rozpoczęcia nagrywania
strumienia dźwięku, implementacje urządzenia, które zawierają sprzęt mikrofonowy i deklarują
android.hardware.microphone, MUSZĄ próbkować i nagrywać dźwięk z tymi
zachowaniami:
Urządzenie MUSI mieć charakterystyki zbliżone do płaskich amplitudy w stosunku do częstotliwości
(SPL) źródła o częstotliwości 1000 Hz, które daje RMS 2500 dla próbek 16-bitowych.
Poziomy amplitudy PCM MUSZĄ śledzić liniowo zmiany SPL wejściowych
w zakresie co najmniej 30 dB od –18 dB do +12 dB w przypadku 90 dB SPL mikrofonu.
Całkowite zniekształcenie harmoniczne MUSI być mniejsze niż 1% w przypadku 1 kHz przy 90 dB SPL na wejściu.

Oprócz powyższych specyfikacji nagrywania, gdy aplikacja rozpoczęła
nagrywanie strumienia audio za pomocą
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION źródła audio:
przetwarzanie redukcji szumów (jeśli jest dostępne) MUSI być wyłączone.
Automatyczna kontrola wzmocnienia (jeśli jest dostępna) MUSI być wyłączona.
Uwaga: chociaż niektóre z wymienionych powyżej wymagań są oznaczone jako „NALEŻY” w przypadku
Androida 4.1, w przyszłej definicji kompatybilności te wymagania
zostaną zmienione na „NALEŻY”. Oznacza to, że te wymagania są opcjonalne w Androidzie 4.1, ale będą
wymagane w przyszłej wersji. Istniejace i nowe urządzenia z Androidem 4.1 bardzo
powinny spełniać te wymagania w Androidzie 4.1, ponieważ w przeciwnym razie
nie będą kompatybilne z Androidem po przejściu na nowszą wersję.
5.4. Opóźnienie dźwięku
Opóźnienie dźwięku to ogólnie odstęp czasu między momentem, w którym aplikacja poprosi o wykonanie operacji odtwarzania lub nagrywania dźwięku, a momentem, w którym implementacja urządzenia faktycznie rozpocznie tę operację.

Wiele klas aplikacji wymaga krótkich opóźnień, aby uzyskać efekty w czasie rzeczywistym, takie jak efekty dźwiękowe czy komunikacja VoIP.
Wdrożenia na urządzeniu
, które obejmują sprzęt mikrofonowy i deklarują android.hardware.microphone
, POWINNA spełniać wymagania dotyczące opóźnienia dźwięku opisane w tej sekcji. Szczegółowe informacje o warunkach, w których implementacje
urządzeń mogą pominąć sprzęt mikrofonu, znajdziesz w sekcji 7.

W ramach tego rozdziału:
„opóźnienie wyjściowe w trybie zimnym” oznacza opóźnienie między momentem, w którym aplikacja
wysyła żądanie odtwarzania dźwięku, a momentem, w którym głośnik zaczyna odtwarzać
odpowiednią ścieżkę dźwiękową, gdy system audio
był nieaktywny i wyłączony przed wysłaniem żądania.
„Opóźnienie wyjściowe w trybie ciepłym” oznacza opóźnienie między momentem, w którym aplikacja
wysyła żądanie odtwarzania dźwięku, a momentem, w którym głośnik zaczyna odtwarzać
odpowiednią ścieżkę dźwiękową, gdy system audio
był nieaktywny, ale nie został wyłączony przed wysłaniem żądania.
„Ciągłe opóźnienie wejściowe” oznacza opóźnienie między momentem, w którym aplikacja
wysyła żądanie odtwarzania dźwięku, a momentem, w którym głośnik zaczyna odtwarzać
odpowiednią ścieżkę dźwiękową, gdy system audio
był nieaktywny, ale nie został wyłączony przed wysłaniem żądania.
„Ciągłe opóźnienie wejściowe” oznacza opóźnienie między momentem, w którym aplikacja
wysyła żądanie odtwarzania / dźwięku, a momentem, w którym głośnik zaczyna odtwarzać
odpowiednią ścieżkę dźwiękową, gdy system audio
był nieaktywny, ale nie został wyłączony przed wysłaniem / żądania.
„Ciągłe opóźnienie wejściowe” oznacza opóźnienie między momentem, w którym aplikacja
wysyła żądanie odtwarzania / dźwięku, a momentem, w którym głośnik zaczyna odtwarzać
odpowiednią ścieżkę dźwiękową, gdy system audio
był nieaktywny, ale nie został wyłączony przed wysłaniem / żądania.
„Ciągłe opóźnienie wejściowe” oznacza opóźnienie między momentem, w którym aplikacja
wysyła żądanie odtwarzania / dźwięku, a momentem, w którym głośnik zaczyna odtwarzać
odpowiednią ścieżkę dźwiękową, gdy system audio
był nieaktywny, ale nie został wyłączony przed wysłaniem / żądania.
„Ciągłe opóźnienie wejściowe” oznacza opóźnienie między momentem, w którym aplikacja
wysyła żądanie odtwarzania / dźwięku, a momentem, w którym głośnik zaczyna odtwarzać
odpowiednią ścieżkę dźwiękową, gdy system audio
był nieaktywny, ale nie został wyłączony przed wysłaniem / żądania.
„Ciągłe opóźnienie wejściowe” oznacza opóźnienie między momentem, w którym aplikacja
wysyła żądanie odtwarzania / dźwięku, a momentem, w którym głośnik zaczyna odtwarzać
odpowiednią ścieżkę dźwiękową, gdy system audio
był nieaktywny, ale nie został wyłączony przed wysłaniem / żądania.
„Ciągłe opóźnienie wejściowe” oznacza opóźnienie między momentem, w którym aplikacja
wysyła żądanie odtwarzania / dźwięku, a momentem, w którym głośnik zaczyna odtwarzać
odpowiednią ścieżkę dźwiękową, gdy system audio
był nieaktywny, ale nie został wyłączony przed wysłaniem / żądania.
„Ciągłe opóźnienie wejściowe” oznacza opóźnienie między moment

Istniejace i nowe urządzenia z Androidem 4.1 bardzo
powinny spełniać te wymagania w Androidzie 4.1, ponieważ w przeciwnym razie nie będą mogły
osiągnąć zgodności z Androidem po przejściu na nowszą wersję.
Jeśli implementacja urządzenia spełnia wymagania podane w tym rozdziale, MOŻE zgłosić obsługę
opóźnienia niskiego poziomu dźwięku, zgłaszając funkcję „android.hardware.audio.low-
latency” za pomocą klasy android.content.pm.PackageManager. [Resources, 37]
Z drugiej strony, jeśli implementacja urządzenia nie spełnia tych wymagań, to MUSI
NIE zgłaszać obsługi dźwięku o niskiej latencji.
5.5. Protokoły sieciowe
Urządzenia MUSZĄ obsługiwać protokoły sieci multimedialnej w przypadku odtwarzania dźwięku i obrazu, zgodnie z
opisem w dokumentacji pakietu Android SDK [Zasoby, 58]. W szczególności urządzenia
MUSZĄ obsługiwać te protokoły sieci medialnej:
RTSP (RTP, SDP)
HTTP(S) progresywny streaming
HTTP(S) transmisja na żywo w wersji 3 (protokół, zasoby, 59) [Resources, 59]
6. Zgodność z narzędziami dla deweloperów
Wdrożenia na urządzeniu MUSZĄ obsługiwać narzędzia dla deweloperów Androida udostępnione w
pakiecie Android SDK. W szczególności urządzenia zgodne z Androidem MUSZĄ być zgodne z:
Android Debug Bridge (ADB) [Resources, 33]
Wdrożenia na urządzeniu MUSZĄ obsługiwać wszystkie funkcje ADB opisane w dokumentacji
pakietu Android SDK. Domyślnie demon adb na urządzeniu MUSI być nieaktywny, a
musi istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie funkcji Android Debug
Bridge.
Usługa monitorowania debugowania Dalvik (znana jako ddms) [Resources, 33]
Wdrożenia na urządzeniu MUSZĄ obsługiwać wszystkie funkcje ddms zgodnie z dokumentacją
Android SDK. Ponieważ ddms korzysta z adb, obsługa ddms powinna być domyślnie nieaktywna
, ale MUSI być obsługiwana, gdy użytkownik aktywuje Android
Debug Bridge, jak opisano powyżej.
Monkey [Resources, 36]
Wdrożenia na urządzeniu MUSZĄ zawierać platformę Monkey i
udostępniać ją do użycia przez aplikacje.
Większość systemów z Linuxem i systemów Apple Macintosh rozpoznaje urządzenia z Androidem
za pomocą standardowych narzędzi Android SDK bez dodatkowego wsparcia. Jednak systemy Microsoft
Windows zwykle wymagają sterownika dla nowych urządzeń z Androidem. (Na przykład
nowe identyfikatory dostawców i czasami nowe identyfikatory urządzeń wymagają niestandardowych sterowników USB na
systemach Windows). Jeśli implementacja urządzenia nie jest rozpoznawana przez narzędzie adb
dostępne w standardowym pakiecie SDK Androida, implementatorzy urządzeń MUSZĄ udostępnić sterowniki
dla systemu Windows, aby umożliwić deweloperom nawiązanie połączenia z urządzeniem za pomocą protokołu adb. Te
sterowniki MUSZĄ być dostępne dla systemów Windows XP, Vista i Windows 7 w wersjach
32- i 64-bitowych.
7. Zgodność sprzętu
Jeśli urządzenie zawiera określony komponent sprzętowy, który ma odpowiedni interfejs API dla
deweloperów zewnętrznych, implementacja urządzenia MUSI implementować ten interfejs API zgodnie z
opisem w dokumentacji pakietu Android SDK. Jeśli interfejs API w pakiecie SDK współdziała z
komponentem sprzętowym, który jest opcjonalny, a na urządzeniu
nie ma tego komponenta:
pełne definicje klas (opisane w dokumentacji pakietu SDK) dla interfejsów API tego komponenta
MUSZĄ być nadal obecne;
zachowanie interfejsu API MUSI być zaimplementowane jako nieobsługujące żadnej operacji w jakiś rozsądny
sposób;
metody interfejsu API MUSZĄ zwracać wartości null, jeśli jest to dozwolone przez dokumentację pakietu SDK;
metody interfejsu API MUSZĄ nie wyrzucać wyjątków nieopisanych w dokumentacji pakietu SDK;
Typowym przykładem scenariusza, w którym te wymagania mają zastosowanie, jest interfejs API telefonii:
nawet na urządzeniach innych niż telefony te interfejsy API muszą być zaimplementowane jako nieobsługujące żadnej operacji w jakiś rozsądny sposób.

Implementacje na urządzeniu MUSZĄ prawidłowo raportować informacje o konfiguracji sprzętu
za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String)
w klasie android.content.pm.PackageManager. [Resources, 37]
7.1. Wyświetlacze i grafika
Android 4.1 zawiera funkcje, które automatycznie dostosowują zasoby aplikacji i układy interfejsu użytkownika
do urządzenia, aby zapewnić prawidłowe działanie aplikacji innych firm na
różnych konfiguracjach sprzętowych [Resources, 38]. Urządzenia MUSZĄ prawidłowo implementować
te interfejsy API i zachowania zgodnie z opisem w tej sekcji.
Jednostki, do których odnoszą się wymagania w tym rozdziale, są zdefiniowane w następujący sposób:
„Fizyczna wielkość przekątnej” to odległość w calach między dwoma przeciwległymi kątami
podświetlonej części wyświetlacza.
„Rozdzielczość druku” (czyli „punkty na cal”) to liczba pikseli na odcinku liniowym
o długości 1 cala. W przypadku podanych wartości dpi zarówno poziomy, jak i
pionowy dpi muszą mieścić się w zakresie.
„Format obrazu” to stosunek dłuższego wymiaru ekranu do krótszego
. Na przykład wyświetlacz o wymiarach 480 x 854 pikseli będzie miał wartość 854 / 480 =
1, 779, czyli mniej więcej „16:9”.
„Piksel niezależny od gęstości” (czyli „dp”) to wirtualna jednostka piksela znormalizowana do ekranu o rozdzielczości 160 dpi, obliczana według wzoru: piksele = dps * (gęstość / 160).

7.1.1. Konfiguracja ekranu
Rozmiar ekranu
Interfejs użytkownika Androida obsługuje różne rozmiary ekranu i umożliwia
aplikacjom wysyłanie zapytań o rozmiar ekranu urządzenia (tzw. „układ ekranu”) za pomocą
android.content.res.Configuration.screenLayout z użyciem
SCREENLAYOUT_SIZE_MASK. Implementacje na urządzeniu MUSZĄ zgłaszać prawidłowy rozmiar
ekranu zgodnie z definicją w dokumentacji pakietu Android SDK [Resources, 38] i określany przez
platformę źródłową Androida.W szczególności implementacje na urządzeniach muszą zgłaszać
prawidłowy rozmiar ekranu zgodnie z podanymi poniżej współrzędnymi logicznych pikseli (dp)
niezależnymi od gęstości.
Urządzenia MUSZĄ mieć rozmiar ekranu co najmniej 426 dp x 320 dp („mały”)
Urządzenia, które zgłaszają rozmiar ekranu „normalny”, MUSZĄ mieć rozmiar ekranu co najmniej 480
dp x 320 dp
Urządzenia, które zgłaszają rozmiar ekranu „duży”, MUSZĄ mieć rozmiar ekranu co najmniej 640
dp x 480 dp
Urządzenia, które zgłaszają rozmiar ekranu „bardzo duży”, MUSZĄ mieć rozmiar ekranu co najmniej 960
dp x 720 dp
Ponadto urządzenia MUSZĄ mieć rozmiar ekranu co najmniej 2,5 cala w przekątnej
fizycznej.
Urządzenia NIE mogą zmieniać zgłaszanego rozmiaru ekranu w żadnym momencie.
Aplikacje mogą opcjonalnie wskazywać obsługiwane rozmiary ekranu za pomocą atrybutu <supports-
screens> w pliku AndroidManifest.xml. Wdrożenia na urządzeniach MUSZĄ
prawidłowo obsługiwać deklarowane przez aplikacje ekrany mały, normalny, duży i bardzo duży
, zgodnie z opisem w dokumentacji pakietu SDK Androida.
Format obrazu
Format obrazu MUSI mieścić się w zakresie od 1,3333 (4:3) do 1,85 (16:9).
Gęstość ekranu
Framework interfejsu użytkownika Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić
programistom aplikacji kierowanie zasobów aplikacji. Wdrożenia na urządzeniach MUSZĄ
zgłaszać jedną z poniższych wartości gęstości logicznej w ramach interfejsu API
android.util.DisplayMetrics i MUSZĄ uruchamiać aplikacje z tą standardową
gęstością.
120 dpi, znane jako „ldpi”
160 dpi, znane jako „mdpi”
213 dpi, znane jako „tvdpi”
240 dpi, znane jako „hdpi”
320 dpi, znane jako „xhdpi”
480 dpi, znane jako „xxhdpi”
Użytkownicy urządzeń powinni zdefiniować standardową gęstość w ramach Androida, która
pod względem liczbowym jest najbliższa fizycznej gęstości ekranu, chyba że ta gęstość logiczna

pod względem liczbowy jest najbliższa fizycznej gęstości ekranu, chyba że ta gęstość logiczna
spowoduje, że podany rozmiar ekranu będzie niższy niż minimalny obsługiwany rozmiar. Jeśli standardowa gęstość standardowego interfejsu Android
jest liczbowo najbliższa fizycznej gęstości i wynikająca z niej wielkość ekranu
jest mniejsza niż najmniejszy obsługiwany rozmiar ekranu (szerokość 320 dp),
w implementacji na urządzeniu NALEŻY użyć standardowej gęstości interfejsu Android
, która jest następną w dół.
7.1.2. Dane wyświetlania
Implementacje na urządzeniu MUSZĄ przekazywać prawidłowe wartości wszystkich danych wyświetlania zdefiniowanych w
android.util.DisplayMetrics [Resources, 39].
7.1.3. Orientacja ekranu
Urządzenia MUSZĄ obsługiwać dynamiczną orientację ekranu, aby aplikacje mogły wyświetlać obraz w orientacji pionowej lub
poziomej. Oznacza to, że urządzenie musi uwzględniać
żądanie aplikacji dotyczące określonej orientacji ekranu. W implementacji na urządzeniu DOWOLNA orientacja (
pionowa lub pozioma) MOŻE zostać wybrana jako domyślna.
Urządzenia MUSZĄ raportować prawidłową wartość bieżącego ułożenia urządzenia, gdy zostanie zapytanie
za pomocą android.content.res.Configuration.orientation,
android.view.Display.getOrientation() lub innego interfejsu API.
Urządzenia NIE mogą zmieniać zgłaszanego rozmiaru ani gęstości ekranu podczas zmiany orientacji
.
Urządzenia MUSZĄ zgłaszać obsługiwane orientacje ekranu (
android.hardware.screen.portrait lub android.hardware.screen.landscape)
i MUSZĄ zgłaszać co najmniej 1 obsługiwaną orientację. Na przykład urządzenie z
orientacją poziomą ekranu (np. telewizor lub laptop) MUSI zgłaszać tylko
android.hardware.screen.landscape.
7.1.4. Przyspieszenie grafiki 2D i 3D
Wdrożenia na urządzeniu MUSZĄ obsługiwać interfejs OpenGL ES 1.0 i 2.0, jak to zostało opisane w dokumentacji
do pakietu SDK Androida. Implementacje na urządzeniu MUSZĄ również
obsługiwać Android Renderscript, zgodnie z opisem w dokumentacji pakietu Android SDK
[Resources, 8].
Implementacje na urządzeniu MUSZĄ poprawnie identyfikować się jako obsługujące interfejsy
OpenGL ES 1.0 i 2.0. Oznacza to, że:
zarządzane interfejsy API (np. za pomocą metody GLES10.getString()) MUSZĄ raportować obsługę interfejsu OpenGL ES 1.0 i 2.0
Natywnie obsługiwane interfejsy OpenGL API (czyli te dostępne dla aplikacji za pomocą plików
libGLES_v1CM.so, libGLES_v2.so lub libEGL.so) MUSZĄ raportować obsługę interfejsu
OpenGL ES 1.0 i 2.0.

Implementacje na urządzeniu MOGĄ implementować dowolne rozszerzenia OpenGL ES.
Jednak implementacje na urządzeniu MUSZĄ zgłaszać za pomocą zarządzanych i
natyywnych interfejsów API OpenGL ES wszystkie obsługiwane ciągi znaków rozszerzeń. Z drugiej strony, implementacje na urządzeniu MUSZĄ NIE zgłaszać
ciągów znaków rozszerzeń, których nie obsługują.
Android 4.1 obsługuje opcjonalne określenie w aplikacji, że
wymaga ona określonych formatów kompresji tekstur OpenGL. Te formaty są zwykle specyficzne dla dostawcy.
Android 4.1 nie wymaga implementacji na urządzeniach w przypadku
żadnego konkretnego formatu kompresji tekstur. Należy jednak prawidłowo raportować wszystkie obsługiwane formaty kompresji tekstur
za pomocą metody getString() w interfejsie API
OpenGL.
Android 4.1 zawiera mechanizm umożliwiający aplikacjom deklarowanie, że chcą
włączyć akcelerację sprzętową grafiki 2D na poziomie aplikacji, aktywności, okna lub
widoku za pomocą tagu manifestu android:hardwareAccelerated lub bezpośredniego
interfejsu API [Zasoby, 9].
W przypadku Androida 4.1 implementacje na urządzeniu MUSZĄ mieć włączoną akcelerację sprzętową
domyślnie i MUSZĄ ją wyłączyć, jeśli deweloper zażąda tego, ustawiając
android:hardwareAccelerated="false" lub wyłączając akcelerację sprzętową
bezpośrednio za pomocą interfejsów API Androida View.
Ponadto implementacje na urządzeniu MUSZĄ działać zgodnie z dokumentacją Androida
SDK dotyczącą akceleracji sprzętowej [Zasoby, 9].
Android 4.1 zawiera obiekt TextureView, który umożliwia deweloperom bezpośrednią integrację
tekstur OpenGL ES z przyspieszeniem sprzętowym jako celów renderowania w hierarchii interfejsu użytkownika.
Wdrożenia na urządzeniu MUSZĄ obsługiwać interfejs TextureView API, a także MUSZĄ zachowywać

jednolite zachowanie w porównaniu z implementacją na Androidzie na poziomie źródłowym.
7.1.5. Tryb zgodności starszych aplikacji
Android 4.1 określa „tryb zgodności”, w którym platforma działa w trybie
„normalnego” rozmiaru ekranu (szerokość 320 dp) na potrzeby starszych
aplikacji, które nie zostały opracowane na potrzeby starszych wersji Androida, które nie obsługują niezależności od rozmiaru ekranu
. Implementacje na urządzeniu MUSZĄ zawierać obsługę starszego trybu aplikacji
w wersji zgodnej z kodem źródłowym Androida open source.
Oznacza to, że implementacje na urządzeniu NIE MOGĄ zmieniać wyzwalaczy ani progów, przy których aktywowany jest tryb zgodności, ani modyfikować zachowania samego trybu zgodności
.

7.1.6. Typy ekranów
Ekrany implementowane na urządzeniu są klasyfikowane jako jeden z 2 typów:
Implementacje wyświetlacza z stałymi pikselami: ekran jest pojedynczym panelem, który obsługuje
tylko jedną szerokość i wysokość piksela. Typowo ekran jest fizycznie zintegrowany z urządzeniem.
Przykłady: telefony komórkowe, tablety itp.
Implementacje wyświetlaczy o zmiennej rozdzielczości: implementacja urządzenia nie ma
wbudowanego ekranu i zawiera port wyjścia wideo, taki jak VGA, HDMI lub
bezprzewodowy port wyświetlacza, albo ma wbudowany ekran, którego rozdzielczość
może się zmieniać. Przykłady: telewizory, dekodery itp.
Wdrażanie urządzeń z ustawionymi parametrami pikseli
W przypadku wdrażania urządzeń z ustawionymi parametrami pikseli MOŻNA używać ekranów o dowolnych wymiarach pikseli,
o ile spełniają one wymagania określone w tej definicji zgodności.
W przypadku implementacji z użyciem pikseli stałych MOŻE występować port wyjścia wideo do korzystania z zewnętrznego
wyświetlacza. Jeśli jednak wyświetlacz jest używany do uruchamiania aplikacji, urządzenie MUSI spełniać
następujące wymagania:
Urządzenie MUSI raportować te same dane dotyczące konfiguracji ekranu i wyświetlacza, jak
opisane w punktach 7.1.1 i 7.1.2, jak w przypadku wyświetlacza z nieruchomymi pikselami.
Urządzenie MUSI raportować tę samą gęstość logiczną jak w przypadku wyświetlacza z nieruchomymi pikselami.
Urządzenie MUSI raportować wymiary ekranu, które są takie same lub bardzo zbliżone
do wymiarów wyświetlacza z nieruchomymi pikselami.
Na przykład tablet o przekątnej 7 cali i rozdzielczości 1024 x 600 pikseli jest uznawany za implementację wyświetlacza mdpi o stałych pikselach o dużej rozdzielczości.
Jeśli zawiera port wyjścia wideo
, który wyświetla obraz w rozdzielczości 720p lub 1080p, implementacja urządzenia MUSI skalować
wyjście tak, aby aplikacje były wykonywane tylko w oknie o dużej rozdzielczości mdpi, niezależnie od tego,
czy używany jest wyświetlacz o stałych pikselach czy port wyjścia wideo.
Wdrażanie urządzeń o zmiennej liczbie pikseli
Wdrażanie urządzeń o zmiennej liczbie pikseli MUSI obsługiwać rozdzielczość 1280 × 720 lub
1920 × 1080 (czyli 720p lub 1080p). Wdrożenia urządzeń z wyświetlaczami o zmiennej rozdzielczości
NIE MOGĄ obsługiwać żadnej innej konfiguracji ani trybu ekranu. Urządzenia
z ekranami o zmiennej liczbie pikseli MOGĄ zmieniać konfigurację ekranu lub tryb
w czasie działania lub uruchamiania. Na przykład użytkownik dekodera może zastąpić wyświetlacz
720p wyświetlaczem 1080p, a implementacja urządzenia może się odpowiednio dostosować
.
Dodatkowo implementacje urządzeń z rozmiarami pikseli zmiennych MUSZĄ raportować te
poziomy konfiguracji dla tych wymiarów pikseli:
1280x720 (zwane też 720p): rozmiar ekranu „duży”, gęstość „tvdpi” (213 dpi)
1920x1080 (zwane też 1080p): rozmiar ekranu „duży”, gęstość „xhdpi” (320 dpi)
W celu zapewnienia przejrzystości implementacje urządzeń z rozmiarami pikseli zmiennych są ograniczone do poziomu
720p lub 1080p w Androidzie 4.1 i MUSZĄ być skonfigurowane tak, aby raportować rozmiar ekranu i poziomy
gęstości zgodnie z opisem powyżej.
7.1.7. Technologia ekranu
Platforma Androida zawiera interfejsy API, które umożliwiają aplikacjom renderowanie bogatych grafik na
ekranie. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zgodnie z definicją w pakiecie SDK Androida
, chyba że jest to wyraźnie dozwolone w tym dokumencie. Szczegółowe informacje:
Urządzenia MUSZĄ obsługiwać wyświetlacze, które mogą renderować 16-bitową grafikę kolorową, i MOGĄ obsługiwać wyświetlacze, które mogą renderować 24-bitową grafikę kolorową.
Urządzenia MUSZĄ obsługiwać wyświetlacze, które mogą renderować animacje.
Używana technologia wyświetlacza MUSI mieć współczynnik proporcji pikseli (PAR) w zakresie od 0,9

do 1,1.
Oznacza to, że współczynnik proporcji pikseli MUSI być zbliżony do kwadratu (1,0) z dokładnością do 10%
.
7.2. Urządzenia wejściowe
7.2.1. Klawiatura
Wdrożenia na urządzeniu:
MUSI zawierać obsługę mechanizmu zarządzania danymi wejściowymi (który umożliwia deweloperom firm zewnętrznych tworzenie mechanizmów zarządzania danymi wejściowymi, np. klawiatur wirtualnych) zgodnie z informacjami na stronie http://developer.android.com
MUSI zawierać co najmniej 1 wdrożenie klawiatury wirtualnej (niezależnie od tego, czy jest obecna klawiatura fizyczna)
MOŻE zawierać dodatkowe wdrożenia klawiatury wirtualnej
MOŻE zawierać klawiaturę sprzętową
NIE MOŻE zawierać klawiatury sprzętowej, która nie pasuje do żadnego z formatów
określonych w android.content.res.Configuration.keyboard [Resources, 40]
(czyli QWERTY lub 12 klawiszy)
7.2.2.

Nawigacja bezdotykowa
Wdrożone na urządzeniu:
MOŻESZ pominąć opcję nawigacji bezdotykowej (czyli możesz pominąć trackball, panel dotykowy lub
koło)
MUSISZ podać prawidłową wartość dla
android.content.res.Configuration.navigation [Resources, 40]
MUSISZ podać rozsądny alternatywny mechanizm interfejsu użytkownika do
wyboru i edycji tekstu, który jest zgodny z silnikami zarządzania danymi wejściowymi.
Oprogramowanie open source na Androidzie zawiera mechanizm wyboru
, który można stosować na urządzeniach bez niedotykowych elementów sterujących nawigacją.
7.2.3. Klawisze nawigacyjne
Funkcje Strona główna, Menu i Wstecz są niezbędne w paradygmacie nawigacji w Androidzie
. Wdrożenia na urządzeniu MUSZĄ udostępniać te funkcje użytkownikowi
w każdej chwili podczas uruchamiania aplikacji. Te funkcje MOŻNA zaimplementować za pomocą
specjalnych przycisków fizycznych (takich jak mechaniczne lub pojemnościowe przyciski dotykowe) lub MOŻNA
zaimplementować za pomocą specjalnych klawiszy programowych, gestów, panelu dotykowego itp. Android
4.1 obsługuje obie implementacje.
Android 4.1 obsługuje działanie asystenta [Resources, 63]. Urządzenia
muszą udostępniać użytkownikowi działanie wspomagające przez cały czas podczas korzystania z aplikacji
.Ta funkcja MOŻE zostać zaimplementowana za pomocą klawiszy sprzętowych lub programowych
.
Implementacje na urządzeniu mogą wykorzystywać osobną część ekranu do wyświetlania
klawiszy nawigacji, ale w takim przypadku muszą spełniać te wymagania:
Klawisze nawigacji w implementacji na urządzeniu MUSZĄ wykorzystywać osobną część
ekranu, która nie jest dostępna dla aplikacji, i NIE MOGĄ
zasłonić ani w inny sposób zakłócić części ekranu dostępnej dla aplikacji.
Implementacje na urządzeniu MUSZĄ udostępniać część ekranu
aplikacjom, która spełnia wymagania określone w sekcji 7.1.1.
Implementacje na urządzeniu MUSZĄ wyświetlać klawisze nawigacji w nieinwazyjnym
trybie „low profile” (np. ściemnionym), gdy aplikacje określają
SYSTEM_UI_FLAG_LOW_PROFILE.

Wdrożenia na urządzeniu MUSZĄ ukrywać klawisze nawigacyjne, gdy aplikacje
określają SYSTEM_UI_FLAG_HIDE_NAVIGATION.
Wdrożenia na urządzeniu MUSZĄ udostępniać klawisz menu aplikacjom, gdy
targetSdkVersion <= 10, i NIE MOGĄ udostępniać klawisza menu, gdy
targetSdkVersion > 10.
Wdrożenia na urządzeniu MUSZĄ udostępniać część ekranu aplikacjom, które spełniają wymagania określone w sekcji 7.1.1.

7.2.4.Wprowadzanie danych za pomocą ekranu dotykowego
W implementacji urządzenia POWINNA być obecna jakaś forma systemu wprowadzania danych za pomocą wskaźnika (
mysz lub ekran dotykowy). Jeśli jednak implementacja urządzenia nie obsługuje systemu wejściowego
wskaźnika, to NIE MOŻE zgłaszać stałej funkcji android.hardware.touchscreen ani
android.hardware.faketouch. Wdrożenia na urządzeniach

z systemem wprowadzania danych za pomocą kursora:
MOŻE obsługiwać niezależne kursory, jeśli system wprowadzania danych na urządzeniu
obsługuje wiele kursorów
MUSI zwracać wartość android.content.res.Configuration.touchscreen
[Resources, 40] codpowiadającą rodzajowi ekranu dotykowego na
urządzeniu
Android 4.0 obsługuje różne ekrany dotykowe, panele dotykowe i fałszywe ekrany dotykowe
. Implementacje na urządzeniach z ekranem dotykowym są powiązane z
wyświetlaczem [Resources, 71], tak aby użytkownik miał wrażenie bezpośredniego manipulowania
elementami na ekranie. Ponieważ użytkownik dotyka bezpośrednio ekranu, system
nie wymaga żadnych dodatkowych możliwości, aby wskazać obiekty, którymi można manipulować. W kontrascie do tego
fałszywy interfejs dotykowy zapewnia system wprowadzania danych użytkownika, który w przybliżeniu odzwierciedla
podzbiór funkcji ekranu dotykowego. Na przykład mysz lub pilot zdalny, który steruje
kursorem na ekranie, umożliwia użytkownikowi sterowanie dotykiem, ale wymaga od niego najpierw wskazania lub skoncentrowania się na elemencie
, a następnie kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, mysz powietrzna z żyroskopem,
wskaźnik z żyroskopem, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe.
Android 4.0 zawiera stałą funkcję android.hardware.faketouch, która
odpowiada urządzeniu wejściowemu bez obsługi dotyku (czyli urządzeniu opartemu na wskaźniku), takiemu jak
mysz lub trackpad, które może odpowiednio emulować wejście dotykowe (w tym podstawowe
gesty) i wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji
ekranu dotykowego. Implementacje na urządzeniach, które deklarują funkcję fałszywego dotyku
, MUSZĄ spełniać wymagania dotyczące fałszywego dotyku podane w sekcji 7.2.5.
Wdrożenia na urządzeniach MUSZĄ raportować odpowiednią funkcję odpowiadającą używanemu typowi danych
. Wdrożenia urządzenia, które obejmują ekran dotykowy (jednodotykowy lub lepszy)
, MUSZĄ zgłaszać stałą platformy android.hardware.touchscreen. Urządzenia
, które zgłaszają stałą platformy
android.hardware.touchscreen, MUSZĄ również zgłaszać stałą platformy
android.hardware.faketouch. Wdrożenia urządzenia, które nie obejmują
ekranu dotykowego (i opierają się tylko na urządzeniu wskazującym) NIE MOGĄ zgłaszać żadnych funkcji ekranu dotykowego
i MUSZĄ zgłaszać tylko android.hardware.faketouch, jeśli spełniają wymagania dotyczące fałszywego
dotyku podane w sekcji 7.2.5.
7.2.5.Fałszywa informacja o dotknięciu
Wdrożenia na urządzeniach, które deklarują obsługę android.hardware.faketouch
, MUSZĄ raportować absolutne współrzędne X i Y kursora na ekranie oraz wyświetlać wizualny kursor na ekranie [Resources, 70]
MUSZĄ raportować zdarzenie dotyku z kodem działania [Resources, 70], który określa
zmianę stanu, która występuje na ekranie, gdy kursor schodzi w dół lub podnosi się w górę [Resources, 70]
MUSZĄ obsługiwać sprowadzanie i podnoszenie kursora na ekranie, co umożliwia użytkownikom emulowanie dotknięcia obiektu na ekranie
MUSZĄ obsługiwać sprowadzanie, podnoszenie i ponownie sprowadzanie kursora w tym samym
miejscu na ekranie w ramach określonego progu czasowego, co umożliwia użytkownikom emulowanie podwójnego dotknięcia obiektu na ekranie [Resources, 70]
MUSZĄ obsługiwać sprowadzanie kursora na ekranie w dowolnym miejscu, przesuwanie go
do innego dowolnego miejsca na ekranie, a następnie podnoszenie go na ekranie, co umożliwia użytkownikom przeciąganie obiektu na ekranie
Urządzenia, które deklarują obsługę android.hardware.faketouch.multitouch.distinct
, MUSZĄ spełniać wymagania dotyczące fałszywego dotyku opisane powyżej, a także MUSZĄ obsługiwać śledzenie
różnych wejść kursora dla co najmniej dwóch niezależnych od siebie wskaźników.

7.2.6. Mikrofon
W implementacji na urządzeniu MOŻNA pominąć mikrofon. Jeśli jednak implementacja urządzenia
nie zawiera mikrofonu, NIE MUSI zgłaszać funkcji android.hardware.microphone
constant i musi zaimplementować interfejs API do nagrywania dźwięku jako no-ops zgodnie z sekcją 7.
Z drugiej strony implementacje urządzenia, które mają mikrofon:
MUSZĄ zgłaszać funkcję android.hardware.microphone
constant MUSZĄ spełniać wymagania dotyczące jakości dźwięku podane w sekcji 5.4 MUSZĄ spełniać wymagania dotyczące opóźnienia dźwięku podane w sekcji 5.5
7.3.
Czujniki

Android 4.1 zawiera interfejsy API umożliwiające dostęp do różnych typów czujników. Urządzenia
mogą nie mieć tych czujników, jak to opisano w następujących
podrozdziałach. Jeśli urządzenie zawiera określony typ czujnika, który ma odpowiedni interfejs API
dla deweloperów zewnętrznych, implementacja urządzenia MUSI implementować ten interfejs API zgodnie z
opisem w dokumentacji pakietu Android SDK. Na przykład implementacje na urządzeniu:
MUSZĄ prawidłowo raportować obecność lub brak czujników zgodnie z klasą
android.content.pm.PackageManager. [Resources, 37]
MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody
SensorManager.getSensorList() i podobnych
MUSI działać prawidłowo w przypadku wszystkich innych interfejsów API czujników (np. zwracać wartość true
lub false w odpowiednich przypadkach, gdy aplikacje próbują zarejestrować listenery, nie wywoływać
listenerów czujników, gdy nie ma odpowiednich czujników; itp.)
MUSI przekazywać wszystkie pomiary czujników za pomocą odpowiedniego międzynarodowego systemu jednostek
(np. wartości metryczne) dla każdego typu czujnika zgodnie z definicją w dokumentacji Android SDK
[Resources, 41]
Powyższa lista nie jest wyczerpująca; należy stosować się do udokumentowanego działania Android SDK
.
Niektóre typy czujników są syntetyczne, co oznacza, że można je wyprowadzić z danych pochodzących z
jednego lub większej liczby innych czujników. (np. czujnik orientacji i czujnik przyspieszenia liniowego).
Wdrożenia na urządzeniach POWINNY implementować te typy czujników
, jeśli zawierają wymagane czujniki fizyczne.
W interfejsach API Androida 4.1 wprowadzono pojęcie „strumiennego” czujnika, który
zwraca dane ciągle, a nie tylko wtedy, gdy się zmienią. Wdrożenia na urządzeniu
MUSZĄ stale dostarczać okresowe próbki danych dla dowolnego interfejsu API
wskazanego w dokumentacji pakietu SDK Androida 4.1 jako czujnik strumieniowy.
7.3.1. Akcelerometr
W implementacji na urządzeniu MUSI być uwzględniony 3-osiowy akcelerometr. Jeśli urządzenie
ma 3-osiowy akcelerometr, to:
MOŻE przesyłać zdarzenia z częstotliwością co najmniej 120 Hz. Powyższe informacje o
częstotliwości akcelerometru są opisane jako „SHOULD” (powinna) w przypadku Androida 4.1. W przyszłej wersji
definicja zgodności zostanie zmieniona na
„MUST” (musi). Oznacza to, że te standardy są opcjonalne w Androidzie 4.1, ale będą
wymagane w przyszłych wersjach. Obecne i nowe urządzenia z Androidem 4.1
powinny spełniać te wymagania w Androidzie 4.1 , aby
można było je uaktualnić do przyszłych wersji platformy.
Muszą one
spełniać wymagania dotyczące systemu współrzędności czujników Androida zgodnie z informacjami w dokumentacji interfejsów API Androida (patrz [Resources, 41])
. Muszą one
spełniać wymagania dotyczące systemu współrzędności czujników Androida zgodnie z informacjami w dokumentacji interfejsów API Androida (patrz [Resources, 41])
. Muszą one
spełniać wymagania dotyczące systemu współrzędności czujników Androida zgodnie z informacjami w dokumentacji interfejsów API Androida (patrz [Resources, 41])
. Muszą one
spełniać wymagania dotyczące systemu współrzędności czujników Androida zgodnie z informacjami w dokumentacji interfejsów API Androida (patrz [Resources, 41])
. Magnetometr
W implementacji na urządzeniu NALEŻY użyć 3-osiowego magnetometru (np. kompasu). Jeśli
urządzenie zawiera 3-osiowy magnetometr:
MUSI być w stanie przesyłać zdarzenia z częstotliwością 10 Hz lub większą
MUSI być zgodny z systemem współrzędnych czujnika Androida zgodnie z opisem w
interfejsach API Androida (zob. [Zasoby, 41]).
MUSI być w stanie próbkować zakres natężeń pola odpowiedni do pokrycia
pola geomagnetycznego
MUSI mieć 8-bitową dokładnośće
MUSI mieć odchylenie standardowe nie większe niż 0, 5 µT
7.3.3. GPS
W implementacji na urządzeniu MUSI być uwzględniony odbiornik GPS. Jeśli implementacja urządzenia
obejmuje odbiornik GPS, TO POWINNA zawierać pewną formę techniki „wspomagania GPS”
, aby zminimalizować czas ustalania pozycji przez GPS.
7.3.4. Gyroscope
W implementacji na urządzeniu POWINIEN znajdować się żyroskop (czyli czujnik zmiany kąta).
Na urządzeniu NIE POWINIEN znajdować się czujnik żyroskopu, chyba że jest też obecny akcelerometr 3-osiowy
. Jeśli implementacja urządzenia zawiera żyroskop, musi:

być wyposażony w kompensację temperatury
być w stanie mierzyć zmiany orientacji do 5,5*Pi
radianów/sekundę (czyli około 1000 stopni na sekundę)
powinien być w stanie przesyłać zdarzenia z częstotliwością co najmniej 200 Hz. Pamiętaj, że chociaż w przypadku
częstotliwości zapisu z powyższego
gyroskopu w Androidzie 4.1 określono jako „SHOULD” (NALEŻY), w definicji zgodności
w przyszłej wersji ta wartość zostanie zmieniona na
„MUST” (NALEŻY). Oznacza to, że te standardy są opcjonalne w Androidzie 4.1, ale będą
wymagane w przyszłych wersjach. Istniejące i nowe urządzenia z Androidem 4.1
są
bardzo zdecydowanie zachęcane do spełniania tych wymagań w Androidzie 4.1 , aby
mogły przejść na przyszłe wersje platformy.
Musisz mieć 12-bitową dokładność
Musisz mieć odchylenie nie większe niż 1e-7 rad^2 / s^2 na Hz (odchylenie na Hz,
lub rad^2 / s). Wariancja może się zmieniać wraz z częstotliwością próbkowania, ale musi być ograniczona do wartości
. Innymi słowy, jeśli mierzymy odchylenie standardowe żyroskopa
przy częstotliwości próbkowania 1 Hz, nie powinno ono przekraczać 1e-7 rad^2/s^2.
Czastampy metadanych muszą być jak najbliższe chwili wystąpienia zdarzenia sprzętowego.
Konstantna latencja musi zostać usunięta.
7.3.5. Barometr
Wdrożenia na urządzeniu MOGĄ zawierać barometr (czyli czujnik ciśnienia otoczenia). Jeśli
urządzenie zawiera barometr, musi:
MUSI być w stanie przesyłać zdarzenia z częstotliwością 5 Hz lub większą
MUSI mieć odpowiednią dokładność, aby umożliwić szacowanie wysokości
MUSI być kompensowany temperaturowo
7.3.7. Termometr
Wdrożenia na urządzeniu MOGĄ, ALE NIE POWINNY zawierać termometru (czyli
czujnika temperatury). Jeśli implementacja urządzenia zawiera termometr, MUSI
mierzyć temperaturę procesora urządzenia. NIE MOŻE mierzyć żadnej innej temperatury
. (Pamiętaj, że ten typ czujnika jest wycofany w interfejsie API Androida 4.1).
7.3.7. Fotometr
W implementacji urządzenia MOŻE być uwzględniony fotometr (np. czujnik światła otoczenia).
7.3.8. Czujnik zbliżeniowy
Możliwe jest, że urządzenie będzie wykorzystywać czujnik zbliżeniowy. Jeśli implementacja urządzenia
obejmuje czujnik zbliżeniowy, MUSI on mierzyć odległość obiektu w
tym samym kierunku co ekran.Oznacza to, że czujnik zbliżeniowy MUSI być skierowany na wykrywanie
obiektów w pobliżu ekranu, ponieważ jego głównym celem jest wykrywanie
telefonu używanego przez użytkownika. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy z
dowolną inną orientacją, nie może być ona dostępna za pomocą tego interfejsu API. Jeśli urządzenie
ma czujnik zbliżeniowy, MUSI on mieć dokładność co najmniej 1 bita.
7.4. Połączenia danych
7.4.1. Telefonia
Termin „telefonia” używany w interfejsach API Androida 4.1 i w tym dokumencie odnosi się konkretnie do
sprzętu związanego z nawiązywaniem połączeń głosowych i wysyłaniem SMS-ów przez sieć GSM lub
CDMA. Te połączenia głosowe mogą być przełączane pakietami, ale
w przypadku Androida 4.1 są one traktowane niezależnie od wszelkich połączeń danych, które mogą być realizowane za pomocą tej samej sieci.
Innymi słowy, funkcje i interfejsy API dotyczące „telefonii” na Androidzie
odnoszą się wyłącznie do połączeń głosowych i SMS-ów. Na przykład implementacje
urządzeń, które nie mogą nawiązywać połączeń ani wysyłać/odbierać SMS-ów, NIE MOGĄ
wykorzystywać funkcji „android.hardware.telephony” ani żadnych funkcji podrzędnych, niezależnie od tego, czy korzystają z sieci komórkowej do przesyłania danych.

Android 4.1 MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego.
Android 4.1 jest zgodny z urządzeniami,które nie są telefonami. Jeśli jednak implementacja urządzenia
obejmuje telefonię GSM lub CDMA, MUSI w pełni obsługiwać
interfejs API dla tej technologii. Implementacje na urządzeniach, które nie obejmują telefonii
, MUSZĄ implementować pełne interfejsy API jako no-ops.
7.4.2. IEEE 802.11 (WiFi)
Implementacje na urządzeniach z Androidem 4.1 POWINNY obsługiwać co najmniej jedną formę
standardu 802.11 (b/g/a/n itd.). Jeśli implementacja urządzenia obejmuje obsługę 802.11, to
MUSI implementować odpowiedni interfejs API Androida.

Wdrożenia na urządzeniu MUSZĄ implementować interfejs multicast API zgodnie z opisem w dokumentacji pakietu SDK
[Zasoby, 62]. Dewice z obsługą Wi-Fi
MUSZĄ obsługiwać multicast DNS (mDNS). Implementacje na urządzeniu NIE MOGĄ filtrować pakietów mDNS
(224.0.0.251) w żadnym momencie działania, w tym wtedy, gdy ekran nie jest w stanie
aktywnym.
7.4.2.1. WiFi Direct
Wdrożenia urządzeń POWINNY obejmować obsługę Wi-Fi Direct (Wi-Fi peer-to-peer). Jeśli
implementacja urządzenia obejmuje obsługę Wifi Direct, MUSI zaimplementować
odpowiednie API Androida zgodnie z dokumentacją pakietu SDK [Zasoby, 68]. Jeśli
implementacja urządzenia obejmuje obsługę Wifi Direct, to:
MUSI obsługiwać zwykłą sieć Wi-Fi
POWINNA obsługiwać jednoczesną pracę w sieci Wi-Fi i Wi-Fi Direct
7.4.3. Bluetooth
W implementacji urządzenia MUSI znaleźć się nadajnik/odbiornik Bluetooth. Wdrożenia
urządzeń, które obejmują nadajnik/odbiornik Bluetooth, MUSZĄ mieć włączone interfejsy API Bluetooth oparte na protokole RFCOMM
, zgodnie z opisem w dokumentacji pakietu SDK [Zasoby, 42]. Wdrożenia na urządzeniu
POWINNA implementować odpowiednie profile Bluetooth, takie jak A2DP
AVRCP, OBEX itp., w sposób odpowiedni dla danego urządzenia.
Pakiet Compatibility Test Suite zawiera przypadki testowe obejmujące podstawowe operacje interfejsu RFCOMM Bluetooth API na Androidzie.
Bluetooth jest jednak protokołem komunikacji
między urządzeniami, więc nie można go w pełni przetestować za pomocą testów jednostkowych na jednym urządzeniu.
W konsekwencji implementacje urządzeń MUSZĄ przejść procedurę testowania Bluetooth
z udziałem człowieka opisaną w Załączniku A.
7.4.4. Komunikacja bliskiego pola
W implementacji urządzenia MUSI być uwzględniony transceiver i powiązany sprzęt do
komunikacji bliskiego pola (NFC). Jeśli implementacja urządzenia zawiera sprzęt NFC
, musi:

zgłosić funkcję android.hardware.nfc
z metody
android.content.pm.PackageManager.hasSystemFeature().
[Resources, 37]
MUSI być w stanie czytać i zapisywać wiadomości NDEF za pomocą podanych poniżej standardów
NFC:
MUSI być w stanie działać jako czytnik/nagrywarka NFC Forum (zgodnie z definicją
specyfikacji technicznej NFC Forum NFCForum-TS-DigitalProtocol-1.0)
za pomocą podanych poniżej standardów NFC:
NfcA (ISO14443-3A)
NfcB (ISO14443-3B)
NfcF (JIS 6319-4)
IsoDep (ISO 14443-4)
NFC Forum Tag Types 1, 2, 3, 4 (zdefiniowane przez NFC Forum)
POWINNA być w stanie czytać i zapisywać wiadomości NDEF za pomocą podanych poniżej standardów
NFC. Pamiętaj, że chociaż w przypadku Androida 4.1 standardy NFC są określone jako
„NALEŻY”, w definicji zgodności przyszłej wersji
planujemy zmienić je na „NALEŻY”. Oznacza to, że te standardy są opcjonalne w
Androidzie 4.1, ale staną się wymagane w przyszłych wersjach. Obecne i nowe urządzenia
z Androidem 4.1 bardzo zapraszamy do spełnienia tych
wymagań w Androidzie 4.1, aby można było je uaktualnić do przyszłych
wersji platformy.
NfcV (ISO 15693)
MUSI obsługiwać przesyłanie i odbieranie danych za pomocą następujących standardów i protokołów peer-to-peer:
ISO 18092
LLCP 1.0 (zdefiniowany przez Forum NFC)
SDP 1.0 (zdefiniowany przez Forum NFC)
NDEF Push Protocol [Resources, 43]
SNEP 1.0 (zdefiniowany przez Forum NFC)
MUSI obsługiwać Android Beam [Resources, 65]:
MUSI implementować serwer NEP domyślny.
Ważne komunikaty NDEF
otrzymane przez domyślny serwer SNEP MUSZĄ zostać wysłane do aplikacji
za pomocą intencji android.nfc.ACTION_NDEF_DISCOVERED. Wyłączenie funkcji
Android Beam w ustawieniach NIE może powodować wyłączenia wysyłania przychodzących wiadomości
NDEF.
Wdrożenia na urządzeniu MUSZĄ obsługiwać intencję
android.settings.NFCSHARING_SETTINGS, aby wyświetlać udostępnianie NFC

Ustawienia [Resources, 67].
MUSZĄ implementować serwer NPP. Wiadomości otrzymane przez serwer NPP
MUSZĄ zostać przetworzone w taki sam sposób jak na serwerze SNEP domyślnym.
MUSZĄ implementować klienta SNEP i próbować wysłać wychodzące dane P2P NDEF
na serwer SNEP domyślny, gdy funkcja Android Beam jest włączona. Jeśli nie zostanie znaleziony domyślny serwer
SNEP, klient MUSI spróbować wysłać dane do serwera
NPP.
NALEŻY umożliwić aktywności na pierwszym planie, aby ustawić wychodzące wiadomości P2P NDEF
za pomocą funkcji android.nfc.NfcAdapter.setNdefPushMessage oraz
android.nfc.NfcAdapter.setNdefPushMessageCal back oraz
android.nfc.NfcAdapter.enableForegroundNdefPush.
NALEŻY użyć gestu lub potwierdzenia na ekranie, np. „Dotknij, aby
przekazać”, przed wysłaniem wychodzących wiadomości P2P NDEF.
NALEŻY ustawić Android Beam jako domyślny
, aby umożliwić przekazywanie połączeń NFC na Bluetooth, gdy urządzenie
obsługuje profil przesyłania obiektów Bluetooth. Wdrożenia na urządzeniu muszą
obsługiwać przekazywanie połączenia do Bluetooth podczas używania
android.nfc.NfcAdapter.setBeamPushUris, implementując specyfikację
„Connection Handover version 1.2” [Resources, 60] i „Bluetooth Secure
Simple Pairing Using NFC version 1.0” [Resources, 61] z forum
NFC. W takiej implementacji SHOULD wykorzystuje żądania SNEP GET
do wymiany żądania przekazania / wybranej informacji za pomocą NFC, a
MUSI używać profilu Bluetooth Object Push Profile do rzeczywistego przesyłania danych Bluetooth
.
MUST pol for al supported technologies while in NFC discovery Mode.
SHOULD be in NFC discovery Mode while the device is awake with the screen
active and the lock-screen unlocked.
(Uwaga: publicznie dostępne linki nie są dostępne w przypadku specyfikacji JIS, ISO i Forum NFC
).
Dodatkowo implementacje urządzeń mogą zawierać obsługę czytnika/nagrywarki dla tych technologii MIFARE:

MIFARE Classic (NXP MF1S503x [Resources, 44], MF1S703x [Resources, 44])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 46])
NDEF na MIFARE Classic (NXP AN130511 [Resources, 48], AN130411
[Resources, 49])
Uwaga:Android 4.1 wobejmie interfejsy API dla tych typów MIFARE. Jeśli implementacja urządzenia
obsługuje MIFARE w roli czytnika/nagrywarki, musi:
MUSI wdrażać odpowiednie interfejsy API Androida zgodnie z dokumentacją
Android SDK
MUSI zgłaszać funkcję com.nxp.mifare z
android.content.pm.PackageManager.hasSystemFeature() method.
[Resources, 37] Uwaga: to nie jest standardowa funkcja Androida, dlatego
nie pojawia się jako stała w klasie PackageManager
android.content.pm.PackageManager.hasSystemFeature() [Resources, 37],
i nie musi implementować interfejsu API NFC w Androidzie 4.1.
Klasy android.nfc.NdefMessage i android.nfc.NdefRecord
reprezentują format reprezentacji danych niezależny od protokołu, dlatego implementacje na urządzeniach MUSZĄ
implementować te interfejsy API, nawet jeśli nie obsługują NFC ani nie deklarują funkcji
android.hardware.nfc.

7.4.5. Minimalne wymagania dotyczące sieci
Wdrożenia na urządzeniu MUSZĄ obejmować obsługę co najmniej jednej formy sieci danych
. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1
standard danych z prędkością 200 Kbit/s lub większą. Przykłady technologii
spełniających te wymagania to EDGE, HSPA, EV-DO, 802.11g, Ethernet itp.
Wdrożenia urządzeń, w których podstawowym połączeniem danych jest standard sieciowy (np. Ethernet), POWINNY również obsługiwać co najmniej jeden powszechny
standard bezprzewodowych danych, np. 802.11 (WiFi).

Urządzenia mogą wykorzystywać więcej niż jedną formę łączności danych.

7.5. Aparaty
Urządzenia MUSZĄ mieć tylny aparat i MOGĄ mieć
przedni aparat. Tylny aparat znajduje się po stronie
urządzenia po przeciwnej stronie niż wyświetlacz, czyli rejestruje obraz po przeciwnej stronie urządzenia, tak jak
tradycyjny aparat. Kamera przednia znajduje się po tej samej stronie
urządzenia co wyświetlacz. Jest to kamera, która zwykle służy do rejestrowania obrazu użytkownika, na przykład
w przypadku konferencji wideo i podobnych aplikacji.
7.5.1. Tylny aparat
Urządzenia MUSZĄ mieć tylny aparat. Jeśli urządzenie
zawiera tylną kamerę:
MUSI mieć rozdzielczość co najmniej 2 Mpix
POWINNA mieć sprzętowy lub oparty na oprogramowaniu autofokus
w sterowniku kamery (przezroczysty dla oprogramowania aplikacji)
MOŻE mieć sprzętowy autofokus z rozszerzoną głębią ostrości (EDOF)
MOŻE zawierać lampę błyskową. Jeśli aparat zawiera lampę błyskową, lampa błyskowa MUSI NIE
być włączona, gdy instancja android.hardware.Camera.PreviewCal została
zarejestrowana na powierzchni podglądu aparatu, chyba że aplikacja wyraźnie
włączyła lampę błyskową, włączając atrybuty FLASH_MODE_AUTO lub FLASH_MODE_ON
obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy
wbudowanej aplikacji aparatu w systemie, ale tylko aplikacji innych firm
korzystających z Camera.PreviewCallback.
7.5.2. Przedni aparat
W przypadku niektórych urządzeń przedni aparat może być wbudowany. Jeśli implementacja urządzenia
obsługuje przedni aparat:
MUSI mieć rozdzielczość co najmniej VGA (czyli 640 x 480 pikseli)
NIE może używać przedniego aparatu jako domyślnego interfejsu Camera API. Oznacza to, że
interfejs API aparatu w Androidzie 4.1 obsługuje w szczególny sposób kamery przednie, a
implementacje na urządzeniu MUSZĄ skonfigurować interfejs API, aby traktował kamerę
przednią jako domyślną kamerę tylną, nawet jeśli jest to jedyna kamera na
urządzeniu.
Możesz DODATKOWO uwzględnić funkcje (takie jak autofokus czy lampa błyskowa) dostępne dla kamer
tylnych, zgodnie z opisem w sekcji 7.5.1.
Musisz ustawić poziome odbicie lustrzane (czyli odbicie w osi Y) strumienia wyświetlanego przez aplikację w
pokazie kamery.
Jeśli implementacja urządzenia umożliwia użytkownikowi obracanie urządzenia (np.
automatycznie za pomocą akcelerometru lub ręcznie za pomocą danych wejściowych użytkownika), to podgląd
kamery MUSI być odzwierciedlone w osi Y względem bieżącej orientacji
urządzenia.
Jeśli bieżąca aplikacja wyraźnie poprosi o obrócenie wyświetlacza kamery
za pomocą metody
android.hardware.Camera.setDisplayOrientation() [Resources, 50]
, podgląd
kamery MUSI być odzwierciedlony w osi Y względem orientacji
określonej przez aplikację.
W przeciwnym razie podgląd MUSI być odzwierciedlony wzdłuż domyślnej osi
poziomej urządzenia.
NALEŻY odbić obraz wyświetlany przez podgląd postu w taki sam sposób jak
strumień obrazu z podglądu kamery. (Jeśli implementacja urządzenia nie obsługuje
postview, to wymaganie oczywiście nie obowiązuje.)
NIE MOŻE odzwierciedlać końcowego obrazu stałego lub strumieni wideo zwróconych do
aplikacji cal backs lub zapisanych w pamięci masowej
7.5.3. Zachowanie interfejsu Camera API
W przypadku interfejsów API związanych z kamerą
(zarówno przedniej, jak i tylnej) implementacja na urządzeniu MUSI zapewniać następujące zachowania:
1.  Jeśli aplikacja nigdy nie wywołała funkcji
android.hardware.Camera.Parameters.setPreviewFormat(int),
to na urządzeniu
musisz użyć android.hardware.PixelFormat.YCbCr_420_SP do danych
przekazanych do aplikacji w ramach funkcji cal backs.
2.  Jeśli aplikacja rejestruje instancję android.hardware.Camera.PreviewCallback
, a system wywołuje metodę onPreviewFrame() w przypadku formatu podglądu
YCbCr_420_SP, dane w tablicy byte[] przekazywane do onPreviewFrame()
muszą być dodatkowo zaszyfrowane w formacie NV21. Oznacza to, że NV21 MUSI być ustawione jako domyślne.
3.  Implementacje na urządzeniu MUSZĄ obsługiwać format YV12 (oznaczony za pomocą stałej

android.graphics.ImageFormat.YV12) w przypadku podglądu kamery zarówno w przypadku
przedniego, jak i tylnego aparatu. (Sprzętowy dekoder wideo i kamera mogą
używać dowolnego natywnego formatu pikseli, ale implementacja urządzenia MUSI obsługiwać
konwersję na YV12.)
Implementacje na urządzeniu MUSZĄ implementować pełny interfejs Camera API zawarty w dokumentacji pakietu SDK Androida
4.1 [Resources, 51]), niezależnie od tego, czy urządzenie ma
autofokus sprzętowy lub inne funkcje. Na przykład aparaty bez autofokusa
MUSZĄ nadal obsługiwać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback
(chociaż nie ma to zastosowania do aparatów bez autofokusa). Pamiętaj, że
to dotyczy również przednich kamer; na przykład chociaż większość przednich
kamer nie obsługuje autofokusa, interfejs API musi być „podrobiony” zgodnie z opisem
.
W implementacjach na urządzeniu MUSISZ rozpoznawać i honorować każdą nazwę parametru zdefiniowaną jako
stała w klasie android.hardware.Camera.Parameters, jeśli podstawowy sprzęt
obsługuje tę funkcję. Jeśli sprzęt urządzenia nie obsługuje danej funkcji, interfejs
API musi być udokumentowany. Z drugiej strony, implementacje na urządzeniu NIE MOGĄ
honorować ani rozpoznawać stałych ciągu znaków przekazywanych do metody
android.hardware.Camera.setParameters() innych niż te opisane jako
stałe w interfejsie android.hardware.Camera.Parameters. Oznacza to, że implementacje na urządzeniu
MUSZĄ obsługiwać wszystkie standardowe parametry kamery, jeśli sprzęt
na to pozwala, i NIE MOGĄ obsługiwać niestandardowych typów parametrów kamery.
Wdrożenia na urządzeniu MUSZĄ nadawać intencję Camera.ACTION_NEW_PICTURE
za każdym razem, gdy aparat zrobi nowe zdjęcie i je
doda do magazynu multimediów.
Wdrożenia na urządzeniu MUSZĄ nadawać intencję Camera.ACTION_NEW_VIDEO
za każdym razem, gdy kamera nagra nowy film i zaznaczony obraz
zostanie dodany do magazynu multimediów.
7.5.4. Ustawienie aparatu
Aparat przedni i tylny (jeśli jest dostępny) MUSZĄ być ustawione tak, aby dłuższy
wymiar aparatu był wyrównany z dłuższym wymiarem ekranu. Oznacza to, że gdy
urządzenie jest trzymane w orientacji poziomej, kamery MUSZĄ rejestrować obraz w
orientacji poziomej. Dotyczy to wszystkich urządzeń, niezależnie od ich naturalnej orientacji, czyli zarówno urządzeń z główną orientacją poziomą, jak i z główną orientacją pionową.

7.6. Pamięć i miejsce na dane
7.6.1. Minimalna ilość pamięci i miejsca na dane
W implementacji na urządzeniu MUSI być co najmniej 340 MB pamięci dostępnej dla jądra
i przestrzeni użytkownika. 340 MB MUSI być dodatkiem do pamięci przeznaczonej na
komponenty sprzętowe, takie jak radio, wideo itp., które nie są kontrolowane przez jądro
.
Wdrożenia na urządzeniu MUSZĄ mieć co najmniej 350 MB pamięci nieulotnej
na potrzeby prywatnych danych aplikacji. Oznacza to, że partycja /data musi mieć co najmniej 350 MB.
Interfejsy API Androida zawierają Menedżera pobierania, którego aplikacje mogą używać do pobierania
plików danych [Resources, 56]. Urządzenie z wdrożeniem Menedżera pobierania
MUSI być w stanie pobierać pojedyncze pliki o rozmiarze co najmniej 100 MB do domyślnej lokalizacji „bufora”
.
7.6.2. Pamięć współdzielona aplikacji
Wdrożenia na urządzeniach MUSZĄ oferować pamięć współdzieloną dla aplikacji. Dostęp do udostępnionego
miejsca na dane MUSI obejmować co najmniej 1 GB.
Implementacje na urządzeniach MUSZĄ być skonfigurowane z domyślnie zamontowanym pamięcią współdzieloną.
„out of the box”. Jeśli współdzielona pamięć nie jest zamontowana na ścieżce Linux /sdcard,
na urządzeniu MUSI znajdować się symboliczny link Linux z ścieżki /sdcard do rzeczywistego punktu montażu.
W przypadku implementacji na urządzeniu MUSISZ zastosować zgodnie z dokumentacją uprawnienie
android.permission.WRITE_EXTERNAL_STORAGE w pamięci współdzielonej.
Wspólne miejsce na dane MUSI być dostępne do zapisu dla każdej aplikacji, która uzyska to uprawnienie
.
W przypadku implementacji na urządzeniu MOŻE być dostępne dla użytkownika miejsce na wymienną pamięć,
na przykład karta Secure Digital. Urządzenia mogą również wykorzystywać wewnętrzną (niewymienną) pamięć jako pamięć współdzielona dla aplikacji.

Niezależnie od tego, w jakiej formie jest używana pamięć współdzielona, implementacje urządzenia MUSZĄ
zapewniać mechanizm umożliwiający dostęp do zawartości tej pamięci z komputera hosta
, na przykład za pomocą pamięci masowej USB (UMS) lub protokołu Media Transfer Protocol (MTP).
Implementacje urządzenia MOGĄ używać pamięci masowej USB, ALE POWINNY używać protokołu Media
Transfer Protocol. Jeśli implementacja urządzenia obsługuje protokół przesyłania multimediów:
Implementacja urządzenia POWINNA być zgodna z hostem MTP Androida
[Resources, 57] oraz z Androidem.
Implementacja urządzenia POWINNA zwracać klasę urządzenia USB 0x00.
Implementacja urządzenia POWINNA zwracać nazwę interfejsu USB „MTP”.
Jeśli urządzenie nie ma portów USB, MUSI zapewniać dostęp do zawartości współdzielonej pamięci za pomocą komputera hosta za pomocą innych środków, takich jak system plików sieciowych
.

Zobacz 2 typowe przykłady. Jeśli implementacja urządzenia obejmuje
gniazdo karty SD, aby spełnić wymagania dotyczące wspólnej pamięci, do urządzenia sprzedawanego użytkownikom MUSI być dołączona karta SD w formacie FAT
o pojemności co najmniej 1 GB, która MUSI
być domyślnie zamontowana. Jeśli implementacja urządzenia korzysta z wewnętrznego stałego
miejsca na dane, aby spełnić ten wymóg, to miejsce na dane MUSI mieć rozmiar co najmniej 1 GB i MUSI być zamontowane w folderze /sdcard (lub /sdcard MUSI być symboliczną lokalizacją w przypadku zamontowania w innym miejscu).

W przypadku implementacji na urządzeniu, które obejmuje wiele ścieżek do pamięci współdzielonej (np. zarówno gniazdo karty SD, jak i pamięć wewnętrzna) NALEŻY zmodyfikować aplikacje podstawowe, takie jak skaner multimediów i ContentProvider, aby obsługiwały w przezroczysty sposób pliki umieszczone w obu
lokacjach.

7.7. USB
W implementacji urządzenia POWINNA być uwzględniona gniazdo klienta USB i POWINNA być uwzględniona gniazdo hosta USB
.
Jeśli implementacja urządzenia zawiera port klienta USB:
port MUSI umożliwiać połączenie z hostem USB za pomocą standardowego portu USB-A
port powinien wykorzystywać format micro USB po stronie urządzenia. Obecne
i nowe urządzenia z Androidem 4.1 bardzo zgodnie z Androidem 4.1 powinny spełniać te wymagania, aby można było je uaktualnić do przyszłych wersji
platformy
. Port powinien być wyśrodkowany na środku krawędzi.
W przypadku implementacji na urządzeniu
NALEŻY umieścić port na dole urządzenia (zgodnie z naturalną
orientacją) lub włączyć obrócenie ekranu w oprogramowaniu dla wszystkich aplikacji (w tym ekranu głównego
), aby wyświetlacz wyświetlał obraz prawidłowo, gdy urządzenie jest skierowane
portem w dół. Obecne i nowe urządzenia z Androidem 4.1 bardzo
zachęca się
do spełniania tych wymagań w Androidzie 4.1, aby
mogły
przejść na przyszłe wersje platformy.
Jeśli urządzenie ma port hosta USB:
może używać niestandardowego formatu portu, ale w takim przypadku MUSI być dostarczane z kablowicami lub
kablowcami umożliwiającymi dostosowanie portu do standardu USB-A
MUSI implementować interfejs API hosta USB w Androidzie zgodnie z dokumentacją w pakiecie SDK Androida
[Resources, 53]
W przypadku implementacji urządzenia MUSI być implementowany debugowanie Androida.

Jeśli w implementacji
urządzenia nie ma portu klienta USB, MUSI ona implementować Android Debug Bridge
za pomocą sieci lokalnej (np. Ethernetet lub 802.11)

8. Zgodność z wydajnością
Wdrożenia na urządzeniu MUSZĄ spełniać kluczowe wskaźniki wydajności urządzenia zgodnego z Androidem 4.1
określone w tabeli poniżej:
Wskaźnik
Próg wydajności
Komentarze
Aplikacje
powinny uruchamiać się w czasie określonym w
.
Czas uruchamiania jest mierzony jako
całkowity czas wczytywania
Przeglądarka: mniej niż
domyślna aktywność aplikacji,
Aplikacja
1300 ms
w tym czas potrzebny do uruchomienia
Czas uruchamiania
Kontakty: mniej niż
proces Linux, wczytywanie pakietu Androida
700 ms
do wirtualnej maszyny Dalvik i cal
Ustawienia: mniej niż
onCreate.
700 ms
Jeśli uruchomiono już
kilka aplikacji, ponowne
uruchomienie
już
uruchomionej aplikacji
po jej
uruchomieniu
nie może zająć więcej czasu niż pierwotny
czas uruchomienia.

9. Zgodność z modelem zabezpieczeń
Wdrożenia na urządzeniu MUSZĄ implementować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android
określonym w dokumentacji referencyjnej Zabezpieczenia i uprawnienia w
API [Resources, 54] w dokumentacji dla deweloperów Androida. Urządzenia
MUSZĄ obsługiwać instalowanie aplikacji podpisanych przez siebie bez
wymagania dodatkowych uprawnień lub certyfikatów od innych firm/autorytetów.
W szczególności urządzenia zgodne MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w
podrozdziałach poniżej.
9.1. Uprawnienia
Wdrożenia na urządzeniu MUSZĄ obsługiwać model uprawnień Androida zgodnie z definicją w
dokumentacji dla deweloperów Androida [Zasoby, 54].W szczególności w implementacji
MUSISZ uwzględnić wszystkie uprawnienia określone w dokumentacji pakietu SDK. Żadne
uprawnienia nie mogą być pomijane, zmieniane ani ignorowane. W implementacjach MOŻNA dodać dodatkowe uprawnienia
, pod warunkiem że nowe ciągi znaków identyfikatora uprawnień nie znajdują się w przestrzeni nazw android.*
.
9.2. Identyfikator użytkownika i izolacja procesów
Wdrożenia na urządzeniu MUSZĄ obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja działa jako unikalny identyfikator użytkownika w stylu Unixa i w oddzielnym procesie.
Wdrożenia na urządzeniu MUSZĄ obsługiwać uruchamianie wielu aplikacji z tym samym identyfikatorem użytkownika Linuxa, pod warunkiem że aplikacje są odpowiednio podpisane i skonstruowane zgodnie z opisem
podanym w dokumentacji dotyczącej zabezpieczeń i uprawnień [Resources, 54].

9.3. Uprawnienia do systemu plików
Wdrożenia na urządzeniu MUSZĄ obsługiwać model uprawnień dostępu do plików w Androidzie zgodnie z opisem
podanym w dokumentacji dotyczącej zabezpieczeń i uprawnień [Resources, 54].
9.4. Inne środowiska wykonawcze
Wdrożenia na urządzeniu mogą obejmować środowiska wykonawcze, które wykonują aplikacje
za pomocą oprogramowania lub technologii innych niż maszyna wirtualna Dalvik lub kod natywny
. Jednak takie alternatywne środowiska wykonawcze NIE MOGĄ naruszać
modelu zabezpieczeń Androida ani zabezpieczeń zainstalowanych aplikacji na Androida, jak to opisano w tej sekcji
.
Alternatywne środowisko uruchomieniowe MUSI być aplikacją na Androida i stosować się do
standardowego modelu zabezpieczeń Androida, zgodnie z opisem w innych miejscach w sekcji 9.
Dostęp do zasobów chronionych przez uprawnienia
, których nie żądano w pliku AndroidManifest.xml środowiska uruchomieniowego, NIE MOŻE być przyznawany za pomocą mechanizmu <uses-
permission>.

Alternatywne środowisko wykonawcze NIE MOŻE zezwalać aplikacjom na korzystanie z funkcji chronionych
przez uprawnienia Androida, które są dostępne tylko dla aplikacji systemowych.
Alternatywne środowisko uruchomieniowe MUSI być zgodne z modelem piaskownicy Androida. Szczegóły:
Alternatywne środowisko wykonawcze POWINNA instalować aplikacje za pomocą menedżera pakietów w oddzielnych
piaskownicach Androida (czyli z użyciem identyfikatorów użytkowników Linuxa itp.)
Alternatywne środowisko wykonawcze MOŻE udostępniać jedno wspólne środowisko piaskownicy Androida
wszystkim aplikacjom korzystającym z alternatywnego środowiska wykonawczego
Alternatywne środowisko wykonawcze NIE MOŻE być uruchamiane z użyciem uprawnień superużytkownika (root) ani przyznawać takich uprawnień innym aplikacjom
(ani przyznawać takich uprawnień innym aplikacjom).

Pliki .apk z alternatywnymi środowiskami wykonawczymi MOGĄ być zawarte w obrazie systemu implementacji urządzenia
, ale MUSZĄ być podpisane innym kluczem niż klucz użyty do podpisania innych aplikacji
zawartych w ramach implementacji urządzenia.
Podczas instalowania aplikacji alternatywne środowisko wykonawcze MUSI uzyskać zgodę użytkownika na uprawnienia
Androida używane przez aplikację. Oznacza to, że jeśli aplikacja musi korzystać z zasobu urządzenia, do którego jest dostępne odpowiednie uprawnienie Androida (takie jak Aparat lub GPS), środowisko uruchomieniowe MUSI poinformować użytkownika, że aplikacja będzie mieć dostęp do tego zasobu.

Jeśli środowisko uruchomieniowe nie rejestruje
możliwości aplikacji w taki sposób, to podczas instalowania dowolnej aplikacji korzystającej z tego środowiska MUSI ono wymienić wszystkie
uprawnienia posiadane przez samo środowisko uruchomieniowe.
10. Testy zgodności oprogramowania
Wdrożenia na urządzeniu MUSZĄ przejść wszystkie testy opisane w tej sekcji.
Należy jednak pamiętać, że żaden pakiet testów oprogramowania nie jest kompleksowy. Z tego powodu
implementujący na urządzeniu powinni w jak największym stopniu
wspierać się na referencyjnej i preferowanej implementacji Androida 4.1
,która jest dostępna w ramach projektu Android Open Source. Pozwoli to zminimalizować ryzyko
wprowadzenia błędów, które powodują niezgodności wymagające przerobienia i potencjalnych aktualizacji
urządzenia.
10.1. Compatibility Test Suite
Wdrożenia na urządzeniu MUSZĄ przejść test zgodności z Androidem (CTS)
[Resources, 2] dostępne w ramach projektu Android Open Source, korzystając z ostatecznej
wersji oprogramowania na urządzeniu. Dodatkowo implementatorzy urządzeń powinni w jak największym stopniu korzystać z
referencyjnej implementacji w drzewie Androida Open Source.
NALEŻY im zapewnić zgodność w przypadku niejednoznaczności w CTS oraz w przypadku wszelkich
reimplementacji części referencyjnego kodu źródłowego.
Testy CTS są przeznaczone do uruchamiania na rzeczywistym urządzeniu. Podobnie jak inne oprogramowanie, CTS może
zawierać błędy. CTS będzie aktualizowany niezależnie od tej definicji zgodności
, a na potrzeby Androida 4.1 może zostać opublikowanych kilka wersji CTS. Wdrożenia na urządzeniu
MUSZĄ przejść najnowszą wersję CTS dostępną w momencie ukończenia oprogramowania urządzenia
.
10.2. CTS Verifier
Implementacje na urządzeniu MUSZĄ prawidłowo wykonywać wszystkie odpowiednie przypadki w CTS
Verifier. Weryfikator CTS jest częścią pakietu Compatibility Test Suite i jest przeznaczony
do uruchamiania przez operatora w celu testowania funkcji, których nie można przetestować za pomocą
automatycznego systemu, takich jak prawidłowe działanie kamery i czujników.
Narzędzia Verifier CTS obejmują testy wielu rodzajów sprzętu, w tym niektórych opcjonalnych.
Wdrożenia urządzenia MUSZĄ przejść wszystkie testy dotyczące sprzętu, który
posiada; na przykład jeśli urządzenie ma akcelerometr, MUSI prawidłowo
wykonywać test akcelerometru w CTS Verifier. Przypadki testowe funkcji oznaczonych w tym dokumencie z definicją zgodności jako opcjonalne MOŻNA pominąć.

Jak wspomniano powyżej, na każdym urządzeniu i w przypadku każdej kompilacji MUSI poprawnie działać narzędzie CTS Verifier.
Ponieważ jednak wiele kompilacji jest bardzo podobnych, nie oczekuje się, że implementujący urządzenia
będą uruchamiać narzędzie CTS Verifier w przypadku kompilacji, które różnią się tylko nieznacznie. W szczególności
implementacje na urządzeniu, które różnią się od implementacji, która przeszła weryfikację w CTS
Verifier, tylko pod względem zestawu dostępnych języków, marki itp., mogą pominąć test CTS Verifier

.
10.3. Aplikacje referencyjne
Wdrożyciele na urządzeniach MUSZĄ przetestować zgodność implementacji za pomocą tych aplikacji o otwartym
źródle:
aplikacje „Aplikacje na Androida” [Resources, 55]
Replica Island (dostępna w Google Play)
Aby implementacja została uznana za kompatybilną, MUSI prawidłowo uruchamiać się na
i działać na implementacji.
11. Oprogramowanie z możliwością aktualizacji
Wdrożenia na urządzeniu MUSZĄ zawierać mechanizm umożliwiający wymianę całego
oprogramowania systemowego. Mechanizm nie musi wykonywać „natychmiastowych” uaktualnień, czyli może wymagać ponownego uruchomienia urządzenia
.
Możesz użyć dowolnej metody, o ile pozwala ona na zastąpienie całego oprogramowania
zainstalowanego fabrycznie na urządzeniu. Na przykład dowolna z tych metod spełnia
to wymaganie:
Pobieranie przez OTA z aktualizacją offline przez ponowne uruchamianie
Aktualizacje „z połączeniem” przez USB z komputera hosta
Aktualizacje „offline” przez ponowne uruchamianie i aktualizację z pliku na wymiennym urządzeniu pamięci masowej
Używany mechanizm aktualizacji MUSI obsługiwać aktualizacje bez kasowania danych użytkownika.
Mechanizm aktualizacji MUSI zachowywać prywatne dane aplikacji i dane aplikacji
udostępnione. Pamiętaj, że oprogramowanie Androida na poziomie upstream zawiera mechanizm aktualizacji
, który spełnia ten wymóg.
Jeśli po wydaniu urządzenia zostanie wykryty błąd, który wpływa na zgodność aplikacji innych firm, ale w ramach
rozsądnego okresu użytkowania produktu, który jest określany we współpracy z zespołem ds. zgodności Androida
, implementator urządzenia MUSI naprawić błąd, stosując dostępne uaktualnienie oprogramowania, które można zastosować
zgodnie z omówionym właśnie mechanizmem.

12. Skontaktuj się z nami
Aby uzyskać wyjaśnienia, możesz skontaktować się z autorami dokumentu pod adresem compatibility@android.com
, aby omówić wszelkie kwestie, które Twoim zdaniem nie zostały w nim opisane.

Załącznik A – procedura testowania Bluetootha
Pakiet Compatibility Test Suite zawiera przypadki testowe obejmujące podstawowe działanie interfejsu API Bluetooth
RFCOMM na Androidzie. Bluetooth jest jednak protokołem komunikacyjnym
między urządzeniami, więc nie można go w pełni przetestować za pomocą testów jednostkowych na jednym urządzeniu.
W związku z tym implementacje urządzeń MUSZĄ przejść procedurę testowania Bluetooth
z udziałem człowieka, opisaną poniżej.
Procedura testowania opiera się na przykładowej aplikacji BluetoothChat zawartej w drzewie projektu Android
na licencji open source. Ta procedura wymaga 2 urządzeń:
urządzenia z dotychczasową implementacją z uruchomioną wersją oprogramowania do przetestowania
oddzielnej implementacji urządzenia, która jest już znana jako kompatybilna, oraz
modelu urządzenia z testowanej implementacji, czyli „znanego urządzenia”
W procedurze testów poniżej te urządzenia są odpowiednio określane jako „kandydat” i „znane
urządzenie”.

Konfiguracja i instalacja
1.  Utwórz plik BluetoothChat.apk za pomocą polecenia „make samples” w drzewie kodu źródłowego Androida
2.  Zainstaluj plik BluetoothChat.apk na urządzeniu, które działa prawidłowo
3.  Zainstaluj plik BluetoothChat.apk na urządzeniu docelowym
Testuj kontrolę Bluetooth za pomocą aplikacji
1.  Uruchom aplikację BluetoothChat na urządzeniu docelowym, gdy Bluetooth jest wyłączony
2.  Sprawdź, czy urządzenie docelowe włącza Bluetooth lub wyświetla użytkownikowi
okno z prośbą o włączenie Bluetootha
Testowanie parowania i komunikacji
1.  Uruchom aplikację Bluetooth Chat na obu urządzeniach
2.  Ustaw urządzenie z dobrze działającym BluetoothChatem jako widoczne (za pomocą menu
).
3.  Na urządzeniu docelowym zeskanuj urządzenia Bluetooth w BluetoothChat
(za pomocą menu) i sparuj z urządzeniem, które działa prawidłowo
4.  Wyślij 10 lub więcej wiadomości z każdego urządzenia i sprawdź, czy drugie urządzenie
odbiera je prawidłowo
5.Zamknij aplikację BluetoothChat na obu urządzeniach, naciskając Strona główna
6.  Rozłącz każde urządzenie z drugim za pomocą aplikacji Ustawienia
Testowanie parowania i komunikacji w odwrotnej kolejności
Kierunek
1.  Uruchom aplikację Bluetooth Chat na obu urządzeniach.
2.  Ustaw urządzenie docelowe jako widoczne w BluetoothChat (za pomocą menu
).
3.  Na urządzeniu, które działa prawidłowo, przeskanuj urządzenia Bluetooth w BluetoothChat
(za pomocą menu) i sparuj z urządzeniem docelowym.
4.  Wyślij 10 wiadomości z każdego urządzenia i sprawdź, czy drugie urządzenie
je odbierz.
5.  Zamknij aplikację Bluetooth Chat na obu urządzeniach, naciskając kilkakrotnie przycisk Wstecz
, aby otworzyć program uruchamiający.
Testowanie ponownych uruchomień
1.  Uruchom ponownie aplikację Bluetooth Chat na obu urządzeniach.
2.  Wyślij 10 wiadomości z każdego urządzenia i sprawdź, czy drugie urządzenie
je odbierz.
Uwaga: w przypadku niektórych testów sekcja testu kończy się na stronie głównej, a w innych – na stronie Wstecz.
Te testy nie są zbędne ani opcjonalne: celem jest
sprawdzenie, czy interfejs API Bluetooth i jego moduł obsługi działają prawidłowo zarówno wtedy, gdy aktywności są
zamykane jawnie (przez naciśnięcie przez użytkownika przycisku Wstecz, który powoduje zakończenie), jak i gdy są wysyłane niejawnie
do tła (przez naciśnięcie przez użytkownika przycisku Home). Każdą sekwencję testów należy wykonać zgodnie z opisem.

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

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