Android und RISC-V: Was Sie zur Vorbereitung wissen müssen

 (opensource.googleblog.com)
2 Punkte von GN⁺ 2023-11-02 | 1 Kommentare | Auf WhatsApp teilen
  • Google hat RISC-V-Unterstützung in AOSP integriert, um Android auf eine neue CPU-Architektur auszuweiten, und erweitert dies von einer experimentellen Phase hin zur Zusammenarbeit im Ökosystem
  • Die anfängliche Unterstützung orientiert sich am rva22-Profil sowie an den Erweiterungen Vector und Vector Crypto, mit dem Fokus darauf, den Funktionsumfang abzustimmen, der für die von Android erwartete Performance-Implementierung nötig ist
  • Schon heute lässt sich Android für RISC-V mit Cuttlefish bauen, testen und ausführen, doch das ART-Backend und Compiler-Optimierungen sind noch nicht fertiggestellt
  • Für Ende 2023 werden die Festlegung des NDK ABI und öffentliche CI-Canary-Builds erwartet; für 2024 sind öffentliche Emulatoren zum Testen mehrerer Formfaktoren geplant
  • Da das Portieren von Android allein nicht ausreicht, bereitet Google gemeinsam mit dem RISE Project, RISC-V International sowie der Community rund um Toolchains und Support-Bibliotheken auch die App-Entwicklungsumgebung vor

RISC-V-Unterstützung kommt in Android

  • Android ist ein Open-Source-Betriebssystem, das verschiedene Gerätetypen und CPU-Architekturen unterstützt, und RISC-V wird als Ziel für eine neue Plattform hinzugefügt
  • RISC-V ist eine freie und offene Instruction Set Architecture (ISA) und verfolgt den Ansatz, die branchenweite Zusammenarbeit aus der Open-Source-Software in das Hardware-Ökosystem zu übertragen
  • Seit seiner Entstehung vor zehn Jahren an der UC Berkeley wurde es schnell im Embedded- und Mikrocontroller-Bereich übernommen und expandiert jüngst in Accelerators, Server und Mobile Computing

Von der Annahme von Patches zur Reife der Unterstützung

  • Google kündigte auf dem RISC-V Summit im November 2022 an, RISC-V-Patches für Android anzunehmen
  • Inzwischen geht es über die reine Annahme von Patches hinaus und bewegt sich in Richtung einer ausgereifteren RISC-V-Unterstützung in Android
  • Da RISC-V eine modulare ISA mit vielen optionalen Erweiterungen ist, muss ein anfänglicher Pflicht-Funktionsumfang definiert werden, um die von Android erwartete hohe Performance zu liefern
    • Die Grundlage umfasst das rva22-Profil
    • Auch die Erweiterungen Vector und Vector Crypto sind enthalten

Lokal baubare und ausführbare AOSP-Umgebung

  • Die Android-Unterstützung für RISC-V lässt sich wie andere AOSP-Plattformziele mit dem Cuttlefish Virtual Device auf einer lokalen Maschine bauen, testen und ausführen
  • Der zugehörige Code ist unter google/android-riscv64 zu finden
  • Ein Ausführungsbeispiel sieht wie folgt aus
$ lunch aosp_cf_riscv64_phone-userdebug
$ m -j
$ launch_cvd -cpus=8 -memory_mb=8192
  • Mit einem vncviewer kann man sich mit dem laufenden Gerät verbinden und damit interagieren

Noch offene Optimierungsaufgaben

  • Die aktuellen Patches ermöglichen es, eine grundlegende Android-Open-Source-Project-Erfahrung zu bauen und auszuführen, sind aber noch nicht vollständig optimiert
  • Die Arbeit am ART-Optimierungs-Backend der Android Runtime läuft noch
  • Auch AOSP, externe Projekte und Compiler sind noch nicht so weit, dass sie unter Nutzung der neuesten ratifizierten Erweiterungen vollständig optimierten und kompakten Code erzeugen
  • Ziel der aktuellen Phase ist weniger eine fertige Produktumgebung als vielmehr die Ermöglichung von Experimenten und Zusammenarbeit

