Google-ის Generic Kernel Image არის შემდეგი ნაბიჯი Android-ის ფრაგმენტაციის პრობლემის გადასაჭრელად

Google წლებია მუშაობს Android-ის ფრაგმენტაციის შემცირებაზე, თუმცა ამის მიზეზი არის Android-ის თანდაყოლილი ბუნება და არჩევანის და თავისუფლების ორლესიანი ხმალი. არსებობს უამრავი OEM აქტიური სივრცეში და ყველა მათგანს სურს საკუთარი მოდიფიკაციების გაკეთება საკუთარი მოწყობილობებისთვის. პრობლემა ის არის, რომ, როგორც ჩანს, Android OS-ის განახლებები ნელა ვრცელდება მთელს დაფაზე, მაგრამ Google-ს ნამდვილად არ შეუძლია გააკეთოს ბევრი რამ, რათა აიძულოს OEM-ები განაახლონ მოწყობილობები. როგორც ასეთი, შემდეგი საუკეთესო რამ, რისი გაკეთებაც Google-ს შეუძლია, არის განახლების პროცესი რაც შეიძლება მარტივი და ხახუნის გარეშე.

ანდროიდის განახლების ტკივილის შემსუბუქება

პირველი მნიშვნელოვანი ინიციატივა Google-ის გრძელვადიან პროექტში განვითარების ტვირთის შესამცირებლად იყო პროექტი Treble. გამოცხადდა Android 8.0 Oreo-სთან ერთად 2017 წელს, Project Treble-მ მოახდინა Android-ის მოდულირება OS-ის ჩარჩოს გამყიდველის იმპლემენტაციისგან (HALs და მოწყობილობისთვის სპეციფიკური Linux kernel fork) გამოყოფით. ამან გაუადვილა Android OEM-ებს თავიანთი OS-ების გადატვირთვა უახლესი AOSP ჩარჩოს თავზე, რადგან მათ შეეძლოთ უახლესი ვერსიის ჩატვირთვა გამყიდველებისგან განახლებული კოდის საჭიროების გარეშე. შედეგად, OEM-ებს შეეძლოთ უფრო სწრაფად მოამზადონ თავიანთი Android ჩანგლები, ვიდრე ადრე, და გაფართოებით, უფრო სწრაფად გაავრცელონ ძირითადი OS განახლებები.

Google-ის გეგმების შემდეგი ნაბიჯი იყო Android-ის ძირითადი კომპონენტებისთვის განახლებების მიწოდების გამარტივება. ამ ინიციატივას Google-მა უწოდა პროექტის მთავარი ხაზი როდესაც მან გააცნო ის Android 10-თან ერთად 2019 წელს. Google-მა არსებითად აიღო კონტროლი OS-ის ძირითად კომპონენტებზე და აუკრძალა OEM-ებს მათი შეცვლა. შემდეგ მათ შექმნეს მიწოდების მექანიზმი Google Play-ს მეშვეობით, რათა მათ შეეძლოთ დისტანციურად გაავრცელონ განახლებები ამ ძირითადი კომპონენტებისთვის ისე, რომ დაელოდონ OEM-ებს, რომ თავად გამოიყენონ პატჩები. Mainline მნიშვნელოვნად გააუმჯობესა, რამდენად სწრაფად იღებენ მოწყობილობები OS- ის მნიშვნელოვანი კომპონენტების განახლებულ ვერსიებს, რაც თავის მხრივ აუმჯობესებს მთლიანად Android ეკოსისტემის უსაფრთხოებას.

თუმცა, რაც შეეხება Treble-ს, Linux-ის ბირთვი რეალისტურად არ უნდა იყოს შერწყმული დახურული წყაროს გამყიდველის კოდით. ტოდ კიოსთან წლევანდელი Linux Plumbers კონფერენცია წარსულში განმარტა სირთულეები, რომლებიც აწყდება Android-ის ფრაგმენტაციას, და ახლა ბევრი მათგანი ასახავს Linux-ის ბირთვს, რომელსაც OEM-ები აგზავნიან თავიანთ მოწყობილობებთან ერთად. კონტექსტში, Google ანაწილებს Linux-ის თითოეულ ბირთვს "Android საერთო ბირთვი” (ACK) ფილიალი, რომელიც ყურადღებით ადევნებს თვალს მთავარ გამოშვებას, მაგრამ ამატებს Android-ის სპეციფიკურ პატჩებს. SoC გამყიდველები, როგორიცაა Qualcomm, MediaTek და Samsung, შემდეგ ჩანგალი რომ ბირთვი თითოეული SoC-სთვის, რომელსაც ისინი ქმნიან. შემდეგ OEM-ები იღებენ ამ SoC-ს სპეციფიკურ ბირთვს და ამატებენ დამატებით პატჩებს, რათა განახორციელონ მხარდაჭერა კონკრეტული ტექნიკისთვის, რომლის გაგზავნაც სურთ.

