Android 4.1 APIs

Nível da API: 16

O Android 4.1 (JELLY_BEAN) é uma evolução da plataforma que oferece melhor desempenho e experiência do usuário. Ele adiciona novos recursos para usuários e desenvolvedores de apps. Este documento fornece uma introdução às novas APIs mais importantes e úteis para desenvolvedores de apps.

Como desenvolvedor de apps, você pode acessar o Android 4.1 no SDK Manager como uma imagem do sistema que pode ser executada no Android Emulator e uma plataforma do SDK em que você pode criar seu app. Faça o download da imagem do sistema e da plataforma assim que possível para criar e testar seu app no Android 4.1.

Para otimizar seu app para dispositivos com o Android 4.1, defina seu targetSdkVersion como "16", instale-o em uma imagem do sistema do Android 4.1, teste e publique uma atualização com essa mudança.

Você pode usar APIs no Android 4.1 e ainda oferecer suporte a versões mais antigas adicionando condições ao código que verifiquem o nível da API do sistema antes de executar APIs sem suporte do minSdkVersion. Para saber mais sobre como manter a compatibilidade com versões anteriores, leia Como criar interfaces compatíveis com versões anteriores.

Confira mais informações sobre como os níveis de API funcionam em O que é o nível da API?.

Componentes do app

Serviços isolados

Ao especificar android:isolatedProcess="true" na tag <service>, o Service será executado no próprio processo de ID do usuário isolado, que não tem permissões próprias.

Gerenciamento de memória

Novas constantes ComponentCallbacks2, como TRIM_MEMORY_RUNNING_LOW e TRIM_MEMORY_RUNNING_CRITICAL, fornecem aos processos em primeiro plano mais informações sobre o estado da memória antes que o sistema chame onLowMemory().

O novo método getMyMemoryState(ActivityManager.RunningAppProcessInfo) permite extrair o estado geral da memória.

Provedores de conteúdo

Um novo método, acquireUnstableContentProviderClient(), permite acessar um ContentProviderClient que pode ser "instável", de modo que o app não falhará se o provedor de conteúdo falhar. Ele é útil quando você interage com provedores de conteúdo em um app separado.

Planos fundo interativos

Novo protocolo de intent para iniciar diretamente a atividade de visualização do plano de fundo interativo, ajudando os usuários a selecionar o plano de fundo interativo sem precisar sair do app e navegar pelo seletor de plano de fundo da tela inicial.

Para iniciar o seletor de plano de fundo interativo, chame startActivity() com um Intent usando ACTION_CHANGE_LIVE_WALLPAPER e um extra que especifique o ComponentName do plano de fundo interativo como uma string em EXTRA_LIVE_WALLPAPER_COMPONENT.

Navegação na pilha de apps

O Android 4.1 facilita muito a implementação dos padrões de design adequados para a navegação acima. Basta adicionar o android:parentActivityName a cada elemento <activity> no arquivo de manifesto. O sistema usa essas informações para abrir a atividade apropriada quando o usuário pressiona o botão "para cima" na barra de ações, além de encerrar a atividade atual. Portanto, se você declarar android:parentActivityName para cada atividade, não vai precisar do método onOptionsItemSelected() para processar eventos de clique no ícone do app da barra de ações. O sistema agora vai processar esse evento e retomar ou criar a atividade adequada.

Isso é particularmente útil para cenários em que o usuário insere uma das atividades do app usando uma intent de "mergulho profundo", como uma notificação ou uma intent de outro app, conforme descrito no guia de design Navegar entre apps. Quando o usuário insere sua atividade dessa maneira, é possível que o app não tenha naturalmente uma backstack de atividades que possam ser retomadas à medida que o usuário navega para cima. No entanto, quando você fornece o atributo android:parentActivityName para suas atividades, o sistema reconhece se o app já contém ou não uma backstack de atividades mãe e, se não, cria uma backstack sintética que contém todas as atividades mãe.

