Windows-Subsystem für Android™️

Das Windows-Subsystem für Android™️ ermöglicht es Ihrem Windows 11-Gerät, die im Amazon Appstore verfügbaren Android-Anwendungen auszuführen. Android ist eine Marke von Google LLC. Wenn Sie ein Entwickler sind, der sich für Windows-Desktopgeräte und die Optimierung des Windows-Betriebssystems interessiert, ist dieser Leitfaden für Sie geeignet.

Wichtig

Microsoft stellt den Support für das Windows-Teilsystem für Android™️ (WSA) ein. Daher wird der Amazon Appstore unter Windows und alle von WSA abhängigen Anwendungen und Spiele ab dem 5. März 2025 nicht mehr unterstützt. Bis dahin steht der technische Support den Kunden zur Verfügung.
Kunden, die den Amazon Appstore oder die Android-Apps vor dem 5. März 2024 installiert haben, haben bis zum Ablaufdatum am 5. März 2025 weiterhin Zugriff auf diese Apps. Wenden Sie sich bitte an unser Supportteam für weitere Fragen bei support.microsoft.com. Wir sind dankbar für die Unterstützung unserer Entwicklercommunity und werden bei der Weiterentwicklung unserer Erfahrungen auch weiterhin Ihr Feedback berücksichtigen.

Um Ihre Android-App auf Windows 11-Geräten verfügbar zu machen, müssen Sie folgende Schritte ausführen:

Weitere Informationen oder Unterstützung:

Dieser Leitfaden unterstützt Sie beim Testen und Debuggen Ihrer Android-App auf Windows:

GitHub für Entwickler

Möchten Sie mehr über die Roadmap für das Windows-Subsystem für Android™️ erfahren, Probleme bei der Entwicklung diskutieren und Bugs oder Funktionsanfragen an das Subsystem-Team senden? Besuchen Sie die GitHub-Seite für Entwickler*innen für das Windows-Subsystem für Android.

Vorschauprogramm

Das Preview-Programm für Windows-Subsystem für Android™️ ist nicht mehr verfügbar.

Einrichten der Entwicklungsumgebung

Um Ihre Android-App in der Windows-Desktopumgebung zu testen, müssen einige Einrichtungsschritte ausgeführt werden.

Voraussetzungen

Das Windows-Subsystem für Android™️ ist unter Windows 11 verfügbar. Ihr Gerät muss bestimmte Anforderungen erfüllen: Geräteanforderungen.

Installieren von Amazon Appstore

Der Microsoft Store installiert das Windows-Subsystem für Android™️ automatisch im Hintergrund, wenn eine der beiden folgenden Benutzeraktionen ausgeführt wird:

  1. Installieren Sie Amazon Appstore über den Microsoft Store. Wenn Sie Abrufen auswählen, wird die Installation der App gestartet.
  2. Sie installieren zum ersten Mal eine Android-App aus dem Microsoft Store, wodurch auch der Amazon Appstore installiert wird.

Die Amazon Appstore-App wird dann im Windows 11-Startmenü angezeigt, ist bei der Suche verfügbar und bietet einen Katalog mit Android-Apps. Die App Windows-Subsystem für Android™️, mit der Sie Einstellungen und Funktionen für mobile Apps steuern können, wird auch im Startmenü angezeigt.

Screenshot der „Microsoft Store“-Seite mit der Schaltfläche „Abrufen“ im Amazon Appstore

Hinweis

Amazon Appstore unter Windows (eine Voraussetzung für die Ausführung von Android-Apps unter Windows 11) ist in ausgewählten Regionen verfügbar.

Windows-Subsystem für Android™️-Einstellungen

Zum Ändern der Einstellungen für das Windows-Subsystem für Android™️ navigieren Sie zu: Start > Alle Apps > Windows-Subsystem für Android™️. Weitere Informationen zu bestimmten App-Features der Einstellungen-App: Verwalten von Einstellungen für mobile Apps auf Windows.

Screenshot der Einstellungen der Latte-App

Testen und Debuggen

Zum Testen und Debuggen Ihrer App auf einem Windows 11-Gerät mit dem Windows-Subsystem für Android™️ sind die folgenden Einrichtungsschritte erforderlich.

Aktivieren des Entwicklermodus in Windows-Einstellungen

Sie müssen zuerst den Entwicklermodus aktivieren. Öffnen Sie die Einstellungen von Windows-Subsystem für Android™️. Aktivieren Sie anschließend den unter Erweiterte Einstellungen den Entwicklermodus.

Herstellen einer Verbindung mit dem Windows-Subsystem für Android™️ zum Debuggen

So stellen Sie eine Verbindung mit der Windows-Subsystem für Android™️-VM zum Debuggen her

  1. Starten Sie eine Android-App, die über den Amazon Appstore installiert wurde.

  2. Sie können eine Verbindung mit adb connect mit dem folgenden Befehl herstellen (adb muss installiert sein):

    adb connect 127.0.0.1:58526
    

