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

Definicja zgodności z Androidem 1.6

Definicja zgodności z Androidem: Android 1.6
Androida 1.6 r2
Google Inc.
kompatybilność@android.com

1. Wstęp
W dokumencie tym wyszczególniono wymagania, jakie muszą spełniać telefony komórkowe
kompatybilny z Androidem 1.6. Definicja ta zakłada znajomość Programu zgodności z systemem Android
[Zasoby, 1].
Użycie zwrotów „musi”, „nie może”, „wymagane”, „powinien”, „nie powinien”, „powinien”, „nie powinien”, „zalecane”,
„może” i „opcjonalny” jest zgodny ze standardem IETF zdefiniowanym w RFC2119 [ Zasoby , 2].
W niniejszym dokumencie „wykonawca urządzenia” lub „wykonawca” to osoba lub organizacja opracowująca urządzenie
rozwiązanie sprzętowo-programowe z systemem Android 1.6. „Implementacja urządzenia” lub „implementacja” to
tak opracowanego rozwiązania sprzętowego/programowego.
Aby uznać za zgodne z systemem Android 1.6, implementacje urządzeń:
1. MUSI spełniać wymagania przedstawione w niniejszej definicji zgodności, w tym wszelkie dokumenty
włączone poprzez odniesienie.
2. MUSI przejść pakiet testów zgodności systemu Android (CTS) dostępny w ramach pakietu Android Open
Projekt źródłowy [ Zasoby , 3]. CTS testuje większość, ale nie wszystkie , komponenty opisane w tym dokumencie
dokument.
Jeżeli ta definicja lub CTS jest cicha, niejednoznaczna lub niekompletna, za odpowiedzialność odpowiada urządzenie
wdrażającego, aby zapewnić kompatybilność z istniejącymi wdrożeniami. Z tego powodu Android Open
Projekt źródłowy [ Zasoby , 4] jest zarówno referencyjną , jak i preferowaną implementacją Androida. Urządzenie
Zdecydowanie zachęca się osoby wdrażające, aby opierały swoje implementacje na kodzie źródłowym „poprzednim”.
dostępne w ramach projektu Android Open Source. Chociaż niektóre elementy można hipotetycznie wymienić
w przypadku alternatywnych wdrożeń praktyka ta jest zdecydowanie odradzana, ponieważ będzie to oznaczać zdanie testów CTS
znacznie trudniejsze. Obowiązkiem realizatora jest zapewnienie pełnej zgodności behawioralnej z
standardowa implementacja systemu Android, w tym i poza pakietem testów zgodności.
2. Zasoby
Niniejsza Definicja Zgodności odnosi się do szeregu zasobów, które można tutaj uzyskać.
1. Omówienie programu zgodności z Androidem: https://sites.google.com/a/android.com/compatibility/
jak to działa
2. Poziomy wymagań IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. Zestaw testów zgodności: http://sites.google.com/a/android.com/compatibility/compatibility-test-
apartament--cts
4. Projekt Android Open Source: http://source.android.com/
5. Definicje i dokumentacja API: http://developer.android.com/reference/packages.html
6. Dostawcy treści: http://code.google.com/android/reference/android/provider/package-
podsumowanie.html
7. Dostępne zasoby: http://code.google.com/android/reference/available-resources.html
8. Pliki manifestu Androida: http://code.google.com/android/devel/bblocks-manifest.html
9. Informacje dotyczące uprawnień Androida: http://developer.android.com/reference/android/
Manifest.permission.html
10. Kompiluj stałe: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. Rozszerzenia przeglądarki Gears: http://code.google.com/apis/gears/

13. Specyfikacja maszyny wirtualnej Dalvik, którą można znaleźć w katalogu dalvik/docs kodu źródłowego
wymeldować się; dostępne również pod adresem http://android.git.kernel.org/?p=platform/
dalvik.git;a=drzewo;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=GŁOWA
14. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. Powiadomienia: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. Przewodnik po stylu ikon paska stanu: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Menedżer wyszukiwania: http://developer.android.com/reference/android/app/SearchManager.html
18. Toast: http://developer.android.com/reference/android/widget/Toast.html
19. Aplikacje na Androida: http://code.google.com/p/apps-for-android
20. Opis pliku apk na Androida: http://developer.android.com/guide/topics/fundamentals.html
21. Most debugowania Androida (adb): http://code.google.com/android/reference/adb.html
22. Usługa monitorowania debugowania Dalvik (ddms): http://code.google.com/android/reference/ddms.html
23. Małpa: http://developer.android.com/guide/developing/tools/monkey.html
24. Dokumentacja dotycząca niezależności wyświetlacza:
25. Stałe konfiguracyjne: http://developer.android.com/reference/android/content/res/
Konfiguracja.html
26. Wyświetlanie wskaźników: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. Kamera: 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ń Androida: http://developer.android.com/guide/topics/security/
bezpieczeństwo.html
Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z zestawu SDK systemu Android 1.6 i tak będzie
funkcjonalnie identyczne z informacjami zawartymi w dokumentacji tego zestawu SDK. W każdym przypadku, gdy to
Definicja zgodności nie zgadza się z dokumentacją SDK, dokumentacja SDK jest brana pod uwagę
autorytatywny. Wszelkie szczegóły techniczne zawarte w odnośnikach zawartych powyżej są uwzględniane poprzez włączenie
być częścią niniejszej Definicji Zgodności.
3. Oprogramowanie
Platforma Android zawiera zarówno zestaw zarządzanych („twardych”) interfejsów API, jak i zbiór tak zwanych „miękkich” interfejsów API
takie jak system Intent, interfejsy API kodu natywnego i interfejsy API aplikacji internetowych. W tej sekcji szczegółowo opisano trudne i
miękkie interfejsy API, które są integralną częścią kompatybilności, a także pewne inne istotne interfejsy techniczne i użytkownika
zachowania. 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. The
Interfejs programowania aplikacji systemu Android (API) to zestaw interfejsów platformy Android, na które narażony jest system Android
aplikacje działające w zarządzanym środowisku VM. Implementacje urządzeń MUSZĄ zapewniać kompletność
implementacje, w tym wszystkie udokumentowane zachowania, wszelkich udokumentowanych interfejsów API udostępnianych przez system Android
1.6 SDK, takie jak:
1. Podstawowe interfejsy API w języku Java dla systemu Android [Zasoby, 5].
2. Dostawcy treści [Zasoby , 6].
3. Zasoby [Zasoby, 7].
4. Atrybuty i elementy AndroidManifest.xml [Zasoby, 8].