Entwicklertests und Emulator-Roadmap

  • Für Ende 2023 wird die Festlegung des NDK ABI erwartet
  • Canary-Builds sollen bald auch in der öffentlichen Android-CI bereitgestellt werden
  • Um riscv64-Android-Anwendungen auf Host-Maschinen einfacher testen zu können, ist geplant, die RISC-V-Ausführung auf x86-64 und ARM64 zu unterstützen
  • Für 2024 ist ein öffentlicher Emulator mit vollständigem Funktionsumfang geplant, mit dem Anwendungen für verschiedene Geräte-Formfaktoren getestet werden können
  • Laut der Ankündigung zur Zusammenarbeit mit Qualcomm wird erwartet, dass der erste Formfaktor Wearables sein wird

Zusammenarbeit im Ökosystem und RISE Project

  • Das Portieren des Android-Betriebssystems allein reicht nicht aus; auch das umgebende Software-Ökosystem muss vorbereitet werden
  • Google arbeitet mit der Community und RISE zusammen
  • Das RISE Project wurde gegründet, um die Verfügbarkeit von Software für leistungsstarke und energieeffiziente RISC-V-Prozessorkerne zu beschleunigen, auf denen High-Level-Betriebssysteme laufen
  • Der Anwendungsbereich umfasst nicht nur Android, sondern auch Linux und andere Betriebssysteme
  • Zu den adressierten Anwendungsdomänen gehört auch High-Performance Computing
  • Die teilnehmenden Unternehmen sind Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head und Ventana