ზემოაღნიშნული დიაგრამა გვიჩვენებს, თუ როგორ გადის მოწყობილობის ბირთვი ცვლილებების რამდენიმე ფენას, რაც მას აბსტრაქტებს Linux LTS ბირთვისგან შორს. მის გასამარტივებლად, ჩვენ ვიწყებთ Linux Kernel-ით და ის რამდენიმე ცვლილებით გაერთიანდება Android Common Kernel-ში. იქიდან, Android Common Kernel გაერთიანდება გამყიდველის ბირთვში (Qualcomm, MediaTek და ა.შ.) თავისი მოდიფიკაციებითა და ცვლილებებით. საბოლოოდ, გამყიდველის ბირთვი გაერთიანდება OEM-ის მოწყობილობის სპეციფიკურ ბირთვში. ამ ეტაპზე, ნებისმიერი მოწყობილობის ბირთვი შორს არის Linux LTS ბირთვისგან, რომლითაც იგი დაიწყო.

ყველა ამ ჩანგლის შედეგად, Android მოწყობილობაზე გაშვებული კოდის დაახლოებით 50% არის ხის გარეთ არსებული კოდი, რაც ნიშნავს, რომ ის არ არის Linux-ის ან AOSP საერთო ბირთვიდან. ეს წარმოუდგენლად ართულებს (რომ აღარაფერი ვთქვათ შრომატევადი და ძვირადღირებული) ცვლილებების შერწყმა. OEM-ებისთვის არ არსებობს ამის სტიმული, მაგრამ ეს პრაქტიკა შეიძლება საზიანო იყოს მოწყობილობის უსაფრთხოებისთვის. ეს არის ისიც, რომ ბევრი Android მოწყობილობა დარჩა LTS ბირთვის ძველ გამოშვებებზე, რაც იწვევს გვერდითი ეფექტს, როდესაც მოწყობილობები კარგავენ წვდომას Linux-ის ბირთვის ახალ ფუნქციებზე.

Android ფრაგმენტირებულია და Google-მა ეს იცის

Google-მა კარგად იცის, რომ ეს პრობლემაა და აქვს სექცია სახელწოდებით "ფრაგმენტაციის ხარჯებიAndroid-ის დეველოპერის დოკუმენტაციაში. ამას გუგლი ამბობს "ფლაგმანური მოწყობილობების უმეტესობა იგზავნება ბირთვის ვერსიით, რომელიც უკვე მინიმუმ 18 თვისაა". კიდევ უარესი, Google ასევე ამბობს ამას "Android 10 მხარს უჭერს 3.18, 4.4, 4.9, 4.14 და 4.19 ბირთვებს, რომლებიც ზოგიერთ შემთხვევაში არ გაუმჯობესებულა ახალი ფუნქციებით 2017 წლის Android 8-ის შემდეგ." ეს ართულებს ფუნქციების დამატებას, რომლებიც საჭიროებენ Linux-ის ბირთვის ახალ ვერსიებს. Linux kernel 3.18 ამოქმედდა 2014 წლის დეკემბერში, როდესაც Android 5.0 Lollipop იყო Android-ის უახლესი ვერსია. ეს აშკარად პრობლემაა და შეუძლია პლატფორმის შეკავება.