Implementacje urządzeń NIE MOGĄ pomijać zarządzanych interfejsów API, zmieniać interfejsów API lub podpisów ani odbiegać od nich
od udokumentowanego zachowania lub obejmować brak działań, z wyjątkiem przypadków wyraźnie dozwolonych w niniejszej Zgodności
Definicja.
3.2. Zgodność z miękkim interfejsem API
Oprócz zarządzanych interfejsów API z sekcji 3.1, system Android zawiera także znaczące „miękkie” oprogramowanie przeznaczone wyłącznie do środowiska wykonawczego
API w postaci takich rzeczy, jak intencje, uprawnienia i podobne aspekty aplikacji na Androida
których nie można wymusić w czasie kompilacji aplikacji. W tej sekcji szczegółowo opisano „miękkie” interfejsy API i system
zachowania wymagane dla zgodności z systemem Android 1.6. Implementacje urządzeń MUSZĄ spełniać wszystkie wymagania
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ą
Strona referencyjna uprawnień [ Zasoby , 9]. Należy pamiętać, że w sekcji 10 wymieniono dodatkowe wymagania związane z
model bezpieczeństwa Androida.
3.2.2. Parametry kompilacji
Interfejsy API systemu Android zawierają szereg stałych w klasie android.os.Build [Zasoby, 10] , które są
ma na celu opisanie bieżącego urządzenia. Aby zapewnić spójne, znaczące wartości na całym urządzeniu
implementacje, poniższa tabela zawiera dodatkowe ograniczenia dotyczące formatów tych wartości, do których
implementacje urządzeń MUSZĄ być zgodne.
Parametr
Uwagi
Wersja aktualnie działającego systemu Android, w języku ludzkim
android.os.Build.VERSION.RELEASE
czytelny format. W systemie Android 1.6 to pole MUSI zawierać wartość ciągu
„1,6”.
Wersja aktualnie działającego systemu Android, w formacie
android.os.Build.VERSION.SDK
dostępne dla kodu aplikacji stron trzecich. W systemie Android 1.6 to pole
MUSI mieć wartość całkowitą 4.
Wartość wybrana przez realizatora urządzenia wyznaczająca konkretną kompilację
aktualnie działającego systemu Android, w formacie czytelnym dla człowieka.
Tej wartości NIE WOLNO ponownie używać w przypadku różnych wersji dostarczonych do końca
użytkowników Android.os.Build.VERSION.INCREMENTAL. Typowym zastosowaniem tego pola jest wskazanie numeru kompilacji lub
Do wygenerowania kompilacji użyto identyfikatora zmiany kontroli źródła. Tam
nie ma wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego
NIE MOŻE mieć wartości null ani pustego ciągu („”).
Wartość wybrana przez realizatora urządzenia, identyfikująca konkretny element wewnętrzny
sprzęt używany przez urządzenie, w formacie czytelnym dla człowieka. Możliwe zastosowanie
android.os.Build.BOARD
tego pola ma na celu wskazanie konkretnej wersji płytki zasilającej
urządzenie. Nie ma wymagań co do konkretnego formatu tego pola,
z tą różnicą, że NIE MOŻE mieć wartości null ani pustego ciągu („”).
Wartość wybrana przez realizatora urządzenia, identyfikująca nazwę
android.os.Build.BRAND
firma, organizacja, osoba fizyczna itp., która wyprodukowała urządzenie, w
formacie czytelnym dla człowieka. Możliwym zastosowaniem tego pola jest wskazanie producenta OEM

i/lub przewoźnika, który sprzedał urządzenie. Nie ma wymagań dot
specyficzny format tego pola, z tą różnicą, że NIE MOŻE mieć ono wartości null ani być puste
strunowy ("").
Wartość wybrana przez realizatora urządzenia identyfikująca specyfikę
konfiguracja lub rewizja nadwozia (czasami nazywana „przemysłową
android.os.Build.DEVICE
design”) urządzenia. Nie ma wymagań co do konkretnego formatu
tego pola, z tą różnicą, że NIE MOŻE mieć wartości null ani pustego ciągu („”).
Ciąg, który jednoznacznie identyfikuje tę kompilację. MUSI być rozsądne
czytelne dla człowieka. MUSI być zgodny z tym szablonem:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(ID_BUILD)/$(NUMER_BUILD):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
Na przykład: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/test-keys
Odcisk palca NIE MOŻE zawierać spacji. Jeśli inne pola zawarte w pliku
szablon powyżej zawiera spacje, NALEŻY je zastąpić kodem ASCII
znak podkreślenia („_”) w odcisku palca.
Ciąg znaków, który jednoznacznie identyfikuje hosta, na którym zbudowano kompilację (w języku ludzkim).
android.os.Build.HOST
czytelny format. Nie ma wymagań dotyczących konkretnego formatu tego
pole, z tą różnicą, że NIE MOŻE mieć wartości null ani pustego ciągu („”).
Identyfikator wybrany przez realizatora urządzenia w celu odniesienia się do konkretnego
wydania, w formacie czytelnym dla człowieka. To pole może być takie samo jak
android.os.Build.VERSION.INCREMENTAL, ale POWINNA być wartością
android.os.Build.ID
w zamierzeniu miało mieć pewne znaczenie dla użytkowników końcowych. Nie ma
wymagania dotyczące konkretnego formatu tego pola, z tym wyjątkiem, że NIE MOŻE
mieć wartość null lub pusty ciąg („”).
Wartość wybrana przez realizatora urządzenia zawierająca nazwę
urządzenie znane użytkownikowi końcowemu. To POWINNO być to samo imię
android.os.Build.MODEL
pod jakim wyrób jest wprowadzany do obrotu i sprzedawany użytkownikom końcowym. Nie ma
wymagania dotyczące konkretnego formatu tego pola, z tym wyjątkiem, że NIE MOŻE
mieć wartość null lub pusty ciąg („”).
Wartość wybrana przez realizatora urządzenia zawierającego rozwinięcie
nazwa lub nazwa kodowa urządzenia. MUSI być czytelny dla człowieka, ale tak nie jest
android.os.Build.PRODUCT
koniecznie przeznaczone do wglądu dla użytkowników końcowych. Nie ma żadnych wymagań
od konkretnego formatu tego pola, z tą różnicą, że NIE MOŻE mieć ono wartości null lub
pusta struna ("").
Rozdzielana przecinkami lista tagów wybranych przez implementującego urządzenie
dodatkowo rozróżnij konstrukcję. Na przykład „bez znaku, debugowanie”. To pole
android.os.Build.TAGS
NIE MOŻE mieć wartości null ani pustego ciągu („”), ale pojedynczy znacznik (np
„uwolnienie”) jest w porządku.
Android.os.Build.TIME
Wartość reprezentująca sygnaturę czasową wystąpienia kompilacji.
Wartość wybrana przez realizatora urządzenia, określająca czas wykonania
konfiguracja kompilacji. To pole POWINNO mieć jedną z wartości
Android.os.Build.TYPE
odpowiadający trzem typowym konfiguracjom środowiska uruchomieniowego Androida: „użytkownik”,
„userdebug” lub „eng”.
Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował plik
android.os.Build.USER
zbudować. Nie ma wymagań co do konkretnego formatu tego pola,
z tą różnicą, że NIE MOŻE mieć wartości null ani pustego ciągu („”).

