APEX στο Android Q: Το μεγαλύτερο πράγμα από το Project Treble;

Η εφαρμογή του APEX είναι ίσως ο μεγαλύτερος πονοκέφαλος που έχει αντιμετωπίσει η Google από την εισαγωγή του Project Treble. Τι είναι το APEX και πώς θα αλλάξει το Android η εισαγωγή του;

Η ιδέα πίσω από το APEX από μόνη της είναι μάλλον κοινή στις καθημερινές διανομές GNU/Linux: ενημερώσεις πακέτων που στοχεύουν συγκεκριμένα τμήματα του συνόλου βιβλιοθηκών Linux. Αλλά αυτό είναι κάτι που η Google δεν προσπάθησε ποτέ να κάνει, δεδομένου ότι το Android έχει χρησιμοποιήσει ένα διαμέρισμα RO (μόνο για ανάγνωση) όπου όλες οι βιβλιοθήκες συστήματος και Τα πλαίσια αποθηκεύονται έναντι των συνηθισμένων κατατμήσεων RW (read-write) που χρησιμοποιούνται στις περισσότερες διανομές Linux, αποδίδοντας την τυπική διαδικασία αναβάθμισης ακατάλληλος.

Οι βιβλιοθήκες είναι προμεταγλωττισμένος κώδικας που μπορεί να χρησιμοποιηθεί σε άλλα προγράμματα. Οι κοινώς χρησιμοποιούμενες μέθοδοι μπορούν να μετατραπούν σε βιβλιοθήκες για κλήση εφαρμογών Android, μειώνοντας το μέγεθος των APK, καθώς ο ίδιος κώδικας δεν θα χρειαστεί να εφαρμοστεί ξανά σε πολλές εφαρμογές. Μπορείτε να βρείτε πολλές προεγκατεστημένες βιβλιοθήκες συστήματος στους καταλόγους /system/lib και /system/lib64. Οι βιβλιοθήκες συστημάτων Android συνήθως δεν ενημερώνονται μεμονωμένα — αντίθετα, ενημερώνονται ως μέρος των αναβαθμίσεων πλατφορμών Android μέσω μιας ενημέρωσης OTA. Από την άλλη πλευρά, οι βιβλιοθήκες σε διανομές Linux μπορούν να ενημερώνονται μεμονωμένα. Με την εισαγωγή του APEX, οι βιβλιοθήκες συστήματος στο Android μπορούν να ενημερώνονται μεμονωμένα όπως οι εφαρμογές Android. Το κύριο πλεονέκτημα αυτού είναι ότι οι προγραμματιστές εφαρμογών θα μπορούν να επωφεληθούν από τις ενημερωμένες βιβλιοθήκες χωρίς να περιμένουν έναν OEM να κυκλοφορήσει μια πλήρη αναβάθμιση συστήματος. Ας δούμε περισσότερες τεχνικές λεπτομέρειες σχετικά με τον τρόπο λειτουργίας του APEX.

Πώς θα αλλάξει το APEX τον τρόπο ενημέρωσης των βιβλιοθηκών;

Το APEX είναι ένα οικοσύστημα που ανάγκασε (ή μάλλον, αναγκάζει) την Google να επανεξετάσει τον τρόπο με τον οποίο το Android φορτώνει όλες τις βιβλιοθήκες και τα αρχεία από ένα μη τυπικό διαμέρισμα διαφορετικό από το /system.

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

Το Android έχει διαμορφώσει ιστορικά τη διαδρομή της βιβλιοθήκης (γνωστή ως LD_LIBRARY_PATH στον κόσμο του Linux) με ένα μόνο αρχείο ονομάζεται ld.config.txt [0] για να διαμορφώσει τις επιτρεπόμενες διαδρομές αναζήτησης για τις κοινόχρηστες βιβλιοθήκες που χρειάζονται είτε δυαδική είτε άλλη βιβλιοθήκη. Αυτές οι διαδρομές είναι κωδικοποιημένες στη διαμόρφωση και δεν είναι επεκτάσιμες. Αυτή η διάταξη, συμπεριλαμβανομένου του διαμερίσματος συστήματος μόνο για ανάγνωση, οδηγεί σε βιβλιοθήκες που δεν μπορούν να ενημερωθούν, εκτός εάν ο χρήστης εγκαταστήσει μια ενημέρωση Android OTA. Η Google διόρθωσε αυτό το πρόβλημα επιτρέποντας την επέκταση της διαδρομής αναζήτησης αφήνοντας τα μεμονωμένα πακέτα APEX να παρέχουν το δικό τους ld.config.txt που περιλάμβανε τις επιπλέον (και ενημερωμένες) διαδρομές βιβλιοθηκών που περιέχονται σε αυτά.

