Definicja zgodności z Androidem 2.2

Prawa autorskie © 2010, Google Inc. Wszelkie prawa zastrzeżone.
kompatybilność@android.com

Spis treści

1. Wstęp

W dokumencie tym wyszczególniono wymagania, jakie muszą zostać spełnione, aby telefony komórkowe były kompatybilne z systemem Android 2.2.

Użycie zwrotów „musi”, „nie może”, „wymagane”, „należy”, „nie powinno”, „powinno”, „nie powinno”, „zalecane”, „może” i „opcjonalne” jest zgodne ze standardem IETF zdefiniowane w RFC2119 [ Zasoby, 1 ].

W niniejszym dokumencie „wykonawca urządzenia” lub „wykonawca” to osoba lub organizacja opracowująca rozwiązanie sprzętowe/programowe z systemem Android 2.2. „Implementacja urządzenia” lub „implementacja” to opracowane w ten sposób rozwiązanie sprzętowe/programowe.

Aby uznać za zgodne z systemem Android 2.2, implementacje urządzeń:

• MUSI spełniać wymagania przedstawione w niniejszej definicji zgodności, w tym wszelkie dokumenty włączone przez odniesienie.
• MUSI przejść najnowszą wersję pakietu testów zgodności Androida (CTS) dostępną w momencie zakończenia wdrażania oprogramowania urządzenia. (CTS jest dostępny w ramach projektu Android Open Source [ Zasoby, 2 ].) CTS testuje wiele, ale nie wszystkie, komponenty opisane w tym dokumencie.

Jeżeli ta definicja lub CTS jest cicha, niejednoznaczna lub niekompletna, odpowiedzialność za wdrożenie urządzenia ponosi odpowiedzialność za zapewnienie zgodności z istniejącymi implementacjami. Z tego powodu projekt Android Open Source [ Zasoby, 3 ] jest zarówno referencyjną, jak i preferowaną implementacją Androida. Zdecydowanie zachęca się osoby wdrażające urządzenia, aby opierały swoje implementacje na „starszym” kodzie źródłowym dostępnym w ramach projektu Android Open Source. Chociaż niektóre komponenty można hipotetycznie zastąpić alternatywnymi implementacjami, praktyka ta jest zdecydowanie odradzana, ponieważ zdanie testów CTS stanie się znacznie trudniejsze. Obowiązkiem wdrażającego jest zapewnienie pełnej zgodności behawioralnej ze standardową implementacją Androida, w tym i poza pakietem testów zgodności. Na koniec należy pamiętać, że niniejszy dokument wyraźnie zabrania niektórych zamian i modyfikacji komponentów.

