I build ad tech for a living. I also have a baby. So I searched Google Play for "baby tracker", "pregnancy tracker", "contraction timer", "baby sleep white noise", "baby monitor", "breastfeeding pumping tracker", "baby milestone", and a few more. Took the top results by install count. Decompiled them with jadx. Scanned every one for tracking SDKs, ad networks, and permission requests.

56 apps on the list. 46 survived decompilation. 472 million combined installs. The scanning was automated: grep for SDK packages, tracker domains, pre-consent initialization, and child data fields near analytics calls.

Facebook Fires Before You Consent

Twelve apps initialize the Facebook SDK before any screen appears. Not before the consent screen. Before any screen. The mechanism is Android's ContentProvider, which runs before Application.onCreate(), which runs before any Activity.

Facebook ships a class called FacebookInitProvider. It's a ContentProvider. When included in an app, it auto-registers and fires at launch. The code path:

FacebookInitProvider.onCreate()
  -> FacebookSdk.sdkInitialize()
    -> FetchedAppSettingsManager.loadAppSettingsAsync()
      -> (network call to Facebook's servers)

ContentProviders execute before any user interaction. Before the consent dialog. Before the splash screen. The SDK, once initialized, collects the advertising ID and sends an app activation event.

Facebook provides an opt-out: set com.facebook.sdk.AutoInitEnabled to false in the manifest. None of these twelve apps do that. Whether the data actually reaches Facebook's servers at runtime is something static analysis cannot prove. But the code path is there, and nothing in the initialization flow gates it on consent.

Child Names Near Analytics Calls

Ten apps have code where a child's name field appears in the same class as analytics event calls. This is co-occurrence in decompiled source, not proof of transmission. Static analysis cannot determine runtime values. But the pattern is worth flagging.

Kinedu is the most striking: child name fields near analytics calls in 11 files, including CreateBabyProfileViewModel, DiaperEntryDetailBottomSheetViewModel, and SkillMilestonesViewModel. Wachanga's breastfeeding tracker has it in the baby name onboarding step, next to the analytics presenter. Philips Pregnancy+ has it in SplashScreenActivity, near a Facebook event call.

What the Code Can't Prove

This is static analysis only. I decompiled APKs and scanned the Java source. I did not intercept network traffic or observe runtime behavior. Specifically:

I can prove an SDK is present. I cannot prove it activates. I can prove code paths exist that combine device IDs with hash functions. I cannot prove the resulting fingerprints are transmitted. The fingerprinting findings (42 of 46 apps) are mostly from embedded SDKs, not the apps' own code. The device ID collection patterns (IMEI, serial number) are largely SDK baggage from older code. On modern Android (API 29+), getDeviceId() is blocked for third-party apps.

The Good Ones

Dormi Baby Monitor has zero analytics or advertising SDKs. Zero tracker domains. Twenty-three permissions, all related to turning a phone into a baby monitor. It does what it says.

BabySleep by Urbandroid has nine permissions, zero SDKs, zero tracker domains. A white noise app that is actually just a white noise app.

Pathways.org Baby Milestones is built by a nonprofit. No ad SDKs, no Facebook, no AppsFlyer. The only fingerprinting finding is from React Native's dev server helper, a framework artifact that doesn't run in production.

I Still Use Four of These Apps

My daughter's sleep schedule depends on one of them.

The average parenting app ships with 7.7 third-party SDKs. 87% request the advertising ID. A third initialize tracking before consent. The default configuration of the standard mobile ad stack is incompatible with the sensitivity of what these apps handle. Three apps proved you can build this without an ad stack. The rest made a different choice.