მაგალითად, Code Aurora Forum, ან მოკლედ CAF, მასპინძლობს წყაროს კოდს სხვადასხვა Qualcomm Snapdragon SoC-ისთვის. Qualcomm, როგორც SoC გამყიდველი, ავრცელებს Linux-ის ბირთვის გაფუჭებულ ვერსიას OEM/ODM-ებზე და შემდეგ ეს კომპანიები ამატებენ მოწყობილობის სპეციფიკურ ცვლილებებს ტრანსპორტირებისას. მოწყობილობები. ეს არის ის, რაც ამატებს ფრაგმენტაციის რამდენიმე ფენას. გარდა ამისა, Qualcomm შეაქვს ცვლილებებს AOSP ჩარჩოში Android-ის ოპტიმიზაციისთვის კომპანიის Snapdragon-ის თითოეული მობილური პლატფორმისთვის. Qualcomm პირადად ავრცელებს თავის შეცვლილ Linux ბირთვს, AOSP ჩარჩოს და სხვა პროგრამულ ინსტრუმენტებს პარტნიორებს, როგორც Board Support Package, ან BSP. CAF არის ადგილი, სადაც Qualcomm საჯაროდ აქვეყნებს Linux-ის ბირთვის ცვლილებებს და AOSP ჩარჩოს ცვლილებებს.

CAF-ის ეს გამოშვება შეიძლება სასარგებლო იყოს Custom ROM-ის დეველოპერებისთვის, რომელთაც სურთ გამოიყენონ ის, როგორც საწყისი წერტილი და არა სუფთა AOSP, რის გამოც ზოგჯერ ხედავთ "CAF-ზე დაფუძნებული" ROM ჩვენს ფორუმებზე. გახსოვთ Snapdragon 625, რომელიც წლების განმავლობაში ითვლებოდა ამდენი საშუალო დონის სმარტფონის ძალაში? ის დაიწყო Linux Kernel 3.18-ით და მხოლოდ 2018 წლის ბოლოს (ჩიპსეტის გამოშვებიდან ორი წლის შემდეგ) Qualcomm-მა განაახლა ბირთვის წყაროები და გამოაქვეყნა ისინი CAF msm8953-ისთვის (Snapdragon 625-ის ჩიპსეტის სახელი), რომელიც უზრუნველყოფს Linux Kernel 4.9-ის მხარდაჭერას. პრობლემა ის არის, რომ OEM-ების უმეტესობა არ განაახლებს ტელეფონებს Linux-ის ბირთვის ამ ახალ ვერსიაზე, განსაკუთრებით არა საშუალო დონის ტელეფონებს ჩიპის გამოშვებიდან ორი წლის შემდეგ გაათავისუფლეს. მართალია, ძალიან იშვიათია ბირთვის მსგავსი განახლება, პირველ რიგში, მაგრამ საქმე იმაშია, რომ აქვს მოხდა, ასე რომ ეს არ არის უბრალოდ შეუძლებელი სცენარი.

მთლიანობაში, ანდროიდის ამჟამინდელი ფრაგმენტაცია არეულობაა, მსუბუქად რომ ვთქვათ. ამ ფრაგმენტაციის გამოსწორების Google-ის უახლესი მცდელობები მოდის Generic Kernel Image-ის ან GKI-ს სახით.

წარმოგიდგენთ Generic Kernel Image-ს

ამ ფრაგმენტაციის გადასაჭრელად Google-მა იმუშავა Android Generic Kernel Image-ზე (GKI). ეს არსებითად არის ბირთვი, რომელიც შედგენილია პირდაპირ ACK ფილიალიდან. GKI იზოლირებს SoC გამყიდველისა და OEM პერსონალიზაციას დანამატების მოდულებზე, რაც გამორიცხავს ხის კოდს და საშუალებას აძლევს Google-ს ბირთვის განახლებები პირდაპირ საბოლოო მომხმარებელს მიაწოდოს. ერთ წელზე მეტი ხნის განმავლობაში, Google მუშაობს GKI განახლებების მიწოდების გზაზე Play Store-ის მეშვეობით, Mainline მოდულის გამოყენებით.

შედეგად, მოწყობილობებმა, რომლებიც გაშვებულია Android 12-ით, რომლებიც ამუშავებენ Linux kernel 5.10.43 ან უფრო მაღალ ვერსიას, უნდა გააკეთონ ერთ-ერთი შემდეგი: მიშაალ რაჰმანის მიხედვით.

• განათავსეთ Google-ის ხელმოწერილი ჩატვირთვის სურათი

ან

• განათავსეთ ჩატვირთვის სურათი ბირთვით, რომელიც ახორციელებს KMI-ს (კერნელი მოდულის ინტერფეისის) ექსპორტს, რომელიც წარმოადგენს GKI-ს მიერ ექსპორტირებული KMI-ს ქვეჯგუფს, ახორციელებს მომხმარებლის სივრცის API-ს ექსპორტს, რომელიც წარმოადგენს GKI-ს მიერ გამოვლენილ UAPI-ს სუპერკომპანიას და მხარს უჭერს შესაბამისი GKI-ს ყველა მახასიათებელს. ვერსია