2. Zasoby

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 API i dokumentacja: http://developer.android.com/reference/packages.html
5. Informacje o uprawnieniach systemu Android: http://developer.android.com/reference/android/Manifest.permission.html
6. Informacje o kompilacji android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. Ciągi dozwolonych wersji Androida 2.2: http://source.Android.com/docs/compatibility/2.2/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. Specyfikacja maszyny wirtualnej Dalvik: dostępna w kodzie źródłowym Androida, pod adresem dalvik/docs
11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
12. Powiadomienia: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
13. Zasoby aplikacji: http://code.google.com/android/reference/available-resources.html
14. Przewodnik po stylu ikon paska stanu: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. Menedżer wyszukiwania: http://developer.android.com/reference/android/app/SearchManager.html
16. Tosty: http://developer.android.com/reference/android/widget/Toast.html
17. Animowane tapety: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
18. Aplikacje na Androida: http://code.google.com/p/apps-for-android
19. Dokumentacja narzędzia referencyjnego (dla adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
20. Opis pliku apk na Androida: http://developer.android.com/guide/topics/fundamentals.html
21. Pliki manifestu: http://developer.Android.com/guide/topics/manifest/manifest-intro.html
22. Narzędzie do testowania Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
23. Lista funkcji sprzętowych Androida: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. Obsługa wielu ekranów: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
28. Przestrzeń współrzędnych czujnika: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. Informacje dotyczące zabezpieczeń i uprawnień systemu Android: http://developer.android.com/guide/topics/security/security.html
30. Interfejs API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z zestawu SDK systemu Android 2.2 i będzie funkcjonalnie identycznych z informacjami zawartymi w dokumentacji tego zestawu SDK. W każdym przypadku, gdy niniejsza Definicja Zgodności lub Zestaw Testów Zgodności nie zgadza się z dokumentacją SDK, dokumentacja SDK jest uważana za wiarygodną. Wszelkie szczegóły techniczne podane w odnośnikach zawartych powyżej są uznawane za część niniejszej Definicji Zgodności.

3. Oprogramowanie

Platforma Android zawiera zestaw zarządzanych interfejsów API, zestaw natywnych interfejsów API oraz zbiór tak zwanych „miękkich” interfejsów API, takich jak interfejsy API systemu Intent i interfejsy API aplikacji internetowych. W tej sekcji szczegółowo opisano twarde i miękkie interfejsy API, które są integralną częścią kompatybilności, a także pewne inne istotne zachowania techniczne i interfejsy użytkownika. Implementacje urządzeń MUSZĄ spełniać wszystkie wymagania zawarte w tej sekcji.

3.1. Zgodność zarządzanego interfejsu API

Zarządzane (oparte na Dalvik) środowisko wykonawcze jest głównym narzędziem dla aplikacji na Androida. Interfejs programowania aplikacji systemu Android (API) to zestaw interfejsów platformy Android udostępnianych aplikacjom działającym w zarządzanym środowisku maszyny wirtualnej. Implementacje urządzeń MUSZĄ zapewniać kompletne implementacje, w tym wszystkie udokumentowane zachowania, dowolnego udokumentowanego interfejsu API udostępnianego przez pakiet SDK systemu Android 2.2 [ Zasoby, 4 ].

Implementacje urządzeń NIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów API ani podpisów, odbiegać od udokumentowanego zachowania ani zawierać zakazu wykonywania operacji, z wyjątkiem przypadków wyraźnie dozwolonych w niniejszej definicji zgodności.

3.2. Zgodność z miękkim interfejsem API

Oprócz zarządzanych interfejsów API z sekcji 3.1, system Android zawiera także istotny „miękki” interfejs API przeznaczony wyłącznie do środowiska wykonawczego w postaci takich elementów, jak intencje, uprawnienia i podobne aspekty aplikacji systemu Android, których nie można wymusić w czasie kompilacji aplikacji. W tej sekcji szczegółowo opisano „miękkie” interfejsy API i zachowania systemu wymagane do zapewnienia zgodności z systemem Android 2.2. Implementacje urządzeń MUSZĄ spełniać wszystkie wymagania przedstawione w tej sekcji.

3.2.1. Uprawnienia

Osoby wdrażające urządzenia MUSZĄ obsługiwać i egzekwować wszystkie stałe uprawnień zgodnie z dokumentacją na stronie odniesienia do uprawnień [ Zasoby, 5 ]. Należy pamiętać, że w sekcji 10 wymieniono dodatkowe wymagania związane z modelem zabezpieczeń systemu Android.

3.2.2. Parametry kompilacji

Interfejsy API systemu Android zawierają wiele stałych w klasie android.os.Build [ Resources, 6 ], które mają opisywać bieżące urządzenie. Aby zapewnić spójne, znaczące wartości we wszystkich implementacjach urządzeń, poniższa tabela zawiera dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi MUSZĄ być zgodne implementacje urządzeń.

3.2.3. Zamierzona kompatybilność

Android używa Intencji, aby osiągnąć luźno powiązaną integrację między aplikacjami. W tej sekcji opisano wymagania związane ze wzorcami intencji, które MUSZĄ być honorowane przez implementacje urządzeń. Przez „honorowany” rozumie się, że osoba wdrażająca urządzenie MUSI udostępnić działanie lub usługę Androida, która określa pasujący filtr intencji oraz wiąże się i implementuje prawidłowe zachowanie dla każdego określonego wzorca intencji.

3.2.3.1. Podstawowe cele aplikacji

Projekt Android upstream definiuje szereg podstawowych aplikacji, takich jak dialer telefoniczny, kalendarz, książka kontaktów, odtwarzacz muzyki i tak dalej. Osoby wdrażające urządzenia MOGĄ zastąpić te aplikacje wersjami alternatywnymi.

Jednakże wszelkie takie alternatywne wersje MUSZĄ uwzględniać te same wzorce zamierzeń, które zapewnił wcześniejszy projekt. Na przykład, jeśli urządzenie zawiera alternatywny odtwarzacz muzyki, musi nadal przestrzegać wzorca intencji wydanego przez aplikacje innych firm w celu wybrania utworu.

Następujące aplikacje są uważane za podstawowe aplikacje systemu Android:

• Zegar biurkowy
• Przeglądarka
• Kalendarz
• Kalkulator
• Kamera
• Łączność
• E-mail
• Galeria
• Globalne wyszukiwanie
• Wyrzutnia
• LivePicker (tzn. aplikacja selektora Live Wallpaper; MOŻE zostać pominięta, jeśli urządzenie nie obsługuje Live Wallpapers, zgodnie z sekcją 3.8.5.)
• Wiadomości (inaczej „Mms”)
• Muzyka
• Telefon
• Ustawienia
• Rejestrator dźwięku

Podstawowe aplikacje systemu Android obejmują różne komponenty Aktywności lub Usługi, które są uważane za „publiczne”. Oznacza to, że atrybut „android:exported” może być nieobecny lub może mieć wartość „true”.

Dla każdej Aktywności lub Usługi zdefiniowanej w jednej z podstawowych aplikacji systemu Android, która nie jest oznaczona jako niepubliczna za pomocą atrybutu android:exported o wartości „false”, implementacje urządzenia MUSZĄ zawierać komponent tego samego typu implementujący ten sam filtr intencji wzorce jako podstawowa aplikacja systemu Android.

Innymi słowy, implementacja urządzenia MOŻE zastąpić podstawowe aplikacje systemu Android; jeśli jednak tak się stanie, implementacja urządzenia MUSI obsługiwać wszystkie wzorce intencji zdefiniowane przez każdą zastępowaną podstawową aplikację systemu Android.

3.2.3.2. Zastąpienie zamiaru

Ponieważ Android jest platformą rozszerzalną, osoby wdrażające urządzenia MUSZĄ pozwolić na zastąpienie każdego wzorca intencji, o którym mowa w sekcji 3.2.3.1, przez aplikacje innych firm. Domyślnie pozwala na to projekt open source Androida; osobom wdrażającym urządzenia NIE WOLNO przypisywać specjalnych uprawnień aplikacjom systemowym do korzystania z tych wzorców zamierzeń ani uniemożliwiać aplikacjom stron trzecich wiązania się z tymi wzorcami i przejmowania nad nimi kontroli. Zakaz ten obejmuje w szczególności, ale nie ogranicza się do wyłączenia interfejsu użytkownika „Chooser”, który pozwala użytkownikowi wybierać pomiędzy wieloma aplikacjami, z których wszystkie obsługują ten sam wzorzec zamiarów.

3.2.3.3. Przestrzenie nazw intencji

Osoby wdrażające urządzenia NIE MOGĄ dołączać żadnego komponentu Androida, który uwzględnia nowe wzorce intencji lub intencji rozgłaszania przy użyciu AKCJI, KATEGORII lub innego ciągu kluczy w przestrzeni nazw android.*. Osoby wdrażające urządzenia NIE MOGĄ dołączać żadnych komponentów Androida, które honorują jakiekolwiek nowe wzorce intencji lub intencji rozgłaszania przy użyciu AKCJI, KATEGORII lub innego ciągu klucza w obszarze pakietu należącym do innej organizacji. Osoby wdrażające urządzenia NIE MOGĄ zmieniać ani rozszerzać żadnych wzorców intencji używanych przez podstawowe aplikacje wymienione w sekcji 3.2.3.1.

Zakaz ten jest analogiczny do zakazu określonego dla klas języka Java w sekcji 3.6.

3.2.3.4. Zamierzenia transmisji

Aplikacje stron trzecich wykorzystują platformę do emitowania określonych intencji w celu powiadamiania ich o zmianach w środowisku sprzętu lub oprogramowania. Urządzenia kompatybilne z Androidem MUSZĄ nadawać publiczne intencje transmisji w odpowiedzi na odpowiednie zdarzenia systemowe. Intencje rozgłaszania są opisane w dokumentacji zestawu SDK.

3.3. Natywna kompatybilność API

Kod zarządzany działający w Dalvik może wywoływać kod natywny dostarczony w pliku .apk aplikacji jako plik ELF .so skompilowany dla odpowiedniej architektury sprzętowej urządzenia. Implementacje urządzeń MUSZĄ obejmować obsługę kodu działającego w środowisku zarządzanym w celu wywołania kodu natywnego przy użyciu standardowej semantyki Java Native Interface (JNI). Następujące interfejsy API MUSZĄ być dostępne dla kodu natywnego:

• libc (biblioteka C)
• libm (biblioteka matematyczna)
• Interfejs JNI
• libz (kompresja Zlib)
• liblog (logowanie na Androida)
• Minimalne wsparcie dla C++
• Obsługa OpenGL zgodnie z opisem poniżej

Implementacje urządzeń MUSZĄ obsługiwać OpenGL ES 1.0. Urządzenia pozbawione akceleracji sprzętowej MUSZĄ implementować OpenGL ES 1.0 przy użyciu programowego modułu renderującego. Implementacje urządzeń POWINNY implementować tyle OpenGL ES 1.1, ile obsługuje sprzęt urządzenia. Implementacje urządzeń POWINNY zapewniać implementację OpenGL ES 2.0, jeśli sprzęt jest w stanie zapewnić rozsądną wydajność w przypadku tych interfejsów API.

Biblioteki te MUSZĄ być kompatybilne ze źródłami (tj. kompatybilne z nagłówkami) i kompatybilne binarnie (dla danej architektury procesora) z wersjami dostarczonymi w Bionic przez projekt Android Open Source. Ponieważ implementacje Bionic nie są w pełni kompatybilne z innymi implementacjami, takimi jak biblioteka GNU C, osoby wdrażające urządzenia POWINNY używać implementacji Androida. Jeśli osoby wdrażające urządzenia korzystają z innej implementacji tych bibliotek, MUSZĄ zapewnić zgodność nagłówków, plików binarnych i zachowania.

Implementacje urządzeń MUSZĄ dokładnie raportować natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pośrednictwem interfejsu API android.os.Build.CPU_ABI . ABI MUSI być jednym z wpisów udokumentowanych w najnowszej wersji Androida NDK, w pliku docs/CPU-ARCH-ABIS.txt . Należy pamiętać, że dodatkowe wersje zestawu Android NDK mogą wprowadzać obsługę dodatkowych interfejsów ABI.

Zgodność kodu natywnego jest wyzwaniem. Z tego powodu należy powtórzyć, że BARDZO zachęca się twórców urządzeń do korzystania z wcześniejszych implementacji bibliotek wymienionych powyżej, aby zapewnić kompatybilność.

3.4. Zgodność sieciowa

Wielu programistów i aplikacji opiera się na zachowaniu klasy android.webkit.WebView [ Resources, 8 ] w swoich interfejsach użytkownika, dlatego implementacja WebView musi być kompatybilna ze wszystkimi implementacjami Androida. Podobnie pełna obsługa Internetu ma kluczowe znaczenie dla wygody użytkownika Androida. Implementacje urządzeń MUSZĄ zawierać wersję android.webkit.WebView zgodną z starszym oprogramowaniem Androida i MUSZĄ zawierać nowoczesną przeglądarkę obsługującą HTML5, jak opisano poniżej.

3.4.1. Zgodność z WebView

Implementacja Android Open Source wykorzystuje silnik renderujący WebKit do implementacji android.webkit.WebView . Ponieważ nie jest możliwe opracowanie kompleksowego zestawu testów dla systemu renderowania stron internetowych, osoby wdrażające urządzenia MUSZĄ używać określonej wersji źródłowej WebKit w implementacji WebView. Konkretnie:

• Implementacje urządzenia android.webkit.WebView MUSZĄ być oparte na kompilacji 533.1 WebKit z nadrzędnego drzewa Android Open Source dla systemu Android 2.2. Ta kompilacja zawiera określony zestaw poprawek funkcjonalności i zabezpieczeń dla WebView. Osoby wdrażające urządzenia MOGĄ uwzględniać dostosowania implementacji WebKit; jednakże żadne takie dostosowania NIE MOGĄ zmieniać zachowania WebView, w tym zachowania renderowania.
• Ciąg agenta użytkownika zgłaszany przez WebView MUSI mieć następujący 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 $(VERSION) MUSI być taka sama jak wartość android.os.Build.VERSION.RELEASE
  • Wartość ciągu $(LOCALE) POWINNA być zgodna z konwencjami ISO dotyczącymi kodu kraju i języka oraz POWINNA odnosić się do aktualnie skonfigurowanych ustawień regionalnych urządzenia
  • Wartość ciągu $(MODEL) MUSI być taka sama jak wartość android.os.Build.MODEL
  • Wartość ciągu $(BUILD) MUSI być taka sama jak wartość android.os.Build.ID

Konfiguracja WebView MUSI obejmować obsługę bazy danych HTML5, pamięci podręcznej aplikacji i interfejsów API geolokalizacji [ Zasoby, 9 ]. Widok sieciowy MUSI obsługiwać tag HTML5 <video> . Interfejsy API HTML5, podobnie jak wszystkie interfejsy API JavaScript, MUSZĄ być domyślnie wyłączone w widoku WebView, chyba że programista wyraźnie włączy je za pośrednictwem zwykłych interfejsów API systemu Android.

3.4.2. Zgodność przeglądarki

Implementacje urządzeń MUSZĄ obejmować samodzielną aplikację przeglądarki do przeglądania stron internetowych przez zwykłego użytkownika. Samodzielna przeglądarka MOŻE być oparta na technologii przeglądarki innej niż WebKit. Jednak nawet jeśli dostarczona jest alternatywna aplikacja przeglądarki, komponent android.webkit.WebView dostarczany aplikacjom innych firm MUSI być oparty na WebKit, jak opisano w Sekcji 3.4.1.

Implementacje MOGĄ dostarczać niestandardowy ciąg agenta użytkownika w samodzielnej aplikacji przeglądarki.

Samodzielna aplikacja przeglądarki (niezależnie od tego, czy jest oparta na wcześniejszej aplikacji przeglądarki WebKit, czy na zamienniku innej firmy) POWINNA zapewniać obsługę możliwie największej ilości HTML5 [ Zasoby, 9 ]. W minimalnym stopniu implementacje urządzeń MUSZĄ obsługiwać geolokalizację HTML5, pamięć podręczną aplikacji i interfejsy API baz danych oraz tag <video> w samodzielnej aplikacji przeglądarki.

3.5. Zgodność behawioralna API

Zachowanie każdego z typów API (zarządzanego, miękkiego, natywnego i internetowego) musi być spójne z preferowaną implementacją projektu open source dla Androida [ Zasoby, 3 ]. Niektóre konkretne obszary zgodności to:

• Urządzenia NIE MOGĄ zmieniać zachowania ani znaczenia standardowej Intencji
• Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (takiego jak usługa, działanie, dostawca treści itp.).
• Urządzenia NIE MOGĄ zmieniać semantyki konkretnego uprawnienia

Powyższa lista nie jest wyczerpująca, a obowiązek zapewnienia zgodności behawioralnej spoczywa na wdrażających urządzenia. Z tego powodu osoby wdrażające urządzenia POWINNY używać kodu źródłowego dostępnego w ramach projektu Android Open Source, tam gdzie to możliwe, zamiast ponownie wdrażać znaczące części systemu.

Zestaw testów zgodności (CTS) testuje znaczną część platformy pod kątem zgodności behawioralnej, ale nie wszystkie. Obowiązkiem realizatora jest zapewnienie zgodności behawioralnej z projektem Android Open Source.

3.6. Przestrzenie nazw API

Android przestrzega konwencji przestrzeni nazw pakietów i klas zdefiniowanych przez język programowania Java. Aby zapewnić kompatybilność z aplikacjami innych firm, twórcom urządzeń NIE WOLNO wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w tych przestrzeniach nazw pakietów:

• Jawa.*
• javax.*
• słońce.*
• android.*
• com.android.*

Zabronione modyfikacje obejmują:

• Implementacje urządzeń NIE WOLNO modyfikować publicznie udostępnionych interfejsów API na platformie Android poprzez zmianę jakichkolwiek podpisów metod lub klas albo poprzez usuwanie klas lub pól klas.
• Osoby wdrażające urządzenia MOGĄ modyfikować podstawową implementację interfejsów API, ale takie modyfikacje NIE MOGĄ wpływać na określone zachowanie i podpis w języku Java jakichkolwiek publicznie udostępnianych interfejsów API.
• Implementatorom urządzeń NIE WOLNO dodawać żadnych publicznie dostępnych elementów (takich jak klasy lub interfejsy albo pola lub metody do istniejących klas lub interfejsów) do powyższych interfejsów API.

„Element publicznie eksponowany” to dowolny konstrukt, który nie jest ozdobiony znacznikiem „@hide” w kodzie źródłowym Androida. Innymi słowy, twórcom urządzeń NIE WOLNO ujawniać nowych interfejsów API ani zmieniać istniejących interfejsów API w przestrzeniach nazw wymienionych powyżej. Osoby wdrażające urządzenia MOGĄ wprowadzać modyfikacje wyłącznie do użytku wewnętrznego, ale modyfikacje te NIE MOGĄ być reklamowane ani w żaden inny sposób udostępniane programistom.

Osoby wdrażające urządzenia MOGĄ dodawać niestandardowe interfejsy API, ale żadne takie interfejsy API NIE MOGĄ znajdować się w przestrzeni nazw będącej własnością innej organizacji lub odnoszącej się do innej organizacji. Na przykład twórcom urządzeń NIE WOLNO dodawać interfejsów API do com.google.* lub podobnej przestrzeni nazw; może to zrobić tylko Google. Podobnie Google NIE WOLNO dodawać interfejsów API do przestrzeni nazw innych firm.

Jeśli osoba wdrażająca urządzenie zaproponuje ulepszenie jednej z powyższych przestrzeni nazw pakietów (na przykład poprzez dodanie przydatnej nowej funkcjonalności do istniejącego interfejsu API lub dodanie nowego interfejsu API), osoba wdrażająca POWINNA odwiedzić stronę source.android.com i rozpocząć proces wprowadzania zmian i zgodnie z informacjami zawartymi na tej stronie.

Należy pamiętać, że powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java; ta sekcja ma po prostu na celu wzmocnienie tych konwencji i uczynienie ich wiążącymi poprzez włączenie ich do niniejszej definicji zgodności.

3.7. Zgodność z maszyną wirtualną

Implementacje urządzeń MUSZĄ obsługiwać pełną specyfikację kodu bajtowego Dalvik Executable (DEX) i semantykę maszyny wirtualnej Dalvik [ Zasoby, 10 ].

Implementacje urządzeń z ekranami sklasyfikowanymi jako średniej lub niskiej gęstości MUSZĄ skonfigurować Dalvik tak, aby przydzielał co najmniej 16 MB pamięci dla każdej aplikacji. Implementacje urządzeń z ekranami sklasyfikowanymi jako o dużej gęstości MUSZĄ skonfigurować Dalvik tak, aby przydzielał co najmniej 24 MB pamięci dla każdej aplikacji. Należy pamiętać, że implementacje urządzeń MOGĄ przydzielać więcej pamięci niż podane liczby.

3.8. Zgodność interfejsu użytkownika

Platforma Android zawiera pewne interfejsy API dla programistów, które umożliwiają programistom podłączenie się do interfejsu użytkownika systemu. Implementacje urządzeń MUSZĄ uwzględniać te standardowe interfejsy API interfejsu użytkownika w niestandardowych interfejsach użytkownika, które opracowują, jak wyjaśniono poniżej.

3.8.1. Widżety

Android definiuje typ komponentu oraz odpowiedni interfejs API i cykl życia, który umożliwia aplikacjom udostępnianie „AppWidget” użytkownikowi końcowemu [ Zasoby, 11 ]. Wersja referencyjna Android Open Source zawiera aplikację Launcher zawierającą elementy interfejsu użytkownika umożliwiające użytkownikowi dodawanie, przeglądanie i usuwanie AppWidgets z ekranu głównego.

Osoby wdrażające urządzenia MOGĄ zastąpić alternatywę dla referencyjnego programu uruchamiającego (tj. ekranu głównego). Alternatywne programy uruchamiające POWINNY zawierać wbudowaną obsługę AppWidgets i udostępniać elementy interfejsu użytkownika umożliwiające dodawanie, konfigurowanie, przeglądanie i usuwanie AppWidgets bezpośrednio w programie uruchamiającym. Alternatywne programy uruchamiające MOGĄ pomijać te elementy interfejsu użytkownika; jeśli jednak zostaną one pominięte, osoba wdrażająca urządzenie MUSI udostępnić oddzielną aplikację dostępną z poziomu programu uruchamiającego, która umożliwi użytkownikom dodawanie, konfigurowanie, przeglądanie i usuwanie AppWidgets.

3.8.2. Powiadomienia

Android zawiera interfejsy API, które umożliwiają programistom powiadamianie użytkowników o ważnych wydarzeniach [ Zasoby, 12 ]. Osoby wdrażające urządzenia MUSZĄ zapewnić obsługę każdej tak zdefiniowanej klasy powiadomień; w szczególności: dźwięki, wibracje, światło i pasek stanu.

Dodatkowo implementacja MUSI poprawnie renderować wszystkie zasoby (ikony, pliki dźwiękowe itp.) przewidziane w interfejsach API [ Zasoby, 13 ] lub w przewodniku po stylach ikon paska stanu [ Zasoby, 14 ]. Osoby wdrażające urządzenia MOGĄ zapewniać użytkownikowi alternatywne środowisko powiadomień niż zapewniane przez referencyjną implementację Android Open Source; jednakże takie alternatywne systemy powiadamiania MUSZĄ obsługiwać istniejące zasoby powiadamiania, jak powyżej.

3.8.3. Szukaj

Android zawiera interfejsy API [ Zasoby, 15 ], które umożliwiają programistom włączenie wyszukiwania do swoich aplikacji i udostępnienie danych aplikacji w globalnym wyszukiwaniu systemowym. Ogólnie rzecz biorąc, ta funkcjonalność składa się z jednego, ogólnosystemowego interfejsu użytkownika, który umożliwia użytkownikom wprowadzanie zapytań, wyświetla sugestie podczas wpisywania przez użytkownika i wyświetla wyniki. Interfejsy API systemu Android umożliwiają programistom ponowne wykorzystanie tego interfejsu do wyszukiwania w ich własnych aplikacjach oraz dostarczanie wyników do wspólnego interfejsu użytkownika wyszukiwania globalnego.

Implementacje urządzeń MUSZĄ obejmować pojedynczy, współdzielony, ogólnosystemowy interfejs użytkownika wyszukiwania, umożliwiający wyświetlanie sugestii w czasie rzeczywistym w odpowiedzi na dane wprowadzone przez użytkownika. Implementacje urządzeń MUSZĄ implementować interfejsy API, które umożliwiają programistom ponowne wykorzystanie tego interfejsu użytkownika w celu zapewnienia wyszukiwania we własnych aplikacjach. Implementacje urządzeń MUSZĄ implementować interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii do pola wyszukiwania, gdy jest ono uruchamiane w trybie wyszukiwania globalnego. Jeśli nie są zainstalowane żadne aplikacje innych firm korzystające z tej funkcjonalności, domyślnym zachowaniem POWINNO być wyświetlanie wyników i sugestii wyszukiwarki internetowej.

Implementacje urządzeń MOGĄ zawierać alternatywne interfejsy użytkownika wyszukiwania, ale POWINNY zawierać twardy lub miękki dedykowany przycisk wyszukiwania, którego można użyć w dowolnej chwili w dowolnej aplikacji w celu wywołania struktury wyszukiwania, z zachowaniem opisanym w dokumentacji API.

3.8.4. Tosty

Aplikacje mogą używać interfejsu API „Toast” (zdefiniowanego w [ Resources, 16 ]) do wyświetlania użytkownikowi końcowemu krótkich, niemodalnych ciągów znaków, które znikają po krótkim czasie. Implementacje urządzeń MUSZĄ wyświetlać toasty z aplikacji dla użytkowników końcowych w jakiś dobrze widoczny sposób.

3.8.5. Animowane tapety

Android definiuje typ komponentu oraz odpowiedni interfejs API i cykl życia, który pozwala aplikacjom udostępniać użytkownikowi końcowemu jedną lub więcej „animowanych tapet” [ Zasoby, 17 ]. Animowane tapety to animacje, wzory i podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które są wyświetlane jako tapeta za innymi aplikacjami.

Uważa się, że sprzęt umożliwia niezawodne uruchamianie animowanych tapet, jeśli umożliwia uruchamianie wszystkich animowanych tapet, bez ograniczeń funkcjonalności, z rozsądną liczbą klatek na sekundę i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują awarie, nieprawidłowe działanie tapet i/lub aplikacji, nadmierne zużycie energii procesora lub baterii albo działanie z niedopuszczalnie niską liczbą klatek na sekundę, uznaje się, że sprzęt nie jest w stanie uruchomić tapety na żywo. Na przykład niektóre animowane tapety mogą wykorzystywać kontekst Open GL 1.0 lub 2.0 do renderowania swojej zawartości. Animowana tapeta nie będzie działać niezawodnie na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ użycie animowanej tapety w kontekście OpenGL może powodować konflikt z innymi aplikacjami, które również korzystają z kontekstu OpenGL.

Implementacje urządzeń umożliwiających niezawodne uruchamianie animowanych tapet, jak opisano powyżej, POWINNY implementować animowane tapety. Implementacje urządzeń, w przypadku których stwierdzono, że nie działają niezawodnie animowane tapety, jak opisano powyżej, NIE MOGĄ implementować animowanych tapet.

4. Zgodność oprogramowania referencyjnego

Osoby wdrażające urządzenia MUSZĄ przetestować zgodność implementacji przy użyciu następujących aplikacji typu open source:

• Kalkulator (zawarty w SDK)
• Lądownik Księżycowy (zawarty w SDK)
• Aplikacje „Aplikacje dla Androida” [ Zasoby, 18 ].
• Wyspa replik (dostępna w Android Market; wymagana tylko w przypadku implementacji urządzeń obsługujących OpenGL ES 2.0)

Każda powyższa aplikacja MUSI zostać uruchomiona i działać poprawnie w trakcie implementacji, aby implementacja została uznana za zgodną.

Ponadto implementacje urządzeń MUSZĄ testować każdą pozycję menu (w tym wszystkie podmenu) każdej z tych aplikacji do testów dymu:

• ApiDemos (zawarte w SDK)
• Ręczne testy dymu (zawarte w CTS)

Każdy przypadek testowy w powyższych aplikacjach MUSI działać poprawnie na implementacji urządzenia.

5. Zgodność opakowań aplikacji

Implementacje urządzeń MUSZĄ instalować i uruchamiać pliki „.apk” systemu Android wygenerowane przez narzędzie „aapt” zawarte w oficjalnym zestawie SDK systemu Android [ Zasoby, 19 ].

Implementacje urządzeń NIE MOGĄ rozszerzać formatów .apk [ Resources, 20 ], Android Manifest [ Resources, 21 ] lub Dalvik bytecode [ Resources, 10 ] w sposób uniemożliwiający prawidłową instalację i działanie tych plików na innych kompatybilnych urządzeniach . Osoby wdrażające urządzenia POWINNY używać referencyjnej implementacji Dalvik i systemu zarządzania pakietami implementacji referencyjnej.

6. Kompatybilność multimediów

Implementacje urządzeń MUSZĄ w pełni implementować wszystkie multimedialne interfejsy API. Implementacje urządzeń MUSZĄ obejmować obsługę wszystkich kodeków multimedialnych opisanych poniżej i POWINNY spełniać opisane poniżej wytyczne dotyczące przetwarzania dźwięku.

6.1. Kodeki multimedialne

Implementacje urządzeń MUSZĄ obsługiwać następujące kodeki multimedialne. Wszystkie te kodeki są dostarczane jako implementacje oprogramowania w preferowanej implementacji Androida z projektu Android Open Source.

Należy pamiętać, że ani firma Google, ani organizacja Open Handset Alliance nie zapewniają, że te kodeki nie są obciążone patentami stron trzecich. Osobom zamierzającym używać tego kodu źródłowego w sprzęcie lub oprogramowaniu informuje się, że implementacje tego kodu, w tym w oprogramowaniu typu open source lub shareware, mogą wymagać licencji patentowych od odpowiednich posiadaczy patentów.

Należy pamiętać, że powyższa tabela nie zawiera szczegółowych wymagań dotyczących szybkości transmisji bitów dla większości kodeków wideo. Powodem tego jest to, że w praktyce obecny sprzęt urządzenia niekoniecznie obsługuje przepływności, które dokładnie odpowiadają wymaganym przepływnościom określonym przez odpowiednie standardy. Zamiast tego implementacje urządzeń POWINNY obsługiwać najwyższą przepływność bitową praktyczną na sprzęcie, aż do limitów określonych w specyfikacjach.

6.2. Nagrywanie dźwięku

Gdy aplikacja korzysta z interfejsu API android.media.AudioRecord do rozpoczęcia rejestrowania strumienia dźwięku, implementacje urządzeń powinny próbować i rejestrować dźwięk z każdym z tych zachowań:

• Przetwarzanie redukcji szumów, jeśli jest obecne, powinno być wyłączone.
• Automatyczna kontrola wzmocnienia, jeśli jest obecna, powinna być wyłączona.
• Urządzenie powinno wykazywać w przybliżeniu płaską amplitudę w porównaniu z charakterystyką częstotliwości; W szczególności ± 3 dB, od 100 Hz do 4000 Hz
• Wrażliwość na wejście audio powinna być ustawiona tak, aby źródło mocy dźwięku 90 dB (SPL) przy 1000 Hz daje RMS 5000 dla próbek 16-bitowych.
• Poziomy amplitudy PCM powinny liniowo śledzić zmiany wejściowe SPL w zakresie co najmniej 30 dB od -18 dB do +12 dB RE 90 dB SPL w mikrofonie.
• Całkowite zniekształcenie harmoniczne powinno być mniejsze niż 1% od 100 Hz do 4000 Hz przy poziomie wejściowym SPL 90 dB.

Uwaga: Chociaż przedstawione powyżej wymagania są określane jako „powinny” dla Androida 2.2, planowana jest definicja kompatybilności dla przyszłej wersji, aby zmienić je na „musi”. Oznacza to, że wymagania te są opcjonalne w Android 2.2, ale będą wymagane przez przyszłą wersję. Istniejące i nowe urządzenia, które prowadzą Android 2.2 Android, są bardzo zachęcane do spełnienia tych wymagań w Android 2.2 , lub nie będą w stanie uzyskać kompatybilności z Androidem po zaktualizowaniu do przyszłej wersji.

6.3. Opóźnienie dźwięku

Opóźnienie dźwięku jest szeroko definiowane jako przedział między tym, gdy aplikacja żąda odtwarzania lub rejestracji dźwięku, a gdy wdrożenie urządzenia faktycznie rozpoczyna operację. Wiele klas aplikacji opiera się na krótkich opóźnieniach, aby osiągnąć efekty w czasie rzeczywistym, takie jak efekty dźwiękowe lub komunikacja VoIP. Implementacje urządzeń powinny spełniać wszystkie wymagania opóźnienia dźwięku przedstawione w tej sekcji.

Do celów niniejszej sekcji:

• „Opóźnienie zimnego wyjścia” jest zdefiniowane jako interwał między tym, gdy aplikacja żąda odtwarzania dźwięku, a kiedy dźwięk zaczyna odtwarzać, gdy system audio był bezczynny i zasilany przed żądaniem
• „ciepłe opóźnienie wyjściowe” jest zdefiniowane jako przedział między tym, gdy aplikacja żąda odtwarzania dźwięku, a kiedy dźwięk zaczyna odtwarzać, gdy system audio został niedawno używany, ale obecnie jest bezczynny (to znaczy cichy)
• „Ciągłe opóźnienie wyjściowe” jest zdefiniowane jako interwał między tym, gdy aplikacja wydaje próbkę do odtwarzania, a gdy głośnik fizycznie odtwarza odpowiedni dźwięk, podczas gdy urządzenie odtwarza obecnie dźwięk
• „Opóźnienie zimnego wejścia” jest zdefiniowane jako przedział między tym, gdy aplikacja żąda nagrywania audio, a gdy pierwsza próbka jest dostarczana do aplikacji za pośrednictwem jej wywołania zwrotnego, gdy system audio i mikrofon były bezczynne i zasilane przed żądaniem
• „Ciągłe opóźnienie wejściowe” jest zdefiniowane jako, gdy nastąpi dźwięk otoczenia, a gdy próbka odpowiadająca temu dźwiękowi jest dostarczana do aplikacji nagrywania za pośrednictwem jego wywołania zwrotnego, podczas gdy urządzenie jest w trybie nagrywania

Korzystając z powyższych definicji, implementacje urządzeń powinny wykazywać każdą z tych właściwości:

• opóźnienie wyjściowe zimnego 100 milisekund lub mniej
• ciepłe opóźnienie wyjściowe 10 milisekund lub mniej
• ciągłe opóźnienie wyjściowe 45 milisekund lub mniej
• Opóźnienie zimnego wejścia 100 milisekund lub mniej
• ciągłe opóźnienie wejściowe 50 milisekund lub mniej

Uwaga: Chociaż przedstawione powyżej wymagania są określane jako „powinny” dla Androida 2.2, planowana jest definicja kompatybilności dla przyszłej wersji, aby zmienić je na „musi”. Oznacza to, że wymagania te są opcjonalne w Android 2.2, ale będą wymagane przez przyszłą wersję. Istniejące i nowe urządzenia, które prowadzą Android 2.2 Android, są bardzo zachęcane do spełnienia tych wymagań w Android 2.2 , lub nie będą w stanie uzyskać kompatybilności z Androidem po zaktualizowaniu do przyszłej wersji.

7. Kompatybilność narzędzi programisty

Implementacje urządzeń muszą obsługiwać narzędzia programistów Androida dostarczone w systemie Android SDK. W szczególności urządzenia kompatybilne z Androidem muszą być kompatybilne z:

• Android Debug Bridge (znany jako ADB) [ Resources, 19 ]
  Implementacje urządzeń muszą obsługiwać wszystkie funkcje adb , jak udokumentowano w systemie Android SDK. Demon adb po stronie urządzenia powinien być domyślnie nieaktywny, ale musi istnieć mechanizm dostępny dla użytkownika do włączenia mostu debugowego Androida.
• Dalvik Debug Monitor Service (znany jako DDMS) [ Resources, 19 ]
  Implementacje urządzeń muszą obsługiwać wszystkie funkcje ddms , jak udokumentowano w systemie Android SDK. Ponieważ ddms korzysta z adb , obsługa ddms powinna być domyślnie nieaktywna, ale musi być obsługiwana za każdym razem, gdy użytkownik aktywuje most debugowania Androida, jak wyżej.
• Monkey [ Resources, 22 ]
  Implementacje urządzeń muszą zawierać Framework Monkey i udostępnić je do korzystania z aplikacji.

8. Kompatybilność sprzętowa

Android ma na celu obsługę implementerów urządzeń tworzących innowacyjne czynniki i konfiguracje formularzy. Jednocześnie programiści Android oczekują pewnego sprzętu, czujników i interfejsów API na całym urządzeniu z Androidem. W tej sekcji wymieniono funkcje sprzętowe, które muszą obsługiwać wszystkie urządzenia kompatybilne z Androidem 2.2.

Jeśli urządzenie zawiera konkretny komponent sprzętowy, który ma odpowiedni interfejs API dla twórców stron trzecich, implementacja urządzenia musi zaimplementować ten interfejs API zgodnie z definicją w dokumentacji Android SDK. Jeśli interakcja API w SDK oddziałuje z komponentem sprzętowym, który jest opcjonalny, a implementacja urządzenia nie posiada tego komponentu:

• Definicje klas dla interfejsów API komponentu muszą być obecne
• Zachowania interfejsu API muszą być wdrażane jako brak-ops w jakiś rozsądny sposób
• Metody API muszą zwrócić wartości zerowe, w których dozwolone przez dokumentację SDK
• Metody API muszą zwrócić implementacje NO-OP klas, w których wartości zerowe nie są dozwolone przez dokumentację SDK

Typowym przykładem scenariusza, w którym obowiązują te wymagania, jest interfejs API telefonii: nawet na urządzeniach innych niż telefoniczne interfejsy API muszą być wdrażane jako rozsądne brak.

Implementacje urządzeń muszą dokładnie zgłaszać dokładne informacje o konfiguracji sprzętowej za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) na klasie android.content.pm.PackageManager . [ Zasoby, 23 ]

