Σε βάθος συνθηκολόγηση του γιατί οι συσκευές SD801 εξαιρούνται από το Nougat

Ενημερώθηκε ώστε να αντικατοπτρίζει την απαίτηση είτε-ή Vulkan ή OpenGL ES 3.1 για Android 7.0

Πρόσφατα, έχουν γραφτεί πολλά άρθρα σχετικά με τις ενημερώσεις εκδόσεων, τις αλληλεπιδράσεις μεταξύ του προμηθευτή και του κατασκευαστή chipset και τι σημαίνει αυτό για τις συσκευές στο μέλλον. Γιατί έχει αυξηθεί αυτή την εβδομάδα;

Λοιπόν, προέκυψε αυτή την εβδομάδα δεδομένου ότι το αξιοσέβαστο Nexus 5 δεν θα λάβει την ενημέρωση για το Android 7.0 (Nougat) και η Qualcomm ανακοίνωσε ότι δεν θα γίνει παρέχοντας υποστήριξη για το MSM8974 (πιο γνωστό ως Snapdragon 801) στην έκδοση 7.0. Αυτό το άρθρο γράφτηκε ως συνεργασία με το XDA Recognized Προγραμματιστής μέλισσα.

Το θέμα έχει προσελκύσει αρκετό ενδιαφέρον από διάφορους ειδησεογραφικούς ιστότοπους, αλλά πολλοί χάνουν τις λεπτές αποχρώσεις του τι πραγματικά συμβαίνει πίσω από τη σκηνή

μικρό. Αυτό το άρθρο θα εξηγήσει λίγο περισσότερα σχετικά με τον τρόπο λειτουργίας των ενημερώσεων λογισμικού, χρησιμοποιώντας την εμπειρία μας στην εργασία με OEM στις επίσημες ενημερώσεις υλικολογισμικού τους. Θα σας εξηγήσουμε τι συμβαίνει στα παρασκήνια (και γιατί) και γιατί μπορεί να μην καταλήξετε να λάβετε το πιο πρόσφατο λογισμικό στο τηλέφωνό σας.

Το πρώτο βήμα στη ζωή μιας ενημέρωσης υλικολογισμικού Android είναι η upstream ενημέρωση. Σε αυτό εργάζεται η Google εσωτερικά. Σε αντίθεση με τις "ανοιχτές ροές εργασίας", το Android αναπτύσσεται χρησιμοποιώντας μια κλειστή ροή εργασίας, με τον πηγαίο κώδικα να πετιέται στον τοίχο κάθε χρόνο περίπου, όταν κυκλοφορεί μια νέα έκδοση. Αρχικά, η Google είπε ότι αυτό έγινε για να αποτρέψει τον κατακερματισμό από άτομα που εκτελούσαν εκδόσεις αιχμής ενώ τα πράγματα εξελίσσονταν γρήγορα τις πρώτες μέρες, αλλά φαίνεται ότι κράτησαν αυτή την πολιτική θέση.

Κάποια στιγμή, συνήθως πριν από τη δημόσια ανακοίνωση μιας ενημέρωσης (αν και με την πρόσφατη εισαγωγή των δημόσιων beta, αυτά τα χρονοδιαγράμματα αλλάζουν), Οι OEM θα ενημερωθούν για μια επερχόμενη ενημέρωση. Στη συνέχεια θα λάβουν τον πηγαίο κώδικα σε μια δεύτερη χρονική στιγμή για την τελική ενημέρωση (στο παρελθόν ήταν μερικές φορές λίγο πριν από την κυκλοφορία, αν και γνωρίζουμε επίσης περιπτώσεις όπου δεν υπάρχει νωρίς ελευθέρωση).

Τα upstream αποθετήρια AOSP περιέχουν υποστήριξη συσκευών μόνο για περιορισμένο αριθμό συσκευών. Αυτές είναι συνήθως οι συσκευές σας Nexus. Ωστόσο, για λόγους που θα γίνουν σαφείς σύντομα, είναι σημαντικό να σημειωθεί ότι η Google δεν έχει πλήρη έλεγχο υλικού σε αυτές τις συσκευές. οι συσκευές κατασκευάζονται από έναν OEM και αυτός ο OEM θα αγοράσει ένα System-on-Chip (SoC) από έναν κατασκευαστή chipset.