Observação:quando o usuário entra em uma atividade profunda no app e cria uma nova tarefa para ele, o sistema insere a pilha de atividades mãe na tarefa. Dessa forma, pressionar o botão "Voltar" também navega de volta pela pilha de atividades mãe.

Quando o sistema cria uma backstack sintética para o app, ele cria uma Intent básica para criar uma nova instância de cada atividade pai. Portanto, não há estado salvo para as atividades pai, como você esperaria se o usuário navegasse naturalmente por cada atividade. Se qualquer uma das atividades mães normalmente mostrar uma interface que depende do contexto do usuário, essas informações de contexto vão estar ausentes, e você precisará enviá-las quando o usuário navegar de volta pela pilha. Por exemplo, se o usuário estiver visualizando um álbum em um app de música, a navegação para cima pode levá-lo a uma atividade que lista todos os álbuns de um gênero musical escolhido. Nesse caso, se a pilha precisar ser criada, será necessário informar à atividade mãe a que gênero o álbum atual pertence para que a mãe possa mostrar a lista adequada, como se o usuário tivesse vindo dessa atividade. Para enviar essas informações a uma atividade mãe sintética, é necessário substituir o método onPrepareNavigateUpTaskStack(). Isso fornece um objeto TaskStackBuilder que o sistema criou para sinalizar as atividades principais. O TaskStackBuilder contém objetos Intent que o sistema usa para criar cada atividade pai. Na implementação de onPrepareNavigateUpTaskStack(), é possível modificar o Intent adequado para adicionar dados extras que a atividade pai pode usar para determinar o contexto adequado e exibir a interface adequada.

Quando o sistema cria a TaskStackBuilder, ele adiciona os objetos Intent que são usados para criar as atividades mãe na ordem lógica, começando pela parte de cima da árvore de atividades. Portanto, o último Intent adicionado à matriz interna é o pai direto da atividade atual. Se você quiser modificar o Intent para o pai da atividade, primeiro determine o comprimento da matriz com getIntentCount() e transmita esse valor para editIntentAt().

Se a estrutura do app for mais complexa, há várias outras APIs disponíveis que permitem processar o comportamento da navegação para cima e personalizar totalmente a backstack sintética. Algumas das APIs que oferecem mais controle incluem:

onNavigateUp()
Substitua-o para realizar uma ação personalizada quando o usuário pressionar o botão "Para cima".
navigateUpTo(Intent)
Chame esse método para concluir a atividade atual e ir para a atividade indicada pelo Intent fornecido. Se a atividade existir na backstack, mas não for a mais próxima, todas as outras atividades entre a atividade atual e a atividade especificada com a intent também serão concluídas.
getParentActivityIntent()
Chamar isso para receber o Intent que vai iniciar o pai lógico da atividade atual.
shouldUpRecreateTask(Intent)
Chamar isso para consultar se uma backstack sintética precisa ser criada para navegar para cima. Retorna verdadeiro se uma pilha sintética precisar ser criada e falso se a pilha apropriada já existir.
finishAffinity()
Chame esse método para finalizar a atividade atual e todas as atividades pai com a mesma afinidade de tarefa que estão conectadas à atividade atual. Se você substituir os comportamentos padrão, como onNavigateUp(), chame esse método ao criar uma pilha de volta sintética na navegação para cima.
onCreateNavigateUpTaskStack
Substitua essa opção se precisar controlar totalmente como a pilha de tarefas sintética é criada. Se você quiser simplesmente adicionar alguns dados extras às intents da backstack, substitua onPrepareNavigateUpTaskStack()

No entanto, a maioria dos apps não precisa usar essas APIs ou implementar onPrepareNavigateUpTaskStack(), mas pode alcançar o comportamento correto simplesmente adicionando android:parentActivityName a cada elemento <activity>.

Multimídia

Codecs de mídia

