Nível da API: 13
O Android 3.2 (HONEYCOMB_MR2
) é uma versão de plataforma incremental que adiciona novas
recursos para usuários e desenvolvedores. As seções abaixo fornecem uma visão geral
dos novos recursos e das APIs para desenvolvedores.
Para desenvolvedores, a plataforma Android 3.2 está disponível como um do SDK do Android para download. A plataforma para download inclui uma biblioteca Android e uma imagem do sistema, bem como um conjunto de aparências e mais. Para começar a desenvolver ou testar no Android 3.2, use o Android SDK Manager para fazer o download da plataforma no 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 aplicativos de tamanho fixo em dispositivos maiores. O novo modo oferece alternativa com escala de pixels ao alongamento padrão da interface do usuário para aplicativos que não são projetados para funcionar em tamanhos de tela maiores, como em tablets. O novo modo é acessível aos usuários a partir de um ícone de menu na barra do sistema, para apps que precisam suporte à compatibilidade.
- Sincronização de mídia do cartão SD
Em dispositivos compatíveis com cartão SD, os usuários agora podem carregar arquivos de mídia diretamente do cartão SD para os apps que os usam. Um recurso do sistema disponibiliza acessível aos apps do 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 à API de suporte de tela da plataforma para oferecem aos desenvolvedores outras formas de gerenciar a interface de usuário do aplicativo Aparelhos com tecnologia Android. A API inclui novos qualificadores de recursos e novos atributos de manifesto que dão a você um controle mais preciso sobre como seus são exibidos em diferentes tamanhos, em vez de depender de categorias de tamanho.
Garantir a melhor exibição possível para apps de tamanho fixo e com limitações suporte a vários tamanhos de tela, a plataforma também fornece um novo zoom modo de compatibilidade que renderiza a IU em uma área de tela menor e a dimensiona para preencher o espaço disponível na tela. Para mais informações sobre o a API de suporte de tela e os controles que ela oferece, consulte as seções abaixo.
Visão geral da API
APIs Screens Support
O Android 3.2 introduz novas telas compatíveis com APIs que oferecem mais controle sobre como seus aplicativos são exibidos em diferentes tamanhos de tela. A API se baseia na API de suporte a telas existentes, incluindo o de densidade de tela generalizado, mas o estende com a capacidade de segmentar intervalos de telas específicos pelas dimensões, medidas em unidades de pixel de densidade independente (como 600 dp ou 720 dp de largura), em vez por tamanhos de tela generalizados (como grande ou extra grande)
Ao projetar a IU de um aplicativo, você ainda pode confiar na plataforma para fornecem abstração de densidade, o que significa que os aplicativos não precisam para compensar as diferenças na densidade de pixels real entre os dispositivos. Você pode projetar a interface do aplicativo de acordo com a quantidade de disponível. A plataforma expressa a quantidade de espaço disponível usando três novos 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"). Da altura da tela largura, é o menor dos dois. Para uma tela na orientação retrato, o A menor largura geralmente é baseada em sua largura, enquanto na orientação paisagem ela se baseia em sua altura. Em todos os casos, o valor menores é derivado de uma característica fixa do tela, e o valor não muda, independentemente da orientação. O valor menor de é importante para aplicativos porque representa a menor largura possível em que a interface do aplicativo precisará ser desenhada, sem incluir áreas de tela reservadas pelo sistema.
- Por outro lado, a largura e a altura da tela representam espaço horizontal ou vertical atual disponível para layout do aplicativo, medido em "dp" sem incluir as áreas de tela reservadas pelo sistema. A largura e altura de uma mudança de tela 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 menor largura da tela atual. Você também pode gerenciar IU de acordo com a largura ou altura atual, conforme necessário. Para isso, a API oferece estas ferramentas:
- Novos qualificadores de recursos para segmentar layouts e outros recursos para um menor largura, largura ou altura mínima e
- Novos atributos de manifesto, para especificar a quantidade máxima intervalo de compatibilidade da tela
Além disso, os aplicativos ainda podem consultar o sistema e gerenciar a interface e o carregamento 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 pela opção de reduzir a largura, largura e altura, é útil entender as diferenças características dos diferentes tipos de tela. A tabela abaixo fornece algumas exemplos, medidos em "dp" unidades.
Tabela 1. Dispositivos típicos, com densidade e o tamanho em dp.
Tipo | Densidade (generalizada) | Dimensões (dp) | Menor largura (dp) |
---|---|---|---|
Telefone 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 de manifesto. Para informações completas sobre como usar a tela consulte Como oferecer suporte a vários Telas.
Novos qualificadores de recursos para suporte a telas
Os novos qualificadores de recursos do Android 3.2 permitem que você direcione melhor seus layouts para intervalos de tamanhos de tela. Usando os qualificadores, é possível criar recursos configurações projetadas para um valor menor de largura, largura atual ou altura atual, medida em pixels de densidade independente.
Os novos qualificadores são:
swNNNdp
: especifica o valor mínimo para a menor largura em que o o recurso deve ser usado, medido em "dp", unidades. Como mencionado acima, a menor largura da tela seja constante, independentemente da orientação. Exemplos:sw320dp
,sw720dp
esw720dp
.wNNNdp
ehNNNdp
: especificam o mínimo largura ou altura em que o recurso precisa ser usado, medida em "dp" unidades. Conforme mencionado acima, a largura e a altura de uma tela são relativas à orientação do da tela e mudam sempre que a orientação muda. Exemplos:w320dp
,w720dp
eh1024dp
.
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 largura maior que 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 quais recursos são carregados em uma determinada tela, marque os recursos com uma qualificador ou combinar vários qualificadores novos ou existentes.
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 ignorarão os novos qualificadores, para que você possa misture conforme necessário para garantir que seu aplicativo tenha uma ótima aparência em qualquer dispositivo. Aqui são 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 qualificadores de tamanho.
Novos atributos de manifesto para compatibilidade com o tamanho de tela
O framework oferece um novo conjunto de atributos de manifesto <supports-screens>
que permitem
você gerencia a compatibilidade do seu app com diferentes tamanhos de tela.
Especificamente, é possível especificar as maiores e menores telas em que o app
foi projetado para ser executado, assim como para a maior tela na qual ele foi projetado
sem precisar da nova tela do sistema
modo de compatibilidade. Como os qualificadores de recurso descritos acima, o novo
de manifesto especificam o intervalo de telas que o aplicativo suporta,
conforme especificado pela smallWidth.
Os novos atributos de manifesto para suporte a telas são:
android:compatibleWidthLimitDp="numDp"
— Este permite que você especifique o valor de MinWidth máximo em que o aplicativo podem ser executadas sem a necessidade do modo de compatibilidade. Se a tela atual for maior do que o valor especificado, o sistema exibirá o aplicativo no modo normal, mas permite que o usuário alterne para o modo de compatibilidade usando uma configuração no barra de sistema.android:largestWidthLimitDp="numDp"
— Este permite que você especifique o valor de MinWidth máximo em que o aplicativo é projetado para funcionar. Se a tela atual for maior que o valor especificado, o sistema força o aplicativo a entrar no modo de compatibilidade da tela para garantir a melhor serão mostrados na tela atual.android:requiresSmallestWidthDp="numDp"
— Este permite que você especifique o valor necessário para menores, podem ser executados. Se a tela atual for menor que o valor especificado, o sistema considera o aplicativo incompatível com o dispositivo, mas não o impede de serem instalados e executados.
Observação:no momento, o Google Play não filtra
apps com base em qualquer um dos atributos acima. O suporte à filtragem será
adicionado em uma versão posterior da plataforma. Aplicativos que exigem
o filtro com base no tamanho da tela pode usar o <supports-screens>
existente
atributos.
Para obter informações completas sobre como usar os novos atributos, consulte Declaração suporte ao tamanho de tela.
Modo de compatibilidade da tela
O Android 3.2 fornece um novo modo de compatibilidade de tela para aplicativos declarando explicitamente que não oferecem suporte a telas tão grandes quanto a da na qual eles estão executando. A nova opção de "zoom" é dimensionado em pixels, 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 de tela como uma opção do usuário para aplicativos que precisam dele. 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 de tela pode não ser apropriado para todos aplicativos, a plataforma permite que o aplicativo o desative usando manifesto atributos. Quando desativado pelo app, o sistema não oferece "zoom" compatibilidade como uma opção para os usuários quando o app está em execução.
Observação: para informações importantes sobre como para controlar o modo de compatibilidade em seus aplicativos, consulte o artigo Novo modo para aplicativos em telas grandes sobre o Android Blog de desenvolvedores.
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 dpi aproximado de 213. Os aplicativos podem fazer consultas
a nova densidade em densityDpi
e podemos usar
o novo qualificador tvdpi
para marcar recursos para televisões e
e dispositivos semelhantes. 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 seja 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 o estado informações recuperadas de uma instância de fragmento por meio desaveFragmentInstanceState()
. - Novo método
saveFragmentInstanceState()
salva o estado atual da instância do do fragmento especificado. O estado pode ser usado posteriormente durante a criação de uma nova instância do fragmento que corresponde ao estado atual. - Novo método
setInitialSavedState()
define o estado inicial salvo de um fragmento quando construído pela primeira vez. - O novo método de callback
onViewCreated()
notifica o fragmento queonCreateView()
for retornado, mas antes que qualquer estado salvo seja restaurado na visualização. - O método
isDetached()
determina se o fragmento foi explicitamente removido da IU. - Novo
attach()
edetach()
permitem que um aplicativo reanexe ou remova fragmentos na IU. - Um novo método de sobrecarga
setCustomAnimations()
permite definir animações específicas a serem executados em operações de entrada/saída e, especificamente, executar a backstack. A implementação atual não considera para o diferente comportamento dos fragmentos ao mostrar a backstack.
- A nova classe
- Informações de tamanho da tela em ActivityInfo e ApplicationInfo
ActivityInfo
adicionaCONFIG_SCREEN_SIZE
eCONFIG_SMALLEST_SCREEN_SIZE
como bitmask emconfigChanges
. Os bits indicam se uma atividade pode lida com o tamanho da tela e o menor tamanho de tela.ApplicationInfo
adiçõeslargestWidthLimitDp
,compatibleWidthLimitDp
erequiresSmallestWidthDp
, derivados dos atributos<supports-screens>
correspondentes no arquivo de manifesto do aplicativo.
- Auxiliares para obter o tamanho de exibição da WindowManager
- Os novos métodos
getSize()
egetRectSize()
permitem que os aplicativos acessem o tamanho bruto da tela.
- Os novos métodos
- Novo "holográfico" público estilos
- Agora, a plataforma expõe uma variedade de imagens públicas estilos
para texto, widgets, guias da barra de ações e muito mais. Consulte
R.style
para acessar a lista completa.
- Agora, a plataforma expõe uma variedade de imagens públicas estilos
para texto, widgets, guias da barra de ações e muito mais. Consulte
LocalActivityManager
,ActivityGroup
e O uso deLocalActivityManager
foi descontinuado- Novos aplicativos precisam usar fragmentos em vez dessas classes. Para continuar sendo executado em versões mais antigas da plataforma, poderá usar a versão Biblioteca (biblioteca de compatibilidade), disponível no SDK do Android. O suporte da v4 A biblioteca oferece uma versão da API Fragment que é compatível com Android 1.6 (API de nível 4)
- Para aplicativos desenvolvidos para o Android 3.0 (nível da API)
11) ou superiores, as guias normalmente são apresentadas na interface do usuário usando o novo
ActionBar.newTab()
e APIs relacionadas para colocar 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 suportado pelo dispositivo. Os aplicativos também podem interagem diretamente com os arquivos do cartão SD usando a API MTP.
Gráficos
- Utilitários parcelable em Point e PointF
Point
ePointF
As classes agora incluem a interfaceParcelable
e os métodos utilitáriosdescribeContents()
,readFromParcel()
ewriteToParcel()
.
Estrutura do IME
- Novo método
getModifiers()
para recuperação do estado atual das teclas modificadoras.
Framework USB
- Novo método
getRawDescriptors()
para recuperar os descritores USB brutos para o dispositivo. Você pode usar o para acessar descritores sem suporte diretamente por meio da APIs de nível de serviço.
Rede
- Constantes de tipo de rede
ConnectivityManager
adiciona as constantesTYPE_ETHERNET
eTYPE_BLUETOOTH
.
Telefonia
- Nova constante do tipo de rede
NETWORK_TYPE_HSPAP
.
Principais utilitários
- Utilitários de parcelable
- A nova interface
Parcelable.ClassLoaderCreator
permite o aplicativo para receber o ClassLoader em que o objeto está sendo criado. - Novos
adoptFd
,dup()
efromFd()
para gerenciamentoParcelFileDescriptor
.
- A nova interface
- Vinculador e IBinder
- Novo método
dumpAsync()
emBinder
eIBinder
permitem que os aplicativos para um arquivo especificado, garantindo que o destino seja executado de forma assíncrona. - O novo código de transação do protocolo
TWEET_TRANSACTION
(IBinder
) permite que os aplicativos enviem um tweet ao objeto de destino.
- Novo método
Novas constantes de recurso
A plataforma adiciona novas constantes de recurso de hardware que podem ser declaradas
nos manifestos dos aplicativos, para informar entidades externas, como o Google
Conjunto de recursos de hardware e software necessários. Você declara 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 somente nos dispositivos em que os requisitos sejam 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 precisam de 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 oferece 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 oferece.
android.hardware.screen.landscape
: o aplicativo exige exibição em orientação paisagem.android.hardware.screen.portrait
: o aplicativo exige exibição em 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, um aplicativo projetado principalmente para uma orientação, como um aplicativo projetado para uma televisão, pode declarar uma das constantes para garantir que ela não esteja disponível para dispositivos que não fornecem essa orientação.
Se alguma das atividades declaradas no manifesto solicitar a execução em uma orientação específica: usando o atributo
android:screenOrientation
, isso também declara que o aplicativo precisa dessa orientação. - Outras constantes de atributo
android.hardware.faketouch.multitouch.distinct
: o aplicativo exige suporte à entrada multitoque emulada com rastreamento distinto de dois ou mais pontos.android.hardware.faketouch.multitouch.jazzhand
: o aplicativo exige suporte à entrada multitoque emulada com rastreamento distinto de cinco ou mais pontos.
Relatório de diferenças da API
Para obter uma visão detalhada de todas as mudanças de API no Android 3.2 (API Nível 13), consulte a API Relatório de diferenças.
Nível da API
A plataforma Android 3.2 oferece uma versão atualizada do a API do framework. A API do Android 3.2 recebe um identificador inteiro, 13: ou seja, armazenadas no próprio sistema. Com esse identificador, chamado de "nível de API", é possível para determinar corretamente se um aplicativo é compatível com no sistema antes de instalar o aplicativo.
Para usar as APIs introduzidas no Android 3.2 em seu aplicativo,
você precisa compilar o aplicativo na biblioteca Android fornecida no
a plataforma do SDK do Android 3.2. Dependendo das suas necessidades,
pode
também é necessário adicionar um android:minSdkVersion="13"
ao elemento <uses-sdk>
na classe
manifesto do aplicativo.
Para mais informações, leia O que é a API Nível?