Se você publicar seu app no Google Play, será necessário criar e fazer upload de um Android App Bundle. Quando você faz isso, o Google Play gera e exibe automaticamente APKs otimizados para a configuração do dispositivo de cada usuário para que eles façam o download apenas do código e dos recursos necessários para executar o app. A publicação de vários APKs é útil se você não está publicando no Google Play, mas precisa criar, assinar e gerenciar cada APK.
Ao desenvolver seu aplicativo Android para aproveitar vários APKs no Google Play, é importante adotar algumas práticas recomendadas desde o início e evitar dores de cabeça desnecessárias no processo de desenvolvimento. Esta lição mostra como criar vários APKs do seu do app, cada um cobrindo uma classe diferente de tamanho de tela. Você também terá algumas ferramentas necessárias para simplificar o máximo possível a manutenção de um codebase de vários APKs.
Confirmar que você precisa de vários APKs
Ao tentar criar um aplicativo que funcione na enorme variedade de modelos Android é natural, naturalmente você quer que o aplicativo tenha a melhor aparência em cada dispositivo. Você quer aproveitar o espaço das telas grandes, mas ainda trabalhar em pequenas, para usar a nova API do Android recursos ou texturas visuais disponíveis em dispositivos modernos, mas sem deixar de lado os mais antigos. Talvez no início, parece que o suporte a vários APKs é a melhor solução, mas essa nem sempre é a caso. A página Como usar A seção de APK único do guia de APKs múltiplos inclui algumas informações úteis sobre como fazer tudo isso com um único APK, incluindo o uso da nossa Biblioteca de Suporte, e links para recursos em todo o guia para desenvolvedores Android.
Se você puder gerenciá-lo, limitar seu aplicativo a um único APK tem várias vantagens, incluindo:
- É mais fácil fazer publicações e testes.
- Há apenas um codebase para manter.
- Seu aplicativo pode se adaptar às mudanças de configuração do dispositivo.
- A restauração de apps é funcional em vários dispositivos.
- Você não precisa se preocupar com preferências de mercado, comportamento de "upgrades" de um APK para o ou qual APK combina com qual classe de dispositivos
O restante desta lição pressupõe que você pesquisou o tópico, absorveu cuidadosamente os material nos recursos vinculados e determinou que vários APKs são o caminho certo para sua para o aplicativo.
Organizar seus requisitos
Comece criando um gráfico simples para determinar rapidamente de quantos APKs você precisa e de qual tela tamanhos de cada APK. Felizmente, não é difícil mapear seus requisitos de maneira rápida, fácil e ter uma referência simples para uso posterior. Digamos que você queira dividir seus APKs em duas dimensões: e o tamanho da tela. Crie uma tabela com uma linha e uma coluna para cada par possível de valores e cores em alguns "blobs", sendo que cada cor representa um APK.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| pequeno | |||||||||||
| normal | |||||||||||
| grande | |||||||||||
| extra grande |
Acima, há um exemplo com quatro APKs. A cor azul corresponde a todos os dispositivos de tela pequena/normal, verde corresponde a dispositivos de tela grande e vermelho dispositivos de tela extra grande, todos com nível de API de 3 a 10. O roxo é um caso especial, já que para todos os tamanhos de tela, mas apenas para a API de nível 11 e mais recentes. Mais importante ainda, olhando para este gráfico, você sabe imediatamente qual APK abrange qualquer combinação de tamanho de tela/API. Para inicialização, você também tem codinomes elegantes para cada um, já que "Testamos o vermelho no ?" é muito mais fácil perguntar para seu amigo do que "Testamos o APK extra grande de 3 a 10 em comparação com o Xoom?". Imprimir isto criar um gráfico e entregá-lo a todas as pessoas que trabalham na sua base de código. Isso facilitará muito sua vida.
Colocar todos os códigos e recursos comuns em um projeto de biblioteca
Seja para modificar um aplicativo Android já existente ou iniciar um do zero, esse é o a primeira coisa que você precisa fazer na base de código e, de longe, a mais importante. Tudo que vai para o projeto da biblioteca só precisa ser atualizada uma vez (por exemplo, strings localizadas em idiomas, temas de cores, bugs corrigidos no código compartilhado), o que melhora o tempo de desenvolvimento e reduz probabilidade de erros que poderiam ter sido facilmente evitados.
Observação: embora os detalhes de implementação de como criar e incluir projetos de biblioteca estejam fora do escopo desta lição, você pode se orientar lendo Criar uma biblioteca Android.
Se você estiver convertendo um aplicativo existente para usar o suporte a vários APKs, vasculhe sua base de código para encontrar cada arquivo de string localizado, lista de valores, tema cores, ícones de menu e layout que não serão alterados nos APKs e colocar tudo isso no projeto da biblioteca. Um código que não muda muito deve também vão para o projeto da biblioteca. Você provavelmente vai estender essas classes para adicionar um método ou dois de APK para APK.
Se, por outro lado, você estiver criando o aplicativo do zero, tente escrever código no projeto da biblioteca primeiro, depois só movê-lo para uma APK individual, se necessário. Isso é muito mais fácil de gerenciar a longo prazo do que adicioná-lo. depois outro, depois outro, meses depois tentando descobrir se esse blob pode ser movido para cima à seção da biblioteca sem estragar nada.
Criar novos projetos de APK
Haverá um projeto Android diferente para cada APK que você gerará. Para facilitar , coloque o projeto da biblioteca e todos os projetos APK relacionados na mesma pasta pai. Cada APK precisa ter o mesmo nome de pacote, embora não tenha precisa compartilhar o nome do pacote com a biblioteca. Se você tivesse três APKs seguindo o esquema descrito anteriormente, seu diretório raiz pode ter esta aparência:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-purple foo-red
Depois que os projetos forem criados, adicione o projeto da biblioteca como referência para cada projeto de APK. Se possível, defina a atividade inicial no projeto da biblioteca e estenda essa atividade no seu APK em um projeto de IA. Ter uma atividade inicial definida no projeto da biblioteca dá a você a chance de colocar toda a inicialização do aplicativo em um só lugar, para que cada APK não precise reimplementar tarefas "universais", como inicializar o Google Analytics, executar verificações de licenciamento e qualquer outro procedimento de inicialização que não mude muito de APK para APK.
Ajustar os manifestos
Quando um usuário faz o download de um aplicativo que usa vários APKs no Google Play, a resposta correta O APK a ser usado é escolhido usando duas regras simples:
- O manifesto precisa mostrar que determinado APK é qualificado.
- Dos APKs qualificados, o número de versão mais alto ganha.
Como exemplo, vamos usar o conjunto de vários APKs descritos anteriormente e presumir que cada O APK foi configurado para oferecer suporte a todos os tamanhos de tela maiores que o "destino" tamanho da tela. Vamos analisar no gráfico de amostra de antes:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| pequeno | |||||||||||
| normal | |||||||||||
| grande | |||||||||||
| extra grande |
Como a cobertura pode ser sobreposta, podemos descrever a área coberta por cada APK desta forma:
- Azul: abrange todas as telas, minSDK 3.
- Verde: telas grandes e maiores, minSDK 3.
- Vermelho: telas extra grandes (geralmente tablets), minSDK 9.
- Roxo: abrange todas as telas, minSDK 11.
Observe que há muita sobreposição nessas regras. Por exemplo, uma Um dispositivo extragrande com API de nível 11 pode executar qualquer um dos quatro APKs especificados. No entanto, usar o "número de versão mais alto vence" regra, podemos definir uma ordem de preferência da seguinte forma:
Roxo ≥ Vermelho ≥ Verde ≥ Azul
Por que permitir essa sobreposição? Vamos supor que o APK roxo tenha algum requisito para que o os outros dois não. Página Filtros no Google Play do guia do desenvolvedor Android tem uma lista completa de possíveis culpados. Como exemplo, vamos supor que a cor roxa precise de uma câmera frontal. Na verdade, o objetivo da cor roxa é use entretenimento com a câmera frontal! Mas nem todos os dispositivos com API de nível 11 ou mais recente TÊM câmeras frontais! Ah, não!
Felizmente, se um usuário navegar no Google Play usando um desses dispositivos, o Google Play analisará a veja que a cor roxa lista a câmera frontal como um requisito e a ignora silenciosamente. depois de concluir que a Roxa e aquele dispositivo não são uma combinação perfeita. Em seguida, ele ver que o vermelho não é compatível apenas com dispositivos extragrandes, mas também não se importa se o temos uma câmera frontal! O usuário ainda pode fazer o download do app no Google Play, porque, apesar de todo o contratempo com a câmera frontal, havia um APK que oferecia suporte a esse Nível da API.
Para manter todos os seus APKs em "faixas" separadas, é importante ter um bom esquema de código de versão. O recomendado pode ser encontrado na área de Códigos de versão do nosso guia para desenvolvedores. Vale a pena ler a seção inteira, mas a essência básica é para esse conjunto de nos APKs, usaríamos dois dígitos para representar o minSDK, dois para representar o tamanho mínimo/máximo da tela e três. para representar o número do build. Dessa forma, quando o dispositivo fizer upgrade para uma nova versão do Android, (por exemplo, de 10 a 11), todos os APKs qualificados e preferidos em relação ao instalado no momento seria vista pelo dispositivo como um "upgrade". O esquema de número da versão, quando aplicado ao exemplo de APKs, pode ser semelhante a:
Azul: 0304001, 0304002, 0304003…
Verde: 0334001, 0334002, 0334003
Vermelho: 0344001, 0344002, 0344003...
Roxo: 1104001, 1104002, 1104003...
Juntando tudo isso, seus manifestos do Android provavelmente se pareceriam com o seguintes:
Azul:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0304001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Verde:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0334001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Vermelho:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0344001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
Roxo:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Tecnicamente, vários APKs funcionarão com a tag "supports-screens" ou com a tag "compatible-screens". Suporte a telas é a preferência e geralmente é um problema ideia usar ambos. Isso torna as coisas desnecessariamente complicadas e aumenta a chance de erros. Observe também que, em vez de aproveitar os valores padrão (pequeno e normal são sempre verdadeiros por padrão), os manifestos definem explicitamente o valor para cada tamanho de tela. Isso pode economizar dores de cabeça: por exemplo, um manifesto com um SDK de destino de < 9 vai ter extragrande definido automaticamente como falso, porque esse tamanho ainda não existia. Por isso, seja explícito.
Analisar a lista de verificação de pré-lançamento
Antes de fazer upload para o Google Play, verifique os itens a seguir. Lembre-se de que essas são são especificamente relevantes para vários APKs e de forma alguma representam uma lista de verificação completa para todos os aplicativos sendo enviados ao Google Play.
- Todos os APKs precisam ter o mesmo nome de pacote.
- Todos os APKs precisam ser assinados com o mesmo certificado.
- Caso os APKs se sobreponham na versão da plataforma, aquele com a minSdkVersion mais recente precisa ter um códigos de versão mais recentes.
- No manifesto, defina como verdadeiro cada tamanho de tela que você quer que seja compatível com o APK. Todos os tamanhos de tela que você quer evitar, defina como falso.
- Verifique se há informações conflitantes nos filtros do manifesto (um APK que só é compatível com cupcake em telas extragrandes não será vista por ninguém)
- Cada manifesto do APK precisa ser exclusivo em pelo menos um dos tipos de tela, textura OpenGL ou versão da plataforma compatível.
- Tente testar cada APK em pelo menos um dispositivo. Fazendo isso, você tem um dos recursos e emuladores de dispositivos personalizáveis na sua máquina de desenvolvimento. O céu é o limite!
Também vale a pena inspecionar o APK compilado antes de enviar ao mercado para garantir que não haja surpresas que possam esconder seu aplicativo no Google Play. Na verdade, isso é bem simples "aapt" ferramenta. O Aapt (Android Asset Packaging Tool) é parte do processo de compilação para criação e para empacotar seus aplicativos Android e também é uma ferramenta muito útil para inspecioná-los.
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Ao examinar a saída aapt, verifique se não há valores conflitantes para com suporte a telas e telas compatíveis, e que você não tenha "uses-feature" não intencionais valores que foram adicionadas como resultado de permissões definidas no manifesto. No exemplo acima, o APK será invisível para a maioria dos dispositivos, se não todos.
Por quê? Ao adicionar a permissão SEND_SMS necessária, o requisito de recurso de android.hardware.telephony é adicionado implicitamente. Como a maioria dos dispositivos extra grandes (se não todos) são tablets sem hardware de telefonia, o Google Play filtrará esse APK nesses casos até que apareçam novos dispositivos grandes o suficiente para informar um tamanho de tela extra grande e que tenham hardware de telefonia.
Felizmente, isso é facilmente corrigido adicionando o seguinte ao seu manifesto:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
O requisito android.hardware.touchscreen também é adicionado implicitamente. Se você quiser que seu APK fique visível em TVs que não tenham tela touchscreen, adicione o seguinte ao manifesto:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
Depois de concluir a lista de verificação de pré-lançamento, faça upload dos seus APKs para o Google Play. Pode demorar um pouco para o aplicativo aparecer ao navegar pelo Google Play, mas, quando isso acontecer, faça uma última verificação. Faça o download do aplicativo em qualquer dispositivo de teste para verificar se os APKs estão segmentando os dispositivos pretendidos. Parabéns, você terminou!