ყველაფერი რაც თქვენ უნდა იცოდეთ Android-ის Project Mainline-ის შესახებ

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

რა არის Project Mainline?

Project Mainline-ის სწორად გასაგებად, ცოტა გადახვევა მოგვიწევს. თუ რამდენიმე წლით უკან დაბრუნდებით, Android-ის განახლებების შესახებ ბევრი საუბარი ფრაგმენტაციის პრობლემაზე იყო ორიენტირებული. ფრაგმენტაცია იყო ერთ-ერთი ყველაზე დიდი გამოწვევა Google-ისთვის, რომელიც უნდა გადაჭრას Android-ზე Ice Cream Sandwich - Lollipop-ის ეპოქაში. მიუხედავად იმისა, რომ Android-ი, როგორც პლატფორმა იღებდა რეგულარულ განახლებებს დიდწილად პროგნოზირებადი ნიმუშით, ამ განახლებებს ძალიან დიდი დრო სჭირდებოდა საბოლოო მომხმარებლების ხელში მისვლას, თუ საერთოდ. ასე რომ, სანამ Google აფიქსირებდა კრიტიკულ შეცდომებს და უსაფრთხოების საკითხებს პლატფორმის დონეზე, ამ ცვლილებების ფაქტობრივი გავრცელება სასურველს ტოვებდა. იყო/არის ბევრი შუამავალი (SoC გამყიდველი, OEM, მატარებლები და ა.შ.) და ბევრი მოძრავი ნაწილი მონაწილეობდა განახლებების მიწოდებაში თქვენს ტელეფონს და ფრაგმენტაციის პრობლემა არ ჩანდა ისე, რომ ის თავისთავად მოგვარდება რაიმე ხისტი დარტყმის საჭიროების გარეშე ინტერვენციები.

ამ პრობლემის გადასაჭრელად ერთ-ერთი მთავარი მცდელობა იყო პროექტი Treble Android 8.0 Oreo-სთან ერთად, რომელიც მოიცავდა Android-ის ძირითად ხელახალი არქიტექტურას, ანდროიდის OS-ის ჩარჩოს კომპონენტების გამიჯვნას გამყიდველის HAL-ებისგან და Linux-ის ბირთვისგან. Project Treble-მა, არსებითად, მოახდინა Android-ის მოდულარიზაცია OS-ის ჩარჩოს გამოყოფით მოწყობილობის სპეციფიკური, ქვედა დონის პროგრამული უზრუნველყოფისგან. ამ გზით, მოწყობილობების შემქმნელებს (OEMs) არ სჭირდებათ ლოდინი სილიკონის მწარმოებლების (SoC გამყიდველი) განახლებას მათი გამყიდველის განხორციელების კოდით, და OEM-ებს შეუძლიათ დამოუკიდებლად განაახლონ Android OS ჩარჩო. საბოლოო შედეგი არის OEM-ის ახალი Android გამოშვებების უფრო სწრაფი მიღება, რადგან მათ ეს აღარ სჭირდებათ დაელოდეთ შუამავალს (SoC გამყიდველი) ჯერ დაასრულებს თავის საქმეს, სანამ ისინი დაიწყებენ მუშაობას მათი.

მიუხედავად იმისა, რომ Android-ის განახლების ვითარება მკვეთრად არ გაუმჯობესდა Project Treble-ით, მან დიდწილად გაააქტიურა უფრო ფართო OEM. Android 10-ისა და Android 11-ის ბეტა ვერსიაში მონაწილეობა, ასევე OEM-ებისთვის უფრო ადვილია მათი მოწყობილობების უფრო სწრაფად განახლება ვადები. გარდა ამისა, GSI-ის (ზოგადი სისტემის გამოსახულების) მთლიანმა კონცეფციამ მნიშვნელოვანი გავლენა მოახდინა ჩვენს ფორუმებზე შემდგომი ბაზრის განვითარებაზე.

დეველოპერი ჩატვირთავს Android 11-ს 22 ძველ მოწყობილობაზე Project Treble GSI-ით

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

Project Mainline-ისთვის Google იყენებს Mainline მოდულებს, რომლებიც მიწოდებულია Google Play Services Framework-ისა და Google Play Store-ის მეშვეობით. თითოეული Mainline მოდული მიწოდებულია როგორც APK ფაილი, APEX ფაილი, ან როგორც APK-in-APEX. როდესაც Mainline მოდულის განახლება ხდება, მომხმარებელი ხედავს "Google Play სისტემის განახლება" (GPSU) შეტყობინებას თავის მოწყობილობაზე. ფაქტობრივად, კრიტიკულ კომპონენტებზე განახლებების მიწოდებისთვის, Google-მა გვერდი აუარა OEM-ის მიერ განახლების გამოქვეყნებას დალოდების აუცილებლობას და თავად აირჩია დავალების შესრულება.