A classe MediaCodec fornece acesso a codecs de mídia de baixo nível para codificar e decodificar mídia. É possível instanciar um MediaCodec chamando createEncoderByType() para codificar mídia ou createDecoderByType() para decodificar mídia. Cada um desses métodos usa um tipo MIME para o tipo de mídia que você quer codificar ou decodificar, como "video/3gpp" ou "audio/vorbis".

Com uma instância de MediaCodec criada, é possível chamar configure() para especificar propriedades, como o formato de mídia ou se o conteúdo está ou não criptografado.

Se você estiver codificando ou decodificando a mídia, o restante do processo será o mesmo depois que você criar o MediaCodec. Primeiro, chame getInputBuffers() para receber uma matriz de objetos ByteBuffer de entrada e getOutputBuffers() para receber uma matriz de objetos ByteBuffer de saída.

Quando estiver tudo pronto para codificar ou decodificar, chame dequeueInputBuffer() para receber a posição do índice do ByteBuffer (da matriz de buffers de entrada) que você vai usar para alimentar a mídia de origem. Depois de preencher o ByteBuffer com a mídia de origem, libere a propriedade do buffer chamando queueInputBuffer().

Da mesma forma, para o buffer de saída, chame dequeueOutputBuffer() para receber a posição do índice do ByteBuffer em que você vai receber os resultados. Depois de ler a saída de ByteBuffer, libere a propriedade chamando releaseOutputBuffer().

É possível processar dados de mídia criptografados nos codecs chamando queueSecureInputBuffer() em conjunto com as APIs MediaCrypto, em vez do queueInputBuffer() normal.

Para mais informações sobre como usar codecs, consulte a documentação do MediaCodec.

Gravar áudio no sinal

O novo método startRecording() permite iniciar a gravação de áudio com base em uma dica definida por um MediaSyncEvent. O MediaSyncEvent especifica uma sessão de áudio (como a definida por MediaPlayer), que, quando concluída, aciona o gravador de áudio para começar a gravação. Por exemplo, você pode usar essa funcionalidade para tocar um tom de áudio que indique o início de uma sessão de gravação, que começa automaticamente para que você não precise sincronizar manualmente o tom e o início da gravação.

Faixas de texto com marcação de tempo

O MediaPlayer agora processa faixas de texto na banda e fora da banda. As faixas de texto na faixa são uma faixa de texto em uma fonte de mídia MP4 ou 3GPP. Faixas de texto fora de banda podem ser adicionadas como uma fonte de texto externa pelo método addTimedTextSource(). Depois que todas as origens de faixas de texto externas forem adicionadas, getTrackInfo() precisará ser chamado para receber a lista atualizada de todas as faixas disponíveis em uma origem de dados.

Para definir a faixa a ser usada com MediaPlayer, chame selectTrack() usando a posição do índice da faixa que você quer usar.

Para receber uma notificação quando a faixa de texto estiver pronta para ser reproduzida, implemente a interface MediaPlayer.OnTimedTextListener e transmita para setOnTimedTextListener().

Efeitos de áudio

A classe AudioEffect agora oferece suporte a outros tipos de pré-processamento de áudio ao capturar áudio:

  • O cancelamento de eco acústico (AEC) com AcousticEchoCanceler remove a contribuição do sinal recebido da parte remota do sinal de áudio capturado.
  • O controle de ganho automático (AGC) com AutomaticGainControl normaliza automaticamente a saída do sinal capturado.
  • O supressão de ruído (NS, na sigla em inglês) com NoiseSuppressor remove o ruído de fundo do sinal capturado.

É possível aplicar esses efeitos de pré-processador no áudio capturado com um AudioRecord usando uma das subclasses AudioEffect.

Observação:não há garantia de que todos os dispositivos sejam compatíveis com esses efeitos. Por isso, sempre verifique a disponibilidade chamando isAvailable() na classe de efeito de áudio correspondente.

