By 
Google is developing a new public API that would let any Android app tap into the same on-device content classification system behind Android System SafetyCore, the pre-installed scanning service that triggered a global privacy backlash after it appeared on billions of devices without user consent or an app icon. The API, called ContentSafetyManager, has surfaced in Android's developer preview documentation and is currently listed under API level 10000, a placeholder value Google uses to mark features still in active development.
The move matters because it would formalise and expand a capability that many Android users did not know existed on their phones in the first place, and that a portion of the security and privacy community has spent the past year and a half trying to remove.
What SafetyCore actually is
Android System SafetyCore first drew attention in early 2025 when users noticed it installing silently in the background, without a launcher icon or an explanatory prompt. According to Google's own support documentation, the package (com.google.android.safetycore) provides infrastructure that lets other apps flag unwanted content, and the classification work happens entirely on the device. Google states that results are not shared with its servers and that the service only activates when an installed app specifically requests content to be classified.
In practice, its most visible use case is Sensitive Content Warnings in Google Messages, which blurs nudity in incoming or outgoing images unless a user turns the feature off, and displays a warning before the content is shown. The setting is opt-out for accounts flagged as belonging to unsupervised teens and opt-in for adults.
The backlash was never really about what the tool claimed to do. It was about how it arrived. Because the app has no icon and reinstalls itself through Play Services updates even after users try to remove it, communities such as Reddit's r/degoogle have continued to document its reappearance more than a year after launch. One workaround that has circulated widely involves sideloading a placeholder app with the same package name and an inflated version number, so the Play Store cannot silently overwrite it with the real SafetyCore. Because the scanning model itself is closed source, users and researchers have had no way to independently confirm Google's claims about where the data goes; they are relying entirely on Google's own documentation and assurances.
What ContentSafetyManager changes
The new API, referenced in Android's developer reference under the android.app.contentsafety package alongside supporting classes such as ClassifiableContent and ContentClassificationResult, exposes the same underlying content safety service to any app that requests access to it. Rather than every messaging, dating, or gallery app building and shipping its own resource-heavy detection model, a developer can submit a file, specified by its MIME type and raw data, and receive one of four classification outcomes: allowed, warning, blocked, or unclassified.
Google's documentation reportedly describes the service as one that "allows granted apps to manage content safety service configured on the device," according to Android developer documentation cited by Cybernews, which first reported on the API's presence in preview builds. The documentation does not reference SafetyCore by name, nor does it define a specific "nudity" category, leaving the exact scope of what the classifier flags somewhat opaque even to developers building against it.
The stated intent mirrors what Apple already offers through its SensitiveContentAnalysis framework, which powers Communication Safety on iPhones and is similarly available to third-party developers. In both cases, the pitch to developers is privacy-preserving moderation: apps get a safety signal without having to route users' private photos through their own remote servers.
Why researchers are uneasy anyway
The practical risk security researchers have flagged is narrower than the API's implications suggest. Content classification, on its own, does not grant an app broader access to a user's photo library or storage. An app still needs its own separately granted permissions to reach files in the first place. Where the concern sharpens is in combination: an app that already holds broad storage access could, in theory, use the classifier to rapidly sort through a user's private media locally, without needing to invent its own detection pipeline or exfiltrate the files to do it.
The bigger and more structural worry, raised repeatedly by privacy advocates since SafetyCore's debut, is what cryptographers call function creep, or more formally, the risks associated with client-side scanning. The concern is not that Google's current implementation is malicious. It is that building a system-level, auto-updating classification pipeline onto billions of devices creates infrastructure that could later be repurposed with nothing more than a routine software update, no reboot, no visible prompt, and no meaningful way for an average user to notice the change.
This is close to the argument the Electronic Frontier Foundation and other cryptography and privacy groups made in 2021, when Apple proposed and then abandoned a client-side system to detect child sexual abuse material on iPhones. The objection then was not primarily about Apple's intentions, but about what the architecture made possible afterward: once a device inspects files locally before they are encrypted, sent, or stored, the protections that end-to-end encryption is supposed to guarantee become harder to rely on. Apple ultimately scrapped that plan and moved to the opt-in, on-device nudity-blur feature it still uses today, the same general approach Google has taken with SafetyCore.
Whether that scenario is likely for Android's content safety pipeline is a separate question from whether it is technically possible. Independent researchers, including teams behind alternative Android builds such as GrapheneOS, actively monitor Play Services binaries for unexpected behaviour, and any sudden shift toward broader file indexing or telemetry would likely draw scrutiny quickly. In its current design, the API also operates on a request-response basis rather than running as a background daemon that scans a device's full storage on its own. Google has also faced regulatory pressure of a different kind before, most notably around device updates and default settings in markets like the European Union, which has made unannounced, sweeping changes to core Android services somewhat more exposed to outside review than they once were.
Why this matters beyond SafetyCore's home market
Android's dominance is not evenly distributed globally, and it is especially pronounced in Kenya, where the platform is estimated to account for the overwhelming majority of smartphones in use, according to mobile analytics estimates from StatCounter and industry trackers. That concentration means changes to core Android system services, even ones framed narrowly around messaging safety, reach a large share of the country's mobile users by default rather than by choice, since services like SafetyCore are not something most Android owners actively opted into or were meaningfully informed about.
Kenya's Data Protection Act, 2019, gives the Office of the Data Protection Commissioner authority over how personal data, including content generated or processed on a device, is collected and handled, though on-device processing that never leaves the phone sits in a greyer regulatory zone than server-side data collection typically does. Neither Google nor Kenyan regulators have issued a public statement specific to ContentSafetyManager, and the API remains in preview rather than general release, meaning its eventual behaviour, permission requirements, and rollout timeline could still change before it reaches production Android builds.
Google has been contacted for comment on the API's development timeline and its relationship to SafetyCore, and this story will be updated if a response is provided.
Comments