Verbindung mit einem Testgerät

So stellen Sie von Windows/Mac eine Verbindung mit einem Testgerät (mit installiertem Windows-Subsystem für Android™️) im selben Netzwerk her

  1. Öffnen Sie auf dem Testgerät (auf dem das Windows-Subsystem für Android™️ installiert ist) ein PowerShell-Fenster, und identifizieren Sie die IP-Adresse des Testgeräts, indem Sie den folgenden Befehl ausführen:

    ipconfig
    
  2. Geben Sie über das Terminal des Geräts zum Debuggen, in dem Android Studio und das Android SDK installiert ist (Mac/Windows), den folgenden Befehl ein:

    adb connect <TEST DEVICE IP ADDRESS>:58526
    

Die <TEST DEVICE IP ADDRESS> finden Sie in der Ausgabe von „ipconfig“ vom Testgerät. Sie können Apps auch über Android Studio bereitstellen und debuggen.

Wenn Sie Android Debug Bridge (ADB) verwenden möchten, um Ihre Entwicklungsarbeitsstation direkt mit Ihrem Android-Gerät zu verbinden, damit Sie Pakete installieren und Änderungen auswerten können, finden Sie Informationen in der Dokumentation zu Android Debug Bridge in Android Open Source.

Debuggen der App

Apps sollten zwar mit Amazon Appstore installiert werden, ist das Debuggen einer Android-App auf einem Windows-Gerät mit einem APK (Android-Anwendungspaket) und adb (Android Debug Bridge) möglich.

So debuggen Sie ein APK mithilfe von adb

  1. Führen Sie die oben beschriebenen Schritte aus, um eine Verbindung mit der VM mit dem Windows-Subsystem für Android™️ herzustellen.

  2. Installieren des APK mit dem adb-Installationsbefehl: adb install app-debug.apk

    Erwartete Ausgabe:

    Performing Streamed Install
    Success
    
  3. Im Windows-Benachrichtigungsmenü wird eine Erfolgsbenachrichtigung „App installiert“ angezeigt, und die App wird gestartet, sobald sie ausgewählt wird.

Erstellen universeller APKs

Das Windows-Subsystem für Android™️ nutzt Intel Bridge-Technologie, um Arm-Anwendungen auf x86-basierten Prozessoren zu emulieren. Arm-Anwendungen können auf Arm-basierten Prozessoren nativ ausgeführt werden. Die Emulationsebene verursacht einen Leistungsmehraufwand. Um eine optimale Leistung zu erzielen, übermitteln Sie Ihre Anwendung für die x86-64- und die Arm64-Architektur.

Überlegungen zur Eingabekompatibilität für Windows-Geräte

Es gibt einige einzigartige Verhaltensweisen bei der Eingabe zu berücksichtigen, die wahrscheinlich Aktualisierungen Ihres Android-App-Codes erfordern, der für Handheldgeräte entwickelt wurde, damit er bei der Ausführung auf einem Windows-Desktopgerät über den Amazon Appstore kompatibel ist.

Tastatureingabe

Für Texteingabefelder, die von einer virtuellen Bildschirmtastatur-Eingabemethode (oder IME) verarbeitet werden, z. B. EditText, sollten sich Apps wie erwartet verhalten. (EditText-Klasse in der Android-Dokumentation).

Für Tastatureingaben, die vom Framework nicht erwartet werden können, müssen Apps das Verhalten selbst verarbeiten. Wenn dies bereits in der App implementiert ist, ist keine zusätzliche Arbeit erforderlich.

Beispielsweise unterstützen einige Spiele möglicherweise bereits Bewegung, die neben Toucheingaben über Tastatur (Tasten w a s d) ermöglicht wird.

Im Folgenden finden Sie Tastatureingaben, für die Entwickler bei der Entwicklung für Windows 11-Geräte Codeaktualisierungen in Betracht ziehen sollten:

  • EINGABETASTE
  • Navigation mit Pfeiltasten und TAB-TASTE
  • Ändern der Farbe zum Hervorheben ausgewählter Elemente
  • STRG-basierte Tastenkombinationen

Weitere Informationen zum Optimieren dieser Tastatureingabeszenarien auf Desktopgeräten finden Sie in der Android-Dokumentation:

Mauseingabe

Entwickler sollten bei der Entwicklung für Windows-Geräte in Betracht ziehen, den Code für die folgenden Mauseingaben zu aktualisieren:

  • Rechtsklick
  • QuickInfos/Text beim Daraufzeigen
  • Effekte beim Daraufzeigen
  • Mausradaktion
  • Drag & Drop

