Android 2.3 Uyumluluk Tanımlaması

Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

Telif hakkı © 2010, Google Inc. Tüm hakları saklıdır.
compatibility@android.com

İçindekiler

1. Giriş

Bu belgede, cep telefonlarının Android 2.3 ile uyumlu olması için karşılanması gereken şartlar listelenmiştir.

"Zorunlu", "Zorunlu değil", "Gerekli", "Olmalıdır", "Olmamalıdır", "Olması gerekir", "Olmaması gerekir", "Önerilen", "Olabilir" ve "İsteğe bağlı" ifadeleri RFC2119 [Kaynaklar, 1] belgesinde tanımlanan IETF standardına göre kullanılmalıdır.

Bu dokümanda "cihaz uygulayıcısı" veya "uygulayıcı", Android 2.3 çalıştıran bir donanım/yazılım çözümü geliştiren kişi veya kuruluştur. "Cihaz uygulaması" veya "uygulama", bu şekilde geliştirilen donanım/yazılım çözümüdür.

Android 2.3 ile uyumlu olarak kabul edilmek için cihaz uygulamalarının, referansla dahil edilen tüm dokümanlar da dahil olmak üzere bu Uyumluluk Tanımı'nda sunulan şartları karşılaması GEREKİR.

Bu tanım veya 10. Bölüm'de açıklanan yazılım testleri net değilse, belirsizse ya da eksikse mevcut uygulamalarla uyumluluğu sağlamak cihaz uygulayıcının sorumluluğundadır. Bu nedenle Android Açık Kaynak Projesi [Kaynaklar, 3], Android'in hem referans hem de tercih edilen uygulamasıdır. Cihaz uygulayıcılarının, uygulamalarını mümkün olduğunca Android Açık Kaynak Projesi'nden edinilebilen "yukarı yönlü" kaynak koda dayandırmaları önemle tavsiye edilir. Bazı bileşenler teorik olarak alternatif uygulamalarla değiştirilebilir olsa da yazılım testlerini geçmek önemli ölçüde daha zor olacağından bu uygulamadan kesinlikle kaçınılmalıdır. Uyumluluk Testi Paketi dahil ve hariç olmak üzere standart Android uygulamasıyla davranışsal olarak tam uyumluluğu sağlamak uygulayıcının sorumluluğundadır. Son olarak, belirli bileşen değişimlerinin ve modifikasyonlarının bu dokümanda açıkça yasaklandığını unutmayın.

Bu Uyumluluk Tanımı'nın, Android'deki 2.3.3 güncellemesine (API düzeyi 10) karşılık gelecek şekilde yayınlandığını lütfen unutmayın. Bu Tanım, 2.3.3'ten önceki Android 2.3 sürümleri için Uyumluluk Tanımını geçersiz kılar ve onun yerini alır. (Yani 2.3.1 ve 2.3.2 sürümleri kullanımdan kaldırılmıştır.) Android 2.3 çalıştıran gelecekteki Android uyumlu cihazlar 2.3.3 veya sonraki bir sürümle birlikte gönderilmelidir.

2. Kaynaklar

1. IETF RFC2119 Şart Düzeyleri: http://www.ietf.org/rfc/rfc2119.txt
2. Android Uyumluluk Programı'na Genel Bakış: http://source.android.com/docs/compatibility/index.html
3. Android Açık Kaynak Projesi: http://source.android.com/
4. API tanımları ve dokümanları: http://developer.android.com/reference/packages.html
5. Android izinleri referansı: http://developer.android.com/reference/android/Manifest.permission.html
6. android.os.Build referansı: http://developer.android.com/reference/android/os/Build.html
7. Android 2.3'te izin verilen sürüm dizeleri: http://source.android.com/docs/compatibility/2.3/versions.html
8. android.webkit.WebView sınıfı: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. HTML5 çevrimdışı özellikleri: http://dev.w3.org/html5/spec/Overview.html#offline
11. HTML5 video etiketi: http://dev.w3.org/html5/spec/Overview.html#video
12. HTML5/W3C coğrafi konum API'si: http://www.w3.org/TR/geolocation-API/
13. HTML5/W3C web veritabanı API'si: http://www.w3.org/TR/webdatabase/
14. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
15. Dalvik sanal makinesi spesifikasyonu: Android kaynak kodunda, dalvik/docs adresinde mevcuttur.
16. Uygulama widget'ları: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
17. Bildirimler: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
18. Uygulama Kaynakları: http://code.google.com/android/reference/available-resources.html
19. Durum çubuğu simgesi stil kılavuzu: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
20. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
21. Bildirimler: http://developer.android.com/reference/android/widget/Toast.html
22. Animasyonlu Duvar Kağıtları: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
23. Referans araç dokümanları (adb, aapt, ddms için): http://developer.android.com/guide/developing/tools/index.html
24. Android apk dosyası açıklaması: http://developer.android.com/guide/topics/fundamentals.html
25. Manifest dosyaları: http://developer.android.com/guide/topics/manifest/manifest-intro.html
26. Maymun test aracı: https://developer.android.com/studio/test/other-testing-tools/monkey
27. Android Donanım Özellikleri Listesi: http://developer.android.com/reference/android/content/pm/PackageManager.html
28. Birden fazla ekranı destekleme: http://developer.android.com/guide/practices/screens_support.html
29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
31. Sensör koordinat alanı: http://developer.android.com/reference/android/hardware/SensorEvent.html
32. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
33. NDEF Push Protokolü: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
40. Kamera yönü API'si: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
42. Android Güvenlik ve İzinler referansı: http://developer.android.com/guide/topics/security/security.html
43. Android için Uygulamalar: http://code.google.com/p/apps-for-android

Bu kaynakların çoğu doğrudan veya dolaylı olarak Android 2.3 SDK'sından türetilmiştir ve işlevsel olarak bu SDK'nın dokümanlarında yer alan bilgilerle aynıdır. Bu Uyumluluk Tanımlama Belgesi'nin veya Uyumluluk Testi Paketi'nin SDK dokümanlarıyla çeliştiği durumlarda SDK dokümanları yetkili kabul edilir. Yukarıda yer alan referanslarda sağlanan tüm teknik ayrıntılar, bu Uyumluluk Tanımı'nın bir parçası olarak kabul edilir.

3. Yazılım

Android platformu, yönetilen API'ler, yerel API'ler ve Intent sistemi ile web uygulaması API'leri gibi "yumuşak" API'lerden oluşur. Bu bölümde, uyumluluğun ayrılmaz parçası olan zorunlu ve isteğe bağlı API'lerin yanı sıra diğer bazı ilgili teknik ve kullanıcı arayüzü davranışları ayrıntılı olarak açıklanmaktadır. Cihaz uygulamaları bu bölümdeki tüm şartlara UYGUN OLMALIDIR.

3.1. Yönetilen API Uyumluluğu

Yönetilen (Dalvik tabanlı) yürütme ortamı, Android uygulamalarının birincil aracıdır. Android uygulama programlama arayüzü (API), yönetilen sanal makine ortamında çalışan uygulamalara sunulan Android platform arayüzleri grubudur. Cihaz uygulamalarında, Android 2.3 SDK'sı tarafından kullanıma sunulan tüm belgelenmiş API'lerin (Kaynaklar, 4) belgelenmiş tüm davranışları da dahil olmak üzere eksiksiz uygulamalar sağlanmalıdır.

Cihaz uygulamalarında, bu Uyumluluk Tanımı'nda özellikle izin verildiği durumlar hariç olmak üzere yönetilen API'ler atlanmamalı, API arayüzleri veya imzaları değiştirilmemeli, belirtilen davranıştan sapılmamalı ya da işlem yapmama işlemleri dahil edilmemelidir.

Bu Uyumluluk Tanımı, Android'in API'leri içeren bazı donanım türlerinin cihaz uygulamaları tarafından atlanmasına izin verir. Bu gibi durumlarda API'ler mevcut olmalı ve makul bir şekilde davranmalıdır. Bu senaryoya özgü gereksinimler için 7. bölüme bakın.

3.2. Soft API Uyumluluğu

Android, 3.1 Bölümü'ndeki yönetilen API'lere ek olarak, Android uygulamalarının derleme sırasında uygulanamayan Intent'ler, izinler ve benzer özellikleri gibi yalnızca çalışma zamanında önemli bir "yumuşak" API içerir. Bu bölümde, Android 2.3 ile uyumluluk için gereken "soft" API'ler ve sistem davranışları ayrıntılı olarak açıklanmıştır. Cihaz uygulamalarının bu bölümde sunulan tüm koşulları karşılaması GEREKİR.

3.2.1. İzinler

Cihaz uygulayıcıları, izin referans sayfasında [Kaynaklar, 5] belirtildiği gibi tüm izin sabitlerini desteklemeli ve uygulamalıdır. 10. Bölüm'de Android güvenlik modeliyle ilgili ek şartların listelendiğini unutmayın.

3.2.2. Derleme Parametreleri

Android API'leri, android.os.Build sınıfında [Resources, 6] mevcut cihazı tanımlamak için tasarlanmış bir dizi sabit içerir. Cihaz uygulamalarında tutarlı ve anlamlı değerler sağlamak için aşağıdaki tabloda, cihaz uygulamalarının UYGUN OLMASI GEREKEN bu değerlerin biçimleriyle ilgili ek kısıtlamalar yer almaktadır.

Parametre	Yorumlar
android.os.Build.VERSION.RELEASE	Şu anda çalışan Android sisteminin, kullanıcılar tarafından okunabilir biçimdeki sürümü. Bu alanda [Kaynaklar, 7] bölümünde tanımlanan dize değerlerinden biri bulunmalıdır.
android.os.Build.VERSION.SDK	Şu anda çalışan Android sisteminin sürümü (üçüncü taraf uygulama kodunun erişebileceği bir biçimde). Android 2.3 için bu alanda 9 tam sayı değeri OLMALIDIR.
android.os.Build.VERSION.INCREMENTAL	Cihaz uygulayıcısı tarafından seçilen ve o anda çalışan Android sisteminin belirli derlemesini kullanıcılar tarafından okunabilir biçimde belirten bir değer. Bu değer, son kullanıcılara sunulan farklı derlemeler için yeniden KULLANILAMAZ. Bu alanın tipik bir kullanımı, derlemeyi oluşturmak için hangi derleme numarasının veya kaynak denetimi değişiklik tanımlayıcısının kullanıldığını belirtmektir. Bu alanın biçimiyle ilgili herhangi bir koşul yoktur. Ancak alanın boş dize ("") veya null değer OLMAMASI gerekir.
android.os.Build.BOARD	Cihaz uygulayıcısı tarafından seçilen ve cihaz tarafından kullanılan belirli dahili donanımı kullanıcı tarafından okunabilir biçimde tanımlayan bir değer. Bu alanın olası bir kullanımı, cihazı besleyen kartın belirli bir revizyonunu belirtmektir. Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir.
android.os.Build.BRAND	Cihazı üreten şirketin, kuruluşun, şahsın vb. adını kullanıcı tarafından okunabilir biçimde tanımlayan, cihaz uygulayıcısı tarafından seçilen bir değer. Bu alanın olası bir kullanımı, cihazı satan OEM'i ve/veya operatörü belirtmektir. Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir.
android.os.Build.DEVICE	Cihaz uygulayıcısı tarafından seçilen ve cihazın gövdesinin (bazen "endüstriyel tasarım" olarak da adlandırılır) belirli yapılandırmasını veya düzeltmesini tanımlayan bir değer. Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir.
android.os.Build.FINGERPRINT	Bu derlemeyi benzersiz şekilde tanımlayan bir dize. Makul ölçüde okunaklı OLMALIDIR. Şu şablonu İZLEMELİYDİR: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Örneğin: acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys Parmak izi boşluk karakterleri İÇERMEMELİDİR. Yukarıdaki şablona dahil edilen diğer alanlarda boşluk karakterleri varsa derleme parmak izinde alt çizgi ("_") karakteri gibi başka bir karakterle DEĞİŞTİRİLMESİ GEREKİR. Bu alanın değeri 7 bit ASCII olarak kodlanabilir OLMALIDIR.
android.os.Build.HOST	Derlemenin oluşturulduğu ana makineyi benzersiz şekilde tanımlayan, kullanıcı tarafından okunabilir biçimde bir dize. Bu alanın biçimiyle ilgili herhangi bir koşul yoktur. Ancak alanın boş veya boş dize ("") OLMAMASI gerekir.
android.os.Build.ID	Cihaz uygulayıcısı tarafından, belirli bir sürümü belirtmek için kullanıcı tarafından okunabilir biçimde seçilen bir tanımlayıcı. Bu alan, android.os.Build.VERSION.INCREMENTAL ile aynı olabilir ancak son kullanıcıların yazılım derlemeleri arasında ayrım yapması için yeterince anlamlı bir değer OLMALIDIR. Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir.
android.os.Build.MODEL	Cihaz uygulayıcısı tarafından seçilen ve son kullanıcının bildiği cihaz adını içeren bir değer. Bu, cihazın pazarlandığı ve son kullanıcılara satıldığı adla aynı OLMALIDIR. Bu alanın biçimiyle ilgili herhangi bir koşul yoktur. Bununla birlikte, alanın boş veya boş dize ("") OLMAMASI ZORUNLUDUR.
android.os.Build.PRODUCT	Cihaz uygulayıcısı tarafından seçilen ve cihazın geliştirme adını veya kod adını içeren bir değer. Kullanıcılar tarafından okunabilir OLMALIDIR ancak son kullanıcıların görüntülemesi için tasarlanmayabilir. Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir.
android.os.Build.TAGS	Cihaz uygulayıcısı tarafından seçilen ve derlemeyi daha da ayırt edici hale getiren, virgülle ayrılmış bir etiket listesi. Örneğin, "unsigned,debug". Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir.
android.os.Build.TIME	Derlemenin gerçekleştiği zamanın zaman damgasını temsil eden bir değer.
android.os.Build.TYPE	Derlemenin çalışma zamanı yapılandırmasını belirten, cihaz uygulayıcısı tarafından seçilen bir değer. Bu alanda, üç tipik Android çalışma zamanı yapılandırmasına karşılık gelen değerlerden biri OLMALIDIR: "user", "userdebug" veya "eng". Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir.
android.os.Build.USER	Derlemeyi oluşturan kullanıcının (veya otomatik kullanıcının) adı veya kullanıcı kimliği. Bu alanın biçimiyle ilgili herhangi bir koşul yoktur. Ancak alanın boş veya boş dize ("") OLMAMASI gerekir.