3.2.3. Zamierzona kompatybilność
Android używa Intencji, aby osiągnąć luźno powiązaną integrację między aplikacjami. Ta sekcja opisuje
wymagania związane ze wzorcami intencji, które MUSZĄ być honorowane przez implementacje urządzeń. Przez
„zaszczycony” oznacza, że osoba wdrażająca urządzenie MUSI zapewnić działanie, usługę lub inną usługę dla systemu Android
komponent, który określa pasujący filtr Intencji i wiąże się z każdym z nich oraz implementuje prawidłowe zachowanie
określony wzorzec 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
wersje alternatywne.
Jednakże wszelkie takie alternatywne wersje MUSZĄ uwzględniać te same wzorce intencji dostarczone przez źródło nadrzędne
projekt. (Na przykład, jeśli urządzenie zawiera alternatywny odtwarzacz muzyki, musi nadal przestrzegać wzorca Intencji
wydawane przez aplikacje innych firm w celu wybrania utworu.) Implementacje urządzeń MUSZĄ obsługiwać wszystkie wzorce intencji
wymienione w dodatku A.
3.2.3.2. Zastąpienie zamiaru
Ponieważ Android jest platformą rozszerzalną, osoby wdrażające urządzenia MUSZĄ zezwolić na każdy wzorzec intencji opisany w
Dodatek A, który ma zostać zastąpiony przez aplikacje innych firm. Projekt open source dla Androida
domyślnie na to pozwala; osobom wdrażającym urządzenia NIE WOLNO przypisywać specjalnych uprawnień do aplikacji systemowych”
korzystania z tych wzorców zamierzeń lub uniemożliwiania aplikacjom stron trzecich wiązania się i przejmowania kontroli
te wzory. Zakaz ten obejmuje w szczególności wyłączenie interfejsu użytkownika „Chooser”, który umożliwia
użytkownikowi możliwość wyboru pomiędzy wieloma aplikacjami, które obsługują ten sam wzorzec intencji.
3.2.3.3. Przestrzenie nazw intencji
Osoby wdrażające urządzenia NIE MOGĄ dołączać żadnego komponentu Androida, który uwzględnia jakąkolwiek nową intencję lub
Wzorce intencji rozgłaszania przy użyciu AKCJI, KATEGORII lub innego ciągu klucza w przestrzeni nazw Android.*.
Osoby wdrażające urządzenia NIE MOGĄ dołączać żadnych komponentów Androida, które honorują jakąkolwiek nową intencję lub
Wzorce intencji rozgłaszania przy użyciu AKCJI, KATEGORII lub innego ciągu klucza w przestrzeni pakietu
należący do innej organizacji. Osoby wdrażające urządzenia NIE MOGĄ zmieniać ani rozszerzać żadnego z Zamierzeń
wzory wymienione w Załącznikach A lub B.
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 korzystają z platformy, aby transmitować określone intencje w celu powiadamiania ich o zmianach w
środowisko sprzętowe lub programowe. Urządzenia kompatybilne z systemem Android MUSZĄ nadawać transmisję publiczną
Intencje w odpowiedzi na odpowiednie zdarzenia systemowe. Lista wymaganych celów transmisji znajduje się w
Załącznik B; należy jednak pamiętać, że zestaw SDK może definiować dodatkowe cele transmisji, co również MUSI mieć miejsce
zaszczycony.
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 ELF
Plik .so skompilowany dla odpowiedniej architektury sprzętowej urządzenia. Implementacje urządzeń MUSZĄ obejmować
obsługa kodu działającego w zarządzanym środowisku w celu wywołania kodu natywnego, przy użyciu standardowej Java
Semantyka interfejsu natywnego (JNI). Dla kodu natywnego muszą być dostępne następujące interfejsy API:
• libc (biblioteka C)
• libm (biblioteka matematyczna)
• Interfejs JNI
• libz (kompresja Zlib)
• liblog (logowanie na Androida)
• Minimalne wsparcie dla C++
• OpenGL ES 1.1
Biblioteki te MUSZĄ być kompatybilne ze źródłami (tzn. kompatybilne z nagłówkami) i kompatybilne binarnie (dla danego
architektura procesora) z wersjami udostępnionymi w Bionic przez projekt Android Open Source. Od
implementacje Bionic nie są w pełni kompatybilne z innymi implementacjami, takimi jak GNU C
biblioteka, osoby wdrażające urządzenia POWINNY używać implementacji Androida. Jeśli realizatorzy urządzeń używają a
różne implementacje tych bibliotek, muszą one zapewniać zgodność nagłówków i plików binarnych.
Zgodność kodu natywnego jest wyzwaniem. Z tego powodu chcielibyśmy powtórzyć, że realizatorzy urządzeń są
BARDZO gorąco zachęcamy do korzystania z wcześniejszych implementacji bibliotek wymienionych powyżej, aby uzyskać pomoc
zapewnić kompatybilność.
3.4. Zgodność interfejsu API sieci Web
Wielu programistów i aplikacji opiera się na zachowaniu klasy android.webkit.WebView [ Zasoby ,
11] dla interfejsów użytkownika, więc implementacja WebView musi być kompatybilna z całym systemem Android
wdrożenia. Implementacja Android Open Source wykorzystuje wersję silnika renderującego WebKit do
wdrożyć WebView.
Ponieważ nie jest możliwe opracowanie kompleksowego zestawu testów dla przeglądarki internetowej, implementatorów urządzeń
MUSI używać określonej wcześniejszej wersji WebKit w implementacji WebView. Konkretnie:
• WebView MUSI używać wersji 528.5+ WebKit z wcześniejszego drzewa Android Open Source
Androida 1.6. Ta kompilacja zawiera określony zestaw poprawek funkcjonalności i zabezpieczeń dla WebView.
• Ciąg agenta użytkownika zgłaszany przez WebView MUSI mieć następujący format:
Mozilla/5.0 (Linux; U; Android 1.6; <język>-<kraj>; <urządzenie
imię>; Build/<identyfikator kompilacji>) AppleWebKit/528.5+ (KHTML, jak Gecko)
Wersja/3.1.2 Mobile Safari/525.20.1

