Propósito

Alguns clientes desejam usar um aplicativo móvel em iOS ou Android para receber transmissões de beacons Bluetooth em segundo plano, em vez de implantar um gateway Bluetooth dedicado. Neste artigo, avaliamos se essa abordagem é tecnicamente viável para o monitoramento baseado em beacons da Lansitec, especialmente para dispositivos como o Etiqueta Bluetooth B002 e B005 Farol Bluetooth. A questão não é se um telefone consegue detectar um beacon. Ele consegue. A verdadeira questão é se um aplicativo de celular consegue fazer isso de forma confiável em segundo plano, ao longo do tempo e com consistência suficiente para substituir um gateway.

Nossa visão é simples: é viável em alguns casos, mas apenas sob as condições certas. Para telefones celulares comuns e aplicativos usados ocasionalmente, essa abordagem geralmente não é confiável o suficiente para ser considerada um substituto completo para um gateway dedicado.

O caso de uso alvo

A arquitetura solicitada é simples no papel. B002 ou B005 O beacon anuncia dados BLE em um intervalo configurado. Um telefone executando o aplicativo do cliente procura esses anúncios, lê o ID do beacon e a intensidade do sinal e envia o evento de detecção para o servidor.

Isso se encaixa nas capacidades da Lansitec. faróis. O B002 É uma etiqueta BLE ultrafina baseada em iBeacon, com intervalos de anúncio configuráveis de 100 ms a 10 s e uma distância de transmissão em linha reta de 150 m. B005 É um farol IP68 mais robusto com intervalos configuráveis, opcional. Suporte ao AoA, e o mesmo alcance de 150 m em linha reta.

Portanto, o problema não está no beacon, mas sim no telefone.

Por que isso é diferente do modelo normal da Lansitec?

Em Lansitec's B-Mobile solução, Gateways Bluetooth são implantados em locais fixos. Faróis Anuncie periodicamente, portais recebem os dados, e o servidor calcula ou interpreta a localização com base nas posições conhecidas daqueles portais. Os mesmos documentos também observam que portal A recepção está efetivamente sempre ativa no modelo de implantação pretendido, e isso RSSI pode variar devido a paredes, interferências e efeitos de múltiplos caminhos.

Ter o aplicativo nesse local altera completamente o projeto da solução.

Um fixo portal Oferece três coisas que um telefone normal não oferece:

• uma posição física conhecida
• comportamento de potência estável
• disponibilidade de recebimento previsível

Esta é a primeira ressalva que faríamos a qualquer cliente. Mesmo que o aplicativo detecte o sinal do beacon, um telefone em movimento não é funcionalmente equivalente a um telefone fixo. portal.

Viabilidade do iOS

No iOS, o funcionamento do Bluetooth em segundo plano é possível, mas limitado. A Apple afirma que aplicativos que só podem ser executados em primeiro plano não conseguem procurar e descobrir periféricos que anunciam enquanto estão em segundo plano ou suspensos. Aplicativos que declaram o modo de segundo plano com foco no Bluetooth ainda podem descobrir e se conectar a periféricos em segundo plano, mas a busca em segundo plano se comporta de maneira diferente: descobertas duplicadas são agrupadas e os intervalos de busca podem aumentar, o que significa que a descoberta pode demorar mais. A Apple também afirma que os aplicativos ativados por eventos de Bluetooth devem terminar rapidamente e observa que há cerca de 10 segundos para o funcionamento em segundo plano antes que a pressão de suspensão se torne um problema. ⁽¹⁾

Existe uma solução alternativa útil para iOS: o monitoramento de regiões por beacons. O framework Core Location da Apple consegue monitorar regiões iBeacon e ativar o aplicativo em eventos de entrada ou saída. Mas há desvantagens. A Apple limita o monitoramento de regiões a 20 regiões por aplicativo e recomenda explicitamente o uso de beacons apenas quando o aplicativo estiver em primeiro plano. ⁽²⁾

Então, o que isso significa na prática?

Para iOS, um aplicativo pode suportar comportamentos em segundo plano relacionados a beacons, especialmente fluxos de trabalho gerais de "entrada em região / saída de região". Mas não é uma boa plataforma para varredura passiva contínua, semelhante a um gateway, em uma ampla implantação. Se o cliente deseja um telefone sempre atento que atue silenciosamente como infraestrutura, o iOS é a opção menos adequada.

Viabilidade do Android

O Android é mais flexível, mas não é mágico. As diretrizes atuais do Google para desenvolvedores afirmam que a comunicação BLE em segundo plano é possível, desde que o processo do aplicativo permaneça ativo. Se o processo for encerrado, as conexões são fechadas. O Google também observa que as varreduras não filtradas são interrompidas quando a tela é desligada e retomadas quando a tela é ligada, a menos que a varredura filtrada seja utilizada.

Para uso em segundo plano, o Android documenta vários caminhos: escanear com um PendingIntent, usar o CompanionDeviceService, usar o WorkManager ou executar um serviço em primeiro plano com o tipo connectedDevice. O Google também desencoraja varreduras periódicas como solução geral, pois são ineficientes e ainda podem ser interrompidas. A partir do Android 14, os serviços em primeiro plano devem declarar explicitamente o tipo de serviço apropriado. ⁽³⁾

