com.samsung.android.biometrics.app.setting Copy

A Samsung platform component that devices report as "Biometrics", and which localises with the device (for example "Datos biométricos", "Dati biometrici", "Biometrische Daten"), so it is a settings surface rather than a background service with an internal name. Samsung publishes no package-level documentation for it, so its exact responsibilities are not a sourced fact. What this site records is that it is preinstalled, Samsung-signed with certificates marked as also signing the framework, has no launcher entry, and declares a permission set that is squarely about biometric enrolment and the lock screen: MANAGE_BIOMETRIC, MANAGE_FINGERPRINT, USE_BIOMETRIC, USE_FINGERPRINT, SET_BIOMETRIC_DIALOG_ADVANCED, DEVICE_POWER, USER_ACTIVITY and INTERACT_ACROSS_USERS_FULL. Reading that as the settings and management surface behind Samsung's biometrics options is inference from the label and permissions rather than something Samsung has published, and it is flagged here as such. What Samsung does document is the behaviour that sits behind it. Knox states that "Raw biometric data or its derivatives, such as templates, are never accessible outside the secure isolated environment, such as the Trusted Execution Environment (TEE) or Secure Element", that biometric data is encrypted with device-specific keys available only inside the TEE, and that users must keep a backup pattern, PIN or password alongside a biometric. Knox also documents re-authentication intervals that are worth knowing when a deployment expects biometrics to work unattended: face recognition requires re-authentication every 24 hours or after the device has been idle for 4 hours, and fingerprints require re-authentication every 72 hours. Nothing here depends on this particular package being the component that implements those rules; they are properties of the platform. Version note: this site's sample spans target SDK 31 to 37 with a version name of 1.0.0 throughout, so the package has tracked Android 12 through recent releases without a version bump this site can use to date changes. Whether the settings it exposes changed across those releases could not be sourced. One detail worth flagging is that a meaningful share of observations report the raw package name rather than a translated label, which usually indicates the component was enumerated without its resources resolving rather than that it is unlabelled. For Android Enterprise, EMM and kiosk use the important point is that this is not the control surface an administrator should be reaching for. Biometric use on the lock screen is governed by policy, not by removing a settings app: Android Management API exposes keyguardDisabledFeatures with values including DISABLE_FINGERPRINT ("Disable fingerprint sensor on secure keyguard screens"), FACE, IRIS and BIOMETRICS ("Disable all biometric authentication on secure keyguard screens"). Use those where biometric unlock must be prevented. Disabling this package instead is likely to remove or break the user's route to enrol and manage biometrics without actually enforcing anything, and given its platform-level signing the wider effects are hard to predict, so treat it as caution and test on a single device before considering it on a fleet.

• Biometric authentication - Samsung Knox Documentation →
• Policy resource (KeyguardDisabledFeature) - Android Management API →
• Package provenance for com.samsung.android.biometrics.app.setting - 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 15 permissions: 7 signature or system-level, 4 install-time and 4 vendor or uncatalogued.
• APK size ranges from 3.9 MB to 14.4 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.