როგორც Google-ი აცხადებს Android-ის ვებსაიტზე:

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

Android 10 ან უფრო ახალი ვერსია გარდაქმნის სისტემის არჩეულ კომპონენტებს მოდულებად, რომელთაგან ზოგი იყენებს APEX კონტეინერის ფორმატს (დანერგილია Android 10-ში) და ზოგი იყენებს APK ფორმატს. მოდულური არქიტექტურა იძლევა სისტემის კომპონენტების განახლების საშუალებას კრიტიკული შეცდომების გამოსწორებით და სხვა საჭიროებისამებრ გაუმჯობესებები, ქვედა დონის გამყიდველის დანერგვაზე ან უფრო მაღალი დონის აპებზე გავლენის გარეშე და მომსახურება.

როგორც Ars Technica აღნიშნავს:

Project Mainline, AKA "Google Play სისტემის განახლებები", დაინერგა Android 10-ში, როგორც მთავარი მცდელობა Android-ის ძირითადი სისტემის კომპონენტების უფრო მოდულარული და განახლებადი. Mainline-მა წარმოადგინა ახალი "APEX" ფაილის ტიპი სპეციალურად სისტემის კომპონენტებისთვის, რომლის მიზანია Android-ის ძირითადი კოდის გაგზავნა Play Store-ის მეშვეობით ისევე მარტივად, როგორც თქვენ გაგზავნით აპლიკაციის განახლებას. ადრე, Android-ის ერთადერთი გადასატანი კოდის ბლოკი იყო APK, ფაილის ტიპი, რომელიც თავდაპირველად შეიქმნა მესამე მხარის აპებისთვის. მას მოჰყვა უსაფრთხოების ყველანაირი შეზღუდვა და მხოლოდ ჩატვირთვის პროცესის გვიან დაწყებას შეეძლო, ამიტომ APEX შეიქმნა უფრო ძლიერი სისტემის კომპონენტების გათვალისწინებით. APEX-ების შექმნა შესაძლებელია მხოლოდ Google-ის ან თქვენი მოწყობილობის მწარმოებლის მიერ, ასე რომ, ისინი შეიძლება იყოს შესამჩნევად უფრო ძლიერი და შეიცავდეს კრიტიკულ ჩატვირთვის კომპონენტებს, როგორიცაა აპლიკაციის გაშვების დრო.

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

Project Mainline — მოდულები

Android 10-ით Google-მა დაავალა 13 კონკრეტული Mainline მოდულის ჩართვა. Android 11-ით, სავალდებულო მოდულების საერთო რაოდენობაა 25. აქ არის სრული სია, რამდენიმე ძირითადი დეტალის გარდა:

ზემოთ მოცემულ სვეტებს გარკვეული კონტექსტის უზრუნველსაყოფად, სვეტი სახელწოდებით „მოწყობილობა განახლებულია ან გაშვებულია Android 11-ზე“ შეიცავს დეტალებს იმის შესახებ, უნდა იყოს თუ არა მოდული (ან არ უნდა იყოს) ამჟამად, დროის ზონის მონაცემების შემთხვევაში მისი ალტერნატივის ჩართვის გამო) ყველა მოწყობილობაზე, რომელიც ან განახლებულია Android 11-ზე, ან გამოდის Android 11-ით. ყუთი. ანალოგიურად, Android 10-ით გაშვებულ მოწყობილობებს მოეთხოვებათ შეიცავდეს რამდენიმე მოდული, მკაცრად რეკომენდირებულია შეიცავდეს რამდენიმე სხვას და არ არის მხარდაჭერილი დანარჩენის მიერ. მოწყობილობებისთვის, რომლებიც განახლებულია Android 10-ზე (განსხვავებით Android-ით გაშვებული), საჭირო მოდულების სია უფრო მოკლეა.

რას აკეთებს თითოეული მთავარი მოდული?

აქ არის მოკლე ახსნა თითოეული მთავარი მოდულისთვის:

Adbd

adbd მოდული მართავს ბრძანების ხაზის adb და IDE გამართვის სესიებს. adbd-ის მოდულირება საშუალებას აძლევს Google-ს, უფრო სწრაფად მოახდინოს მუშაობის გაუმჯობესება და შეცდომების გამოსწორება. ეს გადამწყვეტია, რადგან წარსულში ზოგიერთი ხარვეზი დაკავშირებული იყო ბატარეის ამოწურვასთან და შეიძლება გამოიწვიოს მოწყობილობების 100% CPU-ის გამოყენება, სანამ ტელეფონი არ მოკვდება. ამრიგად, ამ შესწორებების მიღება გადამწყვეტია Google-ისთვის, რადგან adb ფართოდ გამოიყენება აპლიკაციების შემქმნელებისა და OEM-ების მიერ ტესტირებისთვის.