Mauseingaben müssen ähnlich wie Tastatureingaben den offiziellen Android-App-Richtlinien entsprechen. Das bedeutet, die mit der SOURCE_MOUSE-Konstante gekoppelte InputDevice-Klasse muss verwendet werden. Weitere Informationen zum Optimieren dieser Mauseingabeszenarien auf Desktopgeräten finden Sie in der Android-Dokumentation:

Fensterverwaltung und Größenänderung

Im Gegensatz zu herkömmlichen Formfaktoren für Mobilgeräte können Android-Apps, die auf Windows 11 ausgeführt werden, frei in ihrer Größe geändert werden, sollten bei der Größenänderung reaktionsfähig sein und können mithilfe von Windows-Aktionen/Gesten ausgerichtet werden.

Bildschirmmindestanforderung

Windows 11 erzwingt eine Mindestbildschirmauflösung von 720p (1280 x 720) mit einem a >9”-Bildschirm.

Letterboxing und Pillarboxing

Wenn das Seitenverhältnis einer Fenstergröße nicht zwischen den Gerätebildschirmgrößen ausgerichtet werden kann, auf denen das Fenster angezeigt wird, kann dies zu Letterboxing (das Fenster ist breiter als hoch oder horizontal länger) oder Pillarboxing (das Fenster ist schmaler als breit oder vertikal länger) führen. Das Ergebnis sind Balken, die an den Seiten des Fensters platziert werden, um es zu zentrieren. Diese Balken können je nach den ausgewählten Systemeinstellungen von hellem oder dunklem Design sein. Dies geschieht nur bei Bedarf, wenn die Android-App angedockt oder maximiert wird, sodass Android-Apps die umfassenden Andockfunktionen in Windows nutzen und in das Fenstermodell integrieren können.

Beispiel für Letterboxing und Pillarboxing mit leeren Balken, die das Fenster zentrieren

Zusätzliche Überlegungen zur Größenänderung

Folgendes sollte beim Aktualisieren einer Android-App für die Ausführung auf einem Windows 11-Gerät in Bezug auf die Fensterverwaltung und Größenänderung ebenfalls berücksichtigt werden:

  • Anfängliche Startgröße
  • Fensterdimensionen
    • Inhaltsgrenzen
    • Freiformgrößenänderung
  • Bildschirmausrichtung

Weitere Informationen zum Optimieren von Fensteränderungsszenarien auf Desktopgeräten finden Sie im Leitfaden zur Fensterverwaltung in der Android-Dokumentation.

Ereignisse für den Anwendungslebenszyklus

Wenn Sie Android-Anwendungen für eine Umgebung mit mehreren Fenstern entwickeln, hat das Auswirkungen auf die in Ihrer Anwendung verwendeten Lebenszyklusereignisse. Das Überschreiben des Ereignisses onPause liefert zwar möglicherweise auf einem Smartphone oder Tablet die gewünschten Ergebnisse, für den Wechsel der Benutzeroberfläche Ihrer App ist es jedoch in der Regel das falsche Ereignis.

Eine Beschreibung der Lebenszyklusereignisse finden Sie in der Android-Dokumentation. In den meisten Fällen sollten Sie das Ereignis onStop und nicht das Ereignis onPause oder onUserLeaveHint verwenden. Viele Android-Implementierungen mit mehreren Fenstern stellen die Benachrichtigung onUserLeaveHint gar nicht bereit. Das führt dazu, dass unternehmenskritische Logik, die sich in diesem Ereignishandler befindet, auf diesen Plattformen nicht aufgerufen wird. Dies schließt auch das Windows-Subsystem für Android™️ ein.

Überlegungen zum VM-Lebenszyklus

Das Windows-Subsystem für Android™️ verwendet eine VM (virtueller Computer), die Kompatibilität mit dem AOSP-Framework und Geräten wie Tastatur, Maus, Toucheingabe, Stift usw. bietet.

Es gibt drei mögliche Zustände für die VM, auf der Apps mit dem Windows-Subsystem für Android™️ ausgeführt werden:

  1. Wird ausgeführt
  2. Lightweight Doze: Aktiviert nach 3 Minuten ohne App-Aktivität. Deaktiviert durch Benutzeraktivität oder App-Benachrichtigung.
  3. Nicht ausgeführt: Aktiviert nach 7 Minuten ohne App-Aktivität.

Übergänge zwischen diesen Zuständen werden durch Benutzeraktivitäten ausgelöst, z. B. durch Starten oder Interaktion mit der Android-App oder eine App-Benachrichtigung. Android-Apps werden angehalten und dann beendet, wenn ihr Fenster minimiert wird.

VM-Lebenszyklusdiagramm mit „Wird ausgeführt“, „Lightweight Doze“ und „Nicht ausgeführt“

Eigenschaften virtueller Computer

