APIs do Android 3.2

Nível da API: 13

O Android 3.2 (HONEYCOMB_MR2) é uma versão incremental da plataforma que adiciona novos recursos para usuários e desenvolvedores. As seções abaixo fornecem uma visão geral dos novos recursos e APIs para desenvolvedores.

Para desenvolvedores, a plataforma Android 3.2 está disponível como um componente para download do SDK do Android. A plataforma para download inclui uma biblioteca Android e uma imagem do sistema, além de um conjunto de aparências do emulador e muito mais. Para começar a desenvolver ou testar no Android 3.2, use o Android SDK Manager para fazer o download da plataforma no seu SDK.

Destaques da plataforma

Novos recursos para usuários

  • Otimizações para uma variedade maior de tablets

    O Android 3.2 inclui uma variedade de otimizações em todo o sistema para garantir uma ótima experiência do usuário em uma variedade maior de tablets.

  • Zoom de compatibilidade para apps de tamanho fixo

    O Android 3.2 introduz um novo modo de zoom de compatibilidade que oferece aos usuários uma nova maneira de visualizar apps de tamanho fixo em dispositivos maiores. O novo modo oferece uma alternativa dimensionada por pixels ao alongamento de interface padrão para apps que não foram projetados para serem executados em telas maiores, como em tablets. O novo modo está acessível aos usuários por um ícone de menu na barra do sistema para apps que precisam de suporte à compatibilidade.

  • Sincronização de mídia do cartão SD

    Em dispositivos compatíveis com cartão SD, agora os usuários podem carregar arquivos de mídia diretamente do cartão SD para os apps que os utilizam. Um recurso do sistema torna os arquivos acessíveis aos apps no armazenamento de mídia do sistema.

Novos recursos para desenvolvedores

  • API estendida para gerenciar o suporte a telas

    O Android 3.2 introduz extensões para a API de suporte a tela da plataforma para oferecer aos desenvolvedores outras maneiras de gerenciar a interface do aplicativo em uma variedade de dispositivos Android. A API inclui novos qualificadores de recursos e novos atributos de manifesto que oferecem controle mais preciso sobre como os apps são exibidos em diferentes tamanhos, em vez de depender de categorias de tamanho generalizadas.

    Para garantir a melhor exibição possível para apps de tamanho fixo e apps com suporte limitado a vários tamanhos de tela, a plataforma também fornece um novo modo de compatibilidade de zoom que renderiza a interface em uma área de tela menor e a dimensiona para preencher o espaço disponível na tela. Para saber mais sobre a API de suporte de tela e os controles que ela oferece, consulte as seções abaixo.

Visão geral da API

APIs de suporte de telas

O Android 3.2 introduz novas telas com suporte a APIs que oferecem mais controle sobre como os aplicativos são mostrados em diferentes tamanhos de tela. A API se baseia na API de suporte a telas existente, incluindo o modelo de densidade de tela generalizado da plataforma, mas o amplia com a capacidade de segmentar com precisão intervalos de tela específicos pelas dimensões deles, medidas em unidades de pixel independentes de densidade (como 600 dp ou 720 dp de largura), em vez de pelos tamanhos de tela generalizados (como grande ou extra grande).

Ao projetar a interface de um aplicativo, você ainda pode confiar que a plataforma forneça abstração de densidade, o que significa que os aplicativos não precisam compensar as diferenças na densidade real de pixels entre os dispositivos. Você pode projetar a interface do aplicativo de acordo com a quantidade de espaço horizontal ou vertical disponível. A plataforma expressa a quantidade de espaço disponível usando três novas características: smallestWidth, width e height.

  • O smallestWidth de uma tela é o tamanho mínimo fundamental, medido em unidades de pixel independente de densidade (dp). Da altura ou largura da tela, é o menor dos dois. Para uma tela na orientação retrato, a smallestWidth normalmente é baseado na largura, enquanto na orientação paisagem ela se baseia na altura. Em todos os casos, a smallestWidth é derivada de uma característica fixa da tela, e o valor não muda, independentemente da orientação. A smallestWidth é importante para aplicativos, porque representa a menor largura possível em que a IU do aplicativo precisa ser desenhada, sem incluir as áreas de tela reservadas pelo sistema.
  • Por outro lado, a largura e a altura de uma tela representam o espaço horizontal ou vertical atual disponível para o layout do aplicativo, medido em unidades "dp", sem incluir as áreas de tela reservadas pelo sistema. A largura e altura de uma tela mudam quando o usuário alterna entre as orientações de paisagem e retrato.