Μόλις απελευθερωθεί ο πηγαίος κώδικας, η ομάδα υλικολογισμικού του OEM θα καθίσει (μεταφορικά) και θα βάλει τα πόδια της. Το κύριο δέντρο προέλευσης Android δεν διαθέτει υποστήριξη υλικού για τα μυριάδες chipset που χρησιμοποιούνται σε συσκευές αποστολής. Το chipset Qualcomm πιθανότατα δεν υποστηρίζεται στο AOSP, για παράδειγμα. Το δικό σου Exynos σίγουρα δεν είναι. Mediatek ή HiSilicon; Ξέχνα το!

Το BSP περιέχει τα προγράμματα οδήγησης και τα επίπεδα αφαίρεσης υλικού (HAL) που απαιτούνται για την εκτέλεση του Android

Αυτό που χρειάζεται τώρα είναι ένα Πακέτο Υποστήριξης Board (BSP). Αυτό είναι ένα εξαιρετικά εμπιστευτικό πακέτο ιδιόκτητων εξαρτημάτων, που παραδίδεται από έναν κατασκευαστή chipset σε έναν OEM. Το BSP περιέχει τον απαραίτητο πηγαίο κώδικα για να επιτρέψει στους OEM να δημιουργήσουν Android και τα απαραίτητα προγράμματα οδήγησης για τη συσκευή τους.

Αξίζει να σημειωθεί εδώ ότι οι κατασκευαστές OEM όπως η Qualcomm δεν εμπιστεύονται απαραίτητα πλήρως τους συνεργάτες OEM τους -- το BSP διατίθεται με βάση τη «ανάγκη γνώσης». Οι OEM συνήθως δεν έχουν πρόσβαση στον πηγαίο κώδικα για ορισμένα από τα εξαιρετικά απόρρητα μέρη της συσκευής (όπως το λογισμικό που εκτελείται στη ζώνη βάσης). Το να έχει κλείσει αυτό το μέρος σίγουρα έχει επίσης πιθανά προβλήματα, όπως φαίνεται από το κοντινό άφθονος και επαναλαμβανόμενες ASN.1 ανάλυση τρωτών σημείων.

Το BSP περιέχει τα προγράμματα οδήγησης και τα επίπεδα αφαίρεσης υλικού (HAL) που απαιτούνται για την εκτέλεση του Android στη συσκευή σας. Το AOSP περιέχει ένα σύνολο από HAL, τα οποία λειτουργούν ως ορισμοί ως προς το τι αναμένει το λειτουργικό σύστημα να εφαρμόσουν τα προγράμματα οδήγησης. Για να χρησιμοποιήσουμε ένα γελοία υπερβολικά απλοποιημένο (και κατασκευασμένο, για σκοπούς επίδειξης) παράδειγμα, ας φανταστούμε τον φακό στο τηλέφωνό σας.

Ένα παράδειγμα HAL - Ο φακός σας

Ας φανταστούμε ότι η συσκευή σας έχει έναν φακό στο πίσω μέρος (αν έχετε Nexus 7 2013, θα χρειαστεί να φανταστείτε λίγο περισσότερο από όλους τους άλλους -- συγγνώμη!). Αυτό ελέγχεται από έναν οδηγό. Για το τρελά απλό παράδειγμά μας, ας υποθέσουμε ότι το v1 HAL λέει ότι πρέπει να έχετε μια λειτουργία που ονομάζεται "setLED" λαμβάνοντας μία μόνο παράμετρο, την κατάσταση του φωτός. Είναι ένα boolean - αληθές ή ψευδές. Στο 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 και να διατηρήσει τους κατασκευαστές chipset στη δουλειά; Θα αφήσουμε εσάς, τον αναγνώστη, να καταλήξετε στη δική σας γνώμη για αυτό. Ορισμένες ενημερώσεις 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

}

