Wie verwende ich Android SDK und Smartphone-Anbietertools, um einen anderen Kernel zu booten?

Question

Ich habe bei der Suche nach einer Lösung einige Fortschritte gemacht:

1) Alle Benutzerdaten von den für Experimente zu verwendenden Geräten gelöscht (Booten im Wiederherstellungsmodus > Cache löschen / Daten löschen / Werksreset)

2) Inoffizielle Quellen durchgesehen

Es gibt im Internet eine Reihe von Artikeln und Forenbeiträgen. Einige davon sind nützlich. Die meisten sind ziemlich alt und wurden zuletzt vor langer Zeit aktualisiert. Das Schlimme ist, dass die meisten davon Informationen zum Rooten der Geräte enthalten (d. h. zum Brechen der Betriebssystemsicherheit durch absichtliches Installieren eines Rootkits, das eine bekannte Sicherheitslücke ausnutzt, um seine Berechtigungen zu erhöhen) und Links zu nicht vertrauenswürdigen/wenig seriösen Skripten, die solche Rootkits enthalten. Diese potenziell schädlichen Informationen werden mit nützlichen Teilen vermischt, die einen allgemeinen Überblick über die verfügbaren Optionen geben.

Viele Artikel werden auf der Website xda-developers.com veröffentlicht.ForumAbschnitt undWiki.

Einige nützliche Wiki-Artikel:

Diese Wiki-Artikel werden im Allgemeinen eher schlecht gepflegt (die letzten Änderungen erfolgten im Jahr 2015).

3) Wählen Sie die Plattform (x86, ASUS Zenfone2)

In meinem Fall habe ich aus einem Pool meiner eigenen gebrauchten Android-Geräte ausgewählt. Die meisten davon haben ARM-basierte CPUs. Das neueste und leistungsstärkste war ASUS mit x86 Intel CPU (64-Bit-Befehlssatz). Der andere Grund für die Wahl von x86 war die bessere Linux-Unterstützung und die Anforderung, x86/AMD64-basierte lxc-Container auszuführen. Die Wahl von ARM würde die Entwicklung eines separaten Containerzweigs oder die Verwendung einer Art Emulations-/Konvertierungstools erfordern (ich bin nicht sicher, ob solche Tools effizient/gut gewartet/unterstützt sind).

4) Mir wurde klar, dass das Ziel mit offiziellen (vom Hersteller unterstützten) Tools möglicherweise nicht erreichbar ist

Ich habe dem technischen Support von ASUS eine E-Mail bezüglich der Verwendung ihres Tools zum Entsperren des Bootloaders geschickt. Die Antwort war jedoch einfach: „Das Tool entsperrt nur den Bootloader. Wir können Ihnen bei weiteren Schritten nicht helfen und Ihnen nicht einmal sagen, was passiert, wenn Sie das Tool verwenden.“ Das Tool ist also nutzlos (ich weiß nicht einmal, ob es in meinem Fall irgendwie funktioniert hat und worin es sich von unterscheidet fastboot oem unlock). Um das Tool zu aktivieren, musste ich zunächst auf Android 5.0 downgraden, da es in neueren ROM-Versionen nicht unterstützt wurde. Alle Dinge, die das Ändern des Bootloaders und das Booten anderer Images betreffen, sind inoffiziell, werden nicht unterstützt, nicht empfohlen, verfallen gegen die Garantie usw.

5) [OPTIONAL: HINWEIS 1] Wiederherstellung ausgewählt und installiert (wird vom Telefon- oder Betriebssystemanbieter nicht offiziell unterstützt)