8.1. Wyświetlacz

Android 2.2 zawiera w niektórych okolicznościach obiekty, które wykonują pewne automatyczne operacje skalowania i transformacji, aby zapewnić, że aplikacje zewnętrzne działają dość dobrze w różnych konfiguracjach sprzętowych [ zasoby, 24 ]. Urządzenia muszą prawidłowo wdrożyć te zachowania, jak szczegółowo opisano w tej sekcji.

W przypadku Androida 2.2 są to najczęstsze konfiguracje wyświetlania:

Implementacje urządzeń odpowiadające jednej ze standardowych konfiguracji powyżej muszą być skonfigurowane do zgłaszania wskazanego rozmiaru ekranu aplikacji za pośrednictwem klasy android.content.res.Configuration [ Zasoby, 24 ].

Niektóre pakiety .APK mają manifesty, które nie identyfikują ich jako wspierające określony zakres gęstości. Podczas uruchamiania takich aplikacji obowiązują następujące ograniczenia:

• Implementacje urządzeń muszą interpretować zasoby w. APK, które nie mają kwalifikatora gęstości jako domyślnego „Medium” (znanego jako „MDPI” w dokumentacji SDK.)
• Podczas pracy na ekranie gęstości „niskiej” implementacje urządzeń muszą zmniejszyć środki/MDPI aktywów o współczynnik 0,75.
• Podczas działania na ekranie „wysokiej” gęstości implementacje urządzeń muszą skalować środkowe/MDPI aktywów o współczynnik 1,5.
• Implementacje urządzeń nie mogą skalować zasobów w zakresie gęstości i muszą skalować zasoby dokładnie tymi czynnikami między zakresami gęstości.

