com.samsung.faceservice Copy

A Samsung background service that almost every observation on this site reports under the untranslated label "FaceService", in every locale recorded, so it is an internal service name rather than an app a user opens. The one exception is a single en-us observation that records the raw package name instead, which usually means the component was enumerated without its resources resolving rather than that it is unlabelled. It is preinstalled and Samsung-signed with certificates this site also records as signing the framework, has no launcher entry, and is not marked Play-eligible in any of our observations, so on the devices seen here it ships and updates with firmware rather than through a store. Samsung publishes no package-level documentation for it, so what follows rests on its manifest and on Samsung's own certification inventories rather than on a written description. The permissions it declares point at faces in stored media rather than at unlocking the device. It requests READ_MEDIA_IMAGES, READ_MEDIA_VIDEO and READ_MEDIA_VISUAL_USER_SELECTED on the platform side, and on the Samsung side com.samsung.android.providers.media.CMH, com.samsung.android.providers.media.READ, com.samsung.cmh.SKIPHEAVY, com.sec.android.gallery3d.provider2.WRITE, com.samsung.android.permission.MEDIA_CLOUD_CONTENTS, read and write permissions on Samsung's on-device AI search (com.samsung.android.scs.ai.search.permission.READ and WRITE), and read and write permissions named for a face provider of its own, com.sec.face.provider.FaceProvider.data.READ and WRITE. It also holds FOREGROUND_SERVICE, WAKE_LOCK, RECEIVE_BOOT_COMPLETED and ACCESS_NETWORK_STATE. Reading that as a component that detects and indexes faces in on-device photos and videos, and exposes the result to the Samsung gallery and media stack, is inference from the permission set and is flagged here as such. There is a hint in one direction: com.samsung.cmh, the CMHProvider component documented separately on this site, requests a permission named com.samsung.faceservice.START. That is an integration point named for this package, not evidence that any call happens at runtime, and it is offered on that basis. One point is worth stating plainly because the name invites the opposite conclusion. This package requests no biometric permission in anything this site records, which is a reason to doubt that it is the component behind Samsung's face unlock rather than proof of it. Biometric enrolment and the lock screen sit behind the platform biometric stack and Samsung's biometrics settings surface, which is documented separately on this site. Do not read the name as meaning this package unlocks the device. Version note: it has been carried across many Android releases and is actively developed. Samsung's Common Criteria mode application lists record it at version 2.0.65 on the Galaxy S8+ and 2.0.72 on the Galaxy Note9 (both Oreo), 4.0.12 on the Galaxy S20+ 5G (Android 10), and 4.2.07 on the Galaxy S20 5G and 4.2.16 on the Galaxy S21+ 5G (both Android 11), while this site's sample runs from 7.0.13 to 12.1.09 across API 28 to 37, with target SDKs from 30 to 36 and package sizes from roughly 174 KB to 15.9 MB. Worth noting that the two Oreo lists record the row under the raw package name rather than the "FaceService" label that later lists and this site use, so the label settled at some point after Oreo. Those are versions and sizes, not behaviour: Samsung publishes no changelog, and whether the component's role changed across those releases, or only its implementation, could not be sourced. For Android Enterprise, EMM and kiosk use we found no source making it an enrolment, policy or compliance dependency, and there is nothing for a user to reach. Two considerations pull against each other. It is a privileged reader of the photos and videos on the device, and it requests access to network-state information, though it does not request INTERNET in anything this site records. On a privacy-sensitive deployment it belongs in the same review as the rest of the Samsung media stack rather than being waved through. Against that, at least one other Samsung component requests a permission named for starting it, so removing it is the kind of change that surfaces later as broken gallery search, people grouping or media sync rather than as an immediate failure. Where a preinstalled Samsung app genuinely has to go, Samsung documents blocking it by package name through Knox Manage's application policies; test on a single device before applying it to a fleet.

• Galaxy S21+ 5G (SM-G996B, Android 11) Common Criteria mode application list - Samsung Knox Documentation →
• Galaxy S20 5G (SM-G981U, Android 11) Common Criteria mode application list - Samsung Knox Documentation →
• Galaxy S20+ 5G (SM-G986U1, Android 10) Common Criteria mode application list - Samsung Knox Documentation →
• Galaxy Note9 (SM-N960N, Android 8) Common Criteria mode application list - Samsung Knox Documentation →
• Galaxy S8+ LTE (SM-G955U1, Android 8) Common Criteria mode application list - Samsung Knox Documentation →
• Enable or disable a specific system app - Knox Manage - Samsung Knox Documentation →
• Package provenance for com.samsung.faceservice - Android System App Database →
• Package provenance for com.samsung.cmh - 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. It also signs the Android framework, so it is a platform-level key on its device(s). Inferred from the certificate appearing only on Samsung devices (508 packages, 10196 observations).
• Its largest observed manifest declares 17 permissions: 3 runtime (user-granted), 4 install-time and 10 vendor or uncatalogued.
• APK size ranges from 0.2 MB to 15.9 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.