Και λοιπόν? Λοιπόν, τώρα αυτή η νέα έκδοση του Android δεν είναι συμβατή με τα υπάρχοντα "blobs". Ο OEM σας πρέπει να χρησιμοποιήσει αυτές τις νέες σταγόνες, επειδή το λειτουργικό σύστημα Android αναμένει να δει τον νέο ορισμό της λειτουργίας και δεν θα "βρεί" την παλιά όταν αναζητήσει τρόπο ρύθμισης της λυχνίας LED.

Σε αυτό το σημείο, ας κάνουμε ένα σύντομο διάλειμμα για να δούμε πώς διαχειρίζονται οι προσαρμοσμένες ROM (που έχουν δημιουργηθεί από την πηγή) εδώ. Είναι αυτό που θα φωνάζουν οι επιτήδειοι ανάμεσά σας στην οθόνη σας αυτή τη στιγμή - τελικά, είμαστε το XDA, το σπίτι του HTC HD2, το μακροβιότερο τηλέφωνο στον κόσμο... (για την ιστορία, οι τρελές ιδιοφυΐες εκεί τρέχουν Android 6.0 στο HD2 αυτές τις μέρες! Δεν είναι κακό για ένα τηλέφωνο που κυκλοφόρησε αρχικά με Windows Mobile 6.5 το 2009)

Υπάρχουν διάφορες προσεγγίσεις που ακολουθούνται εδώ - μερικές φορές οι προγραμματιστές παραβιάζουν τη ROM και λένε στο λειτουργικό σύστημα να χρησιμοποιήσει τους παλιούς ορισμούς λειτουργιών. Αυτό είναι λίγο ακατάστατο και κάνει πολλές αλλαγές για διατήρηση. Η άλλη προσέγγιση είναι να "αποστραφεί" το δυαδικό OEM.

Η προσέγγιση "shim" είναι να γράψετε και να δημιουργήσετε μόνοι σας μια μικροσκοπική νέα βιβλιοθήκη, η οποία περιέχει τον αναμενόμενο ορισμό της συνάρτησης - για το παράδειγμά μας, θα υποστηρίξαμε τον ακέραιο για τη φωτεινότητα. Έπειτα, μέσα στο παρέμβυσμα, αυτό μεταφράζεται για να πληροί τις απαιτήσεις του παλιού HAL. Έτσι, για το παράδειγμά μας, θα λέγαμε ότι οποιαδήποτε φωτεινότητα που ζητείται πάνω από 128 θα ανάψει το LED και οτιδήποτε κάτω από αυτό θα το απενεργοποιούσε. Ή θα μπορούσατε να πείτε οτιδήποτε δεν θα το ενεργοποιήσει. Εναπόκειται στον προγραμματιστή. Μεταγλωττίζουν το shim και βάζουν το Android να το χρησιμοποιεί αντί για το εγγενές. Στη συνέχεια, το shim καλεί το OEM blob.

Μια γρήγορη "ώθηση adb" και επανεκκίνηση θα πρέπει να βάλει σε λειτουργία και να σας επιτρέψει να ελέγχετε το φανταστικό LED σας, παρόλο που έχετε μόνο το παλιό HAL.

Το πρόβλημα είναι ότι αυτή είναι σαφώς μια ατελής διαδικασία. Τώρα θα έχετε ιδιορρυθμίες - αυτή η συσκευή θα έχει ένα μάλλον τραγανό φλας, που είναι είτε πλήρως ενεργοποιημένο είτε πλήρως απενεργοποιημένο. Αυτό δεν είναι ιδανικό - το λειτουργικό σύστημα πιστεύει ότι παράγει ένα πολύ απαλό φως, αλλά το πραγματικό LED λέγεται ότι διαγωνίζεται σε έναν διαγωνισμό τεχνητού ήλιου και προσπαθεί να σας τυφλώσει. Αλλά hey, η ζωή δεν είναι τέλεια, και τώρα έχετε ένα λειτουργικό LED στο παλιό σας τηλέφωνο!