'Erholung'- ist ein Android-Jargon für Bootloader/BIOS (eine separate Partition im Gerätespeicher, die ein leichtes Linux-basiertes System enthält, das zuerst bootet und ein Bootloader-Menü mit verfügbaren Tools wie „Backup“, „Cache löschen“, „Werksreset“, „Benutzerdefiniertes ROM laden“ usw. präsentiert. Die ursprüngliche OEM-Wiederherstellung erlaubt weder das Flashen von benutzerdefiniertem ROM noch das Booten eines benutzerdefinierten Betriebssystems.

Das Projekt scheint ausgereift, gut strukturiert, wird aktiv gepflegt und macht insgesamt den Eindruck eines wertvollen globalen Open-Source-Projekts. Die Anzahl der unterstützten Geräte und Hersteller ist sehrbemerkenswert. Natürlich würde ich es vorziehen, die Wiederherstellungsversion zu verwenden, die vom Telefonhersteller verwaltet und empfohlen und von dessen offizieller Website heruntergeladen wird (in meinem Fall ASUS).

ANMERKUNG 1:Nachdem ich TWRP installiert und weitere Informationen zu den SDK-Tools erhalten hatte, wurde mir klar, dass es wahrscheinlich möglich war, ein benutzerdefiniertes ROM zu flashen, ohne eine benutzerdefinierte Wiederherstellung zu installieren (indem ich die ADB- und Fastboot-Tools aus dem SDK-Plattform-Tools-Paket verwendete).

ANMERKUNG 2:Der Installationsvorgang ist für jedes Modell gut dokumentiert. Ich habe die „Fastboot-Installationsmethode“ verwendet. Kurze Beschreibung der Methode (siehe bitte die für Ihr Gerät relevante Seite der TWRP-Site): 1) Installieren Sie die Android SDK-Tools (Sie benötigen nur ADB- und Fastboot-Komponenten aus dem Platform-Tools-Paket), 2) Aktivieren Sie den „Entwicklermodus“ auf Ihrem Gerät, indem Sie 7-mal auf die Zeile „Buildnummer“ im Menü „Einstellungen“ > „Info“ tippen. 3) Aktivieren Sie unter „Einstellungen“ > „Entwickleroptionen“ „USB-Debugging“. 4) Stellen Sie über USB eine Verbindung mit Ihrem PC her. 5) Sie können auf Ihrem PC durch Eingabe des Befehls überprüfen, ob das Gerät verbunden ist. adb devices6) Ausführen, adb reboot bootloaderum in den Fastboot-Modus zu wechseln. 7) Legen Sie die richtige Image-Datei, die Sie von der TWRP-Site heruntergeladen und in „twrp.img“ umbenannt haben, in den Ordner mit den ADB- und Fastboot-Binärdateien (normalerweise der Ordner „Platform-Tools“). 8) Führen Sie aus fastboot flash recovery twrp.img.In meinem Fall wurde das Image erfolgreich geflasht, obwohl adb einen Fehler gemeldet hatFAILED (remote: Permission denied), 9) Ausführen fastboot reboot. Sie können Ihr Gerät auch über das TWRP-Menü neu starten. Wichtig ist, dass TWRP Ihr Stock-ROM (Partition mit Android-Betriebssystem) patcht, um zu verhindern, dass TWRP gelöscht und nach dem Booten durch die Stock-Wiederherstellung ersetzt wird. Andernfalls müssen Sie den Vorgang wiederholen. Ja, das war beängstigend, daher Schritt Nr. 1.

6) Eintauchen in die offizielle AOSP-Dokumentation

Nachdem ich die Hoffnung aufgegeben hatte, mit einem Black-Box-Ansatz für das Android-Betriebssystem mein Ziel zu erreichen, begann ich, allgemeine Abschnitte zur Architektur des Android-Betriebssystems und zu den Anforderungen an unterstützte Geräte durchzusehen.

Gute Bilder (Architektur):

Bootloader und Sicherheitsinfo:

Wichtigste Schlussfolgerung:Android hat definitiv nützliche Betriebssystemfunktionen eingeführt, um einen reduzierten Linux-Kernel auf einer Vielzahl proprietärer (FMCG-Welt) Geräte mit lockeren Hardwarestandards auszuführen. Eine der nützlichsten Funktionen, die von Mainstream-Linux übernommen werden könnte und wahrscheinlich auch sollte, ist die HAL-Abstraktionsschicht, die es ermöglicht, mit dem Zoo der proprietären Treiber auf vernünftige Weise umzugehen. Bemerkenswert sind auch die modulare Kernel-Sache mit der Aufteilung des Kernels in SoC-abhängige und Board-abhängige Teile, Energiesparfunktionen und Sicherheitsfunktionen.

