Il s'agit d'un ensemble de scripts minimaux pour exécuter l'émulateur dans un conteneur pour divers systèmes tels que Docker, pour la consommation externe. Les scripts sont compatibles avec Python version 2 et 3.
* Notez qu'il s'agit toujours d'une fonctionnalité expérimentale et nous vous recommandons d'installer cet outil dans un environnement virtuel Python. Veuillez déposer des problèmes si vous remarquez que quelque chose ne fonctionne pas comme prévu.
Ces démos sont destinées à être exécutées sur un système d'exploitation Linux. Votre système doit répondre aux exigences suivantes:
Un interprète Python doit être installé (Python3 avec Python3-Venv pour créer des environnements virtuels)
La BAD doit être disponible sur le chemin. L'ADB fait partie du SDK Android. Notez que l'installation des outils de ligne de commande est suffisante.
Docker doit être installé. Assurez-vous de pouvoir l'exécuter en tant qu'utilisateur non racine
Docker-Compose doit être installé.
KVM doit être disponible. Vous pouvez accéder à KVM en fonctionnant sur "Bare Metal", ou sur une machine (virtuelle) qui fournit une virtualisation imbriquée. Si vous prévoyez d'exécuter ceci dans le cloud (GCE / Azure / AWS / etc.), vous devez d'abord vous assurer d'avoir accès à KVM. Des détails sur la façon d'avoir accès à KVM sur les différents fournisseurs de cloud peuvent être trouvés ici:
Gardez à l'esprit que vous verrez des performances réduites si vous utilisez une virtualisation imbriquée. Les conteneurs ont été testés sous Debian et Ubuntu exécutant le noyau 5.2.17.
Remarque: les images ne s'exécuteront pas dans Docker sur Mac ou Windows
Nous hébergeons maintenant un ensemble de conteneurs dans un référentiel public. Vous pouvez trouver des détails sur les conteneurs ici. Vous pouvez maintenant exécuter ces conteneurs sans les construire. Par exemple:
docker run
-e ADBKEY= " $( cat ~ /.android/adbkey ) "
--device /dev/kvm
--publish 8554:8554/tcp
--publish 5555:5555/tcp
us-docker.pkg.dev/android-emulator-268719/images/30-google-x64:30.1.2
Cela réduira le conteneur s'il n'est pas disponible localement et le lancera. Vous pouvez voir que cela commence:
Après cela, vous pouvez vous connecter à l'appareil en configurant la BAD:
adb connect localhost:5555
L'appareil devrait maintenant apparaître après un certain temps comme:
$ adb devices
List of devices attached
localhost:5555 device
Si vous souhaitez l'utiliser dans un script, vous pouvez effectuer ce qui suit:
docker run -d
-e ADBKEY= " $( cat ~ /.android/adbkey ) "
--device /dev/kvm
--publish 8554:8554/tcp
--publish 5555:5555/tcp
us-docker.pkg.dev/android-emulator-268719/images/30-google-x64:30.1.2
adb connect localhost:5555
adb wait-for-device
# The device is now booting, or close to be booted
Un script plus détaillé peut être trouvé dans Run-in-Script-Example.sh.
Vous pouvez installer le package Python comme suit:
source ./configure.sh
Cela activera un environnement virtuel et mettra le emu-docker
exécutable disponible. Vous pouvez obtenir des informations détaillées sur l'utilisation en les lançant comme suit:
emu-docker -h
Vous devrez accepter les accords de licence avant de pouvoir créer des conteneurs Docker.
Vous pouvez sélectionner de manière interactive la version d'Android et d'émulateur que vous souhaitez utiliser en fonctionnant:
emu-docker interactive --start
Il vous sera demandé de sélectionner une image système et une version d'émulation, après quoi un fichier Docker sera créé. L'image et l'émulateur système seront téléchargés dans le répertoire actuel si nécessaire. Le script vous fournira une commande pour voir les journaux ainsi que la commande pour arrêter le conteneur.
Si le serveur ADB local a détecté automatiquement le conteneur démarré, vous n'avez rien à faire pour l'interroger via BAD. Si ce n'est pas le cas, vous pouvez désormais vous connecter à l'appareil en cours d'exécution à l'aide de la BAD:
adb connect localhost:5555
Pour vérifier si ADB a vu le conteneur, vous pouvez utiliser le:
adb devices
Commandez et vérifiez si un périphérique est détecté.
N'oubliez pas d'arrêter le conteneur Docker une fois que vous avez terminé!
Lisez la section sur la mise à disposition de l'émulateur sur le Web pour exécuter l'émulateur à l'aide de WebBrTC
Émission:
emu-docker list
Interrogera le SDK Android actuellement publié et les URL de sortie pour les fichiers ZIP de:
Pour chaque image système, le niveau d'API, la variante, l'ABI et l'URL sont affichés. Pour chaque émulateur, le canal de mise à jour (stable vs canary), la version, le système d'exploitation hôte et l'URL sont affichés.
Exemple de sortie:
SYSIMG android 21 L x86_64 https://dl.google.com/android/repository/sys-img/android/x86_64-21_r05.zip
SYSIMG android 22 L x86_64 https://dl.google.com/android/repository/sys-img/android/x86_64-22_r06.zip
SYSIMG android 23 M x86_64 https://dl.google.com/android/repository/sys-img/android/x86_64-23_r10.zip
SYSIMG android 24 N x86_64 https://dl.google.com/android/repository/sys-img/android/x86_64-24_r08.zip
SYSIMG android 25 N x86_64 https://dl.google.com/android/repository/sys-img/android/x86_64-25_r01.zip
SYSIMG android 26 O x86_64 https://dl.google.com/android/repository/sys-img/android/x86_64-26_r01.zip
SYSIMG android 27 O x86_64 https://dl.google.com/android/repository/sys-img/android/x86_64-27_r01.zip
SYSIMG android 28 P x86_64 https://dl.google.com/android/repository/sys-img/android/x86_64-28_r04.zip
SYSIMG android 28 Q x86_64 https://dl.google.com/android/repository/sys-img/android/x86_64-Q_r04.zip
SYSIMG google_apis 21 L x86_64 https://dl.google.com/android/repository/sys-img/google_apis/x86_64-21_r30.zip
SYSIMG google_apis 22 L x86_64 https://dl.google.com/android/repository/sys-img/google_apis/x86_64-22_r24.zip
SYSIMG google_apis 23 M x86_64 https://dl.google.com/android/repository/sys-img/google_apis/x86_64-23_r31.zip
SYSIMG google_apis 24 N x86_64 https://dl.google.com/android/repository/sys-img/google_apis/x86_64-24_r25.zip
SYSIMG google_apis 25 N x86_64 https://dl.google.com/android/repository/sys-img/google_apis/x86_64-25_r16.zip
SYSIMG google_apis 26 O x86_64 https://dl.google.com/android/repository/sys-img/google_apis/x86_64-26_r13.zip
SYSIMG google_apis 28 P x86_64 https://dl.google.com/android/repository/sys-img/google_apis/x86_64-28_r09.zip
SYSIMG google_apis 28 Q x86_64 https://dl.google.com/android/repository/sys-img/google_apis/x86_64-Q_r04.zip
SYSIMG google_apis_playstore 28 P x86_64 https://dl.google.com/android/repository/sys-img/google_apis_playstore/x86_64-28_r08.p
SYSIMG google_apis_playstore 28 Q x86_64 https://dl.google.com/android/repository/sys-img/google_apis_playstore/x86_64-Q_r04.zp
EMU stable 29.0.11 windows https://dl.google.com/android/repository/emulator-windows-5598178.zip
EMU stable 29.0.11 macosx https://dl.google.com/android/repository/emulator-darwin-5598178.zip
EMU stable 29.0.11 linux https://dl.google.com/android/repository/emulator-linux-5598178.zip
EMU stable 28.0.25 windows https://dl.google.com/android/repository/emulator-windows-5395263.zip
EMU canary 29.0.12 windows https://dl.google.com/android/repository/emulator-windows-5613046.zip
EMU canary 29.0.12 macosx https://dl.google.com/android/repository/emulator-darwin-5613046.zip
EMU canary 29.0.12 linux https://dl.google.com/android/repository/emulator-linux-5613046.zip
On peut ensuite utiliser des outils comme wget
ou un navigateur pour télécharger un émulateur souhaité et une image système. Une fois les deux obtenus, nous pouvons construire une image Docker.
Compte tenu d'un fichier zip d'émulateur et d'un fichier zip d'image système, nous pouvons créer un répertoire qui peut être envoyé à docker build
via l'invocation suivante d' emu-docker
:
emu-docker create <emulator-zip> <system-image-zip> [--dest docker-src-dir
(getcwd()/src by default)]
Cela place tous les bons éléments pour exécuter une image Docker, mais ne construit pas, ne s'exécute pas ou ne publie pas encore. Un fichier zip émulateur Linux doit être utilisé.
Pour construire l'image Docker correspondant à ces émulateurs et images système:
docker build <docker-src-dir, either ./src or specified argument to
emu_docker.py>
Un ID d'image Docker sortira; Enregistrez cet ID d'image.
Nous supposons actuellement que KVM sera utilisé avec Docker afin de fournir des capacités de virtualisation du CPU à l'image Docker résultante.
Nous fournissons le script d'exécution suivant:
./run.sh <docker-image-id> <additional-emulator-params>
Il fait ce qui suit:
docker run -e ADBKEY="$(cat ~/.android/adbkey)"
--device /dev/kvm
--publish 8554:8554/tcp
--publish 5555:5555/tcp <docker-image-id>
--device /dev/kvm
pour avoir une accélération du processeurRemarque: vous pouvez utiliser un Adbkey public en injectant la variable adbkey_pub, c'est-à-dire: -e adbkey_pub = "$ (cat ~ / .android / adbkey.pub)"
Vous avez également la possibilité de monter A / Data Partion que l'émulateur utilisera si disponible. Cela vous permet d'utiliser un TMPFS qui peut donner des performances accrues, en particulier dans le scénario de virtualisation imbriqué.
Par exemple:
docker run -e ADBKEY="$(cat ~/.android/adbkey)"
--device /dev/kvm
--mount type=tmpfs,destination=/data
--publish 8554:8554/tcp
--publish 5555:5555/tcp <docker-image-id>
Nous ne prenons actuellement en charge que l'accélération matérielle pour NVIDIA. Afin d'utiliser l'accélération matérielle, vous devrez peut-être installer les extensions Nvidia Docker à partir d'ici si vous exécutez une ancienne version de Docker (<19.03). Vous devez vous assurer d'avoir une installation minimale de X si vous utilisez une instance cloud. Par exemple, XVFB peut être utilisé. Vous devez construire les conteneurs en passant dans le drapeau --gpu:
emu-docker create stable Q --gpu
Vous pouvez maintenant lancer l'émulateur avec le script run-with-gpu.sh
:
./run-with-gpu.sh <docker-image-id> <additional-emulator-params>
Le script est similaire à celui décrit ci-dessus avec l'addition qu'il sera:
--gpu all
)L'accélération matérielle améliorera considérablement les performances des applications qui s'appuient fortement sur les graphiques. Notez que même si nous avons besoin d'un serveur X11 pour l'accélération GPU, il n'y aura pas d'interface utilisateur affichée.
Vous pouvez pousser les images créées vers un référentiel en fournissant les paramètres --push et --repo et --tag lors de la création d'une image. Le paramètre --Tag est facultatif et est utilisé pour indiquer la version de l'image créée. Cela va par défaut le build-id de l'émulateur, car les images système sont rarement mises à jour.
Nous avons adopté le schéma de dénomination suivant pour les images:
{api} - {srie} - {abi}
Où:
Par exemple: 29-Playstore-X86: 30.1.2 Indique une image système compatible Playstore avec Q exécutant sur 32 bits x86.
Un exemple d'invocation pour publier toutes les images Q à Google Cloud Repo pourrait être:
emu-docker -v create --push --repo us.gcr.io/emulator-project/ stable " Q "
Les images qui ont été poussées vers un référentiel peuvent être lancées directement à partir du référentiel. Par exemple:
docker run --device /dev/kvm --publish 8554:8554/tcp --publish 5555:5555/tcp
us.gcr.io/emulator-project/29-playstore-x86:30.1.2
Nous transférons le port 5555 pour l'accès ADB à l'émulateur fonctionnant à l'intérieur du conteneur. ADB peut ne pas détecter automatiquement l'appareil, alors exécutez:
adb connect localhost:5555
Votre appareil devrait désormais apparaître comme:
$ adb devices
List of devices attached:
localhost:5555 device
Ce référentiel contient également un exemple qui montre comment vous pouvez utiliser Docker pour rendre l'émulateur accessible via le Web. Cela se fait en composant l'ensemble de conteneurs Docker suivants:
Afin d'exécuter cet échantillon et de pouvoir interagir avec l'émulateur, vous devez garder à l'esprit ce qui suit:
Vous aurez besoin de Docker-Compose.
Vous devez avoir le port 80 et 443 disponible. Les conteneurs Docker créeront un réseau interne et exposeront les ports HTTP et HTTPS.
Vous devrez créer une image docker de l'émulateur, comme décrit dans la documentation ci-dessus.
Selon votre réseau, vous devrez peut-être tourner
Nous utilisons actuellement Firebase pour gérer l'authentification et l'autorisation. Vous devrez fournir une configuration JSON du projet que vous souhaitez utiliser. Vous pouvez utiliser l'échantillon fourni ici, mais il ne fonctionnera que sur LocalHost. Vous pouvez obtenir la configuration de Firebase à partir de la console Placer la configuration Josn Firebase ici:
./js/firebase_config.json
Ceci sera utilisé pour générer les paramètres de configuration et d'envoyés.
Afin de créer les conteneurs Web, vous devez avoir les outils suivants disponibles:
Ensuite, vous devez créer un conteneur avec l'émulateur et la version d'image système que vous souhaitez utiliser. Par exemple:
. ./configure.sh && emu-docker create canary "P.*x86_64"
Une fois que vous avez pris en charge les étapes ci-dessus, vous pouvez créer les conteneurs à l'aide du script create_web_container.sh
:
$ ./create_web_container.sh -h
usage: create_web_container.sh [-h] [-a] [-s] [-i] -p user1,pass1,user2,pass2,...
optional arguments:
-h show this help message and exit.
-a expose adb. Requires ~ /.android/adbkey.pub to be available at run.
-s start the container after creation.
-i install systemd service, with definition in /opt/emulator
Par exemple:
./create_web_container.sh
Cela fera ce qui suit:
Vous pouvez maintenant lancer le conteneur comme suit:
docker-compose -f js/docker/docker-compose.yaml up
Si vous souhaitez rendre ADB disponible, vous pouvez appliquer la superposition trouvée dans JS / Docker / Development.yaml comme suit:
docker-compose -f js/docker/docker-compose.yaml -f js/docker/development.yaml up
Pointez votre navigateur vers localhost. Vous obtiendrez probablement un avertissement en raison de l'utilisation du certificat auto-signé. Une fois que vous avez accepté le certificat, vous devriez être en mesure de vous connecter et de commencer à utiliser l'émulateur.
Gardez les choses suivantes à l'esprit lorsque vous rendez l'émulateur accessible sur la BAD:
~/.android/adbkey
. Ceci est la clé privée utilisée par la BAD. Sans cela, vous ne pourrez pas accéder à l'appareil via BAD.adb connect ip-address-of-container:5555
Avant de pouvoir interagir avec l'appareil. Par exemple: $ adb connect localhost:5555
$ adb shell getprop
Il existe un exemple de script Cloud-init qui fournit des détails sur la façon dont vous pouvez configurer une instance qui lancera et configurera automatiquement un émulateur sur la création. Des détails sur la façon de procéder peuvent être trouvés ici.
Nous avons un document distinct lié à la gestion des problèmes.
Les détails sur la conception et comment modifier l'application React peuvent être trouvés ici