A nova API de suporte a telas foi projetada para permitir que você gerencie a interface do aplicativo de acordo com a smallestWidth da tela atual. Também é possível gerenciar a interface de acordo com a largura ou altura atual, conforme necessário. Para essas finalidades, a API fornece as seguintes ferramentas:

  • Novos qualificadores de recurso para segmentar layouts e outros recursos para uma menor largura, largura ou altura mínimas
  • Novos atributos do manifesto para especificar o intervalo máximo de compatibilidade de tela do app.

Além disso, os aplicativos ainda podem consultar o sistema e gerenciar o carregamento da IU e de recursos no ambiente de execução, como nas versões anteriores da plataforma.

Como a nova API permite segmentar telas mais diretamente por smallestWidth, largura e altura, é útil entender as características típicas dos diferentes tipos de tela. A tabela abaixo fornece alguns exemplos, medidos em unidades "dp".

Tabela 1. Dispositivos típicos, com densidade e tamanho em dp.

Tipo Densidade (generalizada) Dimensões (dp) MenorLargura (dp)
Smartphone de referência mdpi 320x480 320
Tablet pequeno/smartphone grande mdpi 480x800 sobreposição ou
Tablet de 7 polegadas mdpi 600 x 1.024 600
tablet de 10'' mdpi 800 x 1.280 800

As seções abaixo oferecem mais informações sobre os novos qualificadores de tela e atributos de manifesto. Para ver informações completas sobre como usar a API de suporte de tela, consulte Suporte para várias telas.

Novos qualificadores de recursos para suporte a telas

Os novos qualificadores de recursos do Android 3.2 permitem que você direcione seus layouts para intervalos de tamanhos de tela melhor. Usando os qualificadores, é possível criar configurações de recursos projetadas para uma largura mínima específica, a largura atual ou a altura atual, medidas em pixels de densidade independente.

Os novos qualificadores são:

  • swNNNdp: especifica o valor mínimo de smallestWidth em que o recurso precisa ser usado, medido em unidades "dp". Como mencionado acima, a smallWidth de uma tela é constante, independentemente da orientação. Exemplos: sw320dp, sw720dp, sw720dp.
  • wNNNdp e hNNNdp: especificam a largura ou altura mínima em que o recurso precisa ser usado, medida em unidades "dp". Como mencionado acima, a largura e a altura de uma tela são relativas à orientação da tela e mudam sempre que a orientação muda. Exemplos: w320dp, w720dp, h1024dp.

Também é possível criar várias configurações de recursos sobrepostas, se necessário. Por exemplo, você pode marcar alguns recursos para uso em qualquer tela com mais de 480 dp, outros para mais de 600 dp e outros para mais de 720 dp. Quando várias configurações de recursos estão qualificadas para uma determinada tela, o sistema seleciona a configuração com a correspondência mais próxima. Para ter um controle preciso sobre quais recursos são carregados em uma determinada tela, marque recursos com um qualificador ou combine vários qualificadores novos ou existentes.

Com base nas dimensões típicas listadas anteriormente, veja alguns exemplos de como você pode usar os novos qualificadores:

res/layout/main_activity.xml   # For phones
res/layout-sw600dp/main_activity.xml   # For 7” tablets
res/layout-sw720dp/main_activity.xml   # For 10” tablets
res/layout-w600dp/main_activity.xml   # Multi-pane when enough width
res/layout-sw600dp-w720dp/main_activity.xml   # For large width

Versões mais antigas da plataforma vão ignorar os novos qualificadores. Você pode combiná-los conforme necessário para garantir que o app tenha uma ótima aparência em qualquer dispositivo. Veja alguns exemplos:

res/layout/main_activity.xml   # For phones
res/layout-xlarge/main_activity.xml   # For pre-3.2 tablets
res/layout-sw600dp/main_activity.xml   # For 3.2 and up tablets

Para ver informações completas sobre como usar os novos qualificadores, consulte Como usar novos qualificadores de tamanho.

Novos atributos do manifesto para compatibilidade de tamanho de tela