8.1.2. Niestandardowe konfiguracje wyświetlania

Konfiguracje wyświetlania, które nie pasują do jednej ze standardowych konfiguracji wymienionych w rozdziale 8.1.1, wymagają dodatkowego rozpatrzenia i pracy, aby być kompatybilne. Wdrażacze urządzeń muszą skontaktować się z zespołem zgodności z Androidem, jak opisano w sekcji 13, aby uzyskać klasyfikacje dla wiadra, gęstości i skalowania wielkości ekranu. Po dostarczeniu tych informacji implementacje urządzeń muszą je zaimplementować zgodnie z określonymi.

Należy pamiętać, że niektóre konfiguracje wyświetlania (takie jak bardzo duże lub bardzo małe ekrany i niektóre współczynniki kształtu) są zasadniczo niezgodne z Androidem 2.2; Dlatego wdrażacze urządzeń są zachęcani do skontaktowania się z zespołem zgodności z Androidem jak najwcześniej w procesie rozwoju.

8.1.3. Wskaźniki wyświetlania

Implementacje urządzeń muszą zgłaszać prawidłowe wartości dla wszystkich wskaźników wyświetlania zdefiniowanych w android.util.DisplayMetrics [ Resources, 26 ].

8.1.4. Zadeklarowana obsługa ekranu

