FlightSort Connectivity · Android
← Resources flightsort.net
ES
Airport baggage · Android app, network and alarms

How the mobile app connects, and how alarms get through when there's no "normal" network

An airport doesn't always have wifi with internet access — many operational networks are internal VPNs with no outside access. The app is built to work in both worlds, and critical alarms use two independent paths precisely because of that.

01

The four possible network scenarios

"Having wifi" and "having internet" aren't the same thing. That difference is what determines what can work and what can't.

📶

Wifi with internet access

Office, public terminal or home wifi, with normal access to any internet service.

Backend: yesInternet: yes
🔒

Wifi / airport's internal VPN

Private operational network that reaches FlightSort's backend but doesn't reach the internet — common in handling networks.

Backend: yesInternet: no
📱

Mobile data

Carrier 4G/5G coverage. Has internet, but on its own it normally doesn't reach an airport's internal network.

Internet: yesDirect backend: no
🛡️

Mobile data + corporate VPN

VPN tunnel over mobile data into the airport's network. Reaches the backend; whether there's also internet outside the tunnel depends on how the VPN is configured.

Backend: yesInternet: depends
Honest note: if the VPN is "full tunnel" (all mobile traffic goes through it), the device can end up with no real internet access even with data coverage — the exact behavior depends on how each airport's IT department configures it, and it's verified during the diagnostic phase before rollout.
02

Normal app use (foreground)

With the app open, only one thing matters: the network needs to reach FlightSort's backend — by whatever path.

✅

Simple rule

If the phone can reach the backend (directly over wifi/data if it's exposed, or via VPN if it's an internal network), the app works in real time: it sees flights, gets instant updates, and can be queried by voice. It doesn't need "internet" in the strict sense — it needs to reach that one specific server.

03

The alarm system: two independent paths

For a critical alarm to get through even with the app closed or the phone locked, there are two paths that don't depend on each other — precisely because no single path covers every network scenario an airport can have.

Path A

Push notification (FCM)

How it arrivesThe backend detects the critical alarm and sends it through Firebase Cloud Messaging (Google), which delivers it to the device.
When it's usedWhenever the phone has real internet access — regular wifi or mobile data.
With the app closedIt does work — it's a system notification, it doesn't depend on the app being open.
ConsumptionMinimal — it doesn't keep any connection of its own open.
Doesn't work if the phone only has an internal VPN with no internet access: Google is never reachable.
Path B

Direct foreground connection

How it arrivesThe app keeps its own real-time connection to the backend, kept alive by a foreground service (persistent notification).
When it's usedWhenever the phone can reach the backend, with or without internet — including an internal VPN with no outside access.
With the app closedStays alive as long as the foreground service keeps running; Android requires a persistent notification for as long as it lasts.
ConsumptionHigher than path A — it keeps an active connection continuously.
Can fail if the phone manufacturer "kills" the process due to aggressive battery optimization — requires excluding the app from that optimization.
Unconfirmed critical alarm in FlightSort's Android app
Real capture — critical alarms screen

This is what the two paths above look like on screen: an unconfirmed alarm, with baggage still in transit and the countdown to departure, and another already resolved right below it — whichever path it arrived through.

04

Which path works in each scenario

The two paths are complementary, not redundant: each one covers exactly the gap the other leaves.

Network scenario Path A · FCM Path B · Direct Result
Wifi with internet ✅ ✅ Both active — real redundancy
Wifi / internal VPN without internet ❌ ✅ Only the direct path delivers the alarm
Mobile data with internet ✅ ⚠️ only if the backend is reachable Usually only path A
Mobile data + corporate VPN ⚠️ depends on the VPN ✅ The direct path is what guarantees delivery
No coverage of any kind ❌ ❌ No new alarms until connection is restored
When it's not possible, no sugarcoating it: if the phone has no path at all — no internet, no backend access — a real-time alarm simply isn't possible by definition. The app will keep showing the last cached information (offline-first), but it can't warn about something it hasn't been able to receive yet.

Want to validate this against your airport's real network?

During the diagnostic phase we check which network scenarios apply to your specific installation.

Request a demo