Ενώ αυτή η κίνηση διόρθωσε ένα από τα κύρια ζητήματα, υπήρχαν ακόμη μερικά σοβαρά ζητήματα που έπρεπε να ξεπεραστούν. Πρώτα απ 'όλα: σταθερότητα ABI (δυαδική διεπαφή εφαρμογής). Οι βιβλιοθήκες πρέπει πάντα να εξάγουν ένα σταθερό σύνολο διεπαφών για να επιτρέπουν σε άλλες εφαρμογές και βιβλιοθήκες να συνεχίσουν να λειτουργούν με το ίδιο πρωτόκολλο ακόμη και με την αναβαθμισμένη βιβλιοθήκη. Η Google εργάζεται ενεργά σε αυτό προσπαθώντας να δημιουργήσει μια σταθερή διεπαφή C μεταξύ βιβλιοθηκών με APEX.

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

Ακολουθούν μερικά παραδείγματα των τρεχόντων πακέτων APEX που παρέχονται από την AOSP:

• com.android.runtime: ART και bionic runtime (δυαδικά και βιβλιοθήκες)
• com.android.tzdata: Δεδομένα TimeZone και ICU (βιβλιοθήκες και δεδομένα διαμόρφωσης)
• com.android.resolv: Βιβλιοθήκη που χρησιμοποιείται από το Android για την επίλυση αιτημάτων που σχετίζονται με το δίκτυο (βιβλιοθήκες)
• com.android.conscrypt: Ένας πάροχος ασφάλειας Java (πλαίσιο Java)

Πώς εγκαθίσταται και δομείται ένα πακέτο APEX;

Ένα πακέτο APEX είναι ένα απλό αρχείο zip (όπως ένα APK) που μπορεί να εγκατασταθεί από το εύχρηστο ADB μας (σε αυτό το σημείο ανάπτυξης) και, αργότερα, από τον ίδιο τον χρήστη μέσω ενός διαχειριστή πακέτων (όπως το Google Play ή χειροκίνητα μέσω του πακέτου Android εγκαταστάτης).

Η διάταξη ZIP είναι η εξής:

Ας βουτήξουμε σε αυτό.

Το apex_manifest.json καθορίζει το όνομα και την έκδοση του πακέτου.

Το apex_payload.img είναι μια εικόνα μικροσυστήματος αρχείων (μορφοποιημένη ως EXT4).

Τα άλλα αρχεία αποτελούν μέρος της διαδικασίας επαλήθευσης που χρησιμοποιείται για την εγκατάσταση του πακέτου. Ας ρίξουμε μια ματιά.

Η παρουσία του AndroidManifest.xml, ακόμα κι αν χρησιμοποιείται κυρίως σε εφαρμογές, μας βοηθά να κατανοήσουμε ότι το μεγαλύτερο μέρος της υλοποίησης που χρησιμοποιείται για μια τυπική εγκατάσταση APK επαναχρησιμοποιείται ακόμη και για αυτά τα πακέτα. Στην πραγματικότητα, μόνο η επέκταση ελέγχεται για να γίνει διάκριση μεταξύ τους.

ο META-INF/ κατάλογος έχει το πιστοποιητικό πακέτου και χρησιμοποιεί τον ίδιο μηχανισμό με τα κανονικά APK. Αυτά τα πακέτα λοιπόν επαληθεύονται από ένα ζεύγος ιδιωτικού/δημόσιου κλειδιού κατά το χρόνο εκτέλεσης προτού επιτραπεί στον χρήστη να εγκαταστήσει μια ενημέρωση. Αλλά αυτό δεν ήταν αρκετό για την Google, έτσι πρόσθεσε 2 ακόμη επίπεδα ασφάλειας. Χρησιμοποιούν dm-verity για να ελέγξουν την ακεραιότητα της εικόνας και επαληθεύσεις AVB (Android Verified Boot) για να βεβαιωθούν ότι η εικόνα προέρχεται από αξιόπιστη πηγή. Στη χειρότερη περίπτωση, το πακέτο APEX θα απορριφθεί.

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

