Google'ın Genel Çekirdek Görüntüsü, Android'in parçalanma sorununu çözmeye yönelik bir sonraki adımdır

Google, yıllardır Android'deki parçalanmayı azaltmak için çalışıyor; ancak bunun nedenlerinden biri, Android'in doğasında var olan doğası ve seçim ile özgürlüğün iki ucu keskin kılıcıdır. Bu alanda aktif olan sayısız OEM var ve hepsi kendi cihazlarında kendi modifikasyonlarını yapmak istiyor. O halde sorun şu ki, Android işletim sistemi güncellemelerinin genel olarak yayılması yavaş görünüyor, ancak Google'ın OEM'leri cihazlarını güncellemeye zorlamak için yapabileceği pek bir şey yok. Bu nedenle Google'ın yapabileceği bir sonraki en iyi şey, güncelleme sürecini mümkün olduğunca kolay ve sorunsuz hale getirmektir.

Android güncelleme sıkıntısını hafifletmek

Google'ın geliştirme yükünü azaltmaya yönelik uzun vadeli projesindeki ilk büyük girişim, Proje Tiz. 2017'de Android 8.0 Oreo ile birlikte duyurulan Project Treble, işletim sistemi çerçevesini satıcı uygulamasından (HAL'ler ve cihaza özel Linux çekirdek çatalı) ayırarak Android'i modüler hale getirdi. Bu, Android OEM'lerinin, satıcıların güncellenmiş kodlarına ihtiyaç duymadan en son sürümü başlatabilmeleri nedeniyle işletim sistemlerini en son AOSP çerçevesi üzerine yeniden kurmalarını kolaylaştırdı. Sonuç olarak, OEM'ler özel Android çatallarını eskisinden daha hızlı hazırlayabildi ve buna bağlı olarak önemli işletim sistemi güncellemelerini daha hızlı bir şekilde sunabildi.

Google'ın planlarındaki bir sonraki adım, güncellemelerin önemli Android bileşenlerine dağıtımını kolaylaştırmaktı. Google bu girişime çağrıda bulundu Proje Ana Hattı 2019'da Android 10 ile birlikte tanıtıldığında. Google esasen temel işletim sistemi bileşenlerinin kontrolünü ele geçirdi ve OEM'lerin bunları değiştirmesini yasakladı. Daha sonra, OEM'lerin yamaları kendilerinin uygulamasını beklemek zorunda kalmadan bu temel bileşenlere yönelik güncellemeleri uzaktan sunabilmek için Google Play aracılığıyla bir dağıtım mekanizması kurdular. Mainline, cihazların önemli işletim sistemi bileşenlerinin güncellenmiş sürümlerini alma hızını büyük ölçüde iyileştirerek bir bütün olarak Android ekosisteminin güvenliğini artırdı.

Ancak iş Treble'a gelince, Linux çekirdeği gerçekçi olarak kapalı kaynak satıcı koduyla aynı kefeye konmamalı. Todd Kjos bu yılın Linux Tesisatçıları Konferansı Geçmişte Android'de parçalanma söz konusu olduğunda karşılaşılan zorlukları açıklamıştı ve bunların çoğu artık OEM'lerin cihazlarıyla birlikte gönderdiği Linux çekirdeği etrafında yoğunlaşıyor. Bağlam açısından Google, her ana hat Linux çekirdeğini bir "Android Ortak Çekirdeği” (ACK) dalı, ana hat sürümünü yakından takip ediyor ancak Android'e özgü birkaç yama ekliyor. Qualcomm, MediaTek ve Samsung gibi SoC satıcıları daha sonra çatallanıyor O Yaptıkları her SoC için çekirdek. OEM'ler daha sonra SoC'ye özgü çekirdeği alır ve göndermek istedikleri belirli donanıma yönelik desteği uygulamak için ek yamalar ekler.

Yukarıdaki şema, bir cihazın çekirdeğinin, onu Linux LTS çekirdeğinden çok uzakta soyutlayan çeşitli değişim katmanlarından nasıl geçtiğini göstermektedir. Basitleştirmek için Linux Çekirdeği ile başlıyoruz ve birkaç değişiklikle Android Common Çekirdeği ile birleşiyor. Buradan, Android Common Kernel, kendi modifikasyonları ve değişiklikleriyle bir satıcı çekirdeğiyle (Qualcomm, MediaTek, vb.) birleştirilir. Son olarak satıcı çekirdeği, OEM'in aygıta özgü çekirdeğiyle birleştirilir. Bu aşamada herhangi bir cihazın çekirdeği, başlangıçtaki Linux LTS çekirdeğinden çok uzaktadır.

Tüm bu çatalların bir sonucu olarak, bir Android cihazında çalışan kodun %50'ye kadarı ağaç dışı koddur, bu da bunun yukarı akışlı Linux veya AOSP ortak çekirdeklerinden olmadığı anlamına gelir. Bu, yukarı yöndeki değişiklikleri birleştirmeyi inanılmaz derecede zorlaştırır (zaman alıcı ve maliyetli olduğundan bahsetmiyorum bile). OEM'ler için bunu yapmaya yönelik bir teşvik yoktur ancak bu uygulama cihaz güvenliğine zarar verebilir. Bu aynı zamanda birçok Android cihazının eski LTS çekirdek sürümlerinde bırakılmasının nedenidir, bu da cihazların yeni Linux çekirdek özelliklerine erişimini kaybetmesi gibi bir yan etkiye sahiptir.

Android parçalanmış durumda ve Google bunu biliyor

Google bunun bir sorun olduğunu çok iyi biliyor ve hatta "adlı bir bölüm bile var"Parçalanmanın maliyetleri" Android geliştirici belgelerinde. Google bunu söylüyor "amiral gemisi cihazların çoğu zaten en az 18 aylık bir çekirdek sürümüyle birlikte gelir". Daha da kötüsü Google şunu da söylüyor: "Android 10, 3.18, 4.4, 4.9, 4.14 ve 4.19 çekirdeklerini destekliyor ve bazı durumlarda 2017'deki Android 8'den bu yana yeni özelliklerle geliştirilmemiş." Bu, yeni Linux çekirdek sürümleri gerektiren özelliklerin eklenmesini zorlaştırır. Linux çekirdeği 3.18, Android 5.0 Lollipop'un Android'in en son sürümü olduğu Aralık 2014'te piyasaya sürüldü. Bu açıkça bir sorun ve platformu geride tutabilir.

Örneğin Code Aurora Forum veya kısaca CAF, çeşitli Qualcomm Snapdragon SoC'lerin kaynak kodunu barındırır. Bir SoC olarak Qualcomm satıcı, Linux çekirdeğinin çatallanmış bir sürümünü OEM'lere/ODM'lere dağıtır ve bu şirketler daha sonra nakliye sırasında cihaza özgü değişiklikler ekler cihazlar. Birkaç parçalanma katmanı ekleyen şey budur. Ayrıca Qualcomm, Android'i şirketin Snapdragon mobil platformlarının her biri için optimize etmek amacıyla AOSP çerçevesinde değişiklikler yapıyor. Qualcomm, değiştirilmiş Linux çekirdeğini, AOSP çerçevesini ve diğer yazılım araçlarını, Yönetim Kurulu Destek Paketi veya BSP'nin bir parçası olarak ortaklarına özel olarak dağıtır. CAF, Qualcomm'un bu Linux çekirdek değişikliklerini ve AOSP çerçeve değişikliklerini kamuya açıkladığı yerdir.

Bu CAF sürümü, onu saf AOSP yerine bir başlangıç ​​noktası olarak kullanmak isteyen özel ROM geliştiricileri için yararlı olabilir; bu nedenle bazen Forumlarımızdaki “CAF tabanlı” ROM'lar. Yıllardır pek çok orta sınıf akıllı telefona güç veren Snapdragon 625'i hatırlıyor musunuz? Bu, Linux Çekirdeği 3.18 ile piyasaya sürüldü ve ancak 2018'in sonuna doğru (yonga setinin piyasaya sürülmesinden iki yıl sonra) Qualcomm, çekirdek kaynaklarını güncelledi ve bunları şu adreste yayınladı: CAF msm8953 (Snapdragon 625'in yonga seti adı) için Linux Çekirdeği 4.9 desteği geliyor. Sorun şu ki çoğu OEM telefonları bu yeni Linux çekirdeği sürümüne güncellemeyecek, özellikle de çipin piyasaya sürülmesinden iki yıl sonra orta sınıf telefonları piyasaya sürülmüş. Kuşkusuz, böyle büyük bir çekirdek güncellemesinin ilk etapta gerçekleşmesi bile çok nadirdir, ancak önemli olan şu ki sahip olmak gerçekleşti, yani bu sadece imkansız bir senaryo değil.

