com.samsung.android.allshare.service.mediashare Copy

Labelled "Nearby Service" on Galaxy devices, this is a Samsung-signed system package with no launcher entry: this site records it as not user-facing on every observation, and the key that signs it also signs the Android framework. Reading the package name alone, the "mediashare" element names media sharing and the "allshare" element is Samsung's own; no source examined here documents what Samsung intends either to denote, so placing this component among Samsung's media sharing and discovery services is an inference from naming rather than a documented statement. Samsung ships several separate nearby and sharing components, and this site documents Smart View, Quick Share and Nearby device scanning under their own packages; Samsung does not document how the responsibilities are divided between them, so this note does not assert that division. The declared permission set recorded here is the substance, and it is a wide one for a background service. It includes ACCESS_BACKGROUND_LOCATION, NEARBY_WIFI_DEVICES, which the platform manifest defines as required to advertise and connect to nearby devices via Wi-Fi at dangerous protection level, and LOCAL_MAC_ADDRESS, which the manifest defines as allowing applications to read the local Wi-Fi and Bluetooth MAC address. Alongside those sit CHANGE_WIFI_MULTICAST_STATE, CHANGE_WIFI_STATE, CHANGE_NETWORK_STATE and INTERNET, a set consistent with multicast-based discovery on the local network. On the data side it declares MANAGE_EXTERNAL_STORAGE, which the manifest defines as broad access to external storage in scoped storage and describes as intended for the few apps that need to manage files on behalf of users, together with WRITE_MEDIA_STORAGE, READ_EXTERNAL_STORAGE, com.samsung.android.providers.media.READ, READ_PROFILE and com.android.email.permission.READ_ATTACHMENT. It also declares INTERACT_ACROSS_USERS and MANAGE_USERS, the platform permissions for acting across the users on a device, and three permissions in its own conv.svc.sec.nearby namespace covering media sharing and reading and writing its configuration. Declaring a permission is not the same as exercising it, and Samsung publishes no functional documentation for the package, so this note records the reach it is built with rather than claiming what it does with that reach. Version note, and this is the part worth checking before planning around it. Builds observed here declare android.permission.ACCESS_LOCAL_NETWORK, the permission behind Android's local network protections. Google's documentation states that during Android 16 the permission is an opt-in feature, so only apps that opt in are affected, and that starting in Android 17 local network protections are mandatory and enforced for apps targeting Android 17 or higher, with the local network blocked by default for apps that update their target SDK. That matters here because discovery of this kind depends on exactly the traffic those protections gate, including multicast DNS and SSDP. The site records target SDKs from 29 to 36 and observations from API 28 through API 37, suggesting that at least one observed build was prepared for that gating; the permission record on this site is aggregated across observations and does not identify which build first declared it, so the specific release cannot be pinned from the evidence examined here. The version trail otherwise shows steady development rather than replacement. Samsung's own Common Criteria application lists record it at 2.2 on Android 9-era Galaxy S10+ firmware, and at 3.0.11.19 and 3.0.11.17 on the Android 11-era Galaxy S20 FE and Galaxy S20 Ultra lists; this site records 3.3.14.17 through 3.3.21.10, on Samsung hardware only, across models ranging from SM-N950U1 and SM-G973U to current Galaxy devices such as SM-S731B and SM-A566B. For Android Enterprise, EMM and kiosk use, the interest is potential data egress rather than anything a user will see. This is a background service whose permissions are consistent with local-network discovery and with broad media access across shared storage, on hardware that may be shared, unattended or deployed on a network the organisation does not control. Whether it exercises any of that in a given deployment is not documented by Samsung and is not claimed here. On a corporate network, local network discovery by an undocumented OEM service is worth a deliberate decision rather than an assumption. Its cross-user permissions are worth noting for work profile deployments, though what it actually does across a profile boundary is not documented and is not claimed here. Samsung documents neither what depends on the package nor which user-facing sharing features stop working without it, and this site documents Samsung's other sharing components separately, so disabling is rated caution and should be tested per device model rather than applied fleet-wide on the strength of the name.

• core/res/AndroidManifest.xml (NEARBY_WIFI_DEVICES, LOCAL_MAC_ADDRESS, MANAGE_EXTERNAL_STORAGE) - Android platform source →
• Local network permission (ACCESS_LOCAL_NETWORK, Android 16 opt-in and Android 17 enforcement) - Android Developers →
• Galaxy S10+ LTE (G975F) application list - Samsung Knox CC Mode documentation →
• Galaxy S20 FE 5G (G781B) application list - Samsung Knox CC Mode documentation →
• Galaxy S20 Ultra 5G (G988W) application list - Samsung Knox CC Mode documentation →
• Package provenance for com.samsung.android.allshare.service.mediashare - 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 30 permissions: 4 runtime (user-granted), 8 signature or system-level, 10 install-time and 8 vendor or uncatalogued.
• APK size ranges from 0.6 MB to 2.8 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.