Aşağıdaki şekil, Android sensör yığınını temsil etmektedir. Her bileşen yalnızca doğrudan üstündeki ve altındaki bileşenlerle iletişim kurar. Ancak bazı sensörler, mevcut olduğunda sensör merkezini atlayabilir. Kontrol, uygulamalardan sensörlere, veriler ise sensörlerden uygulamalara akar.
Şekil 1. Android sensör yığınının katmanları ve ilgili sahipleri
SDK
Uygulamalar, Sensors SDK (Yazılım Geliştirme Kiti) API aracılığıyla sensörlere erişir. SDK, mevcut sensörleri listeleme ve bir sensöre kaydolmaya yönelik işlevler içerir.
Uygulama, bir sensöre kaydedilirken tercih ettiği örnekleme sıklığını ve gecikme şartlarını belirtir.
- Örneğin, bir uygulama varsayılan ivme ölçere kaydedilebilir, 100 Hz'de etkinlik isteyebilir ve etkinliklerin 1 saniyelik gecikmeli olarak bildirilmesine izin verebilir.
- Uygulama, en az 100 Hz hızında ve muhtemelen 1 saniye gecikmeli olarak ivmeölçerden etkinlik alır.
SDK hakkında daha fazla bilgi için geliştirici belgelerine bakın.
Çerçeve
Çerçeve, çeşitli uygulamaları HAL'a bağlamaktan sorumludur. HAL tek müşterilidir. Çerçeve düzeyinde bu çoklu yayın yapılmazsa her bir sensöre herhangi bir zamanda yalnızca tek bir uygulama erişebilir.
- İlk uygulama bir sensöre kaydolduğunda çerçeve, sensörü etkinleştirmek için HAL'e bir istek gönderir.
- Aynı sensöre ek uygulamalar kaydolduğunda çerçeve, her uygulamanın şartlarını dikkate alır ve istenen güncellenmiş parametreleri HAL'e gönderir.
- Örnekleme sıklığı, istenen örnekleme sıklıklarının en yüksek değeri olacaktır. Bu, bazı uygulamaların istenenden daha yüksek bir sıklıkta etkinlik alacağı anlamına gelir.
- Maksimum raporlama gecikmesi, istenen gecikmeler arasından en düşük olanıdır. Bir uygulama, maksimum raporlama gecikmesi 0 olan bir sensör isterse bazı uygulamalar sensörü sıfır olmayan bir maksimum raporlama gecikmesiyle istese bile tüm uygulamalar bu sensörden gelen etkinlikleri sürekli modda alır. Daha fazla bilgi için Gruplandırma bölümüne bakın.
- Bir sensöre kayıtlı son uygulamanın kaydı silindiğinde, çerçeveler, gereksiz yere güç tüketilmemesi için HAL'e sensörü devre dışı bırakması yönünde bir istek gönderir.
Çoklu yayının etkisi
Çerçevede bir çoklu yayın katmanına duyulan ihtiyaç, bazı tasarım kararlarını açıklar.
- Bir uygulama belirli bir örnekleme sıklığı istediğinde, etkinliklerin daha hızlı bir hızda gelmeyeceğine dair bir garanti yoktur. Başka bir uygulama aynı sensörü daha hızlı bir hızda talep ederse ilk uygulama da bu verileri hızlı hızda alır.
- İstenen maksimum raporlama gecikmesi için de aynı garanti eksikliği geçerlidir: Uygulamalar, istenenden çok daha düşük gecikmeli etkinlikler alabilir.
- Uygulamalar, örnekleme sıklığı ve maksimum raporlama gecikmesi dışındaki sensör parametrelerini yapılandıramaz.
- Örneğin, hem "yüksek doğruluk" hem de "düşük güç" modlarında çalışabilen fiziksel bir sensör düşünün.
- Android cihazlarda bu iki moddan yalnızca biri kullanılabilir. Aksi takdirde, bir uygulama yüksek doğruluk modunu, diğeri ise düşük güç modunu isteyebilir. Bu durumda çerçevenin her iki uygulamayı da tatmin etmesi mümkün olmaz. Çerçeve her zaman tüm müşterilerini memnun edebilmelidir. Bu nedenle bu seçenek kullanılamaz.
- Uygulamalardan sensörlere veya sürücülerine veri gönderme mekanizması yoktur. Bu sayede, bir uygulama sensörlerin davranışını değiştirerek diğer uygulamaların çalışmasını bozamaz.
Sensör birleştirme
Android çerçevesi, bazı karma sensörler için varsayılan bir uygulama sağlar. Bir cihazda jiroskop, ivme ölçer ve manyetometre varsa ancak dönme vektörü, yerçekimi ve doğrusal hızlanma sensörleri yoksa çerçeve, uygulamaların bu sensörleri kullanmaya devam edebilmesi için bu sensörleri uygular.
Varsayılan uygulama, diğer uygulamaların erişebildiği tüm verilere erişemez ve SoC'de çalışmalıdır. Bu nedenle, diğer uygulamalar kadar doğru veya enerji verimli değildir. Cihaz üreticileri, mümkün olduğunca bu varsayılan uygulamaya güvenmek yerine kendi birleşik sensörlerini (dönme vektörü, yerçekimi ve doğrusal hızlanma, ayrıca oyun dönme vektörü gibi yeni kompozit sensörler) tanımlamalıdır. Cihaz üreticileri, sensör çipi tedarikçilerinden de uygulama sunmalarını isteyebilir.
Varsayılan sensör birleştirme uygulaması artık desteklenmiyor ve bu uygulamaya dayalı cihazların CTS'de başarısız olmasına neden olabilir.
Gelişmiş seçenekler
Bu bölüm, Android Açık Kaynak Projesi (AOSP) çerçeve kodunu yönetenler için arka plan bilgisi olarak sağlanmıştır. Donanım üreticileri için geçerli değildir.
JNI
Çerçeve, android.hardware ile ilişkili ve frameworks/base/core/jni/ dizininde bulunan bir Java Native Interface (JNI) kullanır. Bu kod, sensör donanımına erişim elde etmek için daha düşük düzeyli yerel kodu çağırır.
Yerel çerçeve
Yerel çerçeve frameworks/native/ içinde tanımlanır ve android.hardware paketine eşdeğer bir yerel çerçeve sağlar. Yerel çerçeve, sensöre özgü hizmetlere erişim elde etmek için Binder IPC proxy'lerini çağırır.
Cilt IPC
Binder IPC proxy'leri, işlem sınırları üzerinden iletişimi kolaylaştırır.
HAL
Sensörler Donanım Soyutlama Katmanı (HAL) API'si, donanım sürücüleri ile Android çerçevesi arasındaki arayüzdür. Bir HAL arayüzünden (sensors.h) ve sensors.cpp olarak adlandırdığımız bir HAL uygulamasından oluşur.
Arayüz Android ve AOSP katkıda bulunanları tarafından tanımlanır, uygulama ise cihazın üreticisi tarafından sağlanır.
Sensör HAL arayüzü hardware/libhardware/include/hardware adresinde bulunur.
Daha ayrıntılı bilgi için sensors.h dosyasına bakın.
Lansman süreci
HAL uygulaması, your_poll_device.common.version değerini ayarlayarak HAL arayüzünün hangi sürümünü uyguladığını belirtir. Mevcut HAL arayüz sürümleri sensors.h dosyasında tanımlanır ve işlevler bu sürümlere bağlıdır.
Android çerçevesi şu anda 1.0 ve 1.3 sürümlerini desteklemektedir ancak 1.0 sürümü yakında desteklenmeyecektir. Bu dokümanda, tüm cihazların yükseltmesi gereken 1.3 sürümünün davranışı açıklanmaktadır. 1.3 sürümüne nasıl geçeceğinizle ilgili ayrıntılı bilgi için HAL sürümünün desteğinin sonlandırılması başlıklı makaleyi inceleyin.
Çekirdek sürücüsü
Sensör sürücüleri fiziksel cihazlarla etkileşimde bulunur. Bazı durumlarda HAL uygulaması ve sürücüler aynı yazılım öğesidir. Diğer durumlarda, donanım entegratörü sensör çipi üreticilerinden sürücüleri sağlamasını ister ancak HAL uygulamasını yazan yine onlar olur.
HAL uygulaması ve çekirdek sürücüleri her durumda donanım üreticilerinin sorumluluğundadır ve Android, bunları yazmak için tercih edilen yaklaşımlar sağlamaz.
Sensör merkezi
Bir cihazın sensör yığınında isteğe bağlı olarak bir sensör merkezi bulunabilir. Bu merkez, SoC askıya alınmış moddayken düşük güçte bazı düşük düzeyli hesaplamalar yapmak için kullanışlıdır. Örneğin, bu çiplerde adım sayma veya sensör birleştirme işlemleri yapılabilir. Ayrıca, sensör etkinlikleri için donanım FIFO'ları ekleyerek sensör gruplandırmayı uygulamak için de iyi bir yerdir. Daha fazla bilgi için Gruplandırma bölümüne bakın.
Not: Yeni sensörler veya LED'ler kullanan yeni ContextHub özellikleri geliştirmek için Hikey veya Hikey960 geliştirme kartına bağlı bir Neonkey SensorHub da kullanabilirsiniz.
Sensör merkezinin nasıl somutlaştırılacağı mimariye bağlıdır. Bazen ayrı bir çip, bazen de SoC ile aynı çipe dahildir. Sensör merkezinin önemli özellikleri, gruplandırma için yeterli bellek içermesi ve düşük güç tüketimi olan Android sensörlerinin uygulanmasını sağlamak için çok az güç tüketmesidir. Bazı sensör merkezleri, genel hesaplama için bir mikrodenetleyici ve düşük güç sensörleri için çok düşük güç hesaplaması sağlayan donanım hızlandırıcılar içerir.
Sensör merkezinin mimari yapısı ve sensörlerle ve SoC ile (I2C veri yolu, SPI veri yolu vb.) nasıl iletişim kurduğu Android tarafından belirtilmez ancak genel güç kullanımını en aza indirmeyi amaçlamalıdır.
Uygulamanın basitliği üzerinde önemli bir etkisi olduğu görülen bir seçenek, sensör merkezinden SoC'ye giden iki kesinti hattının olmasıdır: biri uyanma kesintileri (uyanma sensörleri için) ve diğeri uyanma dışı kesintiler (uyanma dışı sensörler için).
Sensörler
Bunlar, ölçümleri yapan fiziksel MEMS çipleridir. Çoğu durumda, aynı çipte birkaç fiziksel sensör bulunur. Örneğin, bazı çiplerde ivme ölçer, jiroskop ve manyetometre bulunur. (Her sensör 3 eksen üzerinden veri sağladığı için bu tür çipler genellikle 9 eksenli çip olarak adlandırılır.)
Bu çiplerden bazıları, hareket algılama, adım algılama ve 9 eksenli sensör birleştirme gibi normal hesaplamaları gerçekleştirmek için mantık da içerir.
CDD gücü ve doğruluğu ile ilgili şartlar ve öneriler fiziksel sensörleri değil Android sensörünü hedef alsa da bu şartlar fiziksel sensör seçimini etkiler. Örneğin, oyun dönme vektöründeki doğruluk koşulu, fiziksel jiroskop için gereken doğrulukla ilgili sonuçlar doğurur. Fiziksel sensörlerle ilgili koşulları belirlemek cihaz üreticisine bağlıdır.