APIs do Android 3.1

Nível da API: 12

Para desenvolvedores, a plataforma Android 3.1 (HONEYCOMB_MR1) está disponível como um componente para download do SDK do Android. A plataforma para download inclui uma biblioteca do Android e uma imagem do sistema, além de um conjunto de aparências do emulador e muito mais. A plataforma para download não inclui bibliotecas externas.

Para desenvolvedores, a plataforma Android 3.1 está disponível como um componente para download do SDK do Android. A plataforma para download inclui uma biblioteca do Android e uma imagem do sistema, além de um conjunto de aparências do emulador e muito mais. Para começar a desenvolver ou testar no Android 3.1, use o Android SDK Manager para fazer o download da plataforma no SDK.

Visão geral da API

As seções abaixo fornecem uma visão geral técnica das novidades para desenvolvedores no Android 3.1, incluindo novos recursos e mudanças na API de framework desde a versão anterior.

APIs USB

O Android 3.1 apresenta novas APIs avançadas para integrar periféricos conectados a aplicativos em execução na plataforma. As APIs são baseadas em uma pilha de USB (Universal Serial Bus) e em serviços incorporados à plataforma, incluindo suporte para interações de host e dispositivo USB. Usando as APIs, os desenvolvedores podem criar aplicativos capazes de descobrir, se comunicar e gerenciar uma variedade de tipos de dispositivos conectados por USB.

A pilha e as APIs distinguem dois tipos básicos de hardware USB, com base em se o dispositivo Android está atuando como host ou se o hardware externo está atuando como host:

  • Um dispositivo USB é um hardware conectado que depende do dispositivo Android para servir como host. Por exemplo, a maioria dos dispositivos de entrada, mouses e joysticks são dispositivos USB, assim como muitas câmeras, hubs etc.
  • Um acessório USB é um hardware conectado que tem um controlador host USB, fornece energia e foi projetado para se comunicar com dispositivos Android por USB. Vários periféricos podem ser conectados como acessórios, de controladores de robótica a equipamentos musicais, bicicletas ergométricas e muito mais.

Para os dois tipos, dispositivos USB e acessórios USB, as APIs USB da plataforma oferecem suporte à descoberta por transmissão de intent quando conectados ou desconectados, bem como interfaces, endpoints e modos de transferência padrão (controle, em massa e interrupção).

As APIs USB estão disponíveis no pacote android.hardware.usb. A classe central é UsbManager, que fornece métodos auxiliares para identificar e se comunicar com dispositivos e acessórios USB. Os aplicativos podem adquirir uma instância de UsbManager e, em seguida, consultar a lista de dispositivos ou acessórios conectados e se comunicar com eles ou gerenciá-los. UsbManager também declara ações de intent que o sistema transmite para anunciar quando um dispositivo ou acessório USB é conectado ou desconectado.

Outras classes incluem:

  • UsbDevice, uma classe que representa um hardware externo conectado como um dispositivo USB (com o dispositivo Android atuando como host).
  • UsbAccessory, que representa o hardware externo conectado como o host USB (com o dispositivo Android atuando como um dispositivo USB).
  • UsbInterface e UsbEndpoint, que dão acesso a interfaces e endpoints USB padrão para um dispositivo.
  • UsbDeviceConnection e UsbRequest, para enviar e receber dados e mensagens de controle para ou de um dispositivo USB, de forma síncrona e assíncrona.
  • UsbConstants, que fornece constantes para declarar tipos de endpoint, classes de dispositivos etc.

Embora a pilha USB seja integrada à plataforma, o suporte real para os modos de host USB e acessório aberto em dispositivos específicos é determinado pelos fabricantes. Em particular, o modo host depende do hardware do controlador USB adequado no dispositivo Android.

Além disso, os desenvolvedores podem solicitar a filtragem no Google Play para que os aplicativos não fiquem disponíveis para usuários com dispositivos que não oferecem o suporte USB adequado. Para solicitar a filtragem, adicione um ou os dois elementos abaixo ao manifesto do aplicativo, conforme apropriado:

  • Se o aplicativo só deve ficar visível para dispositivos que oferecem suporte ao modo host USB (conexão de dispositivos USB), declare este elemento:

    <uses-feature android:name="android.hardware.usb.host" android:required="true">

  • Se o aplicativo precisar ficar visível apenas para dispositivos que oferecem suporte a acessórios USB (conexão de hosts USB), declare este elemento:

    <uses-feature android:name="android.hardware.usb.accessory" android:required="true">

