Android 4.1 APIs

API de nível: 16

Android 4.1 (JELLY_BEAN) é uma progressão da plataforma que oferece melhorias e experiência do usuário aprimorada. Ele adiciona novos recursos para usuários e desenvolvedores de aplicativos. Este documento fornece uma introdução aos conceitos mais importantes novas APIs úteis para desenvolvedores de aplicativos.

Como desenvolvedor de aplicativos, o Android 4.1 está disponível para você no SDK Manager como uma imagem do sistema que pode executada no Android Emulator e em uma plataforma de SDK na qual você pode criar seu aplicativo. Você deve faça o download da imagem e da plataforma do sistema o mais rápido possível para criar e testar seu no Android 4.1.

Para otimizar seu aplicativo para dispositivos com o Android 4.1, defina o targetSdkVersion como "16", instale em uma imagem do sistema Android 4.1, testá-lo e publicar uma atualização com essa alteração.

Você podem usar APIs no Android 4.1 e, ao mesmo tempo, oferecer suporte a versões mais antigas, adicionando ao código que verificam o nível da API do sistema antes da execução APIs não compatíveis com seu minSdkVersion. Para saber mais sobre manter a compatibilidade com versões anteriores, leia Criação de compatibilidade com versões anteriores IUs.

Para mais informações sobre como os níveis de API funcionam, consulte O que é uma API Nível?

Componentes do app

Serviços isolados

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

Gerenciamento de memória

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

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

Provedores de conteúdo

Um novo método, acquireUnstableContentProviderClient(), permite acessar um ContentProviderClient que pode ser "instável". para que seu app não falhe se que o provedor de conteúdo faz. Ele é útil quando você está interagindo com provedores de conteúdo em um ambiente app.

Planos fundo interativos

Novo protocolo de intent para iniciar diretamente a atividade de visualização do plano de fundo interativo e ajudar você os usuários selecionam facilmente seu plano de fundo interativo sem forçá-los a sair. seu app e navegar pelo seletor de plano de fundo da tela inicial.

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

Navegação da pilha de apps

O Android 4.1 facilita muito a implementação de padrões de design adequados para a navegação para cima. Tudo o que você precisa fazer é adicionar o android:parentActivityName a cada elemento <activity> no no arquivo de manifesto. O sistema usa essas informações para abrir a atividade adequada quando o usuário pressiona o botão Para cima na barra de ações (enquanto também termina a atividade atual). Então, se você declarar o android:parentActivityName para cada atividade, o método onOptionsItemSelected() não é necessário para processar cliques no ícone de aplicativo da barra de ações. O sistema agora lida com esses eventos e retoma ou cria a atividade apropriada.

Isso é particularmente útil para cenários em que o usuário insere uma das atividades do seu aplicativo. um "mergulho profundo" como de uma notificação ou de uma intent aplicativo diferente (conforme descrito no guia de design para Como navegar entre aplicativos). Quando o usuário inserir a atividade dessa forma, o aplicativo poderá não ter naturalmente uma backstack de atividades que podem ser retomadas enquanto 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 pai e, em caso negativo, construções uma backstack sintética que contém todas as atividades pai.

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

Quando o sistema cria uma backstack sintética para o app, ele cria um Intent básico para gerar uma nova instância de cada atividade mãe. Portanto, não há o estado salvo para as atividades pai, da mesma forma que você esperaria se o usuário tivesse navegado naturalmente através para cada atividade. Se qualquer uma das atividades pai normalmente mostrar uma interface dependente de o contexto do usuário, essas informações de contexto estarão ausentes e você deverá entregá-las quando o usuário e navegar de volta pela pilha. Por exemplo, se o usuário estiver visualizando um álbum em um app de música, navegar para cima pode levar a uma atividade que lista todos os álbuns em uma gênero musical. Nesse caso, se for necessário criar a pilha, é necessário informar o pai atividade a que gênero o álbum atual pertence para que o pai possa exibir a lista adequada como se o usuário realmente veio dessa atividade. Para enviar essas informações a um elemento pai sintético atividade, substitua o método onPrepareNavigateUpTaskStack(). Isso fornece um objeto TaskStackBuilder que o sistema criou para sintetizar as atividades pai. O TaskStackBuilder contém objetos Intent que o sistema usa para criar cada atividade mãe. Em seu implementação de onPrepareNavigateUpTaskStack(), é possível modificar a Intent adequada para adicionar dados extras que a atividade pai pode usar para determinar o contexto e a exibição apropriados a interface adequada.

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

