Aşağıdaki şekilde Android sensör yığını gösterilmektedir. Her bileşen yalnızca doğrudan üstündeki ve altındaki bileşenlerle iletişim kurar. Ancak bazı sensörler, sensör hub'ı mevcut olduğunda bu hub'ı atlayabilir. Uygulamalardan sensörlere kontrol akışları, sensörlerden uygulamalara ise veri akışları gerçekleşir.
1. şekil. 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, kullanılabilir sensörleri listelemek ve bir sensöre kaydolmak için işlevler içerir.
Uygulama, bir sensöre kaydolurken tercih ettiği örnekleme sıklığını ve gecikme gereksinimlerini belirtir.
- Örneğin, bir uygulama varsayılan ivmeölçere kaydolabilir, 100 Hz'de etkinlik isteyebilir ve etkinliklerin 1 saniyelik gecikmeyle bildirilmesine izin verebilir.
- Uygulama, ivmeölçerden en az 100 Hz hızında etkinlikler alır ve bu etkinlikler 1 saniyeye kadar gecikebilir.
SDK hakkında daha fazla bilgi için geliştirici belgelerini inceleyin.
Framework
Çerçeve, çeşitli uygulamaları HAL'ye bağlamaktan sorumludur. HAL'nin kendisi tek istemcili bir sistemdir. Bu çoklu iletim, çerçeve düzeyinde gerçekleşmediği takdirde herhangi bir zamanda her sensöre yalnızca tek bir uygulama erişebilir.
- Bir sensöre ilk uygulama kaydedildiğinde çerçeve, sensörü etkinleştirmek için HAL'ye bir istek gönderir.
- Aynı sensöre ek uygulamalar kaydedildiğinde çerçeve, her uygulamanın gereksinimlerini dikkate alır ve güncellenen istenen parametreleri HAL'ye gönderir.
- Örnekleme sıklığı, istenen örnekleme sıklıklarının maksimum değeri olur. Bu nedenle bazı uygulamalar, istediklerinden daha yüksek bir sıklıkta etkinlik alır.
- Maksimum raporlama gecikmesi, istenen değerler arasındaki minimum değer olacaktır. Bir uygulama, maksimum raporlama gecikmesi 0 olan bir sensör isterse bazı uygulamalar sensörü sıfır olmayan bir maksimum raporlama gecikmesiyle istemiş olsa bile tüm uygulamalar bu sensörden gelen etkinlikleri sürekli modda alır. Daha fazla bilgi için Toplu işleme bölümüne bakın.
- Bir sensöre kayıtlı son uygulama sensörden kaydını sildiğinde, gereksiz güç tüketimini önlemek için çerçeveler sensörü devre dışı bırakmak üzere HAL'ye bir istek gönderir.
Çoklu yayınlamanın etkisi
Çerçevede çoklama katmanına duyulan bu ihtiyaç, bazı tasarım kararlarını açıklar.
- Bir uygulama belirli bir örnekleme sıklığı istediğinde, etkinliklerin daha hızlı bir şekilde gelmeyeceğine dair bir garanti yoktur. Başka bir uygulama aynı sensörü daha hızlı bir oranda isterse ilk uygulama da bu verileri hızlı oranda alır.
- Aynı garanti eksikliği, istenen maksimum raporlama gecikmesi için de geçerlidir: Uygulamalar, istediklerinden çok daha az gecikmeyle etkinlik alabilir.
- Örnekleme sıklığı ve maksimum raporlama gecikmesinin yanı sıra uygulamalar, 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 olduğunu düşünün.
- Aksi takdirde bir uygulama yüksek doğruluk modunu, diğeri ise düşük güç modunu isteyebileceğinden, Android cihazlarda bu iki moddan yalnızca biri kullanılabilir. Çerçevenin her iki uygulamayı da karşılaması 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 bozulmasına neden olamaz.
Sensör birleştirme
Android çerçevesi, bazı bileşik sensörler için varsayılan bir uygulama sağlar. Bir cihazda jiroskop, ivme ölçer ve manyetometre bulunup dönme vektörü, yer çekimi ve doğrusal ivme sensörleri bulunmadığında çerçeve, bu sensörleri uygulamaların kullanabilmesi için uygular.
Varsayılan uygulama, diğer uygulamaların erişebildiği tüm verilere erişemez ve SoC üzerinde çalışması gerektiğinden diğer uygulamalar kadar doğru veya güç açısından verimli değildir. Cihaz üreticileri, mümkün olduğunca bu varsayılan uygulamaya güvenmek yerine kendi birleştirilmiş sensörlerini (dönüş vektörü, yerçekimi ve doğrusal ivme ile oyun dönüş vektörü gibi daha yeni bileşik sensörler) tanımlamalıdır. Cihaz üreticileri, sensör çipi satıcılarından da uygulama sağlamalarını isteyebilir.
Varsayılan sensör füzyonu uygulaması korunmuyor ve bu uygulamaya dayanan cihazların CTS'yi geçememesine neden olabilir.
Gelişmiş seçenekler
Bu bölüm, Android Açık Kaynak Projesi (AOSP) çerçeve kodunu koruyanlar 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şmek için daha düşük düzeydeki 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 paket sağlar. Yerel çerçeve, sensöre özgü hizmetlere erişmek için Binder IPC proxy'lerini çağırır.
Binder IPC
Binder IPC proxy'leri, süreç sınırları üzerinden iletişimi kolaylaştırır.
HAL
Sensors Hardware Abstraction Layer (HAL) API, donanım sürücüleri ile Android çerçevesi arasındaki arayüzdür. Bu, bir HAL arayüzü (sensors.h) ve bir HAL uygulamasından (sensors.cpp) 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 konumunda bulunur.
Daha fazla bilgi için sensors.h dosyasına bakın.
Lansman süreci
HAL uygulaması, your_poll_device.common.version ayarını yaparak hangi HAL arayüzü 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 artık desteklenmeyecektir. Bu belgede, tüm cihazların yükseltilmesi gereken 1.3 sürümünün davranışı açıklanmaktadır. 1.3 sürümüne nasıl yükselteceğinizle ilgili ayrıntılar 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 ise donanım entegratörü, sürücüleri sağlaması için sensör çipi üreticilerinden talepte bulunur ancak HAL uygulamasını yazan taraf kendisidir.
Her durumda, HAL uygulaması ve çekirdek sürücüleri donanım üreticilerinin sorumluluğundadır ve Android, bunları yazmak için tercih edilen yaklaşımlar sunmaz.
Sensör merkezi
Bir cihazın sensör yığını, isteğe bağlı olarak bir sensör hub'ı içerebilir. Bu hub, SoC askıya alma modundayken düşük güçte bazı düşük seviyeli hesaplamalar yapmak için kullanışlıdır. Örneğin, bu çiplerde adım sayma veya sensör füzyonu gerçekleştirilebilir. Ayrıca, sensör etkinlikleri için donanım FIFO'ları ekleyerek sensör gruplaması uygulamak için de iyi bir yerdir. Daha fazla bilgi için Toplu işleme bölümünü inceleyin.
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 hub'ının nasıl somutlaştırıldığı mimariye bağlıdır. Bazen ayrı bir çip, bazen de SoC ile aynı çip üzerinde yer alır. Sensör hub'ının önemli özellikleri arasında, toplu işlem için yeterli belleğe sahip olması ve düşük güç tüketen Android sensörlerinin uygulanabilmesi için çok az güç tüketmesi yer alır. Bazı sensör merkezlerinde genel hesaplama için bir mikro denetleyici ve düşük güç sensörleri için çok düşük güçte hesaplama sağlayan donanım hızlandırıcılar bulunur.
Sensör hub'ının mimarisi ve sensörlerle ve SoC ile (I2C veri yolu, SPI veri yolu, …) iletişimi Android tarafından belirtilmez ancak genel güç kullanımını en aza indirmeyi amaçlamalıdır.
Uygulama basitliği üzerinde önemli bir etkisi olduğu görünen bir seçenek, sensör hub'ından SoC'ye giden iki kesme hattına sahip olmaktır: biri uyandırma kesmeleri (uyandırma sensörleri için), diğeri ise uyandırma dışı kesmeler (uyandırma dışı sensörler için).
Sensörler
Bunlar, ölçümleri yapan fiziksel MEMS çipleridir. Çoğu durumda, aynı çip üzerinde birden fazla fiziksel sensör bulunur. Örneğin, bazı çiplerde ivme ölçer, jiroskop ve manyetometre bulunur. (Bu tür çipler genellikle 9 eksenli çipler olarak adlandırılır. Bunun nedeni, her sensörün 3 eksen üzerinden veri sağlamasıdır.)
Bu çiplerin bazılarında hareket algılama, adım algılama ve 9 eksenli sensör füzyonu gibi normal hesaplamaları yapmak için bazı mantıklar da bulunur.
CDD güç ve doğruluk şartları ile önerileri fiziksel sensörleri değil, Android sensörünü hedeflese de bu şartlar fiziksel sensörlerin seçimini etkiler. Örneğin, oyun dönüş vektöründeki doğruluk şartı, fiziksel jiroskop için gereken doğruluğu etkiler. Fiziksel sensörlerle ilgili koşulları belirlemek cihaz üreticisinin sorumluluğundadır.