Πώς εγκαθίσταται μια εικόνα κατά την εκκίνηση;

Ας ξεκινήσουμε ρίχνοντας μια ματιά στα APEX που είναι εγκατεστημένα αυτήν τη στιγμή στη συσκευή μου (εξομοιωτής)

Όπως μπορείτε να δείτε, τα προεγκατεστημένα πακέτα αποθηκεύονται στο /system/apex/ και όλα αυτά βρίσκονται αυτήν τη στιγμή στην έκδοση με αριθμό 1. Τι συμβαίνει όμως όταν ενεργοποιείται ένα APEX; Θα χρησιμοποιήσουμε ξανά το com.android.tzdata ως παράδειγμα.

Ας επανεκκινήσουμε τη συσκευή και ας αναλύσουμε το logcat.

Οι πρώτες 2 γραμμές παρέχουν αρκετές πληροφορίες για να κατανοήσετε την προέλευση του πακέτου και πού πρόκειται να βρίσκεται εγκατεστημένο: /apex/, ένας νέος κατάλογος που εισήχθη στο Android Q που θα χρησιμοποιηθεί για την αποθήκευση των ενεργοποιημένων πακέτα.

Αφού επαληθευτεί επιτυχώς το πακέτο με το AVB και το δημόσιο κλειδί ταιριάζει, το APEX προσαρτάται χρησιμοποιώντας μια συσκευή βρόχου στο /dev/block/loop0, καθιστώντας το σύστημα αρχείων EXT4 προσβάσιμο στο σύστημα. Μια συσκευή βρόχου είναι μια ψευδο-συσκευή που κάνει ένα αρχείο προσβάσιμο ως συσκευή μπλοκ, καθιστώντας τα περιεχόμενα αυτού του αρχείου προσβάσιμα ως σημείο προσάρτησης.

Σε αυτό το σημείο, το APEX εξακολουθεί να μην χρησιμοποιείται λόγω του επιθέματος @1 (που υποδηλώνει την έκδοση του πακέτου). Για να ενημερωθεί τελικά το σύστημα ότι το πακέτο μας έχει ενεργοποιηθεί με επιτυχία, θα προσαρτηθεί στο /apex/com.android.tzdata όπου το Android αναμένει ενεργά το tzdata. Μια προσάρτηση bind επικαλύπτει έναν υπάρχοντα κατάλογο ή αρχείο σε διαφορετικό σημείο. [1]

Η υλοποίηση APEX περιέχεται εξ ολοκλήρου σε ένα ενιαίο χώρο αποθήκευσης στο AOSP. [2] Ο κατάλογος apexd (APEX daemon) έχει τον κωδικό που εκτελείται σε Android. Ο κατάλογος apexer έχει τον κώδικα που χρησιμοποιείται από το σύστημα κατασκευής για τη δημιουργία των πακέτων APEX.

Ποιος είναι ο σκοπός;

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

Όλες οι συσκευές θα υποστηρίζουν το APEX;

Όχι. Για παράδειγμα, το apexd απαιτεί το /data/apex να είναι διαθέσιμο αμέσως μετά την εκκίνηση για ενημέρωση όλων των λειτουργικών μονάδων Android. Με το FDE (Κρυπτογράφηση πλήρους δίσκου), το /data/apex κρυπτογραφείται μέχρι να ξεκλειδωθεί η συσκευή από τον χρήστη, καθιστώντας το APEX βασικά άχρηστο καθώς μόνο οι παραλλαγές APEX του συστήματος θα φορτωθούν κατά την εκκίνηση. Εκτός από αυτό, όλες οι συσκευές θα πρέπει να υποστηρίζουν APEX, αλλά χρειάζονται μερικές ενημερώσεις κώδικα πυρήνα (πολλές από τις οποίες είναι διορθώσεις που βρέθηκαν από την Google κατά την αναπαραγωγή με συσκευές βρόχου). [3] [4]

---

Πηγές [0], [1], [2], [3], [4]