Caso a estrutura do seu app seja mais complexa, há várias outras APIs disponíveis que permitem lidar com o comportamento da navegação para cima e personalizar totalmente a backstack sintética. Algumas das APIs que dão a você incluem:

onNavigateUp()

Substitua-o para realizar uma ação personalizada quando o usuário pressionar o botão "Para cima".

navigateUpTo(Intent)

Chame este botão para finalizar a atividade atual e ir para a atividade indicada pelo fornecido Intent. Se a atividade existir na backstack, mas não for o pai mais próximo, todas as outras atividades entre a atividade atual e o específica com a intent também são concluídas.

getParentActivityIntent()

Chame esse método para receber o Intent que iniciará a lógica pai para a atividade atual.

shouldUpRecreateTask(Intent)

Chame para consultar se uma backstack sintética precisa ser criada para navegar para cima. Retorna "true" se for necessário criar uma pilha sintética, "false" se a pilha adequada já existe.

finishAffinity()

Chame esta opção para finalizar a atividade atual e todas as atividades mãe com a mesma afinidade de tarefas encadeadas à atividade atual. Se você substituir os comportamentos padrão, como onNavigateUp(), chame esse método ao criar uma backstack sintética com a navegação para cima.

onCreateNavigateUpTaskStack

Substitua essa opção se precisar controlar totalmente como a pilha de tarefas sintéticas é criada. Se você quiser simplesmente adicionar mais dados às intents da backstack, substitua onPrepareNavigateUpTaskStack()

No entanto, a maioria dos apps não precisa usar essas APIs ou implementar onPrepareNavigateUpTaskStack(), mas pode atingir o comportamento correto simplesmente ao adicionar 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 codificação e decodificando sua mídia. Você pode instanciar um MediaCodec chamando createEncoderByType() para codificar mídia ou chamar createDecoderByType() para decodificar mídia. Cada um desses os métodos usam 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, você pode chamar configure() para especificar propriedades como o formato de mídia ou se o conteúdo está criptografado ou não.

Esteja você codificando ou decodificando sua mídia, o restante do processo é o mesmo depois de você crie a MediaCodec. Primeiro, chame getInputBuffers() para ter uma matriz de entrada ByteBuffer. 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 de índice do ByteBuffer (da matriz de buffers de entrada) que você precisa usar para alimentar sua origem. mídia. 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 de ByteBuffer em que receberá os resultados. Depois de ler a saída do ByteBuffer, liberar 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 que você comece a gravação de áudio com base em uma dica definida por um MediaSyncEvent. O MediaSyncEvent especifica uma sessão de áudio. (como definido por MediaPlayer), que, quando concluído, aciona no gravador de áudio para começar a gravar. Por exemplo, é possível usar essa funcionalidade para reproduzir um toque de áudio que indique o início de uma sessão de gravação é iniciado automaticamente para que você não precise sincronizar manualmente o tom e o início de gravação.

Faixas de texto com marcação de tempo

O MediaPlayer agora processa faixas de texto dentro e fora da banda. As faixas de texto em banda vêm como uma faixa de texto dentro de uma fonte de mídia MP4 ou 3GPP. Texto fora de banda faixas podem ser adicionadas como fonte de texto externa usando o método addTimedTextSource(). Depois de todo o texto externo origens de faixas são adicionadas, getTrackInfo() deve ser chamado para a lista atualizada de todas as faixas disponíveis em uma fonte de dados.

