Kaynak kodu olmadan geliştiriciler, özel ROM'larda çalışan kameralar gibi donanım bileşenlerini nasıl elde edebilir? Cevap bir BLOB, dolgu ve çok sayıda hata ayıklamadır.
Android Oreo'nun ve birçok cihazın piyasaya sürülmesiyle birlikte Xiaomi Redmi Not 3, GoogleNexus5 Ve diğerleri bunu gayri resmi olarak alıyorgeliştiriciler Android Açık Kaynak Projesi (AOSP) tabanlı bir ROM'u taşıdığında aynı özelliklerin (çoğunlukla kamera) neden bozulduğunu merak etmek muhtemelen adil olacaktır. Muhtemelen, uzun bir bozuk özellikler listesi içeren ROM'ların XDA forum konularını görmüşsünüzdür. "Ne işe yarıyor?" ve ardından çalışan özelliklerin bir listesi, ardından da altta ikonik "Ne çalışmıyor? Sen söyle!" Forumlarımızda Reddit ve Twitter gibi yerlerde pratik olarak meme haline gelen iki popüler nakarattır.
Bir geliştirici bir AOSP ROM'u cihazına taşımaya çalıştığında neden bu kadar çok işlevsellik bozuluyor? Bunun temel yanıtı, işlevlerin Android'in farklı sürümleri arasında değişmesi nedeniyle, BLOB olarak paketlenmiş eski aygıt sürücülerinin Android'in daha yeni sürümleriyle, hatta yalnızca stok AOSP'yle çalışmamasıdır. Geliştiriciler bunun üstesinden gelmek için "şim" adı verilen bir yöntemden yararlanır, ancak ilgili süreç zorludur, zaman alıcıdır ve bazen hata ayıklamak çok zordur.
Bu makalede, özellikle kameranın AOSP tabanlı ROM'larda düzgün çalışmasını sağlamakla ilgili olarak dolguların nasıl çalıştığını ana hatlarıyla anlatacağız. Örnek olarak OnePlus 3T'yi kullanacağız. Bu özellikleri çalıştırmanın zorluğunun büyük ölçüde cihaza özgü olduğunu unutmayın.
OnePlus 3T OxygenOS'u Çalıştırıyor. OnePlus telefonları özel geliştirme kolaylığıyla bilinmesine rağmen, geliştiricilerin AOSP'nin istikrarlı bağlantı noktalarını oluşturmak için perde arkasında yaptığı pek çok çalışma var.
Şim veya BLOB nedir?
Geliştiricilerin ne yaptığını kısmen anlamaya başlamak için önce birkaç şeyi açıklamamız gerekiyor. Her ne kadar Android işletim sistemi açık kaynak olsa da (buna Android Açık Kaynak Projesi denmesinin bir nedeni var), binlerce Android cihazında gönderilen yazılım (çekirdek hariç) öyle değil. Geliştiricilerin kaynak koduna erişimi yok Samsung Deneyimi, EMUI, OksijenOSveya Android'in diğer üçüncü taraf sürümlerinden herhangi biri.
Artık, hisse senedi AOSP'yi Google olmayan bir cihaza taşıyan geliştiriciler muhtemelen bu Android kaplamalarının kaynak kodunu umursamıyorlar çünkü bunlar Bu ROM'ları değiştirmek ve oluşturmak. Çok büyük bir neden olmasa da bu doğru olurdu: Kameranın düzgün çalışmasını sağlamak için gerekli parçalar, esas olarak the kamera HAL'i (Donanım Soyutlama Katmanı), ayrıca kapalı kaynak.
Yalnızca kamera HAL'sinin değil aynı zamanda ROM'un kapalı kaynağına sahip olmanın sorunu, AOSP'yi cihazlarına taşımaya çalışan geliştiricilerin kör çalışmak. Kapalı kaynak OEM ROM, OEM'in kamera HAL kaynağına erişimi olduğundan, kamera HAL ile gayet iyi bir şekilde arayüz oluşturabilir. Kamera HAL'si, ROM'un kamera donanımıyla "konuşmasını" sağlayan şeydir; o olmasaydı kamera işlevsel olmazdı. HAL kamerayı arabanın direksiyon simidi ve pedalları olarak düşünün. Direksiyon simidi/pedallar, sürücünün dahili bileşenleri kullanması için harici bir arayüz (ROM) sağlayarak aracın dahili bileşenlerinin kontrol edilmesine olanak tanır.
Kamera donanımı giderek daha karmaşık hale geldikçe ( çift kameraların ortaya çıkışı, örneğin), kamera HAL kaynağına erişime sahip olmak, işlevsel bir kamerayla bir AOSP ROM'un taşınmasını çok daha kolay hale getirecektir.
Ancak OEM'ler çeşitli nedenlerden dolayı kamera HAL kaynağına erişim sağlamamaktadır. Birincisi, kamera HAL'sinin tüm mülkiyet haklarına sahip değillerse (örneğin diğer şirketlerin fikri mülkiyet haklarını bünyelerinde bulundurduklarında), kaynağı dağıtamazlar. İkincisi, kamera HAL kaynağını serbest bırakmak, kendi fikri mülkiyet haklarını tehlikeye atabilir. Son olarak, şirketlerin bu kaynak kodunu sağlama konusunda herhangi bir yasal yükümlülüğü yoktur (sahip oldukları çekirdek kaynak kodunun aksine). GPL kapsamında yayınlama zorunluluğu), dolayısıyla onu yayınlamak için hiçbir teşvikleri yok. Peki, kamera HAL kaynağına erişim olmadan, geliştiriciler kameranın AOSP ROM'larda çalışmasını tam olarak nasıl sağlıyorlar? Cevap bir BLOB, dolgu ve çok sayıda hata ayıklamadır.
Bir cihaz BLOB (İkili Büyük OBject), yazılımın derlenmiş biçimi olan önceden paketlenmiş ikili dosyaları içerir. Bu durumda, kamera HAL kaynağı OEM tarafından derlenir ve cihazlara ikili dosyalar olarak gönderilir. Geliştiriciler BLOB'lardan bahsettiğinde, canlı cihazlarda gönderilen ve çıkarabildikleri ikili dosyalardan bahsediyorlar. Artık “kamera BLOB'ları” konusu gündeme geldi. uzun süredir rahatsız olan OnePlus aylardır, ancak gerçek şu ki, geliştiricilerin her zaman kamera BLOB'larına erişimi vardı. kamera HAL kaynak kodu altın bilettir buradaki geliştiriciler için, ancak bu asla ve asla serbest bırakılmayacak OnePlus gibi şirketleri içine sokacağı hukuki tehlike nedeniyle.
Bu nedenle, AOSP'yi bir cihaza getirmek isteyen geliştiricilerin elinde yalnızca kaynak koduna erişimleri olmayan kamera HAL'sinin BLOB'ları kalır. Nadiren bir geliştirici AOSP ROM kodunu kamera HAL BLOB ile eşleştirebilir ve çalışmasını bekleyebilir, bu nedenle ikisi arasındaki boşluğu kapatmak için geliştiriciler "" adı verilen bir şey oluşturur.dolgu.”
"Şim" yapmak, "(bir şeyi) sıkıştırmak veya bir boşluğu doldurmaktır." Bu, bir geliştiricinin etkili bir şekilde yaptığı şeydir. bir dolgu yazmak; BLOB'un, çalıştıkları AOSP kaynak koduyla arayüz oluşturmasına izin vermek için kod eklerler ile. Şimler, tüm farklı türlerdeki BLOB'ların AOSP ile çalışmasını sağlamak için kullanılır, ancak genellikle en çok şimleme gerektiren kamera BLOB'udur. Daha önce de belirttiğimiz gibi, dolgu yalnızca Android'in daha yeni sürümlerini bir cihaza taşımak için gerekli değildir (örn. tüm bu resmi olmayan Android Oreo ROM'ları) ancak aynı Android sürümünün AOSP'sini buna taşırken de gerekli cihaz.
Önerilen Kaynaklar: Mağazadan Rafa: MSM8974 Cihazlarının Neden Nougat'tan Hariç Tutulduğuna Dair Derinlemesine Bir Özet
Örneğin OnePlus 2, ödülünü aldı. son resmi büyük işletim sistemi güncellemesi Android 6.0 Marshmallow şeklinde. Ancak cihaz aslında tamamen çalışan özel AOSP tabanlı ROM'lar Android Nougat'ı temel alıyor ve bu, geliştiricilerin ve onların inceliklerinin sıkı çalışması sayesinde. Bazı şim örneklerini inceleyeceğiz, ancak önce şimlerin tam olarak nasıl çalıştığından bahsetmemiz gerekiyor.
Parlatma nasıl çalışır?
Geliştiricilerin kamera HAL'sine veya OEM ROM kaynağına (ve yalnızca önceden derlenmiş ikili dosyalara) erişimi olmadığından, kamera HAL'ın hangi işlevleri beklediğini bilemezler. Bu nedenle, kamera HAL'nin aradığı işlevin adı ile geliştiricinin üzerinde çalıştığı AOSP kodundaki işlevin gerçek adı arasında genellikle bir uyumsuzluk olur.
Bu sorunu çözmek için geliştiricinin aynı adı kullanan yeni bir işlev oluşturması yeterlidir. HAL BLOB kameranın beklediği işlev, ancak bu yeni işlev geliştiricinin istediğini yerine getiriyor bunu. BLOB ile AOSP arasında aracı görevi gören bu yeni işlev, dolgudur. BLOB'un aradığı işlevi bulamadığı bu özel senaryo, dolguya ihtiyaç duyulan en yaygın senaryolardan biridir.
Belki de OnePlus 3T'yi içeren varsayımsal bir örnekle işler biraz daha anlamlı hale gelecektir. OxygenOS ve OnePlus kamerayı kullanarak bir örnek oluşturacağız. AOSP tabanlı bir Nougat ROM oluşturmak için OnePlus 3T için OxygenOS Nougat'tan alınan kamera BLOB'larını kullanırsak sorunlarla karşılaşabiliriz. Bunun nedeni, kamera BLOB'larının (orijinal olarak OEM tarafından derlenmiş olan) OxygenOS içinde ihtiyaç duyduğu tüm işlevlere referans verebilecek olmasıdır, ancak derlenmiş AOSP ROM bu işlevlere sahip olmayabilir veya bunları farklı bir ad altında derlemiş olabilir (böylece işlev sembolleri arasında uyumsuzluğa yol açabilir), hata. Bu, AOSP ROM içinde BLOB'un beklediği adla (bizim dolgumuz) yeni bir işlev oluşturularak düzeltilebilir.
Programlama bağlamındaki semboller, koddaki belirli işlevlere atıfta bulunmak için kullanılır. Kod düzenlendiğinde bir işlevin konumu değişebileceğinden ve dolayısıyla sabit kodlamayı önlemek için semboller gereklidir. İşlevlere yapılan başvurularda derleyici, diğer işlevlerin her zaman sağa başvurmak için kullanabileceği bir semboller tablosu oluşturur. işlev. Derlemeden önce bir fonksiyonun adını değiştirdiğinizde sembolü de değişir, yani temel olarak herhangi bir değişiklik olur. OEM'in derlemeden önce kamera HAL kaynağına yapması, geliştiricilerin yeni bir kaynak oluşturmasını gerektirecektir. şim.
Şu ana kadar sunduğumuz açıklama, şim oluşturmanın kolay olduğunu gösteriyor. Burada ve orada birkaç işlev adını değiştirmek kulağa çok zor gelmiyor, değil mi? Keşke bu kadar kolay olsaydı. Şimlerin gerçekliği, işlev yeniden adlandırmalarından daha fazlasını içerir. Üzerinde çalıştığı en zor dolgulardan birinin örneğini bize sunabilen XDA Tarafından Tanınmış Geliştirici Sultanxda ile konuştuk.
Shimming - Göründüğü Kadar Kolay Değil
OnePlus 3T'ye aşina olmayanlar için, ön kamera başlangıçta oldukça bozuktu. AOSP tabanlı özel ROM'lar. Başlangıç olarak, 8MP'nin üzerinde herhangi bir fotoğraf çekmeye çalışmak, çöküyor. Sultanxda bu sorunu çözme girişiminde birkaç adım attı. şimler OnePlus 3T ön kameranın düzgün çalışmasını sağlamak için.
Shim #1 - Kamera Paketi Adını Değiştirme
Sultanxda, kullanıcı 8MP'nin üzerinde bir fotoğraf çektiğinde ön kameranın çökmesini önlemek için kamera HAL'sini tüm kameraları OnePlus kamera olarak tanımlamaya zorladı. Bunun nedeni, OnePlus'ın belirli uygulamalara bir yardımcı işlev ayırmaya karar vermesidir (isOnePlusCamera, isFacebookCamera, vb.) bir nedenden dolayı. Sultanxda, kamera HAL'ini değiştirerek bu sorunu çözdü; böylece kullanıcı, sanki OnePlus kamerayı kullanıyormuş gibi - kullanmasa bile - her zaman "doğru" değerini döndüren yeni bir işleve işaret ediyor.
Şim #2 - QuadraCfa'yı devre dışı bırak
Bir sonraki ayar işleminde, muhtemelen kamerayla ilgili Qualcomm'a ait tescilli bir teknoloji olan QuadraCfa'yı devre dışı bırakmak zorunda kaldı. Muhtemelen ne ben ne de Sultanxda QuadraCfa'nın ne olduğundan tam olarak emin olmadığımız için söylüyoruz, ancak Sultanxda, etkinleştirildiğinde ön kameranın kırıldığını biliyor.
QuadraCfa'nın bir şekilde kendi kendine etkinleştiğini gözlemledi ancak bunu neden ve nasıl yaptığından emin değildi. Bunu çözmek onun açısından oldukça alışılmadık bir değişiklik gerektiriyordu. Geleneksel bir dolguda, dolgu işlevi derlendiğinde BLOB'un aradığı eksik sembolü sağlar. Bu durumda BLOB, ihtiyaç duyduğu sembollere zaten sahipti; bunlar muhtemelen QuadraCfa'yı başlatan işlevleri temsil ediyordu.
Bu nedenle, HAL kamerası tarafından kullanılan sembolleri geçersiz kılması ve aslında onları "eksik" hale getirmesi gerekiyordu. onun şimler bu “eksik” sembolleri sağlayacaktır. Bunu yapmanın tek yolu hex kamera HAL'in kendisini düzenliyor. Hex düzenleme temel olarak samanlıkta bir iğne (düzenlemek istediğiniz bir işlev veya dize) bulmak için ikili veri biçimindeki bir grup düzensiz anlamsızlığa bakmaktır.
Bir işlevi hex olarak düzenlemek, bir dizeyi hex olarak düzenlemekten çok daha zordur, ancak neyse ki Sultanxda, bunun yerine QuadraCfa'nın arkasındaki işlevleri hex olarak düzenlemek zorunda kalmamayı başardı. Bu sembolleri geçersiz kılmak için sembol adlarını düzenleyen hex.
Şim #3 - Parlak Işık Çarpması Düzeltmesi
Daha sonra Sultanxda, parlak aydınlatma koşullarında ön kameradan fotoğraf çekmenin kameranın çökmesine neden olacağını tespit etti. Bu hatayı kendi cihazında yeniden oluşturmak için Sultanxda aslında OnePlus One'ın el feneri işlevini açtı ve ışığı OnePlus 3T'nin ön kamerasının önüne tuttu çökmesini sağlamak ve kullanılabilir günlükler üretmek için! Çökmeye hangi işlevin neden olduğunu keşfettikten sonra, cihazı ön kamera için her zaman düşük ışık modunu kullanmaya zorlamak için bir dolgu oluşturdu.
Shim #4 - Düşük Çözünürlüklü Öne Bakan Kamera Resimleri
Parlak ışık çarpmasını önceki takozla düzelttikten sonra Sultanxda, aslında bu takozun doğrudan bir sonucu olarak ortaya çıkan başka bir hata keşfetti: düşük çözünürlüklü ön kamera görüntüleri. Kullanıcının istediği çözünürlükte fotoğraf çekmek yerine (örn. 16MP), ortaya çıkan fotoğraf 4MP'de çekilecektir.
Bunu çözmek için işlevlerde değişiklik yapması gerekiyordu handleSuperResolution Ve isSuperResolution her zaman doğruya dönmek için, ancak YALNIZCA öne bakan kamera etkin olduğunda (çünkü aksi takdirde, arka sensörden fotoğraf çekerken kamera çökebilir).
Öğrenilen Ders - Şimleme Zor Olabilir
Sultanxda, OnePlus 3T ön kameranın çalışmasını sağlamak için oluşturmak zorunda olduğu dolguların tipik dolgu örneğini temsil etmediğini itiraf ediyor. Karmaşıklığı ve BLOB'un kendisini hex düzenlemenin nadir gerekliliği göz önüne alındığında, dolgusuyla oldukça gurur duyuyor. Ancak bu örnek, kamera donanımını belirli cihazlarda çalıştırmanın ne kadar zor olabileceğini gösteriyor.
Umarım kameranızın maceraları benimkinden daha az acı verici olur. -Sultanxda
Günlükler, günlükler ve daha fazla günlük. Bir kilitlenmeyi yeniden oluşturmanın tutarlı bir yolu ve günlükler olmadan, geliştiricilerin sorunun kaynağını bulma konusunda çok az umudu var. Soruna neyin sebep olduğunu bulsalar bile bu her zaman basit bir çözüm olmayabilir. Bu hataları bulma ve giderme sürecinin tamamı günler veya haftalar sürebilir ve kameranın AOSP ROM'larda onarılmasının en zor görevlerden biri olmasının nedeni budur.
Cihazınızda tam işlevli donanıma sahip bir AOSP ROM taşınmışsa, umarım Bu geliştiricilerin size bunları sunmak için yaşamış olabileceği mücadeleyi takdir ediyorum. özellikler. Yaptıkları iş için onları takdir edin çünkü bu kolay değil. Forumlarımızdaki yetenekli geliştiriciler Android'in görünmeyen birçok parçasıyla ilgilendiğinden, kullanıcıların büyük çoğunluğunun farkına bile varmayacağı çok fazla iş var.
Bu makalenin hazırlanmasında önerdiği birçok katkı için Sultanxda'ya özel teşekkürlerimizi sunmak isteriz.