Android Neural Networks API Runtime

ეს არის ბიბლიოთეკა, რომელიც განთავსებულია აპსა და backend-ის დრაივერებს შორის. API თავის მხრივ არის Android C API მობილური მოწყობილობებზე გამოთვლითი ინტენსიური მანქანური სწავლების ოპერაციების გასაშვებად და აპარატურის დაჩქარებული დასკვნის ოპერაციების გასააქტიურებლად.

CellBroadcast

Cell Broadcast ეხება საგანგებო და არასასწრაფო გაფრთხილებებს (როგორიცაა AMBER გაფრთხილებები). ეს მოდული ეხება ამოცანებს ამ სიგნალების ირგვლივ და სხვა დამხმარე ფუნქციებთან, როგორიცაა SMS დეკოდირება და geofencing უკაბელო გადაუდებელი სიგნალიზაციისთვის.

კონსკრიპტირება

Conscrypt მოდული ამუშავებს Android-ის TLS იმპლემენტაციას და სხვა კრიპტოგრაფიულ ფუნქციებს, როგორიცაა გასაღების გენერატორები, ციპერები და შეტყობინებების დაჯესტები. ამ მოდულის მიწოდება Google-ს საშუალებას აძლევს დააჩქაროს უსაფრთხოების გაუმჯობესება, OTA განახლებების დაყრის საჭიროების გარეშე.

DNS Resolver

როგორც სახელი გულისხმობს, DNS გადამწყვეტი წყვეტს DNS-ს, ანუ გარდაქმნის ადამიანის მიერ წაკითხულ URL-ებს IP მისამართებად. მოდული შეიცავს კოდს, რომელიც ახორციელებს DNS stub გადამწყვეტს და მისი მოდულის სახით მიწოდება საშუალებას აძლევს Google-ს უზრუნველყოს მომხმარებლის უკეთესი დაცვა DNS-ის ჩარევისა და კონფიგურაციის განახლების შეტევებისგან.

დოკუმენტების UI

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

გარე სერვისები

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

IPsec/IKEv2 ბიბლიოთეკა

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

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

ამ მოდულის ფუნქცია მაშინვე აშკარაა მისი სახელიდან, თუმცა მისი დანიშნულება ასე არ არის. მოდულის მეტამონაცემების მოდული შეიცავს...მეტამონაცემებს მოწყობილობის მოდულების სიის შესახებ. და ეს დაახლოებით.

ქსელის სტეკის კომპონენტები, ქსელის სტეკის ნებართვის კონფიგურაცია, ტყვე პორტალზე შესვლა

Network Stack Components მოდული უზრუნველყოფს საერთო IP სერვისებს, ქსელთან დაკავშირების მონიტორინგს, ტყვეში შესვლის პორტალის გამოვლენას. ნებართვის კონფიგურაციის მოდული განსაზღვრავს ნებართვას, რომელიც საშუალებას აძლევს სხვა მოდულებს შეასრულონ ქსელთან დაკავშირებული ამოცანები. Captive Portal Login მოდული ეხება დატყვევებულ პორტალებს - ვებ გვერდებს, რომლებიც ნაჩვენებია როდის დაკავშირებულია გარკვეულ საჯარო Wi-Fi ქსელებთან, სადაც მომხმარებელს სთხოვენ დეტალების შეყვანას ინტერნეტის მოსაპოვებლად წვდომა.

ნებართვის კონტროლერი

ეს მოდული აწვდის განახლებულ კონფიდენციალურობის პოლიტიკას და UI ელემენტებს ნებართვების მინიჭებისა და მართვის გარშემო. თუ ეს ნაცნობად ჟღერს Package Installer-ისთვის, ეს იმიტომ ხდება. ფუნქციები, როგორიცაა გაშვების ნებართვების მინიჭება, მართვა და გამოყენების თვალყურის დევნება, იყო Package Installer აპის ნაწილი Android 9-მდე. Android 10-ში, Package Installer აპი დაყოფილია სექციებად, რათა მოხდეს ნებართვების ლოგიკის განახლება. ნებართვის კონტროლერის მოდული მიწოდებულია APK ფაილის სახით და Android 11-ში მოდულს შეუძლია ავტომატურად გააუქმოს გაშვების დროის ნებართვები აპებისთვის, რომლებიც არ იყო გამოყენებული დიდი ხნის განმავლობაში.

SDK გაფართოებები