Aplikacje mogą wskazywać, które rozmiary ekranu obsługują za pośrednictwem atrybutu <supports-screens> w pliku AndroidManifest.xml. Implementacje urządzeń muszą poprawnie honorować wsparcie aplikacji dla małych, średnich i dużych ekranów, jak opisano w dokumentacji Android SDK.

8.2. Klawiatura

Implementacje urządzeń:

• Musi zawierać obsługę frameworka zarządzania wejściowym (która pozwala twórcom stron trzecich tworzyć silniki zarządzania wejściową - tj. Klawiatura miękka), jak szczegółowo opisano na programie
• Musi zapewnić co najmniej jedną implementację klawiatury miękkiej (niezależnie od tego, czy obecna jest klawiatura twardej)
• Może obejmować dodatkowe implementacje klawiatury miękkiej
• Może obejmować klawiaturę sprzętową
• Nie może zawierać klawiatury sprzętowej, która nie pasuje do jednego z formatów określonych w android.content.res.Configuration.keyboard [ Resources, 25 ] (to znaczy Qwerty lub 12-klucza)

8.3. Nawigacja bez dotyku

Implementacje urządzeń:

• Może pominąć opcje nawigacji bez dotyku (to znaczy może pominąć trackball, d-pad lub koło)
• Musi zgłosić prawidłową wartość dla android.content.res.Configuration.navigation [ Resources, 25 ]

