Definicja zgodności z Androidem 2.3

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

Copyright © 2010, Google Inc. Wszelkie prawa zastrzeżone.
compatibility@android.com

Spis treści

1. Wprowadzenie

Ten dokument zawiera listę wymagań, które muszą być spełnione, aby telefony komórkowe były zgodne z Androidem 2.3.

Użycie słów „must” (musi), „must not” (nie musi), „required” (wymagane), „shall” (powinien), „shall not” (nie powinien), „should” (powinien), „should not” (nie powinien), „recommended” (zalecane), „may” (można) i „optional” (opcjonalnie) jest zgodne ze standardem IETF zdefiniowanym w specyfikacji RFC2119 [Resources, 1].

W tym dokumencie „implementer urządzenia” lub „implementer” to osoba lub organizacja opracowująca rozwiązanie sprzętowe/programowe z systemem Android 2.3. „Wdrożenie urządzenia” lub „wdrożenie” to opracowane rozwiązanie sprzętowo-programowe.

Aby uznać implementację urządzenia za zgodną z Androidem 2.3, należy spełnić wymagania podane w tej definicji zgodności, w tym wszelkie dokumenty uwzględnione w dokumentach referencyjnych.

Jeśli definicja lub testy oprogramowania opisane w sekcji 10 są niejasne, niepełne lub nieprecyzyjne, implementator urządzenia jest odpowiedzialny za zapewnienie zgodności z dotychczasowymi implementacjami. Z tego powodu projekt Android Open Source [Zasoby, 3] jest zarówno referencją, jak i preferowaną implementacją Androida. W jak największym stopniu zalecamy, aby implementacje były oparte na „upstreamowym” kodzie źródłowym dostępnym w ramach Projektu Android Open Source. Chociaż teoretycznie niektóre komponenty można zastąpić innymi implementacjami, zdecydowanie odradzamy to robić, ponieważ znacznie utrudni to przejście testów oprogramowania. Obowiązkiem implementatora jest zapewnienie pełnej zgodności z zachowaniem standardowej implementacji Androida, w tym w ramach pakietu Compatibility Test Suite i poza nim. Pamiętaj, że niektóre zamiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.

Ta definicja zgodności została opublikowana w związku z aktualizacją Androida do wersji 2.3.3, która jest na poziomie interfejsu API 10. Ta definicja powoduje zastąpienie definicji zgodności dla wersji Androida 2.3, które są starsze niż 2.3.3. (czyli wersje 2.3.1 i 2.3.2 są nieaktualne). Przyszłe urządzenia zgodne z Androidem w wersji 2.3 MUSZĄ być dostarczane z wersją 2.3.3 lub nowszą.

2. Materiały

