Este é um conjunto de scripts mínimos para executar o emulador em um contêiner para vários sistemas, como o Docker, para consumo externo. Os scripts são compatíveis com o Python versão 2 e 3.
*Observe que este ainda é um recurso experimental e recomendamos a instalação desta ferramenta em um ambiente virtual do Python. Por favor, arquive problemas se perceber que algo não está funcionando como esperado.
Essas demos devem ser executadas em um sistema operacional Linux. Seu sistema deve atender aos seguintes requisitos:
Um intérprete Python deve ser instalado (Python3 com Python3-VenV para criar ambientes virtuais)
O ADB deve estar disponível no caminho. O ADB vem como parte do Android SDK. Observe que a instalação das ferramentas da linha de comando é suficiente.
Docker deve ser instalado. Certifique-se de executá-lo como usuário sem raiz
O Docker-Compose deve ser instalado.
KVM deve estar disponível. Você pode ter acesso ao KVM executando em "bare metal" ou em uma máquina (virtual) que fornece virtualização aninhada. Se você planeja executar isso na nuvem (GCE/Azure/AWS/etc.), primeiro deve ter acesso ao KVM. Detalhes sobre como obter acesso ao KVM nos vários provedores de nuvem podem ser encontrados aqui:
Lembre -se de que você verá desempenho reduzido se estiver usando virtualização aninhada. Os contêineres foram testados no Debian e no Ubuntu Running Kernel 5.2.17.
Nota: as imagens não serão executadas no Docker no Mac ou no Windows
Agora hospedamos um conjunto de contêineres em um repositório público. Você pode encontrar detalhes sobre os contêineres aqui. Agora você pode executar esses contêineres sem construí -los. Por exemplo:
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
Isso abaixará o contêiner se não estiver disponível localmente e o iniciará. Você pode ver que está começando:
Depois disso, você pode se conectar ao dispositivo configurando o ADB:
adb connect localhost:5555
O dispositivo agora deve aparecer depois de um tempo como:
$ adb devices
List of devices attached
localhost:5555 device
Se você deseja usar isso em um script, poderá fazer o seguinte:
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
Um script mais detalhado pode ser encontrado no Run-In-Script-Exemplo.sh.
Você pode instalar o pacote Python da seguinte maneira:
source ./configure.sh
Isso ativará um ambiente virtual e disponibilizará o emu-docker
executável. Você pode obter informações detalhadas sobre o uso lançando -as da seguinte forma:
emu-docker -h
Você terá que aceitar os contratos de licença antes de criar contêineres do Docker.
Você pode selecionar interativamente qual versão do Android e do emulador você deseja usar em execução:
emu-docker interactive --start
Você será solicitado a selecionar uma imagem do sistema e uma versão emuladora, após a qual um arquivo do Docker será criado. A imagem e o emulador do sistema serão baixados para o diretório atual, se necessário. O script fornecerá um comando para ver os logs e o comando para interromper o contêiner.
Se o servidor ADB local detectar o contêiner iniciado automaticamente, você não terá nada a fazer para consultá -lo através do ADB. Se não for esse o caso, agora você pode se conectar ao dispositivo em execução usando o ADB:
adb connect localhost:5555
Para verificar se o ADB viu o contêiner, você pode usar o:
adb devices
comando e verifique se um dispositivo é detectado.
Não se esqueça de parar o recipiente do Docker quando terminar!
Leia a seção sobre como disponibilizar o emulador na web para executar o emulador usando o WebRTC
Emissão:
emu-docker list
Will Will Will os URLs do Android SDK atualmente publicados e de saída para os arquivos ZIP de:
Para cada imagem do sistema, o nível da API, a variante, o ABI e o URL são exibidos. Para cada emulador, o canal de atualização (estável vs canário), versão, sistema operacional host e URL são exibidos.
Exemplo de saída:
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
Pode -se usar ferramentas como wget
ou um navegador para baixar um emulador desejado e uma imagem do sistema. Depois que os dois são obtidos, podemos construir uma imagem do Docker.
Dado um arquivo zip de emulador e um arquivo zip de imagem do sistema, podemos criar um diretório que pode ser enviado para docker build
através da seguinte invocação de emu-docker
:
emu-docker create <emulator-zip> <system-image-zip> [--dest docker-src-dir
(getcwd()/src by default)]
Isso coloca todos os elementos certos para executar uma imagem do Docker, mas ainda não constrói, executa ou publica. Um arquivo zip do emulador Linux deve ser usado.
Para construir a imagem do docker correspondente a esses emuladores e imagens do sistema:
docker build <docker-src-dir, either ./src or specified argument to
emu_docker.py>
Um ID da imagem do Docker será lançado; salve este id de imagem.
Atualmente, assumimos que o KVM será usado com o Docker para fornecer recursos de virtualização da CPU à imagem do Docker resultante.
Nós fornecemos o seguinte script de execução:
./run.sh <docker-image-id> <additional-emulator-params>
Faz o seguinte:
docker run -e ADBKEY="$(cat ~/.android/adbkey)"
--device /dev/kvm
--publish 8554:8554/tcp
--publish 5555:5555/tcp <docker-image-id>
--device /dev/kvm
para ter aceleração da CPUNota: Você pode usar um adbkey público injetando a variável adbkey_pub, ou seja: -e adbkey_pub = "$ (cat ~/.android/adbkey.pub)"
Você também tem a opção de montar a partição de dados A /que o emulador usará se disponível. Isso permite que você use um TMPFS que possa proporcionar um desempenho aumentado, especialmente no cenário de virtualização aninhada.
Por exemplo:
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>
Atualmente, suportamos apenas a aceleração de hardware para a NVIDIA. Para fazer uso de aceleração de hardware, talvez seja necessário instalar as extensões do NVIDIA Docker a partir daqui se estiver executando uma versão mais antiga do Docker (<19.03). Você deve garantir que você tenha uma instalação X mínima se estiver usando uma instância em nuvem. Por exemplo, XVFB pode ser usado. Você deve construir os contêineres passando na bandeira - -GPU:
emu-docker create stable Q --gpu
Agora você pode iniciar o emulador com o script run-with-gpu.sh
:
./run-with-gpu.sh <docker-image-id> <additional-emulator-params>
O script é semelhante ao descrito acima com a adição que será:
--gpu all
)A aceleração do hardware melhorará significativamente o desempenho dos aplicativos que dependem fortemente de gráficos. Observe que, embora precisemos de um servidor X11 para aceleração da GPU, não haverá interface do usuário.
Você pode empurrar as imagens criadas para um repositório, fornecendo os parâmetros - -Push e --repo e - -TAG ao criar uma imagem. O parâmetro - -TAG é opcional e é usado para indicar a versão da imagem criada. Isso padrão é o Build-ID do emulador, pois as imagens do sistema raramente são atualizadas.
Adotamos o seguinte esquema de nomeação para imagens:
{api}-{sort}-{abi}
Onde:
Por exemplo: 29-PlayStore-X86: 30.1.2 Indica uma imagem do sistema habilitada para Playstore com Q em execução no x86 de 32 bits.
Um exemplo de invocação para publicar todas as imagens Q no Google Cloud Repo pode ser:
emu-docker -v create --push --repo us.gcr.io/emulator-project/ stable " Q "
Imagens que foram empurradas para um repositório podem ser lançadas diretamente do repositório. Por exemplo:
docker run --device /dev/kvm --publish 8554:8554/tcp --publish 5555:5555/tcp
us.gcr.io/emulator-project/29-playstore-x86:30.1.2
Encaminhamos a porta 5555 para acesso ADB ao emulador em execução dentro do contêiner. O ADB pode não detectar automaticamente o dispositivo, então execute:
adb connect localhost:5555
Seu dispositivo agora deve aparecer como:
$ adb devices
List of devices attached:
localhost:5555 device
Esse repositório também contém um exemplo que demonstra como você pode usar o Docker para tornar o emulador acessível através da Web. Isso é feito compondo o seguinte conjunto de contêineres do Docker:
Para executar esta amostra e poder interagir com o emulador, você deve ter o seguinte em mente:
Você precisará do Docker-Compose.
Você deve ter a porta 80 e 443 disponíveis. Os contêineres do Docker criarão uma rede interna e exporão as portas HTTP e HTTPS.
Você precisará criar uma imagem do Docker emulador, conforme descrito na documentação acima.
Dependendo da sua rede, você pode precisar fazer
No momento, estamos usando o FireBase para lidar com autenticação e autorização. Você precisará fornecer uma configuração JSON do projeto que deseja usar. Você pode usar a amostra fornecida aqui, mas só funcionará no host local. Você pode obter a configuração do Firebase do console Coloque a configuração do Firebase Josn aqui:
./js/firebase_config.json
Isso será usado para gerar as configurações de configuração e enviado.
Para criar os contêineres da web, você deve ter as seguintes ferramentas disponíveis:
Em seguida, você deve criar um contêiner com a versão de imagem do emulador e sistema que deseja usar. Por exemplo:
. ./configure.sh && emu-docker create canary "P.*x86_64"
Depois de cuidar das etapas acima, você pode criar os contêineres usando o 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
Por exemplo:
./create_web_container.sh
Isso fará o seguinte:
Agora você pode iniciar o contêiner da seguinte maneira:
docker-compose -f js/docker/docker-compose.yaml up
Se você deseja disponibilizar o ADB, pode aplicar a sobreposição encontrada no JS/Docker/Development.yaml da seguinte forma:
docker-compose -f js/docker/docker-compose.yaml -f js/docker/development.yaml up
Aponte seu navegador para a localhost. Você provavelmente receberá um aviso devido ao uso do certificado auto -assinado. Depois de aceitar o certificado, você poderá fazer login e começar a usar o emulador.
Lembre -se das seguintes coisas quando tornar o emulador acessível sobre o ADB:
~/.android/adbkey
. Esta é a chave privada usada pelo ADB. Sem isso, você não poderá acessar o dispositivo sobre o ADB.adb connect ip-address-of-container:5555
antes de interagir com o dispositivo. Por exemplo: $ adb connect localhost:5555
$ adb shell getprop
Existe um script de amostra de entrada de nuvem que fornece detalhes sobre como você pode configurar uma instância que iniciará e configurará automaticamente um emulador na criação. Detalhes sobre como fazer isso podem ser encontrados aqui.
Temos um documento separado relacionado a lidar com problemas.
Detalhes sobre o design e como modificar o aplicativo React podem ser encontrados aqui