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 disponível para download inclui uma biblioteca Android e uma imagem do sistema, além de um conjunto de skins de emulador e muito mais. Para começar a desenvolver ou testar no Android 3.2, use o SDK Manager do Android 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 gama mais ampla 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 ver apps de tamanho fixo em dispositivos maiores. O novo modo oferece uma alternativa dimensionada em pixels ao alongamento da interface padrão para apps que não são criados para execução em telas maiores, como em tablets. O novo modo pode ser acessado pelos usuários em um ícone de menu na barra do sistema para apps que precisam de suporte de compatibilidade.
- Sincronização de mídia do cartão SD
Em dispositivos com suporte a cartão SD, os usuários agora podem carregar arquivos de mídia diretamente do cartão em apps que os utilizam. Uma instalação do sistema torna os arquivos acessíveis a apps pelo 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 telas da plataforma para oferecer aos desenvolvedores outras maneiras de gerenciar a interface do aplicativo em todos os dispositivos com tecnologia Android. A API inclui novos qualificadores de recursos e novos atributos de manifesto que oferecem um controle mais preciso sobre como os apps são exibidos em tamanhos diferentes, 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 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 é baseada na API de suporte a telas existente, incluindo o modelo de densidade de tela generalizada da plataforma, mas a amplia com a capacidade de segmentar com precisão intervalos de tela específicos pelas dimensões, medidas em unidades de pixel independentes de densidade (como 600 dp ou 720 dp de largura), em vez de por tamanhos de tela generalizados (como grande ou extragrande).
Ao projetar a interface de um aplicativo, você ainda pode confiar na plataforma para fornecer 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. É possível 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.
- A smallestWidth de uma tela é o tamanho mínimo fundamental, medido em unidades de pixel independente de densidade ("dp"). É a menor das duas da altura ou largura da tela. Para uma tela na orientação retrato, a smallestWidth normalmente é baseada na largura dela, enquanto na orientação paisagem ela é baseada na altura. Em todos os casos, a lowerWidth é derivada de uma característica fixa da tela, e o valor não muda, independente da orientação. Ela é importante para aplicativos porque representa a menor largura possível em que a interface do aplicativo vai precisar ser desenhada, sem incluir as áreas de tela reservadas pelo sistema.
- Por outro lado, a width e a height da tela representam o espaço horizontal ou vertical atual disponível para o layout do app, medido em unidades "dp", sem incluir as áreas da tela reservadas pelo sistema. A largura e altura de uma tela mudam quando o usuário alterna a orientação entre 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 largura menor da tela atual. Também é possível gerenciar a interface de acordo com a largura ou altura atual, conforme necessário. Para esses fins, a API fornece as seguintes ferramentas:
- Novos qualificadores de recurso para segmentar layouts e outros recursos para menorLargura, 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 interface e de recursos no ambiente de execução, como nas versões anteriores da plataforma.
Como a nova API permite segmentar telas de forma mais direta com valor de largura, 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".
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 fornecem mais informações sobre os novos qualificadores de tela e atributos do manifesto. Para ver informações completas sobre como usar a API de suporte a telas, consulte Suporte a várias telas.
Novos qualificadores de recursos para suporte a telas
Os novos qualificadores de recursos do Android 3.2 permitem segmentar melhor seus layouts para intervalos de tamanhos de tela. Com os qualificadores, é possível criar configurações de recursos projetadas para uma largura mínima mínima, largura atual ou altura atual, medidas em pixels de densidade independente.
Os novos qualificadores são:
swNNNdp
: especifica a menorWidth mínima em que o recurso precisa ser usado, em unidades "dp". Como mencionado acima, a menorWidth da tela é constante, independente da orientação. Exemplos:sw320dp
,sw720dp
,sw720dp
.wNNNdp
ehNNNdp
: especificam a largura ou altura mínima em que o recurso precisa ser usado, 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, é possível 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 são qualificadas para uma determinada tela, o sistema seleciona a configuração mais próxima. Para ter um controle preciso sobre quais recursos são carregados em uma determinada tela, marque os recursos com um qualificador ou combine vários deles.
Com base nas dimensões típicas listadas anteriormente, aqui estão 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, então 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 informações completas sobre como usar os novos qualificadores, consulte Usar novos qualificadores de tamanho.
Novos atributos de 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 maior e menor em que o app
foi projetado para ser executado, bem como a maior tela em que ele foi projetado,
sem precisar do novo modo de compatibilidade
da tela do sistema. Assim 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 por valor de lowerWidth.
Os novos atributos de manifesto para suporte a telas são:
android:compatibleWidthLimitDp="numDp"
: esse atributo permite especificar a menorWidth máxima em que o aplicativo pode ser executado sem precisar do 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 menorWidth máxima em que o aplicativo foi projetado para ser executado. Se a tela atual for maior que o valor especificado, o sistema forçará o aplicativo a entrar no modo de compatibilidade da tela para garantir a melhor exibição na tela atual.android:requiresSmallestWidthDp="numDp"
: esse atributo permite especificar a menorWidth 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 qualquer um 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>
existentes.
Para ter 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 fornece um novo modo de compatibilidade de tela para aplicativos que declaram explicitamente que não oferecem suporte a telas tão grandes quanto a em que estão sendo executados. Esse novo modo "zoom" é dimensionado em pixels. Ele renderiza o aplicativo em uma área 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 e 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 apps, a plataforma permite que ele seja desativado usando atributos do 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 informações importantes sobre como controlar o modo de compatibilidade nos seus apps, consulte o artigo Novo modo para apps em telas grandes (link 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 similares com
telas de densidade moderada, o Android 3.2 introduz uma nova densidade generalizada,
tvdpi
, com um 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 escalonados 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 desaveFragmentInstanceState()
. - 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 de um fragmento quando criado pela primeira vez. - O novo método de callback
onViewCreated()
notifica o fragmento de queonCreateView()
retornou, mas antes de qualquer estado salvo ser restaurado na visualização. - O método
isDetached()
determina se o fragmento foi explicitamente removido da interface. - Os novos métodos
attach()
edetach()
permitem que um aplicativo anexe ou desanexe fragmentos na IU. - 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 o comportamento diferente dos fragmentos ao exibir a backstack.
- A nova classe
- Informações sobre o tamanho da tela em ActivityInfo e ApplicationInfo
ActivityInfo
adicionaCONFIG_SCREEN_SIZE
eCONFIG_SMALLEST_SCREEN_SIZE
como bitmasks emconfigChanges
. Os bits indicam se uma atividade pode lidar com o menor tamanho e tamanho da tela.ApplicationInfo
adiciona os camposlargestWidthLimitDp
,compatibleWidthLimitDp
erequiresSmallestWidthDp
, derivados dos atributos<supports-screens>
correspondentes no arquivo de manifesto do aplicativo.
- Ajuda para descobrir o tamanho de exibição da WindowManager
- Os novos métodos
getSize()
egetRectSize()
permitem que os aplicativos saibam o tamanho bruto da tela.
- Os novos métodos
- Novos estilos "holográficos" públicos
- A plataforma agora expõe uma variedade de 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.
- A plataforma agora expõe uma variedade de estilos "holográficos" públicos
para texto, widgets e guias da barra de ações e muito mais. Consulte
- O uso de
LocalActivityManager
,ActivityGroup
eLocalActivityManager
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 que desenvolvem no Android 3.0 (API de nível
11) ou versões mais recentes, as guias geralmente são apresentadas na IU usando o novo
ActionBar.newTab()
e APIs relacionadas para posicionar guias na área da barra de ações.
Estrutura 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
- Utilitários de parcelable no Point e PointF
- As classes
Point
ePointF
agora incluem a interfaceParcelable
e os métodos utilitáriosdescribeContents()
,readFromParcel()
ewriteToParcel()
.
- As classes
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. Você pode usar o método para acessar descritores sem suporte direto por meio de APIs de nível superior.
Rede
- Constantes de tipo de rede
ConnectivityManager
adiciona as constantesTYPE_ETHERNET
eTYPE_BLUETOOTH
.
Telefonia
- Nova constante de tipo de rede
NETWORK_TYPE_HSPAP
.
Principais utilitários
- Utilitários parcelable
- A nova interface
Parcelable.ClassLoaderCreator
permite que o aplicativo receba o ClassLoader em que o objeto está sendo criado. - Novos
adoptFd
,dup()
efromFd()
para gerenciar objetosParcelFileDescriptor
.
- A nova interface
- Vinculação e IBinder
- O novo método
dumpAsync()
emBinder
eIBinder
permite que os aplicativos façam o despejo para um arquivo especificado, garantindo que o destino seja executado de forma assíncrona. - O novo código de transação do protocolo
IBinder
TWEET_TRANSACTION
permite que os aplicativos enviem um tweet para o objeto de destino.
- O novo método
Novas constantes de recurso
A plataforma adiciona novas constantes de recursos de hardware que podem ser declaradas
nos manifestos do aplicativo para informar entidades externas, como o Google
Play, sobre os recursos necessários de hardware e software. Declare essas
e outras constantes de recurso nos elementos de manifesto <uses-feature>
.
O Google Play filtra os aplicativos com base nos atributos <uses-feature>
para garantir que estejam disponíveis apenas para 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 ambas. Declarar essas constantes indica que o aplicativo não deve 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 são declaradas, isso indica que o aplicativo não tem preferência para as orientações não declaradas e pode ser instalado em um dispositivo que não as ofereça.
android.hardware.screen.landscape
: o aplicativo exige a exibição na orientação paisagem.android.hardware.screen.portrait
: o aplicativo exige a exibição na orientação retrato.
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, aplicativos projetados principalmente para uma orientação, como um aplicativo projetado para uma televisão, podem declarar uma das constantes para garantir que não esteja disponível para dispositivos que não fornecem essa orientação.
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 vai declarar que o aplicativo exige essa orientação. - Outras constantes de recurso
android.hardware.faketouch.multitouch.distinct
: o app exige suporte à entrada multitoque emulada com rastreamento distinto de dois ou mais pontos.android.hardware.faketouch.multitouch.jazzhand
: o aplicativo exige suporte para entrada multitoque emulada com rastreamento distinto de cinco ou mais pontos.
Relatório de diferenças da API
Para ter uma visão detalhada de todas as mudanças da API no Android 3.2 (nível 13 da API), 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 de framework. A API do Android 3.2 recebe um identificador inteiro ( 13), que é armazenado no próprio sistema. Esse identificador, chamado de "nível da API", permite que o sistema determine corretamente se um aplicativo é compatível com ele antes da instalação.
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?