Our view is simple: it is feasible in some cases, but only under the right conditions. For ordinary consumer phones and casually used apps, the approach is usually not reliable enough to be considered a full substitute for a dedicated gateway.<\/p>\n\n\n\n
The target use case<\/h2>\n\n\n\n
The requested architecture is straightforward on paper. A B002<\/a> oder B005<\/a> beacon advertises BLE data at a configured interval. A phone running the customer\u2019s app scans for those advertisements, reads the beacon ID and signal strength, and uploads the detection event to the server.<\/p>\n\n\n\n That fits the capabilities of Lansitec Leuchtfeuer<\/a>. Der B002<\/a> is an ultra-thin BLE label based on iBeacon, with configurable advertisement intervals from 100 ms to 10 s and a line-of-sight transmission distance listed as 150 m. The B005<\/a> is a more rugged IP68 beacon with configurable intervals, optional AoA-Unterst\u00fctzung<\/a>, and the same listed 150 m line-of-sight range.<\/p>\n\n\n\n So the problem lies not in the beacon side but the phone side.<\/p>\n\n\n\n In Lansitecs B-Mobile<\/a> solution, Bluetooth-Gateways<\/a> werden an festen Standorten eingesetzt. Leuchtfeuer<\/a> advertise periodically, Gateways<\/a> receive the data, and the server calculates or interprets the location based on the known positions of those Gateways<\/a>. The same documents also note that Tor<\/a> reception is effectively always on in the intended deployment model, and that RSSI<\/a> can vary because of walls, interference, and multipath effects.<\/p>\n\n\n\n Having the app in this place changes the whole solution design.<\/p>\n\n\n\n A fixed Tor<\/a> gives you three things a normal phone does not:<\/p>\n\n\n\n This is the first caveat we would put in front of any customer. Even if the app hears the beacon, a moving phone is not functionally equivalent to a mounted Tor.<\/a><\/p>\n\n\n\n On iOS, Bluetooth work in the background is possible, but constrained. Apple states that foreground-only apps cannot scan for and discover advertising peripherals while in the background or while suspended. Apps that declare the Bluetooth-central background mode can still discover and connect to peripherals in the background, but background scanning behaves differently: duplicate discoveries are coalesced, and scanning intervals may increase, which means discovery can take longer. Apple also says apps woken for Bluetooth events should finish quickly, and notes roughly 10 seconds for background work before suspension pressure becomes a problem. (1)<\/a><\/sup><\/p>\n\n\n\n There is one useful iOS workaround: beacon region monitoring. Apple\u2019s Core Location framework can monitor iBeacon regions and wake the app on entry or exit events. But there are tradeoffs. Apple limits region monitoring to 20 regions per app, and explicitly recommends beacon ranging only while the app is in the foreground. (2)<\/a><\/sup><\/p>\n\n\n\n So what does that mean in practice?<\/p>\n\n\n\n For iOS, an app can support beacon-related background behavior, especially coarse \u201centered region \/ exited region\u201d workflows. But it is not a good platform for continuous, gateway-like passive scanning across a broad deployment. If the customer wants an always-listening phone that silently acts like infrastructure, iOS is the weak option.<\/p>\n\n\n\n Android is more flexible, but it is not magic. Google\u2019s current developer guidance says background BLE communication is possible, yet the app process needs to stay alive. If the process is killed, connections are closed. Google also notes that unfiltered scans are stopped when the screen turns off, and resumed when the screen turns on, unless filtered scanning is used.<\/p>\n\n\n\n For background use, Android documents several paths: scanning with a PendingIntent, using CompanionDeviceService, using WorkManager, or running a foreground service with the connectedDevice type. Google also discourages periodic scans as a general solution because they are inefficient and may still be interrupted. Starting with Android 14, foreground services must declare the appropriate service type explicitly. (3)<\/a><\/sup><\/p>\n\n\n\n This is the key point: Android can do this better than iOS, but reliability depends heavily on deployment discipline.<\/p>\n\n\n\n A normal consumer Android phone may still stop the app because of OEM battery optimization, user settings, background restrictions, or memory pressure. One might need a customized industrial grade Android device in order to make sure the process is not killed in the background. A managed device with whitelisting, high-priority app handling, controlled power settings, and a role-specific workflow has a much better chance.<\/p>\n\n\n\n We\u2019ve seen three situations where the app-based idea is reasonable.<\/p>\n\n\n\n \u0422his could work in cases where the user keeps the app open during a shift, or the phone is mounted and used as part of a work process, beacon reception becomes much more realistic. An example would if it is mounted in a vehicle or construction equipment. Like an Uber Driver app.<\/p>\n\n\n\n A rugged or customized Android phone, especially one managed by the enterprise, is far better than a random personal handset. Here, the phone is not a casual mobile app platform, it is a semi-dedicated terminal. As such a greater degree of customization is expected and it would be reasonable for the software to be customized in a way that is going to make the process feasible.<\/p>\n\n\n\n If the customer only needs \u201cbeacon seen,\u201d \u201cbeacon near phone,\u201d or \u201cworker entered a zone with a managed handset,\u201d then the app may be good enough. If they need stable room-level or site-level monitoring independent of user behavior, then no, that is Tor<\/a> territory.<\/strong><\/p>\n\n\n\n The app approach has these core limitations:<\/p>\n\n\n\n For a customer who insists on the app approach, we would recommend the following.<\/p>\n\n\n\n Verwenden Android, not iOS<\/strong>, for the primary proof of concept. Build around filtered BLE scans, foreground service behavior where permitted, and enterprise device management. Use rugged\/customized devices if possible. Keep the app tied to an operational workflow, not occasional use. Treat the app as a managed terminal, not a casual install from an app store.<\/p>\n\n\n\n For iOS, position the solution more narrowly. It may support alerting, presence hints, or controlled beacon-region workflows, but not full gateway replacement across demanding deployments.<\/p>\n\n\n\n And for customers who need consistent site coverage, minimal dependency on user behavior, and a stable reference point for tracking, keep the dedicated Bluetooth gateway architecture. That is still the best solution from an engineering and stable functionality perspective.<\/strong><\/p>\n\n\n\n Yes, a mobile app can receive beacon broadcasts in the background. But, that does not automatically make it a good substitute for a Bluetooth-Gateway<\/a>.<\/p>\n\n\n\n On iOS, the approach is limited and should be treated as conditional at best. On standard Android, it is possible but fragile. On customized or industrial Android devices, especially in a managed operational environment, it becomes much more realistic.<\/p>\n\n\n\n So the final conclusion is this:<\/p>\n\n\n\n An app-only background monitoring solution is feasible for selected Android deployments with controlled devices and continuous app use. It is not a reliable general replacement for fixed Bluetooth-Gateways<\/a>, especially on iOS or on unmanaged consumer phones.<\/strong><\/p>\n\n\n\n <\/p>\n\n\n\n Referenzen und weiterf\u00fchrende Literatur:<\/p>\n\n\n\n <\/p>","protected":false},"excerpt":{"rendered":" Purpose Some customers want to use a mobile app on iOS or Android to receive Bluetooth beacon broadcasts in the background, instead of deploying a dedicated Bluetooth gateway. In this paper, we evaluate whether that approach is technically feasible for Lansitec beacon-based monitoring, especially for devices such as the B002 Bluetooth Label and B005 Bluetooth… Weiterlesen \u00bbMachbarkeit der Verwendung einer mobilen App zur Hintergrund\u00fcberwachung von Beacons anstelle eines Bluetooth-Gateways<\/span><\/a><\/p>","protected":false},"author":1,"featured_media":18710,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[19],"tags":[],"class_list":["post-18704","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/posts\/18704","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/comments?post=18704"}],"version-history":[{"count":4,"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/posts\/18704\/revisions"}],"predecessor-version":[{"id":18712,"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/posts\/18704\/revisions\/18712"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/media\/18710"}],"wp:attachment":[{"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/media?parent=18704"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/categories?post=18704"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.lansitec.com\/de\/wp-json\/wp\/v2\/tags?post=18704"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Why is this different from the normal Lansitec model<\/h2>\n\n\n\n
\n
iOS feasibility<\/h2>\n\n\n\n
Android feasibility<\/h2>\n\n\n\n
When the app approach can work<\/h2>\n\n\n\n
First, when the app is effectively in continuous operational use<\/h3>\n\n\n\n
Second, when the hardware is controlled<\/h3>\n\n\n\n
![\"customized](\"https:\/\/www.lansitec.com\/wp-content\/uploads\/2026\/04\/Android-Phone.jpg\" "\\"\\"")
Third, when the requirement is event detection, not infrastructure-grade location<\/h3>\n\n\n\n
Main limitations that should be stated clearly<\/h2>\n\n\n\n
\n
Practical recommendations<\/h2>\n\n\n\n
Abschluss<\/h2>\n\n\n\n
\n