◦ Ciąg „<nazwa urządzenia>” MUSI być taki sam jak wartość
android.os.Build.MODEL
◦ Ciąg „<identyfikator kompilacji>” MUSI być taki sam jak wartość android.os.Build.ID.
◦ Ciągi „<język>” i „<kraj>” POWINNY być zgodne ze zwyczajowymi konwencjami dotyczącymi
kod kraju i język oraz POWINIEN odnosić się do bieżącej lokalizacji urządzenia pod adresem
czas żądania.
Implementacje MOGĄ dostarczać niestandardowy ciąg agenta użytkownika w samodzielnej aplikacji przeglądarki. Co jest
co więcej, samodzielna przeglądarka MOŻE być oparta na alternatywnej technologii przeglądarki (takiej jak Firefox,
Opera itp.) Jednak nawet jeśli dostarczona jest alternatywna aplikacja przeglądarki, komponent WebView
dostarczane do aplikacji innych firm MUSZĄ być oparte na WebKit, jak powyżej.
Samodzielna aplikacja przeglądarki POWINNA obsługiwać Gears [ Zasoby, 12] i MAY
zawierać obsługę części lub całości HTML5.
3.5. Zgodność behawioralna API
Zachowania każdego z typów API (zarządzanego, miękkiego, natywnego i internetowego) muszą być spójne z
preferowana implementacja systemu Android dostępna w ramach projektu Android Open Source.
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 systemu
komponent (taki 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 odpowiedniego zachowania spoczywa na wdrażających urządzenia
zgodność. Z tego powodu osoby wdrażające urządzenia POWINNY używać kodu źródłowego dostępnego za pośrednictwem
Projekt Android Open Source, tam gdzie to możliwe, zamiast ponownego wdrażania znaczących części systemu.
Zestaw testów zgodności (CTS) testuje znaczące części platformy pod kątem zgodności behawioralnej,
ale nie wszystko. Obowiązkiem wdrażającego jest zapewnienie zgodności behawioralnej z systemem Android
Projekt open source.
3.6. Przestrzenie nazw API
Android przestrzega konwencji przestrzeni nazw pakietów i klas zdefiniowanych w programowaniu w języku Java
język. Aby zapewnić kompatybilność z aplikacjami innych firm, twórcom urządzeń NIE WOLNO tworzyć
wszelkie zabronione modyfikacje (patrz poniżej) tych przestrzeni nazw pakietów:
• Java.*
• javax.*
• słońce.*
• Androida.*
• com.android.*
Zabronione modyfikacje obejmują:
• Implementacje urządzeń NIE MOGĄ modyfikować publicznie dostępnych interfejsów API na platformie Android
zmieniając dowolne podpisy metod lub klas albo usuwając klasy lub pola klas.

• Osoby wdrażające urządzenia MOGĄ modyfikować podstawową implementację interfejsów API, ale np
modyfikacje NIE MOGĄ wpływać na określone zachowanie ani podpis żadnego z nich w języku Java
publicznie udostępniane interfejsy API.
• Osoby wdrażające urządzenia NIE WOLNO dodawać żadnych publicznie dostępnych elementów (takich jak klasy lub
interfejsy lub 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 pliku
wcześniejszy kod źródłowy Androida. Innymi słowy, twórcom urządzeń NIE WOLNO ujawniać nowych interfejsów API lub
zmieniać istniejące interfejsy API w przestrzeniach nazw wymienionych powyżej. Osoby wdrażające urządzenia MOGĄ tworzyć tylko wewnętrzne
modyfikacje, ale modyfikacje te NIE WOLNO reklamować ani w żaden inny sposób udostępniać programistom.
Osoby wdrażające urządzenia MOGĄ dodawać niestandardowe interfejsy API, ale żadne takie interfejsy API NIE MOGĄ należeć do własnej przestrzeni nazw
przez inną organizację lub odwołując się do niej. Na przykład twórcom urządzeń NIE WOLNO dodawać interfejsów API do
com.google.* lub podobna przestrzeń nazw; może to zrobić tylko Google. Podobnie Google NIE WOLNO dodawać interfejsów API do
przestrzenie 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
użyteczną nową funkcjonalność do istniejącego API lub dodanie nowego API), wdrażający POWINIEN odwiedzić
source.android.com i rozpocznij proces wprowadzania zmian i kodu, zgodnie z
informacje na tej stronie.
Należy zauważyć, że powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku Java
język programowania; ta sekcja ma po prostu na celu wzmocnienie tych konwencji i uczynienie ich wiążącymi
poprzez włączenie do niniejszej definicji zgodności.
3.7. Zgodność z maszyną wirtualną
Zgodne urządzenie z systemem Android musi obsługiwać pełną specyfikację kodu bajtowego Dalvik Executable (DEX) i
Semantyka maszyny wirtualnej Dalvik [Zasoby, 13].
3.8. Zgodność interfejsu użytkownika
Platforma Android zawiera pewne interfejsy API dla programistów, które umożliwiają programistom podłączenie się do użytkownika systemu
interfejs. Implementacje urządzeń MUSZĄ uwzględniać te standardowe interfejsy API interfejsu użytkownika w niestandardowych interfejsach użytkownika
rozwijają się, 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 udostępnianie aplikacji
„AppWidget” dla użytkownika końcowego [Zasoby , 14] . Wersja referencyjna Android Open Source zawiera plik
Aplikacja uruchamiająca zawierająca 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ć interfejs użytkownika
elementy umożliwiające dodawanie, przeglądanie i usuwanie AppWidgets bezpośrednio w programie uruchamiającym. Alternatywne wyrzutnie MAJ
pomiń te elementy interfejsu użytkownika; jeśli jednak zostaną pominięte, osoba wdrażająca urządzenie MUSI zapewnić
osobna aplikacja dostępna z poziomu Launchera, która umożliwia użytkownikom dodawanie, przeglądanie i usuwanie
Widżety aplikacji.

3.8.2. Powiadomienia
Android zawiera interfejsy API, które pozwalają programistom powiadamiać użytkowników o ważnych wydarzeniach [Zasoby, 15]. Urządzenie
realizatorzy MUSZĄ zapewnić wsparcie dla każdej tak zdefiniowanej klasy powiadomień; konkretnie: dźwięki,
wibracje, światło i pasek stanu.
Dodatkowo implementacja MUSI poprawnie renderować i wszystkie zasoby (ikony, pliki dźwiękowe itp.)
przewidziane w interfejsach API [Zasoby, 7] lub w przewodniku po stylach ikon paska stanu [Zasoby , 16]. Urządzenie
Osoby wdrażające MOGĄ zapewnić użytkownikowi alternatywny sposób obsługi powiadomień niż ten zapewniany przez
odniesienie do implementacji Android Open Source; jednakże takie alternatywne systemy powiadamiania MUSZĄ
wspierać istniejące zasoby powiadomień, jak powyżej.
3.8.3. Szukaj
Android zawiera interfejsy API [Zasoby, 17], które umożliwiają programistom włączenie wyszukiwania do swoich aplikacji,
i ujawnić dane swojej aplikacji w globalnym wyszukiwaniu systemowym. Generalnie taka funkcjonalność
składa się z jednego, ogólnosystemowego interfejsu użytkownika, który umożliwia użytkownikom wprowadzanie zapytań, wyświetla sugestie
podczas pisania przez użytkownika i wyświetla wyniki. Interfejsy API systemu Android umożliwiają programistom ponowne wykorzystanie tego interfejsu do udostępniania
wyszukiwania w ich własnych aplikacjach i umożliwiają programistom dostarczanie wyników zwykłemu użytkownikowi wyszukiwarki globalnej
interfejs.
Implementacje urządzeń MUSZĄ obejmować pojedynczy, współdzielony, ogólnosystemowy interfejs użytkownika umożliwiający wyszukiwanie
sugestie w czasie rzeczywistym w odpowiedzi na dane wejściowe użytkownika. Implementacje urządzeń MUSZĄ implementować interfejsy API, które
umożliwić programistom ponowne wykorzystanie tego interfejsu użytkownika w celu zapewnienia wyszukiwania w ich własnych aplikacjach.
Implementacje urządzeń MUSZĄ implementować interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii
do pola wyszukiwania, jeśli jest ono uruchamiane w trybie wyszukiwania globalnego. Jeśli nie są zainstalowane żadne aplikacje innych firm
skorzystać z tej funkcjonalności, domyślnym zachowaniem POWINNO być wyświetlanie wyników wyszukiwarki internetowej i
propozycje.
Implementacje urządzeń MOGĄ zapewniać alternatywne interfejsy użytkownika wyszukiwania, ale POWINNY zawierać twardy lub miękki interfejs
dedykowany przycisk wyszukiwania, którego można użyć w dowolnej chwili w dowolnej aplikacji, aby wywołać framework wyszukiwania,
z zachowaniem przewidzianym w dokumentacji API.
3.8.4. Tosty
Aplikacje mogą używać interfejsu API „Toast” (zdefiniowanego w [ Zasoby, 18]), aby wyświetlać krótkie niemodalne ciągi znaków
użytkownika końcowego, które znikają po krótkim czasie. Implementacje urządzeń MUSZĄ wyświetlać tosty z
aplikacje dla użytkowników końcowych w sposób dobrze widoczny.
4. Zgodność oprogramowania referencyjnego
Osoby wdrażające urządzenia MUSZĄ przetestować zgodność implementacji przy użyciu następującego oprogramowania typu open source
Aplikacje:
• Kalkulator (zawarty w SDK)
• Lądownik Księżycowy (zawarty w SDK)
• ApiDemos (zawarte w SDK)
• Aplikacje „Aplikacje dla Androida” [ Zasoby, 19]
Aby wdrożenie mogło nastąpić, każda powyższa aplikacja MUSI zostać uruchomiona i działać poprawnie podczas implementacji

uznane za zgodne.
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 , 20].
Implementacje urządzeń NIE MOGĄ rozszerzać kodu bajtowego .apk, manifestu systemu Android ani kodu bajtowego Dalvik
formatach w sposób uniemożliwiający prawidłową instalację i działanie tych plików na innych
kompatybilne urządzenia. Osoby wdrażające urządzenia POWINNY używać referencyjnej implementacji Dalvik,
oraz system zarządzania pakietami implementacji referencyjnej.
6. Kompatybilność multimediów
Zgodne urządzenie z systemem Android musi obsługiwać następujące kodeki multimedialne. Wszystkie te kodeki są
dostarczane jako implementacje oprogramowania w preferowanej implementacji Androida z Android Open
Projekt źródłowy [ Zasoby , 4].
Należy pamiętać, że ani firma Google, ani stowarzyszenie Open Handset Alliance nie składają żadnych oświadczeń w tym zakresie
kodeki nie są obciążone patentami stron trzecich. Osoby zamierzające używać tego kodu źródłowego na sprzęcie lub
W przypadku produktów programowych zaleca się, aby implementacje tego kodu, w tym w oprogramowaniu typu open source lub
shareware, może wymagać licencji patentowych od odpowiednich posiadaczy patentów.
Audio
Nazwa
Szczegóły dekodera kodera
Obsługiwane pliki
Treści mono/stereo w dowolnym formacie
3GPP (.3gp) i
połączenie standardowych przepływności
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
do 160 kbps i pliki o częstotliwościach próbkowania. Brak wsparcia dla raw
od 8 do 48 kHz
AAC (.aac)
Treści mono/stereo w dowolnym formacie
3GPP (.3gp) i
HE-AACv1
połączenie standardowych przepływności
MPEG-4 (.mp4, .m4a)
X
(AAC+)
do 96 kbps i pliki o częstotliwościach próbkowania. Brak wsparcia dla raw
od 8 do 48 kHz
AAC (.aac)
Treści mono/stereo w dowolnym formacie
HE-AACv2
3GPP (.3gp) i
połączenie standardowych przepływności
(wzmocniony
MPEG-4 (.mp4, .m4a)
X
do 96 kbps i częstotliwości próbkowania
AAC+)
akta. Brak wsparcia dla raw
od 8 do 48 kHz
AAC (.aac)
AMR-NB
Próbkowanie od 4,75 do 12,2 kb/s @
Pliki 3GPP (.3gp).
X
X
8 kHz
AMR-WB
9 szybkości od 6,60 kbit/s do 23,85
-3GPP (.3gp) pliki
X
kbit/s próbkowane przy 16 kHz
MP3
Mono/Stereo Stałe pliki MP3 (.mp3) o szybkości 8–320 Kb/s
X
(CBR) lub zmienna przepływność (VBR)
Wpisz 0 i 1 (.mid, .xmf,
Typ MIDI 0 i 1. Wersja DLS 1
MIDI
X
.mxmf). Również RTTTL/RTX
oraz 2. XMF i mobilny XMF.
(.rtttl, .rtx), OTA (.ota),

