Nível de API: {@sdkPlatformApiLevel}
O Android 5.0 (LOLLIPOP) oferece novos recursos para usuários e desenvolvedores de apps. Este documento fornece uma introdução às novas APIs mais relevantes.
Para uma visão de alto nível dos novos recursos da plataforma, veja os destaques do Android Lollipop.
Para começar a criar apps para o Android 5.0, primeiro é preciso conseguir o SDK do Android. Depois disso, use o Gerenciador de SDK para fazer o download das imagens do sistema e da plataforma de SDK do Android 5.0.
Para testar seus apps em um dispositivo real, inclua um Nexus 5 ou 7 com a
IMAGEM DE VISUALIZAÇÃO DO SISTEMA DO ANDROID.
Para melhor otimizar seu app para os dispositivos executando Android {@sdkPlatformVersion}, defina {@code targetSdkVersion} como "{@sdkPlatformApiLevel}", instale o app em uma imagem do sistema do Android {@sdkPlatformVersion}, teste-a e, em seguida, publique o app atualizado com essa alteração.
É possível usar as APIs do Android {@sdkPlatformVersion} ao mesmo tempo em que oferece suporte a versões mais antigas adicionando condições para o nível de API do sistema antes de executar APIs que não são compatíveis com seu {@code minSdkVersion}. Para saber mais sobre a manutenção de compatibilidade com versões anteriores, leia Suporte a diferentes versões de plataforma.
Para mais informações sobre como os níveis de API funcionam, leia O que é um nível de API?
Se você já tiver publicado um app para Android, esteja ciente de que seu app pode ser afetado por alterações feitas no Android 5.0.
A versão 4.4 apresentou um novo tempo de execução experimental do Android, o ART. Na versão 4.4, o ART era opcional, e o tempo de execução padrão continuava sendo o Dalvik. Com o Android 5.0, o ART agora é o tempo de execução padrão.
Para uma visão geral dos novos recursos do ART, consulte Introdução ao ART. Alguns dos principais recursos novos são:
A maioria dos apps para Android deve funcionar com o ART sem alterações. No entanto, algumas técnicas que funcionam em Dalvik não funcionam no ART. Para informações sobre os problemas mais importantes, consulte Verificação do comportamento do app no tempo de execução Android (ART). Preste especial atenção se:
Verifique se suas notificações consideram essas alterações do Android 5.0. Para saber mais sobre como fazer as notificações para o Android 5.0 e superior, consulte o Guia de design de notificações.
As notificações são desenhadas com texto escuro em planos de fundo brancos (ou muito claros) para corresponder aos novos widgets de material design. Verifique a aparência de todas as suas notificações com o novo esquema de cores. Se o resultado não estiver bom, corrija-o:
Se atualmente você estiver adicionando sons e vibrações às suas notificações usando as classes {@link android.media.Ringtone}, {@link android.media.MediaPlayer} ou {@link android.os.Vibrator}, remova este código para que o sistema possa apresentar notificações de forma correta no modo de prioridade. Em vez disso, use métodos {@link android.app.Notification.Builder} para adicionar sons e vibração.
Definir o dispositivo como {@link android.media.AudioManager#RINGER_MODE_SILENT RINGER_MODE_SILENT} faz com que o dispositivo entre no novo modo de prioridade. O dispositivo sai do modo prioridade se você o configurar para {@link android.media.AudioManager#RINGER_MODE_NORMAL RINGER_MODE_NORMAL} ou {@link android.media.AudioManager#RINGER_MODE_NORMAL RINGER_MODE_VIBRATE}.
Anteriormente, o Android usava {@link android.media.AudioManager#STREAM_MUSIC STREAM_MUSIC} como o stream principal para controlar o volume em tablets. No Android 5.0, o stream de volume principal para dispositivos smartphone e tablet agora está unificado e é controlado por {@link android.media.AudioManager#STREAM_RING STREAM_RING} ou {@link android.media.AudioManager#STREAM_NOTIFICATION STREAM_NOTIFICATION}.
Por padrão, as notificações agora são exibidas na tela de bloqueio no Android 5.0. Os usuários podem optar por proteger informações confidenciais evitando que elas sejam expostas, caso em que o sistema automaticamente redige o texto exibido pela notificação. Para personalizar esta notificação redigida, use {@link android.app.Notification.Builder#setPublicVersion(android.app.Notification) setPublicVersion()}.
Se a notificação não tiver informações pessoais ou se você desejar permitir o controle de reprodução de mídia na notificação, chame o método {@link android.app.Notification.Builder#setVisibility(int) setVisibility()} e defina o nível de visibilidade da notificação como {@link android.app.Notification#VISIBILITY_PUBLIC VISIBILITY_PUBLIC}.
Se você estiver implementando notificações que apresentam controles de transporte ou status de reprodução de mídia, considere a possibilidade de usar o novo modelo {@link android.app.Notification.MediaStyle}, em vez de um objeto {@link android.widget.RemoteViews.RemoteView} personalizado. Qualquer que seja a abordagem escolhida, defina a visibilidade da notificação como {@link android.app.Notification#VISIBILITY_PUBLIC VISIBILITY_PUBLIC} de modo que seus controles sejam acessíveis a partir da tela de bloqueio. Ao iniciar o Android 5.0, o sistema não mostra mais os objetos {@link android.media.RemoteControlClient} na tela de bloqueio. Para mais informações, consulte Caso seu app use RemoteControlClient.
As notificações agora podem aparecer em uma pequena janela flutuante (também chamada de notificação de alerta) quando o dispositivo estiver ativo (isto é, o dispositivo estiver desbloqueado e sua tela ativada). Essas notificações aparecem de maneira semelhante à forma compacta da sua notificação, exceto que as de alerta também mostram botões de ação. Os usuários podem utilizar ou dispensar notificações de alerta sem sair do app atual.
Exemplos de condições que podem acionar notificações de alerta incluem:
Caso seu app implemente notificações em qualquer um desses cenários, verifique se as notificações de alerta são exibidas corretamente.
O uso da classe {@link android.media.RemoteControlClient} foi suspenso. Alterne para a nova {@link android.media.session.MediaSession} API assim que possível.
O bloqueio de telas no Android 5.0 não mostra controles de transporte para {@link android.media.session.MediaSession} ou {@link android.media.RemoteControlClient}. Em vez disso, o app pode fornecer controle de reprodução de mídia de tela de bloqueio por meio de uma notificação. Isso dá ao app mais controle sobre a apresentação dos botões de mídia ao mesmo tempo em que fornece uma experiência consistente para usuários de dispositivos bloqueados e desbloqueados.
O Android 5.0 apresenta um novo modelo {@link android.app.Notification.MediaStyle} para essa finalidade. {@link android.app.Notification.MediaStyle} converte as ações de notificação que você adicionou com {@link android.app.Notification.Builder#addAction(int, java.lang.CharSequence, android.app.PendingIntent) Notification.Builder.addAction()} em botões compactos incorporados às notificações de reprodução de mídia do seu app. Passar o token da sessão para o método {@link android.app.Notification.MediaStyle#setMediaSession(android.media.session.MediaSession.Token) setSession()} para informar o sistema de que essa notificação controla uma sessão de mídia em andamento.
Defina a visibilidade da notificação como {@link android.app.Notification#VISIBILITY_PUBLIC VISIBILITY_PUBLIC} para marcar a notificação como segura a fim de ser exibida em qualquer tela de bloqueio (protegida ou não). Para mais informações, consulte Notificações na tela de bloqueio.
Para exibir controles de reprodução de mídia se o app estiver em execução na plataforma da Android TV ou do Android Wear, implemente a classe {@link android.media.session.MediaSession}. Você também deve implementar {@link android.media.session.MediaSession} caso seu app precise receber eventos de botão de mídia em dispositivos Android.
Com a introdução dos novos recursos de tarefas de atividades e documentos simultâneos do Android 5.0 (consulteDocumentos simultâneos e atividades na tela de recentes abaixo), o método {@link android.app.ActivityManager#getRecentTasks ActivityManager.getRecentTasks()} teve seu uso suspenso para aprimorar a privacidade do usuário. Para compatibilidade com versões anteriores, esse método ainda retorna um pequeno subconjunto de seus dados, incluindo a chamada de tarefas do próprio app e, possivelmente, outras tarefas não confidenciais (como Início). Se o app estiver usando esse método para recuperar suas próprias tarefas, use {@link android.app.ActivityManager#getAppTasks() getAppTasks()} em vez de recuperar essas informações.
O Android 5.0 apresenta o suporte a sistemas de 64 bits. O aprimoramento de 64 bits aumenta o espaço de endereço e melhora o desempenho ao mesmo tempo em que oferece suporte integral aos apps existentes de 32 bits. O suporte a 64 bits também melhora o desempenho de OpenSSL para criptografia. Além disso, a versão apresenta novas APIs do NDK de mídia nativas, bem como o suporte a OpenGL ES (GLES) 3.1.
Para usar o suporte a 64 bits fornecidos no Android 5.0, faça o download e instale o NDK Revision 10c a partir da página NDK do Android. Consulte as notas da versão do Revision 10c para mais informações sobre alterações importantes e correções de bug no NDK.
O método {@link android.content.Context#bindService(android.content.Intent, android.content.ServiceConnection, int) Context.bindService()} agora requer um {@link android.content.Intent} explícito e lança uma exceção se fornecido um propósito implícito. Para garantir que seu app é seguro, use um propósito explícito ao iniciar ou vincular seu {@link android.app.Service} e não declare filtros de intenção para o serviço.
O Android 5.0 altera o comportamento padrão para o app.
O lançamento futuro adiciona o suporte ao novo estilo do material design do Android. É possível criar apps com material design que é visualmente dinâmico e tem transições de elemento de interface do usuário que parecem naturais para os usuários. Esse suporte inclui:
Para saber mais sobre como adicionar a funcionalidade de material design ao seu app, consulte Material design.
Em versões anteriores, a tela de recentes podia exibir somente uma tarefa para cada app com o qual o usuário tivesse interagido mais recentemente. Agora seu app pode abrir mais tarefas conforme necessário para outras atividades simultâneas para documentos. Esse recurso facilita fazer muitas tarefas ao mesmo tempo ao permitir que os usuários alternem rapidamente entre atividades individuais e documentos da tela de recentes, com uma experiência consistente de alternação entre todos os apps. Exemplos de tarefas simultâneas podem incluir guias abertas em um app para navegadores da Web, documentos em um app de produtividade, partidas simultâneas em um jogo ou bate-papos em um app de mensagens. O app pode gerenciar tarefas por meio da classe {@link android.app.ActivityManager.AppTask}.
Para inserir uma interrupção lógica para que o sistema trate suas atividades como uma nova tarefa, use {@link android.content.Intent#FLAG_ACTIVITY_NEW_DOCUMENT} ao iniciar a atividade com {@link android.app.Activity#startActivity(android.content.Intent) startActivity()}. Também é possível ter esse comportamento definindo o atributo do elemento <activity>{@code documentLaunchMode} como {@code "intoExisting"} ou {@code "always"} no seu manifesto.
Para evitar que a tela de recentes fique bagunçada, defina o número máximo de tarefas do seu app que podem aparecer na tela. Para fazer isso, defina o atributo <application> {@link android.R.attr#maxRecents android:maxRecents}. O máximo que pode ser especificado atualmente é 50 tarefas por usuário (25 para dispositivos com pouca RAM).
As tarefas na tela de recentes podem ser definidas para persistirem em reinicializações. Para controlar o comportamento de persistência, use o atributo android:persistableMode. Também é possível alterar as propriedades visuais de uma atividade na tela de recentes, como o rótulo, o ícone e a cor da atividade, chamando o método {@link android.app.Activity#setTaskDescription(android.app.ActivityManager.TaskDescription) setTaskDescription()}.
O Android 5.0 atualiza a implementação de {@link android.webkit.WebView} para o Chromium M37, com aprimoramentos de segurança e estabilidade, bem como correções de bugs. A string de user-agent padrão para um {@link android.webkit.WebView} executando no Android 5.0 foi atualizada para incorporar 37.0.0.0 como o número de versão.
Essa versão apresenta a classe {@link android.webkit.PermissionRequest}, que permite ao seu app conceder a {@link android.webkit.WebView} permissão para acessar recursos protegidos, como a câmera e o microfone, por meio de APIs da Web, como getUserMedia(). Seu app precisa ter as permissões de Android apropriadas para esses recursos a fim de conceder as permissões para {@link android.webkit.WebView}.
Com o novo método onShowFileChooser(), é possível usar um campo de formulário de entrada em {@link android.webkit.WebView} e iniciar um seletor de arquivos para selecionar imagens e arquivos do dispositivo Android.
Além disso, essa versão oferece suporte aos padrões abertos de WebAudio, WebGL e WebRTC. Para saber mais sobre os novos recursos incluídos nessa versão, consulte WebView para Android.
O Android 5.0 permite adicionar as funcionalidades de compartilhamento e captura de tela ao seu app com as novas APIs de {@link android.media.projection}. Essa funcionalidade é útil, por exemplo, se você desejar ativar o compartilhamento de tela em um app de conferência de vídeo.
O novo método {@link android.media.projection.MediaProjection#createVirtualDisplay(java.lang.String, int, int, int, int, android.view.Surface, android.hardware.display.VirtualDisplay.Callback, android.os.Handler) createVirtualDisplay()} permite ao seu app capturar o conteúdo da tela principal (a exibição padrão) em um objeto {@link android.view.Surface}, que seu app pode enviar pela rede. A API permite capturar o conteúdo somente de telas não protegidas, e não captura áudio do sistema. Para começar a captura de tela, o app precisa solicitar a permissão do usuário iniciando uma caixa de diálogo de captura de tela usando um {@link android.content.Intent} obtido por meio do método {@link android.media.projection.MediaProjectionManager#createScreenCaptureIntent()}.
Para ver um exemplo de como usar as novas APIs, consulte a classe {@code MediaProjectionDemo} no projeto de amostra.
As telas de bloqueio no Android 5.0 têm a capacidade de mostrar as notificações. Os usuários podem optar por meio das Configurações para permitir que conteúdo de notificação confidencial seja exibido em uma tela de bloqueio protegida.
O app pode controlar o nível de detalhe visível quando as notificações são exibidas na tela de bloqueio segura. Para controlar o nível de visibilidade, chame {@link android.app.Notification.Builder#setVisibility(int) setVisibility()} e especifique um dos seguintes valores:
Quando o nível de visibilidade é {@link android.app.Notification#VISIBILITY_PRIVATE VISIBILITY_PRIVATE}, é possível fornecer uma versão redigida do conteúdo da notificação que oculta detalhes pessoais. Por exemplo, um app de mensagens SMS pode exibir uma notificação que mostra "Você tem três novas mensagens de texto", mas oculta o conteúdo da mensagem e os remetentes. Para fornecer essa notificação alternativa, crie primeiro a notificação de substituição usando {@link android.app.Notification.Builder}. Quando você criar o objeto de notificação privada, anexe a notificação de substituição a ele por meio do método {@link android.app.Notification.Builder#setPublicVersion(android.app.Notification) setPublicVersion()}.
O Android 5.0 usa os metadados associados com as notificações do seu app para classificá-las de modo mais inteligente. Para definir os metadados, chame os métodos a seguir em {@link android.app.Notification.Builder} ao criar a notificação:
O Android 5.0 adiciona o suporte nativo ao OpenGL ES 3.1 e interfaces Java. As novas e importantes funcionalidades fornecidas no OpenGL ES 3.1 incluem:
A interface Java para o OpenGL ES 3.1 no Android é fornecida com {@link android.opengl.GLES31}. Ao usar o OpenGL ES 3.1, declare isso em seu arquivo de manifesto junto com a tag {@code
<manifest>
<uses-feature android:glEsVersion="0x00030001" />
...
</manifest>
Para mais informações sobre como usar o OpenGL ES, inclusive como verificar a versão do OpenGL ES compatível do dispositivo no tempo de execução, consulte o Guia da OpenGL ES API.
Além do OpenGL ES 3.1, essa versão fornece um pacote de extensões com interfaces Java e suporte nativo para a funcionalidade de gráfico avançado. Essas extensões são tratadas como um único pacote pelo Android. Se a extensão {@code ANDROID_extension_pack_es31a} estiver presente, seu app poderá presumir que todas as extensões no pacote estão presentes e ativar os recursos de linguagem de sombreamento com uma única instrução {@code #extension}.
O pacote de extensões oferece suporte a:
A interface Java para o pacote de extensões é fornecido com {@link android.opengl.GLES31Ext}. No manifesto do app, é possível declarar que o app precisa ser instalado somente em dispositivos que oferecem suporte ao pacote de extensões. Por exemplo:
<manifest>
<uses-feature android:name=“android.hardware.opengles.aep”
android:required="true" />
...
</manifest>
O Android 5.0 apresenta a nova android.hardware.camera2 API para facilitar o processamento de imagens e a captura de fotos com granulação baixa. Agora é possível acessar de maneira programática os dispositivos da câmera disponíveis para o sistema com {@link android.hardware.camera2.CameraManager#getCameraIdList() getCameraIdList()} e conectar um determinado dispositivo com {@link android.hardware.camera2.CameraManager#openCamera(java.lang.String, android.hardware.camera2.CameraDevice.StateCallback, android.os.Handler) openCamera()}. Para começar a capturar imagens, crie um {@link android.hardware.camera2.CameraCaptureSession} e especifique os objetos {@link android.view.Surface} para enviar imagens capturadas. O {@link android.hardware.camera2.CameraCaptureSession} pode ser configurado para tirar uma única foto ou várias imagens em uma sequência.
Para ser notificado quando novas imagens são capturadas, implemente o listener {@link android.hardware.camera2.CameraCaptureSession.CaptureCallback} e defina-o na solicitação de captura. Agora quando o sistema conclui a solicitação de captura de imagem, seu listener {@link android.hardware.camera2.CameraCaptureSession.CaptureCallback} recebe uma chamada a {@link android.hardware.camera2.CameraCaptureSession.CaptureCallback#onCaptureCompleted(android.hardware.camera2.CameraCaptureSession, android.hardware.camera2.CaptureRequest, android.hardware.camera2.TotalCaptureResult) onCaptureCompleted()}, fornecendo a você os metadados da captura de imagem em um {@link android.hardware.camera2.CaptureResult}.
A classe {@link android.hardware.camera2.CameraCharacteristics} permite que seu app detecte quais recursos de câmera estão disponíveis em um dispositivo. A propriedade {@link android.hardware.camera2.CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL INFO_SUPPORTED_HARDWARE_LEVEL} do objeto representa o nível de funcionalidade da câmera.
Para ver como usar a Camera API atualizada, consulte as amostras de implementação de {@code Camera2Basic} e {@code Camera2Video} nessa versão.
Essa versão inclui as seguintes alterações em {@link android.media.AudioTrack}:
Use a nova notificação e APIs de mídia para garantir que a interface do usuário do sistema saiba da sua reprodução de mídia e possa extrair e mostrar a capa do álbum. Controlar a reprodução de mídia em uma interface do usuário agora é mais fácil com as novas classes {@link android.media.session.MediaSession} e {@link android.media.session.MediaController}.
A nova classe {@link android.media.session.MediaSession} substitui a classe {@link android.media.RemoteControlClient} que teve seu uso suspenso e fornece um único conjunto de métodos de chamada de retorno para gerenciar os controles de transporte e os botões de mídia. Se o app fornecer a reprodução de mídia e for executado na plataforma Android TV ou Android Wear, use a classe {@link android.media.session.MediaSession} para lidar com os controles de transporte usando os mesmos métodos de chamada de retorno.
É possível criar seu próprio app controlador de mídia com a nova classe {@link android.media.session.MediaController}. Essa classe oferece uma maneira de thread seguro para monitorar e controlar a reprodução de mídia do processo de interface do seu app. Ao criar um controlador, especifique um objeto {@link android.media.session.MediaSession.Token} para que seu app possa interagir com o {@link android.media.session.MediaSession} determinado. Usando os métodos {@link android.media.session.MediaController.TransportControls}, é possível enviar comandos como {@link android.media.session.MediaController.TransportControls#play() play()}, {@link android.media.session.MediaController.TransportControls#stop() stop()}, {@link android.media.session.MediaController.TransportControls#skipToNext() skipToNext()} e {@link android.media.session.MediaController.TransportControls#setRating(android.media.Rating) setRating()} para controlar a reprodução de mídia nessa sessão. Com o controlador, também é possível registrar um objeto {@link android.media.session.MediaController.Callback} para escutar os metadados e mudanças de estado da sessão.
Além disso, é possível criar notificações ricas que permitem o controle de reprodução ligado a uma sessão de mídia com a nova classe {@link android.app.Notification.MediaStyle}.
O Android 5.0 apresenta a capacidade dos apps de procurar a biblioteca de conteúdo de mídia de outro app por meio da nova android.media.browse API. Para expor o conteúdo de mídia no seu app, estenda a classe {@link android.service.media.MediaBrowserService}. Sua implementação de {@link android.service.media.MediaBrowserService} deve fornecer acesso a um {@link android.media.session.MediaSession.Token} para que apps possam reproduzir conteúdo de mídia fornecido por meio do seu serviço.
Para interagir com o serviço de navegador de mídia, use a classe {@link android.media.browse.MediaBrowser}. Especifique o nome do componente para um {@link android.media.session.MediaSession} ao criar uma instância {@link android.media.browse.MediaBrowser}. Usando essa instância do navegador, seu app pode se conectar ao serviço associado e obter um objeto {@link android.media.session.MediaSession.Token} para reproduzir conteúdo exposto por meio do serviço.
O Android 5.0 estende a Estrutura de acesso ao armazenamento para permitir que os usuários selecionem uma subárvore inteira de diretório, fornecendo aos apps o acesso de leitura/gravação a todos os documentos existentes sem exigir confirmação do usuário para cada item.
Para selecionar uma subárvore de diretório, crie e envie um propósito {@link android.content.Intent#ACTION_OPEN_DOCUMENT_TREE OPEN_DOCUMENT_TREE}. O sistema exibe todas as instâncias {@link android.provider.DocumentsProvider} que oferecem suporte à seleção de subárvore, permitindo que o usuário procure e selecione um diretório. O URI retornado representa o acesso à subárvore selecionada. É possível usar {@link android.provider.DocumentsContract#buildChildDocumentsUriUsingTree(android.net.Uri, java.lang.String) buildChildDocumentsUriUsingTree()} e {@link android.provider.DocumentsContract#buildDocumentUriUsingTree(android.net.Uri, java.lang.String) buildDocumentUriUsingTree()} juntamente com {@link android.content.ContentResolver#query(android.net.Uri, java.lang.String[], java.lang.String, java.lang.String[], java.lang.String) query()} para explorar a subárvore.
O novo método {@link android.provider.DocumentsContract#createDocument(android.content.ContentResolver, android.net.Uri, java.lang.String, java.lang.String) createDocument()} permite criar novos documentos ou diretórios em qualquer lugar abaixo da subárvore. Para gerenciar documentos existentes, use {@link android.provider.DocumentsContract#renameDocument(android.content.ContentResolver, android.net.Uri, java.lang.String) renameDocument()} e {@link android.provider.DocumentsProvider#deleteDocument(java.lang.String) deleteDocument()}. Confira o {@link android.provider.DocumentsContract.Document#COLUMN_FLAGS COLUMN_FLAGS} para verificar o suporte do provedor para essas chamadas antes de emiti-las.
Se você estiver implementando um {@link android.provider.DocumentsProvider} e desejar oferecer suporte à seleção de subárvore, implemente {@link android.provider.DocumentsProvider#isChildDocument(java.lang.String, java.lang.String) isChildDocument()} e inclua {@link android.provider.DocumentsContract.Root#FLAG_SUPPORTS_IS_CHILD FLAG_SUPPORTS_IS_CHILD} em {@link android.provider.DocumentsContract.Root#COLUMN_FLAGS COLUMN_FLAGS}.
O Android 5.0 também apresenta novos diretórios específicos ao pacote no armazenamento compartilhado no qual o app pode colocar arquivos de mídia para inclusão em {@link android.provider.MediaStore}. O novo {@link android.content.Context#getExternalMediaDirs()} retorna caminhos para esses diretórios em todos os dispositivos de armazenamento compartilhado. De forma semelhante a {@link android.content.Context#getExternalFilesDir(java.lang.String) getExternalFilesDir()}, permissões adicionais não são necessárias para que o app acesse os caminhos retornados. A plataforma periodicamente verifica novas mídias nesses diretórios, mas também é possível usar o {@link android.media.MediaScannerConnection} para verificar explicitamente se há novo conteúdo.
O Android 5.0 apresenta novas APIs de várias redes que permitem ao seu app verificar dinamicamente as redes disponíveis com recursos específicos, além de estabelecer uma conexão com eles. Essa funcionalidade é útil quando seu app exigir uma rede especializada, como SUPL, MMS ou uma rede de faturamento via operadora. Outro caso de uso é se você desejar enviar os dados usando um determinado tipo de protocolo de transporte.
Para selecionar e se conectar a uma rede dinamicamente a partir do seu app, siga estas etapas:
Quando o sistema detectar uma rede adequada, ele se conectará à rede e chamará a chamada de retorno {@link android.net.ConnectivityManager.NetworkCallback#onAvailable(android.net.Network) onAvailable()}. É possível usar o objeto {@link android.net.Network} da chamada de retorno a fim de receber mais informações sobre a rede ou direcionar o tráfego para que a rede selecionada seja usada.
O Android 4.3 apresentou o suporte de plataforma para o Bluetooth Low Energy(Bluetooth LE) na função central. No Android 5.0, um dispositivo Android agora pode agir como um dispositivo periférico de Bluetooth LE. Os apps podem usar esse recurso para fazer com que sua presença seja percebida pelos dispositivos vizinhos. É possível, por exemplo, criar apps que permitem que um dispositivo funcione como um pedômetro ou um monitor de integridade de dados e envie seus dados para outro dispositivo Bluetooth LE.
As novas APIs de {@link android.bluetooth.le} permitem que seus apps divulguem anúncios, verifiquem respostas e formem conexões com dispositivos Bluetooth LE vizinhos. Para usar os novos recursos de publicidade e varredura, adicione a permissão {@link android.Manifest.permission#BLUETOOTH_ADMIN BLUETOOTH_ADMIN} no manifesto. Quando os usuários atualizam ou fazem o download do seu app a partir da Play Store, eles são solicitados a conceder a seguinte permissão para seu app: "Informações da conexão Bluetooth: permite que o app controle o Bluetooth, incluindo a divulgação para dispositivos Bluetooth vizinhos ou a busca de informações sobre esses dispositivos."
Para começar a publicidade de Bluetooth LE para que outros dispositivos possam descobrir seu app, chame {@link android.bluetooth.le.BluetoothLeAdvertiser#startAdvertising(android.bluetooth.le.AdvertiseSettings, android.bluetooth.le.AdvertiseData, android.bluetooth.le.AdvertiseCallback) startAdvertising()} e passe uma implementação da classe {@link android.bluetooth.le.AdvertiseCallback}. O objeto de chamada de retorno recebe um relatório do sucesso ou da falha da operação de publicidade.
O Android 5.0 apresenta a classe {@link android.bluetooth.le.ScanFilter} para que seu app possa buscar somente os tipos específicos de dispositivos nos quais está interessado. Para iniciar a busca de dispositivos Bluetooth LE, chame {@link android.bluetooth.le.BluetoothLeScanner#startScan(android.bluetooth.le.ScanCallback) startScan()} e passe uma lista de filtros. Na chamada de método, você precisa fornecer também uma implementação de {@link android.bluetooth.le.ScanCallback} para informar quando uma publicidade de Bluetooth LE for encontrada.
O Android 5.0 adiciona estas melhorias para permitir um uso mais amplo e flexível da NFC:
registerAidsForService(). Também é possível usar {@link android.nfc.cardemulation.CardEmulation#setPreferredService(android.app.Activity, android.content.ComponentName) setPreferredService()} para definir o serviço de emulação de cartão preferencial que deve ser usado quando uma atividade específica estiver em primeiro plano.Além de novos recursos, o Android 5.0 enfatiza melhorias na vida útil da bateria. Use as novas APIs e a ferramenta para compreender e otimizar o consumo de energia de seu app.
O Android 5.0 apresenta uma nova {@link android.app.job.JobScheduler} API que permite otimizar a vida útil da bateria definindo as tarefas para que o sistema execute de maneira assíncrona em um momento posterior ou sob condições especificadas (como quando o dispositivo está carregando). O agendamento de tarefa é útil em situações como:
Uma unidade de trabalho está encapsulada por um objeto {@link android.app.job.JobInfo}. Esse objeto especifica os critérios de agendamento.
Use a classe {@link android.app.job.JobInfo.Builder} para configurar como a tarefa agendada deve ser executada. É possível agendar a tarefa para ser executada em condições específicas, como:
Por exemplo, é possível adicionar código como este para executar a tarefa em uma rede não medida:
JobInfo uploadTask = new JobInfo.Builder(mJobId,
mServiceComponent /* JobService component */)
.setRequiredNetworkCapabilities(JobInfo.NetworkType.UNMETERED)
.build();
JobScheduler jobScheduler =
(JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);
jobScheduler.schedule(uploadTask);
Se o dispositivo tiver energia estável (ou seja, se ele estiver conectado por mais de dois minutos e a bateria estiver em um nível de integridade), o sistema executará a tarefa agendada que estiver pronta para execução, mesmo se o prazo dela não tiver expirado.
Para ver um exemplo de como usar a {@link android.app.job.JobScheduler}API, consulte a amostra de implementação de {@code JobSchedulerSample} nesta versão.
O novo comando {@code dumpsys batterystats} gera dados estatísticos interessantes sobre o uso da bateria em um dispositivo, organizados pelo código único do usuário (UID, na sigla em inglês). As estatísticas incluem:
Use a opção {@code --help} para saber mais sobre as diversas opções para adequar a saída. Por exemplo, para imprimir estatísticas de uso da bateria de um determinado pacote de apps desde que o dispositivo foi carregado pela última vez, execute este comando:
$ adb shell dumpsys batterystats --charged <package-name>
É possível usar a ferramenta Battery Historian na saída do comando {@code dumpsys} para gerar uma visualização de HTML de eventos relacionados à energia dos registros. Essa informação facilita para você entender e diagnosticar problemas relacionados à bateria.
O Android 5.0 apresenta a nova funcionalidade para a execução de apps em um ambiente corporativo. Um administrador de dispositivo pode iniciar um processo de provisionamento gerenciado para adicionar um perfil gerenciado copresente, mas separado, a um dispositivo se o usuário tiver uma conta pessoal existente. Os apps que estão associados aos perfis gerenciados são exibidos junto a apps não gerenciados no inicializador do usuário, na tela de recentes e nas notificações.
Para iniciar o processo de provisionamento gerenciado, envie {@link android.app.admin.DevicePolicyManager#ACTION_PROVISION_MANAGED_PROFILE ACTION_PROVISION_MANAGED_PROFILE} em um {@link android.content.Intent}. Se a chamada ocorrer, o sistema acionará a chamada de retorno {@link android.app.admin.DeviceAdminReceiver#onProfileProvisioningComplete(android.content.Context, android.content.Intent) onProfileProvisioningComplete()}. Será possível então chamar {@link android.app.admin.DevicePolicyManager#setProfileEnabled(android.content.ComponentName) setProfileEnabled()} para ativar esse perfil gerenciado.
Por padrão, somente um pequeno subconjunto de apps são ativados no perfil gerenciado. É possível instalar mais apps no perfil gerenciado chamando {@link android.app.admin.DevicePolicyManager#enableSystemApp(android.content.ComponentName, android.content.Intent) enableSystemApp()}.
Se você estiver desenvolvendo um app inicializador, será possível usar a nova classe {@link android.content.pm.LauncherApps} para ter uma lista das atividades inicializáveis do usuário atual e de quaisquer perfis gerenciados associados. O inicializador pode destacar visualmente os apps gerenciados acrescentando um selo de trabalho ao drawable do ícone. Para recuperar o ícone com selo, chame {@link android.content.pm.PackageManager#getUserBadgedIcon(android.graphics.drawable.Drawable, android.os.UserHandle) getUserBadgedIcon()}.
Para saber como usar a nova funcionalidade, consulte a amostra de implementação de {@code BasicManagedProfile} nesta versão.
O Android 5.0 apresenta a capacidade de implantar um app do proprietário do dispositivo. O proprietário do dispositivo é um tipo especializado de administrador de dispositivo que tem a capacidade adicional de criar e remover usuários secundários, bem como definir configurações globais no dispositivo. Seu app de proprietário do dispositivo pode usar os métodos na classe {@link android.app.admin.DevicePolicyManager} para tirar o controle de granulação da configuração, da segurança e dos apps em dispositivos gerenciados. Um dispositivo pode ter somente um proprietário ativo de cada vez.
Para implantar e ativar um proprietário do dispositivo, você precisa realizar uma transferência de dados de NFC de um app de programação para o dispositivo enquanto o dispositivo estiver em seu estado não provisionado. Essa transferência de dados envia as mesmas informações presentes no propósito de provisionamento descrito no Provisionamento gerenciado.
O Android 5.0 apresenta uma nova API de fixação de tela que permite restringir temporariamente a saída dos usuários de sua tarefa ou que eles sejam interrompidos por notificações. Isso pode ser usado, por exemplo, se você desenvolve um app educacional compatível com requisitos de avaliação de alto risco no Android ou em um app de quiosque com um único objetivo. Depois que o app ativar a fixação de tela, os usuários não podem ver as notificações, acessar outros apps ou retornar para a tela inicial do app até saírem do modo.
Existem duas maneiras de ativar a fixação de tela:
Quando o bloqueio de tarefa estiver ativo, o seguinte comportamento ocorre:
Agora é possível processar páginas de documentos PDF para imagens de bitmap e imprimi-las usando a nova classe {@link android.graphics.pdf.PdfRenderer}. Você deve especificar um {@link android.os.ParcelFileDescriptor} que seja buscável (isto é, o conteúdo poderá ser acessado aleatoriamente) e no qual o sistema registre o conteúdo imprimível. O app pode obter uma página para processar com {@link android.graphics.pdf.PdfRenderer#openPage(int) openPage()} e depois chamar {@link android.graphics.pdf.PdfRenderer.Page#render(android.graphics.Bitmap, android.graphics.Rect, android.graphics.Matrix, int) render()} para desativar o {@link android.graphics.pdf.PdfRenderer.Page} aberto em um bitmap. Também é possível definir parâmetros adicionais se você somente deseja converter uma parte do documento em uma imagem de bitmap (por exemplo, para implementar uma renderização de bloco para zoom no documento).
Para obter um exemplo de como usar as novas APIs, consulte o exemplo {@code PdfRendererBasic}.
Agora é possível acessar o histórico de utilização em um dispositivo Android com a nova {@link android.app.usage} API. Essa API fornece informações mais detalhadas sobre o uso do método suspenso {@link android.app.ActivityManager#getRecentTasks(int, int) getRecentTasks()}. Para usar essa API, primeiro é preciso declarar a permissão {@code "android.permission.PACKAGE_USAGE_STATS"} em seu manifesto. O usuário também deve permitir o acesso do app por meio de Configurações > Segurança > Apps com acesso de uso.
O sistema coleta os dados de uso por apps, agregando os dados em intervalos diários, semanais, mensais e anuais. A duração máxima pela qual o sistema mantém esses dados é:
Para cada app, o sistema registra os seguintes dados:
O Android 5.0 adiciona o seguinte suporte a testes e acessibilidade:
A partir do Android 5.0, os usuários podem facilmente alternar entre todos os editores de método de entrada (IME) compatíveis com a plataforma. Executar a ação de comutação designada (normalmente tocando o ícone de globo no teclado virtual) percorre todos os IMEs. Essa mudança de comportamento foi implementada pelo método {@link android.view.inputmethod.InputMethodManager#shouldOfferSwitchingToNextInputMethod(android.os.IBinder) shouldOfferSwitchingToNextInputMethod()}.
Além disso, o framework agora verifica se o próximo IME inclui um mecanismo de alternação (e, portanto, se o IME é compatível com a alternação posterior ao IME). Um IME com mecanismo de alternação não passará a outro IME sem esse mecanismo. Essa mudança de comportamento foi implementada pelo método {@link android.view.inputmethod.InputMethodManager#switchToNextInputMethod(android.os.IBinder, boolean) switchToNextInputMethod()}.
Para saber um exemplo de como usar as APIs de alternação de IME atualizadas, consulte o exemplo atualizado de implementação de teclado virtual nesta versão. Para saber mais sobre como implementar a troca entre IMEs, consulte Criação de um método de entrada.
Os seguintes valores agora são compatíveis no elemento {@code
A seguinte permissão agora é compatível com o elemento {@code