Para definir a faixa a ser usada com o MediaPlayer, você precisa chame selectTrack() usando o índice para a faixa que você quer usar.

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

Efeitos de áudio

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

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

Você pode aplicar esses efeitos de pré-processador em áudio capturado com um AudioRecord usando um dos AudioEffect subclasses.

Observação:não é possível garantir que todos os dispositivos sejam compatíveis com essas Portanto, sempre verifique primeiro a disponibilidade chamando isAvailable() no classe de efeito de áudio.

Reprodução sem intervalos

Agora é possível reproduzir sem lacunas entre dois MediaPlayer. A qualquer momento antes do término do primeiro MediaPlayer, chamar setNextMediaPlayer() e o Android tenta iniciar o segundo player assim que o primeiro parar.

Câmera

Movimento de foco automático

A nova interface Camera.AutoFocusMoveCallback permite que você escute para alterações no movimento de foco automático. Você pode registrar sua interface com setAutoFocusMoveCallback(). Então, quando a câmera está no 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 de se mover.

Sons da câmera

A classe MediaActionSound fornece um conjunto simples de APIs para produzir sons padrão emitidos pela câmera ou por outras ações de mídia. Use essas APIs para reproduzir o som apropriado ao criar uma câmera estática ou de vídeo personalizada.

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

Conectividade

Android Beam

O Android BeamTM agora oferece suporte a grandes transferências de payload por Bluetooth. Quando você define os dados para transferir com o novo setBeamPushUris() ou a nova interface de callback NfcAdapter.CreateBeamUrisCallback, o Android entrega a transferência de dados para Bluetooth ou outro transporte alternativo para velocidades de transferência mais rápidas. Isso é especialmente útil para payloads grandes, como imagens e arquivos de áudio e não exige pareamento visível entre os dispositivos. Nenhum trabalho adicional é necessário 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, implemente NfcAdapter.CreateBeamUrisCallback que você pode especificar para sua atividade chamando setBeamPushUrisCallback().

Ao usar o botão interface de callback, o sistema chamará o método createBeamUris() da interface quando o 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 dentro do atividade, enquanto chamar setBeamPushUris() é útil quando os URIs a serem compartilhados não mudam e você pode defini-los com segurança e com antecedência.

Detecção de serviço de rede

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

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

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

Em seguida, é necessário implementar NsdManager.RegistrationListener. e a transmita para registerService() com seu NsdServiceInfo.

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

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

Descoberta de serviços Wi-Fi P2P

