Wie Android funktioniert, Teil 4

Hallo allerseits! Wir haben uns die Zeit genommen, eine Reihe von Artikeln über das interne Android-Gerät fortzusetzen. In diesem Artikel werde ich über den Android-Startvorgang, über den Inhalt des Dateisystems, über die Speicherung von Benutzer- und Anwendungsdaten, über den Root-Zugriff, über die Portabilität von Android-Builds und über das Fragmentierungsproblem sprechen.

Serienartikel:

• Wie Android funktioniert, Teil 1
• Wie Android funktioniert, Teil 2
• Wie Android funktioniert, Teil 3
• Wie Android funktioniert, Teil 4
• ...

Pakete

Wie ich bereits sagte, basiert die Android-Architektur auf Anwendungen. Es sind Anwendungen, die in vielen Teilen des Systems eine Schlüsselrolle im Gerät spielen. Für das harmonische Zusammenspiel von Anwendungen werden die Aktivitäts- und Absichtsmodelle erstellt, und das Android-Sicherheitsmodell basiert auf der Isolierung von Anwendungen. Wenn der Aktivitätsmanager die Interaktion von Anwendungskomponenten koordiniert, ist der Paketmanager für die Installation, Aktualisierung und Verwaltung der Anwendungsrechte verantwortlich (Paketmanager - Sie können ihn mit dem Befehl pm in der Shell aufrufen).

Wie der Name schon sagt, werden Anwendungen auf dieser Ebene häufig als Pakete bezeichnet . Pakete werden im APK- Format (Android-Paket) verteilt - spezielle Zip-Archive. Jedes Paket hat einen Namen (auch als Anwendungs-ID bezeichnet ), der diese Anwendung eindeutig identifiziert (jedoch nicht ihre spezifische Version - im Gegenteil, die Namen verschiedener Versionen des Pakets müssen übereinstimmen, andernfalls werden sie als separate Pakete betrachtet). Paketnamen werden normalerweise in Notation des umgekehrten DNS-Namens geschrieben. Beispielsweise verwendet die YouTube-Anwendung den Paketnamen com.google.android.youtube . Oft stimmt der Paketname mit dem in seinem Java-Code verwendeten Namespace überein, Android benötigt ihn jedoch nicht (außerdem enthalten die APK-Dateien der Anwendung normalerweise Bibliotheken von Drittanbietern, deren Namespace natürlich überhaupt nichts mit den Paketnamen zu tun hat. wer benutzt sie).

Jede APK während der Montage muss vom Entwickler mit einer digitalen Signatur signiert werden. Android prüft bei der Installation der Anwendung, ob diese Signatur vorhanden ist, und vergleicht beim Aktualisieren einer bereits installierten Anwendung zusätzlich die öffentlichen Schlüssel, mit denen die alte und die neue Version signiert sind. Sie müssen übereinstimmen, wodurch sichergestellt wird, dass die neue Version vom selben Entwickler wie die alte erstellt wurde. (Wenn diese Prüfung nicht verfügbar wäre, könnte der Angreifer ein Paket mit demselben Namen wie die vorhandene Anwendung erstellen, den Benutzer davon überzeugen, es durch „Aktualisieren“ der Anwendung zu installieren, und Zugriff auf die Daten dieser Anwendung erhalten.)

Das Update des Pakets selbst ist die Installation der neuen Version anstelle der alten unter Beibehaltung der vom Benutzer erhaltenen Daten und Berechtigungen. Sie können Anwendungen auch auf ältere Versionen herunterstufen. Gleichzeitig löscht Android jedoch standardmäßig die von der neuen Version gespeicherten Daten, da die alte Version möglicherweise nicht mit den von der neuen Version verwendeten Datenformaten arbeiten kann.

Wie bereits erwähnt, wird der Code jeder Anwendung normalerweise unter einem eigenen Unix-Benutzer (UID) ausgeführt, wodurch deren gegenseitige Isolation sichergestellt wird. Einige Anwendungen fordern Android möglicherweise ausdrücklich auf, eine gemeinsame UID für sie zu verwenden, mit der sie direkt auf die Dateien des jeweils anderen zugreifen und auf Wunsch sogar im selben Prozess ausgeführt werden können.

