Google მუშაობს APEX-ზე: განაახლებს სისტემის ბიბლიოთეკებს, როგორც სტანდარტული Linux დისტრო. მოსალოდნელია Android Q-ში, APEX შეიძლება იყოს ყველაზე დიდი რამ Project Treble-ის შემდეგ.
APEX-ის განხორციელება ალბათ ყველაზე დიდი თავის ტკივილია, რომელსაც Google შეექმნა Project Treble-ის დანერგვის შემდეგ. რა არის APEX და როგორ შეცვლის Android-ს მისი დანერგვა?
APEX-ის იდეა თავისთავად საკმაოდ გავრცელებულია ყოველდღიურ GNU/Linux დისტრიბუციებში: პაკეტის განახლებები, რომლებიც მიზნად ისახავს Linux-ის ბიბლიოთეკის ნაკრების კონკრეტულ ნაწილებს. მაგრამ ეს არის ის, რასაც Google არასოდეს უცდია იმის გათვალისწინებით, რომ Android-მა გამოიყენა RO (მხოლოდ წაკითხვადი) დანაყოფი, სადაც ყველა სისტემის ბიბლიოთეკა და ჩარჩოები ინახება ჩვეულებრივი RW (წაკითხვა-ჩაწერა) ტიხრების წინააღმდეგ, რომლებიც გამოიყენება Linux-ის უმეტეს დისტრიბუციაში, რაც უზრუნველყოფს სტანდარტულ განახლების პროცესს. შეუფერებელი.
ბიბლიოთეკები არის წინასწარ კომპილირებული კოდი, რომელიც შეიძლება გამოყენებულ იქნას სხვა პროგრამებში. ხშირად გამოყენებული მეთოდები შეიძლება გადაკეთდეს ბიბლიოთეკებში Android აპებისთვის გამოსაძახებლად, APK-ების ზომის შემცირება, რადგან ერთი და იგივე კოდი არ საჭიროებს ხელახლა დანერგვას მრავალ აპში. თქვენ შეგიძლიათ იპოვოთ მრავალი წინასწარ დაინსტალირებული სისტემის ბიბლიოთეკა /system/lib და /system/lib64 დირექტორიაში. ანდროიდის სისტემის ბიბლიოთეკები, როგორც წესი, არ ახლდება ინდივიდუალურად — პირიქით, ისინი განახლდებიან როგორც Android პლატფორმების განახლების ნაწილი OTA განახლების მეშვეობით. მეორეს მხრივ, ბიბლიოთეკები Linux დისტრიბუციებში შეიძლება ინდივიდუალურად განახლდეს. APEX-ის დანერგვით, Android-ში სისტემური ბიბლიოთეკები შეიძლება ინდივიდუალურად განახლდეს, როგორც Android აპლიკაციები. ამის მთავარი სარგებელი ის არის, რომ აპლიკაციების შემქმნელებს შეეძლებათ ისარგებლონ განახლებული ბიბლიოთეკებით ისე, რომ არ დაელოდონ OEM-ს სისტემის სრული განახლების გამოქვეყნებას. მოდით ჩავუღრმავდეთ უფრო ტექნიკურ დეტალებს იმის შესახებ, თუ როგორ მუშაობს APEX.
როგორ შეცვლის APEX ბიბლიოთეკების განახლების გზას?
APEX არის ეკოსისტემა, რომელმაც აიძულა (უფრო სწორად, აიძულებს) Google-ს გადახედოს Android-ის ყველა ბიბლიოთეკასა და ფაილს /system-ისგან განსხვავებული არასტანდარტული დანაყოფიდან.
უპირველეს ყოვლისა, ჩვენ უნდა დავაზუსტოთ განსხვავება საერთო ბიბლიოთეკასა და სტატიკური ბიბლიოთეკას შორის. საზიარო ბიბლიოთეკა არის ბიბლიოთეკა (ჩვეულებრივ ფაილი სახელად libkind.so), რომელიც არ შეიცავს თავისთავად გასაშვებად საჭირო ყველა კოდს, მაგრამ რეალურად არის „მიბმული“ სხვა ბიბლიოთეკებთან. კოდის მიწოდება, მაშინ როდესაც სტატიკური ბიბლიოთეკა არის, როგორც თქვენ მიხვდით, ბიბლიოთეკა, რომელიც არ არის დამოკიდებული სხვა ბიბლიოთეკებზე და შეიცავს ყველაფერს სტატიკურად. ფაილი.
Android-მა ისტორიულად დააკონფიგურირა ბიბლიოთეკის გზა (ცნობილია როგორც LD_LIBRARY_PATH Linux-ის სამყაროში) ერთი ფაილით ე.წ. ბიბლიოთეკა. ეს ბილიკები მყარი კოდირებულია კონფიგურაციაში და არ არის გაფართოებადი. ეს განლაგება, მათ შორის მხოლოდ წაკითხვადი სისტემის დანაყოფი, იწვევს განუახლებელ ბიბლიოთეკებს, თუ მომხმარებელი არ დააინსტალირებს OTA Android განახლებას. Google-მა მოაგვარა ეს პრობლემა, რაც საშუალებას აძლევდა გააფართოვოს ძიების ბილიკი, ნება დართვა, რომ ცალკეული APEX პაკეტები უზრუნველყონ საკუთარი ld.config.txt, რომელიც მოიცავდა მათში შემავალ დამატებით (და განახლებულ) ბიბლიოთეკების ბილიკებს.
მიუხედავად იმისა, რომ ამ ნაბიჯმა დააფიქსირა ერთ-ერთი მთავარი პრობლემა, ჯერ კიდევ რამდენიმე სერიოზული პრობლემა იყო დასაძლევი. პირველ რიგში: ABI (აპლიკაციის ორობითი ინტერფეისი) სტაბილურობა. ბიბლიოთეკებმა ყოველთვის უნდა გამოიტანონ ინტერფეისების სტაბილური ნაკრები, რათა სხვა აპებმა და ბიბლიოთეკებმა განაგრძონ მუშაობა იმავე პროტოკოლით, თუნდაც განახლებულ ბიბლიოთეკაში. Google აქტიურად მუშაობს ამაზე, ცდილობს შექმნას სტაბილური C ინტერფეისი APEXed ბიბლიოთეკებს შორის.
მაგრამ APEX არ შემოიფარგლება მხოლოდ ბიბლიოთეკებითა და ბინარებით. სინამდვილეში, ის შეიძლება შეიცავდეს კონფიგურაციის ფაილებს, დროის ზონის განახლებებს და რამდენიმე Java ჩარჩოს (დაშიფვრა წერის დროს).
აქ მოცემულია AOSP-ის მიერ მოწოდებული მიმდინარე APEX პაკეტების რამდენიმე მაგალითი:
- com.android.runtime: ART და ბიონიკური გაშვების დრო (ბინარული და ბიბლიოთეკები)
- com.android.tzdata: TimeZone და ICU მონაცემები (ბიბლიოთეკები და კონფიგურაციის მონაცემები)
- com.android.resolv: ბიბლიოთეკა, რომელსაც იყენებს Android ქსელთან დაკავშირებული მოთხოვნების გადასაჭრელად (ბიბლიოთეკები)
- com.android.conscrypt: ჯავის უსაფრთხოების პროვაიდერი (Java Framework)
როგორ არის დაინსტალირებული და სტრუქტურირებული APEX პაკეტი?
APEX პაკეტი არის მარტივი zip არქივი (როგორც APK), რომელიც შეიძლება დაინსტალირდეს ჩვენი მოსახერხებელი ADB-ით (განვითარების ამ ეტაპზე) და მოგვიანებით, თავად მომხმარებლის მიერ პაკეტის მენეჯერის მეშვეობით (როგორიცაა Google Play ან ხელით Android პაკეტის მეშვეობით). ინსტალერი).
ZIP განლაგება შემდეგია:
მოდით ჩავუღრმავდეთ ამაში.
apex_manifest.json განსაზღვრავს პაკეტის სახელს და ვერსიას.
apex_payload.img არის მიკრო ფაილური სისტემის სურათი (ფორმატირებული როგორც EXT4).
სხვა ფაილები შემოწმების პროცესის ნაწილია, რომელიც გამოიყენება პაკეტის ინსტალაციისთვის. მოდით შევხედოთ.
ყოფნა AndroidManifest.xml, მაშინაც კი, თუ ის ძირითადად გამოიყენება აპლიკაციებში, გვეხმარება გავიგოთ, რომ სტანდარტული APK ინსტალაციისთვის გამოყენებული იმპლემენტაციის უმეტესი ნაწილი ხელახლა გამოიყენება ამ პაკეტებისთვისაც კი. სინამდვილეში, მხოლოდ გაფართოება შემოწმდება მათ შორის დიფერენცირების მიზნით.
The META-INF/ დირექტორიას აქვს პაკეტის სერთიფიკატი და იყენებს იგივე მექანიზმს, როგორც ჩვეულებრივ APK-ებს. ასე რომ, ეს პაკეტები დამოწმებულია პირადი/საჯარო გასაღების წყვილით მუშაობის დროს, სანამ მომხმარებელს მიეცემა განახლების ინსტალაციის უფლება. მაგრამ ეს არ იყო საკმარისი Google-ისთვის, ამიტომ მათ დაამატეს უსაფრთხოების კიდევ 2 ფენა. ისინი იყენებენ dm-verity-ს სურათის მთლიანობის შესამოწმებლად და AVB (Android Verified Boot) დადასტურებას, რათა დარწმუნდნენ, რომ სურათი სანდო წყაროდან მოდის. უარეს შემთხვევაში, APEX პაკეტი უარყოფილი იქნება.
თუ ყველა გადამოწმების ნაბიჯი წარმატებულია, სურათი მოინიშნება როგორც მოქმედი და ჩაანაცვლებს სისტემის ვარიანტს მომდევნო გადატვირთვისას.
როგორ არის დაინსტალირებული სურათი ჩატვირთვისას?
დავიწყოთ ჩემს მოწყობილობაზე ამჟამად დაინსტალირებული APEX-ების გადახედვით (ემულატორი)
როგორც ხედავთ, წინასწარ დაინსტალირებული პაკეტები ინახება /system/apex/-ში და ყველა მათგანი ამჟამად ნომერ 1 ვერსიაზეა. მაგრამ რა ხდება, როდესაც APEX გააქტიურებულია? ჩვენ კვლავ გამოვიყენებთ com.android.tzdata-ს, როგორც მაგალითად.
მოდით გადატვირთოთ მოწყობილობა და გავაანალიზოთ ლოგიკა.
პირველი 2 სტრიქონი იძლევა საკმარის ინფორმაციას პაკეტის წარმოშობის გასაგებად და სად იქნება ის დაინსტალირებული: /apex/, Android Q-ში დანერგილი ახალი დირექტორია, რომელიც გამოყენებული იქნება გააქტიურებულის შესანახად პაკეტები.
მას შემდეგ, რაც პაკეტი წარმატებით დადასტურდება AVB-ით და საჯარო გასაღები ემთხვევა, APEX დამონტაჟებულია მარყუჟის მოწყობილობის გამოყენებით /dev/block/loop0-ზე, რაც EXT4 ფაილურ სისტემას სისტემისთვის ხელმისაწვდომს ხდის. მარყუჟის მოწყობილობა არის ფსევდო მოწყობილობა, რომელიც ხდის ფაილს ხელმისაწვდომს, როგორც ბლოკის მოწყობილობას, რაც ამ ფაილის შიგთავსს წვდომას ხდის, როგორც სამონტაჟო წერტილი.
ამ ეტაპზე, APEX ჯერ კიდევ არ არის გამოყენებული @1 სუფიქსის გამო (ეს მიუთითებს პაკეტის ვერსიაზე). იმისათვის, რომ სისტემამ საბოლოოდ გააცნობიეროს, რომ ჩვენი პაკეტი წარმატებით გააქტიურდა, ის დამაგრდება /apex/com.android.tzdata-ზე, სადაც Android აქტიურად ელის tzdata-ს არსებობას. Bind mount გადაფარავს არსებულ დირექტორიას ან ფაილს სხვა წერტილში. [1]
APEX იმპლემენტაცია მთლიანად შეიცავს ერთ საცავში AOSP-ის ქვეშ. [2] apexd (APEX daemon) დირექტორიაში არის კოდი გაშვებული Android-ზე. apexer დირექტორიაში არის კოდი, რომელიც გამოიყენება build სისტემის მიერ APEX პაკეტების შესაქმნელად.
რა არის მიზანი?
ამ ეტაპზე მხოლოდ ვარაუდები შემიძლია გავაკეთო. ჩემი საუკეთესო ვარაუდით, Google ცდილობს შექმნას APEX პაკეტების ძირითადი ნაკრები, რომელიც შეიძლება განახლდეს Google-ის მიერ, რათა შექმნას Android-ის ერთიანი საბაზისო ბირთვი, რომელიც გაზიარებულია მომწოდებლებს შორის, რაც შესაძლებელს ხდის "სისტემის" განახლებებს, მაგრამ ერთი პაკეტის გამოყენებით განახლებები.
აპირებს თუ არა ყველა მოწყობილობას APEX-ის მხარდაჭერა?
არა. მაგალითად, apexd მოითხოვს, რომ /data/apex ხელმისაწვდომი იყოს ჩატვირთვისთანავე, რათა განახლდეს ყველა Android მოდული. FDE (სრული დისკის დაშიფვრით) /data/apex დაშიფრულია, სანამ მოწყობილობა არ განბლოკავს მომხმარებლის მიერ, რაც APEX-ს ძირითადად უსარგებლო ხდის, რადგან მხოლოდ სისტემის APEX ვარიანტები ჩაიტვირთება ჩატვირთვისას. გარდა ამისა, ყველა მოწყობილობას უნდა ჰქონდეს APEX-ის მხარდაჭერა, მაგრამ მათ სჭირდებათ რამდენიმე ბირთვის პატჩი (რომელთაგან ბევრი არის Google-ის მიერ ნაპოვნი აფიქსირებები მარყუჟის მოწყობილობებთან თამაშისას). [3] [4]
წყაროები [0], [1], [2], [3], [4]