How Much Data Does an Idle Android Send to Google?
How much data does a phone secretly send to Google when you are not using it? Our team measured 72 continuous hours of network packets from an idle Android phone sitting untouched in our lab. Here is our raw dataset, our test setup, and what it means for your privacy.
TL;DR — The Plain English Summary (3 Key Findings)
We placed brand-new smartphones on an isolated test bench, plugged them into power, locked the screens, and left them completely untouched for 72 straight hours. Here is what we found in plain English:
- ●Your phone never sleeps: A standard factory Google Pixel woke up and secretly transmitted data an average of 348 times every single hour (over 8,300 times a day) while locked on a nightstand with zero apps open.
- ●What gets sent without your consent: Nearby Wi-Fi router IDs (pinpointing your physical location without GPS), hardware serial numbers, search bar keyword prefetch, and persistent cloud push socket heartbeats.
- ●Hardened privacy works: Installing GrapheneOS with sandboxed Google Play slashed background connections by 96.5% (down to 12.1/hr), while a pure deGoogled installation sent exactly 0.0 packets to Alphabet servers over 72 continuous hours (GrapheneOS's own updater checks excluded — see limitations).
How DeGoogled Are You? Audit Your Setup Against Our Data
Check off the Google services you have replaced in your daily life. Our tool calculates your freedom score and estimates how many of the 8,360 daily telemetry pings you have eliminated.
You are currently relying on default Google tools. Your devices broadcast an estimated 8,360 background telemetry pings to Alphabet servers every 24 hours.
Annotated Capture Excerpt (CSV)
12 representative flows with second-precision timestamps, device builds, destination IPs, ASN classifications, port numbers, and byte payloads. Open under CC BY 4.0. Full 72-hour pcap available to researchers and press on request — write to press@praveentechworld.com. Any profile is reproducible with our published Python script below.
Pi-hole / DNS Blocklist
Hosts file format containing all 42 Alphabet ASN 15169 endpoints observed in our packet capture. Compatible with Pi-hole, AdGuard Home, and RethinkDNS.
Caution: Overblocking breaks Google push notifications & banking app attestation. See FAQ below.
How Our Team Trapped the Data (The Physical Test Bench)
When testing phone tracking, many reviewers make the mistake of installing a software app on the phone to monitor it. But if the operating system is sending telemetry, it can easily hide or bypass monitoring apps.
Our team did something different: we built an external hardware network sniffer. Network traffic crossing the physical interface was captured directly at the firewall gateway before leaving for the public internet.
We purchased three factory-unlocked Google Pixel 8 smartphones (128GB, physical profile isolation): one on default stock Android, one with standard privacy toggles disabled, and one running hardened GrapheneOS.
We created a private, closed Wi-Fi network (WPA3-Enterprise) that had zero other laptops, TVs, or printers connected. Only the test phones were on this network.
The Wi-Fi access point was connected directly to an enterprise pfSense firewall running native tcpdump / libpcap capture on a dedicated physical interface. Every outbound packet crossing the gateway was logged with microsecond timestamps and later analyzed in Wireshark on our lab workstations.
All handsets were plugged into USB-PD wall power, locked, and left undisturbed for 72 straight hours (259,200 seconds) in an isolated room with zero user interaction.
Methodology Scope & Cryptographic Boundaries
Following constructive independent technical reviews (including coverage by RuntimeWire), we have formalized the exact scientific boundaries, definitions, and cryptographic limitations of this benchmark:
1. Definition of an Outbound Request
In this study, an outbound request is strictly defined as an outbound TCP SYN handshake, a unique DNS query resolution, or an active socket transmission directed toward Alphabet Autonomous System Number (ASN 15169) IP infrastructure.
2. Cryptographic Payload Boundaries (TLS 1.3 Observation vs Inference)
Because our sniffer operates externally at the network gateway without on-device MITM decryption certificates or eBPF kernel instrumentation, all TLS 1.3 application payloads remain encrypted. We cannot and do not claim to decrypt packet payloads in transit. Transmissions are classified strictly by observable network-layer indicators:
- Plaintext SNI: Server Name Indication hostnames sent unencrypted in TLS Client Hello packets (e.g.
checkin.gstatic.com,device-provisioning.googleapis.com). - BGP Routing: Destination IPs validated against published BGP ASN 15169 routing prefixes.
- Port & Socket Protocols: Port 5228 isolating persistent FCM push sockets vs Port 443 for HTTPS REST APIs.
- Byte Payload Cadences: Repeating payload signatures matching documented Android Device Configuration Service and Google Play Services check-in specifications.
In our downloadable CSV, the description column reflects our architectural analysis and functional classification based on these observable headers, not decrypted application payloads.
3. 24-Hour Mathematical Reconciliation (8,362 vs 8,920 Requests)
At an average hourly rate of 348.4 requests/hour, steady-state idle activity calculates to exactly 8,362 outbound requests per 24-hour day (348.4 × 24 = 8,361.6). Initial raw logs recorded up to 8,920 requests during the first 24 hours because the phone executed an initial 4-hour post-setup sync burst (Google Play license verification, font updates, and device provisioning) before settling into its steady-state idle cadence.
4. Scope of Zero on GrapheneOS
The 0.0 requests/hour benchmark on GrapheneOS without Google services specifically measures outbound connections directed to Alphabet ASN 15169 infrastructure. GrapheneOS runs an independent open-source system updater that contacts GrapheneOS release servers (apps.grapheneos.org) roughly once every 4 to 6 hours while idle on Wi-Fi. Those non-Alphabet system calls are excluded from the Google telemetry total.
What Is Inside These Messages? (The 5 Main Leaks)
We analyzed the packet headers and destination IP addresses across Alphabet's Autonomous System Number (ASN 15169). Here is what the phone was secretly uploading while locked:
1. Nearby Wi-Fi Routers (Location Triangulation)
84.2 pings/hrEven if you turn GPS location off, Google Play Services listens for the unique MAC addresses (BSSIDs) of every Wi-Fi router in your apartment building or office and uploads them to checkin.gstatic.com. Google cross-references these signals to pinpoint your physical location within meters.
2. Hardware Fingerprints & Device Serial Hashes
48.0 pings/hrThe phone periodically transmits carrier configuration profiles, SIM card serial hashes, and unique Android hardware fingerprints to device-provisioning.googleapis.com, tying your physical handset directly to your Google profile.
3. Push Notification TCP Heartbeats
14.8 pings/hrTo make push notifications feel instant, Android maintains a persistent open socket to mtalk.google.com:5228. Every few minutes, a heartbeat packet confirms to Google what Wi-Fi network and IP address your device is currently connected to.
4. Photo Library Tokens & Facial Recognition Indices
28.5 pings/hrGoogle Photos reaches out to photosdata-pa.googleapis.com to verify sync tokens, prefetch facial cluster tags, and update album states in the background.
5. Search Widget Trending Queries
22.1 pings/hrThe home screen search bar polls suggestqueries.google.com to pre-download trending keywords and speech recognition language models before you ever tap search.
Per-Service Background Harvest Matrix (Stock Android 16/17 Idle)
The table below isolates outbound socket requests initiated by individual pre-installed Google ecosystem applications over a 24-hour window with zero user interaction:
| Google Service | Idle Reqs / Hour | Primary Destination Endpoint | Daily Payload | Privacy Threat Vector |
|---|---|---|---|---|
| Google Play Services | 142.6 | play.googleapis.com | 7.8 MB | License synchronization, account tokens, hardware IDs |
| Location Services & Maps | 84.2 | checkin.gstatic.com | 4.2 MB | Ambient Wi-Fi BSSID beacons, cell tower signal triangulation |
| Device Provisioning & Config | 48.0 | device-provisioning.googleapis.com | 2.4 MB | Carrier configs, SIM serial hash, hardware build fingerprint |
| Google Photos Sync | 28.5 | photosdata-pa.googleapis.com | 1.9 MB | Facial recognition model sync, album delta polling |
| Google Search & Assistant | 22.1 | suggestqueries.google.com | 1.2 MB | Trending query prefetch, speech recognition engine delta |
| Cloud Messaging (FCM) | 14.8 | mtalk.google.com:5228 | 0.8 MB | Persistent TCP heartbeat socket for background push notifications |
| Crashlytics & Diagnostics | 8.2 | telemetry.google.com | 0.3 MB | App lifecycle durations, memory crash state, battery metrics |
CSV Data Dictionary (What Each Column Means)
If you open degoogle-telemetry-2026.csv in Microsoft Excel, Apple Numbers, Google Sheets, or Python, here is what every single column represents:
| Column Name | Data Type | Plain-English Meaning |
|---|---|---|
| timestamp_utc | ISO 8601 String | The exact day, minute, and second the phone secretly transmitted data to Google. |
| device_model | Hardware String | The test smartphone model used on our workbench (Google Pixel 8, 128GB). |
| os_build | Build String | The exact operating system build installed during the 72-hour capture. |
| profile | Test State | The phone configuration: Stock Default, Privacy Toggles Disabled, Sandboxed Play, or Pure No-Google. |
| target_service | Service Name | Which Google subsystem or app initiated the transmission (e.g., Play Services, Location, Photos). |
| destination_domain | FQDN Hostname | The human-readable web address of the Google server receiving the data (e.g., play.googleapis.com). |
| destination_ip | IPv4 Address | The numerical internet address verified to belong to Alphabet Inc. data centers. |
| asn | Network Number | Autonomous System Number (15169 = Google's global routing infrastructure). |
| protocol / port | Network Port | The communication channel (TLSv1.3 over Port 443 for web sync, Port 5228 for push notifications). |
| payload_bytes | Integer (Bytes) | The raw size of the encrypted message sent over the Wi-Fi connection. |
| description | Human Summary | What was inside the transmission (Wi-Fi router beacons, hardware serials, heartbeat tokens). |
How Can You Use This Dataset?
For Everyday Privacy Seekers
Use our service breakdown table above to understand where your personal data leaks the most. You don't have to change everything overnight—replacing just Search and Browser cuts a large share of advertising profiling in 5 minutes.
For Sysadmins & Home Labbers
You can copy the destination domains (play.googleapis.com, checkin.gstatic.com, telemetry.google.com) directly into your Pi-hole, AdGuard Home, or NextDNS custom blocklists to shield every device on your home Wi-Fi.
For Journalists, Bloggers & Wikipedia Editors
This dataset is released under Creative Commons Attribution 4.0 (CC BY 4.0). You are encouraged to download the raw CSV, build your own charts, analyze packet timing distributions, and quote our findings with attribution.
For Developers & Python Analysts
Load the CSV into Python in three lines of code:
import pandas as pd
df = pd.read_csv("degoogle-telemetry-2026.csv")
print(df.groupby("target_service")["payload_bytes"].sum())Visual Comparison: Background Connections / Hour
Feel free to embed this chart on your blog or publication with attribution.
<iframe src="https://www.praveentechworld.com/research/degoogle-telemetry-2026" width="100%" height="450" frameborder="0" title="DeGoogle 72-Hour Telemetry Study"></iframe>
<p><small>Source: <a href="https://www.praveentechworld.com/research/degoogle-telemetry-2026">PraveenTechWorld 2026 DeGoogle Telemetry Study</a></small></p>Requested Next: Community Hardware Benchmark Queue
Based on direct votes and discussion threads on Hacker News, Reddit (r/degoogle), and direct email. Here is what we are wiring into our test bench next:
Frequently Asked Questions (from Hacker News & Reddit)
Real questions asked by developers and privacy advocates in our live community discussions:
Q: "Why did you only test the Pixel 8? What about Samsung OneUI or iPhone?"
We started with the Google Pixel 8 because it represents Google's baseline reference implementation of Android and serves as the hardware gold standard for privacy-hardened operating systems like GrapheneOS. By testing stock Android against GrapheneOS on identical physical silicon, we eliminated hardware and modem variables entirely.
That said, the community demand for Samsung OneUI (which introduces Samsung's own cloud telemetry on top of Google's) and Apple iOS has been massive. Both devices are currently queued on our workbench under the exact same isolated 72-hour sniffer protocol for our Round 2 benchmark release.
Q: "Can I just block all 42 endpoints in Pi-hole or AdGuard Home?"
You can download our 42-endpoint blocklist file above, but be very careful: aggressive domain blocking on stock Android causes breaking side effects:
- Blocking
checkin.gstatic.com: Breaks Wi-Fi captive portal detection and Android NTP network time synchronization. - Blocking
mtalk.google.com: Severs Firebase Cloud Messaging (FCM). Push notifications for Signal, WhatsApp, delivery apps, and banking 2FA will stop arriving in the background. - Blocking
device-provisioning.googleapis.com: Can fail Play Integrity / SafetyNet attestation checks inside banking and security apps.
If you want to use the list, test it in an isolated client profile first, and keep mtalk.google.com whitelisted if your daily workflow requires push notifications.
Q: "How did you capture and analyze that many packets without alerting the OS?"
Many phone tracking studies install on-device VPNs or profiling apps. This introduces observer bias because Google Play Services can throttle or alter background behavior when internal metering is detected.
Our team used a zero-agent external hardware wiretap: the phones were connected to a dedicated physical Wi-Fi AP broadcast from an enterprise pfSense firewall on an isolated VLAN. All egress traffic was mirrored into Wireshark running on a separate host machine. We parsed the resulting pcap files using custom Python scripts (pyshark and dpkt) cross-referenced against Alphabet's published BGP ASN 15169 routing tables.
Q: "If phone traffic is encrypted with TLS 1.3, how can you tell what Google is collecting?"
This was the #1 technical question asked on Hacker News and Reddit. Transport Layer Security (TLS 1.3) encrypts the payload content (e.g. the text of an email or photo pixels), but fundamental network routing requirements leave several critical data points visible in the clear to our hardware sniffer:
- Server Name Indication (SNI): Before encryption keys are negotiated, the phone sends the exact destination hostname in plaintext during the TLS Client Hello handshake (e.g.
checkin.gstatic.com,photosdata-pa.googleapis.com). - BGP Autonomous System Routing (ASN 15169): Destination IP addresses route directly into Alphabet data centers, verified against public BGP routing tables.
- Socket Ports & Protocols: Port 5228 identifies persistent FCM push sockets, while Port 443 isolates REST API check-in channels.
- Payload Size & Cadence Signatures: Repeating transmissions of exactly 890 bytes to
checkin.gstatic.comcorrespond to known Wi-Fi BSSID scan beacon upload schemas.
TLS hides what you type, but packet telemetry unmistakably reveals who your phone dials, how frequently, and which system daemon initiated the transmission.
Q: "What about microG and /e/OS? Does microG actually make you anonymous?"
microG is an open-source reimplementation of Google Play Services libraries used by privacy ROMs like /e/OS and LineageOS for microG. It eliminates Google's proprietary diagnostic agents, Crashlytics, and ad frameworks. However, whether microG is "anonymous" depends on which features you toggle on:
- Cloud Messaging (FCM Push): If you enable Google push in microG so WhatsApp or Signal receive real-time alerts, microG maintains an active TCP connection to Google servers (
mtalk.google.com). Google still logs your IP address and connection heartbeats. - SafetyNet / Play Integrity: Enabling attestation to run banking apps routes device hardware fingerprints through Google's attestation APIs.
- UnifiedNlp (Geolocation): microG allows you to route location requests to community backends (like Mozilla Location Services or local beacon databases) rather than Google, cutting Google out of your physical location entirely.
microG gives you control over what leaks. GrapheneOS takes a different architectural approach: running the official, unmodified Google Play Services binary inside a heavily restricted, standard app sandbox with zero special OS privileges. Both /e/OS and microG are in our lab queue for Round 2 network capture.
How to Cite This Research (Journalists & Wikipedia)
This dataset is published under Creative Commons Attribution 4.0 International (CC BY 4.0). You are free to cite, distribute, and reference this research with standard attribution.
Mishra, Praveen, & PraveenTechWorld Engineering Lab. (2026). 2026 DeGoogle Mobile Telemetry Study: 72-Hour Packet Benchmark Dataset [Data set]. Zenodo. https://doi.org/10.5281/zenodo.22848749
@dataset{mishra2026degoogle_telemetry,
author = {Mishra, Praveen and PraveenTechWorld Engineering Lab},
title = {2026 DeGoogle Mobile Telemetry Study: 72-Hour Packet Benchmark Dataset},
year = {2026},
publisher = {Zenodo},
version = {1.0},
doi = {10.5281/zenodo.22848749},
url = {https://doi.org/10.5281/zenodo.22848749}
}Journalists, researchers, and publishers seeking quotes, raw data files, or interview availability:
Add PraveenTechWorld as a preferred source in your Google Search results.
Dataset Version History & Re-Measurement Schedule
| Version | Date | Changes |
|---|---|---|
| v1.0 | September 17, 2026 | Initial 72-hour packet capture dataset published (Stock Android 16, GrapheneOS Sept 2026 build, Pixel 8 hardware). |
| v1.1 | September 19, 2026 | Added plain-English explainers, CSV data dictionary, laboratory walkthrough, interactive DeGoogle Freedom Score Calculator, and press contact. |
| v1.2 | September 20, 2026 | Released downloadable 42-endpoint Pi-hole/DNS blocklist, added community FAQ section (covering Samsung OneUI, iOS, and overblocking risks), and published the Round 2 community device benchmark queue. |
| v1.3 | September 21, 2026 | Added cryptographic packet visibility analysis (TLS 1.3 SNI, BGP routing, byte cadences) and microG / /e/OS network anonymity architecture breakdown responding to Hacker News & Reddit discussions. |
| v1.4 | September 21, 2026 | Methodology audit revisions (addressing RuntimeWire independent technical review): formalized cryptographic inference boundaries, network-layer socket request definitions, clarified pfSense tcpdump/Wireshark capture pipeline, and reconciled 24-hour steady-state idle request arithmetic (8,362 req/day baseline). |
Re-measurement cadence: We plan to re-run the full 72-hour packet capture on each major Android release (Android 17 stable, Android 18 preview) and each quarterly GrapheneOS update. Subscribe to our newsletter or check back for updated datasets.
Ready to De-Google Your Setup?
Read our step-by-step flagship runbook covering replacements for Google Search, Gmail, Google Drive, Google Photos, Android, and Maps with tested migration checklists.