Obwohl normalerweise ein Paket einer APK-Datei entspricht, unterstützt Android Pakete, die aus mehreren APKs bestehen (dies wird als geteilte APKs oder geteilte APKs bezeichnet ). Dies ist die Grundlage für solche "magischen" Funktionen von Android, wie das dynamische Laden zusätzlicher Anwendungsmodule ( dynamische Funktionsmodule ) und die sofortige Ausführung in Android Studio (automatische Aktualisierung des laufenden Anwendungscodes ohne dessen vollständige Neuinstallation und in vielen Fällen sogar ohne Neustart).

Dateisystem

Das Dateisystemgerät ist eines der wichtigsten und interessantesten Probleme in der Architektur des Betriebssystems, und das Dateisystemgerät in Android ist keine Ausnahme.

Interessant ist zum einen, welche Dateisysteme verwendet werden, dh in welchem ​​Format der Inhalt der Dateien auf einer bedingten Festplatte gespeichert wird (bei Android sind dies normalerweise Flash-Speicher und SD-Karten) und wie der Kernel des Systems dieses Format unterstützt . Der in Android verwendete Linux-Kernel unterstützt bis zu dem einen oder anderen Grad eine große Anzahl verschiedener Dateisysteme - von denen, die in Windows FAT und NTFS verwendet werden, und denen, die in Darwin vom berüchtigten HFS + und modernen APFS verwendet werden - bis zu den 9pfs des Netzwerks aus Plan 9. Es gibt viele "native" »Für Linux-Dateisysteme - zum Beispiel Btrfs und die ext-Familie.

Der De-facto-Standard für Linux ist seit langem ext4 und wird standardmäßig von den meisten gängigen Linux-Distributionen verwendet. Daher ist die Tatsache, dass es in Android verwendet wird, nicht unerwartet. Einige Assemblys (und einige Enthusiasten) verwenden auch F2FS (Flash-Friendly File System), das speziell für Flash-Speicher optimiert wurde (mit seinen Vorteilen ist jedoch nicht alles so klar ).

Zweitens ist das sogenannte Dateisystem-Layout von Interesse - der Speicherort von System- und Benutzerordnern und -dateien im Dateisystem. Das Dateisystem-Layout unter „normalem Linux“ verdient eine detailliertere Beschreibung (die beispielsweise unter diesem Link zu finden ist ). Ich werde hier nur einige der wichtigsten Verzeichnisse erwähnen:

• /home speichert Benutzer-Home-Ordner; Hier speichern Programme in verschiedenen versteckten Ordnern ( .cache , .cache , .config und andere) ihre Einstellungen, Daten und den Cache, die für den Benutzer spezifisch sind.
• /boot speichert den Linux-Kernel und das initramfs-Image (spezielles Boot-Dateisystem).
• /usr (es wäre logischer, /system aufzurufen) speichert den Hauptteil des Systems selbst, einschließlich Bibliotheken, ausführbarer Dateien, Konfigurationsdateien sowie Ressourcen - Themen für die Benutzeroberfläche, Symbole, Inhalte des Systemhandbuchs usw.
• /etc (es wäre logischer, /config aufzurufen) speichert systemweite Einstellungen,
• /dev speichert Gerätedateien und andere spezielle Dateien (z. B. den Socket /dev/log ).
• /var speichert veränderbare Daten - Protokolle, Systemcache, Datenbankinhalte usw.

Android verwendet ein ähnliches, aber deutlich unterschiedliches Dateisystemlayout. Hier sind einige der wichtigsten Teile davon:

• /data speichert veränderbare Daten,
• Der Kernel und das initramfs-Image werden auf einer separaten Flash-Partition gespeichert, die nicht im Hauptdateisystem bereitgestellt werden kann.
• /system entspricht /usr und speichert das System,
• /vendor - ein Analogon von /system das für Dateien /system die für diese Android-Assembly spezifisch sind und nicht im "Standard" Android enthalten sind.
• /dev speichert wie unter "normalem Linux" Gerätedateien und andere spezielle Dateien.

Die interessantesten dieser Verzeichnisse sind /data und /system . Der Inhalt von /system beschreibt das System und enthält die meisten seiner Bestandteile. /system befindet sich in einem separaten Bereich des Flash-Speichers, der standardmäßig im schreibgeschützten Modus bereitgestellt wird. Normalerweise ändern sich die Daten nur, wenn das System aktualisiert wird. /data ebenfalls in einem separaten Abschnitt und beschreibt den veränderbaren Status eines bestimmten Geräts, einschließlich Benutzereinstellungen, installierter Anwendungen und deren Daten, Caches usw. Das Löschen aller Benutzerdaten, das sogenannte Zurücksetzen auf die Werkseinstellungen, mit diesem Schema dient lediglich zum Löschen des Inhalts des Datenabschnitts. Ein unberührtes System bleibt im Systemabschnitt installiert.

 # mount | grep /system /dev/block/mmcblk0p14 on /system type ext4 (ro,seclabel,relatime,data=ordered) # mount | grep /data /dev/block/mmcblk0p24 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,data=writeback) 