Obsługa formatów dzwonków
i iMelody (.imy)
RTTTL/RTX, OTA i iMelody
Ogga Vorbisa
.ogg
X
8- i 16-bitowy liniowy PCM (szybkość wzrasta
PCM
X
FALA
do ograniczenia sprzętu)
Obraz
Akta
Nazwa
Szczegóły dekodera enkodera
Utrzymany
JPG
X
X
baza+progresywna
GIF-y
X
PNG
X
X
BMP
X
Wideo
Akta
Nazwa
Szczegóły dekodera enkodera
Utrzymany
3GPP (.3GP)
H.263
X
X
akta
3GPP (.3GP)
H.264
X
i MPEG-4
(.mp4) Pliki
MPEG4
X
Plik 3GPP (.3GP)
SP
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 lub ADB [Resources , 21]
Implementacje urządzeń muszą obsługiwać wszystkie funkcje ADB, jak udokumentowano na Androidzie
SDK. Demon ADB po stronie urządzenia powinien być domyślnie nieaktywny, ale musi istnieć użytkownik-
Dostępny mechanizm włączenia mostu debugowego Androida.
• Dalvik Debug Monitor Service lub DDMS [Zasoby , 22]
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
Ilekroć użytkownik aktywuje most debugowania Androida, jak wyżej.

• Monkey [Resources, 23]
Implementacje urządzeń muszą zawierać framework małp i udostępnić je
aplikacje do użycia.
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 wszystkich Android
urządzenie. W tej sekcji wymieniono funkcje sprzętowe, które muszą obsługiwać wszystkie urządzenia kompatybilne z Androidem 1.6. W
Wymagana jest Android 1.6, większość funkcji sprzętowych (takich jak Wi -Fi, kompas i akcelerometr).
Jeśli urządzenie zawiera określony komponent sprzętowy, który ma odpowiedni interfejs API dla stron trzecich
Deweloperzy, implementacja urządzeń musi zaimplementować ten interfejs API zgodnie z definicją w systemie Android SDK
dokumentacja.
8.1. Wyświetlacz
Android 1.6 obejmuje obiekty wykonujące pewne automatyczne operacje skalowania i transformacji w ramach
Niektóre okoliczności, aby zapewnić, że aplikacje zewnętrzne działają dość dobrze na sprzęcie
Konfiguracje, dla których niekoniecznie zostały one wyraźnie zaprojektowane [Zasoby, 24] . Urządzenia muszą
Właściwie wdrażaj te zachowania, jak szczegółowo opisano w tej sekcji.
8.1.1. Standardowe konfiguracje wyświetlania
W tej tabeli wymienia standardowe konfiguracje ekranu uważane za kompatybilne z Androidem:
Przekątna
Rozmiar ekranu
Gęstość ekranu
Typ ekranu
Szerokość (piksele)
Wysokość (piksele)
Zakres długości
Grupa
Grupa
(cale)
QVGA
240
320
2.6 - 3.0
Mały
Niski
WQVGA
240
400
3,2 - 3,5
Normalna
Niski
FWQVGA
240
432
3,5 - 3,8
Normalna
Niski
HVGA
320
480
3,0 - 3,5
Normalna
Średni
WVGA
480
800
3.3 - 4.0
Normalna
Wysoki
FWVGA
480
854
3,5 - 4,0
Normalna
Wysoki
WVGA
480
800
4.8 - 5.5
Duży
Średni
FWVGA
480
854
5,0 - 5,8
Duży
Średni
Należy skonfigurować implementacje urządzeń odpowiadające jednej ze standardowych konfiguracji
Aby zgłosić wskazany rozmiar ekranu do aplikacji za pośrednictwem Android.Content.Res.Configuration [ Zasoby,
25] klasa.
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ć wszelkie zasoby obecne jako domyślne
„Medium” (znany jako „MDPI” w dokumentacji SDK.)
• Podczas pracy na ekranie „niskiej” gęstości implementacje urządzeń muszą zmniejszyć średnio/
Aktywa MDPI współczynnik 0,75.
• Podczas pracy na ekranie „wysokiej” gęstości implementacje urządzeń muszą skalować średnio/
Aktywa MDPI współczynnikiem 1,5.
• Implementacje urządzeń nie mogą skalować zasobów w zakresie gęstości i muszą skalować
Aktywa dokładnie te czynniki między zakresami gęstości.
8.1.2. Niestandardowe konfiguracje wyświetlania
Wyświetl konfiguracje, które nie pasują do jednej ze standardowych konfiguracji wymienionych w sekcji 8.2.1
Dodatkowe rozważania i prace za kompatybilne. Wdrażacze urządzeń muszą skontaktować się z Androidem
Zespół kompatybilności, jak przewidziano w sekcji 12 w celu uzyskania klasyfikacji dla wiadra wielkości ekranu, gęstości,
i współczynnik skalowania. Po dostarczeniu tych informacji implementacje urządzeń muszą je zaimplementować
jak określono.
Zauważ, ż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 1.6; Dlatego zachęca się do wdrażania urządzeń
Skontaktuj się z zespołem zgodności z Androidem tak wcześnie, jak to możliwe 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.2. Klawiatura
Implementacje urządzeń:
• Musi uwzględnić wsparcie dla ram wejściowych zarządzania (które pozwala stronom trzecim
Deweloperzy do tworzenia silników zarządzania wejściowym - tj. Klawiatura miękka), jak szczegółowo opisano
deweloper.android.com
• Musi zapewnić co najmniej jedną implementację klawiatury miękkiej (niezależnie od tego, czy trudny
Klawiatura jest obecna)
• Może obejmować dodatkowe implementacje klawiatury miękkiej
• Może zawierać klawiaturę sprzętową
• Nie może zawierać klawiatury sprzętowej, która nie pasuje do jednego z określonych formatów
w Android.Content.Res.Configuration [ 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, 5-kierunkową podkładkę, lub
koło)
• Musi zgłosić się za pośrednictwem Android.Content.res.Configuration [Zasoby , 25] Prawidłowa wartość dla
Sprzęt urządzenia

8.4. Orientacja ekranu
Kompatybilne urządzenia muszą obsługiwać dynamiczną orientację według aplikacji do portretu lub krajobrazu
orientacja ekranu. Oznacza to, że urządzenie musi szanować żądanie aplikacji dla określonego ekranu
orientacja. 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 są zapytane
Android.content.res.configuration.orientation, 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ący typowi określonego ekranu dotykowego na urządzeniu
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ć klienta pamięci masowej USB dla zdejmowanej/multimedialnej pamięci jest obecna w
urządzenie
• Powinien użyć współczynnika formularza Micro USB po stronie urządzenia
• Powinien zaimplementować obsługę specyfikacji masowej masy USB (aby albo wymienne
lub stałe przechowywanie na urządzeniu można uzyskać z komputera hosta)
• Może obejmować niestandardowy port po stronie urządzenia
Łączenie niestandardowego pinout ze standardowym portem USB-A
8.7. Klawisze nawigacyjne
Funkcje domu, menu i tyłu są niezbędne dla paradygmatu nawigacji na Androida. Urządzenie
Implementacje muszą udostępniać te funkcje przez cały czas, niezależnie od aplikacji
państwo. Funkcje te powinny być zaimplementowane za pomocą dedykowanych przycisków. Mogą być wdrażane
Korzystanie z oprogramowania, gestów, panelu dotykowego itp., Ale jeśli tak, muszą być zawsze dostępne i nie są niejasne lub
zakłócaj dostępny obszar wyświetlania aplikacji.
Wdrażacze urządzeń powinni również dostarczyć dedykowany klucz wyszukiwania. Wdrażacze urządzeń mogą również
Podaj klucze wysyłane i kończą dla połączeń telefonicznych.
8.8. WiFi
Implementacje urządzeń muszą obsługiwać 802.11b i 802.11g i mogą obsługiwać 802.11a.