8.4. Orientacja ekranu

Kompatybilne urządzenia muszą obsługiwać dynamiczną orientację według zastosowań do orientacji ekranu portretowego lub krajobrazu. Oznacza to, że urządzenie musi szanować żądanie aplikacji dotyczące określonej orientacji ekranu. Implementacje urządzeń mogą wybrać orientację portretową lub krajobrazową jako domyślną.

Urządzenia muszą zgłosić prawidłową wartość bieżącej orientacji urządzenia, za każdym razem, gdy jest zapytany za pośrednictwem Android.Content.Res.Configuration.orientacja, Android.View.display.getorientation () lub inne interfejsy API.

8,5. Wejście na ekranie dotykowym

Implementacje urządzeń:

• Musi mieć ekran dotykowy
• Może mieć pojemnikowy lub oporowy ekran dotykowy
• Musi zgłosić wartość android.content.res.Configuration [ Zasoby, 25 ] odzwierciedlając odpowiadające typowi określonego ekranu dotykowego na urządzeniu
• Powinien obsługiwać w pełni niezależnie śledzone wskaźniki, jeśli ekran dotykowy obsługuje wiele wskazówek

8.6. USB

Implementacje urządzeń:

• Musi zaimplementować klienta USB, podłączony do hosta USB ze standardowym portem USB-A
• Musi wdrożyć most debugowania Androida przez USB (jak opisano w sekcji 7)
• Musi zaimplementować specyfikację pamięci masowej USB, aby umożliwić hosta podłączonego do urządzenia dostęp do zawartości woluminu /sdcard
• Powinien użyć współczynnika formularza mikro USB po stronie urządzenia
• Może obejmować niestandardowy port po stronie urządzenia, ale jeśli tak, to musi wysłać kabel zdolny do podłączenia niestandardowego pinout do standardowego portu USB-A
• Powinien zaimplementować obsługę specyfikacji masowej masy USB (aby można było uzyskać dostęp do usuwania lub stałego przechowywania na urządzeniu z komputera hosta)

8.7. Klawisze nawigacyjne

Funkcje domu, menu i tyłu są niezbędne dla paradygmatu nawigacji na Androida. Implementacje urządzeń muszą udostępniać te funkcje przez cały czas, niezależnie od stanu aplikacji. Funkcje te powinny być zaimplementowane za pomocą dedykowanych przycisków. Można je zaimplementować przy użyciu oprogramowania, gestów, panelu dotykowego itp., Ale jeśli tak, muszą być zawsze dostępne i nie są niejasne ani nie zakłócają dostępnego obszaru wyświetlania aplikacji.

Wdrażacze urządzeń powinni również dostarczyć dedykowany klucz wyszukiwania. Wdrażacze urządzeń mogą również dostarczać klucze wysyłania i końcowych dla połączeń telefonicznych.

8.8. Bezprzewodowe sieci danych

Implementacje urządzeń muszą obejmować obsługę szybkich sieci danych bezprzewodowych. W szczególności implementacje urządzeń muszą zawierać obsługę co najmniej jednego standardu danych bezprzewodowych zdolnych do 200 kbit/s lub większych. Przykłady technologii spełniających ten wymóg obejmują Edge, HSPA, EV-DO, 802.11g itp.

Jeśli implementacja urządzenia obejmuje szczególną metodę, dla której system Android SDK zawiera interfejs API (to znaczy WiFi, GSM lub CDMA), implementacja musi obsługiwać API.

Urządzenia mogą zaimplementować więcej niż jedną formę łączności danych bezprzewodowych. Urządzenia mogą wdrażać przewodową łączność danych (takich jak Ethernet), ale mimo to muszą zawierać co najmniej jedną formę łączności bezprzewodowej, jak wyżej.

8.9. Kamera

Implementacje urządzeń muszą obejmować aparat skierowany do tyłu. Dołączony aparat od skupiony na tylnej części:

• Musi mieć rozdzielczość co najmniej 2 megapikseli
• Powinien mieć sprzętowy automatyczny skupienie, albo oprogramowanie auto-skutków zaimplementowane w sterowniku aparatu (przezroczyste dla oprogramowania aplikacyjnego)
• Może mieć sprzęt stałego lub EDOF (rozszerzona głębokość pola)
• Może obejmować błysk. Jeśli aparat zawiera lampę błyskową, lampa lampowa nie może być oświetlona, ​​podczas 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 FLASH_MODE_AUTO lub FLASH_MODE_ON atrybutów z Obiekt Camera.Parameters . Należy pamiętać, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu systemowego, ale tylko do aplikacji stron trzecich za pomocą Camera.PreviewCallback .

Implementacje urządzeń muszą wdrożyć następujące zachowania dla interfejsów API związanych z kamerą:

1. Jeśli aplikacja nigdy nie nazywała android.hardware.camera.parameters.setpreviewformat (int), urządzenie musi używać Android.Hardware.Pixelformat.ycbcr_420_sp do podglądu danych dostarczanych do wywołań zwrotnych aplikacji.
2. Jeśli aplikacja rejestruje instancję android.hardware.camera.previewCallback, a system wywołuje metodę onPreviewFrame (), gdy format podglądu jest YCBCR_420_SP, dane w BYTE [] przekazane do OnPreViewFrame () muszą być w formacie NV21. (Jest to format używany natywnie przez rodzinę sprzętową 7K.) To znaczy, NV21 musi być domyślnie.

Implementacje urządzeń muszą zaimplementować pełny interfejs API aparatu zawarty w dokumentacji SDK z Androidem 2.2 [ Zasoby, 27 ]), niezależnie od tego, czy urządzenie zawiera sprzętowe autofokus lub inne możliwości. Na przykład kamery, które nie mają autofokusa, muszą nadal wywoływać zarejestrowany system android.hardware.Camera.AutoFocusCallback (mimo że nie ma to znaczenia dla kamery spoza Autofocus.)

Implementacje urządzeń muszą rozpoznać i honorować każdą nazwę parametru zdefiniowaną jako stała na klasie android.hardware.Camera.Parameters , jeśli podstawowy sprzęt obsługuje funkcję. Jeśli sprzęt urządzenia nie obsługuje funkcji, interfejs API musi zachowywać się zgodnie z udokumentowaniem. I odwrotnie, implementacje urządzeń nie mogą honorować ani rozpoznać stałych strun przekazanych na android.hardware.Camera.setParameters() inną niż te udokumentowane jako stałe na android.hardware.Camera.Parameters . Oznacza to, że implementacje urządzeń muszą obsługiwać wszystkie standardowe parametry aparatu, jeśli sprzęt na to pozwala, i nie mogą obsługiwać niestandardowych rodzajów parametrów aparatu.

Implementacje urządzeń mogą obejmować kamerę przednich. Jeśli jednak implementacja urządzenia zawiera przednią kamerę, interfejs API aparatu zaimplementowany na urządzeniu nie może domyślnie korzystać z kamery przedniej. Oznacza to, że interfejs API aparatu w Android 2.2 jest przeznaczony wyłącznie do kamer skierowanych do tyłu, a implementacje urządzeń nie mogą ponownie używać ani przeciążyć interfejsu API, aby działać na przedniej kamerze, jeśli jeden jest obecny. Należy pamiętać, że każde niestandardowe interfejsy API dodane przez implementatorów urządzeń do obsługi kamer przednich muszą przestrzegać sekcji 3.5 i 3.6; Na Camera.Parameters , jeśli dostarczona jest niestandardowa podklasa android.hardware.Camera Należy pamiętać, że włączenie przedniej kamery nie spełnia wymagania, aby urządzenia zawierały aparat skierowany do tyłu.

8.10. Akcelerometr

Implementacje urządzeń muszą zawierać 3-osiowy akcelerometr i muszą być w stanie dostarczać zdarzenia przy 50 Hz lub więcej. Układ współrzędnych stosowany przez akcelerometr musi być zgodny z układem współrzędnych czujników Androida, jak szczegółowo opisano w interfejsach API z Androidem (patrz [ Zasoby, 28 ]).