(Ναι, αυτός είναι ένας από τους λόγους για τους οποίους υπάρχουν ιδιορρυθμίες και σφάλματα όταν οι χρήστες και οι προγραμματιστές XDA διαχειρίζονται τα τρελά και τρελά κατορθώματά τους ως προς την ικανότητα μεταφοράς. Εννοώ διάολο, το Galaxy S II είναι φαινομενικά χρησιμοποιήσιμο Android 6.0 ROM τώρα. Πολλά τηλέφωνα που κυκλοφόρησαν πέρυσι εξακολουθούν να μην έχουν 6.0!)

Ας επιστρέψουμε στην προοπτική του OEM. Δυστυχώς, οι περισσότεροι OEM λειτουργούν ήδη τουλάχιστον 1 τηλέφωνο πριν από το σημείο που βρισκόμαστε αυτή τη στιγμή. Η εστίασή τους είναι στο επόμενο τηλέφωνο που πρόκειται να πουλήσουν - δεν μπορείτε πραγματικά να τους κατηγορήσετε, καθώς βγάζουν χρήματα μόνο από συσκευές που πουλάνε. Δεν βγάζουν χρήματα από συσκευές που πούλησαν πριν από ένα ή δύο χρόνια, επομένως πρέπει να συνεχίσουν να κυκλοφορούν νέες συσκευές για να υπάρχουν. Αυτός είναι ένας λόγος για τον οποίο η HTC και η Blackberry αντιμετωπίζουν προβλήματα - δεν έχει σημασία πόσα στελέχη διατηρούν τη λαβή για το παλιό τους Blackberry Curve, καθώς δεν πωλούν νέα συσκευή εκεί.

Εάν ο OEM δεν λάβει BSP, δεν πρόκειται να υποχωρήσει από την προσέγγιση XDA του hacking μαζί μιας κατασκευής. Γιατί; Καλά, πρέπει να υποστηρίζουν αυτό το υλικολογισμικό για τους πελάτες τους. Εάν κυκλοφορήσουν ένα υλικολογισμικό που λειτουργεί κατά το ήμισυ, οι χρήστες θα τους μισούν, θα φωνάζουν και θα φωνάζουν και θα κρατούν τις γραμμές υποστήριξής τους να ηχούν για μέρες.

Οι ΚΑΕ πρέπει επίσης να αντιμετωπίσουν τους μεταφορείς, τουλάχιστον σε μη ευρωπαϊκές αγορές. Οι πάροχοι δεν θέλουν οι πελάτες να έχουν προβλήματα με τις ενημερώσεις λογισμικού. Στην πραγματικότητα, οι πάροχοι συχνά προτιμούν να μην κυκλοφορούν ενημερώσεις λογισμικού.

Για να το καταλάβετε αυτό, φανταστείτε τη Μεγάλη Θεία σας Αλίκη. Είναι αυτή που σας τηλεφωνεί σε άβολες ώρες της ημέρας για να ζητήσει βοήθεια με "αυτό το θέμα του υπολογιστή". Στη συνέχεια περιγράφετε πώς να κάνετε κλικ στο "Μενού Έναρξη" και πρέπει να το αναγνωρίσετε ως "μεγάλη σημαία στην κάτω αριστερή γωνία" και αντιμετωπίζετε σύγχυση. Περίπου 45 λεπτά (και πολλή απογοήτευση) αργότερα, προκύπτει ότι η θεία Αλίκη έχει σύρει το μενού εκκίνησης στη δεξιά άκρη της οθόνης και απλά έπρεπε να το σύρει πίσω. Ναι, με το αριστερό κουμπί του ποντικιού!

Τώρα φανταστείτε ότι έχετε χίλια θεία Αλίκη». Όλοι τηλεφωνούν στην υποστήριξη πελατών σας, δεν μπορούν να βρουν το Candy Crush στο τηλέφωνό τους, ανησυχώντας ότι κάποιος χάκερ το διέγραψε από το τηλέφωνό τους. Α, και τα εικονίδια φαίνονται λίγο διαφορετικά τώρα - μήπως ο χάκερ είναι ακόμα στο τηλέφωνό του;

