com.sec.usbsettings Copy

A very small Samsung platform component that devices report under the label "USBSettings". Samsung ships it as a standard part of Galaxy firmware: it is listed as "USBSettings", package com.sec.usbsettings, in Samsung's own Knox Common Criteria mode application lists, which inventory the software preinstalled on a certified model. Samsung does not publish a description of what it does anywhere we could find, so this note states only what can be sourced. The provenance recorded on this site is unusually clear for a component with no documentation. It is preinstalled and Samsung-signed with certificates that also sign the framework, it has no launcher entry (no user-facing observation in our sample), it is tiny at roughly 37 KB to 76 KB, and it declares just two permissions: RECEIVE_BOOT_COMPLETED, so it starts with the device, and android.permission.MANAGE_USB. That second permission is defined in AOSP as allowing "an application to manage preferences and permissions for USB devices", at protection level signature|privileged, so it is only grantable to a platform-signed or privileged app. A privileged component that starts at boot and holds the USB management permission is consistent with a role in how the device handles USB connections, but the specific behaviour is not documented and is not asserted here. Version note: the version string has not moved. Samsung's Common Criteria lists record it as version 1 on the Galaxy S7 LTE (Android 8) and version 1.0 on both the Galaxy S20+ 5G (Android 10) and the Galaxy S21+ 5G (Android 11), and every observation in this database is also 1.0, while target SDK spans 31 to 37 and the package size roughly doubles across the sample. So the code has clearly been rebuilt across many Android releases without a version bump, and whether its role changed over those releases cannot be sourced. Treat the static version as a naming habit rather than evidence that nothing changed. No observation in our sample is marked Play-eligible, so on the devices we have seen it is updated only with firmware. For Android Enterprise, EMM and kiosk fleets, the practical point is that USB behaviour on a managed device is meant to be controlled by policy rather than by acting on this package. Android Management API policy covers it directly, with usbFileTransferDisabled described as "Whether transferring files over USB is disabled. This is supported only on company-owned devices." and now marked deprecated in favour of deviceConnectivityManagement.usbDataAccess. On Samsung specifically, Knox Service Plugin adds device restrictions including "Allow USB debugging", "Allow USB media player", "Allow USB host player", "Allow USB tethering" and a USB exception list of permitted device classes. Those are the supported levers. Disabling a privileged component that holds MANAGE_USB is a different and undocumented action, and because Samsung does not describe what the package does, the effect on charging, file transfer, accessory handling or ADB cannot be predicted from the outside. Test on a single device before considering it on a fleet, and prefer the documented policies.

• Galaxy S21+ 5G (SM-G996B, 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 S7 LTE (SM-G930R4, Android 8) Common Criteria mode application list - Samsung Knox Documentation →
• MANAGE_USB permission declaration - Android (frameworks/base) core AndroidManifest.xml →
• Device restrictions - Knox Service Plugin, Samsung Knox Documentation →
• Policy resource reference - Android Management API →
• Package provenance for com.sec.usbsettings - 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 2 permissions: 1 signature or system-level and 1 install-time. The signature/system share marks it as a privileged component, not an ordinary app.
• Never reported as user-facing, so it runs as a background or system component rather than an app the user opens.