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 que suporte 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 as informações é o servidor e o dispositivo que recebe as 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 do BLE, implemente os requisitos do Android Bluetooth HCI .
Modos de dispositivo
Ao usar o 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 periférico e dispositivo central pode se comunicar com outros dispositivos periféricos BLE enquanto envia anúncios no modo periférico. Dispositivos compatíveis com Bluetooth 4.1 e anteriores só podem usar BLE no modo central. Os chipsets de dispositivos mais antigos podem não suportar o modo periférico BLE.
Digitalização BLE
Um dispositivo Android pode segmentar e procurar dispositivos Bluetooth específicos com mais eficiência ao usar o BLE. As APIs BLE permitem que os desenvolvedores de aplicativos criem filtros para encontrar dispositivos com menos envolvimento do controlador host.
Verificação de local
Os serviços de localização de um dispositivo podem usar o Bluetooth para detectar beacons Bluetooth e fornecer uma localização mais precisa. É assim que os usuários ativam o recurso:
- Vá para Configurações > Segurança e localização > Localização .
- Verifique se o botão Local Ligado / Desligado está na posição Ligado .
- Vá para o Modo .
- Selecione o modo de alta precisão ou 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 de um aplicativo, o aplicativo não receberá nenhum resultado da verificação de BLE.
A partir do Android 12, as permissões BLUETOOTH_SCAN , BLUETOOTH_ADVERTISE e BLUETOOTH_CONNECT podem permitir que aplicativos procurem dispositivos próximos sem precisar solicitar a 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 Bluetooth . Isso não afeta a varredura BLE para localização ou dispositivos locais.
Filtrando os resultados da verificação
O Android 6.0 e posterior inclui varredura BLE e correspondência de filtro no controlador Bluetooth. Um dispositivo pode filtrar os resultados da 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, pois a varredura BLE é descarregada no firmware. As varreduras em lote reduzem a frequência com que o AP acorda devido à varredura BLE para dispositivos ou beacons.
O recurso OnFound / OnLost é implementado no controlador Bluetooth e testado para confirmar que 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 de estrutura 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 estiver fora de 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 a primeira descoberta (ou um número especificado de anúncios desde a primeira descoberta). Implemente a filtragem BLE usando o comando Advertising Packet Content Filter HCI .