Gute Nachrichten:Linux-Kernel-Entwickler undmancheDie Distributionsanbieter sind sich all dieser guten Aspekte bewusst und tun ihr Bestes, um die entsprechenden Änderungen einzuführen. Offizielle Statistiken (siehe Abbildung 2 derentsprechender AOSP-Dokumentabschnitt) zeigen deutliche Anzeichen für eine Konvergenz zwischen AOSP-Code und Mainstream-Linux. Die Konvergenz hat für beide Seiten (AOSP- und Linux-Community) eindeutig positive wirtschaftliche Auswirkungen. Wenn es um Interessenvertreter wie Google und Hardwarehersteller geht, die ihre Investitionen schützen, scheinen sie in die entgegengesetzte Richtung zu ziehen. Google schützt seine Investitionen in das Ökosystem und die Benutzerbasis, Hardwarehersteller schützen ihre Investitionen in die Entwicklung und Produktion von High-End-Hardware. Die Reibung zwischen diesen beiden Kräften erzeugt eine Art positiven Vektor. Meiner Meinung nach sollte es eine Art Vereinbarung zwischen Google und Hardwareherstellern geben, die diese Reibung auf sinnvolle Weise regelt. Beispielsweise könnten Hardwarehersteller die Einbindung ihrer kartenspezifischen Treiber-Blobs in den Linux-Kernel um etwa 2-3 Jahre verzögern (für SoC-spezifische Treiber-Blobs sollte dieser Zeitraum vielleicht kürzer sein). Dies würde Google und den AOSP-Entwicklern garantieren, dass das Android-Ökosystem die ganze Sahne vom Markt abschöpft (alle Käufe neuer moderner High-End-Hardwaregeräte, Werbeeinnahmen, kostenpflichtige Software und Dienste von High-End-Benutzern). Nach diesen 2-3 Jahren werden die Geräte (die nicht mehr als High-End-Geräte gelten) freigegeben, indem die Treiber-Blobs in Linux integriert werden (die hochwertigsten Hardware-Anbieter würden natürlich lieber den Quellcode bereitstellen). Die Länge dieses Zeitraums entspricht ziemlich genau der üblichen Garantiezeit, die von den Hardware-Anbietern für die meisten Geräte festgelegt wird, und einem Zeitraum, in dem diese Anbieter offizielle Android-Updates (einschließlich Sicherheitsupdates) verteilen. Das ist fair genug.

Schlechte Nachrichten:Es scheint wirklich schwierig zu sein, einen solchen Deal auszuhandeln(im Folgenden „der Deal“)auf kluge und explizite Weise. Das Hauptproblem ist sein globaler Charakter. Denken Sie an die möglichen rechtlichen Aspekte (Kartellrecht in verschiedenen Rechtsgebieten, grenzüberschreitende Steuerfragen usw. usw.), die Anzahl der Hardwareanbieter (OEMs, ODMs, SoC-Hersteller usw. usw.) und andere beteiligte Interessengruppen (Google, AOSP, Android-Entwickler, Linux, Anbieter von Linux-Distributionen – Server, Desktop und möglicherweise mobil, andere Linux-basierte Projekte, GNU, FSF usw. usw. bis hinunter zu den Endbenutzern). Dass es keine Einigung gibt, verlangsamt definitiv die Konvergenz zwischen Linux und AOSP, was wir (die Benutzer) alle bedauern. Aus Hardware-Sicht war vollständige Konvergenz vor mehreren Jahren möglich, als Mainstream-Geräte [Multi-Core x86 CPU / > 2 Gb RAM / > 16 Gb Flash-Laufwerk] auf den Markt kamen. Das Problem wird offensichtlich, wenn diese Hardware nicht zum Ausführen eines Standard-Linux-Kernels (einer Server-Distribution, nicht einmal eines Desktops) verwendet werden kann. Es gibt keine Installationsprogramme, Flash-Tools werden von den Anbietern nicht offiziell unterstützt, die Dokumentation ist spärlich und verstreut. Im Juni 2019 könnte es deutlich besser laufen...

7) Der nächste Schritt wäre die Überwachung der Bemühungen der führenden, auf Konvertierung ausgerichteten Communities und unterstützenden Anbieter sowie der Schritte der Hardwareanbieter und von AOSP/Google zur Aushandlung des Deals.

Answer 1