Reprodução sem intervalos

Agora é possível realizar a reprodução sem intervalos entre dois objetos MediaPlayer separados. A qualquer momento antes da primeira MediaPlayer terminar, chame setNextMediaPlayer(), e o Android tentará iniciar o segundo player assim que o primeiro parar.

Roteador de mídia. As novas APIs MediaRouter, MediaRouteActionProvider e MediaRouteButton fornecem mecanismos padrão e interface para escolher onde abrir a mídia.

Câmera

Movimento de foco automático

A nova interface Camera.AutoFocusMoveCallback permite detectar mudanças no movimento de foco automático. Você pode registrar sua interface com setAutoFocusMoveCallback(). Em seguida, quando a câmera estiver em um modo de foco automático contínuo (FOCUS_MODE_CONTINUOUS_VIDEO ou FOCUS_MODE_CONTINUOUS_PICTURE), você vai receber uma chamada para onAutoFocusMoving(), que informa se o foco automático começou a se mover ou parou.

Sons da câmera

A classe MediaActionSound oferece um conjunto simples de APIs para produzir sons padrão feitos pela câmera ou outras ações de mídia. Use essas APIs para reproduzir o som apropriado ao criar uma câmera de fotos ou vídeos personalizada.

Para reproduzir um som, basta instanciar um objeto MediaActionSound, chamar load() para pré-carregar o som desejado e, no momento apropriado, chamar play().

Conectividade

Android Beam

O Android Beam™ agora oferece suporte a transferências de payload grandes por Bluetooth. Quando você define os dados a serem transferidos com o novo método setBeamPushUris() ou a nova interface de callback NfcAdapter.CreateBeamUrisCallback, o Android transfere a transferência de dados para o Bluetooth ou outro transporte alternativo para alcançar velocidades de transferência mais rápidas. Isso é especialmente útil para payloads grandes, como arquivos de imagem e áudio, e não requer pareamento visível entre os dispositivos. Não é necessário fazer nada extra no app para aproveitar as transferências por Bluetooth.

O método setBeamPushUris() usa uma matriz de objetos Uri que especificam os dados que você quer transferir do app. Como alternativa, é possível implementar a interface NfcAdapter.CreateBeamUrisCallback, que pode ser especificada para sua atividade chamando setBeamPushUrisCallback().

Ao usar a interface de callback, o sistema chama o método createBeamUris() da interface quando o usuário executa um compartilhamento com o Android Beam para que você possa definir os URIs a serem compartilhados no momento do compartilhamento. Isso é útil se os URIs a serem compartilhados podem variar dependendo do contexto do usuário na atividade. Já chamar setBeamPushUris() é útil quando os URIs a serem compartilhados não mudam e podem ser definidos com segurança com antecedência.

Detecção de serviço de rede

O Android 4.1 adiciona suporte à descoberta de serviços baseada em DNS multicast, que permite encontrar e se conectar a serviços oferecidos por dispositivos pares por Wi-Fi, como dispositivos móveis, impressoras, câmeras, players de mídia e outros que estão registrados na rede local.

O novo pacote android.net.nsd contém as novas APIs que permitem transmitir seus serviços na rede local, descobrir dispositivos locais na rede e se conectar a dispositivos.

Para registrar seu serviço, primeiro crie um objeto NsdServiceInfo e defina as diversas propriedades do serviço com métodos como setServiceName(), setServiceType() e setPort().

Em seguida, implemente NsdManager.RegistrationListener e transmita-o para registerService() com o NsdServiceInfo.

Para descobrir serviços na rede, implemente NsdManager.DiscoveryListener e transmita-o para discoverServices().

Quando o NsdManager.DiscoveryListener recebe callbacks sobre os serviços encontrados, você precisa resolver o serviço chamando resolveService() e transmitindo uma implementação de NsdManager.ResolveListener que recebe um objeto NsdServiceInfo com informações sobre o serviço descoberto, permitindo que você inicie a conexão.