8.9. Kamera
Implementacje urządzeń muszą obejmować aparat. Dołączony aparat:
• Musi mieć rozdzielczość co najmniej 2 megapikseli
• Powinien mieć sprzętowy automatyczne skupienie lub automatyczne skupienie oprogramowania zaimplementowane w aparacie
sterownik (przezroczysty dla oprogramowania aplikacyjnego)
• Może mieć sprzęt o stałym stopniu lub EDOF (rozszerzona głębokość pola)
• Może obejmować błysk. Jeśli aparat zawiera lampę błyskową, lampa lampy błyskowej nie może być oświetlona podczas
Android.hardware.camera.previewCallback Instance został zarejestrowany w podglądu aparatu
powierzchnia.
Implementacje urządzeń muszą wdrożyć następujące zachowania dla interfejsów API związanych z kamerą
[Zasoby, 27] :
1. Jeśli aplikacja nigdy nie nazywała android.hardware.camera.parameters.setpreviewformat (int),
Następnie urządzenie musi użyć Android.Hardware.Pixelformat.ycbcr_420_sp dla danych podglądu
dostarczone do oddzwonienia aplikacji.
2. Jeśli aplikacja rejestruje instancję Android.Hardware.camera.PreviewCallback i
System wywołuje metodę onPreviewFram (), gdy format podglądu jest YCBCR_420_SP,
Dane w bajcie [] przekazane do onPreviewFrame () muszą być dalej w formacie kodowania NV21.
(Jest to format używany natywnie przez rodzinę sprzętową 7K.) To znaczy, NV21 musi być domyślnie.
8.9.1. Kamery nie-autofocus
Jeśli urządzeniu nie ma aparatu autofokusu, wdrażacz urządzenia musi spełniać dodatkowe wymagania w
ta sekcja. Implementacje urządzeń muszą zaimplementować pełny interfejs API aparatu zawarty w systemie Android 1.6
Dokumentacja SDK w jakiś rozsądny sposób, niezależnie od rzeczywistych możliwości sprzętu aparatu.
W przypadku Androida 1.6, jeśli kamerą nie ma automatycznego skupienia, implementacja urządzenia musi być zgodna z następującymi:
1. System musi zawierać właściwość systemową tylko do odczytu o nazwie „ro.workraund.noautofocus”
z wartością „1”. Ta wartość ma być używana przez aplikacje takie jak Android Rynek
selektywnie zidentyfikuj możliwości urządzeń i zostaną wymienione w przyszłej wersji Androida
Solidny API.
2. Jeśli aplikacja wywołuje android.hardware.camera.autofocus (), system musi wywołać
metoda wywoławcza ONAUTOFOCUS () na dowolnym zarejestrowanym
Android.hardware.camera.autofoCuscAllback instancje, mimo że tak naprawdę nie jest skupienie
stało się. Ma to na celu uniknięcie przerwania istniejących aplikacji, czekając na zawsze na autofokus
Oddzwonienie, które nigdy nie nadejdzie.
3. Wezwanie do metody autofocuscallback.onautofocus () musi zostać uruchomione przez kierowcę lub
Framework w nowym wydarzeniu w głównym frameworku Looper. To znaczy camera.autofocus ()
Nie może bezpośrednio nazywać autofocuscallback.onautofocus (), ponieważ narusza to Android
Model gwintowania frameworka i przełamie aplikacje.
8.10. Akcelerometr
Implementacje urządzeń muszą zawierać 3-osiowy akcelerometr i muszą być w stanie dostarczać zdarzenia AT
najmniej 50 Hz. Układ współrzędnych stosowany przez akcelerometr musi być zgodny z czujnikiem Androida
System koordynowania, jak szczegółowo opisano w interfejsie API Androida [zasoby , 28].

8.11. Kompas
Implementacje urządzeń muszą zawierać 3-osiowy kompas i musi być w stanie przynajmniej dostarczać zdarzenia
10 Hz. Układ współrzędnych stosowany przez kompas musi być zgodny z współrzędną czujnika Androida
system zdefiniowany w API Androida [zasoby , 28].
8.12. GPS
Implementacje urządzeń muszą zawierać GPS i powinny zawierać jakąś formę „wspomaganego GPS”
Technika zminimalizowania czasu blokady GPS.
8.13. Telefonia
Implementacje urządzeń:
• Musi zawierać telefonię GSM lub CDMA
• Musi zaimplementować odpowiednie interfejsy API, jak szczegółowo opisano w dokumentacji Android SDK pod adresem
deweloper.android.com
Należy zauważyć, że ten wymóg oznacza, że urządzenia inne niż telefony nie są kompatybilne z Android 1.6; Android
1.6 Urządzenia muszą obejmować sprzęt telefoniczny. Informacje na temat nie telefonu można znaleźć w załączniku C
urządzenia.
8.14. Regulacja głośności
Urządzenia kompatybilne z Androidem muszą zawierać mechanizm umożliwiający użytkownikowi zwiększenie i zmniejszenie
wolumen dźwiękowy. Implementacje urządzeń muszą udostępniać te funkcje użytkownikowi przez cały czas,
niezależnie od stanu aplikacji. Funkcje te można zaimplementować za pomocą fizycznych kluczy sprzętowych,
oprogramowanie, gesty, panel dotykowy itp., Ale muszą być zawsze dostępne i nie są niejasne ani nie zakłócają
z dostępnym obszarem wyświetlania aplikacji (patrz wyświetlacz powyżej).
Gdy przyciski te są używane, odpowiednie kluczowe zdarzenia muszą być wygenerowane i wysyłane do
Aplikacja na pierwszym planie. Jeśli zdarzenie nie jest przechwycone i zatopione przez aplikację, to urządzenie
Implementacja musi obsłużyć zdarzenie jako kontrolę głośności systemu.
9. Kompatybilność wydajności
Jednym z celów programu kompatybilności Androida jest zapewnienie spójnego doświadczenia w aplikacji
konsumenci. Kompatybilne implementacje muszą zapewnić nie tylko, że aplikacje po prostu działają poprawnie
Urządzenie, ale robią to z rozsądną wydajnością i ogólnie dobrym doświadczeniem użytkownika.
Implementacje urządzeń muszą spełniać kluczowe wskaźniki wydajności urządzenia kompatybilnego z Android 1.6,
jak w poniższej tabeli:
Metryczny
Próg wydajności
Uwagi