Kısaca söylemek gerekirse, Android'deki mevcut parçalanma tam bir karmaşa. Google'ın bu parçalanmayı düzeltmeye yönelik son girişimleri Genel Çekirdek Görüntüsü veya GKI biçimindedir.

Genel Çekirdek Görüntüsüne Giriş

Bu parçalanmayı gidermek için Google, Android Genel Çekirdek Görüntüsü (GKI) üzerinde çalıştı. Bu aslında doğrudan bir ACK dalından derlenen bir çekirdektir. GKI, SoC satıcısını ve OEM özelleştirmelerini eklenti modüllerine yalıtarak ağaç dışı kodu ortadan kaldırır ve Google'ın çekirdek güncellemelerini doğrudan son kullanıcıya iletmesine olanak tanır. Bir yılı aşkın bir süredir Google, GKI güncellemelerini Play Store aracılığıyla sunmanın bir yolu üzerinde çalışıyor. Mainline modülünün kullanımı yoluyla.

Sonuç olarak, Android 12 ile başlatılan ve Linux çekirdeği 5.10.43 veya üzerini çalıştıran cihazların aşağıdakilerden birini yapması gerekir: Mishaal Rahman'a göre.

• Google imzalı bir önyükleme görüntüsü dağıtın

VEYA

• GKI tarafından dışa aktarılan KMI'nın bir alt kümesi olan bir KMI'yı (Çekirdek Modülü Arayüzü) dışa aktaran bir çekirdeğe sahip bir önyükleme görüntüsü dağıtın, GKI tarafından kullanıma sunulan UAPI'nin üst kümesi olan bir kullanıcı alanı API'sini dışa aktarır ve karşılık gelen GKI'nın tüm özelliklerini destekler versiyon