გამყიდველებს შეუძლიათ შექმნან მოდულები, რომლებიც ჩაერთვებიან GKI-ში, მაგრამ GKI-ს იდეა ისაა, რომ Google იღებს პასუხისმგებლობის ტვირთს ბირთვის ცვლილებების დამუშავებაზე. ბირთვის მოდულის ინტერფეისი (ან KMI, ამის შესახებ მეტი სტატიის შემდეგ ნაწილებში) ეფექტურად არის ის ადგილი, სადაც მოსალოდნელია ხის გარეთ არსებული კოდი.

Google Pixel 6-ის სერიები გამოშვებულია Android 12-ით და ხელმისაწვდომია Linux kernel 5.10-ით და ეს არის პირველი ტელეფონი, რომელიც გამოდის GKI-ით. იმის გამო, რომ Google-ს შეუძლია ბირთვის განახლება Play Store-ის მეშვეობით, ჩვენ შეიძლება ვიხილოთ ბირთვის ხშირი განახლებები, რადგან LTS ბირთვის განახლებები ჩვეულებრივ გამოდის ყოველკვირეულად. ნებისმიერ შემთხვევაში, ეს ბევრად უკეთესი სისტემაა, ვიდრე OTA-ს საშუალებით განახლების ამჟამად უხერხული მეთოდი, თუმცა ეს ნიშნავს, რომ ის არსებითად არის მიბმული GMS ჩარჩოსთან.

Google უბრალოდ განსაზღვრავს GKI-ს, როგორც შემდეგს:

• ის აგებულია ACK წყაროებიდან.
• ეს არის ერთ ბირთვიანი ორობითი პლუს ასოცირებული ჩატვირთვის მოდულები თითო არქიტექტურაზე, LTS გამოშვებაზე (ამჟამად მხოლოდ arm64 android11-5.4 და android12-5.4).
• ის დატესტილია ყველა Android პლატფორმის გამოშვებით, რომლებიც მხარდაჭერილია ასოცირებული ACK-ისთვის. არ არსებობს ფუნქციის გაუქმება GKI ბირთვის ვერსიის სიცოცხლის განმავლობაში
• ის ავლენს სტაბილურ KMI-ს მძღოლებს მოცემულ LTS-ში.
• ის არ შეიცავს SoC-ს ან დაფის სპეციფიკურ კოდს.

Google-ს კი სურს 2023 წლისთვის იყოს ისეთ პოზიციაზე, სადაც მას შეუძლია აიღოს "პირველი დინების" განვითარების მოდელი. ეს დაეხმარება Google-ს, უზრუნველყოს ახალი კოდის პირველი ადგილი Linux-ის მთავარ ბირთვში, რაც შეამცირებს „ტექნიკურ დავალიანებას“ დარიცხულ კოდს Android მოწყობილობებზე.

ბირთვის მოდულის ინტერფეისი (KMI)

ბირთვის მოდულის ინტერფეისი, ან KMI, არის Google-ის გადაწყვეტის ნაწილი Android-ში მიმდინარე ფრაგმენტაციისთვის. არსებითად, SoC და დაფის მხარდაჭერა აღარ არის განლაგებული ბირთვის ბირთვში და სანაცვლოდ გადატანილია ჩასატვირთ მოდულებში. როგორც ბირთვი, ასევე მოდულები შეიძლება დამოუკიდებლად განახლდეს, რადგან მოდულები განახლდება /lib/modules. თავად GKI უნდა იყოს რაც შეიძლება სუფთა და ზოგადი, რაც შესაძლებელი ხდება ცალკეულ მოდულებში არსებული კოდის გადმოტვირთვით.

როგორც ტედ კიოსი განმარტა წლევანდელი Linux Plumbers კონფერენცია, "დიდი მრავალწლიანი ბიძგი არის ყველა აპარატურის სპეციფიკური კოდის ამოღება ზოგადი ბირთვიდან და გამყიდველის მოდულებში. ჩვენ უნდა გვქონდეს სტაბილური ინტერფეისი ამ გამყიდველ მოდულებსა და ზოგად ბირთვს შორის, რათა მათ შეძლონ ასინქრონულად გაგზავნა." GKI 1.0 არსებითად არის "შესაბამისობის ტესტი".