O framework oferece um novo conjunto de atributos de manifesto <supports-screens> que permitem gerenciar o suporte do app a diferentes tamanhos de tela. Especificamente, é possível especificar as telas maiores e menores em que o app foi projetado para ser executado, assim como a maior tela para que ele foi projetado, sem precisar do novo modo de compatibilidade da tela do sistema. Como os qualificadores de recurso descritos acima, os novos atributos de manifesto especificam o intervalo de telas a que o aplicativo oferece suporte, conforme especificado pelo valor de smallestWidth.

Os novos atributos de manifesto para suporte a telas são:

  • android:compatibleWidthLimitDp="numDp": esse atributo permite especificar a smallestWidth máxima em que o aplicativo pode ser executado sem o modo de compatibilidade. Se a tela atual for maior que o valor especificado, o sistema vai mostrar o aplicativo no modo normal, mas permitirá que o usuário alterne para o modo de compatibilidade com uma configuração na barra do sistema.
  • android:largestWidthLimitDp="numDp": esse atributo permite especificar a smallestWidth máxima em que o aplicativo foi projetado para ser executado. Se a tela atual for maior que o valor especificado, o sistema vai forçar o aplicativo a entrar no modo de compatibilidade da tela, a fim de garantir a melhor exibição na tela atual.
  • android:requiresSmallestWidthDp="numDp": esse atributo permite especificar a smallestWidth mínima em que o aplicativo pode ser executado. Se a tela atual for menor que o valor especificado, o sistema considerará o aplicativo incompatível com o dispositivo, mas não impedirá que ele seja instalado e executado.

Observação:atualmente, o Google Play não filtra apps com base em nenhum dos atributos acima. O suporte para filtragem será adicionado em uma próxima versão da plataforma. Os aplicativos que exigem filtragem com base no tamanho da tela podem usar os atributos <supports-screens> atuais.

Para ver informações completas sobre como usar os novos atributos, consulte Como declarar suporte ao tamanho da tela.

Modo de compatibilidade da tela

O Android 3.2 oferece um novo modo de compatibilidade de tela para aplicativos que declaram explicitamente que não oferecem suporte a telas tão grandes quanto a que estão sendo executadas. Esse novo modo de "zoom" é dimensionado em pixels. Ele renderiza o aplicativo em uma área de tela menor e, em seguida, dimensiona os pixels para preencher a tela atual.

Por padrão, o sistema oferece o modo de compatibilidade da tela como uma opção do usuário para apps que exigem isso. Os usuários podem ativar ou desativar o modo de zoom usando um controle disponível na barra do sistema.

Como o novo modo de compatibilidade da tela pode não ser adequado para todos os aplicativos, a plataforma permite que o aplicativo o desative usando atributos de manifesto. Quando desativado pelo app, o sistema não oferece o modo de compatibilidade "zoom" como uma opção para os usuários quando o app está em execução.

Observação:para ver informações importantes sobre como controlar o modo de compatibilidade nos seus apps, consulte o artigo Novo modo para apps em telas grandes (em inglês) no Blog de desenvolvedores Android.

Nova densidade de tela para televisões de 720p e dispositivos semelhantes

Para atender às necessidades de aplicativos executados em televisões de 720p ou semelhantes com telas de densidade moderada, o Android 3.2 introduz uma nova densidade generalizada, tvdpi, com dpi aproximado de 213. Os aplicativos podem consultar a nova densidade em densityDpi e usar o novo qualificador tvdpi para marcar recursos para televisões e dispositivos semelhantes. Por exemplo:

res/drawable-tvdpi/my_icon.png   # Bitmap for tv density

Em geral, os aplicativos não precisam trabalhar com essa densidade. Para situações em que a saída é necessária para uma tela de 720p, os elementos da interface podem ser dimensionados automaticamente pela plataforma.

