წყაროს კოდის გარეშე, როგორ იღებენ დეველოპერები ტექნიკის კომპონენტებს, როგორიცაა კამერები, რომლებიც მუშაობენ საბაჟო ROM-ებში? პასუხი არის BLOB, შიმშილი და უამრავი გამართვა.
Android Oreo-ს და მრავალი მოწყობილობის გამოშვებით, როგორიცაა Xiaomi Redmi Note 3, Google Nexus 5 და სხვები არაოფიციალურად იღებენ მას, ალბათ სამართლიანია გაინტერესებთ, რატომ იშლება იგივე ფუნქციები (ძირითადად კამერა), როდესაც დეველოპერები პორტირებენ Android ღია კოდის პროექტზე (AOSP) დაფუძნებულ ROM-ზე. თქვენ ალბათ გინახავთ ROM-ების XDA ფორუმების თემები გატეხილი ფუნქციების გრძელი სიით ზემოთ. „რა მუშაობს“, რასაც მოჰყვება სამუშაო ფუნქციების სია, შემდეგ ქვემოთ არის ხატოვანი „რა არ მუშაობს? შენ მითხარი!” არის ორი პოპულარული რეფრენი ჩვენს ფორუმებზე, რომლებიც პრაქტიკულად მემად იქცა ისეთ ადგილებში, როგორიცაა Reddit და Twitter.
რატომ ირღვევა ამდენი ფუნქციონირება, როდესაც დეველოპერი ცდილობს AOSP ROM-ის პორტირებას საკუთარ მოწყობილობაზე? ძირითადი პასუხი არის ის, რომ იმის გამო, რომ ფუნქციები იცვლება Android-ის სხვადასხვა ვერსიებში, ძველი მოწყობილობის დრაივერები, რომლებიც შეფუთულია როგორც BLOBs, არ იმუშავებს Android-ის ახალ ვერსიებთან ან თუნდაც მხოლოდ საფონდო AOSP-თან. ამის დასაძლევად დეველოპერები იყენებენ იმას, რასაც „შიმ“ ჰქვია, მაგრამ ჩართული პროცესი რთულია, შრომატევადი და ზოგჯერ ძალიან რთულია გამართვა.
ამ სტატიაში ჩვენ გამოვყოფთ, თუ როგორ მუშაობს shims, განსაკუთრებით AOSP-ზე დაფუძნებულ ROM-ებზე კამერის გამართულად მუშაობისთვის. ჩვენ გამოვიყენებთ OnePlus 3T-ს, როგორც მაგალითად. გაითვალისწინეთ, რომ ამ ფუნქციების ფუნქციონირებასთან დაკავშირებული სირთულე უაღრესად სპეციფიკურია მოწყობილობისთვის.
OnePlus 3T გაშვებული OxygenOS. მიუხედავად იმისა, რომ OnePlus ტელეფონები ცნობილია მათი განვითარების კეთილგანწყობილობით, დეველოპერები ბევრ სამუშაოს აკეთებენ კულისებში, რათა შექმნან AOSP-ის სტაბილური პორტები.
რა არის შიმი ან BLOB?
იმისთვის, რომ გავიგოთ თუ რას აკეთებენ დეველოპერები, ჯერ რამდენიმე რამ უნდა ავხსნათ. მიუხედავად იმისა, რომ Android OS არის ღია წყარო (მას რატომღაც უწოდებენ Android Open Source პროექტს), პროგრამული უზრუნველყოფა (კერნელის გარეშე) ათასობით Android მოწყობილობაზე გაგზავნილი არ არის. დეველოპერებს არ აქვთ წვდომა წყაროს კოდზე Samsung გამოცდილება, EMUI, OxygenOS, ან Android-ის მესამე მხარის რომელიმე სხვა გემოს.
ახლა, დეველოპერებს, რომლებიც ახორციელებენ AOSP-ის მარაგის პორტირებას არა Google მოწყობილობაზე, ალბათ არ აინტერესებთ ამ Android სკინების წყაროს კოდი, რადგან ისინი არ იქნებიან. ამ ROM-ების შეცვლა და აშენება. ეს მართალი იქნებოდა, რომ არა ერთი დიდი, დიდი მიზეზი: ნაწილები, რომლებიც აუცილებელია კამერის გამართულად მუშაობისთვის, ძირითადად The კამერა HAL (Hardware Abstraction Layer), არიან ასევე დახურული წყარო.
არა მხოლოდ კამერის HAL-ის, არამედ ROM-ის დახურული წყაროს არსებობის პრობლემა ის არის, რომ დეველოპერები, რომლებიც მუშაობენ AOSP-ზე თავიანთ მოწყობილობაზე პორტირებაზე, იქნებიან. ბრმა მუშაობს. დახურული OEM ROM-ს შეუძლია ინტერფეისი კამერასთან HAL უბრალოდ, რადგან OEM-ს აქვს წვდომა კამერის HAL წყაროზე. კამერა HAL არის ის, რაც საშუალებას აძლევს ROM-ს "დალაპარაკება" კამერის აპარატურას - მის გარეშე კამერა უფუნქციო იქნებოდა. წარმოიდგინეთ კამერა HAL, როგორც მანქანის საჭე და პედლები. საჭე/პედლები იძლევა მანქანის შიდა კომპონენტების კონტროლის საშუალებას მძღოლისთვის (ROM) შიდა კომპონენტების გამოყენების გარე ინტერფეისით.
რაც უფრო და უფრო რთული ხდება კამერის აპარატურა ( ორმაგი კამერების გამოჩენამაგალითად), კამერის HAL წყაროზე წვდომა ბევრად უფრო მარტივს გახდის AOSP ROM-ის პორტირებას ფუნქციური კამერით.
თუმცა, OEM არ იძლევა წვდომას კამერის HAL წყაროზე სხვადასხვა მიზეზის გამო. პირველ რიგში, თუ მათ არ აქვთ ყველა საკუთრების უფლება კამერაზე HAL (მაგალითად, როდესაც ისინი აერთიანებენ სხვა კომპანიების ინტელექტუალურ საკუთრებას), მაშინ მათ არ შეუძლიათ წყაროს გავრცელება. მეორე, კამერის HAL წყაროს გაშვებამ შეიძლება საფრთხე შეუქმნას მათ საკუთარ ინტელექტუალურ საკუთრებას. და ბოლოს, კომპანიებს არ აქვთ იურიდიული ვალდებულება, მიაწოდონ ეს კოდი (განსხვავებით ბირთვის კოდისგან, რომელიც ისინი არიან ვალდებულია გაათავისუფლოს GPL-ის მიხედვით), ამდენად, მათ არ აქვთ სტიმული, გაათავისუფლონ იგი. ასე რომ, კამერის HAL წყაროზე წვდომის გარეშე, როგორ ახერხებენ დეველოპერები კამერას AOSP ROM-ებზე მუშაობას? პასუხი არის BLOB, შიმშილი და ბევრი და ბევრი გამართვა.
Რჩევა BLOB (Binary Large OBject) შეიცავს წინასწარ შეფუთულ ბინარებს, რომლებიც პროგრამული უზრუნველყოფის კომპილირებული ფორმაა. ამ შემთხვევაში, კამერის HAL წყარო შედგენილია OEM-ის მიერ და იგზავნება მოწყობილობებზე ბინარების სახით. როდესაც დეველოპერები საუბრობენ BLOB-ებზე, ისინი მიუთითებენ იმ ბინარებზე, რომლებიც იგზავნება ცოცხალ მოწყობილობებზე, რომელთა ამოღებაც მათ შეუძლიათ. ახლა, თემა "კამერა BLOBs" არის დიდი ხანია აწუხებდა OnePlus მრავალი თვის განმავლობაში, მაგრამ ფაქტია, რომ დეველოპერებს ყოველთვის ჰქონდათ წვდომა კამერის BLOB-ებზე. The კამერის HAL წყაროს კოდი არის ოქროს ბილეთი თუმცა აქ დეველოპერებისთვის, მაგრამ ეს ასე იქნება არასოდეს, არასოდეს გათავისუფლდე იურიდიული საფრთხის გამო ის ჩააყენებს კომპანიებს, როგორიცაა OnePlus.
ამრიგად, დეველოპერებს, რომლებიც ცდილობენ AOSP-ის მოწყობილობაზე გადატანას, რჩებიან მხოლოდ HAL კამერის BLOB-ებით, რომლებისთვისაც მათ არ აქვთ წვდომა წყაროს კოდზე. იშვიათად თუ ოდესმე დეველოპერს შეუძლია დააწყვილოს თავისი AOSP ROM კოდი კამერასთან HAL BLOB და მოელოდეს, რომ ის იმუშავებს, ამიტომ ამ ორს შორის უფსკრული გადალახვის მიზნით, დეველოპერები ქმნიან იმას, რასაც ეწოდება "შიმ.”
"შიმ" არის "სოლი (რაღაც) ან სივრცის შევსება." ეს არის ფაქტობრივად რასაც დეველოპერი აკეთებს, როდესაც შიმ-ის დაწერა-ისინი დაამატებენ კოდს, რათა BLOB-მა შეძლოს ინტერფეისი AOSP-ის წყაროს კოდთან, რომელსაც ისინი მუშაობენ თან. Shims გამოიყენება იმისათვის, რომ AOSP-თან მუშაობდეს ყველა სხვადასხვა სახის BLOB-ები, მაგრამ, როგორც წესი, ეს არის BLOB კამერა, რომელიც მოითხოვს ყველაზე მეტ ციმციმს. როგორც უკვე აღვნიშნეთ, shimming საჭიროა არა მხოლოდ Android-ის ახალი ვერსიების მოწყობილობაზე პორტირებისთვის (როგორიცაა ყველა ის არაოფიციალური Android Oreo ROM), მაგრამ ასევე საჭიროა იმავე Android ვერსიის AOSP-ზე პორტირებისას. მოწყობილობა.
რეკომენდებული საკითხავი: მაღაზიიდან თარომდე: სიღრმისეული კაპიტულაცია იმის შესახებ, თუ რატომ არის გამორიცხული MSM8974 მოწყობილობები Nougat-იდან
მაგალითად, OnePlus 2-მა მიიღო თავისი ბოლო ოფიციალური ძირითადი OS განახლება Android 6.0 Marshmallow-ის სახით. თუმცა, მოწყობილობას რეალურად აქვს სრულად მუშაობს მორგებული AOSP-ზე დაფუძნებული ROM-ები დაფუძნებულია Android Nougat-ზე და ეს დეველოპერების შრომისმოყვარეობისა და მათი შიმების წყალობით. ჩვენ განვიხილავთ შიმების რამდენიმე მაგალითს, მაგრამ პირველ რიგში, ჩვენ უნდა ვისაუბროთ იმაზე, თუ როგორ მუშაობს შიმები.
როგორ მუშაობს shimming?
ვინაიდან დეველოპერებს არ აქვთ წვდომა კამერის HAL ან OEM ROM წყაროზე (და მხოლოდ წინასწარ შედგენილ ბინარებზე), მათ არ შეუძლიათ იცოდნენ რა ფუნქციებს ელის კამერა HAL. ამის გამო, ხშირად არის შეუსაბამობა ფუნქციის სახელს შორის, რომელსაც კამერა HAL ეძებს და ფუნქციის რეალურ სახელს შორის AOSP კოდში, რომლითაც მუშაობს დეველოპერი.
ამ პრობლემის გადასაჭრელად, დეველოპერი უბრალოდ ქმნის ახალ ფუნქციას, რომელიც იყენებს იმავე სახელს ფუნქცია, რომელსაც კამერა HAL BLOB მოელის, მაგრამ ეს ახალი ფუნქცია უბრალოდ ასრულებს იმას, რაც დეველოპერს სურს მას. ეს ახალი ფუნქცია, რომელიც მოქმედებს როგორც შუამავალი BLOB-სა და AOSP-ს შორის, არის შიმ. ეს კონკრეტული სცენარი, როდესაც BLOB ვერ პოულობს ფუნქციას, რომელსაც ეძებს, არის ერთ-ერთი ყველაზე გავრცელებული, სადაც საჭიროა შიმ.
შესაძლოა, რაღაც უფრო აზრიანი იყოს ჰიპოთეტური მაგალითით, რომელიც ეხება OnePlus 3T-ს. ჩვენ შევქმნით მაგალითს OxygenOS და OnePlus კამერის გამოყენებით. თუ გამოვიყენებთ OxygenOS Nougat-დან აღებულ კამერის BLOB-ებს OnePlus 3T-ისთვის AOSP-ზე დაფუძნებული Nougat ROM-ის შესაქმნელად, შეიძლება პრობლემები შეგვხვდეს. ეს იმიტომ ხდება, რომ კამერა BLOBs (რომელიც თავდაპირველად შედგენილი იყო OEM-ის მიერ) შეძლებს ყველა იმ ფუნქციის მითითებას, რომელიც მას სჭირდება OxygenOS-ის ფარგლებში, მაგრამ ვინაიდან კომპილირებული AOSP ROM-ს შეიძლება არ ჰქონდეს ეს ფუნქციები ან სხვა სახელით იყოს შედგენილი (რაც იწვევს შეუსაბამობას ფუნქციის სიმბოლოებს შორის), იქნება შეცდომა. ამის გამოსწორება შესაძლებელია AOSP ROM-ში ახალი ფუნქციის შექმნით, სახელწოდებით, რომელსაც BLOB მოელის — ჩვენი შიმ.
პროგრამირების კონტექსტში სიმბოლოები გამოიყენება კოდში კონკრეტული ფუნქციების მითითებისთვის. სიმბოლოები აუცილებელია, რადგან ფუნქციის პოზიცია შეიძლება შეიცვალოს კოდის რედაქტირებისას და ა.შ. მყარი კოდირების თავიდან ასაცილებლად ფუნქციებზე მითითებით, შემდგენელი ქმნის სიმბოლოების ცხრილს, რომელიც სხვა ფუნქციებს შეუძლიათ გამოიყენონ ყოველთვის მარჯვნივ მიმართვისთვის. ფუნქცია. როდესაც კომპილაციამდე ცვლით ფუნქციის სახელს, იცვლება მისი სიმბოლოც, ასე რომ, ძირითადად, ნებისმიერი ცვლილება რომელსაც OEM კამერას აწვდის HAL წყაროს კომპილაციამდე, დეველოპერებს ახლის შექმნას დასჭირდება შიმ.
ჩვენ მიერ აქამდე შეთავაზებული ახსნა ისე ჟღერს, თითქოს შიმების შექმნა მარტივია. რამდენიმე ფუნქციის სახელის აქა-იქ შეცვლა არც ისე რთულად ჟღერს, არა? ეს რომ ადვილი ყოფილიყო. შიმების რეალობა მოიცავს არა მხოლოდ ფუნქციების გადარქმევას. ჩვენ ვესაუბრეთ XDA-ს აღიარებულ დეველოპერს Sultanxda-ს, რომელმაც შეძლო მოგვაწოდოს მაგალითი ერთ-ერთი ყველაზე რთული ჩიპის შესახებ, რომელზეც მან მუშაობდა.
Shimming - არც ისე ადვილია, როგორც ჟღერს
მათთვის, ვინც არ იცნობს OnePlus 3T-ს, წინა კამერა თავდაპირველად საკმაოდ გატეხილი იყო. AOSP-ზე დაფუძნებული საბაჟო ROM-ები. დასაწყისისთვის, 8 მეგაპიქსელზე მეტი სურათის გადაღების მცდელობა გამოიწვევს კრახი. ამ საკითხის გადაჭრის მცდელობისას სულთანქსდამ რამდენიმე გააკეთა შიმები რათა OnePlus 3T წინა კამერამ გამართულად იმუშაოს.
Shim #1 - კამერის პაკეტის სახელის შეცვლა
იმისათვის, რომ შეეჩერებინა წინა კამერის ავარია, როდესაც მომხმარებელი იღებდა 8 მეგაპიქსელზე მეტ სურათს, Sultanxda აიძულა კამერა HAL დაედგინა ყველა კამერა, როგორც OnePlus კამერა. ეს კეთდება იმიტომ, რომ OnePlus-მა გადაწყვიტა დამხმარე ფუნქცია მიეძღვნა გარკვეულ აპლიკაციებს (isOnePlusCamera, isFacebookCameraდა ა.შ.) რატომღაც. Sultanxda-მ ეს დააფიქსირა კამერის HAL-ის დახატვით, ასე რომ, ის მიუთითებს ახალ ფუნქციაზე, რომელიც ყოველთვის ბრუნდება „ჭეშმარიტი“, თითქოს მომხმარებელი იყენებს OnePlus-ის კამერას, მაშინაც კი, როცა ის არ არის.
Shim #2 - გამორთეთ QuadraCfa
მისი შემდეგი გამორთვისთვის, მას მოუწია QuadraCfa-ს გამორთვა, რომელიც სავარაუდოდ არის Qualcomm-ის საკუთრების ტექნოლოგია, რომელიც დაკავშირებულია კამერასთან. ჩვენ ვამბობთ, სავარაუდოდ, იმიტომ, რომ არც მე და არც Sultanxda არ ვიცით ზუსტად რა არის QuadraCfa, მაგრამ Sultanxda-მ იცის, რომ ის არღვევდა წინა კამერას, როდესაც ჩართული იყო.
მან შეამჩნია, რომ QuadraCfa როგორღაც ახერხებდა თავის თავს, მაგრამ არ იყო დარწმუნებული, რატომ ან როგორ აკეთებდა ამას. ამის გადაჭრა მოითხოვდა მისი მხრიდან საკმაოდ არატრადიციულ მოდიფიკაციას. ჩვეულებრივ შიმში, შიმ ფუნქცია, როდესაც შედგენილია, უზრუნველყოფს გამოტოვებულ სიმბოლოს, რომელსაც BLOB ეძებს. ამ შემთხვევაში, BLOB-ს უკვე ჰქონდა მისთვის საჭირო სიმბოლოები, რომლებიც სავარაუდოდ წარმოადგენდნენ ფუნქციებს, რომლებიც იწყებდნენ QuadraCfa-ს.
ამგვარად, მას სჭირდებოდა კამერის HAL-ის მიერ გამოყენებული სიმბოლოების გადალახვა და, არსებითად, მათი „დაკარგვის“ გაკეთება. მისი shims უზრუნველყოფს იმ "დაკარგულ" სიმბოლოებს. ამის გაკეთების ერთადერთი გზა არის მეშვეობით ექვსკუთხა რედაქტირება კამერის თავად HAL. თექვსმეტობითი რედაქტირება ძირითადად ეძებს არაორგანიზებულ ჭუჭყს ბინარული მონაცემების სახით, რათა იპოვოთ ნემსი თივის გროვაში - ფუნქცია ან სტრიქონი, რომლის რედაქტირებასაც ეძებთ.
ფუნქციის თექვსმეტობითი რედაქტირება არსებითად უფრო რთულია, ვიდრე სტრიქონის თექვსმეტობითი რედაქტირება, მაგრამ საბედნიეროდ, Sultanxda-მ შეძლო თავიდან აიცილა QuadraCfa-ს უკან არსებული ფუნქციების თექვსმეტობითი რედაქტირება. თექვსმეტობითი რედაქტირება სიმბოლოების სახელების ამ სიმბოლოების გასაუქმებლად.
შიმ #3 - კაშკაშა სინათლის გამოსწორება
შემდეგი, Sultanxda-მ დაადგინა, რომ სურათის გადაღება წინა კამერიდან, როდესაც ნათელი განათების პირობებში, კამერის ავარიას გამოიწვევს. ამ შეცდომის საკუთარ მოწყობილობაზე რეპროდუცირების მიზნით, Sultanxda რეალურად ჩართო მისი OnePlus One-ის ფანრის ფუნქცია და აანთო შუქი OnePlus 3T-ის წინა კამერის წინ იმისათვის, რომ ის ავარიული და გამოსაყენებელი ჟურნალების წარმოება! მას შემდეგ, რაც მან აღმოაჩინა, თუ რა ფუნქციას იწვევდა ავარია, მან შექმნა ჭურვი, რათა აიძულოს მოწყობილობას ყოველთვის გამოეყენებინა დაბალი განათების რეჟიმი წინა კამერისთვის.
Shim #4 - დაბალი გარჩევადობის წინა კამერის სურათები
მას შემდეგ, რაც დააფიქსირა კაშკაშა შუქის ავარია წინა შიგთავსთან, Sultanxda-მ აღმოაჩინა კიდევ ერთი შეცდომა, რომელიც რეალურად წარმოიშვა ამ შიმბის პირდაპირი შედეგით: დაბალი გარჩევადობის წინა კამერის სურათები. იმის ნაცვლად, რომ გადაეღოთ სურათები მომხმარებლის მიერ მოთხოვნილი გარჩევადობით (მაგ. 16MP), შედეგად მიღებული სურათი იქნება გადაღებული 4MP.
ამის გადაჭრა მოითხოვდა ფუნქციების შეცვლას handleSuperResolution და isSuperResolution რომ ყოველთვის დაბრუნდეს ჭეშმარიტი, მაგრამ მხოლოდ მაშინ, როდესაც წინა კამერა აქტიურია (რადგან წინააღმდეგ შემთხვევაში, კამერა დაეჯახა უკანა სენსორიდან სურათების გადაღებისას).
ნასწავლი გაკვეთილი - შიმშილი შეიძლება იყოს რთული
Sultanxda აღიარებს, რომ ჩიპები, რომლებიც მან უნდა შექმნა, OnePlus 3T წინა კამერის მუშაობისთვის, არ წარმოადგენს თქვენს ტიპურ მაგალითს. ის საკმაოდ ამაყობს თავისი შიმშილით, მისი სირთულის და თვით BLOB-ის რედაქტირების იშვიათი აუცილებლობის გათვალისწინებით. მაგრამ ეს მაგალითი უბრალოდ აჩვენებს, თუ რამდენად რთული შეიძლება იყოს კამერის აპარატურის მუშაობა გარკვეულ მოწყობილობებზე.
შეიძლება თქვენი კამერის შიმშის თავგადასავლები ნაკლებად მტკივნეული იყოს ვიდრე ჩემი. -სულთანხდა
ჟურნალები, ჟურნალები და სხვა ჟურნალები. ავარიის რეპროდუცირების თანმიმდევრული ხერხისა და ჟურნალების გარეშე, დეველოპერებს პრობლემის წყაროს პოვნის მცირე იმედი აქვთ. მაშინაც კი, თუ ისინი აღმოაჩენენ, თუ რა იწვევს პრობლემას, ეს ყოველთვის არ არის პირდაპირი გამოსავალი. ამ შეცდომების პოვნისა და აღმოფხვრის მთელ პროცესს შეიძლება დასჭირდეს დღეები ან კვირები და არის მიზეზი იმისა, რომ AOSP ROM-ებზე კამერის დაფიქსირება ერთ-ერთი ყველაზე რთული ამოცანაა.
თუ თქვენს მოწყობილობას აქვს AOSP ROM პორტირებული სრულად ფუნქციონირებადი აპარატურით, იმედია, შეგიძლიათ დაიწყოთ ვაფასებთ იმ ბრძოლას, რომელიც შეიძლება გაიარეს ამ დეველოპერებმა, რათა მოგაწოდოთ ისინი მახასიათებლები. დააფასეთ ისინი მათი შრომისთვის, რადგან ეს ადვილი არ არის. ეს არის ბევრი სამუშაო, რომელსაც მომხმარებელთა დიდი უმრავლესობა ვერც კი შეამჩნევს, რადგან ჩვენს ფორუმებზე ნიჭიერი დეველოპერები ზრუნავენ Android-ის ბევრ უხილავ ნაწილზე.
ჩვენ გვინდა განსაკუთრებული მადლობა გადავუხადოთ Sultanxda-ს მრავალი წვლილისთვის, რომელიც მან შესთავაზა ამ სტატიის შექმნაში.