com.samsung.android.providers.contacts Copy

Samsung's own "Contacts Storage" provider, signed by Samsung OEM keys in our sample. It fills the same role on Galaxy hardware that the Android Open Source Project Contacts Provider fills elsewhere: it is the central store the dialer, contacts app, messaging apps and any app holding contacts permission read from and write to, and it has no user interface of its own. Its recorded permissions are consistent with that role, covering reading and writing contacts, call log and voicemail, directory search binding, sync settings and the default contacts account. Note the package name. AOSP's provider, documented separately on this site, is com.android.providers.contacts; this is a distinct package under Samsung's own namespace. In this dataset the two look complementary: at the time of verification the device count recorded for the AOSP package plus the device count recorded for this one equalled the total number of devices sampled, which is consistent with Samsung's provider standing in for the AOSP one on Galaxy builds rather than sitting alongside it. Both counts are visible on the provenance endpoints cited below and will drift as the sample grows, and we have not sourced Samsung documentation confirming the substitution, so treat this as an observation about the dataset rather than a documented design. For Android Enterprise, EMM and kiosk use it has no enrolment or management role, but it is core infrastructure. Disabling or removing it would break contact storage device-wide, so dialling a saved contact, caller name display, contact pickers and anything else that reads contacts would stop working. Where you need to control contact visibility in a managed deployment, use the policy controls built for it rather than touching the provider. Those controls have a version dimension worth checking: DevicePolicyManager.setCrossProfileCallerIdDisabled was added in API level 21 and setCrossProfileContactsSearchDisabled in API level 24, both were deprecated in API level 34, and from API level 34 the replacements are setManagedProfileCallerIdAccessPolicy and setManagedProfileContactsAccessPolicy, which take a PackagePolicy. Confirm which of these your EMM actually uses on the Android versions you run. Version note: builds observed here run from 13.1.16 to 16.0.21 and target API 31 up to 37, so it tracks current Android releases. The leading version component matches the Android major version those builds ship on, but Samsung does not document its versioning scheme for this package, so do not read anything more into the number than that.

• Contacts Provider - Android Developers →
• DevicePolicyManager (cross-profile caller ID and contacts search) - Android Developers →
• Package provenance for com.samsung.android.providers.contacts - Android System App Database →
• Package provenance for com.android.providers.contacts - Android System App Database →

• Signed by the device maker's own signing key (Samsung), so it is an OEM preinstall, but 2 different certificates appear across the fleet, so OEMs ship their own builds of it. Inferred from the certificate appearing only on Samsung devices (9 packages, 229 observations).
• Its largest observed manifest declares 52 permissions: 8 runtime (user-granted), 13 signature or system-level, 8 install-time and 23 vendor or uncatalogued.
• APK size ranges from 3.4 MB to 8.5 MB across the reporting device profiles, so the build differs substantially between them.
• Never reported as user-facing, so it runs as a background or system component rather than an app the user opens.