Descoberta de serviços por Wi-Fi P2P

As APIs Wi-Fi P2P foram aprimoradas no Android 4.1 para oferecer suporte à descoberta de serviços pré-associados no WifiP2pManager. Isso permite que você descubra e filtre dispositivos próximos por serviços usando o Wi-Fi P2P antes de se conectar a um deles. Já o Network Service Discovery permite descobrir um serviço em uma rede conectada existente (como uma rede Wi-Fi local).

Para transmitir seu app como um serviço por Wi-Fi para que outros dispositivos possam descobrir e se conectar a ele, chame addLocalService() com um objeto WifiP2pServiceInfo que descreve os serviços do app.

Para iniciar a descoberta de dispositivos próximos por Wi-Fi, primeiro é preciso decidir se você vai se comunicar usando o Bonjour ou o Upnp. Para usar o Bonjour, primeiro configure alguns listeners de callback com setDnsSdResponseListeners(), que recebe um WifiP2pManager.DnsSdServiceResponseListener e um WifiP2pManager.DnsSdTxtRecordListener. Para usar o Upnp, chame setUpnpServiceResponseListener(), que recebe um WifiP2pManager.UpnpServiceResponseListener.

Antes de começar a descobrir serviços em dispositivos locais, você também precisa chamar addServiceRequest(). Quando o WifiP2pManager.ActionListener transmitido para esse método receber um callback bem-sucedido, você poderá começar a descobrir serviços em dispositivos locais chamando discoverServices().

Quando os serviços locais forem descobertos, você vai receber um callback para WifiP2pManager.DnsSdServiceResponseListener ou WifiP2pManager.UpnpServiceResponseListener, dependendo se você se registrou para usar o Bonjour ou o Upnp. O callback recebido em ambos os casos contém um objeto WifiP2pDevice que representa o dispositivo par.

Uso da rede

O novo método isActiveNetworkMetered() permite verificar se o dispositivo está conectado a uma rede limitada. Ao verificar esse estado antes de realizar transações de rede intensivas, você pode ajudar a gerenciar o uso de dados que pode custar dinheiro aos usuários e tomar decisões informadas sobre se deve realizar as transações agora ou mais tarde (por exemplo, quando o dispositivo se conectar ao Wi-Fi).

Acessibilidade

APIs do serviço de acessibilidade

O alcance das APIs de serviço de acessibilidade aumentou significativamente no Android 4.1. Agora, é possível criar serviços que monitoram e respondem a mais eventos de entrada, como gestos complexos usando onGesture() e outros eventos de entrada com adições às classes AccessibilityEvent, AccessibilityNodeInfo e AccessibilityRecord.

Os serviços de acessibilidade também podem realizar ações em nome do usuário, incluindo clicar, rolar e percorrer o texto usando performAction e setMovementGranularities. O método performGlobalAction() também permite que os serviços realizem ações como "Voltar", "Tela inicial" e abrir apps recentes e notificações.

Navegação personalizável do app

Ao criar um app Android, agora é possível personalizar esquemas de navegação encontrando elementos com foco e widgets de entrada usando findFocus() e focusSearch(), além de definir o foco usando setAccessibilityFocused().

Widgets mais acessíveis

A nova classe android.view.accessibility.AccessibilityNodeProvider permite que você mostre visualizações personalizadas complexas para serviços de acessibilidade, para que eles possam apresentar as informações de maneira mais acessível. O android.view.accessibility.AccessibilityNodeProvider permite que um widget do usuário com conteúdo avançado, como uma grade de calendário, apresente uma estrutura semântica lógica para serviços de acessibilidade completamente separada da estrutura de layout do widget. Essa estrutura semântica permite que os serviços de acessibilidade apresentem um modelo de interação mais útil para usuários com deficiência visual.

Copiar e colar