Ναι, αυτό προορίζεται να είναι λίγο ανάλαφρο χιούμορ, αλλά έως ότου αντιληφθείτε τους λόγους για τους οποίους οι άνθρωποι θα καλέσουν τον φορέα τους για υποστήριξη, δεν θα πιστεύετε τα προβλήματα που έχουν. Μια ενημέρωση λογισμικού που αλλάζει τον τρόπο λειτουργίας του τηλεφώνου ή το πού βρίσκονται τα πράγματα, θα προκαλέσει σημαντικό κόστος υποστήριξης. Τουλάχιστον, απαιτεί επανεκπαίδευση του προσωπικού υποστήριξης (επειδή, δυστυχώς, οι περισσότεροι από αυτούς δεν είναι μανιώδεις αναγνώστες XDA).

Μόλις ο OEM λάβει το BSP, θα μεταφέρει τη ROM του και θα εφαρμόσει όλες τις αλλαγές του στη ROM. Θα μαζέψουν τα σκεύη τους και θα προσθέσουν ένα φρικτό δέρμα σαν καρτούν που θα έμοιαζε περισσότερο σαν το σπίτι σε ένα εφηβικό Anime. Μετά θα το δοκιμάσουν.

Πολύ.

Υπάρχουν όλες οι απαιτήσεις με τις οποίες πρέπει να συμμορφώνεται το τηλέφωνό σας. Τα δίκτυα κινητής τηλεφωνίας έχουν σχεδιαστεί για να εμπιστεύονται τον εξοπλισμό χρήστη (αυτό που ονομάζουμε τηλέφωνο) να συμπεριφέρεται σωστά. Αυτό σημαίνει ότι απαιτούνται πολλές δοκιμές για την έγκριση της συσκευής. Οι ενημερώσεις λογισμικού κινδυνεύουν να αλλάξουν συμπεριφορές, επομένως τα πράγματα πρέπει να δοκιμαστούν ξανά. Αυτός είναι ο λόγος για τον οποίο θα βλέπετε συνήθως πληροφορίες σχετικά με τις επερχόμενες ενημερώσεις λογισμικού της Sony από εξωτερικές υπηρεσίες δοκιμών, οι οποίες επιβεβαιώνουν ότι το υλικολογισμικό συμμορφώνεται με τις απαιτήσεις δοκιμής.

Τώρα... τι συμβαίνει μετά από μια ή δύο ενημερώσεις (ή σε ορισμένες περιπτώσεις, καμία); Ο κατασκευαστής SoC δεν θα δώσει στον OEM ένα ενημερωμένο BSP. Εξάλλου, ο κατασκευαστής SoC δεν θα πάρει πολλά από αυτό. Το OEM δεν κερδίζει άλλα χρήματα στο τηλέφωνό σας από τότε που πουλήθηκε. Και σε αυτό το σημείο, το τηλέφωνό σας δεν λαμβάνει άλλες σημαντικές ενημερώσεις έκδοσης.

Η μείωση του αριθμού των BSP που θέλει να παραδώσει ο OEM είναι ένας πολύ καλός τρόπος για να εξοικονομήσετε χρήματα - εάν χρειάζεστε μόνο το τρέχον και δεν σκοπεύετε να παραδώσετε καμία κύρια έκδοση αυξάνεται, αυτό θα εξοικονομήσει χρήματα για την αρχική αγορά SoC και την άδεια χρήσης, αλλά σε βάρος μερικών θυμωμένων σπασίκλων στο XDA, που αναρωτιούνται γιατί δεν έλαβαν εκσυγχρονίζω.

Οι ενημερώσεις είναι πολύπλοκες. Υπάρχουν πολλοί διαφορετικοί άνθρωποι που εμπλέκονται στην αλυσίδα. Τίποτα από αυτά δεν δικαιολογεί τους OEM από την τρέχουσα ελλιπή και αξιολύπητη κατάσταση των ενημερώσεων στο Android. Ωστόσο, υπάρχουν ορισμένες πραγματικές προκλήσεις εδώ.