Jest to testowane przez CTS.
Następujące aplikacje
Czas uruchomienia jest mierzony jako całkowity czas na
powinien zostać uruchomiony w ramach
pełne ładowanie domyślnej aktywności dla
Aplikacja
określony czas.
aplikacja, w tym czas potrzebny na rozpoczęcie
Pora obiadowa
Przeglądarka: mniej niż 1300 ms
Proces Linux, załaduj pakiet Android do
MMS/SMS: mniej niż 700 ms
Dalvik VM i zadzwoń do OnCreate.
CLOCK ALARM: mniej niż 650 ms
Wiele aplikacji będzie
Jest to testowane przez CTS.
wystrzelony. Ponowne uruchomienie
Jednoczesne pierwsze aplikacje powinno
Aplikacje
Ukończanie mniej niż
Oryginalny czas premiery.
10. Kompatybilność modelu bezpieczeństwa
Implementacje urządzeń muszą wdrożyć model bezpieczeństwa zgodny z bezpieczeństwem platformy Android
model zdefiniowany w dokumencie referencyjnym bezpieczeństwa i uprawnień w interfejsach API [zasoby, 29] w
Dokumentacja programisty Androida. Implementacje urządzeń muszą obsługiwać instalację autoryzowanego
Wnioski bez wymagania dodatkowych uprawnień/certyfikatów od osób trzecich/organów.
W szczególności kompatybilne urządzenia muszą obsługiwać następujące mechanizmy bezpieczeństwa:
10.1. Uprawnienia
Implementacje urządzeń muszą obsługiwać model uprawnień na Androida zgodnie z definicją w Androidzie
Dokumentacja programisty [ Zasoby , 9]. 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ń.
Wdrożenia mogą dodać dodatkowe uprawnienia, pod warunkiem, że nowe ciągi identyfikacyjne uprawnień nie są w
Android.* Przestrzeń nazw.
10.2. Izolacja użytkownika i procesu
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, podany
że aplikacje są odpowiednio podpisywane i konstruowane, zgodnie z definicją w bezpieczeństwie i uprawnieniach
Odniesienie [ 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ą
Zdefiniowane w odniesieniu do bezpieczeństwa i uprawnień [Zasoby , 29].
11. Suite testowe kompatybilności
Implementacje urządzeń muszą przekazać pakiet testu kompatybilności Android (CTS) [ Zasoby, 3] Dostępne
Z projektu open source z Androidem, korzystając z ostatecznego oprogramowania wysyłkowego na urządzeniu. Dodatkowo,
Wdrażacze urządzeń powinni korzystać z referencyjnej implementacji w drzewie open source Android jako
tak, jak to możliwe i musi zapewnić zgodność w przypadku dwuznaczności w CTS i dla każdego
Ponowne wdrożenie części kodu źródłowego odniesienia.
CTS jest zaprojektowany do uruchamiania na rzeczywistym urządzeniu. Jak każde oprogramowanie, same CT mogą zawierać błędy.
CTS będzie wersja niezależnie od tej definicji kompatybilności i wielu poprawek
CTS może zostać wydany na Android 1.6. Jednak takie wydania naprawią tylko błędy behawioralne w CTS
Testy i nie będą narzucić żadnych nowych testów, zachowań ani interfejsów API dla danego wydania platformy.
12. Skontaktuj się z nami
Możesz skontaktować się z zespołem zgodności z Androidem pod adresem Compaticibity@android.com w celu wyjaśnienia związanych z
Ta definicja kompatybilna i przekazanie informacji zwrotnych na temat tej definicji.

Dodatek A: Wymagane zamiary aplikacji
Uwaga: Ta lista jest tymczasowa i zostanie zaktualizowana w przyszłości.
Działania aplikacyjne
Schematy typy mim
(nic)
Zwykły tekst
http
tekst/html
Przeglądarka
Android.intent.action.view
https
aplikacja/xhtml+xml
aplikacja/
vnd.wap.xhtml+xml
(nic)
Android.intent.action.web_search
http
(nic)
https
Android.media.action.image_capture
Android.media.action.still_image_camera
Kamera
Android.media.action.video_camera
Android.media.action.video_capture
vnd.android.cursor.dir/
Android.intent.action.view
obraz
Android.intent.action.get_content
vnd.android.cursor.dir/
Android.intent.action.pick
wideo
Android.intent.action.attach_data
obraz/*
wideo/*
Android.intent.action.view
rtsp
wideo/mp4
Wideo/3GP
Android.intent.action.view
http
wideo/3gpp
Wideo/3GPP2
Android.intent.action.dial
Telefon /
Android.intent.action.view
tel
Łączność
Android.intent.action.call
Android.intent.action.dial
vnd.android.cursor.dir/
Android.intent.action.view
osoba

vnd.android.cursor.dir/
osoba
vnd.android.cursor.dir/
Android.intent.action.pick
telefon
vnd.android.cursor.dir/
adres pocztowy
vnd.android.cursor.item/
osoba
vnd.android.cursor.item/
Android.intent.action.get_content
telefon
vnd.android.cursor.item/
adres pocztowy
Zwykły tekst
E-mail
Android.intent.action.send
obraz/*
wideo/*
Android.intent.action.view
poczta
Android.intent.action.sendto
SMS-y
Android.intent.action.view
Smsto
SMS / MMS android.intent.action.sendto
mms
MMSTO
audio/*
Aplikacja/OGG
Muzyka
Android.intent.action.view
plik
Aplikacja/X-OGG
Aplikacja/iTunes
audio/mp3
Audio/X-Mp3
Android.intent.action.view
http
audio/mpeg
audio/mp4
audio/mp4a-latm
vnd.android.cursor.dir/
Artistalbum
vnd.android.cursor.dir/
album
vnd.android.cursor.dir/
Android.intent.action.pick
teraz
vnd.android.cursor.dir/
ścieżka
nd.android.cursor.dir/
playlista
vnd.android.cursor.dir/
wideo
głoska bezdźwięczna/*
audio/*
Android.intent.action.get_content
Aplikacja/OGG
Aplikacja/X-OGG
wideo/*

treść
Pakiet
Android.intent.action.view
plik
Instalator
pakiet
plik
Android.intent.action.package_install
http
https
Android.intent.action.all_apps
Android.settings.settings
Android.settings.wireless_settings
Android.settings.airplane_mode_settings
Android.settings.wifi_settings
Android.settings.apn_settings
Android.settings.Bluetooth_settings
Android.settings.Date_Settings
Android.settings.locale_settings
Ustawienia
Android.settings.input_method_settings
com.android.settings.sound_settings
com.android.settings.display_settings
Android.settings.security_setting
Android.settings.Location_Source_settings
Android.settings.internal_storage_settings
Android.settings.memory_card_settings
Android.intent.action.set_wallpaper
Szukaj
Android.intent.action.search
zapytanie
Android.intent.action.search_long_press
Głos
Android.intent.action.voice_command
Zarządzanie kontaktami
Intent Action
Opis
Rozpoczyna aktywność, która pozwala użytkownikowi wybrać
Załącz_image
kontakt, aby dołączyć obraz.
Używany
Extra_create_description
z show_or_create_contact to
określić dokładny opis do bycia

pokazane podczas monitowania użytkownika
Tworzenie nowego kontaktu.
Używany
z show_or_create_contact to
Extra_force_create
zmuszać tworzenie nowego kontaktu, jeśli nie
Znaleziono dopasowywany kontakt.
To jest zamiar wystrzeliwany, gdy
Search_suggestion_clicked
Sugestia wyszukiwania jest klikana.
To jest zamiar wystrzeliwany, gdy
Search_suggestion_create_contact_clicked SEDEL SEDGIZACJA Utworzenia
Kontakt jest klikany.
To jest zamiar wystrzeliwany, gdy
Search_suggestion_dial_number_clicked
Wyszukaj sugestię dotyczącą wybrania numeru
jest klikany.
Bierze jako wprowadzanie adresu URI danych z pocztą:
Show_or_create_contact
lub Tel: Schemat.

Dodatek B: Wymagane intencje transmisji Uwaga: Ta lista jest tymczasowa i będzie
zaktualizowane w przyszłości.
Intent Action
Opis
AKCJA AKCJI: jest to transmitowane raz, po
Action_boot_Completed
System zakończył uruchamianie.
Akcja nadawcza: jest to transmitowane raz, gdy
Action_Call_Button
połączenie jest odbierane.
Akcja nadawcza: „przycisk aparatu” był
Action_camera_button
prasowany.
Działanie nadawania: obecny
Action_configuration_Changed
konfiguracja urządzenia (orientacja, lokalizacja itp.)
zmieniony.
Action_Date_Changed
Działanie transmisji: Data się zmieniła.
Działanie transmisji: Wskazuje warunek niskiej pamięci
Action_Device_storage_low
na urządzeniu
Działanie transmisji: Wskazuje warunek niskiej pamięci
Action_Device_storage_OK
na urządzeniu już nie istnieje
Akcja nadawcza: przewodowy zestaw słuchawkowy podłączony lub
Action_headset_plug
odłączony.
Działanie transmisji: metoda wejściowa była
Action_input_method_Changed
zmieniony.
Działanie nadawania: Media zewnętrzne zostały usunięte
Action_Media_Bad_Removal
z gniazda karty SD, ale Mount Point nie był
nieoprawny.
Akcja nadawcza: „przycisk multimediów” był
Action_Media_Button
prasowany.
Działanie transmisji: Media zewnętrzne są obecne i
sprawdzanie dysku ścieżka do punktu montażu
Action_Media_Checking
Media sprawdzające są zawarte w
Intent.mdata Field.
Działanie nadawania: Użytkownik wyraził chęć
Action_Media_Eject
Usuń zewnętrzne nośniki pamięci.
Działanie nadawania: Media zewnętrzne są obecne i
Action_Media_Mounted
zamontowany w punkcie góry.
Działanie transmisji: Media zewnętrzne są obecne, ale są
Używanie niezgodnego FS (lub jest puste) ścieżka do
Action_media_nofs
punktem montażu dla mediów sprawdzających jest
zawarty w polu intent.mdata.
AKCJA AKCJI: Media zewnętrzne były
Action_Media_Removed
REMOVED.
Akcja nadawcza: skaner mediów zakończył
Action_media_scanner_finished
Skanowanie katalogu.
Działanie nadawania: poproś skanera mediów do
Action_media_scanner_scan_file
Zeskanuj plik i dodaj go do bazy danych multimediów.

Akcja nadawcza: rozpoczął się skaner mediów
Action_Media_Scanner_Started
Skanowanie katalogu.
Działanie nadawania: Media zewnętrzne są niezamontowane
Action_media_shared
Ponieważ jest udostępniany przez masę USB.
Działanie transmisji: Media zewnętrzne są obecne, ale
Action_media_unmountable
nie można zamontować.
Działanie transmisji: Media zewnętrzne są obecne, ale
Action_media_unmounted
nie zamontowany w punkcie góry.
AKCJA AKCJI: WYNIKAJ WYNIKAJĄCE
Action_New_Outging_Call
umieszczony.
Akcja nadawcza: ma nowy pakiet aplikacji
Action_Package_Added
zostały zainstalowane na urządzeniu.
Działanie nadawania: istniejący pakiet aplikacji
Action_Package_Changed
został zmieniony (np. komponent był
włączone lub wyłączone.
Działanie nadawane: Użytkownik wyczyścił dane
paczka. To powinno być poprzedzone
przez akt_package_restarted, po czym
Action_Package_Data_Cleared
Wszystkie jego trwałe dane są wymazane i to
transmisja wysłana. Zauważ, że wyczyszczony pakiet
nie otrzymuje tej transmisji. Dane zawierają
Nazwa pakietu.
Działanie nadawania: istniejący pakiet aplikacji
został usunięty z urządzenia. Dane
Action_Package_Removed
zawiera nazwę pakietu. Paczka
To jest instalowane, nie otrzymuje tego zamiaru.
Akcja nadawcza: nowa wersja aplikacji
Action_package_replaced
Pakiet został zainstalowany, zastępując istniejący
wersja, która została wcześniej zainstalowana.
Działanie nadawania: Użytkownik ponownie uruchomił
Pakiet i wszystkie jego procesy zostały zabite.
Wszystkie powiązane z tym stan czasowe (procesy,
Action_package_restarted
Należy usunąć alarmy, powiadomienia itp.). Notatka
że pakiet ponownie uruchomiony nie odbiera tego
audycja. Dane zawierają nazwę
pakiet.
Działanie nadawania: niektórzy dostawcy treści mają
części ich przestrzeni nazw, w których publikują nowe
Action_Provider_Changed
zdarzenia lub elementy, w których użytkownik może być szczególnie
zainteresowany.
Action_Screen_Off
Działanie nadawania: wysłane po wyłączeniu ekranu.
Action_Screen_on
Działanie nadawania: wysłane po włączeniu ekranu.
Działanie transmisji: Identyfikator użytkownika został usunięty
Action_uid_Removed
z systemu.
Działanie nadawania: urządzenie wprowadziło USB
Action_ums_Connected
Tryb przechowywania masy.

Akcja nadawcza: urządzenie opuściło USB
Action_ums_disconnected
Tryb przechowywania masy.
Działanie transmisji: wysłane, gdy użytkownik jest obecny
Action_user_present
Po przebudzeniu urządzenia (np., gdy jest kluczem
stracony).
Akcja nadawania: aktualna tapeta systemowa
Action_Wallpaper_Changed
zmienił się.
Action_Time_Changed
Akcja nadawcza: czas został ustalony.
Action_time_tick
Działanie nadawania: aktualny czas się zmienił.
Action_timeZone_Changed
Akcja nadawcza: strefa czasowa się zmieniła.
Działanie transmisji: stan ładowania lub opłata
Action_Battery_Changed
Poziom baterii zmienił się.
Działanie transmisji: Wskazuje niski stan akumulatora
Action_battery_low
na urządzeniu. Ta transmisja odpowiada
Okno dialogowe systemowe „niskie ostrzeżenie baterii”.
Akcja nadawania: Wskazuje, że bateria jest teraz w porządku
Po niskim poziomie. To zostanie wysłane
Action_battery_okay
po akcji_battery_low po baterii
wrócił do dobrego stanu.
Stan sieciowy
Intent Action
Opis
Rozgłoszenie działania, co wskazuje, że
Network_state_changed_Action
Zmieniła się łączność ze stanem Wi-Fi.
Rozgłoszenie działania, co wskazuje, że
RSSI_Changed_Action
RSSI (siła sygnału) zmieniła się.
Akcja nadawania, wskazując, że
Supticant_state_changed_action
połączenie z suplikantem było
ustalone lub utracone.
Akcja nadawania, wskazując, że Wi-Fi
Wifi_state_changed_action
został włączony, wyłączony, umożliwiający,
Wyłączanie lub nieznane.
Identyfikatory sieci skonfigurowanych sieci
Network_ids_changed_Action
mógł się zmienić.
Rozgłoszenie działania, co wskazuje, że
Action_background_Data_Setting_Changed Ustawienie dla użycia danych tła ma
zmienione wartości.
Zamiar transmisji wskazujący, że zmiana w
Łączność_Action
Wystąpiła łączność sieciowa.
Działanie nadawania: użytkownik zmienił
Action_Airplane_Mode_Changed
zadzwoń do trybu lub poza samolotem.

Dodatek C: Przyszłe rozważania Niniejszy dodatek wyjaśnia niektóre części tego Androida
1.6 Definicja kompatybilności, aw niektórych przypadkach omówiono przewidywane lub planowane zmiany przez
Przyszła wersja platformy Android. Ten dodatek jest przeznaczony wyłącznie do celów informacyjnych i planowania oraz
nie jest częścią definicji zgodności dla Androida 1.6.
1. Urządzenia nie-telefonowe
Android 1.6 jest przeznaczony wyłącznie na telefony; Funkcjonalność telefonii nie jest opcjonalna. Przyszłe wersje
Oczekuje się, że platforma z Androidem uczyni telefonię opcjonalną (a tym samym pozwoli na inne niż telefon Android
urządzenia), ale tylko telefony są kompatybilne z Android 1.6.
2. Kompatybilność Bluetooth
Wydanie Androida 1.6 Androida nie obsługuje interfejsów API Bluetooth, więc z perspektywy kompatybilności
Bluetooth nie nakłada żadnych rozważań dla tej wersji platformy. Jednak przyszła wersja
Androida wprowadzi interfejsy API Bluetooth. W tym momencie wsparcie Bluetooth stanie się obowiązkowe
zgodność.
W związku z tym zdecydowanie zalecamy, aby urządzenia z Android 1.6 zawierały Bluetooth, aby były
Kompatybilny z przyszłymi wersjami Androida, które wymagają Bluetooth.
3. Wymagane komponenty sprzętowe
Wszystkie komponenty sprzętowe w rozdziale 8 (w tym Wi -Fi, magnetometr/kompas, akcelerometr itp.) Są
wymagane i nie można go pominąć. Oczekuje się, że przyszłe wersje Androida sprawi, że niektóre (ale nie wszystkie) z
Te elementy opcjonalne, w tandemie z odpowiednimi narzędziami dla twórców stron trzecich, aby je obsłużyć
zmiany.
4. Przykładowe aplikacje
Dokument definicji kompatybilności dla przyszłej wersji Androida będzie obejmował bardziej obszerny i
Reprezentatywna lista aplikacji niż te wymienione w sekcji 4 powyżej. Na Androida 1.6,
Należy przetestować aplikacje wymienione w sekcji 4.
5. Dotknij ekranów
Przyszłe wersje definicji kompatybilności mogą, ale nie muszą pozwolić na pominięcie urządzeń dotykowych.
Jednak obecnie znaczna część wdrożenia Android Framework zakłada istnienie
ekran dotykowy; pominięcie ekranu dotykowego złamałoby zasadniczo wszystkie aktualne aplikacje na Androida, które są
Tak więc w Android 1.6 wymagany jest ekran dotykowy dla kompatybilności.

6. Wydajność
Przyszłe wersje CTS mierzą również wykorzystanie procesora i wydajność następujących
Składniki implementacji:
• Grafika 2D
• Grafika 3D
• Odtwarzanie wideo
• Odtwarzanie audio
• Odtwarzanie Bluetooth A2DP

Definicja zgodności z Androidem 1.6

Zarys dokumentu