Este é o ponto crucial: o Android consegue fazer isso melhor que o iOS, mas a confiabilidade depende muito da disciplina de implementação.

Um celular Android comum ainda pode interromper o aplicativo devido à otimização de bateria do fabricante, configurações do usuário, restrições em segundo plano ou falta de memória. Pode ser necessário um dispositivo Android personalizado de nível industrial para garantir que o processo não seja encerrado em segundo plano. Um dispositivo gerenciado com listas de permissão, gerenciamento de aplicativos de alta prioridade, configurações de energia controladas e um fluxo de trabalho específico para cada função tem uma chance muito maior de sucesso.

Quando a abordagem do aplicativo pode funcionar

Já vimos três situações em que a ideia de usar um aplicativo é razoável.

Primeiro, quando o aplicativo está efetivamente em uso operacional contínuo.

Isso poderia funcionar em casos onde o usuário mantém o aplicativo aberto durante o turno, ou quando o telefone está montado e é usado como parte do processo de trabalho, tornando a recepção de beacons muito mais realista. Um exemplo seria se o dispositivo estivesse montado em um veículo ou equipamento de construção, como um aplicativo de motorista da Uber.

Em segundo lugar, quando o hardware é controlado.

Um telefone Android robusto ou personalizado, especialmente um gerenciado pela empresa, é muito superior a um aparelho pessoal qualquer. Nesse caso, o telefone não é uma plataforma para aplicativos móveis comuns, mas sim um terminal semi-dedicado. Como tal, espera-se um maior grau de personalização e seria razoável que o software também fosse personalizado de forma a viabilizar o processo.

Terceiro, quando o requisito é a detecção de eventos, e não a localização em nível de infraestrutura.

Se o cliente precisar apenas de informações como "beacon detectado", "beacon próximo ao telefone" ou "funcionário entrou em uma zona com um dispositivo gerenciado", então o aplicativo pode ser suficiente. Se precisarem de monitoramento estável em nível de sala ou de local, independente do comportamento do usuário, então não, isso é impossível. portal território.

Principais limitações que devem ser claramente indicadas

A abordagem do aplicativo apresenta estas limitações principais:

• A execução em segundo plano é controlada pelo sistema operacional. Tanto o iOS quanto o Android otimizam agressivamente a duração da bateria. 
• Um telefone não é uma infraestrutura fixa. Em B-Mobile, fixo portal A posição faz parte da lógica de rastreamento.
• RSSI é instável. Os próprios documentos da Lansitec indicam uma fraca recepção de sinal entre diferentes pontos da sala., RSSI oscilações e efeitos de múltiplos caminhos.
• O comportamento do usuário importa. Se o usuário fechar o aplicativo, desativar permissões, desligar o Bluetooth ou permitir que o telefone entre em um modo agressivo de economia de energia, o desempenho cairá.
• A variação entre plataformas é real. Principalmente no Android, o comportamento varia entre os fabricantes, já que não é incomum haver uma forte personalização baseada na marca, ao contrário do iOS, onde a Apple tem controle centralizado.

Recomendações práticas

Para um cliente que insiste na abordagem via aplicativo, recomendamos o seguinte.

Usar Android, não iOS, Para a prova de conceito inicial, desenvolva o aplicativo em torno de varreduras BLE filtradas, comportamento de serviço em primeiro plano quando permitido e gerenciamento de dispositivos corporativos. Use dispositivos robustos/personalizados sempre que possível. Mantenha o aplicativo vinculado a um fluxo de trabalho operacional, não para uso ocasional. Trate o aplicativo como um terminal gerenciado, não como uma instalação casual de uma loja de aplicativos.

Para iOS, posicione a solução de forma mais específica. Ela pode oferecer suporte a alertas, dicas de presença ou fluxos de trabalho controlados por região de beacons, mas não à substituição completa do gateway em implantações complexas.

Para clientes que precisam de cobertura consistente do site, dependência mínima do comportamento do usuário e um ponto de referência estável para rastreamento, mantenha a arquitetura de gateway Bluetooth dedicada. Essa ainda é a melhor solução do ponto de vista da engenharia e da estabilidade da funcionalidade.

Conclusão

Sim, um aplicativo móvel pode receber transmissões de beacons em segundo plano. Mas isso não o torna automaticamente um bom substituto para um... Gateway Bluetooth.

No iOS, a abordagem é limitada e, na melhor das hipóteses, deve ser considerada condicional. No Android padrão, é possível, mas frágil. Em dispositivos Android personalizados ou industriais, especialmente em um ambiente operacional gerenciado, torna-se muito mais viável.

Portanto, a conclusão final é esta:

Uma solução de monitoramento em segundo plano que utiliza apenas o aplicativo é viável para implantações selecionadas do Android com dispositivos controlados e uso contínuo do aplicativo. No entanto, não é uma alternativa confiável e geral para monitoramento fixo. Gateways Bluetooth, especialmente em dispositivos iOS ou em telefones de consumo não gerenciados.

Referências e leitura complementar:

1. Apple: Guia de Programação Bluetooth Essencial
2. Apple: Guia de Programação de Localização e Mapas
3. Android: Comunicação BLE em segundo plano