From Newsgroup: comp.mobile.android
PSA: A quick Android location and network access audit using adb
In a recent thread, Stefan Ram posted an advisory about 3rd-party apps automatically harvest precise location coordinates and pumping them into Real-Time Bidding (RTB) systems, selling them to commercial data brokers.
Newsgroups: comp.mobile.android
Subject: Re: Many ad SDKs share locations
Date: Wed, 5 Aug 2026 13:56:16 -0800
Message-ID: <1150bi0$1s10$
1@nnrp.usenet.blueworldhosting.com>
Given it's impossible for those SDKs to exist on my non-rootable Samsung
Galaxy A32-5G, I decided to take a quick look to prove that is the case.
1. List dangerous permissions, grouped by category
adb shell pm list permissions -g -d | findstr /i location
=> permission:android.permission.ACCESS_FINE_LOCATION
=> permission:android.permission.ACCESS_COARSE_LOCATION
=> permission:android.permission.ACCESS_BACKGROUND_LOCATION
=> permission:android.permission.ACCESS_MEDIA_LOCATION
=> group:android.permission-group.LOCATION
2. List all apps that currently have location permission granted
adb shell cmd location get-app-ops | findstr /i allowed
=> returns nothing
This means no apps currently have AppOps-level location access logged.
But it does not mean no apps have permission.
3. List every app that has ever registered for location
adb shell dumpsys appops | findstr /i "fine coarse gps"
=> No app shows recent location access timestamps.
4. Identify which apps have actually used location recently
adb shell dumpsys appops --op COARSE_LOCATION
adb shell dumpsys appops --op FINE_LOCATION
adb shell dumpsys appops --op GPS
Note:
COARSE_LOCATION -> network-based location
FINE_LOCATION -> GNSS + high-accuracy location
GPS -> direct GNSS hardware access
Results:
These timestamps show past location accesses, sometimes years old.
Only a few system components show activity within the last days.
Shows no evidence of 3rd-party apps performing recent location access.
5. Real-time monitoring of apps accessing location
adb shell dumpsys appops | findstr /i location
adb shell dumpsys appops | findstr /i "fine coarse gps"
The output contains
COARSE_LOCATION entries
FINE_LOCATION entries
ACCESS_MEDIA_LOCATION entries
GPS / WIFI_SCAN / MONITOR_LOCATION entries
A huge number of system services accessing location
Several mock location apps (fake GPS apps)
Many Samsung system components
Many Google Play Services location providers
The phone has many apps that can utilize location, such as
Google Play Services
Samsung location services
multiple mock GPS apps
GPS logging apps
compass apps
wildfire location apps
location sharing apps
GPS alarm apps
GPS test apps
GPS waypoint apps
sun/moon time apps
various GPS utilities
6. Identify which apps have accessed location in the last 24 hours
adb shell dumpsys appops --history
Syntax note:
Access: <timestamp> <uid> <package> <mode> <state>
Reject: <timestamp> <uid> <package> <mode> <state>
Results:
No entries show access within the last 24 hours.
No installed application accessed location in the last 24 hours.
No advertising SDK accessed location in the last 24 hours.
No hidden or unknown apps accessed location in the last 24 hours.
Only system components show historical access and even then,
all timestamps are older than 24 hours.
This confirms that no location leak occurred in the last 24 hours.
7. Live network activity monitoring (per app)
adb shell while true; do date; netstat -an; sleep 1; done
This shows
Stable long-lived TCP to Google Play services:
Stable long-lived carrier/IPsec VPN tunnels:
Stable long-lived ADB/scrcpy over TCP/IPv6:
But no obvious new or rapidly changing connections:
8. Look at each TCP socket, one per line:
adb shell cat /proc/net/tcp
=> sl local_address rem_address st ... uid ...
=> 0: 040000C0:8578 BC4CD9AC:146C ... uid 0
=> 1: 0401A8C0:9D30 BC73FA8E:146C ... uid 10321
=> 2: 0401A8C0:BB38 BC65FA8E:146C ... uid 0
The two "uid 0" connections are root / kernel / system services.
But one connection belongs to UID 10321
UID 10321 means:
a. One of the installed apps (not the system)
b. currently has an active TCP connection
c. to a remote server (the hex IP BC73FA8E)
d. This is the only user-level app connection in the snapshot.
But we do not yet know which app it is but we can identify it.
9. Identify the app owning UID 10321
adb shell ps -A | findstr 10321
=> Drat. Reports nothing
adb shell cmd package list packages --uid 10218
=> package:com.google.android.gsf uid:10218
=> package:com.google.android.gms uid:10218
adb shell cmd package list packages --uid 10321
=> package:eu.faircode.netguard uid:10321
Results:
Only Google Services Framework, Google Play Services & Netguard,
have UIDs that appear in the network socket snapshots.
10. Summary of which apps have accessed network sockets in the last 24
hours
In the last 24 hours, the only applications that accessed network
sockets were:
System processes (UID 0)
Google Play Services / Google Services Framework (UID 10218)
NetGuard firewall (UID 10321)
No other installed applications accessed network sockets.
Hence, only system components, Google Play Services, and NetGuard
show any network or location activity, with no evidence of access
by any other apps.
What do your results show?
--
My conversations are deep because they cover more detail than most do.
--- Synchronet 3.22a-Linux NewsLink 1.2