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 que abrangem um intervalo ligeiramente diferente de níveis de API. Você também vai conhecer algumas ferramentas necessário para tornar a manutenção de uma base de código de vários APKs o mais simples possível.
Confirmar que você precisa de vários APKs
Ao tentar criar um aplicativo que funcione em várias gerações da Android é natural, naturalmente você quer que seu aplicativo aproveite os novos recursos de novos dispositivos, sem sacrificar a compatibilidade com versões anteriores. No início, pode parecer que vários APKs suporte é a melhor solução, mas muitas vezes não é o caso. A seção Como usar um APK único A seção "Em vez disso" do guia de APKs múltiplos traz algumas informações úteis sobre como fazer isso com um único APK, incluindo o uso da nossa biblioteca de suporte. Você também pode aprender escrever código que é executado apenas em determinados níveis de API em um único APK, sem recorrer a técnicas caras em termos computacionais, como reflexão de neste artigo.
Se você puder gerenciá-lo, limitar seu aplicativo a um único APK tem vários vantajosas, 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 API de cada APK. Como referência útil, a página Versões da plataforma do O site do desenvolvedor Android fornece dados sobre o número relativo de dispositivos ativos que executam um determinado mais recente da plataforma Android. Além disso, embora pareça fácil no início, acompanhar qual grupo de níveis de API que cada APK vai segmentar fica difícil rapidamente, especialmente se houver pode haver sobreposição (geralmente há). Felizmente, é fácil mapear seus requisitos rapidamente, facilmente e ter uma referência fácil para mais tarde.
Para criar seu gráfico de vários APKs, comece com uma linha de células representando o em vários níveis de API da plataforma Android. Coloque uma célula extra no final para representar o futuro mais recentes do Android.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Agora, basta colorir o gráfico de forma que cada cor represente um APK. Confira um exemplo de como é possível aplicar cada APK a um determinado intervalo de níveis de API.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Depois de criar o gráfico, distribua-o para sua equipe. Comunicação da equipe em seu projeto ficou imediatamente mais simples, já que, em vez de perguntar "Como está o APK para os níveis de API 3 a 6, em vez de perguntar "Como está o APK para os níveis de API 3 a 6, o Android 1.x. Como é mesmo?" Basta dizer "Como o APK azul está chegando junto?"
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 a implementação detalha como criar e incluem projetos de biblioteca estão fora do escopo desta aula, você poderá 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 acabará estendendo essas para adicionar um ou dois métodos 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, mas não necessariamente 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-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 todas a inicialização do seu aplicativo em um só lugar, para que cada APK não precise reimplementar "universal" tarefas como inicializar o Google Analytics, executar verificações de licenciamento e quaisquer outras procedimentos de inicialização que não mudam 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 não definir um nível máximo de API para qualquer um dos APKs. Tomados individualmente, o possível intervalo de cada APK seria fica assim:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Porque é necessário que um APK com uma minSdkVersion posterior também tenha um código de versão superior, sabemos que, em termos de valores de versionCode, vermelho ≥ verde ≥ azul. Portanto, podemos recolher o gráfico da seguinte maneira:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Agora, vamos supor que o APK vermelho tem alguns requisitos que os outros dois não têm. Filtros no Google Play na página de o guia do desenvolvedor Android tem uma lista de possíveis culpados. Para o Por exemplo, vamos supor que o vermelho exija uma câmera frontal. Na verdade, todo o objetivo o APK vermelho é combinar a câmera frontal com novas funcionalidades que foram adicionadas na API. 11. Entretanto, nem todos os dispositivos com API de nível 11 ou superior têm câmeras frontais. A terror!
Felizmente, se um usuário navegar no Google Play usando um desses dispositivos, o Google Play analisará a veja que o vermelho lista a câmera frontal como um requisito e a ignora silenciosamente, definindo determinou que o vermelho e aquele dispositivo não são a combinação perfeita para o paraíso digital. Em seguida, ele verá que O verde não é compatível apenas com versões futuras de dispositivos com a API 11 (já que nenhuma maxSdkVersion foi definida), mas também não importa se há ou não uma câmera frontal. Ainda é possível fazer o download do app do Google Play pelo usuário, porque, apesar de todo o contratempo com a câmera frontal, havia uma um APK compatível com esse nível de API específico.
Para manter todos os APKs em "faixas" separadas, é importante ter um bom código de versão. esquema. O recomendado pode ser encontrado na área de Códigos de versão do nosso guia para desenvolvedores. Como o conjunto de exemplos de APKs lida apenas com um dos três seria suficiente separar cada APK por 1.000, defina os primeiros dígitos como minSdkVersion para esse APK específico e incrementar a partir daí. O resultado será algo como o seguinte:
Azul: 03001, 03002, 03003, 03004…
Verde: 07001, 07002, 07003, 07004...
Vermelho:11001, 11002, 11003, 11004...
Juntando tudo isso, os manifestos do Android provavelmente teriam esta aparência:
Azul:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="03001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="3" /> ...
Verde:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="07001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="7" /> ...
Vermelho:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="11001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="11" /> ...
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 esses itens são especificamente relevantes para vários APKs e não representam uma lista de verificação completa para todos os aplicativos enviados ao Google Play.
- Todos os APKs precisam ter o mesmo nome de pacote.
- Todos os APKs precisam ser assinados com o mesmo certificado.
- Se houver sobreposição de APKs na versão da plataforma, o que tiver a minSdkVersion mais recente precisa ter um código de versão posterior.
- Verifique seus filtros de manifesto em busca de informações conflitantes. Um APK que só aceita o Android Cupcake em telas extra grandes, por exemplo, não será visto 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ê terá um dos emuladores de dispositivos mais personalizáveis do mercado 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" . 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: 'small' 'normal' 'large' '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 não ficará visível para muitos dispositivos.
Por quê? Ao adicionar a permissão necessária SEND_SMS, o requisito de recurso de android.hardware.telephony é adicionado implicitamente. Como a API de nível 11 é o Honeycomb (versão do Android otimizada especialmente para tablets) e nenhum dispositivo Honeycomb tem hardware de telefonia, o Google Play filtrará esse APK em todos os casos até o surgimento de dispositivos futuros com níveis de API mais altos e também com hardware de telefonia.
Felizmente, isso é corrigido de forma simples 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!