Anwendungen - nämlich APK, Odex-Dateien (vorab kompilierter Java-Code) und ELF-Bibliotheken - werden in /system/app (für mit dem System gelieferte Anwendungen) oder in /data/app (für vom Benutzer installierte Anwendungen) installiert Anwendungen). Beim Erstellen einer Android-Assembly wird jeder vorinstallierten Anwendung ein Ordner mit dem Namen des Formulars /system/app/Terminal zugewiesen. Für vom Benutzer installierte Anwendungen werden während der Installation Ordner erstellt, deren Namen mit ihrem Paketnamen beginnen. Beispielsweise wird eine YouTube-Anwendung in einem Ordner mit einem Namen wie /data/app/com.google.android.youtube-bkJAtUtbTuzvAioW-LEStg==/ .

 # pm path com.android.egg package:/system/app/EasterEgg/EasterEgg.apk 

Da vorinstallierte Anwendungen im Systemabschnitt gespeichert sind (deren Inhalt sich, wie ich Sie erinnere, nur ändert, wenn das System aktualisiert wird), können sie nicht gelöscht werden (stattdessen bietet Android die Möglichkeit, sie zu "deaktivieren"). Das Aktualisieren vorinstallierter Anwendungen wird jedoch unterstützt. In diesem Fall wird ein Ordner in /data/app für die neue Version erstellt, und die mit dem System gelieferte Version verbleibt in /system/app . In diesem Fall hat der Benutzer die Möglichkeit, Aktualisierungen einer solchen Anwendung zu "entfernen" und von /system/app zur Version zurückzukehren.

Ein weiteres Merkmal vorinstallierter Anwendungen besteht darin, dass sie spezielle Systemberechtigungen erhalten können. Beispielsweise erhalten Anwendungen von Drittanbietern nicht die DELETE_PACKAGES , mit der Sie andere Anwendungen entfernen können, REBOOT , mit der Sie das System neu starten können, und READ_FRAME_BUFFER , mit der Sie direkt auf den Inhalt des Bildschirms zugreifen können. Diese Berechtigungen haben eine Signaturschutzstufe, dh die Anwendung, die versucht, auf sie zuzugreifen, muss mit demselben Schlüssel signiert sein wie die Anwendung oder der Dienst, in dem sie implementiert sind. In diesem Fall, da diese Berechtigungen vom System implementiert werden, der Schlüssel, mit dem sie signiert sind Android Build

Um veränderbare Daten zu speichern, wird jeder Anwendung ein Ordner in /data/data zugewiesen (z. B. /data/data/com.google.android.youtube für YouTube). Nur die Anwendung selbst hat Zugriff auf diesen Ordner, dh nur die UID, unter der diese Anwendung gestartet wird (wenn die Anwendung mehrere UIDs verwendet oder wenn mehrere Anwendungen eine gemeinsame UID verwenden, kann alles komplizierter sein). In diesem Ordner speichern Anwendungen Einstellungen, Cache (in den Unterordnern shared_prefs bzw. cache ) und alle anderen benötigten Daten:

 # ls /data/data/com.google.android.youtube/ cache code_cache databases files lib no_backup shared_prefs # cat /data/data/com.google.android.youtube/shared_prefs/youtube.xml <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="user_account">username@gmail.com</string> <boolean name="h264_main_profile_supported7.1.2" value="true" /> <int name="last_manual_video_quality_selection_max" value="-2" /> <...> </map> 

Das System kennt die Existenz des cache Ordners und kann ihn selbst bereinigen, wenn nicht genügend Speicherplatz vorhanden ist. Wenn Sie die Anwendung deinstallieren, wird der gesamte Ordner dieser Anwendung vollständig gelöscht und die Anwendung hinterlässt keine Spuren. Alternativ können beide Benutzer in den Einstellungen explizit Folgendes tun:

Dieser jeder Anwendung zugewiesene Datenspeicher wird als interner Speicher bezeichnet.