Framework da interface

  • Fragmentos
    • A nova classe Fragment.SavedState contém as informações de estado recuperadas de uma instância de fragmento por meio de saveFragmentInstanceState().
    • O novo método saveFragmentInstanceState() salva o estado atual da instância do fragmento especificado. O estado pode ser usado mais tarde ao criar uma nova instância do fragmento que corresponda ao estado atual.
    • O novo método setInitialSavedState() define o estado inicial salvo para um fragmento quando criado pela primeira vez.
    • O novo método de callback onViewCreated() notifica o fragmento de que onCreateView() foi retornado, mas antes que qualquer estado salvo seja restaurado na visualização.
    • O método isDetached() determina se o fragmento foi explicitamente removido da interface.
    • Os novos métodos attach() e detach() permitem que um aplicativo anexe ou desanexe fragmentos na interface novamente.
    • Um novo método de sobrecarga setCustomAnimations() permite que você defina recursos de animação específicos para serem executados para operações de entrada/saída e especificamente ao exibir a backstack. A implementação existente não considera os diferentes comportamentos de fragmentos ao exibir a backstack.
  • Informações sobre o tamanho da tela em ActivityInfo e ApplicationInfo
  • Ajuda para descobrir o tamanho de exibição da WindowManager
  • Novos estilos "holográficos" públicos
    • A plataforma agora expõe diversos estilos "holográficos" públicos para texto, widgets e guias da barra de ações e muito mais. Consulte R.style para ver uma lista completa.
  • O uso de LocalActivityManager, ActivityGroup e LocalActivityManager foi descontinuado.
    • Novos aplicativos precisam usar fragmentos em vez dessas classes. Para continuar executando em versões mais antigas da plataforma, você pode usar a Biblioteca de Suporte v4 (biblioteca de compatibilidade), disponível no SDK do Android. A Biblioteca de Suporte v4 oferece uma versão da API Fragment compatível até o Android 1.6 (API de nível 4).
    • Para apps desenvolvidos no Android 3.0 (API de nível 11) ou versões mais recentes, as guias geralmente são apresentadas na interface usando o novo ActionBar.newTab() e APIs relacionadas para posicionar guias na área da barra de ações.

Framework de mídia

  • Os aplicativos que usam o provedor de mídia da plataforma (MediaStore) agora podem ler dados de mídia diretamente do cartão SD removível, quando compatível com o dispositivo. Os aplicativos também podem interagir diretamente com os arquivos do cartão SD, usando a API MTP.

Gráficos

Framework do IME

  • Novo método getModifiers() para recuperar o estado atual das teclas modificadoras.

framework USB

  • Novo método getRawDescriptors() para recuperar os descritores USB brutos do dispositivo. É possível usar o método para acessar descritores sem suporte diretamente por meio das APIs de nível superior.

Rede

Telefonia

Principais utilitários

Novas constantes de recursos

A plataforma adiciona novas constantes de recursos de hardware que podem ser declaradas nos manifestos do aplicativo para informar a entidades externas, como o Google Play, sobre os recursos de hardware e software necessários. Você declara essas e outras constantes de recurso nos elementos do manifesto <uses-feature>.

O Google Play filtra os aplicativos com base nos atributos <uses-feature> para garantir que eles estejam disponíveis somente aos dispositivos em que os requisitos são atendidos.

  • Constantes de recursos para requisitos de paisagem ou retrato

    O Android 3.2 introduz novas constantes de recursos que permitem que os aplicativos especifiquem se exigem exibição na orientação paisagem, retrato ou ambos. Declarar essas constantes indica que o aplicativo não pode ser instalado em um dispositivo que não ofereça a orientação associada. Por outro lado, se uma ou ambas as constantes não forem declaradas, isso indica que o aplicativo não tem preferência pelas orientações não declaradas e pode ser instalado em um dispositivo que não as ofereça.

    Um aplicativo típico que funciona corretamente nas orientações de paisagem e retrato normalmente não precisa declarar um requisito de orientação. Em vez disso, um aplicativo projetado principalmente para uma orientação, como um app projetado para uma televisão, pode declarar uma das constantes para garantir que ela não esteja disponível para dispositivos que não a forneçam.

    Se qualquer uma das atividades declaradas na solicitação do manifesto for executada em uma orientação específica, usando o atributo android:screenOrientation, isso também declarará que o aplicativo exige essa orientação.

  • Outras constantes de recursos

Relatório de diferenças da API

Para ter uma visão detalhada de todas as mudanças da API no Android 3.2 (API de nível 13), consulte o Relatório de diferenças da API.

Nível de API

A plataforma Android 3.2 oferece uma versão atualizada da API do framework. A API do Android 3.2 recebe um identificador de números inteiros (13) que é armazenado no próprio sistema. Esse identificador, chamado de "nível de API", permite que o sistema determine corretamente se um aplicativo é compatível com ele antes de instalá-lo.

Para usar as APIs introduzidas no Android 3.2, é necessário compilar o aplicativo na biblioteca Android fornecida na plataforma SDK do Android 3.2. Dependendo das suas necessidades, talvez também seja necessário adicionar um atributo android:minSdkVersion="13" ao elemento <uses-sdk> no manifesto do aplicativo.

Para mais informações, leia O que é o nível da API?.