As APIs de Wi-Fi P2P foram aprimoradas no Android 4.1 para oferecer suporte à descoberta de serviços de pré-associação em o WifiP2pManager. Isso permite que você descubra e filtre itens por perto dispositivos por serviços usando Wi-Fi P2P antes de se conectar a um deles, enquanto o Serviço de A descoberta permite que você descubra um serviço em uma rede conectada existente (como uma rede Wi-Fi local ou em uma rede VPC.

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

Para iniciar a descoberta de dispositivos próximos por Wi-Fi, você precisa primeiro decidir se se comunicar usando Bonjour ou Upnp. Para usar o Bonjour, primeiro configure alguns listeners de callback com setDnsSdResponseListeners(), que usa um WifiP2pManager.DnsSdServiceResponseListener e um WifiP2pManager.DnsSdTxtRecordListener. Para usar o Upnp, chame setUpnpServiceResponseListener(), que usa 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 uma se um callback for 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 registrados para usar Bonjour ou Upnp. O retorno de chamada recebido em qualquer um dos casos contém um Objeto WifiP2pDevice que representa o dispositivo de peering.

Uso da rede

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

Acessibilidade

APIs do serviço de acessibilidade

O alcance das APIs de serviços de acessibilidade foi aumentado significativamente no Android 4.1. Agora permite criar serviços que monitoram e respondem a mais eventos de entrada, como gestos complexos usando onGesture() e outros eventos de entrada fazendo 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; Método performGlobalAction() também permite que serviços executem ações como "Voltar", "Início" e abrir "Recentes" Apps e notificações.

Navegação de apps personalizável

Ao criar um app Android, agora você pode personalizar esquemas de navegação encontrando elementos e widgets de entrada usando findFocus() e focusSearch(), e definir o foco usando setAccessibilityFocused().

Widgets mais acessíveis

A nova classe android.view.accessibility.AccessibilityNodeProvider permite que você: exibir visualizações personalizadas complexas para que os serviços de acessibilidade possam apresentar as informações em um mais acessível. O android.view.accessibility.AccessibilityNodeProvider permite que um usuário com conteúdo avançado, como grade de calendário, para apresentar uma estrutura semântica lógica para serviços de acessibilidade que são completamente separados da estrutura de layout do widget. Essa semântica permite que os serviços de acessibilidade apresentem um modelo de interação mais útil para usuários que estão 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á as sinalizações 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 propagadas automaticamente para o ClipData, para que o receptor possa que foi concedido a eles.

Suporte a estilos de HTML e string

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

RenderScript

A funcionalidade de computação do Renderscript foi aprimorada com os seguintes recursos:

• Suporte a vários kernels dentro de um script.
• Suporte para leitura da alocação com amostras filtradas da computação em uma nova API de script rsSample:
• Suporte a diferentes níveis de precisão de FP no #pragma.
• Suporte para consulta de outras informações de objetos RS de um script de computação.
• Várias melhorias de desempenho.

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

Observação:o mecanismo gráfico Renderscript experimental agora é descontinuada.

Animação

Animações de inicialização de atividades

Agora você pode iniciar uma 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ê possa e passar 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 atividades a partir de um início especificado posição na tela e um tamanho inicial especificado. Por exemplo, a tela inicial O Android 4.1 usa isso ao abrir um app.

makeThumbnailScaleUpAnimation()

Cria uma animação que aumenta a janela de atividade começando por um do anúncio e uma imagem em miniatura fornecida. Por exemplo, a janela "Apps recentes" O Android 4.1 usa isso ao retornar para um app.

makeCustomAnimation()

Cria uma animação definida pelos seus próprios recursos: um que define a animação do a abertura da atividade e outro para a atividade que está sendo interrompida.

Animador de tempo

O novo TimeAnimator fornece um callback simples mecanismo com o TimeAnimator.TimeListener que notifica em cada frame da animação. Não há duração, interpolação ou definição de valor de 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 da 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 para sua notificação de que cada um oferece uma região de conteúdo maior. Para especifique o estilo da região de conteúdo grande e transmita um destes objetos para setStyle():

Notification.BigPictureStyle

Para notificações com anexos de imagem grandes.

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 se a notificação usa 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 para perfrom.

Prioridades

Agora, você pode sugerir ao sistema a importância da sua notificação para afetar o ordem da notificação na lista, definindo a prioridade com setPriority(). Você pode 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 abaixo.

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

Controles para a interface do sistema

O Android 4.0 (Ice Cream Sandwich) adicionou novas sinalizações para controlar a visibilidade da interface de usuário do sistema , como escurecer a aparência da barra do sistema ou fazê-la desaparecer completamente nos celulares. O Android 4.1 adiciona mais algumas sinalizações que permitem controlar ainda mais a aparência do sistema Elementos da interface e o layout da sua atividade em relação a eles chamando setSystemUiVisibility() e passando as seguintes sinalizações:

SYSTEM_UI_FLAG_FULLSCREEN

Oculta a interface não crítica do sistema (como a barra de status). Se sua atividade usa a barra de ações no modo de sobreposição (por ativar android:windowActionBarOverlay), essa flag também vai ocultar a barra de ações e assim como 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 da tela que está disponível quando você SYSTEM_UI_FLAG_FULLSCREEN ativado, mesmo que os elementos da interface do sistema continuam visíveis. Embora partes do layout sejam sobrepostas pelo interface do sistema, isso é útil se seu aplicativo muitas vezes oculta e mostra a interface do sistema com SYSTEM_UI_FLAG_FULLSCREEN, porque evita que seu layout ajustando-se 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 da tela que está disponível quando você SYSTEM_UI_FLAG_HIDE_NAVIGATION ativado (adicionado no Android 4.0) mesmo que os elementos da IU do sistema ainda estejam visíveis. Embora partes do seu layout sejam sobrepostas pelo barra de navegação, isso é útil se seu aplicativo muitas vezes oculta e mostra a barra de navegação com SYSTEM_UI_FLAG_HIDE_NAVIGATION, porque isso evita que seu layout ajustando-se aos novos limites de layout sempre que a barra de navegação é ocultada ou exibida.

SYSTEM_UI_FLAG_LAYOUT_STABLE

É recomendável adicionar 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 que os limites definidos permanecem consistentes em relação ao espaço na tela disponível. Ou seja, com essa flag definida, a fitSystemWindows() vai se comportar como se a visibilidade dos elementos da interface do sistema não mudasse. mesmo depois de ocultar toda a interface do sistema.

Para saber mais sobre as outras flags relacionadas da interface do sistema, leia sobre aqueles adicionados 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 sua widgets de apps e layouts personalizados de notificação.

Famílias de fontes

O Android 4.1 adiciona muitas outras variantes do estilo de fonte Roboto para um total de 10 variantes, e todas elas podem ser usadas por apps. Agora seus apps têm acesso ao conjunto completo de recursos variantes condensadas.

O conjunto completo de variantes da fonte Roboto disponível é:

• Regular
• Itálico
• Negrito
• Negrito e itálico
• Claro
• Leve-itálico
• Normal condensado
• Itálico condensado
• Negrito condensado
• Negrito-itálico condensado

Você pode aplicar qualquer uma delas com o novo 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 condensado

Em seguida, você pode aplicar negrito e/ou itálico com valores textStyle "bold" e "italic". É possível aplicar ambos da seguinte forma: android:textStyle="bold|italic".

Você também pode 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 que você consulte as conjunto de dispositivos de entrada atualmente conectados e registrados para serem notificados quando um novo dispositivo é adicionado, alterado ou removido. Isso é especialmente útil se você estiver criando um jogo compatível com vários players e você quiser detectar quantos controles estão conectados e quando há mudanças no número de controladores.

É possível consultar todos os dispositivos de entrada conectados chamando getInputDeviceIds(): Isso retorna uma matriz de números inteiros, cada um sendo um ID de um dispositivo de entrada diferente. Em seguida, você poderá chamar 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, alterados ou desconectados, implementar a interface InputManager.InputDeviceListener e registrá-lo com registerInputDeviceListener().

Vibrar para controladores de entrada

Se os dispositivos de entrada conectados tiverem recursos de vibração próprios, será possível controlar a vibração desses dispositivos usando as APIs Vibrator existentes simplesmente chame 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 by por padrão, todos os aplicativos têm permissão de leitura acesso. Isso será alterado em uma versão futura para exigir que os aplicativos solicitem explicitamente acesso de leitura usando essa permissão. Caso seu aplicativo já solicite acesso de gravação, ele automaticamente o acesso de leitura. Há uma nova opção para desenvolvedores para ativar o acesso de leitura para que os desenvolvedores testem seus aplicativos em relação ao comportamento do Android na futuro.

android.Manifest.permission.READ_USER_DICTIONARY

Permite que um aplicativo leia o dicionário do usuário. Isso só deve ser exigido por 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 aplicativo modifique o registro de chamadas do sistema armazenado no seu smartphone

android.Manifest.permission.WRITE_USER_DICTIONARY

Permite que um aplicativo 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 que são dedicados para mostrar a 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" para ter uma experiência típica de televisão na sala de estar: exibido em uma tela grande, em que o usuário está sentado longe, e a forma dominante de entrada é algo como um botão direcional e geralmente não por toque ou mouse/dispositivo apontador.