Criar Instalador App gerar um arquivo apk Android

O que você vai precisar antes de começar

• Node.js instalado na máquina
• Um projeto Expo funcionando (rodando com npx expo start)
• Uma conta gratuita em expo.dev

Não é necessário ter o Android Studio instalado para o caminho principal deste artigo — o build roda na nuvem da Expo, o que facilita bastante em laboratórios ou notebooks mais simples.

Passo 1: Definir o nome de exibição do app

Antes de qualquer build, vale acertar como o app vai aparecer para quem instalar — tanto o nome que aparece embaixo do ícone quanto um identificador interno do projeto. Isso é feito no arquivo app.json, na raiz do projeto:

{
  "expo": {
    "name": "Meu Primeiro App",
    "slug": "meu-primeiro-app"
  }
}

• name: é o nome que aparece na tela do celular, embaixo do ícone. Pode ter espaços e acentos normalmente.
• slug: um identificador interno usado pela Expo (sem espaços, sem acentos, tudo minúsculo). Não aparece para o usuário final, mas precisa existir.

Passo 2: Definir o identificador do pacote Android

Além do nome visível, o Android exige um identificador único e permanente para o app — o “package name”. Ele segue o formato de domínio invertido e, uma vez publicado, não pode ser alterado sem que o app seja tratado como um aplicativo novo. Vale pensar nesse nome com calma já na primeira vez:

{
  "expo": {
    "android": {
      "package": "com.seunome.meuprimeiroapp"
    }
  }
}

Esse campo é o motivo mais comum de um build falhar logo na primeira tentativa — sem ele, o EAS não sabe como identificar seu aplicativo no sistema Android.

Passo 3: Criar e configurar o ícone do app

O ícone é uma das primeiras coisas que dão a sensação de “app de verdade” em vez de projeto de teste. No Expo, ele é uma simples referência de imagem dentro do app.json.

Preparando a imagem

• Formato: PNG
• Tamanho recomendado: 1024x1024px
• Salve o arquivo dentro de uma pasta assets/ na raiz do projeto, por exemplo como assets/icon.png

Apontando para ela no app.json

{
  "expo": {
    "icon": "./assets/icon.png"
  }
}

Ícone adaptativo para Android

O Android moderno usa “adaptive icons”: uma camada de desenho (foreground) separada de uma cor ou imagem de fundo, para o sistema poder recortar automaticamente em formatos diferentes (círculo, quadrado arredondado, gota, etc.):

{
  "expo": {
    "android": {
      "adaptiveIcon": {
        "foregroundImage": "./assets/adaptive-icon.png",
        "backgroundColor": "#E30613"
      }
    }
  }
}

Duas observações importantes:

• O foregroundImage também deve ter 1024x1024px, mas mantenha o desenho principal dentro de uma área central de aproximadamente 660x660px — as bordas costumam ser cortadas pelo sistema, dependendo do formato do ícone no aparelho.
• O backgroundColor é uma cor sólida (código hexadecimal) exibida atrás do desenho.

Passo 4: Configurar a tela de splash (opcional, mas recomendado)

A splash screen é a tela exibida enquanto o app carrega, logo após o toque no ícone. Também é configurada por imagem:

{
  "expo": {
    "splash": {
      "image": "./assets/splash.png",
      "resizeMode": "contain",
      "backgroundColor": "#FFFFFF"
    }
  }
}

resizeMode pode ser contain (mantém a imagem inteira, com espaço ao redor) ou cover (preenche a tela toda, podendo cortar as bordas da imagem).

Passo 5: Definir a versão do app

Ainda no app.json, vale conferir os campos de versão — importantes principalmente se o app for atualizado no futuro:

{
  "expo": {
    "version": "1.0.0",
    "android": {
      "versionCode": 1
    }
  }
}

• version: a versão “visível”, no formato semântico (major.minor.patch)
• versionCode: um número inteiro interno do Android, que precisa aumentar a cada nova versão publicada (1, 2, 3…)

