Expo EAS build no vibe coding: APK no Drive quando o emulador trava a live

O emulador do Android Studio puxou um monte de memória e travou a live. Martin saiu dali: gerou o APK do Fumava, subiu o ficheiro no Drive que já estava no computador e no telemóvel, descarregou e instalou por fora da Play Store.

Nos 68 min desta gravação ele não ditou o comando de Expo EAS build. Nomeou Expo.dev na stack. O que ficou no vídeo foi gerar 1 APK e levá-lo ao telemóvel pelo Drive.

O emulador do Android Studio trava a transmissão

Antes do teste interno, o app rodava no emulador. Martin disse o custo com a live ainda aberta:

Antes estava a testar no emulador, aí depois, como isto aqui puxa um monte de memória, até estava a travar a minha live por causa disso, aqueles emulador aqui da do Android Studio.

Noutra noite dele, a RAM decide entre Expo Go e emulador para ver o app. Aquela live mede memória para escolher como olhar a tela. Esta mede o que acontece quando o emulador e a transmissão pedem a mesma máquina. O teste sai do Android Studio e vai para o telemóvel.

Num post desta mesma live o emulador é o atalho do gate de 12 testadores. O caso daqui é o emulador ligado enquanto ele transmite. Se você transmite enquanto constrói, o emulador é mais um processo a pedir memória à mesma máquina que está a enviar o vídeo. Vale ver como isso terminou em vibe coding para nao confundir branch do git com canal do eas.

1 APK no Drive, depois no telemóvel

Ele gerou o APK e usou o Drive que já estava ligado nos 2 lados:

Aí depois eu comecei a gerar o APK, que é tipo o ficheiro de uma aplicação. Depois subi no meu drive, o drive que está aqui ligado tanto no meu computador como no meu telemóvel. descarregava o ficheiro, instalava o aplicação, não é, por fora da Play Store.

O Drive era o disco que ele já tinha no PC e no telemóvel. Instalar por fora da Play Store tirou o teste da janela do Android Studio e pôs o Fumava no aparelho.

A stack da noite, na voz dele:

A gente está usando é o Play Console, o Google Cloud Console, o Supase, o Expo.dev, o Revenue Cat e o Post Hog

Na stack, além do Play Console e do Google Cloud Console, ele nomeou Supabase, Expo.dev, Revenue Cat e PostHog. Expo.dev está na lista. O gesto gravado é gerar o APK com essa stack e sair do emulador. O comando de Expo EAS build não foi dito em voz alta. Vale ver como isso terminou em eas build.

Teste interno com o e-mail do telemóvel

O APK no aparelho veio primeiro, e só depois o teste interno. O e-mail que ele colocou é o da Play Store do telemóvel, diferente da conta de desenvolvimento:

coloquei o e-mail da minha conta que utilizo na Play Store no telemóvel, que é diferente desta que fiz aqui a o desenvolvimento.

Ele apontou o sítio onde isso entra:

Temos três versões de teste, ó. Teste interno, que era o que eu fiz, de facto

São 3 versões. A que ele fez de facto foi a interna. A ordem gravada começa no APK instalado à mão, passa pelo MVP e chega ao teste interno com a conta do aparelho.

O vibe coding quando o build vira ficheiro

Quando o emulador come a live, o vibe coding passa o teste para um ficheiro no telemóvel de verdade. Você gera o APK, sai do emulador e continua no aparelho.

Quem constrói em vibe coding e transmite ao mesmo tempo encontra o emulador a comer memória da live.

Mais tarde na mesma sessão o .aab já tinha ido para a Play Store. A pergunta que ficou foi como meter um design novo nesse ficheiro:

como é que eu integro isto no APK lá no ficheiro ponto A B que eu enviei para produção no Google.

O "ponto A B" é o .aab. O APK do Drive foi o atalho da transmissão; o .aab é o ficheiro que já estava enviado para produção. A integração do design novo ficou em aberto.

Se o emulador começar a travar a sua live, o próximo passo está neste vídeo. Gera o APK com a stack Expo.dev que ele nomeou, põe o ficheiro num Drive que o telemóvel já vê, instala por fora da Play Store e só depois volta ao teste interno com o e-mail da Play Store do aparelho. Os 68 min estão na live em que o emulador travou a transmissão.