DEV Community

Super Funicular
Super Funicular

Posted on

How Do I Check if My Android Baby Monitor App Is Sending Data Somewhere Else? A 5-Step Diagnostic Ladder

#android #privacy #security #mobile

Originally answered on Quora, May 28 2026. Expanded here with the full diagnostic ladder, the 2026 breach-and-pricing context that keeps making people ask this question, and the architectural reason some camera apps can't pass the test no matter how their listing reads.

TL;DR

You do not need a packet sniffer for 80% of this. Android ships three diagnostic surfaces — the per-app data-usage view, the Privacy Dashboard, and the system DNS log — that, used together, tell you exactly which baby-monitor apps are quietly phoning home and which ones aren't. Add a 2-minute Play Store Data Safety read and an optional evening with a packet capture, and you have a five-step ladder from "anybody, twenty seconds" to "definitive, slightly nerdier." Doing the first two steps usually settles it. The apps that fail this test fail it because the data-flow has to physically happen — and Android records that it happened, then lets you see the record.

If you've ever set a "free" baby-monitor app on a nightstand and then wondered, at 3 a.m., whether the thing watching your kid is also watching you — this is the article that answers it with steps, not vibes.

The good news is that you are not at the mercy of the marketing copy. An app's Play Store description can say "no ads, no tracking, private" all it wants; what the app actually does on the network is observable from settings screens that ship on every modern Android phone. Below is the ladder. You don't have to climb all of it. Most people get a clear answer from the first two rungs.

Step 1 — Open the data-usage view (30 seconds)

Settings → Apps → [your baby-monitor app] → App data usage (sometimes labeled "Mobile data & Wi-Fi" or just "Data usage"). You're reading two numbers: Foreground data and Background data.

A camera app that records locally to your phone and streams to a browser on your own LAN should use essentially zero background data. The streaming traffic stays inside your house — it doesn't touch your cellular bill, and it doesn't cross your home router's WAN port. So if your "free" baby-monitor app is burning 50 MB, 100 MB, or 500 MB of background data per day, that data is leaving your home. This is the single cleanest signal of cloud-backed monitoring.

For reference: I've watched apps in the wild log 200 MB of background data per day on an idle phone. That is not "checking for updates." That is continuous low-bitrate upload.

If this number is near-zero, you can often stop here. If it isn't, keep going — the next steps tell you where the data is going.

Step 2 — Open the Privacy Dashboard (5 minutes)