3.2.3. Intent Uyumluluğu

Android, uygulamalar arasında gevşek bağlı entegrasyon elde etmek için Intent'leri kullanır. Bu bölümde, cihaz uygulamalarının uyması GEREKEN Intent kalıplarıyla ilgili şartlar açıklanmaktadır. "Uygulanır" ifadesi, cihaz uygulayıcının eşleşen bir Intent filtresi belirten ve belirtilen her Intent kalıbı için doğru davranışı bağlayan ve uygulayan bir Android Etkinliği veya Hizmeti sağlaması GEREKTİĞİ anlamına gelir.

3.2.3.1. Temel Uygulama Amaçları

Android yayın öncesi projesi, telefon çevirici, takvim, kişi defteri, müzik çalar gibi çeşitli temel uygulamaları tanımlar. Cihaz uygulayıcıları bu uygulamaları alternatif sürümlerle DEĞİŞTİREBİLİR.

Ancak bu tür alternatif sürümler, yayın öncesi proje tarafından sağlanan aynı Intent kalıplarını UYGUNLAŞTIRMALIDIR. Örneğin, bir cihazda alternatif bir müzik çalar varsa şarkı seçmek için üçüncü taraf uygulamaları tarafından yayınlanan Intent kalıbını yine de dikkate almalıdır.

Aşağıdaki uygulamalar temel Android sistem uygulamaları olarak kabul edilir:

• Masa Saati
• Tarayıcı
• Takvim
• Hesap Makinesi
• Kişiler
• E-posta
• Galeri
• GlobalSearch
• Roketatar
• Müzik
• Ayarlar

Temel Android sistem uygulamaları, "herkese açık" olarak kabul edilen çeşitli etkinlik veya hizmet bileşenleri içerir. Yani "android:exported" özelliği bulunmayabilir veya "true" değerine sahip olabilir.

Temel Android sistem uygulamalarından birinde tanımlanan ve "false" değerine sahip bir android:exported özelliği aracılığıyla herkese açık olmayan olarak işaretlenmeyen her etkinlik veya hizmet için cihaz uygulamalarında, temel Android sistem uygulamasıyla aynı Intent filtresi kalıplarını uygulayan aynı türde bir bileşen BULUNMASI GEREKİR.

Diğer bir deyişle, cihaz uygulaması temel Android sistem uygulamalarını DEĞİŞTİREBİLİR. Ancak bu durumda, cihaz uygulaması, değiştirilen her temel Android sistem uygulaması tarafından tanımlanan tüm Intent kalıplarını DESTEKLEMELİDİR.

3.2.3.2. Intent Geçersiz Kılmaları

Android genişletilebilir bir platform olduğundan cihaz uygulayıcıları, 3.2.3.1 Bölümü'nde atıfta bulunulan her Intent kalıbının üçüncü taraf uygulamaları tarafından geçersiz kılınmasına İZİN VERMELİDİR. Yukarı yönlü Android açık kaynak projesi buna varsayılan olarak izin verir. Cihaz uygulayıcıları, sistem uygulamalarının bu Intent kalıplarını kullanmasına özel ayrıcalıklar eklememeli veya üçüncü taraf uygulamalarının bu kalıplara bağlanmasını ve bu kalıpların kontrolünü devralmasını engellememelidir. Bu yasak, özellikle kullanıcının aynı Intent kalıbını işleyen birden fazla uygulama arasında seçim yapmasına olanak tanıyan "Seçici" kullanıcı arayüzünün devre dışı bırakılmasını içerir ancak bunlarla sınırlı değildir.

3.2.3.3. Intent Ad Alanları

Cihaz uygulayıcıları, android.* ad alanındaki bir ACTION, CATEGORY veya başka bir anahtar dizesi kullanarak yeni Intent veya Broadcast Intent kalıplarını dikkate alan herhangi bir Android bileşeni İÇERMEMELİDİR. Cihaz uygulayıcıları, başka bir kuruluşa ait bir paket alanında ACTION, CATEGORY veya başka bir anahtar dizesi kullanarak yeni Intent veya Broadcast Intent kalıplarını destekleyen Android bileşenleri İÇERMEMELİDİR. Cihaz uygulayıcıları, 3.2.3.1 numaralı bölümde listelenen temel uygulamalar tarafından kullanılan Intent kalıplarından hiçbirini DEĞİŞTİRMELİ veya GENİŞLETMEMELİDİR.

Bu yasak, Bölüm 3.6'da Java dil sınıfları için belirtilene benzer.

3.2.3.4. Yayın Amaçları

Üçüncü taraf uygulamaları, donanım veya yazılım ortamındaki değişiklikler hakkında bilgilendirilmek için belirli Intent'leri yayınlamak üzere platformdan yararlanır. Android uyumlu cihazlar, uygun sistem etkinliklerine yanıt olarak herkese açık yayın Intent'lerini YAYINLAMALIDIR. Yayın intent'leri SDK dokümanlarında açıklanmaktadır.

3.3. Yerel API Uyumluluğu

Dalvik'te çalışan yönetilen kod, uygulama .apk dosyasında uygun cihaz donanım mimarisi için derlenmiş bir ELF .so dosyası olarak sağlanan yerel kodu çağırabilir. Yerel kod, temel işlemci teknolojisine oldukça bağlı olduğundan Android, Android NDK'da docs/CPU-ARCH-ABIS.txt dosyasında bir dizi Uygulama İkili Arabirimi (ABI) tanımlar. Bir cihaz uygulaması bir veya daha fazla tanımlanmış ABI ile uyumluysa aşağıdaki gibi Android NDK ile uyumluluğu UYGULAMALIDIR.

Bir cihaz uygulaması, Android ABI'si desteği içeriyorsa:

• Standart Java Native Interface (JNI) semantikleri kullanılarak yönetilen ortamda çalışan kodun yerel koda çağrılması için destek DAHİL OLMALIDIR.
• Aşağıdaki listedeki her gerekli kitaplıkla kaynak uyumlu (ör. başlık uyumlu) ve ikili uyumlu (ABI için) OLMALIDIR
• Cihaz tarafından desteklenen yerel Uygulama İkili Arabirimi'ni (ABI) android.os.Build.CPU_ABI API üzerinden doğru şekilde bildirmelidir.
• Yalnızca Android NDK'nın en son sürümünde, docs/CPU-ARCH-ABIS.txt dosyasında belgelenen ABI'leri bildirmelidir.
• Yukarı akış Android açık kaynak projesinde bulunan kaynak kod ve başlık dosyaları kullanılarak OLUŞTURULMALIDIR

Aşağıdaki yerel kod API'leri, yerel kod içeren uygulamalar tarafından KULLANILABİLİR OLMALIDIR:

• libc (C kitaplığı)
• libm (matematik kitaplığı)
• C++ için minimum destek
• JNI arayüzü
• liblog (Android günlük kaydı)
• libz (Zlib sıkıştırması)
• libdl (dinamik bağlayıcı)
• libGLESv1_CM.so (OpenGL ES 1.0)
• libGLESv2.so (OpenGL ES 2.0)
• libEGL.so (yerel OpenGL yüzey yönetimi)
• libjnigraphics.so
• libOpenSLES.so (Open Sound Library ses desteği)
• libandroid.so (yerel Android etkinliği desteği)
• Aşağıda açıklandığı şekilde OpenGL desteği

Android NDK'nın gelecekteki sürümlerinde ek ABI'ler için destek sunulabileceğini unutmayın. Bir cihaz uygulaması, mevcut bir önceden tanımlanmış ABI ile uyumlu değilse hiçbir ABI için destek bildirmemelidir.

Yerel kod uyumluluğu zordur. Bu nedenle, cihaz uygulayıcılarının uyumluluğu sağlamak için yukarıda listelenen kitaplıkların yayın öncesi uygulamalarını kullanmalarının ÇOK önemle tavsiye edildiği tekrar vurgulanmalıdır.

3.4. Web Uyumluluğu

Birçok geliştirici ve uygulama, kullanıcı arayüzleri için android.webkit.WebView sınıfının [Resources, 8] davranışını kullandığından Web Görünümü uygulaması, Android uygulamalarıyla uyumlu olmalıdır. Benzer şekilde, eksiksiz ve modern bir web tarayıcısı da Android kullanıcı deneyiminin merkezinde yer alır. Cihaz uygulamalarında, yayın öncesi Android yazılımıyla tutarlı bir android.webkit.WebView sürümü VE aşağıda açıklandığı gibi modern bir HTML5 uyumlu tarayıcı bulunmalıdır.

3.4.1. WebView Uyumluluğu

Android Açık Kaynak uygulaması, android.webkit.WebView'ü uygulamak için WebKit oluşturma motorunu kullanır. Bir web oluşturma sistemi için kapsamlı bir test paketi geliştirmek mümkün olmadığından cihaz uygulayıcıları, WebView uygulamasında WebKit'in belirli bir yayın öncesi derlemesini KULLANMAK ZORUNDADIR. Özellikle:

• Cihaz uygulamalarının android.webkit.WebView uygulamaları, Android 2.3 için yayındaki Android Açık Kaynak ağacındaki 533.1 WebKit derlemesini temel ALMALIDIR. Bu derleme, Web Görünümü için belirli bir işlev ve güvenlik düzeltmeleri grubu içerir. Cihaz uygulayıcıları WebKit uygulamasına özelleştirmeler EKLEYEBİLİR ancak bu tür özelleştirmeler, oluşturma davranışı da dahil olmak üzere Web Görünümü'nün davranışını DEĞİŞTİRMEMELİDİR.
• WebView tarafından bildirilen kullanıcı aracısı dizesi şu biçimde OLMALIDIR:
  Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
  • $(VERSION) dizesinin değeri android.os.Build.VERSION.RELEASE değeriyle AYNI OLMALIDIR
  • $(LOCALE) dizesinin değeri, ülke kodu ve dil için ISO kurallarına uymalı ve cihazın mevcut yapılandırılmış yerel ayarını belirtmelidir.
  • $(MODEL) dizesinin değeri android.os.Build.MODEL değeriyle AYNI OLMALIDIR.
  • $(BUILD) dizesinin değeri android.os.Build.ID değeriyle AYNI OLMALIDIR

WebView bileşeni, HTML5'in mümkün olduğunca büyük bir kısmını [Kaynaklar, 9] desteklemelidir. Cihaz uygulamalarının, WebView'de HTML5 ile ilişkili aşağıdaki API'lerin her birini en azından desteklemesi GEREKİR:

• application cache/offline operation [Resources, 10]
• <video> etiketi [Kaynaklar, 11]
• geolocation [Resources, 12]

Ayrıca, cihaz uygulamaları HTML5/W3C webstorage API'yi [Kaynaklar, 13] destekleMELİ ve HTML5/W3C IndexedDB API'yi [Kaynaklar, 14] DESTEKLEMELİDİR. Web geliştirme standartları kuruluşları web depolama yerine IndexedDB'i tercih etmeye başladığından, IndexedDB'in Android'in gelecekteki bir sürümünde zorunlu bir bileşen haline gelmesinin beklendiğini unutmayın.

Tüm JavaScript API'leri gibi HTML5 API'leri de, geliştirici tarafından normal Android API'leri aracılığıyla açıkça etkinleştirilmediği sürece WebView'de varsayılan olarak devre dışı bırakılmalıdır.

3.4.2. Tarayıcı Uyumluluğu

Cihaz uygulamalarında, genel kullanıcıların web'de gezinmesi için bağımsız bir tarayıcı uygulaması BULUNMASI GEREKİR. Bağımsız tarayıcı, WebKit dışında bir tarayıcı teknolojisine dayalı OLABİLİR. Ancak alternatif bir Tarayıcı uygulaması kullanılsa bile üçüncü taraf uygulamalarına sağlanan android.webkit.WebView bileşeni, 3.4.1 numaralı bölümde açıklandığı gibi WebKit'e dayalı OLMALIDIR.

Uygulamalar, bağımsız tarayıcı uygulamasında özel bir kullanıcı aracısı dizesi GÖNDERMEYEBİLİR.

Bağımsız Tarayıcı uygulaması (üst akış WebKit Tarayıcı uygulamasına veya üçüncü taraf bir değişime dayalı olsun) mümkün olduğunca fazla HTML5 [Kaynaklar, 9] desteği İÇERMELİDİR. Cihaz uygulamalarının, HTML5 ile ilişkili aşağıdaki API'lerin her birini en azından desteklemesi GEREKİR:

• application cache/offline operation [Resources, 10]
• <video> etiketi [Kaynaklar, 11]
• geolocation [Resources, 12]

Ayrıca, cihaz uygulamaları HTML5/W3C webstorage API'yi [Kaynaklar, 13] destekleMELİ ve HTML5/W3C IndexedDB API'yi [Kaynaklar, 14] destekleMELİDİR. Web geliştirme standartları kuruluşları web depolama yerine IndexedDB'i tercih etmeye başladığından, IndexedDB'in Android'in gelecekteki bir sürümünde zorunlu bir bileşen haline gelmesinin beklendiğini unutmayın.

3.5. API Davranış Uyumluluğu

API türlerinin her birinin (yönetilen, yumuşak, yerel ve web) davranışları, yayın öncesi Android açık kaynak projesinin tercih edilen uygulamasıyla tutarlı olmalıdır [Kaynaklar, 3]. Uyumluluğun bazı belirli alanları şunlardır:

• Cihazlar, standart bir Intent'in davranışını veya anlamını DEĞİŞTİREMEZ.
• Cihazlar, belirli bir sistem bileşeni türünün (ör. Hizmet, Etkinlik, İçerik Sağlayıcı vb.) yaşam döngüsünü veya yaşam döngüsü anlamlarını DEĞİŞTİRMEMELİDİR.
• Cihazlar, standart bir iznin anlamını DEĞİŞTİREMEZ

Yukarıdaki listede olası her duruma yer verilmemiştir. Uyumluluk Test Paketi (CTS), platformun önemli bölümlerini davranışsal uyumluluk açısından test eder ancak tümünü test etmez. Android Open Source Project ile davranışsal uyumluluğu sağlamak uygulayıcının sorumluluğundadır. Bu nedenle, cihaz uygulayıcıları sistemin önemli bölümlerini yeniden uygulamak yerine mümkün olduğunda Android Açık Kaynak Projesi aracılığıyla sunulan kaynak kodu KULLANMALIDIR.

3.6. API ad alanları

Android, Java programlama dili tarafından tanımlanan paket ve sınıf ad alanı kurallarına uyar. Cihaz uygulayıcıları, üçüncü taraf uygulamalarla uyumluluğu sağlamak için aşağıdaki paket ad alanlarında yasaklanmış herhangi bir değişiklik YAPMAMALIDIR:

• java.*
• javax.*
• güneş.*
• android.*
• com.android.*

Yasaklanan değişiklikler şunlardır:

• Cihaz uygulamaları, herhangi bir yöntem veya sınıf imzasını değiştirerek ya da sınıfları veya sınıf alanlarını kaldırarak Android platformunda herkese açık olarak sunulan API'lerde değişiklik YAPMAMALIDIR.
• Cihaz uygulayıcıları, API'lerin temel uygulamasını DEĞİŞTİREBİLİR ancak bu tür değişiklikler, herkese açık olarak sunulan API'lerin belirtilen davranışını ve Java dili imzasını ETKİLEMEmelidir.
• Cihaz uygulayıcıları, yukarıdaki API'lere herkese açık öğeler (ör. sınıflar veya arayüzler ya da mevcut sınıflara veya arayüzlere ait alanlar ya da yöntemler) EKLEMEMELİDİR.

"Herkese açık olarak sunulan öğe", yayın öncesi Android kaynak kodunda kullanılan "@hide" işaretçisiyle süslenmemiş tüm yapılardır. Diğer bir deyişle, cihaz uygulayıcıları yukarıda belirtilen ad alanlarında yeni API'ler göstermemeli veya mevcut API'leri değiştirmemelidir. Cihaz uygulayıcıları yalnızca dahili değişiklikler YAPABİLİR ancak bu değişikliklerin reklamı YAPILMAMALI veya geliştiricilere başka bir şekilde gösterilMEMELİDİR.

Cihaz uygulayıcıları özel API'ler EKLEYEBİLİYOR ancak bu tür API'ler başka bir kuruluşa ait veya başka bir kuruluşa atıfta bulunan bir ad alanında OLMAYACAK. Örneğin, cihaz uygulayıcıları com.google.* veya benzer bir ad alanına API ekleMEmelidir; bunu yalnızca Google yapabilir. Benzer şekilde, Google da diğer şirketlerin ad alanlarına API ekleMEmelidir. Ayrıca, bir cihaz uygulaması standart Android ad alanının dışında özel API'ler içeriyorsa bu API'ler, yalnızca açıkça kullanan uygulamaların (<uses-library> mekanizması aracılığıyla) bu API'lerin artan bellek kullanımından etkilenmesi için bir Android paylaşılan kitaplığına paketlenmelidir.