Copiar e colar com intents

Agora você pode associar um objeto ClipData a um Intent usando o método setClipData(). Isso é especialmente útil ao usar uma intent para transferir vários URIs content: para outro aplicativo, como ao compartilhar vários documentos. Os URIs content: fornecidos dessa forma também respeitarão as flags da intent para oferecer acesso de leitura ou gravação, permitindo que você conceda acesso a vários URIs em uma intent. Ao iniciar uma intent ACTION_SEND ou ACTION_SEND_MULTIPLE, os URIs fornecidos na intent agora são propagados automaticamente para a ClipData. Assim, o receptor pode ter acesso a eles.

Suporte a estilos de HTML e string

A classe ClipData agora oferece suporte a texto com estilo (como HTML ou strings com estilo do Android). É possível adicionar texto estilizado em HTML à ClipData com newHtmlText().

RenderScript

A funcionalidade de cálculo do RenderScript foi aprimorada com os seguintes recursos:

  • Suporte a vários kernels em um script.
  • Suporte para leitura da alocação com amostradores filtrados do compute em uma nova API de script rsSample.
  • Suporte a diferentes níveis de precisão de FP em #pragma.
  • Suporte para consulta de mais informações de objetos RS por um script de computação.
  • Várias melhorias de desempenho.

Novos pragmas também estão disponíveis para definir a precisão de ponto flutuante exigida pelos Renderscripts de computação. Isso permite que você ative operações NEON, como operações matemáticas de vetor rápido no caminho da CPU, que não seriam possíveis com o padrão IEEE 754-2008 completo.

Observação:o mecanismo gráfico experimental do Renderscript foi descontinuado.

Animação

Animações de inicialização de atividades

Agora você pode iniciar um Activity usando animações de zoom ou suas próprias animações personalizadas. Para especificar a animação desejada, use as APIs ActivityOptions para criar uma Bundle que você pode transmitir para qualquer um dos métodos que iniciam uma atividade, como startActivity().

A classe ActivityOptions inclui um método diferente para cada tipo de animação que você quer mostrar quando a atividade for aberta:

makeScaleUpAnimation()
Cria uma animação que aumenta a janela de atividade de uma posição inicial especificada na tela e um tamanho inicial especificado. Por exemplo, a tela inicial no Android 4.1 usa isso ao abrir um app.
makeThumbnailScaleUpAnimation()
Cria uma animação que aumenta a janela de atividade a partir de uma posição especificada e de uma imagem de miniatura fornecida. Por exemplo, a janela "Apps recentes" no Android 4.1 usa isso ao retornar a um app.
makeCustomAnimation()
Cria uma animação definida pelos seus próprios recursos: uma que define a animação para a abertura da atividade e outra para a atividade ser interrompida.

Animador de tempo

O novo TimeAnimator oferece um mecanismo de callback simples com o TimeAnimator.TimeListener, que notifica você em todos os frames da animação. Não há duração, interpolação ou definição de valor do objeto com este Animator. O callback do listener recebe informações para cada frame, incluindo o tempo total decorrido e o tempo decorrido desde o frame de animação anterior.

Interface do usuário

Notificações

No Android 4.1, é possível criar notificações com regiões de conteúdo maiores, visualizações de imagens grandes, vários botões de ação e prioridade configurável.

Estilos de notificação

O novo método setStyle() permite especificar um dos três novos estilos de notificação, cada um com uma região de conteúdo maior. Para especificar o estilo da região de conteúdo grande, transmita um destes objetos para setStyle():

Notification.BigPictureStyle
Para notificações que incluem um anexo de imagem grande.
Notification.BigTextStyle
Para notificações que incluem muito texto, como um único e-mail.
Notification.InboxStyle
Para notificações que incluem uma lista de strings, como snippets de vários e-mails.
Ações da notificação