Para informações completas sobre como desenvolver aplicativos que interagem com acessórios USB, consulte a documentação para desenvolvedores.

Para conferir exemplos de aplicativos que usam a API de host USB, consulte Teste do ADB e Missile Launcher.

API MTP/PTP

O Android 3.1 expõe uma nova API MTP que permite que os aplicativos interajam diretamente com câmeras conectadas e outros dispositivos PTP. A nova API facilita para um aplicativo receber notificações quando dispositivos são conectados e removidos, gerenciar arquivos e armazenamento nesses dispositivos e transferir arquivos e metadados para e deles. A API MTP implementa o subconjunto PTP (Picture Transfer Protocol) da especificação MTP (Media Transfer Protocol).

A API MTP está disponível no pacote android.mtp e oferece estas classes:

  • O MtpDevice encapsula um dispositivo MTP conectado pelo barramento do host USB. Um aplicativo pode instanciar um objeto desse tipo e usar os métodos dele para receber informações sobre o dispositivo e os objetos armazenados nele, além de abrir a conexão e transferir dados. Estes são alguns dos métodos:
    • getObjectHandles() retorna uma lista de identificadores para todos os objetos no dispositivo que correspondem a um formato e pai especificados. Para receber informações sobre um objeto, um aplicativo pode transmitir um identificador para getObjectInfo().
    • importFile() permite que um aplicativo copie dados de um objeto para um arquivo no armazenamento externo. Essa chamada pode ser bloqueada por um período arbitrário, dependendo do tamanho dos dados e da velocidade dos dispositivos. Por isso, ela precisa ser feita em uma linha de execução separada.
    • open() permite que um aplicativo abra um dispositivo MTP/PTP conectado.
    • getThumbnail() retorna a miniatura do objeto como uma matriz de bytes.
  • MtpStorageInfo contém informações sobre uma unidade de armazenamento em um dispositivo MTP, correspondente ao conjunto de dados StorageInfo descrito na seção 5.2.2 da especificação MTP. Os métodos na classe permitem que um aplicativo receba a string de descrição, o espaço livre, a capacidade máxima de armazenamento, o ID de armazenamento e o identificador de volume de uma unidade de armazenamento.
  • MtpDeviceInfo contém informações sobre um dispositivo MTP correspondente ao conjunto de dados DeviceInfo descrito na seção 5.1.1 da especificação MTP. Os métodos na classe permitem que os aplicativos recebam o fabricante, o modelo, o número de série e a versão de um dispositivo.
  • MtpObjectInfo contém informações sobre um objeto armazenado em um dispositivo MTP, correspondente ao conjunto de dados ObjectInfo descrito na seção 5.3.1 da especificação do MTP. Os métodos na classe permitem que os aplicativos recebam o tamanho, o formato de dados, o tipo de associação, a data de criação e as informações de miniatura de um objeto.
  • MtpConstants fornece constantes para declarar códigos de formato de arquivo MTP, tipo de associação e status de proteção.

Suporte para novos dispositivos de entrada e eventos de movimento

O Android 3.1 estende o subsistema de entrada para oferecer suporte a novos dispositivos de entrada e novos tipos de eventos de movimento em todas as visualizações e janelas. Os desenvolvedores podem usar esses recursos para permitir que os usuários interajam com os aplicativos usando mouses, trackballs, joysticks, gamepads e outros dispositivos, além de teclados e telas touchscreen.

Para processar entradas de mouse, roda de rolagem e trackball, a plataforma oferece suporte a duas novas ações de evento de movimento:

  • ACTION_SCROLL, que descreve o local do ponteiro em que ocorreu um movimento de rolagem sem toque, como o de uma roda de rolagem do mouse. No MotionEvent, o valor dos eixos AXIS_HSCROLL e AXIS_VSCROLL especifica o movimento de rolagem relativo.
  • ACTION_HOVER_MOVE, informa a posição atual do mouse quando nenhum botão é pressionado, bem como quaisquer pontos intermediários desde o último evento HOVER_MOVE. As notificações de entrada e saída ao passar o cursor ainda não são compatíveis.

Para oferecer suporte a joysticks e gamepads, a classe InputDevice inclui estas novas origens de dispositivos de entrada:

Para descrever eventos de movimento dessas novas fontes, bem como de mouses e trackballs, a plataforma agora define códigos de eixo em MotionEvent, de maneira semelhante à definição de códigos de tecla em KeyEvent. Os novos códigos de eixo para joysticks e controles de jogo incluem AXIS_HAT_X, AXIS_HAT_Y, AXIS_RTRIGGER, AXIS_ORIENTATION, AXIS_THROTTLE e muitos outros. Os eixos MotionEvent atuais são representados por AXIS_X, AXIS_Y, AXIS_PRESSURE, AXIS_SIZE, AXIS_TOUCH_MAJOR, AXIS_TOUCH_MINOR, AXIS_TOOL_MAJOR, AXIS_TOOL_MINOR e AXIS_ORIENTATION.

Além disso, MotionEvent define vários códigos de eixo genéricos que são usados quando o framework não sabe como mapear um eixo específico. Dispositivos específicos podem usar os códigos de eixo genéricos para transmitir dados de movimento personalizados para aplicativos. Para ver uma lista completa de eixos e as interpretações pretendidas, consulte a documentação da classe MotionEvent.

A plataforma fornece eventos de movimento para aplicativos em lotes, de modo que um único evento pode conter uma posição atual e vários movimentos históricos. Os aplicativos precisam usar getHistorySize() para receber o número de amostras históricas e, em seguida, recuperar e processar todas as amostras históricas em ordem usando getHistoricalAxisValue(). Depois disso, os aplicativos precisam processar a amostra atual usando getAxisValue().

Alguns eixos podem ser recuperados usando métodos do acessador especiais. Por exemplo, em vez de chamar getAxisValue(), os aplicativos podem chamar getX(). Os eixos que têm acessadores integrados incluem AXIS_X, AXIS_Y, AXIS_PRESSURE, AXIS_SIZE, AXIS_TOUCH_MAJOR, AXIS_TOUCH_MINOR, AXIS_TOOL_MAJOR, AXIS_TOOL_MINOR e AXIS_ORIENTATION.

Cada dispositivo de entrada tem um ID exclusivo atribuído pelo sistema e também pode fornecer várias fontes. Quando um dispositivo fornece várias fontes, mais de uma fonte pode fornecer dados de eixo usando o mesmo eixo. Por exemplo, um evento de toque proveniente da origem de toque usa o eixo X para dados de posição da tela, enquanto um evento de joystick proveniente da origem de joystick usa o eixo X para a posição do controle. Por esse motivo, é importante que os aplicativos interpretem os valores de eixo de acordo com a origem deles. Ao processar um evento de movimento, os aplicativos precisam usar métodos na classe InputDevice para determinar os eixos compatíveis com um dispositivo ou uma fonte. Especificamente, os aplicativos podem usar getMotionRanges() para consultar todos os eixos de um dispositivo ou todos os eixos de uma determinada origem do dispositivo. Em ambos os casos, as informações de intervalo para eixos retornadas no objeto InputDevice.MotionRange especificam a origem de cada valor de eixo.

Por fim, como os eventos de movimento de joysticks, gamepads, mouses e trackballs não são eventos de toque, a plataforma adiciona um novo método de callback para transmiti-los a uma View como eventos de movimento "genéricos". Especificamente, ele informa os eventos de movimento sem toque para Views por uma chamada para onGenericMotionEvent(), em vez de para onTouchEvent().

A plataforma envia eventos de movimento genéricos de maneira diferente, dependendo da classe de origem do evento. Os eventos SOURCE_CLASS_POINTER vão para o View abaixo do ponteiro, de forma semelhante ao funcionamento dos eventos de toque. Todos os outros vão para o View em foco. Por exemplo, isso significa que uma View precisa estar em foco para receber eventos de joystick. Se necessário, os aplicativos podem processar esses eventos no nível de atividade ou caixa de diálogo implementando onGenericMotionEvent().

Para conferir um exemplo de aplicativo que usa eventos de movimento do joystick, consulte GameControllerInput e GameView.

API RTP

O Android 3.1 expõe uma API à pilha integrada do RTP (Real-time Transport Protocol), que os aplicativos podem usar para gerenciar o streaming de dados interativo ou sob demanda. Em particular, apps que oferecem VOIP, push-to-talk, conferência e streaming de áudio podem usar a API para iniciar sessões e transmitir ou receber streams de dados em qualquer rede disponível.

A API RTP está disponível no pacote android.net.rtp. As aulas incluem:

  • RtpStream, a classe de base de streams que enviam e recebem pacotes de rede com payloads de mídia por RTP.
  • AudioStream, uma subclasse de RtpStream que transporta payloads de áudio por RTP.
  • AudioGroup, um hub de áudio local para gerenciar e misturar o alto-falante, o microfone e o AudioStream do dispositivo.
  • AudioCodec, que contém uma coleção de codecs que você define para um AudioStream.