Satıcılar GKI'ya bağlanan modüller oluşturabilir, ancak GKI'nın amacı Google'ın çekirdek değişikliklerini yönetme sorumluluğunu üstlenmesidir. Çekirdek Modül Arayüzü (veya KMI, bu konuda daha fazla bilgiyi makalenin sonraki bölümlerinde bulabilirsiniz) ağaç dışı kodun etkili bir şekilde gitmesi beklenen yerdir.

Kutudan Android 12 ile çıkan Google Pixel 6 serisi, Linux çekirdeği 5.10 ile birlikte geliyor ve GKI ile birlikte gönderilen ilk telefon. Google, çekirdeği Play Store aracılığıyla güncelleme potansiyeline sahip olduğundan, sık sık çekirdek güncellemelerini bile görebiliriz. LTS çekirdek güncellemeleri genellikle haftalık olarak yayınlandığından. Her iki durumda da, şu anda hantal olan OTA yoluyla güncelleme yönteminden çok daha iyi bir sistem, ancak bu, doğası gereği GMS çerçevesine bağlı olduğu anlamına geliyor.

Google, GKI'yı basitçe şu şekilde tanımlar:

• ACK kaynaklarından oluşturulmuştur.
• Bu, tek çekirdekli bir ikili artı her mimari için LTS sürümüne göre yüklenebilir modüllerdir (şu anda yalnızca arm64 için). android11-5.4 Ve android12-5.4).
• İlgili ACK için desteklenen tüm Android Platformu sürümleriyle test edilmiştir. GKI çekirdek sürümünün kullanım ömrü boyunca herhangi bir özelliğin kullanımdan kaldırılması söz konusu değildir
• Belirli bir LTS içindeki sürücülere kararlı bir KMI sunar.
• SoC veya karta özel kod içermez.

Hatta Google, 2023 yılına kadar "yukarı yönde ilk" geliştirme modelini benimseyebilecek bir konumda olmayı bile istiyor. Bu, Google'ın yeni kodun ana Linux çekirdeğine ilk önce yerleşmesini sağlamasına yardımcı olacak ve Android cihazlarda ağaç dışı koddan kaynaklanan "teknik borcu" azaltacak.

Çekirdek Modül Arayüzü (KMI)

