O Bluetooth Low Energy (BLE), disponível no Android 4.3 e posterior, cria conexões curtas entre dispositivos para transferir rajadas de dados. O BLE permanece no modo de suspensão quando não está conectado. Isso permite que o BLE forneça menor largura de banda e consumo de energia reduzido em comparação com o Bluetooth clássico. É ideal para aplicações como monitor de frequência cardíaca ou teclado sem fio. Para usar BLE, os dispositivos precisam ter um chipset compatível com BLE.
Implementação
Todos os perfis de aplicativos BLE atuais são baseados no Generic Attribute Profile (GATT). Quando um dispositivo Android interage com um dispositivo BLE, o dispositivo que envia informações é o servidor e o dispositivo que recebe informações é o cliente. O Android inclui APIs de desenvolvedor para BLE , incluindo APIs para interações entre servidores GATT e clientes GATT. Para aproveitar totalmente as APIs BLE, implemente os Requisitos de HCI do Android Bluetooth .
Modos de dispositivo
Ao usar BLE, um dispositivo Android pode atuar como um dispositivo periférico, um dispositivo central ou ambos. O modo periférico permite que os dispositivos enviem pacotes de anúncios. O modo central permite que os dispositivos procurem anúncios. Um dispositivo Android atuando como dispositivo periférico e central pode se comunicar com outros dispositivos periféricos BLE enquanto envia anúncios no modo periférico. Dispositivos que suportam Bluetooth 4.1 e anteriores só podem usar BLE no modo central. Chipsets de dispositivos mais antigos podem não suportar o modo periférico BLE.
Digitalização BLE
Um dispositivo Android pode direcionar e procurar dispositivos Bluetooth específicos com mais eficiência ao usar BLE. As APIs BLE permitem que os desenvolvedores de aplicativos criem filtros para encontrar dispositivos com menos envolvimento do controlador host.
Verificação de localização
Os serviços de localização de um dispositivo podem usar Bluetooth para detectar beacons Bluetooth e fornecer uma localização mais precisa. É assim que os usuários habilitam o recurso:
- Vá para Configurações > Segurança e localização > Localização .
- Verifique se o botão de ativação / desativação de localização está na posição Ligado .
- Vá para o modo .
- Selecione Alta precisão ou modo de economia de bateria .
No Android 11 ou inferior, aplicativos individuais exigem permissões de localização para usar a verificação BLE, mesmo que estejam verificando apenas para encontrar dispositivos aos quais se conectar. Se o usuário desabilitar a verificação de localização ou não conceder permissões de localização ao aplicativo, o aplicativo não receberá nenhum resultado de verificação BLE.
A partir do Android 12, as permissões BLUETOOTH_SCAN , BLUETOOTH_ADVERTISE e BLUETOOTH_CONNECT podem permitir que os aplicativos procurem dispositivos próximos sem a necessidade de solicitar permissão de localização. Para obter mais informações, consulte Novas permissões de Bluetooth no Android 12 .
Os usuários podem desativar a verificação em segundo plano do Bluetooth no nível do sistema acessando Configurações > Segurança e localização > Localização > Verificação e desativando a alternância para verificação de Bluetooth . Isso não afeta a verificação BLE de localização ou dispositivos locais.
Filtrando resultados da verificação
O Android 6.0 e posterior inclui varredura BLE e correspondência de filtros no controlador Bluetooth. Um dispositivo pode filtrar resultados de varredura e relatar eventos encontrados e perdidos relacionados a dispositivos BLE para o processador de aplicativos (AP). A filtragem também funciona para varreduras em lote, o que ajuda a economizar energia à medida que a varredura BLE é transferida para o firmware. As varreduras em lote reduzem a frequência com que o AP é ativado devido à varredura BLE em busca de dispositivos ou beacons.
O recurso OnFound / OnLost é implementado no controlador Bluetooth e depois testado para confirmar se os dispositivos BLE não são perdidos nas varreduras. Isso proporciona economia de energia e também pode fornecer os seguintes benefícios:
- Para um evento
OnFound, o AP principal é ativado após a descoberta de um dispositivo específico. - Para um evento
OnLost, o AP é ativado quando um dispositivo específico não pode ser encontrado. - Os aplicativos Framework recebem menos notificações indesejadas quando um dispositivo próximo está ao alcance.
- As verificações contínuas permitem que os aplicativos de estrutura sejam notificados quando um dispositivo está fora do alcance.
Um filtro de varredura pode ser baseado na descoberta de anúncios de um dispositivo (o evento OnFound ). A camada Java pode especificar parâmetros como primeira descoberta (ou um número específico de anúncios desde a primeira descoberta). Implemente a filtragem BLE usando o comando HCI Advertising Packet Content Filter .