Passo 6: Instalar o EAS CLI

O EAS (Expo Application Services) é a ferramenta oficial da Expo para gerar builds nativos. Instale globalmente:

npm install -global eas-cli

Depois, faça login com a sua conta Expo:

eas login

Se aparecer o erro “eas não é reconhecido”: normalmente é o Windows não achar o comando no PATH. Uma alternativa rápida, sem depender de instalação global, é usar:

npx eas-cli login

Passo 7: Configurar o projeto para build

Dentro da pasta do projeto, rode:

eas build:configure

Se aparecer o erro “eas não é reconhecido”:

npx eas-cli build:configure

Esse comando cria um arquivo eas.json na raiz do projeto, com perfis de build pré-definidos (development, preview e production). É esse arquivo que vai controlar como o Expo empacota seu app.

Passo 8: Escolher entre APK e AAB

Por padrão, o EAS gera um arquivo .aab (Android App Bundle), que é o formato exigido pela Google Play Store — mas ele não pode ser instalado diretamente em um celular.

Para gerar um .apk (ideal para testes, demonstrações e instalação manual), edite o perfil desejado no eas.json:

{
  "cli": {
    "version": ">= 23.2.0",
    "appVersionSource": "remote"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal",
      "android": {
        "buildType": "apk"
      }
    },
    "production": {
      "autoIncrement": true
    }
  },
  "submit": {
    "production": {}
  }
}

Passo 9: Rodar o build

Com tudo configurado, execute:

eas build --platform android --profile preview

Se aparecer o erro “eas não é reconhecido”:

npx eas-cli build --platform android --profile preview

O build acontece nos servidores da Expo — você pode acompanhar o progresso pelo terminal ou pelo painel em expo.dev. O processo costuma levar entre 10 e 20 minutos, dependendo da fila.

Ao terminar, o terminal exibe um link direto para baixar o arquivo .apk gerado.

Passo 10 (opcional): Gerar o build localmente, sem o EAS

Se preferir não depender da nuvem da Expo (ou tiver atingido o limite de builds do plano gratuito), é possível compilar direto na própria máquina com o Gradle, sem passar pelo EAS Build.

Pré-requisitos extras: Android Studio (ou Android SDK + Command Line Tools), JDK 17, e as variáveis de ambiente ANDROID_HOME e JAVA_HOME configuradas.

npx expo prebuild --platform android
cd android
./gradlew assembleDebug

No Windows, use gradlew.bat assembleDebug. O APK é gerado em:

android/app/build/outputs/apk/debug/app-debug.apk

Esse comando gera um APK já assinado com uma chave de debug automática — ótimo para testes e demonstrações, mas não indicado para distribuição real (veja a seção sobre keystore mais abaixo).

Passo 11: Instalar o APK no celular

Existem duas formas comuns:

• Pelo link de download: abra o link gerado pelo EAS diretamente no navegador do celular, baixe o arquivo e toque nele para instalar. O Android vai pedir para liberar a permissão “instalar de fontes desconhecidas” na primeira vez.
• Pelo ADB (com o celular conectado ao computador):

  adb install caminho/do/arquivo.apk

Entendendo o Android Keystore

Todo APK instalado em um Android precisa estar assinado digitalmente — é essa assinatura que garante ao sistema que o app veio de uma fonte confiável e que atualizações futuras realmente pertencem ao mesmo desenvolvedor. Essa assinatura é gerada a partir de um arquivo chamado keystore (.jks ou .keystore), que funciona como uma “chave privada” do seu app.

Alguns pontos importantes sobre o keystore:

• Ele precisa ser o mesmo em todas as versões futuras do app. Se você perder o keystore original, não consegue mais publicar atualizações do mesmo aplicativo — só pode subir como um app novo, com um pacote diferente.
• Guarde uma cópia segura (fora do computador do laboratório, por exemplo) junto com a senha usada para gerá-lo.
• Existe o keystore de debug (automático, só serve para testes locais) e o de release (o que realmente identifica seu app para distribuição).