Para oferecer suporte a audioconferências e usos semelhantes, um aplicativo instancia duas classes como endpoints para o stream:

O uso mais simples envolve um único endpoint remoto e um endpoint local. Para usos mais complexos, consulte as limitações descritas para AudioGroup.

Para usar a API RTP, os aplicativos precisam solicitar permissão ao usuário declarando <uses-permission android:name="android.permission.INTERNET"> nos arquivos de manifesto. Para usar o microfone do dispositivo, a permissão <uses-permission android:name="android.permission.RECORD_AUDIO"> também é necessária.

Widgets de aplicativos redimensionáveis

A partir do Android 3.1, os desenvolvedores podem tornar os widgets da tela inicial redimensionáveis, seja na horizontal, na vertical ou em ambos os eixos. Os usuários tocam e pressionam um widget para mostrar as alças de redimensionamento e, em seguida, arrastam as alças horizontais e/ou verticais para mudar o tamanho no layout de grade.

Os desenvolvedores podem tornar qualquer widget da tela inicial redimensionável definindo um atributo resizeMode nos metadados AppWidgetProviderInfo do widget. Os valores do atributo resizeMode incluem "horizontal", "vertical" e "none". Para declarar um widget como redimensionável horizontal e verticalmente, forneça o valor "horizontal|vertical".

Veja um exemplo: 

<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    android:minWidth="294dp"
    android:minHeight="72dp"
    android:updatePeriodMillis="86400000"
    android:previewImage="@drawable/preview"
    android:initialLayout="@layout/example_appwidget"
    android:configure="com.example.android.ExampleAppWidgetConfigure"
    android:resizeMode="horizontal|vertical" >
</appwidget-provider>

Para mais informações sobre widgets da tela inicial, consulte a documentação de widgets de apps.

Framework de animação

  • Nova classe ViewPropertyAnimator
    • Uma nova classe ViewPropertyAnimator oferece uma maneira conveniente para os desenvolvedores animarem propriedades selecionadas em objetos View. A classe automatiza e otimiza a animação das propriedades e facilita o gerenciamento de várias animações simultâneas em um objeto View.

      Usar o ViewPropertyAnimator é simples. Para animar propriedades de um View, chame animate() para construir um objeto ViewPropertyAnimator para esse View. Use os métodos no ViewPropertyAnimator para especificar qual propriedade animar e como fazer isso. Por exemplo, para esmaecer o View até que ele fique transparente, chame alpha(0);. O objeto ViewPropertyAnimator processa os detalhes de configuração da classe Animator, inicia essa classe e renderiza a animação.

  • Cor de fundo da animação
    • Os novos métodos getBackgroundColor() e setBackgroundColor(int) permitem receber/definir a cor do plano de fundo por trás das animações, apenas para animações de janela. Atualmente, o plano de fundo precisa ser preto, com qualquer nível alfa desejado.
  • Como receber a fração animada de ViewAnimator
    • Um novo método getAnimatedFraction() permite que você receba a fração de animação atual, ou seja, a fração decorrida/interpolada usada na atualização de frame mais recente, de um ValueAnimator.

Framework de interface

  • Renderização forçada de uma camada
    • Um novo método buildLayer() permite que um aplicativo force a criação de uma camada de visualização e a renderização imediata da visualização nela. Por exemplo, um aplicativo pode usar esse método para renderizar uma visualização na camada antes de iniciar uma animação. Se a visualização for complexa, renderizá-la na camada antes de iniciar a animação vai evitar que frames sejam pulados.
  • Distância da câmera
    • Os aplicativos podem usar um novo método setCameraDistance(float) para definir a distância da câmera até uma visualização. Isso dá aos aplicativos um controle melhor sobre as transformações 3D da visualização, como rotações.
  • Como acessar uma visualização de calendário de um DatePicker
  • Receber callbacks quando as visualizações são desanexadas
  • O listener de navegação estrutural do fragmento, nova assinatura onInflate()
  • Mostrar o resultado da pesquisa em uma nova guia
  • Cursor de texto desenhável
    • Agora é possível especificar um drawable para usar como cursor de texto usando o novo atributo de recurso textCursorDrawable.
  • Como definir o filho mostrado em visualizações remotas
  • Teclas genéricas para gamepads e outros dispositivos de entrada
    • O KeyEvent adiciona uma variedade de códigos de tecla genéricos para acomodar os botões do gamepad. A classe também adiciona isGamepadButton(int) e vários outros métodos auxiliares para trabalhar com códigos de tecla.

