Android 4.2 Uyumluluk Tanımı

Revizyon 2
Son güncelleme: 17 Şubat 2013

Telif Hakkı © 2012, Google Inc. Tüm hakları saklıdır.
uyumluluk@android.com

İçindekiler

1. Giriş
2. Kaynaklar
3. Yazılım
3.1. Yönetilen API Uyumluluğu
3.2. Yazılım API Uyumluluğu
3.3. Yerel API Uyumluluğu
3.4. Web Uyumluluğu
3.5. API Davranış Uyumluluğu
3.6. API Ad Alanları
3.7. Sanal Makine Uyumluluğu
3.8. Kullanıcı Arayüzü Uyumluluğu
3.9 Cihaz Yönetimi
3.10 Erişilebilirlik
3.11 Metinden Konuşmaya
4. Uygulama Paketleme Uyumluluğu
5. Multimedya Uyumluluğu
6. Geliştirici Araçları ve Seçeneklerinin Uyumluluğu
7. Donanım Uyumluluğu
7.1. Ekran ve Grafik
7.2. Giriş cihazları
7.3. Sensörler
7.4. Veri Bağlantısı
7.5. Kameralar
7.6. Bellek ve Depolama
7.7. USB
8. Performans Uyumluluğu
9. Güvenlik Modeli Uyumluluğu
10. Yazılım Uyumluluk Testi
11. Güncellenebilir Yazılım
12. Bize Ulaşın
Ek A - Bluetooth Test Prosedürü

1. Giriş

Bu belge, cihazların Android 4.2 ile uyumlu olması için karşılanması gereken gereksinimleri sıralamaktadır.

"Zorunlu", "yapmamalı", "gerekli", "yapmalı", "yapmamalı", "yapmalı", "yapmamalı", "önerilen", "olabilir" ve "isteğe bağlı" ifadelerinin kullanımı IETF standardına uygundur RFC2119'da tanımlanmıştır [ Kaynaklar, 1 ].

Bu belgede kullanıldığı şekliyle "cihaz uygulayıcısı" veya "uygulayıcı", Android 4.2 çalıştıran bir donanım/yazılım çözümü geliştiren kişi veya kuruluştur. Bir "cihaz uygulaması" veya "uygulama", bu şekilde geliştirilen donanım/yazılım çözümüdür.

Android 4.2 ile uyumlu sayılması için cihaz uygulamalarının, referans yoluyla dahil edilen tüm belgeler de dahil olmak üzere bu Uyumluluk Tanımında sunulan gereksinimleri karşılaması ZORUNLUDUR.

Bu tanımın veya Bölüm 10'da açıklanan yazılım testlerinin sessiz, belirsiz veya eksik olduğu durumlarda, mevcut uygulamalarla uyumluluğun sağlanması cihaz uygulayıcısı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 olan en geniş ölçüde Android Açık Kaynak Projesi'nde bulunan "yukarı akış" kaynak koduna dayandırmaları şiddetle tavsiye edilir. Bazı bileşenler varsayımsal olarak alternatif uygulamalarla değiştirilebilirken, yazılım testlerini geçmek büyük ölçüde zorlaşacağından bu uygulama kesinlikle önerilmez. Uyumluluk Test Paketi dahil ve ötesinde, standart Android uygulamasıyla tam davranışsal uyumluluğun sağlanması uygulayıcının sorumluluğundadır. Son olarak, belirli bileşen değişikliklerinin ve modifikasyonlarının bu belgede açıkça yasaklandığını unutmayın.

