Ao definir targetSdkVersion = "xx", você certifica que seu aplicativo funciona corretamente (por exemplo, foi exaustivamente testado com êxito) no nível da API xx.
Uma versão do Android em execução no nível da API acima de xx aplicará o código de compatibilidade automaticamente para oferecer suporte a todos os recursos em que você possa confiar que estavam disponíveis no nível xx da API ou antes, mas que agora estão obsoletos no nível superior da versão do Android.
Por outro lado, se você estiver usando quaisquer recursos que se tornaram obsoletos no nível xx ou anterior , o código de compatibilidade não será aplicado automaticamente pelas versões do SO em níveis mais altos da API (que não incluem mais esses recursos) para dar suporte a esses usos. Nessa situação, o seu próprio código deve ter cláusulas de casos especiais que teste o nível API e, se o nível OS detectado é um superior que já não tem a determinado recurso API, seu código deve usar recursos alternativos que estão disponíveis nos executam de OS Nível da API.
Se isso não for possível, talvez alguns recursos da interface não apareçam que normalmente acionariam eventos dentro do seu código, e talvez você esteja perdendo um recurso crítico da interface que o usuário precisa para acionar esses eventos e acessar sua funcionalidade (como no exemplo abaixo).
Conforme indicado em outras respostas, você pode definir targetSdkVersion maior que minSdkVersion se desejar usar alguns recursos da API definidos inicialmente em níveis de API mais altos que o minSdkVersion e tiver tomado medidas para garantir que seu código possa detectar e manipular a ausência desses recursos em níveis mais baixos que targetSdkVersion.
Para avisar os desenvolvedores a testarem especificamente o nível mínimo de API necessário para usar um recurso, o compilador emitirá um erro (não apenas um aviso) se o código contiver uma chamada para qualquer método definido em um nível de API posterior a minSdkVersion, mesmo que targetSdkVersion seja maior ou igual ao nível da API em que esse método foi disponibilizado pela primeira vez. Para remover esse erro, a diretiva do compilador
@TargetApi(nn)
informa ao compilador que o código no escopo dessa diretiva (que precederá um método ou uma classe) foi gravado para testar um nível de API de pelo menos nn antes de chamar qualquer método que dependa de pelo menos esse nível de API . Por exemplo, o código a seguir define um método que pode ser chamado a partir do código em um aplicativo que possui uma minSdkVersion menor que 11 e uma targetSdkVersion 11 ou superior:
@TargetApi(11)
public void refreshActionBarIfApi11OrHigher() {
//If the API is 11 or higher, set up the actionBar and display it
if(Build.VERSION.SDK_INT >= 11) {
//ActionBar only exists at API level 11 or higher
ActionBar actionBar = getActionBar();
//This should cause onPrepareOptionsMenu() to be called.
// In versions of the API prior to 11, this only occurred when the user pressed
// the dedicated menu button, but at level 11 and above, the action bar is
// typically displayed continuously and so you will need to call this
// each time the options on your menu change.
invalidateOptionsMenu();
//Show the bar
actionBar.show();
}
}
Você também pode declarar um targetSdkVersion mais alto se tivesse testado nesse nível mais alto e tudo funcionasse, mesmo se você não estivesse usando nenhum recurso de um nível de API superior ao seu minSdkVersion. Isso seria apenas para evitar a sobrecarga de acessar o código de compatibilidade destinado a se adaptar do nível de destino até o nível mínimo, pois você teria confirmado (por meio de testes) que essa adaptação não era necessária.
Um exemplo de um recurso de interface do usuário que depende do targetSdkVersion declarado seria o botão de menu com três pontos verticais que aparece na barra de status de aplicativos com targetSdkVersion menor que 11, quando esses aplicativos estão em execução na API 11 e superior. Se o seu aplicativo tiver uma targetSdkVersion igual ou inferior a 10, presume-se que a interface do aplicativo dependa da existência de um botão de menu dedicado e, portanto, o botão de três pontos parece substituir o hardware dedicado anterior e / ou as versões na tela desse botão (por exemplo, como visto no Gingerbread) quando o sistema operacional tiver um nível de API mais alto para o qual um botão de menu dedicado no dispositivo não será mais assumido. No entanto, se você definir o targetSdkVersion do seu aplicativo para 11 ou superior, presume-se que você tenha aproveitado os recursos introduzidos nesse nível que substituem o botão de menu dedicado (e. g., a Barra de Ação), ou que você contornou a necessidade de ter um botão de menu do sistema; consequentemente, o menu de três pontos verticais "botão de compatibilidade" desaparece. Nesse caso, se o usuário não conseguir encontrar um botão de menu, ele não poderá pressioná-lo e isso, por sua vez, significa que a substituição de onCreateOptionsMenu (menu) da sua atividade nunca poderá ser chamada, o que, por sua vez, significa que uma parte significativa da funcionalidade do seu aplicativo pode ser privada da interface do usuário. A menos, é claro, que você tenha implementado a Barra de Ação ou algum outro meio alternativo para o usuário acessar esses recursos. para encontrar um botão de menu, ela não pode pressioná-lo, e isso, por sua vez, significa que a substituição onCreateOptionsMenu (menu) da sua atividade talvez nunca seja invocada, o que, por sua vez, significa que uma parte significativa da funcionalidade do seu aplicativo pode ser privado de sua interface com o usuário. A menos, é claro, que você tenha implementado a Barra de Ação ou outro meio alternativo para o usuário acessar esses recursos. para encontrar um botão de menu, ela não pode pressioná-lo, e isso, por sua vez, significa que a substituição onCreateOptionsMenu (menu) da sua atividade talvez nunca seja invocada, o que, por sua vez, significa que uma parte significativa da funcionalidade do seu aplicativo pode ser privado de sua interface com o usuário. A menos, é claro, que você tenha implementado a Barra de Ação ou outro meio alternativo para o usuário acessar esses recursos.
O minSdkVersion, por outro lado, estabelece um requisito de que a versão do sistema operacional de um dispositivo tenha pelo menos esse nível de API para executar seu aplicativo. Isso afeta quais dispositivos podem ver e baixar seu aplicativo quando ele está na loja de aplicativos do Google Play (e possivelmente em outras lojas de aplicativos). É uma maneira de afirmar que seu aplicativo depende de recursos do SO (API ou outro) que foram estabelecidos nesse nível e não possui uma maneira aceitável de lidar com a ausência desses recursos.
Um exemplo do uso de minSdkVersion para garantir a presença de um recurso não relacionado à API seria definir minSdkVersion como 8 para garantir que seu aplicativo seja executado apenas em uma versão habilitada para JIT do interpretador Dalvik (desde que o JIT foi introduzido para o intérprete do Android no nível 8 da API). Como o desempenho de um intérprete habilitado para JIT pode ser até cinco vezes maior do que aquele que não possui esse recurso, se o aplicativo fizer uso pesado do processador, convém exigir o nível 8 ou superior da API para garantir o desempenho adequado.