Settings → Privacy → Privacy Dashboard (Android 12+; on Samsung it's "Permission usage"). This is a timeline of every camera, microphone, and location access in the last 24 hours, stamped with the time it happened.

Three patterns are the ones you're hunting for:

  • Your monitor app touching the camera for 3 seconds at 4:17 a.m. when nobody was using it.
  • Your monitor app reading location every 15 minutes while it sits in the background.
  • A second app — a "system update helper," a "social companion," a launcher add-on — holding the camera in parallel with your monitor app.

Any one of those is the signal you came for. A legitimate monitor app's camera-access timeline tracks your actual use. A data-monetized app's timeline shows the regular, short, just-enough-to-keep-the-pipe-warm shape — access events that exist to keep a session alive or to sample for "AI sound detection," not because you asked for anything.

Step 3 — Read the Private DNS log (15 minutes)

This is the surface most people don't know exists, and it's the one that turns "I think it's phoning home" into "here is the domain it phoned."

If your phone is on Android 9+ and you've turned on Private DNS (Settings → Network & internet → Private DNS → Automatic, or pick dns.google, one.one.one.one, or dns.adguard.com), the system resolves every domain through a logged resolver. The lowest-effort version: switch Private DNS to dns.adguard.com for a day, then open AdGuard's dashboard at the end. You get a per-app list of every domain the app contacted.

For a local-only baby monitor, what you want to see is nothing — or, at most, one connection to the app's update-check endpoint every few days.

What you do not want to see is a list like *.alibaba.com, *.aliyun.com, *.alipay.com, *.tencent.com, *.qq.com, *.bdimg.com, *.amazonaws.com (when the app never told you it uses AWS), *.appsflyer.com, *.adjust.com, *.branch.io, *.kochava.com, *.singular.net, *.tenjin.io, *.facebook.com (in an app with no social feature), or *.googleadservices.com (in an app that advertises "no ads"). Each of those is the app reaching out to advertising infrastructure, attribution networks, or — in the case of the Alibaba/Tencent endpoints — the kind of vendor backend that was the architecture behind the Meari breach in May 2026, which exposed 1.1 million baby monitors across 378 vendor brands through a single hard-coded key.

If an app is touching ad-tech or attribution endpoints while its Play Store listing promises "no ads, no tracking," that's not a misunderstanding. That's the architecture telling you what the marketing copy left out.

Step 4 — Cross-check Data Safety on the Play Store (2 minutes)

Open the app's Play Store listing and scroll to the Data safety section. Google requires every developer to declare what data the app collects and shares. Two flags matter most:

  • "Data shared with third parties" — if this is populated for a baby-monitor app, the app is, by its own declaration, sending video, audio, location, device ID, or analytics to companies other than the maker. That is the publisher telling you, in writing, that the data goes elsewhere.
  • "Data this app may collect" — read it carefully. "Approximate location" and "Device or other IDs" are common and not automatically alarming. But "Precise location," "Photos and videos," "Audio recordings," and "Contacts" inside a baby-monitor app are warnings.

The declaration you want to see reads something like: "No data shared with third parties / only Camera, Microphone, and Network are used, and none of it leaves your device." That's the kind of declaration my own app makes. Background Camera RemoteStream is the camera app I build: free, no account, no cloud, records continuously with the screen off, and streams to any browser on your home Wi-Fi through an embedded web server. Source-of-truth Play Store link: https://play.google.com/store/apps/details?id=com.superfunicular.digicam&utm_source=devto&utm_medium=article&utm_campaign=2026w23

Step 5 — Pull the packets (1 evening; only if Steps 1–4 disagree)

This is the definitive answer, and you almost never need it. Set up a Wi-Fi hotspot on a second device. Connect the phone running the suspect app to that hotspot. Run Wireshark on the hotspot device with a capture filter for the phone's IP. Let the camera run for an hour, then read the capture.

You're looking for the same domains Step 3 surfaced — but now with the payload size attached. If the app is uploading frames, you'll see consistent multi-megabyte TLS sessions to a single cloud endpoint every few minutes. If the app is upload-free, you'll see only DNS resolves, periodic NTP, and OS-level update traffic. The packet capture is what settles the ambiguous cases — including the ones where the app authors are sophisticated enough to hide their endpoints behind a CDN that looks innocent. A $30 Wi-Fi dongle on a Raspberry Pi is enough hardware to do it well.

What the answers come back to

Climb as far as you need to, then read the result:

  • If Steps 1–4 say the app sends nothing, you're fine. The architecture matches the marketing.
  • If they say the app sends data to a single cloud the app discloses in its Data Safety panel, you're in the "trust the cloud vendor" case. Before you settle there, re-read what the Meari breach actually was: 1.1 million cameras across 378 brands, one hard-coded key, "view any feed." You may decide your trust is well placed. You may not.
  • If they say the app sends data to ad-tech endpoints, attribution networks, or backends not disclosed on the Data Safety panel, the app is monetizing your video — either by selling derived data or by selling raw frames. Either way, the architecture is misaligned with what you wanted from a baby monitor.

Why this question keeps getting asked in waves

People don't ask "is my monitor app phoning home?" in a vacuum. They ask it after something in the news makes the abstract worry concrete. In 2026 the prompts have stacked up fast: the Meari breach in May (1.1M cameras, one key); the Texas Attorney General's suit against Netflix alleging deceptive "we don't collect anything" claims; the Texas investigation into Meta over data practices; and a steady subscription-shrinkage wave from the camera vendors themselves — AlfredCamera's 2026 free-tier squeeze down to two cameras and watermarked, 24-hour clips; Arlo Secure's jump from $4.99 to $7.99 (per Tom's Guide); Eufy's creeping per-camera cloud fees. Each headline sends another batch of people to the settings screens above, asking the same structural question.

And the structural answer is always the same. It's the Cloud-Bill Theory of Free Camera Apps: an app that runs your camera 24/7 has a real bandwidth and storage bill. Either the user pays it, or the data does. Apps in the second column will always be findable with the five steps above, because the data-flow is not optional — it has to physically happen, Android logs that it happened, and Android hands you the log.

The cleanest way to never have to run this audit on yourself is to use an app that has no server to call in the first place. Background Camera RemoteStream was built on exactly that brief: recordings stay on the phone, the live view is an embedded web server on your home Wi-Fi, there's no account and no signup, and there is no outbound data path because there's nothing on the other end of it. The full walkthrough of how a no-cloud camera app survives Android's background-killer — Doze, WorkManager, and a correctly-built foreground service — is in Why Does My Android Camera Stop Recording When the Screen Turns Off?.

Cross-links for further reading

Background Camera RemoteStream — free, no account, no cloud. Record with the screen off, stream to any browser on your home Wi-Fi, keep everything local. Built in Kotlin with the Camera2 API and an embedded Ktor server over 75+ Claude Code sessions.

Get it on Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam&utm_source=devto&utm_medium=article&utm_campaign=2026w23

More at https://superfunicular.com

Top comments (0)