Standardisierung und Wege zur Mitwirkung

  • Google baut seine Investitionen in RISC-V International über die bestehende Premium-Mitgliedschaft und die Beteiligung im Board of Directors hinaus weiter aus
  • Mehrere Mitwirkende übernehmen zentrale Rollen in horizontalen Komitees, Arbeitsgruppen und technischen Komitees und beteiligen sich an Spezifikationsdesign und Ratifizierung
  • Die RISC-V-Unterstützung in Android hängt von breiten Beiträgen ab, von der LLVM-Toolchain bis zu grundlegenden Support-Bibliotheken
  • Wichtige Ressourcen für Beiträge und Tests sind:
    • google/android-riscv64: bietet Informationen zum Bauen und Testen der RISC-V-Unterstützung in Android, zu bekannten Problemen sowie zu Möglichkeiten, zu AOSP, Toolchains und Support-Bibliotheken beizutragen
    • RISC-V Android SIG: eine Mailingliste, auf der man den Fortschritt verfolgen und Vorschläge sowie Feedback einbringen kann
  • Google sucht nach Wegen, damit Android-Entwickler, die nativen Code schreiben, neue Plattformen ebenso einfach adressieren können wie Java- und Kotlin-Entwickler

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-02
Hacker-News-Kommentare

  • Erwartet man wirklich, dass Entwickler sich vorbereiten? Das ist der falsche Ansatz. Standardmäßig sollte der Aufwand nahe 0 liegen, so wie Apple es beim M1-Umstieg gemacht hat, und danach sollten optionale Optimierungen möglich sein.
    Man erinnere sich daran, als Google sagte, Android-Apps sollten auf x86 getestet werden, und später noch einmal auf MIPS. Am Ende ist nichts passiert, und Entwickler werden ihre Zeit nicht verschwenden.

    • Aufwand 0? Erinnerungen verblassen offenbar manchmal schnell.
      Apple hat Entwicklern DTK-Systeme für 500 Dollar vermietet, damit sie ARM-Hardware ausprobieren und ihre Apps portieren konnten. Das war weit von 0 Aufwand entfernt, die Hardware musste zurückgegeben werden, und anfangs gab es nicht einmal ein 500-Dollar-Guthaben für den Kauf eines Serienprodukts. Erst nach absehbarem Gegenwind wurde das korrigiert.
      Google stellt stattdessen einen Software-Emulator bereit, was viel einfacher zu handhaben ist und keine komplizierte Gerätelogistik erfordert. Tatsächlich müssen sich vor allem diejenigen vorbereiten, die NDK-Apps entwickeln oder RISC-V-Hardware unterstützen.
      Java-/Kotlin-Apps müssen nicht portiert werden, also ist das nach meinem Maßstab nahe an 0 Aufwand.
    • x86-Builds von Android-Apps und -Bibliotheken sind sehr verbreitet, weil sie das häufigste Ziel im Emulator sind.
      MIPS scheint Google nicht besonders stark vorangetrieben zu haben; es war eher einfach vorhanden.
      Außerdem richtet sich der Artikel mit AOSP-Builds und ausstehenden Patches eher an Gerätehersteller als an App-Entwickler. Er fordert App-Entwickler nicht wirklich zu irgendetwas auf, sondern sagt am Ende vielmehr: „Wir werden uns ansehen, wie man es nativen Android-Entwicklern genauso leicht machen kann wie Java- und Kotlin-Entwicklern, neue Plattformen ins Visier zu nehmen.“
    • MIPS auf Android war praktisch tot, nachdem es 2013 von Imagination Technologies übernommen wurde. Ohne neue SoCs oder neue Smartphones kann Google auch nichts tun.
      x86 ist dank Chromebooks weiterhin weit verbreitet. Wenn man kein NDK verwendet, gibt es für Entwickler wegen eines neuen Targets nichts zu tun.
    • Im allgemeinen Sinn scheint man nicht zu erwarten, dass Entwickler sich vorbereiten. Auch der Titel lautet „Was man wissen muss, um sich vorzubereiten“, was eher bedeutet: Wenn du dich vorbereiten willst, liefern wir Informationen und Ratschläge. Ob man sie annimmt oder nicht, ist optional.
      Das „you“ hier folgt der Formulierung des Titels und bezieht sich nicht auf eine bestimmte Person.
    • Weil für diese Architektur keine relevanten Geräte erschienen sind.

  • Wird die C-Erweiterung, gegen die Qualcomm sich so stark stellt, dann nötig?
    Siehe dazu den zugehörigen Unterthread: https://news.ycombinator.com/item?id=37996820
    Qualcomms neuestes Material ist https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...; darin behaupten sie, dass die von ihnen vorgeschlagenen Zics-Erweiterungen, die „RISC-V ein wenig mehr wie aarch64 machen“, zusammen mit 32-Bit-Long-Jumps eine bessere Code-Dichte als RV64GC erreichen und zudem nicht die Nachteile der C-Erweiterung haben, die sie immer wieder kritisieren.

    • Ich weiß nicht, warum das runtergevotet wird. Diese Frage ist tatsächlich noch ein laufender Streitpunkt.
      Wenn Qualcomm beschließt, einen RISC-V-Snapdragon ohne C-Erweiterung zu bauen, ist schwer vorstellbar, wie Android-NDK-Apps funktionieren sollen, die diese Erweiterung nutzen. Ohne irgendeine Art Trap-und-Emulation wäre das absurd langsam.
    • Qualcomm hat wohl bis zu einem gewissen Grad recht, aber es scheint auch die Motivation zu geben, mehr ARM-Technik wiederzuverwenden.
      Wenn Google RV64GC oder RV64G_Zics vorschreibt, könnte sich das hier entscheiden.
      C-Instruktionen wegzulassen oder zu ändern ist allerdings keine Option mehr, sobald es echte Auslieferungen gibt; im Moment ist das meiste noch Emulator-Testing, daher könnte es nicht allzu sehr ins Gewicht fallen.
    • Das sieht dem Thumb-Befehlssatz von ARM ziemlich ähnlich.
      Die eigentliche Frage ist: warum?
      Siehe: https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-...

  • Nebenbei: Als ich vom neuen AOSP-Emulator erfahren habe, dachte ich aus irgendeinem Grund, man müsse acloud ausführen, um in AOSP statt Goldfish den Cuttlefish-Emulator zu verwenden. acloud weigerte sich aber zu starten, wenn es nicht auf Ubuntu lief.
    Ich habe sogar einen LD_PRELOAD-Hack ausprobiert, der die Ausgabe der Funktion uname ändert, aber danach wollte es dpkg ausführen. Ich nutze NixOS.
    Den alten Emulator korrekt zum Laufen zu bringen, ist wirklich mühsam, und der neue Emulator hat viele Vorteile.
    Seltsamerweise war mir aber überhaupt nicht klar, dass man einfach direkt launch_cvd ausführen kann.

  • Ich hoffe, dass „Android for RISC-V“ erfolgreicher wird als das komplette Desaster „Android for x86“. Ich habe immer noch ein Lenovo-x86-Android-Tablet.
    Wenn ich diesen Artikel lese, schafft er allerdings nicht gerade viel Vertrauen. Hohe Hoffnungen, geringe Erwartungen.

    • Es scheint unvermeidlich, dass der Markt von billigen Consumer-Geräten überschwemmt wird, die RISC-V-Implementierungen als Hauptprozessor nutzen.
      Eher sollte man sich wohl Sorgen machen, dass die ARM-Unterstützung stagniert.
    • Chromebooks sind derzeit größtenteils x86 und führen Android-Apps aus. Für den Android-Emulator gilt dasselbe.
      Nicht jeder ist ein reicher Amerikaner mit einem ARM-MacBook.

  • Vor einigen Jahren wurde Android recht breit in Embedded-Bereichen eingesetzt, in denen kein Smartphone oder Tablet, aber ein grafischer Touchscreen nötig war. Heute ist es fast nur noch für Smartphones und in gewissem Maß für Tablets.
    Der Grund ist, dass kleinere Anbieter, anders als Smartphone- und Tablet-Hersteller, die sehr komplexen neuen Änderungen in Android nicht mehr mitgehen konnten und nach und nach abgesprungen sind.

    • Ich frage mich, was sie stattdessen verwenden.
    • DJI scheint in seinen Controllern immer noch Android zu verwenden.

  • Ich kenne die Lage nicht so genau: Gibt es wichtige Smartphones, die RISC-V implementieren? Und erfordert das Änderungen über den gesamten Stack hinweg? Es dürfte ja wohl nicht damit getan sein, nur das Betriebssystem auszutauschen.

    • Noch nicht, aber die Markteinführung rückt näher.
      Ich bin mir nicht sicher, wo du die Grenze zwischen „Stack“ und „Betriebssystem“ ziehst. Kannst du das etwas genauer ausführen?
    • Nein. Allerdings arbeitet Qualcomm an einem RISC-V-Prozessor für Smartwatches. Das ist nicht nichts.
      Den AOSP-Port für das LiCheePi 4A habe ich noch nicht ausprobiert. Ich sollte ihn wohl einfach mal laufen lassen, um zu sehen, ob er funktioniert.
      Es ist einfacher, Minecraft aus dem Play Store herunterzuladen, als die komplette Toolchain zu bootstrappen, die nötig ist, um PolyMC zum Laufen zu bringen.

  • Google Android wäre das Letzte, was ich auf RISC-V installieren würde.

    • Ich frage mich, ob es positive Auswirkungen auf das Ökosystem hätte, wenn RISC-V bei mobilen CPUs häufiger eingesetzt wird, oder ob große Unternehmen RISC-V stärker in Richtung Enterprise-Use-Cases drängen und es dadurch für Hobbyentwickler weniger freundlich machen würden.
    • Trotzdem könnte es sein, dass man ein RISC-V-Gerät mit vorinstalliertem Android kauft und es anschließend löscht.

  • Wenn man es vermeiden kann, ist es eine dumme Entscheidung, Android auszuführen — erst recht, wenn man durch den Architekturwechsel die Chance hat, auf reines Linux umzusteigen.
    Das Problem ist Banking. Zumindest in Schweden ist man noch auf die mobile BankID angewiesen. Sie wird zum Beispiel auch für Online-Käufe über 20 Dollar benötigt und funktioniert nur unter iOS und Android.

    • Gibt es eine realistische Möglichkeit, auf einem Smartphone ein anderes Betriebssystem als Android zu betreiben und trotzdem Energieeffizienz, Multitouch sowie Unterstützung für Android-Apps mit GPU-Beschleunigung zu bekommen?
      Also etwa eine fertige Lösung, die Android effizient in KVM ausführt, oder einen Ansatz, der Android-Kernel-Funktionen und einen RPC-Server im Userspace bereitstellt.
      Wenn es das nicht gibt, bleibt einem für den Zugriff auf mobile Apps nichts anderes übrig, als Android auszuführen, und das ist praktisch unverzichtbar.
    • In Dänemark gibt es MitID für Banken und Behörden-Websites. Es wird gelegentlich auch zur Kaufbestätigung verwendet.
      Wenn man kein Smartphone hat oder keines nutzen möchte, kann man ein kleines Gerät zur Authentifizierung bekommen. Es wirkt seltsam, dass Schweden jeden mit einem Bankkonto dazu zwingt, auch ein Smartphone zu besitzen. Besonders, weil es viele ältere Menschen geben dürfte, die kein Smartphone haben.