Πολλοί ΚΑΕ φταίνε για τις υπερβολικές υποσχέσεις, και το αναπόφευκτη υποπαροχή που τώρα συνδέουμε. Η θλιβερή πραγματικότητα είναι ότι για τους περισσότερους OEM, οι ενημερώσεις λογισμικού είναι απλώς μια ενόχληση που θα μπορούσαν να κάνουν χωρίς.

Ο τομέας των κινητών είναι κυρίως κολλημένος στη νοοτροπία των χαρακτηριστικών τηλεφώνων. Δηλαδή, όπου μια συσκευή δεν λαμβάνει ποτέ ενημερώσεις. Δοκιμάστε το μια φορά, στείλτε το και μην κοιτάξετε ποτέ πίσω. Με τα ζητήματα ασφαλείας των σύγχρονων smartphone και την απόλυτη πολυπλοκότητα της λειτουργίας ενός λειτουργικού συστήματος πλήρους γενικής χρήσης, με εκατοντάδες εξωτερικές βιβλιοθήκες, αυτό δεν αποτελεί πλέον επιλογή. Ή τουλάχιστον αυτό δεν θα έπρεπε είναι. Η Google έχει κάνει κάποια βήματα για να το διορθώσει, δημοσιεύοντας τουλάχιστον ενημερωτικά δελτία ασφαλείας και ενημερώσεις κώδικα για τις υπάρχουσες εκδόσεις του Android (θυμηθείτε ότι μέχρι πολύ πρόσφατα, ο μόνος τρόπος για να λαμβάνετε ενημερώσεις ασφαλείας ήταν μέσω μιας νέας μεγάλης έκδοσης λειτουργικού συστήματος Android!)

Δυστυχώς, όμως, αυτό δεν είναι πραγματικά αρκετό. Παρόλο που η Google συνεχίζει να εκδίδει ενημερώσεις, η ασφάλεια της συσκευής σας εξακολουθεί να εξαρτάται από τον κατασκευαστή SoC - καθώς οι κατασκευαστές SoC είναι τόσο απολιθωμένοι κάποιος ανακαλύπτοντας πώς ανάβει μερικά LED ή κάνει έναν ήχο μέσω ενός ηχείου, στέλνει τεράστιες ποσότητες δυαδικών σταγόνων στο συσκευές. Αυτές οι σταγόνες περιέχουν έναν αρκετά τρομακτικά ανασφαλή κώδικα (απλώς ρίξτε μια ματιά στα προηγούμενα δελτία ασφαλείας της Google αν νομίζετε ότι αυτό είναι υπερβολή!) και χρειάζεται ενημέρωση. Αυτό σημαίνει ότι απαιτούνται ενημερωμένα BSP.