Gráficos

  • Auxiliares para gerenciar bitmaps
    • setHasAlpha(boolean) permite que um app indique que todos os pixels em um Bitmap são opacos (falso) ou que alguns dos pixels podem conter valores Alfa não opacos (verdadeiro). Em algumas configurações (como RGB_565), essa chamada é ignorada, porque não oferece suporte a valores Alfa por pixel. Isso serve como uma dica de desenho, já que, em alguns casos, um bitmap que é conhecido como opaco pode ter um caso de desenho mais rápido do que um que pode ter valores Alfa não opacos por pixel.
    • getByteCount() recebe o tamanho de um bitmap em bytes.
    • getGenerationId() permite que um aplicativo descubra se um bitmap foi modificado, por exemplo, para armazenamento em cache.
    • sameAs(android.graphics.Bitmap) determina se um determinado Bitmap é diferente do Bitmap atual em termos de dimensão, configuração ou dados de pixel.
  • Como definir o local e a rotação da câmera

Rede

  • Bloqueio de Wi-Fi de alto desempenho
    • Um novo bloqueio de Wi-Fi de alto desempenho permite que os aplicativos mantenham conexões Wi-Fi de alto desempenho mesmo quando a tela do dispositivo está desligada. Os aplicativos que transmitem música, vídeo ou voz por longos períodos podem adquirir o bloqueio de Wi-Fi de alto desempenho para garantir o desempenho do streaming mesmo quando a tela está desligada. Como ele usa mais energia, os aplicativos precisam adquirir o Wi-Fi de alto desempenho quando há necessidade de uma conexão ativa de longa duração.

      Para criar um bloqueio de alto desempenho, transmita WIFI_MODE_FULL_HIGH_PERF como o modo de bloqueio em uma chamada para createWifiLock().

  • Mais estatísticas de tráfego
    • Agora os aplicativos podem acessar estatísticas sobre mais tipos de uso de rede usando novos métodos em TrafficStats. Os aplicativos podem usar os métodos para receber estatísticas de UDP, contagem de pacotes, bytes de payload de transmissão/recebimento de TCP e segmentos para um determinado UID.
  • Nome de usuário de autenticação SIP

Gerenciador de downloads

  • Processamento de downloads concluídos
    • Agora os aplicativos podem iniciar downloads que notificam os usuários apenas quando são concluídos. Para iniciar esse tipo de download, os aplicativos transmitem VISIBILITY_VISIBLE_NOTIFY_ONLY_COMPLETION no método setNotificationVisibility() de um objeto de solicitação.
    • Um novo método, addCompletedDownload(), permite que um aplicativo adicione um arquivo ao banco de dados de downloads para que ele possa ser gerenciado pelo aplicativo Downloads.
  • Mostrar downloads classificados por tamanho

Framework de IME

  • Como receber a chave de valor extra de um método de entrada

Mídia

  • Novos formatos de streaming de áudio
    • O framework de mídia adiciona suporte integrado para conteúdo ADTS AAC bruto, para melhorar o streaming de áudio, além de suporte para áudio FLAC, para conteúdo de áudio compactado de alta qualidade (sem perdas). Consulte o documento Formatos de mídia compatíveis para mais informações.

Controles de inicialização em aplicativos interrompidos

A partir do Android 3.1, o gerenciador de pacotes do sistema monitora os aplicativos que estão em um estado interrompido e fornece um meio de controlar a inicialização deles em processos em segundo plano e outros aplicativos.

O estado interrompido de um aplicativo não é o mesmo que o estado interrompido de uma atividade. O sistema gerencia esses dois estados de parada separadamente.

A plataforma define duas novas flags de intent que permitem que um remetente especifique se a intent pode ativar componentes em um aplicativo interrompido.

Quando nenhuma ou ambas as flags são definidas em uma intent, o comportamento padrão é incluir filtros de aplicativos interrompidos na lista de possíveis destinos.

O sistema adiciona FLAG_EXCLUDE_STOPPED_PACKAGES a todas as intents de transmissão. Isso é feito para evitar que as transmissões de serviços em segundo plano iniciem componentes de aplicativos interrompidos de forma inadvertida ou desnecessária. Um serviço ou aplicativo em segundo plano pode modificar esse comportamento adicionando a flag FLAG_INCLUDE_STOPPED_PACKAGES para transmitir intents que podem ativar aplicativos interrompidos.