Darüber hinaus verfügt Android über eine andere Art von Speicher - den sogenannten externen Speicher (externer Speicher - dieser Name spiegelt die ursprüngliche Idee wider, dass sich der externe Speicher auf einer externen SD-Karte befinden sollte, die in das Telefon eingelegt ist). Tatsächlich spielt der externe Speicher die Rolle des Basisordners des Benutzers. Dort befinden sich Ordner wie Dokumente, Download, Musik und Bilder. Der externe Speicher, den Dateimanager als Standardordner öffnen, ermöglicht dem Computer den Zugriff auf den Inhalt des externen Speichers, wenn eine Verbindung besteht per Kabel.

 # ls /sdcard Alarms Download Podcasts Android Movies Ringtones Books Music Subtitles DCIM Notifications bluetooth Documents Pictures 

Im Gegensatz zum internen Speicher, der in Ordner einzelner Anwendungen unterteilt ist, ist der externe Speicher eine „gemeinsame Zone“: Jede Anwendung, die vom Benutzer die entsprechende Berechtigung erhalten hat, hat vollen Zugriff darauf. Wie bereits in einem früheren Artikel erwähnt, sollten Anwendungen wie der Dateimanager diese Berechtigung anfordern. Für die meisten anderen Anwendungen ist es besser, die Absicht mit der Aktion ACTION_GET_CONTENT , damit der Benutzer die gewünschte Datei im Systemdateimanager auswählen kann.

Viele Anwendungen bevorzugen es, einige ihrer internen Dateien, die groß sind (z. B. einen Cache mit heruntergeladenen Bildern und Audiodateien), in einem externen Speicher zu speichern. Zu diesem Android/data/com.google.android.youtube weist Android Anwendungen in externen Speicherordnern Namen der Form Android/data/com.google.android.youtube . Die Anwendung selbst benötigt keine Berechtigung, um auf den gesamten externen Speicher zuzugreifen, um auf diesen Ordner zuzugreifen (da ihre UID als Eigentümer dieses Ordners festgelegt ist). Jede andere Anwendung mit dieser Berechtigung kann jedoch auf diesen Ordner zugreifen. Es lohnt sich also, sie zu verwenden Nur zum Speichern öffentlicher und unkritischer Daten. Wenn Sie die Anwendung deinstallieren, löscht das System seinen speziellen Ordner im externen Speicher. Dateien, die von Anwendungen in einem externen Speicher außerhalb ihres speziellen Ordners erstellt wurden, gehören jedoch dem Benutzer und bleiben nach dem Entfernen der Anwendung, die sie erstellt hat, an Ort und Stelle.