სინამდვილეში, GKI თავსებადობა ნიშნავს, რომ მოწყობილობა გადის VTS და CTS-on-GSI+GKI ტესტებს ზოგადი სისტემის სურათით (GSI) და GKI ბირთვი დაინსტალირებულია GKI ჩატვირთვის სურათის ჩატვირთვის დანაყოფში და GSI სისტემის გამოსახულების ციმციმებით სისტემაში დანაყოფი. Vendor Test Suite, ან VTS, არის ავტომატური ტესტი, რომელიც უნდა გაიაროს ყველა მოწყობილობამ, რომ ჩაითვალოს Project Treble-თან თავსებადად. თავსებადობის ტესტის კომპლექტი, ან CTS, საჭიროა Google-ის აპლიკაციების პაკეტზე წვდომისთვის.

მოწყობილობებს შეუძლიათ სხვადასხვა პროდუქტის ბირთვით გაგზავნა და შეუძლიათ გამოიყენონ ჩასატვირთი მოდულები, რომლებსაც GKI არ უზრუნველყოფს. თუმცა, როგორც პროდუქტი, ასევე GKI ბირთვი უნდა იტვირთოს მოდულები იმავე vendor_boot და გამყიდველის ტიხრებიდან. ამიტომ, ყველა პროდუქტის ბირთვს უნდა ჰქონდეს იგივე ორობითი ბირთვის მოდულის ინტერფეისი (KMI).

ზემოთ მოყვანილი დიაგრამა გვიჩვენებს რა Google სურს გააკეთოს და განმარტავს, თუ როგორ აპირებს ამის მიღწევას. Generic Kernel და GKI მოდულები იქნება AOSP-ის ნაწილი და GKI-ს შეუძლია დაუკავშირდეს Android ჩარჩოსა და Hardware Abstraction Layer-თან (HAL), რომელიც შეიძლება დანერგოს გამყიდველმა. სპეციფიური საკუთრების კოდი, რომელიც გამყიდველს სურს ბირთვში (მაგალითად, კამერის დრაივერები) სანაცვლოდ გადაიყვანება გამყიდველის მოდულში, რომელიც ხდება GKI-ს გაფართოება KMI-ის მეშვეობით.

როგორ შეუძლია GKI-ს დაეხმაროს Android-ის ფრაგმენტაციის პრობლემის მოგვარებაში

Google ბევრს შრომობს სმარტფონების განვითარების პროცესის გამარტივებაში. ყველა OEM-ს სურს საკუთარი ბრენდის იდენტურობა და ყველა OEM-ს სურს ჰქონდეს საკუთრება მის მოწყობილობებზე. Android One პროგრამისგან განსხვავებით, Android სმარტფონები შეიძლება იყოს თითქმის ის, რაც მათ სურთ, თუ ისინი იცავენ იმ წესების კომპლექტს, რომელსაც Google ადგენს GMS ლიცენზიის მისაღებად. თუმცა, წარსულში Google-ს ბევრი რამ არ გაუკეთებია Android-ის მოწყობილობების განვითარებაში მეფობისთვის ცვლილებები, როგორიცაა Project Treble, Mainline და ახლა GKI ბევრად უფრო ახალია Android-ში ისტორია.

მაგრამ დაეხმარება? ასეც უნდა მოხდეს, თუმცა, სავარაუდოდ, ეს იქნება მრავალწლიანი საქმე, რომელიც მოგვიანებით ხილულ ნაყოფს გამოიღებს. ეს ეხება მხოლოდ Android 12-ით გაშვებულ მოწყობილობებს, რაც იმას ნიშნავს, რომ ჩვენ ვიხილავთ მოწყობილობებს, რომლებსაც არ აქვთ GKI წლების განმავლობაში. ეს ასევე იყო Project Treble-ის კრიტიკა, როდესაც ეს გამოცხადდა, თუმცა აშკარაა, რომ დღეს გამოშვებული ყველა მოწყობილობა მხარს უჭერს მას. ამ საკითხებს დრო სჭირდება და რადგან Google ნელ-ნელა ანდროიდის მმართველობას იწყებს, განვითარების პროცესი შემსუბუქებულია ყველა OEM-ისთვის. ანდროიდის ეკოსისტემა, მაშინაც კი, თუ ზოგიერთ მათგანს ურჩევნია სრული კონტროლი შეინარჩუნოს Linux-ის ბირთვზე, რომელიც გამოიყენება Android-ზე სმარტფონები.