Agora, há suporte para até dois botões de ação que aparecem na parte inferior da mensagem de notificação, independentemente de ela usar o estilo normal ou maior.

Para adicionar um botão de ação, chame addAction(). Esse método usa três argumentos: um recurso drawable para um ícone, texto para o botão e um PendingIntent que define a ação a ser realizada.

Prioridades

Agora é possível indicar ao sistema a importância da notificação para afetar a ordem dela na lista definindo a prioridade com setPriority(). É possível transmitir um dos cinco níveis de prioridade diferentes definidos pelas constantes PRIORITY_* na classe Notification. O padrão é PRIORITY_DEFAULT, e há dois níveis mais altos e dois níveis mais baixos.

As notificações de alta prioridade são aquelas que os usuários geralmente querem responder rapidamente, como uma nova mensagem instantânea, mensagem de texto ou lembrete de evento iminente. As notificações de baixa prioridade são eventos da agenda expirados ou promoções de apps.

Controles da interface do sistema

O Android 4.0 (Ice Cream Sandwich) adicionou novas flags para controlar a visibilidade dos elementos da IU do sistema, como escurecer a aparência da barra do sistema ou fazer com que ela desapareça completamente nos aparelhos. O Android 4.1 adiciona mais algumas flags que permitem controlar ainda mais a aparência dos elementos da interface do sistema e o layout da atividade em relação a eles chamando setSystemUiVisibility() e transmitindo as seguintes flags:

SYSTEM_UI_FLAG_FULLSCREEN
Oculta a interface do sistema não crítica (como a barra de status). Se a atividade usa a barra de ações no modo de sobreposição (ativando android:windowActionBarOverlay), essa sinalização também oculta a barra e faz isso com uma animação coordenada ao ocultar e mostrar os dois.
SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
Define o layout da atividade para usar a mesma área de tela disponível quando você ativa SYSTEM_UI_FLAG_FULLSCREEN, mesmo que os elementos da interface do sistema ainda estejam visíveis. Embora partes do layout sejam sobrepostas pela interface do sistema, isso é útil se o app oculta e mostra a interface do sistema com SYSTEM_UI_FLAG_FULLSCREEN com frequência, porque evita que o layout se ajuste aos novos limites de layout sempre que a interface do sistema é ocultada ou exibida.
SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION
Define o layout da atividade para usar a mesma área de tela disponível quando você ativa SYSTEM_UI_FLAG_HIDE_NAVIGATION (adicionado no Android 4.0), mesmo que os elementos da interface do sistema ainda estejam visíveis. Embora partes do layout sejam sobrepostas pela barra de navegação, isso é útil se o app oculta e mostra a barra de navegação com frequência com SYSTEM_UI_FLAG_HIDE_NAVIGATION, porque evita que o layout seja ajustado aos novos limites de layout sempre que a barra de navegação é ocultada ou aparece.
SYSTEM_UI_FLAG_LAYOUT_STABLE
Adicione essa flag se você estiver usando SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN e/ou SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION para garantir que, ao chamar fitSystemWindows() em uma visualização, os limites definidos permaneçam consistentes em relação ao espaço de tela disponível. Ou seja, com essa flag definida, fitSystemWindows() vai se comportar como se a visibilidade dos elementos da IU do sistema não fosse alterada, mesmo depois de ocultar toda a IU do sistema.

Para saber mais sobre as outras sinalizações de IU do sistema relacionadas, leia sobre as que foram adicionadas no Android 4.0.

Visualizações remotas

GridLayout e ViewStub agora são visualizações remotas, para que você possa usá-las em layouts para widgets de apps e layouts personalizados de notificações.

Famílias de fontes

O Android 4.1 adiciona várias outras variantes do estilo de fonte Roboto, totalizando 10 variantes, e todas elas podem ser usadas por apps. Agora seus apps têm acesso ao conjunto completo de variantes leves e condensadas.