Como o keystore entra em cada caminho de build

Se você seguiu o caminho do EAS Build (nuvem), não precisa se preocupar com nada disso na prática: na primeira vez que você roda o build, o EAS pergunta se quer gerar um keystore automaticamente — e ele mesmo cuida de guardar e reutilizar esse arquivo nos builds seguintes, associado à sua conta Expo.

Já se você optou pelo caminho local com expo prebuild + Gradle, o keystore fica sob sua responsabilidade:

• ./gradlew assembleDebug gera o APK já assinado com uma keystore de debug automática (própria do Android SDK) — perfeita para testes e demonstrações em aula, mas não deve ser usada para distribuir o app de verdade.
• ./gradlew assembleRelease exige uma keystore de release configurada manualmente. Sem ela, o build falha ou gera um APK sem assinatura válida, que só instala em modo debug.

Gerando uma keystore de release manualmente

Se o objetivo for um APK “de verdade” (não apenas para teste em sala), gere a keystore com o próprio JDK:

keytool -genkeypair -v -keystore release.keystore -alias meu-app -keyalg RSA -keysize 2048 -validity 10000

O comando vai pedir uma senha e alguns dados (nome, organização, etc.). Guarde a senha com cuidado — não existe recuperação se ela for perdida.

Depois, informe esse keystore no arquivo android/gradle.properties e no build.gradle do módulo app, apontando para o caminho do arquivo, o alias e as senhas. A documentação oficial do React Native tem o passo a passo completo de onde inserir cada trecho.

Erros comuns e como evitar

• Build falha por falta do “package”: confira o app.json antes de rodar o build.
• Gerou .aab em vez de .apk: revise o buildType no perfil usado dentro do eas.json.
• Limite de builds atingido: o plano gratuito do EAS tem um número limitado de builds por mês — vale acompanhar pelo painel da conta.
• Android bloqueia a instalação: normal na primeira vez — é só liberar “fontes desconhecidas” nas configurações de segurança do aparelho.
• Build local falha sem assinatura: confirme se está usando assembleDebug (para testes) ou se configurou corretamente a keystore de release para assembleRelease.
• Perdeu a keystore de release: infelizmente não tem como recuperar — futuras atualizações do app precisarão ser publicadas como um pacote novo. Guarde sempre uma cópia de backup.
• Ícone ou splash não atualizam: alterações nesses arquivos só aparecem em um novo build nativo — reiniciar o expo start não é suficiente, é preciso gerar o APK de novo.
• “eas não é reconhecido” no terminal: geralmente é falta do PATH configurado no Windows. Use npx eas-cli como alternativa rápida, ou ajuste a variável de ambiente PATH apontando para a pasta global do npm.

Checklist antes do primeiro build

1. Nome de exibição (name) e slug definidos
2. Identificador do pacote Android (android.package) definido, pensado para não precisar mudar depois
3. Ícone (icon e, de preferência, adaptiveIcon) configurado com imagem própria
4. Splash screen configurada (opcional, mas melhora a primeira impressão)
5. Versão (version e versionCode) definida
6. EAS CLI instalado e logado
7. eas.json configurado para gerar apk no perfil desejado

Resumo rápido

1. Personalize nome, ícone, splash e versão no app.json
2. Instale o EAS CLI e faça login
3. Configure o projeto com eas build:configure
4. Ajuste o eas.json para gerar apk
5. Rode eas build --platform android --profile preview
6. Baixe e instale o APK no celular
7. Se for distribuir de verdade, cuide da keystore de release

Com esse fluxo, sair de um projeto Expo funcionando até ter um APK instalável — já com nome, ícone e identidade visual próprios — leva pouco mais do que o tempo de espera do build, sem precisar montar um ambiente Android completo na máquina.