Die Eigenschaften für die VM mit dem Windows-Subsystem für Android™️ sind unten aufgeführt. Das Hartcodieren dieser Werte wird nicht empfohlen, da dies zu zukünftigen Inkompatibilitäten führen kann.

Eigenschaft Wert
Build.MANUFACTURER Microsoft Corporation
Build.MODEL Subsystem für Android(TM)
Build.VERSION.SDK_INT 33
Build.BOARD windows

Umleiten zu Windows-Apps

Das Windows-Subsystem für Android™ leitet Absichten für Dateien und allgemeine URI-Schemas automatisch an den entsprechenden Windows-Standardhandler für Dateien/Protokolle weiter (wenn mehrere Absichtsfilter übereinstimmen, wird Benutzer*innen im Auswahldialogfeld die Option „Windows-Standard-App“ angezeigt). Zu den unterstützten Dateiabsichten gehören ACTION_VIEW, ACTION_EDIT, ACTION_SEND und ACTION_SEND_MULTIPLE, die die Datei vor dem Öffnen in den Ordner „Downloads“ unter Windows kopieren. Zu den unterstützte URI-Absichten gehören ACTION_VIEW für HTTP/HTTPS-Schemas und ACTION_VIEW und ACTION_SENDTO für das mailto-Schema.

Android-Apps können auch manuell mit benutzerdefinierten URI-Schemas zu Windows-Apps umgeleitet werden. Legen Sie die Absichtsaktion auf com.microsoft.windows.LAUNCH_URI fest, und fügen Sie der Absicht eine zusätzliche Zeichenfolge mit dem Namen com.microsoft.windows.EXTRA_URI und dem benutzerdefinierten URI als Wert hinzu. So starten Sie beispielsweise die Windows-Rechner-App aus einer Android-App (Java)

Intent intent = new Intent("com.microsoft.windows.LAUNCH_URI");
intent.putExtra("com.microsoft.windows.EXTRA_URI", "ms-calculator:");
 
try {
    startActivity(intent);
} catch (ActivityNotFoundException e) {
    // Not running in Windows Subsystem for Android&trade;️ (or running on an older build that did not contain this feature).
}

Sicherheit

Sowohl Windows-Kernelmodustreiber als auch Windows-Anwendungen, die auf mittlerer Integritätsebene (IL) ausgeführt werden, können beliebige Android-Container und den Android-App-Arbeitsspeicher untersuchen. Kurzfristig ist nicht geplant, die Erkennung von Cheatprogrammen/Makros/Bots/verdächtigem Verhalten hinzuzufügen.

Entwickler, die getSecurityLevel abfragen, erhalten SECURITY_LEVEL_SW_SECURE_CRYPTO. Weitere Informationen zu getSecurityLevel finden Sie im Referenzhandbuch zur Android-API.

Deinstallieren des Windows-Subsystems für Android™️

Sie können das Windows-Subsystem für Android™️ deinstallieren. Beachten Sie jedoch, dass damit auch alle zugehörigen Apps deinstalliert werden.

  • Durch das Deinstallieren von Amazon Appstore werden das Windows-Subsystem für Android™️ und alle anderen Android-Apps deinstalliert.
  • Beim Deinstallieren einer Amazon Appstore-App wird nur die App deinstalliert (das gleiche Verhalten wie Windows-Apps).
  • Durch das Deinstallieren des Windows-Subsystems für Android™️ werden Amazon Appstore und alle Android-Apps deinstalliert.

Fragen zur Problembehandlung

Wenn unter Windows spezifische Probleme mit Amazon Appstore auftreten, führen Sie die folgenden Schritte zur Problembehandlung aus:

  1. Wählen Sie Windows Search in der Windows-Taskleiste aus.
  2. Suchen Sie nach „Amazon Appstore“, und klicken Sie mit der rechten Maustaste auf das Symbol „Amazon Appstore“.
  3. Wählen Sie in den Dropdownoptionen „App Einstellungen“ aus.
  4. Wählen Sie „Speicher und Cache“ aus, und klicken Sie auf „Speicher löschen“ und „Cache löschen“.
  5. Wechseln Sie zurück, und wählen Sie „Beenden erzwingen“ aus.
  6. Schließen Sie das Fenster „Amazon Appstore-Einstellungen“.
  7. Starten Sie Amazon Appstore neu.

Weitere Schritte zur Problembehandlung im Zusammenhang mit der Einstellungen-App des Windows-Subsystems für Android™️ oder Informationen dazu, wie Sie Feedback über den Feedback-Hub abgeben können, finden Sie unter Problembehandlung und häufig gestellte Fragen zu mobilen Apps unter Windows.

Bei anderen Fragen und für Unterstützung für Entwickler*innen verwenden Sie das Tag „Windows-Subsystem für Android™️“ in Microsoft QA.

Zusätzliche Ressourcen