1. Poziomy wymagań IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2. Omówienie programu zgodności z Androidem: http://source.android.com/docs/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 na 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 2.3: http://source.android.com/docs/compatibility/2.3/versions.html
8. Klasa android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. Funkcje offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
11. Tag wideo HTML5: http://dev.w3.org/html5/spec/Overview.html#video
12. Interfejs API geolokalizacji HTML5/W3C: http://www.w3.org/TR/geolocation-API/
13. Webdatabase API HTML5/W3C: http://www.w3.org/TR/webdatabase/
14. Interfejs API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
15. Specyfikacja maszyny wirtualnej Dalvik: dostępna w kodzie źródłowym Androida w folderze dalvik/docs.
16. Widgety aplikacji: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
17. Powiadomienia: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
18. Zasoby aplikacji: http://code.google.com/android/reference/available-resources.html
19. Przewodnik po stylu ikon na pasku stanu: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
20. Menedżer wyszukiwania: http://developer.android.com/reference/android/app/SearchManager.html.
21. Toasty: http://developer.android.com/reference/android/widget/Toast.html
22. Animowane tapety: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. Dokumentacja narzędzi (dla adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
24. Opis pliku APK na Androida: http://developer.android.com/guide/topics/fundamentals.html
25. Pliki manifestu: http://developer.android.com/guide/topics/manifest/manifest-intro.html
26. Narzędzie do testowania Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
27. Lista funkcji sprzętowych Androida: http://developer.android.com/reference/android/content/pm/PackageManager.html
28. Obsługa wielu ekranów: http://developer.android.com/guide/practices/screens_support.html
29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
31. Przestrzeń współrzędnych czujnika: http://developer.android.com/reference/android/hardware/SensorEvent.html
32. Interfejs Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
33. NDEF Push Protocol: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
40. Interfejs API orientacji aparatu: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
42. Informacje o bezpieczeństwie i uprawnieniach w Androidzie: http://developer.android.com/guide/topics/security/security.html
43. Aplikacje na Androida: http://code.google.com/p/apps-for-android

Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z Androida 2.3 SDK i będzie funkcjonalnie identyczne z informacjami w dokumentacji tego pakietu SDK. W każdym przypadku, gdy dokument definicji zgodności lub pakiet Compatibility Test Suite są niezgodne z dokumentacją pakietu SDK, decydująca jest dokumentacja pakietu SDK. Wszelkie szczegóły techniczne podane w wymienionych powyżej dokumentach są uznawane za część tej Definicji zgodności.

3. Oprogramowanie

Platforma Androida obejmuje zestaw zarządzanych interfejsów API, zestaw natywnych interfejsów API oraz zestaw tak zwanych „miękkich” interfejsów API, takich jak system Intent i interfejsy API aplikacji internetowych. W tej sekcji znajdziesz szczegółowe informacje o twardych i miękkich interfejsach API, które są niezbędne do zapewnienia zgodności, a także o niektórych innych istotnych zachowaniach technicznych i interfejsu użytkownika. Implementacje urządzeń MUSZĄ spełniać wszystkie wymagania opisane w tej sekcji.

3.1. Zgodność z zarządzanym interfejsem API

Zarządzane środowisko wykonawcze (oparte na Dalviku) jest głównym narzędziem do uruchamiania aplikacji na Androida. Interfejs programowania aplikacji (API) Androida to zbiór interfejsów platformy Androida udostępnionych aplikacjom działającym w zarządzanym środowisku maszyny wirtualnej. Implementacje na urządzeniu MUSZĄ zawierać kompletne implementacje wszystkich interfejsów API opisanych w pakiecie SDK Androida 2.3 [Zasoby, 4], w tym wszystkich opisanych zachowań.

Implementacje na urządzeniach NIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów API ani ich podpisów, odbiegać od udokumentowanego zachowania lub zawierać operacji niemających żadnego działania, z wyjątkiem przypadków, w których jest to wyraźnie dozwolone przez tę definicję zgodności.

Ta definicja zgodności zezwala na pominięcie przez implementacje urządzeń niektórych typów sprzętu, dla których Android zawiera interfejsy API. 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 interfejsem API w wersji próbnej

Oprócz zarządzanych interfejsów API wymienionych w sekcji 3.1 Android zawiera też istotne „miękkie” interfejsy API używane tylko w czasie wykonywania, takie jak intencje, uprawnienia i inne aspekty aplikacji na Androida, których nie można wymusić w czasie kompilacji aplikacji. W tej sekcji znajdziesz szczegółowe informacje o interfejsach API „soft” i zachowaniach systemu, które są wymagane do zapewnienia zgodności z Androidem 2.3. Implementacje urządzeń MUSZĄ spełniać wszystkie wymagania podane w tej sekcji.

3.2.1. Uprawnienia

Implementatorzy urządzeń MUSZĄ obsługiwać i stosować wszystkie stałe uprawnienia zgodnie z informacjami na stronie referencyjnej dotyczącej uprawnień [Materiały, 5]. Pamiętaj, że w sekcji 10 wymieniono dodatkowe wymagania dotyczące modelu zabezpieczeń Androida.

3.2.2. Parametry tworzenia

Interfejsy API Androida zawierają kilka stałych wartości w klasie android.os.Build[Resources, 6], które mają opisywać bieżące urządzenie. Aby zapewnić spójne i znaczeniowe wartości we wszystkich implementacjach urządzeń, w tabeli poniżej znajdziesz dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi implementacje urządzeń MUSZĄ być zgodne.

Parametr	Komentarze
android.os.Build.VERSION.RELEASE	Wersja aktualnie uruchomionego systemu Android w czytelnym dla człowieka formacie. To pole MUSI zawierać jeden z ciągów znaków zdefiniowanych w sekcji [Resources, 7].
android.os.Build.VERSION.SDK	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 2.3 to pole MUSI zawierać wartość całkowitą 9.
android.os.Build.VERSION.INCREMENTAL	Wartość wybrana przez implementatora urządzenia, która określa wersję bieżąco działającego systemu Android w czytelnym dla człowieka formacie. Tej wartości NIE MOŻNA używać ponownie w przypadku różnych wersji udostępnionych użytkownikom. Typowym zastosowaniem tego pola jest wskazanie, który numer kompilacji lub identyfikator zmiany w kontroli źródłowej posłużył do wygenerowania kompilacji. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („"”).
android.os.Build.BOARD	Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretny wewnętrzny sprzęt używany przez urządzenie w czytelnym dla człowieka formacie. Możliwe zastosowanie tego pola to wskazanie konkretnej wersji płyty głównej zasilającej urządzenie. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i zgodna z wyrażeniem regularnym "^[a-zA-Z0-9.,_-]+$".
android.os.Build.BRAND	Wartość wybrana przez implementatora urządzenia, która identyfikuje nazwę firmy, organizacji, osoby itp., która wyprodukowała urządzenie, w formacie zrozumiałym dla człowieka. To pole można wykorzystać do wskazania OEM-a lub operatora, który sprzedał urządzenie. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego "^[a-zA-Z0-9.,_-]+$".
android.os.Build.DEVICE	Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretną konfigurację lub wersję obudowy (czasami nazywaną „wzornictwem przemysłowym”) urządzenia. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego "^[a-zA-Z0-9.,_-]+$".
android.os.Build.FINGERPRINT	Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być w rozsądnym stopniu czytelny dla człowieka. Musi on być zgodny z tym szablonem: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Na przykład: acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys Odcisk palca NIE może zawierać znaków odstępu. Jeśli inne pola w powyższym szablonie zawierają znaki odstępu, należy je zastąpić w pliku danych o budowaniu pliku danych o odciskach palców innym znakiem, np. podkreśleniem („_”). Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII.
android.os.Build.HOST	Ciąg znaków, który w czytelnym dla człowieka formacie jednoznacznie identyfikuje hosta, na którym została utworzona kompilacja. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono być puste ani nie może zawierać pustego ciągu znaków („”).
android.os.Build.ID	Identyfikator wybrany przez implementatora urządzenia, który odnosi się do konkretnej wersji w czytelnym dla człowieka formacie. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINIEN zawierać wartość wystarczająco istotną, aby użytkownicy mogli odróżnić różne wersje oprogramowania. Wartość w tym polu MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym "^[a-zA-Z0-9.,_-]+$".
android.os.Build.MODEL	Wartość wybrana przez implementatora urządzenia zawierająca nazwę urządzenia znaną użytkownikowi. Powinna to być ta sama nazwa, pod którą urządzenie jest sprzedawane użytkownikom. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE może być ono puste ani nie może zawierać pustego ciągu znaków („"").
android.os.Build.PRODUCT	Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową urządzenia. MUSI być zrozumiała dla człowieka, ale nie musi być przeznaczona do wyświetlania użytkownikom. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TAGS	Lista tagów wybranych przez implementatora urządzenia, rozdzielona przecinkami, która dodatkowo rozróżnia kompilację. Na przykład „unsigned,debug”. Wartość w tym polu MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME	Wartość reprezentująca sygnaturę czasową utworzenia kompilacji.
android.os.Build.TYPE	Wartość wybrana przez implementatora urządzenia określająca konfigurację środowiska wykonawczego kompilacji. To pole MUSI zawierać jedną z wartości odpowiadających 3 typowym konfiguracjom środowiska uruchomieniowego Androida: „user”, „userdebug” lub „eng”. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego "^[a-zA-Z0-9.,_-]+$".
android.os.Build.USER	Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował kompilację. Nie ma żadnych wymagań dotyczących formatu tego pola, z tym wyjątkiem, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („"").

3.2.3. Zgodność z zamiarem

Android używa intencji do luźnej integracji aplikacji. W tej sekcji opisano wymagania dotyczące wzorów intencji, które MUSZĄ być obsługiwane przez implementacje na urządzeniach. „Spełnianie” oznacza, że implementator urządzenia MUSI udostępnić aktywność lub usługę na 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 upstream Androida definiuje kilka podstawowych aplikacji, takich jak wybieranie numeru, kalendarz, książka adresowa czy odtwarzacz muzyki. Deweloperzy urządzeń MOGĄ zastąpić te aplikacje alternatywnymi wersjami.

Jednak takie alternatywne wersje MUSZĄ przestrzegać tych samych wzorów intencji, które są dostarczane przez projekt źródłowy. Jeśli na przykład urządzenie ma alternatywny odtwarzacz muzyki, nadal musi obsługiwać wzór intencji wydawany przez aplikacje innych firm, aby wybrać utwór.

Te aplikacje są uważane za podstawowe aplikacje systemu Android:

• Zegar biurkowy
• Przeglądarka
• Kalendarz
• Kalkulator
• kontakty,
• Wysyłając e-mailem
• Galeria
• GlobalSearch
• Wyrzutnia
• Muzyka
• Ustawienia

Główne aplikacje systemu Android zawierają różne komponenty Activity lub Service, które są uważane za „publiczne”. Oznacza to, że atrybut „android:exported” może być nieobecny lub mieć wartość „true”.

W przypadku każdej aktywności lub usługi zdefiniowanej w jednej z podstawowych aplikacji systemowych Androida, która nie jest oznaczona jako prywatna za pomocą atrybutu android:exported o wartości „false”, implementacje na urządzeniu MUSZĄ zawierać komponent tego samego typu, który wdraża te same wzorce filtra intencji co podstawowa aplikacja systemowa Androida.

Innymi słowy, implementacja urządzenia MOŻE zastąpić podstawowe aplikacje systemowe Androida, ale jeśli tak się stanie, implementacja urządzenia MUSI obsługiwać wszystkie wzorce intencji zdefiniowane przez każdą podstawową aplikację systemową Androida, która zostanie zastąpiona.

3.2.3.2. Zastąpienia intencji

Ponieważ Android jest platformą rozszerzalną, implementatorzy urządzeń MUSZĄ zezwolić na zastąpienie każdego wzorca intencji, o którym mowa w sekcji 3.2.3.1, przez aplikacje innych firm. Górny projekt o źródle otwartym Androida zezwala na to domyślnie. Implementatorzy urządzeń NIE MOGĄ przypisywać specjalnych uprawnień do korzystania z tych wzorów intencji przez aplikacje systemowe ani uniemożliwiać aplikacjom innych firm wiązania się z tymi wzorami i przejmowania nad nimi kontroli. Zakaz ten obejmuje m.in. wyłączenie interfejsu „Wybór”, który umożliwia użytkownikowi wybór spośród wielu aplikacji, z których każda obsługuje ten sam wzór intencji.

3.2.3.3. Przestrzenie nazw intencji

Implementatorzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub intencji rozgłoszeniowych za pomocą działania, kategorii ani innego kluczowego ciągu znaków w przestrzeni nazw android.*. Implementatorzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub intencji rozgłoszenia za pomocą 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.

Ten zakaz jest analogiczny do zakazu określonego w sekcji 3.6 dotyczącego klas języka Java.

3.2.3.4. Zamiary związane z transmisją

Aplikacje innych firm polegają na platformie, aby przesyłać określone intencje, które informują je o zmianach w środowisku sprzętowym lub programowym. Urządzenia zgodne z Androidem MUSZĄ transmitować publiczne intencje broadcastu w odpowiedzi na odpowiednie zdarzenia systemowe. Intencje dotyczące transmisji są opisane w dokumentacji pakietu SDK.

3.3. Zgodność z natywnym interfejsem API

Kod zarządzany działający w Dalviku może wywoływać kod natywny dostarczony w pliku aplikacji .apk jako plik .so ELF skompilowany dla odpowiedniej architektury sprzętowej urządzenia. Ponieważ kod natywny jest silnie zależny od podstawowej technologii procesora, Android definiuje w Android NDK w pliku docs/CPU-ARCH-ABIS.txt kilka interfejsów binarnych aplikacji (ABI). Jeśli implementacja na urządzeniu jest zgodna z co najmniej 1 zdefiniowanym ABI, powinna być zgodna z Android NDK, jak pokazano poniżej.

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

• MUSI zawierać obsługę kodu działającego w środowisku zarządzanym, aby wywoływać kod natywny, korzystając ze standardowej semanttyki interfejsu JNI (Java Native Interface).
• MUSI być zgodny pod względem źródłowym (czyli zgodny z nagłówkiem) i binarnym (w przypadku interfejsu ABI) z każdą wymaganą biblioteką na liście poniżej.
• NALEŻY dokładnie podać natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pomocą interfejsu API android.os.Build.CPU_ABI.
• NALEŻY zgłaszać tylko te ABI, które są udokumentowane w najnowszej wersji Android NDK w pliku docs/CPU-ARCH-ABIS.txt
• NALEŻY go skompilować, używając kodu źródłowego i plików nagłówkowych dostępnych w poprzednim projekcie Androida open source.

Te interfejsy API natywnego kodu MUSZĄ być dostępne dla aplikacji, które zawierają kod natywny:

• libc (biblioteka C)
• libm (biblioteka matematyczna)
• Minimalne wsparcie dla C++
• Interfejs JNI
• liblog (rejestrowanie na Androidzie)
• libz (kompresja Zlib)
• libdl (linker dynamiczny)
• libGLESv1_CM.so (OpenGL ES 1.0)
• libGLESv2.so (OpenGL ES 2.0)
• libEGL.so (własne zarządzanie powierzchnią OpenGL)
• libjnigraphics.so
• libOpenSLES.so (obsługa biblioteki Open Sound Library)
• libandroid.so (obsługa natywnej aktywności Androida)
• Obsługa OpenGL, jak opisano poniżej

Pamiętaj, że w kolejnych wersjach NDK na Androida możemy dodać obsługę dodatkowych ABI. Jeśli implementacja urządzenia nie jest zgodna z dotychczasowym wstępnie zdefiniowanym ABI, NIE MOŻE zgłaszać obsługi żadnego ABI.

Zgodność kodu natywnego jest trudna do osiągnięcia. Dlatego należy pamiętać, że implementatorzy urządzeń powinni bardzo mocno zachęcać do korzystania z implementacji bibliotek wymienionych powyżej, aby zapewnić zgodność.

3.4. Zgodność z przeglądarką

Wielu deweloperów i aplikacji korzysta z działania klasy android.webkit.WebView [Resources, 8] w swoich interfejsach użytkownika, dlatego implementacja WebView musi być zgodna ze wszystkimi implementacjami Androida. Podobnie nowoczesna przeglądarka internetowa jest kluczowa dla wygody użytkowników Androida. Implementacje na urządzeniach MUSZĄ zawierać wersję android.webkit.WebView zgodną z oprogramowaniem Androida na poziomie upstream i MUSZĄ zawierać nowoczesną przeglądarkę obsługującą HTML5, jak opisano poniżej.

3.4.1. Zgodność WebView

Implementacja open source na Androida używa silnika renderowania WebKit do implementowania android.webkit.WebView. Ponieważ niemożliwe jest opracowanie kompleksowego zestawu testów dla systemu renderowania stron internetowych, implementatorzy urządzeń MUSZĄ używać określonej wersji WebKit w ramach implementacji WebView. Więcej szczegółów:

• Implementacje na urządzeniach android.webkit.WebView muszą być oparte na kompilacji WebKit 533.1 z gałęzi źródłowej drzewa Android Open Source dla Androida 2.3. Ta kompilacja zawiera określony zestaw funkcji i poprawek zabezpieczeń dla WebView. Implementatorzy urządzeń MOGĄ dostosować implementację WebKit, ale wszelkie takie modyfikacje NIE MOGĄ zmieniać działania WebView, w tym renderowania.
• Ciąg znaków klienta użytkownika przesyłany przez WebView musi mieć format:
  Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
  • Wartość ciągu znaków $(VERSION) MUSI być taka sama jak wartość parametru android.os.Build.VERSION.RELEASE.
  • Wartość ciągu tekstowego $(LOCALE) powinna być zgodna z konwencjami ISO dotyczącymi kodu kraju i języka oraz odnosić się do aktualnie skonfigurowanej lokalizacji urządzenia.
  • Wartość ciągu znaków $(MODEL) MUSI być taka sama jak wartość android.os.Build.MODEL
  • Wartość ciągu znaków $(BUILD) MUSI być taka sama jak wartość parametru android.os.Build.ID.

Komponent WebView powinien obsługiwać jak najwięcej funkcji HTML5 [Zasoby, 9]. Implementacje na urządzeniach MUSZĄ obsługiwać co najmniej te interfejsy API związane z HTML5 w WebView:

• pamięć podręczna aplikacji/działanie w trybie offline [Resources, 10]
• tag <video> [Resources, 11]
• geolokalizacja [Resources, 12]

Implementacje urządzeń MUSZĄ obsługiwać interfejs API webstorage HTML5/W3C [Resources, 13] i POWINNY obsługiwać interfejs API IndexedDB HTML5/W3C [Resources, 14]. Pamiętaj, że organizacje opracowujące standardy w zakresie tworzenia stron internetowych przechodzą na IndexedDB zamiast webstorage, dlatego IndexedDB ma stać się wymaganym komponentem w przyszłej wersji Androida.

Interfejsy API HTML5, podobnie jak wszystkie interfejsy API JavaScriptu, muszą być domyślnie wyłączone w komponencie WebView, chyba że 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ądzeniach MUSZĄ zawierać samodzielną aplikację przeglądarki do ogólnego przeglądania internetu przez użytkownika. Samodzielna przeglądarka MOŻE być o zasadzie oparte na technologii przeglądarki innej niż WebKit. Jednak nawet jeśli używana jest inna przeglądarka, komponent android.webkit.WebView udostępniany aplikacjom innych firm MUSI być oparty na WebKit, zgodnie z opisem w sekcji 3.4.1.

Implementacje mogą zawierać niestandardowy ciąg znaków klienta użytkownika w samodzielnej aplikacji przeglądarki.

Samodzielna aplikacja przeglądarki (oparta na aplikacji przeglądarki WebKit lub na zamienniku innej firmy) POWINNA obsługiwać jak najwięcej funkcji HTML5 [Zasoby, 9]. Implementacje na urządzeniach MUSZĄ obsługiwać co najmniej te interfejsy API związane z HTML5:

• pamięć podręczna aplikacji/działanie w trybie offline [Resources, 10]
• tag <video> [Resources, 11]
• geolokalizacja [Resources, 12]

Implementacje urządzeń MUSZĄ obsługiwać interfejs API webstorage HTML5/W3C [Resources, 13] i POWINNY obsługiwać interfejs API IndexedDB HTML5/W3C [Resources, 14]. Pamiętaj, że organizacje opracowujące standardy w zakresie tworzenia stron internetowych przechodzą na IndexedDB zamiast webstorage, dlatego IndexedDB ma stać się wymaganym komponentem w przyszłej wersji Androida.

3.5. Zgodność zachowania interfejsu API

Zachowanie każdego z typów interfejsu API (zarządzanego, miękkiego, natywnego i internetowego) musi być zgodne z preferowaną implementacją w górnym projekcie open source na Androida [Materiały, 3]. Oto niektóre obszary zgodności:

• Urządzenia NIE MOGĄ zmieniać działania ani semantyki standardowego zamiaru.
• Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia danego typu komponentu systemu (np. usługi, aktywności, dostawcy treści itp.).
• Urządzenia NIE MOGĄ zmieniać semantyki standardowych uprawnień.

Powyższa lista nie jest wyczerpująca. Pakiet Compatibility Test Suite (CTS) testuje znaczne części platformy pod kątem zgodności behawioralnej, ale nie wszystkich. Implementator jest odpowiedzialny za zapewnienie zgodności behawioralnej z Android Open Source Project. Dlatego implementatorzy urządzeń powinni w miarę możliwości korzystać z kodu źródłowego dostępnego w ramach projektu Android Open Source, a nie ponownie implementować istotnych części systemu.

3.6. Nazwy katalogów interfejsu API

Android stosuje konwencje dotyczące przestrzeni nazw pakietów i klas zdefiniowane przez język programowania Java. Aby zapewnić zgodność z aplikacjami innych firm, implementatorzy urządzeń NIE MOGĄ wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w tych przestrzeniach nazw pakietów:

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

Zakazane modyfikacje:

• Implementacje na urządzeniu NIE MOGĄ modyfikować publicznie udostępnionych interfejsów API na platformie Androida przez zmianę sygnatur metod lub klas albo usunięcie klas lub pól klas.
• Implementatorzy urządzeń MOGĄ modyfikować implementację interfejsów API, ale takie modyfikacje NIE MOGĄ wpływać na opisane zachowanie i podpis w języku Java interfejsów API udostępnionych publicznie.
• Implementatorzy urządzeń NIE MOGĄ dodawać do interfejsów API żadnych publicznie dostępnych elementów (takich jak klasy, interfejsy, pola czy metody do istniejących klas lub interfejsów).

„Publicznie dostępny element” to dowolna konstrukcja, która nie jest ozdobiona znacznikiem „@hide” używanym w górnym kodzie źródłowym Androida. Innymi słowy, implementatorzy urządzeń NIE MOGĄ udostępniać nowych interfejsów API ani zmieniać istniejących interfejsów API w wymienionych powyżej przestrzeniach nazw. Implementatorzy urządzeń mogą wprowadzić zmiany przeznaczone tylko do użytku wewnętrznego, ale te zmiany NIE MOGĄ być reklamowane ani w inny sposób udostępniane deweloperom.

Implementatorzy urządzeń MOGĄ dodawać niestandardowe interfejsy API, ale nie mogą umieszczać ich w przestrzeni nazw należącej do innej organizacji lub nawiązującej do niej. Na przykład implementatorzy urządzeń NIE MOGĄ dodawać interfejsów API do przestrzeni nazw com.google.* ani podobnych; może to robić tylko Google. Podobnie Google NIE MOŻE dodawać interfejsów API do przestrzeni nazw innych firm. Jeśli implementacja na urządzeniu zawiera niestandardowe interfejsy API spoza standardowego obszaru nazw Androida, muszą one zostać zapakowane w bibliotece współdzielonej Androida, aby tylko aplikacje, które z nich wyraźnie korzystają (za pomocą mechanizmu <uses-library>), były objęte zwiększonym zużyciem pamięci przez te interfejsy API.

Jeśli implementator urządzenia zamierza ulepszyć jeden z wymienionych powyżej przestrzeni nazw pakietów (np. przez dodanie nowej przydatnej funkcji do istniejącego interfejsu API lub dodanie nowego interfejsu API), powinien odwiedzić stronę source.android.com i rozpocząć proces przesyłania zmian i kodu zgodnie z informacjami na tej stronie.

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

3.7. Zgodność maszyny wirtualnej

Implementacje na urządzeniu MUSZĄ obsługiwać pełną specyfikację bajtkodów Dalvik Executable (DEX) i semantykę Dalvik Virtual Machine [Resources, 15].

W przypadku implementacji urządzeń z ekranami o średniej lub niskiej gęstości pamięci należy skonfigurować Dalvik tak, aby każdej aplikacji przydzielić co najmniej 16 MB pamięci. Implementacje urządzeń z ekranami o wysokiej lub bardzo wysokiej gęstości pikseli MUSZĄ skonfigurować Dalvik tak, aby przydzielić co najmniej 24 MB pamięci każdej aplikacji. Pamiętaj, że implementacje na urządzeniach MOGĄ przydzielić więcej pamięci niż te wartości.

3.8. Zgodność interfejsu

Platforma Androida zawiera interfejsy API dla deweloperów, które umożliwiają im łączenie się z interfejsem użytkownika systemu. Implementacje na urządzeniach MUSZĄ uwzględniać te standardowe interfejsy API w ramach niestandardowych interfejsów użytkownika, które są przez nie tworzone, zgodnie z opisem poniżej.

3.8.1. Widżety

Android definiuje typ komponentu oraz odpowiadający mu interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie „widżetu aplikacji” użytkownikowi końcowemu [Resources, 16]. Wersja referencyjna Androida 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.

Implementatorzy urządzeń mogą zastąpić domyślny Launcher alternatywą (np. ekranem głównym). Alternatywny program uruchamiający MUSI zawierać wbudowane wsparcie dla widżetów aplikacji i elementy interfejsu użytkownika umożliwiające dodawanie, konfigurowanie, wyświetlanie i usuwanie widżetów bezpośrednio w programie uruchamiającym. Alternatywny Launcher MOŻE pominąć te elementy interfejsu użytkownika. Jeśli jednak pominie je, implementator urządzenia MUSI udostępnić osobną aplikację dostępną w Launcherze, która umożliwia użytkownikom dodawanie, konfigurowanie, wyświetlanie i usuwanie widżetów aplikacji.

3.8.2. Powiadomienia

Android zawiera interfejsy API, które umożliwiają programistom powiadamianie użytkowników o istotnych wydarzeniach [Materiały, 17]. Implementatorzy urządzeń MUSZĄ zapewnić obsługę każdej z tak zdefiniowanych klas powiadomień, w tym dźwięków, wibracji, światła i paska stanu.

Ponadto implementacja MUSI poprawnie renderować wszystkie zasoby (ikony, pliki dźwiękowe itp.) udostępnione w interfejsach API [Resources, 18] lub w przewodniku po stylu ikonek paska stanu [Resources, 19]. Implementatorzy urządzeń MOGĄ zapewnić użytkownikom odmienne wrażenia związane z powiadomieniami niż w przypadku referencyjnej implementacji Androida Open Source. Jednak takie alternatywne systemy powiadomień MUSZĄ obsługiwać istniejące zasoby powiadomień, jak opisano powyżej.

3.8.3. Szukaj

Android zawiera interfejsy API [Resources, 20], które umożliwiają deweloperom wdrażanie wyszukiwania w aplikacjach oraz udostępnianie danych aplikacji w globalnym wyszukiwaniu systemowym. Ogólnie rzecz biorąc, ta funkcja składa się z jednego interfejsu użytkownika obejmującego cały system, który umożliwia użytkownikom wpisywanie zapytań, wyświetlanie sugestii podczas wpisywania tekstu oraz wyświetlanie wyników. Interfejsy API Androida umożliwiają deweloperom ponowne używanie tego interfejsu do udostępniania wyszukiwania w ich własnych aplikacjach oraz dostarczania wyników do wspólnego globalnego interfejsu wyszukiwania.

Implementacje na urządzeniu MUSZĄ zawierać jeden wspólny interfejs użytkownika wyszukiwarki, który umożliwia wyświetlanie sugestii w czasie rzeczywistym w odpowiedzi na dane wejściowe użytkownika. Implementacje urządzeń MUSZĄ zawierać interfejsy API, które umożliwiają deweloperom ponowne użycie tego interfejsu użytkownika w celu udostępnienia wyszukiwania w ich własnych aplikacjach. Implementacje na urządzeniach MUSZĄ implementować interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii do pola wyszukiwania, gdy jest ono używane w trybie wyszukiwania globalnego. Jeśli nie są zainstalowane żadne aplikacje innych firm, które korzystają z tej funkcji, domyślnie powinny być wyświetlane wyniki wyszukiwania w wyszukiwarce internetowej oraz sugestie.

Implementacje na urządzeniach mogą zawierać alternatywne interfejsy wyszukiwania, ale powinny zawierać twardy lub miękki przycisk wyszukiwania, którego można używać w dowolnym momencie w dowolnej aplikacji, aby wywołać interfejs wyszukiwania. Zachowanie tego przycisku zostało opisane w dokumentacji interfejsu API.

3.8.4. Toasty

Aplikacje mogą używać interfejsu Toast API (zdefiniowanego w [Zasoby, 21]), aby wyświetlać użytkownikowi krótkie niemodalne ciągi znaków, które znikają po krótkim czasie. Implementacje na urządzeniach MUSZĄ wyświetlać komunikaty typu Toast aplikacji dla użytkowników w sposób dobrze widoczny.

3.8.5. Animowane tapety

Android definiuje typ komponentu oraz odpowiedni interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi co najmniej jednej „żywej tapety” [Zasoby, 22]. Tapety na żywo to animacje, wzory lub podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które wyświetlają się jako tapeta za innymi aplikacjami.

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 ulegają awarii, 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 wyświetlania tapety 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ć prawidłowo na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ korzystanie z kontekstu OpenGL przez tapetę na żywo może powodować konflikty z innymi aplikacjami, które również korzystają z tego kontekstu.

Urządzenia, które mogą prawidłowo wyświetlać animowane tapety zgodnie z opisem powyżej, POWINNY obsługiwać animowane tapety. Urządzenia, które nie działają zgodnie z opisem powyżej, nie mogą wyświetlać animowanych tapet.

4. Zgodność z pakietem aplikacji

Implementacje urządzeń MUSZĄ instalować i uruchamiać pliki „.apk” na Androida wygenerowane przez narzędzie „aapt” zawarte w oficjalnym pakiecie SDK Androida [Resources, 23].

Implementacje urządzeń NIE MOGĄ rozszerzać formatów plików .apk [Zasoby, 24], manifestu Androida [Zasoby, 25] ani kodu bajtowego Dalvik [Zasoby, 15] w taki sposób, aby uniemożliwić ich prawidłową instalację i działanie na innych zgodnych urządzeniach. Implementatorzy urządzeń powinni używać referencyjnej implementacji Dalvik w górę łańcucha i systemu zarządzania pakietami referencyjnej implementacji.

5. Zgodność multimedialna

Implementacje na urządzeniach MUSZĄ w pełni implementować wszystkie interfejsy multimedialne API. Implementacje na urządzeniach MUSZĄ obsługiwać wszystkie kodeki multimedialne opisane poniżej i POWINNY być zgodne z wytycznymi dotyczącymi przetwarzania dźwięku opisanymi poniżej. Implementacje na urządzeniu MUSZĄ zawierać co najmniej 1 formę wyjścia audio, np. głośniki, gniazdo słuchawkowe, złącze do głośnika zewnętrznego itp.

5.1. Kodeki multimedialne

Implementacje urządzeń MUSZĄ obsługiwać kodeki multimedialne zgodnie z opisem w następnych sekcjach. Wszystkie te kodeki są dostarczane jako implementacje oprogramowania w ramach preferowanej implementacji Androida z Projektu Android Open Source.

Należy pamiętać, że ani Google, ani Open Handset Alliance nie gwarantują, że te kodeki nie są objęte patentami osób trzecich. Osoby, które chcą używać tego kodu źródłowego w urządzeniach lub produktach programowych, powinny pamiętać, że implementacje tego kodu, w tym w oprogramowaniu open source lub shareware, mogą wymagać licencji na patenty od odpowiednich właścicieli patentów.

Tabele poniżej nie zawierają konkretnych wymagań dotyczących szybkości transmisji danych w przypadku większości kodeków wideo. Dzieje się tak, ponieważ w praktyce obecny sprzęt niekoniecznie obsługuje bitrate, który odpowiada dokładnie wymaganemu bitrate określonemu przez odpowiednie standardy. Zamiast tego implementacje urządzeń powinny obsługiwać najwyższą możliwą szybkość transmisji bitów na sprzęcie, do limitów określonych w specyfikacji.

5.1.1. Dekodery multimediów

Implementacje na urządzeniach MUSZĄ zawierać dekoder dla każdego kodeka i formatu opisanego w tabeli poniżej. Pamiętaj, że dekodery dla każdego z tych typów multimediów są dostarczane przez projekt Android Open-Source.

Dźwięk
	Nazwa	Szczegóły	Format pliku/kontenera
	AAC LC/LTP	mono lub stereo w dowolnej kombinacji standardowych szybkości transmisji bitów do 160 kb/s i częstotliwości próbkowania od 8 do 48 kHz;	3GPP (.3gp) i MPEG-4 (.mp4, .m4a). Nieobsługiwane są pliki AAC (.aac) w formacie surowym.
	HE-AACv1 (AAC+)
	HE-AACv2 (ulepszone AAC+)
	AMR-NB	4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz	3GPP (.3gp)
	AMR-WB	9 szybkości od 6,60 kb/s do 23,85 kb/s z próbkowaniem 16 kHz	3GPP (.3gp)
	MP3	Mono/Stereo 8–320 kb/s CBR lub VBR	MP3 (.mp3)
	MIDI	Typ MIDI 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody	Typ 0 i 1 (.mid, .xmf, .mxmf). Dozwolone są też formaty RTTTL/RTX (.rtttl, .rtx), OTA (.ota) i iMelody (.imy).
	Ogg Vorbis		Ogg (.ogg)
	Menedżer połączeń z partnerami	8- i 16-bitowy linearny PCM (szybkości do limitu sprzętowego)	WAVE (.wav)
Obraz
	JPEG	podstawowa + progresywna
	GIF
	PNG
	BMP
Film
	H.263		pliki 3GPP (.3gp);
	H.264		pliki 3GPP (.3gp) i MPEG-4 (.mp4);
	MPEG4 Simple Profile		Plik 3GPP (.3gp)

5.1.2. Kodery mediów

Implementacje urządzeń powinny obejmować kodery dla jak największej liczby formatów multimediów wymienionych w sekcji 5.1.1. Niektóre kodery nie są jednak przydatne na urządzeniach, które nie mają określonego dodatkowego sprzętu. Na przykład koder dla wideo H.263 nie ma sensu, jeśli urządzenie nie ma kamer. Dlatego implementacje na urządzeniach MUSZĄ stosować kodery multimediów zgodnie z warunkami opisanymi w tabeli poniżej.

Szczegółowe informacje o warunkach, w których implementacje urządzeń mogą pomijać sprzęt, znajdziesz w sekcji 7.

Dźwięk
	Nazwa	Szczegóły	Format pliku/kontenera	Warunki
	AMR-NB	4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz	3GPP (.3gp)	Implementacje urządzeń, które zawierają sprzęt mikrofonowy i definiują android.hardware.microphone, MUSZĄ zawierać kodery dla tych formatów audio.
	AMR-WB	9 szybkości od 6,60 kb/s do 23,85 kb/s z próbkowaniem 16 kHz	3GPP (.3gp)
	AAC LC/LTP	mono lub stereo w dowolnej kombinacji standardowych szybkości transmisji bitów do 160 kb/s i częstotliwości próbkowania od 8 do 48 kHz;	3GPP (.3gp) i MPEG-4 (.mp4, .m4a).
Obraz	JPEG	podstawowa + progresywna		Wszystkie implementacje urządzeń MUSZĄ zawierać kodery dla tych formatów obrazów, ponieważ Android 2.3 zawiera interfejsy API, których aplikacje mogą używać do generowania programowo plików tych typów.
	PNG
Film	H.263		pliki 3GPP (.3gp);	Implementacje urządzeń, które zawierają sprzęt kamery i określają android.hardware.camera lub android.hardware.camera.front, MUSZĄ zawierać kodery dla tych formatów wideo.

Oprócz wymienionych powyżej koderów implementacje na urządzeniach POWINNY zawierać koder H.264. Pamiętaj, że w przyszłej wersji definicji zgodności planujemy zmienić ten wymóg na „MUST”. Oznacza to, że kodowanie H.264 jest opcjonalne w Androidzie 2.3, ale będzie wymagane w przyszłej wersji. Istniejące i nowe urządzenia z Androidem 2.3 bardzo prosimy o spełnienie tego wymagania w Androidzie 2.3, ponieważ w przeciwnym razie nie będą zgodne z Androidem po przejściu na nowszą wersję.

5.2. Nagrywanie dźwięku

Gdy aplikacja użyje interfejsu android.media.AudioRecord API, aby rozpocząć nagrywanie strumienia audio, implementacje na urządzeniu POWINNY pobierać próbki i nagrywać dźwięk z użyciem tych zachowań:

• Przetwarzanie redukcji szumów (jeśli jest dostępne) POWINNA być wyłączona.
• Automatyczna kontrola wzmocnienia (jeśli jest dostępna) powinna być wyłączona.
• Urządzenie POWINNA mieć charakterystyki zbliżone do płaskich charakterystyk amplitudy w zależności od częstotliwości, a precyzyjniej ±3 dB w zakresie 100–4000 Hz.
• Czułość wejścia audio powinna być ustawiona tak, aby źródło o poziomie mocy dźwięku (SPL) wynoszącym 90 dB przy częstotliwości 1000 Hz dawało wartość RMS wynoszącą 5000 dla próbek 16-bitowych.
• Poziomy amplitudy PCM POWINNY śledzić zmiany SPL wejścia w zakresie co najmniej 30 dB od –18 dB do +12 dB w skali SPL 90 dB przy mikrofonie.
• Całkowite zniekształcenie harmoniczne POWINIEN być mniejszy niż 1% w zakresie 100–4000 Hz przy poziomie wejściowym 90 dB SPL.

Uwaga: chociaż wymagania opisane powyżej są oznaczone jako „NALEŻY” w przypadku Androida 2.3, w przyszłej definicji zgodności planujemy zmienić je na „NALEŻY”. Oznacza to, że te wymagania są opcjonalne w Androidzie 2.3, ale staną się wymagane w przyszłej wersji. Istniejące i nowe urządzenia z Androidem 2.3 powinny spełniać te wymagania w Androidzie 2.3. W przeciwnym razie nie będą zgodne z Androidem po przejściu na nowszą wersję.

5.3. Opóźnienie dźwięku

Opóźnienie dźwięku to ogólnie odstęp między momentem, w którym aplikacja poprosi o odtworzenie lub nagranie dźwięku, a chwilą, w której implementacja urządzenia faktycznie rozpocznie działanie. Wiele klas aplikacji wymaga krótkich opóźnień, aby uzyskać efekty w czasie rzeczywistym, takie jak efekty dźwiękowe czy komunikacja VOIP. Implementacje urządzeń, które zawierają sprzęt mikrofonowy i deklarują android.hardware.microphone, POWINNY spełniać wszystkie wymagania dotyczące opóźnienia dźwięku opisane w tej sekcji. W sekcji 7 znajdziesz szczegółowe informacje o warunkach, w których implementacje urządzeń mogą pominąć sprzętowy mikrofon.

Na potrzeby tej sekcji:

• „Opóźnienie wyjścia po zimnym uruchomieniu” to czas od momentu, gdy aplikacja poprosi o odtworzenie dźwięku, do momentu, gdy dźwięk zacznie się odtwarzać, gdy system audio był nieaktywny i wyłączony przed żądaniem.
• „Opóźnienie wyjściowe w stanie gotowości” to przedział czasu od momentu, gdy aplikacja poprosi o odtworzenie dźwięku, do momentu, gdy dźwięk zacznie się odtwarzać, gdy system audio był niedawno używany, ale obecnie jest nieaktywny (czyli nie emituje dźwięku).
• „Ciągła latencja wyjściowa” to przedział czasu między momentem, w którym aplikacja wysyła próbkę do odtworzenia, a momentem, w którym głośnik fizycznie odtwarza odpowiedni dźwięk, gdy urządzenie odtwarza dźwięk
• „Opóźnienie w przyjmowaniu danych z nieaktywnych mikrofonów” to czas od momentu, gdy aplikacja poprosi o nagranie dźwięku, do momentu, gdy pierwszy próbka zostanie przesłana do aplikacji za pomocą funkcji wywołania zwrotnego, gdy system audio i mikrofon były nieaktywne i wyłączone przed wysłaniem żądania.
• „Ciągła opóźnienie wejścia” występuje, gdy występuje dźwięk otoczenia i próbka odpowiadająca temu dźwiękowi jest dostarczana do aplikacji do nagrywania za pomocą wywołania zwrotnego, gdy urządzenie jest w trybie nagrywania.

Zgodnie z powyższymi definicjami implementacje urządzeń powinny mieć te właściwości:

• opóźnienie wyjścia „na zimno” nie większe niż 100 ms;
• opóźnienie wyjścia „na ciepło” nie większe niż 10 ms;
• ciągłe opóźnienie wyjścia na poziomie 45 ms lub mniej
• opóźnienie na wejściu „na zimno” nieprzekraczające 100 ms,
• ciągłe opóźnienie wejścia na poziomie 50 ms lub mniej,

Uwaga: chociaż wymagania opisane powyżej są oznaczone jako „NALEŻY” w przypadku Androida 2.3, w przyszłej definicji zgodności planujemy zmienić je na „NALEŻY”. Oznacza to, że te wymagania są opcjonalne w Androidzie 2.3, ale staną się wymagane w przyszłej wersji. Istniejące i nowe urządzenia z Androidem 2.3 powinny spełniać te wymagania w Androidzie 2.3. W przeciwnym razie nie będą zgodne z Androidem po przejściu na nowszą wersję.

Jeśli implementacja urządzenia spełnia wymagania podane w tej sekcji, MOŻE zgłosić obsługę dźwięku o małej latencji, zgłaszając funkcję „android.hardware.audio.low-latency” za pomocą klasy android.content.pm.PackageManager. [Resources, 27] Jeśli implementacja urządzenia nie spełnia tych wymagań, NIE MOŻE zgłaszać obsługi dźwięku o niskiej latencji.

6. Zgodność z narzędziami dla programistów

Implementacje urządzeń MUSZĄ obsługiwać narzędzia dla programistów Androida udostępniane w pakiecie Android SDK. W szczególności urządzenia zgodne z Androidem muszą być zgodne z:

• Android Debug Bridge (ADB) [Resources, 23]
  Implementacje na urządzeniu MUSZĄ obsługiwać wszystkie funkcje adbopisane w pakiecie Android SDK. Domyślnie demon adb na urządzeniu powinien być nieaktywny, ale musi istnieć dostępny dla użytkownika mechanizm włączania mostu debugowania Androida.
• Dalvik Debug Monitor Service (znany jako ddms) [Resources, 23]
  Implementacje na urządzeniu MUSZĄ obsługiwać wszystkie funkcje ddmsopisane w pakiecie Android SDK. Ponieważ ddms używa adb, obsługa ddms powinna być domyślnie nieaktywna, ale MUSI być obsługiwana, gdy użytkownik aktywuje Android Debug Bridge, jak opisano powyżej.
• Monkey [Resources, 26]
  Implementacje na urządzeniach MUSZĄ zawierać platformę Monkey i musi być ona dostępna dla aplikacji.

Większość systemów opartych na Linuksie i systemów Apple Macintosh rozpoznaje urządzenia z Androidem za pomocą standardowych narzędzi pakietu 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 w systemach Windows). Jeśli implementacja urządzenia jest nieznana dla narzędzia adb udostępnianego w standardowym pakiecie SDK Androida, implementatorzy urządzeń MUSZĄ udostępnić sterowniki Windowsa, które umożliwiają deweloperom nawiązywanie połączenia z urządzeniem za pomocą protokołu adb. Te sterowniki MUSZĄ być dostarczone w wersjach 32- i 64-bitowych dla systemów Windows XP, Windows Vista i Windows 7.

7. Zgodność sprzętowa

Android ma umożliwić implementatorom urządzeń tworzenie innowacyjnych formatów i konfiguracji. Jednocześnie deweloperzy Androida tworzą innowacyjne aplikacje, które korzystają z różnych funkcji i urządzeń dostępnych za pomocą interfejsów API Androida. Wymagania w tej sekcji zapewniają równowagę między innowacjami dostępnymi dla implementatorów urządzeń a potrzebami deweloperów, którzy chcą mieć pewność, że ich aplikacje będą dostępne tylko na urządzeniach, na których będą prawidłowo działać.

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 dokumentacją pakietu Android SDK. Jeśli interfejs API w pakiecie SDK wchodzi w interakcję ze sprzętowym komponentem, który jest oznaczony jako opcjonalny, a urządzenie nie ma tego komponentu:

• muszą być nadal obecne kompletne definicje klas (opisane w pakiecie SDK) interfejsów API komponentu;
• zachowania interfejsu API MUSZĄ być zaimplementowane w sposób, który nie wymaga interwencji użytkownika;
• Metody interfejsu API MUSZĄ zwracać wartości null, gdy jest to dozwolone przez dokumentację pakietu SDK.
• Metody interfejsu API MUSZĄ zwracać implementacje no-op klas, w których wartości null nie są dozwolone zgodnie z dokumentacją pakietu SDK.
• Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, które nie są opisane w dokumentacji pakietu SDK.

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

Implementacje urządzeń MUSZĄ prawidłowo raportować dokładne informacje o konfiguracji sprzętowej za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager. [Zasoby, 27]

7.1. Wyświetlanie i grafika

Android 2.3 zawiera funkcje, które automatycznie dostosowują zasoby aplikacji i rozkłady interfejsu do urządzenia, aby aplikacje innych firm działały prawidłowo w różnych konfiguracjach sprzętowych [Zasoby, 28]. Urządzenia MUSZĄ prawidłowo wdrażać te interfejsy API i zachowania zgodnie z opisem w tej sekcji.

7.1.1. Konfiguracje ekranu

Implementacje urządzeń mogą używać ekranów o dowolnych wymiarach w pikselach, o ile spełniają te wymagania:

• ekrany muszą mieć co najmniej 2,5 cala przekątnej;
• gęstość musi wynosić co najmniej 100 dpi
• współczynnik proporcji MUSI mieścić się w zakresie od 1,333 (4:3) do 1,779 (16:9);
• używana technologia wyświetlania składa się z kwadratowych pikseli;

Implementacje urządzeń z ekranem spełniającym powyższe wymagania są uznawane za zgodne i nie wymagają podejmowania żadnych dodatkowych działań. Implementacja w ramach frameworka Androida automatycznie oblicza cechy wyświetlania, takie jak grupa rozmiarów ekranu i grupa gęstości. W większości przypadków decyzje dotyczące frameworków są prawidłowe. Jeśli używasz domyślnych obliczeń w ramach, nie musisz nic robić. Implementatorzy urządzeń, którzy chcą zmienić domyślne ustawienia lub użyć ekranu, który nie spełnia powyższych wymagań, MUSZĄ skontaktować się z zespołem ds. zgodności z Androidem w celu uzyskania wskazówek, zgodnie z informacjami podanymi w sekcji 12.

Jednostki używane w powyższych wymaganiach są zdefiniowane w ten sposób:

• „Wymiary fizyczne przekątnej” to odległość w calach między dwoma przeciwległymi narożnikami podświetlonej części wyświetlacza.
• „dpi” (co oznacza „punkty na cal”) to liczba pikseli zawartych w liniowym zakresie poziomym lub pionowym o długości 1 cala. Jeśli podano wartości dpi, zarówno poziome, jak i pionowy dpi muszą mieścić się w tym 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ł współczynnik 854 / 480 = 1, 779, czyli mniej więcej „16:9”.

Implementacje urządzeń MUSZĄ używać tylko wyświetlaczy z jedną stałą konfiguracją. Oznacza to, że implementacje na urządzeniach NIE MOGĄ umożliwiać korzystania z wielu konfiguracji ekranu. Przykładowo typowy telewizor obsługuje wiele rozdzielczości, takich jak 1080p, 720p itp., więc ta konfiguracja nie jest zgodna z Androidem 2.3. (obsługa takich konfiguracji jest jednak badana i planowana na przyszłą wersję Androida).

7.1.2. Dane dotyczące wyświetleń

Implementacje na urządzeniu MUSZĄ przekazywać prawidłowe wartości wszystkich danych wyświetlania zdefiniowanych w android.util.DisplayMetrics [Zasoby, 29].

7.1.3. Zadeklarowana obsługa ekranu

Aplikacje opcjonalnie wskazują, które rozmiary ekranu obsługują, za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml. Implementacje urządzeń MUSZĄ prawidłowo obsługiwać deklarowane przez aplikacje wsparcie małych, średnich i dużych ekranów zgodnie z opisem w dokumentacji pakietu SDK Androida.

7.1.4. Orientacja ekranu

Zgodne urządzenia MUSZĄ obsługiwać dynamiczną orientację ekranu w aplikacji, aby można było wyświetlać obraz w orientacji poziomej lub pionowej. Oznacza to, że urządzenie musi uwzględnić prośbę aplikacji o określoną orientację ekranu. Implementacje na urządzeniach mogą domyślnie wybierać orientację pionową lub poziomą. Wymagania tego typu MOŻE spełniać urządzenie, którego nie można fizycznie obrócić, jeśli aplikacje wymagające trybu poziomego będą wyświetlane w trybie poziomym, wykorzystując tylko część dostępnego wyświetlacza.

Urządzenia MUSZĄ raportować prawidłową wartość bieżącego położenia urządzenia, gdy zostanie zapytanie o to za pomocą android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innych interfejsów API.

7.1.5. Akceleracja grafiki 3D

Implementacje na urządzeniach MUSZĄ obsługiwać OpenGL ES 1.0, zgodnie z wymaganiami interfejsów API Androida 2.3. W przypadku urządzeń bez sprzętowego przyspieszania 3D interfejs OpenGL ES 1.0 jest implementowany przez projekt Open-Source na Androidzie. Implementacje urządzeń powinny obsługiwać OpenGL ES 2.0.

Implementacje MOGĄ pominąć obsługę OpenGL ES 2.0. Jeśli jednak pominięto obsługę, implementacje urządzeń NIE MOGĄ raportować, że obsługują OpenGL ES 2.0. Jeśli implementacja urządzenia nie obsługuje OpenGL ES 2.0:

• zarządzane interfejsy API (np. za pomocą metody GLES10.getString()) NIE MOGĄ zgłaszać obsługi interfejsu OpenGL ES 2.0
• natywne interfejsy OpenGL API w językach C/C++ (czyli te dostępne dla aplikacji za pomocą libGLES_v1CM.so, libGLES_v2.so lub libEGL.so) NIE MOGĄ zgłaszać obsługi interfejsu OpenGL ES 2.0.

Jeśli natomiast implementacja urządzenia obsługuje interfejs OpenGL ES 2.0, MUSI prawidłowo zgłaszać tę obsługę za pomocą wymienionych wyżej metod.

Uwaga: Android 2.3 obsługuje opcjonalne określanie przez aplikacje wymaganych formatów kompresji tekstur OpenGL. Te formaty są zwykle specyficzne dla dostawcy. Implementacje na urządzeniach nie muszą stosować formatu kompresji tekstur z Androida 2.3. NALEŻY jednak dokładnie podać wszystkie formaty kompresji tekstur, które są obsługiwane, za pomocą metody getString() w interfejsie OpenGL API.

7.2. Urządzenia wejściowe

Android 2.3 obsługuje wiele trybów wprowadzania danych przez użytkownika. Implementacje urządzeń MUSZĄ obsługiwać urządzenia wejściowe użytkownika zgodnie z informacjami podanymi w tej sekcji.

7.2.1. Klawiatura

Implementacje na urządzeniu:

• MUSI zawierać obsługę mechanizmu zarządzania danymi wejściowymi (który pozwala deweloperom zewnętrznym tworzyć mechanizmy zarządzania danymi wejściowymi, np.klawiaturę ekranową) zgodnie z informacjami na stronie developer. android.com.
• Musisz udostępnić co najmniej 1 implementację klawiatury ekranowej (niezależnie od tego, czy jest dostępna klawiatura fizyczna)
• MOŻE zawierać dodatkowe implementacje klawiatury ekranowej
• MOŻE zawierać klawiaturę sprzętową
• NIE MOŻE zawierać klawiatury sprzętowej, która nie odpowiada żadnemu z formatów określonych w android.content.res.Configuration.keyboard[Resources, 30] (czyli QWERTY lub 12 klawiszy).

7.2.2. Nawigacja bezdotykowa

Implementacje na urządzeniu:

• MOŻE pominąć opcję nawigacji bezdotykowej (czyli może pominąć kulkę, pad lub koło)
• MUSI zawierać prawidłową wartość dla atrybutu android.content.res.Configuration.navigation [Resources, 30]
• MUSI zawierać rozsądny alternatywny mechanizm interfejsu użytkownika do zaznaczania i edytowania tekstu, który jest zgodny z silnikami zarządzania danymi wejściowymi. Kod źródłowy na platformie Android Open-Source zawiera mechanizm wyboru odpowiedni do stosowania na urządzeniach, które nie mają elementów sterujących do nawigacji bezdotykowej.

7.2.3. Klawisze nawigacyjne

Funkcje Strona główna, Menu i Wstecz są niezbędne w ramach paradygmatu nawigacji w Androidzie. Implementacje na urządzeniu MUSZĄ udostępniać te funkcje użytkownikowi przez cały czas, niezależnie od stanu aplikacji. Te funkcje NALEŻY wdrożyć za pomocą specjalnych przycisków. Mogą być wdrażane za pomocą oprogramowania, gestów, panelu dotykowego itp., ale w takim przypadku muszą być zawsze dostępne i nie mogą zasłaniać ani przeszkadzać w dostępnej powierzchni wyświetlacza aplikacji.

Implementatorzy urządzeń powinni też podać klucz wyszukiwania. Implementatorzy urządzeń mogą również udostępniać klawisze wysyłania i kończenia połączeń telefonicznych.

7.2.4. Dotykowe wprowadzanie danych

Implementacje na urządzeniu:

• Musi mieć ekran dotykowy
• MOŻE mieć pojemnościowy lub oporowy ekran dotykowy
• MUSI raportować wartość android.content.res.Configuration [Resources, 30] odpowiadającą typowi ekranu dotykowego na urządzeniu
• NALEŻY obsługiwać wskaźniki śledzone niezależnie, jeśli ekran dotykowy obsługuje wiele wskaźników

7.3. Czujniki

Android 2.3 zawiera interfejsy API umożliwiające dostęp do różnych typów czujników. Implementacje urządzeń mogą w ogóle pomijać te czujniki, jak opisano w następnych 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 w przypadku implementacji na urządzeniach:

• MUSI dokładnie raportować obecność lub brak czujników zgodnie z klasą android.content.pm.PackageManager. [Zasoby, 27]
• MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() lub podobnych metod
• MUSI działać w rozsądny sposób w przypadku wszystkich innych interfejsów API czujników (np. zwracać wartość true lub false w odpowiednich przypadkach, gdy aplikacje próbują zarejestrować odbiorniki, nie wywoływać odbiorników czujników, gdy odpowiednie czujniki są nieobecne, itp.).

Powyższa lista nie jest wyczerpująca. Należy stosować się do udokumentowanego zachowania pakietu Android SDK.

Niektóre typy czujników są syntetyczne, co oznacza, że można je uzyskać na podstawie danych pochodzących z co najmniej jednego innego czujnika. (Przykłady: czujnik orientacji i czujnik przyspieszenia liniowego). Implementacje urządzeń powinny uwzględniać te typy czujników, jeśli zawierają wymagane czujniki fizyczne.

Interfejsy API Androida 2.3 wprowadzają pojęcie „strumieniowego” czujnika, który zwraca dane ciągle, a nie tylko wtedy, gdy się zmienią. Implementacje na urządzeniach MUSZĄ stale dostarczać okresowych próbek danych dla dowolnego interfejsu API wskazanego w dokumentacji pakietu SDK Androida 2.3 jako czujnik strumieniowy.

7.3.1. Akcelerometr

Implementacje na urządzeniach powinny zawierać 3-osiowy akcelerometr. Jeśli implementacja urządzenia obejmuje 3-osiowy akcelerometr:

• MUSI być w stanie przesyłać zdarzenia z częstotliwością co najmniej 50 Hz
• MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida (patrz [Materiały, 31]).
• MUSI umożliwiać pomiar w dowolnym wektorze trójwymiarowym od swobodnego spadania do podwójnego przyspieszenia ziemskiego (2 g) lub więcej.
• Musi mieć co najmniej 8-bitową dokładność
• Odchylenie standardowe musi być mniejsze niż 0,05 m/s2

7.3.2. Magnetometr

Implementacje na urządzeniu powinny zawierać 3-osiowy magnetometr (np. kompas). Jeśli urządzenie ma 3-osiowy magnetometr:

• MUSI być w stanie przesyłać zdarzenia z częstotliwością co najmniej 10 Hz
• MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida (patrz [Materiały, 31]).
• MUSI umożliwiać próbkowanie zakresu natężeń pola odpowiedniego do pokrycia pola geomagnetycznego
• Musi mieć co najmniej 8-bitową dokładność
• Odchylenie standardowe nie może być większe niż 0,5 µT

7.3.3. GPS

Implementacje urządzeń powinny zawierać odbiornik GPS. Jeśli implementacja urządzenia obejmuje odbiornik GPS, powinna zawierać jakąś formę techniki „wspomagania GPS”, aby zminimalizować czas ustalania pozycji przez GPS.

7.3.4. Żyroskop

Implementacje na urządzeniu powinny zawierać żyroskop (czyli czujnik zmiany kątowej). Urządzenia NIE powinny zawierać czujnika żyroskopu, chyba że mają też 3-osiowy akcelerometr. Jeśli implementacja urządzenia zawiera żyroskop:

• MUSI umożliwiać pomiar zmian orientacji do 5,5*Pi radianów/sekundę (czyli około 1000 stopni na sekundę).
• MUSI być w stanie przesyłać zdarzenia z częstotliwością co najmniej 100 Hz
• Musi mieć co najmniej 8-bitową dokładność

7.3.5. barometr;

Implementacje urządzeń MOGĄ zawierać barometr (czyli czujnik ciśnienia powietrza). Jeśli implementacja urządzenia zawiera barometr, musi:

• Musi być w stanie przesyłać zdarzenia z częstotliwością co najmniej 5 Hz
• MUSI mieć odpowiednią dokładność, aby umożliwić oszacowanie wysokości

7.3.7. Termometr

Implementacje urządzeń MOGĄ, ale NIE POWINNY zawierać termometru (czyli czujnika temperatury). Jeśli implementacja urządzenia zawiera termometr, MUSI on mierzyć temperaturę procesora urządzenia. Nie wolno mierzyć innej temperatury. (Pamiętaj, że ten typ czujnika został wycofany z interfejsu API Androida 2.3).

7.3.7. Fotometr

Implementacje urządzeń MOGĄ zawierać fotometr (czyli czujnik światła otoczenia).

7.3.8. Czujnik zbliżeniowy

Urządzenia mogą być wyposażone w czujnik zbliżeniowy. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy, MUSI on mierzyć odległość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI być zorientowany tak, aby wykrywać obiekty w pobliżu ekranu, ponieważ głównym celem tego typu czujnika jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy o dowolnej innej orientacji, NIE MOŻE być on dostępny za pomocą tego interfejsu API. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy, MUSI on mieć dokładność co najmniej 1 bita.

7.4. Łączność z danymi

Połączenie z siecią i dostęp do internetu to kluczowe funkcje Androida. Interakcje między urządzeniami zwiększają użyteczność urządzeń i aplikacji na Androida. Implementacje na urządzeniach MUSZĄ spełniać wymagania dotyczące łączności danych podane w tej sekcji.

7.4.1. Połączenia telefoniczne

Termin „telefonia” używany w interfejsach API Androida 2.3 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. Na potrzeby Androida 2.3 te połączenia głosowe mogą być przełączane pakietowo lub nie, ale są one uważane za niezależne od wszelkich połączeń danych, które mogą być stosowane w ramach tej samej sieci. Innymi słowy, funkcje i interfejsy API „telephony” w Androidzie odnoszą się konkretnie 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Ą zgłaszać funkcji „android.hardware.telephony” ani żadnych podfunkcji, niezależnie od tego, czy do przesyłania danych używają sieci komórkowej.

Android 2.3 MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Oznacza to, że Android 2.3 jest zgodny z urządzeniami, które nie są telefonami. Jeśli jednak implementacja urządzenia obejmuje telefonię GSM lub CDMA, MUSI wdrożyć pełną obsługę interfejsu API dla tej technologii. Implementacje na urządzeniach, które nie obejmują sprzętu telefonicznego, MUSZĄ implementować pełne interfejsy API jako no-ops.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementacje na urządzeniach z Androidem 2.3 powinny obsługiwać co najmniej jedną z form 802.11 (b/g/a/n itp.). Jeśli implementacja urządzenia obejmuje obsługę 802.11, MUSI implementować odpowiedni interfejs API Androida.

7.4.3. Bluetooth

Implementacje urządzeń powinny zawierać nadajnik Bluetooth. Implementacje urządzeń, które zawierają nadajnik Bluetooth, MUSZĄ włączyć interfejs Bluetooth API oparty na RFCOMM zgodnie z opisem w dokumentacji pakietu SDK [Resources, 32]. Implementacje urządzeń powinny wdrażać odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX itp., w sposób odpowiedni dla danego urządzenia.

Pakiet Compatibility Test Suite zawiera przypadki obejmujące podstawową obsługę interfejsu Bluetooth RFCOMM 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 wykonywanych na jednym urządzeniu. W związku z tym implementacje urządzeń MUSZĄ przejść procedurę testowania Bluetooth z udziałem człowieka opisaną w Załączniku A.

7.4.4. Komunikacja Near Field Communication

Urządzenia powinny zawierać transceiver i powiązany sprzęt do komunikacji Near Field Communication (NFC). Jeśli implementacja urządzenia obejmuje sprzęt NFC, to:

• Musisz zgłosić funkcję android.hardware.nfc z metody android.content.pm.PackageManager.hasSystemFeature(). [Zasoby, 27]
• MUSI być w stanie odczytywać i zapisywać komunikaty NDEF za pomocą tych standardów NFC:
  • MUSI być w stanie działać jako czytnik/nagrywarka NFC Forum (zgodnie ze specyfikacją techniczną NFC Forum NFCForum-TS-DigitalProtocol-1.0) za pomocą następujących standardów NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • NfcV (ISO 15693)
    • IsoDep (ISO 14443-4)
    • Typy tagów NFC Forum 1, 2, 3 i 4 (zdefiniowane przez NFC Forum)
  • MUSI umożliwiać przesyłanie i odbieranie danych za pomocą tych standardów i protokołów peer-to-peer:
    • ISO 18092
    • LLCP 1.0 (zdefiniowana przez NFC Forum)
    • SDP 1.0 (zdefiniowana przez NFC Forum)
    • Protokół NDEF Push [Resources, 33]
  • W trybie wykrywania NFC MUSI skanować wszystkie obsługiwane technologie.
  • NALEŻY ustawić tryb wykrywania NFC, gdy urządzenie jest aktywne i ma włączony ekran.

  (pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku wymienionych powyżej specyfikacji JIS, ISO i forum NFC).

  Dodatkowo implementacje urządzeń powinny obsługiwać te powszechnie stosowane technologie MIFARE:

  • MIFARE Classic (NXP MF1S503x [Resources, 34], MF1S703x [Resources, 35])
  • MIFARE Ultralight (NXP MF0ICU1 [Resources, 36], MF0ICU2 [Resources, 37])
  • NDEF na MIFARE Classic (NXP AN130511 [Resources, 38], AN130411 [Resources, 39])

  Pamiętaj, że Android 2.3.3 zawiera interfejsy API dla tych typów MIFARE. Jeśli implementacja urządzenia obsługuje MIFARE:

  • Musisz zaimplementować odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
  • NALEŻY zgłaszać funkcję com.nxp.mifare z metody android.content.pm.PackageManager.hasSystemFeature(). [Zasoby, 27] Pamiętaj, że nie jest to standardowa funkcja Androida i nie pojawia się jako stała w klasie PackageManager.
  • NIE MOŻE implementować odpowiednich interfejsów API Androida ani zgłaszać funkcji com.nxp.mifare, chyba że implementuje też ogólną obsługę NFC zgodnie z opisem w tej sekcji

  Jeśli implementacja urządzenia nie obejmuje sprzętu NFC, NIE MOŻE ona deklarować funkcji android.hardware.nfc z metody android.content.pm.PackageManager.hasSystemFeature() [Resources, 27] i MUSI zaimplementować interfejs NFC API w Androidzie 2.3 jako no-op.

  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 obejmują one obsługi NFC ani nie deklarują funkcji android.hardware.nfc.

  7.4.5. Minimalna funkcjonalność sieci

  Implementacje urządzeń MUSZĄ obsługiwać co najmniej jedną formę sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o szybkości 200 kbps lub wyższej. Przykłady technologii spełniających ten wymóg to EDGE, HSPA, EV-DO, 802.11g, Ethernet itp.

  Implementacje urządzeń, w których podstawowym połączeniem do przesyłania danych jest standard sieci fizycznej (np. Ethernet), POWINNY obejmować obsługę co najmniej jednego popularnego standardu bezprzewodowego przesyłania danych, takiego jak 802.11 (Wi-Fi).

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

  7.5. Aparaty

  Implementacje urządzeń powinny zawierać tylny aparat, a MOGĄ zawierać aparat przedni. Tylny aparat znajduje się po przeciwnej stronie urządzenia niż wyświetlacz. Oznacza to, że rejestruje obrazy z dalszej strony urządzenia, tak jak tradycyjny aparat. Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz, czyli taka, która jest zwykle używana do robienia zdjęć użytkownikowi, na przykład podczas wideokonferencji i podobnych aplikacji.

  7.5.1. Tylny aparat

  Implementacje urządzeń powinny zawierać tylny aparat. Jeśli implementacja urządzenia obejmuje tylny aparat:

  • Rozdzielczość musi wynosić co najmniej 2 megapiksele
  • W sterowniku aparatu (niewidocznym dla oprogramowania aplikacji) powinien być zaimplementowany automatyczny autofokus sprzętowy lub automatyczny autofokus oprogramowania.
  • MOŻE mieć sprzęt z ostrzością stałą lub EDOF (rozszerzoną głębią ostrości).
  • MOŻE zawierać błysk. Jeśli aparat ma lampę błyskową, to lampa MUSI być WYŁĄCZONA, gdy instancja android.hardware.Camera.PreviewCallback została zarejestrowana na powierzchni podglądu aparatu, chyba że aplikacja wyraźnie włączyła lampę błyskową, włączając atrybuty FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu, ale tylko aplikacji innych firm, które korzystają z Camera.PreviewCallback.

  7.5.2. Przedni aparat

  Implementacje urządzeń MOGĄ zawierać przedni aparat. Jeśli implementacja urządzenia obejmuje przedni aparat:

  • Rozdzielczość musi wynosić co najmniej VGA (czyli 640 x 480 pikseli).
  • Domyślnie w interfejsie Camera API NIE MOŻNA używać przedniego aparatu. Oznacza to, że interfejs API aparatu w Androidzie 2.3 obsługuje w szczególny sposób przednie kamery, a implementacje urządzeń NIE MOGĄ skonfigurować interfejsu API tak, aby traktował przednią kamerę jako domyślną tylną kamerę, nawet jeśli jest to jedyna kamera na urządzeniu.
  • MOŻE zawierać funkcje (takie jak autofokus, lampa błyskowa itp.) dostępne dla tylnych aparatów zgodnie z opisem w sekcji 7.5.1.
  • Musisz odwrócić poziomo (czyli lustro) strumień wyświetlany przez aplikację w CameraPreview, jak pokazano poniżej:
  • 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), podgląd aparatu MUSI być odwrócony poziomo względem bieżącej orientacji urządzenia.
  • Jeśli bieżąca aplikacja wyraźnie poprosiła o obrócenie wyświetlacza aparatu za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation() [Resources, 40], podgląd aparatu MUSI być odbiciem lustrzanym w orientacji określonej przez aplikację.
  • W przeciwnym razie podgląd MUSI być odzwierciedlony wzdłuż domyślnej osi poziomej urządzenia.
  • Dane obrazu zwracane do dowolnego wywołania zwrotnego obsługi zdarzeń „postview” w kamerze MUSZĄ być lustrzanym odbiciem danych w taki sam sposób jak strumień obrazu z podglądu kamery. (Jeśli implementacja na urządzeniu nie obsługuje wywołań zwrotnych po wyświetleniu, ten wymóg oczywiście nie obowiązuje).
  • Nie wolno odzwierciedlać końcowego obrazu nieruchomego ani strumieni wideo z powrotem do aplikacji lub do magazynu multimediów.

  7.5.3. Zachowanie interfejsu Camera API

  Implementacje urządzeń MUSZĄ implementować te zachowania w przypadku interfejsów API związanych z kamerą, zarówno w przypadku aparatów przednich, jak i tylnych:

  1. Jeśli aplikacja nigdy nie wywołała metody android.hardware.Camera.Parameters.setPreviewFormat(int), urządzenie MUSI używać android.hardware.PixelFormat.YCbCr_420_SP do danych podglądu przekazywanych do wywołań zwrotnych aplikacji.
  2. Jeśli aplikacja rejestruje instancję android.hardware.Camera.PreviewCallback i system wywołuje metodę onPreviewFrame(), gdy format podglądu to YCbCr_420_SP, dane w byte[] przekazane do onPreviewFrame() muszą być w dalszym ciągu w formacie kodowania NV21. Oznacza to, że NV21 MUSI być ustawiony jako domyślny.
  3. Implementacje urządzeń powinny obsługiwać format YV12 (oznaczony za pomocą stałej android.graphics.ImageFormat.YV12) w przypadku podglądów aparatu zarówno przedniego, jak i tylnego. Pamiętaj, że w przyszłej wersji definicji zgodności ten wymóg zostanie zmieniony na „MUST”. Oznacza to, że w Androidzie 2.3 obsługa YV12 jest opcjonalna, ale będzie wymagana w przyszłej wersji. Istniejące i nowe urządzenia z Androidem 2.3 bardzo zalecamy, aby spełniały ten wymóg w Androidzie 2.3. W przeciwnym razie nie będą kompatybilne z Androidem po uaktualnieniu do przyszłej wersji.

  Implementacje urządzeń MUSZĄ implementować pełny interfejs Camera API zawarty w dokumentacji pakietu SDK Androida 2.3 [Zasoby, 41]), niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład aparaty bez autofokusa MUSZĄ wywoływać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback (chociaż nie ma to zastosowania do aparatów bez autofokusa). Pamiętaj, że dotyczy to również przednich aparatów. Chociaż większość przednich aparatów nie obsługuje autofokusa, wywołania interfejsu API muszą być „udawane” w sposób opisany powyżej.

  Implementacje urządzeń MUSZĄ rozpoznawać i szanować nazwy parametrów zdefiniowane jako stałe w klasie android.hardware.Camera.Parameters, jeśli sprzęt bazowy obsługuje tę funkcję. Jeśli sprzęt urządzenia nie obsługuje danej funkcji, interfejs API musi działać zgodnie z opisem. Z drugiej strony implementacje na urządzeniu NIE MOGĄ obsługiwać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters(), które nie są opisane jako stałe w android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń 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.

  7.5.4. Orientacja aparatu

  Przedni i tylny aparat (jeśli są dostępne) MUSZĄ być ustawione tak, aby dłuższy wymiar aparatu był zgodny z dłuższym wymiarem ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparat MUSI rejestrować obrazy w orientacji poziomej. Dotyczy to niezależnie od naturalnej orientacji urządzenia, czyli zarówno urządzeń z główną orientacją poziomą, jak i z główną orientacją pionową.

  7.6. Pamięć i miejsce na dane

  Podstawową funkcją Androida 2.3 jest uruchamianie aplikacji. Implementacje na urządzeniach muszą spełniać wymagania podane w tej sekcji, aby zapewnić odpowiednią ilość pamięci i pamięci masowej na potrzeby prawidłowego działania aplikacji.

  7.6.1. Minimalna ilość pamięci i miejsca na dane

  Implementacje urządzeń MUSZĄ mieć co najmniej 128 MB pamięci dostępnej dla jądra i przestrzeni użytkownika. 128 MB MUSI być dodatkiem do pamięci przeznaczonej na komponenty sprzętowe, takie jak radio, pamięć itp., które nie są kontrolowane przez jądro.

  Implementacje urządzeń MUSZĄ mieć co najmniej 150 MB pamięci nieulotnej dostępnej dla danych użytkownika. Oznacza to, że partycja /data MUSI mieć co najmniej 150 MB.

  Oprócz powyższych wymagań implementacje urządzeń powinny mieć co najmniej 1 GB pamięci nieulotnej dostępnej dla danych użytkownika. Pamiętaj, że w przyszłej wersji Androida ten wyższy wymóg stanie się minimalnym wymaganiem. Zalecamy, aby implementacje urządzeń spełniały te wymagania już teraz, ponieważ w przeciwnym razie mogą nie być zgodne z przyszłą wersją Androida.

  Interfejsy API Androida zawierają Menedżera pobierania, którego aplikacje mogą używać do pobierania plików danych. Implementacja menedżera pobierania MUSI umożliwiać pobieranie pojedynczych plików o rozmiarze co najmniej 55 MB. Implementacja menedżera pobierania powinna umożliwiać pobieranie plików o rozmiarze co najmniej 100 MB.

  7.6.2. Pamięć współdzielona aplikacji

  Implementacje urządzeń MUSZĄ oferować pamięć współdzieloną dla aplikacji. Udostępnione miejsce na dane musi mieć co najmniej 1 GB.

  Implementacje urządzeń MUSZĄ być skonfigurowane z zainstalowanym domyślnie, „w standardzie” miejscem na dane współdzielone. Jeśli współdzielone miejsce na dane nie jest zamontowane w ścieżce Linuxa /sdcard, urządzenie MUSI zawierać link symboliczny Linuxa z /sdcard do rzeczywistego punktu montowania.

  Implementacje urządzeń MUSZĄ egzekwować zgodnie z dokumentacją uprawnienia android.permission.WRITE_EXTERNAL_STORAGE do tego wspólnego magazynu. W przeciwnym razie udostępnione miejsce na dane MUSI być dostępne do zapisu dla każdej aplikacji, która uzyskała to uprawnienie.

  Implementacje urządzeń mogą zawierać sprzęt do obsługi wymiennych nośników danych, do których użytkownik ma dostęp, np. karty Secure Digital. Implementacje urządzeń mogą przydzielać pamięć wewnętrzną (nieusuwalna) jako pamięć współdzielona dla aplikacji.

  Niezależnie od formy używanej pamięci współdzielonej implementacje urządzeń MUSZĄ zapewniać jakiś mechanizm dostępu do zawartości pamięci współdzielonej z komputera hosta, np. pamięć masowa USB lub protokół Media Transfer Protocol.

  Aby zilustrować tę kwestię, podajemy 2 typowe przykłady. Jeśli implementacja urządzenia obejmuje gniazdo karty SD, aby spełnić wymagania dotyczące współdzielonej pamięci, w ramach urządzenia sprzedawanego użytkownikom MUSI być dołączona karta SD w formacie FAT o rozmiary co najmniej 1 GB, która MUSI być domyślnie zamontowana. Jeśli implementacja urządzenia używa wewnętrznego stałego miejsca na dane, aby spełnić ten wymóg, miejsce na dane MUSI mieć rozmiar co najmniej 1 GB i być zamontowane w /sdcard (lub /sdcard MUSI być symboliczną lokalizacją w stosunku do fizycznej lokalizacji, jeśli jest zamontowane gdzie indziej).

  W przypadku implementacji urządzeń, które obejmują wiele ścieżek do współdzielonej pamięci (np. zarówno gniazda kart SD, jak i współdzieloną pamięć wewnętrzną), NALEŻY zmodyfikować podstawowe aplikacje, takie jak skaner multimediów i ContentProvider, aby obsługiwały w przezroczysty sposób pliki umieszczone w obu lokalizacjach.

  7.7. USB

  Implementacje na urządzeniu:

  • MUSI implementować klienta USB, który można podłączyć do hosta USB za pomocą standardowego portu USB-A.
  • NALEŻY zaimplementować Android Debug Bridge przez USB (jak opisano w sekcji 7).
  • MUSI implementować specyfikację pamięci masowej USB, aby umożliwić hostowi połączonemu z urządzeniem dostęp do zawartości woluminu /sdcard.
  • NALEŻY użyć formatu micro USB po stronie urządzenia
  • MOŻE zawierać niestandardowy port po stronie urządzenia, ale w takim przypadku MUSI być dostarczany z kablowym złączem umożliwiającym podłączenie niestandardowego złącza do standardowego portu USB-A.

  8. Zgodność z kampaniami Performance Max

  Zgodne implementacje muszą nie tylko zapewniać prawidłowe działanie aplikacji na urządzeniu, ale też odpowiednią wydajność i ogólne dobre wrażenia użytkownika. Implementacje urządzeń MUSZĄ spełniać kluczowe wskaźniki wydajności urządzenia zgodnego z Androidem 2.3 określone w tabeli poniżej:

  Wskaźnik	Próg skuteczności	Komentarze
  Czas uruchamiania aplikacji	W wyznaczonym czasie powinny się uruchomić te aplikacje: Przeglądarka: mniej niż 1300 ms MMS/SMS: mniej niż 700 ms AlarmClock: mniej niż 650 ms	Czas uruchamiania jest mierzony jako łączny czas wczytywania domyślnej czynności aplikacji, w tym czas potrzebny na uruchomienie procesu Linuxa, wczytanie pakietu Androida do maszyny wirtualnej Dalvik i wywołanie onCreate.
  Równoczesne zgłoszenia	Gdy uruchomiono kilka aplikacji, ponowne uruchomienie już uruchomionej aplikacji musi zająć mniej czasu niż pierwotny czas uruchomienia.

  9. Zgodność modelu zabezpieczeń

  Implementacje na urządzeniu MUSZĄ stosować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji referencyjnej Bezpieczeństwo i uprawnienia w interfejsach API [Resources, 42] w dokumentacji dla deweloperów Androida. Implementacje urządzeń MUSZĄ obsługiwać instalację samodzielnie podpisanych aplikacji bez konieczności uzyskiwania dodatkowych uprawnień lub certyfikatów od stron trzecich lub organów. W szczególności urządzenia zgodne MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w następujących podrozdziałach.

  9.1. Uprawnienia

  Implementacje urządzeń MUSZĄ obsługiwać model uprawnień Androida zgodnie z opisem w dokumentacji dla deweloperów [Resources, 42]. W szczególności implementacje MUSZĄ stosować wszystkie uprawnienia zdefiniowane zgodnie z dokumentacją pakietu SDK. Żadnych uprawnień nie można pominąć, zmienić ani zignorować. Implementacje MOGĄ dodawać dodatkowe uprawnienia, o ile nowe ciągi znaków identyfikatora uprawnień nie znajdują się w przestrzeni nazw android.*.

  9.2. UID i izolacja procesów

  Implementacje urządzeń MUSZĄ obsługiwać model piaskownicy aplikacji Androida, w którym każda aplikacja działa jako unikalny identyfikator UID w stylu Unixa i w oddzielnym procesie. Implementacje urządzeń MUSZĄ obsługiwać uruchamianie wielu aplikacji jako tego samego identyfikatora użytkownika Linuksa, pod warunkiem że aplikacje są prawidłowo podpisane i skonstruowane zgodnie z opisem w dokumentacji Bezpieczeństwo i uprawnienia [Zasoby, 42].

  9.3. Uprawnienia do systemu plików

  Implementacje urządzeń MUSZĄ obsługiwać model uprawnień dostępu do plików w Androidzie zgodnie z opisem w dokumentacji poświęconej zabezpieczeniom i uprawnieniom [Zasoby, 42].

  9.4. Alternatywne środowiska wykonawcze

  Implementacje urządzeń mogą zawierać środowiska wykonawcze, które wykonują aplikacje za pomocą innego oprogramowania lub innej technologii niż maszyna wirtualna Dalvik czy kod natywny. Jednak takie alternatywne środowiska wykonawcze NIE mogą naruszać modelu zabezpieczeń Androida ani zabezpieczeń zainstalowanych aplikacji na Androida, jak opisano w tej sekcji.

  Alternatywny czas wykonywania MUSI być aplikacją na Androida i stosować się do standardowego modelu zabezpieczeń Androida, jak opisano w sekcji 9.

  Alternatywnym środowiskom uruchomieniowym NIE wolno przyznawać dostępu do zasobów chronionych przez uprawnienia, o które nie prosimy w pliku AndroidManifest.xml środowiska uruchomieniowego za pomocą mechanizmu <uses-permission>.

  Alternatywny czas działania NIE MOŻE zezwalać aplikacjom na korzystanie z funkcji chronionych przez uprawnienia Androida, które są ograniczone do aplikacji systemowych.

  Alternatywne środowisko uruchomieniowe MUSI być zgodne z modelem piaskownicy Androida. Więcej szczegółów:

  • Alternatywny czas wykonywania POWINIEN instalować aplikacje za pomocą menedżera pakietów w oddzielnych piaskownicach Androida (czyli z użyciem identyfikatorów użytkowników Linuksa itp.).
  • Alternatywny czas wykonywania MOŻE udostępniać jedną piaskownicę Androida wszystkim aplikacjom korzystającym z alternatywnego czasu wykonywania.
  • Alternatywne środowisko uruchomieniowe i zainstalowane aplikacje korzystające z alternatywnego środowiska uruchomieniowego NIE MOGĄ używać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida dotyczących udostępnionego identyfikatora użytkownika i certyfikatu podpisywania.
  • Alternatywny czas wykonywania NIE MOŻE uruchamiać, przyznawać ani uzyskiwać dostępu do piaskownicy odpowiadającej innym aplikacjom na Androida.

  Alternatywny czas wykonywania NIE MOŻE być uruchamiany z uprawnieniami superużytkownika (root) ani nie może przyznawać takich uprawnień innym aplikacjom ani nie może ich przyznawać innym aplikacjom.

  Pliki .apk alternatywnych środowisk uruchomieniowych MOGĄ być uwzględnione w pliku obrazu systemu implementacji urządzenia, ale MUSZĄ być podpisane za pomocą klucza innego niż klucz używany do podpisywania innych aplikacji dołączonych do 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 (np. Aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI poinformować użytkownika, że aplikacja będzie mieć dostęp do tego zasobu. Jeśli środowisko uruchomieniowe nie rejestruje w taki sposób możliwości aplikacji, MUSI ono podać wszystkie uprawnienia posiadane przez samo środowisko uruchomieniowe podczas instalowania dowolnej aplikacji korzystającej z tego środowiska.

  10. Testowanie zgodności oprogramowania

  Projekt Android Open-Source zawiera różne narzędzia do testowania, które umożliwiają weryfikację zgodności implementacji urządzeń. Implementacje urządzeń MUSZĄ przejść wszystkie testy opisane w tej sekcji.

  Pamiętaj jednak, że żaden pakiet testów oprogramowania nie jest w pełni kompleksowy. Dlatego zalecamy, aby implementujący urządzenia wprowadzili jak najmniej zmian w urządzeniu referencyjnym i preferowanym wdrożeniem Androida 2.3 dostępnym w ramach Projektu Android Open Source. Pozwoli to zminimalizować ryzyko wprowadzenia błędów, które powodują niezgodności i wymagają ponownego wykonania pracy oraz potencjalnych aktualizacji urządzenia.

  10.1. Compatibility Test Suite

  Implementacje urządzeń MUSZĄ przejść testy Compatibility Test Suite (CTS) [Resources, 2] dostępne w ramach Projektu Android Open Source, korzystając z oprogramowania dołączonego do urządzenia. Dodatkowo implementatorzy urządzeń powinni w jak największym stopniu korzystać z implementacji referencyjnej w drzewie kodu źródłowego Androida na licencji Open Source. Muszą też zapewnić zgodność w przypadku niejednoznaczności w CTS oraz w przypadku każdej ponownej implementacji części referencyjnego kodu źródłowego.

  Test CTS jest przeznaczony do uruchamiania na rzeczywistym urządzeniu. Podobnie jak inne oprogramowanie, CTS może zawierać błędy. Wersje CTS będą wydawane niezależnie od tej definicji zgodności, a w przypadku Androida 2.3 może być udostępnionych kilka wersji CTS. Implementacje urządzeń MUSZĄ przejść najnowszą wersję CTS, która jest dostępna w momencie ukończenia oprogramowania urządzenia.

  Musi przejść najnowszą wersję pakietu testów zgodności Androida (CTS) dostępnego w momencie zakończenia implementacji oprogramowania urządzenia. (CTS jest dostępny w ramach Projektu Android Open Source [Resources, 2]). Test CTS sprawdza wiele, ale nie wszystkie komponenty opisane w tym dokumencie.

  10.2. Weryfikator CTS

  Implementacje na urządzeniu MUSZĄ prawidłowo wykonywać wszystkie odpowiednie przypadki w CTS Verifier. Narzędzie CTS Verifier jest zawarte w pakiecie Compatibility Test Suite i ma być uruchamiane przez operatora w celu testowania funkcji, których nie można przetestować za pomocą automatycznego systemu, np. prawidłowego działania aparatu i czujników.

  Narzędzie CTS Verifier zawiera testy dla wielu rodzajów sprzętu, w tym dla niektórych opcjonalnych. Implementacje urządzeń MUSZĄ przejść wszystkie testy dotyczące posiadanego sprzętu. Jeśli na przykład urządzenie ma akcelerometr, MUSI prawidłowo wykonać test akcelerometru w CTS Verifier. Przypadki testowe funkcji oznaczonych w tym dokumencie jako opcjonalne MOGĄ zostać pominięte.

  Każde urządzenie i każda kompilacja MUSZĄ prawidłowo działać z narzędziem CTS Verifier, jak opisano powyżej. Ponieważ jednak wiele wersji jest bardzo podobnych, implementatorzy urządzeń nie muszą uruchamiać narzędzia CTS Verifier w przypadku wersji, które różnią się tylko nieznacznie. W szczególności implementacje urządzeń, które różnią się od implementacji, która przeszła test CTS Verifier, tylko zestawem obsługiwanych lokalizacji, marki itp., MOGĄ pominąć test CTS Verifier.

  10.3. Aplikacje referencyjne

  Implementatorzy urządzeń MUSZĄ przetestować zgodność implementacji za pomocą tych aplikacji open source:

  • Aplikacje „Aplikacje na Androida” [Zasoby, 43].
  • Replica Island (dostępna w Android Market; wymagana tylko w przypadku implementacji urządzeń obsługujących OpenGL ES 2.0)

  Aby implementacja została uznana za zgodną, każda z wymienionych wyżej aplikacji MUSI uruchamiać się prawidłowo i działać prawidłowo.

  11. Oprogramowanie z możliwością aktualizacji

  Implementacje urządzeń MUSZĄ zawierać mechanizm umożliwiający zastąpienie całego oprogramowania systemowego. Mechanizm nie musi wykonywać aktualizacji „na żywo”, co oznacza, że może być konieczne ponowne uruchomienie urządzenia.

  Można użyć dowolnej metody, o ile pozwala ona na zastąpienie całego fabrycznie zainstalowanego oprogramowania. Na przykład dowolna z tych metod spełnia to wymaganie:

  • Pobieranie bezprzewodowe (OTA) z aktualizacją offline po ponownym uruchomieniu
  • „Przywiązane” aktualizacje przez USB z komputera głównego
  • „Offline” aktualizacje przez ponowne uruchomienie i aktualizację z pliku na wymiennym dysku pamięci

  Używany mechanizm aktualizacji MUSI obsługiwać aktualizacje bez kasowania danych użytkownika. Pamiętaj, że oprogramowanie Androida na poziomie dostawcy zawiera mechanizm aktualizacji, który spełnia ten wymóg.

  Jeśli po wydaniu urządzenia zostanie w nim wykryty błąd, ale w rozsądnym okresie jego użytkowania, który został określony w konsultacji z zespołem ds. zgodności Androida, aby wpłynąć na zgodność aplikacji innych firm, implementator urządzenia MUSI naprawić błąd za pomocą dostępnej aktualizacji oprogramowania, którą można zastosować zgodnie z omówionym właśnie mechanizmem.

  12. Skontaktuj się z nami

  Aby uzyskać wyjaśnienia i przedstawić problemy, które Twoim zdaniem nie zostały omówione w dokumencie, skontaktuj się z jego autorami pod adresem compatibility@android.com.

  Załącznik A. Procedura testowania Bluetooth

  Pakiet Compatibility Test Suite zawiera przypadki obejmujące podstawową obsługę interfejsu Bluetooth RFCOMM 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 wykonywanych na jednym urządzeniu. W związku z tym implementacje urządzeń MUSZĄ przejść procedurę testowania Bluetooth obsługiwaną przez człowieka, opisaną poniżej.

  Procedura testowania opiera się na przykładowej aplikacji BluetoothChat zawartej w drzewie projektu Androida typu open source. Procedura wymaga użycia 2 urządzeń:

  • wdrożenie urządzenia docelowego z kompilacją oprogramowania do przetestowania.
  • osobna implementacja urządzenia, która jest już znana jako zgodna, oraz model z testowanej implementacji urządzenia, czyli „znana dobra” implementacja urządzenia.

  W procedurze testowania te urządzenia są nazywane odpowiednio „kandydatem” i „sprawdzonym”.

  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.

  Testowanie sterowania Bluetooth przez aplikacje

  1. Uruchom 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 tej funkcji.

  Testowanie parowania i komunikacji

  1. Uruchom aplikację Bluetooth Chat na obu urządzeniach.
  2. Upewnij się, że znane i sprawne urządzenie jest wykrywalne w BluetoothChat (za pomocą menu).
  3. Na urządzeniu docelowym wyszukaj urządzenia Bluetooth w BluetoothChat (za pomocą menu) i sparuj je z urządzeniem, które działa prawidłowo.
  4. Wyślij co najmniej 10 wiadomości z każdego urządzenia i sprawdź, czy drugie urządzenie je poprawnie odbiera.
  5. Zamknij aplikację BluetoothChat na obu urządzeniach, naciskając przycisk Strona główna.
  6. Odłącz każde urządzenie od drugiego, używając aplikacji Ustawienia.

  Testowanie parowania i komunikacji w odwrotnym kierunku

  1. Uruchom aplikację Bluetooth Chat na obu urządzeniach.
  2. Urządzenie docelowe musi być wykrywalne w BluetoothChat (za pomocą menu).
  3. Na urządzeniu, które działa prawidłowo, wyszukaj urządzenia Bluetooth w BluetoothChat (za pomocą menu) i sparuj z wybranym urządzeniem.
  4. Wyślij 10 wiadomości z każdego urządzenia i sprawdź, czy drugie urządzenie je odbiera prawidłowo.
  5. Zamknij aplikację Bluetooth Chat na obu urządzeniach, naciskając kilka razy 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 odbiera prawidłowo.

  Uwaga: w przypadku niektórych testów powyżej sekcja testu kończy się po kliknięciu przycisku Strona główna, a w innych – przycisku Wstecz. Te testy nie są zbędne ani opcjonalne: ich celem jest sprawdzenie, czy interfejs API Bluetooth i jego stos działają prawidłowo zarówno wtedy, gdy aktywności są wyraźnie zamykane (przez naciśnięcie przez użytkownika przycisku Wstecz, który wywołuje metodę finish()), jak i wówczas, gdy są niejawnie wysyłane do tła (przez naciśnięcie przez użytkownika przycisku Strona główna). Każda sekwencja testów MUSI być wykonywana zgodnie z opisem.