Bir cihaz uygulayıcısı yukarıdaki paket ad alanlarının birini iyileştirmeyi önerirse (ör. mevcut bir API'ye yararlı yeni işlevler ekleyerek veya yeni bir API ekleyerek) uygulayıcının source.android.com adresini ziyaret etmesi ve bu sitedeki bilgilere göre değişiklik ve kod katkıda bulunma sürecini başlatması GEREKİR.

Yukarıdaki kısıtlamaların, Java programlama dilinde API'leri adlandırmayla ilgili standart kurallara karşılık geldiğini unutmayın. Bu bölüm, bu kuralları pekiştirmeyi ve bu uyumluluk tanımına dahil ederek bağlayıcı hale getirmeyi amaçlamaktadır.

3.7. Sanal Makine Uyumluluğu

Cihaz uygulamaları, Dalvik Executable (DEX) bayt kodu spesifikasyonunun tamamını ve Dalvik sanal makine anlamlarını [Kaynaklar, 15] desteklemelidir.

Orta veya düşük yoğunlukta olarak sınıflandırılan ekranlara sahip cihaz uygulamalarında, Dalvik'in her uygulamaya en az 16 MB bellek ayıracak şekilde yapılandırılması GEREKİR. Yüksek yoğunluklu veya ekstra yüksek yoğunluklu olarak sınıflandırılan ekranlara sahip cihaz uygulamalarında, Dalvik'in her uygulamaya en az 24 MB bellek ayıracak şekilde yapılandırılması GEREKİR. Cihaz uygulamalarının bu rakamlardan daha fazla bellek ayırabileceğini unutmayın.

3.8. Kullanıcı Arayüzü Uyumluluğu

Android platformu, geliştiricilerin sistem kullanıcı arayüzüne bağlanmasına olanak tanıyan bazı geliştirici API'leri içerir. Cihaz uygulamalarında, aşağıda açıklandığı gibi bu standart kullanıcı arayüzü API'leri, geliştirilen özel kullanıcı arayüzlerine DAHİL EDİLMELİDİR.

3.8.1. Widget'lar

Android, uygulamaların son kullanıcıya "AppWidget" göstermesine olanak tanıyan bir bileşen türü ve ilgili API ile yaşam döngüsü tanımlar [Kaynaklar, 16]. Android Açık Kaynak referans sürümü, kullanıcının ana ekrana AppWidget eklemesine, görüntülemesine ve kaldırmasına olanak tanıyan kullanıcı arayüzü öğeleri içeren bir Başlatıcı uygulaması içerir.

Cihaz uygulayıcıları, referans başlatıcıya (ör. ana ekran) alternatif bir seçenek KULLANABİLİR. Alternatif başlatıcılar, uygulama widget'ları için yerleşik destek içermeli ve uygulama widget'larını doğrudan başlatıcıdan eklemek, yapılandırmak, görüntülemek ve kaldırmak için kullanıcı arayüzü öğeleri sunmalıdır. Alternatif başlatıcılar bu kullanıcı arayüzü öğelerini EKSİLTİREBİLİR. Ancak bu öğeler atlanırsa cihaz uygulayıcısı, kullanıcıların AppWidget'ları eklemesine, yapılandırmasına, görüntülemesine ve kaldırmasına olanak tanıyan, başlatıcıdan erişilebilen ayrı bir uygulama sağlamalıdır.

3.8.2. Bildirimler

Android, geliştiricilerin kullanıcıları önemli etkinlikler hakkında bilgilendirmesine olanak tanıyan API'ler içerir [Kaynaklar, 17]. Cihaz uygulayıcıları, tanımlanan her bildirim sınıfı için destek sağlamalıdır. Özellikle: sesler, titreşim, ışık ve durum çubuğu.

Ayrıca, uygulamada API'lerde [Kaynaklar, 18] veya durum çubuğu simgesi stil kılavuzunda [Kaynaklar, 19] sağlanan tüm kaynaklar (simgeler, ses dosyaları vb.) doğru şekilde oluşturulmalıdır. Cihaz uygulayıcıları, bildirimler için referans Android açık kaynak uygulaması tarafından sağlanan alternatif bir kullanıcı deneyimi SUNABİLİR. Ancak bu tür alternatif bildirim sistemleri, yukarıda belirtildiği gibi mevcut bildirim kaynaklarını DESTEKLEMELİDİR.

3.8.3. Arat

Android, geliştiricilerin aramayı uygulamalarına dahil etmesine ve uygulamalarının verilerini küresel sistem aramasında göstermesine olanak tanıyan API'ler [Kaynaklar, 20] içerir. Genel olarak bu işlev, kullanıcıların sorgu girmelerine olanak tanıyan, kullanıcılar yazarken öneriler gösteren ve sonuçları gösteren tek bir sistem genelinde kullanıcı arayüzünden oluşur. Android API'leri, geliştiricilerin kendi uygulamalarında arama sağlamak için bu arayüzü yeniden kullanmalarına ve ortak küresel arama kullanıcı arayüzüne sonuç sağlamalarına olanak tanır.

Cihaz uygulamalarında, kullanıcı girişine yanıt olarak anlık öneriler sunabilen tek bir paylaşılan sistem genelinde arama kullanıcı arayüzü BULUNMASI GEREKİR. Cihaz uygulamalarında, geliştiricilerin kendi uygulamalarında arama sağlamak için bu kullanıcı arayüzünü yeniden kullanmalarına olanak tanıyan API'ler UYGULANMALIDIR. Cihaz uygulamalarında, üçüncü taraf uygulamalarının genel arama modunda çalıştırıldığında arama kutusuna öneri eklemesine olanak tanıyan API'ler UYGULANMALIDIR. Bu işlevi kullanan üçüncü taraf uygulaması yüklü değilse varsayılan davranış, web arama motoru sonuçlarını ve önerilerini göstermek OLMALIDIR.

Cihaz uygulamalarında alternatif arama kullanıcı arayüzleri bulunabilir ancak API dokümanlarında belirtilen davranışla birlikte arama çerçevesini çağırmak için herhangi bir uygulamada dilediğiniz zaman kullanılabilecek özel bir arama düğmesi bulunmalıdır.

3.8.4. Durum mesajları

Uygulamalar, son kullanıcıya kısa süre sonra kaybolan kısa, modal olmayan dizeler görüntülemek için "Toast" API'yi ([Kaynaklar, 21] bölümünde tanımlanmıştır) kullanabilir. Cihaz uygulamalarında, uygulamalardan son kullanıcılara gönderilen pop-up'lar yüksek görünür bir şekilde gösterilmelidir.

3.8.5. Animasyonlu Duvar Kağıtları

Android, uygulamaların son kullanıcıya bir veya daha fazla "canlı duvar kağıdı" göstermesine olanak tanıyan bir bileşen türü ve ilgili API ile yaşam döngüsü tanımlar [Kaynaklar, 22]. Canlı duvar kağıtları, diğer uygulamaların arkasında duvar kağıdı olarak görüntülenen, sınırlı giriş özelliklerine sahip animasyonlar, desenler veya benzer resimlerdir.

Donanım, tüm canlı duvar kağıtlarını işlevsellik açısından herhangi bir sınırlama olmadan, diğer uygulamalar üzerinde olumsuz bir etkisi olmadan makul bir kare hızında çalıştırabiliyorsa canlı duvar kağıtlarını güvenilir bir şekilde çalıştırabilir. Donanımdaki sınırlamalar, duvar kağıtlarının ve/veya uygulamaların kilitlenmesine, hatalı çalışmasına, aşırı CPU veya pil gücü tüketimine ya da kabul edilemeyecek kadar düşük kare hızlarında çalışmasına neden oluyorsa donanım, canlı duvar kağıdını çalıştıramaz. Örneğin, bazı canlı duvar kağıtları içeriklerini oluşturmak için Open GL 1.0 veya 2.0 bağlamı kullanabilir. OpenGL bağlamının canlı duvar kağıdı kullanımı, OpenGL bağlamı kullanan diğer uygulamalarla çakışabileceğinden canlı duvar kağıdı, birden fazla OpenGL bağlamını desteklemeyen donanımlarda güvenilir bir şekilde çalışmaz.

Yukarıda açıklandığı gibi canlı duvar kağıtlarını güvenilir bir şekilde çalıştırabilen cihaz uygulamaları canlı duvar kağıtlarını UYGULAMALIDIR. Yukarıda açıklandığı şekilde animasyonlu duvar kağıtlarını güvenilir bir şekilde çalıştıramayacağı belirlenen cihaz uygulamalarında animasyonlu duvar kağıtları uygulanmamalıdır.

4. Uygulama Paketleme Uyumluluğu

Cihaz uygulamaları, Android ".apk" dosyalarını resmi Android SDK'sına [Kaynaklar, 23] dahil olan "aapt" aracı tarafından oluşturulduğu şekilde yükleyip çalıştırmalıdır.

Cihaz uygulamalarında .apk [Kaynaklar, 24], Android Manifest [Kaynaklar, 25] veya Dalvik bayt kodu [Kaynaklar, 15] biçimleri, bu dosyaların diğer uyumlu cihazlarda doğru şekilde yüklenmesini ve çalışmasını engelleyecek şekilde UZATILMAMALIDIR. Cihaz uygulayıcıları, Dalvik'in referans yayın öncesi uygulamasını ve referans uygulamanın paket yönetim sistemini KULLANMALIDIR.

5. Multimedya Uyumluluğu

Cihaz uygulamalarında tüm multimedya API'leri eksiksiz şekilde uygulanmalıdır. Cihaz uygulamalarında aşağıda açıklanan tüm multimedya codec'leri için destek ZORUNLUDUR ve aşağıda açıklanan ses işleme yönergelerine UYGUN OLMALIDIR. Cihaz uygulamalarında hoparlör, kulaklık jakı, harici hoparlör bağlantısı gibi en az bir ses çıkışı biçimi BULUNMASI GEREKİR.

5.1. Medya codec'leri

Cihaz uygulamaları, aşağıdaki bölümlerde ayrıntılı olarak açıklanan multimedya codec'lerini DESTEKLEMELİDİR. Bu codec'lerin tümü, Android Açık Kaynak Projesi'ndeki tercih edilen Android uygulamasında yazılım uygulamaları olarak sağlanır.

Google veya Open Handset Alliance'ın bu codec'lerin üçüncü taraf patentleriyle ilgili herhangi bir beyanda bulunmadığını lütfen unutmayın. Bu kaynak kodunu donanım veya yazılım ürünlerinde kullanmak isteyenlerin, açık kaynak yazılım veya paylaşımlı yazılım da dahil olmak üzere bu kodun uygulanabilmesi için ilgili patent sahiplerinden patent lisansı almaları gerekebileceğini göz önünde bulundurmaları önerilir.

Aşağıdaki tablolarda, çoğu video codec'i için belirli bit hızı gereksinimleri listelenmez. Bunun nedeni, mevcut cihaz donanımlarının pratikte ilgili standartlar tarafından belirtilen gerekli bit hızlarıyla tam olarak eşleşen bit hızlarını desteklememesidir. Bunun yerine, cihaz uygulamalarında, donanımda mümkün olan en yüksek bit hızı (özelliklerle tanımlanan sınırlara kadar) DESTEKLENMELİDİR.

5.1.1. Medya Kod Çözücüler

Cihaz uygulamalarında, aşağıdaki tabloda açıklanan her codec ve biçim için bir kod çözücü uygulaması BULUNMASI GEREKİR. Bu medya türlerinin her biri için kod çözücülerin, yayın öncesi Android Açık Kaynak Projesi tarafından sağlandığını unutmayın.

Ses
	Ad	Ayrıntılar	Dosya/Kapsayıcı Biçimi
	AAC LC/LTP	160 kb/sn.'ye kadar standart bit hızları ve 8 ila 48 kHz arasındaki örnekleme hızlarının herhangi bir kombinasyonunda mono/stereo içerik	3GPP (.3gp) ve MPEG-4 (.mp4, .m4a). Ham AAC (.aac) desteklenmez.
	HE-AACv1 (AAC+)
	HE-AACv2 (gelişmiş AAC+)
	AMR-NB	8 kHz'te örneklenmiş 4,75 ila 12,2 Kb/sn	3GPP (.3gp)
	AMR-WB	16 kHz'te örneklenen 6,60 kbit/sn ile 23,85 kbit/sn arasında 9 hız	3GPP (.3gp)
	MP3	Mono/Stereo 8-320 Kb/sn sabit (CBR) veya değişken bit hızı (VBR)	MP3 (.mp3)
	MIDI	MIDI Türü 0 ve 1. DLS 1 ve 2 sürümü. XMF ve Mobil XMF. RTTTL/RTX, OTA ve iMelody zil sesi biçimleri için destek	0 ve 1 türü (.mid, .xmf, .mxmf). Ayrıca RTTTL/RTX (.rtttl, .rtx), OTA (.ota) ve iMelody (.imy)
	Ogg Vorbis		Ogg (.ogg)
	PCM : (always use short version (long version) in the first occurrence in any content)	8 ve 16 bit doğrusal PCM (donanım sınırına kadar hızlarda)	WAVE (.wav)
Resim
	JPEG	base+progressive
	GIF
	PNG
	BMP
Video
	H.263		3GPP (.3gp) dosyaları
	H.264		3GPP (.3gp) ve MPEG-4 (.mp4) dosyaları
	MPEG4 Basit Profili		3GPP (.3gp) dosyası

5.1.2. Medya kodlayıcılar

Cihaz uygulamalarında, Bölüm 5.1.1'de listelenen medya biçimlerinin mümkün olduğunca çoğu için kodlayıcılar YER ALMALIDIR. Ancak bazı kodlayıcılar, belirli isteğe bağlı donanımlara sahip olmayan cihazlarda işe yaramaz. Örneğin, cihazda kamera yoksa H.263 video kodlayıcısı işe yaramaz. Bu nedenle, cihaz uygulamaları medya kodlayıcıları aşağıdaki tabloda açıklanan koşullara göre UYGULAMALIDIR.

Donanımın cihaz uygulamaları tarafından atlanma koşulları hakkında ayrıntılı bilgi için 7. Bölümü inceleyin.

Ses
	Ad	Ayrıntılar	Dosya/Kapsayıcı Biçimi	Koşullar
	AMR-NB	8 kHz'te örneklenmiş 4,75 ila 12,2 Kb/sn	3GPP (.3gp)	Mikrofon donanımı içeren ve android.hardware.microphone tanımlayan cihaz uygulamaları BU ses biçimleri için kodlayıcılar İÇERMELİDİR.
	AMR-WB	16 kHz'te örneklenen 6,60 kbit/sn ile 23,85 kbit/sn arasında 9 hız	3GPP (.3gp)
	AAC LC/LTP	160 kb/sn.'ye kadar standart bit hızları ve 8 ila 48 kHz arasındaki örnekleme hızlarının herhangi bir kombinasyonunda mono/stereo içerik	3GPP (.3gp) ve MPEG-4 (.mp4, .m4a).
Resim	JPEG	base+progressive		Android 2.3, uygulamaların bu tür dosyaları programatik olarak oluşturmak için kullanabileceği API'ler içerdiğinden tüm cihaz uygulamalarında bu resim biçimleri için kodlayıcılar BULUNMASI GEREKİR.
	PNG
Video	H.263		3GPP (.3gp) dosyaları	Kamera donanımı içeren ve android.hardware.camera veya android.hardware.camera.front tanımlayan cihaz uygulamaları BU video biçimleri için kodlayıcılar İÇERMELİDİR.

Cihaz uygulamalarında, yukarıda listelenen kodlayıcılara ek olarak bir H.264 kodlayıcı YER ALMALIDIR. Gelecekteki bir sürümün Uyumluluk Tanımı'nda bu şartın "ZORUNLU" olarak değiştirilmesinin planlandığını unutmayın. Yani H.264 kodlaması Android 2.3'te isteğe bağlıdır ancak gelecekteki bir sürümde zorunlu olacaktır. Android 2.3 çalıştıran mevcut ve yeni cihazların Android 2.3'te bu koşulu karşılaması önemle tavsiye edilir. Aksi takdirde, gelecekteki sürüme yükseltildiğinde Android uyumluluğu elde edemezler.

5.2. Ses Kaydetme

Bir uygulama, ses akışı kaydetmeye başlamak için android.media.AudioRecord API'yi kullandığında cihaz uygulamaları aşağıdaki davranışların her biriyle ses örneklemeli ve kaydetmelidir:

• Gürültü azaltma işlemi (varsa) DEVRE DIŞI BIRAKILMALIDIR.
• Varsa otomatik kazanç denetimi DEVRE DIŞI BIRAKILMALIDIR.
• Cihaz, frekansa göre yaklaşık olarak düz bir genlik özelliği GÖSTERMELİDİR; özellikle 100 Hz ile 4.000 Hz arasında ±3 dB
• Ses girişi hassasiyeti, 1000 Hz'de 90 dB ses gücü seviyesi (SPL) kaynağının 16 bitlik örnekler için 5000 RMS vermesi olacak şekilde AYARLANMALIDIR.
• PCM genlik seviyeleri, mikrofondaki 90 dB SPL'ye göre en az 30 dB aralığında (-18 dB ila +12 dB) giriş SPL değişikliklerini doğrusal olarak İZLEMEYECEK.
• Toplam harmonik bozulma, 90 dB SPL giriş seviyesinde 100 Hz ile 4.000 Hz arasında% 1'den az OLMALIDIR.

Not: Yukarıda belirtilen şartlar Android 2.3 için "OLMALI" olarak belirtilmiş olsa da gelecekteki bir sürümün Uyumluluk Tanımı'nda bu şartlar "OLMALI" olarak değiştirilmesi planlanmaktadır. Yani bu şartlar Android 2.3'te isteğe bağlıdır ancak gelecekteki bir sürümde zorunludur. Android 2.3 çalıştıran mevcut ve yeni cihazların Android 2.3'te bu koşulları karşılaması önemle tavsiye edilir. Aksi takdirde, gelecekteki bir sürüme yükseltildiğinde Android uyumluluğu elde edemezler.

5.3. Ses gecikmesi

Ses gecikmesi, genel olarak bir uygulamanın ses çalma veya kayıt işlemi istemesi ile cihaz uygulamasının işlemi gerçekten başlatması arasındaki aralık olarak tanımlanır. Ses efektleri veya VOIP iletişimi gibi gerçek zamanlı efektler elde etmek için birçok uygulama sınıfı kısa gecikmeleri kullanır. Mikrofon donanımı içeren ve android.hardware.microphone beyan eden cihaz uygulamaları BU BÖLÜMDE belirtilen tüm ses gecikmesi şartlarını karşılamalıdır. Cihaz uygulamalarının mikrofon donanımını çıkarabileceği koşullar hakkında ayrıntılı bilgi için 7. Bölümü inceleyin.

Bu bölümün amaçları doğrultusunda:

• "Soğuk çıkış gecikmesi", ses sisteminin istekten önce boşta ve kapalı olduğu durumlarda bir uygulamanın ses çalmayı istemesi ile sesin çalmaya başlaması arasındaki aralık olarak tanımlanır.
• "Sıcak çıkış gecikmesi", ses sisteminin yakın zamanda kullanıldığı ancak şu anda boş olduğu (yani sessiz olduğu) bir durumda, bir uygulamanın ses çalmayı istemesi ile sesin çalmaya başlaması arasındaki aralık olarak tanımlanır.
• "Sürekli çıkış gecikmesi", cihaz ses çalarken bir uygulamanın çalınacak bir örnek yayınlaması ile hoparlörün ilgili sesi fiziksel olarak çaldığı an arasındaki aralık olarak tanımlanır.
• "Soğuk giriş gecikmesi", bir uygulamanın ses kaydı isteğinde bulunduğu andan, ses sistemi ve mikrofon istek öncesinde boşta ve kapalıyken ilk örneğin geri çağırma işlevi aracılığıyla uygulamaya ulaştırılacağı ana kadar geçen süre olarak tanımlanır.
• "Sürekli giriş gecikmesi", cihaz kayıt modundayken ortam sesi oluştuğunda ve bu sese karşılık gelen örnek, geri çağırma işlevi aracılığıyla bir kayıt uygulamasına iletildiğinde gerçekleşir.

Yukarıdaki tanımları kullanarak cihaz uygulamaları şu özelliklerin her birini GÖSTERMELİDİR:

• 100 milisaniye veya daha az soğuk çıkış gecikmesi
• 10 milisaniye veya daha az hazırda çalıştırma çıkış gecikmesi
• 45 milisaniye veya daha az sürekli çıkış gecikmesi
• 100 milisaniye veya daha az soğuk giriş gecikmesi
• 50 milisaniye veya daha az sürekli giriş gecikmesi

Not: Yukarıda belirtilen şartlar Android 2.3 için "OLMALI" olarak belirtilmiş olsa da gelecekteki bir sürümün Uyumluluk Tanımı'nda bu şartlar "OLMALI" olarak değiştirilmesi planlanmaktadır. Yani bu şartlar Android 2.3'te isteğe bağlıdır ancak gelecekteki bir sürümde zorunludur. Android 2.3 çalıştıran mevcut ve yeni cihazların Android 2.3'te bu koşulları karşılaması önemle tavsiye edilir. Aksi takdirde, gelecekteki bir sürüme yükseltildiğinde Android uyumluluğu elde edemezler.

Bir cihaz uygulaması bu bölümün şartlarını karşılıyorsa android.content.pm.PackageManager sınıfı aracılığıyla "android.hardware.audio.low-latency" özelliğini bildirerek düşük gecikmeli ses desteğini bildirebilir. [Kaynaklar, 27] Buna karşılık, cihaz uygulaması bu koşulları karşılamıyorsa düşük gecikmeli ses desteğini bildirmemelidir.

6. Geliştirici Aracı Uyumluluğu

Cihaz uygulamaları, Android SDK'da sağlanan Android Geliştirici Araçları'nı DESTEKLEMELİDİR. Daha ayrıntılı olarak, Android uyumlu cihazlar ŞUNLARLA uyumlu OLMALIDIR:

• Android Debug Bridge (adb olarak bilinir) [Kaynaklar, 23]
  Cihaz uygulamaları, Android SDK'da belirtildiği şekilde tüm adb işlevlerini desteklemelidir. Cihaz tarafındaki adb daemon'ı varsayılan olarak etkin OLMAMALIDIR ancak Android Hata Ayıklama Köprüsü'nü etkinleştirmek için kullanıcının erişebileceği bir mekanizma OLMALIDIR.
• Dalvik Hata Ayıklama İzleyici Hizmeti (ddms olarak bilinir) [Kaynaklar, 23]
  Cihaz uygulamaları, Android SDK'sında belirtildiği gibi tüm ddms özelliklerini DESTEKLEMELİDİR. ddms, adb kullandığından ddms desteği varsayılan olarak devre dışı OLMALIDIR ancak kullanıcı yukarıda belirtildiği gibi Android Hata Ayıklama Köprüsü'nü etkinleştirdiğinde desteklenmelidir.
• Monkey [Kaynaklar, 26]
  Cihaz uygulamaları Monkey çerçevesini İÇERMELİ ve uygulamaların kullanabileceği şekilde kullanıma sunmalıdır.

Linux tabanlı sistemlerin ve Apple Macintosh sistemlerinin çoğu, ek destek olmadan standart Android SDK araçlarını kullanarak Android cihazları tanır. Ancak Microsoft Windows sistemlerinde genellikle yeni Android cihazlar için sürücü gerekir. (Örneğin, yeni tedarikçi firma kimlikleri ve bazen yeni cihaz kimlikleri için Windows sistemlerinde özel USB sürücüleri gerekir.) Standart Android SDK'sında sağlandığı şekilde bir cihaz uygulaması adb aracı tarafından tanınmıyorsa cihaz uygulayıcıları, geliştiricilerin adb protokolünü kullanarak cihaza bağlanmasına olanak tanıyan Windows sürücüleri sağlamalıdır. Bu sürücüler, Windows XP, Windows Vista ve Windows 7 için hem 32 bit hem de 64 bit sürümlerinde sağlanmalıdır.

7. Donanım Uyumluluğu

Android, cihaz uygulayıcılarının yenilikçi form faktörleri ve yapılandırmalar oluşturmasını amaçlar. Aynı zamanda Android geliştiriciler, Android API'leri aracılığıyla kullanılabilen çeşitli donanım ve özelliklere dayalı yenilikçi uygulamalar yazar. Bu bölümdeki şartlar, cihaz uygulayıcılarının yararlanabileceği yenilikler ile geliştiricilerin uygulamalarının yalnızca düzgün çalışacağı cihazlarda kullanılabilmesini sağlamaya yönelik ihtiyaçları arasında bir denge kurar.

Bir cihazda, üçüncü taraf geliştiriciler için ilgili bir API'ye sahip belirli bir donanım bileşeni varsa cihaz uygulaması bu API'yi Android SDK dokümanlarında açıklandığı şekilde UYGULAMALIDIR. SDK'daki bir API, isteğe bağlı olduğu belirtilen bir donanım bileşeniyle etkileşime geçiyorsa ve cihaz uygulamasında bu bileşen yoksa:

• Bileşenin API'leri için eksiksiz sınıf tanımları (SDK tarafından belirtildiği şekilde) hâlâ mevcut OLMALIDIR.
• API'nin davranışları makul bir şekilde işlemsiz olarak uygulanmalıdır.
• API yöntemleri, SDK dokümanlarında izin verildiğinde null değerler DÖNDÜRMELİDİR.
• API yöntemleri, SDK dokümanlarında null değerlere izin verilmeyen sınıfların işlemsiz uygulamalarını DÖNDÜRMELİDİR.
• API yöntemleri, SDK dokümanlarında belirtilmeyen istisnalar ÇIKARTMAMALIDIR.

Bu koşulların geçerli olduğu bir senaryoya tipik bir örnek telefon API'sidir: Telefon olmayan cihazlarda bile bu API'ler makul bir şekilde işlem yapmaz olarak uygulanmalıdır.

Cihaz uygulamaları, android.content.pm.PackageManager sınıfındaki getSystemAvailableFeatures() ve hasSystemFeature(String) yöntemleri aracılığıyla doğru donanım yapılandırma bilgilerini doğru şekilde raporlamalıdır. [Kaynaklar, 27]

7.1. Görüntü ve Grafikler

Android 2.3, üçüncü taraf uygulamalarının çeşitli donanım yapılandırmalarında sorunsuz şekilde çalışmasını sağlamak için uygulama öğelerini ve kullanıcı arayüzü düzenlerini cihaza uygun şekilde otomatik olarak ayarlayan özellikler içerir [Kaynaklar, 28]. Cihazlar, bu bölümde ayrıntılı olarak açıklandığı şekilde bu API'leri ve davranışları düzgün şekilde uygulamalıdır.

7.1.1. Ekran Yapılandırmaları

Cihaz uygulamaları, aşağıdaki koşulları karşılamaları koşuluyla herhangi bir piksel boyutunda ekran kullanabilir:

• Ekranların fiziksel diyagonal boyutu en az 2,5 inç OLMALIDIR.
• Yoğunluk en az 100 dpi OLMALIDIR
• En boy oranı 1,333 (4:3) ile 1,779 (16:9) arasında OLMALIDIR.
• Kullanılan ekran teknolojisi kare piksellerden oluşuyorsa

Yukarıdaki koşulları karşılayan bir ekrana sahip cihaz uygulamaları uyumlu kabul edilir ve ek işlem yapılmasına gerek yoktur. Android çerçevesi uygulaması, ekran boyutu grubu ve yoğunluk grubu gibi ekran özelliklerini otomatik olarak hesaplar. Çoğu durumda, çerçeve kararları doğrudur. Varsayılan çerçeve hesaplamaları kullanılıyorsa ek işlem yapmanız gerekmez. Varsayılanları değiştirmek veya yukarıdaki şartları karşılamayan bir ekran kullanmak isteyen cihaz uygulayıcıları, 12. Bölüm'de belirtildiği gibi, yol göstermesi için Android Uyumluluk Ekibi ile iletişime GEÇMELİDİR.

Yukarıdaki şartlarda kullanılan birimler aşağıdaki gibi tanımlanır:

• "Fiziksel diyagonal boyut", ekranın aydınlatılmış kısmının iki karşıt köşesi arasındaki inç cinsinden mesafedir.
• "dpi" ("inç başına nokta" anlamına gelir), 1 inçlik doğrusal yatay veya dikey bir açıklık tarafından kapsanan piksel sayısıdır. dpi değerlerinin listelendiği yerlerde hem yatay hem de dikey dpi aralıkta olmalıdır.
• "En boy oranı", ekranın uzun boyutunun kısa boyuta oranıdır. Örneğin, 480x854 piksel boyutunda bir ekran için 854 / 480 = 1, 779 veya yaklaşık olarak "16:9" değeri elde edilir.

Cihaz uygulamalarında YALNIZCA tek statik yapılandırmaya sahip ekranlar kullanılmalıdır. Yani cihaz uygulamaları birden fazla ekran yapılandırmasını ETKİNLEŞTİRMEMELİDİR. Örneğin, tipik bir televizyon 1080p, 720p gibi birden fazla çözünürlüğü desteklediğinden bu yapılandırma Android 2.3 ile uyumlu değildir. (Ancak bu tür yapılandırmalar için destek üzerinde çalışılıyor ve Android'in gelecekteki bir sürümünde kullanıma sunulması planlanıyor.)

7.1.2. Görüntülü Reklam Metrikleri

Cihaz uygulamaları, android.util.DisplayMetrics [Kaynaklar, 29] bölümünde tanımlanan tüm görüntüleme metrikleri için doğru değerleri bildirmelidir.

7.1.3. Bildirilen Ekran Desteği

Uygulamalar, isteğe bağlı olarak AndroidManifest.xml dosyasında <supports-screens> özelliği aracılığıyla hangi ekran boyutlarını desteklediklerini belirtir. Cihaz uygulamalarında, Android SDK dokümanlarında açıklandığı gibi, uygulamaların küçük, orta ve büyük ekranlar için belirtilen desteği doğru şekilde dikkate ALINMALIDIR.

7.1.4. Ekran Yönlendirme

Uyumlu cihazlar, dikey veya yatay ekran yönü için uygulamalar tarafından dinamik yönü desteklemelidir. Yani cihaz, uygulamanın belirli bir ekran yönü isteğini dikkate almalıdır. Cihaz uygulamalarında varsayılan olarak dikey veya yatay yön seçilebilir. Fiziksel olarak döndürülemeyen cihazlar, mevcut ekranın yalnızca bir bölümünü kullanarak portre modu isteyen uygulamaları "sinemaskop" moduna alarak bu koşulu karşılayabilir.

Cihazlar, android.content.res.Configuration.orientation, android.view.Display.getOrientation() veya diğer API'ler aracılığıyla sorgulandığında cihazın mevcut yönü için doğru değeri bildirmelidir.

7.1.5. 3D Grafik Hızlandırma

Cihaz uygulamaları, Android 2.3 API'leri tarafından zorunlu kılındığı üzere OpenGL ES 1.0'u DESTEKLEMELİDİR. 3D hızlandırma donanımına sahip olmayan cihazlar için OpenGL ES 1.0'un yazılım uygulaması, yayın öncesi Android Açık Kaynak Projesi tarafından sağlanır. Cihaz uygulamaları OpenGL ES 2.0'ı DESTEKLEMELİDİR.

Uygulamalar Open GL ES 2.0 desteğini EKSİLTİREBİLİR. Ancak destek eksiltildiyse cihaz uygulamaları OpenGL ES 2.0'ı desteklediğini HİÇBİR ŞEKİLDE bildirmemelidir. Özellikle, bir cihaz uygulamasında OpenGL ES 2.0 desteği yoksa:

• Yönetilen API'ler (GLES10.getString() yöntemi gibi) OpenGL ES 2.0 desteğini bildirmemelidir.
• Yerleşik C/C++ OpenGL API'leri (yani, libGLES_v1CM.so, libGLES_v2.so veya libEGL.so aracılığıyla uygulamalar tarafından kullanılabilen API'ler) OpenGL ES 2.0 desteğini bildirmemelidir.

Buna karşılık, bir cihaz uygulaması OpenGL ES 2.0'ı destekliyorsa, bu desteği az önce listelenen yollar üzerinden doğru şekilde bildirmelidir.

Android 2.3'te, uygulamaların isteğe bağlı olarak belirli OpenGL doku sıkıştırma biçimlerine ihtiyaç duyduklarını belirtmelerine yönelik destek bulunduğunu unutmayın. Bu biçimler genellikle tedarikçi firmaya özgüdür. Android 2.3, belirli bir doku sıkıştırma biçimini uygulamak için cihaz uygulamalarını gerektirmez. Ancak, destekledikleri doku sıkıştırma biçimlerini OpenGL API'deki getString() yöntemi aracılığıyla doğru şekilde bildirmelidirler.

7.2. Giriş Cihazları

Android 2.3, kullanıcı girişi için çeşitli modları destekler. Cihaz uygulamalarında, bu bölümde belirtildiği şekilde kullanıcı giriş cihazları desteklenmelidir.

7.2.1. Klavye

Cihaz uygulamaları:

• developer.android. com adresinde açıklandığı gibi Giriş Yönetimi Çerçevesi (üçüncü taraf geliştiricilerin Giriş Yönetimi Motorları (ör.sanal klavye) oluşturmasına olanak tanır) desteği ZORUNLUDUR.
• En az bir sanal klavye uygulaması sağlanmalıdır (sabit klavye olup olmadığına bakılmaksızın)
• Ek sanal klavye uygulamaları içerebilir
• Donanım klavyesi OLABİLİR
• android.content.res.Configuration.keyboard[Kaynaklar, 30] bölümünde belirtilen biçimlerden biriyle eşleşmeyen bir donanım klavyesi İÇERMEMELİDİR (ör. QWERTY veya 12 tuşlu)

7.2.2. Dokunmatik olmayan gezinme

Cihaz uygulamaları:

• Dokunmatik olmayan bir gezinme seçeneğini (ör. dokunmatik yüzey, d-pad veya tekerlek) EKSİLTİREBİLİR.
• android.content.res.Configuration.navigation [Kaynaklar, 30] için doğru değeri bildirmelidir.
• Giriş Yönetimi Motorları ile uyumlu, metin seçimi ve düzenleme için makul bir alternatif kullanıcı arayüzü mekanizması SAĞLANMALIDIR. Yukarı yönlü Android açık kaynak kodu, dokunmatik olmayan gezinme girişlerine sahip cihazlarda kullanılmaya uygun bir seçim mekanizması içerir.

7.2.3. Gezinme tuşları

Ana Sayfa, Menü ve Geri işlevleri, Android gezinme paradigması için gereklidir. Cihaz uygulamalarında, uygulama durumundan bağımsız olarak bu işlevler kullanıcıya her zaman sunulmalıdır. Bu işlevler özel düğmeler aracılığıyla UYGULANMALIDIR. Bu düğmeler yazılım, hareketler, dokunmatik panel vb. kullanılarak uygulanabilir. Bu durumda, düğmelere her zaman erişilebilmelidir ve mevcut uygulama görüntüleme alanını engellememelidir veya bu alanla etkileşime girmemelidir.

Cihaz uygulayıcıları ayrıca özel bir arama anahtarı DA sağlamalıdır. Cihaz uygulayıcıları, telefon görüşmeleri için gönder ve sonlandır tuşları da sağlayabilir.

7.2.4. Dokunmatik ekran girişi

Cihaz uygulamaları:

• Dokunmatik ekrana sahip OLMALIDIR
• Kapasitif veya dirençli dokunmatik ekran OLABİLİR
• Cihazdaki belirli dokunmatik ekranın türüne karşılık gelen android.content.res.Configuration[Kaynaklar, 30] değerini bildirmelidir
• Dokunmatik ekran birden fazla işaretçiyi destekliyorsa tamamen bağımsız olarak izlenen işaretçileri DESTEKLEMELİDİR

7.3. Sensörler

Android 2.3, çeşitli sensör türlerine erişmek için API'ler içerir. Cihaz uygulamalarında, aşağıdaki alt bölümlerde belirtildiği gibi bu sensörler genellikle atlanabilir. Bir cihazda, üçüncü taraf geliştiriciler için ilgili bir API'si olan belirli bir sensör türü varsa cihaz uygulaması bu API'yi Android SDK dokümanlarında açıklandığı şekilde UYGULAMALIDIR. Örneğin, cihaz uygulamaları:

• android.content.pm.PackageManager sınıfına göre sensörlerin varlığını veya yokluğunu doğru şekilde bildirmelidir. [Kaynaklar, 27]
• SensorManager.getSensorList() ve benzer yöntemler aracılığıyla desteklenen sensörlerin doğru listesini DÖNDÜRMELİDİR
• Diğer tüm sensör API'leri için makul bir şekilde davranmalıdır (örneğin, uygulamalar dinleyici kaydettirmeye çalıştığında uygun şekilde doğru veya yanlış döndürerek, ilgili sensörler mevcut olmadığında sensör dinleyicilerini çağırmamak vb.).

Yukarıdaki liste kapsamlı değildir. Android SDK'sının belgelenmiş davranışı yetkili kabul edilir.

Bazı sensör türleri sentetiktir. Yani bir veya daha fazla sensör tarafından sağlanan verilerden türetilebilirler. (Yön sensörü ve doğrusal hızlanma sensörü buna örnek gösterilebilir.) Cihaz uygulamaları, ön koşul olan fiziksel sensörleri içerdiğinde bu sensör türlerini UYGULAMALIDIR.

Android 2.3 API'leri, yalnızca veriler değiştiğinde değil, sürekli olarak veri döndüren bir "akış" sensörü kavramı sunar. Cihaz uygulamalarında, Android 2.3 SDK dokümanlarında akış sensörü olarak belirtilen API'ler için sürekli olarak düzenli veri örnekleri sağlanmalıdır.

7.3.1. İvme ölçer

Cihaz uygulamalarında 3 eksenli ivme ölçer BULUNMASI GEREKİR. Bir cihaz uygulamasında 3 eksenli ivme ölçer varsa:

• Etkinlikleri 50 Hz veya daha yüksek bir hızda yayınlayabilmelidir.
• Android API'lerinde açıklandığı şekilde Android sensör koordinat sistemine UYGUN OLMALIDIR (bkz. [Kaynaklar, 31])
• Herhangi bir üç boyutlu vektörde serbest düşüşten iki katı yerçekimine (2g) kadar veya daha fazlasını ölçebilmelidir.
• 8 bit veya daha fazla doğruluk değerine sahip OLMALIDIR
• Standart sapması 0,05 m/s^2'den büyük OLMAMALIDIR

7.3.2. Manyetometre

Cihaz uygulamalarında 3 eksenli bir manyetometre (ör. pusula) BULUNMASI GEREKİR. 3 eksenli manyetometre içeren cihazlar:

• Etkinlikleri 10 Hz veya daha yüksek bir hızda yayınlayabilmelidir.
• Android API'lerinde açıklandığı şekilde Android sensör koordinat sistemine UYGUN OLMALIDIR (bkz. [Kaynaklar, 31]).
• Coğrafi manyetik alanı kapsayacak şekilde yeterli bir alan gücü aralığını örnekleyebilmelidir.
• 8 bit veya daha fazla doğruluk değerine sahip OLMALIDIR
• Standart sapma 0,5 µT'den büyük OLMAMALIDIR

7.3.3. GPS

Cihaz uygulamaları bir GPS alıcısı İÇERMELİDİR. Bir cihaz uygulamasında GPS alıcısı varsa GPS kilitlenme süresini en aza indirmek için bir tür "desteklenen GPS" tekniği DAHİL EDİLMELİDİR.

7.3.4. Jiroskop

Cihaz uygulamalarında jiroskop (ör. açısal değişim sensörü) BULUNMASI GEREKİR. 3 eksenli ivme ölçer de dahil edilmediği sürece cihazlarda jiroskop sensörü OLMAMALIDIR. Cihaz uygulaması jiroskop içeriyorsa:

• 5,5*Pi radyan/saniyeye (yani saniyede yaklaşık 1.000 derece) kadar yön değişikliklerini ölçebilmelidir.
• Etkinlikleri 100 Hz veya daha yüksek hızda yayınlayabilmelidir.
• 8 bit veya daha fazla doğruluk değerine sahip OLMALIDIR

7.3.5. Barometre

Cihaz uygulamaları bir barometre (ör. ortam hava basıncı sensörü) İÇERİEBİLİR. Cihaz uygulaması barometre içeriyorsa:

• Etkinlikleri 5 Hz veya daha yüksek bir hızda yayınlayabilmelidir.
• Yüksekliği tahmin etmeyi sağlayacak yeterli hassasiyete sahip OLMALIDIR

7.3.7. Termometre

Cihaz uygulamaları termometre (ör. sıcaklık sensörü) İÇERMEYEBİLİR ancak İÇERMEMELİDİR. Bir cihaz uygulamasında termometre varsa cihazın CPU sıcaklığını ÖLÇMESİ GEREKİR. Başka bir sıcaklığı ÖLÇMEMELİDİR. (Bu sensör türünün Android 2.3 API'lerinde desteğinin sonlandırıldığını unutmayın.)

7.3.7. Fotoğraf ölçer

Cihaz uygulamaları bir fotometre (ör. ortam ışığı sensörü) İÇERİEBİLİR.

7.3.8. Yakınlık Sensörü

Cihaz uygulamaları bir yakınlık sensörü içerEBİLİR. Bir cihaz uygulamasında yakınlık sensörü varsa nesnenin yakınlığını ekranla aynı yönde ölçmesi GEREKİR. Yani bu sensör türünün birincil amacı kullanıcının kullandığı telefonu algılamak olduğundan yakınlık sensörü, ekrana yakın nesneleri algılayacak şekilde yönlendirilmelidir. Bir cihaz uygulamasında başka bir yönde yakınlık sensörü varsa bu API aracılığıyla erişilememelidir. Bir cihaz uygulamasında yakınlık sensörü varsa 1 bit veya daha fazla doğruluk değeri OLMALIDIR.

7.4. Veri Bağlantısı

Ağ bağlantısı ve internet erişimi, Android'in önemli özellikleridir. Cihazlar arası etkileşim ise Android cihazlara ve uygulamalarına önemli ölçüde değer katar. Cihaz uygulamalarının bu bölümdeki veri bağlantısı şartlarını karşılaması GEREKİR.

7.4.1. Telefon Hizmeti

Android 2.3 API'leri ve bu doküman tarafından kullanılan "Telefon" terimi, özellikle GSM veya CDMA ağı üzerinden sesli arama yapma ve SMS mesajı göndermeyle ilgili donanıma atıfta bulunur. Bu sesli aramalar paket anahtarlamalı olabilir veya olmayabilir ancak Android 2.3'ün amaçları doğrultusunda, aynı ağ kullanılarak uygulanabilecek veri bağlantılarından bağımsız olarak kabul edilir. Diğer bir deyişle, Android "telephony" işlevi ve API'leri özellikle sesli aramaları ve SMS'leri ifade eder. Örneğin, arama yapamayan veya SMS mesajı gönderip alamayan cihaz uygulamaları, veri bağlantısı için hücresel ağ kullanıp kullanmadıklarından bağımsız olarak "android.hardware.telephony" özelliğini veya herhangi bir alt özelliği bildirmemelidir.

Android 2.3, telefon donanımı içermeyen cihazlarda KULLANILABİLİR. Yani Android 2.3, telefon olmayan cihazlarla uyumludur. Ancak bir cihaz uygulaması GSM veya CDMA telefon görüşmesi içeriyorsa söz konusu teknolojinin API'si için tam destek UYGULANMALIDIR. Telefon donanımı içermeyen cihaz uygulamaları, API'lerin tamamını işlem yapmadan olarak UYGULAMALIDIR.

7.4.2. IEEE 802.11 (Kablosuz)

Android 2.3 cihaz uygulamalarında bir veya daha fazla 802.11 biçimi (b/g/a/n vb.) için destek YER ALMALIDIR. Bir cihaz uygulaması 802.11 desteği içeriyorsa ilgili Android API'yi UYGULAMASI GEREKİR.

7.4.3. Bluetooth

Cihaz uygulamaları bir Bluetooth alıcı/verici içermelidir. Bluetooth alıcı/verici içeren cihaz uygulamaları, SDK dokümanlarında [Kaynaklar, 32] açıklandığı gibi RFCOMM tabanlı Bluetooth API'yi etkinleştirmelidir. Cihaz uygulamaları, cihaza uygun olarak A2DP, AVRCP, OBEX gibi ilgili Bluetooth profillerini UYGULAMALIDIR.

Uyumluluk Testi Paketi, Android RFCOMM Bluetooth API'nin temel işlevlerini kapsayan test örneklerini içerir. Ancak Bluetooth, cihazlar arasındaki bir iletişim protokolü olduğundan tek bir cihazda çalışan birim testleriyle tam olarak test edilemez. Sonuç olarak, cihaz uygulamaları da Ek A'da açıklanan insan tarafından yönetilen Bluetooth test prosedürünü İŞLEMELİDİR.

7.4.4. Yakın Alan İletişimi

Cihaz uygulamalarında Near Field Communication (NFC) için bir alıcı/verici ve ilgili donanım YER ALMALIDIR. Bir cihaz uygulaması NFC donanımı içeriyorsa:

• android.content.pm.PackageManager.hasSystemFeature() yönteminden android.hardware.nfc özelliğini bildirmelidir. [Kaynaklar, 27]
• Aşağıdaki NFC standartları üzerinden NDEF mesajlarını okuyup yazabilmelidir:
  • Aşağıdaki NFC standartları aracılığıyla NFC Forum okuyucu/yazar (NFC Forum teknik spesifikasyonu NFCForum-TS-DigitalProtocol-1.0 tarafından tanımlandığı şekilde) olarak hareket edebilmelidir:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • NfcV (ISO 15693)
    • IsoDep (ISO 14443-4)
    • NFC Forumu Etiket Türleri 1, 2, 3, 4 (NFC Forumu tarafından tanımlanmıştır)
  • Aşağıdaki eşler arası standartlar ve protokoller üzerinden veri gönderip alabilmeli:
    • ISO 18092
    • LLCP 1.0 (NFC Forum tarafından tanımlanmıştır)
    • SDP 1.0 (NFC Forum tarafından tanımlanmıştır)
    • NDEF Push Protokolü [Kaynaklar, 33]
  • NFC keşif modundayken desteklenen tüm teknolojileri taramalıdır.
  • Cihaz açıkken ve ekran etkinken NFC keşif modunda OLMALIDIR.

  (Yukarıdaki JIS, ISO ve NFC Forumu spesifikasyonları için herkese açık bağlantıların kullanılamadığını unutmayın.)

  Ayrıca, cihaz uygulamaları aşağıdaki yaygın olarak dağıtılan MIFARE teknolojilerini DESTEKLEMELİDİR.

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

  Android 2.3.3'ün bu MIFARE türleri için API'ler içerdiğini unutmayın. Bir cihaz uygulaması MIFARE'i destekliyorsa:

  • İlgili Android API'lerini Android SDK'sında belirtildiği şekilde UYGULAMALIDIR
  • android.content.pm.PackageManager.hasSystemFeature() yönteminden com.nxp.mifare özelliğini bildirmelidir. [Kaynaklar, 27] Bunun standart bir Android özelliği olmadığını ve bu nedenle PackageManager sınıfında sabit bir değer olarak görünmediğini unutmayın.
  • Bu bölümde açıklandığı şekilde genel NFC desteğini de uygulamadığı sürece ilgili Android API'lerini uygulamamalı veya com.nxp.mifare özelliğini bildirmemelidir

  Bir cihaz uygulaması NFC donanımı içermiyorsa android.content.pm.PackageManager.hasSystemFeature() yönteminden [Kaynaklar, 27] android.hardware.nfc özelliğini İLAN ETMEMELİDİR ve Android 2.3 NFC API'sini işlem yapmaz olarak UYGULAMALIDIR.

  android.nfc.NdefMessage ve android.nfc.NdefRecord sınıfları protokolden bağımsız bir veri temsili biçimini temsil ettiğinden, NFC desteği içermeseler veya android.hardware.nfc özelliğini belirtmeseler bile cihaz uygulamaları bu API'leri UYGULAMALIDIR.

  7.4.5. Minimum Ağ İşlevi

  Cihaz uygulamalarında bir veya daha fazla veri ağı biçimi için destek ZORUNLUDUR. Daha açık belirtmek gerekirse, cihaz uygulamalarında 200 Kbit/sn veya daha yüksek hızda en az bir veri standardı desteği BULUNMASI GEREKİR. Bu koşulu karşılayan teknolojilere örnek olarak EDGE, HSPA, EV-DO, 802.11g, Ethernet vb. verilebilir.

  Birincil veri bağlantısının fiziksel bir ağ standardı (Ethernet gibi) olduğu cihaz uygulamalarında 802.11 (Kablosuz) gibi en az bir yaygın kablosuz veri standardı desteği de YER ALMALIDIR.

  Cihazlar birden fazla veri bağlantısı biçimi UYGULAYABİLİR.

  7.5. Kameralar

  Cihaz uygulamalarında arka kamera BULUNMASI GEREKİR ve ön kamera BULUNMASI MÜMKÜNDÜR. Arka kamera, cihazın ekranın karşısındaki tarafında bulunan bir kameradır. Yani geleneksel bir kamera gibi cihazın uzak tarafındaki sahneleri görüntüler. Ön kamera, cihazın ekranla aynı tarafında bulunan bir kameradır. Yani genellikle görüntülü konferans ve benzeri uygulamalarda kullanıcının görüntüsünü almak için kullanılan bir kameradır.

  7.5.1. Arka Kamera

  Cihaz uygulamalarında arka kamera BULUNMASI GEREKİR. Bir cihaz uygulaması arka kamera içeriyorsa:

  • En az 2 megapiksel çözünürlüğe sahip OLMALIDIR.
  • Kamera sürücüsünde donanım otomatik odaklama veya yazılım otomatik odaklama uygulanmış OLMALIDIR (uygulama yazılımı için şeffaf)
  • Sabit odaklı veya EDOF (geniş alan derinliği) donanımına sahip OLABİLİR
  • FLAŞ içerebilir. Kamerada ışık varsa uygulama, Camera.Parameters nesnesinin FLASH_MODE_AUTO veya FLASH_MODE_ON özelliklerini etkinleştirerek ışığı açıkça etkinleştirmediği sürece, bir android.hardware.Camera.PreviewCallback örneği bir kamera önizleme yüzeyine kaydedilmişken ışık YANMAZ. Bu kısıtlamanın cihazın yerleşik sistem kamera uygulaması için değil, yalnızca Camera.PreviewCallback kullanan üçüncü taraf uygulamaları için geçerli olduğunu unutmayın.

  7.5.2. Ön Kamera

  Cihaz uygulamaları ön kamera içerEBİLİR. Bir cihaz uygulamasında ön kamera varsa:

  • Çözünürlüğü en az VGA (yani 640x480 piksel) olmalıdır.
  • Camera API için varsayılan olarak ön kamera KULLANMAMALIDIR. Yani Android 2.3'teki kamera API'si, ön kameralar için özel destek sunar ve cihaz uygulamaları, API'yi cihazdaki tek kamera olsa bile ön kamerayı varsayılan arka kamera olarak ele alacak şekilde yapılandırmamalıdır.
  • 7.5.1 numaralı bölümde açıklandığı gibi arkaya bakan kameralarda kullanılabilen özellikler (ör. otomatik odaklama, flaş vb.) DAHİL OLABİLİR.
  • Bir uygulamanın CameraPreview'da gösterdiği yayını aşağıdaki gibi yatay olarak yansıtmalıdır (yani yansıtmalıdır):
  • Cihaz uygulaması kullanıcı tarafından döndürülebiliyorsa (ör. bir ivmeölçer aracılığıyla otomatik olarak veya kullanıcı girişi aracılığıyla manuel olarak) kamera önizlemesi, cihazın mevcut yönüne göre yatay olarak yansıtılmalıdır.
  • Geçerli uygulama, android.hardware.Camera.setDisplayOrientation() [Kaynaklar, 40] yöntemine yapılan bir çağrı aracılığıyla kamera ekranının döndürülmesini açıkça talep ettiyse kamera önizlemesi, uygulama tarafından belirtilen yönde yatay olarak yansıtılmalıdır.
  • Aksi takdirde önizleme, cihazın varsayılan yatay ekseni boyunca YANSITILMALIDIR.
  • "Görüntüleme sonrası" kamera geri çağırma işleyicilerine döndürülen görüntü verilerini, kamera önizleme görüntü akışı ile aynı şekilde yansıtmalıdır. (Cihaz uygulaması görüntüleme sonrası geri çağırma işlevini desteklemiyorsa bu şart geçerli değildir.)
  • Uygulama geri çağırmalarına döndürülen veya medya depolama alanına bağlanan nihai çekilen hareketsiz resim veya video akışlarını yansıtMAMALIDIR

  7.5.3. Kamera API'si Davranışı

  Cihaz uygulamalarında, hem ön hem de arka kameralar için kamerayla ilgili API'ler için aşağıdaki davranışlar uygulanmalıdır:

  1. Bir uygulama hiç android.hardware.Camera.Parameters.setPreviewFormat(int) çağrısı yapmadıysa cihaz, uygulama geri çağırmalarına sağlanan önizleme verileri için android.hardware.PixelFormat.YCbCr_420_SP'yi KULLANMAK ZORUNDADIR.
  2. Bir uygulama android.hardware.Camera.PreviewCallback örneği kaydederse ve sistem, önizleme biçimi YCbCr_420_SP olduğunda onPreviewFrame() yöntemini çağırırsa onPreviewFrame() yöntemine iletilen byte[] içindeki veriler NV21 kodlama biçiminde olmalıdır. Yani NV21 varsayılan OLMALIDIR.
  3. Cihaz uygulamaları, hem ön hem de arka kameralarda kamera önizlemeleri için YV12 biçimini (android.graphics.ImageFormat.YV12 sabitiyle belirtilir) DESTEKLEMELİDİR. Gelecekteki bir sürümün Uyumluluk Tanımı'nda bu şartın "ZORUNLU" olarak değiştirilmesinin planlandığını unutmayın. Yani YV12 desteği Android 2.3'te isteğe bağlıdır ancak gelecekteki bir sürümde zorunlu olacaktır. Android 2.3 çalıştıran mevcut ve yeni cihazların Android 2.3'te bu koşulu karşılaması önemle tavsiye edilir. Aksi takdirde, gelecekteki sürüme yükseltildiğinde Android uyumluluğu elde edemezler.

  Cihaz uygulamalarında, cihazda donanım otomatik odaklama veya başka özellikler bulunup bulunmadığına bakılmaksızın Android 2.3 SDK dokümanlarında [Kaynaklar, 41] yer alan Camera API'nin tamamı uygulanmalıdır. Örneğin, otomatik odaklama özelliği olmayan kameralar, kayıtlı tüm android.hardware.Camera.AutoFocusCallback örneklerini çağırmaya DEVAM ETMELİDİR (otomatik odaklama özelliği olmayan bir kamerayla alakalı olmasa da). Bunun ön kameralar için de geçerli olduğunu unutmayın. Örneğin, çoğu ön kamera otomatik odaklama özelliğini desteklemese bile API geri çağırmalarının açıklandığı şekilde "taklit" edilmesi gerekir.

  Cihaz uygulamaları, temel donanım özelliği destekliyorsa android.hardware.Camera.Parameters sınıfında sabit olarak tanımlanan her parametre adını tanımalı ve dikkate almalıdır. Cihaz donanımı bir özelliği desteklemiyorsa API, dokümanlar uyarınca davranmalıdır. Buna karşılık, cihaz uygulamalarında android.hardware.Camera.Parameters üzerinde sabit olarak belgelenenler dışında android.hardware.Camera.setParameters() yöntemine iletilen dize sabitleri dikkate alınmamalı veya tanınmamalıdır. Yani, donanım izin veriyorsa cihaz uygulamaları tüm standart kamera parametrelerini DESTEKLEMELİ ve özel kamera parametresi türlerini DESTEKLEMEMELİDİR.

  7.5.4. Kamera yönü

  Hem ön hem de arka kameralar (varsa) kameranın uzun boyutunun ekranın uzun boyutuyla hizalanacak şekilde yönlendirilmelidir. Yani cihaz yatay yönde tutulduğunda kameraların yatay yönde görüntüler çekmesi GEREKİR. Bu durum, cihazın doğal yöneliminden bağımsız olarak geçerlidir. Yani hem yatay birincil cihazlar hem de dikey birincil cihazlar için geçerlidir.

  7.6. Bellek ve Depolama

  Android 2.3'ün temel işlevi, uygulamaları çalıştırmaktır. Cihaz uygulamalarının, uygulamaların düzgün çalışması için yeterli depolama alanı ve bellek sağlaması amacıyla bu bölümün şartlarını İYİCE karşılaMASI GEREKİR.

  7.6.1. Minimum Bellek ve Depolama

  Cihaz uygulamalarında, çekirdek ve kullanıcı alanında en az 128 MB bellek bulunmalıdır. 128 MB, çekirdeğin kontrolü altında olmayan radyo, bellek vb. donanım bileşenlerine ayrılmış belleğe ek olarak OLMALIDIR.

  Cihaz uygulamalarında, kullanıcı verileri için en az 150 MB kalıcı olmayan depolama alanı bulunmalıdır. Yani /data bölümünün en az 150 MB olması ZORUNLUDUR.

  Cihaz uygulamalarında, yukarıdaki şartların yanı sıra kullanıcı verileri için en az 1 GB kalıcı depolama alanı OLMALIDIR. Bu daha yüksek gereksinimin, Android'in gelecekteki bir sürümünde zorunlu minimum şart haline gelmesi planlanmaktadır. Cihaz uygulamalarının bu koşulları hemen karşılaması önemle tavsiye edilir. Aksi takdirde, Android'in gelecekteki bir sürümüyle uyumlu olmayabilirler.

  Android API'leri, uygulamaların veri dosyalarını indirmek için kullanabileceği bir İndirme Yöneticisi içerir. İndirme Yöneticisi uygulaması, 55 MB veya daha büyük tek dosyaları indirebilmelidir. İndirme Yöneticisi uygulaması, 100 MB veya daha büyük dosyaları indirebilmelidir.

  7.6.2. Uygulama Ortak Depolama Alanı

  Cihaz uygulamaları, uygulamalar için paylaşılan depolama alanı sunmalıdır. Sağlanan paylaşılan depolama alanı en az 1 GB boyutunda OLMALIDIR.

  Cihaz uygulamaları, varsayılan olarak "kutudan çıkar çıkmaz" paylaşılan depolama alanı ile yapılandırılmalıdır. Ortak depolama alanı /sdcard Linux yoluna monte edilmemişse cihazda /sdcard ile gerçek montaj noktası arasında bir Linux sembolik bağlantısı BULUNMASI GEREKİR.

  Cihaz uygulamalarında, bu paylaşılan depolama alanında android.permission.WRITE_EXTERNAL_STORAGE izninin belgelendiği şekilde uygulanması GEREKİR. Aksi takdirde, paylaşılan depolama alanı bu izni alan tüm uygulamalar tarafından yazılabilir OLMALIDIR.

  Cihaz uygulamalarında, kullanıcının erişebileceği çıkarılabilir depolama alanı (ör. Secure Digital kart) için donanım OLABİLİR. Alternatif olarak, cihaz uygulamaları dahili (çıkarılabilir olmayan) depolama alanını uygulamalar için paylaşılan depolama alanı olarak AYRIŞTIRABİLİR.

  Kullanılan ortak depolama biçiminden bağımsız olarak, cihaz uygulamalarında USB yığın depolama veya Medya Aktarım Protokolü gibi bir ana bilgisayardan ortak depolama alanının içeriğine erişmek için bir mekanizma sağlanmalıdır.

  İki yaygın örneği ele almak faydalı olacaktır. Bir cihaz uygulaması, ortak depolama alanı şartını karşılamak için SD kart yuvası içeriyorsa kullanıcılara satılan cihaza 1 GB veya daha büyük boyutlu FAT biçimli bir SD kart DAHİL EDİLMELİ ve varsayılan olarak monte EDİLMELİDİR. Alternatif olarak, bir cihaz uygulaması bu koşulu karşılamak için dahili sabit depolama alanı kullanıyorsa bu depolama alanı 1 GB veya daha büyük OLMALI ve /sdcard'e bağlı OLMALIDIR (veya başka bir yere bağlıysa /sdcard fiziksel konuma yönelik sembolik bir bağlantı OLMALIDIR).

  Birden fazla paylaşılan depolama yolu içeren cihaz uygulamaları (ör. hem SD kart yuvası hem de paylaşılan dahili depolama alanı), medya tarayıcısı ve ContentProvider gibi temel uygulamaları, her iki konuma yerleştirilen dosyaları şeffaf bir şekilde desteklemek için DEĞİŞTİRMELİDİR.

  7.7. USB

  Cihaz uygulamaları:

  • Standart USB-A bağlantı noktası olan bir USB ana makinesine bağlanabilen bir USB istemcisi UYGULANMALIDIR
  • Android Debug Bridge'i USB üzerinden UYGULAMALIDIR (7. Bölüm'de açıklandığı şekilde)
  • Cihaza bağlı bir ana makinenin /sdcard biriminin içeriğine erişmesine izin vermek için USB yığın depolama alanı spesifikasyonunu UYGULAMALIDIR
  • Cihaz tarafında mikro USB form faktörü KULLANILMALIDIR
  • Cihaz tarafında standart olmayan bir bağlantı noktası BULUNMASI MÜMKÜNDÜR ancak bu durumda özel pin çıkışını standart USB-A bağlantı noktasına bağlayabilecek bir kabloyla birlikte gönderilMELİDİR.

  8. Performans Uyumluluğu

  Uyumlu uygulamalar, yalnızca cihazda doğru şekilde çalıştırılmakla kalmamalı, aynı zamanda makul bir performans ve genel olarak iyi bir kullanıcı deneyimi sunmalıdır. Cihaz uygulamaları, aşağıdaki tabloda tanımlanan Android 2.3 uyumlu bir cihazın temel performans metriklerini karşılamalıdır:

  Metrik	Performans Eşiği	Yorumlar
  Uygulama Başlatma Süresi	Aşağıdaki uygulamalar belirtilen süre içinde başlatılmalıdır. Tarayıcı: 1.300 ms'den kısa MMS/SMS: 700 ms'den kısa AlarmClock: 650 ms'den kısa	Başlatma süresi, Linux sürecini başlatmak, Android paketini Dalvik sanal makinesine yüklemek ve onCreate'i çağırmak için gereken süre dahil olmak üzere, uygulamanın varsayılan etkinliğini yüklemenin tamamlanması için gereken toplam süre olarak ölçülür.
  Eşzamanlı Başvurular	Birden fazla uygulama başlatıldığında, zaten çalışan bir uygulamayı yeniden başlatmak, ilk başlatma süresinden daha kısa sürmelidir.

  9. Güvenlik Modeli Uyumluluğu

  Cihaz uygulamalarında, Android geliştirici belgelerindeki API'ler [Kaynaklar, 42] bölümündeki Güvenlik ve İzinler referans belgesinde tanımlandığı şekilde Android platform güvenlik modeliyle tutarlı bir güvenlik modeli uygulanmalıdır. Cihaz uygulamaları, üçüncü taraflardan/yetkililerden ek izinler/sertifikalar gerektirmeden kendi kendine imzalanan uygulamaların yüklenmesini DESTEKLEMELİDİR. Daha açık belirtmek gerekirse, uyumlu cihazlar aşağıdaki alt bölümlerde açıklanan güvenlik mekanizmalarını DESTEKLEMELİDİR.

  9.1. İzinler

  Cihaz uygulamaları, Android geliştirici dokümanlarında [Kaynaklar, 42] tanımlandığı şekilde Android izin modelini DESTEKLEMELİDİR. Daha açık belirtmek gerekirse, uygulamalarda SDK dokümanlarında açıklandığı şekilde tanımlanan her izin ZORUNLU KILINACAK. Hiçbir izin atlanmamalı, değiştirilmemeli veya yok sayılmamalıdır. Yeni izin kimliği dizelerinin android.* ad alanında olmaması koşuluyla, uygulamalar ek izinler EKLEYEBİLİYOR.

  9.2. UID ve İşlem İzolasyon

  Cihaz uygulamalarında, her uygulamanın benzersiz bir Unix tarzı UID olarak ve ayrı bir işlemde çalıştığı Android uygulama korumalı alanı modeli desteklenmelidir. Cihaz uygulamalarında, Güvenlik ve İzinler referansında [Kaynaklar, 42] tanımlandığı şekilde uygulamaların düzgün şekilde imzalanması ve oluşturulması koşuluyla, aynı Linux kullanıcı kimliğiyle birden fazla uygulamanın çalıştırılması desteklenmelidir.

  9.3. Dosya sistemi izinleri

  Cihaz uygulamalarında, Güvenlik ve İzinler referansında [Kaynaklar, 42] tanımlandığı şekilde Android dosya erişim izinleri modeli desteklenmelidir.

  9.4. Alternatif Yürütme Ortamları

  Cihaz uygulamaları, Dalvik sanal makinesi veya yerel koddan başka bir yazılım ya da teknoloji kullanarak uygulamaları yürüten çalışma ortamı içerEBİLİR. Ancak bu tür alternatif yürütme ortamları, bu bölümde açıklandığı gibi Android güvenlik modelini veya yüklü Android uygulamalarının güvenliğini ÖNEMLİ ÖLÇÜDE ETKİLEMEmelidir.

  Alternatif çalışma ortamları Android uygulamaları olmalı ve Bölüm 9'da başka bir yerde açıklandığı gibi standart Android güvenlik modeline uymalıdır.

  Alternatif çalışma zamanlarına, çalışma zamanının AndroidManifest.xml dosyasında <uses-permission> mekanizması aracılığıyla istenmeyen izinlerle korunan kaynaklara erişim İÇİN VERİLMEMELİDİR.

  Alternatif çalışma zamanları, uygulamaların sistem uygulamalarıyla sınırlı Android izinleriyle korunan özellikleri kullanmasına İZİN VERMEMELİDİR.

  Alternatif çalışma zamanları Android korumalı alan modeline UYGUN OLMALIDIR. Özellikle:

  • Alternatif çalışma ortamları, uygulamaları PackageManager aracılığıyla ayrı Android korumalı alanlarına (ör. Linux kullanıcı kimlikleri) yüklemelidir.
  • Alternatif çalışma ortamları, alternatif çalışma ortamını kullanan tüm uygulamalar tarafından paylaşılan tek bir Android korumalı alanı sağlayabilir.
  • Alternatif çalışma ortamları ve alternatif çalışma ortamı kullanan yüklü uygulamalar, cihazda yüklü diğer uygulamaların korumalı alanını, paylaşılan kullanıcı kimliği ve imzalama sertifikası gibi standart Android mekanizmaları aracılığıyla kullanmak dışında TEKRAR KULLANMAMALIDIR.
  • Alternatif çalışma ortamları, diğer Android uygulamalarına karşılık gelen korumalı alanlarla birlikte başlatılmamalı, bu alanlara erişim izni vermemeli veya bu alanlara erişim izni almamalıdır.

  Alternatif çalışma zamanları, süper kullanıcının (root) veya başka bir kullanıcı kimliğinin ayrıcalıklarıyla başlatılmamalı, bu ayrıcalıklara sahip olmamalı ya da diğer uygulamalara bu ayrıcalıkları vermemelidir.

  Alternatif çalışma zamanlarının .apk dosyaları bir cihaz uygulamasının sistem resmine dahil EDİLEBİLİR ancak cihaz uygulamasına dahil edilen diğer uygulamaları imzalamak için kullanılan anahtardan farklı bir anahtarla İMZALANACAK.

  Alternatif çalışma zamanları, uygulamaları yüklerken uygulama tarafından kullanılan Android izinleri için kullanıcı izni ALMAK ZORUNDADIR. Yani, bir uygulamanın, ilgili Android izninin bulunduğu bir cihaz kaynağını (ör. kamera, GPS vb.) kullanması gerekiyorsa alternatif çalışma zamanı, kullanıcıyı uygulamanın bu kaynağa erişebileceği konusunda BİLGİLENDİRMELİDİR. Çalışma zamanı ortamı, uygulama özelliklerini bu şekilde kaydetmiyorsa çalışma zamanı ortamı, bu çalışma zamanını kullanan herhangi bir uygulamayı yüklerken çalışma zamanının sahip olduğu tüm izinleri LİSTELEMELİDİR.

  10. Yazılım Uyumluluğu Testi

  Android Açık Kaynak Projesi, cihaz uygulamalarının uyumlu olup olmadığını doğrulamak için çeşitli test araçları içerir. Cihaz uygulamalarının bu bölümde açıklanan tüm testleri KESİNLİKLE geçmesi gerekir.

  Ancak hiçbir yazılım test paketinin her şeyi kapsamadığını unutmayın. Bu nedenle, cihaz uygulayıcılarının Android Açık Kaynak Projesi'nde bulunan Android 2.3'ün referans ve tercih edilen uygulamasında mümkün olduğunca az değişiklik yapmaları önemle tavsiye edilir. Bu, yeniden çalışma ve olası cihaz güncellemeleri gerektiren uyumsuzluklara neden olan hataların eklenme riskini en aza indirir.

  10.1. Compatibility Test Suite

  Cihaz uygulamalarının, cihazdaki nihai gönderim yazılımını kullanarak Android Açık Kaynak Projesi'nden edinilebilen Android Uyumluluk Test Paketi'ni (CTS) [Kaynaklar, 2] GEÇMESİ GEREKİR. Ayrıca cihaz uygulayıcıları, Android Açık Kaynak ağacındaki referans uygulamayı mümkün olduğunca kullanmalı ve CTS'de belirsizlik olduğunda ve referans kaynak kodunun bölümlerinin yeniden uygulandığı durumlarda uyumluluğu sağlamalıdır.

  CTS, gerçek bir cihazda çalışacak şekilde tasarlanmıştır. Her yazılım gibi CTS de hata içerebilir. CTS, bu Uyumluluk Tanımı'ndan bağımsız olarak sürümlendirilir ve Android 2.3 için CTS'nin birden fazla düzeltmesi yayınlanabilir. Cihaz uygulamaları, cihaz yazılımı tamamlandığı sırada mevcut olan en son CTS sürümünü ZORUNLU KILINCA geçer.

  Cihazın yazılımı tamamlandığında mevcut olan Android Compatibility Test Suite (CTS) sürümünün en son sürümünü GEÇMELİDİR. (CTS, Android Açık Kaynak Projesi'nin [Kaynaklar, 2] bir parçası olarak kullanılabilir.) CTS, bu dokümanda belirtilen bileşenlerin tümünü olmasa da çoğunu test eder.

  10.2. CTS Doğrulayıcı

  Cihaz uygulamaları, CTS Doğrulayıcı'da geçerli tüm durumları doğru şekilde yürütmelidir. Uyumluluk Test Paketi'ne dahil olan CTS Doğrulayıcı, kamera ve sensörlerin düzgün çalışması gibi otomatik bir sistem tarafından test edilemeyecek işlevleri test etmek için bir operatör tarafından çalıştırılmak üzere tasarlanmıştır.

  CTS Doğrulayıcı, isteğe bağlı olan bazı donanımlar da dahil olmak üzere birçok donanım türü için testler içerir. Cihaz uygulamaları, sahip oldukları donanımla ilgili tüm testleri GEÇMELİDİR. Örneğin, bir cihazda ivmeölçer varsa CTS Doğrulayıcı'da İvmeölçer testini doğru şekilde yürütmelidir. Bu Uyumluluk Tanımı Belgesi'nde isteğe bağlı olarak belirtilen özelliklerle ilgili test durumları atlanabilir veya çıkarılabilir.

  Her cihaz ve her derleme, yukarıda belirtildiği gibi CTS Doğrulayıcı'yı doğru şekilde çalıştırmalıdır. Ancak birçok derleme birbirine çok benzediğinden, cihaz uygulayıcılarının yalnızca önemsiz farklılıklar gösteren derlemelerde CTS Doğrulayıcı'yı açıkça çalıştırması beklenmez. Daha açık belirtmek gerekirse, CTS Doğrulayıcı'yı yalnızca dahil edilen yerel ayarlar, marka vb. açısından geçen bir uygulamadan farklı olan cihaz uygulamaları CTS Doğrulayıcı testini EKSLEYEBİLİR.

  10.3. Referans Uygulamaları

  Cihaz uygulayıcıları, aşağıdaki açık kaynak uygulamaları kullanarak uygulama uyumluluğunu TEST ETMELİDİR:

  • "Android için Uygulamalar" uygulamaları [Kaynaklar, 43].
  • Replica Island (Android Market'te mevcuttur; yalnızca OpenGL ES 2.0 ile desteklenen cihaz uygulamalarında gereklidir)

  Uygulamanın uyumlu olarak kabul edilebilmesi için yukarıdaki her uygulamanın uygulamada başlatılması ve doğru şekilde çalışması GEREKİR.

  11. Güncellenebilir Yazılımlar

  Cihaz uygulamalarında, sistem yazılımının tamamını değiştirecek bir mekanizma BULUNMASI GEREKİR. Mekanizmanın "canlı" yükseltmeler yapması gerekmez. Yani cihazın yeniden başlatılması GEREKEBİLİR.

  Cihazın önceden yüklenmiş yazılımının tamamını değiştirebildiği sürece herhangi bir yöntem kullanılabilir. Örneğin, aşağıdaki yaklaşımlardan herhangi biri bu koşulu karşılar:

  • Yeniden başlatma yoluyla çevrimdışı güncelleme ile kablosuz (OTA) indirmeler
  • Ana makine PC'den USB üzerinden "bağlantılı" güncellemeler
  • Yeniden başlatma ve çıkarılabilir depolama alanındaki bir dosyadan güncelleme yoluyla "Çevrimdışı" güncellemeler

  Kullanılan güncelleme mekanizması, kullanıcı verilerini silmeden güncellemeleri desteklemelidir. Yukarı akış Android yazılımının bu koşulu karşılayan bir güncelleme mekanizması içerdiğini unutmayın.

  Bir cihaz uygulamasında, cihaz kullanıma sunulduktan sonra ancak Android Uyumluluk Ekibi ile yapılan danışma sonucunda belirlenen makul ürün ömrü içinde üçüncü taraf uygulamalarının uyumluluğunu etkileyecek bir hata bulunursa cihaz uygulayıcısı, hatayı az önce açıklanan mekanizmaya göre uygulanabilen bir yazılım güncellemesi aracılığıyla DÜZELTMEKTE ZORUNLUDUR.

  12. Bize Ulaşın

  Açıklamalar almak ve dokümanda yer almadığını düşündüğünüz sorunları bildirmek için compatibility@android.com adresinden doküman yazarlarıyla iletişime geçebilirsiniz.

  Ek A - Bluetooth Test Prosedürü

  Uyumluluk Testi Paketi, Android RFCOMM Bluetooth API'nin temel işlevlerini kapsayan test örneklerini içerir. Ancak Bluetooth, cihazlar arasındaki bir iletişim protokolü olduğundan tek bir cihazda çalışan birim testleriyle tam olarak test edilemez. Bu nedenle, cihaz uygulamaları aşağıda açıklanan manuel olarak çalıştırılan Bluetooth test prosedürünü de ZORUNLU KILINACAK.

  Test prosedürü, Android açık kaynak proje ağacında bulunan BluetoothChat örnek uygulamasına dayanır. Bu işlem için iki cihaz gerekir:

  • Test edilecek yazılım derlemesini çalıştıran bir cihaz uygulaması
  • Uyumlu olduğu bilinen ve test edilen cihaz uygulamasından farklı bir modele sahip ayrı bir cihaz uygulaması (yani "iyi bilinen" bir cihaz uygulaması)

  Aşağıdaki test prosedüründe bu cihazlar sırasıyla "aday" ve "iyi bilinen" cihazlar olarak adlandırılır.

  Yükleme ve Kurulum

  1. Android kaynak kodu ağacından "make samples" aracılığıyla BluetoothChat.apk'yi derleyin.
  2. BluetoothChat.apk dosyasını iyi durumdaki cihaza yükleyin.
  3. BluetoothChat.apk dosyasını aday cihaza yükleyin.

  Uygulamalara göre Bluetooth kontrolünü test etme

  1. Bluetooth devre dışıyken BluetoothChat'i aday cihazda başlatın.
  2. Aday cihazın Bluetooth'u açıp açmadığını veya kullanıcıdan Bluetooth'u açmasını isteyen bir iletişim kutusu gösterip göstermediğini doğrulayın.

  Eşlemeyi ve iletişimi test etme

  1. Her iki cihazda da Bluetooth Chat uygulamasını başlatın.
  2. Çalıştığı bilinen cihazı BluetoothChat'ten (Menü'yü kullanarak) bulunabilir hale getirin.
  3. Aday cihazda, BluetoothChat'ten (Menüyü kullanarak) Bluetooth cihazlarını tarayın ve iyi bilinen cihazla eşleyin.
  4. Her cihazdan 10 veya daha fazla mesaj gönderin ve diğer cihazın bunları doğru şekilde aldığını doğrulayın.
  5. Ana Sayfa'ya basarak BluetoothChat uygulamasını her iki cihazda da kapatın.
  6. Cihaz Ayarları uygulamasını kullanarak her cihazın eşlemesini kaldırın.

  Eşlemeyi ve iletişimi ters yönde test etme

  1. Her iki cihazda da Bluetooth Chat uygulamasını başlatın.
  2. Aday cihazı BluetoothChat'ten (Menü'yü kullanarak) bulunabilir hale getirin.
  3. Çalıştığı bilinen cihazda, BluetoothChat'ten (Menüyü kullanarak) Bluetooth cihazlarını tarayın ve aday cihazla eşleyin.
  4. Her cihazdan 10 veya daha fazla mesaj gönderin ve diğer cihazın bunları doğru şekilde aldığını doğrulayın.
  5. Başlatıcı'ya gitmek için Geri düğmesine art arda basarak her iki cihazda da Bluetooth Chat uygulamasını kapatın.

  Testi yeniden başlatma

  1. Bluetooth Chat uygulamasını her iki cihazda da yeniden başlatın.
  2. Her cihazdan 10 veya daha fazla mesaj gönderin ve diğer cihazın bunları doğru şekilde aldığını doğrulayın.

  Not: Yukarıdaki testlerde, bir test bölümünün Ana Sayfa'yı kullanarak sonlandırıldığı bazı durumlar ve Geri'yi kullanarak sonlandırıldığı bazı durumlar vardır. Bu testler gereksiz değildir ve isteğe bağlı değildir: Amaç, Bluetooth API'nin ve yığınının hem etkinlikler açıkça sonlandırılırken (kullanıcı Geri tuşuna basarak finish() çağrısını yaptığında) hem de dolaylı olarak arka plana gönderilirken (kullanıcı Ana Sayfa tuşuna basarak) düzgün çalıştığını doğrulamaktır. Her test dizisi açıklandığı şekilde YAPILMALIDIR.