Çekirdek Modül Arayüzü veya KMI, Google'ın Android'de devam eden parçalanmaya yönelik çözümünün bir parçasıdır. Temelde, SoC ve kart desteği artık çekirdek çekirdekte bulunmuyor ve bunun yerine yüklenebilir modüllere taşınıyor. Modüller güncellendiğinden hem çekirdek hem de modüller bağımsız olarak güncellenebilir. /lib/modules. GKI'nın mümkün olduğu kadar temiz ve genel olması gerekiyor; bu da artık ağaç dışı olan kodun ayrı modüllere aktarılmasıyla mümkün oluyor.

Ted Kjos olarak şu tarihte açıklandı: Bu yılki Linux Tesisatçıları Konferansı'nda, "çok yıllı büyük çaba, donanıma özgü tüm kodları genel çekirdekten satıcı modüllere çıkarmaktır. Eşzamansız olarak gönderilebilmeleri için bu satıcı modülleri ile genel çekirdek arasında istikrarlı bir arayüze sahip olmamız gerekiyor." GKI 1.0 aslında bir "uyumluluk testidir".

Aslında GKI uyumluluğu, cihazın Genel Sistem Görüntüsü (GSI) ile VTS ve CTS-on-GSI+GKI testlerini geçmesi anlamına gelir ve GKI önyükleme görüntüsünün sistemdeki önyükleme bölümüne ve GSI sistem görüntüsüne flaşlanmasıyla yüklenen GKI çekirdeği bölüm. Satıcı Test Paketi veya VTS, tüm cihazların Project Treble ile uyumlu sayılması için geçmesi gereken otomatik bir testtir. Google'ın uygulama paketine erişmek için Uyumluluk Testi Paketi veya CTS gereklidir.

Cihazlar farklı bir ürün çekirdeğiyle birlikte gönderilebilir ve GKI'nın sağlamadığı yüklenebilir modülleri kullanabilir. Ancak hem ürün hem de GKI çekirdekleri, modülleri aynı satıcı_önyükleme ve satıcı bölümlerinden yüklemelidir. Bu nedenle, tüm ürün çekirdeklerinin aynı ikili çekirdek modülü arayüzüne (KMI) sahip olması gerekir.

Yukarıdaki diyagram Google'ın ne yaptığını göstermektedir. istiyor yapması gerektiğini ve buna nasıl ulaşmayı planladığını açıklıyor. Genel Çekirdek ve GKI modülleri AOSP'nin bir parçası olacak ve GKI, bir satıcının uygulayabileceği Android çerçevesi ve Donanım Soyutlama Katmanı (HAL) ile iletişim kurabilecek. Bir satıcının çekirdekte istediği özel özel kod (örneğin, kamera sürücüleri), bunun yerine KMI aracılığıyla GKI'nin bir uzantısı haline gelen bir satıcı modülüne aktarılacaktır.

GKI, Android'in parçalanma sorununu çözmeye nasıl yardımcı olabilir?

Google, akıllı telefonların geliştirme sürecini kolaylaştırmak için birçok çalışma yapıyor. Her OEM kendi marka kimliğini ister ve her OEM, cihazlarının sahibi olmayı ister. Android One programının aksine, Android akıllı telefonlar, Google'ın GMS lisansı almak için belirlediği kurallara uydukları sürece hemen hemen istedikleri her şey olabilir. Ancak geçmişte Google, Android cihaz geliştirmede hakimiyet kurmak için pek bir şey yapmadı. Project Treble, Mainline ve artık GKI'nın Android'de çok daha yeni olması gibi değişiklikler tarih.

Ama faydası olacak mı? Öyle olmalı, ancak daha sonra gözle görülür meyve veren çok yıllı bir olay olması muhtemel. Bu yalnızca Android 12 ile başlayan cihazlar için geçerli olacak, bu da önümüzdeki yıllarda GKI'ya sahip olmayan cihazları göreceğimiz anlamına geliyor. Bu aynı zamanda Project Treble'a da bir eleştiriydi, ancak açıkçası günümüzde piyasaya sürülen tüm cihazlar bunu destekliyor. Bu işler zaman alır ve Google yavaş yavaş Android'in kontrolünü eline alırken, geliştirme süreci de tüm OEM'ler için kolaylaşıyor. Bazıları Android'de kullanılan Linux çekirdeği üzerinde tam kontrolü elinde tutmayı tercih etse bile Android ekosistemi akıllı telefonlar.