Os aplicativos ficam em um estado interrompido quando são instalados, mas ainda não foram iniciados, e quando são interrompidos manualmente pelo usuário (em Gerenciar aplicativos).

Notificação de primeira inicialização e upgrade do aplicativo

A plataforma adiciona uma notificação melhorada da primeira inicialização e dos upgrades do aplicativo por meio de duas novas ações de intent:

  • ACTION_PACKAGE_FIRST_LAUNCH: enviado ao pacote do instalador de um aplicativo quando ele é iniciado pela primeira vez, ou seja, quando ele sai de um estado interrompido. Os dados contêm o nome do pacote.
  • ACTION_MY_PACKAGE_REPLACED: notifica um aplicativo de que ele foi atualizado, com uma nova versão instalada sobre uma versão atual. Isso é enviado apenas para o aplicativo que foi substituído. Ele não contém outros dados. Para recebê-la, declare um filtro de intent para essa ação. Você pode usar a intent para acionar um código que ajuda a colocar o aplicativo de volta em funcionamento após um upgrade.

    Essa intent é enviada diretamente ao aplicativo, mas somente se ele foi atualizado enquanto estava no estado iniciado (não em um estado interrompido).

Utilitários principais

  • Cache LRU
    • Uma nova classe LruCache permite que seus aplicativos se beneficiem do armazenamento em cache eficiente. Os aplicativos podem usar a classe para reduzir o tempo gasto computando ou fazendo o download de dados da rede, mantendo um consumo de memória sensível para os dados armazenados em cache.LruCache é um cache que contém referências fortes a um número limitado de valores. Sempre que um valor é acessado, ele é movido para o início de uma fila. Quando um valor é adicionado a um cache cheio, o valor no final dessa fila é removido e pode se tornar qualificado para coleta de lixo.
  • Descritor do arquivo como int

WebKit

  • Cookies de esquema de arquivo
    • O CookieManager agora aceita cookies que usam o esquema de URI file:. É possível usar setAcceptFileSchemeCookies() para ativar/desativar o suporte a cookies de esquema de arquivo antes de criar uma instância de WebView ou CookieManager. Em uma instância CookieManager, é possível verificar se os cookies de esquema de arquivo estão ativados chamando allowFileSchemeCookies().
  • Notificação de solicitação de login
    • Para oferecer suporte aos recursos de login automático do navegador introduzidos no Android 3.0, o novo método onReceivedLoginRequest() notifica o aplicativo host de que uma solicitação de login automático para o usuário foi processada.
  • Classes e interfaces removidas
    • Várias classes e interfaces foram removidas da API pública, depois de terem sido descontinuadas. Consulte o Relatório de diferenças da API para mais informações.

Navegador

O aplicativo Browser adiciona os seguintes recursos para oferecer suporte a aplicativos da web:

  • Suporte para reprodução inline de vídeo incorporado na tag <video> do HTML5. A reprodução é acelerada por hardware sempre que possível.
  • Suporte de camada para elementos de posição fixa em todos os sites (dispositivos móveis e computadores).

Novas constantes de recursos

A plataforma adiciona novas constantes de recursos de hardware que os desenvolvedores podem declarar nos manifestos do aplicativo para informar a entidades externas, como o Google Play, sobre os requisitos do aplicativo para novos recursos de hardware compatíveis com essa versão da plataforma. Os desenvolvedores declaram essas e outras constantes de recursos nos elementos de manifesto <uses-feature>.

O Google Play filtra aplicativos com base nos recursos declarados nos elementos de manifesto <uses-feature>. Para mais informações sobre como declarar recursos em um manifesto de aplicativo, leia Filtros do Google Play.

Relatório de diferenças da API

Para uma visualização detalhada de todas as mudanças de API no Android 3.1 (nível 12 da API), consulte o Relatório de diferenças da API.

Nível da API

A plataforma Android 3.1 oferece uma versão atualizada da API de framework. A API do Android 3.1 recebe um identificador de número inteiro, 12, que é armazenado no próprio sistema. Esse identificador, chamado de "nível da API", permite que o sistema determine corretamente se um aplicativo é compatível com ele antes de instalá-lo.

Para usar as APIs introduzidas no Android 3.1 no seu aplicativo, é preciso compilar o aplicativo com a biblioteca do Android fornecida na plataforma do SDK do Android 3.1. Dependendo das suas necessidades, talvez você também precise adicionar um atributo android:minSdkVersion="12" ao elemento <uses-sdk> no manifesto do aplicativo.

Para mais informações, leia O que é o nível da API?.