8.11. Kompas

Implementacje urządzeń muszą zawierać 3-osiowy kompas i muszą być w stanie dostarczyć zdarzenia 10 Hz lub więcej. Układ współrzędnych stosowany przez kompas musi być zgodny z układem współrzędnych czujników Androida, zgodnie z definicją API Androida (patrz [ Zasoby, 28 ]).

8.12. GPS

Implementacje urządzeń muszą zawierać odbiornik GPS i powinny zawierać jakąś formę techniki „wspomaganego GPS”, aby zminimalizować czas blokady GPS.

8.13. Telefonia

Android 2.2 może być używany na urządzeniach, które nie zawierają sprzętu telefonii. Oznacza to, że Android 2.2 jest kompatybilny z urządzeniami, które nie są telefonami. Jeśli jednak implementacja urządzenia obejmuje telefonię GSM lub CDMA, musi wdrożyć pełne wsparcie interfejsu API dla tej technologii. Implementacje urządzeń, które nie zawierają sprzętu telefonii, muszą zaimplementować pełne interfejsy API jako NO-OPS.

Patrz także sekcja 8.8, bezprzewodowe sieci danych.

8.14. Pamięć i przechowywanie

Implementacje urządzeń muszą mieć co najmniej 92 MB pamięci dostępnych dla jądra i przestrzeni użytkowników. 92 MB musi być oprócz dowolnej pamięci poświęconej komponentom sprzętowym, takim jak radio, pamięć itd. Nie jest pod kontrolą jądra.

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

Oprócz powyższych wymagań implementacje urządzeń powinny mieć co najmniej 128 MB pamięci dostępnych dla jądra i przestrzeni użytkowników, oprócz pamięci poświęconej komponentom sprzętowym, które nie są pod kontrolą jądra. Implementacje urządzeń powinny mieć co najmniej 1 GB nieulotnej pamięci dostępnej dla danych użytkownika. Należy pamiętać, że te wyższe wymagania mają stać się twarde minimum w przyszłej wersji Androida. Wdrożenia urządzeń są zdecydowanie zachęcane do spełnienia tych wymagań, w przeciwnym razie mogą nie kwalifikować się do kompatybilności dla przyszłej wersji Androida.

8.15. Udostępniona aplikacja pamięć

Implementacje urządzeń muszą oferować udostępnioną pamięć dla aplikacji. Udostępniona pamięć musi mieć co najmniej 2 GB.

Implementacje urządzeń należy domyślnie skonfigurować z udostępnioną pamięcią zamontowaną „poza pudełkiem”. Jeśli udostępniona pamięć nie jest zamontowana na ścieżce Linux /sdcard , wówczas urządzenie musi zawierać symboliczny link Linux z /sdcard do rzeczywistego punktu montażowego.

Implementacje urządzeń muszą egzekwować zgodnie z dokumentatem zgody na android.permission.WRITE_EXTERNAL_STORAGE w tej wspólnej pamięci. Udostępniona pamięć musi być zapisana przez każdą aplikację, która uzyskuje to pozwolenie.

Implementacje urządzeń mogą mieć sprzęt do dostępnego przez użytkownika pamięci wymiennej, takiej jak bezpieczna karta cyfrowa. Alternatywnie, implementacje urządzeń mogą przydzielić pamięć wewnętrzną (nie do remontu) jako udostępnioną pamięć dla aplikacji.

Niezależnie od formy używanej pamięci współdzielonej, pamięć udostępniona musi zaimplementować masę masy USB, jak opisano w sekcji 8.6. Jak wysyłano z pudełka, udostępniane przechowywanie musi być zamontowane za pomocą grubego systemu plików.

Ilustrujące jest rozważenie dwóch typowych przykładów. Jeśli implementacja urządzenia zawiera gniazdo karty SD w celu spełnienia wymogu pamięci współdzielonej, należy dołączyć do użytku lub większego w formacie tłuszczowej SD lub większej, należy dołączyć użytkownikom, i musi zostać zamontowana. Alternatywnie, jeśli implementacja urządzenia używa wewnętrznego stałego przechowywania, aby spełnić ten wymóg, to przechowywanie musi mieć 2 GB lub większy, sformatowany jako grubość i zamontowana na /sdcard (lub /sdcard musi być symbolicznym linkiem do fizycznej lokalizacji, jeśli tak jest zamontowany gdzie indziej.)

Implementacje urządzeń, które zawierają wiele wspólnych ścieżek pamięci (takie jak zarówno gniazdo karty SD, jak i współdzielona pamięć wewnętrzna) powinny modyfikować podstawowe aplikacje, takie jak skaner multimediów i ContentProvider, aby przejrzysty obsługuje pliki umieszczone w obu lokalizacjach.

8.16. Bluetooth

Implementacje urządzeń muszą obejmować transceiver Bluetooth. Implementacje urządzeń muszą włączyć interfejs Bluetooth oparty na RFCOMM, jak opisano w dokumentacji SDK [ Zasoby, 30 ]. Implementacje urządzeń powinny zaimplementować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX itp., W odpowiednich dla urządzenia.

Pakiet testów kompatybilności obejmuje przypadki obejmujące podstawowe działanie interfejsu API Bluetooth Android RFCOMM. Ponieważ jednak Bluetooth jest protokołem komunikacji między urządzeniami, nie można go w pełni przetestować testami jednostkowymi działającymi na jednym urządzeniu. W związku z tym implementacje urządzeń muszą również przejść procedurę testu Bluetooth opartego na człowieku opisanym w załączniku A.

9. Kompatybilność wydajności

Jednym z celów programu kompatybilności Androida jest umożliwienie konsumentom spójnego doświadczenia. Kompatybilne implementacje muszą zapewnić nie tylko, że aplikacje po prostu działają poprawnie na urządzeniu, ale także to, że robią to z rozsądną wydajnością i ogólną dobrą obsługą. Implementacje urządzeń muszą spełniać kluczowe wskaźniki wydajności urządzenia kompatybilnego z Androidem 2.2 zdefiniowanym w poniższej tabeli:

10. Kompatybilność modelu bezpieczeństwa

Implementacje urządzeń muszą zaimplementować model bezpieczeństwa zgodny z modelem bezpieczeństwa platformy Android, zgodnie z definicją w dokumencie referencyjnym bezpieczeństwa i uprawnień w API [ zasoby, 29 ] w dokumentacji programistów Androida. Implementacje urządzeń muszą obsługiwać instalację aplikacji z podpisem samodzielnie, nie wymagając dodatkowych uprawnień/certyfikatów od osób trzecich/organów. W szczególności kompatybilne urządzenia muszą obsługiwać mechanizmy bezpieczeństwa opisane w podsekcjach obserwujących.

10.1. Uprawnienia

Implementacje urządzeń muszą obsługiwać model uprawnień na Androida, zgodnie z definicją w dokumentacji programisty Androida [ Zasoby, 29 ]. W szczególności implementacje muszą egzekwować każde pozwolenie zdefiniowane zgodnie z opisem w dokumentacji SDK; Nie można pominąć, zmienić ani zignorować uprawnień. Implementacje mogą dodać dodatkowe uprawnienia, pod warunkiem, że nowe ciągi identyfikacyjne uprawnień nie znajdują się w Androidzie.* Przestrzeń nazw.

10.2. Izolacja UID i proces

Implementacje urządzeń muszą obsługiwać model piaskownicy aplikacji Android, w którym każda aplikacja działa jako unikalny UID w stylu UNIX i w osobnym procesie. Implementacje urządzeń muszą obsługiwać uruchamianie wielu aplikacji jako ten sam identyfikator użytkownika Linux, pod warunkiem, że aplikacje są odpowiednio podpisywane i konstruowane, zgodnie z definicją w odniesieniu do bezpieczeństwa i uprawnień [ Zasoby, 29 ].

10.3. Uprawnienia systemu plików

Implementacje urządzeń muszą obsługiwać model uprawnień do dostępu do plików Android, zgodnie z definicją w odniesieniu do bezpieczeństwa i uprawnień [ Zasoby, 29 ].

10.4. Alternatywne środowiska wykonania

Implementacje urządzeń mogą obejmować środowiska wykonawcze, które wykonują aplikacje przy użyciu innego oprogramowania lub technologii niż maszyna wirtualna Dalvik lub kod natywny. Jednak takie alternatywne środowiska wykonania nie mogą narażać modelu bezpieczeństwa Androida ani bezpieczeństwa zainstalowanych aplikacji na Androida, jak opisano w tej sekcji.

Alternatywne czasy wykonawcze muszą same być aplikacjami na Androida i przestrzegać standardowego modelu bezpieczeństwa Androida, jak opisano w innym miejscu w sekcji 10.

Alternatywne czasy rundy nie można przyznać dostępu do zasobów chronionych przez uprawnienia, które nie są wymagane w pliku AndroidManifest.xml w czasie wykonywania za pośrednictwem mechanizmu <uses-permission> .