O conjunto completo de variantes de fonte Roboto disponíveis é:

  • Regular
  • Itálico
  • Negrito
  • Negrito e itálico
  • Claro
  • Itálico claro
  • Condensado regular
  • Condensado itálico
  • Negrito condensado
  • Negrito e itálico condensado

É possível aplicar qualquer um deles com o novo atributo fontFamily em combinação com o atributo textStyle.

Os valores aceitos para fontFamily são:

  • "sans-serif" para Roboto normal
  • "sans-serif-light" para Roboto Light
  • "sans-serif-condensed" para Roboto Condensed

Em seguida, aplique negrito e/ou itálico com os valores textStyle "bold" e "italic". Você pode aplicar os dois da seguinte maneira: android:textStyle="bold|italic".

Também é possível usar Typeface.create(). Por exemplo, Typeface.create("sans-serif-light", Typeface.NORMAL).

Framework de entrada

Vários dispositivos de entrada

A nova classe InputManager permite consultar o conjunto de dispositivos de entrada conectados no momento e se registrar para receber notificações quando um novo dispositivo for adicionado, modificado ou removido. Isso é útil principalmente se você está criando um jogo com suporte a vários jogadores e quer detectar quantos controles estão conectados e quando há mudanças no número de controles.

É possível consultar todos os dispositivos de entrada conectados chamando getInputDeviceIds(). Isso retorna uma matriz de números inteiros, cada um sendo um ID para um dispositivo de entrada diferente. Em seguida, chame getInputDevice() para adquirir um InputDevice para um ID de dispositivo de entrada especificado.

Se você quiser ser informado quando novos dispositivos de entrada forem conectados, modificados ou desconectados, implemente a interface InputManager.InputDeviceListener e registre-a com registerInputDeviceListener().

Vibrar para controladores de entrada

Se os dispositivos de entrada conectados tiverem recursos de vibração próprios, agora é possível controlar a vibração desses dispositivos usando as APIs Vibrator existentes, bastando chamar getVibrator() no InputDevice.

Permissões

Estas são as novas permissões:

READ_EXTERNAL_STORAGE
Concede acesso de leitura protegido ao armazenamento externo. No Android 4.1, por default, todos os aplicativos ainda têm acesso de leitura. Isso será alterado em uma versão futura para exigir que os aplicativos solicitem explicitamente acesso de leitura usando essa permissão. Se o aplicativo já solicitar acesso de gravação, ele também receberá acesso de leitura automaticamente. Há uma nova opção de desenvolvedor para ativar a restrição de acesso de leitura para que os desenvolvedores testem os apps em relação ao comportamento do Android no futuro.
android.Manifest.permission.READ_USER_DICTIONARY
Permite que um aplicativo leia o dicionário do usuário. Isso só é necessário para um IME ou um editor de dicionário, como o app Configurações.
READ_CALL_LOG
Permite que um aplicativo leia o registro de chamadas do sistema, que contém informações sobre chamadas recebidas e efetuadas.
WRITE_CALL_LOG
Permite que um app modifique o registro de chamadas do sistema armazenado no smartphone
android.Manifest.permission.WRITE_USER_DICTIONARY
Permite que um app grave no dicionário de palavras do usuário.

Recursos do dispositivo

O Android 4.1 inclui uma nova declaração de recurso para dispositivos dedicados à exibição da interface do usuário em uma tela de televisão: FEATURE_TELEVISION. Para declarar que o app exige uma interface de televisão, declare esse recurso no arquivo de manifesto com o elemento <uses-feature>:

<manifest ... >
    <uses-feature android:name="android.hardware.type.television"
                  android:required="true" />
    ...
</manifest>

Esse recurso define "televisão" como uma experiência típica de televisão na sala de estar: exibida em uma tela grande, com o usuário sentado distante e o formato predominante de entrada é algo como um botão direcional e geralmente sem dispositivos como mouse, ponteiro e tela touchscreen.