Wie oben erwähnt, wurde zunächst angenommen, dass sich der externe Speicher tatsächlich auf einer externen SD-Karte befindet, da zu diesem Zeitpunkt das Volumen der SD-Karten erheblich größer war als der in die Telefone integrierte Speicher (in HTC Dream waren es nur 256 Megabyte, davon Dem Datenabschnitt wurden ca. 90 Megabyte zugewiesen. Seitdem haben sich viele Bedingungen geändert; Moderne Telefone verfügen häufig nicht über einen SD-Kartensteckplatz, aber nach mobilen Standards ist eine große Menge an internem Speicher installiert (in Samsung Galaxy Note 9 können es beispielsweise bis zu 512 Gigabyte sein ).

Daher befinden sich in modernen Android-Geräten fast immer sowohl interner als auch externer Speicher im internen Speicher. Der reale Pfad, auf dem sich der externe Speicher im Dateisystem befindet, hat die Form /data/media/0 (für jeden Gerätebenutzer wird ein separater externer Speicher erstellt , und die Nummer im Pfad entspricht der Benutzernummer). Aus Kompatibilitätsgründen kann auf den externen Speicher auch über die /sdcard , /mnt/sdcard , /storage/self/primary , /storage/emulated/0 , mehrere Pfade, die mit /mnt/runtime/ , und einige andere Pfade zugegriffen werden.

Andererseits haben viele Geräte noch einen SD-Kartensteckplatz. Die in das Android-Gerät eingelegte SD-Karte kann als normales externes Laufwerk verwendet werden (ohne sie in einen internen oder externen Speicher des Systems umzuwandeln) - speichern Sie Dateien darauf, öffnen Sie die darauf gespeicherten Dateien, übertragen Sie damit Dateien auf andere Geräte usw. Darüber hinaus können Sie mit Android eine SD-Karte "ausleihen" und internen und externen Speicher darauf ablegen (dies wird als ausgeliehener Speicher bezeichnet - angenommener Speicher ). Gleichzeitig formatiert das System die SD-Karte neu und verschlüsselt ihren Inhalt. Die darauf gespeicherten Daten können nicht gelesen werden, indem sie an ein anderes Gerät angeschlossen werden.

Weitere Informationen hierzu finden Sie beispielsweise in diesem Beitrag und in der offiziellen Dokumentation für Anwendungsentwickler und Entwickler von Android-Assemblys .

Laden

Der traditionelle Ansatz zur Sicherheit von Computersystemen beschränkt sich auf den Schutz des Systems vor Softwareangriffen. Es wird angenommen, dass ein Angreifer, der physischen Zugriff auf einen Computer hat, bereits verloren ist : Er kann vollen Zugriff auf alle darauf gespeicherten Daten erhalten. Dazu reicht es ihm beispielsweise aus, auf diesem Computer ein beliebiges von ihm gesteuertes Betriebssystem auszuführen, um die durch das "Haupt" -Rechtssystem auferlegten Einschränkungen zu umgehen oder die Datenplatte direkt mit einem anderen Gerät zu verbinden. Falls gewünscht, kann ein Angreifer den Computer betriebsbereit lassen, aber das darauf installierte System patchen, beliebige Hintertüren, Keylogger usw. installieren.

Es ist der Schutz vor Softwareangriffen, der sich auf das Modell der Einschränkung von Benutzerrechten unter Unix (und die darauf basierende App-Sandbox-Technologie in Android) konzentriert. Die Unix-Einschränkung an sich schützt das System nicht vor einem Benutzer, der den Weg zum Serverraum gefunden und physischen Zugriff auf den Computer erhalten hat. Und wenn seriöse Mehrbenutzerserver vor unbefugtem physischen Zugriff auf PCs - und insbesondere auf mobile Geräte - geschützt werden können und sollten, ist dieser Ansatz einfach nicht anwendbar.

Es gibt zwei Möglichkeiten, um die Situation durch Schutz vor einem Angreifer zu verbessern, der physischen Zugriff auf das Gerät erhalten hat:

• Erstens ist es möglich, auf einer Festplatte gespeicherte Daten zu verschlüsseln , wodurch verhindert wird , dass ein Angreifer Zugriff auf die Daten selbst erhält, selbst wenn er Zugriff auf den Inhalt der Festplatte hat.
• Zweitens ist es möglich, die Fähigkeit zum Laden beliebiger Betriebssysteme auf das Gerät irgendwie einzuschränken und einen Angreifer zu zwingen, Authentifizierungs- und Autorisierungsverfahren im installierten System durchzuführen.

Mit diesen beiden Schutzbereichen ist das sichere Startmodell in Android verbunden.

Verifizierter Start

Der Android-Startvorgang ist so konzipiert, dass Angreifer einerseits kein beliebiges Betriebssystem auf das Gerät herunterladen können, andererseits Benutzer benutzerdefinierte Android-Assemblys (und andere Systeme) installieren können.

Erstens erlauben Android-Geräte im Gegensatz zu „Desktop“ -Computern normalerweise nicht, dass ein Benutzer (oder ein Angreifer) von einem externen Medium startet. Stattdessen wird der auf dem Gerät installierte Bootloader (Bootloader) sofort gestartet. Bootloader ist ein relativ einfaches Programm, dessen Aufgaben (beim Laden im normalen Modus) Folgendes umfassen:

• Initialisierung und Konfiguration der vertrauenswürdigen Ausführungsumgebung (z. B. ARM TrustZone),
• Suchen von Partitionen des internen Speichers, in denen Linux-Kernel-Images und initramfs gespeichert sind,
• (integrity) — — ,
• initramfs .

Flashing, unlocking, fastboot recovery

, bootloader .

-, (Android) , recovery . recovery, Android- , , Android recovery .

«» bootloader', — ( flashing ) . bootloader , fastboot mode ( bootloader mode), bootloader' fastboot ( fastboot Android SDK ).

bootloader' . , Samsung, bootloader'a (Loke) (Odin). Odin Samsung ( Odin), Heimdall .

bootloader' ( ), recovery Android, , :

 $ fastboot flash recovery recovery.img $ fastboot flash boot boot.img $ fastboot flash system system.img 

; : , , bootloader' Android, , , , .

, bootloader' (unlocking the bootloader, OEM unlock) — bootloader' recovery, ( ). Android, LineageOS ( CyanogenMod ), Paranoid Android , AOKP , OmniROM .

bootloader' - , ( data ) . , , (, Google ), — , .

recovery bootloader , .

bootloader' :

recovery, «» (flashaholics) — TWRP (Team Win Recovery Project). - «», zip-, :

Android ( file-based encryption ). ext4 , Linux ( fscrypt ), .

, data , , (credential encrypted storage). , , . , , .

credential encrypted storage Android device encrypted storage — , ( Trusted Execution Environment). , , , . , Direct Boot : ; ( ) device encrypted storage, , . , Direct Boot , , - .

Root

root- — « root» (UID 0, ). , root — Unix-, — — , .

, Android , root- . , « », Android « », root- «», :

• — , APK ,
• : -, email-, , , , , , ( activity intent', ),
• (icon packs),
• , ,
• ( Android-) ,
• , Android, .

, , , root- . root- ( ), Android root . , , Unix-; shell, adb shell , Unix- shell .

, , root :

• -, root- Android — Android Studio QEMU, .
• -, root- Android ( pre-rooted ROMs).
• -, bootloader' root- Android , , su , bootloader.
• , -, , , root-, ( root- ). , 2016 , root- Dirty Cow .

? , root- . , root-, , , . — , . , , system ( ).

, root- — , .

root-

With great power comes great responsibility.

, . , root- .

, , . , root- , , , root- . root, , , , — , , , ..

, Unix, Android , — . root- , , . , root- Android, .

, , root- , . , , , , , . , — , Google Pay ( Android Pay) — root- , .

, - Pokémon GO root- , , .

Google Play root-

Google Google Play Store Google Play Services , root- , Android , , , , . Play Store — ( , ) Android, . ( — , Amazon Android Fire OS — Echo, Fire TV, Fire Phone, Kindle Fire Tablet — Google). root- Android-.

, Google , root-, Google Play ( Open GApps ); Google , .

Device manufacturers work with Google to certify that Android devices with Google apps installed are secure and will run apps correctly. To be certified, a device must pass Android compatibility tests. If you are unable to add a Google Account on your Android device, your Android device software might not have passed Android compatibility tests, or the device manufacturer has not submitted the results to Google to seek approval. As a result, your device is uncertified. This means that your device might not be secure.

If you are a User wanting to use custom ROMs on your device, please register your device by submitting your Google Services Framework Android ID below.

root

«» Linux, Unix-, root- ( sudo su ) ( , Unix- root, ) (, ). , root-.

su Android Open Source Project , Unix- shell ( root), root-. su , , , .

, su . su , root-. , SuperSU ; Magisk .

Magisk

Magisk — , , /system , system ( systemless-ly ), «» Linux . Magisk Hide — root-, root- Magisk — - Google Pay, root- . Magisk Hide root-, SafetyNet Google.

, , Google Pay root- — root- . , root-, - Google Pay. , .

Magisk systemless- «» Magisk Modules , Magisk. , , root- Xposed ViPER , .

SoC,

, «», , — , — (, Wi-Fi ).

, Android- (system on a chip, SoC). — , , -, , LTE-, Bluetooth- Wi-Fi- .. — . , , , , , .

, , . , «», , , , . , , -, , , , .

— Android — SoC . , , — LTE- — . , ; , , .

SoC (, Qualcomm) Android- (, Sony LG), Android, Android Open Source Project. , Android, , , .

Android Android-. , Android. Android , , . .

, : Android — , . Android, .

, , , Android. .

-, . , . , , , , .

-, Android — developer experience (DX, user experience/UX). , Android, API — Android Framework, OpenGL/Vulkan — . , , , Android — , , .

Don't Stop Thinking About Tomorrow

Android- . , Google Nexus Pixel , Android. Android , , , .

, , Android, SoC. Android «» (, , Android-x86 RemixOS ). Android ChromeOS, Chromebook' Android- Linux- -. — Android — Anbox , Android- «» Linux-. (, Android- x86-, , Java, .)

, Android — , Android .

— Android. , , . , , Android .

. 2017 Google Project Treble — , ( HAL, hardware abstraction layer) ( , ) . Treble , , , — — .

Treble . Treble (Sony, Nokia, OnePlus, Oppo, Xiaomi, Essential Vivo — Google) - Android Pie. Treble Essential Android Pie Essential Phone Android Pie. Android — - — , Treble, , SoC.

Treble . Java «write once, run everywhere» — Android- . Treble — , Android SoC. , , Treble. , Android- .

userspace Android: init, Zygote, Binder, props.