Google's 8.3B Ad Purge: Android 17 Permission Changes & Impact on Fraud Detection
Saw the report on Google’s 2025 stats: 8.3 billion ads blocked and nearly 25 million ad accounts suspended. While the volume of adware is staggering, the Android 17 privacy overhaul is the real story here.
The tightening of Play Store policies regarding contact and location permissions is long overdue. We've seen a massive shift from traditional malware to "fleeceware" and aggressive data-harvesting apps that abuse ACCESS_FINE_LOCATION and READ_CONTACTS to build tracking profiles.
With Android 17, third-party apps are going to have a much harder time justifying these permissions. From a defense perspective, this should lower the signal-to-noise ratio in mobile DLP alerts, as legitimate apps will be forced to adhere to stricter "access only when needed" protocols.
Here is a basic KQL query to start identifying apps that might still be abusing background location access in your environment:
DeviceAppEvents
| where Timestamp > ago(30d)
| where ActionType == "LocationPermissionRequested"
| where OSPlatform == "Android"
| extend AppName = initiatingProcessAccountName
| project Timestamp, DeviceName, AppName, ActionType
| summarize count() by AppName, DeviceName
| order by count_ desc
For those managing mobile fleets, how are you planning to update your MDM allow-lists for this? Are you seeing apps requesting permissions that seem unrelated to their function?
This is going to be a headache for our BYOD policy. We rely on specific telemetry from third-party MDM agents that currently require full contact list access for 'emergency contact' features. We'll likely have to switch to specific APIs rather than raw access. On the ad blocking front, I'm glad to see the numbers. We've seen a decline in 'system booster' adware hitting our junior staff devices recently, which correlates with this crackdown.
From a pentesting perspective, it's a cat-and-mouse game. While Google restricts explicit permissions, we often see apps switching to indirect methods like inferring location via Wi-Fi SSID scans or IP geolocation, which don't always trigger the standard permission prompts in earlier Android versions.
If you are auditing an Android 17 device, check if the app holds the NEARBY_WIFI_DEVICES permission, which can sometimes be a proxy for location tracking:
adb shell dumpsys package | grep -A 5 'requested permissions'
It'll be interesting to see if the new policies cover these indirect vectors.
Valid point on the SSID inference, Viktor. To stay ahead of this shift, teams should start auditing apps for the NEARBY_WIFI_DEVICES permission introduced in Android 13, as it's now the primary vector for those indirect location lookups. You can quickly check manifest usage on a test device using:
adb shell dumpsys package packages | grep -A 5 "android.permission.NEARBY_WIFI_DEVICES"
It helps identify which apps are maintaining that 'fuzzy' location capability without triggering the standard alerts.
Since explicit access is tightening, fraudsters will likely pivot to side-channels like battery usage or sensor data for profiling. During dynamic analysis, I recommend monitoring excessive AlarmManager wakeups which often hide tracking logic. This quick snippet helps isolate potential background polling:
adb shell dumpsys alarm | grep -A 10 "Pending Alarm Batches"
Has anyone else noticed an uptick in apps requesting POST_NOTIFICATIONS solely to keep background services alive?
Valid points on the side-channel pivots. Beyond the manifest permissions, we should also look for background service triggers that might persist data collection. A quick way to identify high-risk indicators in an APK bundle is checking for QUERY_ALL_PACKAGES usage combined with advertising IDs.
aapt dump badging app.apk | grep -E 'package:|uses-permission:QUERY_ALL_PACKAGES'
This often reveals aggressive profiling attempts that standard location checks might miss.
Don't overlook the abuse of NotificationListenerService. As direct access tightens, fleeceware often pivots to listening for notifications to scrape PII or 2FA codes. It's easily social-engineered as a 'chat head' feature. When auditing, you can quickly identify these risks using aapt:
aapt dump xmltree app.apk AndroidManifest.xml | grep -A 5 "android.service.notification.NotificationListenerService"
It’s a high-signal indicator for aggressive data harvesting without needing the restricted contact permissions.
From a compliance standpoint, the permission tightening aligns well with privacy regulations, but verifying "essential functionality" claims is now critical. To audit which installed apps currently hold high-risk permissions during your next review, you can use this adb snippet to generate a list:
adb shell 'pm list packages -f | while read line; do pkg=$(echo $line | cut -d= -f2); perm=$(adb shell dumpsys package $pkg | grep "requested permissions:" | grep "ACCESS_FINE_LOCATION"); if [ -n "$perm" ]; then echo $pkg; fi; done'
This helps validate your inventory against the new policy requirements.
With these stricter policies, we need to proactively audit client fleets for legacy permission reliance before functionality breaks. I recommend inventorying apps that still request READ_CONTACTS to identify potential business continuity risks. You can quickly scan a test device using this ADB command to flag non-compliant software for review:
adb shell pm list packages -f --uses-permission android.permission.READ_CONTACTS
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access