Alternatywne czasy uruchamiania nie pozwalają na korzystanie z funkcji chronionych przez uprawnienia z Androida ograniczone do aplikacji systemowych.

Alternatywne czasy wykonawcze muszą przestrzegać modelu piaskownicy z Androidem. Konkretnie:

• Alternatywne czasy uruchomienia powinny instalować aplikacje za pośrednictwem PackageManager w oddzielne piaskownicy z Androidem (to znaczy identyfikator użytkowników Linux itp.)
• Alternatywne czasy wykonawcze mogą zapewnić pojedynczą piaskownicę z Androidem udostępnioną przez wszystkie aplikacje za pomocą alternatywnego środowiska wykonawczego.
• Alternatywne czasy uruchomienia i zainstalowane aplikacje za pomocą alternatywnego czasu wykonywania nie mogą ponownie używać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida współdzielonego identyfikatora użytkownika i certyfikatu podpisywania
• Alternatywne czasy rundy nie mogą się uruchomić, przyznać lub być przyznawany dostęp do piaskownicy odpowiadającej innym aplikacjom na Androida.

Alternatywne czasy rundy nie można uruchamiać, przyznać ani przyznać innym aplikacjom Wszelkie uprawnienia superuseru (root) lub jakiegokolwiek innego identyfikatora użytkownika.

Pliki .APK alternatywnych czasów działających mogą być zawarte w obrazie systemowym implementacji urządzenia, ale muszą być podpisane z kluczem różniącym od klucza używanego do podpisywania innych aplikacji zawartych w implementacji urządzenia.

Podczas instalowania aplikacji alternatywne czasy działań należy uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację. Oznacza to, że jeśli aplikacja musi skorzystać z zasobu urządzenia, dla którego istnieje odpowiednia zgoda na Androida (takiego jak aparat, GPS itp.), Alternatywny czas wykonywania musi poinformować użytkownika, że ​​aplikacja będzie w stanie uzyskać dostęp do tego zasobu . Jeśli środowisko wykonawcze nie rejestruje możliwości aplikacji w ten sposób, środowisko wykonawcze musi wymienić wszystkie uprawnienia posiadane przez sam czas wykonania podczas instalowania dowolnej aplikacji za pomocą tego czasu wykonania.

11. Suite testowe kompatybilności

Implementacje urządzeń muszą przekazać pakiet testu kompatybilności Androida (CTS) [ zasoby, 2 ] dostępne w projekcie open source z Androidem, korzystając z ostatecznego oprogramowania wysyłkowego na urządzeniu. Ponadto wdrażacze urządzeń powinni w jak największym stopniu korzystać z referencyjnej implementacji w drzewie open source z Androidem i muszą zapewnić zgodność w przypadkach dwuznaczności w CTS i wszelkich ponownych implementacjach części kodu źródłowego.

CTS jest zaprojektowany do uruchamiania na rzeczywistym urządzeniu. Jak każde oprogramowanie, same CT mogą zawierać błędy. CTS będą wersji niezależnie od tej definicji zgodności, a wiele wersji CTS może zostać wydanych dla Androida 2.2. Implementacje urządzeń muszą przekazać najnowszą wersję CTS dostępną w momencie zakończenia oprogramowania urządzenia.

12. Oprogramowanie do aktualizacji

Implementacje urządzeń muszą obejmować mechanizm zastąpienia całego oprogramowania systemowego. Mechanizm nie musi wykonywać aktualizacji „na żywo” - to znaczy może być wymagane ponowne uruchomienie urządzenia.

Można zastosować dowolną metodę, pod warunkiem, że może wymienić całe oprogramowanie wstępnie zainstalowane na urządzeniu. Na przykład każde z poniższych podejść spełni ten wymóg:

• Pobieranie Over-the-Air (OTA) z aktualizacją offline za pośrednictwem ponownego uruchomienia
• Aktualizacje „uwięzione” nad USB z komputera hosta
• Aktualizacje „offline” za pośrednictwem ponownego uruchomienia i aktualizacji z pliku na zdejmowanej pamięci

Używany mechanizm aktualizacji musi obsługiwać aktualizacje bez wycierania danych użytkownika. Należy pamiętać, że oprogramowanie z Androidem Upstream zawiera mechanizm aktualizacji, który spełnia ten wymóg.

Jeśli błąd zostanie znaleziony w implementacji urządzenia po jego wydaniu, ale w rozsądnym okresie życia produktu, który jest określony w porozumieniu z zespołem kompatybilności Androida, aby wpłynąć na kompatybilność aplikacji THID-partii Dostępna aktualizacja, którą można zastosować zgodnie z opisanym mechanizmem.

13. Skontaktuj się z nami

Możesz skontaktować się z autorów dokumentów pod adresem Compatibility@android.com w celu uzyskania wyjaśnień i podać wszelkie problemy, które Twoim zdaniem nie obejmuje dokumentu.

Dodatek A - Procedura testu Bluetooth

Pakiet testów kompatybilności obejmuje przypadki obejmujące podstawowe działanie interfejsu API Bluetooth Android RFCOMM. Ponieważ jednak Bluetooth jest protokołem komunikacji między urządzeniami, nie można go w pełni przetestować testami jednostkowymi działającymi na jednym urządzeniu. W związku z tym implementacje urządzeń muszą również przejść procedurę testu Bluetooth opartego na człowieku opisanym poniżej.

Procedura testowa oparta jest na aplikacji BluetoothChat zawartej w drzewie projektu open source Android. Procedura wymaga dwóch urządzeń:

• Wdrożenie urządzenia kandydującego uruchamianie kompilacji oprogramowania do przetestowania
• Oddzielna implementacja urządzenia, o której wiadomo, że jest kompatybilna i modelu z testowanej implementacji urządzenia - to znaczy „znana dobra” implementacja urządzenia

Poniższa procedura testowa odnosi się do tych urządzeń odpowiednio jako „kandydata” i „znanych dobrych”.

Konfiguracja i instalacja

1. Zbuduj BluetoothChat.APK za pośrednictwem „Make Próbki” z drzewa kodu źródłowego Androida.
2. Zainstaluj BluetoothChat.APK na znanym urządzeniu.
3. Zainstaluj BluetoothChat.APK na urządzeniu kandydującym.

Przetestuj kontrolę Bluetooth według aplikacji

1. Uruchom BluetoothChat na urządzeniu kandydującym, a Bluetooth jest wyłączony.
2. Sprawdź, czy urządzenie kandydujące albo włącza Bluetooth, albo montuje użytkownikowi oknem dialogowym, aby włączyć Bluetooth.

Parowanie testów i komunikacja

1. Uruchom aplikację Bluetooth Chat na obu urządzeniach.
2. Udaj znane dobro urządzenie do odkrycia z Bluetoothchat (za pomocą menu).
3. Na urządzeniu kandydującym skanuj urządzenia Bluetooth z wewnątrz Bluetoothchat (za pomocą menu) i połącz z znanym urządzeniem.
4. Wyślij 10 lub więcej wiadomości z każdego urządzenia i sprawdź, czy inne urządzenie odbiera je poprawnie.
5. Zamknij aplikację BluetoothChat na obu urządzeniach, naciskając do domu .
6. Rozprowadź każde urządzenie z drugiego, korzystając z aplikacji Ustawienia urządzenia.

Parowanie testów i komunikacja w odwrotnym kierunku

1. Uruchom aplikację Bluetooth Chat na obu urządzeniach.
2. Udostępnij urządzenie kandydujące z Bluetoothchat (za pomocą menu).
3. Na znanym dobrym urządzeniu skanuj urządzenia Bluetooth z wewnątrz Bluetoothchat (za pomocą menu) i połącz z urządzeniem kandydującym.
4. Wyślij 10 lub wiadomości z każdego urządzenia i sprawdź, czy inne urządzenie odbiera je poprawnie.
5. Zamknij aplikację Bluetooth Chat na obu urządzeniach, wielokrotnie naciskając, aby dostać się do programu Launcher.

Test ponownie się uruchamia

1. Ponownie uruchom aplikację czatu Bluetooth na obu urządzeniach.
2. Wyślij 10 lub wiadomości z każdego urządzenia i sprawdź, czy inne urządzenie odbiera je poprawnie.

Uwaga: Powyższe testy mają pewne przypadki, które kończą sekcję testową za pomocą domu, a niektóre z tyłu. Testy te nie są zbędne i nie są opcjonalne: celem jest sprawdzenie, czy interfejs API i stosu Bluetooth działają poprawnie zarówno, gdy działania są wyraźnie zakończone (przez użytkownika naciskające, które wywołują ()) i domyślnie wysyłane na tło (za pośrednictwem tła (za pośrednictwem tła (za pośrednictwem tła (za pośrednictwem tła (za pośrednictwem tła (za pośrednictwem tła (za pośrednictwem tła Użytkownik naciska na dom.) Każda sekwencja testowa musi być wykonana zgodnie z opisem.