ეს მოდული ცოტა რთული გასაგები და შესაბამისად ახსნაა. Android-ის ყველა გამოშვებას ენიჭება SDK დონე (როგორც წესი, +1 მისი წინამორბედისგან). როდესაც აპლიკაცია მიზნად ისახავს კონკრეტულ SDK-ს, ვარაუდობენ, რომ დეველოპერმა გაითვალისწინა პლატფორმის ქცევითი და API ცვლილებები, რომლებიც მოჰყვა Android-ის გამოშვებას.

SDK Extensions მოდული წყვეტს მოწყობილობის "გაფართოების SDK" დონეს და ასახავს API-ებს აპებისთვის, რათა მოითხოვონ გაფართოების SDK დონე. ეს არის ის, რაც ოფიციალურ დოკუმენტაციაშია ნახსენები. ArsTechnica, თუმცა აღნიშნავს რომ ეს, სავარაუდოდ, მეორადი API ფენაა, რომელიც გაიგზავნება Play Store-ის მეშვეობით.

Statsd, ტელემეტრიის მატარებლის ვერსიის პაკეტი

Statsd პასუხისმგებელია მოწყობილობის მეტრიკის შეგროვებაზე. მეორეს მხრივ, Telemetry Train Version Package არ შეიცავს აქტიურ კოდს ან რაიმე საკუთარ ფუნქციას. ის უბრალოდ შეიცავს "Telemetry Train"-ის ვერსიის ნომერს, რომელიც Google-ის თქმით, არის მეტრიკასთან დაკავშირებული მოდულების ნაკრები. ვერსიის ნომრიდან გამომდინარე, Google Play აჩვენებს უსაფრთხოების პაჩის ვერსიას საბოლოო მომხმარებლებისთვის და ადგენს, ხელმისაწვდომია თუ არა განახლებები მეტრიკასთან დაკავშირებული მოდულებისთვის.

ტეტერინგი

Tethering მოდული აზიარებს მოწყობილობის ინტერნეტ კავშირს სხვა დაკავშირებულ კლიენტ მოწყობილობებთან Wi-Fi, USB, Bluetooth ან Ethernet-ის საშუალებით. მოდული მოიცავს ტეტერინგის კომპონენტებს და მათ დამოკიდებულებებს. ამ Tethering მოდულის გამოყენებით, OEM-ებს შეუძლიათ დაეყრდნონ ერთ, სტანდარტული მითითების განხორციელებას და უზრუნველყონ თანმიმდევრული გამოცდილება მოწყობილობებში.

დროის ზონის მონაცემები

დროის ზონის მონაცემების მოდული აახლებს დღის სინათლის დროს (DST) და დროის ზონებს Android მოწყობილობებზე, სტანდარტიზებს ორივე მონაცემს (რასაც შეუძლია და საკმაოდ ხშირად იცვლება რელიგიური, პოლიტიკური და გეოპოლიტიკური მიზეზების გამო) და ეკოსისტემის განახლების მექანიზმი. Android 8.1 და Android 9 იყენებდნენ APK-ზე დაფუძნებულ დროის ზონის მონაცემთა განახლების მექანიზმს და Android 10 ცვლის მას APEX-ზე დაფუძნებული მოდულის განახლების მექანიზმით. Google აცხადებს, რომ AOSP აგრძელებს პლატფორმის კოდის ჩართვას, რომელიც აუცილებელია APK-ზე დაფუძნებული განახლებისთვის Android 10-ზე განახლებულ მოწყობილობებს კვლავ შეუძლიათ პარტნიორის მიერ მოწოდებული დროის ზონის მონაცემების განახლებების მიღება APK. თუმცა, Google აფრთხილებს, რომ APK-ზე დაფუძნებული განახლებები ანაცვლებს APEX-ზე დაფუძნებულ განახლებას.

Ვაი - ფაი

ეს არის მოდული Wi-Fi ფუნქციონირებისთვის. საბოლოო მომხმარებლებს ახლა შეუძლიათ მიიღონ თანმიმდევრული Wi-Fi გამოცდილება Android მოწყობილობებში, ასევე თავსებადობის პრობლემების გამოსწორება მოდულის განახლებების, აპლიკაციის მეშვეობით დეველოპერებს შეუძლიათ მიიღონ პლატფორმის შემცირებული ფრაგმენტაცია, ხოლო OEM-ებს შეუძლიათ შეასრულონ ოპერატორის მოთხოვნები და ასევე შეამცირონ ხარჯები ინდივიდისთვის მორგება.

---

იმედია, ეს სტატია ხაზს უსვამს იმას, თუ რამდენად მნიშვნელოვანია Project Mainline Google-ის Android ეკოსისტემისთვის.