Οι επιτραπέζιοι υπολογιστές (και κατ' επέκταση οι φορητοί υπολογιστές) είναι εντελώς διαφορετικοί στην αρχιτεκτονική από τις φορητές συσκευές. Το κινητό σας τηλέφωνο ή το tablet σας είναι ουσιαστικά ένα ιδιόκτητο κομμάτι πυριτίου, σχεδιασμένο βιαστικά από μερικούς ανθρώπους που τα λένε καλά, αλλά δεν έχουν αρκετό χρόνο για να φτιάξουν κάτι καλό. Η αγορά κινείται τόσο γρήγορα που μετά βίας είναι σε θέση να συμβαδίσουν με τον ρυθμό με τον οποίο το μάρκετινγκ απαιτεί την κυκλοφορία νέων προϊόντων.

Αυτό σημαίνει ότι έχουν ληφθεί συντομεύσεις - δεν θα βρείτε το τηλέφωνό σας να υποστηρίζεται από τον κύριο πυρήνα Linux και θα διαπιστώσετε ότι κάθε τηλέφωνο έχει διαφορετικό τρόπο εκκίνησης. Στον φορητό υπολογιστή ή τον επιτραπέζιο υπολογιστή σας, ωστόσο, οι προμηθευτές αρκέστηκαν σε ορισμένους τυπικούς τρόπους εκκίνησης - παλαιότερα ήταν MBR (κύριο αρχείο εκκίνησης) με BIOS και τώρα είναι UEFI. Αυτή η τυποποίηση καθιστά δυνατή την εκτέλεση του ίδιου λογισμικού σε κάθε συσκευή.

Ενώ πρόσφατα έγιναν κάποια βήματα προς αυτό, ειδικά με το πρόγραμμα προβολής της Sony και το δικό τους ενοποιημένος πυρήνας, δεν είναι πρακτικό να εκτελείτε έναν κεντρικό πυρήνα στα περισσότερα τηλέφωνα, λόγω του τεράστιου αριθμού νέων πειρατειών που εισάγονται για συγκεκριμένο προμηθευτή σε κάθε συσκευή.

Καλωδιώθηκε η υποδοχή ακουστικών με λάθος τρόπο; Απλά χακάρετε τα προγράμματα οδήγησης! Δεν υπάρχει χρόνος για να το διορθώσετε στο σχέδιο παραγωγής.

Η ομάδα κατασκευής έχει τοποθετήσει τη μονάδα κάμερας ανάποδα στην παρτίδα παραγωγής 1; Ρίξτε μια εισβολή για να ελέγξετε τον εσωτερικό κωδικό έκδοσης και γυρίστε το βίντεο αν είναι έκδοση 1!

Χακς όπως αυτές λύνουν το άμεσο πρόβλημα, αλλά μόνο ξύνουν την επιφάνεια των περίεργων και συγκεκριμένων αλλαγών που συμβαίνουν για το προϊόν. Καλό, υπάρχουν ακόμη και μερικές φορές εντελώς διαφορετικά τσιπ σε διαφορετικές εκδόσεις του ίδιου τηλεφώνου, λόγω εμπορικών αποφάσεων. Αυτά οδηγούν σε εισβολές σε προγράμματα οδήγησης και περίεργες αποφάσεις που είχαν νόημα μόνο εκείνη τη στιγμή, για να λειτουργήσει το τηλέφωνο ώστε να μπορεί να αποσταλεί την επόμενη εβδομάδα.

Ενώ συνεχίζεται η εργασία για την κύρια υποστήριξη για τσιπ ARM ​​64-bit για εκκίνηση μέσω UEFI, μέχρι στιγμής έχει γίνει καμία σαφής κίνηση προς έναν πιο τυποποιημένο τρόπο εκκίνησης συσκευών ARM. Και αυτό είναι λυπηρό, γιατί σημαίνει ότι τα τηλέφωνα θα συνεχίσουν να πετιούνται πολύ πριν το τέλος τους εργάζονται, γιατί απλώς είναι πολύ ακριβό να διατηρήσουν το τεχνικό χρέος και το βάρος τους λογισμικό.

Από την άλλη όμως, εάν ένας OEM θα κερδίσει χρήματα μόνο από την πώληση μιας συσκευής, δεν χρειάζεται να διασφαλίσει ότι οι άνθρωποι θα συνεχίσουν να αγοράζουν νέα τηλέφωνα; Θα μεταβαλλόταν η αγορά των υπολογιστών σε αυτό το μοντέλο εάν δεν υπήρχαν ήδη 30 χρόνια δυναμικής και παλαιού λογισμικού που χρησιμοποιεί την ανοιχτή πλατφόρμα και το πρότυπο υπολογιστή;

Αυτή είναι μια δύσκολη ερώτηση χωρίς εσωτερική γνώση από την Qualcomm, την οποία δυστυχώς δεν έχουμε αυτή τη στιγμή. Ωστόσο, μπορούμε να αντλήσουμε ορισμένες πληροφορίες από τις απαιτήσεις API του προγράμματος οδήγησης Android 7.0 και CTS. Οι απαιτήσεις CTS καθορίζουν τι περιμένει η Google από μια συσκευή που εκτελεί ένα δεδομένο υλικολογισμικό. Το "μεγάλο σφυρί" που χρησιμοποιείται για την επιβολή αυτών των απαιτήσεων είναι η άδεια χρήσης της Google για τη χρήση του αποκλειστικού πακέτου Υπηρεσιών Google Play - Εάν δεν συμμορφωθείτε, δεν μπορείτε να στείλετε τις Εφαρμογές Google στη συσκευή. Ενώ, για κάποιους, αυτό μπορεί να θεωρηθεί πλεονέκτημα, προφανώς αυτό δεν είναι αυτό που θέλουν και περιμένουν οι χρήστες από μια συσκευή.

Το Android 7.0 δεν έχει προσθέσει πολλά μέσω αλλαγών στο HAL ή στα προγράμματα οδήγησης (όπως περιγράφεται παραπάνω), επομένως οποιαδήποτε ασυμβατότητα είναι απίθανο να προέρχεται από εκεί συγκεκριμένα. Αυτό που είναι πιο πιθανό να δημιουργήσει ένα ζήτημα, ωστόσο, είναι η εισαγωγή του α νέα απαίτηση είτε για το API γραφικών Vulkan είτε για το GLES 3.1, να είναι διαθέσιμο για να περάσει το CTS.

Προς το παρόν, πολλά Systems-on-Chip (SoC) δεν έχουν υποστήριξη Vulkan στον επεξεργαστή γραφικών τους, συμπεριλαμβανομένου του MSM8974. Αυτό είναι επίσης πιθανότατα όπου θα προκύψει το ζήτημα της συμβατότητας με το Android 7.0. Και πάλι όμως, χωρίς εσωτερική γνώση από την Qualcomm και τα μελλοντικά της σχέδια, είναι δύσκολο για εμάς να δώσουμε μια οριστική δήλωση χωρίς να την επιβεβαιώσουμε. Προς το παρόν, ωστόσο, πιστεύουμε ότι είναι πιθανό ότι αυτή είναι η "απλή" περίπτωση της Qualcomm που διακόπτει την υποστήριξη για το γερασμένο (στα μάτια τους) chipset MSM8974 και δεν παρέχει BSP (πακέτο υποστήριξης πλακέτας) για 7.0 σε αυτήν την πλατφόρμα. Εάν συνέβαινε αυτό, θα σήμαινε ότι οι OEM θα ήταν σχεδόν βέβαιο ότι δεν θα αποστέλλουν το 7.0 στη συσκευή - θα έπρεπε να βρουν με κάποιο τρόπο υποστήριξη Vulkan ή GLEs 3.1 για τη GPU τους και την πηγή GPU Ο κώδικας είναι ένα από τα γελοία ερμητικά προστατευμένα μέρη των στοίβων κινητών (χωρίς πραγματικό λόγο, θα προσθέταμε - δείτε την AMD, ανοιχτή προμήθεια του δικού της προγράμματος οδήγησης AMDGPU στην επιφάνεια εργασίας για Linux). Δυστυχώς, ωστόσο, τα γραφικά Vulkan και τα επιταχυνόμενα (GLES) γραφικά γενικά είναι λίγο πιο περίπλοκα από ένα απλό LED, επομένως αυτό δεν είναι κάτι για το οποίο πρόκειται να δούμε να εισάγουμε συμβατότητα.

Καθώς το 7.0 δεν έχει κυκλοφορήσει για πολύ καιρό, υπάρχει πραγματική πιθανότητα να μείνουν άλλα chipset (εκτός από τον μικρό αριθμό εντός του ίδιου του 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 δεν υποστηρίζει πάντα το back-port γραφικών API - Το iPhone 4s και το iPhone 5 δεν διαθέτουν το Metal graphics API της Apple, το οποίο είναι κάπως παρόμοιο με αυτό που παρατηρείται με το Android στο Vulkan. Η μόνη διαφορά είναι ότι η Apple συνέχισε να υποστηρίζει τις παλαιότερες συσκευές χωρίς το νέο API γραφικών.

Τι νομίζετε; Θα αναβοσβήσετε μια προσαρμοσμένη ROM στο τηλέφωνό σας για να παρατείνετε τη διάρκεια ζωής του; Πείτε στα σχόλια παρακάτω.