ამ სტატიაში ჩვენ ვიკვლევთ სიმართლეს იმის შესახებ, თუ რატომ არ იღებენ Snapdragon 801 მოწყობილობები Android Nougat-ს. ჩიპსეტის შემქმნელებიდან დაწყებული, გამყიდველებით დამთავრებული, პრობლემები ბევრია!
განახლებულია, რათა ასახავდეს ან-ან Vulkan ან OpenGL ES 3.1 მოთხოვნას Android 7.0-ისთვის
ბოლო დროს დაიწერა უამრავი სტატია ვერსიის განახლებების, გამყიდველისა და ჩიპსეტის შემქმნელის ურთიერთქმედების შესახებ და რას ნიშნავს ეს მოწყობილობებისთვის, რომლებიც წინ მიიწევენ. რატომ გაიზარდა ეს ამ კვირაში?
კარგად, ამ კვირაში გამოჩნდა იმის გათვალისწინებით, რომ პატივცემული Nexus 5 არ მიიღებს Android 7.0 (Nougat) განახლებას და Qualcomm-მა გამოაცხადა, რომ ეს არ იქნება უზრუნველყოფს MSM8974-ის მხარდაჭერას (უფრო ხშირად ცნობილია როგორც Snapdragon 801) 7.0-ზე. ეს სტატია დაიწერა XDA Recognized-თან თანამშრომლობით დეველოპერი ბუმბერაზი.
თემამ საკმაოდ დიდი ინტერესი გამოიწვია სხვადასხვა საინფორმაციო საიტებიდან, მაგრამ ბევრი გამოტოვებს იმ დახვეწილ ნიუანსებს, რაც სინამდვილეში ხდება სცენის მიღმას. ეს სტატია აგიხსნით ცოტა მეტს იმის შესახებ, თუ როგორ მუშაობს პროგრამული უზრუნველყოფის განახლებები, OEM-ებთან მუშაობის გამოცდილების გამოყენებით მათი ოფიციალური firmware განახლებების შესახებ. ჩვენ გაგაცნობთ, თუ რა ხდება კულისებში (და რატომ) და რატომ შეიძლება არ მიიღოთ უახლესი პროგრამული უზრუნველყოფა თქვენს ტელეფონზე.
პირველი ნაბიჯი Android firmware განახლების ცხოვრებაში არის upstream განახლება. ეს არის ის, რაზეც Google მუშაობს შიდა. „ღია სამუშაო ნაკადებისგან“ განსხვავებით, ანდროიდი ვითარდება დახურული სამუშაო ნაკადის გამოყენებით, წყაროს კოდით კედელზე გადაყრილი ყოველწლიურად, როდესაც ახალი გამოშვება გამოდის. თავდაპირველად, Google-მა თქვა, რომ ეს იყო ფრაგმენტაციის თავიდან აცილება იმ ადამიანებისგან, რომლებიც აწარმოებდნენ სისხლდენის ვერსიებს მიუხედავად იმისა, რომ ადრეულ დღეებში ყველაფერი სწრაფად ვითარდებოდა, მაგრამ, როგორც ჩანს, მათ შეინარჩუნეს ეს პოლიტიკა ადგილი.
დროის გარკვეულ მომენტში, ჩვეულებრივ განახლების საჯარო გამოცხადებამდე (თუმცა საჯარო ბეტას ბოლოდროინდელი დანერგვით, ეს ვადები იცვლება), OEM-ებს ეცნობებათ მომავალი განახლების შესახებ. შემდეგ ისინი მიიღებენ წყაროს კოდს საბოლოო განახლებისთვის დროის მეორე მომენტში (წარსულში ასე იყო ზოგჯერ გაშვებამდე ცოტა ხნით ადრე, თუმცა ჩვენ ასევე ვიცით შემთხვევები, როდესაც ადრე არ არის გათავისუფლება).
ზემოთ მდებარე AOSP საცავი შეიცავს მოწყობილობის მხარდაჭერას მხოლოდ შეზღუდული რაოდენობის მოწყობილობებისთვის. ეს ჩვეულებრივ თქვენი Nexus მოწყობილობებია. მიზეზების გამო, რომელიც მალე გახდება ცნობილი, მნიშვნელოვანია აღინიშნოს, რომ Google-ს არ აქვს სრული აპარატურის კონტროლი ამ მოწყობილობებზე; მოწყობილობები დამზადებულია OEM-ის მიერ და ის OEM შეიძენს System-on-Chip-ს (SoC) ჩიპსეტის მწარმოებლისგან.
წყაროს კოდის გამოქვეყნების შემდეგ, OEM-ის პროგრამული უზრუნველყოფის გუნდი (ფიგურალურად) დაჯდება და ფეხს აყენებს. Android-ის მთავარ წყაროს არ აქვს ტექნიკის მხარდაჭერა უამრავი ჩიპსეტისთვის, რომლებიც გამოიყენება გადაზიდვის მოწყობილობებში. თქვენი Qualcomm ჩიპსეტი სავარაუდოდ არ არის მხარდაჭერილი AOSP-ში, მაგალითად. თქვენი Exynos ერთი ნამდვილად არ არის. Mediatek თუ HiSilicon? Დაივიწყე!
BSP შეიცავს დრაივერებს და ტექნიკის აბსტრაქციის ფენებს (HAL), რომლებიც საჭიროა Android-ის გასაშვებად
რაც ახლა საჭიროა არის ა საბჭოს მხარდაჭერის პაკეტი (BSP). ეს არის საკუთრების კომპონენტების სუპერკონფიდენციალური პაკეტი, რომელიც მიწოდებულია ჩიპსეტის მწარმოებლის მიერ OEM-ისთვის. BSP შეიცავს აუცილებელ წყაროს კოდს, რომელიც საშუალებას აძლევს OEM-ებს შექმნან Android და საჭირო დრაივერები მათი მოწყობილობისთვის.
აქ უნდა აღინიშნოს, რომ OEM-ები, როგორიცაა Qualcomm, სულაც არ ენდობიან თავიანთ OEM პარტნიორებს - BSP ხელმისაწვდომია "საჭიროების ცოდნის" საფუძველზე. OEM-ებს, როგორც წესი, არ აქვთ წვდომა მოწყობილობის ზოგიერთი სუპერ-საიდუმლო ნაწილის წყაროს კოდზე (როგორიცაა ბაზაზე გაშვებული პროგრამული უზრუნველყოფა). ამ ნაწილის დახურვას, რა თქმა უნდა, ასევე აქვს პოტენციური პრობლემები, როგორც ამას ახლობლები აჩვენებენ უხვი და განმეორებადი ASN.1 დაუცველობის ანალიზი.
BSP შეიცავს დრაივერებს და ტექნიკის აბსტრაქციის ფენებს (HAL), რომლებიც საჭიროა Android-ის თქვენს მოწყობილობაზე გასაშვებად. AOSP შეიცავს HAL-ების ერთობლიობას, რომლებიც მოქმედებენ როგორც დეფინიციები იმის შესახებ, თუ რას ელის ოპერაციული სისტემა თქვენი დრაივერებისგან. სასაცილოდ ზედმეტად გამარტივებული (და შედგენილი, დემონსტრირების მიზნით) მაგალითის გამოსაყენებლად, წარმოვიდგინოთ ფანარი თქვენს ტელეფონზე.
მაგალითი HAL - თქვენი ფანარი
წარმოვიდგინოთ, რომ თქვენს მოწყობილობას აქვს ფანარი უკანა მხარეს (თუ თქვენ გაქვთ Nexus 7 2013, თქვენ მოგიწევთ ცოტა მეტი წარმოსახვის გაკეთება, ვიდრე ყველა სხვას -- უკაცრავად!). ამას აკონტროლებს მძღოლი. ჩვენი გიჟურად მარტივი მაგალითისთვის, დავუშვათ, რომ v1 HAL ამბობს, რომ თქვენ უნდა გქონდეთ ერთი ფუნქცია სახელწოდებით "setLED" ერთი პარამეტრის, სინათლის მდგომარეობის აღებით. ეს ლოგიკურია - ჭეშმარიტი თუ მცდარი. C-ში ეს ასე გამოიყურება:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
ეს ფუნქცია განსაზღვრულია BSP კოდის ფარგლებში. შემდეგ BSP შედგენილია OEM-ის მიერ ROM-ის აგების დროს და ეს ხდება ერთ-ერთი საკუთრების ".so" ბიბლიოთეკა გამყიდველის დანაყოფზე ან თქვენს მოწყობილობაზე. ეს საშუალებას აძლევს OEM-ს საიდუმლოდ შეინახოს თავისი მოწყობილობის მუშაობის გარკვეული ნაწილები. ახლა, დავუშვათ, რომ მათ სურთ შეაჩერონ ყველას დანახვა, თუ როგორ რთავენ და გამორთებენ ამ LED-ს.
ახლა წარმოიდგინეთ, რომ Google გამოუშვებს მათი HAL-ების განახლებულ ვერსიას Android-ის მომავალ ვერსიაში. ისინი ახლა გადაწყვეტენ, რომ კარგი იქნება, რომ მოგცეთ საშუალება განაახლოთ თქვენი LED-ის სიკაშკაშე, ვიდრე უბრალოდ ჩართოთ ან გამორთოთ იგი. იქნებ ეს არის ადაპტირებული ფლეშისთვის, ან იქნებ ის უბრალოდ HAL-ის განახლების იძულებით და ჩიპსეტის შემქმნელების ბიზნესში შესანარჩუნებლად? ჩვენ ნებას მოგცემთ, მკითხველს, მიაღწიოთ საკუთარ აზრს ამ თემაზე. HAL-ის ზოგიერთ განახლებას აქვს აშკარა სარგებელი (როგორიცაა ახალი კამერა HAL, რომელიც ავლენს ნედლეულ გადაღებას და მსგავსი), ხოლო სხვები გარკვეულწილად ნაკლებად ნათელია დანიშნულებით.
ამ ახალი (გამოგონილი) HAL სიკაშკაშისთვის, დავუშვათ, Google ამბობს, რომ თქვენ კვლავ უნდა გამოავლინოთ ფუნქცია სახელწოდებით setLED, მაგრამ ამჯერად სიკაშკაშისთვის გადაცემული მთელი რიცხვით. ახლა 0 გამორთავს მას და 255 ჩართავს სრულად.
თუ თქვენ ხართ OEM, შეგიძლიათ აიღოთ თქვენი სუპერ საიდუმლო კოდი, რომ ჩართოთ ეს LED და ჩართოთ იგი ამ ახალ ფუნქციაში. თქვენ შეიძლება გამოიყენოთ პულსის სიგანის მოდულაციაც კი, რომ დაარეგულიროთ LED-ის სიკაშკაშე რიცხვიდან გამომდინარე. თქვენ შეცვალეთ ფუნქცია ახლა ასე გამოჩნდეს:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Მერე რა? ჰოდა, ახლა ანდროიდის ეს ახალი ვერსია შეუთავსებელია არსებულ „ბლობებთან“. თქვენი OEM უნდა გამოიყენოს ეს ახალი blobs, რადგან Android OS მოელის, რომ დაინახოს ახალი ფუნქციის განსაზღვრა და ვერ "იპოვის" ძველს, როდესაც ის ეძებს გზებს LED-ის დაყენებისთვის.
ამ ეტაპზე, მოდით, მოკლე შესვენება გადავხედოთ, თუ როგორ მართავს აქ Custom ROM-ები (აშენებული წყაროდან). ეს არის ის, რასაც თქვენ შორის გამჭრიახი ყვირის თქვენს ეკრანზე ახლავე - ბოლოს და ბოლოს, ჩვენ ვართ XDA, სახლი. HTC HD2მსოფლიოში ყველაზე გრძელვადიანი ტელეფონი... (მხოლოდ ჩანაწერისთვის, გიჟი გენიოსები იქ დარბიან Android 6.0 HD2-ზე ამ დღეებში! ცუდი არ არის ტელეფონისთვის, რომელიც თავდაპირველად გაიგზავნა Windows Mobile 6.5-ით 2009 წელს)
აქ არის სხვადასხვა მიდგომა - ზოგჯერ დეველოპერები არღვევენ ROM-ს და ეუბნებიან OS-ს, გამოიყენოს ფუნქციების ძველი განმარტებები. ეს ცოტა ბინძურია და შესანარჩუნებლად ბევრ ცვლილებას ახდენს. სხვა მიდგომა არის OEM ორობითი "შიმ".
"შიმ" მიდგომაა დაწეროთ და შექმნათ პატარა ახალი ბიბლიოთეკა, რომელიც შეიცავს მოსალოდნელ ფუნქციის განმარტებას - ჩვენი მაგალითისთვის, ჩვენ მხარს ვუჭერთ მთელ რიცხვს სიკაშკაშისთვის. შემდეგ, შიმში, ეს ითარგმნება ძველი HAL-ის მოთხოვნების დასაკმაყოფილებლად. ასე რომ, ჩვენს მაგალითზე, ჩვენ შეგვიძლია ვთქვათ, რომ ნებისმიერი სიკაშკაშე, რომელიც მოითხოვება 128-ზე მაღლა, ჩართავს LED-ს, ხოლო ქვემოთ მოცემული ყველაფერი გამორთავს მას. ან შეგიძლიათ თქვათ, რომ ნული არ ჩართავს მას. ეს დეველოპერის გადასაწყვეტია. ისინი ადგენენ შიმს და აძლევენ Android-ს, რომ გამოიყენოს იგი მშობლიურის ნაცვლად. შიმი შემდეგ უწოდებს OEM blob-ს.
სწრაფმა `adb ბიძგმა~ და გადატვირთვამ უნდა გაააქტიუროს შიმშილი და მოგცემთ აკონტროლოთ თქვენი გამოგონილი LED, მიუხედავად იმისა, რომ თქვენ გაქვთ მხოლოდ ძველი HAL.
პრობლემა ის არის, რომ ეს აშკარად არასრულყოფილი პროცესია. ახლა თქვენ გექნებათ უცნაურობები - ამ მოწყობილობას ექნება საკმაოდ უხეში ნათება, რომელიც ან მთლიანად ჩართულია ან მთლიანად გამორთულია. ეს არ არის იდეალური - ოპერაციული სისტემა ფიქრობს, რომ ის ძალიან რბილ შუქს ასხივებს, მაგრამ რეალურ LED-ს ეუბნებიან, რომ ის კონკურსში ხელოვნური მზისგან გამოდის და ცდილობს თქვენს დაბრმავებას. მაგრამ ჰეი, ცხოვრება არ არის სრულყოფილი და ახლა თქვენ გაქვთ მომუშავე LED თქვენს ძველ ტელეფონზე!
(დიახ, ეს არის ერთ-ერთი მიზეზი იმისა, რის გამოც არსებობს უცნაურობები და შეცდომები, როდესაც XDA მომხმარებლები და დეველოპერები მართავენ თავიანთ გიჟურ და გიჟურ მიღწევებს პორტირების უნარის შესახებ. ვგულისხმობ heck, Galaxy S II არის ერთი შეხედვით გამოსაყენებელი Android 6.0 ROM ახლა. გასულ წელს გამოშვებულ ბევრ ტელეფონს ჯერ კიდევ არ აქვს 6.0!)
მოდით გადავუხვიოთ OEM-ის პერსპექტივას. სამწუხაროდ, OEM-ების უმეტესობა უკვე მუშაობს სულ მცირე 1 ტელეფონით ადრე, ვიდრე ჩვენ ახლა ვართ. მათი ყურადღება გამახვილებულია შემდეგ ტელეფონზე, რომლის გაყიდვასაც აპირებენ - მათ ნამდვილად ვერ დაადანაშაულებთ, რადგან ისინი ფულს მხოლოდ ყიდიან მოწყობილობებზე აკეთებენ. ისინი ფულს არ შოულობენ ერთი ან ორი წლის წინ გაყიდული მოწყობილობებიდან, ამიტომ მათ უნდა განაგრძონ ახალი მოწყობილობების გამოშვება. ეს არის ერთ-ერთი მიზეზი, რის გამოც HTC-სა და Blackberry-ს უჭირს - არ აქვს მნიშვნელობა, რამდენი აღმასრულებელი ინარჩუნებს სიკვდილს თავიანთ ძველ Blackberry Curve-ზე, რადგან ისინი იქ არ იღებენ ახალ მოწყობილობას.
თუ OEM არ მიიღებს BSP-ს, ისინი არ აპირებენ XDA-ს მიდგომას დაარღვიონ build-ის ერთად გატეხვა. რატომ? ისე, მათ უნდა დაუჭირონ მხარი ამ პროგრამულ უზრუნველყოფას თავიანთი მომხმარებლებისთვის. თუ ისინი გამოუშვან პროგრამული უზრუნველყოფა, რომელიც ნახევრად მუშაობს, მომხმარებლებს ეზიზღებათ ისინი, ბრაზდებიან და აჟიტირდებიან და დღის განმავლობაში გააგრძელებენ მხარდაჭერის ხაზებს.
OEM-ებს ასევე უწევთ ბრძოლა გადამზიდავებთანყოველ შემთხვევაში არაევროპულ ბაზრებზე. ოპერატორებს არ სურთ კლიენტებს პრობლემები ჰქონდეთ პროგრამული უზრუნველყოფის განახლებებთან დაკავშირებით. სინამდვილეში, ოპერატორები ხშირად ურჩევნიათ არ გამოუშვან პროგრამული უზრუნველყოფის განახლებები.
ამის გასაგებად, წარმოიდგინეთ თქვენი დიდი დეიდა ალისა. ის არის ის, ვინც დაგირეკავთ დღის არასასიამოვნო დროს, რათა გთხოვოთ დახმარება "კომპიუტერის საკითხთან დაკავშირებით". თქვენ შემდეგ აღწერთ, თუ როგორ დააწკაპუნოთ "დაწყების მენიუზე" და უნდა ამოიცნოთ ის, როგორც "დიდი დროშა ქვედა მარცხენა კუთხეში" და დაბნეულობას შეხვდებით. დაახლოებით 45 წუთის (და ბევრი იმედგაცრუების) შემდეგ, ირკვევა, რომ დეიდა ალისამ გადაათრია თავისი საწყისი მენიუ ეკრანის მარჯვენა კიდეზე და უბრალოდ სჭირდებოდა მისი უკან გადატანა. დიახ, მაუსის მარცხენა ღილაკით!
ახლა წარმოიდგინე, რომ გყავს ათასი დეიდა ალისა. ისინი ყველა ურეკავენ თქვენს მომხმარებელთა მხარდაჭერას, ვერ პოულობენ Candy Crush-ს ტელეფონზე, წუხან, რომ ჰაკერმა წაშალა ის მათი ტელეფონიდან. ოჰ, და ხატები ახლა ცოტა განსხვავებულად გამოიყურება - იქნებ ჰაკერი ჯერ კიდევ მათ ტელეფონშია?
დიახ, ეს არის გამიზნული, რომ ცოტათი მხიარული იუმორი იყოს, მაგრამ სანამ არ გამოიცნობთ მიზეზებს, რის გამოც ხალხი მათ მხარდაჭერისთვის მიმართავენ მათ, თქვენ არ დაიჯერებთ მათ პრობლემებს. პროგრამული უზრუნველყოფის განახლება, რომელიც ცვლის, თუ როგორ მუშაობს ტელეფონი ან სად არის ნივთები, გამოიწვევს მნიშვნელოვან მხარდაჭერას. მინიმუმ, ის მოითხოვს დამხმარე პერსონალის გადამზადებას (რადგან მათი უმეტესობა არ არის თქვენი მოყვარული XDA მკითხველი, სამწუხაროდ).
მას შემდეგ, რაც OEM მიიღებს BSP-ს, ისინი პორტირებენ ROM-ს და გამოიყენებენ ყველა ცვლილებას ROM-ში. ისინი დააგროვებენ თავიანთ ჭურჭელს და დაამატებენ საშინელ მულტფილმის კანს, რომელიც თინეიჯერების ანიმეში უფრო ლამაზად გამოიყურება. მერე შეამოწმებენ.
Ბევრი.
არის ყველანაირი მოთხოვნა, რომელსაც თქვენი ტელეფონი უნდა შეასრულოს. მობილური ქსელები შექმნილია იმისთვის, რომ ენდოს მომხმარებლის აღჭურვილობას (რასაც ჩვენ ვუწოდებთ ტელეფონს) სწორად ქცევას. ეს ნიშნავს, რომ საჭიროა ბევრი ტესტირება მოწყობილობის დასამტკიცებლად. პროგრამული უზრუნველყოფის განახლებები საფრთხეს უქმნის ქცევის შეცვლას, ამიტომ ყველაფერი ხელახლა უნდა შემოწმდეს. სწორედ ამიტომ, თქვენ ჩვეულებრივ იხილავთ ინფორმაციას Sony პროგრამული უზრუნველყოფის განახლებების შესახებ გარე სატესტო სერვისებიდან, რომლებიც ადასტურებენ, რომ firmware შეესაბამება ტესტის მოთხოვნებს.
ახლა... რა ხდება განახლების შემდეგ ან ორი (ან ზოგიერთ შემთხვევაში არცერთი)? SoC მწარმოებელი არ მისცემს OEM-ს განახლებულ BSP-ს. ყოველივე ამის შემდეგ, SoC მწარმოებელი ამისგან ბევრს ვერ მიიღებს. OEM აღარ აკეთებს ფულს თქვენს ტელეფონზე გაყიდვის შემდეგ. და ამ ეტაპზე, თქვენი ტელეფონი არ იღებს სხვა ძირითად ვერსიას.
BSP-ების რაოდენობის შემცირება, რომელსაც OEM-ის მიწოდება სურს, ფულის დაზოგვის შესანიშნავი გზაა - თუ მხოლოდ ახლა გჭირდებათ და არ აპირებთ რაიმე ძირითადი ვერსიის მიწოდებას. იზრდება, ეს დაზოგავს ფულს პირველადი SoC შეძენაზე და ლიცენზირებაზე, მაგრამ XDA-ზე რამდენიმე გაბრაზებული ნერდის ხარჯზე, რომლებიც აინტერესებთ, რატომ არ მიიღეს განახლება.
განახლებები რთულია. ბევრი განსხვავებული ადამიანია ჩართული ჯაჭვში. არცერთი ეს არ ამართლებს OEM-ებს Android-ის განახლებების ამჟამინდელი უნაყოფო და პათეტიკური მდგომარეობისგან. მიუხედავად ამისა, აქ არის რეალური გამოწვევები.
ბევრი OEM არის დამნაშავე ზედმეტი პერსპექტივაში და გარდაუვალი არასაკმარისი მიწოდება, რომელსაც ჩვენ ახლა ვუკავშირდებით. სამწუხარო რეალობა ის არის, რომ OEM-ების უმეტესობისთვის, პროგრამული უზრუნველყოფის განახლებები მხოლოდ გაღიზიანებაა, რომლის გარეშეც შეეძლოთ ამის გაკეთება.
მობილური სექტორი ძირითადად ჩარჩენილია ფუნქციური ტელეფონების აზროვნებაში. ანუ, სადაც მოწყობილობა არასოდეს იღებს განახლებებს. ერთხელ გამოსცადეთ, გაგზავნეთ და არასოდეს მოიხედოთ უკან. თანამედროვე სმარტფონების უსაფრთხოების საკითხებთან და საერთო დანიშნულების ოპერაციული სისტემის სრული სირთულის გამო, ასობით გარე ბიბლიოთეკით, ეს აღარ არის ვარიანტი. ან თუნდაც ის არ უნდა იყოს. Google-მა გადადგა გარკვეული ნაბიჯები ამის გამოსწორებისკენ, მინიმუმ გამოაქვეყნა უსაფრთხოების ბიულეტენი და პატჩები არსებული გამოშვებებისთვის Android-ის (გახსოვდეთ, რომ ბოლო დრომდე, უსაფრთხოების განახლებების მიღების ერთადერთი გზა იყო Android OS-ის ახალი ძირითადი ვერსიის მეშვეობით!)
სამწუხაროდ, ეს ნამდვილად არ არის საკმარისი. მიუხედავად იმისა, რომ Google განაგრძობს განახლებების გამოქვეყნებას, თქვენი მოწყობილობის უსაფრთხოება მაინც დამოკიდებულია SoC მწარმოებელზე - ვინაიდან SoC შემქმნელები ძალიან გაქვავებულები არიან ვინმე აღმოაჩენს, თუ როგორ რთავს რამდენიმე LED-ს ან გამოსცემს ხმას დინამიკიდან, ისინი აგზავნიან უზარმაზარ რაოდენობას ორობითი ბალიშებით. მოწყობილობები. ეს ბლოკები შეიცავს საკმაოდ საშინლად დაუცველ კოდს (უბრალოდ გადახედეთ Google-ის უსაფრთხოების წინა ბიულეტენებს, თუ ფიქრობთ, რომ ეს გაზვიადებულია!) და საჭიროა განახლება. რაც ნიშნავს, რომ საჭიროა განახლებული BSP-ები.
დესკტოპ კომპიუტერები (და გაფართოებით, ლეპტოპები) არქიტექტურით სრულიად განსხვავდება მობილური მოწყობილობებისგან. თქვენი მობილური ტელეფონი ან ტაბლეტი ფაქტობრივად არის სილიკონის ძლიერ საკუთრებაში არსებული ნაჭერი, რომელიც შექმნილია იმ ადამიანების მიერ, რომლებიც კარგად ფიქრობენ, მაგრამ არ აქვთ საკმარისი დრო რაიმე კარგის გასაკეთებლად. ბაზარი ისე სწრაფად მოძრაობს, რომ ისინი ძლივს ახერხებენ იმ ტემპს, რომლითაც მარკეტინგი ითხოვს ახალი პროდუქტების გამოშვებას.
ეს ნიშნავს, რომ მალსახმობები მიიღება - თქვენ ვერ იპოვით თქვენს ტელეფონს, რომელსაც მხარს უჭერს ძირითადი Linux ბირთვი და ნახავთ, რომ ყველა ტელეფონს აქვს ჩატვირთვის განსხვავებული გზა. თუმცა, თქვენს ლეპტოპზე ან დესკტოპზე, მოვაჭრეებმა ჩატვირთვის რამდენიმე სტანდარტული ხერხი გადაწყვიტეს - ადრე ეს იყო MBR (ძირითადი ჩატვირთვის ჩანაწერი) BIOS-ით, ახლა კი UEFI. ეს სტანდარტიზაცია შესაძლებელს ხდის ერთი და იგივე პროგრამული უზრუნველყოფის გაშვებას თითოეულ მოწყობილობაზე.
მიუხედავად იმისა, რომ ცოტა ხნის წინ გადაიდგა გარკვეული ნაბიჯები ამ მიმართულებით, განსაკუთრებით Sony-ის გაცნობის პროგრამასთან და მათთან დაკავშირებით ერთიანი ბირთვი, არ არის პრაქტიკული ძირითადი ბირთვის გაშვება ტელეფონების უმეტესობაზე, რადგან თითოეულ მოწყობილობაზე შემოტანილი ახალი გამყიდველისთვის დამახასიათებელი ჰაკების დიდი რაოდენობაა.
ყურსასმენის ჯეკი არასწორად არის გაყვანილი? უბრალოდ გატეხეთ იგი დრაივერებში! წარმოების დიზაინში გამოსწორების დრო არ არის.
მწარმოებელმა ჯგუფმა დაამონტაჟა კამერის მოდული თავდაყირა საწარმოო პარტიაში 1? ჩაატარეთ ჰაკინგი შიდა ვერსიის კოდის შესამოწმებლად და გადაატრიალეთ ვიდეო, თუ ის 1 ვერსიაა!
მსგავსი ჰაკები აგვარებენ მყისიერ პრობლემას, მაგრამ მხოლოდ ასუფთავებენ ზედაპირზე არსებულ უცნაურ და სპეციფიკურ ცვლილებებს. ჰეკ, ზოგჯერ კი არის სრულიად განსხვავებული ჩიპები ერთი და იგივე ტელეფონის სხვადასხვა ვერსიებში, კომერციული გადაწყვეტილებების გამო. ეს იწვევს დრაივერების ჰაკერებს და უცნაურ გადაწყვეტილებებს, რომლებსაც მხოლოდ იმ დროს ჰქონდათ აზრი, რომ ტელეფონმა იმუშაოს, რათა შესაძლებელი იყოს მისი გაგზავნა მომდევნო კვირაში.
მიუხედავად იმისა, რომ მიმდინარეობს მუშაობა 64-ბიტიანი ARM ჩიპების ძირითადი მხარდაჭერისთვის UEFI-ს გამოყენებით ჩატვირთვისთვის, აქამდე იყო არ არის აშკარა მოძრაობა ARM მოწყობილობების ჩატვირთვის უფრო სტანდარტიზებული გზით. და ეს სამწუხაროა, რადგან ეს ნიშნავს, რომ ტელეფონები გაგრძელდება მათი დასრულებამდე დიდი ხნით ადრე სამუშაო სიცოცხლე, რადგან უბრალოდ ძალიან ძვირია ტექნიკური დავალიანებისა და ტვირთის შენარჩუნება პროგრამული უზრუნველყოფა.
მეორეს მხრივ, თუ OEM გამოიმუშავებს ფულს მხოლოდ მოწყობილობის გაყიდვით, განა მათ არ სჭირდებათ იმის უზრუნველყოფა, რომ ხალხი განაგრძობს ახალი ტელეფონების შეძენას? გადავიდოდა თუ არა კომპიუტერების ბაზარი ამ მოდელზე, თუ უკვე არ იყო 30 წლიანი იმპულსი და მემკვიდრეობითი პროგრამული უზრუნველყოფა ღია კომპიუტერის პლატფორმისა და სტანდარტის გამოყენებით?
ეს არის რთული კითხვა Qualcomm-ის შიდა ცოდნის გარეშე, რაც სამწუხაროდ ჩვენ არ გვაქვს ამ მომენტში. თუმცა, ჩვენ შეგვიძლია მივიღოთ გარკვეული ინფორმაცია 7.0 Android-ის დრაივერის API-დან და CTS მოთხოვნებიდან. CTS მოთხოვნები განსაზღვრავს, თუ რას ელის Google მოწყობილობაზე, რომელიც მუშაობს მოცემულ firmware-ზე. ამ მოთხოვნების აღსასრულებლად გამოყენებული „დიდი ჩაქუჩი“ არის Google-ის ლიცენზირება მათი საკუთრების Google Play სერვისების ნაკრების გამოსაყენებლად - თუ არ დაიცავთ, თქვენ არ შეგიძლიათ Google Apps-ის გაგზავნა მოწყობილობაზე. მაშინ როცა, ზოგიერთისთვის ეს შეიძლება ჩაითვალოს უპირატესობადაშკარაა, რომ ეს არ არის ის, რაც მომხმარებლებს სურთ და მოელიან მოწყობილობისგან.
Android 7.0-ს ბევრი რამ არ დაუმატებია HAL-ში ან დრაივერებში (როგორც ზემოთ იყო აღწერილი), ამიტომ რაიმე შეუთავსებლობა ნაკლებად სავარაუდოა, რომ კონკრეტულად იქიდან წარმოიშვას. თუმცა, რაც უფრო სავარაუდოა, რომ პრობლემას წარმოშობს, არის ა ახალი მოთხოვნა Vulkan გრაფიკული API-სთვის ან GLES 3.1-ისთვის, ხელმისაწვდომი იყოს CTS-ის გასავლელად.
ამჟამად, ბევრ სისტემას ჩიპზე (SoC) არ აქვს Vulkan მხარდაჭერა გრაფიკულ პროცესორზე, მათ შორის MSM8974. ასევე, სავარაუდოდ, აქ დადგება Android 7.0-თან თავსებადობის საკითხი. ისევ და ისევ, Qualcomm-ის შიდა ცოდნისა და მათი სამომავლო გეგმების გარეშე, ჩვენთვის რთულია საბოლოო განცხადების გაკეთება მისი კვალიფიკაციის გარეშე. თუმცა, ამ დროისთვის, ჩვენ მიგვაჩნია, რომ სავარაუდოა, რომ ეს არის Qualcomm-ის მხარდაჭერის შეწყვეტის "მარტივი" შემთხვევა. (მათ თვალში) მოძველებული MSM8974 ჩიპსეტი და არ უზრუნველყოფს BSP (დაფის მხარდაჭერის პაკეტი) 7.0-ისთვის ამ პლატფორმაზე. ეს რომ ასე ყოფილიყო, ეს ნიშნავს, რომ OEM-ები თითქმის დარწმუნებული იქნებოდნენ, რომ არ გაგზავნიან 7.0-ს მოწყობილობაზე - მათ როგორმე უნდა ეპოვათ Vulkan ან GLEs 3.1 მხარდაჭერა მათი GPU და GPU წყაროსთვის. კოდი არის მობილური სტეკების ერთ-ერთი სასაცილოდ მჭიდროდ დაცული ნაწილი (უნამდვილესი მიზეზის გარეშე, ჩვენ დავამატებდით - იხილეთ AMD, ღია წყაროს მიღებისას საკუთარი AMDGPU დრაივერი სამუშაო მაგიდაზე Linux). სამწუხაროდ, ვულკანი და ზოგადად დაჩქარებული (GLES) გრაფიკა ცოტა უფრო რთულია, ვიდრე მარტივი LED, ასე რომ, ეს არ არის ის, რისთვისაც ჩვენ ვაპირებთ დავინახოთ შიმები, რომლითაც თავსებადობა შემოგთავაზებთ.
ვინაიდან 7.0 დიდი ხანია არ გამოსულა, არსებობს რეალური შესაძლებლობა სხვა ჩიპსეტების (გარდა თავად AOSP-ში არსებული მცირე რაოდენობისა) დატოვონ. ჩამორჩება 6.0-ზე, ან ტექნიკისა და დრაივერის პრობლემების გამო (ანუ განახლებული BSP არ არის) ან SoC გამყიდველის მხარდაჭერის ნაკლებობის გამო Vulkan-თან ან GLES 3.1-თან დაკავშირებით. API. ამჟამად არც Snapdragon 800 და არც 801 არ უჭერს მხარს რომელიმე მათგანს.
საუკეთესო ფსონი არის ამ სივრცის ყურება - XDA-ს დეველოპერები უკვე კარგ წინსვლას ასრულებენ არაოფიციალური პორტებით 7.0-მდე მრავალი მოწყობილობისთვის, რომლებიც არ იღებენ ოფიციალურ 7.0 მხარდაჭერას Google-ისგან. ეს არის Vulkan-ის ან GLES 3.1-ის მხარდაჭერის გარეშე - ალბათ Android-ზე თამაშების შემქმნელები დაიწყებენ მუშაობას განიცდიან იმედგაცრუებას ფრაგმენტაციის გზით, თუ საკმარისი მომხმარებლები დაიწყებენ მორგებული ROM-ების გაშვებას Vulkan-ის ან GLES 3.1-ის გარეშე მხარდაჭერა?
Apple, როგორც წესი, მხარს უჭერს iPhone ხაზს iOS-ის უახლეს ვერსიაზე დაახლოებით 5 წლის განმავლობაში - iPhone 4s გამოვიდა 2011 წლის ოქტომბერში და განახლებული იყო iOS 9-მდე. თუმცა, ის არ მიიღებს iOS 10-ის მომავალ განახლებას, რაც ტელეფონს 5 წლიან ეფექტურ სიცოცხლეს მისცემს, თუ ვივარაუდებთ, რომ iOS 10 ოქტომბერში გამოვა. აღსანიშნავია, რომ Apple-ს ყოველთვის არ აქვს გრაფიკული API-ის მხარდაჭერა - iPhone 4s და iPhone 5 არ აქვთ აქვს Apple's Metal graphics API, რომელიც გარკვეულწილად მსგავსი სცენარია Android-ში. ვულკანი. ერთადერთი განსხვავება ისაა, რომ Apple-მა განაგრძო ძველი მოწყობილობების მხარდაჭერა ახალი გრაფიკული API-ის გარეშე.
Რას ფიქრობ? ჩართავთ თუ არა ჩვეულ ROM-ს თქვენს ტელეფონზე, რომ გახანგრძლივოთ მისი სიცოცხლის ხანგრძლივობა? თქვით თუ არა ქვემოთ მოცემულ კომენტარებში.