2. Kaynaklar

  1. IETF RFC2119 Gereksinim 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 belgeleri: http://developer.android.com/reference/packages.html
  5. Android İzinleri referansı: http://developer.android.com/reference/android/Manifest.permission.html
  6. android.os.Derleme referansı: http://developer.android.com/reference/android/os/Build.html
  7. Android 4.2'nin izin verdiği sürüm dizeleri: http://source.android.com/docs/compatibility/4.2/versions.html
  8. Oluşturma komut dosyası: http://developer.android.com/guide/topics/graphics/renderscript.html
  9. Donanım Hızlandırma: http://developer.android.com/guide/topics/graphics/hardware-accel.html
  10. android.webkit.WebView sınıfı: http://developer.android.com/reference/android/webkit/WebView.html
  11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  12. HTML5 çevrimdışı özellikleri: http://dev.w3.org/html5/spec/Overview.html#offline
  13. HTML5 video etiketi: http://dev.w3.org/html5/spec/Overview.html#video
  14. HTML5/W3C coğrafi konum API'si: http://www.w3.org/TR/geolocation-API/
  15. HTML5/W3C web veritabanı API'si: http://www.w3.org/TR/webdatabase/
  16. HTML5/W3C IndexedDB API'si: http://www.w3.org/TR/IndexedDB/
  17. Dalvik Sanal Makine özellikleri: Android kaynak kodunda, dalvik/docs adresinde mevcuttur
  18. Uygulama Widget'ları: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  19. Bildirimler: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  20. Uygulama Kaynakları: http://code.google.com/android/reference/available-resources.html
  21. Durum Çubuğu simgesi stil kılavuzu: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
  22. Arama Yöneticisi: http://developer.android.com/reference/android/app/SearchManager.html
  23. Tostlar: http://developer.android.com/reference/android/widget/Toast.html
  24. Temalar: http://developer.android.com/guide/topics/ui/themes.html
  25. R.style sınıfı: http://developer.android.com/reference/android/R.style.html
  26. Canlı Duvar Kağıtları: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  27. Android Cihaz Yönetimi: http://developer.android.com/guide/topics/admin/device-admin.html
  28. DevicePolicyManager referansı: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
  29. Android Erişilebilirlik Hizmeti API'leri: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
  30. Android Erişilebilirlik API'leri: http://developer.android.com/reference/android/view/accessibility/package-summary.html
  31. Gözler Özgür projesi: http://code.google.com/p/eyes-free
  32. Metinden Konuşmaya API'leri: http://developer.android.com/reference/android/speech/tts/package-summary.html
  33. Referans aracı belgeleri (adb, aapt, ddms, systrace için): http://developer.android.com/guide/developing/tools/index.html
  34. Android apk dosyası açıklaması: http://developer.android.com/guide/topics/fundamentals.html
  35. Bildirim dosyaları: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  36. Maymun test aracı: https://developer.android.com/studio/test/other-testing-tools/monkey
  37. Android android.content.pm.PackageManager sınıfı ve Donanım Özellikleri Listesi: http://developer.android.com/reference/android/content/pm/PackageManager.html
  38. Çoklu Ekranları Destekleme: http://developer.android.com/guide/practices/screens_support.html
  39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  40. android.content.res.Yapılandırma: http://developer.android.com/reference/android/content/res/Configuration.html
  41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
  42. Bluetooth API'si: http://developer.android.com/reference/android/bluetooth/package-summary.html
  43. NDEF Aktarma Protokolü: http://source.android.com/docs/compatibility/ndef-Push-protocol.pdf
  44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
  49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
  50. Kamera yönlendirme API'si: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  51. Kamera: http://developer.android.com/reference/android/hardware/Camera.html
  52. Android Açık Aksesuarları: http://developer.android.com/guide/topics/usb/accessory.html
  53. USB Ana Bilgisayar API'si: http://developer.android.com/guide/topics/usb/host.html
  54. Android Güvenliği ve İzinleri referansı: http://developer.android.com/guide/topics/security/security.html
  55. Android için uygulamalar: http://code.google.com/p/apps-for-android
  56. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html
  57. Android Dosya Aktarımı: http://www.android.com/filetransfer
  58. Android Medya Formatları: http://developer.android.com/guide/appendix/media-formats.html
  59. HTTP Canlı Akış Taslak Protokolü: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
  60. NFC Bağlantı Devri: http://www.nfc-forum.org/specs/spec_list/#conn_handover
  61. NFC Kullanarak Bluetooth Güvenli Basit Eşleştirme: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
  62. Wifi Çoklu Yayın API'si: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
  63. Eylem Yardımı: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
  64. USB Şarj Özelliği: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
  65. Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
  66. Android USB Sesi: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
  67. Android NFC Paylaşım Ayarları: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
  68. Wifi Doğrudan (Wifi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
  69. Kilit ve Ana Ekran Widget'ı: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
  70. UserManager referansı: http://developer.android.com/reference/android/os/UserManager.html
  71. Harici Depolama referansı: https://source.android.com/docs/core/storage
  72. Harici Depolama API'leri: http://developer.android.com/reference/android/os/Environment.html
  73. SMS Kısa Kodu: http://en.wikipedia.org/wiki/Short_code
  74. Medya Uzaktan Kumanda İstemcisi: http://developer.android.com/reference/android/media/RemoteControlClient.html
  75. Görüntü Yöneticisi: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
  76. Rüyalar: http://developer.android.com/reference/android/service/dreams/DreamService.html
  77. Android Uygulama Geliştirmeyle İlgili Ayarlar: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
  • Kamera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
  • Bu kaynakların birçoğu doğrudan veya dolaylı olarak Android 4.2 SDK'sından türetilmiştir ve işlevsel olarak söz konusu SDK'nın belgelerindeki bilgilerle aynı olacaktır. Bu Uyumluluk Tanımının veya Uyumluluk Test Paketinin SDK belgeleriyle uyuşmadığı durumlarda, SDK belgeleri yetkili kabul edilir. Yukarıda yer alan referanslarda sağlanan tüm teknik ayrıntılar, dahil edilmek suretiyle bu Uyumluluk Tanımının bir parçası olarak kabul edilir.

    3. Yazılım

    3.1. Yönetilen API Uyumluluğu

    Yönetilen (Dalvik tabanlı) yürütme ortamı, Android uygulamaları için birincil araçtır. Android uygulama programlama arayüzü (API), yönetilen VM ortamında çalışan uygulamalara sunulan Android platformu arayüzleri kümesidir. Cihaz uygulamalarının, Android 4.2 SDK tarafından kullanıma sunulan herhangi bir belgelenmiş API'nin tüm belgelenmiş davranışları da dahil olmak üzere eksiksiz uygulamalarını sağlaması ZORUNLUDUR [ Kaynaklar, 4 ].

    Cihaz uygulamaları, bu Uyumluluk Tanımında özellikle izin verilen durumlar dışında, yönetilen API'leri atlamamalı, API arayüzlerini veya imzalarını değiştirmemeli, belgelenen davranıştan sapmamalı veya işlem yapılmayan işlemleri İÇERMEMELİDİR.

    Bu Uyumluluk Tanımı, Android'in API'ler içerdiği bazı donanım türlerinin cihaz uygulamalarından çıkarılmasına izin verir. Bu gibi durumlarda API'lerin hâlâ mevcut olması ve makul bir şekilde davranması GEREKİR. Bu senaryoya özel gereksinimler için Bölüm 7'ye bakın.

    3.2. Yazılım API Uyumluluğu

    Bölüm 3.1'deki yönetilen API'lere ek olarak, Android aynı zamanda Amaçlar, izinler ve Android uygulamalarının uygulama derleme zamanında uygulanamayan benzer yönleri gibi önemli bir yalnızca çalışma zamanında "yazılımsal" API içerir.

    3.2.1. İzinler

    Cihaz uygulayıcılarının, İzin referans sayfasında [ Kaynaklar, 5 ] belgelendiği şekilde tüm izin sabitlerini desteklemesi ve uygulaması ZORUNLUDUR. Bölüm 10'un Android güvenlik modeliyle ilgili ek gereksinimleri listelediğini unutmayın.

    3.2.2. Parametreleri Oluştur

    Android API'leri, android.os.Build sınıfında [ Kaynaklar, 6 ] mevcut cihazı tanımlaması amaçlanan bir dizi sabit içerir. Cihaz uygulamalarında tutarlı, anlamlı değerler sağlamak için aşağıdaki tablo, cihaz uygulamalarının uyması GEREKEN bu değerlerin formatlarına ilişkin ek kısıtlamalar içerir.

    Parametre Yorumlar
    android.os.Build.VERSION.RELEASE Şu anda çalışmakta olan Android sisteminin insan tarafından okunabilir biçimdeki sürümü. Bu alanın [ Kaynaklar, 7 ]'de tanımlanan dize değerlerinden birine sahip olması ZORUNLUDUR.
    android.os.Build.VERSION.SDK Şu anda çalışmakta olan Android sisteminin, üçüncü taraf uygulama kodunun erişebileceği bir biçimdeki sürümü. Android 4.2 için bu alanın 17 tamsayı değerine sahip olması GEREKİR.
    android.os.Build.VERSION.SDK_INT Şu anda çalışmakta olan Android sisteminin, üçüncü taraf uygulama kodunun erişebileceği bir biçimdeki sürümü. Android 4.2 için bu alanın 17 tamsayı değerine sahip olması GEREKİR.
    android.os.Build.VERSION.INCREMENTAL Cihaz uygulayıcısı tarafından seçilen ve halihazırda çalışmakta olan Android sisteminin belirli yapısını insan tarafından okunabilir biçimde belirten bir değer. Bu değer, son kullanıcılara sunulan farklı yapılar için yeniden KULLANILMAMALIDIR. Bu alanın tipik bir kullanımı, yapıyı oluşturmak için hangi yapı numarasının veya kaynak kontrol değişikliği tanımlayıcısının kullanıldığını belirtmektir. Bu alanın spesifik formatına ilişkin herhangi bir gereklilik yoktur, ancak boş veya boş dize ("") OLMAMALIDIR.
    android.os.Build.BOARD Cihaz tarafından kullanılan belirli dahili donanımı tanımlayan, cihaz uygulayıcısı tarafından seçilen, insan tarafından okunabilir formatta bir değer. Bu alanın olası bir kullanımı, cihaza güç veren kartın özel revizyonunu belirtmektir. Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir ZORUNLU.
    android.os.Build.BRAND Cihaz uygulayıcısı tarafından seçilen, cihazı üreten şirket, kuruluş, şahıs vb. adını insanların okuyabileceği formatta tanımlayan bir değer. Bu alanın olası bir kullanımı, cihazı satan OEM'i ve/veya taşıyıcıyı belirtmektir. Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir ZORUNLU.
    android.os.Build.CPU_ABI Yerel kodun talimat setinin adı (CPU türü + ABI kuralı). Bkz. Bölüm 3.3: Yerel API Uyumluluğu .
    android.os.Build.CPU_ABI2 Yerel kodun ikinci komut kümesinin adı (CPU türü + ABI kuralı). Bkz. Bölüm 3.3: Yerel API Uyumluluğu .
    android.os.Build.DEVICE Cihaz uygulayıcısı tarafından seçilen, cihazın gövdesinin (bazen "endüstriyel tasarım" olarak da adlandırılır) spesifik konfigürasyonunu veya revizyonunu 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 ZORUNLU.
    android.os.Build.FINGERPRINT Bu yapıyı benzersiz şekilde tanımlayan bir dize. Makul düzeyde insan tarafından okunabilir OLMALIDIR. Bu şablona uyması GEREKİR:
    $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
    Örneğin:
    acme/mydevice/generic:4.2/JRN53/3359:userdebug/test-keys
    Parmak izi boşluk karakterleri İÇERMEMELİDİR. Yukarıdaki şablonda yer alan diğer alanlarda boşluk karakterleri varsa, bunların yapı parmak izinde alt çizgi ("_") karakteri gibi başka bir karakterle değiştirilmesi GEREKİR. Bu alanın değeri 7 bitlik ASCII olarak kodlanabilir OLMALIDIR.
    android.os.Build.HARDWARE Donanımın adı (çekirdek komut satırından veya /proc'tan). Makul düzeyde insan tarafından okunabilir OLMALIDIR. Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir ZORUNLU.
    android.os.Build.HOST Yapının oluşturulduğu ana bilgisayarı, insanlar tarafından okunabilir biçimde benzersiz şekilde tanımlayan bir dize. Bu alanın spesifik formatına ilişkin herhangi bir gereklilik yoktur, ancak boş veya boş dize ("") OLMAMALIDIR.
    android.os.Build.ID Cihaz uygulayıcısı tarafından belirli bir yayına atıfta bulunmak üzere seçilen, insanlar tarafından okunabilir formatta bir tanımlayıcı. Bu alan android.os.Build.VERSION.INCREMENTAL ile aynı olabilir, ancak son kullanıcıların yazılım yapıları 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 ZORUNLU.
    android.os.Build.ÜRETİCİ Ürünün Orijinal Ekipman Üreticisinin (OEM) ticari adı. Bu alanın spesifik formatına ilişkin herhangi bir gereklilik yoktur, ancak boş veya boş dize ("") OLMAMALIDIR.
    android.os.Build.MODEL Cihaz uygulayıcısı tarafından seçilen ve son kullanıcının bildiği cihazın adını içeren bir değer. Bu, cihazın pazarlandığı ve son kullanıcılara satıldığı adla aynı OLMALIDIR. Bu alanın spesifik formatına ilişkin herhangi bir gereklilik yoktur, ancak boş veya boş dize ("") OLMAMALIDIR.
    android.os.Build.PRODÜKTÖR Ürünün geliştirme adını veya kod adını (SKU) içeren, cihaz uygulayıcısı tarafından seçilen bir değer. İnsan tarafından okunabilir OLMALIDIR ancak son kullanıcıların görüntülemesi amaçlanmamıştır. Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir ZORUNLU.
    android.os.Build.SERIAL Varsa bir donanım seri numarası. Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^([a-zA-Z0-9]{0,20})$" normal ifadesiyle eşleşmelidir ZORUNLU.
    android.os.Build.TAGS Yapıyı daha da ayırt eden, cihaz uygulayıcısı tarafından seçilen, virgülle ayrılmış etiket listesi. Örneğin, "imzasız, hata ayıklama". Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir ZORUNLU.
    android.os.Build.TIME Derlemenin gerçekleştiği zamanın zaman damgasını temsil eden bir değer.
    android.os.Build.TYPE Yapının çalışma zamanı yapılandırmasını belirten, cihaz uygulayıcısı tarafından seçilen bir değer. Bu alanın üç tipik Android çalışma zamanı yapılandırmasına karşılık gelen değerlerden birine sahip olması GEREKİR: "user", "userdebug" veya "eng". Bu alanın değeri 7 bit ASCII olarak kodlanabilir ve "^[a-zA-Z0-9.,_-]+$" normal ifadesiyle eşleşmelidir ZORUNLU.
    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 spesifik formatına ilişkin herhangi bir gereklilik yoktur, ancak boş veya boş dize ("") OLMAMALIDIR.

    3.2.3. Amaç Uyumluluğu

    Cihaz uygulamalarının, aşağıdaki bölümlerde açıklandığı gibi Android'in gevşek bağlantı Intent sistemini dikkate alması ZORUNLUDUR. "Onurlandırıldı" ile, cihaz uygulayıcısının, eşleşen bir Amaç filtresini belirten ve belirtilen her bir Amaç modeli için doğru davranışı bağlayan ve uygulayan bir Android Etkinliği veya Hizmeti sağlaması ZORUNLU olduğu anlamına gelir.

    3.2.3.1. Temel Uygulama Amaçları

    Android yukarı akış projesi kişiler, takvim, fotoğraf galerisi, müzik çalar vb. gibi bir dizi temel uygulamayı tanımlar. Cihaz uygulayıcıları bu uygulamaları alternatif versiyonlarla değiştirebilirler.

    Bununla birlikte, bu tür alternatif versiyonların yukarı akış projesi tarafından sağlanan aynı Niyet modellerine uyması ZORUNLUDUR. Örneğin, bir cihaz alternatif bir müzik çalar içeriyorsa, bir şarkıyı seçmek için yine de üçüncü taraf uygulamalar tarafından verilen Niyet modelini dikkate almalıdır.

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

    • Masa saati
    • Tarayıcı
    • Takvim
    • Kişiler
    • Galeri
    • Küresel Arama
    • Başlatıcı
    • Müzik
    • Ayarlar

    Çekirdek Android sistem uygulamaları, "herkese açık" olarak kabul edilen çeşitli Etkinlik veya Hizmet bileşenlerini 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 olarak işaretlenmeyen her Etkinlik veya Hizmet için, cihaz uygulamalarının, aynı Amaç filtresini uygulayan aynı türde bir bileşen içermesi ZORUNLUDUR çekirdek Android sistem uygulaması olarak desenler.

    Başka bir deyişle, bir cihaz uygulaması çekirdek Android sistem uygulamalarının yerini OLABİLİR; ancak eğer öyleyse, cihaz uygulamasının değiştirilen her bir çekirdek Android sistem uygulaması tarafından tanımlanan tüm Niyet modellerini desteklemesi ZORUNLUDUR.

    3.2.3.2. Niyet Geçersiz Kılmaları

    Android genişletilebilir bir platform olduğundan, cihaz uygulamalarının Bölüm 3.2.3.2'de atıfta bulunulan her bir Amaç modelinin üçüncü taraf uygulamalar tarafından geçersiz kılınmasına izin vermesi ZORUNLUDUR. Yukarı akışlı Android açık kaynak uygulaması buna varsayılan olarak izin verir; aygıt uygulayıcıları, sistem uygulamalarının bu Amaç kalıplarını kullanımına özel ayrıcalıklar VERMEMELİ veya üçüncü taraf uygulamaların bu kalıplara bağlanmasını ve bunların kontrolünü üstlenmesini engellememelidir. Bu yasak, özellikle, kullanıcının tümü aynı Intent modelini 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 bununla sınırlı değildir.

    Ancak, varsayılan etkinliğin veri URI'si için daha spesifik bir filtre sağlaması durumunda, cihaz uygulamaları belirli URI kalıpları için varsayılan etkinlikler (örn. http://play.google.com) SAĞLAYABİLİR. Örneğin, "http://www.android.com" veri URI'sini belirten bir amaç filtresi, "http://" için tarayıcı filtresinden daha spesifiktir. Cihaz uygulamalarının, kullanıcıların amaçlara yönelik varsayılan etkinliği değiştirebilmesi için bir kullanıcı arayüzü sağlaması ZORUNLUDUR.

    3.2.3.3. Amaç Ad Alanları

    Cihaz uygulamaları, android.* veya com.android.* ad alanındaki bir ACTION, CATEGORY veya başka bir anahtar dize kullanan herhangi bir yeni Intent veya Broadcast Intent modelini kabul eden herhangi bir Android bileşeni İÇERMEMELİDİR. Cihaz uygulayıcıları, başka bir kuruluşa ait olan bir paket alanına bir EYLEM, KATEGORİ veya başka bir anahtar dize kullanan herhangi bir yeni Amaç veya Yayın Amacı modelini kabul eden herhangi bir Android bileşenini EKLEMEMELİDİR. Cihaz uygulayıcıları, Bölüm 3.2.3.1'de listelenen temel uygulamalar tarafından kullanılan Niyet modellerinden herhangi birini DEĞİŞTİRMEMELİ veya GELİŞTİRMEMELİDİR. Cihaz uygulamaları, kendi kuruluşlarıyla açık ve net bir şekilde ilişkilendirilen ad alanlarını kullanan Intent kalıplarını İÇEREBİLİR.

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

    3.2.3.4. Yayın Amaçları

    Üçüncü taraf uygulamalar, donanım veya yazılım ortamındaki değişiklikler hakkında kendilerini bilgilendirmek amacıyla belirli Amaçları yayınlamak için platforma güvenir. Android uyumlu cihazlar, uygun sistem olaylarına yanıt olarak genel yayın Amaçlarını yayınlamalıdır ZORUNLU. Yayın Amaçları SDK belgelerinde açıklanmaktadır.

    3.3. Yerel API Uyumluluğu

    3.3.1 Uygulama İkili Arayüzleri

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

    Bir cihaz uygulaması Android ABI desteğini içeriyorsa:

    • Standart Java Yerel Arayüzü (JNI) semantiğini kullanarak, yerel kodu çağırmak için yönetilen ortamda çalışan kod desteğini içermelidir ZORUNLU.
    • Aşağıdaki listede yer alan her gerekli kitaplıkla kaynak uyumlu (yani başlık uyumlu) ve ikili uyumlu (ABI için) OLMALIDIR
    • Cihaz tarafından desteklenen yerel Uygulama İkili Arayüzünü (ABI) android.os.Build.CPU_ABI API aracılığıyla doğru bir şekilde raporlaması GEREKİR
    • docs/CPU-ARCH-ABIS.txt dosyasında yalnızca Android NDK'nın en son sürümünde belgelenen ABI'leri rapor etmesi GEREKİR
    • Yukarı akışlı Android açık kaynak projesinde bulunan kaynak kodu ve başlık dosyaları kullanılarak OLUŞTURULMALIDIR

    Aşağıdaki yerel kod API'lerinin yerel kod içeren uygulamalarda mevcut olması GEREKİR:

    • libc (C kütüphanesi)
    • libm (matematik kütüphanesi)
    • C++ için minimum destek
    • JNI arayüzü
    • liblog (Android günlüğü)
    • 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 (OpenSL ES 1.0.1 ses desteği)
    • libOpenMAXAL.so (OpenMAX AL 1.0.1 desteği)
    • libandroid.so (yerel Android etkinlik desteği)
    • Aşağıda açıklandığı gibi OpenGL desteği

    Android NDK'nın gelecek sürümlerinin ek ABI'ler için destek sunabileceğini unutmayın. Bir cihaz uygulaması mevcut önceden tanımlanmış bir ABI ile uyumlu değilse, herhangi bir ABI için destek bildirmemesi ZORUNLUDUR.

    Yerel kod uyumluluğu zordur. Bu nedenle, uyumluluğun sağlanmasına yardımcı olmak için cihaz uygulayıcılarının yukarıda listelenen kitaplıkların yukarı akış uygulamalarını kullanmalarının ÇOK güçlü bir şekilde teşvik edildiği tekrarlanmalıdır.

    3.4. Web Uyumluluğu

    3.4.1. Web Görünümü Uyumluluğu

    Android Açık Kaynak uygulaması, android.webkit.WebView öğesini uygulamak için WebKit oluşturma motorunu kullanır. Bir web işleme sistemi için kapsamlı bir test paketi geliştirmek mümkün olmadığından, cihaz uygulayıcılarının WebView uygulamasında WebKit'in belirli yukarı akış yapısını kullanması ZORUNLUDUR. Özellikle:

    • Cihaz uygulamalarının android.webkit.WebView uygulamaları, Android 4.2 için yukarı akışlı Android Açık Kaynak ağacından alınan 534.30 WebKit yapısını temel almalıdır ZORUNLU. Bu yapı, Web Görünümü için belirli bir dizi işlevsellik ve güvenlik düzeltmesi içerir. Cihaz uygulayıcıları WebKit uygulamasına özelleştirmeler dahil edebilir; ancak bu tür özelleştirmelerin, oluşturma davranışı da dahil olmak üzere Web Görünümü davranışını DEĞİŞTİRMEMESİ gerekir.
    • Web Görünümü tarafından bildirilen kullanıcı aracısı dizesi şu formatta OLMALIDIR:
      Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.2 Mobile Safari/534.30
      • $(VERSION) dizesinin değeri, android.os.Build.VERSION.RELEASE değeriyle aynı OLMALIDIR
      • $(LOCALE) dizesinin değeri, ülke kodu ve dil için ISO kurallarına uymalı ve cihazın geçerli yapılandırılmış yerel ayarına gönderme yapmalıdır GEREKLİ
      • $(MODEL) dizesinin değeri, android.os.Build.MODEL değeriyle aynı OLMALIDIR
      • $(BUILD) dizesinin değeri, android.os.Build.ID değeriyle aynı OLMALIDIR
      • Cihaz uygulamaları, kullanıcı aracısı dizesinde Mobile ihmal edebilir

    WebView bileşeninin mümkün olduğu kadar çok HTML5 [ Kaynaklar, 11 ] desteğini içermesi GEREKLİdir. Asgari olarak, cihaz uygulamalarının Web Görünümünde HTML5 ile ilişkili bu API'lerin her birini desteklemesi ZORUNLUDUR:

    Ek olarak, cihaz uygulamalarının HTML5/W3C web depolama API'sini [ Kaynaklar, 15 ] desteklemesi ZORUNLUDUR ve HTML5/W3C IndexedDB API'sini [ Kaynaklar, 16 ] DESTEKLEMELİDİR. Web geliştirme standartları kuruluşları web depolama yerine IndexedDB'yi tercih etmeye başladıkça, IndexedDB'nin Android'in gelecekteki bir sürümünde gerekli bir bileşen haline gelmesinin beklendiğini unutmayın.

    HTML5 API'leri, tüm JavaScript API'leri gibi, geliştirici bunları normal Android API'leri aracılığıyla açıkça etkinleştirmediği sürece, bir Web Görünümünde varsayılan olarak devre dışı bırakılmalıdır ZORUNLU.

    3.4.2. Tarayıcı Uyumluluğu

    Cihaz uygulamalarının, genel kullanıcı web taraması için bağımsız bir Tarayıcı uygulaması içermesi ZORUNLUDUR. Bağımsız Tarayıcı, WebKit dışında bir tarayıcı teknolojisini temel alıyor OLABİLİR. Ancak alternatif bir Tarayıcı uygulaması kullanılsa bile, üçüncü taraf uygulamalara sağlanan android.webkit.WebView bileşeninin Bölüm 3.4.1'de açıklandığı gibi WebKit'i temel alması ZORUNLUDUR.

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

    Bağımsız Tarayıcı uygulaması (ister yukarı akışlı WebKit Tarayıcı uygulamasına ister üçüncü taraf yerine geçen bir uygulamaya dayalı olsun) mümkün olduğu kadar çok HTML5 [ Kaynaklar, 11 ] desteği içermelidir *ÖNERİ. Cihaz uygulamalarının asgari olarak HTML5 ile ilişkili bu API'lerin her birini desteklemesi ZORUNLUDUR:

    Ek olarak, cihaz uygulamalarının HTML5/W3C web depolama API'sini [ Kaynaklar, 15 ] desteklemesi ZORUNLUDUR ve HTML5/W3C IndexedDB API'sini [ Kaynaklar, 16 ] DESTEKLEMELİDİR. Web geliştirme standartları kuruluşları web depolama yerine IndexedDB'yi tercih etmeye başladıkça, IndexedDB'nin Android'in gelecekteki bir sürümünde gerekli bir bileşen haline gelmesinin beklendiğini unutmayın.

    3.5. API Davranış Uyumluluğu

    API türlerinin her birinin (yönetilen, yazılımsal, yerel ve web) davranışları, yukarı akışlı Android açık kaynak projesinin tercih edilen uygulamasıyla tutarlı olmalıdır [ Kaynaklar, 3 ]. Bazı spesifik uyumluluk alanları şunlardır:

    • Cihazlar standart bir Amacın davranışını veya anlamını DEĞİŞTİRMEMELİDİR
    • Cihazlar, belirli bir sistem bileşeni türünün (Servis, Etkinlik, ContentProvider vb.) yaşam döngüsünü veya yaşam döngüsü semantiğini DEĞİŞTİRMEMELİDİR.
    • Cihazlar standart bir iznin anlamını DEĞİŞTİRMEMELİDİR

    Yukarıdaki liste kapsamlı değildir. Uyumluluk Test Paketi (CTS), platformun önemli kısımlarını davranışsal uyumluluk açısından test eder, ancak tamamını test etmez. Android Açık Kaynak Projesi ile davranışsal uyumluluğun sağlanması uygulayıcının sorumluluğundadır. Bu nedenle, cihaz uygulayıcılarının sistemin önemli kısımlarını yeniden uygulamak yerine, mümkün olan yerlerde Android Açık Kaynak Projesi aracılığıyla sağlanan kaynak kodunu kullanması GEREKLİdir.

    3.6. API Ad Alanları

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

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

    Yasaklanan değişiklikler şunları içerir:

    • Cihaz uygulamaları, herhangi bir yöntemi veya sınıf imzasını değiştirerek veya sınıfları veya sınıf alanlarını kaldırarak Android platformundaki genel kullanıma açık API'leri DEĞİŞTİRMEMELİDİR.
    • Cihaz uygulayıcıları, API'lerin temel uygulamasını DEĞİŞTİREBİLİR, ancak bu tür değişiklikler, kamuya açık API'lerin belirtilen davranışını ve Java dili imzasını ETKİLEMEMELİDİR.
    • Cihaz uygulayıcıları yukarıdaki API'lere genel kullanıma açık herhangi bir öğe (sınıflar veya arayüzler veya mevcut sınıflara veya arayüzlere alanlar veya yöntemler gibi) EKLEMEMELİDİR.

    "Herkese açık öğe", yukarı akışlı Android kaynak kodunda kullanıldığı gibi "@hide" işaretçisiyle donatılmayan herhangi bir yapıdır. Başka bir deyişle, cihaz uygulayıcılarının yukarıda belirtilen ad alanlarında yeni API'leri açığa çıkarmaması veya mevcut API'leri değiştirmemesi ZORUNLUDUR. Cihaz uygulayıcıları yalnızca dahili değişiklikler YAPABİLİR, ancak bu değişikliklerin reklamı YAPILMAMALIDIR veya başka bir şekilde geliştiricilere sunulmamalıdır.

    Cihaz uygulayıcıları özel API'ler EKLEYEBİLİR, ancak bu tür API'lerin herhangi biri başka bir kuruluşa ait olan veya başka bir kuruluşa atıfta bulunan bir ad alanında OLMAMALIDIR. Örneğin, cihaz uygulayıcılarının com.google.* veya benzer ad alanına API'ler EKLEMEMELİDİR; bunu yalnızca Google yapabilir. Benzer şekilde Google, diğer şirketlerin ad alanlarına API EKLEMEMELİDİR. Ek olarak, bir cihaz uygulaması standart Android ad alanı dışında özel API'ler içeriyorsa, bu API'lerin bir Android paylaşılan kitaplığında paketlenmesi GEREKİR; böylece yalnızca bunları açıkça kullanan uygulamalar ( <uses-library> mekanizması aracılığıyla) artan bellek kullanımından etkilenir. bu tür API'lerden.

    Bir cihaz uygulayıcısı yukarıdaki paket ad alanlarından birini iyileştirmeyi teklif ederse (mevcut bir API'ye kullanışlı yeni işlevler ekleyerek veya yeni bir API ekleyerek), uygulayıcının source.android.com adresini ziyaret etmesi ve değişikliklere katkıda bulunma sürecini başlatması GEREKLİdir. Bu sitedeki bilgilere göre kod.

    Yukarıdaki kısıtlamaların, Java programlama dilinde API'leri adlandırmaya ilişkin standart kurallara karşılık geldiğini unutmayın; bu bölüm basitçe bu sözleşmeleri güçlendirmeyi ve bu uyumluluk tanımına dahil ederek onları bağlayıcı kılmayı amaçlamaktadır.

    3.7. Sanal Makine Uyumluluğu

    Cihaz uygulamalarının Dalvik Yürütülebilir (DEX) bayt kodu spesifikasyonunun ve Dalvik Sanal Makine semantiğinin tamamını desteklemesi ZORUNLUDUR [ Kaynaklar, 17 ].

    Cihaz uygulamalarının Dalvik'i, yukarı akışlı Android platformuna uygun olarak ve aşağıdaki tabloda belirtildiği şekilde bellek ayıracak şekilde yapılandırması ZORUNLUDUR. (Ekran boyutu ve ekran yoğunluğu tanımları için Bölüm 7.1.1'e bakın.)

    Aşağıda belirtilen bellek değerlerinin minimum değerler olarak kabul edildiğini ve cihaz uygulamalarının uygulama başına daha fazla bellek ayırabileceğini unutmayın.

    Ekran boyutu Ekran Yoğunluğu Uygulama Belleği
    küçük / normal / büyük ldpi / mdpi 16MB
    küçük / normal / büyük tvdpi / hdpi 32MB
    küçük / normal / büyük xhdpi 64MB
    xlarge mdpi 32MB
    xlarge tvdpi / hdpi 64MB
    xlarge xhdpi 128MB

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

    3.8.1. Widget'lar

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

    Cihaz uygulamaları, referans Başlatıcının (yani ana ekranın) alternatifinin yerine OLABİLİR. Alternatif Başlatıcılar, AppWidget'lar için yerleşik destek içermeli ve AppWidget'ları doğrudan Başlatıcı içinde eklemek, yapılandırmak, görüntülemek ve kaldırmak için kullanıcı arayüzü olanaklarını ortaya çıkarmalıdır. Alternatif Başlatıcılar bu kullanıcı arayüzü öğelerini İÇERMEYEBİLİR; ancak bunlar atlanırsa, cihaz uygulamasının Başlatıcıdan erişilebilen, kullanıcıların AppWidget'ları eklemesine, yapılandırmasına, görüntülemesine ve kaldırmasına olanak tanıyan ayrı bir uygulama sağlaması ZORUNLUDUR.

    Cihaz uygulamalarının standart ızgara boyutunda 4 x 4'lük widget'ları işleme kapasitesine sahip olması ZORUNLUDUR. (Ayrıntılar için Android SDK belgelerindeki [ Kaynaklar, 18 ] Uygulama Widget Tasarım Yönergelerine bakın.

    3.8.2. Bildirimler

    Android, geliştiricilerin cihazın donanım ve yazılım özelliklerini kullanarak kullanıcıları önemli olaylar hakkında bilgilendirmesine olanak tanıyan API'ler içerir [ Kaynaklar, 19 ].

    Bazı API'ler, uygulamaların özellikle ses, titreşim ve ışık gibi donanımları kullanarak bildirim göndermesine veya dikkat çekmesine olanak tanır. Cihaz uygulamalarının, SDK belgelerinde açıklandığı şekilde ve cihaz uygulama donanımıyla mümkün olduğu ölçüde donanım özelliklerini kullanan bildirimleri desteklemesi ZORUNLUDUR. Örneğin, bir cihaz uygulaması bir vibratör içeriyorsa, titreşim API'lerini doğru şekilde uygulaması ZORUNLUDUR. Bir cihaz uygulamasında donanım yoksa, karşılık gelen API'lerin işlemsiz olarak uygulanması ZORUNLUDUR. Bu davranışın Bölüm 7'de daha ayrıntılı olarak açıklandığını unutmayın.

    Ek olarak, uygulamanın API'lerde [ Kaynaklar, 20 ] veya Durum/Sistem Çubuğu simge stili kılavuzunda [ Kaynaklar, 21 ] sağlanan tüm kaynakları (simgeler, ses dosyaları vb.) doğru şekilde oluşturması ZORUNLUDUR. Cihaz uygulayıcıları, bildirimler için referans Android Açık Kaynak uygulaması tarafından sağlanana alternatif bir kullanıcı deneyimi sunabilir MAYIN; ancak bu tür alternatif bildirim sistemlerinin yukarıdaki gibi mevcut bildirim kaynaklarını desteklemesi ZORUNLUDUR.

    Android 4.2, devam eden bildirimler için etkileşimli Görünümler gibi zengin bildirimler için destek içerir. Cihaz uygulamalarının, Android API'lerinde belgelendiği gibi zengin bildirimleri düzgün bir şekilde görüntülemesi ve yürütmesi ZORUNLUDUR.

    Android, geliştiricilerin aramayı uygulamalarına dahil etmelerine ve uygulamalarının verilerini küresel sistem aramasında göstermelerine olanak tanıyan API'ler [ Kaynaklar, 22 ] içerir. Genel olarak konuşursak, bu işlevsellik, kullanıcıların sorgu girmesine olanak tanıyan, kullanıcılar yazarken önerileri görüntüleyen ve sonuçları görüntüleyen, sistem çapında tek bir kullanıcı arayüzünden oluşur. Android API'leri, geliştiricilerin kendi uygulamaları içinde arama sağlamak için bu arayüzü yeniden kullanmalarına ve geliştiricilerin sonuçları ortak küresel arama kullanıcı arayüzüne sağlamalarına olanak tanır.

    Cihaz uygulamalarının, kullanıcı girişine yanıt olarak gerçek zamanlı öneriler sunabilen, tek, paylaşılan, sistem çapında bir arama kullanıcı arayüzü içermesi ZORUNLUDUR. Cihaz uygulamalarının, geliştiricilerin kendi uygulamalarında arama sağlamak için bu kullanıcı arayüzünü yeniden kullanmalarına olanak tanıyan API'leri uygulaması ZORUNLUDUR. Cihaz uygulamalarının, üçüncü taraf uygulamaların genel arama modunda çalıştırıldığında arama kutusuna öneriler eklemesine olanak tanıyan API'leri uygulaması ZORUNLUDUR. Bu işlevi kullanan hiçbir üçüncü taraf uygulaması yüklü değilse, varsayılan davranış, web arama motoru sonuçlarını ve önerilerini görüntülemek OLMALIDIR.

    3.8.4. Tostlar

    Uygulamalar, son kullanıcıya kısa bir süre sonra kaybolan kısa kipli olmayan dizeleri görüntülemek için "Tost" API'sini ([ Kaynaklar, 23 ]'de tanımlanmıştır) kullanabilir. Cihaz uygulamalarının, uygulamalardan gelen Toast'ları son kullanıcılara yüksek görünürlükle görüntülemesi ZORUNLUDUR.

    3.8.5. Temalar

    Android, uygulamaların tüm Etkinliğe veya uygulamaya stil uygulamasına yönelik bir mekanizma olarak "temalar" sağlar. Android 4.2, uygulama geliştiricilerinin Android SDK tarafından tanımlanan Holo teması görünümü ve hissiyle eşleşmek istemeleri durumunda kullanabilecekleri tanımlanmış stiller kümesi olarak bir "Holo" veya "holografik" tema içerir [ Kaynaklar, 24 ]. Cihaz uygulamaları, uygulamalara sunulan Holo teması niteliklerinin hiçbirini DEĞİŞTİRMEMELİDİR [ Kaynaklar, 25 ].

    Android 4.2, uygulama geliştiricilerinin, cihaz uygulayıcısı tarafından tanımlandığı şekliyle cihaz temasının görünüm ve hissini eşleştirmek istemeleri durumunda kullanabilecekleri bir dizi tanımlı stil olarak yeni bir "Cihaz Varsayılanı" teması içerir. Cihaz uygulamaları, uygulamalara sunulan DeviceDefault tema niteliklerini DEĞİŞTİREBİLİR [ Kaynaklar, 25 ].

    3.8.6. Canlı Duvarkağıtları

    Android, uygulamaların bir veya daha fazla "Canlı Duvar Kağıdını" son kullanıcıya sunmasına olanak tanıyan bir bileşen türünü ve ilgili API'yi ve yaşam döngüsünü tanımlar [ Kaynaklar, 26 ]. 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 görüntülerdir.

    Donanım, tüm canlı duvar kağıtlarını, işlevsellik konusunda herhangi bir sınırlama olmaksızın, diğer uygulamaları olumsuz etkilemeden makul bir kare hızında çalıştırabiliyorsa, canlı duvar kağıtlarını güvenilir bir şekilde çalıştırabildiği kabul edilir. Donanımdaki sınırlamalar duvar kağıtlarının ve/veya uygulamaların çökmesine, arızalanmasına, aşırı CPU veya pil gücü tüketmesine veya kabul edilemeyecek kadar düşük kare hızlarında çalışmasına neden oluyorsa, donanımın canlı duvar kağıdını çalıştıramayacağı kabul edilir. Örnek olarak, bazı canlı duvar kağıtları, içeriklerini oluşturmak için Open GL 1.0 veya 2.0 bağlamını kullanabilir. Canlı duvar kağıdı, birden fazla OpenGL bağlamını desteklemeyen donanımlarda güvenilir bir şekilde çalışmaz çünkü bir OpenGL bağlamının canlı duvar kağıdı kullanımı, aynı zamanda bir OpenGL bağlamı kullanan diğer uygulamalarla çakışabilir.

    Yukarıda açıklandığı gibi canlı duvar kağıtlarını güvenilir bir şekilde çalıştırabilen cihaz uygulamalarının canlı duvar kağıtlarını uygulaması GEREKLİdir. Yukarıda açıklandığı gibi canlı duvar kağıtlarını güvenilir bir şekilde çalıştırmadığı belirlenen cihaz uygulamaları, canlı duvar kağıtları UYGULAMAMALIDIR.

    3.8.7. Son Uygulama Ekranı

    Yukarı akışlı Android 4.2 kaynak kodu, kullanıcının uygulamadan son ayrıldığı andaki uygulamanın grafiksel durumunun küçük resmini kullanarak en son uygulamaları görüntülemek için bir kullanıcı arayüzü içerir. Cihaz uygulamaları bu kullanıcı arayüzünü değiştirebilir veya ortadan kaldırabilir; ancak Android'in gelecekteki bir sürümünün bu işlevi daha kapsamlı kullanması planlanıyor. Cihaz uygulamalarının, yeni uygulamalar için yukarı akışlı Android 4.2 kullanıcı arayüzünü (veya benzer bir küçük resim tabanlı arayüzü) kullanması şiddetle tavsiye edilir; aksi takdirde, Android'in gelecekteki bir sürümüyle uyumlu olmayabilirler.

    3.8.8. Giriş Yönetimi Ayarları

    Android 4.2, Giriş Yönetimi Motorları desteğini içerir. Android 4.2 API'leri, özel uygulama IME'lerinin kullanıcı tarafından ayarlanabilir ayarları belirlemesine olanak tanır. Cihaz uygulamalarının, bu tür kullanıcı ayarlarını sağlayan bir IME görüntülendiğinde kullanıcının IME ayarlarına her zaman erişebilmesi için bir yol içermesi ZORUNLUDUR.

    3.8.9. Kilit ve Ana Ekran Widget'ları

    Android 4.2, kullanıcıların ana ekrana veya kilit ekranına yerleştirebileceği uygulama widget'ları desteğini içerir (Ayrıntılar için Android SDK belgelerindeki [ Kaynaklar, 69 ] Uygulama Widget Tasarım Yönergeleri'ne bakın). Uygulama widget'ları, yeni bir etkinlik başlatmadan uygulama verilerine ve hizmetlerine hızlı erişim sağlar. Widget'lar, sisteme widget'in nereye yerleştirilebileceğini söyleyen android:widgetCategory bildirim etiketini bildirerek ana ekranda veya kilit ekranında kullanım desteğini bildirir. Özellikle, cihaz uygulamalarının aşağıdaki gereksinimleri karşılaması ZORUNLUDUR.

    • Cihaz uygulamalarının ana ekrandaki uygulama widget'larını desteklemesi ZORUNLUDUR.
    • Cihaz uygulamalarının kilit ekranını desteklemesi GEREKİR. Cihaz uygulamaları kilit ekranı desteğini içeriyorsa, cihaz uygulamalarının kilit ekranındaki uygulama widget'larını desteklemesi ZORUNLUDUR.

    3.8.10. Kilit Ekranı Medya Uzaktan Kumandası

    Android 4.2, medya uygulamalarının cihazın kilit ekranı gibi uzaktan görünümde görüntülenen oynatma kontrolleriyle entegre olmasını sağlayan Uzaktan Kontrol API'si desteğini içerir[ Kaynaklar, 74 ]. Cihaz uygulamaları, uzaktan kumandaların cihazın kilit ekranına yerleştirilmesine yönelik desteği içermelidir ZORUNLU.

    3.8.11. Rüyalar

    Android 4.2, Dreams [ Kaynaklar, 76 ] adı verilen etkileşimli ekran koruyucular için destek içerir. Dreams, şarj cihazı boştayken veya masaüstü dock'a takılıyken kullanıcıların uygulamalarla etkileşimde bulunmasına olanak tanır. Cihaz uygulamalarının Dreams desteğini içermesi ve kullanıcıların Dreams'i yapılandırması için bir ayar seçeneği sunması ZORUNLUDUR.

    3.9 Cihaz Yönetimi

    Android 4.2, güvenlik bilincine sahip uygulamaların, Android Cihaz Yönetimi API'si aracılığıyla şifre politikalarını uygulama veya uzaktan silme gerçekleştirme gibi cihaz yönetimi işlevlerini sistem düzeyinde gerçekleştirmesine olanak tanıyan özellikler içerir [ Kaynaklar, 27 ]. Cihaz uygulamalarının DevicePolicyManager sınıfının [ Kaynaklar, 28 ] bir uygulamasını sağlaması ZORUNLU ve Android SDK belgelerinde [ Kaynaklar, 27 ] tanımlanan cihaz yönetimi politikalarının tamamını desteklemesi GEREKİR.

    Not: Yukarıda özetlenen gereksinimlerden bazıları Android 4.2 için "ZORUNLU" olarak belirtilse de, kilit ekranını destekleyen cihaz uygulamalarının, Android SDK belgelerinde [ Kaynaklar, 27 ] tanımlandığı gibi kilit ekranındaki widget'ları yönetmek için cihaz politikalarını desteklemesi ZORUNLUDUR.

    Not: Yukarıda özetlenen gereksinimlerden bazıları Android 4.2 için "ZORUNLU" olarak belirtilirken, gelecekteki bir sürüm için Uyumluluk Tanımının bunların "ZORUNLU" olarak değiştirilmesi planlanmaktadır. Yani, bu gereksinimler Android 4.2'de isteğe bağlıdır ancak gelecekteki bir sürümde zorunlu olacaktır . Android 4.2'yi çalıştıran mevcut ve yeni cihazların , Android 4.2'deki bu gereksinimleri karşılaması şiddetle tavsiye edilir , aksi takdirde gelecek sürüme yükseltildiğinde Android uyumluluğu elde edemeyeceklerdir.

    3.10 Erişilebilirlik

    Android 4.2, engelli kullanıcıların cihazlarında daha kolay gezinmesine yardımcı olan bir erişilebilirlik katmanı sağlıyor. Ek olarak Android 4.2, erişilebilirlik hizmeti uygulamalarının kullanıcı ve sistem olayları için geri aramalar almasına ve metinden konuşmaya, dokunsal geri bildirim ve iztopu/d-pad navigasyonu gibi alternatif geri bildirim mekanizmaları oluşturmasına olanak tanıyan platform API'leri sağlar [ Kaynaklar, 29 ] . Cihaz uygulamalarının, varsayılan Android uygulamasıyla tutarlı bir Android erişilebilirlik çerçevesi uygulaması sağlaması ZORUNLUDUR. Özellikle, cihaz uygulamalarının aşağıdaki gereksinimleri karşılaması ZORUNLUDUR.

    • Cihaz uygulamalarının, android.accessibilityservice API'leri [ Kaynaklar, 30 ] aracılığıyla üçüncü taraf erişilebilirlik hizmeti uygulamalarını desteklemesi ZORUNLUDUR.
    • Cihaz uygulamalarının AccessibilityEvents oluşturması ve bu olayları, varsayılan Android uygulamasıyla tutarlı bir şekilde tüm kayıtlı AccessibilityService uygulamalarına iletmesi ZORUNLUDUR.
    • Cihaz uygulamalarının erişilebilirlik hizmetlerini etkinleştirmek ve devre dışı bırakmak için kullanıcı tarafından erişilebilen bir mekanizma sağlaması ZORUNLU ve android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS amacına yanıt olarak bu arayüzü görüntülemesi ZORUNLU.

    Ek olarak, cihaz uygulamalarının, cihazda bir erişilebilirlik hizmetinin uygulanmasını sağlaması GEREKLİ ve kullanıcıların, cihaz kurulumu sırasında erişilebilirlik hizmetini etkinleştirmeleri için bir mekanizma sağlaması GEREKLİdir. Erişilebilirlik hizmetinin açık kaynak uygulaması Eyes Free projesinde mevcuttur [ Kaynaklar, 31 ].

    3.11 Metinden Konuşmaya

    Android 4.2, uygulamaların metinden konuşmaya (TTS) hizmetlerinden yararlanmasına olanak tanıyan API'ler içerir ve hizmet sağlayıcıların TTS hizmetlerinin uygulamalarını sağlamasına olanak tanır [ Kaynaklar, 32 ]. Cihaz uygulamalarının Android TTS çerçevesiyle ilgili şu gereksinimleri karşılaması ZORUNLUDUR:

    • Cihaz uygulamalarının Android TTS çerçeve API'lerini desteklemesi ZORUNLU ve cihazda mevcut dilleri destekleyen bir TTS motoru içermesi GEREKİR. Yukarı akışlı Android açık kaynak yazılımının tam özellikli bir TTS motoru uygulaması içerdiğini unutmayın.
    • Cihaz uygulamalarının üçüncü taraf TTS motorlarının kurulumunu desteklemesi ZORUNLUDUR.
    • Cihaz uygulamalarının, kullanıcıların sistem düzeyinde kullanılmak üzere bir TTS motoru seçmesine olanak tanıyan, kullanıcı tarafından erişilebilen bir arayüz sağlaması ZORUNLUDUR.

    4. Uygulama Paketleme Uyumluluğu

    Cihaz uygulamalarının, resmi Android SDK'da yer alan "aapt" aracı tarafından oluşturulan Android ".apk" dosyalarını yüklemesi ve çalıştırması ZORUNLUDUR [ Kaynaklar, 33 ].

    Cihaz uygulamaları, .apk [ Kaynaklar, 34 ], Android Manifest [ Kaynaklar, 35 ], Dalvik bayt kodu [ Kaynaklar, 17 ] veya renderscript bayt kodu formatlarını, bu dosyaların düzgün şekilde yüklenmesini ve çalışmasını engelleyecek şekilde GENİŞLETMEMELİDİR diğer uyumlu cihazlar. Cihaz uygulayıcıları Dalvik'in referans yukarı akış uygulamasını ve referans uygulamasının paket yönetim sistemini KULLANMALIDIR.

    5. Multimedya Uyumluluğu

    Cihaz uygulamalarının hoparlörler, kulaklık jakı, harici hoparlör bağlantısı vb. gibi en az bir ses çıkışı biçimi içermesi ZORUNLUDUR.

    5.1. Medya Codec'leri

    Cihaz uygulamalarının, bu belgede açıkça izin verildiği durumlar dışında, Android SDK belgelerinde [ Kaynaklar, 58 ] belirtilen temel medya formatlarını desteklemesi ZORUNLUDUR. Özellikle, cihaz uygulamalarının aşağıdaki tablolarda tanımlanan medya formatlarını, kodlayıcıları, kod çözücüleri, dosya türlerini ve kapsayıcı formatlarını desteklemesi ZORUNLUDUR. Bu codec'lerin tümü, Android Açık Kaynak Projesinden tercih edilen Android uygulamasında yazılım uygulamaları olarak sağlanmaktadır.

    Ne Google'ın ne de Open Handset Alliance'ın bu codec bileşenlerinin üçüncü taraf patentleri tarafından engellenmediğine dair herhangi bir beyanda bulunmadığını lütfen unutmayın. Bu kaynak kodunu donanım veya yazılım ürünlerinde kullanmak isteyenlere, açık kaynak yazılım veya paylaşılan yazılım da dahil olmak üzere bu kodun uygulanmasının, ilgili patent sahiplerinden patent lisansları gerektirebileceği tavsiye edilir.

    Mevcut cihaz donanımının, ilgili standartlar tarafından belirtilen gerekli bit hızlarıyla tam olarak eşleşen bit hızlarını desteklememesi nedeniyle, bu tabloların çoğu video codec bileşeni için belirli bit hızı gereksinimlerini listelemediğini unutmayın. Bunun yerine, cihaz uygulamalarının donanımda pratik olan en yüksek bit hızını spesifikasyonlarda tanımlanan sınırlara kadar desteklemesi GEREKLİdir.

    Tip Format / Codec Kodlayıcı Kod çözücü Detaylar Dosya Türleri / Kapsayıcı Formatları
    Ses MPEG-4 AAC Profili (AAC LC) GEREKLİ
    Mikrofon donanımını içeren ve android.hardware.microphone tanımını içeren cihaz uygulamaları için gereklidir.
    GEREKLİ 8 ila 48 kHz arası standart örnekleme hızlarıyla mono/stereo/5.0/5.1* içerik desteği.
    • 3GPP (.3gp)
    • MPEG-4 (.mp4, .m4a)
    • ADTS ham AAC (.aac, Android 3.1+ sürümünde kod çözme, Android 4.0+ sürümünde kodlama, ADIF desteklenmez)
    • MPEG-TS (.ts, aranamaz, Android 3.0+)
    MPEG-4 HE AAC Profili (AAC+) Mikrofon donanımını içeren ve android.hardware.microphone tanımını içeren cihaz uygulamaları için GEREKLİDİR GEREKLİ 16 - 48 kHz arası standart örnekleme hızlarıyla mono/stereo/5.0/5.1* içerik desteği.
    MPEG-4 HE AAC v2 Profili (geliştirilmiş AAC+) GEREKLİ 16 - 48 kHz arası standart örnekleme hızlarıyla mono/stereo/5.0/5.1* içerik desteği.
    MPEG-4 Ses Nesnesi Türü ER AAC ELD (Geliştirilmiş Düşük Gecikmeli AAC) Mikrofon donanımını içeren ve android.hardware.microphone tanımını içeren cihaz uygulamaları için GEREKLİDİR GEREKLİ 16'dan 48 kHz'e kadar standart örnekleme oranlarıyla mono/stereo içerik desteği.
    AMR-NB GEREKLİ
    Mikrofon donanımını içeren ve android.hardware.microphone tanımını içeren cihaz uygulamaları için gereklidir.
    GEREKLİ 4,75 ila 12,2 kbps örneklenmiş @ 8kHz 3GPP (.3gp)
    AMR-WB GEREKLİ
    Mikrofon donanımını içeren ve android.hardware.microphone tanımını içeren cihaz uygulamaları için gereklidir.
    GEREKLİ 16kHz'de örneklenmiş 6,60 kbit/s'den 23,85 kbit/s'ye kadar 9 hız 3GPP (.3gp)
    FLAC GEREKLİ
    (Android 3.1+)
    Mono/Stereo (çok kanallı değil). Örnekleme hızları 48 kHz'e kadardır (ancak 48 ila 44,1 kHz alt örnekleyici bir alçak geçiş filtresi içermediğinden 44,1 kHz çıkışlı cihazlarda 44,1 kHz'e kadar önerilir). 16 bit önerilir; 24 bit için renk taklidi uygulanmadı. Yalnızca FLAC (.flac)
    MP3 GEREKLİ Mono/Stereo 8-320Kbps sabit (CBR) veya değişken bit hızı (VBR) MP3 (.mp3)
    MİDİ GEREKLİ MIDI Tip 0 ve 1. DLS Sürüm 1 ve 2. XMF ve Mobil XMF. RTTTL/RTX, OTA ve iMelody zil sesi formatları desteği
    • 0 ve 1 yazın (.mid, .xmf, .mxmf)
    • RTTTL/RTX (.rtttl, .rtx)
    • OTA (.ota)
    • iMelody (.imy)
    Vorbis GEREKLİ
    • Ogg (.ogg)
    • Matroska (.mkv)
    PCM/DALGA GEREKLİ GEREKLİ 8 bit ve 16 bit doğrusal PCM** (donanım sınırına kadar hızlar). Cihazlar 8000,16000 ve 44100 Hz frekanslarında ham PCM kaydı için örnekleme hızlarını desteklemelidir ZORUNLU DALGA (.wav)
    Resim JPEG GEREKLİ GEREKLİ Temel+aşamalı JPEG (.jpg)
    GIF GEREKLİ GIF (.gif)
    PNG GEREKLİ GEREKLİ PNG (.png)
    BMP GEREKLİ BMP (.bmp)
    WEBP GEREKLİ GEREKLİ WebP (.webp)
    Video H.263 GEREKLİ
    Kamera donanımını içeren ve android.hardware.camera veya android.hardware.camera.front tanımını içeren cihaz uygulamaları için gereklidir.
    GEREKLİ
    • 3GPP (.3gp)
    • MPEG-4 (.mp4)
    H.264 AVC GEREKLİ
    Kamera donanımını içeren ve android.hardware.camera veya android.hardware.camera.front tanımını içeren cihaz uygulamaları için gereklidir.
    GEREKLİ Temel Profil (BP)
    • 3GPP (.3gp)
    • MPEG-4 (.mp4)
    • MPEG-TS (.ts, yalnızca AAC ses, aranamaz, Android 3.0+)
    MPEG-4SP GEREKLİ 3GPP (.3gp)
    VP8 GEREKLİ
    (Android 2.3.3+)
    WebM (.webm) ve Matroska (.mkv, Android 4.0+)
    *Not: Yalnızca 5.0/5.1 içeriğinin indirgeme karışımı gereklidir; 2'den fazla kanalın kaydedilmesi veya oluşturulması isteğe bağlıdır. **Not: 16 bit doğrusal PCM yakalama zorunludur. 8 bit doğrusal PCM yakalama zorunlu değildir.

    5.2 Video Kodlama

    Arkaya bakan bir kamera içeren ve android.hardware.camera bildiren Android cihaz uygulamalarının aşağıdaki video kodlama profillerini desteklemesi GEREKLİdir.

    SD (Düşük kalite) SD (Yüksek kalite) HD (Donanım tarafından desteklendiğinde)
    Video codec'i H.264 Temel Profil H.264 Temel Profil H.264 Temel Profil
    Video çözünürlüğü 176x144 piksel 480x360 piksel 1280x720 piksel
    Video kare hızı 12 fps 30 fps 30 fps
    Video bit hızı 56 Kbps 500 Kbps veya daha yüksek 2 Mbps veya daha yüksek
    Ses codec'i AAC-LC AAC-LC AAC-LC
    Ses kanalları 1 (tek renkli) 2 (stereo) 2 (stereo)
    Ses bit hızı 24 Kbps 128 Kbps 192 Kbps

    5.3 Video Kod Çözme

    Android cihaz uygulamalarının aşağıdaki VP8 video kod çözme profillerini desteklemesi GEREKLİdir.

    SD (Düşük kalite) SD (Yüksek kalite) HD 720p
    (Donanım tarafından desteklendiğinde)
    HD 1080p
    (Donanım tarafından desteklendiğinde)
    Video çözünürlüğü 320x180 piksel 640x360 piksel 1280x720 piksel 1920x1080 piksel
    Video kare hızı 30 fps 30 fps 30 fps 30 fps
    Video bit hızı 800 Kbps 2 Mb/sn 8 Mb/sn 20 Mb/sn

    5.4. Ses kaydı

    Bir uygulama, bir ses akışını kaydetmeye başlamak için android.media.AudioRecord API'sini kullandığında, mikrofon donanımını içeren ve android.hardware.microphone bildiren cihaz uygulamalarının, aşağıdaki davranışların her biriyle sesi örneklemesi ve kaydetmesi GEREKİR:

    • Cihaz yaklaşık olarak düz genlik-frekans özellikleri sergilemelidir; özellikle ±3 dB, 100 Hz'den 4000 Hz'e kadar
    • Ses giriş hassasiyeti, 1000 Hz'de 90 dB ses gücü seviyesi (SPL) kaynağının 16 bit örnekler için 2500 RMS verecek şekilde ayarlanması GEREKLİdir.
    • PCM genlik düzeyleri, mikrofondaki 90 dB SPL için -18 dB'den +12 dB'ye kadar en az 30 dB'lik bir aralıkta giriş SPL değişikliklerini doğrusal olarak İZLEMELİDİR.
    • Toplam harmonik bozulma, 90 dB SPL giriş seviyesinde 1KHz için %1'den az OLMALIDIR.

    Yukarıdaki kayıt özelliklerine ek olarak, bir uygulama android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ses kaynağını kullanarak bir ses akışını kaydetmeye başladığında:

    • Varsa gürültü azaltma işlemi devre dışı bırakılmalıdır.
    • Varsa, otomatik kazanç kontrolü devre dışı bırakılmalıdır.

    Not: Yukarıda özetlenen gereksinimlerden bazıları Android 4.2 için "ZORUNLU" olarak belirtilirken, gelecekteki bir sürüm için Uyumluluk Tanımının bunların "ZORUNLU" olarak değiştirilmesi planlanmaktadır. Yani, bu gereksinimler Android 4.2'de isteğe bağlıdır ancak gelecekteki bir sürümde zorunlu olacaktır . Android 4.2'yi çalıştıran mevcut ve yeni cihazların , Android 4.2'deki bu gereksinimleri karşılaması şiddetle tavsiye edilir , aksi takdirde gelecek sürüme yükseltildiğinde Android uyumluluğu elde edemeyeceklerdir.

    5.5. Ses Gecikmesi

    Ses gecikmesi, bir ses sinyalinin sistemden geçmesi sırasında geçen zaman gecikmesidir. Birçok uygulama sınıfı, ses efektleri veya VOIP iletişimi gibi gerçek zamanlı efektleri elde etmek için kısa gecikmelere dayanır.

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

    • "çıkış gecikmesi", bir uygulamanın PCM kodlu veri çerçevesini yazması ile karşılık gelen sesin harici bir dinleyici tarafından duyulabilmesi veya bir dönüştürücü tarafından gözlemlenebilmesi arasındaki süre olarak tanımlanır.
    • "soğuk çıkış gecikmesi", ses çıkış sistemi istekten önce boştayken ve kapatıldığında ilk kare için çıkış gecikmesi olarak tanımlanır
    • "sürekli çıkış gecikmesi", cihaz zaten ses oynattıktan sonra sonraki kareler için çıkış gecikmesi olarak tanımlanır
    • "giriş gecikmesi", cihaza harici bir ses sunulması ile bir uygulamanın PCM kodlu verilerin karşılık gelen çerçevesini okuması arasındaki süredir.
    • "soğuk giriş gecikmesi", ses giriş sistemi istekten önce boştayken ve kapatıldığında, kayıp giriş süresi ile ilk kare için giriş gecikmesinin toplamı olarak tanımlanır
    • "sürekli giriş gecikmesi", cihaz zaten ses yakalarken sonraki kareler için giriş gecikmesi olarak tanımlanır
    • "OpenSL ES PCM arabellek kuyruğu API'si", Android NDK içindeki PCM ile ilgili OpenSL ES API'leri kümesidir; bkz. NDK_root /docs/opensles/index.html

    Bölüm 5'e göre, tüm uyumlu cihaz uygulamalarının en az bir ses çıkışı biçimi içermesi ZORUNLUDUR. Cihaz uygulamalarının şu çıkış gecikmesi gereksinimlerini karşılaması veya aşması GEREKLİdir:

    • 100 milisaniye veya daha az soğuk çıktı gecikmesi
    • 45 milisaniye veya daha az sürekli çıkış gecikmesi

    Bir cihaz uygulaması, OpenSL ES PCM arabellek kuyruğu API'sini kullanırken herhangi bir ilk kalibrasyondan sonra bu bölümün gereksinimlerini karşılıyorsa, desteklenen en az bir ses çıkış cihazı üzerinden sürekli çıkış gecikmesi ve soğuk çıkış gecikmesi için düşük gecikmeli ses desteğini rapor edebilir. , "android.hardware.audio.low-latency" özelliğini android.content.pm.PackageManager sınıfı aracılığıyla bildirerek. [ Kaynaklar, 37 ] Bunun tersine, eğer cihaz uygulaması bu gereksinimleri karşılamıyorsa, düşük gecikmeli ses desteğini BİLDİRMEMELİDİR.

    Bölüm 7.2.5'e göre, mikrofon donanımı cihaz uygulamalarından çıkarılabilir.

    Mikrofon donanımını içeren ve android.hardware.microphone bildiren cihaz uygulamalarının şu giriş ses gecikmesi gereksinimlerini karşılaması GEREKLİdir:

    • 100 milisaniye veya daha az soğuk giriş gecikmesi
    • 50 milisaniye veya daha az sürekli giriş gecikmesi

    5.6. Ağ Protokolleri

    Cihazlar, Android SDK belgelerinde [ Kaynaklar, 58 ] belirtildiği gibi ses ve video oynatmaya yönelik medya ağı protokollerini desteklemelidir ZORUNLU. Özellikle, cihazların aşağıdaki medya ağı protokollerini desteklemesi ZORUNLUdur:

    • RTSP (RTP, SDP)
    • HTTP(S) aşamalı akış
    • HTTP(S) Canlı Akış taslak protokolü, Sürüm 3 [ Kaynaklar, 59 ]

    6. Geliştirici Araçları ve Seçeneklerinin Uyumluluğu

    6.1 Geliştirici Araçları

    Cihaz uygulamalarının Android SDK'da sağlanan Android Geliştirici Araçlarını desteklemesi ZORUNLUDUR. Özellikle, Android uyumlu cihazların aşağıdakilerle uyumlu olması ZORUNLUDUR:

    • Android Hata Ayıklama Köprüsü (adb olarak bilinir) [ Kaynaklar, 33 ]
      Cihaz uygulamalarının, Android SDK'da belgelendiği gibi tüm adb işlevlerini desteklemesi ZORUNLUDUR. Cihaz tarafındaki adb arka plan programının varsayılan olarak etkin olmaması GEREKİR ve Android Hata Ayıklama Köprüsü'nü açmak için kullanıcı tarafından erişilebilen bir mekanizmanın bulunması GEREKİR.
    • Android 4.2.2, güvenli adb desteğini içerir. Güvenli adb, bilinen kimliği doğrulanmış ana bilgisayarlarda adb'yi etkinleştirir. Android 4.2.2'yi çalıştıran mevcut ve yeni cihazların , Android 4.2'deki bu gereksinimi karşılamaları şiddetle tavsiye edilir , aksi takdirde gelecek sürüme yükseltildiğinde Android uyumluluğu elde edemeyeceklerdir.

    • Dalvik Hata Ayıklama İzleme Hizmeti (ddms olarak bilinir) [ Kaynaklar, 33 ]
      Cihaz uygulamalarının, Android SDK'da belgelendiği gibi tüm ddms özelliklerini desteklemesi ZORUNLUDUR. ddms adb kullandığından, ddms desteği varsayılan olarak devre dışı OLMALIDIR, ancak yukarıdaki gibi kullanıcı Android Hata Ayıklama Köprüsü'nü etkinleştirdiğinde desteklenmelidir ZORUNLU.
    • Maymun [ Kaynaklar, 36 ]
      Cihaz uygulamalarının Monkey çerçevesini içermesi ve uygulamaların kullanımına sunması ZORUNLUDUR.
    • SysTrace [ Kaynaklar, 33 ]
      Cihaz uygulamalarının, Android SDK'da belgelendiği gibi systrace aracını desteklemesi ZORUNLUDUR. Systrace varsayılan olarak etkin olmamalıdır ve Systrace'i açmak için kullanıcının erişebileceği bir mekanizmanın bulunması GEREKİR.

    Çoğu Linux tabanlı sistem ve Apple Macintosh sistemi, ek destek olmadan standart Android SDK araçlarını kullanan Android aygıtlarını tanır; ancak Microsoft Windows sistemleri genellikle yeni Android aygıtları için bir sürücü gerektirir. (Örneğin, yeni satıcı kimlikleri ve bazen yeni cihaz kimlikleri, Windows sistemleri için özel USB sürücüleri gerektirir.) Bir cihaz uygulaması, standart Android SDK'da sağlandığı gibi adb aracı tarafından tanınmıyorsa, cihaz uygulayıcılarının geliştiricilerin bağlanmasını sağlayan Windows sürücülerini sağlaması GEREKİR. adb protokolünü kullanan cihaz. Bu sürücüler, hem 32 bit hem de 64 bit sürümlerde Windows XP, Windows Vista, Windows 7 ve Windows 8 için sağlanmalıdır.

    6.2 Geliştirici Seçenekleri

    Android 4.2, geliştiricilerin uygulama geliştirme ile ilgili ayarları yapılandırmaları için destek içerir. Cihaz uygulamaları android.settings.application_deelopment_settings uygulama geliştirme ile ilgili ayarları göstermek amacıyla onurlandırmalıdır [ Resources, 77 ]. Yukarı Akım Android uygulaması, Varsayılan olarak Geliştirici Seçenekleri menüsünü gizler ve kullanıcıların Ayarlar> Aygıt> Hakkında Yedi (7) kez tuşlarına bastıktan sonra geliştirici seçeneklerini başlatmasını sağlar. Cihaz uygulamaları geliştirici seçenekleri için tutarlı bir deneyim sağlamalıdır. Özellikle, cihaz uygulamaları varsayılan olarak geliştirici seçeneklerini gizlemeli ve yukarı akış Android uygulamasıyla tutarlı geliştirici seçeneklerini mümkün kılmak için bir mekanizma sağlamalıdır.

    7. Donanım Uyumluluğu

    Bir cihaz, üçüncü taraf geliştiriciler için karşılık gelen bir API'ya sahip belirli bir donanım bileşeni içeriyorsa, cihaz uygulaması bu API'yi Android SDK belgelerinde açıklandığı gibi uygulamalıdır. SDK'daki bir API, isteğe bağlı olduğu belirtilen bir donanım bileşeniyle etkileşime giriyorsa ve cihaz uygulaması bu bileşene sahip değilse:

    • Bileşenin API'leri için tam sınıf tanımları (SDK tarafından belgelendiği gibi) hala mevcut olmalıdır
    • API'nin davranışları makul bir şekilde işlem yapılmadan uygulanmalıdır ZORUNLU
    • API yöntemleri, SDK belgelerinin izin verdiği yerlerde boş değerler döndürmelidir ZORUNLU
    • API yöntemleri, SDK belgelerinde boş değerlere izin verilmeyen sınıfların işlem dışı uygulamalarını döndürmelidir ZORUNLU
    • API yöntemleri, SDK belgeleri ile belgelenmeyen istisnalar atmamalıdır

    Bu gereksinimlerin geçerli olduğu tipik bir senaryo örneği, telefon API'sidir: telefon olmayan cihazlarda bile, bu API'lerin makul işlem gerektirmeyen işlemler olarak uygulanması gerekir.

    Cihaz uygulamalarının, 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 bir şekilde raporlaması ZORUNLUDUR. [ Kaynaklar, 37 ]

    7.1. Ekran ve Grafik

    Android 4.2, üçüncü taraf uygulamaların çeşitli donanım yapılandırmalarında iyi çalışmasını sağlamak için cihaz için uygun şekilde uygulama varlıklarını ve kullanıcı arayüzü düzenlerini otomatik olarak ayarlayan tesisleri içerir [ Resources, 38 ]. Cihazlar, bu bölümde ayrıntılı olarak açıklandığı gibi bu API'leri ve davranışları düzgün bir şekilde uygulamalıdır.

    Bu bölümdeki gereksinimler tarafından atıfta bulunulan birimler aşağıdaki gibi tanımlanmıştır:

    • "Fiziksel Diagonal Boyut", ekranın aydınlatılmış kısmının iki karşıt köşesi arasındaki inç mesafesidir.
    • "DPI" ("inç başına noktalar" anlamına gelir), DPI değerlerinin listelendiği lineer yatay veya dikey 1 "ile kapsilen piksel sayısıdır.
    • "En boy oranı", ekranın daha uzun boyutun daha uzun boyutunun oranıdır. Örneğin, 480x854 piksel ekran 854 /480 = 1.779 veya kabaca "16: 9" olacaktır.
    • "Yoğunluktan bağımsız piksel" veya ("DP"), pixels = dps * (density / 160) olarak hesaplanan 160 dpi ekranına normalleştirilmiş sanal piksel birimidir.

    7.1.1. Ekran Yapılandırması

    Ekran boyutu

    Android UI çerçevesi, çeşitli farklı ekran boyutlarını destekler ve uygulamaların android.content.res.Configuration.screenLayout aracılığıyla cihaz ekran boyutunu (aka " SCREENLAYOUT_SIZE_MASK düzeni") sorgulamasına izin verir. Cihaz uygulamaları, Android SDK belgesinde tanımlandığı gibi doğru ekran boyutunu bildirmeli ve yukarı akış Android platformu tarafından belirlenmelidir. Özellikle, cihaz uygulamaları aşağıdaki mantıksal yoğunluktan bağımsız piksel (DP) ekran boyutlarına göre doğru ekran boyutunu bildirmelidir.

    • Cihazların ekran boyutları en az 426 dp x 320 dp ('küçük') olmalıdır
    • Ekran boyutunu 'normal' bildiren cihazların en az 480 dp x 320 dp ekran boyutlarına sahip olması gerekir
    • Ekran boyutunu 'büyük' ​​bildiren cihazların en az 640 dp x 480 dp ekran boyutlarına sahip olması gerekir
    • Ekran boyutu 'xlarge' bildiren cihazların en az 960 dp x 720 dp ekran boyutlarına sahip olması gerekir

    Buna ek olarak, cihazların fiziksel diyagonal boyutta en az 2,5 inç ekran boyutlarına sahip olmalıdır.

    Cihazlar bildirilen ekran boyutlarını hiçbir zaman değiştirmemelidir.

    Uygulamalar isteğe bağlı olarak androidManifest.xml dosyasındaki <supports-screens> Ekran> Öznitelik ile hangi ekran boyutlarını desteklediklerini gösterir. Cihaz uygulamaları, Android SDK belgelerinde açıklandığı gibi, uygulamaların küçük, normal, büyük ve xlarge ekranlarına yönelik desteğini doğru bir şekilde onurlandırmalıdır.

    Ekran En Boy Oranı

    En boy oranı 1.3333 (4: 3) ile 1.85 (16: 9) arasında olmalıdır.

    Ekran Yoğunluğu

    Android UI çerçevesi, uygulama geliştiricilerinin uygulama kaynaklarını hedeflemesine yardımcı olmak için bir dizi standart mantıksal yoğunluk tanımlar. Cihaz uygulamaları, android.util.DisplayMetrics API'leri aracılığıyla aşağıdaki mantıklı Android çerçeve yoğunluklarından birini bildirmeli ve bu standart yoğunlukta uygulamaları yürütmelidir.

    • 120 DPI, 'LDPI' olarak bilinir
    • 160 DPI, 'MDPI' olarak bilinir
    • 213 DPI, 'TVDPI' olarak bilinir
    • 'HDPI' olarak bilinen 240 DPI
    • 320 dpi, 'xhdpi' olarak bilinir
    • 480 dpi, 'xxhdpi' olarak bilinir
    Cihaz uygulamaları, bu mantıksal yoğunluk, rapor edilen ekran boyutunu desteklenen minimumun altına itmedikçe, ekranın fiziksel yoğunluğuna sayısal olarak en yakın standart Android çerçeve yoğunluğunu tanımlamalıdır. Fiziksel yoğunluğa sayısal olarak en yakın olan standart Android çerçeve yoğunluğu, desteklenen en küçük uyumlu ekran boyutundan (320 dp genişliği) daha küçük bir ekran boyutuyla sonuçlanırsa, cihaz uygulamaları bir sonraki en düşük standart Android çerçeve yoğunluğunu bildirmelidir.

    7.1.2. Görüntüleme Metrikleri

    Cihaz uygulamaları, android.util.DisplayMetrics [ Resources, 39 ] 'da tanımlanan tüm ekran metrikleri için doğru değerleri rapor etmelidir.

    7.1.3. Ekran Yönü

    Cihazlar, uygulamalarla portre veya peyzaj ekran oryantasyonuna göre dinamik oryantasyonu desteklemelidir. Yani cihazın, uygulamanın belirli bir ekran yönü talebine uyması gerekir. Cihaz uygulamaları varsayılan olarak dikey veya yatay yönlendirmeyi SEÇEBİLİR.

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

    Aygıtlar, oryantasyonu değiştirirken bildirilen ekran boyutunu veya yoğunluğunu değiştirmemelidir.

    Cihazlar hangi ekran yönlerini desteklediklerini ( android.hardware.screen.portrait ve/veya android.hardware.screen.landscape ) bildirmeli ve en az bir desteklenen yönelim bildirmelidir. Örneğin, televizyon veya dizüstü bilgisayar gibi sabit odaklı peyzaj ekranına sahip bir cihazın yalnızca android.hardware.screen.landscape rapor etmelidir.

    7.1.4. 2D ve 3D Grafik Hızlandırma

    Cihaz uygulamaları, Android SDK belgelerinde somutlaşmış ve ayrıntılı olarak hem OpenGL ES 1.0 hem de 2.0'ı desteklemelidir. Cihaz uygulamaları, Android SDK belgelerinde ayrıntılı olarak açıklandığı gibi Android renderscript'i de desteklemelidir [ Resources, 8 ].

    Cihaz uygulamaları da kendilerini doğru bir şekilde OpenGL ES 1.0 ve 2.0 olarak tanımlamalıdır. Yani:

    • Yönetilen API'ler ( GLES10.getString() Yöntemi gibi) gibi OpenGL ES 1.0 ve 2.0 için desteği rapor etmelidir.
    • Yerel C/C ++ OpenGL API'leri (yani, LIBGLES_V1CM.SO, libgles_v2.so veya libegl.so üzerinden uygulamalar için kullanılabilir olanlar) OpenGL ES 1.0 ve 2.0 için destek bildirmelidir.

    Cihaz uygulamaları istenen OpenGL ES uzantılarını uygulayabilir. Bununla birlikte, cihaz uygulamaları, destekledikleri OpenGL ES yönetilen ve yerel API'ler aracılığıyla rapor vermeli ve tersine desteklemedikleri uzatma dizelerini bildirmemelidir.

    Android 4.2'nin isteğe bağlı olarak belirli OpenGL doku sıkıştırma formatları gerektirdiğini belirtmek için uygulamaların desteğini içerdiğini unutmayın. Bu formatlar tipik olarak satıcıya özgüdür. Herhangi bir özel doku sıkıştırma formatını uygulamak için Android 4.2 tarafından cihaz uygulamaları gerekli değildir. Ancak, OpenGL API'sındaki getString() yöntemi aracılığıyla destekledikleri doku sıkıştırma formatlarını doğru bir şekilde bildirmelidirler.

    Android 4.2, uygulamalar için, bir açık etiket android:hardwareAccelerated veya Direct API çağrıları [ Resources, 9] kullanılarak uygulama, etkinlik, pencere veya görünüm seviyesinde 2D grafikler için donanım hızlanmasını sağlamak istediklerini beyan etmek için bir mekanizma içerir [Resources, 9 ].

    Android 4.2'de, cihaz uygulamaları varsayılan olarak donanım ivmesini sağlamalıdır ve geliştirici android:hardwareAccelerated="false" veya Donanım Hızını Doğrudan Android Görünüm API'leri aracılığıyla devre dışı bırakarak talep ederse donanım ivmesini devre dışı bırakmalıdır.

    Buna ek olarak, cihaz uygulamaları, donanım ivmesi üzerine Android SDK belgeleri ile tutarlı davranışlar sergilemelidir [ Resources, 9 ].

    Android 4.2, geliştiricilerin bir UI hiyerarşisinde hedefler oluşturma hedefleri olarak donanımlara uyumlu OpenGL ES dokularını doğrudan entegre etmelerini sağlayan bir TextureView nesnesi içerir. Cihaz uygulamaları TextureView API'sını desteklemeli ve yukarı akış Android uygulaması ile tutarlı davranışlar sergilemelidir.

    7.1.5. Eski Uygulama Uyumluluk Modu

    Android 4.2, çerçevenin, tarih öncesi ekran boyutu bağımsızlığı olan eski Android sürümleri için geliştirilmemiş eski uygulamaların yararına çerçevenin 'normal' ekran boyutu eşdeğeri (320dp genişlik) modunda çalıştığı bir "uyumluluk modu" belirtir. Cihaz uygulamaları, yukarı akış Android açık kaynak kodu tarafından uygulanan eski uygulama uyumluluk moduna destek içermelidir. Yani, cihaz uygulamalarının uyumluluk modunun etkinleştirildiği tetikleyicileri veya eşikleri DEĞİŞTİRMEMELİ ve uyumluluk modunun davranışını DEĞİŞTİRMEMELİDİR.

    7.1.6. Ekran Türleri

    Cihaz uygulama ekranları iki türden biri olarak sınıflandırılır:

    • Sabit piksel ekran uygulamaları: Ekran, yalnızca tek bir piksel genişliğini ve yüksekliği destekleyen tek bir paneldir. Tipik olarak ekran fiziksel olarak cihazla entegre edilir. Örnekler arasında cep telefonları, tabletler vb.
    • Değişken Piksel Ekran Uygulamaları: Aygıt Uygulaması, gömülü ekran yoktur ve vGA, HDMI veya ekran için kablosuz bağlantı noktası gibi bir video çıkış portu içerir veya piksel boyutlarını değiştirebilen gömülü bir ekrana sahiptir. Örnekler arasında televizyonlar, set üstü kutular vb.

    Sabit piksel cihaz uygulamaları

    Sabit piksel cihaz uygulamaları, bu uyumluluk tanımını tanımlayan gereksinimleri karşılamaları koşuluyla, herhangi bir piksel boyutu ekranlarını kullanabilir.

    Sabit piksel uygulamaları, harici bir ekranla kullanılmak üzere bir video çıktı bağlantı noktası içerebilir. Ancak, bu ekran uygulamaları çalıştırmak için kullanılıyorsa, cihaz aşağıdaki gereksinimleri karşılamalıdır:

    • Cihaz, 7.1.1 ve 7.1.2 bölümlerinde ayrıntılı olarak açıklandığı gibi aynı ekran yapılandırmasını ve ekran metriklerini sabit piksel ekran olarak bildirmelidir.
    • Cihaz, sabit piksel ekranla aynı mantıksal yoğunluğu bildirmelidir.
    • Cihaz, sabit piksel ekranla aynı veya çok yakın ekran boyutlarını bildirmelidir.

    Örneğin, 1024x600 piksel çözünürlüğe sahip 7 "diyagonal boyutta bir tablet, sabit piksel büyük MDPI ekran uygulaması olarak kabul edilir. 720p veya 1080p'de görüntülenen bir video çıkış bağlantı noktası içeriyorsa, cihaz uygulaması çıktıyı ölçeklendirmelidir, böylece Uygulamalar yalnızca büyük bir MDPI penceresinde yürütülür, sabit piksel ekran veya video çıktı bağlantı noktasının kullanımda olup olmadığına bakılmaksızın.

    Değişken piksel cihaz uygulamaları

    Değişken piksel cihaz uygulamaları 1280x720 veya 1920x1080'in birini veya her ikisini desteklemelidir (yani 720p veya 1080p). Değişken piksel ekranlara sahip cihaz uygulamaları başka bir ekran yapılandırmasını veya modunu desteklememelidir. Değişken piksel ekranlarla cihaz uygulamaları, çalışma zamanında veya önyükleme zamanında ekran yapılandırmasını veya modu değiştirebilir. Örneğin, bir set üstü kutu kullanıcısı 720p ekranın 1080p ekranla değiştirilmesi ve cihaz uygulaması buna göre ayarlanabilir.

    Ayrıca, değişken piksel cihaz uygulamaları bu piksel boyutları için aşağıdaki yapılandırma kovalarını bildirmelidir:

    • 1280x720 (720p olarak da bilinir): 'büyük' ​​ekran boyutu, 'TVDPI' (213 dpi) Yoğunluk
    • 1920x1080 (1080p olarak da bilinir): 'büyük' ​​ekran boyutu, 'xhdpi' (320 dpi) Yoğunluk

    Netlik için, değişken piksel boyutlarına sahip cihaz uygulamaları Android 4.2'de 720p veya 1080p ile sınırlıdır ve yukarıda belirtildiği gibi ekran boyutu ve yoğunluk kovalarını rapor edecek şekilde yapılandırılmalıdır.

    7.1.7. Ekran Teknolojisi

    Android platformu, uygulamaların ekrana zengin grafikler oluşturmasına izin veren API'ler içerir. Cihazlar, bu belgede özel olarak izin verilmedikçe, Android SDK tarafından tanımlandığı gibi tüm bu API'leri desteklemelidir. Özellikle:

    • Cihazlar, 16 bit renkli grafikler oluşturabilen ekranları desteklemeli ve 24 bit renkli grafiklere sahip ekranları desteklemelidir.
    • Cihazlar, animasyonlar oluşturabilen ekranları desteklemelidir.
    • Kullanılan ekran teknolojisi, 0.9 ile 1.1 arasında bir piksel en boy oranına (par) sahip olmalıdır. Yani, piksel en boy oranı% 10 toleransla kareye (1.0) yakın olmalıdır.

    7.1.8. Harici Ekranlar

    Android 4.2, medya paylaşım özelliklerini ve harici ekranlara erişmek için geliştirici API'lerini etkinleştirmek için ikincil ekran desteği içerir. Bir cihaz harici bir ekranı kablolu, kablosuz veya gömülü bir ek ekran bağlantısı aracılığıyla destekliyorsa, cihaz uygulaması Android SDK belgesinde açıklandığı gibi ekran yöneticisi API'sını uygulamalıdır [ Resources, 75 ]. Güvenli video çıktısını destekleyen ve güvenli yüzeyleri destekleyebilen cihaz uygulamaları, Display.SECURE_FLAG için destek beyan etmelidir. Özellikle , Display.SECURE_FLAG için destek beyan eden cihaz uygulamaları. Akış yukarı Android açık kaynak uygulaması, bu gereksinimi karşılayan kablosuz (Miracast) ve kablolu (HDMI) ekranlar için destek içerir.

    7.2. Giriş cihazları

    7.2.1. Tuş takımı

    Cihaz uygulamaları:

    • Giriş yönetimi çerçevesine destek (üçüncü taraf geliştiricilerin giriş yönetimi motorları oluşturmasına izin veren - yani yumuşak klavye) http://deceloper.android.com adresinde ayrıntılı olarak yer almalıdır.
    • En az bir sanal klavye uygulaması SAĞLAMALIDIR (sert klavyenin mevcut olup olmadığına bakılmaksızın)
    • Ek yazılımsal klavye uygulamalarını İÇEREBİLİR
    • Donanım klavyesi OLABİLİR
    • android.content.res.Configuration.keyboard [ Resources, 40 ] 'da belirtilen biçimlerden biriyle eşleşmeyen bir donanım klavyesi içermemelidir (yani QWERTY veya 12 Key)

    7.2.2. Dokunmatik Olmayan Navigasyon

    Cihaz uygulamaları:

    • Dokunmasız bir navigasyon seçeneğini atlayabilir (yani bir Trackball, D-Pad veya tekerleği atlayabilir)
    • android.content.res.Configuration.navigation için doğru değeri bildirmelidir [ Kaynaklar, 40 ]
    • Giriş yönetimi motorlarıyla uyumlu metnin seçilmesi ve düzenlenmesi için makul bir alternatif kullanıcı arayüzü mekanizması sağlamalıdır. Akış yukarı Android açık kaynak uygulaması, dokunmasız navigasyon girişlerinden yoksun cihazlarla kullanım için uygun bir seçim mekanizması içerir.

    7.2.3. Gezinme tuşları

    Ana Sayfa, Menü ve Geri işlevleri Android navigasyon paradigması için gereklidir. Cihaz uygulamaları, uygulamaları çalıştırırken bu işlevleri her zaman kullanıcı için kullanılabilir hale getirmelidir. Bu işlevler özel fiziksel düğmeler (mekanik veya kapasitif dokunmatik düğmeler gibi) yoluyla uygulanabilir veya özel yazılım anahtarları, jestler, dokunmatik panel, vb. Kullanılarak uygulanabilir. Android 4.2 her iki uygulamayı da destekler.

    Android 4.2, yardım eylemi desteğini içerir [ Resources, 63 ]. Cihaz uygulamaları, uygulamaları çalıştırırken yardım eylemini her zaman kullanıcı için kullanılabilir hale getirmelidir. Bu işlev donanım veya yazılım anahtarları aracılığıyla uygulanabilir.

    Cihaz uygulamaları, navigasyon tuşlarını görüntülemek için ekranın farklı bir bölümünü kullanabilir, ancak eğer öyleyse, bu gereksinimleri karşılamalıdır:

    • Cihaz Uygulama Gezinme Anahtarları, ekranın farklı bir bölümünü kullanmalı, uygulamalar için kullanılamamalı ve ekranın uygulamalar için mevcut olan kısmını belirlememeli veya başka bir şekilde müdahale etmemelidir.
    • Cihaz uygulamaları, ekranın bir kısmını Bölüm 7.1.1'de tanımlanan gereksinimleri karşılayan uygulamalara sunmalıdır.
    • Aygıt uygulamaları, uygulamalar bir Sistem UI modu belirtmediğinde veya SYSTEM_UI_FLAG_VISIBLE belirttiğinde gezinme tuşlarını görüntülemelidir.
    • Aygıt uygulamaları, uygulamalar SYSTEM_UI_FLAG_LOW_PROFILE belirttiğinde, navigasyon tuşlarını göze çarpmayan bir "düşük profilli" (örn. Dimmed) modunda sunmalıdır.
    • Uygulamalar SYSTEM_UI_FLAG_HIDE_NAVIGATION belirttiğinde cihaz uygulamaları gezinme tuşlarını gizlemelidir.
    • Cihaz uygulaması, hedefler <= 10 olduğunda uygulamalara bir menü anahtarı sunmalı ve hedefler> 10 olduğunda bir menü anahtarı sunmamalıdır.

    7.2.4. Dokunmatik ekran girişi

    Cihaz uygulamaları:

    • Bir tür işaretçi giriş sistemine sahip olmalıdır (fare benzeri veya dokunma)
    • Herhangi bir yöntemden (kapasitif veya direnç gibi) bir dokunmatik ekrana sahip olabilir
    • Bir dokunmatik ekran birden fazla işaretçiyi destekliyorsa, bağımsız olarak izlenen işaretçileri tamamen desteklemelidir
    • Cihazdaki belirli dokunmatik ekranın türüne karşılık gelen android.content.res.Configuration [ kaynaklar, 39 ] değerini bildirmelidir.

    Cihaz uygulamaları, kullanılan giriş türüne karşılık gelen doğru özelliği bildirmelidir. Android 4.2'nin, yüksek fideliteli dokunmatik olmayan (yani, işaretçi tabanlı) bir fare veya izleme çantası gibi, dokunmatik tabanlı girişi (temel dahil dahil olmak üzere (temel de dahil olmak üzere işaretçi tabanlı) bir giriş cihazına karşılık gelen android.hardware.faketouch özelliğini içerdiğini unutmayın ( jest desteği) ve cihazın dokunmatik ekran işlevselliğinin taklit bir alt kümesini desteklediğini gösterir. Bir dokunmatik ekran (tek dokunuş veya daha iyi) içeren cihaz uygulamaları da android.hardware.Faketouch rapor etmelidir. Bir dokunmatik ekran içermeyen (ve yalnızca bir işaretçi cihazına güvenen) cihaz uygulamaları herhangi bir dokunmatik ekran özelliği bildirmemeli ve yalnızca android.hardware.faketouch rapor etmelidir.

    7.2.5. Mikrofon

    Cihaz uygulamaları bir mikrofonu atlayabilir. Bununla birlikte, bir cihaz uygulaması bir mikrofonu atlarsa, android.hardware.microphone özelliğini sabit bildirmemeli ve bölüm 7'ye göre ses kayıt API'sını OPS olarak uygulamalıdır. Tersine, mikrofona sahip cihaz uygulamaları:

    • android.hardware.microphone özellik sabitini bildirmelidir
    • Bölüm 5.4'teki ses kalitesi gereksinimlerini karşılamalıdır
    • Bölüm 5.5'teki ses gecikme gereksinimlerini karşılamalıdır

    7.3. Sensörler

    Android 4.2, çeşitli sensör türlerine erişmek için API'ler içerir. Cihaz uygulamaları genellikle aşağıdaki alt bölümlerde belirtildiği gibi bu sensörleri atlayabilir. Bir cihaz, üçüncü taraf geliştiriciler için karşılık gelen bir API'ya sahip belirli bir sensör türü içeriyorsa, cihaz uygulaması bu API'yi Android SDK belgelerinde açıklandığı gibi uygulamalıdır. Örneğin, cihaz uygulamaları:

    • android.content.pm.PackageManager . [ Kaynaklar, 37 ]
    • SensorManager.getSensorList() ve benzer yöntemler aracılığıyla desteklenen sensörlerin doğru bir listesini döndürmelidir
    • Diğer tüm sensör API'leri için makul davranmalıdır (örneğin, uygulamalar dinleyicileri kaydetmeye çalıştığında, ilgili sensörler mevcut olmadığında sensör dinleyicilerini çağırmaz; vb.)
    • Android SDK belgelerinde tanımlanan her bir sensör türü için ilgili uluslararası birim sistemi (IE metrik) değerlerini kullanarak tüm sensör ölçümlerini rapor etmelidir [ Resources, 41 ]

    Yukarıdaki liste kapsamlı değildir; Android SDK'nın belgelenmiş davranışı yetkili olarak kabul edilmelidir.

    Bazı sensör tipleri sentetiktir, yani bir veya daha fazla diğer sensör tarafından sağlanan verilerden türetilebilir. (Örnekler arasında yönlendirme sensörü ve doğrusal ivme sensörü bulunmaktadır.) Cihaz uygulamaları, önkoşul fiziksel sensörleri içerdiklerinde bu sensör türlerini uygulamalıdır.

    Android 4.2, yalnızca veri değiştiğinde değil, verileri sürekli olarak döndüren bir "akış" sensörü kavramı içerir. Cihaz uygulamaları, Android 4.2 SDK belgeleri ile belirtilen herhangi bir API için bir akış sensörü olarak sürekli olarak periyodik veri örnekleri sağlamalıdır. Cihaz uygulamalarının, sensör akışının CPU cihazının bir askıya alınma durumuna girmesini veya bir askıya alınma durumundan uyanmasını engellememesi gerektiğini unutmayın.

    7.3.1. İvmeölçer

    Cihaz uygulamaları 3 eksenli bir ivmeölçer içermelidir. Bir cihaz uygulaması 3 eksenli ivmeölçer içeriyorsa,:

    • 120 Hz veya daha büyük olaylar sunabilmelidir. Yukarıdaki ivmeölçer frekansının Android 4.2 için "yapılması" olarak belirtilse de, gelecekteki bir sürümün uyumluluk tanımının bunları "zorunluluk" olarak değiştirmesi planlandığını unutmayın. Yani, bu standartlar Android 4.2'de isteğe bağlıdır, ancak gelecekteki sürümlerde gerekli olacaktır . Android 4.2 çalıştıran mevcut ve yeni cihazlar , Android 4.2'de bu gereksinimleri karşılamaya çok teşvik ediliyor, böylece gelecekteki platform sürümlerine yükseltebilecekler
    • Android API'lerinde ayrıntılı olarak ayrıntılı olarak Android Sensör Koordinat Sistemine uymalıdır (bkz. [ Kaynaklar, 41 ])
    • Üç boyutlu herhangi bir vektörde serbest düşüşten iki kat daha fazla yerçekimine (2G) veya daha fazla ölçüm yapabilmelidir
    • 8 bit doğruluğa veya daha fazlasına sahip olmalı
    • 0.05 m/s^2'den fazla olmayan bir standart sapmaya sahip olmalıdır

    7.3.2. Manyetometre

    Cihaz uygulamaları 3 eksenli bir manyetometre içermelidir (yani Compass.) Bir cihaz 3 eksenli bir manyetometre içeriyorsa,:

    • 10 Hz veya daha büyük olaylar sunabilmelidir
    • Android API'lerinde ayrıntılı olarak açıklandığı gibi Android sensörü koordinat sistemine uymalıdır (bkz. [ Kaynaklar, 41 ]).
    • Jeomanyetik alanı kapsayacak kadar çeşitli alan güçlü yönlerini örnekleyebilmelidir
    • 8 bit doğruluğa veya daha fazlasına sahip olmalı
    • 0,5 uT'den fazla olmayan bir standart sapmaya sahip olmalıdır

    7.3.3. Küresel Konumlama Sistemi

    Cihaz uygulamaları bir GPS alıcısı içermelidir. Bir cihaz uygulaması bir GPS alıcısı içeriyorsa, GPS kilitleme süresini en aza indirmek için bir çeşit "destekli GPS" tekniği içermelidir.

    7.3.4. Jiroskop

    Cihaz uygulamaları bir jiroskop (yani açısal değişiklik sensörü) içermelidir. 3 eksenli ivmeölçer de dahil edilmedikçe cihazlar bir jiroskop sensörü içermemelidir. Bir cihaz uygulaması bir jiroskop içeriyorsa,:

    • Sıcaklık telafi edilmelidir
    • 5.5*pi radyan/saniyeye kadar yönlendirme değişikliklerini ölçebilmelidir (yani saniyede yaklaşık 1.000 derece)
    • 200 Hz veya daha yüksek olaylar sunabilmelidir. Yukarıdaki jiroskop frekansının Android 4.2 için "yapılması" olarak belirtilmiş olsa da, gelecekteki bir sürümün uyumluluk tanımının bunları "zorunluluk" olarak değiştirmesi planlandığını unutmayın. Yani, bu standartlar Android 4.2'de isteğe bağlıdır, ancak gelecekteki sürümlerde gerekli olacaktır . Android 4.2 çalıştıran mevcut ve yeni cihazlar , Android 4.2'de bu gereksinimleri karşılamaya çok teşvik ediliyor, böylece gelecekteki platform sürümlerine yükseltebilecekler
    • 12 bit doğruluğa veya daha fazlasına sahip olmalı
    • Hz başına 1e-7 rad^2 / s^2'den fazla bir varyans olmalıdır (Hz başına varyans veya rad^2 / s). Varyansın örnekleme hızına göre değişmesine izin verilir, ancak bu değerle kısıtlanmalıdır. Başka bir deyişle, gyro varyansını 1 Hz örnekleme hızında ölçerseniz, 1e-7 rad^2/s^2'den büyük olmamalıdır.
    • Donanım etkinliğinin mümkün olduğunca gerçekleştiğine yakın zaman damgalarına sahip olmalıdır. Sabit gecikme kaldırılmalıdır.

    7.3.5. Barometre

    Cihaz uygulamaları bir barometre (yani ortam hava basınç sensörü) içerebilir. Bir cihaz uygulaması bir barometre içeriyorsa, şunlardır:

    • 5 Hz veya daha büyük olaylar sunabilmelidir
    • Yüksekliği tahmin etmek için yeterli hassasiyete sahip olmalıdır
    • Sıcaklık telafi edilmelidir

    7.3.7. Termometre

    Cihaz uygulamaları bir termometre (yani sıcaklık sensörü) içerebilir ancak bir cihaz uygulaması bir termometre içeriyorsa, CPU cihazının sıcaklığını ölçmelidir. Başka bir sıcaklığı ölçmemelidir. (Bu sensör türünün Android 4.2 API'larında kullanımdan kaldırıldığını unutmayın.)

    7.3.7. Fotometre

    Cihaz uygulamaları bir fotometre (yani ortam ışık sensörü) içerebilir.

    7.3.8. Yakınlık sensörü

    Cihaz uygulamaları bir yakınlık sensörü içerebilir. Bir cihaz uygulaması bir yakınlık sensörü içeriyorsa, bir nesnenin yakınlığını ekranla aynı yönde ölçmelidir. Yani, bu sensör türünün birincil amacı kullanıcı tarafından kullanılan bir telefonu algılamak olduğundan, yakınlık sensörü ekrana yakın nesneleri algılamak için yönlendirilmelidir. Bir cihaz uygulaması başka bir yönlendirme ile yakınlık sensörü içeriyorsa, bu API aracılığıyla erişilememelidir. Bir cihaz uygulamasının yakınlık sensörü varsa, 1 bit doğruluk veya daha fazla olmalıdır.

    7.4. Veri Bağlantısı

    7.4.1. Telefon

    Android 4.2 API'leri tarafından kullanılan "Telefon" ve bu belge, özellikle sesli çağrılar yerleştirme ve bir GSM veya CDMA ağı üzerinden SMS mesajları gönderme ile ilgili donanıma atıfta bulunur. Bu sesli çağrılar paket anahtarlanabilir veya olmayabilirken, aynı ağ kullanılarak uygulanabilecek herhangi bir veri bağlantısından bağımsız olarak kabul edilen Android 4.2'nin amaçları içindir. Başka bir deyişle, Android "Telefon" işlevselliği ve API'ler özellikle sesli çağrılara ve SMS'ye atıfta bulunur; Örneğin, arama yapamayan veya SMS mesajları gönderemeyen cihaz uygulamaları, veri bağlantısı için hücresel bir ağ kullanıp kullanmadıklarına bakılmaksızın "Android.Hardware.Telephony" özelliğini veya herhangi bir alt özellik özelliğini bildirmemelidir.

    Android 4.2, telefon donanımı içermeyen cihazlarda kullanılabilir. Yani, Android 4.2 telefon olmayan cihazlarla uyumludur. Ancak, bir cihaz uygulaması GSM veya CDMA telefonu içeriyorsa, bu teknoloji için API için tam destek uygulamalıdır. Telefon donanımını içermeyen cihaz uygulamalarının, tam API'leri işlemsiz olarak uygulaması ZORUNLUDUR.

    7.4.2. IEEE 802.11 (WiFi)

    Android 4.2 cihaz uygulamaları, bir veya daha fazla form 802.11 (b/g/a/n, vb.) Destek içermelidir. Bir cihaz uygulaması 802.11 desteği içeriyorsa, ilgili Android API'sını uygulamalıdır.

    Cihaz uygulamaları, SDK belgesinde açıklandığı gibi çok noktaya yayın API'sını uygulamalıdır [ Resources, 62 ]. WiFi desteği içeren cihaz uygulamaları çok noktaya yayın DNS'yi (MDN'ler) desteklemelidir. Cihaz uygulamaları, ekranın aktif bir durumda olmadığı zamanlar da dahil olmak üzere herhangi bir çalışma zamanında MDNS paketlerini (224.0.0.251) filtrelememelidir.

    7.4.2.1. Doğrudan kablosuz bağlantı

    Cihaz uygulamaları WiFi Direct (WiFi eşler arası) desteğini içermelidir. Bir cihaz uygulaması WiFi Direct desteğini içeriyorsa, SDK belgesinde açıklandığı gibi ilgili Android API'sını uygulamalıdır [ Resources, 68 ]. Bir cihaz uygulaması WiFi Direct için destek içeriyorsa,:

    • Düzenli WiFi Operasyonunu Desteklemeli
    • Eşzamanlı WiFi ve WiFi Doğrudan İşlemi Desteklemeli

    7.4.3. Bluetooth

    Cihaz uygulamaları bir Bluetooth alıcı -verici içermelidir. Bir Bluetooth alıcı-verici içeren cihaz uygulamaları, SDK belgesinde açıklandığı gibi RFComm tabanlı Bluetooth API'sını etkinleştirmelidir [ Resources, 42 ]. Cihaz uygulamalarının, cihaza uygun şekilde A2DP, AVRCP, OBEX vb. gibi ilgili Bluetooth profillerini uygulaması GEREKLİdir.

    Uyumluluk Test Paketi, Android RFCOMM Bluetooth API'sinin temel çalışmasını kapsayan durumları içerir. Ancak Bluetooth cihazlar arasında bir iletişim protokolü olduğundan tek bir cihaz üzerinde çalışan birim testleriyle tam olarak test edilemez. Sonuç olarak, cihaz uygulamalarının Ek A'da açıklanan insan odaklı Bluetooth test prosedürünü de geçmesi ZORUNLUDUR.

    7.4.4. Yakın Alan İletişimi

    Cihaz uygulamaları, yakın alan iletişim (NFC) için bir alıcı-verici ve ilgili donanım içermelidir. Bir cihaz uygulaması NFC donanımı içeriyorsa,:

    • Android.hardware.nfc özelliğini android.content.pm.PackageManager.hasSystemFeature() yönteminden rapor etmelidir. [ Kaynaklar, 37 ]
    • Aşağıdaki NFC standartları aracılığıyla NDEF mesajlarını okuyabilmeli ve yazabilmelidir:
      • Aşağıdaki NFC standartları aracılığıyla bir NFC forumu okuyucu/yazar olarak hareket edebilmelidir (NFC Forum teknik özellikleri NFCForum-TS-DigitalProtocol-1.0 tarafından tanımlandığı gibi):
        • NFCA (ISO14443-3A)
        • NFCB (ISO14443-3B)
        • NFCF (JIS 6319-4)
        • Isodep (ISO 14443-4)
        • NFC Forumu Etiket Türleri 1, 2, 3, 4 (NFC Forumu tarafından tanımlanmıştır)
    • Aşağıdaki NFC standartları aracılığıyla NDEF mesajlarını okuyabilmeli ve yazabilmelidir. Aşağıdaki NFC standartlarının Android 4.2 için "yapılması" olarak belirtilmiş olsa da, gelecekteki bir sürümün uyumluluk tanımının bunları "zorunluluk" olarak değiştirmesi planlandığını unutmayın. Yani, bu standartlar Android 4.2'de isteğe bağlıdır, ancak gelecekteki sürümlerde gerekli olacaktır . Android 4.2 çalıştıran mevcut ve yeni cihazlar , Android 4.2'de bu gereksinimleri karşılamaya çok teşvik edilmektedir, böylece gelecekteki platform sürümlerine yükseltebilecekler.
      • NFCV (ISO 15693)
    • Aşağıdaki eşler arası standartlar ve protokoller aracılığıyla veri iletme ve alabilmelidir:
      • ISO 18092
      • LLCP 1.0 (NFC Forumu tarafından tanımlanmıştır)
      • SDP 1.0 (NFC Forumu tarafından tanımlanmıştır)
      • NDEF Push Protokolü [ Kaynaklar, 43 ]
      • SNEP 1.0 (NFC Forumu tarafından tanımlanmıştır)
    • Android Beam için destek içermelidir [ Resources, 65 ]:
      • SNEP varsayılan sunucusunu uygulamalıdır. Varsayılan SNEP sunucusu tarafından alınan geçerli NDEF mesajları, Android.nfc.Action_NDEF_DISCOVERED niyeti kullanılarak uygulamalara gönderilmelidir. Android Beam'i ayarlarda devre dışı bırakma, gelen NDEF mesajının gönderilmesini devre dışı bırakmamalıdır.
      • Cihaz uygulamaları android.settings.nfcSharing_settings'in NFC paylaşım ayarlarını gösterme niyetini onurlandırmalıdır [ Resources, 67 ].
      • NPP sunucusunu uygulamalıdır. NPP sunucusu tarafından alınan mesajlar SNEP varsayılan sunucusuyla aynı şekilde işlenmelidir.
      • Bir SNEP istemcisi uygulamalı ve Android Beam etkinleştirildiğinde varsayılan SNEP sunucusuna giden P2P NDEF'i göndermeye çalışmalıdır. Varsayılan SNEP sunucusu bulunmazsa, istemci bir NPP sunucusuna göndermeye çalışmalıdır.
      • Android.nfc.nfcadapter.setndefpushMessage ve Android.nfc.nfcadapter.setndefpushmessagallback ve android.nfc.nfcadapter.enablegroundngroundnreptore kortu
      • Giden P2P NDEF mesajlarını göndermeden önce 'Beam'e Dokunma' gibi bir jest veya ekran onay kullanmalıdır.
      • Varsayılan olarak Android ışını etkinleştirmelidir
      • Cihaz Bluetooth nesne push profilini desteklediğinde Bluetooth'a NFC bağlantı devirini desteklemelidir. Cihaz uygulamaları , Android.nfc.nfcadapter.setbeamPushuris'i kullanırken Bluetooth'a bağlantı devirini desteklemelidir . NFC Forumu. Böyle bir uygulama, NFC üzerinden devir talebini değiştirme / kayıtları seçmek için SNEP GET isteklerini kullanmalıdır ve gerçek Bluetooth veri aktarımı için Bluetooth nesne push profilini kullanmalıdır.
    • NFC keşif modundayken desteklenen tüm teknolojiler için anket yapmalıdır.
    • Cihaz ekran etkinken uyanıkken ve kilit ekranının kilidi açılırken NFC keşif modunda olmalıdır.

    (Yukarıda belirtilen JIS, ISO ve NFC forum özellikleri için halka açık bağlantıların mevcut olmadığını unutmayın.)

    Ayrıca, cihaz uygulamaları aşağıdaki Mifare teknolojileri için okuyucu/yazar desteği içerebilir.

    Android 4.2'nin bu Mifare türleri için API'leri içerdiğini unutmayın. Bir cihaz uygulaması Mifare'i okuyucu/yazar rolünde destekliyorsa:

    • Android SDK tarafından belgelendiği gibi ilgili Android API'leri uygulamalı
    • Com.nxp.mifare özelliğini android.content.pm.PackageManager.hasSystemFeature() yönteminden bildirmelidir. [ Kaynaklar, 37 ] Bunun standart bir Android özelliği olmadığını ve bu nedenle PackageManager sınıfında bir sabit olarak görünmediğini unutmayın.
    • Karşılık gelen Android API'lerini uygulamamalı veya bu bölümde açıklandığı gibi genel NFC desteğini de uygulamaya koymadıkça com.nxp.mifare özelliğini bildirmemelidir.

    Bir cihaz uygulaması NFC donanımı içermiyorsa, Android.hardware.nfc özelliğini android.content.pm.PackageManager.hasSystemFeature() yöntemi [ Resources, 37 ] ve Android 4.2 NFC API'sini olarak uygulamalıdır. bir op.

    android.nfc.NdefMessage ve android.nfc.NdefRecord sınıfları, protokolden bağımsız bir veri temsili formatını temsil ettiğinden, cihaz uygulamaları bu API'leri NFC'ye destek içermeseler veya android.hardware.nfc özelliğini bildirmeseler bile uygulamalıdır.

    7.4.5. Minimum Ağ Yeteneği

    Cihaz uygulamaları, bir veya daha fazla veri ağı biçimi için destek içermelidir. Özellikle, cihaz uygulamaları 200Kbit/sn veya daha fazla kapasiteye sahip en az bir veri standardı desteği içermelidir. Bu gereksinimi karşılayan teknolojilere örnek olarak Edge, HSPA, EV-DO, 802.11G, Ethernet, vb.

    Fiziksel bir ağ oluşturma standardının (Ethernet gibi) birincil veri bağlantısı olduğu cihaz uygulamaları, 802.11 (WiFi) gibi en az bir ortak kablosuz veri standardı için destek içermelidir.

    Cihazlar birden fazla veri bağlantısı uygulayabilir.

    7.5. Kameralar

    Cihaz uygulamaları arkaya bakan bir kamera içermeli ve öne bakan bir kamera içerebilir. Arkaya bakan bir kamera, cihazın yanında ekranın karşısında bulunan bir kameradır; Yani, geleneksel bir kamera gibi cihazın uzak tarafındaki sahneleri görüntüler. Öne bakan bir kamera, cihazın ekranla aynı tarafında bulunan bir kameradır; Yani, video konferans ve benzer uygulamalar gibi kullanıcıyı görüntülemek için kullanılan bir kamera.

    7.5.1. Arka yüz kamerası

    Cihaz uygulamaları arkaya bakan bir kamera içermelidir. Bir cihaz uygulaması arkaya bakan bir 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ına şeffaf)
    • Sabit odaklı veya EDOF (genişletilmiş alan derinliği) donanımına sahip OLABİLİR
    • Bir flaş içerebilir. Kamera bir flaş içeriyorsa, uygulama bir kameranın FLASH_MODE_AUTO veya FLASH_MODE_ON niteliklerini etkinleştirerek flaşı açıkça etkinleştirmediği sürece, bir android.hardware.Camera.PreviewCallback örneği Kamera önizleme yüzeyine kayıtlıyken flaş lambası YANMAMALIDIR. Camera.Parameters nesnesi. Bu kısıtlamanın cihazın yerleşik sistem kamerası uygulaması için geçerli olmadığını, yalnızca Camera.PreviewCallback kullanan üçüncü taraf uygulamalar için geçerli olduğunu unutmayın.

    7.5.2. Ön kamera

    Cihaz uygulamaları öne bakan bir kamera İÇEREBİLİR. Bir cihaz uygulaması öne bakan bir kamera içeriyorsa,:

    • En az VGA çözünürlüğüne sahip olmalıdır (yani 640x480 piksel)
    • Kamera API'sı için varsayılan olarak öne bakan bir kamera kullanmamalıdır. Yani, Android 4.2'deki kamera API'sının öne bakan kameralar için özel bir desteği vardır ve cihaz uygulamaları, API'yi öne bakan bir kamerayı varsayılan arkaya bakan kamera olarak ele alacak şekilde yapılandırmamalıdır, ancak tek kamera olsa bile cihaz.
    • Bölüm 7.5.1'de açıklandığı gibi arkaya bakan kameralarda bulunan özellikleri (otomatik odaklama, flaş, vb.) İçerebilir.
    • Bir CamerApreview'daki bir uygulama tarafından görüntülenen akışı aşağıdaki gibi yatay olarak yansıtmalı (yani yansıtmalı):
      • Cihaz uygulaması kullanıcı tarafından döndürülebilirse (bir ivmeölçer aracılığıyla otomatik olarak veya kullanıcı girişi yoluyla manuel olarak), kamera önizlemesinin cihazın geçerli yönüne göre yatay olarak yansıtılması gerekir.
      • Mevcut uygulama, kamera ekranının android.hardware.Camera.setDisplayOrientation() [ kaynaklar, 50 ] yöntemine yapılan bir çağrı yoluyla döndürülmesini açıkça talep etmişse, kamera önizlemesi uygulama tarafından belirtilen yönü yatay olarak yansiyon olarak yansıtılmalıdır.
      • Aksi takdirde, önizleme cihazın varsayılan yatay ekseni boyunca yansıtılmalıdır.
    • PostView tarafından görüntülenen görüntüyü kamera önizleme görüntü akışıyla aynı şekilde yansıtmalıdır. (Cihaz uygulaması sonrası görüşü desteklemiyorsa, bu gereksinim açıkça geçerli değildir.)
    • Uygulama geri çağrılarına dönen veya medya depolamaya adanmış son yakalanan hareketsiz görüntü veya video akışlarını yansıtmamalı

    7.5.3. Kamera API Davranışı

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

    1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int) , then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
    2. Bir uygulama bir android.hardware.Camera.PreviewCallback örneğini kaydederse ve önizleme formatı YCbCr_420_SP olduğunda sistem onPreviewFrame() yöntemini çağırırsa, onPreviewFrame() işlevine aktarılan byte[] içindeki veriler ayrıca NV21 kodlama formatında olmalıdır. That is, NV21 MUST be the default.
    3. Device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)

    Device implementations MUST implement the full Camera API included in the Android 4.2 SDK documentation [ Resources, 51 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

    Temel donanım bu özelliği destekliyorsa, cihaz uygulamalarının android.hardware.Camera.Parameters sınıfında sabit olarak tanımlanan her parametre adını tanıması ve dikkate alması ZORUNLUDUR. Cihaz donanımı bir özelliği desteklemiyorsa API'nin belgelendiği gibi davranması gerekir. Bunun tersine, Cihaz uygulamalarının android.hardware.Camera.setParameters() üzerinde sabitler olarak belgelenenler dışında, android.hardware.Camera.Parameters yöntemine iletilen dize sabitlerini dikkate almaması veya tanımaması ZORUNLUDUR. Yani, donanım izin veriyorsa cihaz uygulamalarının tüm standart Kamera parametrelerini desteklemesi ZORUNLUDUR ve özel Kamera parametre türlerini DESTEKLEMEMELİDİR. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 78 ]).

    Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

    Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

    7.5.4. Kamera Yönü

    Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

    7.6. Bellek ve Depolama

    7.6.1. Minimum Bellek ve Depolama

    Device implementations MUST have at least 340MB of memory available to the kernel and userspace. The 340MB MUST be in addition to any memory dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

    Device implementations MUST have at least 350MB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 350MB.

    The Android APIs include a Download Manager that applications may use to download data files [ Resources, 56 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default "cache" location.

    7.6.2. Uygulama Paylaşımlı Depolama Alanı

    Cihaz uygulamalarının uygulamalar için paylaşımlı depolama sunması ZORUNLUDUR. The shared storage provided MUST be at least 1GB in size.

    Cihaz uygulamalarının, varsayılan olarak "kutudan çıktığı gibi" monte edilmiş paylaşılan depolama alanıyla yapılandırılması ZORUNLUDUR. Paylaşılan depolama /sdcard Linux yoluna bağlanmamışsa, cihazın /sdcard gerçek bağlama noktasına bir Linux sembolik bağlantısı içermesi GEREKİR.

    Cihaz uygulamalarının, bu paylaşılan depolama biriminde android.permission.WRITE_EXTERNAL_STORAGE iznini belgelendiği şekilde uygulaması ZORUNLUDUR. Aksi halde, paylaşılan depolama bu izni alan herhangi bir uygulama tarafından yazılabilir OLMALIDIR.

    Cihaz uygulamalarında, Secure Digital kart gibi, kullanıcı tarafından erişilebilen çıkarılabilir depolama donanımına sahip OLABİLİR. Alternatif olarak, cihaz uygulamaları dahili (çıkarılamaz) depolama alanını uygulamalar için paylaşılan depolama alanı olarak tahsis edebilir.

    Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol. If the device implementation supports Media Transfer Protocol:

    • The device implementation SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 57 ].
    • The device implementation SHOULD report a USB device class of 0x00 .
    • The device implementation SHOULD report a USB interface name of 'MTP'.

    If the device implementation lacks USB ports, it MUST provide a host computer with access to the contents of shared storage by some other means, such as a network file system.

    İki yaygın örneği ele almak açıklayıcı olacaktır. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

    Birden fazla paylaşılan depolama yolu (hem SD kart yuvası hem de paylaşılan dahili depolama gibi) içeren cihaz uygulamalarının, her iki konuma yerleştirilen dosyaları şeffaf bir şekilde desteklemek için medya tarayıcı ve ContentProvider gibi temel uygulamaları değiştirmesi GEREKLİdir.

    7.7. USB

    Device implementations SHOULD include a USB client port, and SHOULD include a USB host port.

    If a device implementation includes a USB client port:

    • the port MUST be connectable to a USB host with a standard USB-A port
    • the port SHOULD use the micro USB form factor on the device side. Existing and new devices that run Android 4.2 are very strongly encouraged to meet these requirements in Android 4.2 so they will be able to upgrade to the future platform releases
    • the port SHOULD be centered in the middle of an edge. Device implementations SHOULD either locate the port on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new devices that run Android 4.2 are very strongly encouraged to meet these requirements in Android 4.2 so they will be able to upgrade to future platform releases.
    • if the device has other ports (such as a non-USB charging port) it SHOULD be on the same edge as the micro-USB port
    • it MUST allow a host connected to the device to access the contents of the shared storage volume using either USB mass storage or Media Transfer Protocol
    • it MUST implement the Android Open Accessory API and specification as documented in the Android SDK documentation, and MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 52 ]
    • it MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 66 ]
    • it SHOULD implement support for USB battery charging specification [ Resources, 64 ] Existing and new devices that run Android 4.2 are very strongly encouraged to meet these requirements in Android 4.2 so they will be able to upgrade to the future platform releases

    If a device implementation includes a USB host port:

    • it MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to standard USB-A
    • it MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 53 ]

    Device implementations MUST implement the Android Debug Bridge. If a device implementation omits a USB client port, it MUST implement the Android Debug Bridge via local-area network (such as Ethernet or 802.11)

    8. Performans Uyumluluğu

    Device implementations MUST meet the key performance metrics of an Android 4.2 compatible device defined in the table below:

    Metrik Performans Eşiği Yorumlar
    Uygulama Başlatma Zamanı Aşağıdaki uygulamalar belirtilen süre içinde başlatılmalıdır.
    • Tarayıcı: 1300 ms'den az
    • Contacts: less than 700ms
    • Settings: less than 700ms
    Başlatma süresi, Linux işlemini başlatmak, Android paketini Dalvik VM'ye yüklemek ve onCreate'i çağırmak için geçen süre de dahil olmak üzere, uygulama için varsayılan etkinliğin yüklenmesinin tamamlanmasına kadar geçen toplam süre olarak ölçülür.
    Eşzamanlı Uygulamalar Birden fazla uygulama başlatıldığında, halihazırda çalışmakta olan bir uygulamanın başlatıldıktan sonra yeniden başlatılması, orijinal başlatma süresinden daha kısa sürmelidir.

    9. Güvenlik Modeli Uyumluluğu

    Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 54 ] in the Android developer documentation. Cihaz uygulamaları, herhangi bir üçüncü taraftan/yetkiliden herhangi bir ek izin/sertifika gerektirmeden kendinden imzalı uygulamaların kurulumunu desteklemelidir ZORUNLU. Özellikle uyumlu cihazların aşağıdaki alt bölümlerde açıklanan güvenlik mekanizmalarını desteklemesi ZORUNLUDUR.

    9.1. İzinler

    Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 54 ]. Spesifik olarak, uygulamaların SDK belgelerinde açıklandığı şekilde tanımlanan her izni uygulaması ZORUNLUDUR; hiçbir izin atlanamaz, değiştirilemez veya göz ardı edilemez. Yeni izin kimliği dizelerinin android.* ad alanında olmaması koşuluyla, uygulamalar ek izinler EKLEYEBİLİR.

    9.2. UID ve Süreç Yalıtımı

    Cihaz uygulamalarının, her uygulamanın benzersiz bir Unix tarzı UID olarak ve ayrı bir işlemde çalıştığı Android uygulama sanal alanı modelini desteklemesi ZORUNLUDUR. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 54 ].

    9.3. Dosya Sistemi İzinleri

    Device implementations MUST support the Android file access permissions model as defined in as defined in the Security and Permissions reference [ Resources, 54 ].

    9.4. Alternatif Yürütme Ortamları

    Cihaz uygulamaları, Dalvik sanal makinesi veya yerel kod dışında başka bir yazılım veya teknolojiyi kullanarak uygulamaları çalıştıran çalışma zamanı ortamlarını İÇERMELİDİR. Ancak bu tür alternatif yürütme ortamları, bu bölümde açıklandığı gibi Android güvenlik modelinden veya yüklü Android uygulamalarının güvenliğinden ödün VERMEMELİDİR.

    Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

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

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

    Alternatif çalışma zamanlarının Android korumalı alan modeline uyması ZORUNLUDUR. Özellikle:

    • Alternatif çalışma zamanları, uygulamaları PackageManager aracılığıyla ayrı Android sanal alanlarına (yani, Linux kullanıcı kimlikleri vb.) YÜKLEMELİDİR.
    • Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
    • Alternatif çalışma zamanları ve alternatif bir çalışma zamanı kullanan yüklü uygulamalar, paylaşılan kullanıcı kimliği ve imzalama sertifikasına ilişkin standart Android mekanizmaları dışında, cihazda yüklü olan diğer uygulamaların sanal alanını yeniden KULLANMAMALIDIR
    • Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

    Alternatif çalışma zamanları, süper kullanıcı (kök) veya başka herhangi bir kullanıcı kimliği ayrıcalıklarıyla birlikte başlatılmamalı, bu uygulamalara bu ayrıcalıklar verilmemeli veya bu uygulamalara verilmemelidir.

    Alternatif çalışma zamanlarının .apk dosyaları, bir aygıt uygulamasının sistem görüntüsüne dahil OLABİLİR, ancak aygıt uygulamasında yer alan diğer uygulamaları imzalamak için kullanılan anahtardan farklı bir anahtarla imzalanması ZORUNLUDUR.

    Uygulamaları yüklerken alternatif çalışma zamanlarının, uygulama tarafından kullanılan Android izinleri için kullanıcının onayını alması GEREKLİdir. Yani, bir uygulamanın, ilgili Android iznine sahip bir cihaz kaynağını (Kamera, GPS vb. gibi) kullanması gerekiyorsa, alternatif çalışma zamanının kullanıcıya, uygulamanın bu kaynağa erişebileceği konusunda bilgi vermesi ZORUNLUDUR. . Çalışma zamanı ortamı uygulama yeteneklerini bu şekilde kaydetmiyorsa, çalışma zamanı ortamı, bu çalışma zamanını kullanan herhangi bir uygulamayı yüklerken çalışma zamanının kendisi tarafından tutulan tüm izinleri listelemesi ZORUNLUDUR.

    9.5. Çoklu Kullanıcı Desteği

    Android 4.2 includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

    Device implementations MUST meet these requirements related to multi-user support[ Resources, 71 ]:

    • As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
    • Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]

    Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage. The upstream Android open-source project includes an implementation that uses internal device storage for application external storage APIs; device implementations SHOULD use this configuration and software implementation. Device implementations that include multiple external storage paths MUST NOT allow Android applications to write to the secondary external storage

    9.6. Premium SMS Uyarısı

    Android 4.2 includes support for warning users for any outgoing premium SMS message. Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android open-source project provides an implementation that satisfies this requirement.

    10. Yazılım Uyumluluk Testi

    Device implementations MUST pass all tests described in this section.

    However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 4.2 available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

    10.1. Uyumluluk Test Paketi

    Cihaz uygulamalarının, cihazdaki son gönderim yazılımını kullanarak, Android Açık Kaynak Projesi'nde bulunan Android Uyumluluk Test Paketini (CTS) [ Kaynaklar, 2 ] geçmesi ZORUNLUDUR. Ek olarak, cihaz uygulayıcılarının mümkün olduğunca Android Açık Kaynak ağacındaki referans uygulamasını kullanması GEREKLİdir ve CTS'deki belirsizlik durumlarında ve referans kaynak kodunun bazı bölümlerinin yeniden uygulanmasında uyumluluğu SAĞLAMALIDIR.

    CTS gerçek bir cihazda çalıştırılacak şekilde tasarlanmıştır. Herhangi bir yazılım gibi, CTS'nin kendisi de hatalar içerebilir. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.2. Cihaz uygulamalarının, cihaz yazılımı tamamlandığında mevcut olan en son CTS sürümünü geçmesi ZORUNLUDUR.

    10.2. CTS Doğrulayıcı

    Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

    The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

    Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

    10.3. Reference Applications

    Device implementers MUST test implementation compatibility using the following open source applications:

    • The "Apps for Android" applications [ Resources, 55 ]
    • Replica Island (available in Android Market)

    Uygulamanın uyumlu sayılması için yukarıdaki her uygulamanın başlatılması ve uygulamada doğru şekilde davranması ZORUNLUDUR.

    11. Güncellenebilir Yazılım

    Cihaz uygulamalarının, sistem yazılımının tamamını değiştirecek bir mekanizma içermesi ZORUNLUDUR. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

    Cihaza önceden yüklenmiş yazılımın tamamının yerine geçebilecek herhangi bir yöntem kullanılabilir. Örneğin, aşağıdaki yaklaşımlardan herhangi biri bu gereksinimi karşılayacaktır:

    • Yeniden başlatma yoluyla çevrimdışı güncellemeyle kablosuz (OTA) indirmeler
    • Ana bilgisayardan USB üzerinden "Bağlı" güncellemeler
    • Yeniden başlatma ve çıkarılabilir depolama birimindeki bir dosyadan güncelleme yoluyla "çevrimdışı" güncellemeler

    Kullanılan güncelleme mekanizması, kullanıcı verilerini silmeden güncellemeleri desteklemelidir ZORUNLU. That is, the update mechanism MUST preserve application private data and application shared data. Yukarı akışlı Android yazılımının bu gereksinimi karşılayan bir güncelleme mekanizması içerdiğini unutmayın.

    If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software Az önce açıklanan mekanizmaya göre uygulanabilecek güncelleme mevcut.

    12. Contact Us

    Açıklamalar için ve belgenin kapsamadığını düşündüğünüz sorunları dile getirmek için compatibility@android.com adresinden belge yazarlarıyla iletişime geçebilirsiniz.

    Ek A - Bluetooth Test Prosedürü

    Uyumluluk Test Paketi, Android RFCOMM Bluetooth API'sinin temel çalışmasını kapsayan durumları içerir. Ancak Bluetooth cihazlar arasında bir iletişim protokolü olduğundan tek bir cihaz üzerinde çalışan birim testleriyle tam olarak test edilemez. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

    The test procedure is based on the BluetoothChat sample app included in the Android open source project tree. Prosedür iki cihaz gerektirir:

    • test edilecek yazılım yapısını çalıştıran aday cihaz uygulaması
    • a separate device implementation already known to be compatible, and of a model from the device implementation being tested - that is, a "known good" device implementation

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

    Kurulum ve Kurulum

    1. Build BluetoothChat.apk via 'make samples' from an Android source code tree
    2. Install BluetoothChat.apk on the known-good device
    3. Install BluetoothChat.apk on the candidate device

    Uygulamalara Göre Bluetooth Kontrolünü Test Edin

    1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled
    2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth

    Test eşleştirme ve iletişim

    1. Launch the Bluetooth Chat app on both devices
    2. Make the known-good device discoverable from within BluetoothChat (using the Menu)
    3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device
    4. Send 10 or more messages from each device, and verify that the other device receives them correctly
    5. Close the BluetoothChat app on both devices by pressing Home
    6. Unpair each device from the other, using the device Settings app

    Test eşleştirme ve iletişimi ters yönde test edin

    1. Bluetooth sohbet uygulamasını her iki cihazda da başlatın.
    2. Aday cihazını Bluetoothchat içinden keşfedilebilir yapın (menüyü kullanarak).
    3. Bilinen iyi cihazda, Bluetoothchat içinden Bluetooth cihazlarını tarayın (menüyü kullanarak) ve aday cihazla eşleştirin.
    4. Her cihazdan 10 veya mesaj gönderin ve diğer cihazın bunları doğru aldığını doğrulayın.
    5. Başlatıcıya ulaşmak için tekrar tekrar basarak her iki cihazdaki Bluetooth sohbet uygulamasını kapatın.

    Test yeniden başlatır

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

    Not: Yukarıdaki testlerde, bir test bölümünü ev kullanarak ve bazıları geri kullanan bazı durumlara sahiptir. Bu testler gereksiz değildir ve isteğe bağlı değildir: Amaç, Bluetooth API'sinin ve yığınının hem etkinlikler açıkça sonlandırıldığında (geri basıldığında, bitiş () çağıran ()) ve dolaylı olarak arka plana gönderildiğinde doğru çalıştığını doğrulamaktır ( Eve basan kullanıcı.) Her test dizisi açıklandığı gibi gerçekleştirilmelidir.